Not every JSON-RPC request needs the same amount of infrastructure.
A simple eth_blockNumber call returns the latest block height with minimal processing. A historical eth_getLogs query spanning millions of blocks needs far more CPU, storage access, and database reads. Trace APIs, transaction simulations, archive lookups, and debug methods demand even more compute.
If every request cost the same, heavy workloads would become unaffordable for the provider to run. To balance infrastructure cost, most providers assign different weights to different RPC methods instead of billing on request volume alone.
The result: two applications sending the same number of requests can land on very different monthly bills, depending on which methods they call.
Why RPC Pricing Is More Complex Than Request Counts
Providers price RPC access around one constraint: heavier methods consume more compute, storage access, and database reads than lighter ones. How a provider handles that constraint shapes which pricing model it offers.
Talk to an expertThe Four RPC Pricing Models
1. Request-Based Pricing
Request-based pricing is the simplest model. You purchase a monthly allowance based on total API requests, typically in tiers such as 20 million, 100 million, or 500 million requests a month.
This model works well for lightweight applications with predictable traffic. It stays easy to understand, makes budgeting straightforward, and suits prototypes and early-stage applications.
2. Compute Unit Pricing
Instead of counting requests, compute unit pricing assigns a weight to every RPC method:
| RPC method | Relative compute cost |
|---|---|
eth_blockNumber | Low |
eth_getBalance | Low |
eth_call | Medium |
eth_getLogs | High |
trace_transaction | Very high |
debug_traceTransaction | Extremely high |
You purchase compute units rather than requests. This model reflects the actual infrastructure an application consumes, especially for complex queries.
The trade-off is predictability. Monthly cost gets harder to estimate, because infrastructure usage depends on application behavior, not traffic volume alone.
3. Pay-As-You-Go Pricing
Consumption-based pricing charges you only for what you use, with no upfront commitment and flexible scaling. It suits experimental projects and development environments.
The downside is unpredictable spending. A successful product launch, a spike in indexing activity, bot traffic, or rapid user growth can increase infrastructure cost sharply within a short period. Production workloads generally benefit from a pricing model that makes operational cost easier to forecast.
4. Dedicated Infrastructure Pricing
Dedicated infrastructure takes a different approach. Instead of charging for fluctuating usage, you deploy isolated infrastructure reserved for your application alone, typically including:
- Dedicated RPC endpoints
- Reserved CPU and memory
- Isolated storage
- Guaranteed throughput
- Consistent latency
- Infrastructure unaffected by neighboring workloads
Pricing here is based on infrastructure allocation, not consumption. Exchanges, wallets, institutional staking platforms, payment providers, gaming applications, and high-throughput DeFi protocols favor this model, since consistent performance matters more than minimizing the lowest possible monthly bill.
Start for free Explore pricing plansWhere Hidden RPC Costs Usually Appear
Headline pricing rarely reflects the full cost of running blockchain infrastructure. These are the areas where additional charges commonly show up.
Archive Data Access
Historical blockchain state requires archive nodes, which consume far more storage and operational resources than standard full nodes. Many providers charge separately for archive access, restrict archive queries, or reserve archive nodes for premium plans.
Trace and Debug APIs
Methods such as trace_block, trace_transaction, and debug_traceTransaction consume far more compute than standard JSON-RPC requests. Some providers exclude these APIs from standard plans. Others assign very high compute weights to them.
Rate Limiting
A provider may advertise a generous monthly request limit while enforcing strict throughput restrictions, including limits on requests per second, concurrent connections, and burst traffic thresholds.
Applications rarely go down because they exceed a monthly quota. They go down because traffic exceeds the provider's instantaneous capacity limit.
Geographic Performance
Infrastructure location affects user experience directly. If a request travels across continents before reaching a node, latency increases regardless of what you pay. Check whether a provider offers multi-region deployment, global load balancing, regional RPC endpoints, and automatic failover.
Overage Charges
Usage-based billing often lets you exceed your purchased capacity. That flexibility can produce an unexpectedly high invoice during a period of rapid growth. Predictable infrastructure cost matters more as an application moves into production.
Choosing the Right Pricing Model
Different applications carry different infrastructure requirements.
| Workload | Recommended pricing model |
|---|---|
| Personal projects | Request-based |
| Internal tools | Pay-as-you-go |
| MVP applications | Request-based |
| High-growth startups | Compute-based or dedicated |
| Wallet infrastructure | Dedicated |
| DeFi protocols | Dedicated |
| Exchanges | Dedicated |
| Enterprise applications | Dedicated |
Questions Every Engineering Team Should Ask
Before you select an RPC provider, ask:
- How are RPC methods weighted?
- Which APIs carry additional charges?
- Are archive nodes included?
- Are trace APIs available?
- What rate limits apply?
- Are workloads isolated or shared?
- What happens during a sudden traffic spike?
- Is pricing based on infrastructure or consumption?
- What uptime SLA is contractually guaranteed?
- How is latency measured?
Transparent answers to these questions predict long-term infrastructure cost far better than headline pricing alone.
Talk to an engineering expertHow Instanodes Prices RPC Access
Instanodes runs flat, request-based pricing across every tier, from a free plan through Advanced, with no per-method compute weighting. Archive access is included in paid tiers rather than billed separately, and every plan, including Free, carries a contractual 99.95% uptime SLA.
For wallet infrastructure, DeFi protocols, exchanges, and other workloads that need isolated, dedicated capacity, Instanodes runs single-tenant dedicated clusters with custom SLA terms, so you move from shared, request-based pricing to dedicated infrastructure without switching providers.
FAQ
What are the main RPC pricing models?
The four main models are request-based pricing, compute unit pricing, pay-as-you-go pricing, and dedicated infrastructure pricing. Each balances predictability, flexibility, and cost differently.
Why does RPC pricing vary so much between applications with similar traffic?
Because most providers weight requests by RPC method rather than counting them equally. A heavier method, such as eth_getLogs or a trace call, consumes far more compute than a lightweight call like eth_blockNumber, so two applications with identical request counts can see very different bills.
Are archive nodes included in standard RPC pricing?
It depends on the provider. Many charge separately for archive access, restrict archive queries to certain plans, or reserve archive nodes for premium tiers. Confirm archive access and pricing before you commit to a plan.
When should I choose dedicated infrastructure over usage-based pricing?
Choose dedicated infrastructure when consistent latency, guaranteed throughput, and isolation from other customers' traffic matter more than minimizing your lowest possible monthly bill. Wallets, exchanges, DeFi protocols, and other production workloads with strict performance requirements fit this model.
Does Instanodes charge more for archive or trace methods?
No. Instanodes includes archive access in its paid tiers and prices by plan, not by RPC method. A trace call or an archive read counts against your request quota the same as any other call.
