Governança em Gonka: como uma rede descentralizada é gerenciada

A governança na Gonka funciona em dois níveis, cada um com sua própria velocidade e abrangência de decisões.

Operational Voting (minutos) — decisões operacionais dentro da rede. Quando surge uma disputa sobre a validade de uma solicitação de inference ou de um resultado PoC, os hosts votam pelo módulo x/group do Cosmos SDK. O peso do voto é definido pelo PoC weight: quanto mais computação um nó realiza, maior sua influência. Essas votações duram minutos e resolvem conflitos específicos: se o inference foi correto, se o nó fez o seu trabalho.

Governance Voting (dias) — decisões estratégicas sobre o desenvolvimento do protocolo. Atualizações de software, mudanças nos parâmetros da rede, ativação de novos modelos, distribuição de recursos do Community Pool — tudo isso vai a votação de todos os hosts. O período de votação vai de alguns dias a uma semana, para que todos os participantes tenham tempo de analisar a proposta.

A diferença fundamental em relação à maioria dos projetos cripto: o peso do voto é definido pelo Proof of Compute, não pelo staking. Na Gonka não dá para «comprar um voto» simplesmente acumulando tokens na carteira. A influência é proporcional à contribuição de computação real — as GPUs que processam solicitações de IA e geram provas de trabalho. A partir da atualização v0.2.16, passa a contar a potência confirmada na época anterior: um host novo vota com peso zero na sua primeira época, e o aumento de potência adiciona votos a partir da época seguinte. Isso vincula a governança a quem realmente sustenta a arquitetura da rede, e não ao capital especulativo.

Na prática, isso significa que um operador com dois servidores de 8× H100 tem aproximadamente o dobro de votos de um operador com um único servidor desses — porque processa aproximadamente o dobro de solicitações de inference. O sistema se autoequilibra: quem investe mais no funcionamento da rede tem mais influência sobre o seu desenvolvimento.

Atualizar o protocolo Gonka é um processo formalizado, do código à ativação na rede. Cada etapa é transparente e verificável.

Processo de atualização:

1. Pull Request no GitHub — os desenvolvedores (equipe Gonka ou contribuidores) criam um PR no repositório gonka-ai/gonka.
2. Review da comunidade — o código é revisado, discutido e testado. Auditoria CertiK para mudanças críticas.
3. Release — uma nova versão do binário inferenced é compilada.
4. On-chain proposal — é criada uma proposta de atualização na rede com a descrição das mudanças.
5. Deposit + Vote — os hosts fazem o depósito (limiar de ativação) e votam durante o voting period.
6. Cosmovisor — após a aprovação, o Cosmovisor atualiza automaticamente os nós na altura de bloco indicada.

De janeiro a maio de 2026, a rede passou por mais de 13 votações bem-sucedidas — da versão v0.2.2 à v0.2.13. Todas as propostas foram aprovadas. Cronologia dos principais upgrades:

