Request units (RUs)

Documentation Index

Fetch the complete documentation index at: https://docs.chainstack.com/llms.txt

Use this file to discover all available pages before exploring further.

​

What an RU is

A request unit (RU) is the metric Chainstack uses to measure each request against our request-based services. Different requests consume different resources, so pricing is tied to RUs rather than raw call counts. See current service pricing on the pricing page.

​

Cost per request

​

Full vs archive by protocol

For each protocol, here’s what counts as a full request (1 RU) and what counts as an archive request (2 RUs):

​

Method rules

​

Always 2 RUs

All debug_* and trace_* methods — including debug_traceTransaction, debug_traceBlockByNumber, and trace_block — are billed at 2 RUs regardless of block age, as they require archive state. For per-protocol debug and trace capabilities, see Debug and trace APIs.

​

EVM methods affected by block age

The block-age rule in the table above applies to these EVM methods:

• eth_getBalance
• eth_getCode
• eth_getTransactionCount
• eth_getStorageAt
• eth_call
• eth_getProof
• eth_callMany
• eth_createAccessList

All other EVM methods are billed as full (1 RU) regardless of the block they target.

​

Solana method scope

Archive billing on Solana applies only to these methods:

• getTransaction
• getBlock
• getBlockTime
• getBlocks
• getBlocksWithLimit
• getSignaturesForAddress
• getFirstAvailableBlock
• getSignatureStatuses

A request is archive (2 RUs) when its target slot is below firstAvailable + 5,000, where firstAvailable is the lowest slot our Solana full node still retains. Slots at or above this boundary are full (1 RU). getSignaturesForAddress and getFirstAvailableBlock are always billed as archive, regardless of slot. All other Solana methods are billed as full (1 RU) regardless of slot.

​

Two values shape the Solana archive boundary

• Ledger retention — each Solana full node is configured with --limit-ledger-size 400000000 (400 million shreds). Shreds are Solana’s network-propagation units, and the number produced per slot varies with block density, so this caps disk usage rather than fixing the slot count retained.
• Safety buffer — 5,000 slots immediately above the pruning floor. Requests targeting these slots are routed to the archive backend to avoid races where the full node prunes data mid-request. This sets the boundary that triggers archive billing.

​

Putting it together

A call’s RU cost on Solana depends on the method and, for methods eligible for archive billing, the target slot. The ledger size (400M shreds) caps how far back the full node retains data; the 5,000-slot safety buffer above the pruning floor sets the actual billing boundary. For a sequence of calls: See also Solana archive methods availability.

​

HTTP requests vs WebSocket subscriptions

A “request” is anything the node returns to you over the wire. The transport changes how those individual returns are counted.

​

HTTP

Each JSON-RPC call counts as one request, regardless of how much data the response contains.

• eth_blockNumber — 1 request.
• eth_getLogs across 2,000 blocks returning 5,000 events — still 1 request.
• eth_call simulating a complex contract — 1 request.

The RU multiplier (1 RU for full, 2 RUs for archive) is applied on top.

​

WebSocket subscriptions

Subscriptions over WebSocket flip the counting model. Setting up the subscription counts as one request — and then each push notification the node sends to you counts as one more request.

• eth_subscribe newHeads on Ethereum mainnet (≈one new block every 12 s) — ~7,200 requests/day.
• eth_subscribe logs filtered to one contract emitting 5 events per block — ~36,000 requests/day.
• eth_subscribe newPendingTransactions on a high-throughput chain — easily millions of requests/day.

The same rule applies to legacy HTTP filter polling (eth_newPendingTransactionFilter + eth_getFilterChanges): each poll that returns events is one request per call, not per event — but the call cadence is yours to control, unlike a WebSocket push.

​

Predicting whether an EVM call is full or archive

For any EVM protocol in the table above:

1. Read the chain tip with eth_blockNumber.
2. Compute tip − your_block.
3. If the result is 127 or greater, the call is archive (2 RUs). Otherwise it’s full (1 RU).

Calls without a block parameter — eth_blockNumber, eth_chainId, net_version — are always full.