Shared Team Identities: One Identity, Many People

A team can share a CardanoWall identity, but sharing an identity means sharing the Identity Seed. There is no lighter version of that.

Handing over the seed is a full delegation. Anyone who holds it can sign records as that identity and decrypt sealed records addressed to it. CardanoWall can make the workflow comfortable across separate accounts, but it cannot turn one seed into partial, revocable, per-person authority. The cryptography does not bend that way.

So use a shared identity only when shared authority is exactly what you want.

What is a shared team identity?

It is one Label 309 identity used by more than one person or account.

A Label 309 identity is rooted in a single 32-byte Identity Seed. Anyone who imports that seed reconstructs the same signing key and the same receive keys, in any account and in any compatible tool. The identity is not tied to one CardanoWall account, because the seed alone defines it.

A newsroom might run a "Press Team" identity this way. The senior editor creates the identity, saves the seed, and shares it with selected colleagues over a trusted channel. Each colleague imports the seed into their own account and unlocks it under their own passkeys. From that point on, all of them hold the same cryptographic identity.

What can every seed holder do?

Everything the identity can do. The seed is the root, not a scoped permission.

Every holder can:

sign new Label 309 records as the identity;
decrypt sealed records addressed to the identity;
read incoming sealed records once they unlock;
export the seed again and share it onward;
import the identity into another compatible tool, such as the open-source CLI;
publish the identity's receive addresses anywhere.

This is not like inviting someone to a workspace with limited permissions and a revoke button. There is no "read-only" or "publish-but-don't-decrypt" tier. Hold the seed, hold the whole identity.

When does a shared identity make sense?

When the outside world should see one identity that stands for a role, not a person.

Reasonable cases include:

a newsroom intake address;
a legal department's evidence identity;
a security disclosure contact;
an audit committee identity;
a compliance team identity;
a company records identity;
a small project's shared identity.

In each of these, the public-facing identity represents a function or a team, and the fact that several people stand behind it is the point.

What are the risks of a shared identity?

Attribution becomes shared, and so does exposure.

If several people can sign as the same identity, an outside verifier only ever sees one Ed25519 public key. The chain does not record which human used the seed. That can be exactly what the team wants — or a real accountability problem, depending on the situation.

The other risks follow from the same root:

any one member can leak the seed, deliberately or by accident;
one compromised device can compromise the whole identity;
a former member can keep a copy after they leave;
every sealed record sent to the identity is readable by every seed holder;
there is no key rotation in place — changing keys means moving to a new identity.

Shared authority works, but it needs operational discipline around it.

How does CardanoWall handle this across accounts?

Each account keeps its own encrypted copy of the shared identity.

If two people — call them Alice and Bob — both import the same seed, each account gets its own account-to-identity link and its own encrypted vault. Alice's passkeys unlock Alice's vault; Bob's passkeys unlock Bob's. The same cryptographic identity simply appears in both accounts, with no shared server-side state between them.

To attach a pre-existing identity, the importer has to prove they actually hold the seed — not merely that they know the public keys, which anyone can read from a profile or from the chain. The account signs a one-time server challenge with the seed-derived key before the link is created. This stops someone from attaching an identity they only know the public keys for, while still letting a genuine seed holder link it.

Display labels stay private to each account. Alice might label the identity "Press Team"; Bob might label it "Intake." Those labels live inside each account's encrypted vault, never in the public identity, so neither account can see the other's label and a database breach reveals none of them.

Billing stays per account, too. If Alice publishes from her account, Alice's account pays. There is no shared balance, because no balance could be cryptographically enforced when anyone with the seed can publish anyway.

Can a shared identity be revoked from one person?

Not cryptographically — not once they already know the seed.

CardanoWall can remove the identity from an account's vault, remove a passkey, or deactivate the identity in a given account. Those are real service-layer controls, and they matter for the accounts you control.

But none of them reach a copy of the seed that already lives in someone's password manager, a printout, their memory, a backup, a desktop tool, or a second account. Knowledge of 32 bytes cannot be recalled.

So if someone who held the seed should no longer have authority, the honest move is to create a new identity and retire the old one — not to pretend the old seed can be made secret again.

What is a good procedure for a shared identity?

Treat the seed like the high-value shared secret it is.

Before anyone shares it, the team should agree on:

who is allowed to hold the seed;
how the seed is transferred (in person, or end-to-end encrypted);
where the authoritative backup copy lives;
who may add the identity to an account;
which passkeys unlock each account's vault;
who is allowed to publish under the identity;
what happens when someone leaves;
when the identity must be replaced;
where new public keys get announced.

Write that down before an incident or a staff change forces the decision under pressure.

Should a team use one shared identity for everything?

Usually not.

Separate identities keep workflows clean and contain damage. A company might run one identity for security disclosures, another for legal evidence, another for public releases, and another for internal audits.

That separation limits blast radius. If one identity is compromised, the others do not automatically inherit the compromise. It also keeps the address book and whitelist mode easier to reason about, since each identity has a clear, narrow purpose.

What do you do when the team rotates?

Create a new identity. Knowledge of the old seed cannot be revoked, so a clean break is the only real fix.

When a shared identity is compromised, or when a former holder should lose access, the path is:

create a fresh identity and save its new seed;
share the new seed only with the members who should still have it;
update public profiles, receive addresses, and contacts with the new keys;
deactivate the old identity in the accounts you control;
stop using the old receive addresses;
optionally publish a record under the new identity that supersedes the old one.

Sealed records already addressed to the old key stay readable by everyone who ever held the old seed — including the person you are rotating away from. That is a property of encrypting to a long-term public key, not a bug you can patch. Plan around it; do not pretend the old seed can be un-shared.

The short version

Shared team identities are powerful and blunt.

They let a team operate one public Label 309 identity across several accounts and devices. But everyone with the seed has full signing and decryption power, and that power cannot be partially granted or quietly revoked.

Use a shared identity for roles that genuinely need shared authority. Use separate identities whenever accountability, separation, or rotation matters more.