This exploration aims to provide a comprehensive definition and framework for identifying decentralized protocols within the context of distributed ledger technology. It outlines key attributes that decentralized protocols must possess, including fault tolerance, resilience, attack resistance, transparency, and collusion resistance. These attributes form the backbone of Web3, the internet of value, and are essential for ensuring operational integrity and user self-sovereignty. A decentralized protocol is defined as a distributed, permissionless, and non-jurisdictional infrastructure designed to manage value and build an ecosystem. The paper proposes a testing framework to assess the decentralization of a protocol based on four characteristic components—Structural, Control, Influence, and Process—across various levels of the technology stack (Front End, Data, Smart Contract, Settlement). The ultimate measure of decentralization is the protocol's ability to afford users self-sovereignty, assessed through user accessibility and control over the protocol's operations. This framework serves as a tool for evaluating the decentralization of protocols and contributes to the broader understanding of decentralized systems.

This document refers to blockchains, distributed protocols connecting blockchains, and distributed protocols built on top of blockchains collectively as protocols. Consequently, establishing if a protocol is decentralized requires a definition and testing framework.

We can establish a definition once we determine the requirements and a suitable rationale for decentralization. But first, let’s address the attributes of a decentralized protocol.

A protocol is decentralized if it has the following attributes:

• Fault-tolerant and resilient

  • The protocol should sustain partial failures and be able to recover quickly.

• Attack-resistant and transparent

  • The protocol should be transparent to identify and defend against system attacks.

• Collusion-resistant

  • It should be hard for an individual, group, or organization to take control.

The above criteria help to identify decentralized protocols and to establish the broader reasoning behind decentralizing.

Decentralization increases security and robustness through transparency and distribution of control and operations. But it’s at the cost of efficiency relative to centralized organizations. Therefore, decentralizing for the sake of it will not provide a net positive benefit and, in all likelihood, will fail.

Therefore, an additional pragmatic rationale is required to decentralize a protocol with a net positive benefit.

Since decentralized protocols manage the transmission and management of value (Web3) from independent users and act as a platform to create or contribute to an ecosystem, the most reasonable basis for decentralizing is** ensuring operational integrity and protecting* the protocol's value ***to afford its users self-sovereignty.

We can create a definition for decentralized protocols using the above attributes and rationale to decentralize.

Fault tolerance and resilience require a protocol to be distributed and permissionless, with its functionality and code accessible to the public. A protocol should also be transparent, allowing the community to detect faults and defend against attacks. Furthermore, a permissionless protocol can protect its users from the centralized influence of collusion. And finally, the protocol should contribute to developing an ecosystem by affording its users the self-sovereignty to do so.

In short, the definition of a decentralized protocol is as follows:

A distributed, permissionless, non-jurisdictional protocol that serves as infrastructure to manage value, help build an ecosystem, and afford its users self-sovereignty.

The problem is that the definition needs to be more objective and measurable. Fortunately, a protocol that fits the description has four quantifiable characterizing components. Together, the components create a framework that, when successfully applied to a protocol’s technology stack, can be considered equivalent to meeting the criteria, thereby establishing a protocol as decentralized.

The four measurable components of the framework are the following:

• Structural component:

  • The number of tokens/computers/addresses/clients operating the project or protocol.

• Control component:

  • The number of people that control the structural component.

• Influence component:

  • The number of people influencing the control component.

• Process component:

  • The number of processes or functions the protocol has.

The following outlines the equivalency between successfully applying the components and satisfying the criteria of a decentralized protocol.

• A protocol needs redundancies (Structural) and sound operating processes (Process) to be fault-tolerant and resistant.

• A protocol must be transparent and have diverse interests (Control) looking after the operating processes (Process) to be attack-resistant.

• A protocol must have a diverse and independent set of interests (Control) providing competing influences (Influence) to be collusion-resistant.

Transactions are the building blocks of protocols. The base layer of the technology (tech) stack, referred to as the Settlement Layer, is the blockchain executing and settling transactions, with the remaining layers of the stack built out on top.

Outlined below is a generalization of a protocol’s tech stack:

• Settlement Layer

  • The executing blockchain.

• Smart Contract (Backend Layer)

  • The engineering layer of a decentralized application or dApp.

• Frontend Layer (User Interface)

  • The access point to the protocol.

• Data Layer

  • The data storage layer

The main idea is that if each layer of a protocol’s technology stack is decentralized, then the protocol as a whole is likely decentralized. Furthermore, a layer is decentralized if the four components (Structural, Control, Influence, and Process) of that layer have been constructed and applied in a decentralized fashion.

