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 uses TEEs for confidential inference, confidential compute and verifiable execution, and treats their attestations as evidence that anyone can check.

Evidence, not custody

On Tenzro Network, 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.

Measurement registers

A report names the software the enclave runs in its measurement registers: on Intel TDX, MRTD and RTMR0 to RTMR3; on AMD SEV-SNP, MEASUREMENT. tenzro_getTeeAttestation returns the report with its registers, and tenzro_verifyTeeAttestation returns the registers it verified, so a relying party compares them with the published measurements of the image it expects the node to run.

A node operator logs the measurement of the build a node runs with tenzro trust publish-tee-measurement. The measurement logged is the report's own, taken from a fresh report bound to a challenge nonce, so a publisher can only log the build it is actually running.

Private weights: attestation-bound key release

A provider can keep a model's weights private while operators it does not run serve them. The weights are encrypted under one content key and stay encrypted at rest and in transit. The provider opts a model in by registering a release policy on chain with a KeyRelease transaction: the hash of the encrypted weights' manifest, the TPM measured boots it accepts, the Intel TDX or AMD SEV-SNP launch measurements it accepts, and whether a GPU must be attested too. A policy that measures nothing is refused.

For each release, the operator's environment makes a hybrid X25519 and ML-KEM-768 key in memory for that one release, and answers the provider's fresh challenge with evidence over a single binding of the model, the challenge, the job's terms, the operator's machine identity and the release key:

• TPM quote. A quote over the binding by the attestation key the operator's machine identity was admitted with, from a manufacturer-certified TPM, whose measured boot the policy accepts.
• Confidential VM. When the policy names launch measurements, a TDX quote or SEV-SNP report carrying the binding as its user data and one of those measurements.
• GPU. When the policy requires a GPU, an NVIDIA GPU's signed measurements answering the binding, its device chain ending at a GPU root governance recognises and its measurements matching the reference values governance sets.

Evidence made for one release cannot be replayed for another operator, job or key. The provider's broker checks the evidence and records the release on chain, where consensus checks it again against the policy and the governed GPU values and records each binding once. Only then does the broker seal the content key to the environment's release key, so reading it needs both key exchanges broken. The broker never stores the content key: it opens it for one release from the provider's hardware-held envelope and drops it once sealed.

Every key that leaves the provider has an on-chain release event naming the job, the evidence, the measured boot, the launch measurement and the GPU. Once the owner revokes the policy, no further release is recorded, so no broker following the chain releases the key again. Models without a policy are unaffected, and the sealed distribution of private weights to named recipients works as before.

Attested confidential jobs, settled per unit

A confidential workload can run outside Tenzro, in a cloud or on-premises confidential VM, with or without a GPU in confidential mode. Tenzro checks the hardware's statement about the workload and pays for the work that statement covers.

The workload's attestation must answer the job's challenge and verify against the vendor's roots: an Intel TDX quote with its DCAP collateral, an AMD SEV-SNP report with its VCEK chain, or an NVIDIA GPU's signed measurements against the governed GPU roots and reference values. Each completed unit becomes a receipt committing to the job, the unit, the verified measurement, the platform id, the evidence and the unit's output. The payer chains the receipts and signs a cumulative voucher for every unit it verified, and the chain settles exactly the vouchered amount. Work whose attestation does not verify gets no receipt and no voucher.

The verifiers are tested against vendor-published evidence: a production TDX quote with Intel's collateral, an SEV-SNP report from an AMD Milan processor, and an NVIDIA H100's signed measurements from NVIDIA's open-source verifier.

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 Tenzro Network is TEE-first.
• 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 from the node's TEE (the platform is detected)
tenzro tee attest --out report.json

# Verify a report against a fresh challenge
tenzro tee challenge
tenzro tee verify --report <REPORT_HEX> --nonce <NONCE>

# List TEE providers on the network
tenzro tee providers

The matching JSON-RPC methods tenzro_detectTee, tenzro_getTeeAttestation, tenzro_teeAttestationChallenge, tenzro_verifyTeeAttestation and tenzro_listTeeProviders are open methods. A report verifies only against a nonce the verifier issued, so a replayed report fails.

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.

Related

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