# Gonka Docs — Full Documentation > This file contains the complete text of all documentation from gonkadocs.com, > formatted for AI agent consumption. Generated from markdown sources. > Source: https://gonkadocs.com > Auto-generated — always reflects the latest synced content. --- # Gonka Protocol Documentation ## Errors # Errors 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 2025/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 ``` It’s not actually an error. It just indicates that your node hasn’t been assigned a model yet. Most likely, this is because your node hasn’t participated in a Sprint, hasn’t received Voting Power, and therefore hasn’t had a model assigned. If your node has already passed PoC, you shouldn’t see this log anymore. If not, PoC takes place every ~24 hours. --- ## FAQ # FAQ ## Overview ### What is Gonka? Gonka 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. - In terms of Blockchain, Gonka 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. - In terms of Network, Gonka is a comprehensive ecosystem of participants, including Hosts and Developers that interact through a 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. ### What problem is Gonka solving? 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. ### Who are the key participants in the Gonka ecosystem? The Gonka ecosystem has four key participant groups: - Developer builds and deploys AI applications by leveraging the network’s distributed computing power. - Gonka Contributor participates in development of the core blockchain codebase, protocol upgrades, performance optimizations, security patches, and new feature integrations. - Holder holds the network’s native coin, which simply means having a Gonka wallet with coins in it. Holders may hold coins, transfer or sell them, spend them on inference and use them according to the protocol rules. Being a holder does not imply any obligation, responsibility, or governance role beyond standard coin ownership. - Host contributes compute capacity to the network. Hosts perform inference and other computational tasks and are rewarded proportionally to their contributed compute capacity, as long as they maintain honest participation and reliability. Hosts form the backbone of the network. Only Hosts have voting power in the network. This voting power represents their weight in governance and is used to propose and vote on protocol decisions, parameter changes, and upgrades. Any Host acts as Validator, Transfer Agent and an Executor (these are not predefined or on-chain roles, but dynamic operational functions assumed when processing a inference request). ### What is the GNK coin? 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. ### Can I buy GNK coin? Native GNK is **not listed on any centralized exchange (CEX)** yet, so you cannot buy it on a CEX. Follow official announcements on [Twitter](https://x.com/gonka_ai) for any updates regarding listings. There are, however, two legitimate ways to obtain GNK today: - **Mine as a Host.** Contribute computational resources to the network and earn GNK directly. See [mine as a Host](https://gonka.ai/host/quickstart/). - **Buy WGNK on Ethereum and bridge it back to GNK.** GNK can be bridged to Ethereum as **WGNK** (wrapped GNK), which is a standard ERC-20 that trades on DEXs such as Uniswap. You can buy WGNK there and then [bridge it back to native GNK](cross-chain-transfers/ethereum-bridge/withdraw-gnk.md). See the [Ethereum bridge overview](cross-chain-transfers/ethereum-bridge/overview.md). > **Track WGNK price and market data** You can follow WGNK (wrapped GNK) price, market cap, and trading volume on: - [CoinGecko](https://www.coingecko.com/en/coins/wrapped-gonka) - [CoinMarketCap](https://coinmarketcap.com/currencies/gonka/) - [Uniswap](https://app.uniswap.org/explore/tokens/ethereum/0x972a7a92d92796a98801a8818bcf91f1648f2f68) > **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. ### What makes the protocol efficient? 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](https://gonka.ai/whitepaper.pdf). ### How does the network operate? The network's operation is collaborative and depends on the role you wish to take: - As a [Developer](https://gonka.ai/developer/quickstart/): You can use the network's computational resources to build and deploy your AI applications. - As a [Host](https://gonka.ai/host/quickstart/): You can contribute your computational resources to power the network. The protocol is designed to reward you for your contribution, ensuring the network's continuity and sovereignty. ### Is this documentation exhaustive? 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. ### What is the incentive for contributing computational resources? We've created a dedicated document focused on [Tokenomics](https://gonka.ai/tokenomics.pdf), where you can find all the information about how the incentive in being measured. ### What are the hardware requirements? You can find the minimum and recommended [hardware specifications](https://gonka.ai/host/hardware-specifications/) clearly outlined in the documentation. You should review this section to ensure your hardware meets the requirements for effective contribution. ### What wallets can I use to store GNK coins? You can store GNK coin in several supported wallets within the Cosmos ecosystem: - [Keplr](https://www.keplr.app/) - [Cosmostation](https://cosmostation.io/products/application) - `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](https://www.leapwallet.io/), 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. ### Where can I find useful information about Gonka? Below are the most important resources for learning about the Gonka ecosystem: - [gonka.ai](https://gonka.ai/) — the main entry point for project information and ecosystem overview. - [Whitepaper](https://gonka.ai/whitepaper.pdf) — technical documentation describing the architecture, consensus model, Proof-of-Compute, etc. - [Tokenomics](https://gonka.ai/tokenomics.pdf) — project tokenomics overview, including supply, distribution, incentives, and economic design. - [GitHub](https://github.com/gonka-ai/gonka/) — access to the project’s source code, repositories, development activity, and open-source contributions. - [Discord](https://discord.com/invite/RADwCT2U6R) — the primary place for community discussions, announcements, and technical support. - [X (Twitter)](https://x.com/gonka_ai) — news, updates, and announcements. ## Tokenomics ### How is governance power calculated in Gonka? Gonka uses a PoC-weighted voting model: - Proof-of-Compute (PoC): Voting power is proportional to your verified compute contribution. - Collateral commitment: - 20% of PoC-derived voting weight is activated automatically. - To unlock the remaining 80%, you must lock GNK coins as collateral. - This ensures that governance influence reflects real compute work + economic collateral. 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. ### Why does Gonka require locking GNK coins for governance power? 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. ## Collateral ### What is collateral? Collateral is required to activate the collateral-eligible portion of PoC weight after the Grace Period (first 180 epochs). After the Grace Period: - Base Weight (default 20%) is always active. - The remaining weight requires GNK collateral to become active. 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. ### Is collateral required per node or per account? 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. ### Do I need to deposit collateral? Yes, if you want to activate more than the Base Weight. If no collateral is deposited, only the Base Weight remains active. ### How much collateral is required? Formula: ``` Required Collateral = Total Weight × (1 - base_weight_ratio) × collateral_per_weight_unit ``` Because PoC weight may fluctuate across epochs, depositing the exact minimum may result in temporary under-collateralization. Smaller weights may experience proportionally larger relative fluctuations. A buffer of up to 2× the calculated minimum is recommended while collateral levels remain relatively small. ``` Recommended (with conservative buffer): Total Weight × 2 × (1 - base_weight_ratio) × collateral_per_weight_unit ``` ### Can I partially collateralize my weight? Yes. Your total Active Weight consists of: - Base Weight (always active) - Collateral-Eligible Weight (activated proportionally to deposited collateral) If you deposit less than the full required amount: - Base Weight remains fully active - Only the corresponding portion of collateral-eligible weight becomes active - The remaining portion stays inactive Active Weight is calculated as: ``` Active Weight = Base Weight + (Deposited Collateral / Required Collateral) × Collateral-Eligible Weight ``` ### What happens if I do not deposit enough collateral? Your 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. ### When does collateral take effect? Collateral must be deposited before the start of the epoch to be effective. Collateral deposited during an epoch: - does NOT increase weight immediately - applies starting from the next epoch Collateral cannot be increased mid-epoch. ### In what unit do I deposit collateral? Transactions must use ngonka, not GNK. ``` 1 GNK = 1,000,000,000 ngonka ``` Example: ``` 10 GNK = 10,000,000,000 ngonka ``` ### Can collateral be slashed? Yes. Collateral may be slashed for: - Invalid inference - Downtime (Confirmation PoC failure or jail) Invalid inference slashing is capped at once per epoch. Downtime slashing may be applied per jail event. ### What happens to slashed coins? Currently, slashed GNK is permanently burned and removed from circulation. Future governance may change this mechanism. ### Can I withdraw collateral? 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. ### What collateral is NOT - Collateral is NOT voting power. Voting power is derived from PoC weight, not token balance. - Collateral is NOT delegation. Each account must back its own weight. - Collateral is NOT a permanent lock. It can be withdrawn (subject to unbonding). - Collateral was NOT required during the Grace Period (first 180 epochs). ### How are epoch-minted rewards distributed? A fixed amount of GNK is minted each epoch and distributed proportionally to Active PoC Weight. Active Weight determines: - Your share of epoch-minted Reward Coins - Your governance influence If your Active Weight is reduced due to insufficient collateral, your share of epoch rewards decreases proportionally. Inactive weight does not receive rewards. ### Do I need to manually deposit collateral? Yes. Collateral must be deposited by submitting an on-chain transaction. It is not activated automatically. If no collateral is deposited: - Your node continues operating normally. - It is not jailed or disabled. - Only the Base Weight (e.g. 20%) remains active. Your rewards and governance influence will be reduced proportionally. ### Can vested (locked) GNK be used as collateral? No. Collateral must be deposited from your available (unlocked) GNK balance. Vested coins that are not yet released cannot be used as collateral. ## Governance ### What types of changes require a Governance Proposal? Governance Proposals are required for any on-chain changes that affect the network, for example: - Updating module parameters (`MsgUpdateParams`) - Executing software upgrades - Adding, updating, or deprecating inference models - Any other actions that must be approved and executed via the governance module ### Who can create a Governance Proposal? 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](https://github.com/gonka-ai) or [community forums](https://discord.com/invite/RADwCT2U6R)) to increase the likelihood of approval. See [the full guide](https://gonka.ai/governance/transactions-and-governance/). ### What happens if a proposal fails? - If a proposal does not meet quorum → it automatically fails - If the majority votes `no` → proposal rejected, no on-chain changes - If a significant percentage votes `no_with_veto` (above veto threshold) → proposal is rejected and flagged, signaling strong community disagreement - Deposits may or may not be refunded, depending on chain settings ### Can governance parameters themselves be changed? Yes. 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. ### 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? 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: - Granter = account that owns voting power (cold key) - Grantee = account that will submit votes on the granter’s behalf (warm key) 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) === "Command" ``` ./inferenced tx authz grant generic \ --msg-type=/cosmos.gov.v1beta1.MsgVote \ --from= \ --chain-id=gonka-mainnet \ --expiration= \ --home .inference \ --keyring-backend file ``` === "Example response" ``` { "height": "0", "txhash": "8D96FB6FC06FFB928FBC89FE950689CD040C7F338C197BA856175EC7462A3FFA", "codespace": "", "code": 0, "data": "", "raw_log": "", "logs": [], "info": "", "gas_wanted": "0", "gas_used": "0", "tx": null, "timestamp": "", "events": [] } ``` 2) Verify the grant exists (run from any node) === "Command" ``` ./inferenced query authz grants \ --node="http://:26657" \ --output=json | jq . ``` === "Example response" ``` { "grants": [ { "authorization": { "type": "cosmos-sdk/GenericAuthorization", "value": { "msg": "/cosmos.gov.v1beta1.MsgVote" } }, "expiration": "2026-12-03T18:38:18Z" } ], "pagination": { "total": "1" } } ``` 3) Vote using the grantee === "Command" ``` # Find the proposal ID which you are voting for - use it as in the voting body ./inferenced query gov proposals --output json # Prepare the file with the voting body cat > /tmp/authz-vote.json ", "msgs": [ { "@type": "/cosmos.gov.v1beta1.MsgVote", "proposal_id": "", "voter": "", "option": "VOTE_OPTION_YES" } ] } ] } } EOF # Vote using the file ./inferenced tx authz exec /tmp/authz-vote.json \ --from= \ --chain-id=gonka-mainnet \ --home .inference \ --keyring-backend file \ --node="http://:26657" -y ``` === "Example response" ``` { "pagination": { "total": "1" }, "proposals": [ { "deposit_end_time": "2026-03-06T10:40:07.016920026Z", "final_tally_result": { "abstain_count": "0", "no_count": "0", "no_with_veto_count": "0", "yes_count": "0" }, "id": "1", "messages": [ { "type": "cosmos-sdk/MsgSoftwareUpgrade", "value": { "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "height": "406062", "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 }", "name": "v0.2.10", "time": "0001-01-01T00:00:00Z" } } } ], "proposer": "gonka1xfvr8mywcrxrcrryvj8c5d2grvyjdj5c90fd88", "status": 2, "submit_time": "2026-03-04T10:40:07.016920026Z", "summary": "Upgrade Proposal v0.2.10", "title": "Upgrade Proposal v0.2.10", "total_deposit": [ { "amount": "50000000", "denom": "ngonka" } ], "voting_end_time": "2026-03-04T10:50:07.016920026Z", "voting_start_time": "2026-03-04T10:40:07.016920026Z" } ] } ``` Voting options: - `VOTE_OPTION_YES` - `VOTE_OPTION_ABSTAIN` - `VOTE_OPTION_NO` - `VOTE_OPTION_NO_WITH_VETO` 4) Revoke delegation (run from the granter key) === "Command" ``` ./inferenced tx authz revoke /cosmos.gov.v1beta1.MsgVote \ --from= \ --chain-id=gonka-mainnet \ --home .inference \ --keyring-backend file ``` === "Example response" ``` { code: 0 codespace: "" data: "" events: [] gas_used: "0" gas_wanted: "0" height: "0" info: "" logs: [] raw_log: "" timestamp: "" tx: null txhash: A2C3CDA9E95DCF143C0D8981A4F573F1E68879ECF4903B25BA97383C3F2FDFBA } ``` ## Improvement proposals ### What’s the difference between Governance Proposals and Improvement Proposals? Governance Proposals → on-chain proposals. Used for changes that directly affect the network and require on-chain voting. Examples: - Updating network parameters (`MsgUpdateParams`) - Executing software upgrades - Adding new models or capabilities - Any modification that needs to be executed by the governance module 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. - Managed as Markdown files in the [/proposals](https://github.com/gonka-ai/gonka/tree/main/proposals) directory - Reviewed and discussed through GitHub Pull Request - Approved proposals are merged into the repository ### How are Improvement Proposals reviewed and approved? 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. - Read the recommended guide first: [https://github.com/gonka-ai/gonka/discussions/795](https://github.com/gonka-ai/gonka/discussions/795). It explains what belongs in Improvement Proposals and how to write a strong, structured proposal. - Publish and discuss improvement proposals in [GitHub Discussions](https://github.com/gonka-ai/gonka/discussions) (preferred); previously they were stored as Markdown files in the `/proposals` directory. - To help the community evaluate your proposal (and improve its chances later in governance), it’s in the proposer’s interest and responsibility to actively gather early feedback and support signals (reactions, comments, concrete concerns). - Share the Discussion link in Discord’s #improvements-proposals channel for reach and visibility, and amplify it through any other channels available to you (including direct outreach to Hosts/miners) to gather practical input and support. - Share context about your experience and expertise in the proposal thread. 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. - Community review: - Active contributors and maintainers discuss the proposal in [GitHub Discussions](https://github.com/gonka-ai/gonka/discussions). Conversation can happen on any platform, but please consolidate the key context back in [GitHub Discussions](https://github.com/gonka-ai/gonka/discussions): it keeps the full history in one place, stays searchable, and is much easier to maintain over time. GitHub is the main source of truth. - Please ask questions, provide feedback, suggestions, refinements, and upvote relevant proposals. Everybody’s attention and participation in this process is essential for sustainable evolution of the chain. - Strong positive feedback and a high number of upvotes signal genuine community demand, allowing teams to treat well-received proposals as part of a community-driven roadmap and begin implementation with confidence in both community alignment and eventual governance approval. Note that feedback from the hosts is essential - it can help structure the project into milestones, unlock partial bounty payments, and even secure grants from the community pool. Ultimately, however, all on-chain updates and payments are subject to governance approval. ### Can an Improvement Proposal lead to a Governance Proposal? Yes. Often, an Improvement Proposal is used to explore ideas and gather consensus before drafting a Governance Proposal. For example: - You might first propose a new model integration as an Improvement Proposal. - After the community agrees, an on-chain Governance Proposal is created to update parameters or trigger the software upgrade. ## Voting ### How does the voting process work? - Once a proposal is submitted and funded with the minimum deposit, it enters the voting period - Voting options: `yes`, `no`, `no_with_veto`, `abstain` - `yes` → approve the proposal - `no` → reject the proposal - `no_with_veto` → reject and signal a strong objection - `abstain` → neither approve nor reject, but counts toward quorum - You can change your vote anytime during the voting period; only your last vote is counted - If quorum and thresholds are met, the proposal passes and executes automatically via the governance module 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 \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` ### How can I track the status of a Governance Proposal? You can query the proposal status at any time using the CLI: ``` export NODE_URL=http://47.236.19.22:18000 ./inferenced query gov tally 2 -o json --node $NODE_URL/chain-rpc/ ``` ## Running a Node ### What if I want to stop mining but still use my account when I come back? To restore a Network Node in the future, it will be sufficient to back up: - cold key (most important, everything else can be rotated) - secres from tmkms: `.tmkms/secrets/` - keyring from `.inference .inference/keyring-file/` - node key from `.inference/config .inference/config/node_key.json` - password for warm key `KEYRING_PASSWORD` ### My node was jailed. What does it mean? Your 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: - **Consensus Key Mismatch**. The consensus key used by your node may differ from the one registered on-chain for your validator. Make sure the consensus key you are using matches the one registered on-chain for your validator. - **Unstable Network Connection**. Network instability or interruptions can prevent your node from reaching consensus, causing missed signatures. Ensure your node has a stable, low-latency connection and isn’t overloaded by other processes. **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://: ./inferenced tx slashing unjail \ --from \ --keyring-backend file \ --chain-id gonka-mainnet \ --gas auto \ --gas-adjustment 1.5 \ --fees 200000ngonka \ --node $NODE_URL/chain-rpc/ ``` Then, to check if the node was unjailed: ``` ./inferenced query staking delegator-validators \ \ --node $NODE_URL/chain-rpc/ ``` When a node is jailed, it shows `jailed: true`. ### How to decommission an old cluster? 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//disable ``` You can list all node IDs with: ``` curl http://localhost:9200/admin/v1/nodes | jq '.[].node.id' ``` 2) 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:///v1/epochs/current/participants ``` Once 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. ### My node cannot connect to the default seed node specified in the `config.env` If your node cannot connect to the default seed node, simply point it to another one by updating three variables in `config.env`. 1. `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= ``` Available genesis API URLs: ``` http://185.216.21.98:8000 http://36.189.234.197:18026 http://36.189.234.237:17241 http://node1.gonka.ai:8000 http://node2.gonka.ai:8000 http://node3.gonka.ai:8000 https://node4.gonka.ai http://47.236.26.199:8000 http://47.236.19.22:18000 http://gonka.spv.re:8000 ``` 2. `SEED_NODE_RPC_URL` - Public Tendermint RPC access MUST go through the seed node HTTP(S) proxy path `/`. 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:///chain-rpc ``` Example ``` SEED_NODE_RPC_URL=http://node2.gonka.ai:8000/chain-rpc/ ``` > **Important** - Do NOT use `http://:26657` as a public RPC endpoint. - Port `26657` MUST be internal-only (localhost/private network). Public RPC must go via `/`. 3. `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 `/` proxy. Query the node: ``` http://:/chain-rpc/status ``` Example ``` https://node3.gonka.ai/chain-rpc/status ``` Find `listen_addr` in the response, for example: ``` ""listen_addr"": ""tcp://0.0.0.0:5000"" ``` Use this port: ``` export SEED_NODE_P2P_URL=tcp://: ``` Example ``` export SEED_NODE_P2P_URL=tcp://node3.gonka.ai:5000 ``` Final result example ``` export SEED_API_URL=http://node2.gonka.ai:8000 export SEED_NODE_RPC_URL=http://node2.gonka.ai:8000/chain-rpc/ export SEED_NODE_P2P_URL=tcp://node2.gonka.ai:5000 ``` ### How to change the seed nodes? There 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)" Once the file `.node_initialized` is created, the system no longer updates seed nodes automatically. After that point: - The seed list is used as-is - Any changes must be done manually - You can add as many seed nodes as you want The format is a single comma-separated string: ``` seeds = "@:,@:" ``` To view known peers from any running node, use chain RPC: ``` curl http://47.236.26.199:8000/chain-rpc/net_info | jq ``` In response, look for: - `listen_addr` - P2P endpoint - `rpc_addr` - RPC endpoint Example: ``` % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 94098 0 94098 0 0 91935 0 --:--:-- 0:00:01 --:--:-- 91982 { "jsonrpc": "2.0", "id": -1, "result": { "listening": true, "listeners": [ "Listener(@tcp://47.236.26.199:5000)" ], "n_peers": "50", "peers": [ { "node_info": { "protocol_version": { "p2p": "8", "block": "11", "app": "0" }, "id": "ce6f26b9508839c29e0bfd9e3e20e01ff4dda360", "listen_addr": "tcp://85.234.78.106:5000", "network": "gonka-mainnet", "version": "0.38.17", "channels": "40202122233038606100", "moniker": "my-node", "other": { "tx_index": "on", "rpc_address": "tcp://0.0.0.0:26657" } }, ... ``` This displays all peers the node currently sees. === "Option 2. Reinitialize the Node (seeds auto-applied from environment)" 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 docker compose down node sudo rm -rf .inference/data/ .inference/.node_initialized sudo mkdir -p .inference/data/ ``` After restarting the node, it will behave like a fresh installation and recreate its configuration, including the seeds from the environment variables. To verify which seeds were actually applied: ``` sudo cat .inference/config/config.toml ``` Look for the field: ``` seeds = [...] ``` ### How are Hardware, Node Weight, and ML Node configuration actually validated? The 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](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. ### How to switch to `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8`, upgrade ML Nodes, and remove other models? > **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](./host/quickstart.md) and [Multi-Model PoC — Host Operations Guide](./host/multi_model_poc.md). 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-FP8` - `Qwen/Qwen3-32B-FP8` `Qwen/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: - All your ML Nodes serve `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8`. This is the only model that contributes to PoC v2 weight. - All your ML Nodes are upgraded to a PoC v2–compatible image: - ghcr.io/product-science/mlnode:3.0.12-post3 - ghcr.io/product-science/mlnode:3.0.12-post3-blackwell > **Important** - Serving the correct model without upgrading the ML Node is not sufficient. - Nodes that do not meet both conditions will not be eligible once the network switches to a single-model configuration. - The ML Node upgrade must be completed before the migration is finished and PoC v2 is activated through a separate governance proposal following the v0.2.8 upgrade. - The v0.2.8 upgrade itself does not enable PoC v2. **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 ``` Look for the field: ``` "timeslot_allocation": [ true, false ] ``` Interpretation: - First boolean: Whether the node is serving inference in the current epoch - Second boolean: Whether the node is scheduled to serve inference in the next PoC **Recommended behavior** - Prefer changing the model only on nodes where the second value is `false` - This reduces risk while PoC v2 behavior is still being observed - Gradual rollout across epochs is encouraged **4. 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 huggingface-cli download Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 ``` Use ML Node Management API to switch ML Node to a supported model (`Qwen/Qwen3-235B-A22B-Instruct-2507-FP8`). For example: ``` curl -X PUT "http://localhost:9200/admin/v1/nodes/node1" \ -H "Content-Type: application/json" \ -d '{ "id": "node1", "host": "inference", "inference_port": 5000, "poc_port": 8080, "max_concurrent": 800, "models": { "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8": { "args": [ "--tensor-parallel-size", "4", "--max-model-len", "240000" ] } } }' ``` Changes applied via the Admin API will replace model for the next epoch ([https://gonka.ai/host/mlnode-management/#updating-an-existing-mlnode](https://gonka.ai/host/mlnode-management/#updating-an-existing-mlnode)) `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 ``` NVIDIA Blackwell GPUs ``` image: ghcr.io/product-science/mlnode:3.0.12-post3-blackwell ``` Apply changes and restart services. From `gonka/deploy/join`: ``` source config.env docker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull docker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d ``` **6. 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 ``` Optionally re-check node allocation: ``` curl http://127.0.0.1:9200/admin/v1/nodes ``` > **Governance 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: - Hosts are able to serve `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` or `Qwen/Qwen3-32B-FP8` - Hosts must switch their ML Nodes to serve `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` and upgrade them to PoC v2-compatible versions in order to contribute to PoC v2 weight. - The network observes adoption to assess Host readiness for moving to PoC v2 weights. **Stage 2. Governance proposal (optional, future)** Once a sufficient level of adoption among active Hosts is observed (approximately 50%): - A separate governance proposal may be submitted - This proposal may request approval to activate PoC v2 and use PoC v2 for weight assignment 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: - PoC v2 remains inactive for weight assignment - The existing PoC mechanism continues to be used to determine weight **Summary checklist** Before PoC v2 activation, ensure that: - ML Node serves `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` - All other models are removed from the configuration - ML Node image is `3.0.12-post3` (or `3.0.12-post3-blackwell`) ## Keys & security ### Which CLI version should be used for warm keys created after the v0.2.9 upgrade? For granting permissions to new warm keys created after the v0.2.9 upgrade, the CLI [version v0.2.9](https://github.com/gonka-ai/gonka/releases/tag/release/v0.2.9) should be used. ### Where can I find information on key management? You can find a dedicated section on [Key Management](https://gonka.ai/host/key-management/) in the documentation. It outlines the procedures and best practices for securely managing your application's keys on the network. ### I Cleared or Overwrote My Consensus Key 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 \ \ --validator-key \ --keyring-backend file \ --unordered \ --from \ --timeout-duration 1m \ --node http:///chain-rpc/ \ --chain-id gonka-mainnet ``` ### I Deleted the Warm Key Back up the **cold key** on your local device, outside the server. 1) Stop the API container: ``` docker compose down api --no-deps ``` 2) 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 ``` 4) Then execute inside the container: ``` printf '%s\n%s\n' "$KEYRING_PASSWORD" "$KEYRING_PASSWORD" | \ inferenced keys add "$KEY_NAME" --keyring-backend file ``` 5) [LOCAL]: From your local device (where you backed up the cold key), run the transaction: ``` ./inferenced tx inference grant-ml-ops-permissions \ gonka-account-key \ \ --from gonka-account-key \ --keyring-backend file \ --gas 2000000 \ --node http:///chain-rpc/ ``` 6) Start the API container: ``` source config.env && docker compose up -d ``` ## Proof-of-Compute (PoC) ### What is Proof-of-Compute? 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 Proof of Compute. ### What is Sprint? 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. ### How to simulate Proof-of-Compute (PoC)? 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](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](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://:/api/v1/stop" \ -H "Content-Type: application/json" ``` Now you can send a request to initiate PoC: ``` curl -X POST "http://:/api/v1/pow/init/generate" \ -H "Content-Type: application/json" \ -d '{ "node_id": 0, "node_count": 1, "block_hash": "EXAMPLE_BLOCK_HASH", "block_height": 1, "public_key": "EXAMPLE_PUBLIC_KEY", "batch_size": 1, "r_target": 10.0, "fraud_threshold": 0.01, "params": { "dim": 1792, "n_layers": 64, "n_heads": 64, "n_kv_heads": 64, "vocab_size": 8196, "ffn_dim_multiplier": 10.0, "multiple_of": 8192, "norm_eps": 1e-5, "rope_theta": 10000.0, "use_scaled_rope": false, "seq_len": 256 }, "url": "http://api:9100" }' ``` Send this request to `8080` 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](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: 2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 0: GpuGroup(devices=[0], primary=0) (VRAM: 79.2GB) 2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 1: GpuGroup(devices=[1], primary=1) (VRAM: 79.2GB) 2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 2: GpuGroup(devices=[2], primary=2) (VRAM: 79.2GB) 2025-08-25 20:53:33,568 - pow.compute.controller - INFO - Group 3: GpuGroup(devices=[3], primary=3) (VRAM: 79.2GB) 2025-08-25 20:53:33,758 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [0] 2025-08-25 20:53:33,944 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [1] 2025-08-25 20:53:34,151 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [2] 2025-08-25 20:53:34,353 - pow.compute.controller - INFO - Using batch size: 247 for GPU group [3] ``` Then the service will start sending generated nonces to `DAPI_API__POC_CALLBACK_URL`. ``` 2025-08-25 20:54:58,822 - pow.service.sender - INFO - Sending generated batch to http://api:9100/ ``` The http://api:9100 url won’t be available if you paused the api container or if ML Node container and api containers don’t share the same docker network. Expect to see error messages saying that the ML Node failed to send generated batches. The important part is to make sure that the generation process is happening. ### What does a confirmation ratio of 0 mean, and what should I do if this happens? A 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: - API node misconfiguration or downtime - publicly exposed admin or management ports that allow access to ML Nodes - consensus node lagging behind the chain, which may delay PoC participation beyond the allowed window - ML Node driver failures 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. ## Performance & troubleshooting ### How do I protect my node from DDoS attacks using the proxy pre-release (v0.2.8)? A new proxy version is available with rate limiting and DDoS protection measures. What’s New: - Rate limiting on API/RPC endpoints, as protection against excessive requests that have been affecting network nodes - Blocks resource-intensive internal routes like `training` and `poc-batches` - Optional disabling of `/chain-api`, `/chain-rpc`, and `/chain-grpc` endpoints **Update 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 ``` > **Important** 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 ``` Disable the training URL that was used for recent attacks: ``` sed -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 ``` After this, your proxy configuration should look like: ``` proxy: container_name: proxy image: ghcr.io/product-science/proxy:0.2.8-pre-release-proxy@sha256:6ccb8ac8885e03aab786298858cc763a99f99543b076f2a334b3c67d60fb295f ports: - "${API_PORT:-8000}:80" - "${API_SSL_PORT:-8443}:443" environment: - NGINX_MODE=${NGINX_MODE:-http} - SERVER_NAME=${SERVER_NAME:-} - GONKA_API_PORT=9000 - GONKA_API_EXEMPT_ROUTES=chat inference - GONKA_API_BLOCKED_ROUTES=poc-batches training - CHAIN_RPC_PORT=26657 - CHAIN_API_PORT=1317 - CHAIN_GRPC_PORT=9090 - DASHBOARD_PORT=5173 - DISABLE_CHAIN_API=${DISABLE_CHAIN_API:-true} - DISABLE_CHAIN_RPC=${DISABLE_CHAIN_RPC:-true} - DISABLE_CHAIN_GRPC=${DISABLE_CHAIN_GRPC:-true} ``` **Step 3:** Pull and restart proxy ``` docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull proxy source ./config.env && docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d --no-deps proxy ``` **Step 4:** Close External Port 26657 You 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 ``` This will comment out the port mapping in your node container: ``` node: container_name: node ... ports: - "5000:26656" #p2p #- "26657:26657" #rpc ``` **Step 5:** Restart the node: ``` source ./config.env && docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d --no-deps node ``` **Accessing Node Status After Closing Port 26657** If you previously accessed the node status using `curl -s http://localhost:26657/status`, you can now access it from within the containers: === "Option 1: From the proxy container (using `curl`)" ``` docker exec proxy curl -s node:26657/status | jq ``` === "Option 2: From the node container (using `wget`)" ``` docker exec node wget -qO- http://localhost:26657/status | jq ``` For 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)\""' ``` ### How much free disk space is required for a Cosmovisor update, and how can I safely remove old backups from the `.inference` directory? 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-`. 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 cd .inference ls -la # view the list of folders. There will be folders like data-backup... DO NOT DELETE ANYTHING EXCEPT THESE rm -rf ``` ### How to prevent unbounded memory growth in NATS? NATS 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. 1. Install the NATS CLI. Install Golang by following the instructions here: [https://go.dev/doc/install](https://go.dev/doc/install). Then install the NATS CLI: ``` go install github.com/nats-io/natscli/nats@latest ``` 2. If you already have the NATS CLI installed, run: ``` nats stream info txs_to_send --server localhost: nats stream info txs_to_observe --server localhost: ``` ### How to change `inference_url`? You may need to update your `inference_url` if: - You changed your API domain; - You moved your API node to a new machine; - You reconfigured HTTPS / reverse proxy; - You are migrating infrastructure and want your Host entry to point to a new endpoint. 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: - If the participant does not exist, the transaction creates a new one; - If the participant already exists, only three fields may be updated: `InferenceURL`, `ValidatorKey`, `WorkerKey`. All other fields are preserved automatically. This means updating `inference_url` is a safe, non-destructive operation. 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 \ \ --validator-key \ --keyring-backend file \ --unordered \ --from \ --timeout-duration 1m \ --node http:///chain-rpc/ \ --chain-id gonka-mainnet ``` Verify the update by following the link below and replacing the ending with your node address [http://node2.gonka.ai:8000/chain-api/productscience/inference/inference/participant/gonka1qqqc2vc7fn9jyrtal25l3yn6hkk74fq2c54qve](http://node2.gonka.ai:8000/chain-api/productscience/inference/inference/participant/gonka1qqqc2vc7fn9jyrtal25l3yn6hkk74fq2c54qve) ### Why is my `application.db` growing so large, and how do I fix it? 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`: ``` ... pruning = "custom" pruning-keep-recent = "1000" pruning-interval = "100" ``` New 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`: === "OPTION 1: Full resync from snapshot" 1) Stop node ``` docker stop node ``` 2) Remove data ``` sudo rm -rf .inference/data/ .inference/.node_initialized sudo mkdir -p .inference/data/ ``` 3) Start node ``` docker start node ``` This approach may take some time during which the node will not be able to record transactions. Please use available trusted nodes to download snapshot. === "OPTION 2: Resync from local 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 cp -r .inference/config .inference/temp/config mkdir -p .inference/temp/data/ ``` 1.2) Copy snapshots: ``` cp -r .inference/data/snapshots .inference/temp/data/ ``` 1.3) List snapshots ``` inferenced snapshots list --home .inference/temp ``` Copy height for the latest snapshot. 1.4) Start restoring from snapshot ( `node` container is still running) ``` inferenced snapshots restore 3 --home .inference/temp ``` This 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 ``` 2.2) Move original `application.db` ``` mv .inference/data/application.db .inference/temp/application.db-backup mv .inference/wasm .inference/wasm.db-backup ``` 2.3) Replace it with new one ``` cp -r .inference/temp/data/application.db .inference/data/application.db cp -r .inference/temp/wasm .inference/wasm ``` 2.4) Start `node` container (from another terminal window): ``` docker start node ``` 3) Wait till `node` container is synchronized and delete `.inference/temp/` If you have several nodes, it is recommended cleaning one by one. === "OPTION 3: Experimental" Additional option might be to start separate instance of `node` container on separate CPU only machine and setup in strict validator mode: - preserve really short history - limit RPC and API access only to `api` container Once 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](https://discord.com/invite/RADwCT2U6R). === "OPTION 4: Upgrade to the pruning fix" 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](https://github.com/Lelouch33) and is included in release [`0.2.10-post6`](https://github.com/gonka-ai/gonka/compare/main...release/v0.2.10-post6). With the updated logic and the following settings, `application.db` can remain around 100 GB: - `SNAPSHOT_INTERVAL=1000` - `SNAPSHOT_KEEP_RECENT=2` - `pruning-keep-recent = "20000"` - `pruning-interval = "512"` References: - [https://github.com/gonka-ai/gonka/issues/819#issuecomment-3996332369](https://github.com/gonka-ai/gonka/issues/819#issuecomment-3996332369) - [https://github.com/gonka-ai/gonka/pull/867](https://github.com/gonka-ai/gonka/pull/867) 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) echo "--- Pre-flight Check: Confirmation PoC Status ---" && \ CONFIRMATION_POC_ACTIVE=$(curl -sf "https://node3.gonka.ai/v1/epochs/latest" | jq -r '.is_confirmation_poc_active') && \ [ "$CONFIRMATION_POC_ACTIVE" = "false" ] && \ echo "OK: No confirmation PoC active" && \ sudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.10-post7/ .inference/data/upgrade-info.json && \ sudo mkdir -p .inference/cosmovisor/upgrades/v0.2.10-post7/bin/ && \ wget -q -O inferenced.zip 'https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.10-post7/inferenced-amd64.zip' && \ echo "5ed8941d50779fa2359a9745263b324b887465104f81073827321945ab1f392a inferenced.zip" | sha256sum --check && \ sudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.10-post7/bin/ && \ sudo chmod +x .inference/cosmovisor/upgrades/v0.2.10-post7/bin/inferenced && \ echo "Inference Installed and Verified" && \ # Link Binary echo "--- Final Verification ---" && \ sudo rm -rf .inference/cosmovisor/current && \ sudo ln -sf upgrades/v0.2.10-post7 .inference/cosmovisor/current && \ echo "d9093b225cbd531afc56c99d0b0996b1fa2896c0745cd73293f0de08132f7754 .inference/cosmovisor/current/bin/inferenced" | sudo sha256sum --check && \ # Restart source config.env && docker compose up node --no-deps --force-recreate -d ``` ### Automatic `ClaimReward` didn’t go through, what should I do? If you have unclaimed reward, execute: ``` curl -X POST http://localhost:9200/admin/v1/claim-reward/recover \ -H "Content-Type: application/json" \ -d '{"force_claim": true, "epoch_index": 106}' ``` To check if you have unclaimed reward you can use: ``` curl http://node2.gonka.ai:8000/chain-api/productscience/inference/inference/epoch_performance_summary/106/ | jq ``` ## Upgrades ### Upgrade v0.2.14: Pre-upgrade Bridge Update To 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** ```yaml bridge: container_name: bridge image: ghcr.io/product-science/bridge:0.2.14-post3 ``` **Restart bridge container** ```bash source config.env && docker compose up --force-recreate bridge ``` ### Upgrade v0.2.12: Pre-Upgrade Model Cleanup > **Important** 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/`. 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: - [Bash](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.12/proposals/governance-artifacts/update-v0.2.12/cleanup/cleanup_models.sh) - [Python](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.12/proposals/governance-artifacts/update-v0.2.12/cleanup/cleanup_models.py). ```bash ADMIN=${ADMIN:-http://127.0.0.1:9200} KEEP=${KEEP:-Qwen/Qwen3-235B-A22B-Instruct-2507-FP8} APPLY=${APPLY:-"--apply"} curl -sS "$ADMIN/admin/v1/config" | jq -r --arg k "$KEEP" ' .nodes[] | "\(.id): " + ( if (.models | has($k) | not) then "skip (\(.models | keys))" elif (.models | length) == 1 then "ok" else "\(.models | keys) -> [\($k)]" end)' if [[ "$APPLY" == "--apply" ]]; then curl -sS "$ADMIN/admin/v1/config" \ | jq -c --arg k "$KEEP" \ '.nodes[] | select((.models | has($k)) and (.models | length > 1)) | .models = {($k): .models[$k]}' \ | while IFS= read -r p; do id=$(jq -r .id /dev/null && echo "$id: updated" done echo "done; persisted within 60s" else echo "preview only; rerun without APPLY=dry to commit" fi ``` Wait 60 seconds after running the script to ensure the changes are persisted before triggering the upgrade. Then, verify the configuration: ```bash curl -sS http://127.0.0.1:9200/admin/v1/config \ | jq '.nodes[] | {id, models: (.models | keys)}' ``` Expected output: ```json { "id": "", "models": [ "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8" ] } ``` *(Additional nodes will follow the same format)* ### Upgrade v0.2.12: Pre-download binaries ``` # 1. Create Directories sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.12/bin \ .inference/cosmovisor/upgrades/v0.2.12/bin && \ # 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable wget -q -O decentralized-api.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/decentralized-api-amd64.zip" && \ echo "d0143a95e12e1ada06cfea5e4d3deab13534c3523c967e9a6b87ac9f9bf3247d decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \ echo "DAPI Installed and Verified" && \ # 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable sudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.12/bin/ && \ wget -q -O inferenced.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/inferenced-amd64.zip" && \ echo "df7656503d39f6703767d32d5578d1291e32cb114844d8c1cd0f134d1bf4babd inferenced.zip" | sha256sum --check && \ sudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.12/bin/ && \ sudo chmod +x .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \ echo "Inference Installed and Verified" && \ # 4. Cleanup and Final Check rm decentralized-api.zip inferenced.zip && \ echo "--- Final Verification ---" && \ sudo ls -l .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \ sudo ls -l .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \ echo "94ce943338d12844028e84fe770106c9d28d866cf0af99f27da30f56d69efa34 .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api" | sudo sha256sum --check && \ echo "642eb9858cd77d182f3e1c4d44553f5379d615983430e1fd8e85f09632af4271 .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced" | sudo sha256sum --check ``` ## Bounty program ### What is the bounty program? Who can participate? How are rewards paid? It’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: - **Security vulnerabilities** are handled through Gonka’s official program on **[HackerOne](https://hackerone.com/)**. See [How do I report a security vulnerability?](#how-do-i-report-a-security-vulnerability) below. - **Protocol contributions** (fixes, improvements, and new features) are proposed, reviewed, and validated by the community on GitHub, and rewards are paid out through a network upgrade in a stablecoin. See [How do I contribute to protocol development?](#how-do-i-contribute-to-protocol-development) below. ### How do I report a security vulnerability? Gonka runs its security program on **HackerOne**. Submit all vulnerability reports through the official form at **[gonka.ai/docs/report-vulnerability](https://gonka.ai/docs/report-vulnerability/)** rather than disclosing them in public issues, pull requests, or chats. How rewards work on HackerOne: - **Payment is made right after your report is triaged** on HackerOne — it does **not** require you to also submit a fix. - **Fixing the issue is rewarded separately**, in addition to the report itself. - The authoritative severity model, reward amounts, categories, scope, and eligibility rules are all defined by the program on HackerOne. **Always read the full program terms on HackerOne before submitting**, as they take precedence over any summary here. ### What is the vulnerability severity model? 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 ``` Impact is evaluated from a network perspective (a network-wide effect is required for High/Critical). Issues affecting only one participant typically cap at Low or Medium. **Impact 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-chain | **Likelihood** - **Organic — Unintentional;** occurs under normal conditions. Estimate by probability (how often conditions trigger it, usage patterns). - **Intentional — Profitable** — Exploited for financial gain. Higher likelihood when gain is large and cost/complexity is low. - **Intentional — Griefing** — Exploited to cause disruption. Higher likelihood when network-wide effect and low cost; single-participant griefing → lower likelihood. **Risk Matrix** | Impact \ Likelihood | High | Medium | Low | |---------------------|----------|----------|---------------| | Critical | Critical | Critical | High | | High | Critical | High | Medium | | Medium | High | Medium | Low | | Low | Medium | Low | Informational | ### How do I contribute to protocol development? If you want to help develop the protocol (not report a security issue), the workflow is community-driven on GitHub: 1. **Find or create work.** Look for [existing issues labeled `up-for-grabs`](https://github.com/gonka-ai/gonka/issues?q=is%3Aissue%20state%3Aopen%20label%3Aup-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. 2. **Open a pull request.** Ship a solid fix or implementation and open a PR against [`gonka-ai/gonka`](https://github.com/gonka-ai/gonka/). 3. **Gather community validation.** Share the PR in the relevant developer channels and seek validation from the community so the change can be reviewed and included in a network upgrade. **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. ### Where do I propose and discuss ideas for the protocol? - Publish your ideas as **[GitHub Discussions](https://github.com/gonka-ai/gonka/discussions)**. Start with the welcome guide at **[Welcome to Proposals #795](https://github.com/gonka-ai/gonka/discussions/795)**, which explains what belongs there and how to write a strong, structured proposal. - Gather feedback from the community across the channels where it is active — Telegram groups, other community groups, and the [Gonka Discord](https://discord.com/invite/RADwCT2U6R). Please consolidate the key context back into GitHub Discussions so the full history stays searchable and in one place. ### Where can I see the current protocol priorities? The community-aligned **[Gonka Network Development Roadmap](https://github.com/gonka-ai/gonka/blob/main/proposals/gonka-network-development-roadmap.md)** 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. ### Where can I see who was paid bounties, for what, and when? 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](https://github.com/gonka-ai/gonka/). Use them as the main source of truth for who was paid, what the reward was for, and when it was executed. ## Errors ### `No epoch models available for this node` 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 2025/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 ``` It’s not actually an error. It just indicates that your node hasn’t been assigned a model yet. Most likely, this is because your node hasn’t participated in a Sprint, hasn’t received Voting Power, and therefore hasn’t had a model assigned. If your node has already passed PoC, you shouldn’t see this log anymore. If not, PoC takes place every ~24 hours. ### How do I fix `err="no validator signing info found"` when starting from a state sync snapshot? 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):** 1. Stop the node: ``` docker stop node ``` 2. In `.inference/config/app.toml`, set: ``` iavl-disable-fastnode = true ``` 3. Start the node: ``` docker start node ``` After a restart, the issue should not recur. `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. ## Inference ### Why does the 4,096 output token limit cause the model to stall during thinking — returning zero tokens? **This is about you if** - You see `content=null` and `finish_reason=length`. - The model is "silent" — usage shows tokens, but there's no text. - A probe request with `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. ```json { "model": "moonshotai/Kimi-K2.6", "messages": [ {"role": "user", "content": "Write hello world in Python."} ], "max_tokens": 4096, "thinking": {"type": "disabled"}, "thinking_token_budget": 0, "temperature": 0.2 } ``` Why 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). - **The model ID is case-sensitive:** `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 `` and the model ID case): ```bash curl -sS https:///v1/chat/completions \ -H "Authorization: Bearer $GONKA_API_KEY" \ -H "Content-Type: application/json" \ -d @payload.json ``` If 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: ```bash curl https:///v1/chat/completions \ -H 'content-type: application/json' \ -H "Authorization: Bearer $GONKA_API_KEY" \ -d '{ "model": "moonshotai/Kimi-K2.6", "messages": [{"role": "user", "content": "one word"}], "max_tokens": 100 }' ``` | Gateway version | Expected result | |----------------|---------------------| | `devshard ≥ 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 `…` blocks. **Both sections (`` and visible content) consume `max_tokens` equally.** With small `max_tokens` the model burns the entire budget inside `` and returns only ``, 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+):** | Condition | What the gateway does | |---------|---------------------| | `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:** - Re-test against a broker with gateway ≥ 0.2.13 (release 2026-05-23+). - See zero tokens — capture the `id` from the response and send it to the broker. To extract it: ```bash curl ... | jq .id ``` Format: `devshard--`, 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. ### With Kimi K2, the entire token limit can be spent on thinking with no actual output. Is this an output cap, bandwidth, or upstream issue? **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 `` and visible content. This is not bandwidth and not an output cap. **Two escape hatches** 1. **`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`. 2. **`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: | Config | usage.completion_tokens | Wall-clock | |---|---|---| | `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:** - Tool-heavy / agentic flows without reasoning — `"thinking": {"type": "disabled"}` (Kimi) or `"enable_thinking": false` (Qwen, translated automatically). - Complex reasoning — set `thinking_token_budget` explicitly (don't rely on the default `max_tokens / 2`). - If `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 input token cap for Kimi is 4k tokens, and the output cap is 8,192 tokens. When will these limits be raised? **The numbers in the question are incorrect** - **Output cap: 3,072 tokens** on both tested brokers (they return `finish_reason=length` at exactly 3,072 even with `max_tokens=8000`). - **Input: up to 240,000 tokens** (`--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): 1. The gateway default `DefaultRequestMaxTokens = 3,072` is not overridden by the broker operator. 2. The broker operator set `request_max_tokens_cap = 3,072` per-model via an admin endpoint (`POST /v1/admin/settings`). 3. An upstream DAPI or host-side cap (e.g. vLLM `--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()`): ```text ModelArgs: ["--max-model-len","240000", "--tool-call-parser","kimi_k2", "--reasoning-parser","kimi_k2"] VRam: 720 (GB) ``` The 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](https://github.com/gonka-ai/gonka/issues/818)). For large payloads (>50k), landing on a "small" node is systematic behavior, not transient randomness. **For Inference User:** - The real output cap is determined by the broker — ask them for the `request_max_tokens_cap` value for each model. - Hitting a small input limit — this is almost certainly `--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. - Hitting the output cap — ask the broker to raise it. A network-wide bump (above 4,096) is a code change; raise it through a GitHub Discussion on `gonka-ai/gonka`. **For Broker:** - Raising the cap per-model is a single admin call via `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. - A network-wide bump (above 4,096) is a PR to the gateway code + a new release. Stable demand for large outputs — open a Discussion. ### Agents like Hermes, OpenClaw with 30k+ system prompts fail on Kimi. Why? **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`)** - Native context 256K — the model card in `docs/chat-api/` (the exact filename is planned as part of the chat-api docs set). - Mainnet deploy params (on-chain) — `inference-chain/app/upgrades/v0_2_12/upgrades.go:kimiGovernanceModel()`. - Body / message limits (10 MiB, ≤ 2,048 messages) — `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](https://github.com/gonka-ai/gonka/issues/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](https://github.com/gonka-ai/gonka/issues/1229) (opened in May 2026), blockers for agentic scenarios — long reasoning chains, tool-call compatibility, continuation after exceeding output limits. **Quick self-diagnosis checklist** 1. Remove the fields `tags`, `enforced_tokens`, `plugins`, `strict`, `guided_json`, `guided_regex`, `guided_grammar`, `guided_choice` one at a time. Resend the same request after each removal. 2. If none of the removals helped — check the schema depth in `tools[].function.parameters` (≤ 16) and the total number of nodes (≤ 256), see Q9. 3. The payload is clean and it still fails — this is network-level (issue #818). Workaround: retry or split the request. **For Inference User:** - First check the payload against the whitelist in `docs/chat-api/README.md` (planned). Most Hermes / OpenClaw 400s are due to a single field or schema. - **Generic broker messages like "upstream model provider rejected" are misleading:** some brokers collapse specific gateway 400s into a generic message, some pass through the original (`"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.** - The payload is clean and it still fails — network-level (issue #818). Workaround: retry or split; on sustained >50k payloads a single retry is often not enough — split. **For Broker:** - (1) Show the native context window for each model (on the landing page, via the `/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. - **UX:** the gateway returns specific 400s with field names and messages (`"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). ### Why does Kimi generate malformed JSON for tool calls when output exceeds 4k–8k tokens? 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.: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](https://github.com/vllm-project/vllm/pull/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](https://github.com/vllm-project/vllm/issues/17790). Related: `` inside `` breaks hermes parsing — [vLLM #42021](https://github.com/vllm-project/vllm/issues/42021). These don't depend on Gonka — awaiting an upstream fix. **For Inference User:** - **Rewrite `tool_call.id` on the client side** before sending subsequent messages, into the canonical format `functions.:` — the official Moonshot recommendation, duplicated in `docs/chat-api/troubleshooting.md#reject-duplicate-tool-call-id` (planned). An alternative is fresh UUIDs. - **Don't dedup by id** — two calls with the same id may contain different results. Losing them = losing the agent's work. - **Raise `max_tokens`** for responses with tool calls; large `arguments` blobs quickly hit the cap. - A generic broker error "upstream model provider rejected" usually means a gateway-side reject, not the model. First check the message and the ID for duplicates, then suspect the model (see broker differences in Q4). **For Broker:** - Considering gateway-side dedup-by-id — two tool calls with the same ID may contain different results; it's safer to **rewrite the ID into the canonical format** `functions.:` (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. - **UX:** pass through the specific gateway error message (`"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. ### Could enabling guided decoding fix the token cap issue? **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 | Notes | |------|-----------|------------|---------| | `response_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 parameter `structured_outputs` is 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:** - Need maximum portability across brokers and models — use `response_format` (works everywhere). The `structured_outputs` envelope is currently rejected network-wide. - Don't combine `response_format` and `structured_outputs` in one request — HTTP 400. **For Broker:** - Guided decoding doesn't raise throughput. Don't promise it to clients as a solution for the token cap. - Watch for the rollout of PR #1215 (`StructuredOutputsValidator`) on all routes — Qwen3 users are already waiting for the `structured_outputs` envelope for regex / choice / grammar workloads. ### Why does generation speed fluctuate so drastically? And why does the boost apply only to reasoning tokens? 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"](https://github.com/gonka-ai/gonka/issues/818) (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:** - Choose a broker that publishes uptime / p50 TTFT metrics. Available dashboards include [gonka.pw](https://gonka.pw/) and [meter.gonka.gg](https://meter.gonka.gg/) (there may be others; the list is not exhaustive). - On a slow request, remember the payload size: for short ones a retry lands on a different node; for sustained large payloads (>50k) landing on a node with a reduced window is a systematic problem (issue #818), and a retry alone may not work — better to split. - Want to see progress while the model thinks — render `delta.reasoning_content` (or `delta.reasoning`) in the UI, e.g. in a collapsed block. **For Broker:** - The highest-priority shared problem for the whole network. Contribute production logs / traces to [issue #818](https://github.com/gonka-ai/gonka/issues/818) — this gives the core team data they don't have. - Help implement host-side improvements (chunked gossip recovery, per-escrow `lastAfterReq` tracking — tracked in the planned `host-improvements.md` and related issues) — they directly address routing / recovery weak spots. ### Why does speed vary depending on hardware — faster on B200, slower on H200? **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`](https://github.com/kaitakuai/experiments) — not measured on gonka-api.org or gonkagate.com): | GPU | Memory | sm | Qwen3-235B nonces/min per instance | Per-GPU | |-----|--------|-----|------------------------------|---------| | 4×H100 SXM5 | 80 GB HBM3 | 90 | **1,248** @ batch=16 | ~312 | | 4×H200 | 141 GB HBM3e | 90 | **1,408** @ batch=32–64 | ~352 | | 2×B200 | 192 GB HBM3e | 100 | **1,984** @ batch=64 | **~992** | - **H200 vs H100:** +13% per-GPU. Same chip (sm_90), but HBM3e + 141 GB vs HBM3 + 80 GB → allows a smaller TP for large models and a faster KV cache. - **B200/B300 vs H100/H200:** **~3× per-GPU** on Qwen3-235B FP8. - **Kimi-K2.6 INT4 — specific numbers:** 4×B200 gives 2,240 nonces/min = **~560 per-GPU** (see `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). - **Kimi-K2.6 INT4 on Blackwell:** `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"](https://github.com/gonka-ai/gonka/pull/1046) — 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`](https://github.com/kaitakuai/experiments) (updated regularly), your own per-host stats from [gonka.pw](https://gonka.pw/), and network status from [meter.gonka.gg](https://meter.gonka.gg/). Want to influence the hardware distribution — scale devshard escrow toward hosts with the preferred GPUs. ### Why can't the model use tools properly within Kilo Code? 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 | |---------|---------|-----| | The `tags` 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 | Notes | |---------|---------------------|---------| | `tool_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`](https://github.com/gonka-ai/gonka/blob/main/docs/chat-api/agents.md) (planned). A basic working tool-calling example: [Developer Quickstart §1.4](https://gonka.ai/developer/quickstart/#4-tool-calling). **For Inference User:** - **Reproduce with the same curl that Kilo Code generates** (via the client's debug log or an intermediate proxy). In the 400 body the gateway usually states the name of the rejected field; the broker may mask the message into a generic "upstream rejected" — but the specific problem field is usually one. - **Cross-check against the lists in `agents.md` and `troubleshooting.md`** (planned) — most 400s fall into the documented reject anchors (`#reject-tags`, `#reject-enforced_tokens`, `#reject-structured_outputs-kimi`). - **Quick checklist if the error message is unclear:** check the fields `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). - **The rejected field is not documented** — open an issue on [gonka-ai/gonka](https://github.com/gonka-ai/gonka) with the captured request. **For Broker:** - No link to `agents.md` on the dashboard — a cheap quick-win to add. - Have capacity to file an issue about non-standard fields in `gonka-ai/gonka` — it helps every broker in the ecosystem. ### Agents like Hermes and OpenClaw fail to complete tool tasks on Kimi. Why? **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). 1. **The gateway allocates half of `max_tokens` for thinking by default** (see Q1/Q2). With the default `thinking_token_budget = max_tokens / 2`, it goes to `` 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. 2. **The output cap 3,072 (effective) / 4,096 (network ceiling) is tight for tool-heavy outputs** (Q3). Large `arguments` blobs + visible content easily hit the ceiling. 3. **Upstream vLLM tool-parser bugs** (Q5): duplicate `tool_calls[].id` collisions with `n>1` ([vLLM PR #21259 — UNVERIFIED](https://github.com/vllm-project/vllm/pull/21259)) and the hermes parser `JSONDecodeError` on multiple tool blocks ([vLLM #17790](https://github.com/vllm-project/vllm/issues/17790)). Builder pain point with a link: [issue #1229](https://github.com/gonka-ai/gonka/issues/1229) — long reasoning chains, tool-call compatibility, continuation after exceeding output limits are listed as blockers of agentic coding workflows. **For Inference User:** - **For Kimi this is mandatory:** `"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. - **Control tool_call.id on the client side** — rewrite it into the canonical format `functions.:` (Q5) to avoid the gateway duplicate-id reject. - **Control the schema** — keep depth ≤ 16 and nodes ≤ 256 (Q9). MCP tools with large input schemas may not pass. **For Broker:** - Combine the cap bump (Q3 — per-model `request_max_tokens_cap` via `/v1/admin/settings`) with the recommendations above — it covers the main class of agent failures on your gateway. ### OpenCode cannot apply requested code changes (cuts off mid-sentence). What is causing this? Three causes; the client can work around two, but not the third. 1. **`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. 2. **vLLM crashes on edge-case params** — a series of 8 merged PRs (#1170, #1171, #1172, #1174, #1180, #1212, #1215, #1216) added hardening against fields that crashed the engine. On a recent gateway (≥ `devshard 0.2.13`), most known crash scenarios are cut off by 400 validators instead of crashing. 3. **Host stream drops after receipt** (open — described in the planned `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:** - **For Kimi:** `"thinking": {"type": "disabled"}` + `"max_tokens": 4096`. Large diffs — into several tool calls. - **Long-term:** Q3 on the broker cap and Q5 on the tool-call canonical id format. **For Broker:** document the "split big diffs" pattern in the customer FAQ for coding-agent clients. ### Is there a model that handles both input and output without trade-offs? **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.:` | | Qwen3-235B-A22B-Instruct-2507-FP8 | 128K | 240K | no (Instruct) | hermes parser | | MiniMax-M2.7 | ~180K | 180K | yes (`` in content) | `chatcmpl-tool-` | **MiniMax deploy spec (`inference-chain/app/upgrades/v0_2_13/upgrades.go:minimaxGovernanceModel()`):** ```text ModelArgs: ["--enable-auto-tool-choice", "--kv-cache-dtype", "fp8", "--tool-call-parser", "minimax_m2", "--reasoning-parser", "minimax_m2_append_think"] VRam: 320 GB ThroughputPerNonce: 5000 (Kimi 1500 — MiniMax ×3.3 higher) minimaxStartEpoch: 271 HfCommit: d494266a4affc0d2995ba1fa35c8481cbd84294b ``` **Important differences of MiniMax from Kimi/Qwen:** - **`` 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. - **Tool-call IDs `chatcmpl-tool-`** — 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](https://github.com/gonka-ai/gonka/pull/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. ### Why is there no working web search available? **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`](https://github.com/gonka-ai/gonka/discussions). ### When will reliable web fetching be supported? **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`](https://github.com/gonka-ai/gonka/discussions) so the community converges on common conventions (e.g. a side-car that everyone deploys consistently). ### Context7 docs research — summary fails. Is this the output token limit? 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:** ```json { "model": "moonshotai/Kimi-K2.6", "messages": [ {"role": "system", "content": "You produce structured summaries of technical documents."}, {"role": "user", "content": "Summarize the following document:\n\n"} ], "max_tokens": 4096, "thinking": {"type": "disabled"}, "thinking_token_budget": 0, "response_format": { "type": "json_schema", "json_schema": { "name": "document_summary", "strict": true, "schema": { "type": "object", "additionalProperties": false, "required": ["summary", "key_points"], "properties": { "summary": {"type": "string", "description": "3-5 sentences"}, "key_points": {"type": "array", "items": {"type": "string"}, "minItems": 3, "maxItems": 7} } } } } } ``` **For Inference User:** - Use the payload above as a template. `response_format` compresses the output into the required shape, saving budget. - If the document is long and hits the cap (`finish_reason=length`) — split it into N+1 calls: one fetch+plan, the rest section summaries; stitch them together client-side. - Don't combine `response_format` with the `structured_outputs` envelope — HTTP 400 (Q6). - Schema: depth ≤ 16, nodes ≤ 256 (Q9). **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. ### Gonka has no KV cache. When will caching be added? **Short answer: there's no ETA.** On the Gonka gateway side everything is ready — the blocker is on the upstream vLLM side, issue [#33264](https://github.com/vllm-project/vllm/issues/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** - **Gateway behavior:** `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). - **Upstream blocker:** vLLM uses the `cache_salt` field for prompt-cache isolation (RFC #16016, PR #17045). Aliasing `prompt_cache_key` → `cache_salt` is the open [vLLM #33264](https://github.com/vllm-project/vllm/issues/33264) since January 2026, with no merged PR. - **Security rationale:** simply forwarding `cache_key` without isolation would be unsafe — there are [published prompt-cache timing side-channel attacks (arxiv 2502.07776 PROMPTPEEK)](https://arxiv.org/abs/2502.07776). The gateway cannot implement false cache-isolation guarantees. - **80–90% hit rate is not a Gonka claim.** It's either a misinterpretation of someone's marketing material or confusion with OpenAI / Anthropic native cache (which guarantee sticky routing within a single provider). **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. ### When will image input be enabled for Kimi on the Gonka gateway? **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** 1. **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.** 2. **Independent VLM validation review.** The validation methodology for image inputs needs to be independently confirmed. Issue [#1026](https://github.com/gonka-ai/gonka/issues/1026) (initial research: Qwen2-VL-2B F1=100% intermediate) + [#1198](https://github.com/gonka-ai/gonka/issues/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: 1. Take issue [#1198](https://github.com/gonka-ai/gonka/issues/1198) (up-for-grabs) — the independent VLM validation review is the hardest gating item. 2. Review PR [#1150 "vlm benchmark"](https://github.com/gonka-ai/gonka/pull/1150). 3. When Phase 1-3 of the plan become reachable — prepare the gateway capability registry (Phase 3); the operator config will determine which content types your broker accepts. --- ## Architecture # Architecture ## Inference flow across Gonka 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: - Network Node handles communication and consists of: - a Chain Node that connects to the blockchain - an API Node that manages user requests - One or more ML Nodes (inference) which perform LLM inferences (ML Nodes could be deployed across multiple servers). 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: - **Step 1.** A Client (Developer) selects a random node from the list of active participants (Hosts). This random Host acts as the Transfer Agent (TA) and gets an inference request to its API node. Any Host acts as Validator, TA and an Executor (these are not predefined or on-chain roles, but dynamic operational functions assumed when processing a request). - **Step 2.** The TA randomly selects an Executor among all other active Hosts and passes the inference input to the Executor’s API node. In the meantime, the TA’s Chain Node records inference input on-chain. Note that the on-chain record does not hold back the LLM computation and is made in parallel with the work done by the Executor. - **Step 3.** The Executor’s API node forwards the request to one of its ML Nodes, which begins running inference immediately. - **Step 4.** Once computation is complete, the Executor’s ML Node returns the inference output to the Executor’s API node. - **Step 5.** The Executor’s API node sends the output back to the TA’s API node, while the Executor’s Chain Node records a validation artifact on-chain. - **Step 6.** The TA’s API node returns the output to the Client (Developer), while the TA’s Chain Node records it on-chain. Note that while these on-chain entries contribute to overall network bandwidth constraints, they don’t add overhead to a particular inference computation. ### Performance & Validation 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. ## Proof of Compute (PoC) timeline 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. --- ## Dashboard Maintainer Memo For v0.2.13 # Dashboard Maintainer Memo For v0.2.13 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. ## Main Dashboard Impacts ### 1. New Confirmation Weight Computation 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 `ConfirmationWeightScale` - `inference-chain/x/inference/module/confirmation_weight_scales.go`: `buildConfirmationWeightScales` - `inference-chain/x/inference/types/weight.go`: helper functions for confirmation-weight calculation Implementation guidance: 1. Fetch root epoch group data: ```text /chain-api/productscience/inference/inference/current_epoch_group_data /chain-api/productscience/inference/inference/epoch_group_data/{epoch_id} ``` 2. If root `epoch_group_data.confirmation_weight_scales` exists and is non-empty, use it as the source of truth. 3. 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`. 4. For each scale entry: ```text model_id weight_scale_factor ``` fetch that model subgroup: ```text /chain-api/productscience/inference/inference/epoch_group_data/{epoch_id}?model_id={model_id} ``` 5. Find the participant in that subgroup's `validation_weights`. 6. Compute raw model weight from that subgroup's ML nodes: ```text raw_model_weight = sum(validation_weight.ml_nodes[].poc_weight) ``` Do not use root `validation_weight.weight` as this denominator. 7. Scale and floor each model contribution: ```text scaled_model_weight = floor(raw_model_weight * weight_scale_factor) ``` 8. Sum across all `confirmation_weight_scales` entries: ```text weight_to_confirm = sum(scaled_model_weight) ``` 9. Use root `validation_weights[].confirmation_weight` as the confirmed numerator. 10. If chain participant data has `current_epoch_stats.confirmationPoCRatio`, prefer that as the authoritative displayed ratio. 11. If there is no authoritative chain ratio, local estimate is still: ```text min((confirmation_weight / weight_to_confirm) / 0.909, 1.0) ``` Legacy fallback: - If `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. - This fallback is for pre-v0.2.13 data only. For v0.2.13+ epochs, prefer the snapshot. 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`. ### 2. Cache Reset Needed After Upgrade 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: ```text After chain upgrade: - redeploy dashboard - clear dashboard cache/current epoch cache - recalculate recent reward totals ``` Small checks while doing the main work: - Since upgrade v0.2.13 introduces MiniMax, make sure the dashboard reads model IDs from chain state, not from a hardcoded list. - Make sure MiniMax appearing as a new model does not break model/participant display. ## Practical Checklist - Update dashboard CPoC `weight_to_confirm` logic for `confirmation_weight_scales`. - Iterate only models listed in `confirmation_weight_scales` when that snapshot is present. - Use subgroup ML-node `poc_weight` sums as the raw per-model denominator. - Continue preferring chain `current_epoch_stats.confirmationPoCRatio` when present. - After upgrade, reset dashboard cache or redeploy with cache DB cleared. - Recalculate recent reward totals as part of cache reset. - Check participant table and modal for weight, collateral, rewards, and confirmation ratio display. --- ## Dashboard Maintainer Memo — Gonka v0.2.14 # Dashboard Maintainer Memo — Gonka v0.2.14 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. ## 1. Delegation: weight vs reward **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: - **You display `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. - **You recompute weights yourself and apply delegation on top:** stop applying delegation. The chain doesn't anymore. - **You estimate expected rewards as "participant weight ÷ total weight × epoch pot":** this is now wrong whenever delegation, refusal penalties, or exclusions exist. Use the new endpoint instead: `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`). ## 2. Note: reward recipient override 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}`. ## 3. Note: one-time supply step-down 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. ## 4. Note: deprecated inference endpoints 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. --- ## Glossary # Glossary **AI 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](https://gonka.ai/glossary/#glossary:~:text=Proof%20of%20Compute%20(PoC)%20is,is%20the%20execution%20phase%20of%20PoC.) (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:** - **Developer** builds and deploys AI applications by leveraging the network’s distributed computing power. - **Gonka Contributor** participates in development of the core blockchain codebase, protocol upgrades, performance optimizations, security patches, and new feature integrations. - **Holder** holds the network’s native coin, which simply means having a Gonka wallet with coins in it. Holders may hold coins, transfer or sell them, spend them on inference and use them according to the protocol rules. Being a holder does not imply any obligation, responsibility, or governance role beyond standard coin ownership. - **Host** contributes compute capacity to the network. Hosts perform inference and other computational tasks and are rewarded proportionally to their contributed compute capacity, as long as they maintain honest participation and reliability. Hosts form the backbone of the network. Only Hosts have voting power in the network. This voting power represents their weight in governance and is used to propose and vote on protocol decisions, parameter changes, and upgrades. Any Host acts as Validator, Transfer Agent and an Executor (these are not predefined or on-chain roles, but dynamic operational functions assumed when processing a inference request). **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: - [**Chain Node**](https://github.com/product-science/inference-ignite/tree/main/inference-chain) that connects to the blockchain, maintains the blockchain layer, and handles consensus. - [**API Node**](https://github.com/product-science/inference-ignite/tree/main/decentralized-api) serves as the primary coordination layer between the blockchain (Chain Node) and the AI execution environment (ML Node). It exposes REST/gRPC endpoints for interacting with users, developers, and internal components, while managing work orchestration, validation scheduling, and result verification processes that require off-chain execution. In addition to handling user requests, it is responsible for: - Routing inference and training jobs to the ML Node - Recording inference results and ensuring task completion - Scheduling and managing validation tasks - Reporting receipts and signatures to the Chain Node for consensus - Orchestrating PoC **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. --- ## Get Support on Discord # Get Support on Discord Join the Gonka community on [Discord](https://discord.com/invite/RADwCT2U6R) if you need assistance. --- ## Introduction #Gonka 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: - **Developers** build and deploy AI applications using the network’s distributed power. Getting started, visit the [Developer Quickstart Guide](https://gonka.ai/developer/quickstart/). - **Hosts (hardware providers or nodes)** contribute computational resources to the network and are rewarded based on the amount and quality of resources they provide. To begin contributing, visit the [Host Quickstart Guide](https://gonka.ai/host/quickstart/). This collaboration allows the platform to offer AI services at significantly lower prices, making advanced AI technology more accessible to a broader audience. --- ## Model licenses # Model licenses - [DeepSeek-R1](https://github.com/deepseek-ai/DeepSeek-R1/blob/main/LICENSE) - [DeepSeek-V3](https://github.com/deepseek-ai/DeepSeek-V3/blob/main/LICENSE-MODEL) - [Gemma-3-27B](https://ai.google.dev/gemma/terms) - [gpt-oss-120b](https://huggingface.co/openai/gpt-oss-120b/blob/main/LICENSE) - [Kimi-k2.6](https://huggingface.co/moonshotai/Kimi-K2.6/blob/main/LICENSE) - [Llama-3.1-70B](https://ollama.com/library/llama3:70b/blobs/4fa551d4f938) - [Llama-3.1-405B](https://ollama.com/library/llama3.1:405b/blobs/0ba8f0e314b4) - [MiniMax-M2.7](https://github.com/MiniMax-AI/MiniMax-M2.7/blob/main/LICENSE) - [Qwen3-32B](https://huggingface.co/Qwen/Qwen3-32B/blob/main/LICENSE) - [Qwen3-235B](https://huggingface.co/Qwen/Qwen3-235B-A22B/blob/main/LICENSE) --- ## Announcements # Announcements > **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](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. ## July 22, 2026 **Upgrade v0.2.14: Pre-download binaries** The on-chain governance process for the v0.2.14 upgrade proposal is nearing its conclusion. - Voting ends: July 23rd, 2026, at 00:02 UTC - Upgrade height: 5195700 - Estimated upgrade time: July 23rd, 2026, at ~03:45 UTC Hosts are encouraged to review the proposal on [GitHub](https://github.com/gonka-ai/gonka/pull/1267) and participate in the vote. Pre-downloading binaries in advance may help avoid relying on GitHub availability during the upgrade window. ``` # 1. Create Directories sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.14/bin \ .inference/cosmovisor/upgrades/v0.2.14/bin && \ # 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable wget -q -O decentralized-api.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.14/decentralized-api-amd64.zip" && \ echo "4326a27913a05435e37cd5fa9e3d0cf5271351799f8b01b842e049a733976c87 decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.14/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.14/bin/decentralized-api && \ echo "DAPI Installed and Verified" && \ # 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable sudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.14/bin/ && \ wget -q -O inferenced.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.14/inferenced-amd64.zip" && \ echo "ce857ef90deb899c03d78dee01493e544bf8b7ddf8b452e75b3b010b80a8b046 inferenced.zip" | sha256sum --check && \ sudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.14/bin/ && \ sudo chmod +x .inference/cosmovisor/upgrades/v0.2.14/bin/inferenced && \ echo "Inference Installed and Verified" && \ # 4. Cleanup and Final Check rm decentralized-api.zip inferenced.zip && \ echo "--- Final Verification ---" && \ sudo ls -l .dapi/cosmovisor/upgrades/v0.2.14/bin/decentralized-api && \ sudo ls -l .inference/cosmovisor/upgrades/v0.2.14/bin/inferenced && \ echo "9f41f08d865041c9d1b43e28334528d8d542751af40841f9ddc34d64787e5286 .dapi/cosmovisor/upgrades/v0.2.14/bin/decentralized-api" | sudo sha256sum --check && \ echo "526755f37a0660e9ad9a38f01f99ac87920c7cee12554dc613b274e5e9e3d784 .inference/cosmovisor/upgrades/v0.2.14/bin/inferenced" | sudo sha256sum --check ``` ## July 20, 2026 **v0.2.14 Upgrade Proposal Enters Governance** [The v0.2.14 proposal](https://github.com/gonka-ai/gonka/pull/1267) 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](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](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) 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: - http://node1.gonka.ai:8000 - http://node2.gonka.ai:8000 - https://node3.gonka.ai 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/ ./inferenced tx gov vote 89 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 89 -o json --node $NODE_URL/chain-rpc/ ``` **Required 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](https://gonka.ai/docs/FAQ/#upgrade-v0214-pre-upgrade-api-and-bridge-update). 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/](https://gonka.ai/docs/dashboard-maintainer-memo-v0.2.14/)) **Deadlines** - Voting ends: July 23, 2026 at 00:02 UTC / July 22, 2026 at 17:02 PDT - Proposed upgrade height: 5195700 - Estimated upgrade time: July 23, 2026 at 03:45 AM UTC / July 22, 2026 at 8:45 PM PDT **Attention** - Please plan to be online during the upgrade window so that any follow-up steps or mitigation instructions can be applied promptly. - During upgrades, Cosmovisor creates a full state backup in the `.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.](https://gonka.ai/FAQ/#how-much-free-disk-space-is-required-for-a-cosmovisor-update-and-how-can-i-safely-remove-old-backups-from-the-inference-directory) - If `application.db` occupies a significant amount of disk space, the cleanup techniques described in the cosmovisor backup [guide](https://gonka.ai/FAQ/#why-is-my-applicationdb-growing-so-large-and-how-do-i-fix-it) may be applied. - If approved, devshard storage could optionally be backed by a shared Postgres instance after the upgrade (same env vars as payload storage). Local SQLite would remain the default and would prune automatically (last 3 epochs retained). ## July 20, 2026 **[The PR for the devshard-only](https://github.com/gonka-ai/gonka/pull/1482) 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** - The main intent of v4 is high availability of devshard hosts on host failures and upgrades. It can keep serving new requests if one machine is down or restarting, and on version upgrades multiple machines replace versions one by one. This is the first update in a series of devshard and network-node changes that refactor the monolith toward a high-availability, fault-tolerant, scalable architecture. - v4 is the first version intended for multi-instance HA: N versiond / devshardd replicas behind versiond-router on shared Postgres, with sticky session routing and validation-lease exclusivity. The gateway talks to the chain over gRPC only. Public observability is versionless (/devshard/sessions|stats|metrics); only the escrow owner binds via signed chat. When governance publishes a new binary under the same version name (name unchanged, only sha256 changes), versiond can blue/green swap with drain so in-flight work (including SSE) finishes on the old generation. - v4 also lands bug and security fixes. **Action items** Please review the PR [https://github.com/gonka-ai/gonka/pull/1482](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. ## July 16, 2026 **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. * Declare intent before block **5,105,276** (July 17, ~12:05 UTC): ``` ./inferenced tx inference declare-poc-intent moonshotai/Kimi-K2.6 ``` * Switch your MLNode to Kimi in the ~500-block window before epoch 331 PoC starts (block **5,105,776** — July 17, 12:50:53 UTC / 05:50 PDT). * Delegating hosts: pick non-guardian Kimi hosts and spread weight across independent targets — see the [Multi-Model PoC guide](https://gonka.ai/docs/host/multi_model_poc/). **Devshard 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. ## July 16, 2026 **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** 1. Vote on proposal 88 before the deadline — the expedited window is short. 2. Hosts serving Kimi: declare intent for `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 ``` 3. When delegating for the bootstrap: **do not delegate to guardian nodes**; spread delegations across independent Kimi hosts. See the [Multi-Model PoC guide](https://gonka.ai/docs/host/multi_model_poc/) for updated delegation guidance. 4. Brokers / devshard creators: if any of your gateway traffic is still on v1/v2 or `/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](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) 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: - http://node1.gonka.ai:8000 - http://node2.gonka.ai:8000 - https://node3.gonka.ai 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/ ./inferenced tx gov vote 88 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 88 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** - Voting Time: 2026-07-16 11:09 ~ 2026-07-16 23:09 (PDT) / 2026-07-16 18:09 ~ 2026-07-17 06:09 UTC (expedited, 0.667 yes-threshold; turnout matters, vote promptly). - Intent deadline (epoch 330): block **5,105,276** — July 17, ~12:05 UTC (~05:05 PDT). - Epoch 331 PoC starts: block **5,105,776** — July 17, 12:50 UTC (05:50 PDT). More on how the bootstrap works: [https://gonka.ai/docs/host/kimi-bootstrap/](https://gonka.ai/docs/host/kimi-bootstrap/) ## July 15, 2026 **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](https://gonka.ai/docs/network-updates/#july-15-2026)). 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** 1. Vote on proposal 87 before the deadline — the expedited window is short. 2. Hosts serving Kimi: keep your Kimi setup staged and be ready to switch your MLNode back at the bootstrap PoC. 3. When delegating for the bootstrap: do not delegate to guardian nodes; spread delegations across independent Kimi 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](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) 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: - http://node1.gonka.ai:8000 - http://node2.gonka.ai:8000 - https://node3.gonka.ai 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/ ./inferenced tx gov vote 87 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 87 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** * Voting Time: 2026-07-15 17:01 ~ 2026-07-16 05:01 (PDT) / 2026-07-16 00:01 ~ 2026-07-16 12:01 UTC (expedited, 0.667 yes-threshold; turnout matters, vote promptly). * Bootstrap intent deadline and epoch timings follow in the bootstrap instructions. ## July 15, 2026 **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: * On one server, the MLNode running Kimi died due to a provider-side issue. A large share of Kimi delegations was concentrated on this host, so its failure removed those votes at once. * The second server lost its network node to an out-of-memory condition. 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): 1. [Today] An expedited proposal removes Kimi before the next PoC and re-adds it immediately after. A separate announcement with the proposal ID, voting commands, and deadlines follows. 2. [Tomorrow] Kimi goes through the standard bootstrap flow again: declare intent, deploy window, PoC store commit. Instructions will be published before the intent deadline. **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: * **Do not delegate to guardian nodes.** Guardians are the fallback mechanism for PoC validation. Concentrating delegations on them ties the main mechanism and the fallback to the same hardware — this incident is exactly that failure mode. A protocol-level restriction is under discussion. * **Avoid concentrating delegations on any single host.** Until percentage-based multi-host delegation is supported, spread delegations across several independent hosts that run the model. If you operate multiple nodes, delegate to your own node running the model. * **If you can run Kimi directly — this is the biggest help.** More direct hosts means more validation weight and no single point of failure. **Fixes already in the pipeline** * Guardian voting in PoC validation (guardians can always vote) — v0.2.14. * Self-delegation issue — v0.2.14. * Nonce duplicates — v0.2.14 (currently handled by the earlier API update). * RAM growth on network nodes — fixed in devshard v3; requires migration off v1/v2. After full migration, v1/v2 will be removed and `/v1/devshard` closed. Set separate memory limits for the `api` and `versiond` containers. **Required actions for hosts** 1. Vote on the expedited Kimi proposal once it is on-chain (announcement follows). 2. If you plan to serve Kimi: watch for the bootstrap instructions and be ready to declare intent. 3. If you delegate for Kimi: pick a non-guardian delegate; spread weight across independent hosts where possible. 4. Brokers: migrate devshard traffic to `/devshard/v3` now. This fixes the RAM growth issue and is required before v1/v2 removal. 5. Check RAM on network nodes and set container memory limits (`api`, `versiond`). ## July 11, 2026 **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.](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.14/proposals/governance-artifacts/update-v0.2.13-devshard-v3) 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** - Prepared brokers to keep serving inference during the v0.2.14 chain upgrade without depending on the deprecated classic API path. - Improved RAM utilization. - Fixed gateway runtime behavior. - Enabled safe switching between SQLite and Postgres storage. ## July 8, 2026 **The v0.2.13-devshard-v3 runtime upgrade proposal has entered governance** This proposal covers [the devshard v3 release.](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.14/proposals/governance-artifacts/update-v0.2.13-devshard-v3) 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`: `v3` - `binary`: `https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v3.0.0/devshardd.zip` - `sha256`: `ca1294fc8db3f0907a01f362eb4b13665f66d0fd12cfc6f01468b1e27f0bab63` 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/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](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) 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: - http://node1.gonka.ai:8000 - http://node2.gonka.ai:8000 - https://node3.gonka.ai 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/ ./inferenced tx gov vote 83 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 83 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** Voting ends: July 11th, 2026, at 06:41:34 UTC ## July 8, 2026 **PR Review for Upgrade v0.2.14** [The pull request](https://github.com/gonka-ai/gonka/pull/PR) 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** 1. Active hosts review this proposal on [GitHub.](https://github.com/gonka-ai/gonka/pull/PR) 2. The devshard v3 release is proposed and rolled out before the mainnet chain upgrade. 3. Brokers switch inference traffic to `/devshard/v3`. 4. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain. 5. 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. **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** 1. Now — review the PR. Read PR #1267 on GitHub and leave comments on any findings, questions, suggested improvements, edge cases, or vulnerabilities. 2. Now / before the mainnet upgrade — update your API and bridge. To keep the Ethereum bridge stable during the mainnet upgrade, update the `ap`i 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. 3. Vote on devshard v3. 4. Brokers — switch inference traffic to `/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. 5. Dashboard maintainers — be ready to adjust how metrics are counted. Detailed instructions will be published later, after the `devshard v3` vote has launched and is successfully approaching its conclusion. ## July 6, 2026 **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 sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.13-post7/bin/ wget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.13-post7/decentralized-api-amd64.zip' && \ echo "55de4023119d103683cdbfa41c204274d3189636e4119ea3a2d8afdfa0a6fa47 decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.13-post7/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.13-post7/bin/decentralized-api && \ echo "API Installed and Verified" && \ docker stop api && \ sudo rm -rf .dapi/cosmovisor/current && \ sudo ln -sf upgrades/v0.2.13-post7 .dapi/cosmovisor/current && \ echo "e97d89cfaca98547b5966a87bd99ec6faab9df9eda1782f584a36d49237c01e6 .dapi/cosmovisor/current/bin/decentralized-api" | sha256sum --check && \ docker start api ``` ## June 27, 2026 **Kimi-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** 1. Declare PoC intent during epoch 310, before block **4,797,456** (around June 28, ~12:00 UTC): ``` ./inferenced tx inference declare-poc-intent moonshotai/Kimi-K2.6 ``` 2. If enough hosts declare intent, switch your node to Kimi in the ~500-block window before epoch 311 starts (PoC start around June 28, ~12:47 UTC). **Hosts 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 ``` ~~The guardian node `gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5` 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](https://gonka.ai/docs/host/multi_model_poc/) for updated delegation guidance. **Key timings** * Intent deadline (epoch 310): block **4,797,456** — around June 28, ~12:00 UTC. * Epoch 311 starts: block **4,797,956** — around June 28, ~12:47 UTC. More on how the bootstrap works: [https://gonka.ai/docs/host/kimi-bootstrap/](https://gonka.ai/docs/host/kimi-bootstrap/) ## June 26, 2026 **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](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](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: 1. **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`. 2. **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. 3. **Deploy window.** Hosts that declared intent provision their MLNode for the model during the deploy window. 4. **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** 1. **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. 2. **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. 3. **To stay on MiniMax:** Keep serving `MiniMaxAI/MiniMax-M2.7` - no action needed. 4. **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](https://gonka.ai/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) 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: * http://node1.gonka.ai:8000 * http://node2.gonka.ai:8000 * https://node3.gonka.ai Cast a vote (`yes`, `no`, `abstain`, `no_with_veto`): ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced tx gov vote 79 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 79 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** * Proposal 79 voting ends: *June 26th, 2026, at 14:18:58 UTC* (expedited). * Expedited proposals require a 0.667 yes-threshold; turnout matters, so please vote promptly. ## June 25, 2026 **Proposal 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** 1. The delegation `initial_model_id` is set to `MiniMaxAI/MiniMax-M2.7` — MiniMax is the base model. 2. `MiniMaxAI/MiniMax-M2.7` is the only model in PoC params. 3. `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` and `moonshotai/Kimi-K2.6` are removed from PoC params. 4. `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** * Make sure your MLNode is serving `MiniMaxAI/MiniMax-M2.7`. Any host still on Qwen or Kimi will not receive cPoC for this epoch until it switches. * Hosts that intend to serve Kimi again should keep their Kimi setup staged and be ready to switch the MLNode back at PoC 309 — a vote to restore Kimi follows during epoch 308. **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): * **Restore Kimi K2.6** — re-add Kimi and restart its bootstrap. * **Add GLM-5.2** — add GLM-5.2 **without a non-participation penalty**, so hosts can opt in and demand for the model can be measured in advance, with no penalty for hosts that choose not to serve it. ## June 25, 2026 **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** * **Kimi K2.6 — removed to restore it quickly.** Because Kimi does not have sufficient votes for PoC validation, taking it out and re-bootstrapping it is the fastest path back with minimal downtime. A vote to restore Kimi follows in the next epoch. * **Qwen3-235B — retired (separate, unrelated change).** Retiring the older Qwen3-235B is an independent, previously-requested lineup change. It is not related to the Kimi situation and is included here only because it is also a PoC lineup change. * **MiniMax-M2.7 — promoted to the base model.** 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** 1. **Switch your MLNode to `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. 2. **Vote on proposal 78 before the deadline.** The expedited window is short. 3. Hosts that plan to serve Kimi again should still switch their MLNode to MiniMax now, but be ready to switch it back at PoC 309 — a vote to restore Kimi follows in epoch 308. **Coming next** * **Restore Kimi K2.6** — a follow-up vote in epoch 308 to re-add Kimi and restart its bootstrap. * **GLM-5.2** — a follow-up proposal will add GLM-5.2 **without a non-participation penalty**, so hosts can opt in and demand for the model can be tested in advance, with no penalty for hosts that choose not to serve it. **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](https://gonka.ai/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) 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: * http://node1.gonka.ai:8000 * http://node2.gonka.ai:8000 * https://node3.gonka.ai Cast a vote (`yes`, `no`, `abstain`, `no_with_veto`): ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced tx gov vote 78 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 78 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** * Proposal 78 voting ends: **June 25, 2026, 15:39:53 UTC** (expedited). * Epoch 308 forms shortly after: PoC start ~16:50 UTC, effective ~17:25 UTC. * Expedited proposals require a 0.667 yes-threshold; turnout matters, vote promptly. ## June 22, 2026 **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](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. ## June 15, 2026 **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](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](https://github.com/gonka-ai/gonka/blob/devshard-0.2.13-v2/devshard/docs/upgrade.md) and [the versioned package](https://github.com/gonka-ai/gonka/tree/devshard-0.2.13-v2/versioned) for details. **Key Changes** 1. 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 2. Add internal devshard traces and metrics through OpenTelemetry and Prometheus 3. Add join-stack observability with Grafana, Jaeger, Prometheus, Loki, Promtail, and cAdvisor 4. Store per-inference validation counters outside the state root in SQLite/Postgres and expose per-slot totals through devshard stats endpoints after inference pruning 5. 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](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) 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: - http://node1.gonka.ai:8000 - http://node2.gonka.ai:8000 - https://node3.gonka.ai 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/ ./inferenced tx gov vote 76 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 76 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** Voting ends: June 17th, 2026, at 23:39:02 UTC ## June 6, 2026 **[The PR for the devshard-only upgrade](https://github.com/gonka-ai/gonka/pull/1289) 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. ## May 28, 2026 **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](https://gonka.ai/docs/host/quickstart/#optional-poc-delegation-and-refusal)). ## May 26, 2026 **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`. ## May 25, 2026 **Upgrade v0.2.13: pre-download binaries and MiniMax-M2.7 weights** The v0.2.13 upgrade proposal (proposal id [54](https://github.com/gonka-ai/gonka/pull/1143)) has passed on-chain governance and the upgrade is now scheduled. - Upgrade height: 4267300 - Estimated upgrade time: May 26, 2026, 14:42 UTC (07:42 PDT) Pre-downloading binaries and weights in advance helps avoid relying on GitHub / Hugging Face availability during the upgrade window. ``` # 1. Create Directories sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.13/bin \ .inference/cosmovisor/upgrades/v0.2.13/bin && \ # 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable wget -q -O decentralized-api.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13/decentralized-api-amd64.zip" && \ echo "cf31fa4d715e721d1e17b7e2b46d628a0b66b6ef603d352d587abe1d57c40925 decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.13/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.13/bin/decentralized-api && \ echo "DAPI Installed and Verified" && \ # 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable sudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.13/bin/ && \ wget -q -O inferenced.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13/inferenced-amd64.zip" && \ echo "ea7dea6c4e8d96ed61005bed196768cc9f44e5fb17f0714cb64d1d00a485be0c inferenced.zip" | sha256sum --check && \ sudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.13/bin/ && \ sudo chmod +x .inference/cosmovisor/upgrades/v0.2.13/bin/inferenced && \ echo "Inference Installed and Verified" && \ # 4. Cleanup and Final Check rm decentralized-api.zip inferenced.zip && \ echo "--- Final Verification ---" && \ sudo ls -l .dapi/cosmovisor/upgrades/v0.2.13/bin/decentralized-api && \ sudo ls -l .inference/cosmovisor/upgrades/v0.2.13/bin/inferenced && \ echo "f93d579ef9c46ade9f28c73c339df2f7ae73607115b7efeb849316984924f68d .dapi/cosmovisor/upgrades/v0.2.13/bin/decentralized-api" | sudo sha256sum --check && \ echo "e52b86c4f64a47f0ea9bdb3327feb321b8a4208a76b35d52a7e9ddd1b9d6eed5 .inference/cosmovisor/upgrades/v0.2.13/bin/inferenced" | sudo sha256sum --check ``` ## May 22, 2026 **v0.2.13 voting concluded — preparing for upgrade at height 4267300** The on-chain governance vote for [Upgrade Proposal v0.2.13](https://github.com/gonka-ai/gonka/pull/1143) (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** 1. Make sure your bridge container is up to date and synced. The Ethereum mainnet bridge contract (`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](https://gonka.ai/docs/network-updates/#may-7-2026). 2. If you plan to serve `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. 3. Right after the upgrade lands, every host will need to declare a participation mode for **each** governance-approved model — `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. 4. Plan to be online during the upgrade window so any follow-up steps or mitigation instructions can be applied promptly. Make sure `.inference/data` has sufficient free space for the cosmovisor state backup; if `application.db` is large, consider applying [the cleanup techniques](https://gonka.ai/FAQ/#why-is-my-applicationdb-growing-so-large-and-how-do-i-fix-it) from the cosmovisor backup guide before the upgrade. 5. 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](https://github.com/gonka-ai/gonka/pull/1143) - Migration logic: [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.13/inference-chain/app/upgrades/v0_2_13/upgrades.go) ## May 20, 2026 **v0.2.13 Upgrade Proposal Enters Governance** [The v0.2.13 proposal](https://github.com/gonka-ai/gonka/pull/1143) 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. - Includes: Recalibrated weights for Kimi (`0.78`), new model `MiniMaxAI/MiniMax-M2.7`, validation thresholds update, devshard storage rework, plus several PoC/reward fixes. - Activates the Ethereum bridge on mainnet (see dedicated section below). - The proposal extends the post-upgrade grace window to 3000 blocks so hosts are not penalized while the new snapshot logic stabilizes. - Governance: reduces genesis-guardian voting power to ~25% and sets the chain-wide quorum to 0.25. If guardians abstain, non-guardians need roughly ⅓ turnout among the remaining 75% to satisfy quorum (see inference-chain section). - Required preparation: bridge container check, MiniMax decision, dashboard update, cast vote. - Nothing on chain changes until and unless the proposal is approved. The PR: [https://github.com/gonka-ai/gonka/pull/1143](https://github.com/gonka-ai/gonka/pull/1143) **Key changes** **Models** - Adds `MiniMaxAI/MiniMax-M2.7` as a governance-approved model and PoC model. - Updates inference validation thresholds: - Qwen 235B: `0.940` - Kimi K2.6: `0.900` - MiniMax-M2.7: `0.922` - Recalibrates `WeightScaleFactor` values against the Qwen-on-B200 reference after the vLLM 0.20.1 release: - Qwen 235B: `0.359` (unchanged) - Kimi K2.6: `0.78` (down from 1.26, roughly a 38% reduction in per-epoch consensus weight from Kimi at the same PoC weight) - MiniMax-M2.7: `0.3024` Reference data: [https://docs.google.com/spreadsheets/d/1dHHlbhW1_hVgd7Q6MtmcVSOpmnl7NnynoTzPHJ1oU-g/edit?gid=0#gid=0](https://docs.google.com/spreadsheets/d/1dHHlbhW1_hVgd7Q6MtmcVSOpmnl7NnynoTzPHJ1oU-g/edit?gid=0#gid=0) **inference-chain** - Raises the devshard nonce limit from `20_000` to `1_000_000`. - Raises the max devshards per epoch from `100` to `500_000`. - Fixes confirmation PoC reward accounting during new-model bootstrap. - Disables confirmation PoC for the rest of the upgrade epoch so the new snapshot logic starts cleanly from the next epoch. - Resets `ConsecutiveInvalidInferences` when a participant becomes active again. - Backfills missing `MsgRespondDealerComplaints` authz grants for DAPIs that joined before v0.2.12. - Fixes a wiring issue that could cause intermittent permission errors in bridge and liquidity-pool contract calls. - Reduces genesis guardian adjusted voting power to about 25% and sets the chain-wide governance quorum to `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`). - Add 4 early hosts & brokers to `allowed_creator_addresses`. **Ethereum bridge mainnet activation** - Activates Ethereum mainnet bridge setup through the upgrade handler. - Registers the Ethereum bridge contract address `0x972a7a92d92796a98801a8818bcf91f1648f2f68`, USDC and USDT token metadata, bridge trading approvals, and CW20 `wrapped_token` code ID `105`. - Once activated, the bridge enables cross-chain transfers between Gonka mainnet and Ethereum (including wrapping GNK on Ethereum and bridging USDC/USDT). Wrap/unwrap scripts and operator workflows will be documented separately. **decentralized-api & devshard** - Enables `NodeManagerGrpcPort` by default on port `9400`. - Adds Postgres support for devshard state. - Adds pruning for SQLite and Postgres devshard databases. - Adds state snapshots for faster devshard startup and recovery. - Fixes OpenAI-compatible API response parsing. - Fixes long startup behavior and devshard invalidation flow edge cases. **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.](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.13/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](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 docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer ``` **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](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) 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: - http://node1.gonka.ai:8000 - http://node2.gonka.ai:8000 - https://node3.gonka.ai 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/ ./inferenced tx gov vote 54 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 54 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** - Voting ends: May 22, 2026, 22:12:25 UTC - Proposed upgrade height: 4267300 - Estimated upgrade time: May 26, 2026, 14:42:02 UTC - Timeline for operators: voting ends May 22, 22:12 UTC → upgrade height ~May 26 14:42 UTC → rest of the upgrade epoch runs with confirmation PoC skipped (≤ 10000-block grace window) → MiniMax bootstrap snapshot at start_poc − 500 blocks (~43 min before) → first MiniMax PoC stage at the next epoch boundary after the upgrade → MiniMax penalty enforcement at chain epoch 278. **Attention** - Please plan to be online during the upgrade window so that any follow-up steps or mitigation instructions can be applied promptly. - During upgrades, Cosmovisor creates a full state backup in the `.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.](https://gonka.ai/FAQ/#how-much-free-disk-space-is-required-for-a-cosmovisor-update-and-how-can-i-safely-remove-old-backups-from-the-inference-directory) - If `application.db` occupies a significant amount of disk space, the cleanup techniques described in the cosmovisor backup [guide](https://gonka.ai/FAQ/#why-is-my-applicationdb-growing-so-large-and-how-do-i-fix-it) may be applied. - The proposal would intentionally skip Confirmation PoC from the upgrade height through the end of the upgrade epoch (10000-block grace window). If approved, this skip is expected and not a malfunction; the new snapshot logic would start from the next epoch. - If approved, devshard storage could optionally be backed by a shared Postgres instance after the upgrade (same env vars as payload storage). Local SQLite would remain the default and would prune automatically (last 3 epochs retained). - If the proposal fails (quorum not met, or `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. ## May 18, 2026 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](https://github.com/gonka-ai/gonka/pull/1183) To apply the fix, please: 1. Set container version in docker-compose.yml ``` ... proxy: container_name: proxy image: ghcr.io/product-science/proxy:0.2.12-post5 ... ``` 2. Restart container: ``` source config.env && docker compose up -d proxy --force-recreate --no-deps ``` It'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' ``` ## May 17, 2026 **Epoch #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** 1. Keep your API nodes online and accessible where possible. This helps preserve visibility into host participation and supports any follow-up review. 2. Monitor PoC participation in the next epochs. Check that your node enters PoC as expected and that active weight is reflected correctly. 3. Use only supported inference request formats. Do not send or route inference traffic with non-standard request semantics. 4. Expect temporary inference disruption. Access may not be available everywhere immediately and is expected to return gradually through community proxy and broker endpoints. 5. Share relevant logs or observations in the community channels or this thread. This is especially important if your host was affected in epoch #266 or behaves unexpectedly in the following epochs. ## May 16, 2026 **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. ## May 15, 2026 **v0.2.13 Upgrade Proposal Enters Governance** [v0.2.13 proposal](https://github.com/gonka-ai/gonka/pull/1143) is now on chain and open for voting. - Includes: Recalibrated weights for Kimi (`0.78`), new model `MiniMaxAI/MiniMax-M2.7`, validation thresholds update, devshard storage rework, plus several PoC/reward fixes, Ethereum bridge mainnet activation. - Proposal increases grace window after the upgrade to not punish hosts 3000 blocks after upgrade happens. - Required preparation: bridge container check, MiniMax decision, dashboard update, cast vote. - Nothing on chain changes until and unless the proposal is approved. The PR: [https://github.com/gonka-ai/gonka/pull/1143](https://github.com/gonka-ai/gonka/pull/1143) **Key changes** **Models** - Adds `MiniMaxAI/MiniMax-M2.7` as a governance-approved model and PoC model. - Recalibrates `WeightScaleFactor` values against the Qwen-on-B200 reference after the vLLM 0.20.1 release: - Qwen 235B: `0.359` - Kimi K2.6: `0.78` - MiniMax-M2.7: `0.3024` - Reference data: [https://docs.google.com/spreadsheets/d/1dHHlbhW1_hVgd7Q6MtmcVSOpmnl7NnynoTzPHJ1oU-g/edit?gid=0#gid=0](https://docs.google.com/spreadsheets/d/1dHHlbhW1_hVgd7Q6MtmcVSOpmnl7NnynoTzPHJ1oU-g/edit?gid=0#gid=0) - Updates inference validation thresholds **inference-chain** - Raises the devshard nonce limit from `20_000` to `1_000_000`. - Raises the max devshards per epoch from `100` to `500_000`. - Fixes confirmation PoC reward accounting during new-model bootstrap. - Disables confirmation PoC for the rest of the upgrade epoch so the new snapshot logic starts cleanly from the next epoch. - Resets `ConsecutiveInvalidInferences` when a participant becomes active again. - Backfills missing `MsgRespondDealerComplaints` authz grants for DAPIs that joined before v0.2.12. - Fixes Wasm keeper access for bridge and liquidity-pool contract permission checks. - Reduces genesis guardian adjusted voting power to about 25% and sets the chain-wide governance quorum to `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** - Activates Ethereum mainnet bridge setup through the upgrade handler. - Registers the Ethereum bridge contract address `0x972a7a92d92796a98801a8818bcf91f1648f2f68`, USDC and USDT token metadata, bridge trading approvals, and CW20 `wrapped_token` code ID `105`. **decentralized-api & devshard** - Enables `NodeManagerGrpcPort` by default on port `9400`. - Adds Postgres support for devshard state. - Adds pruning for SQLite and Postgres devshard databases. - Adds state snapshots for faster devshard startup and recovery. - Fixes OpenAI-compatible API response parsing. - Fixes long startup behavior and devshard invalidation flow edge cases. **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.](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.13/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](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 docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer ``` **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](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) 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: - http://node1.gonka.ai:8000 - http://node2.gonka.ai:8000 - https://node3.gonka.ai Cast your vote (`yes`, `no`, `abstain`, `no_with_veto`): ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced tx gov vote 52 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 52 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** - Voting ends: May 17, 2026, 07:58:37 UTC - Proposed upgrade height: 4133422 - Estimated upgrade time: May 18, 2026, 13:03:17 UTC **Attention** - Please plan to be online during the upgrade window so that any follow-up steps or mitigation instructions can be applied promptly. - During upgrades, Cosmovisor creates a full state backup in the `.inference/data` directory; ensure sufficient disk space is available. Guidance on safely removing old backups from the `.inference` directory is available in [the documentation.](https://gonka.ai/FAQ/#how-much-free-disk-space-is-required-for-a-cosmovisor-update-and-how-can-i-safely-remove-old-backups-from-the-inference-directory) - If `application.db` occupies a significant amount of disk space, the cleanup techniques described in the cosmovisor backup [guide](https://gonka.ai/FAQ/#why-is-my-applicationdb-growing-so-large-and-how-do-i-fix-it) may be applied. - The proposal would intentionally skip Confirmation PoC from the upgrade height through the end of the upgrade epoch (3000-block grace window). If approved, this skip is expected and not a malfunction; the new snapshot logic would start from the next epoch. - If approved, devshard storage could optionally be backed by a shared Postgres instance after the upgrade (same env vars as payload storage). Local SQLite would remain the default and would prune automatically (last 3 epochs retained). ## May 7, 2026 **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 ``` Check whether your bridge is already running the correct version: ``` docker inspect --format='{{.Image}}' bridge \ | xargs docker inspect --format='{{range .RepoDigests}}{{.}}{{end}}' \ | grep -q 'sha256:8d2f217115c65b27fcb6fe1497471c30891534f18685bd3007d168aa7f1a9371' \ && echo "BRIDGE v0.2.5-post5 is running" || echo "WARNING: OLD BRIDGE" ``` If the command returns: ``` BRIDGE v0.2.5-post5 is running ``` your bridge container is running the expected image. Please also verify that the bridge is synced: ``` docker logs bridge --tail 10000 | grep "Skeleton sync bounds" | tail -1 ``` The output should point to a recent finalized Ethereum block and should not be significantly behind. If 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 docker compose down bridge && sudo rm -rf .inference-eth source config.env && docker compose pull bridge source config.env && docker compose up bridge -d --force-recreate --no-deps ``` After deployment, verify the version again: ``` docker inspect --format='{{.Image}}' bridge \ | xargs docker inspect --format='{{range .RepoDigests}}{{.}}{{end}}' \ | grep -q 'sha256:8d2f217115c65b27fcb6fe1497471c30891534f18685bd3007d168aa7f1a9371' \ && echo "BRIDGE v0.2.5-post5 is running" || echo "WARNING: OLD BRIDGE" ``` If the bridge fails to synchronize, the Ethereum checkpoint sync endpoint may be unavailable. In that case, update `BEACON_STATE_URL` and restart the bridge: ``` sudo sed -i 's|- BEACON_STATE_URL=.*|- BEACON_STATE_URL=https://beaconstate.info/|' docker-compose.yml source config.env && docker compose up bridge -d --force-recreate --no-deps ``` After updating or restarting the bridge, please also verify that it is synced, as described above. ## May 6, 2026 **PR Review for Upgrade v0.2.13** [The pull request](https://github.com/gonka-ai/gonka/pull/1143) 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** - Confirmation PoC used different model sets for measured weight, preserved weight, and reward rescaling. During new-model bootstrap, this could slash honest miners that served both an eligible model and a not-yet-eligible model. The fix stores one epoch snapshot of confirmable models and weight-scale factors, then uses that snapshot for all confirmation and reward-weight calculations. - `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. - DAPIs that joined before v0.2.12 did not have `MsgRespondDealerComplaints` in their cold-to-warm authz grants. The upgrade backfills that permission so they can respond to dealer complaints. - Devshard settlement used a hardcoded `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`. - The upgrade installs a grace-epoch entry for the current epoch with an extended `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. - Wasm keeper access is resolved after app wiring, so contract permission checks work for bridge and liquidity-pool operations. **decentralized-api** - Some OpenAI-compatible upstreams return numeric `stop_reason` values. `Choice.StopReason` now accepts any JSON type, so those responses no longer fail unmarshalling. - Internal devshard storage migration no longer blocks dapi startup. Devshard routes stay unavailable until migration and recovery finish. **devshard** - Devshard storage could grow forever because old escrow data stayed in one SQLite store. Storage is now epoch-scoped and prunes old epochs in the background, keeping the latest 3 epochs. - Devshard needed a shared storage option for larger deployments. It can now use Postgres as the primary store, with SQLite kept as the local fallback. - Postgres data is partitioned by `epoch_id` for sessions, diffs, and signatures, so pruning can drop old epoch data cleanly. - State snapshots reduce recovery work for long-running sessions. - Payload lookup is pinned to the escrow epoch with fallback for epoch-boundary and legacy epoch-0 requests. - Current-epoch shard stats expose nonce, version, group, and per-host counters. **bridge** - Bridge tooling handles Sepolia flags and converts Gonka BLS keys/signatures to the EIP-2537 format expected by the Ethereum contract. - Adds scripts for GNK and wrapped-token bridge operations. 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/blob/347d947596aba754e453e58d5f82ae6054233a9a/proposals/governance-artifacts/update-v0.2.13/README.md ) - [https://github.com/gonka-ai/gonka/pull/1143](https://github.com/gonka-ai/gonka/pull/1143) ## May 6, 2026 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](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 sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.12-api-post3/bin/ wget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.12-api-post3/decentralized-api-amd64.zip' && \ echo "3f2bc481b8320c53f0abe428dc262eaac5a86e8f38b8d796c409bd7116ba5017 decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12-api-post3/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12-api-post3/bin/decentralized-api && \ echo "API Installed and Verified" docker stop api && \ sudo rm -rf .dapi/cosmovisor/current && \ sudo ln -sf upgrades/v0.2.12-api-post3 .dapi/cosmovisor/current && \ echo "da495bc4c414ac9a0d416f85c30dd8dfbbcc76883fd71f6c1e969d37fa184b20 .dapi/cosmovisor/current/bin/decentralized-api" && \ docker start api ``` After the deploy, double-check that the servers on ports 9100 and 9200 are running: ``` curl http://localhost:9200/admin/v1/nodes # may not be bound to localhost ``` ``` curl http://localhost:9100/versions # may not be bound to localhost ``` ## May 6, 2026 A 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](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 sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.12-api-post2/bin/ wget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.12-api-post2/decentralized-api-amd64.zip' && \ echo "7bef88106fc3464d0141a2d14245cc06c341be186250f5d096e27e901deb185e decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12-api-post2/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12-api-post2/bin/decentralized-api && \ echo "API Installed and Verified" docker stop api && \ sudo rm -rf .dapi/cosmovisor/current && \ sudo ln -sf upgrades/v0.2.12-api-post2 .dapi/cosmovisor/current && \ echo "9882b36ac6e5546fc18e3dd34da293cd5255f311f19e14ace74d3b9190c8ca1d .dapi/cosmovisor/current/bin/decentralized-api" && \ docker start api ``` Besides that, if you have an MLNode hosting Kimi-K2.6, please add the deploy arg "--enable-auto-tool-choice" to the deploy params. To do that, you can repeat the command (example for B200): ``` curl -X POST http://localhost:9200/admin/v1/nodes \ -H "Content-Type: application/json" \ -d '{ "id": "", "host": "", "inference_port": 5050, "poc_port": 8080, "max_concurrent": 500, "models": { "moonshotai/Kimi-K2.6": { "args": [ "--enable-auto-tool-choice", # new parameter "--tensor-parallel-size", "4", "--enable-expert-parallel", "--trust-remote-code", "--mm-encoder-tp-mode", "data", "--tool-call-parser", "kimi_k2", "--reasoning-parser", "kimi_k2", "--attention-backend", "FLASHINFER_MLA", "--disable-custom-all-reduce", "--gpu-memory-utilization", "0.95", "--max-num-seqs", "128", "--max-model-len", "240000" ] } } }' ``` And 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. ## May 5, 2026 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/ ./inferenced tx gov vote 48 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 48 -o json --node $NODE_URL/chain-rpc/ ``` **Voting ends**: 2026-05-05 19:00:54 UTC ## May 4, 2026 **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. ## May 4, 2026 **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/](https://gonka.ai/docs/host/kimi-bootstrap/) ## May 4, 2026 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`. ## May 2, 2026 Today's pre-eligibility validations don't pass, with a minimal weight for hosts whose `PoCIntent` is Verify -> Unzip directly to bin -> Make Executable wget -q -O decentralized-api.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/decentralized-api-amd64.zip" && \ echo "d0143a95e12e1ada06cfea5e4d3deab13534c3523c967e9a6b87ac9f9bf3247d decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.12/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \ echo "DAPI Installed and Verified" && \ # 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable sudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.12/bin/ && \ wget -q -O inferenced.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/inferenced-amd64.zip" && \ echo "df7656503d39f6703767d32d5578d1291e32cb114844d8c1cd0f134d1bf4babd inferenced.zip" | sha256sum --check && \ sudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.12/bin/ && \ sudo chmod +x .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \ echo "Inference Installed and Verified" && \ # 4. Cleanup and Final Check rm decentralized-api.zip inferenced.zip && \ echo "--- Final Verification ---" && \ sudo ls -l .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api && \ sudo ls -l .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced && \ echo "94ce943338d12844028e84fe770106c9d28d866cf0af99f27da30f56d69efa34 .dapi/cosmovisor/upgrades/v0.2.12/bin/decentralized-api" | sudo sha256sum --check && \ echo "642eb9858cd77d182f3e1c4d44553f5379d615983430e1fd8e85f09632af4271 .inference/cosmovisor/upgrades/v0.2.12/bin/inferenced" | sudo sha256sum --check ``` ## April 28, 2026 **Upgrade v0.2.12: Pre-Upgrade Model Cleanup** The v0.2.12 upgrade proposal is now halfway through its on-chain voting period. - Voting ends: April 30th, 2026, at 00:12 UTC - Upgrade height: 3834200 - Estimated upgrade time: April 30th, 2026, at 6:00 am UTC Hosts are encouraged to review the proposal on [GitHub](https://github.com/gonka-ai/gonka/pull/948) 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/`. 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: - [Bash](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.12/proposals/governance-artifacts/update-v0.2.12/cleanup/cleanup_models.sh) - [Python](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.12/proposals/governance-artifacts/update-v0.2.12/cleanup/cleanup_models.py). ```bash ADMIN=${ADMIN:-http://127.0.0.1:9200} KEEP=${KEEP:-Qwen/Qwen3-235B-A22B-Instruct-2507-FP8} APPLY=${APPLY:-"--apply"} curl -sS "$ADMIN/admin/v1/config" | jq -r --arg k "$KEEP" ' .nodes[] | "\(.id): " + ( if (.models | has($k) | not) then "skip (\(.models | keys))" elif (.models | length) == 1 then "ok" else "\(.models | keys) -> [\($k)]" end)' if [[ "$APPLY" == "--apply" ]]; then curl -sS "$ADMIN/admin/v1/config" \ | jq -c --arg k "$KEEP" \ '.nodes[] | select((.models | has($k)) and (.models | length > 1)) | .models = {($k): .models[$k]}' \ | while IFS= read -r p; do id=$(jq -r .id /dev/null && echo "$id: updated" done echo "done; persisted within 60s" else echo "preview only; rerun without APPLY=dry to commit" fi ``` Wait 60 seconds after running the script to ensure the changes are persisted before triggering the upgrade. Then, verify the configuration: ```bash curl -sS http://127.0.0.1:9200/admin/v1/config \ | jq '.nodes[] | {id, models: (.models | keys)}' ``` Expected output: ```json { "id": "", "models": [ "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8" ] } ``` *(Additional nodes will follow the same format)* ## April 27, 2026 **v0.2.12 Upgrade Proposal Enters Governance** [The upgrade proposal](https://github.com/gonka-ai/gonka/pull/948) for the next on-chain software version v0.2.12 has now been published on-chain and is open for voting. **Key changes** - **Multi-model PoC (the largest change)** ([#1039](https://github.com/gonka-ai/gonka/pull/1039)). Transition Proof of Compute from a single fixed model to per-model PoC groups. Each governance-approved model generates its own local PoC weight, which is then aggregated into a total consensus weight via model-specific coefficients. Each host must participate in each model group (either directly or by delegating PoC voting weight). - **`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). - **Devshard standalone runtime** ([#1045](https://github.com/gonka-ai/gonka/pull/1045)). Decouples devshard releases from the DAPI / mainnet release cycle. - **Certik audit fixes** ([#1020](https://github.com/gonka-ai/gonka/pull/1020), [#1021](https://github.com/gonka-ai/gonka/pull/1021), [#1022](https://github.com/gonka-ai/gonka/pull/1022), [#987](https://github.com/gonka-ai/gonka/pull/987), [#949](https://github.com/gonka-ai/gonka/pull/949), [#988](https://github.com/gonka-ai/gonka/pull/988), [#825](https://github.com/gonka-ai/gonka/pull/825), [#1011](https://github.com/gonka-ai/gonka/pull/1011), [#1029](https://github.com/gonka-ai/gonka/pull/1029), [#789](https://github.com/gonka-ai/gonka/pull/789)). Audit findings have been addressed. - **Protocol hardening.** Preserved nodes (`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.](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.12/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 ``` Deploy (important to use `--no-deps`): ``` source config.env && \ docker compose -f docker-compose.yml up versiond proxy -d --no-deps ``` That will activate `devshard` 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](https://gonka.ai/docs/host/multi_model_poc/). **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 docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer ``` **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](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) 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: - [http://node1.gonka.ai:8000](http://node1.gonka.ai:8000) - [http://node2.gonka.ai:8000](http://node2.gonka.ai:8000) - [https://node3.gonka.ai](https://node3.gonka.ai) Cast your vote ( `yes`, `no` , `abstain` , `no_with_veto` ): ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced tx gov vote 44 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 44 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** - Voting ends: April 30th, 2026, at 00:12 UTC - Upgrade height: 3834200 - Estimated upgrade time: April 30th, 2026, at 6:00 UTC **Attention** - Please plan to be online during the upgrade window so that any follow-up steps or mitigation instructions can be applied promptly. - During upgrades, Cosmovisor creates a full state backup in the `.inference/data` directory; ensure sufficient disk space is available. Guidance on safely removing old backups from the `.inference` directory is available in [the documentation.](https://gonka.ai/FAQ/#how-much-free-disk-space-is-required-for-a-cosmovisor-update-and-how-can-i-safely-remove-old-backups-from-the-inference-directory) - If `application.db` occupies a significant amount of disk space, the cleanup techniques described in the cosmovisor backup [guide](https://gonka.ai/FAQ/#why-is-my-applicationdb-growing-so-large-and-how-do-i-fix-it) may be applied. - After the upgrade, Postgres is available as an option for local payload storage. ## April 15, 2025 **PR Review for Upgrade v0.2.12** [The pull request](https://github.com/gonka-ai/gonka/pull/948) 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** - **Multi-model PoC (the largest change)** ([#1039](https://github.com/gonka-ai/gonka/pull/1039)). Transition Proof of Compute from a single fixed model to per-model PoC groups. Each governance-approved model generates its own local PoC weight, which is then aggregated into total consensus weight via model-specific coefficients - **Consensus-level transaction fees with automatic migration** ([#937](https://github.com/gonka-ai/gonka/pull/937), [#981](https://github.com/gonka-ai/gonka/pull/981)). Introduces a governance-controlled gas price. Protocol-duty messages (PoC, validations, inference, BLS DKG) are exempt via `NetworkDutyFeeBypassDecorator`. `MsgPoCV2StoreCommit` charges a two-component fee (base validation + count-linear) as the primary Sybil defense. See [docs/host_onboarding.md](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.12/docs/host_onboarding.md) for details. - **Devshard standalone runtime** ([#1045](https://github.com/gonka-ai/gonka/pull/1045)). Decouples devshard releases from the DAPI / mainnet release cycle. - **Certik audit fixes** ([#1020](https://github.com/gonka-ai/gonka/pull/1020), [#1021](https://github.com/gonka-ai/gonka/pull/1021), [#1022](https://github.com/gonka-ai/gonka/pull/1022), [#987](https://github.com/gonka-ai/gonka/pull/987), [#949](https://github.com/gonka-ai/gonka/pull/949), [#988](https://github.com/gonka-ai/gonka/pull/988), [#825](https://github.com/gonka-ai/gonka/pull/825), [#1011](https://github.com/gonka-ai/gonka/pull/1011), [#1029](https://github.com/gonka-ai/gonka/pull/1029), [#789](https://github.com/gonka-ai/gonka/pull/789)). All known audit findings have been addressed. - **Protocol hardening.** Implements a stronger PoC v2 RNG (full 256-bit entropy vs. previous 32-bit), which will activate via a separate governance vote. 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.](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.12/docs/upgrades.md) **Required actions post-upgrade** Existing Hosts: - Ensure cold account holds sufficient (e.g., 100 GNK) to cover the auto-granted fee allowance spend limit. - Deploy, delegate, or explicitly refuse each governance-approved model for the new model once it’s approved by governance (the included model will be activated 3 epochs after the upgrade) - Deploy `versiond` service from `docker-compose.yml` (using the last commit in the main branch) - Recreate `proxy` container using new version and parameters. The documentation will provide the exact command. ## April 1, 2026 ML Node `3.0.12-post6` available A new mlnode version is now available: `ghcr.io/gonka-ai/mlnode:3.0.12-post6` - docker pull ghcr.io/gonka-ai/mlnode:3.0.12-post6 - docker pull ghcr.io/gonka-ai/mlnode:3.0.12-post6-blackwell - docker pull ghcr.io/gonka-ai/mlnode:3.0.12-post6-blackwell-sm120 This version is now set as the default in the main branch: [https://github.com/gonka-ai/gonka/commit/ec8f45573149ce5686e8e5fc29f1a8f49a295689](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](https://github.com/gonka-ai/vllm/compare/release/v0.9.1-pocv2-post5...release/v0.9.1-pocv2-post6) **Guidance** - Upgrading to this version is recommended - The release is fully compatible with previous versions ## March 20, 2026 **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](https://github.com/gonka-ai/gonka/pull/877)** This upgrade introduces an initial version of `devshards`-based inference sessions intended to improve inference scalability. **[`StartInference` and `FinishInference` performance improvements](https://github.com/gonka-ai/gonka/pull/812)** 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](https://github.com/gonka-ai/gonka/pull/813) **Guidance for Hosts** - **Binary Versions:** Updated via the on-chain upgrade process. - **Migration:** Testing and migration details are documented in the [v0.2.11 documentation](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.11/docs/upgrades.md). Additional details for these changes are available in the governance artifacts: [https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.11/proposals/](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.11/proposals/) ## March 19, 2026 **Upgrade v0.2.11: Pre-download binaries** The on-chain governance process for the v0.2.11 upgrade proposal is nearing its conclusion. - Voting ends: March 20th, 2026, at 05:59:52 UTC - Upgrade height: 3186100 - Estimated upgrade time: March 20th, 2026, at 14:30 UTC Hosts are encouraged to review the proposal on [GitHub](https://github.com/gonka-ai/gonka/pull/813) and vote. Pre-downloading binaries in advance may help avoid relying on GitHub availability during the upgrade window. ``` # 1. Create Directories sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.11/bin \ .inference/cosmovisor/upgrades/v0.2.11/bin && \ # 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable wget -q -O decentralized-api.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.11/decentralized-api-amd64.zip" && \ echo "e574c3d86189daf325cc7008603ee8e952efb028afda5bcd4a154dcd334192d4 decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.11/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.11/bin/decentralized-api && \ echo "DAPI Installed and Verified" && \ # 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable sudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.11/bin/ && \ wget -q -O inferenced.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.11/inferenced-amd64.zip" && \ echo "c77528bd2e31e86355a6eefddb50e0db7f9600ebf2940ca440a61ea36e7ef7ca inferenced.zip" | sha256sum --check && \ sudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.11/bin/ && \ sudo chmod +x .inference/cosmovisor/upgrades/v0.2.11/bin/inferenced && \ echo "Inference Installed and Verified" && \ # 4. Cleanup and Final Check rm decentralized-api.zip inferenced.zip && \ echo "--- Final Verification ---" && \ sudo ls -l .dapi/cosmovisor/upgrades/v0.2.11/bin/decentralized-api && \ sudo ls -l .inference/cosmovisor/upgrades/v0.2.11/bin/inferenced && \ echo "8b99e550ddd117a0cb4293b4ae74e0e5dff961a1986f23b58ec7ae6c3f0478f1 .dapi/cosmovisor/upgrades/v0.2.11/bin/decentralized-api" | sudo sha256sum --check && \ echo "6cf186a75782da07156d4d03b4266cefcb36656de89e4a378ae96d8df89ad003 .inference/cosmovisor/upgrades/v0.2.11/bin/inferenced" | sudo sha256sum --check ``` ## March 18, 2026 **v0.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](https://github.com/gonka-ai/gonka/pull/877)** 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](https://github.com/gonka-ai/gonka/pull/812)** - Reduces unnecessary state writes and query overhead for `MsgStartInference` and `MsgFinishInference`. - Simplifies stats handling and cuts work done during the inference lifecycle for better block execution stability. 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](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](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 docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer ``` **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](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) 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: - [http://node1.gonka.ai:8000](http://node1.gonka.ai:8000) - [http://node2.gonka.ai:8000](http://node2.gonka.ai:8000) - [https://node3.gonka.ai](https://node3.gonka.ai) Cast your vote ( `yes`, `no` , `abstain` , `no_with_veto` ): ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced tx gov vote 31 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 31 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** - Voting ends: March 20th, 2026, at 05:59:52 UTC - Upgrade height: 3186100 - Estimated upgrade time: March 20th, 2026, at 14:30 UTC **Attention** - Please plan to be online during the upgrade window so that any follow-up steps or mitigation instructions can be applied promptly. - During upgrades, Cosmovisor creates a full state backup in the `.inference/data` directory; ensure sufficient disk space is available. Guidance on safely removing old backups from the `.inference` directory is available in [the documentation](https://gonka.ai/FAQ/#how-much-free-disk-space-is-required-for-a-cosmovisor-update-and-how-can-i-safely-remove-old-backups-from-the-inference-directory). - If `application.db` occupies a significant amount of disk space, the cleanup techniques described [here](https://gonka.ai/FAQ/#why-is-my-applicationdb-growing-so-large-and-how-do-i-fix-it) may be applied. - After the upgrade, Postgres is available as an option for local payload storage. ## March 17, 2026 **PR Review for Upgrade v0.2.11** [The Pull Request](https://github.com/gonka-ai/gonka/pull/813) 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](https://github.com/gonka-ai/gonka/pull/877) 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](https://github.com/gonka-ai/gonka/pull/812) - Reduces unnecessary state writes and query overhead for `MsgStartInference` and `MsgFinishInference`. - Simplifies stats handling and cuts work done during the inference lifecycle for better block execution stability. 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](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 docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d explorer ``` Reviewers can find the full upgrade proposal, migration details, testing summary, and proposed process [here](https://github.com/gonka-ai/gonka/pull/813). ## March 16, 2026 **API 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](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) echo "--- Pre-flight Check: Confirmation PoC Status ---" && \ CONFIRMATION_POC_ACTIVE=$(curl -sf "https://node3.gonka.ai/v1/epochs/latest" | jq -r '.is_confirmation_poc_active') && \ [ "$CONFIRMATION_POC_ACTIVE" = "false" ] && \ echo "OK: No confirmation PoC active" && \ # Download Binary sudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.10-post7/ .dapi/data/upgrade-info.json && \ sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.10-post7/bin/ && \ wget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-post7/decentralized-api-amd64.zip' && \ echo "71481e6f2c5f9a355ed283a0896833bcc8397e8bcda134a796a46467bd2ff3b0 decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.10-post7/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.10-post7/bin/decentralized-api && \ echo "API Installed and Verified" && \ # Link Binary echo "--- Final Verification ---" && \ sudo rm -rf .dapi/cosmovisor/current && \ sudo ln -sf upgrades/v0.2.10-post7 .dapi/cosmovisor/current && \ echo "313df0747e090518ac052918ad23f9d6e70bb60dede2013375e322c23605f3e0 .dapi/cosmovisor/current/bin/decentralized-api" | sudo sha256sum --check && \ # Restart source config.env && docker compose up api --no-deps --force-recreate -d ``` ## March 11, 2026 **Tool calling** [Tool calling](https://gonka.ai/developer/quickstart/#4-tool-calling) is now available through the standard function-calling pattern (`type: “function”`). The integration flow is simple: - functions are defined by the developer - the model returns structured call arguments when a request matches - execution is handled on the application side. 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. ## March 6, 2026 **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: - Granter = account that owns voting power (cold key) - Grantee = account that will submit votes on the granter’s behalf (warm key) 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) === "Command" ``` ./inferenced tx authz grant generic \ --msg-type=/cosmos.gov.v1beta1.MsgVote \ --from= \ --chain-id=gonka-mainnet \ --expiration= \ --home .inference \ --keyring-backend file ``` === "Example response" ``` { "height": "0", "txhash": "8D96FB6FC06FFB928FBC89FE950689CD040C7F338C197BA856175EC7462A3FFA", "codespace": "", "code": 0, "data": "", "raw_log": "", "logs": [], "info": "", "gas_wanted": "0", "gas_used": "0", "tx": null, "timestamp": "", "events": [] } ``` 2) Verify the grant exists (run from any node) === "Command" ``` ./inferenced query authz grants \ --node="http://:26657" \ --output=json | jq . ``` === "Example response" ``` { "grants": [ { "authorization": { "type": "cosmos-sdk/GenericAuthorization", "value": { "msg": "/cosmos.gov.v1beta1.MsgVote" } }, "expiration": "2026-12-03T18:38:18Z" } ], "pagination": { "total": "1" } } ``` 3) Vote using the grantee === "Command" ``` # Find the proposal ID which you are voting for - use it as in the voting body ./inferenced query gov proposals --output json # Prepare the file with the voting body cat > /tmp/authz-vote.json ", "msgs": [ { "@type": "/cosmos.gov.v1beta1.MsgVote", "proposal_id": "", "voter": "", "option": "VOTE_OPTION_YES" } ] } ] } } EOF # Vote using the file ./inferenced tx authz exec /tmp/authz-vote.json \ --from= \ --chain-id=gonka-mainnet \ --home .inference \ --keyring-backend file \ --node="http://:26657" -y ``` === "Example response" ``` { "pagination": { "total": "1" }, "proposals": [ { "deposit_end_time": "2026-03-06T10:40:07.016920026Z", "final_tally_result": { "abstain_count": "0", "no_count": "0", "no_with_veto_count": "0", "yes_count": "0" }, "id": "1", "messages": [ { "type": "cosmos-sdk/MsgSoftwareUpgrade", "value": { "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "height": "406062", "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 }", "name": "v0.2.10", "time": "0001-01-01T00:00:00Z" } } } ], "proposer": "gonka1xfvr8mywcrxrcrryvj8c5d2grvyjdj5c90fd88", "status": 2, "submit_time": "2026-03-04T10:40:07.016920026Z", "summary": "Upgrade Proposal v0.2.10", "title": "Upgrade Proposal v0.2.10", "total_deposit": [ { "amount": "50000000", "denom": "ngonka" } ], "voting_end_time": "2026-03-04T10:50:07.016920026Z", "voting_start_time": "2026-03-04T10:40:07.016920026Z" } ] } ``` Voting options: - `VOTE_OPTION_YES` - `VOTE_OPTION_ABSTAIN` - `VOTE_OPTION_NO` - `VOTE_OPTION_NO_WITH_VETO` 4) Revoke delegation (run from the granter key) === "Command" ``` ./inferenced tx authz revoke /cosmos.gov.v1beta1.MsgVote \ --from= \ --chain-id=gonka-mainnet \ --home .inference \ --keyring-backend file ``` === "Example response" ``` { code: 0 codespace: "" data: "" events: [] gas_used: "0" gas_wanted: "0" height: "0" info: "" logs: [] raw_log: "" timestamp: "" tx: null txhash: A2C3CDA9E95DCF143C0D8981A4F573F1E68879ECF4903B25BA97383C3F2FDFBA } ``` ## February 21, 2026 **API 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. 1. Upgrade v0.2.10 introduced a strict 5-minute timeout for Executor → MLNode connections, while some requests may take considerably longer. The new API version returns this value back instead of enforcing the strict limit. 2. The request retry system previously retried inference even if it failed due to a processing timeout (not a TLS timeout). Server-side retry for long requests is typically ineffective, as it leads to the same timeout scenario. At the same time, the client may receive inconsistent output. The new API version does not retry inference in such cases. 3. MLNodes that are currently preserved and not participating in PoC generation were still used for PoC validation. This could lead to missed inferences. The new version excludes such nodes from PoC validation. 4. Extra safeguards have been added to the PoC validation pipeline. PR: [https://github.com/gonka-ai/gonka/pull/785](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](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) echo "--- Pre-flight Check: Confirmation PoC Status ---" && \ CONFIRMATION_POC_ACTIVE=$(curl -sf "https://node3.gonka.ai/v1/epochs/latest" | jq -r '.is_confirmation_poc_active') && \ [ "$CONFIRMATION_POC_ACTIVE" = "false" ] && \ echo "OK: No confirmation PoC active" && \ # Download Binary sudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.10-post3/ .dapi/data/upgrade-info.json && \ sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.10-post3/bin/ && \ wget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.10-post3/decentralized-api-amd64.zip' && \ echo "1b75f2785c7884dc24f3c1e39d5ed10f4afcbe5fc677f5569d90d75c752ec150 decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.10-post3/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.10-post3/bin/decentralized-api && \ echo "API Installed and Verified" && \ # Link Binary echo "--- Final Verification ---" && \ sudo rm -rf .dapi/cosmovisor/current && \ sudo ln -sf upgrades/v0.2.10-post3 .dapi/cosmovisor/current && \ echo "de72c665ff71de904210c5472cebb248d163c1398141868e1a1fe198055b5886 .dapi/cosmovisor/current/bin/decentralized-api" | sudo sha256sum --check && \ # Restart source config.env && docker compose up api --no-deps --force-recreate -d ``` ## February 20, 2026 **Recommendation (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](https://github.com/gonka-ai/vllm/tree/release/v0.9.1-pocv2-post5/vllm) **Recommended images to try:** - docker pull ghcr.io/gonka-ai/mlnode:3.0.12-post5 - docker pull ghcr.io/gonka-ai/mlnode:3.0.12-post5-blackwell - docker pull ghcr.io/gonka-ai/mlnode:3.0.12-post5-blackwell-sm120 **Notes:** - This build is intended to be backward compatible with the previous version. - It has already been switched on for a small number of nodes, but it’s still recommended to review the changes before deploying. ## February 19, 2026 **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: - Review the Genesis-defined collateral parameters. - Prepare and deposit the required GNK before Epoch 180. - Ensure [collateral](https://gonka.ai/host/collateral/) is properly set, otherwise PoC-derived rewards will be reduced 5× starting from Epoch 180. 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. ## February 19, 2026 **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: - Mean node weights decreased (normalization effect) - The displayed total H100-equivalent capacity appears proportionally lower - Relative GPU ratios remain unchanged **Why this happened** Previously, PoC weight calculations relied on a nominal epoch duration assumption. After introducing real-time normalization: - PoC duration is aligned with the actual block production time - Weight reflects real compute time more accurately 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. ## February 18, 2026 **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 ``` The transition to `mlnode: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** - Fix: PoC and CPoC intersection bug (PR #752). - IBC Upgrade: Upgrades IBC stack to v8.7.0. - Punishment: Thresholds are now derived from on-chain data (PR #688). - Vesting: Support for streamvesting transfers with active vesting (PR #641). - MLNode: More reliable version of MLNode containers ghcr.io/product-science/mlnode:3.0.12-post4 / ghcr.io/product-science/mlnode:3.0.12-post4-blackwell. **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](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/proposals/governance-artifacts/update-v0.2.10/README.md) ## February 18, 2026 **Collateral parameter update proposal is now open for voting** The proposal for updated collateral parameters has been published for community vote. Proposed parameters: - 0.032 GNK per 1 unit of power (~10 GNK per H100) - 0.01% slashing for miss rate or jail - 0.5% slashing for invalid inference 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](https://gonka.ai/host/collateral/#slashing) 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/ diff -u \ \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 28 -o json --node $NODE_URL/chain-rpc/ ``` **Deadline:** Voting ends on February 19th, 2026, at 07:27:06 UTC. ## February 17, 2026 **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** - Fix PoC and CPoC intersection bug (PR #752) - Upgrades IBC stack to v8.7.0. - Punishment thresholds are now derived from on-chain data (PR #688) - Support for streamvesting transfers with active vesting (PR #641) - More reliable version of MLNode containers `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 ](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 ``` The transition to `mlnode: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: - [http://node1.gonka.ai:8000](http://node1.gonka.ai:8000) - [http://node2.gonka.ai:8000](http://node2.gonka.ai:8000) - [https://node3.gonka.ai](https://node3.gonka.ai) Cast your vote (`yes`, `no` , `abstain` , `no_with_veto`): ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced tx gov vote 27 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node3.gonka.ai/ ./inferenced query gov votes 27 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** - Voting ends: February 18th, 2026, at 09:26:26 UTC - Upgrade height: 2712600 - Estimated upgrade time: February 18th, 2026, at 15:30:00 UTC **Attention** - Check any scripts parsing `inferenced` CLI output. Enums and int64/uint64 values are now encoded as strings due to the IBC stack to v8.7.0 upgrade. - Please plan to be online during the upgrade window so that any follow-up steps or mitigation instructions can be applied promptly. - During upgrades, Cosmovisor creates a full state backup in the `.inference/data` directory; ensure sufficient disk space is available. Guidance on safely removing old backups from the `.inference` directory is available in [the documentation](https://gonka.ai/FAQ/#how-much-free-disk-space-is-required-for-a-cosmovisor-update-and-how-can-i-safely-remove-old-backups-from-the-inference-directory). - If `application.db` occupies a significant amount of disk space, the cleanup techniques described [here](https://gonka.ai/FAQ/#why-is-my-applicationdb-growing-so-large-and-how-do-i-fix-it) may be applied. - After the upgrade, Postgres is available as an option for local payload storage. ## February 16, 2026 **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: - 0.032 GNK per 1 unit of power (~10 GNK per H100) - 0.01% slashing for miss rate or jail - 0.5% slashing for invalid inference 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. ## February 13, 2026 **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:** - Sunday evening (LA time) — Voting period begins - Monday (UTC morning) — Voting active - Tuesday — Upgrade execution (if approved) 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](https://github.com/gonka-ai/gonka/pull/695) ## February 13, 2026 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](https://gonka.ai/FAQ/#recovery-guide-consensus-failure-after-missing-patch) ## February 12, 2026 **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 sudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.9-post3/ .inference/data/upgrade-info.json sudo mkdir -p .inference/cosmovisor/upgrades/v0.2.9-post3/bin/ wget -q -O inferenced.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.9-post3/inferenced-amd64.zip' && \ echo "59896da31f4e42564fc0a2f63a9e0bf4f25f240428f21c0d5191b491847553df inferenced.zip" | sha256sum --check && \ sudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.9-post3/bin/ && \ sudo chmod +x .inference/cosmovisor/upgrades/v0.2.9-post3/bin/inferenced && \ echo "Inference Installed and Verified" # Link Binary echo "--- Final Verification ---" && \ sudo rm -rf .inference/cosmovisor/current sudo ln -sf upgrades/v0.2.9-post3 .inference/cosmovisor/current echo "aaffbbdc446fbe6832edee8cb7205097b2e5618a8322be4c6de85191c51aca1d .inference/cosmovisor/current/bin/inferenced" | sudo sha256sum --check && \ # Restart source config.env && docker compose up node --no-deps --force-recreate -d ``` [https://github.com/gonka-ai/gonka/pull/748](https://github.com/gonka-ai/gonka/pull/748) ## February 12, 2026 **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. ## February 12, 2026 **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' ``` Allowed Transfer Agents (current): ``` gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5 gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u ``` A new library version is available here: [https://gonka.ai/developer/quickstart/#3-inference-using-modified-openai-sdk](https://gonka.ai/developer/quickstart/#3-inference-using-modified-openai-sdk) **Note:** If an address is not included in the allowlist, inference requests routed through that address will not be accepted under the current configuration. ## February 10, 2026 **PR Review for Upgrade v0.2.10** [The Pull Request](https://github.com/gonka-ai/gonka/pull/695) 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](https://github.com/gonka-ai/gonka/pull/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](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/proposals/poc/optimize.md) **[PR #725](https://github.com/gonka-ai/gonka/pull/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:** - **[PR #708](https://github.com/gonka-ai/gonka/pull/708)** IBC Upgrade to v8.7.0 - **[PR #723](https://github.com/gonka-ai/gonka/pull/723)** Testnet bridge setup scripts - **[PR #666](https://github.com/gonka-ai/gonka/pull/666)** Artifact storage throughput optimization - **[PR #688](https://github.com/gonka-ai/gonka/pull/688)** Punishment statistics from on-chain data - **[PR #697](https://github.com/gonka-ai/gonka/pull/697)** Portable BLST build for macOS test builds - **[PR #712](https://github.com/gonka-ai/gonka/pull/712)** Require proto-go generation matches committed code - **[PR #711](https://github.com/gonka-ai/gonka/pull/711)** PoC test params from chain state - **[PR #641](https://github.com/gonka-ai/gonka/pull/641)** Streamvesting transfer with vesting - **[PR #659](https://github.com/gonka-ai/gonka/pull/659)** model assignment checks previous-epoch rewards. - **[PR #716](https://github.com/gonka-ai/gonka/pull/716)** rename PoC weight function for clarity and correctness. **API hardening and reliability fixes:** - **[PR #634](https://github.com/gonka-ai/gonka/pull/634)**: add request body size limits to reduce DoS risk. - **[PR #727](https://github.com/gonka-ai/gonka/pull/727)**: follow-up for #634, pass response writer to `http.MaxBytesReader` and align tests. - **[PR #638](https://github.com/gonka-ai/gonka/pull/638)**: fix unsafe type assertions in request processing. - **[PR #644](https://github.com/gonka-ai/gonka/pull/644)**: avoid rewriting static config on each startup. - **[PR #661](https://github.com/gonka-ai/gonka/pull/661)**: prevent API crash on short network drops. - **[PR #640](https://github.com/gonka-ai/gonka/pull/640)**: add unit tests for node version endpoint behavior. - **[PR #622](https://github.com/gonka-ai/gonka/pull/622)**: propagate refund errors in `InvalidateInference`. - **[PR #639](https://github.com/gonka-ai/gonka/pull/639)**: add missing return after error in task claiming path. - **[PR #643](https://github.com/gonka-ai/gonka/pull/643)**: sanitize nil participants in executor selection. - **[PR #545](https://github.com/gonka-ai/gonka/pull/545)**: minor bug fixes in API flow. **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.](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** 1. Active hosts review this proposal on GitHub and leave feedback. 2. After the PR is reviewed by community, a v0.2.10 release is expected to be created from this branch, and an on-chain upgrade proposal for this version can be submitted, starting the formal governance voting process. 3. If the on-chain proposal passes, this PR is expected to be merged after the upgrade is executed on-chain. Creating the release from [upgrade-v0.2.10](https://github.com/gonka-ai/gonka/tree/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](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.10/proposals/governance-artifacts/update-v0.2.10). 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. ## February 4, 2026 **CLI update reminder** For granting permissions to warm keys created after the v0.2.9 upgrade, the [CLI version v0.2.9](https://github.com/gonka-ai/gonka/releases/tag/release%2Fv0.2.9) should be used. ## February 3, 2026 **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** - Observed changes indicate that GPU weight differences now reflect model-specific inference throughput rather than nominal hardware specifications. For example, the H100 PCIe weight decreased more than the H100 HBM3 weight, consistent with observed inference behavior for `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8`. - Under the current model configuration, B200 GPUs do not demonstrate higher inference performance compared to H100-class GPUs, based on observed inference traces. - Different performance characteristics may be observed if and when larger or more demanding models are introduced through governance in future epochs (for example, DeepSeek V3.2). - Control inference benchmark measurements performed outside of PoC, using standard vLLM-based inference on the same model `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. ## February 2, 2026 **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 sudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.9-post2/ .inference/data/upgrade-info.json sudo mkdir -p .inference/cosmovisor/upgrades/v0.2.9-post2/bin/ wget -q -O inferenced.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.9-post2/inferenced-amd64.zip' && \ echo "8de51bdd1d2c0af5f1da242e10b39ae0ceefd215f94953b9d95e9276f7aa70c7 inferenced.zip" | sha256sum --check && \ sudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.9-post2/bin/ && \ sudo chmod +x .inference/cosmovisor/upgrades/v0.2.9-post2/bin/inferenced && \ echo "Inference Installed and Verified" # Link Binary echo "--- Final Verification ---" && \ sudo rm -rf .inference/cosmovisor/current sudo ln -sf upgrades/v0.2.9-post2 .inference/cosmovisor/current echo "75410178a4c3b867c0047d0425b48f590f39b9e9bc0f3cf371d08670d54e8afe .inference/cosmovisor/current/bin/inferenced" | sudo sha256sum --check && \ # Restart source config.env && docker compose up node --no-deps --force-recreate -d ``` Further instructions, including any required coordination steps for resuming block validation, will be shared separately. ## February 2, 2026 **Block 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: - Verifying that no validator set is able to reach the required validation thresholds - Confirming the network state prior to validator finalization - Preparing a patch to address the identified issue **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. ## February 1, 2026 **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** - The next PoC cycle (the transition from epoch 158 to 159) is critical. Please plan to be online so that any follow-up steps or mitigation instructions can be applied promptly, if needed. - Only ML Nodes serving `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: - are configured to serve the supported model `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` only - images are updated to a PoC v2–compatible version Guidance 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](https://gonka.ai/FAQ/#how-to-switch-to-qwenqwen3-235b-a22b-instruct-2507-fp8-upgrade-ml-nodes-and-remove-other-models). **Key changes now active** **PoC v2 activation** - PoC v2 is used as the active mechanism for weight assignment - Confirmation PoC (V2 tracking) is used as the canonical source of results - Legacy PoC logic is no longer used for weight calculation **Model configuration** - The network operates in a single-model configuration - The model used for PoC v2 and weight assignment is `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` - ML Nodes serving other models are not included in PoC v2 weight assignment. Where supported, an automatic model switch to `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: - The node serves `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` - The node runs a PoC v2–compatible image: - ghcr.io/product-science/mlnode:3.0.12-post1 - ghcr.io/product-science/mlnode:3.0.12-post1-blackwell **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. **Additional protocol updates** - Transfer Agent roles are restricted to a [defined](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.9/proposals/governance-artifacts/update-v0.2.9#transfer-agent-whitelist) `allowlist` for the initial phase - Nodes that participated in PoC generation while ignoring PoC validation have been removed from the [participant's](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.9/proposals/governance-artifacts/update-v0.2.9#suspicious-participant-removal) `allowlist` - [Guardian weights](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.9/proposals/governance-artifacts/update-v0.2.9#guardian-tiebreaker-for-poc-v2-voting) are applied as a deterministic fallback when PoC v2 validation vote thresholds are not reached 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 ](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.9/proposals/governance-artifacts/update-v0.2.9 ) ## February 1, 2026 The on-chain governance process for the v0.2.9 upgrade proposal is nearing its conclusion. - Voting ends: February 1st, 2026, at 22:02:58 UTC - Upgrade height: 2451000. - Estimated upgrade time: February 2nd, 2026, at 05:10:00 UTC Hosts are encouraged to review the proposal on [GitHub](https://github.com/gonka-ai/gonka/pull/668) and participate in the vote. Pre-downloading binaries in advance may help avoid relying on GitHub availability during the upgrade window. ``` # 1. Create Directories sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.9/bin \ .inference/cosmovisor/upgrades/v0.2.9/bin && \ # 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable wget -q -O decentralized-api.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.9/decentralized-api-amd64.zip" && \ echo "ac1ad369052a8c3d01af4d463c49cdd16fcbecc365d201232e7a2d08af8501c0 decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.9/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.9/bin/decentralized-api && \ echo "DAPI Installed and Verified" && \ # 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable sudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.9/bin/ && \ wget -q -O inferenced.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.9/inferenced-amd64.zip" && \ echo "fc628d77aa516896924fbd8f60b8aa6a14161de4582aaef634de62382ea482eb inferenced.zip" | sha256sum --check && \ sudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.9/bin/ && \ sudo chmod +x .inference/cosmovisor/upgrades/v0.2.9/bin/inferenced && \ echo "Inference Installed and Verified" && \ # 4. Cleanup and Final Check rm decentralized-api.zip inferenced.zip && \ echo "--- Final Verification ---" && \ sudo ls -l .dapi/cosmovisor/upgrades/v0.2.9/bin/decentralized-api && \ sudo ls -l .inference/cosmovisor/upgrades/v0.2.9/bin/inferenced && \ echo "52c79f06a8fc175ca6b3819523bb36afbf601d8a8320b1bb5a3cc089ceef62c4 .dapi/cosmovisor/upgrades/v0.2.9/bin/decentralized-api" | sudo sha256sum --check && \ echo "ae20517e4bb38293202f7f5d52439d5315cb32c8f3c34a02fa65feaefadd6193 .inference/cosmovisor/upgrades/v0.2.9/bin/inferenced" | sudo sha256sum --check ``` ## January 31, 2026 **v0.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** - PoC v2 is used as the active mechanism for weight assignment - Confirmation PoC (V2 tracking) is used as the canonical source of results - Legacy PoC logic is no longer used for weight calculation **Model configuration** - The network operates in a single-model configuration - The model used for PoC v2 and weight assignment is `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` - ML Nodes serving other models are not included in PoC v2 weight assignment. Where supported, an automatic model switch to `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: - The node serves `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` - The node runs a PoC v2–compatible image: - ghcr.io/product-science/mlnode:3.0.12-post1 - ghcr.io/product-science/mlnode:3.0.12-post1-blackwell **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. **Additional protocol updates** - Transfer Agent roles are restricted to a [defined](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.9/proposals/governance-artifacts/update-v0.2.9#transfer-agent-whitelist) `allowlist` for the initial phase - Nodes that participated in PoC generation while ignoring PoC validation have been removed from [the participant](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.9/proposals/governance-artifacts/update-v0.2.9#suspicious-participant-removal) `allowlist` - [Guardian weights](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.9/proposals/governance-artifacts/update-v0.2.9#guardian-tiebreaker-for-poc-v2-voting) are applied as a deterministic fallback when PoC v2 validation vote thresholds are not reached 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](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: - are configured to serve the supported model `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` only - images are updated to a PoC v2–compatible version Guidance 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](https://gonka.ai/FAQ/#how-to-switch-to-qwenqwen3-235b-a22b-instruct-2507-fp8-upgrade-ml-nodes-and-remove-other-models). **How to vote** Proposal details and voting are available via `inferenced`. Any active node can be used. Available nodes include: - [http://node1.gonka.ai:8000](http://node1.gonka.ai:8000) - [http://node2.gonka.ai:8000](http://node2.gonka.ai:8000) - [http://node3.gonka.ai:8000](http://node3.gonka.ai:8000) - [https://node4.gonka.ai](https://node4.gonka.ai) Cast your vote ( `yes` , `no` , `abstain` , `no_with_veto` ): ``` export NODE_URL=https://node4.gonka.ai/ ./inferenced tx gov vote 26 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` To check the voting status: ``` export NODE_URL=https://node4.gonka.ai/ ./inferenced query gov votes 26 -o json --node $NODE_URL/chain-rpc/ ``` **Deadlines** - Voting ends: February 1st, 2026, at 22:02:58 UTC - Upgrade height: 2451000. - Estimated upgrade time: February 2nd, 2026, at 05:10:00 UTC Hosts are encouraged to review the proposal on [GitHub](https://github.com/gonka-ai/gonka/pull/668) and participate in the vote. **Attention** - Please plan to be online during the upgrade window so that any follow-up steps or mitigation instructions can be applied promptly, if needed. - During upgrades, Cosmovisor creates a full state backup in the `.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](https://gonka.ai/FAQ/#how-much-free-disk-space-is-required-for-a-cosmovisor-update-and-how-can-i-safely-remove-old-backups-from-the-inference-directory). - If `application.db` occupies a significant amount of disk space, the cleanup techniques described [here](https://gonka.ai/FAQ/#why-is-my-applicationdb-growing-so-large-and-how-do-i-fix-it) may be applied. - After the upgrade, Postgres is available as an option for local payload storage. ## January 29, 2026 **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/](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](https://github.com/gonka-ai/gonka/blob/gm/debug-155-1/debug-validation.ipynb). ## January 29, 2026 **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** - vLLM Integration: PoC is integrated directly into vLLM, enabling an immediate switch from inference to PoC without offloading the model. - MMR Commitments: Artifact storage is migrated off-chain using Merkle Mountain Range commitments; only `root_hash` and `count` are recorded on-chain., - Dual-Mode Migration: Support for V1 (regular PoC) and V2 (Confirmation PoC) tracking is active. **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-FP8` - `Qwen/Qwen3-32B-FP8` **Security & Reliability Improvements** - SSRF & DoS: Validation of `InferenceUrl` to reject internal IPs and addition of timeouts to prevent request hangs. - Vote Flipping: Rejection of duplicate PoC validations to prevent overwriting. - Auth Bypass: Binding of `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: - Model Configuration: Configure the ML node to serve `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` - ML Node Upgrade: Utilize a version supporting PoC v2: - ghcr.io/product-science/mlnode:3.0.12 - ghcr.io/product-science/mlnode:3.0.12-blackwell 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** - Cosmovisor: Node and API binary updates are handled automatically. Existing Hosts do not need to perform manual updates on running containers. - Disk Space: Cosmovisor creates a full state backup in the `.inference/data` directory. Ensure 250+ GB of free space is available. - Postgres: Local payload storage via Postgres is now available for configuration post-upgrade. Monitoring node status and Discord communication is advised during the post-upgrade window to ensure stability. ## January 28, 2026 **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-FP8` - `Qwen/Qwen3-32B-FP8` `Qwen/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: - All your ML Nodes serve Qwen/Qwen3-235B-A22B-Instruct-2507-FP8. This is the only model that contributes to PoC v2 weight. - All your ML Nodes are upgraded to a PoC v2–compatible image: - ghcr.io/product-science/mlnode:3.0.12 - ghcr.io/product-science/mlnode:3.0.12-blackwell > **Important** - Serving the correct model without upgrading the ML Node is not sufficient. - Nodes that do not meet both conditions will not be eligible once the network switches to a single-model configuration. - The ML Node upgrade must be completed before the migration is finished and PoC v2 is activated through a separate governance proposal following the v0.2.8 upgrade. - The v0.2.8 upgrade itself does not enable PoC v2. **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 ``` Look for the field: ``` "timeslot_allocation": [ true, false ] ``` Interpretation: - First boolean: Whether the node is serving inference in the current epoch - Second boolean: Whether the node is scheduled to serve inference in the next PoC **Recommended behavior** - Prefer changing the model only on nodes where the second value is `false` - This reduces risk while PoC v2 behavior is still being observed - Gradual rollout across epochs is encouraged **4. 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 huggingface-cli download Qwen/Qwen3-235B-A22B-Instruct-2507-FP8 ``` Use ML Node Management API to switch ML Node to a supported model (`Qwen/Qwen3-235B-A22B-Instruct-2507-FP8`). For example: ``` curl -X PUT "http://localhost:9200/admin/v1/nodes/node1" \ -H "Content-Type: application/json" \ -d '{ "id": "node1", "host": "inference", "inference_port": 5000, "poc_port": 8080, "max_concurrent": 800, "models": { "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8": { "args": [ "--tensor-parallel-size", "4", "--max-model-len", "240000" ] } } }' ``` Changes applied via the Admin API will replace model for the next epoch [https://gonka.ai/host/mlnode-management/#updating-an-existing-mlnode](https://gonka.ai/host/mlnode-management/#updating-an-existing-mlnode) `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 ``` NVIDIA Blackwell GPUs ``` image: ghcr.io/product-science/mlnode:3.0.12-blackwell ``` Apply changes and restart services. From `gonka/deploy/join`: ``` source config.env docker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull docker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d ``` **6. 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 ``` Optionally re-check node allocation: ``` curl http://127.0.0.1:9200/admin/v1/nodes ``` > **Governance 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: - Hosts are able to serve `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` or `Qwen/Qwen3-32B-FP8` - Hosts must switch their ML Nodes to serve `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` and upgrade them to PoC v2-compatible versions in order to contribute to PoC v2 weight. - The network observes adoption to assess Host readiness for moving to PoC v2 weights. **Stage 2. Governance proposal (optional, future)** Once a sufficient level of adoption among active Hosts is observed (approximately 50%): - A separate governance proposal may be submitted - This proposal may request approval to activate PoC v2 and use PoC v2 for weight assignment 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: - PoC v2 remains inactive for weight assignment - The existing PoC mechanism continues to be used to determine weight **Summary checklist** Before PoC v2 activation, ensure that: - ML Node serves `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` - All other models are removed from the configuration - ML Node image is 3.0.12 (or 3.0.12-blackwell) ## January 28, 2026 The on-chain governance process for the v0.2.8 upgrade proposal is nearing its conclusion. **Upgrade details** - Upgrade height: block 2387000 - Estimated time: January 29th, 2026, at 06:30:00 UTC Pre-downloading binaries in advance may help avoid relying on GitHub availability during the upgrade window. ``` # 1. Create Directories sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.8/bin \ .inference/cosmovisor/upgrades/v0.2.8/bin && \ # 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable wget -q -O decentralized-api.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.8-post1/decentralized-api-amd64.zip" && \ echo "45f28afba4758e54988f61cc358f0ad683e7832ab121ccd54b684fe4c9381a75 decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.8/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.8/bin/decentralized-api && \ echo "DAPI Installed and Verified" && \ # 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable sudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.8/bin/ && \ wget -q -O inferenced.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.8-post1/inferenced-amd64.zip" && \ echo "f0f2e3ee8760e40a78087c98c639a7518bf062138141ed4aec2120f5bc622a67 inferenced.zip" | sha256sum --check && \ sudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.8/bin/ && \ sudo chmod +x .inference/cosmovisor/upgrades/v0.2.8/bin/inferenced && \ echo "Inference Installed and Verified" && \ # 4. Cleanup and Final Check rm decentralized-api.zip inferenced.zip && \ echo "--- Final Verification ---" && \ sudo ls -l .dapi/cosmovisor/upgrades/v0.2.8/bin/decentralized-api && \ sudo ls -l .inference/cosmovisor/upgrades/v0.2.8/bin/inferenced && \ echo "421a761f3a7037d72ee0bd8b3f50a744349f717439c7e0fee28c55948dae9a7c .dapi/cosmovisor/upgrades/v0.2.8/bin/decentralized-api" | sudo sha256sum --check && \ echo "308c63c7bda4fb668632ac3e13f3f6cccacf54c563c8e9fd473bcb48c7389fe0 .inference/cosmovisor/upgrades/v0.2.8/bin/inferenced" | sudo sha256sum --check ``` ## January 27, 2026 **v0.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)** - Integrates PoC directly into vLLM, enabling an immediate switch from inference to PoC without offloading the model or loading a separate PoC model. - Migrates artifact storage off-chain using MMR (Merkle Mountain Range) commitments - only root_hash and count are recorded on-chain. - Includes dual-mode migration strategy: V1 for regular PoC, V2 tracking for Confirmation PoC during rollout. **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-FP8` - `Qwen/Qwen3-32B-FP8` Successful 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** - 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. - PoC Exclusion: Fixes getInferenceServingNodeIds to correctly exclude inference-serving nodes. - Auth Bypass & Replay: Binds epochId to signatures and validates authorization against the correct epoch. 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.](https://github.com/gonka-ai/gonka/pull/539) **Host action required** To participate in the PoC v2 transition, Hosts must complete both of the following steps: - Verify that your ML node is configured to serve `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` - Upgrade the ML Node to a version that supports PoC v2: - ghcr.io/product-science/mlnode:3.0.12 - ghcr.io/product-science/mlnode:3.0.12-blackwell Serving `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: - [http://node1.gonka.ai:8000/](http://node1.gonka.ai:8000/) - [http://node2.gonka.ai:8000/](http://node2.gonka.ai:8000/) - [http://node3.gonka.ai:8000/](http://node3.gonka.ai:8000/) - [https://node4.gonka.ai/](https://node4.gonka.ai/) To check the voting status: ``` export NODE_URL=https://node4.gonka.ai/ ./inferenced query gov votes 25 -o json --node $NODE_URL/chain-rpc/ ``` To vote ( `yes` , `no` , `abstain` , `no_with_veto` ): ``` export NODE_URL=https://node4.gonka.ai/ ./inferenced tx gov vote 25 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` **Deadlines** - Voting ends at January 29th, 2026, at 03:02:20 UTC. - Upgrade is proposed on block 2387000. The estimated time of this block is January 29th, 2026, at 06:30:00 UTC. 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](https://gonka.ai/FAQ/#how-much-free-disk-space-is-required-for-a-cosmovisor-update-and-how-can-i-safely-remove-old-backups-from-the-inference-directory). If `application.db` occupies a significant amount of disk space, the cleanup techniques described [here](https://gonka.ai/FAQ/#why-is-my-applicationdb-growing-so-large-and-how-do-i-fix-it) can be used. **Note:** After the upgrade, Postgres can be configured as storage for local payloads. ## January 19, 2026 **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. - Model Update: Please switch your ML Nodes to the `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` model. - Gradual Rollout: If you operate multiple ML Nodes, you are encouraged to perform these updates gradually across multiple epochs. **How to update** Instructions for updating an existing ML Node can be found here: [https://gonka.ai/host/mlnode-management/#updating-an-existing-mlnode](https://gonka.ai/host/mlnode-management/#updating-an-existing-mlnode) ## January 16, 2026 **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](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](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: - available here: [https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv](https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv) - 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](https://github.com/product-science/filter) **Execution characteristics** - The `allowlist` extends automatically if the proposal is approved. - No software upgrade is needed. - Further adjustments, if needed, remain subject to governance. **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: - The network reverts to the standard participation rules in effect prior to the stabilization period, or - Any alternative configuration must be defined through a separate governance decision. **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: - http://node1.gonka.ai:8000/ - http://node2.gonka.ai:8000/ - http://node3.gonka.ai:8000/ - https://node4.gonka.ai/ To check the voting status: ``` export NODE_URL=http://node1.gonka.ai:8000 ./inferenced query gov votes 22 -o json --node $NODE_URL/chain-rpc/ ``` To vote ( `yes` , `no` , `abstain` , `no_with_veto` ): ``` export NODE_URL=http://node1.gonka.ai:8000 ./inferenced tx gov vote 22 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` **Next 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. ## January 10, 2026 **Temporary participant `allowlist` correction** A new governance vote is currently active. It corrects a filtration edge case by adding several addresses to the [allowlist](https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv) 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](https://github.com/product-science/filter) The `allowlist` is available here: [https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv](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: - http://node1.gonka.ai:8000/ - http://node3.gonka.ai:8000/ - https://node4.gonka.ai/ To check the voting status: ``` export NODE_URL=http://node1.gonka.ai:8000 ./inferenced query gov votes 21 -o json --node $NODE_URL/chain-rpc/ ``` To vote ( `yes` , `no` , `abstain` , `no_with_veto` ): ``` export NODE_URL=http://node1.gonka.ai:8000 ./inferenced tx gov vote 21 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` **Next 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. ## January 10, 2026 **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: - Reported hardware characteristics matching commonly observed configuration patterns (the list of filtered non-standard configuration strings is available here: [https://github.com/product-science/filter/blob/main/filter_strings.txt](https://github.com/product-science/filter/blob/main/filter_strings.txt)) - Demonstrated PoC weight not exceeding 150% of the weight observed for comparable hardware 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** - The `allowlist` becomes active starting from the next epoch (Epoch 135) - The activation occurs during the first PoC of Epoch 135 - No software upgrade is required - From that point, the `allowlist` remains in effect up to and including block 2,222,222 **Reproducibility and methodology** - The `allowlist` is derived exclusively from publicly observable on-chain data - Hardware descriptors are evaluated against a predefined set of configuration patterns using open-source scripts: [https://github.com/product-science/filter](https://github.com/product-science/filter) - The resulting `allowlist` is published here: [https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv](https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv) **Next Steps** No action is required from hosts. ## January 8, 2026 **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](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: - Reported hardware characteristics were evaluated against a predefined set of commonly observed hardware configuration patterns, used to identify deviations and inconsistencies (the exact list of non-standard configuration strings is available here: [https://github.com/product-science/filter/blob/main/filter_strings.txt](https://github.com/product-science/filter/blob/main/filter_strings.txt)), and - Observed PoC weight stayed below 150% of the weight demonstrated by other participants using comparable hardware. Participants that previously exhibited persistent deviations from these patterns are not part of the `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](https://github.com/product-science/filter) The `allowlist` is available here: [https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv](https://github.com/product-science/filter/blob/main/artifacts_end2end/allowlist.csv) **Execution characteristics** - The `allowlist` takes effect automatically if the proposal is approved. - No software upgrade is needed. - The `allowlist` becomes active during the next PoC following a successful vote, expected at block: 2089140. - From that point, the `allowlist` remains in effect up to and including block ​​2222222. - Further adjustments, if needed, remain subject to governance. **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: - The network reverts to the standard participation rules in effect prior to the stabilization period, or - Any alternative configuration must be defined through a separate governance decision. **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: - http://node1.gonka.ai:8000/ - http://node2.gonka.ai:8000/ - https://node4.gonka.ai/ To check the voting status: ``` export NODE_URL=http://node1.gonka.ai:8000 ./inferenced query gov votes 20 -o json --node $NODE_URL/chain-rpc/ ``` To vote ( `yes` , `no` , `abstain` , `no_with_veto` ): ``` export NODE_URL=http://node1.gonka.ai:8000 ./inferenced tx gov vote 20 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` **Next steps after the vote** This process is handled entirely through governance and does not require a software upgrade. **Timelines and Deadlines** - Voting ends: January 10th, 2026, at 06:46:52 UTC. - `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. ## January 8, 2026 **Network Update — Consensus Restored** Following the deployment of the patch, network consensus has stabilized and is now operating within normal parameters. ## January 8, 2026 **Network Update — Patch Ready for Deployment** The patch addressing the recent consensus failure observed during PoC is now available. [GUIDE](https://gonka.ai/FAQ/#upgrade-v027) 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.** ## January 8, 2026 **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. ## January 8, 2026 **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. ## January 8, 2026 **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)** - Temporary reactivation of the Genesis Validator Enhancement — a previously used limited in duration defensive mechanism proposed to be reactivated. - Consensus protection during network growth. During its prior operation: - Three Guardian validators collectively held approximately 34% of consensus voting power - No additional rewards were granted to Guardian validators - This configuration helped prevent consensus stalls in edge cases - The Genesis Validator Enhancement will be deactivated automatically when both of the following conditions are satisfied: - total network power reaches 15.000.000. - block 3.000.000 is reached **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: - address incorrect accounting of failed inference requests (including cases where requests in unsupported formats were processed but not marked as completed) - improve resilience around failed inference handling - introduce batching for `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** - Host-level registration: Registration of new Hosts will be halted until block 2.222.222 (approximately two weeks from now). This measure is intended to stabilize the network and prepare it for further growth. - Developer-lever registration. Registration of new developer addresses will be paused during the stabilization period. A predefined `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): - Nodes that were active during Epoch 117 but did not receive their epoch reward will receive the missed reward for that epoch. - All nodes that were active during Epoch 117 will receive an additional payout equal to 1.083× the Epoch 117 reward, applied uniformly across all eligible nodes, including those that received the original reward. **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:** - No further actions are required by hosts. - Cosmovisor creates a full backup in the `.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](https://gonka.ai/FAQ/#how-much-free-disk-space-is-required-for-a-cosmovisor-update-and-how-can-i-safely-remove-old-backups-from-the-inference-directory) how to safely remove old backups from the `.inference` directory. **Notes:** - Full technical details of the Genesis Validator Enhancement are available here: [https://github.com/gonka-ai/gonka/tree/main/proposals/early-network-protection](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](https://github.com/gonka-ai/gonka/pull/503) ## January 7, 2026 The upgrade proposal for version **v0.2.7** has been approved through on-chain governance. **Upgrade Details** - Upgrade height: block 2.054.000 - Estimated time: January 8, 2026, at 08:10:00 UTC. Pre-downloading binaries in advance may help avoid relying on GitHub availability during the upgrade window. ``` # 1. Create Directories sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.7/bin \ .inference/cosmovisor/upgrades/v0.2.7/bin && \ # 2. DAPI: Download -> Verify -> Unzip directly to bin -> Make Executable wget -q -O decentralized-api.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.7/decentralized-api-amd64.zip" && \ echo "03555ba60431e72bd01fe1fb1812a211828331f5767ad78316fdd1bcca0e2d52 decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.7/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api && \ echo "DAPI Installed and Verified" && \ # 3. Inference: Download -> Verify -> Unzip directly to bin -> Make Executable sudo rm -rf inferenced.zip .inference/cosmovisor/upgrades/v0.2.7/bin/ && \ wget -q -O inferenced.zip "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.7/inferenced-amd64.zip" && \ echo "b7c9034a2a4e1b2fdd525bd45aa32540129c55176fd7a223a1e13a7e177b3246 inferenced.zip" | sha256sum --check && \ sudo unzip -o -j inferenced.zip -d .inference/cosmovisor/upgrades/v0.2.7/bin/ && \ sudo chmod +x .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced && \ echo "Inference Installed and Verified" && \ # 4. Cleanup and Final Check rm decentralized-api.zip inferenced.zip && \ echo "--- Final Verification ---" && \ sudo ls -l .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api && \ sudo ls -l .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced && \ echo "d07e97c946ba00194dfabeaf0098219031664dace999416658c57b760b470a74 .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api" | sudo sha256sum --check && \ echo "09c0e06f7971be87ab00fb08fc10e21ff86f9dff6fc80d82529991aa631cd0a9 .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced" | sudo sha256sum --check ``` Binaries can be considered successfully installed once all commands complete without errors and the confirmation message is displayed. ``` Inference Installed and Verified --- Final Verification --- -rwxr-xr-x 1 root root 224376384 Jan 1 2000 .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api -rwxr-xr-x 1 root root 215172352 Jan 1 2000 .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced .dapi/cosmovisor/upgrades/v0.2.7/bin/decentralized-api: OK .inference/cosmovisor/upgrades/v0.2.7/bin/inferenced: OK ``` **ATTENTION** - Please be online around the upgrade window to follow instructions if issues arise. - 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. ](https://gonka.ai/FAQ/#how-much-free-disk-space-is-required-for-a-cosmovisor-update-and-how-can-i-safely-remove-old-backups-from-the-inference-directory) - Large `application.db` files can be reduced using [these techniques.](https://gonka.ai/FAQ/#why-is-my-applicationdb-growing-so-large-and-how-do-i-fix-it) **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. ## January 7, 2026 **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. ## January 6, 2026 **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)** - Temporary reactivation of the Genesis Validator Enhancement — a previously used limited in duration defensive mechanism proposed to be reactivated. - Consensus protection during network growth. During its prior operation: - Three Guardian validators collectively held approximately 34% of consensus voting power - No additional rewards were granted to Guardian validators - This configuration helped prevent consensus stalls in edge cases - The Genesis Validator Enhancement will be deactivated automatically when both of the following conditions are satisfied: - total network power reaches 15.000.000. - block 3.000.000 is reached **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: - address incorrect accounting of failed inference requests (including cases where requests in unsupported formats were processed but not marked as completed) - improve resilience around failed inference handling - introduce batching for `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** - Host-level registration: Registration of new Hosts will be halted until block 2.222.222 (approximately two weeks from now). This measure is intended to stabilize the network and prepare it for further growth. - Developer-lever registration. Registration of new developer addresses will be paused during the stabilization period. A predefined `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): - Nodes that were active during Epoch 117 but did not receive their epoch reward will receive the missed reward for that epoch. - All nodes that were active during Epoch 117 will receive an additional payout equal to 1.083× the Epoch 117 reward, applied uniformly across all eligible nodes, including those that received the original reward. **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 ./inferenced query gov votes 19 -o json --node $NODE_URL/chain-rpc/ ``` To vote ( `yes` , `no` , `abstain` , `no_with_veto` ): ``` export NODE_URL=http://node1.gonka.ai:8000 ./inferenced tx gov vote 19 yes \ --from \ --keyring-backend file \ --unordered \ --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet \ --yes ``` **Timelines and Deadlines** - Voting ends: January 8th, 2026, at 04:23:14 UTC. - Upgrade proposed at block: 2.054.000. - Estimated upgrade time: January 8, 2026, at 08:10:00 UTC. **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](https://gonka.ai/FAQ/#how-much-free-disk-space-is-required-for-a-cosmovisor-update-and-how-can-i-safely-remove-old-backups-from-the-inference-directory) 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](https://gonka.ai/FAQ/#why-is-my-applicationdb-growing-so-large-and-how-do-i-fix-it) 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](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](https://github.com/gonka-ai/gonka/pull/503) ## January 5, 2026 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](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' ``` Outside of Confirmation PoC, this value should return `false` . **Installation** Download and install the new binary, then restart the `API` container: ``` # Download Binary sudo rm -rf decentralized-api.zip .dapi/cosmovisor/upgrades/v0.2.6-post12/ .dapi/data/upgrade-info.json sudo mkdir -p .dapi/cosmovisor/upgrades/v0.2.6-post12/bin/ wget -q -O decentralized-api.zip 'https://github.com/product-science/race-releases/releases/download/release%2Fv0.2.6-post12/decentralized-api-amd64.zip' && \ echo "f0d1172a90ca4653035e964abe4045f049d03d6060d6519742110e181b1b2257 decentralized-api.zip" | sha256sum --check && \ sudo unzip -o -j decentralized-api.zip -d .dapi/cosmovisor/upgrades/v0.2.6-post12/bin/ && \ sudo chmod +x .dapi/cosmovisor/upgrades/v0.2.6-post12/bin/decentralized-api && \ echo "API Installed and Verified" # Link Binary echo "--- Final Verification ---" && \ sudo rm -rf .dapi/cosmovisor/current sudo ln -sf upgrades/v0.2.6-post12 .dapi/cosmovisor/current echo "4672a39c3a3a0a2c21464c227a3f36e9ebf096ecc872bf9584ad3ea632752a3e .dapi/cosmovisor/current/bin/decentralized-api" | sudo sha256sum --check && \ # Restart source config.env && docker compose up api --no-deps --force-recreate -d ``` --- ## Report a Vulnerability # Report a Vulnerability Found 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. --- ## Technical Integration Guide: Exchange & Bridge Widget # Technical Integration Guide: Exchange & Bridge Widget 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. --- ## 1. Architectural Overview To prevent structural confusion, the asset flows for deposits and withdrawals are split into two separate, independent processes. ### A. Deposit Flow (EVM to Gonka) & Address Derivation 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: [diagram] ### B. Withdraw / Unwrap Flow (Gonka to EVM) During a withdrawal, tokens are burned on the Cosmos side, validator BLS signatures are polled, and then claimed (minted) on the Ethereum side: [diagram] --- ## 2. Deposit Functionality ### A. IBC Deposits (Cosmos to Gonka) IBC deposits transfer assets directly from Cosmos source chains (e.g. Osmosis, Cosmos Hub, Injective) to Gonka. 1. **Enable & Connect Source Chain**: Query Keplr for the source chain credentials. ```typescript async function connectSourceChain(chainId: string) { const walletProvider = (window as any).keplr; if (!walletProvider) throw new Error("Cosmos wallet extension not found."); await walletProvider.enable(chainId); const offlineSigner = walletProvider.getOfflineSigner(chainId); const accounts = await offlineSigner.getAccounts(); return { address: accounts[0].address, offlineSigner }; } ``` 2. **Resolve Channel Routing**: Query the Gonka RPC channel metadata (`/ibc/core/channel/v1/channels`) to resolve counterparty paths. ```typescript async function resolveIbcChannel(nodeUrl: string, targetChainId: string): Promise { const response = await fetch(`${nodeUrl}/ibc/core/channel/v1/channels`).then(r => r.json()); const channels = response?.channels || []; for (const channel of channels) { if (channel.state !== 'STATE_OPEN' || channel.port_id !== 'transfer') continue; const clientData = await fetch( `${nodeUrl}/ibc/core/channel/v1/channels/${channel.channel_id}/ports/transfer/client_state` ).then(r => r.json()); const clientChainId = clientData?.identified_client_state?.client_state?.chain_id || clientData?.client_state?.chain_id; if (clientChainId === targetChainId) { return channel.counterparty?.channel_id || null; } } return null; } ``` 3. **Execute IBC Transfer**: Dispatch a standard CosmJS `MsgTransfer` from the source chain. ```typescript import { SigningStargateClient } from '@cosmjs/stargate'; async function initiateIbcDeposit( sourceChainId: string, sourcePort: string, // e.g., 'transfer' sourceChannel: string, // e.g., 'channel-0' denom: string, // e.g., 'uusdt' amount: string, // In base units senderSourceAddress: string, receiverGonkaAddress: string, offlineSigner: any, rpcUrl: string ) { const client = await SigningStargateClient.connectWithSigner(rpcUrl, offlineSigner); const timeoutTimestamp = (BigInt(Date.now()) + 600_000n) * 1_000_000n; // 10 minutes timeout in nanoseconds const response = await client.sendIbcTokens( senderSourceAddress, // Sender on source chain (e.g. Osmosis address) receiverGonkaAddress, // Receiver on Gonka chain { denom, amount }, sourcePort, sourceChannel, undefined, // timeoutHeight Number(timeoutTimestamp) / 1_000_000_000, // timeoutTimestamp in seconds { amount: [], gas: '200000' } // Fee ); return response.transactionHash; } ``` ### B. EVM Bridge Deposits (EVM to Gonka) EVM deposits involve locking ERC-20 assets on an EVM source chain to mint corresponding tokens on Gonka. The transaction flow requires the following steps: 1. **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: ```typescript import { toBech32 } from '@cosmjs/encoding'; import { ethers } from 'ethers'; async function verifyAddressMismatch( activeEvmAddress: string, cosmosChainId: string, currentCosmosAddress: string, bech32Prefix: string = 'gonka' ) { // 1. Resolve active wallet provider (Keplr) const walletProvider = (window as any).keplr; if (!walletProvider) return { isMismatch: false }; // 2. Fetch key properties from Cosmos wallet const key = await walletProvider.getKey(cosmosChainId); const pubKeyBytes = key.pubKey; if (!pubKeyBytes || pubKeyBytes.length === 0) { console.warn("Public key not available from provider."); return { isMismatch: false }; } // 3. Derive the REAL Ethereum address from the Cosmos public key (keccak256-based) // NOTE: key.ethereumHexAddress is NOT the real EVM address — it is just the Cosmos // address bytes (sha256+ripemd160) represented as hex, which will mismatch. const pubKeyHex = '0x' + Array.from(pubKeyBytes, (b) => b.toString(16).padStart(2, '0')).join(''); const derivedEvmAddress = ethers.computeAddress(pubKeyHex); // 4. Compare active EVM address with derived EVM address const isMismatch = activeEvmAddress.toLowerCase() !== derivedEvmAddress.toLowerCase(); if (isMismatch) { // 5. Derive where the tokens will land by decoding EVM hex and encoding as Bech32 const rawHex = activeEvmAddress.startsWith('0x') ? activeEvmAddress.substring(2) : activeEvmAddress; const hexBytes = new Uint8Array( rawHex.match(/.{1,2}/g)?.map((byte: string) => parseInt(byte, 16)) || [] ); const targetCosmosAddress = toBech32(bech32Prefix, hexBytes); return { isMismatch: true, targetCosmosAddress, // Tokens will mint here expectedEvmAddress: derivedEvmAddress // User must switch EVM wallet to this address }; } return { isMismatch: false }; } ``` 2. **Resolve Bridge Contract Address**: Fetch the approved bridge contract address for the target token from the registry API. ```typescript async function resolveBridgeAddress(nodeUrl: string, chainId: string): Promise { const response = await fetch( `${nodeUrl}/productscience/inference/inference/bridge_addresses/${chainId}` ).then(r => r.json()); const address = response?.bridge_address || response?.address || response?.approved_bridge_address; if (!address) { throw new Error(`Failed to resolve bridge address for chain: ${chainId}`); } return address; } ``` 3. **Switch EVM Network**: Verify and request a switch (`wallet_switchEthereumChain`) to the correct Ethereum network (Mainnet or Sepolia Testnet). ```typescript async function switchEvmNetwork(ethProvider: any, isTestnet: boolean) { const targetChainIdHex = isTestnet ? '0xaa36a7' : '0x1'; // Sepolia or Mainnet try { await ethProvider.request({ method: 'wallet_switchEthereumChain', params: [{ chainId: targetChainIdHex }], }); } catch (switchError: any) { if (switchError.code === 4902) { throw new Error(`Please add the ${isTestnet ? 'Sepolia' : 'Ethereum'} network to your EVM wallet first.`); } throw switchError; } } ``` 4. **Execute 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. ```typescript // 1. Manually encode the ERC-20 transfer(address to, uint256 value) function call // Method selector for transfer(address,uint256) is 0xa9059cbb const methodId = '0xa9059cbb'; const toPadding = bridgeContractAddress.replace(/^0x/i, '').padStart(64, '0'); const amountHex = amountInBaseUnits.toString(16).padStart(64, '0'); const data = methodId + toPadding + amountHex; // 2. Dispatch transaction targeting the ERC-20 Token Contract address // (Resolves either Keplr's injected EVM provider or standard window.ethereum) const ethProvider = (window as any).keplr?.ethereum || (window as any).ethereum; if (!ethProvider) throw new Error("No EVM provider found."); await ethProvider.request({ method: 'eth_sendTransaction', params: [{ from: activeEvmAddress, to: erc20ContractAddress, // Target the ERC-20 contract data: data // Encoded call to transfer tokens to bridgeContractAddress }], }); ``` --- ## 3. Withdrawal Functionality ### A. IBC Withdrawals (Gonka to Cosmos) IBC withdrawals transfer assets directly from Gonka back to Cosmos destination chains (e.g. Osmosis, Cosmos Hub, Injective). 1. **Resolve Local Channel**: Query the Gonka RPC channel list metadata (`/ibc/core/channel/v1/channels`) to resolve the channel targeting the destination chain. 2. **Execute IBC Transfer**: Dispatch a standard CosmJS `MsgTransfer` on the Gonka chain. ```typescript import { SigningStargateClient } from '@cosmjs/stargate'; async function initiateIbcWithdraw( gonkaChainId: string, localChannel: string, // e.g., 'channel-0' denom: string, // e.g., 'ibc/...' or native denom amount: string, // In base units senderGonkaAddress: string, receiverCosmosAddress: string, offlineSigner: any, rpcUrl: string ) { const client = await SigningStargateClient.connectWithSigner(rpcUrl, offlineSigner); const timeoutTimestamp = (BigInt(Date.now()) + 600_000n) * 1_000_000n; // 10 minutes timeout in nanoseconds const response = await client.sendIbcTokens( senderGonkaAddress, // Sender on Gonka chain receiverCosmosAddress, // Receiver on destination chain { denom, amount }, 'transfer', localChannel, undefined, // timeoutHeight Number(timeoutTimestamp) / 1_000_000_000, // timeoutTimestamp in seconds { amount: [], gas: '200000' } // Fee ); return response.transactionHash; } ``` --- ### B. EVM Bridge Withdrawals (Multi-Stage Unwrap) Unwrapping 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: #### Prerequisite: Bridge Epoch Synced Validation 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. ```typescript import { ethers } from 'ethers'; const BRIDGE_ABI = [ 'function getLatestEpochInfo() view returns (uint64 epochId, uint64 timestamp, bytes groupKey)', 'function getCurrentState() view returns (uint8)', 'function isValidEpoch(uint64 epochId) view returns (bool)', 'function submitGroupKey(uint64 epochId, bytes groupPublicKey, bytes validationSig) external', ]; // 1. Fetch current bridge epoch status async function checkBridgeEpochStatus( bridgeAddress: string, chainEpoch: number, ethProvider: any ): Promise { const provider = new ethers.BrowserProvider(ethProvider); const contract = new ethers.Contract(bridgeAddress, BRIDGE_ABI, provider); const latestInfo = await contract.getLatestEpochInfo(); const bridgeEpoch = Number(latestInfo.epochId); return { bridgeEpoch, isSynced: bridgeEpoch >= chainEpoch, }; } // 2. Fetch missing BLS epoch registration data from Orchestrator API async function fetchEpochBLSData(orchestratorUrl: string, epochId: number) { const data = await fetch(`${orchestratorUrl}/bls/epochs/${epochId}`).then(r => r.json()); // Helper to convert base64 to hex const base64ToHex = (b64: string) => { const bytes = Uint8Array.from(atob(b64), c => c.charCodeAt(0)); return '0x' + Array.from(bytes).map(b => b.toString(16).padStart(2, '0')).join(''); }; return { groupPublicKeyHex: base64ToHex(data.group_public_key_uncompressed_256), validationSignatureHex: base64ToHex(data.validation_signature_uncompressed_128), }; } // 3. Sequentially register missing epochs on the Ethereum Bridge async function syncMissingEpochs( bridgeAddress: string, targetEpochId: number, orchestratorUrl: string, ethProvider: any ) { const provider = new ethers.BrowserProvider(ethProvider); const signer = await provider.getSigner(); const contract = new ethers.Contract(bridgeAddress, BRIDGE_ABI, signer); // Check if target epoch is already valid const isValid = await contract.isValidEpoch(targetEpochId); if (isValid) return; const latestInfo = await contract.getLatestEpochInfo(); const latestContractEpoch = Number(latestInfo.epochId); // Sequentially submit group keys for each missing epoch for (let epoch = latestContractEpoch + 1; epoch bridgeEpoch`), the user should be prompted to trigger the sequential epoch sync (`syncMissingEpochs`) before they are allowed to proceed with Stage 1 (burning assets). --- #### Stage 1: Burn/Wrap Tokens on Gonka 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). ##### **A. Custom Registry Setup** 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. ```typescript import { Registry } from '@cosmjs/proto-signing'; import { defaultRegistryTypes } from '@cosmjs/stargate'; import { wasmTypes } from '@cosmjs/cosmwasm-stargate'; // Custom bridge burn / unwrap Msg type registration (for native GNK -> WGNK unwrap) export const MsgRequestBridgeMintType = { typeUrl: '/inference.inference.MsgRequestBridgeMint', create(message: any) { return message; }, fromPartial(message: any) { return message; }, encode(message: any, writer: any) { // Requires standard fields: creator, amount, destinationAddress, chainId, destinationBridgeAddress return writer; }, decode() { return {}; } }; const customRegistry = new Registry([ ...defaultRegistryTypes, ...wasmTypes, // Crucial for /cosmwasm.wasm.v1.MsgExecuteContract ['/inference.inference.MsgRequestBridgeMint', MsgRequestBridgeMintType as any] ]); ``` ##### **B. Message Construction** Depending on the asset being unwrapped, construct either a native unwrap message or a CW-20 execute message: ```typescript // 1. For Native GNK -> WGNK: const msg = { typeUrl: '/inference.inference.MsgRequestBridgeMint', value: { creator: senderAddress, amount: amountInBaseUnits, destinationAddress: recipientEthAddress, chainId: 'ethereum', destinationBridgeAddress: bridgeContractAddress, }, }; // 2. For CW-20 Wrapped Tokens (e.g. USDT, USDC): const withdrawMsg = { withdraw: { amount: amountInBaseUnits, destination_bridge_address: bridgeContractAddress, destination_address: recipientEthAddress, }, }; const msg = { typeUrl: '/cosmwasm.wasm.v1.MsgExecuteContract', value: { sender: senderAddress, contract: cw20ContractAddress, msg: new TextEncoder().encode(JSON.stringify(withdrawMsg)), funds: [], }, }; ``` ##### **C. Local Tx Hash Calculation & Indexer Fallback** On 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: ```typescript import { toHex } from '@cosmjs/encoding'; import { sha256 } from '@cosmjs/crypto'; import { TxRaw } from 'cosmjs-types/cosmos/tx/v1beta1/tx'; async function signAndBroadcastWithIndexerFallback( client: SigningCosmWasmClient, senderAddress: string, messages: any[] ): Promise { // Sign manually using customRegistry const txRaw = await client.sign(senderAddress, messages, 'auto', ''); const txBytes = TxRaw.encode(txRaw).finish(); // Pre-calculate Tx Hash (SHA-256) const txHash = toHex(sha256(txBytes)).toUpperCase(); try { const result = await client.broadcastTx(txBytes); return { transactionHash: result.transactionHash, hasEvents: true }; } catch (error: any) { if (error.message.includes('transaction indexing is disabled')) { // The transaction was broadcast successfully, but the node will not return events return { transactionHash: txHash, hasEvents: false }; } throw error; } } ``` --- #### Stage 2: Resolution of Request IDs & BLS Signature Polling When the burn transaction completes on Gonka, you need to extract the `request_id` and `epoch_id` to poll the validators' signatures. ##### **A. Fetching Request Details (Event-based vs. History Fallback)** 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. ```typescript // 1. Event-based Resolution (Indexing Enabled) function parseUnwrapEvents(txResult: any): { requestId: string; epochId: number } { const blsEvent = txResult.events?.find((e: any) => e.type.includes('EventThresholdSigningRequested')); if (!blsEvent) throw new Error('BLS signing request event not found.'); const getAttr = (key: string) => blsEvent.attributes.find((a: any) => a.key === key).value.replace(/^"|"$/g, ''); return { requestId: getAttr('request_id'), epochId: parseInt(getAttr('current_epoch_id'), 10), }; } // 2. State History Fallback (Indexing Disabled / tx_index = "off") // Query the Cosmos node's state history registry: `GET {nodeUrl}/productscience/inference/bls/signing_history?pagination.limit=100&pagination.reverse=true` // // Example Response: // { // "signing_requests": [ // { // "request_id": "9/Pl3Hztt0KrZTMOQvXv87lNSM+SC4wjuUbJbZU3z8Y=", // "current_epoch_id": "287", // "status": "THRESHOLD_SIGNING_STATUS_COMPLETED", // "created_block_height": "4438273", // "data": [ // "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE=", // "CsXlVAEeF4b1Bz8kMHvW1ii+NAmDSyqIoH38Wvmzcu4=" // ] // } // ] // } async function resolveRequestFromHistory( nodeUrl: string, recipientEthAddress: string, amount: string ): Promise { // Convert EVM hex address to Base64 (orchestrator storage format) const recipientHex = recipientEthAddress.toLowerCase().replace(/^0x/, ''); const bytes = new Uint8Array(recipientHex.length / 2); for (let i = 0; i r.json()); const requests = res.signing_requests || []; // Match recipient and amount const matches = requests.filter((r: any) => r.data && r.data.some((d: string) => d === recipientB64)); if (matches.length === 0) throw new Error('Transaction not found in signing history'); // Sort descending by block height to get the latest matches.sort((a: any, b: any) => parseInt(b.created_block_height) - parseInt(a.created_block_height)); const matched = matches[0]; // Convert Base64 request_id to hex const reqIdBytes = Uint8Array.from(atob(matched.request_id), c => c.charCodeAt(0)); const reqIdHex = '0x' + Array.from(reqIdBytes).map(b => b.toString(16).padStart(2, '0')).join(''); return { requestId: reqIdHex, epochId: parseInt(matched.current_epoch_id, 10), }; } ``` ##### **B. BLS Signature Polling** > **IMPORTANT:** > **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. ```typescript function base64ToHex(base64Str: string): string { const binary = atob(base64Str); const bytes = new Uint8Array(binary.length); for (let i = 0; i b.toString(16).padStart(2, '0')).join(''); } ``` Poll the BLS signatures endpoint (`{orchestratorUrl}/bls/signatures/{hexRequestId}`) until a valid signature is generated by validators. **Example Response**: ```json { "signing_request": { "request_id": "9/Pl3Hztt0KrZTMOQvXv87lNSM+SC4wjuUbJbZU3z8Y=", "current_epoch_id": 287, "status": 3 }, "uncompressed_signature_128": "AAAAAAAAAAAAAAAAAAAAABii5ArDtPtnmRw87QXJJRLlMohL3+fEWhuVKJqrh..." } ``` ```typescript // Watch out for backend enum representations (integers vs strings) // e.g. status 3 or 'THRESHOLD_SIGNING_STATUS_COMPLETED' represents success const COMPLETED_STATUSES = new Set([3, '3', 'THRESHOLD_SIGNING_STATUS_COMPLETED']); const FAILED_STATUSES = new Set([4, '4', 'THRESHOLD_SIGNING_STATUS_FAILED']); async function pollBlsSignature(orchestratorUrl: string, hexRequestId: string): Promise { const url = `${orchestratorUrl}/bls/signatures/${hexRequestId.replace(/^0x/, '')}`; while (true) { const data = await fetch(url).then(r => r.json()); const status = data?.signing_request?.status; if (COMPLETED_STATUSES.has(status)) { const sigBase64 = data?.uncompressed_signature_128; if (!sigBase64) { throw new Error('Signature completed but uncompressed_signature_128 is missing.'); } // Convert 128-byte Base64 signature to Hex format for EVM submission const sigBytes = Uint8Array.from(atob(sigBase64), c => c.charCodeAt(0)); const sigHex = '0x' + Array.from(sigBytes).map(b => b.toString(16).padStart(2, '0')).join(''); return sigHex; } if (FAILED_STATUSES.has(status)) { throw new Error('BLS signature generation failed.'); } await new Promise(resolve => setTimeout(resolve, 3000)); // Poll every 3 seconds } } ``` #### Stage 3: Mint on Ethereum Contract Call `mintWithSignature` on the Ethereum bridge contract, submitting the validators' signature data. ```typescript import { ethers } from 'ethers'; const BRIDGE_ABI = [ 'function withdraw((uint64 epochId, bytes32 requestId, address recipient, address tokenContract, uint256 amount, bytes signature) cmd) external', 'function mintWithSignature((uint64 epochId, bytes32 requestId, address recipient, uint256 amount, bytes signature) cmd) external', ]; async function mintOnEthereum( ethProvider: any, bridgeAddress: string, mintParams: { epochId: number; requestId: string; // 32-byte hex string (0x...) recipient: string; amount: string; signature: string; // 128-byte hex signature tokenContract?: string; // Required for ERC-20 unwraps isNativeGNK?: boolean; } ) { const provider = new ethers.BrowserProvider(ethProvider); const signer = await provider.getSigner(); const contract = new ethers.Contract(bridgeAddress, BRIDGE_ABI, signer); let tx; if (mintParams.isNativeGNK) { const cmd = { epochId: mintParams.epochId, requestId: mintParams.requestId, recipient: mintParams.recipient, amount: mintParams.amount, signature: mintParams.signature, }; tx = await contract.mintWithSignature(cmd); } else { const cmd = { epochId: mintParams.epochId, requestId: mintParams.requestId, recipient: mintParams.recipient, tokenContract: mintParams.tokenContract, amount: mintParams.amount, signature: mintParams.signature, }; tx = await contract.withdraw(cmd); } const receipt = await tx.wait(); if (!receipt || receipt.status === 0) { throw new Error('Transaction reverted on-chain'); } return receipt.hash; } ``` --- ## 4. Resilience Recovery System (Resume/Cache) (Recommended / Optional) To 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**: 1. **Write to cache** immediately before broadcasting Stage 1: ```typescript const cacheKey = `pending_unwrap_${userCosmosAddress}`; localStorage.setItem(cacheKey, JSON.stringify({ status: 'burning', gonkaTxHash: '', amount: amountInBaseUnits, destinationEthAddress, step: 1 })); ``` 2. **Update cache** when Gonka TX is broadcasting, and when `request_id` is resolved. 3. **On Mount**: Check if `localStorage.getItem(cacheKey)` exists. If found, display a **"Pending Transaction Detected"** card allowing the user to either: * **Resume Transaction**: Restores states and directly jumps to Stage 2 (Polling BLS Signatures) or Stage 3 (EVM Minting). * **Discard**: Clears the `localStorage` key. --- ## 5. Token List Resolution & Metadata Gathering 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. ### A. Deposit Token List (`allDepositTokens`) 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: * **Approved Tokens Registry**: Retrieve the list of tradeable/bridgeable tokens from the backend registry: `GET {nodeUrl}/productscience/inference/inference/approved_tokens_for_trade`. * **Dynamic WGNK Injection**: Retrieve the current bridge contract address (`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. * **Symbol & Decimal Resolution**: * **Cosmos (IBC)**: Matches assets against an offline metadata map or queries the Cosmos chain bank metadata: `GET {nodeUrl}/cosmos/bank/v1beta1/denoms_metadata/{denom}`. * **Ethereum (Bridge)**: Queries public EVM RPC nodes via raw `eth_call` actions (`0x95d89b41` for `symbol()` and `0x313ce567` for `decimals()`). #### Implementation Example ```typescript // Inject WGNK dynamically if missing from the approved tokens list const allDepositTokens = computed(() => { const list = [...supportedIbcTokens.value, ...supportedEthTokens.value]; if (resolvedBridgeAddress.value && resolvedBridgeAddress.value.startsWith('0x')) { const hasWgnk = list.some( t => t.symbol === 'WGNK' || String(t.contractAddress).toLowerCase() === resolvedBridgeAddress.value.toLowerCase() ); if (!hasWgnk) { list.push({ chainId: 'ethereum', contractAddress: resolvedBridgeAddress.value, symbol: 'WGNK', decimals: 9, type: 'eth', }); } } return list; }); // Direct ERC-20 metadata queries via JSON-RPC eth_call async function queryEvmRpc(to: string, data: string, rpcUrl: string): Promise { const response = await fetch(rpcUrl, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', method: 'eth_call', params: [{ to, data }, 'latest'], id: 1 }) }).then(r => r.json()); return response?.result || '0x'; } // Parsing ERC-20 Symbol name from hex string function parseBytes32OrString(hex: string): string { if (!hex || hex === '0x') return ''; const clean = hex.replace(/^0x/i, ''); if (clean.length = 128) { const length = parseInt(clean.substring(64, 128), 16); if (length > 0 && length = 32 && charCode **Optional 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**: ```json { "contracts": [ "gonka1fa83z7np903k9vh63guy82qthtv373d7vjeq0y7xeqh50rzn8vtssffkre", "gonka15ggwj9un6qrmu4nj5ev6l7kpdcr00td03ff2mmj4cyhl8u8vjd2qnl3hgk" ], "pagination": { "next_key": null, "total": "0" } } ``` To 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**: ```json { "data": { "name": "USD Coin", "symbol": "USDC", "decimals": 6, "total_supply": "1400000" } } ``` To optimize widget performance and avoid repetitive on-chain smart queries, we highly recommend caching this contract metadata locally. * **Cosmos Native IBC Balances**: Query standard bank balances using the bank module REST API: `GET {nodeUrl}/cosmos/bank/v1beta1/balances/{address}`. **Example Response**: ```json { "balances": [ { "denom": "ngonka", "amount": "1000000000" }, { "denom": "ibc/ED07A3391A112B175915CD8FAF43A2153E30D7181A2E45558B93F44C2754781B", "amount": "5000000" } ], "pagination": { "next_key": null, "total": "2" } } ``` * **Dynamic GNK Injection**: Retrieve the user's native GNK (staking token) balance. If it exists, inject it dynamically into the list of withdrawable tokens (mapped as an unwrap action to the Ethereum bridge) so they can unwrap GNK back to WGNK. #### Implementation Example To construct the final withdrawable tokens list, fetch the balances and merge them together: ```typescript async function getWrappedTokenBalances(nodeUrl: string, walletAddress: string) { const response = await fetch(`${nodeUrl}/productscience/inference/inference/wrapped_token_balances/${walletAddress}`); const data = await response.json(); return data?.balances || []; } async function getIbcBalances(nodeUrl: string, walletAddress: string, ibcDenom: string) { const balUrl = `${nodeUrl}/cosmos/bank/v1beta1/balances/${walletAddress}/by_denom?denom=${encodeURIComponent(ibcDenom)}`; const response = await fetch(balUrl); const data = await response.json(); return data?.balance?.amount || '0'; } // Combine wrapped balances with native GNK token staking balances for unwrap const withdrawableTokens = computed(() => { const list = [...wrappedTokenBalances.value]; // Contains both native IBC balances & CW20 wrapped balances if (walletAddress.value) { const gnkBalance = walletStore.balanceOfStakingToken; const gnkAmt = parseFloat(gnkBalance.amount || '0') / 1_000_000_000; const hasGnk = list.some(t => t.symbol === 'GNK'); if (!hasGnk && gnkAmt > 0) { list.unshift({ symbol: 'GNK', full_denom: gnkBalance.denom, formatted_balance: gnkAmt.toString(), decimals: 9, isNative: false, isGnk: true, token_info: { chainId: 'ethereum', contractAddress: '', // mapped dynamically to bridge contract } }); } } return list; }); ``` --- ## Addresses and keys 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: ```text 0x972a7a92d92796a98801a8818bcf91f1648f2f68 ``` --- # Addresses and keys This is the single most important page to understand before bridging. **Read it before your first transfer.** ## One key, two addresses 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: | Chain | Address format | How the address is derived from the public key | | --- | --- | --- | | Ethereum | `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. ## How the bridge decides where your tokens go 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: 1. Detects the finalized deposit transaction on Ethereum. 2. **Recovers the public key** from your transaction's signature. 3. Computes the **Gonka address** for that public key (the `gonka1…` standard derivation above). 4. Mints/releases the bridged tokens to that `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. ## The seed-phrase pitfall (read this!) 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**: * Ethereum wallets use coin type **60** → path `m/44'/60'/0'/0/0` * Cosmos/Gonka wallets use coin type **1200** → path `m/44'/1200'/0'/0/0` Because 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. 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. ## How to get the matching Gonka address You have two options. ### Option A — Use the dashboard (recommended) 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: ```text https://node1.gonka.ai:8443/dashboard/ ``` ### Option B — Import the same private key into the Gonka keyring If 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: ```bash inferenced keys import-hex # Show the derived Gonka address inferenced keys show -a ``` The 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. 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. ## Quick checklist * Decide which key you will bridge with **before** you start. * If you have USDT/ETH on an Ethereum address already: derive the matching `gonka1…` address from that key (dashboard, or `import-hex`). * If you want to use an existing Gonka address: derive the matching `0x…` Ethereum address from that key, fund it with the token and enough ETH for gas. * Always send a small test amount first and confirm it arrives on the expected `gonka1…` address. --- ## Bridge epoch update # Bridge epoch update 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. ## When you need this 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: ```text A Bridge needs epoch update Bridge: Epoch 283 | Chain: Epoch 284 (1 behind) Withdrawals to Ethereum require the bridge to be synced to the current epoch. ``` If 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. ## Manual update If you are not using the dashboard, submit each missing epoch in order: 1. Check the latest epoch known by the Ethereum bridge contract. 2. Start with `latest + 1`. 3. Fetch the epoch data: ```bash curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/bls/epoch_data/" ``` 4. Use the returned `group_public_key` and `validation_signature` fields with the bridge update script: ```bash HARDHAT_NETWORK=mainnet node submit-epoch-public.js \ 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \ \ \ ``` 5. Repeat for every missing epoch until the bridge epoch matches the chain epoch. 6. Retry the withdrawal or WGNK mint execution on Ethereum. 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. --- ## Bridge via dashboard (UI guide) 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: ```text 0x972a7a92d92796a98801a8818bcf91f1648f2f68 ``` --- # Bridge via dashboard (UI guide) The dashboard is the easiest way to bridge. It handles the key derivation for you (see [Addresses and keys](addresses-and-keys.md)), so you don't need to import private keys or compute addresses by hand. 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](deposit-usdt.md), [Withdraw USDT](withdraw-usdt.md), [Deposit GNK](deposit-gnk.md), and [Withdraw GNK](withdraw-gnk.md) if you prefer to do it manually. ## What the dashboard does for you * **Derives the correct addresses.** Connect the Ethereum wallet you bridge with, and the dashboard shows the matching `gonka1…` address the bridge will deliver tokens to — so you always know where your wrapped tokens will land. * **Warns about seed-phrase accounts.** If you are using a wallet whose Ethereum and Gonka keys come from the same **mnemonic**, the dashboard detects this and warns you, because seed-derived accounts use different keys on each chain — so your Gonka wallet won't show the bridged tokens by default. You still control the receiving address (you can derive the matching key from the same mnemonic), but it requires an extra manual step. Read [Addresses and keys](addresses-and-keys.md) for the full explanation. * **Shows your bridged balances** in a Bridge Assets section, so you can confirm a deposit arrived. * **Reports chain status**, so you can see if the chain is degraded before initiating a transfer. * **Prompts for bridge epoch updates** when the Ethereum bridge is behind the Gonka chain. If you see **A Bridge needs epoch update**, click **Update bridge** to submit the missing epoch key. This is a normal Ethereum transaction, so the connected wallet pays gas. See [Bridge epoch update](bridge-epoch-update.md). ## Supported flows The dashboard supports the full set of transfers without using the CLI: * **ETH Bridge** — deposit any ERC-20 (USDT, USDC, WETH, …) from Ethereum to Gonka, or withdraw back to Ethereum. * **GNK Bridge** — bridge native GNK to Ethereum as WGNK and back. * **IBC Bridge** — transfer IBC-native tokens (e.g. USDT) between Gonka and connected Cosmos chains (Kava). ### Processing time & fees | Bridge type | Direction | Processing time | Gas paid in | |---|---|---|---| | ETH Bridge (ERC-20) | Ethereum → Gonka | ~15–20 min (waits for Ethereum finalization) | ETH | | ETH Bridge (ERC-20) | Gonka → Ethereum | ~1–5 min | ETH | | GNK Bridge | Gonka → Ethereum (mint WGNK) | ~1–5 min | ETH | | GNK Bridge | Ethereum → Gonka (burn WGNK) | ~15–20 min | ETH | | IBC | Kava → Gonka | ~1–3 min | KAVA | | IBC | Gonka → Kava | ~1–3 min | GNK (0 fee) | --- ## Deposit tokens to Gonka 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: * **ERC-20 tokens** (USDC, USDT, WETH, …) and **GNK** (as WGNK) go through the **Ethereum bridge**. * **IBC tokens** (USDT IBC, …) go through **IBC** to a connected Cosmos chain. ### How ETH / GNK bridge deposits work 1. **Lock tokens on Ethereum** — your tokens are sent to the bridge contract and locked. 2. **Validator signatures** — Gonka validators observe the finalized Ethereum deposit and collect BLS signatures. 3. **Mint on Gonka** — the wrapped tokens are minted on Gonka and delivered to your derived `gonka1…` address. ### How IBC deposits work 1. **Approve transfer in wallet** — you sign an IBC transfer from the source chain (e.g. Kava). 2. **IBC packet relay** — the packet is relayed to Gonka. 3. **Tokens arrive on Gonka** — IBC tokens appear in your Gonka wallet. ### 1. Open the dashboard Open one of the genesis nodes in your browser: - [https://node1.gonka.ai:8443](https://node1.gonka.ai:8443) - [https://node2.gonka.ai:8443](https://node2.gonka.ai:8443) 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. ### 2. Connect your Keplr wallet 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](../../wallet/create-account.md) 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](addresses-and-keys.md) before proceeding. ### 3. Choose token and amount 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)" === "GNK" === "IBC (USDT)" Click **REVIEW & BRIDGE**. ### 4. Confirm the transaction Your wallet will open a **Confirm Transaction** screen. Review the details carefully before approving: === "ERC-20 (USDC)" - **Token and amount** — verify the correct token and amount. - **From** — your Ethereum address (the sender). - **To** — the bridge contract address (`0x972a7A92…648f2F68`). This is expected — you are sending tokens to the bridge, which will then mint wrapped tokens on Gonka. - **Tx Fee** — the Ethereum gas fee you will pay. === "GNK" - **Token and amount** — verify the correct token and amount. - **To** — the bridge contract address. - **Tx Fee** — the Ethereum gas fee. === "IBC (USDT)" - **Message type** — `IBC Transfer`. - **Amount and destination** — e.g. "Send 0.1 USDt to gonka1… via channel-161". - **Tx Fee** — paid in KAVA (e.g. 0.05 KAVA). Click **Approve** to submit the transaction. Double-check the details before confirming. Bridge transfers are **irreversible**. If anything looks wrong, click **✕** to cancel and start over. ### 5. Deposit complete The widget will show a **Deposit complete** screen with a summary of the operation. === "ERC-20 (USDC)" === "GNK" === "IBC (USDT)" The progress tracker shows: - **Approve transfer in wallet** — done - **IBC packet relay transfer** — done From this screen you can: - Click **VIEW ON EXPLORER** to see the transaction details. - Click **TRANSFER MORE TOKENS** to make another deposit. - Click **DISCONNECT** to disconnect your wallet. ### 6. Verify your deposit You can confirm your wrapped tokens arrived in several ways: - **In the dashboard**: open `https://node2.gonka.ai:8443/dashboard/gonka/account/` and check your balances. - **Via the transaction link** shown on the Deposit complete screen. - **In Keplr**: wrapped tokens (CW-20) do not appear in Keplr automatically — follow the steps below to add them manually. --- ### Add wrapped tokens to Keplr 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. 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 | |---|---| | USDC | `gonka1fa83z7np903k9vh63guy82qthtv373d7vjeq0y7xeqh50rzn8vtssffkre` | | USDT | `gonka15ggwj9un6qrmu4nj5ev6l7kpdcr00td03ff2mmj4cyhl8u8vjd2qnl3hgk` | **Step 4.** Done — the token now appears in your Keplr wallet as a **Gonka CW20** token. --- ## Withdraw tokens from Gonka 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: * **ERC-20 tokens** and **GNK** go through the **Ethereum bridge**. * **IBC tokens** (USDT IBC, …) go through **IBC** to a connected Cosmos chain. ### How ETH / GNK bridge withdrawals work 1. **Burn tokens on Gonka** — the wrapped token is burned (or native GNK is locked) on the Gonka chain. 2. **Validator signatures** — Gonka validators produce a BLS aggregate signature authorizing the release. 3. **Release on Ethereum** — the original token is released from the bridge contract on Ethereum (or WGNK is minted). ### How IBC withdrawals work 1. **Approve transfer in wallet** — you sign an IBC transfer on Gonka. 2. **IBC packet relay** — the packet is relayed to the destination chain. 3. **Tokens arrive** — IBC tokens appear in your wallet on the destination chain (e.g. Kava). ### 1. Open the dashboard Open one of the genesis nodes in your browser: - [https://node1.gonka.ai:8443](https://node1.gonka.ai:8443) - [https://node2.gonka.ai:8443](https://node2.gonka.ai:8443) Navigate to the **Developers** section in the left sidebar. Select the **WITHDRAW** toggle in the bridge widget. ### 2. Connect your Keplr wallet 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](../../wallet/create-account.md) 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](addresses-and-keys.md) before proceeding. ### 3. Choose token and amount 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. 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. === "GNK" === "ERC-20 (USDC)" === "IBC (USDT)" The destination address is a `kava1…` address on the Kava chain. Processing time is ~1–3 minutes. Click **REVIEW & BRIDGE**. ### 4. Confirm the transaction on Gonka Keplr will open a **Confirm Transaction** popup for the Gonka chain. Review the details and click **Approve**. === "GNK" - **Message type** — `MsgRequestBridgeMint`, which locks your GNK on Gonka and requests minting of WGNK on Ethereum. - **Tx Fee** — 0 GNK. === "ERC-20 (USDC)" - **Message type** — `Execute Wasm Contract` call to the wrapped token's CW-20 contract with a `withdraw` payload. - **Tx Fee** — 0 GNK. === "IBC (USDT)" - **Message type** — `IBC Transfer`. - **Amount and destination** — e.g. "Send 0.1 USDt (Kava/channel-5) to kava1… via channel-5". - **Tx Fee** — 0 GNK. 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. ### 5. Confirm the release transaction on Ethereum (ETH / GNK bridge only) 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. - **To** — the bridge contract address on Ethereum. - **Tx Fee** — the Ethereum gas fee (paid in ETH). The exact amount depends on current gas prices. === "GNK" === "ERC-20 (USDC)" Click **Approve** to submit the release transaction. ### 6. Withdrawal complete The widget shows a **Withdrawal complete** screen with all stages marked as done. === "GNK" === "ERC-20 (USDC)" === "IBC (USDT)" The progress tracker shows: - **Approve transfer in wallet** — done - **IBC packet relay transfer** — done From this screen you can: - Click **VIEW ON EXPLORER** to see the transaction details. - Click **TRANSFER MORE TOKENS** to make another withdrawal. - Click **DISCONNECT** to disconnect your wallet. ### 7. Verify your withdrawal You can confirm your tokens arrived in several ways: - **ETH bridge / GNK**: check the released ERC-20 tokens or WGNK in your Ethereum wallet. WGNK appears in Keplr automatically. - **IBC**: check the token balance on the destination chain (e.g. USDT on Kava in Keplr). - **Explorer link**: use the **VIEW ON EXPLORER** link on the Withdrawal complete screen. --- ## Deposit GNK (Gonka → Ethereum) 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: ```text 0x972a7a92d92796a98801a8818bcf91f1648f2f68 ``` --- # Deposit GNK (Gonka → Ethereum) Lock GNK on Gonka and receive wrapped GNK (**WGNK**) at your Ethereum address. ### A) Request Minting WGNK on Ethereum Use CLI to submit a bridge minting request: ```bash ./inferenced tx inference request-bridge-mint \ \ "0xYourEthereumAddr" \ "ethereum" \ --destination-bridge-address 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \ --from \ --chain-id gonka-mainnet \ --gas auto --gas-adjustment 1.5 \ -y \ --node http://node1.gonka.ai:8000/chain-rpc/ ``` 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`). #### Expected Output ```text ... txhash: 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805 ``` Allow a couple of blocks to be mined, then check the status: ```bash ./inferenced query tx 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805 --node http://node1.gonka.ai:8000/chain-rpc/ ``` Verify that `"code": 0` and extract the base64 `request_id`: ```json "request_id": "vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=" ``` Convert the base64 `request_id` to hexadecimal format: ```bash echo "vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=" | base64 -d | xxd -p -c 256 ``` **Example Hex Output:** ```text bd24d688dd69be8a31705a032f378f084ab7c7f0b9350fa314cbdf704a330a6e ``` ### B) Get BLS Signature Status Query the BLS signature API with your request ID hex: ```bash curl "https://node2.gonka.ai:8443/v1/bls/signatures/" \ | jq -r ' { uncompressed_signature_128: .uncompressed_signature_128, current_epoch_id: .signing_request.current_epoch_id, request_id: .signing_request.request_id } ' ``` > **Bridge 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](bridge-epoch-update.md). ### C) Submit Mint Command on Ethereum Submit the mint command to the bridge contract on Ethereum using the [mint-wgnk.js](https://github.com/gonka-ai/gonka/blob/gm/contracts/proposals/ethereum-bridge-contact/mint-wgnk.js) script: ```bash HARDHAT_NETWORK=mainnet node mint-wgnk.js \ 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \ \ \ \ \ ``` --- ## Deposit USDT (Ethereum → Gonka) 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: ```text 0x972a7a92d92796a98801a8818bcf91f1648f2f68 ``` --- # Deposit USDT (Ethereum → Gonka) To 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. 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](addresses-and-keys.md) for how to derive the correct address (or use the dashboard). ### A) Send USDT to the Bridge Contract on Ethereum Execute the transfer to the bridge contract: ```javascript const tx = await usdtContract.transfer( "0x972a7a92d92796a98801a8818bcf91f1648f2f68", // bridge address amountBN // BigNumber amount ); await tx.wait(); ``` 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. ### B) Check Wrapped Token Balance on Gonka Query the wrapped tokens owned by your Gonka address: ```bash curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/wrapped_token_balances/{gonkaAddress}" ``` #### Example Response ```json { "balances": [ { "token_info": { "chainId": "ethereum", "contractAddress": "0xUSDTContractAddress", "wrappedContractAddress": "gonka1CW20WrappedUSDTAddress" }, "symbol": "USDT", "balance": "100000", "decimals": "6", "formatted_balance": "0.1" } ] } ``` ### C) Transfer Wrapped USDT on Gonka Use the wrapped CW-20 token contract address (`gonka1CW20WrappedUSDTAddress`) returned from the query above: ```bash export WUSDT_CONTRACT="gonka1CW20WrappedUSDTAddress" ./inferenced tx wasm execute $WUSDT_CONTRACT \ '{"transfer":{"recipient":"gonka1xxxxxxxx...","amount":"123456"}}' \ --from \ --chain-id gonka-mainnet \ --gas auto --gas-adjustment 1.5 \ -y \ --node http://node1.gonka.ai:8000/chain-rpc/ ``` #### Example Output ```text ... txhash: 39E3D4B86CF6B0C8952C789F4D73DB9FE27DEA4BD25F3842BE9298C78980A51D ``` Allow 2-3 blocks to be mined, then check the status of the transaction: ```bash ./inferenced query tx 39E3D4B86CF6B0C8952C789F4D73DB9FE27DEA4BD25F3842BE9298C78980A51D --node http://node1.gonka.ai:8000/chain-rpc/ ``` 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`). --- ## Multisig signer guide # Multisig signer guide This guide is for individuals who have been selected to be signers on the Gonka Ethereum Bridge Multisig. ## What is a Safe Multisig? 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. ## 1. Prerequisites Before you can be added to the multisig, please make sure the following items are ready: * **Ethereum Wallet Address**: A secure Ethereum address that you control. * **Hardware Wallet (Highly Recommended)**: For mainnet security, it is strongly advised to use a hardware wallet (e.g., Ledger or Trezor) rather than a software-only "hot" wallet. * **Network Access**: Ensure you can access [app.safe.global](https://app.safe.global) and have an RPC provider (like Infura, Alchemy, or a public node) configured in your wallet. * **Small Amount of ETH**: While signing a transaction is usually free (off-chain signature), the person who **executes** the final transaction will need to pay gas in ETH. It is good practice for every signer to have at least 0.05 - 0.1 ETH for emergency executions. ## 2. Onboarding Process ### Step 1: Provide your Address Send your public Ethereum address (0x...) to the multisig administrator. **Double-check every character.** Do not send your private key or seed phrase. ### Step 2: The Addition Transaction 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). ### Step 3: Access the Safe Once the transaction is confirmed on the blockchain: 1. Go to [app.safe.global](https://app.safe.global). 2. Connect your wallet. 3. Add the Safe. 4. Enter the Multisig Address provided by the administrator. 5. You should now see the Safe dashboard and your address listed under "Owners." ## 3. How to Sign Transactions The most common task for a participant is reviewing and signing proposed transactions. 1. **Review**: * Open the Safe dashboard. * Go to the **"Transactions"** tab -> **"Queue"**. * Click on the transaction to expand the details. 2. **Sign**: Click the **"Sign"** button. Your wallet will pop up asking for a signature. This is usually an off-chain signature and does not cost gas. 3. **Wait**: Once the threshold of signatures is reached, the transaction can be executed. ## 4. How to Execute Transactions If you are the last person to sign, or if you are tasked with finalizing a transaction: 1. After the required number of signatures (e.g., 2 or 3) are collected, the **"Execute"** button will become active. 2. Click **"Execute"**. 3. Your wallet will prompt you to pay the gas fee to submit the transaction to the blockchain. 4. Once the transaction is mined, the action is completed. ## 5. Security Best Practices * **Verify the Safe Address**: Always ensure you are interacting with the correct Safe address. Bookmark the link once you've loaded it. * **Check Transaction Details**: Malicious actors may try to propose transactions that transfer ownership to themselves. Never sign a transaction if you don't understand the destination or the purpose. * **Keep Backups**: Ensure your hardware wallet seed phrase is backed up securely offline. If you lose access to your key, the multisig cannot "reset" your access without a majority vote from the other signers. * **Use the Official App**: Only use [app.safe.global](https://app.safe.global). Beware of phishing sites. --- ## Ethereum bridge overview # Ethereum bridge overview 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: ```text 0x972a7a92d92796a98801a8818bcf91f1648f2f68 ``` [View the bridge contract on Etherscan](https://etherscan.io/address/0x972a7a92d92796a98801a8818bcf91f1648f2f68){target=_blank} > **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](https://skynet.certik.com/projects/gonka){target=_blank}. 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)](../../assets/audits/CertiK-Gonka-Ethereum-Bridge-Audit.pdf){target=_blank}. The bridge allows you to move: * **Any ERC-20 token** (e.g., [USDT](https://etherscan.io/token/0xdAC17F958D2ee523a2206206994597C13D831ec7){target=_blank}, [USDC](https://etherscan.io/token/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48){target=_blank}, [WETH](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2){target=_blank}) from Ethereum to Gonka and back. * **Native Gonka coin (GNK)** to Ethereum (as wrapped GNK) and back. > **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](register-token.md) 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](addresses-and-keys.md) **before** your first transfer. --- ## Overview ### Wrapping ERC-20 Tokens (e.g., USDT) from Ethereum to Gonka 1. **Deposit**: The owner of the ERC-20 token sends their tokens to the bridge smart contract address on Ethereum. 2. **Locking & Minting**: The tokens become locked in the contract. Each Gonka host runs a small bridge container that watches the bridge address. Once the deposit is **finalized** on Ethereum and **more than 50% of the hosts (by voting power)** have independently confirmed it, the bridge mints wrapped versions of that ERC-20 on the Gonka chain as CW-20 tokens. 3. **One wrapped contract per token**: Each Ethereum token maps to exactly **one** wrapped CW-20 contract on Gonka (keyed by chain ID + Ethereum contract address). The first deposit of a given token instantiates that contract; every later deposit of the **same** token reuses the **same** wrapped contract. Only the bridge can instantiate these contracts or mint their tokens. 4. **Ownership**: After minting, ownership of the wrapped tokens is assigned to the Gonka address derived from the same private/public key pair used on Ethereum. From this point, the owner can freely transfer the wrapped tokens to any other Gonka account. See [Deposit USDT (Ethereum → Gonka)](deposit-usdt.md) for the step-by-step flow. Registering a token (see [Register a bridge token](register-token.md)) 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. ### Unwrapping / Withdrawing back to Ethereum 1. **Request**: The owner submits a special withdrawal transaction on the Gonka chain. This locks/burns the wrapped token and triggers BLS signature generation. 2. **Signature Retrieval**: Check the status of the signature generation using the provided API endpoint. 3. **Execution**: Once the BLS signature is produced, it is used to send a withdrawal command to the bridge contract on Ethereum. The contract verifies the signature and releases the original tokens to the target Ethereum address. See [Withdraw USDT (Gonka → Ethereum)](withdraw-usdt.md) for the step-by-step flow. ### Wrapping Native GNK to Ethereum (WGNK) 1. **Escrow**: A special transaction locks GNK on an escrow account and triggers BLS signature generation. 2. **Execution**: The generated BLS signature is submitted to the bridge contract on Ethereum to mint WGNK to the target Ethereum address. See [Deposit GNK (Gonka → Ethereum)](deposit-gnk.md) for the step-by-step flow. 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. ### Returning WGNK from Ethereum back to GNK 1. **Burn**: WGNK is sent to the bridge contract on Ethereum, which burns it. 2. **Release**: Once the burn is recognized by Gonka consensus, the equivalent native GNK is released from escrow to the Gonka address derived from the same key that burned the WGNK. See [Withdraw GNK (Ethereum → Gonka)](withdraw-gnk.md). ### Bridging ETH (as WETH) The bridge detects ERC-20 transfers, not native ETH transfers. To bring ether to Gonka: 1. **Wrap**: Wrap your ETH into **WETH** (the standard Wrapped Ether ERC-20) on Ethereum. 2. **Bridge**: Send the WETH to the bridge contract — it behaves like [any other ERC-20 deposit](deposit-usdt.md). Gonka mints the wrapped WETH as a CW-20 token to the Gonka address derived from the same key, and you can withdraw it back to Ethereum the same way. --- ## How Gonka → Ethereum is authorized (the daily group key) 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: * At the start of each epoch (about **once per day**), Gonka generates a **new group key** and signs it with the **previous** epoch's key. * A small transaction must be submitted to the Ethereum bridge contract to register that new key. The contract only accepts the **next** sequential epoch key, signed by the previous one — so the key history forms an unbroken chain back to genesis. * **Anyone** can submit this update with the same public data. 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: 1. Submit the withdrawal/mint operation on Gonka, specifying the **recipient Ethereum address**. This burns/escrows the asset and triggers BLS signing with the group key. 2. Retrieve the produced signature. 3. Submit the signature plus the transfer data to the bridge contract on Ethereum, which verifies it against the current group key and releases the ERC-20, ETH, or WGNK to the recipient. ### If the current epoch key isn't registered yet 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](bridge-epoch-update.md). ## Timing & finalization Transfer time depends on the direction: * **Ethereum → Gonka: about 15–20 minutes.** The bridge waits for the deposit block to be **finalized** on Ethereum (≈ two epochs) before minting. Gonka uses no intermediaries that front the funds and take on risk, so this wait is unavoidable. The exact time also depends on where in the Ethereum epoch your transaction lands. * **Gonka → Ethereum: fast.** The group key is formed once per epoch and used all day, so you can start a withdrawal at any time and only wait for the BLS signature and your Ethereum execution transaction. > **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](tracker-integration.md), wait until it is healthy again before bridging. ## Bridge vs. exchange 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: * On Ethereum, e.g. swap **WGNK ↔ USDC** on a DEX such as Uniswap. * On Gonka, swap wrapped tokens via the on-chain liquidity pool. So a typical "sell GNK on Ethereum" flow is: bridge GNK → WGNK to Ethereum, then trade WGNK for another token on a DEX. ## Bridge vs. IBC This bridge connects Gonka directly with **Ethereum**. Gonka also supports **IBC** for transfers with other Cosmos chains (see the [IBC](../ibc/withdraw-usdt-via-kava.md) section). * Use the **Ethereum bridge** to move assets between **Ethereum and Gonka**. It is typically simpler and needs fewer gas tokens than routing through IBC. * A token bridged from Ethereum lives on Gonka as a wrapped CW-20 tied to this bridge. It can be transferred within Gonka and sent **back to Ethereum**, but it **cannot** be forwarded or sold onto another Cosmos chain — for that you would use an IBC-native asset. --- ## Where to next * [Addresses and keys](addresses-and-keys.md) — how a single private key controls both your Ethereum and Gonka addresses, and the seed-phrase pitfall. * [Using the dashboard](dashboard.md) — the easiest way to bridge, with no CLI or raw keys. * [Bridge epoch update](bridge-epoch-update.md) — what to do if the bridge is one or more epochs behind the Gonka chain. * [Deposit USDT (Ethereum → Gonka)](deposit-usdt.md) and [Withdraw USDT (Gonka → Ethereum)](withdraw-usdt.md) — bridging an ERC-20 both ways. * [Deposit GNK (Gonka → Ethereum)](deposit-gnk.md) and [Withdraw GNK (Ethereum → Gonka)](withdraw-gnk.md) — bridging native GNK both ways. * [Register a bridge token](register-token.md) — optional metadata/trading registration. * [Dashboard & tracker integration](tracker-integration.md) — for explorer/tracker operators integrating bridge data. --- ## Register a bridge token 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: ```text 0x972a7a92d92796a98801a8818bcf91f1648f2f68 ``` --- # Register a bridge token > **Registration 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: * attaches **metadata** (name, symbol, decimals) so the wrapped token displays correctly in wallets, explorers, and the dashboard, and * makes the token **eligible for trading** in the on-chain liquidity pool. 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. ### Prerequisites Before starting, you need the following information about the ERC-20 token: * **Chain ID**: The source chain identifier (typically `"ethereum"` or `"sepolia"` for testnet). * **Contract Address**: The ERC-20 contract address on Ethereum (e.g., `0xdAC17F958D2ee523a2206206994597C13D831ec7` for USDT). * **Name**: The full name of the token (e.g., `"Tether USD"`). * **Symbol**: The ticker symbol of the token (e.g., `"USDT"`). * **Decimals**: The token's precision (e.g., `6` or `18`). ### Step-by-Step Instructions #### Step 1: Get the Governance Module Address (Authority) The governance module account address acts as the `authority` that signs and executes the proposal. To find this address on your node, run: ```bash inferenced query auth module-accounts --node $SEED_URL/chain-rpc/ | grep -B2 'name: gov' ``` Copy the returned Cosmos address (e.g., `cosmos1...gov...`). #### Step 2: Prepare the Proposal File 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). ##### Proposal JSON Template ```json { "messages": [ { "@type": "/inference.inference.MsgRegisterTokenMetadata", "authority": "cosmos1...gov...", // from step 1 "chainId": "ethereum", "contractAddress": "0xTokenContractAddressOnEthereum", "name": "Token Name", "symbol": "SYMBOL", "decimals": 18, "overwrite": false } ], "metadata": "ipfs://CID", "deposit": "500000000000ngonka", "title": "Register Wrapped SYMBOL Token Metadata", "summary": "This proposal registers the metadata for the SYMBOL ERC-20 token bridged from Ethereum on the Gonka chain." } ``` Replace: * `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). #### Step 3: Submit the Governance Proposal Run this transaction from your private machine holding your Cold Account Key: ```bash inferenced tx gov submit-proposal ./register_token_proposal.json \ --from \ --keyring-backend file \ --unordered --timeout-duration=60s \ --gas=2000000 --gas-adjustment=5.0 \ --node $SEED_URL/chain-rpc/ \ --yes ``` You will be prompted to enter your file keyring password. #### Step 4: Top Up Deposit and Vote Once submitted, retrieve the `proposal_id` from the transaction log or query all proposals: ```bash inferenced query gov proposals --node $SEED_URL/chain-rpc/ ``` If your initial deposit was below the minimum required to enter the voting period, top it up: ```bash inferenced tx gov deposit 500000000000ngonka \ --from \ --keyring-backend file \ --unordered --timeout-duration=60s \ --gas=2000000 --gas-adjustment=5.0 \ --node $SEED_URL/chain-rpc/ \ --yes ``` Once the proposal is in the **Voting Period**, cast your vote: ```bash inferenced tx gov vote yes \ --from \ --keyring-backend file \ --unordered --timeout-duration=60s \ --gas=2000000 --gas-adjustment=5.0 \ --node $SEED_URL/chain-rpc/ \ --yes ``` #### Step 5: Verification After the voting period ends and the proposal passes, you can verify that the metadata is successfully registered. ##### 1. Verify Metadata Query the token metadata using the chain API or CLI: ```bash curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/token_metadata/ethereum/0xTokenContractAddressOnEthereum" ``` ##### 2. Verify Wrapped Token Balances Once 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: ```bash curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/wrapped_token_balances/{gonkaAddress}" ``` ##### 3. One wrapped contract per token Each 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.: ```text https://node1.gonka.ai:8443/dashboard/gonka/cosmwasm/105/transactions?contract= ``` --- ## Dashboard & tracker integration 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: ```text 0x972a7a92d92796a98801a8818bcf91f1648f2f68 ``` --- # Dashboard & tracker integration This 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. ## End-user dashboard The hosted dashboard already exposes bridge functionality for end users — connecting an Ethereum wallet, deriving the matching `gonka1…` address (see [Addresses and keys](addresses-and-keys.md)), viewing wrapped balances, and driving deposits/withdrawals: ```text https://node1.gonka.ai:8443/dashboard/ ``` Per-contract CosmWasm transaction history (useful for auditing a wrapped token) is available at: ```text https://node1.gonka.ai:8443/dashboard/gonka/cosmwasm/105/transactions?contract= ``` ## Bridge contract addresses (per chain) The trusted bridge contract addresses Gonka accepts deposits from, by chain: ```bash curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/bridge_addresses/ethereum" ``` ## Bridge transactions List inbound bridge transactions (deposits/burns being validated and completed): ```bash curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/bridge_transactions" ``` Look up a single transaction by its origin coordinates `(originChain, blockNumber, receiptIndex)`: ```bash curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/bridge_transaction/ethereum/{blockNumber}/{receiptIndex}" ``` Each 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". ## Wrapped token balances for an address List all wrapped (CW-20) balances held by a Gonka address, with symbol, decimals, and a human-formatted balance: ```bash curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/wrapped_token_balances/{gonkaAddress}" ``` ## Token metadata Resolve the registered name/symbol/decimals for a bridged token by its source chain and Ethereum contract: ```bash curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/token_metadata/ethereum/{ethereumContractAddress}" ``` Metadata only exists for tokens that have been registered (see [Register a bridge token](register-token.md)). 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. ## One wrapped contract per token 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. ## Trading-related queries (liquidity pool) If you also surface trading data: ```bash # Tokens approved for trading via the liquidity pool curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/approved_tokens_for_trade" # Validate that a CW-20 is an authorized wrapped token for trading curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/validate_wrapped_token_for_trade/{contractAddress}" # The singleton liquidity pool contract address / code id curl "https://node2.gonka.ai:8443/chain-api/productscience/inference/inference/liquidity_pool" ``` ## Bridge service status The decentralized API exposes the bridge ingestion queue health, useful for an operations panel: ```bash curl "https://node2.gonka.ai:8443/v1/bridge/status" curl "https://node2.gonka.ai:8443/v1/bridge/addresses?chain=ethereum" ``` --- ## Withdraw GNK (Ethereum → Gonka) 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: ```text 0x972a7a92d92796a98801a8818bcf91f1648f2f68 ``` --- # Withdraw GNK (Ethereum → Gonka) This is the reverse of [Deposit GNK (Gonka → Ethereum)](deposit-gnk.md). 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](addresses-and-keys.md). ### A) Burn WGNK on Ethereum 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. ```javascript // WGNK is the bridge contract itself (it is both the bridge and the WGNK ERC-20) const tx = await wgnkContract.transfer( "0x972a7a92d92796a98801a8818bcf91f1648f2f68", // bridge / WGNK address amountBN // BigNumber amount (9 decimals) ); await tx.wait(); ``` WGNK uses **9 decimals** to match the native GNK token. ### B) Wait for Finalization 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. ### C) Check Your GNK Balance on Gonka Query the native balance of the Gonka address derived from your key: ```bash inferenced query bank balances --node http://node1.gonka.ai:8000/chain-rpc/ ``` You should see the released amount in `ngonka` (1 GNK = 10^9 ngonka). 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](addresses-and-keys.md)). --- ## Withdraw USDT (Gonka → Ethereum) 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: ```text 0x972a7a92d92796a98801a8818bcf91f1648f2f68 ``` --- # Withdraw USDT (Gonka → Ethereum) 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](overview.md#how-gonka-ethereum-is-authorized-the-daily-group-key) for the background. ### A) Send Withdrawal Request on Gonka Initiate the withdrawal transaction using CLI: ```bash ./inferenced tx wasm execute \ '{"withdraw":{"amount":"","destination_address":"0xYourEthereumAddr","destination_bridge_address":"0x972a7a92d92796a98801a8818bcf91f1648f2f68"}}' \ --from \ --chain-id gonka-mainnet \ --gas auto --gas-adjustment 1.5 \ -y \ --node http://node1.gonka.ai:8000/chain-rpc/ ``` 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`). #### Expected Output ```text ... txhash: 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805 ``` ### B) Retrieve Withdrawal Receipt & Request ID Allow a couple of blocks to be mined, then query the transaction hash to obtain the request ID: ```bash ./inferenced query tx 12E8ABCA5A35D73042564FDF6D686424F742414EEC172450AB6EDA34BD1F0805 --node http://node1.gonka.ai:8000/chain-rpc/ ``` Ensure the output contains `"code": 0` (indicating success) and extract the base64-encoded `request_id`: ```json "request_id": "vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=" ``` Convert the base64 `request_id` to hexadecimal format: ```bash echo "vSTWiN1pvooxcFoDLzePCEq3x/C5NQ+jFMvfcEozCm4=" | base64 -d | xxd -p -c 256 ``` **Example Hex Output:** ```text bd24d688dd69be8a31705a032f378f084ab7c7f0b9350fa314cbdf704a330a6e ``` ### C) Get BLS Signature Status Query the BLS signature API with your request ID hex: ```bash curl "https://node2.gonka.ai:8443/v1/bls/signatures/" \ | jq -r ' { uncompressed_signature_128: .uncompressed_signature_128, current_epoch_id: .signing_request.current_epoch_id, request_id: .signing_request.request_id } ' ``` The 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](bridge-epoch-update.md). ### D) Submit Withdrawal Command on Ethereum Use the [withdraw-tokens.js](https://github.com/gonka-ai/gonka/blob/gm/contracts/proposals/ethereum-bridge-contact/withdraw-tokens.js) script: ```bash HARDHAT_NETWORK=mainnet node withdraw-tokens.js \ 0x972a7a92d92796a98801a8818bcf91f1648f2f68 \ \ \ \ 0xdAC17F958D2ee523a2206206994597C13D831ec7 \ \ ``` --- ## Withdraw USDT via Kava (Gonka → Ethereum) # Withdraw USDT via Kava (Gonka → Ethereum) **Use 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. ## Important: this guide is for IBC USDT This guide covers **IBC USDT on Gonka / Kava Cosmos**. Do **not** confuse it with: - native **ERC-20 USDT** on Ethereum - exchange USDT balances - USDT on other networks Before sending funds, always check: - asset denom - source network - destination network - destination address ## Route overview The route has **three steps**: 1. **Gonka → Kava (Cosmos)** in **Keplr** 2. **Kava → Kava EVM** in **[app.kava.io](https://app.kava.io)** 3. **Kava EVM → Ethereum** in **[Stargate](https://stargate.finance/transfer)** ## Before starting Requirements: - **Spendable USDT on Gonka** in the wallet balance - Some **`GNK`** for Gonka transaction fees - Some **KAVA** for Kava / Kava EVM fees - Some **ETH** for Ethereum fees - **Keplr** and **MetaMask** installed - A **small test transfer first** **Useful official pages:** - Keplr help, including IBC: [help.keplr.app](https://help.keplr.app/) - Kava app, including transfer + wKAVA: [app.kava.io](https://app.kava.io) — transfer: [app.kava.io/transfer](https://app.kava.io/transfer) - Kava Help Center: [help.app.kava.io](https://help.app.kava.io/) - Stargate bridge UI: [stargate.finance/transfer](https://stargate.finance/transfer) - Kava guide on bridging USDT with Stargate: [How to Bridge USDt with Stargate](https://www.kava.io/news/how-to-bridge-usdt-with-stargate) ## Important: use the right address at each step - In **Step 1**, send to the **Kava Cosmos address** in Keplr: **`kava1...`** - In **Step 2**, connect both wallets inside **app.kava.io** - In **Step 3**, receive on the **Ethereum address** in MetaMask: **`0x...`** --- ## Step 1 — Send USDT from Gonka to Kava (Cosmos) This step sends funds from **Gonka** to a **Kava Cosmos** address in **Keplr**. ### 1. Turn on manual IBC in Keplr In **Keplr**: **Settings → Advanced → Manual IBC Transfer → ON** If labels differ slightly by version, use Keplr’s own docs: [help.keplr.app](https://help.keplr.app/). ### 2. Configure the transfer on Gonka - Open **Advanced IBC Transfer** for the **USDT / USDt** asset If Keplr shows **Add IBC channel** or **New IBC channel**, set: - **Destination chain:** **Kava** - **Source Channel Id:** **`channel-5`** Then save the channel. ### 3. Copy the Kava address - Make sure **Kava** is visible in Keplr - Switch to **Kava** - Copy the full **`kava1...`** address ### 4. Send a small test amount On **Advanced IBC Transfer**, choose **Kava (`channel-5`)** from the destination dropdown. Then: - Paste the **`kava1...`** address - Enter a **small test amount** - Leave **memo** empty unless the destination is an **exchange deposit address** requiring a **memo/tag** - Review the fee in **`ngonka`** - Approve the transaction USDT should appear on **Kava in Keplr**. --- ## Step 2 — Move USDT from Kava IBC to Kava EVM This step moves funds from **Kava Cosmos** to **Kava EVM**. Start with a small test amount. ### 1. Open the Kava transfer tool Open the **Transfer** page: [app.kava.io/transfer](https://app.kava.io/transfer). ### 2. Connect both wallets - Connect **Keplr** for the **Kava** IBC side - Connect **MetaMask** for the **Kava EVM** side ### 3. Set the route Choose: - **Asset:** **USDT** - **Sending chain:** **Kava IBC** - **Receiving chain:** **Kava EVM** - Click **Transfer** 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](https://help.app.kava.io/article/44-how-to-transfer-usdt-to-cosmos-chains-with-a-single-click). ### If USDT does not appear in MetaMask 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: - the current **[Kava Help Center](https://help.app.kava.io/)** - the **[app.kava.io](https://app.kava.io)** UI - the wallet’s token information If MetaMask asks for decimals, use **6**. --- ## Step 3 — Bridge USDT from Kava EVM to Ethereum This step bridges funds from **Kava EVM** to **Ethereum mainnet**. ### 1. Open Stargate Open: [stargate.finance/transfer](https://stargate.finance/transfer). Background from Kava on this bridge pattern: [How to Bridge USDt with Stargate](https://www.kava.io/news/how-to-bridge-usdt-with-stargate). ### 2. Make sure MetaMask is on Kava EVM Before starting, MetaMask should be connected to **Kava EVM**. The source network is **Kava EVM**, not Ethereum. ### 3. Set the bridge route In Stargate, choose: - **From / Source:** **Kava EVM** - **To / Destination:** **Ethereum** - **Asset:** **USDT** In some UIs, the source may be shown simply as **Kava**. The important condition is matching the network where USDT sits after Step 2. ### 4. Review fees and send a small test Before confirming: - Check the **bridge fee** - Check the **estimated received amount** - Send a **small test first** Then approve the transaction in MetaMask. USDT should appear on **Ethereum Mainnet in MetaMask**. ### If Stargate does not offer this route 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. --- ## Step 4 — Confirm the funds on Ethereum - Switch MetaMask to **Ethereum Mainnet** - Check the **USDT** balance for the receiving address - If needed, import the token manually A commonly used Ethereum mainnet USDT contract is: `0xdAC17F958D2ee523a2206206994597C13D831ec7` Before importing, verify the current contract in a trusted source such as: - **Tether** - **[Etherscan](https://etherscan.io/)** - the wallet’s verified token list After the test amount arrives, repeat the same flow for the remaining balance. --- ## Optional — Move KAVA between Kava Cosmos and Kava EVM If KAVA is needed on the other side for gas, use: [app.kava.io/evm/wkava](https://app.kava.io/evm/wkava). Step-by-step guide from Kava: [Send KAVA to and from Kava Cosmos and Kava EVM](https://help.app.kava.io/article/26-send-kava-to-and-from-kava-cosmos-and-kava-evm). --- ## Advanced note — verify the Gonka IBC channel before large transfers 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: ```bash 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}' ``` At the time of guide preparation, the Gonka → Kava transfer used: - **Gonka side:** `channel-5` - **Kava side:** `channel-161` When sending **from Gonka**, use the **Gonka-side channel**, which is **`channel-5`**. --- ## Final safety reminder Before sending the full amount, make sure: - Step 1 ended with USDT visible on **Kava in Keplr** - Step 2 ended with USDT visible on **Kava EVM in MetaMask** - Step 3 offers **USDT from Kava EVM to Ethereum** in **Stargate** - The test transfer completed successfully 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. --- ## Redirecting to Hosts Section # Redirecting to Hosts Section This page is redirecting you to the [Hosts section](/docs/#hosts) of the documentation. If you are not redirected automatically, please [click here](/docs/#hosts). --- ## Benchmark to Choose Optimal Deployment Config for LLMs # Benchmark to Choose Optimal Deployment Config for LLMs ## Intro 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-validation.md) (`mlnode-validate` skill in the [`gonka` repo](https://github.com/gonka-ai/gonka)). [Link to our vLLM fork](https://github.com/product-science/vllm/tree/productscience/v0.8.1). ## Understanding vLLM Parameters To configure a vLLM-based model deployment, you define `args` for each model: ``` "Qwen/Qwen3-32B-FP8": { "args": [ "--tensor-parallel-size", "4", "--pipeline-parallel-size", "2" ] } ``` These args define the configuration for each vLLM instance that MLNode will manage. Detailed descriptions can be found in the [vLLM documentation](https://docs.vllm.ai/en/v0.8.1/serving/engine_args.html). The 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._ | | | ## Performance testing To measure the performance of your model deployment, you'll use the `compressa-perf` tool. You can find the tool on [GitHub](https://github.com/product-science/compressa-perf). ### 1. Install the Benchmark Tool First, install `compressa-perf` using pip: ``` pip install git+https://github.com/product-science/compressa-perf.git ``` ### 2. Obtain the Configuration File The benchmark tool uses a YAML configuration file to define test parameters. A default configuration file is available [here](https://github.com/product-science/inference-ignite/blob/main/mlnode/packages/benchmarks/resources/config.yml). ### 3. Run the Performance Test Once your model is deployed, you can test its performance. Use the following command, replacing `` and `` 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 \ measure-from-yaml \ --no-sign \ --node_url http://: \ config.yml \ --model_name MODEL_NAME ``` Performance results will be saved to a file named `compressa-perf-db.sqlite` ### 4. View Results To display the benchmark results, including key metrics and parameters, run: ``` compressa-perf list --show-metrics --show-parameters ``` This command will output a report with the following performance metrics: | **Metric** | **Description** | **Desired Value** | |-------------------------------|------------------------------------------------------------------------------------------------------------------|-------------------| | **TTFT (Time To First Token)** | Time elapsed until the **first token** is generated. | Lower is better | | **LATENCY** | Total time taken for the model to generate the **complete response**. | Lower is better | | **TPOT (Time Per Output Token)** | Average time to generate **each token after the first one**. | Lower is better | | **THROUGHPUT_INPUT_TOKENS** | Input token processing speed: total **prompt tokens** / total response time (tokens per second). | Higher is better | | **THROUGHPUT_OUTPUT_TOKENS** | Output token generation speed: total **generated tokens** / total response time (tokens per second). | Higher is better | ## Deployment and Performance Optimization Plan Testing is performed on a server where MLNode has been deployed according to [the instructions](https://gonka.ai/host/multiple-nodes/#running-the-inference-node-on-a-separate-server). Ensure the performance tool (`compressa-perf`) is installed and the necessary configuration file has been downloaded before proceeding. ### 1. Establish Initial Configuration with Mandatory Parameters - Define base configuration: === "JSON" ```JSON "MODEL_NAME": { "args": [ ] } ``` ### 2. Define Potential Deployment Configurations for Testing Determine 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. ### 3. Test Each Configuration and Measure Performance For each defined configuration: #### 3.1. Deploy the Configuration Deploy the current configuration using the MLNode REST API endpoint: ``` http://:/api/v1/inference/up ``` Python example below: === "Python" ```Python import requests from typing import List, Optional def inference_up( base_url: str, model: str, config: dict ) -> dict: url = f"{base_url}/api/v1/inference/up" payload = { "model": model, "dtype": "float16", "additional_args": config["args"] } response = requests.post(url, json=payload) response.raise_for_status() return response.json() model_name = "MODEL_NAME" model_config = { "args": [ "--tensor-parallel-size", "8", "--pipeline-parallel-size", "1", ] } inference_up( base_url="http://:", model=model_name, config=model_config ) ``` #### 3.2. Verify Deployment - Check the MLNode logs for any errors that may have occurred during deployment. - Verify the deployment status by checking the REST API endpoint `http://:/api/v1/state`. The expected status: ``` {'state': 'INFERENCE'} ``` #### 3.3. Measure Performance Run the `compressa-perf` tool to measure the performance of the deployed configuration and collect the relevant metrics. ### 4. Compare Performance Results Across Configurations 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. ## Example: `Qwen/Qwen3-32B-FP8` at 8x4070 STi server 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: - API management port (default 8080) is mapped to `http://24.124.32.70:46195` - Inference port (default 5000) is mapped to `http://24.124.32.70:46085` For 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 fp8` ### 1. Establish Initial Configuration with Mandatory Parameters Based on these mandatory parameters, the initial configuration for `Qwen/Qwen3-32B-FP8` must include: === "JSON" ```JSON "Qwen/Qwen3-32B-FP8": { "args": [ ] } ``` ### 2. Define Potential Deployment Configurations for Testing The `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: - **TP=8, PP=1** - **TP=4, PP=2** - TP=2, PP=4 - TP=1, PP=8 High pipeline parallelism typically doesn't yield good performance in a single-server deployment. Therefore, in this example, we’ll test only two configurations: - Configuration 1 (TP=8, PP=1). - Configuration 2 (TP=4, PP=2) ### 3. Deploy and Measure Each Configuration #### 3.1 Configuration 1 (TP=8, PP=1) ##### 3.1.1. Deploy Use a Python script to deploy the model: === "Python" ```Python ... model_name = Qwen/Qwen3-32B-FP8" model_config = { "args": [ "--tensor-parallel-size", "8", "--pipeline-parallel-size", "1", ] } inference_up( base_url="http://24.124.32.70:46195", model=model_name, config=model_config ) ``` The expected status: ``` {"status": "OK"} ``` ##### 3.1.2. Verify Deployment In MLNode logs, we see that vLLM has been deployed successfully: ``` ... INFO 05-15 23:50:01 [api_server.py:1024] Starting vLLM API server on http://0.0.0.0:5000 INFO 05-15 23:50:01 [launcher.py:26] Available routes are: INFO 05-15 23:50:01 [launcher.py:34] Route: /openapi.JSON, Methods: GET, HEAD INFO 05-15 23:50:01 [launcher.py:34] Route: /docs, Methods: GET, HEAD INFO 05-15 23:50:01 [launcher.py:34] Route: /docs/oauth2-redirect, Methods: GET, HEAD INFO 05-15 23:50:01 [launcher.py:34] Route: /redoc, Methods: GET, HEAD INFO 05-15 23:50:01 [launcher.py:34] Route: /health, Methods: GET INFO 05-15 23:50:01 [launcher.py:34] Route: /load, Methods: GET INFO 05-15 23:50:01 [launcher.py:34] Route: /ping, Methods: GET, POST INFO 05-15 23:50:01 [launcher.py:34] Route: /tokenize, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /detokenize, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /v1/models, Methods: GET INFO 05-15 23:50:01 [launcher.py:34] Route: /version, Methods: GET INFO 05-15 23:50:01 [launcher.py:34] Route: /v1/chat/completions, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /v1/completions, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /v1/embeddings, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /pooling, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /score, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /v1/score, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /v1/audio/transcriptions, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /rerank, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /v1/rerank, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /v2/rerank, Methods: POST INFO 05-15 23:50:01 [launcher.py:34] Route: /invocations, Methods: POST INFO: Started server process [4437] INFO: Waiting for application startup. INFO: Application startup complete. INFO: 127.0.0.1:37542 - "GET /v1/models HTTP/1.1" 200 OK ``` To further verify, let's check the status via the API: === "Python" ```python requests.get( "http://24.124.32.70:46195/api/v1/state" ).JSON() ``` The expected status: ``` {'state': 'INFERENCE'} ``` The model has been deployed successfully. ##### 3.1.3. ​​Measure Performance Start the performance test: ``` compressa-perf \ measure-from-yaml \ --no-sign \ --node_url http://24.124.32.70:46085 \ --model_name Qwen/Qwen3-32B-FP8 \ config.yml ``` > **Check 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 ``` Results: ![Results for Configuration 1](results-for-configuration-1-(tp=8-pp=1).png) #### 3.2. Configuration 2 (TP=4, PP=2) ##### 3.2.1. Deploy Use a Python script to deploy the model: === "Python" ```Python ... model_name = "Qwen/Qwen3-32B-FP8" model_config = { "args": [ "--tensor-parallel-size", "4", "--pipeline-parallel-size", "2", ] } inference_up( base_url="http://24.124.32.70:46195", model=model_name, config=model_config ) ``` The expected status: ``` {"status": "OK"} ``` ##### 3.2.2. Verify Deployment Check that the log shows successful deployment and `/api/v1/state` still returns `{'state': 'INFERENCE'}` ##### 3.2.3. ​​Measure Performance Measure performance a second time using the same command: ``` compressa-perf \ measure-from-yaml \ --no-sign \ --node_url http://24.124.32.70:46085 \ --model_name Qwen/Qwen3-32B-FP8 \ config.yml ``` When the test finishes, we can check the results: ``` compressa-perf list --show-metrics --show-parameters ``` ![Results for Configuration 2](results-for-configuration-2-(tp=4-pp=2).png) ### 4. Compare Performance Results Across Configurations Our 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.6245** | The TP=4 and PP=2 setup shows consistently better performance, and we should use it. --- ## Collateral # Collateral 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. ## Key Concepts - For the first 180 epochs (Grace Period), no collateral is required. All participants receive 100% of their potential weight unconditionally. - After the grace period, a portion of a participant's weight (default 20%) is granted unconditionally as Base Weight. - The remaining weight (default 80%) is Collateral-Eligible Weight and must be backed by deposited collateral. This ensures that participants with significant governance power also bear proportional economic responsibility. - The final Active Weight is the sum of Base Weight and the weight activated by collateral. Active Weight is used for all PoC-weighted governance decisions. Assume all `$NODE_URL` is URL of node with enabled chain rpc and chain api. ## Parameters ### Get Current Collateral Parameters (On-chain) ```bash curl "$NODE_URL/chain-api/productscience/inference/inference/params" | jq '.params.collateral_params' ``` - `slash_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. ## Compute collateral per weight 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` ```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" ``` For 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](#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`: ```bash curl -s "$NODE_URL/chain-api/productscience/inference/inference/params" \ | jq '.params.collateral_params.grace_period_end_epoch' ``` On mainnet the grace period has already ended, so collateral is required now. ## Recommended Buffer 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. ## Deposit Collateral 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. ### 1. Check current collateral Replace `` with the address you want to inspect (your own or someone else's). Via CLI: ```bash ./inferenced query collateral show-collateral \ --node $NODE_URL/chain-rpc/ ``` Or via API: ```bash curl "$NODE_URL/chain-api/productscience/inference/collateral/collateral/" ``` If no collateral has ever been deposited for this address, the response will be empty or return a not-found error — that is expected. ### 2. Deposit collateral Always use the `ngonka` denomination. The transaction is signed by the participant's **Account Key (cold key)**: ```bash ./inferenced tx collateral deposit-collateral ngonka \ --from gonka-account-key \ --keyring-backend file \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet ``` To compute a sensible `` for a given target weight, see [Compute collateral per weight](#compute-collateral-per-weight) above. For the recommended safety margin, see [Recommended Buffer](#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](#withdraw-collateral) section below). ### 3. Verify the deposit 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. ```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 ``` The 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. ## Withdraw Collateral 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): ```bash curl -s "$NODE_URL/chain-api/productscience/inference/collateral/params" | jq '.params.unbonding_period_epochs' ``` To withdraw collateral: ```bash ./inferenced tx collateral withdraw-collateral ngonka \ --from gonka-account-key \ --keyring-backend file \ --node $NODE_URL/chain-rpc/ \ --chain-id gonka-mainnet ``` To check unbonding collateral: ```bash ./inferenced query collateral show-unbonding-collateral \ --node $NODE_URL/chain-rpc/ ``` Or via API: ```bash curl "$NODE_URL/chain-api/productscience/inference/collateral/unbonding/" ``` ## Slashing Collateral can be slashed for two reasons: - **Invalid inference** - when a participant submits an invalid inference result. - **Downtime** - when a participant fails Confirmation PoC or is jailed. When a slash is triggered, the penalty is applied proportionally to both: - the participant's active collateral, and - any collateral currently in the unbonding queue. 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: ```bash curl "$NODE_URL/chain-api/cosmos/tx/v1beta1/txs?query=slash_collateral.participant=''" ``` To check if your collateral was slashed for Downtime: ``` curl "$NODE_URL/chain-rpc/block_search?query=\"slash_collateral.participant=''\"" curl "$NODE_URL/chain-rpc/block_results?height=" | jq '.result.finalize_block_events[] | select(.type == "slash_collateral")' ``` For automatic slashing events (e.g. jail) that occur during block processing (BeginBlock), use the block search RPC. First find the block where slashing occurred: ```bash curl "$NODE_URL/chain-rpc/block_search?query=\"slash_collateral.participant=''\"" ``` Then query the block results to see the slash details (replace `BLOCK_HEIGHT` with the height found above): ```bash curl "$NODE_URL/chain-rpc/block_results?height=" | jq '.result.finalize_block_events[] | select(.type == "slash_collateral")' ``` For common questions, see the [Collateral FAQ](https://gonka.ai/FAQ/#collateral). --- ## Gonka Genesis Ceremony # Gonka Genesis Ceremony 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. ## Overview The ceremony is a transparent and auditable process managed entirely through GitHub Pull Requests (PRs). The core workflow is straightforward: - Hosts (Validators) submit information and offline transaction files (`GENTX` and `GENPARTICIPANT`) via PRs - The Coordinator aggregates and verifies these inputs to publish the final, agreed `genesis.json` with a scheduled `genesis_time` and recorded hash. - Validators verify that the file is produced correctly and launch their nodes 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. > **** | Principle | Description | |-----------|-------------| | **Transparency and Auditability** | Using GitHub PRs for all submissions creates a public, verifiable record of the entire process from start to finish. | | **Decentralized Launch** | The ceremony ensures the network begins with an agreed-upon set of independent validators, establishing decentralization from block zero. | | **Verifiable State** | The final `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. | ## Prerequisites Before participating in the ceremony, each Host (validator) must: 1. Fork [the Gonka Repository](https://github.com/gonka-ai/gonka/) to your GitHub account. 2. Choose a Host (validator) name and create your validator directory: ```bash cp -r genesis/validators/template genesis/validators/ ``` This directory will be used for sharing information and transactions during the ceremony. 3. Follow the local setup portion of the Quickstart Guide. - Before the ceremony, you must complete the local machine setup as described in the [Gonka Quickstart](https://gonka.ai/host/quickstart) guide. This includes installing the `inferenced` CLI, creating your Account Cold Key, and pulling the Docker images. - Stop after pulling the images and do not launch the services; the ceremony process replaces the server-side setup and on-chain transactions with an offline, PR-based workflow. 4. Confirm readiness: - `inferenced` CLI is installed locally and your Account Cold Key is created. - Containers are pulled, models downloaded, and environment variables (`config.env`) are configured. ## Ceremony Process 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. - **Phase 1 [Validators]**: Prepare Keys and initial server setup; open PR with validator information (including node ID, ML operational address, and consensus pubkey) - **Phase 2 [Coordinator]**: Aggregate validator info and publish `genesis.json` draft for review - **Phase 3 [Validators]**: Generate offline `GENTX` and `GENPARTICIPANT` files from the draft; open PR with files - **Phase 4 [Coordinator]**: Verify and collect transactions, patch `genesis.json`, set `genesis_time` - **Phase 5 [Validators]**: Retrieve final `genesis.json`, verify hash, and launch nodes before `genesis_time` ### Deploy Scripts To simplify the process, the deploy scripts for the Ceremony will be in [/deploy/join](/deploy/join) directory of [the Gonka Repository](https://github.com/gonka-ai/gonka/). 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 stack - `GENESIS_SEEDS` — seed node address list used for initial P2P connectivity at launch - `IS_GENESIS` — toggle genesis-only paths (e.g., hash verification, bootstrap behavior) in compose/scripts Location: 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. ### Phase 1. [Validators]: Prepare Keys and Initial Server Setup 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. #### 1.1 [Local] Confirm Account Cold Key (from Quickstart) The Account Cold Key was created during `quickstart.md`. You can view its information with: ```bash ./inferenced keys list --keyring-backend file ``` **Example output:** ``` Enter keyring passphrase (attempt 1/3): - address: gonka1eq4f5p32ewkekf9rv5f0qjsa0xaepckmgl85kr name: "gonka-account-key" pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"A4U3G2eY46mwhWx7ZXieT+LetPJhG0jHNuVCQB6wgBZK"}' type: local ``` #### 1.2 [Server]: Initialize Node and Get Node ID ```bash docker compose run --rm node ``` **Example output:** ``` 51a9df752b60f565fe061a115b6494782447dc1f ``` #### 1.3 [Server]: Extract Consensus Public Key Start the `tmkms` service to generate the consensus key, then extract the public key. ```bash docker compose up -d tmkms && docker compose run --rm --entrypoint /bin/sh tmkms -c "tmkms-pubkey" ``` **Example output:** ``` /wTVavYr5OCiVssIT3Gc5nsfIH0lP1Rqn/zeQtq4CvQ= ``` #### 1.4 [Server]: Generate ML Operational 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: Note: `$KEY_NAME` and `$KEYRING_PASSWORD` are defined in Quickstart `config.env`. ```bash docker compose run --rm --no-deps -it api /bin/sh ``` Inside the container, create the ML operational key: ```bash printf '%s\n%s\n' "$KEYRING_PASSWORD" "$KEYRING_PASSWORD" | inferenced keys add "$KEY_NAME" --keyring-backend file ``` **Example output:** ``` ~ # printf '%s\n%s\n' "$KEYRING_PASSWORD" "$KEYRING_PASSWORD" | inferenced keys add "$KEY_NAME" --keyring-backend file - address: gonka1gyz2agg5yx49gy2z4qpsz9826t6s9xev6tkehw name: node-702105 pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"Ao8VPh5U5XQBcJ6qxAIwBbhF/3UPZEwzZ9H/qbIA6ipj"}' type: local **Important** write this mnemonic phrase in a safe place. It is the only way to recover your account if you ever forget your password. again plastic athlete arrow first measure danger drastic wolf coyote work memory already inmate sorry path tackle custom write result west tray rabbit jeans ``` #### 1.5 [Local]: Prepare PR with validator information Create or update `genesis/validators//README.md` with the following fields. Use values collected above and from Quickstart. ```markdown Account Public Key: Node ID: ML Operational Address: Consensus Public Key: P2P_EXTERNAL_ADDRESS: ``` #### 1.6 Create Pull Request Submit a PR to [the Gonka Repository](https://github.com/gonka-ai/gonka/) with your validator information. Include a clear title such as "Add validator: " and ensure all required fields are populated in your `README.md` file. ### Phase 2. [Coordinator]: Genesis Draft Preparation The coordinator will: - Review and merge all validator PRs from Phase 1 - Prepare the initial `genesis.json` draft, which includes all Account Addresses, and place it in `genesis/genesis-draft.json` - Announce the availability of the draft to all Hosts ### Phase 3. [Validators]: `GENTX` and `GENPARTICIPANT` Generation This phase involves generating the necessary transaction files for chain initialization. These transactions include: - `MsgCreateValidator` - Creates your validator on the chain - `MsgSubmitNewParticipant` - Registers your node as a network Host The `gentx` command requires the following variables from previous steps: | **Variable** | **Description** | |----------|-------------| | `` | Name of Account Cold Key in local registry (e.g., "gonka-account-key" from Quickstart) | | `` | The validator name chosen in the Prerequisites section | | `` | Address of ML Operational Key from step 1.4 | | `$PUBLIC_URL` | Environment variable with public URL from Quickstart's `config.env` | | `` | Consensus public key from step 1.3 | | `` | 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: ```bash cp ./genesis/genesis-draft.json ~/.inference/config/genesis.json ``` 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. #### [Local]: Create GENTX and GENPARTICIPANT Files 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. ```bash ./inferenced genesis gentx \ --keyring-backend file \ 1ngonka \ --moniker \ --pubkey \ --ml-operational-address \ --url $PUBLIC_URL \ --chain-id gonka-mainnet \ --node-id ``` **Example output:** ``` ./inferenced genesis gentx \ --home ./702121 \ --keyring-backend file \ 702121 1ngonka \ --pubkey eNrjtkSXzfE18jq3lqvpu/i1iIog9SN+kqR2Wsa6fSM= \ --ml-operational-address gonka13xplq68fws3uvs8m7ej2ed5ack9hzpc68fwvex \ --url http://36.189.234.237:19238 \ --moniker "mynode-702121" --chain-id gonka-mainnet \ --node-id 149d25924b9a6676448aea716864c31775645459 Enter keyring passphrase (attempt 1/3): Classic genesis transaction written to "702121/config/gentx/gentx-149d25924b9a6676448aea716864c31775645459.json" Genparticipant transaction written to "702121/config/genparticipant/genparticipant-149d25924b9a6676448aea716864c31775645459.json" ``` #### [Local]: Submit Generated Files Copy the generated files to your validator directory and create a PR: - Copy files to your validator directory: ```bash cp ~/.inference/config/gentx/gentx-.json genesis/validators// cp ~/.inference/config/genparticipant/genparticipant-.json genesis/validators// ``` - Create a PR with the following files: - `genesis/validators//gentx-.json` - `genesis/validators//genparticipant-.json` Use a clear PR title like "Add gentx files for validator: ". ### Phase 4. [Coordinator]: Final Genesis Preparation 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: 1. Collecting Genesis Transactions: The `collect-gentxs` command gathers all `gentx-.json` files, validates them, and incorporates them into `genesis.json` to populate the initial validator set. 2. Patching Participant Data: The `patch-genesis` command processes the `genparticipant-.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. #### 4.1 [Coordinator]: Collect Genesis Transactions ```bash ./inferenced genesis collect-gentxs --gentx-dir gentxs ``` #### 4.2 [Coordinator]: Process Participant Registrations ```bash ./inferenced genesis patch-genesis --genparticipant-dir genparticipants ``` #### 4.3 [Coordinator]: Configure Network Seeds The 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: `@,@,...` 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. ### Phase 5. [Validators]: Chain Launch 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. #### 5.1 [Server]: Update and Launch 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. ```bash git pull ``` - **Update 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. ```bash source config.env docker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull ``` - **Launch Your Validator** Finally, start all services. ```bash docker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d ``` #### 5.2 [Server]: Verify Launch Status After launching, monitor your node's logs to confirm it is waiting for the genesis time: ```bash docker compose logs node -f ``` Look for a message similar to this: ``` INF Genesis time is in the future. Sleeping until then... genTime=2025-08-14T09:13:39Z module=server ``` > **Important Notes** - The `api` container may restart several times before the `node` container is fully operational - Once the genesis time passes, you should see block production messages in the logs > **[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](https://gonka.ai/host/quickstart) or join [the community Discord](https://discord.com/invite/RADwCT2U6R). --- ## Hardware Specifications # Hardware Specifications 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 | --- ## How to edit Host public info # How to edit Host public info 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. ## Prerequisites - You must be the operator of the Host/Validator (you hold the operator key). - Your node must be running and connected to the network. - If you want a verified avatar, have an identity service (for example, [Keybase](https://keybase.io/)). ## Fields / Parameters 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](https://keybase.io/), 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. | ## Step-by-step guide Run the following command if you don’t have a PGP key yet. ``` keybase pgp gen ``` > **** `keybase 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 `No` Run the following command if you have an existing PGP key, import it into Keybase. ``` keybase pgp select ``` Open the Keybase app. Enter your real name, which will be publicly visible in explorer. Name 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. ### Update your node info 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 \ --chain-id="gonka-mainnet" \ --from \ --new-moniker \ --website \ --identity \ --keyring-backend file \ --node /chain-rpc/ \ --yes ``` Once 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 \ \ --node /chain-rpc/ ``` This should show the updated moniker, website, and identity. **Example output** ``` ... 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 ``` Wait 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. --- ## Key Management Architecture # Key Management Architecture This document describes the comprehensive key management architecture for Gonka Network, a decentralized AI infrastructure that requires robust security through role-based key separation. ## Overview 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](/host/quickstart/). This document focuses on understanding the complete key management architecture and security model. ## Key Architecture at Launch (v0) 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 | ## Security Model ### Account Key (Cold Wallet) - **CRITICAL** - Master key that grants permissions to all other keys - Must be stored offline on a secure, air-gapped machine - Only for granting permissions and validator registration - Protected by mnemonic phrase - **if lost, all access is permanently lost** ### ML Operational Key (Warm Wallet) - Authorized by Account Key for ML-specific transactions - Encrypted file on server, accessed programmatically - Automated transactions (inference requests, proof submissions, rewards) - Can be rotated/revoked by Account Key at any time ### Consensus Key (TMKMS - Warm Storage) - Managed by secure TMKMS service - Warm storage with double-signing prevention - Block validation and network consensus participation - Can be rotated by Account Key or authorized delegates ## Best Practices ### Security Guidelines 1. **Account Key Protection** - Secure local machine with encrypted storage and minimal internet exposure - *Secure local machine*: A dedicated computer with restricted access, not used for daily browsing/email, ideally air-gapped or with limited network connectivity - Use `file` or `os` keyring backend for secure local storage - Use strong, unique passphrases for keyring protection - Maintain offline backup of mnemonic phrase in secure location - Never use for routine operations - only for granting permissions and validator actions 2. **Hardware Wallet Support** - **Current Status**: Not supported at network launch - **Critical**: Always save and securely store your mnemonic phrase as your ultimate recovery method 3. **ML Operational Key Management** - Must use `file` keyring backend for server-based storage with programmatic access - Store encrypted on server with strong passphrase protection - Regularly rotate ML Operational Keys using Account Key authorization - Enable programmatic access by containers while maintaining encryption at rest 4. **Operational Security** - Implement proper backup and recovery procedures for all keys - Test key recovery procedures in safe environment before production deployment - Monitor and audit key usage patterns ### Recovery Procedures 1. **Account Key Loss**: **CRITICAL** - No recovery possible without mnemonic 2. **ML Operational Key Loss**: Create new key and re-authorize with Account Key 3. **Consensus Key Loss**: Rotate consensus key using Account Key authorization ## Multi-signature Groups (v1 Advanced) ``` Company Participant: ├── Account Key → Secure Storage + Multi-sig ├── ML Operational Key → Automated AI workloads ├── Governance Group → Multi-sig for protocol votes │ ├── CEO/Founder │ ├── CTO/Tech Lead │ └── Head of Operations └── Treasury Group (Optional) → Separate multi-sig for high-value transfers ├── CEO/Founder ├── CFO/Finance Lead └── Board Member ``` --- > **Production 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](https://gonka.ai/FAQ/), or join [Discord server](https://discord.com/invite/RADwCT2U6R) for assistance with general inquiries, technical issues, or security concerns. --- ## Kimi K2.6 Bootstrap # Kimi K2.6 Bootstrap `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](./quickstart.md). 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. 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`. ## Timeline #### 1. Before block `3873996`, all participants must submit: - `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` - `PoCDelegation` / `PoCRefusal` - if they are NOT going to deploy `Kimi-K2.6` #### 2. At block `3873996`, the chain runs pre-evaluation to check whether it should try to activate the model based on `PoCIntent` / `PoCDelegation` - 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) - If the model does not become pre-eligible => hosts who submitted `PoCIntent` should keep their nodes on `Qwen235B` #### 3. At block `3874496`, PoC starts ### Possible Scenarios The bootstrap of a new model can follow these main scenarios: 1. 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) - Everyone who submitted `PoCDelegation` / `PoCRefusal` keeps their full weight (no punishment) - Everyone who submitted nothing loses 15% of their weight => it is important to explicitly send a transaction with your intended behavior 2. 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) - Everyone who submitted `PoCDelegation` / `PoCRefusal` keeps their full weight (no punishment) - Everyone who submitted nothing loses 15% of their weight - Everyone who submitted `PoCIntent` and does not participate loses 15% of their weight If the model passes both checks, punishment follows the usual scenarios described in the documentation. ## Instructions for hosts who are going to deploy Kimi-K2.6 #### 1. Send `PoCIntent` to the chain: ``` export NODE=https://node3.gonka.ai/ ./inferenced tx inference declare-poc-intent moonshotai/Kimi-K2.6 \ --from node-2 \ --node "$NODE" \ --chain-id gonka-mainnet \ --keyring-backend file \ --gas auto \ --gas-adjustment 1.3 \ -y ``` #### 2. Check your setup and make sure the `Kimi-K2.6` weights are downloaded and you can deploy the model successfully 3. Wait for block `3873996`+ and check whether the model becomes pre-eligible: ```bash NODE=https://node3.gonka.ai MODEL='moonshotai/Kimi-K2.6' 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' ``` The results will be sent in all channels. #### 4. Switch the model to Kimi-K2.6 if needed Example command to deploy Kimi-K2.6 on 4xB200 / 8xB200: ``` curl -X POST http://localhost:9200/admin/v1/nodes \ -H "Content-Type: application/json" \ -d '{ "id": "", "host": "", "inference_port": 5050, "poc_port": 8080, "max_concurrent": 500, "models": { "moonshotai/Kimi-K2.6": { "args": [ "--tensor-parallel-size", "4", "--enable-expert-parallel", "--trust-remote-code", "--mm-encoder-tp-mode", "data", "--tool-call-parser", "kimi_k2", "--reasoning-parser", "kimi_k2", "--attention-backend", "FLASHINFER_MLA", "--disable-custom-all-reduce", "--gpu-memory-utilization", "0.95", "--max-num-seqs", "128", "--max-model-len", "240000" ] } } }' ``` #### 5. Validate your deployment The [`gonka` repo](https://github.com/gonka-ai/gonka) 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](./mlnode-validation.md) and [`skills/mlnode-validate/SKILL.md`](https://github.com/gonka-ai/gonka/blob/main/skills/mlnode-validate/SKILL.md). ## Instructions for hosts who are NOT going to deploy Kimi-K2.6 #### 1. Check if you trust any host who is going to deploy Kimi K2.6 / send `PoCIntent` Current intents: ```python import time import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry NODE = "https://node3.gonka.ai" MODEL = "moonshotai/Kimi-K2.6" 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_kimi_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_kimi_model.append((addr, w)) try: resp = get_json( s, f"{NODE}/chain-api/productscience/inference/inference/poc_delegation/{addr}", ) except requests.RequestException as e: skipped.append((addr, w, str(e))) time.sleep(DELAY) continue for i in resp.get("intents") or []: if i.get("model_id") == MODEL: intents.append((addr, w)) time.sleep(DELAY) total = 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_kimi_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. Send delegation or refusal Delegation: ``` export NODE=https://node3.gonka.ai/chain-rpc/ ./inferenced tx inference set-poc-delegation moonshotai/Kimi-K2.6 \ --from gonka-account-key \ --node "$NODE" \ --chain-id gonka-mainnet \ --keyring-backend file \ --gas auto \ --gas-adjustment 1.3 \ -y ``` Refusal: ``` export NODE=https://node3.gonka.ai/chain-rpc/ ./inferenced tx inference refuse-poc-delegation moonshotai/Kimi-K2.6 \ --from gonka-account-key \ --node "$NODE" \ --chain-id gonka-mainnet \ --keyring-backend file \ --gas auto \ --gas-adjustment 1.3 \ -y ``` --- ## MiniMax-M2.7 Bootstrap # MiniMax-M2.7 Bootstrap `MiniMaxAI/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](./quickstart.md). For the wider context of multi-model PoC mechanics, see [Multi-Model PoC](./multi_model_poc.md). The previous model bootstrap and its mechanics are documented in [Kimi K2.6 Bootstrap](./kimi-bootstrap.md). 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`. ## Timeline 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): ```bash curl -s "https://node3.gonka.ai/chain-api/productscience/inference/inference/params" \ | jq '.params.delegation_params.w_threshold' # {value, exponent} encodes a decimal: e.g. {"value":"1","exponent":-1} → 0.1 (10%). ``` To 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: ```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 becomes pre-eligible at the earliest epoch where participating hosts plus delegations cover the thresholds. ### Possible Scenarios The bootstrap of MiniMax-M2.7 can follow these main scenarios: 1. **MiniMax does not pass pre-evaluation in a given epoch's snapshot** (and remains not eligible at PoC): - Everyone who submitted `PoCIntent` keeps their full weight (no punishment) - Everyone who submitted `PoCDelegation` / `PoCRefusal` keeps their full weight (no punishment) - **Before epoch `278`**: everyone who submitted nothing also keeps their full weight (punishment is suppressed during the grace period) - **From epoch `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`** 2. **MiniMax passes pre-evaluation but does not become eligible at PoC** (e.g., an INTENT host fails to deploy in time): - Hosts that actually deployed MiniMax-M2.7 and submitted MiniMax PoC commits during this epoch keep their full weight from their existing model groups (no punishment) - Everyone who submitted `PoCDelegation` / `PoCRefusal` keeps their full weight (no punishment) - **From epoch `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](./multi_model_poc.md). ## Hardware eligibility 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](./quickstart.md#hardware-and-machines). Practical implications: - **A100 80GB owners**: MiniMax-M2.7 is the **first governance-approved model that fits the A100 80GB envelope**. If you previously could not host Kimi or Qwen-235B, you are now eligible to earn consensus weight via MiniMax. Recommended config: 8×A100 80GB with `tp=4` (two instances per host) or `tp=8` (one instance). - **H100 / H200 owners**: MiniMax-M2.7 is comparable to Qwen3-235B on consensus output (a few percent in either direction depending on workload mix) and clearly preferable to Kimi K2.6 after Kimi's coefficient adjustment in `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). - **B200 / B300 owners**: MiniMax-M2.7 runs well, but Kimi K2.6 retains a narrow consensus-output lead on flagship hardware. No change required if you already run Kimi. ## Instructions for hosts who are going to deploy MiniMax-M2.7 #### 1. Send `PoCIntent` to the chain ```bash 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. Pre-download the weights and verify deployability The MiniMax-M2.7 FP8 weights are **~230 GB**. Plan disk space and bandwidth accordingly. Follow the guide to [pre-download model weights](https://gonka.ai/host/quickstart/#server-pre-download-model-weights-to-hugging-face-cache-hf_home) using the repo and commit below: - `hf_repo`: `MiniMaxAI/MiniMax-M2.7` - `hf_commit`: `d494266a4affc0d2995ba1fa35c8481cbd84294b` Verify the model loads on your hardware before the bootstrap snapshot block. The chain registers MiniMax with `Model.ModelArgs`: ``` --enable-auto-tool-choice --max-model-len 180000 --kv-cache-dtype fp8 --tool-call-parser minimax_m2 --reasoning-parser minimax_m2_append_think ``` #### 3. Wait for the next evaluation epoch and check pre-eligibility After each evaluation epoch's snapshot block, the chain emits a `bootstrap_model_preeligibility` event: ```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' ``` The 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. #### 4. Switch the model to MiniMax-M2.7 if pre-eligible Example command to deploy MiniMax-M2.7 on 8×A100 80GB (`tp=4`, two instances per host): ```bash curl -X POST http://localhost:9200/admin/v1/nodes \ -H "Content-Type: application/json" \ -d '{ "id": "", "host": "", "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" ] } } }' ``` For 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. #### 5. Validate your deployment The [`gonka` repo](https://github.com/gonka-ai/gonka) 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](./mlnode-validation.md) and [`skills/mlnode-validate/SKILL.md`](https://github.com/gonka-ai/gonka/blob/main/skills/mlnode-validate/SKILL.md). ## Instructions for hosts who are NOT going to deploy MiniMax-M2.7 #### 1. Check if you trust any host who is going to deploy MiniMax / sent `PoCIntent` ```python 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: resp = get_json( s, f"{NODE}/chain-api/productscience/inference/inference/poc_delegation/{addr}", ) except requests.RequestException as e: skipped.append((addr, w, str(e))) time.sleep(DELAY) continue for i in resp.get("intents") or []: if i.get("model_id") == MODEL: intents.append((addr, w)) time.sleep(DELAY) total = 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. Send delegation or refusal Delegation: ```bash export NODE=https://node3.gonka.ai/chain-rpc/ ./inferenced tx inference set-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 ``` Refusal: ```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 ``` --- ## ML Node Management # ML Node Management This guide explains how to manage inference nodes (ML Nodes) connected to your Network Node using the **Admin API**. You will learn how to: - Add a new ML Node - Add multiple ML Nodes in a single batch - Update an existing ML Node - Enable or disable an ML Node - Delete an ML Node - List all configured ML Nodes 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. --- ## Prerequisites Before managing ML Nodes, make sure that: - You have completed the [Quickstart guide](https://gonka.ai/host/quickstart/) through **step 3.3** (key management and Host registration). - Your **Network Node** is running and reachable from the server where you execute the `curl` commands. - You have access to the **Admin API** on port `9200` of the Network Node server. Throughout this guide we assume you run commands **from the Network Node server** itself: ```bash export ADMIN_API_URL=http://localhost:9200 ``` If 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). --- ## ML Node Definition 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: ```json { "id": "node1", "host": "10.0.0.21", "inference_port": 5050, "poc_port": 8080, "max_concurrent": 500, "models": { "MiniMaxAI/MiniMax-M2.7": { "args": [ "--tensor-parallel-size", "4" ] } } } ``` > **Supported 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.](https://gonka.ai/host/benchmark-to-choose-optimal-deployment-config-for-llms/) --- ## Listing ML Nodes Use this endpoint to see all ML Nodes currently registered with your Network Node. **Endpoint** - `GET /admin/v1/nodes` **Example** ```bash curl -X GET "$ADMIN_API_URL/admin/v1/nodes" | jq ``` **Expected result** - Returns a JSON array containing all configured ML Nodes and their current configuration. --- ## Adding a New ML Node Use this operation to register a **single** new ML Node with your Network Node. **Endpoint** - `POST /admin/v1/nodes` > **Adding a MiniMax node on 4xH100** Example request for `MiniMaxAI/MiniMax-M2.7` on `4xH100`: ```bash curl -X POST "$ADMIN_API_URL/admin/v1/nodes" \ -H "Content-Type: application/json" \ -d '{ "id": "node-minimax", "host": "10.0.0.22", "inference_port": 5050, "poc_port": 8080, "max_concurrent": 500, "models": { "MiniMaxAI/MiniMax-M2.7": { "args": [ "--tensor-parallel-size", "4", "--max-model-len", "180000" ] } } }' ``` **Expected 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. --- ## Adding Multiple ML Nodes in a Batch 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/batch` **Example** ```bash curl -X POST "$ADMIN_API_URL/admin/v1/nodes/batch" \ -H "Content-Type: application/json" \ -d '[ { "id": "node1", "host": "10.0.0.21", "inference_port": 5050, "poc_port": 8080, "max_concurrent": 500, "models": { "MiniMaxAI/MiniMax-M2.7": { "args": [ "--tensor-parallel-size", "4", "--max-model-len", "180000" ] } } }, { "id": "node2", "host": "10.0.0.22", "inference_port": 5050, "poc_port": 8080, "max_concurrent": 500, "models": { "MiniMaxAI/MiniMax-M2.7": { "args": [ "--tensor-parallel-size", "4", "--max-model-len", "180000" ] } } } ]' ``` **Expected result** - If **all** nodes validate and register successfully: - Returns `201 Created` with an array of registered nodes. - If **some** nodes fail validation: - Returns `206 Partial Content` with `nodes` (successful ones) and an `errors` array describing failures. - If **all** nodes fail validation: - Returns `400 Bad Request` with details in the `errors` array. --- ## Updating an Existing ML Node Updating an ML Node is implemented as an **upsert**: - If the `id` already exists, the node is **updated**. - If the `id` does not exist, a **new** node is created. You can use **either**: - `POST /admin/v1/nodes` with an existing `id`, or - `PUT /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** ```bash curl -X PUT "$ADMIN_API_URL/admin/v1/nodes/node1" \ -H "Content-Type: application/json" \ -d '{ "id": "node1", "host": "http://10.0.0.21", "inference_port": 5050, "poc_port": 8080, "max_concurrent": 800, "models": { "MiniMaxAI/MiniMax-M2.7": { "args": [ "--tensor-parallel-size", "4", "--max-model-len", "180000" ] } } }' ``` **Expected result** - On success, returns `200 OK` with the updated node configuration. - If the node cannot be updated (for example, model not allowed by governance), returns `400 Bad Request` with an error message. --- ## Enabling an ML Node 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/enable` **Example** ```bash curl -X POST "$ADMIN_API_URL/admin/v1/nodes/node1/enable" ``` **Expected result** - On success, returns: ```json { "message": "node enabled successfully", "node_id": "node1" } ``` - If the node does not exist, returns `404 Not Found` with an error message. --- ## Disabling an ML Node 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/disable` **Example** ```bash curl -X POST "$ADMIN_API_URL/admin/v1/nodes/node1/disable" ``` **Expected result** - On success, returns: ```json { "message": "node disabled successfully", "node_id": "node1" } ``` - If the node does not exist, returns `404 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). --- ## Deleting an ML Node Use this endpoint to remove an ML Node configuration entirely from the Network Node. **Endpoint** - `DELETE /admin/v1/nodes/:id` **Example** ```bash curl -X DELETE "$ADMIN_API_URL/admin/v1/nodes/node1" ``` **Expected result** - On success, returns `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. --- ## Verifying Changes After any add/update/enable/disable/delete operation, you can verify the current state of all ML Nodes: ```bash curl -X GET "$ADMIN_API_URL/admin/v1/nodes" | jq ``` For end-to-end verification at the protocol level (after Proof-of-Compute), you can also check the current list of active participants: ```bash curl http://node2.gonka.ai:8000/v1/epochs/current/participants | jq ``` This 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. --- ## Validate ML Node Deployment # Validate ML Node Deployment The [`gonka` repo](https://github.com/gonka-ai/gonka) 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`](https://github.com/gonka-ai/gonka/blob/main/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. ## What the script does `validate.py` runs four phases against a running ML Node, printing `[i/4]` headers as it progresses: 1. **`[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. **`[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. **`[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/4] validate`** — `POST /api/v1/inference/pow/generate` with `wait=true`, `nonces=[...]`, `validation.artifacts=`, 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/_/`: - `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: `. ## Required inputs Per [SKILL.md → Required inputs](https://github.com/gonka-ai/gonka/blob/main/skills/mlnode-validate/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. ## Deploy config: from the caller, not the golden This is a load-bearing rule from [SKILL.md → Deploy config: from the caller, not the golden](https://github.com/gonka-ai/gonka/blob/main/skills/mlnode-validate/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--.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`: ```python import json, pathlib src = pathlib.Path('mlnode/packages/benchmarks/scripts/poc_validation/artifacts/.json') node_cfg = json.loads(pathlib.Path('deploy/join/node-config--.json').read_text()) d = json.loads(src.read_text()) d['additional_args'] = list(node_cfg[0]['models']['']['args']) d['source'] = f"vectors from {src.name}; additional_args from deploy/join/node-config--.json" dst = src.with_name(src.stem + '-.json') dst.write_text(json.dumps(d, indent=2)) ``` ```bash python3 mlnode/packages/benchmarks/scripts/poc_validation/validate.py \ --mlnode-url "$MLNODE_URL" --model "$MODEL" --reference ``` The 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. ## Available golden references Per [SKILL.md → Available golden references](https://github.com/gonka-ai/gonka/blob/main/skills/mlnode-validate/SKILL.md#available-golden-references), the repo ships these under `mlnode/packages/benchmarks/scripts/poc_validation/artifacts/`. The auto-lookup `.json` picks the default filename per model; variants beyond the default require an explicit `--reference `. 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](#deploy-config-from-the-caller-not-the-golden) above). | Model | Filename | Vectors | Recording context | |-------|----------|---------|-------------------| | `Qwen/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. ## Ready-made deploy configs in `deploy/join/` The repo ships `node-config-*.json` files matching common GPU classes for each approved model: - `deploy/join/node-config-qwen235B-B200.json` - `deploy/join/node-config-kimik26-B200.json` - `deploy/join/node-config-kimik26-H200.json` - `deploy/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.json` These configs are also reproduced inline in the [Host Quickstart](./quickstart.md). ## Pass criteria Per [SKILL.md → Pass criteria](https://github.com/gonka-ai/gonka/blob/main/skills/mlnode-validate/SKILL.md#pass-criteria): - **Clean PASS** — `validation.passed == true`, `validation.has_mismatches == false`, `n_mismatch == 0`, `fraud_detected == false`. - **PASS with mismatches within stat-test tolerance** — `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. - **FAIL** — `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.). ## When no artifact exists for the requested model `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](https://github.com/gonka-ai/gonka/blob/main/skills/mlnode-validate/SKILL.md#when-no-artifact-exists-for-the-requested-model). ## Related guides - [Host Quickstart](./quickstart.md) — initial deploy and `node-config.json` examples for every supported model and GPU class. - [ML Node Management](./mlnode-management.md) — adding / updating / enabling / disabling ML Nodes via the Admin API. - [Benchmark to Choose Optimal Deployment Config for LLMs](./benchmark-to-choose-optimal-deployment-config-for-llms.md) — performance tuning (TP / PP) via `compressa-perf`. - [Kimi K2.6 Bootstrap](./kimi-bootstrap.md) / [MiniMax-M2.7 Bootstrap](./minimax-bootstrap.md) — on-chain bootstrap timelines and `PoCIntent` / delegation transactions. --- ## Multi-Model PoC — Host Operations Guide # Multi-Model PoC — Host Operations Guide 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: - **Do not delegate to guardian nodes.** Guardians are the fallback mechanism for PoC validation. Concentrating delegations on them ties the primary voting mechanism and the fallback to the same hardware, so both fail together. Earlier guidance that suggested a guardian node as a delegation target is withdrawn. A protocol-level restriction is planned for v0.2.14. - **Avoid concentrating delegations on any single host.** A delegation only counts if the delegate submits a PoC store commit that epoch. If one heavily delegated host goes down, all weight delegated to it vanishes at once and the model group can lose its validation majority. If you operate several accounts, point them at different delegates. Percentage-based delegation to multiple hosts from one account is not supported yet. ## What changed in v0.2.12 and v0.2.13 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 ``` Look 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: - Lowering validation thresholds for new models would allow a small subset of the network to accumulate disproportionate influence. - Keeping the standard 2/3 threshold would make it very hard to activate new models, since a supermajority of hosts would need to deploy them first. Delegation solves this: - Hosts who do not run a model can still contribute their weight to validation - New models can bootstrap safely without forcing full network adoption - The network preserves its security guarantees while remaining flexible ## Governance model 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. ## Scope and prerequisites **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 ./inferenced tx inference --help ``` **Further reading (design and fees):** [multi-model PoC proposal README](https://github.com/gonka-ai/gonka/blob/67e205acc46da7cafe330e605b4b22e5d38f2dc7/proposals/multi-model-poc/README.md). --- ## What should I do? (quick decision guide) ``` 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) │ │ │ Never a guardian node; prefer a host that is │ │ │ not already a top delegation target │ │ │ │ └─ NO │ │ └─ Refuse delegation (~10% penalty) │ └─ If you do nothing └─ Risk highest penalty (~15%) ``` In most cases: - Delegation is the safest default if you are not running the model - Doing nothing is the worst option once penalties are enabled ## Recommended actions If you are not running a given model: - If you operate multiple nodes and at least one runs that model: delegate to your own node for that model - If you do not run that model at all: delegate to a host you trust. When picking one: - it must **not** be a guardian node; - it should have served that model **stably across recent epochs** (a delegation counts only if the delegate submits a PoC store commit that epoch); - it should have had **non-zero consensus weight in the previous epoch**; - prefer hosts that are **not already major delegation targets** — if `max_model_voting_power_percentage` is set, weight delegated above the cap is burned, and concentration makes the whole group fragile. - If you do not trust any delegate: use `refuse-poc-delegation` for that model Once `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. ## Your options (per model) > To get a list of all governance-approved `model_id` values, run: > ``` > ./inferenced query inference params --node "$NODE" -o json > ``` > Look inside `poc_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?](#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](#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](#bootstrap-pre-eligibility-events). | ### Strategy comparison | 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 weight - `no_participation_penalty`: ~15% (if quorum forms without you) - `delegation_share`: ~5% of your weight is transferred to the delegate These 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: - deploy the model - configure delegation - or explicitly refuse Check `penalty_start_epoch` in `params` for exact timing. --- ## What PoC delegation is 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. --- ## When your on-chain choices are frozen 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. ### Does your delegation actually count? `set-poc-delegation` can be sent anytime, but it only **helps** the delegate if **at validation start** all of the following hold: - the delegate **ran PoC** for that `model_id` in that epoch (has the corresponding work committed the usual way), and - the delegate had **non-zero consensus weight in the previous epoch**. Otherwise 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. ### Bootstrap pre-eligibility events 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: - If `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. - If only `meets_reachability` is false, verify your node is reachable before the next capture height. --- ## Copy-paste setup commands ### Session variables (set once in this shell) 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`. ```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)" # If keys show fails, set your address explicitly: # MY_ADDR="gonka1..." ``` Each `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. ### Parameters and epoch ```bash ./inferenced query inference params --node "$NODE" -o json ``` ```bash ./inferenced query inference get-current-epoch --node "$NODE" -o json ``` ### Query delegation state **All models:** ```bash ./inferenced query inference poc-delegation "$MY_ADDR" --node "$NODE" -o json ``` **One model** (second argument optional): ```bash ./inferenced query inference poc-delegation "$MY_ADDR" "$MODEL" --node "$NODE" -o json ``` The response lists **delegations**, **refusals**, and **intents** separately; for a given model you will have **at most one** of the three. --- ### Transactions **Delegate** (the delegate need not already be running that model's PoC when you send the tx): ```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 ``` **Clear delegation:** ```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 ``` **Refuse:** ```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 ``` **Bootstrap intent:** ```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 ``` --- ## Penalties and parameters Penalties 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). | Where in `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). --- ## Host checklist 1. Before the upgrade, clean your persisted MLNode config so it contains only supported models. 2. Prefer one logical model per ML node where possible. Misconfiguration is easier when several models exist on the same node. 3. After upgrade, confirm `params` lists every model you care about under `poc_params`. 4. Check each model’s `penalty_start_epoch`. 5. Check whether `refusal_penalty`, `no_participation_penalty`, and `delegation_share` are non-zero. 6. For each model, decide whether you want to run it, delegate, refuse, or do nothing. 7. If you run the model yourself, make sure your PoC stack submits valid PoC v2 store commits for that model. 8. If you delegate, verify the result with `poc-delegation`, and confirm the delegate actually committed PoC for that model in the current epoch. 9. For new models, watch `bootstrap_model_preeligibility` events and send `declare-poc-intent` before the capture height if you plan to participate. 10. After any config change, restart, or new host onboarding, make sure no unsupported models are present in the persisted DAPI configuration. 11. Never set a guardian node as your delegation target. 12. After any network incident, re-verify that your delegate is still serving the model; delegations are snapshotted at validation start and cannot be re-routed mid-epoch. --- ## Multiple nodes # Multiple nodes 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: - **Network node** – a service consisting of two nodes: a **chain node** and an **API node**. This service handles all communication. The **chain node** connects to the blockchain, while the **API node** manages user requests. - **Inference (ML) node** – a service that performs inference of large language models (LLMs) on GPU(s). You need at least one **ML node** to join the network. The guide provides instructions for deploying both services on the same machine as well as on different machines. Services are deployed as Docker containers. --- ## Prerequisites For the Network node, the approximate hardware requirements are: - 16 cores CPU (amd64) - 64+ GB RAM - 1TB NVMe SSD - 100Mbps minimum netowork connection (1Gbps preffered) The final requirements will depend on the number of MLNodes connected and their total throughput. Before proceeding, complete the [Quickstart guide](https://gonka.ai/host/quickstart/) through step 3.3, which includes: - Hardware and software requirements - Download deployment files - Container access authentication - Key management setup (Account Key and ML Operational Key) - Host registration and permissions --- ## Starting the network and inference node This section describes how to deploy a distributed setup with a network node and multiple inference nodes. 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://: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. ## Starting the network node Make sure you have completed the [Quickstart guide](https://gonka.ai/host/quickstart/) 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. ### Single-Machine Deployment: Network Node + Inference Node 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 && \ docker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d && \ docker compose -f docker-compose.yml -f docker-compose.mlnode.yml logs -f ``` This will start **one network node** and **one inference node** on the same machine. ### Separate Deployment: Network Node Only 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 && \ docker compose -f docker-compose.yml up -d && \ docker compose -f docker-compose.yml logs -f ``` ### The Network Node Status The 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): ```bash http://node2.gonka.ai:8000/v1/epochs/current/participants ``` If 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. ## Running the inference node on a separate server On the other servers, we run only the inference node, and for that, follow the instructions below. ### Step 1. Configure the Inference Node **1.1. Download Deployment Files** Clone the repository with the base deploy scripts: ``` git clone https://github.com/gonka-ai/gonka.git -b main ``` **1.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 ``` Create 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 ``` **1.3. Ports open for network node connections** ``` 5050 - Inference requests (mapped to 5000 of MLNode) 8080 - Management API Port (mapped to 8080 of MLNode) ``` > **Important** These ports must not be exposed to the public internet (they should be accessible only within the network node environment). ### Step 2. Launch the Inference Node 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 ``` This 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). ## Adding (Registering) Inference Nodes with the Network Node 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 \ -H "Content-Type: application/json" \ -d '{ "id": "", "host": "", "inference_port": , "poc_port": , "max_concurrent": , "models": { "": { "args": [ ] } } }' ``` **Parameter descriptions** | Parameter | Description | Examples | |-------------------|--------------------------------------------------------------------------------------------------|-----------------------------------------------------------| | `id` | 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://` | | `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 arguments | |-----------------------------------------|---------------------------------------------------------------------------------------| | `MiniMaxAI/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.](https://gonka.ai/host/benchmark-to-choose-optimal-deployment-config-for-llms/) If the node is successfully added, the response will return the **configuration** of the newly added inference node. ### Retrieving All Inference Nodes To get a list of **all registered inference nodes** in your network node, use: ```bash curl -X GET http://localhost:9200/admin/v1/nodes ``` This will return a JSON array containing all configured inference nodes. ### Removing an inference node Being connected to your **network node** server, use the following Admin API request to remove an inference node dynamically without restarting: ```bash curl -X DELETE "http://localhost:9200/admin/v1/nodes/{id}" -H "Content-Type: application/json" ``` Where `id` is the identifier of the inference node as specified in the request when registering the inference node. If successful, the response will be **true.** --- ## Network Node API # Network Node API This section describes the `Network Node API`, specifically the `/v1/epochs/{epoch_id}/participants` endpoint. This endpoint is used to retrieve: - Merkle proofs - Host data - Validator signatures ## Usage Current Epoch Data ```bash curl -X GET http:///v1/epochs/current/participants ``` Specific Epoch Data ```bash curl -X GET http:///v1/epochs//participants ``` --- ##Example response breakdown ```bash linenums="1" { "active_participants": { "participants": [ { "index": "gonka17tvsmufmewvwfy3dfxz7l20jmlhhn6ekfcun7r", "validator_key": "ljvRT9VScsxQKKX4S91yJRNppbz691ceD4sBYBRrAys=", "weight": 10, "inference_url": "http://genesis-api:8080", "models": [ "unsloth/llama-3-8b-Instruct" ], "seed": { "participant": "gonka17tvsmufmewvwfy3dfxz7l20jmlhhn6ekfcun7r", "block_height": 9, "signature": "6a2523cd5898539ef8ea765c7ab78f0de5dbcbb32a34b9706baa7294589f94d657422f573e7a4325d4ba8661466171c9621a51544478eb69f90a49b5271c1400" } } ], "epoch_group_id": 1, "poc_start_block_height": 9, "created_at_block_height": 15 }, "addresses": [ "BBDEDC12E4830D2086263415BE3FB4BF43C505A5" ], "active_participants_bytes": "0acc020a2d636f736d6f7331377476736d75666d657776776679336466787a376c32306a6d6c68686e36656b6663756e3772122c6c6a765254395653637378514b4b5834533931794a524e7070627a363931636544347342594252724179733d180a2217687474703a2f2f67656e657369732d6170693a383038302a1b756e736c6f74682f6c6c616d612d332d38622d496e73747275637432b4010a2d636f736d6f7331377476736d75666d657776776679336466787a376c32306a6d6c68686e36656b6663756e377210091a8001366132353233636435383938353339656638656137363563376162373866306465356462636262333261333462393730366261613732393435383966393464363537343232663537336537613433323564346261383636313436363137316339363231613531353434343738656236396639306134396235323731633134303010011809280f", "proof_ops": { "ops": [ { "type": "ics23:iavl", "key": "QWN0aXZlUGFydGljaXBhbnRzLzEvdmFsdWUv", "data": "CuMEChtBY3RpdmVQYXJ0aWNpcGFudHMvMS92YWx1ZS8S1QIKzAIKLWNvc21vczE3dHZzbXVmbWV3dndmeTNkZnh6N2wyMGptbGhobjZla2ZjdW43chIsbGp2UlQ5VlNjc3hRS0tYNFM5MXlKUk5wcGJ6NjkxY2VENHNCWUJSckF5cz0YCiIXaHR0cDovL2dlbmVzaXMtYXBpOjgwODAqG3Vuc2xvdGgvbGxhbWEtMy04Yi1JbnN0cnVjdDK0AQotY29zbW9zMTd0dnNtdWZtZXd2d2Z5M2RmeHo3bDIwam1saGhuNmVrZmN1bjdyEAkagAE2YTI1MjNjZDU4OTg1MzllZjhlYTc2NWM3YWI3OGYwZGU1ZGJjYmIzMmEzNGI5NzA2YmFhNzI5NDU4OWY5NGQ2NTc0MjJmNTczZTdhNDMyNWQ0YmE4NjYxNDY2MTcxYzk2MjFhNTE1NDQ0NzhlYjY5ZjkwYTQ5YjUyNzFjMTQwMBABGAkoDxoLCAEYASABKgMAAh4iKwgBEgQCBB4gGiEgwUNlynn4mzi4AC3u2itEeV3Y7Qe2vynK7Qqup2tmVgAiKwgBEgQECB4gGiEgiNVJ1Gl2VO0MezltgAUQs72vlGp3j3OWKH1OAD9MPHoiKwgBEgQGDB4gGiEgLyrwJqJ3jIIDD+gd8EO/3G8lNiCgkcpBn9IkqETCGbYiKwgBEgQIEh4gGiEgktjdW4rq4PGPx+En8SQnX7eIl6J5Qf4I9NEMMCokPa4iKwgBEgQKKB4gGiEg4Lo2jUStQ7FHrFhkm+Tk5df+rBHeeA6Ey5npZw+DEIk=" }, { "type": "ics23:simple", "key": "aW5mZXJlbmNl", "data": "CtoBCglpbmZlcmVuY2USIAeInJI1DSn8uBZz5z28V3JeXiQ7kPFDaCWqZeKu/1+ZGgkIARgBIAEqAQAiJwgBEgEBGiCkF0H31nsqBz1NVD3bG1444WqkoI982R1FXozDhDZvTyInCAESAQEaIJXhyLpHqjGG8RNH1IDYExUpZFPyxZvc7HLLmYEKxBeAIicIARIBARogVb5ZN4+aA5PlSPOrcbIeH/EuZ+nmQpJSod9LdNOb3WkiJQgBEiEBecxJ03qGQtj8qBYv4F3GTI9KLCix0WU+5PQNmJxXm7o=" } ] }, "validators": [ { "address": "BBDEDC12E4830D2086263415BE3FB4BF43C505A5", "pub_key": "ljvRT9VScsxQKKX4S91yJRNppbz691ceD4sBYBRrAys=", "voting_power": 1000000, "proposer_priority": 0 } ], "block": [ { "header": { "version": { "block": 11 }, "chain_id": "gonka-mainnet", "height": 15, "time": "2025-04-02T21:13:34.100375646Z", "last_block_id": { "hash": "306D1EBC3628F0571D5F772C85B554A8CD30C298648B4E325EC82945E7D20841", "parts": { "total": 1, "hash": "055C7DD9132B5133B7D422D423ED775BC4FF5E7E3C7447C4539B5573D67686DD" } }, "last_commit_hash": "04584765750C36899099C65023702382D718F5CF5E44581F675EAEDF4F15DE9E", "data_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "validators_hash": "BC21E09900AE1CBD50444061E0B1853550A509A3B8CE3B2BF5DA0C9DCC0351B0", "next_validators_hash": "BC21E09900AE1CBD50444061E0B1853550A509A3B8CE3B2BF5DA0C9DCC0351B0", "consensus_hash": "048091BC7DDC283F77BFBF91D73C44DA58C3DF8A9CBC867405D8B7F3DAADA22F", "app_hash": "6DAF9E22F6A30D441F5C40BF37ABD8A3B11A7582F5023413639C3015C6E47713", "last_results_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "evidence_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "proposer_address": "BBDEDC12E4830D2086263415BE3FB4BF43C505A5" }, "data": { "txs": null }, "evidence": { "evidence": null }, "last_commit": { "height": 14, "round": 0, "block_id": { "hash": "306D1EBC3628F0571D5F772C85B554A8CD30C298648B4E325EC82945E7D20841", "parts": { "total": 1, "hash": "055C7DD9132B5133B7D422D423ED775BC4FF5E7E3C7447C4539B5573D67686DD" } }, "signatures": [ { "block_id_flag": 2, "validator_address": "BBDEDC12E4830D2086263415BE3FB4BF43C505A5", "timestamp": "2025-04-02T21:13:34.100375646Z", "signature": "twGyWJvYr+jV1Hhfjio7p7lkDbg2+OrpUqI6Nmb3xHta0hKQyoky2S4U755x2YewLdG8t/1TlaqzurljQoXmDg==" } ] } } ] } ``` **`active_participants`** `participants`: List of active participants, including: - `index`: gonka address - `validator_key`: Public key (Base64) - `weight`: Voting weight - `inference_url`: Service endpoint - `models`: List of supported models - `seed`: Signature seed with metadata **`addresses`**: 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 address - `pub_key`: Public key (Base64) - `voting_power`: Current voting power - `proposer_priority`: Consensus proposer priority **`block`**: List of blocks surrounding the epoch event - Includes full block header metadata, proposer address, commit signatures, etc. - Useful for verifying the inclusion and commitment of Host data **Need help?** Find answers on [FAQ page](https://gonka.ai/FAQ/), or join [Discord server](https://discord.com/invite/RADwCT2U6R) for assistance with general inquiries, technical issues, or security concerns. --- ## [Optional] SSL Setup # [Optional] SSL Setup ## Use cases Hosts who want HTTPS for the public API, chain endpoints (RPC/REST/gRPC), and/or the Explorer. --- ## Choose your mode | `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. --- ## A) Setup using **Proxy SSL** (Automated) ### What you get - **Automatic issuance & renewal** of TLS certs (Let’s Encrypt via DNS‑01). - A **single entry‑point** nginx proxy that terminates TLS and routes to your services. - **Flip‑the‑switch** enablement with `docker compose` using the `ssl` profile. ### How it works (high level) 1. You run two containers: **`proxy`** (nginx) and **`proxy-ssl`** (ACME issuer). 2. On first start (or when a cert is missing), `proxy` asks `proxy-ssl` for a cert for `CERT_ISSUER_DOMAIN` (and allowed subdomains, if configured). 3. `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`). 4. `proxy` picks up the issued certs and serves HTTPS. Renewals repeat automatically. ### Requirements checklist (Proxy SSL) - DNS **A/AAAA** records for your domain point to the host where `proxy` runs. - **DNS API credentials** for one supported provider: Route53, Cloudflare, Google Cloud DNS, Azure, DigitalOcean, Hetzner. - A working compose stack including `proxy` and `proxy-ssl` (via the `ssl` profile). - Open inbound ports **8000/8443** on your firewall. ### Walkthrough — step by step (Proxy SSL) #### 0) Prepare directories (safe to re‑run) ```bash mkdir -p deploy/join/secrets/nginx-ssl deploy/join/secrets/certbot ``` #### 1) Configure `deploy/join/config.env` Minimal example for **HTTPS on 8443**: ```bash # Core proxy settings NGINX_MODE=both API_PORT=8000 # HTTP backend (used if you also keep 80 open) API_SSL_PORT=8443 # HTTPS backend # Automatic certificate issuance via proxy-ssl CERT_ISSUER_DOMAIN=your.domain CERT_ISSUER_ALLOWED_SUBDOMAINS=api,explorer,rpc # optional; comma-separated CERT_ISSUER_JWT_SECRET=change-me # any strong shared secret # ACME / Let's Encrypt account ACME_ACCOUNT_EMAIL=you@example.com ACME_DNS_PROVIDER=cloudflare # one of: route53|cloudflare|gcloud|azure|digitalocean|hetzner # DNS provider credential - see instructions how to abtain below ``` #### 2) DNS Credentials Cheat Sheet Use the credential(s) that match your provider. Click a provider to jump to the **how‑to** below. | Provider | Required env | |---|---| | [**Cloudflare**](#cloudflare-dns-token-how-to) | `CF_DNS_API_TOKEN` | | [**AWS Route53**](#aws-route53-credentials-how-to) | `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_REGION` | | [**Google Cloud DNS**](#google-cloud-dns-credentials-how-to) | `GCE_PROJECT`, `GCE_SERVICE_ACCOUNT_JSON_B64` | | [**Azure DNS**](#azure-dns-credentials-how-to) | `AZURE_CLIENT_ID`, `AZURE_CLIENT_SECRET`, `AZURE_TENANT_ID`, `AZURE_SUBSCRIPTION_ID` | | [**DigitalOcean DNS**](#digitalocean-dns-credentials-how-to) | `DO_AUTH_TOKEN` | | [**Hetzner DNS**](#hetzner-dns-credentials-how-to) | `HETZNER_API_KEY` | > **** **Cloudflare**{#cloudflare-dns-token-how-to} 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 Route53**{#aws-route53-credentials-how-to} **Option A — AWS CLI** ```bash HOSTED_ZONE_ID="Z123EXAMPLE" cat > route53-acme.json /dev/null || true aws iam attach-user-policy --user-name "$USER_NAME" --policy-arn "$POLICY_ARN" CREDS=$(aws iam create-access-key --user-name "$USER_NAME") AWS_ACCESS_KEY_ID=$(echo "$CREDS" | jq -r .AccessKey.AccessKeyId) AWS_SECRET_ACCESS_KEY=$(echo "$CREDS" | jq -r .AccessKey.SecretAccessKey) echo "AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID" echo "AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY" echo "AWS_REGION=" ``` **Option 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 DNS**{#google-cloud-dns-credentials-how-to} **Option A — gcloud CLI:** ```bash PROJECT_ID="" SA_NAME="acme-dns" SA_EMAIL="$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com" gcloud config set project "$PROJECT_ID" # 1) Service account gcloud iam service-accounts create "$SA_NAME" \ --display-name "ACME DNS for proxy-ssl" # 2) Role gcloud projects add-iam-policy-binding "$PROJECT_ID" \ --member "serviceAccount:$SA_EMAIL" \ --role "roles/dns.admin" # 3) Key → base64 (single line) gcloud iam service-accounts keys create key.json --iam-account "$SA_EMAIL" GCE_SERVICE_ACCOUNT_JSON_B64=$(base64 **** **Azure DNS**{#azure-dns-credentials-how-to} **Option A — Azure CLI** (quick) ```bash # 1) Login and choose subscription az login az account set --subscription "" # 2) Set where your DNS zone lives RG=">" ZONE=">" # e.g., gonka.ai SP_NAME="gonka-acme-$(date +%s)" SUBSCRIPTION_ID=$(az account show --query id -o tsv) SCOPE="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RG/providers/Microsoft.Network/dnszones/$ZONE" CREDS=$(az ad sp create-for-rbac \ --name "$SP_NAME" \ --role "DNS Zone Contributor" \ --scopes "$SCOPE" \ --only-show-errors) # 4) Extract values AZURE_CLIENT_ID=$(echo "$CREDS" | jq -r .appId) AZURE_CLIENT_SECRET=$(echo "$CREDS" | jq -r .password) AZURE_TENANT_ID=$(echo "$CREDS" | jq -r .tenant) # 5) Print for your env file echo "AZURE_CLIENT_ID=$AZURE_CLIENT_ID" echo "AZURE_CLIENT_SECRET=$AZURE_CLIENT_SECRET" echo "AZURE_SUBSCRIPTION_ID=$SUBSCRIPTION_ID" echo "AZURE_TENANT_ID=$AZURE_TENANT_ID" ``` **Option B — Portal** 1) 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 DNS**{#digitalocean-dns-credentials-how-to} 1) Open DigitalOcean Control Panel. 2) Go to API → Tokens. 3) Generate a write‑scoped token and set `DO_AUTH_TOKEN`. > **** **Hetzner DNS**{#hetzner-dns-credentials-how-to} 1) Open https://dns.hetzner.com. 2) Go to API Tokens. 3) Create a new token and set `HETZNER_API_KEY`. #### 3) Start (or enable) SSL components From `deploy/join`: ```bash # Enable / upgrade only the proxy pieces source ./config.env && \ docker compose --profile "ssl" \ -f docker-compose.yml -f docker-compose.mlnode.yml \ pull proxy proxy-ssl && \ docker compose --profile "ssl" \ -f docker-compose.yml -f docker-compose.mlnode.yml \ up -d proxy proxy-ssl ``` Only `proxy` and `proxy-ssl` need to be (re)started for SSL changes. Other services can remain running. #### 4) Verify - Confirm DNS records for your domain point to the proxy host. - Tail logs for SSL activity (issuance/renewal): ```bash docker compose logs -n 200 proxy proxy-ssl ``` - Probe health: ```bash curl -I https://your.domain:8443/health # Expect: HTTP/2 200 OK ``` #### 5) Renewal & when you must act **Automatic:** - Certificate renewals (issuer reuses `./secrets/nginx-ssl`). - Nginx picks up renewed certs on container restart. **You act when:** - Rotating **DNS credentials** → update env & restart `proxy-ssl`. - Changing `CERT_ISSUER_DOMAIN` or subdomains → update env, ensure DNS records exist, then restart `proxy` and `proxy-ssl`. - Moving hosts/IPs → update DNS to point to the new proxy **before** issuing/renewing. Commands to apply env changes: ```bash source ./config.env && \ docker compose --profile "ssl" -f docker-compose.yml -f docker-compose.mlnode.yml up -d proxy proxy-ssl ``` --- ## B) Setup using **Manual SSL** (BYO certificates) ### How it works (high level) - You issue certificates yourself (e.g., Dockerized Certbot using DNS‑01) and place them under `./secrets/nginx-ssl/`. - The `proxy` (nginx) container serves TLS using cert/key files read from `SSL_CERT_SOURCE`. ### Requirements checklist (Manual SSL) - Certificates will be issued **manually** (Let’s Encrypt via Certbot, or other CA). - Place **`cert.pem`** (fullchain) and **`private.key`** (mode `0600`) under `deploy/join/secrets/nginx-ssl/`. - Set `NGINX_MODE` to `both` (recommended for migration) or `https`. - Set `SERVER_NAME` to your **full domain name** and `API_SSL_PORT` to your HTTPS port (default **8443** in our stack). - Set `SSL_CERT_SOURCE=./secrets/nginx-ssl`. - **Do not** set `CERT_ISSUER_DOMAIN` (that is only for the automated Proxy SSL mode). ### Walkthrough — step by step (Manual SSL) #### 0) Prepare directories ```bash mkdir -p secrets/nginx-ssl secrets/certbot ``` #### 1) Generate certs (Dockerized Certbot; DNS‑01) ```bash DOMAIN= ACCOUNT_EMAIL= # renewal notices mkdir -p secrets/nginx-ssl secrets/certbot docker run --rm -it \ -v "$(pwd)/secrets/certbot:/etc/letsencrypt" \ -v "$(pwd)/secrets/nginx-ssl:/mnt/nginx-ssl" \ certbot/certbot certonly --manual --preferred-challenges dns \ -d "$DOMAIN" --email "$ACCOUNT_EMAIL" --agree-tos --no-eff-email \ --deploy-hook 'install -m 0644 "$RENEWED_LINEAGE/fullchain.pem" /mnt/nginx-ssl/cert.pem; \ install -m 0600 "$RENEWED_LINEAGE/privkey.pem" /mnt/nginx-ssl/private.key' ``` > 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/`. #### 2) Edit `deploy/join/config.env` ```bash export NGINX_MODE="both" # or https export API_SSL_PORT="8443" # HTTPS port served by proxy export SERVER_NAME="${DOMAIN}" # full domain name export SSL_CERT_SOURCE="./secrets/nginx-ssl" # IMPORTANT: do NOT set CERT_ISSUER_DOMAIN in Manual mode ``` #### 3) Update & restart only the proxy ```bash source config.env && \ docker compose -f docker-compose.mlnode.yml -f docker-compose.yml pull proxy && \ docker compose -f docker-compose.mlnode.yml -f docker-compose.yml up -d --no-deps proxy ``` #### 4) Verify HTTPS ```bash curl -I https://:8443/health # Expect: HTTP/2 200 OK ``` --- ## Proposals # Proposals In Gonka, there are two main ways to propose and coordinate changes: Governance and Improvement Proposals. ## Improvement Proposals (off-chain) Used to discuss long-term plans, major architectural ideas, and shape the community roadmap. They are similar to Bitcoin’s [BIPs](https://github.com/bitcoin/bips). - Managed as Markdown files in the [/proposals](https://github.com/gonka-ai/gonka/tree/main/proposals) directory - Anyone can create a Pull Request with a new proposal - Active participants review proposals on GitHub - If approved, the PR gets merged into the repository For off-chain improvement proposals, see the [/proposals](https://github.com/gonka-ai/gonka/tree/main/proposals) folder. ## Governance Proposals (on-chain) Used for changes that directly affect the network and require on-chain voting: - Changing network parameters (e.g. via `MsgUpdateParams`) - Executing software upgrades - Introducing new models - Introducing new features - Any other modifications that must be approved by the community on-chain 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](https://gonka.ai/tokenomics.pdf). > **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. ### Key governance parameters | **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: ```bash inferenced query gov params -o json --node /chain-rpc/ \ | jq '.params | { min_deposit, expedited_min_deposit, voting_period, expedited_voting_period, quorum, threshold, expedited_threshold, veto_threshold, burn_vote_veto }' ``` For on-chain governance steps and full tally formulas, see [the detailed guide](https://gonka.ai/governance/transactions-and-governance/) and [Voting on Proposals](https://gonka.ai/governance/voting-on-proposals/). --- ## Setting up your chain # Setting up your chain **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: - **Network Node** – a service consisting of two nodes: a **Chain Node** and an **API Node**. This service handles all communication. The **Chain Node** connects to the blockchain, while the **API Node** manages user requests. - **Inference (ML) node** – a service that performs inference of large language models (LLMs) on GPU(s). You need at least one **ML Node** to join the network. 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. > **** 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. ## Prerequisites 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. ### Supported models 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 | Role | |----------|------| | `MiniMaxAI/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"`: ```bash curl -sS http://node2.gonka.ai:8000/v1/governance/models ``` To list only model ids, pipe the response: `jq -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: - **Kimi K2.6** — `deploy/join/node-config-kimik26-H200.json`, `deploy/join/node-config-kimik26-B200.json` - **MiniMax M2.7** — `deploy/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.json` The 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](#33-local-machine-grant-permissions-to-ml-operational-key), **after** registration and verification. Copy-paste commands are at the end: [Optional: PoC delegation and refusal](#optional-poc-delegation-and-refusal). For strategy and penalties, read [Multi-Model PoC — Host Operations Guide](./multi_model_poc.md). > **Governance and model classification** - Models may be classified into a category if approved by governance. - Decisions about adding or changing supported models are made by governance. - For details on governance procedures and how to propose new models, see the [Transactions and Governance Guide](https://gonka.ai/governance/transactions-and-governance/). ### Proposed Hardware Configuration To run a valid node, you need machines with [supported GPU(s)](/host/hardware-specifications/). Below is a reference layout: | **Model Name** | **ML Nodes (min)** | **Example Hardware** | **Minimum VRAM per ML Node** | |------------------------------------------|-------------------|-------------------------------------------------|----------------| | `moonshotai/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](./multi_model_poc.md). Example vLLM arguments for B200-class hosts are in [Kimi K2.6 Bootstrap](./kimi-bootstrap.md) and in the `node-config.json` examples below. More details about the optimal deployment configuration can be found [here](https://gonka.ai/host/benchmark-to-choose-optimal-deployment-config-for-llms/). The server hosting the Network Node should have: - 16-core CPU (amd64) - 64+ GB RAM - 1TB NVMe SSD - 100Mbps minimum network connection (1Gbps preferred) 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: - at least 1.5x RAM of GPU VRAM - a 16-core CPU (Network Node and ML Node can be deployed on the same server). - NVIDIA Container Toolkit installed and configured, with a CUDA Toolkit version between 12.6 and 12.9. You can check the version with `nvidia-smi`. ### Network access, proxy, and ports (IMPORTANT) 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: - 5000 - Tendermint P2P communication - 8000 / 8443 - Application service via proxy only > **WARNING: Internal ports** The following ports are internal-only and MUST NOT be publicly accessible: - 26657 - Tendermint RPC - 9100, 9200 — Network Node internal API - 5050 — ML Node / vLLM inference API - 8080 — ML Node API 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:** - Allow access to these ports only from localhost, a private network or whitelisting - Never expose them publicly - Docker defaults are NOT secure > **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. ```bash title="API Manual Routes Control" # Defines which routes bypass rate limits (Exempt) vs those completely disabled (Blocked) - GONKA_API_EXEMPT_ROUTES=chat inference - GONKA_API_BLOCKED_ROUTES=poc-batches training ``` ```bash title="Chain Routes Disabling" # Disables public access to Chain services by default - DISABLE_CHAIN_API=${DISABLE_CHAIN_API:-true} - DISABLE_CHAIN_RPC=${DISABLE_CHAIN_RPC:-true} - DISABLE_CHAIN_GRPC=${DISABLE_CHAIN_GRPC:-true} ``` The 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 machine" Bind 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: ports: - "127.0.0.1:9100:9100" - "127.0.0.1:9200:9200" ``` **ML Node (`docker-compose.mlnode.yml`)** ``` ports: - "127.0.0.1:${PORT:-8080}:8080" - "127.0.0.1:${INFERENCE_PORT:-5050}:5000" ``` Do NOT use: - "9100:9100" - "9200:9200" - "5050:5000" - "8080:8080" === "CASE 2: ML Node and Network Node on DIFFERENT machines" 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: - ML Node APIs - `DAPI_API__POC_CALLBACK_URL` If 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. ## Setup Your Nodes The quickstart instructions are designed to run both the Network Node and the inference node on a single machine (one server setup). > **** If you are deploying multiple GPU nodes, please refer to the detailed [Multiple nodes deployment guide](https://gonka.ai/host/multiple-nodes/) 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. ### Key Management Overview Before configuring your Network Node, you need to set up cryptographic keys for secure operations. **It is recommended to read the [Key Management Guide](/host/key-management/) before launching a production node.** We use a three-key system: - **Account Key** (Cold Wallet) - Created on your local secure machine for high-stakes operations - **Consensus Key** (TMKMS - Warm Storage) - Managed by secure TMKMS service and used for block validation and network consensus participation - **ML Operational Key** (Warm Wallet) - Created on the server for automated AI workload transactions ### [Local machine] Install the CLI Tool 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.zip` - `inferenced-darwin-arm64.zip` - `inferenced-linux-amd64.zip` - `inferenced-linux-arm64.zip` Do 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](https://github.com/gonka-ai/gonka/releases/tag/release/v0.2.9) or [newer](https://github.com/gonka-ai/gonka/releases). 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** ```bash chmod +x inferenced ./inferenced --help ``` > **macOS 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. ### [Local machine] Create Account Key **IMPORTANT: Perform this step on a secure, local machine (not your server)** > **** The Account Key is your primary, high-privilege key. It is created locally and never stored on your servers. - Master key that grants permissions to all other keys - Must be stored offline on a secure, air-gapped machine - Only for granting permissions and validator registration - Protected by mnemonic phrase - if lost, all access is permanently lost Create your Account Key using the `file` keyring backend (you can also use `os` for enhanced security on supported systems): ```bash ./inferenced keys add gonka-account-key --keyring-backend file ``` CLI will ask you for passphrase and show data about created key-pair. ``` ❯ ./inferenced keys add gonka-account-key --keyring-backend file Enter keyring passphrase (attempt 1/3): Re-enter keyring passphrase: - address: gonka1rk52j24xj9ej87jas4zqpvjuhrgpnd7h3feqmm name: gonka-account-key pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"Au+a3CpMj6nqFV6d0tUlVajCTkOP3cxKnps+1/lMv5zY"}' type: local **Important** write this mnemonic phrase in a safe place. It is the only way to recover your account if you ever forget your password. pyramid sweet dumb critic lamp various remove token talent drink announce tiny lab follow blind awful expire wasp flavor very pair tell next cable ``` **CRITICAL**: 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. ### [Server] Download Deployment Files Clone the repository with the base deploy scripts: ```bash git clone https://github.com/gonka-ai/gonka.git -b main && \ cd gonka/deploy/join ``` And copy `config` file template: ``` cp config.env.template config.env ``` After cloning the repository, you’ll find the following key configuration files: | File | Description | |-------------------------------|----------------------------------------------------------------------------------| | `config.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 | ### [Server] Setup Environment Variables > **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: 1. Obtain a domain name and configure DNS to point to your server's IP address 2. Press the **"Reset"** button above and select **"Yes"** when asked about having a domain name 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 Reset If your node cannot connect to the default seed node, [see the FAQ for details.](https://gonka.ai/FAQ/#my-node-cannot-connect-to-the-default-seed-node-specified-in-the-configenv) ### [Server] Edit Environment Variables Which variables to edit: All other variables can be left as is. **How to get variables from domain providers:** > **** 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`. > **** **Option A — AWS CLI** ```bash HOSTED_ZONE_ID="Z123EXAMPLE" cat > route53-acme.json /dev/null || true aws iam attach-user-policy --user-name "$USER_NAME" --policy-arn "$POLICY_ARN" CREDS=$(aws iam create-access-key --user-name "$USER_NAME") AWS_ACCESS_KEY_ID=$(echo "$CREDS" | jq -r .AccessKey.AccessKeyId) AWS_SECRET_ACCESS_KEY=$(echo "$CREDS" | jq -r .AccessKey.SecretAccessKey) echo "AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID" echo "AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY" echo "AWS_REGION=" ``` **Option 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:** ```bash PROJECT_ID="" SA_NAME="acme-dns" SA_EMAIL="$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com" gcloud config set project "$PROJECT_ID" # 1) Service account gcloud iam service-accounts create "$SA_NAME" \ --display-name "ACME DNS for proxy-ssl" # 2) Role gcloud projects add-iam-policy-binding "$PROJECT_ID" \ --member "serviceAccount:$SA_EMAIL" \ --role "roles/dns.admin" # 3) Key → base64 (single line) gcloud iam service-accounts keys create key.json --iam-account "$SA_EMAIL" GCE_SERVICE_ACCOUNT_JSON_B64=$(base64 > **** **Option A — Azure CLI** (quick) ```bash # 1) Login and choose subscription az login az account set --subscription "" # 2) Set where your DNS zone lives RG=">" ZONE=">" # e.g., gonka.ai SP_NAME="gonka-acme-$(date +%s)" SUBSCRIPTION_ID=$(az account show --query id -o tsv) SCOPE="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RG/providers/Microsoft.Network/dnszones/$ZONE" CREDS=$(az ad sp create-for-rbac \ --name "$SP_NAME" \ --role "DNS Zone Contributor" \ --scopes "$SCOPE" \ --only-show-errors) # 4) Extract values AZURE_CLIENT_ID=$(echo "$CREDS" | jq -r .appId) AZURE_CLIENT_SECRET=$(echo "$CREDS" | jq -r .password) AZURE_TENANT_ID=$(echo "$CREDS" | jq -r .tenant) # 5) Print for your env file echo "AZURE_CLIENT_ID=$AZURE_CLIENT_ID" echo "AZURE_CLIENT_SECRET=$AZURE_CLIENT_SECRET" echo "AZURE_SUBSCRIPTION_ID=$SUBSCRIPTION_ID" echo "AZURE_TENANT_ID=$AZURE_TENANT_ID" ``` **Option B — Portal** 1) 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. > **** 1) 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:** ```bash source config.env ``` > **Using 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. ### [Server] Edit Inference Node Description for the Server 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](https://gonka.ai/governance/transactions-and-governance/). === "Kimi — 4×B200 / 8×B200 (and 8×H200 reference class)" 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`. !!! note "edit node-config.json" ``` [ { "id": "node1", "host": "inference", "inference_port": 5000, "poc_port": 8080, "max_concurrent": 500, "models": { "moonshotai/Kimi-K2.6": { "args": [ "--tensor-parallel-size", "4", "--enable-expert-parallel", "--trust-remote-code", "--mm-encoder-tp-mode", "data", "--tool-call-parser", "kimi_k2", "--reasoning-parser", "kimi_k2", "--attention-backend", "FLASHINFER_MLA", "--disable-custom-all-reduce", "--gpu-memory-utilization", "0.95", "--max-num-seqs", "128", "--max-model-len", "240000" ] } } } ] ``` The same `"models"` block is used when registering or updating a node via the API; see [Kimi K2.6 Bootstrap](./kimi-bootstrap.md) for an equivalent `curl` example. === "Kimi — 8×H200" 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. !!! note "edit node-config.json" ``` [ { "id": "node1", "host": "inference", "inference_port": 5000, "poc_port": 8080, "max_concurrent": 500, "models": { "moonshotai/Kimi-K2.6": { "args": [ "--tensor-parallel-size", "8", "--enable-expert-parallel", "--trust-remote-code", "--mm-encoder-tp-mode", "data", "--tool-call-parser", "kimi_k2", "--reasoning-parser", "kimi_k2", "--attention-backend", "FLASHMLA", "--gpu-memory-utilization", "0.90", "--max-model-len", "240000" ] } } } ] ``` === "MiniMax — 4×A100" Use 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`. !!! note "edit node-config.json" ``` [ { "id": "node1", "host": "inference", "inference_port": 5000, "poc_port": 8080, "max_concurrent": 500, "models": { "MiniMaxAI/MiniMax-M2.7": { "args": [ "--moe-backend", "marlin", "--tensor-parallel-size", "4", "--gpu-memory-utilization", "0.95", "--max-num-seqs", "128", "--enable-auto-tool-choice", "--max-model-len", "180000", "--kv-cache-dtype", "fp8", "--tool-call-parser", "minimax_m2", "--reasoning-parser", "minimax_m2_append_think" ] } } } ] ``` === "MiniMax — 4×H100" Use 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`. !!! note "edit node-config.json" ``` [ { "id": "node1", "host": "inference", "inference_port": 5000, "poc_port": 8080, "max_concurrent": 500, "models": { "MiniMaxAI/MiniMax-M2.7": { "args": [ "--tensor-parallel-size", "4", "--attention-backend", "FLASHINFER", "--gpu-memory-utilization", "0.92", "--max-num-seqs", "128", "--enable-auto-tool-choice", "--max-model-len", "180000", "--kv-cache-dtype", "fp8", "--tool-call-parser", "minimax_m2", "--reasoning-parser", "minimax_m2_append_think" ] } } } ] ``` === "MiniMax — 2×H200" Use 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`. !!! note "edit node-config.json" ``` [ { "id": "node1", "host": "inference", "inference_port": 5000, "poc_port": 8080, "max_concurrent": 500, "models": { "MiniMaxAI/MiniMax-M2.7": { "args": [ "--tensor-parallel-size", "2", "--attention-backend", "FLASHINFER", "--gpu-memory-utilization", "0.92", "--max-num-seqs", "128", "--enable-auto-tool-choice", "--max-model-len", "180000", "--kv-cache-dtype", "fp8", "--tool-call-parser", "minimax_m2", "--reasoning-parser", "minimax_m2_append_think" ] } } } ] ``` === "MiniMax — 2×B200" Use 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`. !!! note "edit node-config.json" ``` [ { "id": "node1", "host": "inference", "inference_port": 5000, "poc_port": 8080, "max_concurrent": 500, "models": { "MiniMaxAI/MiniMax-M2.7": { "args": [ "--tensor-parallel-size", "2", "--moe-backend", "FLASHINFER_TRTLLM", "--gpu-memory-utilization", "0.92", "--max-num-seqs", "128", "--enable-auto-tool-choice", "--max-model-len", "180000", "--kv-cache-dtype", "fp8", "--tool-call-parser", "minimax_m2", "--reasoning-parser", "minimax_m2_append_think" ] } } } ] ``` For more details on the optimal deployment configuration, please refer to [this link](https://gonka.ai/host/benchmark-to-choose-optimal-deployment-config-for-llms/). > **Validate the deployment** The [`gonka` repo](https://github.com/gonka-ai/gonka) 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](./mlnode-validation.md). ### [Server] Pre-download Model Weights to Hugging Face Cache (HF_HOME) 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.6" ```bash mkdir -p $HF_HOME huggingface-cli download moonshotai/Kimi-K2.6 ``` Model license: see [Model licenses](../model-licenses.md). For operational notes and on-chain options (intent, delegation), see [Kimi K2.6 Bootstrap](./kimi-bootstrap.md). === "MiniMax M2.7" ```bash mkdir -p $HF_HOME huggingface-cli download MiniMaxAI/MiniMax-M2.7 ``` Model license: see [Model licenses](../model-licenses.md). 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). ## Launch Nodes ### 1. [Server] Pull Docker Images (Containers) Make sure you are in the `gonka/deploy/join` folder before running the next commands. ```bash docker compose -f docker-compose.yml -f docker-compose.mlnode.yml pull ``` ### 2. [Server] Start Initial Services Start the essential services needed for key setup (excluding the API service): ```bash source config.env && \ docker compose up tmkms node -d --no-deps ``` We start these specific containers first because: - **`tmkms`** - Generates and securely manages the Consensus Key needed for validator registration - **`node`** - 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 step > **Recommendation** You can check logs to verify that the initial services started successfully: ```bash docker compose logs tmkms node -f ``` If you see the Chain Node continuously processing block events, then the setup is working correctly. > **** - Managed by secure TMKMS service - Warm storage with double-signing prevention - Block validation and network consensus participation - Can be rotated by Account Key or authorized delegates During the registration command on [step 3.2.](https://gonka.ai/host/quickstart/#32-server-register-host) (`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](https://gonka.ai/FAQ/#i-cleared-or-overwrote-my-consensus-key)” on the FAQ page). ### 3. Complete Key Setup and Host Registration Now we need to complete the key management setup by creating the warm key, registering the Host, and granting permissions: #### 3.1. [Server] Create ML Operational Key > **** - Authorized by Account Key for ML-specific transactions - Encrypted file on server, accessed programmatically - Automated transactions (inference requests, proof submissions, rewards) - Can be rotated/revoked by Account Key at any time - Needs constant availability, so do not remove or rotate it unless necessary. 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: ```bash docker compose run --rm --no-deps -it api /bin/sh ``` Inside the container, create the ML operational key: ```bash printf '%s\n%s\n' "$KEYRING_PASSWORD" "$KEYRING_PASSWORD" | inferenced keys add "$KEY_NAME" --keyring-backend file ``` > **Important** Do not run this command twice. The ML Operational Key (Warm Key) is generated once per server and must be preserved across restarts. - If you accidentally deleted it or reinitialized, follow the recovery instructions in the FAQ: “[I Deleted the Warm Key](https://gonka.ai/FAQ/#i-deleted-the-warm-key)”. - When restarting your node, skip this step entirely — the key is already generated and stored persistently inside the API container. **Example output:** ``` ~ # printf '%s\n%s\n' "$KEYRING_PASSWORD" "$KEYRING_PASSWORD" | inferenced keys add "$KEY_NAME" --keyring-backend file - address: gonka1gyz2agg5yx49gy2z4qpsz9826t6s9xev6tkehw name: node-702105 pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"Ao8VPh5U5XQBcJ6qxAIwBbhF/3UPZEwzZ9H/qbIA6ipj"}' type: local **Important** write this mnemonic phrase in a safe place. It is the only way to recover your account if you ever forget your password. again plastic athlete arrow first measure danger drastic wolf coyote work memory already inmate sorry path tackle custom write result west tray rabbit jeans ``` #### 3.2. [Server] Register Host From the same container, register the Host — this links your URL, Account Key, and Consensus Key (fetched automatically) on-chain: ``` inferenced register-new-participant \ $DAPI_API__PUBLIC_URL \ $ACCOUNT_PUBKEY \ --node-address $DAPI_CHAIN_NODE__SEED_API_URL ``` **Expected output:** ``` ... Found participant: gonka1rk52j24xj9ej87jas4zqpvjuhrgpnd7h3feqmm (url: http://36.189.234.237:19250, status: ACTIVE) Participant is now available at http://36.189.234.237:19250/v2/participants/gonka1rk52j24xj9ej87jas4zqpvjuhrgpnd7h3feqmm Account balance: 0 ``` > **Account 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: ```text rpc error: code = Unknown desc = runtime error: invalid memory address or nil pointer dereference: panic ``` This 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**: ```bash ./inferenced query auth account \ --node /chain-rpc/ \ --output json | jq -r '.account.value.sequence // .sequence // "0"' ``` If 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: ```bash curl -s $DAPI_CHAIN_NODE__URL/status | jq -r '.result.validator_info.pub_key.value' ``` **Step 2.** Exit the container, then run this command on your **local machine** (where your Account Key is stored): ```bash ./inferenced tx inference submit-new-participant \ \ --validator-key \ --keyring-backend file \ --from \ --timeout-duration 1m \ --unordered \ --node /chain-rpc/ \ --chain-id gonka-mainnet ``` `` — 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 ` 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: ```bash exit ``` #### 3.3. [Local machine] Grant Permissions to ML Operational Key **IMPORTANT: 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: ```bash ./inferenced tx inference grant-ml-ops-permissions \ gonka-account-key \ \ --from gonka-account-key \ --keyring-backend file \ --gas 2000000 \ --node /chain-rpc/ ``` **Expected output:** ``` ... Transaction sent with hash: FB9BBBB5F8C155D0732B290C443A0D06BC114CDF43E8EE8FB329D646C608062E Waiting for transaction to be included in a block... Transaction confirmed successfully! Block height: 174 ``` #### 3.4. [Server] Manual SSL Certificate Setup If you selected manual SSL certificate setup in the questionnaire above, follow these steps to configure your SSL certificates: ##### Prepare directories ```bash mkdir -p secrets/nginx-ssl secrets/certbot ``` ##### Generate certificates (Dockerized Certbot; DNS‑01) ```bash DOMAIN= ACCOUNT_EMAIL= # renewal notices mkdir -p secrets/nginx-ssl secrets/certbot docker run --rm -it \ -v "$(pwd)/secrets/certbot:/etc/letsencrypt" \ -v "$(pwd)/secrets/nginx-ssl:/mnt/nginx-ssl" \ certbot/certbot certonly --manual --preferred-challenges dns \ -d "$DOMAIN" --email "$ACCOUNT_EMAIL" --agree-tos --no-eff-email \ --deploy-hook 'install -m 0644 "$RENEWED_LINEAGE/fullchain.pem" /mnt/nginx-ssl/cert.pem; \ install -m 0600 "$RENEWED_LINEAGE/privkey.pem" /mnt/nginx-ssl/private.key' ``` > **DNS 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/`. ##### Verify certificate files Ensure the certificate files are in place: ```bash ls -la secrets/nginx-ssl/ ``` You 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=` - `SSL_CERT_SOURCE=./secrets/nginx-ssl` Make sure to edit `SERVER_NAME` with your actual domain name before proceeding. ## 4. [Server] Launch Full Node Finally, launch all containers, including the API: > **Configuration Required** Please complete the [questionnaire above](#quickstart-questionnaire) to generate the launch commands. Launch all containers: ```bash source config.env && \ docker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d ``` Launch all containers with automatic SSL certificate management: ```bash source config.env && \ docker compose --profile "ssl" \ -f docker-compose.yml -f docker-compose.mlnode.yml \ up -d ``` The `--profile "ssl"` flag enables the `proxy-ssl` container which automatically manages SSL certificates. Launch all containers with manual SSL certificates: ```bash source config.env && \ docker compose -f docker-compose.yml -f docker-compose.mlnode.yml up -d ``` ## Verify Node Status {#verify-node-status} Verify HTTPS is working: ```bash curl -I https://:8443/health # Expect: HTTP/2 200 OK ``` Open this URL, replacing `` with your address: ``` http://node2.gonka.ai:8000/v2/participants/ ``` You 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/ ``` Once your node completes the Proof of Compute stage (which runs every 24 hours), you can visit the following URL to see your node: ```bash http://node2.gonka.ai:8000/v1/epochs/current/participants ``` You can [simulate the Proof of Compute on a MLNode yourself](https://gonka.ai/FAQ/#how-to-simulate-proof-of-compute-poc) 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](https://gonka.ai/wallet/dashboard/) here: ``` http://node2.gonka.ai:8000/dashboard/gonka/validator ``` Once your node is running, check your node status through the proxy. ```bash curl http://:8000/chain-rpc/status ``` On the server, you can use private ones (from within the container or if 26657 is bound to localhost). ```bash curl http://0.0.0.0:26657/status ``` Using the public endpoint of the genesis node. ```bash curl http://node2.gonka.ai:8000/chain-rpc/status ``` Once 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](https://gonka.ai/host/validator_info/). ## 5. [Local machine] Deposit Collateral **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. ```bash export NODE_URL="" # e.g. http://node2.gonka.ai:8000 export CHAIN_ID="gonka-mainnet" PARAMS=$(curl -s "$NODE_URL/chain-api/productscience/inference/inference/params") BASE_WEIGHT_RATIO=$(echo "$PARAMS" | jq -r '.params.collateral_params.base_weight_ratio | (.value | tonumber) * pow(10; .exponent | tonumber)') COLLATERAL_PER_UNIT=$(echo "$PARAMS" | jq -r '.params.collateral_params.collateral_per_weight_unit | (.value | tonumber) * pow(10; .exponent | tonumber)') MAX_WEIGHT=$(curl -s "$NODE_URL/v1/epochs/current/participants" \ | jq '[.active_participants.participants[].weight] | max') DEPOSIT=$(printf "%.0f" "$(echo "$MAX_WEIGHT * (1 - $BASE_WEIGHT_RATIO) * $COLLATERAL_PER_UNIT * 2" | bc -l)") echo "Recommended deposit (covers network max with 2x buffer): ${DEPOSIT} ngonka" ``` The 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`): ```bash ./inferenced tx collateral deposit-collateral ${DEPOSIT}ngonka \ --from gonka-account-key \ --keyring-backend file \ --node $NODE_URL/chain-rpc/ \ --chain-id $CHAIN_ID ``` Verify: ```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 ``` Deposits 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](https://gonka.ai/host/collateral/). ## Optional: PoC delegation and refusal {#optional-poc-delegation-and-refusal} Use this section **after** your Host is registered, the ML Operational Key is authorized, and you can [verify](#verify-node-status) 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](./multi_model_poc.md). Set `NODE` to any synced chain RPC (same pattern as `grant-ml-ops-permissions`: seed API URL from `config.env` with `/chain-rpc/` appended). ```bash export NODE="" # e.g. http://node2.gonka.ai:8000/chain-rpc/ export CHAIN_ID="gonka-mainnet" export KEY="gonka-account-key" export KEYRING_BACKEND="file" ``` Check governance parameters (penalties, `penalty_start_epoch`, etc.): ```bash ./inferenced query inference params --node "$NODE" -o json ``` **Inspect your PoC delegation / refusal / intent state** (all models): ```bash MY_ADDR="$(./inferenced keys show "$KEY" -a --keyring-backend "$KEYRING_BACKEND")" ./inferenced query inference poc-delegation "$MY_ADDR" --node "$NODE" -o json ``` **Delegate** — attach your weight for that model's PoC validation to `DELEGATEE` (their `gonka1…` address). Example for Kimi: ```bash MODEL="moonshotai/Kimi-K2.6" 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 ``` Example for MiniMax (e.g. you run Kimi only on your GPUs): ```bash MODEL="MiniMaxAI/MiniMax-M2.7" 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 ``` **Clear** a delegation for one model: ```bash MODEL="moonshotai/Kimi-K2.6" ./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 ``` **Refuse** delegation for one model (explicit on-chain “no”): ```bash MODEL="moonshotai/Kimi-K2.6" ./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 ``` `declare-poc-intent` applies mainly to **new model bootstrap** windows; see [Kimi K2.6 Bootstrap](./kimi-bootstrap.md). More commands and edge cases: [Multi-Model PoC — Host Operations Guide](./multi_model_poc.md#copy-paste-setup-commands). ## Stopping and Cleaning Up Your Node ### How to stop your node Check the epoch you are currently in. Open the URL: [http://node1.gonka.ai:8000/api/v1/epochs/latest](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": { "index": 88, ... } ``` Remember the latest epoch index your node worked for. In the same JSON response, find: ``` "next_epoch_stages": { ... "claim_money": } ``` This block number indicates the block after which you can claim the reward. However, it is important to understand you should proceed with disabling each ML Node now (do not wait for this block before disabling your ML Nodes). Disable each ML Node. ``` curl -X POST http://:/admin/v1/nodes//disable ``` Wait for the next epoch. Do not stop the Network Node or the ML Nodes yet. The disable flag takes effect only after the next epoch starts. Keep 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 `` and `` with your actual values): ``` inferenced query inference show-epoch-performance-summary --node http://node1.gonka.ai:8000/chain-rpc/ --output json ``` Example: ``` Output: { "epochPerformanceSummary": { "epoch_index": "87", "participant_id": "", "missed_requests": "1", "rewarded_coins": "123456", "claimed": true } } ``` If the result shows `claimed = 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 \ -H "Content-Type: application/json" \ -d '{"force_claim": true}' ``` Verify 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 ``` This stops and removes all services defined in the `docker-compose.yml` and `docker-compose.mlnode.yml` files without deleting volumes or data unless explicitly configured. ### How to clean up your node (full reset) If you want to completely reset your node and remove all data (for redeployment or migration), use the following cleanup steps. 1. To clean up cache and start fresh, remove the local `.inference` and `.dapi` folders (inference runtime cache and identity): ```bash rm -rf .inference .dapi .tmkms ``` 2. (Optional) Clear model weights cache: ```bash rm -rf $HF_HOME ``` 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](https://gonka.ai/FAQ/), or join [Discord server](https://discord.com/invite/RADwCT2U6R) for assistance with general inquiries, technical issues, or security concerns. --- ## How to Create and Submit a Governance Proposal on Gonka # How to Create and Submit a Governance Proposal on Gonka Step-by-step for submitting Proposal with `inferenced`. Aligned with Gonka Transactions & Governance. Replace every placeholder with your own values before running commands. ## Placeholders | Placeholder | Meaning | |---|---| | `` | Your key name in the keyring (not your `gonka1...` address) | | `` | Path to the proposal JSON file, e.g. `./proposal.json` | | `` | Node base URL without `/chain-rpc/`, e.g. `http://node1.gonka.ai:8000` | | `` | e.g. `gonka-mainnet` for mainnet | If a command fails with `connection` or `parse`, check that every RPC command uses `/chain-rpc/` with exactly one `/chain-rpc/`. --- ## Two URLs (do not mix them) | Task | Variable | |---|---| | `inferenced query / tx` | `/chain-rpc/` (must include `/chain-rpc/`) | | `create-client` (HTTP `.../v1/participants` on the seed) | `` (no `/chain-rpc/`) | Using `/chain-rpc/` for `--node-address` in `create-client` is incorrect and will fail or hit the wrong service. --- ## Prerequisites ### 1. Install CLI Download a build for your OS from Gonka releases, unpack, then: ```bash chmod +x inferenced ./inferenced --help ``` For detailed CLI installation instructions, see the [local machine CLI setup guide](https://gonka.ai/host/quickstart/#local-machine-install-the-cli-tool). After installing the CLI, you can return to this page and continue. ### 2. Read governance parameters from the chain 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: ```bash ./inferenced query gov params \ --node "/chain-rpc/" \ --chain-id "" \ -o json | jq '.params | { min_deposit, expedited_min_deposit, max_deposit_period, voting_period, expedited_voting_period, quorum, threshold, expedited_threshold, veto_threshold, burn_vote_veto }' ``` Your 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: ```text min_deposit: 500000000000ngonka # 500 GNK expedited_min_deposit: 1000000000000ngonka # 1000 GNK max_deposit_period: 86400s # 24 hours voting_period: 172800s # 48 hours expedited_voting_period: 43200s # 12 hours quorum: 0.25 threshold: 0.500000000000000000 expedited_threshold: 0.667000000000000000 veto_threshold: 0.334000000000000000 burn_vote_veto: true ``` ### 3. Proposal JSON Prepare 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: #### Proposal description fields Keep the on-chain text short and clear. Make sure the proposal includes: - A short summary of what the proposal is about. - A link to the full proposal description with all details. - The wallet address where funds should be sent, if the proposal requests funding. - The requested amount and denom, if the proposal requests funding. #### Proposal JSON structure 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: ```bash ./inferenced query auth module-accounts \ --node "/chain-rpc/" \ --chain-id "" \ -o json | jq -r '.accounts[] | select(.value.name=="gov") | .value.address' ``` Use 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. ### 4. Optional: new key + register participant (`create-client`) This creates a key and calls the seed HTTP API (participant registration). Use `` only: ```bash ./inferenced create-client "" \ --node-address "" ``` Store 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`. --- ## Publish the proposal on-chain ### 1. Check balance ```bash ./inferenced query bank balances \ "$(./inferenced keys show "" -a --keyring-backend file)" \ --node "/chain-rpc/" \ --chain-id "" ``` Ensure you have enough `ngonka` (or the fee denom your node expects) for `min_deposit` and fees. ### 2. Submit Recommended pattern from the official Gonka doc: ```bash ./inferenced tx gov submit-proposal "" \ --from "" \ --keyring-backend file \ --chain-id "" \ --node "/chain-rpc/" \ --unordered --timeout-duration=60s \ --gas 2000000 --gas-adjustment 5.0 \ --yes ``` After 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. --- ## Voting and tally Voting steps and result formulas are documented on the dedicated page: - [Voting on Proposals](https://gonka.ai/governance/voting-on-proposals/) --- ## Submit a Parameter Change Proposal **TL;DR:** draft a proposal with `MsgUpdateParams`, include **all** params for that module, ensure deposit meets `min_deposit`, submit, then track/deposit/vote. ### 1. Get the governance module address (authority) ```bash inferenced query auth module-accounts --node /chain-rpc/ | grep -B2 'name: gov' ``` ### 2. Export current params for the target module ```bash inferenced query inference params -o json --node /chain-rpc/ > current_params.json ``` ### 3. Check governance deposit and tally parameters ```bash inferenced query gov params -o json --node /chain-rpc/ \ | jq '.params | { min_deposit, expedited_min_deposit, voting_period, expedited_voting_period, quorum, threshold, expedited_threshold, veto_threshold, burn_vote_veto }' ``` ### 4. Draft the proposal file ```bash inferenced tx gov draft-proposal # fills draft_proposal.json and draft_metadata.json ``` Edit `draft_proposal.json` and include the full `params` object. ### 5. Submit the proposal ```bash inferenced tx gov submit-proposal ./draft_proposal.json \ --from \ --keyring-backend file \ --unordered --timeout-duration=60s \ --gas=2000000 --gas-adjustment=5.0 \ --node /chain-rpc/ \ --yes ``` ### 6. Ensure your proposal is on-chain ```bash inferenced query gov proposals --node /chain-rpc/ ``` ### Review the contents carefully (especially param updates) ```bash # 2a) Get current module params (example: inference module) inferenced query inference params -o json --node /chain-rpc/ > current_params.json # 2b) Extract proposed params from the proposal inferenced query gov proposal -o json --node /chain-rpc/ \ | jq '.proposal.messages[] | select(."type"=="inference/x/inference/MsgUpdateParams") | .value' \ > proposed_params.json # 2c) Diff diff -u current_params.json proposed_params.json || true ``` For `MsgUpdateParams`, modules typically expect the **full** params object and `authority` set to the **gov module account**. --- ## Transactions & Governance # Transactions & Governance 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](https://gonka.ai/host/quickstart/#local-machine-install-the-cli-tool)). Transactions are sent through an RPC endpoint (here referred to as `/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 /chain-rpc/`. Unordered transactions are supported and recommended here to avoid sequence contention. ([docs.cosmos.network](https://docs.cosmos.network/sdk/v0.53/learn/beginner/tx-lifecycle)) ???+ note "Always include these flags in transaction commands" - `--from ` → 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 /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](https://docs.cosmos.network/sdk/v0.53/learn/beginner/tx-lifecycle) and [Gas & Fees](https://docs.cosmos.network/sdk/v0.53/learn/intro/sdk-design#modules). ## When a Governance Proposal Is Required Governance Proposals are required for any on-chain changes that affect the network, for example: - Updating module parameters (`MsgUpdateParams`) - Executing software upgrades - Adding, updating, or deprecating inference models - Transferring funds from the Community Pool - Any other actions that must be approved and executed via the governance module --- ## Who can create a Governance Proposal 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](https://github.com/gonka-ai) or [community forums](https://discord.com/invite/RADwCT2U6R)) to increase the likelihood of approval. --- ???+ note "Need proposal creation, voting, voting power, eligibility, and delegation details?" - [Creating Proposals](/governance/creating-proposals/) - [Voting on Proposals](/governance/voting-on-proposals/) - [Voting Power, Eligibility, Delegation](/governance/voting-power-eligibility/) ## Check Live Governance Parameters 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. ```bash inferenced query gov params -o json --node /chain-rpc/ \ | jq '.params | { min_deposit, expedited_min_deposit, max_deposit_period, voting_period, expedited_voting_period, quorum, threshold, expedited_threshold, veto_threshold, burn_vote_veto }' ``` At 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. ## Track Proposal Status ```bash # One proposal inferenced query gov proposal -o json --node /chain-rpc/ # Tally only inferenced query gov tally -o json --node /chain-rpc/ # List all inferenced query gov proposals -o json --node /chain-rpc/ ``` ([docs.cosmos.network](https://docs.cosmos.network/sdk/v0.53/build/modules/gov/README)) For the full quorum, threshold, veto, and `abstain` formulas, see [Voting on Proposals](/governance/voting-on-proposals/#how-the-result-is-counted). **You can also monitor governance via dashboards:** - Node dashboard pattern: `/dashboard/gonka/gov` > **** - [http://node1.gonka.ai:8000/dashboard/gonka/gov](http://node1.gonka.ai:8000/dashboard/gonka/gov) - [http://node2.gonka.ai:8000/dashboard/gonka/gov](http://node2.gonka.ai:8000/dashboard/gonka/gov) - and other > **** - [vote.gonka.vip/governance](https://vote.gonka.vip/governance) - [tracker.gonka.hyperfusion.io/governance](https://tracker.gonka.hyperfusion.io/governance) - [gonka.gg/network/proposals](https://gonka.gg/network/proposals) --- ## Notes ???+ note "Notes" - **Unordered tx semantics.** When using `--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](https://docs.cosmos.network/sdk/v0.53/learn/beginner/tx-lifecycle)) - **Gas tuning.** If simulations are tight or validators use higher min gas prices, raise `--gas-adjustment` or set `--gas-prices` per network policy. ([docs.cosmos.network](https://docs.cosmos.network/sdk/v0.53/learn/beginner/tx-lifecycle)) --- ## Voting on Proposals # Voting on Proposals ## Who Can and Cannot Vote 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: - **PoC failure**: the participant is marked `INACTIVE`, dropped from the next epoch's compute results, given `tokens = 0`, and cannot vote. - **CPoC failure**: Confirmation PoC, where peers cross-validate each other's PoC submissions. Same outcome: removed from the active set, `tokens = 0`, no vote weight. - **Active participant**: tokens are recomputed from the new weight, vote weight = weight, or boosted for Guardians. **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. --- ## Verify and Vote Most participants only need to verify a proposal and cast a vote. Do these four things: ### Identify the right proposal ID (and verify it is the one you were told) ```bash # List all proposals (IDs + basic info) inferenced query gov proposals -o json --node /chain-rpc/ # Inspect a specific proposal in detail inferenced query gov proposal -o json --node /chain-rpc/ ``` Confirm the **id**, **title**, **summary**, and (if present) **metadata** match what was shared with you. ???+ note "Know the voting options and short flow" - **Options:** `yes`, `no`, `no_with_veto`, `abstain`. - **Flow:** proposals open (after deposit) -> voting period runs -> outcome decided by quorum/threshold/veto parameters -> if passed, messages execute via the gov module. - You may change your vote any time before voting period ends; the last vote counts. ### Check current governance parameters 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. ```bash inferenced query gov params -o json --node /chain-rpc/ \ | jq '.params | { voting_period, expedited_voting_period, quorum, threshold, expedited_threshold, veto_threshold, burn_vote_veto, min_deposit, expedited_min_deposit }' ``` At the time of writing, mainnet parameters are: ```text min_deposit: 500000000000ngonka # 500 GNK expedited_min_deposit: 1000000000000ngonka # 1000 GNK max_deposit_period: 86400s # 24 hours voting_period: 172800s # 48 hours expedited_voting_period: 43200s # 12 hours quorum: 0.25 threshold: 0.500000000000000000 expedited_threshold: 0.667000000000000000 veto_threshold: 0.334000000000000000 burn_vote_veto: true ``` ### How the result is counted The tally uses PoC-weighted voting power. A proposal can pass only after quorum is reached: ```text total_votes / total_bonded_voting_power >= quorum ``` Where: ```text total_votes = Yes + No + NoWithVeto + Abstain non_abstain_votes = Yes + No + NoWithVeto ``` With current mainnet params, quorum is: ```text total_votes / total_bonded_voting_power >= 0.25 ``` After quorum, veto is checked before the pass threshold: ```text NoWithVeto / (Yes + No + NoWithVeto + Abstain) > veto_threshold ``` With current mainnet params: ```text NoWithVeto / total_votes > 0.334 ``` If 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: ```text Yes / (Yes + No + NoWithVeto) > threshold ``` With current mainnet params: ```text Yes / non_abstain_votes > 0.5 ``` For expedited proposals: ```text Yes / non_abstain_votes > 0.667 ``` ### How `abstain` affects the result `abstain` is neutral, but it still affects the tally: - It counts toward quorum. - It is excluded from the Yes threshold denominator. - It is included in the veto denominator, so it pushes the veto ratio down. Important: `abstain` does **not** add to `no_with_veto`. The veto numerator is only `NoWithVeto`. Example: ```text Yes = 40 No = 0 NoWithVeto = 20 Abstain = 40 veto ratio = 20 / 100 = 20% # veto does not trigger pass ratio = 40 / 60 = 66.7% # passes regular threshold ``` ### Cast (or change) your vote ```bash # options: yes | no | no_with_veto | abstain inferenced tx gov vote yes \ --from \ --keyring-backend file \ --unordered --timeout-duration=60s \ --gas=2000000 --gas-adjustment=5.0 \ --node /chain-rpc/ \ --yes ``` ```bash # See tally inferenced query gov tally -o json --node /chain-rpc/ # Optional: list votes inferenced query gov votes -o json --node /chain-rpc/ ``` --- ???+ note "Notes" - **Who can create a proposal:** anyone with a valid governance (cold) key who pays required fees/deposit. - **Track status:** use `query gov proposal`, `query gov tally`, and `query gov proposals`. See also [Track Proposal Status](/governance/transactions-and-governance/#track-proposal-status). - **Transaction flags:** in governance transactions, keep `--keyring-backend file --unordered --timeout-duration=60s --gas=2000000 --gas-adjustment=5.0 --node /chain-rpc/`. --- ## Voting Power, Genesis Guardians and Delegation # Voting Power, Genesis Guardians and Delegation ## Total bonded weight calculation The total bonded weight is the sum of `validator.tokens` across all bonded validators with `tokens > 0`: ```text total_bonded = Σ validator.tokens (over all bonded validators with tokens > 0) ``` Each validator's `tokens` value is set on every epoch transition by the inference module via `Staking.SetComputeValidators()`. For the vast majority of validators: ```text validator.tokens = participant.weight (their PoC weight in the current epoch) ``` For the Genesis Guardians, an additional power-enhancement step is applied first (see below). --- ## Genesis Guardians 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. > **** - `gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5` (`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: - [Early network protection proposal](https://github.com/gonka-ai/gonka/tree/main/proposals/early-network-protection) ???+ note "Purpose" - Prevent a 67% takeover of consensus during the early, low-stake phase. - Help block malicious governance proposals during bootstrap. - Provide rapid-response capability against protocol exploits. - Make cheap majority acquisition during bootstrap economically uninteresting. --- ### Guardian power boost calculation Before `SetComputeValidators` runs, the inference module applies `applyEarlyNetworkProtection`, which computes enhanced power as follows: ```text other_total = total_network_power − Σ guardian_original_power total_enhancement = other_total × multiplier per_guardian_power = total_enhancement / guardian_count guardian.tokens = per_guardian_power # original PoC weight is REPLACED non_guardian.tokens = participant.weight # unchanged ``` As 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: ```text guardian_share = multiplier / (1 + multiplier) guardian_share = 0.33334 / 1.33334 ≈ 25% ``` **Effect (measured at each epoch transition):** - At the instant the boost is applied, the combined Guardian share targets `multiplier / (1 + multiplier)` of total bonded power. - This target is reached **when the boost runs**, not as a fixed steady state. Guardian `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. - With the current `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. - Cannot extract value or unilaterally change consensus — coordination among the Guardians is required for any action. --- ### Guardian boost end conditions The enhancement deactivates automatically (no governance vote required) when both of the following on-chain conditions are met: ```text total_network_power >= network_maturity_threshold (currently 15,000,000) current_height >= network_maturity_min_height (currently 3,000,000) ``` Current status on the live network: - The height threshold (`3,000,000`) has already been crossed. - Total network power is still well below `15,000,000`, so the boost remains active. - The boost will switch off in the first epoch transition after the network's aggregate PoC weight crosses `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. --- ## Governance delegation (cold key to warm key) 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: - Granter = account that owns voting power (cold key) - Grantee = account that will submit votes on the granter’s behalf (warm key) ???+ note "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. ### Another key votes 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) === "Command" ``` ./inferenced tx authz grant generic \ --msg-type=/cosmos.gov.v1beta1.MsgVote \ --from= \ --chain-id=gonka-mainnet \ --expiration= \ --home .inference \ --keyring-backend file ``` === "Example response" ``` { "height": "0", "txhash": "8D96FB6FC06FFB928FBC89FE950689CD040C7F338C197BA856175EC7462A3FFA", "codespace": "", "code": 0, "data": "", "raw_log": "", "logs": [], "info": "", "gas_wanted": "0", "gas_used": "0", "tx": null, "timestamp": "", "events": [] } ``` #### 2. Verify the grant exists (run from any node) === "Command" ``` ./inferenced query authz grants \ --node="/chain-rpc/" \ --output=json | jq . ``` === "Example response" ``` { "grants": [ { "authorization": { "type": "cosmos-sdk/GenericAuthorization", "value": { "msg": "/cosmos.gov.v1beta1.MsgVote" } }, "expiration": "2026-12-03T18:38:18Z" } ], "pagination": { "total": "1" } } ``` #### 3. Vote using the grantee === "Command" ``` # Find the proposal ID which you are voting for - use it as in the voting body ./inferenced query gov proposals --output json # Prepare the file with the voting body cat > /tmp/authz-vote.json ", "msgs": [ { "@type": "/cosmos.gov.v1beta1.MsgVote", "proposal_id": "", "voter": "", "option": "VOTE_OPTION_YES" } ] } ] } } EOF # Vote using the file ./inferenced tx authz exec /tmp/authz-vote.json \ --from= \ --chain-id=gonka-mainnet \ --home .inference \ --keyring-backend file \ --node="/chain-rpc/" -y ``` === "Example response" ``` { "height": "0", "txhash": "C31311D9C43DD6F1DDE7CA143989A0551E3075C2FA0A2BB5F054A120AE552B2B", "codespace": "", "code": 0, "data": "", "raw_log": "", "logs": [], "info": "", "gas_wanted": "0", "gas_used": "0", "tx": null, "timestamp": "", "events": [] } ``` `code: 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. --- ## Eligibility summary | Status | Can vote? | Vote weight | |---|---|---| | Active participant, in epoch | Yes | `= 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` | --- ## Run your own gateway # Run your own gateway 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](quickstart.md#1-use-a-community-broker-recommended) instead — that path does not require Docker, on-chain escrows, or an allow-listed creator address. ### Allowlisted creator address required > **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](quickstart.md#3-become-a-broker) in the Developer Quickstart — or use a [community broker](quickstart.md#1-use-a-community-broker-recommended) instead. > > After you import your key in [§2.3](#23-import-the-creator-key), verify membership in [§2.4](#24-confirm-allowlist-membership). 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`**. ### How this setup works 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. ### What you need 1. **Allowlisted escrow creator** — `$DEVSHARD_CREATOR` on `allowed_creator_addresses` ([prerequisite](#allowlisted-creator-address-required) above; confirm in [§2.4](#24-confirm-allowlist-membership)) 2. A Linux host with Docker 3. Outbound HTTPS to a public Gonka mainnet endpoint ([node3](https://node3.gonka.ai/) for chain REST + public API) 4. The [inferenced CLI v0.2.13](https://github.com/gonka-ai/gonka/releases/tag/release/v0.2.13) on the same host (for queries and on-chain settle) 5. A funded `gonka1…` address used **only** as that escrow creator (after allowlist is confirmed) ### Mainnet reference | Item | Value | | ------------------------ | --------------------------------------------------------------- | | Chain ID | `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](#22-create-configdevshardenv). Every command below assumes you have run `source config.devshard.env` from your deploy directory. --- ## 1. Install tools and create a deploy directory ### 1.1 Install Docker and `inferenced` Confirm Docker is available: ```bash docker --version ``` Download **inferenced v0.2.13** from the [release page](https://github.com/gonka-ai/gonka/releases/tag/release/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` keeps CLI state separate from a default `~/.inference` install. `INFERENCED_KEYRING` is only a folder name for imported keys. ### 1.2 Create the deploy directory 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**: ```bash sudo mkdir -p /srv/gonka/devshard-gateway sudo chown "$USER:$USER" /srv/gonka/devshard-gateway cd /srv/gonka/devshard-gateway ``` --- ## 2. Prepare identity and configuration ### 2.1 Generate API keys and escrow wallet From the deploy directory, generate secrets and save the output for the next step: ```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` is a **dedicated escrow creator** wallet. Do not reuse validator, participant, or broker keys. ### 2.2 Create `config.devshard.env` This file must exist before `source config.devshard.env` or `docker compose up`. Docker Compose loads it into the container. ```bash nano config.devshard.env ``` Example mainnet contents (paste secrets from [§2.1](#21-generate-api-keys-and-escrow-wallet)): ```bash # Chain (public node — gonka-mainnet) 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 # inferenced CLI (local; not used by the gateway container) export INFERENCED_HOME="$HOME/.devshard-inferenced" export INFERENCED_KEYRING="$INFERENCED_HOME/keyring-devshard" # Escrow creator + gateway auth (from §2.1) export DEVSHARD_PRIVATE_KEY= export DEVSHARD_API_KEYS=sk-... export DEVSHARD_ADMIN_API_KEY=sk-admin-... # Gateway (devshardctl container) 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 ``` `DEVSHARDS_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: ```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' ``` You should see a recent block height. Optional — list governance models: ```bash curl -sS "$NODE_BASE/v1/governance/models" | jq ``` ### 2.3 Import the creator key ```bash source config.devshard.env test -f config.devshard.env test -n "$DEVSHARD_PRIVATE_KEY" ``` `--keyring-backend test` is the Cosmos SDK backend name (local dev keyring). ```bash inferenced keys import-hex devshard-create "$DEVSHARD_PRIVATE_KEY" \ --keyring-backend test \ --keyring-dir "$INFERENCED_KEYRING" \ --home "$INFERENCED_HOME" ``` If import reports the key already exists, skip import. Resolve the on-chain creator address: ```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" ``` Optional — persist `DEVSHARD_CREATOR` in the env file (run once): ```bash grep -q '^export DEVSHARD_CREATOR=' config.devshard.env || \ echo "export DEVSHARD_CREATOR=$DEVSHARD_CREATOR" >> config.devshard.env ``` The name `devshard-create` is only a local label; on-chain transactions use `--from devshard-create` to sign as `$DEVSHARD_CREATOR`. ### 2.4 Confirm allowlist membership **Do not skip this step.** Escrow creation in [§4](#4-create-an-escrow-and-open-api-access) 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](quickstart.md#3-become-a-broker) to request a governance params update. Re-run this check after any governance vote before creating an escrow. ```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' ``` The 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](https://github.com/gonka-ai/gonka/blob/gm/microrelease/inference-chain/app/upgrades/v0_2_13/upgrades.go), 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](#25-fund-the-creator-account), [§3](#3-deploy-the-gateway), or [§4](#4-create-an-escrow-and-open-api-access) until it is added on chain. ### 2.5 Fund the creator account Only after [§2.4](#24-confirm-allowlist-membership) returns `true`, fund the creator: ```bash inferenced query bank balances "$DEVSHARD_CREATOR" \ --node "$NODE_RPC" --chain-id "$CHAIN_ID" -o json --home "$INFERENCED_HOME" \ | jq '.balances[] | select(.denom=="ngonka")' ``` Send 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](#escrow-lifetime-and-rotation)), fund the creator for **several** deposits per epoch—not only the one manual escrow in [§4](#4-create-an-escrow-and-open-api-access). > **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](https://gonka.ai/cross-chain-transfers/ethereum-bridge/dashboard/). The dashboard derives the correct `gonka1…` address from your Ethereum wallet and handles the deposit without CLI tools. --- ## 3. Deploy the gateway 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](#4-create-an-escrow-and-open-api-access); starting the gateway first is fine. | Path | Purpose | | --------------------- | ----------------------------------------- | | `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: ```bash cd /srv/gonka/devshard-gateway ``` ### 3.1 Create `docker-compose.yml` ```bash nano docker-compose.yml ``` Gateway-only compose (no `node` or `api` services): ```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` injects chain URLs and keys into the container. - The volume mount keeps registered escrows and admin settings across restarts. - `127.0.0.1:18080` binds the API to localhost only; put nginx or another reverse proxy in front if remote clients need access. ### 3.2 Pull the image and start the container Load environment variables and pull the image: ```bash cd /srv/gonka/devshard-gateway source config.devshard.env sudo docker compose pull ``` Start the gateway in the background: ```bash sudo docker compose up -d ``` Confirm the service is healthy: ```bash sudo docker compose ps ``` Expect `devshardctl-multi` (or your `DEVSHARD_INSTANCE_NAME`) in state **running**, with health **healthy** after the start period. ### 3.3 Verify the HTTP API ```bash curl -fsS http://127.0.0.1:18080/v1/status | jq '{runtimes, capacity: .capacity.models}' ``` A JSON response means the gateway is up. Escrows may be empty until you complete [§4](#4-create-an-escrow-and-open-api-access). Chat completions are available at: `http://127.0.0.1:18080/v1/chat/completions` (or the URL your reverse proxy forwards to that port). --- ## 4. Create an escrow and open API access **Allowlist check:** `$DEVSHARD_CREATOR` must already be allowlisted ([§2.4](#24-confirm-allowlist-membership)). Otherwise escrow create fails on chain. The deposit in §4.1 must be **≥** on-chain `min_amount` from §2.4. ### 4.1 Create and register the escrow 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](#6-finalize-and-settle-the-escrow), unless you enable automatic rotation in [Escrow lifetime and rotation](#escrow-lifetime-and-rotation) below. ```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" ``` Keep `ESCROW_ID` in your shell for the rest of this guide. In a new session, set it again (for example `export ESCROW_ID=1`). ### 4.2 Open user API access Models default to `admin_only` until you enable API-key access: ```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" }] }' ``` Confirm the escrow is loaded: ```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 . ``` ### Running multiple escrows (parallel pool) One 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](#5-send-a-test-request)–[§6](#6-finalize-and-settle-the-escrow) below use one escrow; use the pool when you need more throughput or rotation across epochs. ### Escrow lifetime and rotation This guide’s steps in [§4.1](#41-create-and-register-the-escrow)–[§4.2](#42-open-user-api-access) and [§5](#5-send-a-test-request)–[§6](#6-finalize-and-settle-the-escrow) 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. #### How long does a manual escrow live? **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](#6-finalize-and-settle-the-escrow)). | | **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](#24-confirm-allowlist-membership) (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](#24-confirm-allowlist-membership). 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). #### Does the gateway auto-rotate? **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**: 1. `**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). 2. **After the chain leaves the PoC-active window** for that transition: create `**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. #### Enable rotation (production / always-on gateways) Use this after you have already created, funded, and tested at least one escrow manually ([§4](#4-create-an-escrow-and-open-api-access)). 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): ```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" }] } }' ``` Restart is not required: enabling rotation in settings starts the rotator on the running gateway. Inspect timing and the last per-model rotation results: ```bash curl -fsS http://127.0.0.1:18080/v1/debug/rotation \ -H "Authorization: Bearer $DEVSHARD_ADMIN_API_KEY" | jq ``` Useful fields include `chain.blocks_until_next_rotation`, `settings`, and `latest` (per-model stage, counts, and errors). #### If rotation does not run or escrows pile up | Symptom | What to check | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Nothing happens across epochs | Confirm `"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](#6-finalize-and-settle-the-escrow). | | Wrong epoch timing | Rotation uses live chain phase data; ensure `DEVSHARD_PUBLIC_API` / chain REST point at your mainnet node ([§2.2](#22-create-configdevshardenv)). | For a **single manual test**, leave rotation **disabled**, complete [§5](#5-send-a-test-request), then [§6](#6-finalize-and-settle-the-escrow). Enable rotation when you want the gateway to keep fresh escrows across epochs without manual recreate. --- ## 5. Send a test request The gateway endpoint is OpenAI-compatible. Set your API key and send a chat completion: ```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}' ``` In 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](#42-open-user-api-access). --- ## 6. Finalize and settle the escrow 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](#41-create-and-register-the-escrow). Finalize is **per escrow** and must use the path `/devshard/{id}/v1/finalize`, not `/v1/finalize` alone. ### 6.1 Finalize off-chain state ```bash 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` 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: ```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 Settle on chain The ngonka amount which was not used is returned to your creator address after host payouts and protocol fees. ```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 Confirm settlement and refund Escrow state on chain: ```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}' ``` Expect `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): ```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}' ``` After settlement, most of the unused deposit should return to `$DEVSHARD_CREATOR`, minus inference cost, settlement fees, and transaction gas. --- ## 7. Pause, redirect, and stop the gateway Sections [§1](#1-install-tools-and-create-a-deploy-directory)–[§6](#6-finalize-and-settle-the-escrow) cover a single test escrow. This section is for pausing routing, redirecting clients when asked, or shutting down the host. ### 7.1 Deactivate one escrow After you settle in [§6](#6-finalize-and-settle-the-escrow), 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. ```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 Redirect all client traffic (gateway kill-switch) To 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. ```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" } }' ``` To 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](https://github.com/gonka-ai/gonka) repo). After `gateway.db` exists, use `**POST /v1/admin/settings`**. ### 7.3 Stop the container and optional cleanup Optional — remove the local gateway record (run while the container is still up, after settle): ```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" ``` Stop Docker: ```bash cd /srv/gonka/devshard-gateway sudo docker compose down # Optional: remove persisted gateway state # sudo rm -rf .devshardctl ``` --- ## 8. Update the gateway without dropping traffic (hot-swap) Replacing 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**: - Second `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. - Public routing via reverse proxy upstream name change (not a full proxy container restart for chat). **The Step-by-step playbook** is being prepared at the moment. --- ## Related - [Developer Quickstart](quickstart.md) — community brokers and [Become a broker](quickstart.md#3-become-a-broker) **Need help?** See the [FAQ](https://gonka.ai/FAQ/), join [Discord](https://discord.com/invite/RADwCT2U6R), or open a [broker / allowlist request](https://github.com/gonka-ai/gonka/issues/new?title=Request+to+be+added+as+a+Gonka+broker) on GitHub. --- ## Developer Quickstart # Developer Quickstart 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](#2-run-your-own-gateway-advanced) 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. > **** Gonka 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. | --- ## 1. Use a community broker (recommended) 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 ` 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. ### 1.1 Pick a broker - [https://gonka24.com/](https://gonka24.com/) - [https://proxy.gonka.gg/](https://proxy.gonka.gg/) · [▶ demo](https://drive.google.com/file/d/1-Zk__4cY_ENi0Q8gw-JHgEBz6XZWXKAj/view?pli=1) - [https://gonkagate.com/](https://gonkagate.com/) - [https://gate.joingonka.ai/](https://gate.joingonka.ai/) · [▶ demo](https://www.youtube.com/watch?v=_761q6UEluc) - [https://router.gonkascan.com/](https://router.gonkascan.com/) · [▶ demo](https://youtu.be/1uWmLGPoBCM) - [https://gonka-api.org/](https://gonka-api.org/) · [▶ demo](https://youtu.be/JgY2ikjcP9M) - [https://gonkabroker.com/](https://gonkabroker.com/) - [https://router.mingles.ai/](https://router.mingles.ai/) · [▶ demo](https://youtu.be/gegiRnNMavY) - [https://console.hyperfusion.io/](https://console.hyperfusion.io/) - [https://inference.dahl.global](https://inference.dahl.global) > **** 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?](#3-interested-in-operating-a-gateway). Some brokers provide a **▶ demo** link to a short onboarding screencast — style and length may vary. > **** Community 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: G-Meter Gonka Power 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. ### 1.2 Get an API key Follow the onboarding instructions on the broker's site. Typically, you will: 1. Sign up on the broker's site (email, account, billing setup). 2. Generate an API key in the broker's dashboard. 3. Note the broker's `base_url` (for example `https://api./v1`) and the list of supported models. ### 1.3 Connect a no-code app or AI coding assistant 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](#12-get-an-api-key)): 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:///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 interfaces" Examples: 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. === "AI IDEs and coding agents" 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. === "No-code automations" 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](#14-send-your-first-request-on-gonka). ### 1.4 Send your first request on Gonka Set environment variables: ```bash export GONKA_BROKER_URL= # e.g. https://api.example-broker.com/v1 export GONKA_BROKER_API_KEY= export GONKA_MODEL=MiniMaxAI/MiniMax-M2.7 # or any model your broker supports ``` The Gonka broker endpoint is OpenAI-compatible, so you can use the official OpenAI SDK directly — no Gonka-specific client is required. === "Python" Install the OpenAI Python SDK: ```bash pip install openai ``` Create `example.py`: ```py linenums="1" import os from openai import OpenAI client = OpenAI( base_url=os.environ["GONKA_BROKER_URL"], api_key=os.environ["GONKA_BROKER_API_KEY"], ) response = client.chat.completions.create( model=os.environ["GONKA_MODEL"], messages=[ {"role": "user", "content": "Write a one-sentence bedtime story about a unicorn"} ], ) print(response.choices[0].message.content) ``` Run with `python example.py`. === "TypeScript" Install the OpenAI JS SDK: ```bash npm install openai ``` Create `example.mjs`: ```ts linenums="1" import OpenAI from "openai"; const client = new OpenAI({ baseURL: process.env.GONKA_BROKER_URL, apiKey: process.env.GONKA_BROKER_API_KEY, }); const response = await client.chat.completions.create({ model: process.env.GONKA_MODEL, messages: [{ role: "user", content: "Hello! Tell me a short joke." }], }); console.log(response.choices[0].message.content); ``` Run with `node example.mjs`. === "Go" Use the official `openai-go` client: ```go linenums="1" package main import ( "context" "log" "os" "github.com/openai/openai-go" "github.com/openai/openai-go/option" ) func main() { client := openai.NewClient( option.WithBaseURL(os.Getenv("GONKA_BROKER_URL")), option.WithAPIKey(os.Getenv("GONKA_BROKER_API_KEY")), ) r, err := client.Chat.Completions.New(context.Background(), openai.ChatCompletionNewParams{ Model: os.Getenv("GONKA_MODEL"), Messages: []openai.ChatCompletionMessageParamUnion{ openai.UserMessage("Write a haiku about programming"), }, }) if err != nil { log.Fatal(err) } log.Println(r.Choices[0].Message.Content) } ``` In a few moments, you should see the inference response in your terminal. ### 1.5 Tool calling 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). === "Python" ```py linenums="1" import os import json from openai import OpenAI client = OpenAI( base_url=os.environ["GONKA_BROKER_URL"], api_key=os.environ["GONKA_BROKER_API_KEY"], ) tools = [ { "type": "function", "function": { "name": "get_weather", "description": "Get the current weather for a city", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "City name"} }, "required": ["city"], }, }, } ] response = client.chat.completions.create( model=os.environ["GONKA_MODEL"], messages=[{"role": "user", "content": "What's the weather in Paris?"}], tools=tools, tool_choice="auto", ) message = response.choices[0].message if message.tool_calls: call = message.tool_calls[0] args = json.loads(call.function.arguments) print(call.function.name, args) ``` === "TypeScript" ```ts linenums="1" import OpenAI from "openai"; const client = new OpenAI({ baseURL: process.env.GONKA_BROKER_URL, apiKey: process.env.GONKA_BROKER_API_KEY, }); const tools = [ { type: "function", function: { name: "get_weather", description: "Get the current weather for a city", parameters: { type: "object", properties: { city: { type: "string", description: "City name" } }, required: ["city"], }, }, }, ]; const response = await client.chat.completions.create({ model: process.env.GONKA_MODEL, messages: [{ role: "user", content: "What's the weather in Paris?" }], tools, tool_choice: "auto", }); const message = response.choices[0].message; if (message.tool_calls) { const call = message.tool_calls[0]; const args = JSON.parse(call.function.arguments); console.log(call.function.name, args); } ``` --- ## 2. Run your own gateway (advanced) If 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?](#3-interested-in-operating-a-gateway) below. Full deployment instructions are in [Run your own gateway](gateway-developer-quickstart.md). --- ## 3. Interested in operating a gateway? 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](#11-pick-a-broker) 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](gateway-developer-quickstart.md). To request consideration for on-chain allow-listing, open a [GitHub issue](https://github.com/gonka-ai/gonka/issues/new?title=Gateway+allowlist+request) 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](https://gonka.ai/FAQ/), or join the [Discord server](https://discord.com/invite/RADwCT2U6R) for technical issues or security concerns. --- ## Create a new Gonka account # Create a new Gonka account To start using Gonka Network, you first need to create a Gonka Account. There are several ways to do this: - Via external wallet (Keplr, Cosmostation, Fox Wallet) - Via `inferenced` CLI tool > **Bridge 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](../cross-chain-transfers/ethereum-bridge/addresses-and-keys.md) 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: - With the `inferenced` CLI tool - In Keplr using the “Connect with Google” flow Step-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](https://foxwallet.com/){target=_blank}. === "External wallet" === "I do not have an external wallet" === "Keplr mobile app" Go to [the official Keplr website](https://www.keplr.app/){target=_blank} 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. !!! note "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](../cross-chain-transfers/ethereum-bridge/addresses-and-keys.md) 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. === "Keplr browser extension" Go to [the official Keplr website](https://www.keplr.app/){target=_blank} and click "Get Keplr wallet". Choose an extension for your browser. Add the selected extension to your browser. === "Firefox" === "Google Chrome" After 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. !!! note "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](../cross-chain-transfers/ethereum-bridge/addresses-and-keys.md) 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. ??? note "Optional: How to add an additional Gonka account in Keplr wallet — click to view steps" Open 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. !!! note "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](../cross-chain-transfers/ethereum-bridge/addresses-and-keys.md) 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! === "Cosmostation browser extension" !!! note "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](../cross-chain-transfers/ethereum-bridge/addresses-and-keys.md) for details. Get [Cosmostation Wallet browser extension](https://cosmostation.io/products/application). 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). === "I have an external wallet" === "Keplr mobile app" !!! note "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](../cross-chain-transfers/ethereum-bridge/addresses-and-keys.md) 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. === "Keplr browser extension" !!! note "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](../cross-chain-transfers/ethereum-bridge/addresses-and-keys.md) 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”](#add-gonka-network-to-your-keplr-wallet)). Go to [the official Keplr website](https://www.keplr.app/){target=_blank} and click "Get Keplr wallet". Choose an extension for your browser. Add the selected extension to your browser. === "Firefox" === "Google Chrome" After 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. #### Add Gonka network to your Keplr wallet 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. === "Cosmostation browser extension" !!! note "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](../cross-chain-transfers/ethereum-bridge/addresses-and-keys.md) for details. Install the [Cosmostation Wallet browser extension](https://cosmostation.io/products/application) if you haven't already (if you have the extension installed, go to the step ["Add Gonka network to your Cosmostation wallet"](#add-gonka-network-to-your-cosmostation-wallet)). Add the extension to your browser. Open the Cosmostation extension and log in to your existing wallet. #### Add Gonka network to your Cosmostation wallet 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. #### View your Gonka private key 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). === "Via `inferenced` CLI tool" 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](https://github.com/gonka-ai/gonka/releases)). !!! note "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: ```bash export ACCOUNT_NAME= export NODE_URL= ``` - Replace `` with your chosen account name. ??? note "Things to know about account names" 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. - Replace `` with a random Node URL. You can either: - Use one of the **genesis nodes** from the list below. - Fetch the **current list of active participants** and select a random node. Do not forget to write it down, you will need it in the next step. ??? note "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. ??? note "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 nodes" Set the `NODE_URL` to one of the genesis nodes: ```bash title="Genesis Node List" http://36.189.234.237:17241 https://node1.gonka.ai:8443 https://node2.gonka.ai:8443 http://47.236.26.199:8000 http://47.236.19.22:18000 http://gonka.spv.re:8000 ``` === "Current list of active participants" Alternatively, 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: === "Link" [https://node2.gonka.ai:8443/v1/epochs/current/participants](https://node2.gonka.ai:8443/v1/epochs/current/participants) === "Command" ```bash curl https://node2.gonka.ai:8443/v1/epochs/current/participants ``` Download the `inferenced` CLI tool (the latest `inferenced` binary for your system is [here](https://github.com/gonka-ai/gonka/releases)). ??? note "Enabling Execution on Mac OS" On macOS, after downloading the `inferenced` binary, you may need to manually enable execution permissions. Follow these steps: 1. Open a terminal and navigate to the directory where the binary is located. 2. Run the following command to grant execution permission: ``` chmod +x inferenced ``` 3. Try running `./inferenced --help` to ensure it's working. 4. If you see a security warning when trying to run `inferenced`, go to System Settings → Privacy & Security. 5. Scroll down to the warning about `inferenced` and click "Allow Anyway". You can create an account with the following command: ```bash ./inferenced keys add "$ACCOUNT_NAME" ``` Make sure to securely save your passphrase — you'll need it for future access. This command will: - Generate a keypair - Save it to `~/.inference` - Return your account address, public key, and mnemonic phrase (store it securely in a hard copy as well!) ```bash - address: name: ACCOUNT_NAME pubkey: '{"@type":"...","key":"..."}' type: local ``` You 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. - Whoever has the private key controls the wallet. - If you lose it, you lose access. - If someone else gets it, they can take your funds. So the private key must always be stored securely and never shared with anyone. ```bash ./inferenced keys export $ACCOUNT_NAME --unarmored-hex --unsafe ``` To retrieve a list of all locally stored accounts, execute the following command: ``` inferenced keys list [--keyring-backend test] ``` Now 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. --- ## Getting Started with the Dashboard # Getting Started with the Dashboard 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: - **Preview Mode** — explore a dashboard and view network data without creating an account. - **Full Mode** — unlock the complete feature set by connecting your own wallet. === "**Preview Mode**" If you want to explore the network or see real-time inference metrics before setting up your own account, follow these steps: 1. Here is the list of genesis nodes. Choose a random node from the list below and open it in a new browser window/tab. - [http://36.189.234.237:17241](http://36.189.234.237:17241) - [https://node1.gonka.ai:8443](https://node1.gonka.ai:8443) - [https://node2.gonka.ai:8443](https://node2.gonka.ai:8443) - [http://47.236.26.199:8000](http://47.236.26.199:8000) - [http://47.236.19.22:18000](http://47.236.19.22:18000) - [http://gonka.spv.re:8000](http://gonka.spv.re:8000) ??? note "Alternative: fully decentralized way to choose a random node" Open the Hosts list: [http://node2.gonka.ai:8443/v1/epochs/current/participants](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. 2. Once opened, you’ll see real-time data streamed directly from the Host’s node. !!! note "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](https://gonka.ai/wallet/dashboard/#__tabbed_1_2). === "**Full Mode**" First, open the dashboard using Preview Mode. Once you’ve accessed it, continue with the instructions below to enable all features. ### 1. Access Gonka Account To unlock the full functionality of the dashboard, you need a Gonka account. - Already have one? Proceed to the ["Set Up External Wallet"](https://gonka.ai/wallet/dashboard/#2-set-up-external-wallet) section below. - New user? [Create a Gonka account](https://gonka.ai/wallet/create-account/) first, then return here. ### 2. Set Up External Wallet To interact with Dashboard through your wallet, it is recommended to use [Keplr](https://www.keplr.app/){target=_blank} (a browser extension wallet built for Cosmos-based chains). ??? note "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. - If you have a Keplr wallet browser extension, proceed to the ["Connect wallet"](https://gonka.ai/wallet/dashboard/#3-connect-wallet) section. - If you haven't set it up yet, follow the steps below. Install an extension for your browser. Go to [the official Keplr website](https://www.keplr.app/){target=_blank} and click "Get Keplr wallet". Choose an extension for your browser. Add the selected extension to your browser. === "Firefox" === "Google Chrome" After 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. ??? note "Important note on wallet-bridge compatibility" The 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: - With the `inferenced` CLI tool - In Keplr using the “Connect with Google” flow These are the recommended and supported options for users who need Ethereum bridge compatibility. See [Create a Gonka account](https://gonka.ai/wallet/create-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! ### 3. Connect wallet 3.1. Open Gonka dashboard following the [preview mode](https://gonka.ai/wallet/dashboard/#__tabbed_1_1) 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. ??? note "Optional: How to add an additional Gonka account in Keplr wallet — click to view steps" Open 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. ??? note "Important note on wallet-bridge compatibility" The 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: - With the `inferenced` CLI tool - In Keplr using the “Connect with Google” flow These are the recommended and supported options for users who need Ethereum bridge compatibility. See [Create a Gonka account](https://gonka.ai/wallet/create-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! --- ## Pricing # Pricing 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](../developer/quickstart.md#11-pick-a-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. ## Pricing Mechanism - The system monitors usage of every model on a per-block basis. - For each model: - If utilization is above the target → price increases. - If utilization is below the target → price decreases. - Adjustments are bounded by a maximum per-block increase/decrease rate to maintain stability. - Prices are expressed directly in coins. ## Price Adjustment Algorithm 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. ### Stability Zone Model 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: 1. **Current Utilization Calculation**: At the end of each block, the system calculates the recent utilization based on inference requests processed in the current block and recent block history versus estimated network capacity. 2. **Stability Zone Check**: If utilization is between 40% and 60%, no price adjustment occurs, maintaining price stability during normal network operation. 3. **Price Adjustment**: If utilization is below 40%, prices decrease to encourage more usage. If utilization is above 60%, prices increase to moderate demand. 4. **Linear Price Adjustment**: Price changes are directly proportional to utilization deviation from the stability zone, with the elasticity parameter determining the maximum change at extreme utilization levels (0% or 100%). > **** The price calculation follows this formula, similar to Ethereum's EIP-1559, but calculated separately for each model: ``` // Calculate per-model utilization and pricing for each_model in active_epoch_models: model_capacity = get_cached_capacity(model_id) // from capacity/{model_id} KV store model_utilization = model_tokens_processed_in_recent_blocks[model_id] / model_capacity if model_utilization >= 0.40 and model_utilization <= 0.60: // Stability zone - no price change new_model_price[model_id] = previous_model_price[model_id] else if model_utilization < 0.40: // Below stability zone - decrease price utilization_deficit = 0.40 - model_utilization adjustment_factor = 1.0 - (utilization_deficit * price_elasticity) new_model_price[model_id] = previous_model_price[model_id] * adjustment_factor else: // Above stability zone - increase price utilization_excess = model_utilization - 0.60 adjustment_factor = 1.0 + (utilization_excess * price_elasticity) new_model_price[model_id] = previous_model_price[model_id] * adjustment_factor // Ensure price never goes below 1 nicoin per token new_model_price[model_id] = max(new_model_price[model_id], min_per_token_price) ``` With the default elasticity of 0.05, this means for each model independently: - Maximum price change: 2% per block per model (when model utilization reaches 0% or 100%) - At 20% model utilization: 1% price decrease per block for that model - At 80% model utilization: 1% price increase per block for that model - Price floor: Never drops below 1 nicoin to prevent zero-cost scenarios and maintain network economics - Independent pricing: Each model's price adjusts based on its own demand and capacity The minimum price of 1 nicoin serves as a technical and economic safeguard: - Prevents computational issues with zero pricing - Ensures participants always receive minimal compensation - Maintains network incentive structure even during extremely low demand - Uses the smallest denomination unit, making it effectively negligible while preventing edge cases ## Query current pricing The current network pricing configuration can be queried from any active node. ``` curl http://node2.gonka.ai:8000/v1/governance/pricing | jq ``` Example response: ``` % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 175 100 175 0 0 315 0 --:--:-- --:--:-- --:--:-- 314 { "unit_of_compute_price": 100, "models": [ { "id": "MiniMaxAI/MiniMax-M2.7", "units_of_compute_per_token": 10000, "price_per_token": 1 } ], "dynamic_pricing_enabled": true } ``` ## Supported denominations 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? | Ratio | |--------|----------------------------------|-----------|--------------------------------------| | `ngonka` | Base unit used on the network | Yes | 1 | | `gonka` | Human-readable display unit | No | 1 `gonka` = 1,000,000,000 `ngonka` | ## Benefits and Economic Impacts The dynamic pricing system provides several economic and operational benefits: - **Per-Model Market Efficiency**. Automatic price discovery for each AI model ensures that inference costs reflect true demand and supply conditions for specific models, leading to more efficient resource allocation and fair pricing that accounts for different computational requirements and popularity levels. - **Model-Specific Network Stability**. By targeting optimal utilization levels per model, the system prevents both network congestion for popular models and underutilization for specialized models, maintaining consistent service quality across the entire model portfolio. - **Enhanced Participant Incentives**. Dynamic pricing creates stronger economic incentives for participants to: - Support diverse model portfolios to capture different pricing opportunities - Maintain high-performance nodes for resource-intensive models - Optimize their resource allocation across models based on demand patterns - Remain online during peak demand periods for their supported models - **Model-Aware Developer Experience**. Predictable per-model pricing algorithms combined with the grace period provide developers with: - Better cost forecasting capabilities for specific models - Clear economic signals about model demand and resource requirements - Flexibility to choose optimal models for their use cases - Early-stage development opportunities without cost barriers across all models ## References - [Tokenomics V2 Proposal: Dynamic Pricing](https://github.com/gonka-ai/gonka/blob/dl/tokenomics-v2/proposals/tokenomics-v2/dynamic-pricing.md) - [Dynamic Pricing Task Plan](https://github.com/gonka-ai/gonka/blob/dl/tokenomics-v2/proposals/tokenomics-v2/dynamic-pricing-todo.md) --- ## Wallet & Transfer Guide # Wallet & Transfer Guide 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](https://gonka.ai/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](https://gonka.ai/wallet/create-account/) first, then return here. Once you have access to your account, return to this guide to learn how to: - [Query Balance](https://gonka.ai/wallet/wallet-and-transfer-guide/#query-balance) - [Send Coins](https://gonka.ai/wallet/wallet-and-transfer-guide/#send-coins) - [Check Transaction Status](https://gonka.ai/wallet/wallet-and-transfer-guide/#check-transaction-status) ## Denominations 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? | Ratio | |--------|----------------------------------|-----------|--------------------------------------| | `ngonka` | Base unit used on the network | Yes | 1 | | `gonka` | Human-readable display unit | No | 1 `gonka` = 1,000,000,000 `ngonka` | ## Get Your Wallet Address Before you can check balances or send funds, you need to know your wallet address. ```bash inferenced keys list [--keyring-backend test] ``` This command lists all the wallet keys (accounts) you’ve created locally, along with their addresses and public keys. Example output: ``` - address: gonka1f85frkfw89cgpva0vgpyuldjgu6uhyd82hmjzr name: genesis pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"A+Qpbyhtsdl5N/6O6S/qJ9uvtbI7OFFsO5dcNrpEU0nv"}' type: local ``` Write down the address (used to receive coins and query balance). --- ## Query Balance To check your balance, ensure you have sufficient funds before transferring, or to verify a successful transfer, use the following command: ```bash inferenced query bank balances [--node ] ``` This shows how many coins are in your wallet. **Example:** ```bash inferenced query bank balances gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x --node http://node2.gonka.ai:8000/chain-rpc/ ``` --- ## Send Coins In 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. === "CLI" 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. ```bash inferenced tx bank send --chain-id gonka-mainnet [--node | --keyring-backend test] ``` !!! note `` 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:** ```bash inferenced tx bank send genesis gonka1a3jpdl4epdts64gns3a3fy9hjv2n9e3v7kxx0e 100ngonka --chain-id gonka-mainnet ``` === "Keplr (web-extension)" 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 address" Paste the receiver’s Gonka wallet address into the address field. Specify the amount you intend to send. === "If you do not know the receiver’s Gonka wallet address" 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. === "Keplr (mobile app)" 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 address" Paste the receiver’s Gonka wallet address into the address field. Specify the amount you intend to send. === "If you do not know the receiver’s Gonka wallet address" 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. --- ## Check Transaction Status 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: ```bash inferenced query tx --chain-id gonka-mainnet [--node ] ``` - Replace `` with the actual transaction hash you received from the transfer command. - You can optionally specify a node and chain ID if needed. **Example:** ```bash inferenced query tx 9712D97F127A1908C4DC4A1F4409AE380DC3BF0D662FA8D7E394422989CFFE2F --chain-id gonka-mainnet ``` If the transaction was successful, the output will contain: - `code: 0` — indicates success - A block `height` — the block in which the transaction was included - A `timestamp` — the time the block was committed - Details about the transaction message (e.g., `sender`, `receiver`, `amount`, `module`, `gas` used) **Sample response (truncated for clarity):** ```bash linenums="1" code: 0 txhash: 9712D97F127A1908C4DC4A1F4409AE380DC3BF0D662FA8D7E394422989CFFE2F height: "233596" timestamp: "2025-04-24T02:21:24Z" tx: ... body: messages: - '@type': /cosmos.bank.v1beta1.MsgSend from_address: gonka17ek5qgf94zsp024kppcyze37p95drr3wnt6jp3 to_address: gonka1ydt57pmnsd508ckw4fh6ey6h299v50zljpylla amount: - amount: "10" denom: ngonka ``` If the code is non-zero, the transaction has failed. Check the `raw_log` or info fields for error messages. --- # Community Documentation ## Gonka Network Development Roadmap # Gonka Network Development Roadmap 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. ## Strategic horizons Gonka is building toward three levels of scale. ### Horizon 1. Lead DeAI The nearest goal is to become the leading decentralized AI compute network. - largest H100-equivalent usable capacity among DeAI networks - multi-model and multi-modality network - real and reliable inference usage - strong developer and contributor activation - strong visibility among the AI infrastructure market, hosts, developers, and ecosystem partners. ### Horizon 2. Compete with neoclouds The next goal is to compete with AI infrastructure and neocloud providers such as Nebius, CoreWeave, Lambda and similar platforms. - 100K–250K H100 / accelerator-equivalent capacity - hundreds of billions of inference tokens per day - stable API, model catalog - enterprise / private inference paths. ### North Star. Frontier-scale decentralized compute The long-term direction for Gonka is to become a decentralized compute layer for frontier-scale AI infrastructure. - 1M+ H100 / accelerator-equivalent capacity - trillions of inference tokens per day - low-cost inference at global scale - trusted execution, verification, and privacy architecture - ability to train, fine-tune, and serve Gonka-native models. ## Foundation 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: - maintain the strategic roadmap and funding priorities; - fund protocol-adjacent, ecosystem, research, and infrastructure teams; - act as a legal counterparty for vendors, partners, and service providers that cannot work directly with a DAO; - define milestones, acceptance criteria, support periods, and handoff requirements; - coordinate technical review for protocol-facing work; - support host growth, developer adoption, model onboarding, security, bridges, market access, enterprise readiness, and training research; - publish transparent status for funded work. ## Roadmap tracks overview - **Multi-model network:** faster rollout of relevant models, optimized images, and model-specific PoC / rewards. - **Developer and AI agent access:** SDKs and adapters, OpenRouter / aggregator readiness, delegated wallets. - **Hosts and compute capacity growth:** deployment utilities, maintenance windows, optimized node images, AI inference ASIC / accelerator readiness. - **Network reliability and observability:** network status, incident console, alerts, and stability reports. - **Protocol security, hardening, and abuse prevention:** attack registry, regression suite, pricing / incentive checks, and vulnerability disclosure. - **Market access, liquidity, and bridges:** safe asset movement, DEX liquidity, and top-tier CEX readiness. - **Public sandbox and consumer-GPU testnet:** an environment for testing protocol upgrades, models, integration, lower-cost / consumer-grade GPU operators. - **Enterprise and privacy-sensitive workloads:** private inference gateway and TEE. - **Model training on a distributed network:** primitives and staged experiments for distributed training workloads. - **Market model:** market-based mechanisms for reward distribution and token pricing to align miner incentives with real usage. - **Marketing and demand activation:** demand generation, developer adoption, host acquisition, ecosystem partnerships, and public proof of real usage. - **Community development and internal coordination:** community research and coordination. ## Metrics affected by roadmap projects Every project in the roadmap should deliver measurable value against at least one of these metrics: - New compute capacity and host base growth - Host retention and confidence - Inference, developer activation and real network usage - Network reliability and trust - Inference scaling and usable capacity - Enterprise readiness - Lower support burden - Model training and research readiness - Market visibility and ecosystem trust *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. # Near-term priorities In the near term, Gonka should focus on network stability, predictable operation, and real inference usage. ### Core stability and reliability 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. ### Economic alignment review 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. ### Demand activation 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. # Mid- and long-term priorities ### Track 1. Multi-model network 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. #### Project 1. Model launch factory Ready-to-use model launch packages: runtime configurations, optimized images, benchmark scenarios, hardware requirements, readiness criteria, and rollback checklist. **Metrics:** - **PRIMARY:** inference, developer activation and real network usage. - **SECONDARY:** host retention and confidence. **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. #### Project 2. PoC, intents, weights, and rewards for model groups 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:** - **PRIMARY:** network reliability and trust. - **SECONDARY:** host retention and confidence. **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. --- ### Track 2. Developer and AI agent access Gonka becomes easier to integrate through APIs, SDKs, common developer tools, routing aggregators, and AI agents. #### Project 1. SDKs, adapters, and reference integrations A set of SDKs, adapters, wrappers, sample apps, and compatibility tests for popular developer toolchains. **Scope includes:** - OpenAI-compatible SDK flows - adapters / wrappers for selected AI frameworks, starting with LangChain / LangGraph - integration with Vercel AI SDK or a similar popular app-layer SDK - agent-runtime integrations - coding-tool scenarios. **Metrics:** - **PRIMARY:** inference, developer activation and real network usage. **What this gives the network:** A developer can integrate Gonka through familiar tools and examples instead of learning the internal mechanics of the network. #### Project 2. Adapter for OpenRouter / aggregators An adapter for OpenRouter and/or a similar routing aggregation layer. **Metrics:** - **PRIMARY:** inference, developer activation and real network usage. **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. #### Project 3. Delegated wallets and agent accounts 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:** - **PRIMARY:** inference, developer activation and real network usage. **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. --- ### Track 3. Hosts and compute capacity growth Network growth, simple onboarding, and host retention. #### Project 1. Hardware-neutral inference requirements 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:** - **PRIMARY:** inference scaling and usable capacity. - **SECONDARY:** new compute capacity and host base growth. **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. #### Project 2. Maintenance windows for hosts 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:** - **PRIMARY:** host retention and confidence. - **SECONDARY:** network reliability and trust. **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. #### Project 3. Optimized node images 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:** - **PRIMARY:** inference scaling and usable capacity. - **SECONDARY:** new compute capacity and host base growth; host retention and confidence. **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. --- ### Track 4. Network reliability and observability 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. #### Project 1. Network incident and stability center 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:** - **PRIMARY:** network reliability and trust. - **SECONDARY:** lower support burden; host retention and confidence. **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. #### Project 2. External testing lab 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:** - **PRIMARY:** network reliability and trust. - **SECONDARY:** host retention and confidence. **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. #### Project 3. Network documentation 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:** - **PRIMARY:** network reliability and trust. - **SECONDARY:** lower support burden; faster host onboarding. **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. --- ### Track 5. Protocol security, hardening, and abuse prevention #### Project 1. Attack registry and regression check suite A registry of known attack classes and automated checks that prevent these attacks from coming back in future versions. **Metrics:** - **PRIMARY:** network reliability and trust. - **SECONDARY:** enterprise readiness; host retention and confidence. **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. #### Project 2. Economic and incentive attack simulator 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:** - **PRIMARY:** network reliability and trust. **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. #### Project 3. Vulnerability disclosure program A public security process for reporting vulnerabilities: page, form, triage rules, severity categories, path from report to fix, and regression test. **Metrics:** - **PRIMARY:** network reliability and trust. - **SECONDARY:** enterprise readiness. **What this gives the network:** External researchers and community participants get a safe reporting path without exposing exploit details in public chats. --- ### Track 6. Market access and liquidity, and bridges Gonka needs a controlled path for token accessibility, liquidity, cross-chain asset movement, and exchange presence. #### Project 1. DEX launch and top-tier CEX readiness 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:** - **PRIMARY:** network reliability and trust. **What this gives the network:** Gonka gets a clear exchange-access strategy and improves token accessibility. #### Project 2. Cross-chain routes Supported routes for moving assets between Gonka and external networks. **Metrics:** - **PRIMARY:** developer activation and real network usage. **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. #### Project 3. Contract security and cross-chain interop 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:** - **PRIMARY:** network reliability and trust. - **SECONDARY:** enterprise readiness. **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. --- ### Track 7. Public sandbox and consumer-GPU testnet Gonka gets safe environments for testing models, integrations, settings, Devshard scenarios, and consumer-GPU participation without risk to mainnet. #### Project 1. Public testing sandbox 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:** - **PRIMARY:** developer activation and real network usage. - **SECONDARY:** network reliability and trust. **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. --- ### Track 8. Enterprise and privacy-sensitive workloads Gonka should support scenarios where a user or application does not want to reveal input data to the host. #### Project 1. TEE-backed private inference 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:** - **PRIMARY:** enterprise readiness. - **SECONDARY:** network reliability and trust; inference, developer activation and real network usage. **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. #### Project 2. Private inference access layer An access layer and first pilot scenarios for private inference on top of TEE-capable nodes. **Initial pilot scenarios:** - private RAG - secure document processing - internal AI agents - inference with sensitive user data - enterprise API flow through TEE-capable nodes. **Metrics:** - **PRIMARY:** enterprise readiness. **What this gives the network:** Enterprise users get a practical path to start using Gonka for privacy-sensitive workloads. --- ### Track 9. Model training on a distributed GPU network Gonka should develop training as a separate class of workloads on top of shard infrastructure. #### Project 1. Training shard primitives 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:** - **PRIMARY:** model training and research readiness. **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. #### Project 2. Decentralized training and AI safety research 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:** - **PRIMARY:** model training and research readiness. **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. --- ### Track 10. Market model 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. #### Project 1. Market-based reward distribution 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:** - **PRIMARY:** real network usage and GPU utilization. - **SECONDARY:** network reliability and trust. **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. #### Project 2. Demand-based per-model token pricing 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:** - **PRIMARY:** real network usage. - **SECONDARY:** network reliability and trust. **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. #### Project 3. Reward distribution proportional to work-cons earnings 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:** - **PRIMARY:** real network usage. - **SECONDARY:** host retention and confidence. **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. --- ### Track 11. Marketing, demand activation, and ecosystem growth 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. #### Project 1. Target audience research Quantitative and qualitative research: - developers and AI teams that need inference; - hosts and hardware suppliers that provide compute capacity; - enterprise and ecosystem partners that can bring real workloads; - protocol contributors; - market participants and external observers that need clear evidence of traction, usage, and network maturity. 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:** - **PRIMARY:** people reached and research data collected, first successful cases we can tell in public, time to first valuable action. **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. #### Project 2. Demand activation and developer usage 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:** - **PRIMARY:** inference, developer activation and real network usage. - **SECONDARY:** paid conversion after credits, retained usage after subsidies, active applications after 30 / 60 / 90 days, and repeat API usage. **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. #### Project 3. Host growth and usable compute capacity 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:** - **PRIMARY:** new compute capacity and host base growth. - **SECONDARY:** inference scaling and usable capacity; host retention and confidence. **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. #### Project 4. Project visibility through publications on credible platforms 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:** - **PRIMARY:** number and tier of publications on credible platforms. - **SECONDARY:** search visibility for target queries on Google and AI search systems. **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. #### Project 5. Ecosystem narrative, distribution, and public trust 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:** - **PRIMARY:** community growth, market visibility, and network trust. - **SECONDARY:** referral traffic, inbound partner interest, analyst mentions, backlinks, citations, media invitations, event invitations. **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. --- ### Track 12. Community development and internal coordination 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. #### Project 1. Community research and contributor insights 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:** - **PRIMARY:** contributor retention and recurring ecosystem participation. - **SECONDARY:** identification and resolution of major ecosystem coordination bottlenecks. **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. #### Project 2. Internal communication and coordination channels 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:** - **PRIMARY:** reduction of ecosystem communication fragmentation. - **SECONDARY:** feedback on ecosystem communication and coordination quality. **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. --- ## Rules for external teams and funded work **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. --- ## Gonka Restitution Committee # Gonka Restitution Committee ## The Problem - The protocol changes and sometimes participants suffer losses due to bugs and unpredictable behavior - It would be fair to compensate participants for their losses - Not all losses occur because of the protocol; such losses are not compensated - A governance wallet was created to make such compensations, among other things, using unclaimed rewards - The current compensation mechanism is through voting, but: - Only the team can prepare compensation votes at the moment - If a bug affects a small number of participants, it's difficult to draw attention to the problem and gather quorum - The task of triaging issues falls on the team ## Proposal Therefore, I propose forming a compensation committee that: - Collects information and accepts compensation claims from participants - Pre-filters compensations that are related to the protocol - Groups incidents and periodically brings them to a general vote ## How this can be organized - A chat of 10-15 people together with the Gonka team - The team observes and helps answer questions, but decisions are made by committee members - Initially the team helps make proposals, then we do it ourselves - Initial committee composition — everyone present in this chat. Later we decide together who else to add - Discussion is conducted in English to be inclusive ## Requirements for participants - Have technical understanding of how the network works - No more than one participant from one segment - Have the ability and motivation to participate - We already have the first compensation proposal (epochs 132 and 133) and several other participants who had issues; we can test the process with this - Everything else we'll figure out as we go ## Join If you have the opportunity and desire to be part of the committee — please confirm your participation. **Основатель:** [@votkon](https://telegram.me/votkon) --- ## Governance Support Committee # Governance Support Committee ## Роль комитета Комитет поддержки самоуправления является сервисным комитетом. Его задача — помогать делать governance процесс понятным, прозрачным и удобным для авторов пропозалов, хостов и сообщества. Комитет не является политическим, продуктовым или лоббистским органом. Комитет не делает оценочных суждений о качестве пропозалов, их содержании, авторах и результатах исполнения. Роль комитета — поддерживать процесс, а не формировать мнение сообщества или хостов. ## Задачи комитета - Помощь с подготовкой и запуском on-chain голосований - Помощь авторам в инициировании обсуждения proposals - Организация AMA для авторов пропозалов - Контроль предоставления публичных статусов по финансируемым проектам - Отслеживание сроков и next steps, которые были публично заявлены или оговорены в принятом пропозале - Информирование хостов и сообщества о текущем статусе пропозалов ## Стартовый состав комитета - [@AntonLooch](https://telegram.me/AntonLooch) - [@DmitriyV00](https://telegram.me/DmitriyV00) - [@MageDeFi](https://telegram.me/MageDeFi) - [@nikkolet](https://telegram.me/nikkolet) - [@OpenMindedPerson](https://telegram.me/OpenMindedPerson) - [@maksimenkoff](https://telegram.me/maksimenkoff) - [@paranko](https://telegram.me/paranko) - [@zotov_daniil](https://telegram.me/zotov_daniil) - [@dem_ww](https://telegram.me/dem_ww) --- ## **Устав Комитета поддержки самоуправления** > **Auto-sync:** this document is automatically synchronized from [Google Docs](https://docs.google.com/document/d/1xPmMFoXhhVXeTTvGwQ_tGCcZJgIwViqok-H08yod_Pk/edit) every hour. Direct edits in the repository will be overwritten. # **Устав Комитета поддержки самоуправления** ## **1. Роль комитета** Комитет поддержки самоуправления является сервисным комитетом. Его задача - помогать делать governance процесс понятным, прозрачным и удобным для авторов пропозалов, хостов и сообщества. Комитет не является политическим, продуктовым или лоббистским органом. ## **2. Нейтральность** Комитет не делает оценочных суждений о качестве пропозалов, их содержании, авторах и результатах исполнения. Комитет не определяет, является ли пропозал хорошим или плохим, полезным или вредным, качественно или некачественно исполненным. Роль комитета - поддерживать процесс, а не формировать мнение сообщества или хостов. ## **3. Задачи комитета** Комитет может заниматься: - помощью с подготовкой и запуском on-chain голосований; - помощью авторам со списком каналов, где стоит разместить информацию о пропозале; - координацией анонсов в чатах, на порталах и в community-каналах; - организацией AMA для авторов пропозалов; - контролем предоставления публичных отчетов; - отслеживанием сроков и next steps, которые были публично заявлены или оговорены в принятом пропозале; - информированием хостов и сообщества о текущем статусе пропозалов. ## **4. Принципы работы** Комитет работает на основе: - нейтральности; - прозрачности; - публичной коммуникации; - равного отношения к авторам пропозалов; - саморегулирования через внутренние голосования. ## **5. Принятие решений** Комитет является саморегулирующимся. Внутренние решения принимаются голосованием членов комитета. Каждый член комитета имеет один голос. Голосование считается состоявшимся, если в нем приняли участие не менее 1/3 от общего числа членов комитета. Стандартный срок голосования составляет 24 часа. Голосование может быть завершено раньше, если один из вариантов набрал достаточное количество голосов и итог уже не может измениться с учетом оставшихся голосов. Решение считается принятым, если за него проголосовало простое большинство участвующих в голосовании членов комитета. ## Вопросы: 1. Что является главным продуктом комитета? Что мы должны получить на выходе и как поймем, что комитет выполнил свою роль? Например: пропозал готовый к голосованию хостов - понятный, оформленный по стандарту, публично представленный сообществу и хостам, а принятый пропозал - отслеженный до результата с отчетами. Варианты можно еще накидать. Также будет множество подпродуктов у комитета - промежуточные результаты. Но главный продукт должен быть какой-то один, то что является конечным результатом всей деятельности комитета. 2. Как мы можем измерить главный продукт, посчитать его? Какими способами? Хорошо бы применить к подсчету еще и чек-лист проверки пропозала, который выкатили на голосование (соответствует нашему продукту или нет, засчитываем себе в заслуги или нет). > **Устав и границы: процесс vs оценка.** > > **Пайплайн proposal от идеи до голосования.** > > **Первое окно: куда писать и кто отвечает.** > > **Роли внутри комитета.** > > **Dashboard + отчётность по уже профинансированным proposal.** > > --- ## Index --- ## Продуктовый комитет # Продуктовый комитет Продуктовый комитет помогает хостам оценивать ценность, риски и roadmap-соответствие пропозалов. ## Назначение Продуктовый комитет помогает голосующим хостам не пропустить ценные пропозалы и вовремя обратить внимание на потенциально опасные для сети инициативы. Решения комитета носят рекомендательный характер. Комитет не обещает реагировать на все пропозалы подряд. **Ответственный:** [@paranko](https://telegram.me/paranko) ## Фокус оценки Комитет в первую очередь смотрит на инициативы, которые: - Могут принести значимую пользу сети и важны для протокола, хостов, разработчиков и пользователей инференса. - Отражены в актуальном roadmap. - Могут создать существенные риски для сети. ## Фреймворк Для оценки используется **Proposal Scoring Framework v1** — первая версия фреймворка для продуктовых и технических пропозалов. По итогам рассмотрения комитет публикует заполненную оценку в каналах сообщества и направляет её хостам. ## Формат работы - Заседания проходят с видеозаписью. - Записи публикуются на YouTube-канале комитета. - По сильным инициативам комитет помогает подсветить ценность через рекомендацию и публичные AMA. - По потенциально вредным или подозрительным пропозалам готовится отдельная реакция и рекомендации. - Для изменений roadmap используются открытые встречи в формате **GIP — Gonka Improvement Protocol**. ## Состав **Контрибуторы:** - [@ak986](https://telegram.me/ak986) - [@qDanik](https://telegram.me/qDanik) - [@dem_ww](https://telegram.me/dem_ww) - [@baridoka](https://telegram.me/baridoka) **Хосты:** - [@akamitch](https://telegram.me/akamitch) - [@MageDeFi](https://telegram.me/MageDeFi) - [@OpenMindedPerson](https://telegram.me/OpenMindedPerson) - [@Otli4nik_A](https://telegram.me/Otli4nik_A) - [@votkon](https://telegram.me/votkon) - [@maksimenkoff](https://telegram.me/maksimenkoff) - [@SysManHF](https://telegram.me/SysManHF) - [@paranko](https://telegram.me/paranko) --- --- ## Go-to-Market Committee # Go-to-Market Committee Комитет помогает развивать go-to-market-направление сети: от формулирования задач для внешних исполнителей и координации с ними — до оценки маркетинговых пропозалов, проверки экспертизы команд и контроля качества исполнения. ## Как работает комитет - **Регулярные созвоны** раз в неделю + опциональные дополнительные созвоны - **Оценка пропозалов** проводится кворумом, в который входит не менее 3-х членов комитета. Члены кворума готовят письменные заключения, потом обсуждают их на совместном созвоне — и выносят заключение. Не согласные с мнением большинства могут выразить "особое мнение", которое также войдет в заключение. - **Чаты с исполнителями**, в которые могут добавиться все желающие - **Дедлайн на рассмотрение:** 2 недели с момента поступления предложения ## При оценке пропозалов комитет старается ответить на вопросы - Какие есть преимущества и проблемы у предложения? - В чем именно экспертны исполнители, что именно нам у них стоит выспросить / купить и по какой цене? - Хорошо ли подходит исполнитель для выстраивания долгосрочного взаимодействия? Как воспринимает аргументы? Какая история его работы с предыдущими заказчиками? ## Поддержка сильных инициатив По сильным и полезным инициативам комитет помогает: - Подсветить их ценность для сети через рекомендацию пропозала и публичные AMA-сессии с командами - Доработать пропозал так, чтобы он был наверняка принят ## Итоги рассмотрения К текущему моменту комитет рассмотрел все недавно обсуждавшиеся proposals, которые потенциально могут поступить в сеть. Итоги рассмотрения будут опубликованы позже. ## Активные члены К следующим членам комитета можно приходить с вопросами и предложениями-пропозалами: - [@arsenm1](https://telegram.me/arsenm1) - [@pavelp221](https://telegram.me/pavelp221) - [@MageDeFi](https://telegram.me/MageDeFi) - [@empro3](https://telegram.me/empro3) - [@telega1547](https://telegram.me/telega1547) - [@andre_arkhi](https://telegram.me/andre_arkhi) - [@vkatsman](https://telegram.me/vkatsman) В состав комитета входят опытные CMO в продуктовой и web3-сферах, B2B-биздевы, журналисты и другие профессионалы. Любой хост может присоединиться в качестве наблюдателя и, возможно, участника-консультанта — для этого нужно написать [@vkatsman](https://telegram.me/vkatsman). --- 📋 [Полный состав комитета и подробные профили](./members.md) --- ## Go-to-market committee: состав и экспертиза # Go-to-market committee: состав и экспертиза ## Viktor Katsman - **LinkedIn:** [Viktor Katsman](https://www.linkedin.com/in/viktor-katsman/) - **Telegram:** [@vkatsman](https://telegram.me/vkatsman) - Ex-Yandex, PhD; специалист по go-to-market технических продуктов на ранних стадиях в AI, EdTech и финансах - В 2019 году увеличил годовую выручку Яндекс.Маркета на $34M за счет перестроения AI-алгоритма ранжирования - Прошел калифорнийскую программу Founders University по строительству и масштабированию early-stage стартапов - Развил собственный проект [Inream.com](https://inream.com) до финансово устойчивой модели. - Имеет практический опыт привлечения платящих клиентов в early-stage стартапы – как в B2B, так и в B2C - Исследует low-cost marketing и недорогие методы маркетинговых исследований для early-stage продуктов - Автор Track 11: Marketing, demand activation, and ecosystem growth в принятой сообществом Roadmap - Инициировал создание Go-to-market committee - В Gonka фокусируется на проверке спроса, customer development, маркетинговой аналитике и масштабируемом использовании inference **Ключевая экспертиза:** - Early-stage GTM для технических продуктов - Demand validation и PMF-проверка - Customer development и market research - Маркетинговая аналитика и построение воронок - Привлечение платящих клиентов в B2B и B2C - Low-cost marketing и growth experiments - Demand activation для Gonka inference --- ## Arseny Myakotnikov - **LinkedIn:** [Arseny Myakotnikov](https://www.linkedin.com/in/arseny-myakotnikov-5a4341177/) - **Telegram:** [@arsenm1](https://telegram.me/arsenm1) - 10+ лет в маркетинге, из них 7+ в web3; в крипте с начала 2017 года — на уровне CMO для десятков финтех-, web3- и AI-продуктов - Привлёк $300M+ AUM для DeFi хедж-фонда, масштабировав базу с ~1K до 15K+ активных пользователей - Сейчас CMO венчурной студии dome.net — запускает web3- и B2B SaaS-продукты - Управлял бюджетами $100K+ и командами до 12 человек - Фаундер: запустил собственный InfoFi-продукт (2k MAU) и Jeet Trade — трейдинг-платформу на Solana ($3M+ оборот, 600+ пользователей) - Как CMO [Rivo.xyz](https://rivo.xyz) (DeFi-маркетплейс) привёл 10K+ активных пользователей, $10M+ объёма инвестиций и 30+ партнерств с крупными DeFi-протоколами (Avalanche, GMX, Pendle); token presale с ATH-капитализацией $8M и 15K держателей токена - Большой нетворк в крипте: закрытые alpha-сообщества, инфлюенсеры/KOL, DAO, DeFi-проекты, маркетинговые подрядчики, экосистемные проекты **Ключевая экспертиза:** - Full-cycle GTM для web3- и AI-продуктов - Перформанс- и influence-маркетинг, PR, content, SEO/GEO - Community, partnerships и token launches/TGE - Маркетинговая воронка и аналитика - User acquisition в B2B и B2C - Запуск продуктов с нуля (0→1) и создание маркетинг AI-агентов --- ## Andre Antares - **LinkedIn:** [Andre Antares](https://www.linkedin.com/in/andre-antares-9063ba15b) - **Telegram:** [@andre_arkhi](https://telegram.me/andre_arkhi) - Отвечает за контент и маркетинг в Ancapex, сервисе майнинга для Gonka - За последние полгода команда с нуля построила активное Telegram-сообщество - Видеоконтент проекта собрал более 1 млн просмотров на YouTube, Instagram и TikTok - Команда привлекла больше $200k депозитов в майнинг Gonka - С 2018 года занимается маркетингом Web3-проектов - В портфолио – больше 20 проектов в crypto, DeFi и AI - Запускал DeFi-протоколы, yield-агрегаторы, AI-агентов, token sale и NFT-коллекции - Отвечал за привлечение пользователей, инвесторов, ликвидности и торговых объемов - Один из последних кейсов – yield-агрегатор Rivo, где было привлечено более $9M объема в депозитах и свопах на платформе - Имеет опыт переговоров с партнерами, кросс-маркетинговых активностей и работы с инфлюенсерами – от подбора под целевую аудиторию до сценариев для видео и интервью **Ключевая экспертиза:** - Web3-маркетинг и growth - Контент-стратегия - Видео-контент и social media distribution - Работа с инфлюенсерами - Кросс-маркетинг и партнерства - DeFi, yield-агрегаторы и token sale - Привлечение пользователей, ликвидности и торговых объемов - Community growth для crypto-продуктов --- ## Hleb D - **Telegram:** [@telega1547](https://telegram.me/telega1547) - Сооснователь Gonka24, сервиса-брокера инференса Gonka - Имеет опыт создания и продвижения собственных проектов и бизнесов – от digital products до e-commerce - Работал с окупаемой таргетированной рекламой в Facebook, тестированием гипотез, воронками, позиционированием и привлечением клиентов. - Имеет практический опыт B2B lead generation - Сейчас занимается поиском B2B-лидов для Gonka24 и общается с потенциальными клиентами - Собирает обратную связь с рынка: клиентские боли, возражения и реальные сценарии использования - В Go-to-market committee приносит практические инсайты "с полей" о том, что нужно B2B-клиентам, какие у них возражения и как формулировать предложения для рынка **Ключевая экспертиза:** - B2B-лидогенерация для inference-продуктов - Inference brokerage - Работа с потенциальными B2B-клиентами - Сбор рыночной обратной связи - Анализ клиентских болей, возражений и use cases - Воронки, таргетированная реклама и тестирование гипотез --- ## Mikhail - **Telegram:** [@empro3](https://telegram.me/empro3) - PhD track в США по business economics and finance; фокус – corporate governance - Отвечал за региональный маркетинг партнеров NVIDIA, включая запуск новых GPU и ускорителей физики - Продвигал SSD / OCZ до лидерской позиции в регионе: до 70% доли рынка на пике, около $10M квартального оборота и $1.5M годового маркетингового бюджета - По кейсу OCZ достиг первого места по медиаактивности и узнаваемости бренда - Помогал ГМИИ им. Пушкина в становлении программы лояльности - Помогал Seattle Opera привлекать молодежную аудиторию последние 4 сезона подряд; в 2026 году проект достиг лучшего результата за историю организации даже в абсолютных значениях **Ключевая экспертиза:** - Стратегический маркетинг - Маркетинг hardware и compute-инфраструктуры - Запуск и продвижение технологических продуктов - Работа с крупными маркетинговыми бюджетами - Рост узнаваемости бренда и медиаактивности - Институциональное развитие и corporate governance - Программы лояльности и развитие аудитории --- ## Eldar I - **Telegram:** [@MageDeFi](https://telegram.me/MageDeFi) - Операционный директор в пуле Gonka.Top - Отвечает за бизнес и операционную часть пула: onboarding участников, продажи, партнерскую программу, поддержку участников и внутренние процессы - До Gonka.Top 10 лет работал в компании с Митчем, где вырос от клиент-менеджера до исполнительного директора - Последние 3 года занимался майнингом биткоина, размещением в дата-центрах и изучением организации майнинг-инфраструктуры - Силен в выстраивании процессов, контроле статусов, сроков и договоренностей - Готовит понятные организационные документы, регламенты и помогает выстраивать коммуникацию между участниками - Основной фокус – операционное управление, процессы, коммуникация и сопровождение исполнения **Ключевая экспертиза:** - Операционное управление - Onboarding участников - Продажи и партнерские программы - Поддержка участников - Контроль статусов, сроков и договоренностей - Организационные документы и регламенты - Координация исполнителей и коммуникация между участниками - Майнинг-инфраструктура и дата-центры --- ## Timur Vyalshin - **Telegram:** [@lexti](https://telegram.me/lexti) - По образованию – инженер по качеству в автомобилестроении; 5 лет работал в automotive quality на заводе Hyundai - 4.5 года занимался YouTube / Telegram-каналом CryptoCommons - 1 год был advisor криптобиржи CoinW - Уже 5 лет управляет компанией как генеральный директор - Имеет практический startup-опыт - Может помогать с листингами на биржах – как бесплатными, так и платными - Может разрабатывать механики вовлечения новых участников и взаимодействовать с исполнителями пропозалов - Основной опыт – СНГ crypto-сегмент; международные контакты в основном через представителей бирж, в том числе по Азии **Ключевая экспертиза:** - Crypto-community и Telegram / YouTube-каналы - Листинги на биржах - Взаимодействие с crypto exchanges - Механики вовлечения участников - Координация исполнителей пропозалов - Операционное управление компанией --- ## Eugene Maksimenkov - **LinkedIn:** [Eugene Maksimenkov](https://www.linkedin.com/in/maksimenkoff/) - **Telegram:** [@maksimenkoff](https://telegram.me/maksimenkoff) - В Gonka с октября; получил первый в сети bounty за найденную уязвимость - Сделал несколько продуктов вокруг Gonka: кроссплатформенный кошелёк [wallet.gonka.vip](https://wallet.gonka.vip), tracker / explorer для майнеров [tracker.gonka.vip](https://tracker.gonka.vip) и площадку тендеров [vote.gonka.vip](https://vote.gonka.vip) - По его оценке, wallet.gonka.vip остается единственным нативным Gonka-кошельком для iOS и Android - Более 10 лет живет в США, Bay Area - Работал в Apple, Amazon, Meta, Robert Half и других компаниях - Основной профессиональный background – QA, testing, automation, mobile / web testing, analytics testing и project management - Сейчас развивает Dutiap – dating-приложение и AI-инструмент для оценки фото - В комитете готов помогать с технической оценкой marketing / GTM пропозалов: реалистичность продукта, качество реализации, security, mobile / web experience, аналитика и практический контекст США **Ключевая экспертиза:** - Техническая оценка marketing / GTM пропозалов - Security и поиск уязвимостей - QA, testing и automation - Mobile / web product experience - Analytics testing и точность данных - Разработка продуктов вокруг Gonka - AI-продукты и consumer apps - Практический контекст США --- ## Pavel Petko - **LinkedIn:** [Pavel Petko](https://www.linkedin.com/in/pavelpetko/) - **Telegram:** [@pavelp221](https://telegram.me/pavelp221) - Журналист и редактор Gonka Community Blog - Более 9 лет работает на стыке медиа, аналитики и бизнес-развития в независимой медийной организации - Founder & Publisher Racket One Insights – аналитического проекта, сфокусированного на исследованиях рынка в сфере спортивного спонсорства - Прошел программу по Media Management в Stockholm School of Economics in Riga - Через Gonka Community Blog работает с материалами об экосистеме, governance, use cases, AMAs, Roadmap и community activity - В Go-to-market committee готов помогать с медиа направлением: публичной коммуникацией, прозрачностью, PR / СМИ и объяснением процессов для сообщества - Готов помогать по направлениям, связанным с PR, освещением в СМИ, публикациями и медийной видимостью **Ключевая экспертиза:** - Медийная стратегия - Анализ данных и исследования рынка - PR и освещение в СМИ - Публичная коммуникация и объяснение процессов - Governance visibility - Медийная упаковка экосистемных инициатив --- ## Mikhail Chudinov - **LinkedIn:** [Mikhail Chudinov](https://www.linkedin.com/in/mikhail-chudinov/) - **Telegram:** [@akamitch](https://telegram.me/akamitch) - Более 20 лет опыта в администрировании серверов и высоконагруженных систем - Более 10 лет опыта управления IT-командами - Работал с высоконагруженными платформами в adult industry, финтехе, криптостартапах и доменной инфраструктуре, включая парковку около 100,000 доменов на saw.com - В Gonka с ноября 2025 года - Создал первый community pool Gonka.Top - Привлек около $1.3M в майнинг Gonka - В пике в пуле одновременно работали 53 сервера с конфигурацией 8×H100 - С декабря 2025 года ведет YouTube-канал Gonka.Top с новостным и образовательным контентом о Gonka - Канал собрал 146.6K просмотров органически, без платного трафика - Провел три интервью и организовал бесплатные коллаборации с небольшими AI YouTube-авторами - В комитете готов помогать с mining-side growth, привлечением участников в пул, технической коммуникацией и контентными форматами для сообщества **Ключевая экспертиза:** - Mining infrastructure и host economics - Администрирование серверов и высоконагруженные системы - Управление IT-командами - Community pool growth и привлечение майнеров - Привлечение капитала в майнинг - Органический YouTube-контент и образовательная дистрибуция - Интервью, коллаборации и работа с AI-креаторами - Объяснение сложных технических тем --- # On-Chain Proposals ## Community Pool # Community Pool 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 --- ## Community Pool (distribution module) **Address:** [`gonka1jv65s3grqf6v6jl3dp4t6c9t9rk99cd8h2rzwa`](https://gonka.gg/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](https://gonkadocs.com/proposals/proposals/2026-q2/42/)** — the planned Global Compute Sovereignty Summit was cancelled, and the proposer returned the allocated funds. See the [return instructions](https://gonkadocs.com/community/discussion/show-and-tell/1390-how-to-return-funds-to-the-community-pool-ibc-usdt/) for details.* **Inflow rate:** ~13,150 GNK/day (varies with block time, fee volume, and staking ratio). Verify on-chain ``` curl -s https://node3.gonka.ai/chain-api/cosmos/distribution/v1beta1/community_pool ``` --- ## Community Sale **Address:** [`gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2`](https://gonka.gg/address/gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2) Current balance: 17,500,000 GNK (~$10,500,000 USDT) · $764,075 USDT This address was created by **[proposal #14](/proposals/proposals/2025-q4/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-chain ``` curl -s https://node3.gonka.ai/chain-api/cosmos/bank/v1beta1/balances/gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2 ``` --- ## Gov Module (authority) **Address:** [`gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33`](https://gonka.gg/address/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-chain ``` curl -s https://node3.gonka.ai/chain-api/cosmos/bank/v1beta1/balances/gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33 ``` --- ## How Community Pool Spending Works 1. A governance proposal includes one or more funding messages — `MsgCommunityPoolSpend` (GNK/USDT from the Community Pool) or batch-vesting transfers (GNK from the Gov Module). 2. If the proposal **passes**, the Gov Module authority address executes the transfers. 3. USDT is held in the Community Pool as the IBC denom `ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4` and transferred via `MsgExecuteContract` (withdraw_ibc). **Key constraint:** No single key controls these funds — every spend requires a passed governance vote. --- ## Historical Funding 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](https://gonkadocs.com/proposals/proposals/2026-q3/82/) | 2026-07-10 | External Test Lab x Community DevNet | Community Pool | 80,000 | $88,000 | | [#77](https://gonkadocs.com/proposals/proposals/2026-q2/77/) | 2026-06-26 | Gonka PR Proposal for US/Global Regions | Community Pool | — | $75,000 | | [#76](https://gonkadocs.com/proposals/proposals/2026-q2/76/) | 2026-06-17 | Governance 16: devshard v2 and bounty payouts | Community Pool | — | $93,600 | | [#74](https://gonkadocs.com/proposals/proposals/2026-q2/74/) | 2026-06-12 | Gonka Labs: Maintaining Infrastructure, Improving Products,… | Community Pool + Gov Module | 330,000 | $70,000 | | [#68](https://gonkadocs.com/proposals/proposals/2026-q2/68/) | 2026-06-07 | Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovs… | Community Pool | — | $70,000 | | [#67](https://gonkadocs.com/proposals/proposals/2026-q2/67/) | 2026-06-05 | Kimi Restitution (epochs 265-276) | Gov Module | 946,509 | — | | [#65](https://gonkadocs.com/proposals/proposals/2026-q2/65/) | 2026-06-04 | TheSoul - Offer 2.3: Digital strategy (100,000 GNK) | Community Pool | 100,000 | — | | [#64](https://gonkadocs.com/proposals/proposals/2026-q2/64/) | 2026-06-04 | TheSoul - Offer 2.2: Analytics and attribution (28,000 GNK) | Community Pool | 28,000 | — | | [#63](https://gonkadocs.com/proposals/proposals/2026-q2/63/) | 2026-06-04 | TheSoul - Offer 2.1: Website and landings (10,000 USDT) | Community Pool | — | $10,000 | | [#62](https://gonkadocs.com/proposals/proposals/2026-q2/62/) | 2026-06-04 | TheSoul - Offer 1.3: Influencer pilot (50,000 USDT) | Community Pool | — | $50,000 | | [#61](https://gonkadocs.com/proposals/proposals/2026-q2/61/) | 2026-06-04 | TheSoul - Offer 1.2: Brandbook (20,000 USDT) | Community Pool | — | $20,000 | | [#60](https://gonkadocs.com/proposals/proposals/2026-q2/60/) | 2026-06-04 | TheSoul - Offer 1.1: Brand positioning (25,000 USDT) | Community Pool | — | $25,000 | | [#55](https://gonkadocs.com/proposals/proposals/2026-q2/55/) | 2026-05-23 | GRC Proposal #2 - Restitution (epochs 248-254) | Community Pool + Gov Module | 346,029 | — | | [#51](https://gonkadocs.com/proposals/proposals/2026-q2/51/) | 2026-05-15 | Support Gonka's presence at WebX Asia | Community Pool | — | $75,000 | | [#50](https://gonkadocs.com/proposals/proposals/2026-q2/50/) | 2026-05-09 | Retroactive bounty: open-source PoC throughput optimization… | Community Pool | 20,000 | — | | [#49](https://gonkadocs.com/proposals/proposals/2026-q2/49/) | 2026-05-07 | Gonka Media Dominance in TechL/AI with 5 AI Influencers | Community Pool | — | $45,000 | | [#46](https://gonkadocs.com/proposals/proposals/2026-q2/46/) | 2026-05-04 | Epochs 132-247 compensation payout from gov module (batch v… | Gov Module | 3,053,800 | — | | [#42](https://gonkadocs.com/proposals/proposals/2026-q2/42/) | 2026-04-19 | Support Gonka at Global Compute Sovereignty Summit | Community Pool | — | $10,000 | | [#39](https://gonkadocs.com/proposals/proposals/2026-q2/39/) | 2026-04-10 | Community Series Film — Why Gonka Exists | Community Pool | 31,250 | — | | [#33](https://gonkadocs.com/proposals/proposals/2026-q1/33/) | 2026-03-27 | Epochs 132-133 compensation payout from gov module | Community Pool + Gov Module | 27,906 | — | | [#32](https://gonkadocs.com/proposals/proposals/2026-q1/32/) | 2026-03-24 | Epoch 158 compensation payout from gov module (batch vestin… | Community Pool + Gov Module | 30,538 | — | | [#14](https://gonkadocs.com/proposals/proposals/2025-q4/14/) | 2025-11-27 | Sale GNK from Community Fund | Community Pool | 20,000,000 | — | | [PR #919](https://github.com/gonka-ai/gonka/pull/919) | 2026-03 | v0.2.11 bounty distribution | Upgrade Handler (Gov Module) | 150,750 | — | | [PR #1446](https://github.com/gonka-ai/gonka/pull/1446) | 2026-07 | v0.2.14 bounty distribution | Upgrade Handler (Community Sale) | — | $45,250 | | [PR #1113](https://github.com/gonka-ai/gonka/pull/1113) | 2026-04 | v0.2.12 bounty distribution | Upgrade Handler (Community Sale) | — | $35,200 | | [PR #497](https://github.com/gonka-ai/gonka/pull/497) | 2026-01 | v0.2.6 bounty distribution | Upgrade Handler (Gov Module) | 30,000 | — | | [PR #733](https://github.com/gonka-ai/gonka/pull/733) | 2026-02 | v0.2.10 bounty distribution | Upgrade Handler (Gov Module) | 23,000 | — | | [PR #1168](https://github.com/gonka-ai/gonka/pull/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 | --- ## Bounty Distribution 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**. | Version | PR | Status | Date | Recipients | Total GNK | Total USDT | Source | :------ | :- | :----- | :--- | :--------- | --------: | --------: | :---- | v0.2.14 | [PR #1446](https://github.com/gonka-ai/gonka/pull/1446) | Open | 2026-07 | 16 recipients | — | $45,250 | Community Sale | | v0.2.13 | [PR #1168](https://github.com/gonka-ai/gonka/pull/1168) | Merged | 2026-05 | 2 recipients | — | $18,000 | Community Sale | | v0.2.12 | [PR #1113](https://github.com/gonka-ai/gonka/pull/1113) | Merged | 2026-04 | 13 recipients | — | $35,200 | Community Sale | | v0.2.11 | [PR #919](https://github.com/gonka-ai/gonka/pull/919) | Merged | 2026-03 | 26 recipients | 150,750 | — | Gov Module | | v0.2.10 | [PR #733](https://github.com/gonka-ai/gonka/pull/733) | Merged | 2026-02 | 11 recipients | 23,000 | — | Gov Module | | v0.2.6 | [PR #497](https://github.com/gonka-ai/gonka/pull/497) | Merged | 2026-01 | 2 recipients | 30,000 | — | Gov Module | ### Recipient Details ### v0.2.14 — [PR #1446](https://github.com/gonka-ai/gonka/pull/1446) (Open) | Recipient | Address | Amount | Description | | :------- | :------ | ----: | :---------- | | @akup | [`gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56`](https://gonka.gg/address/gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56) | $5,000 USDT | devshards v3 RM, upgrade review, HackerOne reviews | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | $6,000 USDT | RM, HackerOne reviews | | @qdanik | [`gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8`](https://gonka.gg/address/gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8) | $10,000 USDT | RM, HackerOne reviews, MiniMax R&D, PoC (incl. GPU) | | @ouicate | [`gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a`](https://gonka.gg/address/gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a) | $1,000 USDT | PR #1253: stop stale PoC validation | | @ouicate | [`gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a`](https://gonka.gg/address/gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a) | $1,000 USDT | PR #1255: settle before releasing unbonding | | @ouicate | [`gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a`](https://gonka.gg/address/gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a) | $1,000 USDT | PR #1278: bound event-listener tx queue | | @0xMayoor | [`gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8`](https://gonka.gg/address/gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8) | $500 USDT | PR #1100: prevent uint64 wrap in settle | | @0xMayoor | [`gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8`](https://gonka.gg/address/gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8) | $750 USDT | PR #1101: widen ShouldValidate to uint64 | | @0xMayoor | [`gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8`](https://gonka.gg/address/gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8) | $500 USDT | PR #1347: distribute unsettled escrow per slot | | @0xMayoor | [`gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8`](https://gonka.gg/address/gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8) | $2,000 USDT | PR #1376: bridge block sync vulnerability | | @alancapex | [`gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09`](https://gonka.gg/address/gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09) | $3,000 USDT | PR #889: on-chain configurable reward recipients | | @Ryanchen911 | [`gonka1zqss46r6jf6dhhyaa777kc2ppvjhn0ufkx4y57`](https://gonka.gg/address/gonka1zqss46r6jf6dhhyaa777kc2ppvjhn0ufkx4y57) | $7,500 USDT | PR #998: implementing maintenance windows | | @redstartechno | [`gonka105ce4495mj0mwkxqeasgdzqfq5jjrfq32eza5l`](https://gonka.gg/address/gonka105ce4495mj0mwkxqeasgdzqfq5jjrfq32eza5l) | $500 USDT | PR #1307: avoid query-gas-limit on grant check | | @Lelouch33 | [`gonka128nd36m2pz5qcs4q6rd69622flyls05nleazqq`](https://gonka.gg/address/gonka128nd36m2pz5qcs4q6rd69622flyls05nleazqq) | $5,000 USDT | Vulnerability report 1 | | @Lelouch33 | [`gonka128nd36m2pz5qcs4q6rd69622flyls05nleazqq`](https://gonka.gg/address/gonka128nd36m2pz5qcs4q6rd69622flyls05nleazqq) | $1,000 USDT | Vulnerability report 2 | | @blizko | [`gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq`](https://gonka.gg/address/gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq) | $1,000 USDT | v0.2.13 upgrade review | | **Total** | | **$45,250 USDT** | | ### v0.2.13 — [PR #1168](https://github.com/gonka-ai/gonka/pull/1168) (Merged) | Recipient | Address | Amount | Description | | :------- | :------ | ----: | :---------- | | @blizko | [`gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq`](https://gonka.gg/address/gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq) | $8,000 USDT | Prompt of death: vLLM crash via structured outputs | | kaitaku.ai | [`gonka1x45hruazmcqxslj3g8a08988hr5fr3wx33drhp`](https://gonka.gg/address/gonka1x45hruazmcqxslj3g8a08988hr5fr3wx33drhp) | $10,000 USDT | Kimi experiments report | | **Total** | | **$18,000 USDT** | | ### v0.2.12 — [PR #1113](https://github.com/gonka-ai/gonka/pull/1113) (Merged) | Recipient | Address | Amount | Description | | :------- | :------ | ----: | :---------- | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | $6,000 USDT | CertiK audit fixes (GEB-29, GEB-35, …) | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | $3,000 USDT | DKG dealer consensus — PR #825 | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | $1,000 USDT | Developer inference access / account API | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | $500 USDT | OpenAI compatibility and API error handling | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | $2,500 USDT | v0.2.12 release management | | @akup | [`gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56`](https://gonka.gg/address/gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56) | $5,000 USDT | v0.2.12 release management | | — | [`gonka1yhdhp4vwsvdsplv4acksntx0zxh8saueq6lj9m`](https://gonka.gg/address/gonka1yhdhp4vwsvdsplv4acksntx0zxh8saueq6lj9m) | $9,000 USDT | Inference validation optimization — Issue #929 | | — | [`gonka1vu28c7w5zxqe28lakrrfdrkvscft326rxur3dv`](https://gonka.gg/address/gonka1vu28c7w5zxqe28lakrrfdrkvscft326rxur3dv) | $3,000 USDT | Acquire node gRPC — PR #945 | | @0xMayoor | [`gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8`](https://gonka.gg/address/gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8) | $2,000 USDT | Fund atomicity error safety — PR #789 | | @qdanik | [`gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8`](https://gonka.gg/address/gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8) | $1,500 USDT | Align validator slashing — PR #940 | | — | [`gonka1c34w3r45f0uftjckt2yy4k22vnc3zqjnp0umyz`](https://gonka.gg/address/gonka1c34w3r45f0uftjckt2yy4k22vnc3zqjnp0umyz) | $500 USDT | Free inference vulnerability report | | — | [`gonka139f7x4gur2yuyty64dkqxep8jk3d7ku8ayjaqg`](https://gonka.gg/address/gonka139f7x4gur2yuyty64dkqxep8jk3d7ku8ayjaqg) | $200 USDT | Chat completions fix — Issue #499 | | @blizko | [`gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq`](https://gonka.gg/address/gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq) | $1,000 USDT | Review of upgrade v0.2.11 | | **Total** | | **$35,200 USDT** | | ### v0.2.11 — [PR #919](https://github.com/gonka-ai/gonka/pull/919) (Merged) | Recipient | Address | Amount | Description | | :------- | :------ | ----: | :---------- | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | 2,500 GNK | Data race conditions fix review — PR #543 | | — | [`gonka1yhdhp4vwsvdsplv4acksntx0zxh8saueq6lj9m`](https://gonka.gg/address/gonka1yhdhp4vwsvdsplv4acksntx0zxh8saueq6lj9m) | 25,000 GNK | PoC Integration into vLLM v0.11.1 — Issue #628 | | @blizko | [`gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq`](https://gonka.gg/address/gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq) | 10,000 GNK | vLLM HTTP 502 via prompt series | | @blizko | [`gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq`](https://gonka.gg/address/gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq) | 1,000 GNK | Dust transaction vulnerability report | | @ouicate | [`gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a`](https://gonka.gg/address/gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a) | 5,000 GNK | Remote DoS of Validator PoC | | @ouicate | [`gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a`](https://gonka.gg/address/gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a) | 5,000 GNK | State Bloat PoC / End-Block DoS | | @ouicate | [`gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a`](https://gonka.gg/address/gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a) | 750 GNK | Bridge ETH address parsing vuln | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | 1,000 GNK | Planned task — PR #775 | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | 1,250 GNK | Planned task — PR #773 | | @qdanik | [`gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8`](https://gonka.gg/address/gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8) | 12,000 GNK | vLLM 0.15.1 compatibility experiments | | @qdanik | [`gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8`](https://gonka.gg/address/gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8) | 15,000 GNK | vLLM simultaneous PoC + inference | | @qdanik | [`gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8`](https://gonka.gg/address/gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8) | 5,000 GNK | Wind down window vulnerability — PR #767 | | @akup | [`gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56`](https://gonka.gg/address/gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56) | 1,000 GNK | Nodes unable to join from snapshots | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | 3,000 GNK | Nodes unable to join (source problem) | | — | [`gonka17kmfwzthep3alxt57vqcqr48uv7swp0u63gcnj`](https://gonka.gg/address/gonka17kmfwzthep3alxt57vqcqr48uv7swp0u63gcnj) | 750 GNK | StartInference/FinishInference — Issue #780 | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | 5,000 GNK | StartInference/FinishInference — Issue #781 | | @akup | [`gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56`](https://gonka.gg/address/gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56) | 5,000 GNK | StartInference/FinishInference — Issue #782 | | @Lelouch33 | [`gonka128nd36m2pz5qcs4q6rd69622flyls05nleazqq`](https://gonka.gg/address/gonka128nd36m2pz5qcs4q6rd69622flyls05nleazqq) | 7,500 GNK | Important issue + testing with fix — PR #867 | | kaitaku.ai | [`gonka1x45hruazmcqxslj3g8a08988hr5fr3wx33drhp`](https://gonka.gg/address/gonka1x45hruazmcqxslj3g8a08988hr5fr3wx33drhp) | 22,500 GNK | vLLM 0.15.1 compatibility — Issue #730 | | — | [`gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6`](https://gonka.gg/address/gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6) | 5,000 GNK | Batch Transfer With Vesting — PR #835 | | @qdanik | [`gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8`](https://gonka.gg/address/gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8) | 5,000 GNK | Collateral slashing vulnerability — PR #868 | | @akup | [`gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56`](https://gonka.gg/address/gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56) | 7,500 GNK | v0.2.11 release management | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | 7,500 GNK | v0.2.11 release management | | @0xMayoor | [`gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8`](https://gonka.gg/address/gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8) | 2,500 GNK | v0.2.10 upgrade review | | @blizko | [`gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq`](https://gonka.gg/address/gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq) | 2,500 GNK | v0.2.10 upgrade review | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | 2,500 GNK | v0.2.10 upgrade review | | **Total** | | **150,750 GNK** | | ### v0.2.10 — [PR #733](https://github.com/gonka-ai/gonka/pull/733) (Merged) | Recipient | Address | Amount | Description | | :------- | :------ | ----: | :---------- | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | 500 GNK | Minor vulnerability fix — PR #661 | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | 700 GNK | Planned task — PR #644 | | @akup | [`gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56`](https://gonka.gg/address/gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56) | 10,000 GNK | Medium risk vulnerability report + fix — PR #659 | | — | [`gonka1c34w3r45f0uftjckt2yy4k22vnc3zqjnp0umyz`](https://gonka.gg/address/gonka1c34w3r45f0uftjckt2yy4k22vnc3zqjnp0umyz) | 5,000 GNK | First report of vulnerability fixed in #659 | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | 1,000 GNK | Low risk vulnerability — PR #545 | | — | [`gonka1jkydytz99gkh0t42gjj4lz0mmdeumqp7mtzke3`](https://gonka.gg/address/gonka1jkydytz99gkh0t42gjj4lz0mmdeumqp7mtzke3) | 100 GNK | Minor bug fix — PR #640 | | — | [`gonka123khww9elhtj49zumz0daleaudl6jn9y87tf23`](https://gonka.gg/address/gonka123khww9elhtj49zumz0daleaudl6jn9y87tf23) | 500 GNK | First report + suggested fix — Issue #422 | | — | [`gonka1jkydytz99gkh0t42gjj4lz0mmdeumqp7mtzke3`](https://gonka.gg/address/gonka1jkydytz99gkh0t42gjj4lz0mmdeumqp7mtzke3) | 100 GNK | Minor bug fix — PR #638 | | — | [`gonka1jkydytz99gkh0t42gjj4lz0mmdeumqp7mtzke3`](https://gonka.gg/address/gonka1jkydytz99gkh0t42gjj4lz0mmdeumqp7mtzke3) | 100 GNK | Minor bug fix — PR #634 | | @ouicate | [`gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a`](https://gonka.gg/address/gonka1f0elpwnx7ezytdlck35003nz6qk8kzvurvnj4a) | 5,000 GNK | Independent report on issue in PR #710 | | @x0152 | [`gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe`](https://gonka.gg/address/gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe) | 500 GNK | Low risk vulnerability — PR #643 | | **Total** | | **23,000 GNK** | | ### v0.2.6 — [PR #497](https://github.com/gonka-ai/gonka/pull/497) (Merged) | Recipient | Address | Amount | Description | | :------- | :------ | ----: | :---------- | | — | [`gonka1gmuxdcxlsxn5z72elx77w9zym7yrgfxqgzg6ry`](https://gonka.gg/address/gonka1gmuxdcxlsxn5z72elx77w9zym7yrgfxqgzg6ry) | 20,000 GNK | Vulnerability in Confirmation PoC — PR #459 | | @0xMayoor | [`gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8`](https://gonka.gg/address/gonka1s8szs7n43jxgz4a4xaxmzm5emh7fmjxhach7w8) | 10,000 GNK | Bridge Exchange Double Vote Case Bypass | | **Total** | | **30,000 GNK** | | --- --- ## Pipeline .pipeline-wrap { max-width: 640px; margin: 0 auto; padding: 1rem 0.5rem 3rem; font-size: 0.75rem; line-height: 1.45; color: #1f2328; } .pipeline-intro { font-size: 0.78rem; color: #57606a; margin-bottom: 1.5rem; line-height: 1.45; } .pipeline-timeline { position: relative; } .pipeline-timeline::before { content: ""; position: absolute; left: 13px; top: 10px; bottom: 10px; width: 2px; background: #24292f; } .pipeline-stage { margin-bottom: 2rem; } .pipeline-stage:last-child { margin-bottom: 0; } .stage-header { display: grid; grid-template-columns: 28px 1fr; gap: 10px; align-items: center; margin-bottom: 0.5rem; } .stage-node { justify-self: center; width: 16px; height: 16px; box-sizing: border-box; border-radius: 50%; border: 2.5px solid #24292f; background: #fff; position: relative; z-index: 2; } .stage-title { font-size: 3.0rem; font-weight: 700; line-height: 1.2; color: #1f2328; letter-spacing: -0.02em; } .pipeline-item { display: grid; grid-template-columns: 28px 1fr; gap: 10px; margin-bottom: 0.4rem; } .pipeline-item:last-child { margin-bottom: 0; } .item-dot { justify-self: center; align-self: start; margin-top: 0.48em; width: 8px; height: 8px; border-radius: 50%; background: #24292f; position: relative; z-index: 2; } .item-text { font-size: 0.6rem; line-height: 1.4; color: #24292f; } .item-text a { color: #0969da; text-decoration: underline; text-underline-offset: 2px; } РАЗДЕЛ В ПРОЦЕССЕ РАЗРАБОТКИ Полный цикл жизни предложения от идеи до отчётности. Каждый этап прозрачен, проверяем сообществом и задокументирован. Подготовка Ознакомиться с актуальным роадмапом 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 — за соблюдение процедур. --- ## Gonka Community Pre-Proposals # Gonka Community Pre-Proposals Community proposals from [gonka.vote](https://gonka.vote). These are off-chain indicative polls where GNK holders signal support for potential on-chain governance proposals. --- ## 🟢 Active Proposals 3Active 13Votes 1.4M GNKTotal Bid | Status | Title | Author | Votes | Avg. Bid | Closes | | :----- | :----- | :----- | ----: | -------: | :----- | | 🟢 | [Вестинг: почему его стоит отменить сейчас](./d23b0edf-57fb-4522-bd79-04ffdcc9d7a5/) | Mitch | 3 | 0.00 GNK | 2026-08-01 | | 🟢 | [Привлечение $3M+ нового капитала на Uniswap](./e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b/) | Andrey Orlov | 5 | 138.3K GNK | 2026-08-02 | | 🟢 | [Привлечение $3M+ нового капитала на Uniswap v2.0](./f341b83c-78f0-4ab2-b8fd-ddc7ac5d9c37/) | Andrey Orlov | 5 | 138.3K GNK | 2026-08-08 | --- ## 🔴 Expired Proposals 31Expired 15Votes 798.4K GNKTotal Bid | Status | Title | Author | Votes | Avg. Bid | Closed | | :----- | :----- | :----- | ----: | -------: | :----- | | 🔴 | [Should Gonka make fallbacks to other services like OpenRouter?](./f9a4302d-7823-4cd4-9987-b0758569db93/) | Viktor | 1 | 0.00 GNK | 2026-07-24 | | 🔴 | [Улучшаем инфиренс Kimi](./d185d9eb-243f-4228-b4ac-e2c7a50a5325/) | Mitch | 6 | 0.00 GNK | 2026-07-21 | | 🔴 | [External Test Lab & Community DevNet](./205219a5-6ed2-4f25-8d22-fa7c65a45ba6/) | Sergii Paranko | 4 | 172.9K GNK | 2026-07-14 | | 🔴 | [Private Inc × Gonka — Network Growth Initiative](./ed8148eb-535e-4677-9a6b-5316c81c996a/) | Igor Alexeev | 0 | 0.00 GNK | 2026-07-13 | | 🔴 | [Предложение по развитию игровой экосистемы блокчейна через турнирные пулы вознаг](./fd9989ca-7c5b-4a2f-baf4-2465e6915ba6/) | Victor | 0 | 0.00 GNK | 2026-07-12 | | 🔴 | [Интеграция ИИ Gonka в инфраструктуру QR Mint](./7d2ec26b-6524-4fc6-b676-a13d822536e8/) | Victor | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [12+1. Team EntroPi Grant Request](./f6b4e378-8950-4bcf-ac7f-d70d9d246630/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [12. Team Slava MSE Team Grant Request](./08405617-5654-4ead-be62-642affa1739e/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [11. Team GonkaGate Grant Request](./d2f317f0-541a-4d9f-bbac-d2d394906bf2/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [10. Team Alexander Kuprin Grant Request](./59175b49-b83f-4aa6-98f5-b27fffb23cd8/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [9. Team Gonka-API.org Grant Request](./f021bdb3-59f4-4906-bfaa-7b90b72019b1/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [8. Team Gonka.TV Grant Request](./47ab8faa-f9bd-41ba-8e86-6c760d4975a6/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [7. Team Epokha AI / epokha.ai Grant Request](./0395efa6-8eef-4d83-85cb-83d36a937f96/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [5. Team Lefine Grant Request](./662adc44-01c4-41ca-9c0d-ac61f472ee56/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [4. Team Gonka NL BE Community Grant Request](./db4d91a4-1ee7-46ee-a3d1-0e8ba546d04b/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [3. Team Gonka Wallet Grant Request](./2b6b2142-685a-4eda-b2a1-f8853228f3e6/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [Team Gonka.AI \| Inside Grant Request](./4792a93f-127a-4a0e-9a12-acd229c1e865/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [1. Team Veylox Grant Request](./66e6583a-27b4-4bae-91fb-8f0489736b0d/) | Slava MyGonka | 0 | 0.00 GNK | 2026-07-11 | | 🔴 | [Go-To-Market Team for 3 Month to Set Up the Basis](./cb7f643f-3d56-47ec-9193-f9f2f80a99fb/) | Dem \| Démíngān | 2 | 26.7K GNK | 2026-07-10 | | 🔴 | [Gonka Media Library by Saccade](./f215996d-e562-42b5-b2b1-400226e612fa/) | Dem \| Démíngān | 2 | 26.7K GNK | 2026-07-10 | | 🔴 | [Стресс тест инфиренса](./efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571/) | Mitch | 0 | 0.00 GNK | 2026-06-05 | | 🔴 | [Bring Gonka to EBC12 as a Gold Sponsor](./29baf37b-811f-4c36-b517-66a578383f1c/) | Heydar Naghiyev | 0 | 0.00 GNK | 2026-06-04 | | 🔴 | [Большое видео на канале Falcon Finance (Александр Соколовский)](./550f71de-897f-4ce5-8af8-97854775f8b2/) | Дмитрий В | 0 | 0.00 GNK | 2026-05-28 | | 🔴 | [Улучшения для vote.gonka.vip](./b7083379-6dc5-4198-b9b0-1b8b98f0ac01/) | Alex A.A. | 0 | 0.00 GNK | 2026-05-25 | | 🔴 | [International Marketing Campaign for Gonka — English-Speaking Markets](./28dcf8fb-3138-4e8b-adc0-0fb82962276c/) | Evgenii Maksimenkov | 0 | 0.00 GNK | 2026-05-25 | | 🔴 | [Universal Continuous GPU Benchmark for Gonka Hosts (vLLM v0.19+, Anti-Sybil)](./673770df-0b72-4d04-a038-f8c12546817f/) | Evgenii Maksimenkov | 0 | 0.00 GNK | 2026-05-25 | | 🔴 | [Gonka NOP: ретроактивный грант + финансирование поддержки и новых фич.](./2cbbe98e-ceff-4f09-a1cd-e8d370e97fde/) | O D | 0 | 0.00 GNK | 2026-05-20 | | 🔴 | [Коэффициент для Kimi 2.6 - 1,87](./d14f975e-0e40-4a94-81c5-715a02c3826e/) | Alex Sharoiko Александр Шаройко | 0 | 0.00 GNK | 2026-05-20 | | 🔴 | [Gonka.TV — амбассадор Гонки на YouTube](./00e8a72a-e121-4ea1-8d30-95a0d51268b2/) | Mikhail Chudinov | 0 | 0.00 GNK | 2026-05-11 | | 🔴 | [Bounty for open-source PoC throughput contributions](./6392c2ea-7fb8-45c7-b1ec-80fb16d81d93/) | Serhii Hovorov | 0 | 0.00 GNK | 2026-05-08 | | 🔴 | [Return Withheld Miner Rewards: Redistribute Gov-Wallet Balance for Ep 132–247](./012f8a32-45ab-4ba8-b6f3-39631d19eb84/) | Evgenii Maksimenkov | 0 | 0.00 GNK | 2026-05-08 | --- *Data synced from [gonka.vote](https://gonka.vote). Last updated: 2026-07-26 07:44 UTC* --- ## 4. Team Gonka NL BE Community Grant Request # 4. Team Gonka NL BE Community Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal 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: * Growing the Benelux Telegram community through targeted outreach and onboarding campaigns. * Creating localized educational content to help new users understand Gonka and its ecosystem. * Organizing community engagement activities, discussions, and promotional events. * Supporting new users with onboarding and ecosystem guidance. * Acting as a regional bridge between the global Gonka community and Dutch-speaking users. * Increasing awareness of Gonka across social platforms and relevant crypto communities in the Netherlands and Belgium. 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. ## What contributions or products has your team already developed for Gonka (with links pls)? 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. ## GNK Wallet Address gonka1rlcuz7yref90npgfwyqx4yeese4qk6e8y9ccwt ## Your Discord ID for Contact Purposes Clarkkent8494 ## Email Address [fissaoui01@gmail.com](mailto:fissaoui01@gmail.com) --- ## Comments (1) ### 💬 Slava MyGonka *2026-06-11 07:13* · 👍 0 · 👎 0 Привет! А я не знал про то, что у тебя большой крипто канал. Молодец! Вопросы: 1. Ты пробовал майнинг Gonka? Кто-то из комьюнити пробовал? 2. Ты пробовал использовать инференс Gonka? Кто-то из комьюнити пробовал? 3. Сколько GNK ты бы хотел получить за 3 месяца? 4. Можешь в цифрах дать какие-то обязательства? Количество публикаций, контакты с блогерами, публикации за пределами Телеграм... Т.е. что-то, что можно было бы измерить. Спасибо за инициативу! Здорово, что подключается европейское комьюнити! --- --- [View on gonka.vote](https://gonka.vote/proposal/db4d91a4-1ee7-46ee-a3d1-0e8ba546d04b) --- ## 5. Team Lefine Grant Request # 5. Team Lefine Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal 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: * Add quick AI answers powered by Gonka on **lefine.pro**, so users who visit the website and ask simple questions can receive responses through Gonka Inference. * Build deeper AI tools on top of Gonka, including a scheduler that can analyze a repository, break it down into chunks, and assign the right task to the right place. * Provide access to Gonka Inference through Lefine as a regular tool. * Distribute an API powered by Gonka through various interfaces and chat bots, making Gonka-based responses easier and more accessible for users. 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. ## What contributions or products has your team already developed for Gonka (with links pls)? 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 ## GNK Wallet Address gonka19lde9h69wzfsw3nj9yzltak7gcwrmjpvjpd7he ## Your Discord ID for Contact Purposes kogeletey ## Email Address [itgood76@gmail.com](mailto:itgood76@gmail.com) --- ## Comments (1) ### 💬 Slava MyGonka *2026-06-11 08:34* · 👍 0 · 👎 0 Привет! Сайт не работает: https://lefine.pro/ или я не туда захожу? 2. Какие инструменты вы планируете использовать (или уже используете)? OpenSorce? 3. Это - коммерческий проект? Очень круто, что у вас есть опыт реализации аналогичных проектов. Спасибо за инициативу! --- --- [View on gonka.vote](https://gonka.vote/proposal/662adc44-01c4-41ca-9c0d-ac61f472ee56) --- ## Bounty for open-source PoC throughput contributions # Bounty for open-source PoC throughput contributions 🔴 Expired **Author:** 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. --- ## Full Proposal 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: - Big pools capture the gains; smaller miners stay slow - Optimizations don't flow back into the public `gonka-ai/vllm` and `mlnode` repos - New miners join a network whose floor is lower than it could be - The chain's actual realized GNK/GPU-hour is below what's technically achievable 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: 1. **Merged upstream** into a public Gonka repo — `gonka-ai/vllm`, `gonka-ai/mlnode`, `gonka-ai/inference-chain`, or a designated successor. 2. **Reproducible benchmark** — a public A/B harness against a reference build (currently Qwen3-235B-A22B-Instruct-2507-FP8) on at least one supported GPU class (B200 / H100 / A100). Includes "before" and "after" commit SHAs. 3. **Net positive impact** — at least 5% sustained nonces/min uplift on the reference setup. 4. **Independently verified** — reproduced by ≥ 2 unrelated miners on their own hardware, attested on-chain. ### Reward structure (for community discussion) - Flat bounty per qualifying contribution: **2,000 GNK** - Bonus tier for ≥ 10% uplift: **+3,000 GNK** - Funded from a dedicated optimization-bounty pool topped up via routine community-pool spend proposals tied to confirmed merges — no extra emissions - Contributor names the recipient address at PR submission - One person can receive multiple bounties for distinct optimizations ### 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`](https://github.com/gonka-ai/vllm/pull/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* - **Not** a proposal to pay any specific person — it's a standing policy anyone can claim. - **Not** a vote on `vllm#36` itself — that PR lands or not on its technical merits regardless of this tender. - **Not** a binding tx — tenders are indicative polls. If this passes, a separate formal community-pool spend funds the first round. ## Open questions for the community - Right uplift threshold? (5% suggested; could be 3% or 10%) - Right bounty size? (2k + 3k GNK suggested; could scale with measured network-wide impact) - Verification process? (2 independent miners suggested) - Scope: PoC-only, or also general inference throughput? (broader = more impact, harder to verify) - Eligibility for retroactive contributions? (e.g. anything merged in the last 30 days) --- ## Comments (1) ### 💬 Mikhail Chudinov *2026-05-04 14:34* · 👍 1 · 👎 0 Идея правильная, считаю что давать нужно минимум эквивалент 1000$ за каждый % прироста веса. Дала оптимизация +10% = выдать 10к$ Курс GNK может сильно плавать, поэтому такой бонус я бы привязывал к USD. Это будет хорошее, более понятное предложение для программистов, которые впервые услышали про гонку. Что тут можно пооптимизировать, понятным образом протестировать результат в нонсах в минуту скриптом и получить разовую приличную выплату в случае успеха. Создавать отдельный пулл под финансирование не вижу смысла. Считаю что достаточно каждое такое улучшение проводить как пропозал отдельный, из комьюнити пула. В качестве верификации что эта оптимизация полезна выступают майнеры, своим голосованием. --- --- [View on gonka.vote](https://gonka.vote/proposal/6392c2ea-7fb8-45c7-b1ec-80fb16d81d93) --- ## Should Gonka make fallbacks to other services like OpenRouter? # Should Gonka make fallbacks to other services like OpenRouter? 🔴 Expired **Author:** 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) на случай, когда сеть или отдельные брокеры отваливаются. Решили: польза от фаллбеков не окупает рисков --- ## Full Proposal Контекст Обсуждали план — собирать много лендингов «своих брокеров» под целевые аудитории (нашими силами и силами существующих брокеров) и распределять трафик между брокерами, подходящими под конкретную ЦА, а также под обёртками технологически стабильных брокеров. В рамках этого рассматривался вариант: одновременно слать запрос на несколько брокеров и брать первый пришедший ответ, а если отваливается вся сеть — делать **fallback на OpenRouter**, как минимум для тех, кому нормальны цены уровня 1/3–1/5 от OpenRouter. Именно вокруг этого фаллбека на нашей стороне и шла дискуссия. --- ## Аргументы ЗА фаллбеки на нашей стороне 1. **Без стабильности не будет виральности.** Если у клиентов Gonka регулярно отваливается инференс, позитивного вирального эффекта распространения не получится. 2. **Не хотим терять приведённых клиентов из-за «неудачного» брокера.** Брокеры, продающие инференс по себестоимости с небольшой наценкой, физически не смогут оплачивать OpenRouter, а принуждать всех к этому странно и нереализуемо. При этом терять клиентов, которых мы сами привели, из-за того что они попали на слабого брокера, не хочется. 3. **Пользователю нужно «нажал 2 кнопки — и всё работает».** Если брокеры сами настроят фаллбеки, то к нам будет приходить уже нормальный ответ и до наших фаллбеков дело просто не дойдёт — то есть они выступают страховкой, а не постоянной статьёй расходов. 4. **Лучшее понимание цен + поддержка курса GNK.** Мы будем точнее понимать, по каким ценам продавать инференс, и в большинстве случаев это на порядки дороже, чем у сети / дешёвых брокеров. Соответственно, мы сможем и оплачивать OpenRouter, и направлять порядка половины выручки на закупку GNK с рынка — обеспечивая себе баланс в GNK и способствуя росту курса. 5. **Экономика сходится.** Если продавать B2B по цене выше 1/10 от OpenRouter при доле отвалов до ~10%, либо подписку за $5–10/мес, которой пользователь почти не пользуется — этого достаточно, чтобы покрыть расходы на фаллбеки. В исключительных случаях просадку можно закрывать из маркетингового бюджета, чтобы не портить впечатление о сети. 6. **Стратегический вижн.** Стабильно падающая цена токена — риск, что от проекта отвернутся инвесторы; растущий объём публичных кейсов использования, наоборот, демонстрирует успех и упрощает вовлечение новых участников (от разработчиков до производителей ASIC). Мы не в вакууме — есть конкуренты, надо бежать быстрее. Отсюда вопрос: не стоит ли применить «fake it until you make it» в части ощущения работающей сети, чтобы быстрее запустить виральные процессы. --- ## Аргументы ПРОТИВ (легли в основу решения) 1. **Фидбек от разработчиков.** По обратной связи от программистов, использующих AI API: фаллбеки они настраивают сами. B2B-клиентам и программистам наши фаллбеки не нужны — они хотят покупать именно то, что у нас есть, без надстроек. 2. **Не смешивать слои.** Сервис, который дёшево продаёт API под агента и собирает его фаллбеками «с миру по нитке» (включая Gonka), — это отдельный продукт, способный работать, даже если Gonka умрёт. Это **не** Gonka-брокер, и путать эти слои опасно. Такого продукта у нас пока и нет. 3. **Фаллбек лучше настраивать самому.** Свои фаллбеки, настроенные как ты хочешь, всегда лучше, чем когда за тебя это делает third-party так, как ей удобно. 4. **Слишком рисковая бизнес-модель.** Если отваливается не 10%, а 50% запросов или на полдня — уходишь в большой минус. Такое можно себе позволить, только когда карман жгут миллионы инвесторских денег. Разумнее продавать то, что есть, ничего не выдумывая. 5. **Кто платит за фаллбек?** Открытый вопрос: как одновременно давать «дешёвую цену» и оплачивать более дорогой фаллбек-инференс — экономика этого на «дешёвом» тарифе неочевидна. --- ## Итоговое решение Идея делать фаллбеки на нашей стороне **снимается**, на старте это точно не необходимо. --- [View on gonka.vote](https://gonka.vote/proposal/f9a4302d-7823-4cd4-9987-b0758569db93) --- ## Улучшаем инфиренс Kimi # Улучшаем инфиренс Kimi 🔴 Expired **Author:** 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 и настройки нод. --- ## Full Proposal Факты: * \~20% веса сети приходится на Kimi * Запросов на инфиренс идет столько, что ноды с Kimi часто перегружены, и ответ падает с ошибкой * Недели 2 назад Kimi можно было нормально пользоваться * Сейчас Kimi часто дает ошибку, стало больше запросов * Сама по себе цена не будет расти и при 100% загрузке нод с Kimi (динамического прайсинга нету в девшардах, и в след релизе не появится) * Майнеры часто запускают Kimi на 8xH-200, чтобы не терять 5% за делегацию. Хотя по весу, там было бы выгоднее запустить MiniMax. Эта карта слабовата для Kimi, работает плохо, по сути ее запускают для галочки, такие ноды получают инфиренсы и плохо с ними справляются, ухудшают качество. Если отменить штраф \- на них перестанут запускать Kimi и качество улучшится, но тут надо прояснить от чего нас защищает этот штраф? * На 8xB-300 выгодность для Minimax и Kimi одинакова. И там все запускают Minimax, потому что без нагрузки жить проще, ниже риск падения ноды, и это базовая модель которая не может “выпасть из сети”, как было с Kimi недавно. * На 8xB-200 Kimi выгоднее чем Minimax на 20%. Пока загадка почему там тоже часто запущен Minimax. Если вы такой майнер \- скажете мне в личку плиз. У разработчиков большие планы, как много чего улучшить, и от майнеров тут не особо что то зависит, ток советы можем давать. Но вот что мы реально можем, так это менять настройки через Governance, и это сработает прямо сейчас. # Что можно сделать если у вас 8xB-200 * Перейдите на Kimi прямо сейчас\! * Оптимизированные ML образы тут: [https://registry.kaitaku.ai/](https://registry.kaitaku.ai/) * Станете зарабатывать на 20% больше. * И пользователям инфиренса будет приятно. # Что можно сделать через Governance * Убрать штраф за не-делегацию модели. * Результат: на H-200 перестанут запускать Kimi, тк это потеряет экономический смысл. Качество инференция улучшится, ошибок станет меньше. * Повысить коэфициент для Kimi, процентов на 10 * Результат: майнеры с B-300 начнут запускать Kimi вместо MiniMax * Поднять цену на инфиренс Kimi. * Результат: меньше станут гонять тестовых запросов, снизится нагрузка. По сути такая защита от спама. * На сколько поднимать: * Для начала в 10 раз, посмотреть, повлияет ли это вообще на количество запросов. Может быть там тестовых мало, а все что есть это реальные клиенты. Если так то продолжить еще поднимать. * Даже если поднять в 100 раз, то все равно у нас будет дешевле в 10 раз чем на OpenRouter # Последовательность изменений * Все изменения делать отдельными пропозалами. Поменяли, посмотрели 3-4 дня хотя бы что поменялось, сделали выводы, потом менять что то другое. * Первым делом я бы убрал штраф за не-делегацию. Но тут стоит прояснить \- от чего он нас вообще должен был защищать? Я что то забыл, напомните плиз. * Потом повысить коэфициент для Kimi, процентов на 10\. На H-200 минимакс все равно останется выгоднее. А на H-100 вообще Kimi нельзя запустить, так что Minimax не вымрет. * Потом поднять цену инфиренса на Kimi. И делать это постепенно, новыми пропозалами, такое динамическое ценообразование “врнучную”, пока не станет заметно что цена влияет на нагрузу. --- ## Comments (2) ### 💬 Viktor *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 --- ### 💬 Slava MyGonka *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](https://gonka.vote/proposal/d185d9eb-243f-4228-b4ac-e2c7a50a5325) --- ## Привлечение $3M+ нового капитала на Uniswap v2.0 # Привлечение $3M+ нового капитала на Uniswap v2.0 🟢 Active **Author:** 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 --- ## Full Proposal Суть предложения 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 получает не только новых пользователей, но и полностью готовую инфраструктуру привлечения капитала, которую сможет использовать для дальнейшего масштабирования. ⸻ 2. Кто мы Меня зовут Андрей Орловский, я являюсь основателем команды и буду лично отвечать за реализацию данного proposal. На сегодняшний день наша команда базируется в Цюрихе и состоит из 10 человек: 4 media buyer, 5 специалистов по обработке пользователей и 1 технического специалиста. Мы работаем в affiliate-маркетинге с 2023 года и сегодня самостоятельно управляем рекламным бюджетом более $70,000 в месяц. Основная специализация нашей команды — построение Telegram-воронок для привлечения инвесторов в различные проекты. Именно этим направлением мы занимаемся ежедневно: привлекаем целевую аудиторию, выстраиваем путь пользователя от первого контакта до первого депозита и постоянно оптимизируем каждый этап воронки на основе накопленной статистики. За последние годы мы накопили большой объем практических данных по различным географиям, хорошо понимаем экономику привлечения пользователей, стоимость подписчика, стоимость диалога и стоимость первого финансового действия. Это позволяет принимать решения не на предположениях, а на основе реальных данных. За время работы мы сформировали собственную систему привлечения и обработки инвесторов, которую ежедневно используем в своих проектах. Мы понимаем, что результат зависит не только от качества трафика, но и от качества дальнейшей работы с пользователем, поэтому уделяем одинаковое внимание каждому этапу воронки — от первого рекламного касания до первого депозита и последующего сопровождения. Для максимальной прозрачности мы также подготовили отдельный Telegram-канал, в котором собраны материалы по proposal: примеры Telegram-воронки, лендингов, креативов, рекламных кабинетов, партнерств, и другие подтверждения нашей работы. Ссылка: https://t.me/proposaluniswap Именно этот опыт и лег в основу предложения, которое мы подготовили для GONKA. ⸻—————————————— 3. Что мы предлагаем Наша цель — построить для GONKA систему, которая будет ежедневно привлекать новый капитал через покупку токена на Uniswap. Мы не рассматриваем этот проект как разовую рекламную кампанию. Наша задача — создать работающую систему привлечения пользователей, которую можно масштабировать и использовать в долгосрочной перспективе. Основным показателем эффективности для нас является не количество просмотров, кликов или регистраций, а объем нового капитала, привлеченного в экосистему GONKA. Именно поэтому вся маркетинговая стратегия, воронка, обработка пользователей и система удержания строятся вокруг одной цели — максимального объема привлеченного капитала через Uniswap с его последующим удержанием ⸻ 4. KPI и экономика проекта Общий 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 млн и учитывает только первое финансовое действие пользователя. ⸻ 5. Как будет работать воронка Наша задача — провести пользователя от первого знакомства с проектом до покупки токена через 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 ⸻ 6. Стратегия удержания пользователей Наша задача — не просто довести пользователя до первого депозита, а сделать его долгосрочным участником экосистемы GONKA. После первого финансового действия работа с пользователем не заканчивается. AI Agent и менеджеры продолжают сопровождать пользователя, отвечают на возникающие вопросы, помогают разобраться в возможностях экосистемы и поддерживают постоянную коммуникацию. Именно повторные инвестиции формируют основную часть долгосрочной ценности каждого привлеченного пользователя. Поэтому стратегия удержания является не отдельным этапом, а продолжением всей воронки. Весь контент, коммуникация, работа AI Agent и менеджеров будут направлены на формирование доверия к проекту, повышение вовлеченности пользователя и долгосрочное участие в экосистеме GONKA. Такой подход позволяет постепенно увеличивать LTV каждого пользователя, повышает вероятность повторных инвестиций и способствует формированию сообщества долгосрочных держателей токена. ⸻ 7. Финансирование Общая программа рассчитана на рекламный бюджет $300,000 и реализацию в течение 3-4 месяцев. Программа разделена на 6 последовательных этапов по $50,000. Настоящий proposal касается только первого этапа, в рамках которого запрашивается финансирование $50,000. Первый этап посвящен построению инфраструктуры, запуску рекламных кампаний, тестированию воронки и поиску наиболее эффективных связок. На этом этапе определяются лучшие GEO, аудитории, рекламные креативы, подходы к обработке пользователей и оптимальная экономика привлечения капитала. Целевой KPI первого этапа составляет 4x от рекламного бюджета. После выполнения KPI первого этапа мы опубликуем proposal на второй этап программы, целевой KPI которого составит 7x от рекламного бюджета. Начиная с третьего этапа целевой KPI составит 10x+. Чтобы не останавливать уже работающую инфраструктуру и рекламные кампании, proposal на следующий этап планируется публиковать заранее, до полного расходования бюджета текущего этапа, однако запуск каждого нового этапа возможен только после выполнения KPI предыдущего этапа и одобрения сообщества. Мы считаем такую модель наиболее безопасной для GONKA, поскольку сообщество сохраняет полный контроль над каждым этапом программы и принимает решение о дальнейшем финансировании только на основании достигнутых результатов. ⸻ 8. Вознаграждение команды За реализацию каждого этапа наше вознаграждение составляет: * 8% от рекламного бюджета — фиксированная часть, выплачивается после утверждения соответствующего этапа; * 12% — выплачивается только после подтверждения выполнения KPI предыдущего этапа и одновременно с финансированием следующего этапа. Например, в рамках первого этапа команда получает только фиксированную часть 8%. Оставшиеся 12% выплачиваются только при успешном выполнении KPI первого этапа и утверждении сообществом второго proposal. Если KPI не выполнен или следующий этап не утвержден, переменная часть вознаграждения не выплачивается. Отдельно хотим отметить, что все вознаграждение команды мы предлагаем выплачивать исключительно в токене GNK. ⸻ 9. Отчетность и прозрачность Выполнение KPI будет подтверждаться на основании внутренней CRM-системы, в которой фиксируется каждый привлеченный пользователь. После первого депозита в систему заносится адрес кошелька пользователя, сумма первого депозита и дальнейшая история его взаимодействия с проектом. Именно на основании этих данных будет производиться расчет выполнения KPI по каждому этапу кампании. Один раз в неделю мы будем публиковать подробный отчет о ходе реализации проекта. В него войдут текущие результаты кампании, выполнение KPI, стоимость подписчика, стоимость диалога, результаты по различным географиям, текущие гипотезы, проведенные тесты, достигнутые результаты и планы на следующую неделю. При необходимости мы готовы проводить еженедельные AMA-созвоны, на которых будем подробно отвечать на вопросы сообщества и разбирать результаты кампании. Если в процессе реализации проекта у маркетингового комитета возникнут дополнительные вопросы, мы готовы в любой момент предоставить необходимую информацию и отдельно обсудить текущие результаты. ⸻ 10. Что получает GONKA После завершения кампании GONKA получает не только от $3,000,000 нового капитала, но и полностью готовую систему привлечения пользователей, которая остается в распоряжении проекта и может использоваться для дальнейшего масштабирования. В рамках реализации проекта GONKA получает: * Telegram-каналы с аудиторией в сотни тысяч пользователей, значительная часть которых уже будет вовлечена в экосистему GONKA и иметь опыт взаимодействия с проектом; * полностью протестированную маркетинговую воронку привлечения капитала; * все рекламные связки, лендинги, креативы и контент, созданные в рамках кампании; * AI Agent, обученный на десятках тысяч реальных диалогов с пользователями и оптимизированный для сопровождения пользователей, доведения до первого депозита, повторных инвестиций и долгосрочного удержания; * накопленную статистику, аналитику и результаты всех проведенных тестов; * готовую инфраструктуру привлечения капитала, которую можно использовать для дальнейшего масштабирования без необходимости создавать ее заново. По сути, GONKA получает не разовую рекламную кампанию, а полноценный маркетинговый актив, который продолжит работать и после завершения финансирования, привлекать новых пользователей и увеличивать объем капитала внутри экосистемы. ⸻ 11. Защита от фрода и методика расчета KPI Для расчета KPI будет использоваться прозрачная методика, направленная не только на учет объема привлеченного капитала, но и на подтверждение его качества. При расчете KPI используются следующие принципы: * учитываются только новые кошельки, соответствующие заранее определенным критериям; * проводится анализ связанных адресов и исключаются повторяющиеся паттерны; * исключаются круговые прогоны, самопокупки и любые другие попытки искусственно завысить результат; * KPI рассчитывается по объему капитала, который фактически остается в экосистеме на момент проверки, а не по суммарному объему всех входящих средств; * при необходимости может использоваться минимальный срок удержания средств до момента их учета в KPI. Например, если KPI первого этапа составляет 4x, то при рекламном бюджете $50,000 на момент подачи proposal на второй этап в кошельках пользователей, привлеченных в рамках первого этапа, должно находиться не менее $200,000. Именно эта сумма считается выполнением KPI, а не общий объем всех покупок за весь период. Такая модель позволяет оценивать не только объем привлеченного капитала, но и его качество, поскольку ключевой метрикой является объем средств, который фактически остается в экосистеме GONKA. ———————- 12. Дополнительные материалы Для более детального ознакомления с proposal и нашей работой подготовлены следующие материалы: * Пример Telegram-канала, который демонстрирует структуру будущей воронки. Данный канал является демонстрационной версией и создан исключительно для того, чтобы показать общую механику, структуру и подход к работе. Ссылка: https://t.me/demo_chanel_gonka * Материалами по proposal — лендинги, креативы, видео рекламных кабинетов, примеры Telegram-воронки, информация о партнерах, записи AMA-сессий и другие подтверждения нашей работы Ссылка: https://t.me/proposaluniswap * Личный Telegram для связи — если у вас останутся вопросы по proposal или потребуется дополнительная информация, вы всегда можете связаться со мной напрямую. TG: @FrancesGreen9 --- ## Comments (1) ### 💬 Криптан *2026-07-23 19:01* · 👍 1 · 👎 0 Все это не работает, за такой бюджет который просят проще хорошего MM и маркетинг который реально работает на различных целевых площадках таких как DEXTools,DexScreener,CoinGecko и нормальные колы у топовых инфлов. --- --- [View on gonka.vote](https://gonka.vote/proposal/f341b83c-78f0-4ab2-b8fd-ddc7ac5d9c37) --- ## 11. Team GonkaGate Grant Request # 11. Team GonkaGate Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal 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: * Improve fault-tolerant infrastructure, routing, failure handling, observability, accounting, and load behavior. * Continue scaling GonkaGate toward thousands and later tens of thousands of requests per second. * Expand one-command setup tools for AI agents and developer tools. * Continue work on planned integrations, including: * Codex setup: https://github.com/GonkaGate/codex-setup * OpenHuman setup: https://github.com/GonkaGate/openhuman-setup * Finish the model performance analytics layer on model pages, including metrics such as throughput, latency, end-to-end latency, tool-call error rate, structured-output error rate, and reliability data. * Add payment and balance top-up flows so developers can continue using Gonka after free trial credits. * Implement USD top-ups by credit card. * Add crypto top-ups through NOWPayments with support for multiple currencies. * Improve billing flows, credit accounting, usage tracking, and spend reporting. * Continue improving the dashboard as an operations panel for Gonka developers. * Expand plugins and developer features, including search, file handling, structured output reliability, privacy controls, and practical tools for agents and applications. * Grow real developer usage through open-source tooling, documentation, examples, integrations, and targeted outreach. The goal is to make Gonka easier to adopt, easier to trust, and easier to use in production. ## What contributions or products has your team already developed for Gonka (with links pls)? 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. ### OpenAI-compatible Gonka API 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. ### Developer dashboard 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. ### Free developer onboarding Every registered user currently receives **$10 in free credits**, allowing developers to test Gonka models, agents, plugins, and integrations without a payment step. ### Open-source setup tools for agents 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 ### n8n integration 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 ### Plugins and application features Team GonkaGate added features around Gonka that developers need in real products, including: * Web Search plugin. * PDF input and file parsing support. * Response Healing for malformed structured outputs. * Privacy Sanitization for safer handling of sensitive data. * Structured Outputs. * Tool Calling. * Presets for reusable model and request settings. 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 ### Public docs, model pages, pricing, and status The team also built public developer-facing pages: https://gonkagate.com/en/models https://gonkagate.com/en/pricing https://status.gonkagate.com ## GNK Wallet Address gonka1lv55k52lvxz074yhr7kcne86srf7dse9pvyfhm ## Your Discord ID for Contact Purposes 279952435668320256 ## Email Address [daniil.koryto@gmail.com](mailto:daniil.koryto@gmail.com) --- ## Comments (1) ### 💬 Slava MyGonka *2026-06-11 07:59* · 👍 0 · 👎 0 Привет! Пользуюсь вашим Гейтом. Очень доволен. Особенно радует наличие классной документации. И то, что ее можно "скормить" Агенту. Вот тут похожее предложение от ваших конкурентов: https://vote.gonka.vip/tenders/f021bdb3-59f4-4906-bfaa-7b90b72019b1 Свое мнение по этому поводу я там высказал. Кратно: Поддержав один Gonka Брокер мы ставим в проигрышное положение других. Но есть идея по компенсации затрат. 1. Скажи, сколько инференса уже потрачено через твой Gate и сколько GNK ты за это заплатил? Вот это точно можно просить вернуть. Думаю, комьюнити одобрит. 2. Можно ли как-то подтвердить эти траты? 3. Скажи, а ты мог бы помочь с созданием документации для Хостов? Чтобы так же, как у тебя на сервисе было, через md или как там сделано? Через Контейнер? Т.е. чтобы можно было просто установить в бота и все. А дальше бот уже поставит. И хорошо бы, чтобы этот бот был на Gonka. Спасибо за классный сервис! --- --- [View on gonka.vote](https://gonka.vote/proposal/d2f317f0-541a-4d9f-bbac-d2d394906bf2) --- ## Предложение по развитию игровой экосистемы блокчейна через турнирные пулы вознаг # Предложение по развитию игровой экосистемы блокчейна через турнирные пулы вознаг 🔴 Expired **Author:** 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** — механизм интеграции игровых турниров с инфраструктурой блокчейна для привлечения пользователей, увеличения ликвидности и роста сетевой активности. --- ## Full Proposal --- ## Проблема Большинство игровых турниров работают по простой модели: * игроки платят взнос; * средства распределяются между победителями; * после завершения турнира деньги покидают экосистему. Такая модель не создаёт долгосрочной ценности ни для игры, ни для блокчейна. Одновременно многие блокчейны сталкиваются со следующими задачами: * привлечение новых пользователей; * рост TVL и ликвидности; * увеличение активности валидаторов; * расширение использования DeFi-протоколов; * стимулирование использования инфраструктуры сети. --- ## Решение Предлагается механизм **Tournament Yield Pools**. Игровые турниры становятся инструментом роста блокчейн-экосистемы. Вместо хранения турнирных взносов без использования средства автоматически направляются в существующие механизмы доходности сети. --- ## Как работает система ### 1. Вход в турнир Игрок оплачивает фиксированный взнос. Например: * $1 * 5 USDC * 1 токен сети Средства поступают в смарт-контракт турнирного пула. --- ### 2. Размещение средств Смарт-контракт автоматически распределяет средства между инфраструктурными механизмами блокчейна: #### Стейкинг валидаторов Средства участвуют в защите сети и получают вознаграждение за стейкинг. #### DEX-пулы ликвидности (опционально) Средства размещаются в пулах ликвидности и получают часть торговых комиссий. #### Протоколы кредитования (опционально) Средства могут использоваться в lending-протоколах сети для получения процентного дохода. #### AI-инфраструктура (опционально) Часть средств может направляться на финансирование вычислительных ресурсов, GPU и сервисов искусственного интеллекта внутри экосистемы. --- ### 3. Формирование дохода Все доходы от стейкинга, DEX и других протоколов аккумулируются в отдельном призовом пуле. Основной капитал продолжает работать внутри экосистемы. --- ### 4. Турнир Игроки соревнуются внутри игры. Победители определяются по игровым показателям: * времени прохождения; * очкам; * рейтингу; * турнирной таблице. --- ### 5. Выплата наград Полученный доход распределяется между лучшими участниками. Пример: * 1 место — 50% * 2 место — 30% * 3 место — 20% Модель может настраиваться под конкретную игру. --- ## Что получают игроки ### Победители Получают награды из дохода, который генерируется средствами турнирного пула. ### Остальные участники Их вклад продолжает работать внутри системы и участвует в формировании будущих наград. Каждый новый турнир предоставляет возможность улучшить результат и получить часть доходов экосистемы. --- ## Что получает блокчейн ### Рост TVL Каждый турнир увеличивает объём средств внутри сети. ### Рост активности DeFi Появляется дополнительный поток ликвидности в: * стейкинг; * или DEX; * или lending-протоколы. ### Привлечение пользователей Игровые проекты становятся источником новых пользователей для блокчейна. ### Увеличение использования токена сети Игровая активность напрямую связана с инфраструктурой блокчейна. --- ## Первая площадка для тестирования В качестве пилотного проекта предлагается использовать игру **HardCore Arena**. Текущий статус: * игра уже работает; * существует система турниров; * реализован редактор уровней; * развивается игровое сообщество. HardCore Arena позволит протестировать модель на реальных пользователях и подготовить инфраструктуру для подключения других игр. --- ## Необходимая разработка Для реализации требуется создание набора смарт-контрактов: * управление турнирными пулами; * интеграция со стейкингом; * интеграция с DEX; * интеграция с lending-протоколами; * расчёт и распределение наград; * система рейтингов и турнирных результатов. В классических турнирах призы состоятся из национальных проигравших участников. В пулах доходности турниров призы зависят от доходов, которые генерируют средства участников внутри независимой подвески: стейкинга, ликвидности пулов, кредитных протоколов и других показателей доходности. Это превращает игровую активность в источник роста сети, сеть — в источник дополнительных ценностей для игроков. --- ## Ожидаемый результат Создание универсального механизма, который позволит любому игровому проекту использовать блокчейн не только как платёжный слой, но и как инструмент формирования устойчивой экономики турниров. Модель способна масштабироваться на множество игр и стать дополнительным драйвером роста экосистемы блокчейна. --- ## Comments (4) ### 💬 Slava MyGonka *2026-06-12 22:04* · 👍 0 · 👎 0 Большинство турниров - это некоммерческое мероприятие. Часто оно даже убыточно. Часто, чтобы покрыть затраты кроме стартовых взносов еще привлекается финансирование: - спонсоры - реклама - гос поддержка Если и есть прибыль, то это - доход организатора. 2. В сети PoW нет стейкинга. Это есть только в сетях PoS. 3. Инвестиции в Пулы Ликвидности - рискованны. Идея с турнирами - прикольная. Можно на проведение турнира запросить средства из Комьюнити Пула. Но по чем турнир? Как прикрутить к турниру Gonka? ) --- ### 💬 Victor *2026-06-12 22:23* · 👍 0 · 👎 0 Я разрабатываю модель как универсальный механизм доходности турниров для экосистем. Если приземлить к Гонке: Пул/грантовый фонд сообщества Gonka может использоваться в качестве начальной ликвидности (начальной ликвидности) для первого набора турнирных хранилищ-контрактов в пилотной игре HardCore Arena. Каждый турнир = отдельное хранилище смарт-контрактов внутри экосистемы Gonka. Гонка в этой модели не обеспечивает призы напрямую, а обеспечивает инфраструктуру и стартовую ликвидность для запуска механизма. Дальнейшая система становится автономной за счет: вступительные первые игроки генерирование дохода внутри DeFi-стратегий (стейкинг/ликвидность/кредитование) Таким образом, Gonka выступает не как источник награды, а как инфраструктурный уровень для запуска стандартного механизма турнирного хранилища. --- ### 💬 Victor *2026-06-12 22:27* · 👍 0 · 👎 0 Модель не требует изменений в современном консенсусе Gonka (PoW/AI-ориентированная архитектура) и может быть реализована как механизм уровня приложения относительно обратной связи. При этом она совместима с будущими возможными стимул-механиками сетей (стейкинг, вознаграждения, программы ликвидности), если они будут выведены на уровень протокола или экосистемных инициатив. --- ### 💬 Mitch *2026-06-24 16:58* · 👍 0 · 👎 0 Не соответствует роадмапу, поэтому продуктовый комитет не примет. Считаю что мы не должны спонсировать истории по использованию монеты gonka как еще одной монеты с которой можно делать то же самое что и со всеми другими монетами блокчейнов. --- --- [View on gonka.vote](https://gonka.vote/proposal/fd9989ca-7c5b-4a2f-baf4-2465e6915ba6) --- ## Коэффициент для Kimi 2.6 - 1,87 # Коэффициент для Kimi 2.6 - 1,87 🔴 Expired **Author:** 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 нерентабельным и тем самым губит сеть. --- ## Full Proposal Проблема: Слишком высокий коэффициент. Решение: Уменьшить коэффициент пропорционально цене аренды 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](https://gonka.vote/proposal/d14f975e-0e40-4a94-81c5-715a02c3826e) --- ## Привлечение $3M+ нового капитала на Uniswap # Привлечение $3M+ нового капитала на Uniswap 🟢 Active **Author:** 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 --- ## Full Proposal Суть предложения 2. Кто мы 3. Что мы предлагаем 4. KPI и экономика проекта 5. Как будет работать воронка 6. Стратегия удержания пользователей 7. Финансирование 8. Вознаграждение команды 9. Отчетность и прозрачность 10. Что получает GONKA 11. Дополнительные материалы 1. Суть предложения Мы предлагаем реализовать маркетинговую кампанию, целью которой является привлечение нового капитала в экосистему GONKA. За 90 дней мы планируем построить систему, которая будет ежедневно привлекать новых пользователей и конвертировать их в инвесторов через покупку токена на Uniswap. Запрашиваемый рекламный бюджет составляет $300,000. Финансирование предлагается разделить на 6 последовательных траншей, при этом каждый следующий транш выделяется только после выполнения согласованного KPI предыдущего этапа. Основной KPI кампании — привлечение от $3,000,000 нового капитала на uniswap KPI построен по максимально консервативной модели и учитывает только первое финансовое действие пользователя. Повторные инвестиции, удержание аудитории, органический рост и сарафанный эффект в расчет KPI не включаются. По нашей внутренней оценке только платный трафик способен привлечь $6–7 млн нового капитала. Однако эти показатели мы сознательно не закладываем в обязательный KPI, чтобы не завышать ожидаемый результат. После завершения кампании GONKA получает не только новых пользователей, но и полностью готовую инфраструктуру привлечения капитала, которую сможет использовать для дальнейшего масштабирования. --------------------------------- 2. Кто мы Мы работаем в affiliate-маркетинге с 2023 года и сегодня самостоятельно управляем рекламным бюджетом более $70,000 в месяц. Основная специализация нашей команды — построение Telegram-воронок для привлечения инвесторов в различные проекты. Именно этим направлением мы занимаемся ежедневно: привлекаем целевую аудиторию, выстраиваем путь пользователя от первого контакта до первого депозита и постоянно оптимизируем каждый этап воронки на основе накопленной статистики. За последние годы мы накопили большой объем практических данных по различным географиям, хорошо понимаем экономику привлечения пользователей, стоимость подписчика, стоимость диалога и стоимость первого финансового действия. Это позволяет принимать решения не на предположениях, а на основе реальных данных. За время работы мы сформировали собственную систему привлечения и обработки инвесторов, которую ежедневно используем в своих проектах. Мы понимаем, что результат зависит не только от качества трафика, но и от качества дальнейшей работы с пользователем, поэтому уделяем одинаковое внимание каждому этапу воронки — от первого рекламного касания до первого депозита и последующего сопровождения. Именно этот опыт и лег в основу предложения, которое мы подготовили для GONKA. --------------------------------- 3. Что мы предлагаем Наша цель — построить для GONKA систему, которая будет ежедневно привлекать новый капитал через покупку токена на Uniswap. Мы не рассматриваем этот проект как разовую рекламную кампанию. Наша задача — создать работающую систему привлечения пользователей, которую можно масштабировать и использовать в долгосрочной перспективе. Основным показателем эффективности для нас является не количество просмотров, кликов или регистраций, а объем нового капитала, привлеченного в экосистему GONKA. Именно поэтому вся маркетинговая стратегия, воронка, обработка пользователей и система удержания строятся вокруг одной цели — максимального объема привлеченного капитала через Uniswap с его последующим удержанием --------------------------------- 4. KPI и экономика проекта Основной 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 млн и учитывает только первое финансовое действие пользователя. --------------------------------- 5. Как будет работать воронка Наша задача — провести пользователя от первого знакомства с проектом до покупки токена через Uniswap, а затем сопровождать его, увеличивая вероятность повторных инвестиций. Meta Ads Пользователь впервые знакомится с GONKA через рекламные кампании и переходит на лендинг. ↓ Лендинг Лендинг выполняет роль промежуточного этапа перед Telegram. Его задача — вызвать первоначальный интерес к проекту, сформировать базовое доверие и мотивировать пользователя перейти в Telegram. ↓ Telegram После перехода пользователь отправляет заявку на вступление в Telegram-канал. Бот автоматически принимает заявку, отправляет приветственное сообщение с базовой информацией о проекте и предоставляет контакты для дальнейшей коммуникации. Telegram становится основной площадкой взаимодействия с пользователем. Именно здесь за счет контента постепенно формируется доверие к проекту. ↓ Tora AI После первого контакта основную часть коммуникации берет на себя Tora Ai. Он отвечает на вопросы пользователей, сопровождает их, помогает разобраться в проекте и доводит большинство пользователей до первого депозита. ↓ Менеджер Если пользователь планирует крупную инвестицию или AI Agent определяет необходимость личной коммуникации, диалог передается менеджеру, который сопровождает пользователя до совершения покупки. ↓ Покупка токена через Uniswap Основная цель всей воронки — привлечение нового капитала через покупку токена на Uniswap. ↓ Долгосрочное сопровождение После первого депозита работа не заканчивается. Пользователь продолжает получать сопровождение через AI Agent и менеджеров. Основная задача этого этапа — укреплять доверие к проекту, сопровождать пользователя внутри экосистемы и увеличивать объем повторных инвестиций. --------------------------------- 6. Стратегия удержания пользователей Наша задача — не просто довести пользователя до первого депозита, а сделать его долгосрочным участником экосистемы GONKA. После первого финансового действия работа с пользователем не заканчивается. AI Agent и менеджеры продолжают сопровождать пользователя, отвечают на возникающие вопросы, помогают разобраться в возможностях экосистемы и поддерживают постоянную коммуникацию. Именно повторные инвестиции формируют основную часть долгосрочной ценности каждого привлеченного пользователя. Поэтому стратегия удержания является не отдельным этапом, а продолжением всей воронки. Весь контент, коммуникация, работа AI Agent и менеджеров будут направлены на формирование доверия к проекту, повышение вовлеченности пользователя и долгосрочное участие в экосистеме GONKA. Такой подход позволяет постепенно увеличивать LTV каждого пользователя, повышает вероятность повторных инвестиций и способствует формированию сообщества долгосрочных держателей токена. --------------------------------- 7. Финансирование Общий рекламный бюджет кампании составляет $300,000 и рассчитан на реализацию проекта в течение 3–4 месяцев. Мы предлагаем разделить финансирование на 6 последовательных траншей по $50,000. Такая модель позволяет сообществу контролировать реализацию проекта и выделять следующий транш только после подтверждения результатов предыдущего этапа. Первый транш полностью посвящен построению инфраструктуры, запуску рекламных кампаний и тестированию воронки. На этом этапе определяются наиболее эффективные географии, аудитории, рекламные креативы, подходы к обработке пользователей и оптимальная экономика привлечения капитала. Несмотря на то, что первый этап является тестовым, целевой KPI первого транша составляет 3x от рекламного бюджета. После завершения первого этапа воронка считается сформированной. Дальнейшая работа уже не связана с поиском рабочей модели — начинается ее масштабирование. Для второго транша целевой KPI составляет 7x+. Начиная с третьего транша и на всех последующих этапах целевой KPI составляет 10x+ от объема рекламного бюджета. Каждый следующий транш выделяется только после подтверждения выполнения KPI предыдущего этапа. Результат подтверждается на основании фактически привлеченного капитала через Uniswap. Мы считаем такую модель наиболее безопасной для сообщества, поскольку финансирование проекта происходит поэтапно и напрямую зависит от достигнутых результатов. --------------------------------- 8. Вознаграждение команды За реализацию проекта наше вознаграждение составляет: * 8% от рекламного бюджета — фиксированная часть; * 12% — выплачивается только после выполнения согласованного KPI. Если KPI не выполнен, переменная часть вознаграждения не выплачивается. Отдельно хотим отметить, что наше вознаграждение мы предлагаем выплачивать исключительно в токене GNK --------------------------------- 9. Отчетность и прозрачность Выполнение KPI будет подтверждаться на основании внутренней CRM-системы, в которой фиксируется каждый привлеченный пользователь. После первого депозита в систему заносится адрес кошелька пользователя, сумма первого депозита и дальнейшая история его взаимодействия с проектом. Именно на основании этих данных будет производиться расчет выполнения KPI по каждому этапу кампании. Один раз в неделю мы будем публиковать подробный отчет о ходе реализации проекта. В него войдут текущие результаты кампании, выполнение KPI, стоимость подписчика, стоимость диалога, результаты по различным географиям, текущие гипотезы, проведенные тесты, достигнутые результаты и планы на следующую неделю. При необходимости мы готовы проводить еженедельные AMA-созвоны, на которых будем подробно отвечать на вопросы сообщества и разбирать результаты кампании. Если в процессе реализации проекта у маркетингового комитета возникнут дополнительные вопросы, мы готовы в любой момент предоставить необходимую информацию и отдельно обсудить текущие результаты. --------------------------------- 10. Что получает GONKA После завершения кампании GONKA получает не только от $3,000,000 нового капитала, но и полностью готовую систему привлечения пользователей, которая остается в распоряжении проекта и может использоваться для дальнейшего масштабирования. В рамках реализации проекта GONKA получает: * Telegram-каналы с аудиторией в сотни тысяч пользователей, значительная часть которых уже будет вовлечена в экосистему GONKA и иметь опыт взаимодействия с проектом; * полностью протестированную маркетинговую воронку привлечения капитала; * все рекламные связки, лендинги, креативы и контент, созданные в рамках кампании; * AI Agent, обученный на десятках тысяч реальных диалогов с пользователями и оптимизированный для сопровождения пользователей, доведения до первого депозита, повторных инвестиций и долгосрочного удержания; * накопленную статистику, аналитику и результаты всех проведенных тестов; * готовую инфраструктуру привлечения капитала, которую можно использовать для дальнейшего масштабирования без необходимости создавать ее заново. По сути, GONKA получает не разовую рекламную кампанию, а полноценный маркетинговый актив, который продолжит работать и после завершения финансирования, привлекать новых пользователей и увеличивать объем капитала внутри экосистемы. --------------------------------- 11. Дополнительные материалы В Telegram-канале проводятся Google Meet / AMA-встречи, публикуются дополнительные материалы по proposal и подтверждения нашей работы. Ссылка: https://t.me/+VRgPAZqMaaczYmI8 --- ## Comments (24) ### 💬 Andrey Orlov *2026-07-03 19:06* · 👍 3 · 👎 0 1. Нет, вы немного неправильно поняли, я говорил именно про Telegram-каналы, Telegram-аккаунты мы тоже будем использовать, но это уже отдельная часть воронки 2. Нет, закупка рекламы будет осуществляться исключительно через Meta, Telegram мы используем уже как площадку для дальнейшего прогрева и коммуникации с пользователем 3. По поводу языка, здесь я тоже неправильно понял ваш предыдущий вопрос, подумал, что речь шла о языке самого proposal, Telegram-каналы не будут на русском языке, основное GEO у нас — Tier 1, поэтому основной язык будет английский, для отдельных стран возможна локализация под конкретный язык, например немецкий для Германии, русского языка в воронке не будет 4. Да, Telegram очень популярен именно среди той аудитории, на которую мы ориентируемся, это криптоинвесторы и пользователи Web3, поэтому для нашей модели привлечения это один из самых эффективных каналов коммуникации и прогрева пользователей --- ### 💬 Sergei Koniakov *2026-07-03 18:35* · 👍 2 · 👎 0 Добрый час! Одно дело, когда маркетолог берет 10% за купленную услугу. Услугу как правило поменять обратно на деньги без существенных потерь затруднительно. Другое дело, когда берут 10% за купленные GNK через Uniswap. Их легко можно обменять обратно на usdt с минимальными потерями, и опять пустить в ход на покупку GNK. Реальность такого привлечения инвесторов мы не сможем проверить. Они легко закроют сделку на обещанные 3млн$. И даже если изначальные мотивы светлые, мы никак не сможем это перепроверить. Вопрос: как вы сможете сделать невозможным «накрутку» результатов от ваших усилий? --- ### 💬 Andrey Orlov *2026-07-03 18:54* · 👍 2 · 👎 0 1. Да 2. Нет, мы используем Telegram-каналы с постами трех–пятилетней давности, после чего полностью адаптируем их под нашу воронку: создаём новый контент, нарративы и локализуем под каждое GEO, это делается для повышения доверия пользователей, что касается сотен тысяч пользователей - это обычная математика, которая рассчитывается исходя из бюджета и средней стоимости привлечения, но наша основная цель не подписчики, а депозиты и долгосрочные держатели токена 3. Тут нет какого-то одного обещания, под которое мы будем привлекать пользователей, вся продажа строится как единая система, начиная с момента, когда человек увидел рекламный креатив, затем попал на лендинг, в Telegram-канал, прошёл через прогрев и только после этого начал общение с обработчиком, который уже индивидуально выстраивает коммуникацию с каждым человеком, исходя из его возможностей, целей и возражений, глобально воронка одна, но подход к каждому пользователю индивидуальный, именно за счёт этого достигается максимальная конверсия и ltv 4. Почти весь бюджет будет направлен непосредственно на закупку рекламы, только в первом транше будет небольшая часть разовых расходов на создание всей инфраструктуры, Telegram-каналы, их оформление, подготовку, закупку аккаунтов, технические расходы и другие необходимые элементы воронки, со второго транша весь бюджет уже будет идти исключительно на масштабирование рекламы. --- ### 💬 Andrey Orlov *2026-07-03 18:55* · 👍 2 · 👎 0 Спасибо за вопрос, ответ очень простой Мы ведём учёт каждого привлечённого депозита через адрес кошелька, после того как пользователь совершает покупку, адрес его кошелька и сумма покупки фиксируются в CRM За счёт этого можно будет в любой момент посмотреть, какой кошелёк, на какую сумму купил токены, когда именно была совершена покупка, а также отследить его дальнейшее поведение, именно поэтому накрутить результат таким способом не получится Мы строим воронку под долгосрочных инвесторов, а не под разовые покупки, поэтому этот механизм изначально предусмотрен в proposal --- ### 💬 Andrey Orlov *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, а не на гипотетических сценариях, которые экономически не имеют логики --- ### 💬 Andrey Orlov *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, а не на предположениях, которых в нем нет. --- ### 💬 Andrey Orlov *2026-07-03 20:26* · 👍 2 · 👎 1 Давайте тогда тоже по фактам. Если следовать вашему сценарию с $100 000, которые «оборачиваются» 30 раз, то это было бы видно буквально всем, потому что мы фиксируем не только объём покупок, но и адреса кошельков, суммы, время покупки и их дальнейшее поведение, вся статистика будет доступна для проверки, поэтому повторяющееся движение одного и того же капитала очень быстро станет очевидным. Кроме того, цель proposal - не показать разовый объём покупок, а привлечь долгосрочных держателей токена, если кошельки постоянно покупают, продают и гоняют один и тот же капитал, это сразу будет видно по их истории, такой сценарий никак не соответствует нашим KPI. По поводу Telegram, здесь у вас тоже есть неточность, если бы вы внимательно ознакомились с proposal, то увидели бы, что обработка лидов строится на связке AI + операторов, а минимальный депозит в нашей модели составляет $500, речь не идёт о ручной переписке ради покупок на $10–100. Мы спокойно относимся к критике и готовы обсуждать любые риски, но хотелось бы, чтобы обсуждение строилось на том, что действительно написано в proposal, а не на сценариях, которые противоречат его логике и заявленной модели работы. --- ### 💬 Dem | Démíngān *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. --- ### 💬 Andrey Orlov *2026-07-05 14:56* · 👍 1 · 👎 0 Виктор, приятно видеть ваш вопрос! Сейчас подробно отвечу, так же все еще жду вас на созвон Сразу уточню один момент, мы никогда не строили аналитику вокруг конверсий Meta → лендинг или лендинг → Telegram, потому что для нашей модели это вторичные показатели, основными метриками для нас всегда были подписчик → сообщение и сообщение → депозит, именно по ним мы оптимизировали всю воронку и строили финансовую модель proposal. Для Tier-1 GEO стоимость подписчика в нашей модели обычно находится в диапазоне $4-6, иногда и ниже, конверсия подписчик → сообщение составляет примерно 35-50%, а сообщение → депозит при качественном трафике и нашей обработке находится в диапазоне 20-30%, именно эти диапазоны мы использовали при расчете proposal. Все эти показатели основаны на нескольких годах практической работы именно с этой воронкой, это не теоретические расчеты и не усредненные значения из интернета, за это время мы протестировали огромное количество креативов, лендингов, механик прогрева, обработки и аналитики, именно поэтому хорошо понимаем, какие изменения действительно влияют на стоимость привлечения и конверсии, а какие нет, именно этот накопленный опыт и лег в основу финансовой модели proposal. Если говорить о самих диапазонах, это не закрытая информация, любой человек, который профессионально работает с подобными воронками или регулярно общается с крупными медиабайинговыми командами, подтвердит, что подобные значения находятся в реалистичном диапазоне, если потребуется, в финальной версии proposal мы можем еще детальнее расписать математику по каждому этапу. --- ### 💬 Slava MyGonka *2026-07-03 18:58* · 👍 0 · 👎 0 Если я правильно понял, то речь идет не про телеграм каналы, а про телеграм экаунты, верно? 2. Закупка рекламы, это реклама в Телеграм? Я считаю, что зацикливаться на русском языке - это ошибка. Это не самый популярный в мире язык. Но начать можно и с него. Но не весь бюджет сюда. Только малую тестовую часть. Остальное - на другие языки. А дальше вопрос: Популярен ли Телеграм в других языковых комьюнити? --- ### 💬 Sergei Koniakov *2026-07-03 19:00* · 👍 0 · 👎 0 На вашей стороне CRM, какое-то общение и адрес кошелька. Автоматически зарегать 1000 кошельков при помощи ПО не составляет труда. Как и не составляет труда «написать» в телеграм по рекламной ссылке. Совершить автоматически 1000 покупок GNK на эти кошельки тоже не сложно. Так что ваше «накрутить результат таким способом не получится» - не соответствует действительности --- ### 💬 Sergei Koniakov *2026-07-04 08:21* · 👍 0 · 👎 0 Откровенно говоря, я исходил из того, что вы берёте деньги только за результат - 10% от привлеченных инвестиций в GNK на Uniswap. Эта сумма упоминалась в Gonka RU. На деле картина другая: - 8% рекламного бюджета - гарантированы по выплате; - 12% рекламного бюджета при достижении KPI; - плюс, здесь не упоминалось, но все мы знаем, что телеграм каналы и рекламные системы платят кэшбэк от рекламных бюджетов; Эти кэшбэки могут достигать 15-20-25% от рекламного бюджета; Кэшбэк упоминается не как критика в ваш адрес а-ля «Вы хотите заработать на Gonka!», а лишь как еще 1 фактор того, что цель заработать и мотивация может лежать не в плоскости достижения KPI (12% от рекламного бюджета), а в плоскости гарантированного получения кэшбэка от рекламы + 8% от рекламного бюджета. --- ### 💬 Sergei Koniakov *2026-07-04 08:23* · 👍 0 · 👎 0 Перечисление этих фактов это просто возражения, которые естественным образом возникают у любого заказчика, особенно в отношении новых исполнителей, с кем никогда не работал. Задача же исполнителя убедить и предложить такие варианты условий/отчетов, которые железобетонно успокоят каждое возражение --- ### 💬 Sergei Koniakov *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% Это если прогонять бюджеты через эти рекламные системы. У каждого телеграм канала есть еще отдельные партнерские программы. --- ### 💬 Алексей *2026-07-04 12:34* · 👍 0 · 👎 0 Ссылки и пруфы на вас можно и на ваши кейсы? --- ### 💬 Andrey Orlov *2026-07-04 13:32* · 👍 1 · 👎 1 Не совсем понятно, на основании чего вы пришли к такому выводу. На AMA мы подробно рассказали, кто мы, чем занимаемся и почему работаем именно как медиабайинговая команда, а не публичная компания. Мы также сразу сказали, что готовы пройти верификацию личности, предоставить документы и при необходимости провести личную встречу. Что касается портфолио, оно также показывалось публично. Мы публиковали материалы по нашей текущей работе и записи реальных рекламных кампаний. Поэтому утверждение, что «ничего нельзя проверить», не совсем соответствует действительности. Если, по вашему мнению, для принятия решения требуется дополнительная информация, это абсолютно нормальный запрос, мы готовы обсуждать, что еще можно предоставить в рамках публичного обсуждения. Но утверждать, что не было предоставлено вообще ничего, на наш взгляд, некорректно --- ### 💬 Andrey Orlov *2026-07-04 13:41* · 👍 0 · 👎 0 Да, подобные механизмы вполне можно реализовать. Например, учитывать только новые кошельки, которые соответствуют заранее согласованным критериям, анализировать связанные адреса и исключать повторяющиеся цепочки переводов, отдельно считать общий приток капитала и капитал, который фактически остался в экосистеме спустя заранее согласованный период времени. При необходимости можно согласовать минимальный срок удержания средств, после которого инвестиция будет учитываться при расчете KPI. Мы открыты к тому, чтобы до начала реализации совместно с маркетинговым комитетом и сообществом определить прозрачную методику подсчета, которая исключит круговые прогоны, самопокупки и любые попытки искусственно завысить результат. Более того, нам самим это выгодно, поскольку наша цель - привлечь долгосрочный капитал, а не показать красивую цифру в отчете --- ### 💬 Andrey Orlov *2026-07-04 13:43* · 👍 0 · 👎 0 Сергей, проблема в том, что вы снова обсуждаете модель, которой нет в нашем proposal, мы нигде не писали, что собираемся закупать трафик через Telegram Ads, Vitamin, eLama, Click.ru, Telega.in или любые другие подобные сервисы, наша модель построена на закупке трафика через Meta, то есть Facebook и Instagram, именно об этом и идет речь в proposal, поэтому перечисленные вами программы к нашей модели просто не относятся, мы не закладывали их в экономику, не учитывали в расчетах и не рассматриваем как источник дохода, именно поэтому мы и написали, что подобная мотивация в нашем случае отсутствует, давайте все-таки обсуждать то, что действительно описано в proposal, а не сценарии, которых в нем нет --- ### 💬 Andrey A *2026-07-06 08:11* · 👍 0 · 👎 0 Прошу предоставить: 1. Подробную информацию о вашей команде и выполненных кейсах. Либо информацию, кто из комьюнити выполнил верификацию этих данных. А также указать причины существующей анонимизации пропоузера. 2. Примеры креативов, посылов, воронок, которые вы хотите применять для привлечения к покупке. Понятно, что они не разработаны. Но хотя бы в общем какие будут нарративы. "Купите gnk , чтобы ... " Чтобы что? --- ### 💬 Andrey Orlov *2026-07-06 17:01* · 👍 0 · 👎 0 Андрей, приветствую. Скорее всего, мы уже не будем подавать proposal, потому что нам фактически перекрыли возможность его продвигать, нам закрыли доступ в основной чат Gonka, мы не можем писать в Talent Hub, а маркетинговый комитет перестал отвечать, в итоге мы не можем провести публичную AMA, хотя именно для этого она и планировалась. По первому вопросу, подробно о нашей команде и опыте мы уже рассказывали на первой AMA с маркетинговым комитетом, я также неоднократно говорил, что готов пройти любую верификацию, предоставить документы и лично созвониться, объяснить, кто мы и чем занимаемся, гораздо проще на звонке, чем текстом, именно поэтому мы и хотели провести открытую AMA для всех. Что касается кейсов, у нас есть отработанная воронка привлечения инвесторов, она не привязана к одной нише и применяется в разных вертикалях, меняется только продукт, аудитория и коммуникация, наша задача не заранее угадать правильный ответ, а быстро найти его через тесты и затем масштабировать то, что показывает лучший результат, именно этот подход мы и хотели применить для Gonka. По поводу причины анонимизации, честно говоря, не совсем понял вопрос, если сможете уточнить, с удовольствием отвечу. По второму вопросу, мы никогда не строим работу на предположениях, любая новая страна, продукт или аудитория начинается с тестов, именно тесты показывают, какие креативы, посылы, лендинги и воронки работают лучше всего, поэтому сейчас написать конкретный нарратив в формате «купите GNK, потому что…» было бы просто гаданием, именно эти процессы мы и хотели подробно разобрать на AMA, но, к сожалению, такой возможности нам не оставили. --- ### 💬 Slava MyGonka *2026-07-03 17:12* · 👍 0 · 👎 1 Привет! 1. Это только на русском языке, верно? 2. Телеграм каналы вы будете заново создавать? Сотни тысяч пльзователей, это, конечно, сильно, но реально ли? 3. Под какие обещания вы планируете приглашать Пользователей? 4. Куда конкретно будет тратиться бюджет? Покупка рекламы в ТГ и все? Спасибо! --- ### 💬 Sergei Koniakov *2026-07-03 19:41* · 👍 0 · 👎 1 «зачем нам для получения финансирования в $300,000 заводить собственные $3–5 млн и покупать на них GNK». Для того, чтобы прокрутить 3млн$ совершенно не нужно их иметь в наличии. Об этом знает любой, кто занимается арбитражом. Допустим, у вас в наличии только 100к$. Нужно его обернуть 30 раз. Все это может сделать специально для этого написанное ПО, которое разобьет их на мелкие суммы. « пришлось бы закупить около 30 000 Telegram-аккаунтов, а если учитывать, что один аккаунт стоит порядка $3–4». Вы же не хотите сказать, что у вас будут живые люди вести переписку с лидами на предмет покупки GNK на 10-100-500$? Судя по тому, как вы активно отрицаете реальность этого сценария, дальше дискуссию не продолжаю. То, что хотел высказать - уже высказал. --- ### 💬 Антон Луч *2026-07-04 11:53* · 👍 0 · 👎 1 Будут ли использованы какие-либо антифрод-правила: независимая верификация новых кошельков, лимиты на связанные адреса, отсев повторяющихся паттернов, требования к удержанию средств в течение времени и раздельный учёт брутто- и нетто-притока (считать не только сколько денег вошло, но и сколько денег реально осталось в проекте, без круговых прогонов и самопокупок). --- ### 💬 Viktor *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](https://gonka.vote/proposal/e0cc7d32-5d1a-49e1-94e8-0ca3d9ccbf6b) --- ## Universal Continuous GPU Benchmark for Gonka Hosts (vLLM v0.19+, Anti-Sybil) # Universal Continuous GPU Benchmark for Gonka Hosts (vLLM v0.19+, Anti-Sybil) 🔴 Expired **Author:** 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. --- ## Full Proposal 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). ## 2. Scope of Work The Contractor shall design, implement, test, document, and upstream a benchmark subsystem (hereinafter — *the Benchmark*) consisting of: 1. A **measurement agent** integrated into the ML Node, running alongside vLLM serving. 2. An **on-chain attestation protocol** for submitting and verifying samples. 3. A **scoring function** producing per-Host weight inputs consumable by the existing PoC pipeline. 4. A **reference verifier** runnable by any Host to independently re-check published artifacts. 5. **Operator tooling, dashboards, and full test/CI coverage.** ## 3. Functional Requirements ### 3.1. Continuous, Non-Interrupting Operation - The Benchmark MUST run as a persistent workload throughout the epoch (17280 blocks, ~24h), not as a discrete Sprint window. - The Benchmark MUST NOT pause, drain, or evict active inference requests. p99 inter-token latency degradation on the served production model MUST NOT exceed **3%** versus a clean baseline measured under identical concurrency. - The Benchmark MUST integrate with vLLM v0.19+ scheduler hooks (continuous batching, chunked prefill, prefix caching) and submit its workload as **first-class requests through the same engine** — not via a parallel CUDA context that would distort accounting. - KV cache pressure introduced by the Benchmark MUST be bounded by an operator-configurable ceiling (default: ≤5% of `gpu_memory_utilization`). - The Benchmark MUST yield CPU/GPU resources to user-paid inference under load (configurable QoS class; default: lower priority than paid traffic, higher than idle). ### 3.2. Universality Across Models - The Benchmark MUST produce comparable scores **independent of the model the Host currently serves**, including but not limited to: Qwen3-235B-A22B-Instruct-2507-FP8, dense models in the 7B–70B range, and MoE models with active-parameter counts from 7B to 50B+. - Scoring MUST normalize across: dense vs. MoE architectures, FP8 / BF16 / FP16 / INT8 precisions, single-GPU and tensor-parallel (TP=2/4/8) and pipeline-parallel deployments, NVLink and PCIe interconnects. - The Benchmark MUST define a canonical **reference workload**: a fixed set of synthetic transformer micro-tasks (attention, MLP/MoE routing, all-reduce, prefill, decode) executed on a **canonical Sprint-style transformer with randomized layer transformations** seeded by on-chain randomness, identical for every Host in a given measurement window. - Score units MUST be expressed in **AI Tokens per second per GPU-equivalent**, calibrated so that hardware tiers (e.g., A100 80GB, H100, H200, RTX PRO 6000 Blackwell, MI300X) map to a stable, monotonic ranking across the supported model spectrum. ### 3.3. Sampling and Randomization - Each epoch MUST contain **N ≥ 64 micro-measurements per GPU**, scheduled at **unpredictable times** derived from a VRF over `(epoch_seed, host_address, gpu_uuid)`. - The exact start time, duration, seed, model permutation, and input nonces of each micro-measurement MUST NOT be predictable by the Host more than **one block (~5s)** in advance. - Micro-measurement duration MUST be bounded (target: 200ms–2s) so that no single measurement materially affects served latency, while N samples aggregate to a low-variance epoch score (target: per-Host score CoV ≤ 2% across 3 consecutive honest epochs on identical hardware). ## 4. Security Requirements ### 4.1. Anti-Hot-Plug / Anti-Burst Hardware Attack - The Benchmark MUST detect and penalize Hosts that add GPUs only for measurement windows. Required mechanisms: - **Continuous GPU presence attestation**: each declared GPU MUST report a signed heartbeat at least once per **30s**, including `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. - GPUs that miss more than **0.5% of heartbeats per epoch** MUST be excluded from the epoch score for that Host. - **Hardware fingerprint binding**: a GPU's contribution to the epoch score MUST be discounted by `min(1, observed_uptime_in_epoch / required_uptime)` where `required_uptime` ≥ 95% of the epoch. - **Cross-Host fingerprint deduplication**: the same `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. ### 4.2. Anti-Sybil and Anti-Replay - All measurement inputs MUST be derived from on-chain VRF output; a Host cannot precompute outputs. - All measurement outputs MUST be committed via `(commit, reveal)` with a commit deadline ≤1 block after measurement and reveal ≤2 blocks after commit. Late reveals MUST be rejected. - Replay of a previous epoch's outputs MUST be detectable via VRF binding to `(epoch_id, block_height, gpu_uuid)`. - **No-mock guarantee**: the Benchmark workload MUST share weights, KV cache, and CUDA streams with the production vLLM engine, so substituting a synthetic high-throughput kernel for the real one is detectable via cache-coherency and timing-side-channel signatures. ### 4.3. Anti-Outsourcing - Sample latency MUST be measured **end-to-end inside the Chain Node**, not self-reported by the ML Node, with RTT bounds enforced (default: ≤50ms intra-Host, configurable). This makes it economically irrational to forward measurement workloads to a remote GPU farm. - Optional TEE attestation (SEV-SNP, TDX, or NVIDIA H100/H200 Confidential Computing) SHOULD be supported as a verification booster (higher Confirmation Ratio for TEE-attested Hosts). ### 4.4. Statistical Validation Compatible with Existing PoC - Verification MUST follow Gonka's existing **statistical (non-bitwise) validation** model: a Validator Host re-runs a random subset (1–10% per Reputation tier) of the Executor's micro-measurements and accepts results within a defined tolerance band (e.g., logits L2 distance ≤ ε, throughput within ±5% of declared). - Cheating detection MUST trigger the existing slashing path: full epoch reward forfeiture for the offending Host. ## 5. Technical Requirements | Area | Requirement | |---|---| | Language | Python 3.11+ for agent; Go for Chain Node integration; Rust acceptable for hot-path kernels | | Runtime | vLLM v0.19+, CUDA 12.4+, NCCL 2.21+, PyTorch 2.4+ | | GPUs | NVIDIA Ampere/Hopper/Blackwell (A100, H100, H200, B200, RTX PRO 6000 Blackwell); AMD MI300X support as stretch goal | | Interconnects | NVLink 3/4/5, NVSwitch, PCIe Gen4/Gen5, InfiniBand HDR/NDR | | Orchestration | Docker + docker-compose parity with existing `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 | ## 6. Deliverables 1. **Source code** in the `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. 2. **Reference Docker images** published to a public registry, signed with cosign. 3. **Whitepaper update** extending the existing `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. 4. **Migration guide** for existing Hosts, including a parallel-run period (≥2 epochs) where both legacy Sprint and Continuous Benchmark scores are produced and reconciled. 5. **Governance proposal text** ready for on-chain submission to activate the new scoring path. 6. **Operator runbook**: deployment, troubleshooting, expected metric ranges per GPU SKU. 7. **Conformance test suite** runnable by any Host as `inferenced benchmark verify`. ## 7. Acceptance Criteria The Benchmark is accepted when, on a testnet of ≥20 heterogeneous Hosts running for ≥7 consecutive epochs: - Inference p99 latency degradation ≤3% versus pre-deployment baseline. - Per-Host score CoV ≤2% across 3 consecutive honest epochs on stable hardware. - All four reference attack scenarios (hot-plug burst, output replay, remote outsourcing, kernel substitution) are detected with ≥99% true-positive rate and ≤0.1% false-positive rate. - Score ranking across Hosts is monotonic in raw GPU FLOPS×memory-bandwidth product within ±5% noise, independent of which model the Host serves. - Verifier re-execution of a random 10% sample yields ≥99.5% agreement with Executor-published artifacts on honest Hosts. --- ## Comments (12) ### 💬 Evgenii Maksimenkov *2026-04-25 18:41* · 👍 2 · 👎 0 What are your thoughts? --- ### 💬 Alex A.A. *2026-04-25 19:05* · 👍 2 · 👎 0 Начало положено! Язык работает. --- ### 💬 Alex A.A. *2026-04-25 19:09* · 👍 1 · 👎 0 Через телеграм можно зайти. Круто! --- ### 💬 Nikita *2026-04-25 19:45* · 👍 1 · 👎 0 🔥🔥🔥 --- ### 💬 Alisa Chudinov *2026-04-25 19:47* · 👍 1 · 👎 0 Very intresting! --- ### 💬 Mikhail Chudinov *2026-04-25 19:50* · 👍 1 · 👎 0 Изучаю пока функционал сервиса. Проблема с мульти PoC точно есть, и над ней надо думать. Но такой бенчмарк не единственный подход. Думаю что надо думать о полностью рыночном механизме, который не может быть заменен бенчмарком. --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-26 19:57* · 👍 1 · 👎 0 Тест. Интересно, как работает ) Не обращайте внимание ) --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-26 19:58* · 👍 0 · 👎 0 Тестирую функционал тоже ) Не обращай внимание ) --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-26 19:59* · 👍 0 · 👎 0 Hi! How is it going?! --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-26 20:09* · 👍 0 · 👎 0 https://www.youtube.com/shorts/WTSRfhsLYwQ --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-29 04:45* · 👍 0 · 👎 0 А сколько проверка PoC занимает сейчас ресурсов? Предлагаемое решение будет забирать до 3%, верно? 2. Когда у сети будет больше Инференса, не решит ли это проблему с читерами? Не будут ли они улетать в МисРейт тогда? --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-26 19:57* · 👍 0 · 👎 1 But what will happend if I reply in English? --- --- [View on gonka.vote](https://gonka.vote/proposal/673770df-0b72-4d04-a038-f8c12546817f) --- ## 7. Team Epokha AI / epokha.ai Grant Request # 7. Team Epokha AI / epokha.ai Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal 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: * Build the core platform with a dashboard, chat interface, memory, workflows, and integrations. * Launch **100+ ready-to-use AI agents** for automation, research, content creation, monitoring, and productivity. * Add integrations with Telegram, Discord, Gmail, Google Calendar, GitHub, RSS feeds, and other external services. * Create tutorials and educational content around practical AI agent use cases. * Publish demos, videos, and real-world examples powered by Gonka. * Promote Agent Gonka through community engagement, social media, and content marketing, including Telegram, X, and YouTube. 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. ## What contributions or products has your team already developed for Gonka (with links pls)? 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: * Social media data collection and content creation. * Marketing automation. * Research and intelligence gathering. * Market monitoring. * Business process automation. * Scheduled cron jobs. * Personal assistants. * Chat-based interfaces. ## GNK Wallet Address gonka158pj5tn26n46ffaw553dkf3e7xjfxahj0s5xug ## Your Discord ID for Contact Purposes 830865664000000010 ## Email Address [johnmentalpt@gmail.com](mailto:johnmentalpt@gmail.com) --- ## Comments (1) ### 💬 Slava MyGonka *2026-06-11 07:24* · 👍 0 · 👎 0 Прикольно! А чем скилы для агента на GonkaAI отличаются от скилов на других LLM? 2. Что такое Скил? Это md файл для агента? 3. О каких агентах идет речь? Hermes? Open Claw? Идея показать 100+ вариантов использования Агентов на Инференсе Gonka мне нравится. 4. Сколько GNK вы бы хотели получить за 3 месяца? 5. Когда планируется выход продукта? 6. Это коммерческий продукт или некоммерческий? 7. Можно посмотреть на руководство какое-нибудь, которое вы уже создали? 8. Планируются ли другие языки, кроме английского? Спасибо за инициативу! --- --- [View on gonka.vote](https://gonka.vote/proposal/0395efa6-8eef-4d83-85cb-83d36a937f96) --- ## Улучшения для vote.gonka.vip # Улучшения для vote.gonka.vip 🔴 Expired **Author:** 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 Любые идеи, хочушки, плюшки и т.д. по улучшению этого сервиса. Давайте сделаем конфетку секси :) --- ## Full Proposal Основная ветка для улучшения работы этого сервиса. Топовые идеи - вынесу в тело. --- ## Comments (13) ### 💬 Alex A.A. *2026-04-25 20:11* · 👍 1 · 👎 0 1. На главной страницы возможно надо отображать топ тендоры: Но вопрос, как счетать что есть топ ? По коментам, звездам, голосам... ? 2. Добавить статистику коментариев ( количество) в виджет на основной таблице. 3. Если потом будет мало телеги (входа) можно дискорд прикрутить, но тут с безопасностью чуть по другому... --- ### 💬 Evgenii Maksimenkov *2026-04-25 20:15* · 👍 1 · 👎 0 1. Сейчас по умолчанию установлена сортировка по количеству голосов (но можно вручную задавать) 2. Уже есть бейдж. 3. Да хорошая идея P.S. Изменять тело предложения нельзя после создания, это сделано специально. Чтобы не подменять условия, когда голоса уже отданы. --- ### 💬 Alex A.A. *2026-04-25 20:30* · 👍 1 · 👎 0 Многое уже увидел. Вы обновляете быстрее чем идеи приходят. 1. Что насчет закрепления каких нибудь пропозылов... Кпримеру этого на начальный этап, что бы улучшить сервис. --- ### 💬 Alex A.A. *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 --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-29 04:49* · 👍 1 · 👎 0 Хотел приложить скрин, и не могу, т.к. не поддерживает месенджер картинки. Нужно сделать прокрутку в самый низ и в самый верх. Чтобы мышкой долго не крутить. 2. После публикации сообщения не понятно, опубликовано оно или нет. Может, переводить фокус на сообщение и там же внизу окно для ввода оставить? Второе. --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-29 04:50* · 👍 1 · 👎 0 3. Сократить шапку на главной странице Иначе видно только три первых карточки. Пусть лучше будет видно больше карточек без прокрутки. --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-29 04:52* · 👍 1 · 👎 0 5. Дать возможность исправлять сообщение и удалять его. --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-29 04:56* · 👍 1 · 👎 0 6. Уменьшить количество символов в Заголовке. Пусть пишут короче. https://prnt.sc/EitFZF9w8aKa 7. Через ГонкаAI дать возможность создавать краткую версию описания. Я не могу столько читать. Не знаю, как это отобразить в Интерфейсе, но важно, чтобы можно было вкратце посмотреть. Может, дать такую возможность тем, кто формирует предложение? Или просто добавить кнопки такие: Сократить через GonkaAI и Показать Полностью --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-29 04:58* · 👍 1 · 👎 0 11. Добавить сюда всплывающие примечания: https://prnt.sc/ax9mlD-RDtuC А то я не понимаю, что такое "Грант". --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-29 05:16* · 👍 1 · 👎 0 77. Дать возможность видеть Пропоузелы в виде Таблицы. Т.е. переключать режимы отображения. --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-29 04:51* · 👍 0 · 👎 0 Скрин https://prnt.sc/ewucmviwxzPL --- ### 💬 Evgenii Maksimenkov *2026-06-03 11:20* · 👍 0 · 👎 0 Проверка уведомлений --- ### 💬 Alex A.A. *2026-06-03 11:23* · 👍 0 · 👎 0 А если так, кому прийдет уведомление ? --- --- [View on gonka.vote](https://gonka.vote/proposal/b7083379-6dc5-4198-b9b0-1b8b98f0ac01) --- ## Gonka Media Library by Saccade # Gonka Media Library by Saccade 🔴 Expired **Author:** 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 --- ## Full Proposal Proposal — Gonka Media Library ## Project **Gonka Media Library — Explainer Library & Platform** ## DAO **Gonka** ## Scope Explainer series **20 episodes, 40 min total** + web download & self-branding platform. ## Deliverables - **Explainer library** — 20 episodes, 40 min total, grouped into 4 horizontal long-form films, 16:9. - Every episode is also released as a standalone vertical short, 9:16 — 20 shorts. - Editable source / project files included. - **Localization** — Russian & English subtitles + base Russian & English voiceover on every episode. - **Self-branding platform** — web app to browse and download the videos and sources, with the user’s logo auto-inserted on each video’s intro & outro. - Built, hosted and maintained by Saccade. ## Timeline - Production & platform build: approximately 4 months. - Target delivery date: **28 October 2026**. - Topic list and episode breakdown agreed with the DAO before production. - Platform delivered together with the video library. - Hosting & support continue after launch. ## Price Full package: everything in Deliverables, plus 1 year hosting & support. **Total: 40,000 GNK + 74,000 USDT** Fixed package price · paid in two assets. ## Not Included - Paid distribution, ad spend and media buying. - Bespoke per-client video edits beyond the automated self-branding. ## Support & Updates - Platform hosting, compute & storage included for 1 year from launch. - Every 3 months Saccade batches all in-scope updates, including changed figures & data where the content itself stays the same, and applies them across the library at no extra cost. - Updates delivered within 1 month of each cycle, depending on volume. - New content, new episodes or anything beyond the agreed topic list quoted and billed separately. ## Payment & Terms - Once approved by the DAO, this proposal is the working agreement — no separate signature required. - **100% on approval** — released by the DAO multisig once the vote passes, on-chain, net to Saccade. - Delivery: video library handed over + platform live. - Acceptance: the DAO returns one consolidated set of notes within 5 business days. - No notes = accepted. - Off-spec items are corrected to the agreed spec. --- [Portal](https://saccade-gonka-ai.vercel.app/) [Proposal](https://saccade-gonka-ai.vercel.app/pdf/gonka-proposal.pdf) --- **Saccade Media House** [t.me/JackyBlack](https://t.me/JackyBlack) · [saccade.media](https://saccade.media) --- ## Comments (2) ### 💬 Andrey A *2026-07-06 08:29* · 👍 1 · 👎 0 Абсолютно нет вопросов к качеству роликов и есть личное желание их увидить. Вопросы возникают: 1. "Приемка: DAO предоставляет один консолидированный список правок в течение 5 рабочих дней." Срок маленький, учитывая отсутствие в DAO людей, которые займутся этим фултайм. Более подойдет поэтапное принятие. 2. Пользователем материалов станут (те, кто станут брендировать): - пулы (в данный момент почти все МЛМ) - гейты При этом возможностей для медиадистрибьюции они имеют немного. Гораздо лучше запустить дистрибьюции на общие ресурсы gonka , откуда уже направить их в те же гейты. Иначе получается, что мы создаем качественные и дорогостоящие материалы, на распространение которых средства практически не будут потрачены. --- ### 💬 Jack Chernov (Jack Black) *2026-07-06 14:31* · 👍 0 · 👎 0 Привет, Андрей! Спасибо большое за вопрос. 1. Срок можно увеличить, мы никуда не убежим - мы участники сообщества. Просто хочется какой-то срок, чтобы не растягивать. 2. Пулы, гейты - на самом деле и во время участия в выставках это пригодится и для разбрасывания по инфлам как интеграция (частично) - тоже да. То есть если инфлюенсер рассказывает в интеграции про механику - он показывает на экране схему, которую мы визализируем по красоте. В некоторых случаях это может быть как интгерация полноценно. 3. По дистрибуции мы ведем переговоры с Soul Publishing. Пока есть "кивок головой", но деталей мы еще не обсудили это всячески стараемся стимулировать. Сегодня очередная попытка будет. ___ По сути мы хотим создать гибкий медиа набор, который можно будет содержать в порядке и дистрибутировать оперативно в разных направлениях. Это поможет в том числе и в медиа коллаборациях, чтобы партнер понял детали, не погружаясь в вайт пейпер. Вот посмотри пример нашего экслпейнера https://saccade.media/ru/unboring-explainer Он объединил компанию вокруг инструмента и вдохновил на его использование. Не просто объяснил сухо, а местами улыбнул. В Гонке мы хотим сделать в таком ключе, просто чуть менее "няшно". Но все равно, душевно. Спасибо за дискуссию, всегда на связи! @jackyblack --- --- [View on gonka.vote](https://gonka.vote/proposal/f215996d-e562-42b5-b2b1-400226e612fa) --- ## Вестинг: почему его стоит отменить сейчас # Вестинг: почему его стоит отменить сейчас 🟢 Active **Author:** 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. --- ## Full Proposal **Вестинг: почему его стоит отменить сейчас** ## **Коротко** Вестинг решает не ту задачу, которую мы думаем. Он не защищает цену — это доказано. Он определяет, **кто вообще может участвовать в сети**. У него есть плюс, и мы его честно разберём. Но минус перевешивает. Отменить его стоит не потому, что это спасёт цену. А потому что когда продукт будет готов и придёт спрос — сеть должна быть привлекательна и удобна для поставщиков GPU. Поставщикам GPU нужны деньги сразу, а не через пол года, причем понятное количество денег в USD, а не неизвестное. --- ## **Начнём с плюса** Не буду делать вид, что у вестинга нет смысла. Смысл есть, и его стоит признать. **Вестинг замедляет движение денег.** Токены, которые заперты, не продаются. Меньше токенов на рынке — меньше давления на цену. Это правда, и это работает. Экономисты называют это скоростью обращения. Идея простая: если одна и та же тысяча токенов за месяц десять раз переходит из рук в руки — давления на цену больше, чем если она лежит. Вестинг делает так, чтобы лежала. **Второй плюс: сигнал.** «180 дней вестинга» читается со стороны как «команда серьёзная, майнеры не сбегут завтра». Биржи это смотрят, аналитики это смотрят. **Третий: он сглаживает шок при старте.** Первые полгода после запуска сети продавать было буквально нечего — всё в локе. Это дало проекту время. Всё это настоящее. Теперь посмотрим на цену этих плюсов. ## **Что произошло на самом деле** **Январь: цена 1.5. Сейчас: 0.15. Падение в 10 раз за полгода.** Всё это время вестинг работал на полную. 180 дней, у всех, без исключений. Он не защитил ничего. Дальше — вес сети. Пик был 11 млн, сейчас 559 тысяч. **Падение в 20 раз.** Мощность ушла быстрее, чем цена. Полгода механизм работал в идеальных условиях — и цена всё равно упала в 10 раз. Это не значит, что вестинг бесполезен. Это значит, что **его эффекта не хватило**. И стоит понять, почему. ## **Почему так вышло** Разберём, как вестинг работает на самом деле, а не как кажется. **У нас линейный разлок: каждый день приходит 1/180 от намайненного.** Представь майнера, который работает уже полгода. Что он получает сегодня? * Сегодня разлачивается 1/180 от того, что он намайнил 180 дней назад * Плюс 1/180 от намайненного 179 дней назад * Плюс 1/180 от 178 дней назад * ...и так 180 раз Складываем: он получает сегодня **примерно столько же, сколько намайнил сегодня**. Не ровно столько — тут две оговорки: **Оговорка 1: эмиссия падает.** У нас непрерывный халвинг, награда за эпоху плавно уменьшается. Значит то, что разлачивается сегодня, было намайнено при более щедрых условиях. Разлок получается чуть **больше** сегодняшней добычи. Забавно, но это значит, что вестинг при падающей эмиссии не сглаживает предложение, а слегка **увеличивает** его — тянет более щедрое прошлое в настоящее. **Оговорка 2: вес сети менялся, и сильно.** Полгода назад в сети было 2 млн веса, сейчас 559 тысяч. У кого доля выросла — тот сегодня майнит больше, чем разлачивает. У кого упала — наоборот. Но принцип от этого не меняется: **Для того, кто работает больше 180 дней, вестинг превращается в постоянный поток.** Не в блокировку. Он получает деньги каждый день, просто со сдвигом на полгода и с поправкой на то, как менялись эмиссия и его доля. ## **Вестинг не механизм удержания** Влияет ли вестинг на тех, кто решил перестать майнить? Нет — он выключит ноду, а хвост всё равно придёт 180 дней. Намайнил один день — будешь получать разлок полгода. Значит вестинг — это **не механизм удержания**. Он не создаёт ни одной причины остаться. Он создаёт только барьер для входа. ## **Но есть вещь похуже** Вот тут главное. Майнер арендовал сервер за $30 000 / мес. Он оптимизирует железо, следит за аптаймом, дебажит ноду. Это его работа, он в ней профи. Что он получает? Не деньги. Он получает обещание токенов на полгода вперёд, по цене, которую никто не знает. Причём это не разовая история. Он всё время держит примерно 90 дней добычи в вестинге. Продал сегодняшний разлок — завтра прилетит следующий. Пока майнишь — не избавишься. Он не хотел держать эти токены. Он не может от них отказаться. **Мы взяли специалиста по железу и пытаемся заставить его быть инвестором.** ## **Что из этого следует** Посчитай окупаемость сервера при вестинге. Ты арендуешь железо за $30 000 / мес сегодня. Окупаемость зависит от цены GNK, которая определится в течение следующих 180 дней. Ты её не знаешь. **Это не сложная задача. Это нерешаемая задача.** Величина, от которой всё зависит, лежит в будущем. Посчитать нельзя. Можно только угадать. Кто в такой ситуации зайдёт? Только тот, у кого **есть мнение о цене GNK**. То есть инвестор. ## **Кто сейчас майнит?** Коллективные пулы по сути вышли из игры. Мой Gonka.Top обслужил последнего клиента 2 недели назад, с тех пор спроса нет вообще. Ancapex майнит на 4xB200 и все. Остальные вообще закрылись. Даже топовый МЛМ пул перестал майнить. Средние инвесторы, которые заходили через гонку на 10-100k$ через майнинг на арендованых серверах тоже похоже вышли из игры, судя по моему опросу. Кого не спрошу “я уже не майню”. Знаю 3х человек, фанатов, которые купили под гонку по одному серверу\! Из них самый лучший всего лишь с H200. Похоже что сеть держится всего на нескольких крупных инвесторах, которые уже вложили не один миллион $ в майнинг gonka, и которые поддерживают сервера по сути как защита своих инвестиций, чтоб гонка не закрылась вообще. Эту же позицию и BitFury озвучивали на AMA “мы запустим свои сервера, и до нуля не дадим упасть сети, пока продукт не будет готов”. Может уже и запустили. Может быть конечно, кто то из крупных просто еще не набрал запланированный объем, и его все устраивает, но в этом есть большие сомнения. **HyperFusion** — казалось бы, вот он, настоящий провайдер. Своё железо, каналы сбыта, контакты с бизнесом. Но в Gonka он ведёт себя **как инвестор**: майнит за свои, несёт токенный риск, ждёт роста. Не потому что хочет — потому что других условий нет. Кого нет? **Провайдера GPU, который работает как провайдер.** Того, кто считает: час 8xB300 стоит $X, продаю за $Y, маржа Z%. Который продаёт часы в Vast.ai, Runpod, напрямую бизнесу — и параллельно продавал бы в Gonka, если бы сходилось. Его нет, потому что **сойтись не может**. Ему платят токеном, которого он не просил, по цене, которую узнает через полгода. ## **Про сложность, которую мы создали** Инвесторы всё же находят способ. С ноября по февраль это работало так: инвестор давал оператору майнинга вроде меня доллары на сервер и его работу, а майнинг шёл на кошелёк инвестора. Роли разделялись: оператор занимался железом, инвестор нёс риск. Хорошая конструкция. Но посмотрите, сколько там лишнего: * Инвестору надо **найти** оператора. Рынка нет — ищут по чатам и рекламе. * Надо **поверить** незнакомому человеку\\организации. * Надо **сравнить** операторов между собой. Публичных метрик нет — берут того, кого нашли. * Надо разбираться с кошельками, подписями, адресами выплат. И всё это ради чего? Чтобы получить GNK. **Который можно просто купить на Uniswap.** Вся эта конструкция существует не потому, что она кому-то нужна. Она существует потому, что **майнинг и инвестирование склеены вестингом**, и чтобы их разлепить, приходится строить ручной костыль из доверия и переговоров. Раздели их в протоколе — и костыль не нужен. Оператор получает GNK и продаёт, сразу получая небольшую маржу в USD. Инвестор покупает на Uniswap, когда хочет и сколько хочет. Каждый делает то, что умеет, никто никого не ищет. ## **И вот главное** Допустим, кор-тим всё сделал. Инференс стабилен, багов нет, динамический прайсинг работает, цена реальная. Пришёл спрос. Кто придёт его обслуживать? Провайдер с 50 GPU смотрит на Gonka и видит: платят токеном, полгода лока, окупаемость непредсказуема. Он идёт в OpenRouter — там платят долларами послезавтра. **Он не придёт. Ни при каком спросе. Ни при какой цене инференса.** Не потому что Gonka плохая. Потому что **условия входа написаны не для него.** ## **Плюс против минуса** Теперь сведём. **Плюс:** вестинг замедляет движение денег. Меньше продаж — цена держится лучше. Эффект реальный, но ограниченный: мы видели, что его не хватило даже близко. **Минус:** вестинг не пускает в сеть тех, кто мог бы её вырастить. Почему минус тяжелее? Замедление денег — это **разовый и небольшой эффект на цену**. Он работает в моменте и не накапливается. Мы прожили полгода с максимальным вестингом — и получили −90%. А рост сети — это **фундамент цены**. Больше мощности → лучше качество и скорость → больше клиентов → больше реальный спрос на GNK → выше цена. Это не разовый эффект, он множится. Мы платим вестингом за небольшое замедление продаж, а взамен отдаём **саму способность расти**. И это видно по цифрам: за полгода вес сети упал в 20 раз, а цена — в 10\. Мощность падала **быстрее** цены. Мы защищали не то. ## **Про аргумент «те, кто в Гонке, всё равно холдят»** В сообществе звучит мысль: участники майнят ради того, чтобы держать GNK. Они верят, что токен будет работать в большой сети, и не собираются его сбрасывать. Вестинг им не мешает — они и так холдят. А раз никому не мешает, то и трогать нечего. Для тех, кто уже здесь, это правда. Они действительно холдят. Мы это видим прямо сейчас: разлоченное лежит и не продаётся. Но вопрос не в тех, кто уже здесь. Вопрос в тех, кого здесь нет. Провайдер с 50 GPU не собирается холдить GNK. Он не верит и не не-верит — у него просто нет мнения. Он продаёт вычисления, у него счета за стойку и электричество в долларах каждый месяц. Холдить чужой токен полгода — это не его бизнес. Вестинг написан под тех, кто и так холдит. Для них он безобиден — и именно поэтому они его не замечают. А для тех, кто мог бы прийти со своим железом и просто работать, он закрывает дверь. ## **Почему именно сейчас** Тут два довода, и оба про момент. **Первый: Обвала в разы думаю не будет.** Посмотрите на факт: у тех, кто сидит в вестинге, уже накопилась куча разлоченного. **И они его не продают.** Цена плохая, ждут. На Uniswap за последний месяц в среднем в день 29k GNK покупки и 64k продажи. При том что ежедневно разлок более 250к GNK. Значит вестинг их уже не держит. Они и без него не продают. Убери его завтра — они продолжат не продавать. Если же сделать это изменение на росте, отмена вестинга вероятно может затормозить рост, это значимое изменение и он может отпугнуть инвестора. А сейчас пугать некого. Убирать вестинг, и делать прочие радикальные изменения надо на дне. Не на восстановлении. **Второй, более важный: условие входа должно существовать раньше входящего.** Скажут: «сейчас отмена бесполезна, притока всё равно нет». Да. Именно поэтому её надо делать **сейчас**. Дверь строят до того, как придут гости. Если мы дождёмся продукта и только потом откроем — потеряем полгода на то, чтобы провайдеры узнали, поверили, посчитали, зашли. А в момент запуска мощность нужна сразу. ## **Когда будет готов продукт?** Просто отмена вестинга конечно не спасёт сеть. Сеть спасёт продукт. Это работа кор-тима в первую очередь, и она займёт столько, сколько займёт. Там много чего надо сделать, начиная с переделки PoC и дополнительных механизмов в девшардах. Кроме фикса багов уже известных, и поиска новых. Радует что не только кор тим работает над протоколом, но и сторонние программисты. Что нужно как минимум: * работающий динамический прайсинг, подстройка цены под загрузку нод модели * мотивация майнерам хостить самые востребованные модели (сейчас например на B300 хостят MiniMax и GPU простаивают, в то время как малое количество нод с Kimi перегружены запросами) * схема для быстрого тестирования и онбординга новых моделей В идеале вообще уйти от PoC и присваивать вес за реально произведенную полезную работу. Это на словах простая идея, но техническая реализация ОЧЕНЬ сложная, по сути нет даже пока ее готовой логической архитектуры (я видел только наброски под кодовым названием WASP). Усложняется все тем \- что у нас децентрализованная сеть, доверять можно только консенсусу, и учесть надо все возможные векторы атаки технические и экономические манипуляции. ## **Тогда зачем отменять вестинг?** Открыть двери в майнинг не только инвесторам, но и реальным GPU провайдерам. Можно построить идеальный прайсинг. Но если платят через полгода и тем более неизвестно сколько \- провайдер не придёт. Отмена вестинга не достаточна. Но она желательна, если мы хотим догнать по комьюту большие корпорации. И отменять лучше сейчас, иначе мы построим продукт, который неудобен поставщикам GPU, а мы же делаем сеть именно чтоб им было удобнее поставить свои GPU в гонку, проще и выгоднее. ## **Что конкретно предлагается** **Убрать вестинг с новой эмиссии.** Параметр меняется глобально: с даты X всё, что намайнено, приходит сразу. Старые локи продолжают разблокироваться как есть. ## **Итог** У вестинга есть плюс: он замедляет продажи. Мы его признаем. Но он же **склеивает две разные роли в одну**. Хочешь майнить — будь инвестором. Не хочешь быть инвестором — ищи того, кто согласится, договаривайся, согласовывай. Собсно боль поставщиков GPU “поиск клиента на мощности” остается не решенной, меняется только тип клиента, нужна реклама, отдел продаж и работа с клиентами. А должно быть \- поставил новые GPU, настроил, подключил к гонке и зарабатываешь, как майнинг биткоина. Инвестору не нужен майнер на самом деле. Ему нужен GNK — и он лежит на Uniswap. Сейчас инвестор ищет майнера, просто как более дешевую точку входа, и готов за это получить менее качественную, залоченную гонку. Плюс небольшой и разовый. Минус — структурный: он ограничивает **скорость роста сети**. А рост сети влияет на цену сильнее и дольше, чем любое замедление продаж. Мы готовимся к тому дню, когда продукт будет готов. В этот день нам нужно, чтобы человек с 50 GPU мог посмотреть на Gonka и посчитать — а не гадать. Сегодня посчитать нельзя. Давайте это исправим. --- ## Comments (8) ### 💬 Dem | Démíngān *2026-07-18 08:00* · 👍 2 · 👎 1 1. что если автор просто попросил llm отформатировать в MD? 2. команда может и знает, как поступать, но они не голосуют. --- ### 💬 Mitch *2026-07-18 14:06* · 👍 1 · 👎 0 Расшарил чат, в результате которого я сделал эту статью. https://claude.ai/share/bdcf32ba-920b-434f-ba62-9a686f13f2f5 --- ### 💬 Slava MyGonka *2026-07-18 08:26* · 👍 0 · 👎 0 А еще мне интересно, кто эти люли, которые покупают на 29К в день. И покупают еще не самым простым способом - через Uniswap и WGNK. Нам бы увеличить в 10 раз это количество людей, и тогда вся эмиссия продавалась бы за 1 день. Предлагаю приложить усилия к популяризации токена GNK как инвестиционного актива. --- ### 💬 Kirill Smerkins *2026-07-18 09:37* · 👍 2 · 👎 2 1. Ты реально не можешь отличить форматирование от реального АИ содержания? Тебе указали на паттерны - двойные обороты, длинные тире, структура текста и заголовков - 80% именно создано АИ. А запрос был примерно такой - "накидай аргументы в пользу отмены вестинга". Справочно для других: Dem лично знаком с Митчем, отсюда у него всегда будет преобладать защищающая его позиция. 2. Никто не спорит что команда "может и знает" и они точно также могут попросить проголосовать (как это сделал сейчас Моргачев со своим пропозалом). Не надо придумывать за команду и разработчиков проблемы и потом придумывать решения с целью выпендриться и залутать часть комьюнити пула под бесполезный пропозал. "Они не голосуют" - это не проблема! --- ### 💬 Andrey A *2026-07-18 09:59* · 👍 0 · 👎 0 Когда сеть "будет готова" и размеры на инференс в гнк будут существенные (в виду цены в несколько центов они станут существенными даже при низкой стоимости инференса), например, 100-200к gnk в эпоху, то именно вестинг может создать дефицит и начать выводить цену туда, где ее хотят видеть. В противном случае, все расходы на инференс моментально возвращаются на рынок. Отмена вестинга не дает главного — она не увеличивает спрос на бирже на гнк. Поэтому даже при появлении новых майнеров, желающих продать сразу — сделать в плюс они это не смогут. Также нельзя забывать, что отмена вестинга снижает привлекательность майнинга для новых инвесторов. Так как отмена неизбежно сокращает спред между биржей и себестоимостью. Плохо ли это? Не факт. Это не определяющие доводы в пользу вестинга (думаю его пора сократить), но хотелось бы услышать прежде всего мнение от разработчика токеномики. --- ### 💬 Mitch *2026-07-18 14:09* · 👍 0 · 👎 0 Как раз нет, Девид уверен в пользе вестинга. Эта статья, попытка указать команде что у вестинга есть очень существенный минус. В чате было обсуждение, поресерчил идеи с ии, отобрал то что сам считаю важным и оформил чтоб удобно читалось. --- ### 💬 Slava MyGonka *2026-07-18 08:22* · 👍 0 · 👎 1 Сейчас Майнер = Инвестор. Это те люди, которые хотят купить GNK в долгосрок и купить ниже рыночной стоимости. В Майнинге, даже с большими комиссиями 20% майнинг пула, это пока получалось. 2. Ты предлагаешь расширить понятие Майнер-Инвестор до Майнер - Поставщик оборудования. То, что они сразу будут сливать все намайненное в стакан - это понятно. В этом случае мы фактически отдаем маржу Майнера - Инвестора Майнеру- поставщику GPU. Мне это не нравится. Мы убираем вообще стимул долгосрочных инвестиций. 3. Сейчас поставщики GPU могут почти бесплатно хостить модели Gonka. Мы это обсуждали однажды. Т.е. они ставят модель Gonka и на эту же модель запускают инференс своих клиентов (или свой собственный) в обход Gonka. Так они зарабатывают два раза. При такой схеме их себестоимость добычи GNK = 0. Если они сразу получат GNK, то продажа даже по 0,01 USD будет им выгодна. Вестинг пока немного защищает от таких схем. Т.е. чтобы так делать нужно быть немножко Майнером-Инвестором. В общем, у меня нет точного мнения на этот счет, но Майнеры-Инвесторы мне нравятся больше, чем Майнеры-Поставщики, т.к. вторые фактически занимаются "скальпингом", т.е. краткосрочной спекуляцией. Наратив майнинга должен быть таким: Через Майнинг вы получите GNK дешевле, чем на споте. Если убрать Вестинг, то такой наратив будет уже невозможен. А хотя... Bitcoin же как-то майнится... --- ### 💬 Kirill Smerkins *2026-07-18 07:18* · 👍 1 · 👎 3 80% написано с помщью АИ - двойные конструкции, длинные тире и изложение - все это говорит о том, что автор просто забил свой тезис в не самую лучшую ИИ-шку и попросил накидать аргументы в защиту своего мнения. Хватит создавать видимость работы, когда закончились собственные возможности заработка на майнинге и ушел основной источник дохода. Хватит выносить бесполезные пропозалы и абузить комьюнити пул (не в части этого конкретного предложения). Команда и Bitfury сами знают как поступать с токеномикой и разработкой. --- --- [View on gonka.vote](https://gonka.vote/proposal/d23b0edf-57fb-4522-bd79-04ffdcc9d7a5) --- ## 10. Team Alexander Kuprin Grant Request # 10. Team Alexander Kuprin Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal 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: * Detecting and logging inferences that fail, are missed, or are wrongly invalidated. * Tracing requests using the **OTEL** protocol. * Measuring execution context, including API node load, ML node load, and network-layer data for detecting possible attacks. * Authenticating collected data with Gonka key signatures, so data is accepted only from active epoch participants. This should help prevent spam or flooding and make it easier to localize problems. 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. ## What contributions or products has your team already developed for Gonka (with links pls)? 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 ## GNK Wallet Address gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56 ## Your Discord ID for Contact Purposes alexanderkuprin_ ## Email Address [kuprin.alexander@gmail.com](mailto:kuprin.alexander@gmail.com) --- ## Comments (1) ### 💬 Slava MyGonka *2026-06-11 07:52* · 👍 0 · 👎 0 Привет! Это предложение выходит за рамки моего понимания. Но вопросы я все-таки задам )) 1. Какие серверы нужны и сколько они стоят? 2. Кого ты планируешь привлечь в Контрибьюторы? Они об этом знают? 3. Сколько средств нужно на реализацию этого проекта? Т.е. сколько ты запрашиваешь? 4. Будут ли хосты делиться информацией? Как их мотивировать это делать? Здорово, что есть такая инициатива! Чем больше инфы о работе сети, тем лучше! --- --- [View on gonka.vote](https://gonka.vote/proposal/59175b49-b83f-4aa6-98f5-b27fffb23cd8) --- ## Gonka NOP: ретроактивный грант + финансирование поддержки и новых фич. # Gonka NOP: ретроактивный грант + финансирование поддержки и новых фич. 🔴 Expired **Author:** 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: ретроактивно за уже сделанную разработку, за дальнейшую поддержку и за разработку новых функций. --- ## Full Proposal **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, который покрывает: 1. Ретроактивно — за уже выполненную разработку текущей рабочей версии инструмента. 2. Поддержка пользователей — помощь операторам в работе с инструментом: диагностика проблем, ответы на вопросы и сопровождение по мере выхода обновлений Gonka. 3. Новые функции — реализация новых возможностей и расширение круга поддерживаемых сценариев (GUI/TUI для новичков, локальный мониторинг, Ansible-модуль, прочее). **Структура вознаграждения (для обсуждения)** Совокупный размер гранта — порядка 50 000 USDT (или эквивалент в GNK), пакетом за все три направления. **Что это дает сети** Грант приносит пользу не отдельным группам участников, а сети в целом. Прямо сейчас эффект может казаться неочевидным: операторов немного, и большинство справляется собственными силами. Но устойчивый рост сети потребует простого пути подключения для тех, кто только присматривается к Gonka, и поддержки этого пути в актуальном состоянии — иначе рост упрётся в порог входа, который преодолевают далеко не все. NOP — часть этой инфраструктуры, а этот грант - это инвестиция в ее будущий рост. **Вопросы** К обсуждению принимаются любые вопросы. Начать можно с этих: - Какая сумма гранта адекватна? 50 000 USDT — стартовая точка с нашей стороны. - В чём выплачивать? USDT, GNK или комбинация и в каком соотношении? - Единовременно или с вестингом — если выплата в GNK? - Какие новые функции в приоритете? TODO лист открыт для изменений. --- ## Comments (4) ### 💬 O D *2026-05-13 18:38* · 👍 2 · 👎 0 Дополнительные ссылки: https://youtu.be/kQGPSxLaakE?t=829 https://youtu.be/kQGPSxLaakE?t=1988 --- ### 💬 Дмитрий В *2026-05-14 00:24* · 👍 1 · 👎 0 Абсолютно крутой инструмент и нужная работа. Тем более если целиться в рост +100 +1000 партисипонтов ежемесячно. --- ### 💬 Evgenii Maksimenkov *2026-05-14 08:54* · 👍 1 · 👎 0 Вещь важная и нужная. Но $50k многовато имхо. Также возможно быть не своевременно - NOP пригодится при следующей волне новых майнеров. --- ### 💬 Mikhail Chudinov *2026-05-14 16:59* · 👍 1 · 👎 0 Ну так это же классно, что к следующей волне майнеров, такой инструмент уже будет обкатан, а не начнет делаться внезапно. Да, чуть дороговато, но не то чтоб прям супер дорого. Топовые разрабы которые участвовали в многих крипто проектах и привыкли очень хорошо зарабатывать. Мне очень нравится команда которая стоит за nop, и хочется чтобы они остались с гонкой. Они бы дальше и в сам блокчейн могли контрибутить. --- --- [View on gonka.vote](https://gonka.vote/proposal/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde) --- ## External Test Lab & Community DevNet # External Test Lab & Community DevNet 🔴 Expired **Author:** 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. --- ## Full Proposal 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 | # 2. Problem Statement 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. # 3. Roadmap Alignment This proposal directly implements two projects from the [Gonka Network Development Roadmap](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md). **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**.** # 4. What We Are Building 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 | # 5. Community DevNet Infrastructure - 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](https://huggingface.co/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. # 6. Burst GPU Testing Budget - 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. # 7. External Testing Team 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 ## Preferred / Nice-to-Have - 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 # 8. Project Owners and Accountability | Role | Proposed owner | Responsibilities | | --- | --- | --- | | **Project Lead** | [Sergii Paranko](https://www.linkedin.com/in/paranko/) (S∃ga L∈nin) | Overall project accountability, governance coordination, scope and milestone control, QA contractor selection and onboarding, public reporting, and testing laboratory oversight. | | **Infrastructure Lead** | [Mikhail Chudinov](https://www.linkedin.com/in/mikhail-chudinov/) (Mitch) | DevNet provisioning, hardware selection, regional hosting, monitoring, operational stability, and infrastructure cost control. | | **External Testing Team** | 2 hired QA / Infrastructure Testing Engineers | Test execution, reports, defect documentation, regression tracking, and release-readiness recommendations. | # 9. Transparency and Reporting - 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. # 10. Protocol Maintainer Coordination - 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. # 11. Release Validation Handoff Requirements | **Validation type** | **Expected handoff** | |--------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Protocol release / production upgrade** | Protocol Maintainers provide release candidate, upgrade notes, affected components, and expected test focus at least 7 days before the planned governance vote or production rollout, where feasible. | | **DevShard / test environment validation** | DevShards or another testable environment are provided with scope and expected test focus at least 3 days before the expected validation result, where applicable. | 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. # 12. Milestones and Acceptance Criteria ## Workstream A: DevNet Infrastructure | **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. | ## Workstream B: External Testing Lab | **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. | # 13. KPIs | **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 | # 14. Budget Estimate 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](https://nebius.com/prices) 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. # 15. Payment Schedule | **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. | # 16. End-of-pilot GNK recognition 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. | # 17. Open Source, Ownership and Handoff - 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. # Decision Requested 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. --- ## Comments (5) ### 💬 Dem | Démíngān *2026-07-04 12:15* · 👍 5 · 👎 0 АМА: https://youtu.be/tYfeXANyPtM?si=X7g-H1awc1PB1uqI&t=1957 --- ### 💬 Andrey A *2026-07-06 07:42* · 👍 1 · 👎 0 Поделюсь мыслями. Не ставлю под сомнение факт, что core-тим сообщили о необходимости этой структуры именно в таком виде, с этим просто есть 100% доверие. С других же сторон информация менее известна. Меня смущает, что пропосал посвящен QA. Старая, зрелая и специализированная область. При этом в бэкграунде текущей команды не вижу подтвержденного опыта именно в построении QA-процессов, SDET или тестировании blockchain-инфраструктуры. В самом пропосале заявлены высокие требования к QA-инженерам, но непонятно, как команда без явного QA-бэкграунда будет их отбирать, оценивать качество их работы и принимать результаты. Для Сергея руководство проектом с двумя QA-инженерами выглядит одновременно как заметная смена направления (причем в "скучную" тему qa) и как профессиональный дауншифтинг относительно его предыдущего уровня ролей. Для Михаила понятна инфраструктурная часть, но не очень понятно, где его опыт подтверждает способность строить именно QA-лабораторию, а не devops-инфраструктуру. Если что-то из опыта не отражено в линкедин, прошу усилить пропосал этой информацией. Если релевантного опыта нет, то прошу пояснить, почему он считается не обязательными и в чем именно интерес команды заниматься этой темой. Потому что, если интереса нет, то энтузиазм может очень быстро закончиться. В общем, основные вопросы не относительно актуальности пропосала и не о суммах в нем. --- ### 💬 Sergii Paranko *2026-07-07 05:11* · 👍 0 · 👎 0 Андрей, спасибо за содержательный комментарий. Вопрос понятный и справедливый. Важное уточнение: я не планирую лично выполнять роль QA/SDET-инженера или подменять собой профильную экспертизу. Тестированием будут заниматься профильные QA / Infrastructure Testing Engineers. В моих прошлых проектах у меня регулярно были команды тестирования, за которые я как руководитель отвечал организационно: постановка процесса, приоритизация, контроль. В некоторых проектах тестирование было размером с половину команды разработки. Здесь масштаб сильно меньше: небольшая внешняя лаборатория. Кто поможет с технической валидацией специалистов-тестировщиков и их онбордингом я указал в пункте 10 (Protocol Maintainer Coordination). А качество работы лаборатории будем показывать: все артефакты публичные, участники сообщества с экспертизой смогут оценить и подсказать. Митч нужен как раз для devops-инфраструктуры: региональное размещение, мониторинг, стабильность, плюс поиск и организация найма burst GPU-ресурсов для почасовых тестов, когда они нужны. Что касается мотивации: она такая же, как и с роадмапом: не хочу, чтобы мои инвестиции обесценились, а лучше бы они выросли в цене. Вознаграждение за проект тоже станет весомее, когда сеть станет стабильнее и защищеннее от критических багов. --- ### 💬 Sergii Paranko *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 --- ### 💬 Sergii Paranko *2026-07-10 13:24* · 👍 0 · 👎 0 [Предложение №82 — External Test Lab & Community DevNet принято.](https://gonka.vote/governance/82) Спасибо всем, кто изучил предложение и принял участие в голосовании. Начинаем первый месяц работы: поиск и найм специалистов в QA-команду, поиск и аренда оборудования, запуск первых нод. Первый отчёт будет опубликован примерно 9 августа — за четыре дня до разблокировки второго транша. --- --- [View on gonka.vote](https://gonka.vote/proposal/205219a5-6ed2-4f25-8d22-fa7c65a45ba6) --- ## Bring Gonka to EBC12 as a Gold Sponsor # Bring Gonka to EBC12 as a Gold Sponsor 🔴 Expired **Author:** 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 --- ## Full Proposal 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. ## Proposal 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: - Gold Sponsor online and on-site visibility - 18sqm branded booth with tables for meetings and deal-flow - 1 panel speaking slot - 1 complimentary speaking slot - Recommended panel topic: AI & Compute Infrastructure in Financial Markets - 7 curated 1-to-1 Executive Meetings with selected attendees - 6 General tickets - 1 VIP ticket - 2 Speaker VIP tickets - Media exposure through EBC’s press network - Newsletter mention to EBC’s 65,000+ subscriber audience - Social media promotion on LinkedIn and X - Professional event photography - Recording of Gonka’s speaking participation - YouTube upload and post-event content assets Total requested budget: 62,000 USDT. ## Why now 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: - Build awareness in the European market - Open conversations with exchanges and infrastructure partners - Reach institutional and enterprise audiences - Generate qualified partnership and business development opportunities - Create reusable content for future marketing and community growth - Position Gonka as part of the European digital asset and AI infrastructure conversation If approved, this tender would allow Gonka to participate in EBC12 with a serious presence instead of attending passively or missing the opportunity entirely. ## Requested funding 62,000 USDT ## Success metrics After the event, the community should receive a short report covering: - Number of meetings completed - Type of companies met - Partnership or exchange conversations opened - Speaking session delivered - Content assets received - Photos, videos and recordings published - Key follow-up opportunities created for Gonka --- ## Comments (2) ### 💬 Dem | Démíngān *2026-05-22 08:43* · 👍 2 · 👎 0 Добрый день, ничего не вижу про автора пропозала, а точнее о тех, кто именно будет представлять gonka. --- ### 💬 Heydar Naghiyev *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](https://gonka.vote/proposal/29baf37b-811f-4c36-b517-66a578383f1c) --- ## Team Gonka.AI \| Inside Grant Request # Team Gonka.AI \| Inside Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal 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: * Grow the channel to **1,000 subscribers**. * Attract at least **56 new miners**, bringing the total number of personally invited miners to **100+**. * Introduce the audience to the new **Omniverse** mining pool after testing it personally and preparing an honest review. * Work together with the author of a Medium blog to collect and publish real Gonka use cases, guides, breakdowns, and practical examples. * Continue supporting small startups and initiatives within the Gonka ecosystem by giving them exposure through the channel. * Start working with the **NOVA** exchange and direct the audience there to help bring liquidity and active users. * Run a summer giveaway to attract new users and give them a chance to try GNK. * Implement SEO optimization for the channel and get it indexed in Yandex search results, so new users can find Gonka-related information more easily. All of this will be done by one person — a student who believes in Gonka and is building a community around it. ## What contributions or products has your team already developed for Gonka (with links pls)? 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%**. ## GNK Wallet Address gonka1c3lrggulyl9xpsvnnjpykhyzvk7l5fcd92w63n ## Your Discord ID for Contact Purposes 960564245471301683 ## Email Address [andres88005553535@gmail.com](mailto:andres88005553535@gmail.com) --- ## Comments (1) ### 💬 Slava MyGonka *2026-06-11 06:38* · 👍 0 · 👎 0 Привет! Речь идет про этот канал: https://t.me/newsgonkaai Забыл добавить ссылку ) А это - рекламный канал, верно? Суть канала - приглашение людей в Майнинг пул Анкапекс. Приглашение по реферальной программе. Omniverse, NOVA - молодые проекты. Нужно с ними повнимательнее. Хорошо бы, чтобы они сами о своих продуктах рассказали в Комьюнити, а то что-то не слышно новостей ) **Вопросы:** 1. Сколько GNK тебе нужно на три месяца? 2. Какие обязательства ты готов дать? Желательно в цифрах 3. Я вижу, что очень много постов в канале - это просто Репосты из других каналов. Чем твой канал лучше других? Спасибо за инициативу! Я подписан )) --- --- [View on gonka.vote](https://gonka.vote/proposal/4792a93f-127a-4a0e-9a12-acd229c1e865) --- ## 3. Team Gonka Wallet Grant Request # 3. Team Gonka Wallet Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal 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. ## What contributions or products has your team already developed for Gonka (with links pls)? The team has developed **Gonka Wallet**, described as the first wallet specifically created for the **Gonka.ai** ecosystem. Telegram channel: https://t.me/GonkaWallet ## GNK Wallet Address gonka15vunu0new53m83ccvfcmkf84v7q4s8ldsjfu4y ## Your Discord ID for Contact Purposes shtirbetsai ## Email Address [vr.atom.com@gmail.com](mailto:vr.atom.com@gmail.com) --- ## Comments (1) ### 💬 Slava MyGonka *2026-06-11 07:08* · 👍 0 · 👎 0 Привет! Вы куда-то пропали на несколько месяцев. При этом у вас были очень крутые идеи. Как дела? Сервисом по кабинету для майнеров (классная идея) кто-то пользуется? Вход в экосистему Gonka через кошелек Telegram - прикольно. О предложении: 1. Это предложение, как я вижу, ничего не имеет общего с вашим предыдущим проектом, верно? Т.е. это - отдельная идея. 2. Сколько средств вам нужно? 3. Какого результата вы ожидаете? Желательно в цифрах. 4. Я несколько раз прочитал, и не смог понять, что должно получиться по итогу. Типа фриланс биржа по разработке ботов на базе Gonka? Есть ли аналоги? --- --- [View on gonka.vote](https://gonka.vote/proposal/2b6b2142-685a-4eda-b2a1-f8853228f3e6) --- ## Gonka Integration Grant for AI Startups and Products (GNK Rewards) # Gonka Integration Grant for AI Startups and Products (GNK Rewards) 🟢 Active **Author:** 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. --- ## Full Proposal 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. ## 2. Who Can Apply Eligible applicants are companies or teams that: 1. Operate an AI-powered product (live or in active development) that uses LLM inference as a core component. 2. Have a **working product or functional MVP** at time of application — concept-only pitches are NOT eligible. 3. Have a registered legal entity (any jurisdiction permitted by Gonka compliance). 4. Pass basic KYB (Know-Your-Business) checks. **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). ## 3. Grant Tiers | Tier | Grant Amount (GNK equivalent in USD) | For | |---|---|---| | **Starter** | $5,000 | Pre-revenue products, 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-case | GNK is paid at the 7-day TWAP at the date of each milestone payout. Recipients are responsible for their own tax treatment. ## 4. Team Requirements Applicants MUST demonstrate: 1. **Technical capability**: at least 1 founder or core team member with verifiable engineering background (GitHub profile, prior shipped product, or equivalent). LinkedIn alone is not sufficient. 2. **Working product**: live URL, app store listing, or demo video showing the product in actual use. Mockups and Figma files are not accepted. 3. **Real users or pilot customers**: minimum 50 active users OR 1 paying customer OR 3 signed LOIs at time of application. 4. **No anonymous teams** for Growth tier and above. Starter tier permits pseudonymous teams with established crypto reputation. 5. **Clean track record**: no prior fraud, rug pulls, or unresolved legal issues against the team or company. 6. **English communication**: at least one team member able to communicate fluently in English for technical and reporting purposes. ## 5. Technical Integration Requirements To qualify for grant payout, the integration MUST meet ALL of the following: ### 5.1. Production Integration - Gonka MUST be wired into the **production codepath** of the product, not a sandbox or feature-flagged demo. - Integration MUST use the OpenAI-compatible `/v1/chat/completions` endpoint (or other supported Gonka APIs) with proper ECDSA request signing as specified in the Gonka Developer Docs. - Production traffic share served by Gonka MUST meet the tier minimum (see §3) and be verifiable via on-chain inference records. ### 5.2. Reliability and Fallback - Implementation MUST handle Gonka network errors gracefully (retries with exponential backoff, optional fallback to a secondary provider). - Implementation MUST NOT route only failed/degraded requests to Gonka. Routing logic MUST be either deterministic (e.g., percentage split) or unbiased. ### 5.3. Code Quality - Integration code MUST be reviewable. For closed-source products, the relevant integration module MUST be shared privately with the Gonka grants team for verification. - Open-source integrations are encouraged and MAY receive a 10% bonus on the grant amount. ### 5.4. Telemetry - Recipient MUST share basic usage telemetry with Gonka monthly: total inference calls routed to Gonka, total tokens, error rate, p95 latency observed. Aggregate numbers only — no end-user data required. ## 6. Visibility Requirements To qualify for grant payout, the recipient MUST complete ALL of the following: ### 6.1. Website - "Powered by Gonka" badge displayed on the product website (footer or about/tech page acceptable). Badge assets provided by Gonka. - One sentence in the product's stack/technology section naming Gonka as the inference provider, linked to gonka.ai. ### 6.2. Public Announcement - One public announcement post on the recipient's primary channel (X, blog, or LinkedIn) announcing the integration. Minimum reach: the recipient's actual organic following — no requirement to buy reach. - Post MUST tag @gonka_ai (or current official handle) and MUST be coordinated with the Gonka marketing team for timing (not content approval — recipient retains editorial control). ### 6.3. Case Study Cooperation - Recipient agrees to participate in **one** case study (written interview, 60–90 min total time commitment) within 6 months of grant completion. Gonka produces and publishes the case study; recipient reviews for accuracy before publication. ### 6.4. Logo Use - Recipient grants Gonka the right to use the recipient's name and logo in: - Gonka's website (Developers / Customers section) - Gonka's pitch decks and marketing materials - Gonka's social channels in the context of this integration - This right is non-exclusive, royalty-free, and revocable on 30 days' notice if the integration is discontinued. ### 6.5. Optional (Bonus) - Conference talk, podcast appearance, or YouTube video featuring the integration: **+5% grant bonus**. - Open-source release of the integration (with permissive license): **+10% grant bonus** (already mentioned in §5.3). - Maximum cumulative bonus: 20%. ## 7. Milestone-Based Payout Structure 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 completed | If 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). ## 8. Fraud Prevention - Synthetic traffic, bot-generated inference calls, or any artificial inflation of usage metrics triggers immediate forfeiture and clawback of all paid milestones. - Gonka reserves the right to audit on-chain inference patterns and request reasonable verification (e.g., correlation with public product usage metrics). - Multiple grant applications from related entities (same team, same product under different names) are not permitted. ## 9. Application Requirements Applicants MUST submit: 1. **Company info**: legal entity, jurisdiction, founding date, team size. 2. **Product info**: live URL, current MAU/ARR (if applicable), inference volume estimate (calls/month, tokens/month). 3. **Team info**: founders' names, GitHub/LinkedIn, prior products shipped. 4. **Integration plan**: which Gonka model(s) will be used, expected traffic share, integration timeline, fallback strategy. 5. **Tier requested** with justification. 6. **Visibility commitment**: confirmation of §6 obligations. 7. **Wallet address** (Gonka-compatible bech32) for grant payout. ## 10. Out of Scope - Equity investment, SAFE, token warrants — this is a non-dilutive grant only. - Co-marketing budget beyond the case study and announcement (separate marketing partnerships handled outside this program). - Custom model deployment on Gonka network (separate process). - Free inference credits beyond what the grant amount can purchase at standard rates. --- ## Votes (3) | Voter | Amount | Date | | :----- | :----- | :--- | | `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 | --- ## Comments (1) ### 💬 Alex Sharoiko Александр Шаройко *2026-04-26 20:48* · 👍 1 · 👎 0 Нужно установить требования еще по количеству инференса, который они будут использовать. А то я уже использую инференс Гонка для своих проектов. Но при этом я не думаю, что мне за это нужно платить )) --- --- [View on gonka.vote](https://gonka.vote/proposal/ed7bd700-bb5a-4c99-9dae-bdcba6641015) --- ## Return Withheld Miner Rewards: Redistribute Gov-Wallet Balance for Ep 132–247 # Return Withheld Miner Rewards: Redistribute Gov-Wallet Balance for Ep 132–247 🔴 Expired **Author:** 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. --- ## Full Proposal 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 ## The situation Two governance upgrades quietly changed where unpaid miner rewards go: - **v0.2.9** (proposal #26, executed 2026-02-01) — when a participant is penalized during cPoC validation, the unpaid 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, executed 2026-03-20) — slashed collateral was changed from `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). ## Why this is miner money, not community money 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. ## What I'm proposing 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: - **Range**: epochs `132..247` (132 is the first epoch with observable inflow; 247 is the last epoch whose payouts were fully settled at computation time). - **Source data**: 100% on-chain, fetched from a standard gonka full node via `block_search`, `block_results`, `epoch_group_data`, and `epoch_performance_summary`. No off-chain inputs. - **Math**: Hamilton (largest-remainder) integer apportionment in pure ngonka. The CSV total equals the in-range inflow exactly — every ngonka accounted for. - **#32 and #33**: not subtracted. The double-payment for the addresses involved in those two proposals works out to ~1.7% of the wallet balance — well below the typical per-epoch noise, and not worth the extra complexity in the algorithm. 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. ## Questions for the community 1. Do you think the gov-wallet balance should be returned to the miners who would have received it under the pre-v0.2.9 rules? 2. Is the proportional-by-rewarded-coins approach fair, or do you prefer a different methodology (e.g. by raw weight, by number of validated inferences, etc)? 3. Would you vote **yes** on an on-chain proposal that uses `MsgBatchTransferWithVesting` (mirroring #32 and #33) to execute this exact distribution? 4. Anything missing — edge cases, addresses I've miscategorized, an epoch boundary I've drawn wrong? 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. --- ## Comments (15) ### 💬 Evgenii Maksimenkov *2026-05-01 14:49* · 👍 2 · 👎 0 В предложении я специально подчеркнул, что у комьюнити уже есть свой пул который уже пополняется на 2% и там уже скопилось 102 972 832 GNK этого хватит на более чем 10 лет, если тратить по миллиону. А ранние майнеры помимо этого уже были “наказаны” дополнительным 10-30% налогом каждую эпоху, из-за того что сеть не могла эффективно бороться с ддос атаками. (Сейчас это уже изменилось, я описал ниже) Оригинальное предложение было составлено на английском языке и слово “legitimate source” там имело другую окраску. Имелось ввиду, что это правильный источник, который для этого и предназначается. Если будут какие-то конкретные идеи по алгоритму распределения (и чем они лучше предложенного), я буду рад обсудить. --- ### 💬 Evgenii Maksimenkov *2026-05-01 06:02* · 👍 1 · 👎 0 Просто вернуть. Отключение может возобновить ддос. --- ### 💬 Evgenii Maksimenkov *2026-05-01 06:03* · 👍 1 · 👎 0 Нужно различать govrnance и комьюнити кошелек. то разные вещи и для разных целей. Я написал об этом в самом предложении. --- ### 💬 Nik *2026-05-01 07:54* · 👍 1 · 👎 0 Отличная идея, распределить пропорционально выполненной работе - то есть обработанным инференсам! --- ### 💬 Alex Sharoiko Александр Шаройко *2026-05-01 10:29* · 👍 1 · 👎 0 Ты предлагаешь вернуть награды всем майнерам? И читерам тоже? Там чел в течение 35 дней обманывал сеть. https://prnt.sc/x0M-Pq9kv4gG А теперь мы ему выплатим раз в 5 больше того, что он наобманывал ) Уж лучше пусть средства будут в Комьюнити Пуле. --- ### 💬 Evgenii Maksimenkov *2026-05-01 14:34* · 👍 1 · 👎 0 С момента 130 эпохи было многое реализовано для предотвращения ддоса: Закрыты порты 26657 - теперь все запросы идут через прокси Инфиренс запросы распределяют TA. И это правильно - нужно бороться в целом с возможностью ддоса, т.к. мотивация может быть и не GNK-материальная (например, участники другой сети решат положить конкурента). Не факт, что комьюнити снова договориться о выплате. И мало кто будет тратить свои ресурсы, ради призрачной надежды получить дополнительно 10% через 3 месяца. К тому же выплата происходит постфактум и рычаг всегда остаётся у комьюнити - если видим что попытки ддоса возобновились, голосуем против очередного распределения. --- ### 💬 Evgenii Maksimenkov *2026-05-01 14:38* · 👍 1 · 👎 0 Если мы вступаем на путь чери пикинга, то нужно четко оглашать правила кто достоин, а кто нет. И если уже есть такие критерии, то они априори уже должны быть внедрены в саму сеть. Любой участник получит не в 5 раз больше, а примерно +10% от того что он недополучил. P.S. Конкретно у твоего примера - там больше половина нод отключалась и по итогу они и так не получат награду. --- ### 💬 Дмитрий В *2026-05-01 18:46* · 👍 1 · 👎 0 Это точно хороший алгоритм и хорошо продуман. Как разовая акция тут все прекрасно и поделана хорошая работа. Вижу, что не я один подсветил, что тут риск ненужного прецедента может быть. Но если попробовать изначально сразу позиционировать идею как разовую, типа закрыть прошлые «косяки», тогда риск минимизируется. Источники копилки думаю могут быть разные, это везде так, я бы лично не создавал ощущения, что штрафы могут быть амнистированы в будущем, но это мой подход, я не налоговик.) просто мнение.) --- ### 💬 Mikhail Chudinov *2026-05-02 04:07* · 👍 1 · 👎 0 Ок, убедил. Я проголосовал YES --- ### 💬 Alex Sharoiko Александр Шаройко *2026-05-01 05:51* · 👍 0 · 👎 0 А ты хочешь вернуть, или вообще отключить эту фичу? --- ### 💬 Alex Sharoiko Александр Шаройко *2026-05-01 05:57* · 👍 0 · 👎 0 Сейчас это получается около 10%. Но, я думаю, после обновления % будет ниже. Токеномика Gonka предполагает налог 2%. А тут получилось чуть больше) Интересно, какой % будет дальше тратиться? С одной стороны, хорошо, когда в Комьюнити пул есть средства, а с другой, хорошо бы, чтобы майнеры были довольны. Не знаю. У меня нет чёткого мнения. Но то, что налог должен быть, я считаю правильным. Но его пока нет. Зато есть эта фича) --- ### 💬 Дмитрий В *2026-05-01 07:30* · 👍 0 · 👎 0 - Считаю нужно тратить деньги из пула, а не смотреть на них.) - Думаю этот кошель ровно такой же пул, хорошо что есть механизм возобновления баланса пула. - Большой остаток в пуле говорит о том, что деньги срочно нужно тратить, но не о том, что откуда пришли, то туда же и отправить. Странный механизм сбора штрафов и налогов.) - Нужно тем не менее как-то вознаградить ранних майневро. - Хотя участие сейчас в сети отчасти и есть вознаграждение, хоть есть и риск, что проект не стрельнет. Мы сами на это идем. - Логическая ошибка на мой взгляд в предложении и небольшая манипуляция): названы «законными» возвраты майнерам лишь по тому что прошло голосование. Звучит как отсылка к прецеденту. По такой логике текущий возврат можно тоже будет назвать законным. Тогда следующий возврат тоже можно назвать законным. Что на дистанции опосредованно узаконит ошибки и нарушения за которые берется штраф, ибо регулярная амнистия это поощрение нарушений. - Если как-то возможно сделать отсев и вознаградить ранних майнеров по другой математике или за другие заслуги, то было бы хорошо. На мой взгляд это не обязательно должно быть справедливо распределено, можно вознаградить кого-то за самое долгое участие в сети или тех у кого самые оптимизированные мощности. Как сказал Павел Дуров, конкуренцию нужно вознаграждать, а если ставить всем пятерки только за то, что они пришли на урок, убивает результат. - Считаю искать правду в том как поступить с монетами, в зависимости от туда откуда они пришли, чуть противоречит мировой налоговой практике. Пользовался бы принципом в том числе «От каждого по возможности, каждому по потребности», можно выдать наоборот тем, у кого самые не оптимизированные мощности, за участие в сети и поддержку даже в сложных для самого себя условиях. - Но фонды это нужная идея, считать откуда пришло, чтобы поддерживать конкретный сектор всей экономики. Но тут получается это единственный источник, фонды должны быть значительно меньше тогда. Обычно каждый 5-10-20%, не больше. - Можно исходить из этого и вернуть по 20% например, получится налоговый вычет, такой механизм есть в мировой практике. Но на сколько это будет опять же поощрять ошибки или ДДОС или другие действия, надо считать. --- ### 💬 Nik *2026-05-01 07:52* · 👍 0 · 👎 0 "можно выдать наоборот тем, у кого самые не оптимизированные мощности" - это же полностью противоречит принципу Дурова вознаграждать конкуренцию. --- ### 💬 Дмитрий В *2026-05-01 08:11* · 👍 0 · 👎 0 Да, верно подмечено. Просто накидываю идеи, эта не удачная, я бы ее не брал.) --- ### 💬 Mikhail Chudinov *2026-05-01 12:33* · 👍 0 · 👎 0 Если сейчас вернуть - то логично, что и через месяц когда будет выдвинуто аналогичное предложение, давайте опять поделим, то так же поделим. Мотивация ддосить, чтоб другие майнеры остались без выплат, чтобы получить самому повышенную выплату - появится. Пусть выплата не гарантирована, и через время.. Но мотивация ддосить появляется, это плохо. --- --- [View on gonka.vote](https://gonka.vote/proposal/012f8a32-45ab-4ba8-b6f3-39631d19eb84) --- ## 9. Team Gonka-API.org Grant Request # 9. Team Gonka-API.org Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal 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: * Launch targeted marketing campaigns to accelerate user acquisition for Gonka API. * Test marketing channels and go-to-market strategies to increase usage and network adoption. * Continue positioning Gonka API as a simple and convenient entry point for developers, AI agents, and inference users. * Potentially resume the UGC content project and publish additional videos about Gonka on the author’s YouTube channel. * If Gonka opens inference access to everyone and removes broker whitelists, evolve Gonka API into a broader infrastructure tool for advanced inference consumers. * Keep the current provider model for users who prefer a simple gateway. * Add direct-access tools for advanced users. * Develop functionality for fiat-to-GNK access, API key management, and network address management. * Prepare the platform for future network needs, including direct and secure workload control when TEE support becomes available. The long-term goal is to make Gonka API a versatile administrative and infrastructure tool for the Gonka network. ## What contributions or products has your team already developed for Gonka (with links pls)? 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: * **214 total users** * **90 active users** * **15 paid users** * **$260 in revenue** 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: * Creating a marketing chat dedicated to onboarding new builder and execution teams. * Personally inviting several high-level execution teams that could support Gonka’s growth, including professionals who previously worked with Bitfury. * Making voluntary PR contributions to improve the documentation on gonka.ai, especially to help new consumers connect to the network more easily. ## GNK Wallet Address gonka1ue9uvex7cxea5y4xvhka240l0k457nhdt2qd7h ## Your Discord ID for Contact Purposes dmitriiv4054 ## Email Address [voronovda00@gmail.com](mailto:voronovda00@gmail.com) --- ## Comments (1) ### 💬 Slava MyGonka *2026-06-11 07:39* · 👍 0 · 👎 0 Привет! Классное видео! https://youtu.be/hwX_4_v6xxI Одно из лучших про Gonka Пришлось гуглить, что такое UGC-контент. это User Generated Content, то есть контент, созданный пользователями, а не самой компанией или официальной командой проекта. Ваш проект: Gonka-API.org - коммерческий Брокер. Таких уже в сети, кажется, 9. Выделив финансирование вам, мы поставим в невыгодное положение другие Гейты (брокеры). Я бы хотел, чтобы каждый гейт предоставил токены для бесплатных АПИ. Вот эти токены можно оплатить из средств Комьюнити Пула. Давайте подумаем в эту сторону, т.е. чтобы Гонка компенсировала все затраты Брокеров на Инференс. 2. А вот про видео - давайте поподробнее ) Это прям очень крутое видео. Вопросы: 1. Сколько денег вам нужно (в GNK с вестингом) на то, чтобы продолжить создавать видео контент такого уровня? Можно короче. 2. Можно планы в цифрах? Крутой контент. Молодцы! Видно, что профессионалы, а не я на коленке ))) --- --- [View on gonka.vote](https://gonka.vote/proposal/f021bdb3-59f4-4906-bfaa-7b90b72019b1) --- ## 12+1. Team EntroPi Grant Request # 12+1. Team EntroPi Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal 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: * Local AI infrastructure. * Cloud AI infrastructure. * Sovereign AI infrastructure. * Decentralized AI infrastructure. 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. ## What contributions or products has your team already developed for Gonka (with links pls)? 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. ## GNK Wallet Address gonka16vkaxtvglq7kghtf846eg0d92j7amdgx7f95ud ## Your Discord ID for Contact Purposes ihortanyenkoff ## Email Address [it@entropi.ai](mailto:it@entropi.ai) --- ## Comments (1) ### 💬 Slava MyGonka *2026-06-11 08:07* · 👍 0 · 👎 0 Привет! 1. Вы из Германии? 2. У вас уже есть рабочий продукт, верно? https://entropi.ai/ 3. Как он связан с Gonka? 4. Какое количество GNK вы бы хотели получить? 5. Какой измеримый результат планируете предоставить? Я не до конца понял суть проекта, но, может, кто-то из комьюнити разберется в деталях. Спасибо за инициативу! --- --- [View on gonka.vote](https://gonka.vote/proposal/f6b4e378-8950-4bcf-ac7f-d70d9d246630) --- ## Стресс тест инфиренса # Стресс тест инфиренса 🔴 Expired **Author:** 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 — первый пилот выплат от фаундейшена через майлстоуны. Обсудим ТЗ, цену и сроки. --- ## Full Proposal Для того чтобы понять выполнен ли первейший пункт роадмапа в краткострочных задачах “Обеспечить стабильно работающий инфиренс” нам нужен понятный тест. # Тех Задание v 0.1 Сделать скрипт стресс теста, который бы многопоточно загружал инфиренс. Тк прямого доступа к инфиренсу теперь нет, то через брокеров * Скрипт опенсорс, чтоб можно было клонировать и запустить локально * Веб версия, чтоб поставить себе на сервер, и разрешить пользователям вписывать свои ключи api и запускать тест онлайн * Все запросы должны быть уникальные, чтобы не получать ответы из кеша * Отображение балансов брокеров * Настройки * ключи по всем [брокерам](https://gonka.ai/docs/developer/quickstart/#1-use-a-community-broker-recommended) перечисленным на офф сайте * трешхолд значения “нормальной работы” по всем моделям (одинаковые для всех брокеров) * Максимальное время до первого токена * Максимальное время ответа (для каждой модели и сложности). Если время превышено то в результате такой ответ считается медленным * Допустимый % ошибок * Параметры теста * Выбор брокеров для теста, можно параллельно все сразу * Выбор моделей для теста, можно параллельно все сразу * Сложность запроса простой\\средний\\максимум для модели * Количество запросов * Количество параллельных запросов * Результаты с разбивкой по брокерам и моделям (таблички и реалтайм графики) * Количество успешных\\ с ошибками * Средняя скорость * Среднее время до первого токена * Количество медленных первых токенов * Количество медленных ответов * Удобное сохранение результата, чтоб можно было их сравнивать потом между собой визуально и автоматически # Вопросы к сообществу Перед реализацией этого проекта давайте обсудим: * действително ли он нужен * максимальная сумма в USDT которую мы готовы заплатить исполнителю * готовы ли мы оплатить в USDT или только Gonka с вестингом на 180 дней * срок реализации * срок поддержки софта которая должна входить в оплату * есть ли смысл разбить на майлстоуны и какие они могут тут быть * что еще стоит включить в ТЗ ? # План по реализации Я, Mitch из Gonka.Top, [https://t.me/akamitch](https://t.me/akamitch) берусь быть координатором этого проекта в нашем зарождающемся фаундейшене. После того как мы определись с требованиями, ценой, майлстоунами, провести пропозал по выплате всей суммы на специально созданный для этого кошелек. Я найду\\согласую исполнителя, буду принимать у него работу по майлстоунам, отписывать сообществую новости по продвижению, выплачивать исполнителю. В идеале конечно использовать не кошелек, а смарт контракт с мультипомписью совета фаундейшн, для обкатки процесса и кошелек считаю подойдет. Проект выглядит простым, недорогим, быстрым и подходит для обкатки подхода, альтернативного ретро выплатам. --- ## Comments (8) ### 💬 Mitch *2026-05-30 14:08* · 👍 2 · 👎 0 На одном из блокеров уже есть тест, похожий на описанный https://gonka-api.org/test --- ### 💬 Mitch *2026-05-30 20:04* · 👍 2 · 👎 0 Команда gonka.gg сегодня сделала публичный сервис с результатами тестирования 6ти брокеров! https://meter.gonka.gg/ Класс! Хотелось бы не только сервис, а еше в опенсорс, чтоб все могли запускать сами и менять параметры тестов. --- ### 💬 Evgenii Maksimenkov *2026-05-29 23:44* · 👍 1 · 👎 0 Хорошая идея, однако если эта тулза будет в открытом доступе (а только так её возможно принять сообществу), то возможны злоупотребления и ddos атаки. Плюс в будущем софт каждого брокера будет отличаться и то, как они балансят запросы тоже. --- ### 💬 Mikhail N *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. --- ### 💬 Mitch *2026-05-30 13:30* · 👍 0 · 👎 0 Сейчас доступ к инфренсе - только через брокеров. Напрямую то не работает больше вообще. Мож кстати для теста стоит и еще одного брокера отдельного зарегать. Тест получается сквозной, и тестит весь пайплайн включая брокеров. Результат теста также может показать что какие то брокеры лучше чем другие. DDOS тут рубится на брокере лимитом очч просто, скрипт же у нас работает с одного IP, без и с одного акка брокера. Так что для атаки он не годится на самом деле. --- ### 💬 Alex A.A. *2026-06-01 10:33* · 👍 0 · 👎 0 Круто! спасибо! Из минусов, не показывается номер ошибки... ( или я не увидел) --- ### 💬 Alex A.A. *2026-06-02 12:05* · 👍 0 · 👎 0 Тулза не работает к сожалению для костомных. Ошибку шлет: Failed to load models: Provider fallback2 is not Gonka — public test disabled. --- ### 💬 Alex A.A. *2026-06-03 11:29* · 👍 0 · 👎 0 Тестирую фитчу, дай знать как увидишь --- --- [View on gonka.vote](https://gonka.vote/proposal/efc0edeb-bc49-4c6b-a6e7-5b20ccfbe571) --- ## 1. Team Veylox Grant Request # 1. Team Veylox Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal **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 --- ## Comments (8) ### 💬 Slava MyGonka *2026-06-11 06:29* · 👍 1 · 👎 0 Привет! Глянул ваш сайт с Мерчем. Прикольно. Молодцы ) Вот вам лого для вашего сайта )) https://drive.google.com/file/d/15DSQha49eM82qClEJCorUP1uF5NN94LC/view?usp=sharing Вы знаете, что есть База Знаний уже как минимум одна: https://www.gonkadb.com/bin/view/Main/ Писали ли вы когда-нибудь Статьи информационные? Давайте вы одну какую-то напишете, чтобы понимать, чего ожидать. И видео есть какое-нибудь уже? Хорошо бы тоже снять. Т.е. покажите, что будет по итогу. 2. Сколько вам денег на это нужно? 3. Можно ли в цифрах ваше предложение? Сколько видео, сколько статей, план публикаций... Т.е. чтобы результат был измеряемым. Спасибо! --- ### 💬 Leo 111 *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. --- ### 💬 Slava MyGonka *2026-06-16 21:18* · 👍 1 · 👎 0 Я посмотрел сайт. Мне нравится ваша идея. Хорошо, что мы думаем в одном направлении. Знаешь, о чем я думал? Я считаю, что мы можем писать инструкции не только для людей, но скорее для Агентов. Я бы хотел, чтобы у нас была инструкция (правильнее будет сказать "документация"), которую можно было передать агенту (Cursor, Cloude, Codex) и чтобы он все установил, согласно инструкции. А эта инструкция бы обновлялась постоянно. Т.е. кто-то бы ее поддерживал в актуальном состоянии. Скажите, пожалуйста, а на каком языке вы говорите? Английский? Нужно продумать как сделать так, чтобы Статьями могли пользоваться люди на разных языках. 2. Знакомы ли вы с инициативой NOPE? https://github.com/inc4/gonka-nop 3. Какой у вас опыт в Майнинге? Вы сейчас майните? 4. Сейчас создается Комитет, который будет рассматривать такие предложения и помогать делать Пропоузелы. Пока он только создается. Вот здесь чат: https://t.me/Gonka_Marketing Там по русски пишут, но можно и по английски. Спасибо! --- ### 💬 Leo 111 *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. 1. 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. 2. I have indeed heard of the NOPE initiative and planned to have it as one of the options for registering a node. 3. 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. 4. Great, I speak Russian and English, so no problem at all )) --- ### 💬 Slava MyGonka *2026-06-17 18:47* · 👍 1 · 👎 0 Ребята из NOPE больше, кажется, не поддерживают свой проект. Но это не мешает зайти и посмотреть их код. Он есть на ГитХаб. Давай я все-таки уточню: ты планируешь сделать детальную документацию для людей. Эта документация позволит быстрее разобраться с разворачиванем ноды. Т.е. упростит процесс входа. 2. еще ты опишешь, как арендовать на разных площадках. Это интересно ) А на каких ты арендовал, если не секрет? Брал ли ты на spot? Это выгодно? --- ### 💬 Leo 111 *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. --- ### 💬 Slava MyGonka *2026-06-21 10:10* · 👍 1 · 👎 0 А сейчас майните? Тут же постоянно что-то меняется. Разбираетесь в коэффициентах? Как подключались, сами или через AI Агента типа Gursor? Оптимизация нод. Есть ли идеи и опыт? А ты есть в этом чате? https://t.me/gonka_hosts --- ### 💬 Leo 111 *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](https://gonka.vote/proposal/66e6583a-27b4-4bae-91fb-8f0489736b0d) --- ## Private Inc × Gonka — Network Growth Initiative # Private Inc × Gonka — Network Growth Initiative 🔴 Expired **Author:** 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. --- ## Full Proposal 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. ⸻ 2. 🏢 Who We Are 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. ⸻ 3. 🎯 Why Gonka 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. ⸻ 4. 🌎 Target Markets 🇺🇸 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. ⸻ 5. 👥 Target Audience 🖥 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 ⸻ 6. ⚙️ How It Works 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. ⸻ 7. 🏗 Project Infrastructure 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. ⸻ 8. 💰 Program Structure 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. ⸻ 9. 📊 Phase One Budget 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. ⸻ 10. ⏳ Phase One Implementation Plan (45 Days) 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 ————— 11. 📈 Program KPIs 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%+ ⸻ 12. 📊 Transparency & Reporting 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. ⸻ 13. 📋 Deliverables • 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 ⸻ 14. 🤝 Conclusion 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. --- ## Comments (2) ### 💬 Dem | Démíngān *2026-07-04 12:36* · 👍 1 · 👎 0 Scam --- ### 💬 Slava MyGonka *2026-06-14 09:57* · 👍 0 · 👎 0 Скамеры вышли на новый уровень. Благодаря AI можно делать не только хорошие вещи, но, как мы видим, и плохие тоже. Будьте внимательны. Этот пропоузел - это пример возможностей скамеров, вооруженных AI. Никому нельзя верить ) --- --- [View on gonka.vote](https://gonka.vote/proposal/ed8148eb-535e-4677-9a6b-5316c81c996a) --- ## Большое видео на канале Falcon Finance (Александр Соколовский) # Большое видео на канале Falcon Finance (Александр Соколовский) 🔴 Expired **Author:** Дмитрий В **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 — как главный пример децентрализации. Бессрочная публикация. --- ## Full Proposal Большое видео на канале Falcon Finance (Александр Соколовский) **Привет всем!** Выношу на предварительное обсуждение сильную маркетинговую возможность. ### 📌 О канале - **Канал:** [Falcon Finance](https://www.youtube.com/@FalconFinanceX) — авторский канал Александра Соколовского. - **Подписчики:** более 145 000 - **Просмотры:** видео регулярно набирают от 100–200 тыс. до 600+ тыс. просмотров - **Аудитория:** думающие люди, интересующиеся экономикой, технологиями, кризисами и будущим. > Именно Александр Соколовский в октябре 2025 года выпустил одно из самых популярных и глубоких интервью с братьями Либерманы («Open AI — это пузырь»). Многие участники нашего сообщества впервые узнали о Gonka AI именно из этого видео. ### 🔥 Почему это предложение особенно ценно Видео на канале собирают тысячи комментариев — люди активно обсуждают, спорят и делятся мнениями. Это говорит о высоком вовлечении и доверии аудитории. Контент здесь не пролетает мимо, а вызывает серьёзную рефлексию. --- ## 💡 Идея видео **Формат:** большое авторское видео (25–35 минут) в уже привычном для канала формате. **Основная тема:** *«Два сценария будущего»* — два пути развития мира в эпоху искусственного интеллекта: 1. **Первый путь** — корпоративная монополия, массовая экономическая невостребованность людей, концентрация власти и прибыли у нескольких гигантов. 2. **Второй путь** — децентрализованный, открытый и доступный ИИ, где обычные люди и инженеры тоже могут владеть мощностями и получать выгоду. **Gonka AI** будет представлена как один из самых серьёзных и перспективных проектов, реализующих именно второй (позитивный) сценарий — полезный Proof-of-Work, открытая сеть вычислений и реальная альтернатива централизованным корпорациям. Видео будет сделано в высоком качестве Falcon Finance: сильный сценарий, качественный монтаж, эмоциональная подача и глубокий анализ. --- ## 📦 Что входит в предложение - Полное производство видео под ключ (сценарий, озвучка, монтаж, визуализация) - Бессрочная публикация видео на канале Falcon Finance - Естественная и глубокая интеграция Gonka AI - Ссылки на официальный сайт - Право использовать ключевые фрагменты видео в наших целях (кроме коммерческих целей) --- ## 💰 Бюджет **$70 000** (GNK или USDT) ### Почему это хорошая инвестиция для Gonka - Выход на качественную, уже частично прогретую аудиторию (возможно, кто-то уже слышал про Gonka из интервью с Либерманами, но на ранней стадии проекта не нашел для себя точку входа) - Высокий уровень доверия канала → интеграция будет восприниматься как экспертное мнение, а не как реклама - Видео имеет все шансы стать вечным контентом и набирать просмотры годами, каждый раз когда тема будет получать новый виток и резонанс - Тысячи комментариев = мощный социальный отклик и органическое обсуждение проекта --- ## ❓ Возможные возражения и наши ответы **«70 тысяч долларов — это очень дорого»** > Для сравнения: обычная 2-минутная рекламная интеграция на канале Александра Соколовского стоит чуть больше 17 000 долларов. При этом она носит чисто информационный характер и не имеет глубокого рекомендательного веса. В нашем случае мы получаем не короткую рекламную вставку, а полноценное большое авторское видео длительностью 25–30 минут, сделанное в фирменном высоком качестве канала. Gonka AI будет интегрирована естественно и глубоко как важная часть позитивного сценария будущего. Кроме того, это эксклюзивная и уникальная возможность именно для нас, ранее на канале не выходило «платных видео». **«Мы можем найти более дешёвые варианты продвижения»** > Хороших каналов действительно немало, однако к ним крайне тяжело подойти с около-крипто продуктом. Ещё сложнее убедить автора принять оплату в монете проекта. И важно отметить, что каналов именно с такой концентрацией подходящей ЦА не так много. Подходящая ЦА — люди, которым может быть не всё равно и у которых срезонирует идея децентрализованного AI, и уже среди них могут быть и ранее инвесторы, и разработчики, и другие категории участников. **«Видео может не набрать просмотров»** > На канале Falcon Finance очень часто поднимается тема будущего, неопределённости, влияния технологий на экономику и общество. Видео в формате «Два сценария будущего» естественным образом впишется в существующие интересы аудитории. Предыдущие видео в похожем стиле стабильно собирают сотни тысяч просмотров и тысячи комментариев, что говорит о высоком потенциале органического охвата и долгосрочного интереса. --- ## 🗣 Вопросы для обсуждения Хотел бы услышать ваше мнение по следующим вопросам: 1. Как вы в целом оцениваете идею размещения большого содержательного видео именно на канале Falcon Finance у Александра Соколовского? 2. Насколько хорошо, по-вашему, тема «Два сценария будущего ИИ» (корпоративная монополия vs децентрализация) резонирует с текущей повесткой и ценностями нашего сообщества? 3. Есть ли у вас важные дополнения или акценты, которые обязательно стоит отразить в таком видео? > Если после обсуждения идея найдёт поддержку, подготовлю полный формальный пропосал для голосования. --- ## ⚠️ Важные условия и уточнения - **Стоимость** в $70 000 ниже не обсуждается. Если комьюнити предложит свою цену — мы готовы её рассмотреть, но ничего не обещаем. - **Охваты и просмотры** не гарантируются и не прописываются в условиях сделки. YouTube самостоятельно решает, какой аудитории и в каком количестве показывать контент. - **Gonka AI** не будет объектом прямой рекламы в видео. Мы гарантируем, что в ролике будут подсвечены положительные стороны децентрализованного ИИ и проекта Gonka, однако автор может упомянуть и спорные моменты проекта, а также сделать отсылки к другим технологиям и конкурентам. Это важно для сохранения доверия и аутентичности. - **Права на сохранение видео.** Автор оставляет за собой право скрыть видео в случае резких репутационных рисков, связанных с Gonka AI. Также через 1 год после публикации автор может пересмотреть целесообразность размещения видео. Однако при высоких просмотрах, вовлечённости и положительном резонансе видео, разумеется, останется в открытом доступе. --- **Жду ваших комментариев и обратной связи.** --- ## Comments (14) ### 💬 Дмитрий В *2026-04-29 01:03* · 👍 1 · 👎 0 Да, я из команды Александра. --- ### 💬 Дмитрий В *2026-04-29 01:21* · 👍 1 · 👎 0 Завтра посмотрю стату, поделюсь если есть такая инфа. Хотя и тот и тот вариант на мой взгляд ок, получать новых и греть старых тоже норм. Как мы видим сконвертилось за все время в RU чаты со всех источников ~2к человек на текущий момент, так что полезно бы и погреть старых. Кстати добавил бы сюда уведомления.) Хотя бы для автора тендера, чтобы мог сразу отвечать на вопросы. И прикреплять изображения еще, если можно.) --- ### 💬 Дмитрий В *2026-04-29 09:04* · 👍 1 · 👎 0 Помимо всего прочего, это как я и написал «сильная маркетинговая возможно», ни меньше. Если тут будут маркетологи, было бы интересно их мнение.) --- ### 💬 Sergey il *2026-06-07 14:03* · 👍 1 · 👎 0 В текущем виде данное предложение полное безумие. Хотя и я хорошо отношусь к данному автору. 1.На его второстепенном канале. 2.Упоминание вскользь. 3.Оплата если будет токенами они пойдут сразу в стакан по данному предложению ( безумие ) . 4.И все это за 70 тыщ $. 5. Сам факт отсутствия желания держать токены говорит, что автор не энтузиаст Gonka, зачем ему из данного проекта выделать тогда такую сумму на таком раннем этапе. Разумней выделять бюджет энтузиастам проекта, которые готовы вкладывать свои силы долгосрочно. Это выглядит супер оверпрайс при таких условиях. А тем более на данном этапе проекта. --- ### 💬 Evgenii Maksimenkov *2026-04-29 01:00* · 👍 0 · 👎 0 В тендере говориться: “мы готовы её рассмотреть, но ничего не обещаем”. Не совсем понятно от чего лица она выставлена. Дмитрий из команды Александра? Или это просто взято с сайта? --- ### 💬 Evgenii Maksimenkov *2026-04-29 01:11* · 👍 0 · 👎 0 А есть ли какие-то данные на сколько аудитория канала Falcon Finance пересекается с аудиторией канала с подкастами, где уже было интервью с братьями? Другими словами: сколько получится получить новой аудитории, которая ещё не видела интервью? --- ### 💬 Evgenii Maksimenkov *2026-04-29 01:35* · 👍 0 · 👎 0 Согласились бы вы получить сумму в GNK с вестингом? --- ### 💬 Alex Sharoiko Александр Шаройко *2026-04-29 04:15* · 👍 0 · 👎 0 Кажется, ты хотел составить таблицу со списком потенциальных каналов. Давайте с этого начнем. Какие еще каналы популярные есть на разных языках, и какие там цены? Есть ли каналы, которые готовы разместить контент бесплатно? 2. Братья уже ведь были на его канале. https://www.youtube.com/watch?v=wp7izqZmiWM&t=3121s Думаешь, аудитория там не пересекается? То интервью было платным? 3. Есть ли в сумме 70 000 комиссия организатора пропоузела? 4. Русский язык - это лишь малая часть интернета. Я предлагаю приложить усилия по выходу на международный уровень. --- ### 💬 Дмитрий В *2026-04-29 08:17* · 👍 0 · 👎 0 В общем в цифрах это не замерить. Но можно посмотреть косвенно по метрике «Что смотрят ваши зрители». На основном канале подкаста есть зрители которые за последнюю неделю посмотрели видео на канале Falcon Finance, но видео занимает 10 место из 15 других видео на других известных популярных каналах, там в основном подкасты и нонфикшн. Это низкая позиция, но какая-то доля есть. Это порядки думаю до 3-5%, точнее не возьмусь сказать. --- ### 💬 Дмитрий В *2026-04-29 09:00* · 👍 0 · 👎 0 1. Бро, про таблицу-список уже отвечал.) там речь про вертикальный контент, и в основном сиюминутные закупы того что актуально сейчас, в основном это были бы пользователи инференса, или просто нативное упоминание гонки в контексте постоянного дорожная токенов и отмены лимитов в подписках. Это разные задачи и типы контента. С ней тоже вернусь, но позже, эти идеи и задачи могут жить параллельно и никак не мешать друг другу, возможно только усиливать чуть-чуть. Если думаешь что для такого типа контента время не пришло, а для вертикальной рекламы у блогеров время пришло, напиши свои мысли. Я думаю не так, но можно пообсуждать тут сразу, может будут аргументы интересные. Я думаю надо брать возможность. 2. Было бы хорошо если бы пересекались аудитории, но что косвенно говорит стата — там максимум 3-5% пересечение, может и сильно меньше. Если было бы больше, было бы лучше на мой взгляд, чем больше касаний тем лучше. 3. Никакой комиссии не заложено. Я спросил команду стоимость, сюда ее принес как есть. Говорю как есть, у меня есть фикс процент за коммерческие коллабы которые мы создаем, но там даже не двухзначный процент если что. Но мой интерес есть, он стандартный, никаких сверх сумм тут не заложено. 4. Это тема не этой ветки. Я тоже думаю англоязычная аудитория ценнее, в долгую уж точно. Да, давай приложим усилия и выйдем еще и у англо аудитории.) Если вопрос намекает, что значит что на русскую совсем ничего не делать, даже не знаю что тут обсуждать.) я бы точно делал. Мне кажется это просто одно размещение из 100 которые будут. Если думать что это какое-то ван-шот гейм чейнд размещение, то это не так.) --- ### 💬 Alex Sharoiko Александр Шаройко *2026-05-01 06:54* · 👍 0 · 👎 0 Тогда можно возвращать, скажем, каждые 100 эпох. Т.е. регулярно. --- ### 💬 Il’gar *2026-05-02 19:42* · 👍 0 · 👎 0 Как идею поддерживаю, но в моменте кажется избыточным. Прежде всего из-за стоимости. GonkaTv - канал для (!!!) комьюнити, видится мне куда более эффективным вложением указанной суммы. Он поможет формировать общую повестку и не выпадать из контекста тем, у кого нет возможности следить за чатами. Думаю, если получится быть интересными прежде всего самим себе, оставив чуть приоткрытой дверь, то все остальное приложится. Сори за оффтоп. --- ### 💬 Alex Sharoiko Александр Шаройко *2026-05-02 19:43* · 👍 0 · 👎 0 Последнее сообщение не в тот чат случайно отправил. Оно про возврат наград Хостерам за прошедшие эпохи. --- ### 💬 Дмитрий В *2026-04-29 08:06* · 👍 0 · 👎 1 GNK ок. С вестингом не хочется, так как в любом случае вся сумма будет обменена на стейблы условно почти сразу. Нам вестинг не интересен. Если есть аргументы почему следует именно с вестингом делать пропосал, то конечно точно можно обсуждать. Кажется сумма не большая, чтобы пройти по otc и не влиять на что-то в экономике гонки. --- --- [View on gonka.vote](https://gonka.vote/proposal/550f71de-897f-4ce5-8af8-97854775f8b2) --- ## Gonka.TV — амбассадор Гонки на YouTube # Gonka.TV — амбассадор Гонки на YouTube 🔴 Expired **Author:** 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. Ищу поддержку сообщества. --- ## Full Proposal [Gonka.TV](http://Gonka.TV) — предложение сообществу Меня зовут Михаил, все меня знают под ником Mitch. Я основатель первого майнинг пула [gonka.top](http://gonka.top) и, судя по всему, неплохо умею объяснять сложные технические вещи простым языком — об этом мне говорят сами люди из сообщества. **Идея простая:** я хочу плотнее заняться YouTube-направлением и развить его в полноценный ресурс [Gonka.TV](http://Gonka.TV). --- ## Что я вижу в этом проекте ### 🎓 Обучающие материалы Сейчас нет нормальных видеоинструкций по Гонке: как поднять ноду вручную, как настроить сетевую ноду, мультинод-сетап, как работать с кошельками и блок-эксплорером. Всё это я готов снять — понятно, пошагово, без воды. Особенно важно для тех, кто только пришёл в крипту и хочет разобраться с нуля. ### 🎙️ Интервью и AMA Приглашать участников сообщества, программистов, людей, которые строят продукты на Гонке. Плюс — ходить на другие каналы как амбассадор проекта. ### 📢 Продвижение Я убеждён: ждать «пока продукт будет готов» — устаревший подход. Все успешные проекты строят аудиторию параллельно с разработкой. Чем больше людей знают о Гонке сейчас, тем больше среди них окажется тех, кто захочет участвовать — как разработчики, как хосты, как сообщество. --- ## Что нужно для запуска ### 💰 Зарплата Чтобы заниматься этим всерьёз, мне нужна оплата своего времени — по сути, зарплата, которой хватает на жизнь. Минимальная планка — **$5,000 в месяц**. ### 🎬 Монтаж Я не монтажёр — и тратить время на монтаж вместо съёмки и подготовки контента нет смысла. Фрилансер берёт порядка $100–200 за видео. При планируемом объёме это ещё **~$1,500–3,000 в месяц**. ### 🤝 Коллаборации с блогерами Органически попасть к миллионнику с каналом в 600 подписчиков сложно. Крупные блогеры берут за интервью — и это реальный способ дать Гонке трафик. Сообщество могло бы выделять бюджет на такие коллаборации отдельно, по мере необходимости. ### 🔧 Железо Минимум: кольцевая лампа, нормальный микрофон. Это копейки, разовые расходы. --- ## Примерный объём в месяц | Тип контента | Количество | |---|---| | Интервью и AMA-сессии | 4–5 | | Обучающие видео | 10–20 | --- ## Твоё мнение важно Что конкретно стоит делать? Обучалки или продвижение? Платные коллабы с крупными блогерами или органический рост? На что сообщество готово выделить ресурс? **Пиши своё видение в комментариях к тендеру: [vote.gonka.vip](https://vote.gonka.vip/)** --- ## Comments (6) ### 💬 Дмитрий В *2026-04-28 11:35* · 👍 4 · 👎 0 Делил бы маркетинг внутренний (инструкции и тд) и внешний (философия и подкасты). И возможно и каналы бы разные под это. Но делил бы не радикально.) серое это ок и там и там. Гонка тв для меня был бы интересен без инструкции, больше про трансляцию идей во вне, но и про внутреннюю кухню и события тоже ок, но простым языком, понятным свежему адепту. Митч как мне кажется может и так и так прекрасно транслировать. --- ### 💬 Mikhail Chudinov *2026-04-28 13:21* · 👍 3 · 👎 0 Gonka.TV это будет независимый компоненент --- ### 💬 Evgenii Maksimenkov *2026-04-27 23:55* · 👍 2 · 👎 0 Какой будет первый срок финансирования? Сколько месяцев должен покрыть первый грант? --- ### 💬 Il’gar *2026-04-28 02:16* · 👍 2 · 👎 0 Много раз высказывался под видео на ютюб и в чате. Повторяться, наверное, нет смысла - в последнем выпуске Митч утолил почти все мои чаяния. Добавлю только: вокруг метели, ориентиры потеряны. Многие умные и талантливые люди разочарованы событиями, на которые не могут повлиять. В таких обстоятельствах Gonkа.Tv имеет все шансы стать местом сборки. Дорого/дешево решать не мне, невесомый --- ### 💬 Dem | Démíngān *2026-04-28 06:30* · 👍 2 · 👎 0 Мне больше всего нравятся истории с коллабами с другими блогерами. Но тут возникает конфликт, если это делается от имени пула, то и монетизация идти должна от пула. Или Gonka.TV это независимый компонент? --- ### 💬 Mikhail Chudinov *2026-04-28 00:14* · 👍 1 · 👎 0 1 месяц думаю для первого достаточно --- --- [View on gonka.vote](https://gonka.vote/proposal/00e8a72a-e121-4ea1-8d30-95a0d51268b2) --- ## 12. Team Slava MSE Team Grant Request # 12. Team Slava MSE Team Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal 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**. ### Gonka Media Over the next three months, the team plans to: * Prepare and publish at least **180 posts** in Gonka Media — at least **2 posts per day**. * Expand content translation to **160 languages** using Gonka inference. * Cut at least **180 short video clips** from interviews and long videos. * Translate these video clips into at least **10 popular languages**. * Publish video clips and materials in open access so that national communities can reuse them in Telegram, Discord, YouTube, X, and other channels. * Invite two people to join the team: * Project Assistant. * Video Editor. ### Gonka Data Base / GonkaDB Over the next three months, the team plans to: * Move important articles from GitBook to GonkaDB. * Update existing articles in the Knowledge Base. * Expand the Knowledge Base with new materials about Gonka, including inference, hosts, wallets, governance, bridge, development, API, and community tools. * Create a prototype of Markdown documentation for hosts to simplify node deployment through AI agents and tools such as Cursor and Codex. * Improve old developer instructions and prepare new ones for connecting to and using Gonka inference. * Prepare instructions for connecting Gonka to programming tools and AI coding tools. 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/ ## What contributions or products has your team already developed for Gonka (with links pls)? Team Slava MSE Team has already developed and maintains several working projects for the Gonka ecosystem. ### Gonka Ranking Dashboard 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. ### Gonka Knowledge Base 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. ### Gonka Links Catalog 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. ### Gonka Media * Telegram: https://t.me/GonkaAI_Media * Discord: https://discord.gg/QznXmMjG8r * YouTube: https://www.youtube.com/@GonkaAI * Video and marketing materials archive: https://www.gonkadb.com/bin/view/OBSHCHEE/Gonka-Arkhiv-Video/ 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. ## GNK Wallet Address gonka1nkv9ls3usj0az2waax0zhgndqx9kcl0dusrr6g ## Your Discord ID for Contact Purposes alexandr8475 ## Email Address [penspinning.mse@gmail.com](mailto:penspinning.mse@gmail.com) --- ## Comments (1) ### 💬 Slava MyGonka *2026-06-11 08:01* · 👍 0 · 👎 0 Кто-то хочет принять участие в этом? Оплата в GNK )) Назовите свою цену, будем думать. В планах у меня взять обычного человека на работу на четверть ставки в свою организацию и просто платить ему зарплату. Но можно и кого-то из Комьюнити. Пока у меня не очень хороший опыт работы с волонтерами Комьюнити. Начинают резво, и потом пропадает запал. --- --- [View on gonka.vote](https://gonka.vote/proposal/08405617-5654-4ead-be62-642affa1739e) --- ## Интеграция ИИ Gonka в инфраструктуру QR Mint # Интеграция ИИ Gonka в инфраструктуру QR Mint 🔴 Expired **Author:** 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 для автоматической генерации условий бонусов и проверки вали --- ## Full Proposal Интеграция ИИ Gonka в инфраструктуру QR Mint ## Обзор проекта **QR Mint** — это существующая инфраструктура для создания, дистрибуции и монетизации цифровых активов в нескольких блокчейн-сетях. Платформа уже включает: * создание и управление NFT; * реферальные механики; * партнёрские программы и бонусные системы; * API для платежей и цифровых активов; * инфраструктуру для подключения сторонних проектов. Мы предлагаем интегрировать **ИИ Gonka** непосредственно в QR Mint как интеллектуальный слой, который смогут использовать все проекты, работающие через платформу. --- ## Почему именно QR Mint (https://qr-mint.net) Большинство AI-интеграций создаются для одного продукта. Мы предлагаем другой подход. Вместо интеграции ИИ в отдельную игру или NFT-коллекцию, мы интегрируем его в инфраструктуру. После подключения Gonka любой будущий проект, использующий QR Mint, сможет получить доступ к AI-функциям через единую систему. Это создаёт масштабируемый канал распространения технологий Gonka. --- ## Что будет делать ИИ ### Генерация механик вознаграждений ИИ поможет создавать: * механики полезности NFT; * бонусные программы; * системы лояльности; * партнёрские вознаграждения; * модели вовлечения пользователей. Цель — помочь проектам создавать более устойчивые цифровые экономики. --- ### Аналитика поведения пользователей Система сможет анализировать: * вовлечённость пользователей; * удержание аудитории; * использование цифровых активов; * эффективность бонусных программ. Эти данные будут полезны как проектам, так и для дальнейшего развития ИИ Gonka. --- ## Демонстрационный кейс: HardCore Arena (сама игра game.qr-mint.net) Для демонстрации интеграции будет использована **HardCore Arena** — существующая игра, разработанная нашей командой. Текущее состояние проекта: * рабочая игра; * редактор уровней; * 31 уровень; * турнирная механика. --- ### Балансировка сложности ИИ сможет анализировать прохождение уровней и рекомендовать изменения для повышения качества игрового процесса. ### Помощь в создании уровней На основе существующих данных ИИ сможет помогать авторам создавать новые уровни и игровые сценарии. --- ## Почему это выгодно Gonka ### Инфраструктурный канал распространения Одна интеграция открывает доступ ко всем будущим проектам, использующим QR Mint. Нет необходимости интегрировать ИИ отдельно в каждое приложение. --- ### Реальное применение ИИ Gonka становится частью работающей экосистемы, а не экспериментальным прототипом. Технология получает практическое применение в цифровых активах, игровых механиках и системах вовлечения пользователей. --- ### Данные для развития ИИ Интеграция создаёт поток реальных данных из: * игровых систем; * бонусных программ; * цифровых активов. Это позволяет улучшать модели на основе реального пользовательского поведения. --- ## Наш вклад Мы предоставляем: * готовую инфраструктуру QR Mint; * готовый демонстрационный проект HardCore Arena; * разработку интеграции; * тестирование; * документацию; * привлечение первых пользователей платформы. --- ## Запрашиваемое финансирование **10 000 долларов** Средства будут направлены на: * разработку AI-модулей; * интеграцию Gonka в QR Mint; * тестирование и оптимизацию; * документацию; * привлечение первых проектов, использующих новую инфраструктуру. --- ## Видение Мы предлагаем Gonka получить инфраструктуру, данные и первый игровой кейс для развития собственного направления AI для игр Наша цель — создать инфраструктурный слой, который позволит использовать возможности Gonka во множестве проектов: играх, NFT-системах, программах лояльности, цифровых активах и будущих Web3-приложениях. **QR Mint становится инфраструктурой. Gonka становится интеллектуальным слоем. HardCore Arena становится первым работающим примером применения этой технологии.** --- ## Comments (7) ### 💬 Victor *2026-06-11 09:50* · 👍 0 · 👎 0 Сама игра в телеграмме https://t.me/TheWorldHardestGame_bot --- ### 💬 Slava MyGonka *2026-06-11 10:17* · 👍 0 · 👎 0 Привет! Жалко, что нельзя текст редактировать, верно? ) Я уже попросил разработчиков это поправить. Но, возможно, это не БАГ, а Фича? ) 2. Средства лучше запрашивать в GNK с Вестингом, как мне кажется. 3. Это - коммерческий проект? 4. Это полностью ваш проект или вы как посредник? 5. На сколько хорошо вы знаете проект Gonka? 6. Есть ли какой-то измеримый результат вашей предполагаемой работы? Игра у меня так и не загрузилась. Черный экран и Loading. https://prnt.sc/NKQcDLAwSzAH --- ### 💬 Victor *2026-06-11 11:07* · 👍 0 · 👎 0 Привет, 6 Это баг в игре, нужно 2 раза обновить, но или попробуйте обновить через game.qr-mint.net 3 и 4 Это мой проект, я несу полностью отвсетвенность так и за техническую часть так и за маркетинг и дистрибуцию 5. Досточно хорошо, сам гонка сделан на блокчейн космос тот использует использует архитектуру Tendermint, реализован братьями Либерманами. С опытом космовских сеток я досточно знаком и есть опыт с ИИ частью пока не работал, как планирую закончить блокчейн часть 6. Да, есть это во первых это - техническая интеграций часть интеграция от блокчейна до ИИ, - А также транзакций можно будет все отследить - Аудиторий, по тем же игрокам, метрикам и так далее Но это будет работать если проект будет развиваться дальше, а на это нужно средства, поэтому я сделал за прос на грант --- ### 💬 Victor *2026-06-11 11:07* · 👍 0 · 👎 0 Привет, 6 Это баг в игре, нужно 2 раза обновить, но или зайте через game.qr-mint.net , там выше отпечатка --- ### 💬 Victor *2026-06-11 15:05* · 👍 0 · 👎 0 Адрес кошелька GNK gonka1h8fxp0mpn9kyw4swe8y8xsh5k58kuugevqdmym Telegran dao0dev Адрес электронной почты qr.mint.dev@gmail.com --- ### 💬 Mitch *2026-06-24 16:53* · 👍 0 · 👎 0 Для меня ваш проект выглядит как клиент, который мог бы использовать инфиренс от гонки. Интеграцию вам надо делать с любым из броккеров гонки. Не вижу причин, по которым бы такая разработка и интеграция бы спонсировалась из комьюнити пула. Создание брокеров мы кстати тоже не спонсируем, люди просто делают бизнес. И вы тоже можете построить продукт, использя дешевый инфиренс. --- ### 💬 Mitch *2026-06-24 17:00* · 👍 0 · 👎 0 Если бы у вас был трафик, то это имело бы какой то смысл, а так у вас 0 пользователей по сути. --- --- [View on gonka.vote](https://gonka.vote/proposal/7d2ec26b-6524-4fc6-b676-a13d822536e8) --- ## Go-To-Market Team for 3 Month to Set Up the Basis # Go-To-Market Team for 3 Month to Set Up the Basis 🔴 Expired **Author:** 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. --- ## Full Proposal Internal Go-To-Market Team for Gonka [Read full proposal](https://app.integrity.sh/p/SuMCnGQBhz-0asAYBUz1U) ## Summary 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. ## Main Goals - Build onboarding funnels for key target audiences from the Gonka roadmap. - Set up unified marketing analytics across the Gonka ecosystem. - Test channels, offers, landing pages, and audience segments. - Build shared knowledge about target audiences, competitors, and positioning. - Create CRM systems for B2B leads, AI aggregators, accelerators, communities, and influencers. - Coordinate GTM work between internal and external contributors. - Support ecosystem services such as inference brokers, wallets, mining pools, and GNK exchange flows. - Target: reach around 2,000 non-RU monthly paying users with an average bill of $200 per month. ## Scope of Work ### 1. Acquisition Funnels 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. ### 2. Marketing Analytics 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. ### 3. Hypothesis Management All GTM hypotheses will be collected in one shared place, including: - target audiences - channels - offers - formats - test results - acquisition cost - lead quality - ideas to scale next ### 4. CRM and Outreach Separate CRMs will be built for: - B2B companies - AI aggregators and OpenRouter competitors - AI accelerators - communities - influencers - strategic partners Each contact will include communication details and current status. ### 5. Ecosystem Support 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. ### 6. Competitor Research Competitor analysis will be split by audience type: - inference users: OpenAI, Anthropic, OpenRouter, Together.ai, and others - GPU holders: Bittensor, io.net, Aethir, Vast.ai, RunPod, TensorDock - investors: decentralized AI projects, semiconductor stocks, and other investment alternatives - AI/ML labs: decentralized networks, centralized clouds, and data centers ## Go-To-Market Plan The first month will focus on setup and testing: - analytics setup - onboarding funnels - pSEO, GEO, and AEO website structure - early community and influencer tests - initial GTM strategy - first acquisition experiments After the setup phase, the team will scale the best-performing channels and formats. Reporting will include: - bi-weekly contribution-based award distribution - AMAs with the team - dashboards with key results - transparent updates for Gonka service creators and ecosystem participants ## Team The project is led by experienced C-level operators who have been investing in Gonka since November 2025. ### Key People - Viktor Katsman: [LinkedIn](https://www.linkedin.com/in/viktor-katsman/) - Arseny Myakotnikov: [LinkedIn](https://www.linkedin.com/in/arseny-myakotnikov-5a4341177/) Relevant experience includes: - 10+ years in marketing - 7+ years in web3 - crypto experience since 2017 - GTM strategy for fintech, web3, AI, and B2B SaaS products - paid traffic, influencers, PR, content, SEO/GEO, communities, partnerships, token launches, analytics, and product marketing - experience building products from 0 to 1 - major achievement: attracting $300M+ AUM for a DeFi hedge fund and scaling active users from around 1K to 15K+ ## Recent GTM Contributions Over the last two months, the team has already participated in Gonka go-to-market activities: - Viktor Katsman created the first version of the GTM strategy and led the Marketing track in the applied roadmap. - Hleb Dapkiunas worked on startup business development and collected useful requirements from the market. - Viktor Katsman helped secure a meaningful case where Integrity added Gonka models in beta as “Powerful models at a fraction of the price”. ## Budget ### Team Bonus - 840K GNK total vesting bonus - 280K GNK per month for 3 months - team size: around 8-15 people - some tasks may be delegated to external agencies - the bonus is designed to align the team with long-term GNK growth ### Monthly GNK Allocation | Direction | Budget per month | |---|---:| | Analytics | 30K GNK | | pSEO + AEO | 30K GNK | | B2B: inference sellers, users, and investors | 60K GNK | | B2C: agent users, AI startup founders, indie devs | 50K GNK | | Reddit posts + subreddit | 30K GNK | | Community collaborations | 30K GNK | | Influencer collaborations | 30K GNK | | Paid traffic activities | 10K GNK | | Product Hunt launches | 10K GNK | | **Total** | **280K GNK / month** | ### USDT Budget - 54K USDT total - 18K USDT per month - not paid to the team directly | Direction | Budget per month | |---|---:| | Google Search experiments for inference users | 5K USDT | | External supporters for social activities | 3K USDT | | Influencers, communities, listings, partnerships, tools, agencies, conferences, and other GTM activities | 10K USDT | | **Total** | **18K USDT / month** | The exact allocation may change during execution based on what performs best. ## Actual Cost - 840K GNK vesting bonus - 54K USDT operational GTM budget ## Additional Materials - [Internal GTM draft strategy](https://docs.google.com/spreadsheets/d/1jjVCJqyQvjKfc_tSB5Wy9Z5w7tGm4Eq3jXGJtlD1r9I/edit?usp=sharing) - [Gonka Network Development Roadmap](https://github.com/gonka-ai/gonka/blob/d5e30ca891209f25fd84e36ef439e1f54ec9090c/proposals/gonka-network-development-roadmap.md) [Read full proposal](https://app.integrity.sh/p/SuMCnGQBhz-0asAYBUz1U) --- ## Comments (9) ### 💬 Dem | Démíngān *2026-07-04 12:16* · 👍 2 · 👎 0 AMA: https://youtu.be/tYfeXANyPtM?si=uKUTEboIwh2HJ5tR&t=3747 --- ### 💬 Andrey A *2026-07-06 08:07* · 👍 2 · 👎 0 Прошу за личную критику не воспринимать. Если работа подается как проектная и при этом не раскрывается структура вознаграждения конкретных участников, сразу возникают вопросы к релевантным кейсам именно этой команды. Сейчас таких кейсов в предложении фактически нет (и не может быть, так как команда будет собираться). Если же бюджет запрашивается на построение GTM-команды, то он должен быть разделен на понятные категории: ФОТ, рекламные бюджеты, подрядчики, инструменты, мероприятия и прочие операционные расходы. Решено это не делать в том числе по соображениям безопасности - ок, но тогда предложение становится слабее. Сумма запроса значительная. Она превышает бюджеты, которые ранее запрашивали известные компании. Выделение такой суммы возможно только после детального изучения пропоузеров: валидации заявленного опыта, связи с бывшими партнерами, работодателями или клиентами, проверки реальных результатов и роли участников в этих результатах. Насколько я понимаю, сейчас в Gonka нет устойчивой структуры, которая могла бы провести такую проверку. Поэтому более разумным выглядит дождаться формирования foundation или другой governance-структуры, которая сможет выполнять due diligence подобных предложений. Тем более BF говорили, что их как раз это волнует. Кроме того, большое количество правок этого предложения до публикации, по словам самих пропоузеров, дополнительно подтверждает, что выбранная структура и формат запроса остаются спорными. --- ### 💬 Viktor *2026-07-05 15:45* · 👍 1 · 👎 0 1. Конфликт интересов: вопрос/критика -> наш ответ -- вопрос/критика -- Конфликт интересов у авторов/исполнителей пропозала в связи с тем, что они также являются влиятельными членами Go-To-Market комитета. "Не смогут объективно координировать других исполнителей." "Не смогут объективно оценивать другие входящие пропозалы, будут стараться из завалить" -- наш ответ -- 📌 I. Конфликты интересов будут у всех активных людей, которые пойдут работать на благо Gonka. Все хотят заработать побольше. Задача сети: привлекать экспертных людей, готовых долго и консистентно работать в обмен за возможность много выиграть при успехе проекта. 📌 II. Замечу, что сейчас мы уже существуем в состоянии глубочайшего конфликта интересов. Все, у кого есть полезные инсайды по продвижению, стараются делиться ими очень осторожно, вымеряя, что они получат взамен. Ведь, скорее всего, ничего не получат. Особенно это относится к внешним исполнителям. А что если The Soul, пользуясь большими бюджетами сети для продвижения, воспользуется моими инсайдами, но направит трафик мимо моего брокера? Мало кто хочет активно работать над Gonka бесплатно. Если люди будут тратить своё время, но ничего за это не будут получать — либо они все быстро выгорят, либо у нас родится куча всяких коррупционных схем. Люди тихой сапой будут продвигать пропозалы своих ставленников за откаты, убеждать их вести трафик именно на свои сервисы, и тд. Чтобы это предотвратить, нам надо найти способы финансировать людей в соответствии с их заслугами. Наше предложение напрямую направлено на решение этой проблемы в части go-to-market. 📌 III. Конфликт интересов в оценке нашего собственного пропозала безусловно есть, мы лично хотим чтобы он был принят, и чтобы мы получили вознаграждение. 📌 IV. Конфликта интересов в работа с внешними исполнителями станет сильно меньше. Наша задача: продемонстрировать нашу эффективность за 3 месяца, получить от сети премии: удвоения-утроения GNK и быть продленными дальше. При этом наш бюджет и возможности сейчас очень ограничены. Разумеется, мы будем рады независимо пришедшим качественным внешним исполнителям, благодаря которым наш бюджет и возможности расширятся. Конфликт интересов возникнет только если начнет образовываться другая сильная команда, готовая системно работать над go-to-market и не желающая объединяться / не согласная с нашей стратегией. В этом случае к нашему мнению нужно будет относиться более критически. Но не стоит забывать, что мы как держатели GNK лично заинтересованы во всем, что приводит к росту цены GNK. --- ### 💬 Viktor *2026-07-06 16:00* · 👍 1 · 👎 0 Спасибо за комментарий! 1. Структура вознаграждения и кейсы частично имеются; довольно много людей, с которыми планируем начинать, известны. Многие из них уже много вкладываются в Gonka, и сделали много полезного бесплатно. 2. Бюджет на категории разделен с поправкой на то, что мы находимся на ранней стадии и сами не знаем, что лучше заработает. 3. По сумме: здесь как раз можно обсудить с конкретикой по заявленным планируемым тратам бюджетов. Последнее не понял. В любом случае мы сейчас максимально открыты к обсуждениям. --- ### 💬 Viktor *2026-07-05 15:47* · 👍 0 · 👎 0 2. Надо ли сейчас заниматься go-to-market: вопрос/критика -> наш ответ -- вопрос/критика -- Стоит ли заниматься Go-To-Market для пользователей инференса, пока сеть не работает стабильно? Ну привлечем мы аудиторию, она обожжется. Потом даст 2й шанс. Снова обожжется. Станут ли пользоваться 3й раз? -- наш ответ -- 📌 По этому вопросу было очень много дискуссий, в том числе при обсуждении Roadmap. И было принято решение, что нужно. В том числе, что уже сейчас нужно исследование целевых аудиторий, понимание как их дешево находить, что и в каком формате им предлагать; как приоритизировать задачи в разработке чтобы быстрее удовлетворить запрос ключевых сегментов пользователей. "Хоп, инференс заработает — и люди прибегут" — так бывает очень редко, и все равно ограниченно. За Roadmap с этим решением проголосовали, он принят, не хочется откатываться назад. 📌 Также нам крайне важна отладка сети, в том числе отладка механизмов рыночной регуляции. Без этой отладки аудитория все равно обожжется. только позже. 📌 Безусловно, в коммуникациях с пользователями надо подсвечивать, что проект еще на ранней стадии и что сеть нестабильна — и предлагать пробовать именно тем, кому сеть интересна уже в текущем состоянии. --- ### 💬 Viktor *2026-07-05 15:49* · 👍 0 · 👎 0 3. Почему сразу много направлений, а не одно лучшее: вопрос/критика -> ответ -- вопрос/критика -- Почему мы планируем сразу много направлений, а не одно гипотетически самое конверсионное? -- ответ -- 📌 Вероятность того, что одно направление выстрелит, слишком мала чтобы все ставить на него. 📌 Наша задача: дойти до ощутимых результатом и продемонстрировать нашу эффективность за 3 месяца. Это НЕ "попробовать способ продвижения Х", а найти реально работающие способы продвижения. 📌 Мы много думали и сами, и разговаривали с опытными CMO, спрашивали, на чтобы бы они сделали ключевую ставку. Топ собранных мнений: 📌 1. Нужна ставка на реселлеров инференса: openrouter, together.ai, requesty, liteLLM — у них уже есть большие объемы, Gonka для них это существенная экономия, а для Gonka это существенный спрос. НО в B2B всегда долгий цикл сделки и есть риск: Gonka сейчас на слишком ранней стадии для них, наша сеть нестабильна, у нас исчезают модели. 📌 2. Нужна ставка на B2C, на строителей агентов и indie-хакеров: они могут сразу подключиться, заплатить за токены вперед и рассказывать об опыте использования. НО Угадать с направлением, языком, способом привлечения и оффером заранее едва ли получится. Нужно будет проверить много разных гипотез. Нужны либо активные энтузиасты, либо деньги на платный маркетинг. 📌 В итоге мы отобрали треки, которые, наиболее вероятно, приведут к успеху, и планируем по ним двигаться. При этом ситуация меняется, мы планируем регулярные брейнштормы по целевым аудиториям и гипотезам их привлечения — и вполне может быть, что наши фокусы по ходу этих трех месяцев изменятся. Также есть аналитика, pSEO, соцсети, и другие вещи про узнаваемость бренда Gonka, которые критически важны по всем направлениям, и странно ими не заниматься если это в любом случае важно для проекта и способно кратно повысить эффективность по остальным направлениям. --- ### 💬 Viktor *2026-07-05 15:50* · 👍 0 · 👎 0 4. Бонус в GNK. Он на команду 8-15 человек? Слишком большая разбежка. Это фултайм? И что это за люди и кто нанимает? -- ответ -- 📌 Мы отвечаем за успех инициативы, и, следовательно, найм. Планируем вовлечь и активных людей из комьюнити, и извне. Кто-то готов вовлекаться fulltime, кто-то - part-time. 📌 Работать будем по направлениям (B2B, B2C, узнаваемость бренда Gonka) и спринтам (2 недели). На каждое направление+спринт выделяется бюджет, который в конце распределяется между участниками пропорционально вкладу и достигнутым результатам. Те, кто работает лучше, получает больше. Менее успешные меняют стратегию или выпадают. 8-15 - примерная оценка числа людей, попадающих в спринт. Для распределения наград планируется использовать AI-агентов, помогающих собирать проделанную работу и достижения, систематизировать это, готовиться к АМА, и, в том числе, распределять награды. --- ### 💬 Viktor *2026-07-05 15:51* · 👍 0 · 👎 0 5. Цена очень дорогая. Почти 1 млн гнк из 120 млн в community. -- ответ -- 📌 Полная сумма из бюджета, которую мы хотим аллоцировать под это дело на 3 месяца ~ 3М GNK. 840K GNK - это минимальная оплата в GNK в вестинге чуть ниже рынка прямых зарплат в USD. C момента обсуждения нами ставок с участниками курс GNK упал на ~ 35%. Существенная часть мотивации соглашаться на работу в таких условиях: удвоение-утроение бонуса в случае хороших результатов работы, запросы на выплаты которых планируется подавать отдельными пропозалами по результатам. 📌 Много раз обсуждалось, сколько GNK нам логично тратить в месяц на продвижение на раннем, и, во многом, определяющем этапе. Назывались цифры и в 1M GNK, и в 2M GNK в месяц. Наш запрос укладывается в минимальную из оценок. Также замечу, что предыдущие месяцы GNK на продвижение из community на продвижение практически не выделялись. Эти средства есть, лежат, и обесцениваются вместе с падающим курсом GNK. 📌 На подготовку этого предложения ушло 2 месяца. Мы учли децентрализованные особенности проекта: как вовлечь и уже имеющихся предпринимателей изнутри, и предпринимателей извне; как справедливо и эффективно распределять трафик между сервисами, не сильно теряя в эффективности воронок привлечения; как лучше организовывать работу по привлечению целевых аудиторий разных типов в нашем случае. --- ### 💬 Viktor *2026-07-05 15:52* · 👍 0 · 👎 0 6. Каковы личные бонусы у вас или других сотрудников? -- ответ -- Не будут раскрыты: 1. По причинам безопасности и конфиденциальности (так же как корпорации не раскрывают публично зарплаты своих сотрудников) 2. Потому что мы их сами еще не знаем. У нас есть референсные цифры, но это сильно зависит от того, как пойдет проверка тех или иных гипотез, какие направления кажутся более эффективными и как будут распределяться бюджеты внутри Например: если я могу отдать 10% своих GNK за активность, которая вырастит их курс на 20% — я с удовольствием это делаю. --- --- [View on gonka.vote](https://gonka.vote/proposal/cb7f643f-3d56-47ec-9193-f9f2f80a99fb) --- ## 8. Team Gonka.TV Grant Request # 8. Team Gonka.TV Grant Request 🔴 Expired **Author:** 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. --- ## Full Proposal 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. ## What contributions or products has your team already developed for Gonka (with links pls)? The team has already produced news and educational videos for the Gonka community, as well as interviews with AI YouTubers. ## GNK Wallet Address gonka1fx65y7jfce6q4cj3zf7wvfuse3juu7c8gg0hqp ## Your Discord ID for Contact Purposes mitchseed ## Email Address [newmitch@gmail.com](mailto:newmitch@gmail.com) --- ## Comments (1) ### 💬 Slava MyGonka *2026-06-11 07:30* · 👍 0 · 👎 0 )) Я прочитал это предложение и прям улыбнулся. Оно по приколу сделано? )) А теперь серьезно: 1. Как часто планируются ролики? Хорошо бы иметь цифры. 2. Будет ли монтаж? 3. Будет ли перевод на другие языки? (тут я могу помочь) 4. Презентабельность добавим? Задний план, картинка, фоновые звуки 5. Логотип бы ) 6. Работает команда? 7. Сколько средств ты бы хотел получить на 3 месяца производства контента? Мне нравятся твои видео. Всегда их смотрю. Ты умеешь последовательно излагать и не терять мысль по ходу изложения. Молодец! ) --- --- [View on gonka.vote](https://gonka.vote/proposal/47ab8faa-f9bd-41ba-8e86-6c760d4975a6) --- ## International Marketing Campaign for Gonka — English-Speaking Markets # International Marketing Campaign for Gonka — English-Speaking Markets 🔴 Expired **Author:** 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. --- ## Full Proposal 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. ## 2. Objectives The Campaign MUST drive measurable growth in three primary funnels: 1. **Hosts** — onboard new compute providers (target audience: GPU farm operators, mining pools transitioning from ETH/BTC, mid-tier data centers). 2. **Developers** — drive API adoption (target audience: AI builders seeking OpenAI-compatible alternatives, Web3 devs, indie LLM app developers). 3. **Token holders / community** — grow informed, retained holder base (target audience: DePIN investors, crypto-AI thesis traders, governance participants). Brand awareness is a secondary KPI, not the primary one. Vanity metrics (impressions, follower count alone) are NOT acceptable as primary deliverables. ## 3. Target Markets and Audience - **Geography**: United States, United Kingdom, Canada, Australia, Singapore, UAE, Western Europe (English-language content only for v1). - **Languages**: English only. Localization to other languages is OUT OF SCOPE for this tender. - **Channels (mandatory coverage)**: - X (Twitter): crypto-AI KOLs, DePIN community - YouTube: long-form technical content, AMAs, host setup tutorials - Podcast circuit: Bankless, The Defiant, Empire, Unchained, Lightspeed, equivalent tier - Reddit: r/CryptoCurrency, r/MachineLearning, r/LocalLLaMA, r/ethereum (informational, non-spam) - Discord/Telegram: organic community growth, AMA hosting - Technical media: CoinDesk, The Block, Decrypt, Blockworks, Cointelegraph, Messari, Delphi Digital - Developer channels: Hacker News, Dev.to, Hashnode (continuing existing `what-is-gonka.hashnode.dev`), Substack, Mirror ## 4. Agency Requirements (Mandatory) Bidders MUST demonstrate **all** of the following: 1. **Portfolio**: minimum **5 prior crypto/Web3 campaigns** completed in the last 36 months, with at least **2 in the DePIN, L1, or decentralized-AI category**. Case studies with verifiable before/after metrics are required. 2. **Crypto-native team**: lead strategist, content lead, and KOL manager MUST have ≥3 years in crypto marketing each. CVs with on-chain or public attribution required. 3. **English-native content**: all copy, scripts, and long-form content MUST be authored or edited by native English speakers. AI-generated copy is permitted as a draft tool only; final outputs MUST be human-edited and disclosed. 4. **KOL relationships**: documented working relationships (not cold outreach) with minimum **30 crypto KOLs** in the 50K+ follower tier on X, with at least **10 specifically in the AI/DePIN niche**. 5. **Media access**: existing editorial relationships with at least **3 of**: CoinDesk, The Block, Decrypt, Blockworks, Cointelegraph, Messari, Delphi Digital. Pay-to-publish placements MUST be disclosed and excluded from earned-media KPIs. 6. **No conflicts**: no active engagement with directly competing networks (Bittensor, io.net, Akash, Render, Aethir, Prime Intellect) during the campaign and for 6 months after. Disclosure of any historical engagements required. 7. **Compliance**: ability to comply with FTC disclosure rules, MiCA where applicable, and SEC guidance on token promotion. No unregistered securities-style promotion. ## 5. Phased Structure and Payouts 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. ### Phase 1 — Discovery, Positioning, and Asset Production (Weeks 1–6) — 15% of total budget **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). ### Phase 2 — Launch Wave and Earned Media (Weeks 7–14) — 25% of total budget **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 | 150K | Pro-rated payout below the floor: 0%. Bot-filtering methodology MUST be specified in the proposal (e.g., HypeAuditor, SparkToro, or equivalent third-party verification). ### Phase 3 — Conversion and Adoption Drive (Weeks 15–26) — 35% of total budget **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 on `gonka-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. ### Phase 4 — Sustain, Measure, Handover (Weeks 27–32) — 25% of total budget **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 | ## 6. Measurement, Verification, and Anti-Fraud - **Independent verification**: KOL impressions, follower deltas, and bot percentages MUST be verified by an independent tool (HypeAuditor, SparkToro, Modash, or equivalent) and the raw report attached to each invoice. - **On-chain attribution**: Host onboarding KPIs MUST be verified by on-chain Host registration events; agency-submitted lists are NOT sufficient. - **UTM hygiene**: all campaign traffic MUST flow through UTM-tagged links; attribution dashboard (e.g., PostHog, Plausible, Matomo) MUST be set up and read-access shared with Gonka. - **No fake engagement**: any detected use of bots, follow/unfollow farms, comment pods, or paid engagement without disclosure triggers immediate termination and forfeiture of the current and remaining phase payouts. - **Sentiment monitoring**: agency MUST run continuous sentiment monitoring (e.g., LunarCrush, Santiment, or equivalent) and report weekly. Sustained negative sentiment shifts attributable to campaign messaging require remediation at agency expense. ## 7. Reporting Cadence | Frequency | Content | |---|---| | Weekly | KPI dashboard snapshot, content shipped, upcoming week plan | | Bi-weekly | 30-min sync with Gonka core team | | End of each phase | Phase-completion report, KPI verification, invoice | | End of campaign | Full funnel attribution, post-mortem, lessons-learned doc | All reporting tools MUST grant read-access to designated Gonka team members. No reporting via screenshots only. ## 8. Brand and Messaging Constraints - All messaging MUST be technically accurate. Claims about throughput, cost, decentralization, or compliance MUST be reviewed by Gonka technical leads before publication. - No price predictions, no "guaranteed returns" framing, no securities-implication language. - No FUD against named competitors. Comparison content is permitted but MUST be data-driven and reviewed by Gonka. - Discord and Telegram moderation MUST follow Gonka's existing community guidelines. - Agency-produced content MUST be reviewable in draft for ≥48h before publication for tier-1 placements; ≥24h for routine content. ## 9. Deliverables (Final) By end of Phase 4: 1. Full asset library transferred to Gonka (raw files, source files, brand book). 2. KOL and media contact list with relationship notes. 3. Content playbooks: launch playbook, KOL activation playbook, crisis comms playbook. 4. Final attribution report (PDF + raw data). 5. 30-day post-campaign retention report. 6. Recommendations for Phase 5 (in-house continuation or rebid). ## 10. Out of Scope - Non-English localization (separate tender if needed). - Token listings and exchange relations (handled by Gonka/Product Science directly). - Influencer-paid deals exceeding $50K per individual without Gonka pre-approval. - Paid advertising spend (separate budget line, not part of agency fees). - Investor relations and VC outreach. ## 11. Submission Requirements Bidders MUST submit: 1. **Agency profile** with team CVs and disclosure of all current and past 12-month crypto clients. 2. **Portfolio**: 5+ case studies with verifiable metrics, ≥2 in DePIN/L1/decentralized-AI. 3. **KOL roster** (sample of 30+ with niche tags, follower tier, prior collaboration evidence). 4. **Media access matrix**: which tier-1/tier-2 outlets the agency has direct editorial relationships with. 5. **Phase-by-phase proposal** mapped to Sections 5.1–5.4, with proposed budget per phase. 6. **Total budget** (USD or USDC; payment in GNK acceptable for up to 50% with mutually agreed lockup terms). 7. **Risk register**: top 5 risks the agency sees in this campaign and proposed mitigations. 8. **Conflict-of-interest disclosure** per §4.6. --- ## Comments (2) ### 💬 Дмитрий В *2026-05-03 22:04* · 👍 0 · 👎 0 Тут двояко: "Платные сделки с инфлюенсерами, превышающие $50K на одного человека, без предварительного одобрения Gonka. Расходы на платную рекламу (отдельная статья бюджета, не входит в гонорары агентства)." то есть рекламные размещения до 50к входят или не входят в пропосал? Я бы предложил наверное более явно прописал по бюджетам мысли. А то голосующие могут не понять как голосовать по сумме гранта. Ну и про передачу доступов и контактов это тонкая история, комьюнити тут ничего не решит и никак не возьмет по умолчанию материалы, тем более часть из них чувствительная. Или продумал бы это заранее или возложил бы сразу на исполнителя продумать это и создать технологию передачи активов как-то технологично. --- ### 💬 Дмитрий В *2026-05-03 22:15* · 👍 0 · 👎 0 Думаю я бы в целом дал бы больше свободы исполнителю, а то с одной стороны запрос на топ-1 исполнителя, с другой стороны рамки по стратегии и создание некого фрейма неповоротливости. А ситуация в поле может меняться быстро, тем более в теме ии. Добавил бы еще, что это все не строго, если исполнитель видит по своему и уверен в силах, обладает регалиями, пусть вызывается, мы его рассмотрим. И возникает странная обратная ситуация), если исполнитель зайдет на эту страницу и увидит тендер где предложено сообществом условно по курсу сейчас это 30 млн руб, то развернется и не будет тратить силы.) то есть мы никак не привлекаем так сильных ребят, а отгоняем чтоли.. --- --- [View on gonka.vote](https://gonka.vote/proposal/28dcf8fb-3138-4e8b-adc0-0fb82962276c) --- ## On-Chain Governance Proposals # On-Chain Governance Proposals Passed Rejected Voting With Funding ## Overview 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 ## 2026-Q3 *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) ## 2026-Q2 *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%) ## 2026-Q1 *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%) ## 2025-Q4 *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%) ## 2025-Q3 *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%) 90 proposals across 5 quarters. Last updated: 2026-07-26 07:25 UTC function _ovInit() { document.querySelectorAll('.prop-vote-countdown').forEach(function(el) { var deadline = new Date(el.getAttribute('data-deadline')); function update() { var diff = deadline - new Date(); if (diff 0) el.textContent = d + 'd ' + h + 'h ' + m + 'm'; else if (h > 0) el.textContent = h + 'h ' + m + 'm'; else el.textContent = m + 'm'; } update(); setInterval(update, 60000); }); } _ovInit(); --- ## 2026-Q2 Proposals # 2026-Q2 Proposals Passed Rejected Voting With Funding ## 2026-Q2 Summary 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 2026-Q2 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%) ← Back to all proposals --- ## Gonka Withheld Rewards Redistribution # Gonka Withheld Rewards Redistribution 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. ## TL;DR - Withheld rewards (≈ **3 053 801 GNK**) sit in the gov module account (`gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33`). - These are unpaid earnings that belong to miners, not community-pool funds. - The proposal redistributes them proportionally to each miner's actual rewarded share in each affected epoch. - The computation is fully reproducible from a single Python script and any gonka node. ## Background — How We Got Here 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. ### Upgrade v0.2.9 — Withheld rewards routed to gov 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. ### Upgrade v0.2.11 — Slashed collateral routed to gov v0.2.11 (proposal **#31**, passed 2026-03-20) extended the same policy to slashed collateral. PR [#775](https://github.com/gonka-ai/gonka/pull/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](https://github.com/gonka-ai/gonka/issues/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. ### Earliest evidence of the mechanism 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. ## Why These Are Miner Funds, Not Community Funds 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. - The **community pool** is a separate on-chain account (`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 **gov module account** (this proposal's subject) holds two distinct things: temporary deposits attached to live governance proposals (returned to depositors when voting ends), and the withheld / slashed coins introduced by v0.2.9 and v0.2.11. 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). ## Prior Art — Proposals #32 and #33 Two narrow predecessors already used the gov balance to compensate miners who had documented losses: - **Proposal #32** (passed 2026-03-24): paid 30 538 GNK to compensate participants for lost preserved weights specific to epoch 158, computed individually from a snapshot of historical preserved weight at block 2 443 438. The batch was sent from gov via `MsgBatchTransferWithVesting`. - **Proposal #33** (passed 2026-03-27): paid 27 906 GNK to compensate participants affected by a cPoC bug in epochs 132–133, again via batch vesting from gov, with smaller community-pool payments to proposal authors. Both proposals confirm two things relevant to the present design: 1. The gov balance is a legitimate source for miner compensation (precedent established and ratified by governance). 2. Past compensations were targeted by ad-hoc methodology (per-incident loss models). The present proposal does not retroactively adjust those payouts; it simply redistributes the *current* balance proportionally. 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. ## Algorithm 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. ### Step 1 — Resolve module addresses dynamically 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. ### Step 2 — Discover all blocks where `inference → gov` happened 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='' AND transfer.recipient=''" ``` This yields ~116 blocks for the entire history covered by the proposal — a 5× reduction relative to a naïve `recipient=''` query, with no loss of relevant data. ### Step 3 — Sum the per-block ngonka inflow 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. ### Step 4 — Read real epoch boundaries 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. ### Step 5 — Per-participant rewards 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). ### Step 6 — Map inflow to epoch and aggregate 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. ### Step 7 — Apportionment The total amount to distribute is ``` T = sum(inflow[epoch]) for epoch in 132..247 ``` This 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: 1. Apportion `T` across epochs in proportion to `inflow[epoch]`. The sum of per-epoch budgets equals `T` exactly. 2. For each epoch, apportion that epoch's budget across its participants in proportion to `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. ### Output A single CSV (`payouts.csv` by default): ```csv recipient,ngonka,gnk gonka1...,257001064815774,257001.064815774 gonka1...,255743613433661,255743.613433661 ... ``` Sorted by descending amount. The sum of the `ngonka` column equals `T` exactly. ## Reproducing the Computation ```bash pip install -r requirements.txt python3 taxreturn.py {NODE IP} --out payouts.csv ``` The script accepts either a hostname/IP (default port 8000) or a full URL. A SQLite cache is created in `cache_/` 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. ## Files - `taxreturn.py` — end-to-end computation script. - `requirements.txt` — single dependency (`aiohttp`). - `cache_/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). ## Verification Checklist for Reviewers - [ ] Module addresses resolved from the live chain (`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]). - [ ] Spot-check any individual recipient: their `rewarded_coins` from `epoch_performance_summary` for any epoch matches the reward reflected in their `vest_reward` events on chain. --- ## #46 – Epochs 132-247 compensation payout from gov module (batch vesting) # #46 – Epochs 132-247 compensation payout from gov module (batch vesting) Passed **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`](https://gonka.gg/address/gonka1gmuxdcxlsxn5z72elx77w9zym7yrgfxqgzg6ry){:target="_blank"} **Metadata:** [https://github.com/gonkavip/taxreturn/blob/main/README.md](https://github.com/gonkavip/taxreturn/blob/main/README.md) 3,053,800 GNK · Gov Module [View on gonka.gg](https://gonka.gg/network/proposals/46){:target="_blank"} 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](https://gonka.gg/address/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](https://gonka.gg/address/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 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 247 plus minor pre-132 entries) and is not addressed by this proposal. --- ## Final Tally Yes 97,030 (36.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 172,837 (64.0%) Total 269,867 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.streamvesting.MsgBatchTransferWithVesting` | | 2 | `/inference.streamvesting.MsgBatchTransferWithVesting` | | 3 | `/inference.streamvesting.MsgBatchTransferWithVesting` | | 4 | `/cosmos.bank.v1beta1.MsgMultiSend` | Contract Details ```json [ { "@type": "/inference.streamvesting.MsgBatchTransferWithVesting", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "outputs": [ { "recipient": "gonka17gpuntq09zsaqtmpe544gc32tk4424dwv5t34f", "amount": [ { "denom": "ngonka", "amount": "257001064815774" } ] }, { "recipient": "gonka12av9up884t9lcsf70rs0l7jfmkmc8k9sxfuknt", "amount": [ { "denom": "ngonka", "amount": "255743613433661" } ] }, { "recipient": "gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p", "amount": [ { "denom": "ngonka", "amount": "146181292922666" } ] }, { "recipient": "gonka1vjshzxh3sfam2xh0f7vzz4klrv5pkq4zutk8qt", "amount": [ { "denom": "ngonka", "amount": "133077773396493" } ] }, { "recipient": "gonka1famtxh54kad6ylwtm60j6d7h6unpc08d4vdqnk", "amount": [ { "denom": "ngonka", "amount": "109602184403519" } ] }, { "recipient": "gonka1r34p353cxrvxf3x29raz0x8axflen82a04env4", "amount": [ { "denom": "ngonka", "amount": "91015967243441" } ] }, { "recipient": "gonka1rcpc45n6zch9qlkn4m3cwngekad89xu8mcr09v", "amount": [ { "denom": "ngonka", "amount": "74190426382549" } ] }, { "recipient": "gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2", "amount": [ { "denom": "ngonka", "amount": "67057435920376" } ] }, { "recipient": "gonka155cnj622zfdl64f23ljmk2tzv7tewl6fp4m2hl", "amount": [ { "denom": "ngonka", "amount": "59254989887340" } ] }, { "recipient": "gonka1myu058axjs62mc3e7na9krwvqpfl9z3gtcw9es", "amount": [ { "denom": "ngonka", "amount": "56304331223331" } ] }, { "recipient": "gonka1pvkv59e72vju2h7s9j3ex62c5xneqey350vpwn", "amount": [ { "denom": "ngonka", "amount": "48774245916588" } ] }, { "recipient": "gonka1v425qs8gxupjcw3lqx5fsldtve88vd9gaa7r60", "amount": [ { "denom": "ngonka", "amount": "45239835425126" } ] }, { "recipient": "gonka1umvyh0rz5fdmk9qhxurshhchennajced6f4s89", "amount": [ { "denom": "ngonka", "amount": "45211223884337" } ] }, { "recipient": "gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09", "amount": [ { "denom": "ngonka", "amount": "43574867284019" } ] }, { "recipient": "gonka187tn9y92ur6tu0zf69u94hwl0q77m47y0k36hv", "amount": [ { "denom": "ngonka", "amount": "35326094895179" } ] }, { "recipient": "gonka1llxvtg0657ldmqn4l3t0ag496ff355j5kawagy", "amount": [ { "denom": "ngonka", "amount": "34703179493138" } ] }, { "recipient": "gonka1w6wwv3wq25p8qge4lqsnfzs8lsd3s8ty6au65p", "amount": [ { "denom": "ngonka", "amount": "34463669064904" } ] }, { "recipient": "gonka1jltjehxsnum94nt8c00ts7khmpy4lafv6gryzk", "amount": [ { "denom": "ngonka", "amount": "31922079726022" } ] }, { "recipient": "gonka1q5xt54wncgzk7dxv9x64uln68455g83wu9tugg", "amount": [ { "denom": "ngonka", "amount": "29700347178857" } ] }, { "recipient": "gonka1yq4vwn7fc9x7lykjhc0x3e7r2atee32czy34mt", "amount": [ { "denom": "ngonka", "amount": "29575164563616" } ] }, { "recipient": "gonka1pllyukkeymx3hfd9mts3pryr9y6efs9eshty87", "amount": [ { "denom": "ngonka", "amount": "24858173755208" } ] }, { "recipient": "gonka1zrnrd7zcqnhjytqa8zsg63slxt2g45ctlqy3fm", "amount": [ { "denom": "ngonka", "amount": "23491990914627" } ] }, { "recipient": "gonka1022747hjz6sdfeup0dalcys6hshlqlnnpkdmqk", "amount": [ { "denom": "ngonka", "amount": "23169453291659" } ] }, { "recipient": "gonka1zap7nsccl6x83ucwvq0q6qrefmf9n7ejmj49j3", "amount": [ { "denom": "ngonka", "amount": "23114014245507" } ] }, { "recipient": "gonka1ln28jur0gvuwf8frx63lwwagysdf03e8ldayf3", "amount": [ { "denom": "ngonka", "amount": "20534659528938" } ] }, { "recipient": "gonka1f7d43z2qpcv07huwf3qjj4zpssvx6080a357wh", "amount": [ { "denom": "ngonka", "amount": "20232541892180" } ] }, { "recipient": "gonka19ghzvgfr065s3fr5awuvs3nhy9fq4n7wrr9kel", "amount": [ { "denom": "ngonka", "amount": "19798354315593" } ] }, { "recipient": "gonka1f5fhrywmd5p0jcd5atk4rm2tjxpdn772lw833k", "amount": [ { "denom": "ngonka", "amount": "19460684093418" } ] }, { "recipient": "gonka1w6kt2aj02du25kuc9wsza94h9l7exa0uf64fjq", "amount": [ { "denom": "ngonka", "amount": "18811567809251" } ] }, { "recipient": "gonka12pcu9mcrpa4w4sjd9y3dsksnvu495ss6f9r4ra", "amount": [ { "denom": "ngonka", "amount": "18694274050888" } ] }, { "recipient": "gonka1kzmqu27lhan874pzxr0fy0v7xqyenydh9mp8sj", "amount": [ { "denom": "ngonka", "amount": "18036443683332" } ] }, { "recipient": "gonka1hqwfnnh30scu6lyzhl5alwjqmaeq3vhkcfxkgu", "amount": [ { "denom": "ngonka", "amount": "17681834939234" } ] }, { "recipient": "gonka17rfqamx8vr4zpd6z0jnulre4acht2lj7tq205e", "amount": [ { "denom": "ngonka", "amount": "16531786626167" } ] }, { "recipient": "gonka1uzk2scggfzghr9a5j92l00gzw4jx4adc66977y", "amount": [ { "denom": "ngonka", "amount": "16134062752611" } ] }, { "recipient": "gonka1m9sf2rpg635efaw59djqlxkqew9sxvmqd6g343", "amount": [ { "denom": "ngonka", "amount": "15283991233760" } ] }, { "recipient": "gonka1rdarkrtrfnfcvrnf58jyndccqj0r4k630n38rh", "amount": [ { "denom": "ngonka", "amount": "14730803064393" } ] }, { "recipient": "gonka1ffjt0acf87chys5w93wsrdj2s94rrmcq8mt48l", "amount": [ { "denom": "ngonka", "amount": "14595703339352" } ] }, { "recipient": "gonka15munkmx6x7k6rqqeexjet4556p7at39ks9qgr5", "amount": [ { "denom": "ngonka", "amount": "14474260304851" } ] }, { "recipient": "gonka1cw859nqcd9mg3y3alraluswu55xz9j36evsxd3", "amount": [ { "denom": "ngonka", "amount": "14322176494890" } ] }, { "recipient": "gonka1ag5r7em9qp7dn8nf6jecudhu38amu3nwtqv3cg", "amount": [ { "denom": "ngonka", "amount": "13573694792548" } ] }, { "recipient": "gonka14ued4vcdeluj9v9vmsmteap7vtg7t50640hvmf", "amount": [ { "denom": "ngonka", "amount": "13242399993440" } ] }, { "recipient": "gonka1jv4fcx2gtuj4ejwnng4phugfclgjmhvg9d9cvz", "amount": [ { "denom": "ngonka", "amount": "13080046839379" } ] }, { "recipient": "gonka1fkrsesmn2hdj30fhwyam6h4f2e77un36xalhvl", "amount": [ { "denom": "ngonka", "amount": "12497662398412" } ] }, { "recipient": "gonka1lrls7q8nu8rhjgchctswfsjlnjh84vwycw3jgt", "amount": [ { "denom": "ngonka", "amount": "12126284267879" } ] }, { "recipient": "gonka188c86f9mrlt4nlcg89f82nnfm9jzq9gtjafj50", "amount": [ { "denom": "ngonka", "amount": "11969739290348" } ] }, { "recipient": "gonka1apnzzz6wlpevze3vzsmk7n0vp6az5609magdf6", "amount": [ { "denom": "ngonka", "amount": "11932993515432" } ] }, { "recipient": "gonka13pacjyw9quwfvzllp2h7u27h6f5khqlftw3jmk", "amount": [ { "denom": "ngonka", "amount": "11908860089941" } ] }, { "recipient": "gonka109g8dnt43nj45xhg83jyjt5f2ywz336w36qzyl", "amount": [ { "denom": "ngonka", "amount": "11857109690479" } ] }, { "recipient": "gonka1ea4hhgnahtu4g0zzpmz2p8elcyx7x99hamk0x4", "amount": [ { "denom": "ngonka", "amount": "11834634316463" } ] }, { "recipient": "gonka1dms4wtzer5zjx32c3grc5twksd8kdp0ut952g7", "amount": [ { "denom": "ngonka", "amount": "11804999068025" } ] }, { "recipient": "gonka1tja3g2da45efhe2p83gk3whtussmgmtsdlgprt", "amount": [ { "denom": "ngonka", "amount": "11775889822160" } ] }, { "recipient": "gonka1caju8tg6yg3wkvryhks57jwd8des6ssypfrhhj", "amount": [ { "denom": "ngonka", "amount": "11755346548282" } ] }, { "recipient": "gonka1vkafyzr5yz5aht6gzapw6lc52h5wwmnrjwvqlz", "amount": [ { "denom": "ngonka", "amount": "11717956702716" } ] }, { "recipient": "gonka1yn54kaefrf7sjk66c74gqap0mquzjqvthsyhwe", "amount": [ { "denom": "ngonka", "amount": "11673458189519" } ] }, { "recipient": "gonka1h3s37p0l23mg6ak9h9nmayh6r9f2vm6umj3qet", "amount": [ { "denom": "ngonka", "amount": "11513343140557" } ] }, { "recipient": "gonka167mtkjz3c7k4mnv77zgneul4eakz35qqysgj2l", "amount": [ { "denom": "ngonka", "amount": "11305089109736" } ] }, { "recipient": "gonka1wr20kvjrm6y6cvqk7jt2e5gpyl45qq3mvt7sr4", "amount": [ { "denom": "ngonka", "amount": "11078446910205" } ] }, { "recipient": "gonka1m08n5646hjpavvmjfarad9kr9pxufe7sfy3v7e", "amount": [ { "denom": "ngonka", "amount": "11016071211074" } ] }, { "recipient": "gonka16sthutkxgr88vlkgvqak2h7pdt76fcznfz6w43", "amount": [ { "denom": "ngonka", "amount": "10921214768840" } ] }, { "recipient": "gonka1wthc28t25pg63hzvl07rl8e8r6km6hesl6jhsz", "amount": [ { "denom": "ngonka", "amount": "10711052597420" } ] }, { "recipient": "gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu", "amount": [ { "denom": "ngonka", "amount": "10356524697948" } ] }, { "recipient": "gonka1zktn8j65wlys8a8e38hqhf4y3x6m4x04zskkrx", "amount": [ { "denom": "ngonka", "amount": "9988586022231" } ] }, { "recipient": "gonka10etnufq85u67k075yuxq6h3rzwlcln5rffhlyx", "amount": [ { "denom": "ngonka", "amount": "9921527771819" } ] }, { "recipient": "gonka1zauv3up2rp4al5lhsqnqfh2kqfx2zvy3l0qwss", "amount": [ { "denom": "ngonka", "amount": "9155922064919" } ] }, { "recipient": "gonka1apw5tzk6a3l9hdpdx5q9v2leehvz5rvvw44x8s", "amount": [ { "denom": "ngonka", "amount": "8903896410063" } ] }, { "recipient": "gonka14ljarev2nlzu4ej50vx7ylj2rvg4n20fnq2ysc", "amount": [ { "denom": "ngonka", "amount": "8669865143449" } ] }, { "recipient": "gonka12mqkaycdsc7qr37ey5rqw6vhjvkk7waxdc7rjh", "amount": [ { "denom": "ngonka", "amount": "8536705102147" } ] }, { "recipient": "gonka1z3kelh3gx3t6kz303f8trdll3j5ap3zz8csyfm", "amount": [ { "denom": "ngonka", "amount": "8325426582463" } ] }, { "recipient": "gonka1756ph2flj5y6kw5xqktfgwj3s2ct54ddz0jj0e", "amount": [ { "denom": "ngonka", "amount": "7783596922366" } ] }, { "recipient": "gonka1aazyzjuywye4530acgjgw0stu4ydpt9hv4afut", "amount": [ { "denom": "ngonka", "amount": "7472635175272" } ] }, { "recipient": "gonka1vdw6tst3lelc84garssnnjzx7fjpkja2wzpxe8", "amount": [ { "denom": "ngonka", "amount": "7257439323925" } ] }, { "recipient": "gonka10vljxvwy6n9hh263chkt0hj0kg7t0qmdwfrurs", "amount": [ { "denom": "ngonka", "amount": "7126663727384" } ] }, { "recipient": "gonka1y95qr73kms3zv5ju0kxtu58ksxdyrkyz8m0430", "amount": [ { "denom": "ngonka", "amount": "7004483068232" } ] }, { "recipient": "gonka1shc0ywxd993zz3w3h5xdp5uhgu9rv27ws7mmqx", "amount": [ { "denom": "ngonka", "amount": "6835043483003" } ] }, { "recipient": "gonka1hszud9tlfe7qs2elkjmmkavk5yhrdned587frx", "amount": [ { "denom": "ngonka", "amount": "6775865712894" } ] }, { "recipient": "gonka1p2959dx973hd57qsalxvesrcv649296x90ry76", "amount": [ { "denom": "ngonka", "amount": "6713217861349" } ] }, { "recipient": "gonka1rxprdtkfpkszyx3zvyerzk0z52uqpn85wpfvdj", "amount": [ { "denom": "ngonka", "amount": "6510598709806" } ] }, { "recipient": "gonka16p322ch887xjv67erm5dw0lgt4kqj9gz498pv7", "amount": [ { "denom": "ngonka", "amount": "6442327838961" } ] }, { "recipient": "gonka1ad7al35f74hdlwl5vzmqla4gg3zlajthqsyeva", "amount": [ { "denom": "ngonka", "amount": "6326560493160" } ] }, { "recipient": "gonka1kyl5le4t0k9dftmu5lj0xqp0dx52dyvn0rtr8y", "amount": [ { "denom": "ngonka", "amount": "6235376338191" } ] }, { "recipient": "gonka100k8hr43z5vp0fnyc94m7lum6mj4st6vksxz8s", "amount": [ { "denom": "ngonka", "amount": "5805465594251" } ] }, { "recipient": "gonka12gwxa8vcvahyd4ygcxp4624ywaw98wp953wuva", "amount": [ { "denom": "ngonka", "amount": "5785980666618" } ] }, { "recipient": "gonka1fyghf5n3uk7dtl529mxk6389vryd4xvnh93825", "amount": [ { "denom": "ngonka", "amount": "5740322096699" } ] }, { "recipient": "gonka1lr9mj6dgkv0h76c8y8w0l3esztyg9v2q8d6d8d", "amount": [ { "denom": "ngonka", "amount": "5649008951922" } ] }, { "recipient": "gonka1v6gqe8zaqqmlevnmpxa6chjy9mt422mac2lhwc", "amount": [ { "denom": "ngonka", "amount": "5626416345685" } ] }, { "recipient": "gonka19xadn767xykcg4j5jl6nxk55dsdr2muu9r3fhy", "amount": [ { "denom": "ngonka", "amount": "5420417253933" } ] }, { "recipient": "gonka1hwvel7n3zuk6wruefuzc356l9myske9stckwnz", "amount": [ { "denom": "ngonka", "amount": "5233882003557" } ] }, { "recipient": "gonka1z7h4mzz5kkcydj4l6lzr9j73x49dlcq84mmkrv", "amount": [ { "denom": "ngonka", "amount": "5225544478337" } ] }, { "recipient": "gonka1z8dh5kqdn2nnsg527qawy58ca5fme38xffq7ah", "amount": [ { "denom": "ngonka", "amount": "5150029035155" } ] }, { "recipient": "gonka1lh0danzlvxm5qtaly7myqd3n5sus0fq92n8shx", "amount": [ { "denom": "ngonka", "amount": "5146315546795" } ] }, { "recipient": "gonka1vcvn2p5gczr5pynqq0ca0933tdrf5w64sjgtdg", "amount": [ { "denom": "ngonka", "amount": "4919938488061" } ] }, { "recipient": "gonka14tqh62mangwzrma2lgg2dm375rcjzn2ydy8ttm", "amount": [ { "denom": "ngonka", "amount": "4894031265459" } ] }, { "recipient": "gonka1fc9tzt83dgrqswlgay4668cuqjrk7zsqks2vm2", "amount": [ { "denom": "ngonka", "amount": "4879946653867" } ] }, { "recipient": "gonka168yvlgt9jg86frg2z90cc8w4pz9hnd7f8lshux", "amount": [ { "denom": "ngonka", "amount": "4828093037828" } ] }, { "recipient": "gonka15kf06ehfplnqtvgnndyfym9w9f63686cvw3nqj", "amount": [ { "denom": "ngonka", "amount": "4809487452462" } ] }, { "recipient": "gonka18v2az8fn2z28ykxu7zyc09crqdmjuldmnag0g2", "amount": [ { "denom": "ngonka", "amount": "4766372692428" } ] }, { "recipient": "gonka12s5q7gzej93ty6ydqrr4ugwrt26zcwtggamz0k", "amount": [ { "denom": "ngonka", "amount": "4615281886684" } ] }, { "recipient": "gonka14cu38xpsd8pz5zdkkzwf0jwtpc0vv309ake364", "amount": [ { "denom": "ngonka", "amount": "4508685844396" } ] }, { "recipient": "gonka1jrkf560tvgqw3f9z4axs9da34lgnrd396e3rs0", "amount": [ { "denom": "ngonka", "amount": "4504841695639" } ] }, { "recipient": "gonka10vh6xfdrksy7npapnhs6pnwmd3ldpxgl8n2gdd", "amount": [ { "denom": "ngonka", "amount": "4499200011386" } ] }, { "recipient": "gonka19pve9p3eth8j7ssv7k4f57lljrtjtl6mjgnuxq", "amount": [ { "denom": "ngonka", "amount": "4394936385598" } ] }, { "recipient": "gonka17t9elrdnnzqd5q2w240ue47tn253gjuhpkflwx", "amount": [ { "denom": "ngonka", "amount": "4374758888276" } ] }, { "recipient": "gonka1u4zxypjgcr8khlzefwjr0vwdaj2uzruw2cehj3", "amount": [ { "denom": "ngonka", "amount": "4258606767870" } ] }, { "recipient": "gonka1u4gtnwh0hvzlyvran3l7my7hr883ej367ed80r", "amount": [ { "denom": "ngonka", "amount": "4251488209351" } ] }, { "recipient": "gonka1ux86q8cgnpvkal497xag8p04ds2u2v23qxawv6", "amount": [ { "denom": "ngonka", "amount": "4240884907658" } ] }, { "recipient": "gonka1r288zwzcvw87qeyk7tdwe29nux2s4wxzustuk8", "amount": [ { "denom": "ngonka", "amount": "4232778601728" } ] }, { "recipient": "gonka13rcy8ytzdfyfz8jx5l3ru0l093k7mp5e9waanq", "amount": [ { "denom": "ngonka", "amount": "4199542856791" } ] }, { "recipient": "gonka19dh0tamdjnhtccfdpmsnty3gxfpp0wkdusl0xr", "amount": [ { "denom": "ngonka", "amount": "4118725388207" } ] }, { "recipient": "gonka1t8x0m85qvyfzvyevwrj2m28ytf6w3kmlf5r7ez", "amount": [ { "denom": "ngonka", "amount": "4080444259026" } ] }, { "recipient": "gonka1wvv656pt2d8x2khcvytqeessck5uzjnxzsa8f6", "amount": [ { "denom": "ngonka", "amount": "4004509906206" } ] }, { "recipient": "gonka18hns0dspklh6r89nyeg8qaph4vhfkd63tl7a37", "amount": [ { "denom": "ngonka", "amount": "3987721650077" } ] }, { "recipient": "gonka17ef5hl0588tmjm9ypw7t2kge78wrkcpvyspc0p", "amount": [ { "denom": "ngonka", "amount": "3672928729539" } ] }, { "recipient": "gonka19s3wpdecq3znh7gflv5xax06p96s2uv3qdrtup", "amount": [ { "denom": "ngonka", "amount": "3669248888230" } ] }, { "recipient": "gonka1aun6f73uq2r5fujk38xe0tww980r6a0lz6a45g", "amount": [ { "denom": "ngonka", "amount": "3621234292444" } ] }, { "recipient": "gonka1ltv80h8740pc8u4jj7fqwvt8d4rnw3nkc4shaa", "amount": [ { "denom": "ngonka", "amount": "3457371816527" } ] }, { "recipient": "gonka1zpw8tml8xl4fm6zm8zpf2u4pq4tehmd9e2vgq7", "amount": [ { "denom": "ngonka", "amount": "3362231861628" } ] }, { "recipient": "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "amount": [ { "denom": "ngonka", "amount": "3285555682598" } ] }, { "recipient": "gonka1yd8s6z8enw080kj2wgynuwdxzx40gttchqe4za", "amount": [ { "denom": "ngonka", "amount": "3258863349046" } ] }, { "recipient": "gonka1vwsp87trl60t4g67fa677k7d7jztuc3g4qjc3w", "amount": [ { "denom": "ngonka", "amount": "3221665521411" } ] }, { "recipient": "gonka1r5hdy9q5v783ef7td98k4c68cxl6a58h5sytfq", "amount": [ { "denom": "ngonka", "amount": "3220639632240" } ] }, { "recipient": "gonka1ujnc662v6g69jm6fgxnr79a2m7ehzeut059239", "amount": [ { "denom": "ngonka", "amount": "3211234640565" } ] }, { "recipient": "gonka15suq3puxz0ec7fnyurwf47qn8jqs8trhyw0uau", "amount": [ { "denom": "ngonka", "amount": "3149836763605" } ] }, { "recipient": "gonka19dqylqjzp4x04mkktz067l4exrcrg8g7777777", "amount": [ { "denom": "ngonka", "amount": "3133323012338" } ] }, { "recipient": "gonka1k7qdnu46x2uyta6fuja3jsmr2cw7ta38krfhfv", "amount": [ { "denom": "ngonka", "amount": "3065588470988" } ] }, { "recipient": "gonka1amlmhjym02shahjv8ldmupg4cx0qc66q6f85rj", "amount": [ { "denom": "ngonka", "amount": "3017095901974" } ] }, { "recipient": "gonka1svynlfqqsxzuxfm67lgy986438h6l2u8tz4clj", "amount": [ { "denom": "ngonka", "amount": "3012757568456" } ] }, { "recipient": "gonka1zpm8qujddac84y7wfh7h3p85ys336n9zjqckzl", "amount": [ { "denom": "ngonka", "amount": "2999175542710" } ] }, { "recipient": "gonka172esz53695ykvv038y8mvdfc6mkk2q0dgfmjks", "amount": [ { "denom": "ngonka", "amount": "2941665532530" } ] }, { "recipient": "gonka1zsvl7ujlc8z3a35v2q6e3nml7ftyk23v76jqgl", "amount": [ { "denom": "ngonka", "amount": "2926379308218" } ] }, { "recipient": "gonka1czmu5smv804kq6pqtyvmjxcjjj720mgl4xc3hd", "amount": [ { "denom": "ngonka", "amount": "2797625789804" } ] }, { "recipient": "gonka1f37ltf3h2fcytmxf5svyc4w88k5wzsammgyk69", "amount": [ { "denom": "ngonka", "amount": "2785737330882" } ] }, { "recipient": "gonka14c0vannxsak0qq4lpmr5qkn40gcfmcvnyu4z2r", "amount": [ { "denom": "ngonka", "amount": "2765024397341" } ] }, { "recipient": "gonka157lvhw8ay84qf6xs6rhvud7hjpnsp5zdcqg0s5", "amount": [ { "denom": "ngonka", "amount": "2739159995711" } ] }, { "recipient": "gonka1yewc6rmr5zhcpy6dnpt4wup990j299qt03x40s", "amount": [ { "denom": "ngonka", "amount": "2614646090348" } ] }, { "recipient": "gonka1nzjz6svr80uqt49r6u409rsq3skd7fqdmz0lks", "amount": [ { "denom": "ngonka", "amount": "2597919588432" } ] }, { "recipient": "gonka1zqqrnrlnam5knwvpmxvlpj4za04t62pxzh65y4", "amount": [ { "denom": "ngonka", "amount": "2594962821488" } ] }, { "recipient": "gonka1zvpy47fagx96g8zzhwwxu9yztke82cqvwearsg", "amount": [ { "denom": "ngonka", "amount": "2593764205535" } ] }, { "recipient": "gonka1g3xpka5ynkdgspd2r2atma4vzlklrz0kssez0d", "amount": [ { "denom": "ngonka", "amount": "2586979530168" } ] }, { "recipient": "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "amount": [ { "denom": "ngonka", "amount": "2579411768290" } ] }, { "recipient": "gonka18nzvzzync0v9q73ka2jsh05ptmhda73t8g6gzl", "amount": [ { "denom": "ngonka", "amount": "2554062642627" } ] }, { "recipient": "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "amount": [ { "denom": "ngonka", "amount": "2526605346157" } ] }, { "recipient": "gonka16q0zaetd6hq6d8zj48ur0v967xrrwh566kcazc", "amount": [ { "denom": "ngonka", "amount": "2525839052072" } ] }, { "recipient": "gonka1mwwzgd5qztcjddg2pwej0xw8xywqr5l4san6ee", "amount": [ { "denom": "ngonka", "amount": "2516239230812" } ] }, { "recipient": "gonka1p2hqmt2lxgw5ctdlt6valanxxqsmtf73g27mpg", "amount": [ { "denom": "ngonka", "amount": "2487864393256" } ] }, { "recipient": "gonka1m27e6qup7q8jmvnrn29kahd7vlx6r4l84z4thz", "amount": [ { "denom": "ngonka", "amount": "2475577450540" } ] }, { "recipient": "gonka1wj0jmwtwjk0g05tuugh9t028nxl92qrn7e8ajy", "amount": [ { "denom": "ngonka", "amount": "2448108786799" } ] }, { "recipient": "gonka1a3urcggdzkamu76nd847034z7w6kx2en46jzan", "amount": [ { "denom": "ngonka", "amount": "2438132794092" } ] }, { "recipient": "gonka1snq79gf7l5kjm00gkdcu9dmpwzk207eq07nuue", "amount": [ { "denom": "ngonka", "amount": "2431479512542" } ] }, { "recipient": "gonka17wmjdfda8tfkfujp24usqzsxv32vrycnhvj3cl", "amount": [ { "denom": "ngonka", "amount": "2410047815267" } ] }, { "recipient": "gonka1uawu7tlxcuss8xk9m63fpjm86y58chsg5xwsjt", "amount": [ { "denom": "ngonka", "amount": "2307961462204" } ] }, { "recipient": "gonka10yvlwvt2t3eqrze399ky2wtqfr507zld06wn9m", "amount": [ { "denom": "ngonka", "amount": "2291889908713" } ] }, { "recipient": "gonka1vn8dkrcwmqet2954u7zxt6e3q4q5p87zf4ug8m", "amount": [ { "denom": "ngonka", "amount": "2274332708925" } ] }, { "recipient": "gonka1wtg6f6xstldpe4ty2khcf4h7ggkwhyez3f5xn9", "amount": [ { "denom": "ngonka", "amount": "2211681613298" } ] }, { "recipient": "gonka1zr82xvxge0n8hf2u9ysrvfgr8u5lcvrqwc6ufx", "amount": [ { "denom": "ngonka", "amount": "2184531466278" } ] }, { "recipient": "gonka1zyh5wtm75k9hnwyavx9uhserp9hf7mnw7m8tzk", "amount": [ { "denom": "ngonka", "amount": "2180450032879" } ] }, { "recipient": "gonka12nwehnhahquy97ulu8824pnw9p0fszxzpnexk7", "amount": [ { "denom": "ngonka", "amount": "2164973775818" } ] }, { "recipient": "gonka134gw5wnwukm032r3xn4fe73ptrfqewjwnj42q9", "amount": [ { "denom": "ngonka", "amount": "2122972978099" } ] }, { "recipient": "gonka1nwkzwsy9msnvw6dvx7dwyvqgpzrll5th3qjnqx", "amount": [ { "denom": "ngonka", "amount": "2114472670926" } ] }, { "recipient": "gonka1vvnnc0aw2v8j8zarm7p0egfgajpmus23sm8gd5", "amount": [ { "denom": "ngonka", "amount": "2113698536568" } ] }, { "recipient": "gonka18gjl3tetpx0qdknl0vdhhducfycggpjrrjy6me", "amount": [ { "denom": "ngonka", "amount": "2112266881636" } ] }, { "recipient": "gonka1tlvg4kjx7ljd5thgd5fkgh39q6lu8cmxupktgg", "amount": [ { "denom": "ngonka", "amount": "2097917153622" } ] }, { "recipient": "gonka15x0egllrr3wlucagztrpf7u8365zdjjy3qh8aa", "amount": [ { "denom": "ngonka", "amount": "2095430372995" } ] }, { "recipient": "gonka1vy396smh98ak3ts4zlthjnsv2ypr845mrfz7x5", "amount": [ { "denom": "ngonka", "amount": "2094173145999" } ] }, { "recipient": "gonka1dg6s2c2mrwg972xs7309nh57t7q98hqv99jew8", "amount": [ { "denom": "ngonka", "amount": "2087135335497" } ] }, { "recipient": "gonka1zx097psrq9p99yz8src4henyrtsdpjv3n7hp5u", "amount": [ { "denom": "ngonka", "amount": "2071309702684" } ] }, { "recipient": "gonka1lv34hh600uye40wjjq9fspqwernyjqjuz92w8f", "amount": [ { "denom": "ngonka", "amount": "2063313281497" } ] }, { "recipient": "gonka1tx980hp394dfn80rut6gr3j5yujz7wdl08dups", "amount": [ { "denom": "ngonka", "amount": "2050662840697" } ] }, { "recipient": "gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np", "amount": [ { "denom": "ngonka", "amount": "2047604055909" } ] }, { "recipient": "gonka1ymupls5cj6dfkvppeetcfpkszqxmyyrjtsn5pz", "amount": [ { "denom": "ngonka", "amount": "2046231858543" } ] }, { "recipient": "gonka1hytku6t3cfd7wppyrjvu357jjqpsgsw6wcprcy", "amount": [ { "denom": "ngonka", "amount": "2034728655450" } ] }, { "recipient": "gonka1k3xh9h66ye5pdgv2v94xhf7paz445e7qwraz7h", "amount": [ { "denom": "ngonka", "amount": "2025139415576" } ] }, { "recipient": "gonka1nkedq5vefl0xlxf66cgpx5l6eldtjtr3e2q5sp", "amount": [ { "denom": "ngonka", "amount": "2014461604344" } ] }, { "recipient": "gonka1a3f2cpds29pq0x7yvuh5we233l6aytcgl8gtlx", "amount": [ { "denom": "ngonka", "amount": "1999560523360" } ] }, { "recipient": "gonka17v3mupkkl6gapd2nfe8n442npj0vm8tezv53rx", "amount": [ { "denom": "ngonka", "amount": "1988287022886" } ] }, { "recipient": "gonka1eazh84v0e60s9m7exxp3nsadcfgvnsthgypjvl", "amount": [ { "denom": "ngonka", "amount": "1981994552976" } ] }, { "recipient": "gonka14pdvgt025fwkf38cr74hhcj2nfl98c044tswya", "amount": [ { "denom": "ngonka", "amount": "1978853219827" } ] }, { "recipient": "gonka1l4vfzkwd555pvxqzr3ksphgwgv8xsh89ytmjp0", "amount": [ { "denom": "ngonka", "amount": "1974075810606" } ] }, { "recipient": "gonka1x5fvtepacy4gk0nsjenj0fgs46jmhs22an4zyg", "amount": [ { "denom": "ngonka", "amount": "1950427976353" } ] }, { "recipient": "gonka1d7p03cu2y2yt3vytq9wlfm6tlz0lfhlgv9h82p", "amount": [ { "denom": "ngonka", "amount": "1950216716356" } ] }, { "recipient": "gonka1kwflqwdrvk6ax62er4tkdwmjayh3eq80ketq2u", "amount": [ { "denom": "ngonka", "amount": "1936371393787" } ] }, { "recipient": "gonka1kk9m3h8y5qg2qt50m4htdczlmu9nuvgssa7wvx", "amount": [ { "denom": "ngonka", "amount": "1930810890692" } ] }, { "recipient": "gonka18zc66p9kmjxe43zfm0ckmzds2aey7nd7lz7tju", "amount": [ { "denom": "ngonka", "amount": "1911831420473" } ] }, { "recipient": "gonka1llgg3kvg9sc6xz09jtkcrucrppxgn78xe4xlv0", "amount": [ { "denom": "ngonka", "amount": "1909204747983" } ] }, { "recipient": "gonka1sszyf9vva7xvyk84fnc7zwk0gde3avrhstp8yq", "amount": [ { "denom": "ngonka", "amount": "1898302802394" } ] }, { "recipient": "gonka1ntsw9ufhpvzan82lhe496zhdqvfy9rptm6rr5s", "amount": [ { "denom": "ngonka", "amount": "1882174535198" } ] }, { "recipient": "gonka1hr7tssnwuw7jk8s4gjf8uq6k9aw2evnygsfd5y", "amount": [ { "denom": "ngonka", "amount": "1881610689490" } ] }, { "recipient": "gonka1py4j23jhz2nah9d8lqpxn2lq6e07lx6e6jmaym", "amount": [ { "denom": "ngonka", "amount": "1869327972267" } ] }, { "recipient": "gonka1y29s2ckdl0csktxhpx77a7dvwyhj9u4xyrcynm", "amount": [ { "denom": "ngonka", "amount": "1868663974330" } ] }, { "recipient": "gonka13yg0vc937qfnhc0lr7c57cr63edl5jxh6g6sds", "amount": [ { "denom": "ngonka", "amount": "1856520150195" } ] }, { "recipient": "gonka1nrutssh27xyjxa2a3x7xqs5j72uwfcfhkux0lq", "amount": [ { "denom": "ngonka", "amount": "1852033816609" } ] }, { "recipient": "gonka1mrjfnu5n4cpz0kc6ctkj7m6wyydgjstje8yyg2", "amount": [ { "denom": "ngonka", "amount": "1832711080363" } ] }, { "recipient": "gonka16gmle2g7g0n654xpq5sq6p4kakwhyglzwzj84x", "amount": [ { "denom": "ngonka", "amount": "1823343472413" } ] }, { "recipient": "gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e", "amount": [ { "denom": "ngonka", "amount": "1809157685416" } ] }, { "recipient": "gonka1z4ldfav9tl7x3w9aqfry89zd0kt7sa2lhff6te", "amount": [ { "denom": "ngonka", "amount": "1793236353527" } ] }, { "recipient": "gonka100yl7qvcpdrt834zay8wusptg8g6yrv4p7fh4w", "amount": [ { "denom": "ngonka", "amount": "1772948015912" } ] }, { "recipient": "gonka15uz4vcp4r0yrn3wy6lw7kslcv75l04cmy5vfac", "amount": [ { "denom": "ngonka", "amount": "1766341236334" } ] }, { "recipient": "gonka16k03ze5ynkprsd4n6e5uzhthvu9jjk553rauqy", "amount": [ { "denom": "ngonka", "amount": "1763176140135" } ] }, { "recipient": "gonka14a0856a3q78pmesxpc946xm9nsj3f275l9f5pa", "amount": [ { "denom": "ngonka", "amount": "1762281983678" } ] }, { "recipient": "gonka1t8p0tjqls358gmzvd3rnnjulraq2k3m772vnt8", "amount": [ { "denom": "ngonka", "amount": "1760449387496" } ] }, { "recipient": "gonka10dmnjuj9pyxk8zcyhykccr2pte2e8sj93e2ljp", "amount": [ { "denom": "ngonka", "amount": "1743800721431" } ] }, { "recipient": "gonka1qwfrtz9c7kcrfkrrlne2pkcye74mj6ce33xdkl", "amount": [ { "denom": "ngonka", "amount": "1730972390651" } ] }, { "recipient": "gonka1p2lhgng7tcqju7emk989s5fpdr7k2c3ek6h26m", "amount": [ { "denom": "ngonka", "amount": "1729511203691" } ] }, { "recipient": "gonka1uqdg47fc37pxn0px59mgs6jaxzyu5axjsunqcn", "amount": [ { "denom": "ngonka", "amount": "1722700206424" } ] }, { "recipient": "gonka145666cll76ptcyy9ceymtalr8gnvv73ne99p32", "amount": [ { "denom": "ngonka", "amount": "1721387071686" } ] }, { "recipient": "gonka1slndy4rsmld579628302rj5gz8z9qf4v6ppmc4", "amount": [ { "denom": "ngonka", "amount": "1720964413511" } ] }, { "recipient": "gonka1k3lva2jsxu5qx30f65yxdlcey8d6f3unmy2gks", "amount": [ { "denom": "ngonka", "amount": "1714912277605" } ] }, { "recipient": "gonka1lq2qtfapw52lkqnwkadr9a7yyhzllz32hhg75l", "amount": [ { "denom": "ngonka", "amount": "1712950116810" } ] }, { "recipient": "gonka1qraf3edrgj8j0jmm9p709p8jver4kfa5qm2dlw", "amount": [ { "denom": "ngonka", "amount": "1712937593153" } ] }, { "recipient": "gonka1dpt9zx2dqcky6yjjwrd8xz2w7lq6vffy9mhvgs", "amount": [ { "denom": "ngonka", "amount": "1710228510544" } ] }, { "recipient": "gonka1l44nacmpmt83kavvevmhlh8elspjtjn6wvwzm0", "amount": [ { "denom": "ngonka", "amount": "1705987345103" } ] }, { "recipient": "gonka1st0kn8x2slqc4ruphzwcsqux8fz4y9fxkgny2p", "amount": [ { "denom": "ngonka", "amount": "1703111172537" } ] }, { "recipient": "gonka1sa32xmpxvv7nepfc22004rgdl4ddjvne42guce", "amount": [ { "denom": "ngonka", "amount": "1701186828287" } ] }, { "recipient": "gonka1y2gqpy8533d23dyuwsx67snesddu2w6pf4la73", "amount": [ { "denom": "ngonka", "amount": "1679548662497" } ] }, { "recipient": "gonka1d0cekvf368psxff6ur7pl42vvs225rzu9a76nj", "amount": [ { "denom": "ngonka", "amount": "1676087196251" } ] }, { "recipient": "gonka1ju7jfznld7vg0f35wgz507m6c0lzgugpmajnvn", "amount": [ { "denom": "ngonka", "amount": "1657983373908" } ] }, { "recipient": "gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0", "amount": [ { "denom": "ngonka", "amount": "1649092472277" } ] }, { "recipient": "gonka1x0tmf77y7pgwjz3pmjtdphr6gr264fsya0ck97", "amount": [ { "denom": "ngonka", "amount": "1644308356211" } ] }, { "recipient": "gonka1ge9amk4ymld27d35akj3ky9uph4gyz6rdpepjj", "amount": [ { "denom": "ngonka", "amount": "1640782235179" } ] }, { "recipient": "gonka18vjpx0ju0su0t89y3gjvktsx9cak579a8tvzlv", "amount": [ { "denom": "ngonka", "amount": "1640531529430" } ] }, { "recipient": "gonka197mvutfxtz0kfuttd8pedys2qscffqatzf7cks", "amount": [ { "denom": "ngonka", "amount": "1635594374059" } ] }, { "recipient": "gonka1p2hcr8q3zst98rnw5t2ek7ah04xc7avjyqsykx", "amount": [ { "denom": "ngonka", "amount": "1635540874840" } ] }, { "recipient": "gonka1jnvpyydsxvqx484qua8nj6sm8gw7zq0jrv5qch", "amount": [ { "denom": "ngonka", "amount": "1624531548601" } ] }, { "recipient": "gonka17pnpw8uphnvsehcdpsxuar5nctlksvftlpvfcm", "amount": [ { "denom": "ngonka", "amount": "1612758520040" } ] }, { "recipient": "gonka1pxnftcgh4cf20326zvqxu7d8zmwrpfn07qmpn8", "amount": [ { "denom": "ngonka", "amount": "1610736048493" } ] }, { "recipient": "gonka1s5vtmnn8tqvqfh7gd9hv48kkt2t4mkh7s85zh6", "amount": [ { "denom": "ngonka", "amount": "1600385389897" } ] }, { "recipient": "gonka1nkmwp905ka4dzvuwvdaudgjj7yjk8h5aslfw73", "amount": [ { "denom": "ngonka", "amount": "1587901780412" } ] }, { "recipient": "gonka1450wvd5uugfj7gru4heut5ulnneunplvxs995e", "amount": [ { "denom": "ngonka", "amount": "1585492932064" } ] }, { "recipient": "gonka178p3vw9zxs885l4a29g3sep0v9uplfq4pzvmrq", "amount": [ { "denom": "ngonka", "amount": "1568245761958" } ] }, { "recipient": "gonka19cjm4c5mt3j3qdr8vhytmm4hef3pnkvkm0x7m2", "amount": [ { "denom": "ngonka", "amount": "1550424742012" } ] }, { "recipient": "gonka18gx37lvw563n8h27zg4r86hpxyhfkrnc9v8gsx", "amount": [ { "denom": "ngonka", "amount": "1545986812272" } ] }, { "recipient": "gonka1rcxn206a5smzzhd3g0edgg6tyv97jk052nc9fx", "amount": [ { "denom": "ngonka", "amount": "1543746149423" } ] }, { "recipient": "gonka15ye48c3rp57hwt9t6tzc6h0t5sh88zvj0yznwn", "amount": [ { "denom": "ngonka", "amount": "1542148067169" } ] }, { "recipient": "gonka1czjrfgs9xfuax25j8nsjrdklzn6repcn25zjxd", "amount": [ { "denom": "ngonka", "amount": "1533880283950" } ] }, { "recipient": "gonka14s76f83l8m3guvr8vu54dmla798jzy3u09vxzx", "amount": [ { "denom": "ngonka", "amount": "1532015935333" } ] }, { "recipient": "gonka1sgpe9jdpa407ykm537demqj26xn7x88ayjdzly", "amount": [ { "denom": "ngonka", "amount": "1529218270093" } ] }, { "recipient": "gonka1gstreuc0fz4gksar9sx2uzg4au2k7k83cremld", "amount": [ { "denom": "ngonka", "amount": "1503708999515" } ] }, { "recipient": "gonka1xkk2g9t0t7euahr5wtjerv7tng3pnrcl0h3gcz", "amount": [ { "denom": "ngonka", "amount": "1496033993846" } ] }, { "recipient": "gonka1m3vrwz0e6wmclfl3kmwvqq4j7pl65nmvhuz0le", "amount": [ { "denom": "ngonka", "amount": "1493192656255" } ] }, { "recipient": "gonka1nrf23a58fa0t0haq584272lsw2tfkm553l04a0", "amount": [ { "denom": "ngonka", "amount": "1467443775463" } ] }, { "recipient": "gonka1x3wd5ypslj50nk9cvs72e3re9mfcdpcqwhnulj", "amount": [ { "denom": "ngonka", "amount": "1467176555799" } ] }, { "recipient": "gonka14vyhz7henu2lxssa02lf3qwmufv8kvxzn85frf", "amount": [ { "denom": "ngonka", "amount": "1434213603092" } ] }, { "recipient": "gonka188qynuf5zs5966vzlrf2q2tj7h7laa995vrxr3", "amount": [ { "denom": "ngonka", "amount": "1432954903593" } ] }, { "recipient": "gonka1dx3kzqghjsfr4scjvmy0lvk4lk7qhvh9n358k2", "amount": [ { "denom": "ngonka", "amount": "1429796170034" } ] }, { "recipient": "gonka1juwk05glldgn7850a3547jsl7l4vrhx9k5g3cr", "amount": [ { "denom": "ngonka", "amount": "1423107302701" } ] }, { "recipient": "gonka1ccdm8j6sjyhq4qask049dwgaczs7f3pxte6zmp", "amount": [ { "denom": "ngonka", "amount": "1421622489933" } ] }, { "recipient": "gonka1q4mexpvre73dwjaz93xuwwxgh5526pe2ps2eec", "amount": [ { "denom": "ngonka", "amount": "1417150602535" } ] }, { "recipient": "gonka1qmpm8tsynnfkqe9902dd6ny4lc5hvp8q7wkrpc", "amount": [ { "denom": "ngonka", "amount": "1402806799218" } ] }, { "recipient": "gonka186ghmxetau6dykfzqdqxe7vhra5w77e98gcdn7", "amount": [ { "denom": "ngonka", "amount": "1382392335195" } ] }, { "recipient": "gonka1ctz9hz6c2pc9hpj5qsw83fmmf9uekqesg4k9sh", "amount": [ { "denom": "ngonka", "amount": "1380013105932" } ] }, { "recipient": "gonka1mhepzjgj5asrx2rjh69ckdae9cuhaynqtuv4sp", "amount": [ { "denom": "ngonka", "amount": "1376447164167" } ] }, { "recipient": "gonka1dzdmx5ljrwkelrmgd7suv2q43epn293qacpgqn", "amount": [ { "denom": "ngonka", "amount": "1352946136845" } ] }, { "recipient": "gonka19zxzp5xlgj0gq7xlnfhaqcedjrqv0jhpq3zdwc", "amount": [ { "denom": "ngonka", "amount": "1344056281126" } ] }, { "recipient": "gonka19sf4axsacdphm598alpxt7t2qpacxttdmj5e06", "amount": [ { "denom": "ngonka", "amount": "1323698843693" } ] }, { "recipient": "gonka1ekx3z5gm4azxvsectsflhpul24d06x7rz978d5", "amount": [ { "denom": "ngonka", "amount": "1315872206099" } ] }, { "recipient": "gonka1jvmumx6rwyq302m6y6z5hdkc4cgu845mcgjwud", "amount": [ { "denom": "ngonka", "amount": "1293131959851" } ] }, { "recipient": "gonka19f9hkpmjaldncsfly4j63sy932y8hughn4l3d8", "amount": [ { "denom": "ngonka", "amount": "1288877578717" } ] }, { "recipient": "gonka1qx3znmtpxqgmz3t4tgpdk68dsfxuccn6cxnp8s", "amount": [ { "denom": "ngonka", "amount": "1288707962259" } ] }, { "recipient": "gonka14yprk25twtverkpcsdgnrg5raeuycmkl5dwa34", "amount": [ { "denom": "ngonka", "amount": "1276582463923" } ] }, { "recipient": "gonka1lecmns7dj5wm8f53pe6c8nueukqafknel2wt2m", "amount": [ { "denom": "ngonka", "amount": "1269049737730" } ] }, { "recipient": "gonka1lswsj2x7u4606wqpunmm07skgf76r3dyz4v0d8", "amount": [ { "denom": "ngonka", "amount": "1241250357209" } ] }, { "recipient": "gonka1d5c40gkxqycyxpmup22lw0sp3e3pxat9aee7sx", "amount": [ { "denom": "ngonka", "amount": "1236651340303" } ] }, { "recipient": "gonka14qwpw2l0qmevxy9snllfaw0r9svnh4vdyl3897", "amount": [ { "denom": "ngonka", "amount": "1229611229584" } ] }, { "recipient": "gonka1hx9a6297776yndfgajr7tc3e9kj96t77m4xxf7", "amount": [ { "denom": "ngonka", "amount": "1228846322760" } ] }, { "recipient": "gonka1d5nn7u0hq0pumgmfxk95nj5h3zkuskkdh96dzd", "amount": [ { "denom": "ngonka", "amount": "1211538663678" } ] }, { "recipient": "gonka1830lqug50lse998x2lakk4pj5ypfumz5pasz0y", "amount": [ { "denom": "ngonka", "amount": "1210731495895" } ] }, { "recipient": "gonka1u3fmal7ep88gcgauwe09zk8e77985cqmeuu2fc", "amount": [ { "denom": "ngonka", "amount": "1206598666620" } ] }, { "recipient": "gonka1n6uaty84yezgfcymndq75nmza8y8krt9j0czjm", "amount": [ { "denom": "ngonka", "amount": "1199452287667" } ] }, { "recipient": "gonka16r4kxszdpa6k7wakgt6wk6vus6txhqwqd5drkh", "amount": [ { "denom": "ngonka", "amount": "1193662593554" } ] }, { "recipient": "gonka1h5cc5829dh3260vmnugr5vp0nac7mmktrrhe6l", "amount": [ { "denom": "ngonka", "amount": "1188612232016" } ] }, { "recipient": "gonka12dvpyn0a2tvuc28vanrj7nr7d8ez022mms4vf2", "amount": [ { "denom": "ngonka", "amount": "1186466441984" } ] }, { "recipient": "gonka1j8l7fcxqxakp2py7jcgh27ccgxaze7krscxfe5", "amount": [ { "denom": "ngonka", "amount": "1169732083672" } ] }, { "recipient": "gonka18xeqnspxpg2vncufnjne485rkaagwvz7whyn0d", "amount": [ { "denom": "ngonka", "amount": "1167393439685" } ] }, { "recipient": "gonka1mtahyzwk726p50mqkj2n6jt3u32vcyrgwzqmw8", "amount": [ { "denom": "ngonka", "amount": "1161040511004" } ] }, { "recipient": "gonka174srhxhfktxx4hv94zcdz4jqfw9kvc4ge2p0pu", "amount": [ { "denom": "ngonka", "amount": "1160447819571" } ] }, { "recipient": "gonka1a46zzvkdg5kf7raesh7rp2e3alx7gzgq3ww4ac", "amount": [ { "denom": "ngonka", "amount": "1152015798500" } ] }, { "recipient": "gonka1qmlkwzrpv5zkzzpgkthftd29uqg0ka8dddc290", "amount": [ { "denom": "ngonka", "amount": "1151698611178" } ] }, { "recipient": "gonka12tfc6ccmadjqv6yaa3axxsuhy6zv6tupu78p8u", "amount": [ { "denom": "ngonka", "amount": "1134910852048" } ] }, { "recipient": "gonka1e4elawx3wgp407u3vqr8kj7ctef0qzme6wvntr", "amount": [ { "denom": "ngonka", "amount": "1129567802700" } ] }, { "recipient": "gonka1xwkesaxvdadh9wt9yyladu0r260s7whklcktds", "amount": [ { "denom": "ngonka", "amount": "1124226587642" } ] }, { "recipient": "gonka1erjgpt52lp7atyq5c5u5tpprtqjr4pt6zd2pny", "amount": [ { "denom": "ngonka", "amount": "1122166176790" } ] }, { "recipient": "gonka12qz87r7g5sde33c6jnjp7n5kxj4t650v9ezxu7", "amount": [ { "denom": "ngonka", "amount": "1095484122804" } ] }, { "recipient": "gonka1k4ufjpu9h79zy4hdtly8dcgyfkjmeunqtk3k9e", "amount": [ { "denom": "ngonka", "amount": "1094749475242" } ] }, { "recipient": "gonka1u60q4n3ymcglvhglylchpyvc04kvvurl967mgk", "amount": [ { "denom": "ngonka", "amount": "1092175889843" } ] }, { "recipient": "gonka1zhjhpgcmzyc92mlhawja4esnwuwu5u8sjlm4c2", "amount": [ { "denom": "ngonka", "amount": "1090676645680" } ] }, { "recipient": "gonka1338kw8rwv6qlujzrgfacce3ej6emekzjwudrge", "amount": [ { "denom": "ngonka", "amount": "1085517708212" } ] }, { "recipient": "gonka1ypy2ygsa7se9lrcwxlstgwsy0lfged0kg8ft95", "amount": [ { "denom": "ngonka", "amount": "1085335893801" } ] }, { "recipient": "gonka18py93vhrf7mn3yjkqjdpkwlqfpavu3f06ssllv", "amount": [ { "denom": "ngonka", "amount": "1084494242094" } ] }, { "recipient": "gonka12pwvrkm7vqkme62y0u6pgms79w8eqyt57s2vcx", "amount": [ { "denom": "ngonka", "amount": "1081514356117" } ] }, { "recipient": "gonka18qd8fhk9uj0zk5xlgnsfkpj78ed65sptf0jkwr", "amount": [ { "denom": "ngonka", "amount": "1077905106645" } ] }, { "recipient": "gonka1x5zn0e5n9c8qjjjt38g0wd05px89q5pxaxqpq7", "amount": [ { "denom": "ngonka", "amount": "1075980413077" } ] }, { "recipient": "gonka1rw9fhpnf6pnlwzpfq836w89qmu6v7kfxs9xmvn", "amount": [ { "denom": "ngonka", "amount": "1075006911309" } ] }, { "recipient": "gonka1ajvs7j8wlgjy8d3kjad520am6jm3a4alj7k4jq", "amount": [ { "denom": "ngonka", "amount": "1070942320028" } ] }, { "recipient": "gonka1l45efpupwqw9uky3gjwy35mwae9jwgffuqpm7s", "amount": [ { "denom": "ngonka", "amount": "1067617076850" } ] }, { "recipient": "gonka1j6dthe47wll5rhf2nn6r7xw9zy2luah2ant9pf", "amount": [ { "denom": "ngonka", "amount": "1050721942469" } ] }, { "recipient": "gonka129ks6ra4ddy8ppsfk0gr8yu24sqk3nanmm34cs", "amount": [ { "denom": "ngonka", "amount": "1036348256503" } ] }, { "recipient": "gonka1xg25gmn8uzeyzqqrchx6mfz379mvg43zsvj0y3", "amount": [ { "denom": "ngonka", "amount": "1035165938494" } ] }, { "recipient": "gonka10kjjhgzngn2yj9fgrcfu4wf5lj6xv05u7xhz53", "amount": [ { "denom": "ngonka", "amount": "1032271654590" } ] }, { "recipient": "gonka1qpvpnr3anscj0tsnm64fus27xhnx20lf4rvjeq", "amount": [ { "denom": "ngonka", "amount": "1011681975315" } ] }, { "recipient": "gonka1trz6e3rczlp4ma749v8zk6xng9jmcnrvnwv4rh", "amount": [ { "denom": "ngonka", "amount": "1011128733862" } ] }, { "recipient": "gonka16p9vx68hfr5vpy6s59rvrz85le5dq22uymukgv", "amount": [ { "denom": "ngonka", "amount": "1010920650828" } ] }, { "recipient": "gonka1tfds6hy4tge3p3pkzcj38qjnsgpadjhjk5f3ga", "amount": [ { "denom": "ngonka", "amount": "1006193213519" } ] }, { "recipient": "gonka1eg6tyw49ujmk7mgwqzyhzzyzcupzhw7fhku0qz", "amount": [ { "denom": "ngonka", "amount": "1003350070071" } ] }, { "recipient": "gonka14g78ez2zy08k8sssue483zmfpgd4qut8zcwlqc", "amount": [ { "denom": "ngonka", "amount": "1003067493292" } ] }, { "recipient": "gonka1qjdt3qykdrka2am7s5rtrze44f7y8vccegjc70", "amount": [ { "denom": "ngonka", "amount": "1002860190000" } ] }, { "recipient": "gonka1ex0ck58q3elelsysl3r9qwjljs7yn2yd65kr6h", "amount": [ { "denom": "ngonka", "amount": "984546173428" } ] }, { "recipient": "gonka105qfr38n0rz0d2r8hererw9ws5qx7njcujezvu", "amount": [ { "denom": "ngonka", "amount": "968810021710" } ] }, { "recipient": "gonka1k3aj9lxjllcslaus7a2ha5d3pla4rre67ksnsc", "amount": [ { "denom": "ngonka", "amount": "963915416268" } ] }, { "recipient": "gonka1y07fqanen3dwgr5dku36gy8lfk3uxtj000t38p", "amount": [ { "denom": "ngonka", "amount": "960156417708" } ] }, { "recipient": "gonka19f8zl7a979j0z90r5k0pajhua2y6ajtykxe8dk", "amount": [ { "denom": "ngonka", "amount": "936394415904" } ] }, { "recipient": "gonka1y3r32jhy6s4ge2sl5ly5s90gc0r9d2n4wmzvu9", "amount": [ { "denom": "ngonka", "amount": "920045323759" } ] }, { "recipient": "gonka1rn5nud8367cnspgas0dmtq2plxkacjsttqtdy8", "amount": [ { "denom": "ngonka", "amount": "916211818671" } ] }, { "recipient": "gonka13jelpte0qx5f0up3pzmmgnnqj5877rwfs08n7q", "amount": [ { "denom": "ngonka", "amount": "915755003150" } ] }, { "recipient": "gonka1gz6d9j834xvhvyt7c67ux6egugns7dlc5dzqds", "amount": [ { "denom": "ngonka", "amount": "912883054093" } ] }, { "recipient": "gonka1c6y9p4w87equy52va4us3qzycz9w28ua9693gl", "amount": [ { "denom": "ngonka", "amount": "893219350563" } ] }, { "recipient": "gonka10g4ak0ku3lezt0q3kk346updcyyz83369pqtgx", "amount": [ { "denom": "ngonka", "amount": "883688223962" } ] }, { "recipient": "gonka1nq396dmfz2rntud8urt7ddyc7ysyg6rlax5vyc", "amount": [ { "denom": "ngonka", "amount": "880740116277" } ] }, { "recipient": "gonka1c8pemd8czpgeg69cu95y58fstuquw93uwqml7f", "amount": [ { "denom": "ngonka", "amount": "879178934834" } ] }, { "recipient": "gonka100xav7dpl82gxrtg72yjhpz2zn6f24gv035ted", "amount": [ { "denom": "ngonka", "amount": "866376648961" } ] }, { "recipient": "gonka14zg378dzun4p2zhyuaq59y2q0e340wzahgz97q", "amount": [ { "denom": "ngonka", "amount": "861590303143" } ] }, { "recipient": "gonka1wkgawwdzj623ss8eywayzdj6qcgr2llygactje", "amount": [ { "denom": "ngonka", "amount": "860922847224" } ] }, { "recipient": "gonka1afe8squhg6aqwuts34wsyuu3rmn349hqqp6tqf", "amount": [ { "denom": "ngonka", "amount": "838808955066" } ] }, { "recipient": "gonka1jqwrpyqn34jx0ermlus46f87epayqxtakhyu5u", "amount": [ { "denom": "ngonka", "amount": "838114379054" } ] }, { "recipient": "gonka12gc47yq8m7rnsa3aucq8mlzm7men8jaac7qkkz", "amount": [ { "denom": "ngonka", "amount": "834890948011" } ] }, { "recipient": "gonka167m8t885t8j4wr8qmh652x9d2jvhtdk4f367fd", "amount": [ { "denom": "ngonka", "amount": "827209263037" } ] }, { "recipient": "gonka14nurupejmd8vgu806jx4qpf6jfs55mrlc6umem", "amount": [ { "denom": "ngonka", "amount": "824722902081" } ] }, { "recipient": "gonka1y0y9fcfhlhuz76falhdekx8w56pk88jaxssydu", "amount": [ { "denom": "ngonka", "amount": "823559566189" } ] }, { "recipient": "gonka1k6p754pyhxud2399knyccgjpjvdafj2u9xlgyf", "amount": [ { "denom": "ngonka", "amount": "811589446121" } ] }, { "recipient": "gonka106prclvpt5lgl9p20ql8kr6ap8vt0un535slvu", "amount": [ { "denom": "ngonka", "amount": "808642141902" } ] }, { "recipient": "gonka1ehqrd2828q8zrkn4qafym30eky56krezucxxhz", "amount": [ { "denom": "ngonka", "amount": "807768895044" } ] }, { "recipient": "gonka1p209mlvngz8hu0p5ff7dsjzqhjpx4jzn6k652r", "amount": [ { "denom": "ngonka", "amount": "805071964127" } ] }, { "recipient": "gonka1662dun8ufuvjfa652th9farq6devh57p0v4r3y", "amount": [ { "denom": "ngonka", "amount": "803355958966" } ] }, { "recipient": "gonka16msrxqwfedlll09hdwv0zmma6wttxx0wqqlt0y", "amount": [ { "denom": "ngonka", "amount": "781828824066" } ] }, { "recipient": "gonka12fazh3etpdx947ldwen4wudnds7wu4kjp5vd76", "amount": [ { "denom": "ngonka", "amount": "775232433739" } ] }, { "recipient": "gonka17cnuuvplky4ck8hwj8smh6he6tgq6su45r5v5y", "amount": [ { "denom": "ngonka", "amount": "774143127202" } ] }, { "recipient": "gonka12hzd9zlz3tgslky477d4wa0jlwacv4nj9vxlmj", "amount": [ { "denom": "ngonka", "amount": "771984739406" } ] }, { "recipient": "gonka1hxtg78hm0lneuygmgzanxmasn4x5rykwmmle7z", "amount": [ { "denom": "ngonka", "amount": "768342112553" } ] }, { "recipient": "gonka14sk8te3wu4zh9dal9yd9tm3pd2qerdru4aqm05", "amount": [ { "denom": "ngonka", "amount": "764375908138" } ] }, { "recipient": "gonka13tfjp70mhjxhdl3kjweuln07zu6y9ed3gr9k6y", "amount": [ { "denom": "ngonka", "amount": "763220498896" } ] }, { "recipient": "gonka1p6wekfevflq2h4rx9jekc86qaqa4ussw8legsd", "amount": [ { "denom": "ngonka", "amount": "756975902050" } ] }, { "recipient": "gonka1x2lalvrn6cucvzwfcd5cwwhggfuxqckw8k0zrq", "amount": [ { "denom": "ngonka", "amount": "755267022910" } ] }, { "recipient": "gonka1369ax8kr4ma8zu708jr3x2r902lfs8tcguyxl8", "amount": [ { "denom": "ngonka", "amount": "755258914621" } ] }, { "recipient": "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "amount": [ { "denom": "ngonka", "amount": "752017682985" } ] }, { "recipient": "gonka1lhycnwdtc6txcpvdvz2wym3zpdhlrj6w2z4evj", "amount": [ { "denom": "ngonka", "amount": "749894259281" } ] }, { "recipient": "gonka1eaf9r3qqnweqx23z0ahh77legtv2gnk3wwdwl2", "amount": [ { "denom": "ngonka", "amount": "739075526779" } ] }, { "recipient": "gonka1v5ggga7lslfg2e57m9anxud40v2s4t9dw8yj68", "amount": [ { "denom": "ngonka", "amount": "726622286387" } ] }, { "recipient": "gonka10e7qay76svkulq7wx3mez60jvdxj5pmjynmyrz", "amount": [ { "denom": "ngonka", "amount": "716814751592" } ] }, { "recipient": "gonka1hhw376qvn4wuu424r9ueflvkv7fzzat9wuuvjg", "amount": [ { "denom": "ngonka", "amount": "714039075269" } ] }, { "recipient": "gonka1j4gwddnpf9h6n6899znss7tprqzxpwpedk7ayf", "amount": [ { "denom": "ngonka", "amount": "712231234908" } ] }, { "recipient": "gonka10ux22dq9a5dn5t4v370vzkww874yc6pmudxjen", "amount": [ { "denom": "ngonka", "amount": "710726835542" } ] }, { "recipient": "gonka1vmwqf4mkl4ucqnrgjmnsl694hktepaecuvvyz0", "amount": [ { "denom": "ngonka", "amount": "698413545705" } ] }, { "recipient": "gonka1mdy7nlecw4xaqdxmeh3qlqzakg9ftge9szfqgg", "amount": [ { "denom": "ngonka", "amount": "696337292930" } ] }, { "recipient": "gonka1ktl3kkn9l68c9amanu8u4868mcjmtsr5tgzmjk", "amount": [ { "denom": "ngonka", "amount": "694260787860" } ] }, { "recipient": "gonka1lmh6fy92ac2wldnpugg3t3xhp8lnqzgq0j0efg", "amount": [ { "denom": "ngonka", "amount": "693656303863" } ] }, { "recipient": "gonka1ccgvme9cpkwqes65jqgcmy09dtze9cp933cm0p", "amount": [ { "denom": "ngonka", "amount": "693235305004" } ] }, { "recipient": "gonka1g9n5yek0sk84qpx0lwc7hq6p3v2fqr5ggml3gg", "amount": [ { "denom": "ngonka", "amount": "684113588212" } ] }, { "recipient": "gonka1y4kyhqy022gt4kklxxflgqkutnx96ssww66zg6", "amount": [ { "denom": "ngonka", "amount": "668334873066" } ] }, { "recipient": "gonka1vz2jg42w39l63dmvmjqdsnxx0ywnzt9nzypdy7", "amount": [ { "denom": "ngonka", "amount": "667372982192" } ] }, { "recipient": "gonka19yqs6l5s2wl908fswm58zptxvkvg82dtynwuku", "amount": [ { "denom": "ngonka", "amount": "660800031574" } ] }, { "recipient": "gonka1g884r7q58wptvlcpuk09gvw9j5uhwadr4qjexs", "amount": [ { "denom": "ngonka", "amount": "657348636670" } ] }, { "recipient": "gonka1w3ewq7swwdxx8fsht8tl250f7qv44edhlltrh8", "amount": [ { "denom": "ngonka", "amount": "642705050439" } ] }, { "recipient": "gonka1h2c3mkxq4xej7dmsp5hcva8msn78v07xuqhl90", "amount": [ { "denom": "ngonka", "amount": "641937320557" } ] }, { "recipient": "gonka14cqs3cnsahrr52end3twr7sq3rhtwnj8j8pyzv", "amount": [ { "denom": "ngonka", "amount": "641595530709" } ] }, { "recipient": "gonka1l289k89zulv5ml63ursf975cvmr0j85k8ls46t", "amount": [ { "denom": "ngonka", "amount": "636049841835" } ] }, { "recipient": "gonka10cyq8zuplcwr5ntesxn52wp5ky3a7c3nrqdce8", "amount": [ { "denom": "ngonka", "amount": "634870695105" } ] }, { "recipient": "gonka1j62evzhlg556krdfhynpduchyl0px8qga8wfut", "amount": [ { "denom": "ngonka", "amount": "633074416696" } ] }, { "recipient": "gonka14fn68sulr6v6l78kvur9u6yw5lwurtqcrqkh93", "amount": [ { "denom": "ngonka", "amount": "618164993040" } ] }, { "recipient": "gonka1h796gh5vnp0l3k0klvzk9rw9240223njss8g5y", "amount": [ { "denom": "ngonka", "amount": "617132119663" } ] }, { "recipient": "gonka1zsnpv9htjtq35ux04hal5l8dnlgah22zl6rk3h", "amount": [ { "denom": "ngonka", "amount": "616305081132" } ] }, { "recipient": "gonka1lqv96tny8a0344e6jfgxk500q5ct7zy9ekz49m", "amount": [ { "denom": "ngonka", "amount": "613560930734" } ] }, { "recipient": "gonka1aev99sylsnfzyu2dwlnw6f9lugjkvav7kxqp0k", "amount": [ { "denom": "ngonka", "amount": "605263625720" } ] }, { "recipient": "gonka140f97y9dsnjc2cdusp0hzx73tk693ycg6mkqy5", "amount": [ { "denom": "ngonka", "amount": "598119300722" } ] }, { "recipient": "gonka1hhx6pvs6n4ehgv4wzz7h9f68t8hm96t9fq0ydd", "amount": [ { "denom": "ngonka", "amount": "594067847856" } ] }, { "recipient": "gonka1fp8zl07qccdzuekns2q55jgmcag40kjrm8z0z9", "amount": [ { "denom": "ngonka", "amount": "588451915703" } ] }, { "recipient": "gonka1frfr2z4lclq0wjqsrstnhm48rmvkmd0tfsssvk", "amount": [ { "denom": "ngonka", "amount": "586439098001" } ] }, { "recipient": "gonka1chktrhryd3zpxcwtw595wg9mxgj0wwwmzsule5", "amount": [ { "denom": "ngonka", "amount": "583192531647" } ] }, { "recipient": "gonka163ug8zucqeag9v5ey4au34jqt7vejkmxsg74eu", "amount": [ { "denom": "ngonka", "amount": "578583751996" } ] }, { "recipient": "gonka147rfj8kg892wfqvqrsl39d3h26k002cv54qxv7", "amount": [ { "denom": "ngonka", "amount": "576363693008" } ] }, { "recipient": "gonka1ndlfjnp5d7eruyrhjvn6uape3jp630qld7l9yl", "amount": [ { "denom": "ngonka", "amount": "570320457368" } ] }, { "recipient": "gonka1fxdt48vp78uxa7apuuamv4clwafxagnjg9eulc", "amount": [ { "denom": "ngonka", "amount": "566039434935" } ] }, { "recipient": "gonka1elw9xd79mpsrt7jqwkweg6yv02nvda49xhcej2", "amount": [ { "denom": "ngonka", "amount": "564618912568" } ] }, { "recipient": "gonka12hw8xf5rgy7fn0wt3qaxyk9gav6eu2rns25t2v", "amount": [ { "denom": "ngonka", "amount": "563676112102" } ] }, { "recipient": "gonka1clevcl55wh3g8fx82y9nuhcnxc8kalwf53a4gj", "amount": [ { "denom": "ngonka", "amount": "560601174860" } ] }, { "recipient": "gonka15sptlamre9vq4m5t7pa7je5r2pc34kmlwvj0jz", "amount": [ { "denom": "ngonka", "amount": "558487767957" } ] }, { "recipient": "gonka159kqhlp3psj4r7r9646lhjpfz5apwmyen6y7m2", "amount": [ { "denom": "ngonka", "amount": "552690033928" } ] }, { "recipient": "gonka14law208gj4hgpr04y2udwlkkxh3k9mv07evgh4", "amount": [ { "denom": "ngonka", "amount": "548618679904" } ] }, { "recipient": "gonka1p22v6ncqsys9fh85gdmkakpe24x2zqfyp60z5q", "amount": [ { "denom": "ngonka", "amount": "547116218730" } ] }, { "recipient": "gonka1ujfwdfe0tq667vt5sz2pus524zpjveedp4tkj2", "amount": [ { "denom": "ngonka", "amount": "545997408120" } ] }, { "recipient": "gonka1p60lruhxmwcsa9taa28cp4k4f6kv2kvyu5h5ep", "amount": [ { "denom": "ngonka", "amount": "545755552498" } ] }, { "recipient": "gonka10t67f5zxh7canhuznxg7cperec6286jjqh5pey", "amount": [ { "denom": "ngonka", "amount": "544379556981" } ] }, { "recipient": "gonka10t34t7tvvgrzd8npm30u8dx4uw2v9axcercgak", "amount": [ { "denom": "ngonka", "amount": "543506694568" } ] }, { "recipient": "gonka1sskwvat6wk6sdjjg87ne2nhexdyznxntu07vzh", "amount": [ { "denom": "ngonka", "amount": "542959627601" } ] }, { "recipient": "gonka1d2mfxjhvx0zm3jd05arl0d36qn2k03mc5y7zt4", "amount": [ { "denom": "ngonka", "amount": "538035929178" } ] }, { "recipient": "gonka1vn6hk34wme5xvqzjmm26u9snkxg7nqd490gmwq", "amount": [ { "denom": "ngonka", "amount": "535027430493" } ] }, { "recipient": "gonka15vunu0new53m83ccvfcmkf84v7q4s8ldsjfu4y", "amount": [ { "denom": "ngonka", "amount": "530331698652" } ] }, { "recipient": "gonka1c40y2drwhu7px0gue02696y8ypwq2y30fxnfp5", "amount": [ { "denom": "ngonka", "amount": "523388377860" } ] }, { "recipient": "gonka1yquunstmnn35tuc6wsrlv020ul2rnuyldqkt37", "amount": [ { "denom": "ngonka", "amount": "523050197093" } ] }, { "recipient": "gonka1gsarmv9gsc7g9fv9nsqtk6t0d7erxpurf5mvvl", "amount": [ { "denom": "ngonka", "amount": "521369292752" } ] }, { "recipient": "gonka1fryp5vn5xppkwykzjul6e2crkgxgwhl2cunrmx", "amount": [ { "denom": "ngonka", "amount": "514067267997" } ] }, { "recipient": "gonka1mkdgh784u7la8fpexnge9wqhdw65al67f9e2k3", "amount": [ { "denom": "ngonka", "amount": "496529632342" } ] }, { "recipient": "gonka1043d00lu0v3fz53cut34twtcanalqg9u8vehp2", "amount": [ { "denom": "ngonka", "amount": "490582260899" } ] }, { "recipient": "gonka1w568mv4h5c7sln767rxc8hzf6s9nhxvs7raz08", "amount": [ { "denom": "ngonka", "amount": "489475546267" } ] }, { "recipient": "gonka1awufch9x3slh9h9t3exa36r23rwjknswldce09", "amount": [ { "denom": "ngonka", "amount": "489140116165" } ] }, { "recipient": "gonka1wt8sr9jxzpec65j7zkxsgh6edk3m6r8nlf5za4", "amount": [ { "denom": "ngonka", "amount": "488209774154" } ] }, { "recipient": "gonka18ejynmrg67epw5psqhv9stm9yrskerhvqvm5qs", "amount": [ { "denom": "ngonka", "amount": "486890528819" } ] }, { "recipient": "gonka1desd6924c4aturcdmwk59jpye5em3q2ze8gvjn", "amount": [ { "denom": "ngonka", "amount": "486556076647" } ] }, { "recipient": "gonka1crldgzq22fly44ek58rq900ef48usac8f3hpxd", "amount": [ { "denom": "ngonka", "amount": "483028542609" } ] }, { "recipient": "gonka1yk34z38t92jzjgq2ga7tkfpj07sf4ss3tj6n2m", "amount": [ { "denom": "ngonka", "amount": "480269006881" } ] }, { "recipient": "gonka1vxs4azxcym36wts0t7z5nj65ma8pnkvpmywxa0", "amount": [ { "denom": "ngonka", "amount": "479871438049" } ] }, { "recipient": "gonka1g99cz2zdgalleuzhwa6h3yxf5k7khjwxg423ms", "amount": [ { "denom": "ngonka", "amount": "476757658504" } ] }, { "recipient": "gonka17tlh09e32xpv2uj433ytjnwwd8fh24jclpzm5s", "amount": [ { "denom": "ngonka", "amount": "476168080739" } ] }, { "recipient": "gonka13r2vlppxhkmk0868yfu79hkaewrzv50luhnyev", "amount": [ { "denom": "ngonka", "amount": "475133166252" } ] }, { "recipient": "gonka14ayvun7uw0d9u6nk7k6w3zdeewq0p9qzqycsmv", "amount": [ { "denom": "ngonka", "amount": "472492213078" } ] }, { "recipient": "gonka17amsnz2csvjwt3rdezys6gj7wggexxwtwt03a9", "amount": [ { "denom": "ngonka", "amount": "471319390306" } ] }, { "recipient": "gonka18x3y80uu9s53lewvt0eu6tgc9rrvaht7yqzmw4", "amount": [ { "denom": "ngonka", "amount": "470090030109" } ] }, { "recipient": "gonka1290wk5as5vg4f6l5r5sl2hjr2ty24lam3l6vlj", "amount": [ { "denom": "ngonka", "amount": "469485703062" } ] }, { "recipient": "gonka1sun7e0re84mjf79c6euqp9v4jeujgz2x25w4e9", "amount": [ { "denom": "ngonka", "amount": "448558908153" } ] }, { "recipient": "gonka1eqjpx0k806kcu8tjr64zlswk9vkznsstyeq0j8", "amount": [ { "denom": "ngonka", "amount": "443820315340" } ] }, { "recipient": "gonka1cy5x2c2zq4s9zq5r2xz609j63mprpc9tdz8drr", "amount": [ { "denom": "ngonka", "amount": "443036488390" } ] }, { "recipient": "gonka1l279mvj0rgkr5gkrtkdfeetmf602lkfvkf038j", "amount": [ { "denom": "ngonka", "amount": "442746566649" } ] }, { "recipient": "gonka1534swfr4vp6s9zc8prhw6uzzvp9teg5pnrrs06", "amount": [ { "denom": "ngonka", "amount": "440021550150" } ] }, { "recipient": "gonka1975m3w08ywrc89aqcr9m8z6z70a38jf64vwte8", "amount": [ { "denom": "ngonka", "amount": "438907596251" } ] }, { "recipient": "gonka1lacrx7sdpwvy2fjxsldmz0w8ptk5qlegrh0qyc", "amount": [ { "denom": "ngonka", "amount": "438552332390" } ] }, { "recipient": "gonka1cv73drcy44vfspr9ryhdh4yxq3r4w4n7lt0a06", "amount": [ { "denom": "ngonka", "amount": "438282542671" } ] }, { "recipient": "gonka1g69nf83247psxptvw9clwehma6f2g4q2c08073", "amount": [ { "denom": "ngonka", "amount": "434588074767" } ] }, { "recipient": "gonka19f20kkuwra4z2ml74ephrallpguclua83l9zrt", "amount": [ { "denom": "ngonka", "amount": "433808055245" } ] }, { "recipient": "gonka1kdhuzlaahg0du24n5kyr29h3344gewmmmrs89z", "amount": [ { "denom": "ngonka", "amount": "432325812729" } ] }, { "recipient": "gonka18hsyhvgheg5agh86jkut9d7ggkx4swq2ms3f7s", "amount": [ { "denom": "ngonka", "amount": "431488493451" } ] }, { "recipient": "gonka1kx5y69fvgcag8n2lvwtjq2yqu4rkqauwc0nuy8", "amount": [ { "denom": "ngonka", "amount": "431006304323" } ] }, { "recipient": "gonka1he4syma87py2f65rfy3zsrtw5e4nhs69t3sgjt", "amount": [ { "denom": "ngonka", "amount": "425831596283" } ] }, { "recipient": "gonka17lw5msaae6hupgylapqcqmggcyyzhvdgy406s4", "amount": [ { "denom": "ngonka", "amount": "425243818848" } ] }, { "recipient": "gonka1a9yz979xxryjh9hdzuyxddscwtg9g92079hjra", "amount": [ { "denom": "ngonka", "amount": "425076183432" } ] }, { "recipient": "gonka19nsaq8gdavl04mx0v6lhvzzdkqhu6uf56l38w0", "amount": [ { "denom": "ngonka", "amount": "424272905394" } ] }, { "recipient": "gonka1063hmy29tgwh5zpup7m9qat7nvgrnyyyuudjaa", "amount": [ { "denom": "ngonka", "amount": "423526894395" } ] }, { "recipient": "gonka1cs744mzemn5h8p2e7c0zkc67sgdd5p8es3qe9v", "amount": [ { "denom": "ngonka", "amount": "419663870856" } ] }, { "recipient": "gonka1cu4et2vt7squt6jslmn7jc6sr3kr9dwx8807er", "amount": [ { "denom": "ngonka", "amount": "416726958772" } ] }, { "recipient": "gonka1k8emnxc8ex8qa47h9l5y0dxprxen0hhqlnexwy", "amount": [ { "denom": "ngonka", "amount": "415098212687" } ] }, { "recipient": "gonka1hz02vsjwrjnfu65knc8xnwh4xawt02nzaltctt", "amount": [ { "denom": "ngonka", "amount": "414514027990" } ] }, { "recipient": "gonka1w2dtrs7thx2jfeu389ztwc38h0nd4pv2hl7xtp", "amount": [ { "denom": "ngonka", "amount": "413803912716" } ] }, { "recipient": "gonka1d7fl3tfcjj52uavnfsalmydtdn3uvqvs2wph58", "amount": [ { "denom": "ngonka", "amount": "413793735098" } ] }, { "recipient": "gonka15vwfhvvya0xhf8cfxxgsqwkjmv8ay2hhzdd0yl", "amount": [ { "denom": "ngonka", "amount": "411140962032" } ] }, { "recipient": "gonka1nxp4edhgytlmczmmwvzgu6humsuwpf8t8yvd40", "amount": [ { "denom": "ngonka", "amount": "404230785405" } ] }, { "recipient": "gonka1gku2agvxyl9yvq6j0ulu8thm8n2mmg32dxvm8k", "amount": [ { "denom": "ngonka", "amount": "400668604165" } ] }, { "recipient": "gonka18xpmr5v362gwvxlq78twhg7ht07wu4kzdqu4y2", "amount": [ { "denom": "ngonka", "amount": "399555085227" } ] }, { "recipient": "gonka1k9wr42jrdudvxsrdrgnxqaxcchrwy2ss84ha7t", "amount": [ { "denom": "ngonka", "amount": "397336261711" } ] }, { "recipient": "gonka1wnhd4uqvf3k38av7m9s3ssdzu0kvqskmes69gu", "amount": [ { "denom": "ngonka", "amount": "389942484029" } ] }, { "recipient": "gonka19z0dg9zpfkdfye0ddrnkcynrwvqslw4a2alzf0", "amount": [ { "denom": "ngonka", "amount": "388059563885" } ] }, { "recipient": "gonka1fhcxxfnk0ap7u5hjyvgvd0500lpq8qre59hwza", "amount": [ { "denom": "ngonka", "amount": "387606471004" } ] }, { "recipient": "gonka1uwknfekug2ykhygjpfy5n7uc8l6naxz267dgsw", "amount": [ { "denom": "ngonka", "amount": "381373301630" } ] }, { "recipient": "gonka107et3r7gxsrkce7wq42jjf5k98r5xvsfy6xsn5", "amount": [ { "denom": "ngonka", "amount": "380030638392" } ] }, { "recipient": "gonka16dqp2jfmnaahwxq5x7snn2h2ap026v5lwhr5m7", "amount": [ { "denom": "ngonka", "amount": "378999867692" } ] }, { "recipient": "gonka1c7wr8u3j78dfd2jmymzq3c3a2gzx75g2s682dl", "amount": [ { "denom": "ngonka", "amount": "378149101711" } ] }, { "recipient": "gonka15e0y6kxleal3l4vr9vucwv72vu8cfndjtljl6y", "amount": [ { "denom": "ngonka", "amount": "375476917342" } ] }, { "recipient": "gonka1lmcyrg9fh0lj7spq2ra4kduttf86ede5xlrmay", "amount": [ { "denom": "ngonka", "amount": "372770462475" } ] }, { "recipient": "gonka1w29nvdy6caqtrw30whz9h6ghl0xszwh3egndah", "amount": [ { "denom": "ngonka", "amount": "372546833803" } ] }, { "recipient": "gonka1n8sczgy8379gqx0z4xuwrv7g50tcml6r9whkxa", "amount": [ { "denom": "ngonka", "amount": "370848240747" } ] }, { "recipient": "gonka165eh4p7rkucdv3p0pd92l67rm8fw8apq0p2c9e", "amount": [ { "denom": "ngonka", "amount": "365333781875" } ] }, { "recipient": "gonka1f7uwyhetekfar5h5q7vtatne28futuffypde4j", "amount": [ { "denom": "ngonka", "amount": "364832113795" } ] }, { "recipient": "gonka16a89kpc76p0m26zv4rck5sm9kc7yl5d59ztjpr", "amount": [ { "denom": "ngonka", "amount": "361064732604" } ] }, { "recipient": "gonka10p49jx70haq9uhjy94y80zkfv3xk5pafk5wc5q", "amount": [ { "denom": "ngonka", "amount": "353283309527" } ] }, { "recipient": "gonka1lmgutdlel0fny79zvlsh9aw3c0dw75gtscka3g", "amount": [ { "denom": "ngonka", "amount": "353061160395" } ] }, { "recipient": "gonka1gsnlch7sav73dxearvt7ylh3qcq3fdurad72za", "amount": [ { "denom": "ngonka", "amount": "351121509816" } ] }, { "recipient": "gonka17njwpngllwv7hlgsdx2h7n0yxjjsqgth2lsy72", "amount": [ { "denom": "ngonka", "amount": "351084936780" } ] }, { "recipient": "gonka1mmlyd5xxu5l68yx8wzclrkxkxvm88mhq5tp5s0", "amount": [ { "denom": "ngonka", "amount": "348627504128" } ] }, { "recipient": "gonka1hzqehs8eq609tmmwhhj239acd4t04ev97277q3", "amount": [ { "denom": "ngonka", "amount": "345108557136" } ] }, { "recipient": "gonka1yt2s5u5k06rm2au8dsqm4kzwmw7klqsrd6xd95", "amount": [ { "denom": "ngonka", "amount": "344628037407" } ] }, { "recipient": "gonka1qlt90c4hxccgnuc478jaa3xl5klga84xzrvpda", "amount": [ { "denom": "ngonka", "amount": "344336495222" } ] }, { "recipient": "gonka1nhsw6z4z4vevzzyrdkq2fxfgn8dypuudjvangc", "amount": [ { "denom": "ngonka", "amount": "340275511499" } ] }, { "recipient": "gonka13w7j5pmzg0an9gutm40eflfkl74zsja9jqqvcs", "amount": [ { "denom": "ngonka", "amount": "335905698946" } ] }, { "recipient": "gonka125xgn4z89quhrjhv6qfgn83wqwlaykxs8upjrt", "amount": [ { "denom": "ngonka", "amount": "331972513490" } ] }, { "recipient": "gonka1q96dv6st48490vtzx2pwuwkjg439dr4hg6dzjn", "amount": [ { "denom": "ngonka", "amount": "330848630051" } ] }, { "recipient": "gonka1qkwzxe3hwrghhmgek5kvnyhyaw9akkc8mfwsaa", "amount": [ { "denom": "ngonka", "amount": "327938028015" } ] }, { "recipient": "gonka1pa6xam0gh4hccrsunf9nmervcqt3pe5z9l3xrl", "amount": [ { "denom": "ngonka", "amount": "322218386967" } ] }, { "recipient": "gonka18c9r7maxex83kfdm8zpvquleqam8aqm2klkag5", "amount": [ { "denom": "ngonka", "amount": "321451865905" } ] }, { "recipient": "gonka19yvj22q22w5nr8uxtlj6e5wu30cqn3sexmcdcs", "amount": [ { "denom": "ngonka", "amount": "320461635235" } ] }, { "recipient": "gonka1kyft3snetrh9fnetvwrzt4fr5dwm5szl9sx9hq", "amount": [ { "denom": "ngonka", "amount": "319963060625" } ] }, { "recipient": "gonka1xfg6ed596n8ka7tjp7j604prf5n4mgv3h9d02t", "amount": [ { "denom": "ngonka", "amount": "319780202816" } ] }, { "recipient": "gonka17ypfh585hv7g2vyrmdqqpy2czssa7h0pmndyul", "amount": [ { "denom": "ngonka", "amount": "316536534268" } ] }, { "recipient": "gonka1au9qsemsqtng83kf3nfac38gqe0c0f9qslw750", "amount": [ { "denom": "ngonka", "amount": "305617072534" } ] }, { "recipient": "gonka107yrh33u84sund37fkkpslen5untjl7vw3pd9e", "amount": [ { "denom": "ngonka", "amount": "304553256378" } ] }, { "recipient": "gonka19teuc4q23h48m2ser9aqll9nactthfkcs9meke", "amount": [ { "denom": "ngonka", "amount": "303905885385" } ] }, { "recipient": "gonka1fy86zl25jft206rx0j63km5ru2cn3e7t80zzu8", "amount": [ { "denom": "ngonka", "amount": "300459975051" } ] }, { "recipient": "gonka1gdrrsudtxaldp2jrtn2v6qzpd8zr2u544pz3u5", "amount": [ { "denom": "ngonka", "amount": "295893581436" } ] }, { "recipient": "gonka1ceuk4gvskjw9deuvequ0hd6ty2u7h4jsg5a8uj", "amount": [ { "denom": "ngonka", "amount": "295213275244" } ] }, { "recipient": "gonka1g58w4wu7yyla55vfmhm96v9jheyetnxr02jzz7", "amount": [ { "denom": "ngonka", "amount": "295111850857" } ] }, { "recipient": "gonka10ay2yczzqfpels9ez3m6q7mwuje2tqkwjym8wc", "amount": [ { "denom": "ngonka", "amount": "293127877431" } ] }, { "recipient": "gonka1dg7tym5xfd6rt0mnujqcgsdjtdarhtz6pnrvse", "amount": [ { "denom": "ngonka", "amount": "291849556888" } ] }, { "recipient": "gonka10qf25fwar63g6zkvn2nm6pj65va2yz2esl3yd4", "amount": [ { "denom": "ngonka", "amount": "285924438943" } ] }, { "recipient": "gonka1uv8lw89ththtj05c54wehfnqls9u2pza53q33z", "amount": [ { "denom": "ngonka", "amount": "285901741010" } ] }, { "recipient": "gonka1jpxayv4ef6c5z4wn9mxqsla0zkcwu5tq2536sw", "amount": [ { "denom": "ngonka", "amount": "285899745563" } ] }, { "recipient": "gonka1pj07u20jn9cx48r0jwen6evz7mrfj75t3argv4", "amount": [ { "denom": "ngonka", "amount": "285330045368" } ] }, { "recipient": "gonka12fz88uq255gr4l34fedtd240qu9ajhppettvx2", "amount": [ { "denom": "ngonka", "amount": "282968038250" } ] }, { "recipient": "gonka19xy6zmvpu9x4cyhnuryd3c8c4q8t9v5guj3hzl", "amount": [ { "denom": "ngonka", "amount": "279949746921" } ] }, { "recipient": "gonka13r0fwd8flq4psphqkda8u5f5pxu79wcx3s3zmu", "amount": [ { "denom": "ngonka", "amount": "278793671891" } ] }, { "recipient": "gonka1tan3ssg0sz6kzseze5ezvnynhtyf2rfn6pczjv", "amount": [ { "denom": "ngonka", "amount": "278205980463" } ] }, { "recipient": "gonka1gyk0aahvr3qeju4zx0nplfreej6cy4jjk8svc5", "amount": [ { "denom": "ngonka", "amount": "277853300380" } ] }, { "recipient": "gonka15zc68q2924r90hdwmcdgw0pfwvlsnltn6nht9a", "amount": [ { "denom": "ngonka", "amount": "277420674432" } ] }, { "recipient": "gonka1crlh7547ndxs8kl0urejhlttns7fy4ft344zy5", "amount": [ { "denom": "ngonka", "amount": "276941913821" } ] }, { "recipient": "gonka19kd8xatmw86wyz6v5qmc9kqwfnk62cydql7da5", "amount": [ { "denom": "ngonka", "amount": "270590570224" } ] }, { "recipient": "gonka1lajfpxh74xse4xxease0trz5gwecze99875tjf", "amount": [ { "denom": "ngonka", "amount": "268236872042" } ] }, { "recipient": "gonka1xx297g3m4um7g6eayn03cwdmu8feal93sqv4wh", "amount": [ { "denom": "ngonka", "amount": "268107287831" } ] } ], "vesting_epochs": "180" }, { "@type": "/inference.streamvesting.MsgBatchTransferWithVesting", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "outputs": [ { "recipient": "gonka1m2wtkjw80ukazgyngp8eykjukr9jx5rumdsmyr", "amount": [ { "denom": "ngonka", "amount": "267346122911" } ] }, { "recipient": "gonka1wcdrfhud0ey55mq7r83r9jm9n99qauzpm2egp6", "amount": [ { "denom": "ngonka", "amount": "266334120077" } ] }, { "recipient": "gonka1gfltwk9nphmfgn9d77c97p3xzqt4yr0a20md6m", "amount": [ { "denom": "ngonka", "amount": "266302403647" } ] }, { "recipient": "gonka1qvpct2fqwpfqhznwjqs498ggp7wyxjkd4mvxhz", "amount": [ { "denom": "ngonka", "amount": "266127303219" } ] }, { "recipient": "gonka1l46sylzza3jymv5mhf7aa7v2ncgq5zadd4ye4k", "amount": [ { "denom": "ngonka", "amount": "264732746305" } ] }, { "recipient": "gonka1eheatjgzlu9pulsh7ggsx9gan4sy20ay5ytmvn", "amount": [ { "denom": "ngonka", "amount": "264208241317" } ] }, { "recipient": "gonka1vlk3ck2mkdeehrvr523aq5fz4dmqazyeppy08r", "amount": [ { "denom": "ngonka", "amount": "264161735479" } ] }, { "recipient": "gonka1ewlwawmd4z42daay08hspv45nmzlvffw0ums94", "amount": [ { "denom": "ngonka", "amount": "263088357407" } ] }, { "recipient": "gonka1uvfshcyxnasdt5grn9we9qzl90ryujfkpcarjf", "amount": [ { "denom": "ngonka", "amount": "262854578382" } ] }, { "recipient": "gonka18ee58ff309k3fv2dn9f8zfa9q94huk4ue9y7t4", "amount": [ { "denom": "ngonka", "amount": "261363469059" } ] }, { "recipient": "gonka1lnvyznywq8u2kda780e6h82t6r9nmsuj4j4dp5", "amount": [ { "denom": "ngonka", "amount": "261153730494" } ] }, { "recipient": "gonka13a4v8gxxjav5t4xq5y9cv9d8rfnvkjfw5adqz3", "amount": [ { "denom": "ngonka", "amount": "259477811528" } ] }, { "recipient": "gonka1pf4z32nqz5ax7zsxsmf4tan8wsnp957y9t4qtt", "amount": [ { "denom": "ngonka", "amount": "258408978669" } ] }, { "recipient": "gonka1myfzqktyp8lrdwpymqw5cfyjsr0msa6a3y9c2n", "amount": [ { "denom": "ngonka", "amount": "256716919639" } ] }, { "recipient": "gonka12p7vdr8am7w6yakudrk7l2nqcnka8xqrruejty", "amount": [ { "denom": "ngonka", "amount": "256536328020" } ] }, { "recipient": "gonka1uk73fw4tnfv9rfdeekxycvt0v8cncr64syejra", "amount": [ { "denom": "ngonka", "amount": "256395083588" } ] }, { "recipient": "gonka14m522cfm77emja0fnd0y0p9ls74q8kfpxvemsq", "amount": [ { "denom": "ngonka", "amount": "254971732952" } ] }, { "recipient": "gonka10y0j44g5zae0kep8xmgv8upl7p6dcurnl72m5n", "amount": [ { "denom": "ngonka", "amount": "250313363132" } ] }, { "recipient": "gonka1p57jas3hm3gmdvh64z92ycr28z968j0fn6n6jd", "amount": [ { "denom": "ngonka", "amount": "249620064759" } ] }, { "recipient": "gonka1l2pah3qf2jgdw50lzm6hpt352fsccthmrz57ms", "amount": [ { "denom": "ngonka", "amount": "249348523620" } ] }, { "recipient": "gonka1pts20pjtryksdxp9lvydk9vvs8mmd9ruzqgu4z", "amount": [ { "denom": "ngonka", "amount": "248032627366" } ] }, { "recipient": "gonka1a333gjgcsen6wkg0m5j7vnyw3paz8e598pfsev", "amount": [ { "denom": "ngonka", "amount": "247131413356" } ] }, { "recipient": "gonka1fpkw6p595r2npvtx6l02tmtggwlkz0s7ns7xev", "amount": [ { "denom": "ngonka", "amount": "246941799835" } ] }, { "recipient": "gonka1p2fj0vx4kpx3tdm7u853v9q67n9frrcmttxrqy", "amount": [ { "denom": "ngonka", "amount": "246560012735" } ] }, { "recipient": "gonka14xc7cn3n2zvnw3a5zh3p0827hw9hruqfze62e8", "amount": [ { "denom": "ngonka", "amount": "246508658850" } ] }, { "recipient": "gonka1ldzl4gaalctyfwupak25avzvu0s29zjvayne49", "amount": [ { "denom": "ngonka", "amount": "243351881717" } ] }, { "recipient": "gonka1m2s8r88lj40thm3zkd0fc92sqk6wswhx8a2xyh", "amount": [ { "denom": "ngonka", "amount": "240542872784" } ] }, { "recipient": "gonka1p92n7yphf8eqcygcwkpvgggt7d9ql69mchllcr", "amount": [ { "denom": "ngonka", "amount": "240217006117" } ] }, { "recipient": "gonka1jpg0ct9h272lefy99w4sgd2ul9ukvzwhfanvn0", "amount": [ { "denom": "ngonka", "amount": "240216332176" } ] }, { "recipient": "gonka1adz6e58nz8k79fsg3hxq2sg6thym2l073hyyh9", "amount": [ { "denom": "ngonka", "amount": "239700513689" } ] }, { "recipient": "gonka16tru27h865g77cfhsyfpepcjlqlgavl4dc0a0t", "amount": [ { "denom": "ngonka", "amount": "239693182441" } ] }, { "recipient": "gonka1lnynt0wfxhn049m7mjg7kpxcklspwz6ngw0rsv", "amount": [ { "denom": "ngonka", "amount": "239434096502" } ] }, { "recipient": "gonka1kyrhxw6frcjk4hh8rdeswxftwxuxwgphxnk8kk", "amount": [ { "denom": "ngonka", "amount": "238833085068" } ] }, { "recipient": "gonka1mhhq8ky8czhny7wk3sk9uquwn43twd4emksh3e", "amount": [ { "denom": "ngonka", "amount": "237989906345" } ] }, { "recipient": "gonka13nftxrmqx9hum0ajmweyqqpclkgge6wgp33ms3", "amount": [ { "denom": "ngonka", "amount": "236763437310" } ] }, { "recipient": "gonka1q6v5taltnxxzjrgpheu5t7pfjwmsu6x8gs24sw", "amount": [ { "denom": "ngonka", "amount": "235788952207" } ] }, { "recipient": "gonka13z9nw50phzh9sesempfam6prrgzz9c43n7hl0f", "amount": [ { "denom": "ngonka", "amount": "234860999377" } ] }, { "recipient": "gonka1rvuym8r7kmage5jw8jnzxyephcvelkaerzqumx", "amount": [ { "denom": "ngonka", "amount": "234562856172" } ] }, { "recipient": "gonka10k27r58herdqs3m4c6vyjlc2jsxnpjy2x73zgc", "amount": [ { "denom": "ngonka", "amount": "234423646081" } ] }, { "recipient": "gonka1sptzpk2tlxv958s22nu0juamt09hkcrhrrhx5l", "amount": [ { "denom": "ngonka", "amount": "233442651437" } ] }, { "recipient": "gonka13l0e92dedmwm0a2zcxnctvqlcl2tw7hhkdmsnx", "amount": [ { "denom": "ngonka", "amount": "232321910249" } ] }, { "recipient": "gonka138xt5y8kyzg6lcjva8vqyz9av9shhyz6e6nv39", "amount": [ { "denom": "ngonka", "amount": "231917217521" } ] }, { "recipient": "gonka1663gc0f8f6fdylzk9m9akxjjfvj8f9n94nhvnu", "amount": [ { "denom": "ngonka", "amount": "231917217521" } ] }, { "recipient": "gonka1ad56r73l5z92x9f3qe7e52q0jckmg9ytmghp87", "amount": [ { "denom": "ngonka", "amount": "227878307385" } ] }, { "recipient": "gonka1tl5m3vuqsx333v7095ymwjdc4vdk2wd9r5hqws", "amount": [ { "denom": "ngonka", "amount": "224016160981" } ] }, { "recipient": "gonka1as0kls7e88q6ull9t2gyhe5zk9utzaezwml9kt", "amount": [ { "denom": "ngonka", "amount": "223384429920" } ] }, { "recipient": "gonka1pu7h5ntzt94ptwr5y5nctfjvpfd0hclqspcryl", "amount": [ { "denom": "ngonka", "amount": "223117695596" } ] }, { "recipient": "gonka1p7ze99aywsyudnn38wrxjsgzhmcu64swe9zmua", "amount": [ { "denom": "ngonka", "amount": "220252368742" } ] }, { "recipient": "gonka1j3m7rwdjrf44xy8p7ff4w3srqxaml0f73x09ud", "amount": [ { "denom": "ngonka", "amount": "218704613298" } ] }, { "recipient": "gonka1mqf4hr9a68zf78gcjkxmkz6nkzp76d0nqea9sv", "amount": [ { "denom": "ngonka", "amount": "218463578010" } ] }, { "recipient": "gonka192gv4k5kh88g5s9xll8k7w065lz0rjwh7zj55v", "amount": [ { "denom": "ngonka", "amount": "217527398702" } ] }, { "recipient": "gonka1gd79gdm2s35rc4mhssgwrqh2lnmaff0wq4mwq6", "amount": [ { "denom": "ngonka", "amount": "214679298921" } ] }, { "recipient": "gonka1tl6wzyuvf8t32ny8deqdz4kufle6fq0k72cy8j", "amount": [ { "denom": "ngonka", "amount": "212901999312" } ] }, { "recipient": "gonka166wgzjsx5hm4cxc58uc42watkgcppgv80yts48", "amount": [ { "denom": "ngonka", "amount": "212573545475" } ] }, { "recipient": "gonka14jxtac6gra9cc97q7gw6el2l7f2v2d32f8973x", "amount": [ { "denom": "ngonka", "amount": "212467763300" } ] }, { "recipient": "gonka17fcahf38xh8ghzyyrc55tarz9nd0vw6xd29nsk", "amount": [ { "denom": "ngonka", "amount": "212248188434" } ] }, { "recipient": "gonka14p0njxtlnx2c8zn570nvvaf730gnnkwvetlwj8", "amount": [ { "denom": "ngonka", "amount": "211609774624" } ] }, { "recipient": "gonka1zv89w02sdfzwy74s9vcthk38dnfsw36s4h7s93", "amount": [ { "denom": "ngonka", "amount": "210396399071" } ] }, { "recipient": "gonka1a6jjdd2ufn7x5qpp56627pk40sneqwyl989444", "amount": [ { "denom": "ngonka", "amount": "209535834916" } ] }, { "recipient": "gonka14flzeq3mc2qh4h8senj5glhrtsknln6ugkhm3x", "amount": [ { "denom": "ngonka", "amount": "209188155802" } ] }, { "recipient": "gonka1lrn7dux37jx6f9nqnh8mfrx2d0p4npw8xnjpxn", "amount": [ { "denom": "ngonka", "amount": "208871586849" } ] }, { "recipient": "gonka1399mlkshf3drn67zqm7vsc6na9a96t55jrhjeu", "amount": [ { "denom": "ngonka", "amount": "208341539624" } ] }, { "recipient": "gonka1rqfj7selleh544mstj7quwmqned0wm2trpe9wu", "amount": [ { "denom": "ngonka", "amount": "206171996533" } ] }, { "recipient": "gonka1su7xfxq7a6dalv38gujj5tz5urkmw0044vush0", "amount": [ { "denom": "ngonka", "amount": "204906813326" } ] }, { "recipient": "gonka1mecj5za64q5cnuu3vaey88g7kn996h2lv8aylu", "amount": [ { "denom": "ngonka", "amount": "204341940016" } ] }, { "recipient": "gonka1umjryvc7nyl6w44u8mrrqwffv3mnk0xftx74er", "amount": [ { "denom": "ngonka", "amount": "204112867833" } ] }, { "recipient": "gonka1qyw37eedekdrhu9937k2ewvh5ql99qlmsv3nj4", "amount": [ { "denom": "ngonka", "amount": "203997831326" } ] }, { "recipient": "gonka1lzp3eyygk2zttc52r6jnfugdr76eq3mnqyl8hp", "amount": [ { "denom": "ngonka", "amount": "202116870034" } ] }, { "recipient": "gonka1pnfyj6kw3h3v2qu60j42j8h3cuf3jpqqgnaet7", "amount": [ { "denom": "ngonka", "amount": "201720882778" } ] }, { "recipient": "gonka1ukxf7quyy8qsz3gy2crtlzh5qfptd2awzs3a4k", "amount": [ { "denom": "ngonka", "amount": "198376817068" } ] }, { "recipient": "gonka13dyaa9jucv4r06a5nf2nsz27mwdr0ttfpzxx3f", "amount": [ { "denom": "ngonka", "amount": "194440591844" } ] }, { "recipient": "gonka1my88wstqm2e795srgpxzat60z5hy0p7a85ytpk", "amount": [ { "denom": "ngonka", "amount": "192759389776" } ] }, { "recipient": "gonka15e2swr409v3c4ydpq9ahsn3zuqxyj47axn3lf0", "amount": [ { "denom": "ngonka", "amount": "192684097628" } ] }, { "recipient": "gonka1pucvx8mx0nux5gcd2wgfyg9mwkaaqaqplw674l", "amount": [ { "denom": "ngonka", "amount": "188014787856" } ] }, { "recipient": "gonka1gt0406jz45mjt0jujqtfd3m9lcyah93t0wj084", "amount": [ { "denom": "ngonka", "amount": "184115258724" } ] }, { "recipient": "gonka1k53k8vfzg4vg88vp9anh84ykzwdw4nzqppll97", "amount": [ { "denom": "ngonka", "amount": "181381921472" } ] }, { "recipient": "gonka14vp3katk6685avqjxhwrn6cckrpgjrf5vjz8jm", "amount": [ { "denom": "ngonka", "amount": "176880182563" } ] }, { "recipient": "gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw", "amount": [ { "denom": "ngonka", "amount": "175555534697" } ] }, { "recipient": "gonka1cpm8uguw5f3vyl3gz7537e3mln47uyzyld57g3", "amount": [ { "denom": "ngonka", "amount": "175238478624" } ] }, { "recipient": "gonka15mh2v944wxk3phxfkegglpgfpq9mjcm6vmpyng", "amount": [ { "denom": "ngonka", "amount": "172060368100" } ] }, { "recipient": "gonka10thh6z0wvq9c05j4z3f9qtpxxedruqn5ae350k", "amount": [ { "denom": "ngonka", "amount": "171896958330" } ] }, { "recipient": "gonka1ch7hgwuc2ld0fvp305fkqn2ff38qek8cyls4ww", "amount": [ { "denom": "ngonka", "amount": "171757160407" } ] }, { "recipient": "gonka139l5ttdauzdt8hfd43yfrwv97df547spjslnpe", "amount": [ { "denom": "ngonka", "amount": "171401905152" } ] }, { "recipient": "gonka13nuzs6xh6rygx7w3vhtfgadt4vvn0lgfmyd4pt", "amount": [ { "denom": "ngonka", "amount": "171010486577" } ] }, { "recipient": "gonka1xjdmt0s2dy5juxh0uhct3lye94xdmf4ku528sh", "amount": [ { "denom": "ngonka", "amount": "170817573835" } ] }, { "recipient": "gonka145qtr0h90fvz88klshvl4r4htw4thdgcvpey3g", "amount": [ { "denom": "ngonka", "amount": "170468417948" } ] }, { "recipient": "gonka12s6rzcvuq4mc3rl6dm9n3j609vm3pp39vwhuk6", "amount": [ { "denom": "ngonka", "amount": "168900273074" } ] }, { "recipient": "gonka15ekp90x056vsuw37za6vt9p54r6kr7pr76hyyd", "amount": [ { "denom": "ngonka", "amount": "168502394988" } ] }, { "recipient": "gonka1nykx6u9qklnq7nkqm0px2nwthu4hzfkhejcrze", "amount": [ { "denom": "ngonka", "amount": "166874432859" } ] }, { "recipient": "gonka1zaup3ecnckjvmyqfnfdjj6jn3hsazqt3zjsexv", "amount": [ { "denom": "ngonka", "amount": "166331047284" } ] }, { "recipient": "gonka1cckj93kp9kegry64scpn4ew9965g3qrswyshl9", "amount": [ { "denom": "ngonka", "amount": "165813241052" } ] }, { "recipient": "gonka1dtnru3j85vee0vm20vkvd256nfd9t7jzuvnd27", "amount": [ { "denom": "ngonka", "amount": "165570544195" } ] }, { "recipient": "gonka18n9rq8q9gq0guvrm2mzk7hd2hvtf6cf6k6ul44", "amount": [ { "denom": "ngonka", "amount": "164645713730" } ] }, { "recipient": "gonka1uwf8ce2knja6az8x6l2fawxh0yx0pz68n7pk7c", "amount": [ { "denom": "ngonka", "amount": "161957022779" } ] }, { "recipient": "gonka1aumu6ctfvp6hdccmcvrhrz8ete926zleyhacr5", "amount": [ { "denom": "ngonka", "amount": "161849926896" } ] }, { "recipient": "gonka1hhtht6rssq5hy22r7kyrrtkglvslxtkqt5yau8", "amount": [ { "denom": "ngonka", "amount": "160968782293" } ] }, { "recipient": "gonka1fh58x94xd6rdqz599svj9ftdt9rckg6ggxvn3p", "amount": [ { "denom": "ngonka", "amount": "159981237348" } ] }, { "recipient": "gonka18jmc50as0esg8sf4ylkxhxftvwe2xm4fvw87s7", "amount": [ { "denom": "ngonka", "amount": "158802073834" } ] }, { "recipient": "gonka1kysyccuws3hl7ul2e9kfftanevvsskf5jtjfr2", "amount": [ { "denom": "ngonka", "amount": "158644782785" } ] }, { "recipient": "gonka1n57qkc9umnqu4whuy7rse9gx09f9m470wq9f2u", "amount": [ { "denom": "ngonka", "amount": "158346504252" } ] }, { "recipient": "gonka19kue8dlczfr0vl94tta3l9k5s08hwuu0zd5ewv", "amount": [ { "denom": "ngonka", "amount": "157578607135" } ] }, { "recipient": "gonka1730jjs2rhajxp434m6syr4uwemqfw3d9dkdvje", "amount": [ { "denom": "ngonka", "amount": "157245995276" } ] }, { "recipient": "gonka172eahn496yyps4fap74fv4y843n4ghl43atmkk", "amount": [ { "denom": "ngonka", "amount": "156516180131" } ] }, { "recipient": "gonka1cm5hykwz4vygmmvv6uf3jhxtg2dnt56799p3d7", "amount": [ { "denom": "ngonka", "amount": "156182631825" } ] }, { "recipient": "gonka1dutrpxzkvnjqt75yqwlszkeegujsuprdu9vr8g", "amount": [ { "denom": "ngonka", "amount": "155651458202" } ] }, { "recipient": "gonka1kpj3zlnu9cj94nyraaxk4jcmqddvhnxzacjmg9", "amount": [ { "denom": "ngonka", "amount": "154202832584" } ] }, { "recipient": "gonka18fgyw8c7deqkk4zq8n9efgrwjjypdrd7cskv48", "amount": [ { "denom": "ngonka", "amount": "154076603835" } ] }, { "recipient": "gonka1w0fj4kscwkru05vgq4pk3xwdf6dq63emw7etw6", "amount": [ { "denom": "ngonka", "amount": "153903941571" } ] }, { "recipient": "gonka1yysfdney9ayqhgd8e03zdkhqte3pr09zzevdrq", "amount": [ { "denom": "ngonka", "amount": "153058195413" } ] }, { "recipient": "gonka183y38fjefqfgxafe05fw24rjtj4elzy84wxwdl", "amount": [ { "denom": "ngonka", "amount": "152807764227" } ] }, { "recipient": "gonka1e2wq9deve5zk6znff34c0x9xdklt0qs6u43x4x", "amount": [ { "denom": "ngonka", "amount": "152046448413" } ] }, { "recipient": "gonka1h60zhqxm8c40aupf2fwjd8uxlzsle9n55jmzn2", "amount": [ { "denom": "ngonka", "amount": "151958899171" } ] }, { "recipient": "gonka1az2ancd696ewym33xvskz0pznqxdv6ya2ljy84", "amount": [ { "denom": "ngonka", "amount": "151932993107" } ] }, { "recipient": "gonka1f9w9z55f4spuhwus5ksc86ynd9t4fxyphlkkvf", "amount": [ { "denom": "ngonka", "amount": "151779181849" } ] }, { "recipient": "gonka10rvvl89yply8d5rks5k0674fadat45e3gvtau5", "amount": [ { "denom": "ngonka", "amount": "150902484619" } ] }, { "recipient": "gonka10jrlgh9yege62d3wnytkgamdgjyqs9xpjxm32n", "amount": [ { "denom": "ngonka", "amount": "149737865560" } ] }, { "recipient": "gonka1ev28hzcw4tduvnuk0avlckq33cusgf3n3gr76k", "amount": [ { "denom": "ngonka", "amount": "147757474732" } ] }, { "recipient": "gonka1h4e7j4h5jy8dac8sjqke2pckvv6eva5ec2v0jv", "amount": [ { "denom": "ngonka", "amount": "146849951021" } ] }, { "recipient": "gonka19ne8zk9j5xk50zvwcpwyeyl2wn72xmwkfycnse", "amount": [ { "denom": "ngonka", "amount": "145209327994" } ] }, { "recipient": "gonka13e5a0f67nzmvcdt27c083np9wlmqz2sjexnh4g", "amount": [ { "denom": "ngonka", "amount": "144573220781" } ] }, { "recipient": "gonka17339jstnve8h7mzms493x9twwznadymtvj7vjt", "amount": [ { "denom": "ngonka", "amount": "143413498930" } ] }, { "recipient": "gonka1ut2pkphww74zzeyadhs7u7s6k9rrcmfrnzd6y6", "amount": [ { "denom": "ngonka", "amount": "142805232382" } ] }, { "recipient": "gonka1vtz94uthrqn93rcf2yn4hpuj2q6pqkhh632j6s", "amount": [ { "denom": "ngonka", "amount": "142284804161" } ] }, { "recipient": "gonka15natyl5kwtzta9lr0xeqmew3j5thza2lslvw4x", "amount": [ { "denom": "ngonka", "amount": "140802844450" } ] }, { "recipient": "gonka1hk6css6jcxwcjnft04fwmnww67u8kuw0865gv3", "amount": [ { "denom": "ngonka", "amount": "139111306692" } ] }, { "recipient": "gonka12c8m72s7g8mudeaa440tpkafs973vjhllv3fuc", "amount": [ { "denom": "ngonka", "amount": "138036035184" } ] }, { "recipient": "gonka1dc2utw2lm4ucr8q7r6wthglfsrck49z7rqdv2f", "amount": [ { "denom": "ngonka", "amount": "137272425110" } ] }, { "recipient": "gonka1r9zaxcvn5rysp09hrlla6k8ltssuhtpl07wtqu", "amount": [ { "denom": "ngonka", "amount": "137067051773" } ] }, { "recipient": "gonka1lzxwqhc5fqwltg57emk2lprd7qzmapp22mv0h7", "amount": [ { "denom": "ngonka", "amount": "136134900662" } ] }, { "recipient": "gonka1y9vw8ejeknw5h5n0tunzxffjh33rdn5tddhaud", "amount": [ { "denom": "ngonka", "amount": "136074117621" } ] }, { "recipient": "gonka1w0tk2ghwtgd9l4xakrgvrugcc9rptwpg2z33a2", "amount": [ { "denom": "ngonka", "amount": "135421921802" } ] }, { "recipient": "gonka17h7crvknkw8er5cuc43dgdp8eh974s5hahauuq", "amount": [ { "denom": "ngonka", "amount": "134798235437" } ] }, { "recipient": "gonka19zywrpdzxws82hpqsw2addmlkwkfwwcm805djx", "amount": [ { "denom": "ngonka", "amount": "134784519739" } ] }, { "recipient": "gonka12wcc34cfzmqu57w96squwnmp9yw32j04s9hss3", "amount": [ { "denom": "ngonka", "amount": "134398933707" } ] }, { "recipient": "gonka1k7u2vdwaljgcvhkn8nftxq3ffj6zzq09cw0shq", "amount": [ { "denom": "ngonka", "amount": "134388658518" } ] }, { "recipient": "gonka1um9kz95phrhe439rent9q9ld3huvdcy5jf6t0x", "amount": [ { "denom": "ngonka", "amount": "133426507127" } ] }, { "recipient": "gonka13r5m25jc0q69d9mjzhjfdzdu3t24n5te793l4x", "amount": [ { "denom": "ngonka", "amount": "133343103856" } ] }, { "recipient": "gonka15z2fxrrxx7cwk4j7vp98rat7ajfpjxrqevyp0s", "amount": [ { "denom": "ngonka", "amount": "132724968024" } ] }, { "recipient": "gonka14wp5g2auyarncnwk6ufl8stmyrlgzx0l0d3f80", "amount": [ { "denom": "ngonka", "amount": "132673212651" } ] }, { "recipient": "gonka1maujm456qnv250gfydngd8dhf7yh356ca3h5pv", "amount": [ { "denom": "ngonka", "amount": "132364393420" } ] }, { "recipient": "gonka15s3uh8xyla66mx86hknjs6rrq740e5dtc6guga", "amount": [ { "denom": "ngonka", "amount": "132038508775" } ] }, { "recipient": "gonka1pzdzdgd3auppy7x8a73suxaucgjcutfevrwzjp", "amount": [ { "denom": "ngonka", "amount": "131528255395" } ] }, { "recipient": "gonka1laltt78qucmexcplsm9t99un7h2329vmdhrc62", "amount": [ { "denom": "ngonka", "amount": "131494563463" } ] }, { "recipient": "gonka1ctgxkaut4gdsj5rv3eru275df0t606jav0exfd", "amount": [ { "denom": "ngonka", "amount": "131210890946" } ] }, { "recipient": "gonka1rpedugp4rhy989wfg8tr5ux7k6d4fhkjlqk234", "amount": [ { "denom": "ngonka", "amount": "131165213697" } ] }, { "recipient": "gonka1z9wz95l4eu2ltwvavy4m7w5qjvyac3ktt5zhs2", "amount": [ { "denom": "ngonka", "amount": "130951300105" } ] }, { "recipient": "gonka18cy6n7f3ceu97uxe5xqtr0ndww55wmmahg330r", "amount": [ { "denom": "ngonka", "amount": "130759784369" } ] }, { "recipient": "gonka1d5v93rmxuramndpmcsxvum6e5snznkw90nedha", "amount": [ { "denom": "ngonka", "amount": "130371958274" } ] }, { "recipient": "gonka1qpz3622ewmu42cu0l9gelga7wyet57m4pllwc9", "amount": [ { "denom": "ngonka", "amount": "130192901188" } ] }, { "recipient": "gonka1rk43zfsxe7tefa88qh3t7wl3dvjwn3hq22njc4", "amount": [ { "denom": "ngonka", "amount": "129962381233" } ] }, { "recipient": "gonka1nlp2g4ze3799z6xqvsjqqkqn746mtjs7t6v7kc", "amount": [ { "denom": "ngonka", "amount": "129920348863" } ] }, { "recipient": "gonka1270mrwh27pgnrtmmsmyy5rsq2h8ug6l4zvg4cu", "amount": [ { "denom": "ngonka", "amount": "129781359391" } ] }, { "recipient": "gonka1cjvdez8e6mwjxg0e3g7rrds9ezm9c7kemlu3g7", "amount": [ { "denom": "ngonka", "amount": "129659729868" } ] }, { "recipient": "gonka16de96xdt4dqfjslenvu6pwd9y96n5scqqq9sy9", "amount": [ { "denom": "ngonka", "amount": "129484936698" } ] }, { "recipient": "gonka10fvaz7sgva6563fkcp9wxlk5hz7gj8fmu0w699", "amount": [ { "denom": "ngonka", "amount": "129266291194" } ] }, { "recipient": "gonka1pmxhj3vqv0uq5l4nvdeky4lpjyryw3fg24ste8", "amount": [ { "denom": "ngonka", "amount": "127476065003" } ] }, { "recipient": "gonka16324l7r5jllqjm7e5wlf2h44cr3dsmjj8a6py7", "amount": [ { "denom": "ngonka", "amount": "127316042720" } ] }, { "recipient": "gonka17w5kpa57jtqnqy7wdp5d03jkjmk0vjwdpp5xmg", "amount": [ { "denom": "ngonka", "amount": "127306159205" } ] }, { "recipient": "gonka1fwjwxw6cvspwautdrhr2jf4mfayy074t5npwnx", "amount": [ { "denom": "ngonka", "amount": "126899324556" } ] }, { "recipient": "gonka1f4mcr5pzn9rtdyzdv9dfg4x47vrqxk0f2ujqs7", "amount": [ { "denom": "ngonka", "amount": "126046910212" } ] }, { "recipient": "gonka1ky9mpdps70l9fe59dg7a7ctnaunkuuc8uet8q2", "amount": [ { "denom": "ngonka", "amount": "126035998095" } ] }, { "recipient": "gonka1z6va0ch94wqltysk7hc6zd6qjp0wddayrw2hua", "amount": [ { "denom": "ngonka", "amount": "124756655528" } ] }, { "recipient": "gonka1qu9mna5xlvlnw9455ygtjq92wuzkzm237w8l08", "amount": [ { "denom": "ngonka", "amount": "124587196777" } ] }, { "recipient": "gonka1ays6epuyqejjj0fxgj9lx9mxv42q3ac64y28sp", "amount": [ { "denom": "ngonka", "amount": "124090764074" } ] }, { "recipient": "gonka16sfwtnse80aleg7sgmumnu3qxhtf93mf86479a", "amount": [ { "denom": "ngonka", "amount": "124064035159" } ] }, { "recipient": "gonka1wdcy2gdq7kfj9e0y3g0gtjl2cjdtqep3s8r5dk", "amount": [ { "denom": "ngonka", "amount": "123629210589" } ] }, { "recipient": "gonka1w5vse5uanra5uvkgzwf6mx2ltrev0tvpnx72g3", "amount": [ { "denom": "ngonka", "amount": "123282336551" } ] }, { "recipient": "gonka1qlwcwa7nppc0ng5qccwm3g0t0knkf5nmr036vc", "amount": [ { "denom": "ngonka", "amount": "123151176825" } ] }, { "recipient": "gonka1rt963v04mgt43ju2smuakde99pv7wscy5yxnte", "amount": [ { "denom": "ngonka", "amount": "123101315702" } ] }, { "recipient": "gonka1jcxsgcnctv69xd9v35qy45m45pg3wwhn0f8pl2", "amount": [ { "denom": "ngonka", "amount": "122771515329" } ] }, { "recipient": "gonka10arv470cmu80mlz3wtrkk0xt93lxy62mqzyfdf", "amount": [ { "denom": "ngonka", "amount": "122241510732" } ] }, { "recipient": "gonka15y9q9je0hs0uhq39v37g9yprhxhj8rqu5cqc58", "amount": [ { "denom": "ngonka", "amount": "121891963143" } ] }, { "recipient": "gonka15phrun9xzcm2f9vz7lfef9yj26xjhte9jl2jvc", "amount": [ { "denom": "ngonka", "amount": "121106135330" } ] }, { "recipient": "gonka1pjpkm3plwgr3h7jemjxtvfeqypnzemussthdvz", "amount": [ { "denom": "ngonka", "amount": "120561777639" } ] }, { "recipient": "gonka1guvvfsnjfxa573k5f8tc0wam0h4hhcfldlyky5", "amount": [ { "denom": "ngonka", "amount": "119869867063" } ] }, { "recipient": "gonka13u2c48f45umqvmdpfrfxdt9xcu8erd044wpwdg", "amount": [ { "denom": "ngonka", "amount": "119768896713" } ] }, { "recipient": "gonka123fment8nj6mrekwv9rh5zmevxjd7t05c8azrd", "amount": [ { "denom": "ngonka", "amount": "119320259600" } ] }, { "recipient": "gonka1snurcwfvugkldrtr8pmdnpaugf9khcp073sfzz", "amount": [ { "denom": "ngonka", "amount": "118967130447" } ] }, { "recipient": "gonka1fs4fapsf05qf3992m92ac3cl38uzh56vev4806", "amount": [ { "denom": "ngonka", "amount": "118301931963" } ] }, { "recipient": "gonka1rre47ll99hmea7eselqcmmnh5xncqyx0jlvylh", "amount": [ { "denom": "ngonka", "amount": "116853501225" } ] }, { "recipient": "gonka103tuctlftrr5zzc2vgmu86vw4u6pus9wxnm8a4", "amount": [ { "denom": "ngonka", "amount": "115732147820" } ] }, { "recipient": "gonka1lm0jdqg6v2m5hekyh7ul039sqnlhjc8qw50yq4", "amount": [ { "denom": "ngonka", "amount": "115440034138" } ] }, { "recipient": "gonka1895n7u9np4s675vhksellqkpkqxk5xkv4upaxr", "amount": [ { "denom": "ngonka", "amount": "115354023876" } ] }, { "recipient": "gonka1vrrsqx454f04dmadju83dps8742lh0klrjq05n", "amount": [ { "denom": "ngonka", "amount": "114565133254" } ] }, { "recipient": "gonka185kgdje9wjucxtkdu0nqhpqlwxutc5kc7nss8u", "amount": [ { "denom": "ngonka", "amount": "114359358092" } ] }, { "recipient": "gonka1hdm8wlf8e07e692ezay5g8qyemks4242g7kr9d", "amount": [ { "denom": "ngonka", "amount": "113839791894" } ] }, { "recipient": "gonka13kd0e5393704ummmwf7pqvphlm5qsqdpe3kal2", "amount": [ { "denom": "ngonka", "amount": "113627417363" } ] }, { "recipient": "gonka1gd74wnjdp0sjxf5slgtwqx4t7pphvwl9qak360", "amount": [ { "denom": "ngonka", "amount": "113514953117" } ] }, { "recipient": "gonka14mn57n7sq2mcf5mm2399fmqrgujwgxlec970ar", "amount": [ { "denom": "ngonka", "amount": "111531052020" } ] }, { "recipient": "gonka1jfr0hq4k5lfzu7h2qsvh8dppard9t7lndsrngp", "amount": [ { "denom": "ngonka", "amount": "108753172219" } ] }, { "recipient": "gonka1jcut7ms9l432y90exzpfz5835p04lrzpndtdfl", "amount": [ { "denom": "ngonka", "amount": "108690771987" } ] }, { "recipient": "gonka13mehzn6a86z7mkf0fcked5y2644r7hnq2txxpa", "amount": [ { "denom": "ngonka", "amount": "106795222668" } ] }, { "recipient": "gonka1q35556zp34twsnaa4uk6300zjcn3f6ucpawtf2", "amount": [ { "denom": "ngonka", "amount": "106715637183" } ] }, { "recipient": "gonka1hzcmnax508hhtudrxpk52djg9nkl5cpxflz2uk", "amount": [ { "denom": "ngonka", "amount": "106522545672" } ] }, { "recipient": "gonka19rd75sm0zeh2cmnepmg79ffn00jtpsdw2zj495", "amount": [ { "denom": "ngonka", "amount": "104746067502" } ] }, { "recipient": "gonka1rrmf3s6m7rh3plqn0xam5c38xsl9wwvrtjzr48", "amount": [ { "denom": "ngonka", "amount": "104693626058" } ] }, { "recipient": "gonka1r4vqtz3mhhxzk83693xy8lt3rey5u9l7w809jd", "amount": [ { "denom": "ngonka", "amount": "104509634423" } ] }, { "recipient": "gonka1mjtqjukfgjlzg82tz3s4pwna06kan7zmhysfqd", "amount": [ { "denom": "ngonka", "amount": "104122884934" } ] }, { "recipient": "gonka17d3y8a0meyn4ql7a9rk5c24dlx0kke0lvt9ndz", "amount": [ { "denom": "ngonka", "amount": "104058765553" } ] }, { "recipient": "gonka1ppvjh3l2q0rrz7hz86uaywzzn44edqqcwstplg", "amount": [ { "denom": "ngonka", "amount": "103288987878" } ] }, { "recipient": "gonka1pd4qf3clxgtc4nu5q0nltwugc49ukl2laep5xx", "amount": [ { "denom": "ngonka", "amount": "103143431572" } ] }, { "recipient": "gonka12p5ausvgfg5m9d8t47pvm4j7wd0vzfflv7s88n", "amount": [ { "denom": "ngonka", "amount": "103118913038" } ] }, { "recipient": "gonka1td0msg9jesqsk8k3wnu32zpg9femfgtaazmt23", "amount": [ { "denom": "ngonka", "amount": "103108880731" } ] }, { "recipient": "gonka1dzk7rawvnkfwfptkzhdf7dh5s4xsqfml72tmcy", "amount": [ { "denom": "ngonka", "amount": "101825659644" } ] }, { "recipient": "gonka12634qjw29fmhf3yw7rlcgf8mldl56r2ufqk8rc", "amount": [ { "denom": "ngonka", "amount": "101800864877" } ] }, { "recipient": "gonka1jpr8eqt329k8en46lldxr8hlkmqeaugnhl5yf6", "amount": [ { "denom": "ngonka", "amount": "101610655231" } ] }, { "recipient": "gonka1wpz5sgkjwhkh9py26rp3zlefgc9sc673gkncmk", "amount": [ { "denom": "ngonka", "amount": "101335290873" } ] }, { "recipient": "gonka1dyhqew6q9xfxx5taqu3purr9nd3e43h5lznqd3", "amount": [ { "denom": "ngonka", "amount": "101007211526" } ] }, { "recipient": "gonka1v0td7x4ndxhveg50vzp6nkz4s25qy2wpvrxm32", "amount": [ { "denom": "ngonka", "amount": "100348368672" } ] }, { "recipient": "gonka12sjs2wwerzfp25y2w9cqpwk9r8z4uddmlt5spw", "amount": [ { "denom": "ngonka", "amount": "100065871270" } ] }, { "recipient": "gonka1jawqmq4lmu8fadddrt0mejfxu5lkrdc02fwuzm", "amount": [ { "denom": "ngonka", "amount": "99394771511" } ] }, { "recipient": "gonka1fyu654mhgdq2fwns2mupuzdtzxjy3k7jwew4rl", "amount": [ { "denom": "ngonka", "amount": "99363059061" } ] }, { "recipient": "gonka1mennxsd8zj44rsmlajyv5ygflke4hqhlpvx36x", "amount": [ { "denom": "ngonka", "amount": "99112729540" } ] }, { "recipient": "gonka1ya8us8ezzpppg5ncy7z0n6e43hn4z268vgqvh5", "amount": [ { "denom": "ngonka", "amount": "99087685606" } ] }, { "recipient": "gonka10ujznhjy9m2chl05dvjhvf525202yz8hwkzsqu", "amount": [ { "denom": "ngonka", "amount": "99080710750" } ] }, { "recipient": "gonka10r5p7vd7sw6tthp0nuld8yajvpgufamrd63epk", "amount": [ { "denom": "ngonka", "amount": "98853788734" } ] }, { "recipient": "gonka1r4qetzmw4g3aenwtcxpdm6l42aeq5gzwqltn39", "amount": [ { "denom": "ngonka", "amount": "98841091076" } ] }, { "recipient": "gonka1ap3tj4grfc000wqyxw8hna7aa96xkd65gfq4fs", "amount": [ { "denom": "ngonka", "amount": "98600587026" } ] }, { "recipient": "gonka1mjjaep4d3vt9myh96zrslx6cet5qr0xvd9zqg3", "amount": [ { "denom": "ngonka", "amount": "98365224243" } ] }, { "recipient": "gonka1zn4ey6xqym4vzr6s8trtu65n9wez648fysxz67", "amount": [ { "denom": "ngonka", "amount": "98152946833" } ] }, { "recipient": "gonka1fujc399fxp9pjrjvd0ymjjk3rzsgl4raq20pg6", "amount": [ { "denom": "ngonka", "amount": "98146886859" } ] }, { "recipient": "gonka14g5nf5z695era59sz6zat5mv7n4w73vp26cgx5", "amount": [ { "denom": "ngonka", "amount": "98046972854" } ] }, { "recipient": "gonka1707yvgk9wgpzrp35wd84mcps4pujelx36n5du9", "amount": [ { "denom": "ngonka", "amount": "97633080910" } ] }, { "recipient": "gonka1ach2c5kms3ds2728a7dlqwsgddftxljsefxd3u", "amount": [ { "denom": "ngonka", "amount": "97318831010" } ] }, { "recipient": "gonka1pdk0x9w50zsym389jlkhp6skdzx480m2p8ymvc", "amount": [ { "denom": "ngonka", "amount": "97288189733" } ] }, { "recipient": "gonka1a8u5zzrmhhdz7hp4gk3lmpltrwq90ley2cn5ef", "amount": [ { "denom": "ngonka", "amount": "96908898986" } ] }, { "recipient": "gonka1mjk8kvkr34vm974s0hmjuanrzv8y4fj3r8fjjm", "amount": [ { "denom": "ngonka", "amount": "96665741850" } ] }, { "recipient": "gonka1djqnccng4mece9p7kpyh588thq6hzt3vk2fmln", "amount": [ { "denom": "ngonka", "amount": "96631310149" } ] }, { "recipient": "gonka1v765pascdp3v6qqtpdrcqm8qwdwq4hxa85gu5z", "amount": [ { "denom": "ngonka", "amount": "96463736476" } ] }, { "recipient": "gonka1y58p9p64g0hu6uct73qhnpwlgum9t2fjjqmu4j", "amount": [ { "denom": "ngonka", "amount": "96403504140" } ] }, { "recipient": "gonka1gxk3xjg43ryaht8ze0395m7ph4879gmsfd5emu", "amount": [ { "denom": "ngonka", "amount": "96378122086" } ] }, { "recipient": "gonka160q92s7d63d3gtcx5lmdxu92uf8fjqut0v622k", "amount": [ { "denom": "ngonka", "amount": "96131889143" } ] }, { "recipient": "gonka1dmjrdj39n950jzcxqw6zqa7vhtg945gqu5tfhm", "amount": [ { "denom": "ngonka", "amount": "95900252568" } ] }, { "recipient": "gonka16cstfwxnuv08zpyalmv38e48crhe8a9pft7etg", "amount": [ { "denom": "ngonka", "amount": "95852808244" } ] }, { "recipient": "gonka16uc05mvmja22zxgljh6fs82533w805h5ya3nzg", "amount": [ { "denom": "ngonka", "amount": "95099239123" } ] }, { "recipient": "gonka1zepcpcnw6qa45k38muhgavzflelun6rh5hu35k", "amount": [ { "denom": "ngonka", "amount": "94985993363" } ] }, { "recipient": "gonka1zzkxnpq2txntwh5eu49jk67x42yh8wystnkamy", "amount": [ { "denom": "ngonka", "amount": "94948040978" } ] }, { "recipient": "gonka1udx48lyqzrc2ygpkzjq6wthh3ejm6x5cytvxjh", "amount": [ { "denom": "ngonka", "amount": "94914864372" } ] }, { "recipient": "gonka1zhqp9w6nq9sexnew3pg9auqhz85dm86ght6sz0", "amount": [ { "denom": "ngonka", "amount": "94865153257" } ] }, { "recipient": "gonka1xycg2mc0ktaz4372q4ln3f0thefk86shhguk0w", "amount": [ { "denom": "ngonka", "amount": "94740499656" } ] }, { "recipient": "gonka135jr9e2gyzq5lfqvc9tq8n0k3c398dgmmwy835", "amount": [ { "denom": "ngonka", "amount": "94453083418" } ] }, { "recipient": "gonka1rpszx3te4396yyplpl7lmcqngcwtk5vw0t57ym", "amount": [ { "denom": "ngonka", "amount": "94213445288" } ] }, { "recipient": "gonka13qk3jur62xvma480z767lc0ks8c8esc28nxmvt", "amount": [ { "denom": "ngonka", "amount": "94200923689" } ] }, { "recipient": "gonka1h4ajcmsuzuwxx8h9h3vwcn4gr74ld99cxkfux7", "amount": [ { "denom": "ngonka", "amount": "94145274686" } ] }, { "recipient": "gonka1zaklf2yedw6my8lw6vt797vzpn67qeusj5a6zl", "amount": [ { "denom": "ngonka", "amount": "94027646763" } ] }, { "recipient": "gonka1n3xkj998f4q6lf62v7hw7r07jcwaer8xlmjrww", "amount": [ { "denom": "ngonka", "amount": "93814425565" } ] }, { "recipient": "gonka1r9u4nyprt7ym64pdea4a7wpjf446c0zsmphqx9", "amount": [ { "denom": "ngonka", "amount": "93814268546" } ] }, { "recipient": "gonka1jjredx8nvy86dcae5fhpvge0kmamdxx2h7dr9h", "amount": [ { "denom": "ngonka", "amount": "93360669761" } ] }, { "recipient": "gonka1nuhz5kqnmxs3dfd884hdv39kdy2854lff8ma8c", "amount": [ { "denom": "ngonka", "amount": "93139084616" } ] }, { "recipient": "gonka1sn2fuds6qh5dhrdp7afdyepmr6lcpwvsuwzlye", "amount": [ { "denom": "ngonka", "amount": "93076148574" } ] }, { "recipient": "gonka1tvgem50n2xna9apg29wm0ts5rjmjxj0zv23t69", "amount": [ { "denom": "ngonka", "amount": "93040772174" } ] }, { "recipient": "gonka12fnudtsmw6heu6t982rnk8c5lgpgz4wmvwd75s", "amount": [ { "denom": "ngonka", "amount": "92917832759" } ] }, { "recipient": "gonka1fp444xd5027mzhx0tnlxkx6euczhp9glt5f09a", "amount": [ { "denom": "ngonka", "amount": "92870034734" } ] }, { "recipient": "gonka1w0vl46tr786vdtgtk5fyadnsqtl8pyc8cf7txy", "amount": [ { "denom": "ngonka", "amount": "92334898742" } ] }, { "recipient": "gonka1mt6fz28j7rls3psgspaq0xhj862wlklgcat6am", "amount": [ { "denom": "ngonka", "amount": "92230277903" } ] }, { "recipient": "gonka1ylhpz2dd9f6x6apkzr773yw0kaagkhpaph86qn", "amount": [ { "denom": "ngonka", "amount": "92052863940" } ] }, { "recipient": "gonka1r4zuhduduwqzyw4a5y5y5aw57sj9jl56qpp7pk", "amount": [ { "denom": "ngonka", "amount": "92046884335" } ] }, { "recipient": "gonka14ntugumwzhdlkc66qlzczdmfa02fcm4pcldtwz", "amount": [ { "denom": "ngonka", "amount": "91978374358" } ] }, { "recipient": "gonka182wjthlm5zdkwpcc3x5cfy83sel392ljwufsz7", "amount": [ { "denom": "ngonka", "amount": "91796190843" } ] }, { "recipient": "gonka180h3x4dv834pyn2ua3k596hrsk7d2l5utljtg6", "amount": [ { "denom": "ngonka", "amount": "91623762432" } ] }, { "recipient": "gonka14r6ypa2jngcd8pwt22f2nwdhlt2s3cxr4k9xne", "amount": [ { "denom": "ngonka", "amount": "91578702172" } ] }, { "recipient": "gonka12gmwdxjwyqs8y2cxjzrnza8jtf2pyp34udp893", "amount": [ { "denom": "ngonka", "amount": "91160224704" } ] }, { "recipient": "gonka1qfq964gewr83f4vh26qz25hl8na7kmvy93j3el", "amount": [ { "denom": "ngonka", "amount": "90860100796" } ] }, { "recipient": "gonka1p8g3rh58seh553lqywe6rz7ratkm0j4p6kxs3q", "amount": [ { "denom": "ngonka", "amount": "90805078088" } ] }, { "recipient": "gonka1jr3644x2p5j90yl3jpyuvfrp28l37vpvkjq2yx", "amount": [ { "denom": "ngonka", "amount": "90782290218" } ] }, { "recipient": "gonka1ezpg20aga2mv3avkda2zqh5nh8jys9pg0q2cnq", "amount": [ { "denom": "ngonka", "amount": "90775814301" } ] }, { "recipient": "gonka17ftklmd8esnj47nr7dg7c5c6wujvqxqjv03774", "amount": [ { "denom": "ngonka", "amount": "90714808880" } ] }, { "recipient": "gonka1e9vdm8ny7saz4n7yx7hng8hvdj0nu85v4edgnr", "amount": [ { "denom": "ngonka", "amount": "90592471780" } ] }, { "recipient": "gonka124hmlh3500ysl26n25nlfsgnj0hxuvy9cwcrql", "amount": [ { "denom": "ngonka", "amount": "90461276907" } ] }, { "recipient": "gonka18vdcv0y6ms6xgvvvt7mrfnd3drqte5qhwcx9z4", "amount": [ { "denom": "ngonka", "amount": "90171717711" } ] }, { "recipient": "gonka1j6ddjngvwy3x0yze36nks8dvlqdep9fxaj67tv", "amount": [ { "denom": "ngonka", "amount": "89957741125" } ] }, { "recipient": "gonka1wcqxjxzjsfwvaxl3l24qzemjlf0e8nextxhv8j", "amount": [ { "denom": "ngonka", "amount": "89880996129" } ] }, { "recipient": "gonka1a90lj3ks0fg7mxrvqy7dx4g09g72hrlndpmwsj", "amount": [ { "denom": "ngonka", "amount": "89781778806" } ] }, { "recipient": "gonka1hqwgkck88d5wnpea0y9dn0gxmyg4rwjgcnvacf", "amount": [ { "denom": "ngonka", "amount": "89749374453" } ] }, { "recipient": "gonka17mw34tnvce5jg8s2lrn07556guh7yj25dgm4pf", "amount": [ { "denom": "ngonka", "amount": "89631346745" } ] }, { "recipient": "gonka1u7l9jg4krgl8kpu9lc2ml8hscjhmyrgtv6nd2q", "amount": [ { "denom": "ngonka", "amount": "89550533869" } ] }, { "recipient": "gonka1y9vdzmy84uy9c9dgqx8adnusg3ssv7wjmscga8", "amount": [ { "denom": "ngonka", "amount": "89464227627" } ] }, { "recipient": "gonka19gua58wyw5q5r2zqfnzj8srrftk4wy5kewszue", "amount": [ { "denom": "ngonka", "amount": "89249641302" } ] }, { "recipient": "gonka1r2366aa7ql8t9welxtxpjvzwknzpgzkqqssuld", "amount": [ { "denom": "ngonka", "amount": "89171932070" } ] }, { "recipient": "gonka1xspavhncfmlpsllpfajs3r5623a4s8tcumrmwa", "amount": [ { "denom": "ngonka", "amount": "89095259493" } ] }, { "recipient": "gonka18camnxdy5vc2x6752dqter77a0gjjwxg3k5ece", "amount": [ { "denom": "ngonka", "amount": "88361666090" } ] }, { "recipient": "gonka1ts6k67zt064z87rx9hztm93cd3yh5mkqje6z4c", "amount": [ { "denom": "ngonka", "amount": "88233756172" } ] }, { "recipient": "gonka1qcamnqy86hqzcatvlgr78mvgmpcc25ms40pdj2", "amount": [ { "denom": "ngonka", "amount": "88140042305" } ] }, { "recipient": "gonka1ktd5rha9hghm4hzt2eyc8v2p6g66a0zmry07qh", "amount": [ { "denom": "ngonka", "amount": "88100124152" } ] }, { "recipient": "gonka1l5y7amaux93wgd60wn0446h97ezl3vjd6sy025", "amount": [ { "denom": "ngonka", "amount": "87851457797" } ] }, { "recipient": "gonka1eujeuwxcv5skh3pv6njzjcjs53pfafcun307eg", "amount": [ { "denom": "ngonka", "amount": "87631863329" } ] }, { "recipient": "gonka1sycnmyd9rfw0gptt3s604mg9zgpvhg05lgag4m", "amount": [ { "denom": "ngonka", "amount": "87040314540" } ] }, { "recipient": "gonka13fpvt243g8sh87ere5avz74qx5qj7vzesr0p4j", "amount": [ { "denom": "ngonka", "amount": "87031978353" } ] }, { "recipient": "gonka1j6muv0n8023gm7aapthnrf0g3a86w6hg98wgcu", "amount": [ { "denom": "ngonka", "amount": "86957076905" } ] }, { "recipient": "gonka10snluhflqhmwl5xrpuy9ugevypxdjjsft370fq", "amount": [ { "denom": "ngonka", "amount": "86248504694" } ] }, { "recipient": "gonka19h06zf4dmh2qgcdj90cthnw85vpz59cusa72yj", "amount": [ { "denom": "ngonka", "amount": "86082840435" } ] }, { "recipient": "gonka1gxue6uufgvh6dgjexqvsv7ph99k8wkatafymqw", "amount": [ { "denom": "ngonka", "amount": "85650539447" } ] }, { "recipient": "gonka1x27t7qzmphupfz88ysycct97m49z2e27khhsw3", "amount": [ { "denom": "ngonka", "amount": "85580796539" } ] }, { "recipient": "gonka1g6x8ffcysdfju6anvt7we6u2e80fl7pgzjmk99", "amount": [ { "denom": "ngonka", "amount": "85576402054" } ] }, { "recipient": "gonka1m0ftrwltdf7dntqhx9juwgadzyl2h4m3sm77zj", "amount": [ { "denom": "ngonka", "amount": "85261614159" } ] }, { "recipient": "gonka10000627dkz6nvmf09ctqy073v0fls696uznwgg", "amount": [ { "denom": "ngonka", "amount": "85195742182" } ] }, { "recipient": "gonka1xl56zt2c2ahfuk0u68x084avulmth95lptx9cs", "amount": [ { "denom": "ngonka", "amount": "84075875465" } ] }, { "recipient": "gonka1qncqtrf48qrttfwd2s3j42dfnanyvcg6cvwyzs", "amount": [ { "denom": "ngonka", "amount": "83289011476" } ] }, { "recipient": "gonka185kz5j9ur5jczu9wf2vful353vg3eahm77n39x", "amount": [ { "denom": "ngonka", "amount": "82904464621" } ] }, { "recipient": "gonka1rpdnweugm7ykl7hy4p0qe858m9fvkgdm9k5m3g", "amount": [ { "denom": "ngonka", "amount": "82676318325" } ] }, { "recipient": "gonka1x9qndq86jt6x8r5pqx4hlx92rl0x3qu2hn2d3r", "amount": [ { "denom": "ngonka", "amount": "82461286603" } ] }, { "recipient": "gonka1a3qq9jmmhr9xyn8p56v5hzfeuxp9r68suv6uhy", "amount": [ { "denom": "ngonka", "amount": "82204026961" } ] }, { "recipient": "gonka1qc0ygywfl626jmy2ccq9a0swt9zr3p39vf4xwq", "amount": [ { "denom": "ngonka", "amount": "82040544704" } ] }, { "recipient": "gonka1j4pnudv2z7wtfn0l83glqv8x7shtkcustzca40", "amount": [ { "denom": "ngonka", "amount": "81950403605" } ] }, { "recipient": "gonka199lgrq8l9xcqqnr0agajzl78c4dpfvwnsc4elm", "amount": [ { "denom": "ngonka", "amount": "81906401738" } ] }, { "recipient": "gonka1u33ffwp7rswdy9upkxrgq726gk42z8qyqkv3rz", "amount": [ { "denom": "ngonka", "amount": "81393348557" } ] }, { "recipient": "gonka1xccz7s9k0mhys2uuyaqjsnn2wm90uv3lrh7s4r", "amount": [ { "denom": "ngonka", "amount": "81323872273" } ] }, { "recipient": "gonka1lyafw67ys2ft7t4npn7y940696r38kfn9k6xlh", "amount": [ { "denom": "ngonka", "amount": "81313899110" } ] }, { "recipient": "gonka1fnwznrjccpukhe3u5dnqqnr02nhr5hq89jhghs", "amount": [ { "denom": "ngonka", "amount": "81148339233" } ] }, { "recipient": "gonka1l2pu0eqvsah7ap5hy6rdn6dxse37wy6cy4k2ef", "amount": [ { "denom": "ngonka", "amount": "81013936463" } ] }, { "recipient": "gonka1mu29dgr7yx6l3x46c535p2aymzp0hns2fpz5e3", "amount": [ { "denom": "ngonka", "amount": "80695586398" } ] }, { "recipient": "gonka1pq5f5c4k8qn7k73qkzza460y435r3dusaxytys", "amount": [ { "denom": "ngonka", "amount": "80636595060" } ] }, { "recipient": "gonka1auert95hm33pzvzau2pe2ft62krx7d39ypknxm", "amount": [ { "denom": "ngonka", "amount": "80467028178" } ] }, { "recipient": "gonka18wn7au6ezwnswn9jaqhjkf7wa9plrppd0ufz3p", "amount": [ { "denom": "ngonka", "amount": "79811207133" } ] }, { "recipient": "gonka1c3wplss6ju6fc5mhp0dg4lc7lhvkyrvjg28ejl", "amount": [ { "denom": "ngonka", "amount": "79442825338" } ] }, { "recipient": "gonka138qmc42pq75mxf3r3fh9k35ukvj9frmvuc7f0p", "amount": [ { "denom": "ngonka", "amount": "79104869230" } ] }, { "recipient": "gonka17kua4qvnfmedl4atk2e03gjlgm42qxckef6uhw", "amount": [ { "denom": "ngonka", "amount": "78966317577" } ] }, { "recipient": "gonka165pppmxfxxzu4dn33twqwq2rz5cnem2srprlnn", "amount": [ { "denom": "ngonka", "amount": "78501576885" } ] }, { "recipient": "gonka1mhmedjwqt6gsx8urpwehyhud5klxxra2r6cgy5", "amount": [ { "denom": "ngonka", "amount": "78191452363" } ] }, { "recipient": "gonka1ucxu8fuqv5vt8rrwrmt45lkjx5u3e99ajtgv4h", "amount": [ { "denom": "ngonka", "amount": "78024194907" } ] }, { "recipient": "gonka1rz9h38uuyxvfhgh9jrdc8s2gjjcsex36xsvl2l", "amount": [ { "denom": "ngonka", "amount": "77833473263" } ] }, { "recipient": "gonka1g2sspwpvsetwxmwjyp5e4pe2e67clkfpc3sfld", "amount": [ { "denom": "ngonka", "amount": "77383886748" } ] }, { "recipient": "gonka1kadhltjszhue262r7z7khldv90ru8cvy42zv29", "amount": [ { "denom": "ngonka", "amount": "77216401578" } ] }, { "recipient": "gonka1r4cnahcpv6kktwcg795lnqwx5q74fmawsasg75", "amount": [ { "denom": "ngonka", "amount": "76804234728" } ] }, { "recipient": "gonka1qx4f2vzhccv0ndhssfgafvf55xf4smuzjmkvky", "amount": [ { "denom": "ngonka", "amount": "76484009057" } ] }, { "recipient": "gonka149q5us80a94u45uuedufucdmn8ud5xq4de9g9e", "amount": [ { "denom": "ngonka", "amount": "75888387094" } ] }, { "recipient": "gonka1d5nh80xxh7fkf0hmqlxqfq6vls8cq3j0fgg8f3", "amount": [ { "denom": "ngonka", "amount": "75670029934" } ] }, { "recipient": "gonka1tdgnyws5p4ddg2wsg08tmdwggfxpp6e4ev29yc", "amount": [ { "denom": "ngonka", "amount": "75487213864" } ] }, { "recipient": "gonka1gyydhl9lp0udz3409ps0c0lk0y4ft8qcyv8tfq", "amount": [ { "denom": "ngonka", "amount": "74670879328" } ] }, { "recipient": "gonka105fgwnqwd72m685xcalvvsdyzmf59khq607rlx", "amount": [ { "denom": "ngonka", "amount": "74655472026" } ] }, { "recipient": "gonka15nkz4dxslphkty92y0c8m9umule32g9n5e5wvm", "amount": [ { "denom": "ngonka", "amount": "74224656430" } ] }, { "recipient": "gonka16gu0el3h5p572lswsmldyg358apqphcxsdfuq2", "amount": [ { "denom": "ngonka", "amount": "73664304515" } ] }, { "recipient": "gonka1c3jmrfkysvrlgv9av98wlyq4yed3x7uue0wvy2", "amount": [ { "denom": "ngonka", "amount": "73495720908" } ] }, { "recipient": "gonka15rvksn9gxgpszyr8270cd4wj2x3d460r394uv4", "amount": [ { "denom": "ngonka", "amount": "73364273374" } ] }, { "recipient": "gonka1cgf6pmcnkf54rctpgzpx6j32zeut8udm0rr8rf", "amount": [ { "denom": "ngonka", "amount": "73039999876" } ] }, { "recipient": "gonka1psgzz288a434dv6863ldd73xma70zw7387muj2", "amount": [ { "denom": "ngonka", "amount": "72928738056" } ] }, { "recipient": "gonka1ql9asemklpkpr2d4mh33xw5gj0g5tm0v98c5q3", "amount": [ { "denom": "ngonka", "amount": "72928738056" } ] }, { "recipient": "gonka179g6jf5uulrufkhwlymsmwwu93r0j2qvpkdh53", "amount": [ { "denom": "ngonka", "amount": "72432731038" } ] }, { "recipient": "gonka1v9r9a4rnmqqvz3h8fzc72aj80j0pma340f45xk", "amount": [ { "denom": "ngonka", "amount": "71749717564" } ] }, { "recipient": "gonka12chgl62wfzvkvjwj7mz568ct7xyzdaa0ld4d8c", "amount": [ { "denom": "ngonka", "amount": "71580103440" } ] }, { "recipient": "gonka1adacqpq6z6sg9qqsy4f0p02p0sfn2f6n6dldae", "amount": [ { "denom": "ngonka", "amount": "71080597479" } ] }, { "recipient": "gonka13x8n3ttss76js4f86maeck6uey5nklvy6lvdnw", "amount": [ { "denom": "ngonka", "amount": "70873731290" } ] }, { "recipient": "gonka1cnnxxev6yaauzarywk6n6vcs0ej0jygwvff9xz", "amount": [ { "denom": "ngonka", "amount": "70139978358" } ] }, { "recipient": "gonka1thdyumjevc50uf822fzk6ypmychmvsdqu6wnnz", "amount": [ { "denom": "ngonka", "amount": "70006055624" } ] }, { "recipient": "gonka1myknj5jphyt8tlrgzf3zs4a66m4x2httq627sd", "amount": [ { "denom": "ngonka", "amount": "69808784200" } ] }, { "recipient": "gonka10ekkjpyfad6265m2502d4tp3n8yp9n0d7rlzk4", "amount": [ { "denom": "ngonka", "amount": "68295169799" } ] }, { "recipient": "gonka10prje5tj49lek50dpch085f66crl62sut2n0vw", "amount": [ { "denom": "ngonka", "amount": "67445879840" } ] }, { "recipient": "gonka1qhzauckmv78r9wpsr6lvjku5g70hmktgv2ku7d", "amount": [ { "denom": "ngonka", "amount": "66900282591" } ] }, { "recipient": "gonka1cmlns93pn4ddkn9rz4lqcedjacwg6t6vxcdzjk", "amount": [ { "denom": "ngonka", "amount": "66738741782" } ] }, { "recipient": "gonka1rvjfqzm8spt5nfq84jvfdr8we8pgkv8ent08s5", "amount": [ { "denom": "ngonka", "amount": "66694599285" } ] }, { "recipient": "gonka18zgw37evwkpes7redzgh79pjy77rkv5hx4xpz7", "amount": [ { "denom": "ngonka", "amount": "66681318749" } ] }, { "recipient": "gonka1k7qxl4aqv4yu2we32v08wxac6hpuzp9z535sxt", "amount": [ { "denom": "ngonka", "amount": "66666998214" } ] }, { "recipient": "gonka1ggr0m6pm98pdgm9tacqekclaavm6jgqvxespaq", "amount": [ { "denom": "ngonka", "amount": "66088918807" } ] }, { "recipient": "gonka144yh00dcckkpfwr5mv9yz2cpa68c8sw0h3c6cy", "amount": [ { "denom": "ngonka", "amount": "66021237930" } ] }, { "recipient": "gonka1000y038g5sqz6ewnq6f6ktl3xx07fmezc3zrng", "amount": [ { "denom": "ngonka", "amount": "65864614614" } ] }, { "recipient": "gonka18lrgkmk9jawp93ppzd3q2gvldskn6yxn0gpfcx", "amount": [ { "denom": "ngonka", "amount": "65724151752" } ] }, { "recipient": "gonka1nge0x24twxwvran6rh4qe56ckxk3ecmkrjhjf2", "amount": [ { "denom": "ngonka", "amount": "65668418996" } ] }, { "recipient": "gonka13ykzwj2f5zzngs7jl7ywczgestspevqh2vagsj", "amount": [ { "denom": "ngonka", "amount": "65421547215" } ] }, { "recipient": "gonka1nl4vtgr88sy088djkxsknau5fwnx8akh3ppl6d", "amount": [ { "denom": "ngonka", "amount": "64768866083" } ] }, { "recipient": "gonka1h2qxkeglzstqhdmuewyuwdkae0rk3l8wqxwrl5", "amount": [ { "denom": "ngonka", "amount": "64509160547" } ] }, { "recipient": "gonka1strn82prjujtuh0dkpt024a4j49qgf37dq83dn", "amount": [ { "denom": "ngonka", "amount": "64402004004" } ] }, { "recipient": "gonka1rzchltn9xn5ysur4c6x89xvtuuddzccvt8zqrw", "amount": [ { "denom": "ngonka", "amount": "63860517133" } ] }, { "recipient": "gonka1skdtv4vlkwgcnqel2e48vvquhp40mq83m2yjl7", "amount": [ { "denom": "ngonka", "amount": "63742010063" } ] }, { "recipient": "gonka1zmy7dpumv9akvlsqv0n74fyxhhzsmzgjz9rvxf", "amount": [ { "denom": "ngonka", "amount": "63398728288" } ] }, { "recipient": "gonka1uup559m63mjcq6wyewff2su0e2wv5lsyyrcrll", "amount": [ { "denom": "ngonka", "amount": "63352709447" } ] }, { "recipient": "gonka1wma6mrcffqsp9xaunscm2phckdaxj3m25efscu", "amount": [ { "denom": "ngonka", "amount": "63157541543" } ] }, { "recipient": "gonka1edyd5lny4esrc35f6egjukmnfseyyyj4vn54mc", "amount": [ { "denom": "ngonka", "amount": "62630134385" } ] }, { "recipient": "gonka1a2k2pz759kj543yzxse4hvvsyjkaw0f42mkpl2", "amount": [ { "denom": "ngonka", "amount": "62491818490" } ] }, { "recipient": "gonka1n0225yr8w7eqdsw3g4kz45vpnyajy69vv4z678", "amount": [ { "denom": "ngonka", "amount": "62479095739" } ] }, { "recipient": "gonka14zzmvt5esggym639wk0v8s3gdgdmnjzrh6p7rv", "amount": [ { "denom": "ngonka", "amount": "62432366788" } ] }, { "recipient": "gonka1zkmn95dkr6kpt7vaqc4vdues0q4f72rttcfxq6", "amount": [ { "denom": "ngonka", "amount": "62312811300" } ] }, { "recipient": "gonka162nxvxvppgfx9ahjlptezrd29t96rm9htun3fr", "amount": [ { "denom": "ngonka", "amount": "62243288794" } ] }, { "recipient": "gonka17akw9frq5grupdh9fwtc4mym3fgcujf9esdmta", "amount": [ { "denom": "ngonka", "amount": "61900860097" } ] }, { "recipient": "gonka16w7yu8apgeepr4xc44r6xq65nj2vxnykfcc0yy", "amount": [ { "denom": "ngonka", "amount": "61543016753" } ] }, { "recipient": "gonka150qqxu2zf0lzc3nngal79h0n5ls6lhszzraytv", "amount": [ { "denom": "ngonka", "amount": "61448135933" } ] }, { "recipient": "gonka1j9rxapzwm06quxcul5686e7f39g6swhfhwxtwa", "amount": [ { "denom": "ngonka", "amount": "61417075275" } ] }, { "recipient": "gonka1zmx4cwayvhf8hevcu6am0sk8ul5trckc2uftmp", "amount": [ { "denom": "ngonka", "amount": "61279907916" } ] }, { "recipient": "gonka1hy4zasaf3knphe923exxm3vl6vyr8m5k8y8ucs", "amount": [ { "denom": "ngonka", "amount": "61262015909" } ] }, { "recipient": "gonka1qvzmfwlcx663f6klq9050h0hs7neacy6ltyt0s", "amount": [ { "denom": "ngonka", "amount": "61219102383" } ] }, { "recipient": "gonka1djrtqmjn5gsgdetglnc9j4x6lq3yuvs2rq8ws2", "amount": [ { "denom": "ngonka", "amount": "60826144815" } ] }, { "recipient": "gonka1m7emdk4ez3dm6xmps9v28y8prreq7le58cppmk", "amount": [ { "denom": "ngonka", "amount": "60258273144" } ] }, { "recipient": "gonka1y46v988rv03mdn2c320fxtle6lramzk4nf8s6r", "amount": [ { "denom": "ngonka", "amount": "60074233066" } ] }, { "recipient": "gonka10xrtfzs46mmjs8dy48auh2xfxq07dxs0mhdcmp", "amount": [ { "denom": "ngonka", "amount": "60063333760" } ] }, { "recipient": "gonka129wh6ap5m5v0skcxvdcgn5nrfa8d0v5jwfz83p", "amount": [ { "denom": "ngonka", "amount": "59908319488" } ] }, { "recipient": "gonka1fyz5uz37ah85tjls6j9kw5grjtrzugt3nwvdpd", "amount": [ { "denom": "ngonka", "amount": "59777122878" } ] }, { "recipient": "gonka1jve3qdmmea6kgcl4y5r3hhll3lm0zuz7kutqft", "amount": [ { "denom": "ngonka", "amount": "59673726353" } ] }, { "recipient": "gonka1ujskhylfq7xqzvanuy90fm640zf459x0qtgtxy", "amount": [ { "denom": "ngonka", "amount": "59447873425" } ] }, { "recipient": "gonka1c8utgl2469d7mjlhhd4afhj3ycm6rq60y7v8dl", "amount": [ { "denom": "ngonka", "amount": "59398642986" } ] }, { "recipient": "gonka19fpma3577v3fnk8nxjkvg442ss8hvglxwqgzz6", "amount": [ { "denom": "ngonka", "amount": "59024162022" } ] }, { "recipient": "gonka1rtylvt6ylcdphuez6eqerj7d7pv7dc3kh6yvzc", "amount": [ { "denom": "ngonka", "amount": "58194552206" } ] }, { "recipient": "gonka1u9zzj3yj3mwrx0j836u9va0v7swnn4w2u3crl5", "amount": [ { "denom": "ngonka", "amount": "57831348106" } ] }, { "recipient": "gonka1n5gsftqp7ez0tcvaxm5mpxjaw258hcp5zvr6tr", "amount": [ { "denom": "ngonka", "amount": "57811346776" } ] }, { "recipient": "gonka1s5cqcwmggkp47nwczq3nluh0rjsut4auz69lyg", "amount": [ { "denom": "ngonka", "amount": "57773345295" } ] }, { "recipient": "gonka1zej4dv2sf03axwnenq9qfxvpx5wcdd65sd3rn5", "amount": [ { "denom": "ngonka", "amount": "57567254646" } ] }, { "recipient": "gonka19qkysq3adu5lrasgvgy7ecd78erz7jndye92jv", "amount": [ { "denom": "ngonka", "amount": "57280775552" } ] }, { "recipient": "gonka16ehmqk5dkl3v4stgh8k77ttc0kw7se2kn62k8p", "amount": [ { "denom": "ngonka", "amount": "56036171965" } ] }, { "recipient": "gonka104z9al2taf6gspj2qlsqtjwpxt7ypmpn5z0nxa", "amount": [ { "denom": "ngonka", "amount": "55771358960" } ] }, { "recipient": "gonka10pgvk2tumqy5n4v2h9dqtkxqes9p208qdy37ta", "amount": [ { "denom": "ngonka", "amount": "55629036578" } ] }, { "recipient": "gonka1cnna5kqqynkkuwl464x4p5zx5jz00lwxdh9adn", "amount": [ { "denom": "ngonka", "amount": "55550103611" } ] }, { "recipient": "gonka1000937gjpju4udj2wlj3yld0lcw024tp0ztqew", "amount": [ { "denom": "ngonka", "amount": "55163652942" } ] }, { "recipient": "gonka1ksvye76z43mrtjpdkh3krm579clamh9yh2ytn8", "amount": [ { "denom": "ngonka", "amount": "55154440930" } ] }, { "recipient": "gonka108gphssdzk24czkrm9apwf50uvs8073u4kwn5t", "amount": [ { "denom": "ngonka", "amount": "54736342264" } ] }, { "recipient": "gonka1u35yjypsyfaw4wpf7gn8m8q9ppumz0yys24tw0", "amount": [ { "denom": "ngonka", "amount": "54433755946" } ] }, { "recipient": "gonka1ctja5ccavyeqnfz7d4nw20a6ytmte9m5hrqayj", "amount": [ { "denom": "ngonka", "amount": "53932484693" } ] }, { "recipient": "gonka1pgn9v9studsuhud80h8hphdq8nzxf4380vm7jy", "amount": [ { "denom": "ngonka", "amount": "53909712952" } ] }, { "recipient": "gonka1rmww9xqyh0p6tyqk0pmzdexnth9q5gj6yw9u85", "amount": [ { "denom": "ngonka", "amount": "53846770983" } ] }, { "recipient": "gonka102yeygzzq74pudsa9nwvjh3q9x4q7wscr23hlw", "amount": [ { "denom": "ngonka", "amount": "53748095481" } ] }, { "recipient": "gonka16d7eeauutuukquwqlj4kgunm67wm6nph9n4zxx", "amount": [ { "denom": "ngonka", "amount": "53547737659" } ] }, { "recipient": "gonka1rp7kqzjeajyq0qag4hl5gcd7x5v64akghdzuqm", "amount": [ { "denom": "ngonka", "amount": "53452611683" } ] }, { "recipient": "gonka15pgw0fe32rv78hdj2clch9acy0mv08j7xkrmxz", "amount": [ { "denom": "ngonka", "amount": "53438396225" } ] }, { "recipient": "gonka1ddhzyd0xlhqnzp05apu26s3ay6mn4mlzll5mjz", "amount": [ { "denom": "ngonka", "amount": "53359805996" } ] }, { "recipient": "gonka14n7ghzxz6252fzu7zdlfm9a6rrqd2dn3xq3ukm", "amount": [ { "denom": "ngonka", "amount": "53319980876" } ] }, { "recipient": "gonka1g5t786e2hnry8c4d6fd4rh5t3vsfdnevejtsvy", "amount": [ { "denom": "ngonka", "amount": "53227984900" } ] }, { "recipient": "gonka1gjuagf8hw0skzwhekxxhccy6zy4g3qxal5ynku", "amount": [ { "denom": "ngonka", "amount": "52838302546" } ] }, { "recipient": "gonka19m47kxgeecyvl4xll882zxwcc7hva5slfxnvq5", "amount": [ { "denom": "ngonka", "amount": "52800202780" } ] }, { "recipient": "gonka1d7qwgjstqhlp62hkhdujcfm2dp3snm97jr0vjh", "amount": [ { "denom": "ngonka", "amount": "52548445182" } ] }, { "recipient": "gonka17fc94j99063t6ullr6cgu02ps7kwut28f9ggpj", "amount": [ { "denom": "ngonka", "amount": "52038846995" } ] }, { "recipient": "gonka1rvnehahwukcckaeu209jqszkvsztjwmfh2zakj", "amount": [ { "denom": "ngonka", "amount": "51587510358" } ] }, { "recipient": "gonka1vttxzd68fur26l9lew5netz6wxnx7hmmzdkqrn", "amount": [ { "denom": "ngonka", "amount": "51489220843" } ] }, { "recipient": "gonka10006x5p5z8zukfye552fd58qqj2qth69kv5kmn", "amount": [ { "denom": "ngonka", "amount": "51393381221" } ] }, { "recipient": "gonka16s9lzz6z882l4lzhm6lh6p4xgsy7r4qlzlgq2u", "amount": [ { "denom": "ngonka", "amount": "51026162306" } ] }, { "recipient": "gonka1qw4wmm6gp57yanpe5jmhmwpcwqzag30zgk7tat", "amount": [ { "denom": "ngonka", "amount": "50976766164" } ] }, { "recipient": "gonka1zrmra5s53f6pgzxx89znkn5k0duwsksr2xuzke", "amount": [ { "denom": "ngonka", "amount": "50696660699" } ] }, { "recipient": "gonka19sftyj72xf8g4kulg7jngvfacw07a8yu0yrjrm", "amount": [ { "denom": "ngonka", "amount": "50296636363" } ] }, { "recipient": "gonka1n3hh2ysxeg37hus7txur32qvxnkmx20fpqfqyr", "amount": [ { "denom": "ngonka", "amount": "49854734345" } ] }, { "recipient": "gonka12kqft8tme0z5zm6skx8zwja7aq8knqc0udfcwp", "amount": [ { "denom": "ngonka", "amount": "49596016899" } ] }, { "recipient": "gonka10009skl232h4c94st5ar3j3c2e34cfk2cpgrj0", "amount": [ { "denom": "ngonka", "amount": "49529511304" } ] }, { "recipient": "gonka1275py7sglqhuyqzmzmdgmpfz9mxsthp8cayjkt", "amount": [ { "denom": "ngonka", "amount": "49381058895" } ] }, { "recipient": "gonka1000hqfkcp3cs0fq4r78vvpkjlv5n4x4sdgcv7v", "amount": [ { "denom": "ngonka", "amount": "49375333358" } ] }, { "recipient": "gonka1000xmydnfvphwy4n5yww4ex6nwk9mqslf2gnhs", "amount": [ { "denom": "ngonka", "amount": "49347000732" } ] }, { "recipient": "gonka1x2qapwtlprmlcxrdtvrskswuznn8v29r4se5tc", "amount": [ { "denom": "ngonka", "amount": "48764873138" } ] }, { "recipient": "gonka1kzhcxdkfdkdyzvl3sdp34yrwkfngdhjwrmua03", "amount": [ { "denom": "ngonka", "amount": "48442213992" } ] }, { "recipient": "gonka1hkz4qdpl2z4zvlyt6mxfsx04yxfp7sjhnyu2xn", "amount": [ { "denom": "ngonka", "amount": "47842380548" } ] }, { "recipient": "gonka10008pmwrke48xh42dhe0ul0mm0mhhvz6ta9srs", "amount": [ { "denom": "ngonka", "amount": "46976792533" } ] }, { "recipient": "gonka1zw680tan4k6uwklyq6eedmga8ew85ys4arqkdg", "amount": [ { "denom": "ngonka", "amount": "46885742385" } ] }, { "recipient": "gonka1nm6gfclrfgtf7j56pxpk07ywpazl92puma7a2g", "amount": [ { "denom": "ngonka", "amount": "46821448184" } ] }, { "recipient": "gonka100009u7hegukxy5ne3w6ycfleaj7uuvh2juxqd", "amount": [ { "denom": "ngonka", "amount": "45998425495" } ] }, { "recipient": "gonka1m8f37e29m7lpvycx5u9dzxp89lzqu2ghfhumw4", "amount": [ { "denom": "ngonka", "amount": "45932814256" } ] }, { "recipient": "gonka1slnscxc26qm7vvpn5qs9yzq9n0l82r4ywkl054", "amount": [ { "denom": "ngonka", "amount": "45861564016" } ] }, { "recipient": "gonka1ym8g5f34h5zu4p4d4ldjnycfkty9qxpmyx5a3m", "amount": [ { "denom": "ngonka", "amount": "45641991851" } ] }, { "recipient": "gonka1qzmhx83xnamk0uqup3lxpf2te9karrwjm9cjh7", "amount": [ { "denom": "ngonka", "amount": "45410751244" } ] }, { "recipient": "gonka1nplx25jwgvg072v4a408vs4xcevceumd04khx5", "amount": [ { "denom": "ngonka", "amount": "44230778694" } ] }, { "recipient": "gonka1l42zhzv3hy6d3y88aq37mdgux4u9crd968v9s4", "amount": [ { "denom": "ngonka", "amount": "44220485796" } ] }, { "recipient": "gonka14a7gpyhushhjhdmwn6dw45tfypaxyeks2kpqtd", "amount": [ { "denom": "ngonka", "amount": "43804495764" } ] }, { "recipient": "gonka16jcz67lj4683hn9ky6w07z7qx2ls5vzgqtc3ey", "amount": [ { "denom": "ngonka", "amount": "43733608497" } ] }, { "recipient": "gonka1u94lnzwgv84xmlu5yhm27pt9qelh0xxay434rn", "amount": [ { "denom": "ngonka", "amount": "43657912074" } ] }, { "recipient": "gonka1t90v237jp5zmw5qu3cmja30nvc9n7t0wstq4vz", "amount": [ { "denom": "ngonka", "amount": "43355126381" } ] }, { "recipient": "gonka13t5wu88fecl8uts96p2gl9xxrta0kavrm2tpfw", "amount": [ { "denom": "ngonka", "amount": "43317278170" } ] }, { "recipient": "gonka1q7sm2pxvn6fauhtvaqemww8pjpauc3rxqkdl6h", "amount": [ { "denom": "ngonka", "amount": "43184809429" } ] }, { "recipient": "gonka1g273eq5mzhlmd6au5wsm3xymhqhphcer93dtpa", "amount": [ { "denom": "ngonka", "amount": "43146961218" } ] }, { "recipient": "gonka1zu2y7jyppptuzgute0ftldhpjl6uzdrduh8xcu", "amount": [ { "denom": "ngonka", "amount": "43090188900" } ] }, { "recipient": "gonka1llw9eff2va8jdt2z0wsy470xag4f7nlhazm4cy", "amount": [ { "denom": "ngonka", "amount": "43052340689" } ] }, { "recipient": "gonka14u7kt72elx59t45gexkkz83a78cfr3vt5976sq", "amount": [ { "denom": "ngonka", "amount": "43014492477" } ] }, { "recipient": "gonka1mh2mjta097tak0ak29d0awd3esy7lkwsnxqc87", "amount": [ { "denom": "ngonka", "amount": "43014492477" } ] }, { "recipient": "gonka16l5sg48x82jqn9am9us6gug43vj3eg40cxf5uw", "amount": [ { "denom": "ngonka", "amount": "42976644265" } ] }, { "recipient": "gonka10k9lnnfq0m73dcunyskt6yhccvw9xyzajeujcs", "amount": [ { "denom": "ngonka", "amount": "42957720160" } ] }, { "recipient": "gonka1dfzzlu0v33hhw0uqyxa665hjdddjvhc4ktzkm3", "amount": [ { "denom": "ngonka", "amount": "42900947842" } ] }, { "recipient": "gonka1f9zjwwe5dgstuk4y9fkcu5kdmdx68r5l4wvvek", "amount": [ { "denom": "ngonka", "amount": "42768479102" } ] }, { "recipient": "gonka1hm9s72e0ampva68rvtz57n7d3gp3dxgs37mdge", "amount": [ { "denom": "ngonka", "amount": "42768479102" } ] }, { "recipient": "gonka1qw9ezz48getxr5y3xcwuawyc3l3syk2j7520ap", "amount": [ { "denom": "ngonka", "amount": "42579238044" } ] }, { "recipient": "gonka1f5gtxpge7xn85nh230dwcg6qvz7cv8h74h3mha", "amount": [ { "denom": "ngonka", "amount": "42560313938" } ] }, { "recipient": "gonka1jm9euh70xtv3xg7jpnqwvclqtwwdxm83jucuj2", "amount": [ { "denom": "ngonka", "amount": "42560313938" } ] }, { "recipient": "gonka1j9drlddzf50vmnk85cep0n4c5shca8n84t90tz", "amount": [ { "denom": "ngonka", "amount": "42427845197" } ] }, { "recipient": "gonka1hfum2nzy80k3uq86nla97a4w423u0zh26axfxt", "amount": [ { "denom": "ngonka", "amount": "42424052467" } ] }, { "recipient": "gonka1xt7gy4ya2095jxnf9aerspw95r8h4t5mk39z57", "amount": [ { "denom": "ngonka", "amount": "42026901717" } ] }, { "recipient": "gonka1vhprg9epy683xghp8ddtdlw2y9cycecmm64tje", "amount": [ { "denom": "ngonka", "amount": "41636379591" } ] }, { "recipient": "gonka1x2rltnk5rggqh73xluduge4gznf2ynakkg0ma4", "amount": [ { "denom": "ngonka", "amount": "41595184542" } ] }, { "recipient": "gonka1kth9pyyalm0u0wfc7dwdwnsntaer9gmfntlgq9", "amount": [ { "denom": "ngonka", "amount": "41352784953" } ] }, { "recipient": "gonka1ks3t0r8g5glvv4um6ml2gy5dzg7l3t2xmp3fg2", "amount": [ { "denom": "ngonka", "amount": "40888897439" } ] }, { "recipient": "gonka1h360mfpkc9py7hya69mylceahm9a7hmd09et8p", "amount": [ { "denom": "ngonka", "amount": "40648916574" } ] }, { "recipient": "gonka19lvs39k8pewhh2ecjp2t8ey5xpeac46jvtlprk", "amount": [ { "denom": "ngonka", "amount": "40038583196" } ] }, { "recipient": "gonka1hatmw3tnlskh6jzkc8ds2yxvlpmrvhrz8pgx0c", "amount": [ { "denom": "ngonka", "amount": "39954392489" } ] }, { "recipient": "gonka1fuezrv0q9hslr4jjgl4cwquytxqe3drksxq6fa", "amount": [ { "denom": "ngonka", "amount": "39354187373" } ] }, { "recipient": "gonka1zmxs507rnegc0takkkarfsu4cktemhzz4anmet", "amount": [ { "denom": "ngonka", "amount": "39296624546" } ] }, { "recipient": "gonka1uzruntzafa6pvv80gxqfcq0kl7f4vxlyw9n0g8", "amount": [ { "denom": "ngonka", "amount": "38302782759" } ] }, { "recipient": "gonka1sg2uj8u59hjkzh6qwfsgg0n0w63ux35my80h4a", "amount": [ { "denom": "ngonka", "amount": "37153182023" } ] }, { "recipient": "gonka100070ewvrcraax995yd78cm0nraryzp4hal3hk", "amount": [ { "denom": "ngonka", "amount": "36874808119" } ] }, { "recipient": "gonka1cpjcdc97u67m3x35hjj8znuvq37pldfsatmcd6", "amount": [ { "denom": "ngonka", "amount": "36854153699" } ] }, { "recipient": "gonka14vypx85sx0qd4aajmzklhy6s0ygftf57zafd8a", "amount": [ { "denom": "ngonka", "amount": "36709046746" } ] }, { "recipient": "gonka1cq9f8uc3hz39qtuf3q77r5kv2y2hy52ehmmvy6", "amount": [ { "denom": "ngonka", "amount": "36635985230" } ] }, { "recipient": "gonka1ax52nxfepvshvatstyd3t3v56feaph24xzzf79", "amount": [ { "denom": "ngonka", "amount": "36609116979" } ] }, { "recipient": "gonka1tj9573sdggg2s9ysq8ec7me8xactn0a4kusqaa", "amount": [ { "denom": "ngonka", "amount": "36287326427" } ] }, { "recipient": "gonka1clm58yldg7zp7dmuwrqyh4quqt339qr3q8fajm", "amount": [ { "denom": "ngonka", "amount": "36201014737" } ] }, { "recipient": "gonka1equqcel7hzlu07ekt7tep62yh23wp0cc2ryqyr", "amount": [ { "denom": "ngonka", "amount": "36063803320" } ] }, { "recipient": "gonka1wn9aqvsgnl7zdf4qqndczawav7a22gtq23qax0", "amount": [ { "denom": "ngonka", "amount": "35946029498" } ] }, { "recipient": "gonka1362yedf9k0xpce8y30xg4g4e2mmgvstaf856qd", "amount": [ { "denom": "ngonka", "amount": "35860557521" } ] }, { "recipient": "gonka1000zfcrzdjwwucvs9k2wuy4j5ecj69q5f4v57h", "amount": [ { "denom": "ngonka", "amount": "35723100105" } ] }, { "recipient": "gonka1aevup75mz4q3vd89ljkqjlrkxvfpwk3dtvtvq2", "amount": [ { "denom": "ngonka", "amount": "35621686765" } ] }, { "recipient": "gonka1zvuzj7ya9zafw309prasd0r4jhykf47mhcpp3x", "amount": [ { "denom": "ngonka", "amount": "35304088198" } ] }, { "recipient": "gonka1a2hgufj4f8d307cfa8n4kc8xts56rtnvsxydkz", "amount": [ { "denom": "ngonka", "amount": "35301237878" } ] }, { "recipient": "gonka1fnmyrkw6qta9uqn4q666c4d8k2vj3ves68rt38", "amount": [ { "denom": "ngonka", "amount": "35296092668" } ] }, { "recipient": "gonka1gwakaz7dzpay0e4at7jmj0mrnqwjex6kza4dlf", "amount": [ { "denom": "ngonka", "amount": "35279872145" } ] }, { "recipient": "gonka1kch7y24sjux5s7qd9l9j02qzusk33xeqwyz0kc", "amount": [ { "denom": "ngonka", "amount": "35208000415" } ] }, { "recipient": "gonka1h9axtmze6nqeeh9azggrk0k2qcx8lz2shd67jg", "amount": [ { "denom": "ngonka", "amount": "35161574671" } ] }, { "recipient": "gonka1m3nnusrecvld0jwueulywqwq0wa0tp7uav2n39", "amount": [ { "denom": "ngonka", "amount": "34979570001" } ] }, { "recipient": "gonka1cn7jka3lx0ex0dxwdcfeaxkqfjl2as080mx90k", "amount": [ { "denom": "ngonka", "amount": "34811978339" } ] }, { "recipient": "gonka1qswp63txcftfdcgcle4lshkly0nmmlfr9ecj8r", "amount": [ { "denom": "ngonka", "amount": "34785029208" } ] }, { "recipient": "gonka14q3s4vmmlukl936q7e4asuwjnakv7u59hsvuwm", "amount": [ { "denom": "ngonka", "amount": "34699810342" } ] }, { "recipient": "gonka1jyqp04yrjn8vdwqwkuwfd8nqal4d4vr3lpdyuk", "amount": [ { "denom": "ngonka", "amount": "34678286219" } ] }, { "recipient": "gonka1jvp4r2dx3t0d736fmxy5ncgwp0w3kdy063m5ps", "amount": [ { "denom": "ngonka", "amount": "34608772474" } ] } ], "vesting_epochs": "180" }, { "@type": "/inference.streamvesting.MsgBatchTransferWithVesting", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "outputs": [ { "recipient": "gonka1xuk3ganuhygvpge340sfepuwlr89s50fytlx2p", "amount": [ { "denom": "ngonka", "amount": "34550836403" } ] }, { "recipient": "gonka1t0gevkpnxe8000ke344zuhf5ljwefmdxnfzp0g", "amount": [ { "denom": "ngonka", "amount": "34441986746" } ] }, { "recipient": "gonka1sl8fmjg6glvq4gl9q9u4dyek74e2lzj2ucua5g", "amount": [ { "denom": "ngonka", "amount": "34373143271" } ] }, { "recipient": "gonka19w5vy2z5gz9f4jr76f8uz09023wz2snycaty05", "amount": [ { "denom": "ngonka", "amount": "34354165145" } ] }, { "recipient": "gonka16jw23vytrm9cw93s2aea6s4g6f2zkrg6dch6wm", "amount": [ { "denom": "ngonka", "amount": "34270642651" } ] }, { "recipient": "gonka1fjrq7m6xy9wpmm88vr63d08ps8dt9em38lhq08", "amount": [ { "denom": "ngonka", "amount": "34243443664" } ] }, { "recipient": "gonka1e6q0zgndr833egu2050lqqdg7tg8av62duv6em", "amount": [ { "denom": "ngonka", "amount": "34053173676" } ] }, { "recipient": "gonka106wrpdwkuudnxdm0lwzw2zharr8tfx7ug07p9f", "amount": [ { "denom": "ngonka", "amount": "33837315554" } ] }, { "recipient": "gonka1dqgcdz94x42ukcfmy6crj55a0j2qucsaecx0j5", "amount": [ { "denom": "ngonka", "amount": "33771096244" } ] }, { "recipient": "gonka10gj5lnsxalcwzeve04k2pdzhx2nrlqp4hkrevd", "amount": [ { "denom": "ngonka", "amount": "33752736179" } ] }, { "recipient": "gonka1a357vdludl6kpmx0c7cstf3vc0muu7t7ltw8sd", "amount": [ { "denom": "ngonka", "amount": "33655742883" } ] }, { "recipient": "gonka148eld5kxu6k867pz6yxmwps0kpy7rdxg2x2xau", "amount": [ { "denom": "ngonka", "amount": "33642299445" } ] }, { "recipient": "gonka1e9muhlte58rwqrr3493qxcwcj8mqrg5azxa6v4", "amount": [ { "denom": "ngonka", "amount": "33452672982" } ] }, { "recipient": "gonka1cze6ecxhaqxmls39l0kwxad50x2skqmk3hswlf", "amount": [ { "denom": "ngonka", "amount": "33330881406" } ] }, { "recipient": "gonka15g9vxflt3q92w07kcw099zjtc3lft9vwtr254x", "amount": [ { "denom": "ngonka", "amount": "33274192458" } ] }, { "recipient": "gonka1j2g3g844qspgnjjrtmcrt55ssg4h6akdt4f66a", "amount": [ { "denom": "ngonka", "amount": "33264959641" } ] }, { "recipient": "gonka1yw3ggwwftvp2u3vt9l5hcyqftkd05nu4j3h7sr", "amount": [ { "denom": "ngonka", "amount": "33206286702" } ] }, { "recipient": "gonka1t4jkhfkwexdz6rm95rdd9qg2905uwd59jc7yyt", "amount": [ { "denom": "ngonka", "amount": "33195596171" } ] }, { "recipient": "gonka10qpuqx5xcp4l4yjfh49gdcedgjsh3eazjm470v", "amount": [ { "denom": "ngonka", "amount": "33112451957" } ] }, { "recipient": "gonka1w2pxkv4v6r5h6sdvges287l2g5rsd3r4x77080", "amount": [ { "denom": "ngonka", "amount": "33054621263" } ] }, { "recipient": "gonka1vnmmnq4x9f7d3kume6xq2fh8x3mdye25gclzln", "amount": [ { "denom": "ngonka", "amount": "32894864872" } ] }, { "recipient": "gonka1jrwj2hqjwy5ulgkpdsdv6gwch7x4alnj88wmm5", "amount": [ { "denom": "ngonka", "amount": "32889996241" } ] }, { "recipient": "gonka1j3xajqgg0mu9lvfu320mknu736nl0ltmeeqje7", "amount": [ { "denom": "ngonka", "amount": "32859737836" } ] }, { "recipient": "gonka1r4cynx8smndx0vc3j8h0x8ld8h9wyzzs73cxye", "amount": [ { "denom": "ngonka", "amount": "32787729371" } ] }, { "recipient": "gonka1dn2gwpylkpjmxhgpyp6vfwqp5awydtguck5wc5", "amount": [ { "denom": "ngonka", "amount": "32775299091" } ] }, { "recipient": "gonka1evnq82x3j2mpf9a7mgrtuav2r2v635q7ekt96g", "amount": [ { "denom": "ngonka", "amount": "32774603729" } ] }, { "recipient": "gonka14hruf6ljltha9yklfgpd0s8jleyc3wdraatfre", "amount": [ { "denom": "ngonka", "amount": "32768119221" } ] }, { "recipient": "gonka1nfammd4gwrde0jhn7w0tfu0228a5jfmst76t34", "amount": [ { "denom": "ngonka", "amount": "32744316972" } ] }, { "recipient": "gonka122yzg0agje5a4nq8spx2fwe2cye79x7hz3shgl", "amount": [ { "denom": "ngonka", "amount": "32701398221" } ] }, { "recipient": "gonka1mklzy8yt48wkk7qrgz485dn995zkvfmjy29nfz", "amount": [ { "denom": "ngonka", "amount": "32625393668" } ] }, { "recipient": "gonka1xcvj6xlqy7p7fzyne5jqrnz96fa4xfh35vymwt", "amount": [ { "denom": "ngonka", "amount": "32621269459" } ] }, { "recipient": "gonka15lxz9w7m77dr04dxv7smxmc4xl2vr4klu2gclf", "amount": [ { "denom": "ngonka", "amount": "32567168832" } ] }, { "recipient": "gonka1gum47e5sn43ughhktw5a46f7rc6cs2s08tpl69", "amount": [ { "denom": "ngonka", "amount": "32519583467" } ] }, { "recipient": "gonka1neug285zahkpplsfmgrhnkmjjwzalk3z88uekt", "amount": [ { "denom": "ngonka", "amount": "32457360602" } ] }, { "recipient": "gonka1p3jfqqnjuu20zyk5t5d9xhemys2z7zxrln5vv0", "amount": [ { "denom": "ngonka", "amount": "32452798094" } ] }, { "recipient": "gonka1gg2jwjfjf22gda82gm947mjs8z0gpg9tk2eh3m", "amount": [ { "denom": "ngonka", "amount": "32400210330" } ] }, { "recipient": "gonka1mxa996t7rjsuj8l7g82qfwcgy5yed5ckf9lr5k", "amount": [ { "denom": "ngonka", "amount": "32365494850" } ] }, { "recipient": "gonka13uuqfsenjazwu6am5fctzscar364s240zek5st", "amount": [ { "denom": "ngonka", "amount": "32363472008" } ] }, { "recipient": "gonka1pwumgsfldkzspvpun6rgty0evpz47l9mwa79v9", "amount": [ { "denom": "ngonka", "amount": "32361902785" } ] }, { "recipient": "gonka13vpvregum5amwn0s0qyfac0cdngxc2cq3cp67n", "amount": [ { "denom": "ngonka", "amount": "32292448899" } ] }, { "recipient": "gonka1hvat7x6qspwh5vw2pynwcdh57kc6xjl8g67ljx", "amount": [ { "denom": "ngonka", "amount": "32279098218" } ] }, { "recipient": "gonka1lp3q5zammhv5a7fmn5u58clz5k7wr0205h6llk", "amount": [ { "denom": "ngonka", "amount": "32235369089" } ] }, { "recipient": "gonka1sytjktet2reklks2qk32f2pm4rrah2l0lm8c0c", "amount": [ { "denom": "ngonka", "amount": "32218931896" } ] }, { "recipient": "gonka1x8pupvvcgcn00kguy9umycj98qgqehwlxt6l93", "amount": [ { "denom": "ngonka", "amount": "32184179555" } ] }, { "recipient": "gonka1xcjc32p5g72gc4tjxsm890star2l7w2g8n67w6", "amount": [ { "denom": "ngonka", "amount": "32110065428" } ] }, { "recipient": "gonka1urf86dzpmgx44afh32ug7yy3x6hw86gpm9te00", "amount": [ { "denom": "ngonka", "amount": "32098302598" } ] }, { "recipient": "gonka1jmynyvawnx9jlwd6he7q8hdltpy2dv2tz74daz", "amount": [ { "denom": "ngonka", "amount": "32080961460" } ] }, { "recipient": "gonka1ta39vdtx4qmlwpvmpjyajn5yulflf0ye2nu4m4", "amount": [ { "denom": "ngonka", "amount": "32078160185" } ] }, { "recipient": "gonka1lnus3x4dy0ze8naktrldft5edx4e36qc53yxjf", "amount": [ { "denom": "ngonka", "amount": "32045279321" } ] }, { "recipient": "gonka1zqxg52qngwtgzgnrvljdwcwt9q0jz9r2djkpyj", "amount": [ { "denom": "ngonka", "amount": "32037212078" } ] }, { "recipient": "gonka1m2rsvln78rv2rt4m0ypvzmg6z9pm803nef55k9", "amount": [ { "denom": "ngonka", "amount": "31953104138" } ] }, { "recipient": "gonka1m3hfvjy92ewcvykqkk69j7kgkhffwxw0n8q0an", "amount": [ { "denom": "ngonka", "amount": "31937771492" } ] }, { "recipient": "gonka1y6g6xx6lyp3gdnyq7k9tm9fa7ykzjdx68hyzpx", "amount": [ { "denom": "ngonka", "amount": "31933368965" } ] }, { "recipient": "gonka1mqmvutyh7h87fgw6k246c4q5n0xjjfn3vmqupj", "amount": [ { "denom": "ngonka", "amount": "31856310730" } ] }, { "recipient": "gonka1ntlp35e8cyylh5fjmlzt0qvkhyjszsuwngd6ka", "amount": [ { "denom": "ngonka", "amount": "31832976398" } ] }, { "recipient": "gonka1y2e6vzpws7dguken363g9zfs3835l7k3m2p8x0", "amount": [ { "denom": "ngonka", "amount": "31632833215" } ] }, { "recipient": "gonka1scl6c3zk73p920m83r2lndljprz68rjepez6u3", "amount": [ { "denom": "ngonka", "amount": "31613895044" } ] }, { "recipient": "gonka1m3twars04gxy3dtxwjrvz4s7x82ljx4y35hmpt", "amount": [ { "denom": "ngonka", "amount": "31587952243" } ] }, { "recipient": "gonka18ulrvu3qfvvtq3s079dl2dwql2rev66zmgjk97", "amount": [ { "denom": "ngonka", "amount": "31545402924" } ] }, { "recipient": "gonka1py2eckpy6nqu6uxnxzq8zdfwl533xewpca86sx", "amount": [ { "denom": "ngonka", "amount": "31533425283" } ] }, { "recipient": "gonka1cx5jhxlg8mwjgl8v50h8ypcyxrz4qyh4ef20g4", "amount": [ { "denom": "ngonka", "amount": "31502791956" } ] }, { "recipient": "gonka1pd4dw77pux8rz63v7wqeyx2nlun874e2l4ycve", "amount": [ { "denom": "ngonka", "amount": "31501836223" } ] }, { "recipient": "gonka1u894qk409f4rt7fta590n7fu6szsu6s8nqq0dj", "amount": [ { "denom": "ngonka", "amount": "31471079219" } ] }, { "recipient": "gonka1fvw4sad9uqe75tg3q9gaj8rhav7dc454wr2gxe", "amount": [ { "denom": "ngonka", "amount": "31466429934" } ] }, { "recipient": "gonka1vmhd38lxl68lm76755u4xdxp5wqm646a2hasze", "amount": [ { "denom": "ngonka", "amount": "31391271778" } ] }, { "recipient": "gonka1qlqjyqpmmq4r3fa8tfner44z78728z8ndkgvcc", "amount": [ { "denom": "ngonka", "amount": "31334651104" } ] }, { "recipient": "gonka1rs07h66nfduhnf5qg7u968zqumragmmacuand8", "amount": [ { "denom": "ngonka", "amount": "31134689297" } ] }, { "recipient": "gonka1000rv0ddp9yk6djr4y29mt0gu3m4p8mg4kmjcv", "amount": [ { "denom": "ngonka", "amount": "31018248930" } ] }, { "recipient": "gonka1evsnmudxqr9lxchjj5gsxq39qk4p3tr0y9uxu7", "amount": [ { "denom": "ngonka", "amount": "30946574535" } ] }, { "recipient": "gonka1g8v99pzkqhc752fvh7fkn3vxznrgrx7pdraa7m", "amount": [ { "denom": "ngonka", "amount": "30652966655" } ] }, { "recipient": "gonka1ekdjk6vfnsnn4dr8fsdeyjtg5g3c0wyp4z3ett", "amount": [ { "denom": "ngonka", "amount": "30627286133" } ] }, { "recipient": "gonka1pyvqmxs6rkv8sqpax42gkf9ffvlnqjcx0ht0va", "amount": [ { "denom": "ngonka", "amount": "30537231760" } ] }, { "recipient": "gonka1kjrvy4xme4ctepdjspjdw677nmvdwlps4hl5h8", "amount": [ { "denom": "ngonka", "amount": "30329750676" } ] }, { "recipient": "gonka1apdtylf7dfskdy545zv2pxvrfja286vrl7cqh8", "amount": [ { "denom": "ngonka", "amount": "30297241505" } ] }, { "recipient": "gonka1000xjetteyu7gy726vnhdxq69y3meq04gvnk4d", "amount": [ { "denom": "ngonka", "amount": "30257047419" } ] }, { "recipient": "gonka1qx3stahnpknaf8lq0kzdtedtxmq965hj9tp0jv", "amount": [ { "denom": "ngonka", "amount": "30103611780" } ] }, { "recipient": "gonka1000sng4u5jm7jdjnwxvq6uwmw067mvcurd9205", "amount": [ { "denom": "ngonka", "amount": "30052491473" } ] }, { "recipient": "gonka1l059p34y0lcsuudgs8ln83nt6htjnmjcccqn7v", "amount": [ { "denom": "ngonka", "amount": "30045474025" } ] }, { "recipient": "gonka1xk4mz0avlmvzser49tfrcgsjglq4a8u05j55p6", "amount": [ { "denom": "ngonka", "amount": "29865175360" } ] }, { "recipient": "gonka1mev8s38pz9u55jkg46ql6lw8xlsnvf4ggcefd2", "amount": [ { "denom": "ngonka", "amount": "29862700465" } ] }, { "recipient": "gonka1qxy42sc078ut52ws06nsa5fyzcfjyx7a56lw84", "amount": [ { "denom": "ngonka", "amount": "29797245460" } ] }, { "recipient": "gonka1xec9u9kczf7jckvtxgalghsfcnk938h2ng9flq", "amount": [ { "denom": "ngonka", "amount": "29780634312" } ] }, { "recipient": "gonka1p2t9xrr5qs8xxx7rayy37tjh7pvl0x4sdgnd8h", "amount": [ { "denom": "ngonka", "amount": "29746316564" } ] }, { "recipient": "gonka185qz338ahgj324udxakau55tk9frygxrs8zduz", "amount": [ { "denom": "ngonka", "amount": "29568742112" } ] }, { "recipient": "gonka1af4yltv435t3f2mx0qkw2mafdrkmqng05g7l8a", "amount": [ { "denom": "ngonka", "amount": "29348401884" } ] }, { "recipient": "gonka122dtadquy0ayf6nzx7thg6643w7cv0fcnqssq6", "amount": [ { "denom": "ngonka", "amount": "29338115964" } ] }, { "recipient": "gonka1x4wafrl70272pzg3897zzefexwtmeuyar7tsll", "amount": [ { "denom": "ngonka", "amount": "29286218804" } ] }, { "recipient": "gonka14m8tpzysrtjyew3s42mxq9u6gxz3pfacafq28k", "amount": [ { "denom": "ngonka", "amount": "29196937196" } ] }, { "recipient": "gonka1uw0kpk6hcmm0sh05l27sq6m5max7pg0n2ptsuk", "amount": [ { "denom": "ngonka", "amount": "29162923009" } ] }, { "recipient": "gonka1tj5jr5439yx3juzdcx77zgyhkq53u7dtsn6vc5", "amount": [ { "denom": "ngonka", "amount": "29160747790" } ] }, { "recipient": "gonka1u88dwqlx6ew6mhg0pp3wtjaf9d590w2z8706cu", "amount": [ { "denom": "ngonka", "amount": "29156743686" } ] }, { "recipient": "gonka1kfsa9q7upj8wnqrkaud755y7w2vwug3pjp832h", "amount": [ { "denom": "ngonka", "amount": "29156126361" } ] }, { "recipient": "gonka1nv5twlr9sl69g650apxxe0h4vy7mw6y8cx9sha", "amount": [ { "denom": "ngonka", "amount": "29156019868" } ] }, { "recipient": "gonka1e4qcqggpllj4ulsd97ha9agm2e05sd48d4lmyh", "amount": [ { "denom": "ngonka", "amount": "29145312078" } ] }, { "recipient": "gonka1cy2l9yrumllfmm2gjs9vu9wmz2qq5qnjfy6sd3", "amount": [ { "denom": "ngonka", "amount": "29087280139" } ] }, { "recipient": "gonka1wpar5p0kmn5cwwn5awzjeycgt6rkr58723fttn", "amount": [ { "denom": "ngonka", "amount": "28777782573" } ] }, { "recipient": "gonka1quxrzzy8dwhzpmsdql05nqdzj3u3n0syk4r6pr", "amount": [ { "denom": "ngonka", "amount": "28709079143" } ] }, { "recipient": "gonka1d3vxnhh9tm8lahmnehhwcuqy7lc72rudn5hfpg", "amount": [ { "denom": "ngonka", "amount": "28656347359" } ] }, { "recipient": "gonka1ndga0ugvxa975ftycq908hrscpcnt6enzvrzt8", "amount": [ { "denom": "ngonka", "amount": "28651721737" } ] }, { "recipient": "gonka1nluanlq02cg8qrwyqn2qm2zf0mmlyqdevtf66a", "amount": [ { "denom": "ngonka", "amount": "28621080859" } ] }, { "recipient": "gonka1dr9jslmgk9pp3kt0twe98g3hm5cnn2z3ehpaz2", "amount": [ { "denom": "ngonka", "amount": "28556369016" } ] }, { "recipient": "gonka16jp0xfvv20eg55wn2lxy298jms3g9wvtjfnkvf", "amount": [ { "denom": "ngonka", "amount": "28524035939" } ] }, { "recipient": "gonka1tqr0yuykhd4j4wgzdzng46rd22c9jlfuxkz238", "amount": [ { "denom": "ngonka", "amount": "28381133704" } ] }, { "recipient": "gonka1l5v6g8xahf88pqnv3htq72c6kf792yvw3aqx39", "amount": [ { "denom": "ngonka", "amount": "28359785290" } ] }, { "recipient": "gonka1xrcdrdjy0s0e5nhy6nw3tcm9vrzn347qtct4p2", "amount": [ { "denom": "ngonka", "amount": "28330276533" } ] }, { "recipient": "gonka1v8z57yg47n8h4zveyj4cdpn0ll8k9zpcm7egkv", "amount": [ { "denom": "ngonka", "amount": "28226744290" } ] }, { "recipient": "gonka1usa7alwmkwrvsu22fg4p8k2ftan35glprkkx4z", "amount": [ { "denom": "ngonka", "amount": "28140172307" } ] }, { "recipient": "gonka1rss07hzdm9d3y45fg3s3rnxjgzs26yt0h7khs6", "amount": [ { "denom": "ngonka", "amount": "28114972205" } ] }, { "recipient": "gonka1wjxkarkm69harhu6h77n56slpqmjg6ygarf4tl", "amount": [ { "denom": "ngonka", "amount": "28060817332" } ] }, { "recipient": "gonka1cx4dkft2kzdzfjcuale2lw5cqaptdzgahwrj90", "amount": [ { "denom": "ngonka", "amount": "28035258544" } ] }, { "recipient": "gonka10ejjacwvwma37rn8wrf3je7gt8u7lulu7vh8ly", "amount": [ { "denom": "ngonka", "amount": "27926968729" } ] }, { "recipient": "gonka1h6829d8eykrqgev9jr630htpze3j220er9f2ag", "amount": [ { "denom": "ngonka", "amount": "27921982770" } ] }, { "recipient": "gonka1w50e3hn86mt8gmaknecnr4mez0j94vlw04lcjq", "amount": [ { "denom": "ngonka", "amount": "27903755847" } ] }, { "recipient": "gonka1xlvxvzec4n4xn8mjyj88jrg7zlkmfqy9uglucu", "amount": [ { "denom": "ngonka", "amount": "27739201757" } ] }, { "recipient": "gonka1wrcr9gxu2r94chjsuk3wpcqefsv7ts0rnc94ve", "amount": [ { "denom": "ngonka", "amount": "27727239454" } ] }, { "recipient": "gonka1s5ysllxfjd9gglayqe3zpqfzsr4juq9ztzr78a", "amount": [ { "denom": "ngonka", "amount": "27630256085" } ] }, { "recipient": "gonka1c8m85uzdz43j9k9539z7zsn4hp8k4qu9qc6cux", "amount": [ { "denom": "ngonka", "amount": "27627053790" } ] }, { "recipient": "gonka1u9832k7znn5k4an7a9ad8nmej0jswc7ep20q3n", "amount": [ { "denom": "ngonka", "amount": "27543558063" } ] }, { "recipient": "gonka1sw7d7r42hqwgxz4ln2x4p4pjqxgejwqnxxzj3f", "amount": [ { "denom": "ngonka", "amount": "27537076467" } ] }, { "recipient": "gonka1tpvcpcmmqcku5g53tv2q4wehgqw3nmeq3jk4vn", "amount": [ { "denom": "ngonka", "amount": "27513731840" } ] }, { "recipient": "gonka1ut2k5s0jgnwx09nrkzvuprcd58m3afumcv87jm", "amount": [ { "denom": "ngonka", "amount": "27303988288" } ] }, { "recipient": "gonka10003spukrualhl3h80k9x5m9vrmvlmp8kf4t4w", "amount": [ { "denom": "ngonka", "amount": "27272106213" } ] }, { "recipient": "gonka1nad4h437q7zl6nmwvuxzh9g73vkm5cdymxvuqp", "amount": [ { "denom": "ngonka", "amount": "27260782735" } ] }, { "recipient": "gonka1z25rl5qzdeyn5hc6ktnzhpm09q2devk2568pql", "amount": [ { "denom": "ngonka", "amount": "26803751077" } ] }, { "recipient": "gonka1q0r6nmh849xatx62cd09axnx4et4egu4z7n7jj", "amount": [ { "denom": "ngonka", "amount": "26667340407" } ] }, { "recipient": "gonka100092zwvcksslturgx39lzwy6ztjxuttt3spej", "amount": [ { "denom": "ngonka", "amount": "26561829616" } ] }, { "recipient": "gonka1679j5jww67exhkzdvsdw0n7ak7ukyszhy0mny6", "amount": [ { "denom": "ngonka", "amount": "26427638108" } ] }, { "recipient": "gonka1clpf7wtd8p333p20z3caasxxyru6gdqwhzuun9", "amount": [ { "denom": "ngonka", "amount": "26422116370" } ] }, { "recipient": "gonka1yaqxj5hxmme0q7m2wutngne0fdyaajv83p558f", "amount": [ { "denom": "ngonka", "amount": "26232511177" } ] }, { "recipient": "gonka1fc50lzgcdmrr569grw2sflk7m8ew9ptrqzfru6", "amount": [ { "denom": "ngonka", "amount": "25852031521" } ] }, { "recipient": "gonka19k8devnfgkw5ftgsynjrewp4hcwnfph3ynqzfz", "amount": [ { "denom": "ngonka", "amount": "25832387144" } ] }, { "recipient": "gonka1n5r055hu5tr63rgqs7xg4d45ar8q6yy3qdhn04", "amount": [ { "denom": "ngonka", "amount": "25418754091" } ] }, { "recipient": "gonka1pks9m29wqac2kxdj8v8acq58rjshh6u8y2a772", "amount": [ { "denom": "ngonka", "amount": "25368378661" } ] }, { "recipient": "gonka10r7l6unulyg0wtk8kl980k7fpvjskxuxdtnt7t", "amount": [ { "denom": "ngonka", "amount": "25228485721" } ] }, { "recipient": "gonka1yqpl6vwwyzkde0ngsclghy7dzyau0mjja3gva8", "amount": [ { "denom": "ngonka", "amount": "24967799828" } ] }, { "recipient": "gonka17ry2rgtktp9f6etejw4ls2dnagrctxqvlu7e9k", "amount": [ { "denom": "ngonka", "amount": "24660387802" } ] }, { "recipient": "gonka1lzngx5unw6qu7f97zkq6wkvmk5aze4quwn7rnt", "amount": [ { "denom": "ngonka", "amount": "24047476336" } ] }, { "recipient": "gonka1k9ser0a6lr23rqt843z6w0e03us4lp6af546fg", "amount": [ { "denom": "ngonka", "amount": "23595720321" } ] }, { "recipient": "gonka13jw6k5lleqepjyjsm8r4lhrfnn955h8wrexdz2", "amount": [ { "denom": "ngonka", "amount": "23566377466" } ] }, { "recipient": "gonka1g47tma3ruze3dtk36ru97pcn6yp0ffcyws5dr6", "amount": [ { "denom": "ngonka", "amount": "23474900146" } ] }, { "recipient": "gonka1u5t8ue2699e9z92kytnxys2l0eehywsxeqvnnx", "amount": [ { "denom": "ngonka", "amount": "23449857585" } ] }, { "recipient": "gonka149c9zggn4su56mrasyrkakk8apcpuz23sx35eq", "amount": [ { "denom": "ngonka", "amount": "23285172476" } ] }, { "recipient": "gonka1h583klq89w5m39tt832clppkfx807av7m07656", "amount": [ { "denom": "ngonka", "amount": "23001560992" } ] }, { "recipient": "gonka14dkhe6rhy2nq6snmkp2ssnaesumsuwctlmrzcn", "amount": [ { "denom": "ngonka", "amount": "22218014068" } ] }, { "recipient": "gonka13crxlqch46e2jdm6uq03g8wsxndqkpdgay6j3u", "amount": [ { "denom": "ngonka", "amount": "22005384622" } ] }, { "recipient": "gonka1nc8nlx0dd5uhz82t3fyxlsy4d5n07fw87mrv8g", "amount": [ { "denom": "ngonka", "amount": "21592621870" } ] }, { "recipient": "gonka1j4zdyxve2f9fkj8d2nx2cvg09wv67cy7xucm0h", "amount": [ { "denom": "ngonka", "amount": "21529927723" } ] }, { "recipient": "gonka1njzjqpx6t4jwe9t0fu8vtzn5cj5xjlaussvctx", "amount": [ { "denom": "ngonka", "amount": "20936569149" } ] }, { "recipient": "gonka1ksz9raj0yvg7wxdfhuj5474lmjpkzkphu0jw27", "amount": [ { "denom": "ngonka", "amount": "20908935725" } ] }, { "recipient": "gonka1au034ld8fsrvtyxpzxx8nnnqe5kmhe20lmhuwm", "amount": [ { "denom": "ngonka", "amount": "19688669380" } ] }, { "recipient": "gonka10000uv63da0ee5drk26erkwrvcmpmj7kg6kw48", "amount": [ { "denom": "ngonka", "amount": "19682731338" } ] }, { "recipient": "gonka1sq6myvv8r263v4ll5l3ny790nsg5s4507crtqr", "amount": [ { "denom": "ngonka", "amount": "19238314261" } ] }, { "recipient": "gonka1cxml8gqycch45s3l54nhmy5usfg2ughrzq4kvx", "amount": [ { "denom": "ngonka", "amount": "19235354950" } ] }, { "recipient": "gonka1llyscnv8vdflufpm8j7n52macpd3s6kt73uusn", "amount": [ { "denom": "ngonka", "amount": "19145554351" } ] }, { "recipient": "gonka1aqjsdkgajzdzxlyru3q2rc9eqduyyw2qdc2g3q", "amount": [ { "denom": "ngonka", "amount": "19094744887" } ] }, { "recipient": "gonka1tvjdvlf3jmc48ckycguvdvlepgj7jgx9q5m2aw", "amount": [ { "denom": "ngonka", "amount": "19056503512" } ] }, { "recipient": "gonka15hc8eqp4axp7lztjuk0y5z0af6drw5k0eltrue", "amount": [ { "denom": "ngonka", "amount": "18671721349" } ] }, { "recipient": "gonka1e2rnawlpqumhjgmkqwjkyeyhfnsgaxqdelmwqc", "amount": [ { "denom": "ngonka", "amount": "18515753485" } ] }, { "recipient": "gonka1zjajt7pt4tx0djf9r7gksur320gug5e9ymqkaf", "amount": [ { "denom": "ngonka", "amount": "18468775368" } ] }, { "recipient": "gonka1velxhp2knfmqa2406rvwygex8j9fr5d8vd8q3u", "amount": [ { "denom": "ngonka", "amount": "18462078890" } ] }, { "recipient": "gonka1t8r67ncy50g23sz5xlal9hahnq72ej25jd0nrt", "amount": [ { "denom": "ngonka", "amount": "18173527129" } ] }, { "recipient": "gonka1d8v8s56a27wrjc0gfj4c0vafq67j2ddhr7n5k7", "amount": [ { "denom": "ngonka", "amount": "17733795714" } ] }, { "recipient": "gonka1v5k8fqqfc0v798gm8svcv6tczppvegsetw4mfc", "amount": [ { "denom": "ngonka", "amount": "17582019223" } ] }, { "recipient": "gonka16g6lr5tzelh4m66gxf5hlvcjf0drcwnyse7yau", "amount": [ { "denom": "ngonka", "amount": "17495597361" } ] }, { "recipient": "gonka1e8d0gt4d3u565208jjn035a6h3nvxzwtc4w8j9", "amount": [ { "denom": "ngonka", "amount": "17282570667" } ] }, { "recipient": "gonka16th7hk6p6z9vy02yvt56mtx3aqj78zaxqgka4a", "amount": [ { "denom": "ngonka", "amount": "17247968332" } ] }, { "recipient": "gonka1crsq8zatznue5t6mw4ezrgvw4rtre2paw6lfs3", "amount": [ { "denom": "ngonka", "amount": "17057302371" } ] }, { "recipient": "gonka1cz5pcp5wfnkkahasj9vge9snpvl8ayz5nvu8z5", "amount": [ { "denom": "ngonka", "amount": "16858670071" } ] }, { "recipient": "gonka1eqjy6gy8vapf3xtukyrcva0cn952m07sntnlzv", "amount": [ { "denom": "ngonka", "amount": "16690841039" } ] }, { "recipient": "gonka12u5pjkvehkhzky5s0yn3j0teseqa2wk3m26aq5", "amount": [ { "denom": "ngonka", "amount": "16519802104" } ] }, { "recipient": "gonka1nu5tnluwfc6e0m9deyaht2mj0t0tluap9t424s", "amount": [ { "denom": "ngonka", "amount": "16109548769" } ] }, { "recipient": "gonka1qdulrz55xwma52j8xtmw09pgg6h5pena004s3q", "amount": [ { "denom": "ngonka", "amount": "15992987647" } ] }, { "recipient": "gonka1hp35n496dgnhfl98qlhhzvq5zema6zlcv8slvd", "amount": [ { "denom": "ngonka", "amount": "15872119095" } ] }, { "recipient": "gonka18jd4my9aae5jc3gp8sjkxtt988ctazxwcu00zz", "amount": [ { "denom": "ngonka", "amount": "15809776995" } ] }, { "recipient": "gonka1f2vks2fy4f3gvdmhgemlzygsmwgj4uwhr3eq87", "amount": [ { "denom": "ngonka", "amount": "15665265795" } ] }, { "recipient": "gonka1mvjsdf8cnxwx94umn4ylfnd6n9mjr062z5z2mj", "amount": [ { "denom": "ngonka", "amount": "15665265795" } ] }, { "recipient": "gonka1kmwyjt6nx29k72jtvgdeyduk7mvgra859utwr6", "amount": [ { "denom": "ngonka", "amount": "15521495000" } ] }, { "recipient": "gonka1vlcd8tr2nh5x6h4wl9vacpzucpp9a2p9rv8c57", "amount": [ { "denom": "ngonka", "amount": "15505364916" } ] }, { "recipient": "gonka1xxt27tswyf3aevmrh4g9w6pxhgvm5rhpcah0f3", "amount": [ { "denom": "ngonka", "amount": "15453041804" } ] }, { "recipient": "gonka1fvyenm5ms57hmyze8yl659c8ljg4r89nlwap9u", "amount": [ { "denom": "ngonka", "amount": "15416153987" } ] }, { "recipient": "gonka1swxxjxn2gyyjxur62ppty5c8uaa9m8s8tvajfx", "amount": [ { "denom": "ngonka", "amount": "15396149423" } ] }, { "recipient": "gonka1du3ra0wra9l7d8uqctdrdzneufpw54k3rngjme", "amount": [ { "denom": "ngonka", "amount": "15380717791" } ] }, { "recipient": "gonka1rd09mzfck3m3nfz3mhmlt6ker6ru2dg2ryhwkx", "amount": [ { "denom": "ngonka", "amount": "15359318274" } ] }, { "recipient": "gonka17eha2wcrge8zp36tn85ywgx7dqmwu6hux3wqpu", "amount": [ { "denom": "ngonka", "amount": "15245298006" } ] }, { "recipient": "gonka103w3g3q88yfvcaewfef0l4gmlsjhykdz76wxav", "amount": [ { "denom": "ngonka", "amount": "15233953411" } ] }, { "recipient": "gonka1xteg3zgysvkvfl4lzs5gwxpkgtx0qra6m90jv3", "amount": [ { "denom": "ngonka", "amount": "15057878015" } ] }, { "recipient": "gonka12ha2hfpkjqcs5qgkfl5symtuws9k5rcx0qeuea", "amount": [ { "denom": "ngonka", "amount": "14869979963" } ] }, { "recipient": "gonka1q8a0m7llx9vwpxlt9a4khn9t3d5wgfwcr34dyr", "amount": [ { "denom": "ngonka", "amount": "14714689688" } ] }, { "recipient": "gonka1mmd53mj5u5uepcznq3u4apyc8l7rg9g0d0ec6d", "amount": [ { "denom": "ngonka", "amount": "14662835696" } ] }, { "recipient": "gonka1se5fl8amfchfdy5sf4qzxrd7tuu7vua9aphy5x", "amount": [ { "denom": "ngonka", "amount": "14011977229" } ] }, { "recipient": "gonka19c58vpkdx4gyh6jqzwuhdt7mky534c939fhqg3", "amount": [ { "denom": "ngonka", "amount": "13868650238" } ] }, { "recipient": "gonka1qtd6sqrfhqlfzl5guvq4rh2jduayekf8sx7vze", "amount": [ { "denom": "ngonka", "amount": "13807478913" } ] }, { "recipient": "gonka1e0x4rzdmgcxh4a6e0vz7rncgudvvc06kf3tfpg", "amount": [ { "denom": "ngonka", "amount": "13644783323" } ] }, { "recipient": "gonka1ch7c2pseksehq76xpm9ghfd98ccjxqf7e698h4", "amount": [ { "denom": "ngonka", "amount": "13588546573" } ] }, { "recipient": "gonka17u6cwzx6f9jkngqllyw4z7fylwyymgvgv6gkj8", "amount": [ { "denom": "ngonka", "amount": "12545963620" } ] }, { "recipient": "gonka13xpjvala86d3y6jdjpnfk56ptjawq29t4gprtx", "amount": [ { "denom": "ngonka", "amount": "12189951247" } ] }, { "recipient": "gonka14htw7ph065xeugpwhcsqnvmemfpluhldrvzx6j", "amount": [ { "denom": "ngonka", "amount": "12056464578" } ] }, { "recipient": "gonka12u0uyuexgd37yexwxgwljzstgunaurswguehkx", "amount": [ { "denom": "ngonka", "amount": "12027960359" } ] }, { "recipient": "gonka16n8lkh7qtyme055xjshfmlrvts8s5ujx396s0d", "amount": [ { "denom": "ngonka", "amount": "11946641426" } ] }, { "recipient": "gonka1ye7unfm0nf6qa7awmcgxql7u2zq9fqv0g5qw3h", "amount": [ { "denom": "ngonka", "amount": "11690401599" } ] }, { "recipient": "gonka127ut4ut239agy405vmznj2jz3z57egrfuza7dw", "amount": [ { "denom": "ngonka", "amount": "11617342739" } ] }, { "recipient": "gonka1yuhp76axp2uvnflmlhjch2cmqcp0xf7595zklc", "amount": [ { "denom": "ngonka", "amount": "11247620300" } ] }, { "recipient": "gonka105ce4495mj0mwkxqeasgdzqfq5jjrfq32eza5l", "amount": [ { "denom": "ngonka", "amount": "10338358934" } ] }, { "recipient": "gonka1uf5cg7ef0ns6877nl27y0s6rt06cdmn40k5a88", "amount": [ { "denom": "ngonka", "amount": "10257214287" } ] } ], "vesting_epochs": "180" }, { "@type": "/cosmos.bank.v1beta1.MsgMultiSend", "inputs": [ { "address": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "coins": [ { "denom": "ngonka", "amount": "832642933775" } ] } ], "outputs": [ { "address": "gonka1azuz6leyh94mjyal7deprr2wpwqesr5530872r", "coins": [ { "denom": "ngonka", "amount": "9501541710" } ] }, { "address": "gonka137kvnsjwkz6aqdlsfz5nkuh04wamt7gydgm570", "coins": [ { "denom": "ngonka", "amount": "9452166946" } ] }, { "address": "gonka1f3qe6rwl8a8lga0atrdq7uqfu9dewl0vtg9rnv", "coins": [ { "denom": "ngonka", "amount": "9414778596" } ] }, { "address": "gonka1fezpsxrwms4njwkskesu0s5t8wl46ueegk5s3p", "coins": [ { "denom": "ngonka", "amount": "8844332803" } ] }, { "address": "gonka1tl9ws8h8wje933ggmp6qav870s2kt2vsl8nxtg", "coins": [ { "denom": "ngonka", "amount": "8792952388" } ] }, { "address": "gonka1enwgqdpwrthzwzl79xgcf936rt8n4zulnnn89p", "coins": [ { "denom": "ngonka", "amount": "8721856694" } ] }, { "address": "gonka15k9c2xzuman9mtggecwed2kpts0y7wgnnrgzvu", "coins": [ { "denom": "ngonka", "amount": "8704908709" } ] }, { "address": "gonka18gm3udhlraw29z4and3yde959fmu3rs9sqm3t6", "coins": [ { "denom": "ngonka", "amount": "8528426620" } ] }, { "address": "gonka1a32tfg0a3xe7zer9m3ttuxr57wdffpc82qnacq", "coins": [ { "denom": "ngonka", "amount": "8445259634" } ] }, { "address": "gonka1xtzmqjwf0au4ad5m3nmdu07262vjn605uxyjtu", "coins": [ { "denom": "ngonka", "amount": "8292640093" } ] }, { "address": "gonka135yst4re34z3rlfquhknqxvnaj35pjwu0mw622", "coins": [ { "denom": "ngonka", "amount": "8165434002" } ] }, { "address": "gonka1p8av4fdlefkwluhx864sw4h7nayytt6c7x9u43", "coins": [ { "denom": "ngonka", "amount": "8155197424" } ] }, { "address": "gonka19pe5zksljpfjydt64xz5yv7jxsr3cn2tqt8k9r", "coins": [ { "denom": "ngonka", "amount": "7685191084" } ] }, { "address": "gonka1gdg70vwrtr8gmal53zzq7d6xk2exh75uh2mtcm", "coins": [ { "denom": "ngonka", "amount": "7672285704" } ] }, { "address": "gonka143x3v0etsful8p4hznnltpeq8arz2g8lkrjumf", "coins": [ { "denom": "ngonka", "amount": "7493644311" } ] }, { "address": "gonka1h8fmjrpth99xt8ee0wrdljfg7fpvquc9d4et0d", "coins": [ { "denom": "ngonka", "amount": "7409052775" } ] }, { "address": "gonka1w6cjf08fgm3yalqf7ytt0hz6thlhs53d2fn7j2", "coins": [ { "denom": "ngonka", "amount": "7373299925" } ] }, { "address": "gonka12x78v2mjvvtnhnfmlrezdxejecwzzgxr5wjlty", "coins": [ { "denom": "ngonka", "amount": "7103237040" } ] }, { "address": "gonka1wwx6nhqe7xlyvqjs0r3wj767xaurcucvz0npmn", "coins": [ { "denom": "ngonka", "amount": "7078693293" } ] }, { "address": "gonka1zppcd072lkwv7wxpxv5rd06kz9yf0trexwqtps", "coins": [ { "denom": "ngonka", "amount": "6941440630" } ] }, { "address": "gonka15syzg3weelezg42agd3esadaa3t4tr5hcup57r", "coins": [ { "denom": "ngonka", "amount": "6602202484" } ] }, { "address": "gonka15pfa2nj0m0yrqcynqe2zegzpnttx4tfqp46fgm", "coins": [ { "denom": "ngonka", "amount": "6559062334" } ] }, { "address": "gonka1rad9yt3eyaflkhm4xpslk85ps4de2kae2fguyz", "coins": [ { "denom": "ngonka", "amount": "6537844596" } ] }, { "address": "gonka19ayh77ndf2k8ps2992vf6n70emsq09ngxuvqh9", "coins": [ { "denom": "ngonka", "amount": "6489763866" } ] }, { "address": "gonka1547gss5hs48tg024zg7cm3f4r747a8ed0mrgru", "coins": [ { "denom": "ngonka", "amount": "6244004304" } ] }, { "address": "gonka18dy9cn8e65kh6jy2j6v5du26tq9tkpf8e2n5uk", "coins": [ { "denom": "ngonka", "amount": "6174834101" } ] }, { "address": "gonka14rv62lyedvmmghs78qc4yymdtas6rdz3wjupty", "coins": [ { "denom": "ngonka", "amount": "6156917861" } ] }, { "address": "gonka1m7df6745x0vr02pf2lr369vapfzddh3jxhawvq", "coins": [ { "denom": "ngonka", "amount": "6144655815" } ] }, { "address": "gonka1qlulzskcx4n7ctlj3tjusjzl9vk5me8zrr7ysl", "coins": [ { "denom": "ngonka", "amount": "6081456323" } ] }, { "address": "gonka1vhg44vzedv5dzp8njajh8rtylxsctqr2xv5v6s", "coins": [ { "denom": "ngonka", "amount": "5972208238" } ] }, { "address": "gonka16a28hafy6j6p4z0gdt7tv68e393glanr3td979", "coins": [ { "denom": "ngonka", "amount": "5901353964" } ] }, { "address": "gonka1vkh8e2uqk9mdw0ql83g0p4ge0wmqstcasulngn", "coins": [ { "denom": "ngonka", "amount": "5811099649" } ] }, { "address": "gonka1s5997zeltdrwfc35pzzzznhk3908valhlnc76g", "coins": [ { "denom": "ngonka", "amount": "5765093045" } ] }, { "address": "gonka18yuxmht359nlwj40cdz6dlr8nyaulgk0gv9yma", "coins": [ { "denom": "ngonka", "amount": "5742736254" } ] }, { "address": "gonka1rlf0ggajudsvxuvgkukpmg2xwd06htv4vu2ktx", "coins": [ { "denom": "ngonka", "amount": "5712867994" } ] }, { "address": "gonka1xyj2jlq36rhauw7lx6zwmj26dregc7qqd660vz", "coins": [ { "denom": "ngonka", "amount": "5709268559" } ] }, { "address": "gonka1j2m047a6sujxeznp7rkvq5t64k3hu203cruufs", "coins": [ { "denom": "ngonka", "amount": "5390538673" } ] }, { "address": "gonka1nv7pw7xpydpkhxs35zgu450ymhzmtck0aryhls", "coins": [ { "denom": "ngonka", "amount": "5338417094" } ] }, { "address": "gonka15xr92pc7v0jvq5aqwqt43hpvvpvs3q5229lrmh", "coins": [ { "denom": "ngonka", "amount": "5307464452" } ] }, { "address": "gonka1a3pkge3g33v3zdkq7qmycpjwpulms6ejt8z00f", "coins": [ { "denom": "ngonka", "amount": "5264460448" } ] }, { "address": "gonka1nccp3l8d8n36akvaper2ngzpe8a843key0n985", "coins": [ { "denom": "ngonka", "amount": "5114884594" } ] }, { "address": "gonka1y2vf9hwhemy8rkn69nmqwuf90ndk5cr3985pf9", "coins": [ { "denom": "ngonka", "amount": "5080696083" } ] }, { "address": "gonka15p7s7w2hx0y8095lddd4ummm2y0kwpwljk00aq", "coins": [ { "denom": "ngonka", "amount": "5061339468" } ] }, { "address": "gonka1z669rrm4sygpede8sqddavhsef6wc9vwjsp9wh", "coins": [ { "denom": "ngonka", "amount": "5044445895" } ] }, { "address": "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "coins": [ { "denom": "ngonka", "amount": "4818475251" } ] }, { "address": "gonka1gvrssnvlsj6he2lyv40y5fpdawn2xuvtldqv99", "coins": [ { "denom": "ngonka", "amount": "4804965891" } ] }, { "address": "gonka1n80jruuunhn8q9scqkuqcvsq8dz3hv03zl6sjn", "coins": [ { "denom": "ngonka", "amount": "4800051495" } ] }, { "address": "gonka1pvlt0c9dqyxvxyzwf0t3q7ff2m2andsl4hakn9", "coins": [ { "denom": "ngonka", "amount": "4712678395" } ] }, { "address": "gonka12znqneqlv4va4he2vz2safylpx7kj6gw2r48d5", "coins": [ { "denom": "ngonka", "amount": "4529478439" } ] }, { "address": "gonka19hfr9trsvue37wfn7tpaqjlp6sdjhyzvyecyw7", "coins": [ { "denom": "ngonka", "amount": "4377146350" } ] }, { "address": "gonka1zkegnzhzcyeu9m74f8907tg5ga2dyhxnfuxm0w", "coins": [ { "denom": "ngonka", "amount": "4182985948" } ] }, { "address": "gonka1ke4t935aqvya0kcee2nxcjp82vk8sa3sjs60fh", "coins": [ { "denom": "ngonka", "amount": "4028980470" } ] }, { "address": "gonka1c7fjlg6p7l0ynydyzkzzkxdwue7y864tytj02g", "coins": [ { "denom": "ngonka", "amount": "3966294792" } ] }, { "address": "gonka1wuhwtgcrlq7j9yzlev73raej734a9ym4clslnr", "coins": [ { "denom": "ngonka", "amount": "3727207309" } ] }, { "address": "gonka1smjq2hmma0c42rvf4epkp6tgfpy5z9cqzp3kqd", "coins": [ { "denom": "ngonka", "amount": "3716196059" } ] }, { "address": "gonka1000aqvxfkugmfy9ygfq3waq9r6q97e2yzjkspk", "coins": [ { "denom": "ngonka", "amount": "3695515387" } ] }, { "address": "gonka10ham8mkawe850sk3aq9vfjvsw2nzvl63ulcuyl", "coins": [ { "denom": "ngonka", "amount": "3486710564" } ] }, { "address": "gonka1k2dvwkg22kqmgh0s6xt8xuk4s4ak0k4py05cyr", "coins": [ { "denom": "ngonka", "amount": "3449792975" } ] }, { "address": "gonka15fpzwc7d2z3r4y5475p6k7uqknnkj38gsus3d9", "coins": [ { "denom": "ngonka", "amount": "3404136954" } ] }, { "address": "gonka1ttnyggsrxqyaqkty5uy6umak6cy2epcycmgn7k", "coins": [ { "denom": "ngonka", "amount": "3403934586" } ] }, { "address": "gonka12uttst9yzdrfjqhjanvnlydq0dms2ktaljqaq8", "coins": [ { "denom": "ngonka", "amount": "3359427978" } ] }, { "address": "gonka16as27w5m0jtskdgxx6hyhhm6r3khechwcc6quw", "coins": [ { "denom": "ngonka", "amount": "3258925442" } ] }, { "address": "gonka1s0hm7zhcw2ms89g2s8lsfr9s02d88yfph9p75v", "coins": [ { "denom": "ngonka", "amount": "3163798107" } ] }, { "address": "gonka12favtgswt6sw2wx8ywf6fz5jz6dl09ga3s2tpu", "coins": [ { "denom": "ngonka", "amount": "3140706768" } ] }, { "address": "gonka188zesyhzwt6crz9dlcll2cs3wezput0kfren9t", "coins": [ { "denom": "ngonka", "amount": "3086954434" } ] }, { "address": "gonka1ed4dzdu86mz2jhmn8ddajdh79dmx2lqdhcdulv", "coins": [ { "denom": "ngonka", "amount": "3007115951" } ] }, { "address": "gonka1un2c9f66mg2g6xcpmulq9tqfs3vjd7nn0ftjs5", "coins": [ { "denom": "ngonka", "amount": "2968246664" } ] }, { "address": "gonka1q8pf6vaqxtnnwl896uytd0waejnypkv3wz6a94", "coins": [ { "denom": "ngonka", "amount": "2921590102" } ] }, { "address": "gonka1r9zhmnd99rq9knfzng6smasywxakw2r8ltjvp4", "coins": [ { "denom": "ngonka", "amount": "2921590102" } ] }, { "address": "gonka1rtq5mhv2mw9ammge8ezlyy6z0f4yz8c0gjlkcu", "coins": [ { "denom": "ngonka", "amount": "2921590102" } ] }, { "address": "gonka1xqrc7jrcx6rgv5zpngnm4yunsf5qvcmklygxn5", "coins": [ { "denom": "ngonka", "amount": "2921590102" } ] }, { "address": "gonka184jz8ja5gqkr3kt98a3a4syyypwj07j0qngukg", "coins": [ { "denom": "ngonka", "amount": "2918969582" } ] }, { "address": "gonka1948n747ayualpznexxchnx95pdnpu25mph804e", "coins": [ { "denom": "ngonka", "amount": "2761436531" } ] }, { "address": "gonka1vd44gk5gr8x7s6557sx6vnf4q7pn6q848qq7sl", "coins": [ { "denom": "ngonka", "amount": "2717813483" } ] }, { "address": "gonka1yn43f97x8hqq66nkezwykqcddngtz4ynwlk6y9", "coins": [ { "denom": "ngonka", "amount": "2717813483" } ] }, { "address": "gonka17nhm4sh9wugmrpmpdchpfv5l69n2na4q72y2ch", "coins": [ { "denom": "ngonka", "amount": "2717813482" } ] }, { "address": "gonka1u7pmx5k2s0fj37pge77vxyt2qn4ja8jjsgkl3d", "coins": [ { "denom": "ngonka", "amount": "2695474896" } ] }, { "address": "gonka1xmjrx334m6vsv32uvt0em0jzsd8zn9qfmntmy6", "coins": [ { "denom": "ngonka", "amount": "2564657593" } ] }, { "address": "gonka1gkdl40hfau92xwh39updqzzrpllaqv7fjanhlm", "coins": [ { "denom": "ngonka", "amount": "2527572548" } ] }, { "address": "gonka1xlskhflqewyv2uaalp4va6efmws2fudf3qxqrn", "coins": [ { "denom": "ngonka", "amount": "2446073554" } ] }, { "address": "gonka18vws9s85353vl20qyx5eemfuhdq0auf749hryn", "coins": [ { "denom": "ngonka", "amount": "2422922586" } ] }, { "address": "gonka1zq6edydsgjv6k34zh36td2h238wafd6p3r605z", "coins": [ { "denom": "ngonka", "amount": "2411889280" } ] }, { "address": "gonka1w4u0ylrw5sl7nczl52vfjzz8ccvgaltrnejklc", "coins": [ { "denom": "ngonka", "amount": "2405998742" } ] }, { "address": "gonka1rvpg7grgz7gdj2jgpawyc3g996hktavc4e8rf5", "coins": [ { "denom": "ngonka", "amount": "2401414751" } ] }, { "address": "gonka1tsjsvfv4n3gvwrjjla0suvwz3ypm42g0unpqpk", "coins": [ { "denom": "ngonka", "amount": "2401414751" } ] }, { "address": "gonka1wsrytagxfhv0kn89hnzvsp8pg4xqrxq4x87s48", "coins": [ { "denom": "ngonka", "amount": "2401414751" } ] }, { "address": "gonka1yql3sw3ptvysqgwvh6n0c2fjnyqjdd0wv4xnfn", "coins": [ { "denom": "ngonka", "amount": "2401414751" } ] }, { "address": "gonka16lksjaqq2gqpeexvqg4xgux6hdtms3wnk4jjle", "coins": [ { "denom": "ngonka", "amount": "2302664161" } ] }, { "address": "gonka1yhljtdxhznktmyvzns2gpeeqr8ytzcel42amg5", "coins": [ { "denom": "ngonka", "amount": "2273140919" } ] }, { "address": "gonka1xzt80teg2sx6245gt3p96qax6dcdr56f6keqwr", "coins": [ { "denom": "ngonka", "amount": "2271913154" } ] }, { "address": "gonka1p45pgtzjtjaq0nqxm0a6dstyeqa3lx5dpx253k", "coins": [ { "denom": "ngonka", "amount": "2263994957" } ] }, { "address": "gonka1c5mazlks00w89uumst0ghmk0jyug24ajjrmu4e", "coins": [ { "denom": "ngonka", "amount": "2256402589" } ] }, { "address": "gonka1leq6gdxs2d7fxqg7528hkq8tk50v2pdj2pzq9k", "coins": [ { "denom": "ngonka", "amount": "2241549835" } ] }, { "address": "gonka12mwqjk8y4svymxjndzw4cxcpp09pj9c072l26g", "coins": [ { "denom": "ngonka", "amount": "2229759398" } ] }, { "address": "gonka1elhpys4c6cg5k5n6093a6wm865gpyul3pr756q", "coins": [ { "denom": "ngonka", "amount": "2191785067" } ] }, { "address": "gonka1lutcrd6ylg63293aukds7pxardj6sl4pz2y2ls", "coins": [ { "denom": "ngonka", "amount": "2191785067" } ] }, { "address": "gonka1rccd6tq06vl2tq2rz9p6uxuuc8tn9878le92gp", "coins": [ { "denom": "ngonka", "amount": "2049597188" } ] }, { "address": "gonka1ft0x56racya2r7asndxdrwyy9ltl993f5h7zyz", "coins": [ { "denom": "ngonka", "amount": "2022244001" } ] }, { "address": "gonka105az9lyvju6l32qvl4xkzqru4cs4xuft8lh0e5", "coins": [ { "denom": "ngonka", "amount": "1993090946" } ] }, { "address": "gonka17f3cgvf0xd5rpafaqeugyqece62ahef2nexa9g", "coins": [ { "denom": "ngonka", "amount": "1993090946" } ] }, { "address": "gonka1kwqlf3mrlv4zg79ffuuq3uxesa22fkdfmfr9gq", "coins": [ { "denom": "ngonka", "amount": "1993090946" } ] }, { "address": "gonka1q5n2dyavs267z64kdljw4u8wy9y6a45sk020pu", "coins": [ { "denom": "ngonka", "amount": "1993090946" } ] }, { "address": "gonka1qlc7kpa3lm8fz0muw54unkwxd8rwt509y5jydd", "coins": [ { "denom": "ngonka", "amount": "1993090946" } ] }, { "address": "gonka1qp9pyg45lagg2gnpt83ryp05emlekp95jgzdja", "coins": [ { "denom": "ngonka", "amount": "1993090946" } ] }, { "address": "gonka1lf8zrnapty4nny6l9dr66nd7xc4j4ktr6rujha", "coins": [ { "denom": "ngonka", "amount": "1944133310" } ] }, { "address": "gonka1920xc45wphxgq22kfelxscp39jcc2vnmyxpday", "coins": [ { "denom": "ngonka", "amount": "1885982410" } ] }, { "address": "gonka1m935423dlgd36w2ezsn9npyfkvufk4nxmynmyf", "coins": [ { "denom": "ngonka", "amount": "1885982410" } ] }, { "address": "gonka1n3l720a7khmcx3th4xzsuttjv0xpq974ej3j6m", "coins": [ { "denom": "ngonka", "amount": "1885982410" } ] }, { "address": "gonka1slzst7ur93jz3rmakat5ygd0pyrl2nxexnwgrp", "coins": [ { "denom": "ngonka", "amount": "1885982410" } ] }, { "address": "gonka1x8emnupg2gajvsmy5zdtev26n60uh59zlqznz9", "coins": [ { "denom": "ngonka", "amount": "1885982410" } ] }, { "address": "gonka1l9eclck7nn4ame8zm26ahh4wd0j0v7atp9vuh7", "coins": [ { "denom": "ngonka", "amount": "1848732764" } ] }, { "address": "gonka19qz97dxgwgfzedtf8yzwzy43quwlggmq33hnuw", "coins": [ { "denom": "ngonka", "amount": "1844957304" } ] }, { "address": "gonka1tadzlvqgcj53nnqdlppnpxcvd98ygwp370a6tn", "coins": [ { "denom": "ngonka", "amount": "1844957304" } ] }, { "address": "gonka1w4y9r7g7fzh2zq8wxydlh4x9j26casunxfdzmk", "coins": [ { "denom": "ngonka", "amount": "1844957304" } ] }, { "address": "gonka12am8m49ejfg4n5sjxrjkgxjqeyv0knw2jxgzzg", "coins": [ { "denom": "ngonka", "amount": "1833988532" } ] }, { "address": "gonka14jrd4theu4uxr6qftuddnqehg2mrcqxzsgv4n0", "coins": [ { "denom": "ngonka", "amount": "1833988532" } ] }, { "address": "gonka18vanjpcvmnarm4t9fcdjjza3vdvnacv63n5675", "coins": [ { "denom": "ngonka", "amount": "1833988532" } ] }, { "address": "gonka1fqd0dz7mnq47p3puhpmgzvrl7x8l2awg0tlwx6", "coins": [ { "denom": "ngonka", "amount": "1833988532" } ] }, { "address": "gonka1rkzw2my8pmadftpkpfq7qnsca9fjr573xcv2m7", "coins": [ { "denom": "ngonka", "amount": "1833988532" } ] }, { "address": "gonka1ty2k0gdcnr9qflthxcd9mvmakva7arsv8m42qz", "coins": [ { "denom": "ngonka", "amount": "1833988532" } ] }, { "address": "gonka1u6gv92fshuc2z927224jecsc5hrwps4en3hlxc", "coins": [ { "denom": "ngonka", "amount": "1833988532" } ] }, { "address": "gonka1wua3u0ts50u0vs2hms9l6u04wnq3m94mn7whcq", "coins": [ { "denom": "ngonka", "amount": "1833988532" } ] }, { "address": "gonka1z43km02x94rryj03utuna9y3falahzy3fxl4kw", "coins": [ { "denom": "ngonka", "amount": "1833988532" } ] }, { "address": "gonka1tddep45jx77myyua8se2pltqe0glmp0mcgql5r", "coins": [ { "denom": "ngonka", "amount": "1813086360" } ] }, { "address": "gonka1tdm3u8fgwdqr07l9xutal8724986c4n2v8e0m7", "coins": [ { "denom": "ngonka", "amount": "1813086360" } ] }, { "address": "gonka1xp332v7jcrvyxnn20zumdfxajydak0mwxusngr", "coins": [ { "denom": "ngonka", "amount": "1813086360" } ] }, { "address": "gonka1zt4tedf2rqqdu7m53f5rhpt90pakvqcnnrg6fx", "coins": [ { "denom": "ngonka", "amount": "1813086360" } ] }, { "address": "gonka15llevgky75a7jknr5m0kzme669xuwrqdxex5f3", "coins": [ { "denom": "ngonka", "amount": "1809031774" } ] }, { "address": "gonka1m50khzaxc3pnhqpjgn8ptlv5ws5uhexnck5qht", "coins": [ { "denom": "ngonka", "amount": "1685013318" } ] }, { "address": "gonka1rd27hnfvz44x6tjc0j355yyxhgdwdkpwj6ppwq", "coins": [ { "denom": "ngonka", "amount": "1679070580" } ] }, { "address": "gonka15q3hcqdkvthz82rht3vxayfmx3u5hcq00evfxg", "coins": [ { "denom": "ngonka", "amount": "1663454722" } ] }, { "address": "gonka1r4ntslxj8f4xfmrmk939vrkknv2dfdr6rstkf9", "coins": [ { "denom": "ngonka", "amount": "1663454722" } ] }, { "address": "gonka1t45g664kkw3dhtcwgux3nvrtn9q5262ez5crlm", "coins": [ { "denom": "ngonka", "amount": "1663454722" } ] }, { "address": "gonka1tj0d67xcqhx7xv8fj96c4q0f46cdz6rx02pq8c", "coins": [ { "denom": "ngonka", "amount": "1663454722" } ] }, { "address": "gonka1wv38ew6cvmsv9t7y4h6jjdvp70k5s2mh4hhs2y", "coins": [ { "denom": "ngonka", "amount": "1663454722" } ] }, { "address": "gonka1x3uccqp4a6kse5d2r743m9zas5khz900w67hja", "coins": [ { "denom": "ngonka", "amount": "1663454722" } ] }, { "address": "gonka1z8pr9dy362yvvw9c0wx3fc8w9yrgv2ervakd3x", "coins": [ { "denom": "ngonka", "amount": "1663454722" } ] }, { "address": "gonka10rk42wkre2wp24m3n8u2maa4p2nm3ev5r0fwcy", "coins": [ { "denom": "ngonka", "amount": "1627117056" } ] }, { "address": "gonka1gz76l4rtf7rkg6fuhnyuq2w3letq9687pqznwy", "coins": [ { "denom": "ngonka", "amount": "1627117056" } ] }, { "address": "gonka1lmppztny6yhjcshlh5jd7484lms0hxvjpe8ytu", "coins": [ { "denom": "ngonka", "amount": "1627117056" } ] }, { "address": "gonka1m09t38h8fy20qx6896ht450j8rfmtdel6tq93x", "coins": [ { "denom": "ngonka", "amount": "1627117056" } ] }, { "address": "gonka1qfvwhm2cpz8y6ekvnqacmlgqhhjvws8ptkcygn", "coins": [ { "denom": "ngonka", "amount": "1627117056" } ] }, { "address": "gonka1u4vw85xxgvwmu4zgsy9fxd48w0x98d2hee98h6", "coins": [ { "denom": "ngonka", "amount": "1627117056" } ] }, { "address": "gonka1v6gq7sphhr6g7v9xnjl40uzlw39eay8t7vmc0y", "coins": [ { "denom": "ngonka", "amount": "1627117056" } ] }, { "address": "gonka1xn5rd6anmtkvdvd9hwh4d3pspxp8v458554fmk", "coins": [ { "denom": "ngonka", "amount": "1627117056" } ] }, { "address": "gonka143hahlzmxj26dlcdl5552yl9futt7jahjgeu69", "coins": [ { "denom": "ngonka", "amount": "1614219386" } ] }, { "address": "gonka1g9vvr2ynjjuf2etlzg6h22dxuxkl3zphrury58", "coins": [ { "denom": "ngonka", "amount": "1614219386" } ] }, { "address": "gonka1v3v0ydfpycqygs6jlvdzv7cjp04gsk24sepr9m", "coins": [ { "denom": "ngonka", "amount": "1614219386" } ] }, { "address": "gonka1wsx8enzwl8mnwkqfghl7gwe2x930s33qnhw4qp", "coins": [ { "denom": "ngonka", "amount": "1614219386" } ] }, { "address": "gonka1y69wttdm3vkadw004kmejj4c0dyae3cz25dxhj", "coins": [ { "denom": "ngonka", "amount": "1614219386" } ] }, { "address": "gonka1xk0hzuxrfja57xvm0r5n43v67h3cvhz4vq656l", "coins": [ { "denom": "ngonka", "amount": "1605362777" } ] }, { "address": "gonka1zqddqel0zwzae6zfeh4dpt45d5f656yghdenpp", "coins": [ { "denom": "ngonka", "amount": "1593305536" } ] }, { "address": "gonka18emzcnep4wf2kar3zy54cwl7j2j9g857q9q9qw", "coins": [ { "denom": "ngonka", "amount": "1589523430" } ] }, { "address": "gonka144sh6452klgn9mp2h9yjesdfv9qy27m3dp6pzm", "coins": [ { "denom": "ngonka", "amount": "1574995627" } ] }, { "address": "gonka1s2f53k0y5jydp25gfkz0rzxy3sxl35gyz5z3d7", "coins": [ { "denom": "ngonka", "amount": "1574995627" } ] }, { "address": "gonka1vg0ys6nafj3ete8g5td5lyag6fc06uxx40ylcu", "coins": [ { "denom": "ngonka", "amount": "1574995627" } ] }, { "address": "gonka1wmsag8tufeqxwefr8swh8v6ujy8h9z67scrxp0", "coins": [ { "denom": "ngonka", "amount": "1574995627" } ] }, { "address": "gonka1jn3ldkrdvdpcruz87p65cg8yy8dmpjrmq9g2cd", "coins": [ { "denom": "ngonka", "amount": "1531654714" } ] }, { "address": "gonka1uw65v6surnyfvykqvky6wq3s90zrknr6ceh38h", "coins": [ { "denom": "ngonka", "amount": "1531654714" } ] }, { "address": "gonka1wvs7grm0vc2a3d834sksk46hdc28ypu6dm7cmt", "coins": [ { "denom": "ngonka", "amount": "1531654714" } ] }, { "address": "gonka1ym9lr260763xk06ktu2mstmtcxztn34jvce35f", "coins": [ { "denom": "ngonka", "amount": "1531654714" } ] }, { "address": "gonka1fzh9xgz35ugt50z23wwcjvemrcq8mj34v60gme", "coins": [ { "denom": "ngonka", "amount": "1502935837" } ] }, { "address": "gonka1ke9m4zyygwa4cydfrmk6w9axthr84lwagejgve", "coins": [ { "denom": "ngonka", "amount": "1502935837" } ] }, { "address": "gonka1vll2z4rhell9kzwnagqzfwj3lqkkn4lvpyzduw", "coins": [ { "denom": "ngonka", "amount": "1502935837" } ] }, { "address": "gonka15ayg9m2kcek8l6ent5vmmczkkujumq0alrtgwz", "coins": [ { "denom": "ngonka", "amount": "1502935836" } ] }, { "address": "gonka12vq65qqgep5x2zvjxqzqtnsw2hpyz92czen8z5", "coins": [ { "denom": "ngonka", "amount": "1500945892" } ] }, { "address": "gonka1e94a7r2tn3n8ewa3mha3vjnq2dkvgt5stfqgqg", "coins": [ { "denom": "ngonka", "amount": "1500945892" } ] }, { "address": "gonka1ecercvenlsnghx4yakvdpdq2mantyh5ythhn29", "coins": [ { "denom": "ngonka", "amount": "1500945892" } ] }, { "address": "gonka1l7p83akwkcxtksnwve23x5wp47zammznm4qus8", "coins": [ { "denom": "ngonka", "amount": "1500945892" } ] }, { "address": "gonka1lwl6qhrdqw43sqc2y4eclfrngf799rnm7mmx87", "coins": [ { "denom": "ngonka", "amount": "1500945892" } ] }, { "address": "gonka1wfn87ruutktth7l8ne3rvhmlsscqxah09kua02", "coins": [ { "denom": "ngonka", "amount": "1500945892" } ] }, { "address": "gonka1wzujgkw64xvz3vqttg7ktl5tlsdga7l53g6d55", "coins": [ { "denom": "ngonka", "amount": "1500945892" } ] }, { "address": "gonka1j9xwc4d02qyujg9wvnegyk3sxtl52lc6lpa30r", "coins": [ { "denom": "ngonka", "amount": "1487110895" } ] }, { "address": "gonka1pumyaaza5qtjp0k5ur6nsyzq4n93aukph6vfex", "coins": [ { "denom": "ngonka", "amount": "1479023010" } ] }, { "address": "gonka1x55dmkfh9a0meenzwwmpdavnle0lz993xj5ayu", "coins": [ { "denom": "ngonka", "amount": "1479023010" } ] }, { "address": "gonka1j9eurz4unzt8g7ptk7sc0shmaty9gcsh64u6ap", "coins": [ { "denom": "ngonka", "amount": "1475638662" } ] }, { "address": "gonka17yy2ywjsdq652z275pte4rr7u3m7ujk7hzcy2p", "coins": [ { "denom": "ngonka", "amount": "1464169878" } ] }, { "address": "gonka1c3wneuskddk3ddx45454jhwjt679gtc3anl8c4", "coins": [ { "denom": "ngonka", "amount": "1464169878" } ] }, { "address": "gonka1n7wy6cx4mf3lw3r8ltasn2uxzxylamkrl4t0kh", "coins": [ { "denom": "ngonka", "amount": "1464169878" } ] }, { "address": "gonka1qfqj3853nxm4tesryz98fz32effv9t97s9qvcp", "coins": [ { "denom": "ngonka", "amount": "1464169878" } ] }, { "address": "gonka1slww044z57zd56q629zq4le82vw38gjkzfht8s", "coins": [ { "denom": "ngonka", "amount": "1464169878" } ] }, { "address": "gonka1yh2k3mtf4wy4ddgae29fxzdrfl3e2zcat927dq", "coins": [ { "denom": "ngonka", "amount": "1464169878" } ] }, { "address": "gonka1usnmdjdt2xfzyl9xll67mna8teupacwt0gx2yt", "coins": [ { "denom": "ngonka", "amount": "1462431155" } ] }, { "address": "gonka1ypsleu690v2pj7j7xeejcfwkdpk9ps7yfhdtdq", "coins": [ { "denom": "ngonka", "amount": "1462166420" } ] }, { "address": "gonka1zg8sly8kpvgmtg6mapx67du83n6u93z2l4vudj", "coins": [ { "denom": "ngonka", "amount": "1462166420" } ] }, { "address": "gonka1n6dhkcn2ek5yy948y487nj52hyp4mcvpxjjqed", "coins": [ { "denom": "ngonka", "amount": "1452515195" } ] }, { "address": "gonka1raes6xggfna8sxceh5z7slxvdzaa4x63hsdrr6", "coins": [ { "denom": "ngonka", "amount": "1452515195" } ] }, { "address": "gonka1y9y7027gllfnx0u04s0x4nx8u5mfaurgaw57hs", "coins": [ { "denom": "ngonka", "amount": "1452515195" } ] }, { "address": "gonka1yxjq6h8qq5kvf86004rhmxf2edwjdgynq22l4k", "coins": [ { "denom": "ngonka", "amount": "1452515195" } ] }, { "address": "gonka1zq5ar3u7l6hzrxgwn9qszy54pc89k7ueqsjwkn", "coins": [ { "denom": "ngonka", "amount": "1452515195" } ] }, { "address": "gonka1zxyjn6yuqm4e2v2wz2y7a9lhcxazc674dyvx5g", "coins": [ { "denom": "ngonka", "amount": "1452515195" } ] }, { "address": "gonka18jv6tlf26fekum8zxa5zmgnz7anqunkxddjaf9", "coins": [ { "denom": "ngonka", "amount": "1412735200" } ] }, { "address": "gonka1juyynkna0cwjg4xjlzuw62lk0u0jwnhuqegdkh", "coins": [ { "denom": "ngonka", "amount": "1412735200" } ] }, { "address": "gonka1wzm3dmnkymnuj8g5mxne9w453ef05mteun4cpz", "coins": [ { "denom": "ngonka", "amount": "1412735200" } ] }, { "address": "gonka1ylz70ycevzkv3t2s004xpetd2eqwj6ylr3fpv0", "coins": [ { "denom": "ngonka", "amount": "1412735200" } ] }, { "address": "gonka1zphxd376tvtev5drq09dtnj7nfxtghw6gtewpf", "coins": [ { "denom": "ngonka", "amount": "1412735200" } ] }, { "address": "gonka1442mg9djng8kvtmj5mjzenkakq4j7n3fs8tjkx", "coins": [ { "denom": "ngonka", "amount": "1403533787" } ] }, { "address": "gonka14sdm8urd88v49ns7n6hz99chpunxjkr0w3m8y7", "coins": [ { "denom": "ngonka", "amount": "1403533787" } ] }, { "address": "gonka16kc6rg5emg6n24pyu78a4m9p2q43tteppx4ee5", "coins": [ { "denom": "ngonka", "amount": "1403533787" } ] }, { "address": "gonka1cw76rlm0ewnj7d90fvgyp37rav9dv5hm3mvy3x", "coins": [ { "denom": "ngonka", "amount": "1403533787" } ] }, { "address": "gonka1eq8ptvu4mecxkdc7gj0eqzxp4ysjnz6f8ez43c", "coins": [ { "denom": "ngonka", "amount": "1403533787" } ] }, { "address": "gonka1ha7fpwwu9st0wgyyz9ahd3xchk05nx7mtj4ng8", "coins": [ { "denom": "ngonka", "amount": "1403533787" } ] }, { "address": "gonka1t9scyr8q6dh3xsajedllt6dn4szd06fvnqjt2y", "coins": [ { "denom": "ngonka", "amount": "1403533787" } ] }, { "address": "gonka1ttrglrkzc96auuaq6nrv0wdygwm7ph5887j9wr", "coins": [ { "denom": "ngonka", "amount": "1403533787" } ] }, { "address": "gonka19g7jp7tcpnh9ul6gkr3kdc3lmcy55w6swvql0f", "coins": [ { "denom": "ngonka", "amount": "1380879260" } ] }, { "address": "gonka1dgkjlfqrm56tr6evkydg2qkkldzancnm097hj4", "coins": [ { "denom": "ngonka", "amount": "1377704962" } ] }, { "address": "gonka1e38cgywjkf4hejnf9utmpguq3qug0s5rd45kqm", "coins": [ { "denom": "ngonka", "amount": "1350159486" } ] }, { "address": "gonka1jcelp2ad2x0jf2vnyhkhd6wquug0zpd09sxxw4", "coins": [ { "denom": "ngonka", "amount": "1350159486" } ] }, { "address": "gonka1kdmstpljv33v8lz457lmj8f9g995l7ygwm460s", "coins": [ { "denom": "ngonka", "amount": "1350159486" } ] }, { "address": "gonka1l0enytn32rklk95dxrdt3v39hktxdw79trvgj5", "coins": [ { "denom": "ngonka", "amount": "1350159486" } ] }, { "address": "gonka1l0qv64xdu3dk2zzm5vk97j0drcmkus95u50gqk", "coins": [ { "denom": "ngonka", "amount": "1350159486" } ] }, { "address": "gonka1l6pp6p5hgaa69rj0eazn73f7gkawue94fq5v9g", "coins": [ { "denom": "ngonka", "amount": "1350159486" } ] }, { "address": "gonka1nkzdygk3g2p2usnueuqxyep3462350hgzxs86s", "coins": [ { "denom": "ngonka", "amount": "1350159486" } ] }, { "address": "gonka1tmk2tzdneht6smu34pkmqdvu7p34qavvmwtwq2", "coins": [ { "denom": "ngonka", "amount": "1350159486" } ] }, { "address": "gonka1u9a7r4w76gult5n9ysadnual9fghkc6yda60wj", "coins": [ { "denom": "ngonka", "amount": "1350159486" } ] }, { "address": "gonka1usmu5mfu8vsafvsrsvdutl50vy8kumdhv0j2x9", "coins": [ { "denom": "ngonka", "amount": "1350159486" } ] }, { "address": "gonka1vcawx5jc2hahydd9sqw30hlxyd9ppupm9ez0yz", "coins": [ { "denom": "ngonka", "amount": "1350159486" } ] }, { "address": "gonka1y62nqpx6ywvshndet4806nf0wasm4959hv9fgu", "coins": [ { "denom": "ngonka", "amount": "1328322785" } ] }, { "address": "gonka18anrx4l59z34te42whq5nx3xy7ftlw0ka98lkx", "coins": [ { "denom": "ngonka", "amount": "1328014484" } ] }, { "address": "gonka1jxtdrqyjc52j7wm2h4ec8g7enjz9r3qjy2hn8g", "coins": [ { "denom": "ngonka", "amount": "1328014484" } ] }, { "address": "gonka1s9ecxss47vq0w0hwr72f6sdpthtasem9nx33tf", "coins": [ { "denom": "ngonka", "amount": "1328014484" } ] }, { "address": "gonka1xxmpgunsrg9ayx8zejnjw8zu76czmc8fre3ece", "coins": [ { "denom": "ngonka", "amount": "1328014484" } ] }, { "address": "gonka1ws5s5jrnkle6xwe4glk59yehq4qexgamjkct8c", "coins": [ { "denom": "ngonka", "amount": "1312191174" } ] }, { "address": "gonka132jlm2gj75cqyuvnnufv5uhnlmfm06jvm25zuv", "coins": [ { "denom": "ngonka", "amount": "1305380116" } ] }, { "address": "gonka167ez4nvjumd0rrk78awcvxawwmf505cwrvk5nq", "coins": [ { "denom": "ngonka", "amount": "1305380116" } ] }, { "address": "gonka1hmj9lrcxt9zds40uq94gga2ps7t7x75eky6cvq", "coins": [ { "denom": "ngonka", "amount": "1305380116" } ] }, { "address": "gonka1txq9e2jzdfhlnugd63u5630vqnzucwavrqnu4d", "coins": [ { "denom": "ngonka", "amount": "1305380116" } ] }, { "address": "gonka1w2d6hlurl8hn47emf59eenam99gng7j7hmafj5", "coins": [ { "denom": "ngonka", "amount": "1305380116" } ] }, { "address": "gonka16lsgkqgz25fj53rtp9kgdafec37kth6nnf4an4", "coins": [ { "denom": "ngonka", "amount": "1291375509" } ] }, { "address": "gonka1st5dm5ec3fl084y87wfklum6sv49n782k0tsnk", "coins": [ { "denom": "ngonka", "amount": "1291375509" } ] }, { "address": "gonka16m7l3g7hr3y0r3a5wdh0wmwh9rshye44ssyssw", "coins": [ { "denom": "ngonka", "amount": "1288230717" } ] }, { "address": "gonka1deyrcv9dfe5a5q9tn9k0ngv8c4p7sm3gq7v2vh", "coins": [ { "denom": "ngonka", "amount": "1288230717" } ] }, { "address": "gonka1f3p6j8euk9pv9ap9trvj2eusklny4ue7ys9gun", "coins": [ { "denom": "ngonka", "amount": "1283740510" } ] }, { "address": "gonka1v559jhxth9uqj30f3k78tpd202lyf6x2h8g6c2", "coins": [ { "denom": "ngonka", "amount": "1283740510" } ] }, { "address": "gonka1vye2pcqanatat8n7haxq4ddf3wtlrdefxuxsru", "coins": [ { "denom": "ngonka", "amount": "1283740510" } ] }, { "address": "gonka1qa2dzvnva77uc2778rtvz69n27uau8jtetr4g7", "coins": [ { "denom": "ngonka", "amount": "1279683947" } ] }, { "address": "gonka1ue0adff609mng4n78l4vs8vc4fgaz93xcylt9m", "coins": [ { "denom": "ngonka", "amount": "1235205415" } ] }, { "address": "gonka16dhzkyjqvqt2f6h9s9f0fx0dpqaukq5hu47uul", "coins": [ { "denom": "ngonka", "amount": "1233899971" } ] }, { "address": "gonka1287a8wk9nnd7w96ejr5qkj3a04hcf4nmtckc8p", "coins": [ { "denom": "ngonka", "amount": "1226742101" } ] }, { "address": "gonka14z0upz96hw5sd6jgw4qpmy4lfjg294y560f7te", "coins": [ { "denom": "ngonka", "amount": "1226742101" } ] }, { "address": "gonka18g789gnqf4990eel5dzgpx383t0fzdef6nmw2q", "coins": [ { "denom": "ngonka", "amount": "1226742101" } ] }, { "address": "gonka1h82jwcefsu9ur3yfj97593tlyve2jes89kyqg4", "coins": [ { "denom": "ngonka", "amount": "1226742101" } ] }, { "address": "gonka1uuywlyxfddqrjgpz8u4lqevz838qr30rp020yp", "coins": [ { "denom": "ngonka", "amount": "1226742101" } ] }, { "address": "gonka123vh2t9er866647lsn6kclt8lfq2l9kwy4le76", "coins": [ { "denom": "ngonka", "amount": "1210440236" } ] }, { "address": "gonka17et3ctw6t4d5ylnuc2kwc8xrlwk69y0cggzjqm", "coins": [ { "denom": "ngonka", "amount": "1178466861" } ] }, { "address": "gonka169ms5ewh68ervhaxslul5cmfaavnt57nkmrvgt", "coins": [ { "denom": "ngonka", "amount": "1175204200" } ] }, { "address": "gonka1sg7amslhnqrw6qyvkdt5f6ru8kakyw5uss0mj7", "coins": [ { "denom": "ngonka", "amount": "1175204200" } ] }, { "address": "gonka1wpy06qhy7j7a0zcsax0q94za5p0g9g3g2sc32y", "coins": [ { "denom": "ngonka", "amount": "1175204200" } ] }, { "address": "gonka1cp45adu29a93qp8fwqn9sqt2hyqkl8qc5hty58", "coins": [ { "denom": "ngonka", "amount": "1171383222" } ] }, { "address": "gonka1ea8zl02zfvpxlpgdpywky9za5yy0ufy7htrwqz", "coins": [ { "denom": "ngonka", "amount": "1171383222" } ] }, { "address": "gonka1we6ghh9kgtm5na6wf3cyfjvj5fauuln08nx3r4", "coins": [ { "denom": "ngonka", "amount": "1171383222" } ] }, { "address": "gonka1000j4nzln9sg895wqvxn8eg5yrtpvgj2hxsqyw", "coins": [ { "denom": "ngonka", "amount": "1169798309" } ] }, { "address": "gonka1rmr4x8lyw76gzuyzta68gj965zfa00gzh2aszz", "coins": [ { "denom": "ngonka", "amount": "1151289716" } ] }, { "address": "gonka12fdlw5g8wex6v74nd42vfhnympsz5kn8p3adh5", "coins": [ { "denom": "ngonka", "amount": "1130375146" } ] }, { "address": "gonka1cenhl8aucrr06z5wtprdpaxa0dutzt90rgkt99", "coins": [ { "denom": "ngonka", "amount": "1130375146" } ] }, { "address": "gonka1dhn7hjn6udpyv6gkhfulnalufv4947a4e9kyne", "coins": [ { "denom": "ngonka", "amount": "1130375146" } ] }, { "address": "gonka1p3hklp6flhdffdkwr70azcsum77fha3ecqwgg0", "coins": [ { "denom": "ngonka", "amount": "1130375146" } ] }, { "address": "gonka1s43peau7vafujfxyape603yklhdzjh2stq702z", "coins": [ { "denom": "ngonka", "amount": "1130375146" } ] }, { "address": "gonka1xmgcpaw6n57ewn6s2fhggxaakemaaxuv4pdpmq", "coins": [ { "denom": "ngonka", "amount": "1130375146" } ] }, { "address": "gonka1dzg3tnd6ygsw0tf06fcu9tc7sw3jzrwx6ftv7c", "coins": [ { "denom": "ngonka", "amount": "1114827285" } ] }, { "address": "gonka1pka4am8g4atxzlgm3m6sy09uel7ecegtsp04zf", "coins": [ { "denom": "ngonka", "amount": "1090219613" } ] }, { "address": "gonka10jjrlvkfkqupgudz0l603sq99y3wkt3urwjm0x", "coins": [ { "denom": "ngonka", "amount": "1088838295" } ] }, { "address": "gonka174jxwp94lwgqr4nwlj5kke3z6fnat6p5dlg55x", "coins": [ { "denom": "ngonka", "amount": "1079384495" } ] }, { "address": "gonka1ek6mqw0g0jzee3gexx70nepqw86dxmknur6f42", "coins": [ { "denom": "ngonka", "amount": "1079384495" } ] }, { "address": "gonka1mgu675kpx9fxftcs80x7sn4tdxcsqfnhes5j88", "coins": [ { "denom": "ngonka", "amount": "1079384495" } ] }, { "address": "gonka1u9pwgk75elh6qk9ehjm38xx4h9xzt99us3meud", "coins": [ { "denom": "ngonka", "amount": "1079384495" } ] }, { "address": "gonka1y4fvesetallc8w5srs3fdeaashzez0v2maksey", "coins": [ { "denom": "ngonka", "amount": "1079384495" } ] }, { "address": "gonka1yvygc3csnr2c6ee6lag82wk7p2s9vss0npu7an", "coins": [ { "denom": "ngonka", "amount": "1079384495" } ] }, { "address": "gonka1amqg6l5eshydfnhlyhncshducrfnrde58rsmrh", "coins": [ { "denom": "ngonka", "amount": "1052725900" } ] }, { "address": "gonka1cldfsqjcch9w892eumdhc5ru80psjt6jck0tg4", "coins": [ { "denom": "ngonka", "amount": "1051968845" } ] }, { "address": "gonka1r9e4ew3na86n2mqzwz057930rxq5yycxpj9shj", "coins": [ { "denom": "ngonka", "amount": "1051968845" } ] }, { "address": "gonka1smep2w2jmng5987qujy37ux0jf3xrj6kdy59qn", "coins": [ { "denom": "ngonka", "amount": "1051968845" } ] }, { "address": "gonka1syr9s5dha0qcanrd2jpx6f85965yde0nytyux4", "coins": [ { "denom": "ngonka", "amount": "1051968845" } ] }, { "address": "gonka1vewz77c875qr8lvr0m62wmf0lw8lv3qr94g6e4", "coins": [ { "denom": "ngonka", "amount": "1051968845" } ] }, { "address": "gonka1xj5cdd7qfpjsste7lyz8ktfj7xl5q3kjydf3un", "coins": [ { "denom": "ngonka", "amount": "1051968845" } ] }, { "address": "gonka1vev00u8gl87e22eq8zpsr8lrnmhpvk4hl0yx3d", "coins": [ { "denom": "ngonka", "amount": "1022338944" } ] }, { "address": "gonka17py7gzq2pa75eu2z0wzp9kjum20zgxxk2jrxss", "coins": [ { "denom": "ngonka", "amount": "1012832854" } ] }, { "address": "gonka1cur9xf76n8gvgvw608r3kaxfeamyafpw5wkc99", "coins": [ { "denom": "ngonka", "amount": "1012832854" } ] }, { "address": "gonka1dc645alkwumpj3fuhxg4xu6hc255w3q5s9p3rs", "coins": [ { "denom": "ngonka", "amount": "1012832854" } ] }, { "address": "gonka1fwyt5sz43zs3hc8k0r5cgquvss9d6aa2975pfw", "coins": [ { "denom": "ngonka", "amount": "1012832854" } ] }, { "address": "gonka1jfs2xqkykvlpgfahslqpljr5sxcekw7s8kutvl", "coins": [ { "denom": "ngonka", "amount": "1012832854" } ] }, { "address": "gonka1lvmvyuv982ev45srx4yzj8xa4kk63n4ecswq07", "coins": [ { "denom": "ngonka", "amount": "1012832854" } ] }, { "address": "gonka18tm9tu9rak460pjdpj6xvfeffk474h6xhgme3c", "coins": [ { "denom": "ngonka", "amount": "1000955959" } ] }, { "address": "gonka1lyc347ysjruw7hvvejekqwu0y62cq0898dzarl", "coins": [ { "denom": "ngonka", "amount": "1000955959" } ] }, { "address": "gonka1pcu4wfdv2jtpfsnhgjk4zp7d46z47928xj73st", "coins": [ { "denom": "ngonka", "amount": "1000955959" } ] }, { "address": "gonka1qv2dwvqxt542k5ewhggm2wtcpadvzg6mzupzg8", "coins": [ { "denom": "ngonka", "amount": "1000955959" } ] }, { "address": "gonka1upq4e3ahzea8mu5mhrdptff94xru98lx47h43z", "coins": [ { "denom": "ngonka", "amount": "1000955959" } ] }, { "address": "gonka1x20c5d9wzatlr0t69xjm05x9uemq9mnk00udfa", "coins": [ { "denom": "ngonka", "amount": "1000955959" } ] }, { "address": "gonka1yrfq267gf5jz76m3j5sln7f5h00t9g6fmat4gp", "coins": [ { "denom": "ngonka", "amount": "1000955959" } ] }, { "address": "gonka1yukev873tps58s6rlkh6czs5rrqp2sdqw7pm58", "coins": [ { "denom": "ngonka", "amount": "1000955959" } ] }, { "address": "gonka1t4xjvjtrr6fkw50d0mqz93004jh52x62apdlqj", "coins": [ { "denom": "ngonka", "amount": "992484682" } ] }, { "address": "gonka18qpw36ctvuea4g4ygvhlquhefc9ckglffelm98", "coins": [ { "denom": "ngonka", "amount": "989308146" } ] }, { "address": "gonka1svytprwy050gprlvhp44nkyzfss53y07d8fnj6", "coins": [ { "denom": "ngonka", "amount": "989308146" } ] }, { "address": "gonka1x0wr4u4jnzyqsvme97zy8p2uqdl9llxf938uh4", "coins": [ { "denom": "ngonka", "amount": "989308146" } ] }, { "address": "gonka1wk44rwpyrfe3urqmepx8g7n5wh44j57ywhmzny", "coins": [ { "denom": "ngonka", "amount": "978610621" } ] }, { "address": "gonka1rhswewu6mczgme9p87uwtyufu3px3t8vksn22c", "coins": [ { "denom": "ngonka", "amount": "971125899" } ] }, { "address": "gonka1lc6gsl33geyvknx9fl54p2rlzjxjvygwfyul74", "coins": [ { "denom": "ngonka", "amount": "951668342" } ] }, { "address": "gonka1u6ckk5ql3c0xjvha5ll3mhv9cr047njvazx648", "coins": [ { "denom": "ngonka", "amount": "935153654" } ] }, { "address": "gonka18a9dnx4u7z0jqf66l4uk6zgnhszhd4qs5u7447", "coins": [ { "denom": "ngonka", "amount": "929101099" } ] }, { "address": "gonka19tq260hnd4y83q9m7nk6q5yc9xenesukvznak4", "coins": [ { "denom": "ngonka", "amount": "929101099" } ] }, { "address": "gonka1m4hsj08wgcjnwdjlnssed0tr4umralj6p5lfsf", "coins": [ { "denom": "ngonka", "amount": "929101099" } ] }, { "address": "gonka1tr9v4n6v7tycc2rplnazxfa672h82sgg7w5z8k", "coins": [ { "denom": "ngonka", "amount": "929101099" } ] }, { "address": "gonka1u4zpegkxj5aj3pkpvgyukh8n2cswc3njk7xf40", "coins": [ { "denom": "ngonka", "amount": "929101099" } ] }, { "address": "gonka1wxgfseq4t6ph7jfrvrnjkf88424n7d93e5pskz", "coins": [ { "denom": "ngonka", "amount": "929101099" } ] }, { "address": "gonka18d032cycta26ussz94was3us7tlwcgh4gx75xp", "coins": [ { "denom": "ngonka", "amount": "922450792" } ] }, { "address": "gonka1grj4l6fr9uqj43tqqe6m4st7a6zwam8rznzryy", "coins": [ { "denom": "ngonka", "amount": "922450792" } ] }, { "address": "gonka1nfz6dszuzcewxaukt7t6natedpdjptf9r7uxwg", "coins": [ { "denom": "ngonka", "amount": "922450792" } ] }, { "address": "gonka1quj84w0dqrkk4jklyg5p0dkvvukey3lnchu9f3", "coins": [ { "denom": "ngonka", "amount": "922450792" } ] }, { "address": "gonka1rs5hvyh4rs2f0y9ywkmwfek8r0d59tf4pvknwg", "coins": [ { "denom": "ngonka", "amount": "922450792" } ] }, { "address": "gonka1tmngrjsrnwu3d3c7r3043wf2ml692w0pnpu044", "coins": [ { "denom": "ngonka", "amount": "922450792" } ] }, { "address": "gonka1u8s6vtmp79an7f7xw8hmrmvlntadf3j8na3ajc", "coins": [ { "denom": "ngonka", "amount": "922450792" } ] }, { "address": "gonka1djk2tqcjsqqd56rfz4p5lmpwwug297zs8ygmx3", "coins": [ { "denom": "ngonka", "amount": "920305803" } ] }, { "address": "gonka1hkccmh2jc7c8wfs5ydtelx8x6m5957ae200dre", "coins": [ { "denom": "ngonka", "amount": "920305803" } ] }, { "address": "gonka1l3f79kphpczsw4cz357cxue98gjpcuyxrczh8e", "coins": [ { "denom": "ngonka", "amount": "920305803" } ] }, { "address": "gonka1u5ex4n6r7cjqkkqm4wh5khtzxaee7v52yce29n", "coins": [ { "denom": "ngonka", "amount": "920305803" } ] }, { "address": "gonka1x805263eml3mwyeny8cvdpe9q27f4ku3h2yatl", "coins": [ { "denom": "ngonka", "amount": "920305803" } ] }, { "address": "gonka1xsntypk5ehu70rvy4nxh49d7zvk6nwf8tj2xd8", "coins": [ { "denom": "ngonka", "amount": "920305803" } ] }, { "address": "gonka16qm4h6qlv5q65cz6q4m4z4h252tzk55hfu0u6f", "coins": [ { "denom": "ngonka", "amount": "912027590" } ] }, { "address": "gonka1puuuug080fa7p3kpdvwq624ufnxe4vqg8yd62f", "coins": [ { "denom": "ngonka", "amount": "912027590" } ] }, { "address": "gonka1r6xg9wcw2ekrlyyp0ct04zqv23dz695tcdx6vh", "coins": [ { "denom": "ngonka", "amount": "912027590" } ] }, { "address": "gonka1rkr3np6d965ztapgle7hlynvdtx5pqqwef9ks8", "coins": [ { "denom": "ngonka", "amount": "912027590" } ] }, { "address": "gonka1vxusszuq3z92ck4q5vkd877zu5grk7qu2j7dqf", "coins": [ { "denom": "ngonka", "amount": "912027590" } ] }, { "address": "gonka1xnf7rsktgug63zfl68f22rnecljruzyk6f0ja6", "coins": [ { "denom": "ngonka", "amount": "912027590" } ] }, { "address": "gonka17sktsm7djnwla0txhlq3lpeekw3jz38y2shqj3", "coins": [ { "denom": "ngonka", "amount": "903465613" } ] }, { "address": "gonka19u7w9jek8y5nj7qzssm3x6a8p2ukmrxrust6qs", "coins": [ { "denom": "ngonka", "amount": "903465613" } ] }, { "address": "gonka1fwum8860xfxfqghem7npn643ppftsfevwply74", "coins": [ { "denom": "ngonka", "amount": "903465613" } ] }, { "address": "gonka1x3szaeuwkx6c6wal4h3pr6z5a5d6p7dus4jy3h", "coins": [ { "denom": "ngonka", "amount": "903465613" } ] }, { "address": "gonka146a8kuv4hf6lg5ex0h7k89vwld2c7lwp5923cy", "coins": [ { "denom": "ngonka", "amount": "903465612" } ] }, { "address": "gonka15dyl07mzr3h6harfrmkkav9vhgv64gsa3qp0s8", "coins": [ { "denom": "ngonka", "amount": "903465612" } ] }, { "address": "gonka1l3m5ake2y2aeka55x62dxem4dd52fyaku2vz3j", "coins": [ { "denom": "ngonka", "amount": "897394442" } ] }, { "address": "gonka10cgunscfhdwjmndzcjv7znyj8nmdrf2jacxn0x", "coins": [ { "denom": "ngonka", "amount": "889432972" } ] }, { "address": "gonka13v2qrzt2r8c0ctwct8j9hzqwew27chx6uwvlkm", "coins": [ { "denom": "ngonka", "amount": "889432972" } ] }, { "address": "gonka15an2wjcwrqlmqfn52hcycqdqegepdwraux8eqw", "coins": [ { "denom": "ngonka", "amount": "889432972" } ] }, { "address": "gonka194pzpr7mqwkdldzgpfaadd8wwu663t3yaupcus", "coins": [ { "denom": "ngonka", "amount": "889432972" } ] }, { "address": "gonka1a7ckfc5a9r8w87w3kfw5cxa7fhww67vk7krh03", "coins": [ { "denom": "ngonka", "amount": "889432972" } ] }, { "address": "gonka1k6tjjlcj5y0rt3zu4gjq3pqjfync84v84atdel", "coins": [ { "denom": "ngonka", "amount": "889432972" } ] }, { "address": "gonka1ym3p4nn8r6xydcj9a5jg88fwfquc23ndufh4td", "coins": [ { "denom": "ngonka", "amount": "889432972" } ] }, { "address": "gonka1lc3a4lshfj5a7axh5w78edv8lc33hyyjef5692", "coins": [ { "denom": "ngonka", "amount": "870471367" } ] }, { "address": "gonka14cee9dv3ew5chhttaka7p5q6ua0dfep5eqs0js", "coins": [ { "denom": "ngonka", "amount": "864229823" } ] }, { "address": "gonka16rq8wlak0r4v9cdqs8sk3k4j28rxveyzn4eu4h", "coins": [ { "denom": "ngonka", "amount": "864229823" } ] }, { "address": "gonka19akvnwa3dvw8zkthcm36vegvwmymkr3hxq0qve", "coins": [ { "denom": "ngonka", "amount": "864229823" } ] }, { "address": "gonka1mjcyendh6mej6w6s2xymklpenn6ggw46l78esp", "coins": [ { "denom": "ngonka", "amount": "864229823" } ] }, { "address": "gonka1ve37whw9475rj3l0dy57xch9rnjcha9afv4f3s", "coins": [ { "denom": "ngonka", "amount": "864229823" } ] }, { "address": "gonka19mh7jn9xmzz9m0nrczgd32usqrcqm7mpsrh77j", "coins": [ { "denom": "ngonka", "amount": "845482324" } ] }, { "address": "gonka1l3f9ze5n0fdwyaz4r9faeujhhx7szc53p9gclf", "coins": [ { "denom": "ngonka", "amount": "820297858" } ] }, { "address": "gonka1a8dz4xw9xwwe0s3myandm6t0v4kvwea7pwrsmq", "coins": [ { "denom": "ngonka", "amount": "816800688" } ] }, { "address": "gonka1xnnu7yj6lsdmh3cjne9hk929y6yx8u5rwredz0", "coins": [ { "denom": "ngonka", "amount": "816800688" } ] }, { "address": "gonka14dd23kqxte3yhuae93g953ehh73f3djnuq0ern", "coins": [ { "denom": "ngonka", "amount": "806821251" } ] }, { "address": "gonka15ra622ntmvwys9mxqncn2uv9vwknlytfu959ff", "coins": [ { "denom": "ngonka", "amount": "806821251" } ] }, { "address": "gonka17f97mtfja2d38q8vjw5vsx8w833398aymznrxm", "coins": [ { "denom": "ngonka", "amount": "806821251" } ] }, { "address": "gonka19w0rclzvhpt0h9skdptfpaz5jw2t80ml2geuw9", "coins": [ { "denom": "ngonka", "amount": "806821251" } ] }, { "address": "gonka1k5cycfsyhqk8txq95gtfffhpg20h6vlk84tdhv", "coins": [ { "denom": "ngonka", "amount": "806821251" } ] }, { "address": "gonka1qzfec6p82ssja27nzs09ch09p87lqu3xx5e50f", "coins": [ { "denom": "ngonka", "amount": "806821251" } ] }, { "address": "gonka1whtj4z520meenq52f2zudu8zwmu06vg389x7pu", "coins": [ { "denom": "ngonka", "amount": "806821251" } ] }, { "address": "gonka1y9ayc8l9jxypsgmpqup0ean597g0ftlywf7urd", "coins": [ { "denom": "ngonka", "amount": "806821251" } ] }, { "address": "gonka18zmmjk9799qeu7s2cku5yh3ty6xayxds7n42gh", "coins": [ { "denom": "ngonka", "amount": "803064557" } ] }, { "address": "gonka1mkwqr346yy5ag0x450hht9ndl2wqhuzrfz0fd7", "coins": [ { "denom": "ngonka", "amount": "803064557" } ] }, { "address": "gonka1v3y4tse5aj58d7kxe4jqsw6e2hedewd82d737c", "coins": [ { "denom": "ngonka", "amount": "803064557" } ] }, { "address": "gonka1w5xvh0ag9a2vd43lrurx5emlckth8fzv2tvepu", "coins": [ { "denom": "ngonka", "amount": "803064557" } ] }, { "address": "gonka1zqj957tgjylep4vctsz8rw827slsddqww8drj5", "coins": [ { "denom": "ngonka", "amount": "803064557" } ] }, { "address": "gonka1rh9eca49arpw96m2zmvr2usk9qdy6q5gns8gj7", "coins": [ { "denom": "ngonka", "amount": "771105184" } ] }, { "address": "gonka1sv2jztqucv0z6whq6k3wlnd3u2qezpplrwyhdx", "coins": [ { "denom": "ngonka", "amount": "736873285" } ] }, { "address": "gonka1w6clgj4gjpd3r28gjp7vrza3rwzujl4gty6ln7", "coins": [ { "denom": "ngonka", "amount": "735506121" } ] }, { "address": "gonka1dll7aqkqleqt8s363fx2s3versn3r3c0zt3vj0", "coins": [ { "denom": "ngonka", "amount": "729725585" } ] }, { "address": "gonka1q6h4shel59yz6hqshz3ncdtegulj9840nzzyxs", "coins": [ { "denom": "ngonka", "amount": "728601300" } ] }, { "address": "gonka1w0tchrxx49gfc0n8jua94pav7tw0l5hrhuzywl", "coins": [ { "denom": "ngonka", "amount": "719208754" } ] }, { "address": "gonka1qre9aepalndahwj37xrcepndmut2vu9dr3kh4t", "coins": [ { "denom": "ngonka", "amount": "703040454" } ] }, { "address": "gonka1rxgvr9yg6xk3l2dak8glg0ld587q2wzzslvrl3", "coins": [ { "denom": "ngonka", "amount": "699277690" } ] }, { "address": "gonka1t9yhhn62sx36kg89h7js2ts507s46mqd40pe4s", "coins": [ { "denom": "ngonka", "amount": "699277690" } ] }, { "address": "gonka1z0lnxp7el2gxcqm37ckg8dfuac4rkuzf54wpa3", "coins": [ { "denom": "ngonka", "amount": "699277690" } ] }, { "address": "gonka1dpee7kv4dwlmu9nr3skv488lxuhwsy3x70h0uq", "coins": [ { "denom": "ngonka", "amount": "692810573" } ] }, { "address": "gonka1rq3skz3zfawkh7qsnjyzy9r3wf0xq8at096wy7", "coins": [ { "denom": "ngonka", "amount": "648016885" } ] }, { "address": "gonka1at7qj6ynelhp9kc3mgkw94m8j6jhrfh8wxse4n", "coins": [ { "denom": "ngonka", "amount": "644755098" } ] }, { "address": "gonka1q8a7k5dl82znt5xwe7f63523gxd8h027epdg54", "coins": [ { "denom": "ngonka", "amount": "586647280" } ] }, { "address": "gonka12yxxjv4n3al94jgythp4jqyas8een5pu6xr2nr", "coins": [ { "denom": "ngonka", "amount": "586612174" } ] }, { "address": "gonka1cfmrgwmxv9dh5knq2p4fehqpnudr4xm72gnpkm", "coins": [ { "denom": "ngonka", "amount": "586612174" } ] }, { "address": "gonka1mf3w6hjc3y56tk85zqqgj25rxmp6wuv0vr74d7", "coins": [ { "denom": "ngonka", "amount": "586612174" } ] }, { "address": "gonka1psznjawqr5m4dashm90wp46aq047twrxeel6qe", "coins": [ { "denom": "ngonka", "amount": "586612174" } ] }, { "address": "gonka1v5e25pcuvnv7q8vd2uwhvkkhskfs5laaxx3g8s", "coins": [ { "denom": "ngonka", "amount": "586612174" } ] }, { "address": "gonka1wttl0ghw929832auepgvq3gqrpfatcnfrzvqw2", "coins": [ { "denom": "ngonka", "amount": "586612174" } ] }, { "address": "gonka1y4rhy7fd7hlkrntctmxyehjkq8rrzp27nenk9v", "coins": [ { "denom": "ngonka", "amount": "586612174" } ] }, { "address": "gonka1yrqlpjnpqv9d626vl8s29vk383x74s0k5tdtd0", "coins": [ { "denom": "ngonka", "amount": "586612174" } ] }, { "address": "gonka1yr7r80d483ukqeq3xkx6ymgqm6r22n5wdv8atj", "coins": [ { "denom": "ngonka", "amount": "585881308" } ] }, { "address": "gonka1c2vpftj3n7679qp3k57yrtlhwp4qaay7ege9u8", "coins": [ { "denom": "ngonka", "amount": "560510475" } ] }, { "address": "gonka1dmrm7jd0lrrgj346sz4kajdq9c3ves860c7hhy", "coins": [ { "denom": "ngonka", "amount": "560510475" } ] }, { "address": "gonka1l0e82j7tr3urs3ekrdqluchv47e0n4y0e5ulgg", "coins": [ { "denom": "ngonka", "amount": "560510475" } ] }, { "address": "gonka16jrtxjqd8dznacsrtjpkf5mx0knja2xvwrgndp", "coins": [ { "denom": "ngonka", "amount": "559789055" } ] }, { "address": "gonka149ln5ehu48p00qalzafv7y3rkp6p7rmv8h3g8n", "coins": [ { "denom": "ngonka", "amount": "552021686" } ] }, { "address": "gonka1z3z2lyte45juefxfmsvhnqny7wfg9npmp8gm03", "coins": [ { "denom": "ngonka", "amount": "552021686" } ] }, { "address": "gonka1z7jrc6dvktlr6fccaj37jm4ncgj29jqrp5jvu7", "coins": [ { "denom": "ngonka", "amount": "552021686" } ] }, { "address": "gonka1t9pfwfag57kxmf3kyt088la4d8f892v24jvsf5", "coins": [ { "denom": "ngonka", "amount": "541507759" } ] }, { "address": "gonka17y2whumwxn6gmpwppg6q25947h82ev78w0kgup", "coins": [ { "denom": "ngonka", "amount": "535616589" } ] }, { "address": "gonka1xq4ngnc3zdsdl3rvtu7ytnkndpakzqu4dx0v7v", "coins": [ { "denom": "ngonka", "amount": "524592936" } ] }, { "address": "gonka1dk535rvfyvd8f46h56rtz46z22a6hmvjmyryha", "coins": [ { "denom": "ngonka", "amount": "523497524" } ] }, { "address": "gonka1ey9dfu98ngcjpg3lkmwc69xdsp2d9eaknyyl28", "coins": [ { "denom": "ngonka", "amount": "517494112" } ] }, { "address": "gonka16spupg33ck73rk4d82h8fusxkh823r62dshg0p", "coins": [ { "denom": "ngonka", "amount": "485580854" } ] }, { "address": "gonka1zj97wuqysdd0snt07z9204hlnf7phc4v9dnl5f", "coins": [ { "denom": "ngonka", "amount": "473074333" } ] }, { "address": "gonka1y3dmsztt4wewmg2fl7w6t42tcwwa2g0wsy5csl", "coins": [ { "denom": "ngonka", "amount": "441617349" } ] }, { "address": "gonka1n52k98esfltn4q783kuwg0amjn6cmuf94mwqep", "coins": [ { "denom": "ngonka", "amount": "440790436" } ] }, { "address": "gonka1q6gwd6gf6pke29257lwfsxds3nlq06882tc6zn", "coins": [ { "denom": "ngonka", "amount": "440790436" } ] }, { "address": "gonka1qq6cpau55hgse9yvwrup7fz38tvzc604jszfjy", "coins": [ { "denom": "ngonka", "amount": "440790436" } ] }, { "address": "gonka1uq2fykmv82rdx3qk4lua6hpak9u327swgdgepk", "coins": [ { "denom": "ngonka", "amount": "440790436" } ] }, { "address": "gonka1x9nx86r5sx4awdmpadd2nmhlrnmezlxxe8ncps", "coins": [ { "denom": "ngonka", "amount": "440790436" } ] }, { "address": "gonka14wmt933kjf2hlred8330gw28qjpt24j9p8muzp", "coins": [ { "denom": "ngonka", "amount": "385759538" } ] }, { "address": "gonka1htfcs20dtdrywddza7mhv9hjr7naj3juyv8474", "coins": [ { "denom": "ngonka", "amount": "381624153" } ] }, { "address": "gonka13ejhmp3g53r7csgautav95km9rjycxzy99a058", "coins": [ { "denom": "ngonka", "amount": "366760323" } ] }, { "address": "gonka1y38q7euwkznfc28agxlugtmn9f5xgufkt8ts7m", "coins": [ { "denom": "ngonka", "amount": "366760323" } ] }, { "address": "gonka14lhckrwqkxxw5w454yvcn7qv63vyn79rkcakg7", "coins": [ { "denom": "ngonka", "amount": "359592198" } ] }, { "address": "gonka1qty48qty43a3jm6jlq5t4aktz3yzs380uxxg2m", "coins": [ { "denom": "ngonka", "amount": "287541589" } ] }, { "address": "gonka18frq9ltz0m7u7aw7fkmwhqh89ut3w2e434nxjx", "coins": [ { "denom": "ngonka", "amount": "266551491" } ] }, { "address": "gonka1fthllm8hzk69qkz3dhhyarj029z52yclrlj5va", "coins": [ { "denom": "ngonka", "amount": "255137616" } ] }, { "address": "gonka1p4epndztqtsdu0cemsvm3kae70ec6nr7snfcms", "coins": [ { "denom": "ngonka", "amount": "251078150" } ] }, { "address": "gonka1zdmwgnl9ycmctdehe5cqv5wpepty62lcms8alx", "coins": [ { "denom": "ngonka", "amount": "249741938" } ] }, { "address": "gonka15nafqu6uglskzqkfgvh0mue7gats9dded3nctk", "coins": [ { "denom": "ngonka", "amount": "199164662" } ] }, { "address": "gonka1hn9wmlfe7nha0x26p7nsqvk9g8pnwml74hrm8n", "coins": [ { "denom": "ngonka", "amount": "189322890" } ] }, { "address": "gonka1wus9fvrxvx6sls623tme6rfgznu0l2myxm0k7z", "coins": [ { "denom": "ngonka", "amount": "186513559" } ] }, { "address": "gonka18xk4m8t0zj9vpse5c2dem8uxhqw0egtjuafy77", "coins": [ { "denom": "ngonka", "amount": "180102359" } ] }, { "address": "gonka1vs26xk4zvv6dv56j8r9ns7wzk6s00p8etk7wu7", "coins": [ { "denom": "ngonka", "amount": "131853118" } ] }, { "address": "gonka1vz2ygndntgjw2nyrqgehd4sayw64pz26tvw7qt", "coins": [ { "denom": "ngonka", "amount": "102378278" } ] } ] } ] ``` --- ## #39 – Community Series Film — Why Gonka Exists # #39 – Community Series Film — Why Gonka Exists Passed **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`](https://gonka.gg/address/gonka1snq0m4rdvq0sswm03r5jsmtzw3p384qsy3l4t4){:target="_blank"} **Metadata:** [https://miro.com/app/board/uXjVG6L2uvQ=/](https://miro.com/app/board/uXjVG6L2uvQ=/) 31,250 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/39){:target="_blank"} 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: --- ## Final Tally Yes 394,971 (76.0%) No 183 (0.0%) Veto 0 (0.0%) Abstain 124,587 (24.0%) Total 519,741 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1snq0m4rdvq0sswm03r5jsmtzw3p384qsy3l4t4", "amount": [ { "denom": "ngonka", "amount": "31250000000000" } ] } ] ``` --- ## Gonka Node Observability Platform # Gonka Node Observability Platform Proposal by INC4 (https://inc4.net) | 16 April 2026 Funding Request: \$96,000 USD (USDT) for 12 months --- ## Table of Contents 1. [Executive Summary](#1-executive-summary) 2. [Problem Statement](#2-problem-statement) 3. [Industry Context](#3-industry-context) 4. [Proposed Solution](#4-proposed-solution) 5. [Technical Approach](#5-technical-approach) 6. [Scope and Deliverables](#6-scope-and-deliverables) 7. [Budget and Payment Schedule](#7-budget-and-payment-schedule) 8. [Success Criteria](#8-success-criteria) 9. [Team](#9-team) --- ## 1. Executive Summary 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. --- ## 2. Problem Statement ### Off-chain state of the network is not visible 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: - Why a validator's miss rate is high - Whether RAM or GPU memory is exhausted - Whether ML or other containers are crash-looping - How long model loading takes after a restart - Whether a PUBLIC_URL is reachable from outside - Comparative performance across validators 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. ### What happens without a solution - Silent failures go undetected for hours or days — costing validators missed epochs and lost rewards - No common ground for debugging — each operator uses different tools, different baselines, different definitions of "normal" - The Core Team lacks fleet-wide visibility — making it harder to diagnose network-level issues and plan upgrades - New operators are on their own — high barrier to entry for smaller hosts without DevOps expertise --- ## 3. Industry Context ### Collecting validator metrics in one place is not new 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: - Solana — validators report metrics to a shared backend; the network publishes a public Grafana dashboard at `https://metrics.solana.com:3000` - Polkadot — nodes send telemetry by default to a shared backend; a public real-time dashboard is available at `https://telemetry.polkadot.io` - Kusama — uses the same Substrate Telemetry system as Polkadot, with its own view at `https://telemetry.polkadot.io/#list/Kusama` - NEAR — every node ships with a default telemetry endpoint (`telemetry.nearone.org`) and pushes data every 10 seconds - Aptos — all nodes push metrics to a centralized telemetry service (`telemetry.mainnet.aptoslabs.com`) by default; the architecture is documented in a public SPEC - Celestia — maintains an OpenTelemetry collector endpoint (`otel.celestia.observer`) for DA nodes, plus a Prometheus-based observability stack for consensus nodes This 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. --- ## 4. Proposed Solution ### Gonka Node Observability Platform A managed, open-source observability stack where validator operators voluntarily push off-chain metrics to a shared platform maintained by INC4. ### Design principles | 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 | ### Value delivered 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 --- ## 5. Technical Approach The platform will be deployed on distributed cloud infrastructure, providing: - High availability — no single point of failure; redundant infrastructure with 99.5%+ uptime SLA - Automatic scaling — the platform grows seamlessly as more validators join, with no manual intervention required - Push-based data collection — validators push metrics outbound via HTTPS; no new inbound ports are required, and existing firewall configurations are fully preserved 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. --- ## 6. Scope and Deliverables | # | 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 | --- ## 7. Budget and Payment Schedule ### Summary | 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 | | ### Payment schedule | 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 report | Vesting 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. ### Risks - Low validator adoption — INC4 will actively support onboarding and demonstrate platform value through early adopters - Infrastructure cost growth — the budget includes a reserve; if needed, migration to a more cost-effective solution is possible without service interruption - Platform does not affect the Gonka network — it operates as a completely separate layer; any platform issue has zero impact on validators or consensus 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. --- ## 8. Success Criteria 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 --- ## 9. Team - Website: https://inc4.net - GitHub: https://github.com/inc4 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. --- ## #41 – INC4 | Gonka Node Observability Platform # #41 – INC4 | Gonka Node Observability Platform Rejected **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`](https://gonka.gg/address/gonka12ss9dh7fj3xxmk23s8aje4hrpqq669u20v3ja6){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/discussions/1085](https://github.com/gonka-ai/gonka/discussions/1085) **Failed reason:** proposal did not get enough votes to pass $96,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/41){:target="_blank"} 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: --- ## Final Tally Yes 17,955 (57.1%) No 13,494 (42.9%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 31,449 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1yf2f23sqx8fradjn7laqp0twamlhy4sj6vzwmg946ux4awfqaaes9avx7a", "amount": [ { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "96000000000" } ] } ] ``` --- ## #69 – Increase minimum governance deposit to 500 GNK # #69 – Increase minimum governance deposit to 500 GNK Failed **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`](https://gonka.gg/address/gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k){:target="_blank"} **Failed reason:** maximum deposit period must not be nil: 0 [View on gonka.gg](https://gonka.gg/network/proposals/69){:target="_blank"} 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. --- ## Final Tally Yes 199,799 (96.9%) No 46 (0.0%) Veto 4,202 (2.0%) Abstain 2,210 (1.1%) Total 206,257 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.gov.v1.MsgUpdateParams` | Contract Details ```json [ { "@type": "/cosmos.gov.v1.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "min_deposit": [ { "denom": "ngonka", "amount": "500000000000" } ], "max_deposit_period": null, "voting_period": null, "quorum": "", "threshold": "", "veto_threshold": "", "min_initial_deposit_ratio": "", "proposal_cancel_ratio": "", "proposal_cancel_dest": "", "expedited_voting_period": null, "expedited_threshold": "", "expedited_min_deposit": [ { "denom": "ngonka", "amount": "1000000000000" } ], "burn_vote_quorum": false, "burn_proposal_deposit_prevote": false, "burn_vote_veto": false, "min_deposit_ratio": "" } } ] ``` --- ## #58 – Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky) # #58 – Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky) 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`](https://gonka.gg/address/gonka1v5cl6pudnagau7exyu3a9h74clw9zm7l5psp0r){:target="_blank"} **Metadata:** [https://vote.gonka.vip/tenders/550f71de-897f-4ce5-8af8-97854775f8b2](https://vote.gonka.vip/tenders/550f71de-897f-4ce5-8af8-97854775f8b2) **Failed reason:** proposal did not get enough votes to pass $70,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/58){:target="_blank"} # 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: ## About the channel Falcon Finance () 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. ## What the grant covers 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. ## Terms - 70,000 USD for full end-to-end production and permanent publication - Single payment, no vesting or tranches - Recipient: [gonka1w6amu8jg623pqrfw3a8wxlz0s2ph2yp0wvpuu3](https://gonka.gg/address/gonka1w6amu8jg623pqrfw3a8wxlz0s2ph2yp0wvpuu3) --- ## Final Tally Yes 98,018 (53.4%) No 0 (0.0%) Veto 85,697 (46.6%) Abstain 0 (0.0%) Total 183,715 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "amount": "70000000000", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "recipient": "gonka1w6amu8jg623pqrfw3a8wxlz0s2ph2yp0wvpuu3" } }, "funds": [] } ] ``` --- ## Full Proposal > 📋 Part of the **[TheSoul × Gonka proposal overview](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/7)** — 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` ## Approach — where we start 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. ## What we deliver - **Competitive Map** — positioning of key players in AI infrastructure and DePIN: where the gaps are, where it's oversaturated. - **Brand Idea & Values** — core brand concept, 3–5 values, mission and brand promise, aligned with the team. - **Archetype & Tone of Voice** — brand archetype and tone/voice guidelines (v1), the foundation for all copy and communications. - **Audience Personas** — 3 detailed profiles (miner, inference buyer, investor): motivations, barriers, and key messages. ## Final deliverable 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. ## Terms | | | |---|---| | Timeline | 3–4 weeks | | Format | Fixed scope | | Commitment | This phase only | | Unlocks | Offer 1.2 | ## On-chain action On pass, the gov authority calls the community USDT vault's `withdraw_ibc`, sending 25,000 USDT (IBC) to the recipient wallet: ```json { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "25000000000", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm" } }, "funds": [] } ``` USDT has 6 decimals: 25,000 × 10⁶ = 25,000,000,000. --- ## #60 – TheSoul - Offer 1.1: Brand positioning (25,000 USDT) # #60 – TheSoul - Offer 1.1: Brand positioning (25,000 USDT) Passed **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`](https://gonka.gg/address/gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm){:target="_blank"} **Metadata:** [https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/1](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/1) $25,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/60){:target="_blank"} 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. --- ## Final Tally Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "25000000000", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm" } }, "funds": [] } ] ``` --- ## #59 – Gonka Onboarding Video Guide — Milestone 1 (Prepayment) # #59 – Gonka Onboarding Video Guide — Milestone 1 (Prepayment) Rejected **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`](https://gonka.gg/address/gonka1tg7x8pv5lfnytkr9av3532mf2qq22ysdxxzr87){:target="_blank"} **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 Pool [View on gonka.gg](https://gonka.gg/network/proposals/59){:target="_blank"} 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](https://gonka.gg/address/gonka1tg7x8pv5lfnytkr9av3532mf2qq22ysdxxzr87). Amount: 5,000 USDT. Examples of prior work: and . Questions: rohan.sm.content@outlook.com. --- ## Final Tally Yes 24,505 (43.6%) No 0 (0.0%) Veto 0 (0.0%) Abstain 31,699 (56.4%) Total 56,204 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "amount": "5000000000", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "recipient": "gonka1tg7x8pv5lfnytkr9av3532mf2qq22ysdxxzr87" } }, "funds": [] } ] ``` --- ## #71 – Gonka PR Proposal for US/Global Regions # #71 – Gonka PR Proposal for US/Global Regions 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`](https://gonka.gg/address/gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09){:target="_blank"} **Metadata:** [https://www.figma.com/deck/qd7a7bkcit9O1LZ8whP9Ei](https://www.figma.com/deck/qd7a7bkcit9O1LZ8whP9Ei) **Failed reason:** proposal did not get enough votes to pass $75,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/71){:target="_blank"} 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: loom: --- ## Final Tally Yes 180,108 (99.8%) No 72 (0.0%) Veto 0 (0.0%) Abstain 233 (0.1%) Total 180,413 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "75000000000", "recipient": "gonka133cwxkcjj4g7kskf6tzee5l0y2ulvglsxt382l" } }, "funds": [] } ] ``` --- ## #77 – Gonka PR Proposal for US/Global Regions # #77 – Gonka PR Proposal for US/Global Regions Passed **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`](https://gonka.gg/address/gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09){:target="_blank"} **Metadata:** [https://www.figma.com/deck/qd7a7bkcit9O1LZ8whP9Ei](https://www.figma.com/deck/qd7a7bkcit9O1LZ8whP9Ei) $75,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/77){:target="_blank"} 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: loom: --- ## Final Tally Yes 152,042 (100.0%) No 71 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 152,113 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "75000000000", "recipient": "gonka133cwxkcjj4g7kskf6tzee5l0y2ulvglsxt382l" } }, "funds": [] } ] ``` --- ## Weekly Report — 13-17 July # Weekly Report — 13-17 July **Дата публикации:** 2026-07-17 --- - Мы поделились нашей контент-стратегией и получили ряд предложений от комитета. Мы активно используем ее в питчинге СМИ. - Мы использовали присутствие братьев Либерман на WebX на этой неделе и организовали 2 интервью: одно с MPost и одно с Blockchain Reporter. Материал MPost уже опубликован, ссылку мы делились в другом треде. - Мы также согласовали 2 авторские колонки для братьев Либерман — для The AI Journal и Securities.io, они сейчас находятся в процессе подготовки. - Мы также начали контакт с рядом ревью- и листикл-площадок и сообщим об обратной связи по мере ее получения. - Мы также начали питчинг братьев Либерман для ведущих мировых компаний в сфере AI, Web3 и технологий. Будем держать вас в курсе по мере получения ответов. Ожидает согласования - Мы ожидаем удобное время для еженедельного звонка. Всем хороших выходных! --- ## Weekly Report — 20–24 July # Weekly Report — 20–24 July **Дата публикации:** 2026-07-24 --- - Интервью братьев Либерман, организованное на конференции WebX, опубликовано в Blockchain Reporter. Материал также получил синдикацию в блоге Binance - это поможет увеличению охвата публикации. - Мы передали авторскую колонку братьев Либерман в The AI Journal для публикации. Поделимся ссылкой, когда материал выйдет в медиа. - Мы засекьюрили участие Gonka в двух листикл-материалах — в Analytics Insight и CryptoDaily. Сейчас ждем детали от редакторов. Всем хороших выходных! --- ## Full Proposal > 📋 Part of the **[TheSoul × Gonka proposal overview](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/7)** — 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` ## Approach — measure from day one 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. ## What we deliver - **GA4 Setup** — full account, properties, data streams, and conversion events configured for all three audiences. - **UTM Framework** — UTM parameter taxonomy for all channels and creators, with documentation and templates. - **Event Tracking** — all key on-site actions tagged: CTA clicks, form fills, inter-landing navigation. - **Dashboard & Reports** — live funnel dashboard per segment plus an executive report template for the Gonka team. ## Final deliverable 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. ## Terms | | | |---|---| | Timeline | 2–3 weeks | | Requires | Live website (2.1) | | Commitment | This phase only | | Unlocks | Offer 2.3 | ## On-chain action On pass, the gov authority spends from the community pool, sending 28,000 GNK to the recipient wallet: ```json { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm", "amount": [{ "denom": "ngonka", "amount": "28000000000000" }] } ``` GNK has 9 decimals: 28,000 × 10⁹ = 28,000,000,000,000 ngonka (≈ 7,000 USDT at 0.25 GNK/USDT). --- ## #64 – TheSoul - Offer 2.2: Analytics and attribution (28,000 GNK) # #64 – TheSoul - Offer 2.2: Analytics and attribution (28,000 GNK) 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`](https://gonka.gg/address/gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm){:target="_blank"} **Metadata:** [https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/5](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/5) 28,000 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/64){:target="_blank"} 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. --- ## Final Tally Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm", "amount": [ { "denom": "ngonka", "amount": "28000000000000" } ] } ] ``` --- ## #40 – Governance: extend voting period to 48 hours # #40 – Governance: extend voting period to 48 hours Passed **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`](https://gonka.gg/address/gonka1k6p754pyhxud2399knyccgjpjvdafj2u9xlgyf){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/40){:target="_blank"} 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. --- ## Final Tally Yes 377,158 (57.7%) No 0 (0.0%) Veto 12,030 (1.8%) Abstain 264,790 (40.5%) Total 653,978 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.gov.v1.MsgUpdateParams` | Contract Details ```json [ { "@type": "/cosmos.gov.v1.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "min_deposit": [ { "denom": "ngonka", "amount": "25000000" } ], "max_deposit_period": "86400s", "voting_period": "172800s", "quorum": "0.334000000000000000", "threshold": "0.500000000000000000", "veto_threshold": "0.334000000000000000", "min_initial_deposit_ratio": "0.000000000000000000", "proposal_cancel_ratio": "0.500000000000000000", "proposal_cancel_dest": "", "expedited_voting_period": "43200s", "expedited_threshold": "0.667000000000000000", "expedited_min_deposit": [ { "denom": "ngonka", "amount": "50000000" } ], "burn_vote_quorum": false, "burn_proposal_deposit_prevote": false, "burn_vote_veto": true, "min_deposit_ratio": "0.010000000000000000" } } ] ``` --- ## Full Proposal 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. ## Execution Framework If this roadmap is approved, it should open two follow-up directions. ### 1. External Teams and Contributors 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. ### 2. Foundation Framework Discussion 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. --- ## #57 – Approve the Gonka Network Development Roadmap # #57 – Approve the Gonka Network Development Roadmap 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`](https://gonka.gg/address/gonka1k6p754pyhxud2399knyccgjpjvdafj2u9xlgyf){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/pull/1266](https://github.com/gonka-ai/gonka/pull/1266) [View on gonka.gg](https://gonka.gg/network/proposals/57){:target="_blank"} 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: You can read the full text here: *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.* ## Important Note 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. ## Execution Framework If this roadmap is approved, it should open two follow-up directions. ### 1. External Teams and Contributors 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. ### 2. Foundation Framework Discussion 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. --- ## Final Tally Yes 257,150 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 257,150 votes ## Messages | # | Type | | :- | :--- | Contract Details ```json [] ``` --- ## #66 – test proposal - 测试方案 # #66 – test proposal - 测试方案 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`](https://gonka.gg/address/gonka1hwyjwehgp6e5pgpg0ye4a7unwu5q9xzljpuwr5){:target="_blank"} **Failed reason:** proposal did not get enough votes to pass $1,000,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/66){:target="_blank"} test proposal - 测试方案 --- ## Final Tally Yes 0 (0.0%) No 0 (0.0%) Veto 579,377 (100.0%) Abstain 0 (0.0%) Total 579,377 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "amount": "1000000000000", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "recipient": "gonka1hwyjwehgp6e5pgpg0ye4a7unwu5q9xzljpuwr5" } }, "funds": [] } ] ``` --- ## #76 – Governance 16: devshard v2 and bounty payouts # #76 – Governance 16: devshard v2 and bounty payouts Passed **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`](https://gonka.gg/address/gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le){:target="_blank"} $93,600 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/76){:target="_blank"} Register devshard approved version v2. --- ## Final Tally Yes 239,924 (100.0%) No 17 (0.0%) Veto 0 (0.0%) Abstain 16 (0.0%) Total 239,957 votes ## Messages | # | 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 ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "35", "poc_exchange_duration": "0", "poc_validation_delay": "5", "poc_validation_duration": "240", "set_new_validators_delay": "120", "inference_validation_cutoff": "2", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "500" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "processed_logprobs" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": true, "confirmation_poc_v2_enabled": true, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": true, "poc_stronger_rng_enabled": false, "models": [ { "model_id": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "2", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "3593", "exponent": -4 }, "penalty_start_epoch": "0" }, { "model_id": "moonshotai/Kimi-K2.6", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "4", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "78", "exponent": -2 }, "penalty_start_epoch": "251" }, { "model_id": "MiniMaxAI/MiniMax-M2.7", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "75", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "3024", "exponent": -4 }, "penalty_start_epoch": "278" } ], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2475000", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2475000" }, "transfer_agent_access_params": { "allowed_transfer_addresses": [ "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u" ] }, "devshard_escrow_params": { "min_amount": "50000000", "max_amount": "100000000000", "max_escrows_per_epoch": 500000, "group_size": 16, "allowed_creator_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk", "gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90", "gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c", "gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn", "gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp" ], "token_price": "10", "approved_versions": [ { "name": "v1", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip", "sha256": "dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c" }, { "name": "v2", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip", "sha256": "1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b" } ], "max_nonce": 1000000, "devshard_requests_enabled": true, "default_inference_seal_grace_nonces": 0, "default_inference_seal_grace_seconds": 0, "create_devshard_fee": "0", "fee_per_nonce": "0", "refusal_timeout": "0", "execution_timeout": "0", "validation_rate": 0, "vote_threshold_factor": 0, "default_auto_seal_every_n_nonces": 0 }, "fee_params": { "min_gas_price_ngonka": "0", "base_validation_gas": "500000", "gas_per_poc_count": "100" }, "delegation_params": { "deploy_window": "500", "refusal_penalty": { "value": "1", "exponent": -1 }, "no_participation_penalty": { "value": "15", "exponent": -2 }, "delegation_share": { "value": "5", "exponent": -2 }, "w_threshold": { "value": "1", "exponent": -1 }, "v_min": "3", "cap_factor": { "value": "75", "exponent": -2 }, "initial_model_id": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", "max_model_voting_power_percentage": { "value": "3", "exponent": -1 } }, "maintenance_params": null } }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "2000000000", "recipient": "gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq" } }, "funds": [] }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "100000000", "recipient": "gonka16k7nzvlheye8zhtyykcanxz0hldnfkmaedye8d" } }, "funds": [] }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "3000000000", "recipient": "gonka18enyz7h6hh5zjveee5wnhkhrcexamfz0zdxxqe" } }, "funds": [] }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "17000000000", "recipient": "gonka1ejkupq3cy6p8xd64ew2wlzveml86ckpzn9dl56" } }, "funds": [] }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "14000000000", "recipient": "gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8" } }, "funds": [] }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "10000000000", "recipient": "gonka1m96zrcwsw0wrzw20mxala4gp8r6lju2ewtjd62" } }, "funds": [] }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "500000000", "recipient": "gonka1ppn53fu8q3pxvwwf8ycjf3c6nzlugs3hmw6a3q" } }, "funds": [] }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "17000000000", "recipient": "gonka1x45hruazmcqxslj3g8a08988hr5fr3wx33drhp" } }, "funds": [] }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "30000000000", "recipient": "gonka1yhdhp4vwsvdsplv4acksntx0zxh8saueq6lj9m" } }, "funds": [] } ] ``` --- ## Support Gonka at Global Compute Sovereignty Summit # Support Gonka at Global Compute Sovereignty Summit 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](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](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. --- ## #42 – Support Gonka at Global Compute Sovereignty Summit # #42 – Support Gonka at Global Compute Sovereignty Summit 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`](https://gonka.gg/address/gonka1tknn6p8f2y4843fp4ud6ynq0727r7g8l568d27){:target="_blank"} **Metadata:** [https://github.com/DeAI-Nation/summit-proposal/blob/main/README.md](https://github.com/DeAI-Nation/summit-proposal/blob/main/README.md) $10,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/42){:target="_blank"} 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: Detailed proposal: --- ## Final Tally Yes 375,771 (68.6%) No 0 (0.0%) Veto 0 (0.0%) Abstain 172,050 (31.4%) Total 547,821 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "10000000000", "recipient": "gonka1gpsnclfyw59nghahf9cs9d76qqqwv9v7hrjlnz" } }, "funds": [] } ] ``` --- ## Run any epoch's calculator 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, #1180, #1183) 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. # Run any epoch's calculator python3 e267/calculate_compensation_267.py # Regenerate aggregate per-address totals 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 # Epoch group data (validation weights, confirmation weights) inferenced query inference show-epoch-group-data \ --node --height -o json # Per-participant reward summary inferenced query inference show-epoch-performance-summary-by-participant \ --node -o json # Delegation snapshot (query at poc_start - 500) 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 # Epoch group data (validation weights, confirmation weights) inferenced query inference show-epoch-group-data epoch> \ --node ARCHIVE_NODE> --height epoch_end> -o json # Per-participant reward summary inferenced query inference show-epoch-performance-summary-by-participant \ epoch> address> --node ARCHIVE_NODE> -o json # Delegation snapshot (query at poc_start - 500) 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 --- ## #67 – Kimi Restitution (epochs 265-276) # #67 – Kimi Restitution (epochs 265-276) Passed **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`](https://gonka.gg/address/gonka1nvcwl2c7jxj2h47c56y8dmcmf0tynt5dplzngy){:target="_blank"} **Metadata:** [https://github.com/votkon/gonka-kimi-restitution](https://github.com/votkon/gonka-kimi-restitution) 946,509 GNK · Gov Module [View on gonka.gg](https://gonka.gg/network/proposals/67){:target="_blank"} 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. --- ## Final Tally Yes 319,920 (78.9%) No 150 (0.0%) Veto 84,623 (20.9%) Abstain 744 (0.2%) Total 405,437 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.streamvesting.MsgBatchTransferWithVesting` | Contract Details ```json [ { "@type": "/inference.streamvesting.MsgBatchTransferWithVesting", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "outputs": [ { "recipient": "gonka1qa90tgczc0k5dvk4l5nvlf5y6phgm6mg22sfjv", "amount": [ { "denom": "ngonka", "amount": "158541879455919" } ] }, { "recipient": "gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu", "amount": [ { "denom": "ngonka", "amount": "101147807218599" } ] }, { "recipient": "gonka1uhqpup9fev3zahlx6n326lp0krznc6usjtx6lu", "amount": [ { "denom": "ngonka", "amount": "96601320933414" } ] }, { "recipient": "gonka1wthc28t25pg63hzvl07rl8e8r6km6hesl6jhsz", "amount": [ { "denom": "ngonka", "amount": "79247555226990" } ] }, { "recipient": "gonka1q5xt54wncgzk7dxv9x64uln68455g83wu9tugg", "amount": [ { "denom": "ngonka", "amount": "73073708453292" } ] }, { "recipient": "gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09", "amount": [ { "denom": "ngonka", "amount": "66487744752217" } ] }, { "recipient": "gonka1gvrrhjmy4w4mayvs2s5l23edj8ertcmtd2v4zr", "amount": [ { "denom": "ngonka", "amount": "52290195675726" } ] }, { "recipient": "gonka1j7x6dv42xehe9e5au4ku3wvzwtqlegfjhlvzj6", "amount": [ { "denom": "ngonka", "amount": "39809676543013" } ] }, { "recipient": "gonka1jrgm47v5eg876udmzg6j6glqcsd5x0vk6crpax", "amount": [ { "denom": "ngonka", "amount": "33750579636210" } ] }, { "recipient": "gonka10079cnl3nuh2k82mhkm04dj0slhtw9kmjewwau", "amount": [ { "denom": "ngonka", "amount": "20610390027954" } ] }, { "recipient": "gonka15munkmx6x7k6rqqeexjet4556p7at39ks9qgr5", "amount": [ { "denom": "ngonka", "amount": "18234887510983" } ] }, { "recipient": "gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw", "amount": [ { "denom": "ngonka", "amount": "17630158097135" } ] }, { "recipient": "gonka1830lqug50lse998x2lakk4pj5ypfumz5pasz0y", "amount": [ { "denom": "ngonka", "amount": "13958367773340" } ] }, { "recipient": "gonka1ujnc662v6g69jm6fgxnr79a2m7ehzeut059239", "amount": [ { "denom": "ngonka", "amount": "12612234865692" } ] }, { "recipient": "gonka1007g0ut3u4wjkay9hegqfev4pj90qgexwskmcw", "amount": [ { "denom": "ngonka", "amount": "11688555563236" } ] }, { "recipient": "gonka1c6fwzedfsmpu4jnjekv4cn7mvr7x7fuqd6uqt9", "amount": [ { "denom": "ngonka", "amount": "11366419253907" } ] }, { "recipient": "gonka1007dchuqgdnute4qam70kmn56j2vfw38mhyrqv", "amount": [ { "denom": "ngonka", "amount": "11262520197774" } ] }, { "recipient": "gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2", "amount": [ { "denom": "ngonka", "amount": "11021183080111" } ] }, { "recipient": "gonka1wt8sr9jxzpec65j7zkxsgh6edk3m6r8nlf5za4", "amount": [ { "denom": "ngonka", "amount": "10934181496134" } ] }, { "recipient": "gonka1wkgawwdzj623ss8eywayzdj6qcgr2llygactje", "amount": [ { "denom": "ngonka", "amount": "10456612261496" } ] }, { "recipient": "gonka1xwkesaxvdadh9wt9yyladu0r260s7whklcktds", "amount": [ { "denom": "ngonka", "amount": "9768694504061" } ] }, { "recipient": "gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np", "amount": [ { "denom": "ngonka", "amount": "9423072516255" } ] }, { "recipient": "gonka19cjm4c5mt3j3qdr8vhytmm4hef3pnkvkm0x7m2", "amount": [ { "denom": "ngonka", "amount": "8441669467829" } ] }, { "recipient": "gonka18xeqnspxpg2vncufnjne485rkaagwvz7whyn0d", "amount": [ { "denom": "ngonka", "amount": "6820652573831" } ] }, { "recipient": "gonka1mmlyd5xxu5l68yx8wzclrkxkxvm88mhq5tp5s0", "amount": [ { "denom": "ngonka", "amount": "6618057560512" } ] }, { "recipient": "gonka1scskt6wpnjnumsah6kjphmdu87vjgvcxmn4rxv", "amount": [ { "denom": "ngonka", "amount": "5645801436758" } ] }, { "recipient": "gonka1wvv656pt2d8x2khcvytqeessck5uzjnxzsa8f6", "amount": [ { "denom": "ngonka", "amount": "5511598438612" } ] }, { "recipient": "gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e", "amount": [ { "denom": "ngonka", "amount": "4673802241961" } ] }, { "recipient": "gonka14ljarev2nlzu4ej50vx7ylj2rvg4n20fnq2ysc", "amount": [ { "denom": "ngonka", "amount": "4444392150972" } ] }, { "recipient": "gonka1l8jd2nz92mnem0xwgwkltcw2952cnlphs5arsa", "amount": [ { "denom": "ngonka", "amount": "4167200640617" } ] }, { "recipient": "gonka1007n977a7uda3pd9m6hftw8xcql0tc20m96myu", "amount": [ { "denom": "ngonka", "amount": "3396492511794" } ] }, { "recipient": "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "amount": [ { "denom": "ngonka", "amount": "3018840187451" } ] }, { "recipient": "gonka1tl5m3vuqsx333v7095ymwjdc4vdk2wd9r5hqws", "amount": [ { "denom": "ngonka", "amount": "2731396085272" } ] }, { "recipient": "gonka14g78ez2zy08k8sssue483zmfpgd4qut8zcwlqc", "amount": [ { "denom": "ngonka", "amount": "2602055673919" } ] }, { "recipient": "gonka1zktn8j65wlys8a8e38hqhf4y3x6m4x04zskkrx", "amount": [ { "denom": "ngonka", "amount": "2392222959397" } ] }, { "recipient": "gonka1tlvg4kjx7ljd5thgd5fkgh39q6lu8cmxupktgg", "amount": [ { "denom": "ngonka", "amount": "2293694674600" } ] }, { "recipient": "gonka15p7s7w2hx0y8095lddd4ummm2y0kwpwljk00aq", "amount": [ { "denom": "ngonka", "amount": "2034501080557" } ] }, { "recipient": "gonka1tja3g2da45efhe2p83gk3whtussmgmtsdlgprt", "amount": [ { "denom": "ngonka", "amount": "1805142497891" } ] }, { "recipient": "gonka1ce02jjduga8jvwj8jx39mxn0jr345vgkx7lk2n", "amount": [ { "denom": "ngonka", "amount": "1753409171279" } ] }, { "recipient": "gonka1hwvel7n3zuk6wruefuzc356l9myske9stckwnz", "amount": [ { "denom": "ngonka", "amount": "1575513416778" } ] }, { "recipient": "gonka12pcu9mcrpa4w4sjd9y3dsksnvu495ss6f9r4ra", "amount": [ { "denom": "ngonka", "amount": "1166439755518" } ] }, { "recipient": "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "amount": [ { "denom": "ngonka", "amount": "1025259358283" } ] }, { "recipient": "gonka10070xwkwv00sulsa7gdfwkgh8w069stkjjf39x", "amount": [ { "denom": "ngonka", "amount": "1017602508283" } ] }, { "recipient": "gonka10075dz43h94zhqu5hwdj3nyjay6v8mzwvpxr0s", "amount": [ { "denom": "ngonka", "amount": "1017602508283" } ] }, { "recipient": "gonka1007lnkyhdh7aq0vjdcdwcerkdh4yy85rymjdg6", "amount": [ { "denom": "ngonka", "amount": "1007974841606" } ] }, { "recipient": "gonka13a4v8gxxjav5t4xq5y9cv9d8rfnvkjfw5adqz3", "amount": [ { "denom": "ngonka", "amount": "521637814838" } ] }, { "recipient": "gonka1myu058axjs62mc3e7na9krwvqpfl9z3gtcw9es", "amount": [ { "denom": "ngonka", "amount": "279015575378" } ] }, { "recipient": "gonka14ef2pxjge75gflqftn7m2wy0xv59gq9uc7qnct", "amount": [ { "denom": "ngonka", "amount": "276414090986" } ] }, { "recipient": "gonka1fvly5jrewyjmjfgwah3khy9rttq4cqajcesv9p", "amount": [ { "denom": "ngonka", "amount": "113864833864" } ] }, { "recipient": "gonka1cuwejs77gectp3n32wg8q27hlsa4m3hqspf4ww", "amount": [ { "denom": "ngonka", "amount": "108366531966" } ] }, { "recipient": "gonka1tmk2tzdneht6smu34pkmqdvu7p34qavvmwtwq2", "amount": [ { "denom": "ngonka", "amount": "100568940182" } ] }, { "recipient": "gonka1gyk0aahvr3qeju4zx0nplfreej6cy4jjk8svc5", "amount": [ { "denom": "ngonka", "amount": "30990428883" } ] } ], "vesting_epochs": "160" } ] ``` --- ## Full Proposal > 📋 Part of the **[TheSoul × Gonka proposal overview](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/7)** — 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` ## Approach — visual system as infrastructure 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. ## What we deliver - **Logo System** — primary logo, monogram, light/dark variants, clear-space rules, and prohibited uses. - **Color & Typography** — primary and extended palette, typographic scale, pairing principles, ready-to-use font files. - **Graphic Language** — patterns, iconography, layout principles: Gonka's unique visual code, consistent across every surface. - **SMM Templates** — ready-to-use template set for X, Telegram, and LinkedIn, adapted to all formats and placements. ## Final deliverable 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. ## Terms | | | |---|---| | Timeline | 4–6 weeks | | Format | Fixed scope | | Commitment | This phase only | | Requires | Offer 1.1 | ## On-chain action On pass, the gov authority calls the community USDT vault's `withdraw_ibc`, sending 20,000 USDT (IBC) to the recipient wallet: ```json { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "20000000000", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm" } }, "funds": [] } ``` USDT has 6 decimals: 20,000 × 10⁶ = 20,000,000,000. --- ## #61 – TheSoul - Offer 1.2: Brandbook (20,000 USDT) # #61 – TheSoul - Offer 1.2: Brandbook (20,000 USDT) 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`](https://gonka.gg/address/gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm){:target="_blank"} **Metadata:** [https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/2](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/2) $20,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/61){:target="_blank"} 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. --- ## Final Tally Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "20000000000", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm" } }, "funds": [] } ] ``` --- ## #72 – Open devshard escrow creation to community wallet gonka1afj0tz53z56zngs425m83vxl5y2xmwm692hfrn # #72 – Open devshard escrow creation to community wallet gonka1afj0tz53z56zngs425m83vxl5y2xmwm692hfrn Rejected **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`](https://gonka.gg/address/gonka1afj0tz53z56zngs425m83vxl5y2xmwm692hfrn){:target="_blank"} **Metadata:** `ipfs://` **Failed reason:** proposal did not get enough votes to pass [View on gonka.gg](https://gonka.gg/network/proposals/72){:target="_blank"} 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. --- ## Final Tally Yes 5,337 (2.2%) No 7,953 (3.3%) Veto 221,234 (90.7%) Abstain 9,421 (3.9%) Total 243,945 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "35", "poc_exchange_duration": "0", "poc_validation_delay": "5", "poc_validation_duration": "240", "set_new_validators_delay": "120", "inference_validation_cutoff": "2", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "500" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "processed_logprobs" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": true, "confirmation_poc_v2_enabled": true, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": true, "poc_stronger_rng_enabled": false, "models": [ { "model_id": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "2", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "3593", "exponent": -4 }, "penalty_start_epoch": "0" }, { "model_id": "moonshotai/Kimi-K2.6", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "4", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "78", "exponent": -2 }, "penalty_start_epoch": "251" }, { "model_id": "MiniMaxAI/MiniMax-M2.7", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "75", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "3024", "exponent": -4 }, "penalty_start_epoch": "278" } ], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2475000", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2475000" }, "transfer_agent_access_params": { "allowed_transfer_addresses": [ "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u" ] }, "devshard_escrow_params": { "min_amount": "50000000", "max_amount": "100000000000", "max_escrows_per_epoch": 500000, "group_size": 16, "allowed_creator_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk", "gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90", "gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c", "gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn", "gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp", "gonka1afj0tz53z56zngs425m83vxl5y2xmwm692hfrn" ], "token_price": "10", "approved_versions": [ { "name": "v1", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip", "sha256": "dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c" } ], "max_nonce": 1000000, "devshard_requests_enabled": true, "default_inference_seal_grace_nonces": 0, "default_inference_seal_grace_seconds": 0, "create_devshard_fee": "0", "fee_per_nonce": "0", "refusal_timeout": "0", "execution_timeout": "0", "validation_rate": 0, "vote_threshold_factor": 0, "default_auto_seal_every_n_nonces": 0 }, "fee_params": { "min_gas_price_ngonka": "0", "base_validation_gas": "500000", "gas_per_poc_count": "100" }, "delegation_params": { "deploy_window": "500", "refusal_penalty": { "value": "1", "exponent": -1 }, "no_participation_penalty": { "value": "15", "exponent": -2 }, "delegation_share": { "value": "5", "exponent": -2 }, "w_threshold": { "value": "1", "exponent": -1 }, "v_min": "3", "cap_factor": { "value": "75", "exponent": -2 }, "initial_model_id": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", "max_model_voting_power_percentage": { "value": "3", "exponent": -1 } }, "maintenance_params": null } } ] ``` --- ## Full Proposal 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 1. Problem 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. 2. Solution 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 3. Deliverables 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 4. Team 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 5. Budget Breakdown ($100,000) 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 6. Milestone-Based Accountability 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 7. Stakeholder Impact 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 8. Risks 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 --- ## #70 – GNK Racers: Launch GameFi Mini-App to Drive User Growth & Wallet Activity # #70 – GNK Racers: Launch GameFi Mini-App to Drive User Growth & Wallet Activity Rejected **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`](https://gonka.gg/address/gonka13kzs38qkq4uc0astlshv39kt9gpu3sr99unpcq){:target="_blank"} **Metadata:** [https://github.com/Pestarzt0011/GNKRacers-proposal](https://github.com/Pestarzt0011/GNKRacers-proposal) **Failed reason:** proposal did not get enough votes to pass 246,000 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/70){:target="_blank"} 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: Bi-weekly progress reporting committed. --- ## Final Tally Yes 38,621 (25.0%) No 107,644 (69.6%) Veto 6,241 (4.0%) Abstain 2,245 (1.5%) Total 154,751 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka13kzs38qkq4uc0astlshv39kt9gpu3sr99unpcq", "amount": [ { "denom": "ngonka", "amount": "246000000000000" } ] } ] ``` --- ## #48 – Lower Direct Participation Threshold to 10% # #48 – Lower Direct Participation Threshold to 10% Passed **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`](https://gonka.gg/address/gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/48){:target="_blank"} 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. --- ## Final Tally Yes 808,529 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 808,529 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "35", "poc_exchange_duration": "0", "poc_validation_delay": "5", "poc_validation_duration": "240", "set_new_validators_delay": "120", "inference_validation_cutoff": "2", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "500" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "processed_logprobs" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": true, "confirmation_poc_v2_enabled": true, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": true, "poc_stronger_rng_enabled": false, "models": [ { "model_id": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "2", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "3593", "exponent": -4 }, "penalty_start_epoch": "0" }, { "model_id": "moonshotai/Kimi-K2.6", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "4", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "12620856201975851", "exponent": -16 }, "penalty_start_epoch": "251" } ], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2475000", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2475000" }, "transfer_agent_access_params": { "allowed_transfer_addresses": [ "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u" ] }, "devshard_escrow_params": { "min_amount": "50000000", "max_amount": "100000000000", "max_escrows_per_epoch": 100, "group_size": 16, "allowed_creator_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk", "gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc" ], "token_price": "10", "approved_versions": [ { "name": "v1", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.12/devshardd.zip", "sha256": "15f722444e6545bc787f1ef6d1011557d25a8b05cb9f6aaf1a514349d36d4715" } ], "max_nonce": 0, "devshard_requests_enabled": false, "default_inference_seal_grace_nonces": 0, "default_inference_seal_grace_seconds": 0, "create_devshard_fee": "0", "fee_per_nonce": "0", "refusal_timeout": "0", "execution_timeout": "0", "validation_rate": 0, "vote_threshold_factor": 0, "default_auto_seal_every_n_nonces": 0 }, "fee_params": { "min_gas_price_ngonka": "0", "base_validation_gas": "500000", "gas_per_poc_count": "100" }, "delegation_params": { "deploy_window": "500", "refusal_penalty": { "value": "1", "exponent": -1 }, "no_participation_penalty": { "value": "15", "exponent": -2 }, "delegation_share": { "value": "5", "exponent": -2 }, "w_threshold": { "value": "1", "exponent": -1 }, "v_min": "3", "cap_factor": { "value": "75", "exponent": -2 }, "initial_model_id": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", "max_model_voting_power_percentage": { "value": "3", "exponent": -1 } }, "maintenance_params": null } } ] ``` --- ## Community Funding Proposal — Gonka Labs — Year One # Community Funding Proposal — Gonka Labs — Year One **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](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md). ## Overview 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. ### What the network gets 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](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md) - **A reliable block explorer for everyone** — gonka.gg serves 5,000+ users daily and is usually the first place new users land to understand Gonka. V2 makes it faster, more accurate, and mobile-friendly. *Track 4 · Track 11* - **Gonka inference, reachable by businesses** — proxy.gonka.gg brings real B2B integrations (Integrity is already live), solving each business's special integration demands, driving token demand and proving Gonka inference is production-ready. *Track 2 · Track 11* - **RPC orchestrator, hardened to enterprise grade** — rpc.gonka.gg is the default Keplr RPC. SLAs, geo-aware routing, public SLA dashboard, open-source aggregation layer. *Track 4 · Track 8* - **Gonka on mobile** — Gonka App for iOS and Android: wallet, governance, and AI inference from any Gonka model, in one superapp. *Track 2 · Track 11* - **Governance anyone can participate in** — Gonkavote and expanded tooling making on-chain decisions accessible, not just for technical users. *Track 12* - **MTD (Marketing Transparency Dashboard)** — open-source, every marketing initiative gets a public page: goals, deadlines, owner, status, performance analysis. Auditable by anyone. *Track 11* ## Highlights - Funding: **70,000 USDT** (single payment for 6 months of infra & ops) + **330,000 GNK** (180-day linear vesting — team's forward compensation). - 5 core products brought to enterprise grade: rpc.gonka.gg, proxy.gonka.gg, gonka.gg, Gonka App, Gonkavote — plus two new products: **G-Router** (multi-broker inference router) and **MTD** (Marketing Transparency Dashboard). - rpc.gonka.gg multi-provider aggregation is **already live** — aggregates 6block, Hyperfusion, PS and others behind a single endpoint. The **official default RPC for Gonka in the Keplr wallet**. Addresses community request [#521](https://github.com/gonka-ai/gonka/issues/521). - B2B inference integrations are **already underway** — proxy.gonka.gg is being actively overhauled to support them. First public example: [Integrity](https://t.me/GonkaAI_ru/40504) — an Israeli-American startup ("#1 Product of the Day" on Product Hunt, $1M+ raised) running Gonka models in production beta. - 16+ products, 15 open-source repos — built entirely without external funding since December 2025. ## Built for the ecosystem, not for profit 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. ## Who We Are 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](https://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. ## Track Record 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: ### Gonka.gg 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. ### rpc.gonka.gg Managed RPC infrastructure. 400+ endpoints across 6 surfaces. ClickHouse-indexed, up to 110x faster than raw RPC. ### Proxy Cloud-hosted OpenAI-compatible API for Gonka inference at [proxy.gonka.gg](https://proxy.gonka.gg). **1–2B tokens served daily.** ### Gonka App Open-source Chrome extension wallet with GNS integration, governance, IBC tokens, and dApp provider. 700+ users. [gonkalabs/ggwallet](https://github.com/gonkalabs/ggwallet) ### Gonka Name Service On-chain human-readable .gnk names. 4,000+ registered. Integrated across all our products. [gonkalabs/gns](https://github.com/gonkalabs/gns) ### OpenGNK Self-hosted OpenAI-compatible proxy for Gonka inference. 400+ installs. Tool calling, privacy sanitization. [gonkalabs/opengnk](https://github.com/gonkalabs/opengnk) ### Gonkablocks No-code AI tools platform on Gonka inference at [blocks.gonka.gg](https://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. ### Gonkavote.com Pre-vote governance signaling tool at [gonkavote.com](https://gonkavote.com). Gauge community sentiment on a proposal before it goes to on-chain vote. [gonkalabs/prevote](https://github.com/gonkalabs/prevote) ### G-Meter Network performance metrics dashboard at [meter.gonka.gg](https://meter.gonka.gg). Real-time latency, throughput, and health monitoring across the Gonka network. [gonkalabs/gmeter](https://github.com/gonkalabs/gmeter) ### Feather Lightweight, open-source Gonka RPC node anyone can run. Designed for low-resource hardware and self-hosted setups. [gonkalabs/feather](https://github.com/gonkalabs/feather) ### Tx-Scanner Open-source blockchain indexer that accumulates millions of Gonka transactions and serves them with sub-second API latency. Powers gonka.gg. [gonkalabs/tx-scanner](https://github.com/gonkalabs/tx-scanner) ### Gonka Agent Open-source agent toolkit for building autonomous workflows on top of Gonka inference. [gonkalabs/gonka-agent](https://github.com/gonkalabs/gonka-agent) ### Contract Playground Write, compile, simulate, and deploy CosmWasm smart contracts entirely in the browser. [gonkalabs/wasm-cloud-compiler](https://github.com/gonkalabs/wasm-cloud-compiler) ### GonkaClaw One-command AI agent setup powered by Gonka inference. [gonkalabs/gonkaclaw](https://github.com/gonkalabs/gonkaclaw) ### Ready Set Gonka Community project directory for the Gonka ecosystem at [readysetgonka.com](https://readysetgonka.com). ### Gonka Restitution Committee (GRC) 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](https://github.com/gonkalabs/GRC-intake-form), [GRC-e267-kimi_shortfall](https://github.com/gonkalabs/GRC-e267-kimi_shortfall), [GRC-e247-preserver-audit](https://github.com/gonkalabs/GRC-e247-preserver-audit) ### Built in the open **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. ## Why This Proposal 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: - **Move to enterprise-grade reliability** — SLAs, multi-provider failover, monitoring with on-call response, zero-downtime deployments. - **Ship first-class mobile apps** — Gonka App on iOS and Android, and beyond the wallet: a Gonka superapp that puts convenient Gonka services — wallet, governance, network data, and AI inference from any Gonka model — on the phone. - **Build B2B-grade inference infrastructure** — proxy.gonka.gg is already the #1 provider on Gonka by daily inference volume. Serving businesses at commercial scale takes a full commercial layer: analytics, org-level API management, multi-region presence, escrow tooling, and infrastructure refactored for commercial loads. - **Grow the team sustainably** — from 3 to up to 5 engineers, matched to actual production load. 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. ## The Ask **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. ## Disbursement Mechanism 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. ### 1. Half a year of infra and ops — 70,000 USDT 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. ### 2. GNK locked in 180-day linear vesting — 330,000 GNK 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. ## Budget Breakdown ### USDT — 70,000 USDT total **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. ### Where the monthly USDT goes 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. | ### GNK — 330,000 GNK (180-day linear vesting) **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. ## Roadmap & Deliverables 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](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md#project-2-adapter-for-openrouter--aggregators) 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. ### rpc.gonka.gg — Multi-provider RPC aggregation & enterprise reliability [Gonka Roadmap](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md): Track 4: Network reliability & observability · Track 8: Enterprise workloads - **Already live** — multi-provider load balancer aggregating all available Gonka RPC providers (6block, Hyperfusion, PS and others) behind a single rpc.gonka.gg address, with latency-based routing and automatic failover. Shipped ahead of this proposal in response to community issue [#521](https://github.com/gonka-ai/gonka/issues/521): wallets keep working even when individual providers go offline. - **gRPC & WebSocket full support** — expand beyond HTTP/REST to cover all RPC surfaces that wallets and node operators use. - **Geo-aware serving** — route every request to the nearest healthy region so responses are fast regardless of where the requester is located. - **Public SLA dashboard** — uptime history per provider, latency percentiles (p50/p95/p99), incident log. Every metric publicly visible. - **Open-sourcing the aggregation layer** — publish the multi-provider router so anyone can audit it or run their own instance. ### proxy.gonka.gg — B2B inference portal with analytics [Gonka Roadmap](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md): Track 2: Developer & AI agent access · Track 11: Demand activation · Track 8: Enterprise workloads - **Already live** — business analytics portal, API key management, and the first round of performance optimization. proxy.gonka.gg is our product and is already **#1 on Gonka by daily inference volume**, serving 1–2B tokens per day. - **B2B integrations are already happening** — some non-public, like provisioning 100 API keys with 300M tokens each for a company to test Gonka at scale; and some public, like [Integrity](https://t.me/GonkaAI_ru/40504) — an Israeli-American startup ("#1 Product of the Day" on Product Hunt, $1M+ raised) now running Gonka models in production beta. - **Broker-level fixes for every integration** — each B2B integration surfaces real issues at the broker level, and we solve them inside proxy.gonka.gg itself — payments, key provisioning, stability — so Gonka inference gets seriously utilized, not just demoed. - **Go-to-market analytics system** — a two-tier internal analytics layer built for distribution. *Actors* create UTM-tagged links (source, medium, campaign, content, referral term) to track any channel — Telegram, paid ads, influencers, partner integrations. *Analysts* get a dashboard with multi-dimensional filtering across all UTM dimensions and date ranges: unique visitors, first action conversion, requests by model with error-rate breakdowns, token consumption over time, and deposited funds. Every metric sliceable by any combination of UTM parameters. Powers referral programs, partner attribution, and campaign testing. - **Multi-region deployment** — geographic endpoints across EU, US, and CIS to cut round-trip latency for users and businesses worldwide. - **Escrow monitoring utility** — built into the product for easier escrow rotation when consuming Gonka inference at commercial scale. - **Devshard proxy optimizations** — reduce per-request overhead as commercial load keeps growing. ### gonka.gg — V2.0 — new high-performance engine [Gonka Roadmap](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md): Track 4: Network reliability & observability · Track 11: Demand activation - **The Etherscan of Gonka** — every V2 improvement serves one goal: making gonka.gg the leading explorer for the network, the default place everyone goes for on-chain data. - **Pre-computed data pipeline** — V2 puts more compute behind the explorer: heavy queries and analytics are pre-computed ahead of time instead of on demand, targeting 3–5× faster API responses under production load. We can finally afford the hardware to do it right. - **Better UI** — cleaner layouts, faster navigation, redesigned data views across the whole explorer. - **Real-time WebSocket feeds** — live block, transaction, and validator event streams. Currently everything is polled; V2 pushes updates the moment they land on-chain. - **Improved GPU and inference metrics accuracy** — current GPU history data has edge cases and gaps. V2 fixes the underlying data pipeline and adds full history backfill. - **Mobile-responsive redesign** — gonka.gg was built desktop-first. V2 is mobile-first with a rebuilt layout that works on all screen sizes. - **Search improvements** — cross-entity search (address, tx hash, block, validator, GNS name) from a single input, sub-50ms response time. ### Gonka App — iOS & Android — a Gonka superapp [Gonka Roadmap](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md): Track 2: Developer & AI agent access · Track 11: Demand activation - **A superapp, not just a wallet** — one app that puts convenient Gonka services on the phone: wallet, governance, GNS, network data. The mobile home for the entire ecosystem. - **AI inference from your pocket** — chat with any model on the Gonka network directly from the app. No API keys, no setup — just pick a model and go. The full power of Gonka inference, accessible to anyone with a phone. - **Built with Expo** — single codebase shipping to both the App Store and Google Play, with native modules where performance demands it. - **Trust Wallet–level wallet** — full feature parity with the Chrome extension and beyond: governance voting, GNS resolution, IBC transfers, dApp provider protocol. - **Biometric authentication** — Face ID / Touch ID on iOS, fingerprint on Android. Secure enclave key storage, never exposed in plaintext. - **Push notifications** — new governance proposals, transaction confirmations, GNS name expiry warnings. Opt-in per notification type. - **WalletConnect support** — connect to dApps from the mobile wallet, not just the browser extension. ### Gonkavote — Governance tooling improvements [Gonka Roadmap](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md): Track 12: Community coordination **Already live** at [gonkavote.com](https://gonkavote.com) · [open-source on GitHub](https://github.com/gonkalabs/prevote). This proposal expands it further. - **Historical governance analytics** — full participation history for all past proposals: voter turnout, YES/NO/ABSTAIN breakdown over time, validator voting patterns. Currently this data is not available anywhere on the Gonka network. - **Multi-wallet integration** — sign and submit pre-vote signals from all major wallets, not just one. - **Proposal tracking and notifications** — follow specific proposals, get notified when voting opens, closes, or results are published. - **Delegation-aware voting** — show how much voting power is behind each signal, not just raw address counts. ### GNS — Names marketplace & ecosystem deepening [Gonka Roadmap](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md): Track 2: Developer & AI agent access - **Public names marketplace** — buy, sell, and transfer .gnk names between wallets on an open market. Names have real value: short names, brand names, and vanity addresses are already scarce. A marketplace makes that value liquid. - **Scam labeling & safety layer** — community-driven flagging of suspicious names and addresses, surfaced everywhere GNS is resolved: explorer, wallet, and dApps. - **Deeper integration** — GNS resolution in every product we touch: gonka.gg search, Gonka App send-to-name, governance profiles, and Gonkavote voter identity. Already officially integrated with [hex.exchange](https://hex.exchange). ### Transparency — MTD — Marketing Transparency Dashboard [Gonka Roadmap](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md): Track 11: Demand activation & ecosystem growth - **Context** — Gonka has seen 300k+ USDT worth of marketing proposals. The community has no unified way to track whether any of it delivered results. We will build the tool that changes that. - **Deliverable tracker** — every marketing initiative or proposal gets a public page: stated deliverables, deadlines, owner, and current status. Updates are timestamped and immutable. - **Performance dashboard** — key metrics per initiative: reach, engagement, on-chain activity correlated to campaign windows, and cost-per-outcome where measurable. No cherry-picking — all campaigns visible. - **Open-source** — the entire system is published on GitHub. Anyone can deploy it for their own Cosmos chain, verify the data pipeline, or propose improvements. ### G-Router — Multi-broker Gonka inference router [Gonka Roadmap](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md): Track 2, Project 2: Adapter for OpenRouter / aggregators — *direct 1:1 implementation* · Track 11: Demand activation - **Context** — right now, developers integrating Gonka inference must choose a specific provider manually (a devshard, a proxy, etc.). There is no unified routing layer. This creates friction, single points of failure, and prevents Gonka from appearing in OpenRouter-style aggregator directories — a major discovery channel for AI developers. Track 2, Project 2 of the Gonka Network Development Roadmap explicitly calls for this: *"An adapter for OpenRouter and/or a similar routing aggregation layer."* - **Single unified endpoint** — one API address that routes to the best available Gonka inference provider based on model availability, latency, and load. Developers never need to manage provider selection manually. - **OpenAI-compatible API** — drop-in replacement for any OpenAI-compatible SDK. Change one line: the base URL. Everything else — model names, streaming, function calling — works as-is. - **Multi-provider load balancing** — distribute traffic intelligently across all active Gonka inference providers. No single provider is a bottleneck or single point of failure. - **Fallback and retry logic** — if a provider returns an error or times out, the router transparently retries on another without the client ever seeing it. - **OpenRouter listing** — once stable, submit Gonka to OpenRouter as a provider. This unlocks access to thousands of developers who already use OpenRouter for model routing and discovery, without ever having heard of Gonka. ### Roadmap is community-driven — and other products aren't abandoned 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. ## Team Growth 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. ## Accountability We believe in transparency and accountability. Here's how we'll keep the community informed: - **Monthly progress reports** — public updates on GitHub Discussions detailing what we shipped, what we spent, and what's next. - **Open-source everything** — all new products maintain our 80%+ open-source commitment. Code is auditable at any time. - **On-chain transparency** — all GNK vesting is on-chain and verifiable by anyone. USDT payment is a single traceable transaction. - **GNK vesting** — 330,000 GNK in vesting over 180 days. Every release is visible and verifiable by anyone. 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. ## Your Vote Matters 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. ### Voting is now live On-chain voting for this proposal is open. View and vote on [gonka.gg/network/proposals/74](https://gonka.gg/network/proposals/74). [Vote Now](https://gonkavote.com) · [Proposal #74 on gonka.gg](https://gonka.gg/network/proposals/74) ## Summary | 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 | --- ## #74 – Gonka Labs: Maintaining Infrastructure, Improving Products, and Launching New Ones # #74 – Gonka Labs: Maintaining Infrastructure, Improving Products, and Launching New Ones Passed **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`](https://gonka.gg/address/gonka1e3pepqllu89t8l2acw86fgp5jjkw8m7kcl47nk){:target="_blank"} **Metadata:** [https://gonkalabs.com/proposal](https://gonkalabs.com/proposal) $70,000 · Community Pool · 330,000 GNK · Gov Module [View on gonka.gg](https://gonka.gg/network/proposals/74){:target="_blank"} Full 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: --- ## Final Tally Yes 305,163 (79.6%) No 3,791 (1.0%) Veto 15 (0.0%) Abstain 74,304 (19.4%) Total 383,273 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | | 2 | `/inference.streamvesting.MsgTransferWithVesting` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "70000000000", "recipient": "gonka16j4zv6723mrnycwn0qgw0j48dr9qecyclxg5jh" } }, "funds": [] }, { "@type": "/inference.streamvesting.MsgTransferWithVesting", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka16j4zv6723mrnycwn0qgw0j48dr9qecyclxg5jh", "amount": [ { "denom": "ngonka", "amount": "330000000000000" } ], "vesting_epochs": "180" } ] ``` --- ## Gonka Labs — Monthly Report No.1 # Gonka Labs — Monthly Report No.1 **Дата публикации:** 2026-07-18 18:31 UTC **Источник:** [Discussion #1477 — Gonka Labs - Monthly Report No.1](https://github.com/gonka-ai/gonka/discussions/1477) --- # ![](https://resource.inkdown.me/assets/11g/tk4ZX4b2sHaSu/ZarQaYSqnMMS69H.png) Hey! Gonka Labs here. On June 12th the community passed [Proposal #74](https://gonka.gg/network/proposals/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: 1. **OpenBroker** - new product, live 2. **Pulse** - new product, live 3. **gonka.gg** - ~240 QA bugs closed + big product updates (devshards / inference, network analytics, mobile) 4. **proxy.gonka.gg** - B2B inference proxy scaled hard + public status/analytics + DevShards v3 5. **Infra move** - Whole infra migrated (explorer + indexer stack, all dbs, all backend, new frontend and analytics stack) onto the new production setup. *** ## 1. OpenBroker We already announced the launch here: [OpenBroker - broker for brokers or Devshards as a service](https://github.com/gonka-ai/gonka/discussions/1363) (Jun 23). ![](https://resource.inkdown.me/assets/11g/tk4ZX4b2sHaSu/GUY7yidIzteGuy9.png) 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](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](https://openbroker.gonka.gg/stats). ### Since launch (numbers as of Jul 18) - **33 active brokers** - 48 registered orgs ![](https://resource.inkdown.me/assets/11g/tk4ZX4b2sHaSu/Fdbf8HKI2CJLyQf.png) - **~3.2GNK deposited** into broker ledgers - **~15M requests logged** in usage (~15M lifetime hits through the dual-gateway router) - **~11.8B tokens served** (8.5 logged since migration) across MiniMax, Kimi, GLM, Qwen (usage window since early July; launch load test already pushed past **1B tokens in ~1 hour**) - Peak observed throughput around **~100 req/s** (busiest minutes ~5.7k req/min; busiest day ~1.06M requests) - **DevShards v3 live** on both production gateways - image `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 away - Real brokers / relays already pointing parts or all traffic at OpenBroker (public org names): **gonkarelay.com**, **Gonka24.com**, **Gonka-API.org**, **gate.joingonka.ai**,**Vitarum, etc**, plus several private / internal accounts. ### Ops + product work after launch - Moved production off the early Railway pilot (where we landed after Qupra DC issues in end of June) onto a **dedicated server**. Same public domains, more headroom under load - Dual-gateway HA with live traffic drain/switch (used for the v3 migrate - one gateway at a time, verify, then the other) - Broker dashboard: per-request usage, participant / redundancy attempt breakdown, cost reconciliation - New broker APIs: `GET /v1/usage` and `GET /v1/usage/{id}` so integrators can pull request-level cost/token data without scraping the UI - Hardening under real load (connection pooling to the gateway router, escrow rotation / capacity ops, model-aware capacity after governance model changes) ### Feedback thread (git discussions) Thanks for the sharp measurements. Where we landed so far: - **Billing / hung requests** - usage logging + `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 completions - **~10s fixed overhead** - largely protocol / escrow path (block times), not OpenBroker markup. Dual gateways + v3 cutover keep us on the current network path; further shaving depends on protocol-side escrow UX - **Large-prompt hang band** - treated as a gateway/host-path issue; we keep feeding failure modes back to core while brokers route production traffic through us OpenBroker 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: - Product: [https://openbroker.gonka.gg](https://openbroker.gonka.gg) - API: [https://api.openbroker.gonka.gg/v1](https://api.openbroker.gonka.gg/v1) - Register: [https://openbroker.gonka.gg/register](https://openbroker.gonka.gg/register) - Stats: [https://openbroker.gonka.gg/stats](https://openbroker.gonka.gg/stats) - Launch post: [https://github.com/gonka-ai/gonka/discussions/1363](https://github.com/gonka-ai/gonka/discussions/1363) *** ## 2. Pulse 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. ![](https://resource.inkdown.me/assets/11g/tk4ZX4b2sHaSu/rj4gBndPAI6mlw5.png) Live: [https://pulse.gonka.gg](https://pulse.gonka.gg) ### What shipped - Full Pulse app on Railway (API + web + Postgres), collectors on a ~2h cadence - Sources: X, Instagram, YouTube, curated web / press - Dashboard: last-24h activity / reach / engagement charts, general sentiment gauge + 14-day tone chart, GNK market (Uniswap v3 + HEX OTC), market Fear & Greed, top creators, content feed, EN + RU ui translations - Sentiment analysis runs on LLMs running in Gonka (same network we all are building for) - not a closed SaaS LLM - Embedded on the gonka.gg homepage (sentiment, Fear & Greed, latest news, link out to Pulse) - Public read API for stats / market / feed / news / creators so gonka.gg and others can reuse the data. Some dashboards are already ingesting it alongside basic network info. ### Numbers (as of Jul 18) - **~2,600 posts indexed** - **~11.9M total reach** and **~149K engagement** across indexed content - Sentiment: **100% of indexed items analyzed** (latest daily reading in the mid-50s / Neutral) - Last 24h snapshot (volatile): **~43 new posts**, **~784K reach gained**, **~4.5K engagement gained** ### Why this matters 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. *** ## 3. gonka.gg - bugs + product work 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. ![](https://resource.inkdown.me/assets/11g/tk4ZX4b2sHaSu/rqIXpMRSJzuXQfe.png) ### QA bug smash (~240) 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: - Mobile layouts and basic UX reorganizations - charts, maps, tooltips escaping the viewport on touch - table, card alignments, repositionings, restructuring - status badges, filters, i18n gaps - reward / weight tooltips and incomplete-epoch edge cases - block / tx / wallet polish - Updated indexers (28k less load on the network) - Devshards V3 flow alignment for inference data ingestion - A lot of backend work to make page load time go down 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". ### Product / data updates on gonka.gg (since the vote) **Inference after DevShards (v0.2.12+)** - Built and run a dedicated `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. - Added **DevShards v3** support in the poller (v2 and v3 coexist on hosts during migration; we probe `/devshard/v3` and union live shard inventories so traffic does not silently drop when gateways switch). ![](https://resource.inkdown.me/assets/11g/tk4ZX4b2sHaSu/SOejlg1EImWiYAz.png) **Network analytics** - **Model Weight Share** on `/network` - weight distribution across AI models per epoch, with an all-epochs view (Redis-cached so it stays fast). - GPU / reward-per-weight chart polish for in-progress epochs. - Live Devshard flow tightened to recent epochs so the UI stays honest under load. **Token holders** - Supply fetch fallbacks when LCD nodes flake. - Prune stale holder rows so rankings do not keep wallets that dropped under the qualification threshold. **Infra behind the explorer** (also see section 4) - Proper Frontend serving with lowest ttfb possible, API with horizontal auto-scaling, archive ClickHouse + tx-scanner + devshard-poller on dedicated server. - Continuous deploys for explorer fixes without taking the archive down. Explorer: [https://gonka.gg](https://gonka.gg) Inference: [https://gonka.gg/network/inference](https://gonka.gg/network/inference) Network: [https://gonka.gg/network](https://gonka.gg/network) ### Why it matters Faster deploys, less risk of a bugfix taking down indexing, room to run the heavier pre-compute work from the V2 explorer roadmap. *** ## 4. proxy.gonka.gg - B2B inference + public status [proxy.gonka.gg](https://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](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. ![](https://resource.inkdown.me/assets/11g/tk4ZX4b2sHaSu/2SJccZe5re5SE93.png) ### Numbers (as of Jul 18) 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. - **~29.0B tokens** served (~5.2M requests, ~96.8% OK) - **~23.6B tokens in the last 7 days** (~3.5M requests) - **~7.3B tokens in the last 24 hours** (~1.1M requests) - Peak recent days ~**4.8-5.0B tokens / day**; peak hour observed ~**823M tokens** in a single hour (~270k requests) - Model mix (token share): **MiniMax-M2.7 ~25.6B**, **Kimi-K2.6 ~3.4B**, plus residual Qwen / other - Accounts: +10-30 new accounts daily. ![](https://resource.inkdown.me/assets/11g/tk4ZX4b2sHaSu/hzZ0XERXO0tSDDp.png) ### What shipped since the vote - **Dedicated production box** for the API (`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. - **Own DevShard gateway ops** - escrow rotation, capacity-aware concurrency limits, admin tooling. Gateway now on **DevShards v3** (`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) - **Public status / analytics page** at [https://proxy.gonka.gg/status](https://proxy.gonka.gg/status) - aggregate capacity %, load, in-flight vs cap, active shards, network participant counts, error-rate history + reason breakdown. Deliberately no escrow ids / host IPs (safe to share with customers) - **Usage honesty** - requested-vs-served model on usage logs when fallback fires, so dashboards show what the client asked for and what actually ran - Product surface kept current for B2B: models page, docs, partner paths, top-up flows, password reset, etc. (dashboard UX work continued alongside the infra move) ### Why it matters 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: - Product: [https://proxy.gonka.gg](https://proxy.gonka.gg) - API: [https://api.proxy.gonka.gg/v1](https://api.proxy.gonka.gg/v1) - Status: [https://proxy.gonka.gg/status](https://proxy.gonka.gg/status) *** 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. *** ## Links - Gonka Labs: [https://gonkalabs.com](https://gonkalabs.com) - Explorer: [https://gonka.gg](https://gonka.gg) - OpenBroker: [https://openbroker.gonka.gg](https://openbroker.gonka.gg) - Pulse: [https://pulse.gonka.gg](https://pulse.gonka.gg) - Proxy: [https://proxy.gonka.gg](https://proxy.gonka.gg) - RPC: [https://rpc.gonka.gg](https://rpc.gonka.gg) - GitHub: [https://github.com/gonkalabs](https://github.com/gonkalabs) - OpenBroker launch: [https://github.com/gonka-ai/gonka/discussions/1363](https://github.com/gonka-ai/gonka/discussions/1363) Feedback welcome in the thread - what should we prioritize next month from the proposal list? --- ## #45 – Governance Architecture Proposal for the Gonka.ai Network # #45 – Governance Architecture Proposal for the Gonka.ai Network 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`](https://gonka.gg/address/gonka1syw6cs7jl5rmz7gpm3rq3836y2t484xp00ywrz){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/discussions/1104](https://github.com/gonka-ai/gonka/discussions/1104) **Failed reason:** proposal did not get enough votes to pass 119,000 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/45){:target="_blank"} 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: Full discussion: --- ## Final Tally Yes 118,126 (25.6%) No 0 (0.0%) Veto 210,906 (45.6%) Abstain 133,057 (28.8%) Total 462,089 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka14zlgmrd6v5gaqudxmvkn0yg8g55qpvcep9n6ds", "amount": [ { "denom": "ngonka", "amount": "119000000000000" } ] } ] ``` --- ## #37 – What is your stance on MLM projects around gonka.ai? # #37 – What is your stance on MLM projects around gonka.ai? Rejected **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`](https://gonka.gg/address/gonka1ry4uzczgu7xxusa5whl387dd5alr7737spd0v2){:target="_blank"} **Metadata:** [https://gonka.ai](https://gonka.ai) **Failed reason:** proposal did not get enough votes to pass 1 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/37){:target="_blank"} If you are against MLM projects around gonka.ai, vote YES. All funds will be used to counter such projects. The amount is symbolic. --- ## Final Tally Yes 957 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 957 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1ry4uzczgu7xxusa5whl387dd5alr7737spd0v2", "amount": [ { "denom": "ngonka", "amount": "1000000000" } ] } ] ``` --- ## #75 – Private Inc × Gonka — Network Growth Initiative # #75 – Private Inc × Gonka — Network Growth Initiative 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`](https://gonka.gg/address/gonka1q022xj6uyylzzhdlsh3jtkp5ycrnzwgpwgp4tn){:target="_blank"} **Metadata:** [https://vote.gonka.vip/tenders/ed8148eb-535e-4677-9a6b-5316c81c996a](https://vote.gonka.vip/tenders/ed8148eb-535e-4677-9a6b-5316c81c996a) **Failed reason:** proposal did not get enough votes to pass $300,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/75){:target="_blank"} 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: 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: --- ## Final Tally Yes 0 (0.0%) No 0 (0.0%) Veto 313,499 (100.0%) Abstain 0 (0.0%) Total 313,499 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "amount": "300000000000", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "recipient": "gonka1vvhnfezn37yc8aftc0af6rcn97xn53fqjmdzf9" } }, "funds": [] } ] ``` --- ## #73 – Increase minimum governance deposit to 500 GNK and expedited minimum deposit to 1000 GNK # #73 – Increase minimum governance deposit to 500 GNK and expedited minimum deposit to 1000 GNK Passed **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`](https://gonka.gg/address/gonka1337v0tk0ng0dhmz2pk9qv0gsvpe48eafppc6u8){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/73){:target="_blank"} 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. --- ## Final Tally Yes 295,843 (96.3%) No 40 (0.0%) Veto 572 (0.2%) Abstain 10,823 (3.5%) Total 307,278 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.gov.v1.MsgUpdateParams` | Contract Details ```json [ { "@type": "/cosmos.gov.v1.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "min_deposit": [ { "denom": "ngonka", "amount": "500000000000" } ], "max_deposit_period": "86400s", "voting_period": "172800s", "quorum": "0.250000000000000000", "threshold": "0.500000000000000000", "veto_threshold": "0.334000000000000000", "min_initial_deposit_ratio": "0.000000000000000000", "proposal_cancel_ratio": "0.500000000000000000", "proposal_cancel_dest": "", "expedited_voting_period": "43200s", "expedited_threshold": "0.667000000000000000", "expedited_min_deposit": [ { "denom": "ngonka", "amount": "1000000000000" } ], "burn_vote_quorum": false, "burn_proposal_deposit_prevote": false, "burn_vote_veto": true, "min_deposit_ratio": "0.010000000000000000" } } ] ``` --- ## #79 – Add Kimi K2.6 and GLM 5.2 model # #79 – Add Kimi K2.6 and GLM 5.2 model Passed **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`](https://gonka.gg/address/gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/79){:target="_blank"} Add Kimi K2.6 and GLM 5.2 model --- ## Final Tally Yes 330,364 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 330,364 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | | 2 | `/inference.inference.MsgRegisterModel` | | 3 | `/inference.inference.MsgRegisterModel` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "35", "poc_exchange_duration": "0", "poc_validation_delay": "5", "poc_validation_duration": "240", "set_new_validators_delay": "120", "inference_validation_cutoff": "2", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "500" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "processed_logprobs" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": true, "confirmation_poc_v2_enabled": true, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": true, "poc_stronger_rng_enabled": false, "models": [ { "model_id": "MiniMaxAI/MiniMax-M2.7", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "75", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "3024", "exponent": -4 }, "penalty_start_epoch": "278" }, { "model_id": "moonshotai/Kimi-K2.6", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "4", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "90", "exponent": -2 }, "penalty_start_epoch": "310" }, { "model_id": "zai-org/GLM-5.2-FP8", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "45", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "247", "exponent": -2 }, "penalty_start_epoch": "500" } ], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2475000", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2475000" }, "transfer_agent_access_params": { "allowed_transfer_addresses": [ "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u" ] }, "devshard_escrow_params": { "min_amount": "50000000", "max_amount": "100000000000", "max_escrows_per_epoch": 500000, "group_size": 16, "allowed_creator_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk", "gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90", "gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c", "gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn", "gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp" ], "token_price": "10", "approved_versions": [ { "name": "v1", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip", "sha256": "dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c" }, { "name": "v2", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip", "sha256": "1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b" } ], "max_nonce": 1000000, "devshard_requests_enabled": true, "default_inference_seal_grace_nonces": 0, "default_inference_seal_grace_seconds": 0, "create_devshard_fee": "0", "fee_per_nonce": "0", "refusal_timeout": "0", "execution_timeout": "0", "validation_rate": 0, "vote_threshold_factor": 0, "default_auto_seal_every_n_nonces": 0 }, "fee_params": { "min_gas_price_ngonka": "0", "base_validation_gas": "500000", "gas_per_poc_count": "100" }, "delegation_params": { "deploy_window": "500", "refusal_penalty": { "value": "1", "exponent": -1 }, "no_participation_penalty": { "value": "15", "exponent": -2 }, "delegation_share": { "value": "5", "exponent": -2 }, "w_threshold": { "value": "1", "exponent": -1 }, "v_min": "3", "cap_factor": { "value": "75", "exponent": -2 }, "initial_model_id": "MiniMaxAI/MiniMax-M2.7", "max_model_voting_power_percentage": { "value": "3", "exponent": -1 } }, "maintenance_params": null } }, { "@type": "/inference.inference.MsgRegisterModel", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "proposed_by": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "id": "moonshotai/Kimi-K2.6", "units_of_compute_per_token": "10000", "hf_repo": "moonshotai/Kimi-K2.6", "hf_commit": "5a49d036ab7472b7d5912ded487150ec1358c11d", "model_args": [ "--enable-auto-tool-choice", "--max-model-len", "240000", "--tool-call-parser", "kimi_k2", "--reasoning-parser", "kimi_k2" ], "v_ram": "720", "throughput_per_nonce": "1500", "validation_threshold": { "value": "900", "exponent": -3 } }, { "@type": "/inference.inference.MsgRegisterModel", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "proposed_by": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "id": "zai-org/GLM-5.2-FP8", "units_of_compute_per_token": "10000", "hf_repo": "zai-org/GLM-5.2-FP8", "hf_commit": "70311cfa0158cce7dd2cf5d2e04f68e3fdc3efc1", "model_args": [ "--reasoning-parser", "glm45", "--enable-auto-tool-choice", "--tool-call-parser", "glm47", "--max-model-len", "400000" ], "v_ram": "1120", "throughput_per_nonce": "700", "validation_threshold": { "value": "750", "exponent": -3 } } ] ``` --- ## Full Proposal > 📋 Part of the **[TheSoul × Gonka proposal overview](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/7)** — 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` ## Approach — data, not promises 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**. ## What we deliver - **Creator Selection & Outreach** — 8 primary creators + 5 backups, vetted by audience quality and past crypto performance. - **Brief & Approval** — creative briefs per creator, message alignment with the Gonka team, content review and sign-off. - **UTM Tracking** — unique UTM links per creator from day one, real-time click and conversion tracking across all placements. - **Performance Report** — full report at close: reach, clicks, CTR, and scaling recommendations for Phase 3. ## Final deliverable A live campaign with selected creators, a full performance report at close, and strategic scaling recommendations for Phase 3 — all based on real data. ## Terms | | | |---|---| | Timeline | 3 months | | Platforms | X · YouTube · Newsletters | | Market | Western, English-speaking | | Unlocks | Phase 3 scaling | ## On-chain action On pass, the gov authority calls the community USDT vault's `withdraw_ibc`, sending 50,000 USDT (IBC) to the recipient wallet: ```json { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "50000000000", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm" } }, "funds": [] } ``` USDT has 6 decimals: 50,000 × 10⁶ = 50,000,000,000. --- ## #62 – TheSoul - Offer 1.3: Influencer pilot (50,000 USDT) # #62 – TheSoul - Offer 1.3: Influencer pilot (50,000 USDT) 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`](https://gonka.gg/address/gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm){:target="_blank"} **Metadata:** [https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/3](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/3) $50,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/62){:target="_blank"} 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. --- ## Final Tally Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "50000000000", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm" } }, "funds": [] } ] ``` --- ## #68 – Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky) # #68 – Big YouTube Deep-Dive on Falcon Finance (Alexander Sokolovsky) 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`](https://gonka.gg/address/gonka1e3pepqllu89t8l2acw86fgp5jjkw8m7kcl47nk){:target="_blank"} **Metadata:** [https://vote.gonka.vip/tenders/550f71de-897f-4ce5-8af8-97854775f8b2](https://vote.gonka.vip/tenders/550f71de-897f-4ce5-8af8-97854775f8b2) $70,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/68){:target="_blank"} 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 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: --- ## Final Tally Yes 260,353 (96.4%) No 749 (0.3%) Veto 6,288 (2.3%) Abstain 2,546 (0.9%) Total 269,936 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "70000000000", "recipient": "gonka1w6amu8jg623pqrfw3a8wxlz0s2ph2yp0wvpuu3" } }, "funds": [] } ] ``` --- ## #78 – Governance 17: update PoC model lineup # #78 – Governance 17: update PoC model lineup 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`](https://gonka.gg/address/gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/78){:target="_blank"} 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. --- ## Final Tally Yes 255,215 (97.1%) No 170 (0.1%) Veto 0 (0.0%) Abstain 7,390 (2.8%) Total 262,775 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | | 2 | `/inference.inference.MsgDeleteGovernanceModel` | | 3 | `/inference.inference.MsgDeleteGovernanceModel` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "35", "poc_exchange_duration": "0", "poc_validation_delay": "5", "poc_validation_duration": "240", "set_new_validators_delay": "120", "inference_validation_cutoff": "2", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "500" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "processed_logprobs" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": true, "confirmation_poc_v2_enabled": true, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": true, "poc_stronger_rng_enabled": false, "models": [ { "model_id": "MiniMaxAI/MiniMax-M2.7", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "75", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "3024", "exponent": -4 }, "penalty_start_epoch": "278" } ], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2475000", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2475000" }, "transfer_agent_access_params": { "allowed_transfer_addresses": [ "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u" ] }, "devshard_escrow_params": { "min_amount": "50000000", "max_amount": "100000000000", "max_escrows_per_epoch": 500000, "group_size": 16, "allowed_creator_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk", "gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90", "gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c", "gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn", "gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp" ], "token_price": "10", "approved_versions": [ { "name": "v1", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip", "sha256": "dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c" }, { "name": "v2", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip", "sha256": "1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b" } ], "max_nonce": 1000000, "devshard_requests_enabled": true, "default_inference_seal_grace_nonces": 0, "default_inference_seal_grace_seconds": 0, "create_devshard_fee": "0", "fee_per_nonce": "0", "refusal_timeout": "0", "execution_timeout": "0", "validation_rate": 0, "vote_threshold_factor": 0, "default_auto_seal_every_n_nonces": 0 }, "fee_params": { "min_gas_price_ngonka": "0", "base_validation_gas": "500000", "gas_per_poc_count": "100" }, "delegation_params": { "deploy_window": "500", "refusal_penalty": { "value": "1", "exponent": -1 }, "no_participation_penalty": { "value": "15", "exponent": -2 }, "delegation_share": { "value": "5", "exponent": -2 }, "w_threshold": { "value": "1", "exponent": -1 }, "v_min": "3", "cap_factor": { "value": "75", "exponent": -2 }, "initial_model_id": "MiniMaxAI/MiniMax-M2.7", "max_model_voting_power_percentage": { "value": "3", "exponent": -1 } }, "maintenance_params": null } }, { "@type": "/inference.inference.MsgDeleteGovernanceModel", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "id": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8" }, { "@type": "/inference.inference.MsgDeleteGovernanceModel", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "id": "moonshotai/Kimi-K2.6" } ] ``` --- ## Full Proposal > 📋 Part of the **[TheSoul × Gonka proposal overview](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/7)** — 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` ## Approach — plan before you scale 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. ## What we deliver - **360° Strategy Document** — full digital playbook: channels, audiences, messages, formats, and volumes. - **Channel Matrix** — which channel for which audience, with what KPI and budget logic. - **Brand Voice Guidelines** — tone of voice by channel and segment: how Gonka sounds consistent everywhere. - **Social Media Strategy** — X, Telegram, LinkedIn: formats, frequency, content types, and an influencer framework. ## Final deliverable 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. ## Terms | | | |---|---| | Timeline | 2–3 weeks | | Requires | GA4 data (2.2) | | Commitment | This phase only | | Unlocks | Phase 3 | ## On-chain action On pass, the gov authority spends from the community pool, sending 100,000 GNK to the recipient wallet: ```json { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm", "amount": [{ "denom": "ngonka", "amount": "100000000000000" }] } ``` GNK has 9 decimals: 100,000 × 10⁹ = 100,000,000,000,000 ngonka (≈ 25,000 USDT at 0.25 GNK/USDT). --- ## #65 – TheSoul - Offer 2.3: Digital strategy (100,000 GNK) # #65 – TheSoul - Offer 2.3: Digital strategy (100,000 GNK) 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`](https://gonka.gg/address/gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm){:target="_blank"} **Metadata:** [https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/6](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/6) 100,000 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/65){:target="_blank"} 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. --- ## Final Tally Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm", "amount": [ { "denom": "ngonka", "amount": "100000000000000" } ] } ] ``` --- ## #50 – Retroactive bounty: open-source PoC throughput optimization (+10–12% measured) with 250 total installations # #50 – Retroactive bounty: open-source PoC throughput optimization (+10–12% measured) with 250 total installations 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`](https://gonka.gg/address/gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3){:target="_blank"} **Metadata:** [https://vote.gonka.vip/tenders/6392c2ea-7fb8-45c7-b1ec-80fb16d81d93](https://vote.gonka.vip/tenders/6392c2ea-7fb8-45c7-b1ec-80fb16d81d93) 20,000 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/50){:target="_blank"} 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: --- ## Final Tally Yes 281,723 (59.1%) No 0 (0.0%) Veto 0 (0.0%) Abstain 194,589 (40.9%) Total 476,312 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3", "amount": [ { "denom": "ngonka", "amount": "20000000000000" } ] } ] ``` --- ## Upgrade Proposal: v0.2.13 # Upgrade Proposal: v0.2.13 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. ## Upgrade Plan 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. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain. ## Migration The on-chain migration logic is defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.13/inference-chain/app/upgrades/v0_2_13/upgrades.go). Migrations: - Sets `DevshardEscrowParams.MaxEscrowsPerEpoch` to `500_000`. - Sets `DevshardEscrowParams.MaxNonce` to `1_000_000`. The previous settlement path used a hardcoded `20_000` nonce limit. - Sets `GenesisOnlyParams.GenesisGuardianMultiplier` to `0.33334`, reducing genesis guardian power from about 34% to about 25% of adjusted voting power while early-network protection applies. - Sets the chain-wide governance quorum to `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`). - Backfills `EpochGroupData.ConfirmationWeightScales` for the current epoch and clamps existing confirmation weights down to the new expected value. - Backfills `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. - Disables confirmation PoC triggers for the rest of the upgrade epoch via a grace-epoch `UpgradeProtectionWindow` of 3000 blocks. The new snapshot logic starts from the next epoch. - Adds MiniMax-M2.7 (`MiniMaxAI/MiniMax-M2.7`) as a governance model and PoC model config with `PenaltyStartEpoch = 271` (bootstrap activation epoch). - Updates `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: - Kimi (`moonshotai/Kimi-K2.6`): `0.78` - MiniMax (`MiniMaxAI/MiniMax-M2.7`): `0.3024` - Updates `Model.ValidationThreshold` from cross-version vLLM results: - Qwen (`Qwen/Qwen3-235B-A22B-Instruct-2507-FP8`): `0.940` - Kimi (`moonshotai/Kimi-K2.6`): `0.900` - MiniMax (`MiniMaxAI/MiniMax-M2.7`): `0.922` - Adds `--enable-auto-tool-choice` to Kimi `ModelArgs` if missing. ## Changes ### inference-chain - Confirmation PoC used different model sets for measured weight, preserved weight, and reward rescaling. During new-model bootstrap, this could reduce confirmation weight for honest miners serving both an eligible model and a not-yet-eligible model. v0.2.13 stores one epoch snapshot of confirmable models and weight-scale factors, then uses it for confirmation and reward calculations. - `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. - Devshard settlement now reads the nonce limit from `DevshardEscrowParams.MaxNonce` instead of a hardcoded constant. - Genesis guardians held about 34% of adjusted voting power, which made quorum hard to reach when they did not vote. The upgrade reduces guardian power to about 25% via `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`). ### decentralized-api - Some OpenAI-compatible upstreams return numeric `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. - The internal devshard service inside dapi uses the same devshard storage changes listed below, including pruning and Postgres support. ### devshard - Devshard storage could grow forever because old escrow data stayed in one SQLite store. Storage is now epoch-scoped and prunes old epochs in the background, keeping the latest 3 epochs. - Devshard can use Postgres as the primary store for larger deployments, with SQLite kept as a local fallback. - Postgres data is partitioned by `epoch_id` for sessions, diffs, and signatures, so pruning can drop old epoch data cleanly. --- ## #52 – Upgrade Proposal: v0.2.13 # #52 – Upgrade Proposal: v0.2.13 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/aa413e198825ddcc5eac80f4ca2e85a9bc54700e/proposals/governance-artifacts/update-v0.2.13/README.md](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](https://gonka.gg/network/proposals/52){:target="_blank"} Upgrade Proposal: v0.2.13 --- ## Final Tally Yes 88,420 (34.1%) No 0 (0.0%) Veto 170,799 (65.9%) Abstain 0 (0.0%) Total 259,219 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.13", "time": "0001-01-01T00:00:00Z", "height": "4133422", "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 }", "upgraded_client_state": null } } ] ``` --- ## #43 – Governance Architecture Proposal for the Gonka.ai Network # #43 – Governance Architecture Proposal for the Gonka.ai Network 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`](https://gonka.gg/address/gonka1syw6cs7jl5rmz7gpm3rq3836y2t484xp00ywrz){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/discussions/1104](https://github.com/gonka-ai/gonka/discussions/1104) **Failed reason:** proposal did not get enough votes to pass 104,166 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/43){:target="_blank"} 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: --- ## Final Tally Yes 123,104 (26.5%) No 335,534 (72.2%) Veto 5,913 (1.3%) Abstain 0 (0.0%) Total 464,551 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka14zlgmrd6v5gaqudxmvkn0yg8g55qpvcep9n6ds", "amount": [ { "denom": "ngonka", "amount": "104166000000000" } ] } ] ``` --- ## Support Gonka's Presence at WebX Asia # Support Gonka's Presence at WebX Asia **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 --- ## Summary 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. ## On-chain Proposal Text ### Support Gonka's presence at WebX Asia 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. ## On-chain Execution Details **Proposal JSON:** [`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](http://node1.gonka.ai:8000/dashboard/gonka/gov/42) ("Support Gonka at Global Compute Sovereignty Summit"). | Field | Value | |---|---| | Message type | `/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) | ## Post-Event Reporting 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. ## About 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 on July 13-14. --- ## #51 – Support Gonka's presence at WebX Asia # #51 – Support Gonka's presence at WebX Asia Passed **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`](https://gonka.gg/address/gonka15p7s7w2hx0y8095lddd4ummm2y0kwpwljk00aq){:target="_blank"} **Metadata:** [https://github.com/6block/gonka-webx-proposal/blob/main/README.md](https://github.com/6block/gonka-webx-proposal/blob/main/README.md) $75,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/51){:target="_blank"} 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: --- ## Final Tally Yes 395,003 (62.8%) No 1,767 (0.3%) Veto 64,217 (10.2%) Abstain 168,275 (26.7%) Total 629,262 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "75000000000", "recipient": "gonka1yqj5xf0wtqgpdmv5v68cus0tp2j5fv7lzcfd6g" } }, "funds": [] } ] ``` --- ## Upgrade Proposal: v0.2.12 # Upgrade Proposal: v0.2.12 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. ## Upgrade Plan 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`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.12/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//*` traffic is routed through `proxy -> versiond -> devshardd`. New hosts joining after the upgrade should use the updated container versions from this compose file. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain. ## Testing 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. ## Migration The on-chain migration logic is defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.12/inference-chain/app/upgrades/v0_2_12/upgrades.go). Migrations: - Auto-creates `x/feegrant` allowances for every existing cold-to-warm ML ops authz grant in case transaction fees are later turned on. - Initializes `FeeParams` with `min_gas_price_ngonka = 0` (fees are effectively disabled at upgrade time, see Changes). - Migrates singular PoC model parameters into the new multi-model `PocParams.Models` list and initializes `DelegationParams`. - Adds the `moonshotai/Kimi-K2.6` governance model and its PoC model config (`seq_len=1024`, scaled weight coefficient, penalty start at effective epoch + 2). - Seeds `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. - Sets `EpochParams.ConfirmationPocSafetyWindow` to `500` blocks and `DelegationParams.DeployWindow` to `500` blocks. - Clears legacy PoC v2 data (which used old key layouts) and seeds new pruning state markers for the new multi-model collections. - Backfills `ActiveParticipant.VotingPowers` and `EpochGroupData` subgroup voting power for the current epoch to ensure seamless PoC validation post-upgrade. - Removes unused `TopMiners` and training states (training will be moved to an off-chain architecture similar to devshards). ## Changes ### [Multi-model PoC](https://github.com/gonka-ai/gonka/pull/1039) 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: - Each governance-approved model gets its own PoC group. PoC runs for all eligible groups in parallel. - Weight is split into two layers. `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. - Because not every Host can run every model, a Host not serving a model can delegate its consensus weight to a group member for PoC validation only (this does not affect block signing or governance voting power). This preserves the existing security model: a model group must reach a 2/3 validation threshold of the *total network consensus weight*, not just the group-local weight, even if its direct members hold less than that total amount. - For each active model, Hosts must explicitly choose their participation mode (DIRECT, DELEGATE, REFUSE). Hosts who do nothing receive a penalty. Penalties are skipped during a model's initial grace period. 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. ### Transaction fees for spam prevention ([#937](https://github.com/gonka-ai/gonka/pull/937), [#981](https://github.com/gonka-ai/gonka/pull/981), [#1120](https://github.com/gonka-ai/gonka/pull/1120)) 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. ### Devshards (formerly "subnets") — standalone, versioned runtime ([#1045](https://github.com/gonka-ai/gonka/pull/1045)) 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. - Multiple devshard versions can run side-by-side. Traffic to `/devshard//*` is routed to the corresponding binary, while the legacy `/v1/devshard/*` route remains active during the transition. - The standalone devshard directly communicates with MLNodes during inference but does not manage their lifecycle, cleanly separating the roles of MLNode manager (DAPI) and client. - Each session is cryptographically bound to the specific binary version that served it. The settlement payload now includes a cleartext `version` field, ensuring a session cannot mix responses from different versions. - The term "subnet" is entirely replaced by "devshard" across the codebase. Additionally, float math in devshard settlement has been replaced with deterministic integer arithmetic to eliminate consensus-failure risks. ### Random selection of preserved MLNodes ([#1089](https://github.com/gonka-ai/gonka/pull/1089)) 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: - Late-binding: an operator cannot predict far in advance whether a given node will be preserved for the next PoC window. - The candidate pool is the current model subgroup `EpochGroupData.ValidationWeights` / `MlNodes`, applying existing protocol exclusions. - `ActiveParticipants` stays stable for the whole epoch; `timeslot_allocation[POC_SLOT]` is deprecated for scheduling. - The broker reads the current episode snapshot instead of the static epoch-long flag. - Reward weight collapses from the old "preserved + measured" split into a single `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. ### New governance model: Kimi K2.6 (`moonshotai/Kimi-K2.6`) 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. ### Certik audit fixes 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. ### Removals and cleanups - The unused TopMiner reward logic is removed, and the upgrade handler clears the `TopMiners` collection during migration with no financial impact. - The in-chain training placeholder is removed. The feature was never used and carried security risks, so training is moving to an off-chain architecture similar to devshards. - Developers no longer need to register as a Participant to run inference, as an account with a public key on chain is now sufficient. ### Protocol hardening and correctness - PoC v2 RNG is stronger because the new mechanism addresses the 32-bit entropy flaw that made forged proofs feasible. It will be activated via an additional governance vote once MLNodes are updated. - The MLNode version is now propagated to chain state so the network always reflects the exact software version each node is running. This allows the network to track adoption of new MLNode versions. - A long-standing consensus issue in the BLS DKG dealing phase is corrected. - Validator slashing now consistently aligns with the required-collateral model instead of legacy behavior. - Fixes a bug where `inference_finished` event parsing failed on zero-timestamps. ### API and tooling improvements - The DAPI now accepts multipart-encoded OpenAI requests alongside JSON to improve compatibility with upstream SDKs. - More accurate HTTP status codes and error shapes, including 400/422 for malformed payloads, ensure upstream OpenAI SDKs behave correctly. - The DAPI exposes node acquisition RPCs in the private network with TTL eviction via a new NodeManager gRPC server, which lets external services like devshards coordinate MLNode usage cleanly. - End-to-end inference validation tests in Testermint are updated to cover status transitions. - Deployment documentation is updated with multisig and access-control setups for production operators. #### Action will be required ##### Multi-model 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: - DIRECT mode means the Host runs the model and participates in its PoC directly. - DELEGATE mode means the Host delegates its PoC validation power for that model to another Host running it. - REFUSE mode means the Host explicitly refuses participation for that model. - INTENT mode means the Host declares early intent to participate before deploying hardware for models approved but not yet active. - NONE mode means the Host does nothing for that model (this will result in a penalty). *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.* --- ## #44 – Upgrade Proposal: v0.2.12 # #44 – Upgrade Proposal: v0.2.12 Passed **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/76d0eb971233f9544f681a25e860844e3f45641e/proposals/governance-artifacts/update-v0.2.12/README.md](https://github.com/gonka-ai/gonka/blob/76d0eb971233f9544f681a25e860844e3f45641e/proposals/governance-artifacts/update-v0.2.12/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/44){:target="_blank"} Upgrade Proposal: v0.2.12 --- ## Final Tally Yes 506,142 (99.6%) No 2,057 (0.4%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 508,199 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.12", "time": "0001-01-01T00:00:00Z", "height": "3834200", "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 }", "upgraded_client_state": null } } ] ``` --- ## Full Proposal > 📋 Part of the **[TheSoul × Gonka proposal overview](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/7)** — 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` ## Approach — the website as a conversion tool 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. ## What we deliver - **Website Redesign** — full redesign built on the brandbook: identity, navigation, hero, and information architecture. - **3 Core Audience Landing Pages** — one page per segment defined in 1.1, each with its own messaging and CTA. - **CTA Architecture** — conversion paths per audience: from landing page to target action. - **Mobile Optimization** — full responsiveness, Core Web Vitals, tracking-ready infrastructure for 2.2. ## Final deliverable 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. ## Terms | | | |---|---| | Timeline | 4–6 weeks | | Requires | Positioning (1.1) + Brandbook (1.2) | | Commitment | This phase only | | Unlocks | Offer 2.2 | ## On-chain action On pass, the gov authority calls the community USDT vault's `withdraw_ibc`, sending 10,000 USDT (IBC) to the recipient wallet: ```json { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "10000000000", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm" } }, "funds": [] } ``` USDT has 6 decimals: 10,000 × 10⁶ = 10,000,000,000. --- ## #63 – TheSoul - Offer 2.1: Website and landings (10,000 USDT) # #63 – TheSoul - Offer 2.1: Website and landings (10,000 USDT) 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`](https://gonka.gg/address/gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm){:target="_blank"} **Metadata:** [https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/4](https://github.com/ADME-CY-LTD/thesoul-gonka-proposals/issues/4) $10,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/63){:target="_blank"} 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. --- ## Final Tally Yes 220,798 (67.9%) No 0 (0.0%) Veto 70,043 (21.5%) Abstain 34,369 (10.6%) Total 325,210 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "10000000000", "recipient": "gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm" } }, "funds": [] } ] ``` --- ## #38 – CryptoCommons: Community Support & Token Promotion Plan # #38 – CryptoCommons: Community Support & Token Promotion Plan Rejected **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`](https://gonka.gg/address/gonka1kk4a0kuc6uh5yrlfqe2ehuq6a4v7vcxx8fvxxr){:target="_blank"} **Metadata:** [https://discord.com/channels/1336477374442770503/1425189436748206171/1481942972055552041](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 Module [View on gonka.gg](https://gonka.gg/network/proposals/38){:target="_blank"} 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 --- ## Final Tally Yes 0 (0.0%) No 183 (2.3%) Veto 7,893 (97.7%) Abstain 0 (0.0%) Total 8,076 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.streamvesting.MsgBatchTransferWithVesting` | | 2 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/inference.streamvesting.MsgBatchTransferWithVesting", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "outputs": [ { "recipient": "gonka1lqjjgnme3ayk2q0w8thxnhx69l639dtz9j3r2l", "amount": [ { "denom": "ngonka", "amount": "25000000000000" } ] } ], "vesting_epochs": "180" }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1lqjjgnme3ayk2q0w8thxnhx69l639dtz9j3r2l", "amount": [ { "denom": "ngonka", "amount": "20000000000000" } ] } ] ``` --- ## #47 – Retroactive bounty: open-source PoC throughput optimization (+10–12% measured) with 250 total installations # #47 – Retroactive bounty: open-source PoC throughput optimization (+10–12% measured) with 250 total installations 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`](https://gonka.gg/address/gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3){:target="_blank"} **Metadata:** [https://vote.gonka.vip/tenders/6392c2ea-7fb8-45c7-b1ec-80fb16d81d93](https://vote.gonka.vip/tenders/6392c2ea-7fb8-45c7-b1ec-80fb16d81d93) **Failed reason:** proposal did not get enough votes to pass 20,000 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/47){:target="_blank"} 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: --- ## Final Tally Yes 70,819 (33.6%) No 0 (0.0%) Veto 0 (0.0%) Abstain 139,828 (66.4%) Total 210,647 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3", "amount": [ { "denom": "ngonka", "amount": "20000000000000" } ] } ] ``` --- ## Full Proposal 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. --- ## #55 – GRC Proposal #2 - Restitution (epochs 248-254) # #55 – GRC Proposal #2 - Restitution (epochs 248-254) 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`](https://gonka.gg/address/gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k){:target="_blank"} **Metadata:** [https://github.com/votkon/grc-proposal-2](https://github.com/votkon/grc-proposal-2) 39,722 GNK · Community Pool · 306,307 GNK · Gov Module [View on gonka.gg](https://gonka.gg/network/proposals/55){:target="_blank"} 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. --- ## Final Tally Yes 188,670 (61.2%) No 0 (0.0%) Veto 0 (0.0%) Abstain 119,835 (38.8%) Total 308,505 votes ## Messages | # | 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 ```json [ { "@type": "/inference.streamvesting.MsgBatchTransferWithVesting", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "outputs": [ { "recipient": "gonka12av9up884t9lcsf70rs0l7jfmkmc8k9sxfuknt", "amount": [ { "denom": "ngonka", "amount": "87515706412000" } ] }, { "recipient": "gonka1q5xt54wncgzk7dxv9x64uln68455g83wu9tugg", "amount": [ { "denom": "ngonka", "amount": "52989936765000" } ] }, { "recipient": "gonka1famtxh54kad6ylwtm60j6d7h6unpc08d4vdqnk", "amount": [ { "denom": "ngonka", "amount": "30915639076000" } ] }, { "recipient": "gonka1umvyh0rz5fdmk9qhxurshhchennajced6f4s89", "amount": [ { "denom": "ngonka", "amount": "19853590458000" } ] }, { "recipient": "gonka188c86f9mrlt4nlcg89f82nnfm9jzq9gtjafj50", "amount": [ { "denom": "ngonka", "amount": "11685431400000" } ] }, { "recipient": "gonka1dzdmx5ljrwkelrmgd7suv2q43epn293qacpgqn", "amount": [ { "denom": "ngonka", "amount": "10930934355000" } ] }, { "recipient": "gonka1r5hdy9q5v783ef7td98k4c68cxl6a58h5sytfq", "amount": [ { "denom": "ngonka", "amount": "4623954018000" } ] }, { "recipient": "gonka163ug8zucqeag9v5ey4au34jqt7vejkmxsg74eu", "amount": [ { "denom": "ngonka", "amount": "4086605073000" } ] }, { "recipient": "gonka1wkgawwdzj623ss8eywayzdj6qcgr2llygactje", "amount": [ { "denom": "ngonka", "amount": "3933361320000" } ] }, { "recipient": "gonka1zsvl7ujlc8z3a35v2q6e3nml7ftyk23v76jqgl", "amount": [ { "denom": "ngonka", "amount": "3409330900000" } ] }, { "recipient": "gonka1vcvn2p5gczr5pynqq0ca0933tdrf5w64sjgtdg", "amount": [ { "denom": "ngonka", "amount": "2481939374000" } ] }, { "recipient": "gonka1wthc28t25pg63hzvl07rl8e8r6km6hesl6jhsz", "amount": [ { "denom": "ngonka", "amount": "2358756296000" } ] }, { "recipient": "gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu", "amount": [ { "denom": "ngonka", "amount": "1987904622000" } ] }, { "recipient": "gonka1u9a7r4w76gult5n9ysadnual9fghkc6yda60wj", "amount": [ { "denom": "ngonka", "amount": "1945265555000" } ] }, { "recipient": "gonka1pvkv59e72vju2h7s9j3ex62c5xneqey350vpwn", "amount": [ { "denom": "ngonka", "amount": "1927972100000" } ] }, { "recipient": "gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np", "amount": [ { "denom": "ngonka", "amount": "1894756997000" } ] }, { "recipient": "gonka1dpt9zx2dqcky6yjjwrd8xz2w7lq6vffy9mhvgs", "amount": [ { "denom": "ngonka", "amount": "1841921987000" } ] }, { "recipient": "gonka1lswsj2x7u4606wqpunmm07skgf76r3dyz4v0d8", "amount": [ { "denom": "ngonka", "amount": "1827469872000" } ] }, { "recipient": "gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09", "amount": [ { "denom": "ngonka", "amount": "1812926330000" } ] }, { "recipient": "gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0", "amount": [ { "denom": "ngonka", "amount": "1780381271000" } ] }, { "recipient": "gonka1ge9amk4ymld27d35akj3ky9uph4gyz6rdpepjj", "amount": [ { "denom": "ngonka", "amount": "1771829231000" } ] }, { "recipient": "gonka1jltjehxsnum94nt8c00ts7khmpy4lafv6gryzk", "amount": [ { "denom": "ngonka", "amount": "1741951170000" } ] }, { "recipient": "gonka1llgg3kvg9sc6xz09jtkcrucrppxgn78xe4xlv0", "amount": [ { "denom": "ngonka", "amount": "1727750282000" } ] }, { "recipient": "gonka145666cll76ptcyy9ceymtalr8gnvv73ne99p32", "amount": [ { "denom": "ngonka", "amount": "1688729573000" } ] }, { "recipient": "gonka1slndy4rsmld579628302rj5gz8z9qf4v6ppmc4", "amount": [ { "denom": "ngonka", "amount": "1602460126000" } ] }, { "recipient": "gonka19cjm4c5mt3j3qdr8vhytmm4hef3pnkvkm0x7m2", "amount": [ { "denom": "ngonka", "amount": "1581661457000" } ] }, { "recipient": "gonka187tn9y92ur6tu0zf69u94hwl0q77m47y0k36hv", "amount": [ { "denom": "ngonka", "amount": "1573597372000" } ] }, { "recipient": "gonka1pllyukkeymx3hfd9mts3pryr9y6efs9eshty87", "amount": [ { "denom": "ngonka", "amount": "1572442861000" } ] }, { "recipient": "gonka14tqh62mangwzrma2lgg2dm375rcjzn2ydy8ttm", "amount": [ { "denom": "ngonka", "amount": "1482391068000" } ] }, { "recipient": "gonka1043d00lu0v3fz53cut34twtcanalqg9u8vehp2", "amount": [ { "denom": "ngonka", "amount": "1478451308000" } ] }, { "recipient": "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "amount": [ { "denom": "ngonka", "amount": "1446802128000" } ] }, { "recipient": "gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e", "amount": [ { "denom": "ngonka", "amount": "1416649392000" } ] }, { "recipient": "gonka18xeqnspxpg2vncufnjne485rkaagwvz7whyn0d", "amount": [ { "denom": "ngonka", "amount": "1387426691000" } ] }, { "recipient": "gonka1t8p0tjqls358gmzvd3rnnjulraq2k3m772vnt8", "amount": [ { "denom": "ngonka", "amount": "1377181840000" } ] }, { "recipient": "gonka19ghzvgfr065s3fr5awuvs3nhy9fq4n7wrr9kel", "amount": [ { "denom": "ngonka", "amount": "1348734584000" } ] }, { "recipient": "gonka1h3s37p0l23mg6ak9h9nmayh6r9f2vm6umj3qet", "amount": [ { "denom": "ngonka", "amount": "1343669924000" } ] }, { "recipient": "gonka16k03ze5ynkprsd4n6e5uzhthvu9jjk553rauqy", "amount": [ { "denom": "ngonka", "amount": "1291153511000" } ] }, { "recipient": "gonka1zpw8tml8xl4fm6zm8zpf2u4pq4tehmd9e2vgq7", "amount": [ { "denom": "ngonka", "amount": "1252141319000" } ] }, { "recipient": "gonka1ccdm8j6sjyhq4qask049dwgaczs7f3pxte6zmp", "amount": [ { "denom": "ngonka", "amount": "1240267552000" } ] }, { "recipient": "gonka12pcu9mcrpa4w4sjd9y3dsksnvu495ss6f9r4ra", "amount": [ { "denom": "ngonka", "amount": "1155361073000" } ] }, { "recipient": "gonka16q0zaetd6hq6d8zj48ur0v967xrrwh566kcazc", "amount": [ { "denom": "ngonka", "amount": "1122206687000" } ] }, { "recipient": "gonka12gc47yq8m7rnsa3aucq8mlzm7men8jaac7qkkz", "amount": [ { "denom": "ngonka", "amount": "1048532370000" } ] }, { "recipient": "gonka1tlvg4kjx7ljd5thgd5fkgh39q6lu8cmxupktgg", "amount": [ { "denom": "ngonka", "amount": "1045748557000" } ] }, { "recipient": "gonka1mdy7nlecw4xaqdxmeh3qlqzakg9ftge9szfqgg", "amount": [ { "denom": "ngonka", "amount": "1042787803000" } ] }, { "recipient": "gonka1y4kyhqy022gt4kklxxflgqkutnx96ssww66zg6", "amount": [ { "denom": "ngonka", "amount": "942026558000" } ] }, { "recipient": "gonka1m27e6qup7q8jmvnrn29kahd7vlx6r4l84z4thz", "amount": [ { "denom": "ngonka", "amount": "889089066000" } ] }, { "recipient": "gonka1xwkesaxvdadh9wt9yyladu0r260s7whklcktds", "amount": [ { "denom": "ngonka", "amount": "858868299000" } ] }, { "recipient": "gonka12fazh3etpdx947ldwen4wudnds7wu4kjp5vd76", "amount": [ { "denom": "ngonka", "amount": "811918139000" } ] }, { "recipient": "gonka1lr9mj6dgkv0h76c8y8w0l3esztyg9v2q8d6d8d", "amount": [ { "denom": "ngonka", "amount": "806228688000" } ] }, { "recipient": "gonka17ef5hl0588tmjm9ypw7t2kge78wrkcpvyspc0p", "amount": [ { "denom": "ngonka", "amount": "771087961000" } ] }, { "recipient": "gonka1fp8zl07qccdzuekns2q55jgmcag40kjrm8z0z9", "amount": [ { "denom": "ngonka", "amount": "741302011000" } ] }, { "recipient": "gonka12tfc6ccmadjqv6yaa3axxsuhy6zv6tupu78p8u", "amount": [ { "denom": "ngonka", "amount": "726053879000" } ] }, { "recipient": "gonka1tl5m3vuqsx333v7095ymwjdc4vdk2wd9r5hqws", "amount": [ { "denom": "ngonka", "amount": "722793158000" } ] }, { "recipient": "gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw", "amount": [ { "denom": "ngonka", "amount": "705402646000" } ] }, { "recipient": "gonka1fc9tzt83dgrqswlgay4668cuqjrk7zsqks2vm2", "amount": [ { "denom": "ngonka", "amount": "688423583000" } ] }, { "recipient": "gonka17tlh09e32xpv2uj433ytjnwwd8fh24jclpzm5s", "amount": [ { "denom": "ngonka", "amount": "643577322000" } ] }, { "recipient": "gonka1cckj93kp9kegry64scpn4ew9965g3qrswyshl9", "amount": [ { "denom": "ngonka", "amount": "599735081000" } ] }, { "recipient": "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "amount": [ { "denom": "ngonka", "amount": "579778319000" } ] }, { "recipient": "gonka17fcahf38xh8ghzyyrc55tarz9nd0vw6xd29nsk", "amount": [ { "denom": "ngonka", "amount": "568610436000" } ] }, { "recipient": "gonka1gyydhl9lp0udz3409ps0c0lk0y4ft8qcyv8tfq", "amount": [ { "denom": "ngonka", "amount": "562251638000" } ] }, { "recipient": "gonka1nkzdygk3g2p2usnueuqxyep3462350hgzxs86s", "amount": [ { "denom": "ngonka", "amount": "558904902000" } ] }, { "recipient": "gonka15rvksn9gxgpszyr8270cd4wj2x3d460r394uv4", "amount": [ { "denom": "ngonka", "amount": "552211430000" } ] }, { "recipient": "gonka1usmu5mfu8vsafvsrsvdutl50vy8kumdhv0j2x9", "amount": [ { "denom": "ngonka", "amount": "552211430000" } ] }, { "recipient": "gonka1psgzz288a434dv6863ldd73xma70zw7387muj2", "amount": [ { "denom": "ngonka", "amount": "548864694000" } ] }, { "recipient": "gonka1ql9asemklpkpr2d4mh33xw5gj0g5tm0v98c5q3", "amount": [ { "denom": "ngonka", "amount": "548864694000" } ] }, { "recipient": "gonka1vcawx5jc2hahydd9sqw30hlxyd9ppupm9ez0yz", "amount": [ { "denom": "ngonka", "amount": "542171223000" } ] }, { "recipient": "gonka1p60lruhxmwcsa9taa28cp4k4f6kv2kvyu5h5ep", "amount": [ { "denom": "ngonka", "amount": "534999150000" } ] }, { "recipient": "gonka10snluhflqhmwl5xrpuy9ugevypxdjjsft370fq", "amount": [ { "denom": "ngonka", "amount": "525437543000" } ] }, { "recipient": "gonka14g78ez2zy08k8sssue483zmfpgd4qut8zcwlqc", "amount": [ { "denom": "ngonka", "amount": "522077665000" } ] }, { "recipient": "gonka1tmk2tzdneht6smu34pkmqdvu7p34qavvmwtwq2", "amount": [ { "denom": "ngonka", "amount": "515397335000" } ] }, { "recipient": "gonka1830lqug50lse998x2lakk4pj5ypfumz5pasz0y", "amount": [ { "denom": "ngonka", "amount": "505691801000" } ] }, { "recipient": "gonka168yvlgt9jg86frg2z90cc8w4pz9hnd7f8lshux", "amount": [ { "denom": "ngonka", "amount": "498998329000" } ] }, { "recipient": "gonka1h2m79scgaq6ultrwge03wjk0ys4whgcejphmql", "amount": [ { "denom": "ngonka", "amount": "474959200000" } ] }, { "recipient": "gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2", "amount": [ { "denom": "ngonka", "amount": "451760266000" } ] }, { "recipient": "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "amount": [ { "denom": "ngonka", "amount": "396253535000" } ] }, { "recipient": "gonka1d7p03cu2y2yt3vytq9wlfm6tlz0lfhlgv9h82p", "amount": [ { "denom": "ngonka", "amount": "365789060000" } ] }, { "recipient": "gonka1p2lhgng7tcqju7emk989s5fpdr7k2c3ek6h26m", "amount": [ { "denom": "ngonka", "amount": "365789060000" } ] }, { "recipient": "gonka1fvly5jrewyjmjfgwah3khy9rttq4cqajcesv9p", "amount": [ { "denom": "ngonka", "amount": "357960400000" } ] }, { "recipient": "gonka1k6p754pyhxud2399knyccgjpjvdafj2u9xlgyf", "amount": [ { "denom": "ngonka", "amount": "329318817000" } ] }, { "recipient": "gonka1eazh84v0e60s9m7exxp3nsadcfgvnsthgypjvl", "amount": [ { "denom": "ngonka", "amount": "311581116000" } ] }, { "recipient": "gonka1zktn8j65wlys8a8e38hqhf4y3x6m4x04zskkrx", "amount": [ { "denom": "ngonka", "amount": "271309892000" } ] }, { "recipient": "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "amount": [ { "denom": "ngonka", "amount": "252678564000" } ] }, { "recipient": "gonka1vjz8csqsr0ph0lv0yylc4auypnzrld7y6l2feu", "amount": [ { "denom": "ngonka", "amount": "233997500000" } ] }, { "recipient": "gonka1qwfrtz9c7kcrfkrrlne2pkcye74mj6ce33xdkl", "amount": [ { "denom": "ngonka", "amount": "220215225000" } ] }, { "recipient": "gonka1l0qv64xdu3dk2zzm5vk97j0drcmkus95u50gqk", "amount": [ { "denom": "ngonka", "amount": "192771990000" } ] }, { "recipient": "gonka10jjrlvkfkqupgudz0l603sq99y3wkt3urwjm0x", "amount": [ { "denom": "ngonka", "amount": "149599097000" } ] }, { "recipient": "gonka1gyk0aahvr3qeju4zx0nplfreej6cy4jjk8svc5", "amount": [ { "denom": "ngonka", "amount": "142236278000" } ] }, { "recipient": "gonka10t67f5zxh7canhuznxg7cperec6286jjqh5pey", "amount": [ { "denom": "ngonka", "amount": "140897583000" } ] }, { "recipient": "gonka1uf5cg7ef0ns6877nl27y0s6rt06cdmn40k5a88", "amount": [ { "denom": "ngonka", "amount": "59571900000" } ] }, { "recipient": "gonka15sptlamre9vq4m5t7pa7je5r2pc34kmlwvj0jz", "amount": [ { "denom": "ngonka", "amount": "23911954000" } ] } ], "vesting_epochs": "150" }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3", "amount": [ { "denom": "ngonka", "amount": "4500000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka16j4zv6723mrnycwn0qgw0j48dr9qecyclxg5jh", "amount": [ { "denom": "ngonka", "amount": "8875000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6", "amount": [ { "denom": "ngonka", "amount": "11062500000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k", "amount": [ { "denom": "ngonka", "amount": "15284700000000" } ] } ] ``` --- ## Gonka NOP - grant for the node deployment tool # Gonka NOP - grant for the node deployment tool A CommunityPool funding request covering delivered work on gonka-nop, ongoing operator support, and continued development of the tool. ## TL;DR 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. ## What is gonka-nop 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. - 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 ## The deployment problem 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. ## Proposal 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. ## Grant terms 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: - https://vote.gonka.vip/tenders/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde - https://gonkavote.com/proposals/6 ## Why this matters for the network 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. ## INC4 - Website: https://inc4.net - GitHub: https://github.com/inc4 --- ## #56 – INC4 | Gonka NOP - grant for the node deployment tool # #56 – INC4 | Gonka NOP - grant for the node deployment tool 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`](https://gonka.gg/address/gonka1juwk05glldgn7850a3547jsl7l4vrhx9k5g3cr){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/discussions/1192](https://github.com/gonka-ai/gonka/discussions/1192) **Failed reason:** proposal did not get enough votes to pass $50,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/56){:target="_blank"} # Gonka NOP: grant for the node deployment tool 50,000 USDT from the CommunityPool to INC4 Full proposal: ## What it is 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. ## What the grant covers 1. Work already delivered - INC4 took on the initial development as a contribution to the network. 2. Support for NOP users - 6 months of help, fixes, updates with every network release. 3. Continued development - expanding functionality, supporting more deployment scenarios, lowering the entry barrier further, etc. ## Why this matters for the network 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. ## Terms - Single payment, no vesting or tranches - Work is open on GitHub: code, releases, issues - this is the report to the DAO ## Links Repository on GitHub: Documentation: Live walkthrough on YouTube (by Gonka.Top@Mitch): --- ## Final Tally Yes 31,851 (58.6%) No 9,566 (17.6%) Veto 12,961 (23.8%) Abstain 0 (0.0%) Total 54,378 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "50000000000", "recipient": "gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3" } }, "funds": [] } ] ``` --- ## #49 – Gonka Media Dominance in TechL/AI with 5 AI Influencers # #49 – Gonka Media Dominance in TechL/AI with 5 AI Influencers Passed **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`](https://gonka.gg/address/gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09){:target="_blank"} **Metadata:** [https://app.notion.com/p/Gonka-AI-AI-Influencer-Lab-Proposal-3514ff1f5a9a81faae76efbeb153cbe2](https://app.notion.com/p/Gonka-AI-AI-Influencer-Lab-Proposal-3514ff1f5a9a81faae76efbeb153cbe2) $45,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/49){:target="_blank"} 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: --- ## Final Tally Yes 496,683 (71.1%) No 0 (0.0%) Veto 0 (0.0%) Abstain 201,560 (28.9%) Total 698,243 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "45000000000", "recipient": "gonka1ugpgrr9quvmw9qdsw9wf6s56c5vvl62v9chqmv" } }, "funds": [] } ] ``` --- ## ICG — AI Avatars Monthly Report No.1 # ICG — AI Avatars Monthly Report No.1 **Дата публикации:** 2026-07-21 --- Всем привет! На связи команда ICG — продолжаем работу над AI-аватарами «Гонки». Ниже — апдейт по проекту с цифрами за всё время с запуска. ## Что сделано к этому моменту - Перезапустили площадки, которые не пошли с первого раза — у Gonka 1 перезапущенный YouTube принёс основную массу подписчиков - Там, где рост на отдельных площадках ниже планируемого, запускаем параллельные аккаунты — чтобы минимизировать риск, что алгоритмы пессимизируют аккаунт и нужных охватов не будет --- ### 1. GONKA AI 1 Концепция: девушка-аватар — 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). --- ### 2. GONKA AI 2 Концепция: мужской аватар 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 растёт ниже плана — параллельно запустили второй аккаунт. --- ### 3. GONKA AI 3 Концепция: мужской аватар 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. --- ### 4. GONKA AI 4 Концепция: девушка-аватар — бывший 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% | --- ### 5. GONKA AI 5 Концепция: мужской аватар Dean — разработчик-одиночка нового типа: строит продукты с помощью AI-инструментов. | Метрика | Значение | | :--- | :--- | | Опубликовано | 83 видео из 180 по плану | | Подписчики | 1 072 | | Суммарный охват | 191 573 | | Средние просмотры | IG 861 · TikTok 638 · YouTube 580 | | ER | IG 1,20% · TikTok 3,11% · YouTube 1,85% | Здесь самые слабые просмотры по проекту — мы полностью поменяли внешность аватара и продолжаем паблишинг уже с новым обликом. --- ## Итого по всем 5 аватарам - **~2 540 000** суммарного охвата - **8 300+** подписчиков Немного прозрачности, как обычно: часть площадок мы перезапускали, и цифры выше включают подписчиков и старых, и новых версий аккаунтов. Перезапуски и параллельные аккаунты — штатная часть работы с AI-аватарами на ранней фазе. Есть аккаунты как Gonka 3, которые отлично растут и дальше будут становится сильно выше среднего, есть те которые растут хуже. Мы постоянно итерируем внешности, перезапускаем аккаунты чтобы сделать более быстрый рост. Пока мы идём в +- плане от метрик которые были изначально. С учётом того что некоторые аккаунты перезапускаются, мы будем переопубликовывать видео которые были опубликованны в старые и поэтому суммарно опубликованных видео в нашем батче 3-х месячном будет больше 180. Сейчас осталось ещё 1,5–2 месяца паблишинга дейли контента во все соцсети. ## Почему мы всё ещё не показываем сами соцсети 🔒 Позиция не изменилась: аккаунты в фазе активного роста, публичные ссылки сейчас — это риск теневых банов, копикатов и накрутки, искажающей органический сигнал. Вся информация по аккаунтам по-прежнему у команды ancapex — они могут независимо подтвердить цифры. ## Что дальше Усиливаем Gonka 3, докатываем параллельные аккаунты там, где рост ниже плана, и смотрим на первые цифры AI 5 с новой внешностью. Через 2 недели вернёмся с новым апдейтом. --- ## #36 – Register Kava USDT IBC metadata and approve for trading # #36 – Register Kava USDT IBC metadata and approve for trading 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`](https://gonka.gg/address/gonka1m9sf2rpg635efaw59djqlxkqew9sxvmqd6g343){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/36){:target="_blank"} Register IBC token metadata and approve the denomination for trading on Gonka mainnet. --- ## Final Tally Yes 421,414 (99.6%) No 0 (0.0%) Veto 0 (0.0%) Abstain 1,788 (0.4%) Total 423,202 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgRegisterIbcTokenMetadata` | | 2 | `/inference.inference.MsgApproveIbcTokenForTrading` | Contract Details ```json [ { "@type": "/inference.inference.MsgRegisterIbcTokenMetadata", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "chainId": "kava_2222-10", "ibcDenom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "name": "USDT", "symbol": "USDT", "decimals": 6, "overwrite": true }, { "@type": "/inference.inference.MsgApproveIbcTokenForTrading", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "chainId": "kava_2222-10", "ibcDenom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4" } ] ``` --- ## Gonka NOP - grant for the node deployment tool # Gonka NOP - grant for the node deployment tool A CommunityPool funding request covering delivered work on gonka-nop, ongoing operator support, and continued development of the tool. ## TL;DR 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. ## What is gonka-nop 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. - 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 ## The deployment problem 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. ## Proposal 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. ## Grant terms 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: - https://vote.gonka.vip/tenders/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde - https://gonkavote.com/proposals/6 ## Why this matters for the network 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. ## INC4 - Website: https://inc4.net - GitHub: https://github.com/inc4 --- ## #53 – INC4 | Gonka NOP - grant for the node deployment tool # #53 – INC4 | Gonka NOP - grant for the node deployment tool 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`](https://gonka.gg/address/gonka12ss9dh7fj3xxmk23s8aje4hrpqq669u20v3ja6){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/discussions/1192](https://github.com/gonka-ai/gonka/discussions/1192) **Failed reason:** proposal did not get enough votes to pass $50,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/53){:target="_blank"} # Gonka NOP: grant for the node deployment tool 50,000 USDT from the CommunityPool to INC4 Full proposal: ## What it is 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. ## What the grant covers 1. Work already delivered - INC4 took on the initial development as a contribution to the network. 2. Support for NOP users - help, fixes, updates with every network release. 3. Continued development - expanding functionality, supporting more deployment scenarios, lowering the entry barrier further, etc. ## Why this matters for the network 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. ## Terms - Single payment, no vesting or tranches - Work is open on GitHub: code, releases, issues - this is the report to the DAO ## Links Repository on GitHub: Documentation: Live walkthrough on YouTube (by Gonka.Top@Mitch): --- ## Final Tally Yes 139,052 (46.8%) No 0 (0.0%) Veto 158,195 (53.2%) Abstain 0 (0.0%) Total 297,247 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "50000000000", "recipient": "gonka14fxt7xlj74h54u5lz8epz0qeuhpka6xjhzsyq3" } }, "funds": [] } ] ``` --- ## Upgrade Proposal: v0.2.13 # Upgrade Proposal: v0.2.13 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. ## Upgrade Plan 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. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain. ## Migration The on-chain migration logic is defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.13/inference-chain/app/upgrades/v0_2_13/upgrades.go). Migrations: - Sets `DevshardEscrowParams.MaxEscrowsPerEpoch` to `500_000`. - Sets `DevshardEscrowParams.MaxNonce` to `1_000_000`. The previous settlement path used a hardcoded `20_000` nonce limit. - Adds addresses of several early miners and known brokers to `DevshardEscrowParams.AllowedCreatorAddresses`. - Sets `GenesisOnlyParams.GenesisGuardianMultiplier` to `0.33334`, reducing genesis guardian power from about 34% to about 25% of adjusted voting power while early-network protection applies. - Sets the chain-wide governance quorum to `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`). - Backfills `EpochGroupData.ConfirmationWeightScales` for the current epoch and clamps existing confirmation weights down to the new expected value. - Backfills `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. - Disables confirmation PoC triggers for the rest of the upgrade epoch via a grace-epoch `UpgradeProtectionWindow` of 10000 blocks. The new snapshot logic starts from the next epoch. - Adds MiniMax-M2.7 (`MiniMaxAI/MiniMax-M2.7`) as a governance model and PoC model config with `PenaltyStartEpoch = 278` (bootstrap activation epoch). - Updates `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: - Kimi (`moonshotai/Kimi-K2.6`): `0.78` - MiniMax (`MiniMaxAI/MiniMax-M2.7`): `0.3024` - Updates `Model.ValidationThreshold` from cross-version vLLM results: - Qwen (`Qwen/Qwen3-235B-A22B-Instruct-2507-FP8`): `0.940` - Kimi (`moonshotai/Kimi-K2.6`): `0.900` - MiniMax (`MiniMaxAI/MiniMax-M2.7`): `0.922` - Adds `--enable-auto-tool-choice` to Kimi `ModelArgs` if missing. ## Changes ### inference-chain - Confirmation PoC used different model sets for measured weight, preserved weight, and reward rescaling. During new-model bootstrap, this could reduce confirmation weight for honest miners serving both an eligible model and a not-yet-eligible model. v0.2.13 stores one epoch snapshot of confirmable models and weight-scale factors, then uses it for confirmation and reward calculations. - `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. - Devshard settlement now reads the nonce limit from `DevshardEscrowParams.MaxNonce` instead of a hardcoded constant. - The upgrade adds addresses of several early miners and known brokers to the devshard creator allowlist without removing existing allowed creator addresses. - Genesis guardians held about 34% of adjusted voting power, which made quorum hard to reach when they did not vote. The upgrade reduces guardian power to about 25% via `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`). - Adds `MsgSetDevshardRequestsEnabled`, a guardian-signed transaction for emergency disabling and re-enabling devshard inference requests. ### decentralized-api - Some OpenAI-compatible upstreams return numeric `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. - The internal devshard service inside dapi uses the same devshard storage changes listed below, including pruning and Postgres support. ### devshard - Devshard storage could grow forever because old escrow data stayed in one SQLite store. Storage is now epoch-scoped and prunes old epochs in the background, keeping the latest 3 epochs. - Devshard can use Postgres as the primary store for larger deployments, with SQLite kept as a local fallback. - Postgres data is partitioned by `epoch_id` for sessions, diffs, and signatures, so pruning can drop old epoch data cleanly. --- ## #54 – Upgrade Proposal: v0.2.13 # #54 – Upgrade Proposal: v0.2.13 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/3f0c34f77c9b8f8c32ca5303ef3ffad23d66d5ea/proposals/governance-artifacts/update-v0.2.13/README.md](https://github.com/gonka-ai/gonka/blob/3f0c34f77c9b8f8c32ca5303ef3ffad23d66d5ea/proposals/governance-artifacts/update-v0.2.13/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/54){:target="_blank"} Upgrade Proposal: v0.2.13 --- ## Final Tally Yes 228,216 (62.8%) No 0 (0.0%) Veto 0 (0.0%) Abstain 135,071 (37.2%) Total 363,287 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.13", "time": "0001-01-01T00:00:00Z", "height": "4267300", "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 }", "upgraded_client_state": null } } ] ``` --- ## 2026-Q1 Proposals # 2026-Q1 Proposals Passed Rejected Voting With Funding ## 2026-Q1 Summary 17Total Proposals 10Passed (59%) 7Rejected (41%) Software Upgrade6 Governance Parameters5 Funding / Grants4 Other2 3,600 GNK · Community Pool · 54,844 GNK · Gov Module 2026-Q1 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%) ← Back to all proposals --- ## #18 – Test # #18 – Test 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`](https://gonka.gg/address/gonka15vunu0new53m83ccvfcmkf84v7q4s8ldsjfu4y){:target="_blank"} **Metadata:** `e30=` **Failed reason:** proposal did not get enough votes to pass [View on gonka.gg](https://gonka.gg/network/proposals/18){:target="_blank"} Test proposal --- ## Final Tally Yes 4,237 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 4,237 votes ## Messages | # | Type | | :- | :--- | Contract Details ```json [] ``` --- ## Upgrade Proposal: v0.2.8 # Upgrade Proposal: v0.2.8 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. ## Upgrade Plan 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`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.8/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. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. Once the PR is approved by a majority, a `v0.2.8` 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 hosts. ## Testing 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. ## Migration The on-chain migration logic is defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.8/inference-chain/app/upgrades/v0_2_8/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. ## PoC V2 Migration 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. ## Changes ### [PR #505](https://github.com/gonka-ai/gonka/pull/505) Security Fixes for v0.2.7 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 ### [PR #609](https://github.com/gonka-ai/gonka/pull/609) BLS optimized * Significantly optimizes BLS signature verification (from ~2s down to <10ms) by using the `blst` library and precomputing slot public keys. ### [PR #540](https://github.com/gonka-ai/gonka/pull/540) Remove ALL panic and Must from chain code * Removes `panic` and `Must` calls from chain code to prevent consensus failures. * Implements linting (`forbidigo`) and CI checks to enforce this rule. ### [PR #534](https://github.com/gonka-ai/gonka/pull/534) Security: prevent SSRF via executor redirect * Prevents SSRF attacks where a malicious executor redirects Transfer Agent requests to internal services (e.g., admin API). * Implements a custom HTTP client that disables following redirects. * **Thanks to:** @x0152 ### [PR #544](https://github.com/gonka-ai/gonka/pull/544) Inference: defense-in-depth against int overflow * Fixes integer overflow vulnerabilities in escrow and cost calculations using checked arithmetic. * Adds hard caps for token counts and improves error handling to fail closed on overflows. * **Thanks to:** @ouicate ### [PR #506](https://github.com/gonka-ai/gonka/pull/506) Standardize floating point math * Replaces dangerous floating-point math with `shopspring/decimal` for deterministic calculations (e.g., Dynamic Pricing). * Updates reward exponent calculation to use a table-based approach for decay rates. ### [PR #536](https://github.com/gonka-ai/gonka/pull/536) Perf: optimize participants endpoint with single balance query * Optimizes the `/v1/participants` endpoint by replacing N gRPC calls with a single blockchain query. * Achieves ~500x speedup for large sets of participants. * **Thanks to:** @x0152 ### [PR #553](https://github.com/gonka-ai/gonka/pull/553) Membership for correct epoch for Validation requests * Ensures validation rights are checked against the active participants of the target epoch, not the current one. * Fixes logic for sharing work coins and refunds during validation/invalidation. ### [PR #607](https://github.com/gonka-ai/gonka/pull/607) Fix(inference): update totalDistributed after debt deduction * Fixes a bug where `totalDistributed` was not updated after deducting debt, causing tokens to be lost instead of returned to governance. * **Thanks to:** @0xMayoor ### [PR #549](https://github.com/gonka-ai/gonka/pull/549) Disable future timestamp check for EA * Temporarily disables the future timestamp check in the External Adapter (EA) to prevent rejecting requests when the EA is behind the chain during high load. ### [PR #550](https://github.com/gonka-ai/gonka/pull/550) Negative coin balance for settle * Handles edge cases with negative coin balances by subtracting the negative amount from rewards instead of erroring. ### [PR #541](https://github.com/gonka-ai/gonka/pull/541) PoC validation, retry getting nodes * Adds retry logic for retrieving nodes during Proof of Compute (PoC) validation to improve robustness. ### [PR #551](https://github.com/gonka-ai/gonka/pull/551) Fix(bls): reject duplicate slot indices in partial signatures * Rejects partial signatures with duplicate slot indices to prevent verification failures during aggregation. * **Thanks to:** @0xMayoor ### [PR #563](https://github.com/gonka-ai/gonka/pull/563) Fix(inference): variable shadowing in direct payment path * Fixes a variable shadowing bug that caused errors (like `SendCoins` failures) to be swallowed during refunds. * **Thanks to:** @0xMayoor ### [PR #559](https://github.com/gonka-ai/gonka/pull/559) Burn extra pool coins, fix ValueDecimal validation * Burns coins from an inadvertently created account. * Fixes validation for `ValueDecimal` to correctly handle `nil` values. ### [PR #616](https://github.com/gonka-ai/gonka/pull/616) Integration test database, debugging assistance * Adds functionality to upload integration test results to BigQuery. * Includes fuzz testing and improved debugging logs. ### [PR #547](https://github.com/gonka-ai/gonka/pull/547) Updated script snippets and MacOS Tahoe 26.1 Docker settings * Updates documentation and adds Docker settings for running testermint locally on MacOS Tahoe. ### [PR #618](https://github.com/gonka-ai/gonka/pull/618) PoC v2 & Offchain PoC data * Integrates PoC directly into vLLM, enabling immediate switch from inference to PoC without offloading the model or loading a separate PoC model. * Migrates artifact storage off-chain using MMR (Merkle Mountain Range) commitments - only `root_hash` and `count` are recorded on-chain. * Adds statistical test-based validation with L2-distance mismatch rule and calibrated thresholds. * New chain messages: `SubmitPocValidationsV2`, `PoCV2StoreCommit`, `MLNodeWeightDistribution`. * Includes dual-mode migration strategy: V1 for regular PoC, V2 tracking for Confirmation PoC during rollout. --- ## #25 – Upgrade Proposal: v0.2.8 # #25 – Upgrade Proposal: v0.2.8 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/9241d81b9ed7f33f6864476c2b07c9e833037735/proposals/governance-artifacts/update-v0.2.8/README.md](https://github.com/gonka-ai/gonka/blob/9241d81b9ed7f33f6864476c2b07c9e833037735/proposals/governance-artifacts/update-v0.2.8/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/25){:target="_blank"} Upgrade Proposal: v0.2.8 --- ## Final Tally Yes 4,153,562 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 4,153,562 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.8", "time": "0001-01-01T00:00:00Z", "height": "2387000", "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 }", "upgraded_client_state": null } } ] ``` --- ## #20 – Enable Whitelist # #20 – Enable Whitelist 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/20){:target="_blank"} --- ## Final Tally 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 ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgAddParticipantsToAllowList` | | 2 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgAddParticipantsToAllowList", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "addresses": [ "gonka10000627dkz6nvmf09ctqy073v0fls696uznwgg", "gonka100009u7hegukxy5ne3w6ycfleaj7uuvh2juxqd", "gonka10000uv63da0ee5drk26erkwrvcmpmj7kg6kw48", "gonka10003spukrualhl3h80k9x5m9vrmvlmp8kf4t4w", "gonka10006x5p5z8zukfye552fd58qqj2qth69kv5kmn", "gonka100070ewvrcraax995yd78cm0nraryzp4hal3hk", "gonka10008pmwrke48xh42dhe0ul0mm0mhhvz6ta9srs", "gonka100092zwvcksslturgx39lzwy6ztjxuttt3spej", "gonka1000937gjpju4udj2wlj3yld0lcw024tp0ztqew", "gonka10009skl232h4c94st5ar3j3c2e34cfk2cpgrj0", "gonka1000hqfkcp3cs0fq4r78vvpkjlv5n4x4sdgcv7v", "gonka1000rv0ddp9yk6djr4y29mt0gu3m4p8mg4kmjcv", "gonka1000sng4u5jm7jdjnwxvq6uwmw067mvcurd9205", "gonka1000xjetteyu7gy726vnhdxq69y3meq04gvnk4d", "gonka1000xmydnfvphwy4n5yww4ex6nwk9mqslf2gnhs", "gonka1000y038g5sqz6ewnq6f6ktl3xx07fmezc3zrng", "gonka1000zfcrzdjwwucvs9k2wuy4j5ecj69q5f4v57h", "gonka1002c4q4xly43ykn9am73p40xgfl6l3vs66f7de", "gonka100k8hr43z5vp0fnyc94m7lum6mj4st6vksxz8s", "gonka100mrlhdj7rvj9dxskmtkerhcrmpjq7lx95z8hy", "gonka102zvy0egvt7kfhj46gpzg09sdqu6lzfczalt6p", "gonka104z9al2taf6gspj2qlsqtjwpxt7ypmpn5z0nxa", "gonka105ce4495mj0mwkxqeasgdzqfq5jjrfq32eza5l", "gonka1060g3x0qxkarfvupav5srccyuht95swyl0kpzc", "gonka106wrpdwkuudnxdm0lwzw2zharr8tfx7ug07p9f", "gonka107swr6xrllv06a6t8e7yewdjc6sgrf8uyhamgn", "gonka109g8dnt43nj45xhg83jyjt5f2ywz336w36qzyl", "gonka109xyam3aq9xt6tjgkgtwwahky7hfd84nl8tvup", "gonka10awwdfkwvp70wpkkda2nlhe90q6tjus6awme38", "gonka10az8z6jv7lkywkjeajah2sdd9c0ysdm3rc09j0", "gonka10cgs0yszeu9r9yh8q3a4xqumr2xrllpnzw04v0", "gonka10chphxxphg5pwj2zmu6uue89zlsk22wnqa9utt", "gonka10cllk38hyhjgz96dv2x586wd4thntwx8n7yw54", "gonka10dn20l38dxx4a7rfnd9qwdass86j27c79w3tm7", "gonka10dqhrlqs3e3zp0tjfgqg055z9vadkyku56sxze", "gonka10ejjacwvwma37rn8wrf3je7gt8u7lulu7vh8ly", "gonka10ekkjpyfad6265m2502d4tp3n8yp9n0d7rlzk4", "gonka10etnufq85u67k075yuxq6h3rzwlcln5rffhlyx", "gonka10ftkd2zat7h8vlx59vwmfv8qe07qzg8cuf5fd6", "gonka10fvaz7sgva6563fkcp9wxlk5hz7gj8fmu0w699", "gonka10gj5lnsxalcwzeve04k2pdzhx2nrlqp4hkrevd", "gonka10h37w4zmxw2talt77lkr067hvy3fgdfy43gd0e", "gonka10hd93y4ja2nypv6e448q0f8wtqn39napkxhxtw", "gonka10he6c5p4hzehewj4eftusd7xw2ngakl7lnv3at", "gonka10jrlgh9yege62d3wnytkgamdgjyqs9xpjxm32n", "gonka10kmsyy00yxnky2xfqy9wce0l7uaadq4jjp3ykg", "gonka10l4faswz4hqytwmndgjf0wag7c0wzspz2v05zn", "gonka10lz43ane7tkgqaypqxzsszpul9llvuc9p9yvt2", "gonka10m9xmpvlev54nkq45vmu8ycv6g2gyhehruuun6", "gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09", "gonka10nqlxm9jn7hswf4h8amytr6l9dgfjrz4yslhdw", "gonka10p49jx70haq9uhjy94y80zkfv3xk5pafk5wc5q", "gonka10pe4w7wyts6y3mfvulx6qpg2xrd45qjxr6lwx3", "gonka10pqlmde25yv6200ylh77p0xhydvn99eswyr4kf", "gonka10prje5tj49lek50dpch085f66crl62sut2n0vw", "gonka10qdn59cwvwt75axra2yaskmde5k8cxpxjj6pml", "gonka10qpuqx5xcp4l4yjfh49gdcedgjsh3eazjm470v", "gonka10qwy9tu8qhg8xpfp3pzalrk7x2zp4vctr6gm3w", "gonka10r5p7vd7sw6tthp0nuld8yajvpgufamrd63epk", "gonka10r7l6unulyg0wtk8kl980k7fpvjskxuxdtnt7t", "gonka10rkd4kvhuy3z7c09wprklc0yjn045xjqcz5ph2", "gonka10rvvl89yply8d5rks5k0674fadat45e3gvtau5", "gonka10rzq9m43l6dl2zz9c60man27gnqmw3q84rfahq", "gonka10s6jn354l57xjlgpdskrpk8s82rleth22tpyhf", "gonka10stfkwuxzkalnjc4xnrjgqn3xp8hpkqakyaqg4", "gonka10sy48qz62el4y2srve5hhydgvump8whmn2aqzy", "gonka10ujznhjy9m2chl05dvjhvf525202yz8hwkzsqu", "gonka10usl446vaa6t2chrmw9zrkztpc45zqupcelxw0", "gonka10vh6xfdrksy7npapnhs6pnwmd3ldpxgl8n2gdd", "gonka10vljxvwy6n9hh263chkt0hj0kg7t0qmdwfrurs", "gonka10wcfjy6p7r8k337wd85k0dqw5jg0zdaunf909w", "gonka10wjkjleq8q5gp5u8t0qsmz6mfvdk80tzm26h8d", "gonka10xfyg4v6wwvfzgf7h5fkkkt70xl2e8uy2z8ey2", "gonka10xrtfzs46mmjs8dy48auh2xfxq07dxs0mhdcmp", "gonka10zrtrt8gu4z38evcxdl8jqdxrdnkl2rx0jq6za", "gonka1227320u62rpdyw8j0ve62yv6yqzy0h67u44sqr", "gonka122dtadquy0ayf6nzx7thg6643w7cv0fcnqssq6", "gonka122yzg0agje5a4nq8spx2fwe2cye79x7hz3shgl", "gonka124hmlh3500ysl26n25nlfsgnj0hxuvy9cwcrql", "gonka125cxtlla2yvvyv02k7rfzn2z9j0geg853xwvvk", "gonka125t846zduxfneg9yac5wndm93skz35n36cvdmm", "gonka12634qjw29fmhf3yw7rlcgf8mldl56r2ufqk8rc", "gonka1270mrwh27pgnrtmmsmyy5rsq2h8ug6l4zvg4cu", "gonka127fgxedhqq63mdxlns9djfrhq4vcqm60pwpj38", "gonka127vlq8ayd4jfnrpcfzhqdl9z6npqf3l6zyucve", "gonka127xejprdqv8n06e8k5sa5fvsuxj4wwx2r4pqsk", "gonka128ms7uc9shq5kskszpm0qgp09mnvnqjyg6dxk9", "gonka128xkg6fp2x4806gv7eq84mlffau07rscll2pzg", "gonka129wh6ap5m5v0skcxvdcgn5nrfa8d0v5jwfz83p", "gonka12c27qus5pw87x4ayaulmcp34q5pkeseettw3nr", "gonka12chgl62wfzvkvjwj7mz568ct7xyzdaa0ld4d8c", "gonka12cmcsytuv0v0ycfkda3qv3qeap9f2t32eez3au", "gonka12df4fprrjpx5ldr85cvwq7mm8m4je945hk3nxf", "gonka12dm36k4rm5cqrhzkusdvd9ehcxdcxq5e8tg778", "gonka12favtgswt6sw2wx8ywf6fz5jz6dl09ga3s2tpu", "gonka12fnudtsmw6heu6t982rnk8c5lgpgz4wmvwd75s", "gonka12gjgr8z4fnp8085sk4yk37hxeyvmnz8vzr68l8", "gonka12gmwdxjwyqs8y2cxjzrnza8jtf2pyp34udp893", "gonka12gwxa8vcvahyd4ygcxp4624ywaw98wp953wuva", "gonka12h7trxvn79f5tzhyx6rjvsxl5s5vvc6vkuxhff", "gonka12ha2hfpkjqcs5qgkfl5symtuws9k5rcx0qeuea", "gonka12hzd9zlz3tgslky477d4wa0jlwacv4nj9vxlmj", "gonka12knaleggn7983e543h9tpvlja4ug8uue4kzv33", "gonka12mqkaycdsc7qr37ey5rqw6vhjvkk7waxdc7rjh", "gonka12mxf4q5puj8axckumreaaesyuup96h5fmk7t8n", "gonka12n7ekj4sg7xd63qe772qpeae59v4zw76t0xpd5", "gonka12nezxpl3fa7svx6qer2mm9wjatv9apewlnfcy9", "gonka12nhgx6fyuzwpx8l7j2x5mey30kypeeyqwplw24", "gonka12p5ausvgfg5m9d8t47pvm4j7wd0vzfflv7s88n", "gonka12pwvrkm7vqkme62y0u6pgms79w8eqyt57s2vcx", "gonka12rncugjwhws83nxa56lfqkwlvespxsvt3rmv9z", "gonka12rsuc4h9s3nm45gk6rpxzc20w3zwrcg30f05dr", "gonka12s6zccy883qt5kh0mfclfkwh7crqhcc7j9rhgt", "gonka12sw2dy5m9zmqzq3a7zfxhca5tqs8rr2502meym", "gonka12t2jkef3wfwlyk3z0zpsqu7ydjqa69g4lhmh6w", "gonka12u0uyuexgd37yexwxgwljzstgunaurswguehkx", "gonka12u5pjkvehkhzky5s0yn3j0teseqa2wk3m26aq5", "gonka12ucux8mskk0q28tf5setdhe3krtcv0z5kaqg2n", "gonka12ugjh4gt4zlaa8mevs9zy9a33e54des09rtcdl", "gonka12uljlkmp5dhhktyqzt6yfczvp77d7u9tzv64h3", "gonka12uttst9yzdrfjqhjanvnlydq0dms2ktaljqaq8", "gonka12yqmpf64phckq5e824u642k0ra7khmzjw97uln", "gonka130cls75rtr33ewjnhlrarzxqeqfet4kan043hz", "gonka130e2cpzwjn8s2hlamk5nzw8kflwjzjx9hy79wl", "gonka1338kw8rwv6qlujzrgfacce3ej6emekzjwudrge", "gonka133hhcavuqzavltuwnm0pdf2c4dr7ds4nz6lzjz", "gonka134n7pr3tty8kjn4d55uaja00qs4s4wjqjw9xn8", "gonka1352259h74sya49pux36nmarl9ukwnlmnk6tnwj", "gonka135jr9e2gyzq5lfqvc9tq8n0k3c398dgmmwy835", "gonka135nsexwmvpz9h0updyhsx7ccch52gqmcvn6hzq", "gonka1362yedf9k0xpce8y30xg4g4e2mmgvstaf856qd", "gonka136z8kvkj4vxgw70vgzmkdxfvk605zmtkdsc7r5", "gonka1375jlpwvdm9vg4feas4w5ywm8v8dkyh0vnfqft", "gonka137kvnsjwkz6aqdlsfz5nkuh04wamt7gydgm570", "gonka138dpk7h8d3u8324x9yzcx20x05wlas6h0ette3", "gonka138lf7hkwehhf6e4t063lg2wejn4969jv953h29", "gonka139qugrjwz49z4qqjxxdszspd6f5dyhur5sazz0", "gonka13a4v8gxxjav5t4xq5y9cv9d8rfnvkjfw5adqz3", "gonka13c06ej90ce6x65ey3zf42qd4d0zhhcsgsatw98", "gonka13crxlqch46e2jdm6uq03g8wsxndqkpdgay6j3u", "gonka13dv9pz037mzr7grelf7035nnanwfazzwydkye6", "gonka13e90ku29c6k7hyf5c5h220grxmfqygr80wq86d", "gonka13fdngdaqyy850fnuxzv3lq3dq9jupcxkgcc9vc", "gonka13ffdnm87gn48le8qmers2p7md5jx4xegpkupxu", "gonka13fpvt243g8sh87ere5avz74qx5qj7vzesr0p4j", "gonka13hqh2wcv3jaeqq5yfxqq5fce66tp2vyeu582jc", "gonka13jw6k5lleqepjyjsm8r4lhrfnn955h8wrexdz2", "gonka13jwpl2lm2h7z6kwyefqdjdflt7cdlm8phl598m", "gonka13lduw4kdvyyf05psepnncm306k4wuyfwcg7y78", "gonka13mwall70xn50pd79lndtsn33xuh7mrpw2eq56q", "gonka13pacjyw9quwfvzllp2h7u27h6f5khqlftw3jmk", "gonka13pruhnupyrvvu83xhprx8j5t2xujxyt7tsgr36", "gonka13q4z3dyww6ttmw23dku08ywc6xsh26hzxru292", "gonka13qk3jur62xvma480z767lc0ks8c8esc28nxmvt", "gonka13r4nepsx5dy057fw4anedrzk0j0nn4l0l4uqyr", "gonka13t5ltq70zl5z5649gayvw3dcpj78pl4hyd4pv8", "gonka13uuqfsenjazwu6am5fctzscar364s240zek5st", "gonka13uwt8t3sp5ycp8lefzgm942uxfvu4svv50cl5p", "gonka13v746mx4nx0thn2vw7am79q8p3wn6p9lauvm4h", "gonka13vpvregum5amwn0s0qyfac0cdngxc2cq3cp67n", "gonka13vyq4vkp5u24lyswy95ffz5e9zpxerc6gsuy9c", "gonka13x3udp8tx4yejz269h87sq27jn8jm6m5uzh5vx", "gonka13xpjvala86d3y6jdjpnfk56ptjawq29t4gprtx", "gonka13ykzwj2f5zzngs7jl7ywczgestspevqh2vagsj", "gonka13z4ml6nqpapjhgkr95myty9ah2hu2myk50t503", "gonka1404cgu64cj84j9jupmkpepfgwztdnl6526vk3r", "gonka14354l3sqgrc9vhrh5cq6dqgyff62zsj68a5yez", "gonka143n3ql46aj0vnsgxt7n0kps4znqrps3a78jxzy", "gonka144vvgtrfvc2eyy4wfau52ptgy838d2pln9sj9z", "gonka144yh00dcckkpfwr5mv9yz2cpa68c8sw0h3c6cy", "gonka1450wvd5uugfj7gru4heut5ulnneunplvxs995e", "gonka147uwtqfs5ddkc6flx6jeqvfnfsg3n5rzzcnhux", "gonka148eld5kxu6k867pz6yxmwps0kpy7rdxg2x2xau", "gonka148huvv3fn3kxup6xwdsgfldu8t3g2wxxkjlgex", "gonka148s6qhahux0xewgz598kfwes98nkuhrv5fv20n", "gonka1495sh4hvvxxke5z59dg3rvz3a2r55358kjlqlr", "gonka14a0856a3q78pmesxpc946xm9nsj3f275l9f5pa", "gonka14a6s6979y4ddamfj2weu3fyur8qjeutzx7ka3z", "gonka14c0vannxsak0qq4lpmr5qkn40gcfmcvnyu4z2r", "gonka14c4hk9zcaexda5ecgzhlhp9lpzgy00dnn6ucmj", "gonka14cfcjj5djk4k38zghtmxktqutu00yc7uh6wvg3", "gonka14cqs3cnsahrr52end3twr7sq3rhtwnj8j8pyzv", "gonka14cu38xpsd8pz5zdkkzwf0jwtpc0vv309ake364", "gonka14d939yheufy96w9wjyp5a36qyzg333v0nja4gj", "gonka14dkhe6rhy2nq6snmkp2ssnaesumsuwctlmrzcn", "gonka14eskdwdmwkvewjela8fgu2l0k22q0xqqad4a39", "gonka14fn68sulr6v6l78kvur9u6yw5lwurtqcrqkh93", "gonka14hruf6ljltha9yklfgpd0s8jleyc3wdraatfre", "gonka14jgzwyjzzauwnnky3694jlgsfkdp4lk6yn8zxk", "gonka14jxtac6gra9cc97q7gw6el2l7f2v2d32f8973x", "gonka14kdusfrenfkktv4300pykwwzqxeuf40xh33rpq", "gonka14law208gj4hgpr04y2udwlkkxh3k9mv07evgh4", "gonka14lgvmj4amze4mgjzcaydvmu72jgk9gefz3073l", "gonka14lmda3tmfl6p4f7umusld8rhgq8rjz2tcswhmr", "gonka14lr40jgsgmgf60tcvdsqkq6240gvttenpwpmf0", "gonka14lwepzn9qq5dg3pp8er2km0w68g6geex8dspx5", "gonka14m882prhw4aqr557swzg5gew2gy4ctky0gft98", "gonka14m8tpzysrtjyew3s42mxq9u6gxz3pfacafq28k", "gonka14mcmmjm9nq5d9jmds3m5ypjjzzgcevw62dsknp", "gonka14mdlu97z2vz4gflvcnegj5as0escdp6vrhgauz", "gonka14mmw8h9cy9sjpn3qfl7d78s3x9atru52pucc67", "gonka14mn57n7sq2mcf5mm2399fmqrgujwgxlec970ar", "gonka14n4p8wfa03rhmy4agc560k4a3zafavakl28mpk", "gonka14ntugumwzhdlkc66qlzczdmfa02fcm4pcldtwz", "gonka14nurupejmd8vgu806jx4qpf6jfs55mrlc6umem", "gonka14nyfdumjvclvd5y0q8yckfa09ncatcrfhnnx87", "gonka14p0njxtlnx2c8zn570nvvaf730gnnkwvetlwj8", "gonka14pdvgt025fwkf38cr74hhcj2nfl98c044tswya", "gonka14q3s4vmmlukl936q7e4asuwjnakv7u59hsvuwm", "gonka14qwpw2l0qmevxy9snllfaw0r9svnh4vdyl3897", "gonka14r6ypa2jngcd8pwt22f2nwdhlt2s3cxr4k9xne", "gonka14rrnu8m687kr8pz6yjekmsl2ym0hk3z9npulhz", "gonka14rv62lyedvmmghs78qc4yymdtas6rdz3wjupty", "gonka14s76f83l8m3guvr8vu54dmla798jzy3u09vxzx", "gonka14sdawlkm5wxmn9wkjxkvxnqqh8s9rj3qwh8anz", "gonka14sk8te3wu4zh9dal9yd9tm3pd2qerdru4aqm05", "gonka14t2pv3mws7mgx7tq6renr4etwylgqy5v6gsde3", "gonka14t5y6yqckvxv2gfd82usd20mh79jg3decl2fcc", "gonka14tqh62mangwzrma2lgg2dm375rcjzn2ydy8ttm", "gonka14trttth9yraycnhhmtz2anjctnu547pd8wm9pj", "gonka14txjznwtjcad86wr8z7hg45c53qfh5yqg2qeas", "gonka14ued4vcdeluj9v9vmsmteap7vtg7t50640hvmf", "gonka14ukr55pmpak2aetnrlvrvjg5jv0wmchnac82kq", "gonka14v584a3c4zva867gtz7euycg7dvmnrqhn6gkqd", "gonka14vyhz7henu2lxssa02lf3qwmufv8kvxzn85frf", "gonka14vypx85sx0qd4aajmzklhy6s0ygftf57zafd8a", "gonka14w5j25qvat9a0t4an364ngj5aanxhg6kpa4x7s", "gonka14wep5tkhkjsyz8chj8f5ht2ef07ewjl225d9rd", "gonka14yprk25twtverkpcsdgnrg5raeuycmkl5dwa34", "gonka14zzmvt5esggym639wk0v8s3gdgdmnjzrh6p7rv", "gonka150qqxu2zf0lzc3nngal79h0n5ls6lhszzraytv", "gonka1524ud0qz2j7fle8sgzjje3hjrgla2e5xx2qv3g", "gonka1538g26tlyue5fqzf3czr8u7jgp9p0alkf85qpn", "gonka1547gss5hs48tg024zg7cm3f4r747a8ed0mrgru", "gonka154hcsr6u9y9vq6rk48yml5sr8l09wtsv3m2zeg", "gonka154j3xc2ke2qutupgc97sydt3fwgl6mmkch2k59", "gonka155axgn044k2g4rfmmzr9e8v7qtffeks2gc8cms", "gonka155cnj622zfdl64f23ljmk2tzv7tewl6fp4m2hl", "gonka155g6nkjql5sgaz0j8ugr9ghc62heflj9g84mqz", "gonka155j4fnq22ues53dn3vsayep0esccrc45wpntgc", "gonka1568w7lv436sx68rllg9raf06ehxx7dmu8fe4uk", "gonka157gmpc2eghnlkj5cjw4w7sqgntyhkc0hrk4nxy", "gonka1584camcctmeuvd9gv0nklp2ann46s89rytymzn", "gonka158yftj0umuzztsk37v9ykf9m6kd27335lmrsgf", "gonka158zr8zw4rna9784gdyf2d04lcek3vnfpajly5p", "gonka159kqhlp3psj4r7r9646lhjpfz5apwmyen6y7m2", "gonka159xaydqhftfweml5cppf3s8r7rtynxt6fhy2xe", "gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4", "gonka15autzyv5vcfztjhfk0g73w2gyuejdwhd5m6z4h", "gonka15cfrdzvnupzg9yzasdd8wr5pfj6u9zc6vtz4t3", "gonka15ckw8wekv69j0mj50e738djj924qy247dlmxhd", "gonka15czyzyutwscapz8w0curdwguhytus8dafakqnn", "gonka15e2swr409v3c4ydpq9ahsn3zuqxyj47axn3lf0", "gonka15emcqmdxke9dxv7t3urvnrrt05jmha44n0n93u", "gonka15fpzwc7d2z3r4y5475p6k7uqknnkj38gsus3d9", "gonka15g3dyj00srh2mvsfaayfemtlgee733mteu0ahr", "gonka15g9vxflt3q92w07kcw099zjtc3lft9vwtr254x", "gonka15gxk20xupc5w30crs4w7a70ekdp6yyc23qa4yd", "gonka15hc8eqp4axp7lztjuk0y5z0af6drw5k0eltrue", "gonka15j9dqqmx8y65cvyqug2agywrh9g3684qsltsma", "gonka15jmygcgehvxl7mqe7n9rql8drf893296382yxg", "gonka15jr8vzfwpwx64cdtr7dat0m66uzgmcfcedmqv5", "gonka15kf06ehfplnqtvgnndyfym9w9f63686cvw3nqj", "gonka15llevgky75a7jknr5m0kzme669xuwrqdxex5f3", "gonka15lxz9w7m77dr04dxv7smxmc4xl2vr4klu2gclf", "gonka15mh2v944wxk3phxfkegglpgfpq9mjcm6vmpyng", "gonka15mjrd9t4uxff98z399e00yr4l2vt8va25zka7r", "gonka15n6a5gxxt6tr55qj5jj24swzjvw559p4ln2s7f", "gonka15nafqu6uglskzqkfgvh0mue7gats9dded3nctk", "gonka15natyl5kwtzta9lr0xeqmew3j5thza2lslvw4x", "gonka15nkz4dxslphkty92y0c8m9umule32g9n5e5wvm", "gonka15st9yldmsajhvw0vqase6csljm0lg6meyu575c", "gonka15sut7vetqhjuaphh7ssspdnng4ztlpy8p5d2jq", "gonka15tkxfpguhgejwvh52nk2tqdm5ssedgfkxm49rp", "gonka15utn3mfqktfz9qp8c7h98e2z5utrkgja6yqljr", "gonka15vunu0new53m83ccvfcmkf84v7q4s8ldsjfu4y", "gonka15wdjxzgy0pzu8wxa9dck7f7cwjuwjt29uqq26t", "gonka15wnwyyj9pntl8hnte83kq3s9eaffayf2ln9t04", "gonka15x0egllrr3wlucagztrpf7u8365zdjjy3qh8aa", "gonka15xm7znu7k6m04tzlvsqdj0p4rzs7rqdmj9kk53", "gonka15xr92pc7v0jvq5aqwqt43hpvvpvs3q5229lrmh", "gonka15ye48c3rp57hwt9t6tzc6h0t5sh88zvj0yznwn", "gonka15z0gkfpf69u7rvqng8ueqhh9dhx870smxwvuyc", "gonka15z2fxrrxx7cwk4j7vp98rat7ajfpjxrqevyp0s", "gonka15zjdjecv0vvwwj54pfq6cdwemsdnvksnewmu6d", "gonka15zqen8wckv5yd57ykdgl77a9lvk04wtcz7lam6", "gonka160gnz0he79feg3sk33u47elyek7xh7aa99pay6", "gonka160q92s7d63d3gtcx5lmdxu92uf8fjqut0v622k", "gonka16324l7r5jllqjm7e5wlf2h44cr3dsmjj8a6py7", "gonka1648ye07w74mcswjqh3d8v66w64tygku2aqnmex", "gonka164gj2cnugxrrr2x09rn20p6mkxm4tyc8q8d7gd", "gonka1662dun8ufuvjfa652th9farq6devh57p0v4r3y", "gonka1679j5jww67exhkzdvsdw0n7ak7ukyszhy0mny6", "gonka167m8t885t8j4wr8qmh652x9d2jvhtdk4f367fd", "gonka168yvlgt9jg86frg2z90cc8w4pz9hnd7f8lshux", "gonka169ea3dxnzgug0a3gdhk53q5s7fqvwsajzlvg7u", "gonka16a89kpc76p0m26zv4rck5sm9kc7yl5d59ztjpr", "gonka16akhyrh9uyl64c4hwsr33t6tcrsg9vmsydwqd4", "gonka16anc7s5fsphftjqw2n4445lkcj60x40wddgjpw", "gonka16c4q44hlm8zkzhv420tf72zffctgzmgxpnpkg5", "gonka16c5qgjajmp80hgvy2ttwp82j7nr2q85zahr8jf", "gonka16crq00f4jhwvsz2m77mzldnp4uhjg0ltxzzmxv", "gonka16cstfwxnuv08zpyalmv38e48crhe8a9pft7etg", "gonka16d7eeauutuukquwqlj4kgunm67wm6nph9n4zxx", "gonka16daflx380whd3zlms32fgv48x4ll4dp5e50rj6", "gonka16dhzkyjqvqt2f6h9s9f0fx0dpqaukq5hu47uul", "gonka16elscdycasqnlycuj9thwylcwv9f0dl5geyqmt", "gonka16eyh3004s2kehwhnp2hwv0z6m7g5tz94dgc0eq", "gonka16f0cecptf3synlxdk9tyw3pkqwff4fvam3lss6", "gonka16g6lr5tzelh4m66gxf5hlvcjf0drcwnyse7yau", "gonka16gu0el3h5p572lswsmldyg358apqphcxsdfuq2", "gonka16hfzlft90x5mtfgryaml64xu6slms07p64td40", "gonka16hlgjjgnlfztydeyhc0ej5mu6fgac44xjft5q9", "gonka16hp3n0wedw9xzhqqpuea36pcwea96rz6lcnvyk", "gonka16hu6hqs4ks8rr8xyejksnm0lx7vt982dyn4ajj", "gonka16jrtxjqd8dznacsrtjpkf5mx0knja2xvwrgndp", "gonka16jvt3fhm33sm4l3y72rqs74w43lff7ugcdsm3m", "gonka16jw23vytrm9cw93s2aea6s4g6f2zkrg6dch6wm", "gonka16l058qgnqvvauh6f7lcmj7x87ceqcq3y7h557w", "gonka16lksjaqq2gqpeexvqg4xgux6hdtms3wnk4jjle", "gonka16llmzx924zgd7faurq9d7dqlkrduy2pk5lfyn3", "gonka16mcgy7edzv8vr95ldyr76sjxjjftk7es986nvd", "gonka16msrxqwfedlll09hdwv0zmma6wttxx0wqqlt0y", "gonka16n8lkh7qtyme055xjshfmlrvts8s5ujx396s0d", "gonka16p322ch887xjv67erm5dw0lgt4kqj9gz498pv7", "gonka16p9vx68hfr5vpy6s59rvrz85le5dq22uymukgv", "gonka16qpr6mr9w08wuarfycm9s68jfk3wuxs0efl6ng", "gonka16qz02dw2x6y4rfkedn8dvqp2n8ka6cmexqvm2l", "gonka16rtefgwd6qkz6760eyv53s8cuuu87vy0t7xakt", "gonka16s547tkt7r7fk3dvh736lcfw97wvgnpnjjefy4", "gonka16sfwtnse80aleg7sgmumnu3qxhtf93mf86479a", "gonka16spupg33ck73rk4d82h8fusxkh823r62dshg0p", "gonka16sthutkxgr88vlkgvqak2h7pdt76fcznfz6w43", "gonka16tlht0m9aanxklqddt3xlwwxr5axw9yydg52wu", "gonka16u0fznlfmuwamawnp50kk0kygw9k259mq9tu93", "gonka16uc05mvmja22zxgljh6fs82533w805h5ya3nzg", "gonka16v0ut8km4ccfzr2ste4zeegzpwrvx70z7kpzyn", "gonka16vz2gpallzd2e8gcv3834rr0x4xnqrp2cfresm", "gonka16wwlcqzng98g9ct3qdvu4pxy5xgqeyj4svp5g7", "gonka16y97d2mgtl2fl05jjux2ajxt32uf7q3sn8nntl", "gonka16zrwagk5neau324q48dqzy82z5nys9f6rcnsrh", "gonka1707yvgk9wgpzrp35wd84mcps4pujelx36n5du9", "gonka170rtkycpjpga8yj05wdf0f6thj4p6nwhccr8gp", "gonka170xdfaxm27yf46lgaah6k6t482gkcxwjmjn22u", "gonka172esz53695ykvv038y8mvdfc6mkk2q0dgfmjks", "gonka17339jstnve8h7mzms493x9twwznadymtvj7vjt", "gonka173knqc9ahr69n8sd0jupqryung25gdmxz6wnc8", "gonka174cacl7cjljnz8xywy9zcfcvj9a84gdn9yhcs3", "gonka174srhxhfktxx4hv94zcdz4jqfw9kvc4ge2p0pu", "gonka1756ph2flj5y6kw5xqktfgwj3s2ct54ddz0jj0e", "gonka175m43rc7dg6xarxksu9meg9l6fp3tg2ewte6kh", "gonka177farep9vx76e7nyxuhr6gfcl95jcz0y2ev9ny", "gonka178lh4vpc78xv0rl0cd7ks2c0w5uypdr4j268dh", "gonka178p3vw9zxs885l4a29g3sep0v9uplfq4pzvmrq", "gonka179aq77jrmqmtymq0sh0qt86hkdwqsnc9uxa9ff", "gonka179twja6r5x5vqj7agex89dealpnhlvrytxfwx6", "gonka17amsnz2csvjwt3rdezys6gj7wggexxwtwt03a9", "gonka17cnuuvplky4ck8hwj8smh6he6tgq6su45r5v5y", "gonka17eha2wcrge8zp36tn85ywgx7dqmwu6hux3wqpu", "gonka17exwulhw83ehh6lzkkj2nfdusjwlls2m3wsfdw", "gonka17ftklmd8esnj47nr7dg7c5c6wujvqxqjv03774", "gonka17gldla54cqe8tcrhw89vrlttm7n0aef9mj908g", "gonka17hjy6s7d8u3umauk69wmc7whpckttm2lhg23j7", "gonka17kv7akcuv5kqfjkgnhpr7akyy9ss5q3c8uw0jc", "gonka17mr6hc0nt0mf4ntyaldlnrq2wgvzj9709zwvuf", "gonka17mw34tnvce5jg8s2lrn07556guh7yj25dgm4pf", "gonka17myk5rgk3zrp75vztk4y7pnwzdt8jjz5nlz4rj", "gonka17n5aq50j0wldc2zq2k88gnle2afzpsw9d0mkh2", "gonka17nhy0gakmp3yhlrm5h9xghj5mgwgyxagr8zmm0", "gonka17pf6srgxeuqlhp9nqeway96rpzpvxcld9n7tjf", "gonka17qfgwe3zfe2jxa04hngnpc2duz4smnw486tszd", "gonka17rfqamx8vr4zpd6z0jnulre4acht2lj7tq205e", "gonka17rj9s4mvusl789h4km6hcazx79w9eg2xk7pva4", "gonka17ry2rgtktp9f6etejw4ls2dnagrctxqvlu7e9k", "gonka17ss43vkwh7x0a23cld333v8n33k7ut90j5c375", "gonka17sxv5v9x57xvwt37dtza28f7z658z42czqzvny", "gonka17t6ymyj3snmfyfdvqv984f69t9vgn69ptuuzg2", "gonka17t9elrdnnzqd5q2w240ue47tn253gjuhpkflwx", "gonka17u4k0dw7jjnagd4g4zl7r7j6rgq274amjq70tj", "gonka17u6cwzx6f9jkngqllyw4z7fylwyymgvgv6gkj8", "gonka17vllfmumam28sjwgaj4hdzsuemd82uzvxgemw4", "gonka17vlmumlt34gdv5phdgedjlkq3u4wynyapnwv8d", "gonka17w5kpa57jtqnqy7wdp5d03jkjmk0vjwdpp5xmg", "gonka17w8dqjk6qf8jraddt5j8spcrtvxjwnn82x5cev", "gonka17wmjdfda8tfkfujp24usqzsxv32vrycnhvj3cl", "gonka17wrwvhuhzzvmdjhxwd9xdgve89tvynvfl83gp7", "gonka17xv7c6ej25m9apcn9aave473xyz09j8lfyk76w", "gonka17z2dhez5j64tnpe3cddwp90j66vm5trjfuck2m", "gonka180h3x4dv834pyn2ua3k596hrsk7d2l5utljtg6", "gonka180j0t04yp55y4rjc2lvv0dmn3p36x62rkmqelu", "gonka182wjthlm5zdkwpcc3x5cfy83sel392ljwufsz7", "gonka183ve5urj0pw30rdq65w45h8vcl24wzuaqdqnnf", "gonka184jz8ja5gqkr3kt98a3a4syyypwj07j0qngukg", "gonka184k54ycpzw9jfsx95yucggq66resf60z4tfpz0", "gonka185kgdje9wjucxtkdu0nqhpqlwxutc5kc7nss8u", "gonka185qz338ahgj324udxakau55tk9frygxrs8zduz", "gonka188zesyhzwt6crz9dlcll2cs3wezput0kfren9t", "gonka189qh4gle43kmcp33l6378wkswk3ll6sa832tvt", "gonka18an976klvmrmkdc72e9vnyprg9zucpqghqg68p", "gonka18c99ap6aj8w9hqw6g4m3sj8zuyykv3hcn4tn8l", "gonka18cd8qdrtdgam6q8udqsarstnsq8ze4ll5xangz", "gonka18ee58ff309k3fv2dn9f8zfa9q94huk4ue9y7t4", "gonka18emzcnep4wf2kar3zy54cwl7j2j9g857q9q9qw", "gonka18fgyw8c7deqkk4zq8n9efgrwjjypdrd7cskv48", "gonka18frq9ltz0m7u7aw7fkmwhqh89ut3w2e434nxjx", "gonka18gm3udhlraw29z4and3yde959fmu3rs9sqm3t6", "gonka18gpd8hs08re5k2yvekrfn9fwczdx5v2x9uu92u", "gonka18hd789dtn9xxdvthv7n875knvhz09t53uagprm", "gonka18hjdsunec7aawge3anu2ux3kj0u83frnakxxzm", "gonka18hvv0d72zz3edm4q05fzsfjpvmt0jeyghtlk63", "gonka18j04vs7r2fwlqvr9t9yyd8ruapp7f8k79eq59a", "gonka18j6w2kesdq38fv0wtuspjal8lk2q7h7zage7z4", "gonka18jfgr28786dgrd4cr4w5tld02qankassm99p23", "gonka18k4t0cdmzh4rz6egvvene799fnmpsjesas8tqd", "gonka18k7q4309jelw3h08t9zx5c4ugxr5dyw26j7slu", "gonka18k7zrfe3lr3cpt6n9pd3s7kxlc9c7mmzqyfsmu", "gonka18kcyrz9hazs4p62mdusln02cnana8fxvjcgsvp", "gonka18l36t8yrdjuuutkazal79ampv8xqt8hgdd9e2f", "gonka18ln64yqvsltcheyfgttyyu2lxtr07fqsa33xam", "gonka18m3wcaqacd0u4mfg5xwsxxywy22ytlr6vq4aht", "gonka18mx9vhavyv2ym9jdj8wwssk7syy4ev9rst0tca", "gonka18nzvzzync0v9q73ka2jsh05ptmhda73t8g6gzl", "gonka18p7jkz3t7vrcztrpvj0e0rtgvpyt537uemuww5", "gonka18py93vhrf7mn3yjkqjdpkwlqfpavu3f06ssllv", "gonka18qd8fhk9uj0zk5xlgnsfkpj78ed65sptf0jkwr", "gonka18ra0mksnvvjvgd55xs8x57m5qynwy4cl4rmcps", "gonka18sp6r0zvkejt2n02al5ykwt82gxdml22hsxjw2", "gonka18tq63pqvp8gtdqs6wlnsv6qxfm62gm93purzfa", "gonka18tzk9e0wxed2qx9m0uefr9qpv7pqlju9rs7tlc", "gonka18ulrvu3qfvvtq3s079dl2dwql2rev66zmgjk97", "gonka18v2az8fn2z28ykxu7zyc09crqdmjuldmnag0g2", "gonka18vgk40336ml0a6hc2svn0j6e7agvgu0ft7phjq", "gonka18xgwk828shrhke6vu5pzc2r46dhy02fyslqxya", "gonka18xk4m8t0zj9vpse5c2dem8uxhqw0egtjuafy77", "gonka18xlg2894655tds4sw5u9cfdadewh4cj9sep7tc", "gonka18xpmr5v362gwvxlq78twhg7ht07wu4kzdqu4y2", "gonka18xugc3hdmmphyh0kf2eh4s4yp9ljeaewqdckpu", "gonka18yuxmht359nlwj40cdz6dlr8nyaulgk0gv9yma", "gonka18zgw37evwkpes7redzgh79pjy77rkv5hx4xpz7", "gonka192gv4k5kh88g5s9xll8k7w065lz0rjwh7zj55v", "gonka193gkseffudele243trt7huw0lwgklz5zjsg844", "gonka1947eeszm9l0jwqdaf8rzusccuysnky4m27tyrx", "gonka1948n747ayualpznexxchnx95pdnpu25mph804e", "gonka195yjkuhddrd6f9nm3u3suhn4mrrgnstp7gp8ug", "gonka1970phcy6tplw6kvyewg2qtgfvp9n7svwdwhy2u", "gonka1982cyglwds69k8uvn6xl4aq8jwtx4gm3xnxeay", "gonka1987tjmv8e4wkhf396z2pmdzljtsw2hp7z78nmf", "gonka198st4ejrt03hpv5nxpryyh09rfkahw3wyxh2ck", "gonka1993yrqg6dk2z6zq7rmhnf7rsq3prrnf4peeldv", "gonka199fzuu9fxas3ur9wh3th4ug3yn5y3nsap2x9y2", "gonka199lgrq8l9xcqqnr0agajzl78c4dpfvwnsc4elm", "gonka199sunl2lxpg436h7yulp9pgxg6wykxlcw64rlk", "gonka19a32drl83k3hpgnu67yvjm73dth7ymmkk0qgsr", "gonka19a86ph5yfnrquvz3mznamsgqrzhfzr88wdna84", "gonka19asq7vq9a2l3ugc2j5zcwfw7yddz0mc6qtfepq", "gonka19ayh77ndf2k8ps2992vf6n70emsq09ngxuvqh9", "gonka19c58vpkdx4gyh6jqzwuhdt7mky534c939fhqg3", "gonka19cf6ls3ed23gpz4hdfwx60se0s8druejdnlegl", "gonka19cjm4c5mt3j3qdr8vhytmm4hef3pnkvkm0x7m2", "gonka19djgy0erv0wddgynxafe787s25cj8c9evhzuuf", "gonka19dywm5l2qdd4xqmxgdwgzs6gfjkzyp2crqq62s", "gonka19f3n6z7pdz7q8kp7vgyvx5jkm47h3lxzqz2rj9", "gonka19f8zl7a979j0z90r5k0pajhua2y6ajtykxe8dk", "gonka19fuuu2wk0jz6uta34zgs95svn4ctqr79n8jtkk", "gonka19g7jp7tcpnh9ul6gkr3kdc3lmcy55w6swvql0f", "gonka19ghzvgfr065s3fr5awuvs3nhy9fq4n7wrr9kel", "gonka19gp65p7td0e6rnh5p7cjhjf402e2rejckgy3js", "gonka19h06zf4dmh2qgcdj90cthnw85vpz59cusa72yj", "gonka19h26fcdqq54uv6mv2n6vtr23avhsfz5ehx0pu9", "gonka19h7f66hruyjyq2qu5dwgpcjhsujkxlmhr6h34w", "gonka19hfr9trsvue37wfn7tpaqjlp6sdjhyzvyecyw7", "gonka19hw6vevp0gtxw6xhjgumvmfra0tufw826h9nhx", "gonka19jdzvyj3z25hn36u600ktr7tkq6mgc7mvwjkn5", "gonka19k7cswucfu8mz9fszkdnyp66lvjddaa55q3hdw", "gonka19k8devnfgkw5ftgsynjrewp4hcwnfph3ynqzfz", "gonka19kd8xatmw86wyz6v5qmc9kqwfnk62cydql7da5", "gonka19m47kxgeecyvl4xll882zxwcc7hva5slfxnvq5", "gonka19mh7jn9xmzz9m0nrczgd32usqrcqm7mpsrh77j", "gonka19nd876302m3ll2h7sd55hp9pqzv2hpqalh8pjj", "gonka19ne8zk9j5xk50zvwcpwyeyl2wn72xmwkfycnse", "gonka19nsaq8gdavl04mx0v6lhvzzdkqhu6uf56l38w0", "gonka19p32dj6ht0qx8jt26svqscghv3ken5p2y0yqx6", "gonka19pkgaly3t4x4eucac586uv40e7v0qcykxl97d8", "gonka19pve9p3eth8j7ssv7k4f57lljrtjtl6mjgnuxq", "gonka19q4njhy579ygcgdgr0s3y8py5chqcatx9wxzdp", "gonka19qmrvlpczrqqazkjkgcllv2ksnglhrmg9g28mq", "gonka19r0gsvkrwv7e5a5k8ece956ux34tym9jj6dsdm", "gonka19rd75sm0zeh2cmnepmg79ffn00jtpsdw2zj495", "gonka19rsdxkmu05suy48sz5ly78djzdprk2x6lwqapl", "gonka19s258ae7sx5t0psuwz9sunlksaglwu6705cpzk", "gonka19sf4axsacdphm598alpxt7t2qpacxttdmj5e06", "gonka19skrxufhfnxdn0ly64f6qcnwy0nse2m46r8n69", "gonka19td66n4atq5nj2u3zy3dn39nr5jy0m934dy0vx", "gonka19tvnzlndce56yjskv9ggxtrf0dtsld6yj2hhtj", "gonka19v7q5yydapnyc09ty8js82h526ammktsmfj7a0", "gonka19vg946jgy3s9y4rww8elcml89yxj07dz5wsavl", "gonka19w5vy2z5gz9f4jr76f8uz09023wz2snycaty05", "gonka19xannf93dhhgcqgunqqa88xnqsury7pwq0dc02", "gonka19yqs6l5s2wl908fswm58zptxvkvg82dtynwuku", "gonka19z29zedqjwf0s06g0rcpzfpnee5t2k332vknwh", "gonka1a0hd294we6ga6paq69ue85jrgzc6ql23nuwlul", "gonka1a2hgufj4f8d307cfa8n4kc8xts56rtnvsxydkz", "gonka1a2k2pz759kj543yzxse4hvvsyjkaw0f42mkpl2", "gonka1a32tfg0a3xe7zer9m3ttuxr57wdffpc82qnacq", "gonka1a357vdludl6kpmx0c7cstf3vc0muu7t7ltw8sd", "gonka1a38fuw59433kqs4246m49whqst2jutnr2g632d", "gonka1a3f2cpds29pq0x7yvuh5we233l6aytcgl8gtlx", "gonka1a3f63kvt0uyhh5h6xuhvh6j9ap43kzl5qwzrkd", "gonka1a3pkge3g33v3zdkq7qmycpjwpulms6ejt8z00f", "gonka1a3qq9jmmhr9xyn8p56v5hzfeuxp9r68suv6uhy", "gonka1a46zzvkdg5kf7raesh7rp2e3alx7gzgq3ww4ac", "gonka1a5r7fr92jeyplh0zvt58a95lzkzsflyatr4lnf", "gonka1a65qveen0d9qpu6ujpe27gf6vylptk347757av", "gonka1a6u8ggplgzjtgmu6e5uy2tr9tp8mjryyqq7rca", "gonka1a7a6c7valseg9mmp4lentvd25955vxucjv3kfz", "gonka1a7yqal0cdz0j5ehwnufrnd82q8fuvqk9sqnvtw", "gonka1a8kqlcjyr78rnpzphust74m5z8a6kug65fmhrx", "gonka1a8nua2fxa3fdw3dn9e5q0828e4cmyje8ug8n7e", "gonka1a8stu46tkpzlmr3d9d9v2hhxkwpupsll4t33g5", "gonka1a90lj3ks0fg7mxrvqy7dx4g09g72hrlndpmwsj", "gonka1a9yz979xxryjh9hdzuyxddscwtg9g92079hjra", "gonka1aa8fyjxx94hu3hx686hcuq8nlk69vj64uxmax2", "gonka1aamtlhdj0mnnvz8y99z234ahrgffsyyg86elcs", "gonka1acd025j03py8885lqnaslehxsxtlchm9y58pt8", "gonka1ach2c5kms3ds2728a7dlqwsgddftxljsefxd3u", "gonka1ad5g88e4se9p9q33cnj7gcw6edj88gd9wdg8l8", "gonka1adzm2h68q36j0lzcgl8cnhe7qse0jnlfdnl8k5", "gonka1aemqjfd5ljg9hcdtvjszjx9ned2d8fn6dwfrls", "gonka1aev99sylsnfzyu2dwlnw6f9lugjkvav7kxqp0k", "gonka1aevup75mz4q3vd89ljkqjlrkxvfpwk3dtvtvq2", "gonka1af40hp4pl2rhupsss33j964a8uyrcn9j244qls", "gonka1af4yltv435t3f2mx0qkw2mafdrkmqng05g7l8a", "gonka1afe8squhg6aqwuts34wsyuu3rmn349hqqp6tqf", "gonka1ag5r7em9qp7dn8nf6jecudhu38amu3nwtqv3cg", "gonka1ag6cukxq4nklq309rydjl29q2ptx7xls67trtu", "gonka1agaevegmmxq7d3jhl8frp50ynzzlr0fvhhrhxa", "gonka1agp2tqpnpl4fu8y7wwls800taqeznpds4e0r07", "gonka1agp7nrlez0cvw0tvgmcfpyg7vmztmv57kvergu", "gonka1agpg82nyn9gh2wu7txegdg3aydfs2ynqq0spd6", "gonka1ah2y5uemn9fs3xtzrm6xur88e75rzdv0gcr842", "gonka1ahs8vh2zdk07pxqr0d5wl2xf4t2vkls9h8w9y5", "gonka1ajvs7j8wlgjy8d3kjad520am6jm3a4alj7k4jq", "gonka1akp9f0wtxxe9mntfgpgr2kycger6y7pys7sa58", "gonka1alue9zj5d4qx6fr2ptjd09x5659vmnj47etq6y", "gonka1am04gd8qn00tvgq39a69v4905kxu7egq5jy5vf", "gonka1amlmhjym02shahjv8ldmupg4cx0qc66q6f85rj", "gonka1ap3tj4grfc000wqyxw8hna7aa96xkd65gfq4fs", "gonka1apdtylf7dfskdy545zv2pxvrfja286vrl7cqh8", "gonka1apnzzz6wlpevze3vzsmk7n0vp6az5609magdf6", "gonka1apvm78gywn09vgngzyk56qsjzcaf30dgwyzzyp", "gonka1apw5tzk6a3l9hdpdx5q9v2leehvz5rvvw44x8s", "gonka1aqgxnhvyqu20vacrgstwyn6p5vyar30cekvznk", "gonka1aqxf9su9tcpuctk5mhldayhnp6r44z50sy4vk6", "gonka1arjrt3ck388u0adldr5uzqat62dl8390d0h40a", "gonka1ase4nhwf0rpm9zchzyg5vfln5jmmyyptjxlh7u", "gonka1au034ld8fsrvtyxpzxx8nnnqe5kmhe20lmhuwm", "gonka1auert95hm33pzvzau2pe2ft62krx7d39ypknxm", "gonka1augp89v55hycznay4jyzx34k9e0g508pynugjr", "gonka1aun6f73uq2r5fujk38xe0tww980r6a0lz6a45g", "gonka1av434mm6yp7zr23skze0hrkzgzxghvxkza2r34", "gonka1avf8tjm2mypex33h6tmpp3qxfjpwtv725zp5j2", "gonka1avgp48q8r04n0pe2jru80ta3lm3592y4rhfndt", "gonka1awnue8wwvu5ym3n4eulw80f3vn3ygf82q7470q", "gonka1awp2fxe98uq5s4lpxrhfms099ugxff75ks9xd6", "gonka1ax52nxfepvshvatstyd3t3v56feaph24xzzf79", "gonka1axhsky6cnx9dhggy9uc3cu7zzpfanam9vxykeh", "gonka1ayp9ts3ygzf2fqcu3vv35r37gyk5tf26u8fhgn", "gonka1ayt7p4r63km96cf4qpajw5aa7j02025hp2a3nw", "gonka1azuz6leyh94mjyal7deprr2wpwqesr5530872r", "gonka1c3603dlx4e4ml4prjzh44av9l80kc0w4az2chh", "gonka1c3wplss6ju6fc5mhp0dg4lc7lhvkyrvjg28ejl", "gonka1c5eskqt7fw6zlxz2samjmpurcfd7uz624hwqca", "gonka1c5mazlks00w89uumst0ghmk0jyug24ajjrmu4e", "gonka1c5nmg75lds8muyhry5pzntjprw3xwy082hmqtv", "gonka1c7fjlg6p7l0ynydyzkzzkxdwue7y864tytj02g", "gonka1c7m56us0xvycx4r48nej85rygtxvamadzkf6rg", "gonka1c7nulmsg8enww58gx4tazzmqe0jk5he39tme7g", "gonka1c7t7hsrj5kz28j36dujltk67sz0j5tesexmxj2", "gonka1c7utjkcmkje9c5pymc0hpl7l90ks8x740xejup", "gonka1c80ja2yjn6jfgv7e7hag9mgq3s538lzwajk4e0", "gonka1c88tzjv8upxvhexey9u0dhkes8ym07fyywmumt", "gonka1c8pemd8czpgeg69cu95y58fstuquw93uwqml7f", "gonka1c8utgl2469d7mjlhhd4afhj3ycm6rq60y7v8dl", "gonka1c8vyamwarv89dr7l0w8gsez3jl527vw29dasjn", "gonka1c9vapf2p500rqs2uwkge4ran0y7rc8wseseswp", "gonka1ca9pva58lm296uphq5wd2v95h6amfyvvnypxdc", "gonka1cajt2dwgsycyc9vwn6y74r38cs27hpnwzu222c", "gonka1caju8tg6yg3wkvryhks57jwd8des6ssypfrhhj", "gonka1ccghzsp36s49jc9cz25yjhpqpntz2kj637lwsl", "gonka1ccgvme9cpkwqes65jqgcmy09dtze9cp933cm0p", "gonka1ccw6cmswpdxzh3447r6jesv0vevjhn6av0myu0", "gonka1ccx63zrqqjny476pxjdw3lslpafsgx66y7uwy5", "gonka1ce02jjduga8jvwj8jx39mxn0jr345vgkx7lk2n", "gonka1ce4na09vlynk78ah6yzglsl8ggan7pm7n22253", "gonka1cej8h5222tkfqmgqwn558vav93f8k4khw9ccp4", "gonka1ceuk4gvskjw9deuvequ0hd6ty2u7h4jsg5a8uj", "gonka1cfg49qfgd02l650kguq3m898sp3d2n6y7dg29c", "gonka1cfyx84sn02jz2fh9peetxtjwk2sd3z3wflnnlk", "gonka1cgpwnc8mqykaagn9lt0rkk7c9a5v9ztwwue2u7", "gonka1cgsj4fald9ppasaxj3le0q5nlpzekg0p70yc86", "gonka1cgup7ru2sls3c57g2dtg2s4u9427klvkc295sg", "gonka1ch7c2pseksehq76xpm9ghfd98ccjxqf7e698h4", "gonka1cjpfg340wpfjpslylgd75vjjldnkgcg4tanu9w", "gonka1cjvdez8e6mwjxg0e3g7rrds9ezm9c7kemlu3g7", "gonka1ck3frre8x5ld02g37tq559cxltn5wllry8ellp", "gonka1clm58yldg7zp7dmuwrqyh4quqt339qr3q8fajm", "gonka1clpf7wtd8p333p20z3caasxxyru6gdqwhzuun9", "gonka1cmlns93pn4ddkn9rz4lqcedjacwg6t6vxcdzjk", "gonka1cmud7raqjvndsrzupmn5jh3l2yc448l7k0xr3n", "gonka1cn7e70cc0u08eejlvfdjr60ytz4ynxv92d8f97", "gonka1cn7jka3lx0ex0dxwdcfeaxkqfjl2as080mx90k", "gonka1cnkw5c7d68rym3yr9yqtsesmjqzxss2ax4rwlt", "gonka1cnnxxev6yaauzarywk6n6vcs0ej0jygwvff9xz", "gonka1cpjcdc97u67m3x35hjj8znuvq37pldfsatmcd6", "gonka1cpsegrwafs8quzgx2hutyj0hq66erwjrpsx7d0", "gonka1cq9f8uc3hz39qtuf3q77r5kv2y2hy52ehmmvy6", "gonka1cqtz4d3l7h2a4tugs0raut667uul4n7wm0swl7", "gonka1cr3z9f5xxlcj5rarzhzjwg8wy0vj4fzcr83wcm", "gonka1crsq8zatznue5t6mw4ezrgvw4rtre2paw6lfs3", "gonka1cs744mzemn5h8p2e7c0zkc67sgdd5p8es3qe9v", "gonka1ct7u9ckcgpsjl8m45tsuwc87tcnvmgr4n4r7fd", "gonka1ctg9a7xql5utt4d436d63c4ua3rprzs8efadhs", "gonka1ctmvfd9j52pnm3hypya8wp2yula7tz4xj6gd7q", "gonka1cuafx4u2kucf98lmggz9z2ltmzv57mdgz4ugs4", "gonka1cw859nqcd9mg3y3alraluswu55xz9j36evsxd3", "gonka1cwgcczr7fng927htuk3nqz9m0xdaka67m3utvp", "gonka1cwyqtrxpm3ed6nvz469dw72mx0q0rammc79mxt", "gonka1cx4dkft2kzdzfjcuale2lw5cqaptdzgahwrj90", "gonka1cx5jhxlg8mwjgl8v50h8ypcyxrz4qyh4ef20g4", "gonka1cz4d6jc2lrwj8tg69y5gunl39wr8era9l4qta4", "gonka1cz5pcp5wfnkkahasj9vge9snpvl8ayz5nvu8z5", "gonka1cz86v7wqgahnfna3trq9nc6u35uq95et0hpmrv", "gonka1cze6ecxhaqxmls39l0kwxad50x2skqmk3hswlf", "gonka1czeff7478ukmkf9v2qf3m3qmqzr95muz2fnty9", "gonka1czjrfgs9xfuax25j8nsjrdklzn6repcn25zjxd", "gonka1d0cekvf368psxff6ur7pl42vvs225rzu9a76nj", "gonka1d2wkjaxdk4gpkl4qyvskf36pfkmsnkwqrnymtm", "gonka1d3juktegp4yhc2j8kgl3nfte847v0ql6jwls9n", "gonka1d3vxnhh9tm8lahmnehhwcuqy7lc72rudn5hfpg", "gonka1d427eecnze3t0vt8yjawge4ldcc6pelq486cpl", "gonka1d4s22pmrnxfx9l3tlnjzr4a2h4cvvq2v0t4jrq", "gonka1d5v93rmxuramndpmcsxvum6e5snznkw90nedha", "gonka1d7427yp20ntvw7qy7z60chqhda0e38ajz06jzq", "gonka1d7e3sqgru9tsf2cff577k03sf93cffmdshtlcj", "gonka1d7erkmqm6acwpugjrzytdnrcw2wgx9t4vt7jum", "gonka1d7fl3tfcjj52uavnfsalmydtdn3uvqvs2wph58", "gonka1d7p03cu2y2yt3vytq9wlfm6tlz0lfhlgv9h82p", "gonka1d7sgezy57w3lqh9jkyrt3qwnqyxfmx67cn6zhc", "gonka1d8cjw3cpnvxpafdjjdstzkpxew6mgw05cql7uz", "gonka1d8hkxe6x673an4sjyge53ycd98tj95xpledc8c", "gonka1d8r44tu6sdz5k9tuu55pfz3egdmc87h3xavad2", "gonka1d8v8s56a27wrjc0gfj4c0vafq67j2ddhr7n5k7", "gonka1d9xaxvwysmhg4562cj9j0yq5quqglth992zufw", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1desd6924c4aturcdmwk59jpye5em3q2ze8gvjn", "gonka1dg9gr2l29qq25c45ges0sha8qfe4j6yelqjs8e", "gonka1dgkjlfqrm56tr6evkydg2qkkldzancnm097hj4", "gonka1dhvqhulqqj0484e5wpr0kexp020ycg0vaeszs7", "gonka1dhy8pjtmmyyvuqyeuejzca73254hympgde3ut0", "gonka1djqnccng4mece9p7kpyh588thq6hzt3vk2fmln", "gonka1dk535rvfyvd8f46h56rtz46z22a6hmvjmyryha", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1dkspylxagcxg3z4tfe440t5mjeh33fq9rkxaxd", "gonka1dkw90fau6c7lktjvu20xn4wxs2cxw0h9ta7wwx", "gonka1dmjcf3kul6p2drc8hu988nsa4utnvf9qjwssm6", "gonka1dmjrdj39n950jzcxqw6zqa7vhtg945gqu5tfhm", "gonka1dms4wtzer5zjx32c3grc5twksd8kdp0ut952g7", "gonka1dmwqt0j3ndwzgg54msl3ws0cjzukud62uyqte8", "gonka1dn2gwpylkpjmxhgpyp6vfwqp5awydtguck5wc5", "gonka1dpetn2nshq469heedtcdxxw4yxhkcez38z85df", "gonka1dpxaf4sgn39r6trsv8qmm3aqg3p2h05vz03n5t", "gonka1dqgcdz94x42ukcfmy6crj55a0j2qucsaecx0j5", "gonka1dqj0vpxk9ka2lmqqytaq3jjsfmryv4wnlqaxst", "gonka1dr9jslmgk9pp3kt0twe98g3hm5cnn2z3ehpaz2", "gonka1dsyve3xewcmnt5pavtu67qj8ap8hu7x7aatm36", "gonka1dt53aqun3p66rcp5e5u5gmfuqkarz6d6nr8lrm", "gonka1dtd9gma5839lf75g4awyce7q5ttahsm2japutm", "gonka1du3ra0wra9l7d8uqctdrdzneufpw54k3rngjme", "gonka1duuygcl0kax887rxz4ed505v695j3sxktzvn9z", "gonka1dvpgtz2aad62ax2d2hta7lc4x7gwh47j8gdla8", "gonka1dw97knrf4lza0r7k68j2vevsudz0uym0l022au", "gonka1dx955a4u87sfxaqmq7d74ra87gvtfywgas5wcc", "gonka1dxs4az0nz6mxpdcjjtf2fk9fylrsr9f8d3qzfe", "gonka1dxu9esgpzd0qsn5nn4q7p06zlxz3ldl7xfhj8y", "gonka1dy53k9x8wk70tj7gz3xaxzse0gpfkx64gd32fq", "gonka1dyddmtqh96djn4nzne2enp60xm2kpx92hr58sv", "gonka1dysl5crmmsrjskj5m37zd26cqks0krgrzukzhw", "gonka1dzk7rawvnkfwfptkzhdf7dh5s4xsqfml72tmcy", "gonka1dzq455a5ulu5pmnj645p3emkmlq62eq7g7ltg2", "gonka1e02zf87fd9pnlxykva6lwzmadttlkxsc29jd6k", "gonka1e2e84nsp2avw3jlqy3fcnjw2xm5ynpwq5u7nns", "gonka1e2mhxxxcv0mxl2v3mtwxcfqh5y5gv4qu7u020t", "gonka1e2rnawlpqumhjgmkqwjkyeyhfnsgaxqdelmwqc", "gonka1e4elawx3wgp407u3vqr8kj7ctef0qzme6wvntr", "gonka1e4qcqggpllj4ulsd97ha9agm2e05sd48d4lmyh", "gonka1e5t9uywfzty00enw37ws7hp6kwxqh53lhwfpes", "gonka1e689jkzfex694tq0h5rgfj83ymnq4t0nkxtx68", "gonka1e6q0zgndr833egu2050lqqdg7tg8av62duv6em", "gonka1e75pydhslyncjztslwjkfprrysuw49pdukgu7v", "gonka1e7pv9kd6hzpyqsy9j5hupcmsfacwgvkx4nmwk6", "gonka1e7r2m2pfwguls3r3dnrqtyn89stlcallwzaxk0", "gonka1e8d0gt4d3u565208jjn035a6h3nvxzwtc4w8j9", "gonka1e8gq493h6mq7c267zwjq8hx9lmxn6xan5ykwqu", "gonka1e8gvu52lnjyu9t93vu3kn238j77r0y0y66frrl", "gonka1e8vudlkysw99cspmqaps9rnp953mwlld8y9n3c", "gonka1e9j2dsvadkgzm4smm0aen6tucyqxg8jzlqzmqe", "gonka1e9muhlte58rwqrr3493qxcwcj8mqrg5azxa6v4", "gonka1e9vdm8ny7saz4n7yx7hng8hvdj0nu85v4edgnr", "gonka1ea4hhgnahtu4g0zzpmz2p8elcyx7x99hamk0x4", "gonka1eak0x8zmyt9dj82ncged56fr2yf23uqakypvvt", "gonka1ear4626d396zccl86vytalmmpwh045x7umu8v3", "gonka1eexhw7ks3cd88cyu6qx5zzq3ag484mgw4mzn72", "gonka1efg6yds06fgst92sxdup52ytxcy2gr7qcymt8l", "gonka1eggkxayqpv6u4s693lwj5a6zv72jd7w77y4mwy", "gonka1egvfr7l6udwnaz5tgqwwwyhn8vrg9wu74r3z89", "gonka1ehqrd2828q8zrkn4qafym30eky56krezucxxhz", "gonka1ej8770sh45yke7kahqp2pg7ek96q2ue3v6mf7w", "gonka1ejnrepce6yurpscd7gsek24x8ga3cnpw84dms5", "gonka1eky23pgk360sra7m855eha55d592vt46cjz79r", "gonka1el30g8vdc89hk5n6ta7z9hh4ynencwfmnfdtee", "gonka1elyuw0z00r05tzhas8g8daltkjagfflqpy0fzs", "gonka1em0j55hzkc2ce9f0lnrqwfrl595dzh8qtpu59w", "gonka1enwgqdpwrthzwzl79xgcf936rt8n4zulnnn89p", "gonka1epvd7y2twy23v50n40rzgxd2xf9g6q3vcj765h", "gonka1eq2xaz8y0y3ssfc982xnxvr6q67crtyqxem5c2", "gonka1eqmgv4mh0qjvpg37jum4peppflzhhd33rfwc9k", "gonka1equqcel7hzlu07ekt7tep62yh23wp0cc2ryqyr", "gonka1erjgpt52lp7atyq5c5u5tpprtqjr4pt6zd2pny", "gonka1ery6edny4e62qwlf53qwv2r0uxdecktdkngjwm", "gonka1eucsf5susdrxz5mharlw8et3ns9rf6987077xj", "gonka1eupa9v2qs77yqz7ramc88gy5vmwyfsc2rq8eqy", "gonka1eurhaq0k7yfmhcgc4r6fev4w74dnj8h35y6aca", "gonka1evckvrxg4rxvstuvd6rng3mxv3sz538q40yx5s", "gonka1evnq82x3j2mpf9a7mgrtuav2r2v635q7ekt96g", "gonka1evsnmudxqr9lxchjj5gsxq39qk4p3tr0y9uxu7", "gonka1ewlwawmd4z42daay08hspv45nmzlvffw0ums94", "gonka1ex0ck58q3elelsysl3r9qwjljs7yn2yd65kr6h", "gonka1exdrn4u567mv9qcauycd3s4ezavxpdp8ucu8re", "gonka1exu6f0cxdaec4fvk928fs5xzwek7wzdy5d0yz5", "gonka1ezpg20aga2mv3avkda2zqh5nh8jys9pg0q2cnq", "gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e", "gonka1f0vwsp59u0etdafaa920x0yleqz72elr3493yf", "gonka1f363jm4dxu3p2hg90cqt3tkqaucrfd3v20yr46", "gonka1f3c4y4kq5hevh7wssyd7wrx88x6p6prmaunl89", "gonka1f3qe6rwl8a8lga0atrdq7uqfu9dewl0vtg9rnv", "gonka1f3t8ksnaxly2w69udasl5gteejszplgg5dlhth", "gonka1f47q2ppldw5f9wkfv7xgwhvmptd27knqrl8xr4", "gonka1f4gh3yku2nffs66jdvfn6phydewpqt9jz85avv", "gonka1f4mcr5pzn9rtdyzdv9dfg4x47vrqxk0f2ujqs7", "gonka1f5fhrywmd5p0jcd5atk4rm2tjxpdn772lw833k", "gonka1f6gtlzcsls4phv00jk5a8phjd68vszquewsetc", "gonka1f6rxz64xdejyay88u57lvx2jlgsj6n5lrpyya8", "gonka1f7d43z2qpcv07huwf3qjj4zpssvx6080a357wh", "gonka1f7d5j263cw6ukux38kg5gglup83aazctchmtp8", "gonka1f80z9c5kd2lkh38p93rmf0lnf6exxk4r5l4ees", "gonka1f9psx8elegnzfgqjt38p09dyscqy0xv094yf66", "gonka1f9py6qeqf7wvqcrfgykx3j0xxg63rtnkh7nxy8", "gonka1fam2nfplw6ff60vdu2uwqtand2tnm80hx4t7sj", "gonka1fanvhrjx0jsm4klln6wzdtwfw9p2rmuzk60xz9", "gonka1fc9tzt83dgrqswlgay4668cuqjrk7zsqks2vm2", "gonka1fczfacxeypuvc20judf2s6t92djtd8tglszmw5", "gonka1fd0wcpeazhngh78cl9acql74t2frq5n9qr5c8u", "gonka1fd40dy9zf2c5tywnxggmjuvu5hnrdrdnyyxcqs", "gonka1fdj0s8004udagkzlccs3h0ysf5lg758x0jfe5v", "gonka1fe82wt2w5lmzq9wtjt3gceung3wnhk69l54fdd", "gonka1fedsruuulzavlw3tgqmsz4g7gxkzsrjrwhzqmk", "gonka1fezpsxrwms4njwkskesu0s5t8wl46ueegk5s3p", "gonka1ffjt0acf87chys5w93wsrdj2s94rrmcq8mt48l", "gonka1fg6qtey0yuv25kzjl3883umv6h9he6khupn2l2", "gonka1fgd672fwnd5ls6ccsxvfww2vlsx3sklyr5w9xk", "gonka1fgmw3l0x9f4ragu4sak7fyh698ewx50t5xk7qe", "gonka1fh9xegf6j93yxx58d2dff78kj7e3szwn6cekqa", "gonka1fhwdrlzmynw7lwfgws5fdnazxlwqa2xs5td6xw", "gonka1fjrq7m6xy9wpmm88vr63d08ps8dt9em38lhq08", "gonka1fkq3xav4zuv62hst7zxtg904sy4hnusxvtwvtg", "gonka1fl2ux2967t2pgcqf9evta9lc4l3a4l2gale7tg", "gonka1flls3egqqpt53gp6ea590yf9zuk0ertrxu9jts", "gonka1fnmyrkw6qta9uqn4q666c4d8k2vj3ves68rt38", "gonka1fntz0497gt905j5zpp0pwlcn7jm2lxuhaxtcdl", "gonka1fp444xd5027mzhx0tnlxkx6euczhp9glt5f09a", "gonka1fp8ue6lf5qspkqu6yfpatjquun35r54zw4ndul", "gonka1fpehxtynjh0vv93nzg44qgwsyd8u25hq7pyyw7", "gonka1fpvk8l6rw9dyvcgq20ypxk86g377g3lrnu7609", "gonka1fq8xhs3ezhzzf7psp3qrnn6ngn0u7g03rg8tj5", "gonka1fqd6w3mydcdcezgfyvww7nu5t60xwmlrm8vcy7", "gonka1fqfrmpuy3dwcg276c7g860vl6vszqz6utu3f8a", "gonka1frfr2z4lclq0wjqsrstnhm48rmvkmd0tfsssvk", "gonka1frxcs6msdrxmwc4eh8am36tgppu0kr97za54pd", "gonka1fryp5vn5xppkwykzjul6e2crkgxgwhl2cunrmx", "gonka1fs4fapsf05qf3992m92ac3cl38uzh56vev4806", "gonka1fuezrv0q9hslr4jjgl4cwquytxqe3drksxq6fa", "gonka1fujc399fxp9pjrjvd0ymjjk3rzsgl4raq20pg6", "gonka1fvghsj6rd3fullw4vahsd5a6xp4c8cd02ugj8d", "gonka1fvw4sad9uqe75tg3q9gaj8rhav7dc454wr2gxe", "gonka1fvyenm5ms57hmyze8yl659c8ljg4r89nlwap9u", "gonka1fx8kje2lu4atkatdq2t36fmkkmvp7qwlw0kstl", "gonka1fxdt48vp78uxa7apuuamv4clwafxagnjg9eulc", "gonka1fy93y79kmp26jx7musr6vep9ux6ntv4chsh03s", "gonka1fyjge8p3rc66v38x2q63srvawsd2wpnhx2ek77", "gonka1fzchus8tda68rkw623a4rquwe48stcexf6nt30", "gonka1fzd9ne43l0rjuptdaxdvlhh9x65krl0vucrf5d", "gonka1g0jmlf77jldctcc5smfxhghllkr84xqe5mrt6c", "gonka1g0wws8e9j9jk4q9he0n2gd2f4ad5aqg7g6y6lz", "gonka1g2qwc7vglapd4ktc90a0m0r8zdrg2nh5tr3mrw", "gonka1g3jpvmr728u2rwymu8pe7g3lcspfwxr4ysqk22", "gonka1g436fhdnvutucwczf8v26dc8q0cwfjhkpf9jz7", "gonka1g47mkj7zc92jx6sg5249lrl3xg6050qk2r54ja", "gonka1g47tma3ruze3dtk36ru97pcn6yp0ffcyws5dr6", "gonka1g4pqp4lpmq79q7p3h5r27lcywu5lerq4pj90dh", "gonka1g5cud480r6ehvj8ycrn03puvkgz43m0jz02rg6", "gonka1g5d7f2pwkzez2kmu92xshk56u3k957r4nyuxmn", "gonka1g5npauthlljh77s2uujv3v66dhrryhn6sqgu47", "gonka1g5t786e2hnry8c4d6fd4rh5t3vsfdnevejtsvy", "gonka1g678l9qnqes783gywczqn49lpgglyxz7cnww8y", "gonka1g6x8ffcysdfju6anvt7we6u2e80fl7pgzjmk99", "gonka1g6yumzzkzla2wwl0mmtmt6ndmeh6nlzqhvrg7z", "gonka1g884r7q58wptvlcpuk09gvw9j5uhwadr4qjexs", "gonka1g892jehuvdnrkgs26e3mp5fj4z7ec27wd2w4up", "gonka1g8v99pzkqhc752fvh7fkn3vxznrgrx7pdraa7m", "gonka1gd79gdm2s35rc4mhssgwrqh2lnmaff0wq4mwq6", "gonka1gdg70vwrtr8gmal53zzq7d6xk2exh75uh2mtcm", "gonka1gdqzjphqrg5kxacp2yctd8vq2uuq7ve6t9zyem", "gonka1gdrrsudtxaldp2jrtn2v6qzpd8zr2u544pz3u5", "gonka1gedxlmkl6whh98yk2r9nea3w2alnhk6mmm6q7n", "gonka1gfc09aclykn00wh4049et0d7n898syf96nnr75", "gonka1gg2jwjfjf22gda82gm947mjs8z0gpg9tk2eh3m", "gonka1gjh8us69gese2jtcz4h2x55n4xzdfuz8p2nckz", "gonka1gjlhk2wnct7hhya548chqjj2ezrs3za0pcxxnc", "gonka1gjq6euu48kuvfcpm29a4ndsh4fv5cuplv2w54u", "gonka1gkasfu2he86nhh43wnraw6227flvlrgvgnv26p", "gonka1gkdl40hfau92xwh39updqzzrpllaqv7fjanhlm", "gonka1gl3guy3q0wpas2v2vfw39qhw0cf99l6s7r3n9w", "gonka1glnuet7gsd75kfafv5whf0xpz7rfm6jp99fn8c", "gonka1gmc0mdgl6yypxhmmfjuzvpzls3n3qshusc83nc", "gonka1gmed6tx2mr5n25xq599tfxsspxqqgdudyxrp09", "gonka1gn7pthppja6ux9u5ql04836cwzfdnm5nj9svhx", "gonka1gnm6zvkvk6h3dvmmrd5pyw556fs53jcml8y5yw", "gonka1gnthnc8a4xw046a40c23vrd6gy2pgcjxe6a3qn", "gonka1gpsva2qeedt3uzxd96v32m63l7prtyp4cg02n6", "gonka1gqruzgfhxqqg5ftvpg3945wm7mjsfxd0kq99up", "gonka1gr8njjad9rwfmay75xvkr6dmtkky3e3fwceuxq", "gonka1grfptv5qp4gxecpmr4lcqcavxhtj8kus0z3a4z", "gonka1gsarmv9gsc7g9fv9nsqtk6t0d7erxpurf5mvvl", "gonka1gsd7hegj4slypsjuq6wggf0eeqzyekfmptgjd5", "gonka1gstreuc0fz4gksar9sx2uzg4au2k7k83cremld", "gonka1gt2km3x8th4q0py6qqwlznzzsdyg80a00ve4at", "gonka1gtses9txpuphmel3kmqekmqt4lccajak3m6kl6", "gonka1gtvwqjnw3lff8nfw7a2hm4el9z3rqhh7gg4lhz", "gonka1guzkdc9hp24shxslgsgdhde4p2k039ealazwqs", "gonka1gvrssnvlsj6he2lyv40y5fpdawn2xuvtldqv99", "gonka1gwakaz7dzpay0e4at7jmj0mrnqwjex6kza4dlf", "gonka1gwpt0md5cddhkwny9t2w74604k27x7un6gqles", "gonka1gxn05uya6uq0q9y0d97vn874daedjl8pkxclhc", "gonka1gxxccka8pa385xvqawmdpcuxezce28yt590wx5", "gonka1gz6d9j834xvhvyt7c67ux6egugns7dlc5dzqds", "gonka1h0qgfukptflxpurx4nykw3jtg8ya3a96j0gske", "gonka1h0qs5gghs7u0k8xu8qn75ay4lpx8ty0ugwrw2z", "gonka1h0s9m9q6le8wpkcl4qwtdghru95nldmald6ze2", "gonka1h2qxkeglzstqhdmuewyuwdkae0rk3l8wqxwrl5", "gonka1h2xedl4r0zw2vs0al95thr8qfceynvc9fnkj36", "gonka1h3s37p0l23mg6ak9h9nmayh6r9f2vm6umj3qet", "gonka1h4ajcmsuzuwxx8h9h3vwcn4gr74ld99cxkfux7", "gonka1h4cfhw7q6jmjy2uvpgmmvm8qwquhdll9dzk4ac", "gonka1h52frcjm37lttqr5zyy2avqfdn7e27lvyet948", "gonka1h583klq89w5m39tt832clppkfx807av7m07656", "gonka1h60zhqxm8c40aupf2fwjd8uxlzsle9n55jmzn2", "gonka1h6829d8eykrqgev9jr630htpze3j220er9f2ag", "gonka1h6ls6p4tpr82yjmtgxp3yd05kmkc2juca3dwa4", "gonka1h7sgpj74ay676syn230h07lmvj6737z9jqpavd", "gonka1h8c9ue2d5uzl2exflrhuztln7lv9p6fk3w89rw", "gonka1h8yc409j90mwdcn2aeh8d69rs9hn8smr2pudag", "gonka1h9axtmze6nqeeh9azggrk0k2qcx8lz2shd67jg", "gonka1hfl8ataf0gu6tjrs08vqk9rl5q8vefcvfj4hsv", "gonka1hfum2nzy80k3uq86nla97a4w423u0zh26axfxt", "gonka1hfzrys23maw679ql8gurytter0ajkk307yl7ys", "gonka1hg4jc9632n0w7pa0pjvsqm0wz0zkmtw7g0rvv3", "gonka1hh8zunec9e6d5sy5cme5utljcuf0d86mnr49xv", "gonka1hhx6pvs6n4ehgv4wzz7h9f68t8hm96t9fq0ydd", "gonka1hkxve0xr274qfsyjzdgezh5j89teya73lwnwvx", "gonka1hkz4qdpl2z4zvlyt6mxfsx04yxfp7sjhnyu2xn", "gonka1hly4pd9h23dssjcg586jgvmtu77kkl3unnl60c", "gonka1hmeg4xq8autummlkzathgxaezmwe02ul2qe0c3", "gonka1hmjjq6ghykww8f8ujajnnmu2dpk2drrth8mtva", "gonka1hn2xxsd4ht9ky9f58z9w33r0wednexld6rkmrr", "gonka1hn9wmlfe7nha0x26p7nsqvk9g8pnwml74hrm8n", "gonka1hnye4t9y9g6t2vg2m9wy3jj7cgcamteu27lnjy", "gonka1hqwgkck88d5wnpea0y9dn0gxmyg4rwjgcnvacf", "gonka1hr7tssnwuw7jk8s4gjf8uq6k9aw2evnygsfd5y", "gonka1hrvp8gaxd9y43uuphgpmgmp3xlau3veeq9x6xj", "gonka1htmpsguygyvuvrw0ntw7exaqmys0k2p88t8am3", "gonka1hvat7x6qspwh5vw2pynwcdh57kc6xjl8g67ljx", "gonka1hw2777przvsf5e37dj05tpk4yjh8l6qrdsfmhg", "gonka1hx9a6297776yndfgajr7tc3e9kj96t77m4xxf7", "gonka1hxd4rmd3fp5n80ujv7dfya2qz5pl4fghxg6xa4", "gonka1hxexmarrxfq0kp9t5nuf9qzqst3234qq8xe5fk", "gonka1hxu5ylqz0hnvaskruw4nc0xqklxa2kkwm9ytfr", "gonka1hy4zasaf3knphe923exxm3vl6vyr8m5k8y8ucs", "gonka1hzthxq56ngl8jzxf00mwqcpnzcd99z47fdjxuw", "gonka1j054huyld6akrgzgjzxv9vr9mghvwdfestwkaa", "gonka1j2g3g844qspgnjjrtmcrt55ssg4h6akdt4f66a", "gonka1j2m047a6sujxeznp7rkvq5t64k3hu203cruufs", "gonka1j2z5evvrty3tsxqc7rmu8vpwapz5ysff9usr08", "gonka1j3f2xkapx8cmczpjqcsrh7cc3peyj3ngkjv4p8", "gonka1j3m7rwdjrf44xy8p7ff4w3srqxaml0f73x09ud", "gonka1j3xajqgg0mu9lvfu320mknu736nl0ltmeeqje7", "gonka1j4gwddnpf9h6n6899znss7tprqzxpwpedk7ayf", "gonka1j4rxhges6g8fj2cvvexdcaw8xgmwpff5wk9req", "gonka1j4zdyxve2f9fkj8d2nx2cvg09wv67cy7xucm0h", "gonka1j54kqnxzsx7ge8qywa0esgqunk3f8ewyj5g55s", "gonka1j5tclse90jvw9w9y9q54f03tt49yward4uuhle", "gonka1j6ddjngvwy3x0yze36nks8dvlqdep9fxaj67tv", "gonka1j6erqkek0ce2nwdxkwxzthq54ynls5w5dr8ww2", "gonka1j767qeys5gf6fg65cffquxv4l3lcrgzhljdgfv", "gonka1j773yv2sqm38tt6d07x3eq7n8vqe2n7qenv420", "gonka1j850hy8d07pgnsnhepkc9jpwpzg5cf3rzg5t9c", "gonka1j98sugzzgzqv82qz8dqdtz2pd2y65tnwgyalsy", "gonka1j9eurz4unzt8g7ptk7sc0shmaty9gcsh64u6ap", "gonka1j9rxapzwm06quxcul5686e7f39g6swhfhwxtwa", "gonka1j9xwc4d02qyujg9wvnegyk3sxtl52lc6lpa30r", "gonka1jaqsen7lac4x9aedjh9lgjlwje9d2exjj8w8a4", "gonka1jd6ehyf80r4a3jzm0vzx33ypwwnhzqcyuqz8u6", "gonka1jdzclqkwzmcp4ecqqpygn6h505jksl56hs93ym", "gonka1jewynpl0xxyamgzdnuyv6873dl4h8eelgaj6fh", "gonka1jh8ex3vr88ks5c9vlvu6ynnkg2jf57n0vjm8dz", "gonka1jhr626gdt9yewgw4spdvnmjwnrnm3xhcf9kmz5", "gonka1jjrk62tfthp2ju7fzh9t6snc709mxmcmeep98y", "gonka1jjvtrkjvkwa8y3vkpf7yykcn50vj5ue74ll0l7", "gonka1jjypsepz06guqc2lkmtr27mm6dma9vf7pfrzqh", "gonka1jkesey028m99wsu4fw8ze62c355l9gju4k9hpa", "gonka1jljdzfsx4tar5v4z86gt53p7ulk6p4wdyqhvfl", "gonka1jltjehxsnum94nt8c00ts7khmpy4lafv6gryzk", "gonka1jmazay9q7j62mawcu644zre75hzqnnfar00pgj", "gonka1jmynyvawnx9jlwd6he7q8hdltpy2dv2tz74daz", "gonka1jnqucqsd3unyxsgkthqxxvd2put87eewpvcv98", "gonka1jpr8eqt329k8en46lldxr8hlkmqeaugnhl5yf6", "gonka1jprcfmj3x3uddc7tt9ha4zxk6kwy3y87cht4wf", "gonka1jq3gltn3z5amp8x29cknhvd2dffuz3c7qukm5v", "gonka1jqlwkd708ths3fzrz7mga7uuv40esryaf09y77", "gonka1jrkf560tvgqw3f9z4axs9da34lgnrd396e3rs0", "gonka1jrwj2hqjwy5ulgkpdsdv6gwch7x4alnj88wmm5", "gonka1jt09ylwdxd07xjh3skyen24g50uq6kle87cuyp", "gonka1jt5mqrx0yg5k6qdqhnkc4kpya4mzy52ngyh34c", "gonka1ju7jfznld7vg0f35wgz507m6c0lzgugpmajnvn", "gonka1julpf52dx8ha7pvjs8zrcvualzc6lxde86kyqf", "gonka1jurc8vjfyumlxkaw7jn8wslvzteqdv4skrkgcj", "gonka1juwk05glldgn7850a3547jsl7l4vrhx9k5g3cr", "gonka1jve3qdmmea6kgcl4y5r3hhll3lm0zuz7kutqft", "gonka1jvp4r2dx3t0d736fmxy5ncgwp0w3kdy063m5ps", "gonka1jwc0yrrx2dp0snptvrd3q56tsggtqwmg582kv8", "gonka1jyqp04yrjn8vdwqwkuwfd8nqal4d4vr3lpdyuk", "gonka1jz62cr02k3cwqpktc269gm8dp86fmkljp0qa88", "gonka1k0ufv2jx53celkma2h0adks56dlxpcgca0g87k", "gonka1k2mfvh3la689wel2lg89w74yw6d7t4s8rz75k5", "gonka1k37scwnyck5nzfqxwdq3gnw26squrtjs3ls4kr", "gonka1k3lva2jsxu5qx30f65yxdlcey8d6f3unmy2gks", "gonka1k3xh9h66ye5pdgv2v94xhf7paz445e7qwraz7h", "gonka1k445mjg7hxs55jtwvt0p0zk5qu2quqwfa50qkw", "gonka1k44asc7sg45hufxyg6jrg9melfcn8wqu9u8rzm", "gonka1k5648w4l9c7ta4x2p0aaq6xuhyxchmrp3huf2g", "gonka1k5kmlr7xjuvwvhmprl0k676lmy9w0qc2c07hjc", "gonka1k6fz733jh2f3mhp753mfqtnej6gfynq2ekg5c6", "gonka1k82cpjqhfgt347x7grdudu7zfaew6strzjwhyl", "gonka1k8z6m5jyfe4pax2jca8hhtd5gntfq6qjyhexma", "gonka1k9ser0a6lr23rqt843z6w0e03us4lp6af546fg", "gonka1k9wzrm5yq5chfkpr50q0xu92pjte9mgjapfjuh", "gonka1kamuzqzeryzwwmeqqyy5nnthxlfm4vvrtqjtl9", "gonka1kch7y24sjux5s7qd9l9j02qzusk33xeqwyz0kc", "gonka1ke4t935aqvya0kcee2nxcjp82vk8sa3sjs60fh", "gonka1ke5uzpx6h2g94h6c6a3428xflsnd9w89yca249", "gonka1kff2tw3dzzx9662uda2xfxafw7ysxkg3jedtsy", "gonka1kfsa9q7upj8wnqrkaud755y7w2vwug3pjp832h", "gonka1kgqpp073jl6c55fva4yhsnwnq2jsv70h8zaq9u", "gonka1kj6dqlnz200k4dsd6tph06cl7l84adhlxs4j96", "gonka1kjcnckrvf7plpylg5usjr57dsqyj8mdnzlywvk", "gonka1kjrvy4xme4ctepdjspjdw677nmvdwlps4hl5h8", "gonka1kkfmsuqzcyvfm40exx3ue2tlg8er3csxlm2nh3", "gonka1kklqpl45kg9sey5fxul5nmzegujn8yrl5szsyw", "gonka1kkttnunts30mcg5px727eghs5z3vfwnpanz2ed", "gonka1kku5fhg2e72fgmzz6eu7rxgusg4c4j4dkvmvvw", "gonka1kkzm42zy7vkc68c52jufq054slac2qr52uqxjm", "gonka1klparcrck0qmq9as298e6m928xy4ktfwwkp9vr", "gonka1klys5qww5c7c7v4ru68rtpu6uh2wgdxrk99des", "gonka1kq53efeal2w6l9sw7ggxw5wau0a0h9qdfur354", "gonka1kqmcxqgqdxl8cnpw7juatlsapklf02tdn3rkjt", "gonka1kqrhuykwqusdwt5cap25zck7jv6t9v8c0tvuzc", "gonka1kre73lv6ylwaxvfmr3aegesnjvxufj9hctyslr", "gonka1krw2vrwvq5jt7w5sgaqtnarurptl0w7hf7ld0y", "gonka1krw8er7nj49x7gt2jaqspuxvnvg4gj8x7x87du", "gonka1ks0d8nmf4ruv23f9hcqz4utqtq9n9cqmlu3hs6", "gonka1ks3t0r8g5glvv4um6ml2gy5dzg7l3t2xmp3fg2", "gonka1ksz9raj0yvg7wxdfhuj5474lmjpkzkphu0jw27", "gonka1kszzxe5l2u8fsc5nhua9kht2me5phje38p3dv8", "gonka1ktd5rha9hghm4hzt2eyc8v2p6g66a0zmry07qh", "gonka1ktl3kkn9l68c9amanu8u4868mcjmtsr5tgzmjk", "gonka1ktwjjzurxgfkumvcw3fccahw030c7jyn4gnq9j", "gonka1kuqs2pav58q5ntduqe8ywdpf2vm0etduxgt2se", "gonka1kursgjfk5n2tm49u57gexj696hwja7a20exkg4", "gonka1kwnqpmtg3524egy7u5zjwqzc9d9erzn4pd2g5w", "gonka1kwtmwtc30ej6j5f7vp5xcr4mtdxyduzjlqwk7q", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1ky9mpdps70l9fe59dg7a7ctnaunkuuc8uet8q2", "gonka1kzhcxdkfdkdyzvl3sdp34yrwkfngdhjwrmua03", "gonka1l059p34y0lcsuudgs8ln83nt6htjnmjcccqn7v", "gonka1l0jr5p0nuyxu2ed3xlwnwpz3alqf2hg5fv20vj", "gonka1l0ueph5pclg9ygaaxsrmxmv24ss28a5ddwe4as", "gonka1l42zhzv3hy6d3y88aq37mdgux4u9crd968v9s4", "gonka1l44nacmpmt83kavvevmhlh8elspjtjn6wvwzm0", "gonka1l45efpupwqw9uky3gjwy35mwae9jwgffuqpm7s", "gonka1l4pk0jzx7kczmkan6hsj3p7q6w8twd96sq3h9x", "gonka1l4vfzkwd555pvxqzr3ksphgwgv8xsh89ytmjp0", "gonka1l5rs7xq89dy8ycw06mrf22f79r74t6y85g2ylc", "gonka1l5v6g8xahf88pqnv3htq72c6kf792yvw3aqx39", "gonka1l5y7amaux93wgd60wn0446h97ezl3vjd6sy025", "gonka1l6f2fsyj65pth4zuk682q4y3dfjexex4ve8xlt", "gonka1l6na675fh6h7kc5ww30n7fs6wqxwyhgcaljhsu", "gonka1l763nf87r604swhrwyjh4dl804ytvgkzmdrfuq", "gonka1l7kftz35d67xnzppm3esrrrpumhwajhg7lr5cz", "gonka1l884ep59uec8sxkhhhxkm20ty8lyd3kczr6xg2", "gonka1l8jd2nz92mnem0xwgwkltcw2952cnlphs5arsa", "gonka1l922skaf4ytgw7m9x5t08z0enrmmnxnqxuh8uc", "gonka1l9h0kja3w827mjg9alfzp3f0wrqhcsmcdw6yt3", "gonka1la6ec0l7yyc7y209u7qdcae72zgsmsk8aam98m", "gonka1lacrx7sdpwvy2fjxsldmz0w8ptk5qlegrh0qyc", "gonka1lajfpxh74xse4xxease0trz5gwecze99875tjf", "gonka1lan2x2er0djczj7rumtdn29rnr5g870cn0tfk0", "gonka1laqwa3adrgswp7gw48nhdxt5ahqz699tk0n2cs", "gonka1lc0h0gynvcsddc5cra0ymr08krg9932gw43ml3", "gonka1lc80tv6k38xc6qagx67wy42mkdl3zplgykhjz3", "gonka1ld9ssdzqfxpsleangl5rquw2hnu08z69z8rtzv", "gonka1lda8vlte0t6jdtcwwec5de45unvkqrr06caw00", "gonka1le5sf54mwjq5teje5nszna2ngm242jt7y4gcr2", "gonka1lecmns7dj5wm8f53pe6c8nueukqafknel2wt2m", "gonka1leq6gdxs2d7fxqg7528hkq8tk50v2pdj2pzq9k", "gonka1lf5cpgqfxn9sd00cdeuekyxwhckt2stv5famma", "gonka1lfx42xx9nezvgm4jffdgxndqjkv22xsfjajzpm", "gonka1lg44xnww260jmxc5jytq6gfrad65ye9z04p5au", "gonka1lgq3aauurjduv9jkce3kwkpvqdlcfqca79l7lu", "gonka1lh0danzlvxm5qtaly7myqd3n5sus0fq92n8shx", "gonka1lhgjw9dzf7mxhxr497z6wggj0wfl07jh8g3clh", "gonka1lhycnwdtc6txcpvdvz2wym3zpdhlrj6w2z4evj", "gonka1lk2qgpw55yvykx26x042ypns6sux5upf77m8h4", "gonka1lkcraf975jaqnj64qtnfrm85ppka2kug9gfpk0", "gonka1lkx89m6mpx0q5qntu5fgnvza22hymegtftkwdw", "gonka1llgwryqd9vue4yzqt4ddwtm2ljyytxn9g4l6tp", "gonka1llxuc898aqzq4twjrcjkcsfsyq9pj3mz2zx4lq", "gonka1llxvtg0657ldmqn4l3t0ag496ff355j5kawagy", "gonka1lmh6fy92ac2wldnpugg3t3xhp8lnqzgq0j0efg", "gonka1ln28jur0gvuwf8frx63lwwagysdf03e8ldayf3", "gonka1lnaq68m0dj2y8lkvyvy6ntggtvfgscjzvqqarp", "gonka1lnus3x4dy0ze8naktrldft5edx4e36qc53yxjf", "gonka1lnynt0wfxhn049m7mjg7kpxcklspwz6ngw0rsv", "gonka1lp3q5zammhv5a7fmn5u58clz5k7wr0205h6llk", "gonka1lpxkqa9pke9t9u7kjdaeezwlnphd249wujqhd5", "gonka1lqv96tny8a0344e6jfgxk500q5ct7zy9ekz49m", "gonka1lr9mj6dgkv0h76c8y8w0l3esztyg9v2q8d6d8d", "gonka1lrls7q8nu8rhjgchctswfsjlnjh84vwycw3jgt", "gonka1lrnzluw7jqsyt883z2540882zczlnpa7cm3454", "gonka1lsjva3ng4m58xlpyq482l8nx33qfv4tnx0ms63", "gonka1lt2fnjvdjg2lhcflvkwpe0hkg7xsnwj2ypydpt", "gonka1luaf4vqch7v9xjdx7lyvz2qp2lp77uds6q36g7", "gonka1lvg9yq3cvpft32en50stcrsrtzjsar6gfpe3er", "gonka1lvtxgn7lyjwnaggfp2r8wykkcnuuw757pex9ft", "gonka1lwqgew0dlvyq8h0q3nh879ncmmghu26pwr56f3", "gonka1lwv6fnaa84qlq5udua9ew5pm8zyu6k7wgmvh8z", "gonka1lxnfxu7t2wwerxhjpaxm0sk5rhd7w99tj8dyy0", "gonka1lzngx5unw6qu7f97zkq6wkvmk5aze4quwn7rnt", "gonka1lzxwqhc5fqwltg57emk2lprd7qzmapp22mv0h7", "gonka1m08n5646hjpavvmjfarad9kr9pxufe7sfy3v7e", "gonka1m0ftrwltdf7dntqhx9juwgadzyl2h4m3sm77zj", "gonka1m2alnnr0tcjj0a3k0jlhcr8zvykawa2uhm9lmw", "gonka1m2rsvln78rv2rt4m0ypvzmg6z9pm803nef55k9", "gonka1m2s8r88lj40thm3zkd0fc92sqk6wswhx8a2xyh", "gonka1m3hfvjy92ewcvykqkk69j7kgkhffwxw0n8q0an", "gonka1m4z5hf4v3hmmqajlg2yyfgzguq4h9c7y7c78fy", "gonka1m50khzaxc3pnhqpjgn8ptlv5ws5uhexnck5qht", "gonka1m5hsg3c5xzqpcvqndp4vwvjxaj5se6ur6ym6jj", "gonka1m5wrtd0ue2nevk0uqdju6jc3pnaxaz9hakuqnj", "gonka1m7df6745x0vr02pf2lr369vapfzddh3jxhawvq", "gonka1m7emdk4ez3dm6xmps9v28y8prreq7le58cppmk", "gonka1m8czp8f4z2qgtrfyzm3sa795l2vsxy0pqa47sj", "gonka1m8z74q6y6hcykh4t9s83l0qyt47lhdtx0wp4cy", "gonka1m9u4n8rthwr0j62j26zjg4a6d39lgut45yaz7x", "gonka1m9u9fzvxdk566azkzr2yja7u3m0fyzkd8n4c97", "gonka1mc59jg0j8exezfcv6lrgfyfrpzyehwtjvz5nju", "gonka1md534cgw67whyacx43e4z805frz40m3pjlrkyf", "gonka1md8zqldq84t3a7xerx0s6y6yx9pscnwg3r9z50", "gonka1mdpv608e3ft4mcky9mm9pjr5u6e9ge2mm36v32", "gonka1mecj5za64q5cnuu3vaey88g7kn996h2lv8aylu", "gonka1meqfrv7nzu3gxeuswveamctspyelu5lxlncaac", "gonka1meu25hanyk0es2rsefuy5fk5n5yupdya6caj5x", "gonka1mev8s38pz9u55jkg46ql6lw8xlsnvf4ggcefd2", "gonka1mfw9jretedxtulns6zxpfwk32f42h8chgukd9t", "gonka1mfxj2hdjlhaus0julkl042sque2krql745remr", "gonka1mgpldv4kd8r6dfw8lzxsx3zpwewvy9py5tteum", "gonka1mhmedjwqt6gsx8urpwehyhud5klxxra2r6cgy5", "gonka1mhrqx7w46uxvjmn4npqkh7mg4wuf0cnfr4zhyv", "gonka1mjjaep4d3vt9myh96zrslx6cet5qr0xvd9zqg3", "gonka1mklzy8yt48wkk7qrgz485dn995zkvfmjy29nfz", "gonka1mlxr8huxrdwguzp68wa602r8e42kylhcykp5xv", "gonka1mnhqt0x8pjcwvt37888umswrt2tgud0pfhpml9", "gonka1mq7nldjv9ulgj5m568asg9xee6cdr7mptjklew", "gonka1mqmvutyh7h87fgw6k246c4q5n0xjjfn3vmqupj", "gonka1mrshuuyxr9ae9h75lhq0fn6vdcw4lzc0g98nxx", "gonka1mssa34cgucqepx7u4mvfesycjfhknagryjrssv", "gonka1mt5aelfmzgs6a398kkfd5v8u684wpxcy7a69gz", "gonka1mupzp3sl80jtmwgy3r8cr0lmh9l5muwflzkylg", "gonka1mw6r7p04ntkkl0ml23x3fjamf6az60qjcky0ma", "gonka1mwwzgd5qztcjddg2pwej0xw8xywqr5l4san6ee", "gonka1mxa996t7rjsuj8l7g82qfwcgy5yed5ckf9lr5k", "gonka1mxn2p7c0y47syy58dqdmwwr66q77xgqmfdqhvq", "gonka1mxrgh0h6zjd54wzk50r5m9vzlmx8qcq42akfg8", "gonka1myu058axjs62mc3e7na9krwvqpfl9z3gtcw9es", "gonka1myzsl5ed5sa530fnx9fg0huejn75a4ktx8r5sn", "gonka1mzm99wp90edjnl7y9h4ua9x4e4ygvveyren8vh", "gonka1n0225yr8w7eqdsw3g4kz45vpnyajy69vv4z678", "gonka1n3m0gq42mgcrz8mkpz9vfxm2e4a74r0ftjcuj0", "gonka1n3qzf6c5djdymanrez4sm2artltls3z89mhfua", "gonka1n3xkj998f4q6lf62v7hw7r07jcwaer8xlmjrww", "gonka1n445fvvfh9x55uc872k463f8rd2dlp65qmfdng", "gonka1n5gsftqp7ez0tcvaxm5mpxjaw258hcp5zvr6tr", "gonka1n5r055hu5tr63rgqs7xg4d45ar8q6yy3qdhn04", "gonka1n5tq7jjmdznxnvfz06562hnqrphwvezkl2xt8m", "gonka1n6c0mmnmayt3vuny9lwak54kpsjgphzrtzmvdw", "gonka1n6nwmpa4x5yre0hcmk67lt5ntyk9f0fdupl83y", "gonka1n6uaty84yezgfcymndq75nmza8y8krt9j0czjm", "gonka1n80jruuunhn8q9scqkuqcvsq8dz3hv03zl6sjn", "gonka1n8cyaczhcly4vr7x84hatnfwdskjpqrtzvsemu", "gonka1n8fxs9k92q7z9r2mffcpwwejll583mkc4em2rj", "gonka1n8zcl8cmlf4606duwygssqq72dzlanrfsczlpv", "gonka1nad4h437q7zl6nmwvuxzh9g73vkm5cdymxvuqp", "gonka1nauzjd0ke0tw64zcn5xdc5jla95evspd0ezzc6", "gonka1nawpf3y2lpxfz2466300dg72act533jq8k5sjg", "gonka1naxe7nweppkcv5vmwf9v67annhgl0gprqrmvcl", "gonka1nccp3l8d8n36akvaper2ngzpe8a843key0n985", "gonka1ncfgx0yldqhfehj5v79te4x8sfftaxe7lk5g4s", "gonka1ncnqnsfj3ay5vwk6c35p4uxhalq0fqvdk8eq2h", "gonka1ndga0ugvxa975ftycq908hrscpcnt6enzvrzt8", "gonka1ndlfjnp5d7eruyrhjvn6uape3jp630qld7l9yl", "gonka1ndms0xza09rvl030rua4dwgv8rp8d5makflf5d", "gonka1nehrf67v0r9n6fuxv5ephwchwj4f59wt9wk202", "gonka1neug285zahkpplsfmgrhnkmjjwzalk3z88uekt", "gonka1nexpkweg8ed4axymsvhh0h54yf0axwxr9vumll", "gonka1nez52allmuwua7tnkycsnd6ptfg3xqlpdegza7", "gonka1nfammd4gwrde0jhn7w0tfu0228a5jfmst76t34", "gonka1nge0x24twxwvran6rh4qe56ckxk3ecmkrjhjf2", "gonka1njzjqpx6t4jwe9t0fu8vtzn5cj5xjlaussvctx", "gonka1nkedq5vefl0xlxf66cgpx5l6eldtjtr3e2q5sp", "gonka1nkjqnyhkn2grewtfhng5futkp6drjf9967jzhq", "gonka1nkmwp905ka4dzvuwvdaudgjj7yjk8h5aslfw73", "gonka1nl4vtgr88sy088djkxsknau5fwnx8akh3ppl6d", "gonka1nluanlq02cg8qrwyqn2qm2zf0mmlyqdevtf66a", "gonka1nm87fj75k9c8pt39h9v44nmwnusx6k6h9egnvk", "gonka1nnadfzm8peka8y8nxvhmdtzh4qwfsqfft8j50s", "gonka1npluqfku4cmccry4uhh0cpne6ez5x7df6pqh04", "gonka1npysyl7dwt3ynzryqgm8803rggm8y5tylaw5gp", "gonka1nq396dmfz2rntud8urt7ddyc7ysyg6rlax5vyc", "gonka1nqe4qqjq2yz44kyz74wmkwp0q0njryekd26kcg", "gonka1nsgfcyld8f754tl9eyr5n7yuqdezw94jfw28td", "gonka1ntlp35e8cyylh5fjmlzt0qvkhyjszsuwngd6ka", "gonka1ntsw9ufhpvzan82lhe496zhdqvfy9rptm6rr5s", "gonka1nu728kerfd6n0mzmudvv2fvgqh7x7euq8tuwkr", "gonka1nuhz5kqnmxs3dfd884hdv39kdy2854lff8ma8c", "gonka1nuykj8gr2e45w5dj9vj5qel6g3v0v2fxclwfgx", "gonka1nv3j3r9cq4x4uu80eg0g6ckawvgvs7uhnya7pu", "gonka1nv5twlr9sl69g650apxxe0h4vy7mw6y8cx9sha", "gonka1nv7pw7xpydpkhxs35zgu450ymhzmtck0aryhls", "gonka1nwp3vczfqa2jlrrkgqxd4ep4jkg2f2j8zlrjvk", "gonka1nx49hxjcu2ps3f6hya22226kwxplg6jlku7w02", "gonka1nxrltpfnrsv7rrreg2mx38d00z7v8repvqkara", "gonka1ny3p3wt53hmsngwktd4fc07semxn6yn3fv22tq", "gonka1p0jj3c80gtax49285au9jqvrgqdqedyxxgz596", "gonka1p209mlvngz8hu0p5ff7dsjzqhjpx4jzn6k652r", "gonka1p22v6ncqsys9fh85gdmkakpe24x2zqfyp60z5q", "gonka1p2959dx973hd57qsalxvesrcv649296x90ry76", "gonka1p2jkducv0vjd2a0dgyprw3dm047wn4tm3c8yks", "gonka1p2lhgng7tcqju7emk989s5fpdr7k2c3ek6h26m", "gonka1p2qdf5ka0r2kg4e56t2cdlyjuw93hsrrhvxhgy", "gonka1p2t9xrr5qs8xxx7rayy37tjh7pvl0x4sdgnd8h", "gonka1p33xuwsqagkdqgd70hzujr39aj90tplne03knp", "gonka1p36amfh75q5z65l9ganenncjzmz69xgjttvdwc", "gonka1p3jfqqnjuu20zyk5t5d9xhemys2z7zxrln5vv0", "gonka1p4epndztqtsdu0cemsvm3kae70ec6nr7snfcms", "gonka1p4gp7ff9dcagsefc23mwsuzxgney4uk4efwxfh", "gonka1p57jas3hm3gmdvh64z92ycr28z968j0fn6n6jd", "gonka1p6wekfevflq2h4rx9jekc86qaqa4ussw8legsd", "gonka1p8av4fdlefkwluhx864sw4h7nayytt6c7x9u43", "gonka1p8wl8gugrjcs46zhv087cqyr4weqxwyy6jl5z0", "gonka1p9zkutm98sur64hmjfr3yrxmqy4eaq70xmf8tt", "gonka1pa9djeznv9lveqqp46uunzn2azpvuwfjlja3ap", "gonka1pan0aps9t0tj0400y04pceppwwet552qk8l9ch", "gonka1paue8q0lckvlf3x8u6hcpww294pgg2rcywj0m8", "gonka1pavt7a7nqv2cek4f3mpgezqvj07et840st7a0n", "gonka1pazqpx9jyhfe87v6aqmqr5j62aadfx27dmwe5t", "gonka1pd3z8s9rs2actnayqgde077wnxyqn4w7g5cj0p", "gonka1pd4dw77pux8rz63v7wqeyx2nlun874e2l4ycve", "gonka1pdk0x9w50zsym389jlkhp6skdzx480m2p8ymvc", "gonka1pene3szj86frl9ndsajxkxwvgnn55l46m7jvj8", "gonka1pf4z32nqz5ax7zsxsmf4tan8wsnp957y9t4qtt", "gonka1pfgtn4aa7hy5jwxe5wfll8n4d5dmqgughpdu6s", "gonka1pfs6u98h406re70w9fpdnsjuad7xl7wpaflagq", "gonka1pfu9vgjcvrd9sdrkhg5jelky2kllcqnt4m2ekj", "gonka1pfv7nwekx9yt9wsn0zffv95wuqcqrlt6dvlx7r", "gonka1pj07u20jn9cx48r0jwen6evz7mrfj75t3argv4", "gonka1pj5hfsh0nk42satd225n9qg5pumedawtvrmqsd", "gonka1pjsg254jtuaz4rm9kq27nyplrp266x79mxffqw", "gonka1pks9m29wqac2kxdj8v8acq58rjshh6u8y2a772", "gonka1pl2kzr7gjl678m0ckw5cvmyu83ez2dvaxp0a5c", "gonka1pl2xyrfma445tlrjkzkc7wjmdgm5e0ala9gsfn", "gonka1pl3kdq9yxryppe0xgk6mr3g9s4sjaz4w68knuc", "gonka1pla6kzmj079jzaxdk9n3qrkjfdavuwcsmfqchs", "gonka1ppqspznyn94e87rxzhnnedc57y4r2hae2g3k6u", "gonka1pq5f5c4k8qn7k73qkzza460y435r3dusaxytys", "gonka1ps3z7eca0gpmtk6r26fkaydk35mdm4nefulvy6", "gonka1psl7we7z3cem3jpa5qxzrr7px8wu2grpcrcf0k", "gonka1pvfuygufq6u5qkeamedeqatmklxqy47k83xj3k", "gonka1pvkv59e72vju2h7s9j3ex62c5xneqey350vpwn", "gonka1pvmxfx2cy6s2d57tp98mklkkv83xnjjn6y96r4", "gonka1pwsyqpmm62ttedcs4y4we2v65pj4sgfqqvqzut", "gonka1pwumgsfldkzspvpun6rgty0evpz47l9mwa79v9", "gonka1pwyup7dmg7e2ftwx3wjltttuhyjnhcd5yztegg", "gonka1px9wxf6y3a5lerck88uhgfvajya4cvyhuk2cgf", "gonka1py2eckpy6nqu6uxnxzq8zdfwl533xewpca86sx", "gonka1py4j23jhz2nah9d8lqpxn2lq6e07lx6e6jmaym", "gonka1pyqaz5h238ddqmtrzq44yz48jgevkdtcv6y02q", "gonka1pytm8e4v7najun4glnym68f7vahycjn0998ruj", "gonka1pyvqmxs6rkv8sqpax42gkf9ffvlnqjcx0ht0va", "gonka1pyzywchfllyeydrx6pmahs4cw8zgtrs50kedez", "gonka1pzdzdgd3auppy7x8a73suxaucgjcutfevrwzjp", "gonka1pzeet74x2wvssdh9t24f258vz426ydu66pcr6f", "gonka1pzlxrm2dq3u2tafyhm20k32ffhtlxg3298tmdg", "gonka1pzspqqr05uep69y4pgmxx4upszqxkgnhpn88ds", "gonka1pzuq9ygxfrcp5e6qdzu2py5qgcw5gqvde7kt0t", "gonka1q0a3u8s2azydlu2s2902qxwfz8d7mkze4lf45f", "gonka1q2lycs67690trv65uzv5vj0fsrkqweyq5v9zz0", "gonka1q2z8yy5lj200k3xgk38cqqlnypkqxphu7gr4r3", "gonka1q4mexpvre73dwjaz93xuwwxgh5526pe2ps2eec", "gonka1q543ehua5w7fu5fksraapfdjqp3rdjm5g7696v", "gonka1q5lw358k7wp8twyxqn84seam6m50j95kylxahr", "gonka1q6l6jmvdpwzznzkg05na4a2v3xad5hgkgul547", "gonka1q6sd8xu4u4cy5sa73saj93ns37t02rggx69czl", "gonka1q6v5taltnxxzjrgpheu5t7pfjwmsu6x8gs24sw", "gonka1q8qrnq968kz2t3wwv7wv8tqmfgp0mt3fgxa552", "gonka1q96dv6st48490vtzx2pwuwkjg439dr4hg6dzjn", "gonka1q9aufvwxg7e36pr83ajfw9u2dtx9fh0de33zmv", "gonka1qak506qcusvn3cnn7rmezslzn3xns8mpm5qnuh", "gonka1qcamnqy86hqzcatvlgr78mvgmpcc25ms40pdj2", "gonka1qcwzjttnvmcrvgdprkh0n5s2jleny7yqcjl8l9", "gonka1qd7ey9vezh36fkefjc902p2d26k4wsfcvl7rru", "gonka1qdlfxf9gmveurlhc4wzw7xd3rsmseeqcrpre4s", "gonka1qe0fq7y0vm2sy0qhvtj0falnh07h4j994aexwz", "gonka1qenxp829ukclk079kjpmpdrtjqpacl3l3h4gyt", "gonka1qfp9x8jfax3uwq370saqd8ykr4h5uptqdp9qfw", "gonka1qhzauckmv78r9wpsr6lvjku5g70hmktgv2ku7d", "gonka1qjdt3qykdrka2am7s5rtrze44f7y8vccegjc70", "gonka1qjpz06uz5myq6dhww8dn9z522u8w8a5xndf9gx", "gonka1qk0gctucm7l3vvpxuauyw4d8pflxhxsfp868fm", "gonka1qlqjyqpmmq4r3fa8tfner44z78728z8ndkgvcc", "gonka1qlt90c4hxccgnuc478jaa3xl5klga84xzrvpda", "gonka1qm9xucadpgwzllmjmdydqkehvgzprpx2fcuf5n", "gonka1qmlkwzrpv5zkzzpgkthftd29uqg0ka8dddc290", "gonka1qmpm8tsynnfkqe9902dd6ny4lc5hvp8q7wkrpc", "gonka1qn23ufgpfs6vyg0jkx3pqpq2asp3m950wcexn0", "gonka1qnq7389z4fqu27ra2j6vq9uvsmyz5hv7p8x92c", "gonka1qnuvx76nfurfzxqhmksutx2zd8gy6x4gauhcxh", "gonka1qnx9zqkq3wfhqcqfvt7euq4n3ccldmpun2jsv7", "gonka1qpnjw7rpx0p8f7amyw3y72uv2kqh6f52ejs6hm", "gonka1qpnlvs4jffw8tye3ye8vas2sk9z9w48pcfrsj2", "gonka1qpu6rp5kpmw3zvsy5umf8hutsp2ju98zhpm4t5", "gonka1qpz3622ewmu42cu0l9gelga7wyet57m4pllwc9", "gonka1qq958073w4kcxlkrtcs8xz93sdexzu35c3tsnp", "gonka1qq9k4gn5kr57fzldudmggkztvuw3acek2j6yna", "gonka1qqfhl6lfsfrj7z3433cv0xjudeq6fm3yltvnmw", "gonka1qqpsxmrmk99lw0xaychamatvydd8uw49qw2pga", "gonka1qraf3edrgj8j0jmm9p709p8jver4kfa5qm2dlw", "gonka1qre9aepalndahwj37xrcepndmut2vu9dr3kh4t", "gonka1qrna7lsqy0r9aejpvzdrn683tfx34hg5cjv6ym", "gonka1qrzf7dyl8f87lyf894vc6a29w0ulx3wuzfa59n", "gonka1qsz5a04rzwq6vy7rskn55zpeffed744humh640", "gonka1qtd6sqrfhqlfzl5guvq4rh2jduayekf8sx7vze", "gonka1qtsymrl6f30lje0x3m6jkqrrggtundn6ldr3ah", "gonka1qu6wjjzrtrttcppmta7ddr3d7uxce9aqyu8n4n", "gonka1quxrzzy8dwhzpmsdql05nqdzj3u3n0syk4r6pr", "gonka1qvd85uwf4syuhenx53lexx6ru4grtqsrng7tp4", "gonka1qvpct2fqwpfqhznwjqs498ggp7wyxjkd4mvxhz", "gonka1qvxecjzvf98wj2p0cemkxja9k7rphdhc3d476e", "gonka1qvzmfwlcx663f6klq9050h0hs7neacy6ltyt0s", "gonka1qx3stahnpknaf8lq0kzdtedtxmq965hj9tp0jv", "gonka1qx3znmtpxqgmz3t4tgpdk68dsfxuccn6cxnp8s", "gonka1qxy42sc078ut52ws06nsa5fyzcfjyx7a56lw84", "gonka1qy72uqasgd00un7qwexvfdl4zzy8ejaqj2zkqc", "gonka1qygkrhu964zy4r2t9fmlz8fe0q7s0nujw9hvu8", "gonka1qyw37eedekdrhu9937k2ewvh5ql99qlmsv3nj4", "gonka1qz3hjsvpp8r0hg6j7q8nz3f68hyzpytucydkuv", "gonka1qzmhx83xnamk0uqup3lxpf2te9karrwjm9cjh7", "gonka1r288zwzcvw87qeyk7tdwe29nux2s4wxzustuk8", "gonka1r34p353cxrvxf3x29raz0x8axflen82a04env4", "gonka1r370qpenltv0usrdmn0huqytahmv3ns6uvw604", "gonka1r4cynx8smndx0vc3j8h0x8ld8h9wyzzs73cxye", "gonka1r4d99td5fx5lwvqv5zu5zg4rnjrsm6587lk568", "gonka1r4qetzmw4g3aenwtcxpdm6l42aeq5gzwqltn39", "gonka1r4x3f3pf7ttzqah5d5kqjdd62t8upz8gyj42ff", "gonka1r4zuhduduwqzyw4a5y5y5aw57sj9jl56qpp7pk", "gonka1r6m6ns0rzfwtsrunuzplfweq95xz0alpz6f044", "gonka1r6zt565kkkc8mfq94vpntyflzv6htpxy2gl2j7", "gonka1r9u4nyprt7ym64pdea4a7wpjf446c0zsmphqx9", "gonka1rc6f9ejjzjkmvhs7seztw0208yj206llspmcwf", "gonka1rcpc45n6zch9qlkn4m3cwngekad89xu8mcr09v", "gonka1rd09mzfck3m3nfz3mhmlt6ker6ru2dg2ryhwkx", "gonka1rdarkrtrfnfcvrnf58jyndccqj0r4k630n38rh", "gonka1re75gjhf3ha0xj8mtm9f9xpej2f9ksmhere8ck", "gonka1rfct5dqgxrcx9p4gwdkv984y9k0utduepxgwg0", "gonka1rfkzg8gqf85lszf65zzavztmdzfty9gparsnkx", "gonka1rh4y6gz308k4m2kafa3964gdq4hayn84lqynpv", "gonka1rhswewu6mczgme9p87uwtyufu3px3t8vksn22c", "gonka1rjajg99qfa352rh9km32mvlhs4jhvt05zjtntw", "gonka1rjaw2x7hmdws0s4tln27tsuu333l9uacrg3s69", "gonka1rjqmetyjpjx5ygpe9w26phyf3gs3wjfxdpq3uv", "gonka1rk43zfsxe7tefa88qh3t7wl3dvjwn3hq22njc4", "gonka1rky3uprhdgs3pkzdtctkgzrw0gqyy004e7w0je", "gonka1rl0dfaks4au0ggnq25f77m8js7pztamlfcupsr", "gonka1rlf0ggajudsvxuvgkukpmg2xwd06htv4vu2ktx", "gonka1rlma7sepz2p459gh4a7l4e7qtt82g49aet6kj5", "gonka1rlz8rsu3snzcfj9953vy4rtufpux94hg3ce63t", "gonka1rmr4x8lyw76gzuyzta68gj965zfa00gzh2aszz", "gonka1rn5jll76utekvhjaxpqa4mwap3twnknnd6fv0c", "gonka1rn5nud8367cnspgas0dmtq2plxkacjsttqtdy8", "gonka1rn628v6aw5tpm27a0atu38t5s7vf2upd2453jx", "gonka1rnpdd6l0nwnn3remldkdpf2t959jlz0cedzu3c", "gonka1rp8zq302zzkjrxf7and6u2c27qhjsdj2fqmd9t", "gonka1rpedugp4rhy989wfg8tr5ux7k6d4fhkjlqk234", "gonka1rpf7xk4nkk4qzn4wd373a74rdc8wja79kzxmra", "gonka1rpszx3te4396yyplpl7lmcqngcwtk5vw0t57ym", "gonka1rq2xnnkkj2qfpxgc3cgpr7klxdeph42ldh9fp3", "gonka1rq3skz3zfawkh7qsnjyzy9r3wf0xq8at096wy7", "gonka1rqjuqpzpkqpzmjnknzurgnlvgwas9qd8r9hylz", "gonka1rrmf3s6m7rh3plqn0xam5c38xsl9wwvrtjzr48", "gonka1rs07h66nfduhnf5qg7u968zqumragmmacuand8", "gonka1rss07hzdm9d3y45fg3s3rnxjgzs26yt0h7khs6", "gonka1rsu02ssu7kugt563ztkqjqshrp9smkfnn97ufn", "gonka1rt963v04mgt43ju2smuakde99pv7wscy5yxnte", "gonka1rtpd6uex2w3mm7kqwf24acnwlm9hvua07kc7ef", "gonka1rttgfl6t876cjye384e5nkkff5dvr5l6lfw45k", "gonka1rtylvt6ylcdphuez6eqerj7d7pv7dc3kh6yvzc", "gonka1rv075f7vue9kvpzm2hnuup94ca53ny8pnmq0e8", "gonka1rvjfqzm8spt5nfq84jvfdr8we8pgkv8ent08s5", "gonka1rvnehahwukcckaeu209jqszkvsztjwmfh2zakj", "gonka1rxlj5kufnplyw8h64aem6cjey43mzryc02mnl7", "gonka1rxzxtj3hjhe7nu4gym4ude3nxnlmya4zmssuey", "gonka1ryh8696kkgmkc5j8g2xynryquvlgelus3vkld4", "gonka1rzchltn9xn5ysur4c6x89xvtuuddzccvt8zqrw", "gonka1rzw2qaa3erwls8mvxyv4kqwhdgjxlg47stzy5e", "gonka1s0edjm47rt4qmg23w6u72fwjwqechkg4pucd2j", "gonka1s0hm7zhcw2ms89g2s8lsfr9s02d88yfph9p75v", "gonka1s2g8xn479mvyqjgm43gpnzsaqakghh22a96my9", "gonka1s3d6rz3eugu45k30vyddmgqjtnzpvnrxhr56kf", "gonka1s49nsfqljwk8er0h8ph720yw9u6u77hqsh8g79", "gonka1s4f6kxgd69gvsqdyk23lrdwtt4aj53j3uqfyvh", "gonka1s57kc5supfau8hms3kzknxnlhunvzve2rvuh8x", "gonka1s5997zeltdrwfc35pzzzznhk3908valhlnc76g", "gonka1s5vtmnn8tqvqfh7gd9hv48kkt2t4mkh7s85zh6", "gonka1s5ysllxfjd9gglayqe3zpqfzsr4juq9ztzr78a", "gonka1s70twnw42wx7x9729ln244lpjyye6z3nycuyqe", "gonka1s765hq8kapmu8xjhuh3hqzser3y83mcs39x3la", "gonka1s7ceynxf9l79lp6ju87hcjwwwwgdazjuvapeqk", "gonka1s99ftlh7rjncegja96yrx9j5z63naz7w4zft70", "gonka1s9av3zym9dde3qf4x4rvava3g6g9vhy8husgu3", "gonka1s9far3deerxzusyma4muy797w7g4tzwgkymtz7", "gonka1s9sd0uj3clwfssgg6l3c9s7mclq02r22uhw06t", "gonka1salznr2vz0mp6nk3u3tuzuq44xeq8fx5fhx0k0", "gonka1scl6c3zk73p920m83r2lndljprz68rjepez6u3", "gonka1sd4u7pzjm59jskaeqjsw3srjgqx8rzyxsxwj2y", "gonka1ses84s2nylyjldfdptynyhvqxe3df70k363tcf", "gonka1sfp2hzdx0g6fvhfsp4quvsj8kj0r6792ehw8r7", "gonka1sgxwsdxm34x4ukexkpr0zkmjk462rgcca8nttd", "gonka1shc0ywxd993zz3w3h5xdp5uhgu9rv27ws7mmqx", "gonka1shuyt6kd7lqqfeuyznut78wd0n825h3p45skuw", "gonka1skdtv4vlkwgcnqel2e48vvquhp40mq83m2yjl7", "gonka1skf6lv8rwvugww5tap9sfuhxzkw27g6zsz8wy6", "gonka1slnscxc26qm7vvpn5qs9yzq9n0l82r4ywkl054", "gonka1smjq2hmma0c42rvf4epkp6tgfpy5z9cqzp3kqd", "gonka1sn2fuds6qh5dhrdp7afdyepmr6lcpwvsuwzlye", "gonka1snq0m4rdvq0sswm03r5jsmtzw3p384qsy3l4t4", "gonka1sqf3t5jdjfhszwq4t69nfzmnwghhfqlcr8rpjl", "gonka1sqtypxgdekav0n20etf827t4s7zft4v3xur9t5", "gonka1sr4nurfqkl7m5y5hyt04260vsnw3ql9t536nl6", "gonka1srer0flyzeqxfeh0zypl6dgn2cuym3zpskp7f4", "gonka1sreuf8vldaxyr29p0hs0ftjsvjjafh0n2ujx60", "gonka1ss0rvvm282vdj4e9nd8axacenvkghu4dh5j8je", "gonka1sskwvat6wk6sdjjg87ne2nhexdyznxntu07vzh", "gonka1sslsmuwg5q4dxzx60w5a0aqn7m6u6ceqcmqehv", "gonka1sszyf9vva7xvyk84fnc7zwk0gde3avrhstp8yq", "gonka1strn82prjujtuh0dkpt024a4j49qgf37dq83dn", "gonka1sugc6alxu3clxa705sqy7tvk4glup3v3pwndvr", "gonka1sun7e0re84mjf79c6euqp9v4jeujgz2x25w4e9", "gonka1svynlfqqsxzuxfm67lgy986438h6l2u8tz4clj", "gonka1sw7d7r42hqwgxz4ln2x4p4pjqxgejwqnxxzj3f", "gonka1sxgpt7r5tv82g9kffldvrn0aehk4ccj0ezvy0e", "gonka1sxyyrpqzm0d3fvy9m2a39f28fszfpkwjhpw9wm", "gonka1sy673yew46jqh7c7h77qt0sq32ryjwrkmy66tf", "gonka1szk5zjwpx7lzq4phdnqepdyfkf7hnmvh8lawdt", "gonka1szy8cukyys4f8m5utxcv46t4czh3yw3rztjsmv", "gonka1t034d3fnvrxrdf36cauyt6w7ztye4ym49n8a3x", "gonka1t0d30xr8ec56xj2ndj0885aa6mh58nsxg5dlk5", "gonka1t0gevkpnxe8000ke344zuhf5ljwefmdxnfzp0g", "gonka1t4jkhfkwexdz6rm95rdd9qg2905uwd59jc7yyt", "gonka1t4wzh95nlm3gge0seejpz24fu4h5fyv04lsdw4", "gonka1t4xds4ltl85hyj025aksrvpuqrwfgmvxv9nwz5", "gonka1t4xjvjtrr6fkw50d0mqz93004jh52x62apdlqj", "gonka1t5tzkq2tpvcanfu6x9ffpycljcn24ggwj4fw6v", "gonka1t6yxxjy444nphftd4u3nwjnvmujpn4d9prcxp7", "gonka1t88kkvnrayz5l2u043tccd2pks4rt8y346z9dv", "gonka1t8amxundxmtlz8wgns08mcrvkgpzsunlcl4qs9", "gonka1t8jjpaq2m0svru73kh9l0m62e7lr7qxxw6uvea", "gonka1t8r67ncy50g23sz5xlal9hahnq72ej25jd0nrt", "gonka1t8wz4w0cfe84nggqqx7xzl7tf0cm7pyf8jumxd", "gonka1t8x0m85qvyfzvyevwrj2m28ytf6w3kmlf5r7ez", "gonka1t9dcjtppgqc9hn209tamezl6wzl5csxfx6xuwv", "gonka1t9mr68j8qlyks0tnyjvtmxtzdpa6s3qr0lz36u", "gonka1t9pfwfag57kxmf3kyt088la4d8f892v24jvsf5", "gonka1ta39vdtx4qmlwpvmpjyajn5yulflf0ye2nu4m4", "gonka1tc0qx8n79jnslhu8mz8xvmtxej2ctmsqvumyej", "gonka1tc76r4jum9pahk2xyzp424rvn62axmkxk5h8lc", "gonka1tcgqp32zkz42k44vj4u9atvq5y0n4l4mjux53q", "gonka1td5sty9kpz50j0yglnlsqndrpdr62wfmv2hup3", "gonka1tedle92e0fc5ax2u8ct2a674ss07vwaf3tc8ma", "gonka1tg2rut7rcqnyap8pevhl8u3avtzyj96eqcwmcx", "gonka1tg7ytm94dnfjcm3r6rs7kadukfg8makqztxm9n", "gonka1tgeac8xh3amg04pajgwuv8hqea5g3dywl9r5qr", "gonka1tghcjejxe3uwfpc7s2lnjxfcd0lt8chcemurjy", "gonka1tgtsqayddf96dwxry4mnu5qy0ae377q8few3cp", "gonka1thdyumjevc50uf822fzk6ypmychmvsdqu6wnnz", "gonka1thk7297f234mzc7nhuklphgfd9xnnzfh09j79j", "gonka1tml58t8c87c65amrqee5rpurmlskr9v9p3de62", "gonka1tnetdyn52684nzr3glttfayvurl594vwlysl43", "gonka1tnns8g0n55yn53wd4l9qqf753vt7p2kjkdw5cn", "gonka1tnv2unfr9g7w7qcmecvyhr29anj2ah2dhzgrhd", "gonka1tpvcpcmmqcku5g53tv2q4wehgqw3nmeq3jk4vn", "gonka1tqr0yuykhd4j4wgzdzng46rd22c9jlfuxkz238", "gonka1trg07y6w7egkk52m9thep7gzedt60n325smlgk", "gonka1trz6e3rczlp4ma749v8zk6xng9jmcnrvnwv4rh", "gonka1tsw2k68zfr772nlg57dxwyyrurrdd3wtwvq3u3", "gonka1tvcxz7z6gr2wnkpfnrndjdt2dxzfd6tvm4tjly", "gonka1tvgem50n2xna9apg29wm0ts5rjmjxj0zv23t69", "gonka1tvjdvlf3jmc48ckycguvdvlepgj7jgx9q5m2aw", "gonka1twd7gt8899knlrd5rnr5ezk0cf8z6sp97tj6xj", "gonka1tx980hp394dfn80rut6gr3j5yujz7wdl08dups", "gonka1txc39uylflnjry3lqtl7uldm7fj5nlmgwaxqv2", "gonka1txht3m05p620r07ns5xypelpu707nmyvk8gxqw", "gonka1txqr3q55gup8vvhdxvx4vxvkf5ta8wv5mchcln", "gonka1ty4lrqv892cl69p7ktvnnmtuqz4f3flujdz9em", "gonka1tyl3kfk00ufamxgtpw3ck2dtr070pjhv9f9s32", "gonka1tz5jnxtllr28c08uazvr0xhzcl5rff6g86x7w4", "gonka1tz87rwumutt9rfvwh7m7e6klrenvm0l6mgazk6", "gonka1tzgv28x96g2lk8ajwvc3sd3s6xwsrslh5q5t0k", "gonka1u0xx46n03fh6cek0c6y79jv6207vqlaxv6yd9p", "gonka1u0yexj65qvc53paqeqajxu2tw5my9r305q5c60", "gonka1u2g98h3hwphu278djwh4zwdqpumvzyu56znz5e", "gonka1u3fzjf6qlfw2jehuy47yvlpsm4yjlzhemz0sen", "gonka1u3xqm25tyxumlqmm9wm8wn27jf8e40v5x7fles", "gonka1u3yj987rh628jzpfg89xzh8j5d6ru9ckm3vky4", "gonka1u4gtnwh0hvzlyvran3l7my7hr883ej367ed80r", "gonka1u4zxypjgcr8khlzefwjr0vwdaj2uzruw2cehj3", "gonka1u5t8ue2699e9z92kytnxys2l0eehywsxeqvnnx", "gonka1u60q4n3ymcglvhglylchpyvc04kvvurl967mgk", "gonka1u6sz4hrvlsu9y4ldzndrm6w64jrfd6h3sn93qg", "gonka1u7l9jg4krgl8kpu9lc2ml8hscjhmyrgtv6nd2q", "gonka1u7m697urr3uuvh9vh509lfwdeg9f7ddj2ad5qz", "gonka1u7pmx5k2s0fj37pge77vxyt2qn4ja8jjsgkl3d", "gonka1u88dwqlx6ew6mhg0pp3wtjaf9d590w2z8706cu", "gonka1u894qk409f4rt7fta590n7fu6szsu6s8nqq0dj", "gonka1u9832k7znn5k4an7a9ad8nmej0jswc7ep20q3n", "gonka1uae244rrrhj5pd27me4x2xj8kp34m7am9r5qkv", "gonka1uazclgk2ejcz3ygg04pgzeh7upzj99ja594a2d", "gonka1uckzfka6a2lqrdwefclqxp3unlzx7fen8xx62u", "gonka1udx48lyqzrc2ygpkzjq6wthh3ejm6x5cytvxjh", "gonka1ue804vhgmwscwd4j4xrq0n773c9kalfz876k3f", "gonka1uf85kdk97p45cazueu0jmyxyd5h63c3glwnnug", "gonka1uflg48g2lea8ufhz0s924vyz9cg3sh38uwnplq", "gonka1ug0hps56zsaw8ahtc0kvlt0v5xlac6zyn86hq6", "gonka1uggvat72uxf2ce9ljau8aqe8r7c2x8vdyyywfw", "gonka1uhztm53hju3x5u6fnzxw0zj8fafdt4u6flnm82", "gonka1ujfwdfe0tq667vt5sz2pus524zpjveedp4tkj2", "gonka1ujnc662v6g69jm6fgxnr79a2m7ehzeut059239", "gonka1ujskhylfq7xqzvanuy90fm640zf459x0qtgtxy", "gonka1uk73fw4tnfv9rfdeekxycvt0v8cncr64syejra", "gonka1ukyxxl5lc2srm7vagm4lvu94eyjuu3k47k0zzg", "gonka1uml7pt09fremdt28c6ytsdxnvsnup8j9rthcud", "gonka1un2c9f66mg2g6xcpmulq9tqfs3vjd7nn0ftjs5", "gonka1unmxpx98c6zrxcetzzqdrvsfcs00e89kl64jq2", "gonka1up0vsdrqerqg2fehpqcyyqclq209rr7l7fr7fv", "gonka1upjdf9mn6dcafsks5fjwlenvsac0udcned7f42", "gonka1upkmkts5wxa9ashk6hqtwvsw8x6em8stmjpu0l", "gonka1uqekt59wsnqj40ay40pndush83ngwf4vpyvm5c", "gonka1uqy4k39f35m923pdd2kyy20xc4hwyjup8sk5ek", "gonka1urf86dzpmgx44afh32ug7yy3x6hw86gpm9te00", "gonka1usa7alwmkwrvsu22fg4p8k2ftan35glprkkx4z", "gonka1usnmdjdt2xfzyl9xll67mna8teupacwt0gx2yt", "gonka1ut2k5s0jgnwx09nrkzvuprcd58m3afumcv87jm", "gonka1ut2pkphww74zzeyadhs7u7s6k9rrcmfrnzd6y6", "gonka1uuf3jr427y6hhx00nuk4g930vmyvjeesp84u6z", "gonka1uumdyg9wqd4y0tp4kmqk855fzhyur9vrpq54m2", "gonka1uup559m63mjcq6wyewff2su0e2wv5lsyyrcrll", "gonka1uv8lw89ththtj05c54wehfnqls9u2pza53q33z", "gonka1uw0kpk6hcmm0sh05l27sq6m5max7pg0n2ptsuk", "gonka1uwf8ce2knja6az8x6l2fawxh0yx0pz68n7pk7c", "gonka1uwknfekug2ykhygjpfy5n7uc8l6naxz267dgsw", "gonka1ux4gjvk07z6utgjqs3ttwk9lzr4cn7y0225n57", "gonka1ux86q8cgnpvkal497xag8p04ds2u2v23qxawv6", "gonka1uym5ugewtkwpcjs48f68uda3x2xjthmtatf7s9", "gonka1uz0cqpsgm8p2309exw04es8ddymaxh4sjlkvds", "gonka1uzseyfxgfu5zyp6kmsxdxuc8v0dsut9u7l8q3a", "gonka1v075hwqssfhg9puu05wff4chj43tene34m69z4", "gonka1v0td7x4ndxhveg50vzp6nkz4s25qy2wpvrxm32", "gonka1v0uvvhrxje6zqeyqqransjulw8h6wfkhmut5s2", "gonka1v425qs8gxupjcw3lqx5fsldtve88vd9gaa7r60", "gonka1v4h2k3xevzud35pvmfteqgt3wvqv9juazgpc5g", "gonka1v5dx7wtagjs428wks2fhhelgk5lvrv3a2kfzpk", "gonka1v5ggga7lslfg2e57m9anxud40v2s4t9dw8yj68", "gonka1v5k8fqqfc0v798gm8svcv6tczppvegsetw4mfc", "gonka1v765pascdp3v6qqtpdrcqm8qwdwq4hxa85gu5z", "gonka1v7n6p2ahk3crq72ml03s2atxx54tslm05ljegr", "gonka1v7vp7n3c4rw6qs6v3fxz2xqzvc3evq78uj3s78", "gonka1v88x0ss42fayta52dne50em0ys78thx596s973", "gonka1v8z57yg47n8h4zveyj4cdpn0ll8k9zpcm7egkv", "gonka1v9470ud6z8qugz4h8l9fzpm7r0zpus59dmm49c", "gonka1v98ujdeqleke9t9hu3uwlj2fnl4w7eajuf807e", "gonka1v9j2m8kax0a2fl8wr07nwwhnvz9n4gh9hfwkmu", "gonka1van8gsjadpp390wn9dn3uk785amv8plervrrz7", "gonka1vc5fdc8hdy0mkga5x9qzkrv0qnnvsdckzxf52l", "gonka1vc7zlu79yqzcwnx2rj0nhnn9nwqr90sfj7ek7z", "gonka1vcxtkr3ysjuscvfx96u36rqlqydzvtw8jkkzjc", "gonka1vdw6tst3lelc84garssnnjzx7fjpkja2wzpxe8", "gonka1vfafh4jq674227q8j0h33fwz4jmgtxmp4vsd93", "gonka1vh0gcrqj87qjaj4w9gumlvgn6kukj0507tr7g6", "gonka1vhg44vzedv5dzp8njajh8rtylxsctqr2xv5v6s", "gonka1vhph86z8s64n9fy59cqnyueudjaavce4tn6uj2", "gonka1vhsq90aynmx9dh5crfa2jpaps8pnw0t7rpnle5", "gonka1vja7resa43dh09kcz8yphnl2ntzt03z7wcu5z8", "gonka1vjshzxh3sfam2xh0f7vzz4klrv5pkq4zutk8qt", "gonka1vkafyzr5yz5aht6gzapw6lc52h5wwmnrjwvqlz", "gonka1vkejpc23506fhl08smlc6a0vhlkyvqf58mw80t", "gonka1vkf44mhxmf8tnsd8naffgkcklgm2sc4egpw3xc", "gonka1vkh8e2uqk9mdw0ql83g0p4ge0wmqstcasulngn", "gonka1vlcd8tr2nh5x6h4wl9vacpzucpp9a2p9rv8c57", "gonka1vm7kk386cn065gxu4jxgssjr26lrptrveavdfy", "gonka1vmhd38lxl68lm76755u4xdxp5wqm646a2hasze", "gonka1vmksq2lcutx2s7ue6eaurejam98f2lqgqv5rj6", "gonka1vmwqf4mkl4ucqnrgjmnsl694hktepaecuvvyz0", "gonka1vn6hk34wme5xvqzjmm26u9snkxg7nqd490gmwq", "gonka1vnmmnq4x9f7d3kume6xq2fh8x3mdye25gclzln", "gonka1vnqkfvynhyth9j0vv7zkj97czexn9lx3yv9ea2", "gonka1vp9m8e9yw6yky45fkcekspx9u3useaj0aa37qn", "gonka1vqxu2rx9s0l7zf8gyuty2wg2cm2vk2zdgse5nn", "gonka1vr2kemnagr3lhqhnxxz8rknxecwujxh0znljul", "gonka1vrrsqx454f04dmadju83dps8742lh0klrjq05n", "gonka1vs26xk4zvv6dv56j8r9ns7wzk6s00p8etk7wu7", "gonka1vtq7skdleemwn3vzh9xlt7x29a2s8ykedcc5e5", "gonka1vttxzd68fur26l9lew5netz6wxnx7hmmzdkqrn", "gonka1vtzh9e6m2ypwms3m28mt0y8d8x6xf927lkva5m", "gonka1vumgvuv4ln4s0kjlxj2zmu09s6k233096pemp4", "gonka1vur7jr3m5s66k28zd4dpxd4zn28qk3mwdqccgl", "gonka1vwmvfhguwdwz8987waanh69zvyxe5cdtkvqqx6", "gonka1vwp26f092nhg8dpfgma63ayp8xuyzh3xz34cyq", "gonka1vwsp87trl60t4g67fa677k7d7jztuc3g4qjc3w", "gonka1vxfdzcjvxxrwsj99tz09h3k88lxwk0xmfqx4t7", "gonka1vxmmas5zkp4pee0rkv9dsy54pugy7ln3fas68n", "gonka1vxs4azxcym36wts0t7z5nj65ma8pnkvpmywxa0", "gonka1vy396smh98ak3ts4zlthjnsv2ypr845mrfz7x5", "gonka1vz2ygndntgjw2nyrqgehd4sayw64pz26tvw7qt", "gonka1w0tchrxx49gfc0n8jua94pav7tw0l5hrhuzywl", "gonka1w0vl46tr786vdtgtk5fyadnsqtl8pyc8cf7txy", "gonka1w2dtrs7thx2jfeu389ztwc38h0nd4pv2hl7xtp", "gonka1w2pxkv4v6r5h6sdvges287l2g5rsd3r4x77080", "gonka1w3ewq7swwdxx8fsht8tl250f7qv44edhlltrh8", "gonka1w3r6sjxjaxj8y4gd5z6dt9levdjhsmhzfj3l7k", "gonka1w4u0ylrw5sl7nczl52vfjzz8ccvgaltrnejklc", "gonka1w50e3hn86mt8gmaknecnr4mez0j94vlw04lcjq", "gonka1w59gydgpkexrtuhjzvq7ms4fk87a52yfkaxlzu", "gonka1w5r9hazcw30ykc88m9wtwqfc0hvtyyfl0eyt75", "gonka1w6439pku8l32dzxrvy73y6t85jf8azfet7ulnf", "gonka1w6cjf08fgm3yalqf7ytt0hz6thlhs53d2fn7j2", "gonka1w6kt2aj02du25kuc9wsza94h9l7exa0uf64fjq", "gonka1w6wwv3wq25p8qge4lqsnfzs8lsd3s8ty6au65p", "gonka1w9zuag3atlsc4e5twyk3dklngf00uqszswxfv6", "gonka1wavv3jgx6d035nz79an2zwukltsa5jmmvg78v7", "gonka1wcqxjxzjsfwvaxl3l24qzemjlf0e8nextxhv8j", "gonka1wcxzxzhwjqzdr3uv6ej73ewxs0zw6dcnxvnr8e", "gonka1wd0evpm3u4ugfsr6vsr2jsdfqqmy57pw03l444", "gonka1wevtku4rm50m9jy6zgzvaxxu2xcx4kxmlz6rxw", "gonka1weya2e3ghtymyq2euv98nezgdmu4cuym6jqhwx", "gonka1wffadfyz0m0r8rrkgkzqvwq3h60z58t90v2vx7", "gonka1wg894suuxx088yaw6etlh273y0fk946ygl8srz", "gonka1wj8cnrcagjty98wplk3mxas4cxvyde9w446mzd", "gonka1wjxkarkm69harhu6h77n56slpqmjg6ygarf4tl", "gonka1wmkuw2aseh8txs47nl9ja4ydj3zex3n0s6wlt4", "gonka1wmqlm0yg3fd07ala8kss83wugraqfxxupptlzn", "gonka1wmxautv27705qfsaeh0k7ln3zpzr7ms70uhmsz", "gonka1wn59zuv2uu5yrtgy6jj3l7gqfpn25u4pyvm8gt", "gonka1wn5t79a8vl7pe90xndxe5rj4uqsntwqa2k8950", "gonka1wncyr3fhv2nddh55ul3sp6mae9m3hhs6uw6e56", "gonka1wnhd4uqvf3k38av7m9s3ssdzu0kvqskmes69gu", "gonka1wp5awdtgf8dvrnc8zz7x8nen7wra32qerr72l5", "gonka1wpan224906ant68frjd8vqreaxr87hudy2wvd9", "gonka1wpar5p0kmn5cwwn5awzjeycgt6rkr58723fttn", "gonka1wpg4enqr88smt8ms2afy6tnhvu84nkrj6nw78s", "gonka1wqdugevdn7ncdn37dtgusez48hqllat3f2npqp", "gonka1wrcr9gxu2r94chjsuk3wpcqefsv7ts0rnc94ve", "gonka1wsnawnqxnaly69zyjy0q54um7lws2a0h0p5g7d", "gonka1wssxah2n99y3rk8trnhhrlmfnjvctmzxqdlfc3", "gonka1wtdclwuqzkftgvewyy5eespzfmhvsd72aw4vae", "gonka1wtgcg5283mptdanvhc5xx9njxp4jkr7e6d6kh3", "gonka1wtncy6s3pl243sq3c4u4ketlktu89332mq8sxw", "gonka1wudxqp62tjpjgzacss8wfwt80a7yqpjzgagtqf", "gonka1wus9fvrxvx6sls623tme6rfgznu0l2myxm0k7z", "gonka1wv3xjmltywfzrw26cwr77y95ctktf2kqz47nqe", "gonka1wwelvfqawyqe3c8m4jyrusza2ey9qqvmwc2062", "gonka1wwx6nhqe7xlyvqjs0r3wj767xaurcucvz0npmn", "gonka1wxhqy4g2r3yz0aa0dhyswvgp2qqmzlp8a7vysw", "gonka1wxzy4uh88gxl08gwyw4l2cq6gmkjjq4yvv946r", "gonka1wyhnm2w3hpah5kfyjc0jnha4mcdfwuukr36k96", "gonka1wzcaq4kph5et8hrjhjrg65s95eslz7zpzulsud", "gonka1wzf9qqfnw6h7ddnf6hg2veje730qj94pqexfz4", "gonka1x2lalvrn6cucvzwfcd5cwwhggfuxqckw8k0zrq", "gonka1x2qapwtlprmlcxrdtvrskswuznn8v29r4se5tc", "gonka1x2vld9c33f8p67nrm9lf3p797qsyh0mpjle8l8", "gonka1x3e7306tdw22td8x7kmesnu5e4s5shcl6yqhyn", "gonka1x3fx4lv49xhjkdc4wqpshulawu0wj7tx4a4ms9", "gonka1x3wd5ypslj50nk9cvs72e3re9mfcdpcqwhnulj", "gonka1x3z0cpfmt366qy2jqpjptfhd8epsp0tcsq2n7u", "gonka1x45wvrqz4vy02hewle9fuwh8a8lc7fnhd8k0yf", "gonka1x4rmvlzx6yrxdl74242nmxh0575jnxf5nvm25f", "gonka1x4wafrl70272pzg3897zzefexwtmeuyar7tsll", "gonka1x4zre05983hdlasvgg37tw9ga2wy2l8mmellf0", "gonka1x5qf8s2u5hsyyvvk79sr3w4cv0wakkr9atprm2", "gonka1x5vauttk3el3f9xqy80zz6ggty7l4kkll276lu", "gonka1x8pupvvcgcn00kguy9umycj98qgqehwlxt6l93", "gonka1x8rea443t8qgrrvqgf7rhxv5s3ujvqcgs8udg4", "gonka1x9qndq86jt6x8r5pqx4hlx92rl0x3qu2hn2d3r", "gonka1xa0h9g6tdg3gntu7t2vdk48fsca8qlxyp6c7zf", "gonka1xaqsz52keh4td77z5g792kq5f2yqkukdvzmvyf", "gonka1xarpggza7rzp23srr85g2dedhxz2w8qlltv63w", "gonka1xayazzcc4twv6gelka9duhjl8c6kv3pl9gx2ql", "gonka1xccz7s9k0mhys2uuyaqjsnn2wm90uv3lrh7s4r", "gonka1xcjc32p5g72gc4tjxsm890star2l7w2g8n67w6", "gonka1xcu3jzaecelnnjhsjshrrgmqwlfqf7r6t8tfvn", "gonka1xcvj6xlqy7p7fzyne5jqrnz96fa4xfh35vymwt", "gonka1xdx6tywcwjj74hmyxdr7v9mexg58zp7scuwumn", "gonka1xec9u9kczf7jckvtxgalghsfcnk938h2ng9flq", "gonka1xeura290zggxuy5p2u70dtcs0crhgycjf3sxm0", "gonka1xg25gmn8uzeyzqqrchx6mfz379mvg43zsvj0y3", "gonka1xg7n297px8hnfva8trvza3t37qcm33jlz4nflq", "gonka1xghj8y0y49c74cpjyzel7r3r0uxaz685gue663", "gonka1xh09vkepgdwgdrarzqkcwnmu7yh4na2mag0xdu", "gonka1xh4w0uz432gtrjvfeqmtenkscqla3fzl5lvyyc", "gonka1xjzevenwugx3g05aa5jp3f78775ewcv8ya0j4j", "gonka1xk4mz0avlmvzser49tfrcgsjglq4a8u05j55p6", "gonka1xkk2g9t0t7euahr5wtjerv7tng3pnrcl0h3gcz", "gonka1xkk6nrxhlty9nt3yj80m4c3hsu962rjn2wmstc", "gonka1xkl9gxtjcde5rhhsqjch92m0xccwp6rh67k4hp", "gonka1xl56zt2c2ahfuk0u68x084avulmth95lptx9cs", "gonka1xlhf46rtwrnulfhzzwldqltynsyk22pesyva5l", "gonka1xlvxvzec4n4xn8mjyj88jrg7zlkmfqy9uglucu", "gonka1xm6gxfut4zz4358f0p32sj3jsl4cvthgdsnffg", "gonka1xmjrx334m6vsv32uvt0em0jzsd8zn9qfmntmy6", "gonka1xmtxd6frwdwvgeleettq769he4adc5g4vw7ejv", "gonka1xpvunl3269g3sejxg02hhke6nmwdwpf5gy6xw0", "gonka1xqt2sd42lzgcgvun37dcu65muyj4zfyhdhkdk6", "gonka1xrcdrdjy0s0e5nhy6nw3tcm9vrzn347qtct4p2", "gonka1xsglq4r3kaf7xr05yxgpcve8pju7zndl0xqn78", "gonka1xspavhncfmlpsllpfajs3r5623a4s8tcumrmwa", "gonka1xtd5kgw3k62jxumvtymvzww8dajrvu7cl9resf", "gonka1xteg3zgysvkvfl4lzs5gwxpkgtx0qra6m90jv3", "gonka1xtqxm7wx5qws7smmvwltzczfmhhpvysj3yzkfl", "gonka1xtwmtuyylt4d6uc6rds2lmpr2whmxx2wyteac0", "gonka1xuk3ganuhygvpge340sfepuwlr89s50fytlx2p", "gonka1xwtm07gnned6kf0j8vm3umryjutrhn2z467lja", "gonka1xxpvru04dvxzzq3kdwy93gu6yr47xrcr6mtjs9", "gonka1xycg2mc0ktaz4372q4ln3f0thefk86shhguk0w", "gonka1xyj2jlq36rhauw7lx6zwmj26dregc7qqd660vz", "gonka1xyxak0gyx76hrrkwukvyc6g2rpkruwjkpuh0p6", "gonka1xzajvz25mj3jaujmdu3c07phzwdm3zy0xh4yx9", "gonka1xzqcjz7vt9py3jn6jqkvs890txpry8cjdtrrna", "gonka1y07fqanen3dwgr5dku36gy8lfk3uxtj000t38p", "gonka1y0c59fsgtzxw4gdz96gnm6ke75j3cstwh5287e", "gonka1y0y9fcfhlhuz76falhdekx8w56pk88jaxssydu", "gonka1y27z7ujdhyugf7fzj69prey7m2f8rerx2zumpz", "gonka1y29s2ckdl0csktxhpx77a7dvwyhj9u4xyrcynm", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1y2e6vzpws7dguken363g9zfs3835l7k3m2p8x0", "gonka1y3r32jhy6s4ge2sl5ly5s90gc0r9d2n4wmzvu9", "gonka1y46v988rv03mdn2c320fxtle6lramzk4nf8s6r", "gonka1y4h94tjlg89lgs5l8gxk5vp76vqkenh453aqm5", "gonka1y58p9p64g0hu6uct73qhnpwlgum9t2fjjqmu4j", "gonka1y6ck2z2mdlmg9lru45uc8wge7d0te8q47t4eyw", "gonka1y6g6xx6lyp3gdnyq7k9tm9fa7ykzjdx68hyzpx", "gonka1y6pvlv88a0jn33dxzx0kh67m9nqmxypkrgc7uk", "gonka1y6wq2ghzq8edr7hp5myrctjkeqhdry8yuz0ft5", "gonka1y7c7zmn7y2h94qqe7q4w2300u85lzsp2nlxtgf", "gonka1y95qr73kms3zv5ju0kxtu58ksxdyrkyz8m0430", "gonka1y9vdzmy84uy9c9dgqx8adnusg3ssv7wjmscga8", "gonka1ya6mzkqvk7ss3l4jnu5fspt5vvzzmnn2ftqvda", "gonka1yaqxj5hxmme0q7m2wutngne0fdyaajv83p558f", "gonka1ycmm7dsxa6sg09x2yg05elta6wwcj3mk6em45l", "gonka1ycwxzenntgm5vrz696n9s0fv43g9cp3dsux3ku", "gonka1ycyya4sw9qyfhzq5c8mz9xqgdyd5jcxaaw8343", "gonka1yd8s6z8enw080kj2wgynuwdxzx40gttchqe4za", "gonka1ye7unfm0nf6qa7awmcgxql7u2zq9fqv0g5qw3h", "gonka1yfzf79pf8qapdmue6xx4j32fccktz2svy0030t", "gonka1ygzpvwx56xhtqylysfj8dkw7dpeampewpexvrc", "gonka1yhu3dsc5elznnc3fsw9rmfvvng2nf02ca03ng7", "gonka1yhztnnpnpt9ef6j520sh7x3aef5pxwewrsgzek", "gonka1yk34z38t92jzjgq2ga7tkfpj07sf4ss3tj6n2m", "gonka1yk9yfpnp4m439sjydwxt5ddvgfluht7zeem2mr", "gonka1ylhpz2dd9f6x6apkzr773yw0kaagkhpaph86qn", "gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p", "gonka1ym8yy3g474za5u5f739lxm6gctanc3ldustm96", "gonka1yn54kaefrf7sjk66c74gqap0mquzjqvthsyhwe", "gonka1ynv0jkg24cm4nf6gkwgqr8e6rjw8yc94raesls", "gonka1yp4s6p4dfd8gl3q8yz7tnqv58w2u7090zaze6v", "gonka1yp9zq863pfu4muamh5p6y5ahq00g47d8dtdwln", "gonka1yps5566s8222gefuwxep5yusv5fndvact0v2jq", "gonka1yps69kyf78rz9qj6cl58krkxp753tr56vt8phd", "gonka1ypy2ygsa7se9lrcwxlstgwsy0lfged0kg8ft95", "gonka1yq4vwn7fc9x7lykjhc0x3e7r2atee32czy34mt", "gonka1yq9kcavnnn3s7xj2ghzexjql7h4ca52rdnknza", "gonka1yqhuclpv6v0nm0kkkdn8gf7nh28fqtrv574987", "gonka1yquunstmnn35tuc6wsrlv020ul2rnuyldqkt37", "gonka1yrsd0w7u9rhc34pefu3gmqsa3kadkqehl2kmfe", "gonka1yrzpu8lp6tcark7vn0rjx2666fdceqcc8jmem6", "gonka1ysmj80gjrk5zswqmhevsugqrgvl30h973tv9pu", "gonka1yt2gm863yknevuu6nq6dzafckpxkjdmz3m0pct", "gonka1ythzsrcvd47fk2umtu6lvn562e9424es7p95wc", "gonka1ytmv7l93dv0xclwhqx9k8lt4yj3jfwylda3yv2", "gonka1yu3mrl4w3lgr3wu33sxpkm6j9du5pv65um5gcl", "gonka1yuqkaz3zlyg6kwsmjsmr69vy08yd8ufjyew9zk", "gonka1yv5nq3kzyaa0urcdfs4cu0ampcdw9d2c5dk0j4", "gonka1yvewyvecx746gm6ahlydptlxwx93d66dwsth24", "gonka1yw2klh9ew87jg5flesna6uf4phdyzzw0243jex", "gonka1yw3ggwwftvp2u3vt9l5hcyqftkd05nu4j3h7sr", "gonka1yxl3u4kgj9wwwf7yc46t74a3fky9fa8gfltj8v", "gonka1yysfdney9ayqhgd8e03zdkhqte3pr09zzevdrq", "gonka1yztsu2v8ywzfgejqc332w6ygcza9zp79zn5l86", "gonka1z046uvnyqryv34ecp5hnmpm5wh837jm3dy4tdv", "gonka1z05ztpmhgz0vj84t40nlvz4m003p3qwtsz5nk2", "gonka1z2uvzety5ktp6x39pgsmxjgqu2pzvuh928lm6v", "gonka1z3jn2nsta650733hsd7d55h7phv56t6yykj6yx", "gonka1z3kelh3gx3t6kz303f8trdll3j5ap3zz8csyfm", "gonka1z4ldfav9tl7x3w9aqfry89zd0kt7sa2lhff6te", "gonka1z54yfs6424efhsuxg060wu5pses56g7zga0z3m", "gonka1z669rrm4sygpede8sqddavhsef6wc9vwjsp9wh", "gonka1z7h4mzz5kkcydj4l6lzr9j73x49dlcq84mmkrv", "gonka1z7ph9yp99lh5yr4zs0gv20sht5a32uh3rtjlwh", "gonka1z8dh5kqdn2nnsg527qawy58ca5fme38xffq7ah", "gonka1z9fgh9mxsug0nyyp9p7l3dvzhuplflakc2xjkn", "gonka1z9whxqam96r6xh6h4088lcjmy3uec2l5v32dww", "gonka1zajzjefaegdmulnqeq7ads04jh5pm9c4vs4a7u", "gonka1zaklf2yedw6my8lw6vt797vzpn67qeusj5a6zl", "gonka1zap7nsccl6x83ucwvq0q6qrefmf9n7ejmj49j3", "gonka1zcsj9h5dvl0jdgen9u8levdn7exvnffq0ayql5", "gonka1zcznpcp8hfe9ca8jnk9mtc2dmddf9t8cz5temj", "gonka1ze3pxkfyvk2jqyswnvzed6qa364f6nd6x04m3g", "gonka1zeaucp7k6cauj84e92wccnxnsua0a73rl8tpvj", "gonka1zepcpcnw6qa45k38muhgavzflelun6rh5hu35k", "gonka1zftzg8jxcu5jkevnrstzsh49a0p6vp3pwx3uwx", "gonka1zg0r3tru3z22mtu7gn74shssmyfjlghtckfatg", "gonka1zga6u9tycf3752e8yxr45tygymfkw6fxlf86pd", "gonka1zh5kme35psmcvlx2tgrg5nzlm0mu0ea3868p67", "gonka1zhac4vznmnk63jyrvgz5nskhskuz0a80ql9l0t", "gonka1zjajt7pt4tx0djf9r7gksur320gug5e9ymqkaf", "gonka1zjyq40fs8grxh4zme0w4s5qv3rvssnccru4xmw", "gonka1zkegnzhzcyeu9m74f8907tg5ga2dyhxnfuxm0w", "gonka1zkmn95dkr6kpt7vaqc4vdues0q4f72rttcfxq6", "gonka1zls8l6d825gchrvtqgykzrdkqlvzcnyhstft46", "gonka1zm5t9v9mrvpr4ddfx433snxqa8uyy32fqwp5zv", "gonka1zmkvl7ws46vhq4pkaxzm4c5x3d9kl5kpymkjj2", "gonka1zmx4cwayvhf8hevcu6am0sk8ul5trckc2uftmp", "gonka1zmxs507rnegc0takkkarfsu4cktemhzz4anmet", "gonka1zn4ey6xqym4vzr6s8trtu65n9wez648fysxz67", "gonka1zpm8qujddac84y7wfh7h3p85ys336n9zjqckzl", "gonka1zq9440mp8dlja32asrseascgs4xwwrwdrrratw", "gonka1zqddqel0zwzae6zfeh4dpt45d5f656yghdenpp", "gonka1zqp2nzfra4n3eq0vf6nrdqqmua3fknul5mjn4y", "gonka1zqw2tpr69zj44qv38flanuyce9ufakpdvr4xnv", "gonka1zqxg52qngwtgzgnrvljdwcwt9q0jz9r2djkpyj", "gonka1zrmra5s53f6pgzxx89znkn5k0duwsksr2xuzke", "gonka1zrnrd7zcqnhjytqa8zsg63slxt2g45ctlqy3fm", "gonka1zs04qud0wnca4ryp4vu7888nfr3gl5q9hhaf7e", "gonka1zsnpv9htjtq35ux04hal5l8dnlgah22zl6rk3h", "gonka1zt30y870usf0fqjwm3600d2zc3qqk9yxgsggvt", "gonka1zupqz5a8w4a5mjqdqylq8h6hr3fl2arvlkd38r", "gonka1zuvs5jm3r3wpcatfepzmfqlg82em5sglr5qx4l", "gonka1zv89w02sdfzwy74s9vcthk38dnfsw36s4h7s93", "gonka1zvuzj7ya9zafw309prasd0r4jhykf47mhcpp3x", "gonka1zvxyj7xykheej9vkk0ttvel0eynql9pxlxtr9s", "gonka1zw680tan4k6uwklyq6eedmga8ew85ys4arqkdg", "gonka1zxlyzhhe3qvd568su0qey7wam0drutrzts5f88", "gonka1zzkxnpq2txntwh5eu49jk67x42yh8wystnkamy", "gonka1zzrrrk7349qqqpykqker092y2ske3m8afgure3" ] }, { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "60", "poc_exchange_duration": "5", "poc_validation_delay": "5", "poc_validation_duration": "120", "set_new_validators_delay": "120", "inference_validation_cutoff": "20", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": { "value": "25", "exponent": -1 }, "model_params": { "dim": 1792, "n_layers": 64, "n_heads": 64, "n_kv_heads": 64, "vocab_size": 8196, "ffn_dim_multiplier": { "value": "1", "exponent": 1 }, "multiple_of": 8192, "norm_eps": { "value": "1", "exponent": -5 }, "rope_theta": 10000, "use_scaled_rope": false, "seq_len": 256, "r_target": { "value": "1398077", "exponent": -6 } }, "model_id": "", "seq_len": "0", "poc_v2_enabled": false, "confirmation_poc_v2_enabled": false, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2294222", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu" ] }, "participant_access_params": { "new_participant_registration_start_height": "2222222", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "0" }, "transfer_agent_access_params": null, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } } ] ``` --- ## #35 – gonka.ai / TheSoul social media awareness project # #35 – gonka.ai / TheSoul social media awareness project Rejected **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`](https://gonka.gg/address/gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm){:target="_blank"} **Failed reason:** proposal did not get enough votes to pass 970,000 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/35){:target="_blank"} 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: --- ## Final Tally Yes 9,150 (25.5%) No 10,325 (28.8%) Veto 2,450 (6.8%) Abstain 13,939 (38.9%) Total 35,864 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1ls44amlsum476ajg48dzq09uh9am8rg8qdl2q4r03h75ujfk2t0stkevej", "amount": [ { "denom": "ngonka", "amount": "970000000000000" } ] } ] ``` --- ## #28 – Collateral Parameters Update # #28 – Collateral Parameters Update 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Failed reason:** proposal did not get enough votes to pass [View on gonka.gg](https://gonka.gg/network/proposals/28){:target="_blank"} 0.032 GNK per 1 unit of power, 0.01% slashing for miss rate or jail, 0.5% slashing for invalid inference --- ## Final Tally Yes 314,460 (96.5%) No 11,504 (3.5%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 325,964 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "60", "poc_exchange_duration": "5", "poc_validation_delay": "5", "poc_validation_duration": "480", "set_new_validators_delay": "120", "inference_validation_cutoff": "2", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": { "value": "262", "exponent": -3 }, "model_params": { "dim": 1792, "n_layers": 64, "n_heads": 64, "n_kv_heads": 64, "vocab_size": 8196, "ffn_dim_multiplier": { "value": "1", "exponent": 1 }, "multiple_of": 8192, "norm_eps": { "value": "1", "exponent": -5 }, "rope_theta": 10000, "use_scaled_rope": false, "seq_len": 256, "r_target": { "value": "1398077", "exponent": -6 } }, "model_id": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", "seq_len": "1024", "poc_v2_enabled": true, "confirmation_poc_v2_enabled": true, "stat_test": { "dist_threshold": { "value": "2", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "5", "exponent": -3 }, "slash_fraction_downtime": { "value": "1", "exponent": -4 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "32", "exponent": 6 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2475000", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2475000" }, "transfer_agent_access_params": { "allowed_transfer_addresses": [ "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u" ] }, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } } ] ``` --- ## #21 – Fix mistakes in allowlist # #21 – Fix mistakes in allowlist Passed **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/21){:target="_blank"} --- ## Final Tally Yes 3,020,391 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 3,020,391 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgAddParticipantsToAllowList` | | 2 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgAddParticipantsToAllowList", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "addresses": [ "gonka10ham8mkawe850sk3aq9vfjvsw2nzvl63ulcuyl", "gonka14uu6edm0ma60089yslrw0a2fgcl7d6p4ekyapf", "gonka15ffxwcy7dk5k4unleeernxppgwgg2686eq4lfs", "gonka18dy9cn8e65kh6jy2j6v5du26tq9tkpf8e2n5uk", "gonka19hwucu9qdsvlhnj5hyhcavtr9esgfvkvc6phfy", "gonka1adacqpq6z6sg9qqsy4f0p02p0sfn2f6n6dldae", "gonka1arn3ksw9zv7mz4mneydvxqhsv4cg3uvxqljal8", "gonka1c25w5hhue4t6yt5ya24vk47zpanaulx4znys7z", "gonka1hqdqhlqpqpee3zdrupe5ech54hn6tf5er4esg3", "gonka1l9yanamzzhq4rfjnq05rm05cssqrqcaely9xwx", "gonka1lmgutdlel0fny79zvlsh9aw3c0dw75gtscka3g", "gonka1lwhyr98mv8yynf5g05495m6x68fcak8d3p78f5", "gonka1mmwngrtpc4fd4jquv5vfsnscqdzmcz0zgrvy0g", "gonka1myqk82deh6wexqazulwaqm6x340vh8kch44qwl", "gonka1ntlpylyhgwlg87pkh7dlyg5tnkad5986hnsgmf", "gonka1pnfyj6kw3h3v2qu60j42j8h3cuf3jpqqgnaet7", "gonka1q0r6nmh849xatx62cd09axnx4et4egu4z7n7jj", "gonka1stxj7a8ka9r66t98vltld0u5cd9vs97nsqplq3", "gonka1t4scergcmv6w9tllx9eeyfvgmwae8uzqnqqlps" ] }, { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "60", "poc_exchange_duration": "5", "poc_validation_delay": "5", "poc_validation_duration": "120", "set_new_validators_delay": "120", "inference_validation_cutoff": "20", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": { "value": "25", "exponent": -1 }, "model_params": { "dim": 1792, "n_layers": 64, "n_heads": 64, "n_kv_heads": 64, "vocab_size": 8196, "ffn_dim_multiplier": { "value": "1", "exponent": 1 }, "multiple_of": 8192, "norm_eps": { "value": "1", "exponent": -5 }, "rope_theta": 10000, "use_scaled_rope": false, "seq_len": 256, "r_target": { "value": "1398077", "exponent": -6 } }, "model_id": "", "seq_len": "0", "poc_v2_enabled": false, "confirmation_poc_v2_enabled": false, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2294222", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2222222", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2222222" }, "transfer_agent_access_params": null, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } } ] ``` --- ## Upgrade Proposal: v0.2.8 # Upgrade Proposal: v0.2.8 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. ## Upgrade Plan 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`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.8/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. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. Once the PR is approved by a majority, a `v0.2.8` 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 hosts. ## Testing 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. ## Migration The on-chain migration logic is defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.8/inference-chain/app/upgrades/v0_2_8/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. ## PoC V2 Migration 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. ## Changes ### [PR #505](https://github.com/gonka-ai/gonka/pull/505) Security Fixes for v0.2.7 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 ### [PR #609](https://github.com/gonka-ai/gonka/pull/609) BLS optimized * Significantly optimizes BLS signature verification (from ~2s down to <10ms) by using the `blst` library and precomputing slot public keys. ### [PR #540](https://github.com/gonka-ai/gonka/pull/540) Remove ALL panic and Must from chain code * Removes `panic` and `Must` calls from chain code to prevent consensus failures. * Implements linting (`forbidigo`) and CI checks to enforce this rule. ### [PR #534](https://github.com/gonka-ai/gonka/pull/534) Security: prevent SSRF via executor redirect * Prevents SSRF attacks where a malicious executor redirects Transfer Agent requests to internal services (e.g., admin API). * Implements a custom HTTP client that disables following redirects. * **Thanks to:** @x0152 ### [PR #544](https://github.com/gonka-ai/gonka/pull/544) Inference: defense-in-depth against int overflow * Fixes integer overflow vulnerabilities in escrow and cost calculations using checked arithmetic. * Adds hard caps for token counts and improves error handling to fail closed on overflows. * **Thanks to:** @ouicate ### [PR #506](https://github.com/gonka-ai/gonka/pull/506) Standardize floating point math * Replaces dangerous floating-point math with `shopspring/decimal` for deterministic calculations (e.g., Dynamic Pricing). * Updates reward exponent calculation to use a table-based approach for decay rates. ### [PR #536](https://github.com/gonka-ai/gonka/pull/536) Perf: optimize participants endpoint with single balance query * Optimizes the `/v1/participants` endpoint by replacing N gRPC calls with a single blockchain query. * Achieves ~500x speedup for large sets of participants. * **Thanks to:** @x0152 ### [PR #553](https://github.com/gonka-ai/gonka/pull/553) Membership for correct epoch for Validation requests * Ensures validation rights are checked against the active participants of the target epoch, not the current one. * Fixes logic for sharing work coins and refunds during validation/invalidation. ### [PR #607](https://github.com/gonka-ai/gonka/pull/607) Fix(inference): update totalDistributed after debt deduction * Fixes a bug where `totalDistributed` was not updated after deducting debt, causing tokens to be lost instead of returned to governance. * **Thanks to:** @0xMayoor ### [PR #549](https://github.com/gonka-ai/gonka/pull/549) Disable future timestamp check for EA * Temporarily disables the future timestamp check in the External Adapter (EA) to prevent rejecting requests when the EA is behind the chain during high load. ### [PR #550](https://github.com/gonka-ai/gonka/pull/550) Negative coin balance for settle * Handles edge cases with negative coin balances by subtracting the negative amount from rewards instead of erroring. ### [PR #541](https://github.com/gonka-ai/gonka/pull/541) PoC validation, retry getting nodes * Adds retry logic for retrieving nodes during Proof of Compute (PoC) validation to improve robustness. ### [PR #551](https://github.com/gonka-ai/gonka/pull/551) Fix(bls): reject duplicate slot indices in partial signatures * Rejects partial signatures with duplicate slot indices to prevent verification failures during aggregation. * **Thanks to:** @0xMayoor ### [PR #563](https://github.com/gonka-ai/gonka/pull/563) Fix(inference): variable shadowing in direct payment path * Fixes a variable shadowing bug that caused errors (like `SendCoins` failures) to be swallowed during refunds. * **Thanks to:** @0xMayoor ### [PR #559](https://github.com/gonka-ai/gonka/pull/559) Burn extra pool coins, fix ValueDecimal validation * Burns coins from an inadvertently created account. * Fixes validation for `ValueDecimal` to correctly handle `nil` values. ### [PR #616](https://github.com/gonka-ai/gonka/pull/616) Integration test database, debugging assistance * Adds functionality to upload integration test results to BigQuery. * Includes fuzz testing and improved debugging logs. ### [PR #547](https://github.com/gonka-ai/gonka/pull/547) Updated script snippets and MacOS Tahoe 26.1 Docker settings * Updates documentation and adds Docker settings for running testermint locally on MacOS Tahoe. ### [PR #618](https://github.com/gonka-ai/gonka/pull/618) PoC v2 & Offchain PoC data * Integrates PoC directly into vLLM, enabling immediate switch from inference to PoC without offloading the model or loading a separate PoC model. * Migrates artifact storage off-chain using MMR (Merkle Mountain Range) commitments - only `root_hash` and `count` are recorded on-chain. * Adds statistical test-based validation with L2-distance mismatch rule and calibrated thresholds. * New chain messages: `SubmitPocValidationsV2`, `PoCV2StoreCommit`, `MLNodeWeightDistribution`. * Includes dual-mode migration strategy: V1 for regular PoC, V2 tracking for Confirmation PoC during rollout. --- ## #24 – Upgrade Proposal: v0.2.8 # #24 – Upgrade Proposal: v0.2.8 Rejected **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/d61cf37eb97e0aaf3e4b227a1d6f31ea8635797a/proposals/governance-artifacts/update-v0.2.8/README.md](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](https://gonka.gg/network/proposals/24){:target="_blank"} Upgrade Proposal: v0.2.8 --- ## Final Tally Yes 0 (0.0%) No 0 (0.0%) Veto 3,775,640 (100.0%) Abstain 0 (0.0%) Total 3,775,640 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.8", "time": "0001-01-01T00:00:00Z", "height": "2386600", "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 }", "upgraded_client_state": null } } ] ``` --- ## Upgrade Proposal: v0.2.10 # Upgrade Proposal: v0.2.10 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. ## Upgrade Plan 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`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/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 ``` The 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. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. Once the PR is reviewed by the community, a `v0.2.10` 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 hosts. ## Testing 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. ## Migration The on-chain migration logic is defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/inference-chain/app/upgrades/v0_2_10/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`. ## 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: [`proposals/poc/optimize.md`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.10/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. ## 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. 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`). ## Upgrade Grace Period 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. ## Changes ### [PR #710](https://github.com/gonka-ai/gonka/pull/710) PoC Validation Sampling Optimization * Reduces validation complexity from quadratic to slot-based sampling. * Adds deterministic slot assignment shared by chain and API, with snapshot-backed weight synchronization. * Keeps backward-compatible fallback path when `ValidationSlots=0` and includes upgrade-time default of `ValidationSlots=0` for safe rollout. ### [PR #725](https://github.com/gonka-ai/gonka/pull/725) PoC weight normalization on real PoC time * Adds time-based PoC weight normalization to reduce sensitivity to block-time variance. * Introduces `PocNormalizationEnabled` in PoC params and uses validation snapshot timestamps to compute normalization factor. * Integrates normalization into both regular PoC and confirmation PoC weight calculations. * Upgrade handler enables normalization by default for `v0.2.10`. ### [PR #767](https://github.com/gonka-ai/gonka/pull/767) Upgrade grace period, tool calling, and PoC timing fix * Adds grace epoch protection for the upgrade epoch: extended CPoC window (3000 blocks) and relaxed miss/invalid thresholds. * Updates Qwen model with tool calling support (`--enable-auto-tool-choice`, `--tool-call-parser hermes`). * Adjusts validation threshold from 0.970917 to 0.958. * Deprecates `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. ### [PR #708](https://github.com/gonka-ai/gonka/pull/708) IBC Upgrade to v8.7.0 * Upgrades IBC stack to v8.7.0. * Aligns chain interoperability components with current IBC release line. ### [PR #723](https://github.com/gonka-ai/gonka/pull/723) Testnet bridge setup scripts * Adds bridge setup scripts for testnet operations. * Improves reproducibility of bridge deployment and validation workflows. ### [PR #666](https://github.com/gonka-ai/gonka/pull/666) Artifact storage throughput optimization * Improves PoC artifact storage throughput. ### [PR #688](https://github.com/gonka-ai/gonka/pull/688) Punishment statistics from on-chain data * Uses on-chain data for punishment statistics with dynamic table selection. ### [PR #697](https://github.com/gonka-ai/gonka/pull/697) Portable BLST build for macOS test builds * Uses a portable BLST build path for macOS test binaries. * Improves reliability of local/test build pipeline on macOS hosts. ### [PR #712](https://github.com/gonka-ai/gonka/pull/712) Require proto-go generation matches committed code * Enforces proto-go generation consistency in development flow. * Prevents accidental drift between generated and committed protobuf code. ### [PR #711](https://github.com/gonka-ai/gonka/pull/711) PoC test params from chain state * Replaces hardcoded PoC test defaults with chain state parameters. ### [PR #641](https://github.com/gonka-ai/gonka/pull/641) Streamvesting transfer with vesting * Adds `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). * Adds safety limits to prevent abusive requests: max `3650` vesting epochs and max `10` coin denoms per transfer. ### API hardening and reliability fixes * [PR #634](https://github.com/gonka-ai/gonka/pull/634): add request body size limits to reduce DoS risk. * [PR #727](https://github.com/gonka-ai/gonka/pull/727): follow-up for #634, pass response writer to `http.MaxBytesReader` and align tests. * [PR #638](https://github.com/gonka-ai/gonka/pull/638): fix unsafe type assertions in request processing. * [PR #644](https://github.com/gonka-ai/gonka/pull/644): avoid rewriting static config on each startup. * [PR #661](https://github.com/gonka-ai/gonka/pull/661): prevent API crash on short network drops. * [PR #640](https://github.com/gonka-ai/gonka/pull/640): add unit tests for node version endpoint behavior. * [PR #622](https://github.com/gonka-ai/gonka/pull/622): propagate refund errors in `InvalidateInference`. * [PR #639](https://github.com/gonka-ai/gonka/pull/639): add missing return after error in task claiming path. * [PR #643](https://github.com/gonka-ai/gonka/pull/643): sanitize nil participants in executor selection. * [PR #545](https://github.com/gonka-ai/gonka/pull/545): minor bug fixes in API flow. ### Other fixes * [PR #659](https://github.com/gonka-ai/gonka/pull/659): model assignment checks previous-epoch rewards. * [PR #716](https://github.com/gonka-ai/gonka/pull/716): rename PoC weight function for clarity and correctness. ## Proposed Bounties | PR/Issue | Sum GNK | Bounty Explanation | |-----------|---------|---------------------| | PR #661 | 500 | Valid fix for minor vulnerability that was previously reported in issue #422 | | PR #644 | 700 | Planned task, not a vulnerability, important for the network. | | PR #659 | 10,000 | Detailed report and fix for a Medium risk vulnerability. | | Report | 5,000 | First report of the vulnerability fixed in #659 | | PR #545 | 1,000 | Report and fix of low risk vulnerability. Extra appreciation for discovering and reporting it during the review of another PR. | | PR #640 | 100 | Valid minor bug fix. | | Issue #422 | 500 | First report and suggested fix. Fixed in PR #661 | | PR #638 | 100 | Valid minor bug fix. | | PR #634 | 100 | Valid minor bug fix. | | Report | 5,000 | Independent report on the issue addressed by PR #710. | | PR #643 | 500 | Report and fix of low risk vulnerability. | | PR #641 | 1,500 | Valid implementation of a planned task. | | PR #622 | 700 | Valid minor vulnerability report and fix. | | PR #688 | 1,500 | Valid implementation of a planned task with adjusting scope, important for the network. | * Review of previous upgrades with meaningful feedback - 2,500 GNK each : * v.0.2.9: [blizko](https://github.com/blizko) & [x0152](https://github.com/x0152) * v.0.2.8: [blizko](https://github.com/blizko), [x0152](https://github.com/x0152), [ouicate](https://github.com/ouicate), [jacky6block](https://github.com/jacky6block) & [akup](https://github.com/akup) --- ## #27 – Upgrade Proposal: v0.2.10 # #27 – Upgrade Proposal: v0.2.10 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/faa358dec3091e19cb92267556443775431ecc81/proposals/governance-artifacts/update-v0.2.10/README.md](https://github.com/gonka-ai/gonka/blob/faa358dec3091e19cb92267556443775431ecc81/proposals/governance-artifacts/update-v0.2.10/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/27){:target="_blank"} Upgrade Proposal: v0.2.10 --- ## Final Tally Yes 1,540,653 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 1,540,653 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.10", "time": "0001-01-01T00:00:00Z", "height": "2712600", "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 }", "upgraded_client_state": null } } ] ``` --- ## #34 – gonka.ai / TheSoul social media awareness project # #34 – gonka.ai / TheSoul social media awareness project 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`](https://gonka.gg/address/gonka1s3tnqglxt6xwy9ttuedtz8cp4x9tlwp8sdcvvm){:target="_blank"} **Failed reason:** proposal did not get enough votes to pass 970,000 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/34){:target="_blank"} 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: --- ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1ls44amlsum476ajg48dzq09uh9am8rg8qdl2q4r03h75ujfk2t0stkevej", "amount": [ { "denom": "ngonka", "amount": "970000000000000" } ] } ] ``` --- ## Upgrade Proposal: v0.2.9 # Upgrade Proposal: v0.2.9 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. ## Upgrade Plan 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`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.9/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. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. Once the PR is approved by a majority, a `v0.2.9` 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 hosts. ## Testing 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. ## Migration The on-chain migration logic is defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.9/inference-chain/app/upgrades/v0_2_9/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. ## PoC V2 Full Activation 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. ## Model Consolidation 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. ## Transfer Agent Whitelist 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. ## Changes ### [PR #674](https://github.com/gonka-ai/gonka/pull/674) Missed inferences fix * Don't punish for missed inferences of non-preserved nodes during PoC. * Don't punish for missed inferences if participant doesn't support the model. * **Thanks to:** @x0152, @DimaOrekhovPS ### [PR #678](https://github.com/gonka-ai/gonka/pull/678) CPoC downtime penalty redistribution * Lower confirmation reward penalty is now transferred to the community pool instead of being lost. * Ensures penalties are redistributed fairly during CPoC downtime events. ### Guardian Tiebreaker for PoC V2 Voting * Adds guardians tiebreaker logic for undecided POC V2 votes. * When neither valid nor invalid votes reach majority, guardians can break the tie if they unanimously agree. * Trigger conditions: no majority exists, guardians enabled, at least one guardian voted, all voting guardians agree. ### Enforced Model Auto-Switch (API) * Automatically switches all nodes to `Qwen/Qwen3-235B-A22B-Instruct-2507-FP8` with `--tensor-parallel-size 4`. * Three-layer enforcement: config enforcement, state enforcement, and runtime verification. * Runtime verification queries vLLM `/v1/models` endpoint and triggers redeploy on mismatch. ### Transfer Agent Whitelist (Chain + API) * New chain parameter for allowed Transfer Agent addresses. * Early enforcement at API level before expensive operations. * Validation at chain level in `StartInference` and `FinishInference`. ### Suspicious Participant Removal * Removes 25 participants from the allowlist who exhibited suspicious behavior during epoch 155 POC. * These participants completed POC generation phase but did not vote for other participants at validation phase. * Addresses are permanently removed from the participant allowlist. ### Reset POC Slots for V2 Epoch * Resets `TimeslotAllocation[1]` (POC_SLOT) to `false` for all nodes. * Updates both `ActiveParticipants` and `EpochGroupData` structures. * Ensures all nodes participate in the first V2 POC phase. --- ## #26 – Upgrade Proposal: v0.2.9 # #26 – Upgrade Proposal: v0.2.9 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/808247ea17c254f0b81cfa67edb579ba249175f0/proposals/governance-artifacts/update-v0.2.9/README.md](https://github.com/gonka-ai/gonka/blob/808247ea17c254f0b81cfa67edb579ba249175f0/proposals/governance-artifacts/update-v0.2.9/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/26){:target="_blank"} Upgrade Proposal: v0.2.9 --- ## Final Tally Yes 2,708,406 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 2,708,406 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.9", "time": "0001-01-01T00:00:00Z", "height": "2451000", "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 }", "upgraded_client_state": null } } ] ``` --- ## #29 – Network Parameters Update: Disable TA Allowlist, Increase Prices 100x # #29 – Network Parameters Update: Disable TA Allowlist, Increase Prices 100x Rejected **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`](https://gonka.gg/address/gonka148zyn5m8vjw5wvzr5yg37cdml64z668rav5j5m){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/main/proposals/governance-artifacts/param-update-2025-02/README.md](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](https://gonka.gg/network/proposals/29){:target="_blank"} Remove TransferAgent allowlist restrictions (empty list = all TAs allowed) and increase per-token pricing 100x (min 100, base 10000 ngonka) to reduce spam. --- ## Final Tally Yes 7,314 (2.9%) No 0 (0.0%) Veto 243,060 (97.1%) Abstain 0 (0.0%) Total 250,374 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "35", "poc_exchange_duration": "0", "poc_validation_delay": "5", "poc_validation_duration": "240", "set_new_validators_delay": "120", "inference_validation_cutoff": "2", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": { "value": "3593", "exponent": -4 }, "model_params": { "dim": 1792, "n_layers": 64, "n_heads": 64, "n_kv_heads": 64, "vocab_size": 8196, "ffn_dim_multiplier": { "value": "1", "exponent": 1 }, "multiple_of": 8192, "norm_eps": { "value": "1", "exponent": -5 }, "rope_theta": 10000, "use_scaled_rope": false, "seq_len": 256, "r_target": { "value": "1398077", "exponent": -6 } }, "model_id": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", "seq_len": "1024", "poc_v2_enabled": true, "confirmation_poc_v2_enabled": true, "stat_test": { "dist_threshold": { "value": "2", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "100", "base_per_token_price": "10000", "grace_period_end_epoch": "90", "grace_period_per_token_price": "0" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2475000", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2475000" }, "transfer_agent_access_params": { "allowed_transfer_addresses": [] }, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } } ] ``` --- ## Install Python dependencies 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: # Install Python dependencies pip install -r requirements.txt # Configure environment (first time only) cp .env.example .env # Edit .env to set your archive node URL and inferenced binary path # Run analysis # Phase 1: Fetch epoch data and analyze confirmation ratio distributions python3 fetch_epoch_data.py 132 133 # Phase 2: Identify affected participants (those who received no rewards) python3 identify_affected.py 132 133 # Phase 3: Calculate compensation amounts 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 # Example: Check if a participant received rewards in epoch 132 ADDRESS="gonka14ued4vcdeluj9v9vmsmteap7vtg7t50640hvmf" # Query their epoch performance summary (after settlement at height 2,060,000) $INFERENCED query inference show-epoch-performance-summary-by-participant \ 132 $ADDRESS --node $ARCHIVE_NODE --height 2060000 -o json | jq '.' # Look for "rewarded_coins" field: # - If absent or "0" → participant received NO rewards (affected) # - If present with value > 0 → participant received rewards (not affected) 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 # Participant address ADDR="gonka1hec2h63xkf9qf7gn07uwucveuhjfrqks8f4dmh" # 1. Check their confirmation ratio (from epoch_132_data.json) cat epoch_132_data.json | jq --arg addr "$ADDR" \ '.participants[] | select(.address == $addr) | {address, confirmation_ratio, base_weight, confirmation_weight}' # 2. Check their performance stats (before epoch end) $INFERENCED query inference show-participant $ADDR \ --node $ARCHIVE_NODE --height 2058356 -o json | \ jq '.participant.current_epoch_stats' # 3. Check if they received rewards (after settlement) $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 # Sample a successful participant who DID receive rewards SUCCESS_ADDR="gonka1w6wwv3wq25p8qge4lqsnfzs8lsd3s8ty6au65p" # Get their epoch summary $INFERENCED query inference show-epoch-performance-summary-by-participant \ 132 $SUCCESS_ADDR --node $ARCHIVE_NODE --height 2060000 -o json | \ jq '{rewarded_coins, address}' # Get their confirmation_weight cat epoch_132_data.json | jq --arg addr "$SUCCESS_ADDR" \ '.participants[] | select(.address == $addr) | {confirmation_weight}' # Calculate coefficient manually: # coefficient = rewarded_coins / confirmation_weight # Should equal ~52,796,590.93 for epoch 132 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. --- ## #33 – Epochs 132-133 compensation payout from gov module # #33 – Epochs 132-133 compensation payout from gov module 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`](https://gonka.gg/address/gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k){:target="_blank"} **Metadata:** [https://github.com/votkon/epoch-132-analysis](https://github.com/votkon/epoch-132-analysis) 3,100 GNK · Community Pool · 24,806 GNK · Gov Module [View on gonka.gg](https://gonka.gg/network/proposals/33){:target="_blank"} Distribute compensation for CPoC bug affected participants in epochs 132-133. --- ## Final Tally Yes 184,243 (41.8%) No 0 (0.0%) Veto 0 (0.0%) Abstain 256,296 (58.2%) Total 440,539 votes ## Messages | # | 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 ```json [ { "@type": "/inference.streamvesting.MsgBatchTransferWithVesting", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "outputs": [ { "recipient": "gonka1r3h2aumyr3cjma50w9rkhmfp7ewqnzxyysxqxf", "amount": [ { "denom": "ngonka", "amount": "4843494827072" } ] }, { "recipient": "gonka1apw5tzk6a3l9hdpdx5q9v2leehvz5rvvw44x8s", "amount": [ { "denom": "ngonka", "amount": "4255766000801" } ] }, { "recipient": "gonka14ued4vcdeluj9v9vmsmteap7vtg7t50640hvmf", "amount": [ { "denom": "ngonka", "amount": "3616886374064" } ] }, { "recipient": "gonka1hec2h63xkf9qf7gn07uwucveuhjfrqks8f4dmh", "amount": [ { "denom": "ngonka", "amount": "1825917300632" } ] }, { "recipient": "gonka1p22v6ncqsys9fh85gdmkakpe24x2zqfyp60z5q", "amount": [ { "denom": "ngonka", "amount": "1090021596230" } ] }, { "recipient": "gonka178p3vw9zxs885l4a29g3sep0v9uplfq4pzvmrq", "amount": [ { "denom": "ngonka", "amount": "1060818652888" } ] }, { "recipient": "gonka19fpma3577v3fnk8nxjkvg442ss8hvglxwqgzz6", "amount": [ { "denom": "ngonka", "amount": "804947679963" } ] }, { "recipient": "gonka1s5vtmnn8tqvqfh7gd9hv48kkt2t4mkh7s85zh6", "amount": [ { "denom": "ngonka", "amount": "758407087247" } ] }, { "recipient": "gonka1pvkv59e72vju2h7s9j3ex62c5xneqey350vpwn", "amount": [ { "denom": "ngonka", "amount": "711355059445" } ] }, { "recipient": "gonka1l45efpupwqw9uky3gjwy35mwae9jwgffuqpm7s", "amount": [ { "denom": "ngonka", "amount": "684300143460" } ] }, { "recipient": "gonka1jrkf560tvgqw3f9z4axs9da34lgnrd396e3rs0", "amount": [ { "denom": "ngonka", "amount": "632440625861" } ] }, { "recipient": "gonka1lmh6fy92ac2wldnpugg3t3xhp8lnqzgq0j0efg", "amount": [ { "denom": "ngonka", "amount": "627223500217" } ] }, { "recipient": "gonka1v0td7x4ndxhveg50vzp6nkz4s25qy2wpvrxm32", "amount": [ { "denom": "ngonka", "amount": "494711157525" } ] }, { "recipient": "gonka1czmu5smv804kq6pqtyvmjxcjjj720mgl4xc3hd", "amount": [ { "denom": "ngonka", "amount": "271520886519" } ] }, { "recipient": "gonka1ya6mzkqvk7ss3l4jnu5fspt5vvzzmnn2ftqvda", "amount": [ { "denom": "ngonka", "amount": "220428521548" } ] }, { "recipient": "gonka1dydrqvyaa0s8puwmk9e5d5x5hchrm883eckngj", "amount": [ { "denom": "ngonka", "amount": "175020698924" } ] }, { "recipient": "gonka1ra2jy33a2uuyu4jq2f9gf8va555f4tkhr3e4j9", "amount": [ { "denom": "ngonka", "amount": "165992481875" } ] }, { "recipient": "gonka1ktl3kkn9l68c9amanu8u4868mcjmtsr5tgzmjk", "amount": [ { "denom": "ngonka", "amount": "165398106423" } ] }, { "recipient": "gonka1v8z57yg47n8h4zveyj4cdpn0ll8k9zpcm7egkv", "amount": [ { "denom": "ngonka", "amount": "143659523913" } ] }, { "recipient": "gonka1tpvcpcmmqcku5g53tv2q4wehgqw3nmeq3jk4vn", "amount": [ { "denom": "ngonka", "amount": "138115881866" } ] }, { "recipient": "gonka1hqwgkck88d5wnpea0y9dn0gxmyg4rwjgcnvacf", "amount": [ { "denom": "ngonka", "amount": "137985185878" } ] }, { "recipient": "gonka19w5vy2z5gz9f4jr76f8uz09023wz2snycaty05", "amount": [ { "denom": "ngonka", "amount": "134507427301" } ] }, { "recipient": "gonka17et3ctw6t4d5ylnuc2kwc8xrlwk69y0cggzjqm", "amount": [ { "denom": "ngonka", "amount": "133680968228" } ] }, { "recipient": "gonka1jvp4r2dx3t0d736fmxy5ncgwp0w3kdy063m5ps", "amount": [ { "denom": "ngonka", "amount": "130978525216" } ] }, { "recipient": "gonka1clm58yldg7zp7dmuwrqyh4quqt339qr3q8fajm", "amount": [ { "denom": "ngonka", "amount": "129955655047" } ] }, { "recipient": "gonka10ekkjpyfad6265m2502d4tp3n8yp9n0d7rlzk4", "amount": [ { "denom": "ngonka", "amount": "128319062775" } ] }, { "recipient": "gonka1njzjqpx6t4jwe9t0fu8vtzn5cj5xjlaussvctx", "amount": [ { "denom": "ngonka", "amount": "122224107996" } ] }, { "recipient": "gonka1zmx4cwayvhf8hevcu6am0sk8ul5trckc2uftmp", "amount": [ { "denom": "ngonka", "amount": "122224107996" } ] }, { "recipient": "gonka1g5t786e2hnry8c4d6fd4rh5t3vsfdnevejtsvy", "amount": [ { "denom": "ngonka", "amount": "119689871632" } ] }, { "recipient": "gonka1a357vdludl6kpmx0c7cstf3vc0muu7t7ltw8sd", "amount": [ { "denom": "ngonka", "amount": "118141504588" } ] }, { "recipient": "gonka150qqxu2zf0lzc3nngal79h0n5ls6lhszzraytv", "amount": [ { "denom": "ngonka", "amount": "113487445316" } ] }, { "recipient": "gonka1kch7y24sjux5s7qd9l9j02qzusk33xeqwyz0kc", "amount": [ { "denom": "ngonka", "amount": "113027153740" } ] }, { "recipient": "gonka1c8utgl2469d7mjlhhd4afhj3ycm6rq60y7v8dl", "amount": [ { "denom": "ngonka", "amount": "104997622909" } ] }, { "recipient": "gonka1a2k2pz759kj543yzxse4hvvsyjkaw0f42mkpl2", "amount": [ { "denom": "ngonka", "amount": "104895335892" } ] }, { "recipient": "gonka1j9rxapzwm06quxcul5686e7f39g6swhfhwxtwa", "amount": [ { "denom": "ngonka", "amount": "104383900807" } ] }, { "recipient": "gonka10xrtfzs46mmjs8dy48auh2xfxq07dxs0mhdcmp", "amount": [ { "denom": "ngonka", "amount": "94155199111" } ] }, { "recipient": "gonka14zzmvt5esggym639wk0v8s3gdgdmnjzrh6p7rv", "amount": [ { "denom": "ngonka", "amount": "91598023687" } ] }, { "recipient": "gonka1ksz9raj0yvg7wxdfhuj5474lmjpkzkphu0jw27", "amount": [ { "denom": "ngonka", "amount": "33420242057" } ] }, { "recipient": "gonka1j6ddjngvwy3x0yze36nks8dvlqdep9fxaj67tv", "amount": [ { "denom": "ngonka", "amount": "23781731443" } ] }, { "recipient": "gonka1vlcd8tr2nh5x6h4wl9vacpzucpp9a2p9rv8c57", "amount": [ { "denom": "ngonka", "amount": "19997111815" } ] }, { "recipient": "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "amount": [ { "denom": "ngonka", "amount": "18667380595" } ] }, { "recipient": "gonka1rlf0ggajudsvxuvgkukpmg2xwd06htv4vu2ktx", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka1vkh8e2uqk9mdw0ql83g0p4ge0wmqstcasulngn", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] } ], "vesting_epochs": "180" }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka197hqnwcl30x4js3egvaujjmfknlxy7rmfw3y6k", "amount": [ { "denom": "ngonka", "amount": "2500000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka12jaf7m4eysyqt32mrgarum6z96vt55tckvcleq", "amount": [ { "denom": "ngonka", "amount": "100000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka170gvlkfx4vg267y7mx0d5nexlf3lxs8nktjw75", "amount": [ { "denom": "ngonka", "amount": "100000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1uvk3w9sswd8nnzt29yjyw94vwmuq6g6h8a2fr7", "amount": [ { "denom": "ngonka", "amount": "100000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1ss36q35zmqhpj83vctedd25s34qz7d5vspahay", "amount": [ { "denom": "ngonka", "amount": "100000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1ajxyae8vgzlh3t6frq64e7vj3fnga7vuxt0zhf", "amount": [ { "denom": "ngonka", "amount": "100000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1d5nn7u0hq0pumgmfxk95nj5h3zkuskkdh96dzd", "amount": [ { "denom": "ngonka", "amount": "100000000000" } ] } ] ``` --- ## Upgrade Proposal: v0.2.11 # Upgrade Proposal: v0.2.11 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. ## Upgrade Plan 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`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.11/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. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain. ## Testing 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. ## Migration The on-chain migration logic is defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.11/inference-chain/app/upgrades/v0_2_11/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. ## Changes ### [PR #877](https://github.com/gonka-ai/gonka/pull/877) Inference shards (Experimental) - Introduces subnet-based inference flow, moving per-inference coordination off-chain. - The chain now handles only session setup, escrow, and settlement. - Adds support for subnet state, transport, signing, storage, settlement, and API integration. - **Note:** This feature is currently experimental and under limited access. For reference design and architecture, see [`proposals/inference/`](https://github.com/gonka-ai/gonka/tree/main/proposals/inference). ### [PR #812](https://github.com/gonka-ai/gonka/pull/812) StartInference and FinishInference performance improvements - Reduces unnecessary state writes and query overhead for `MsgStartInference` and `MsgFinishInference`. - Simplifies stats handling and cuts work done during the inference lifecycle for better block execution stability. ### [PR #760](https://github.com/gonka-ai/gonka/pull/760) Unified Permissions - Consolidates message-permission checks across the inference module. - Removes duplicated authorization logic to make permission behavior more explicit and testable. ### [PR #779](https://github.com/gonka-ai/gonka/pull/779) Inference msgs optimization: optimize key verification - Reduces cryptographic verification overhead in the inference message path. - Avoids repeating signature checks where protocol guarantees make them redundant. ### [PR #874](https://github.com/gonka-ai/gonka/pull/874) MsgValidation and MsgClaimRewards performance optimization - Reduces hot-path lookups and adds transient caching in validation and reward-claiming paths. - Restructures validation/reward logic and introduces state pruning support. ### [PR #822](https://github.com/gonka-ai/gonka/pull/822) BLS related fixes based on Certik audit - Applies Certik audit fixes to the BLS module. - Fixes threshold-validation and duplicate-slot handling issues for distributed key generation and threshold-signing flows. ### [PR #814](https://github.com/gonka-ai/gonka/pull/814) IBC Trade Support - Introduces governance-controlled support for trading approved IBC-denominated assets. - Includes chain message/query changes and contract updates for the community sale and liquidity pool. ### [PR #868](https://github.com/gonka-ai/gonka/pull/868) Required-collateral aware slashing flow - Bases slashing penalties on required collateral rather than the full deposited amount. - Makes the slashing model more proportional for participants who over-deposit relative to the minimum. ### [PR #888](https://github.com/gonka-ai/gonka/pull/888) Fix: collateral - Fixes reward calculation for undercollateralized miners, ensuring actual collateral accurately reduces effective earning power. ### [PR #775](https://github.com/gonka-ai/gonka/pull/775) fix: redirect slashed coins to gov - Redirects slashed collateral to governance-controlled destinations. ### Other changes - [PR #867](https://github.com/gonka-ai/gonka/pull/867) Fix the application.db bloat issue. - [PR #835](https://github.com/gonka-ai/gonka/pull/835) Add Batch Transfer With Vesting. - [PR #773](https://github.com/gonka-ai/gonka/pull/773) feat: delete governance model. - [PR #675](https://github.com/gonka-ai/gonka/pull/675) security: update CometBFT to v0.38.21 (CSA-2026-001). - [PR #543](https://github.com/gonka-ai/gonka/pull/543) fix: data race conditions. - [PR #815](https://github.com/gonka-ai/gonka/pull/815) Update CONTRIBUTING.md. - [PR #807](https://github.com/gonka-ai/gonka/pull/807) Update issue templates. ## Proposed Bounties Bounty ID | Sum GNK | Bounty Explanation | GitHub ID -- | -- | -- | -- PR #543 | 2500 | extra bounty for a comprehensive review of all cases where the data race conditions fix was needed | @x0152 Issue #628 | 25000 | PoC integration into vllm v0.11.1 [report](https://github.com/axeltec-software/gonka/tree/axeltec/poc-integration/proposals/poc-integration-vllm-v0.11)  |  [Axel-t](https://www.axel-t.com/), @Red-Caesar -- | 10000 | report of series of prompts resulting in vllm HTTP 502 response, significant impact, was already used for intentoinal greifing | @blizko -- | 1000 | report of dust transaction vulnerability extending blocks | @blizko -- | 5000 | report of Remote DoS of Validator PoC Software via dist Assertion | @ouicate -- | 5000 | report of State Bloat PoC and End-Block DoS via Unbounded Batch / Validation Payloads | @ouicate -- | 750 | report of Bridge Ethereum Address Parsing Silently Falls Back to Zero Bytes (Loss/Misdirection of Funds) | @ouicate PR #775 | 1000 | planned task | @x0152 PR #773 | 1250 | planned task | @x0152 [qdanik/vllm/pull/5](https://github.com/qdanik/vllm/pull/5) | 12000 | vLLM 0.15.1 Compatibility Experiments - basis for next ML node version | @qdanik [qdanik/vllm/pull/6](https://github.com/qdanik/vllm/pull/6) | 15000 | vLLM 0.15.1 Compatibility Experiments - basis for next ML node version. covering simultanious PoC and inference | @qdanik -- | 5000 | report of wind down window vulnerability fixed in PR #767 | @qdanik Issue #797 | 1000 | collective solving of nodes unable to join from snapshots - proposed valuable hypothesis | @akup Issue #797 | 3000 | collective solving of nodes unable to join from snapshots - found source problem | @x0152 Issue #780 | 750 | collective solving StartInference and FinishInference issue | @hleb-albau Issue #781 | 5000 | collective solving StartInference and FinishInference issue | @x0152 Issue #782 | 5000 | collective solving StartInference and FinishInference issue | @akup PR #867 | 7500 | important issue that affected many participants, not a vulnerability, fairly easy fir; adding extra payment for fully testing and providing results of the test together with the fix | @Lelouch33 Issue #730 | 22500 | vLLM 0.15.1 Compatibility Experiments - basis for next ML node version | @clanster, @baychak PR #835 | 5000 | Batch Transfer With Vesting implementation, huge kudos for figuring out how to use testnet | @huxuxuya PR #868 | 5000 | collateral slashing vulnerability and fix; low severity: low risk, medium likelyhood, organic | @qdanik v0.2.11 | 7500 | release management | @akup v0.2.11 | 7500 | release management | @x0152 v0.2.10 | 2500 | upgrade review | @yapion v0.2.10 | 2500 | upgrade review | @blizko v0.2.10 | 2500 | upgrade review | @x0152 --- ## #31 – Upgrade Proposal: v0.2.11 # #31 – Upgrade Proposal: v0.2.11 Passed **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/74f5ff859dd6d83eb8c2576b55c76fa41e669341/proposals/governance-artifacts/update-v0.2.11/README.md](https://github.com/gonka-ai/gonka/blob/74f5ff859dd6d83eb8c2576b55c76fa41e669341/proposals/governance-artifacts/update-v0.2.11/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/31){:target="_blank"} Upgrade Proposal: v0.2.11 --- ## Final Tally Yes 673,699 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 673,699 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.11", "time": "0001-01-01T00:00:00Z", "height": "3186100", "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 }", "upgraded_client_state": null } } ] ``` --- ## Upgrade Proposal: v0.2.7 # Upgrade Proposal: v0.2.7 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. ## Upgrade Plan 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`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.7/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. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. Once the PR is approved by a majority, a `v0.2.7` 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 hosts. Start after upgrade: ``` git pull source config.env && docker compose -f docker-compose.postgres.yml up -d ``` ## Testing The 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. ## Migration The on-chain migration logic is defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.7/inference-chain/app/upgrades/v0_2_7/upgrades.go). Migration sets new parameters: - `GenesisGuardianParams.NetworkMaturityThreshold` = 15,000,000 - `GenesisGuardianParams.NetworkMaturityMinHeight` = 3,000,000 - Guardian addresses migrated from legacy `GenesisOnlyParams` 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: - Epoch 117 rewards for nodes that didn't receive them (but successfully recovered) plus additional reward for all active nodes proportional to the chain halt duration - Bounty program rewards for bug reports ## Changes --- ### Genesis Guardian Enhancement (Temporary) Commits: [3c004c6dd](https://github.com/gonka-ai/gonka/commit/3c004c6dd), [0e5094ca0](https://github.com/gonka-ai/gonka/commit/0e5094ca0), [da1413498](https://github.com/gonka-ai/gonka/commit/da1413498) Temporary reactivation of the Genesis Guardian Enhancement, a previously used defensive mechanism. - Genesis Guardian parameters moved from genesis-only config to governance-controlled params - Network maturity thresholds set: total power >= 15,000,000 AND block height >= 3,000,000 - Guardian addresses migrated from legacy params into governance-updatable `GenesisGuardianParams` - Enhancement automatically deactivates when both maturity conditions are satisfied --- ### Developer Access Restriction Commits: [3c004c6dd](https://github.com/gonka-ai/gonka/commit/3c004c6dd), [ca4b5f92f](https://github.com/gonka-ai/gonka/commit/ca4b5f92f), [fc3d13fb9](https://github.com/gonka-ai/gonka/commit/fc3d13fb9), [d5fae6671](https://github.com/gonka-ai/gonka/commit/d5fae6671) Temporary restriction of inference execution to an allowlisted set of developer addresses. - Inference requests (`MsgStartInference`, `MsgFinishInference`) gated by `requested_by` address - Restriction active until block height 2,294,222 - Allowlist is governance-updatable via `DeveloperAccessParams` - Non-allowlisted developers receive `ErrDeveloperNotAllowlisted` --- ### Participant Access Gating Commits: [1d309fe27](https://github.com/gonka-ai/gonka/commit/1d309fe27), [d1523d1ca](https://github.com/gonka-ai/gonka/commit/d1523d1ca) New participant registration pause and PoC blocklist enforcement. - New host registration (`SubmitNewParticipant`, `SubmitNewUnfundedParticipant`) blocked until height 2,222,222 - PoC blocklist enforced in `MsgSubmitPocBatch` and `MsgSubmitPocValidation` - Adds `MsgAddParticipantsToAllowList`, `MsgRemoveParticipantsFromAllowList`, and `QueryParticipantAllowList` for future governance-controlled epoch allowlist (disabled by default) --- ### PoC Transaction Filtering Commits: [1644047b9](https://github.com/gonka-ai/gonka/commit/1644047b9), [2dbdcca00](https://github.com/gonka-ai/gonka/commit/2dbdcca00) Protocol-level filtering of stale PoC transactions and improved tx-manager reliability. - Ante handler rejects too-late `MsgSubmitPocBatch` and `MsgSubmitPocValidation` during CheckTx - API tx-manager adds block-based deadlines per message type (PoC: 240 blocks, inference: 150 blocks) - Business logic errors (e.g., duplicate validation, participant not found) fail immediately instead of retrying - Batching for `MsgSubmitPocBatch` and `MsgSubmitPocValidation` transactions --- ### Inference Completion Handling Commit: [2c05788d5](https://github.com/gonka-ai/gonka/commit/2c05788d5) Fixes incorrect accounting of failed inference requests. - Malformed or broken payloads no longer cause inferences to be marked as missed - Improves resilience around failed inference handling in the API --- ### Governance-Owned Leftovers Commit: [cf483b34e](https://github.com/gonka-ai/gonka/commit/cf483b34e) Settlement and bitcoin reward remainder accounting. - Expired/unclaimed `SettleAmount` transferred to governance module account instead of burned - Bitcoin rewards: missed-share and rounding remainder transferred to governance and tracked via `BitcoinResult.GovernanceAmount` --- ### Epoch 117 + Bounty Rewards Distribution Commits: [3d8d4caf2](https://github.com/gonka-ai/gonka/commit/3d8d4caf2), [a4828a1d0](https://github.com/gonka-ai/gonka/commit/a4828a1d0) Reward distribution executed during upgrade. - Nodes active during Epoch 117 that didn't receive their epoch reward get the recovered amount - All nodes active during Epoch 117 receive an additional payout proportional to the chain halt duration - Bounty program rewards distributed for reported bugs --- ## #19 – Upgrade Proposal: v0.2.7 # #19 – Upgrade Proposal: v0.2.7 Passed **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/d18165669326fffd6732bc124183a72c076a69ee/proposals/governance-artifacts/update-v0.2.7/README.md](https://github.com/gonka-ai/gonka/blob/d18165669326fffd6732bc124183a72c076a69ee/proposals/governance-artifacts/update-v0.2.7/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/19){:target="_blank"} Upgrade Proposal: v0.2.7 --- ## Final Tally Yes 3,886,156 (96.1%) No 148,604 (3.7%) Veto 8,096 (0.2%) Abstain 0 (0.0%) Total 4,042,856 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.7", "time": "0001-01-01T00:00:00Z", "height": "2054000", "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 }", "upgraded_client_state": null } } ] ``` --- ## Simple Coin Amount Explanation (Epoch 158) # Simple Coin Amount Explanation (Epoch 158) 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 --- ## #32 – Epoch 158 compensation payout from gov module (batch vesting) # #32 – Epoch 158 compensation payout from gov module (batch vesting) 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`](https://gonka.gg/address/gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6){:target="_blank"} **Metadata:** [https://github.com/huxuxuya/epoch158/blob/main/SIMPLE_COIN_AMOUNT_LOGIC.md](https://github.com/huxuxuya/epoch158/blob/main/SIMPLE_COIN_AMOUNT_LOGIC.md) 500 GNK · Community Pool · 30,038 GNK · Gov Module [View on gonka.gg](https://gonka.gg/network/proposals/32){:target="_blank"} Distribute compensation proportional to epoch 158 lost preserved weights. Implemented as one MsgBatchTransferWithVesting. --- ## Final Tally Yes 501,114 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 501,114 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.streamvesting.MsgBatchTransferWithVesting` | | 2 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/inference.streamvesting.MsgBatchTransferWithVesting", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "outputs": [ { "recipient": "gonka10000627dkz6nvmf09ctqy073v0fls696uznwgg", "amount": [ { "denom": "ngonka", "amount": "236153328927" } ] }, { "recipient": "gonka100009u7hegukxy5ne3w6ycfleaj7uuvh2juxqd", "amount": [ { "denom": "ngonka", "amount": "181761590719" } ] }, { "recipient": "gonka10003spukrualhl3h80k9x5m9vrmvlmp8kf4t4w", "amount": [ { "denom": "ngonka", "amount": "217718885065" } ] }, { "recipient": "gonka10008pmwrke48xh42dhe0ul0mm0mhhvz6ta9srs", "amount": [ { "denom": "ngonka", "amount": "244307025251" } ] }, { "recipient": "gonka1000937gjpju4udj2wlj3yld0lcw024tp0ztqew", "amount": [ { "denom": "ngonka", "amount": "228860581905" } ] }, { "recipient": "gonka1000hqfkcp3cs0fq4r78vvpkjlv5n4x4sdgcv7v", "amount": [ { "denom": "ngonka", "amount": "282391370813" } ] }, { "recipient": "gonka1000rv0ddp9yk6djr4y29mt0gu3m4p8mg4kmjcv", "amount": [ { "denom": "ngonka", "amount": "146158804908" } ] }, { "recipient": "gonka1000xjetteyu7gy726vnhdxq69y3meq04gvnk4d", "amount": [ { "denom": "ngonka", "amount": "187129862832" } ] }, { "recipient": "gonka1000xmydnfvphwy4n5yww4ex6nwk9mqslf2gnhs", "amount": [ { "denom": "ngonka", "amount": "185104099770" } ] }, { "recipient": "gonka1000zfcrzdjwwucvs9k2wuy4j5ecj69q5f4v57h", "amount": [ { "denom": "ngonka", "amount": "209767765048" } ] }, { "recipient": "gonka100k8hr43z5vp0fnyc94m7lum6mj4st6vksxz8s", "amount": [ { "denom": "ngonka", "amount": "234380786248" } ] }, { "recipient": "gonka10etnufq85u67k075yuxq6h3rzwlcln5rffhlyx", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka10fvaz7sgva6563fkcp9wxlk5hz7gj8fmu0w699", "amount": [ { "denom": "ngonka", "amount": "178165861284" } ] }, { "recipient": "gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09", "amount": [ { "denom": "ngonka", "amount": "131775887169" } ] }, { "recipient": "gonka10p49jx70haq9uhjy94y80zkfv3xk5pafk5wc5q", "amount": [ { "denom": "ngonka", "amount": "291760524973" } ] }, { "recipient": "gonka10vljxvwy6n9hh263chkt0hj0kg7t0qmdwfrurs", "amount": [ { "denom": "ngonka", "amount": "298800051613" } ] }, { "recipient": "gonka1270mrwh27pgnrtmmsmyy5rsq2h8ug6l4zvg4cu", "amount": [ { "denom": "ngonka", "amount": "179229386891" } ] }, { "recipient": "gonka12gwxa8vcvahyd4ygcxp4624ywaw98wp953wuva", "amount": [ { "denom": "ngonka", "amount": "310802697754" } ] }, { "recipient": "gonka12hzd9zlz3tgslky477d4wa0jlwacv4nj9vxlmj", "amount": [ { "denom": "ngonka", "amount": "302091916588" } ] }, { "recipient": "gonka1450wvd5uugfj7gru4heut5ulnneunplvxs995e", "amount": [ { "denom": "ngonka", "amount": "359269079007" } ] }, { "recipient": "gonka14cu38xpsd8pz5zdkkzwf0jwtpc0vv309ake364", "amount": [ { "denom": "ngonka", "amount": "166619011832" } ] }, { "recipient": "gonka14dkhe6rhy2nq6snmkp2ssnaesumsuwctlmrzcn", "amount": [ { "denom": "ngonka", "amount": "33323802366" } ] }, { "recipient": "gonka14jxtac6gra9cc97q7gw6el2l7f2v2d32f8973x", "amount": [ { "denom": "ngonka", "amount": "157148569518" } ] }, { "recipient": "gonka14pdvgt025fwkf38cr74hhcj2nfl98c044tswya", "amount": [ { "denom": "ngonka", "amount": "93185100842" } ] }, { "recipient": "gonka14qwpw2l0qmevxy9snllfaw0r9svnh4vdyl3897", "amount": [ { "denom": "ngonka", "amount": "86449438662" } ] }, { "recipient": "gonka14s76f83l8m3guvr8vu54dmla798jzy3u09vxzx", "amount": [ { "denom": "ngonka", "amount": "85993641973" } ] }, { "recipient": "gonka14tqh62mangwzrma2lgg2dm375rcjzn2ydy8ttm", "amount": [ { "denom": "ngonka", "amount": "621200242896" } ] }, { "recipient": "gonka155cnj622zfdl64f23ljmk2tzv7tewl6fp4m2hl", "amount": [ { "denom": "ngonka", "amount": "248814348064" } ] }, { "recipient": "gonka15kf06ehfplnqtvgnndyfym9w9f63686cvw3nqj", "amount": [ { "denom": "ngonka", "amount": "157047281365" } ] }, { "recipient": "gonka15mh2v944wxk3phxfkegglpgfpq9mjcm6vmpyng", "amount": [ { "denom": "ngonka", "amount": "179533251351" } ] }, { "recipient": "gonka16324l7r5jllqjm7e5wlf2h44cr3dsmjj8a6py7", "amount": [ { "denom": "ngonka", "amount": "170012164960" } ] }, { "recipient": "gonka168yvlgt9jg86frg2z90cc8w4pz9hnd7f8lshux", "amount": [ { "denom": "ngonka", "amount": "103769712840" } ] }, { "recipient": "gonka16lksjaqq2gqpeexvqg4xgux6hdtms3wnk4jjle", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka16sfwtnse80aleg7sgmumnu3qxhtf93mf86479a", "amount": [ { "denom": "ngonka", "amount": "147323618668" } ] }, { "recipient": "gonka174srhxhfktxx4hv94zcdz4jqfw9kvc4ge2p0pu", "amount": [ { "denom": "ngonka", "amount": "165656774377" } ] }, { "recipient": "gonka178p3vw9zxs885l4a29g3sep0v9uplfq4pzvmrq", "amount": [ { "denom": "ngonka", "amount": "791212407856" } ] }, { "recipient": "gonka17amsnz2csvjwt3rdezys6gj7wggexxwtwt03a9", "amount": [ { "denom": "ngonka", "amount": "105643543672" } ] }, { "recipient": "gonka17nhy0gakmp3yhlrm5h9xghj5mgwgyxagr8zmm0", "amount": [ { "denom": "ngonka", "amount": "22891122598" } ] }, { "recipient": "gonka17w5kpa57jtqnqy7wdp5d03jkjmk0vjwdpp5xmg", "amount": [ { "denom": "ngonka", "amount": "171683419486" } ] }, { "recipient": "gonka184jz8ja5gqkr3kt98a3a4syyypwj07j0qngukg", "amount": [ { "denom": "ngonka", "amount": "29525496625" } ] }, { "recipient": "gonka185kgdje9wjucxtkdu0nqhpqlwxutc5kc7nss8u", "amount": [ { "denom": "ngonka", "amount": "290190558600" } ] }, { "recipient": "gonka18xpmr5v362gwvxlq78twhg7ht07wu4kzdqu4y2", "amount": [ { "denom": "ngonka", "amount": "386819456648" } ] }, { "recipient": "gonka192gv4k5kh88g5s9xll8k7w065lz0rjwh7zj55v", "amount": [ { "denom": "ngonka", "amount": "167479961133" } ] }, { "recipient": "gonka1948n747ayualpznexxchnx95pdnpu25mph804e", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka199lgrq8l9xcqqnr0agajzl78c4dpfvwnsc4elm", "amount": [ { "denom": "ngonka", "amount": "327312666708" } ] }, { "recipient": "gonka19g7jp7tcpnh9ul6gkr3kdc3lmcy55w6swvql0f", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka19mh7jn9xmzz9m0nrczgd32usqrcqm7mpsrh77j", "amount": [ { "denom": "ngonka", "amount": "178469725743" } ] }, { "recipient": "gonka19nsaq8gdavl04mx0v6lhvzzdkqhu6uf56l38w0", "amount": [ { "denom": "ngonka", "amount": "156236976140" } ] }, { "recipient": "gonka1a32tfg0a3xe7zer9m3ttuxr57wdffpc82qnacq", "amount": [ { "denom": "ngonka", "amount": "16256748571" } ] }, { "recipient": "gonka1a3f2cpds29pq0x7yvuh5we233l6aytcgl8gtlx", "amount": [ { "denom": "ngonka", "amount": "383375659443" } ] }, { "recipient": "gonka1a9yz979xxryjh9hdzuyxddscwtg9g92079hjra", "amount": [ { "denom": "ngonka", "amount": "306751171631" } ] }, { "recipient": "gonka1aev99sylsnfzyu2dwlnw6f9lugjkvav7kxqp0k", "amount": [ { "denom": "ngonka", "amount": "49023466095" } ] }, { "recipient": "gonka1ajvs7j8wlgjy8d3kjad520am6jm3a4alj7k4jq", "amount": [ { "denom": "ngonka", "amount": "167631893363" } ] }, { "recipient": "gonka1au034ld8fsrvtyxpzxx8nnnqe5kmhe20lmhuwm", "amount": [ { "denom": "ngonka", "amount": "17269630102" } ] }, { "recipient": "gonka1c8pemd8czpgeg69cu95y58fstuquw93uwqml7f", "amount": [ { "denom": "ngonka", "amount": "385907863270" } ] }, { "recipient": "gonka1cjvdez8e6mwjxg0e3g7rrds9ezm9c7kemlu3g7", "amount": [ { "denom": "ngonka", "amount": "175076572615" } ] }, { "recipient": "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "amount": [ { "denom": "ngonka", "amount": "21371800302" } ] }, { "recipient": "gonka1erjgpt52lp7atyq5c5u5tpprtqjr4pt6zd2pny", "amount": [ { "denom": "ngonka", "amount": "157604366207" } ] }, { "recipient": "gonka1ewlwawmd4z42daay08hspv45nmzlvffw0ums94", "amount": [ { "denom": "ngonka", "amount": "180140980269" } ] }, { "recipient": "gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e", "amount": [ { "denom": "ngonka", "amount": "49327330554" } ] }, { "recipient": "gonka1f5fhrywmd5p0jcd5atk4rm2tjxpdn772lw833k", "amount": [ { "denom": "ngonka", "amount": "277326963158" } ] }, { "recipient": "gonka1f7d43z2qpcv07huwf3qjj4zpssvx6080a357wh", "amount": [ { "denom": "ngonka", "amount": "297280729317" } ] }, { "recipient": "gonka1frfr2z4lclq0wjqsrstnhm48rmvkmd0tfsssvk", "amount": [ { "denom": "ngonka", "amount": "178520369820" } ] }, { "recipient": "gonka1fryp5vn5xppkwykzjul6e2crkgxgwhl2cunrmx", "amount": [ { "denom": "ngonka", "amount": "186724710220" } ] }, { "recipient": "gonka1fs4fapsf05qf3992m92ac3cl38uzh56vev4806", "amount": [ { "denom": "ngonka", "amount": "29474852549" } ] }, { "recipient": "gonka1fvyenm5ms57hmyze8yl659c8ljg4r89nlwap9u", "amount": [ { "denom": "ngonka", "amount": "27601021717" } ] }, { "recipient": "gonka1g884r7q58wptvlcpuk09gvw9j5uhwadr4qjexs", "amount": [ { "denom": "ngonka", "amount": "269173266834" } ] }, { "recipient": "gonka1gsarmv9gsc7g9fv9nsqtk6t0d7erxpurf5mvvl", "amount": [ { "denom": "ngonka", "amount": "313334901581" } ] }, { "recipient": "gonka1gz6d9j834xvhvyt7c67ux6egugns7dlc5dzqds", "amount": [ { "denom": "ngonka", "amount": "315715173179" } ] }, { "recipient": "gonka1h3s37p0l23mg6ak9h9nmayh6r9f2vm6umj3qet", "amount": [ { "denom": "ngonka", "amount": "314246494959" } ] }, { "recipient": "gonka1j3m7rwdjrf44xy8p7ff4w3srqxaml0f73x09ud", "amount": [ { "denom": "ngonka", "amount": "98300152573" } ] }, { "recipient": "gonka1jrkf560tvgqw3f9z4axs9da34lgnrd396e3rs0", "amount": [ { "denom": "ngonka", "amount": "56366857194" } ] }, { "recipient": "gonka1ju7jfznld7vg0f35wgz507m6c0lzgugpmajnvn", "amount": [ { "denom": "ngonka", "amount": "188446608822" } ] }, { "recipient": "gonka1juwk05glldgn7850a3547jsl7l4vrhx9k5g3cr", "amount": [ { "denom": "ngonka", "amount": "195891288074" } ] }, { "recipient": "gonka1k3lva2jsxu5qx30f65yxdlcey8d6f3unmy2gks", "amount": [ { "denom": "ngonka", "amount": "101541373472" } ] }, { "recipient": "gonka1k3xh9h66ye5pdgv2v94xhf7paz445e7qwraz7h", "amount": [ { "denom": "ngonka", "amount": "129344971495" } ] }, { "recipient": "gonka1kjrvy4xme4ctepdjspjdw677nmvdwlps4hl5h8", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka1ks3t0r8g5glvv4um6ml2gy5dzg7l3t2xmp3fg2", "amount": [ { "denom": "ngonka", "amount": "94197982373" } ] }, { "recipient": "gonka1ktl3kkn9l68c9amanu8u4868mcjmtsr5tgzmjk", "amount": [ { "denom": "ngonka", "amount": "169505724195" } ] }, { "recipient": "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "amount": [ { "denom": "ngonka", "amount": "23549495593" } ] }, { "recipient": "gonka1ky9mpdps70l9fe59dg7a7ctnaunkuuc8uet8q2", "amount": [ { "denom": "ngonka", "amount": "176140098222" } ] }, { "recipient": "gonka1l44nacmpmt83kavvevmhlh8elspjtjn6wvwzm0", "amount": [ { "denom": "ngonka", "amount": "667438284781" } ] }, { "recipient": "gonka1l4vfzkwd555pvxqzr3ksphgwgv8xsh89ytmjp0", "amount": [ { "denom": "ngonka", "amount": "1252276080718" } ] }, { "recipient": "gonka1lh0danzlvxm5qtaly7myqd3n5sus0fq92n8shx", "amount": [ { "denom": "ngonka", "amount": "116633308282" } ] }, { "recipient": "gonka1llxvtg0657ldmqn4l3t0ag496ff355j5kawagy", "amount": [ { "denom": "ngonka", "amount": "287557066620" } ] }, { "recipient": "gonka1lqv96tny8a0344e6jfgxk500q5ct7zy9ekz49m", "amount": [ { "denom": "ngonka", "amount": "329996802765" } ] }, { "recipient": "gonka1lrls7q8nu8rhjgchctswfsjlnjh84vwycw3jgt", "amount": [ { "denom": "ngonka", "amount": "318146088853" } ] }, { "recipient": "gonka1lzxwqhc5fqwltg57emk2lprd7qzmapp22mv0h7", "amount": [ { "denom": "ngonka", "amount": "183078336709" } ] }, { "recipient": "gonka1mecj5za64q5cnuu3vaey88g7kn996h2lv8aylu", "amount": [ { "denom": "ngonka", "amount": "316829342863" } ] }, { "recipient": "gonka1myu058axjs62mc3e7na9krwvqpfl9z3gtcw9es", "amount": [ { "denom": "ngonka", "amount": "160744298953" } ] }, { "recipient": "gonka1n5r055hu5tr63rgqs7xg4d45ar8q6yy3qdhn04", "amount": [ { "denom": "ngonka", "amount": "10483323845" } ] }, { "recipient": "gonka1nccp3l8d8n36akvaper2ngzpe8a843key0n985", "amount": [ { "denom": "ngonka", "amount": "36261158806" } ] }, { "recipient": "gonka1p2959dx973hd57qsalxvesrcv649296x90ry76", "amount": [ { "denom": "ngonka", "amount": "418573292641" } ] }, { "recipient": "gonka1p2lhgng7tcqju7emk989s5fpdr7k2c3ek6h26m", "amount": [ { "denom": "ngonka", "amount": "31449971534" } ] }, { "recipient": "gonka1p57jas3hm3gmdvh64z92ycr28z968j0fn6n6jd", "amount": [ { "denom": "ngonka", "amount": "147880703510" } ] }, { "recipient": "gonka1pf4z32nqz5ax7zsxsmf4tan8wsnp957y9t4qtt", "amount": [ { "denom": "ngonka", "amount": "126002462443" } ] }, { "recipient": "gonka1pnfyj6kw3h3v2qu60j42j8h3cuf3jpqqgnaet7", "amount": [ { "denom": "ngonka", "amount": "867026590443" } ] }, { "recipient": "gonka1pvkv59e72vju2h7s9j3ex62c5xneqey350vpwn", "amount": [ { "denom": "ngonka", "amount": "137751888201" } ] }, { "recipient": "gonka1pzdzdgd3auppy7x8a73suxaucgjcutfevrwzjp", "amount": [ { "denom": "ngonka", "amount": "862417979478" } ] }, { "recipient": "gonka1q6v5taltnxxzjrgpheu5t7pfjwmsu6x8gs24sw", "amount": [ { "denom": "ngonka", "amount": "161352027871" } ] }, { "recipient": "gonka1q96dv6st48490vtzx2pwuwkjg439dr4hg6dzjn", "amount": [ { "denom": "ngonka", "amount": "1274458186245" } ] }, { "recipient": "gonka1qjdt3qykdrka2am7s5rtrze44f7y8vccegjc70", "amount": [ { "denom": "ngonka", "amount": "158414671431" } ] }, { "recipient": "gonka1qmlkwzrpv5zkzzpgkthftd29uqg0ka8dddc290", "amount": [ { "denom": "ngonka", "amount": "179533251351" } ] }, { "recipient": "gonka1qre9aepalndahwj37xrcepndmut2vu9dr3kh4t", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka1qvpct2fqwpfqhznwjqs498ggp7wyxjkd4mvxhz", "amount": [ { "denom": "ngonka", "amount": "176190742299" } ] }, { "recipient": "gonka1r34p353cxrvxf3x29raz0x8axflen82a04env4", "amount": [ { "denom": "ngonka", "amount": "304117679650" } ] }, { "recipient": "gonka1r4qetzmw4g3aenwtcxpdm6l42aeq5gzwqltn39", "amount": [ { "denom": "ngonka", "amount": "99211745951" } ] }, { "recipient": "gonka1rcpc45n6zch9qlkn4m3cwngekad89xu8mcr09v", "amount": [ { "denom": "ngonka", "amount": "253119094570" } ] }, { "recipient": "gonka1rk43zfsxe7tefa88qh3t7wl3dvjwn3hq22njc4", "amount": [ { "denom": "ngonka", "amount": "176950403447" } ] }, { "recipient": "gonka1rpedugp4rhy989wfg8tr5ux7k6d4fhkjlqk234", "amount": [ { "denom": "ngonka", "amount": "187737591751" } ] }, { "recipient": "gonka1rt963v04mgt43ju2smuakde99pv7wscy5yxnte", "amount": [ { "denom": "ngonka", "amount": "172595012864" } ] }, { "recipient": "gonka1shc0ywxd993zz3w3h5xdp5uhgu9rv27ws7mmqx", "amount": [ { "denom": "ngonka", "amount": "251042687432" } ] }, { "recipient": "gonka1slnscxc26qm7vvpn5qs9yzq9n0l82r4ywkl054", "amount": [ { "denom": "ngonka", "amount": "17117697872" } ] }, { "recipient": "gonka1tvjdvlf3jmc48ckycguvdvlepgj7jgx9q5m2aw", "amount": [ { "denom": "ngonka", "amount": "86854591274" } ] }, { "recipient": "gonka1u60q4n3ymcglvhglylchpyvc04kvvurl967mgk", "amount": [ { "denom": "ngonka", "amount": "16712545260" } ] }, { "recipient": "gonka1uk73fw4tnfv9rfdeekxycvt0v8cncr64syejra", "amount": [ { "denom": "ngonka", "amount": "153704772313" } ] }, { "recipient": "gonka1un2c9f66mg2g6xcpmulq9tqfs3vjd7nn0ftjs5", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka1uv8lw89ththtj05c54wehfnqls9u2pza53q33z", "amount": [ { "denom": "ngonka", "amount": "173101453629" } ] }, { "recipient": "gonka1v425qs8gxupjcw3lqx5fsldtve88vd9gaa7r60", "amount": [ { "denom": "ngonka", "amount": "345240669804" } ] }, { "recipient": "gonka1v5ggga7lslfg2e57m9anxud40v2s4t9dw8yj68", "amount": [ { "denom": "ngonka", "amount": "913213988252" } ] }, { "recipient": "gonka1vkafyzr5yz5aht6gzapw6lc52h5wwmnrjwvqlz", "amount": [ { "denom": "ngonka", "amount": "345645822417" } ] }, { "recipient": "gonka1vkh8e2uqk9mdw0ql83g0p4ge0wmqstcasulngn", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka1vn6hk34wme5xvqzjmm26u9snkxg7nqd490gmwq", "amount": [ { "denom": "ngonka", "amount": "347013212484" } ] }, { "recipient": "gonka1vwsp87trl60t4g67fa677k7d7jztuc3g4qjc3w", "amount": [ { "denom": "ngonka", "amount": "383578235749" } ] }, { "recipient": "gonka1vxs4azxcym36wts0t7z5nj65ma8pnkvpmywxa0", "amount": [ { "denom": "ngonka", "amount": "82701776997" } ] }, { "recipient": "gonka1w2pxkv4v6r5h6sdvges287l2g5rsd3r4x77080", "amount": [ { "denom": "ngonka", "amount": "17320274178" } ] }, { "recipient": "gonka1w3ewq7swwdxx8fsht8tl250f7qv44edhlltrh8", "amount": [ { "denom": "ngonka", "amount": "210020985430" } ] }, { "recipient": "gonka1w6cjf08fgm3yalqf7ytt0hz6thlhs53d2fn7j2", "amount": [ { "denom": "ngonka", "amount": "10331391615" } ] }, { "recipient": "gonka1xteg3zgysvkvfl4lzs5gwxpkgtx0qra6m90jv3", "amount": [ { "denom": "ngonka", "amount": "75712894434" } ] }, { "recipient": "gonka1y29s2ckdl0csktxhpx77a7dvwyhj9u4xyrcynm", "amount": [ { "denom": "ngonka", "amount": "183483489321" } ] }, { "recipient": "gonka1y95qr73kms3zv5ju0kxtu58ksxdyrkyz8m0430", "amount": [ { "denom": "ngonka", "amount": "186522133914" } ] }, { "recipient": "gonka1yk34z38t92jzjgq2ga7tkfpj07sf4ss3tj6n2m", "amount": [ { "denom": "ngonka", "amount": "157705654360" } ] }, { "recipient": "gonka1ypy2ygsa7se9lrcwxlstgwsy0lfged0kg8ft95", "amount": [ { "denom": "ngonka", "amount": "197056101835" } ] }, { "recipient": "gonka1yq4vwn7fc9x7lykjhc0x3e7r2atee32czy34mt", "amount": [ { "denom": "ngonka", "amount": "31956412300" } ] }, { "recipient": "gonka1yquunstmnn35tuc6wsrlv020ul2rnuyldqkt37", "amount": [ { "denom": "ngonka", "amount": "991104577978" } ] }, { "recipient": "gonka1z3kelh3gx3t6kz303f8trdll3j5ap3zz8csyfm", "amount": [ { "denom": "ngonka", "amount": "52416619224" } ] }, { "recipient": "gonka1z4ldfav9tl7x3w9aqfry89zd0kt7sa2lhff6te", "amount": [ { "denom": "ngonka", "amount": "512771275014" } ] } ], "vesting_epochs": "180" }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1t7mcnc8zjkkvhwmfmst54sasulj68e5zsv4yzu", "amount": [ { "denom": "ngonka", "amount": "500000000000" } ] } ] ``` --- ## #30 – Test Proposal # #30 – Test Proposal Rejected **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`](https://gonka.gg/address/gonka1awyggfq4e32d4y66ttq3hyud7dyrr0ajf8af0w){:target="_blank"} **Metadata:** `Test proposal for governance UI` **Failed reason:** proposal did not get enough votes to pass [View on gonka.gg](https://gonka.gg/network/proposals/30){:target="_blank"} Testing governance voting from the wallet app. --- ## Final Tally Yes 0 (0.0%) No 47 (100.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 47 votes ## Messages | # | Type | | :- | :--- | Contract Details ```json [] ``` --- ## #22 – Allowlist Timing # #22 – Allowlist Timing Passed **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/22){:target="_blank"} Update Expiration Dates for Developer Access and Participant Allowlist --- ## Final Tally Yes 3,476,742 (99.9%) No 2,836 (0.1%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 3,479,578 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "60", "poc_exchange_duration": "5", "poc_validation_delay": "5", "poc_validation_duration": "120", "set_new_validators_delay": "120", "inference_validation_cutoff": "20", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": { "value": "25", "exponent": -1 }, "model_params": { "dim": 1792, "n_layers": 64, "n_heads": 64, "n_kv_heads": 64, "vocab_size": 8196, "ffn_dim_multiplier": { "value": "1", "exponent": 1 }, "multiple_of": 8192, "norm_eps": { "value": "1", "exponent": -5 }, "rope_theta": 10000, "use_scaled_rope": false, "seq_len": 256, "r_target": { "value": "1398077", "exponent": -6 } }, "model_id": "", "seq_len": "0", "poc_v2_enabled": false, "confirmation_poc_v2_enabled": false, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2443558", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2443558" }, "transfer_agent_access_params": null, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } } ] ``` --- ## 2025-Q3 Proposals # 2025-Q3 Proposals Passed Rejected Voting With Funding ## 2025-Q3 Summary 6Total Proposals 5Passed (83%) 1Rejected (17%) Governance Parameters3 Software Upgrade2 Models / IBC1 2025-Q3 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%) ← Back to all proposals --- ## Increase PoC Validation Duration # Increase PoC Validation Duration This proposal changes the following parameter: - `inference.epoch_params.poc_validation_duration` from `20` to `120`. ## Motivation 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. --- ## #3 – Increase PoC Validation Length # #3 – Increase PoC Validation Length 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/2bf281cec95eaef061e2dfe46d4d104a7e1c2229/proposals/poc-validation-length/README.md](https://github.com/gonka-ai/gonka/blob/2bf281cec95eaef061e2dfe46d4d104a7e1c2229/proposals/poc-validation-length/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/3){:target="_blank"} Proposal updates poc_validation_duration from 20 to 100. --- ## Final Tally Yes 162,514 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 162,514 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "60", "poc_exchange_duration": "5", "poc_validation_delay": "5", "poc_validation_duration": "120", "set_new_validators_delay": "120", "inference_validation_cutoff": "80", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "0", "poc_pruning_max": "0", "poc_slot_allocation": null, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "20", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "60", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": null, "bad_participant_invalidation_rate": null, "invalidation_h_threshold": null, "downtime_good_percentage": null, "downtime_bad_percentage": null, "downtime_h_threshold": null, "downtime_reputation_preserve": null, "quick_failure_threshold": null, "binom_test_p0": null, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": false, "confirmation_poc_v2_enabled": false, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "0" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "10752", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "0", "invalidations_sample_period": "0", "invalidations_limit_curve": "0", "minimum_concurrent_invalidations": 0, "max_inferences_per_block": "0" }, "confirmation_poc_params": null, "genesis_guardian_params": null, "developer_access_params": null, "participant_access_params": null, "transfer_agent_access_params": null, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } } ] ``` --- ## Adjust Params According to real block length # Adjust Params According to real block length 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` ## Motivation 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. ## New values estimations At `/chain-rpc/status` we can get (for genesis nodes): ``` "latest_block_height": "223562", "latest_block_time": "2025-09-05T21:17:32.061238117Z", ... "earliest_block_height": "1", "earliest_block_time": "2025-08-22T08:42:00.713839Z", ``` Then: - `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` --- ## #1 – Correct Epoch Length # #1 – Correct Epoch Length 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/9f34f2c3c8203d8ae269934facaa79069f4d8012/proposals/epoch-length/README.md](https://github.com/gonka-ai/gonka/blob/9f34f2c3c8203d8ae269934facaa79069f4d8012/proposals/epoch-length/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/1){:target="_blank"} Proposal updates epoch_length and restrictions length according to real block length in seconds. --- ## Final Tally Yes 74,474 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 74,474 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | | 2 | `/inference.restrictions.MsgUpdateParams` | | 3 | `/cosmos.mint.v1beta1.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "60", "poc_exchange_duration": "5", "poc_validation_delay": "5", "poc_validation_duration": "20", "set_new_validators_delay": "120", "inference_validation_cutoff": "80", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "0", "poc_pruning_max": "0", "poc_slot_allocation": null, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "20", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "60", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": null, "bad_participant_invalidation_rate": null, "invalidation_h_threshold": null, "downtime_good_percentage": null, "downtime_bad_percentage": null, "downtime_h_threshold": null, "downtime_reputation_preserve": null, "quick_failure_threshold": null, "binom_test_p0": null, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": false, "confirmation_poc_v2_enabled": false, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "0" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "10752", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "0", "invalidations_sample_period": "0", "invalidations_limit_curve": "0", "minimum_concurrent_invalidations": 0, "max_inferences_per_block": "0" }, "confirmation_poc_params": null, "genesis_guardian_params": null, "developer_access_params": null, "participant_access_params": null, "transfer_agent_access_params": null, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } }, { "@type": "/inference.restrictions.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "restriction_end_block": "1385263", "emergency_transfer_exemptions": [], "exemption_usage_tracking": [] } }, { "@type": "/cosmos.mint.v1beta1.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "mint_denom": "ngonka", "inflation_rate_change": "0.130000000000000000", "inflation_max": "0.200000000000000000", "inflation_min": "0.070000000000000000", "goal_bonded": "0.670000000000000000", "blocks_per_year": "5618012" } } ] ``` --- ## Upgrade Proposal: v0.2.2 # Upgrade Proposal: v0.2.2 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. ## Upgrade Plan 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. ## Testing ### Testnet 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. ### Migration on real chain data 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. ## Changes ### Exact token enforcement in Completion API (`3f49d869d9b4d70b0c0ac8d783fec65745978592`) 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. ### Potential vulnerability in `POST /v1/participants` (`2927b241616ba08ae596dc1e029746f6c219c443`) 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. ### Prevent negative-coin panics in keeper flows (`f0ed9b331b2a60a88d34bdc04dc503f61e81ad67`) 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. ### Missed validations recovery before claim (`801299d4bac47e5267451bdbebb9f46c6bc4c3b1`) #### Problem 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: - Gaps in inference validation coverage. - Potentially lower reputation and compute credit for participants. - Inconsistent incentives between those who missed validations for legitimate reasons and those who didn’t. - A risk that some invalid inferences remain undetected if they were missed by validators. #### Solution 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. ### On-chain MLNode versioning and partial upgrades (`b2ef4fbe355431ad31d72b22aa062dce4892bfbd`) This commit introduces a mechanism for automatic on-chain upgrades of MLNode containers. The upgrade is enabled by: **Architecture Overview:** ``` ┌─────────────────┐ ┌──────────────┐ ┌─────────────────┐ │ decentralized- │───▶│ ML Proxy │───▶│ MLNode v3.0.8 │ │ api │ │ (NGINX) │ │ (old version) │ └─────────────────┘ │ │ └─────────────────┘ │ │ ┌─────────────────┐ │ │───▶│ MLNode v3.0.10 │ └──────────────┘ │ (new version) │ └─────────────────┘ ``` #### Key Changes: - MLNode version is now stored on-chain and managed by partial upgrades. - The `api` service fetches the version at startup and updates automatically when an upgrade height is reached. - The `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. - Fixed a bug where partial upgrades were ignored because the `Name` field was empty. - Removed local version plan storage from the `api` config. - Refactored and stabilized `testermint` integration tests to reduce flakiness. - Adds an upgrade handler and migration for the on-chain upgrade. ### Dynamic Docker address resolution for proxy (`2845b898bd48b7203bd7f3302781faf4f160f900`) - Dynamically resolves MLNode upstream in the NGINX template/entrypoint. - Updates `deploy/join/nginx.conf` and proxy scripts for container networks. - Improves robustness across host/container setups. ### Fix: Additional check for nonce duplicates on-chain (`b7d7600ec49ced4dfbedf6c01305aa5205f8d78`) 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. ### Fix: Preventing generation of nonce duplicates (`1ae494372cb216046ab25ee179e3c21f392c5329`) `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`. ### Proposals for new way to validation inference `dee011bfbc41f43cefde0c64b1efc6746976e01e` ### Paginator fixes `ecdfb135773f1e4854468a0e7585bd54bfe1d9fd` 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. #### Key Changes * **`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. ### Multiple Fixes and Security Improvements (`3ea3e5b5b1aa758e29741d5a5312dd41be10bf95`) The commit introduces multiple fixes and security improvements: #### Missed `node_id` to PoCBatch (`inference-chain/x/inference/keeper/msg_server_submit_poc_batch.go`) `node_id` is used to detect which node produced the nonce's batch #### Remove legacy weight distribution from batches without `node_id` `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 #### Remove MLNodes without HardwareNodes or models supported by Governance `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 #### Statistical Validation for Missed inference and validation 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 #### Set Participant status to `ACTIVE` for all ActiveParticipant when switch epoch `inference-chain/x/inference/module/module.go:moveUpcomingToEffectiveGroup` #### Fix counter for successful inferences `inference-chain/x/inference/keeper/msg_server_start_inference.go` `inference-chain/x/inference/keeper/msg_server_finish_inference.go` #### Fix for interrupted inference validation #### Logging ### Accept Claim only from CurrentEpoch -1 (`c8e6aefcf88958f5f2968cc9f305e1d6c0028dcd`) --- ## #6 – Upgrade Proposal: v0.2.2 # #6 – Upgrade Proposal: v0.2.2 Passed **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/422dd37c36ad65bc3be2c84cd18a4d86e7ddec10/proposals/governance-artifacts/update-v0.2.2/README.md](https://github.com/gonka-ai/gonka/blob/422dd37c36ad65bc3be2c84cd18a4d86e7ddec10/proposals/governance-artifacts/update-v0.2.2/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/6){:target="_blank"} Upgrade Proposal: v0.2.2 --- ## Final Tally Yes 130,079 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 130,079 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.2", "time": "0001-01-01T00:00:00Z", "height": "517935", "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 }", "upgraded_client_state": null } } ] ``` --- ## New supported models # New supported models 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-32B` - `RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16` - replacement for `Qwen/Qwen2.5-7B-Instruct` (minor improvement to get rid of fully dynamic quantization) ## New values estimations The methodology for computing the thresholds is detailed in the [thresholds_sep2025.ipynb](./thresholds_sep2025.ipynb). A reproducible version of this notebook is available in the project repository at [/mlnode/packages/benchmarks/notebooks/thresholds_sep2025.ipynb](../../..//mlnode/packages/benchmarks/notebooks/thresholds_sep2025.ipynb). The data used for our experiments is available for verification [link](https://drive.google.com/drive/folders/1ehpcVC0pGw0XwrchXZUxTTRy1KdhBxrz?usp=drive_link). For maximum confidence, participants are encouraged to recompute the thresholds independently using the provided notebook. - All experiments were conducted using MLNode `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. ## Release process 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. --- ## #2 – Proposal introducing new Qwen3 models # #2 – Proposal introducing new Qwen3 models 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/c8668fd0f6144109165e0386f55fe22eb3cb27c7/proposals/governance-artifacts/models-1/README.md](https://github.com/gonka-ai/gonka/blob/c8668fd0f6144109165e0386f55fe22eb3cb27c7/proposals/governance-artifacts/models-1/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/2){:target="_blank"} 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. --- ## Final Tally Yes 62,612 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 62,612 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgRegisterModel` | | 2 | `/inference.inference.MsgRegisterModel` | | 3 | `/inference.inference.MsgRegisterModel` | | 4 | `/inference.inference.MsgRegisterModel` | | 5 | `/inference.inference.MsgRegisterModel` | Contract Details ```json [ { "@type": "/inference.inference.MsgRegisterModel", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "proposed_by": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "id": "Qwen/Qwen2.5-7B-Instruct", "units_of_compute_per_token": "100", "hf_repo": "Qwen/Qwen2.5-7B-Instruct", "hf_commit": "a09a35458c702b33eeacc393d103063234e8bc28", "model_args": [ "--quantization", "fp8" ], "v_ram": "24", "throughput_per_nonce": "20000", "validation_threshold": { "value": "97", "exponent": -2 } }, { "@type": "/inference.inference.MsgRegisterModel", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "proposed_by": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "id": "Qwen/QwQ-32B", "units_of_compute_per_token": "1000", "hf_repo": "Qwen/QwQ-32B", "hf_commit": "976055f8c83f394f35dbd3ab09a285a984907bd0", "model_args": [ "--quantization", "fp8", "--kv-cache-dtype", "fp8" ], "v_ram": "80", "throughput_per_nonce": "6000", "validation_threshold": { "value": "97", "exponent": -2 } }, { "@type": "/inference.inference.MsgRegisterModel", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "proposed_by": "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "id": "RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16", "units_of_compute_per_token": "100", "hf_repo": "RedHatAI/Qwen2.5-7B-Instruct-quantized.w8a16", "hf_commit": "a5609cbf939e46f4c17f189100d5e6825da318b0", "model_args": [], "v_ram": "24", "throughput_per_nonce": "20000", "validation_threshold": { "value": "991429", "exponent": -6 } }, { "@type": "/inference.inference.MsgRegisterModel", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "proposed_by": "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "id": "Qwen/Qwen3-32B-FP8", "units_of_compute_per_token": "1000", "hf_repo": "Qwen/Qwen3-32B-FP8", "hf_commit": "aa55da1ecc13d006e8b8e4f54579b1ea8c3db2df", "model_args": [], "v_ram": "80", "throughput_per_nonce": "6000", "validation_threshold": { "value": "95814", "exponent": -5 } }, { "@type": "/inference.inference.MsgRegisterModel", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "proposed_by": "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "id": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", "units_of_compute_per_token": "10000", "hf_repo": "Qwen/Qwen3-235B-A22B-Instruct-2507-FP8", "hf_commit": "c0eb82898e3da8fb6dd017e3e6698a5e37b3a3e6", "model_args": [ "--max-model-len", "240000" ], "v_ram": "320", "throughput_per_nonce": "1500", "validation_threshold": { "value": "970917", "exponent": -6 } } ] ``` --- ## #5 – Expedite voting for upgrades # #5 – Expedite voting for upgrades 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/5){:target="_blank"} Expedite voting for upgrades --- ## Final Tally Yes 172,265 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 172,265 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.gov.v1.MsgUpdateParams` | Contract Details ```json [ { "@type": "/cosmos.gov.v1.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "min_deposit": [ { "denom": "ngonka", "amount": "25000000" } ], "max_deposit_period": "10800s", "voting_period": "10800s", "quorum": "0.334000000000000000", "threshold": "0.500000000000000000", "veto_threshold": "0.334000000000000000", "min_initial_deposit_ratio": "0.000000000000000000", "proposal_cancel_ratio": "0.500000000000000000", "proposal_cancel_dest": "", "expedited_voting_period": "5400s", "expedited_threshold": "0.667000000000000000", "expedited_min_deposit": [ { "denom": "ngonka", "amount": "50000000" } ], "burn_vote_quorum": false, "burn_proposal_deposit_prevote": false, "burn_vote_veto": true, "min_deposit_ratio": "0.010000000000000000" } } ] ``` --- ## Upgrade Proposal 1 # Upgrade Proposal 1 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. ## Upgrade Plan 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. ## Testing ### Testnet 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. ### Migration on real chain data 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. ## Changes ### Exact token enforcement in Completion API (`3f49d869d9b4d70b0c0ac8d783fec65745978592`) 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. ### Potential vulnerability in `POST /v1/participants` (`2927b241616ba08ae596dc1e029746f6c219c443`) 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. ### Prevent negative-coin panics in keeper flows (`f0ed9b331b2a60a88d34bdc04dc503f61e81ad67`) 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. ### Missed validations recovery before claim (`801299d4bac47e5267451bdbebb9f46c6bc4c3b1`) #### Problem 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: - Gaps in inference validation coverage. - Potentially lower reputation and compute credit for participants. - Inconsistent incentives between those who missed validations for legitimate reasons and those who didn’t. - A risk that some invalid inferences remain undetected if they were missed by validators. #### Solution 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. ### On-chain MLNode versioning and partial upgrades (`b2ef4fbe355431ad31d72b22aa062dce4892bfbd`) This commit introduces a mechanism for automatic on-chain upgrades of MLNode containers. The upgrade is enabled by: **Architecture Overview:** ``` ┌─────────────────┐ ┌──────────────┐ ┌─────────────────┐ │ decentralized- │───▶│ ML Proxy │───▶│ MLNode v3.0.8 │ │ api │ │ (NGINX) │ │ (old version) │ └─────────────────┘ │ │ └─────────────────┘ │ │ ┌─────────────────┐ │ │───▶│ MLNode v3.0.10 │ └──────────────┘ │ (new version) │ └─────────────────┘ ``` #### Key Changes: - MLNode version is now stored on-chain and managed by partial upgrades. - The `api` service fetches the version at startup and updates automatically when an upgrade height is reached. - The `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. - Fixed a bug where partial upgrades were ignored because the `Name` field was empty. - Removed local version plan storage from the `api` config. - Refactored and stabilized `testermint` integration tests to reduce flakiness. - Adds an upgrade handler and migration for the on-chain upgrade. ### Dynamic Docker address resolution for proxy (`2845b898bd48b7203bd7f3302781faf4f160f900`) - Dynamically resolves MLNode upstream in the NGINX template/entrypoint. - Updates `deploy/join/nginx.conf` and proxy scripts for container networks. - Improves robustness across host/container setups. ### Fix: Additional check for nonce duplicates on-chain (`b7d7600ec49ced4dfbedf6c01305aa5205f8d78`) 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. ### Fix: Preventing generation of nonce duplicates (`1ae494372cb216046ab25ee179e3c21f392c5329`) `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`. ### Proposals for new way to validation inference `dee011bfbc41f43cefde0c64b1efc6746976e01e` --- ## #4 – Upgrade Proposal: v0.2.2 # #4 – Upgrade Proposal: v0.2.2 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/f0f3301dadae0a2f30bdc2968bebb21da81026f4/proposals/governance-artifacts/update-v0.2.2/README.md](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](https://gonka.gg/network/proposals/4){:target="_blank"} Upgrade Proposal: v0.2.2 --- ## Final Tally Yes 109 (0.1%) No 0 (0.0%) Veto 109,637 (99.9%) Abstain 0 (0.0%) Total 109,746 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.2", "time": "0001-01-01T00:00:00Z", "height": "512000", "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 }", "upgraded_client_state": null } } ] ``` --- ## 2026-Q3 Proposals # 2026-Q3 Proposals Passed Rejected Voting With Funding ## 2026-Q3 Summary 12Total Proposals 7Passed (58%) 5Rejected (42%) Governance Parameters5 Funding / Grants5 Software Upgrade1 GRC / Restitution1 80,000 GNK · $88,000 · Community Pool 2026-Q3 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) ← Back to all proposals --- ## #87 – Remove Kimi K2.6 model # #87 – Remove Kimi K2.6 model Passed **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`](https://gonka.gg/address/gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/87){:target="_blank"} Remove moonshotai/Kimi-K2.6 from PoC params and delete it from the governance model list. --- ## Final Tally 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) ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | | 2 | `/inference.inference.MsgDeleteGovernanceModel` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "35", "poc_exchange_duration": "0", "poc_validation_delay": "5", "poc_validation_duration": "240", "set_new_validators_delay": "120", "inference_validation_cutoff": "2", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "500" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "processed_logprobs" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": true, "confirmation_poc_v2_enabled": true, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": true, "poc_stronger_rng_enabled": false, "models": [ { "model_id": "MiniMaxAI/MiniMax-M2.7", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "75", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "3024", "exponent": -4 }, "penalty_start_epoch": "278" }, { "model_id": "zai-org/GLM-5.2-FP8", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "45", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "247", "exponent": -2 }, "penalty_start_epoch": "500" } ], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2475000", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2475000" }, "transfer_agent_access_params": { "allowed_transfer_addresses": [ "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u" ] }, "devshard_escrow_params": { "min_amount": "50000000", "max_amount": "100000000000", "max_escrows_per_epoch": 500000, "group_size": 16, "allowed_creator_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk", "gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90", "gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c", "gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn", "gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp" ], "token_price": "10", "approved_versions": [ { "name": "v1", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip", "sha256": "dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c" }, { "name": "v2", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip", "sha256": "1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b" }, { "name": "v3", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v3.0.0/devshardd.zip", "sha256": "ca1294fc8db3f0907a01f362eb4b13665f66d0fd12cfc6f01468b1e27f0bab63" } ], "max_nonce": 1000000, "devshard_requests_enabled": true, "default_inference_seal_grace_nonces": 0, "default_inference_seal_grace_seconds": 0, "create_devshard_fee": "0", "fee_per_nonce": "0", "refusal_timeout": "0", "execution_timeout": "0", "validation_rate": 0, "vote_threshold_factor": 0, "default_auto_seal_every_n_nonces": 0 }, "fee_params": { "min_gas_price_ngonka": "0", "base_validation_gas": "500000", "gas_per_poc_count": "100" }, "delegation_params": { "deploy_window": "500", "refusal_penalty": { "value": "1", "exponent": -1 }, "no_participation_penalty": { "value": "15", "exponent": -2 }, "delegation_share": { "value": "5", "exponent": -2 }, "w_threshold": { "value": "1", "exponent": -1 }, "v_min": "3", "cap_factor": { "value": "75", "exponent": -2 }, "initial_model_id": "MiniMaxAI/MiniMax-M2.7", "max_model_voting_power_percentage": { "value": "3", "exponent": -1 } }, "maintenance_params": null } }, { "@type": "/inference.inference.MsgDeleteGovernanceModel", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "id": "moonshotai/Kimi-K2.6" } ] ``` --- ## #91 – Temporarily update BLS signing parameters # #91 – Temporarily update BLS signing parameters 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`](https://gonka.gg/address/gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/91){:target="_blank"} 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. --- ## Final Tally 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) Voters VoterVote gonka1y2a9p5…ryv5leYes 100.0% gonka1gvrrhj…d2v4zrYes 100.0% gonka1dkl4ma…y552cpYes 100.0% gonka1kx9mca…nm6wc5Yes 100.0% --- ## Messages | # | Type | | :- | :--- | | 1 | `/inference.bls.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.bls.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "i_total_slots": 100, "t_slots_degree_offset": 50, "dealing_phase_duration_blocks": "5", "verification_phase_duration_blocks": "3", "signing_deadline_blocks": "923460", "dispute_phase_duration_blocks": "3", "completed_fallback_blocks": "0", "max_signing_attempts": 1 } } ] ``` --- ## GRC Proposal #3 - Restitution # GRC Proposal #3 - Restitution This proposal closes the confirmed GRC3 restitution package, separating committee-confirmed damage into victim restitution and committee work/bounty payments. ## Executive Summary 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 | One `MsgBatchTransferWithVesting` 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. ## Final Victim Settlement The victim settlement uses exact same-address, same-epoch P4 overlap deductions: ``` final_payout = max(planned_amount - p4_paid_overlap, 0) ``` | Metric | Amount / Count | |---|---:| | Committee-confirmed damage before overlap deductions | 99773.810455897 GNK | | Exact P4 paid overlap | 34944.788622168 GNK | | Deducted from Proposal #3 payout | 29619.785787646 GNK | | P4 overpaid amount recorded for audit only | 5325.002834522 GNK | | Final victim payout | 70154.024668251 GNK | | Chain minimum top-up for positive outputs below 10 GNK | 30.808440219 GNK | | Victim chain transfer total | 70184.833108470 GNK | | Settlement rows | 47 | | Unique planned recipients | 44 | | Positive chain recipients after zeroed overlaps | 40 | | Rows with exact P4 overlap | 7 | Rows 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. ## GRC Case Review | 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 | ## Committee Work Package 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 | ## Chain Payload 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 ## Verification 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 ## Source Full audit trail, payout breakdown, and chain-ready JSON: - GitHub: [https://github.com/huxuxuya/GRC-3-result](https://github.com/huxuxuya/GRC-3-result) - Dashboard: [https://huxuxuya.github.io/GRC-3-result/](https://huxuxuya.github.io/GRC-3-result/) --- ## #80 – GRC Proposal #3 - Restitution # #80 – GRC Proposal #3 - Restitution 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`](https://gonka.gg/address/gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6){:target="_blank"} **Metadata:** [https://github.com/huxuxuya/GRC-3-result](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 Module [View on gonka.gg](https://gonka.gg/network/proposals/80){:target="_blank"} 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. --- ## Final Tally 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) ## Messages | # | 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 ```json [ { "@type": "/inference.streamvesting.MsgBatchTransferWithVesting", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "outputs": [ { "recipient": "gonka10079cnl3nuh2k82mhkm04dj0slhtw9kmjewwau", "amount": [ { "denom": "ngonka", "amount": "5890493167171" } ] }, { "recipient": "gonka1007dchuqgdnute4qam70kmn56j2vfw38mhyrqv", "amount": [ { "denom": "ngonka", "amount": "7287485958471" } ] }, { "recipient": "gonka1007g0ut3u4wjkay9hegqfev4pj90qgexwskmcw", "amount": [ { "denom": "ngonka", "amount": "7238152949000" } ] }, { "recipient": "gonka105ce4495mj0mwkxqeasgdzqfq5jjrfq32eza5l", "amount": [ { "denom": "ngonka", "amount": "14096689777" } ] }, { "recipient": "gonka10kmsyy00yxnky2xfqy9wce0l7uaadq4jjp3ykg", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09", "amount": [ { "denom": "ngonka", "amount": "16028213179615" } ] }, { "recipient": "gonka12l3fwycgvs9tdpze59za89zq4cexhkxddafxdh", "amount": [ { "denom": "ngonka", "amount": "150749450599" } ] }, { "recipient": "gonka14ljarev2nlzu4ej50vx7ylj2rvg4n20fnq2ysc", "amount": [ { "denom": "ngonka", "amount": "79662604523" } ] }, { "recipient": "gonka1598sglu00mktw3973jmwsu3vdw29mgcfjleju2", "amount": [ { "denom": "ngonka", "amount": "71065864191" } ] }, { "recipient": "gonka15fpzwc7d2z3r4y5475p6k7uqknnkj38gsus3d9", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka15munkmx6x7k6rqqeexjet4556p7at39ks9qgr5", "amount": [ { "denom": "ngonka", "amount": "4064625997098" } ] }, { "recipient": "gonka16xa2sdc8qe2289nzr4e6vmdyzlke8g8fn8e75s", "amount": [ { "denom": "ngonka", "amount": "69342202123" } ] }, { "recipient": "gonka170wwtpvhwzgghd638z84z35gjggl7cvyzrkh8p", "amount": [ { "denom": "ngonka", "amount": "156696892692" } ] }, { "recipient": "gonka17pw6099q758qwzewtrqmqpf5c2lrhr97fwqexu", "amount": [ { "denom": "ngonka", "amount": "923163292052" } ] }, { "recipient": "gonka19nd876302m3ll2h7sd55hp9pqzv2hpqalh8pjj", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka1amlmhjym02shahjv8ldmupg4cx0qc66q6f85rj", "amount": [ { "denom": "ngonka", "amount": "217372045879" } ] }, { "recipient": "gonka1ce02jjduga8jvwj8jx39mxn0jr345vgkx7lk2n", "amount": [ { "denom": "ngonka", "amount": "1975688510632" } ] }, { "recipient": "gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0", "amount": [ { "denom": "ngonka", "amount": "113179188133" } ] }, { "recipient": "gonka1duuaqdx06sx8v2dzggltwwmqyuw8lvjkjq7xll", "amount": [ { "denom": "ngonka", "amount": "161268199400" } ] }, { "recipient": "gonka1fvly5jrewyjmjfgwah3khy9rttq4cqajcesv9p", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka1gyk0aahvr3qeju4zx0nplfreej6cy4jjk8svc5", "amount": [ { "denom": "ngonka", "amount": "83791459026" } ] }, { "recipient": "gonka1h9asnq9x2kux2m8pcwaeegljzmd4ym4h26p07n", "amount": [ { "denom": "ngonka", "amount": "33560566095" } ] }, { "recipient": "gonka1hjjse9r0zfe0q8k4hfe4t5xuzstjqvky7dnj05", "amount": [ { "denom": "ngonka", "amount": "56561388067" } ] }, { "recipient": "gonka1hmjjq6ghykww8f8ujajnnmu2dpk2drrth8mtva", "amount": [ { "denom": "ngonka", "amount": "11227314154" } ] }, { "recipient": "gonka1j7x6dv42xehe9e5au4ku3wvzwtqlegfjhlvzj6", "amount": [ { "denom": "ngonka", "amount": "10262057515369" } ] }, { "recipient": "gonka1jt5mqrx0yg5k6qdqhnkc4kpya4mzy52ngyh34c", "amount": [ { "denom": "ngonka", "amount": "19116778155" } ] }, { "recipient": "gonka1lh0danzlvxm5qtaly7myqd3n5sus0fq92n8shx", "amount": [ { "denom": "ngonka", "amount": "182307306602" } ] }, { "recipient": "gonka1mmlyd5xxu5l68yx8wzclrkxkxvm88mhq5tp5s0", "amount": [ { "denom": "ngonka", "amount": "3540857046786" } ] }, { "recipient": "gonka1mmwngrtpc4fd4jquv5vfsnscqdzmcz0zgrvy0g", "amount": [ { "denom": "ngonka", "amount": "15900304370" } ] }, { "recipient": "gonka1pks9m29wqac2kxdj8v8acq58rjshh6u8y2a772", "amount": [ { "denom": "ngonka", "amount": "243541684885" } ] }, { "recipient": "gonka1q3n37e2uc4npkheyjllx2ztx5yh42rk6vz3kgn", "amount": [ { "denom": "ngonka", "amount": "27431059448" } ] }, { "recipient": "gonka1qx3znmtpxqgmz3t4tgpdk68dsfxuccn6cxnp8s", "amount": [ { "denom": "ngonka", "amount": "25489037540" } ] }, { "recipient": "gonka1rcpc45n6zch9qlkn4m3cwngekad89xu8mcr09v", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka1scskt6wpnjnumsah6kjphmdu87vjgvcxmn4rxv", "amount": [ { "denom": "ngonka", "amount": "1531342862912" } ] }, { "recipient": "gonka1t88kkvnrayz5l2u043tccd2pks4rt8y346z9dv", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka1t8jjpaq2m0svru73kh9l0m62e7lr7qxxw6uvea", "amount": [ { "denom": "ngonka", "amount": "10000000000" } ] }, { "recipient": "gonka1u4zxypjgcr8khlzefwjr0vwdaj2uzruw2cehj3", "amount": [ { "denom": "ngonka", "amount": "246274027398" } ] }, { "recipient": "gonka1wt8sr9jxzpec65j7zkxsgh6edk3m6r8nlf5za4", "amount": [ { "denom": "ngonka", "amount": "8784035574445" } ] }, { "recipient": "gonka1xy9py6zlxsum2m0z422qwa0um6au7ls4r65ky8", "amount": [ { "denom": "ngonka", "amount": "32043361480" } ] }, { "recipient": "gonka1zktn8j65wlys8a8e38hqhf4y3x6m4x04zskkrx", "amount": [ { "denom": "ngonka", "amount": "578039630382" } ] } ], "vesting_epochs": "150" }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka100s7x2t0npruu9ta02306qfmaened3vg3a9dn6", "amount": [ { "denom": "ngonka", "amount": "13950000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka123pr0p0salv96xvne9qln70x3usvpyscug5f9a", "amount": [ { "denom": "ngonka", "amount": "4600000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka16j4zv6723mrnycwn0qgw0j48dr9qecyclxg5jh", "amount": [ { "denom": "ngonka", "amount": "10800000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1gmuxdcxlsxn5z72elx77w9zym7yrgfxqgzg6ry", "amount": [ { "denom": "ngonka", "amount": "12300000000000" } ] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1ppn53fu8q3pxvwwf8ycjf3c6nzlugs3hmw6a3q", "amount": [ { "denom": "ngonka", "amount": "6200000000000" } ] } ] ``` --- ## Internal Go-To-Market Team for 3 Month to Set Up the Basis: acquisition funnels, analytics, sharable target audience deep understanding # Internal Go-To-Market Team for 3 Month to Set Up the Basis: acquisition funnels, analytics, sharable target audience deep understanding 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. ## What we'll do ### I. Onboarding funnels for target audiences of all types mentioned in the [roadmap](https://github.com/gonka-ai/gonka/blob/d5e30ca891209f25fd84e36ef439e1f54ec9090c/proposals/gonka-network-development-roadmap.md) (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. | 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 | ### Where are we going to send the traffic? - Token investors traffic → to pages with aggregation of ways to buy GNK and mining pools - Inference users traffic → to working pages 1. Random product chose 2. Aggregation of all existing brokers 3. Unifying broker, which sends the request to 3 random brokers (whose metrics are good enough) — and return the first relevant answer, also handles situation if the requested Gonka model was unavailable - Large B2B, GPU Hosts, and all other significant → to pages with documentation, community links and suggestion to book a call ### II. Marketing analytics: who, from which channel, usage funnel. We will try to cover all services in the Gonka ecosystem, including: Inference Brokers, GNK exchange, Wallets, Mining pools, and other — all who interested in traffic. 1. Unified analytics format — with traffic and GNK bonuses for those who'll support it 2. Dashboards with clear metrics, including conversion funnels, segmented by channel, offer, performer, and other relevant filters. ### III. B2B & B2C bisdev — consistent and transparent work with hypotheses of target audiences, channels, offers, and formats — all collected in one place and can be easily shared with external teams 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. 1. Which ideas do we have? 2. What do we believe the most and why? 3. What are the results of our tests? Key: acquisition cost & leads quality 4. What are we going to scale? What should we focus on next? ### IV. CRMs separately collecting B2Bs, AI-aggregators (openrouter competitors), AI-accelerators, communities for outreach, influencers — with communication details and clear statuses among them ### V. Collect requirements and conduct other activities that support Gonka network development 1. Inference development: helping with transparency, requirements and priorities 2. Model training: identifying requirements and clients for the first model, we can easily train in parallel on unused GPUs in our network ### VI. Competitors, how do they positioned for our target audiences, and what are they doing — research, separated by various types of target audiences 1. Inference users competitors: OpenAI, Anthropic, OpenRouter, Together.ai, and other 2. GPU-holders competitors: decentralized networks (bittensor, io.net, Aethir) and GPU clouds (Vast.ai, RunPod, TensorDock) 3. Investors competitors: decentralized web-3 projects (like TAO), stocks, especially semiconductors, and other types of investments 4. AI/ML Labs: decentralized or not networks and data centers ### VII. Coordination between other performers (including external) and hosts, helping performers to understand our actual situation and requirements ### VIII. Achieve ~2000 non-ru monthly paying users with average bill $200 / month - (1000-1500 instead of 2000 in the reduced version of the budget) - International focus on ~1000 paying for inference and ~1000 token investors - **Key Metrics:** people reached and research data collected, first successful cases we can tell in public, time to first valuable action, inference, developer activation and real network usage, community growth, market visibility, and network trust. - **Long-term focus: in 9-15 months** network should achieve **tens of thousands H100 equivalent** (openrouter-like size) with **at least 30% utilization** + stable growth of GNK token price. ## Go-to-market actions | Action | Target Audience | Priority | 3-month Goal (reference) | | :--- | :--- | :--- | :--- | | Communities collaboration | B2C Inference users, Token Investors | High | 100+ communities coverage, 500-1000 paying per month | | Influencers collaboration | B2C Inference users | High | 500-1000 paying per month | | Blog & SEO & GEO | B2C Inference users, B2B Inference users, Token Investors, GPU Hosts | High | 5-7k monthly organic visitors, 100-200 paying per month | | B2B bisdev — Viktor + Hleb | B2B Inference users, AI/ML Labs & Devs, Token Investors, B2C Inference users | High | 100-500 clients engaged, 5-10 meaningful cases + requirements | | B2B focused on AI aggregator listing & inference competitors outreach — Viktor + Hleb | B2B Inference users, B2C Inference users | High | 100-500 clients engaged, 5-10 meaningful cases + requirements | | Crypto aggregator listing coordination — Arseny | Token Investors, Liquidity providers, LP funds | High | no exact KPI, need to be done ASAP | | Top inference users behaviour and requirements research — Viktor | B2B Inference users, B2C Inference users | High | acceleration for all activities | | Reddit presence — Arseny | B2C Inference users, B2B Inference users, GPU Hosts | High | 300-500 paying per month, 500k+ unique users impressions | | Social marketing on X — Arseny | B2C Inference users, Token Investors, GPU Hosts | Medium | 100-200 paying per month | | Product Hunt launch with "Cheap AI product" | B2C Inference users, Token Investors | Medium | 1-3 launches per 3 months | | Content creators campaign | B2C Inference users, B2B Inference users, GPU Hosts | Medium | 5-10 members ambassador team with KPI | | Paid Traffic Test | B2C Inference users | Medium | 100-200 paying per month | | KOLs round | Token Investors, B2C Inference users | Low | — | | AI startup accelerators & founders partnerships | B2B Inference users, B2C Inference users, Token Investors | Low | 5-10 partnerships | 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) ## The Team Top persons, responsible for the results — C-Level Executives, investing in Gonka since November 2025. - **Viktor Katsman** — details: [LinkedIn](https://www.linkedin.com/in/viktor-katsman/) 1. [PhD](https://www.spbstu.ru/science/the-department-of-doctoral-studies/defences-calendar/the-degree-of-candidate-of-sciences/katsman_viktor_igorevich/) in AI Technologies for Education; finished California Founder University program for early-stage startup founders 2. Have extensive experience both: - as a product, analyst and AI developer in big corporations like Yandex - as an early-stage startup founder, acting as CEO, CPO, CTO, CMO, and CBDO 3. Best achievement: led ML eComm to result as $34M in year revenue growth - Created the first version of [go-to-market strategy in May](https://docs.google.com/spreadsheets/d/1jjVCJqyQvjKfc_tSB5Wy9Z5w7tGm4Eq3jXGJtlD1r9I/edit?gid=809249310#gid=809249310), and was responsible for the Marketing track in the applied [roadmap](https://github.com/gonka-ai/gonka/blob/d5e30ca891209f25fd84e36ef439e1f54ec9090c/proposals/gonka-network-development-roadmap.md), leads The Soul and other external performers. - **Arseny Myakotnikov** — details: [LinkedIn](https://www.linkedin.com/in/arseny-myakotnikov-5a4341177/) 1. 10+ years in marketing, 7+ in web3, in crypto since early 2017; currently CMO at venture studio dome.net, launching web3 and B2B SaaS products 2. Owned full-cycle marketing as CMO for dozens of fintech, web3 and AI products 2.1. building and executing GTM strategies across paid traffic, influence, PR, content marketing, SEO/GEO, community building, partnerships & co-marketing, token launches / TGE, funnel analytics and product marketing 2.2. founder experience: builds products 0 to 1 and drives early audience — launched own InfoFi product (2k MAU) and Jeet Trade, a Solana trading platform with $3M+ volume and 600+ users 3. 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](https://telegram.me/c/4298804361/80). (To join the group "Gonka_Use Cases" to see the comment use [this invite](https://telegram.me/+3ZKaDbM7MJYwNGVk)) 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](https://docs.google.com/spreadsheets/d/1jjVCJqyQvjKfc_tSB5Wy9Z5w7tGm4Eq3jXGJtlD1r9I/edit?gid=809249310#gid=809249310), and was responsible for the Marketing track in the applied [roadmap](https://github.com/gonka-ai/gonka/blob/d5e30ca891209f25fd84e36ef439e1f54ec9090c/proposals/gonka-network-development-roadmap.md), 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](https://medium.com/@pavelpetko/a-closer-look-gonka-models-are-now-available-in-integrity-an-ai-powered-project-workspace-b03478d19e96) — Integrity added Gonka models as "Powerful models at a fraction of the price" in Beta stage for all users. ## Cost + Budget - 600K GNK (180K in day 0 + 130K GNK in day 30 + 130K GNK in day 60 + 160K GNK in day 90) — our bonus. The team size is 8-15 people, some tasks will be delegated for external agencies, ready for long-term partnership relations. Rewards are estimated based on market salary benchmarks and converted into GNK at the actual exchange rate at June 20. - This bonus shouldn't be downgraded if our work will be continued (by another proposal after 3 months). We should be motivated to increase GNK-price the long-term. If it grows, then our bonus grows. If it falls — our bonus falls. - 36K USDT (12K USDT / month) for bounties and external services expenses and operations. The cost breakdown will be transparent and open. ### Monthly GNK Allocation | Direction | Budget per month | Were (in 280K GNK version) | Key executives | | :--- | ---: | ---: | :--- | | Analytics | 30K GNK | 30K GNK | Viktor | | pSEO + AEO | 30K GNK | 30K GNK | Arseny + Vlad | | B2B Focused on Significant Inference Sellers and Users + Investors involved | 50K GNK | 60K GNK | Viktor + Brokers (Hleb, ...) + Bisdevs (Dmitry, ...) | | B2C focused on Agents users, AI Startup founders and Indie Devs (including communities & influencers partnerships) | 40K GNK | 50K GNK | Viktor + Brokers (Alex, ...) + Yan | | Local Conferences (excluded from B2B + B2C for clarity) | 10K GNK | 0K GNK | Yan | | Reddit Posts + Subreddit | 20K GNK | 30K GNK | Arseny | | Communities Collaborations | 20K GNK | 30K GNK | Arseny | | Influencers Collaborations (left for The Soul except micro-influencer's experiments included in B2C) | 0K GNK | 30K GNK | Arseny | | Paid traffic activities (left for the future) | 0K GNK | 10K GNK | Viktor | | Product Hunt launches (left for the future) | 0K GNK | 10K GNK | Viktor | | **Total** | **200K GNK** | **280K GNK** | | 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. ### Monthly USDT Budget | 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 USDT** | | USDT 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). - Up to 150K USD — external teams and/or scaling of successful initiatives. **Actual cost = 600K GNK + 36K USDT** --- ## #85 – Internal Go-To-Market Team for 3 Month # #85 – Internal Go-To-Market Team for 3 Month 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`](https://gonka.gg/address/gonka1vfafh4jq674227q8j0h33fwz4jmgtxmp4vsd93){:target="_blank"} **Metadata:** [https://app.integrity.sh/p/SuMCnGQBhz-0asAYBUz1U](https://app.integrity.sh/p/SuMCnGQBhz-0asAYBUz1U) **Failed reason:** proposal did not get enough votes to pass 600,000 GNK · $36,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/85){:target="_blank"} 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: 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 (that Sega used in ) --- ## Final Tally 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) ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgInstantiateContract2` | | 2 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | | 3 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgInstantiateContract2", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "admin": "", "code_id": "107", "label": "go-to-market-team-milestone-escrow", "msg": { "governance": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "payouts": [ { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ngonka", "amount": "10000000000000", "unlock_after_days": 0 }, { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ngonka", "amount": "10000000000000", "unlock_after_days": 60 }, { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 99 }, { "recipient": "gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 0 }, { "recipient": "gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4", "denom": "ngonka", "amount": "10000000000000", "unlock_after_days": 30 }, { "recipient": "gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4", "denom": "ngonka", "amount": "50000000000000", "unlock_after_days": 99 }, { "recipient": "gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw", "denom": "ngonka", "amount": "40000000000000", "unlock_after_days": 0 }, { "recipient": "gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw", "denom": "ngonka", "amount": "25000000000000", "unlock_after_days": 30 }, { "recipient": "gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw", "denom": "ngonka", "amount": "25000000000000", "unlock_after_days": 60 }, { "recipient": "gonka1qederwp6etpnzm0et6d924c5n08cycauhdqwuy", "denom": "ngonka", "amount": "40000000000000", "unlock_after_days": 0 }, { "recipient": "gonka1qederwp6etpnzm0et6d924c5n08cycauhdqwuy", "denom": "ngonka", "amount": "35000000000000", "unlock_after_days": 30 }, { "recipient": "gonka1qederwp6etpnzm0et6d924c5n08cycauhdqwuy", "denom": "ngonka", "amount": "35000000000000", "unlock_after_days": 60 }, { "recipient": "gonka1k7400padt0g0kreh364c8vfsn58eg8r566yvnd", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 0 }, { "recipient": "gonka1k7400padt0g0kreh364c8vfsn58eg8r566yvnd", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 30 }, { "recipient": "gonka1k7400padt0g0kreh364c8vfsn58eg8r566yvnd", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 60 }, { "recipient": "gonka1k7400padt0g0kreh364c8vfsn58eg8r566yvnd", "denom": "ngonka", "amount": "50000000000000", "unlock_after_days": 99 }, { "recipient": "gonka137zkmd6msle3556h2gls9t0tyqvathpzad2ev3", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 0 }, { "recipient": "gonka137zkmd6msle3556h2gls9t0tyqvathpzad2ev3", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 30 }, { "recipient": "gonka137zkmd6msle3556h2gls9t0tyqvathpzad2ev3", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 60 }, { "recipient": "gonka137zkmd6msle3556h2gls9t0tyqvathpzad2ev3", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 99 }, { "recipient": "gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "3000000000", "unlock_after_days": 0 }, { "recipient": "gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "3000000000", "unlock_after_days": 30 }, { "recipient": "gonka1eym0g7fye3rzn6tj03qwfy0xeqkad6d5stdyaw", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "3000000000", "unlock_after_days": 60 }, { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "9000000000", "unlock_after_days": 0 }, { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "9000000000", "unlock_after_days": 30 }, { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "9000000000", "unlock_after_days": 60 } ], "close_after_days": 300 }, "funds": [], "salt": "Z3RtLXRlYW0tMjAyNg==", "fix_msg": false }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1stfulpj6t5mc0nekph7g7tcf7dv5mszm95xtvt6rc5repv7t5yvq28h3ja", "amount": [ { "denom": "ngonka", "amount": "600000000000000" } ] }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "36000000000", "recipient": "gonka1stfulpj6t5mc0nekph7g7tcf7dv5mszm95xtvt6rc5repv7t5yvq28h3ja" } }, "funds": [] } ] ``` --- ## Bringing $3M+ in New Capital to GONKA via Uniswap — Phase 1/6 ($50k USDT) # Bringing $3M+ in New Capital to GONKA via Uniswap — Phase 1/6 ($50k USDT) **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. ## 1. Executive Summary 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. ## 2. Who We Are 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 ## 3. What We Propose 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. ## 4. KPI & Project Economics | 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+** | - Average subscriber cost: $4-6 - Average dialogue cost: $6-12 depending on geography - At $300,000 budget: 30,000+ new dialogues - ~20-23% of users start financial interaction - Minimum first deposit (FTD) assumed: $500 - KPI calculated on **first financial action only** (FTD). Repeat investments, retention, organic growth not included in mandatory KPI - Internal estimate: $6-7M potential from paid traffic alone ## 5. Funnel **Meta Ads → Landing Page → Telegram → AI Agent → Manager → Uniswap → Long-term Support** 1. **Meta Ads** — user first discovers GONKA through ad campaigns 2. **Landing Page** — builds initial interest and trust, motivates transition to Telegram 3. **Telegram** — bot auto-accepts, sends welcome message, provides contacts. Main interaction platform where trust is built through content 4. **AI Agent (Tora AI)** — handles majority of communication, answers questions, guides users toward first deposit 5. **Manager** — handles large investors or cases requiring personal communication 6. **Uniswap Purchase** — primary goal of the entire funnel 7. **Long-term Support** — AI Agent and managers continue engagement post-deposit Demo channel: https://telegram.me/demo_chanel_gonka ## 6. User Retention Strategy 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. ## 7. Funding - Total program budget: $300,000 - 6 sequential phases of $50,000 each - **This proposal: Phase 1 — $50,000** - Phase 1 focuses on infrastructure build, ad campaign launch, funnel testing, finding optimal GEO/audiences/creatives - Subsequent phases submitted only after KPI achievement of prior phase ## 8. Team Compensation | Component | Percentage | Timing | |---|---|---| | Fixed portion | 8% of ad budget | Paid after phase approval | | Variable portion | 12% of ad budget | Paid only after KPI achieved + next phase approved | | **Total (per phase)** | **20%** | | If KPI is not met or next phase not approved, variable portion is forfeited. All compensation to be paid exclusively in GNK tokens. ## 9. Reporting & Transparency - Weekly public reports: campaign results, KPI progress, subscriber/dialogue costs, GEO results, hypotheses, tests, plans - KPI verified through internal CRM tracking each user's wallet address, FTD amount, and interaction history - Weekly AMA calls if needed - Open to additional committee questions at any time ## 10. What GONKA Receives 1. **$3,000,000+ in new capital** (internal estimate: $6-7M) 2. Telegram channels with hundreds of thousands of engaged users 3. Fully tested marketing funnel for capital acquisition 4. All ad creatives, landing pages, content created during campaign 5. AI Agent trained on tens of thousands of real dialogues, optimized for user onboarding, first deposit, repeat investments, and long-term retention 6. Accumulated analytics and test results 7. Ready-to-scale capital acquisition infrastructure ## 11. Anti-Fraud & KPI Methodology - Only new wallets meeting predefined criteria are counted - Related address analysis eliminates repeat patterns - Circular runs, self-purchases, and artificial inflation attempts excluded - KPI calculated on capital that **remains in the ecosystem at verification time**, not total incoming volume - Minimum holding period may be applied before funds count toward KPI Example: at $50,000 Phase 1 budget, target is $200,000 in wallets at verification time. ## 12. Additional Materials - Demo Telegram channel: https://telegram.me/demo_chanel_gonka - Proposal materials (landings, creatives, ad accounts, funnel examples, partner info, AMAs): https://telegram.me/proposaluniswap - Contact: @FrancesGreen9 ## Full Proposal Source https://gonka.vote/proposal/f341b83c-78f0-4ab2-b8fd-ddc7ac5d9c37 --- ## #84 – Bringing $3M+ in New Capital to GONKA via Uniswap — Phase 1/6 ($50k USDT) # #84 – Bringing $3M+ in New Capital to GONKA via Uniswap — Phase 1/6 ($50k USDT) Rejected **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`](https://gonka.gg/address/gonka1njlf4guhkf60tt8z4ayf4sx73nkf5vsumjplat){:target="_blank"} **Metadata:** [https://gonka.vote/proposal/f341b83c-78f0-4ab2-b8fd-ddc7ac5d9c37](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 Pool [View on gonka.gg](https://gonka.gg/network/proposals/84){:target="_blank"} 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: 1. Proposal Overview. 2. Who We Are. 3. What We Propose. 4. KPI & Project Economics. 5. How the Funnel Works. 6. User Retention Strategy. 7. Funding. 8. Team Compensation. 9. Reporting & Transparency. 10. What GONKA Receives. 11. Anti-Fraud Protection & KPI Methodology. 12. Additional Materials. Full PROPOSAL: Demo Telegram Channel: Additional materials, proof of our work, landing page examples, creatives, advertising accounts, and partnership references: --- ## Final Tally 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) ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgExecuteContract` | | 2 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "amount": "50000000000", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "recipient": "gonka1njlf4guhkf60tt8z4ayf4sx73nkf5vsumjplat" } }, "funds": [] }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1njlf4guhkf60tt8z4ayf4sx73nkf5vsumjplat", "amount": [ { "denom": "ngonka", "amount": "20000000000000" } ] } ] ``` --- ## #88 – Restore Kimi K2.6 and remove v1, v2 # #88 – Restore Kimi K2.6 and remove v1, v2 Passed **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`](https://gonka.gg/address/gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/88){:target="_blank"} 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). --- ## Final Tally 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) ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | | 2 | `/inference.inference.MsgRegisterModel` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "35", "poc_exchange_duration": "0", "poc_validation_delay": "5", "poc_validation_duration": "240", "set_new_validators_delay": "120", "inference_validation_cutoff": "2", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "500" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "processed_logprobs" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": true, "confirmation_poc_v2_enabled": true, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": true, "poc_stronger_rng_enabled": false, "models": [ { "model_id": "MiniMaxAI/MiniMax-M2.7", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "75", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "3024", "exponent": -4 }, "penalty_start_epoch": "278" }, { "model_id": "moonshotai/Kimi-K2.6", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "4", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "945", "exponent": -3 }, "penalty_start_epoch": "332" }, { "model_id": "zai-org/GLM-5.2-FP8", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "45", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "25935", "exponent": -4 }, "penalty_start_epoch": "500" } ], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2475000", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2475000" }, "transfer_agent_access_params": { "allowed_transfer_addresses": [ "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u" ] }, "devshard_escrow_params": { "min_amount": "50000000", "max_amount": "100000000000", "max_escrows_per_epoch": 500000, "group_size": 16, "allowed_creator_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk", "gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90", "gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c", "gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn", "gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp" ], "token_price": "10", "approved_versions": [ { "name": "v3", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v3.0.0/devshardd.zip", "sha256": "ca1294fc8db3f0907a01f362eb4b13665f66d0fd12cfc6f01468b1e27f0bab63" } ], "max_nonce": 1000000, "devshard_requests_enabled": true, "default_inference_seal_grace_nonces": 0, "default_inference_seal_grace_seconds": 0, "create_devshard_fee": "0", "fee_per_nonce": "0", "refusal_timeout": "0", "execution_timeout": "0", "validation_rate": 0, "vote_threshold_factor": 0, "default_auto_seal_every_n_nonces": 0 }, "fee_params": { "min_gas_price_ngonka": "0", "base_validation_gas": "500000", "gas_per_poc_count": "100" }, "delegation_params": { "deploy_window": "500", "refusal_penalty": { "value": "1", "exponent": -1 }, "no_participation_penalty": { "value": "15", "exponent": -2 }, "delegation_share": { "value": "5", "exponent": -2 }, "w_threshold": { "value": "1", "exponent": -1 }, "v_min": "3", "cap_factor": { "value": "75", "exponent": -2 }, "initial_model_id": "MiniMaxAI/MiniMax-M2.7", "max_model_voting_power_percentage": { "value": "3", "exponent": -1 } }, "maintenance_params": null } }, { "@type": "/inference.inference.MsgRegisterModel", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "proposed_by": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "id": "moonshotai/Kimi-K2.6", "units_of_compute_per_token": "10000", "hf_repo": "moonshotai/Kimi-K2.6", "hf_commit": "5a49d036ab7472b7d5912ded487150ec1358c11d", "model_args": [ "--enable-auto-tool-choice", "--max-model-len", "240000", "--tool-call-parser", "kimi_k2", "--reasoning-parser", "kimi_k2" ], "v_ram": "720", "throughput_per_nonce": "1500", "validation_threshold": { "value": "900", "exponent": -3 } } ] ``` --- ## External Test Lab & Community DevNet # External Test Lab & Community DevNet *4-month pilot proposal for community-owned testing infrastructure and QA capacity* # 1. 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 | # 2. Problem Statement 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. # 3. Roadmap Alignment This proposal directly implements two projects from the [Gonka Network Development Roadmap](https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md). **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**.** # 4. What We Are Building 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 | # 5. Community DevNet Infrastructure - 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](https://huggingface.co/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. # 6. Burst GPU Testing Budget - 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. # 7. External Testing Team 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 ## Preferred / Nice-to-Have - 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 # 8. Project Owners and Accountability | Role | Proposed owner | Responsibilities | | --- | --- | --- | | **Project Lead** | [Sergii Paranko](https://www.linkedin.com/in/paranko/) (S∃ga L∈nin) | Overall project accountability, governance coordination, scope and milestone control, QA contractor selection and onboarding, public reporting, and testing laboratory oversight. | | **Infrastructure Lead** | [Mikhail Chudinov](https://www.linkedin.com/in/mikhail-chudinov/) (Mitch) | DevNet provisioning, hardware selection, regional hosting, monitoring, operational stability, and infrastructure cost control. | | **External Testing Team** | 2 hired QA / Infrastructure Testing Engineers | Test execution, reports, defect documentation, regression tracking, and release-readiness recommendations. | # 9. Transparency and Reporting - 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. # 10. Protocol Maintainer Coordination - 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. # 11. Release Validation Handoff Requirements | **Validation type** | **Expected handoff** | |--------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Protocol release / production upgrade** | Protocol Maintainers provide release candidate, upgrade notes, affected components, and expected test focus at least 7 days before the planned governance vote or production rollout, where feasible. | | **DevShard / test environment validation** | DevShards or another testable environment are provided with scope and expected test focus at least 3 days before the expected validation result, where applicable. | 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. # 12. Milestones and Acceptance Criteria ## Workstream A: DevNet Infrastructure | **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. | ## Workstream B: External Testing Lab | **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. | # 13. KPIs | **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 | # 14. Budget Estimate 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](https://nebius.com/prices) 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. # 15. Payment Schedule | **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. | # 16. End-of-pilot GNK recognition 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. | # 17. Open Source, Ownership and Handoff - 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. # Decision Requested 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. --- ## #82 – External Test Lab x Community DevNet # #82 – External Test Lab x Community DevNet Passed **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`](https://gonka.gg/address/gonka1k6p754pyhxud2399knyccgjpjvdafj2u9xlgyf){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/discussions/1388](https://github.com/gonka-ai/gonka/discussions/1388) 80,000 GNK · $88,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/82){:target="_blank"} 4-month pilot of the External Test Lab & Community DevNet: a community-owned testing layer for Gonka. Full proposal and discussion: 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](https://gonka.gg/address/gonka1g57f45qjvn0529vpgj8x8mzt8r5k4audchm3pp9pezywxwf4rexqlj8ayw). No admin, no migration - recipients and amounts can never change. Source and verification: --- ## Final Tally 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) ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgInstantiateContract2` | | 2 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | | 3 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgInstantiateContract2", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "admin": "", "code_id": "107", "label": "testlab-devnet-milestone-escrow", "msg": { "governance": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "payouts": [ { "recipient": "gonka1pn5953zm5j29w23u8csz4uuqwpg486j05e9aj4", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "22000000000", "unlock_after_days": 0 }, { "recipient": "gonka1pn5953zm5j29w23u8csz4uuqwpg486j05e9aj4", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "22000000000", "unlock_after_days": 34 }, { "recipient": "gonka1pn5953zm5j29w23u8csz4uuqwpg486j05e9aj4", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "22000000000", "unlock_after_days": 64 }, { "recipient": "gonka1pn5953zm5j29w23u8csz4uuqwpg486j05e9aj4", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "22000000000", "unlock_after_days": 94 }, { "recipient": "gonka1pn5953zm5j29w23u8csz4uuqwpg486j05e9aj4", "denom": "ngonka", "amount": "40000000000000", "unlock_after_days": 124 }, { "recipient": "gonka1fx65y7jfce6q4cj3zf7wvfuse3juu7c8gg0hqp", "denom": "ngonka", "amount": "40000000000000", "unlock_after_days": 124 } ], "close_after_days": 200 }, "funds": [], "salt": "dGVzdGxhYi1kZXZuZXQtcGlsb3Q=", "fix_msg": false }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1g57f45qjvn0529vpgj8x8mzt8r5k4audchm3pp9pezywxwf4rexqlj8ayw", "amount": [ { "denom": "ngonka", "amount": "80000000000000" } ] }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "88000000000", "recipient": "gonka1g57f45qjvn0529vpgj8x8mzt8r5k4audchm3pp9pezywxwf4rexqlj8ayw" } }, "funds": [] } ] ``` --- ## #86 – Increase Kimi-K2.6 and GLM-5.2 weight_scale_factor by 5% # #86 – Increase Kimi-K2.6 and GLM-5.2 weight_scale_factor by 5% 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`](https://gonka.gg/address/gonka123pr0p0salv96xvne9qln70x3usvpyscug5f9a){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/86){:target="_blank"} 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. --- ## Final Tally 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) ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "35", "poc_exchange_duration": "0", "poc_validation_delay": "5", "poc_validation_duration": "240", "set_new_validators_delay": "120", "inference_validation_cutoff": "2", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "500" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "processed_logprobs" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": true, "confirmation_poc_v2_enabled": true, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": true, "poc_stronger_rng_enabled": false, "models": [ { "model_id": "MiniMaxAI/MiniMax-M2.7", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "75", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "3024", "exponent": -4 }, "penalty_start_epoch": "278" }, { "model_id": "moonshotai/Kimi-K2.6", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "4", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "945", "exponent": -3 }, "penalty_start_epoch": "310" }, { "model_id": "zai-org/GLM-5.2-FP8", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "45", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "25935", "exponent": -4 }, "penalty_start_epoch": "500" } ], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2475000", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2475000" }, "transfer_agent_access_params": { "allowed_transfer_addresses": [ "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u" ] }, "devshard_escrow_params": { "min_amount": "50000000", "max_amount": "100000000000", "max_escrows_per_epoch": 500000, "group_size": 16, "allowed_creator_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk", "gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90", "gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c", "gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn", "gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp" ], "token_price": "10", "approved_versions": [ { "name": "v1", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip", "sha256": "dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c" }, { "name": "v2", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip", "sha256": "1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b" }, { "name": "v3", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v3.0.0/devshardd.zip", "sha256": "ca1294fc8db3f0907a01f362eb4b13665f66d0fd12cfc6f01468b1e27f0bab63" } ], "max_nonce": 1000000, "devshard_requests_enabled": true, "default_inference_seal_grace_nonces": 0, "default_inference_seal_grace_seconds": 0, "create_devshard_fee": "0", "fee_per_nonce": "0", "refusal_timeout": "0", "execution_timeout": "0", "validation_rate": 0, "vote_threshold_factor": 0, "default_auto_seal_every_n_nonces": 0 }, "fee_params": { "min_gas_price_ngonka": "0", "base_validation_gas": "500000", "gas_per_poc_count": "100" }, "delegation_params": { "deploy_window": "500", "refusal_penalty": { "value": "1", "exponent": -1 }, "no_participation_penalty": { "value": "15", "exponent": -2 }, "delegation_share": { "value": "5", "exponent": -2 }, "w_threshold": { "value": "1", "exponent": -1 }, "v_min": "3", "cap_factor": { "value": "75", "exponent": -2 }, "initial_model_id": "MiniMaxAI/MiniMax-M2.7", "max_model_voting_power_percentage": { "value": "3", "exponent": -1 } }, "maintenance_params": null } } ] ``` --- ## Partnerships with Inference Resellers, B2C users acquisition and conversion funnels analytics setup # Partnerships with Inference Resellers, B2C users acquisition and conversion funnels analytics setup 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](https://app.integrity.sh/p/SuMCnGQBhz-0asAYBUz1U). ## Budget | 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 USDT** | | Hundreds 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. ## Payments and Timeline 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 ### Month Budget Breakdown - **$8K / month + 40K GNK** — 4 positions base (4 x $2K / month + 4 x 10K GNK) - **$6K / month + 40K GNK** — rewards, additional positions, referrals and experiments tailored to new marketing activities or their acceleration - **$5K / month** — AI for the team, Analytics, B2B-outreach (smartlead, apollo, zapmail, apify), Influencers databases subscriptions (hypeauditor, adstail, rizzult, modash), AI agencies, Infrastructure, domains, referral bonuses ## KPIs | KPI | Until day 31 | Until day 62 | Until day 99 | | :--- | :--- | :--- | :--- | | Partnerships and pilots with inference resellers | 1-2 | 3-5 | 7-15 | | OpenRouter-size comparable partnerships | selection and letters | discussions | 1-3 pilots started | | Interviews with competitors marketers | 3-5 | 5-7 | 10-15 | | New non-ru Gonka users in our communities | 100-500 (~10% paid) | 300-1500 (~15% paid) | 1000-5000 (~20% paid) | | Posts in relevant communities (1K-100K subscribers) | 100-200 | 200-500 | 300-800 | | Collaborations with microinfluencers (AI / Agents creators with 500-10K subscribers) | 10-30 | 25-80 | 40-150 | | Local meetups | 1-2 | 2-5 | 5-10 | | Offers x Languages x Onboardings (landings) tested | 50-100 | 80-200 | 100-300 | | Public use cases | 1-2 | 3-5 | 10-15 of various usage types | | Analytics | set with ready dashboards; 3-8 key Gonka services connected | 10-15 key Gonka services are connected | 10-30 key Gonka services are connected | | Reports and AMAs every 2 weeks | 2 | 4 | 6 + final | 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](https://github.com/paranjko/testlab-devnet-escrow/tree/1b2e529876141816b5c2130840d04fb93694bf72) (that Sega used in [proposal 82](https://gonka.vote/governance/82)). ## Team 1. **Viktor Katsman** ([LinkedIn](https://www.linkedin.com/in/viktor-katsman/), [PhD](https://www.spbstu.ru/science/the-department-of-doctoral-studies/defences-calendar/the-degree-of-candidate-of-sciences/katsman_viktor_igorevich/) in AI Technologies for Education), experience both in big corporations like Yandex and as early-stage startups founder and CMO. 2. **Dima Kim** ([LinkedIn](https://www.linkedin.com/in/dimakim/)) — B2B bisdev, built Speechki and sold it, ex-TechStars, ex-Alchemist. 3. **Alex Milman** ([LinkedIn](https://www.linkedin.com/in/milman-blum/)) — B2B bisdev, SEO Likwid Export, successful cases with Yandex & Nebius. 4. **Ian Nerovny** ([LinkedIn](https://www.linkedin.com/in/nerovny/)) — founder at Unicorn Embassy, built a network of ~200 conferences in Georgia, Spain, the Emirates and other places. 5. **Alex** (Entrepreneur, Founder of JoinGonka Broker), **Hleb** (Founder of Gonka24 Broker), **Pavel and others** — we will engage the most experienced and active community members and distribute rewards depending on their contribution and results. ## Key Benefits for Gonka 1. Onboardings, analytics, ability to measure, control all other activities, finding what worked the best. 2. Meaningful partners and use cases, that will also accelerate all other go-to-market activities. 3. Understanding the best target audiences to scale and their requirements. Voting: [https://gonka.vote/governance/90](https://gonka.vote/governance/90) --- ## #90 – Partnerships with Inference Resellers, B2C users acquisition and conversion funnels analytics setup # #90 – Partnerships with Inference Resellers, B2C users acquisition and conversion funnels analytics setup 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`](https://gonka.gg/address/gonka1vfafh4jq674227q8j0h33fwz4jmgtxmp4vsd93){:target="_blank"} **Metadata:** [https://app.integrity.sh/p/NLgLEHfL8Msoz0nh2-_Tf](https://app.integrity.sh/p/NLgLEHfL8Msoz0nh2-_Tf) **Failed reason:** proposal did not get enough votes to pass 240,000 GNK · $57,000 · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/90){:target="_blank"} 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: 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 (that Sega used in ) +-------------------------------+-------------------+-------------------+-------------------+ | 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 | | | | +-------------------------------+-------------------+-------------------+-------------------+ --- ## Final Tally 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) ## Messages | # | Type | | :- | :--- | | 1 | `/cosmwasm.wasm.v1.MsgInstantiateContract2` | | 2 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | | 3 | `/cosmwasm.wasm.v1.MsgExecuteContract` | Contract Details ```json [ { "@type": "/cosmwasm.wasm.v1.MsgInstantiateContract2", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "admin": "", "code_id": "107", "label": "go-to-market-team-milestone-escrow", "msg": { "governance": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "payouts": [ { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 0 }, { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 31 }, { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 62 }, { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 99 }, { "recipient": "gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 0 }, { "recipient": "gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 31 }, { "recipient": "gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 62 }, { "recipient": "gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4", "denom": "ngonka", "amount": "30000000000000", "unlock_after_days": 99 }, { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "9500000000", "unlock_after_days": 0 }, { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "9500000000", "unlock_after_days": 31 }, { "recipient": "gonka1zhcn5yz86z0jlsyzm9xkkhx6km5p8a4apw9rsj", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "9500000000", "unlock_after_days": 62 }, { "recipient": "gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "9500000000", "unlock_after_days": 0 }, { "recipient": "gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "9500000000", "unlock_after_days": 31 }, { "recipient": "gonka15at6rrk3tspus7mu0t2yg26r4guq7sqkpq3wf4", "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "9500000000", "unlock_after_days": 62 } ], "close_after_days": 150 }, "funds": [], "salt": "Z3RtLXRlYW0tMjAyNg==", "fix_msg": false }, { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka1stfulpj6t5mc0nekph7g7tcf7dv5mszm95xtvt6rc5repv7t5yvq28h3ja", "amount": [ { "denom": "ngonka", "amount": "240000000000000" } ] }, { "@type": "/cosmwasm.wasm.v1.MsgExecuteContract", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "contract": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "msg": { "withdraw_ibc": { "denom": "ibc/115F68FBA220A028C6F6ED08EA0C1A9C8C52798B14FB66E6C89D5D8C06A524D4", "amount": "57000000000", "recipient": "gonka1stfulpj6t5mc0nekph7g7tcf7dv5mszm95xtvt6rc5repv7t5yvq28h3ja" } }, "funds": [] } ] ``` --- ## Kimi cPoC Validation Failure, Epochs 306–309 # Kimi cPoC Validation Failure, Epochs 306–309 | 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, causing `confirmation_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. | --- ## Overview 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. --- ## Epoch Block Heights | 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 — clean | Reward formula: `323,000 × e^(−0.000475 × (epoch − 1))` GONKA. | Epoch | Theoretical Reward | |-------|--------------------| | 306 | 279,437.13 GONKA | | 307 | 279,304.43 GONKA | | 309 | 279,039.21 GONKA | --- ## Root Cause Evidence `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 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 :26657 INFERENCED_BINARY=/path/to/inferenced ``` The `.env` is loaded from `../gonka-segment-report/.env`. ```bash python3 e306/calculate_compensation_306.py python3 e307/calculate_compensation_307.py python3 e309/calculate_compensation_309.py python3 aggregate_compensation.py ``` --- ## Chain Query Reference ```bash # PoC nonce commits for an epoch inferenced query inference all-poc-v2-store-commits \ --node --height -o json # Epoch group data (validation weights, confirmation weights) inferenced query inference show-epoch-group-data \ --node --height -o json # Per-participant reward summary inferenced query inference show-epoch-performance-summary-by-participant \ --node -o json ``` | Epoch | poc_start | epoch_end | |-------|-----------|-----------| | 306 | 4,721,001 | 4,736,791 | | 307 | 4,736,392 | 4,752,182 | | 309 | 4,767,174 | 4,782,964 | --- ## #81 – Kimi cPoC Restitution (epochs 306-309) # #81 – Kimi cPoC Restitution (epochs 306-309) 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`](https://gonka.gg/address/gonka123pr0p0salv96xvne9qln70x3usvpyscug5f9a){:target="_blank"} **Metadata:** [https://github.com/votkon/gonka-kimi-e306-issue](https://github.com/votkon/gonka-kimi-e306-issue) **Failed reason:** proposal did not get enough votes to pass 175,082 GNK · Gov Module [View on gonka.gg](https://gonka.gg/network/proposals/81){:target="_blank"} 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). --- ## Final Tally Yes 235,728 (56.2%) No 609 (0.1%) Veto 183,094 (43.7%) Abstain 18 (0.0%) Total 419,449 votes ✓ Turnout 419,449 / 741,825 (56.5%) · Quorum 25% (185,456) ## Messages | # | Type | | :- | :--- | | 1 | `/inference.streamvesting.MsgBatchTransferWithVesting` | Contract Details ```json [ { "@type": "/inference.streamvesting.MsgBatchTransferWithVesting", "sender": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "outputs": [ { "recipient": "gonka1yal0ysgzc860zt3y8cds8656tnueusgymftvkw", "amount": [ { "denom": "ngonka", "amount": "45002842624839" } ] }, { "recipient": "gonka1gvrrhjmy4w4mayvs2s5l23edj8ertcmtd2v4zr", "amount": [ { "denom": "ngonka", "amount": "27081229515922" } ] }, { "recipient": "gonka125n6kr5gvdup0lndfkps7t6rd6592panhrg3np", "amount": [ { "denom": "ngonka", "amount": "10752097867403" } ] }, { "recipient": "gonka10mmdjau4dnj8krs7sh7t7635ttnmq9u3vqgz09", "amount": [ { "denom": "ngonka", "amount": "9348214480985" } ] }, { "recipient": "gonka1gtdrqh9jpkqxdaskxkpwjpy2q284q8qnvg58uj", "amount": [ { "denom": "ngonka", "amount": "9007313194119" } ] }, { "recipient": "gonka168rtjfkszuhcggg4dfyse4yh7xn9zwfglnkns2", "amount": [ { "denom": "ngonka", "amount": "7827216214294" } ] }, { "recipient": "gonka1qa90tgczc0k5dvk4l5nvlf5y6phgm6mg22sfjv", "amount": [ { "denom": "ngonka", "amount": "7754878837428" } ] }, { "recipient": "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "amount": [ { "denom": "ngonka", "amount": "6449817683838" } ] }, { "recipient": "gonka1uhqpup9fev3zahlx6n326lp0krznc6usjtx6lu", "amount": [ { "denom": "ngonka", "amount": "5784283093297" } ] }, { "recipient": "gonka1f0u3y2wneer8zhz3ypw4x54h38cpa0qsy8ts3e", "amount": [ { "denom": "ngonka", "amount": "5654647873240" } ] }, { "recipient": "gonka16j7xfk3hvguy5gz95mzg3p5dkuwla7aux03kdw", "amount": [ { "denom": "ngonka", "amount": "5614918581345" } ] }, { "recipient": "gonka1skw86pm4dvfhzslu5a9gsc98ahspalge8rprp4", "amount": [ { "denom": "ngonka", "amount": "5546181336564" } ] }, { "recipient": "gonka1aw77zuy536tufqd56zfq6ev3234u5ftty0zkte", "amount": [ { "denom": "ngonka", "amount": "5545625985548" } ] }, { "recipient": "gonka1d694r00czmq75txghwjcuk07lxvc8d4ekgsha0", "amount": [ { "denom": "ngonka", "amount": "5545062683374" } ] }, { "recipient": "gonka1ujg4pt8crhxdymnsatalzdj0hhkgfqjmlp9zel", "amount": [ { "denom": "ngonka", "amount": "5533752395951" } ] }, { "recipient": "gonka1jfv9n2af9y8xgnn6834mnp924vkpucmvchsq8d", "amount": [ { "denom": "ngonka", "amount": "5310157560537" } ] }, { "recipient": "gonka1kvmerzu64094dt9t62ea0cp75larh39ulzldum", "amount": [ { "denom": "ngonka", "amount": "3368636073541" } ] }, { "recipient": "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "amount": [ { "denom": "ngonka", "amount": "2248987476581" } ] }, { "recipient": "gonka1ym3np7guxart483yfdxnlztuazx22cjt0e4a2p", "amount": [ { "denom": "ngonka", "amount": "1706210826186" } ] } ], "vesting_epochs": "160" } ] ``` --- ## #83 – Approve devshard v3 # #83 – Approve devshard v3 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`](https://gonka.gg/address/gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/83){:target="_blank"} Update current chain params by adding v3 to devshard_escrow_params.approved_versions. --- ## Final Tally 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) ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "35", "poc_exchange_duration": "0", "poc_validation_delay": "5", "poc_validation_duration": "240", "set_new_validators_delay": "120", "inference_validation_cutoff": "2", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "500" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "processed_logprobs" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": true, "confirmation_poc_v2_enabled": true, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": true, "poc_stronger_rng_enabled": false, "models": [ { "model_id": "MiniMaxAI/MiniMax-M2.7", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "75", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "3024", "exponent": -4 }, "penalty_start_epoch": "278" }, { "model_id": "moonshotai/Kimi-K2.6", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "4", "exponent": -1 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "90", "exponent": -2 }, "penalty_start_epoch": "310" }, { "model_id": "zai-org/GLM-5.2-FP8", "seq_len": "1024", "stat_test": { "dist_threshold": { "value": "45", "exponent": -2 }, "p_mismatch": { "value": "1", "exponent": -1 }, "p_value_threshold": { "value": "5", "exponent": -2 } }, "weight_scale_factor": { "value": "247", "exponent": -2 }, "penalty_start_epoch": "500" } ], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": { "network_maturity_threshold": "15000000", "network_maturity_min_height": "3000000", "guardian_addresses": [ "gonkavaloper1y2a9p56kv044327uycmqdexl7zs82fs5lyang5", "gonkavaloper1dkl4mah5erqggvhqkpc8j3qs5tyuetgdc59d0v", "gonkavaloper1kx9mca3xm8u8ypzfuhmxey66u0ufxhs70mtf0e" ] }, "developer_access_params": { "until_block_height": "2459367", "allowed_developer_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d", "gonka1x7zh2277spp7jfqjhv0g5mnezg290xdr4kpfnk", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1khca2ht3m0nvpfghrxwgvnmj74t0sx6qzc2edd" ] }, "participant_access_params": { "new_participant_registration_start_height": "2475000", "blocked_participant_addresses": [ "gonka1blockedxxxxxxxxxxxxxxxxxxxxxx" ], "use_participant_allowlist": true, "participant_allowlist_until_block_height": "2475000" }, "transfer_agent_access_params": { "allowed_transfer_addresses": [ "gonka1y2a9p56kv044327uycmqdexl7zs82fs5ryv5le", "gonka1dkl4mah5erqggvhqkpc8j3qs5tyuetgdy552cp", "gonka1kx9mca3xm8u8ypzfuhmxey66u0ufxhs7nm6wc5", "gonka1ddswmmmn38esxegjf6qw36mt4aqyw6etvysy5x", "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u" ] }, "devshard_escrow_params": { "min_amount": "50000000", "max_amount": "100000000000", "max_escrows_per_epoch": 500000, "group_size": 16, "allowed_creator_addresses": [ "gonka10fynmy2npvdvew0vj2288gz8ljfvmjs35lat8n", "gonka1uyqp5z3dveamfw4pmw7p7rfvwdvgzewnqrzhsu", "gonka1sy7ug80wrnm6gk47creak0j5eagjpf7maqcqwk", "gonka1w66aw6jayepglwgz66qtunetr5nyw9ls7evq5g", "gonka1v8gk5z7gcv72447yfcd2y8g78qk05yc4f3nk4w", "gonka1gndhek2h2y5849wf6tmw6gnw9qn4vysgljed0u", "gonka1z66ec2zedwpapp6jrj9raxgl93e5ec9z5my52h", "gonka1jw6xg0wun3g8m2fjm8lula82dw5p6jl8yp28mn", "gonka15sjedpgseutpnrjx2ge3mgau3s8ft5qzym9waa", "gonka1l4a2wtls9rgd2mnnj6mheml5xlq3kknngj4p7h", "gonka1f3yg5385n3f9pdw2g3dcjcnfqyej67hcu9vfet", "gonka15g5pu70k7l6hvdt8xl80h4mxe332762csupaeg", "gonka1p0uanq0aay6n3l4gtnshg63cy6vx3zgvkyc5lc", "gonka1r2s0rwgskp6y4ed7qr7d25qdwjwlvpp6demv90", "gonka1ls8wqecwj369du8s2t9a223xu9sgvmzlw2ye9c", "gonka10wmset95nhgfjt4wklsyjqpx55m40zy3gha2pn", "gonka17ld2g62230w0erzexefzw03sw0adtuchr425rp" ], "token_price": "10", "approved_versions": [ { "name": "v1", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v1/devshardd.zip", "sha256": "dad6f1b97843816c0a33874b89ac403e48b54fe3aa1a0fdccb228d89d2a5594c" }, { "name": "v2", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fdevshard%2Fv2.0.0/devshardd.zip", "sha256": "1a3b58bd0ac20dbb8baa68b1bf6c80516ca3c0f4d39e06160d07613ec1b1340b" }, { "name": "v3", "binary": "https://github.com/gonka-ai/gonka/releases/download/release%2Fv0.2.13-devshard-v3.0.0/devshardd.zip", "sha256": "ca1294fc8db3f0907a01f362eb4b13665f66d0fd12cfc6f01468b1e27f0bab63" } ], "max_nonce": 1000000, "devshard_requests_enabled": true, "default_inference_seal_grace_nonces": 0, "default_inference_seal_grace_seconds": 0, "create_devshard_fee": "0", "fee_per_nonce": "0", "refusal_timeout": "0", "execution_timeout": "0", "validation_rate": 0, "vote_threshold_factor": 0, "default_auto_seal_every_n_nonces": 0 }, "fee_params": { "min_gas_price_ngonka": "0", "base_validation_gas": "500000", "gas_per_poc_count": "100" }, "delegation_params": { "deploy_window": "500", "refusal_penalty": { "value": "1", "exponent": -1 }, "no_participation_penalty": { "value": "15", "exponent": -2 }, "delegation_share": { "value": "5", "exponent": -2 }, "w_threshold": { "value": "1", "exponent": -1 }, "v_min": "3", "cap_factor": { "value": "75", "exponent": -2 }, "initial_model_id": "MiniMaxAI/MiniMax-M2.7", "max_model_voting_power_percentage": { "value": "3", "exponent": -1 } }, "maintenance_params": null } } ] ``` --- ## Upgrade Proposal: v0.2.14 # Upgrade Proposal: v0.2.14 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. ## 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 1. Active hosts review this proposal on GitHub. 2. The devshard v3 release is proposed and rolled out before the mainnet chain upgrade. 3. Brokers switch inference traffic to `/devshard/v3`. 4. If the on-chain proposal is approved, this PR will be merged immediately after the upgrade is executed on-chain. ## Changes ### inference-chain / decentralized-api - Replace the PoC artifact store with SMST-based nonce indexing to prevent duplicate artifacts, with benchmarks, params, and snapshot rebuild fixes [`9a63468`](https://github.com/gonka-ai/gonka/commit/9a6346862e9b365db7994cfa2f07aa81a2a5f958), [`22a21b0`](https://github.com/gonka-ai/gonka/commit/22a21b0b6d893200af0a88f5bb551d238c64f556) by @gmorgachev, @DimaOrekhovPS, @0xMayoor. - Add DAPI-side early-share detection as an additional security layer, later reworked to check inclusion by nonce instead of dense index so it stays correct against the SMST store [#1382](https://github.com/gonka-ai/gonka/pull/1382), [#1416](https://github.com/gonka-ai/gonka/pull/1416) by @libermans, @DimaOrekhovPS, @gmorgachev. - Remove deprecated classic decentralized-api inference paths and bind devshard routes to runtime versions [#1386](https://github.com/gonka-ai/gonka/pull/1386) by @gmorgachev. - Track the last software upgrade height and fix disabling cPoC in the window around chain upgrades [#1268](https://github.com/gonka-ai/gonka/pull/1268) by @patimen. - Seed maintenance-window params in the v0.2.14 handler with maintenance disabled by default, so governance can enable it later [#998](https://github.com/gonka-ai/gonka/pull/998), [#1428](https://github.com/gonka-ai/gonka/pull/1428) by @Ryanchen911, @DimaOrekhovPS. - Zero mint inflation during upgrade, burn the fee collector base-denom balance, and add Dahl (@paranjko) to allowed devshard escrow creators [#1418](https://github.com/gonka-ai/gonka/pull/1418) by @gmorgachev. - Add on-chain configurable reward claim recipients and apply them to stale devshard escrow payouts [#889](https://github.com/gonka-ai/gonka/pull/889), [#1377](https://github.com/gonka-ai/gonka/pull/1377) by @alancapex, @DimaOrekhovPS. - Prevent reward payments for incoming delegations from excluded hosts [#1378](https://github.com/gonka-ai/gonka/pull/1378) by @gmorgachev. - Add a total supply endpoint for integrations that need plain-text GONKA supply [#1346](https://github.com/gonka-ai/gonka/pull/1346) by @DimaOrekhovPS. - Sync bridge block progress so Ethereum transactions are not lost if nodes restart during upgrade [#1376](https://github.com/gonka-ai/gonka/pull/1376) by @GLiberman. - Smaller settlement, validation, fee, and setup-report fixes: [#1100](https://github.com/gonka-ai/gonka/pull/1100), [#1101](https://github.com/gonka-ai/gonka/pull/1101), [#1129](https://github.com/gonka-ai/gonka/pull/1129), [#1160](https://github.com/gonka-ai/gonka/pull/1160), [#1253](https://github.com/gonka-ai/gonka/pull/1253), [#1255](https://github.com/gonka-ai/gonka/pull/1255), [#1278](https://github.com/gonka-ai/gonka/pull/1278), [#1307](https://github.com/gonka-ai/gonka/pull/1307), [#1383](https://github.com/gonka-ai/gonka/pull/1383), [#1413](https://github.com/gonka-ai/gonka/pull/1413) by @0xMayoor, @0xgonka, @ouicate, @redstartechno, @GLiberman, @DimaOrekhovPS. ### devshard - Serve inference during the PoC validation phase on validation-inference-capable nodes [#1348](https://github.com/gonka-ai/gonka/pull/1348) by @qdanik, @gmorgachev. - Enable standalone `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](https://github.com/gonka-ai/gonka/pull/1417) by @akup. - Fix a production host leak where failed session resolution left validation workers alive [#1417](https://github.com/gonka-ai/gonka/pull/1417) by @gmorgachev. - Collect gateway v3 fixes: runtime versioning, observability, escrow rotation, request parameter validation, SSE handling, drain barriers, and gateway v2 cleanup [#1427](https://github.com/gonka-ai/gonka/pull/1427) by @gmorgachev, @qdanik, @libermans, @a-kuprin. - Distribute unsettled devshard escrow by slot instead of unique address [#1347](https://github.com/gonka-ai/gonka/pull/1347) by @0xMayoor. ## Testing 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. ## Contributors (sorted alphabetically) - @0xgonka - @0xMayoor - @a-kuprin - @akup - @alancapex - @d-bogdan-engenious (testing) - @DimaOrekhovPS - @GLiberman - @gmorgachev - @libermans - @maria-mitina (testing) - @ouicate - @patimen - @qdanik - @redstartechno - @Ryanchen911 --- ## #89 – Upgrade Proposal: v0.2.14 # #89 – Upgrade Proposal: v0.2.14 Passed **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.14/proposals/governance-artifacts/update-v0.2.14/README.md](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.14/proposals/governance-artifacts/update-v0.2.14/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/89){:target="_blank"} Upgrade Proposal: v0.2.14 --- ## Final Tally Yes 296,240 (100.0%) No 0 (0.0%) Veto 115 (0.0%) Abstain 0 (0.0%) Total 296,355 votes ✓ Turnout 296,355 / 545,426 (54.3%) · Quorum 25% (136,356) ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.14", "time": "0001-01-01T00:00:00Z", "height": "5195700", "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 }", "upgraded_client_state": null } } ] ``` --- ## 2025-Q4 Proposals # 2025-Q4 Proposals Passed Rejected Voting With Funding ## 2025-Q4 Summary 11Total Proposals 10Passed (91%) 1Rejected (9%) Governance Parameters5 Software Upgrade5 Funding / Grants1 20,000,000 GNK · Community Pool 2025-Q4 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%) ← Back to all proposals --- ## Upgrade Proposal: v0.2.5 # Upgrade Proposal: v0.2.5 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. ## Upgrade Plan 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`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.5/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. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. Once the PR is approved by a majority, a `v0.2.5` 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 hosts. The `bridge` container can be started any time after upgrade by: 1. Pulling the latest changes from `main` branch (after `upgrade-v0.2.5` merged) ``` git pull ``` 2. Start ``` source config.env && docker compose up bridge -d ``` It'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). ## Further Steps The PR introduces 3 contracts: - [liquidity pool](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.5/inference-chain/contracts/liquidity-pool/) - [wrapped token](https://github.com/gonka-ai/gonka/tree/upgrade-v0.2.5/inference-chain/contracts/wrapped-token/) - [Ethereum contract](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.5/proposals/ethereum-bridge-contact/BridgeContract.sol) All contracts might be proposed for voter approval via separate proposals. ## Testing ### Testnet 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. ## Migration The on-chain migration logic and default values for new parameters are defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.5/inference-chain/app/upgrades/v0_2_5/upgrades.go). Specific data migrations are implemented in: - [`migrations_confirmation_weight.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.5/inference-chain/x/inference/keeper/migrations_confirmation_weight.go): Initializes confirmation weights for the current epoch. - [`migrations_bridge.go`](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.5/inference-chain/x/inference/keeper/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. ## Changes --- ### Native Bridge Commit: [f7470c1eab3ebdda30dda90b0d81131b7b472a64](https://github.com/gonka-ai/gonka/pull/404/commits/168f7a8652260528c56acb25d918e7be5a19beca). This commit introduces primitives for native bridge for the Ethereum blockchain and contracts for its integration. Details can be found [here](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.5/proposals/governance-artifacts/update-v0.2.5/bridge.md). --- ### BLS Signature fix Commit: [f7470c1eab3ebdda30dda90b0d81131b7b472a64](https://github.com/gonka-ai/gonka/pull/404/commits/f7470c1eab3ebdda30dda90b0d81131b7b472a64). This commit fixes a bug in BLS Group Public Key generation. --- ### Participant Status Update Commit: [101062297948f9a9574266adaf6439500502d6ba](https://github.com/gonka-ai/gonka/pull/404/commits/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](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.5/proposals/invalid-participant-exclusion/README.md) --- ### Confirmation PoC Commit: [e9dbf137b0fbb050c724877b4b607da88ab1dc64](https://github.com/gonka-ai/gonka/pull/404/commits/e9dbf137b0fbb050c724877b4b607da88ab1dc64) This commit introduces Random Confirmation PoC - a new layer to verify inference-serving nodes maintain computational capacity during the whole epoch. Details: [here](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.5/proposals/random-poc/README.md) --- ### New Schedule for `POC_SLOT=true` (nodes who serves inference during PoC) Commit: [9ce1b6099529e69cdfd792f966efedb077c4ad86](https://github.com/gonka-ai/gonka/pull/404/commits/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](https://github.com/gonka-ai/gonka/blob/upgrade-v0.2.5/proposals/poc-schedule-v2/README.md) --- ### Blackwell Support for MLNode and Fixes Commit: [b77dcaca528ccfcf74e5f02d2bc90d55229a22f5](https://github.com/gonka-ai/gonka/pull/404/commits/b77dcaca528ccfcf74e5f02d2bc90d55229a22f5) Fix for vLLM to support Blackwell GPUs (tested on B200). --- ### Account transfer fix Commit: [4228a70579c195fcb7b989ddf19006d0ddf1e8ae](https://github.com/gonka-ai/gonka/pull/404/commits/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. --- ### Paginator fix for `GetMembers` Commit: [bbce9f4f296c4df9b722367f47b162c9cb6f6d46](https://github.com/gonka-ai/gonka/pull/404/commits/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. --- ### MLNode status check fixes, retry mechanism Commit: [1352c131aff8713578033362b7dc2c3e22684277](https://github.com/gonka-ai/gonka/pull/404/commits/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. --- ### Recalculate total weight after punishment Commit: [cf2d3931d2a1f8f9205194d12a4d7aa9b1d43980](https://github.com/gonka-ai/gonka/pull/404/commits/cf2d3931d2a1f8f9205194d12a4d7aa9b1d43980) The commit fixes a bug where undistributed rewards paid to the first host included rewards for invalid participants. --- ### BLS Signature Fixes: Aggreagation and format Commit: [e4bbb293f79ed0f368900092c9e65393ca25bfdf](https://github.com/gonka-ai/gonka/pull/404/commits/e4bbb293f79ed0f368900092c9e65393ca25bfdf) This commit fixes aggregation of partial signatures and align format with Etherium pre-compiled. ### Changing default MLNode state to INFERENCE Commit: [deefc869249c873377ae0feb0336aee3ac5034f1](https://github.com/gonka-ai/gonka/pull/404/commits/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 -- --- ## #13 – Upgrade Proposal: v0.2.5 # #13 – Upgrade Proposal: v0.2.5 Passed **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/e25ddb7d462972cce202c8b39448bf3feb8e29a0/proposals/governance-artifacts/update-v0.2.5/README.md](https://github.com/gonka-ai/gonka/blob/e25ddb7d462972cce202c8b39448bf3feb8e29a0/proposals/governance-artifacts/update-v0.2.5/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/13){:target="_blank"} Upgrade Proposal: v0.2.5 --- ## Final Tally Yes 428,459 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 428,459 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.5", "time": "0001-01-01T00:00:00Z", "height": "1404000", "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 }", "upgraded_client_state": null } } ] ``` --- ## #17 – Expected amount of Confirmation PoC per epoch # #17 – Expected amount of Confirmation PoC per epoch 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/17){:target="_blank"} Expected amount of Confirmation PoC per epoch to 4, p0 for binomial test to 0.1 --- ## Final Tally Yes 3,261,413 (100.0%) No 85 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 3,261,498 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "60", "poc_exchange_duration": "5", "poc_validation_delay": "5", "poc_validation_duration": "120", "set_new_validators_delay": "120", "inference_validation_cutoff": "20", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": { "value": "1", "exponent": -1 }, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "150", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": { "value": "0", "exponent": 0 }, "bad_participant_invalidation_rate": { "value": "1", "exponent": -1 }, "invalidation_h_threshold": { "value": "4", "exponent": 0 }, "downtime_good_percentage": { "value": "98", "exponent": -2 }, "downtime_bad_percentage": { "value": "99", "exponent": -2 }, "downtime_h_threshold": { "value": "1", "exponent": 2 }, "downtime_reputation_preserve": { "value": "0", "exponent": 0 }, "quick_failure_threshold": { "value": "1", "exponent": -6 }, "binom_test_p0": { "value": "1", "exponent": -1 }, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": { "value": "25", "exponent": -1 }, "model_params": { "dim": 1792, "n_layers": 64, "n_heads": 64, "n_kv_heads": 64, "vocab_size": 8196, "ffn_dim_multiplier": { "value": "1", "exponent": 1 }, "multiple_of": 8192, "norm_eps": { "value": "1", "exponent": -5 }, "rope_theta": 10000, "use_scaled_rope": false, "seq_len": 256, "r_target": { "value": "1398077", "exponent": -6 } }, "model_id": "", "seq_len": "0", "poc_v2_enabled": false, "confirmation_poc_v2_enabled": false, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 1, "max_inferences_per_block": "1000" }, "confirmation_poc_params": { "expected_confirmations_per_epoch": "4", "alpha_threshold": { "value": "5", "exponent": -1 }, "slash_fraction": { "value": "0", "exponent": 0 }, "upgrade_protection_window": "500" }, "genesis_guardian_params": null, "developer_access_params": null, "participant_access_params": null, "transfer_agent_access_params": null, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } } ] ``` --- ## #11 – Bandwidth Limits # #11 – Bandwidth Limits Passed **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/11){:target="_blank"} Bandwidth Limits --- ## Final Tally Yes 349,596 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 349,596 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "60", "poc_exchange_duration": "5", "poc_validation_delay": "5", "poc_validation_duration": "120", "set_new_validators_delay": "120", "inference_validation_cutoff": "80", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": null, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "100", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": null, "bad_participant_invalidation_rate": null, "invalidation_h_threshold": null, "downtime_good_percentage": null, "downtime_bad_percentage": null, "downtime_h_threshold": null, "downtime_reputation_preserve": null, "quick_failure_threshold": null, "binom_test_p0": null, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": false, "confirmation_poc_v2_enabled": false, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "0" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 0, "max_inferences_per_block": "0" }, "confirmation_poc_params": null, "genesis_guardian_params": null, "developer_access_params": null, "participant_access_params": null, "transfer_agent_access_params": null, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } } ] ``` --- ## #12 – Bandwidth Limits # #12 – Bandwidth Limits Passed **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/12){:target="_blank"} Bandwidth Limits --- ## Final Tally Yes 257,565 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 257,565 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "60", "poc_exchange_duration": "5", "poc_validation_delay": "5", "poc_validation_duration": "120", "set_new_validators_delay": "120", "inference_validation_cutoff": "80", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": null, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "100", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "300", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": null, "bad_participant_invalidation_rate": null, "invalidation_h_threshold": null, "downtime_good_percentage": null, "downtime_bad_percentage": null, "downtime_h_threshold": null, "downtime_reputation_preserve": null, "quick_failure_threshold": null, "binom_test_p0": null, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": false, "confirmation_poc_v2_enabled": false, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "100" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 0, "max_inferences_per_block": "0" }, "confirmation_poc_params": null, "genesis_guardian_params": null, "developer_access_params": null, "participant_access_params": null, "transfer_agent_access_params": null, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } } ] ``` --- ## #10 – Bandwidth Limits # #10 – Bandwidth Limits 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/10){:target="_blank"} Bandwidth Limits --- ## Final Tally Yes 287,496 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 287,496 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "60", "poc_exchange_duration": "5", "poc_validation_delay": "5", "poc_validation_duration": "120", "set_new_validators_delay": "120", "inference_validation_cutoff": "80", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": null, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "20", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "60", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": null, "bad_participant_invalidation_rate": null, "invalidation_h_threshold": null, "downtime_good_percentage": null, "downtime_bad_percentage": null, "downtime_h_threshold": null, "downtime_reputation_preserve": null, "quick_failure_threshold": null, "binom_test_p0": null, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": false, "confirmation_poc_v2_enabled": false, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "0" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "53760", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 0, "max_inferences_per_block": "0" }, "confirmation_poc_params": null, "genesis_guardian_params": null, "developer_access_params": null, "participant_access_params": null, "transfer_agent_access_params": null, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } } ] ``` --- ## #14 – Sale GNK from Community Fund # #14 – Sale GNK from Community Fund 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} 20,000,000 GNK · Community Pool [View on gonka.gg](https://gonka.gg/network/proposals/14){:target="_blank"} Sale GNK from Community Fund --- ## Final Tally 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 ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.distribution.v1beta1.MsgCommunityPoolSpend` | Contract Details ```json [ { "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "recipient": "gonka18pkq9mwxxlmyq7kr5txhm060wemg2s4u94wvsfd9w2kdc0u99d6spk8pz2", "amount": [ { "denom": "ngonka", "amount": "20000000000000000" } ] } ] ``` --- ## Upgrade Proposal: v0.2.6 # Upgrade Proposal: v0.2.6 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. ## Upgrade Plan 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`](https://github.com/gonka-ai/gonka/blob/gm/dev-0.2.6/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. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. Once the PR is approved by a majority, a `v0.2.6` 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 hosts. ## Optional: PostgreSQL for Payload Storage 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 source config.env && docker compose -f docker-compose.postgres.yml up -d ``` ## Testing The 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. ## Migration The on-chain migration logic is defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/gm/dev-0.2.6/inference-chain/app/upgrades/v0_2_6/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) ## Changes --- ### Off-Chain Payloads Commit: [477fb6e81](https://github.com/gonka-ai/gonka/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](https://github.com/gonka-ai/gonka/blob/gm/dev-0.2.6/proposals/offchain-payloads/README.md) --- ### Transaction Batching Commit: [288b37732](https://github.com/gonka-ai/gonka/commit/288b37732) Batching for StartInference/FinishInference transactions. --- ### PoC Parameters On-Chain Commits: [86ebd4d65](https://github.com/gonka-ai/gonka/commit/86ebd4d65), [806b01616](https://github.com/gonka-ai/gonka/commit/806b01616), [f41e05142](https://github.com/gonka-ai/gonka/commit/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. --- ### BLS DealerShared Recovery Commit: [5b22aafd5](https://github.com/gonka-ai/gonka/commit/5b22aafd5) Enables BLS secret recovery when container restarts. --- ### Nodes Always Available Commit: [093c2e36a](https://github.com/gonka-ai/gonka/commit/093c2e36a) Nodes remain available for inference even when disabled for next epoch. --- ### NATS Storage Fix Commit: [ae938d357](https://github.com/gonka-ai/gonka/commit/ae938d357) NATS messages retained for 24 hours instead of forever. Resolves issue with large `.dapi/.nats` directory. --- ### Force Recovery Commit: [fe02ed509](https://github.com/gonka-ai/gonka/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. --- ### Epoch Performance Query Commit: [08ad82a7b](https://github.com/gonka-ai/gonka/commit/08ad82a7b) Adds `EpochPerformanceSummaryAll` query endpoint. --- ### GPU Distribution Fix Commit: [fae7d20a5](https://github.com/gonka-ai/gonka/commit/fae7d20a5) Limits PoC batch queue per GPU to prevent one GPU from accumulating all batches. Ensures even distribution across multiple GPUs. --- ### ClaimReward Performance Commits: [19755e70d](https://github.com/gonka-ai/gonka/commit/19755e70d), [933eeb296](https://github.com/gonka-ai/gonka/commit/933eeb296), [8df8a1cf9](https://github.com/gonka-ai/gonka/commit/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). --- ### PoC Confirmation Weight Fix [Bounty Bug] Commit: [b44d51e0c](https://github.com/gonka-ai/gonka/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 --- ### Upgrade Rewards Distribution Commit: [676f5e620](https://github.com/gonka-ai/gonka/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](https://github.com/gonka-ai/gonka/blob/gm/dev-0.2.6/inference-chain/app/upgrades/v0_2_6/upgrades.go). --- ## #15 – Upgrade Proposal: v0.2.6 # #15 – Upgrade Proposal: v0.2.6 Rejected **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/384b95025f11cff177fa40ec191f724852f54edb/proposals/governance-artifacts/update-v0.2.6/README.md](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](https://gonka.gg/network/proposals/15){:target="_blank"} Upgrade Proposal: v0.2.6 --- ## Final Tally Yes 1,034,445 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 1,034,445 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.6", "time": "0001-01-01T00:00:00Z", "height": "1773000", "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 }", "upgraded_client_state": null } } ] ``` --- ## Upgrade Proposal: v0.2.3 # Upgrade Proposal: v0.2.3 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. ## Upgrade Plan 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. ## Testing ### Testnet 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. ## Changes ### Replace listening to Tx events with querying blocks for event data (`5830799a390a5303445c0515d1db28ba5d943dcb`) 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: - Event listener now has a single subscription: `tendermint/event/NewBlock` - Each new block pushes a height update to `BlockObserver` in `block_observer.go` - `BlockObserver` queries events for incoming blocks and tracks the last processed block height - `Tx` event worker pool still initializes in `event_listener.go` but reads from `BlockObserver` event queue - Special barrier events act as delivery notification mechanism for all events in a given block ### Reproducible seed from Epoch Signature (`1fe45b447b070b31fbb7ead59c60634f39116386`) 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. ### Certik Audit fixes (`5596c5765c0b449de69f3d6ca03125fa9ff4f63e`) Batch of minor fixes addressing Certik audit findings. ### Batch processing of inferences on validation (`49a2976e19379c5935c99063862c9652039bfa5d`) Fixed a bug where the chain failed to process inference batches under high load conditions. ### Auto re-query of unclaimed rewards (`52796f18e2b00579f901eb9576a715169e3bfc54`) Implemented automatic re-querying mechanism for rewards that were not claimed on initial attempt. ### cosmos-sdk cleanup (`c4592d6141232b7677c4d940ac1933aa5d1fe16c`) 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 ### proxy and proxy-ssl services (`80437507ea40eddd67c518074675f9c7970eb627`) 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. --- ## #7 – Upgrade Proposal: v0.2.3 # #7 – Upgrade Proposal: v0.2.3 Passed **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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/b8094aaf75bde4041692675dd9e565286b056896/proposals/governance-artifacts/update-v0.2.3/README.md](https://github.com/gonka-ai/gonka/blob/b8094aaf75bde4041692675dd9e565286b056896/proposals/governance-artifacts/update-v0.2.3/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/7){:target="_blank"} Upgrade Proposal: v0.2.3 --- ## Final Tally Yes 132,672 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 132,672 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.3", "time": "0001-01-01T00:00:00Z", "height": "645400", "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 }", "upgraded_client_state": null } } ] ``` --- ## Upgrade Proposal: v0.2.4 # Upgrade Proposal: v0.2.4 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. ## Upgrade Plan 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`). ## Testing ### Testnet 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. ## Changes --- ### Training Security See the commits related to this change [here](https://github.com/gonka-ai/gonka/pull/385/commits/c8a9391b29a7a21100f42a71f0ccd67f40bf0e05) and [here](https://github.com/gonka-ai/gonka/pull/358/commits/4d3e49de4aa499dee042c397062c78a0fc94413a) #### Overview 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 #### Solution 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. --- ### Major Certik Audit fixes 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](https://github.com/gonka-ai/gonka/pull/385/commits/be00dc0188fd028a967b4167ed287af6124f4d14) #### Pubkey must match address When adding a new Participant, the pubkey must match the address (GOC-12). Specific changes [here](https://github.com/gonka-ai/gonka/pull/358/commits/1867daadd77c73f2807b273f2b2ce3dfa0107859) #### Panic avoidance during EndBlock 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](https://github.com/gonka-ai/gonka/pull/358/commits/505a3e4be8f4d7489a95a5a7f9d05879095b1161) and [here](https://github.com/gonka-ai/gonka/pull/358/commits/eef739c614f8167b100819e5617253e53ac8d6df) #### Validate inference timestamps on chain 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](https://github.com/gonka-ai/gonka/pull/358/commits/fe2d5284c00e7e095b7a16fff00ccea4794d429e) #### Pruning Improvements 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](https://github.com/gonka-ai/gonka/pull/358/commits/1bbda08851a69f07b99efc5f6a7aa35d49171914) and [here](https://github.com/gonka-ai/gonka/pull/358/commits/f190ba597c819c213d291708a164e6a18f7fb15f) #### Validation Limits `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](https://github.com/gonka-ai/gonka/pull/358/commits/393ad481868ff04fb942a0a322c22eef560a304a) and [here](https://github.com/gonka-ai/gonka/pull/358/commits/ff68328ec21f692ac70415fd1ab8fab16baef771) --- ### Config Management Improvements for API nodes #### Config Storage 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. #### Solution Introduce a file based SqlLite DB to handle changing values and synchronize them for the API node. Source code is [here](https://github.com/gonka-ai/gonka/pull/385/files/be00dc0188fd028a967b4167ed287af6124f4d14..7fcd6a374d0c2da565d6174a8eb5940acbc97957) #### MLNode management api 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. --- ### Unordered Transaction Timeout fix #### Context 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 #### Problem 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. #### Solution - Use the latest block time instead of node machine time to sign and verify TTL for transactions - Detect slow or halted chains and stop sending retries to allow better chain recovery - Cap number of retry attempts (at 100 for now) Source code is [here](https://github.com/gonka-ai/gonka/pull/385/commits/c17e288333c41d64ca9f38cf3c4873ed0a2f9e2d) --- ### Support small GPUs on TestNet #### Problem `testnet` should support smaller GPUs in order to encourage bigger participation in testnet, increasing tests and therefore network robustness. #### Solution - Add testenv specific environment variables to detect when the chain is testnet vs mainnet - Add testenv specific params to have different proof-of-compute configurations (enabling smaller GPUs and faster testing) Full changes are [here](https://github.com/gonka-ai/gonka/pull/385/commits/45fda6d3329f3b795e8a0c1bd86396665d39a3de) --- ### MLNode Management APIs & vLLM Stability Improvements Far more details available in the PR description at the top [here](https://github.com/gonka-ai/gonka/pull/385/commits/492164a07d845b6dfb2b30a8a575ed7e5d46ddf1), 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. --- ### Health endpoints for MLNode and experimental auto-detection for node setup issues [here](https://github.com/gonka-ai/gonka/pull/385/commits/b7b284f42145dc0130a89fe151a74a13d2fe2571) --- ## #8 – Upgrade Proposal: v0.2.4 # #8 – Upgrade Proposal: v0.2.4 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/blob/12a09bb24c1f668a23f0e85bbf277e6010603921/proposals/governance-artifacts/update-v0.2.4/README.md](https://github.com/gonka-ai/gonka/blob/12a09bb24c1f668a23f0e85bbf277e6010603921/proposals/governance-artifacts/update-v0.2.4/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/8){:target="_blank"} Upgrade Proposal: v0.2.4 --- ## Final Tally Yes 286,826 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 286,826 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.4", "time": "0001-01-01T00:00:00Z", "height": "937700", "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 }", "upgraded_client_state": null } } ] ``` --- ## #9 – Higher Bandwidth Limits & Voting Time Back to 24H # #9 – Higher Bandwidth Limits & Voting Time Back to 24H 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} [View on gonka.gg](https://gonka.gg/network/proposals/9){:target="_blank"} Higher Bandwidth Limits & Voting Time Back to 24H --- ## Final Tally Yes 394,887 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 394,887 votes ## Messages | # | Type | | :- | :--- | | 1 | `/inference.inference.MsgUpdateParams` | | 2 | `/cosmos.gov.v1.MsgUpdateParams` | Contract Details ```json [ { "@type": "/inference.inference.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "epoch_params": { "epoch_length": "15391", "epoch_multiplier": "1", "epoch_shift": "16980", "default_unit_of_compute_price": "100", "poc_stage_duration": "60", "poc_exchange_duration": "5", "poc_validation_delay": "5", "poc_validation_duration": "120", "set_new_validators_delay": "120", "inference_validation_cutoff": "80", "inference_pruning_epoch_threshold": "2", "inference_pruning_max": "5000", "poc_pruning_max": "1000", "poc_slot_allocation": null, "confirmation_poc_safety_window": "0" }, "validation_params": { "false_positive_rate": { "value": "5", "exponent": -2 }, "min_ramp_up_measurements": 10, "pass_value": { "value": "99", "exponent": -2 }, "min_validation_average": { "value": "1", "exponent": -2 }, "max_validation_average": { "value": "1", "exponent": 0 }, "expiration_blocks": "20", "epochs_to_max": "30", "full_validation_traffic_cutoff": "10000", "min_validation_halfway": { "value": "5", "exponent": -2 }, "min_validation_traffic_cutoff": "100", "miss_percentage_cutoff": { "value": "1", "exponent": -2 }, "miss_requests_penalty": { "value": "1", "exponent": 0 }, "timestamp_expiration": "60", "timestamp_advance": "30", "estimated_limits_per_block_kb": "0", "invalid_reputation_preserve": null, "bad_participant_invalidation_rate": null, "invalidation_h_threshold": null, "downtime_good_percentage": null, "downtime_bad_percentage": null, "downtime_h_threshold": null, "downtime_reputation_preserve": null, "quick_failure_threshold": null, "binom_test_p0": null, "claim_validation_enabled": false, "logprobs_mode": "" }, "poc_params": { "default_difficulty": 5, "validation_sample_size": 200, "poc_data_pruning_epoch_threshold": "1", "weight_scale_factor": null, "model_params": null, "model_id": "", "seq_len": "0", "poc_v2_enabled": false, "confirmation_poc_v2_enabled": false, "stat_test": null, "validation_slots": 0, "poc_normalization_enabled": false, "poc_stronger_rng_enabled": false, "models": [], "validation_vote_threshold_bps": 0 }, "tokenomics_params": { "subsidy_reduction_interval": { "value": "5", "exponent": -2 }, "subsidy_reduction_amount": { "value": "2", "exponent": -1 }, "current_subsidy_percentage": { "value": "9", "exponent": -1 }, "work_vesting_period": "180", "reward_vesting_period": "180" }, "collateral_params": { "slash_fraction_invalid": { "value": "2", "exponent": -1 }, "slash_fraction_downtime": { "value": "1", "exponent": -1 }, "downtime_missed_percentage_threshold": { "value": "5", "exponent": -2 }, "grace_period_end_epoch": "180", "base_weight_ratio": { "value": "2", "exponent": -1 }, "collateral_per_weight_unit": { "value": "42", "exponent": -1 } }, "bitcoin_reward_params": { "use_bitcoin_rewards": true, "initial_epoch_reward": "323000000000000", "decay_rate": { "value": "-475", "exponent": -6 }, "genesis_epoch": "1", "utilization_bonus_factor": { "value": "5", "exponent": -1 }, "full_coverage_bonus_factor": { "value": "12", "exponent": -1 }, "partial_coverage_bonus_factor": { "value": "1", "exponent": -1 } }, "dynamic_pricing_params": { "stability_zone_lower_bound": { "value": "4", "exponent": -1 }, "stability_zone_upper_bound": { "value": "6", "exponent": -1 }, "price_elasticity": { "value": "5", "exponent": -2 }, "utilization_window_duration": "60", "min_per_token_price": "1", "base_per_token_price": "100", "grace_period_end_epoch": "90", "grace_period_per_token_price": "0" }, "bandwidth_limits_params": { "estimated_limits_per_block_kb": "1075200", "kb_per_input_token": { "value": "23", "exponent": -4 }, "kb_per_output_token": { "value": "64", "exponent": -2 }, "invalidations_limit": "500", "invalidations_sample_period": "120", "invalidations_limit_curve": "250", "minimum_concurrent_invalidations": 0, "max_inferences_per_block": "0" }, "confirmation_poc_params": null, "genesis_guardian_params": null, "developer_access_params": null, "participant_access_params": null, "transfer_agent_access_params": null, "devshard_escrow_params": null, "fee_params": null, "delegation_params": null, "maintenance_params": null } }, { "@type": "/cosmos.gov.v1.MsgUpdateParams", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "params": { "min_deposit": [ { "denom": "ngonka", "amount": "25000000" } ], "max_deposit_period": "86400s", "voting_period": "86400s", "quorum": "0.334000000000000000", "threshold": "0.500000000000000000", "veto_threshold": "0.334000000000000000", "min_initial_deposit_ratio": "0.000000000000000000", "proposal_cancel_ratio": "0.500000000000000000", "proposal_cancel_dest": "", "expedited_voting_period": "10800s", "expedited_threshold": "0.667000000000000000", "expedited_min_deposit": [ { "denom": "ngonka", "amount": "50000000" } ], "burn_vote_quorum": false, "burn_proposal_deposit_prevote": false, "burn_vote_veto": true, "min_deposit_ratio": "0.010000000000000000" } } ] ``` --- ## Upgrade Proposal: v0.2.6 # Upgrade Proposal: v0.2.6 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. ## Upgrade Plan 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`](https://github.com/gonka-ai/gonka/blob/gm/dev-0.2.6/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. ## Proposed Process 1. Active hosts review this proposal on GitHub. 2. Once the PR is approved by a majority, a `v0.2.6` 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 hosts. ## Optional: PostgreSQL for Payload Storage 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 source config.env && docker compose -f docker-compose.postgres.yml up -d ``` ## Testing The 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. ## Migration The on-chain migration logic is defined in [`upgrades.go`](https://github.com/gonka-ai/gonka/blob/gm/dev-0.2.6/inference-chain/app/upgrades/v0_2_6/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) ## Changes --- ### Off-Chain Payloads Commit: [477fb6e81](https://github.com/gonka-ai/gonka/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](https://github.com/gonka-ai/gonka/blob/gm/dev-0.2.6/proposals/offchain-payloads/README.md) --- ### Transaction Batching Commit: [288b37732](https://github.com/gonka-ai/gonka/commit/288b37732) Batching for StartInference/FinishInference transactions. --- ### PoC Parameters On-Chain Commits: [86ebd4d65](https://github.com/gonka-ai/gonka/commit/86ebd4d65), [806b01616](https://github.com/gonka-ai/gonka/commit/806b01616), [f41e05142](https://github.com/gonka-ai/gonka/commit/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. --- ### BLS DealerShared Recovery Commit: [5b22aafd5](https://github.com/gonka-ai/gonka/commit/5b22aafd5) Enables BLS secret recovery when container restarts. --- ### Nodes Always Available Commit: [093c2e36a](https://github.com/gonka-ai/gonka/commit/093c2e36a) Nodes remain available for inference even when disabled for next epoch. --- ### NATS Storage Fix Commit: [ae938d357](https://github.com/gonka-ai/gonka/commit/ae938d357) NATS messages retained for 24 hours instead of forever. Resolves issue with large `.dapi/.nats` directory. --- ### Force Recovery Commit: [fe02ed509](https://github.com/gonka-ai/gonka/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. --- ### Epoch Performance Query Commit: [08ad82a7b](https://github.com/gonka-ai/gonka/commit/08ad82a7b) Adds `EpochPerformanceSummaryAll` query endpoint. --- ### GPU Distribution Fix Commit: [fae7d20a5](https://github.com/gonka-ai/gonka/commit/fae7d20a5) Limits PoC batch queue per GPU to prevent one GPU from accumulating all batches. Ensures even distribution across multiple GPUs. --- ### ClaimReward Performance Commits: [19755e70d](https://github.com/gonka-ai/gonka/commit/19755e70d), [933eeb296](https://github.com/gonka-ai/gonka/commit/933eeb296), [8df8a1cf9](https://github.com/gonka-ai/gonka/commit/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). --- ### PoC Confirmation Weight Fix [Bounty Bug] Commit: [b44d51e0c](https://github.com/gonka-ai/gonka/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 --- ### Upgrade Rewards Distribution Commit: [676f5e620](https://github.com/gonka-ai/gonka/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](https://github.com/gonka-ai/gonka/blob/gm/dev-0.2.6/inference-chain/app/upgrades/v0_2_6/upgrades.go). --- ## #16 – Upgrade Proposal: v0.2.6 # #16 – Upgrade Proposal: v0.2.6 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`](https://gonka.gg/address/gonka18lluv53n4h9z34qu20vxcvypgdkhsg6nn2cl2d){:target="_blank"} **Metadata:** [https://github.com/gonka-ai/gonka/commit/5be305ad380db8854313d2b0369049c8105f681b/proposals/governance-artifacts/update-v0.2.6/README.md](https://github.com/gonka-ai/gonka/commit/5be305ad380db8854313d2b0369049c8105f681b/proposals/governance-artifacts/update-v0.2.6/README.md) [View on gonka.gg](https://gonka.gg/network/proposals/16){:target="_blank"} Upgrade Proposal: v0.2.6 --- ## Final Tally Yes 1,985,917 (100.0%) No 0 (0.0%) Veto 0 (0.0%) Abstain 0 (0.0%) Total 1,985,917 votes ## Messages | # | Type | | :- | :--- | | 1 | `/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade` | Contract Details ```json [ { "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade", "authority": "gonka10d07y265gmmuvt4z0w9aw880jnsr700j2h5m33", "plan": { "name": "v0.2.6", "time": "0001-01-01T00:00:00Z", "height": "1820000", "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 }", "upgraded_client_state": null } } ] ``` ---