How to Receive a Sealed Record

To receive a sealed record, you share a receive address and let your software find the records your keys can open. There is no mailbox the server fills for you. Your client scans the public Label 309 feed, tries your receive keys against each sealed record, and shows the ones that successfully decrypt.

That inversion is the whole idea: your inbox is discovered by decryption, not assigned by a server. The chain never carries a readable recipient field, and the gateway never needs to know which records are yours.

What is a sealed record?

A sealed record is a Proof of Existence with the content encrypted.

The public record still commits to the plaintext hash, so the proof can later show that exact content existed by a public block time. The file itself is encrypted, and the ciphertext lives at a content-addressed location such as Arweave or IPFS — never on chain. (For the public-proof mechanics, see how Label 309 works.)

Anyone holding a matching key can decrypt the ciphertext, recover the original bytes, recompute the plaintext hash, and confirm the decrypted file matches the on-chain commitment. Anyone without a key sees that a sealed record exists — but should not be able to read the content.

What do I give the sender?

You give the sender a receive address. Nothing more.

For Label 309 sealed records, receive addresses come in two forms:

age1… — the classical X25519 receive path.
age1pqc1… — a hybrid post-quantum receive path (X25519 combined with ML-KEM-768, in the X-Wing construction).

A receive address is public and safe to share. It lets someone encrypt a record to you and nothing else. It is derived from your identity, but it does not reveal it.

Do not give the sender your Identity Seed. The seed is the private root of your identity — the 32 bytes from which your signing key and your receive keys deterministically derive. Anyone who holds it can sign and decrypt as you. (More on why the seed is the real backup: your identity is a seed.)

How does the sender create the record?

The sender's software does the sealing locally. At a high level:

