Remote Procedure Calls (RPC) in Crypto: The Hidden Plumbing of Web3

Remote Procedure Calls, or RPC, are the mechanism that lets wallets, exchanges, DeFi apps and even AI agents talk to blockchains without running their own nodes. In practice, RPC endpoints are the dial‑tone of crypto: every balance check, swap, stablecoin payment or L2 bridge hop rides over them, even if users never see the term on screen.

Introduction

Remote Procedure Call is a decades‑old computer science pattern that allows one program to request that another program, often running on a different machine, execute a function as if it were local. In Web3, this abstraction has become the standard way for applications to query blockchains and submit transactions: your wallet does not “speak Ethereum” or “speak Starknet” directly, it speaks RPC to a node that does. By standardizing how clients ask for balances, broadcast signed transactions, or read historical logs, RPC turns the messy, stateful internals of a blockchain node into a simple API surface developers can code against.

This layer has quietly grown into critical infrastructure. Full nodes on networks like Bitcoin, Ethereum, Solana or Starknet validate blocks, participate in consensus, and store chain history, but they are not naturally optimized for thousands of concurrent API requests from consumer apps. To solve this, specialized RPC nodes and platforms emerged that focus on serving read and write traffic at scale, while leaving consensus and long‑term storage to other parts of the network. The result is an ecosystem of public RPC endpoints, commercial providers, and bespoke private gateways that together underpin almost every crypto interaction, from a retail stablecoin payment to an institutional MEV‑aware trading strategy.

Recent developments underscore how central this plumbing has become. Layer‑2 systems like Starknet are upgrading their node software and simultaneously deprecating older RPC versions, forcing wallets and dapps to adapt or lose connectivity. Infrastructure companies such as Ankr advertise access to dozens of chains through a single enterprise RPC platform, position this as a way to launch new networks like AB Chain into the stablecoin and payments market, and even re‑architect their load balancers and physical backbone to shave tens of milliseconds off every call. At the same time, exploits like the KelpDAO bridge hack, where attackers poisoned the downstream RPC infrastructure used by a cross‑chain oracle, show that RPC endpoints are not just performance bottlenecks but also security choke points. In parallel, regulators and industry groups debate whether RPC providers are merely “software utilities” or financial intermediaries that should fall under broker‑dealer rules.

This explainer unpacks how RPC actually works in crypto, why it matters for MEV and execution quality, how providers like Ankr, QuickNode and Lava fit into the stack, how RPC design differs across Ethereum, L2s and specialized chains, and what the emerging patterns around security, regulation and resilience mean for users and builders. The goal is to treat RPC not as a niche developer topic, but as a core piece of market infrastructure that the broader crypto audience should understand.

Danicjade

Apr 13, 2026

View article →

The Graph eyes JSON-RPC integration to deliver full-stack Web3 data services, combining indexed data with live chain interaction for streamlined developer experience

𝕏/@graphprotocol • Apr 13, 2026

Top Comment

Benthic

Apr 13, 2026

Graph indexers already run full nodes to serve subgraphs — bolting JSON-RPC onto that infra is low marginal cost for operators but puts GRT tokenomics directly against Alchemy and Infura's pricing models where centralized providers hit 45-115ms response times at scale. The x402 + MCP integration for AI agent pay-per-query is the sleeper feature here; autonomous agents that can query both indexed subgraph data and live chain state through one decentralized gateway with micropayments is a workflow that doesn't cleanly exist yet. Whether indexer QoS can stay competitive when you're routing RPC through a staking-and-dispute layer instead of bare metal is the open question that'll determine if this captures real dev traffic or stays a roadmap bullet point.

What RPC Means in a Blockchain Context

From generic RPC to JSON‑RPC

At its core, RPC is a way for one piece of software (the client) to invoke functions on another (the server) without needing to know anything about how that server is implemented. In classical distributed systems, this took many forms, from language‑specific frameworks to protocol‑agnostic standards. In blockchains, the dominant form is JSON‑RPC, in which requests and responses are encoded as JSON objects sent over HTTP or WebSockets. Ethereum popularized this model by exposing its node functionality via a JSON‑RPC interface that clients can call with methods like eth_getBalance, eth_sendRawTransaction, or eth_getLogs. Other EVM‑compatible chains and some non‑EVM systems have converged on similar designs to be compatible with existing tooling.

A JSON‑RPC request typically specifies a method name, parameters, a version indicator, and an identifier. For example, a wallet checking your ETH balance might send a request resembling the following.

``json { "jsonrpc": "2.0", "method": "eth_getBalance", "params": ["0xYourAddressHere", "latest"], "id": 1 } ``

The node, or RPC server, receives this request, executes the corresponding internal function—reading from its local view of chain state—and returns a JSON response with the result and the same identifier so the client can match calls to responses. Many Ethereum JSON‑RPC methods can be grouped into “gossip”, “state”, and “history” categories: gossip methods expose data about pending transactions and new blocks, state methods return current account or contract state, and history methods query past blocks and logs. This separation highlights both the usefulness and the risk of RPC: access to gossip and state lets wallets and DeFi apps react quickly to real‑time conditions, but it also opens the door to MEV, censorship, or manipulation if the data feed is not trustworthy.

Nodes, validation and the need for RPC

To see why specialized RPC nodes exist, it helps to recall the core duties of a blockchain node. On networks like Ethereum or Solana, nodes validate transactions and blocks, enforce consensus rules, and store chain data, often in full copy form. Validation means checking signatures, ensuring transactions follow protocol rules, and confirming that the resulting state transitions are correct; consensus participation involves voting on which blocks are accepted and in which order; storage entails keeping block history and state so that new nodes can synchronize and existing ones can service queries. Nodes also gossip with each other, propagating new transactions and blocks across the peer‑to‑peer network to keep everyone in sync.

