Skip to main content

ZIGChain Governance

TL;DR: ZIGChain governance lets ZIG holders propose and vote on chain changes—each staked token counts as one vote.

Overview​

ZIGChain governance is a decentralized decision-making process that allows ZIGChain users to participate in the network's future. Users can vote on proposals, where each ZIG token equals one vote, to change parameters such as fees and validator count, or decide how to spend the treasury. The governance process is essential for ZIGChain's decentralized nature as it ensures the network evolves through community consensus.

This page covers the full ZIGChain governance lifecycle from community feedback through deposit, voting, and final results. Read the Governance Module for module parameters and CLI details. For step-by-step submission, see the Governance Proposal Submission Guide. You can also vote and browse proposals in the Governance Proposals on ZIGChain Hub dashboard.

Key Concepts​

  • Bonded tokens: ZIG staked with active validators; only bonded stake counts toward voting power in ZIGChain governance.
  • Deposit period: Window after submission when supporters add ZIG until the proposal reaches the minimum deposit or is dropped.
  • Quorum: Minimum share of bonded ZIG that must vote before a proposal can pass or fail on its merits.
  • Veto threshold: Cap on "No with Veto" votes; above it, the proposal is vetoed and deposits are burned.
  • Expedited proposal: Fast-track vote with a shorter period and a higher Yes threshold than standard ZIGChain governance proposals.
  • Proposal status: Final on-chain outcome such as passed, rejected, vetoed, dropped, or canceled, recorded in transaction logs.

ZIGChain Governance Process Overview​

ZIGChain governance follows five stages from idea to result:

    1. Community Consultation: Share your idea with the community to gather feedback before you submit on chain.
    1. Proposal Submission: Submit a formal proposal with an initial deposit. Any ZIG holder can start a proposal.
    1. Deposit Period: Supporters add ZIG until the minimum deposit is met; reaching that threshold starts the voting period. If the target is not reached by period end, the proposal closes and all deposited ZIG return to the proposer and supporters.
    1. Voting Period: Delegators with bonded tokens on active validators can vote on the proposal. The proposal must meet quorum and the pass threshold to succeed.
    1. Voting Results: When voting ends, the proposal is closed and final results are calculated.
    • If the proposal passes, it is executed on chain and deposited tokens are returned to the proposer and supporters.
    • If it is rejected, deposited tokens are returned to the proposer and supporters.
    • If the proposal is vetoed, deposited tokens are burned.
ZIGChain governance process from community consultation through voting results

Detailed Steps of the Governance Process​

The sections below walk through each stage of ZIGChain governance in order. Each step builds on the previous one, from sharing a draft with the community through deposit, voting, and final tally. Use the examples to see how deposit rules, vote inheritance, and pass conditions work in practice.

1) Share with the Community​

While it is not mandatory, sharing your idea with the community before submission is strongly recommended. Early feedback helps you refine the proposal and find supporters before you lock deposits on chain. A well-reviewed draft is more likely to reach the deposit threshold and pass quorum once voting starts.

2) Draft and Submit a Proposal​

Submitting a proposal requires an initial deposit of at least 400 ZIG on Mainnet. The initial deposit proves serious intent and filters low-quality submissions before they enter the full deposit period.

note

These values may change via governance proposals. Always confirm using the CLI or API. (minimum_initial_deposit_ratio * min_deposit = 0.04 * 10,000).

  • Minimum Initial Deposit Ratio Example:
    Alice submits a proposal and deposits 200 ZIG to support it. However, as it doesn't reach the minimum, it is not valid (0.04 * 10,000 = 400 ZIG), so Alice should deposit at least 400 ZIG to submit the proposal.

3) Deposit Period​

To prevent spam, proposals must reach a minimum deposit of 10,000 ZIG before proceeding to the voting period. During the deposit period, ZIG holders can deposit any amount of ZIG to support the proposal. Once the total deposits reach 10,000 ZIG, the voting period begins. If the minimum deposit is not met by the end of the period, the proposal is closed, and all deposited ZIG are returned to supporters.

  • Deposit Period and Amounts Example:
    Alice submitted a proposal with a deposit of 8,000 ZIG. After 4 days, the proposal has yet to reach the minimum deposit amount (10,000), so the 8,000 ZIG are returned to Alice.

4) Voting Period​

