The proof nobody can verify

Anchoring a decision ledger to a public chain has become an almost trivial exercise. Take the events, build a Merkle tree, write the root in a transaction. An afternoon of work, a line in the changelog, and from that point on the system "is anchored". The half almost nobody designs with the same care comes later: someone outside your company has to be able to check one specific claim without trusting you.

Four things, and they must exist together

A verification is not a statement, it is a computation someone else repeats. For that computation to be possible, four elements have to be available, and the operative word is together.

The original entry, byte for byte as it was when it was hashed. Not the record re-read from the database and reserialized by a newer version of the application: that produces a different hash, and a different hash is indistinguishable from tampering.

The inclusion proof for that entry — the path of sibling nodes from the leaf to the root. It has to be stored, or regenerable by anyone holding the ledger, not only by the internal tool that runs on one machine on your team.

The root, at a block height someone can name. "It is on the chain" is not a coordinate; the block number and the transaction hash are.

And a way to read that chain that is not your API. This is the one that breaks most often. If the auditor has to call your server in order to check your claim, they are trusting you again — through a different door, with more moving parts in between. What is needed is a public node, an independent explorer, something you do not control.

The ways you lose it are boring

None of these failures are dramatic, which is exactly why they go unnoticed until the wrong moment.

The entry gets reserialized by a refactor, and the hash moves. The proof is generated by a script that exists only in the folder of whoever wrote it. The root sits on a chain the team stopped funding, or on a testnet that was eventually shut down. The application that produced the log is decommissioned and takes with it the only component capable of demonstrating anything.

In all of those cases the data is still there. It is the verification path that is gone, and without it the anchor is a receipt you wrote yourself.

The verifier is a deliverable

The practical consequence, for anyone building these systems, is that the verifier is not an accessory to add if there is time left. It is part of the delivery: a frozen, versioned serialization format, exportable proofs, on-chain coordinates stored in the clear alongside the record, and a verification tool that runs outside your perimeter — ideally something an auditor can execute on their own.

The same logic applies upstream of the chain. Regimes that govern high-risk systems ask for records that stay usable over time, not merely written once. A record nobody can open any more satisfies the letter and misses the point.

So the design question was never what to anchor. It is who verifies, with what in their hands, and whether that path still works when your company is not in the room.

If an auditor asked today, could they verify a single entry without you?