---
title: "Governance minimization"
url: "https://caper.network/wiki/dao-governance/concepts/fundamentals/governance-minimization"
updated: 2026-09-06
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Governance minimization

|  |  |
| --- | --- |
| **Topic** | The design school that a protocol's safest governance surface is the _smallest_ one — shrink what a token vote can change, ideally toward nothing |
| **Also called** | Minimal governance, governance-free design, "ungovernance," ossification |
| **Core claim** | Every governable parameter is a permanent, exploitable attack surface; removing the parameter removes the attack |
| **Theoretical root** | Vitalik Buterin's [credible neutrality](https://balajis.com/p/credible-neutrality) (2020); named the first of four principles in a16z's [“Machiavelli for DAOs”](https://a16zcrypto.com/posts/article/machiavelli-principles-dao-decentralized-governance/) (2024) |
| **Spectrum** | Fully immutable ([Liquity](/wiki/daos/stablecoins/liquity) V1, [Reflexer RAI](/wiki/daos/stablecoins/reflexer-rai)) → minimized core + governed periphery (Uniswap) → fully governed (Compound, Aave) |
| **Key risk** | Immutable code cannot be patched — a latent bug or a stale parameter becomes permanent |
| **Mirror image** | [Progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) distributes the keys; governance minimization destroys them |

**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 theory: credible neutrality and governance as attack surface

The intellectual root is Vitalik Buterin's 2020 essay on [credible neutrality](https://balajis.com/p/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”](https://a16zcrypto.com/posts/article/machiavelli-principles-dao-decentralized-governance/) (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](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) 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.

## The spectrum, from immutable to minimally governed

Real protocols sit on a spectrum, not a binary. At the extreme, [Liquity](/wiki/daos/stablecoins/liquity) shipped its V1 as [governance-free](https://www.liquity.org/features/governance-free) contracts with no admin key — every parameter was fixed at deployment and, per its [own documentation](https://docs.liquity.org/v2-faq/general), the code "can never be changed"; LQTY is explicitly not a governance token. [Reflexer's RAI](/wiki/daos/stablecoins/reflexer-rai) went further and _removed_ its remaining controls in staged "ungovernance" steps until no new collateral types could ever be added.

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 — most famously the [protocol fee switch](https://developers.uniswap.org/docs/ecosystem/governance/overview) and the treasury — so the market itself is fixed while a thin governance layer decides only revenue and grants. 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.

## What governance usually can't eliminate

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](/wiki/dao-governance/concepts/treasury/dao-treasury-management) 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](/wiki/dao-governance/concepts/fundamentals/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 trade-off: ossification and the missing patch

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](/wiki/dao-governance/concepts/voting/token-weighted-voting), 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.

## How Caper approaches this

Most protocols that pursue governance minimization freeze their _contracts_ but leave their _market_ — prices, issuance, fees — under a vote. A [caper](/wiki/foundations/what-is-a-caper) minimizes governance at exactly that layer. Its [bonding curve](/wiki/markets/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.” The curve’s slope constant `CURVE_K` is not in that package. It sits in the **swappable logic** tier beside the fee schedule, and a governed `UPGRADE` proposal in the $CAPER caper points the registry at a fresh logic component carrying its own. 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 – but the stronger form of the claim, that no proposal type can reprice it at all, is the one that fails: `UPGRADE` is that proposal type.

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.

## References

- [Vitalik Buterin — “Credible Neutrality As A Guiding Principle” (2020)](https://balajis.com/p/credible-neutrality)
- [a16z crypto (Miles Jennings) — “Machiavelli for DAOs,” part 1: principles](https://a16zcrypto.com/posts/article/machiavelli-principles-dao-decentralized-governance/)
- [a16z crypto — “Machiavelli for DAOs,” part 2: designing governance](https://a16zcrypto.com/posts/article/machiavelli-daos-designing-effective-decentralized-governance/)
- [Liquity — Governance Free](https://www.liquity.org/features/governance-free) · [Liquity V2 FAQ (minimal governance)](https://docs.liquity.org/v2-faq/general)
- [Uniswap — Governance Overview (immutable core, fee switch)](https://developers.uniswap.org/docs/ecosystem/governance/overview)