---
title: "Emissions without a vote: who sets a token's monetary policy"
url: "https://caper.network/wiki/dao-governance/concepts/treasury/emissions-without-a-vote"
updated: 2026-08-12
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Emissions without a vote: who sets a token's monetary policy

|  |  |
| --- | --- |
| **Topic** | Where a DAO token's issuance rate is actually decided, and how often that is anywhere a vote can reach |
| **Core question** | If the supply of a governed token changes this year, which passed proposal changed it? For the three tokens read below, the answer is none. |
| **Three shapes** | A schedule the DAO cannot amend (Curve) · a capped permission the DAO has never used (Uniswap) · a hardcoded drip that ended by running out (Compound) |
| **What the vote does reach** | Allocation, not amount: Curve's gauge weights, Compound's per-market COMP speeds |
| **Measured** | Ethereum mainnet, 12 August 2026, blocks 25,740,317–25,740,331, by direct `eth_call`; every figure below is reproducible with the four calls in the method section |
| **Read at source** | [Curve ERC20CRV.vy](https://github.com/curvefi/curve-dao-contracts/blob/master/contracts/ERC20CRV.vy) · [Curve GaugeController.vy](https://github.com/curvefi/curve-dao-contracts/blob/master/contracts/GaugeController.vy) · [Uniswap Uni.sol](https://github.com/Uniswap/governance/blob/master/contracts/Uni.sol) · [Compound Comp.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/Comp.sol) · [Compound Reservoir.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Reservoir.sol) |
| **Related** | [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) · [Standing authorizations](/wiki/dao-governance/concepts/treasury/standing-authorizations) · [Vote-escrow tokenomics](/wiki/dao-governance/concepts/voting/vote-escrow) · [Protocol-owned liquidity](/wiki/dao-governance/concepts/treasury/protocol-owned-liquidity) |

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](/wiki/dao-governance/concepts/treasury/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](/wiki/daos/dexs/curve-dao)'s CRV is issued by an inflation schedule written into the token contract itself. [ERC20CRV.vy](https://github.com/curvefi/curve-dao-contracts/blob/master/contracts/ERC20CRV.vy) declares `RATE_REDUCTION_TIME` as one year and `RATE_REDUCTION_COEFFICIENT` as `1189207115002721024`, which is 21/4 scaled by 1018. 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](/wiki/daos/dexs/uniswap-dao)'s UNI is the opposite construction: the mint power exists, it belongs to governance, and it has never been exercised. [Uni.sol](https://github.com/Uniswap/governance/blob/master/contracts/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](/wiki/daos/lending/compound-dao)'s COMP cannot be minted at all. [Comp.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/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](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Reservoir.sol): 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](https://github.com/curvefi/curve-dao-contracts/blob/master/contracts/GaugeController.vy) 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](/wiki/dao-governance/concepts/voting/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](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Comptroller.sol) 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](/wiki/foundations/what-is-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](/wiki/markets/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](/wiki/governance/voting) 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.