While a single node can expose an RPC interface for direct use, application developers quickly run into practical limitations if they try to use a generic full node as the back‑end for a popular wallet or DeFi protocol. Blockchains are optimized for determinism and security, not for serving thousands of concurrent HTTP requests or streaming logs to analytic dashboards. Public full nodes may throttle requests, lack efficient indices for complex queries, or be configured with default settings that are unsuitable for high‑volume or latency‑sensitive workloads. That is why many teams deploy separate RPC nodes, sometimes with extra indexing layers, to expose a more performant and developer‑friendly interface while still drawing data from honest, consensus‑participating nodes underneath.

Specialized RPC platforms extend this pattern by running fleets of such nodes across regions, adding load balancers, caching layers, monitoring, and often custom features for particular ecosystems. Ankr, for example, positions itself as “the world’s largest RPC platform,” claiming access to more than thirty blockchains through a unified interface that can be tailored to specific projects. This kind of abstraction allows a dapp that starts on Ethereum to later add support for Starknet, Polygon or AB Chain’s payments network without learning each chain’s node‑management quirks, relying instead on the provider to supply compatible RPC endpoints for each environment.

RPC as the “bridge” for end users

For end users, the RPC layer is typically invisible yet omnipresent. When a mobile wallet such as Crypto.com Onchain shows a list of tokens and balances, it is issuing RPC calls to a node to read the blockchain and render the results. When the user presses “Send” or “Swap,” the wallet constructs and signs a transaction locally, then uses RPC to broadcast the signed payload to the network for inclusion in a block. Some wallets and browser extensions ship with default RPC endpoints for major chains but allow users to swap the endpoint or add custom ones, precisely because an ideal RPC node should be fast and reliable to avoid lag, stale balances, or failed sends.

Crypto.com’s documentation, for instance, describes an RPC node as a server that helps apps function and verify transactions by letting users read data on the blockchain and send transactions across different networks. Users can navigate into settings, choose the “Networks and RPC” section, and either swap the RPC node for a given blockchain or add a custom RPC node by pasting a URL provided by a service such as Ankr or QuickNode. Sub‑wallets inside the app automatically reflect those RPC URL changes, meaning that simply changing the endpoint can affect the experience across all tokens and DeFi integrations using that network. QuickNode’s guides similarly encourage users to configure custom RPC connections in wallets like Backpack for Solana, emphasising that a dedicated, high‑performance endpoint reduces delays and avoids public RPC congestion.

The result is that every time a user thinks they are “talking to Ethereum,” they are actually talking to whichever RPC node their wallet or app has chosen. That delegation creates both convenience and risk: convenience because it outsources the complexity of running and upgrading nodes, risk because any weakness or misconfiguration in the RPC layer can propagate upstream to wallets, bridges and DeFi apps that rely on its view of the world.

RPC Nodes, Providers and Infrastructure Design

Self‑hosted nodes versus third‑party platforms

Developers deciding how to connect their applications to a blockchain typically face a spectrum of options ranging from running their own nodes to relying entirely on third‑party RPC platforms. Operating a self‑hosted node gives maximum control over configuration, logging and privacy, but it requires expertise in node operations, constant monitoring, sufficient hardware, and timely upgrades in response to protocol changes. When chains like Starknet deprecate an entire RPC version as part of a node release, operators must upgrade not only the consensus software but also the RPC interfaces and their own client code that relies on them.

By contrast, third‑party platforms such as Ankr, QuickNode, Lava Network and others abstract most of this effort. Ankr advertises enterprise‑grade RPC access to more than thirty blockchains, coupled with staking and other infrastructure services, so that teams can build dapps without running any nodes themselves. In some cases, these providers even serve as the launch partner for new networks: AB Chain, a heterogeneous blockchain network designed for stablecoins, payments and interoperable digital financial infrastructure, integrated Ankr’s RPC service from day one so developers could access an AB Chain endpoint and start building without waiting for the community to spin up public nodes. Similarly, some perpetuals exchanges and L2 ecosystems have turned to external RPC platforms when introducing EVM execution layers, outsourcing low‑latency node operations to infrastructure specialists.

The trade‑offs echo those in traditional cloud computing. Running your own nodes is akin to managing on‑premises servers: you own the stack, including its failures, but you control data locality and trust assumptions. Using a large RPC provider is closer to renting space on a specialized cloud: you gain elasticity, global latency optimization and often better observability, at the cost of concentrating trust and tying your uptime to the provider’s operational choices. For many teams, particularly in early stages or during rapid growth, the latter is an acceptable compromise, especially when the provider can offer service‑level guarantees and support around peak events like token launches or airdrops.

Load balancing, latency and specialized routing

Serving blockchain RPC traffic at scale introduces constraints that differ from generic web APIs. Many blockchain queries depend on the node’s perceived block height: if you accidentally route one call to a node that is a few blocks behind and another to one that is fully synced, you can show inconsistent balances or contract states across different screens of the same app. Recognizing this, infrastructure providers have begun to build blockchain‑native load balancers that route traffic based not only on geography and health but also on chain‑specific metrics and block numbers.

Ankr has described how it migrated its RPC traffic from a general‑purpose CDN to a private global fiber network operated by a partner, Asphere, in order to gain more direct control over routing, cut latency by up to eighty percent in some paths, and improve user privacy by reducing exposure to third‑party intermediaries. On top of this network, Ankr built a protocol‑aware load balancer that tracks block height per chain and chooses back‑end nodes that are both healthy and up‑to‑date, avoiding scenarios where users see stale chain data because their requests hit lagging nodes. This style of design highlights how RPC providers have to think simultaneously about network engineering, distributed systems and blockchain‑specific semantics.

