The Centralization of Control

Part one of a dive into emerging defnitions of decentralization, and how it might apply to projects past and future

Despite being a foundational component of what makes a blockchain a blockchain, the concept of “decentralization” remains notoriously difficult to define precisely. Drilling down and defining this and similar concepts and terms are prerequisite for the drafting, revision, and ultimate adoption of a legal and regulatory infrastructure that allows for the industry to operating in the United States and access its markets in an open, legal, and functional way. Sarah Brennan, General Counsel of Delphi Ventures, has been a persistent and leading voice the CryptoLaw/CryptoPolicy universe, and her LinkedIn post back in April (been kicking this around for a while - sorry) “Strategy of a Decentralization Test” took a hard swing at setting out some mechanical standards for what a decentralized system entails. This was followed by “Designing Policy for a Flourishing Blockchain Industry” published by the Decentralization Research Center, which proposes an expanded set of criteria. My goal here is to digest and baby bird this work for you, dear readers, and then follow into some reflection on attempts at decentralization in recent memory by looking at some better known, ostensibly decentralized projects, and finally dive into the discussion surrounding the use of foundations as “wrappers” for decentralized protocols/systems. If this seems like a lot, it is because it is. But, if the goal is operationalizing decentralization in a rules-based manner, and providing a blueprint for builders, counselors, and end users, with thoughtful and meaningful safe-harbors and frameworks for decentralized systems, applications, and the people who use them, this is worth that needs to be done (and discussed). My goal is to get through everything in three posts. So, stay tuned.

tldr

Instead of looking to broad, general conceptions of decentralization, one can look at whether a protocol is: Open, Functional, Autonomous, Permissionless, Non-Custodial, Distributed, Credibly Neutral, and Economically Independent.

With these guideposts, serving as an aspirational benchmark for maximal decentralization, builders, lawmakers/regulators, and users/market participants may be better able to ascertain centralization risk (and adjust accordingly).

Decentralization - A Matter of Control?

Brennan argues that the most effective way to define and test for decentralization is to focus on control – i.e., who has the practical ability to unilaterally influence a blockchain network’s operations or extract value from participants – in a deliberate shift away from more subjective or abstract definitions, such as the SEC’s 2019 guidance, which relies on open-ended, principles-based factors. This broad, vague standard left a lot of room for discretionary enforcement, allowing bad-faith regulators - *cough* Gensler *cough* - to weaponize standards that were ostensibly intended to provide clarity, ultimately undermining the whole point of providing guidance (which should be actionable and reliable). Alternatively, this control-based approach “propose[s] eight criteria… that, if met, would significantly reduce information asymmetries stemming from the control of a blockchain’s token, justifying lower regulatory burdens or exemptions under securities laws.” These attributes are designed to be technology-neutral (applicable to any current or future protocol) and to produce evidence mainly from the network’s architecture (e.g., source code and on-chain data).

Eight Control Criteria

The control-focused approach to evaluating decentralization is boiled down to eight principles or standards, which each target a specific dimension or facet of control or influence. In theory, the more of these principles that a protocol demonstrates, the more decentralized it is:

· Open: The network’s software is open-source and publicly available. Openness of code is foundational because closed-source systems give insiders exclusive knowledge or power; making the code public ensures anyone can run or fork the code and verify how the system works. Open-source intellectual property also prevents a developer or company from using copyright or secrecy to exercise indirect control over the network or its tokenholders.

· Functional: The blockchain must be operational and usable – supporting real transactions or interactions – rather than a mere promise of future functionality. If a network is not yet functional, its value (and the value of any token) remains under the control of the developers’ future actions, which indicates centralization. A live, functional network, by contrast, suggests that the system can run on its own and users can utilize it meaningfully without relying on a centralized party’s efforts to realize promised features.

· Autonomous: The network operates and enforces its rules automatically, based on pre-set code, without the need for human intervention in its ongoing transactions and processes. In other words, the consensus mechanism and core protocol functions run on their own. This autonomy eliminates centralized operational control – no single party should need to “push a button” for the network to function day-to-day. Autonomous networks reduce single points of failure and tampering - even if some nodes or participants go offline, the system continues, which enhances resilience and trustlessness. Notably, this principle doesn’t forbid all human action – upgrades or governance can still involve people – but it requires that any such intervention be constrained by transparent, code-defined rules, checks, and balances.

· Permissionless: No person or coordinated group has the unilateral authority to restrict others from using the network lawfully, meaning anyone can participate in core activities – e.g., deploying applications or smart contracts, running a node or validator, transacting on the network, and participating in governance – without needing approval from a centralized gatekeeper (or cabal of gatekeepers). A permissionless network prevents any choke-point that could censor users, exclude competitors, or unilaterally benefit certain persons or groups or persons. If a tokenholder’s ability to use or govern the network can be individually restricted by some authority, that holder is subject to significant control-related risks, as Brennan notes, because the authority could discriminate or extract rents. Truly permissionless access, by contrast, creates an open playing field and allows the network to organically grow and decentralize over time. The over-time piece being an important note, where many if not all projects might not start fully permissionless on day one due to security concerns. This criterion could then be met by over time when insiders exit positions of influence or control, shepherding the network towards decentralization.

