Introduction

OGONG

Decentralized AI inference you don't have to trust. You can check it.

The idea in one paragraph

The world has far more capable GPUs than any one company runs. The reason inference still piles up inside a few big providers isn’t a shortage of compute. It’s trust. You can’t safely pay a stranger’s GPU for an answer you have no way to check. It could quietly swap in a cheaper model, hand back a stale cached reply, or just run the model badly, and you would never know.

OGONG removes that problem. Providers prove their work, independent validators re-check a sample of it, and payment stays in escrow until the check passes. Because checking an answer is tens of times cheaper than producing it (about 30-40x on datacenter GPUs), the network can verify nearly everything. So anyone’s GPU becomes safe to pay, and inference spreads back out.

Read next

CLI-first, no GUI required

Every role in OGONG runs headless from the command line, with no dependency on any hosted or branded stack, and no GUI to install. The command line is the real thing.

ogong-validatord   # validator / audit node
ogong-verifierd    # re-runs committed work to score an audit
ogong-routerd      # provider marketplace match engine
ogong-gatewayd     # OpenAI-compatible consumer endpoint
ogong-provider     # provider daemon, also a zero-signup local model server

Every piece above is real software you run from the command line. The sections that follow link straight into it.

What is OGONG

OGONG is a network where anyone can serve AI inference from their own GPU and get paid, and where the correctness of every answer is checked by the protocol instead of taken on faith.

The problem

There are far more capable GPUs in the world than any single company runs. So why does inference still concentrate inside a handful of big providers? Not because compute is scarce. It’s because trust is.

If you pay an anonymous machine for an answer, how do you know it actually ran the model you asked for? It could quietly swap in a cheaper, smaller model. It could hand back a stale cached reply. It could just run the model badly. You’d have no way to tell. That uncertainty is what forced inference to huddle inside a few operators you simply have to trust.

The fix

OGONG makes a stranger’s GPU safe to pay, using two ideas:

1. Cheap verification. Providers commit to their work (a compact fingerprint of how they produced the answer), and an independent verifier re-checks it by teacher-forcing a single pass over the answer, with no re-generation. Checking is far cheaper than generating (tens of times cheaper, about 30-40x on datacenter GPUs), so the network can verify nearly everything.
2. Hardware attestation (for privacy). A provider running inside a secure enclave (a TEE) can prove, with a hardware-signed certificate, exactly what code and model it’s running, and that the operator can’t even read your prompt.

Money rides on top of this: the consumer’s payment sits in escrow and is only released after the answer passes its check and a quorum of validators co-signs.

How an answer flows

consumer ──▶ gateway ──▶ router ──▶ provider (GPU + model)
                                        │  commits its work, signs a record
                                        ▼
                                   validator ──▶ audits a random sample
                                        │             (verifier re-runs it)
                                        ▼
                                   escrow ──▶ quorum co-signs ──▶ provider paid

• The provider serves the model and commits a checkable record of what it produced.
• A validator audits a random slice of that work and, on success, co-signs payment.
• The chain holds the escrow and only releases on a validator quorum.

See Network roles for what each piece does, and How verification works for the checking mechanics.

More than text

OGONG verifies far more than chat. The same commit-and-check mechanism covers every modality a provider can serve:

• Text and vision: chat completions, embeddings, and image-input (vision) prompts.
• Image generation: diffusion image models.
• Audio: music generation, text-to-speech (TTS), and speech-to-text (STT).
• Video: latent video diffusion.

The trick that makes text cheap to verify carries to all of them. For diffusion, audio, and video, the provider commits a trajectory (the sampled denoising steps) and the verifier re-runs a single step to check it, so a full audit stays a small fraction of generation cost no matter the modality. See Images, audio & video for how that check works.

Bigger than one GPU

A model too large for any single GPU is served by a cohort of providers, each running a slice of its layers, each slice independently verified and paid. It is the capability that the whole zero-bond design exists to make possible. See Split inference.

What OGONG is not

• Not a hosted product. OGONG is an open protocol and a set of CLI binaries you run. (A separate hosted service may use the network, but that’s a different product.)
• Not private by default. Privacy and verifiability are different things. Only the TEE tier hides your content from the operator; the Verified tier proves correctness on an ordinary GPU but the provider can still see what it serves. The docs are careful about this; see Trust tiers.

Trust tiers

Every model on OGONG carries a trust tier that tells you exactly what guarantee you’re getting. The tier describes how the work is served and checked, not which company made the model.

Two guarantees, plainly

The whitepaper draws the line at two things, and they are not the same:

• Privacy: can the machine operator read your prompt and the answer?
• Correctness: can you be sure the answer really came from the model you asked for?

These are two independent axes, and OGONG offers exactly two tiers, one for each way of pinning down correctness. There is no unverified, “just trust me” tier: all supply on the network is checked one way or the other.

Confidential (TEE): verifiably private

The provider runs inside a Trusted Execution Environment and produces a hardware-signed attestation (a DCAP quote on Intel TDX, with NVIDIA Confidential Computing for the GPU). The quote proves what code and model are running and gives you an encrypted channel into the enclave. The operator of the machine cannot read your prompt or the response.

• Trust root: hardware attestation, checked by you (or a validator on your behalf), and you must check it before you send anything, which is what turns “private” into verifiably private.
• Per-reply guarantee: the enclave signs a receipt over each response, so correctness is hardware-attested for the specific answer you got; settlement won’t release on a receipt that doesn’t verify.
• The honest caveat: confidentiality is only as strong as the TEE itself. A working enclave break on the host serving your request would defeat privacy, and attestation is only as current as the platform’s security version: a valid quote on revoked or out-of-date microcode is rejected. Note the asymmetry: under a compromised minority of enclaves, network correctness still holds (it rests on the audit and the honest validator majority); it’s privacy that degrades.
• Use it for: anything sensitive. Content never leaves the enclave in the clear.

Verified: correct, but the provider can see it

This is the public-compute tier, on any GPU and no special hardware. The provider commits to its work and two independent verifiers re-check it cheaply by teacher-forcing a single pass (see How verification works). If both re-checks agree, the work is accepted and paid. This proves the answer came from the claimed model.

• Trust root: a cryptographic commitment plus an independent statistical audit.
• What kind of guarantee: probabilistic, not cryptographic. Empirically the separation between honest and cheating work is wide (a substituted model misses by ~10x), but it’s a statistical bound calibrated per hardware pair, not a worst-case proof. Keeping the honest cross-hardware drift clear of near-lossless quantization fraud is the network’s central open calibration gate, so thresholds are set conservatively. For a hard, per-reply correctness claim today, the Confidential (TEE) tier is the stronger basis.
• Encrypted in transit, but the operator can read it. The request travels end-to-end encrypted to the GPU: a Verified provider advertises an X-Wing (hybrid post-quantum) key, the client seals to it, and only the provider decapsulates, so the router, gateway, and any relay in between see only ciphertext (and your identity is stripped at the router). What this does not hide is the content from the operator of the GPU running your job: that machine decrypts and processes the plaintext, so a dishonest operator could read it. Hiding content from the operator needs a TEE, so if that’s your threat model, use Confidential.

Why no “private on commodity hardware” tier?

Transit privacy you can have on any GPU (the X-Wing seal above keeps every relay in the dark). Privacy from the operator is the part you can’t have without a TEE: on an ordinary GPU the operator can always read what the card is processing. So the Verified tier gives correctness plus transit encryption, but only the Confidential tier hides content from the machine’s operator. OGONG is honest about this rather than blurring it.

Running your own GPU

Pointing a tool at a GPU you own is a different thing from picking a network tier: there’s no third party to attest or audit, because you already trust the machine. That’s local mode: a zero-signup, no-account server you run for yourself or a friend over an encrypted tunnel. It isn’t part of the marketplace’s tier system. See Local mode.

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.

Verifying images, audio, video & speech

OGONG verifies more than text. The same protocol covers image, audio, video, and text-to-speech models, but the check itself is different, because these models work differently from a chat model.

Why the text check doesn’t transfer

A language model produces a probability distribution over the next token at every step, and that distribution is a fingerprint of the exact computation that made it. The Verified-tier check (see How verification works) commits and cheaply re-derives those distributions.

A diffusion or flow model hands you nothing like that. It starts from noise and runs N denoising steps down to a final latent, then decodes that latent to pixels or audio. There is no per-token distribution and no position to teacher-force. The only natural thing to look at is the final output, and the output is exactly what a cheaper computation can forge. So the text defenses are not weak here; they simply do not apply.

Check the process, not the output

