Client-side encryption
How build inputs are sealed to your wallet key before they ever reach the network.
Confidentiality begins on your machine. Before any input is submitted, it is encrypted client-side under a key bound to your wallet — so the network, the API, and the operator only ever handle ciphertext.
The flow
- Derive a key. A build key is derived from your wallet, scoped to this build.
- Encrypt the input. The payload (code, prompt, schema) is encrypted locally. Plaintext never leaves your device.
- Submit ciphertext. Only the ciphertext is routed to a sealed, attested node.
- Decrypt inside the seal. The environment decrypts the input internally, runs the build, and re-encrypts the output to your wallet key.
- Decrypt the result. Only your wallet can decrypt the returned output.
Why attestation comes first
The client checks a node's attestation before routing ciphertext to it. An environment that can't prove it's sealed never receives your build.
What the operator sees
| Stage | Visible to operator |
|---|---|
| In transit | Ciphertext + timing |
| Inside the seal | Nothing — the boundary is opaque to the host |
| After the build | Nothing — all state is destroyed |
Next
- See the guarantees in Sealed execution.
- Follow the full path in Lifecycle of a build.