Exchanges and trading platforms likewise focus on RPC latency and determinism. Partnerships like Kraken’s work with Lava Network aim to supercharge trading by using specialized RPC infrastructure that minimizes jitter and supports high‑volume order submissions. In DeFi, CoWSwap’s experiments measuring which RPC endpoint delivers the best swap prices on Ethereum underscore that infrastructure choices can have direct financial consequences: they found that an MEV‑aware endpoint called MEV Blocker produced better execution than standard RPC, and warned that using the wrong RPC means “literally” worse token output on every swap. That insight has pushed RPC providers, wallets and aggregators to think about routing not just for availability but also for optimal execution quality.

Multi‑RPC and fallback architectures

Single‑provider reliance creates an obvious failure mode: when that provider or its cloud platform experiences an outage, every app and wallet pointed at its nodes can fail simultaneously. Recent cloud disruptions have made this risk concrete for DeFi, as many RPC providers rely on hyperscale clouds such as AWS, which occasionally report incidents affecting certain regions or services. During such events, some users find that their wallets cannot connect, that DeFi frontends time out when querying balances or positions, or that pending transactions are stuck with no visible status.

A growing response is to build multi‑RPC architectures, in which frontends, backends or middleware can automatically fail over between several providers, or between public and private RPC endpoints. Walrus Sites, a project focused on keeping DeFi frontends reachable during volatility and infrastructure shocks, recently added multi‑aggregator and multi‑RPC fallback support so that apps can continue serving users even if individual RPC providers fail or experience degraded performance. Instead of hard‑coding a single endpoint, a Walrus‑backed frontend can consult several providers in parallel, select the one that responds fastest or most consistently, and swap away from a failing endpoint without manual intervention.

A similar pattern appears at the wallet level, where products like Crypto.com’s Onchain wallet or Backpack allow users to swap RPC nodes, add custom endpoints, or delete custom nodes that misbehave. Because the wallet maintains configuration per chain, changing the RPC URL automatically applies to all sub‑wallets and token integrations for that network. This makes it possible for sophisticated users to add MEV‑protecting endpoints for Ethereum, low‑latency Solana endpoints for NFT trading, or private RPC nodes for testing. It also underscores how critical endpoint maintenance is: if a widely used public RPC for a given chain upgrades with breaking changes or drops support for historical queries, wallets and dapps that do not adapt can silently degrade.

Public RPCs versus dedicated enterprise endpoints

Most chains maintain at least one “public RPC” endpoint, often funded by the foundation or core development teams, to provide low‑friction access for developers and users. However, these public endpoints are typically throttled, may lack full historical data, and are more prone to congestion during network spikes. Coverage from across the ecosystem has highlighted instances where public RPC upgrades triggered service interruptions and reduced access to older block history, prompting teams to set up backup endpoints or rent capacity from commercial providers to ensure continuity.

Enterprise RPC platforms, by contrast, sell access to dedicated or prioritized nodes with higher rate limits, stronger uptime guarantees, and sometimes advanced features like request replay protection, custom indexing, or regulatory‑grade logging. Ankr’s enterprise offering, for example, has been used by companies like Uniblock to support scalable growth without managing node fleets in‑house, promising “blazing‑fast blockchain connections” tailored to each project. Similarly, some providers partner with AI‑centric stacks such as ObolClaw to pre‑load AI agents with access to a reliable Ethereum RPC hosted by a trusted operator, allowing agents to interact with the blockchain without managing API keys or maintaining their own node balances.

The resulting landscape is stratified: hobbyists and small projects often rely on public RPCs or free community tiers of providers; growth‑stage DeFi protocols adopt a mix of paid RPC and self‑hosted nodes; exchanges, stablecoin issuers and institutional DeFi platforms invest in multi‑region, multi‑provider setups with custom routing and monitoring. In all cases, though, the RPC interface remains the common abstraction through which applications see the chain.

RPC Across Ethereum, L2s and Other Ecosystems

Ethereum’s JSON‑RPC as a de facto standard

Ethereum’s implementation of JSON‑RPC has become the baseline for much of the industry. The public documentation outlines a range of methods that dapps can use to interact with the network, grouped roughly by the kind of data they access. Gossip‑oriented calls might fetch information about pending transactions or subscribe to new block events over WebSockets, state queries return account balances or contract storage at a given block, and history calls retrieve past blocks, logs, and receipts. When a transaction is sent via eth_sendRawTransaction, the node accepts the signed payload, adds it to its transaction pool, and returns a hash that clients can use to track its progress. Once the transaction is mined, dapps can call eth_getTransactionReceipt to learn in which block it was included, how much gas was used by the EVM, and whether a new contract was created.

The fact that many EVM‑compatible chains adopt Ethereum’s JSON‑RPC schema makes life easier for infrastructure providers and developers alike. Hedera’s Hiero JSON‑RPC Relay, which exposes an Ethereum‑like interface over the Hedera network, recently changed several default configuration values precisely to better align its behaviour with what developers expect from standard Ethereum JSON‑RPC implementations. Those changes included enabling a transaction pool by default so pending transactions are tracked in memory, enabling WebSocket subscriptions, and disabling some rate limits, thereby making the relay behave more like the typical Ethereum node setups that existing tools assume. At the same time, the Hedera team warned operators that turning on features like transaction pools and subscriptions would increase memory usage and the number of long‑lived connections, highlighting the operational implications of mimicking Ethereum semantics.

Bitcoin, by contrast, has its own RPC interface tailored to UTXO‑based semantics, and its node implementations periodically add new RPC fields and methods as part of software releases. Bitcoin ABC’s recent update, for example, introduced a new RPC field alongside other under‑the‑hood improvements in its 0.32.11 release, reflecting the ongoing evolution of RPC interfaces even in more conservative ecosystems. For application developers, this means that while Ethereum JSON‑RPC has emerged as a de facto standard in the EVM world, they still must handle idiosyncrasies across non‑EVM chains and keep pace with incremental changes.

L2s, Starknet and the role of RPC versioning

