Token Launch Protocols and the MiCA Perimeter

Automated token launch platforms have become one of the largest sources of transaction volume and protocol revenue in the industry. Pump.fun on Solana, Pons on Robinhood Chain and a widening set of comparable platforms on other chains now issue tokens in the hundreds of thousands, and at points their fee revenue has placed them among the highest earning applications in the sector. The mechanics are well documented and largely open source. Where the persons who deploy and operate these protocols stand under Regulation (EU) 2023/1114, the Markets in Crypto-Assets Regulation, is not documented at all.

The question has become practical. The MiCA transitional periods closed on 1 July 2026, and ESMA has since called on unauthorised providers to wind down and reminded non-EU firms that they cannot serve Union clients outside the narrow reverse solicitation gateway. Simultaneously the European Commission's targeted consultation on the review of MiCA, open until 30 September 2026, asks the market to supply the criteria for deciding whether a decentralised application is fully decentralised. The perimeter is being enforced and reconsidered at the same time. This note maps the position service by service, confined to the persons who offer the protocol, meaning the deployers, the operators of the interface and the recipients of the protocol fee. The position of a person who mints a token through such a platform is a different question, not addressed here. We have also anonymised the architectures: what follows describes two structural archetypes currently available in the market, and applies to any implementation sharing the relevant features rather than to any particular provider.

The architecture, stated neutrally

In the first archetype, the curve model, a single permissionless transaction deploys a fixed supply token at a deterministic address and initialises a protocol-owned pricing contract. That contract quotes against a constant product invariant seeded with a virtual reserve, so it can quote from the first unit sold without any real quote liquidity having been contributed. Purchasers transact with the contract, not with each other. When cumulative purchases exhaust a reserved allocation, the accumulated reserves are converted into a full range position on a conventional automated market maker, and the liquidity provider claim over that position is burned or locked with no withdrawal path. A fee is taken on the quote leg of every transaction in both phases and split between a protocol recipient and the token creator on a schedule the operator sets. In the second archetype, the direct pool model, there is no price discovery phase at all: the same transaction deploys the token, initialises a pool on a third party automated market maker at a fixed fee tier, mints a one-sided position and locks it. The token trades in its final venue from the first block, graduation is a status label rather than an event, and revenue reaches the operator and creator as liquidity provider fees inside a position nobody can withdraw.

Both sit on a common off-chain layer, and that layer matters more to the analysis than the contracts do. There is an interface that discovers, ranks and presents new tokens, and an indexing pipeline behind it. There is frequently an API that assembles, and in some implementations partially signs, the transaction the user countersigns. There are named fee recipient addresses, and privileged administrative roles that can vary launch parameters, halt launches, redirect a creator's fee stream and, in one implementation, move reserves in transit between curve and pool. In at least one live implementation, contracts custodying liquidity and controlling creator earnings have deployed addresses and no published source.

First threshold: are these tokens within MiCA at all?

Article 2(4)(a) removes crypto-assets qualifying as financial instruments from MiCA's scope, and Article 2(3) removes those that are unique and not fungible. ESMA's Guidelines on the conditions and criteria for the qualification of crypto-assets as financial instruments, ESMA75-453128700-1323, adopted under the Article 2(5) mandate, make displacement to Directive 2014/65/EU unlikely in the ordinary case: Guideline 7 provides that an expectation of future profit "should not in itself be sufficient to qualify a crypto-asset as a financial instrument in accordance with MiFID II". A fungible, transferable token conferring no rights against any person satisfies none of the cumulative transferable security criteria and is neither a money market instrument, a unit in a collective investment undertaking nor a derivative. Two qualifications. The guidelines never address rightless speculative tokens directly, and the words memecoin and meme appear nowhere in them, so the residual classification is an inference from the structure of Article 2 rather than a stated position. And Guideline 9 provides that where a hybrid token displays features of a financial instrument those characteristics take precedence, which keeps the boundary live for any platform issuing tokens with revenue entitlements, redemption rights or derivative payoffs. We proceed on the basis that the tokens are crypto-assets other than asset-referenced or e-money tokens, so Titles II, V and VI are the operative regimes.

