Services

A service is any API that can be reached through Pocket Network. Blockchain RPC endpoints are the best-known examples, but a service can be anything that answers an HTTP request: an LLM inference endpoint, an embeddings model, a data aggregator, a rendering API, an MCP server. Pocket does not care what the service does. It cares that a request was signed by a paying application, that a staked supplier answered it, and that the supplier can prove it did.

Every service registered on the network is listed at explorer.pocket.network/services.

Services Are Permissionless

Anyone can register a service, and anyone can supply one. There is no allowlist, no review, and no foundation approval step. Registering costs a one-time fee, supplying requires a stake, and both are governed by on-chain parameters rather than by people. A service with one supplier and a service with two hundred are the same kind of object on-chain.

The consequence is that quality is decided by the market, not by the protocol. Gateways score suppliers on the responses they return, applications choose which gateways and services to use, and a service that is badly specified or badly served simply attracts no traffic. The guides in this section exist so a service you register is specified and served well from the first relay.

How the Pieces Fit Together

Six pieces are involved in every relay. Three are on-chain records, two are running software, and a gateway is both.

The flow of a single relay:

client ──► gateway (or a self-signing application)
               │  finds the current session for (application, service)
               │  picks one of the session's suppliers
               │  signs the request with the application's key
               ▼
        supplier's RelayMiner ──► service backend
               │  verifies the signature and session
               │  forwards the request as plain HTTP
               │  signs the backend's response
               │  records the relay for its claim
               ▼
        gateway ──► client

Sessions are the unit of accounting. Every 20 blocks the protocol deterministically assigns a set of suppliers to each (application, service) pair. The RelayMiner batches the relays it served during a session into a claim, submits it, and is paid from the application’s stake when the claim settles. The service owner receives 2.5% of each settlement too, which is the economic reason to register a service well rather than just to register it.

Two Roles, Usually One Person at First

Registering a service and supplying a service are separate acts with separate on-chain records.

• The service owner registers the service ID, sets its price, and publishes the metadata card that tells everyone else how to call it and how to serve it. This is a one-time act plus occasional updates. The owner does not need to run anything.
• A supplier stakes on the service and runs a backend plus a RelayMiner. Suppliers are what make a service reachable. Without at least one supplier, a registered service exists on-chain and serves nothing.

When you bring a new service to the network you will almost always do both: register the service, then become its first supplier. Once the service has traffic, other operators can stake on it independently by reading the card you published.

What Makes a Service Work Well Behind Gateways

The protocol enforces nothing about the shape of a request or a response; a RelayMiner signs whatever bytes the backend returns. Gateways, which carry almost all of the network’s traffic, enforce more, because they grade every response to decide which suppliers to trust. If a service returns responses a gateway cannot grade, the gateway marks the suppliers serving it as failing even though they answered correctly, and a service that gets its own suppliers penalized is one nobody will keep supplying.

The rules that matter are covered in Deploy a Service, but the short version is:

• Every response is a JSON object. HTML, CSV, images, or any other non-JSON output travels as a string field inside that object.
• All inputs arrive in the request body. Gateways do not forward the caller’s headers, so nothing can depend on them.
• Client errors are 4xx with a JSON body. Server errors are 5xx and are never paid.
• The service has a metadata card that describes the API accurately, including health checks a supplier can run before staking. Cards are how services will be discovered on the network, including by the agentic portal, and a service without one will not be found.

Where to Go Next

• Register a Service — create the on-chain service record, choose its price, and publish its metadata card
• Deploy a Service — build a backend that works well behind a RelayMiner, stake a supplier, run the RelayMiner, and test end to end
• Supplier Staking — the owner-operator model and the full stake configuration reference
• Application Staking — how the paying side of a relay works
• Gateway Operators — the access layer most users reach services through