What is a Solana address lookup table? How to close one

The short answer

An address lookup table (ALT) is a Solana account that stores up to 256 addresses so that version 0 transactions can reference each one with a 1-byte index instead of a full 32-byte key. Every table holds rent for 56 bytes plus 32 bytes per address: 0.00093472 SOL empty, 0.04255008 SOL full at today's rate. Only the table's authority can get that SOL back, in two steps: deactivate the table, wait until its deactivation slot leaves the 512-entry SlotHashes list (about 3.5 to 4 minutes), then close it.

What is an address lookup table?

An address lookup table is an on-chain account, owned by the Address Lookup Table program AddressLookupTab1e1111111111111111111111111, that holds a list of public keys. It exists to work around Solana's 1,232-byte transaction size limit. In a legacy transaction every account is written out as 32 bytes, so a swap route through several pools runs out of room fast (the "Transaction too large" error in why Solana transactions fail). A v0 transaction can instead name a lookup table and list indexes into it, one byte per account. The Solana guide to lookup tables describes this as compression of up to 256 addresses per table.

The table's data is a 56-byte header followed by the addresses. I checked the layout against the program source:

Bytes	Field	What it means
0 to 3	Type tag	1 for an initialized lookup table
4 to 11	deactivation_slot	u64::MAX while active; the slot of deactivation otherwise
12 to 19	last_extended_slot	Slot of the latest extend; new addresses are usable from the next slot
20	last_extended_slot_start_index	Where that latest batch starts
21	Authority present	1 if the table has an authority, 0 if frozen
22 to 53	Authority	The key that must sign every change
54 to 55	Padding	Keeps the addresses 8-byte aligned
56 onward	Addresses	32 bytes each, at most 256

The authority is a table's owner in every practical sense. It does not have to be the account that paid the rent, but it is the only key that can extend, deactivate, freeze or close the table, and closing sends the rent wherever the authority chooses.

What instructions does the lookup table program have?

The program has five instructions, and their order in the source is also their instruction index:

Index	Instruction	Who signs	What it does
0	CreateLookupTable	Payer	Creates an empty 56-byte table at an address derived from the authority and a recent slot
1	FreezeLookupTable	Authority	Removes the authority forever; the table can never change or be closed
2	ExtendLookupTable	Authority, payer	Appends addresses; the payer tops up the rent for the extra bytes
3	DeactivateLookupTable	Authority	Sets deactivation_slot to the current slot; new transactions can no longer use the table
4	CloseLookupTable	Authority	After the cool-down, moves all lamports to a recipient and empties the account

Since the feature relax_authority_signer_check_for_lookup_table_creation was activated on mainnet (epoch 577), creating a table no longer needs the authority's signature, only the payer's. The program also enforces a few rules worth knowing: an empty table cannot be frozen, a deactivated table cannot be extended or frozen, and a table cannot be its own close recipient.

Who ends up owning lookup tables?

Developers and bots own lookup tables; ordinary wallets almost never do. A table belongs to whoever is set as its authority, and that is the key of whoever created it. The usual creators are:

• Protocols and aggregators. Jupiter, for example, ships its own tables with every swap. When I asked Jupiter's API for a 0.1 SOL to USDC route on November 4, 2026, it returned the table 9JGzPYdYzjGntWuHuzDSnRLKa7v6CcZ8dhZBGBSccuDp, which holds 253 addresses and 0.0420624 SOL of rent, with the authority 9RAufBfjGQjDfrwxeyKmZWPADHSb8HcoqCdrmpqvCr1g. Your swap reads that table; the rent is not yours and you cannot close it.
• Developers. Anyone building transactions with many accounts creates tables from a script or the CLI, often a new one per test run, and forgets them.
• Bots. Arbitrage, liquidation and market-making bots create tables for the accounts they hit repeatedly, sometimes by the dozen.

So if you only trade through wallets and dApps, expect to find nothing, and the SOL in your wallet is more likely in empty token accounts and other rent deposits. If you ever ran a bot or deployed code from a key, it is worth checking that key. The trading bot wallet cleanup guide covers the token account side of the same wallets.

How much SOL is locked in a lookup table?

A lookup table holds the rent-exempt minimum for 56 + 32 x N bytes, which is 0.00093472 SOL for an empty table plus 0.00016256 SOL per address at the current rate of 5,080 lamports per byte. I took these figures from getMinimumBalanceForRentExemption on mainnet on November 4, 2026. An account keeps the lamports it was funded with, so tables created before Solana lowered rent from 6,960 lamports per byte hold the older, higher amount:

