Museum · Entry #0 · The LedgerProof genesis entry
The chain catching its own bug.
On May 6, 2026 — twelve days before the LedgerProof v1.0 specification was finalized — the first receipt was anchored to the canonical chain. It was a small thing: a BTC trading-signal note from a developer-test publisher account, dated and signed and stamped to Bitcoin. It was Entry #0. And it had a bug.
The bug did not appear for almost a year. The verifier worked. The chain grew. Entries 1, 2, 3, and onward were issued, anchored, and verified correctly. The Frankfurt operator passed 99.5% availability, then 99.9%. The IETF draft was confirmed. The pilots began. The Foundation took shape.
And then on May 31, 2026, twelve months after Entry #0 was first written to the chain, the public verifier at verify.ledgerproofhq.io — the same verifier any regulator can paste a URL into — returned its first FAIL banner. On Entry #0. On the genesis receipt itself.
This page exists to explain what happened, what we did about it, and why we left the broken receipt on the chain.
What you would see if you clicked the verifier
Visiting verify.ledgerproofhq.io/#/0 displays an explanatory card pointing to LPR-ERRATA-001. Before the errata was published, the same URL displayed the raw verifier output:
Six checks pass. One fails. The chain integrity is intact in every way that matters cryptographically — the entry exists, the entry hash is correct, the publisher key was active, the Ed25519 signature is valid, the receipt was anchored, the Bitcoin transaction has tens of thousands of confirmations.
The content of the entry, as stored on the chain today, does not produce the content_hash that was committed to the chain on May 6, 2026.
What the entry contains
A trading signal. Conviction 0.92, BTC long. Dated. The note says "LedgerProof genesis entry — May 6 2026."
What was committed to the chain on May 6, twelve months ago, was a SHA-256 hash of some canonicalization of the content as it existed at that moment. The content as it exists today does not produce the same hash under any of the forty-some canonicalization variants tested.
The most likely explanation, documented in LPR-ERRATA-001, is that the content was edited after the hash was committed — a typo correction, a punctuation normalization, a whitespace adjustment — and the hash was not recomputed. The publisher pipeline at the time was being iteratively developed. The edit-after-hash anti-pattern was not yet guarded against.
Timeline
Entry #0 issued
The first receipt anchored to the LedgerProof canonical chain. Bitcoin block — verifiable via the entry's anchor receipt.
LPR v1.0 spec finalized
The publisher pipeline stabilized. Entries 1+ are issued under the v1.0 path and continue to verify correctly today.
Verifier surfaces the Content hash mismatch
While building the public-facing verifier UX, the LedgerProof team browser-tested the verification flow against /#/0 and discovered that Entry #0's Content hash check returns FAIL.
Root cause confirmed
Five-minute empirical investigation: ~40 canonicalization variants tested, none reproduce the stored hash. Entries 1, 2, 3, 4 all pass. The bug is contained to Entry #0.
LPR-ERRATA-001 published
The Foundation's first public errata. Verifier updated to render an explanatory card for Entry #0 (and any future pre-v1.0 entry flagged) instead of the raw FAIL banner.
Trail of Bits independent audit
3-day scoped engagement to validate v1.1+ canonicalization correctness and sign off on the LPR-ERRATA-001 narrative. Memo published at security.ledgerproofhq.io upon completion.
Founding-declaration receipt issued
A new canonical founding-declaration entry is issued via the v1.1 publisher path. The slug /r/founding-declaration resolves to it. Entry #0 remains untouched.
Why we did not erase Entry #0
The LedgerProof canonical chain is append-only. The hash chain (prev_hash → entry_hash) for entries 1 through N is rooted in Entry #0's entry_hash. Removing or modifying Entry #0 would invalidate every subsequent entry's prev_hash linkage and destroy the chain integrity that the protocol's value depends on.
More importantly: removing Entry #0 would defeat the property that makes the chain trustworthy. If we erased the broken receipt to make the verifier show all green, we would have built a system that does not catch its own bugs. We would have built a system where the operator can quietly fix history.
LedgerProof is the system where the operator cannot quietly fix history. The chain catches its own bug. Twelve months after issuance. Using its own public verifier. Surfacing the failure in an interface a regulator can paste a URL into and see for themselves.
That is the property. Entry #0 stays.
What this proves about every other receipt on the chain
If you are a regulator, a General Counsel, an auditor, or a critic reading this page: the existence of this errata is the strongest evidence we can offer that the protocol works as advertised.
The chain caught a bug, surfaced it in public, explained it transparently, and committed to a remediation path that does not erase history. The verifier you are reading about is the same verifier you can paste any other receipt URL into. The same six checks will run on every entry. If any future entry fails Content hash, you will see the same banner.
We will not hide it.
Read the full errata: LPR-ERRATA-001 → Verify Entry #0 yourself →