Progressive decentralization is the idea that a crypto protocol should not launch as a fully-formed DAO, nor stay a company forever, but move from one to the other in stages — a founding team relinquishing control "by degrees, over time." The term was coined by Jesse Walden of a16z in January 2020, and it has since become the default mental model for how a startup becomes a community-owned network. It is less a single mechanism than a sequencing discipline: which control to give up, and crucially, when.
The playbook: product first, then community, then control
Walden's playbook is three ingredients delivered in a strict order. First, product/market fit — built by a small core team with full control, because a protocol nobody uses has nothing worth decentralizing. Second, community participation — economic incentives that turn users into contributors who maintain and extend the protocol. Only third, once the social and economic dynamics have stabilized, does the team pursue sufficient decentralization: distributing tokens and governance rights widely enough that the network runs without them.
The ordering is the whole point. Walden argues that attempting the three at once, or decentralizing before there is a product worth governing, leaves a project "stuck" — a treasury and a token-holder base arguing over a thing that has not yet proven it should exist. The canonical worked example is Compound, which shipped a lending product, then a governance token and on-chain voting, and only then let the team fade into one voice among many. The reverse — governance before product — is one of the recurring patterns in how DAOs fail.
Why the sequence is also a legal argument
Progressive decentralization is not only product advice; it is a regulatory strategy. Under the US Howey test, an asset is an investment contract (a security) when buyers expect profit "from the efforts of others." A token sold by a small team that controls the roadmap looks a great deal like that. The industry's counter-argument traces to former SEC official William Hinman's 2018 speech, which floated the notion that a token can start as a security and later cease to be one once the network is “sufficiently decentralized” — at which point "the efforts of others" no longer meaningfully drive its value.
That single idea does a lot of work. It reframes "hand over control" from a nice-to-have into the event that (in theory) transmutes a token from a security into a commodity, and it is why so many teams pair a progressive-decentralization roadmap with a legal wrapper — a foundation or association that can hold the keys during the awkward middle. The obvious hazard is optics-as-substance: Walden's own warning is that "faking autonomy is a quick way to undermine trust," and regulators have been increasingly willing to look past a governance forum to ask who actually holds the upgrade key.
Decentralization is not all-or-nothing
A useful refinement came from Jad Esber and Scott Duke Kominers (a16z, 2023), who point out that decentralization "needn't be all-or-nothing." They break a protocol into minimum decentralizable units — the core team, external contributors, the technology stack, finance, and internal processes — each of which can be slid toward community control at its own pace. A team might open-source its contracts and hand the treasury to a token-holder vote long before it lets go of, say, the frontend or the trademark.
The honest reading of the framework is also its sharpest critique. If every dimension has its own slider, a team can leave the load-bearing ones — contract upgradeability, the admin multisig — pulled firmly toward "centralized" while advertising the token vote as proof of decentralization. Critics call the result regressive or theatrical decentralization, and it is the gap between a governance forum and a credible exit right that usually reveals it: if holders who lose a vote cannot leave with their share, and the team can still upgrade the contract, control never actually moved.
The other road: governance minimization
Progressive decentralization assumes a protocol needs an ongoing governance layer and the only question is who runs it. A rival school argues the opposite: the safest governance surface is a small one, and the destination is not a vibrant DAO but a protocol with almost nothing left to govern. Liquity shipped its V1 as immutable contracts with no admin keys at all — there was never a control key to progressively hand over. Reflexer's RAI went further and removed governance in staged "ungovernance" levels until no new collateral types could ever be added.
Read side by side, the two roads answer the same anxiety — that a token vote is a large, permanently exploitable attack surface — in mirror image. Progressive decentralization distributes the keys; governance minimization destroys them. Most real protocols land somewhere in between, keeping a guarded lever or two (a security council, a parameter steward) behind timelocks and vetoes. The design question every DAO eventually faces is not "how decentralized are we" but "how much of this should be governable at all."
How Caper approaches this
Caper sidesteps the progressive-decentralization journey by not starting centralized. A caper is a single immutable Scrypto component: there is no founder upgrade key, no admin multisig, and no treasury wallet to relinquish later — so there is no control-key handover to sequence, and none of the securities-optics of a "we'll decentralize eventually" roadmap. The founder's only lasting privilege is economic (a front-loaded slice of each buy's XRD), not a control lever.
Its governance surface is deliberately small and fixed at genesis. The treasury lives in a protocol-controlled vault that moves only through five typed, on-chain proposal paths — PAYOUT, INVEST, and VOTE — and never through arbitrary calldata, and anyone can trigger a passed proposal's execution (the execute entrypoints are public; the treasury badge is presented as a proof inside the call and never leaves its vault). In the vocabulary of this page, that is closer to governance minimization from day one than to progressive decentralization: rather than promising future decentralization, a caper simply never concentrates the load-bearing keys in the first place. What weight a holder does carry is earned, not merely bought — a member's vote weight and their exit share are the same soulbound-anchored figure (t·v)/(V·T), where v is a non-transferable, soulbound proof-of-vote record. Stake still counts — t is a multiplier — but the decisive part cannot be acquired on an exchange, so there is no key, and no bag, that buys the protocol outright.
References
- Jesse Walden — “Progressive Decentralization: A Playbook for Building Crypto Applications” (a16z, 2020)
- Jad Esber & Scott Duke Kominers — “Progressive decentralization: a high-level framework” (a16z, 2023)
- William Hinman — “Digital Asset Transactions: When Howey Met Gary (Plastic)” (SEC, 2018)
- The Howey Test (SEC / Investor.gov)