Progressive Decentralization: A Three-Stage Model for Web3 Founders

TL;DR

• a16z's Progressive Decentralization model has three stages, adapted for crypto by combining with Paul Graham's Founder Mode framework.
• Stage 1: Product-market fit. Centralized, founder-controlled, fast iteration. Move when the protocol is real and growing.
• Stage 2: Community development. Transitional, moderated control, governance vehicle live. Move when the community is large enough to take meaningful decisions.
• Stage 3: Sufficient decentralization. Distributed governance, founder steps back, regulatory clarity. Move when the protocol can survive the founders quitting.
• Common failure modes: decentralizing too early (no PMF, governance attacks possible) or too late (regulatory exposure, founder bottleneck, brain drain). Most teams err on one side or the other; few hit the timing right.
• Real reference protocols: Uniswap (~3 years from launch to V3 governance), Aave (similar arc), Compound (similar arc), Beanstalk (counterexample: decentralized too early, $182M governance attack via flash loan).

Why this matters

Progressive decentralization is the single most contested operational decision in Web3. The team that runs the protocol is also the team that wrote the smart contracts, ran the early operations, and currently makes most of the decisions. They are simultaneously:

• The protocol's biggest asset (their judgment, their relationships, their roadmap clarity).
• The protocol's biggest liability (regulatory exposure, single point of failure, governance centralization).

Moving from "team controls everything" to "community controls everything" is a multi-year process. Done right, the protocol survives generations of contributors. Done wrong, the protocol either ossifies under founder control or collapses to governance attacks before the team has built the safeguards.

If you're a founder, this article is the framework that prevents most of the failure modes. The framework comes from a16z's 2020 essay, refined through five years of observed protocol arcs.

The three stages

Stage 1: Product-market fit

You have a protocol idea. You're shipping fast, iterating based on user feedback, making most decisions yourself or in a small team. Centralization is a feature; you can change anything in days.

What this looks like:

• Smart contracts are upgradeable or multi-sig-controlled. The team can patch bugs, add features, change parameters.
• Decisions are made by the founders + a small core team. No formal governance.
• The token (if any) is held mostly by the team and early backers; it has no real on-chain power.
• Communication is direct: Discord, Telegram, a small community.

When to stay in Stage 1: until you have meaningful TVL, real users, and a genuine product-market signal. Most protocols try to leave Stage 1 too early.

What "meaningful PMF" means depends on the category. For DEXes: $10M+ daily volume sustained for 3+ months. For lending: $50M+ TVL with active borrowers. For NFT marketplaces: thousands of weekly active traders. The thresholds matter less than the durability: PMF is when you can stop pumping the protocol and it keeps growing.

Stage 2: Community development

You have PMF. The protocol is real. Now you start handing decisions to the community.

What this looks like:

• Token distribution begins. Liquidity mining, airdrops, contributor rewards.
• Governance vehicle launches (Snapshot for off-chain signaling, Compound Bravo / OpenZeppelin Governor for on-chain execution).
• Some parameters are now governance-controlled (interest rate models, fee switches). Others remain admin-controlled (security pause, oracle source).
• Community proposals begin. Most are ignored or rubber-stamped by the team initially; the practice of governance is more important than the substance.
• The team is publicly accountable for decisions but still effectively in charge.

This stage typically lasts 12-24 months. The team is teaching the community how to govern, while retaining most operational control. The token has utility (governance) and may have value (fee accrual, opt-in fee switch).

When to stay in Stage 2: until the community has demonstrated it can make non-trivial decisions without devolving into chaos. Specifically: a controversial governance proposal has been resolved through community discussion, with a meaningful turnout (typically 5%+ of token supply voting).

When to leave Stage 2: when the community's governance capability matches or exceeds the team's operational capability. This is rare; most teams stay in Stage 2 for years.

Stage 3: Sufficient decentralization

The community owns the protocol. The founders, if they're still around, are contributors not controllers. Decisions are made on-chain through governance.

What this looks like:

• Smart contracts are immutable or governance-only-upgradeable through long timelocks (usually 7+ days).
• The team holds a meaningful but not controlling stake (typically 10-25%, down from 30-40% at launch).
• Operational power is decentralized: validators, liquidators, keepers, monitors are all third parties.
• The team can quit and the protocol survives.

This is the regulatory test the SEC and similar agencies have been using to distinguish "a centralized financial product" from "a decentralized network". Sufficient decentralization is also the legal target.

Reaching this stage takes 3-7 years for most protocols. Many never reach it. Some shouldn't (small protocols don't need full decentralization; they need to be acquired or sunset).

When to move from Stage 1 to Stage 2

The signal: PMF is real, the team is starting to bottleneck.

Concrete indicators:

• Daily user count is in 5-figures, growing.
• TVL is in 8-figures, sustained.
• Outside contributors are submitting meaningful PRs, not just typo fixes.
• Decisions are being made faster than the team can deliberate them.

When you cross these, launch the governance vehicle. Initially, it does almost nothing (the team still decides), but the infrastructure is in place. Token distribution begins shortly after.

Common mistake: launching the governance vehicle before PMF. The early users of any governance system are speculators, not protocol stakeholders. They optimize for short-term token price, not long-term protocol health. A pre-PMF governance vehicle is a magnet for proposals that don't help the protocol.

When to move from Stage 2 to Stage 3

The signal: the community has shown it can govern.

Concrete indicators:

• Multiple controversial proposals have passed through governance with meaningful turnout (5%+ of supply).
• Key technical contributors (engineers, security researchers, ops) are paid by the protocol's treasury through governance, not by the founding team.
• Outside legal counsel agrees the team's operational role no longer constitutes "control" under relevant securities laws.
• The protocol's revenue covers operating costs, freeing the team from financial pressure.

