Skip to main content

Rate limits

Solana-specific

  • Solana Mainnet:
    • Developer plan: 5 requests per second (RPS)
    • Growth plan: 50 requests per second (RPS)
  • Solana Devnet:
    • Developer plan: 25 requests per second (RPS)
    • Growth plan: 250 requests per second (RPS)

Arbitrum-specific

  • Arbitrum Mainnet: debug_traceBlockByNumber 20 RPS on all plans

Cronos-specific

  • Cronos Mainnet archive: debug_traceBlockByNumber 10 RPS on all plans

All other protocols

For global plan RPS limits across all other protocols, see Requests per second (RPS) plan limits.

EVM Range limits

For eth_newFilter requests, Developer subscription plan users get capped at 10,000 blocks per request. For the eth_getLogs, the caps are:
  • Developer plan — 100 blocks
  • Growth plan — 10,000 blocks
  • Pro plan — 10,000 blocks
  • Business plan — 10,000 blocks
  • Enterprise — 10,000 blocks. Customization available on request.
Learn more about eth_getLogs limits by reading Understanding eth_getLogs limitations.
Need a larger range? Dedicated Nodes support custom block-range limits on request.

EVM eth_getProof history limits

eth_getProof returns a proof only for blocks inside the node’s proof history. On Global Nodes that history is fixed per network, and a request for an older block returns an error instead of a proof. A proof for a block 127 or more blocks behind the tip is also an archive request and costs 2 RUs — see Full vs archive by protocol. Proof generation time grows with block depth. On Ethereum Mainnet, a proof about 9,000 blocks behind the tip takes over a minute, so raise your client’s request timeout for deep proofs. Need proofs further back? A Dedicated Node running Reth supports a longer proof window on request, up to 1,209,600 blocks (about 168 days on Ethereum Mainnet). Generation time still grows with depth, so a proof hundreds of thousands of blocks back takes tens of minutes.

EVM disabled debug methods

The following debug methods are disabled on EVM chains:
  • debug_executionWitness
  • debug_executionWitnessByBlockHash
  • debug_executePayload

Custom tracers on EVMs

EVM debug and trace methods accept two kinds of tracers:
  • Native (built-in) tracers — selected by name, such as callTracer. Available on Global Nodes; the exact set depends on the protocol (see below).
  • Custom JavaScript tracers — where you pass raw JavaScript as the tracer argument. These are disabled on Global Nodes and are available as customized solutions on the Enterprise plan on Dedicated Nodes.

Available native tracers

The following native tracers are enabled by default on EVM Global Nodes:
  • 4byteTracer
  • callTracer
  • prestateTracer
  • noopTracer
On Global Nodes, the extended set — flatCallTracer, muxTracer, and erc7562Tracer — is enabled per protocol rather than everywhere. Requesting one where it is not enabled returns the disabled tracer error. On Polygon, flatCallTracer is what replaces the retired Erigon trace_* namespace, because it returns traces in the Parity-style flat format — see Polygon methods. Three networks accept a narrower default set. The limit comes from the network’s node client, so these tracers return a client error rather than the disabled tracer error:
  • Monad — callTracer and prestateTracer only. 4byteTracer and noopTracer return -32602.
  • ZKsync Era — callTracer only. prestateTracer, 4byteTracer, and noopTracer return -32602.
  • Kaia — noopTracer returns -32000. The other three default tracers work.
See Debug and Trace | Ethereum for a description of each tracer.

Disabled tracer error

Requesting a tracer that isn’t enabled on the node—a custom JavaScript tracer, or a native tracer not available on that protocol—returns:

Ethereum eth_simulateV1 supports only full node

Running eth_simulateV1 | Ethereum will yield only a full node response—i.e. the data from the latest 128 blocks. Archive data is not supported for this call and the node will respond with missing trie node.

Fantom method limits

The following limits are applied on all subscription plans:
  • debug_traceBlockByNumber: 5 RPS
  • debug_traceBlockByHash: 5 RPS

Solana method limits

The following per-method RPS limits apply to Solana Mainnet Global Nodes. On Dedicated Nodes, per-method limits are configured per node.
The getConfirmedBlock method was removed in Agave 2.0 and returns Method not found on current validators. Use getBlock instead.
Architectural limits (set by Solana, not Chainstack):

getProgramAccounts limits

On Solana Mainnet Global Nodes, the getProgramAccounts rate limit depends on the size of the program you query. Each program is assigned a size tier by its approximate number of accounts, and each tier has one limit for requests that include filters and a lower limit for requests without them. Filters raise the limit only within the program’s tier — a filtered request to a program with 1M or more accounts is limited to 3 requests per 20 seconds. The following rules also apply:
  • A program without an assigned size tier, such as a recently deployed program, is limited to 2 RPS with or without filters.
  • Requests to some high-traffic programs at finalized or confirmed commitment are served from a cache under separate per-program limits instead of the size tiers.
  • Unfiltered requests to the SPL Token Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA), Token-2022 (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb), and Kin (kinXdEcpDQeHPEuQnqmUgtYykqKGVFq6CeVX5iAHJq6) are rejected with error -32602 — see getProgramAccounts filters. The SPL Token Program and Kin are also excluded from indexing.
  • A request over the limit returns HTTP 429 with JSON-RPC error -32005.

Solana scan method limits

The account-scan methods — getProgramAccounts, getTokenAccountsByOwner, getTokenAccountsByDelegate, and getSupply — read across a program’s accounts, which on a large program can be hundreds of millions of accounts. To keep one heavy scan from tying up a node, Solana Mainnet Global Nodes run each scan under a 60-second execution-time limit and a per-request memory limit, and run a limited number of scans at once. A scan that waits more than 15 seconds for a free scan slot is dropped without running. A scan that exceeds the execution-time or memory limit is aborted and returns error -32012 rather than hanging:
To keep the scan within the limits, narrow the query — for example with dataSize or memcmp filters on getProgramAccounts. A scan dropped from the queue also returns error -32012, with the message scan aborted: scan abandoned after waiting Nms for a scan slot, where N is the time the request spent queued in milliseconds. The scan never ran, so the same request can succeed later. Retry it with exponential backoff.

Solana accounts excluded from indexing

The following Solana accounts are excluded from the program-id secondary index and cannot be queried with getProgramAccounts. Use getTokenAccountsByOwner instead:
  • TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA — SPL Token Program
  • kinXdEcpDQeHPEuQnqmUgtYykqKGVFq6CeVX5iAHJq6 — Kin

Solana method availability

The following methods are available only on the paid plans:
  • getProgramAccounts
  • getLargestAccounts — this method is available only on Dedicated Nodes.
  • getSupply
  • getTokenAccountsByOwner

Solana archive methods availability

While most methods are supported on Solana Global Nodes, only the following methods can fetch archive data:
  • getSignaturesForAddress
  • getTransaction
  • getBlock
  • getBlocks
  • getBlockHeight
  • getBlockTime
  • getBlocksWithLimit
Note that this is only true for mainnet as there are no Solana archive nodes for Devnet.
Last modified on October 2, 2026