Today we are introducing Verifiable RPC, or vRPC, a new addition to Ankr's Web3 API that gives every JSON-RPC response cryptographic proof of its own integrity, checked by your own client before your application ever acts on the data.

Upgrade security with vRPC today →

vRPC Solves a Critical Industry Vulnerability

Every application built on a blockchain rests on an assumption that was rarely thought of until it failed badly: that the RPC node answering a query is telling the truth. Developers spend enormous effort auditing smart contracts, screening transactions, and hardening consensus mechanisms, yet the data pipeline connecting their application to the chain itself is typically trusted by default.

In April 2026, that assumption proved costly when compromised RPC nodes returned fabricated eth_call results to unsuspecting backends. There was no malicious transaction to flag and no consensus rule being broken. The infrastructure simply reported state that did not exist, and systems built to act on trusted data did exactly what they were designed to do: they acted on it. The result was millions in losses authorized against a version of the blockchain that was never real.

This was not a smart contract bug or the product of a phished private key. It was a failure at the layer beneath the application, in the infrastructure that every wallet, bridge, exchange, and lending protocol depends on without a way to verify. That distinction matters, because it means the exposure is not specific to one protocol's code quality or one team's operational discipline.

Any system that reads blockchain state through RPC, which is to say nearly every system in the industry, carries this risk today, regardless of provider. vRPC offers a vital security patch.

Why the Existing Security Stack Doesn't Cover This

The Web3 security stack has matured considerably over the past several years, but each layer within it was designed to solve a different problem. Wallet and transaction screening tools operate at the application layer, evaluating what a user is about to sign and flagging patterns associated with known attack types. This is valuable work, but it is fundamentally probabilistic, and it depends on there being a transaction to inspect in the first place. Light clients, where they exist, verify consensus directly against the chain, which is a strong guarantee, but one that is only available on a subset of networks and only covers the specific data a light client is built to check.

Neither layer addresses what happened in April. There was no transaction pattern to screen because the exploit occurred before any transaction was constructed. There was no consensus violation because the fabricated response never touched the chain at all; it was manufactured entirely at the RPC layer and handed to a backend that had no independent means of verifying it. This is the structural blind spot in the current stack: the infrastructure layer, where raw chain data first reaches an application, has historically been the one link in the chain that nothing else was built to verify.

vRPC is designed to sit precisely at that layer, underneath wallet screening and alongside light clients rather than in competition with either.

How Verifiable RPC Establishes Trust

The design principle behind vRPC is straightforward to state and considerably harder to build: every response leaving an Ankr node should carry cryptographic proof of its own integrity, verifiable by the client itself, without requiring a round trip back to Ankr or blind faith in the provider's word.

This is accomplished through three layered mechanisms.

• Attested execution. The component responsible for signing responses runs inside an Intel TDX enclave, co-located with the node itself. TDX is Intel's hardware-based confidential computing architecture, and it works by carving out an isolated "trust domain" within the processor that remains protected even from the host operating system, the hypervisor, and anyone with administrative access to the underlying machine. In practice, this means that even if the surrounding infrastructure were compromised, the code running inside the enclave, and the keys it uses to sign responses, would remain inaccessible to an attacker. The enclave's identity is a cryptographic measurement of the exact binary in production, and that measurement is published to a signed public registry rather than asserted privately, so the claim of what is running inside the enclave can be independently checked rather than taken on trust.

• Signed responses. Each JSON-RPC response carries an Ed25519 signature computed over the request, the response, the chain ID, and a timestamp. This travels in three additional HTTP headers alongside the response, meaning the JSON-RPC payload itself remains byte-identical to what your application already expects. There is no new protocol to adopt and no schema migration to plan for.

