In recent years, the global crypto-legal landscape has evolved at an unprecedented pace. An increasing number of jurisdictions, including those traditionally viewed as offshore, are actively developing regulatory frameworks to bring crypto assets and related services into a more predictable and regulated environment. In this article, we focus on Markets in Crypto-Assets Regulation (widely known as MiCA).

This landmark regulation seeks to establish a harmonised framework for crypto asset services across the EU. MICA’s key implications for crypto businesses have been recently explored in an article by Illia Shenheliia, Aurum’s associate partner.

For DeFi teams, however, one passage tends to attract immediate attention: Recital 22, which indicates that MiCA should not apply to crypto-asset services provided “in a fully decentralised manner without any intermediary.” However, what this standard means in practice – and where regulators are likely to draw the line – is not straightforward.

Below, we unpack how “full decentralisation” is typically assessed across technical, governance, and operational layers, and what DeFi projects can do to evaluate (and, where needed, strengthen) their decentralisation in substance.

Why Recital 22 Is Not a Safe Harbour by Default

Many DeFi projects breathe a sigh of relief when they reach Recital 22 of MiCA – the passage suggesting that crypto-asset services provided “in a fully decentralised manner without any intermediary” fall outside the regulation’s scope. It is easy to read this as a DeFi safe harbour.

In practice, however, Recital 22 is not a free pass for anything labelled “decentralised”. The real question is not what a project calls itself, but whether – across the full lifecycle of the service – control and decision-making are genuinely distributed, or can still be attributed to a core team, a foundation, or another identifiable operator. That assessment is rarely binary, and most protocols sit somewhere on a spectrum.

Moreover, although Recital 22 is often read as a DeFi carve-out, it also highlights a countervailing risk. MiCA may still apply where only parts of a service are decentralised. The exemption is narrow and hinges on the service being provided in a fully decentralised manner, without any intermediary at all.

This is why the key question under MiCA’s Recital 22 exemption is not “are smart contracts deployed on a permissionless chain?”, but who can still change outcomes: who controls admin keys and upgrades, who can pause or reroute activity, who sets parameters, and whether the user interface becomes a practical gateway. Below, we break this down layer by layer to show where regulators are likely to draw the line when evaluating whether a DeFi service is truly “fully decentralised” in substance.

What Is DeFi (and Why Labels Don’t Decide Regulatory Scope)

Although there is no universally accepted definition of Decentralised Finance (DeFi), it is commonly understood as a non-custodial financial ecosystem that operates in a decentralised way using distributed ledger technology (DLT) to offer financial services. DeFi is designed to function without central intermediaries or authorities, allowing users to retain full control and ownership of their assets at all times.

At the same time, DeFi is not entirely new in terms of what it offers. If we look beyond the technology, many DeFi products closely resemble traditional financial services. Platforms for lending, borrowing, and trading, for example, perform functions that are familiar from conventional financial markets. The real difference lies in how these services are delivered: through automated, self-executing protocols and smart contracts rather than any central intermediaries.

Take trading as an example. In traditional finance, buying or selling assets usually happens on regulated exchanges and often through brokers. In DeFi, trading takes place directly between users, typically through decentralised platforms such as Uniswap, with assets exchanged straight from users’ wallets. The entire process is governed by automated smart contracts, removing the need for brokers or central operators.

Is Your Product Truly “Fully Decentralised”? A Layer-by-Layer Control Test

Regulators tend to assess decentralisation as a control question across several layers. Not every business model marketed as DeFi is truly or sufficiently decentralised. It is therefore essential to look at substance over form and assess each product on a case-by-case basis – an approach commonly taken by supervisory authorities and regulators. In practice, many DeFi projects appear highly centralised during their early, bootstrapping phase and only become progressively more decentralised as they are deployed, scaled, and opened to the public.

When assessing a project’s level of decentralisation, several key factors are typically considered, including:

Settlement Layer: Does the Underlying Network Support Decentralised Execution?

The level of decentralisation of the settlement layer on which a project deploys its smart contracts is essential. A blockchain can be considered decentralised when it operates on a permissionless and sufficiently distributed network of nodes that collectively store, share, and update the copy of the same ledger. Unrestricted access to node participation is essential, as it allows a broad and diverse set of participants to support the network, reinforcing its decentralised nature.

Architecture Layer: Who Can Pause, Upgrade, or Reroute the Protocol?

DeFi products run on smart contracts, which are essentially pieces of code stored on a blockchain that automatically enforce predefined terms once certain conditions are met. While these contracts are typically deployed on decentralised networks and inherit certain of their features, their use alone does not make a project decentralised.