Layer‑2 systems introduce additional complexity because they often run their own execution environments and settlement cycles while attempting to feel “Ethereum‑like” to users and developers. Starknet, a zk‑rollup that executes smart contracts in its own Cairo VM while settling proofs to Ethereum, illustrates how tightly coupled RPC interfaces are to the protocol’s evolution. The upcoming Starknet v0.14.3 release, scheduled for testnet and mainnet rollout, includes several major changes: an automatic algorithm for adjusting the minimum L2 gas base fee according to the STRK token price, more frequent and typically smaller blocks to reduce latency, and a reduction in the target L2 gas per block while keeping the maximum block size unchanged. These modifications are codified in various Starknet Improvement Proposals and require node operators and wallets to update their software to keep gas estimations and block expectations aligned with the network’s new behaviour.

Crucially, v0.14.3 also deprecates Starknet’s RPC version 0.8, which had been introduced in May 2025. Starting from this release, full nodes and SDKs will no longer support RPC 0.8, and new versions will only support RPC 0.9 or 0.10.1, with the latter recommended for most applications. That means any wallet, dapp or middleware that still speaks RPC 0.8 must migrate or risk losing connectivity. The Starknet team has emphasised that applications should plan their migrations carefully, as changes in the communication between the feeder gateway and full nodes may affect how quickly transactions are visible and how preconfirmation‑like data flows. For developers, this underscores that RPC is not a static contract: as L2s evolve their gas models, proof systems and block cadence, they may also version and deprecate RPC methods, forcing clients to track compatibility closely.

Other L2s make similar adjustments. Prover infrastructure upgrades, such as those seen in certain zk‑rollup ecosystems, have aimed to reduce the cost of RPC calls by improving internal task databases, optimizing pricing across ETH, USD and native tokens, and eliminating redundant calls. The broad pattern is that as L2s chase lower fees and higher throughput, their node and RPC implementations must become more efficient and sometimes more opinionated, which in turn pushes RPC providers and client libraries to adapt.

Polygon, private mempools and MEV‑aware RPC

Polygon offers another instructive example of how RPC endpoints can be specialized for particular concerns, in this case protection against Miner/Maximal Extractable Value (MEV). The Polygon team recently launched a “Private Mempool” feature: a private transaction submission endpoint that protects transactions from frontrunning and sandwich attacks by keeping them out of the public mempool until they are included in a block. Rather than requiring developers to rewrite their applications, Polygon designed the feature so that users can simply swap their transaction submission RPC endpoint to the Private Mempool URL, while continuing to perform read operations through their existing providers.

This means that dapps can integrate MEV protection with essentially a one‑line change to their RPC configuration. Transactions submitted through the private endpoint bypass the public gossip layer where MEV bots monitor pending transactions, making it significantly harder for adversaries to reorder, front‑run or sandwich user trades. Enterprise tiers of the service are available for production workloads, reflecting the demand from large DeFi projects and exchanges for stronger execution guarantees. Polygon’s design demonstrates that RPC is not merely a passive conduit for data but a point where networks can offer differentiated services, such as MEV protection, without changing the underlying consensus rules.

Other experiments in MEV‑aware RPC include community‑run endpoints like MEV Blocker on Ethereum, which CoWSwap has highlighted as delivering better swap prices compared with standard RPC endpoints. By routing transactions through an endpoint that cooperates with a network of searchers and builders to minimize harmful MEV, users can achieve more favourable execution while keeping their existing dapps and wallets unchanged. Again, the change is purely at the RPC configuration level, underlining how much power is concentrated in this seemingly mundane setting.

Specialized payment chains and stablecoin‑centric RPC

Beyond general‑purpose smart contract platforms, specialized networks for stablecoins and payments are also leaning heavily on RPC infrastructure. AB Chain, for example, is described as a heterogeneous blockchain network designed to power stablecoins, payments, and interoperable digital financial infrastructure in a world where stablecoin supply has grown into the hundreds of billions of dollars. To accelerate adoption, AB Chain integrated Ankr’s RPC service from its launch, giving developers a ready‑made AB Chain endpoint through Ankr’s portal. In effect, the chain’s value proposition—fast, low‑cost payments and omnichain stablecoin assets—depends on having reliable, low‑latency RPC access for wallets, merchant processors and cross‑chain bridges.

As stablecoins increasingly serve as the transactional backbone for both DeFi and real‑world payments, the importance of their RPC infrastructure will grow in lockstep. Retail wallet users may tolerate occasional hiccups when swapping volatile tokens, but merchants and payroll providers rely on predictable confirmation times and accurate, up‑to‑date balances for stablecoin transfers. Any instability in the RPC layer, whether from cloud outages, misconfigured rate limits or incompatible software upgrades, can translate into failed payments or misreported account states. In this sense, the RPC infrastructure around stablecoin‑centric chains functions as a new kind of payment rail, even if the base layer remains permissionless and decentralized.

w00tcake

Apr 20, 2026

View article →

LayerZero attributes KelpDAO exploit with Lazarus Group. RPC probably the culprit

𝕏/@layerzero_core • Apr 20, 2026

Top Comment

Benthic

Apr 20, 2026

RPC compromise as the vector tracks the Radiant playbook from October 2024 — contracts worked fine, but signers saw sanitized calldata while malicious payloads hit the chain. Lazarus has moved past contract-level exploits; the game now is social engineering into dev infra, then MITM on the signing flow. Audit budgets don't close this gap — you need hardware-enforced calldata verification before any multisig signs.

Performance, Cost and Execution Quality

How RPC affects user experience

From the end user’s perspective, the most visible effects of RPC choices are speed, reliability and apparent correctness. A slow or overloaded RPC endpoint can make a wallet feel laggy, with balances taking seconds to refresh or transactions stuck in a “pending” state long after they have been finalized on chain. In contrast, a fast, well‑tuned endpoint gives a near‑real‑time view of the network, with new blocks and events appearing smoothly as they occur. For traders, this difference translates directly into how quickly they can react to price moves, adjust positions, or monitor risk.

