What Is a Receive Address?

A receive address is the public address someone uses to send you a sealed Label 309 record.

You can hand it to a person, a company, or an automated system. They use it to encrypt a sealed proof so that only you can open it. What they cannot do with it is read your other sealed records, sign as your identity, or recover your Identity Seed. A receive address is a public key, not a secret.

The rule fits in one line: share your receive address, protect your Identity Seed.

What is a receive address for?

A receive address tells a sender how to encrypt a sealed record so that only you can decrypt it.

In CardanoWall, a sealed record is a Proof of Existence whose content is encrypted. The Cardano blockchain still proves that the record existed at a specific block time and commits to the hash of the plaintext, while the file itself stays encrypted and lives off-chain at a content-addressed location.

If a sender wants you — and only you — to open that file later, they add one of your receive addresses as a recipient before they publish. Their software wraps the file's encryption key to your receive key. Later, your own client recognizes the record as yours, decrypts it locally, and shows it to you.

So a receive address is not a mailbox that CardanoWall hosts on your behalf. It is a public encryption address that lets anyone seal content to you without going through us.

Is a receive address secret?

No. It is meant to be shared.

You can put a receive address on a contact card, paste it into a message, print it, publish it on a profile, or give it to one specific sender. Anyone who has it can encrypt a sealed record for you — and that is the whole point.

What they cannot do is just as important. Someone holding your receive address cannot read sealed records addressed to you, cannot derive your private key from it, and cannot sign records as your identity. The address is one half of a keypair; the half that opens things never leaves your device.

The secret you guard is your Identity Seed, not your receive address. (For why the seed sits at the root of everything, see your identity is a seed.)

What does a receive address look like?

Label 309 reuses the receive-address formats from the age encryption ecosystem, encoded as lowercase Bech32 strings.

A classical receive address starts with age1:

age1...

A hybrid post-quantum receive address starts with age1pqc:

age1pqc1...

The real strings are much longer than these stubs — the hybrid one especially, because its public key carries far more material. The prefix is what tells software which kind of recipient key it is looking at.

The visual distinction that matters most is case:

Public receive addresses are lowercase, like age1... or age1pqc1....
Your private Identity Seed uses the uppercase L309-SEED-1... display form.

This is a deliberate convention borrowed from age, where secrets are shown in uppercase and public addresses in lowercase. If you remember nothing else from this page, remember it: a lowercase age1... string is shareable; an uppercase L309-SEED-1... string is the secret that controls your whole identity. Never paste the second one where the first one belongs.

Why are there classical and post-quantum addresses?

Because some sealed records need to stay private for a very long time, and "long" is exactly where future computers become a worry.

The age1... address is the classical X25519 receive path. It is compact, widely compatible with age tooling, and well suited to everyday use.

The age1pqc1... address is a hybrid post-quantum receive path. It combines X25519 with a lattice-based scheme (ML-KEM-768, the pairing known as X-Wing). It is longer because the public key is larger, and its purpose is to give sealed payloads a stronger option against a future adversary who records ciphertext today and hopes to break it with a quantum computer later.

This does not mean anyone should claim permanent security — cryptography keeps moving, and no honest service promises otherwise. The accurate claim is algorithm agility plus a hybrid post-quantum option for sealed payloads: Label 309 references its algorithms by name from extensible registries, so new ones can be added without breaking old records. For ordinary content, the classical path is fine. For sensitive or long-lived data, prefer the stronger receive mode when the product offers it.

How does someone send me a sealed record?

The flow is short, and you only ever supply the public half.

You give the sender one of your receive addresses.
They compose a sealed CardanoWall record and add your address as a recipient.
Their software encrypts the file and wraps the encryption key to your receive key.
The ciphertext is stored at a content-addressed location off-chain.
A Label 309 record is published on Cardano, carrying the plaintext hash and the wrapped key — never the file, and never your address.
Later, your client discovers the record by testing your keys against it locally.
If your key opens it, you can decrypt the file.

At no point does the sender need your Identity Seed, the gateway need your private key, or the blockchain need to show a readable "to" field. (For the receiving side end to end, see how to receive sealed records.)

How do I find records that were sent to me?

Your client finds them by trying your keys locally — a technique called trial decryption.

This is one of the strongest privacy properties of sealed Label 309 records. There is no server-side database mapping recipients to records, and there is no on-chain field that names you. Nobody has to deliver a record "to your account" for you to receive it.

Instead, your client reads sealed records from the public record feed and, for each one, quietly tries your receive keys against the wrapped key slots. If a record contains a slot your key can open, it appears in your inbox. If it does not, your client learns nothing and moves on.

