Test credit and test token
AngeronaBeta

Attestation

The TEE badge, the checks behind it, the enclave operators, and how to test a TEE model by hand.

A fake enclave is worthless, so you need a way to spot a real one. Attestation is that way. The hardware signs a report on the machine and its software, including a key that exists inside the enclave alone, and your browser studies the report before sealing anything with that key.

The badge means three checks passed

A TEE model earns the badge only if all three pass:

  • Server check: about once an hour, our server sends each TEE model a new random nonce and requests attestation, noting whether it passed and whether the nonce returned intact.
  • Browser check: when a session opens, your browser repeats the request with a nonce of its own and runs the tests below.
  • Signed reply: replies arrive with an enclave signature, matched against the key from that attestation.

Fail one and the badge is gone. It describes a single model at a single check, live, so yesterday's pass can be today's failure. Nothing gets the mark in advance.

Your browser runs six checks

CheckWhat it proves
Verification resultThe verifier approved the enclave's Intel TDX quote and NVIDIA GPU evidence
NonceYour browser's fresh random nonce comes back in the report, so it was made now, for you, and no replay
Signing key bindingThe opening 20 bytes of the report's data field hold the enclave's signing address. That ties the key to the report, and its private half never leaves the enclave
Nonce bindingBytes 32–63 of that field hold your nonce, tying the hardware report to your request
Model public keyYour browser encrypts to the attested key, whose address matches the signing address
Response signatureThe attested signing address signed every reply

A session never goes without at least one fresh attestation in your browser.

Two companies operate the enclaves

The hardware is Intel TDX CPUs plus NVIDIA confidential-computing GPUs. Each attestation report names its operator, and that name is final.

OperatorModels
PhalaKimi K3, GLM 5.3, GLM 5.2, Gemma 4 26B A4B Uncensored, GPT OSS 120B, Qwen 2.5 7B, Qwen3 VL 30B A3B
NEAR AIKimi K2.6, Qwen 3.8 27B, Qwen 3.6 35B A3B FP8, DeepSeek V4 Flash, GLM 5.3 Flash

A model that fails gets no badge. It stays selectable, with no hardware proof attached.

You can check it yourself in four steps

Don't take the badge on trust. The steps get harder and more complete as you go.

Step one: watch the traffic

Send a TEE message with the Network tab of your developer tools open, and locate the request holding it:

  • Message content shows up as long hex strings, old turns included, with none of your words.
  • Two public keys travel alongside: your session key and the model key used for encryption.
  • The stream coming back is hex too, apart from readable token counts.

Spot your own words in a TEE request body? That's a bug, and we want to hear about it.

Step two: read the attestation report

The Network tab also holds the JSON attestation report fetched for the model. Open it and confirm:

  • The nonce inside matches what your browser sent.
  • The signing public key yields an address equal to the report's signing address, and it's the same model key you saw in step one.
  • Report data opens with the signing address (bytes 0–19), with your nonce at bytes 32–63.
  • An operator appears by name: Phala or NEAR AI.

Here is the check with viem:

import { publicKeyToAddress } from "viem/accounts";

// signingPublicKey: the uncompressed public key from the report (starts with 04)
// signingAddress, reportData, nonce: from the report and your request
const keyMatches = publicKeyToAddress(`0x${signingPublicKey}`).toLowerCase() === signingAddress.toLowerCase();

const rd = reportData.toLowerCase().replace(/^0x/, "");
const addressBound = rd.startsWith(signingAddress.slice(2).toLowerCase()); // bytes 0–19
const nonceBound = rd.slice(64, 128) === nonce.toLowerCase(); // bytes 32–63

Step three: verify the hardware quote

So far you've relied on the verifier's word. To stop relying on it, examine the raw evidence yourself:

  • Intel TDX quote: feed it to a DCAP verifier, Phala's open-source dcap-qvl for example. Next confirm REPORTDATA (signing address in the opening 20 bytes, your nonce at bytes 32–63), debug mode switched off, and measurements (MRTD and RTMRs) equal to the figures the operator publishes for its software.
  • NVIDIA GPU evidence: submit it to NVIDIA's attestation service (NRAS).

Two passes and your proof rests on signing keys from Intel and NVIDIA, with Angerona and all middlemen out of the picture.

Step four: check a response signature

The app requests a signature per reply ID, visible in the Network tab. It follows EIP-191, so ordinary wallet libraries can test it:

import { verifyMessage } from "viem";

const ok = await verifyMessage({ address: signingAddress, message: text, signature });

Take the signing address from the attestation report. What gets signed looks like sha256(request as the enclave saw it):sha256(response as the enclave saw it). Small rewrites along the route leave you no way to rebuild those hashes. So the signature confirms the attested key produced the reply carrying this ID, without covering each byte.

Attestation covers the enclave and stops there

  • The page you loaded: whether its JavaScript encrypts properly is outside the proof, and step one tests that.
  • Metadata: which model, when, how large and how many tokens all stay visible beyond the enclave.
  • Chip flaws: the whole scheme expects Intel TDX and NVIDIA confidential computing to behave as designed.

All limits are on Privacy modes.

Privacy modesData handling