How Gonka Governance Works
Gonka is built on the Cosmos SDK, and its governance system inherits the battle-tested x/gov module. Every validator and token delegator can participate in on-chain proposals that shape the protocol's direction. Here is how the system operates and why its design choices matter.
The Mechanics
Governance proposals follow a defined lifecycle: submission, deposit period, voting period, and execution. Anyone holding GNK tokens can submit a proposal, but it must collect a minimum deposit before entering the voting phase. Once the deposit threshold is met, validators and their delegators have a fixed window to cast votes.
Three parameters define the outcome:
- Quorum: 33.4% — At least one-third of all staked tokens must participate for the vote to be valid. This prevents a small minority from pushing changes through during low-activity periods.
- Threshold: 50% — Of all votes cast (excluding abstentions), more than half must be "Yes" for the proposal to pass. A simple majority.
- Veto: 33.4% — If more than one-third of votes are "NoWithVeto," the proposal is rejected regardless of the Yes count, and the deposit is burned. This acts as a safety valve against proposals that a significant minority considers harmful.
Proposal Types
Gonka governance supports four main proposal types:
Software Upgrade — The most consequential type. These proposals specify a new binary version and a block height at which validators must switch. The v0.2.10 release, for example, was activated through an on-chain software upgrade proposal. Validators had a 3,000-block grace period (~5 hours) to complete the transition.
Parameter Change — These modify runtime parameters without requiring a new binary. For instance, the ValidationSlots parameter, which controls how many inference slots a validator can claim, can be adjusted through a parameter change proposal. This allows the community to tune network economics without coordinating a full software upgrade.
Community Pool Spend — The protocol accumulates tokens in a community pool from block rewards. Spend proposals allocate these funds for development, marketing, grants, or any purpose the community approves. The bounty payments to community contributors in v0.2.10 were made from this pool.
Text Proposals — Non-binding proposals used for signaling community intent. These do not trigger any automatic on-chain action but serve as a formal polling mechanism for decisions that require off-chain coordination.
Governance in Practice
The v0.2.10 upgrade illustrates how the process works end-to-end. After the release was tagged and tested on testnet, a software upgrade proposal was submitted on-chain. Validators reviewed the changes, verified the testnet deployment, and voted during the voting period. Once the proposal passed with sufficient quorum and majority, the chain automatically halted at the designated block height, and validators upgraded their nodes to the new binary.
This process takes 2-3 days from proposal submission to activation, which balances speed with sufficient review time.
Community-Driven Development
Beyond formal governance, Gonka runs a bounty program that pays community contributors in GNK tokens for accepted pull requests. This creates a direct connection between governance (which allocates community pool funds) and development (which produces the code that governance proposals activate).
The result is a feedback loop: contributors write code, governance approves releases, and the community pool funds future contributions.
Why This Design
The 33.4% quorum and veto thresholds come directly from Cosmos SDK defaults, proven across dozens of chains over several years. They balance three competing needs: making governance accessible (not requiring 67% participation), preventing minority capture (requiring real quorum), and providing a safety mechanism against contentious changes (veto power).
For Gonka specifically, this structure means that model updates, inference parameters, and consensus changes all flow through the same transparent process. No single entity can push changes to MainNet without community approval.