How CardanoWall Stores Your Identity

CardanoWall never stores your Identity Seed in plaintext. The server holds an encrypted vault that only your own passkeys can open, plus the public, non-secret data needed to run your account. The seed itself — the thing that is your identity — stays on your side.

Here is the mental model in one line: your Identity Seed is the portable identity and the real backup; the hosted vault is a passkey-unlocked convenience layer, not custody.

This post walks through what CardanoWall stores, what it deliberately cannot read, and what that means when something goes wrong.

What is an Identity Seed, and why does it matter?

A CardanoWall identity is built from one 32-byte Identity Seed. From that seed, deterministic key derivation produces the keys you actually use: an Ed25519 key that signs records and X25519-based keys that receive sealed files. The same 32 bytes always rebuild the same identity, anywhere — the website, the command-line tool, the SDKs, or any other software that follows the open Label 309 derivation rules.

That is the important property: the seed is portable, and it determines everything. The keys are downstream of it. So the only question that matters for storage is where the seed lives.

The answer is: with you. CardanoWall can keep an encrypted copy for convenience, but it stores ciphertext, not readable seeds.

What does CardanoWall actually store?

CardanoWall stores the service data needed to run your account. That includes:

your account login state;
billing and balance records;
your public identity keys;
public proof records and Cardano transaction references;
the encrypted identity-vault ciphertext;
API keys, kept only as hashes;
product settings such as each identity's lifecycle state;
your address-book entries and inbox preferences.

Notice what is not on that list. Your Identity Seed, your derived private signing key, your derived private receive keys, and any decrypted sealed files are all client-side secrets. They are never stored in a readable server column. The encrypted vault is the only place the server keeps anything seed-related, and it keeps it as ciphertext it cannot open.

For the full picture of what is visible to the service versus what stays on your device, see what CardanoWall can see.

What is the identity vault?

The identity vault is a single encrypted bundle that holds the secrets for your account's identities.

Inside the vault plaintext, each entry contains one identity's 32-byte seed and the private display label you chose for it — "Personal", "Press Team", whatever you typed. (An account can hold several identities; each gets its own entry.) The label lives inside the encryption too, so it is never exposed server-side.

Before any of this is stored, it is encrypted. CardanoWall keeps the result as one current vault row per account, in the age v1 format. The server can hold that ciphertext and hand it back to you, but it does not hold the key material needed to open it.

That is the whole point: the vault is not custody. It is an encrypted convenience cache. The canonical, portable artifact is still the seed.

What unlocks the vault?

Your registered passkey unlocks it — and nothing else can.

The vault is encrypted exclusively to WebAuthn passkey factors that support the PRF (pseudo-random function) extension, with one recipient stanza per passkey. There is deliberately no password-derived stanza and no public-key stanza in the hosted vault. During an unlock, your authenticator performs user verification and releases PRF-derived key material to the browser; that material opens the vault locally.

CardanoWall's server never receives the plaintext seed, the decrypted vault, or any private key derived from the seed. From the server's side, all it knows is that an account is authenticated and that it can serve back a blob of ciphertext. Your browser, driven by your passkey ceremony, is what opens it.

For how passkeys provide this lock and the recovery tradeoffs of different passkey types, see how passkeys protect your identity vault.

Why not just store the seed on the server?

Because that would turn CardanoWall into a custodian of your identity — and custody is exactly the failure mode the design avoids.

If a service stored plaintext seeds, or seeds it could decrypt itself, then a server breach could become a user-key breach. An attacker who stole the database or the server's keys might be able to sign as users or decrypt their sealed records. That is a single point of catastrophic failure.

CardanoWall is built around a different promise: a database leak should not reveal Identity Seeds, because the server never holds the material that opens them. The design is meant to make a hypothetical breach serious but not catastrophic for your keys.

The encrypted-to-passkeys-only choice has two specific consequences worth naming. Because there is no password-derived stanza, a stolen vault has nothing to brute-force — there is no human-chosen passphrase to grind through. And because there is no public-key stanza, there is no asymmetric target for a future quantum (Shor-style) attack to aim at; the keys protecting the vault are 256-bit symmetric values held inside your authenticators, where the relevant quantum threat is Grover-style search, leaving roughly a 128-bit effective security margin.

