Ethereum RPC pricing is harder to compare than it looks. Two providers can advertise similar headline numbers and still bill you wildly differently, because the unit being counted is not the same. This post breaks down the pricing models you will actually meet, shows how to estimate a monthly bill for each, and explains where a bundled-credit plan fits. Provider plans and weights change frequently; treat the numbers here as a qualitative snapshot as of June 2026 and confirm against official docs before you commit.
The models you will meet
Compute units (weighted per method). The dominant model for large gateways. Every method has a cost multiplier, so a cheap eth_blockNumber and an expensive debug_traceTransaction draw down very different amounts from the same budget. The headline “X compute units/month” tells you almost nothing until you know your method mix.
Credits or request quotas. A simpler relative of compute units. Calls cost a small number of credits, sometimes uniform, sometimes lightly weighted for heavy methods. Easier to reason about when the per-method spread is narrow.
Flat capacity (requests per second, dedicated nodes). You pay for throughput, not per call. Predictable, but you are sizing for peak load and often paying for idle headroom.
Hardware plus ops (self-hosting). No request meter at all; your cost is the box, the disk, and the engineer-hours. Lowest marginal cost per call, highest fixed cost and operational burden.
Why compute units are hard to forecast
The trouble with weighted models is that the bill is a function of your traffic shape, not just its volume. Two apps making the same number of calls can differ by an order of magnitude in cost if one leans on traces and large eth_getLogs ranges while the other only reads balances.
To forecast a compute-unit bill you have to model:
- The multiplier for each method you call.
- The frequency of each method.
- Surcharges for large responses or wide block ranges (see our deep dive on eth_getLogs block range limits).
Few teams have time to build that model, so they discover the real cost in production. That is the core complaint behind most “I need an Infura alternative” searches.
A worked example
Say a backfill job makes, per day:
- 500,000 standard reads (
eth_call,eth_getBalance,eth_getBlockByNumber) - 20,000 log queries (
eth_getLogs) - 5,000 trace calls (
trace_replayTransaction)
Under a weighted compute-unit model, the trace and log calls dominate the bill even though they are a small fraction of the request count, because their multipliers are large. Your monthly cost is driven by the 5% of traffic that is expensive, and a small change in trace volume moves the bill noticeably.
Under a bundled-credit plan with a narrow weight spread, the same workload is far easier to size: you count calls, apply a small handful of weights, and check the total against your monthly allowance.
How BLAZED.sh prices RPC
BLAZED.sh uses a per-request credit model with a deliberately narrow weight spread, drawn from a credit balance granted monthly by your subscription. As of June 2026:
- Most Ethereum methods cost 1 credit per call (
eth_call,eth_getBalance,eth_getBlockByNumber, and so on). - A few heavy operations cost 4 credits (
txpool_content,trace_replayBlockTransactions,trace_replayTransaction). - Very large responses add 50 credits per MB over the threshold, since bytes off the node are the real cost driver there.
- Credits are included in the monthly plan (the free plan bundles 1M credits, Beta 5M, and Beta XL 25M), and WebSocket subscriptions follow the same model.
The point is not that calls are free; it is that the per-method spread is small (mostly 1, occasionally 4) and your allowance is granted monthly with your subscription, so forecasting is counting rather than modeling. Pricing is still being finalized, so check the current RPC pricing page before you plan around specific numbers.
Because your code runs on the same host as a fully synced node, the large-response surcharge also matters less than it would across a public gateway: you are reading bytes over a local socket, not paying egress to pull a full block or a wide log range across the internet.
Which model should you pick
- Spiky or trace-heavy workloads where the bill keeps surprising you: a bundled-credit or flat plan removes the per-method modeling.
- Steady, read-light traffic on a generous free tier: a compute-unit gateway may be the cheapest path, and there is no reason to move.
- Predictable high throughput you can size: dedicated nodes or flat capacity.
- You have the ops appetite and want zero request meter: self-host.
Conclusion
The headline price on an RPC plan is rarely the number that lands on your invoice. What decides the bill is the pricing model and how it interacts with your traffic shape. If compute-unit math is the thing you keep fighting, a bundled-credit plan with a narrow weight spread turns a forecasting problem into simple arithmetic, and running your code on the node removes the egress surcharges entirely. To see how a service is built this way, read building an Ethereum webhook API.