A DAO's most consequential recurring decision is how many new tokens exist next year. It dilutes every holder, funds every incentive programme, and sets the floor under the token's price. It is also, in the three largest cases this page reads at source, not a decision the DAO takes. The issuance number was fixed once, by whoever wrote the token contract, and the ballot box never gets near it.

This is not the same observation as standing authorizations, where a DAO votes once to delegate a class of future actions inside bounds it chose. Here there was no delegating vote at all: the schedule predates the governance system, and in one of the three cases no address on Earth can change it. The distinction matters because governance dashboards count proposals, and a monetary policy that produces no proposals looks, from the dashboard, like a monetary policy nobody is arguing about.

Shape one: a schedule the DAO cannot amend

Curve's CRV is issued by an inflation schedule written into the token contract itself. ERC20CRV.vy declares RATE_REDUCTION_TIME as one year and RATE_REDUCTION_COEFFICIENT as 1189207115002721024, which is 2^1/4 scaled by 10¹⁸. At each annual boundary the emission rate is divided by that coefficient, cutting issuance by 15.91% a year, forever.

Read live on 12 August 2026, the contract answers mining_epoch() = 5, rate() = 3663926723928765860 (3.6639 CRV per second, or 115,545,593 CRV a year) and start_epoch_time() = 1755037048, which is 22:17:28 UTC on 12 August 2025. Add the reduction interval and epoch six begins at 22:17:28 UTC on 12 August 2026 – the same day this page was written – dropping the rate to 3.0810 CRV per second, or 97,161,875 CRV a year. Against a totalSupply() of 2,409,286,293 CRV, this year's issuance is 4.80% of the float.

No proposal precedes that cut, and none could stop it. The only function that writes self.rate is _update_mining_parameters, and the only way in is the external update_mining_parameters(), whose entire access control is one line: assert block.timestamp >= self.start_epoch_time + RATE_REDUCTION_TIME. Its own docstring says it plainly – "callable by any address, but only once per epoch". The token's admin may set the minter once, hand over adminship and change the token's name; it has no power over the rate at all. A DAO that wanted a different CRV emission curve would have to issue a different token.

Two details reward reading the source rather than the marketing. First, the schedule is permissionless to advance but not automatic: someone has to send the transaction, and the contract warns that "total supply becomes slightly larger if this function is called late". Second, available_supply() returns 2,419,552,174 CRV against a minted totalSupply() of 2,409,286,293 – a gap of 10,265,881 CRV that the schedule has already released and no gauge has yet claimed. The schedule runs whether or not anyone collects.

Shape two: a permission the DAO has never used

Uniswap's UNI is the opposite construction: the mint power exists, it belongs to governance, and it has never been exercised. Uni.sol caps a mint at mintCap = 2 percent of supply, spaces mints by minimumTimeBetweenMints = 1 days * 365, and gates them behind mintingAllowedAfter. The mint function requires the caller to be minter, which reads on-chain as 0x1a9c8182c09f50c8318d769245bea52c32be35bc – a timelock with a 48-hour delay() whose own admin is the Uniswap governor. The permission is genuinely the DAO's.

Two on-chain values show it has never been used. mintingAllowedAfter() returns 1704067200: exactly midnight UTC on 1 January 2024. Line 116 of the contract rewrites that field to block.timestamp + minimumTimeBetweenMints on every successful mint, so a round constructor-set midnight surviving in that slot is proof no mint has landed. And totalSupply() returns exactly 1000000000000000000000000000 – one billion UNI to the wei, the genesis number unchanged.

So for two years and seven months the Uniswap DAO has held a standing, capped, self-executing authority to issue up to 2% of UNI a year, and has not once put it to a vote. The absence is the finding: an unused power still sets an expectation, and every holder's dilution risk is a proposal away from becoming real.

Shape three: a drip that ended by running out

Compound's COMP cannot be minted at all. Comp.sol declares uint public constant totalSupply = 10000000e18 – a compile-time constant, with no mint function anywhere in the contract. Ten million COMP is all there will ever be, and no vote changes that.

