How the CardanoWall Address Book Works

The CardanoWall address book is a private list of verified contacts that lets you seal a record to someone by name instead of pasting their receive address by hand. Each entry holds the public keys you need to recognize and encrypt to a person or team — their signing key and, optionally, their receive addresses — plus a note about how you checked that the keys really belong to them.

It is a convenience-and-safety layer in the CardanoWall app. It does not change the Label 309 standard or appear in any record. When you seal a file, the address book is just where your app looks up the right key before publishing.

What problem does the address book solve?

It removes the most dangerous step in sealing a record: pasting a public key by hand.

A sealed record is encrypted to one or more receive addresses, which are public keys written as long age1... or age1pqc... strings. They are not meant to be read or retyped by a human. One wrong character and you can encrypt to the wrong key — so either the intended recipient cannot open the file, or, worse, the wrong party can.

The address book turns "paste this 60-character string" into "send to Alice Legal." You do the careful verification once, save it, and reuse it. That is convenience, but mostly it is fewer chances to make a key-handling mistake on a file that matters.

What does a trusted contact store?

Each contact is a small set of public facts, scoped to your account:

a display name you choose;
the contact's Ed25519 signing public key (required — this is the contact's identifier);
an optional classical receive address (age1..., an X25519 key);
an optional hybrid post-quantum receive address (age1pqc...);
how you verified the contact, recorded as one of a few methods: in person, QR handoff, a DNS TXT record, a .well-known page, or a manual check;
the time you verified it;
free-form notes.

There are no private keys here, and nothing secret. A contact is your own record of someone else's public keys and how much you trust them.

The two receive addresses are independent and both optional. A contact can carry one, both, or neither. An entry with only a signing key is still useful for recognizing that person's signatures, but you cannot seal a file to it until a receive address is added — the composer simply won't offer it as a recipient in that mode.

Why store the Ed25519 signing key?

Because the key is the identity — the name is just a label.

In Label 309, authorship is expressed by optional record signatures, and the Ed25519 public key is what verifies them. If a signed record claims to come from someone you know, the key bytes are the thing your software actually checks. Two people can pick the same display name; the public key is the stable identifier you can compare exactly.

So the contact stores the cryptographic identifier and pins your human-readable label to it. When a signed record arrives, you can see "this matches Alice's saved key" instead of squinting at hex.

Why store receive addresses, and why two of them?

Receive addresses are the keys you encrypt to, and CardanoWall supports two flavors.

The classical age1... address uses X25519 and is shorter. The hybrid age1pqc... address pairs X25519 with a post-quantum key and is much longer, which is the price of protecting long-lived sensitive content against a future quantum attacker. (For more on the difference, see what a receive address is.)

Saving these in a contact lets the composer offer the right recipients for the encryption mode you're using. If you're sealing with the classical scheme, it shows contacts that have a classical address; if you're using the hybrid scheme, it shows the ones with a hybrid address. If a contact has no address for the active mode, the app does not pretend it can encrypt to them — it leaves them out of the list rather than guessing.

Is a saved contact proof that the keys belong to a real person?

No. The address book records what you believe and how you checked it — nothing more.

An entry does not prove that a key belongs to a particular person, company, newsroom, auditor, or regulator. It cannot; verifying that link is human work, and it stays your responsibility. The address book's job is to preserve the verification you did so you don't have to repeat it — not to perform it for you.

Reasonable ways to verify a contact before you save it:

exchange the key in person, or scan a QR code face to face;
confirm it from a DNS TXT record or a .well-known page on a domain you trust;
check it against a signed public profile;
call a known number, or use an existing secure channel, to read back the key;
follow a company's established key-exchange process.

For sensitive files, confirm the key through two independent channels rather than one. Verifying a recipient before you seal a file goes deeper on this.

Is the address book public, or stored on-chain?

Neither. It is account-local service data that never leaves CardanoWall.

Your contacts are not written into Label 309 records and never touch the blockchain or Arweave. A sealed record contains encryption slots — keys wrapped to recipients — not a readable address-book entry; an observer cannot reconstruct your contact list from what gets published.

That said, an address book is still sensitive in its own right. Names, notes, and verification methods can reveal relationships and workflows. CardanoWall scopes every contact to your account so it cannot leak across accounts, and the server keeps these details out of its logs: contact operations are recorded with only a request identifier and your account identifier, never the keys, names, or notes themselves.

How does the address book help the composer?

It turns saved public keys into a pick-by-name recipient list.

When you create a sealed record, the composer loads the contacts that have a receive address for the mode you're using and lets you choose recipients by name. The app inserts the correct address; you never retype it. That makes recurring deliveries far less error-prone:

repeated legal disclosures and e-discovery handoffs;
auditor and compliance deliveries;
newsroom or whistleblower intake;
partner and team-to-team evidence sharing;
a customer's security contact;
your own backup recipients.

The fewer times you paste a long key by hand, the fewer chances there are to paste the wrong one.

What should you put in a contact's notes?

Only what helps you trust the entry later — and nothing secret.

Good notes capture how and when you verified, so a teammate (or future you) can judge whether to rely on it:

"Verified in person at the Lisbon office, 2026-06-02";
"DNS TXT checked on example.com";
"QR code shown by Alice during a video call";
"From the company's signed security page";
"Rotated from old key ending ab90";
"Use the post-quantum address for legal files."

Never put secrets in notes. The address book is not an identity vault — notes are ordinary service data, so treat them like an address-book card, not a password store.

What happens when a contact rotates keys?

Treat a new key as a brand-new fact to verify, never an automatic update.

Keys change: a company rotates its receive addresses, a team moves from a classical to a hybrid address, or a compromised identity gets replaced. How you update the contact depends on which key changed.

A new receive address can be edited into the existing contact in place — the signing key still identifies the same person.
A new signing key is effectively a new identity, so it becomes a new contact entry; you can keep or remove the old one as you wish.

Either way, the steps are the same:

verify the new key through a trusted channel before you save it;
record how you verified it in the notes;
stop sending sensitive files to the old address;
keep a short note about the rotation so the history is clear.

The trap to avoid: trusting a new key just because it arrived in the same channel that may already be compromised. A rotation announcement is only as trustworthy as the channel it came through.

The short version

The address book is a safety layer for humans. Label 309 works in public keys; people work in names and relationships. CardanoWall's address book connects the two — save a verified contact once, then pick recipients by name and cut the mistakes out of sending sealed records.

It does not prove anyone's identity on its own, and a proof still only shows that specific bytes existed by a given time, not who owns or authored them. What the address book does is preserve the verification work you already did, so you can reuse it safely.