RPC can also affect perceived correctness. If a dapp queries different endpoints that are out of sync, it might display inconsistent information about the same address. An RPC node that lags several blocks behind can show outdated balances, making it seem as though a transfer has not arrived when it has already been confirmed. For chains with complex state, such as L2s where sequencer and settlement states can diverge temporarily, developers must be especially careful to use consistent RPC vantage points, or risk confusing users with contradictory status indicators.

The cost dimension is more subtle but no less important. While most consumer wallets do not pass RPC costs directly to users, the economics matter for app developers, especially those serving large audiences or running data‑intensive analytics. RPC providers typically charge based on request volume, bandwidth, or method mix, so poorly optimized dapps that make redundant or heavy calls can incur substantial bills. Prover node upgrades in some L2 ecosystems have specifically targeted these pain points by introducing more efficient methods, caching and job profitability comparisons that reduce the number of RPC calls needed for tasks like proof generation, thereby lowering costs for both infrastructure operators and their downstream users.

MEV, routing and price improvement

Execution quality in DeFi is increasingly shaped by MEV dynamics, and RPC plays a pivotal role in routing transactions into the relevant ecosystems. When a user submits a swap through a DEX aggregator, the transaction may travel to the network’s public mempool via a standard RPC endpoint, where arbitrage bots can see it and attempt to exploit it through frontrunning or sandwiching. MEV‑aware RPC endpoints attempt to mitigate this by either keeping transactions private until inclusion or by coordinating with trusted builders to secure better ordering and back‑run sharing arrangements.

Polygon’s Private Mempool RPC endpoint exemplifies the first approach by providing a write‑only endpoint that bypasses the public mempool and delivers transactions directly to validators or block builders participating in the private system. By simply switching their transaction submission RPC URL to this endpoint, users can protect themselves from common forms of MEV without changing their dapp logic or wallet interfaces. CoWSwap’s advocacy of MEV Blocker on Ethereum illustrates a complementary model in which the RPC endpoint collaborates with a set of searchers and builders who agree to refrain from harmful MEV and share some of the beneficial MEV back with users, thereby improving effective swap prices.

The implication is that two users submitting identical swaps at the same time through different RPC endpoints can receive meaningfully different execution: one may be sandwiched and lose value, while the other benefits from protection and potentially from back‑run revenue sharing. For sophisticated traders and protocols, choosing or even operating their own MEV‑aware RPC endpoints becomes part of their strategy, akin to choosing a prime broker or co‑location facility in traditional markets. For retail users, wallet defaults will likely determine their exposure, which is why wallet teams face increasing pressure to integrate MEV‑protecting endpoints by default.

Cloud costs, migration and provider competition

On the infrastructure side, RPC providers face their own performance and cost balancing act. Hosting large fleets of nodes, each maintaining full or archival chain data across many networks, is expensive both in storage and compute. When a chain undergoes a major upgrade, providers must often spin up new nodes, maintain overlapping versions for a time, and coordinate upgrades with their clients to avoid breaking changes. This operational overhead contributes to the pricing models that developers see.

To remain competitive, some providers are re‑architecting their infrastructure to reduce both latency and cost. Ankr’s decision to migrate its RPC traffic from Cloudflare to Asphere’s private global fiber network is a prominent example: by owning more of the network path, Ankr claims to have reduced latency by up to eighty percent while also gaining more deterministic performance and better privacy for users. The same effort produced a blockchain‑native load balancer that can route based on block height and chain metadata rather than generic health checks. For customers, this kind of optimization can translate into faster user experiences and more stable pricing if providers can pass along cost savings from more efficient operations.

Competition also plays out in feature sets. Some providers differentiate with archival data and advanced indexing for historical analytics, others with specialized endpoints for high‑frequency trading, and still others with compliance‑friendly logging for enterprises subject to regulatory reporting. As The Graph and similar indexing projects explore tighter JSON‑RPC integration—combining indexed data with live chain interaction for a more seamless developer experience—the lines between RPC providers, indexers and data warehouses may blur, giving rise to “full‑stack” Web3 data services that treat RPC as just one interface among many.

Security, Trust and the Dark Side of RPC

RPC as a security boundary

While RPC is conceptually just a way of asking nodes to perform functions, in practice it forms a major security boundary between on‑chain reality and off‑chain systems. Wallets, bridges, cross‑chain messaging protocols and oracles frequently rely on RPC endpoints to derive their view of the chain: they ask “Has this transaction finalized?”, “What is the current state root?”, or “Did this event occur in this block?” The integrity of those answers depends on the honesty and correctness of the RPC servers, and by extension on their data sources and configurations.

The KelpDAO bridge exploit in April 2026 illustrates this risk starkly. According to Chainalysis, attackers linked to North Korea’s Lazarus Group stole roughly 116,500 rsETH, worth around 290–292 million dollars, from KelpDAO’s LayerZero bridge by forging a cross‑chain message. The attack targeted the verification process for cross‑chain messages, specifically the set of nodes whose data fed into the LayerZero Labs Decentralized Verification Network (DVN) responsible for confirming messages. By poisoning the downstream RPC infrastructure used by that DVN, the attackers induced it to confirm a fraudulent cross‑chain message as valid, leading the Ethereum‑side contract to release rsETH to an attacker‑controlled address.

LayerZero itself emphasized in a public statement that its core protocol functioned as intended and that the attack was isolated to a single application due to its modular security design, which allowed multiple DVNs and configurations. Nonetheless, the incident reveals that even when the base protocol and smart contracts are sound, weaknesses in the RPC layer—such as reliance on a narrow set of potentially compromised nodes—can lead to catastrophic exploits. It also underlines the importance of invariant‑based monitoring that compares events across chains, which Chainalysis and others advocate as a way to detect cross‑chain anomalies caused by such infrastructure attacks.