The insight is that an output is not evidence of the computation that produced it; a process is. A diffusion model’s computation is not a single result, it is a sequence of N steps, each one a forward pass of the same network the provider claims to run. That sequence is checkable in exactly the way a lone output is not.

So the provider commits a trajectory: a Merkle root over the latent at sampled denoising steps, plus the final latent. To verify, an auditor:

1. draws a step at random,
2. asks the provider to open the committed latents at that step (Merkle proofs checked first),
3. runs one reference denoising step from the committed input, and
4. accepts if the result matches the committed output within a tolerance.

One step re-run against the N the provider performed: cost ρ ≈ 1/N, the same cheap-check economics as text. Sampling k steps instead of one raises both the cost and the per-request catch rate.

The Merkle-inclusion check runs before the tolerance check, so a provider cannot serve one trajectory, commit another, and reveal whichever is convenient. The only way to pass is for every committed step to match the reference model’s step, which is to say, to actually run the model. A final check then decodes the committed last latent and confirms it matches the served bytes, so a provider cannot run the honest trajectory and hand back a different output.

Measured on four engines

The primitive is implemented and measured on four independent engines, with no shared code:

An honest re-run reproduces each checked step exactly; a substituted computation lands two to three orders of magnitude away.

Two more modalities reuse an existing check rather than a new one: audio-driven video (Wan2.2-S2V) commits the same denoising trajectory as video, and speech-to-text (Whisper) is autoregressive, so it is verified by the same per-position logprob commitment as text. Text-to-speech is the one that needed a new shape: it is not a denoising trajectory but a per-frame diffusion head, so the provider commits each frame’s inputs (conditioning plus noise) and its output latent, and the verifier re-runs one head step.

An honest caveat (and a happy one)

The accept tolerance is a measured quantity, not a proven constant. A different GPU or kernel reproduces a latent with a small nonzero drift, so the threshold is set from the honest cross-hardware drift, and the guarantee is that this drift stays clear of a cheat’s divergence. For diffusion that separation is comfortable: the honest drift is tiny and a cheat diverges by 0.27 to 1.0. That actually makes diffusion a cleaner verification target than text, where the near-lossless quantization band is the hard case.

One subtlety: guidance schemes that carry momentum across steps are not reproducible from a single committed latent alone inside the guidance window. Image and video (S2V) avoid it with a forced-Euler trajectory (every step self-contained). The audio DPM++ path — whose adaptive-projected-guidance interval is ~the middle half of the steps — now commits the per-step guidance momentum alongside each latent, so a verifier re-checks a band step by reproducing the guided update and confirming the momentum’s own recurrence. That closes the interval at the same cheap 1/N cost without downgrading the audio to Euler, and a band cheat is caught by a single random sample. Implemented and live-validated; enabled per model during rollout.

Split inference: models too big for one GPU

Some models are too large to fit on any single GPU a casual provider owns. OGONG serves them anyway, by splitting one model across a cohort of providers, each running a slice of its layers, with every slice independently verified and paid. This is verified split inference: decentralized inference of a frontier model across ordinary GPUs that no single machine could hold.

Why only a zero-bond network can do this

Sharding a model across machines is not new. Doing it across untrusted, unbonded machines is. In a design where each provider must post a slashable bond, sharding multiplies the capital barrier by the number of shards: ten segments, ten bonds. Casual nodes never clear that bar.

OGONG posts no correctness bond (see Why there is no correctness bond), so the barrier doesn’t multiply. A cohort of ordinary, unbonded GPUs can serve a frontier model, each segment paid only for the layers it ran.

How a cohort serves one model

1. A provider advertises a segment: the range of layers it can run.
2. The router assembles the cheapest cohort whose segments tile the whole model, end to end.
3. A lead drives the request through the cohort: the first shard runs from the prompt, each interior shard runs its layers from the previous shard’s output, and the result flows down the chain.
4. Each shard commits the hidden state at its layer boundary and signs it with its provider key. The commitments chain: one segment’s output is the next’s input.

So the model is computed in a relay, and the relay leaves a signed, checkable trail. It is architecture-agnostic because it rides the residual stream every decoder transformer exposes; the only per-model detail is the input embedding an interior shard skips.

Verified per segment

The same cheap audit that checks a whole model checks each segment. A validator re-runs a sampled segment and confirms its boundary reproduces:

• An honest re-run reproduces the boundary essentially exactly (on a 2B model: ~0% on the same engine, ~0.6% drift across backends), while a substituted sub-computation lands ~30% off, a roughly 50x separation, on the same calibration the whole-model check uses.
• Because each boundary is signed, a cheat is localized to the one provider that produced it, with no trusted lead. A caught segment withholds the whole request (the consumer is refunded) and ejects exactly that provider. An honest shard risks nothing.
• The deterrence holds per segment, and it is a formally proven, machine-checked result. A shard’s compute saving and its fee share both scale with the layers it runs, but the stake it puts at risk does not shrink with its slice. So a smaller shard is, if anything, more deterred, and sharding never weakens the honesty guarantee that protects a whole model.

End to end, a two-shard cohort in which each shard loads only its own layers reproduces the single-machine model’s output to a relative difference of about 1e-5.

Paid per slice, on-chain

Settlement is a single cohort settle: each shard is paid for its slice under a conservation invariant, the per-shard amounts must sum to the provider’s share, so a release can never exceed the request’s fee. A non-conserving split is rejected on-chain with no funds moved.

A topology, not a tier

Split inference is a serving topology, orthogonal to the trust tiers. It composes with both: a cohort’s guarantee follows the tier of its shards, a cohort of Verified shards is Verified, a cohort of Confidential shards is Confidential. See How verification works for the per-segment audit it builds on.

It composes the whole stack

Split inference is not a bolt-on. It is the capstone that falls out of everything else OGONG already does:

• the zero-bond result removes the per-shard capital barrier, so a cohort of casual nodes is even possible,
• cheap per-segment verification catches a lying shard for a fraction of its compute,
• signed boundary commitments localize a cheat to the one node that produced it,
• the router assembles the cohort and on-chain cohort settlement pays each shard its slice under a conservation invariant.

Each of those was built for serving a whole model on one machine. Put together, they let a crowd of ordinary GPUs serve a model none of them could run alone, which is why it’s a headline capability rather than a feature.

Tokenomics

OGONG is the network’s unit of account: consumers pay it for inference, and providers and validators earn it for serving and securing the network. Model makers are attributed on-chain, with a royalty slot reserved for them (inactive at launch, deferred to governance).

The principles

• Fixed supply. A hard cap of 5,000,000,000 OGONG, enforced as an on-chain invariant.
• Earned by work. The dominant 80% (4B) is never pre-allocated. It is emitted only for verified contribution (served inference plus passed liveness challenges) on an 8-year halving schedule, Bitcoin-style, open to anyone on the same permissionless terms. The period was stretched from four years to eight to keep early-year emission, and the inflation it implies, moderate. The curve is asymptotic: roughly four-fifths of the earned tranche emits within the first ~20 years, approaching but never quite reaching the cap.
• Initial supply. The remaining 1B (20%) is allocated at launch: 625M to core team & advisors, 250M to the Ogong foundation, and 125M to public liquidity.
• Stake is priority, not a bond. Staked OGONG buys routing priority and availability weighting. It is not a slashable correctness deposit. Cheap verification, not capital at risk, is what keeps answers honest. (See How verification works.)

How emission is earned

The earned tranche mints to the roles that produce and secure work, in proportion to what each verifiably contributes per epoch:

• providers for settled inference,
• validators and verifiers for audits performed,
• routers for routes served,

plus a liveness credit for answering a random availability challenge, which decays with the halving as a bootstrap. Each epoch the validators first agree one canonical work tally — a leader proposes the distribution and the others ratify it only if it matches their own within tolerance — and then co-sign the mint against that agreed distribution. So nothing mints without consensus, and honest validators that saw the epoch boundary slightly differently still converge instead of stalling.

A hard per-epoch ceiling backs this on-chain: the total minted across all recipients in an epoch can never exceed that epoch’s scheduled reward, and the running total can never exceed the anti-front-load cumulative schedule or the 5B cap. So no amount of fan-out — splitting a mint across many recipient addresses — can inflate an epoch’s emission beyond the halving curve.

Where the money goes per request

When a verified request settles, the escrowed fee is split on-chain across the parties that produced and secured the result: the provider that served it, the router, and the validator with a verification reserve. The model’s maker is attributed too, though the maker-royalty slot is reserved and currently inactive. A reply that fails its audit releases no fee at all.

