Solana

Solana Beta is live. Try BoltRPC Solana endpoints free - start your trial now.

Blockchain RPC Pricing Explained: Compute Units vs Request Units

How compute unit pricing works in blockchain RPC — and why eth_getLogs costs more than eth_getBalance on most providers. Plus how fixed request unit pricing changes the math for DeFi teams.

BoltRPC
BoltRPC Team
8 min read
Blockchain RPC Pricing Explained: Compute Units vs Request Units

Blockchain RPC Pricing Explained: Compute Units vs Request Units

You signed up for an RPC provider, picked what looked like a reasonable plan, and your first invoice was three times what you expected. If this has happened to you, compute unit pricing is almost certainly why.

This guide explains how RPC billing actually works on the major providers, why certain methods cost dramatically more than others, and how to calculate what you will actually pay before you commit to a plan.


What Are Compute Units?

Compute units (CUs), also called credits, credits per second, or throughput units depending on the provider, are a billing metric that assigns different weights to different RPC methods based on how resource-intensive they are.

The idea is logical: an eth_blockNumber call that returns one number is cheaper to serve than an eth_getLogs call that scans millions of blocks and returns thousands of events. So providers charge more CUs for heavier methods.

The problem is that the multipliers are large, they vary between providers, and they are not prominently displayed at plan selection time.


How Compute Units Work in Practice

Compute unit pricing assigns different weights to different RPC methods. A typical weighting table from a CU-priced provider looks like this:

MethodCU Cost (typical)Relative Cost
eth_blockNumber10
eth_getBalance191.9×
eth_call262.6×
eth_getTransactionReceipt20020×
eth_getLogs75–7507.5–75×
trace_block2,983298×

So a plan advertised as “10 million requests per month” does not mean 10 million eth_getLogs calls. It means 10 million compute units, which translates to roughly 133,000 eth_getLogs calls (at 75 CUs each) or about 13,000 trace_block calls (at 2,983 CUs each).

The real cost of eth_getLogs:

eth_getLogs is the method DeFi teams use most heavily: indexing events, tracking transfers, monitoring protocol activity. At 75 CUs per call on CU-priced providers (up to 750 for large queries), it drains plans faster than almost anything else.

On a 10M CU plan:

  • You can make ~526,000 simple eth_getBalance calls (10M ÷ 19)
  • Or ~133,000 eth_getLogs calls (10M ÷ 75)
  • Or ~17,000 heavy eth_getLogs queries (10M ÷ 750 for large block ranges)

If your application runs an event indexer or tracks protocol activity, 17,000 heavy log queries is not a lot. A simple indexer running every 12 seconds hits that limit in about 2.4 days.


The Real Monthly Cost for DeFi Applications

Here is a cost comparison for a typical DeFi dashboard that makes 500,000 RPC calls per day (15M/month) across a mix of methods:

Method mix (typical DeFi dashboard):

  • 60% eth_call (balance reads, price reads): 9M calls
  • 30% eth_getLogs (event monitoring): 4.5M calls
  • 10% eth_getTransactionReceipt (tx confirmation): 1.5M calls

Compute unit calculation:

MethodCallsCU per callTotal CUs
eth_call9,000,00026234,000,000
eth_getLogs4,500,00075337,500,000
eth_getTransactionReceipt1,500,000200300,000,000
Total15,000,000871,500,000 CUs

Cost at that CU volume on a typical CU-priced provider:

On providers using compute unit pricing at this workload volume (871.5M CUs), you typically need a $225-299/month plan. BoltRPC uses a fixed monthly plan — visit boltrpc.io/pricing for current plan details.

The difference on lighter workloads is even more dramatic. At lower volumes, compute unit pricing plans may have lower headline costs but specific method usage drives the effective bill up unexpectedly.


Why eth_getLogs Is the Biggest Surprise

Most developers first encounter compute unit pricing when they add event monitoring to their application.

A simple pattern: check for new events every 12 seconds (one Ethereum block).

// This looks innocent
setInterval(async () => {
  const logs = await provider.getLogs({
    address: PROTOCOL_ADDRESS,
    topics: [eventTopic],
    fromBlock: lastCheckedBlock,
    toBlock: 'latest',
  });
  processLogs(logs);
}, 12000);

At one call every 12 seconds: 7,200 calls/day. At 75 CUs each: 540,000 CUs/day, 16.2M CUs/month. On a CU-priced provider with a 10M CU plan, this single polling loop exhausts the plan in 18 days. You have not even added balance reads or transaction confirmation yet.

The fix on CU-priced providers:

  • Use WebSocket subscriptions instead of polling (only consumes CUs when events fire)
  • Narrow block ranges aggressively
  • Cache results, avoid re-querying unchanged data