Second threshold: is there a person, and does recital 22 help?

Recital 22 repays reading in full rather than in the abbreviated form in which it circulates. The Regulation "should apply to natural and legal persons and certain other undertakings and to the crypto-asset services and activities performed, provided or controlled, directly or indirectly, by them, including when part of such activities or services is performed in a decentralised manner. Where crypto-asset services are provided in a fully decentralised manner without any intermediary, they should not fall within the scope of this Regulation." The first sentence does more work than the second. It reaches activities performed, provided or controlled directly or indirectly, and contemplates that part of a service may be decentralised without taking the whole outside scope. The carve-out is narrow on its own terms, qualified twice over by "fully" and by "without any intermediary".

No European institution has interpreted it. The Commission, answering ESMA Q&A 2671 on 21 May 2026, accepted that listing a crypto-asset on a decentralised exchange in the Union could amount to an offer to the public, then said only that "[w]hether a platform is fully decentralised or not, is assessed on a case-by-case basis by the competent authorities". The joint EBA and ESMA report under Article 142, ESMA75-453128700-1391, records that "MiCAR, however, does not specify how to interpret references to fully decentralised". The Commission's consultation asks at question 61 which criteria should be used, offering a candidate list: an identifiable intermediary, control by an identifiable person, significant concentration of governance power, custody of user assets, non-open-source code, and marketing by an identifiable entity. The MFSA's discussion paper 03-2026 of 12 June 2026 reproduces almost the same indicators, treats the assessment as fact-specific, and observes that "most systems retain some features that could be considered centralised, even where the protocol is decentralised". The AMF, which has engaged with the question longest, is careful to state that its published material is not an official position.

Four official documents, each confirming that no interpretation exists. What can be said is that on every criterion any European institution has been willing to put in writing, neither archetype is fully decentralised: there are identifiable deployers, administrative keys that vary launch economics, named recipients of a continuous revenue stream, and an interface and marketing surface operated by an identifiable person, and in one implementation unpublished source for contracts holding live value. What follows from that is narrow. Not that these persons provide a crypto-asset service, only that they cannot use recital 22 to avoid the question. The definitions in Article 3(1) still have to be applied on their own terms.

Operation of a trading platform

Article 3(1)(18) defines the service as "the management of one or more multilateral systems, which bring together or facilitate the bringing together of multiple third-party purchasing and selling interests in crypto-assets, in the system and in accordance with its rules, in a way that results in a contract". Two drafting features matter. The definition requires the bringing together of multiple third-party interests, importing the multilaterality question. And unlike the MiFID II definition of a multilateral trading facility in Article 4(1)(22) of Directive 2014/65/EU, MiCA requires only that this occur "in accordance with its rules", not in accordance with non-discretionary rules. That is a lower threshold, and it removes an argument otherwise available in the MiFID II context.

ESMA has said little directly. Q&A 2579 of 20 June 2025, on shared order books, holds that "the management of an order book is one of the fundamental parts of the management of multilateral systems" and that the service is carried out "by each entity operating the different order books that are being shared". It establishes that the matching state is the object of the service and that more than one person can provide it in respect of the same venue, but it expressly disclaims any assessment of other models, is not authority on automated market makers, and should not be cited as though it were.

Where MiCA is silent the natural analogue is ESMA's opinion on the trading venue perimeter, most recently restated in ESMA74-276584410-11099 of May 2026, and its reasoning is uncomfortable for the curve model. ESMA applies four cumulative criteria at paragraph 11, and treats a system as "technology neutral, hence the type of technology used or whether it is automated or non-automated does not determine whether it is a system" at paragraph 13. At paragraph 30, "it is the functioning of the arrangement that is key to assess whether the activity should require authorisation". Most significantly, at paragraph 34, on a technology supplier that sets the terms of interaction rather than merely supplying software: "if the software vendor has embedded a number of rules that govern the interaction of trading interests in the system and does not allow investment firms to set its own rules: in this case, the software vendor would be operating a multilateral system." A bonding curve is functionally nothing other than a set of embedded rules governing interaction that no other person may vary.

