Defining Decentralization for Law

29 min readApr 16, 2020

The Growing Relevance of Decentralization to Law

In recent years, “decentralization” has become an important concept for purposes of the law. Consider:

Regulators such as the Securities & Exchange Commission (SEC) and the Financial Crimes Enforcement Network (FinCEN) have recognized that the applicability of financial regulations to blockchain systems can depend on the degree of control people have over them, with certain regulations being inapplicable when a system is “sufficiently decentralized” or “non-custodial”.
U.S. politicians have even learned to discern among decentralized cryptocurrencies and centralized cryptocurrencies, and to view the centralized solutions with more skepticism, as evinced in the U.S. Congress’s recent hearings on Facebook’s Project Libra.
Courts have held that the decentralized, trust-reduced nature of blockchain systems can affect how property laws and tort claims are interpreted — for example, the information in blockchain systems can form a foundation for property rights in tokens such as Bitcoin, even though information is typically not treated as property in other contexts.

Unfortunately, lawyers, regulators and politicians might not always fully understand or explain what they mean by “decentralized”, nor why they believe decentralization has legal significance. Worse still, there is not even a clear non-legal meaning of “decentralization”. Some argue that even fully read-/write-unpermissioned blockchains like Bitcoin are not decentralized, while others have argued that blockchains like Bitcoin and Ethereum are truly decentralized but other systems (like enterprise blockchains) are not.

The purpose of this article is to remind people that understanding when a system is decentralized for legal purposes is a critical task, to explain in more detail what I think a reasonable legal test of “decentralization” will look like and to encourage other attorneys and technologists to work on this important issue.

Why Do We Need a Legal Test for Decentralization?

Much has already been written about why the law does apply or should apply differently to decentralized systems than centralized systems. Thus, I will not attempt an in-depth policy justification of that position here, but for the most part will simply assume it is true. For those who may doubt the premise, I would suggest reviewing some or all of the resources listed under the endnotes for this article.

Assuming the law applies differently to a “sufficiently decentralized” system than to a centralized system, it is imperative that lawyers, judges, regulators and others involved in the legal industry develop a common understanding of what “decentralization” means. Otherwise, they will not know how to apply the law. I believe that a test for when a system is decentralized will be the best way of creating a consistent understanding.

A Legal Philosophy Interlude — Principles vs. Standards vs. Rules

The task of explicitly building the concept of “decentralization” into law could be approached in various ways, each of which has pros and cons.

The pros and cons of formulating laws as principles, standards or rules have been discussed extensively in legal philosophy generally, as well as specifically in the context of securities law reform. Although the subject is nuanced, in general it may be said that:

A principles-based approach is the most flexible and likely to yield consistently sound results, but is slow and provides little ex ante certainty to market participants.
A standards-based approach is slightly less flexible while still having many of the advantages of a principles-based approach, but provides more clarity and predictability — though still typically will require extensive and costly legal analysis (the “Howey test” being a great example).
A rule-based approach is the most clear and provides the most ex ante certainty with the lowest transaction costs, but therefore must also be the most conservative and probably yield many ‘false negatives’ — i.e., proscribing activity that would be considered legitimate under a more principles-based or standards-based approach.

The best legal systems combine the strengths of all three approaches to the law. U.S. securities laws provide an excellent example of this tripartite strategy. For example:

Section 4(a)(2) of the Securities Act of 1933 (the ’33 Act) exempts from SEC registration requirements “transactions by an issuer not involving any public offering”;
standards and practices about the meaning of “public offering” developed over some decades, through court opinions, regulatory action and consensus of the legal profession; and
in 1982, the SEC implemented Regulation D as a bright-line, non-exclusive “safe harbor” defining some clear circumstances in which a securities offering would not be deemed a “public offering” — such as a sale only to accredited investors.

It is important to note that, in this evolution from principles to standards to rules, the rules do not override the standards, and the standards do not override the principles. Instead, all three forms of law remain available to market participants, who may select among them depending on their needs and risk appetite. A market participant who is highly risk-averse or cannot afford (in time and/or money) the costs of a very bespoke approach will opt to take advantage of the bright-line safe harbor rule. A more sophisticated market participant can, if they so wish, retain advisors to help them structure an offering that is legally compliant when considered in light of the deeper principles and policy considerations embodied in the statute.

