Start With the Problem
Suppose you have a 600-paragraph novel. You want to prove that paragraph 312 — "The deal was always about to close; it simply never did" — has not been altered since the book was written. You also don't want to give the verifier the entire manuscript, because the book is under copyright and you haven't published it yet.
The naive solution: hash the entire manuscript and put the hash on a blockchain. Cheap, simple. Problem: if the verifier wants to check paragraph 312, they need the entire manuscript to recompute the hash. The manuscript is not public. Stalemate.
The Merkle tree solution: hash each paragraph individually, then build a tree from those hashes, and put only the root of the tree on-chain. To verify paragraph 312, the verifier only needs the hash of that paragraph and a small number of neighboring hashes — enough to reconstruct the path from paragraph 312 to the root. The rest of the manuscript stays private. The math still works.
Building the Tree: One Level at a Time
Let's simplify to four paragraphs — P1, P2, P3, P4 — and work through the tree construction.
Level 0 — Leaf hashes: Each paragraph is hashed with SHA-256, producing four fixed-length outputs: h(P1), h(P2), h(P3), h(P4). These are the leaves.
Level 1 — Pair hashes: Adjacent leaves are concatenated and re-hashed: h(h(P1) + h(P2)) produces h12, and h(h(P3) + h(P4)) produces h34. These are the branches.
Level 2 — Root: The two branch hashes are concatenated and hashed: h(h12 + h34) produces the Merkle root. This single value represents all four paragraphs.
The Proof Path
Now suppose a verifier wants to check whether P3 has been altered. They have P3. They want to verify that h(P3) is still a leaf in the tree whose root is on-chain.
The proof they need: (1) the hash of P4, their neighbor at the leaf level; (2) h12, the branch on the other side. With those two values and their own computation of h(P3), they can reconstruct the root:
Compute h(P3). Concatenate with h(P4) to get h34. Concatenate h12 with h34 and hash again. If the result matches the on-chain root, P3 is intact. If P3 was changed — even one character — h(P3) changes, h34 changes, and the root doesn't match.
The verifier learns nothing about P1 or P2 — they only see h12, which reveals no content. The proof is compact: logarithmic in the number of leaves. For a 600-paragraph novel, proving any single paragraph requires only about 10 hash values, not 599 paragraphs of content.
Why This Is the Correct Structure for Literature
A hash of the entire manuscript treats the book as atomic — unchanged or entirely changed. A Merkle tree treats it at paragraph granularity, which is the natural editing unit. This matters for two reasons:
Incremental verification: If a later edition corrects a typo in paragraph 47, you can re-anchor paragraph 47, update the affected branch, and produce a new root while demonstrating that paragraphs 1–46 and 48–600 are unchanged. The tree preserves the editing history without collapsing the entire provenance record.
Selective disclosure: The manuscript can be partially released — a preview, an excerpt — with proofs that the excerpted paragraphs belong to a specific anchored version. The undisclosed paragraphs remain provably committed without being revealed.
The LPS-1 Implementation
The 2,500 Donkeys uses this structure. Every paragraph is hashed with SHA-256. The leaf hashes are assembled into a binary Merkle tree. The Merkle root is submitted to the LPS-1 smart contract on Polygon Mainnet. The smart contract records the root, the submitting address, and the block timestamp.
The LPS-1 verifier then implements 293 checks across the full paragraph set. These checks confirm: that every leaf hash is correctly computed from its paragraph content; that the tree structure is correctly assembled; that the on-chain root matches the locally computed root; and that the on-chain timestamp precedes the publication date.
All 293 tests pass on the current anchored version of The 2,500 Donkeys. The test suite is MIT-licensed on GitHub. You can clone it, run it, and verify the result independently, without any API call to a proprietary service, without any trust in XXXIII Publishing, and without reading the full manuscript.
What Satoshi Did With It
Bitcoin uses Merkle trees to organize transactions within each block. A block contains hundreds of transactions. The block header contains only the Merkle root of those transactions. Any light client — a phone wallet, a browser extension — can verify that a specific transaction is included in a specific block by requesting only the small proof path, not the full block of data.
This is called an SPV proof — Simplified Payment Verification. It's what makes it possible to verify Bitcoin transactions on a low-power device without downloading the 600GB blockchain. The Merkle tree makes the verification efficient by making it partial: you don't need the whole thing to check any part of it.
The same efficiency applies to literary verification. The whole manuscript doesn't need to be public to prove that any part of it is authentic. The tree structure carries that proof efficiently, permanently, without trust.
The deal chain never produced a receipt. Every document was a promise, not a proof. The Merkle root is a receipt. It proves what was committed, when, and by whom — without revealing what the commitment contains.