Therefore, given a tech layer, the framework's objective is assessing each component and evaluating the extent to which it operates in a decentralized manner. Then, aggregating the assessments across all the layers to derive a conclusion for the protocol.

A system is considered the sum of its parts, and this document follows the same approach with protocol decentralization. However, the Composite Fallacy states that in complex systems, such as protocols, that’s not always the case - the system may differ from the sum of its parts and consequently function unexpectedly. Therefore, ensuring an assessment is correct requires testing it against an expected outcome.

A decentralized protocol produces observable traits and capabilities, the most essential being user agency. Users and the community should be free to contribute to decision-making, planning, management, and profitability. Decentralized protocols must allow and provide users the ability to claim and defend their self-sovereignty.

Therefore, the final step to verifying decentralization is identifying if the protocol has the expected outcome of user self-sovereignty.

The main point of self-sovereignty is to mitigate the event of a person, group, or technology unduly changing or manipulating a user’s interactions, transactions, or value in a protocol. A decentralized protocol naturally makes it highly unlikely and gives users the confidence to assert user agency.

Further, users require access and the ability to contribute to the protocol freely to stay informed and ensure the likelihood of manipulation remains low, thereby maintaining their self-sovereignty.

A protocol, therefore, should result in the following operational traits of decentralization:

• Political Decentralization:

  • The community has the decision-making power and influence to create policy.

• Administrative Decentralization

  • The community is responsible for planning, financing, and management.

• Economic Decentralization:

  • The community is responsible for generating revenue and controlling expenditures.

Decentralized protocols incentivize communities to use and optimally contribute to its operations and maintenance. Protocols can run independently, without a community, but the focus here is on protocols that incentivize their communities.

A community collaborates to develop and deploy a decentralized protocol and creates two emergent operating structures - a decentralized workforce and governance.

The workforce and governance emerge through incentives to service the protocol's required operations, operate the functions, and optimize the decision-making of the protocol.

Consequently, through the community, workforce, or governance, users must be free to access, understand, and contribute towards the protocol's three traits (policy, administration, and economic), resulting in self-sovereignty and proving that the protocol is decentralized.

Lastly, our team at the UDHC has created a short survey anyone can fill out on behalf of a protocol and see where it falls on a spectrum of decentralization.

This exploration aims to provide a comprehensive definition and framework for identifying decentralized protocols within the context of distributed ledger technology. It outlines key attributes that decentralized protocols must possess, including fault tolerance, resilience, attack resistance, transparency, and collusion resistance. These attributes form the backbone of Web3, the internet of value, and are essential for ensuring operational integrity and user self-sovereignty. A decentralized protocol is defined as a distributed, permissionless, and non-jurisdictional infrastructure designed to manage value and build an ecosystem. The paper proposes a testing framework to assess the decentralization of a protocol based on four characteristic components—Structural, Control, Influence, and Process—across various levels of the technology stack (Front End, Data, Smart Contract, Settlement). The ultimate measure of decentralization is the protocol's ability to afford users self-sovereignty, assessed through user accessibility and control over the protocol's operations. This framework serves as a tool for evaluating the decentralization of protocols and contributes to the broader understanding of decentralized systems.

This document refers to blockchains, distributed protocols connecting blockchains, and distributed protocols built on top of blockchains collectively as protocols. Consequently, establishing if a protocol is decentralized requires a definition and testing framework.

We can establish a definition once we determine the requirements and a suitable rationale for decentralization. But first, let’s address the attributes of a decentralized protocol.

A protocol is decentralized if it has the following attributes:

• Fault-tolerant and resilient

  • The protocol should sustain partial failures and be able to recover quickly.

• Attack-resistant and transparent

  • The protocol should be transparent to identify and defend against system attacks.

• Collusion-resistant

  • It should be hard for an individual, group, or organization to take control.

The above criteria help to identify decentralized protocols and to establish the broader reasoning behind decentralizing.

Decentralization increases security and robustness through transparency and distribution of control and operations. But it’s at the cost of efficiency relative to centralized organizations. Therefore, decentralizing for the sake of it will not provide a net positive benefit and, in all likelihood, will fail.

Therefore, an additional pragmatic rationale is required to decentralize a protocol with a net positive benefit.

Since decentralized protocols manage the transmission and management of value (Web3) from independent users and act as a platform to create or contribute to an ecosystem, the most reasonable basis for decentralizing is** ensuring operational integrity and protecting* the protocol's value ***to afford its users self-sovereignty.

We can create a definition for decentralized protocols using the above attributes and rationale to decentralize.