My contention is that it should also be the same way with determining the law around “decentralization.” First, we need a flexible, rich and nuanced jurisprudential standard for assessing when a system may be sufficiently decentralized. Then, Goodhart’s law notwithstanding, there should also be a clear, bright-line “safe harbor” encompassing a subset of systems for which it is particularly obvious that they are decentralized, and market participants who wish to do so should be able to follow the conservative path set out in that safe harbor without fear of legal reprisals. Of course, non-legal principles of blockchain governance will continue to play a role, and should inform how the legal standards and rules are applied; a great example is Donald McIntryre’s “10 Principles for Blockchain Governance”.

In this article I will attempt to propose both a more flexible standard and a bright-line safe harbor for assessing whether a blockchain system is decentralized as a matter of law.

A Taxonomy of Blockchain Power Forms

In order to determine whether a blockchain system is “decentralized,” we must first itemize the various potential forms of power over a blockchain system. Only if control over each of them is “decentralized” should the system as a whole be considered to be clearly and indisputably “decentralized” as a matter of law.

1. Validation Power

Validation power refers to the ability of persons participating in or relying on the network to read and validate its data. Aside from certain read-permissioned enterprise blockchain systems, the validation power of most blockchain systems is decentralized because the blockchain data is freely accessible to anyone through the peer-to-peer network and uses a cryptographic scheme that enables any person with the right software and understanding to independently verify the validity of state changes by running the data through cryptographic checks. Decentralization of validation power also requires that all relevant software code be publicly available for review and operation.

Since decentralization is not all-or-nothing, some blockchain systems may decentralize validation power better than others. A blockchain system with serious “state bloat” may require such a large amount of data to be downloaded and validated, or the state transition rules may be so computationally challenging, that only enterprise-grade computer systems are up to the task. The validation power of such a blockchain system is still decentralized, but not as decentralized as in a system that is more lightweight and can be affordably and quickly validated by consumer-grade equipment. Validation power on the system with heavier state should be considered to be less decentralized than on the system with lighter state, but may still be sufficiently decentralized for purposes of the law.

2. Consensus Power

Consensus power refers to the ability of persons to write data to the blockchain. To write data to the blockchain is typically a two-step process: (1) a properly formed proposal to add a block must be made; and (2) that proposal must be accepted by the other nodes on the network in accordance with the consensus protocol embodied in the software client(s) those nodes are running.

Because Step 2 (accepting blocks) is essentially automatic and passive, Step 1 (proposing valid blocks) is the primary vector for potential “attacks” on the system. Thus, most protocols permission the power to propose blocks:

In open proof-of-work-based systems such as Bitcoin and Ethereum 1.x, block production is permissioned by the protocol’s requirement that valid block proposals be accompanied by a hash meeting certain criteria, which can only be generated by running real-time computations on expensive computer hardware. Yet, anyone who has such hardware can propose a block— they do not need to be accepted into the network based on identity.
Delegated-proof-of-stake blockchains such as EOS and Cosmos protect against sybil attacks by only allowing a finite number of identified block proposers who are elected to serve that role. Their permissioning is identity-based and election-based.
Direct proof-of-stake systems use a stake-weighted random block proposer and validator function, which allows them to have an indefinite number of potential block proposers whose incentives are secured by their stakes. Overall permissioning takes the form of having put up stake, and per-block permissioning takes the form of randomness.

Since the power to propose blocks is, in one sense or another, permissioned, it is also scarce and therefore valuable. Therefore, the circumstantial prerequisites of block proposal power may be analogized to ownership of the “means of production” within traditional capitalist economies — a “means of block production,” as it were.

When a single person or group of affiliated persons controls a very large percentage of the means of block production, that person or group also controls the consensus power of the network for most practical purposes, because the blocks proposed by that person or group will outpace those proposed by a minority of block producers and will be accepted and added to the blockchain automatically by the other nodes on the network in accordance with the consensus rules. This gives rise to the notion that consensus attacks on a blockchain, such as the notorious “double spend,” are possible.

The possibility that some person or affiliated group of persons could dominate consensus power reveals that, at least in the short term, the integrity of all blockchain systems depends on an honest “majority” assumption. Depending on the architecture of the protocol, “majority” may mean different things — in some cases even control of less than 50% of the means of block production can effectively provide control over the blockchain system. For example, on the EOS protocol, an honest majority means 2/3rds of block producers are honest, so control of 34% of the block producers would be enough to credibly threaten a consensus attack.

