Four gates, one passage. The chain routes its future through the validator set.
A validator's job does not end at block production. Every chain built on the Cosmos SDK ships an x/gov module, and that module routes the chain's future through the validator set. When a software upgrade goes live, validators voted. When a parameter changes, validators voted. When a community-pool spend reaches a recipient, validators voted. The validator who signs every block but ignores every proposal is present at the machinery while absent from the decisions that shape it.
This lesson covers the governance lifecycle as an operational discipline. Four phases, each with its own parameters, its own actor set, and its own failure mode. The validator's obligation at each phase is concrete: know the deadlines, track the proposals, cast the vote.
The Cosmos SDK's x/gov module implements on-chain governance as a four-gate passage. Each gate is sequential. A proposal that fails any gate does not advance. A proposal that passes all four produces a state change the entire network executes simultaneously at block N+1 after tally closes.
Any address submits MsgSubmitProposal. Proposal type determines which module handles ratification: text (signal), software upgrade (x/upgrade plan), parameter change, or community pool spend.
Proposal needs min_deposit (512 ATOM on Hub) within deposit_period (48h default). Miss threshold: proposal fails and deposits burn. Hit threshold early: voting opens immediately.
Validators vote with bonded stake over voting_period (14 days on Hub). Options: Yes, No, NoWithVeto, Abstain. Delegators may override their validator's vote with their own MsgVote.
Quorum ≥33.4% of total bonded stake must participate. NoWithVeto <33.4% or deposits burn. Yes >50% of Yes+No+NoWithVeto: proposal passes and messages execute.
In Cosmos SDK v0.47 and later, proposals carry a list of sdk.Msg objects in a messages field. The older subspace-key-value pattern still appears on chains that have not upgraded their SDK. Know which pattern the target chain uses before crafting the proposal JSON.
The burn-on-veto mechanism is the community's tool against governance spam. A proposal that draws more than veto_threshold in NoWithVeto votes loses its depositors' tokens. The 33.4% veto threshold is deliberately lower than a majority: it takes a significant minority who consider a proposal actively harmful, not merely wrong, to trigger the burn.
A validator with no proposal watcher will discover a vote deadline only after it passes. Query proposals currently in voting period:
gaiad query gov proposals \
--status voting_period \
--output json \
--node <rpc-endpoint>Fields of interest: id, voting_end_time, status. The voting_end_time is the deadline. The validator must cast before it, not at it.
Once the proposal is identified and assessed:
gaiad tx gov vote <proposal-id> <yes|no|no_with_veto|abstain> \
--from <validator-operator-key> \
--chain-id <chain-id> \
--node <rpc-endpoint> \
--fees <amount>uatom \
--gas auto--from key here is the validator's operator key, not the consensus key. The consensus key lives in the remote signer (tmkms or hardware KMS) and must not appear in governance transactions. The separation established in the 2026-06-13 key security lesson applies unchanged at the governance terminal.
gaiad tx gov deposit <proposal-id> <amount>uatom \
--from <depositor-key> \
--chain-id <chain-id> \
--node <rpc-endpoint> \
--fees <amount>uatomThe deposit-or-burn calculus: if a proposal is likely to draw sufficient NoWithVeto votes, contributing to its deposit is costly even if a standard failure would have returned the tokens. If the proposal carries merit, the deposit returns at tally. Read the proposal before depositing.
Abstain is not a non-vote. It contributes to quorum while declining to influence direction. A validator who cannot evaluate a technical parameter change before voting_end_time has one sound option: cast Abstain to ensure their bonded stake counts toward quorum without voting on a matter they have not studied. The discipline to name: if a validator consistently Abstains on every proposal, that is abdication. Governance records are public and queryable; delegators who care will notice the pattern.
A software upgrade proposal is not merely a governance event. When it passes tally, the module writes an UpgradePlan to x/upgrade state at the target block height. The chain halts there automatically. Every operator must have the new binary staged before the halt height. Upgrade planning must begin at proposal submission, not at proposal passage. The window between passage and halt height is the rehearsal window for the binary swap, and it closes on-chain time, not the operator's calendar.
The example is a ParameterChange proposal to raise max_validators on a test chain from 125 to 150. The operator sponsors the proposal and votes on it.
{
"title": "Increase max_validators from 125 to 150",
"description": "The active validator set has operated near capacity for 45 consecutive days. Expanding to 150 accommodates demand without materially affecting consensus performance at current delegation concentration.",
"changes": [
{
"subspace": "staking",
"key": "MaxValidators",
"value": "150"
}
],
"deposit": "512000000uatom"
}Including the full min_deposit at submission skips the deposit-period risk. An operator who controls 512 ATOM and believes in the proposal should prefer this over leaving the deposit window open.
gaiad tx gov submit-legacy-proposal param-change proposal.json \
--from <operator-key> \
--chain-id cosmoshub-4 \
--node https://rpc.cosmos.directory:443/cosmoshub \
--fees 2000uatom \
--gas autoThe tx receipt carries the proposal_id. Record it.
gaiad query gov proposal <proposal-id> \
--node https://rpc.cosmos.directory:443/cosmoshub \
--output jsonStatus transitions from PROPOSAL_STATUS_DEPOSIT_PERIOD to PROPOSAL_STATUS_VOTING_PERIOD the moment deposit threshold clears. The voting_end_time field appears once voting opens.
gaiad tx gov vote <proposal-id> yes \
--from <operator-key> \
--chain-id cosmoshub-4 \
--node https://rpc.cosmos.directory:443/cosmoshub \
--fees 2000uatom \
--gas auto
gaiad query gov tally <proposal-id> \
--node https://rpc.cosmos.directory:443/cosmoshub
# After tally — verify the parameter took effect
gaiad query staking params \
--node https://rpc.cosmos.directory:443/cosmoshubThe liveness monitoring lesson (2026-06-20) built the operational watchdog posture: a polling loop pointed at the slashing sign-info endpoint, alerting on missed-block thresholds. Governance watch is the same discipline at a different endpoint. The watcher, the threshold, the alert path, and the idempotent action handler all follow the same shape. What changes is the object being monitored and the action being guarded.
The signing key security lesson (2026-06-13) established the critical separation between the consensus key and the operator key. Governance voting is an operator-key transaction. The hardware-wallet discipline described there is equally binding at the governance terminal.
The chain upgrade coordination lesson (2026-05-30) documented the x/upgrade halt-and-resume cycle in mechanical detail. That lesson began with the binary in hand and the halt height approaching. Today's lesson surfaces the earlier phase: the software upgrade proposal that triggers the halt must pass all four governance gates before any operator prepares a binary. The upgrade timeline begins at proposal submission.
Today's Bash lesson encodes the governance watch discipline as executable scripts. Three scripts cover the operational surface: a proposal-status daemon that polls active proposals and alerts when a voting deadline approaches, an idempotent vote-submission wrapper that checks for an existing vote before sending a transaction, and a deposit guard that fires when a target proposal risks expiring below min_deposit. All three carry the strict-mode header and trap-cleanup pattern from the 2026-06-13 Bash lesson. The polling loop is the direct descendent of the liveness watchdog from 2026-06-20.
A validator's governance record is public. Every vote, every abstain, and every silence is on-chain and queryable by any delegator who wants to know whether their chosen operator governs the chain they entrust it to run. The governance watch discipline is not advisory. It is part of the validator's obligation to the network, the same as uptime.
Know the chain's governance parameters before a proposal enters voting. Build the watcher before a deadline appears. Cast the vote.