DeFi Front Ends under MiCA

I. Overview

Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA) has, in principle, applied since 30 December 2024. The longest transitional period permitted under Union law for providers already lawfully operating before that date ended on 1 July 2026; Germany had shortened this period to 31 December 2025. New market entrants were never covered by the grandfathering regime in the first place.¹

Against this backdrop, the question of whether and under which conditions operators of DeFi front ends require authorisation as crypto-asset service providers arises with practical urgency. A blanket answer is not available. Although MiCA is familiar with the notion of an "online interface", it does not turn the provision of a website or app into a stand-alone crypto-asset service. What matters is whether one of the services listed in Article 3(1)(16) MiCA is professionally provided to clients through the respective technical and organisational layer.²

The assessment must therefore be conducted by product and by transaction path. The same provider may offer pure analytics, a classic self-custodial swap and an intent-based order flow side by side within the same interface. These functions may have to be assessed differently under supervisory law.

II. The Relevant Framework of Analysis

1. Covered Asset and EU Nexus

Every front-end analysis is preceded by the question of the material scope of application. MiCA applies to services relating to crypto-assets, but not to crypto-assets that qualify as financial instruments within the meaning of MiFID II. Particularly with derivatives and perpetual contracts, securities regulation may therefore apply instead of MiCA. In addition, the service must be provided "in the Union"; for third-country providers, market solicitation, target clientele, contractual relationships and the actual provision of services to EU clients must each be examined separately.²

2. Who Is the Addressee of the Authorisation Requirement?

The actual authorisation requirement follows from Article 59 MiCA. Under that provision, a person may, in principle, provide crypto-asset services in the Union only if authorised as a crypto-asset service provider or if it belongs to the financial entities listed in Article 60 MiCA and meets the conditions set out there. Article 3(1)(15) describes the provider as a legal person or other undertaking whose occupation or business is the provision of one or more crypto-asset services to clients on a professional basis.²

Direct remuneration is not an express element of the definition. Conversely, not every indirect economic benefit turns an open-source project into a professional service. What must be assessed is the overall picture of the activity: its permanence, organisation, market solicitation, monetisation and the relationship with users.

3. Which Service Is Being Provided?

For transaction-related front ends, three services are regularly at the centre of the analysis:

• Reception and transmission of orders: the receipt from a person of an order to purchase, sell or subscribe for crypto-assets and the transmission of that order to a third party for execution, Article 3(1)(23) MiCA.
• Operation of a trading platform: the management of one or more multilateral systems which bring together, or facilitate the bringing together of, multiple third-party buying and selling interests, in accordance with the rules of the system, in a way that results in a contract, Article 3(1)(18) MiCA.
• Execution of orders on behalf of clients: the conclusion of agreements to buy or sell crypto-assets on behalf of clients, Article 3(1)(21) MiCA.

Depending on the product design, further services such as advice, transfer services, custody or the exchange of crypto-assets using proprietary capital may also become relevant. The three services mentioned above are therefore central for DeFi front ends, but not exhaustive.²

An important uncertainty must be borne in mind with respect to reception and transmission: the definition in Article 3(1)(23) refers generally to transmission to a "third party". Article 80(1), by contrast, describes the obligations of such a service provider by reference to transmission to a trading platform for crypto-assets or to another crypto-asset service provider. This does not necessarily rule out a broader reading of the term "third party", but it counsels against treating every mere call of an autonomous smart contract as a transmission of orders without further analysis.³

The same holds for the trading platform: an order book, a database or an auction is not sufficient on its own. What is decisive is whether multiple third-party interests interact within the system under its rules and whether that interaction results in a contract. The principles on multilateral systems familiar from the MiFID context can assist the interpretation; they must not, however, be transposed schematically onto every DeFi architecture.

4. Recital 22: No Blanket Safe Harbour

Recital 22 clarifies that crypto-asset services provided in a fully decentralised manner without any intermediary do not fall within the scope of MiCA. This is not a stand-alone authorisation or exemption provision, but an interpretative guideline on the reach of the Regulation. ESMA emphasises that full decentralisation is to be assessed by the competent authorities on a case-by-case basis. EBA and ESMA further point out that MiCA may apply to activities that are provided or controlled, directly or indirectly, by persons, even where other parts of the arrangement are designed in a decentralised manner.⁴

Two opposing corrections follow from this: a centrally operated front end does not automatically pull the entire underlying protocol into the scope of the Regulation. Conversely, the decentralisation of autonomous smart contracts does not shield a separately controlled API, order book, routing or access layer. Each function and each layer must be attributed separately.

III. Three Front-End Archetypes

1. Purely Informational Interface

The first archetype retrieves public on-chain data and displays, for instance, pool statistics, prices or trading volumes, without preparing transactions, giving personalised recommendations, or receiving or forwarding orders. Such a pure analytics function regularly does not meet any of the definitions in Article 3(1)(16) MiCA.