For a blockchain system to be considered legally decentralized, the consensus power, and thus the means of block production, should be decentralized. For example, on EOS, 2/3rds of block producers should be not only honest in practice, but also unaffiliated such that the honesty of each must be and can be tested separately. If it turned out that 2/3rds of EOS block producers were all entities owned by the same parent corporation (or were otherwise closely affiliated — for example, operating under a joint venture agreement providing for shared governance and incentives), the consensus power on EOS would not be decentralized.

Decentralization of consensus power may be less important technically and economically than it is legally. It has been persuasively argued that consolidation of hashpower in proof-of-work systems is unlikely in itself to result in consensus attacks, because the block producers, although powerful, have strong incentives to preserve the value of their capital by maintaining the integrity and neutrality of the system. This could be considered a reason why decentralization of consensus power is not important in assessing when a system is sufficiently decentralized as a matter of law.

For purposes of the law, however, this pragmatic consideration has limited implications. Regulatory law is paranoid and proactive. Thus, it does not merely seek to punish bad behavior by the powerful after they have abused their power, but should impose disclosure and compliance obligations to prevent harm by those who are particularly well positioned to inflict it. For example, under SEC rules, directors and officers of public corporations are not only required to disclose their bad conduct, but are required to disclose their structural conflicts of interest and lawful self-interested transactions.

From a purely legal standpoint, regulations or heightened duties of disclosure and care should apply to affiliated miners or other types of block producers who dominate the consensus power of a network to the point where they could inflict significant damage if they wanted to, even if they have good incentives and in practice have not (so far) abused their power. Thus, consensus power should always be considered in assessing decentralization.

However, in systems with otherwise good cryptoeconomic incentives (such as the non-repurposable sunk capital costs assumed by PoW ASIC miners), concentration of consensus power may be the least worrisome form of concentration of power. Thus, it may be that there can be significant concentration of consensus power, but the system as a whole may still be decentralized if there is competition for the means of block production and the persons who own the means of block production do not also possess a significant amount of other forms of power over the system.

3. Protocol/Client Power

Protocol power refers to the ability of persons to define or influence the blockchain system’s protocol.The protocol is comprised of various rules and procedures, including rules and procedures for determining which version of the blockchain is considered canonical, the circumstances under which new tokens can be minted, the validity and ordering of transactions, the range of allowable scripting logic and other matters defining how the blockchain system should operate.

Client power refers to the ability of persons to change the code of the software clients run by nodes on the network. Client power is closely related to protocol power, because the protocol must be expressed and implemented in the code of the software clients. People who wish to transact on the network must either download and run these clients or (via APIs) route transactions through others who have done so.

Protocol power and client power are theoretically separate. In Bitcoin, BIP 0014 introduced a distinction between the Bitcoin protocol and the dominant Bitcoin client, Bitcoin Core — a distinction that is expressed by creating a separate versioning scheme for the protocol. In practice, however, protocol power and client power tend to blur. For example, the Bitcoin Wiki’s entry on protocol documentation states that “[t]he Bitcoin protocol is specified by the behavior of the reference client,” and the reference client is defined as Bitcoin Core.

Although nodes on Bitcoin and Ethereum are in fact using a variety of clients, each network has a clear dominant client — Bitcoin Core in the case of Bitcoin and Go-Ethereum (Geth) in the case of Ethereum. Developers for these “core” clients have the most funding and influence. Maintainers of the minority clients tend to make conforming changes from the core client without significant political debate. I am unaware of any past situation in which the maintainers of the minority clients, for political or philosophical reasons, affirmatively refused to adopt a protocol change that was implemented by the maintainers of the dominant client. Accordingly, for purposes of testing decentralization, I will discuss protocol/client power as a single form of power.

