Trusted execution environments

A trusted execution environment (TEE) runs a workload in hardware-isolated memory that the host operator cannot read, and produces signed evidence, called an attestation, of exactly what software is running. Tenzro Network 1 uses TEEs for confidential inference, confidential training and verifiable execution, and treats their attestations as evidence that anyone can check.

Evidence, not custody

On Network 1, a TEE proves what is running. It does not hold anyone's keys.

• Account, validator and operator keys are rooted in a TPM 2.0, a Secure Enclave or a passkey. See Hardware-rooted keys.
• A TEE attestation is evidence attached to a result: this output came from this code, on this platform, at this security level.
• Consensus weight and leader selection do not depend on TEEs. A validator needs a TPM 2.0 machine, not a TEE.

Keeping the two apart means a weakness found in one TEE platform affects the evidence from that platform, which relying parties can stop accepting, and never exposes funds or identities.

Supported platforms

NVIDIA confidential GPUs extend a CPU TEE; they do not replace one. The trust boundary is the confidential VM created by Intel TDX or AMD SEV-SNP, and the GPU is admitted into it over an authenticated link with its memory protected. A node offers confidential GPU compute only when it has both a CPU TEE and a GPU in confidential-computing mode. Evidence collection fails closed if confidential computing is disabled, the GPU is in a developer or debug mode, or there is no confidential VM to anchor to.

Measured boot is not a TEE. A TPM and Secure Boot prove what was loaded at boot, which is valuable for machine identity. A TEE proves what is running and protects it while it runs. A TPM-only host can validate, hold hardware-rooted keys and attest its boot chain, but it does not satisfy a confidential-compute requirement and cannot take the TEE provider role.

How an attestation is verified

Every attestation is verified in full against its vendor's chain before any part of the network acts on it:

1. Fresh nonce. The verifier issues a random challenge, and the platform must include it in the signed report data. A report that does not carry the verifier's nonce is rejected, so old evidence cannot be replayed.
2. Signature over the report. The report signature is checked with the platform's attestation key.
3. Full certificate chain. That key is checked link by link up to the vendor's pinned root certificate, including validity periods and revocation.
4. Platform security level. The reported firmware and microcode level (TCB) must meet the required minimum, and debug modes must be off.
5. Measurement. The measured software must match a measurement the relying party accepts.

Simulated or self-reported evidence is never accepted. A report either verifies against real vendor hardware or it fails.

Binding a result to the enclave

Verifying that some enclave exists is not enough; you need to know that this output came from it. When a request asks for attestation, the enclave's report data commits to the request id, the operation and the output:

user_data = SHA-256("tenzro/tee/enclave-response" || len-prefixed(request_id, operation, data))

The hardware signs user_data, so a relying party that verifies the report and recomputes the binding learns that this exact output came from an enclave with that exact measurement. Length prefixing stops a response from being lifted from one request and presented as the answer to another. If attestation was requested and the hardware cannot produce it, the call fails rather than returning a result without evidence.

What TEEs are used for

• Confidential inference. Prompts and outputs stay inside protected memory, and the response carries evidence of the model and runtime. Inference verification on Network 1 is TEE-first.
• Confidential training. Training rounds can run inside TEEs so data owners can contribute without exposing raw data.
• Validation and re-execution. TEE providers can re-run a piece of work and attest the result, for example to answer an ERC-8004 validation request.
• Evidence in contracts. EVM contracts can check attested results through the TEE_VERIFY precompile.

Using the CLI

# What TEE hardware does this machine have?
tenzro tee detect

# Produce an attestation (auto-detects the platform, or choose tdx, sev-snp, nitro, gpu)
tenzro tee attest --provider auto

# Verify a quote
tenzro tee verify --provider tdx --quote <hex>

# List TEE providers on the network
tenzro tee providers

The matching JSON-RPC methods tenzro_detectTee, tenzro_getTeeAttestation, tenzro_verifyTeeAttestation and tenzro_listTeeProviders are open methods.

Becoming a TEE provider

Operators with Intel TDX, AMD SEV-SNP, AWS Nitro or confidential NVIDIA GPUs can run the tee role and bond as a security provider. See Operators and roles.

Attested clock

Long-running, multi-party work needs timestamps no single participant can bend: SLA windows, payment mandate expiries, task deadlines. The attested clock gives you a timestamp envelope from a node's TEE:

A relying party checks three things: the signature over the envelope, that the monotonic counter strictly increases for that enclave (which detects rollback), and that the wall-clock time is within its drift tolerance. Use it for deadlines inside workflows and agreements; block times already cover ordering on chain.

tenzro attested-clock now

or the open JSON-RPC method tenzro_attestedClockNow.

Related

• Security
• Hardware-rooted keys
• Zero-knowledge proofs
• Private AI