Multi-Chain RPC in 2026: Node Providers vs Gateway Layers

Search for a free multi-chain RPC and you get two fundamentally different products described in nearly identical language. One operates blockchain nodes and sells you metered access to them. The other operates no nodes at all and sits between your application and whichever endpoints you already have. Both call themselves RPC providers. Choosing the wrong one costs you a sprint, because the gap only becomes obvious once you are integrating.

The distinction is not academic. It determines what “free” means, what happens when you hit a ceiling, and whether adding the product removes a dependency or adds a layer on top of one. Get it right and the two categories compose well. Get it wrong and you have adopted something that cannot do the job you adopted it for.

• A node provider runs the infrastructure. Your ceiling is their plan, and outgrowing it means paying more or adding a second provider.
• A gateway layer runs no nodes. It consolidates authentication, routing, failover and caching across the endpoints you supply.
• “Free” on a node provider means a metered allowance. “Free” on a gateway means the layer itself is free while your upstream costs continue.
• Most production multi-chain stacks eventually want both, because they solve different problems.

Two Products, One Category Name

The confusion is understandable. Both categories expose a URL that speaks JSON-RPC, both support many chains, and both advertise reliability. From your client code they look identical: you point an HTTP transport at an endpoint and send a request.

The difference is what is behind that URL. With a node provider there is a fleet of blockchain nodes they built, run and pay for. With a gateway there is routing logic, and behind that, endpoints that you configured — which usually belong to a node provider.

One diagnostic question settles it quickly: if this product disappeared tomorrow, would I lose access to chain data, or would I lose the layer that manages access? A node provider’s disappearance means you need new nodes. A gateway’s disappearance means your application talks to its upstreams directly, with less resilience but the same data.

What a Node Provider Sells

Alchemy, QuickNode, Chainstack, dRPC and Tenderly all operate in this category, along with Ankr, Infura and the various public endpoint services. Their product is capacity: synchronized nodes across many chains, kept online, with archive depth and enabled namespaces varying by plan.

Their pricing reflects that they own the cost. Metering is usually in compute units, credits or flat request counts, weighted so that expensive methods consume more of your allowance. A free tier is a genuine allowance of that capacity, sized for development, and it ends when you exceed it.

What you are actually buying is method coverage and depth. Whether debug_traceTransaction works, how far back archive queries reach, and which namespaces are enabled are all decided at this layer. No amount of routing intelligence above it can add a method the underlying node does not implement.

What a Gateway Layer Sells

A gateway sits between your application and your endpoints. It handles authentication in one place, selects among endpoints, retries and fails over on transport failures, applies circuit breaking to endpoints that are failing consistently, and can cache responses so repeated reads never reach an upstream at all.

What it does not do is operate nodes. It cannot serve data your upstreams cannot serve, cannot extend archive depth, and cannot enable a namespace your provider disabled. A gateway improves how you reach capacity. It does not create capacity.

Aurpay’s RPC Gateway is a current example, and its documentation is unusually direct about this boundary, which makes it a useful reference for the category. It covers 20 chain and network combinations across Ethereum, Polygon, BNB Smart Chain, Arbitrum, Optimism, Base, Solana, Bitcoin, Litecoin and TRON behind one App API Key, and it is free and open source under Apache-2.0.

It also ships a shared cache, called Accelerator, which can answer a request with no upstream call at all. That capability is deliberately narrow: it serves an explicit list of ten method and parameter shapes, including eth_blockNumber, eth_getBlockByNumber at an explicit hex height, the Solana slot and block reads, and the Bitcoin and Litecoin block reads. Everything outside that list, and every cache miss, needs an endpoint you configured. The documentation states plainly that this is a cache-hit capability rather than a public endpoint, and that the gateway will not query some public node on your behalf when the cache misses.

That constraint is the honest shape of the category. A gateway that claimed to serve arbitrary methods for free would be a node provider wearing a different label, and would have the cost structure to match.

Why “Free” Means Two Different Things

On a node provider, free is an allowance. Someone is paying for synchronized nodes across a dozen chains, and the free tier is a sampling of that capacity sized for development. It ends predictably, and when it does your options are to pay, to reduce usage, or to spread load across several providers’ free tiers. That works, but leaves you managing several keys and several failure modes.

On a gateway, free means the layer costs nothing while your upstream costs continue unchanged. Adopting one does not reduce your provider bill on day one. It reduces it to the extent that caching removes duplicate reads, and it makes multi-provider setups practical enough that spreading load stops being a maintenance burden.

This is why comparing a gateway’s free tier against a node provider’s free tier produces a meaningless number. They are not the same unit. The useful question is what each layer removes from your operational surface, which we work through in comparing RPC node providers on metering and coverage.

Which One You Actually Need

