Public Profiles and Receive Addresses on CardanoWall

A public profile is an optional, shareable page for a single CardanoWall identity. It can show a display name, the identity's public keys, its receive addresses, and a short bio you choose to publish — so people can seal encrypted records to you without asking for a key every time.

It is a discovery convenience, not a trust anchor. Anyone can put any name next to any key, so a sender should still confirm the profile belongs to the person or organization they intend before sending anything sensitive. Discovery and trust are two different steps.

What is a public profile?

It is a per-identity page you turn on by choice.

A CardanoWall account can hold several identities. The public profile is enabled per identity, not for the whole account — so you can run one public receive identity for inbound files while keeping other identities entirely private. When you enable it, the identity gets a short, shareable link of the form cardanowall.com/p/<short-id>. Turn the profile off and that link stops resolving; turn it on again and the identity gets a fresh link rather than reusing the old one.

A profile can show the public facts you opt to publish:

a public display name;
the identity's Ed25519 signing public key (used to verify its signatures);
its classical age1... receive address;
its hybrid age1pqc1... receive address;
a short bio or set of instructions.

It deliberately does not expose your account email, billing data, the private labels you give identities, the other identities in your account, or anything inside your encrypted vault. Those are not part of the page and are never published.

Why publish a receive address at all?

So people can seal records to you without a back-and-forth.

To receive an encrypted (sealed) proof record, a sender needs your receive address — the public key they wrap the content key to. They can get it from a direct message, a DNS record, a .well-known page on your domain, or a public profile. (For a fuller explanation of what that address is and how sealing uses it, see what is a receive address.)

A public profile shines when many people need to send to the same identity:

newsroom tips;
security disclosures;
legal intake;
creator submissions;
partner evidence delivery;
a company compliance mailbox.

The profile makes the address easy to find. The encryption keeps the content private from everyone except the key holders — the address being public does not make the files public.

What should you put on a public profile?

Only public information you are comfortable sharing forever.

Good profile content:

the identity's public display name;
a short note on what this identity receives;
the receive addresses;
how to verify the page is really yours (your domain, a DNS record);
a clear statement of what not to send here.

Keep off the page:

the private labels you use for identities internally;
a personal email you did not mean to publish;
confidential workflow details;
anything secret. Your Identity Seed and private keys never go anywhere — not on a profile, not in a bio, not anywhere off your device.

Treat the page as permanently public, because for practical purposes it is.

How should a sender verify a profile before trusting it?

Reach the profile through a path the sender already trusts.

A CardanoWall profile is more meaningful when a sender arrives at it from your official website, a DNS record on your domain, a .well-known page, a verified social account, or a code you hand over in person. An unfamiliar profile link that shows up in an unsolicited message is unverified by default — the link proves nothing about who is behind it.

For sensitive files, a careful sender cross-checks several signals rather than one:

the profile URL and display name;
the Ed25519 signing-key fingerprint;
the receive address itself;
an independent channel — your official domain or .well-known page;
any entry they had already saved for you in their address book.

The point worth repeating: a profile is easy to share, which is exactly why it is easy to forge. It is a starting point for verification, not a substitute for it. We walk through this check in detail in verify a recipient before you seal a file.

Should a profile list both receive addresses?

Usually, yes — publish both and let the sender choose.

The classical age1... address is shorter and broadly compatible. The hybrid age1pqc1... address is much longer and is designed for long-lived sensitive material, where it adds a post-quantum layer alongside the classical key. Both derive from the same identity, so listing both costs nothing and gives senders the right option for the job.

If a sender's tooling only supports one of the two today, publish that one and say which it is, so nobody guesses.

How does a profile work with the address book?

A profile feeds the address book; the address book preserves the trust.

A typical loop:

you publish a profile for your receive identity;
a sender opens it and verifies it through an independent channel;
the sender saves you as a contact, capturing your keys and how they verified you;
the sender picks you by name in the composer from then on;
future sends skip the copy-paste and the re-verification.

The profile is for discovery; the saved contact is what carries trust forward. For how those saved contacts are stored and what each entry holds, see how the address book works and create your address book.

What happens when a profile changes?

Treat a changed key as a new claim, not an automatic update.

A profile can change because a receive address rotates, an identity is retired, or a team hands off ownership. A sender should not trust a new key just because it turned up at a familiar link — the same link can serve a different key.

For higher-risk inbound channels, announce a key change through more than one path:

the public profile;
your official website;
a DNS TXT or .well-known record;
a signed announcement;
a direct note to known partners.

On the receiving side, senders should update a saved contact only after re-verifying — the same care they took the first time.

What are the privacy limits of publishing a profile?

Publishing a profile deliberately links public facts together.

By enabling a profile you are choosing to associate a display name and a set of receive keys with one identity. People can use that to send you records or to recognize that identity's signatures. The page does not reveal your account's private structure, but the keys on it are public by design and stay public.

A sealed record protects the contents for the key holders; it does not make the sender or recipient anonymous, and anyone who decrypts a record can choose to share the plaintext afterward. If you need to keep contexts separate — a public intake identity versus a quiet personal one — use separate identities rather than one profile that ties everything together. If your inbound channel attracts noise, CardanoWall's whitelist mode lets a given identity surface only senders you have already verified.

The short version

A public profile makes one identity's receive addresses easy to find, which is genuinely useful for teams, creators, newsrooms, security contacts, and anyone who wants encrypted records from many people. It is a per-identity page you opt into, it never exposes secrets, and it can be turned off.

But finding an address is not the same as trusting it. A sender should still reach the profile through a trusted channel and confirm the keys before sealing a sensitive file. A good profile does not replace that check — it just makes it easier to do.