> ## Documentation Index > Fetch the complete documentation index at: https://docs.pinaivu.com/llms.txt > Use this file to discover all available pages before exploring further. # Architecture Overview > How the coordinator, nodes, gateway, chat-relayer, and explorer fit together ## Components Each component sits in exactly one of three layers — **decentralized**, **off-chain but verifiable**, or **on-chain** — and that distinction is the subject of [Decentralization & verifiability model](/architecture/decentralization). Don't read "Pinaivu" as a single trust domain; read it as three different kinds of claim stitched together by the contracts: | Component | Layer | Role | | ------------------------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Coordinator** | Off-chain, verifiable | Attested Nitro Enclave (the [Nautilus](/architecture/decentralization) pattern) that brokers auctions between clients and decentralized GPU nodes, settles payment, and signs routing receipts. Never runs inference itself. | | **Node** | Decentralized | Independent operator's GPU machine. Runs the model, joins the open libp2p mesh, bids on inference requests, signs a `ProofOfInference` per completed job. | | **Gateway** (`api.pinaivu.com`) | Off-chain | Stateless OpenAI-compatible front door for developers. Per-key auth, no memory layer, not itself an enclave. | | **chat-relayer** (`chat.pinaivu.ai`) | Off-chain, verifiable | Stateful front door for end users — itself a second Nitro Enclave — adds cross-session memory via embeddings + Walrus. | | **Explorer** (`explorer.pinaivu.com`) | Off-chain | Public lookup for routing receipts, payments, and node activity, backed by the explorer-indexer service. | | **Sui contracts** (`pinaivu::*`) | On-chain | The root of trust: enclave registration, receipt verification, treasury vault. What makes the off-chain components' claims checkable. | | **Walrus** | Decentralized | Independent, content-addressed storage network for archived receipts and encrypted chat session history. | ## Component diagram The diagram below uses the same three-way split as [Decentralization & verifiability model](/architecture/decentralization): **ON-CHAIN** (Sui), **OFF-CHAIN, VERIFIABLE** (the Nautilus-pattern enclaves), and **DECENTRALIZED** (the node mesh and Walrus). ``` ┌─────────────────────────────────────┐ │ ON-CHAIN (Sui) │ │ pinaivu::{enclave, receipts, vault}│ └────────────┬───────┬────────────────┘ │ │ register/ │ │ settle() update_pcrs │ │ (sig must verify │ │ under registered │ │ enclave key) ┌──────────────────────────┴───────┴───────────────────┐ │ OFF-CHAIN, VERIFIABLE │ │ Coordinator — Nitro Enclave (NSM-attested) │ │ HTTP API · libp2p mesh · apalis · signs receipts │ └────────┬─────────────────────┬────────────┬─────────┘ │ │ │ ▼ ▼ ▼ DECENTRALIZED Postgres + Redis DECENTRALIZED libp2p mesh (auction) (receipts, jobs, Walrus storage │ payments) (archived ┌──────────┴──────────┐ receipts) │ │ ┌───┴───┐ ┌────┴────┐ │ node │ │ node │ independent operators, │ │ │ │ each bids + runs inference, └───────┘ └─────────┘ sends signed CompletionAck api.pinaivu.com ──▶ gateway (off-chain, stateless) ────┐ ├──▶ coordinator chat.pinaivu.ai ──▶ chat-relayer (off-chain, verifiable,─┘ (above) Nitro Enclave) │ ▼ cross-session memory: pgvector + DECENTRALIZED Walrus storage ``` ## Request lifecycle ``` 1. client → coordinator POST /v1/chat/completions { model, messages, client_pubkey_hex } 2. coordinator publishes InferenceRequest on gossipsub "/pinaivu/inference/any/1.0.0" 3. nodes receive request, bid via "/pinaivu/bids/1.0.0" InferenceBid { peer_id, price_per_1k, latency, reputation, http_endpoint, payout_address } 4. coordinator ranks bids, picks winner, signs DispatchToken 5. coordinator → client { request_id, node_url, dispatch_token } 6. client → node POST {node_url}/v1/inference { prompt, dispatch_token } 7. node verifies dispatch_token, runs inference, returns the response directly to the client, builds + signs ProofOfInference 8. node → coordinator libp2p request-response on "/pinaivu/completion/1.0.0" CompletionAck { request_id, proofs[], aggregated_output_hash, signature } 9. coordinator verifies primary sig + every embedded proof, signs RoutingReceipt (BCS IntentMessage), stores it, enqueues settlement 10. apalis worker computes payouts from proofs, submits vault::settle PTB(s) on Sui 11. anyone GET /v1/proofs/{request_id} → receipt ``` Two things are worth noticing in that lifecycle: the **response never streams through the coordinator** (step 7 goes straight node → client), and the **coordinator never runs a model** — it only ranks bids, signs, and verifies. Both of those properties are what keep the coordinator's off-chain job narrow enough to fit inside an enclave and stay verifiable. See [Decentralization & verifiability model](/architecture/decentralization) for why each of these pieces (Nautilus enclave, Sui, Walrus, open node mesh) closes a specific way a naive "just trust our server" coordinator could otherwise misbehave. Nautilus, Sui, Walrus, and the open node mesh — what each one prevents Wire types, signing formats, libp2p topics `pinaivu::enclave`, `receipts`, `vault` How chat.pinaivu.ai keeps conversations coherent across nodes and sessions