> ## 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. # Decentralization & Verifiability Model > What's decentralized, what's off-chain-but-verifiable, and what's on-chain — and how they connect ## The core distinction It's easy to conflate "decentralized" with "trustworthy" — they're not the same property, and Pinaivu deliberately doesn't claim the first where it hasn't earned it. Three different claims are layered here, and keeping them separate is the point of this page: | Layer | Claim | Mechanism | | ------------------------------ | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------- | | **GPU compute** | Genuinely **decentralized** — no single operator, open to join | libp2p node mesh, permissionless bidding | | **Coordinator + chat-relayer** | Off-chain, single instances today, but **verifiable** — not decentralized, not blindly trusted either | Nautilus / Nitro Enclave attestation | | **Sui contracts** | **On-chain**, the anchor that makes the off-chain components' claims checkable by anyone | `pinaivu::enclave`, `receipts`, `vault` | | **Walrus** | Independent, content-addressed storage — genuinely decentralized at the storage layer | HTTP publisher/aggregator over an external network | ``` DECENTRALIZED OFF-CHAIN, VERIFIABLE ON-CHAIN (no single operator) (Nautilus / Nitro Enclave) (Sui Move) ────────────────── ───────────────────────── ───────────────────── ┌─────────────────┐ auction ┌─────────────────────┐ register ┌──────────────────────┐ │ libp2p node mesh │◀──────────▶│ Coordinator │──────────▶│ pinaivu::enclave │ │ independent GPU │ dispatch │ (1 instance today, │ attest │ EnclaveConfig + │ │ operators, open │ /ack │ attested, signs │ │ Enclave │ │ to join │ │ receipts) │ └──────────┬───────────┘ └─────────────────┘ └──────────┬────────────┘ │ │ signed verify_signature