For a project to be truly decentralised, no single person or organisation should be able to control access to its smart contracts, change how they work, or stop them from operating after deployment. In practice, however, many projects retain certain administrative keys or similar mechanisms, which, even if only in theory, may allow their team to pause transactions, adjust parameters, or reroute liquidity, often justified as emergency safeguards for user protection. However, no matter how good the intentions, such control weakens decentralisation and raises questions about how independent the system really is.

That said, smart contract upgradability is often necessary to adapt to changing market or network conditions and to remain competitive in the DeFi ecosystem. It should not automatically be viewed as a sign of centralisation. The issue is not upgradability itself, but who controls it. When upgrade powers are concentrated in the hands of a few team members, they can undermine decentralisation. By contrast, when upgrades are governed through a decentralised structure, such as a decentralised autonomous organisation (DAO), the project is more likely to preserve a genuinely decentralised character.

Governance Layer: Is Decision-Making Genuinely Distributed or Still Attributable?

Decentralisation at the governance level is most clearly expressed through DAOs. A DAO emerges when a wide and diverse group of participants collectively decides how a project should evolve, rather than relying on a core project team. DAOs usually operate through a crypto asset known as a governance token. This token represents voting power, allowing participants to actively influence key decisions and shape the project’s future in a transparent and measurable way.

That said, the mere existence of a DAO does not guarantee a project’s decentralisation. What truly matters is the scope of authority granted to DAO members and how governance tokens, i.e. voting power, are distributed among them.

For decentralisation to be meaningful, key decisions about a project, including its technical infrastructure, development roadmap, and upgrades, must be genuinely made by the DAO through transparent governance processes that are easy for all members to understand and participate in. When DAO governance becomes a mere formality that rubber-stamps decisions already made by a small group, or when only minor issues are subject to DAO approval while real control remains with a core team, the project’s decentralisation rightly comes into question.

In practice, many DAOs also need a DAO-adjacent legal entity to enter into legal, commercial, and business relationships with partners, contributors and other service providers. To preserve decentralisation, this entity must be carefully structured. It should act solely on the DAO’s instructions, exercise only the powers granted by the DAO, and remain fully accountable to the DAO members. At AURUM, we are always happy to help projects establish DAOs and design governance frameworks that support genuine decentralisation while enabling real-world operations. You can learn more about DAO legal structuring in our DAO 3.0: The Harmony Framework.

The distribution of governance tokens is also critical. When voting power is concentrated in the hands of one or a few holders, it can undermine decentralisation. That said, each situation must be assessed on a case-by-case basis. For example, a holder may be considered significant if they can meet quorum alone or consistently influence governance outcomes. By contrast, a project may still be decentralised when a small group of active voters shapes decisions due to wider voter inactivity, provided they do not control a substantial share of the total token supply.

User Interface Layer: Is the Front-End Becoming the Real Intermediary?

On permissionless blockchains, anyone can directly interact with smart contracts. However, doing so often requires advanced technical knowledge that most users do not possess. For this reason, Web3 projects typically provide user-friendly, web-based interfaces that allow users to access and interact with smart contracts more easily.

To support decentralisation, it is essential that project interfaces do not introduce elements of centralisation. Interfaces should be clearly separate from the underlying protocol or smart contracts, and should not be the only way to interact with them. Instead, they should be just one of many possible access points, including interfaces that may be developed and operated by third parties.

Ideally, an interface’s role should be limited to preparing call data based on the user’s selected parameters and desired actions, displaying that data for user signature and further broadcasting. It should not hold, manage, or safeguard user assets, nor influence how transactions are executed. When an interface or its operator takes part in transactions, influences their outcome, or temporarily controls user assets before they reach the smart contracts, this can introduce centralisation risks and may trigger regulated activities.

Decentralisation under MiCA: Two Conditions That Don’t Always Travel Together

Although MiCA explicitly states that it does not apply to crypto asset services provided “in a fully decentralised manner without any intermediary”, the regulation offers no definition of what “fully decentralised” actually entails. Likewise, EU authorities have not yet issued clear guidance on how this concept should be interpreted in practice.

“Fully Decentralised” vs “Without an Intermediary”: Why the Difference Matters

If interpreted literally, two conditions must be met at the same time for a service or product to fall outside MiCA’s scope: (1) full decentralisation, and (2) the absence of any intermediary. That said, these conditions are not interchangeable, and one does not automatically imply the other. The European Parliament supports this distinction in its report, noting that the absence of intermediaries is not a prerequisite for decentralisation ​​as it involves the distribution of control and decision-making, whereas disintermediation focuses on the removal of intermediaries. Instead, disintermediation may simply occur as a consequence of decentralisation as the need for central intermediaries diminishes.

When Intermediaries Still Exist: SICIs and DeFi’s “Systemic” Reality

