For AI agents: an LLM-friendly Markdown version of every page is available by appending .md to its URL or by sending an Accept: text/markdown request header. The full documentation index is at https://www.ankr.com/docs/llms.txt
Skip to main content

Verifiable RPC (vRPC)

Verifiable RPC (vRPC) returns cryptographically signed responses. Each one carries proof that it came from an approved, unmodified blockchain node running inside an Intel TDX hardware enclave, and that it was not altered in transit. Your client verifies that proof on every response before the data reaches your code, so you no longer have to take the operator's word that an RPC reply is genuine.

vRPC works with regular JSON-RPC calls and with path-based REST chains, and it is a one-line change to adopt: swap your ethers or viem client for the vRPC drop-in, and every existing call keeps working, now verified.

The problem it solves​

When you call an RPC endpoint, you implicitly trust that the operator returns real chain data and runs the software they claim. Nothing in a plain RPC response lets you check that. A response can be altered in memory, or served by a compromised or mis-routed node, and a standard client has no way to tell the difference between falsified data and the truth.

vRPC closes that gap. A node that does not hold the enclave's signing key cannot produce a valid signature, so a falsified or tampered response fails verification at your client before you ever act on it.

How the attestation flow works​

A vRPC node runs a sidecar in front of the blockchain node, both inside an Intel TDX confidential VM. The sidecar signs every response with an Ed25519 key that is generated inside the enclave and never leaves it. The public half of that key is bound into the enclave's hardware attestation quote, so anyone can confirm the key signing your responses really belongs to that enclave.

Each response carries three headers, vRPC-Pubkey, vRPC-Timestamp, and vRPC-Signature. The signature covers a canonical pre-image built from the chain id, the request body, the response body, and the signing timestamp. Your client rebuilds that pre-image from the bytes it sent and received and verifies the signature locally, so the check adds no network round-trip to a call. The hardware attestation quote is fetched once per node and cached, keeping it off the hot path.

Verification is fail-closed: if the signature, freshness, or chain binding does not check out, the call throws and you get nothing back. The client never hands you unverified data. For the exact list of what is and is not verified today, see What is verified.

Beyond EVM: JSON-RPC and REST​

vRPC is not limited to JSON-RPC. Responses from path-based REST chains (for example TON's REST API or Stellar Horizon) carry the same signed vRPC-* headers over the same pre-image, so they are verifiable with the same primitives. The ethers and viem drop-ins cover EVM JSON-RPC; the transport-agnostic core package verifies any signed HTTP response, including REST.

A one-line integration​

You pass a single plain URL. The SDK derives the verifiable route and the attestation route itself, so there is no second base URL to configure and no per-call wiring to maintain. Everything downstream, getBalance, eth_call, contract reads, getLogs, getBlock, estimateGas, works exactly as before, now verified. See the Quickstart for the exact swap.

Open source​

Both the SDK and the sidecar are open source, so you can read the code, verify the claims, and run the verification yourself:

The trust model does not depend on trusting Ankr: the proof travels with each response, and you verify the math on your own side.

Get started​