A provider that is directly reachable (it serves the request over its own endpoint, not relayed through the router) pays no router cut — that share folds back into the provider’s residual. Only a NAT’d provider served through the router’s reverse-tunnel relay pays the router share, since the router did the work of carrying its traffic. The settle proves which case applies, so a provider cannot claim the direct rate while actually being relayed.

Why a deposit isn’t needed

In most pay-for-work networks an operator posts a large refundable bond so they have something to lose if they cheat. OGONG drives that to zero: because verification covers nearly every request, simply forfeiting the cheated request’s fee is deterrent enough. That frees stake to do what operators actually want, buy priority, instead of sitting idle as collateral.

A floor price keeps that deterrent honest: a request is not routed below a governance-set minimum, so fee competition can never shrink the fee-at-risk — and with it the cost of getting caught — toward zero. And a consumer who wants certainty over speed can force verification of its own request (every time, or at a probability it chooses) rather than rely on the network’s baseline audit sampling.

Network roles

OGONG is a small set of cooperating processes. Each is a standalone CLI binary; you can run one, several, or all of them. The three infrastructure roles (provider, validator, router) are permissionless, and a single operator may run any of them.

Provider

Serves models from a GPU and earns OGONG for verified work. The provider daemon is ogong-provider. It:

• runs an embedded inference engine (text, image, audio, STT, TTS) as a managed subprocess, or fronts an existing engine (llama-server, vLLM, Ollama),
• commits a verifiable record of each reply, signed with a hybrid post-quantum key (Ed25519 ‖ ML-DSA-44), and pushes it to a validator at end-of-stream,
• registers itself with the router marketplace and/or joins the on-chain network.

“Turning it on” is the whole onboarding step: a provider risks zero capital for correctness; there’s no bond to post. Optional stake buys routing priority (pure upside). A provider’s GPU also doubles as a verifier for peers serving the same model. It has several modes: a tunnel client for home contributors, a direct HTTPS server for TEE operators, and a zero-signup local server. See Provider node.

Validator

ogong-validatord, the security layer. It’s an attested CPU enclave with no GPU and no model weights; it never runs a forward pass. It:

• reads the on-chain registry to discover peer validators (no manual peer config needed),
• receives signed commitment records from providers,
• drives the threshold-BLS randomness beacon (a per-validator VRF is the bootstrap fallback) that audit-selects a sampled fraction of replies (audit rate --alpha) and assigns two independent verifiers (a cross-check; accept only if both agree),
• adjudicates the verifier’s scores against the committed commit_root (Merkle inclusion first, then thresholds),
• when it holds the settlement role, gathers peer co-signatures over QUIC and submits the on-chain quorum settle,
• posts the one slashable bond the system keeps, forfeit if it issues a false verdict.

See Validator node.

Verifier

ogong-verifierd, the audit muscle. A verifier is really a provider GPU acting in audit duty: when a validator audit-selects a reply, it VRF-picks two verifiers from the other providers serving the same model and dispatches the job to both. Each verifier teacher-forces a single pass over the claimed output, scores the drift against the commitment, and returns Accept / Reject; the reply is accepted only if both agree, so a colluding verifier cannot rubber-stamp what the honest second verifier rejects. It’s paid a flat fee per audit regardless of verdict, so it’s neutral on the outcome. See How verification works.

Router & gateway

The marketplace match layer:

• ogong-routerd, the match engine, an attested enclave on the request hot path. Providers register (Upsert); consumers query (Route) for a provider that can serve a given ogong/<tier>/<maker>/<model>, matched on price, tier, and free capacity, and drawn proportionally to stake × reputation. It runs verified routing code that can’t read the plaintext it relays, holds no consensus stake, and is slashable for misrouting.
• ogong-gatewayd, an OpenAI-compatible HTTP front door for consumers. It accepts a model request, matches via the router, and forwards to the selected provider. It can also act as a fiat on-ramp, paying the network in OGONG on a user’s behalf.

See Router & gateway.

Chain

The Solidity contracts under contracts/ (deployed on Robinhood Chain, an EVM Layer-2). They hold the staking pool, the validator registry, escrow, the quorum-gated settle function (a release needs k registered-validator co-signers, verified on-chain via ecrecover), and emission. Makers are attributed on-chain (their royalty slot is reserved but inactive). Inference never touches the chain; only consensus-critical metadata and a hash anchor of each commitment do.

Consumer

Any application and its users. The team’s hosted product is merely one consumer, with no privileged status. A consumer pays a per-request fee held in on-chain escrow, released to the provider only after the reply survives its audit window; on a reject, the consumer is the party refunded. Payment can be in OGONG directly, or via the gateway’s fiat path for zero crypto exposure.

Maker

Not a process but a role. A maker is the author of a model served on the network, identified in the model id ogong/<tier>/<maker>/<model> and recorded on-chain as a royalty payee. The protocol reserves a maker-royalty slot, but it is inactive at launch (deferred to governance, which has to settle who may legitimately claim a model). The fees that do settle go to the provider, router, validator, and a verification reserve. See Tokenomics.

Quickstart

This walks you from an empty machine to a live, end-to-end OGONG mesh running locally: providers committing work, validators auditing it, and quorum-gated settlement on a local anvil chain (the OGONG contracts are Solidity on Robinhood Chain, an EVM L2). Everything is CLI, no GUI.

If you just want to serve a model with zero network and zero signup, skip to Local mode.

0. Prerequisites

• Rust (stable) and cargo.
• Foundry (forge + anvil, for the Solidity contracts and the local chain). Install from https://getfoundry.sh.
• Node + npm (some provisioning helpers are TypeScript).
• A model file for whichever modality you’re serving (e.g. a .gguf for text, or the ACE-Step audio model used by the live mesh demo).

1. Build the binaries

From the repository root:

# Validator + verifier (the EVM settlement backend is the default build)
cargo build --release \
  -p validator-service --bin ogong-validatord --bin ogong-verifierd

# Router marketplace + consumer gateway
cargo build --release -p ogong-router-service --bin ogong-routerd --bin ogong-gatewayd

# Provider daemon
cargo build --release -p ogong-provider

The resulting binaries land in target/release/. Add it to your PATH or call them by full path.

2. Bring up the local chain

Stand up a local anvil chain with the OGONG contracts deployed and wired, in one command:

scripts/evm-localnet.sh

This starts anvil (if one is not already running), forge-deploys the whole contract set (token, staking, escrow, emission, registry), hands the mint authority to the emission contract at genesis, and writes scripts/.evm-localnet.env with the OGONG_EVM_* addresses the daemons read. Load it into each daemon shell:

set -a; source scripts/.evm-localnet.env; set +a

The whole EVM settle path (a metered release, a validator quorum co-signing an EIP-712 digest, the on-chain ecrecover settle, the provider paid) is proven end to end by the acceptance tests, which spin up their own anvil and deploy the same contracts:

forge test --root contracts                       # 31 Solidity tests
cargo test -p validator-service --test evm_mesh   # the validator EvmSink settles + pays a provider
cargo test -p ogong-provider  --test evm_commands # stake, unbond, transfer on chain

See The local mesh for the daemon-by-daemon tour.

3. Or wire the pieces by hand

To understand the moving parts, run them individually:

# A validator that audits every reply and dispatches to a verifier
ogong-validatord \
  --bind 0.0.0.0:4533 \
  --alpha 1 \
  --verifier-endpoint 127.0.0.1:4544 \
  --verifier-cert /path/to/verifier.der

# The verifier, pointed at an independent engine instance
ogong-verifierd \
  --bind 0.0.0.0:4544 \
  --provider-url http://127.0.0.1:11436

# The marketplace match engine (writes its cert so a gateway can pin it)
ogong-routerd --bind 0.0.0.0:4544 --cert-out router.der

# The OpenAI-compatible consumer front door
ogong-gatewayd --bind 0.0.0.0:4546 --router 127.0.0.1:4544 --router-cert router.der

# A provider serving an embedded text model and joining the network
ogong-provider configure \
  --embedded-text /path/to/model.gguf \
  --join-network \
  --validator-endpoint 127.0.0.1:4533
ogong-provider start

4. Call it

Once a gateway is up, talk to the network through any OpenAI-compatible client:

curl http://127.0.0.1:4546/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{
    "model": "ogong/verified/<maker>/<model>",
    "messages": [{"role":"user","content":"Hello from OGONG"}]
  }'

See the Consumer API for the model-id format and supported endpoints.

Next

• Provider node - every provider mode and flag.
• Validator node - audit rate, peers, settlement.
• The local mesh - a stage-by-stage tour of what the scripts do.

Provider node

A provider serves models from your GPU and earns OGONG for verified work. The daemon is ogong-provider. It is fully headless and ships no GUI.