Poisoning, censorship and data integrity

Beyond outright exploits, RPC endpoints present opportunities for censorship, data manipulation or selective withholding of information. Because many users and applications access blockchains primarily through a small set of popular RPC providers, those providers can, in principle, choose not to relay certain transactions, not to serve certain addresses, or to delay or reorder requests. Even when providers act in good faith, external pressures such as regulatory demands or DDoS attacks can indirectly cause certain transactions or users to experience degraded service.

Poisoning attacks, where an attacker feeds false data into an RPC layer, can be subtle. For example, if a cross‑chain protocol samples multiple nodes but those nodes all derive their data from the same compromised RPC infrastructure, the protocol might believe it has diversity when in fact it has a single point of failure. The KelpDAO incident is one such example, but similar dynamics could arise for oracles that read on‑chain data via RPC, data providers that compute indexes, or AI agents that autonomously act on chain based on what they see through their RPC connections. ObolClaw’s model, where AI agents are pre‑loaded with an Ethereum RPC hosted by a specific operator, shows the utility of having a reliable, curated endpoint for agents to interact with Ethereum; it also highlights that if that endpoint were ever subverted, agents could be misled at scale.

Mitigating these risks involves both architectural and operational responses. Architecturally, protocols can use multiple independent data sources, including light clients, direct node connections, and diverse RPC providers, and can design verification schemes that require consensus among them before accepting critical messages. Operationally, providers can invest in hardened infrastructure, anomaly detection, and transparent status reporting. Walrus Sites’ multi‑RPC fallback for DeFi frontends, for instance, is primarily about uptime, but it also introduces opportunities to compare responses across endpoints and detect inconsistencies that might signal corruption or censorship. In this sense, multi‑RPC is not just a resilience pattern but also a security one.

MEV, privacy and front‑running

MEV is another area where RPC choices intersect with security and trust, albeit from a more economic angle. When users broadcast transactions via standard public RPC endpoints, those transactions typically enter a public mempool where bots can see them before inclusion and attempt to extract value by reordering or inserting their own transactions. The resulting frontrunning and sandwiching can significantly worsen user outcomes, especially for large swaps or thin liquidity pools. Private or MEV‑aware RPC endpoints attempt to address this by giving users a more direct or protected route into the block building process.

Polygon’s Private Mempool endpoint, as noted earlier, keeps transactions out of the public mempool, thus preventing many opportunistic MEV strategies from activating. However, it requires trust that the operators of the private mempool will not themselves engage in harmful MEV or censor transactions. Community‑run endpoints like MEV Blocker on Ethereum similarly require some degree of trust in their governance and implementation, though they often publish their principles and code to build credibility. The key point is that RPC configuration becomes a security choice: users and wallets must decide whom to trust to handle their transactions between signing and inclusion.

Privacy also intersects with RPC at the metadata level. Standard RPC calls typically include the caller’s IP address and potentially identifiable patterns of behaviour, which can be logged by providers and correlated across sessions. Providers like Ankr argue that using private global networks and minimizing reliance on third‑party CDNs enhances user privacy by reducing the number of intermediaries that can observe or log RPC traffic. Some privacy‑focused wallets encourage users to run their own nodes or use Tor‑compatible RPC endpoints to reduce metadata leakage. As regulators increase their scrutiny of transaction flows, the logging practices of RPC providers may become a flashpoint, particularly for privacy‑sensitive users transacting in stablecoins or accessing DeFi protocols.

Reliability, Upgrades and Operational Risk

Upgrades, breaking changes and version drift

RPC interfaces are not static; they evolve alongside node software and protocol features. This evolution can introduce breaking changes that propagate up the stack. Starknet’s deprecation of RPC version 0.8 is a clear example: once nodes and SDKs stop supporting that version, any application still using its methods will experience failures, even though the underlying chain continues operating normally. The Starknet team has recommended that applications upgrade to RPC 0.9 or 0.10.1, and has warned that some changes in feeder gateway behaviour may affect latency in how quickly candidate transactions become visible, effectively aligning RPC semantics more closely with final on‑chain execution.

The Hedera Hiero JSON‑RPC Relay update shows another class of changes, where default configuration values are adjusted to better match typical Ethereum expectations. Enabling transaction pools, subscriptions and disabling certain rate limits can improve developer experience but also increase resource usage, which operators must anticipate when upgrading. The Hedera team explicitly advised operators to decide whether they wanted the new defaults or to preserve existing behaviour, and provided configuration snippets for both paths, underscoring that RPC configuration is as much an operational choice as an application interface.

Public RPC endpoints for various chains often undergo similar upgrades, sometimes with less fanfare. Reports of “public RPC upgrade risks” emphasize that changing node software or configurations without backward compatibility can interrupt service for wallets and apps that assume older behaviour, particularly around historical data. For instance, if a public endpoint drops support for certain archival queries to save storage or improve performance, data dashboards and forensic tools relying on those queries may break. This is one reason many serious analytics providers and institutional users insist on their own nodes or paid archival RPC services, even when public endpoints exist.

Outages, cloud dependence and multi‑provider strategies

Outages at the RPC layer can stem from node bugs, misconfigurations, provider network issues, or failures in underlying cloud platforms. The AWS Health Dashboard, for example, regularly reports service incidents affecting compute, networking or storage in specific regions. When RPC providers host their infrastructure on such clouds, these incidents can translate into partial or total loss of blockchain connectivity for their customers. During major outages, users may report that their wallets cannot fetch balances or submit transactions, even though the underlying blockchain continues to produce blocks.

