Solana transaction versions and lookup tables, explained

Why account references consume message space

A transaction carries signatures, account references, instruction data and validity information. Every byte uses part of its format's size budget. A complex trade can need many accounts even though the user sees one operation.

Legacy messages write account addresses inline. A full public key uses 32 bytes, before the surrounding message structures and signatures. Adding accounts therefore competes with other message data for space.

Current Solana format documentation lists a 1,232-byte maximum for legacy and v0 transactions and 4,096 bytes for v1. These limits apply to the respective transaction formats. Other resource and account limits still apply; message capacity is only one constraint.

A builder chooses a supported format for the construction. A bigger message is useful only when the wallet, submission path and program workflow support the required format and resources.

V0 uses lookup tables for selected addresses

An address lookup table, or ALT, is an onchain record containing public keys. A v0 message can name a table and reference selected entries by compact indices instead of writing every selected key inline.

For a conceptual example, a table stores a group of addresses used by a trading route. The transaction carries the table's address and indices for the needed read-only or writable entries. The runtime resolves them into actual keys before execution.

The instruction still operates on full accounts. The lookup representation saves wire space; it does not give the route new permissions or bypass compute constraints. ALT-loaded accounts are not transaction signers, so required signers remain represented through the appropriate static message rules.

Tables have state and lifecycle conditions. A constructor needs the correct table contents and usable entries. Referring to a different, stale or unavailable table can make a message fail before its intended application action.

Readers must reconstruct the complete account list

Compiled instructions refer to positions in the message's account list. With v0, the complete execution list includes resolved lookup addresses in addition to static keys.

If an explorer or indexer reads only static keys, it can assign a transfer to the wrong account or fail to interpret a program. Match instruction indices to the fully resolved list and respect the format's ordering.

Parsed or metadata-rich RPC responses can help expose the necessary addresses. The exact representation depends on requested encoding and supported version, so make that part of your reader's contract.

A practical test fixture should include a transaction that actually uses lookup-loaded accounts. A parser successfully reading a simple legacy payment has not yet demonstrated that behaviour.

Documented transaction size limits

V1 changes both space and resource configuration

The current v1 format removes ALTs and writes accounts inline under a larger size budget. Resource settings are carried through message configuration rather than simply copying the legacy/v0 ComputeBudget-instruction pattern.

Its priority fee is an absolute lamport total in the message configuration. In legacy and v0, the familiar priority calculation multiplies requested compute-unit price and limit. Apply the format's actual rules when estimating and displaying fees.

The official page marks v1 active on mainnet, devnet and testnet at the date of this source check. A protocol's activation and a particular wallet or SDK's support are separate properties. Existing tooling can still default to an older format.

When moving an integration, examine construction, wallet signing, serialization, simulation, submission and readback. Each component needs to understand the format it handles.

Opt data readers into versions they can decode

Transaction-reading methods expose a maximum-supported-version option where applicable. A reader restricted to v0 can reject a v1 record even when the transaction executed correctly.

Set that option to the highest version your decoder and downstream logic actually support. Updating a parameter alone is not a complete migration if accounting code still assumes the old account or resource layout.

Handle an unsupported-version error as a visible coverage issue. Preserve the signature and resume processing after adding support. Silently skipping it can create a missing payment or an incomplete activity total.

For a library or service, document supported versions and test both supported and intentionally unsupported inputs. This makes a compatibility failure distinguishable from a missing network record.

Test a format across the complete path

Prepare representative fixtures: a simple legacy transfer, a v0 request with loaded addresses and a v1 construction supported by the chosen tools. Record the source and expected interpretation for each.

Verify signer and writable roles, resolved accounts, instruction decoding and fees. Then confirm that simulated and observed results can be read back without dropping the version-specific fields needed by your application.

A transaction builder and an accounting reader can fail at different points. Keep their test results separate, and include the wallet's advertised support in integration checks. The transaction anatomy guide provides the common concepts beneath those version differences.

Common questions