Configuration lives in ~/.ogong-provider/config.json (written by configure, re-runnable any time). Downloaded models go to ~/.ogong-provider/models/.

Modes at a glance

Serving an engine

A provider either embeds an engine (spawns and manages it as a subprocess) or adapts to one you already run (Ollama, vLLM, llama-server). Embedded modes per modality:

Modalities compose: you can run text, image, and audio at once, each its own subprocess. For many models on a RAM budget, use --served-models <json> for on-demand LRU loading (engines load lazily and evict under a memory budget) instead of eager-spawning each.

Adapter alternatives (front an existing server): --upstream, --image-upstream, --audio-upstream, --video-upstream.

Joining the network

To earn on OGONG, a provider pushes each signed served-record to a validator (and, when metered, settles on-chain). It is off unless you opt in:

ogong-provider configure \
  --embedded-text ~/.ogong-provider/models/your-model.gguf \
  --machine mac-studio \
  --join-network \
  --validator-endpoint 127.0.0.1:4533
ogong-provider start

• --join-network - opt into the verified-inference network.
• --validator-endpoint <host:port> - the ogong-validatord to push signed records to.
• --machine <name> - short machine id, combined with your user id to form your canonical provider id.

An EVM payout key (secp256k1) is generated locally on first run; your payout address is its 20-byte hex address. Print it with:

ogong-provider wallet

Tunnel mode (home contributor)

ogong-provider start dials out to a tunnel server over QUIC and serves through it, so a home GPU behind NAT can contribute without exposing a public address. Requires an API key (--api-key, or OGONG_PROVIDER_API_KEY). The tunnel is only the transport: combined with --join-network, a home GPU serves on the Verified tier like any other provider, its work is committed and audited. (For a purely private server you run only for yourself, with no account and no audit, see Local mode.)

TEE / marketplace operator

ogong-provider serve runs a direct HTTPS server (skips the tunnel) for operators with a public, TEE-attested instance:

ogong-provider serve --listen 0.0.0.0:8443 --cert fullchain.pem --key privkey.pem

For TEE-tier attestation, fetch a DCAP quote bound to your report-data with ogong-provider quote, then submit your identity with ogong-provider marketplace-register. The operator-side admin runs DCAP chain verification before approving.

Inspecting

ogong-provider show     # print config (api key redacted)
ogong-provider wallet   # print EVM payout address (hex)
ogong-provider pull --list   # browse the model catalog
ogong-provider pull <name>   # download a model

See the CLI reference for the full flag list.

Advanced serving

Most providers just run ogong-provider local --model ... and never touch a flag. When you’re serving a large model, packing more concurrency onto a GPU, or splitting a model across hardware, there are extra knobs.

ogong-provider tunes its embedded engine (a llama.cpp fork’s llama-server, which it spawns and proxies) mostly through environment variables. For full control of how a model is placed on hardware, you front your own engine with --upstream instead.

It auto-sizes by default

You usually don’t need to set any of this. When the provider spawns the engine, it inspects the model (weight size, KV bytes per token, whether it’s MoE) against your machine’s memory budget (discrete VRAM, or a share of system RAM) and picks a config on its own:

• if the model fits, it spends the spare memory on concurrent request slots (capped where a single GPU stops scaling),
• if a MoE model is too big, it turns on the expert cache to stream cold experts,
• if a dense model is too big, it falls back to mmap / SSD paging so it still runs.

The knobs below are overrides of those automatic choices, for when you want to tune it yourself.

Two ways to tune

1. Embedded engine + env knobs. Keep using --embedded-text / local, and set LLAMAMP_* variables to control KV cache, MoE, speculative decoding, and GPU offload.
2. Front your own engine (--upstream). Launch llama-server (or vLLM) yourself with any flags you like, then point ogong-provider serve (or start / local) at it with --upstream http://127.0.0.1:8080/v1. This is how you do multi-GPU tensor-split and multi-node splits, which the embedded path doesn’t expose directly. ogong-provider still commits and settles exactly the same; the placement is the engine’s concern.

GPU offload

By default the embedded engine offloads all layers to the visible GPU(s). To cap it (for example, partial offload on a small card):

LLAMAMP_NGL=40 ogong-provider local --model my-model.gguf

KV cache: quantize it and size it

The KV cache dominates memory once you serve many concurrent requests. Quantize it and grow the context to fit more slots:

LLAMAMP_CACHE_TYPE_K=q8_0 LLAMAMP_CACHE_TYPE_V=q4_0 LLAMAMP_PARALLEL=16 \
  ogong-provider local --model my-model.gguf --n-ctx 16384

Quantized KV needs flash attention on, and is incompatible with tensor-split mode.

MoE: run a model bigger than your VRAM

A Mixture-of-Experts model can be served even when it doesn’t fit in VRAM by keeping some experts on CPU. Three controls, in increasing order of how much they offload:

• Partial offload (LLAMAMP_NCMOE=N): keep the experts of the first N MoE layers on CPU. The right knob when a model is only slightly too big.
• Full offload (the engine’s -cmoe, via a catalog model’s args): all experts on CPU.
• Expert cache (LLAMAMP_MOE_CACHE_SLOTS): for models well over budget, the OGONG engine streams cold experts through a slot cache, so an oversized MoE keeps running instead of failing to load. It auto-enables when a MoE exceeds the budget.

# partial: keep the first 12 MoE layers' experts on CPU
LLAMAMP_NCMOE=12 ogong-provider local --model big-moe.gguf

# or the streaming expert cache
LLAMAMP_MOE_CACHE_SLOTS=24 ogong-provider local --model big-moe.gguf

Speculative decoding

The engine accelerates generation by drafting tokens ahead and verifying them in a batch. ogong-provider turns it on automatically when it finds a drafter:

• set LLAMAMP_DRAFT_MODEL=/abs/path/to/drafter.gguf, or
• let a catalog model pull its own drafter (entries carry a draft_url).

LLAMAMP_DRAFT_MODEL=/models/drafter.gguf ogong-provider local --model gemma-4.gguf

The method defaults to MTP (multi-token prediction). Override it with LLAMAMP_SPEC_TYPE:

The n-gram methods need no draft model at all, so they work on any model.

Multi-GPU: split a model across GPUs

The embedded engine already spreads a model across all visible GPUs in layer-split mode. For tensor-parallel across GPUs, pass the engine’s split flags through a catalog model’s args array (every flag there is appended verbatim to the engine command):

ogong-provider local --served-models \
  '[{"id":"big","kind":"Text","path":"/models/big.gguf",
     "args":["--split-mode","tensor","--tensor-split","1,1","--flash-attn","on"]}]'

Any flag the engine supports can be set this way, per model. Alternatively, launch your own llama-server with the split flags and front it with ogong-provider serve --upstream http://127.0.0.1:8080/v1 ....

Multi-node: split a model across machines

A single model can be sharded across the GPUs of several machines. Each worker node runs the rpc-server binary (shipped with the provider) to expose its GPU; the provider node lists the workers, and the engine splits the model’s layers across the pool.

# on each worker box, expose its GPU over RPC:
rpc-server --host 0.0.0.0 --port 50052

# on the provider box, point at the workers; the model is sharded across them:
LLAMAMP_RPC_SERVERS="10.0.0.2:50052,10.0.0.3:50052" \
  ogong-provider local --model big.gguf

Trusted networks only The RPC transport is unauthenticated and unencrypted. Run it only over a private network you control, never the public internet.

You run and point at your own rpc-server nodes. Automatic discovery and a sharding policy (the provider spawning and balancing remote workers for you) are a separate layer still to come; for now this is the manual enable-and-point path.

Your machines vs. the network The RPC path above shards a model across your own machines, which you run and trust. To serve a model too big for your hardware by joining a cohort of independent providers that each verify and get paid for their slice, see Split inference, the network-level capability.

Run a split cohort

Some models are too large for any single GPU a casual provider owns. A cohort serves them anyway: each node runs a slice of the model’s layers, signs the boundary it produced, and is paid for exactly the layers it ran. This page shows how to stand one up. For the concept and the guarantees, see Split inference.

Two ways to serve a slice

The network-native path is the first: a provider advertises the layer range it can run, and the router’s planner tiles live ads into the cheapest cohort that covers the whole model. The explicit path is the same serving mechanism with the cohort named by hand, which is the clearest way to watch it work end to end.

Advertise a segment to the network

Set one field in the provider config so the router can place you in cohorts:

ogong_segment = "<lo>:<hi>:<n_layers>"

