How BoltRPC Request Units Work: Method Weights, Cost Calculation, Optimization

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_protocolVersion	Returns the Ethereum protocol version	3
eth_syncing	Returns node synchronization status	3
eth_chainId	Returns the current chain ID	3
eth_mining	Returns true if the client is mining	3
eth_hashrate	Returns the node’s current hashrate	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_getCompilers	Returns available compilers in the client	8
eth_compileSolidity	Compiles Solidity source code	12
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 100

Cache 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 trial.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.

---

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is an RPC compute unit?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "An RPC compute 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 data payloads consume more units. BoltRPC uses request units (RUs) as the basis for usage measurement."
      }
    },
    {
      "@type": "Question",
      "name": "Why do different RPC methods cost different amounts?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Different methods require different levels of node work. Returning a cached block number is nearly free. Scanning log events across thousands of blocks or replaying a transaction at the opcode level requires substantially more CPU, memory, disk access. Fixed method weighting reflects actual resource consumption."
      }
    },
    {
      "@type": "Question",
      "name": "How many RUs does eth_getLogs cost on BoltRPC?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "eth_getLogs costs 4 RUs per call on BoltRPC. Most standard read methods cost 3 RUs. eth_sendRawTransaction costs 5 RUs. debug_* methods cost 6 RUs. The full weight table is published on the BoltRPC blog."
      }
    },
    {
      "@type": "Question",
      "name": "What happens if I exceed my RU quota?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Contact the BoltRPC team to discuss upgrade options. Enterprise plans offer custom RU quotas with dedicated infrastructure."
      }
    },
    {
      "@type": "Question",
      "name": "Does BoltRPC pricing change based on which methods I call?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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."
      }
    },
    {
      "@type": "Question",
      "name": "Are the RU weights the same across all chains?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. The RU weight table applies uniformly across all supported networks on BoltRPC."
      }
    }
  ]
}
</script>