Verify the trust anchor

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

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

const client = new T3nClient({
  trustAnchor: await fetchTrustedManifest("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: 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.

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

Overview

Get Started

Agent Onboarding

Quick Tips

Reference

Use Cases

Support