For example, 0:13:26 advertises layers 0 through 12 of a 26-layer model. The router’s planner then composes you with other segment providers into a cohort that tiles [0, n_layers) with no gaps. Everything else (verification, settlement) is automatic and identical to whole-model serving.

Run an explicit cohort

This is the hands-on version: split a model by layer range, run one segment server per shard, and drive the cohort with the lead. It runs on one machine across several processes, or across several machines by binding to real addresses.

What you need

• The boundary engine built (llama-eval-callback).
• The two binaries ogong-segment-server and ogong-lead.
• A GGUF model, plus two facts about it: its hidden width n_embd, and the interior-shard input scale embd-div (it is sqrt(n_embd) for Gemma, and 1 for Llama, Qwen, Phi, DeepSeek, GLM).

1. Split the model into per-shard GGUFs

Pick a layer tiling that covers [0, n_layers) with no gaps or overlaps. For a 26-layer model split in two:

gguf_segment_split.py  model.gguf  shard0.gguf  0  13
gguf_segment_split.py  model.gguf  shard1.gguf  13 26

Each shard holds only its layer range plus the embedding and output tensors. No shard holds the whole model.

2. Run one segment server per shard

One daemon per shard, each on its own address, each with its own signing key (generated and saved on first run). The first shard runs from the prompt; interior shards run from the upstream boundary, so they take --embd-div:

ogong-segment-server --model shard0.gguf --layers 0:13  --n-embd 2304 \
    --engine-bin llama-eval-callback --bind 0.0.0.0:9201 --key node0.key

ogong-segment-server --model shard1.gguf --layers 13:26 --n-embd 2304 --embd-div 48 \
    --engine-bin llama-eval-callback --bind 0.0.0.0:9202 --key node1.key

Each loads its model once and stays resident, signing every boundary it produces.

3. Drive the cohort with the lead

The lead threads the boundary shard to shard, collects each signed segment, and verifies the assembled pipeline (every signature, and that the chain tiles [0, n_layers)) before returning:

ogong-lead --shards 10.0.0.1:9201=0:13,10.0.0.2:9202=13:26 \
    --n-layers 26 --prompt "The capital of France is"

A healthy cohort prints cohort VERIFIED, with each shard’s layer range, node id, and signature check. A faked or dropped boundary breaks the chain and is localized to its signer; the lead reports the failure instead.

Verified settlement

To submit a verified run to a validator for an independent re-audit and on-chain payment, give the lead the validator and the paying account:

ogong-lead --shards ... --n-layers 26 --prompt "..." \
    --validator <host:port> --validator-cert <cert> \
    --consumer <wallet> --gross <amount> --wallets <shard0-wallet>,<shard1-wallet>

The validator re-runs the audited segment on its own reference engine and, on accept, settles the cohort on chain: each shard is paid for its slice under a conservation invariant, so the per-shard amounts must sum to the provider’s share and a release can never exceed the request’s fee. A caught cheat is ejected and the consumer refunded.

Notes

• Tiling. The shard ranges must be in order and cover [0, n_layers) exactly. A gap or an overlap is rejected.
• Generality. Any decoder transformer works, because the cohort rides the residual stream every such model exposes. Only --embd-div differs by family: Gemma scales its input, the rest use 1.
• One model, many machines. Binding the segment servers to real addresses is all it takes to spread a cohort across separate hosts. The lead and the verification are unchanged.

Validator node

A validator secures the network: it discovers peers from the on-chain registry, receives signed commitment records from providers, audits a sampled fraction of replies, and (when it holds the settlement role) gathers peer co-signatures and submits the on-chain quorum settle. The binary is ogong-validatord.

Build

cargo build --release --features settlement \
  -p validator-service --bin ogong-validatord --bin ogong-verifierd

The settlement feature is what enables on-chain settle; build without it for an audit-/cosign-only node.

Run

ogong-validatord \
  --bind 0.0.0.0:4533 \
  --alpha 1 \
  --verifier-endpoint 127.0.0.1:4544 \
  --verifier-cert /path/to/verifier.der

Key flags

Without --verifier-endpoint, audited replies await a manual verdict submission instead of auto-dispatch. With no --peer, the node draws its audit beacon solo.

In production the audit randomness comes from the threshold-BLS committee beacon (set up by a dealerless DKG across the registered validators); the per-validator VRF described by --peer is the bootstrap fallback used until that committee key is established.

Discovery - no manual peering

A validator reads the on-chain registry every ~30s (at confirmed commitment) to discover peers. You stake and register the node on-chain with its real endpoint and cert; from then on the mesh finds itself. The --peer flag exists for the audit beacon and for setups without registry discovery.

consensus_id = sha256(cert) ties a registered validator to the cert it presents over QUIC, so peers pin each other by their on-chain-registered certs.

Settlement environment

When a node holds the settlement role it needs these (the evm feature reads them):

There is no authority key: a release settles only when k co-signatures clearing the stake-weighted two-thirds quorum are assembled. Cosign-only peers run without the sink env (strip it with env -u if reusing a shell).

A peer only co-signs a release it independently holds in its own log, so the handling node forwards each metered record to its co-signer peers before it settles; a peer that never received the record declines. This is automatic; peers just need to be reachable on their bound address.

The whole committee, whatever its size, settles in one call: the handling node passes the gathered co-signatures as a Signature[] array and the settle contract ecrecovers each, sums the distinct signers’ bonded stake, and releases once it clears the quorum. There is no per-signer account triple, no address lookup table, and no accumulate-then-settle path; committee size is bounded by gas, not transaction size. Measured settle gas is roughly 192k / 239k / 346k at k = 3 / 9 / 21 co-signers.

Staking and activation

Anyone can become a validator with no gatekeeper: bond MIN_VALIDATOR_STAKE and register on-chain. Newly-staked stake counts toward the quorum only after an activation delay (set at deploy time via OGONG_ACTIVATION_SECONDS; 0 locally), so a freshly-bonded stake cannot be used to front-run an in-flight settle. Activating that stake into the quorum is self-only — you activate your own bond, not anyone else’s (a validator could otherwise activate a peer’s aged-dormant stake at an adversarial moment to spike the quorum bar and revert an in-flight settle) — and the validatord self-activates once the delay elapses, so in practice you only stake and register. The co-signer also binds each settle’s payout to the provider’s on-chain registered address, so the residual can never be redirected. Unstaking removes stake from the quorum immediately.

The verifier

ogong-verifierd is the audit muscle a validator dispatches to. It re-runs sampled steps of a committed trajectory on an independent engine and returns a verdict.

ogong-verifierd \
  --bind 0.0.0.0:4544 \
  --provider-url http://127.0.0.1:11436 \
  --k 2 \
  --cert-out verifier.der

Run the verifier against a separate engine instance from the provider’s; soundness comes from independent re-execution, not co-location.

See How verification works for the audit theory.

Router & gateway

The router/gateway pair is OGONG’s marketplace match layer. The router maintains a registry of providers and answers match queries; the gateway is the OpenAI-compatible HTTP front door consumers actually call. Both are standalone QUIC binaries in ogong-router-service with no GUI and no on-chain dependency for pure matching.

Build

cargo build --release -p ogong-router-service --bin ogong-routerd --bin ogong-gatewayd

Router - ogong-routerd

The match engine. Providers register themselves (Upsert); consumers (or the gateway) query (Route) for a provider that can serve a given ogong/<tier>/<maker>/<model>. It starts with an empty registry and fills as providers register.

ogong-routerd --bind 0.0.0.0:4544 --cert-out router.der

Match-only vs relay. By default the router only does matching - consumers Route, then forward the request themselves (this is what ogong-gatewayd does, which lets it read provider response headers). With --relay the router sits on the hot path and forwards bytes to the provider’s endpoint itself. Env equivalents: OGONG_ROUTER_CERT_OUT, OGONG_ROUTER_RELAY.

Gateway - ogong-gatewayd

The consumer front door. Serves an OpenAI-compatible HTTP API, matches each request through the router, and forwards it to the selected provider.

ogong-gatewayd \
  --bind 0.0.0.0:4546 \
  --router 127.0.0.1:4544 \
  --router-cert router.der \
  --max-price 1000000

Env equivalents: OGONG_ROUTER, OGONG_ROUTER_CERT, OGONG_GATEWAY_MAX_PRICE.

End to end

# 1. router (writes its cert)
ogong-routerd --bind 0.0.0.0:4544 --cert-out router.der &

# 2. gateway (pins that cert)
ogong-gatewayd --bind 0.0.0.0:4546 --router 127.0.0.1:4544 --router-cert router.der &

# 3. a provider registers with the router (see Provider node)
# 4. call the gateway with any OpenAI client
curl http://127.0.0.1:4546/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"ogong/verified/<maker>/<model>","messages":[{"role":"user","content":"hi"}]}'

