Post-quantum migration

As of 2026-09-12, hybrid signatures and key exchange are distinct from the research effort covering commitments, proofs and settlement state. Bounded proof and state-transition paths have run on fresh networks; operational notes and the complete venue path are not yet post-quantum. Existing ledgers and deployments are preserved; in-place ledger migration is outside the current scope.

Proof and fresh-network implementation record · PQC note implementation boundary · 2026-09-12

Prove the private computation instead of adding commitments

The PQC note direction commits private quantities and randomness with SHA-512, then proves the opening relations and settlement arithmetic. The hash is not additively homomorphic. In simplified notation, C0 = H(v0 || r0), C1 = H(v1 || r1) and C2 = H(v2 || r2) are proved together with v0 = v1 + v2 and quantity bounds. The actual format also binds domains, deployment policy, assets and ownership.

DeFMI is intended to verify public commitments and a proof tied to canonical inputs, spending authority, unused nullifiers and outputs before updating state. Sending an opening to a server for a hash comparison is not a private proof. Adding a hybrid signature does not make Pedersen binding or a note proof post-quantum.

Executed research and the incomplete operational path

• Executed: collaborative proofs using hashes, codes and sumcheck. Seven owner-local inputs proved a bounded four-account arithmetic relation, checked by a separate public-data-only verifier. The sealed-input experiment recorded 740 canonical Block/State transitions including fill, no-fill and recovery. A separate fresh-network experiment observed acceptance and matching state after restart on five validators on one host.
• In progress: a new PQC note format, a recipient-only spending key, hybrid-encrypted delivery and wallet-local recovery. The complete private note relation, especially correct output encryption, anonymous membership and spend, and the operational reservation/fill/refund path remain incomplete.
• Verdict: the executed research is smoke_only. Independent custody, the full path from real QOMM/OCLOB inputs, and external validation of the exact construction's zero knowledge, quantum soundness and concrete security parameters remain open.

Sealed-input execution receipt · Fresh-network execution receipt

Historical hybrid rollout: 2026-09-06–2026-09-08

The foundation: zkfmi-crypto

One crate that every other repository depends on by pinned git revision. It defines the vocabulary and the compositions; it does not replace the services' own key stores or DeKYX's issuer epochs, it gives them a common shape.

• Suite identifiers, closed and versioned: the classical suites in use (Ed25519, FROST over ristretto255, Pedersen and Bulletproofs over ristretto255, X25519 in TLS 1.3, SHA-256/512, SHAKE128), the post-quantum ones (ML-KEM-768, ML-DSA-65, ML-DSA-44, SLH-DSA-SHA2-128s) and the hybrids (X25519MLKEM768, Ed25519+ML-DSA-65). Each carries its purpose and its byte sizes, checked against the FIPS 203/204/205 constants in tests. Unknown suites and versions are refused, never defaulted.
• Canonical signing input: protocol, version, network, deployment, contract, transaction kind, object identifiers, sequence or nonce, expiry, suite and body hash, length-prefixed with fixed-width integers under the domain ZKFMI:CANONICAL:v1. Golden byte vectors are fixed in hex. The same body under a different purpose yields a different preimage, so a signature cannot be moved between uses.
• Purpose-bound keys: a key record names its participant, purpose (quote, settlement instruction, key rotation, governance, transport, attestation), suite, generation, validity window, revocation and rotation proof. Rotation is signed both ways: the old key signs the new, the new signs the old key's identifier.
• Hybrid signature: Ed25519 and ML-DSA-65 over the same canonical input. Verification accepts only when both verify; one failing, one missing or the two swapped is a rejection. The ML-DSA context string carries the purpose and suite.
• Hybrid key exchange: X25519 and ML-KEM-768 with independently generated secrets combined through HKDF-SHA256 over both shared secrets, both ciphertexts and the suite identifier. Substituting either half changes the derived key, which is tested.
• Backends: RustCrypto ml-dsa 0.1.1 and ml-kem 0.3.2 (pure Rust, Apache-2.0 OR MIT) behind byte-oriented traits so that a FIPS-validated backend such as aws-lc-rs could be substituted later; ed25519-dalek 2.2 and x25519-dalek 2.0 on the classical side. #![forbid(unsafe_code)], secrets zeroized. The choice is an engineering choice, not a production, audit or FIPS claim.

What the bytes cost

Three ML-DSA-65 signatures for a 3-of-7 approval are 9,927 B. Against the settlement package sizes measured on the classical stack (57,971 B in the account-rail runs, 3,424 B with Bulletproofs at 64-bit rails), the extra signatures are not the dominant term, but the plan's provisional 16 KB target and 32 KB ceiling were written against a package definition that already exceeds them; they are to be re-set after the definition is fixed. On the policy-update path, ML-DSA-65 is about 15× the bytes of Ed25519, under three megabytes a second at the rates a real market maker uses. Timing is measured in the next section.

What the time costs

Measured on 2026-09-07 on one x86-64 core of the build host, through the same signer, verifier and KEM traits the stack uses, 300 samples per operation after warm-up, 256-byte message. The bench is examples/pqc_bench.rs in zkfmi-crypto; the prediction written before the run, the run receipt and the review of where the prediction missed are in docs/PQC_PERFORMANCE_2026-09-07.md. Medians; one run.

