Introduction

Solana settles state at the speed of its validators. But reading that state — balances, accounts, blocks, transactions, token holders — is a separate problem with its own failure modes: stale reads, silent fork lag, opaque infrastructure, and no way to prove that the answer you got was actually fresh. Pluid exists to make reads first-class.

Pluid is a decentralized, geo-distributed read-RPC mesh and block explorer. Every node in the mesh stakes to serve reads, every answer is anchored to the slot it was observed at, and every response ships with a signed proof-of-serve receipt you can verify independently — without trusting Pluid at all.

The Read-Layer Thesis

The chain has a strong story for writes: leaders produce blocks, the cluster votes, finality is measurable. Reads have none of that. When you call an RPC endpoint, you are trusting an unaudited box to tell you the truth about chain state, at an unknown slot, with no signature and no recourse. The read path is where most application bugs, MEV surprises, and “why is my balance wrong” tickets actually live.

Pluid treats the read path as infrastructure worth verifying. Three commitments define the layer:

• Freshness is explicit. Every read carries the slot it was resolved at, so staleness is observable instead of assumed.
• Answers are signed. Each response includes an ed25519 receipt over a canonical digest of the query and the answer. You can verify it offline.
• The mesh is open. Reads are served by an independent, staked node mesh — not a single trusted provider — and anyone can run a node.

Mesh + Receipts

A request hits the nearest healthy node in the Pluid mesh. The node resolves the read against chain state, stamps it with the observed slot, and signs a receipt. The receipt is the product: it lets a wallet, an indexer, or a counterparty confirm that a specific answer was served at a specific slot by a key the network recognizes.

{
  "result": { "lamports": 4198320512, "slot": 296410233 },
  "slot": 296410233,
  "receipt": {
    "query": "getBalance:5tz...9aF",
    "answerDigest": "9f1c…ab",
    "slot": 296410233,
    "issuedAt": 1718900000000,
    "sig": "7c0a…ff"
  }
}

Because the receipt is signed over a deterministic, key-sorted JSON encoding, the verifier recomputes the exact same bytes and checks the signature against Pluid’s published public key. No network round-trip, no trust in the responder. See Receipts & Proof-of-Serve for the full scheme.

What You Can Build

• Wallets and portfolio views that prove the freshness of every balance they show.
• Indexers and bots that attach receipts to the reads driving their decisions.
• Explorers and dashboards over slots, epochs, blocks, transactions, and token holders.
• Realtime UIs subscribed to the global stats stream over Socket.IO.

Where to Go Next

• Quickstart — install the SDK, make your first read, verify a receipt.
• REST API Reference — every /api/v1 route with params, responses, and curl examples.
• Receipts & Proof-of-Serve — the verification scheme in full.