The single dealer analysis compounds this. One might expect a curve to be bilateral, since every purchaser transacts with the contract rather than another purchaser. But ESMA's test for bilaterality, at paragraphs 42 and 43, is that the system "must not bring together third-party interests" and "its operator must deal on own account", the dealer being "required to take on market risk". Paragraphs 44 and 45 then close the door: where a system with a single liquidity provider "is operated by a third-party, who sets the rules of how trading interests interact and brings together trading interests without trading on own account, it cannot be considered as bilateral", and "[t]he bilateral nature of a system cannot refer only to the parties that agree on the transaction and disregard the operator of the trading system." The operator of a curve does not deal on own account and takes no market risk, which on ESMA's reasoning is exactly what disqualifies the arrangement from being bilateral.

The arguments the other way are not weak. ESMA's interaction criterion at paragraph 21 requires that the system allow users to react to trading interests, so that it is possible to "match, arrange and/or negotiate essential terms of a transaction". A curve permits none of that: a purchaser cannot see, respond to or negotiate with another purchaser's interest, only accept the contract's quote. On that reading the curve is neither a matching system nor a bulletin board but a third thing the opinion does not contemplate. There is also a structural argument from MiCA itself. Article 76(5) prohibits an operator from dealing on own account on the platform it operates, Article 76(1)(a) and (2) require admission approval processes and a suitability assessment of every crypto-asset admitted by reference to "the experience, track record and reputation of the issuer of those crypto-assets and its development team", Article 76(9) to (11) impose continuous pre-trade and post-trade transparency, and Article 76(12) requires settlement to be initiated within twenty-four hours. If the curve is a trading platform, the attaching obligations are ones the architecture cannot satisfy at the volumes these systems run without ceasing to be what it is. That is either a strong indication that the drafter did not have this architecture in mind, or an indication that it cannot lawfully be operated from the Union. The text does not say which.

The direct pool model looks materially different. The operator initialises a pool on somebody else's automated market maker and locks the position. It maintains no matching venue, and the rules of interaction are set by the underlying protocol rather than by the launch platform, so on ESMA's operator-centred reasoning it is probably not managing a multilateral system. One asymmetry also cuts in favour of providers generally. Article 1(5b) of Regulation (EU) No 600/2014, as amended by Regulation (EU) 2024/791, provides that all multilateral systems "shall operate either in accordance with the provisions of Title II of Directive 2014/65/EU concerning MTFs or OTFs or in accordance with the provisions of Title III of that Directive concerning regulated markets". MiCA contains no equivalent. It does not regulate systems; it regulates persons whose occupation or business is the provision of a crypto-asset service to clients on a professional basis, per Article 3(1)(15). That absence is the strongest textual argument that the legislature did not intend to capture systems operating without a person providing a service through them.

Exchange of crypto-assets for funds or for other crypto-assets

Articles 3(1)(19) and (20) define these as "the conclusion of purchase or sale contracts concerning crypto-assets with clients" for funds or for other crypto-assets "by using proprietary capital". Recital 85 speaks of exchange "by using their own capital", and Article 77 requires a non-discriminatory commercial policy, publication of a firm price or of the method for determining the price, and execution at the displayed price once the order is final. Against the curve model the fit is arresting in some respects and impossible in others. ESMA's Q&A 2653 of 14 October 2025 observes that the definition and the Article 77 obligations "entail that the CASP providing exchange services lacks discretion on fulfilling or not an order" once the client and order satisfy the published policy and finality conditions. That is an unusually good description of a contract that quotes deterministically and cannot refuse a conforming transaction, and Article 77(2)'s requirement to publish a method for determining the price is satisfied in substance by publishing the curve.

