What a Proof of Existence Does Not Prove

A Proof of Existence proves one narrow thing: these exact bytes existed no later than a public time. That is genuinely useful, and it is also the whole claim.

A valid proof does not automatically show that a file is true, original, owned by the publisher, legally usable, complete, or admissible in court. Each of those is a separate claim that needs its own evidence. The fastest way to use a proof well, and to avoid over-claiming with it, is to understand exactly where its guarantee stops.

This article walks through the claims people often assume a timestamp covers, says plainly which ones it does and does not, and shows how to add the missing layer when you need more.

What does a Proof of Existence actually prove?

It proves a byte-level commitment to a moment in time.

Someone takes a file, message, dataset, image, video, archive, or manifest and computes a cryptographic hash of it. That hash goes into a public, timestamped record. Later, anyone holding the original bytes recomputes the hash and compares it to the record. If the two match, the verifier can state one thing with confidence:

This exact byte sequence existed no later than the time of the public record.

With CardanoWall and the open Label 309 standard, that public record is Cardano transaction metadata published under metadata label 309. To check it, a verifier reads the transaction from a public Cardano explorer, reassembles the Label 309 record, validates its structure, and compares the hash (or, for batched records, a Merkle inclusion proof). No CardanoWall server, domain, or account is part of that check. The proof stands on the public chain alone.

That commitment is the foundation. Everything that follows is a different question.

Does a proof prove the file is true?

No. A false statement can be timestamped just as easily as a true one. A fabricated invoice, a mistaken report, a manipulated image — all of them hash to something, and all of them can be anchored.

A Proof of Existence does not judge content. It proves that specific content existed by a time, not that the content is correct.

That is still worth a lot. If a report is later corrected, the original report's proof shows what existed before the correction. If an image is disputed, the proof shows that a particular file existed before the dispute began. But whether the claim inside the file is accurate comes from somewhere else entirely: the surrounding evidence, the review process, the data sources, the witnesses, the context.

A proof fixes when and what bytes. It never decides true or false.

Does a proof prove ownership?

No. If a file is public, anyone can hash it. Timestamping a public PDF, photo, video, source file, or dataset does not make you its owner — it only records that you held those bytes by that time.

A timestamp can support an ownership story when it sits alongside other facts:

drafts and edit history;
signed records;
original source files;
contracts and licences;
employment or commissioning records;
repository history;
communications with collaborators.

The proof is evidence about timing. It is not a title deed, and it does not establish exclusive rights.

Does a proof prove who created the file?

Not by itself. A hash-only proof says that bytes existed; it says nothing about who made them. If two people hold the same file, either one can publish the same hash.

Label 309 records can carry an optional signature. A signed record proves that a specific cryptographic key signed the record body, which is meaningfully stronger than a bare hash because it ties the proof to a key rather than to whoever happened to submit the transaction. Signatures are always optional in the standard — a publisher who wants to stay issuer-agnostic simply omits them.

Even with a signature, the wording matters. A signature proves the key signed the record. It does not, on its own, prove the real-world person behind that key. That link comes from how the key was established: onboarding, a published public key, organizational policy, a contract, device custody, or another process outside the proof itself.

If you want a proof that also carries authorship, you sign it deliberately and manage the signing key with care. The walkthrough in hash, sign, seal, share covers when each of those steps is worth adding.

Does a proof prove the publisher was first?

Usually not on its own. A proof can show that the publisher held the bytes by a certain time. It cannot show that nobody else held them earlier.

This matters most for AI training data, datasets, creative works, and trade secrets. If a company timestamps a dataset manifest today, it has strong evidence that the manifest existed today. But if another party produces an older proof, repository history, or signed record, the timeline shifts toward them.

The practical lesson: publish early and consistently. A later proof is still useful, but an earlier public commitment is always the stronger one. The earlier you anchor, the harder your timeline is to undercut.

Does a proof prove the file was never changed?

It proves something more precise: that a file you have now matches the bytes that were committed.

It does not prove that no copy anywhere was ever altered. It does not protect your local disk, and it does not stop someone from editing a different version of the file. The verification question it answers is narrow and concrete:

Does this file match the hash in the public record?

If yes, the file in front of you is the exact byte sequence that was committed. If no, then either the file changed, the wrong file was supplied, the wrong hash was checked, or the record belongs to different bytes — the mismatch alone does not tell you which.

For anything you may need to defend later, keep three things together: the original file, the transaction reference, and any manifest or Merkle inclusion proof. If the original file itself might be lost, that is exactly the case for a sealed proof.

Does a proof preserve the file for you?

A hash-only proof does not. If you publish only a hash and later lose the original bytes, you may still have evidence that some byte sequence existed — but you may no longer be able to show what that sequence was.

This is why Label 309 supports sealed records. A sealed proof commits to the hash of the plaintext while storing the encrypted ciphertext at a content-addressed location, addressed with an ar:// (Arweave) or ipfs:// (IPFS) URI. A holder of the right key can later fetch the ciphertext, decrypt it, recompute the plaintext hash, and confirm it matches the on-chain commitment — recovering both the bytes and the proof that ties them to a time.

