Managed RPC and node providers compared on CU pricing and fallbacks

RPC pricing is quoted in compute units and eaten in production incidents. Every provider in the table above sells the same two things - request throughput and chain coverage - and differs on everything that matters: rate-limit semantics, write-path reliability, censorship behavior, and what happens at the 429. The ranking puts failure behavior first, because single-endpoint dependencies fail at the worst possible time. The median contract term across the population is n/a - but the real commitment is the one in your client config, which outlives every invoice.

Compute units are not dollars

Every provider prices in its own currency - compute units, credits, per-method weights - and the conversion to real requests differs by chain and by method [1][2]:

• Weighted methods. An archive eth_call can cost 10-100x a balance read on some schedules. Your bill follows your workload shape, not your request count [3]. 25% of the population documents crypto payment - worth knowing when the invoice needs to come from somewhere specific.
• Archive access. Deep-history queries cost more or fail outright - check the tier table before deep-history work, not after [3].
• Burst semantics. Rolling-window rate limits behave differently from per-second caps. Load-test with your p99 traffic, not your average [2].

Live from our database - caveats and sources in each linked review.

The censorship and outage surface

A managed RPC is a choke point you opted into. The honest incident checklist:

• Who can block a method or address - some providers filter sanctioned addresses at the endpoint level; the clause lives in the ToS [1]. If your dApp needs neutral infrastructure, this is a design question, not a paragraph.
• Jurisdiction of the endpoint - the same neutral-infrastructure question one level up: where the company sits decides which orders it must obey. The staking hub records the same field per operator.
• Single-provider blast radius - provider outages are the most common dApp "we did nothing and it broke" incident. A fallback endpoint on a different operator and chain topology turns a hard outage into a slow one.
• Write paths - reads tolerate a marketplace; sends and state transitions deserve your own node or a bonded provider with SLA credits. The endgame is running your own node - cheaper than it sounds for single-chain workloads [6]. For the custody logic behind that call - why holding your own keys and your own endpoint changes the trust model - the no-kyc hub and mining hub make the same argument from the hardware side.

The three camps, priced honestly

• Managed commercial (QuickNode, Alchemy, Infura, Chainstack) - polished dashboards, documentation, visible rate schedules [2][3][4]. Best for teams that want product, not infrastructure.
• Protocol markets (Pocket, Lava) - bonded operators serve requests, payment settles on-chain [7][8]. Real redundancy in theory; in practice, latency and chain coverage spread wider than commercial tiers.
• Community tiers (dRPC-style) - pay-per-use pricing with a free lane [6]. Fine for development; verify the SLA before production.

Fallback design that actually survives

The figure above is the whole strategy. Implement it with real plumbing, not aspirational comments:

• Primary/secondary split across operators - same chain, different company, different infra. Health-check both at the method level, not the DNS level.
• Circuit breaker with error budgets - switch on sustained 5xx/timeout, not on single failures. Sticky switching avoids split-brain reads during chain reorgs.
• Self-hosted catch-all for writes - your own node signs and broadcasts directly when both providers degrade; even a modest VPS box covers the write path [6].

The pattern repeats across this whole market: redundancy you configure is worth more than redundancy you bought. 8 providers make the live table; 25% of them let you start without identity checks, which matters mostly for development environments. 75% of the rows have facts we verified ourselves rather than marketing claims - the rest are documented-but-unverified, which is exactly the gap your replay test closes. The full test loop - replay, kill, restore - belongs in your deploy pipeline, not in a vendor demo.

Testing your actual stack

Compare providers with your own load profile, not their benchmarks:

1. Replay a production day - replay request traces against two endpoints; compare error rates at p95/p99, not medians.
2. Test the write path separately - transaction propagation timing is where cheap tiers quietly degrade [6].
3. Verify archive queries at your oldest block - the answer differs more between tiers than between providers [3].
4. Price the failover - a fallback endpoint that never runs is still a cost. Bill both endpoints at your p99 replay and compare the combined bill against the single-provider price you are replacing.

For the same reliability logic applied to compute rather than endpoints, the compute hub covers interruption-tolerant job design - the checkpoint discipline transfers directly. The hosting hub is the same argument for machines instead of endpoints: the honest comparison is always finished-work cost, never the rate card.