│ receipt │ ▼ ▼ ┌─────────────────┐ ┌─────────────────────┐ ┌──────────────────────┐ │ Walrus storage │◀──archive─│ chat-relayer │ │ pinaivu::receipts │ │ network │ /chat │ (1 instance today, │ │ typed payload │ │ independent │ blobs │ attested, also │ └──────────┬───────────┘ │ node operators │ │ Nitro Enclave) │ │ └─────────────────┘ └─────────────────────┘ ▼ ┌──────────────────────┐ │ pinaivu::vault │ │ settle() gated on │ │ enclave signature │ └──────────────────────┘ ``` **Read it like this**: the GPU layer and Walrus are decentralized because no single party runs them. The coordinator and chat-relayer are *not* decentralized — they're single off-chain services — but they're **verifiable**, because the Sui contracts on the right give anyone a way to check, independent of Pinaivu's own infrastructure, that those services ran the code they claim to have run and signed what they claim to have signed. "Sufficiently decentralized" describes the compute and storage layers on the left; "verifiable" describes the off-chain Nautilus components in the middle; the contracts on the right are what connects the two claims. ## The core tension Private inference over a decentralized GPU network still needs some party to run the auction, route the dispatch, and settle payment in real time. That's inherently a coordination role — and naive coordination usually means centralization: one company's server decides who wins, what gets paid, and what the "official" history is, and everyone has to trust them not to cheat. Pinaivu's answer isn't to eliminate the coordinator — that's not realistically possible for a low-latency auction — it's to make the coordinator's power **checkable rather than trusted**. Four pieces of infrastructure do that job, each closing a different way a centralized coordinator could otherwise cheat: | Threat if the coordinator were "just trusted" | What closes it | | -------------------------------------------------------------- | -------------------------------------------------------------- | | Coordinator secretly runs different code than what it claims | **Nautilus** / Nitro Enclave (TEE) | | Coordinator forges a receipt, or its operator key drains funds | **Sui** (on-chain signature verification) | | Coordinator (or its operator) quietly edits/deletes history | **Walrus** (independent, content-addressed storage) | | Coordinator picks which GPU does the work | **decentralized GPU node mesh** (open, permissionless bidding) | *** ## 1. Nautilus / Nitro Enclave — making the coordinator's code trustless The coordinator doesn't run as an ordinary server process — it runs inside an **AWS Nitro Enclave**, following the **Nautilus** pattern (the same template used by `nautilus-memwal-relayer`, and reused again for chat-relayer). This is the foundation everything else builds on: every other guarantee in this document ultimately traces back to "the code inside this enclave is provably the code that's published," and that claim only exists because of the Nautilus attestation chain. Concretely, in this codebase: * The enclave generates an **ephemeral Ed25519 keypair at every boot** — this key never leaves the enclave, not even the operator who owns the EC2 instance can extract it. * AWS's **Nitro Security Module (NSM)** produces a signed attestation document binding that ephemeral pubkey to the exact measurements (PCR0/1/2) of the code that's running — a cryptographic hash of the actual binary, not a claim about it. * The build is **reproducible**: rebuilding the same source produces byte-identical PCRs (verified explicitly — `make eif` twice and diff the `.pcrs` output). This means anyone can independently compile the coordinator's public source and confirm the PCRs match what's attested on-chain — there's no way to attest one binary and quietly run another. * Every artifact the coordinator produces — the dispatch token, the routing receipt — is signed by that enclave-bound key. The host's own root user, AWS itself, or the operator running the EC2 instance cannot forge a signature under that key, because the key was generated inside the enclave's isolated memory and never exported. `chat-relayer` follows the exact same Nautilus shape for the same reason — chat prompts are at least as sensitive as inference requests, so the code that sees them is attested too. See [Memory layers](/architecture/memory-layers). **What this buys**: even though there's one coordinator process, the operator cannot misbehave without it being mathematically detectable — any forged receipt would carry a signature that doesn't verify against the registered, attested key. *** ## 2. Sui — making the coordinator's attestation and payouts publicly checkable Attestation alone is useless if no one can compare it against anything. Sui is where that comparison becomes a public, permanent, queryable fact instead of a claim the company makes on its own website. * **On-chain enclave registration** (`pinaivu::enclave` Move module, ported from the `suiverify` pattern): at every deploy, the coordinator submits its fresh NSM attestation on-chain. The contract checks the PCRs against a registered `EnclaveConfig`, and if they match, mints/updates an `Enclave` object holding the coordinator's current pubkey. This is the trust root — anyone, including a hostile auditor with zero access to Pinaivu's infrastructure, can independently rebuild the coordinator's source, get the same PCRs, and confirm the on-chain object reflects exactly that code. * Receipts are **BCS-encoded `IntentMessage`s**, signed in a format Sui's Move VM can verify natively (`enclave::verify_signature`). A client (or anyone) can call this on-chain function directly with a receipt and its signature and get a yes/no answer about authenticity — no API call to Pinaivu required at all. * The **vault** (`pinaivu::vault`) is the actual money, and it enforces the trust boundary at the contract level, not the application level: `settle()` requires a receipt whose signature verifies against the registered, attested enclave key. The **operator key** (which signs the Sui transaction, pays gas) is deliberately not the same key that authorizes a payout — operator key compromise alone cannot drain the vault, because the operator key has no spending authority by itself; only a valid enclave-signed receipt does. A `settled` table prevents replaying the same receipt twice. * **Refund path**: if settlement never happens, the contract allows the depositor to claw back escrowed funds after a deadline — so a coordinator that goes dark or stalls doesn't create a one-way trap for client funds. **What this buys**: the coordinator's signing key isn't trusted because Pinaivu-the-company vouches for it — it's trusted because Sui itself, a network Pinaivu doesn't control, will only release funds if the math checks out against a publicly auditable on-chain attestation record. `pinaivu::enclave`, `pinaivu::receipts`, `pinaivu::vault` — module-by-module *** ## 3. Walrus — making the coordinator's history impossible to quietly rewrite Signed receipts only matter if they actually persist somewhere nobody can edit after the fact. Walrus is **content-addressed decentralized storage**: a blob's identity *is* its content hash, so you can't silently edit history without the blob ID itself changing — and a changed ID immediately 404s instead of silently serving different bytes. Two separate uses of Walrus enforce this for two different kinds of history: ### Routing receipt archive Routing receipts are batched and archived (the explorer-indexer's cron job) into CBOR blobs uploaded to Walrus, with the resulting `walrus_blob_id` stamped back onto the database row. This has been verified empirically in this build: a blob was fetched independently from the Walrus aggregator, decoded, and confirmed to byte-match the original receipt — proving the audit trail survives even if Pinaivu's own Postgres/API went away entirely. ### Chat session continuity Session blobs (the node-side chat continuity layer, see [Memory layers](/architecture/memory-layers)) are encrypted, client-controlled conversation history, also stored on Walrus rather than a private database the operator could unilaterally read or alter — the node fetches, decrypts with a key only the client holds, and re-uploads after each turn, chaining blob IDs (`prev_blob_id`) so the conversation has tamper-evident lineage. **What this buys**: the system of record doesn't live inside a company's private infrastructure — it lives on a network with its own independent node operators, and content-addressing means edits are detectable, not just inconvenient. Both Walrus integrations in this project — the node's session blobs and the explorer-indexer's receipt archive — talk to Walrus over its plain HTTP publisher/aggregator API, with a filesystem-backed mock for local dev and tests. No Walrus SDK is required for either. *** ## 4. The node mesh — decentralizing the actual compute None of the above matters if the inference itself runs on Pinaivu's own hardware — that would just relocate the trust problem. It doesn't: * GPU nodes are **independent operators** running their own hardware, joining a public libp2p gossipsub mesh, bidding on auctions the coordinator broadcasts. Anyone can run a node — no permission from Pinaivu required beyond connecting to the mesh. * The coordinator **never runs inference** — it only brokers the auction and verifies the resulting proof. The actual compute, the actual model weights, the actual GPU — all of that is outside any single party's control. * Each completed job carries a `ProofOfInference` signed by the node's own key (self-derived from its libp2p peer ID, no registration needed) — so the receipt names which independent operator actually did the work, and that claim is independently verifiable without trusting the coordinator's word for it. *** ## Where the off-chain components are centralized — and why that's a separate question from verifiability Being precise about which claim applies to which layer matters more than overclaiming "decentralized" for everything. The coordinator and chat-relayer are **off-chain, single-instance, Nautilus-pattern components** — they are not decentralized today, and the docs shouldn't imply otherwise. What they are is **verifiable**: their code identity is attested by NSM, their signing key is registered on-chain, and every artefact they produce can be checked against that on-chain record by anyone, without asking Pinaivu for anything. That's a different — and for this stage, more achievable — property than decentralizing the broker role itself: * **One coordinator instance today, and one chat-relayer instance.** Both are off-chain Nitro Enclave services; the architecture supports verifying exactly which code is running in each, but there's currently one live instance of each, not N independent ones a client could choose between. A coordinator outage halts private inference even if no one can forge receipts during that outage. The GPU compute layer being routed to is genuinely decentralized; the off-chain component routing to it is not — it's verifiable instead, per the diagram at the top of this page. * **Settlement is currently a "free"/treasury model**, not per-request client escrow — Pinaivu pre-funds the vault rather than each client depositing per job. This is a real, intentional simplification for this stage, not yet the fully trust-minimized endpoint described in the on-chain design. * **The gateway and chat-relayer are trust boundaries too**, just not cryptographically attested ones yet across the board — chat-relayer runs in an enclave (Nautilus); the plain gateway doesn't. A compromised gateway could theoretically misroute or rate-limit unfairly, though it can't forge a receipt or drain the vault. * **`bid_set_hash`** exists in the receipt schema but isn't populated yet — meaning the "no silent bid filtering" guarantee (proving the coordinator didn't selectively hide higher bids) is designed for but not yet wired up. * **Node discovery and reputation are not yet decentralized governance** — there's no on-chain registry of trusted nodes; reputation is currently coordinator-tracked metadata, not a slashing-backed staking system. * **chat-relayer's per-user memory encryption key is relayer-held**, not user-wallet-derived — see the caveat in [Memory layers](/architecture/memory-layers#one-honest-caveat). *** ## The overall shape of the argument Pinaivu makes two separate claims, and keeps them separate on purpose: 1. **The GPU compute network is sufficiently decentralized.** Independent operators, open libp2p mesh, no permission required to join, no single party's hardware in the critical path. 2. **The off-chain components that broker access to that network — the coordinator and chat-relayer — are not decentralized, but they are verifiable.** No single party, including Pinaivu itself, can unilaterally fake what happened, redirect funds, or rewrite history, even though one coordinator process brokers each transaction in real time — because every artefact it signs is checkable against an on-chain record it cannot quietly alter. That second claim is what the rest of this page builds, layer by layer: * **Code trust** → Nitro Enclave attestation + reproducible builds (the Nautilus pattern) for the off-chain coordinator/chat-relayer components * **Identity/payout trust** → Sui's on-chain verification, independent of the operator's own infrastructure * **History trust** → Walrus's content-addressed storage, independent of the operator's own database * **Compute trust** → the open, genuinely decentralized libp2p GPU mesh, where the coordinator brokers but never executes Each layer removes one specific way the "trust the company" model could be abused, without requiring the broker role itself to be solved by a fully leaderless protocol — which, for a low-latency real-time auction, isn't a realistic constraint to impose in the first place. The honest summary: **decentralized compute, verifiable coordination.**