Disclaimer: This article is for informational purposes only and does not constitute legal advice. I am a contributor of Kleros, and some references to Kleros are included in this article. These mentions are not intended as promotional content but as part of the discussion of decentralized governance mechanisms.

The Decentralization Dilemma

We are mere days away from the entry into application of Titles I, II, V, VI, and VII of the European Union’s Markets in Crypto-Assets Regulation (MiCA). This landmark regulatory framework aims to provide clarity and structure to the crypto industry, but it also raises critical questions about the meaning of decentralization. Specifically, Recital 22 of MiCA introduces a distinction that could shape the future of blockchain-based projects:

“This 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. This Regulation covers the rights and obligations of issuers of crypto-assets, offerors, persons seeking admission to trading of crypto-assets and crypto-asset service providers. Where crypto-assets have no identifiable issuer, they should not fall within the scope of Title II, III or IV of this Regulation. Crypto-asset service providers providing services in respect of such crypto-assets should, however, be covered by this Regulation.”

This statement reveals a key issue with MiCA’s approach: what does “fully decentralized” actually mean? The regulation sets up a binary choice: either a service is fully decentralized and falls outside MiCA’s scope, or it isn’t. Even minor deviations could lead to non-compliance, leaving developers and participants at risk of significant fines or criminal penalties. This binary framing creates a regulatory environment where decentralization is treated as an all-or-nothing standard, one that most projects will struggle to meet.

According to regulatory status, builders face two divergent paths. The first is the “easy road”: adopt a centralized structure, operate as a CASP under MiCA, provide regulated crypto-asset services and become more of the same things we know and what blockchain originally tried to change. The second is the “high road”: striving for full decentralization, but facing the risk of falling short and being subject to penalties. The need for clear guidelines is now more pressing than ever.

The reality is that “full decentralization” is closer to a myth than a practical standard. It is not only improbable but perhaps unattainable. A blockchain protocol, no matter how robust, relies at some point on some centralized human or technical input. We must assume that the EU did not pass a law with an impossible mandate and that “full decentralization” under MiCA is achievable. The real question is how this can be accomplished.

The Danish Approach

The Danish Financial Supervisory Authority (FSA) has already weighed in on this debate in their paper “Principles for the assessment of decentralisation in the markets for crypto-assets”, offering some guidance to evaluate decentralization. The Danish FSA cautions that projects claiming to operate “entirely decentralized” must tread carefully. Misclassifying a service could result in severe consequences. Moreover, the key insight from this paper is that the Danish FSA understands “…the provider of the interface to be an order executor if the provider makes available to the user the software that converts the user’s trading interests into an order entry on the DEX. Because the limited liability company has control of this software, the company also enters into an agreement with the user that the user can use the company’s service to place orders on a DEX”.

Applying this criteria, if an interface provider enables users to convert trading interests into order execution on a decentralized exchange (DEX), that provider is effectively performing a regulated activity. Therefore, a “fully decentralized” infrastructure and application layer would be possible, but would render almost all front-end operators as CASPs, of course as long as they provide access to a service classified as a crypto-assets service under MiCA. This is only a paper and it’s not to be said the general criteria of other National Competent Authorities authorities in the EU, or ESMA itself, but it’s a troubling opinion since front-end developers may find themselves subject to MiCA’s requirements simply for building interfaces that facilitate access to decentralized systems. The need for trully decentralized user interfaces has therefore never been more pressing.

What is the meaning of decentralization in the US?

In the United States, the concept of decentralization has been a subject of ongoing debate in the regulatory scene, especially in relation to how “sufficient decentralization” could determine whether a crypto token qualifies as a security or not.

More recently, the Financial Innovation and Technology for the 21st Century bill (FIT21) emerged, outlining a framework for evaluating digital assets. Under FIT21, an asset’s classification as a digital commodity or security ultimately relies on its level of decentralization. The bill requires that the asset be submitted to the SEC for certification to assess whether it meets the criteria for being sufficiently decentralized and operational. While there are significant concerns about FIT21’s regulatory approach, particularly its potential to fragment the market by classifying assets as either securities or commodities, one notable aspect is its more specific treatment of decentralization. Unlike MiCA, FIT21 takes a deeper dive into decentralization, introducing definitions that could function as a Decentralization Test:

Decentralization Test Based on FIT21 Definitions

1. No Centralized Control Over Functionality: The blockchain system should not have been under unilateral control or subject to significant changes in functionality by any person in the previous 12 months. No individual should have the authority to alter the blockchain’s core operations.