· Non-Custodial: Users retain total independent control over their assets and tokens; the network’s design does not require entrusting one’s private keys or funds to any intermediary. In a non-custodial system, only the users themselves can move or manage their tokens, with cryptographic keys, and any third-party service providers cannot unilaterally affect those assets. This principle aligns with the core crypto ethos of self-custody. If a protocol required users to give control of tokens to a central operator (even temporarily), that operator would wield significant power (and legal responsibility). Brennan points out that U.S. financial regulations likewise recognize this distinction – for example, mere software providers or communication networks are not deemed intermediaries so long as they never take control of customer assets. Ensuring non-custodial design thus not only protects users but also clearly delineates the system as decentralized infrastructure rather than a custodial service.

· Distributed: Control and ownership in the network are broadly distributed such that no single person or small group under common control can unilaterally change the network’s rules or dominate its token supply or voting power. This criterion has two quantitative prongs: (a) no person or affiliated group should have unilateral technical authority to alter the protocol or its consensus rules; and (b) no person or group should beneficially own or be able to vote more than a certain threshold of the total token supply (Brennan suggests on the order of 10–20%). The core idea is to prevent any would-be “controller” from holding a concentration of tokens that gives de facto control. This distribution test directly targets the risk of outsized influence or collusion: if one person (or cabal of persons, whether natural or legal) can alter the network or holds, say, 50% of tokens, then other participants face information asymmetries and conflict of interest risks akin to a traditional centralized company. By driving token holdings below some threshold (say ~20% like Brenna suggests), there is greater assurance that the network’s value and governance are not captive to any given insider or set of insiders. This standard draws from established legal notions of control (looking in particular to ’34 Act insider disclosures) and the FIT 21 Act proposed a 20% decentralization threshold.

· Credibly Neutral: The network’s code and rules do not grant special advantages or hard-coded privileges to any specific person or group; all similarly situated participants are treated equally by the protocol. Credible neutrality means the system can’t be easily manipulated to favor insiders or punish certain users. For example, there should be no “backdoor” admin keys that allow the developers to freeze others’ assets, and no permanent governance veto rights reserved for founders. Brennan emphasizes that credible neutrality is a hallmark benefit of open blockchain networks, distinguishing them from corporate platforms that might discriminate or extract value arbitrarily. When neutrality is achieved, users can trust that the network won’t unfairly change the rules against them – the protocol commits to a level playing field. If neutrality is lacking (say developers retained an override switch), it “pits one user/use case against others” and undermines the openness that fosters broad participation and competition. This criterion is an intersection with others (open source, permissionlessness, etc.) resulting in “credible neutrality” once avenues for favoritism or hidden control have been removed (or never existed in the first place).

· Economically Independent: The network has in place mechanisms that link the token’s value to the actual usage and success of the network, rather than to the efforts of a single company or promoter. In practice, this means the core protocol has implemented features like: (a) native utility for the token (e.g., the token is used to pay for network fees or services); (b) algorithmic supply adjustments or burn mechanisms tied to network activity; or (c) automated distribution of fees/proceeds generated by the network to tokenholders or into the protocol’s treasury. This way, the token’s economic value is derived from the network performance which “squares” the expectations of profit with the reality of a functional network, reducing information asymmetry and reducing reliance on a central team’s promises and promotional efforts. Brennan notes that implementing a robust token economy can help distinguish the token from a traditional security or a “convertible virtual currency” in the eyes of regulators, because the token is no longer just a stake in a company’s (founders’) efforts, it is an essential and integral part of a self-governing network’s value flow.

A Workable Standard? At the Very Least, a Good Start

Brennan does not insist that every blockchain project must satisfy all eight criteria at all times. She recognizes that different types of projects (layer-1 protocols vs. small dApps, early-stage vs. mature networks) may decentralize along different timelines or emphasize different aspects. Accordingly, this framework is meant to be applied flexibly or partially, but with criteria/principles providing an aspirational benchmark for maximal decentralization. If a project can show it meets these tests, Brennan contends, it should justifiably be treated as decentralized legal, regulatory, and policy purposes (e.g., regulators could deem its token not a security or exempt it from certain compliance burdens) because the traditional risks associated with centralized actors (fraud, information asymmetry, insider control of value) are sufficiently mitigated.

The key to my mind is that verification of decentralization should rely on publicly observable facts (source code, on-chain data) with “additional transparency through mandatory disclosures when necessary.” That way, projects are incentivized to adopt structures at the technical and legal levels to maximize transparency in form, function, and governance. Decentralization is not just a technical state, but a process that benefits from sunlight and clarity – reducing information asymmetry and promoting incentive-aligned, functional utilities.

What kind of lawyer would I be without a disclaimer?

Everything I post here constitutes my own thoughts, should only be used for informational purposes, and does not constitute legal advice or establish a client-attorney relationship (though I am happy to discuss if there is something I can help you with). I can be reached via email at dlopezkurtz@crokefairchild.com, on telegram @davidlopezkurtz, on twitter @lopezkurtz, and on LinkedIn here.