In practice, as the European Parliament has rightly noted, certain DeFi ecosystems may rely on essential intermediaries known as Systemically Important Crypto Intermediaries (SICIs). This concept refers to legal entities or protocols that, despite the decentralisation ethos, have grown so large and interconnected that their failure could endanger the stability of the wider crypto ecosystem and, potentially, even traditional financial markets. For example, some DeFi platforms facilitate direct peer-to-peer lending or borrowing; others pool user funds to provide liquidity; and in some models, transactions are recorded on an intermediary’s balance sheet. These actors play a crucial role in the functioning and resilience of DeFi systems, demonstrating that complete disintermediation is neither always feasible nor necessarily desirable.

This is why MiCA’s requirement to satisfy both conditions – full decentralisation and the absence of intermediaries – may create practical uncertainty for DeFi projects trying to determine whether they fall within the regulation’s scope.

Regulatory Signals You Can Use Today: A Practical Benchmark for DeFi Teams

In our view, until clearer guidance emerges on when DeFi projects are sufficiently decentralised to fall outside the scope of MiCA, the prudent approach is to follow commonly recognised aspects of technical and operational decentralisation, as outlined in this article. This view is supported not only by theory, but also by regulatory practice, such as the approach of the Danish Financial Supervisory Authority (FSA), which has articulated its principles for assessing decentralisation in the markets for crypto-assets. According to this document, the Danish FSA’s assessment of decentralisation is two-fold:

Danish FSA Approach: Technical Decentralisation

The Danish FSA first examines whether a regulated activity is provided exclusively through smart contracts that cannot be said to be controlled by a legal entity. This includes assessing whether the smart contracts are genuinely self-executing and autonomous, and whether they embed rights that allow control over the activity. The regulator also considers whether the underlying DLT system is sufficiently distributed or decentralised, whether any access mechanisms exist enabling control over the activity, and whether decision-making power is concentrated in the hands of specific actors.

Danish FSA Approach: Decentralised Governance and Attribution of Control

If the technical provision of the regulated activity is not considered decentralised, the Danish FSA then assesses whether managerial control over its offer can be attributed to a legal entity. In this context, the regulator looks at whether the persons behind the offer constitute a legal entity, whether the structure and distribution of governance tokens indicate centralisation, and whether any legal entities hold decision-making powers that effectively allow them to control the offer of such activity.

Key Takeaways: Decentralisation Is Evidence of Real Control Distribution

• “Fully decentralised” under MiCA is not a label – it’s a control analysis. The practical question is whether decision-making and operational power can still be attributed to a core team or legal entity.
• Deploying smart contracts on a permissionless blockchain is only the starting point. Regulators are likely to assess who can still influence outcomes after deployment, not just where the code lives.
• Admin keys and emergency powers are centralisation signals. The ability to pause transactions, change parameters, reroute liquidity, or intervene in execution weakens “full decentralisation” – even if intended for user protection.
• Upgradability is not the problem; concentrated upgrade control is. Upgrade mechanisms can be compatible with decentralisation if changes are governed through transparent, genuinely distributed governance rather than a small operator group.
• A DAO does not automatically mean decentralised governance. What matters is the DAO’s real authority (over upgrades and core parameters) and whether voting power is sufficiently distributed rather than concentrated.
• Token distribution and quorum dynamics matter as much as the token cap table. A single holder (or coordinated group) that can meet quorum or consistently determine outcomes will look like control – even if governance is “on-chain”.
• User access can reintroduce an intermediary through the interface layer. If a single “official” front-end is the only practical access point, or if the interface can gate, filter, or influence transactions, it becomes a real control surface.
• The safest approach today is to evidence decentralisation across the stack. Document who controls keys and upgrades, how governance passes in practice, and whether there are credible alternative access routes to the protocol.

In Conclusion

While MiCA does not define what it means to be “fully decentralised”, the EU is already laying the groundwork for future DeFi policy through MiCA’s reporting and review mechanisms. This includes the EBA–ESMA Joint Report on DeFi and related crypto-asset market developments, published on January 16, 2025. The direction of travel is clear: decentralisation is likely to be assessed as a question of control and attribution, not of narrative or self-description.

A DeFi project can look decentralised on the surface while still retaining decisive control points – through admin keys, upgrade authority, emergency stops, concentrated voting power, or a single “official” interface that becomes a practical gatekeeper. Those design choices may be sensible for security and usability, but they also make it harder to argue that the service is provided fully decentralised and without an intermediary in substance.

For that reason, the most defensible approach today is to treat decentralisation as something you can evidence. Document who can change parameters, who can pause or upgrade contracts, how governance decisions pass in practice (not just in theory), and whether users have credible alternative routes to access the protocol beyond the project’s primary interface. Until EU guidance becomes more explicit, teams that proactively map and reduce attributable control – across the settlement, architecture, governance, and interface layers – will be best positioned to manage MiCA scope risk and adapt smoothly as supervisory expectations mature.