Addresses	Account size	Rent today (lamports)	Rent today (SOL)	Older tables (SOL)	You keep after a 5% fee (today's rate)
0	56 bytes	934,720	0.00093472	0.00128064	0.00088798
1	88 bytes	1,097,280	0.00109728	0.00150336	0.00104242
10	376 bytes	2,560,320	0.00256032	0.00350784	0.00243230
20	696 bytes	4,185,920	0.00418592	0.00573504	0.00397662
30	1,016 bytes	5,811,520	0.00581152	0.00796224	0.00552094
64	2,104 bytes	11,338,560	0.01133856	0.01553472	0.01077163
128	4,152 bytes	21,742,400	0.02174240	0.02978880	0.02065528
256 (full)	8,248 bytes	42,550,080	0.04255008	0.05829696	0.04042258

One table is small money. A bot key with forty full tables, though, has about 1.7 SOL sitting in them. For other sizes the Solana rent calculator uses the live rate, and the rent-exempt minimum by account type puts lookup tables next to token accounts, stake accounts and program buffers.

How do you find lookup tables you own?

You find them by searching the lookup table program for accounts whose authority field, at byte offset 22, is your address. Wallets and the Solana CLI do not list them for you; solana address-lookup-table get <ADDRESS> only shows a table whose address you already know. Two ways work:

1. Read-only scan. Open the Buffer & ALT Closer, connect the wallet, or paste any address into the lookup field without connecting. It lists every table with that authority, with its SOL balance and whether it is active, cooling down or closable. Scanning signs nothing.
2. One RPC call. Send getProgramAccounts for AddressLookupTab1e1111111111111111111111111 with a memcmp filter of offset: 22 and bytes: <your address>. Adding dataSlice with length 0 keeps the response small; the lamports field of each result is its rent.

If you deployed or ran scripts with a CLI keypair, the authority is that key, not your browser wallet. Run solana address to see it, then search for that address.

How do you close an address lookup table?

You close it in two transactions a few minutes apart: deactivate, wait for the cool-down, then close. The program enforces the order.

Step	Instruction	Cost	What happens
1. Check	none	Free	Confirm nothing you run still references the table
2. Deactivate	DeactivateLookupTable	Network fee	Table stops working for new transactions; this is permanent
3. Wait	none	Free	About 512 blocks, roughly 3.5 to 4 minutes
4. Close	CloseLookupTable	Network fee	All lamports go to the recipient; the account is emptied

The wait is measured against the SlotHashes sysvar, which keeps the hashes of the most recent 512 blocks. While the deactivation slot is still in that list, the program reports the table as deactivating with 512 - position blocks remaining, or 513 if you try in the very same slot, and a close fails with "Table cannot be closed until it's fully deactivated in N blocks". Once the slot drops out of the list the table counts as deactivated and the close succeeds. Because skipped slots never enter the list, the wall-clock wait is a little longer than 512 x 400 ms.

The cool-down has a side effect the program comments call out: a closed table cannot be recreated at the same address, since table addresses come from a recent slot. Closing is final, and if you need the same set of addresses later you create a new table.

How do you close a lookup table with the Solana CLI?

The Solana CLI has an address-lookup-table command with create, extend, deactivate, close, freeze and get subcommands. I checked the flags against the Agave CLI source. With the authority as your configured keypair:

1. Inspect the table: solana address-lookup-table get <TABLE_ADDRESS>.
2. Deactivate it: solana address-lookup-table deactivate <TABLE_ADDRESS>. The first time, the CLI stops with "WARNING! Once a lookup table is deactivated, it is no longer usable by transactions" and asks you to rerun with --bypass-warning.
3. Wait about four minutes.
4. Close it: solana address-lookup-table close <TABLE_ADDRESS>. Add --recipient <ADDRESS> to send the SOL somewhere other than the default keypair, and --authority <KEYPAIR> if the authority is not your default keypair.

If you try to close an active table, the CLI refuses before sending anything: "Lookup table account ... is not deactivated. Only deactivated lookup tables may be closed". The CLI route is free apart from network fees and is the right choice if you have the keypair file and only a few tables. It works one table per command, which gets slow for a bot key with dozens.

How does SOLTidy's Buffer & ALT Closer handle lookup tables?

I built the Buffer & ALT Closer for keys that have collected many tables, or for authorities that live in a browser or hardware wallet rather than a keypair file. This is what it does, from its code:

• Finds tables by authority. It runs the offset-22 getProgramAccounts search above and skips frozen tables, whose authority byte is 0, because they can never be closed.
• Reads the cool-down from the chain. It reads the SlotHashes sysvar and marks each table active, deactivating (with the minutes left) or closable. Tables that are cooling down cannot be selected.
• Deactivates for free. The Deactivate button builds DeactivateLookupTable for every selected active table. SOLTidy charges nothing for this step; you pay only the network fee. The panel warns that deactivation is irreversible before you sign.
• Closes for 5%. Closing builds CloseLookupTable with your wallet as both authority and recipient, so the full balance returns to you, and the 5% SOLTidy fee is a separate SOL transfer in the same transaction. Closes are packed into as few transactions as fit the 1,232-byte limit, and each transaction pays the fee only on its own tables.
• Only acts for the connected wallet. You can scan any address read-only, but close and deactivate are enabled only when the scanned address is the wallet you connected, because only the authority can sign.

The same tool closes abandoned program deploy buffers, which usually hold far more SOL than lookup tables; it finds both in one scan. To see exactly what a transaction did afterward, paste its signature into the Solana transaction decoder, which shows whether it was legacy or v0, names the Address Lookup Table program and translates lookup table errors into plain English.

Is it safe to close a lookup table?

Closing is safe for your funds but permanent for the table, so the real risk is breaking something that still uses it. Deactivation takes effect at once: any program, bot, script or frontend that still lists the table in its v0 transactions starts failing on its next send. Before you deactivate, check:

• Your own code. Search your bot and app configs for the table address.
• Shared tables. If other people's transactions depend on your table, closing it breaks them too. This is the case freezing exists for.
• Tables you did not create. You cannot close those anyway; the program rejects any signer that is not the authority with "Incorrect lookup table authority".

Closing never touches your tokens or other accounts. The instruction only moves the table's own lamports to the recipient and resizes the table to zero bytes.

Bottom line

An address lookup table is a list of up to 256 addresses that v0 transactions use to fit more accounts into 1,232 bytes, and each one locks 56 + 32 x N bytes of rent: 0.00093472 SOL empty, 0.04255008 SOL full. Most wallets own none, because aggregators like Jupiter use their own. If you run bots or write code, check the keys you used: deactivate unused tables, wait about four minutes for the SlotHashes cool-down, then close them. The Solana CLI does it free one table at a time; the Buffer & ALT Closer scans any authority, deactivates for the network fee only and closes in bulk for 5% of the SOL recovered.