Buffer Account

What it is

A Buffer account is scratch space for deploying or upgrading a program. ELF bytes are written into a buffer across many transactions (a program is far larger than one transaction can carry), and only once the full ELF is staged and verified does a single Deploy or Upgrade instruction copy it into the ProgramData account.

Why it exists

A Solana program’s ELF is often hundreds of kilobytes — it can’t fit in one transaction’s 1,232-byte limit. Buffers let you upload the code in chunks (Write instructions) into a staging account, then atomically promote it. It also enables governance flows: stage an upgrade in a buffer, then have a multisig or DAO authorize the final swap.

Byte layout

The account holds the Buffer variant of UpgradeableLoaderState (bincode), then the partial-or-complete ELF:

The header is 37 bytes (4 + 1 + 32) when an authority is set; the staged ELF follows.

Where you see it

During solana program deploy and solana program write-buffer. Buffers are transient — they exist between the first Write and the final Deploy/Upgrade, then are closed to reclaim rent. You’ll occasionally find abandoned buffers from failed deploys still holding rent.

Common gotchas

• ELF starts at offset 37 here, 45 in ProgramData. The two state variants have different header sizes (Buffer has no slot field). Don’t reuse the ProgramData offset to parse a Buffer.
• Abandoned buffers strand rent. A deploy that fails midway leaves a funded buffer. solana program close --buffers reclaims them; check for orphaned buffers if SOL goes missing during deploys.
• The buffer authority controls the deploy. Only the buffer’s authority can finalize a deploy/upgrade from it — relevant for multisig-gated upgrade flows where the buffer is staged by one party and promoted by another.
• Discriminator 1, not 3. Buffer is variant 1; ProgramData is 3. The 4-byte tag at offset 0 tells you which you’re looking at.