A hybrid signature takes 0.36 ms to make and 0.17 ms to check on one core. A settlement end to end is measured in tens of milliseconds to seconds, so the primitives alone do not show in latency; what the whole path adds is measured in the next section. On the wire the migration shows in bytes: each signed object grows by 3,309 B per signature and 1,952 B per embedded public key. Single-core verification throughput falls from about 26,000 to about 5,800 per second. Encapsulation and decapsulation, which are on the path of every recipient envelope, less than double. ML-DSA-65 signing has a long tail: p90 is 951 µs against the 340 µs median, from the rejection sampling the standard specifies. Every hybrid row is the sum of its two components to within 5 µs. The sizes the bench produced matched the table above in every row.

What the time costs end to end

Measured on 2026-09-08 on an idle 64-core host with the two images that have served the public OCLOB demo: the classical image deployed until 2026-09-07 (MP-SPDZ default TLS with RSA-2048 certificates, Ed25519 application signatures) and the hybrid image deployed since. 20 rounds per image after 2 warm-up rounds, alternating images every round; a round is a maker sell that rests, then a taker buy that fills it. Prediction, run and review are in docs/PQC_E2E_LATENCY_2026-09-08.md in zkfmi-crypto. One run.

Where the time goes. Every order spawns the 7 MP-SPDZ parties afresh, and each party opens 12 mutually authenticated TLS connections, so one round performs 42 handshakes. One mutual handshake, measured with the same OpenSSL 3.5.5 over the loopback: 1.07 ms with the RSA-2048 certificates the classical image used, 0.56 ms with Ed25519 certificates, 2.19 ms with ML-DSA-65 certificates and X25519MLKEM768. ML-DSA-65 signing at 0.69 ms per signature in OpenSSL 3.5.5 is the largest term, about +13 ms per round. The hybrid image also re-reads and hashes the 45 MB of engine binaries against the .pqc-tls.sha256 receipt on every round, about 35 ms; the migration added that check, and it runs before the MPC timer starts. The hybrid application signatures (1 plan, 7 party receipts, 1 node receipt, 5 transition attestations, a 3-node quorum) add an estimated 10 to 20 ms. The remaining 30 to 40 ms is the non-cryptographic difference between the two builds and was not separated.

Against the plan: throughput on this path is 95.5% and 95.9% of the classical rate, inside the 95% target by half a point; the added latency is 16 ms and 76 ms at p95 against a 5 ms target, so that target is not met as deployed. The prediction written before the run expected a difference between −10 and +5 ms and was wrong on two counts: it had the engine receipt check running once at start-up, and it had ML-DSA-65 signing faster than RSA-2048 signing, which in OpenSSL 3.5.5 it is not (0.69 ms against 0.27 ms). Both fixes were then made the same day: the engine artifacts are hashed once per process and re-checked by file identity per round, and the demo runner keeps its 7 parties alive between rounds, feeding each round through named pipes (the seven-process cluster of the native acceptance still spawns per round). The second run in the table shows the result: the hybrid image is now faster than the classical one by 177 ms and 202 ms per order, so both plan targets are met against the deployed classical stack; a classical image with the same runner would still be an estimated 10 to 20 ms faster, from the hybrid application signatures. The prediction written before that run expected a larger fall (at least 300 ms per leg, measured 250 and 276): the parties' start-up, connection setup and receipt hash were about 250 ms of the round, and the remaining 500 ms is the circuit's own preprocessing and online phases, which MP-SPDZ generates per round inside the loop.

The plan, and where each phase stands

What the native acceptance ran

One frozen source snapshot of all eight repositories (1,119 files, hash-identical before and after the run) built into pinned images on one Linux host, then: seven MP-SPDZ processes over the hybrid TLS adapter, the DeFMI L1, and the OCLOB maker and taker APIs. Four scenarios passed in sequence, 15 minutes in total.

• market: three rounds, two autonomous settlements, four post-quantum response signatures, eight one-time keys, recovery after a lost response, zero duplicate settlements.
• finality: a signed private-state receipt returns byte-identical on retry in the same process, after reopen and from another process; double application refused; seven-node canonical observation; substitution refused; wallet reopen; three claims; two confidential facility witnesses recovered and spent into the next order.
• lifecycle: three fills, twelve new post-quantum keys, six response signatures, an ordered cancel after partial fills with exact replay and restart, expiry release, a seven-node restart checkpoint.
• P6 recovery: two recovery tests under freshly resolved immutable dependencies.

Two defects were found by this run and fixed before it passed: a receipt whose ML-DSA signature was regenerated on every retry (the signed receipt is now persisted and replayed), and a refund opening re-authorised under a new operation identifier after a partial fill (the original claim context is now kept). Supporting gates: 125 OCLOB tests, 279 tests across the zkPI, DeKYX, DeCCP and P5 workspaces, QOMM transport and demo tests, Aethel end-to-end, all with strict clippy.

Boundary between the existing classical path and new PQC research

The existing Pedersen, Bulletproofs, Triptych and FROST path depends on discrete logarithms; the new Ristretto confidential-asset path also refuses PQC On. The research path uses SHA-512 and code-based proofs, with BN254 only as an arithmetic field. It does not use curve commitments, a pairing-based final proof or committee signatures as a substitute for proof soundness. This does not establish post-quantum security of the exact implemented composition.

Evidence limits

• Single host, one administrator. No independent operators, no WAN, no physical HSM.
• No FIPS validation of the backends and no external audit.
• The performance comparison is one run on one idle host with the two deployed OCLOB images over the loopback. The plan's throughput target (≥95% of baseline) is met by half a point; its latency target (a p95 overhead of 5 ms) is not: +16 ms on a resting order and +76 ms on a filled order at p95. The seven-process network fault tests are not seven-node WAN evidence.
• The P5 prover depends on an upstream alpha (Miden 0.32) and proves a deliberately narrow statement.