Abstract
Agents are only as useful as what they are allowed to see, and what they see is increasingly the most sensitive data a person has: wallet histories, exchange keys, financial statements, private correspondence. Today that data is sent in clear to whoever runs the model, under a promise. Hermetic replaces the promise with a measurement. Agents run inside hardware enclaves; every session produces a receipt signed by the hardware that names the code, the model and the rules it ran under; and the hash of that receipt is anchored on Robinhood Chain. The content of a session stays sealed. The identity of the run becomes public and auditable. Operators bond $HERMETIC behind every enclave and are slashed for invalid attestations or proven leaks.
1. The problem
A chatbot sees what you type into it. An agent sees what it can reach. The step from one to the other has quietly changed what "privacy" means for AI. A trading agent cannot advise on a portfolio it cannot read. A tax agent cannot file without the statements. An agent that acts on your behalf needs your credentials to act.
Every one of these agents today runs on infrastructure the user cannot inspect. The data is decrypted on a server, processed by software the user has never seen, possibly logged, possibly retained, possibly used for training. The user's only assurance is a policy document. Policies can change, can be broken, and cannot be verified from outside.
On-chain finance makes the problem sharper. The data an agent needs to be useful with tokenised assets, positions, fills, counterparties, timing, is exactly the data that is most valuable to someone else. Leaking it is not an embarrassment; it is a loss.
2. Design goals
Hermetic is designed around four goals.
- Content stays sealed. No party other than the user, not the operator, not Hermetic, not the chain, can read the input or the output of a session.
- The run is public. Anyone can verify which hardware, which code, which model and which policy a session used, without access to its content.
- Native speed. Agents need answers in seconds. The guarantee must not cost orders of magnitude in latency.
- Accountable operators. Whoever runs the hardware has something at stake if the guarantee is broken.
3. Architecture
3.1 Enclaves
A Hermetic enclave is an Intel TDX confidential virtual machine paired with an NVIDIA H100 GPU in confidential computing mode. TDX encrypts the virtual machine's memory with keys held by the CPU; the H100 extends that protection to GPU memory and to the link between CPU and GPU. The host operating system, the hypervisor and the operator cannot read either.
Each enclave runs a Hermetic build: a minimal runtime that loads one pinned model, the tools allowed by a policy, and nothing else. Builds are reproducible from public source, so their measurement can be recomputed by anyone.
3.2 Sessions
A session has four movements.
Seal. The client obtains the enclave's TDX quote and GPU attestation report. Both bind a public key generated inside the enclave. The client checks the quote against Intel's root, the GPU report against NVIDIA's attestation service, the measurement against the Hermetic registry, and the operator's bond. Only then does it encrypt the input to the enclave key.
Run. The runtime decrypts the input inside the enclave, runs the agent, and enforces the policy: retention, egress, tools, maximum duration.
Attest. The runtime assembles a receipt body: measurement, model digest, policy hash, salted commitments to input and output, operator, timestamps. It obtains a fresh quote whose report data is the hash of that body.
Anchor. A verifier checks the final quote and writes the receipt hash to the anchor contract on Robinhood Chain. The answer and the full receipt return to the client.
3.3 Receipts
A receipt is designed to be useful to someone who will never see the data. It proves that a specific session happened, inside a specific measured environment, under a specific policy, and that the operator could not have altered any of it. Input and output are represented only by salted commitments; the salt stays with the user, who can later prove the content of a session to a party of their choosing.
3.4 The registry
The registry is an on-chain list of what the network accepts: enclave build measurements, model digests, and policy hashes. A session whose measurement is not listed is rejected by the client before any data is sent, and a receipt that names an unlisted entry is grounds for slashing. The registry is governed by $HERMETIC holders.
4. Trust model
Hermetic is honest about its foundations. Trusted execution is a hardware assumption, not a proof.
Users trust the hardware vendors' roots of trust, the isolation of the silicon, and the code of the measured build, which is public and reproducible. Users do not trust the operator, Hermetic, or the chain.
Hermetic does not protect against data leaving through egress the policy allows, against wrong answers from the model, or against physical attacks on the chip by a determined operator with laboratory equipment. Bonds raise the cost of the last one; they do not remove it. Enclaves have known side-channel attacks in their history; the registry only accepts builds on patched platforms and can delist a platform when a new attack is published.
Zero-knowledge proofs of large-model inference would remove the hardware assumption, but are not practical at the latency agents require today. The receipt format is versioned so that a proof can be attached to it when that changes.
5. Economics
5.1 The token
$HERMETIC launches on Pons on Robinhood Chain. It has three functions.
- Bond. Operators must bond $HERMETIC to be routed sessions. The bond is slashable.
- Payment. Sessions are priced in USDG or $HERMETIC, with a discount for paying in $HERMETIC.
- Governance. Holders vote on the registry: builds, model digests, policies, and the minimum bond.
5.2 Fees
The proposed split of each session fee is 70% to the operator, 20% to the cover pool and 10% to buyback and burn of $HERMETIC. These parameters are set by governance.
5.3 Slashing
A bond is slashed for an invalid attestation, a receipt naming an unlisted build, or a proven leak, meaning content that matches a session commitment, published or sold, with the salt revealed by its owner. A share of the slashed amount rewards whoever submits the evidence; the remainder funds the cover pool, which compensates users after a proven leak.
6. Applications
Wallet-aware trading agents that read full position and fill histories without exposing them to the infrastructure provider.
Credential-holding agents that keep exchange and API keys inside the enclave, decrypted only where they are used.
Document agents for tax, accounting and compliance that read statements and return filings, with a receipt that proves the retention policy.
Agent-to-agent negotiation, where two agents representing two parties meet in one attested room whose rules both sides can verify before a message is exchanged.
7. Roadmap
- Registry and receipt anchor contracts on Robinhood Chain.
- A first enclave operated by the team, anchoring a receipt for every session.
- The TypeScript SDK, with attestation verification on the client.
- Bonded third-party operators, routing and live slashing.
- Holder governance of the registry.
- Agent-to-agent sessions.
The status of each step is maintained in the documentation, with the addresses and measurements it introduces.
8. Conclusion
The more an agent can do, the more it has to see. Hermetic does not ask users to see less or agents to do less. It changes where the seeing happens: inside a room the operator cannot enter, whose door is measured, whose rules are public, and whose every use leaves a receipt on chain. Your data goes in. Nothing comes out.