When you cross these, you can transition meaningfully. The team's role shifts from "controllers" to "service providers": they propose changes, run grant programs, write specifications, but execute through governance like any other contributor.

Common mistake: staying in Stage 2 indefinitely. Founders often justify continued centralization with "the community isn't ready". Sometimes true, often a rationalization. The community gets ready by being given responsibility; never giving it ensures they never get ready.

Failure modes at each transition

Failure: decentralizing too early

The Beanstalk case is canonical. Beanstalk launched in 2021 as a decentralized stablecoin protocol. By April 2022, governance was on-chain with low-friction proposal/execution. An attacker flash-loaned $1B+ in governance tokens, acquired 67% of voting power, passed a malicious proposal that drained $182M from the protocol's treasury. Total elapsed time: under one block.

What went wrong: Beanstalk decentralized governance before it had the safeguards (timelocks, supply caps, snapshot-based voting) needed to prevent flash-loan attacks. The protocol was too small for the decentralization model it had adopted.

The fix: timelocked governance (changes execute after 7+ days, allowing time for response), snapshot-based voting (vote weight locked at proposal time, not execution time), and minimum delegation thresholds. Beanstalk eventually rebuilt with these and recovered, but the damage was done.

Failure: decentralizing too late

The opposite pattern is less catastrophic but more common. Founders maintain Stage 1 control for years past PMF. The community grows frustrated. Key contributors leave. The protocol stagnates.

What this looks like in practice:

• Launches feel like consultations: "we're going to do X, what do you think?", followed by X regardless of community input.
• Treasury decisions are opaque or unilateral.
• Critical contributors (auditors, validators, infrastructure) are friend-and-family deals, not openly bid.
• Forks emerge with superior community ownership, drawing users away.

The fix is harder than launching governance: you need to actually transfer power. Founders have to write fewer commits, attend fewer decisions, and let the community make some calls badly. The community learns by doing, which means by failing some.

Failure: stuck in Stage 2

A surprisingly common pattern: governance launches, lasts a year, no one votes. The team continues making all decisions, now with the appearance of community legitimacy but none of the substance.

This is sometimes called "governance theater". The fix: meaningful proposals that the team explicitly does NOT pre-approve, with active campaign work to drive turnout. Push the community to vote on something controversial, accept the result, demonstrate that governance matters.

Real protocol case studies

Uniswap

• 2018: launch (Stage 1).
• 2020: V2 launch + UNI airdrop (move to Stage 2).
• 2021-2024: governance experiments, Uniswap Foundation, university delegate programs (deepening Stage 2).
• 2024+: ongoing fee switch debates as test of community decision-making capacity.
• Currently: late Stage 2, with meaningful but not yet sufficient decentralization.

Uniswap is the textbook case of careful staging. Each transition took years; the team avoided rushing.

Aave

Similar arc. ETHLend → Aave V1 (2020, Stage 1) → token migration + governance launch (late 2020, Stage 2) → safety module + multiple V2/V3 protocol updates through governance → V4 launch with $1.5M security spend (covered in the security budget article).

Aave is in late Stage 2; the safety module gives the protocol survivability beyond founding team, which is a Stage 3 indicator.

Compound

Similar to Aave but slightly faster. Launch (Stage 1, 2018) → COMP token + Compound Bravo (2020, Stage 2) → V3 (Comet) launch with deeper community involvement.

Beanstalk (counterexample)

Skipped Stage 2 community-development and went directly to high-throughput on-chain governance in Stage 1. Result: $182M flash-loan governance attack. The protocol survived after a community-funded restart, but the failure pattern is etched into the framework: don't skip Stage 2.

Related questions

What's the right token distribution for each stage? Stage 1: team and seed investors. Stage 2: add airdrops, liquidity mining, public sale (if any). Stage 3: more decentralized over time, with circulating-vs-locked supply approaching circulating-vs-circulating.

Should the team multisig dissolve in Stage 3? Not necessarily. Many Stage 3 protocols keep a multisig for security pause and emergency response, with timelocked governance for everything else. The multisig is a pragmatic concession, not a violation of decentralization principles.

How do I balance speed in Stage 1 with the need to set up governance vehicle in Stage 2? Don't optimize. Stage 1 is for shipping. The governance vehicle launches when you have something to govern. Most teams launch governance too early and regret it; very few launch too late.

What about VC-backed protocols where investors want fast token distribution? Investor pressure to launch tokens early is real, but flexibility exists in cliff schedules (no liquidity for 12-24 months) and milestone-based unlocks. Use these. Tokens that unlock to investors before PMF distort the protocol's economics.

Does this framework apply to non-DeFi protocols? The principle (incremental power transfer) generalizes. The specifics (governance attacks via flash loans) are DeFi-specific. NFT projects, infrastructure, gaming all face progressive decentralization but with different risks at each stage.

Where to see this in Academy

eMBA Module 2 (Building and Leading a Protocol Team) Lessons 1-2 cover the Founder Mode → Governance Mode transition in depth, including a worked example of the Stage 1 to Stage 2 decision for a hypothetical protocol. The lesson reframes Paul Graham's Founder Mode (a Web2 framework about CEO involvement) for the Web3 context where "Governance Mode" replaces "Manager Mode".

Module 1 Lesson 5 (Monolithic vs Modular) connects to this: protocols that ship in modular pieces can transition each piece's control independently, which gives more flexibility in staging than a monolithic launch allows. The core-with-replaceable-modules architecture (canonical for many DeFi blue-chips) was partly designed to enable this.

The right mental model: progressive decentralization is the protocol's analog of corporate succession planning. You're transferring control from the founders to the community over time. Done well, the protocol outlives any specific contributor. Done badly, the protocol is trapped in founder dependence or destroyed in a governance attack.