Create Your CardanoWall Address Book

To create your CardanoWall address book, add a trusted contact and save their public keys, a display name, how you verified them, and any notes — one entry per contact, all stored under your own account. Once a contact is saved, sealing a file to them becomes picking a name from a list instead of pasting a long key string in a hurry.

The best time to verify a key is before the urgent moment, not during it. So build the address book in advance, while you can take your time and use a channel you actually trust.

This is the practical setup guide. For how the feature works under the hood — what is stored, where, and why it stays on your account — see How the address book works.

What should you add first?

Start with the people or teams you send to repeatedly.

For example:

your lawyer;
your auditor;
a newsroom contact;
an internal security team;
a compliance officer;
a board committee;
a partner organization;
your own backup identity;
a customer security contact;
a trusted colleague.

Don't try to fill the address book with everyone. Start with the contacts whose keys matter most — the ones you'd hate to get wrong.

What information does a contact need?

At minimum: a display name and the contact's signing public key.

To seal records to a contact, you also save a receive address. A receive address is the public key a sender encrypts to; the matching private key never leaves the recipient's device. Contacts can carry two of them:

a classical X25519 receive address (an age1... string);
an optional hybrid post-quantum receive address (an age1pqc... string), for long-lived material where post-quantum protection matters.

To recognize records signed by a contact, save their Ed25519 signing public key. CardanoWall stores this key for every contact and uses it to match a contact to the records they sign.

For operational clarity, also record how you verified the contact. CardanoWall's trusted-contact model tracks a verification method — manual, DNS TXT record, .well-known page, in person, or QR handoff — alongside the date you verified.

New to receive addresses? What is a receive address covers the concept in one page.

How should you verify a contact?

Use a channel you already trust, independent of the one that handed you the key.

Good options include:

scanning a QR code shown in person;
checking a .well-known page on the recipient's official domain;
checking a DNS TXT record on a domain you already trust;
comparing the key during a video call;
receiving the key through an existing encrypted channel;
confirming a public profile through an official website.

For sensitive files, don't rely on a single message that says "use this new address." If the channel is compromised, the key it carries may be compromised too. Verifying the recipient before you seal anything is the whole point — Verify a recipient before you seal a file walks through it.

What should the display name be?

Use a name you can recognize at a glance, months from now.

Good names are specific:

"Alice Chen — Legal";
"Acme Security Team";
"Press Team Intake";
"Board Audit Committee";
"My Offline Backup";
"Partner Compliance";
"Example Newsroom Tips".

Avoid vague labels like "main", "new key", or "John" if your account may hold many contacts over time.

The display name is a human convenience. The signing key is the real cryptographic identifier — the name is just how you find the right one.

Should you save both receive addresses?

Usually yes, if the contact provides them.

The classical age1... receive address is compact and fine for everyday sealed records. The hybrid age1pqc... receive address is built for long-lived sensitive material, where you want protection that holds up even against a future quantum attacker. If a contact publishes both, saving both gives you flexibility: when you compose, CardanoWall can use the address that matches the encryption mode you pick.

If the contact publishes only one, save what you have and add the other later. A contact added by signing key alone carries no receive address at all until you supply one — that's fine for recognizing their signatures, but you can't seal to them yet.

What should go in the notes?

Verification context — never secrets.

Useful notes:

"Verified via DNS TXT on 2026-06-14";
"QR handoff at office";
"Use hybrid address for legal archives";
"Rotated from previous address after device loss";
"Official security page confirmed";
"Confirmed by phone with known number".

Don't put passwords, Identity Seeds, private keys, decrypted file contents, or confidential case facts in contact notes. The notes are for how you trust this key, not for the things you're protecting with it.

How do you keep contacts current?

Review them whenever a relationship or a key changes.

Update a contact when:

the recipient rotates keys;
a team changes ownership;
a contractor leaves;
a public profile is retired;
the recipient publishes a new hybrid address;
a key may have been compromised;
you no longer send records to that party.

Remove stale contacts promptly. A stale address is worse than no address, because it gives you false confidence that you're sealing to the right person when you may not be.

How does this help when you compose?

It turns a key decision into a contact decision.

When you create a sealed record, you can choose from the contacts that have a usable receive address, by name. That cuts copy-paste mistakes and makes repeated workflows faster.

For example:

a legal team sends a sealed evidence bundle to the same outside counsel every time;
a security team sends incident material to a forensic partner;
a creator sends source files to a known client;
a newsroom receives confidential material through a public profile;
a company shares compliance evidence with its auditor.

The address book isn't just comfort. It's workflow memory. If you want incoming records limited to people you've already vetted, pair it with whitelist mode, which filters your Inbox to known contacts.

Be careful here.

An address book reveals relationships and workflows — who you talk to, and how often. A team may genuinely need a common set of contacts, but shared contact management should match the organization's security model, not just convenience.

Trusted contacts are saved per account, so even people who share a single identity each keep their own contact labels and notes. That can be good for privacy, but it means the team needs an explicit process for verifying keys and pushing updates. For high-value recipients, write down who verified the key and when. If your team works from a shared identity, Shared team identities covers the tradeoffs.

The short version

Build the address book before the urgent send.

Save each contact's signing key, receive addresses, a clear display name, the verification method, and useful notes. Verify through a channel you already trust. Keep entries fresh and drop the stale ones.

Then, when you seal a file, you pick the person you meant — instead of trusting a long string you pasted in a rush.