Governance in Gonka: How a Decentralized Network is Managed

Governance in Gonka operates on two levels, each with its own speed and scale of decisions.

Operational Voting (minutes) — operational decisions within the network. When a dispute arises about the validity of an inference request or PoC result, hosts vote via the x/group module of Cosmos SDK. The vote weight is determined by PoC weight – the more computations a node performs, the greater its influence. Such votes last minutes and resolve specific conflicts: whether the inference was correct, whether the node performed its work.

Governance Voting (days) — strategic decisions about protocol development. Software updates, network parameter changes, activation of new models, distribution of Community Pool funds – all this is put to a vote by all hosts. The voting period is from several days to a week, so that all participants have time to familiarize themselves with the proposal.

Key difference from most crypto projects: vote weight is determined by Proof of Compute, not staking. In Gonka, you cannot “buy a vote” by simply accumulating tokens in your wallet. Influence is proportional to real computational contribution – GPUs that process AI requests and generate proofs of work. This ties governance to those who truly support the network architecture, not to speculative capital.

In practice, this means: a farm operator with 10 H100s has 10 times more votes than an operator with one card – because they process 10 times more inference requests. The system is self-balancing: those who contribute more to the network's operation have more influence on its development.

Updating the Gonka protocol is a formalized process from code to network activation. Every step is transparent and verifiable.

Update Process:

1. Pull Request on GitHub — developers (Gonka team or contributors) create a PR in the gonka-ai/gonka repository.
2. Community Review — code is reviewed, discussed, and tested. CertiK audit for critical changes.
3. Release — a new version of the gonkad binary is built.
4. On-chain proposal — an on-chain update proposal is created with a description of the changes.
5. Deposit + Vote — hosts deposit (activation threshold) and vote during the voting period.
6. Cosmovisor — upon approval, Cosmovisor automatically updates nodes at the specified block height.

From January to May 2026, the network went through 13+ successful votes — from v0.2.2 to v0.2.13. All proposals were approved. Timeline of key upgrades:

• v0.2.11 (March 2026, proposal #31) — 673,699 “yes” votes with 0 “no” votes. Subnet inference was introduced — an off-chain computation mechanism via subnets, promising a 100x increase in throughput.
• v0.2.13 (May 2026, proposal #54) — accepted May 21, 2026 (62.8% “yes”, 39.9% turnout with a 33.4% quorum), activated at block 4267300. Added MiniMax-M2.7 as the third model in the network, activated Ethereum bridge wiring, and lowered the quorum to 0.25.

Voting Options:

• Yes — I support the update.
• No — Against the update.
• No with Veto — Strongly against; if more than 33% of votes, the proposal is rejected, and the deposit is burned.
• Abstain — I abstain but participate in the quorum.

The entire voting history is available at gonka.gg/network/proposals — you can view each proposal, its results, and the list of voters.

GiP is a system for formalizing ideas for the development of the Gonka protocol, launched on February 24, 2026, through GitHub Discussions (issue #795).

Format of each GiP:

• Motivation — what problem the proposal solves.
• Solution — technical description of the solution.
• Roadmap — implementation plan by stages.
• Open Questions — unresolved questions for community discussion.

GiPs are not binding — they do not oblige the team to implement them. But they form community consensus and set the direction for future on-chain proposals. In fact, GiP is “pre-governance”: discussion before voting.

Key GiPs:

• #800 Multi-Model PoC — support for multiple AI models simultaneously. Currently, the network works with Qwen3-235B and Kimi K2.6 (via DevShards since May 2026). MiniMax-M2.7 is being added in v0.2.13. GiP describes the architecture for parallel operation of different models with separate Proof of Useful Work.
• #801 Inference Scaling — subnet architecture for scaling. Part of this GiP has already been implemented in v0.2.11 (subnet inferenced).
• #860 Quality Protocol — routing requests based on response quality. Nodes that provide better results receive more traffic and rewards.

Any participant can create a GiP through GitHub Discussions. The barrier to entry is minimal — only a GitHub account and an understanding of the problem are needed. Active discussions involving the Gonka team and hosts show that the system works: proposals receive feedback, are refined, and move towards implementation.

Community Pool — a fund for the development of the Gonka ecosystem. Approximately 20% of the genesis emission (~200 million GNK) is allocated for grants, bounties, and funding community initiatives.

Bounties for code contributions — the main mechanism for distributing Community Pool funds. Developers receive rewards for PRs in the gonka-ai/gonka repository: from bug fixes to implementing new features. The size of the bounty depends on the complexity and importance of the contribution:

Approval mechanism: bounties are included in the README for upgrade proposals. When hosts vote for a protocol upgrade, they simultaneously approve the list of payments for PRs included in that release. Transparency is complete – anyone can check what was paid for and how much.

In addition to bounties, the Community Pool can fund: ecosystem tool development, marketing, educational initiatives, and research grants. Learn more about earning through GitHub — in a separate article.

A young network is vulnerable: few nodes, low stake, a 51% attack is theoretically possible. Gonka addresses this with several mechanisms.

Guardian System — three trusted nodes, controlled by the Gonka team, with a total of 34% consensus power. Guardians cannot impose decisions (34% < 67% for adoption), but can block a malicious proposal (34% > 33% veto threshold). Key: Guardians are automatically deactivated when the total network power (total_network_power) reaches 10 million units. This is not a manual switch – deactivation is programmed into the protocol.

Collateral system — hosts must deposit GNK as collateral to obtain full weight:

• Base Weight (20%) — unconditional weight, accrued simply for the node's operation.
• Collateral-Eligible (80%) — additional weight, available only with GNK collateral. The collateral amount is proportional to computing power.

Slashing — penalties for violations:

• 20% of collateral — for INVALID inference (node produced an incorrect result).
• 10% of collateral — for downtime (node is unavailable beyond the permissible threshold).

Grace Period — 180 epochs (~6 months), during which new hosts can operate without collateral. This lowers the entry barrier: you can start mining, earn GNK through rewards, and only then deposit collateral. After the Grace Period, a node without collateral receives only 20% of its potential weight.

All these mechanisms are described in GNK tokenomics and are aimed at one goal: to protect the network in its early stages without sacrificing decentralization in the long term.

Governance in Gonka is not a static system, but an evolving process. Here are the key development directions for 2026–2027.

Multi-Model PoC (GiP #800) — implemented: Kimi K2.6 is already running in DevShards since May 2026, MiniMax-M2.7 is being added in v0.2.13 (proposal #54). The next candidates are embedding models for RAG: this will open Gonka to a new class of applications (search engines, corporate knowledge bases, chatbots with memory).

Inference Quality Protocol (GiP #860) — routing by quality. Currently, requests are distributed based on node availability; in the future — based on response quality. Nodes with better hardware and more stable operation will receive priority.

On-chain governance migration (2026–2027) — transition to a full x/gov module from Cosmos SDK. This will provide: formalized proposal types, automatic execution of approved changes, integration with IBC (Inter-Blockchain Communication), and the ability to create governance proposals via any Cosmos-compatible wallet.

You can follow and participate in voting at gonka.gg/network/proposals.