Request units (RUs)

​

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):

​

Always 2 RUs

These EVM methods are billed at 2 RUs regardless of block age:

• All debug_*, trace_*, and arbtrace_* methods — including debug_traceTransaction, debug_traceBlockByNumber, and trace_block.
• eth_callMany

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_call
• eth_createAccessList
• eth_estimateGas
• eth_feeHistory
• eth_getAccount
• eth_getBalance
• eth_getBlockByNumber
• eth_getBlockReceipts
• eth_getBlockTransactionCountByHash
• eth_getBlockTransactionCountByNumber
• eth_getCode
• eth_getLogs
• eth_getProof
• eth_getStorageAt
• eth_getTransactionByBlockNumberAndIndex
• eth_getTransactionCount
• eth_getUncleCountByBlockHash
• eth_getUncleCountByBlockNumber
• eth_newFilter
• eth_simulateV1

For eth_getLogs and eth_newFilter, the block evaluated for billing is fromBlock if set, otherwise toBlock if set, otherwise latest. For example, eth_getLogs({fromBlock: 1, toBlock: latest}) bills as archive because fromBlock is far below the tip — even though the range extends to latest. 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.

​

TON method scope

TON requests are billed as full (1 RU) by default. Archive billing (2 RUs) applies in two cases. Always archive, regardless of parameters:

• getTransactions
• getTransactionsStd

These methods return an account’s transaction history keyed by address (and logical time), not by block. The depth of the result cannot be determined before the request is served, so they are always classified as archive. Archive only when targeting a historical block — these methods take a block/seqno parameter and are billed as archive (2 RUs) when the requested seqno is more than 128 behind the chain tip, and full (1 RU) otherwise (recent block, or no block parameter):

• v2:
  • getBlockTransactions
  • getBlockTransactionsExt
  • getBlockHeader
  • lookupBlock
  • shards / getShards
  • getShardAccountCell
  • getShardBlockProof
  • getMasterchainBlockSignatures
  • getAddressState
  • getConfigParam
  • getConfigAll
• v3:
  • transactions
  • transactionsByMasterchainBlock
  • blocks
  • traces
  • actions
  • masterchainBlockShards
  • masterchainBlockShardState

The threshold is evaluated against the latest seqno of the workchain referenced by the request — the masterchain by default. All other TON methods — across v2 REST, v3 REST, and the /jsonRPC envelope — are billed as full (1 RU).

​

Aptos method scope

Aptos requests are billed as full (1 RU) by default. Aptos sequences data two ways, and the archive threshold differs by which an endpoint takes:

• Ledger version — a global counter that increments on every transaction, including the system transactions Aptos adds to each block. The threshold is 256 versions.
• Block height — one increment per block. Because each block spans several versions, the threshold is 128 blocks — roughly the same depth in time as 256 versions.

Archive billing (2 RUs) applies in three cases. Always archive, regardless of parameters:

• /v1/accounts/{address}/transactions

This endpoint returns an account’s transaction history keyed by address, not by block or version. The depth of the result cannot be determined before the request is served, so it is always classified as archive. Archive when targeting a historical block height — billed as archive (2 RUs) when the requested height is more than 128 behind the chain tip, and full (1 RU) otherwise:

• /v1/blocks/by_height/{block_height}

Archive when targeting a historical ledger version — billed as archive (2 RUs) when the requested version is more than 256 behind the latest version, and full (1 RU) otherwise:

• /v1/blocks/by_version/{version}
• /v1/transactions — the start version
• /v1/transactions/by_version/{txn_version}
• /v1/transactions/by_hash/{txn_hash} — resolved to its ledger version
• /v1/accounts/{address}/resources — the ledger_version parameter
• /v1/accounts/{address}/resource/{resource_type} — the ledger_version parameter
• /v1/tables/{table_handle}/item — the ledger_version parameter
• /v1/tables/{table_handle}/raw_item — the ledger_version parameter
• /v1/view — the ledger_version parameter

A request that omits the block or version parameter, or targets one within the threshold, is billed as full (1 RU). All other Aptos endpoints are billed as full (1 RU).

​

Starknet method scope

Starknet requests are billed as full (1 RU) by default. Three cases are billed at 2 RUs. Always 2 RUs — these trace methods are billed at the trace rate (2 RUs) regardless of block age, the same as the EVM debug_*/trace_* rule:

• starknet_traceBlockTransactions
• starknet_traceTransaction

Archive when targeting a historical block — these block-scoped methods are billed as archive (2 RUs) when the requested block is more than 128 behind the chain tip, and full (1 RU) otherwise (recent block, or a latest/pending block tag):

• starknet_getBlockWithTxHashes
• starknet_getBlockWithTxs
• starknet_getBlockWithReceipts
• starknet_getStateUpdate
• starknet_getBlockTransactionCount
• starknet_getTransactionByBlockIdAndIndex
• starknet_getClass
• starknet_getNonce
• starknet_getClassHashAt
• starknet_getClassAt
• starknet_call
• starknet_getStorageAt

Archive when the event range is historical — starknet_getEvents is billed as archive (2 RUs) when its from_block or to_block is more than 128 behind the tip, and full (1 RU) otherwise. This parallels the eth_getLogs rule in the EVM section. All other Starknet methods are billed as full (1 RU) regardless of the block they target.

​

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.