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
Top comments (1)
"a reader that is not your API" is the point people skip. we check player actions from chain data and learned the same thing, if the only way to verify a claim is our own endpoint we havent really proven anything. anyone with a block explorer should land on the same answer