What Goes on the Blockchain When You Make a Proof?

When you make a proof with CardanoWall, what lands on Cardano is a small proof record, not your file. For a plain Proof of Existence, that record contains a hash of the exact bytes you are proving. For a sealed proof, it can also carry an encryption envelope and content-addressed links to encrypted ciphertext stored elsewhere. The plaintext file never has to go on Cardano at all.

That distinction is the whole point: a public proof is not the same thing as public content. You can create a permanent, timestamped commitment to a document and still keep the document private.

This is the model behind Label 309, the open standard CardanoWall implements. The rest of this article walks through exactly what is public in each kind of proof.

What is public in a hash-only proof?

In a hash-only proof, the public part is the record and the hash — nothing else.

The record says, in effect: someone committed to these exact bytes by this Cardano block time. The hash is a cryptographic fingerprint of the bytes. Later, a verifier can recompute the same hash from the original file and check that it matches the one on chain.

Anyone reading the chain can see:

the Cardano transaction;
the metadata label 309;
the Label 309 record bytes;
the content hash (or hashes);
the block time and confirmation context.

What they cannot see is the file itself — unless you separately publish that file somewhere.

That is why Proof of Existence works well for private documents, datasets, legal materials, compliance logs, and internal artifacts. You get a public, timestamped commitment without revealing the content. If you are new to the idea, what is Proof of Existence covers the foundation.

Does Cardano store my file?

No — not in CardanoWall's normal proof model.

Cardano stores the transaction and its metadata. In Label 309, that metadata carries the proof record, and the record can contain hashes, optional storage links, optional signatures, optional Merkle roots, and optional encryption-envelope data. The file itself is never uploaded as plaintext into Cardano metadata.

There is also a hard technical reason: Cardano constrains each metadata string to 64 bytes, so a record body is split into small chunks purely for transport and reassembled before anyone reads it. A whole file would never fit. Blockchains are not a place to dump private files; they are a place to anchor commitments that others can later verify. For the full mechanics, see how Label 309 works.

What happens when I attach a file?

It depends on which kind of proof you make. There are three modes.

Hash-only. CardanoWall hashes the file in your browser and publishes only the hash in the record. The original file stays with you and never leaves your device.

Public content with a storage link. The file bytes are placed in content-addressed storage, and the Label 309 record references that storage location. The content is public, and the link binds the fetched bytes to the record.

Sealed. The file is encrypted first. The encrypted payload is stored through content-addressed storage such as Arweave or IPFS, and the record references the ciphertext and carries the envelope data the right key holder needs to decrypt it.

In every mode, the hash is the proof. Storage only helps people retrieve the bytes; encryption only controls who can read them. This is the same hash-sign-seal-share progression described in hash, sign, seal, share.

What is public in a sealed proof?

A sealed proof is private content with a public commitment. The chain proves when; the encryption controls who can read it.

The public record reveals a deliberately narrow set of facts:

that the record is sealed (an envelope is present);
the plaintext hash;
content-addressed ciphertext links such as ar://... or ipfs://...;
the encryption envelope's header;
the key-encapsulation family used for the recipient slots — for example, classical or hybrid post-quantum;
the number of encrypted key slots;
any signatures included in the record;
the transaction time and on-chain metadata.

The public record does not reveal:

the plaintext file;
the decrypted message;
a readable list of recipients;
any recipient's private key;
the sender's private keys.

The ciphertext is public in one narrow sense — anyone can download it from storage — but without a matching key it stays unreadable. That is the normal pattern for sealed records: public proof, encrypted content, decryption that happens locally on the recipient's device.

Are recipient addresses written on the chain?

No. There is no readable recipient directory anywhere in the record.

In a Label 309 sealed record, recipients are reached through encrypted key slots. A recipient's client scans public sealed records and quietly tries to open each slot with its own private keys. When a slot opens, the client can decrypt the payload and show the record in the inbox. The chain never carries a field that says "recipient: Alice" or names a public profile — the recipient relationship is discovered by successful local decryption, not published.

To make this leak even less, the sender shuffles the slots with a secure random generator before publishing, so even their order carries no signal about who comes first. The only recipient-adjacent fact the chain exposes is how many slots there are — never who they belong to.

This is what separates the design from most messaging systems: the server does not need to know who the recipient is for the recipient to find their records. If you are receiving sealed records, how to receive sealed records explains the inbox side.

Does "sealed" mean anonymous?

No. Sealed means the record format does not publish the plaintext or a readable recipient list. That is genuinely useful, but it is not the same as full anonymity.

