Public ledger · Alpha Covenant Holdings LLC (PA 0016032097)
Every signing path, its algorithm and key; the receipt signature-set states; the plan against EO 14412 / OMB M-26-15. Facts with check URLs. Not a certification; "PQC-ready" is not a phrase we use.
Receipts registered: 3,594 · carrying the HYBRID set (ML-DSA-65 + Ed25519): 30 since 2026-10-25T03:18:28 · earlier, CLASSICAL_ONLY: 3,564 (still verifiable by hash, transparency log, SLH-DSA checkpoint and OpenTimestamps).
| Receipt signature set | where: receipt_registry.signature_set at registration (receiptspec.record → vc.sign_hash_set) signs: ASCII bytes of the receipt SHA-256 hex algorithms: ML-DSA-65 (FIPS 204, key-pq-1) + Ed25519 (FIPS 186-5, key-1) state: HYBRID since 2026-10-25; earlier receipts CLASSICAL_ONLY (no set) verify: GET /api/receipts/{rid}/signatures |
|---|---|
| Verifiable Credential export | where: GET /api/receipts/{rid}/vc (vc.py) signs: sha256(JCS(proof config)) ‖ sha256(JCS(credential)) algorithms: Ed25519 eddsa-jcs-2022 (signature of record) + ML-DSA-65 ml-dsa-65-jcs-2026 (parallel proof) state: HYBRID proof set since 2026 verify: POST /api/vc/verify or any Data Integrity verifier resolving did:web |
| Audit-log entries, corrections, decision-record countersignature | where: vc.sign_hash (attestations.py, audit log) signs: ASCII bytes of the entry's SHA-256 hex algorithms: Ed25519 (key-1) state: CLASSICAL_ONLY — next path to move to the HYBRID set verify: entry carries verificationMethod; key in /api/vc/did.json |
| Registry tree-head checkpoints and daily archive digest | where: pqarchive.py (key-slh-1), translog.py signs: Merkle tree head / daily digest algorithms: SLH-DSA-SHA2-192s (FIPS 205, hash-based) + OpenTimestamps (Bitcoin-anchored SHA-256 Merkle proof) state: post-quantum already; hash-based mathematics distinct from ML-DSA verify: /api/public-record/archive-hash, /api/log/proof/{rid} |
| Transport (TLS) to this site | where: hosting platform's edge; not operated by us signs: — algorithms: TLS 1.2/1.3 as the edge negotiates; key establishment is the edge's (classical ECDHE unless the edge offers a hybrid ML-KEM group) state: not under our control; stated, not claimed verify: openssl s_client -connect alphacovenantholdings.com:443 and read the negotiated group |
| Session tokens and partner API keys | where: auth.py, partnerapi.py signs: — (random bearer tokens compared by equality, not signed) algorithms: CSPRNG tokens; SHA-256 where a token is stored hashed state: no signature; unaffected by the signature transition verify: n/a |
| CLASSICAL_ONLY | Ed25519 only. Receipts registered before the signature set existed carry no set; their SHA-256, transparency-log inclusion, SLH-DSA archive checkpoint and OpenTimestamps anchor still verify. |
|---|---|
| HYBRID · now | Ed25519 + ML-DSA-65, both detached over the ASCII bytes of the receipt's SHA-256 hex. Verification of the set succeeds only if BOTH verify. A verifier that does not know ML-DSA may check the Ed25519 signature alone and must say so. |
| PQC_ONLY | ML-DSA-65 only; Ed25519 no longer issued. Target state — by policy no later than 2031-12-31 (the OMB M-26-15 digital-signature date for agencies' covered systems); earlier if a break in Ed25519 is published. |
| 0 · Inventory done 2026-10 | Enumerate every place a signature is created, stored or verified. Status: Done — the six paths above. No signing path exists outside this list. |
|---|---|
| 1 · Agility layer done 2026-10 | Algorithm, standard and key id named on every signature; verifiers read the algorithm field and say which they checked. Status: Done — receipt-signature-set/v1 carries algorithm/standard/public_key_id per signature; verify endpoint returns a result per algorithm. |
| 2–3 · Hybrid default done 2026-10-25 | Every new receipt carries ML-DSA-65 + Ed25519 over its hash; set verifies only if both verify. Status: Done for new receipts. Audit-log and countersignature paths still Ed25519-only: next. |
| 3b · External verification by 2027-06-30 | A party outside this platform verifies at least 1,000 hybrid sets from the public keys alone and publishes the result. Status: Not done. Anyone may do it today from /api/receipts/{rid}/signatures and /api/vc/did.json; we will publish the first such report we receive. |
| 4 · PQC signature of record by 2030-12-31 | ML-DSA-65 becomes the signature of record; Ed25519 retained as compatibility proof; FIPS-validated implementation replaces the reference one if available. Status: Planned. |
| 5 · PQC only no later than 2031-12-31 | Ed25519 no longer issued (state PQC_ONLY). Every historical receipt still verifies by its SHA-256, its stored classical signature under the retired key kept in the DID document, its SLH-DSA checkpoint and its OpenTimestamps anchor. Status: Planned; earlier if a break in Ed25519 is published. |
| Key establishment quantum-safe (FIPS 203 ML-KEM) 2030-12-31 | Authority: EO 14412 (June 2026); OMB M-26-15 Binds: Federal agencies' high-value and high-impact systems Our fact: Key establishment on this site is TLS at the hosting edge, which we do not operate. We state what the edge negotiates; we cannot change it. Everything evidentiary here is hash-and-signature based and does not depend on key establishment. |
|---|---|
| Digital signatures quantum-safe 2031-12-31 | Authority: EO 14412; OMB M-26-15 Binds: Federal agencies' high-value and high-impact systems Our fact: New receipts carry ML-DSA-65 today beside Ed25519 (HYBRID). Archive checkpoints carry SLH-DSA. Our own policy date for PQC_ONLY is no later than 2031-12-31. |
| FAR-covered contractors meet federal cryptographic standards end of 2030 (FAR Council rule directed; proposed rule due within 180 days of the order) | Authority: EO 14412 §(FAR directive) Binds: Contractors under covered FAR contracts, once the rule is final Our fact: We are not today a party to a FAR-covered contract. If we become one, the rule as finalised governs; this page is our inventory for that conversation, not a compliance claim. |
| Hash-based chain of custody | The SHA-256 hash and its daily chained digest are the anchor. The transition changes which signature sits beside the hash, not the record or its hash. |
|---|---|
| 'Not read' disclosure | A source that did not answer prints as did_not_answer. That rule has nothing to do with the signature algorithm. |
| Open specification | Receipt Format v1 is unchanged (CC BY 4.0). The signature set lives in the registry beside the hash; it is additive and not inside the hashed body. |
| Who decides | A signature attests that this platform registered this hash at this time. It attests nothing about the party, and nothing about any decision a reader makes. |
| Nothing re-signed | Receipts issued before the set existed are not re-signed, re-hashed or edited. Durability comes from keeping every key and every proof public. |
Keys: /api/vc/did.json · per-receipt check: /api/receipts/{rid}/signatures · JSON of this page: /api/public/cryptography · algorithms and AI use: /api/public-record/durability. Implementation note: ML-DSA-65 and SLH-DSA are produced with reference implementations that are not FIPS-validated; a validated module replaces them when one is available to us.