Progressive Decentralization

What Is Progressive Decentralization?

Progressive decentralization is a strategy for building blockchain protocols and applications where a founding team retains centralized control during early development, then systematically transfers authority to a distributed community of users, token holders, and contributors over time. Rather than attempting to launch a fully decentralized system from day one, teams deliberately sequence the handoff of power in stages.

The concept was popularized by Jesse Walden, formerly of a16z crypto and founder of Variant Fund, in a 2020 essay that outlined a practical playbook for crypto founders. Walden argued that most successful crypto applications need centralized leadership early on to iterate quickly, fix bugs, and find product-market fit. Attempting full decentralization before the product works creates a system that is both slow to improve and unlikely to attract users.

The approach draws an important distinction: decentralization is a spectrum, not a binary state. A project can be centralized in some dimensions (development, infrastructure) while being decentralized in others (asset custody, transaction validation). Progressive decentralization provides a framework for moving along that spectrum deliberately.

How It Works

The progressive decentralization framework divides a project's lifecycle into three overlapping phases. Each phase shifts more control from the founding team to the broader community.

Phase 1: Product-Market Fit

In the earliest stage, the founding team operates much like a traditional startup. They control the codebase, deploy smart contracts with admin keys, manage infrastructure, and make all product decisions unilaterally. The priority is building something people want to use.

During this phase, centralized control is a feature, not a bug. The team can ship updates daily, respond to security incidents in minutes, and pivot the product direction based on user feedback. Attempting governance votes for every parameter change at this stage would be paralyzing.

• The team controls contract upgrades and protocol parameters
• Infrastructure runs on team-managed servers and nodes
• Revenue and treasury remain under team control
• Users interact with the product but have no formal governance role

Phase 2: Community Participation

Once the product demonstrates traction, the team begins distributing ownership and decision-making power. This typically involves launching a governance token and establishing formal governance processes.

Token distribution is the critical mechanism. Teams allocate tokens to early users, developers, liquidity providers, and community contributors through a combination of airdrops, liquidity mining programs, and grants. The goal is distributing tokens to people who actively use and contribute to the protocol, not just speculators.

• Governance token launch with distribution to active users and contributors
• Community votes on protocol parameters (fees, incentive allocations, integrations)
• Grant programs fund independent development and ecosystem growth
• The team retains veto power or emergency controls during the transition

Phase 3: Sufficient Decentralization

In the final phase, the community assumes full control. The team relinquishes admin keys, removes upgrade privileges, or transfers them to a multisig controlled by elected community members. The protocol operates as a decentralized autonomous organization.

"Sufficient decentralization" does not mean the founding team disappears. Team members typically remain as contributors, but they hold no more power than any other token holder. Governance proposals, treasury allocations, and protocol upgrades all require community approval through on-chain voting.

• Admin keys burned, transferred to community multisig, or governed by timelock
• Protocol upgrades require on-chain governance votes
• Treasury managed by community-elected delegates or direct voting
• The founding team participates as regular contributors and token holders

Why Teams Choose This Path

Several practical constraints make progressive decentralization attractive compared to launching fully decentralized from inception.

Regulatory Strategy

In 2018, SEC Director William Hinman argued that a digital asset might start as a security but cease to be one once its network becomes "sufficiently decentralized." He pointed to Ethereum as an example: ETH may have been sold as a security during its initial offering, but by 2018 the network had decentralized enough that ongoing sales were not securities transactions.

This framework gave crypto projects a roadmap. By starting centralized and progressively decentralizing, teams could potentially move their tokens from securities to non-securities status. While this interpretation remains contested and Hinman's remarks were not formal SEC guidance, it has heavily influenced how projects structure their token launches and governance transitions.

Development Speed

Decentralized governance is inherently slower than centralized decision-making. A governance proposal might take days or weeks to pass through voting, while a centralized team can ship a fix in hours. Early-stage protocols need the ability to iterate rapidly, respond to exploits, and adjust parameters based on real-world usage data.

Bootstrapping Network Effects

Protocols face a cold start problem: they need users to generate value, but users only come when value already exists. Centralized teams can subsidize early activity, negotiate partnerships, and make strategic decisions that a diffuse community cannot coordinate on. Once network effects take hold, community governance becomes viable because the protocol generates value independently of any single team.

Notable Examples

Uniswap

Uniswap launched in 2018 as a simple automated market maker built by a small team. In September 2020, the team distributed UNI governance tokens through a retroactive airdrop to all past users, giving 400 UNI to every address that had ever used the protocol. Governance was then transferred to UNI token holders, who vote on treasury grants, fee switch activation, and protocol upgrades. Research from the University of Oxford found that Uniswap's distribution approach produced relatively broad governance participation, with the top five addresses controlling approximately 12% of voting power.

