Ask when anything happens on Gonka and the answer is "at the epoch boundary." Validator power updates? Epoch boundary. Payment settlement? Epoch boundary. Reward unlocks, price updates, model assignments, collateral penalties? Epoch boundary, all of them. The epoch is the network's unit of time, trust and money, and once you can read where the current epoch stands, the whole chain becomes legible.

This post walks the full lifecycle — what triggers each phase, what happens on chain and off, and how to follow along from the Epoch tile on GNKScan's home page.

What an epoch actually is

An epoch is a span of blocks with a fixed internal schedule. Specific heights within it trigger phase transitions, tracked on chain by an epoch context that both the blockchain module and every participant's API node watch. Because the schedule is defined in block heights, every participant sees each transition at exactly the same moment — there is no coordinator handing out assignments.

Conceptually, each epoch answers three questions in order:

1. Who has compute? (proof-of-compute generation)
2. Are they telling the truth? (validation)
3. Then let them work and get paid. (the long middle, plus settlement at the boundary)

In production configurations, reward vesting is typically set to 180 epochs and described as roughly 180 days — the practical rhythm to keep in mind is an epoch on the order of a day.

Phase by phase

1. The epoch opens: a new epoch group

At the proof-of-compute start height, the chain creates a fresh epoch group — the on-chain record of who participates this round and with what weight — and prunes data from expired rounds. Meanwhile every API node fires a start event to its ML nodes, seeded with a block-derived random value. The seed is why nobody can precompute proofs: the task does not exist until the block that defines it does.

2. The Sprint: generating proofs

For the generation window, every participant's GPUs run the transformer-based proof task — searching for nonces whose model outputs meet a distance target, batching results, and streaming them on chain as proof-of-compute batch messages. The mechanics get a full treatment in How Gonka's Proof of Compute Works; for epoch purposes, the point is that this window is the network's census. Whatever compute shows up here, verified, is the compute that counts for the entire next epoch.

3. Validation: the network audits itself

At the validation start height, participants switch roles from contestant to auditor. Each one samples other participants' submitted batches deterministically, re-generates the sampled proofs on its own ML nodes, and posts validation verdicts back on chain. Acceptance is majority-by-weight: a submission stands when more than half of the network's compute weight vouches for it.

4. The turn of the epoch: weights, validators, settlement

The validation end height is the busiest moment on the chain. In quick succession:

• New weights are computed from accepted proofs (ComputeNewWeights on chain).
• The validator set updates — SetComputeValidators hands CometBFT a fresh power table, so block production and governance weight now reflect the new census.
• The previous epoch settles. Participants are paid their work coins (escrowed user fees) and their proportional share of newly minted reward coins, as described in our tokenomics guide.
• Vesting ticks. Each participant's oldest vesting tranche unlocks to spendable balance.
• Models are assigned to participants for the incoming epoch, and the active participant set is registered.

One block later, it is an ordinary epoch again.

5. The long middle: inference service

Most of an epoch is not ceremony — it is work. User requests hit participants' API nodes, fees go to escrow, ML nodes generate completions, and finish-inference messages settle the actual cost on chain. Work is allocated in proportion to epoch-group weight, so the census from phase 2 directly determines who earns what. You can watch this traffic dominate the transaction feed between boundaries.

Inference validation scales with volume

Proof batches are not the only thing the network cross-checks — inference itself is validated too, and the whitepaper defines how often based on each participant's request volume per epoch:

• High volume (at or above 10,000 requests per day/epoch): validation runs at the minimum sampling rate — with that many requests, statistical sampling catches misbehavior cheaply.
• Low volume (100 or fewer): every single task is validated, because a small sample of a small volume proves nothing.
• In between: the validation frequency adjusts linearly between those endpoints.

To smooth out traffic spikes, the volume figure used is the greater of the previous epoch's total and the current one — a participant cannot dodge scrutiny by alternating quiet and busy epochs.

Epoch groups and the two kinds of weight

The epoch group created in phase 1 is more than a participant list: it is the ledger of internal network power for the round — the weight used for validating peers' proofs, allocating inference work, and assigning models. Consensus power in the staking module is a separate table, updated from epoch-group results only at the boundary. During an epoch the two can diverge legitimately; the synchronization points are exactly the phase transitions above. If two dashboards show different "weight" for the same participant, check which system each is reading.

Continuity between rounds

Epochs are not memoryless. Participants from the previous epoch with inference allocation are preserved into the next round's bookkeeping, top miners are registered from proof-of-compute performance, and the epoch store keeps current, upcoming and previous epochs addressable — by sequential index and by proof-start block height — so settlement always closes out the round that just ended, cleanly, one block after its successor takes over.

Following epochs on GNKScan

• The Epoch tile on the home page shows the current epoch number, its phase, and progress through the phase.
• Inferences (Epoch) on the same console counts the current round's inference volume, with a delta against the previous epoch.
• Epoch boundaries are visible in the transaction feed as bursts of proof batches, validation messages and reward claims.
• The participants list reflects the most recent completed census; analytics shows the longer arc across many epochs.

The epoch clock is also the right mental model for reading odd-looking data. A participant with zero inferences mid-epoch may simply have missed this round's census; a spike of transactions at a fixed interval is settlement, not an anomaly. When in doubt, check the phase first — on Gonka, when explains most of what. For the bigger picture of what all this machinery is for, start with What Is Gonka?