‍Why Does Decentralization Matter?

The concept of decentralization is foundational to the crypto space.  It underpins the ethos of blockchain technology, which has its foundations on censorship resistance, liveness guarantees, transparency, permissionless access, and security, all of which are uniquely enabled by true decentralization.

Further, decentralization has given rise to critical industry concepts, like DeFi (decentralized finance), and has led to crypto projects classifying themselves as centralized versus decentralized and to users discerning between centralized and decentralized crypto protocols and applications.  

However, despite its importance, the term ‘decentralization’ often lacks clarity, precision and standardization, leading to regulatory ambiguities and varying interpretations among crypto stakeholders.  Not many people are able to actually define what decentralization really means and, more importantly, what it should imply in practice.  I want to help solve that.

What is Decentralization?

From a theoretical standpoint, decentralization can be defined as “the degree to which control, decision-making, and participation in a given protocol are distributed across a wide and independent set of stakeholders”.  However, theoretical definitions alone are not enough if they do not help us understand what things should actually mean, in practice.

People have historically used the term ‘decentralized’ as if it was a black or white thing: a protocol is either centralized or decentralized.  That is an obviously flawed approach, since it forces us to disregard many relevant nuances that should be given some weight in the equation when assessing a protocol’s decentralization.  Many crypto industry participants agree today that decentralization is a spectrum, and not a black or white reality.

Accepting decentralization as a spectrum is a good first step, but it is not the end of the road.  In fact, conceiving decentralization as a spectrum has given rise to new terms that may be as opaque as (or potentially even more opaque than) the term ‘decentralization’ itself, such as “full decentralization” or “sufficient decentralization”.  Can you say with confidence what “sufficiently decentralized” actually means, and what it should imply in practice?  Maybe you can, or maybe you just have an opinion about it.  I do too, and that’s why I’m excited to present the XYZ Decentralization Index.

Introducing the XYZ Decentralization Index

The XYZ Decentralization Index (the “Index”) has been developed with the main aim of providing a structured framework for evaluating decentralization in crypto protocols from a practical angle, specifically for regulatory purposes.  This post introduces the Index, outlines its criteria, and discusses its implications for crypto regulators, developers, users and other stakeholders.

The Index establishes a high-level framework for objectively measuring decentralization across six core criteria, which are considered essential.  It is designed to be both practical and comprehensive, enabling stakeholders to evaluate a protocol’s decentralization objectively.  Since each of the six core criteria are considered essential from a decentralization standpoint,  a protocol must satisfy all criteria to be considered 'sufficiently decentralized' pursuant to the Index.

The Six Core Criteria

1. Open-Source, Immutable Code

All code relating to the protocol (including the software for the core protocol, the user interface, the API and/or any other relevant components of the protocol’s infrastructure) must be publicly and freely accessible, auditable, and forkable, available for use by anyone under a sufficiently broad free open-source licence, such as an MIT Licence or a GNU Affero General Public License.  In addition, all code (especially any smart contracts) on which the protocol relies must be immutable, meaning that no centralized actor or group of actors has administrative, operational or ownership privileges controlling parameter changes, upgrades and/or the minting or burning of tokens.

This is a must, and no concessions are acceptable regarding the open-source nature and immutability of a protocol’s code if it purports to be a decentralized protocol.

2. Number of Independent Validating Node Operators

The protocol must be run by at least 5 independent validating node operators.  It is crucial to emphasize that the 5 validating node operators must be truly independent from one another and not acting in a coordinated fashion and/or subject to joint or common control by a smaller set of participants.

While this number (5) is somewhat arbitrary, I think it guarantees a reasonable absolute minimum level of decentralization of the ultimate control of the protocol and its availability.  It should be relatively unlikely that 5 independent actors (or even a majority thereof) collude and/or decide to discontinue their operations at the same time.  It also guarantees certain resiliency and diversity in the validating node operator set in the event of a fork of the protocol.  

3. Validating Node Control Distribution (Nakamoto Coefficient)

The protocol must be controlled by no less than 3 independent validating node operators.  This is the well-known Nakamoto coefficient.  

The term ‘control’ shall be assessed on a case-by-case basis, based on each network’s software and consensus mechanisms (e.g. more than 50% of the stake in proof-of-stake EVM chains subject to so-called “51% attacks”, more than two thirds of the stake in delegated proof-of-stake CosmosSDK chains, etc.).

This test should also be applied making the necessary adaptations to blockchains with different security mechanisms (e.g., a controlling majority of the stake weight in proof-of-stake blockchains, a controlling majority of the liquidity in proof-of-liquidity networks, etc.).  

For protocols that are applications deployed on top of blockchains, this test can be applied at the level of the blockchain on which they are deployed.  

4. Number of Token Holders

There shall be at least 100 independent holders of the protocol’s token.  

This test assumes that the protocol has its own token and that the token has certain utility relating to the protocol (i.e., staking, governance, access and/or other functionalities).  

While the 100-tokenholder threshold is, again, somewhat arbitrary, it has several objective benefits.  It makes it hard for small groups of related participants (family members, groups of friends, etc.) to coordinatedly launch or acquire control over the supply of a protocol’s token.  It also signifies a reasonable minimum level of support and engagement for the protocol and the token.  Moreover, it creates a credible, sizable layer of oversight, supervision and accountability over other key protocol participants (such as validating node operators).

Further to the above, the 100-tokenholder threshold is supported by the minimum number of members required to form a DUNA (Decentralized Unincorporated Nonprofit Association) under Wyoming laws, and is basically the main criteria that guarantees a minimum level of decentralization in a DUNA and that justifies the ‘D’ in the acronym.

