Every Gonka epoch opens with a race. At a block height fixed by the epoch schedule, every participant's GPUs drop what they are doing and start generating proofs of computational power, seeded by the chain itself so nobody can precompute an advantage. The whitepaper calls this competition a Sprint. When it ends, the results — cross-checked by the rest of the network — decide two things at once: who validates blocks for the next epoch, and how much paid inference work each participant will receive.

This post traces that pipeline end to end, then covers the part most people miss: Gonka runs on two parallel power systems, and knowing which one you are looking at explains most of the confusing numbers on any Gonka dashboard, including ours.

Why proof of compute at all

Consensus needs a scarce resource. Proof-of-work burns energy on puzzles with no external value; proof-of-stake uses locked capital. Gonka's premise is that for a network whose product is AI computation, the natural scarce resource is the computation itself. If you can prove you control a certain amount of ML compute — and the rest of the network can verify it cheaply — that proof can back your vote.

The implementation lives in a modified Cosmos SDK. In stock Cosmos, voting power equals bonded tokens divided by a power-reduction constant. Gonka's fork sets that constant to one and feeds validator power directly from computational results via a function called SetComputeValidators. No tokens are bonded for consensus; the chain's total "bonded" figure is simply the sum of proven compute scores.

Stage 1: The Sprint begins

When the chain reaches the proof-of-compute start height, two things happen in parallel. On-chain, the epoch module creates a new epoch group and prunes stale data from previous rounds. Off-chain, each participant's decentralized API node detects the phase transition, generates a random seed from the block, and dispatches a start command to every ML node it manages — carrying the block hash, the participant's public key, and a callback URL for results.

Seeding the work from a fresh block hash matters: the task cannot be started early, and every participant gets the same starting conditions at the same moment.

Stage 2: Generating transformer-based proofs

Here is the part that separates Gonka from hash-based mining: the proof workload is built from the same kind of computation the network sells. ML nodes initialize transformer models with the seed and search for nonces whose model outputs land within a target distance — batching up nonces and distance calculations, and streaming these batches back to the API node, which wraps them in MsgSubmitPocBatch transactions and submits them on chain.

Because the proof task exercises the same hardware and software stack as inference, a participant cannot look strong in the Sprint while being useless at the actual job. Capacity claims are backed by the kind of compute that will later serve user requests. You can watch these batch submissions land in the transaction feed near the start of each epoch — they are labeled as proof-of-compute batch messages.

Stage 3: Everyone checks everyone

Claimed compute is worthless until verified, so the next phase flips every participant into auditor mode. Each API node queries the full set of submitted batches from the chain, applies deterministic sampling to pick which nonces to re-check, and switches its ML nodes into validation mode. The nodes re-generate proofs for the sampled nonces and compare results, producing fraud-detection statistics that go back on chain as MsgSubmitPocValidation messages.

Sampling is what keeps this affordable. Validators do not redo each other's entire Sprint; they re-run enough of a statistically chosen sample that systematic cheating gets caught.

Stage 4: Majority rules, weighted by compute

At the validation deadline, the chain computes the outcome in a function fittingly named ComputeNewWeights. The decision rule is majority-by-weight:

• A participant's submission is accepted when valid attestations arrive from more than half of the network's compute weight.
• It is rejected when invalid attestations exceed half of the weight, factoring in fraud-detection thresholds from the statistical analysis.

Note the recursion: this epoch's validation is weighted by compute standings that were themselves established by previous epochs' validated Sprints. Power in Gonka is always one epoch deep in provenance.

Stage 5: New validators, new epoch

Finally, accepted results flow into SetComputeValidators, which reconciles the new scores with the existing validator set and hands CometBFT an updated power table. Account settlement runs for the epoch that just ended — participants are paid, as described in our tokenomics guide — model assignments are made for the incoming epoch, and the cycle restarts.

The two power systems

Gonka tracks power in two places, and they answer different questions.

Staking-module power (consensus power) is what SetComputeValidators writes. It drives everything the underlying Cosmos machinery cares about: which validators produce blocks, how governance votes are weighted, how consensus-level misbehavior is penalized.

Epoch-group power (internal network power) lives in the inference module's epoch groups. It governs the working side of the network during an epoch: how much weight each participant carries when validating other participants' proofs, how inference requests are allocated, and which models each participant is assigned to serve.

The two are synchronized at epoch boundaries — successful participants' epoch-group results become the next staking-module power table — but during an epoch they can legitimately differ. When a participant's "weight" on one page doesn't match its consensus power on another, you are usually looking at one number from each system.

What this looks like on GNKScan

A few practical tips for watching proof of compute happen:

• The Epoch tile on the GNKScan home page shows the current epoch and its phase, so you can tell whether the network is mid-Sprint, validating, or in ordinary inference service.
• Bursts of proof-of-compute batch and validation messages in the transaction feed mark epoch boundaries.
• The participants page lists the active set with their weights — the output of the most recent completed cycle.
• Block production itself never pauses; blocks keep landing at /blocks through every phase, many of them empty during quiet stretches.

Why the design holds together

Three properties do the heavy lifting. The workload is useful-equivalent: proofs exercise the same transformer stack that serves customers, so capacity cannot be faked with special-purpose hardware that would be useless for inference. Verification is sampled and mutual: everyone audits everyone, at a cost far below re-execution. And the incentives are aligned across both power systems: the same proven compute that wins consensus power also wins paid work, so honest capacity is rewarded twice while getting caught costs you both.

For where the money goes after settlement — work coins, minted rewards, vesting and slashing — continue with Gonka Tokenomics. For the broader context of what the network is for, start at What Is Gonka?