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, on either lane. On the OGONG L1 routing priority and emission share are earned by verified work and nothing else, so there is no deposit to make at all. On the EVM lane the router marketplace additionally lets a provider stake for priority weighting, which is pure upside and never slashable for a wrong answer. 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,
• earns its seat by verified work, and posts no bond: a validator caught issuing false verdicts is ejected, forfeiting the seat and the future emission the seat was worth, rather than having capital confiscated. Nobody posts capital anywhere in the protocol, so there is nothing anywhere for anyone to seize.

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. That weighting is the deployed EVM lane’s; the router has not yet been migrated to read the L1’s verified-work measure instead, which is tracked as roadmap work. 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

There are two settlement lanes, and it matters which one a given statement is about.

The OGONG L1 is the sovereign chain: a Substrate runtime with BABE authorship and GRANDPA finality, where the GRANDPA authority weight of a validator is its recently verified work rather than any stake. Its pallets are registry, pouw, readiness, calibration, settlement, disputes, and emission. There is no staking pallet, because there is nothing to stake: seats are earned by work, lost by ejection, and never bought. The committee is bounded at 300 seats (GRANDPA messaging is quadratic in the committee, so the set that finalises blocks has to be bounded even though mining is not — anyone may earn and claim emission without ever holding a seat). It carries an EVM lane of its own at chain id 2030 so Solidity tooling works against it directly. See The OGONG L1.

The EVM contracts under contracts/ are the older deployment (Robinhood Chain, an EVM Layer-2), superseded by the L1 but still what the client settles against today. There was a Solana program set too, likewise superseded. The L1 carries its own EVM lane, so nothing is given up by retiring them. They hold a 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. Where these docs describe staking, they are describing this lane; the L1 has none. Migrating the client off these contracts is roadmap work.

On both lanes, makers are attributed on-chain (their royalty slot is reserved but inactive), and 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.