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 to vote on. The full supply of a caper's governance token – 100 billion units, the CURVE_CAP constant every caper shares – is minits token is created once, when the caper is created, into an inventory vault, with no mint role and no burn role attached to the resource. Nlaunches, and nothing in theits 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 heremint more or burn any; buying takes tokens from that fixed supply and selling returns them. A caper's votes (/wiki/governance/voting) are aboutdecide what theits treasury does, never about how many tokens exist. The one resource a caper does mint is its soulbound vote token. Each ranked ballot cast mints the voter exactly one (VOTE_MINT, a constant in the logic every caper runs), and exit (/wiki/foundations/leaving-a-caper) burns the ones a leaving member hands in. The vote token has no price and cannot be transferred, but it sets each member's share of the treasury on exit, so it is where a caper's dilution happens: every ballot anyone casts shrinks every other member's claim slightly. That rate is not on a caper's own ballot either. Only an Upgrade proposal on $CAPER, which replaces the logic for every caper at once, could change it. That is a narrower design, not a better one in every respect: aVote weight is earned by voting rather than bought, so a big bag alone can't capture control. A fixed supply cannot fund anpay for incentive programmes by printing, so: a caper that wants to pay for something has to pay out of its treasury and show the payment. The tradepays from its treasury, through a proposal its 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 impossiblemembers vote on, as Paying someone from a caper (/wiki/foundations/paying-someone-from-a-caper) describes.

How Caper approaches this A …about how many tokens exist. The one resource a caper does mint is its soulbound vote token. Each ranked ballot cast mints the voter exactly one (VOTE_MINT, a constant in the logic every caper runs), and exit (/wiki/foundations/leaving-a-caper) burns the ones a leaving member hands in. The vote token has no price and cannot be transferred, but it sets each member's share of the treasury on exit, so it is where a caper's dilution happens: every ballot anyone casts shrinks every other member's claim slightly. That rate is not on a caper's own ballot either. Only an Upgrade proposal on $CAPER, which replaces the logic for every caper at once, could change it. That is a narrower design, not…able is to make it impossible.

Topic Where a DAO token's issu…s Measured Ethereum mainnet, 12 August5 September 2026, blocks 25,740,317–25,740,331913,717, by direct eth_call; efirst read 12 August 2026 and re-read in full since, because one of the three had moved. Every figure below is reproducible with the four calls in the method section R…sury/protocol-owned-liquidity)

Shape one: a schedule the DAO … year, forever. Read live on 12 August5 September 2026, the contract answers mining_epoch() = 56, rate() = 3663926723928765860 (3.6639080982847903985532 (3.0810 CRV per second, or 115,545,59397,161,875 CRV a year) and start_epoch_time() = 175503786573048, which is 22:17:28 UTC on 12 August 20256. Add the reduction interval and egainst a totalSupply() of 2,415,754,928 CRV, this year’s issuance is 4.02% of the float. Epoch sixeven 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 float7 and takes the rate to 2.5908 CRV per second, or 81,703,072 CRV a year. The epoch turned over between this page’s two readings, and the way it did is the finding. On 12 August 2026 the contract answered mining_epoch() = 5 and rate() = 3663926723928765860 against a float of 2,409,286,293 CRV – an issuance share of 4.80% – and this page worked the coefficient forward to predict a cut to 3.0810 CRV per second that evening. The prediction was exact: the rate on chain today is 3080982847903985532, to the wei. That is precisely what makes a page like this one decay invisibly. A forecast that lands leaves prose whose arithmetic still re-derives perfectly, so the stale paragraph reads as carefully sourced rather than out of date; the only thing wrong with it is the tense. Every figure above was re-read at source rather than carried forward. No proposal precedes that c…available_supply() returns 2,419,552,17425,995,672 CRV against a minted totalSupply() of 2,409,286,29315,754,928 – a gap of 10,265,88140,744 CRV that the schedule has alr…hether or not anyone collects.

Check any token yourself None… watches, and no announcement. Re-read on 5 September 2026, 24 days after the first pass, the four checks reproduced with exactly one change. Uniswap’s mintingAllowedAfter() is still the constructor’s 1704067200 and its totalSupply() still exactly one billion UNI to the wei; Compound’s reservoir balance is still zero and the Comptroller still holds 0.000126 COMP. The only number on this page that moved is the one no vote can reach. Curve’s epoch rolled on its own schedule, advanced by a transaction any address could have sent and none had to be authorised to send, while both constructions that governance does control sat untouched for 24 days. The page’s argument is usually made by inspection; here it ran as an experiment.

Shape one: a schedule the DAO …2:17:28 UTC on 12 August 2026 -– the same day this page was written -– dropping the rate to 3.0810 C…own docstring says it plainly -– "callable by any address, but…otalSupply() of 2,409,286,293 -– a gap of 10,265,881 CRV that …hether or not anyone collects.

Shape two: a permission the DA…f50c8318d769245bea52c32be35bc -– a timelock with a 48-hour del… 1000000000000000000000000000 -– one billion UNI to the wei, t…posal away from becoming real.

Shape three: a drip that ended…ant totalSupply = 10000000e18 -– a compile-time constant, with…ipRate() = 500000000000000000 -– half a COMP per block -– with token() pointing at COMP…nsaction, one grant at a time -– the Comptroller itself holds 0.00013 COMP.

What the vote actually reaches…s stepping on week boundaries -– a continuous, high-stakes, he…rket supply and borrow speeds -– the allocation -– while the total it was alloca…mpty balance, not from a vote.

Check any token yourself None… resolve the address it names -– a timelock or governor means …ract is supposed to be paying -– the reservoir, the vesting es… watches, and no announcement.

How Caper approaches this A …of a caper's governance token -– 100 billion units, the CURVE_…P constant every caper shares -– is minted once when the caper…f Curve, Uniswap and Compound -– "which passed proposal changed the supply?" -– has no analogue here. A caper…able is to make it impossible.

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. - 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. - 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. - 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. - 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.