19. PQC Key Migration
19.1 The Problem
No on-chain mechanism can distinguish an attacker holding a stolen ECDSA key from the legitimate owner. Earlier commit-reveal designs suffered from symmetric griefing: both the attacker and the legitimate owner could cancel each other's commitments, resulting in a denial-of-service race.
19.2 Three-Mechanism Migration Model
The repository documents a migration design with three mechanisms. Availability and activation of each mechanism depend on the deployed account and migration implementation:
| Mechanism | Purpose | Trigger |
|---|---|---|
| 1. Direct registration + PoP | Normal case (99% of users) | User proactively registers PQC key |
| 2. Pending delay + alert | Anti-theft safeguard | Defined by the deployed migration path |
| 3. Social recovery M-of-N | Account already compromised | Guardians intervene during 48h window |
Mechanism 1 — Direct registration: The migration design binds a new post-quantum public key to the existing account through an ownership proof. The concrete signature profile must follow the implementation used by the deployed migration path; the current node's ordinary signing path uses ML-DSA-65.
Mechanism 2 — Pending delay: The documented design includes a delayed activation state and alert window. The exact duration, activation authority and event behavior are network/configuration parameters and must be verified from the deployed migration contract.
Mechanism 3 — Guardian recovery: The design includes guardian-assisted intervention for an unauthorized migration. Threshold, freeze semantics, guardian changes and recovery timing must be fixed and tested by the deployed account implementation.
Guardian set changes: The documented design proposes delayed guardian changes; the exact delay and authorization rules must be verified in the deployed implementation.