> ## Documentation Index
> Fetch the complete documentation index at: https://docs.terminal3.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 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 |

```typescript theme={null}
import { T3nClient, resolveTrustAnchor, loadWasmComponent } from "@terminal3/t3n-sdk";

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

<Warning>
  `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.
</Warning>

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`.

<Note>
  **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.
</Note>

<Note>
  **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.
</Note>

<Note>
  **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 })`.
</Note>

<Accordion title="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).
</Accordion>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.