What CardanoWall Can See (and What It Can't)

CardanoWall can see ordinary service data and the public proof records you publish. By design, it does not see your plaintext Identity Seed, your private keys, or the plaintext of a file you seal. The most sensitive material is held and used on your device, not on our servers.

That is the honest version of the privacy model. CardanoWall is a hosted product built on a gateway, so it genuinely needs account, billing, publication, and indexing data to function. The interesting question is not "does CardanoWall see anything?" — it does. The interesting question is what kind of data it sees, and what stays encrypted from us.

This article walks through that line, category by category.

What account data does CardanoWall store?

Normal hosted-service data. Depending on how you use the product, that can include:

your account identifier;
login identifiers such as an email address or a linked OAuth account reference;
billing records and your prepaid balance;
API key metadata and the hashed form of API keys (never the plaintext key);
payment-processor references for top-ups;
account-level settings;
timestamps of account actions;
support and operational metadata;
rate-limit and security logs.

This is the same shape of data any account-based service holds. None of it is your Identity Seed.

What identity data can it see?

Public identity keys — and nothing private.

In CardanoWall, an identity is derived deterministically from a single 32-byte Identity Seed, and the public keys of that identity are what the service needs to do its job: list your identity, count its signed proofs, link an identity to your account after a possession check, and show a public profile when you choose to publish one.

So the service can see public identity data such as:

the Ed25519 signing public key;
the X25519 receive public key;
the optional hybrid post-quantum receive public key;
the identity's creation time in the service database;
the link state between an account and an identity;
any public profile fields you enable.

These are public or service-level facts. They are not the private signing key or the private receive key, and they cannot be turned back into your seed.

What does the server never need to see?

Anything that would let it act as you. The server does not need, and is built not to hold in usable form:

plaintext Identity Seeds;
Ed25519 private signing keys;
X25519 private receive keys;
hybrid (post-quantum) receive secrets;
the unlock material your passkey produces;
the decrypted contents of your identity vault;
the decrypted plaintext of a sealed file.

All of that lives on your device after you unlock, or in backups you control. The portable, canonical copy of an identity is its seed — that one artifact, not the hosted convenience layer, is the real backup.

What does the encrypted vault reveal to the server?

That it exists — and little else.

To let you unlock on a new device with a passkey, CardanoWall stores one current encrypted vault row per account. The server can read the row's metadata — when it was last updated, its version number, and which registered passkey credentials are associated with it — because it needs those for unlock UX and lifecycle management.

What the server cannot do is decrypt the vault. The vault is a single age-style ciphertext addressed exclusively to your WebAuthn passkey unlock factors (PRF stanzas). There is deliberately no password-derived unlock path and no public-key recipient added to it, so the stored ciphertext exposes nothing the server could grind offline. This is a service-layer convenience, not custody: we hold the locked box, your passkeys hold the only keys.

The vault's plaintext contains your Identity Seeds and your private display labels — exactly the material that must never be server-readable. The same design also governs revocation: removing a passkey re-encrypts the vault to your remaining factors and hard-deletes the previous ciphertext, so the removed authenticator can no longer open the current vault. That is real revocation for the current state, though it is not retroactive — a copy an attacker already exfiltrated and could still open is a separate problem. How passkeys protect your identity vault goes deeper on this.

What proof data is public?

The proof itself. Label 309 records are published on Cardano precisely so that anyone with the transaction reference can verify them. Depending on the record, the public data can include:

content hashes;
the transaction reference;
the block time the chain assigns;
the record's structure;
signatures and signer public keys, when the author chose to sign;
Merkle roots, for batched records;
encrypted-envelope metadata;
content-addressed storage URIs (ar://, ipfs://);
the number of encrypted recipient slots;
the key-exchange family used for a sealed record.

That data is public on purpose: it is what makes a proof verifiable without trusting CardanoWall. For a sealed record, note what is not there — the plaintext of the file never goes on chain. An observer can see that a record is sealed, how many recipient slots it has, and which key-exchange family it uses, but not who the recipients are and not the contents.

What can storage gateways see?

Stored bytes and request metadata.

If a record points at content on Arweave or IPFS, the public gateways that serve those bytes can see requests for them. For a public file, those bytes are plaintext. For a sealed file, those bytes are ciphertext, and they should stay unreadable without the recipient's private key.

Gateways can also observe timing, object size, and request patterns. They are not a place to put trust for confidentiality. That is the whole reason to seal a sensitive file before it goes to storage rather than relying on the storage layer to keep it private.

What can the browser see while you're unlocked?

Everything it needs to act as your identity — for as long as the session is unlocked.

After you unlock, your Identity Seeds and the private keys derived from them live in your browser's session memory so the app can sign and decrypt. When you decrypt a sealed file, the plaintext is in the browser too. On lock or sign-out, that in-memory material is zeroized on a best-effort basis.

This is client-side privacy, and it is honest about its limits. Keeping secrets on your device protects you from server custody, but it means your device and browser environment matter. A malicious browser extension, hostile local software, or an active cross-site-scripting flaw during an unlocked session can read what is in memory. Strict content-security headers, a minimal-script unlock flow, and unlocking only on explicit action all reduce that exposure — but they cannot eliminate it. For sensitive identities, use a device you trust; browser storage and session keys explains exactly what is and isn't cached.

What can the address book reveal?

Your contact list is service data, and it can be sensitive in its own way.

Trusted contacts are account-local entries that save you from pasting long public keys every time you seal a file to someone. An entry can hold a display name, a signing public key, optional receive addresses (classical and post-quantum), how and when you verified the contact, and free-form notes.

These are not Identity Seeds, but a list of who you correspond with can reveal relationships and workflows. CardanoWall's logging is written to keep that quiet: the server-side actions that create and edit contacts record only a request identifier and your account identifier — never the contact's name, keys, notes, or verification method.

What does CardanoWall not promise?

It does not promise invisibility.

CardanoWall is not an anonymity network. The blockchain, the storage gateways, the payment system, your account login, your browser, and your network path can all expose metadata. Publishing an unsigned sealed record keeps the sender, the recipients, and the plaintext out of the Label 309 record itself — but that is record-level privacy, not full anonymity. The fee-paying Cardano address, your IP as seen by gateways, and similar signals live outside the record and outside this guarantee.

It also does not make a compromised device safe. If your unlocked session is running malicious code, that code can see what you can see.

And a published proof is public by design. It shows that specific bytes existed by a specific public time. It does not, on its own, prove who authored them, who owns them, or that their contents are true — see what a proof does not prove for that boundary.

The short version

CardanoWall can see service data and public proof data. By design it does not see your plaintext Identity Seed, your private keys, your vault plaintext, or the plaintext of a sealed file.

So, in practice: seal sensitive files before they leave your device, keep a safe copy of your seed, unlock on devices you trust, and treat anything you publish on chain as permanently public.

Good privacy starts with knowing exactly where each kind of data lives — and CardanoWall is built so the data that matters most lives with you.