Governance minimization is the argument that the amount of a protocol a token vote can change should be kept as small as possible – and that for many protocols the right amount is zero. Where the mainstream DAO playbook treats an active governance layer as the goal, governance minimization treats it as a liability to be spent down: every parameter a vote can move is a lever an attacker, a cartel, or a regulator can try to seize, so the most robust protocol is the one with almost nothing left to govern. The position is not anti-governance so much as anti-surface – it asks, of each governable knob, whether the ability to change it later is worth the standing risk that someone changes it against you.
The intellectual root is Vitalik Buterin's 2020 essay on credible neutrality, which argues that a mechanism deciding high-stakes outcomes should be one where, in his words, "just by looking at the mechanism’s design, it is easy to see that the mechanism does not discriminate for or against any specific people." A governable parameter is in tension with that ideal: if a vote can redirect fees, mint tokens, or re-point an oracle, then the mechanism's behaviour depends on who controls the vote, and its neutrality is only as credible as its least-captured election.
a16z's Miles Jennings makes the operational case in “Machiavelli for DAOs” (2024), where governance minimization is the first of four principles for durable DAO design: reduce a protocol's reliance on, and the power of, its governance, because "eliminating all but essential governance would enhance the credible neutrality of a system" and lower the ongoing cost and risk of running it. The same reasoning drives the governance-attack literature: a low-quorum treasury vote or a flash-loaned proposal is only dangerous because there is a powerful lever on the other end of it. Take the lever away and the attack has nothing to grab.
Real protocols sit on a spectrum, not a binary. At the extreme, Liquity shipped its V1 as governance-free contracts with no admin key – every parameter was fixed at deployment and, per its own documentation, the code "can never be changed"; LQTY is explicitly not a governance token. Reflexer's RAI went further and removed its remaining controls in staged "ungovernance" steps until no new collateral types could ever be added. PoolTogether made its V5 core immutable in 2023 and then, in March 2026, had its token holders hand the governance timelock to a contract that can never use it.
A step in from the edge is the "immutable core, governed periphery" pattern. Uniswap's core AMM contracts are non-upgradeable, but UNI holders retain a narrow set of levers, the protocol fee switch and the treasury, so the market itself is fixed while a thin governance layer decides only revenue and grants. Holders pulled the first of those levers when the UNIfication proposal passed on 25 December 2025, with 125m UNI for and 742 against. It turned protocol fees on, starting with v2 and selected v3 pools on Ethereum, sends them to a mechanism that burns UNI, and burned 100m UNI from the treasury; the burn address held 112m UNI on 1 October 2026.
The v2 factory now names a fee recipient, and still names the Uniswap timelock as the only address that can change it, so the fee stays a parameter each later vote can move. Fully governed protocols such as Compound and Aave sit at the far end, where a vote can upgrade the very contracts users' funds sit in. Governance minimization is the claim that, all else equal, a protocol should move toward the immutable end of that line and keep only the governance it genuinely cannot do without.
Even minimizers concede a residue of decisions that resist automation. In practice they cluster into three kinds: protocol upgrades and maintenance (re-pointing an oracle, deploying a fixed contract), complex parameter setting that markets can't self-tune (collateral factors, risk caps), and treasury decisions (diversification, grants, incentives). The minimizer's discipline is to scope the surviving governance tightly – Liquity V2, for instance, keeps a minimal vote whose only power is directing a slice of protocol revenue to liquidity incentives, and nothing else. The design question every DAO eventually faces, as the progressive-decentralization debate frames it, is not "how decentralized are we" but "how much of this should be governable at all," and governance minimization answers: as little as the protocol can survive with.
The cost of destroying a lever is that you can never pull it again. Immutable code that ships with a latent bug cannot be patched, and a parameter that was right at launch can drift out of step with a market that immutability cannot follow – the same property that makes a contract un-capturable makes it un-fixable. Critics argue this trades one risk for another: a governed protocol can respond to an exploit or a black-swan de-peg, an "ungovernable" one can only watch. Minimizers answer that governance is itself the larger and more permanent risk, and that adaptability is better bought through narrowly-scoped, timelocked, veto-guarded levers than through a general-purpose vote over the whole system. Where a protocol should land on that trade-off depends on how much of its behaviour genuinely needs to change after launch – and how much is just a lever waiting to be seized.
Most protocols that pursue governance minimization freeze their contracts but leave their market – prices, issuance, fees – under a vote. A caper minimizes governance at exactly that layer. Its bonding curve is fixed at the layer a member is most exposed to, and the reason is a split between two packages rather than one act of freezing. The curve’s notional cap N is CURVE_CAP, declared in contracts/common/src/lib.rs and asserted by the state tier on every mint and every migration; that package is published with OwnerRole::None, so its code is immutable on-chain and the cap is, in the source’s own words, “a structural invariant no logic version can violate.”
Since a source change on 2 October 2026, the slope constant CURVE_K and the reserve integral cumulative_xrd sit in that package too, and the state tier uses them to check every buy and sell itself: assert_reserve in contracts/core/src/caper_dao.rs aborts a trade that would leave the reserve below what the curve says the circulation is worth (a caper that migrated an existing token is allowed the shortfall its migration created, and no more).
Pricing a trade is still the swappable logic tier’s job, and a governed UPGRADE proposal in the $CAPER caper points the registry at a fresh logic component. So no per-caper majority can reprice the price at which its own members enter and exit, and no runtime setter exists on any tier. An UPGRADE can still change the price a trader is quoted, but it can no longer take the reserve below the curve, whether by paying a seller too much or by minting tokens the reserve does not back. The check ships with the next core redeploy: on the core deployed to Stokenet on 25 September, CURVE_K sits in the logic tier and an UPGRADE can reprice the curve outright.
What remains governable is deliberately narrow and pointed at the treasury alone. The treasury moves only through a small, fixed set of typed, on-chain proposal paths – PAYOUT, INVEST, DIVEST and METADATA, plus UPGRADE, which the contract lets only the $CAPER caper raise – never through arbitrary calldata, and a passed proposal's execution is public: anyone can trigger it, and the treasury badge is presented as a proof inside the call rather than handed to a signer.
In the vocabulary of this page, a caper is minimized by construction rather than spent down over time: the surface any per-caper majority governs is its treasury and nothing more, scoped to the five typed executive kinds – plus, since 5 September 2026, a sixth option kind, DEBATE, which is ranked like the others and can win a tally but executes nothing by construction. It is the mirror of the ossification critique above: because no caper’s own ballot can reach its market, there is no per-caper market lever for anyone to capture, and none to lose to a bug either. The one lever that exists is platform-wide, and pulling it takes a proposal in the $CAPER caper that every caper trades under.