The “Decentralization Test” for Web3 Protocols: A Playbook for Builders

This article is part of a larger playbook for Web3 builders. For further information, head to the article How to Approach Legal Strategy for Your Web3 Project. 

In the article How to Approach Legal Strategy for Your Web3 Project, we aimed to highlight the pivotal role of establishing a legal strategy for a Web3 project. This strategy significantly influences protocol development, marketing, customer acquisition, monetization models, and other critical aspects. We delved into two approaches: creating a fully decentralized Web3 project and constructing a project under team/founder control (centralized strategy).

The centralized route usually involves obtaining licenses, incorporating KYC, and adhering to financial promotion requirements in intended markets. While this centralized strategy is generally quite straightforward and easy to follow, the decentralized strategy in Web3 poses a common challenge for builders who often encounter two key questions:

1. How can we determine the threshold of decentralization necessary for a protocol to be labeled “fully decentralized”, all whilst ensuring it doesn't fall under VASP/CASP, securities, capital markets, and other regulatory frameworks?
2. How can we achieve a level of “sufficient decentralization” for the protocol, considering the practical impossibility of building a fully decentralized Web3 project from day one?

In this article, we propose that Web3 builders follow a two-stage “self-assessment” process for decentralized protocols:

1. First stage: Assessing the protocol's risk profile based on the data it handles and the activities within its operational structure.
2. Stage 2: Assessing the protocol to determine its degree of “decentralization”, consequently analyzing the risks for the developers involved with such a protocol.

Let’s start with questions that evaluate the protocol's risk profile and explore why these answers are crucial for assessing the risks associated with launching the protocol.

Question 1: What type of data does the protocol process?

In our article Differentiating DLT, protocols, dApps we have already mentioned one of the criteria for classifying protocols: the type of data that the protocol processes. Based on this criterion, we have identified three categories of decentralized protocols:

• those that process data on value exchange (DeFi protocols)
• those that process data on decentralized decision making (governance protocols)
• those that process data on digital identity (zk(zero-knowledge) proof protocols)

How does this criterion impact the protocol's risk profile? It helps to address these questions:

• what industry does the protocol operate in (finance, gaming (game dev), governance, identity)?
• is this industry regulated (e.g., finance), or unregulated (e.g., video games).

In regulated industries where the protocol operates, developers face significantly higher risks concerning protocol non-compliance compared to unregulated sectors.

Question 2: What is the mechanism of the smart contracts protocol?

The next question is the mechanics of the smart contracts that are incorporated into the protocol. Smart contracts are a set of rules (“self-executing algorithms”) according to which the protocol processes certain data. Taking DeFi protocols as an example, depending on their smart contract mechanisms, we can illustrate different types of DeFi protocols:

• Decentralized lending-borrowing, where smart contracts independently accept deposits from lenders and issue “loans” to borrowers, as seen in the case of MakerDAO.
• Decentralized trading involves, where smart contracts autonomously settle orders between sellers and buyers on decentralized exchange platforms, like dYdX.
• Decentralized market making, where smart contracts autonomously use digital assets from liquidity pools for trading on decentralized exchanges, like Uniswap.

How does this affect the risk profile of the protocol? This criterion helps to determine the list of activities that the protocol performs autonomously (“protocol services”) and determines whether they could be legally qualified as regulated activities or not. 

Should the protocol's anticipated activities (“protocol services”) fall within regulated domains (by being regulated activities), then developers face substantially higher risks in terms of protocol non-compliance compared to scenarios involving unregulated activities.

How the degree of protocol decentralization impacts the extent of responsibility placed on its developers

If the risk profiling identifies that the protocol operates in a regulated sector (e.g., finance) and involves activities categorized as regulated (e.g., lending-borrowing or digital asset trading), then the subsequent step for Web3 builders involves evaluating their personal or company risks based on their chosen approach to ownership and governance structuring for the protocol. The general approach is that the more control developers exert over the protocol, the greater responsibility they have for its operations. 

Therefore, evaluating the level of “decentralization” in the protocol is a crucial exercise for Web3 builders. It helps to not only determine the regulatory boundaries but also to assess the personal risks for developers based on their level of influence over the protocol.

How to assess the degree of decentralization in a protocol

The following six criteria are required to assess the extent of decentralization of the protocol.

Criterion 1: the possibility of external influence on the protocol's operation

The first criterion for a “self-assessment” of the protocol is gauging the level of “independence” that the protocol has from external influence. This means evaluating whether external players such as developers, founders, DAOs, etc., have the technical capability to influence the operation of the protocol. For example, having access to the protocol's smart contract private keys, enabling them to freeze user transactions, suspend withdrawals, set or adjust fees, etc.

This criterion helps distinguish various protocol types:

1. Permissionless: External players lack control to control transactions, block withdrawals, or impose conditions or fees on transactions.
2. Semi-permissionless: External players (e.g., developers or a DAO)  possess limited technical capabilities, often required to influence the operation of the protocol. For example, freezing withdrawals from the protocol during a security breach (such as a cyber attack) until the protocol is updated to resolve the issue of vulnerability. 
3. Permission-based: External players (like developers or a DAO) have full control over the protocol's operations, enabling actions such as freezing user transactions or setting protocol fees.

Why is this important from a legal standpoint? This criterion helps to analyze the technical capabilities of external players (developers, founders, DAOs, etc.) to influence the protocol.  Consequently, it determines the activities for which these external players bear responsibility due to their technical influence. It also delineates activities where the protocol operates fully permissionless, absolving external players of responsibility in those realms.

For instance, if developers or DAOs have the capability to block or freeze user transactions, it is assumed that they should use their technical abilities to implement appropriate measures in the protocol to combat money laundering or tax evasion. However, the presence of these technical capabilities within a project team that disregards measures to tackle illicit activities in the protocol may indicate negligence by the developers or DAOs, and, as a result, could lead to liability for negligent actions.

Criterion 2: Protocol Autonomy

The criterion focuses on the presence or absence of protocol elements, that, due to technical or other limitations, cannot function entirely autonomously through self-executing smart contracts. Consequently, these elements require administration or management by external players.

Based on this criterion, the following protocol types can be identified:

• Autonomous: These protocols operate without elements requiring external management. They rely entirely on self-executing smart contracts, enabling the protocol to function autonomously.
• Quasi-autonomous: These protocols have partial elements that necessitate external management. The elements might encompass protocol upgradability (for enhancing cybersecurity), strategic or reserve funds (for managing protocol liquidity), and token incentive or grant funds (for encouraging contributors and builders). 
• Non-autonomous: These protocols are subject to developer or DAO decisions. External players predominantly govern most protocol elements, determining their operation and functionality.

Why is this important from a legal perspective? This criterion assists in identifying any elements within the protocol that require external management or administration, essentially highlighting the presence of “non-autonomous” components. It also identifies the extent of powers held by developers or the DAO within the protocol ecosystem, specifies the DAO's responsibilities, and outlines the DAO's response mechanisms in case of erroneous decisions. For instance, failing to manage the strategic or reserve fund, which leads to a liquidity gap in the protocol and results in user fund losses would necessitate a response from the DAO.

Criterion 3: Protocol Monetization

Another criterion for assessing a protocol's “decentralization” level involves whether the protocol incorporates monetization mechanisms, such as a fee pool accumulating transaction commissions processed by the protocol. If the protocol involves monetization (e.g., if it has a fee pool) the subsequent inquiries pertain to the beneficiary of the protocol earnings and the entity controlling fund distribution from the fee pool. Based on these questions, the following protocol types can be identified:

• Non-monetized / value-accrual protocol (a protocol without monetization or value accrual): This type lacks a mechanism for accumulating earnings. Instead, the protocol's “commissions” are autonomously distributed as incentives among ecosystem participants who contribute to the technical functioning of the protocol (e.g., validators / node operators receiving rewards for supporting protocol operations).
• Monetized protocol with DAO governance: The protocol incorporates monetization and employs a DAO to make decisions on the distribution of the protocol's earnings through decentralized voting. This allocation aims to support and further develop the protocol's ecosystem.
• Monetized protocol with developer / founder beneficiaries: The protocol has monetization, channeling earnings (from a fee pool, for example) to developers and founders. These individuals independently make decisions regarding the utilization of the profits from the protocol.

Why is this important from a legal perspective? From a legal standpoint, the beneficiary of a protocol's monetization holds significant importance. If the protocol generates earnings, then determining the ultimate beneficiary (whether validators, infrastructure players, team/engineers, or the DAO) becomes crucial.The legal obligations placed on the beneficiaries vary based on their individual roles, as they are incentivized to maximize their earnings. Consequently, to comply with legal requirements, each beneficiary is obliged to ensure that these earnings originate only from legal sources.

Criterion 4: Protocol Code

Every protocol is first and foremost a code. Therefore, in addition to controlling various functions of the protocol, another criterion is needed to assess the level of “decentralization” of the protocol: namely, the right of ownership to the protocol code (the structure of intellectual property of the protocol).

Based on this criterion, the following types of protocols can be identified:

• Fully open-sourced protocols: These protocols have entirely open codebases, typically under licenses like the MIT license, allowing developers to copy, modify, restart, or perform various other actions with the code.
• Partially open-sourced: In this scenario, certain components of the protocol initially remain closed to mitigate the risk of hacker attacks, particularly in the early development phases. However, the intention is to open source these elements as soon as their development permits this.
• Proprietary: In this setting, the majority of the protocol's elements are closed and under the full control of the project team.

Why is this important from a legal standpoint? Whoever controls the code controls the protocol. Therefore, when the protocol code is closed and controlled by the project team, it implies some form of control over the protocol’s functionalities, business model, and other aspects controlled through code governance. Consequently, this instills an expectation from the team that the operational principles embedded within the protocol's code align with the legislation applicable to the protocol.