The obstacle is proprietary capital. The reserves in a curve contract are not the operator's: they are contributed by purchasers, held by the contract, and destined on graduation for a pool over which the operator's liquidity provider claim is burned or permanently immobilised. The operator does not fund the position, does not bear the market risk of holding the token, and cannot withdraw. Whatever else it is doing, it is not concluding purchase contracts using proprietary capital, and the MiFID II analogue confirms rather than circumvents the point, dealing on own account in Article 4(1)(6) of Directive 2014/65/EU meaning "trading against proprietary capital resulting in the conclusion of transactions". A second obstacle is that the contracts must be concluded "with clients", and Article 3(1)(39) defines a client circularly as any person to whom a crypto-asset service provider provides crypto-asset services. The Commission's answer to Q&A 2293 of 6 June 2025 supplies the only guidance: proprietary trading "typically lacks client relationships, as service providers act in their own name rather than for clients", in which case "CASP licensing is not required". The touchstone is the client relationship, and whether a person who deploys a contract that strangers transact with under published terms has clients is the question that answer does not reach.

The net position is that the curve model sits between the trading platform head and the exchange head and fits neither cleanly. It fails the exchange head because the capital is not the operator's, and it fails the classic bilateral characterisation for the same reason, which pushes it back toward multilaterality. That is an uncomfortable place to be, because it is the kind of gap a supervisor resolves by asking what the arrangement does rather than what it is called, which is precisely the instruction ESMA gives in Q&A 2653.

Execution of orders, and reception and transmission of orders

Article 3(1)(21) defines execution as "the conclusion of agreements, on behalf of clients, to purchase or sell one or more crypto-assets", and includes "the conclusion of contracts to sell crypto-assets at the moment of their offer to the public or admission to trading". Article 3(1)(23) defines reception and transmission as the reception of an order from a person "and the transmission of that order to a third party for execution". On the face of both, the ordinary launch platform does neither: the user signs and broadcasts, so the operator concludes no agreement on the user's behalf and transmits no order to a third party for execution. Q&A 2653 does not disturb that, because every limb of its analysis presupposes that the provider either concludes a contract or transmits an order.

What Q&A 2653 does supply is a method and a warning. National authorities "should not rely solely on the qualification provided by the CASP, or the terms used by the CASP in the contractual or marketing documentation", and should pay "special attention" to "the order fulfilment flow"; where a provider acts as counterparty the question is whether "a reasonable person in the client's position" would understand it to be acting as agent, and in cases of doubt involving retail clients "there should be a presumption that the CASP acts as an agent". Applied to the off-chain layer that produces an open question. Some implementations expose an API that constructs the transaction, resolves the accounts, generates the token's keypair server side, partially signs with it, accepts a fee payer distinct from the user, and submits only to a private block engine endpoint when a front-running protection flag is set. Each is a step in the order fulfilment flow performed by the operator rather than the user, and none is the conclusion of an agreement on the user's behalf. But a supervisor asking what a reasonable retail user would understand to be happening, when the platform builds and co-signs the transaction and chooses the submission path, may not find the distinction persuasive.

There is no guidance on this anywhere in the Union, and MiFID II offers none either, the equivalent question about order routing technology and smart order routers never having been squarely answered. The closest any European authority has come is the MFSA's question 27, asking "[t]o what extent should actors such as paymasters, bundlers, or AI-agent operators be considered as providing crypto-asset services under MiCA when such activities are offered on a professional and commercial basis?" That is the right question, posed and not answered. Two further points. The final limb of Article 3(1)(21) is directed precisely at the primary distribution moment a launch platform exists to serve. And Article 80(2), which prohibits a provider receiving and transmitting orders from accepting "any remuneration, discount or non-monetary benefit in return for routing orders received from clients to a particular trading platform", would be difficult for any launch platform whose architecture routes every trade to a single venue from which it takes a fee.

Placing of crypto-assets

This is, in our view, the least discussed and most exposed of the heads. Article 3(1)(22) defines placing as "the marketing, on behalf of or for the account of the offeror or a party related to the offeror, of crypto-assets to purchasers". There is no requirement to conclude a contract, hold an asset, receive an order or operate a venue. Marketing on behalf of or for the account of the offeror suffices, and recital 88 confirms that placing on behalf of an offeror "should not be deemed to be a separate offer", which is to say it is a service performed for the offeror rather than an offer in its own right.

