Governance

Cosmos SDK chains change through on-chain governance: anyone with tokens can submit a proposal, stakers vote with their bonded tokens, and a proposal that passes executes its messages automatically. This section covers how that works, how to submit a proposal, and templates for the common proposal types.

• Submit a proposal — proposal file, metadata, deposit, voting
• Text proposal — signalling, no on-chain change
• Software upgrade — schedule a chain upgrade, compatible with Cosmovisor
• Parameter change — change module, gov or consensus parameters
• Community pool spend — pay from the community pool
• IBC client recovery — revive an expired or frozen IBC client
• CosmWasm store code — upload contract code where uploads need governance

The commands use <binary> for the chain's node binary (bitsongd, gaiad, …) and the gov module of the Cosmos SDK. Chains can add their own rules: AtomOne, for example, runs its own governance module (atomone.gov.v1) with different parameters and messages. Check the chain's own documentation as well.

Proposal lifecycle

1. Deposit period. A proposal is submitted with a deposit in the chain's staking token. It enters voting once its deposits reach the minimum deposit (min_deposit). Others can add to the deposit until max_deposit_period ends; if the minimum isn't reached by then, the proposal is removed.
2. Voting period. Stakers vote yes, no, no_with_veto or abstain during voting_period. Delegators who don't vote inherit their validator's vote; a delegator's own vote overrides it.
3. Tally. At the end of the voting period the proposal passes if:
   • turnout reaches the quorum (share of all bonded tokens that voted),
   • no_with_veto stays below veto_threshold (share of all votes, including abstain),
   • yes is above threshold (share of the votes, excluding abstain).
4. Execution. The messages of a passed proposal run, signed by the gov module account. If one of them fails, the proposal ends as FAILED and nothing changes.

Deposits are refunded when a proposal passes or is rejected, and burned when it is vetoed (burn_vote_veto). Depending on the chain's settings they are also burned if the proposal misses quorum (burn_vote_quorum) or never reaches voting (burn_proposal_deposit_prevote).

Expedited proposals

From Cosmos SDK v0.50, a proposal can be submitted as expedited: it needs a higher deposit (expedited_min_deposit), votes for a shorter time (expedited_voting_period) and needs a higher yes share (expedited_threshold, 0.667 by default). If it doesn't pass in time, it continues as a regular proposal.

Check the chain's parameters

The values differ per chain; check them before submitting:

<binary> query gov params

Or through a REST endpoint, for example ours for BitSong:

curl -s https://api.bitsong.chaintools.tech/cosmos/gov/v1/params/tallying

Its params object holds all governance parameters, not just the tally ones:

{
  "min_deposit": [{ "denom": "ubtsg", "amount": "5000000000" }],
  "max_deposit_period": "1296000s",
  "voting_period": "604800s",
  "quorum": "0.400000000000000000",
  "threshold": "0.500000000000000000",
  "veto_threshold": "0.334000000000000000",
  "min_initial_deposit_ratio": "0.500000000000000000",
  "expedited_voting_period": "86400s",
  "expedited_threshold": "0.75",
  "expedited_min_deposit": [{ "denom": "ubtsg", "amount": "10000000000" }],
  "burn_vote_quorum": false,
  "burn_proposal_deposit_prevote": false,
  "burn_vote_veto": true,
  "min_deposit_ratio": "0.010000000000000000"
}

Shortened from BitSong's response on 2026-10-16. Amounts are in the base denomination: 5000000000ubtsg is 5,000 BTSG, 604800s is seven days. Two deposit rules are easy to miss:

• min_initial_deposit_ratio: share of min_deposit the submitter must pay with the proposal itself (here half of it).
• min_deposit_ratio (SDK v0.50+): every later deposit must be at least this share of min_deposit.

Which proposal format a chain uses

The format depends on the chain's Cosmos SDK version. Check it with <binary> version --long (field cosmos_sdk_version) or the node info of a REST endpoint:

curl -s https://api.bitsong.chaintools.tech/cosmos/base/tendermint/v1beta1/node_info | jq -r .application_version.cosmos_sdk_version

Cosmos SDK	Proposal format
v0.45 and earlier	Legacy proposals only: tx gov submit-proposal <type> with flags or a type-specific JSON file
v0.46	Proposals hold messages: tx gov submit-proposal proposal.json (no title or summary fields yet); legacy types through submit-legacy-proposal
v0.47	Adds title and summary to proposal.json, and tx gov draft-proposal
v0.50 and later	Adds expedited

On 2026-10-16 the chains ChainTools validates ranged from v0.45 (Decentr) through v0.47 (Sentinel), v0.50 and v0.53 (most chains) to v0.55 (Dungeon).