Network Architecture
The network is the substrate that holds the model. It is not a chain in the conventional sense; it is a small on-chain settlement layer wrapped around a much larger off-chain compute and data layer. This chapter specifies the architecture at the level of components and their interfaces. Operational details (validator economics, data formats, settlement semantics) are documented in subsequent chapters.
Three layers
The network has three layers, stacked by latency budget:
- Settlement layer. On-chain state: validator registry, checkpoint registry, job ledger, treasury. Single-second finality. Touched on every economic action; never touched during inference.
- Coordination layer. Off-chain, signed messages: job announcements, validator heartbeats, routing tables, attestation streams. Sub-second propagation across the network. Touched on every job dispatch.
- Execution layer. Validator-local: model forward passes, training steps, dataset ingestion. Latency ranges from milliseconds (inference) to weeks (pretraining). The bulk of the network's work happens here.
The settlement layer is the smallest and the slowest. The execution layer is the largest and the fastest. The coordination layer mediates between them.
Component map
| Component | Layer | Purpose |
|---|---|---|
| Token mint | Settlement | Holds supply, enforces transfer policy |
| Validator registry | Settlement | Mapping of validator IDs to stake, hardware tier, surfaces served |
| Checkpoint registry | Settlement | Active checkpoint per surface, by content hash |
| Job ledger | Settlement | Posted jobs, bids, selections, attestations |
| Treasury | Settlement | Holds fee proceeds, executes disbursements under timelock |
| Routing service | Coordination | Maps user queries to validators |
| Attestation stream | Coordination | Validator-signed execution logs, batched to chain on cadence |
| Challenge service | Coordination | Receives fraud proofs, computes payouts |
| Validator daemon | Execution | Runs surfaces locally, signs outputs |
| Dataset shards | Execution | Content-addressed data slices held by validators |
How a single query traverses the network
A user query at the language surface follows this path:
- The user submits a query to a public endpoint operated by the foundation or by an independent gateway.
- The gateway hashes the query, signs it, and forwards it to the routing service with the desired surface and latency tier.
- The routing service consults the current validator registry and the surface's active checkpoint, and selects a validator (or set of validators, for redundancy) from the eligible pool.
- The validator runs the forward pass locally, signs the output, and returns it through the gateway.
- With probability (configurable, currently around 3%), the same query is dispatched in parallel to a second validator; outputs are compared.
- Mismatched outputs trigger a challenge through the challenge service.
- At the end of the period, validator-signed attestations are batched and submitted to the on-chain attestation program, which credits validators' reward accounts.
Steps 1, 4, 7 touch the settlement or coordination layers; step 3 is the routing decision. All other steps are local to a validator and to the gateway.
Why this split
Three observations select for the three-layer split.
Throughput. A general intelligence cannot run on a chain. The throughput required for inference at any meaningful user count is many orders of magnitude above what any current chain offers. The execution layer therefore cannot live on chain.
Verifiability. A network with no on-chain state cannot enforce its own invariants. The settlement layer is what makes the network a network rather than a federation of independent services.
Latency. On-chain finality is too slow for any user-facing operation. The coordination layer absorbs the latency gap by allowing signed off-chain messages with on-chain backstop.
The settlement chain
The codex assumes a high-throughput chain with sub-second finality. The reference deployment is on Solana, with the token issued under the SPL standard and protocol-owned liquidity on Raydium CPMM. The architecture is portable to any chain with comparable primitives, but the live deployment is Solana-specific and the rest of the codex should be read with that in mind.
What the architecture does not specify
It does not specify the wire format between gateways and validators (this is operational, subject to revision without protocol change). It does not specify the gateway operator set (anyone can operate a gateway). It does not specify the user-facing API (this is a product concern, not a protocol concern).
The architecture specifies only what must be globally agreed for the network to function. Everything else is local.