Once the deposit threshold is met, the proposal enters a voting phase lasting 4 days, or 1 day if expedited. ZIGChain delegators with bonded tokens (tokens staked with active validators; see How ZIGChain Staking Works) can cast votes as follows:

  • Yes
  • No
  • No with Veto (to reject malicious proposals)
  • Abstain

Votes cast by validators are automatically inherited by their delegators unless the delegators cast their own vote. If a delegator has both bonded and unbonded tokens, only the bonded tokens are considered in the vote count. This inheritance rule means inactive delegators still contribute voting weight through their validator's choice.

  • Voting Example:
    Alice has 10,000 ZIG delegated to 2 validators. Validator A has 6,000 ZIG (active) and Validator B has 4,000 ZIG (inactive). If Alice votes, only the 6,000 ZIG staked with Validator A are considered. If she doesn't vote, her vote defaults to Validator A's choice.

5) Voting Results​

A proposal must meet three conditions to pass:

  1. Quorum Check:
    At least 33.4% of total bonded ZIGs must participate in the vote.

  2. Veto Check:
    "No with Veto" votes must not exceed 33.4% of total votes; otherwise, the proposal is vetoed, and deposits are burned.

  3. Threshold Check:
    At least 51% of non-abstaining votes must be in favor (66.67% for expedited proposals).

Proposals are rejected if either quorum or threshold are not met.

  • Quorum Example:
    Alice and Bob's proposal reaches the minimum deposit. With 1 million bonded ZIG in the network, 334,000 ZIG (33.4%) voting participation is needed to meet quorum. The proposal receives only 250,000 ZIG in voting participation during the voting period (less than the quorum), resulting in a return of deposits to Alice and Bob.

  • Veto Example:
    Alice proposes a malicious proposal. During the voting period, the proposal has the following votes:
    Yes - 100,000
    No - 50,000
    Abstain - 100,000
    No with Veto - 150,000

    The proposal is vetoed as the number of "No with Veto" votes is greater than total votes * veto threshold (150,000 > 400,000 * 33.4% = 133,333.33333). As it is tagged as a vetoed proposal, the deposited ZIG are burned.

  • Threshold Example:
    Alice submitted a proposal and deposited 25,000 ZIG to support it. The proposal has the following votes:
    Yes - 105,000
    No - 50,000
    Abstentions - 195,000
    No with Veto - 50,000

    The proposal reaches the quorum and is not vetoed. It is accepted if the number of yes votes exceeds the threshold calculation:
    Yes > 51% * (total votes - abstentions)
    (105,000 > 0.51 * (400,000 - 195,000)) -> (105,000 > 104,550)
    The proposal is accepted.

Special Cases in ZIGChain Governance​

Some ZIGChain governance paths use shorter timelines, higher pass bars, or partial deposit burns. Expedited proposals shorten the voting window and raise the pass threshold for any proposal type when the proposer meets the deposit requirement. Cancellation lets a proposer withdraw before voting ends with a penalty on deposits.

Expedited Proposals​

Any proposal can use an expedited path in ZIGChain governance when the proposer meets the deposit requirement. Expedited votes run for a shorter voting period and require a higher Yes threshold than standard proposals. Confirm current values in the Governance Module or via the CLI. Expedited paths still need the full minimum deposit before voting opens. Supporters must mobilize votes quickly once the deposit threshold is met.

  • Expedite Example:
    Alice proposes an expedited proposal with a deposit of 500,000 ZIG. After meeting the minimum deposit requirement, the proposal enters a shorter voting period where it must achieve both quorum and the expedited approval threshold to pass.

Cancel Proposals​

A proposer can cancel an open ZIGChain governance proposal before voting ends. Half of the total deposit returns to the proposer and supporters. The other half is burned. This penalty discourages frivolous submissions while still letting authors withdraw flawed drafts without waiting for a full vote.

  • Cancel Proposal Example:
    Alice deposits 20,000 ZIG and Bob adds 5,000 ZIG to support the proposal. If Alice cancels the proposal, half of the total deposit (12,500 ZIG) is burned and half is returned proportionally:
    • Alice receives 10,000 ZIG
    • Bob receives 2,500 ZIG

Governance Proposal Types​

ZIGChain governance proposals use typed messages that set what the chain executes if the vote passes. The proposal type determines whether the chain updates a parameter, spends from the community pool, or schedules a software upgrade. Choose the type that matches your intent before you submit.

