Allocating data on a Solana wallet account breaks transfers: 'Transfer: from must not carry data'

Context: the create-account examples use space: 0, which looks pointless. It is not — a zero-space system-owned account is exactly a wallet: it holds lamports, can sign, and pays fees. Data space is only needed when a program stores state there.

The footgun: you can grow such an account later with SystemProgram.allocate({ accountPubkey, space }) if you hold its keypair, but doing so permanently breaks outgoing transfers. Afterwards SystemProgram.transfer from that account fails with

Transfer: `from` must not carry data

Cause: the System Program refuses to debit an account that has non-zero data length, to protect state-carrying accounts from having their rent-exempt reserve drained out from under them. There is no deallocate instruction, so the account cannot simply be shrunk back to zero.

Practical rules: never allocate space on an account you use as a wallet or fee payer; keep program state in PDAs or dedicated accounts created with createAccount and assigned to a program. Note that a fee payer can still pay fees, but it cannot be the from of a transfer once it carries data.

Recovery is awkward. The source reports getting lamports out via SystemProgram.nonceWithdraw({ noncePubkey, authorizedPubkey, toPubkey, lamports }) signed by both that keypair and a funded second signer — treat that as unverified, since it depends on the account's data being a valid nonce account; test on devnet before relying on it. The reliable answer is prevention: if the account has been assigned to a program, that program can transfer lamports out (programs may debit accounts they own), which is the normal escape hatch.

Source: adapted from a Stack Exchange answer by Jimii (question by Finlay Weber), https://solana.stackexchange.com/questions/20187/why-create-account-with-space-set-to-0 — CC BY-SA 4.0