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

What is verified, and what is not

Verifiable RPC is precise about its guarantees. This page states exactly what a verified response proves today and, just as importantly, what it does not yet prove. Knowing the boundary is part of using vRPC correctly. All checks below are fail-closed: if a check fails, the call throws and no unverified data is ever returned.

What is verified today​

For every HTTP response, the SDK enforces that the response is:

  • Signed — vRPC-Signature is a valid Ed25519 signature against the pinned signing key from the response header.
  • Untampered — the signature verifies over a canonical pre-image binding the chain id, the request body, the response body, and the timestamp. Any mutation of the request or response body fails as a bad signature.
  • Fresh — the response timestamp sits inside a replay window (default 60 seconds); a replayed old response is rejected as stale.
  • Correctly chain-bound — verified against the chain id you pinned. A wrong or substituted chain binds a different pre-image and fails, so genuine data from the wrong chain does not slip through when you pin the chain explicitly.
  • Replay-checked — the freshness window plus a fresh per-request nonce bound into the attestation quote reject replays of an old response or an old quote.

On the default path, the SDK also runs a mandatory, always-on hardware verifier: the DCAP attestation quote is verified by a cloud verifier (Phala by default, overridable to a self-hosted endpoint) and bound to the response signing key, the nonce, and the compose hash, fail-closed. With no verifier configured, the call fails closed rather than passing unverified.

What is not (yet) verified​

Being explicit here is what makes the guarantee credible. The following are not covered today:

Full local TDX attestation​

The default path does verify the DCAP quote, but it delegates that verdict to a mandatory, always-on cloud verifier (Phala by default), fail-closed, so a forged quote is rejected. What is still deferred:

  • Verifying the quote locally against the Intel PCK root, so you do not have to trust a remote verifier service.
  • RTMR event-log replay.
  • A node-independent compose-hash source. Today's compose-hash check is self-consistency only: both values come from the same node, so it catches drift, not a malicious node. A real anchor needs an independent compose source.
  • TCB-status policy.

If you want the full local chain of trust now, you can run Phala's dstack-verifier against the sidecar's quote yourself. Note also that the default public cloud verifier is no-SLA and publishes submitted quotes; point the verifier at a self-hosted endpoint to avoid that egress.

WebSocket subscription streams​

The sidecar signs HTTP responses only. WebSocket push streams (eth_subscribe) bypass the HTTP signing path and are unverified. Use an HTTP transport for anything you need a signature on. HTTP event polling (via filters) stays on the verified path.

ENS off-chain reads​

ENS off-chain resolution, CCIP-Read, avatar, and IPFS, fetches data from gateways outside the signed RPC path. Those bytes are unverified even when the on-chain RPC legs around them are signed.

Why this matters​

vRPC's value is that you do not have to trust the operator; you verify the math. That claim only holds if the boundary is stated honestly. A verified response is signed, untampered, fresh, correctly chain-bound, and replay-checked, fail-closed. Everything beyond that boundary is documented above so you can decide what you rely on.