The week of June 22–28, 2026 was light on merged code and heavy on a network-level change. Fifteen pull requests merged across two active repos (gonka and gonka-docs), and 14 tracked issues closed. The headline did not arrive as a code PR at all: governance proposal 78 passed and swapped the AI model the whole network runs. Underneath that, two correctness fixes landed in the chain — one closing a rewards-sampling exploit, one stopping duplicate bridge mints.

A new model: proposal 78 and MiniMax-M2.7

Until this week, Gonka ran a single network model, Qwen3-235B-A22B. Governance proposal 78 changed that. It passed on June 25, 2026 and took effect from epoch 308.

  • MiniMaxAI/MiniMax-M2.7 is now the sole active Proof of Compute (PoC) model and the base model (initial_model_id). Proof of Compute is the mechanism where hosts prove they ran real inference rather than a hash puzzle, so the model they run is the model the network checks them against.
  • Qwen3-235B-A22B-Instruct-2507-FP8 and moonshotai/Kimi-K2.6 were removed from the PoC parameters and deleted from the governance model list.
  • The documentation caught up across 18 files in PR #1258, replacing Qwen with MiniMax-M2.7 everywhere it was shown as the active or default model.
  • PR #1259 published the bilingual (EN/ZH) announcement, including the host actions operators must take to serve the new weights.

In plain terms: the network swapped the AI model it runs. Hosts have to pull and serve MiniMax-M2.7 to keep validating from epoch 308 onward. The change was expedited as a fast re-bootstrap, so the migration window is short.

Rewards and consensus correctness

Two chain fixes in the gonka repo tightened how validators are checked and paid.

  • Issue #1254 replaced the block-hash-seeded RNG with the signed msg.Seed for reservoir sampling in getMustBeValidatedInferences. The block hash changes every block, which let a validator re-submit ClaimRewards across different blocks until a lucky sample under-counted its missed validations and the statistical test passed. That is retry grinding. Because msg.Seed is signed by the validator and verified against the stored SeedSignature, it cannot change between retries, so the sample is identical every time and the grinding path closes.
  • Issue #927, a P1, added a maintenance window for hosts. Operators can now schedule planned downtime without accumulating liveness penalties or risking jail.
  • PR #1307 repaired the admin setup report. The GET /admin/v1/setup/report endpoint returned permissions_granted as UNAVAILABLE on a populated chain, because its permission check queried the entire authz grant store and ran past the node's query-gas-limit. The fix queries grants per cold-to-warm key pair instead, a 13-line change in one file.

Bridge accounting

Issue #1249 fixed a bridge accounting bug where one Ethereum deposit could mint or release tokens more than once. Validators submitting the same L1 event with different string forms — different hex casing on ReceiptsRoot, or leading zeros in BlockNumber, ReceiptIndex, or Amount — produced multiple independent BridgeTransaction records. Vote aggregation keyed off the raw strings, and completion was guarded per record rather than per logical deposit. The fix canonicalizes the deposit keys and adds a global completion dedup, so one deposit results in exactly one mint or escrow release.

Security disclosure and onboarding

  • PR #1253 added a standalone /report-vulnerability/ page embedding the HackerOne submission form, so researchers can file security reports from the docs site. PR #1257 wired it into navigation and PR #1254 reworded it to a network-focused tone.
  • Broker and gateway access moved on both the docs and issue sides. PR #1250 added a new broker; PR #1249 added a gonka-api.org demo and synced the ZH broker links. On the issue tracker, broker requests (#1262, #1245, #1247) and gateway allowlist requests (#1321, #1342, #1229) closed, along with self-serve API-key questions (#1319, #1331) from hosts who want to spend their own GNK directly.

Build pipeline

  • PR #1362 kept upgrade archives AMD64-only, removing the multi-arch archive loop and the ARM-only workflow setup (6 additions, 29 deletions across 6 files) while leaving the local Docker build plumbing intact.
  • A testnet-only workflow (PR #1361) builds just the amd64 Linux path, pulling release build time from 60-plus minutes back toward the previous 10–13.

By the numbers

Repo PRs Notable issues
gonka 2 #1254, #1249, #927, #1307
gonka-docs 13 proposal 78 rollout (#1258, #1259)
Total 15 14 issues closed

Coming up

The immediate work is operational: hosts still running Qwen3-235B or Kimi K2.6 must migrate to MiniMax-M2.7 to keep validating past epoch 308, and the next few days should bring operator reports as that re-bootstrap settles. The HackerOne disclosure channel is live but deliberately kept out of the main navigation for now, so expect a follow-up once the intake flow is confirmed.