On-Chain Proposal Process

1. Deposit Period

A proposal enters the deposit period the moment it's submitted and stays there until its total deposit reaches min_deposit, or until max_deposit_period elapses, whichever comes first. A proposal submitted with the full min_deposit attached skips this waiting period entirely and enters voting immediately in the same transaction.

Deposits

Any address can contribute to a proposal's deposit, not only the original proposer. This is what lets a proposer test interest with a small deposit first, and lets supporters who didn't write the proposal still help push it into the voting period:

aiozd tx gov deposit <proposal_id> "1000000000000000000000attoaioz" \
  --from=<key> \
  --chain-id=<chain_id>

aiozd query gov deposits <proposal_id>

Burned Deposits

If min_deposit is never reached within max_deposit_period, the proposal is dropped and every deposit already contributed to it, from every depositor, is burned rather than refunded. This is a deliberate spam deterrent: without it, submitting proposals with a token deposit and letting them quietly expire would be free.

In practice it means depositing on a proposal you don't expect to reach quorum for is a real cost, not a free way to show support. It's worth being reasonably confident a proposal will clear min_deposit before contributing to it.

2. Voting Period

Once min_deposit is met, the voting period opens immediately for voting_period. Any bonded validator or delegator can vote for its full duration:

aiozd tx gov vote <proposal_id> <Yes|No|NoWithVeto|Abstain> \
  --from=<key> \
  --chain-id=<chain_id>

See Delegator Guide (CLI) for the equivalent command with --gas/--gas-adjustment flags. Check any address's current vote, or every vote cast so far, at any time:

aiozd query gov vote <proposal_id> <voter_address>
aiozd query gov votes <proposal_id>

An address can vote multiple times during the period, paying the transaction fee each time; only the most recently submitted vote counts, so re-voting simply overwrites whatever choice came before it. There's no way to "lock in" an early vote against a later change of mind, by yourself or anyone else.

What Do the Voting Options Mean?

• Yes: support the proposal as written
• No: oppose the proposal
• NoWithVeto: oppose strongly enough to signal the proposal is harmful or submitted in bad faith, not merely something you disagree with
• Abstain: count toward quorum without taking a side, useful for a validator who wants to signal participation without weighing in on the substance

Voting power follows bonded stake: 1 bonded AIOZ carries 1 unit of voting weight, whether it's self-bonded by a validator or delegated to one.

A delegator who does not vote directly inherits their validator's vote automatically; casting a vote of your own overrides that inheritance for your share of the stake, regardless of which way your validator ends up voting.

What Determines Whether or Not a Governance Proposal Passes?

Among non-abstain votes:

• Yes / (Yes + No + NoWithVeto) > threshold (50% on mainnet), and
• NoWithVeto / (Yes + No + NoWithVeto) < veto_threshold (33.4% on mainnet)

If either condition fails, the proposal does not pass. Even a proposal with overwhelming Yes support relative to No can still be vetoed if NoWithVeto alone clears the veto threshold; the two conditions are checked independently, not as a single combined ratio.

Abstain votes are excluded from both calculations entirely, they only matter for quorum below.

How Is Quorum Determined?

(Yes + No + NoWithVeto + Abstain) / TotalBondedStake >= quorum

Quorum is checked against all votes including Abstain, and against total bonded stake network-wide, not just the stake belonging to addresses that bothered to vote. A large Abstain turnout still counts toward clearing quorum even though it doesn't affect the Yes/No/NoWithVeto ratio used for the pass/veto conditions above; a validator who wants a proposal to have the chance to pass, without personally endorsing it, can vote Abstain to help clear quorum.

If turnout doesn't clear quorum (33.4% on mainnet), the proposal fails outright regardless of how the votes that were cast are split, even a unanimous Yes among a small minority of bonded stake.

How Is Voting Tallied?

Tallying happens automatically in the block that ends the voting period. There is no manual step, no one submits a "finalize" transaction. The resulting status (PROPOSAL_STATUS_PASSED, REJECTED, or FAILED) is queryable immediately after:

aiozd query gov proposal <proposal_id>

REJECTED and FAILED both mean the proposal did not pass, but for different reasons worth distinguishing when reading the result. REJECTED means quorum was met but the vote didn't clear threshold (or was vetoed).

FAILED more generally covers a proposal that couldn't be executed even though quorum and threshold were otherwise satisfied, for example a Parameter Change proposal whose payload turned out to be invalid at execution time.

For a Parameter Change or Community Pool Spend proposal, a PASSED result also triggers immediate execution: the parameter changes, or the community pool transfer executes, in the same block the tally finalizes. There's no separate step to "apply" a passed proposal; by the time you can query it as PASSED, its effect has already happened.