LedgerProof Foundation · First public errata · June 1, 2026
LPR-ERRATA-001 — Entry #0 Content-Hash Stored-Value Mismatch
What this errata documents
The LedgerProof entry at canonical sequence 0 ("the genesis entry") stores a content_hash field whose value does not match any reproducible canonicalization of the content field as stored on the canonical chain.
When the public verifier at verify.ledgerproofhq.io is asked to verify Entry #0, the Content hash check returns FAIL with the message "Content hash mismatch — content may have been tampered." All other checks (Entry hash, Publisher key, Ed25519 signature, Receipt, Bitcoin anchor confirmation) return PASS.
This errata explains why, confirms the scope is limited to Entry #0 alone, and documents the remediation.
Scope confirmation
Verification testing against the live LedgerProof Canonical API at api.ledgerproofhq.io/v1/entries/{seq} for sequences 0 through 4, applying the verifier's content-hash logic exactly as published:
| Sequence | Stored content_hash (first 16) | Verifier-computed | Result |
|---|---|---|---|
| 0 | 051d95c233eeff21 | a655a3d8a814a415 | FAIL |
| 1 | eec835d8fcbef092 | eec835d8fcbef092 | PASS |
| 2 | c1c477d4bb1203b6 | c1c477d4bb1203b6 | PASS |
| 3 | 4fcc413019011cb4 | 4fcc413019011cb4 | PASS |
| 4 | d4a6d7b0dca93ba9 | d4a6d7b0dca93ba9 | PASS |
The verifier code is operating correctly. The Rust publisher canonicalization is operating correctly. Entry #0 is the only entry on the chain that exhibits this mismatch.
Root cause (most likely)
Entry #0 was issued during the pre-v1.0 publisher draft period (May 6, 2026 — twelve days before the v1.0 spec was finalized on May 18). During that period, the publisher pipeline was being iteratively developed. The most consistent explanation for the observed mismatch is that the content field of Entry #0 was edited (a typo correction, an em-dash normalization, or a whitespace adjustment) after content_hash was computed and committed to the canonical chain, and the hash was not recomputed.
Approximately 40 reasonable canonicalization variants were tested against the stored content (JCS RFC 8785, V8 JSON.stringify, CBOR, MessagePack, sorted-keys, Unicode normalization NFC/NFD/NFKD, em-dash substitutions, field-add/remove permutations, alternate hash algorithms, HMAC-with-publisher-key, double-SHA-256). None reproduced the stored content_hash value.
In all considered explanations, the failure is operational and historical — confined to the single entry, not arising from a flaw in any version of the published LedgerProof Protocol.
Why Entry #0 is being enshrined, not erased
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.
Enshrining Entry #0 — leaving it permanently on the chain, FAIL banner and all — is the correct behavior for an append-only, tamper-evident ledger. A regulator, auditor, or critic who clicks verify.ledgerproofhq.io/#/0 will see exactly what they should see: a receipt that fails its own integrity check because the integrity check works.
Remediation
A canonical "founding declaration" receipt will be re-issued as a new entry on the working v1.1 publisher path. Its canonical sequence number is assigned at issuance time and recorded in this section once anchored. The slug router renders the warm errata card at verify.ledgerproofhq.io/#/0 until the replacement is anchored; once issued, the slug /r/founding-declaration resolves to the replacement entry directly.
Entry #0 remains on the chain, unmodified. The replacement does not override; it stands alongside.
CI test added in response
ledgerproof-platform now contains a CI test that hashes a 100-entry corpus drawn from the live API in both the Rust publisher canonicalization library and the TypeScript verifier canonicalization library, and fails the build on any bytewise hash drift between them. This is preventive, not corrective — no drift exists today.
Public commitments arising from this errata
The LedgerProof Foundation commits to:
- Append-only chain integrity. Entry #0 will not be removed, modified, or excluded from canonical chain enumeration.
- Public errata register. This and all future errata are published at spec.ledgerproofhq.io/errata/ indefinitely. Each errata is anchored as a receipt.
- Cross-language canonicalization conformance in CI. No SDK or verifier release that fails the cross-language hash conformance test will ship.
- Pre-v1.0 reference receipts segregated. Receipts issued during the pre-v1.0 publisher draft period are flagged in the canonical registry with a
pre_v1marker for downstream tooling.
This errata is the Foundation's first public commitment to operating an open protocol in public.
The bug was found by the system itself, surfaced transparently, and explained completely. Subsequent errata, when they arise, will be handled identically.
Founder, LedgerProof Foundation · June 1, 2026