See the Consumer API for the model-id format and endpoints.

Network stats & discovery (ogong-stats)

ogong-stats is a read-only HTTP indexer that answers, at any moment, what the network can serve, how much stake secures it, and how much has been emitted - straight from chain. It reads no secrets and holds no keys. Every value it returns is a plain read of the same on-chain contract state, and every live model it lists is verified against the provider’s bonded ad_commitment before it is surfaced.

Because it only reports what the chain already says, you can run it locally (pointed at any RPC) for a fully trust-minimized personal view, or host it as a public dashboard that anyone else can spot-check against chain.

Build

cargo build --release -p ogong-stats

Run

Configuration is the same environment the other readers use:

OGONG_EVM_RPC_URL=http://127.0.0.1:8545 \
OGONG_EVM_ESCROW=<escrow contract address> \
OGONG_EVM_STAKING=<staking contract address> \
OGONG_EVM_EMISSION=<emission contract address> \
OGONG_EVM_REGISTRY=<registry contract address> \
ogong-stats --bind 127.0.0.1:8088

Endpoints

All responses are JSON with Access-Control-Allow-Origin: *, so a browser dashboard can read them directly. If the chain or routers are unreachable the service stays up and returns 503 with a clear error rather than stale or invented numbers.

What is on-chain vs what is indexed

The point of the indexer is that everything it shows is provable, so it helps to know where each number comes from:

• Directly on-chain (a single account read): the bonded provider/validator/router sets, each provider’s ad_commitment and trust root, the approved TEE enclave set, total staked security, and the emission schedule + totals.
• Indexed from chain history: realized settled volume per provider per epoch (the settle-watch indexer buckets it as the emission tally).
• Not on-chain by design: the plaintext model list + prices (only the ad_commitment hash is on chain, so the indexer fetches each live ad and verifies it against that hash), and live free compute. The capacity numbers here are the routers’ live advertised supply; realized verified throughput per epoch is the settle-watch view, not this one.

Consume the network (ogong-connect)

There are two ways to send inference to OGONG, and they are different jobs:

• Point an app at the gateway directly. Any OpenAI-compatible client can call an ogong-gatewayd URL and request an ogong/<tier>/<maker>/<model> id. Simple, but the app has to know a gateway URL and it does the tier/E2EE handling itself.
• Run ogong-connect. A small local daemon that is the consumer: it figures out a gateway, verifies the provider’s attestation, establishes end-to-end encryption, dispatches your request, and opens the sealed reply. Any OpenAI or Ollama client points at http://127.0.0.1:PORT and gets verified, private remote inference without knowing anything about the network.

This page is about the second one.

ogong-connect is how you use the network. It is not the same as ogong-provider local, which runs a model on your own machine with no network, no account, and plaintext localhost (see Local mode). Use local to self-host; use connect to reach the network.

Run it

ogong-connect                          # zero-config: figures out a gateway, listens on 127.0.0.1:11435
ogong-connect --gateway https://my-gw  # pin a specific / self-hosted / local gateway
OGONG_GATEWAY=https://my-gw ogong-connect

Then point any client at it:

# OpenAI-compatible
curl http://127.0.0.1:11435/v1/chat/completions \
  -d '{"model":"ogong/verified/meta/llama-3.1-8b","messages":[{"role":"user","content":"hi"}]}'

# Ollama-compatible (set OLLAMA_HOST=http://127.0.0.1:11435)
curl http://127.0.0.1:11435/api/chat \
  -d '{"model":"ogong/tee/deepseek/deepseek-chat","messages":[{"role":"user","content":"hi"}]}'

The daemon serves /v1/chat/completions, /v1/models, and the Ollama surface (/api/chat, /api/generate, /api/tags, /api/version).

What it does per request

The model id’s tier decides how the provider is trusted before anything is sealed to it:

• ogong/verified/...: fetch the provider’s advertised X-Wing key, seal the request to it, POST it, and open the sealed reply. The GPU decapsulates; every relay in between sees only ciphertext.
• ogong/tee/...: first fetch a nonce-bound attestation, verify the TDX quote (trusted measurement, freshness, and that the serving key is bound in report_data) and that the attested key vouches for the encryption key, and only then seal to it. A mock or stale attestation is refused.

Either way the request never leaves your machine in the clear, and (for TEE) you never encrypt to a key that isn’t provably an approved enclave’s.

How it finds a gateway

You don’t have to know a gateway URL. Resolution order:

1. --gateway or OGONG_GATEWAY, if set.
2. Otherwise the client picks the first reachable gateway from the set it knows.

The known set starts from a small list of bootstrap gateways baked into the binary, plus a cache from previous runs (~/.ogong/gateways.json). On connect it gossips: it asks whatever gateway it reached for GET /v1/gateways (the HTTP mirror of the validator mesh’s peer-discovery) and merges the result into its set, persisting the union. So each run starts from a wider, self-healing view and depends less on the hardcoded seeds. Every running ogong-connect also serves /v1/gateways, so clients can discover the network through each other, not just through one central gateway.

The trustless endgame (in progress) is reading the on-chain provider/gateway registry directly, so the client never has to trust any single gateway or the baked-in seeds to learn the set.

Local mode (no network)

ogong-provider local runs a standalone inference server on your own machine with no OGONG network, no tunnel, and no account. It serves an OpenAI-compatible API and an Ollama-compatible API on the same port, so existing tools point at it unchanged. This is the zero-friction on-ramp, and a drop-in local runner in its own right.

Serve a model

# Serve one model (downloads on demand into ~/.ogong-provider/models if a catalog name)
ogong-provider local --model ~/.ogong-provider/models/llama-3.2-3b-instruct.gguf

# Serve several at once, each routable by id
ogong-provider local \
  --model llama-3.2-3b-instruct \
  --model qwen2.5-7b-instruct

Because it binds Ollama’s default port (127.0.0.1:11434) and speaks Ollama’s API, anything configured for Ollama works against it with no changes.

Use it

# OpenAI-style
curl http://127.0.0.1:11434/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"llama-3.2-3b-instruct","messages":[{"role":"user","content":"hi"}]}'

# Ollama-style
curl http://127.0.0.1:11434/api/chat \
  -d '{"model":"llama-3.2-3b-instruct","messages":[{"role":"user","content":"hi"}]}'

One-shot terminal chat

For a quick REPL without even setting up a server:

ogong-provider run llama-3.2-3b-instruct --system "You are concise."

Spawns the engine and streams replies to prompts read from stdin. Ctrl-D / Ctrl-C to quit. No account, no config.

Managing models

ogong-provider pull --list        # browse the catalog
ogong-provider pull <name|url>    # download into ~/.ogong-provider/models

When you’re ready to contribute to the network, the same binary joins it; see Provider node.

The local mesh

You can run OGONG’s whole verification spine on your own machine, against a local anvil chain: providers commit work, validators audit it and co-sign settlement over real QUIC, and escrow releases on chain only on a validator quorum. The on-chain layer is the Solidity contract set (contracts/), deployed to Robinhood Chain (an EVM L2) in production and to a local anvil here. It is a local, ephemeral network, the fastest way to watch the whole spine work before pointing the same processes at a live chain.

Components

• contracts (contracts/, Solidity) - the staking pool, validator registry, escrow, and the quorum-gated settle (a release needs k registered-validator co-signatures, verified on chain via ecrecover over an EIP-712 digest). There is no authority key on the money path.
• validatord (ogong-validatord, EVM settlement is the default build) - generates its own cert, reads the on-chain registry to discover peers, and (when it holds the settlement sink) settles a release by gathering peer co-signatures over QUIC and submitting one settle call.
• verifierd (ogong-verifierd) - re-runs a committed trajectory to score an audit.

1. Bring up the chain

scripts/evm-localnet.sh
set -a; source scripts/.evm-localnet.env; set +a

This starts anvil, deploys and wires the contracts, and writes the OGONG_EVM_* addresses the daemons read (OGONG_EVM_RPC_URL, OGONG_EVM_CHAIN_ID, and the escrow / staking / emission / registry addresses). See Validator node for the full settlement env a node needs (its OGONG_EVM_KEY and cert).

2. What the spine proves

The three properties the mesh demonstrates, and the checks that prove each on the EVM stack:

