Writing a Merkle root on-chain takes an afternoon. Building something a third party can actually verify takes design. Those are not the same project, and only the second one is worth anything.
A verification is a computation someone else repeats. Four things have to exist together for that to be possible:
- The entry — byte for byte as it was hashed. Re-reading it from the DB and reserializing with a newer model class moves the hash, and a moved hash is indistinguishable from tampering.
- The inclusion proof — the sibling path from leaf to root. Stored or regenerable by anyone holding the ledger, not just your internal CLI.
- The root — at a nameable block height. "It's on chain" is not a coordinate; block number + tx hash are.
- A reader that is not your API. If the auditor calls your server to check your claim, they're trusting you again through a different door.
How it gets lost, all boring:
- a refactor reserializes the entry
- the proof generator only exists on one laptop
- the chain is one nobody funds anymore, or a testnet that got shut down
- the app is decommissioned and takes the verifier with it
The data survives all four. The verification path doesn't — and without it the anchor is a receipt you wrote yourself.
Treat the verifier as a deliverable: frozen versioned serialization, exportable proofs, on-chain coordinates in the clear, and a verification tool that runs outside your perimeter.
Full version: https://www.omarbaruzzo.it/en/blog/la-prova-che-nessuno-verifica
