Search for the cheapest Ethereum RPC and you get a list of headline prices, which is the one number that reliably fails to predict your invoice. The honest answer is that the cheapest provider depends on the shape of your traffic, and that the sticker price is only the floor. What actually decides the bill is how a model prices the heavy parts of your workload: traces, wide log queries, large responses, and bursts. This post breaks down where the real cost hides, which model is cheapest for which workload, and how to compare them without guessing. Plans and weights move often; treat the specifics here as a qualitative snapshot as of July 2026 and confirm against official docs before you commit.
Why the cheapest sticker is rarely the cheapest bill
A low advertised price buys you a base allowance and not much certainty about what sits on top of it. On a compute-unit gateway, the multiplier on traces and large eth_getLogs ranges means a small slice of expensive calls can set most of your bill, so two apps with identical request counts can differ by an order of magnitude. Large responses add egress you did not quote for. Tight block-range and result caps force you to chunk queries, and every extra chunk is another billable round trip, so the limit quietly turns into cost; the mechanics of that are in the eth_getLogs block range guide. Bursts trip rate limits, and the retries that follow are more billable calls. None of these show up on the pricing page.
The lesson is not that gateways are overpriced. It is that “cheapest” is a property of the model meeting your traffic, not of the number on the plan card. Our compute units vs credits breakdown works a full example through both models.
The genuinely cheap case: read-light traffic on a free tier
If your app makes a modest number of plain reads, balances, block headers, and the occasional eth_call, the cheapest Ethereum RPC is almost certainly a major gateway’s free tier, and there is no reason to pay for anything else. Free tiers are generous precisely because read-light traffic is cheap to serve, and a compute-unit model with a big free allowance is hard to beat when you never touch the expensive methods. If that is you, stop here; the rest of this post is about the workloads that outgrow that tier.
Where each model is cheapest
Once traffic grows or leans on heavy methods, the ranking changes. The point is to match the model to your traffic rather than to chase a headline.
| Model | Cheapest when | Watch out for |
|---|---|---|
| Free tier (compute units) | low volume, read-light, hobby and prototypes | heavy methods and growth blow past the free allowance fast |
| Usage / compute units | steady mid volume with a light method mix | traces, wide logs, and large responses set the real bill |
| Credits | mid volume where the weight spread is narrow | still remote, still metered per call |
| Dedicated / flat capacity | predictable high throughput you can size | you pay for peak headroom that sits idle |
| Self-host | very high volume, marginal cost near zero | high fixed cost and full ops burden are yours |
| On-node bundled credits | high-volume or heavy node access without running hardware | built for backend workloads near the node, not CDN edge |
Self-hosting deserves a note because it looks cheapest on paper and often is not. The marginal cost per call approaches zero once the box is running, but the fixed cost is real: hardware, disk that grows with archive state, sync time, upgrades, and the engineer-hours to keep it healthy. It is cheapest at genuinely high, steady volume and for teams that already run infrastructure; below that, the ops time usually costs more than the RPC ever would.
The on-node angle: remove the surcharges, not just the rate
There is a fourth lever most comparisons miss. Egress, chunking round trips, and per-method weighting are all consequences of your code being on one machine and the node being on another. Move the code onto the node host and those surcharges largely disappear from the bill rather than getting negotiated down.
That is the model BLAZED.sh uses. Your container or script runs on the same server as a fully synced node, and you read the chain over a local socket instead of the public internet (ws://eth:8545 today; IPC is the maximum-performance local transport in general and a planned direction). Pricing is per-request credits with a deliberately narrow spread: most methods cost 1 credit, a few heavy operations cost 4, and the credits are granted monthly by your subscription rather than metered against a wide compute-unit table. Because reads happen over a local socket, the large-response egress that inflates a gateway bill is not in the hot path, and a 1,000-block eth_getLogs window today can mean fewer chunked calls than stricter hosted caps. The current numbers live on the RPC pricing page, and since pricing is still being finalized, check there before you plan around specifics.
The effect is that forecasting becomes counting. You multiply calls by a small, mostly-uniform weight and check the total against a monthly allowance, instead of modeling a method mix against a table you cannot see until the invoice arrives.
How to actually compare providers
The reliable way to find your cheapest option is to price your real workload, not the plan card. Estimate the volume of each method group you call: plain reads, log queries, and traces. Apply each candidate provider’s weights or credit costs to those counts. Add the surcharges the pricing page hides, meaning egress on your large responses, the extra calls your block-range limit forces you to chunk into, and a realistic allowance for burst retries. For self-hosting, add the monthly hardware and a fair estimate of ops hours. The provider with the lowest sticker will frequently not be the one with the lowest total, and knowing which is which takes an afternoon of arithmetic rather than a surprise at the end of the month.
Conclusion
The cheapest Ethereum RPC is the one whose pricing model fits your traffic, not the one with the smallest number on the card. For read-light apps that is a free tier, full stop. For high-volume or trace-heavy workloads the headline price is the least reliable part of the quote, and the cost that actually moves the bill is method weighting, egress, and the round trips your limits force. If you are tired of that math, a bundled-credit plan with a narrow weight spread turns forecasting into counting, and running your code on the node removes the egress surcharges instead of negotiating them. If your reason for shopping is a specific provider rather than price alone, the Infura, Alchemy, and QuickNode alternative guides pick up from there.