Your Identity Is a Seed

A CardanoWall identity is one secret: a 32-byte Identity Seed. Save it and you can rebuild the whole identity anywhere; lose it and you lose the ability to act as that identity in the future.

From those 32 bytes, compatible software derives the keys you use to sign records and to receive sealed files. If you back up the seed, you can restore the same identity in CardanoWall, in the cardanowall command-line tool, in the CardanoWall Desktop app, or in any other software that follows the Label 309 key model.

It is not a Cardano wallet seed phrase. It holds no ADA and pays no transaction fees. It is the portable root of your Proof-of-Existence identity, and nothing else.

What is an Identity Seed?

An Identity Seed is the secret root of a Label 309 identity. It is a single 32-byte value.

Think of it as the one thing you must keep to recover that identity later. Every public-key fact the standard expresses about you — the key that vouches for a record, the keys that receive a sealed file — is a deterministic function of those 32 bytes.

From the seed, conformant software can recreate:

the signing key used to sign records;
the classical receive key for sealed records;
the optional post-quantum receive key for sealed records.

The derivation is deterministic: the same seed produces the same keys every time, in every implementation that follows the standard. That is what keeps the backup simple. You do not save three private keys. You save one seed.

Why is it not a wallet seed phrase?

Because a CardanoWall identity is not a Cardano wallet.

A wallet recovery phrase controls funds. An Identity Seed controls a proof identity. It lets you sign Label 309 records and decrypt sealed records addressed to that identity. It does not custody ADA, pay Cardano transaction fees, or replace your wallet.

This separation is deliberate. A proof tool should never train people to paste a wallet recovery phrase where it does not belong. The Identity Seed has its own format and its own purpose, and it is designed to look visibly different from a wallet recovery phrase and from a public receive address.

So treat the reverse as a warning sign too: if a tool asks for your wallet recovery phrase in order to create a Label 309 identity, stop.

What does the seed look like?

The default backup form is a checksummed string that begins like this:

L309-SEED-1...

The uppercase styling is intentional. Secrets should look loud and different from public addresses, the same way a private key is written in uppercase while a receive address stays lowercase.

Tooling also accepts the raw 32-byte value as hexadecimal, but the human backup format is the one designed to be recognized and copied safely. Its checksum catches typos, truncation, and accidental corruption before they turn into a broken backup. The visual form is not the point, though — what matters is what the string represents: the 32 bytes that recreate the identity.

What keys come from the seed?

Three keys are derived from the seed, each for a different job. The standard expands the seed independently into each one, so a weakness in any single algorithm cannot leak the others.

First, an Ed25519 signing key. This signs Label 309 records. When a verifier checks a valid signature, it can say that this key vouched for the record body. Signatures are always optional — Label 309 is issuer-agnostic, and a record verifies on its content hash and chain timestamp whether or not anyone signed it.

Second, an X25519 receive key. This is the classical encryption key used to receive sealed records.

Third, an optional hybrid post-quantum receive key, which combines X25519 with a lattice-based key-encapsulation mechanism. It gives sealed payloads a stronger long-term encryption option while keeping the same one-seed backup.

You rarely need to see any of these private keys. The software derives them when needed; the thing you hold is the seed.

What can someone do with my seed?

Anyone who has your Identity Seed can act as that identity.

They can derive your signing key and sign records as you. They can derive your receive keys and decrypt sealed records addressed to you. That is the whole reason the seed is sensitive — it is the identity, not a password protecting the identity.

So handle it like a high-value secret. Do not paste it into unfamiliar websites. Do not send it over chat. Do not leave it in a plain-text file on a shared computer. And do not confuse it with a public receive address, which is safe to share. The receive address is public; the Identity Seed is not.

What happens if I lose it?

If you lose the seed and your unlock factors, you lose the ability to use that identity going forward. What you keep depends on what you still hold:

Proofs you already published stay on chain. Their timestamps do not depend on you.
Anyone can still verify those existing records, including signed ones.
But you may no longer be able to sign new records as that identity.
You may no longer be able to decrypt sealed records already addressed to that identity.
You may no longer be able to decrypt sealed records sent to that identity later.

This is the honest cost of end-to-end encryption. If no one else holds your secret, no one — including CardanoWall — can restore it for you. That property is exactly what keeps the service from being able to read your sealed files; it is also why the backup matters. (For the related question of why this single seed stays central even when passkeys make day-to-day unlock easy, see why the identity seed still matters.)