2. Open Access to the Blockchain System: Over the past 12 months, no person should have had the unilateral authority to restrict others from using, earning, transmitting the digital asset, deploying software, participating in governance, or operating nodes within the blockchain system.

3. Limited Ownership by Issuer or Affiliates: In the past 12 months, the digital asset issuer or affiliates should not have owned 20% or more of the total available units of the digital asset or the voting power in the system. This ensures that no single party dominates the blockchain’s governance.

4. No Centralized Source Code Control: Over the last 3 months, neither the issuer nor its affiliates should have made significant contributions to the blockchain’s source code that alter its functionality, unless such changes were technical (e.g., fixing vulnerabilities or cybersecurity risks) or were adopted through a decentralized governance process.

5. No Investment Marketing: In the last 3 months, the digital asset issuer or affiliates should not have marketed the asset to the public as an investment. This prevents the asset from being treated as a speculative investment opportunity.

6. Equitable Distribution of Digital Assets: Over the past 12 months, all digital asset issuances through the blockchain’s programmatic functioning must have been distributed to end users in an equitable, non-discretionary manner, such as through rewards for activities like mining, staking, or other blockchain-related tasks.

It’s fair to say that the political landscape shifted with Donald Trump’s victory in the presidency, and as a result, the fate of this law is now uncertain. While FIT21 has gained attention, it is still unclear whether it will be approved in its current form.

Moving Toward Decentralization: What We Can Do Now

While the concept of full decentralization remains ambiguous and the need for clear standards is more pressing than ever, drawing from the references above, there are steps that builders can take to achieve a fair level of decentralization.

For the purpose of this paper, I won’t dive into decentralization at the settlement or architecture layer (how decentralized is the blockchain you’re building on? or how decentralized are the components upon which your DApp relies?) Instead, I’ll focus more on the governance layer: how decentralized is decision-making, and how are those decisions actually enforced?

Minimizing Control

“Power tends to corrupt, and absolute power corrupts absolutely”. Sometimes, power tends to concentrate in the hands of a few, even in systems designed to distribute it broadly. Without mechanisms to counterbalance this tendency, decision-making and influence can become centralized over time, undermining the very principles of decentralization. That’s why from day one it’s important to have mechanisms in place that prevent this from happening.

To minimize control and automate processes whenever possible, it is essential to distinguish between immutable smart contracts and those that can be modified or controlled by third parties. Immutable smart contracts are designed to remain unchanged once deployed, ensuring that the logic they contain cannot be altered. In contrast, upgradable contracts may include functions that allow certain actions or parameters to be updated by a designated party, potentially undermining the contract’s autonomy.

A recent ruling on Tornado Cash further emphasizes the importance of immutability in decentralized systems. On November 26, 2024, the U.S. Court of Appeals for the Fifth Circuit ruled that the Treasury Department’s Office of Foreign Assets Control (OFAC) had overreached by sanctioning Tornado Cash’s immutable smart contracts. The case, Van Loon et al. v. Department of the Treasury, centered on whether these smart contracts could be classified as “property” under the International Emergency Economic Powers Act (IEEPA). The court determined that immutable smart contracts could not be considered property because they cannot be controlled or altered by any individual or entity, and therefore they cannot be owned. This ruling challenges the application of sanctions to decentralized systems, as it reinforces that immutable contracts, by their nature, are resistant to manipulation or external control.

When smart contracts are immutable, they function without the risk of being modified by a central authority, aligning with the core principles of decentralization. On the other hand, modifiable smart contracts introduce a level of control that can compromise the system’s autonomy and undermine the goal of decentralization.

However, sometimes having immutable smart contracts is not viable for a project and some level of governance is necessary, then control over the protocol should be as decentralized as possible. One key aspect of decentralization is ensuring that control over a protocol’s smart contract keys is as distributed as possible, rather than being concentrated in the hands of a few signers, typically the project’s founders. This issue was highlighted in the bZx DAO class action, where the United States District Court for the Southern District of California ruled that a successful phishing attack on a bZx developer, who held the sole key to upgrade a smart contract, allowed a hacker to access all user funds “rendering the distinction between custodial and non-custodial meaningless”. The court’s decision implies that if control over a protocol’s smart contract is concentrated among one or a few developers, it effectively becomes custodial, and thus, not truly decentralized. This highlights the need to remove signers from the process whenever possible and decentralize control of the smart contract to the token holders.

