How verification works

OGONG rests on one fact: checking an answer is far cheaper than producing it. Call the ratio ρ (rho): the cost of verifying divided by the cost of generating. On datacenter GPUs ρ ≈ a few percent (2.5-3.7% measured, tens of times cheaper, about 30-40x); even on Apple Silicon, the weakest targeted backend, it’s ≈ 5% (about 20x cheaper).

That number is the whole game. If verifying is cheap, the network can check nearly every answer, and once almost everything is checked, you no longer need providers to post a big slashable deposit to keep them honest. Cheap full-coverage checking replaces the bond.

The reason verification is this cheap is that the checker never re-generates the answer. It teacher-forces a single forward pass over the prompt plus the claimed output and reads the model’s internal numbers off that one pass. Generation is autoregressive: one slow step per token. A teacher-forced prefill does the whole sequence in one batched pass, and that is where the ~30-40x comes from.

The commitment: proving what you did

When a provider answers a request, it generates in fixed windows of 32 tokens and emits a small leaf per window. The leaves form a Merkle tree whose root is the commit_root. Each leaf binds two complementary fingerprints of how the output was produced:

• Hidden-state sketch. A commitment over the model’s per-token last hidden states (the input to the language-model head), captured as a sign-random-projection (SRP) sketch: the hidden states are projected onto a bank of random ±1 directions. The directions are seeded by a per-request projection key that the validator derives from the request id (not the provider’s to choose, and not known until the request is in flight), so a substitute model cannot hide in a hand-picked corner of the activation space and a provider cannot precompute its sketch. The provider and verifier derive the same key from the signed request, so they project onto identical directions; on the Verified tier this per-request key is mandatory, with a fixed public seed kept only as a legacy whole-model fallback. Every direction mixes all coordinates, so the comparison is well-conditioned. This is the sharper of the two checks.
• Logprob digest. The top-k log-probabilities at every decode position in the window. Committing all positions is strictly stronger than sampling a few.

The provider signs a per-reply record. The signed payload binds the request, the response, and the model identity together:

record = ( reply_id, req_hash, resp_hash, model_root, commit_root, n_tokens, t0, t1 )
sig     = Ed25519(record) ‖ ML-DSA-44(record)

The signature is hybrid post-quantum: a classical Ed25519 signature and an ML-DSA-44 (lattice) signature, so the record stays valid even if one scheme is later broken. model_root is a SHA-256 over the model’s ordered shard content hashes, which implicitly binds the quantization, since the quant format is part of the bytes being hashed. The record is pushed to the handling validator at end-of-stream (a few hundred bytes), so the commitment is anchored even if the provider later goes offline. A provider that cannot produce its openings simply fails the audit.

The audit: re-checking without re-generating

A provider that serves a cheaper model in place of the one it promised is wearing a disguise. The network’s auditors, the Golden Eyes (named for the fiery gaze that sees through any transformation), are what catch it.

A validator decides whether to audit a given reply using a coverage rate α (alpha), drawn from a verifiable random function (VRF) over the reply id. --alpha 1 audits every reply, and the design target is full coverage. Because the draw is unpredictable and an audit may run any time within the reply’s audit window, a provider cannot tell which replies are checked, so it cannot serve the real model only when it thinks it’s being watched.

Consumers can raise their own coverage. α is a network-wide floor a consumer can override upward: a request may carry a verify flag — always, or at a probability the consumer picks — that forces its own audit. If you value certainty over the last few milliseconds of latency, you buy a guaranteed check on your request rather than trusting the sampled rate.

The randomness is a committee threshold-BLS beacon, not one node’s coin flip. The validators share a single BLS key, set up by a dealerless distributed key generation (DKG) so no one ever holds the whole key, and each epoch’s beacon is the unique threshold signature over that epoch. Because a BLS threshold signature is the same no matter which validators combine their shares, no coalition can predict, grind, or steer the draw, and a validator cannot move it by withholding (the remaining shares reconstruct the identical value). Anyone can verify the beacon against the group public key. It is a drand-style construction, and it is what closes the “watch, then decide” attack. (A per-validator VRF aggregate remains as a bootstrap fallback until the committee key is established.)

