Ankr says its RPC platform now processes over 1 trillion requests per month across 80+ chains, powering wallets, dApps, MEV systems and other Web3 services.Ankr says its RPC platform now processes over 1 trillion requests per month across 80+ chains, powering wallets, dApps, MEV systems and other Web3 services.

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

2025/09/25 03:00
blockchain-integration-web3

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.

Disclaimer: The articles reposted on this site are sourced from public platforms and are provided for informational purposes only. They do not necessarily reflect the views of MEXC. All rights remain with the original authors. If you believe any content infringes on third-party rights, please contact service@support.mexc.com for removal. MEXC makes no guarantees regarding the accuracy, completeness, or timeliness of the content and is not responsible for any actions taken based on the information provided. The content does not constitute financial, legal, or other professional advice, nor should it be considered a recommendation or endorsement by MEXC.
Share Insights

You May Also Like

Preliminary analysis of the Balancer V2 attack, which resulted in a loss of $120 million.

Preliminary analysis of the Balancer V2 attack, which resulted in a loss of $120 million.

On November 3, the Balancer V2 protocol and its fork projects were attacked on multiple chains, resulting in a serious loss of more than $120 million. BlockSec issued an early warning at the first opportunity [1] and gave a preliminary analysis conclusion [2]. This was a highly complex attack. Our preliminary analysis showed that the root cause was that the attacker manipulated the invariant, thereby distorting the calculation of the price of BPT (Balancer Pool Token) -- that is, the LP token of Balancer Pool -- so that it could profit in a stable pool through a batchSwap operation. Background Information 1. Scaling and Rounding To standardize the decimal places of different tokens, the Balancer contract will: upscale: Upscales the balance and amount to a uniform internal precision before performing the calculation; downscale: Reduces the result to its original precision and performs directional rounding (e.g., inputs are usually rounded up to ensure the pool is not under-filled; output paths are often truncated downwards). Conclusion: Within the same transaction, the asymmetrical rounding direction used in different stages can lead to a systematic slight deviation when executed repeatedly in very small steps. 2. Prices of D and BPT The Balancer V2 protocol’s Composable Stable Pool[3] and the fork protocol were affected by this attack. Stable Pool is used for assets that are expected to maintain a close 1:1 exchange ratio (or be exchanged at a known exchange rate), allowing large exchanges without causing significant price shocks, thereby greatly improving the efficiency of capital utilization between similar or related assets. The pool uses the Stable Math (a Curve-based StableSwap model), where the invariant D represents the pool's "virtual total value". The approximate price of BPT (Pool's LP Token) is: The formula above shows that if D is made smaller on paper (even if no funds are actually withdrawn), the price of BPT will be cheaper. BTP represents the pool share and is used to calculate how many pool reserves can be obtained when withdrawing liquidity. Therefore, if an attacker can obtain more BPT, they can profit when withdrawing liquidity. Attack Analysis Taking an attack transaction on Arbitrum as an example, the batchSwap operation can be divided into three stages: Phase 1: The attacker redeems BPT for the underlying asset to precisely adjust the balance of one of the tokens (cbETH) to a critical point (amount = 9) for rounding. This step sets the stage for the precision loss in the next phase. Phase Two: The attacker uses a carefully crafted quantity (= 8) to swap between another underlying asset (wstETH) and cbETH. Due to rounding down when scaling the token quantity, the calculated Δx is slightly smaller (from 8.918 to 8), causing Δy to be underestimated and the invariant D (derived from Curve's StableSwap model) to be smaller. Since BPT price = D / totalSupply, the BPT price is artificially suppressed. Phase 3: The attackers reverse-swap the underlying assets back to BPT, restoring the balance within the pool while profiting from the depressed price of BPT—acquiring more BPT tokens. Finally, the attacker used another profitable transaction to withdraw liquidity, thereby using the extra BPT to acquire other underlying assets (cbETH and wstETH) in the Pool and thus profit. Attacking the transaction: https://app.blocksec.com/explorer/tx/arbitrum/0x7da32ebc615d0f29a24cacf9d18254bea3a2c730084c690ee40238b1d8b55773 Profitable trades: https://app.blocksec.com/explorer/tx/arbitrum/0x4e5be713d986bcf4afb2ba7362525622acf9c95310bd77cd5911e7ef12d871a9 Reference: [1]https://x.com/Phalcon_xyz/status/1985262010347696312 [2]https://x.com/Phalcon_xyz/status/1985302779263643915 [3]https://docs-v2.balancer.fi/concepts/pools/composable-stable.html
Share
PANews2025/11/04 14:00