Governance in Gonka: How a Decentralized Network is Managed

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

Operational Voting (minutes) — day-to-day decisions within the network. When a dispute arises over the validity of an inference request or a PoC result, hosts vote through the Cosmos SDK x/group module. Voting weight is determined by PoC weight — the more compute a node performs, the greater its influence. Such votes last minutes and resolve specific conflicts: whether an inference was correct, whether a node did its job.

Governance Voting (days) — strategic decisions about the protocol's development. Software upgrades, changes to network parameters, activation of new models, allocation of Community Pool funds — all of this goes to a vote of all hosts. The voting period is from several days to a week, so that all participants have time to review the proposal.

The key difference from most crypto projects: voting weight is determined by Proof of Compute, not by staking. In Gonka you can't "buy a vote" simply by accumulating tokens in a wallet. Influence is proportional to real compute contribution — the GPUs that process AI requests and generate proofs of work. Since the v0.2.16 upgrade, the power confirmed in the previous epoch counts: a new host votes with zero weight for its first epoch, and added power contributes votes starting from the next epoch. This ties governance to those who actually support the network architecture, rather than to speculative capital.

In practice this means: an operator with two servers of 8× H100 each has roughly twice as many votes as an operator with one such server — because they process roughly twice as many inference requests. The system is self-balancing: those who invest more in the network's operation have more influence over its development.

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

The upgrade process:

1. Pull Request on GitHub — developers (the Gonka team or contributors) open a PR in the gonka-ai/gonka repository.
2. Community review — the code is inspected, discussed, and tested. CertiK audits critical changes.
3. Release — a new version of the inferenced binary is built.
4. On-chain proposal — an upgrade proposal is created on the network describing the changes.
5. Deposit + Vote — hosts make a deposit (the activation threshold) and vote during the voting period.
6. Cosmovisor — once approved, Cosmovisor automatically upgrades the 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. Every proposal was approved. Here's a timeline of the key upgrades:

• v0.2.11 (March 2026, proposal #31) — 673,699 votes in favor with 0 against. Introduced subnet inference — an off-chain computing mechanism via subnets that promises a 100x throughput increase.
• v0.2.13 (May 2026, proposal #54) — approved on May 21, 2026 (62.8% in favor, 39.9% turnout against a 33.4% quorum), activated at block 4267300. Added MiniMax-M2.7 as the third model on the network, activated Ethereum bridge wiring, and lowered the quorum to 0.25.

Vote options:

• Yes — I support the upgrade.
• No — I'm against the upgrade.
• No with Veto — I'm strongly opposed; if more than 33% vote this way, the proposal is rejected and the deposit is burned.
• Abstain — I abstain but still count toward the quorum.

The full voting history is available at gonka.gg/network/proposals — you can view every 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, via GitHub Discussions (issue #795).

Format of each GiP:

• Motivation — the problem the proposal addresses.
• 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 obligate the team to implement them. However, they form community consensus and set the direction for future on-chain proposals. In fact, GiPs are "pre-governance": a discussion before a vote.

Key GiPs:

• #800 Multi-Model PoC — support for multiple AI models simultaneously. Currently, the network works with MiniMax M2.7 (added in v0.2.13), DeepSeek V4 Flash (proposal #94), and GLM-5.3 Flash (proposal #101). The GiP describes the architecture for the parallel operation of different models with separate Proof of Useful Work.
• #801 Inference Scaling — subnet architecture for scaling. Part of this GiP is already implemented in v0.2.11 (subnet inference).
• #860 Quality Protocol — request routing based on response quality. Nodes that provide the best results receive more traffic and rewards.

Any participant can create a GiP via GitHub Discussions. The barrier to entry is minimal — you only need a GitHub account and an understanding of the problem. Active discussions with the participation of the Gonka team and hosts show that the system works: proposals receive feedback, are refined, and move toward 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 areas for 2026–2027.

Multi-Model PoC (GiP #800) — implemented: the first to arrive in May 2026 via DevShards was Kimi K2.6 (later removed from the network), MiniMax-M2.7 was added in v0.2.13 (proposal #54), DeepSeek V4 Flash was connected in August 2026 (proposal #94), and GLM-5.3 Flash in September 2026 (proposal #101). 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, it will be based on response quality. Nodes with better hardware and more stable performance will receive priority.

On-chain governance migration (2026–2027) — migration to the full x/gov module from the 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 votes at gonka.gg/network/proposals.