The qualification is important: as soon as the interface issues user-specific recommendations, prepares concrete transactions or opens an executable order flow, the product as a whole can no longer be treated as a "mere display". The individual module is decisive.

2. Self-Custodial Transaction Preparation

With the second archetype, the front end computes a route, generates calldata and hands an as yet unsigned transaction to the wallet. The user reviews and signs it and sends it – depending on the set-up via an RPC endpoint of their own choice or a pre-configured one – to a router or pool contract.

The user's signature is a weighty indicator against execution by the front-end operator, but not an automatic exclusion. What is decisive is whether the operator itself concludes an agreement on behalf of the client or in fact controls the execution. Factors weighing against execution include, in particular, that the user can freely reject or modify the transaction and dispatch it via infrastructure of their own choosing, and that the operator no longer intervenes in the process after handing over the calldata.

With respect to reception and transmission, the position remains open. Indicators in favour of a service include the receipt of an already binding instruction, an operator-run relayer or RPC, gas sponsoring, automated forwarding, subsequent parameterisation, or the ability to reject transactions. Weighing against it is a purely local, non-custodial process in which the user merely receives non-binding calculations and transmits to an autonomous contract themselves. This archetype is therefore not a uniform safe harbour, but a genuine grey area.

3. Intent and Order-Relay Architecture

With the third archetype, the user signs an order or intent off-chain. A separate infrastructure receives the signed message, validates it, stores it where applicable and makes it available to fillers, resolvers or solvers for execution. The third party then executes the transaction on-chain and frequently bears the network costs.

Such an architecture approaches the definition of reception and transmission considerably more closely than mere calldata generation. Nevertheless, a proper subsumption remains necessary here too: who receives the order? On whose behalf is action taken? To which third party is it transmitted? What role does the operator play in validation, auction, selection, parameterisation and settlement? The wording of Article 3(1)(23) and the open reach of Article 80 MiCA justify a high risk assessment, but not yet a blanket equation of every intent protocol with an intermediary requiring authorisation.

A trading platform additionally comes into consideration where multiple third-party interests interact within a system managed by the operator under predefined rules and contracts result from that interaction. Resting orders increase the proximity to a trading system, but are not decisive on their own. Particularly relevant are cross-order matching, batch auctions, binding RFQs, access rules for executing parties and the question of whether the system itself determines which interests contract with one another.

IV. Application to Prevailing Market Architectures

The following assessments relate to the transaction paths documented as of August 2026. Product names must not be equated with a uniform supervisory function; routing logic and back-end components may change.

1. Analytics and Explore Views

Pure analytics modules at Uniswap as well as pure dashboard functions of DeFiLlama or DeBank correspond to the first archetype, insofar as they exclusively display public data. This says nothing about other functions of the same offerings, such as swap, bridge, wallet or recommendation modules.

2. Classic Pool and Aggregator Routes

A classic Uniswap pool swap or a 1inch Classic swap may correspond to the second archetype where the front end merely generates the route and transaction data, the user signs and pays for the on-chain transaction themselves, and forwarding is not taken over by the front-end operator. For 1inch, the current product documentation expressly distinguishes between the user-funded Classic mode and the resolver-executed Fusion mode.⁵

For the legal assessment, however, the label "Classic" is not sufficient. What must be examined are, in particular, the RPC used, a possible transaction relay, smart-wallet delegations, gas abstraction and the question of whether the back end supplements parameters or controls execution after the user's signature.

3. UniswapX and Uniswap Limit Orders

With UniswapX, the user signs a Permit2-based order which is transmitted to a filler infrastructure and executed on-chain by third parties. According to the product documentation, the current limit order function of the Uniswap interface likewise uses the UniswapX network and publishes orders to an open network of third-party fillers. The current Uniswap documentation distinguishes an access-restricted quoter role from a technically open filler role. In the RFQ process, a Uniswap back end first obtains quotes, the user signs the order, after which a further "hard" RFQ phase may take place; the finalised order is then passed to the filler network. The publicly documented UniswapX order service validates, stores and distributes signed orders.⁶

These features give rise to a considerable risk of reception and transmission of orders at the level of the respectively controlled back-end services. The technically open filler role does not eliminate that risk. It does show, however, that the assessment must not rest on the inaccurate assumption of a generally closed filler set; rather, the legal and factual operator attribution of each back-end component must be established separately. Nor is the trading platform definition met merely because orders are stored or several fillers compete for execution. What remains required is the multilateral bringing together of third-party buying and selling interests under the rules of the system, resulting in a contract.

4. CoW Protocol

With CoW Protocol, the proximity to the third archetype is particularly pronounced. According to the technical documentation, the order book is the central API for users and integrations. It creates quotes, validates signed orders, may reject invalid orders and stores accepted orders in a database. An autopilot forms auctions from these; independent solvers compete for settlement solutions. Opposing user interests can be taken into account directly within a batch solution as a "coincidence of wants".⁷

