Active, Deactivated, Deleted: What Each Identity State Means

CardanoWall gives each identity in your account a lifecycle state that controls how that identity can be used. Active means full use. Deactivated means the identity stays listed and can still decrypt, but it is blocked from new signing, publishing, and sending in your account. Deleted is not a state at all — it is an action that unlinks the identity from your account and removes its entry from your encrypted vault; re-importing the saved Identity Seed restores access.

None of these account-level actions rewrites the blockchain. A proof you already published stays valid and verifiable, forever, no matter what state the publishing identity is in.

Why does an identity have a lifecycle at all?

Because the cryptography and the account are two different layers, and only one of them is permanent.

A CardanoWall identity is built on the Label 309 standard, where an identity is exactly one thing: a 32-byte Identity Seed and the keys derived from it. That binding is immutable — one seed is one identity, for the life of that identity. There is no "rotate the key under the same identity." (If that idea is new, start with your identity is a seed.)

But a hosted product still has to answer everyday account questions that the cryptography does not:

Should this identity be usable for new records?
Should it stay visible for old records?
Should it keep decrypting incoming sealed records?
Should it remain attached to this account at all?
Should the user be warned before relying on an old identity?

Lifecycle states answer those product questions without touching the seed. They are account bookkeeping layered on top of a cryptographic fact that never moves.

What does an active identity do?

Active is normal use. An active identity can:

sign new records;
publish proofs;
send sealed records;
decrypt sealed records addressed to it;
appear in the identity switcher;
sync inbox state;
be selected in the composer.

Most identities spend most of their life active. The other two states are deliberate choices you make about a specific identity.

What does deactivating an identity do?

Deactivating means: do not use this identity for new authorship in this account.

A deactivated identity stays in the account and keeps its read access. It can still decrypt sealed records — including records that arrive after you deactivate it. What it cannot do is sign, publish, or send from that account until you reactivate it. This is enforced on the server, not just by a greyed-out button: the publish path checks the identity's state before it does anything.

Deactivation is the right tool when:

a team is rolling over to a replacement identity;
a key may be old but is not confirmed compromised;
an identity should go read-only for a while;
a workflow is paused;
a shared identity should stop publishing from one particular account.

It is fully reversible. Reactivating flips the same switch back and restores full use.

Why can a deactivated identity still decrypt?

Because deactivation is something your account knows and senders do not.

The state lives in CardanoWall's records, never on the blockchain and never in the Label 309 wire format. A sender who already holds your receive address can still encrypt a sealed record to it, and Cardano will accept that record as long as it is otherwise well-formed. There is no on-chain signal that would tell the sender to stop.

So if your account still holds the seed, it can still open what arrives. Blocking decryption would punish the recipient and risk losing genuinely important incoming evidence, while doing nothing to stop the sender. Deactivation therefore draws the line where it is useful: it blocks new authorship and leaves read access intact.

What does deleting an identity do?

Deleting removes the identity from this account — and nothing more.

When you delete an identity, two things happen together. The account-to-identity link is removed, and the identity's seed entry is removed from your account's encrypted vault, which is re-encrypted to the remaining identities. The link is dropped first, so list membership and the publish gate flip immediately even if the vault rewrite needs a retry; a vault entry with no link behind it is inert.

After that, this account can no longer unlock or use the identity — unless the user re-imports the saved Identity Seed.

What delete deliberately does not touch:

It does not touch any other account's link to the same identity. Each account that holds the identity keeps its own independent copy, so an identity you share with a teammate keeps working in their account.
It does not delete anything from the blockchain.
It does not delete records the identity already published.

Delete is the end of this account's custody of the identity. There is no "destroy this identity everywhere" button, and there cannot be one — every holder of the seed keeps full power over it, and signed proofs on Cardano are permanent.

Can you undo a delete?

Yes — if you saved the seed.

Because the Identity Seed is the identity, re-importing the same seed reconstructs the exact same public and private keys. The account can then link to that identity again. CardanoWall requires you to prove you actually hold the seed during this step (by signing a one-time challenge with the seed-derived key), not merely that you know the public keys, which are visible to anyone. Once that proof checks out, the link is restored.

If you did not save the seed, deletion can make sealed content unreadable from that account — permanently. That is why deletion warnings should be blunt: delete only if the seed is backed up somewhere you control, or you are genuinely comfortable losing future access from this account. (Why the Identity Seed still matters goes deeper on this.)

Do lifecycle states affect proofs you already published?

No. This is the whole point.

A published proof verifies from public chain data alone. If a record was signed by an identity, that signature is a mathematical fact about the bytes — and no CardanoWall account state can make it disappear. A verifier resolves the signer's public key straight from the transaction metadata and checks it against public material; no CardanoWall server is consulted, so no account state can be consulted either.

This is essential for Proof of Existence. The promise is that a published record survives service state, account state, and even the vendor: you do not have to trust CardanoWall's servers, domain, or continued existence to verify it. Your interface may show that an identity is deactivated or deleted in your account, but a verifier treats the on-chain record exactly the same regardless. (A proof still has limits worth understanding — see what a proof does not prove.)

What if the seed is compromised?

Create a new identity. Do not rely on deactivation alone.

Deactivation is a service-layer control, not cryptographic revocation. If someone has the seed, they can still use that identity outside your account and outside CardanoWall entirely — the seed works in any conformant tool, with no service in the loop. Flipping a state in your account does nothing about that.

For a suspected seed compromise:

create a new identity and save the new seed;
deactivate the old identity in your account;
stop advertising the old receive address in public places;
republish the new public keys through the channels people trust to reach you;
where it matters, publish new records that supersede the affected ones, signed under the new identity.

The old identity cannot be made un-compromised. The seed is the only thing that ever conferred control over it, and a leaked secret stays leaked. This is the same reason a removed passkey is not retroactive: a service-layer action can cut off future access, but it cannot reach back and undo exposure that already happened.

How should a team use these states?

Treat lifecycle states as policy, not as a substitute for seed custody.

A team should decide, up front, when an identity is:

active for daily work;
deactivated after a project ends;
deactivated during a compromise investigation;
deleted from a member's account after they leave;
replaced with a new identity after a seed is exposed.

The one thing these states cannot do is revoke knowledge of a seed. A departed member who still holds the 32 bytes keeps full power over a shared identity, no matter what any account does. Excluding them means replacing the identity — a fresh seed shared only with the people who remain — not deactivating the old one. Shared team identities covers the trade-offs of running one identity across several people.

What is the safest default?

Deactivate before you delete.

When you are unsure, deactivation is the gentler choice. The identity stays visible and keeps decrypting, but new use is blocked, and you can reactivate at any time. Nothing is lost.

Delete only when you are confident that at least one of these holds:

the seed is backed up somewhere outside CardanoWall; or
the identity is genuinely no longer needed; or
this account simply should not have access to it anymore.

Deleting without a seed backup is the most common way people lock themselves out of their own sealed content.

The short version

Active means normal use. Deactivated means read-only in this account — it still decrypts, but it cannot sign, publish, or send. Deleted means unlinked from this account and dropped from its vault, recoverable only by re-importing the seed.

These states help you manage identities inside CardanoWall. They do not change the cryptographic facts already written to Cardano. The Identity Seed remains the final recovery path — so save it before you delete anything.