DeFi frontends are particularly sensitive to such disruptions, because they often depend on a narrow set of RPC endpoints and aggregator APIs to fetch pool data, quotes and account positions. Commentators have noted that frontends tend to fail at the worst possible times—during volatility spikes and traffic surges—precisely when users need them most. Walrus Sites’ multi‑RPC and multi‑aggregator support aims to mitigate this by giving frontends multiple “anchors” they can fall back to during storms. Instead of relying on a single provider that may be overwhelmed or offline, a Walrus‑integrated frontend can query several providers and pivot dynamically, preserving reachability even when parts of the infrastructure seascape are in turmoil.

For exchanges, stablecoin issuers and large DeFi protocols, similar logic applies at greater scale. Kraken’s integration with Lava Network’s RPC infrastructure, for example, reflects a desire not only for low latency but also for robustness under high traffic. Some institutions maintain relationships with several RPC providers and run their own nodes as a further backup, effectively layering redundancy. The challenge lies in managing configuration, monitoring and failover logic across this diversity without introducing new failure modes or security gaps.

Wallet configuration, custom RPCs and user control

At the user level, wallets are increasingly exposing RPC configuration as a first‑class setting rather than hiding it behind developer modes. Crypto.com’s Onchain product lets users swap, add or delete RPC nodes for supported chains, warning them when entered URLs appear incorrect and automatically propagating changes across sub‑wallets. QuickNode’s tutorials on adding custom RPCs to wallets like Backpack emphasize how this can improve performance and reliability, especially for busy networks like Solana. This democratization of RPC configuration empowers users but also introduces complexity: a misconfigured or malicious custom RPC can compromise privacy, degrade execution quality, or even facilitate phishing by returning misleading data.

Best practice for users is to favour reputable providers, verify URLs through official channels rather than search engine ads or private messages, and avoid experimenting with critical funds on untrusted endpoints. For power users seeking MEV protection or regional performance gains, it is increasingly common to maintain several custom RPC configurations and switch between them as needed. However, as the KelpDAO incident shows, even reputable setups can be compromised indirectly through poisoned infrastructure, which is why multi‑RPC strategies and robust monitoring are valuable not just at the provider level but also at the protocol and wallet level.

Benthic

Apr 24, 2026

View article →

DeFi Education Fund and Digital Chamber petition SEC to codify broker carve-outs for validators, oracles, and RPC providers

Crowdfundinsider • Apr 24, 2026

Top Comment

Benthic

Apr 24, 2026

DeFi Education Fund, the Digital Chamber, and a coalition of crypto groups petitioned SEC Chair Paul Atkins to open formal notice-and-comment rulemaking that codifies when DeFi activity counts as broker activity. They want explicit carve-outs for validators, oracles, RPC/API providers, data networks, and cloud services — infrastructure the SEC's Division of Markets and Trading already signaled shouldn't require broker-dealer registration. The play is locking that staff position into binding rules before a future administration reverses it.

Regulation, Market Structure and the Role of RPC Providers

Are RPC providers financial intermediaries?

As crypto markets mature, regulators and industry groups are wrestling with how to classify infrastructure providers, including validators, oracles and RPC platforms. In a written input to the U.S. Securities and Exchange Commission, the DeFi Education Fund and the Chamber of Digital Commerce argued that the SEC should codify carve‑outs for such infrastructure providers from broker‑dealer registration requirements, on the grounds that they do not exercise the kind of discretionary control over customer assets and transactions that brokers do. Their submission explicitly mentions API and RPC providers alongside validators and data services, framing them as “other infrastructure providers” whose activities should be supported rather than constrained by securities regulation.

The core debate centres on whether operating an RPC endpoint that transmits transaction data and exposes chain state constitutes “effecting transactions in securities” or otherwise fits within existing broker‑dealer definitions. Proponents of carve‑outs argue that RPC providers act more like Internet service providers or web hosts: they transmit messages and make data accessible but do not advise customers, set prices, or hold assets. Critics might counter that, in practice, RPC providers can exert substantial influence over which transactions get through under what conditions, especially when they operate MEV‑aware or private endpoints, and that they may in fact curate or prioritize order flow in ways that resemble certain brokerage functions.

However regulators ultimately decide, the fact that RPC providers are part of the conversation underscores their systemic importance. For stablecoin issuers, decentralized exchanges, and even institutional lenders using on‑chain collateral, the reliability and neutrality of RPC infrastructure can affect everything from settlement risk to best execution obligations. As more traditional financial institutions experiment with tokenized assets and stablecoin payments, they may demand contractual assurances from RPC providers, pushing the industry toward more formal service level agreements and compliance frameworks.

Economic models and centralization pressures

Economically, RPC providers sit at the intersection of node operations, bandwidth, storage and customer support. Their revenue models typically blend subscription fees, per‑request pricing and enterprise contracts. The capital intensity of running large fleets of nodes across many chains, coupled with the benefits of scale in caching, routing and security, create natural centralization pressures: a handful of large providers can often outcompete smaller ones on price and reliability, potentially leading to a concentrated market for critical infrastructure.

At the same time, there are countervailing forces. Open‑source node software and community‑run public RPC endpoints lower barriers to entry for new providers. Protocols like The Graph, which aims to merge indexed data with live JSON‑RPC interaction, could enable more specialized players to offer value‑added services on top of public or self‑hosted nodes. Multi‑RPC strategies at the application level help mitigate the risks of provider concentration by making it easier to add or swap endpoints, reducing switching costs. Projects that embed light clients or partial node functionality in their applications further dilute dependence on centralized RPC platforms, though at the cost of bandwidth and device resources.

The regulatory environment will also shape economic outcomes. If major jurisdictions were to classify RPC providers as broker‑dealers or similar, compliance costs could reinforce concentration, as only large, well‑capitalized entities would be able to navigate the regulatory overhead. Conversely, clear carve‑outs and recognition of RPC providers as neutral conduits could encourage a more diverse ecosystem of specialized services. For now, most providers operate in a gray zone, mindful of regulatory developments but focused on servicing the immediate demands of rapidly evolving chains and applications.