Protocol/client power tends to be permissioned. For example, only a few individuals have “merge authority” over the official code repositories for Bitcoin Core and Geth. These persons are typically referred to as “core developers,” and I will adopt this terminology going forward. Most of the time, core developers are not expressly acting as agents or fiduciaries of any other person in pursuing their core development work, meaning that they can make changes to the client at their discretion. On the other hand, those individuals may also be funded by other sources of potential centralization — for example, by a “Foundation” which controls all or most of the capital generally available for funding development or by a for-profit company such as Blockstream (for Bitcoin) or ConsenSys (for Ethereum). These funding relationships may create agency-like pressures on core developers even if there is no contractual or equitably imposed agency relationship.

Because protocol/client power is held by core developers, such power may superficially appear very centralized. However, there are at least two very important checks and balances on such power: (1) the clients for most blockchains (including Bitcoin and Ethereum) are free open-source software; and (2) with certain exceptions (such as Tezos), the core developers do not have the power to push a client update to the nodes running the client on the network or otherwise compel persons running nodes to adopt a client update.

The combination of these two factors means that the broader community of people running nodes on the network — including miners, cryptocurrency exchanges, hobbyists, dApp providers and others, who for simplicity I refer to collectively as “users”—also have power. The users must (again, with certain exceptions, such as Tezos) voluntarily and affirmatively accept any new version of the client, and (in theory) have a viable alternative to doing so: They can continue to run the prior version of the open-source client, or can modify the new version of the open-source client to remove any changes that are objectionable and run that modified version. I refer to this countervailing power as “user power,” which is analyzed in a separate section below.

The nuances involved in measuring protocol/client power do not end at pointing out the balance between core developer power and user power. Even without taking user power into account, client/protocol power may be more decentralized if the core developers receive funding from various unaffiliated sources (rather than a single Foundation) and the commit process involves a complicated multisig scheme where keys are held by unaffiliated individuals.

The existence of multiple clients, while it has not to date been a significant catalyst of protocol politics, may operate as a subtle constraint on the discretion of the core developers, since if the maintainers of another client that has substantial popularity dissent, there is a risk of a contentious protocol fork and thus also a contentious network/chain fork.

Fear of potential legal liability for causing users to lose funds, though it has yet to be tested by the courts, likely operates as a similar subtle constraint, which core developers have sometimes expressed being conscious of. Core developers will also tend to care about their reputations, which would be harmed by bad conduct or mistakes.

Just as protocol/client power can be less centralized than it superficially appears, user power may not be as effective of a counterbalancing force in practice as it is in theory. The damage users can suffer from a contentious protocol/network fork mean that those who would like to dissent from a protocol/client upgrade must weigh the value of their dissent against its cost. If the name of the system and/or ticker symbol for the cryptocurrency are trademarked and that trademark is owned by, say, a Foundation, that Foundation has very potent protocol/client power, because it gets to decide legally which version of the protocol/client can use the trademark.

Accordingly, only protocol/client upgrades which are either extremely objectionable to a minority-in-power of users, or are (weakly or strongly) opposed by a majority-in-power of users, will fail to be adopted. Moreover, core developers are free to bundle protocol/client changes together so that users who object to one aspect of the changes will still accept the new version because they agree with other aspects. Finally, many users may be uninformed or apathetic — the classic ‘free rider’ problem — yet, unlike passive stockholders in a corporation, do not have ‘representatives’ advocating for their interest in a fiduciary relationship. These types of factors subtly constrain user power and make user adoption of a client upgrade, by itself, an inadequate measure of protocol/client consensus and legitimacy. Thus, in systems like Bitcoin and Ethereum, core developers’ power is checked by user power only in extreme cases, which is not as good for decentralization as if user power were a potent check on core developer power across the full spectrum of potential protocol/client changes.

Arguably, separation of concerns — separating the governance mechanism from the upgrade mechanism — could deliver better decentralization of protocol/client power. As noted above, Tezos is dissimilar to Bitcoin and Ethereum inasmuch as it allows protocol/client updates to be ‘pushed’ to users, which in itself would seem to be an indicator of centralization. This might make Tezos look more centralized, but Tezos has other checks on protocol/client power — including a less clear division between core and non-core developers and a token-voting mechanism for approving client upgrades. However, the Tezos approach has other disadvantages and has sometimes been described as plutocratic, because it shrinks the class of “users” (as I have defined it) to token holders only, and thus risks sacrificing the possibility of richer political debates accompanying a proposed protocol/client change. For more on this issue, see under “User Power” below.

4. Economic Power

