Verify the trust anchor

What fetchTrustedManifest actually checks, and when the unsafe_trust_server opt-out is (and isn’t) appropriate.

trustAnchor is a required field on T3nClient — the client throws immediately at construction if it’s missing or malformed. It decides whether the SDK verifies it’s really talking to a genuine T3N enclave running the official image, or simply trusts whatever the server presents.

There are three valid values, and the difference is a security boundary, not a style preference:

Option	Meaning	Use for
await resolveTrustAnchor(env)	One-call convenience: fetches and verifies the environment’s trust manifest and hands back a ready-to-use TrustAnchor. Same verification as fetchTrustedManifest, less boilerplate.	Any hosted node (testnet, production) — the default recommendation
await fetchTrustedManifest(env)	Fetches the operator-signed trust manifest for the environment, verifies its signature against a public key baked into the SDK, and returns a verified anchor. Use this form directly when you need the lower-level control (e.g. passing { minVersion }, see below).	Any hosted node (testnet, production)
{ unsafe_trust_server: true }	No verification at all — the client accepts whatever attestation the server presents.	Local dev nodes only

import { T3nClient, resolveTrustAnchor, loadWasmComponent } from "@terminal3/t3n-sdk";

const client = new T3nClient({
  trustAnchor: await resolveTrustAnchor("testnet"),
  wasmComponent: await loadWasmComponent(),
  // ...handlers, as in Quickstart
});

unsafe_trust_server is correct only for local development. A local node has no genuine TDX hardware quote to present, so real verification cannot succeed there. Never pass it against a hosted node, and never write a catch that silently falls back to it — that would remove the protection without telling you the cluster stopped serving a manifest.

What happens: resolveTrustAnchor(env) (or the equivalent fetchTrustedManifest(env) call) fetches the manifest the node itself serves at GET /api/trust-manifest, checks its ECDSA signature against a public key pinned in the SDK, and — only if that passes — returns a TrustAnchor pinning the node’s expected peer IDs and two allow-listed measurements: rtmr1_allowlist and rtmr3_allowlist. If the manifest is missing, unsigned, signed by the wrong key, or older than one this process already accepted, it throws rather than falling back to trusting the server. Handle the throw; don’t catch it and substitute unsafe_trust_server.

RTMR1 is the measurement that matters now. As of testnet-v1.0.10, the node measures rootfs integrity via dm-verity + a Unified Kernel Image, which lands in RTMR1 — rtmr1_allowlist is the real, current integrity signal. tee-init.sh no longer extends RTMR3, so rtmr3_allowlist is kept only for backward compatibility with older attestation consumers; don’t treat it as meaningful going forward. TrustAnchor gained rtmr1_allowlist as a required field in this release — if you construct a TrustAnchor by hand instead of through resolveTrustAnchor/fetchTrustedManifest, you must supply it.

Attestation verification is now vendor-aware. As of testnet-v1.0.10, the SDK can verify both TDX (RTMR1/RTMR3) and AMD SEV-SNP attestation — the trust manifest schema gained two optional fields, sev_snp_measurement_allowlist and sev_snp_product, alongside the existing rtmr1_allowlist/rtmr3_allowlist. resolveTrustAnchor/fetchTrustedManifest handle both transparently — nothing changes in the code above regardless of which hardware the cluster you’re targeting runs on. If you need the lower-level primitives directly (verifying a raw quote yourself rather than going through a T3nClient), new exports cover the SEV-SNP side: verifyDkgAttestation (vendor-aware, dispatches automatically), verifySevSnpReport, detectQuoteVendor, sevSnpVcekUrl, fetchSevSnpCollateral. The existing verifyTdxQuote is unchanged. Most developers on the shared testnet/production clusters (TDX hardware) will never need these directly — they matter for a private-cloud cluster that runs on SEV-SNP hardware.

Rollback protection is per-process. The manifest version floor is held in memory and lost when your process restarts. If you need a client to reject an older manifest across restarts (protecting against a replayed pre-rotation manifest), persist the accepted version yourself and pass it back via fetchTrustedManifest(env, { minVersion }).

Under the Hood: what if fetchTrustedManifest throws a fetch error?

A signed manifest rolls out per-environment alongside each cluster’s deploy, so an environment can exist in the SDK before its nodes are actually serving one — fetchTrustedManifest throws a fetch error in that case, not a signature error. If that happens for an environment you expect to work, the cluster likely hasn’t published a manifest yet; it will once it next redeploys. Until then, target an environment that already has one, or opt out explicitly and knowingly with { unsafe_trust_server: true } (local dev only — see the Warning above).