For validators
Get paid to check the work.
A validator runs the same hardware as a datacenter operator, but instead of serving customer inference, you pull a sample of finished jobs and re-run them. When your replay output matches the operator's signed receipt, the job stands. When it disagrees, you raise a challenge. You earn from the verification slice in proportion to the replays you actually perform, so your pay tracks the work you do rather than the size of your wallet.
The role
Replay, not opinion.
Orogen validators do not vote on whether an answer is good. You re-execute the job and compare hashes. The replay is bit-exact when the operator runs in deterministic-kernel mode and you run the same model and adapter on equivalent hardware, so a mismatch is a fact you can point at rather than a judgment call. Your score comes from a physical replay event with a verifiable input and output pair, so there is no rubric to game and no subjective evaluation to dispute.
- Pull the receipt's committed tuple from the chain: model hash, adapter hash, prompt hash, output hash, attestation quote, and nonce.
- Fetch the matching weights from the content-addressed CDN and replay the job on identical hardware.
- An exact output-hash match finalizes the job. A mismatch opens a challenge window.
Sampling
How the sample is drawn.
Sampling is unpredictable on purpose, so an operator cannot tell which of their jobs will be checked. Each epoch, roughly every 72 minutes, the chain produces a VRF output that seeds a per-validator sampling schedule. Because the seed is unknown to operators ahead of time, there is no way to serve a clean answer only on the jobs that happen to be watched.
- Tier-weighted rates: 1 to 5 percent at the datacenter tiers, 5 to 10 percent at cloud-rented, and 10 percent or more at prosumer.
- Edge and embed-only tiers are stake-anchored. They are not sampled, but their stake is still at risk in a fraud dispute.
- The VRF seed binds your schedule for the epoch, so neither you nor the operator can steer which jobs land in the sample.
Challenges
What happens on a mismatch.
A single disagreement does not slash anyone on its own. It opens a challenge that other validators are invited to replay, and the protocol narrows the dispute to the exact point where the two executions diverged. When the opML challenge window opens, other validators re-run the same job, bisection isolates the divergent layer, and a dispute panel renders the verdict against whichever side was wrong. Consensus across many independent replays is the arbitrator, not any one validator's word.
Stake
What you stake.
Validators hold ten times the operator minimum for the tier they sample, which keeps the cost of a bad challenge higher than any payout it could earn. At current parameters that is 5,000 OROG to sample the premium datacenter tier, 1,000 OROG for standard datacenter, 500 OROG for cloud-rented, and 250 OROG for prosumer. Your stake is itself slashable for a missed challenge, for a false-positive challenge raised against a correct operator, and most severely for colluding with an operator you sample.
Pay
Pay follows replays, not presence.
The verification slice is 15 percent of each job's settlement, paid out per epoch in proportion to the replays you complete, with consensus alignment as a multiplier. If you hold stake but run no replays, you receive nothing from that slice, because the protocol pays for verifiable work rather than for showing up. For each replay you submit the job id, your replayed output hash, and a match-or-mismatch decision, and the chain scores you against the finalized outcome.
- Aligned decisions earn full weight for that replay.
- Repeated disagreement with the finalized outcome, the signature of false-positive challenges, decays your weight and shrinks your share of the slice.
- If cluster correlation suggests stake-weighted collusion, the dispute panel can promote any replay to an N-of-M re-execution by independent validators.
Slashing
The slashing math.
Slashed stake is burned at the chain level rather than handed to the challenger. That closes the door on the usual failure mode where challengers profit from raising false positives, so the result of a valid challenge is reputation and a share of the verification slice, never the loser's stake. Faults fall into three classes.
# Indicative slashing schedule (at-launch parameters)
# Soft fault (single sampling mismatch on a low-stakes request)
slash = min(stake * 0.005, 25 OROG)
reputation_decay = -50 points
# Hard fault (repeated mismatches OR opML challenge resolves against operator)
slash = min(stake * 0.10, full_stake)
reputation_decay = -500 points
# Severe fault (coldkey duplication, fraudulent attestation, signed-receipt forgery)
slash = full_stake
ban_duration = 90 days
governance_review = required (publish dispute panel verdict on-chain)Separation of duties
Two roles, kept apart.
The protocol separates validators from the watcher set so that the people doing the replays are not the same people rendering final verdicts on each other. Validators are stake-bonded, and the verification slice is allocated to replay work they actually perform. Validator-watchers are a smaller set that runs the opML challenge bisection and arbitrates the dispute panel, bonded with a much larger stake (50,000 OROG at current parameters) and rotated by governance, with their decisions appealable on-chain. A watcher can override a clearly incorrect validator consensus, which gives the system a backstop without letting validators police themselves.
Get started
Start replaying.
The Forge testnet is live. The OpenAI-compatible gateway, the public chain node, the CLI wallet, and the Python and TypeScript SDKs are all running today. Forge currently uses a small foundation validator set while the independent replay path is hardened. The replay-sampling specification (RFC-0006) is the formal reference, and the operator page covers the hardware and attestation side of the same setup.