What Is Proof of Existence?

Proof of Existence is a way to show that exact data existed no later than a certain time, using a public timestamp anyone can check.

The method is simple. Hash the data, publish that hash in a public timestamped record, and later let anyone with the original data recompute the hash and compare it against the record. If the two hashes match, the verifier knows the same bytes existed no later than the time of that record. They don't have to trust you, your server, or your account — only the public record and the math.

The file itself never has to be public. The proof can be public while the content stays private.

What does Proof of Existence prove?

It proves one narrow, useful claim:

These exact bytes existed no later than this public time.

That is all the basic proof asserts — and its strength comes from how specific it is.

Almost anything can be reduced to a cryptographic hash: a document, image, video, dataset, source-code archive, build artifact, contract, log file, model output, or manifest. The hash is a short fingerprint of one exact byte sequence. Change a single byte and the fingerprint changes completely.

When that hash is anchored in a public record, the record becomes a time witness. Later, if you show someone the original file, they hash it again. If the new hash matches the recorded one, they can confirm the file in front of them is the same data that was committed earlier — at or before the record's timestamp.

That makes Proof of Existence valuable whenever timing matters:

showing a file existed before a dispute;
showing a report existed before an audit deadline;
showing a software artifact existed at release time;
showing a dataset snapshot existed before it was modified;
showing an AI output, prompt set, or media file existed before it was challenged.

The proof is not a description of the file. It is a cryptographic commitment to its exact bytes.

Why doesn't the file need to be public?

Because the public claim is the hash, not the file.

A good hash function works like a one-way fingerprint. Anyone can compute the hash from the file, but someone who sees only the hash cannot reconstruct the file from it. That is why a private document can carry a public proof: the record says "someone committed to these exact bytes at this time" without revealing the bytes.

For example, a company can hash a confidential dataset manifest and publish only the hash. The dataset stays private. Later, if the company needs to prove what the snapshot contained, it can reveal the full manifest, a subset of it, or a single-item inclusion proof — whichever the situation calls for.

This is also why Proof of Existence suits legal, compliance, and security teams: it creates an external timestamp without putting private evidence into a public database. For a closer look at that pattern, see confidential disclosure without public files.

What role does the blockchain play?

The blockchain is the public time witness — the part nobody, including the publisher, can quietly rewrite.

If a hash lives only in your own database, the proof depends entirely on your system. When the timestamp is later questioned, someone can reasonably ask whether the database was rewritten, restored from a backup, edited by an administrator, or backdated. A public blockchain removes that doubt. Once a transaction is confirmed, the timestamped record is visible to anyone and is no longer under the publisher's sole control.

For CardanoWall, the proof record is anchored in Cardano transaction metadata under metadata label 309. A verifier fetches the transaction from a public Cardano explorer of their choice, reads the record, and checks the content hash against the original bytes. No CardanoWall server is involved in that check — the whole point is that the proof stands without us.

The blockchain does not understand your document, and it doesn't need to. It records the proof data; the meaning comes from a verifier recomputing the hash and confirming the bytes match.

What is the simplest proof?

The simplest proof is hash-only.

You pick a file. The software computes a hash, such as SHA-256 or BLAKE2b-256. That hash goes into a record published in Cardano metadata. Later, a verifier repeats the hash computation on the original file, and if the digest matches, the proof passes.

So the first level reduces to three facts:

The content exists.
Its hash is anchored on chain.
Anyone with the original content can verify the match.

For many uses, that is enough. A timestamped hash is powerful precisely because it is simple — there is little to misconfigure and nothing to trust.

When is a hash not enough?

A bare hash answers one question well, but not every question.

It does not say who created the file. It only shows the bytes existed. If two people both hold the same public PDF, either of them can publish a hash of it; the hash alone says nothing about authorship.

It does not preserve the file. Lose the original bytes and you still have a public hash, but you may have nothing left to match against it.

And it does not deliver the file to anyone. If another person needs the original data, a bare hash won't hand it to them.

That is why the underlying record format is layered. A hash-only record is fully valid, but the standard also supports signatures, sealed (encrypted) payloads, recipient-addressed delivery, and Merkle batching — each adding one capability on top of the timestamp.

How does a signature change the proof?

A signature adds a key-backed statement.

A signed record says more than "these bytes existed by this time." It can also say "this key signed this record." That matters for authorship, approvals, internal controls, and business workflows: an organization can use a signing key to show that a specific system, team, or identity vouched for a record, and a creator can sign a proof to associate their identity with a work.

The wording has to stay precise, though. A signature shows that the key signed the record — not who, in the real world, holds that key. Tying a key to a person depends on context established outside the record. (CardanoWall keeps signatures optional by design; anyone can publish, and verifiers never have to trust the publisher.)