Fault tolerance and resilience require a protocol to be distributed and permissionless, with its functionality and code accessible to the public. A protocol should also be transparent, allowing the community to detect faults and defend against attacks. Furthermore, a permissionless protocol can protect its users from the centralized influence of collusion. And finally, the protocol should contribute to developing an ecosystem by affording its users the self-sovereignty to do so.

In short, the definition of a decentralized protocol is as follows:

A distributed, permissionless, non-jurisdictional protocol that serves as infrastructure to manage value, help build an ecosystem, and afford its users self-sovereignty.

The problem is that the definition needs to be more objective and measurable. Fortunately, a protocol that fits the description has four quantifiable characterizing components. Together, the components create a framework that, when successfully applied to a protocol’s technology stack, can be considered equivalent to meeting the criteria, thereby establishing a protocol as decentralized.

The four measurable components of the framework are the following:

• Structural component:

  • The number of tokens/computers/addresses/clients operating the project or protocol.

• Control component:

  • The number of people that control the structural component.

• Influence component:

  • The number of people influencing the control component.

• Process component:

  • The number of processes or functions the protocol has.

The following outlines the equivalency between successfully applying the components and satisfying the criteria of a decentralized protocol.

• A protocol needs redundancies (Structural) and sound operating processes (Process) to be fault-tolerant and resistant.

• A protocol must be transparent and have diverse interests (Control) looking after the operating processes (Process) to be attack-resistant.

• A protocol must have a diverse and independent set of interests (Control) providing competing influences (Influence) to be collusion-resistant.

Transactions are the building blocks of protocols. The base layer of the technology (tech) stack, referred to as the Settlement Layer, is the blockchain executing and settling transactions, with the remaining layers of the stack built out on top.

Outlined below is a generalization of a protocol’s tech stack:

• Settlement Layer

  • The executing blockchain.

• Smart Contract (Backend Layer)

  • The engineering layer of a decentralized application or dApp.

• Frontend Layer (User Interface)

  • The access point to the protocol.

• Data Layer

  • The data storage layer

The main idea is that if each layer of a protocol’s technology stack is decentralized, then the protocol as a whole is likely decentralized. Furthermore, a layer is decentralized if the four components (Structural, Control, Influence, and Process) of that layer have been constructed and applied in a decentralized fashion.

Therefore, given a tech layer, the framework's objective is assessing each component and evaluating the extent to which it operates in a decentralized manner. Then, aggregating the assessments across all the layers to derive a conclusion for the protocol.

A system is considered the sum of its parts, and this document follows the same approach with protocol decentralization. However, the Composite Fallacy states that in complex systems, such as protocols, that’s not always the case - the system may differ from the sum of its parts and consequently function unexpectedly. Therefore, ensuring an assessment is correct requires testing it against an expected outcome.

A decentralized protocol produces observable traits and capabilities, the most essential being user agency. Users and the community should be free to contribute to decision-making, planning, management, and profitability. Decentralized protocols must allow and provide users the ability to claim and defend their self-sovereignty.

Therefore, the final step to verifying decentralization is identifying if the protocol has the expected outcome of user self-sovereignty.

The main point of self-sovereignty is to mitigate the event of a person, group, or technology unduly changing or manipulating a user’s interactions, transactions, or value in a protocol. A decentralized protocol naturally makes it highly unlikely and gives users the confidence to assert user agency.

Further, users require access and the ability to contribute to the protocol freely to stay informed and ensure the likelihood of manipulation remains low, thereby maintaining their self-sovereignty.

A protocol, therefore, should result in the following operational traits of decentralization:

• Political Decentralization:

  • The community has the decision-making power and influence to create policy.

• Administrative Decentralization

  • The community is responsible for planning, financing, and management.

• Economic Decentralization:

  • The community is responsible for generating revenue and controlling expenditures.

Decentralized protocols incentivize communities to use and optimally contribute to its operations and maintenance. Protocols can run independently, without a community, but the focus here is on protocols that incentivize their communities.

A community collaborates to develop and deploy a decentralized protocol and creates two emergent operating structures - a decentralized workforce and governance.

The workforce and governance emerge through incentives to service the protocol's required operations, operate the functions, and optimize the decision-making of the protocol.

Consequently, through the community, workforce, or governance, users must be free to access, understand, and contribute towards the protocol's three traits (policy, administration, and economic), resulting in self-sovereignty and proving that the protocol is decentralized.

Lastly, our team at the UDHC has created a short survey anyone can fill out on behalf of a protocol and see where it falls on a spectrum of decentralization.