> ## 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 two valid values, and the difference is a security boundary, not a style preference:

| Option                            | Meaning                                                                                                                                                        | Use for                               |
| --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- |
| `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. | 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, fetchTrustedManifest, loadWasmComponent } from "@terminal3/t3n-sdk";

const client = new T3nClient({
  trustAnchor: await fetchTrustedManifest("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: `fetchTrustedManifest(env)` 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 allow-listed RTMR3 measurement. 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>
  **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>