Sealed execution, explained without the jargon

Enclaves, attestation, hardware boundaries — the vocabulary is intimidating. The idea underneath is simple. Here's the plain-language version.

Start with a locked room

Imagine a room with a slot in the door. You slide in a sealed envelope. Inside, someone does the work you asked for, seals the result in a new envelope addressed only to you, and pushes it back out through the slot. The room has no windows. The person who owns the building can see that someone is working and how long it takes — but never what's on the paper.

That's sealed execution. The "room" is a hardware-enforced enclave; the "envelopes" are encryption; the "building owner" is the node operator.

The four moving parts

1. Encryption on your device. Before anything is sent, your data is encrypted locally with a key tied to your wallet. Plaintext never leaves your machine. What travels over the network is ciphertext — unreadable to anyone who intercepts it, including the node.

2. The hardware boundary. Modern processors can carve out a protected region of memory that even the operating system and the machine's owner cannot read. Code runs inside; data is decrypted inside; and the boundary is enforced by the silicon, not by a setting someone can flip.

3. Attestation. Before you trust a room, you want proof it's the right room. The enclave can produce a signed statement — an attestation — that says "I am running exactly this code, on genuine hardware, unmodified." You (or a verifier) check that statement against what you expected. If it doesn't match, you don't send the envelope.

4. Destruction. When the job is done, the result is re-encrypted to your key and returned. Then the enclave's memory is wiped. Nothing readable persists.

What the operator can and can't see

This is the part worth internalizing. The operator can see that a job ran, roughly how much compute it used, and when it settled. The operator cannot see the input, the output, or anything about what the computation was actually doing. They host the cage; you hold the key.

Why not just use encryption?

Ordinary encryption protects data at rest (sitting on a disk) and in transit (moving across a network). The hard gap is data in use — the moment it has to be decrypted to be computed on. Traditionally, that's exactly when a cloud server sees your plaintext. Sealed execution closes that gap by making "in use" happen inside a boundary the host can't cross.

The trade-offs

Sealed execution isn't free. It moves your trust onto the hardware vendor's root of trust and the correctness of the sealed runtime, and it adds steps — encryption, routing, attestation checks — that a plain cloud call skips. Those are real costs. The payoff is that "trust me" becomes "verify the attestation," which is a much better deal when the data is sensitive.

Strip away the vocabulary and it's just that locked room: work goes in sealed, comes out sealed, and the owner of the building never reads the paper.

Keep reading