NexFlow › Library › Pocket Network explained

Pocket Network — the decentralized RPC layer, explained

Pocket is a bet that RPC access should not be a three-company market: a protocol where staked node operators relay RPC reads for dozens of chains and get paid per relay in POKT. This is how the relay economy actually works, where it's honest, and what running a node on it looks like.

Infra explainer · updated September 2026 · not financial advice

Every decentralized application has the same central dependency: a small set of companies runs the RPC endpoints that wallets and backends actually call. Pocket Network exists to make that layer a protocol instead of a vendor — applications buy relay throughput, independent node runners sell it, and the network clears the two sides with POKT. In the current Shannon design the pieces are applications (which stake POKT for relay budgets through gateways), suppliers/servicers (staked nodes that carry the actual relays across dozens of chain dialects), and the protocol layer that meters, verifies and pays for work — including probabilistic relay mining that estimates served volume without having to log every request on-chain.

The claim worth taking seriously is structural: instead of trusting one endpoint operator to be honest and upright, you trust a market — many operators, random assignment, payments proportional to measured work. Whether that market beats a reputable provider on latency and consistency is a real engineering question, not a slam dunk, and honest answers differ by chain and by time of day.

How a relay actually flows

An app (usually via a gateway — the shim that makes Pocket look like a normal RPC URL) sends a standard JSON-RPC call for a chain Pocket supports. The protocol assigns it to servicers staked for that chain; the servicer's own backend node answers, the response travels back, and the relay gets counted toward the servicer's mined-work estimate. Payment is minted POKT per relay — issuance, not fees — which is exactly why the economics depend on POKT's price and the chain's emission schedule rather than on a stable per-call USD rate.

Compared to a provider like our own /rpc lanes — which are operated upstreams with a stated free/paid split — Pocket's promise is censorship-resistance and operator diversity. Compared to running your own node, it trades ops burden for protocol risk: you stop babysitting hardware and start depending on relay-mining rules and the market's servicer depth for the chain you need.

What a node runner signs up for

A Pocket servicer stakes POKT, runs a node for the chains it wants to serve, and earns from relay mining. The honest cost ledger: POKT stake at risk per the protocol's slashing rules, real hardware or VPS spend scaled to the chains you serve (each chain you relay is another backend to keep synced), and an ops loop that rewards uptime — relays you can't serve are relays you don't get paid for. The income side is minted POKT against your measured relay share, so the economics are a volume business, not a flat rent.

The catch is the obvious one for anyone who's run nodes: serving many chains means tracking many chains. Each supported chain is a synced backend, an upgrade cadence, and a failure surface. Operators that claim "50 chains, one node" are describing the configuration file, not the maintenance bill — each line in that file is a sync to babysit and an upgrade window to catch.

A note on the marketplace, honestly stated

Pocket's two-sided market has the classic cold-start property: servicers go where relays are, apps go where servicers are, and a thin chain on Pocket is thin the way a small exchange's order book is thin — the protocol cannot conjure coverage. The Shannon rebuild attacked exactly that with relay mining that makes servicer pay legible, but legibility doesn't create demand. The practical read for a builder: check the chain list and current servicer depth for the network you actually need before designing around the lane, the same way you'd check a provider's status page before designing around ours. Neither model removes the need to watch the lane you depend on — they just move which dial you watch.

Where the decentralized-RPC model is genuinely better

Censorship and single-operator risk. An app pointed at a gateway draws relays from many operators; one operator going hostile or offline degrades the pool, not your app. This is the real answer to "the endpoint is a trusted lens" — your lens keeps changing hands.

Long-tail chain coverage. Pocket serves dozens of chains, including ones no major provider bothers to list — if your chain's public RPC is a weekend hobby server, a relay market with staked suppliers is often the more reliable free-ish path.

Aligned incentives on data integrity. Servicers get paid per verified relay; the protocol samples and scores work rather than trusting operator self-reports. That is not the same as "trustless truth" — an adversarial supermajority could still coordinate — but it's a different threat model than one company's SLA page, and for many builders a strictly better one.

Where it isn't

Latency consistency. A market of operators has a wider latency distribution than one tuned fleet; the tail of slow relays is what apps actually feel. Gateways exist partly to manage that distribution — which reintroduces a choke point you should price in.

Pricing in a volatile token. Relay rewards are POKT-denominated; servicer economics float with the token, and the emission schedule decides whether running a node is income or a donation. Anyone modeling "APY" from relays should date-stamp the assumption and revisit monthly.

Verification limits. Relay-mining measures that work happened, not that the data was right — correctness still leans on cross-checking, the same discipline we recommend for any endpoint: verify critical reads against a second source, whether that's an explorer, a second provider, or our own free relay lanes. The operator set changing under you does not change what a wrong answer costs.

Frequently asked