• v0.2.11 (março de 2026, proposal #31) — 673.699 votos «a favor» com 0 «contra». Introduziu o subnet inference — um mecanismo de computação off-chain por meio de sub-redes, que promete um aumento de 100 vezes na capacidade de processamento.
• v0.2.13 (maio de 2026, proposal #54) — aprovada em 21 de maio de 2026 (62,8% «a favor», participação de 39,9% com quórum de 33,4%), ativada no bloco 4267300. Adicionou o MiniMax-M2.7 como terceiro modelo da rede, ativou o Ethereum bridge wiring e reduziu o quórum para 0.25.

Opções de voto:

• Yes — apoio a atualização.
• No — contra a atualização.
• No with Veto — totalmente contra; se passar de 33% dos votos, a proposta é rejeitada e o depósito é queimado.
• Abstain — me abstenho, mas conto para o quórum.

Todo o histórico de votações está disponível em gonka.gg/network/proposals — dá para ver cada proposta, os resultados e a lista de quem votou.

GiP é um sistema de formalização de ideias para o desenvolvimento do protocolo Gonka, lançado em 24 de fevereiro de 2026 através do GitHub Discussions (issue #795).

Formato de cada GiP:

• Motivation — qual problema a proposta resolve.
• Solution — descrição técnica da solução.
• Roadmap — plano de implementação por etapas.
• Open Questions — questões pendentes para discussão com a comunidade.

Os GiP não são binding — eles não obrigam a equipe à sua implementação. No entanto, eles formam o consenso da comunidade e estabelecem a direção para futuras on-chain proposals. De fato, os GiP são «pre-governance»: discussão antes da votação.

GiP chave:

• #800 Multi-Model PoC — suporte para múltiplos modelos de IA simultaneamente. Atualmente, a rede opera com MiniMax M2.7 (adicionado na v0.2.13), DeepSeek V4 Flash (proposal #94) e GLM-5.3 Flash (proposal #101). O GiP descreve a arquitetura para a operação paralela de diferentes modelos com Proof of Useful Work separado.
• #801 Inference Scaling — subnet architecture para escalabilidade. Parte deste GiP já está implementada na v0.2.11 (subnet inference).
• #860 Quality Protocol — roteamento de solicitações considerando a qualidade das respostas. Os nós que oferecem melhores resultados recebem mais tráfego e recompensas.

Qualquer participante pode criar um GiP através do GitHub Discussions. O limite de entrada é mínimo: apenas é necessária uma conta do GitHub e compreensão do problema. As discussões ativas com a participação da equipe Gonka e os hosts demonstram que o sistema funciona: as propostas recebem feedback, são aprimoradas e avançam para a implementação.

Community Pool é o fundo para o desenvolvimento do ecossistema Gonka. Cerca de 20% da emissão gênese (~200 milhões de GNK) foram alocados para subsídios, recompensas e financiamento de iniciativas da comunidade.

Recompensas por contribuições de código — o principal mecanismo para distribuir fundos do Community Pool. Os desenvolvedores recebem uma recompensa por PR no repositório gonka-ai/gonka: desde a correção de bugs até a implementação de novos recursos. O tamanho da recompensa depende da complexidade e importância da contribuição:

Mecanismo de aprovação: as recompensas são incluídas no README das propostas de atualização. Quando os hosts votam na atualização do protocolo, eles aprovam simultaneamente a lista de pagamentos pelos PRs que fazem parte dessa versão. A transparência é total — qualquer um pode verificar o que foi pago e quanto.

Além das recompensas, o Community Pool pode financiar: o desenvolvimento de ferramentas do ecossistema, marketing, iniciativas educacionais e subsídios para pesquisa. Mais detalhes sobre como ganhar através do GitHub — em um artigo separado.

Uma rede jovem é vulnerável: poucos nós, pouco staking, um ataque de 51% é teoricamente possível. Gonka resolve isso com vários mecanismos.

Sistema de Guardiões — três nós confiáveis, controlados pela equipe Gonka, com um total de 34% do poder de consenso. Os Guardiões não podem impor decisões (34% < 67% para aprovação), mas podem bloquear uma proposta maliciosa (34% > 33% limiar de veto). Fundamental: Os Guardiões são desativados automaticamente quando o poder total da rede (total_network_power) atinge 10 milhões de unidades. Isso não é um interruptor manual — a desativação é programada no protocolo.

Sistema Colateral — os hosts devem depositar uma garantia em GNK para obter o peso total:

• Peso Base (20%) — peso incondicional, atribuído pelo simples fato de o nó estar funcionando.
• Elegível para Colateral (80%) — peso adicional, disponível apenas com garantia em GNK. O tamanho da garantia é proporcional ao poder computacional.

Slashing — punição por violações:

• 20% da garantia — por inferência INVÁLIDA (o nó forneceu um resultado incorreto).
• 10% da garantia — por tempo de inatividade (o nó está indisponível além do limite permitido).

Período de Carência — 180 épocas (~6 meses), durante as quais novos hosts podem operar sem garantia. Isso reduz a barreira de entrada: é possível começar a minerar, ganhar GNK através de recompensas e só então depositar o colateral. Após o término do Período de Carência, um nó sem garantia recebe apenas 20% do peso potencial.

Todos esses mecanismos são descritos na tokenomics GNK e visam um único objetivo: proteger a rede na fase inicial, sem sacrificar a descentralização a longo prazo.

A governança em Gonka não é um sistema estático, mas um processo em evolução. Estas são as áreas-chave de desenvolvimento para 2026–2027.

Multi-Model PoC (GiP #800) — implementado: o primeiro em maio de 2026 através do DevShards foi o Kimi K2.6 (posteriormente retirado da rede), o MiniMax-M2.7 foi adicionado na v0.2.13 (proposal #54), o DeepSeek V4 Flash foi conectado em agosto de 2026 (proposal #94), o GLM-5.3 Flash — em setembro de 2026 (proposal #101). Os próximos candidatos são modelos de embedding para RAG: isso abrirá a Gonka para uma nova classe de aplicações (mecanismos de busca, bases de conhecimento corporativas, chatbots com memória).

Inference Quality Protocol (GiP #860) — roteamento por qualidade. Atualmente, as solicitações são distribuídas de acordo com a disponibilidade dos nós; no futuro, será baseado na qualidade das respostas. Os nós com melhor hardware e maior estabilidade receberão prioridade.

On-chain governance migration (2026–2027) — transição para o módulo completo x/gov do Cosmos SDK. Isso trará: tipos de proposal formalizados, execução automática de mudanças aprovadas, integração com IBC (Inter-Blockchain Communication) e a possibilidade de criar governance proposals através de qualquer carteira compatível com Cosmos.

Você pode seguir as votações e participar em gonka.gg/network/proposals.