Week in Gonka: DevShard fix, PoC Challenge and TrainShards

Week September 21–27

PoC Challenge entered the branch of the upcoming v0.2.16 upgrade. It is a mechanism for checking a host's claimed capacity between regular PoCs. For DevShard, a fixed version v5.0.2 went to a vote; it stops nodes from failing because they run out of database connections. Both stages of TrainShards landed in the code: a mechanism for borrowing the network's GPUs for model training. Other votes covered marketing spending and a Gonka appearance at a conference in Singapore.

Key points

  • Tokens. The network processed 567.2B inference tokens this week — more than the week before (+144.5%).
  • Network. Network weight is 543,574 (+9.0% since the start of the week), GPUs in H100 terms 2,136 (+9.0%), participants 25 (−3).
  • PoC Challenge was merged into the v0.2.16 upgrade branch and will only work after that upgrade. It is an extra check on hosts on top of regular and confirmation PoC.
  • Proposal № 108 updates DevShard v5 to v5.0.2 and removes versions v3 and v4.
  • Both stages of TrainShards v0 were merged: reserving GPUs on chain and running training jobs on them off chain.

Network in numbers

Metric Now Before Change
Tokens this week, bn 567.2 231.9 +144.5%
Average per epoch, bn 81.0 33.1 —
Best epoch (400), bn 118.6 — —
Network weight 543,574 498,485 +9.0%
GPUs (H100) 2,136 1,959 +9.0%
Participants 25 28 −3

Tokens: the week is the last seven fully settled epochs (398–404), "before" is the seven epochs preceding them; an epoch total is final about one epoch after it ends. Weight, GPUs and participants: now and at the start of the week.

What changed

PoC Challenge (PR 1811). PoC, or proof of compute, checks that a host really has the computing capacity it claims. Regular PoC runs every epoch, and confirmation PoC is triggered at random during it. Now an approved address can challenge an active participant: the target is taken off inference and keeps generating PoC until the next regular PoC. The challenger locks a payment, a fraction of the target's reward for the rest of the epoch. If the target passes, it receives the payment. If it fails, it is treated like a failed confirmation PoC and the funds go back to the challenger. The code is in the v0.2.16 upgrade branch; the current mainnet version does not have this feature. A guard was added there as well (PR 1828): a challenge cannot be opened while the PoC parameter flag without which its votes are refused is switched off. In addition, the delay between the end of the PoC data exchange and the start of its validation can no longer be removed (PR 1846): without it, nodes voted before a challenge segment had finished, and a participant doing valid work could be marked as failed.

Fees (PR 1848). The v0.2.16 upgrade introduces message groups with separate gas rules. Messages that previously fell into no group, and so stayed free, are now assigned: some go to the epoch group, and governance authority messages go to a new governance group. That group is disabled, so proposals, votes and direct governance transactions stay free until governance enables it. According to the network announcement, all groups are disabled at upgrade and the protocol still charges no fees.

Warm keys (PR 1760). A warm key is an operational key that a participant's cold key grants rights for routine operations. It can now submit the declaration of intent to take part in PoC. At the v0.2.16 upgrade this right is added automatically to existing cold and warm key pairings, so the rights do not have to be granted again.

DevShard. This is the off-chain layer through which the gateway routes inference requests to hosts and pays them from escrow. An escrow holds funds locked in advance to pay for requests until final settlement. The aggregated PR 1584 of the DevShard v5 branch was merged: a height-sync protocol and a set of fixes. In the gateway (PR 1826) the finalize lock is now per escrow rather than global, so a slow finalize no longer stalls the others. An escrow whose funds are held by unfinished requests is put on hold instead of being replaced by a new escrow. Fixes from the v4.1.1 line, already running on mainnet, were carried into the v6 branch (PR 1781); that is a future version and has not shipped yet. The gateway now accepts the Bearer authorization scheme in any letter case (PR 1548). Closed: issue 1762, where the host and the gateway could read escrow timeouts differently and reach different decisions. The documentation gained a guide to a high-availability DevShard host (gonka-docs PR 1453) and a section on the Postgres connection limit (gonka-docs PR 1469): earlier versions sized connection pools by the host's CPU count, and the default limit was not enough.

TrainShards (PR 1350 and PR 1618). TrainShards v0 lets a researcher borrow the network's GPUs for training for a limited time. A run first needs an approved governance proposal. The chain picks matching nodes, reserves them and freezes their weight. While a node is reserved it does no inference and no PoC, and it receives no penalties. The off-chain part prepares the nodes, joins them into a mesh, deploys the container and collects a result for settlement.

PoC in the vLLM plugins. PoC work and ordinary chat requests are now processed in a shared batch instead of taking turns (gonka-vllm-plugins PR 8). This change targets a separate decode-PoC branch; the main branch is unaffected. The same scheme was prepared for GLM-5.3-Flash (gonka-vllm-plugins PR 12). The validator now judges a disagreement by the cell the prover claimed rather than by its own gap. An attempt with an invalid value is dropped from the sample instead of aborting the whole check (gonka-vllm-plugins PR 16 and gonka-vllm-plugins PR 17). The documentation now lists GLM-5.3-Flash as an active PoC model (gonka-docs PR 1467).

Security and proxy. Closed: issue 1572, about the training control API on GPU workers being reachable without authentication. Also closed: issue 1695, where proxy rate limits could not be tuned for trusted clients that are not network participants themselves.

Governance

No. Proposal Outcome
106 Marketing Committee — Operations Reddit Contributor Pilot Rejected
107 Gonka at HSC Asset Management Singapore, 8 October 2026 Rejected
108 Update DevShard v5 to v5.0.2 Passed
No. Yes No Abstain
106 26,026 107,375 248,932
107 0 349,017 40,556
108 366,276 0 0

Proposal № 106 (deadline September 23, 19:09 UTC) is the Marketing Committee's request for funds from the Community Pool: for the committee's ongoing work and for a separate Reddit contributor pilot.

Proposal № 107 (deadline September 25, 13:20 UTC) asks for funds from the Community Pool for a fireside chat on AI with Gonka's founders at the HSC Asset Management conference in Singapore.

Proposal № 108 (deadline September 27, 00:03 UTC) updates DevShard v5 to v5.0.2. Each running DevShard version opened a Postgres pool sized to the host's CPU count. Several versions on a multicore host used up every connection, and the node failed. v5.0.2 caps the pools at the session limit. Versions v3 and v4 are removed, and v4.1 stays unchanged. According to the announcement, hosts do not need to do anything: the versiond service picks up the new binary and verifies its checksum. The proposal is documented (gonka-docs PR 1471).

What's next

The pull request for the v0.2.16 upgrade is open for review. Meaningful comments, bug findings and security issues may be eligible for community bounties in the next upgrade cycle; details are in the network announcements. The upgrade includes trusted weight, dynamic coefficients, fee groups and PoC Challenge. Coefficient ranges stay closed at upgrade, so coefficients and rewards will not move until governance opens them. The DevShard v6 branch has to inherit the fixes of the v4.1.1 line before it ships.

Further reading