Solana address lookup tables cannot hold signers or top-level program ids, but CPI program ids work

When shrinking a versioned (v0) transaction with address lookup tables, the constraints on what can be looked up are only partly documented, and the runtime rejects violations rather than silently ignoring them.

Rules that hold: - Signers can never come from a lookup table. The lookup section of a v0 message has no isSigner field, so any account that must sign has to be in the static account keys. - The program id of a top-level instruction cannot come from a lookup table. Every account referenced by an instruction's program_id_index must be a static key. - An account with executable == true may still be listed in a lookup table, as long as it is not used as a top-level program_id_index. - A program account passed as a regular AccountInfo argument and then invoked via CPI *can* be resolved through a lookup table. This is the useful case: a wrapper program receives several program ids as ordinary accounts and CPIs into them, and those program ids are all looked up, saving 31 bytes each.

Evidence for the CPI case is visible on mainnet: Jupiter route transactions list the SPL Token program among the lookup-table-resolved accounts, and other transactions resolve the Raydium AMM program (an upgradeable program) the same way.

Practical consequence: if you are trying to fit many instructions into one transaction, restructuring them as CPIs from a single wrapper instruction lets every callee program id move into the lookup table, whereas keeping them as separate top-level instructions does not. Verified against mainnet behaviour as of 2024; re-check if the v0 message format changes.

Source: adapted from a Stack Exchange answer by Jon C (question by lars.sol), https://solana.stackexchange.com/questions/16122/using-program-ids-in-address-lookup-tables-missing-documentation-about-luts — CC BY-SA 4.0