• Client-side verification. Verification happens locally, inside your own stack, using a drop-in replacement for your existing ethers or viem provider, or as a lightweight verifying proxy in front of your backend if you would rather not touch client code. Signature checks resolve in microseconds. The one meaningful exception is the first response received from a given signing node, which triggers a one-time hardware attestation check against the Phala verifier, a process that can also be self-hosted for teams that prefer not to depend on a third party even for this step. That check is cached, so every subsequent response from that node verifies at the same microsecond speed as the signature check alone. If a response fails verification at any point, whether the signature is invalid or the underlying attestation cannot be confirmed, the client fails closed. Tampered data never reaches your application logic.

Where vRPC Matters Most

The systems with the most to gain from verifiable data are, unsurprisingly, the ones already handling the largest financial exposure per read.

Bridges and decentralized validator networks depend on RPC reads to determine what state to relay or attest to across chains, and a forged read at that stage can propagate an incorrect state to every chain downstream of it.

Real-world asset platforms compute redemptions and net asset value directly from on-chain reads, and a fabricated balance or price feed can trigger a redemption against collateral that was never actually there.

Custodians and exchanges rely on RPC data to construct proof-of-reserves attestations that auditors and regulators are increasingly expected to trust. Trading and liquidation engines make automated decisions in milliseconds based on state they have no ability to independently confirm in real time.

In each case, the cost of a single forged response scales with the amount of capital the system is willing to move on the strength of that data, which is precisely why RPC-layer integrity has moved from a theoretical concern to an active line item in enterprise risk assessments.

Turning Cryptographic Proof into Compliance Evidence

Beyond the immediate security case, vRPC produces something that has been notably absent from most Web3 infrastructure: a durable, independently verifiable record of every read a system relied on. That record maps cleanly onto language that compliance and audit teams already work with. The Markets in Crypto-Assets regulation's expectations around a complete, machine-readable audit trail are satisfied by signed envelopes that exist for exactly that purpose.

The Federal Reserve's SR 11-7 guidance calls for validation layers that check model outputs against verified data sources, which describes precisely the function vRPC performs upstream of any model or automated decision system. SOC 2's Processing Integrity criteria ask for deterministic authentication of inputs before they are acted upon, and a signed, attested response is a direct answer to that requirement. Ankr currently holds SOC 2 Type II certification, with ISO 27001 certification underway, and vRPC is built to extend that same posture of verifiable assurance down to the data layer itself.

For teams that have historically had to explain to auditors that RPC data is trusted because the provider is reputable, vRPC offers something categorically stronger: proof that does not depend on reputation at all.

An Open Standard, Not a Silo

We deliberately built vRPC to be adoptable industry-wide. The wire format adds three documented HTTP headers and nothing else. The client SDK is released under Apache 2.0, and the signing sidecar is released under AGPL 3.0. The attestation model is designed to align with the IETF's Remote Attestation Procedures architecture (RFC 9334), an existing standards effort for describing how attestation evidence is produced, conveyed, and appraised across systems.

We are also bringing vRPC to Ethereum Magicians as a proposed Interface EIP, with the explicit intent that it complement protocol-level integrity efforts such as EIP-7792 rather than compete with them.

The reasoning behind this openness is simple. RPC-layer forgery is not a problem that benefits from a single vendor holding the only solution. It is a systemic exposure across the industry, and the value of verifiable infrastructure increases as more of the ecosystem adopts a common, auditable standard for it. Any RPC provider is free to implement vRPC. We believe the industry is better served if they do.

Getting Started

vRPC currently runs across the 100+ chains Ankr already operates, spanning EVM and non-EVM networks, provisioned on dedicated TDX capacity that we scale in coordination with the teams adopting it. For organizations ready to evaluate, we offer a 30-minute technical scoping call, after which we return a scoped integration plan specific to your stack, typically requiring no code changes to begin a pilot. We are currently accepting a limited number of design-partner teams for early access this quarter.

The infrastructure layer has been the one part of the Web3 stack that nothing else could verify. That is no longer the case.

Get started with vRPC →

Join the Conversation on Ankr’s Channels!

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