• Registry-driven discovery. Each validatord stakes and registers on chain with its real QUIC endpoint and cert, then learns its peers purely from the on-chain registry, with no manual peer wiring. A newly registered, staked validator appears in everyone’s discovery automatically, weighted by stake.
• Quorum settle over real QUIC. A metered release is pushed to the co-signer peers first (each holds its reply so it will co-sign), then to the handling node, which gathers the peers’ co-signatures over QUIC and submits the on-chain quorum settle. The whole committee settles in one call: the contract ecrecovers the gathered signatures, sums the distinct signers’ bonded stake, and releases once it clears the two-thirds quorum. Proven by cargo test -p validator-service --test evm_mesh: the actual validator EvmSink settles a metered release on a live anvil and the provider is paid on chain.
• Audit-gated settle. A real generation is audited before its escrow releases, and only an Accept settles. The handling validator audits a reply (--alpha 1) via a verifierd that re-runs sampled steps on an independent engine, adjudicates, and only then gathers the peers’ co-signatures and settles. A reject simply never settles, so the funds stay the consumer’s.

The contract-level guarantees (an uncosigned settle moves nothing, a sub-quorum is rejected, the fee split conserves the gross, a provider stake is never slashable) are covered by forge test --root contracts (31 tests). The full economic lifecycle in one run is the System.t.sol capstone.

3. Run the daemons by hand

With the chain up and the env loaded, run the pieces individually (see Quickstart for the full set):

# A settling validator: needs OGONG_EVM_KEY plus the sourced OGONG_EVM_* env.
OGONG_EVM_KEY=<validator 32-byte hex key> \
  ogong-validatord --bind 0.0.0.0:4533 --alpha 1 \
  --verifier-endpoint 127.0.0.1:4544 --verifier-cert /path/to/verifier.der

# Stake and register a provider (reads the same OGONG_EVM_* env):
ogong-provider stake --amount 10000
ogong-provider register-validator --endpoint 127.0.0.1:4533 --cert validator.der

Notes

• --alpha 0 = no audit (immediate unaudited release), used to isolate the settlement mesh. --alpha 1 + --verifier-endpoint/--verifier-cert wires the audit path.
• Co-locating the verify-engine with the provider is a demo convenience; soundness uses a separate engine instance.
• The settle path is bounded by gas, not transaction size, so a quorum of any size settles in one call. See Validator node for the gas figures.
• examples/traj_audit_loop is the in-process, CI-friendly equivalent, no chain or live engine required.

CLI reference

Every OGONG role is a standalone binary. All flags are exposed via --help on each binary; this page is a curated index of the ones that matter. Defaults shown are the binaries’ built-in defaults.

ogong-validatord

Validator / audit node (QUIC).

Settlement env (EVM): OGONG_VALIDATOR_CERT_OUT, OGONG_EVM_RPC_URL, OGONG_EVM_CHAIN_ID, OGONG_EVM_KEY, and the contract addresses OGONG_EVM_ESCROW, OGONG_EVM_STAKING, OGONG_EVM_EMISSION, OGONG_EVM_REGISTRY. See Validator node.

ogong-verifierd

Audit verifier: re-runs committed work on an independent engine.

ogong-routerd

Marketplace match engine (QUIC).

Env: OGONG_ROUTER_CERT_OUT, OGONG_ROUTER_RELAY.

ogong-gatewayd

OpenAI-compatible consumer front door.

Env: OGONG_ROUTER, OGONG_ROUTER_CERT, OGONG_GATEWAY_MAX_PRICE.

ogong-provider

Provider daemon. Subcommands:

Selected configure flags:

local flags: --model (repeatable), --mmproj, --n-ctx, --listen, --upstream, --served-models.

Consumer API

Consumers reach the network through ogong-gatewayd, which speaks an OpenAI-compatible HTTP API. Any OpenAI client library works; point its base URL at the gateway.

Model id format

OGONG model ids encode the trust tier, the maker, and the model:

ogong/<tier>/<maker>/<model>

• <tier> - verified or tee (see Trust tiers).
• <maker> - the model author; attributed on-chain (royalty slot reserved, inactive at launch).
• <model> - the model name.

Example: ogong/verified/<maker>/llama-3.3-70b.

The gateway parses the id, asks the router for a provider that can serve that tier + model, and forwards the request.

Chat completions

curl http://127.0.0.1:4546/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{
    "model": "ogong/verified/<maker>/<model>",
    "messages": [
      {"role": "system", "content": "You are helpful."},
      {"role": "user", "content": "Hello from OGONG"}
    ],
    "stream": true
  }'

Streaming uses standard OpenAI SSE framing.

Other modalities

Providers can serve image, audio (music / TTS / STT), and video. The corresponding OpenAI-style endpoints are forwarded to a provider that serves that modality:

Availability depends on what providers in the marketplace are serving for the requested tier.

Pricing

The gateway enforces a budget ceiling per 1k tokens via --max-price (atomic OGONG units). Requests that would exceed it are rejected at match time. Settlement of paid work happens on-chain after a passing audit and validator quorum; see How verification works.

End-to-end encryption protocol

A Verified-tier provider runs on an ordinary GPU with no enclave, so the network gives you confidentiality from cryptography instead of trusted hardware: the client seals its request to the provider’s public key, every relay (gateway, router, reverse tunnel) sees only ciphertext, and only the provider can open it. The provider seals the reply back to a key the client generated per request.

This page is the wire protocol, so anyone can write a client, including a browser “personal mode” one. The canonical implementation is the Rust crates ogong-e2ee (crypto), ogong-client (consumer), and ogong-provider (the provider’s xwing_e2ee interceptor); this page matches them byte for byte.

Primitives

• KEM: X-Wing — the IETF hybrid that runs X25519 and ML-KEM-768 together and combines their secrets, so an attacker must break both the classical and the post-quantum part (harvest-now, decrypt-later is covered). A provider publishes its X-Wing encapsulation (public) key in its attested advertisement.
• AEAD: ChaCha20-Poly1305 — 32-byte key, 12-byte nonce, 16-byte tag.
• KDF: SHA-256, domain-separated. The one-shot AEAD key is SHA-256("ogong-e2ee-xwing-v1" || shared_secret); the streaming session key is SHA-256("ogong-e2ee-xwing-session-v1" || shared_secret) (a different domain, so the two can never collide).

Model binding (AAD)

Every AEAD operation authenticates an associated-data value that binds the served model, so an on-path relay that rewrites the cleartext x-ogong-model header breaks the tag instead of silently steering you to a different model:

aad = "ogong-e2ee-inference-aad-v1" || u32_le(len(model)) || model_utf8

Request

The client generates a fresh reply keypair per request and seals an envelope to the provider’s X-Wing public key. The reply key rides inside the seal (not a cleartext header), so a relay cannot substitute its own to intercept the response.

envelope   = u32_le(len(reply_pub)) || reply_pub || request_json
sealed_req = xwing_seal(provider_pub, envelope, aad(model))
           = xwing_ciphertext || chacha20poly1305(key = KDF("...xwing-v1", ss), nonce = 0, envelope, aad)

POST it to /v1/chat/completions with:

The one-shot request nonce is all-zeros: safe because each seal makes a fresh X-Wing encapsulation, so the AEAD key is single-use.

Trusting the provider key. On the Verified tier the client must authenticate the advertised X-Wing key against the provider’s pinned record_signer (a signed key-binding with an expiry) before sealing; on the TEE tier the key is bound into the enclave’s attestation quote. See Trust tiers. Skipping this turns E2EE into blind-seal, which a relay can MITM, so a real client fails closed without a pin.

One-shot response

For a non-streaming reply the provider seals the whole response as one envelope to reply_pub:

header  x-ogong-e2ee: xwing
body    xwing_seal(reply_pub, response_json, aad(model))

The client opens it with its reply secret key.

Streaming response

For a streaming (SSE) reply the provider does one X-Wing encapsulation to reply_pub to establish a shared session key, then seals each chunk under it with cheap symmetric crypto — one KEM, not a seal per chunk. The response is a sequence of length-delimited frames:

header  x-ogong-e2ee: xwing-stream
body    frame*  where each frame = u32_le(len) || payload

  frame 0        payload = xwing_ciphertext            (the KEM; client decapsulates -> session key)
  frame 1..N     payload = chacha20poly1305(
                             key   = KDF("...xwing-session-v1", ss),
                             nonce = u64_le(i) padded to 12 bytes,   // i = 0,1,2,... per chunk
                             chunk_i, aad(model))
  final frame    len = 0                               (clean end-of-stream marker)

The per-chunk nonce is the chunk counter (64-bit little-endian in the low 8 bytes of the 12-byte nonce). Because the session key is fresh per response, no (key, nonce) pair ever repeats — the AEAD safety condition. The counter also authenticates order: a relay that reorders, drops, or splices chunks makes an open fail, and a missing terminal frame is detectable truncation.