How does sealing change the proof?

A sealed proof adds encrypted preservation.

In a sealed record, the on-chain proof still commits to the hash of the plaintext. But the file itself can be encrypted and stored at a content-addressed location — an ar:// (Arweave) or ipfs:// address — with only its reference in the record. The chain never sees the plaintext.

This matters when losing the original file would make the hash hard to use. With a sealed proof, someone holding the right key can later fetch the stored ciphertext, decrypt it, recompute the plaintext hash, and confirm that the decrypted file is exactly the content committed on chain. Because the storage address is derived from the bytes themselves, the recipient can also tell that a storage gateway returned the right bytes without trusting that gateway.

The public chain never has to expose the plaintext. The encrypted payload travels with the proof while the decryption key stays with whoever is meant to hold it.

How does recipient delivery change the proof?

Recipient delivery lets a sealed record be encrypted for someone else.

If you know a recipient's receive address (a public key they have shared), you can publish a sealed record that only they can open with their own key. Notably, the record carries no field saying "this is for Alice." There is no addressee on chain at all. The recipient's software scans public records and quietly trial-decrypts the ones that might be addressed to its keys, opening only the ones that actually are.

That turns Proof of Existence into more than personal timestamping. It can support confidential disclosure, legal evidence exchange, private compliance packages, and internal audit handoffs — workflows where the timeline should be public but the content must not be. Before you seal anything to someone, though, it's worth confirming the key really belongs to them; see verify a recipient before you seal a file.

One honest limit: encryption protects the bytes, not the people. Sealing keeps the plaintext readable only by key holders, but it doesn't guarantee anonymity, and a recipient can always leak the plaintext once they've decrypted it.

How does Merkle batching change the proof?

Merkle batching lets one record commit to many items at once.

Instead of one transaction per file, a system can hash thousands or millions of items, fold those hashes into a Merkle tree, and publish a single 32-byte root. Later, an inclusion proof shows that one specific item was part of the committed batch. The verifier doesn't need every file on chain: the root is the public commitment, and a short inclusion proof — one that grows only with the logarithm of the batch size — links an individual item back to that root. Every other item in the batch stays private.

This fits high-volume workflows:

CI/CD artifacts and release manifests;
daily compliance logs;
AI-generated content at scale;
dataset snapshots;
audit-evidence folders;
media and publishing archives.

Merkle mode keeps the on-chain record tiny while letting one proof cover an enormous set of items. For a worked example, see one record for thousands of files.

What does Proof of Existence not prove?

This is the section that keeps the proof honest. A timestamped commitment is strong because it is specific — and being specific means there are claims it simply does not make.

It does not prove a document is true. A false document can be timestamped just as easily as a true one.

It does not prove ownership. Anyone can hash a file they do not own.

It does not prove authorship on its own. Authorship needs signatures, key management, and real-world context layered on top.

It does not prove a software build is secure. It can show which artifact, SBOM, log, or manifest existed at a given time, but security depends on the build process and the controls around it.

It does not prove a dataset was lawfully collected or used. It can show that a dataset commitment existed — which may be important evidence — but legal rights are a separate question that depends on your jurisdiction and your counsel.

In short: Proof of Existence gives you timing and integrity, not truth or rights. Any further claim has to be built carefully on top of that foundation. What a proof does not prove goes deeper on exactly where the line sits.

Why CardanoWall builds on Label 309

A proof is only as useful as it is portable. One that works only inside a single website isn't much of a proof — a serious one should be readable by independent tools, verifiable from public infrastructure, and understood by software the original service never wrote.

That is why CardanoWall is built on Label 309, an open, vendor-neutral standard for Proof of Existence on Cardano. Label 309 — not the CardanoWall app — is the durable artifact; the web app, the command-line tool, and the SDKs are reference implementations downstream of it. The standard defines one record format that scales from a bare timestamp up:

hash-only proofs for simple existence;
signed proofs for key-backed authorship claims;
sealed proofs for encrypted preservation;
recipient-sealed proofs for private delivery;
Merkle proofs for high-volume batches;
named algorithm identifiers, so the cryptography can evolve over time without breaking older records.

The format is also being put through public review: Proof of Existence under metadata label 309 has been submitted to the Cardano CIP process and is under review by the CIP editors as a Metadata-category proposal. (Metadata label 309 is the on-chain identifier; the CIP number is assigned separately by the process.) The full standard, its reference implementations, and the open-source code all live publicly at github.com/cardanowall under permissive licenses.

CardanoWall is the interface. Label 309 is the record format. The proof is designed to outlive both — the interface and the company that helped you publish it.