The sender picks a file or message.
The software computes the plaintext hash.
The software generates a one-time content key and encrypts the content.
For each recipient, it wraps that content key to the recipient's receive key, producing a per-recipient slot.
The ciphertext is uploaded to content-addressed storage (such as ar://).
A Label 309 record is published on Cardano, carrying the plaintext hash and the sealed envelope.

The on-chain record proves the timing and carries the wrapped key slots. The stored ciphertext holds the encrypted file. Your private key is what opens your slot. The same sequence — hash, sign, seal, share — is walked through in hash, sign, seal, share.

How does my client find a record meant for me?

Your client scans public records and tries to open them.

This is the part that feels unfamiliar if you expect a normal mailbox. In a hosted inbox, the server knows which account a message belongs to and routes it. A sealed Label 309 record carries no such routing. The envelope lists wrapped key slots, but no recipient public key appears anywhere on the wire — there is no addressee field to read.

So your client syncs the public feed of Label 309 records and, for each sealed one, tests whether any slot opens with your identity's receive keys. This is local trial-decryption: an attempt to unwrap each slot, performed entirely on your device. If a slot opens, the record is yours and your client adds it to your inbox. If none opens, your client ignores it.

A subtle but important consequence: the order of slots leaks nothing either. A sender shuffles the slots before publishing, so even the position of "the primary recipient" carries no signal.

Does trial-decryption have to download every file?

No. Trial-decryption runs against the envelope carried in the on-chain record, not the stored file.

The wrapped slots and a small authentication tag live in the record metadata itself. Your client can determine that a record is addressed to you — and recover the content key — from those on-chain bytes alone, before fetching any ciphertext. That matters because ciphertext can be large: a desktop client can first discover which records are yours, then fetch encrypted files lazily when you open them, or pre-cache them according to your settings.

For an offline-first client, this split is the foundation:

sync the public record feed;
trial-decrypt locally against the envelopes;
cache the matching ciphertext if you want it;
decrypt on demand when you open a file;
keep everything already synced usable without a network.

What does the gateway actually know?

A gateway knows what any public observer knows, plus the operational details of the service it runs.

For a hosted gateway, that can include account activity, API usage, your quote-and-publish flow, upload activity, balance state, network-level infrastructure data, and the public record metadata everyone can see. (For the full picture of the boundary, see what CardanoWall can see.)

What it does not need is your Identity Seed, your receive private keys, or any ability to decrypt sealed content for you. The privacy property here is not "the server learns nothing about anything" — that would be dishonest. It is narrower and more useful: recipient matching and decryption happen locally, so no readable recipient field is published and no private key is ever sent to the gateway. The gateway is recipient-blind by design; any attempt to filter records by recipient is simply ignored, because there is no recipient column to filter on.

Why is there no public recipient field?

Because a public recipient field would leak the social graph.

If every sealed record named exactly who it was for, an observer could map relationships between senders and recipients without reading a single byte of plaintext. For confidential workflows — a source contacting a newsroom, a sealed bid, evidence in escrow — that exposure can be the whole risk.

Label 309 uses wrapped key slots instead. The record carries encrypted material that only the intended key holders can open. An observer can see that a record is sealed and how many slots it has, but not a readable list of recipients.

This is not perfect anonymity, and it should not be sold as such. Slot count, publish timing, and external metadata can still reveal something, and a sender who needs to defeat timing correlation has to publish off the sensitive timeline. What the design eliminates is the most obvious leak: a public recipient column on a permanent ledger.

What if I have several identities?

Your client tries each unlocked identity.

You might keep one identity for personal records, one for a company, one for legal intake, and one for a high-risk confidential channel. Each has its own seed and its own receive keys, so a record sealed to one is invisible to the others until that identity's keys are tried.

An offline-first client tracks how far each identity has scanned through the record feed independently. That independence is what lets you import an old seed later and have the client re-scan the whole feed for that identity — rather than starting at today and silently missing everything sent before the import.

What happens when I restore an old Identity Seed?

Compatible software re-derives the same receive keys from the seed, deterministically.

That means an old seed can find old sealed records, as long as the records are still on chain to scan and the ciphertext is still retrievable or cached. The client re-scans the public feed, trial-decrypts the sealed envelopes, and rebuilds the inbox view for that identity. Restoring the seed restores the ability to recognise records meant for it — the gateway holds no private mailbox to hand back.

This is one of the clearest reasons the seed matters so much, and why the identity seed still deserves your attention. If you lose the seed for a recipient identity, sealed records addressed to it may become unreadable — even though the public proofs remain on chain and continue to verify. Encryption has no recovery backdoor by design; the seed is the recovery path.

Can a desktop client receive records offline?

It can work with whatever it has already synced.

CardanoWall Desktop — an open-source Rust application built with Tauri on the open-source Rust SDK (github.com/cardanowall) — is built exactly around this. Once it has synced records and cached ciphertext, it lists, searches, verifies, and decrypts that local data with no network connection. If a record has not been synced yet, or a ciphertext has not been fetched, it needs the network to retrieve those — and says so plainly rather than failing silently.

This mirrors how a serious email client behaves: offline does not mean the world stops. Your local mirror, cache, and vault become the source of truth until the network returns. (More on the offline model: offline proofs and CardanoWall Desktop.)

How should I verify who sent a record?

Receiving a sealed record proves only that your key can open it. It does not prove who sent it.

Authorship in Label 309 is optional. If a record carries a signature, that signature shows a particular key vouched for the record — but you still need context to decide whose key that is. If a record is unsigned, the sender may have deliberately avoided binding any identity, which is exactly what some confidential workflows require.

For sensitive material, confirm sender keys and receive addresses out of band: keep an address book, compare key fingerprints, and use a directory or direct confirmation you already trust. Encryption protects the content; deciding whose key you are talking to is a separate, human trust decision. The address book mechanics are covered in how the address book works.

What can go wrong?

The most consequential failure is losing the seed. Lose the Identity Seed for a recipient identity and you may lose the ability to decrypt records addressed to it — permanently, for that identity.

The rest are operational, and good software should surface them honestly rather than hide them:

the ciphertext was never uploaded successfully;
the storage location is temporarily unavailable;
the sender used the wrong receive address;
you imported the wrong identity;
the local device is compromised (a malicious program on an unlocked machine can read in-memory secrets — see public-computer mode);
the record is too new and has not reached the confirmation depth you require;
the record is valid but unsigned, so no sender identity is established.

A proof system earns trust by showing uncertainty, not by papering over it.

The short version

To receive sealed records:

Share a receive address.
Keep your Identity Seed safe and backed up.
Let your client scan the public Label 309 feed.
Let it trial-decrypt locally.
Open and verify the records your keys can decrypt.

Your inbox is not a server-side list of messages addressed to your account. It is a local view of sealed records your identity can open — and that is precisely what keeps the gateway out of your private correspondence.

One last honest note on limits: a sealed record keeps plaintext encrypted for its key holders, but it does not guarantee anonymity, and anyone who decrypts it can choose to leak the plaintext afterward. The proof shows that specific bytes existed by a public time. It does not prove truth, ownership, or authorship — see what a proof does not prove.