The fix on fixed-rate providers like BoltRPC:

  • BoltRPC pricing is straightforward — fixed monthly plans with no surprise bills. Optimize for performance, not billing math.

How to Check Your Provider’s Compute Unit Weights

Every CU-priced provider publishes their weighting table, usually in their documentation under “Compute Units”, “Credits”, or “Request Rates”. Look for this before selecting a plan.

Before choosing a plan, calculate your actual CU consumption by:

  1. Listing every RPC method your application calls
  2. Estimating daily call volume per method
  3. Multiplying by the CU weight for each
  4. Summing the total and choosing a plan above that number

Most teams skip this step, choose a plan based on headline request count, and discover the real cost after their first large invoice.


Fixed-Rate Pricing: A Different Model

Some providers use a fixed-rate model instead of compute unit weighting. Rather than large per-method multipliers, these providers charge a flat monthly fee with predictable costs regardless of which methods you call most heavily. BoltRPC uses this model.

What changes with fixed-rate pricing:

  1. Budget predictability: Your monthly plan cost is fixed. No surprise invoices when your application shifts toward heavier methods.

  2. Optimization focus shifts: You optimize RPC calls for application performance, not to avoid expensive method calls. Use Multicall3 because it makes your app faster, not because you are counting credits.

  3. DeFi workloads become more predictable: Workloads that run event indexers or log monitors continuously benefit most from flat-rate billing.

  4. Indexers and monitoring bots: Continuous monitoring applications that make thousands of log queries per hour avoid the CU drain that hits on compute-weighted providers.

BoltRPC pricing: BoltRPC uses a fixed monthly plan — visit boltrpc.io/pricing for current plan details. Plans start at $49/month. No hidden multipliers. The same pricing across all 22 supported networks.


When Compute Unit Pricing Is Not a Problem

Compute unit pricing is not always worse. For applications with simple read patterns (mostly eth_call and eth_getBalance), the headline plan limits are accurate and CU consumption is predictable.

CU pricing becomes a problem when:

  • Your application uses eth_getLogs heavily
  • You run event indexers or monitoring bots
  • You use debug/trace methods (debug_traceTransaction, trace_block)
  • Your call volume spikes during market events
  • You are building analytics tools that scan large block ranges

For simple dApps with moderate call volumes and no heavy log queries, the difference between models is smaller.


How to Estimate Your Monthly RPC Cost

Use this formula before choosing a provider and plan:

Monthly CU cost =
  (daily calls × 30) × CU weight per method

Example:
  eth_call:    100,000/day × 30 × 26 CU = 78,000,000 CU/month
  eth_getLogs: 10,000/day  × 30 × 75 CU = 22,500,000 CU/month
  Total: 100,500,000 CU/month
  → CU-priced provider at ~100M CU tier: often $199/month or more

On a fixed-rate provider like BoltRPC:
  Same 110,000 daily calls → fixed monthly plan cost regardless of method mix.
  → BoltRPC pricing starts at $49/month. Visit boltrpc.io/pricing for current plan details.

FAQ

Are compute units the same across all providers?

No. Every provider has its own CU table with different weights for different methods. A method that costs 75 CU on one provider may cost 40 CU on another. Some providers like BoltRPC use flat-rate monthly billing instead of CU weighting entirely. Always check the specific provider’s documentation before comparing plan prices.

Do free tiers use compute unit pricing?

Yes. Most free tiers on CU-priced providers also apply compute unit weighting. A free tier does not mean unlimited calls to any method. Heavy methods drain free allowances quickly.

Can I switch from compute unit to fixed-rate pricing mid-month?

Yes. Most providers allow plan changes. If you are consistently hitting limits due to heavy eth_getLogs or trace method usage, switching to a provider with flat-rate pricing mid-month typically saves money immediately.

Does fixed-rate pricing have rate limits?

Yes. Fixed-rate providers still have requests-per-second limits and monthly volume caps. The difference is that you pay a flat monthly fee — no dynamically computed compute unit multipliers. Your plan cost is predictable from day one.

What is the most expensive RPC method?

Trace and debug methods are typically the most CU-intensive. debug_traceTransaction and trace_block can cost 1,000–3,000+ CU per call on providers that support them. Most analytics and forensics tools that use these methods extensively find flat-rate pricing significantly cheaper.


Start your free 2-week trial on BoltRPC. Fixed monthly plans, 20+ networks, no surprise bills: trial.boltrpc.io

Related: Optimizing RPC Calls for DeFi | How to Choose a Blockchain RPC Provider

Frequently asked questions

Ready to build with high-performance RPC?

Start your free trial today. No credit card required. Access 20+ networks instantly.

Disclaimer: The content in this article is for informational purposes only and does not constitute financial, legal, or technical advice. Code examples and configurations are provided as-is. Always verify information with official documentation and test thoroughly in your own environment before deploying to production.

Continue reading