Trust model

This page defines who is trusted for what in Verifiable RPC, and what nobody has to trust. vRPC is trust-minimized, not trustless: the claim is that a response came, byte for byte, from an approved blockchain client and sidecar running inside genuine Intel TDX hardware. For what the SDK checks on each response, see What is verified.

Party or component	Trusted for	Not trusted, verified instead
Intel (TDX hardware)	Memory encryption and isolation, honest measurements, quote signing. This is the root assumption
Publisher of the upstream client image (for example the client team's registry)	The official public image matches their source	Which image ran: that is measured
dstack (OS image, guest agent, key management service)		Open source; every component is measured into the quote
Quote verifier (Phala's cloud verifier by default)	Correct DCAP verification verdicts. The default verifier receives and publishes every quote your SDK submits	Replaceable: open source, self-hostable, pluggable in the SDK (hardwareVerifier)
Ankr (hosts, key service, gateway, network edge)	Liveness. Which node configurations the key service approves: there is no published registry of approved configuration hashes yet, but you can read the images in the attested manifest yourself. Until the SDK checks the platform measurements (MRTD, RTMR0 to RTMR3) and the key provider, also that each node boots the published dstack image with Ankr's key service. In Ankr Confidential RPC mode, also the metadata it sees and not replaying calls	Response integrity on the path, and that the signing key is quoted by genuine TDX hardware, verified cryptographically

The base: Intel TDX

Intel TDX (Trust Domain Extensions) runs a VM as a trust domain. The CPU encrypts and integrity-protects guest memory with keys derived inside the processor and isolates the guest from the host OS, the hypervisor and other VMs. The host can schedule and stop the VM, but cannot read or modify its memory or registers.

TDX also provides measurement and remote attestation. As the VM boots, each stage is hashed into measurement registers: MRTD for the virtual firmware, RTMR0 to RTMR3 for the hardware configuration, the kernel, the command line and initrd, and the runtime application identity. On request, the CPU produces a quote: a signed report with all measurements plus 64 bytes of caller-chosen REPORTDATA. The quote is signed by an attestation key vouched for by Intel's Quoting Enclave, whose certificate chains to the Intel SGX Root CA. DCAP verification checks this chain plus revocation lists and TCB information, and yields a TCB status that reflects the platform's patch level.

Why this is a reasonable root:

• The root of trust is hardware. Quote-signing keys derive from CPU fuses and never leave the die. Forging a quote in software would require breaking Intel's signature chain.
• The trust is narrow and checkable. The one unverifiable assumption is that Intel TDX does what Intel documents. Everything above it, firmware, OS and application, is measured and verifiable against the quote.
• It is the assumption confidential computing already rests on across major clouds, with an active research and TCB-recovery process. Side channels remain a research area; see Residual risks.

dstack and the confidential VM

dstack, Phala's open-source TEE stack, turns raw TDX into an operable platform. Everything it adds stays inside the measurement chain, so you can verify it rather than trust it:

• Reproducible OS image. MRTD and RTMR0 to RTMR2 are pre-computable from the published dstack image and VM specification, so a verifier knows in advance what a legitimate VM measures.
• RTMR3 is the application identity, recorded at runtime through an event log: the compose hash (sha256 of the exact deployment manifest: the container set, images by digest, environment), the key provider, the instance id and the app id.
• The key management service runs in its own confidential VM, with its own quote. It releases the signing key to a node only after the node's quote verifies and its compose hash is on the approved list for that app. Holding the key therefore implies the node booted an approved configuration.
• Substituting the key service is measured. The key provider in RTMR3 binds the node to one key-service root; a different one changes the measurement.
• Disks are encrypted at rest with LUKS2 (aes-xts-plain64) and per-instance keys, so the host sees only ciphertext. XTS gives confidentiality, not authenticated integrity, and the data volume has no dm-integrity; the read-only OS image is integrity-protected separately by dm-verity. See the disk vectors below.

Trusting the container images

The measurement chain proves which images ran: the deployment pins every image by immutable digest, dstack checks digests before pulling, and the manifest bytes are hashed into RTMR3. It cannot prove by itself that an image's binary matches its source code. That is a provenance question, and the answer differs per image.

Sidecar image. Open source (AGPL-3.0), published to GitHub Container Registry by a public CI pipeline, and signed with cosign (Sigstore keyless). The signature binds the image digest to the workflow that built it, so anyone can confirm the image was built from public source by the repository's CI, with no Ankr key to trust.

Blockchain client images. Nodes run the official public images from the client teams' own registries, pinned by digest, so the attestation proves the node ran exactly that official image. The binary inside cannot be checked against its source unless the client ships reproducible builds, and most do not. This is an explicit, named trust assumption, the one virtually every node operator makes; in vRPC it is at least pinned and measured, since a swapped image changes the compose hash and the node loses its key. Reproducible builds and upstream provenance are roadmap work.

Verify the artifacts

The SDK packages are published to npm from CI through npm Trusted Publishing, with no long-lived token, and carry SLSA provenance. Check what you installed:

npm audit signatures

The proxy image is cosign-signed and provenance-attested by the SDK's release workflow:

cosign verify ghcr.io/w3tech/vrpc-proxy:0.4.0 \
  --certificate-identity-regexp 'https://github\.com/w3tech/verifiable-rpc-sdk/\.github/workflows/publish\.yml@.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

gh attestation verify oci://ghcr.io/w3tech/vrpc-proxy:0.4.0 -R w3tech/verifiable-rpc-sdk

The sidecar image is cosign-signed by the sidecar's release workflow:

cosign verify ghcr.io/w3tech/verifiable-rpc-sidecar:v0.5.2 \
  --certificate-identity-regexp 'https://github\.com/w3tech/verifiable-rpc-sidecar/\.github/workflows/publish\.yml@.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

What the attestation proves

One quote, fetched with your nonce, carries a complete chain of trust. Read it bottom up:

1. Genuine hardware. The quote's signature chains through the Quoting Enclave to the Intel SGX Root CA. Software cannot produce it.
2. Unmodified platform. MRTD and RTMR0 to RTMR2 match the published dstack image: the firmware, kernel and boot chain are the open-source stack, not a lookalike prepared by the host.
3. This exact application. The quote commits to the compose hash. The attestation also returns the raw deployment manifest, so a verifier recomputes its sha256 and reads which images, by digest, make up the node.
4. This exact signing key. The first 32 bytes of REPORTDATA are the sidecar's Ed25519 public key. The key is not merely claimed by the sidecar; the CPU quoted it.
5. Fresh, for you. The last 32 bytes of REPORTDATA are your nonce, so the quote was generated now, for this verifier, not replayed.
6. Approved configuration. The key service released the key only to an approved compose hash, so holding the key attests that the configuration was approved.

The proof works by contradiction. Swap the firmware and MRTD mismatches; patch the kernel and RTMR1 or RTMR2 mismatches; change one byte of the deployment (an image, an environment variable, the entrypoint) and the compose hash changes, so the key service withholds the key and the hash check fails; run the sidecar outside a TEE and there is no valid quote at all; present someone else's quote and REPORTDATA does not bind the key and your nonce.

What the attestation does not prove: that the code is bug-free (it proves identity, not correctness), that the node's chain data is canonical, or that the service stays up. Verification has to run outside the VM, which is what the SDK does in your process. Today the SDK checks points 1, 4 and 5, and that the returned manifest matches the compose hash in the quote. It does not yet compare MRTD and RTMR0 to RTMR3 with the published dstack image or check the key provider, so points 2 and 6 rest on Ankr; see What is verified.

What the signature proves

Every response carries an Ed25519 signature, by the attested key, over sha256(chain_id) ‖ sha256(request) ‖ sha256(response) ‖ timestamp_ms. Given a verified attestation for that key, the signature proves:

• Origin: these bytes were produced inside the attested VM, by the sidecar in front of the approved client image.
• Integrity: nothing between the enclave and your process changed a byte: not the load balancer, the gateway, a middlebox or a CDN.
• Request binding: it answers your exact request bytes, not a different question.
• Chain binding: it came from the chain you asked; a BSC response cannot be replayed as Arbitrum.
• Recency: it was signed within the replay window.

What the signature does not prove: that the answer is correct. If the node is on a minority fork, still syncing, or hit by a consensus bug, the sidecar faithfully signs a wrong but authentic answer. vRPC proves the source; for proof of state, combine it with a light client.

Attack vectors and defenses

Vector	Attack	Defense
Compromised host or provider insider	Root on the host, or a hijacked hypervisor or provisioning layer, reads the signing key or tampers with the running node	TDX: the host cannot read or write VM memory; the key exists only inside the enclave and in the key service's own enclave. The host can only stop the node: liveness, not integrity
Disk or state-database tampering	The host edits the VM's data volume so the node serves altered state	Data volumes are LUKS2-encrypted with per-instance keys, so the host sees only ciphertext and a targeted edit is infeasible: flipping ciphertext bits scrambles whole 16-byte blocks into garbage the attacker cannot control. Tampering is not cryptographically detected; it surfaces as database corruption or crashes, a denial of service, not controlled state
Response tampering in transit	A load balancer, proxy, middlebox, CDN or TLS-terminating edge rewrites the response	Ed25519 over the response bytes; the gateway forwards bytes unchanged; the SDK fails closed with BadSignature. TLS is not relied on: the signature holds even over plain HTTP
Request tampering in transit	An on-path attacker modifies the request (for example eth_call params or the block tag) and lets the node answer the altered question	The sidecar signs the hash of the request as received; the SDK rebuilds it from the bytes it sent, so any change fails as BadSignature
Attestation tampering	An on-path attacker rewrites the attestation response: the quote, the key or the manifest	The quote is Intel-signed; a substituted quote fails the REPORTDATA binding or hardware verification; a substituted key fails the match against the response signer; a substituted manifest fails the compose-hash check
Answer substitution	Serving a cached or different response to your request	The request hash is inside the signature; the gateway's response cache is bypassed on vRPC routes
Replay	Re-serving a stale, once-valid signed response	Signed timestamp plus the SDK replay window
Cross-chain replay	Replaying a signed response from another chain's node	The chain id is inside the signature
Fake sidecar outside a TEE	An impostor signs responses with its own key	The SDK requires a quote that carries that key in REPORTDATA; software cannot forge one
Stale or borrowed attestation	Presenting a pre-generated quote or another node's quote	A fresh 32-byte random nonce in REPORTDATA; the attested key must equal the response signer; the gateway resolves the node id exactly, with no fallback
Malicious configuration change	An operator, or an attacker with deploy access, alters the deployment: another image, injected environment, a debug entrypoint	Any byte change gives a new compose hash, and the key service withholds the key unless the new hash is approved. Today approval is Ankr's decision; the SDK checks that the manifest matches its hash, and you can read the manifest
Registry image swap	A registry serves different bytes under the same tag	Images are pinned by digest and checked before pull; the sidecar image is also cosign-signed
Key-service substitution	Pointing the VM at a rogue key service that leaks keys	The key provider is measured into RTMR3; a different one changes the measurement
Fake verifier verdict	Compromising the hardware-verification step	The verifier is pluggable and open source; the default can be replaced with a self-hosted one; the SDK re-checks the bindings against the verifier's parsed output

Residual risks

• Upstream image supply chain. A compromised official client image, through malicious source or a hijacked publish pipeline, is attested like a legitimate one. Today's mitigation is digest pinning of official images; reproducible builds and upstream provenance are roadmap work.
• Disk rollback. A host cannot forge the encrypted volume, but it could revert the whole volume to an older snapshot of itself. The same instance keys decrypt it and the node serves stale but correctly signed data. Timestamps stay fresh, so this shows up as a lagging block height, caught by health and lag monitoring, not by cryptography.
• Snapshot provenance. Nodes bootstrap chain data from snapshots, and clients do not re-verify state against state roots on read. A poisoned snapshot would be served and signed faithfully. Snapshots come from our own nodes and official sources; attestation measures containers, not data volumes.
• TEE side channels. Microarchitectural attacks against TDX are actively researched, and Intel ships TCB updates. Quote verification reports the TCB status; hosts are kept current.
• Application bugs. Attestation proves which code ran, not that it is correct. This applies to the client, the sidecar and dstack alike, all open source.
• Availability. An operator can always shut a node down. vRPC never claims liveness; Ankr is trusted for it.
• Configuration approval. Ankr decides which compose hashes the key service approves, and there is no published registry of approved hashes yet. The attested manifest shows exactly which images a node runs, so a change is visible, but the SDK does not compare it with a list you control.
• Data correctness. Out of scope by design: vRPC cannot detect reorgs, minority forks or majority attacks. Combine it with light clients where you need proof of state.

In Ankr Confidential RPC mode

In Ankr Confidential RPC mode the same chain of trust also carries confidentiality: the client encrypts each call to the attested signing key, in its X25519 form, so only the attested VM can read it.

• Ankr gateway and edge, logs and telemetry: not trusted for confidentiality. They see ciphertext and metadata (API key, client IP address, chain, node, sizes, status, timing, number of calls in a batch). Still trusted for liveness, and now also for not replaying calls: a replay runs the call again, but only the original client can read the answer.
• Operator of the node's host: not trusted. TDX keeps the plaintext in VM memory. This holds only while the node's logs stay inside the VM: blockchain clients log failed calls with method and error data, so the approved configuration must keep log export off (dstack public_logs: false, readable in the attested manifest). During the demo phase it is not off yet.
• The key service and the approved configurations: now trusted for confidentiality as well. Any node software version Ankr approves for that node can derive the same key, decrypt recorded traffic to it and answer future calls, because there is no forward secrecy. Approving a configuration therefore also grants read access to that node's encrypted traffic.
• The node and the sidecar: see the plaintext by design; the attestation proves which code that is.