A launch platform markets newly created tokens to purchasers. That is what its interface is for: a token page for each issuance, a discovery feed of new launches, ranked and trending listings, notification streams, and in some implementations creator livestreams and social integration. It does this in relation to tokens issued by the persons who use it, and takes a share of the trading fees those tokens generate, which is to say it is remunerated by reference to the success of the marketing. Whether that is done on behalf of or for the account of the offeror is the whole question. Against: the platform acts on its own account under standard terms of use rather than as agent for any individual creator, and the creator drives the offer. For: Article 79(1) presupposes an agreement between the placing provider and the offeror, and a launch platform's terms of use combined with a contractual creator fee share look very much like such an agreement, entered into on identical terms with every creator.

ESMA Q&A 2551, answered by the Commission on 18 February 2026, is the nearest official material and addresses a different arrangement, namely a person offering crypto-assets with the issuer's written consent, who "acts on behalf of the issuer and no CASP license is to be required, where that activity is not exercised in the context of the provision of the crypto-services". The launch platform case is untouched. There is no Q&A, guideline, national guidance or enforcement anywhere in the Union on whether a launch platform places the tokens launched through it, and the Commission's consultation does not mention launchpads at all. The MiFID II analogue is thin but not absent: Annex I Section A(7) of Directive 2014/65/EU lists placing of financial instruments without a firm commitment basis as an investment service in its own right, and it has never required the placing agent to take principal risk. Distribution is regulated separately from execution, and a person who distributes another's instruments to purchasers for reward has historically been inside the perimeter rather than outside it.

Custody, transfer services, advice and portfolio management

Custody, in Article 3(1)(17), means "the safekeeping or controlling, on behalf of clients, of crypto-assets or of the means of access to such crypto-assets". For a genuinely non-custodial platform this is a clean exclusion, and recital 83 puts the adjacent case beyond argument: "[h]ardware or software providers of non-custodial wallets should not fall within the scope of this Regulation." It is engaged directly where the platform operates a hosted wallet, generates and retains keys, or offers a mode in which it holds the user's key and submits on the user's behalf, and it is arguable where account abstraction, paymaster or bundler arrangements give the operator the ability to intervene in the movement of assets, the MFSA's formulation being the right test, namely who can ultimately exercise control or intervene. The locked liquidity position is an unresolved oddity: a contract holding a position nobody may withdraw is controlling crypto-assets, but the client on whose behalf it does so is hard to identify. Transfer services, in Article 3(1)(26), require a service of transfer on behalf of a person from one distributed ledger address to another, and a platform that constructs a transaction the user signs transfers nothing.

Advice is more dangerous than it looks, and the reason is recent. Article 3(1)(24) captures "offering, giving or agreeing to give personalised recommendations to a client" in respect of "one or more transactions relating to crypto-assets, or the use of crypto-asset services". ESMA's Q&A 2882 of 18 June 2026 holds that the MiCA advice perimeter "should be regarded as broader than the perimeter of advice under MiFID II", that "introductory services consisting of the recommendation of a crypto-asset service to a potential investor ... even if not made in relation to specific transactions in crypto-assets, may be regarded as advice on crypto-assets", and that the saving carve-out is confined to "providing solely a reference to a CASP (without further indications) equally accessible to all potential investors". ESMA was addressing introducers rather than protocol interfaces, but the wording is general. A generic, undifferentiated interface presenting the same information to every visitor sits within the carve-out. An interface that personalises what it surfaces by reference to the connected wallet, recommends a route, or curates and features particular tokens for particular users, may not. The Q&A is three months old and, so far as we can establish, has not been applied to a front end by anyone.

Portfolio management, in Article 3(1)(25), requires managing portfolios "in accordance with mandates given by clients on a discretionary client-by-client basis", which ordinary launch mechanics do not engage. Protocol-operated autonomous trading agents, tokenised agent products and vault strategies are a different matter, and ESMA's Q&A 2463 of 7 April 2025 confirms that its MiFID II material on automated and copy trading applies in the crypto-asset context at least for qualifying which service is provided.

