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 activation on the network. Each 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, tested. CertiK audit for critical changes.
3. Release — a new version of the gonkad binary is assembled.
4. On-chain proposal — an update proposal with a description of changes is created on the network.
5. Deposit + Vote — hosts make a deposit (activation threshold) and vote during the voting period.
6. Cosmovisor — if approved, Cosmovisor automatically updates nodes at the specified block height.

From January to March 2026, the network went through 11+ successful votes — from v0.2.2 to v0.2.11. All proposals were approved. The last major vote — proposal #31 (v0.2.11) — gathered 673,699 “yes” votes with 0 “no” votes. This update introduced subnet inference — a mechanism for off-chain computations via subnets, promising a 100x increase in throughput.

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 forfeited.
• Abstain — I abstain, but participate in the quorum.

The entire voting history is available at gonka.gg/network/proposals — you can view each proposal, 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 — 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. But they form community consensus and set 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. The network currently operates with Qwen3-235B; this 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 inference).
• #860 Quality Protocol — request routing considering response quality. Nodes providing better results receive more traffic and rewards.

Any participant can create a GiP via GitHub Discussions. The entry threshold 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) — simultaneous support for multiple models. The first candidate is embedding models for RAG. This will open Gonka to a completely new class of applications: search engines, corporate knowledge bases, chatbots with memory.

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

On-chain governance migration (2026–2027) — transition to a full-fledged 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 through any Cosmos-compatible wallet.

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