Protocol stewardship & longevity

Evidence has to outlive its era.

A proof issued today may be examined in a courtroom, an audit, or an archive decades from now. These are the three commitments that make that survivable: versioning, cryptographic migration, and stewardship.

1 · Versioning — old receipts never break

Every receipt carries its protocol version. Verifiers are required to validate each receipt under the rules of the version it was issued under — never retroactively under newer rules. Version changes are additive and published openly; a change that would invalidate previously issued receipts is, by policy, not a version change but a defect, and is handled through the public errata process (LPR-ERRATA-NNN) with its full history preserved.

2 · Post-quantum posture — stated before it's urgent

Two primitives matter, with two different horizons:

• SHA-256 (hashing, Merkle trees, anchoring): a quantum adversary (Grover) reduces its security margin but does not break it; the hash-based commitments that anchor the record remain robust on any realistic horizon.
• Ed25519 (signatures): a large-scale quantum computer (Shor) would break this class of signatures. Our mitigation is structural: signatures in LedgerProof establish who issued a receipt, while what existed when is established by hash commitments on the public ledger — which do not depend on signature security. The planned migration path is to a NIST-standardized post-quantum signature scheme (ML-DSA / FIPS 204) introduced as a new protocol version, with dual-signing during transition so history chains cleanly across the boundary.

We commit to publishing a concrete migration timeline when NIST-standard implementations are production-mature in our stack — and to never marketing "quantum-proof" claims in the meantime.

3 · Stewardship — the rules can't be enclosed

The protocol specification, conformance vectors, and verifier are stewarded by the LedgerProof Foundation (a California nonprofit; 501(c)(3) in process), legally separate from the commercial company. The company builds managed products on the protocol; it does not own the protocol. Practical consequences:

• The specification and verifier remain open (Apache-2.0) — anyone may implement, verify, or fork.
• Changes to verification rules go through the Foundation's public process, not a product roadmap.
• If the company ceases to exist, the Foundation's charter directs continuity of the specification and public verification tooling — see continuity & durability.

Alignment: the receipt/transparency architecture follows the IETF SCITT working group's direction and RFC 9162-style Merkle transparency. Standards participation is ongoing; claims of formal standardization will be made only when true. Questions: veronica@ledgerproofhq.io.