Ankr’s RPC Network Surpasses 1 Trillion Monthly Requests Across 80+ Chains

Ankr, a major Web3 infrastructure provider, announced this week that its RPC platform now processes more than 1 trillion requests per month, a milestone that underlines just how much of blockchain activity runs through centralized infrastructure even as apps try to decentralize. The company framed the milestone not as a marketing puff, but as a snapshot of everyday traffic: everything from balance checks to rollup calls and MEV bot pulls.

Remote Procedure Calls (RPCs) are the read/write plumbing of blockchains, the API layer between wallets, dApps and the node fleets that actually hold state. According to Ankr, the largest slices of that trillion-request pie come from wallets and frontends, indexers and analytics services, bots and MEV systems, rollups/L2s and bridges (which generate lots of cross-chain calls), and a long tail of smaller dApps across more than 80 networks.

Those everyday calls include frequent read methods, like eth_call, eth_getBalance and eth_getBlockByNumber, with heavier range and log queries (eth_getLogs), tracing/debug calls, websocket subscriptions for new heads and pending transactions, and a smaller but mission-critical volume of writes such as eth_sendRawTransaction.

What Does it Mean?

Reaching a trillion monthly requests forces trade-offs: reliability, latency and cost all matter when apps depend on on-chain data. Ankr says it addresses those pressures with a mix of network and software engineering: global anycast and regional routing to cut latency, blockchain-aware load balancing, specialized fleets (separating hot reads from archive and trace/debug/ write paths), rate shaping and method-weighted failover logic, plus bespoke infrastructure for enterprise customers with very high throughput. The result, the company argues, is an RPC layer that can handle both the routine, a wallet checking an account balance, and the bursty, a rollup or MEV system hammering endpoints.

For developers, Ankr’s message is practical: you’ll see the best performance if you design your apps to be polite to RPCs . That means using caching, batching calls, pinning traffic to regions, respecting method weights, and monitoring usage by chain and method. In short, optimize how you ask for data as much as where you get it.

Why does this matter? RPCs are the invisible choke points that can make or break user experience. No balance reads, no swaps; no reliable subscriptions, no real-time UX. As more users and services flock to L2s, bridges and multi-chain wallets, the volume and complexity of RPC traffic grow, and with it the need for scalable, resilient infrastructure. Ankr’s trillion-request claim is therefore less a trophy and more a metric of how much of Web3 currently depends on a handful of infrastructure providers.

Ankr’s full thread and breakdown of traffic types is available on their official post. Developers building on Web3 would do well to treat RPCs as a core part of architecture planning, not an afterthought, because behind every smooth balance check or instant swap are thousands of tiny API calls that have to land and return in milliseconds.