Executive Summary
Cross-cell value release in JIL's federation is always authorized by a classical Ed25519 signature from the federation hub over a canonical release-authorization message. A destination cell may additionally pin the hub's full ML-DSA-65 (FIPS 204) post-quantum public key - a 1952-byte value that does not fit the ledger's existing 32-byte storage word - by decomposing it deterministically across exactly 61 individual 32-byte storage slots (1952 divides evenly by 32), so the oversized key is represented entirely within the ledger's existing storage Merkle without any schema change.
Once a cell has pinned this key, every release destined for that cell must carry a valid ML-DSA-65 signature over the identical canonical authorization message, verified deterministically in-consensus by every validator, in addition to the classical Ed25519 signature - fail-closed, meaning a pinned-but-missing-or-invalid post-quantum signature is rejected even where the classical signature alone would otherwise be considered valid.
Problem Statement
Migrating a live, multi-party settlement system to post-quantum cryptography faces two concrete engineering obstacles beyond the cryptography itself: post-quantum public keys are dramatically larger than classical ones and often do not fit a chain's existing fixed-width storage primitives without a schema migration, and a network of independently operated cells cannot realistically coordinate a synchronized, all-at-once cutover without risking downtime or excluding cells that are not yet ready.
Why a Naive Approach Fails
- Key-size mismatch: A 1952-byte ML-DSA-65 public key does not fit a typical 32-byte storage word; storing it requires either a schema change or a decomposition scheme.
- Forced synchronization: Requiring every cell to adopt post-quantum verification simultaneously creates a hard coordination dependency across independently operated infrastructure.
- All-or-nothing security: A design that either fully requires or fully ignores post-quantum signatures gives no way for security-conscious cells to adopt protection ahead of the rest of the federation.
Technical Architecture
61-Slot Key Decomposition
| Element | Value |
|---|---|
| ML-DSA-65 public key length | 1952 bytes (FIPS 204) |
| Existing storage word width | 32 bytes |
| Slots required | 61 (1952 ÷ 32, exact division, no padding) |
| Pin points | Genesis, or a post-genesis corridor-configuration transaction |
Each of the 61 slots is addressed deterministically by index, so reading the full key back is a simple, deterministic reconstruction rather than a variable-length lookup - keeping the read path as deterministic as every other in-consensus state read.
Fail-Closed, Per-Cell-Opt-In Verification Gate
- The hub always signs the canonical release-authorization message with its classical Ed25519 key; classical verification against the pinned hub key is unconditional.
- If, and only if, the destination cell has a pinned ML-DSA-65 key, the release execution path additionally requires a valid ML-DSA-65 signature over the identical canonical message.
- A cell with a pinned key that receives a release lacking a post-quantum signature is rejected outright - the check is fail-closed, not best-effort.
- A cell that has not pinned a key continues to accept Ed25519-only releases without modification, so federation-wide interoperability is preserved during a staggered rollout.
The hub itself already produces both signatures on every release authorization it issues, so the hybrid path is exercised end-to-end in the settlement flow that assembles a release authorization, not merely specified as a future capability.
Prior Art Differentiation
Most post-quantum migration proposals for blockchain systems describe either a hard-fork flag day (all validators upgrade simultaneously) or an off-chain/best-effort attestation that does not affect consensus-level acceptance. JIL Sovereign's design is distinguished by (1) solving the key-size/storage-layout mismatch with a deterministic slot-decomposition scheme rather than a schema migration, and (2) making hybrid verification an in-consensus, fail-closed, per-destination-cell opt-in - each cell independently controls when it starts requiring the additional signature, without requiring the rest of the federation to change in lockstep.