Economic power refers to the ability of persons to affect token price through the funding of research and development or token trading activity.

Although economic power may sound complex and difficult to measure, in practice I believe the main sources of economic power are ownership/control of a sizable percentage of the blockchain system’s native token and ownership/control of capital that was raised and set aside for research, development and/or marketing purposes by selling the token in an ICO, IEO or other similar investment scheme.

An example of a blockchain system with highly concentrated economic power would be MakerDAO, because the Maker Foundation has sold MKR tokens to investors, controls the capital from such sales, controls a substantial percentage of MKR tokens and through such MKR tokens controls parameters of the system that can auction new MKR tokens at any price. An example of a system with somewhat more decentralized economic power would be ZCash, where the development fund is co-governed by a non-profit Foundation and a for-profit technology company, which are legally required to be unaffiliated under the terms of their agreements, and the spending of the fund is managed by a board which is additionally required to have representation that is independent from both the Foundation and the technology company. (Incidentally, the ZCash trademark and logo are also jointly owned by the Foundation and technology company.)

Of all the forms of power over a blockchain system, economic power is the most potent, because it overlaps with the other forms of power. In proof-of-stake systems, economic power may overlap substantially with consensus power. If a person with substantial economic power over a proof-of-work system also has substantial consensus power through ownership of mining ASICs, that person may have much greater control over the system as a whole than would an ordinary dominant miner. Economic power representing control over capital earmarked for the system may also overlap with protocol/client power, since ordinarily he who controls the purse strings for funding the protocol and client also controls the protocol and client themselves. In systems with on-chain governance, economic power may also overlap substantially with both user power and (more directly than through funding mechanisms) protocol/client power.

Accordingly, in any legal test for determining decentralization, economic power should be assessed the most stringently of any of the forms of power over a blockchain system. Thus, while a relatively high concentration of consensus power may be tolerable in a system like Bitcoin while still asserting that Bitcoin is legally decentralized, a similarly high concentration of economic power should not be as tolerable.

5. User Power

User power refers to the ability of persons who do not have a significant amount of consensus power, protocol/client power or economic power to influence or resist those who do have a significant amount of such power. If user power is very strong, then even if the other forms of power are somewhat more concentrated than one might hope, the system may still be decentralized.

In systems without formal governance, like Bitcoin and Ethereum, “user” can have a very broad meaning, and includes, for example, token investors, token holders, companies running dAPPs, hobbyist node operators, small-scale miners, non-core protocol/client developers, other developers or professionals who make their living advising about the system or businesses or governments that use the system as part of their infrastructure.User power primarily takes two forms: (1) moral/reputational rewards and punishments effected through social signalling; and (2) adversarial forking. There are other forms of user power— such as the power of token holders to sell tokens and thus adversely affect price or the power of dApp devs to migrate their users to another blockchain system — but there are also significant costs to such types user power, and, more importantly, not all types of users share those types of user power in common.

Even the relatively brief histories of Bitcoin and Ethereum provide some excellent examples of how powerful users can be. In Bitcoin, the threat of a user-activated hardfork, made credible through a joint exercise of user power and protocol/client power over Bitcoin, was instrumental in activating SegWit on terms different from those struck under the so-called “New York Agreement” by a small group of persons having substantial consensus power and economic power over Bitcoin. This has rightfully been touted as a watershed moment revealing the power of users (see here, here and here). The arguable success and persistence of various adversarial forks from Bitcoin (Bitcoin Cash, Bitcoin Satoshi Vision, et. al.) is likewise a testament to user power in another form — since users who dissented from the triumph of “small-blockers” could fork away and start a system intended to cater more to the payments use case. On the Ethereum side, the persistence of the original Ethereum blockchain as “Ethereum Classic” after TheDAO hardfork shows that user protest to chain reorganizations decided by those with significant protocol/client power can be effective.

In systems like Bitcoin and Ethereum, user power depends on the ability of a wide group of unaffiliated community participants to coordinate with one another. In general, it will require that the protocol/client is fully open source and that core devs do not have the ability to push updates to the client, so that adoption of client changes is voluntary and the threat of an adversarial fork is credible. Ideally, to make the threat of a fork effective, ownership of the brand and ticker symbol for the blockchain should be ‘up for grab’ by users, but other forms of decentralized brand ownership (such as the co-ownership arrangement by two independent organizations observed in ZCash) may also be effective. Other factors, like full nodes being easy to run, and a wide variety of unaffiliated, well-funded businesses being included in the user base, can be very helpful in bolstering decentralization through user power.

