About Pocket Network

Pocket Network is an open, decentralized network for data services. Developers publish an API as a service, independent operators serve it, and AI agents, MCP clients, and apps pay for every request they make. The network meters each request and pays for it on-chain.

A service can be anything that answers an HTTP request with JSON: a market data feed, a public-records lookup, a search or document tool, LLM inference, an MCP server, or a blockchain’s RPC. Blockchain RPC is where Pocket started and is still served, free, through the Foundation’s public endpoints. It is now one kind of service among many.

There are no gatekeepers on the protocol. Anyone can publish a service, anyone can serve one, and anyone can call one.

The Problem

Data that software needs usually sits behind a single provider. Every source means another account, another API key, and another billing relationship, and every one of them is a point of failure: when that provider goes down, everything depending on it goes down too.

AI agents make this worse. An agent cannot fill in a sign-up form or manage a subscription, and wiring up each data source by hand does not scale. And the developers who build useful data services have no simple way to get paid for them without building billing, keys, and customer management themselves.

How Pocket Solves It

Pocket Network is a marketplace that matches Applications (who need data) with Suppliers (who run the services). A Gateway layer routes each request to a good Supplier automatically, and portals such as the Agentic Portal put services in front of agents that pay per call.

Here’s what happens when a request goes through Pocket:

1. The request reaches a gateway, directly or through a portal
2. The gateway looks up which Suppliers are serving that service in the current session
3. Its quality system picks a Supplier based on latency, reliability, and correctness
4. The request is forwarded to that Supplier’s service
5. The response comes back through the same path
6. Behind the scenes, the Supplier and the service’s owner are paid for the work

This all happens transparently. From the caller’s perspective, it’s just a normal API endpoint.

Why It Matters

Build once, earn on every request. Whoever registers a service sets its price in compute units and earns a share of every settled request on it, no matter which Supplier served it. There is no billing system to build and no customer to invoice. See Services.

No accounts or API keys for agents. On the Agentic Portal, payment is the credential: agents pay per call and never sign up for anything. See Agent Services.

No single point of failure. Many independent operators can serve the same service, and gateways route around any that go offline or answer badly. The network is self-healing: when servers fail, requests go elsewhere.

Fully permissionless. Anyone can register a service on-chain. Anyone can run a Supplier. There is no allowlist and no approval process on the protocol. Portals curate what they list; the network itself does not.

Privacy-preserving. Pocket does not store personally identifiable information. The only information recorded is request origin and destination.

The protocol is completely on-chain. Every relay is metered on-chain, every settlement is public, and every economic parameter is a governance value anyone can query. POKT’s supply is deflationary, and that is verifiable on-chain too.

Stable pricing. Compute units have a fixed dollar value, so a service’s price stays stable in dollars even when POKT moves.

The Four Actors

How It Works: The Relay Lifecycle

Every piece of data served through Pocket Network follows the same cycle — from request to verified payment, without trusting any single party.

1. Session Assignment

The protocol assigns Suppliers to Applications in time-bounded windows called sessions. Given an Application, a service (like eth), and a block height, every node on the network independently calculates the exact same assignment. There is no central scheduler — the math is deterministic and manipulation-resistant.

2. Relay Serving

During a session, the Application sends data requests (relays) through a Gateway, which routes them to assigned Suppliers. A relay is a data request served through the protocol — it can be a call to a data API, an LLM inference request, or a blockchain query (“What’s this wallet’s balance?”), whatever the service registered on-chain provides. The Supplier’s RelayMiner queries its backend service and returns the answer.

3. Claim Submission

After the session window closes, each Supplier submits a claim — an on-chain statement declaring how many relays they served. Think of it like a timesheet: “I served 50,000 relays for eth during session #12345.”

4. Proof Verification

The protocol doesn’t trust claims at face value. It requires each Supplier to submit a proof — cryptographic evidence that the work actually happened. Pocket uses a technique called probabilistic proofs: the protocol randomly selects specific relays from the session and the Supplier must prove those particular relays were served correctly. If the sample checks out, the full claim is accepted.

5. Settlement

Once the proof is validated, the protocol settles the claim:

1. Burn: POKT is burned from the Application’s stake (proportional to the compute units consumed)
2. Mint: New POKT is minted — the mint ratio (currently 0.975) sets what fraction of burned POKT is re-minted; the remainder is permanent PIP-41 deflation
3. Distribute: The minted POKT is split among participants:

The Economic Loop

This creates a self-sustaining cycle:

Applications burn POKT → Suppliers earn POKT → more Suppliers join → better service → more Applications use the network → more POKT burned

The more the network is used, the more POKT is burned. With PIP-41’s deflation, total supply decreases over time as usage grows — aligning everyone’s incentives with network adoption.

Compute Units: How Work Is Priced

Not all relays are equal. A simple lookup is cheaper than an LLM completion. Pocket uses compute units (CUs) to measure work, and a governance-controlled exchange rate converts CUs to POKT.

The chain: Relays served → Compute units consumed → uPOKT burned/minted → POKT distributed

Each service’s owner sets its price in CUs per relay when registering it. Compute units have a fixed dollar value, so prices stay stable in dollars.

Key Concepts

• Relay — a single request-response served through the protocol, to any service on the network.
• POKT — the native token. Applications burn it to consume relays, Suppliers earn it for serving them, and it is mildly deflationary over time.
• Session — the time-bounded window that assigns a set of Suppliers to a specific Application, computed deterministically from on-chain state rather than stored.
• Claims & Proofs — the mechanism Suppliers use to prove the work they did before the protocol settles payment.

The Shannon Protocol

Pocket’s current protocol is Shannon, named after Claude Shannon, the father of information theory. It replaced the original Morse protocol and introduced relay mining, Token Logic Modules, and a modular architecture built to scale. For the technical architecture, see Shannon Architecture; for the Morse → Shannon migration history, see Shannon Upgrade.

Next Steps

• Service developers: Services — publish your API and get paid for every request
• Agent builders: Agent Services — call services per request, with no accounts or keys
• Blockchain RPC: Developers — free public endpoints, in 30 seconds
• Token holders: Token & Staking — understand POKT and staking options
• Node operators: Node Operators — run infrastructure and earn POKT
• Go deeper: Sessions, Claims & Proofs — the technical detail behind the relay lifecycle
• Tokenomics: POKT Tokenomics — the full economic model