Recover SOL from failed program deploys and unused lookup tables

Deploying a program is not one transaction. The CLI first creates a buffer account owned by the BPF Upgradeable Loader, sized for the whole program binary, and funds it with the rent-exempt minimum for that size — about 0.00000508 SOL per byte, so a 300 KB program locks roughly 1.6 SOL and a 1 MB program about 5.3 SOL. It then writes the binary into the buffer in hundreds of small transactions, and only at the end copies the buffer into the program's data account and closes it.

If anything interrupts that sequence — dropped write transactions during congestion, an expired blockhash, a closed terminal, running out of SOL for the final step — the buffer stays on chain with its full deposit. Each retry that does not reuse the buffer creates another one. The CLI prints a seed phrase to resume with, which is easy to lose, and nothing in a wallet or on most explorers shows that these accounts exist. It is common for an active deployer key to have several SOL sitting in forgotten buffers.

A buffer account starts with a 4-byte type tag of 1, followed by an optional authority: one byte that says whether an authority is set and then its 32-byte public key. This tool searches the loader's accounts for exactly that 37-byte prefix with your address in it, which returns every buffer you control in a single RPC call. The size shown is derived from the account's balance, since a buffer holds exactly the rent-exempt minimum for its length.

Closing uses the loader's Close instruction with three accounts: the buffer, the recipient of the lamports, and the buffer authority as signer. The loader zeroes the account and moves its entire balance to the recipient, which here is always your connected wallet. Closing a buffer has no effect on any deployed program: a program runs from its program data account, not from a buffer. The only thing you lose is the ability to resume that specific interrupted deploy, so do not close a buffer for an upload you still intend to finish.

The Solana CLI can do the same thing for free: solana program show --buffers lists buffers for the configured keypair, and solana program close --buffers closes them all and returns the SOL. If you have the CLI installed and the deployer keypair file at hand, that is the cheapest route and we recommend it.

The closer is for the other cases: you deployed from a browser-based IDE or a wallet-adapter flow, you are on a machine without the toolchain, the authority is a hardware wallet, or you just want to check several team addresses quickly without touching key files. It can only close buffers whose authority is the wallet you connect. If you deployed with a CLI keypair, the read-only lookup still shows what is recoverable; to close from the browser you would import that key into a wallet, which you should weigh against simply running the CLI command.

Address lookup tables let versioned transactions reference accounts by a one-byte index instead of a 32-byte key. A table has 56 bytes of metadata plus 32 bytes per stored address, so a full table of 256 addresses holds about 0.043 SOL in rent and a small one about 0.001 SOL. Bots, aggregator integrations and test scripts often create tables by the dozen and never clean them up. The tool finds every table whose authority field, at byte offset 22, is your address.

Closing is a two-step process enforced by the program. Deactivate marks the table with the current slot; from that moment no new transaction can use it. The table can be closed only once that slot has aged out of the SlotHashes sysvar, which keeps the last 512 slots — roughly four minutes. The tool reads that sysvar to tell you whether a table is closable now or how long is left. Deactivation cannot be undone, so any program, bot or frontend still referencing the table will start failing at once. Tables whose authority has been removed are frozen and can never be closed.