However, there are also constraints on user power in systems like Bitcoin and Ethereum — see above under “Protocol/Client Power” for a discussion of some of them. Arguably, Ethereum may have much less user power today than it did at the time of the ETC hardfork, because the dApps built on Ethereum are interdependent. Accordingly, in all but the most egregiously offensive exercises of protocol/client power, major dApp developers, who otherwise could operate as a source of independent user power, will tend to value staying on the same fork as one another more highly than they value asserting their individual political views on the relevant issue.

In systems with formal on-chain governance, user power can assume additional forms, but they tend to belong to only to one category of user: the token holder. In delegated proof-of-stake systems, token holders have voting rights and the analysis of user power can become very complicated.

For example, if token holders can appoint block producers through their user power, consensus power is less centralized because it is constrained by token holders much more directly than Bitcoin users can constrain Bitcoin miners. However, if in such a system economic power is also very concentrated, then most users may actually have less power over consensus than they would in a system like Bitcoin, because a voting-minority is much more ineffectual in a system of formal governance than a vocal moral-minority can be in a system of multi-polar governance. If economic power happens to be concentrated in the hands of those holding substantial consensus power, the formalism of the system can lead to endless rent-seeking under the guise of formalist legitimacy. Similar pros and cons apply to on-chain governance of protocol/client development.

Although the analysis of user power is very complicated, in general it may be said that the broader and more diverse the base of “users” and the more power they have, the more likely a system is to be decentralized under the law.

A Flexible Test for Decentralization

A flexible test for decentralization would consider all the forms of blockchain power referred to above as factors, would assess each factor in light of the detailed facts and circumstances of a particular blockchain system, and would decide whether the system is sufficiently decentralized for legal purposes based on a kind of fuzzy logic about the extent to which each form of power is decentralized and how each form of power relates to the others in each specific case. This is, in effect, a form of lawyerly voodoo, but such tests — the Howey test being an example that is particularly notorious in the blockchain community — are common in the law, and can yield very good results and a degree of predictability as good judges consider cases and build up a body of precedent.

Here is my first stab at a flexible, rich legal test for determining whether a blockchain system is legally decentralized:

General Statement of Test. An Open Network System is sufficiently decentralized if control over that system is widely distributed among independent persons.
Open Network System. An open network system is either:
(a) a peer-to-peer network of free open-source software clients which send, receive, validate and record data states on a distributed ledger in accordance with a protocol that is enforceable and verifiable by operation of the software clients; or
(b) software code which is recorded for execution by clients and recording of operations on the distributed ledger of a peer-to-peer network of the kind described in clause “(a)” (aka a “smart contract” or system of “smart contracts”).
Detailed Statement of Test. In general, sufficient decentralization will be found if, in light of all facts and circumstances, either:
(1) no single person or group of affiliated persons (a “group”) controls any material component of the Open Network System; or
(2) if clause “(1)” is not satisfied — i.e., if a person or group does control one or more material components of the Open Network System (but less than all of the material components)— control over the other material components is widely distributed among un-affiliated persons in a manner that substantially limits the controlling person’s or group’s power to interfere with or alter the Open Network System to directly or indirectly achieve a material benefit for the controlling person or group in a manner that would adversely affect third parties’ rights, powers, privileges, property interests or uses relating to the Open Network System.
‘Material components’ of an Open Network System include, without limitation, the consensus component, economic component, software protocol/client component and user component of the Open Network System.
Rebuttable Presumptions to be Used in Applying the Test
(1) There is a rebuttable presumption that a person or group owning or controlling more than 20% of the native tokens of an Open Network System, or who own or control token-sale proceeds the fair value of which exceeds 20% of the market capitalization of such token, has or have control over the economic component of the open network system.
(2) There is a rebuttable presumption that a person or group owning or controlling enough of the means of block production to violate the ‘honest majority’ assumption applicable to the Open Network System has or have control over the consensus component of the Open Network System.
(3) There is a rebuttable presumption that a person or group controlling a software client used by more than 50% of the validating nodes on the Open Network System has or have control over the protocol/client component of the Open Network System.
(4) For Open Network Systems consisting of smart contracts, there is a rebuttable presumption that a person or group with ‘administrative’ or ‘ownership’ privileges controlling parameter changes, upgrades and/or the minting or burning of tokens has or have control over the Open Network System.