This does not make every risk disappear. It means the most important secret is not sitting in a readable server column waiting to be copied.

Is the vault a backup?

Not the backup of last resort. The real portable backup is the Identity Seed.

If you have the seed, you can rebuild the same identity in CardanoWall, the command-line tool, the SDKs, the desktop app, or any future Label 309 software that follows the same derivation rules. The seed is the one thing that travels everywhere.

The hosted vault helps you avoid retyping the seed every day. It can also help you move to another signed-in device when your passkey provider syncs the passkey across your devices. But the vault belongs to the service layer. It can be deleted, become unavailable, or be removed when you remove your last passkey. The seed is the thing to save. Why the identity seed still matters goes deeper on this.

What happens in the browser when you unlock?

When you unlock an identity, the browser needs temporary access to private key material. That is unavoidable: to sign a record, the client must hold the signing key; to decrypt a sealed file, it must hold the receive key. Those keys are derived from the seed in the browser, after you unlock.

The design keeps secrets out of ordinary persistent browser storage. The browser's local cache (IndexedDB) may hold the encrypted vault ciphertext — the same bytes the server has — so a page reload needs only one passkey tap instead of a network round-trip. It never caches the plaintext seed. The active private keys live in session memory, held outside the application's UI state, and are zeroized on lock or sign-out on a best-effort basis.

This is a web-crypto model, not hardware isolation, and it is honest about its limits. A malicious browser extension, a compromised device, or an active malicious script running during an unlocked session can read what is in memory while you are unlocked. Strict content-security policy, minimal scripts, and unlock-on-explicit-action-only reduce that surface, but they cannot eliminate it. CardanoWall removes server custody risk; it cannot make an untrusted device safe. The mechanics are covered in browser storage and session keys, and the broader principle in why keys never leave the device.

What happens when you remove a passkey?

The vault is rebuilt without that factor.

When you remove a passkey, the current vault is re-encrypted to the remaining factors and written as a new single row, replacing the old ciphertext in place. The removed passkey can no longer open the vault that exists. The service even enforces this at the storage boundary: a vault can never be written wrapped to a credential the account has already removed.

This is real revocation for the current hosted vault. It is service-layer control, not time travel. If a passkey was misused while it was still valid — for instance, used to open the vault and read the seed inside an active session — then the attacker may already hold the seed, and re-encrypting the vault afterward does not claw that back. In that case the right response is not a reset but a fresh start: create a new identity, deactivate the old one, and publish the new public keys where people expect to find them.

What happens if you remove a passkey walks through the exact sequence.

What if CardanoWall disappears?

Your published proofs still verify.

A Label 309 proof is designed to be standalone-verifiable. Verifying one depends on public Cardano data, on public content-addressed storage when the record points to it, and on the verifier's own copy of the original content or decryption material. A valid proof does not require CardanoWall to stay online — anyone with the transaction reference and a public Cardano explorer can check it.

Your identity also survives if you saved the seed. The same 32 bytes reconstruct the same identity in any conformant tool.

What you lose without the seed is the future use of that identity: producing new signatures, and decrypting sealed records addressed to it. The proofs you already published remain verifiable forever, but you can no longer act as that identity. This asymmetry — published proofs are permanent, future use depends on holding the seed — is the deliberate price of having no custodian.

What should you actually do?

Save the Identity Seed first.

Put it somewhere you trust for high-value secrets: a password manager, an offline secure location, or whatever model you use for things you cannot afford to lose. Then add a passkey for daily convenience.

For ordinary use, that combination is a strong balance: the seed stays portable, and the passkey keeps day-to-day access smooth. For high-risk identities, add operational controls — a hardware security key, a dedicated device, and a separate identity reserved for sensitive work.

One more thing to keep straight: a lost seed (with no unlock factors left) means the identity's future use is gone, but its proofs still verify. A stolen seed is full identity compromise, and the response is a new identity plus deactivating the old one — never a password reset, because there is no password to reset.

The short version

CardanoWall stores encrypted vault ciphertext, not plaintext Identity Seeds.

Your seed is the identity. Your passkey unlocks the encrypted vault. The browser uses private keys only after you unlock, and clears them on lock. The server can help you publish, sync, and conveniently recover access — but by design it cannot read or recreate your identity.

Save the seed. Use the passkey. Know the difference.