How it works
How verification works.
Most inference networks ask you to trust the operator. You send a prompt, you get an answer, and you take it on faith that the model you paid for is the model that ran. Orogen works the other way around. Each job comes back with a signed receipt, the network re-runs a sample of jobs to catch anyone cutting corners, and the chain keeps a record so a disputed result has something to arbitrate against. This page walks through the full path from the request you send to the payment an operator receives, in plain language first and full mechanism second.
The loop
The loop between you, the network, and the chain.
Verification is a loop between three parties, and once you see the shape of it, every layer below fits into place. You send a request and get back an answer along with a signed receipt. The receipt binds four things together: the exact model, your input, the output, and a hardware attestation that names which GPU ran the job and confirms it ran in a protected mode. You can check that receipt yourself in a single call. The network then re-runs a sample of completed jobs on identical hardware and compares the result, and if the replayed output does not match the receipt, that opens a challenge. Underneath both, the chain stores the receipt commitment, which is the record both sides point to when a result is disputed and the ledger that settlement is written against.
- You send a request and get back an answer plus a signed receipt that you can verify locally.
- The network re-runs a sample of completed jobs on identical hardware and compares the result. A mismatch opens a challenge.
- The chain stores the receipt commitment, the record both sides point to when a result is disputed and the ledger settlement is written against.
The receipt
What you can check yourself.
The receipt is the part you hold. Every response carries the model hash, the adapter hash, a hash of your prompt, a hash of the output, the operator's identity key, the hardware attestation quote, and a timestamp, all signed by the operator. Your SDK verifies the signature locally, so you can confirm the response came from the operator the network routed you to and that the model and adapter were the exact weights you asked for. Weights are content-addressed, which means each model has a public root hash you can match against the one named in your receipt. If an operator quietly swapped in a smaller model or a cheaper quantization, the hash will not match and you will know.
Attestation
Proving which hardware ran the job.
A signature tells you who signed, and attestation tells you what they signed on. Before an operator can serve traffic, the hardware proves itself to the chain.
- Operators boot into confidential compute mode: NVIDIA confidential computing on the GPU (H100, H200, B200) and Intel TDX or AMD SEV-SNP on the host, both producing attestation quotes at boot.
- The chain verifies the full attestation chain against the vendor roots (NVIDIA NVTrust for the GPU, Intel Trust Authority or AMD KDS for the host) and binds it to the operator's identity and GPU device certificate.
- Operators re-attest every seven days and on any firmware or driver update. A stale attestation routes to zero traffic until it is refreshed. Running more than one hardware vendor is deliberate, so the network does not depend on a single supplier's security model.
Replay sampling
The network checks the work.
Attestation covers the hardware, and replay covers the answer. Validators pull a sample of finished jobs, between one and five percent, and re-run them on hardware identical to the operator's. If the replayed output matches the receipt, the job stands, and if it does not, the mismatch opens a challenge. Validators hold ten times the minimum operator stake and are themselves attested, so the parties checking the work have more at stake than the parties doing it.
- Replay only works if the same prompt produces the same output bit for bit, and standard inference kernels do not guarantee that. Floating-point GEMM on modern GPUs can return slightly different numbers depending on batch size and the number of streaming multiprocessors in play.
- Orogen workers run deterministic kernels that fix the reduction order and the tile scheduler, so a validator with the same model and the same prompt reproduces the same result exactly. The throughput cost is roughly three to eight percent against stock kernels on H100, measured on Llama-3.1-70B.
- Edge and embedding-only tiers run on hardware where deterministic kernels are not practical, such as Apple Silicon and CPU. Those tiers fall back to stake-backed verification, a weaker posture in exchange for lower pricing, and the receipt always states which posture applied.
Challenges
Settling a disputed job.
When a replay turns up a mismatch, the job enters a challenge window that stays open for 24 hours. Independent watchers re-execute the disputed job and post their own commitments. Where two parties disagree, a bisection game narrows the dispute step by step until it isolates the exact layer of the computation where the results diverged, so the panel rules on a single pinpointed difference. The chain's dispute panel then renders a slashing decision against whichever side was wrong. This is the opML approach, and it means a fault comes down to re-execution that anyone can run and a divergence that anyone can locate, rather than one party's word against another's. For a small set of high-stakes small-model and embedding workloads where the cost is justified, the protocol also offers full zkML proofs as a premium tier, where the operator proves the computation cryptographically instead of leaving it open to challenge.
On-chain receipt
The record that outlasts the request.
Every finalized job writes its receipt commitment to the chain, and that commitment is what makes the rest of the loop enforceable. A validator that finds a mismatch has a fixed reference to challenge against, a watcher has a canonical job to re-execute, and you have a permanent record of what you were promised that does not depend on the operator keeping their logs. You never have to rely on Orogen's account of what happened, because the chain holds the receipt and the receipt is the source of truth.
Settlement
Paying for verified work in dollars.
Verification decides whether a job counts, and settlement decides what it pays. Orogen settles through burn-and-mint, which ties new token issuance directly to real inference revenue rather than to a fixed inflation schedule. Akash made a similar move when its burn-and-mint redesign shifted from a 13 to 15 percent inflationary regime toward revenue-linked issuance.
- You top up the gateway in stablecoins or another supported asset, quoted at the oracle price at the time. To settle the job, the gateway burns OROG at the oracle spot price, and that burn mints you a USD-pegged compute credit that the job consumes on completion.
- When the job finalizes and the sample confirms it, fresh OROG is minted to the operator at the oracle spot price, split 75 percent to the provider, 15 percent to verification, 5 percent to treasury, and 5 percent to governance.
- The operator's payout is denominated against the dollar, and most of it auto-swaps to a stablecoin by default. The operator is paid in USD-equivalent value for completed, verified work rather than in exposure to a token price.
- Because the burn at top-up and the mint at payout happen at different prices, issuance moves with demand. New OROG is minted only against work the network verified, so supply tracks revenue, with no foundation mint discretion and no halving schedule.
BME loop · price-anchored
Oracle feed → burn → execute → verify → bounded mint
pallet-bme · pallet-oracle
-
01
Customer → gateway
Top-up in USDC / USD / ETH / BTC. Oracle-quoted at receipt; payment recorded.
-
02 · burn
Gateway burns OROG
OROG bought from protocol AMM or open market at oracle spot; pallet-bme retires the supply.
-
03
CUC mint (USD-pegged, 30d)
Non-transferable compute credit issued to the customer account, routable per job.
-
04 · execute
Router → operator (vLLM / SGLang / TRT-LLM)
Operator runs under TEE attestation with a deterministic kernel; signed receipt returned.
-
05 · verify
Validator replay sampling (1–5 %)
Bit-identical re-execution on attested hardware. Mismatch → opML challenge window.
-
06 · finalise
on_job_finalised fires
CUC is consumed (burned). Pallet-bme computes the bounded mint for this epoch.
-
07 · mint
Fresh OROG minted at oracle spot
Mint quantity passes the floor / ceiling envelope below, then splits four ways.
Pallet rule · epoch (~72 min)
mint = MIN( cap_year_N,
rolling_burn_90d × elasticity,
ceiling_5pct_supply )
mint = MAX( mint, floor_0_5pct_supply )
The chain rejects any mint above the computed bound, including any
foundation-side attempt to override. Elasticity is governance-bounded to
[0.8, 1.5].
Emission split · 75 / 15 / 5 / 5
Operator
Validators
Treasury
Governance
Why it composes
Verification that scales with what is at risk.
No single layer carries the whole load. Stake alone only asks you to trust an operator's collateral. zkML proves every token but costs orders of magnitude more than the inference itself. Orogen composes attestation, deterministic replay, opML challenges, on-chain receipts, and a stake floor underneath them, so the cost of verification scales with what is actually at risk on a given request. The result is open-model inference where the customer, the network, and the chain can each check the work independently, and none of them has to rely on the operator's word for it.