Title II, and the white paper cascade

The offeror of a token launched through such a platform is the person who launches it, per Article 3(1)(13). The platform is not the offeror, and the Article 4 exemptions belong to the creator, though it is worth noting that the free issuance exemption in Article 4(3)(a) is unlikely to be available where the platform charges a launch fee or the creator receives a fee stream, since the second subparagraph of Article 4(3) provides that a crypto-asset is not offered for free where the offeror "receives from prospective holders of that crypto-asset any fees, commissions, or monetary or non-monetary benefits in exchange for that crypto-asset".

The provision that matters to the operator is Article 5(2): "[w]hen a crypto-asset is admitted to trading on the initiative of the operator of a trading platform and a crypto-asset white paper has not been published in accordance with Article 9 in the cases required by this Regulation, the operator of that trading platform for crypto-assets shall comply with the requirements set out in paragraph 1 of this Article." That is a conditional cascade of some severity. If the operator is a trading platform operator, and tokens reach trading on its initiative without a white paper, the operator inherits the obligation to draw up, notify and publish a white paper for each of them, to comply with Article 14's conduct duties, and to bear the civil liability Article 15(1) imposes toward every holder for information that is not complete, fair or clear. Articles 6(1)(c) and 6(3) contemplate this expressly, requiring the white paper to identify the operator and to substitute the operator for the offeror in the mandatory responsibility statement.

There is a partial answer. The Commission's answer to Q&A 2552 of 18 February 2026 holds that Article 5(2) does not apply to crypto-assets without an identifiable issuer, which per recital 22 fall outside Title II, while adding that platform operators must nonetheless "conduct suitability assessments, and determine issuer identifiability". For permissionless launches by pseudonymous creators that may take much of the sting out of Article 5(2), though it substitutes an obligation to assess identifiability which presupposes a process no launch platform currently runs. The wider point is that almost every consequence that matters to the operator is conditional on the trading platform characterisation, and those conditional obligations are ones the architecture cannot meet: Article 76(2) requires a suitability assessment of each crypto-asset by reference to its issuer's track record and development team, which is not a coherent exercise for anonymous creators issuing tens of thousands of tokens a day, and Article 76(13) requires that fee structures "do not create incentives to place, modify or cancel orders or to execute transactions in a way that contributes to disorderly trading conditions or market abuse", a direct problem for volume-based rebate and cashback mechanisms. The characterisation and the compliance consequences stand or fall together.

Title VI, which does not wait for a licence

The market abuse title changes the character of the analysis, because it does not depend on anybody providing a crypto-asset service. Article 86(1) applies Title VI "to acts carried out by any person concerning crypto-assets that are admitted to trading or in respect of which a request for admission to trading has been made". Article 86(2) extends it to "any transaction, order or behaviour ... irrespective of whether such transaction, order or behaviour takes place on a trading platform", and Article 86(3) to "actions and omissions, in the Union and in third countries". Any person, on or off platform, inside or outside the Union.

Article 91(1) prohibits engaging or attempting to engage in market manipulation. Article 91(2)(a) captures, "unless carried out for legitimate reasons", entering into a transaction, placing an order or engaging in any other behaviour which gives or is likely to give "false or misleading signals as to the supply of, demand for, or price of, a crypto-asset", or which secures or is likely to secure the price "at an abnormal or artificial level". Article 91(3)(b)(iii) treats as manipulation the placing of orders creating a false or misleading signal about supply, demand or price, "in particular by entering orders to initiate or exacerbate a trend". Three features of the architecture should be read against those provisions. The first is the protocol-operated autonomous trading agent, which in at least one live implementation mints additional supply and trades a newly launched token with equal buy and sell probabilities in a random walk during its first day of life, burning what it does not sell; whatever the intention, an operator-run programme of transactions generating volume and price movement that does not originate in third party demand requires a serious answer to Article 91(2)(a)(i). The second is the volume-linked rebate, returning a share of the fee to traders in proportion to their swap volume, which is a direct financial incentive to generate volume and engages both Article 91(2)(a)(i) and, if the platform characterisation applies, Article 76(13). The third is the protocol buy-back, funded from revenue and executed discretionarily, which needs testing against Article 91(2)(a)(ii).