For a selected reply the validator assigns two independent verifiers (a cross-check), and the selection is model-aware: each is drawn from the other providers already serving the same model_root, because only a peer running the same model can teacher-force it, and the two are picked from disjoint slices of the audit seed so neither can predict the other. Each verifier:

1. fetches the original request and the claimed output,
2. runs one teacher-forced prefill of (prompt + claimed output), with no re-generation,
3. recomputes both fingerprints and scores the drift against the commitment,
4. returns Accept or Reject.

The reply is Accepted only if both verifiers agree; any disagreement forces a reject. (The network falls back to a single verifier only when the eligible pool has one member.)

Two checks, spanning the spectrum of cheating:

An honest re-run scores essentially zero on both. A substituted model scores ~1.1 on the hidden-state check: an order-of-magnitude margin, decisive on a single reply. The two checks are complementary. The hidden-state sketch rejects size swaps and aggressive quantization; the logprob check covers the near-lossless band a sketch might wave through. Matching the output distribution (distillation) does not help an impostor: it would still have to reproduce the reference model’s internal activations, a strictly harder target.

Only a doubly-confirmed Accept is allowed to settle. Each verifier re-runs on its own engine instance; co-locating one with the provider is just a demo convenience, and soundness comes from the re-execution being independent. Because a lazy or colluding verifier cannot rubber-stamp a reply the honest second verifier would reject, the two-verifier agreement is the primary defense; it also means honeypot indistinguishability is no longer load-bearing. Verifiers are paid a flat fee per audit regardless of verdict, so they’re neutral on the outcome, and the validator still periodically slips in honeypot audits with a known correct verdict as a complementary check. Two kinds, catching the two ways a verifier can cheat: a known-bad output that an honest verifier must reject (a verifier that rubber-stamps it is a lazy accepter), and a known-good output that an honest verifier must accept (a verifier that flags it is a false-accuser trying to get honest providers slashed). Disagreeing with a honeypot’s known verdict in either direction gets the verifier slashed and ejected at once.

Setting the tolerance: the network calibrates itself

The audit rejects when the scored drift exceeds a tolerance. That tolerance is not a hand-set constant. It is a measured property of (model, hardware): an honest re-run on a different GPU lands a tiny distance from the commitment, and the tolerance has to clear that honest distance while still rejecting a substitute. On a permissionless network, where anyone can bring a model the engine supports, it cannot be pre-measured for every one. So the validator self-calibrates it.

Each accept tolerance is derived from the honest drift distribution the validator already observes while auditing, per model and per metric (the hidden-state sketch, the logprob distances, and the diffusion single-step re-check alike). A new model serves at a conservative ceiling, accrues honest re-checks, and its tolerance tightens toward that model’s real cross-hardware tail. A low-drift model ends up checked more strictly; a model whose honest hardware genuinely spreads wider is accommodated, up to the ceiling. Three properties keep this sound:

• Never looser than the ceiling. The derived value is clamped to the conservative bound, which is governed on-chain alongside the other reject thresholds, so self-calibration can only ever make verification tighter, never weaker.
• Only honest data counts. The distribution is built from accepted re-checks only, already below the threshold, so a caught cheat never enters it.
• Distinct providers required. A tolerance tightens only once enough distinct providers (distinct GPUs, by the proof-of-distinct-GPU below) have contributed, so no single operator can move it.

Validators gossip their distributions and merge them, so the whole set converges on one tolerance per model rather than each node calibrating from its own slice of traffic. The cross-hardware drift a model actually exhibits is the seed; the network grows the threshold from there.

Settlement: money follows the check

Verification gates payment, and the validator never runs the model itself; it only adjudicates the verifier’s scores. Before applying any threshold it checks Merkle inclusion of the scored windows against the signed commit_root, so a score computed against material the provider never committed is rejected as tampered.

1. The consumer’s fee sits in on-chain escrow.
2. The handling validator, having adjudicated Accept, gathers co-signatures from a quorum of registered validators (a stake-weighted supermajority, more than two-thirds of validator stake). Each co-signer binds not just the amount and payout but the specific consumer escrow being debited — it re-derives that escrow from the consumer it metered for the reply and refuses to sign a settle that would charge anyone else.
3. With the quorum’s co-signatures it submits the on-chain settle.
4. Escrow releases and the parties are paid.