To consume: read frame 0, decapsulate it to the session key, then open frames at counter 0,1,2,... until the zero-length terminal, concatenating the plaintext (the original SSE byte stream).

Who runs a client

This protocol is the consumer path, and a consumer is anyone who speaks it — not only a personal app. Two common shapes:

• A person, for themselves — a CLI or a browser “personal mode” app. A browser client is just this protocol in JS/WASM: the gateway/router blind-relay the opaque sealed bytes (they never hold plaintext), so the browser does all the crypto itself — seal the request to the provider’s authenticated X-Wing key, send the opaque body through the gateway, and open the sealed reply (reassembling the stream with the frame format above). No server-side change is needed.
• A service or business — a backend that uses OGONG for inference and wraps it in its own product (a chat app, an API, an agent). The operator is the OGONG consumer: it holds the token and pays for the work, so its users never touch OGONG — they sign in and pay however the operator chooses. This is the standard “wrap an inference API in your product” model.

Where the seal happens decides who is shut out of the plaintext

The encryption is identical in both shapes; what differs is which client performs the seal:

• The end user’s browser seals (the operator only blind-relays): genuinely end-to-end from that user to the GPU — even the operator cannot read it. Use this for a “we can’t see your prompts” product.
• The operator’s backend seals (users send plaintext to the backend over ordinary TLS, the backend does the OGONG E2EE outward): the OGONG network, relays, and reverse tunnels see only ciphertext, but the operator — being the consumer — does see the plaintext. Normal for any app wrapping an inference API; it is just not end-to-end from the user.

Both are valid; it is the operator’s choice of where the crypto terminates. A client can embed the ogong-client logic directly, or point at a gateway (ogong-gatewayd) that handles tier trust, E2EE, and settlement — so a service can resell verified inference without implementing the low-level protocol, and its customers never deal with the token.

Whichever client seals, it MUST authenticate the provider’s X-Wing key first (Verified: the pinned record_signer binding; TEE: the attestation quote) and fail closed without it — otherwise an on-path relay can hand over its own key and read everything.

Glossary

α (alpha), a validator’s audit coverage in [0,1]. --alpha 1 audits every reply; --alpha 0 audits none. The design target is full coverage, affordable because checking is cheap.

β (beta), target lifetime false-ejection rate (the Ville bound) used by the SPRT when deciding to eject a provider.

Attestation, a hardware-signed proof of what code and model an enclave is running; the trust root of the Confidential (TEE) tier. See DCAP quote.

Commitment, a verifiable digest a provider emits over its work: a Merkle tree, root commit_root, whose leaves bind a hidden-state SRP sketch and a top-k logprob digest per 32-token window. Lets a verifier re-check a sampled slice cheaply.

commit_root, the Merkle root of a reply’s per-window commitment leaves, signed into the provider’s record.

consensus_id, sha256(cert); ties a registered validator to the QUIC cert it presents, so peers pin one another by their on-chain-registered certs.

DCAP quote, a hardware-signed attestation (Intel TDX) proving what code/model is running inside a TEE; the trust root for the Confidential tier.

Earned-trust ramp, a freshly registered provider starts at a low routing-weight floor (~10%) and rises to full weight only after enough clean history (~16 audited accepts and ~16 passed GPU challenges), with full-coverage force-auditing until then. Makes the register-cheat-eject-recycle cycle unprofitable.

Escrow, on-chain account holding a consumer’s funds until a release is audited and quorum-settled. On a reject the funds are refunded to the consumer.

Gateway, ogong-gatewayd; the OpenAI-compatible HTTP front door for consumers, and an optional fiat on-ramp.

Honeypot audit, a planted audit carrying a known verdict; a verifier that disagrees with it (rubber-stamping a known-bad accept, or false-flagging a known-good reply) is slashed. A complementary check: the primary defense against a lazy/colluding verifier is the two-verifier cross-check (an audit goes to two independent verifiers and settles as accept only if both agree).

Hybrid PQ signature, the provider record is signed with Ed25519 and ML-DSA-44, so it survives the future break of either scheme.

KS test (Kolmogorov–Smirnov), the sup-norm distance between the committed and recomputed top-k logprob distributions; catches a localized probability shift that an averaged TV would dilute. Reject threshold ≈ 0.10.

LOGIC, the logprob-commitment primitive: top-k logprob digests at every decode position. The cheap first check, using values the engine already exposes.

Maker, the author of a model, identified in ogong/<tier>/<maker>/<model> and attributed on-chain. A royalty slot is reserved but inactive at launch (deferred to governance).

model_root, a SHA-256 over the model’s ordered shard content hashes; binds a commitment to a specific model identity (quantization included implicitly).

Proof-of-distinct-GPU, the Verified-tier Sybil cost: a timed challenge in which the validator requires a committed reply on the provider’s loaded model within a wall-clock deadline (default ~16 tokens in 20s). Misses feed a miss-rate SPRT that ejects identities an operator’s real throughput cannot sustain. The challenge reply doubles as a correctness audit, so the anti-Sybil work is productive verification.

Provider, a node serving inference from a GPU; the daemon is ogong-provider. Risks no correctness bond and doubles as a verifier for peers serving the same model.

Quorum settle, the on-chain settlement that releases escrow; requires co-signatures from a stake-weighted supermajority of validators (more than two-thirds of stake). Each co-signature also binds the specific consumer escrow being debited, so a settle cannot be redirected to charge a different consumer’s allowance.

Reputation, a per-provider score (with stake) that weights how much work the router routes to it.

ρ (rho), the ratio of verification cost to generation cost. Measured at a few percent (2.5-3.7%) on datacenter GPUs (~30-40x cheaper than generation) and ≈ 5% on Apple Silicon (~20x). This is what makes full-coverage auditing affordable.

Router, ogong-routerd; the marketplace match engine, an attested enclave that draws a provider proportionally to stake × reputation and is slashable for misrouting.

Score mode, the engine path that returns per-token logprobs/hidden states from a single teacher-forced prefill without generating (what makes the audit cheap). The default verification path (capability-detected, with a fallback).

Settlement sink, the role/env that lets a validator submit the on-chain settle. Only the handling validator holds it; peers are cosign-only.

SPRT, sequential probability ratio test; accumulates per-reply verdicts into a running decision so a persistent cheater is ejected quickly while honest noise rarely is (bounded by β).

SRP sketch (sign-random-projection), the hidden-state commitment: the activations projected onto a bank of random ±1 directions seeded by a per-request projection key the validator derives from the request id. Well-conditioned and not the provider’s to choose (nor precomputable), so a substitute model can’t hide in a hand-picked subspace. Mandatory on the Verified tier, with a fixed public seed kept only as a legacy whole-model fallback. Replaces the older provider-chosen magnitude-top-k scheme. Reject threshold (relative-L2) ≈ 0.10.

Stake, OGONG locked by an operator to buy priority and availability weighting. It is not a slashable correctness bond.

Teacher-forced verification, the audit method: the verifier runs one forward pass over (prompt + claimed output) and reads the model’s hidden states and logprobs off that pass, instead of re-generating. The source of ρ ≈ a few percent (2.5-3.7% on datacenter GPUs).

TEE (Confidential tier), Trusted Execution Environment; the verifiably-private tier where the operator can’t read your prompt.

Threshold-BLS beacon, the committee randomness source for audit selection. Validators share one BLS key (via a dealerless DKG); each epoch’s beacon is the unique threshold signature over it, so no coalition can grind or steer the draw and withholding can’t move it. Anyone verifies it against the group public key. A drand-style construction; it closes the “watch then decide” attack.

TOPLOC, the hidden-state-commitment primitive (implemented as the SRP sketch); a stronger check than logprobs alone because it pins internal activations, which distillation can’t fake.

Total-variation (TV) distance, the distance between committed and recomputed top-k logprob distributions; a companion signal to KS (honest ~0.01, a quant cheat ~0.05). The logprob reject line itself is KS ≈ 0.10.

Trajectory, the recorded sequence of a generation (token windows, or sampled denoising steps for diffusion) that a verifier re-checks during an audit.

Validator, ogong-validatord; an attested CPU enclave (no GPU) that audit-selects work, adjudicates verifier scores, co-signs settlement, and posts the only slashable bond in the system.

Verifier, ogong-verifierd; a provider GPU in audit duty that teacher-forces the claimed output on an independent engine and returns Accept/Reject, paid a flat fee per audit.

VRF (verifiable random function), the per-validator audit-selection primitive, now the bootstrap fallback to the threshold-BLS beacon. Keeps audit selection unpredictable yet verifiable, so a provider can’t tell which replies are checked.