If on-chain voting isn’t used, it’s important to employ tools that allow removing signers and ensure the decentralized and trustless execution of proposals. Solutions like OSnap or Kleros SafeSnap can play a vital role by enabling proposals to be executed directly on-chain by any participant, without the need for centralized authority, thus maintaining the trustless and decentralized control of the protocol.

Voting power

Centralization can be mitigated by shifting control over smart contract upgradability from a small group of signers to governance token holders. However, the question arises: what if the tokens are concentrated in just a few hands? How many independent token holders are necessary to truly consider governance decentralized? Is it 10? 100? 1,000? For instance, in Wyoming’s legal framework for Decentralized Unincorporated Nonprofit Associations (DUNA), at least 100 token holders are required. However, the answer isn’t as simple as a number. Sometimes, even with a seemingly sufficient number of token holders, centralized control can still emerge in cases such as:

1. Voting Apathy: Voting apathy occurs when token holders do not to engage in the governance process whether for apathy or lack of incentives. This can lead to a concentration of decision-making power, as only a few active participants dominate voting. To counter this, it’s crucial to implement mechanisms that encourage participation. For instance, certain DAOs may choose to acknowledge community members, similar to the approach taken by Optimism with their Citizenship.

2. Collusion: Collusion happens when a group of token holders coordinate their votes to skew the results in their favor. This is particularly concerning in governance systems where a few participants control a large portion of the voting power. One way to mitigate this risk is through the use of minimal anti-collusion infrastructure (MACI).

3. Voting Censorship: Another concern in decentralized governance is the potential for voting censorship. In some cases, proposals are filtered or censored to prevent spam or malicious activities. However, these filtering mechanisms themselves can be prone to manipulation. To ensure true decentralization, it’s critical that these filtering processes are not controlled by any single entity or group of entities.

Concentrated ownership, particularly among the initial team or investors, can create a perception of control that undermines decentralization. For example, earlier this year, the SushiSwap team proposed a governance vote that was later approved, to transfer $40 million from the decentralized treasury to a centralized organization called Sushi Labs. However, there were accusations that the team used the protocol’s multisig wallet to vote for their own proposal. It was also claimed that the team took a short-term loan to increase their voting power during the vote, raising concerns about manipulation.

It’s not uncommon for entities formed by founders and elected by the DAO to take care of some management tasks to accumulate and maintain significant power (as seen in the recent Mantra DAO case). It’s essential to take steps to prevent such scenarios, ensuring they don’t erode the principles of decentralization.

Voting Rights and their impact in Decentralization

How can voting rights embedded in governance tokens impact decentralization? In their paper, the Danish Financial Supervisory Authority (FSA) notes that holders of governance tokens typically only exercise their decision-making powers by voting on proposals within a DAO or partnership, and it further emphasizes that when assessing decentralization, it’s essential to consider the rights attached to governance tokens in relation to the organization of token holders. If these rights allow decisions on critical aspects of regulated activities, like access to a service, this suggests a level of centralization.

This perspective creates a challenge for most token-governed DAOs, as very few could be deemed fully decentralized under such criteria. However, the final report issued by ESMA a few days ago states that “governance rights in blockchain protocols are distinct from corporate voting rights associated with traditional securities […] participation in protocol governance does not automatically equate to voting rights on corporate decision-making”

Despite this clarification, the precise impact of governance tokens and the participation of token holders on decentralization remains uncertain.

Enforcing Rules in a Trustless World

To mitigate the risks of centralization, ensuring a distributed token allocation and implementing a governance framework with clear rules that prevent entities from voting in situations where conflicts of interest arise are essential steps toward maintaining true decentralization. But equally important is the inclusion of robust checks and balances to ensure that governance rules are not only well-defined but also actively enforced. A practical example of such a framework is Q Protocol, an EVM-compatible blockchain designed for governance. It functions as a “digital jurisdiction” or “supreme court” where DAOs can establish their own constitutions and enforce their rules in a decentralized manner. If a management team violates a DAO’s constitution, the protocol allows any participant to escalate the matter to Q protocol’s root nodes, operated by individuals and institutions with specialized expertise located around the world, who play a critical role in interpreting rules and translating them into on-chain actions, such as implementing slashing mechanisms or exercising veto powers. This operational structure reinforces both the legitimacy and the decentralized integrity of the system.

Other arbitration systems, such as Kleros, Aragorn, and UMA, also provide mechanisms for resolving disputes and maintaining adherence to decentralized governance principles.