For prototyping on a single chain, a node provider’s free tier alone. A gateway adds configuration you do not need yet, and the reliability problems it solves have not appeared. Point your client at one endpoint and build.

For production on one or two chains with modest traffic, a node provider plus application-level caching. You will hit duplicate-read waste long before you hit reliability problems, and caching in your own code is cheaper than a new layer. The techniques in cutting RPC costs with response caching apply directly.

For production across several chains, or anywhere an outage has real consequences, the gateway earns its place. The tipping point is usually one of three things: you are managing more than three or four endpoint credentials across environments, you have written retry and failover logic in more than one service, or you have had an incident where a provider degraded and traffic kept going to it. The second is the strongest signal — retry logic reimplemented per service is reimplemented inconsistently, and the differences surface during incidents. That failure mode is covered in RPC failover and circuit breaking.

For teams already at scale with dedicated nodes, the gateway is about consolidation rather than reliability. One key, one calling convention and one place where routing policy lives is worth something once several teams are calling the same infrastructure.

Running the Gateway Layer Yourself

Because a gateway operates no nodes, self-hosting one is far more tractable than running blockchain infrastructure. You are deploying a stateless proxy with some shared state for health and circuit tracking, not synchronizing chains and managing terabytes of storage.

That is why open source matters more in this category than in node provision. The Aurpay gateway is Apache-2.0 licensed with the source public, so the routing behavior can be audited and the layer can be run on your own infrastructure. If your constraint is that requests must not transit a third party, this is the version of the category that can satisfy it — an option that does not exist when the product is the nodes themselves.

The trade-off is the usual one. Self-hosting means you own the uptime of the layer that was supposed to improve your uptime, which is only a good trade when you already run infrastructure competently. The repository is new, published in August 2026, so treat it as something to evaluate rather than something with years of production history behind it.

A Reference Stack

A multi-chain application that has outgrown a single free tier usually converges on the same shape. Two node providers per chain, chosen so their failure modes are not correlated, both configured as endpoints on a gateway route. Weighted load balancing across them, with a small weight on the secondary so its health observations stay current rather than going stale from disuse.

Caching sits in front of the routing layer, so repeated reads consume no attempt budget and are unaffected by upstream outages. Transaction submission uses a separate route with priority ordering and a stricter retry policy, because a timed-out write must not be retried the way a read can. Application-level checks handle what no routing layer can see: whether the data returned is fresh enough for the decision being made.

Nothing in that stack requires the gateway and the providers to come from the same vendor, and they generally should not. The layers are separable on purpose.

Frequently Asked Questions

Is an RPC gateway a replacement for Alchemy or QuickNode?

No. A gateway operates no nodes and cannot serve data your upstreams cannot serve. It sits in front of providers like those and manages authentication, routing, failover and caching. If you remove your node provider and keep only a gateway, most methods stop working.

What does a free RPC gateway actually cost me?

The layer itself is free, but your upstream provider costs continue. The savings come from caching removing duplicate reads and from being able to spread traffic across several providers’ allowances without maintaining that logic yourself. Expect a reduction in provider spend, not its elimination.

Can I use a gateway with no endpoint configured at all?

Only for whatever narrow set of cached reads it supports, and only when the cache actually holds the answer. On the Aurpay gateway that is ten specific method and parameter shapes, and a miss returns error code -32004 rather than falling through to a public node. Treat endpoint-free operation as a convenience for a first call, not as an architecture.

Do I need a gateway if I only use one chain?

Usually not at first. Single-chain applications get more benefit from application-level caching and a sensible retry loop. The gateway becomes worthwhile when you are managing several endpoints, several environments, or have duplicated failover logic across services.

Does adding a gateway increase latency?

It adds a hop, so on a cache miss you pay a small amount of additional latency. On a cache hit you save the entire upstream round trip, which is a much larger number. Whether the net is positive depends on your hit rate, which is why measuring per method matters.

Which category should I evaluate first?

The node provider, always. Method coverage and archive depth are decided there, and no gateway can compensate for a provider that does not serve what you need. Once coverage is settled, the gateway question becomes about reliability and consolidation.

Pick the Layer That Matches the Problem

If your problem is access to chain data, you need a node provider, and the comparison is about method coverage, archive depth and metering. If your problem is managing access — several endpoints, several environments, retry logic duplicated across services, or an incident where traffic kept flowing to a degraded upstream — you need a gateway, and no amount of provider shopping will fix it.

Most teams building across several chains eventually run both. If you want to evaluate the gateway half without changing providers, the Aurpay RPC Gateway is free, open source under Apache-2.0, and sits in front of the endpoints you already have across 20 chain and network combinations. Its documentation is explicit about the boundaries described here, including what it deliberately does not handle for you, which is the part worth reading before you depend on any layer of this kind.