Compound

Compound introduced the COMP governance token in 2020, distributing tokens to users who supplied or borrowed assets on the protocol. COMP holders govern interest rate models, asset listings, and protocol parameters. Compound was among the first DeFi protocols to implement formal on-chain governance and served as a template for many subsequent projects. However, analysis showed higher concentration: the top five addresses held over 42% of voting power, illustrating how token distribution design directly shapes governance outcomes.

MakerDAO

MakerDAO, the protocol behind the DAI stablecoin, is one of the longest-running examples. Originally governed by the Maker Foundation, it progressively transferred control to MKR token holders before the foundation formally dissolved in 2021. MKR holders now govern collateral types, stability fees, and risk parameters for the entire system. The transition took approximately four years from token launch to foundation dissolution.

Use Cases

Progressive decentralization applies broadly across crypto infrastructure, not just DeFi protocols.

• DeFi protocols: lending platforms, DEXs, and stablecoin issuers use it to transition from team-managed parameters to community governance
• Layer 2 networks: Bitcoin and Ethereum scaling solutions often launch with a limited operator set and plan to expand to permissionless participation over time
• Infrastructure protocols: oracle networks, bridges, and data availability layers start with curated node operators before opening to broader participation
• NFT platforms and social protocols: marketplaces and social networks distribute governance to creators and users who generate the platform's value

Bitcoin Layer 2 Networks

Progressive decentralization is particularly relevant for Bitcoin Layer 2 networks. These protocols often require a trusted operator set at launch because their security models depend on coordinated key management, transaction ordering, or state validation. Spark, for example, currently operates with a small set of operators using FROST threshold signatures in a 1-of-n trust model where any single honest operator protects user funds. The design accommodates expanding the operator set over time without requiring protocol changes, allowing the network to progressively decentralize as it matures. Users retain self-custody and unilateral exit rights regardless of operator behavior, providing a security floor even during early centralized phases.

Governance Minimization

A related concept is governance minimization: the idea that the best outcome is not maximum governance participation, but reducing the number of decisions that require governance at all. Under this view, progressive decentralization should aim to make the protocol increasingly autonomous and self-executing, minimizing the attack surface that governance introduces.

Governance introduces risks: token holder capture, voter apathy, and governance attacks where adversaries accumulate enough tokens to pass malicious proposals. A protocol that requires fewer governance decisions is more resilient than one that requires votes on every parameter. Progressive decentralization, when combined with governance minimization, aims to transition from team control not to community voting on everything, but to a state where the protocol runs with minimal human intervention.

Risks and Considerations

The "Never Decentralize" Problem

The most common criticism of progressive decentralization is that it provides cover for teams that never intend to give up control. Without binding commitments or timelines, "we'll decentralize later" becomes an indefinite promise. Critics point to projects that have maintained admin keys and centralized control for years while claiming to be on a decentralization path.

Evaluating a project's commitment requires examining concrete actions: Are admin key privileges being reduced over time? Is token distribution broadening? Are governance decisions actually being made by the community? Roadmap promises without measurable milestones are a red flag.

Token Distribution Challenges

How tokens are distributed determines whether governance is genuinely decentralized or controlled by insiders. Token vesting schedules for founders and investors often concentrate voting power in early hands. If the team and venture capital backers hold a majority of tokens, governance is decentralized in name only.

Walden himself noted that projects began "speed running" the phases, launching tokens before achieving product-market fit or building a real community. This attracted speculators rather than users, producing governance systems where most token holders have no interest in participating.

Regulatory Uncertainty

The legal status of progressive decentralization remains unsettled. While Hinman's 2018 remarks suggested a path from security to non-security status, subsequent SEC leadership expressed skepticism about project decentralization claims. The SEC sought to distance itself from Hinman's remarks during the Ripple litigation, arguing they were not official agency guidance. Projects relying on progressive decentralization as a regulatory strategy face ongoing legal uncertainty.

Security During Transition

The transition period between centralized and decentralized control creates unique security risks. Admin keys that will eventually be burned still exist today. Emergency controls designed for the founding team may be exploited if compromised. Governance systems with low participation are vulnerable to governance attacks by well-funded adversaries.

Projects must carefully manage the security tradeoffs at each phase: too much centralization creates single points of failure, while premature decentralization removes the ability to respond to incidents quickly.

Measuring Decentralization

There is no universal standard for measuring decentralization. Different dimensions matter: token distribution, node operation, development activity, governance participation, and infrastructure dependencies. A project can be decentralized in token holdings but centralized in development, or have distributed validators but a single front-end provider. Academic researchers have proposed frameworks like Balaji Srinivasan's Nakamoto Coefficient, but no single metric captures the full picture.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.