Executive Summary
JIL Sovereign's post-quantum transition service manages network-wide cryptographic migration through an explicit six-state phase machine - planning, classical-only, hybrid rollout, hybrid mandatory, post-quantum preferred, and post-quantum only - that operationalizes a three-stage migration doctrine (classical-only, hybrid transition, post-quantum-only) as a set of concrete, enforced states rather than a calendar target alone.
Advancement from one phase to the next is gated on an objective, measured migration percentage - the tracked share of wallets or keys that have actually completed migration - rather than on elapsed time; a phase advance is refused outright if the threshold for the next phase has not been met, regardless of how much calendar time has passed. Running in parallel, an independent per-algorithm deprecation schedule advances a legacy algorithm through its own five-state lifecycle strictly on calendar dates. Because classical and hybrid/post-quantum signers remain simultaneously valid throughout the multi-month transition, the network never requires a coordinated halt to change its cryptographic posture.
Problem Statement
Migrating a live financial network's cryptography is often modeled as a single flag-day cutover: pick a date, and after that date the network only accepts the new scheme. That approach forces a hard choice between two bad outcomes - cut over on schedule even if migration is incomplete (locking out not-yet-migrated participants, or worse, halting the network), or delay the cutover indefinitely while migration drags (leaving the legacy scheme live long past its intended retirement).
Why a Calendar-Only Cutover Is the Wrong Gate
- Calendar time doesn't track reality: A date-based cutover has no relationship to how much of the network has actually migrated by that date.
- All-or-nothing risk: A single global cutover means the entire network's liveness depends on migration having actually completed by a fixed moment.
- No graceful partial state: Without an enforced intermediate hybrid phase, there is no controlled window in which both schemes are simultaneously valid while adoption catches up.
Technical Architecture
Six-State, Percentage-Gated Phase Machine
| Phase | Migration % Required to Enter | Migration Doctrine Stage |
|---|---|---|
| Planning | N/A (starting state) | Classical-only |
| Classical Only | N/A | Classical-only |
| Hybrid Rollout | 25% | Hybrid transition |
| Hybrid Mandatory | 50% | Hybrid transition |
| Post-Quantum Preferred | 75% | Post-quantum only |
| Post-Quantum Only | 95% | Post-quantum only |
An advance request that targets the next phase is refused with an explicit error, naming the current migration percentage and the threshold still required, whenever the tracked migration percentage has not yet reached that phase's threshold - the phase machine cannot be pushed ahead of measured reality.
Independent Per-Algorithm Deprecation Schedule
Separately from the migration-percentage-gated phase machine, each legacy signing algorithm carries its own five-state deprecation lifecycle - announced, warning, soft-deprecated, hard-deprecated, removed - which advances strictly on calendar dates configured per algorithm, independent of the overall network migration percentage. This lets an operator set and communicate hard retirement dates for a legacy algorithm while the network-wide phase gate remains governed by actual migration progress.
Per-Wallet Migration Sub-State Machine
Individual wallets or keys progress through their own lifecycle - not started, notified, key generated, testing, migrated, verified - with an explicit rolled-back state as an escape hatch. Supported target algorithms include two hybrid modes pairing a classical algorithm with a post-quantum one, and a dedicated compliance check confirms a wallet can actually operate in dual-signature mode before it is counted as migration-complete.
Full Auditability
Every phase change, deprecation-schedule transition, wallet migration, and compliance check is journaled as a typed event, giving a complete, replayable record of how and when the network's cryptographic posture changed and why each transition was permitted.
Prior Art Differentiation
Conventional cryptographic-agility proposals for blockchain networks typically describe a target end-state (e.g. "the network will support post-quantum signatures") and a rough timeline, without an enforced, measured gate tying phase advancement to actual adoption. TLS-style cipher-suite deprecation in web infrastructure is calendar-driven and does not need to solve for a single shared consensus state the way a blockchain network's signature scheme does. JIL Sovereign's design is distinguished by combining a strictly migration-percentage-gated phase machine (not calendar-gated) for the network-wide posture with an independently calendar-gated per-algorithm deprecation schedule, plus a per-wallet sub-state machine with an explicit rollback path - three coordinated but independently governed state machines rather than one flag-day switch.