Plenty of surrounding signals can still reveal information:

transaction timing;
payment flows;
account activity at the gateway;
network metadata;
browser or device fingerprints;
repeated patterns in slot counts;
operational mistakes by the sender or recipient.

For sensitive work, hold this line carefully. Label 309 can keep plaintext and recipients out of the public record. It cannot erase every trace created by the surrounding network, payment, device, or human process — and a recipient who decrypts a sealed file can always choose to leak the plaintext afterward. Confidentiality of the content is not the same as anonymity of the participants.

What becomes public when a record is signed?

If a record includes signatures, those signatures are public — and so is the key behind each one.

A Label 309 signature lets a key vouch for the record body. That is useful when a company, creator, system, or identity wants to stand behind a proof. But a signature also exposes a public key, and depending on the signing path it can expose wallet-linked information. For public proofs, that may be exactly what you want. For sensitive sealed records, it usually is not.

This is why signatures are optional, never required. A hash-only record proves existence on its own. A sealed, unsigned record can avoid binding any sender identity into the record. A signed record adds accountability when accountability is the goal. The right choice depends entirely on the workflow.

One caveat worth stating plainly: a verified signature proves a key signed the record body. It does not prove that the same key submitted the transaction or chose its block time — anyone can republish an identical body. Read a verified signature as "signed by this key", not "published by this key at this time".

What is public in a Merkle proof?

A Merkle proof publishes a single root commitment, and nothing else about the batch.

Instead of putting thousands of hashes directly into Cardano metadata, you can build a Merkle tree from an ordered list of items and publish just one 32-byte root. The root is public; the full list of items stays off chain. Later, anyone holding an inclusion proof can show that one specific item was in the committed list, and that proof folds back up to the public root.

This is the right tool whenever the chain should commit to a large batch without exposing every item in it:

continuous-integration and release artifacts;
daily audit logs;
AI content outputs and dataset manifests;
compliance evidence;
legal evidence sets.

The root proves commitment to the list as a whole; the undisclosed items reveal nothing. The tradeoff is operational: your organization must preserve the off-chain leaf list and the inclusion-proof material, because the root alone cannot reproduce them. The pattern is covered in depth in one record for thousands of files.

Can CardanoWall read my sealed files?

By design, no. Sealing and decryption happen with keys that stay on your device, and the gateway is built so it never receives the private keys needed to decrypt sealed content.

The gateway does see public record data, the ciphertext, quote and publish metadata, account activity, and storage details. It does not need your Identity Seed or any recipient's private key to publish a proof, and those secrets are never sent to it.

That said, confidentiality is not only a protocol property. A compromised device, a malicious browser extension, a phishing site, a careless backup, or an ordinary operational mistake can still expose secrets. The record format can keep a properly sealed file unreadable to the gateway; it cannot protect a key that the user gives away. So the practical advice is unchanged: protect your Identity Seed, verify receive addresses out of band for sensitive data, and use trusted software. What CardanoWall can see goes through this boundary in detail.

What if I want nothing stored except the hash?

Then make a hash-only proof. Label 309 does not require any storage link — a hash-only record is fully valid on its own. You keep the original file privately and publish only the proof record.

That is often the right model for:

private contracts;
confidential datasets;
internal reports;
sensitive legal materials;
source artifacts that already live in a private repository;
anything where public storage would add risk and no benefit.

The tradeoff is simple. The hash will exist forever, but if you lose the original file you may no longer be able to produce the bytes that match it — and a hash with no matching bytes proves little. If that risk matters for a given document, a sealed proof is the better choice.

What if I want the encrypted file preserved?

Then make a sealed proof. Sealed proofs are built for cases where the original bytes matter and may need to be recovered later. The file is encrypted, the ciphertext is stored or referenced, and the public record commits to the plaintext hash.

Later, anyone holding a matching key can decrypt the ciphertext and demonstrate that the plaintext matches the on-chain commitment. This suits long-term evidence, sensitive records, and data that should stay confidential but should not disappear. If you need to share confidentially with specific people, confidential disclosure without public files is the practical guide.

The short version

Cardano stores the proof record — not your file.
The record can carry hashes, signatures, Merkle roots, encryption-envelope data, and content-addressed links.
Plaintext files never need to go on Cardano.
Sealed files live as ciphertext outside Cardano and are verified later against the on-chain plaintext hash.
Recipients are discovered locally by decryption, not by reading a recipient field on the chain.

That is the privacy model in one line: public commitments, private content, local verification.