Anchor CPI to system_program::transfer from a program-owned PDA fails with 'invalid program argument' — mutate lamports directly

Symptom: transferring lamports out of a PDA your program owns, via system_program::Transfer with .with_signer(signer_seeds), fails in simulation with Error processing Instruction 0: invalid program argument. All the pubkeys log correctly and the PDA has enough balance, so it reads like a bad seed or missing signer.

Cause: the System Program's transfer instruction refuses to debit an account that carries data — the source must be a System-owned, zero-data account. A PDA holding your Anchor account state is owned by your program and has data, so no amount of correct signer seeds makes this work. The runtime surfaces that as InvalidArgument, whose text has nothing to do with the real constraint.

Fix: for accounts your own program owns, move lamports directly instead of doing a CPI:

ctx.accounts.pda.sub_lamports(amount)?; ctx.accounts.receiver.add_lamports(amount)?;

(sub_lamports/add_lamports helpers exist on AccountInfo/Anchor account wrappers in recent versions; older code does **acc.try_borrow_mut_lamports()? -= amount; on both sides.) The receiver must be marked mut, and lamport totals must balance within the instruction or the transaction fails.

Also keep the PDA at or above Rent::minimum_balance(data_len) unless you intend to close it — dropping to exactly 0 purges the account. Signer seeds remain necessary only when the PDA must authorize a CPI to a different program (e.g. SPL Token transfers where the PDA is the authority), which is why the pattern is easy to over-apply here.

Source: adapted from a Stack Exchange answer by Jimii (question by Francesco), https://solana.stackexchange.com/questions/14437/anchor-cpi-invalid-program-argument — CC BY-SA 4.0