5. Governance Control Distribution

The protocol’s governance system must be controlled by no less than 3 independent actors.  

This fifth test’s threshold is set at 3 just like the threshold for the third test in the Index (the Nakamoto Coefficient), and thus could be referred to as the ‘Governance Nakamoto Coefficient’.  

Here, ‘control’ shall also be assessed on a case-by-case basis, based on the quorums, majorities and other rules foreseen in the protocol’s governance system.

For purposes of this test, the parties that may exercise the governance rights associated with the tokens should be considered, even if they are not the ultimate owners of the tokens (for example, custodians, centralized exchanges, and validators in dPoS networks should be considered in lieu of the actual ultimate owners of the tokens if the former are entitled to exercise the tokens’ governance rights).

This test assumes that the protocol has its own token and that the token has certain governance rights associated with it that grant a certain level of control over the protocol or certain aspects, parameters or components of the protocol.  This test should be disregarded if the protocol that is being assessed does not have a token-based governance system and any change to the protocol’s software or parameters depends on the validating nodes.  

6. Key Infrastructure Diversity

There must be at least 2 independent operators for each key infrastructure component that is required for the protocol to function.  These may include clients, sequencers and/or other necessary infrastructure components.  Emphasis is placed on the terms required / necessary, which should be construed strictly.

Protocol users should be able to select or rely on the infrastructure components maintained by any of the multiple key infrastructure operators at will and with no material disadvantages between one or the other.  

To clarify, RPC nodes and user interfaces (also referred to as UIs, GUIs or front-ends) should, in my view, not be considered as essential or strictly required for a protocol to function and, therefore, a protocol must not necessarily have more than one active RPC node or front-end to be considered sufficiently decentralized, assuming the RPC node operators and/or the front-end operators do not have exclusive control over the users’ access to the protocol nor custody over user funds.

A Holistic Approach to Decentralization

The XYZ Decentralization Index considers the most essential indicators of a protocol’s decentralization, and sets reasonable thresholds for each of them to enable users of the Index to clearly conclude whether a protocol is, as a whole, ‘sufficiently decentralized’ or not.

In my view, a protocol, when looked at as a whole, can be said to be as decentralized as the least decentralized of its components.  That is why, for a protocol to be considered ‘sufficiently decentralized’ pursuant to the XYZ Decentralization Index, the protocol would need to pass all of the tests in the Index, not just some (or even a majority) of them.  It is possible, however, that a protocol passes some but not all of the tests in the Index, in which case certain layers or components of the protocol could be said to be sufficiently decentralized, but not the protocol as a whole.  For example, a protocol with fully open-source, immutable code, run by 30 independently-operated validating nodes, with a Nakamoto Coefficient of 5, but with less than 100 total token holders and a Governance Nakamoto Coefficient of 1 could not, based on the Index, be said to be sufficiently decentralized as a whole, but it would probably be fair to say that the operation of a validating node (i.e., the validation activity) in particular is sufficiently decentralized in that protocol (even if other layers or components of the protocol are not sufficiently decentralized).  

There are other criteria that have been considered and intentionally excluded from the scope of the Index because, in my personal opinion, while they are nice-to-haves from a decentralization standpoint, there is not a minimum threshold that should be considered essential for a protocol to be deemed sufficiently decentralized, especially from a regulatory standpoint.  These intentionally-excluded variables include, among others: (i) the geographical distribution of the nodes, the token holders and/or any infrastructure operators; (ii) accessibility to the protocol’s token (where it can be purchased, how liquid it is, etc.); (iii) accessibility to participation in the protocol’s consensus mechanism (and/or the underlying blockchain’s consensus mechanism, as applicable); (iv) other significant barriers to entry (e.g. highly demanding hardware requirements); (v) the number of independent developers contributing to the protocol’s open-source code; (vi) community engagement; (vii) geoblocking or screening tools implemented at a protocol level and/or at the level of any specific component of the protocol; and (viii) interoperability with other protocols.

Implications for the Crypto Industry

By providing clear, measurable thresholds, the XYZ Decentralization Index addresses several existing challenges:

1. Regulatory Clarity: Regulators gain a structured tool to assess the true level of decentralization of any crypto protocol, reducing ambiguity and enabling consistent enforcement of crypto-specific regulations.
2. Entrepreneurial Confidence: Innovators and investors can better understand the decentralization requirements for regulatory compliance, fostering a more conducive environment for innovation.
3. Community Engagement: The Index encourages ongoing dialogue within the crypto industry to refine and evolve the framework, ensuring its relevance in a rapidly changing landscape.

A First Step Toward Standardization

While the XYZ Decentralization Index is not without its limitations and is likely partially flawed and/or incomplete, it represents a significant step forward in creating a practical approach to defining and measuring decentralization.  By fostering dialogue and encouraging feedback, the Index aims to build a consensus-driven standard that balances theoretical ideals with practical realities.

Join the Conversation

The decentralization debate is far from over, and your input is invaluable.  Whether you agree with the criteria in the Index or see room for improvement, your perspective can help refine this framework.  Reach out with your thoughts and feedback, and let’s shape the future of decentralization together!

If you liked this post, I plan to write a follow-up post early next year assessing various real-life crypto protocols (including dYdX) using the XYZ Decentralization Index in order to determine whether they are sufficiently decentralized or not, so keep an eye out for that!  

Acknowledgements

I want to thank Rebecca Rettig, Marc Boiron, David Gogel, Charles d’Haussy and Vivian Yeong for their valuable feedback on drafts of this post.