This will typically be a difficult test to meet. And it should be a difficult test to meet. The purpose of finding that a blockchain system is sufficiently decentralized as a matter of law is to declare that since no person controls the system, no person is legally responsible for it and it is not subject to regulations, such as securities laws, that would ordinarily apply in similar circumstances. For this, the blockchain system must essentially be an un-owned, public commons. To qualify as such, it should truly exist for the benefit of and under the control of the public, rather than predominantly serving the interests of any specific person or group. Since power is subtle and omnipresent, a test of power must be rich, probing and comprehensive. One could analogize the difficulty of passing such a test to the difficulty of passing a “strict scrutiny” test under constitutional law.

However, the test is also very flexible and allows for balanced, fact-specific reasoning. Thus, under this test, a judge would be free to consider very nuanced check/balance dynamics such as those I raised in the previous section. For example, a judge would be free to declare that Bitcoin is legally decentralized even if there are facts in evidence showing that ASIC ownership is highly concentrated. After all, the judge could be persuaded that the power of any substantial ASIC owner would be checked by users through the threat of an adversarial fork or massive sale of BTC.

A Bright-Line “Safe Harbor” for Decentralization

Although a broad, conceptual test like the one set forth in the prior section will be the most flexible, accurate and complete method of determining whether a system is legally decentralized, I believe it would be insufficient by itself. Participants in blockchain systems should have more ex ante certainty about how the law applies to them than can be afforded by a complex, “fuzzy logic”, multi-factorial test. Accordingly, it would be highly desirable to propose a bright-line “safe harbor” identifying a subset of systems that are clearly decentralized based on simple facts (or so likely to be decentralized based on those facts that it is not worth regulators’ or judge’s time to undertake a closer inquiry).

Like other safe harbors (for example, the SEC’s “Regulation D”), reliance on such a safe harbor should be non-exclusive — i.e., anyone who wishes to adopt less conservative assumptions should still be free to prove decentralization through the broader, looser, conceptual test set forth in the prior section. It may also be necessary to define different safe harbors in different contexts — for example, a different safe harbor for considering decentralization under the Bank Secrecy Act than the Securities Act of 1933.

Here is a simplified version of the safe harbor I have proposed in the context of the securities laws. The full version of my proposal can be found here, and my open letter to the SEC explaining the rationale behind the proposal was published here. In this proposal, I use the term “Network Maturity” instead of of ‘sufficient decentralization’ because that is the term what was used by Commissioner Peirce in her version of the safe harbor to define the point when the securities laws stop applying to a token. It is also important to note that this safe harbor contemplates that the development team would publish up-front all of the efforts it plans to undertake prior to the point of ‘Network Maturity,’ and that these efforts would either be completed, or waived through governance approvals, prior to and as a condition to achieving ‘Network Maturity’:

Other Tests & Metrics

Other thinkers have suggested other tests and metrics which could either be used on a standalone basis or combined with my tests above to help measure decentralization:

