Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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 a verifier,
  • 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 a verifier from the other providers serving the same model and dispatches the job. The verifier teacher-forces a single pass over the claimed output, scores the drift against the commitment, and returns Accept / Reject. 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 Solana program (Anchor) under chain/programs/chain. It holds the staking pool, the validator registry, escrow, the quorum-gated settle instruction (a release needs k registered-validator co-signers), 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.