Criterion 5: Protocol Tokenomics

Another element of the protocol that merits distinction as its own criterion, is the protocol’s native token. This criterion will not be relevant for all protocols, as tokenless protocols are only just beginning to emerge, however, it is essential for protocols with native tokens. The essence of the criterion lies in the analysis of the process of issuing and distributing tokens, and the structure of control over this process.

Based on this criterion, we can identify the following protocol types:

• A protocol employing a two-stage process for issuing its native token: This encompasses the genesis token supply and continuous token supply stages, both involving autonomous emission and distribution among participants within the ecosystem.
• A protocol employing a two-stage issuance process for its native token: The initial stage of the genesis token supply operates autonomously, fostering a community of token holders. The subsequent stage of the continuous token supply is structured and governed by a DAO.
• A protocol executing a single campaign: This protocol executes a token generation event for token issuance wherein all token supply is under the control of the project’s developers or founders.

Why is this important from a legal perspective? If the analysis of this criterion reveals that the issuance and initial distribution of tokens were under the control of developers/founders, it's presumed that the team ensured compliance during the token generation campaign. This process would have likely involved a thorough and meticulous analysis of token types (utility vs. security), distribution goals (fundraising vs. community building), and commitments to token receipts (such as participating in decentralized governance, revenue sharing, exclusive protocol functionality access, etc.). Non-compliance with these aspects may render the team liable for breaching securities laws, capital market regulations, VASP/CASP regimes, etc.

Criterion 6: Protocol's composability

Much of the criteria we have explored above focus on identifying and analyzing “centers of centralization” within the protocol by seeking out elements that display signs of centralized administration and management. The final—and very crucial— criterion aims to analyze the protocol in the context of decentralization. This is the criterion of control over the protocol's integration potential with other protocols and interfaces.

Based on this, the following protocol types can be distinguished:

• Freely composable protocols: These protocols allow integration into other decentralized protocols without needing permissions or sanctions from third parties. Interface providers can launch websites, applications, or browser extensions independently, granting end users seamless access to the protocol.
• Partially composable protocols: Certain protocol elements might require additional efforts or permissions from developers or DAOs for potential integrations. This could be for reasons related to reputation, cybersecurity, or compliance. For instance, the DAO might conduct an analysis of a partnership protocol before integrating it. This helps ensure that liquidity from the partnership protocol has a transparent source of origin and will not “contaminate” the liquidity of the protocol controlled by the DAO, helping to maintain protocol integrity.
• Permission-based composable protocols: These protocols require developers' permission for any potential integrations. Developers independently make decisions regarding these integrations, exerting control over the protocol's composability.

Why is this important from a legal perspective? In most cases, users interact with decentralized protocols through user-friendly interfaces (front-ends) developed for seamless interaction. Control over such interfaces entails managing user engagement, identifying their locations, and analyzing their wallets. Should developers or companies “monopolize” control, whether through exclusive interface launches or exclusive integrations with other protocols, then they will have to bear obligations along with the benefits. These obligations include ensuring that such integrations comply with the laws of countries where users or interface providers are located. This involves undertaking an analysis of the legality of interfaces, compliance with sanction laws, regulated financial promotion, etc.

Grappling with the concept of progressive decentralization

The criteria outlined in this article give founders, builders, developers, and the wider Web3 community a better idea of how to assess the degree to which a protocol is decentralized. However, it is impossible to build a protocol that is fully decentralized from inception and subsequent steps for Web3 builders involve mapping the progressive decentralization process for their protocol. 

With a good grasp on the degree of a protocol’s decentralization, Web3 builders must next develop a roadmap to transform the protocol from partially decentralized to fully and sufficiently decentralized. This approach has already been explored by prominent Web3 VCs, including a16z and Variant Fund. It is called progressive decentralization.

To learn more about what progressive decentralization represents and how to apply it to a Web3 project, read the next chapter in our playbook: The Progressive Decentralization Playbook for Web3 Builders.

Pin down your legal strategy for your protocol

Much of the excitement in the Web3 space lies in building, developing, exploring, and innovating within the community. In contrast, the legal aspect—the strategy, the structuring, the legal analysis, and opinions—tends to strike builders with fear, sometimes slowing and sometimes freezing the project’s process as attempts are made to resolve legal queries.

At Legal Nodes, we feel the excitement of the Web3 sphere, of founders and builders developing and launching their projects at all stages, including protocols that are fully decentralized, centralized, or somewhere in-between. 

We regularly assist Web3 teams with their legal conundrums, starting with the big question of “What even are our options right now?” before exploring the ever-changing water of worldwide regulation and assessing the risks and opportunities available to each team. We help pick out best-case examples and explore ways to proactively build a compliant structure that will dissuade regulators from issuing heavy fines in the future.

To receive legal support for your crypto project, protocol, token release, or any legal structuring matter surrounding your Web3 venture, speak with a team member today.