> ## Documentation Index > Fetch the complete documentation index at: https://chainstack-docs-polygon-erigon-trace-deprecation.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Request units (RUs) > How Chainstack bills full and archive requests across all supported protocols, with exact thresholds and method rules. ## 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](https://chainstack.com/pricing/). ## Cost per request | Request | Cost | | ------- | ----- | | Full | 1 RU | | Archive | 2 RUs | ## 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)**: | Protocols | Classification | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Ethereum, Polygon, BNB Smart Chain, Arbitrum, Base, Optimism, Avalanche, Linea, Mantle, Berachain, Scroll, Zora, Sonic, Unichain, Monad, Hyperliquid (HyperEVM), Plasma, Kaia, Cronos, Gnosis Chain, Celo, MegaETH, Ronin, Fantom, zkSync Era, Blast, Tempo | Less than 127 blocks behind the tip is **full**; 127 or more blocks behind is **archive** | | Solana | **Archive** billing applies to specific methods when fetching historical slots. See [Solana method scope](#solana-method-scope) below. | | TON | Most requests are **full**. `getTransactions` and `getTransactionsStd` are always **archive**; block/seqno methods are **archive** when the requested seqno is more than 128 behind the tip. See [TON method scope](#ton-method-scope) below. | | Aptos | Most requests are **full**. `/v1/accounts/{address}/transactions` is always **archive**; block-height methods are **archive** when the requested height is more than 128 behind the tip, and ledger-version methods when the requested version is more than 256 behind. See [Aptos method scope](#aptos-method-scope) below. | | Starknet | Most requests are **full**. Trace methods are always **2 RUs**; block-scoped methods are **archive** when the requested block is more than 128 behind the tip. See [Starknet method scope](#starknet-method-scope) below. | | Polkadot | Most requests are **full**. Sidecar trace endpoints are always **2 RUs**; `chain_getBlockHash` and block-scoped Sidecar endpoints are **archive** when the requested block is more than 128 behind the tip. See [Polkadot method scope](#polkadot-method-scope) below. | | Bitcoin, Sui, TRON, opBNB, Harmony | No archive split — every request is billed as full | ## 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](/docs/debug-and-trace-apis). ## EVM methods affected by block age The block-age rule in the [table above](#full-vs-archive-by-protocol) 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](https://github.com/solana-foundation/specs/blob/main/p2p/shred.md) 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: | Call | Why | Cost | | ------------------------------------------------------------ | -------------------------------------------- | --------- | | `getBalance(account)` | Not eligible for archive billing | 1 RU | | `getTransaction(signature)` on a recent transaction | Eligible; target slot above the boundary | 1 RU | | `getTransaction(signature)` on a transaction from months ago | Eligible; target slot below the boundary | 2 RUs | | `getSignaturesForAddress(address)` | Always archive | 2 RUs | | `getBlock(slot=1)` | Eligible; target slot far below the boundary | 2 RUs | | **Total** | | **8 RUs** | See also [Solana archive methods availability](/docs/limits#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. ## Polkadot method scope Polkadot is served over two transports — the Substrate node JSON-RPC and the [Sidecar](https://github.com/paritytech/substrate-api-sidecar) REST API. Both are billed as full (1 RU) by default. Three cases are billed at 2 RUs. **Always 2 RUs** — these Sidecar trace endpoints are billed at the trace rate (2 RUs) regardless of block age, the same as the EVM `debug_*`/`trace_*` rule: * `/experimental/blocks/head/traces` * `/experimental/blocks/{number}/traces` * `/experimental/blocks/{number}/traces/operations` * `/experimental/blocks/head/traces/operations` **Archive when targeting a historical block (JSON-RPC)** — 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 no block parameter): * `chain_getBlockHash` **Archive when targeting a historical block (Sidecar REST)** — a Sidecar request that reads a historical block is billed as archive (2 RUs) when that block is more than 128 behind the chain tip, and full (1 RU) otherwise (recent block, the chain head, or no block specified). The block is taken from the path on these endpoints: * `/blocks/{number}` * `/blocks/{number}/header` * `/blocks/{blockId}/extrinsics/{extrinsicIndex}` * `/blocks/{blockId}/extrinsics-raw` * `/blocks/{blockId}/para-inclusions` …or from the `at` query parameter on any other Sidecar endpoint. All other Polkadot methods and Sidecar endpoints — including requests that target the chain head or omit a block — are billed as full (1 RU). ## 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. If you're running sustained subscriptions, consider an [Unlimited Node](/docs/unlimited-node) — it uses RPS-tiered flat-fee pricing instead of per-request billing, so subscription throughput stops mapping to RU cost. 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](#full-vs-archive-by-protocol): 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.