The Role of Token Distribution

Ensuring a fair and transparent token distribution from the outset is essential for maintaining decentralization in voting power. Concentrated ownership, especially among the initial team or investors, can create a perception of control that undermines the principles of decentralization. Therefore, projects must design token distribution mechanisms that emphasize long-term objectivity and inclusivity.

According to FIT21’s decentralization test, issuers should not have unilateral control over the blockchain system, and digital asset issuances must be distributed to end users in a equitable, non-discretionary manner, and end users must be able to participate in the ecosystem.

A decentralized system should ensure that participants are rewarded based on objective parameters. However, in reality, many projects are far from decentralized in terms of their sources of contributions and opportunities for participation. One potential solution is Retro Public Goods Funding (RetroPGF) mechanism. Unlike traditional funding models, RetroPGF focuses on rewarding past contributions rather than funding future projects. The idea is to allocate funds based on the impact of individuals’ or organizations’ contributions to the DAO, benefiting the broader community and ecosystem.

It’s not uncommon for complaints to arise about the concentration of control over fund allocation and unfair reward distribution. The core principle of RetroPGF is equitable distribution based on contributions, but this needs to be accompanied by clear, objective rules that are enforceable, even by minority members of the DAO. If rewards’ decisions are left solely to discretionary votes, those with the most power could unfairly allocate rewards to themselves or their allies, leaving honest contributors unrewarded, increasing token concentration. To avoid this, the reward decision process should involve a hybrid mechanism, combining voting with the fulfillment of objective, enforceable rules that can be enforced by anyone.

This can also be achieved through off-chain voting tools like Kleros SafeSnap, alongside a RetroPGF policy that can only be altered by a super-majority. If a reward decision violates any of the established principles or policy rules, the execution of that decision should be challenged and adjudicated by a neutral and impartial arbitrator to ensure RetroPGF rules are upheld.

For example, using Kleros SafeSnap, if minority developers feel their contributions are being disregarded or unfairly compensated in favor of a powerful contributor who has influenced the vote, anyone could challenge the execution of the transaction when attempting to allocate the reward. An impartial and neutral jury would then decide if the rewards were allocated according to the DAO’s constitution or the RetroPGF policy that ensures equitable contribution assessment, preventing the majority from acting based on discretionary power. This ensures that the token allocation system remains fully decentralized and immune to centralized decision-making, as anyone can challenge reward executions through a fair and impartial arbitration process, in compliance with, for example, some of the rules of FIT21’s decentralization test.

Conclusion: The need for clearer standards on decentralization

MiCA’s binary approach to decentralization presents both a challenge and an opportunity. The challenge is navigating a regulatory landscape where the threshold for full decentralization often seems out of reach. Yet, this is also an opportunity for the Ethereum ecosystem to take the lead, setting clear standards and creating practical tools for decentralization.

From day one, projects should prioritize implementing objective and enforceable principles for token allocation to avoid concentrated ownership and to promote decentralized governance. Whenever possible, they should reduce governance dependencies, ensuring that no single entity has the power to influence the protocol’s operation. This includes removing signers with too much centralized control over the protocol’s smart contracts and DAO treasury. Additionally, projects should introduce mechanisms and incentives that allow minority participants to challenge violations of decentralization principles by the majority holders.

However, this is not enough. To succeed in today’s regulatory landscape, builders need a clear and practical path to decentralization. While there are some useful papers that identify decentralization issues in the different layers (like this insightful Decentralization Handbook made by BCAS), there are still fragmented opinions, offering insights without a unified framework that connects the challenges with the actual solutions and tools available to address these centralization pain points. What we need is a clear and commonly agreed “Builder’s Guide to the Decentralization Galaxy”.

While it may not be realistic to have one guideline for every decentralized project, creating clear guidelines for the most common use cases related to services that could fall under MiCA is a step in the right direction. This would give builders a practical roadmap to follow, and clear and objective standards for grant providers to evaluate if funded projects remain genuinely committed to the decentralization principle.

There are still challenges when it comes to the other layers of decentralized projects, aside from governance, where viable solutions may not yet exist. However, simply recognizing these gaps is the first step toward driving the creation of new tools and frameworks that can help strengthen decentralization.

This isn’t just about complying with regulations from the old world, it's about bringing the vision of decentralized networks to life.

For both builders and regulators, this moment is a chance to clearly define what decentralization truly means — and why it matters.