ZIGChain supports multiple proposal types, including:

  • text: For general suggestions or parameter discussions
  • community-pool-spend: Requests to allocate funds from the community pool
  • software-upgrade: Used for chain upgrades
  • cancel-software-upgrade: Cancels a previously scheduled upgrade
  • other: Allows choosing any whitelisted Cosmos message (e.g., parameter changes)

When selecting other, a full list of message types (e.g., MsgUpdateParams, MsgSetWithdrawAddress) is displayed. Choose the one appropriate for your intent.

Governance Proposal Statuses​

After voting ends, the chain emits a final status in transaction logs under the proposal_result attribute. That status tells you whether deposits returned, burned, or led to an on-chain change.

StatusDescription
proposal_droppedProposal didn't meet the minimum deposit.
proposal_passedProposal passed quorum and threshold successfully.
proposal_rejectedProposal failed quorum or vote threshold.
expedited_proposal_rejectedExpedited proposal failed stricter voting rules.
optimistic_proposal_rejectedOptimistic proposal failed its criteria.
proposal_failedProposal passed voting but failed during execution.
proposal_canceledProposal was canceled by its proposer before voting ended.

Users can check the current status of a ZIGChain governance proposal using CLI commands like:

PROPOSAL_ID=1
zigchaind query gov proposal $PROPOSAL_ID \
--chain-id zigchain-1 --node https://public-zigchain-rpc.numia.xyz

Managing Governance Through ZIGChain Hub​

Visit Governance Proposals on ZIGChain Hub to view and vote on ZIGChain governance proposals without using the CLI. The Hub mirrors on-chain proposal data and lets wallet holders sign votes from the browser. ZIGChain governance parameters such as deposit minimums and voting windows can change through parameter votes, so confirm live values in the Governance Module before you act.

Viewing Proposals​

The Hub proposals page lists active and past ZIGChain governance votes in one place. Use the summary cards and table to scan status at a glance, then open a row for full details.

The proposals page displays:

  • Summary cards: Total, Voting, Passed, and Rejected proposal counts
  • Proposals table: ID, title, end time, and status for each proposal
  • Search: Find specific proposals by title
  • Filter: Filter by All or Active proposals
  • Proposal details: Click any proposal to view full description, voting results

How to Vote​

Casting a vote through the Hub follows the same on-chain rules as the CLI. You must hold bonded ZIG before the voting period ends, and your ballot overrides any vote your validator would inherit on your behalf.

  1. Connect your wallet (e.g. Keplr) to ZIGChain Hub
  2. Navigate to active proposals in the voting period
  3. Select your vote: Yes, No, No with Veto, or Abstain
  4. Confirm the transaction
  5. Monitor results as the proposal progresses
note

You need staked ZIG tokens to vote. Your voting power equals your staked amount, and if you don't vote, your vote will follow your validator's choice.

Governance Parameters​

ZIGChain governance uses deposit minimums, voting windows, and threshold ratios to discourage spam and keep decisions representative. Mainnet currently requires a 10,000 ZIG minimum deposit, a 4-day standard voting period, and quorum and veto thresholds near 33.4%. Expedited proposals use a shorter voting period and a higher pass threshold than standard proposals.

These parameters can change when the community passes a parameter-update proposal, so always read live values before you submit or vote. Refer to the Governance Module for the full parameter list and CLI query commands.

Common Questions​

Can I vote in governance with unbonded ZIG tokens?​

No. Only bonded tokens staked with active validators count toward voting weight in ZIGChain governance. Unbonded or liquid wallet balance does not add voting power, even if you hold a large ZIG balance. To vote, delegate to an active validator and wait until your stake is bonded before the voting period ends.

What happens to deposits when a proposal is vetoed?​

Deposits are burned when "No with Veto" votes exceed the veto threshold. This penalty targets proposals the community flags as harmful or malicious. Veto burns are intentional: they raise the cost of submitting reckless proposals and signal that delegators will not tolerate changes that threaten network safety.

Can a proposer cancel a proposal before voting ends?​

The proposer can cancel while the proposal is still open. Half of the total deposit is refunded and half is burned, split proportionally between the proposer and supporters. Cancellation is useful when a draft contains errors, but the burn discourages using cancel as a way to avoid a likely rejection.

What is the difference between expedited and standard proposals?​

Expedited proposals use a shorter voting period and a higher Yes threshold among non-abstaining votes than standard proposals. Standard ZIGChain governance votes use the default voting period and pass threshold. Expedited paths suit time-sensitive matters but require stronger community consensus because the shorter window gives delegators less time to review the details. Confirm live values in the Governance Module.