Hash-only is enough when you will keep the file yourself. Sealing is the better choice when recovery, or delivery to someone else, is part of the plan.

Does a proof prove legality or compliance?

No. A company can timestamp data that was collected improperly. A creator can timestamp content they have no right to distribute. A team can timestamp a compliance log that is incomplete. A vendor can timestamp a release manifest for software that still ships with vulnerabilities.

A Proof of Existence can support a compliance effort by making records tamper-evident and time-anchored. It cannot stand in for the compliance program itself.

Real compliance comes from policies, controls, lawful data collection, access records, retention rules, reviews, approvals, and sometimes external audits. A proof helps show what existed when. It does not certify that the underlying process was correct. If you are anchoring audit trails, compliance logs without vendor trust is about exactly that boundary.

Does a proof establish chain of custody?

No. Chain of custody is a process story: who collected an item, where it was stored, who accessed it, how it moved, what tools touched it, and what controls prevented tampering along the way.

A Label 309 proof can be one piece of that story. It can show that a file, an export, a log, or an evidence manifest existed by a public time and still matches later. It cannot name every custodian or explain every handling step unless those facts are themselves recorded — and ideally committed — elsewhere.

For evidence workflows, the pattern is to timestamp the manifest and keep the surrounding process records that the proof points back to.

Does a proof guarantee privacy?

No, and the limits are worth being specific about.

A hash-only record does not reveal the original file under normal conditions, but it still discloses that someone committed something at a certain time. And if the file is low-entropy or guessable, an attacker can hash likely candidates and check each one against the record until a match appears.

A sealed record goes further: the plaintext never goes on-chain in the clear — only its hash and a recipient-blind sealed envelope do, with the ciphertext kept off-chain — and Label 309 is deliberately designed so that recipient public keys never appear in the record at all. But privacy is bigger than the record format. Timing, fee payment, gateway logs, IP addresses, browser behaviour, storage access, file names that live outside the encrypted payload, and ordinary operational mistakes can each leak information the cryptography never touches.

Sensitive workflows need operational security around the proof, not encryption alone. When the goal is to disclose to a specific party without exposing anything publicly, confidential disclosure without public files covers the approach.

Does a proof guarantee anonymity?

No. An unsigned sealed Label 309 record can avoid putting a sender identity or a readable recipient list into the proof record itself — the slots that carry the wrapped keys reveal how many recipients there are, never who. That is a real and useful property. It does not make the surrounding publishing process anonymous.

The Cardano transaction still has inputs and pays a fee. A hosted gateway may see account, payment, network, or timing details. Fetching the ciphertext from storage can leave traces. A user can reuse an address or reveal context somewhere else.

So the honest claim is narrow: the record format can omit readable sender and recipient fields. Full anonymity depends on the whole operational setup, not on the bytes alone — a distinction that matters most in whistleblower evidence and similar high-stakes cases.

Does a proof guarantee it will be accepted as legal evidence?

No. Courts, regulators, arbitrators, and counterparties each decide what evidence they accept under the rules that apply to them. A cryptographic proof can be persuasive evidence of integrity and timing, but it is not a universal legal pass.

In some jurisdictions or contracts, a qualified timestamp, a notary, a regulated trust service, or a specific signature method may be required. In others, a public-blockchain proof may carry real weight as part of a broader evidence package. Which applies depends on the jurisdiction and the matter.

Use counsel when a proof will matter legally. A proof can help establish timing and integrity; it does not replace legal advice, and this article is not legal advice. The practical role a Proof of Existence tends to play in disputes is laid out in legal evidence and e-discovery.

How do you make a proof stronger?

You add the layer that matches the claim you actually need — and only that layer.

Need timing. Publish a hash, or a Merkle root for many files at once.
Need authorship or approval. Sign the Label 309 record and manage the signing key properly.
Need recovery of the bytes. Seal the file and store the encrypted ciphertext.
Need confidential delivery. Encrypt to the recipient's receive address.
Need high-volume evidence. Commit a single Merkle root and keep the leaf list and inclusion proofs; one anchor can stand in for thousands of files, as covered in one record for thousands of files.
Need legal weight. Combine the proof with policy, contracts, qualified services where your jurisdiction requires them, and a documented chain of custody.

Each layer answers a different question. Stacking them is how a bare timestamp becomes a proof that carries exactly the claim you intend.

The short version

A proof is strongest when it says only what it can actually prove.

Label 309 proves byte-level existence by a public Cardano time. On top of that it can add authorship signatures, sealed preservation, confidential delivery, and Merkle batching. It does not replace truth, ownership, law, identity, operational security, or process — and it does not pretend to.

That honesty is not a weakness in the design. It is what makes the proof dependable: you always know exactly what it backs, and exactly what it leaves to the rest of your evidence.