A reply that fails its audit never settles: its fee is withheld and refunded to the consumer (the wronged party), not paid to whoever caught the cheat, so no one profits from a reject and there’s no incentive to fabricate one. A reply without a validator quorum never settles either. Correctness and consensus both have to hold.

Challenge escrow: disputing a reply after the fact

Baseline sampling catches cheating cheaply, but anyone who suspects a specific reply slipped through can escalate it directly. A challenger stakes a bounty to open a dispute against a reply; a stake-weighted validator quorum resolves it, refunding the bounty if the challenge is upheld or forfeiting it to the treasury if not — so a frivolous challenge costs the challenger and a real catch does not. Each resolution is quorum-signed over a digest that binds a per-dispute round counter, so the signatures that resolved one round can never be replayed onto a later re-opened dispute for the same reply. This is the escalation rung above the routine audit: cheap sampling for the common case, a funded challenge for anything a party wants to contest.

The sequential audit: one strike is rarely the whole story

Individual verdicts feed a sequential probability ratio test (SPRT) per provider. An honest provider’s occasional cross-hardware noise won’t eject it; the lifetime false-ejection rate is held below a target β (the Ville bound, ~0.1%). A provider that cheats persistently crosses the threshold and is ejected in a number of audits that grows only logarithmically in 1/β. In the measured hidden-state regime the margin is so wide that a single audited reject is already conclusive.

Sybil resistance: proving a distinct GPU

On the Confidential tier the hardware attests itself. On the Verified tier there is no enclave, so a single operator could try to register many identities on one machine, then have them audit each other and rubber-stamp their own work. The defense is a timed proof-of-distinct-GPU: the validator periodically sends each Verified provider a fresh synthetic prompt and requires a committed reply on its loaded model within a wall-clock deadline (by default a short 16-token completion answered within 20 seconds, calibrated per GPU class). A faker with no real GPU, or an operator spreading too little compute across too many identities, cannot serve the forward pass in time and misses the deadline.

Misses feed a per-provider miss-rate SPRT, the same sequential test used for audit verdicts. A sustained elevated miss rate ejects the identity, and because the test scores the rate rather than a consecutive run, an operator cannot dodge it by interleaving the occasional pass. Crucially, the challenge reply is a real committed inference, so it doubles as an ordinary correctness audit: the anti-Sybil work is productive verification, not burned compute. The number of distinct identities an operator can sustain is therefore capped by its actual throughput, not by capital.

Identities also have to earn their place. A freshly registered provider starts at a low routing-weight floor (about 10%) and only ramps to full weight after it has accrued enough clean history: on the order of 16 audited accepts and 16 passed GPU challenges. Until then its replies are force-audited at full coverage. That makes the register, cheat the un-audited fraction, get ejected, and re-register cycle unprofitable, since a recycled identity earns little volume until it has proven itself again.

Why there is no correctness bond

Most pay-for-work networks make the worker post a slashable bond: catch them cheating and you burn it. The bond exists for one reason, catching the cheat is expensive. If you can only afford to re-check one request in a thousand, a cheater is caught about once in a thousand tries, so the punishment has to be a thousand times the per-request gain, far more than a single fee. The bond is just the multiplier that compensates for rarely looking.

A bond, in other words, is a tax you pay for not being able to check the work, and OGONG removes the reason for it. Because verification is cheap enough to cover nearly every request, a cheat is caught essentially every time, so the deterrent can be the one thing already on the table: the escrowed fee for the cheated request. Since any working market prices a request above the compute saved by cheating, forfeiting that single fee already outweighs the cheat. Honesty wins with no bond and no reputation stake required. (The result is machine-checked in Z3 and Lean, and cross-checked as a game in PRISM-games.)

So staking on OGONG buys routing priority and availability, more stake means more routed work and earnings, not a deposit you lose for a wrong answer; on-chain, a slash against provider stake is rejected outright. The only slashable bond the system keeps is the validator’s, posted against issuing false verdicts (a different role). Sybil resistance costs no capital either: the proof that an identity is a distinct physical GPU is its verification duty, so the anti-Sybil work is the audit, not burned collateral. See Tokenomics.