A note on the worse case: a stolen seed is full identity compromise, and there is no reset. The response is to create a new identity and deactivate the old one — not to rotate a password. The difference between an active, deactivated, and deleted identity is worth understanding before you need it.

How should I back it up?

Back it up like any secret that cannot be reissued.

A password manager is a reasonable home for most people. Some keep an offline copy in a safe place. Organizations may hold seeds under their existing key-management procedures, access controls, and recovery policies. The right answer scales with how sensitive the records are — but the principle does not change: the seed is the portable artifact, and the backup is a copy of those 32 bytes.

CardanoWall's own conveniences sit on top of that, not in place of it. On the web, your account can keep each identity in an encrypted vault that only your passkeys can open, so daily unlock is one tap — see how CardanoWall stores your identity. The vault is convenience and roaming, not custody: the service stores ciphertext it cannot decrypt, and the seed remains the ultimate backup.

Can I use the same seed in another app?

Yes — as long as the other app follows the Label 309 key model.

That is the whole point of standardizing the seed. A proof identity should not be trapped inside one interface. The same seed should restore the same identity in a web app, the command-line tool, the desktop app, an SDK integration, or a future third-party product that implements the same derivation rules.

This is what vendor independence means in practice. If CardanoWall helps you create a proof, that proof stays verifiable outside CardanoWall — a verifier needs only the transaction metadata, optionally the file bytes, and a public Cardano explorer. And if CardanoWall helps you create an identity, the seed stays useful in any compatible software. The standard, the reference SDKs, and the CLI are all open source under github.com/cardanowall.

Can I have more than one identity?

Yes, and many people should.

You might keep one identity for personal records, one for work, one for a company process, and one for a specific high-risk workflow. Each identity has its own independent seed, and each seed produces its own signing and receive keys. Keeping them separate makes privacy, access control, and operations easier to reason about.

A few concrete examples:

A journalist may not want the same receive address for public tips and internal newsroom records.
A company may not want the same signing key for CI/CD release proofs and legal evidence packages.
A researcher may separate public claims from private dataset proofs.

The seed model supports this directly. Each identity stands alone, with no shared root linking them.

How does this relate to a receive address?

A receive address is the public string other people use to send you sealed records. It is derived from your identity's receive keys, it is safe to share, and it lets no one read your messages or sign as you.

There are two forms. Classical receive addresses begin with age1…. The optional hybrid post-quantum receive addresses begin with age1pqc1…. Both are public.

So the rule to keep clear, in the product and in your own habits, is simple: the receive address is public; the Identity Seed is private. They should never be mistaken for each other.

How does this work with the desktop app?

CardanoWall Desktop — a cross-platform Rust and Tauri application built on the open-source Rust SDK — is open source at github.com/cardanowall. It is built around local ownership of identities, and it is worth understanding how that works.

Identities live in an encrypted local vault on your machine. The Rust core handles unlock, signing, verification, trial-decryption of incoming sealed records, and sealed-record decryption — all locally. Private keys never leave the device and are never sent to a gateway. Because the app is offline-first, records and decrypted files you have already synced stay usable with no network connection, and "offline" is treated as a normal state rather than an error.

The desktop app is still just one client, though. Your identity is portable across all of them — the same seed restores the same identity here as anywhere else.

What does CardanoWall actually know?

As a hosted service, CardanoWall sees account information, billing state, gateway activity, public record data, and whatever metadata is needed to run the product. What it is designed not to need is just as important:

It does not need your Identity Seed to publish a proof.
It does not need recipient private keys to deliver sealed records.
It cannot decrypt your sealed files.

The proof model is strongest when private keys stay with you and verification can run independently of the service. That does not erase every risk: a malicious browser extension, a phishing site, a compromised device, or a simple mistake can still expose secrets, and a script running inside an unlocked session can read keys held in memory. The right mental model is not "nothing can go wrong." It is "the protocol does not require CardanoWall to hold the keys that decrypt your sealed records."

The short version

Your Identity Seed is the root of your Label 309 identity. It is 32 bytes, and it is the real backup.

Save it. Protect it. Do not confuse it with a wallet seed phrase, and do not share it the way you would a receive address.

With the seed, compatible software can restore your signing key and your receive keys. Without it, your published proofs still verify on chain — but your ability to sign as that identity or decrypt sealed records may be gone. CardanoWall is one interface among several. The identity is the seed.