Distribution was handled instead by a Reservoir: a contract holding COMP and releasing it to the Comptroller at dripRate tokens per block. Read live, the reservoir at 0x2775b1c75658Be0F640272CCb8c72ac986009e38 answers dripRate() = 500000000000000000 – half a COMP per block – with token() pointing at COMP and target() at the Comptroller, and dripStart() at block 10,229,427. All three are set in the constructor and the contract exposes no setter for any of them; its only state-changing function is drip(), which anyone may call and which "will only drip up to the amount of tokens available".

That reservoir's COMP balance today is zero. The distribution that defined Compound's liquidity mining did not end with a proposal to end it. It ended because a number chosen in June 2020 finished paying out a fixed pot, on a schedule that no COMP holder ever voted on and none could have amended. Whatever COMP flows now has to be moved by a governance transaction, one grant at a time – the Comptroller itself holds 0.00013 COMP.

What the vote actually reaches

In all three cases governance is busy, and in all three it is busy downstream of the number that matters. Curve's GaugeController lets veCRV holders call vote_for_gauge_weights, subject to a WEIGHT_VOTE_DELAY of ten days per gauge, with weights stepping on week boundaries – a continuous, high-stakes, heavily-lobbied election over the split of an emission whose size is not on any ballot. That gap is the whole reason the vote-escrow market exists: when you cannot change how much is printed, the only thing left to buy is where it goes.

Compound is the same division drawn differently. _setCompSpeeds in the Comptroller is gated by require(adminOrInitializing(), "only admin can set comp speed"), so the DAO sets the per-market supply and borrow speeds – the allocation – while the total it was allocating from came out of an immutable drip.

The practical test for any DAO is therefore not "does governance control the token?" but three narrower questions. Can any address change the issuance rate? If yes, whose, and under what cap and cooldown? And when the schedule ends or the pot empties, does anything at all announce it? A DAO that cannot answer the third question will discover its incentive programme has stopped the way Compound's did: from an empty balance, not from a vote.

Check any token yourself

None of this needs an indexer, an API key, or a governance dashboard. Every figure on this page came from eth_call against a public RPC endpoint, and the method generalises to any ERC-20 a DAO claims to govern.

1. Is the supply fixed? Call totalSupply() (0x18160ddd) and compare it to the genesis number in the project's own launch post. Exact equality to a round number is strong evidence nothing has ever been minted.
2. Who may mint? Read the verified source for a mint function and find its access control. Then resolve the address it names – a timelock or governor means the DAO holds the power; a schedule inside the token means nobody does.
3. What are the bounds? Look for a cap and a cooldown (Uniswap's mintCap and minimumTimeBetweenMints), or a rate and a reduction interval (Curve's rate and RATE_REDUCTION_TIME). A permission with no cap and no cooldown is not monetary policy, it is a key.
4. Is it still running? Check the balance of whatever contract is supposed to be paying – the reservoir, the vesting escrow, the distributor. A distribution contract with a zero balance has stopped, whatever the documentation still says.

The fourth check is the one every governance dashboard misses, because a distribution that ends by exhaustion generates no proposal, no event a governance indexer watches, and no announcement.

How Caper approaches this

A caper has no monetary policy to vote on, because it has no issuance schedule. The full supply of a caper's governance token – 100 billion units, the CURVE_CAP constant every caper shares – is minted once when the caper is created, into an inventory vault, with no mint role and no burn role attached to the resource. Nothing in the contract can enlarge or shrink it later, and there is no proposal type that tries.

What moves is the split between the vault and holders, along the bonding curve: buying takes tokens out of inventory at a price the curve sets, selling puts them back. So the question this page asks of Curve, Uniswap and Compound – "which passed proposal changed the supply?" – has no analogue here. A caper's votes are about what the treasury does, never about how many tokens exist.

That is a narrower design, not a better one in every respect: a fixed supply cannot fund an incentive programme by printing, so a caper that wants to pay for something has to pay out of its treasury and show the payment. The trade is deliberate. Dilution is the one governance risk a holder cannot audit after the fact, and the simplest way to make it auditable is to make it impossible.