Session lifecycle
A session is the unit of work in Hermetic. It has four movements and produces exactly one receipt.
1. Seal
Before anything is sent, the client asks the chosen operator for the enclave's evidence: an Intel TDX quote and an NVIDIA GPU attestation report. Both carry a public key generated inside the enclave at boot. The client verifies:
- the TDX quote chains to Intel's root of trust;
- the GPU report is valid and confidential computing mode is on;
- the measurement (MRTD and runtime registers) is listed in the Hermetic registry;
- the operator holds an active bond.
Only then is the input encrypted to the enclave key.
2. Run
Inside the enclave, the Hermetic runtime loads the pinned model, the tools allowed by the policy, and decrypts the input. Memory is encrypted by the CPU; the GPU's memory and the link between CPU and GPU are encrypted in confidential computing mode. Network egress is limited to the hosts named in the policy.
3. Attest
When the agent finishes, the runtime builds the receipt body: measurement, model digest, policy hash, a commitment to the input, a commitment to the output, timestamps and the operator address. It asks the hardware for a fresh quote whose report data is the hash of that body. The answer is encrypted back to the client.
4. Anchor
A verifier checks the quote and posts the receipt hash to the anchor contract on Robinhood Chain. Thirty-two bytes per session, plus the operator and the registry entry it ran under. The full receipt is returned to the client, who can publish it, share it, or keep it.
Failure cases
| What fails | What happens |
|---|---|
| Quote does not verify at open | The client refuses to send. No fee is charged. |
| Measurement not in registry | Same as above. |
| Enclave dies mid-run | No receipt is anchored. The session is retried on another operator. |
| Quote does not verify at close | The receipt is rejected and the operator's bond is exposed to a slashing claim. |