Post-Quantum Cryptographic Migration

01Executive Summary

JIL Sovereign introduces the first production-grade methodology for migrating a live blockchain network from classical cryptographic algorithms (Ed25519, X25519) to post-quantum algorithms (CRYSTALS-Dilithium, CRYSTALS-Kyber) using a three-phase epoch-based key rotation protocol that guarantees zero network downtime throughout the transition.

The migration protocol operates across configurable epoch windows (default 10,000 blocks per epoch), moving the entire network through three distinct phases: Hybrid Dual-Signing, PQ-Primary with Classical Fallback, and PQ-Only with Legacy Deprecation. A guardian notification system ensures that all key holders receive advance notice of at least one full epoch before any phase transition occurs.

02Problem Statement

Quantum computers capable of breaking Ed25519 and ECDSA signatures are projected to arrive within the next 10 to 15 years. When they do, any blockchain still relying solely on classical cryptography will be vulnerable to retrospective key extraction, signature forgery, and total fund theft. The threat model is not theoretical - it is a matter of timeline.

2.1 The Quantum Threat to Blockchain

• Shor's Algorithm breaks the discrete logarithm and integer factorization problems underlying Ed25519, ECDSA, and RSA in polynomial time on a sufficiently large quantum computer.
• Grover's Algorithm reduces the effective security of symmetric ciphers and hash functions by half - AES-256 becomes AES-128 equivalent.
• Harvest Now, Decrypt Later - adversaries are already capturing encrypted blockchain traffic for future decryption once quantum capability arrives.

2.2 Why Existing Approaches Fail

03Technical Architecture

The migration protocol divides the transition into three phases, each governed by epoch boundaries. An epoch is a configurable block window (default: 10,000 blocks at 1.5-second block times, approximately 4.2 hours per epoch). Phase transitions occur only at epoch boundaries and require guardian notification one full epoch in advance.

3.1 Three-Phase Migration Model

3.2 Epoch Boundary Mechanism

Every block header contains an epoch_number field derived from floor(block_height / epoch_size). The active phase is stored in the epoch registry contract and can only advance at the first block of a new epoch. This ensures that all validators process phase transitions deterministically at the same block height.

{
  "epoch_number": 42,
  "epoch_size": 10000,
  "current_phase": "HYBRID_DUAL_SIGN",
  "next_phase": "PQ_PRIMARY",
  "transition_block": 430000,
  "guardian_notified_at_block": 420000,
  "guardian_notification_epoch": 41
}

3.3 Guardian Notification System

The guardian notification system is a protocol-level broadcast mechanism that alerts all key holders at least one full epoch (10,000 blocks) before any phase transition. Notifications are embedded in block headers as structured events and propagated through the validator gossip layer, ensuring every participant - including offline wallets that sync later - receives the notification deterministically.

• Notification Event: Embedded in the first block of the epoch preceding a transition
• Content: Current phase, next phase, transition block height, required actions
• Delivery: Block header event, validator gossip, wallet push notification, explorer display
• Verification: Any node can independently verify the notification by reading the epoch registry

04Implementation

4.1 Dual-Signed Transaction Format

During Phase 1, every transaction carries two signatures in a structured envelope. The classical signature occupies the standard signature field for backward compatibility, while the post-quantum signature is appended in an extension field that legacy nodes can safely ignore during the transition period.

{
  "tx_type": "PaymentTx",
  "from": "jil1abc...def",
  "to": "jil1xyz...789",
  "amount": "1000000",
  "nonce": 42,
  "classical_sig": {
    "algorithm": "Ed25519",
    "public_key": "base64url(32 bytes)",
    "signature": "base64url(64 bytes)"
  },
  "pq_sig": {
    "algorithm": "ML-DSA-65 (Dilithium3)",
    "public_key": "base64url(1952 bytes)",
    "signature": "base64url(3293 bytes)"
  },
  "epoch": 42,
  "phase": "HYBRID_DUAL_SIGN"
}

4.2 Epoch Registry API

4.3 Key Rotation Workflow

1. Generate PQ Keypair: User's device generates a CRYSTALS-Dilithium keypair locally using a CSPRNG seeded by the device's secure enclave.
2. Sign Rotation Request: A key rotation transaction is signed with the existing Ed25519 key, binding the new Dilithium public key to the account.
3. On-Chain Registration: The rotation transaction is validated by consensus and the PQ public key is stored alongside the classical key in the account registry.
4. Dual-Signing Enabled: From the next block onward, the account can produce dual-signed transactions meeting Phase 1 requirements.
5. Guardian Confirmation: The guardian notification system confirms the successful key rotation to all network participants.

05Integration with JIL Ecosystem

5.1 Validator Consensus

All 20 validators participate in the epoch-based migration. During Phase 1, validators produce blocks with dual signatures. The 14-of-20 BFT threshold applies to both signature types - a block is valid only if at least 14 validators provide valid signatures under both algorithms.

5.2 Bridge Signatures

The 14-of-20 multi-signature bridge transitions in lockstep with the main chain. Bridge attestations carry dual signatures during Phase 1, ensuring that cross-chain messages remain verifiable under both classical and post-quantum assumptions throughout the migration.

5.3 MPC Signing

The MPC 2-of-3 threshold signing protocol (GG20) is extended with a PQ-compatible threshold scheme. During Phase 1, each signing ceremony produces both an Ed25519 threshold signature and a Dilithium threshold signature. The user's shard (Shard A) is upgraded to contain both classical and PQ key material.

5.4 Wallet Keys

The web wallet and mobile SDK expose a key migration interface that guides users through generating their PQ keypair. Wallets that have not migrated by Phase 3 cannot submit new transactions but can still receive funds. A grace period of 5 epochs after Phase 3 activation allows late migrators to complete their key rotation using a special migration-only transaction type.

06Prior Art Differentiation

07Implementation Roadmap

08Patent Claim