Most requests a free RPC plan buys, across 12 providers
How many requests of a real workload each provider's free plan allowance buys in a month, once credits, Compute Units and Request Units are converted into the requests they actually pay for.
TL;DR. As of , dRPC leads free allowance at 10.50M (p50, 24h) across 10 ranked plans, measured on Dapp frontend, Ethereum. Source: OpenChainBench, https://openchainbench.com/benchmarks/rpc-free-tier.
Read this carefully
Allowance, not latency and not reliability. A plan that buys the most requests is not thereby the fastest or the most correct; those are measured on the per-chain RPC pages. Published allowances, human-verified against each provider's own pricing page with the date it was read. A free plan is one that costs nothing and renews, so QuickNode's one-month trial is not here. Where a provider publishes a daily cap it is multiplied by 30.
"200 million credits a month" tells you nothing until you know what a credit buys. Providers meter free plans in four different units, and the same unit costs a different number of credits depending on the method called, so the advertised numbers cannot be compared as printed. This page converts every free allowance into the one unit a developer can reason about: how many requests of a real workload it pays for before the plan stops or starts charging. The answer moves with the workload, which is why the figure is published per workload rather than as one number. A dapp frontend calling eth_call and eth_getBalance drains an allowance at a different rate than a log indexer calling eth_getLogs, and on BlockPI's free plan the gap between the cheapest workload and the most expensive is large on a single plan, with nothing on the pricing page saying so. Every row carries the two ends of that span next to its headline figure, so the plans a workload cannot surprise are visible without reading four tabs: Ankr and dRPC meter flat, and their floor is their ceiling.
Methodology
We take each provider's free plan allowance as published, in whatever unit the provider meters, and divide it by what one request of a given workload costs in that unit. The result is the number of requests the free plan buys in a month. The unit conversion is the whole point: Alchemy meters Compute Units weighted per method, Chainstack meters one flat Request Unit for every method, Infura meters credits on a daily cap, and Ankr meters flat requests. Those four numbers are not comparable until they are divided by the method mix that spends them. Five mixes are priced and four are offered as tabs. The unfiltered view is the dapp frontend mix on Ethereum, the case most readers arrive with. A plan that leads one workload can trail on another, and the table does not hide that by averaging them: an allowance averaged across a trace mix and a simple-read mix describes no workload anyone runs, and taking each plan's best workload instead would rank every provider on its most flattering measurement. So the span is reported rather than collapsed. Beside each headline figure sit the least and the most generous workload that plan serves on that chain, which is what separates an allowance that can be budgeted from one that happens to be large on the mix you opened.
Results: 10 plans ranked by Free allowance (p50, 24h)
| № | Plans | Free allowance | Success |
|---|---|---|---|
| 1 | dRPC | 10.50M | 100.00% |
| 2 | OnFinality | 6.86M | 100.00% |
| 3 | Chainstack | 3.00M | 100.00% |
| 4 | BlockPI | 1.82M | 100.00% |
| 5 | Alchemy | 1.26M | 100.00% |
| 6 | Validation Cloud | 1.22M | 100.00% |
| 7 | Ankr | 1.00M | 100.00% |
| 8 | Infura | 902.3K | 100.00% |
| 9 | Blockdaemon | 191.7K | 100.00% |
| 10 | GetBlock | 75.0K | 100.00% |
Frequently asked
Which free RPC plan gives the most requests?
It depends on the workload, and the table reorders when you change it. On the Ethereum dapp mix the leader is the plan at the top of the board right now; on a log indexer mix the order is different, because methods like eth_getLogs cost more units on providers that weight per method and cost the same as any other call on providers that do not. Read the figure for the workload you actually run, and read the two columns beside it: they give the worst and the best that plan does across every workload it serves, so you can see whether its headline is a floor or a best case before committing to it.
Why not just compare the advertised numbers?
Because they are in four different units. 30M Compute Units, 3M Request Units, 3M daily credits and 1M requests are four numbers that cannot be ordered until each is divided by what one request of your workload costs in that unit. That division is what this page does.
Is the biggest allowance the best free plan?
Not on its own. Throughput ceilings, archive access and reliability are not scored here, and a plan with a large allowance behind a low rate limit will not serve a busy frontend. This page answers one question, how far the allowance goes, and the per-chain RPC pages answer how fast those endpoints respond.
Source code github.com/ChainBench/OpenChainBench/tree/dev/harnesses/rpc-cost