Gonka Participants vs Validators: How to Read the Active Set
Why GNKScan says participants instead of bonded validators, how epoch-active GPUs differ from registered addresses, and how to interpret weight and live GPU counts.
If you come from Cosmos or Ethereum staking, you look for "validators," bonded stake, and commission rates. Gonka reuses some of that vocabulary and then breaks the model: voting power is proven compute, not locked tokens. GNKScan therefore talks about participants, active sets, and live GPUs. This post is a decoder ring for those labels.
The short version
| Label | Meaning on Gonka / GNKScan |
|---|---|
| Registered participant | An address that has registered compute capacity at some point (cumulative, large) |
| Active participant | In the current epoch group — allowed to validate and earn for this epoch |
| Weight | Compute-derived voting / reward share for this epoch, not bonded GNK |
| Live GPUs | Hardware currently in INFERENCE status among the active set |
| Registered GPUs (active set) | All reported GPUs among active participants, including non-serving states |
| Chain-wide total GPUs | Sum across all registered hardware — includes junk and inactive hosts; not the fleet to quote |
Why not "validators"?
Gonka still has a Tendermint/CometBFT-style consensus layer and a validator set that signs blocks. That set is filled from proof-of-compute outcomes each epoch (SetComputeValidators in the whitepaper's language), not from a stake-weighted delegation market. Calling the UI "Validators" without context misleads people into looking for bonded amounts that do not drive power.
GNKScan's participants page (route kept for familiarity) lists the active set and weights. For the mechanism, see How Gonka's Proof of Compute Works.
Epoch boundaries rotate who counts
At proof-of-compute start, the chain builds a new epoch group. Only that group is "active" for the following validation and inference window. An address can be registered forever and still show zero live GPUs this epoch if it is not in the active set or its nodes are not in INFERENCE status.
That is why GNKScan scoped GPU aggregation to active-epoch members: summing INFERENCE GPUs across all registered addresses inflated the headline number by an order of magnitude (tens of thousands of ghost cards). Live figures should sit in the hundreds to low thousands in mid-2026 production, not ~64k.
How to read the home GPU tile
- GPUs Live — INFERENCE-status cards among active participants (serving work).
- Subtext may show compute nodes or participant counts from the gateway.
- Cross-check Inference for per-participant models and nodes.
If the number looks insane, check status and whether network stats are stale or degraded.
Weight vs stake
Weight is an outcome of verified compute in the epoch process. It feeds consensus power and reward share. It is not:
- liquid GNK balance on an address page,
- "self-bonded" stake in the Cosmos staking module sense,
- or a promise of future APY independent of serving inference.
Payments and reward coins settle at epoch boundaries; see epochs and tokenomics.
Practical checklist
- Use active participants when describing "who secures the network this epoch."
- Use registered only when you mean cumulative onboarding, and say so.
- Quote live GPUs from GNKScan's active-scoped metric, not raw chain-wide hardware totals.
- Open a participant on Inference before assuming their GPUs are serving.