What the Cosmos Hub governs

The Cosmos Hub is the first chain built on the Cosmos SDK and the origin of the x/gov module that most Cosmos app-chains still run today. Its token, ATOM, is bonded to validators for consensus and is the same weight that votes. Governance here is not advisory: an approved proposal changes chain parameters, spends the community pool, or swaps the node software itself. Proposal #1049, in voting as this page was written, is simply titled “Gaia v27.6.0 Upgrade”: the chain's own binary is a ballot question.

That makes the Hub one of the cleanest large-scale examples of on-chain governance in production, and a useful contrast to the Snapshot-plus-multisig pattern that dominates Ethereum DAOs. It is also the template two of this directory's other entries inherited: dYdX and Osmosis both govern through the same module on their own sovereign chains.

The pipeline: deposit, then vote

Every proposal passes through two windows, both defined by on-chain gov parameters:

• Deposit period, up to 14 days. A proposal only enters voting once its deposits reach 500 ATOM; the submitter must post at least 10% of that themselves, and anyone can top up the rest. Proposals that never reach the minimum expire.
• Voting period, 7 days, fixed. There is no lead-in, no confirmation curve, and no per-topic track: a typo fix in a parameter and a full runtime upgrade get exactly the same week.

An expedited proposal compresses voting to 3 days but raises the bar to 66.7% Yes. The interesting detail is the failure mode: per the x/gov specification, an expedited proposal that misses its higher threshold is not rejected, it is converted into a regular proposal and restarts voting under normal rules. Urgency costs you a stricter bar, not the proposal.

Four options, and what each one actually does

Voters choose Yes, No, NoWithVeto, or Abstain, and the three tally rules each count a different denominator. Getting these apart is the whole skill of reading a Cosmos vote:

• Quorum, 40%: the share of bonded voting power that cast anything at all. Abstain counts here. It is the turnout test.
• Threshold, 50%: Yes as a share of Yes + No + NoWithVeto. Abstain is excluded. It is the majority test.
• Veto, 33.4%: NoWithVeto as a share of all votes, abstain included. Clear it and the proposal fails no matter how large the Yes majority was.

Abstain is therefore not a null vote. It helps a proposal reach quorum while refusing to help it reach a majority, which is how large validators signal “this should be decided, but not by me”. NoWithVeto is the sharp one: on the Hub, burn_vote_veto is set to true while burn_vote_quorum and burn_proposal_deposit_prevote are both false. A vetoed proposal's 500 ATOM deposit is destroyed; one that simply fails, or never reaches quorum at all, is refunded in full. The Hub charges you for being objectionable, not for being ignored, which is a deliberate spam filter aimed at bad-faith proposals rather than unpopular ones.

Validator inheritance: the default that decides most votes

The Hub's most consequential design choice is not a threshold, it is a default. Per the module spec: “If a delegator does not vote, it will inherit its validator vote.” A delegator who votes after their validator overrides it; one who never votes has still voted, through whoever they staked with.

This is why Cosmos turnout numbers look healthy next to the single-digit participation documented on voter apathy pages elsewhere in this wiki, and why that comparison is misleading. Turnout measures bonded stake represented, not people who formed a view. With max_validators set to 200 and a 5% minimum commission, the practical electorate is a couple of hundred operators whose delegators mostly never override them. Cosmos did not solve apathy; it made apathy vote.

The trade is real in both directions. Inheritance guarantees a decisive result within seven days and removes the quorum-failure mode that stalls token-weighted DAOs. It also means delegation chosen for yield, uptime, and commission silently becomes delegation of political authority, and unstaking to escape it costs a 21-day unbonding period.

Proposal 848, and the fork that followed

The clearest case study in Hub governance is Proposal 848, “ATOM Halving: Set the max. Inflation Rate to 10%”, submitted 11 November 2023. Its final on-chain tally, in ATOM:

• Yes: 73,165,204  ·  No: 56,667,012  ·  NoWithVeto: 11,669,550  ·  Abstain: 36,323,836

Run the three tests separately and the result is a lesson in denominators. Yes took 51.7% of the non-abstain vote, clearing the 50% threshold by under two points, while amounting to only 41.1% of everything cast. NoWithVeto reached 6.6%, nowhere near the 33.4% needed to burn it. The proposal passed, and it is still in force: the Hub's live mint parameters read inflation_max: 0.10 today, against an inflation_min of 7% that a later reduction attempt failed to move.

What happened next is the part DAO designers should sit with. The losing 48% did not accept the outcome and did not keep arguing. They left, and took the state with them: AtomOne launched as a self-described minimal fork of the Hub, airdropped ATONE to over a million ATOM addresses, and rebuilt governance around the specific things its founders objected to, including a live on-chain constitution and the removal of delegation-based voting. A two-point margin on one parameter produced a chain split, which is exit in its rawest form: when a governance system offers no way out short of forking, forking is the way out. See also how DAOs fail.

Treasury, and the Hub in July 2026

The Hub's treasury is the community pool, funded by a 2% community tax skimmed from staking rewards and spent only by passing proposal. It is a protocol-native fund with no multisig standing between a vote and a disbursement, and, like most on-chain treasuries, it is easier to fill than to deploy well.

Live chain state gives a fair picture of the Hub's current position. Of 521.95M ATOM in supply, 328.03M is bonded, a bonded ratio near 62.8%. Because that sits below the protocol's goal_bonded of 67%, the inflation schedule drifts up toward its 10% ceiling to bid for more stake, which is exactly the dynamic Proposal 848 capped rather than removed. Governance has kept widening what the chain does: Proposal 1007 (August 2025) enabled permissionless CosmWasm contract deployment, passing with 97.4M ATOM Yes against 1.4M No. It has also kept saying no, rejecting two IBC client-recovery proposals (#1047 and #1048) in July 2026 alone.

How Caper approaches this

Inheritance is the assumption Caper declines. There is no delegation layer in the contract and no validator standing in for you: if you do not vote, nothing votes your balance. A member's weight comes from what they personally hold and the votes they personally cast, computed as (t × v) / (V × T), where t is their governance-token balance, v the vote tokens they have accumulated, V the vote-token supply, and T circulating supply. Holdings alone do not carry a vote, and participation alone does not either; the two multiply.

The pass rule differs in the same direction. Rather than testing turnout against total bonded stake, settlement compares the leading option's share of the weight actually cast against a threshold of 1.5 / number of options, and refuses to pass a proposal whose leading option is a “no”. Weight is also clamped at settlement to the smaller of what a voter held when they voted and what they hold when the tally runs, so selling out of a position after voting shrinks the vote it bought. See proposals and voting for the full mechanism, and the networks directory for sibling chains, including Polkadot, which reaches for conviction locks where Cosmos reaches for delegation.