Ketsal Open Standards has proposed a very philosophically kindred approach to measuring decentralization (i.e., break the ecosystem into factors or dimensions and measure decentralization of each), along with additional details on the relevant factors — and, importantly, a lot more quantitative reasoning. Each factor is usefully classified according to whether it affects computational, economic and/or political decentralization. Well worth a read, especially if you like the approach here.
M. Todd Henderson & Max Raskin have proposed a variation on the “efforts of others” prong of Howey, which they call the “Bahamas test.” One version of the Bahamas test goes like this: “If the sellers fled to the Bahamas or ceased to show up to work — like Satoshi Nakamoto — would the project still be capable of existing? If the answer is “yes,” then the risk of fraud is sufficiently reduced such that the instrument is not a security.” ‘Capable of existing’ is not just that there’s a philosophically possible world where it could exist, but rather depends on the relevant barriers to entry and entails an assessment of how realistic it would be for someone to step in and maintain the system. Judge Castel, in his opinion in SEC v. Telegram, used the “Bahamas test” and concluded that the TON Blockchain failed it because Telegram’s efforts were critical.
Jake Brukhman has proposed using the the Banzhaf power index to measure the relative voting power of a member within a DAO. For voting-based governance systems, this could show how decentralized they are by revealing a wide distribution of swing-voting power.
Balaji S. Srinivasan has proposed the minimum Nakamoto coefficient as a simple, quantitative measure of a system’s decentralization, motivated by the well-known Gini coefficient and Lorenz curve. Similar to my tests above, Balaji’s scheme finds a Nakamoto coefficient for each relevant subsystem (clients, developers, token ownership, etc.) in order to determine whether the blockchain system as a whole is decentralized. However, in the process it does lose out on some potential to take un-quantifiable factors into account — for example, the check/balance dynamic among miners, developers and users. In the legal context, Nakamoto coefficients would likely be best used as one important piece of evidence for decentralization, but should not in and of themselves be dispositive of the issue.
In his seminal speech “Digital Asset Transactions: When Howey Met Gary (Plastic)”, William Hinman proposed the “Hinman factors” for measuring when a blockchain system is “sufficiently decentralized”:

Is there a person or group that has sponsored or promoted the creation and sale of the digital asset, the efforts of whom play a significant role in the development and maintenance of the asset and its potential increase in value?
Has this person or group retained a stake or other interest in the digital asset such that it would be motivated to expend efforts to cause an increase in value in the digital asset? Would purchasers reasonably believe such efforts will be undertaken and may result in a return on their investment in the digital asset?
Has the promoter raised an amount of funds in excess of what may be needed to establish a functional network, and, if so, has it indicated how those funds may be used to support the value of the tokens or to increase the value of the enterprise? Does the promoter continue to expend funds from proceeds or operations to enhance the functionality and/or value of the system within which the tokens operate?
Does application of the Securities Act protections make sense? Is there a person or entity others are relying on that plays a key role in the profit-making of the enterprise such that disclosure of their activities and plans would be important to investors? Do informational asymmetries exist between the promoters and potential purchasers/investors in the digital asset?
Do persons or entities other than the promoter exercise governance rights or meaningful influence?
Are the assets dispersed across a diverse user base or concentrated in the hands of a few that can exert influence over the application?
Is the application fully functioning or in early stages of development?

IC3 proposes a voting-bloc-entropy measurement of DAO decentralization
Several computer scientists propose Token-weighted voting, Infrastructure, Governance, Escalation and Reputation (TIGER) as a framework for assessing sufficient decentralization of DAOs.

Rules of Thumb / Shortcuts / Intuition Pumps

Below are a few rules-of-thumb, shortcuts and intuition pumps that might reach similar results to the above formal tests with less legalism and formality:

How difficult or easy would it be for investors who had nothing to do with the project before but have extensive capital (and willingness to engage the right experts with it) to invest heavily in the open network token, wage an “activist investor” campaign and push a new governance or protocol direction for the open network despite the opposition of incumbent leaders/figureheads? (More easy → network is more likely to be sufficiently decentralized — generally. In the case of a protocol that has a hard social consensus against governance changes, like Bitcoin, difficulty in waging an activist campaign could be evidence in favor of decentralization).
Are the initial suppliers of tech talent and capital still highly active, only somewhat active, or not at all active in undertaking activities that could reasonably be expected to drive value to the open network token? If still active, are they coordinating with one another or acting separately? If one or more of them were to openly retire from the project tomorrow, how badly would the token’s value be affected in the short term? Sometimes people call this the “bus test” — are there key people who if they were “hit by a bus” the value and future of the open network would plummet? If so, then the network is less likely to be sufficiently decentralized.

Conclusion

I have done my best to efficiently set forth a reasonable starting point for legally testing when a blockchain system is sufficiently decentralized. However, it is only that — a starting point. A great deal more work is needed by a great many people to gain confidence in testing the existence and effects of decentralization for legal purposes.

Both the flexible test and the safe harbor set forth above in this article are available here. I have no illusions that I have developed a perfect test, and thus would highly encourage anyone interested in this issue — including but not limited to lawyers and coders — to ‘fork my legal code,’ as it were, and suggest alternatives and improvements. Only through such a collective effort will we will arrive at a satisfactory understanding of decentralized blockchain systems under the law.