RPC providers: how an application reads a blockchain

JSON-RPC is a stateless protocol that encodes a request and a response as JSON, and the calls an application makes are narrow in number and uneven in cost. Reading the chain head with a call such as eth_blockNumber is cheap. Reading a balance or a contract's current state is cheap. Submitting a signed transaction is cheap for the node and consequential for the user.

The expensive one is the log query. Asking for all events matching a filter across a wide block range makes the node scan, and that is the call a provider restricts first, by block range, by result count or by refusing it outright on a free tier. The second expensive family is the subscription: a WebSocket subscription to new blocks or to matching events is how an application learns about something without polling, and a free endpoint often does not offer it. An application designed against those two limits looks completely different from one that was not, which is why the endpoint decision belongs at the start of a project.

A public endpoint, the one printed in a chain's documentation or offered by an explorer, is free, shared and owed to nobody. Rate limits on free and shared tiers typically sit in the tens of requests per second, the endpoint can be deprecated or changed without notice, and the operator sees every query. It is right for a prototype and wrong for anything a firm answers for.

A hosted provider sells a shared or a dedicated endpoint with a service level, archive access without the storage cost, WebSocket subscriptions and routing across several data centers so a request lands near the application. The rule of thumb in the market is that an application above roughly ten thousand requests per second belongs on dedicated infrastructure. An own node gives correctness the firm verified itself and queries no one else sees, at the operational cost the blockchain node infrastructure page sets out. Most firms end up with a dedicated provider plus an own node for the queries that matter.

A full node keeps only the recent state, on Ethereum the last 128 blocks by default, because older state is not needed to validate new blocks. Any question about the past, a balance at a date, a contract's state before an upgrade, an event from last year, needs an archive node that kept it all.

That is why archive access is priced separately or confined to higher tiers: the node behind it runs from about two terabytes with a storage-efficient client up to twelve terabytes and more, and it grows. For a financial firm the relevant point is that the questions auditors ask are exactly the historical ones. A valuation as at a reporting date, a holding at a year end, a transaction history for a tax filing are all archive queries, so a firm whose endpoint cannot answer them has a reporting problem and not a technical preference.

This is the part of the subject that gets least attention and matters most to a regulated firm. An RPC provider sits between the application and the network, so it can decline to relay a transaction, and the large providers do: leading centralized providers filter transactions involving addresses on the US OFAC sanctions list, and some providers exclude entire countries from access. Vitalik Buterin has warned that a market concentrated in a few RPC providers faces strong pressure to deplatform or censor users.

For a European firm that cuts two ways and both belong in the risk file. Sanctions screening the firm must do itself anyway, so a provider that filters is not doing it harm on that axis. But a provider that applies one jurisdiction's list to a European firm's traffic is imposing a policy the firm did not choose and cannot see, and a transaction silently not relayed is an operational failure that looks like a network problem. The second exposure is informational: every query tells the provider which addresses the firm is interested in, which for an asset manager is position data, and a provider that sees pending transactions can also act on their ordering.

Two endpoints from two providers is the obvious answer and it is harder than it sounds, because the failure that matters is not an endpoint returning an error. An endpoint that answers from a node several blocks behind the chain head returns a valid response with stale data, and an application that checks only for HTTP errors accepts it.

Working failover therefore means the application compares the block height in a response against what it expects, treats a lagging endpoint as failed, and routes to the second provider. It also means the second provider is tested under load before it is needed, and that the firm knows which of its queries the fallback cannot serve, typically the archive and subscription ones. A fallback that has never carried production traffic is a plan and not a control.

A regulated firm that depends on an RPC provider for a function that matters has an ICT third-party arrangement, and the duties follow from that fact and not from the size of the invoice. The arrangement goes in the register of information with the function it supports and whether that function is critical or important, the contract needs the audit, access and exit provisions DORA expects, and the firm needs a tested answer to the provider disappearing.

The awkward part is that the market's standard terms were not written for this. A self-service signup with a credit card is not a contract that gives a supervisor audit rights, and a firm whose chain access runs on such a signup has a documentation gap, not a technical one. The DORA regulation in Germany page covers the German supervision, and digital operational resilience in Europe the European frame.

Only by running the node yourself, which replaces the provider with your own operations team. There is no third option: something has to hold a copy of the chain and answer queries against it, and either the firm operates that or somebody else does. The useful framing is therefore not whether to depend on a provider but which dependency the firm can document and recover from, and most firms conclude that an own node for the accountable queries plus a provider for breadth is the combination they can defend.

Six questions, and the answers belong in the contract. Whether the endpoint is dedicated or shared. Whether archive queries are included and to which depth. Which rate limits apply per method, because the log query is the one that breaks. Whether the provider filters transactions and against which lists. Where the nodes are hosted and under which jurisdiction. And what the provider commits to on how far behind the chain head its nodes may fall, which is the service level that actually matters and the one least often offered.