Encrypt with SEAL
When the dapp encrypts your file, what that actually protects, and what the decryption flow looks like for you and anyone you share with.
When the dapp encrypts
The dapp turns on encryption automatically when both are true:
Starter, Pro, and Enterprise all include SEAL encryption. Free tier blobs are stored in the clear.
Created automatically on your first upload. SEAL keys are scoped to the BlobStore — without one, there's nowhere to bind the encryption.
You can confirm encryption is on by looking at the wizard's right sidebar —
under Storage settings it'll say Encryption: SEAL · threshold.
What SEAL is
SEAL is Sui's threshold encryption system. The encryption key for your file is split across two independent key servers running on different infrastructure. To decrypt, your wallet has to sign a request, and both servers have to return their share of the key — neither one alone can reconstruct it.
This means:
| Attack | What it gets the attacker |
|---|---|
| Compromise one key server | Nothing — they only hold half the key |
| Compromise the Walrus storage | Ciphertext bytes. Useless without the key |
Read your BlobStore on-chain | Filename, size, owner — not contents |
| Steal your wallet's private key | Full decrypt access (same as if you'd lost your house keys) |
The threshold model is what makes "encrypted at rest on a public blob store" actually meaningful.
What's encrypted, what's not
The file's bytes. Walrus storage nodes hold only ciphertext. The aggregator serves only ciphertext.
Your wallet address (owner), the filename you chose, the file's size, the upload timestamp (Sui epoch), the content type.
If "ssn-2026.pdf" appears as the filename, anyone reading your BlobStore on-chain sees that text — even though they can't decrypt the file. Use innocuous names for sensitive content if metadata privacy matters.
What decryption looks like
When you (or someone you've shared with) clicks an encrypted blob to view or download it:
First read of the session only. The signature unlocks a 1-hour SEAL session key.
Via the aggregator's HTTP GET, just like a public blob.
Each server checks the on-chain BlobStore: are you the owner OR on the viewer allowlist for this blob? If yes, it returns its share.
Locally. Plaintext only ever exists in your browser's memory, never on a server.
If either server refuses (you're not authorized) or fewer than 2 are
reachable (network issue), you get a SealDecryptError and the file stays
ciphertext.
What about sharing?
Encryption and sharing are tightly coupled — only an encrypted blob needs to be shared (public blobs are already readable by anyone with the blob id).
See Share access for the full flow: how to add viewer wallets at upload time, change the list later, and revoke when needed.
Re-encrypting an existing blob
You can't. SEAL encrypts at upload time and the ciphertext is what's stored on Walrus. To "rotate" the encryption, re-upload the file and (if you want) delete the old blob.
Cost of encryption
Negligible compared to storage:
| Operation | Cost |
|---|---|
| Encrypting at upload | Free (browser CPU + 1 round-trip to key servers) |
| Decrypting at read | Free (wallet signature + 2 round-trips to key servers) |
| Storage premium | None — ciphertext is the same size as plaintext (give or take a 16-byte tag) |
The reason encryption is locked behind paid plans isn't cost; it's pricing discipline. The free tier is meant for "let me try Walrus" use cases, not durable private storage.