What makes those questions sharper than their equivalents in traditional markets is the absence of the safe harbours a listed issuer would expect. Title VI contains no analogue to Article 5 of Regulation (EU) No 596/2014 on buy-back programmes and stabilisation, and no analogue to Article 13 on accepted market practices; the phrase "accepted market practice" does not appear in Title VI at all. The only qualifying language is the bare and undefined "unless carried out for legitimate reasons" in Article 91(2)(a), which does not extend to the fictitious device limb in Article 91(2)(b) or the dissemination limb in Article 91(2)(c). A programme capable of falling within a formal exemption if it concerned shares has no equivalent shelter here.

Article 92(1) then imposes on "[a]ny person professionally arranging or executing transactions in crypto-assets" the obligation to maintain effective arrangements, systems and procedures to prevent and detect market abuse, and to report without delay any reasonable suspicion regarding an order or transaction "and other aspects of the functioning of the distributed ledger technology such as the consensus mechanism". The expression is defined nowhere in the Regulation. Commission Delegated Regulation (EU) 2025/885, adopted under the Article 92(2) mandate, applies the obligation irrespective of the capacity in which the order is placed or the transaction executed, and irrespective of whether execution is on chain or off chain, and requires ongoing monitoring of the functioning of the distributed ledger including the consensus mechanism, an appropriate level of human analysis, and systems with sufficient capacity to operate in an algorithmic trading environment. ESMA has issued guidelines on supervisory practices under the Article 92(3) mandate, ESMA75-453128700-1408.

Everything in Articles 86 and 92 turns on one undefined phrase in Article 86(1), namely whether the tokens are admitted to trading or the subject of a request for admission. MiCA does not define admission to trading, and does not say whether a permissionless bonding curve or an automated market maker pool is a venue to which anything can be admitted. If it is, Title VI attaches to the whole ecosystem and Article 92 attaches to whoever professionally arranges the transactions. If it is not, the market abuse title is largely inert for these architectures notwithstanding the breadth of Article 86. That phrase carries more weight than any other question in this note, and no European institution has addressed it.

Access, third countries and the interface

Authorisation is not available on a light-touch basis to a person outside the Union. Article 59(2) requires a registered office in a Member State where at least part of the services are carried out, effective management in the Union, and at least one resident director. Article 61 permits provision at the client's own exclusive initiative, but ESMA's guidelines on reverse solicitation, ESMA35-1872330276-2030, construe solicitation broadly and technology-neutrally to include websites, applications, social media, search engine optimisation, sponsorship and remunerated influencer promotion, construe exclusive initiative narrowly, and give effect to the third subparagraph of Article 61(1), which disapplies any contractual clause or disclaimer purporting to characterise a solicited relationship as client-initiated. A globally accessible interface with no Union targeting is not obviously soliciting. An interface in a Union language that is not customary in international finance, promoted by Union-based creators for reward, or optimised for Union search traffic, is on ESMA's own examples a different matter.

ESMA has also already articulated, in another context, the objection to a structure separating a Union-facing interface from an extra-territorial protocol. Its opinion on broker models, ESMA75-453128700-1048 of 31 July 2024, addresses groups seeking authorisation for brokerage services while intending "to leave a large part of the group activities (and in particular the operation of a trading platform for crypto-assets) outside of MiCA", and instructs national authorities to ensure an application does not aim at obtaining "a 'legal cover' in the Union for third-country firms which seek to solicit clients or prospective clients in the Union". It concerns corporate structuring rather than protocols, but the logic that one cannot license the thin client-facing layer and leave the venue outside the perimeter transposes readily onto a front end and protocol split.

