Study: “We Are DeFi, So MiCA Does Not Apply to Us”. EBA and ESMA Disagree.

Key Findings

• MiCA’s fully decentralised exemption in Recital 22 applies only when no single entity controls protocol parameters, governance mechanisms, or core infrastructure, and users access a common good resource rather than a designated service provider;
• Decentralization is not binary. ESMA treats it as a spectrum, and even ostensibly decentralized protocols typically have identifiable entities exercising control over governance, upgrades, and fee structures;
• The test is functional, not technological. Regulators ask what control the operator actually exercises, not what technology the system is built upon;
• Software developers are not automatically CASPs. But developers who retain sufficient influence over the crypto-assets, the platform, or ongoing business relationships with users cross the regulatory threshold.

The Myth: MiCA Doesn’t Affect DeFi

Recital 22 of MiCA states that services provided in a fully decentralised manner without any intermediary fall outside the regulation’s scope. Many DeFi teams read this and stop there.

The problem is that the Regulation never defines fully decentralised in its operative provisions. The term appears only in the preamble. Two conditions can be distilled from Recital 22 and subsequent regulatory guidance:

• No single entity may exercise control over protocol parameters, governance mechanisms, or core technological infrastructure;
• Users must access what amounts to a common good resource, not purchase services from a designated provider with whom a contractual relationship exists.

Achieving both conditions simultaneously is far harder than most teams assume.

Why Full Decentralization Is Exceptionally Rare in Practice

Before any legal work begins, a lawyer assessing a DeFi project will analyze the project’s layers, their state of decentralization, and the team’s plans on ownership and governance. The initial assessment frequently reveals that what the team considers fully decentralized is not.

To satisfy the exemption, all elements of the project must meet the criteria of full autonomy and lack of internal or external influence across governance, ownership, and interfaces. Very few projects achieve this.

A recent example makes this concrete. On 21 April 2026, Arbitrum’s Security Council froze over 30 ETH (approximately USD 71M) associated with the Kelp DAO exploit. A 12-member governing body moved funds into an intermediary wallet, locking them pending a governance vote. Arbitrum is, by definition, a permissionless layer-2 network. But the exercise of discretionary control over user assets is precisely what fails MiCA’s full decentralization test. The permissionlessness of the underlying ledger did not change that outcome.

The regulatory lesson: substance-over-form determines scope. A simple claim of decentralization is not sufficient to rule out CASP authorization obligations.

What ESMA and EBA Actually Say

ESMA’s Second Consultation Package proposed a definition of permissionless distributed ledger technology as a technology where no entity controls the distributed ledger or its use, and nodes can be set up by anyone meeting technical requirements. This definition draws from the Financial Stability Board’s framework, which distinguishes between permissionless (fully decentralized) DLT, permissioned DLT allowing a degree of centralization, and centralized platforms.

ESMA acknowledges that the exact scope of this exemption remains uncertain and considers that each system must be assessed on a case-by-case basis.

The Joint Report with EBA published on 13 January 2025 (ESMA75-453128700-1391 / EBA/Rep/2025/01), prepared pursuant to Article 142 of MiCA, provides the clearest empirical picture. DeFi represents approximately four percent of the global crypto-asset market capitalization. The Report confirms that very few DeFi systems achieve truly full decentralization as contemplated by Recital 22. Even ostensibly decentralized protocols typically have identifiable entities exercising varying degrees of control over governance, protocol upgrades, smart contract deployment, and fee structures.

On software developers specifically, entities merely creating and selling software tools for crypto-asset services are not automatically CASPs. However, entities that retain control or sufficient influence over the software, protocol, platform, or business relationships with users may be deemed CASPs. The critical test is control and influence, not technological involvement.

The same Joint Report addresses ML/TF risks and ICT considerations. The absence of AML/CFT controls in purely decentralized systems presents significant regulatory concerns. ICT risks are identified as primary concerns, with a majority of DeFi-related financial losses attributable to smart contract vulnerabilities, oracle manipulation, and MEV exploitation. These factors inform the supervisory approach to entities operating at various points on the decentralization spectrum.

The FATF Foundation and What Contractual Relationships Reveal

ESMA’s framework builds directly on FATF’s Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs (October 2021). The FATF position: a person who creates or sells a software application may not constitute a VASP when solely engaging in its creation or sale, with emphasis on solely.

Where creators, owners, or operators maintain control or exert sufficient influence over DeFi arrangements, they may fall under the VASP definition regardless of how decentralized the arrangement appears. Two principles follow:

• Owners and operators can often be identified by their relationship to the activities being undertaken, not by the labels applied;
• Partial centralization cannot be excluded simply because portions of the process are automated through smart contracts.

ESMA’s analysis of Article 73 of MiCA, which governs outsourcing to third parties, adds another dimension. There is no legal basis to categorize permissionless DLTs used by CASPs as third-party providers, because no formal contractual relationship is required to interact with permissionless blockchains. Permissionless DLTs are therefore regarded as common good resources. Permissioned DLTs operated by commercial enterprises, by contrast, typically involve formal contracts and constitute a third-party provider relationship.

The consequence for platform operators: deploying smart contracts on a permissionless blockchain like Ethereum does not, in itself, establish a third-party service relationship. But if the operator retains control over those smart contracts, can upgrade or modify their functionality, controls the front-end interface, or maintains administrative keys that can pause, freeze, or modify the protocol, those centralized elements bring the operator within MiCA’s scope. The permissionless nature of the underlying ledger does not change this.

Key Takeaways

• The Fully Decentralised Exemption Is Exceptionally Narrow. If any single entity exercises control over governance, protocol parameters, or core infrastructure, the exemption does not apply;
• Substance Over Form Dictates Compliance. Regulators assess what control the operator actually exercises. Administrative keys, front-end control, and upgrade capability all bring an operator within MiCA’s scope, regardless of the underlying technology;
• Decentralization Is a Spectrum. ESMA does not treat decentralization as binary. The presence of identifiable entities exercising control over fee structures, protocol upgrades, or governance triggers regulatory scrutiny, even in heavily automated systems;
• Permissionless Blockchains Are Common Goods, But That Does Not Shield Operators. ESMA categorizes permissionless DLTs as common good resources under Article 73. Deploying on a permissionless chain does not shield a platform operator who retains functional control over deployed contracts;
• Software Developers Are Not Automatically CASPs. Creating and selling non-custodial software does not automatically classify an entity as a CASP. Retaining sufficient influence over the crypto-assets, the platform, or ongoing user relationships does.