> ## 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. # Why Sui > Move, Nautilus, Walrus, and gasless settlement — why the on-chain layer is built on Sui specifically, not 'a chain' The on-chain layer described in [On-chain contracts](/architecture/onchain) and [Decentralization & verifiability model](/architecture/decentralization) isn't written against "EVM" or "a generic L1" and then deployed wherever — it's built against three Sui-specific primitives that don't have a drop-in equivalent elsewhere. Pinaivu uses all three together, and that combination is the actual reason Sui was the only realistic choice. ## The three pieces of the Sui stack Pinaivu depends on | Piece | What it is | What Pinaivu uses it for | | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Move** | Sui's resource-oriented smart contract language — assets are typed objects with linear-logic ownership, not balances in a mapping | `pinaivu::vault`'s `Balance` and `settled` dedupe table can't be double-spent or re-entered by construction; a `Coin` either exists once or it doesn't | | **Nautilus** | Sui's native framework for registering AWS Nitro Enclave attestations on-chain (`0x2::nitro_attestation`) and verifying enclave-signed payloads in the Move VM | This *is* `pinaivu::enclave` — `register_enclave`, `update_pcrs`, `verify_signature` are built directly on Sui's attestation primitive, not a custom oracle Pinaivu had to invent | | **Walrus** | Sui's affiliated decentralized blob storage network, with blob certification and lifecycle tied to Sui objects | The routing-receipt archive and chat session/memory blobs — see [Decentralization & verifiability model §3](/architecture/decentralization#3-walrus-making-the-coordinators-history-impossible-to-quietly-rewrite) | None of these are "a Sui port of a thing that exists elsewhere" — Nautilus attestation verification and Walrus's blob-to-object binding are specific to Sui's data model. Reproducing them on another chain would mean Pinaivu building and trusting its own attestation bridge and its own storage network, which defeats the point: the whole reason the coordinator and chat-relayer are *verifiable instead of trusted* is that Sui already gives anyone a way to check an NSM attestation against a public, on-chain record without asking Pinaivu for anything. ## Why settlement to node operators specifically needs Sui's object model Two properties of how Sui handles assets matter for paying GPU node operators, and neither is free on an account-balance chain: * **A payee needs zero SUI to receive a payout.** `pinaivu::vault::settle` transfers a `Coin` object directly to the payee's address. The coordinator's operator key pays the gas for that transaction — the node operator's address doesn't need to hold any gas token, exist on-chain beforehand, or sign anything to receive funds. On an account-balance model where every address needs a funded balance just to *exist* or to later move what it received, onboarding a new GPU node operator would require a funding step before their first payout even works. * **Settlement isn't pinned to a volatile gas token.** `Vault` is generic over the coin type — the same `settle()` logic works whether `T` is `0x2::sui::SUI` or a native stablecoin issued on Sui (e.g. USDC). A node operator can be paid in a stable asset for predictable earnings without Pinaivu needing a second settlement path; it's the same Move module, topped up with a different coin type via `top_up`. Put together: **gasless-for-the-payee, stable-denominated settlement** is a consequence of Move's object model plus Sui's native stablecoin support — it isn't a feature Pinaivu had to build on top of the chain, it's what falls out of using `Coin` objects instead of balance entries. This describes the settlement mechanism's *capability*, not a claim that every node operator is being paid in a stablecoin today — which coin type funds a given `Vault` is an operational choice made at `new_vault` / `top_up` time. See [On-chain contracts](/architecture/onchain#pinaivuvault). ## The shape of the dependency ``` Move → typed, linear-logic assets: settle() can't double-pay or be replayed Nautilus → on-chain attestation registry: coordinator/chat-relayer are checkable, not trusted (the "verifiable" half of the decentralized/verifiable split) Walrus → decentralized, content-addressed storage tied to the same ecosystem's object model Sui's Coin → gasless payouts to node operators, in whatever coin type (including stable assets) the vault is funded with ``` Each of these is doing a specific job none of the others can substitute for — which is why Pinaivu's on-chain layer is "built on Sui" rather than "built on a blockchain that happens to be Sui." `pinaivu::enclave`, `receipts`, `vault` — the Move side of this page Where Nautilus and Walrus fit into the bigger trust picture