New Frontiers: AI Agents, Full‑Stack Data and Stablecoin Payments

AI agents and autonomous RPC usage

One of the more novel developments in the RPC landscape is the rise of AI agents that interact with blockchains autonomously. ObolClaw, for example, combines the Obol Stack with OpenClaw agents to let Ethereum users run agents locally that can deploy infrastructure and execute on‑chain actions on their behalf. These agents come pre‑loaded with an Ethereum RPC hosted by DV Labs, local wallet infrastructure, and the ability to expose services to the public web and register on Ethereum as agents with free or paid APIs. In practice, this means that an AI agent can, without human intervention, query chain state, construct transactions, and submit them via RPC, much like a human user with a wallet—only at machine speed and scale.

The presence of a pre‑configured, reliable RPC endpoint is crucial to this model. It frees users from managing API keys or paying for node access, and it ensures that agents have a stable, predictable channel to the blockchain. But it also raises new questions about trust and safety: if the RPC endpoint misbehaves, whether due to compromise, censorship or simple misconfiguration, AI agents could make decisions based on faulty data or fail to execute tasks as intended. As AI‑driven on‑chain activity grows, we can expect more experimentation with agent‑specific RPC endpoints, multi‑RPC verification schemes, and perhaps protocol‑level features designed to make machine‑driven consumption of blockchain data more robust.

Full‑stack Web3 data services

The separation between RPC providers, indexers and analytics platforms is also starting to blur. The Graph, a decentralized indexing protocol, has signalled interest in JSON‑RPC integration to provide a full‑stack Web3 data service that combines indexed data with live chain interaction. The idea is to let developers query historical and aggregated data through GraphQL while also issuing JSON‑RPC calls for current state and transaction submission, all through a unified interface. Such a model would treat RPC as one component in a larger data plane, abstracting away even more of the underlying node complexity.

For developers of stablecoin payment systems, lending protocols, prediction markets or NFT platforms, this integration can streamline architecture: instead of maintaining separate connections to RPC endpoints and indexing services, they can write to a single API that handles both. From an infrastructure perspective, however, this increases the stakes: outages or misconfigurations in such full‑stack providers could simultaneously affect reads and writes, and the complexity of the systems increases the attack surface. Nonetheless, demand for simplifying the developer experience is strong, and many expect full‑stack data services built around JSON‑RPC compatibility to become a standard part of the Web3 tooling landscape.

Stablecoin payments and everyday transactions

Stablecoins are emerging as a core use case for blockchains, with total supply estimates in the 300–320 billion dollar range according to recent industry coverage. Networks like AB Chain are explicitly designed to support fast, low‑cost stablecoin payments and omnichain assets, positioning themselves as the backbone of a new digital payments economy. In such a setting, RPC infrastructure is analogous to payment processor gateways in traditional finance: it must be highly available, low latency, and capable of handling spikes during payroll cycles, e‑commerce peaks or remittance waves.

For merchants accepting stablecoin payments, the RPC layer determines how quickly they can verify that a payment has been initiated, confirmed or potentially reversed. For payroll systems paying employees in stablecoins across multiple chains, RPC endpoints are responsible for reporting balances accurately and providing reliable gas estimation. For cross‑border remittances using stablecoin rails, RPC uptime can directly influence the perceived reliability of the service. As stablecoins move closer to mainstream usage, expectations for RPC reliability will approach those for card networks and bank APIs, even though the underlying infrastructure remains decentralized.

Projects that combine stablecoin payments with L2 scaling, such as rollups that specialize in payments, add further layers. They must juggle RPC connectivity for both the L2 and its settlement layer, ensuring that apps see a consistent picture of finality and do not, for example, treat an L2 transfer as finalized before its risk window on the L1 has passed. Infrastructure providers that can offer coherent, multi‑chain RPC views across L1s, L2s and specialized payment chains will likely find strong demand among payment processors and neobanks looking to tap into stablecoin rails without immersing themselves in node operations.

Outlook

RPC has evolved from a low‑level implementation detail into a critical layer of crypto market infrastructure, shaping everything from user experience and execution quality to security, regulation and the viability of stablecoin payments. As Ethereum and L2s like Starknet continue to iterate on their node software and gas models, RPC interfaces will likewise evolve, with versioning and backward compatibility becoming ongoing concerns for developers and providers. Infrastructure companies such as Ankr, Lava Network and others will keep competing on latency, reliability and feature depth, using techniques like private global fiber networks and blockchain‑native load balancers to differentiate.

At the same time, MEV‑aware and privacy‑preserving RPC endpoints—such as Polygon’s Private Mempool and community projects like MEV Blocker—are likely to proliferate, embedding execution‑side protections into what used to be a neutral transport layer. Security incidents like the KelpDAO exploit will push protocols and bridges to treat RPC not just as a performance concern but as a primary security boundary, prompting wider adoption of multi‑RPC architectures, invariant‑based monitoring and more sophisticated validation of cross‑chain messages. Regulators’ evolving views on RPC providers, as reflected in advocacy for broker‑dealer carve‑outs, will influence how centralized or diverse this layer becomes, especially as traditional institutions and stablecoin issuers deepen their reliance on on‑chain infrastructure.

Over the next few years, the most sophisticated users may barely notice RPC at all, interacting instead with abstracted full‑stack data services, AI agents and wallets that make intelligent, dynamic choices about endpoints behind the scenes. Yet the health of the ecosystem will remain tightly bound to how robust, open and secure these RPC layers are. For a crypto news audience, understanding RPC is therefore not optional technical trivia but a prerequisite for grasping where Web3 infrastructure, MEV mitigation, DeFi resilience and the future of stablecoin payments are headed.