The crypto world can seem intensely complicated at times, as it blends some of the most difficult-to-grasp concepts of both computing and finance. And under every Web3 protocol, there is an iceberg of infrastructure and inner workings. This article will cover one of the most ubiquitous aspects of blockchain infrastructure – the enormous amount of Remote Procedure Calls (RPCs) processed every day that make every transaction and function of crypto possible.

Learn more: What Are RPC Nodes and Endpoints?

Ankr’s RPC platform sits at the I/O boundary between apps and blockchains. It provides a frontend for developers to interface with node fleets for 80+ networks and answers an enormous volume of JSON-RPC requests from wallets, dApps, indexers, bots, and rollups, and an array of other parties making onchain queries. As of 2025, Ankr hit 1 trillion monthly RPC requests served as a massive share of Web3 traffic.

This fact presents interesting engineering questions: where do all these requests come from, what exactly are they, and how do you serve them reliably with low tail latency at global scale?

This article walks through the traffic sources, method mix, and the systems patterns Ankr uses to keep RPCs fast and consistent across many chains.

Start Using Ankr’s Free RPC Service →

Who’s generating all this traffic?

1) Wallets and frontends. Every page load or screen change may fire multiple read requests to hydrate balances, token lists, NFT metadata pointers, allowances, nonces, and fee quotes. Think eth_call, eth_getBalance, eth_getBlockByNumber, eth_getTransactionCount, and chain-specific equivalents. JSON-RPC is the lingua franca here.

2) Indexers and analytics. Off-chain services that build search and analytics continually crawl historical and near-tip data. This is heavy on range scans like eth_getLogs and trace/debug calls when supported. Archive access and debug/trace APIs are billed at higher weights precisely because they are compute- and I/O-intensive.

3) Bots and MEV infrastructure. Arbitrage, liquidation, and keeper bots subscribe via WebSockets to pending transactions and new heads, then burst write transactions. The steady background is a high-rate read workload, punctuated by latency-sensitive writes once signals trigger. Ankr exposes WSS and charges subscription and messages received for all chains at all times to account for persistent fan-out.

4) Rollups, L2s, and appchains. Sequencers, provers, and bridges perform intensive RPC usage across L1 and L2. When a new partner chain goes live on Ankr, you will often see a step-function in request volume. Recent examples include Etherlink and Monad additions.

5) Long-tail dApps. The 80+ supported networks mean thousands of projects, together forming a huge traffic distribution. Ankr’s “Chainlist” page is a live directory of the supported networks on which these dApps are deployed.

What those requests are

Across EVM-compatible chains, a representative mix looks like:

• Hot reads (frequently repeated): eth_call, eth_getBalance, eth_blockNumber, eth_getBlockByNumber, eth_getTransactionReceipt. High QPS, cache-friendly near the tip, and the vast majority of traffic by count.
• Range queries and logs: eth_getLogs with from/to block ranges. Expensive if unbounded, often rate-limited or weighted in pricing.
• Trace and debug: trace_block, trace_transaction, debug_traceTransaction. Archive-heavy, large CPU and disk working sets.
• Subscriptions: eth_subscribe over WSS for new heads, logs, and pending transactions. Sustained bandwidth with low per-message latency requirements.
• Writes: eth_sendRawTransaction and equivalents. A small fraction of total requests by count, but operationally critical. Writes can be prioritized and routed to healthy validators with the freshest view of the tip.

Why are there so many RPC requests?

Even a simple wallet load can fan out 10–50 reads per account across assets and allowances. Multiply by users, sessions, and chains, then add:

• Block cadence. At ~12 seconds per Ethereum block, dApps refresh every new head. Chains with sub-second slots generate even more frequent cache invalidations and head polling.
• Subscriptions. A single dashboard may hold 5–20 concurrent WSS subscriptions.
• Indexers. Backfills and continuous ingestion replay history and tail the tip across multiple chains.

Combine these and “billions per day” emerges naturally, which is already world-scale IOPS across dozens of networks.

How Ankr serves it without falling over

1) Global anycast and regional routing. Ankr’s global private fiber network makes it possible to place endpoints close to users and route to the nearest healthy region to reduce RTT and tail latency. Ankr highlights 30+ global regions with bare-metal nodes to shorten roundtrip paths.

2) Blockchain-aware load balancing. Ankr’s blockchain-native load balancer moves beyond generic L4/L7 balancers to a scheduler that understands chain freshness, role specialization, and query type. The balancer chooses nodes not only by health but by tip height, archive vs full role, and method class, which helps avoid stale reads and reduces retries.

3) Horizontal fleet specialization. Separate hot-path full nodes from archive and trace/debug nodes. Keep mempool and write paths isolated. This reduces cache contention and surfaces predictable SLOs for read-heavy endpoints.

4) Backpressure and rate shaping. Free and Premium tiers have request-per-minute ceilings and per-method weights so that heavy scans do not drown hot reads.

5) Failover and health probes attuned to chain semantics. Health is not just HTTP 200. Nodes must be in consensus, synced to within a small delta of the head, and serving correct state roots for the requested block. Ankr discusses failover that keeps request error rates down during node failures or reorgs.

6) Dedicated enterprise throughput. For partners with bursty or guaranteed QPS needs, Ankr provisions dedicated infra and higher RPS ceilings.

Read vs write: why RPCs are essential to blockchain UX

RPC is not an optional convenience. Every read of chain state and every write of a transaction flows through an RPC interface, typically JSON-RPC over HTTPS or WebSockets. Without RPC, there is no web3 UX: no balances, no token lists, no swaps, no mints, no bridges. That is why the majority of ecosystem traffic is RPC, not gossip or P2P.

Multi-chain reality: 80+ networks is not “just more endpoints”

Supporting many networks means:

• Heterogeneous method sets and quirks. EVM chains diverge on limits, features, and performance. Solana, Cosmos SDK chains, Aptos, and others have non-EVM APIs and different scaling bottlenecks.
• Version skew and protocol upgrades. Mainnet and testnets advance at different paces. The balancer must be upgrade-aware to keep endpoints consistent during forks and hard-fork windows.
• Cross-chain developer ergonomics. A common dashboard, per-project tokens, usage analytics, and statistics by chain, method, IP, and country help developers control costs and debug.
• Rolling onboarding of new chains. New RPCs for networks like Etherlink and high-throughput environments such as Monad add both traffic and capabilities.

Developer tips for making the most of your RPC usage

• Design for caching. Batch calls and prefer block-pinned reads when you can. You will get better cache hit rates and stable latencies near the tip.
• Budget for method weights. If you use traces, plan for higher cost and lower throughput ceilings. Move non-interactive scans to batched jobs.
• Use WSS wisely. Subscriptions are great for reactivity but can be noisy. Scope topics tightly and throttle client consumers.
• Pin to regions when latency matters. If you are latency sensitive to a specific sequencer or validator set, talk to your provider about regional routing and dedicated endpoints. Ankr offers enterprise orchestration at high RPS.
• Watch your analytics. Per-project, per-chain, per-method statistics make it obvious where you can trim. Ankr exposes these in the dashboard.

Final thoughts

RPC is the read/write tap of web3. The reason Ankr’s numbers are so large is not hype. It is simply the aggregation of every balance check, allowance probe, log query, mempool subscription, and transaction submission across 80+ chains and thousands of applications. The engineering that turns this chaotic workload into consistently fast responses is the interesting story, and it rests on blockchain-aware load balancing, specialized node fleets, and global anycast infrastructure.

Join the Conversation on Our Channels!

X | Telegram | Substack |  Discord | YouTube | LinkedIn | Reddit | All Links