'Cross-program invocation with unauthorized signer' sending SOL from a PDA — mutate lamports instead of System transfer

Symptom: an Anchor instruction tries to move SOL out of a PDA that stores program state, using invoke_signed with the System program's transfer and the PDA's seeds, and fails with Cross-program invocation with unauthorized signer or writable account. The seeds and bump look right, and the same pattern works when the sender is a plain wallet.

Cause: the System program's transfer instruction requires the source account to be **owned by the System program**. A PDA that holds your #[account] state is owned by your program, so the System program refuses to debit it — the CPI's signer privileges are irrelevant. The error names signers, which sends people re-deriving seeds and bumps for hours; that is the wrong lead.

Fix: because your program owns the account, it can mutate its lamports directly, no CPI needed:

**ctx.accounts.sender.to_account_info().try_borrow_mut_lamports()? -= AMOUNT;
**ctx.accounts.receiver.to_account_info().try_borrow_mut_lamports()? += AMOUNT;

Both accounts must be mut. Lamports must balance exactly across the instruction or the runtime rejects the transaction. Do not drop a data-bearing account below its rent-exempt minimum unless you intend to close it, and prefer Anchor's close = recipient constraint when you do.

The rule to remember, in both directions: CPI to the System program works when the PDA is a system-owned, dataless "vault" (created but never assigned to your program) and your program signs with its seeds; direct lamport arithmetic is the route when your program owns the account. Depositing *into* a program-owned PDA is always fine via a normal System transfer, since only the debit side is restricted.

Source: adapted from a Stack Exchange answer by Jonas H. (question by Gregz), https://solana.stackexchange.com/questions/9628/anchor-program-unable-to-sign-a-transfer-with-a-pda — CC BY-SA 4.0