Confidential Disclosure Without Publishing the File

You can prove a file existed at a certain time without making the file public.

That is what a sealed Label 309 record does. The sender hashes the plaintext, encrypts the file, and publishes a proof record on Cardano. The ciphertext is stored at a content-addressed location and made available only to the key holders who can decrypt it. The public blockchain proves that a specific commitment existed by a public block time; the plaintext stays readable only to the chosen audience.

This fits legal, compliance, security, journalism, partner, and internal investigation work — anywhere the timeline matters but the document should not be posted to the open internet.

What does confidential disclosure mean here?

It means sharing evidence with a specific audience instead of the whole world.

That audience might be a lawyer, an auditor, a regulator, a journalist, an internal investigation team, a customer's security contact, a board committee, a partner — or a future version of yourself.

The goal is to prove the evidence existed at a certain time without putting the plaintext on a public blockchain or a public website. Sealed Proof of Existence is built for exactly that shape: a public time claim over a private file.

What actually goes on the public chain?

The proof record goes public. The plaintext does not.

The on-chain record can carry:

the plaintext hash — this is the proof of timing;
the Cardano transaction's block time;
an encryption envelope holding the wrapped key material;
one or more content-addressed ciphertext URIs (ar:// or ipfs://);
an optional signature, if the sender chooses to sign;
a Merkle root, if the disclosure covers many files at once.

The record deliberately does not carry:

the plaintext file;
a readable recipient list;
any recipient's private key;
your Identity Seed;
the decrypted evidence.

One nuance worth stating plainly: recipient public keys never appear on chain either. A recipient is not named in the record — they discover that a record is theirs only by successfully trial-decrypting it. An observer learns that a record is sealed, sees its plaintext hash and block time, and can count the wrapped key slots, but the slots are shuffled into a secure random order before publication, so even "primary recipient first" leaks nothing. The count tells you how many, never who.

The ciphertext itself can be downloaded by anyone who has the URI. Without a matching key, it stays unreadable.

How does a recipient open a sealed record?

The recipient shares a receive address with the sender, and the sender seals the record to it.

A receive address is just a public key. The sender wraps the file's encryption key to that address. Later, the recipient's client scans public Label 309 records and tries to open each record's encrypted key slots with its own private receive keys — all locally, on the recipient's device. Nothing about which records are theirs ever leaves the machine.

When a slot opens, the client fetches the ciphertext, decrypts it, recomputes the plaintext hash, and checks that hash against the on-chain commitment. A match confirms two things at once: the recipient has the real file, and that exact file is the one committed at the recorded block time.

Because the recipient holds a private key, this is where verification crosses from "a commitment existed" to "this specific content existed." For the sender-side mechanics of sharing a receive address and receiving sealed records, see how to receive sealed records.

Why not just email the encrypted file?

Email can move files, but it is not a durable, independently verifiable timestamp.

A message can be deleted, altered, or lost. Attachments get stripped. Mail servers get decommissioned. Export formats are messy and hard to authenticate years later. None of that gives a verifier a way to prove when the file existed.

A sealed Label 309 record gives the file a public proof anchor that does not depend on your mailbox or anyone's server. The encrypted payload can be preserved separately, and the recipient can later prove that the decrypted content matches a hash committed on a public chain. You can still notify the recipient by email — just don't let the proof depend on it.

Why not just upload the encrypted file to private storage?

You can, and you often should. But private storage alone gives you no public time anchor.

A company storage bucket, a case-management tool, or a secure portal can hold encrypted files perfectly well. What none of them answers on their own is: can a later verifier prove when that encrypted package existed, and that the decrypted plaintext matches a public commitment? Without that, "we had this file in March" is an assertion, not evidence.

Label 309 adds the timestamped commitment. It does not replace your secure storage — it gives that storage a verifiable proof layer on top.

When should the disclosure record be signed?

Sign it when accountability matters more than anonymity.

Signing a record is optional. A signature lets a specific identity key vouch for the disclosure — useful when a company sends a formal evidence package to an auditor, or when a legal team needs an accountable, attributable record. The signature is a public-key-backed authorship claim, and a verifier can check it without trusting any server.

Leave the record unsigned when the sender's anonymity matters more. An unsigned sealed record binds no sender identity on chain at all, which is exactly what whistleblower drops and sealed-bid scenarios need. The tradeoff should be a deliberate choice: a signature can establish who stood behind the disclosure, and in sensitive contexts that same attribution can reveal more than the sender wants.

Can one record reach several recipients?

Yes. A single sealed record can wrap the file's encryption key into separate slots for multiple recipients.

Each recipient opens the record with their own key, and one recipient cannot use their slot to derive another recipient's key. That covers a law firm and its client, an internal investigation team, an auditor and a company contact, several regulators at once, a board committee — or a sender who keeps a recoverable copy for themselves while sharing with others.

The public record may reveal the number of slots, but never a readable list of who they belong to.

What about a large evidence package with many files?

Use a manifest and Merkle batching instead of one transaction per file.

Hash each file into a leaf, fold the leaves into a single Merkle root, and publish that one root in the Label 309 record. Seal the manifest and the supporting files as needed. Later, a recipient or auditor can verify any individual file with a short inclusion proof — entirely offline — rather than treating the whole package as an opaque archive. Inclusion proofs grow only with the logarithm of the batch size, so a thousand-file disclosure still verifies item by item.

This is the same one-root-for-many-files pattern described in one record for thousands of files; here it makes large disclosures inspectable instead of all-or-nothing.

What does a sealed record actually prove?

The claims are strong, but they are specific. A sealed Label 309 record can show:

that exact data existed by a public block time;
that decrypted ciphertext matches the committed plaintext hash;
that a specific key signed the record, if the record is signed;
that a specific file was included in a Merkle-batched evidence set;
that a recipient who holds the key and the ciphertext had access to decryptable evidence.

Each of those is a precise, independently checkable statement about timing and integrity.

What does it not prove?

Just as importantly, here is what it does not establish:

It does not prove the evidence is true. A proof certifies bytes and timing, not facts.
It does not prove the sender had a legal right to disclose the file.
It does not prove the recipient's real-world identity unless the receive address was verified through a trusted process. Confirming who really owns an address is a separate step — see verify a recipient before you seal a file.
It does not provide anonymity. Timing patterns, network metadata, gateway and payment trails, device fingerprints, and operational mistakes can all reveal information that lives outside the record. A recipient can also leak the plaintext once they have decrypted it.
It does not replace legal counsel or safe-disclosure procedures, and whether a given proof helps in a dispute depends on the jurisdiction.

For the general version of this boundary, see what a proof does not prove.

How should a team set this up before they need it?

Define the disclosure workflow before the crisis, not during it. Decide in advance:

who can create sealed disclosures;
which identity, if any, signs formal records;
which receive addresses are trusted, and how they were verified;
where the ciphertext is stored;
who is allowed to decrypt;
how manifests are structured for multi-file packages;
how transaction references are recorded and handed off;
how evidence is exported for legal review.

The cryptography is only one layer. The surrounding process is what determines whether the proof is actually useful when pressure arrives. For an evidence-handling perspective, see legal evidence and e-discovery and, for higher-risk sources, whistleblower evidence.

The short version

Confidential disclosure needs two things at once: privacy and proof.

Sealed Label 309 records keep the file encrypted for chosen key holders while publishing a public, timestamped commitment to its hash. Recipients decrypt locally and confirm the plaintext matches the on-chain hash. Signatures, Merkle roots, and multi-recipient slots add stronger workflow options when you need them.

Use it to prove the timeline without ever publishing the file.