That is why the inbox model is closer to "my software can open this record" than to "the server handed this record to me." The recognition happens on your device, with your keys, and never reveals which records are yours to an observer.

Does the sender know the address is really mine?

Only if they got it from you, or from a source they already trust.

A receive address on its own is just a public key string. It does not prove a real-world identity. If you copy an address off a website, a profile, a printed card, or a message, you still have to decide whether that address truly belongs to the person or organization you think it does.

For anything sensitive, verify a receive address out of band before you rely on it. That might mean reading the key's fingerprint aloud over a call, confirming it in person, checking a page the organization demonstrably controls, or looking it up in an address book you maintain. A name printed next to a key is only an assertion by whoever printed it — it is not a cryptographic guarantee, and two people using the same display name still produce different key bytes.

Do not send a highly sensitive sealed file to an address just because someone posted it in a channel you cannot vouch for. The matching guide verify a recipient before you seal a file walks through this step.

Can I have more than one receive address?

Yes — in two ways.

Each Label 309 identity exposes receive addresses derived from its receive keys: a classical age1... and, optionally, a hybrid age1pqc1.... And a person or company can hold several identities, each with its own seed and its own addresses.

That lets you separate contexts cleanly — for example:

personal records and work records;
legal evidence intake;
a journalist's confidential tip line;
CI/CD automation;
a partner-specific channel.

Separation keeps workflows from bleeding into each other and makes operational security easier to reason about. If one identity is retired, the others are untouched.

What happens if I change identities?

An Identity Seed is an identity. Create a new identity and you get a new seed and new receive addresses; there is no in-place "rotation" of the seed behind a single identity.

This matters for old mail. A sealed record addressed to your previous identity can still only be opened with that identity's seed and receive keys. A new identity does not inherit the ability to decrypt records sealed to an old one.

That is why the identity lifecycle is worth understanding. If an identity is no longer safe to sign or publish with, you can deactivate it: it stops being usable for new signing and publishing, but it stays in your vault and can still decrypt sealed content — both records you received before and records that arrive afterward. If you instead delete the identity and keep no backup of its seed, the sealed content addressed to it becomes unreadable, because the seed was the only thing that could open it. Your published proofs still verify regardless — losing the seed does not invalidate a timestamp — but you lose the ability to decrypt anything that was sealed to that identity.

The receive address is public; the seed is what lets you keep receiving and decrypting.

Can a receive address sign records?

No. A receive address is for encryption only.

In the Label 309 key model, one 32-byte seed deterministically derives several keys for different jobs: an Ed25519 key that signs records, and X25519 (and optionally X-Wing) keys that receive sealed content. The signing key vouches for records; the receive keys open sealed ones. They come from the same seed but never trade roles.

That separation is one of the reasons the seed model is convenient: a single backup restores the whole identity, while each derived key keeps a clear, fixed purpose. Signatures, by the way, are always optional in Label 309 — a sealed record can carry an author signature or carry none at all.

What can an observer learn from the blockchain?

Anyone can read public Label 309 records on Cardano. For a sealed record, an observer can see that it is sealed, the block time it was published, the public plaintext hash, the encryption-envelope fields, and the number of recipient key slots.

What they should not be able to see is just as definite: not your plaintext, not a readable field naming you as the recipient, and not your private key — which a receive address can never expose.

But sealed records are not a complete anonymity system, and it is honest to say so. The slot count itself reveals "how many recipients", never "who". And factors outside the record — publish timing, payment flows, network metadata, gateway activity, browser behavior, and ordinary operational mistakes — can still leak information that the cryptography never touches. Receive addresses keep recipient discovery local and encrypted; they do not erase every external trace.

Share the receive address that matches the kind of sealed record you want to receive.

For everyday or maximum-compatibility use, that is usually the classical age1... address. For sensitive, long-lived data, prefer the hybrid age1pqc1... address where it is offered, and let the product handle the wrapping details.

And the one absolute: never share your L309-SEED-1... Identity Seed as a receive address. It is not a receive address. It is the secret that controls the identity — signing, decryption, everything. The lowercase age1... string is what you publish; the uppercase seed is what you guard.

The short version

A receive address is public. Your Identity Seed is private.

Give people your receive address when you want them to send you sealed records. Verify that address out of band when the data is sensitive. Keep your seed backed up and protected, because the seed is the single artifact that lets any compatible software — the website, the command-line tool, or the desktop app — restore your signing and decryption keys.