Against all of this, the Union's revealed posture is worth recording. Q&A 2711 of 8 December 2025 treats a decentralised exchange as a venue at which an authorised provider may execute, subject to client consent under Article 78(5), and regulates the provider rather than the venue. The EBA's supervisory work on money laundering risk requires providers to monitor flows to and from decentralised arrangements without asserting that those arrangements are in scope. And the Commission's consultation, at questions 62 to 65, canvasses provider due diligence, whitelists and protocol certification rather than an extension of the service perimeter. The working assumption across the institutions is to regulate the licensed access point and say nothing about the protocol, and ESMA staff put it plainly in a risk analysis of maximal extractable value, ESMA50-481369926-29744: "[i]n the EU, MiCA is not intended to directly address DeFi." That is staff analysis binding nobody, but it is the clearest expression of the institutional assumption available.

The four hinges

Reduced to essentials, the answer turns on four unresolved questions. The first is whether a deterministic pricing contract, deployed by an identifiable person who sets its terms and takes a fee from every transaction executed through it, is the management of a multilateral system. MiCA's definition is more permissive than the MiFID II analogue, requiring only that the bringing together occur in accordance with the system's rules rather than non-discretionary rules. ESMA's reasoning on embedded rules and on the limits of bilaterality points one way; its interaction criterion points the other; MiCA's silence on the equivalent of Article 1(5b) MiFIR points the other again.

The second is whether reserves accumulating inside such a contract can be proprietary capital when the person who deployed it neither funds them, bears their risk, nor can withdraw them. If they cannot, the exchange head is unavailable, and its unavailability makes the trading platform question harder rather than easier. The third is whether constructing, co-signing and routing a transaction that the user ultimately signs is a step in the order fulfilment flow of a regulated service; nothing in MiCA, the Q&As, national guidance or the MiFID II material answers this, and the MFSA has asked it without answering it. The fourth, and most consequential, is whether tokens issued and traded through these architectures are admitted to trading within the meaning of Article 86(1), a phrase that governs the entire market abuse title, applies to any person irrespective of authorisation, and is nowhere defined.

There is a fifth question, which is not a hinge but an omission. Nobody has asked whether a launch platform places the tokens launched through it within the meaning of Article 3(1)(22). Placing requires no venue, no capital, no order and no custody, only marketing on behalf of or for the account of the offeror. Of all the heads in Article 3(1)(16) it maps most naturally onto what a launch platform visibly does, and it has attracted no attention at all.

Where that leaves matters

As at the date of this note there is no European soft law or supervisory material of any kind addressing whether an automated market maker, a bonding curve or a liquidity pool constitutes the operation of a trading platform; whether operating a front end, interface or API for a protocol brings a person into scope; whether transaction construction and relaying is execution or reception and transmission; whether fee extraction from a protocol is relevant to scope at all; or how token launch platforms should be analysed. We have identified no enforcement action, public warning or supervisory decision in any Member State directed at a launch platform, a decentralised exchange, an automated market maker or a protocol interface operator, under MiCA or any predecessor national regime. The register of non-compliant entities ESMA maintains under Article 110 is where that would first become visible.

That is not the same as an answer that these protocols fall outside regulation. It is an absence of interpretation, in a Regulation whose recital 22 reaches services performed, provided or controlled directly or indirectly, whose market abuse title applies to any person anywhere in the world, and whose review is currently open. Providers reading the silence as comfort should note that the Commission has asked the market for the decentralisation criteria it lacks, that one national authority has already put on record that most systems retain features that could be considered centralised, and that the same authority is asking whether it should issue guidance on assessing decentralisation. The gap is being closed, and the direction in which it closes is not yet fixed. Anyone with a view worth having on where the line should fall has until 30 September 2026 to put it to the Commission.

---

This note is a general analysis of the regulatory perimeter and is not legal advice on any particular arrangement. Axis Group advises on digital asset regulation, licensing and market structure in Malta and across the European Union. If you would like to discuss how this analysis applies to a specific architecture, we would be glad to hear from you.