RPC request units (RUs) measure the computational cost of each method call to a blockchain node. Different methods consume different amounts of compute: a simple block number read requires minimal node resources, while scanning event logs across thousands of blocks requires significantly more. BoltRPC uses fixed, published weights per method so you always know the cost of a call before you build.
Why RPC Methods Don’t All Cost the Same
When your application calls an RPC endpoint, the node on the other end does real work. Not all work is equal.
Light reads like eth_blockNumber or eth_chainId require the node to return a single cached value. The CPU cost is negligible, the data size is minimal, the response is near-instant.
State reads like eth_getBalance or eth_getCode require the node to look up a value in the state trie. This involves disk I/O against the node’s state database.
Log queries like eth_getLogs require the node to scan through block receipts across a specified range, filter by topic and address, and return a variable-size payload. A query spanning 1,000 blocks with many matching events requires substantially more work than a single state read.
Transaction submission via eth_sendRawTransaction requires the node to decode and validate the transaction, check it against current state, propagate it to peers, and hold it in the mempool.
Debug and trace methods like debug_traceTransaction require the node to re-execute a transaction step by step, maintaining full EVM state at each opcode. This is orders of magnitude more expensive than any standard read.
Pool inspection methods like txpool_content require the node to serialize its entire pending transaction pool, which can hold thousands of transactions during high-activity periods.
Pricing that ignores these differences treats a mempool scan the same as a block number read. Method-based weighting reflects actual infrastructure cost. When weights are fixed and published, you can forecast your bill before a single line of code ships.
BoltRPC Request Unit Weight Table
BoltRPC assigns a fixed RU weight to every supported method. These weights never change mid-billing cycle. The tables below cover the full BoltRPC method catalog, grouped by category.
General Methods
| Method | Description | RU Weight |
|---|---|---|
web3_clientVersion |
Returns the current client version | 3 |
web3_sha3 |
Returns Keccak-256 of the given data | 3 |
net_version |
Returns the network ID (chain ID) | 3 |
net_listening |
Returns true if client is listening for connections | 3 |
net_peerCount |
Returns the number of connected peers | 3 |
txpool_status |
Pending and queued transaction counts (Geth only) | 6 |
txpool_contentFrom |
Pending and queued transactions for a given address (Geth only) | 6 |
txpool_inspect |
Textual summary of pending and queued transactions (Geth only) | 6 |
txpool_content |
All pending and queued transactions (Geth only) | 12 |
Ethereum Methods
| Method | Description | RU Weight |
|---|---|---|
eth_syncing |
Returns node synchronization status | 3 |
eth_chainId |
Returns the current chain ID | 3 |
eth_gasPrice |
Returns current gas price in wei | 3 |
eth_accounts |
Returns addresses owned by the client | 3 |
eth_blockNumber |
Returns the most recent block number | 3 |
eth_getBalance |
Returns address balance at a given block | 3 |
eth_getStorageAt |
Returns value from a storage position at a given address | 3 |
eth_getTransactionCount |
Returns the number of transactions sent from an address | 3 |
eth_getBlockTransactionCountByHash |
Returns transaction count for a block by hash | 3 |
eth_getBlockTransactionCountByNumber |
Returns transaction count for a block by number | 3 |
eth_getUncleCountByBlockHash |
Returns uncle count for a block by hash | 3 |
eth_getUncleCountByBlockNumber |
Returns uncle count for a block by number | 3 |
eth_getCode |
Returns the contract code at a given address | 3 |
eth_sign |
Signs data with a specific account | 3 |
eth_sendTransaction |
Creates and broadcasts a transaction | 4 |
eth_sendRawTransaction |
Sends a pre-signed transaction for broadcast | 5 |
eth_call |
Executes a message call without creating a transaction | 3 |
eth_estimateGas |
Estimates the gas needed for a transaction | 3 |
eth_getBlockByHash |
Returns block information by hash | 3 |
eth_getBlockByNumber |
Returns block information by number | 3 |
eth_getTransactionByHash |
Returns transaction information by hash | 3 |
eth_getTransactionByBlockHashAndIndex |
Returns transaction by block hash and index | 3 |
eth_getTransactionByBlockNumberAndIndex |
Returns transaction by block number and index | 3 |
eth_getTransactionReceipt |
Returns transaction receipt by hash | 3 |
eth_getUncleByBlockHashAndIndex |
Returns uncle by block hash and index | 3 |
eth_getUncleByBlockNumberAndIndex |
Returns uncle by block number and index | 3 |
eth_newFilter |
Creates a new filter object | 3 |
eth_newBlockFilter |
Creates a filter for new block events | 3 |
eth_newPendingTransactionFilter |
Creates a filter for pending transactions | 3 |
eth_uninstallFilter |
Uninstalls a filter | 3 |
eth_getFilterChanges |
Polls for filter changes since the last call | 3 |
eth_getFilterLogs |
Returns all logs matching a filter object | 3 |
eth_getLogs |
Returns logs based on filter criteria | 4 |
eth_subscribe |
Subscribes to events (newHeads, logs, newPendingTransactions) | 3 |
eth_unsubscribe |
Unsubscribes from an event using the subscription ID | 3 |
eth_getProof |
Returns account and storage values including Merkle-proof | 3 |
eth_maxPriorityFeePerGas |
Returns the priority fee needed to be included in a block | 3 |
eth_subscription |
Subscription event stream | 3 |
Debug Methods (Geth/Parity specific)
| Method | Description | RU Weight |
|---|---|---|
debug_traceTransaction |
Returns the trace of a transaction | 6 |
debug_traceBlockByHash |
Traces a block by block hash | 6 |
debug_traceBlockByNumber |
Traces a block by block number | 6 |
debug_traceBlock |
Full stack trace of all transactions in a block | 6 |
debug_traceCall |
Returns trace result by executing an eth_call in block context | 6 |
debug_storageRangeAt |
Returns a storage range for a given address | 6 |
debug_accountRange |
Returns an account range at a given block | 6 |
debug_getBadBlocks |
Returns a list of recent bad blocks seen on the network | 6 |
Personal Methods (Geth/Parity account management)
| Method | Description | RU Weight |
|---|---|---|
personal_newAccount |
Creates a new account | 6 |
personal_lockAccount |
Locks an unlocked account | 6 |
personal_ecRecover |
Returns the address that signed the given data | 6 |
personal_unlockAccount |
Unlocks an account for a specified duration | 9 |
personal_sign |
Signs data with a specific account | 12 |
personal_sendTransaction |
Creates, signs, and sends a new transaction | 20 |
Parity-specific Methods
| Method | Description | RU Weight |
|---|---|---|
parity_pendingTransactions |
Returns the list of pending transactions | 6 |
parity_allTransactions |
Returns all transactions for the given block | 6 |
parity_traceReplayTransaction |
Returns the trace replay of a given transaction hash | 12 |
parity_listStorageKeys |
Returns the list of keys at a specific storage location | 20 |
Parity Trace Methods
| Method | Description | RU Weight |
|---|---|---|
trace_call |
Traces a call at the given block | 6 |
trace_rawTransaction |
Traces a raw transaction for a given block | 6 |
trace_block |
Traces all transactions in a block | 6 |
trace_callMany |
Performs multiple call traces on top of the same block | 6 |
trace_filter |
Returns traces matching given filter | 6 |
trace_transaction |
Returns all traces of given transaction | 6 |
trace_replayTransaction |
Replays a transaction and returns the trace | 12 |
trace_replayBlockTransactions |
Replays all transactions in a block and returns traces | 12 |
Whisper Protocol Methods (Geth)
| Method | Description | RU Weight |
|---|---|---|
shh_post |
Sends a whisper message | 6 |
shh_version |
Returns the current whisper protocol version | 6 |
shh_addToGroup |
Adds an identity to a group | 6 |
shh_newFilter |
Creates a Whisper filter | 6 |
shh_uninstallFilter |
Uninstalls a Whisper filter | 6 |
shh_newIdentity |
Creates a new identity in Whisper | 9 |
shh_newGroup |
Creates a new Whisper group | 9 |
shh_getFilterChanges |
Polls Whisper for changes since the last call | 9 |
shh_getMessages |
Returns messages that match the filter | 9 |
shh_hasIdentity |
Checks if the client holds private keys for a given identity | 12 |
The most frequently called methods in production (eth_call, eth_getBalance, eth_blockNumber) sit at 3 RUs. Standard write operations (eth_sendRawTransaction) cost 5 RUs. Debug and trace methods run at 6 RUs. The expensive outliers are Whisper identity operations (9-12 RUs), mempool serialization (12 RUs), Solidity compilation (12 RUs), and full storage iteration or signed transaction broadcast (20 RUs).
Fixed weights mean predictable budgeting. Before you write a single function, you know the exact RU cost of every call. Your infrastructure cost is a formula, not a surprise.
How to Calculate Your RPC Bill
Your monthly RU consumption is the sum of calls per method multiplied by the RU weight for that method, across your entire application.
Formula:
Total RUs = sum of (calls_per_method × weight_per_method)Three worked examples across common production patterns:
Example 1: DeFi protocol (mixed read/write)
A DeFi lending protocol checks prices, reads user positions, submits liquidations.
| Method | Daily Calls | RU Weight | Daily RUs |
|---|---|---|---|
eth_call (price reads) |
50,000 | 3 | 150,000 |
eth_getBalance |
5,000 | 3 | 15,000 |
eth_getLogs (event monitoring) |
2,000 | 4 | 8,000 |
eth_sendRawTransaction (liquidations) |
200 | 5 | 1,000 |
| Total | 174,000/day |
Monthly total: ~5.2M RUs. The Builder plan at 30M RUs covers this comfortably.
Example 2: NFT indexer (log-heavy)
An NFT indexer tracks Transfer events across multiple collections.
| Method | Daily Calls | RU Weight | Daily RUs |
|---|---|---|---|
eth_getLogs |
20,000 | 4 | 80,000 |
eth_call (ownerOf queries) |
10,000 | 3 | 30,000 |
eth_getBlockByNumber |
1,000 | 3 | 3,000 |
| Total | 113,000/day |
Monthly total: ~3.4M RUs. The Builder plan at 30M RUs covers this comfortably. The Pro plan at 150M RUs gives room to scale before needing to upgrade.
Example 3: High-frequency trading bot (transaction-heavy)
A trading bot monitors blocks, simulates transactions, submits at high frequency.
| Method | Daily Calls | RU Weight | Daily RUs |
|---|---|---|---|
eth_blockNumber (polling) |
100,000 | 3 | 300,000 |
eth_call (simulations) |
50,000 | 3 | 150,000 |
eth_sendRawTransaction |
5,000 | 5 | 25,000 |
txpool_content |
500 | 12 | 6,000 |
| Total | 481,000/day |
Monthly total: ~14.4M RUs. The Builder plan at 30M RUs covers this. At 10x volume, the Pro plan at 150M RUs handles the scale.
The pattern across all three examples: standard production applications fit comfortably within lower-tier plans because the most common methods (eth_call, eth_blockNumber, eth_getBalance) carry the lowest weights.
How to Optimize Your RPC Usage
Understanding method weights opens a direct path to reducing your RU consumption without changing your application’s behavior.
Batch with multicall instead of individual eth_call requests
A standard ownership check loop calls ownerOf(tokenId) once per token. With a Multicall3 contract, you can batch 100 ownership checks into a single eth_call at 3 RUs instead of 300 RUs for 100 separate calls.
// 100 separate calls: 300 RUs
for (const tokenId of tokenIds) {
await contract.ownerOf(tokenId); // 3 RUs each
}
// 1 multicall: 3 RUs total
const results = await multicall.aggregate3(calls); // 3 RUs for all 100Cache eth_blockNumber aggressively
Polling eth_blockNumber every 500ms generates 172,800 calls per day (518,400 RUs). Ethereum produces a new block every 12 seconds. Caching the block number for 3 seconds reduces polling calls by 6x with no meaningful impact on freshness.
Replace polling with WebSocket subscriptions
A polling loop checking for new events via eth_getLogs every few seconds generates continuous RU load. A single WebSocket subscription to eth_subscribe("logs", filter) delivers events in real time at the cost of one persistent connection. For event-driven applications, subscriptions eliminate the polling cost almost entirely. See WebSocket vs HTTP RPC for implementation patterns.
Scope eth_getLogs queries precisely
eth_getLogs costs 4 RUs per call regardless of result size, but a query spanning 10,000 blocks puts more load on the node than one spanning 100 blocks. Keep ranges tight and paginate large historical queries. Always filter by specific contract address and topic signature to reduce the data the node needs to scan. See eth_getLogs in production for range management patterns.
Move debug methods off the critical path
debug_traceTransaction and related methods cost 6 RUs. They are essential for debugging but should never run in a production request path. Run traces offline or in a development environment. In production, use eth_getTransactionReceipt (3 RUs) for confirmation checks.
BoltRPC Plans and RU Quotas
| Plan | Monthly Price | RU Quota | Support |
|---|---|---|---|
| Builder | $49 | 30M RUs | Community |
| Pro | $199 | 150M RUs | Business hours |
| Business | $699 | 500M RUs | 24/7 monitoring |
| Enterprise | $1,499 | 1B RUs | Dedicated node + team member |
Monthly plan price is flat. Your infrastructure cost is the same every month regardless of which methods you call or how you distribute RU consumption across the billing period. Accepts credit card and crypto.
BoltRPC handles 2 billion daily requests and is trusted by Chainlink and Tiingo for production workloads. The fixed weight system applies at every scale: the same pricing model that works for a developer building a first protocol works for institutional trading infrastructure.
See full plan details at boltrpc.io/pricing.
Start your free 2-week trial at dashboard.boltrpc.io.
FAQ
What is an RPC compute unit? An RPC compute unit (or request unit) is a measure of how much computational work a blockchain node performs to respond to a method call. Methods requiring more CPU, disk I/O, or larger payloads consume more units. BoltRPC uses request units (RUs) as the basis for usage measurement.
Why do different RPC methods cost different amounts? Different methods require different levels of node work. Returning a cached block number requires negligible resources. Scanning log events across thousands of blocks, serializing the mempool, or replaying a transaction at opcode level requires substantially more CPU, memory, disk access. Fixed method weighting reflects actual resource consumption.
How many RUs does eth_getLogs cost on BoltRPC?
eth_getLogs costs 4 RUs per call. Most standard read methods (eth_call, eth_getBalance, eth_blockNumber) cost 3 RUs. eth_sendRawTransaction costs 5 RUs. debug_* methods cost 6 RUs. The full weight table is published above.
What happens if I exceed my RU quota? Contact the BoltRPC team at boltrpc.io/contact to discuss upgrade options. Enterprise plans offer custom RU quotas with dedicated infrastructure.
How do I monitor my RU usage? RU consumption is visible in the BoltRPC dashboard with real-time tracking and a breakdown by method type.
Does BoltRPC pricing change based on which methods I call?
The monthly plan price is fixed. RUs are your usage quota within that plan. A call to eth_sendRawTransaction (5 RUs) draws down your quota faster than eth_blockNumber (3 RUs), but your monthly cost does not change. You know your infrastructure bill before the billing cycle begins.
Are the RU weights the same across all chains? Yes. The RU weight table applies uniformly across all supported networks on BoltRPC.