Mapping the RPC Landscape​

A framework for understanding how RPC providers, federations, proxies, and aggregators differ

Crypto RPC markets are compute commodity markets in disguise. Before unpacking that fully, it helps to understand the ecosystem of entities that provide RPC access — because despite looking similar on the surface, each category operates very differently, and the implications for reliability, pricing, and performance are significant.

Why RPC Markets Are Compute Commodity Markets

At the lowest level, RPC calls are requests for computation. A node receives data (block numbers, addresses, transaction hashes), processes it according to a protocol specification, and returns the result. The computational cost is real — CPU, memory, disk I/O — but it is commoditized in the same way that cloud computing is commoditized.

What makes RPC markets distinct is that the commodity is not generic compute, but *correct* compute. Returning incorrect data from a blockchain node has asymmetric consequences: the caller may execute transactions based on false state, make decisions on corrupted data, or lose capital. This asymmetry means that the market does not just optimize for price and speed — it must also optimize for accuracy, which introduces structural complexity.

The variances in how different entities provide RPC access come down to several key factors:

- **Price** — the cost per request

- **Rate limits and capacity** — how much unexpected load the system can absorb

- **Data quality** — the frequency with which correct vs. incorrect data is returned

- **Latency** — how performant the node is when called

- **Geography** — the physical location of the node relative to the caller

- **Availability** — whether the provider supports the chain and methods you need (archive calls, in particular, are challenging)

As a result of these variances, three (actually four) major categories of RPC entities have emerged.

RPC Providers

Providers are the entities that buy, manage, and orchestrate their own inventory of nodes. They own the hardware, run the node software, and make the nodes accessible via JSON-RPC interfaces.

**Key characteristics:**

- Own and operate their own node infrastructure

- Direct control over node configuration and maintenance

- Pricing is typically volume-based, with enterprise tiers

- Limited by their own infrastructure geography and capacity

**Examples:** Alchemy, Quicknode, Chainstack, and many others.

Providers offer simplicity — one integration point, one support channel, one pricing structure. But they are limited by their own infrastructure. If a provider does not run nodes for a particular chain, or if their nodes in a particular region are underperforming, the caller has no way to access better alternatives through that provider.

RPC Federations

Federations are networks that allow independent node operators to contribute their nodes to a shared pool. Members join the federation, and the federation routes requests across its members.

**Key characteristics:**

- Operate a shared network rather than owned infrastructure

- Members contribute their nodes; the federation manages routing

- Often positioned as community-driven or open alternatives

- May have governance structures involving members

**Examples:** dRPC, Pocket Network, Infura DIN, Lava Network

Federations offer geographic distribution without requiring central infrastructure investment. However, the quality of nodes in a federation depends on the incentives and standards enforced by the federation operator. There is a fundamental tension: if membership is too open, quality varies; if too restrictive, the federation's scale advantage diminishes.

RPC Proxies

Proxies are software layers that sit between the caller and RPC providers. They dynamically route requests to whichever provider is best suited for a given request, based on configuration.

**Key characteristics:**

- Software-defined routing logic

- Caller maintains control over provider configuration

- Can combine multiple providers in a single deployment

- Require operational overhead to manage and tune

**Examples:** eRPC, Lava Network (proxy functionality)

Proxies and aggregators are not mutually exclusive. A client can run proxy software client-side while connecting to providers or federations. The proxy gives the caller flexibility but puts the complexity of multi-provider management on the caller.

RPC Aggregators

Aggregators operate very differently from providers, federations, and proxies. An aggregator does not run nodes. It does not have members. Instead, it sits on top of the largest inventory of nodes globally and routes every request to the best underlying provider based on real-time performance data.

**Key characteristics:**

- No owned infrastructure; purely a routing layer

- Dynamic, real-time selection of the best provider per request

- Pricing is adjusted based on the underlying provider cost plus margin

- Requires extensive infrastructure to measure and evaluate provider performance continuously

**Examples:** RouteMesh

Aggregators offer the lowest prices and latencies for consumers because millions of pathways are evaluated for each request. Despite adding their own margin, aggregators still achieve lower effective costs because they select the optimal provider for each specific chain, method, and latency requirement.

Trends

The diagrams above show nodes at the end of the chain, but what happens between the caller and the node has many nuances. The trends shaping the RPC landscape are moving toward increased abstraction:

**Nodes are becoming a commodity** — the hardware and software for running nodes are increasingly accessible. The value is no longer in running a node, but in knowing which node to use for which request.

**Routing intelligence is becoming the differentiator** — as nodes become more commoditized, the competitive advantage shifts to entities that can intelligently route requests based on performance data, latency measurements, and cost optimization.

**The architecture is maturing** — just as the internet developed layers of technical abstraction (TCP/IP, DNS, CDNs), crypto is developing similar layers of RPC abstraction. The nodes remain essential, but the routing and selection layers become where value is concentrated.

Choosing the Right Category

The question is not which category is "best" — it depends on your requirements:

- **If you need simplicity and single-vendor support** — a provider works well for applications with limited chain/method coverage and tolerance for higher latency or cost.

- **If you want community-driven infrastructure** — a federation offers geographic distribution with a shared ownership model.

- **If you need full control over routing** — a proxy gives you flexibility but requires operational overhead.

- **If you need maximum reliability and cost efficiency** — an aggregator evaluates millions of pathways per request, selecting the optimal provider for each specific need.

The landscape is evolving, and the entities that thrive will be those that best solve the fundamental problem: delivering correct, fast, affordable data to every caller, on every chain, at every moment.