There are accordingly weighty arguments in favour of reception and transmission of orders. The trading platform question also arises more sharply here than with a mere single-order relay, because multiple user orders are processed jointly and can potentially be matched against one another. It nevertheless remains to be clarified who in fact and in law manages the order book, the autopilot, solver access and the rulebook. A reference to a DAO or to open-source code does not replace this operator analysis; equally, no particular legal entity may be presumed to be the service provider without it.

5. 1inch Fusion

With 1inch Fusion, the user signs an order; resolvers registered or admitted at protocol level compete in a Dutch auction for its execution and, as a rule, bear the on-chain gas costs. The current 1inch documentation describes resolvers as addresses admitted and registered at protocol level with staking requirements, and expressly distinguishes Fusion from the Classic swap, in which the user executes the transaction and pays gas themselves.⁵

Here too, the authorisation risk lies primarily in the infrastructure that receives orders, distributes them and organises resolver access. Whether 1inch itself, an API provider, another group company or a further entity provides the respective function must be determined on the basis of the actual operational and contractual structure. The label "resolver model" does not answer the attribution question.

V. Attribution, Terms of Service and Decentralisation

Contractual self-descriptions are neither meaningless nor decisive. A sentence such as "we merely provide an interface" cannot do away with the actual function. Conversely, a broadly drafted product description alone does not prove that the legal entity concerned itself provides every technical service. Terms of service, API terms, fee models, participant rules, technical documentation and actual operations must be evaluated together. Current Uniswap Labs terms designate the hosted interface and further services as their own "Products"; the API terms provide, among other things, for revocable access as well as powers to modify, restrict and suspend. Such provisions are relevant indicators of control, but no conclusive supervisory subsumption.⁶

Five questions are particularly helpful for the attribution analysis:

1. Who receives, validates and stores the signed order or transaction?
2. Who determines routing, auction mechanism, order parameters and settlement path?
3. Who sets the access of quoters, fillers, resolvers or solvers and can withdraw it?
4. Who can reject, withhold, block, prioritise or remove orders from the system?
5. Who operates and monetises the API, relayer, order book, autopilot, indexer or the RPC essential to the process?

The more of these functions converge in one identifiable entity, the weaker the argument becomes that the service is provided in a fully decentralised manner without any intermediary.

The attribution to a DAO must likewise be treated in a differentiated manner. A DAO is not an "other undertaking" within the meaning of MiCA merely by virtue of its label; but neither is it automatically beyond any attribution. What matters are the degree of organisation, economic activity, permanence, governance rights, operational control and the possibility of assigning concrete service functions to a legal entity or a sufficiently organised unit. Merely relocating a responsibility into governance documents does not decentralise the actual function.

dYdX Chain may serve as a technical counter-example: there, validators and full nodes hold local in-memory order books; the respective block proposer generates matches for the next block. This demonstrates that an order book and matching can be organised without a single central order book server. It does not follow, however, that the entire service is automatically fully decentralised. Validators, indexers, front-end and API operators may continue to perform identifiable functions. Moreover, dYdX primarily trades perpetual products; before any MiCA assessment, it must therefore first be examined whether the instruments traded qualify as financial instruments and are excluded under Article 2(4)(a) MiCA.⁸

VI. Practical Consequences

Operators should not classify the brand or the protocol as a whole, but document each concrete transaction path. A robust review comprises at least: the legal qualification of the assets traded; the EU nexus; the legal entities and technical operators involved; the path from user input, signature and order through to settlement; all rejection, access and control rights; the mapping onto the service definitions; and the professional and economic embedding of the activity.

If this analysis reveals a service requiring authorisation, mere disclaimers or a renaming of the function will not suffice. Depending on the business model, the options include obtaining authorisation, the complete transfer of the function requiring authorisation to an authorised provider, genuine organisational and technical decentralisation, or the effective discontinuation of the service in the EU market. Decentralisation, too, must be functionally effective: open source, forkability and DAO governance are not sufficient as long as an identifiable entity controls the productive order flow.

VII. Conclusion

The architecture of a DeFi front end is central to the MiCA assessment, but not decisive on its own. MiCA attaches to persons, professional activities, client relationships and specifically defined services. A purely informational interface regularly remains outside the authorisation regime. A self-custodial swap with local transaction preparation is a borderline case whose assessment depends on relay, RPC, gas and control functions. With intent and order-relay models involving controlled reception, validation, storage and distribution of signed orders, the risk of reception and transmission requiring authorisation is considerably higher.

Even there, however: an order book is not automatically a trading platform, a user signature does not automatically rule out execution, and a DAO or DeFi label does not replace an attribution analysis. What is decisive is who actually provides and controls which function. It is precisely this function and operator analysis that should be documented before product launch, upon every material change to the architecture and before addressing the EU market.

This article provides a general supervisory analysis and does not replace a review of the specific product and its actual operational structure.

‍