Prove One File from a Merkle Batch: The Inclusion Certificate

When you publish a batch of files to Cardano, only one small fingerprint goes on chain: a single Merkle root that stands in for the whole list. That keeps publishing cheap. But it raises an obvious question — if only the root is on chain, how do you later prove that one particular file was really in the batch?

The answer is an inclusion certificate: a small file you can download that proves one specific file's hash was part of that published batch. Anyone can check it in their own browser, against any public Cardano explorer, with no trust in CardanoWall. And because the proof is baked into the file, it keeps working forever.

This is the everyday companion to Merkle batching. Batching is how you commit to thousands of files at once; an inclusion certificate is how you pick one of them back out and prove it later.

What problem does an inclusion certificate solve?

Imagine you published a thousand files in a single batch last year — a folder of contracts, a set of release artifacts, a day of audit logs. All of them were folded into one Merkle root, and that root was timestamped on Cardano. Cheap, compact, done.

Now someone challenges just one of those files. Maybe a counterparty asks, "Can you show this exact contract existed before the deadline?" The blockchain only holds the root, not the file and not the list. Pointing at the transaction proves some batch of a known size existed — but not that this one document was inside it.

An inclusion certificate closes that gap. It is a tiny, self-contained file that says, in effect: "this file's hash was item number 42 of the batch behind this Cardano transaction, and here is the exact math anyone can run to confirm it." You hand over the certificate, and the other side checks it without needing you, your account, or even our website to still exist.

What does a certificate actually contain?

Think of it as a sealed evidence packet with three parts.

The fingerprint of your file. Not the file itself — just its hash. The certificate never carries your document's contents, so it is safe to share even when the file is private.
The proof path. A short list of "sibling" fingerprints that let anyone fold your file's hash back up the Merkle tree and arrive at exactly the published root. This is the part that makes the certificate self-contained: the math is baked in, so no one ever has to ask you for the rest of the batch.
The blockchain anchor. The Cardano transaction the root was published in, the time the blockchain recorded for it, and a couple of public explorer links so anyone can look it up themselves.

It also includes a plain-English claim line stating what the certificate proves, and a short note on how to verify it independently. One certificate can cover one file or several at once — each gets its own proof path and a clear verified mark.

CardanoWall can hand you this packet in a couple of formats: a JSON file (the machine-readable original that tools can re-check) and a PDF (a readable, printable version for people and legal files, with the JSON tucked inside it as an attachment so the document is still machine-verifiable).

How do you get one?

You make it yourself, on the transaction's page, in your browser.

Open the public page for the transaction that carried the batch. Because the record contains a Merkle root, the page offers an inclusion check. From there it is two small steps:

Tell it which file. Either paste the file's hash, or just drop the file onto the page — your browser hashes it locally and never uploads it.
Read the result. The page fetches the batch's leaf list, recomputes the proof, and shows you a clear green (your file is in the batch) or red (it is not) result.

When it is green, you download the certificate — JSON, PDF, or both. That download is the portable proof. Email it, file it, attach it to a contract, drop it in a data room. It is now independent of CardanoWall entirely.

The whole thing happens client-side. We don't generate the certificate on a server and ask you to trust it; your own browser does the work, which is exactly why the result is trustworthy.

Why doesn't anyone have to trust CardanoWall?

Because nothing in the certificate depends on us being honest, online, or even in business.

Two claims sit inside an inclusion certificate, and both are things anyone can check for themselves:

Your file was in the batch. A verifier folds your file's hash up the proof path and confirms it reproduces the published root. This is pure arithmetic — it needs only the certificate file, nothing else. If even one bit of your file changed, the fold would land on a different root and the check would fail.
The root really is on Cardano. A verifier looks up the transaction on any public Cardano explorer — Cardanoscan, AdaStat, one of their own choosing — and confirms the same root sits in the on-chain record. No CardanoWall server is involved in that lookup at all.

Put together, those two checks prove the file existed on or before the time the blockchain stamped on that transaction. And that time comes from Cardano, not from us. We cannot fast-forward a block, backdate a transaction, or quietly edit history; the blockchain decides when things happened. That is the whole point of anchoring to a public chain instead of asking you to trust a company's clock.

If CardanoWall vanished tomorrow, every certificate we ever issued would keep verifying. The open-source cardanowall command-line tool, and any independent tool that understands the format, can re-run the same checks.

flowchart LR
  A["Your file"] -->|"hash locally"| B["File hash"]
  B --> C["Fold up the proof path"]
  C --> D["Recomputed root"]
  E["Cardano transaction<br/>(public explorer)"] --> F["Published root + block time"]
  D -->|"must match"| F
  F --> G["Existed on or before<br/>the block time"]

What does a certificate not prove?

A certificate is precise about one thing and silent about everything else — and being honest about that is what makes it trustworthy.

It proves that a specific file's hash existed on or before the blockchain's block time, and that it was part of the committed batch. That is it. In particular:

It does not prove who created the file. A certificate says nothing about authorship. Anyone could have published the batch. (Authorship in Label 309 is a separate, optional signature, never assumed — see what a proof does not prove.)
It does not prove the file is true, accurate, or lawful. It proves the bytes existed by a certain time, not that what they say is correct.
It does not prove the file is the only or the original version. It proves this exact file was in the batch — not that no other version exists.
It is not a "qualified" timestamp. This is a blockchain-anchored timestamp, the same family as other blockchain timestamps. It is strong corroborating evidence of timing, but it is not an eIDAS qualified electronic timestamp from a regulated authority. If a process specifically requires a qualified timestamp, this does not by itself meet that bar (see proof of existence vs. a timestamp authority).

The certificate's value is exactly that it overclaims nothing. It nails down timing and integrity, and it leaves the meaning to the documents and people around it.

How does this relate to OpenTimestamps?

If you already know OpenTimestamps, the idea will feel familiar.

OpenTimestamps gives you a small .ots proof file: a portable, self-contained timestamp that anyone can verify later without trusting the service that made it. An inclusion certificate is the same shape of thing — a portable proof file you can hand to anyone — with two differences worth knowing.

The timestamp authority is the Cardano blockchain, with the time taken from the block that carried your root, rather than from a calendar server. And the proof math is the same Merkle-tree construction used elsewhere in the standard, so a single certificate can pick one file out of a large committed batch. Same spirit, different anchor.

For a fuller side-by-side, see how Proof of Existence compares to OpenTimestamps.

The short version

Publish many files under one Merkle root and you keep the blockchain cost tiny. An inclusion certificate is how you later prove that any single one of those files was really in the batch: a small download, checkable in your own browser, against any public Cardano explorer, with the time supplied by the chain and no trust in CardanoWall. The proof path is baked into the file, so the certificate keeps working long after any particular tool, account, or company is gone.