Versioned Transaction — The Power of v0

I have the Address Lookup Table created. The accounts are registered. The activation delay has passed. The table is live on-chain, holding thirty stable addresses — program IDs, pool states, vault accounts, token mints — all compressed from 32 bytes each to a single byte index. The compression ratio is extraordinary. The math checks out. The four-hop cycle that consumed 1,385 bytes in raw form now fits inside 493 bytes with the lookup references.

There is just one problem. The transaction I am building does not know how to use the table.

I construct the transaction the way I have always constructed it — the same way every Solana tutorial teaches it, the same way the SDK defaults to, the same way every simple swap example on the internet demonstrates. I serialize it. I look for the field where the lookup table reference belongs. It does not exist. There is no slot in the transaction format for an ALT address. There is no field for index arrays. There is no mechanism to say "resolve account number 12 from this external table." The transaction format I am using does not have the plumbing.

The format is called legacy. And legacy transactions cannot use Address Lookup Tables. Not because of a configuration flag. Not because of a missing parameter. Because the data structure itself lacks the fields. It is like trying to plug a USB-C cable into a VGA port. The shapes do not match. The technology is incompatible at the physical level.

To use Address Lookup Tables, I need a different transaction format entirely. I need a Versioned Transaction. Specifically, version 0.

The 2G Phone Problem

Think about what happened when mobile carriers rolled out 5G networks across the United States. The towers went up. The infrastructure was built. The coverage maps showed bright purple zones in every major metro area. The network was there, ready to deliver gigabit speeds to anyone who connected.

But if you were still carrying a phone from 2005 — one of those chunky flip phones with a 2G radio — the 5G network might as well not exist. Your phone cannot see it. Your phone's radio hardware does not understand the 5G signal format. The antenna does not tune to the right frequencies. The chipset does not speak the protocol. The 5G tower is broadcasting right above your head, and your 2G phone connects to the old tower three blocks away because that is the only signal it knows how to interpret.

The problem is not the network. The problem is the device. The capability exists in the infrastructure. The device cannot access it.

This is the relationship between legacy transactions and Address Lookup Tables. The ALT infrastructure exists on-chain. The Address Lookup Table program is deployed. The tables are created, populated, activated. The validators know how to resolve indices. The runtime handles everything. The infrastructure is there. But the legacy transaction format — the 2G phone — cannot access it. The format does not have the fields. It does not speak the protocol.

Versioned Transactions are the 5G phone. Same network. Same towers. Same infrastructure. But the device can now access what the network offers.

What Legacy Looks Like Inside

To understand why legacy transactions cannot use ALTs, I need to look at what a legacy transaction actually contains at the byte level.

A legacy Solana transaction has two sections: signatures and a message. The message is where the action happens, and its structure is fixed:

Legacy Message:
┌─────────────────────────────────────┐
│ Header (3 bytes)                    │
│   - num_required_signatures (1B)    │
│   - num_readonly_signed (1B)        │
│   - num_readonly_unsigned (1B)      │
├─────────────────────────────────────┤
│ Account Keys (variable)             │
│   - compact-u16 length prefix       │
│   - N × 32-byte public keys        │
├─────────────────────────────────────┤
│ Recent Blockhash (32 bytes)         │
├─────────────────────────────────────┤
│ Instructions (variable)             │
│   - compact-u16 length prefix       │
│   - Each instruction:               │
│     - program_id index (1B)         │
│     - account indices array         │
│     - instruction data              │
└─────────────────────────────────────┘

That is the entire structure. Header, account keys, blockhash, instructions. Four sections. Nothing else.

Notice what is missing. There is no section for external table references. There is no field for lookup table addresses. There is no array of indices that point into an on-chain table. The format has exactly four components, and none of them is "address table lookups."

This is not an oversight. When the legacy format was designed, Address Lookup Tables did not exist. The format was designed for a world where every account referenced by a transaction carries its full 32-byte address inline, in the account keys array. The format is complete and correct for that world. It just cannot represent the concept of "look up this address in an external table." The vocabulary does not include that word.

Every account that a legacy transaction touches must appear in the account keys array as a full 32-byte public key. The instruction section references accounts by their index into the account keys array — "use account number 3" means "use the fourth 32-byte key in the account keys array." This indexing system works perfectly. It is compact, efficient, and unambiguous. But it only works with accounts that are physically present in the account keys array. There is no mechanism to say "use account number 3 from this external lookup table" because the format has no concept of external lookup tables.

This is like an old paper form from the DMV — the kind with fixed boxes for each piece of information. Name here. Address here. Date of birth here. Social Security number here. If the form does not have a box for email address, you cannot provide your email address. You can write it in the margins, but the processing system will ignore it because it reads the boxes. Adding a new field requires printing a new form. The legacy transaction format is the old form. Address Lookup Table references need a new box. The new box requires a new form.

The v0 Upgrade

Versioned Transactions introduce that new form. The key word is "versioned" — the transaction now carries an explicit version number that tells the validator which format to expect.

The version number is a single byte, prepended to the message. But it is not any byte. It uses a specific encoding trick to maintain backward compatibility with legacy transactions.

Here is the trick: the first byte of a legacy message is the num_required_signatures field from the header. This value is always a positive integer — at least 1 (every transaction has at least one signer) and at most 127 in practice. It is never zero. It is never negative. In binary, the high bit (bit 7) is always 0.

Versioned transactions set the high bit to 1. If the first byte of the message has its high bit set, the runtime knows this is a versioned transaction and interprets the remaining 7 bits as the version number. If the high bit is 0, it is a legacy transaction and the byte is the signature count.

First byte of message:
  0xxxxxxx → Legacy message (value = num_required_signatures)
  1xxxxxxx → Versioned message (version = lower 7 bits)

Version 0: 0b10000000 = 0x80 = 128

One byte. That is the entire cost of versioning. One byte that was previously always in the range 1-127 now encodes the format version when its high bit is set. The elegance is in the backward compatibility — old validators that do not understand versioned transactions see a num_required_signatures value of 128 or higher, which is invalid, and reject the transaction cleanly. No crash, no corruption, no misinterpretation. Just a clean rejection. New validators check the high bit, determine the version, and parse accordingly.

This is the Real ID principle. When the United States introduced Real ID — the enhanced driver's license standard with additional security features — old licenses did not suddenly become unreadable. The old format still works at establishments that accept it. But TSA at the airport now checks for the Real ID star marking. If the marking is present, the license is processed under the new rules with the new capabilities. If the marking is absent, the license is processed under the old rules. One small marking on the card determines which processing path applies. The card's physical format barely changed. The capabilities it unlocks are fundamentally different.

The v0 version byte is that star marking. One byte on the transaction tells the validator: "this transaction speaks the new protocol. It can reference lookup tables. Parse me accordingly."

The v0 Message Structure

With the version byte established, the v0 message extends the legacy format with one additional section at the end:

v0 Message:
┌─────────────────────────────────────┐
│ Version prefix (1 byte: 0x80)       │
├─────────────────────────────────────┤
│ Header (3 bytes)                    │
│   - num_required_signatures (1B)    │
│   - num_readonly_signed (1B)        │
│   - num_readonly_unsigned (1B)      │
├─────────────────────────────────────┤
│ Static Account Keys (variable)      │
│   - compact-u16 length prefix       │
│   - N × 32-byte public keys        │
├─────────────────────────────────────┤
│ Recent Blockhash (32 bytes)         │
├─────────────────────────────────────┤
│ Instructions (variable)             │
│   - compact-u16 length prefix       │
│   - Each instruction:               │
│     - program_id index (1B)         │
│     - account indices array         │
│     - instruction data              │
├─────────────────────────────────────┤
│ Address Table Lookups (variable)    │  ← NEW
│   - compact-u16 length prefix       │
│   - Each lookup:                    │
│     - table address (32B)           │
│     - writable indices (1B each)    │
│     - readonly indices (1B each)    │
└─────────────────────────────────────┘

The first four sections — header, account keys, blockhash, instructions — are structurally identical to the legacy format. A v0 message starts the same way a legacy message does (after the version prefix). The same 3-byte header. The same array of 32-byte account keys. The same 32-byte blockhash. The same instruction encoding.

The difference is the fifth section: Address Table Lookups. This section did not exist in legacy. It is the new box on the new form.

Each entry in the Address Table Lookups section contains three pieces of information:

The table address (32 bytes). This is the public key of the Address Lookup Table account on-chain. The validator uses this address to load the table's contents and resolve the indices. One table address per referenced table. If the transaction uses two different lookup tables, there are two entries in this section, each with its own 32-byte table address.

Writable indices (variable, 1 byte each). An array of indices into the table, each pointing to an address that the transaction needs to write to. A compact-u16 prefix encodes the array length, followed by the indices themselves. If the transaction writes to table entries at positions 3, 7, and 15, this array contains three bytes: 3, 7, 15.

Read-only indices (variable, 1 byte each). Same structure as the writable indices, but for accounts that the transaction only reads from. The separation between writable and read-only is not decorative. Solana's transaction scheduler uses this information to parallelize execution. Two transactions that both read from the same account can execute in parallel. Two transactions where one writes to an account that the other reads must be serialized. Getting the writable/read-only distinction right affects scheduling efficiency, which in MEV translates to whether a transaction lands in a slot or gets delayed.

The total byte cost of one ALT reference in a v0 transaction:

• Table address: 32 bytes
• Writable indices count prefix: 1 byte (compact-u16, usually 1 byte for small counts)
• Writable indices: W bytes (one per writable account looked up)
• Read-only indices count prefix: 1 byte
• Read-only indices: R bytes (one per read-only account looked up)

For a table that resolves 30 accounts — say 15 writable and 15 read-only — the ALT reference costs 32 + 1 + 15 + 1 + 15 = 64 bytes. Those 30 accounts, carried inline, would cost 30 × 32 = 960 bytes. The savings: 896 bytes. The ratio: 15 to 1 in total space consumed.

Account Index Resolution

The addition of the Address Table Lookups section changes how account indices work throughout the transaction.

In a legacy transaction, every account index in the instruction section refers to the account keys array. Index 0 is the first key in the array. Index 5 is the sixth key. The mapping is simple and direct.

In a v0 transaction, the account index space is expanded. The indices still start with the static account keys — the 32-byte keys that appear directly in the message. But after the static keys, the index space extends into the looked-up accounts. The writable accounts from the first table come next, then the read-only accounts from the first table, then the writable accounts from the second table (if any), and so on.

Account Index Space (v0):
┌──────────────────────────────────────────────┐
│ 0..N-1    : Static account keys (inline)     │
│ N..N+W1-1 : Table 1 writable lookups         │
│ N+W1..N+W1+R1-1 : Table 1 read-only lookups  │
│ N+W1+R1.. : Table 2 writable lookups (if any)│
│ ...                                          │
└──────────────────────────────────────────────┘

When an instruction says "use account index 22," the validator checks: is 22 within the range of static keys? If yes, use the 32-byte key at position 22 in the account keys array. If no, subtract the static key count and resolve the remainder against the lookup table entries. The instruction does not need to know whether account 22 is a static key or a looked-up key. The instruction just says "22." The resolution happens at the runtime level, transparent to the program executing the instruction.

This transparency is important. DEX programs that process swap instructions do not need to care whether their accounts arrived via static keys or via ALT lookups. The program sees the same accounts, the same data, the same permissions. The compression is entirely in the transport layer — how the transaction describes its accounts to the network — not in the execution layer.

It is like the difference between a standard highway and an express lane. A driver on the standard highway and a driver in the express lane are both driving. Both obey the same traffic laws. Both arrive at the same destination. Both use the same car on the same road surface. The express lane does not change how driving works. It changes how the driver accesses the road. The experience on the road is identical. The on-ramp is different.

Why Legacy Survived as Long as It Did

If v0 transactions are strictly superior — they can do everything legacy transactions can do, plus reference lookup tables — why does the legacy format still exist? Why is it not deprecated and removed?

The answer is the same reason the United States still has roads that predate the Interstate Highway System. They work. Millions of transactions use them. Changing them has costs.

Legacy transactions are simpler. They have fewer fields. They require less parsing logic. They are supported by every RPC provider, every wallet, every SDK, every block explorer, every indexer, every analytics tool on Solana. The ecosystem grew up on legacy transactions. Every piece of infrastructure knows how to handle them.

Versioned transactions require updated infrastructure. An RPC endpoint must understand the v0 format to accept and relay a v0 transaction. A wallet must understand v0 to sign one. A block explorer must understand v0 to display one correctly. An indexer must understand v0 to parse the transaction log and resolve the looked-up accounts.

In the early days after versioned transactions were introduced, this was a real barrier. Some RPC providers had not updated their software. Some wallets rejected v0 transactions with confusing error messages. Some block explorers displayed v0 transactions incorrectly, showing raw indices instead of resolved addresses. The infrastructure was catching up, and during that catch-up period, using v0 meant risking compatibility issues at every point in the pipeline.

By 2026, this migration is essentially complete. Every major RPC provider supports v0. Every major wallet signs v0 transactions. Every block explorer resolves ALT references correctly. The ecosystem has caught up. The 5G coverage map is filled in. There are still edge cases — some niche tools, some older self-hosted RPC nodes, some legacy SDK versions — but the mainstream infrastructure fully supports v0.

For a simple transfer — sending SOL from one wallet to another — there is no reason to use v0. The transaction touches three or four accounts. The byte budget is nowhere near the limit. Legacy works fine. Adding the v0 version prefix and an empty Address Table Lookups section costs bytes without saving any. It is like taking the express lane for a two-mile drive. The overhead of entering and exiting the express lane exceeds the time saved.

But for complex transactions — multi-instruction swaps, DeFi interactions that touch a dozen accounts, and especially multi-hop arbitrage cycles — v0 is not optional. It is the prerequisite for the entire compression stack. Without v0, there is no ALT. Without ALT, there is no byte savings. Without byte savings, complex cycles do not fit in 1,232 bytes. The chain of dependencies is absolute.

The One-Byte Revolution

Step back and consider the magnitude of change produced by a single byte.

The version prefix is one byte. 0x80. That is all. One byte added to the beginning of the transaction message. Eight bits. The smallest addressable unit of data in modern computing.

That one byte unlocks the Address Table Lookups section. The Address Table Lookups section enables ALT references. ALT references compress 32-byte addresses to 1-byte indices. That compression saves hundreds of bytes per transaction. Those saved bytes unlock multi-hop arbitrage cycles that are physically impossible under the legacy format.

One byte → one new section → one compression mechanism → hundreds of bytes saved → entire classes of transactions made possible.

It is analog television versus HDTV. For decades, American television broadcast in NTSC — an analog standard dating to 1941. The signal format was fixed. The resolution was fixed. The color encoding was fixed. Every TV set, every broadcast tower, every cable box spoke NTSC. The picture was adequate. It worked. It had worked for sixty years.

Then digital television arrived. The signal format changed. The encoding changed. The resolution leaped from 480 interlaced lines to 1080 progressive lines. The picture quality improved by an order of magnitude. But the transition required new transmitters, new receivers, new cables, new tuners. Old TVs could not decode the new signal. Converter boxes bridged the gap during the transition. Eventually the old analog signals were switched off entirely.

The versioned transaction migration is smaller in scale but identical in structure. The old format (legacy) works but has hard limits on what it can represent. The new format (v0) adds a small change to the signal — one byte of version prefix — that unlocks an entirely new capability. The transition required infrastructure updates across the ecosystem. Converter boxes (compatibility layers in SDKs and RPC providers) bridged the gap. And now, the new format is the standard for any transaction that needs its full power.

The one byte is not the revolution. The one byte is the door. Behind the door is the Address Table Lookups section, which is the room that holds the compression mechanism, which is the tool that solves the 1,232-byte constraint for complex transactions.

The Signing Difference

There is a subtle but critical detail in how signing works for versioned transactions versus legacy transactions.

In a legacy transaction, the signer signs the serialized message — the raw bytes of the header, account keys, blockhash, and instructions. The signature covers every byte of the message.

In a v0 transaction, the signer signs the serialized v0 message — which includes the version prefix and the Address Table Lookups section. This means the lookup table references are signed. The signer commits not just to "I want these instructions executed with these accounts" but also to "I want these accounts resolved from this specific table."

This matters for security. If the lookup table references were not signed, an attacker could potentially intercept the transaction, replace the table reference with a malicious table containing different addresses, and forward the modified transaction. The swap instructions would execute against different pool accounts — accounts controlled by the attacker. The signing covers the table addresses and the indices, preventing this attack vector.

The signing also covers the table address itself, not just the indices. This means a transaction commits to a specific table. If the table is closed and recreated at the same address with different contents — a theoretical attack where the attacker creates a table with the same address but maps index 5 to a different account — the signature would still be valid because the table address has not changed. However, this attack is infeasible in practice because Solana account addresses are derived from creation parameters in a way that makes address reuse after deletion effectively impossible for program-derived addresses.

The practical implication for bot development: the transaction must be fully assembled — including all ALT references and resolved indices — before signing. The signing function receives the complete v0 message with all lookup references already in place. This is different from a workflow where you might sign first and attach metadata later. In v0, everything is metadata. Everything is signed.

What Cannot Be Looked Up

Not every account in a v0 transaction can come from a lookup table. Some accounts must remain in the static account keys array regardless of whether they appear in a table.

Signers must be static. Any account that signs the transaction — typically the fee payer and any instruction-level signers — must appear in the static account keys array with its full 32-byte address. This is because the signature verification logic needs to match each signature against a specific public key, and that matching happens against the static keys. A signer referenced through a lookup table would be ambiguous — the validator would need to load the table before it could verify the signature, but signature verification is one of the first processing steps, before account loading.

The fee payer must be static. The fee payer is always the first account in the static keys array (index 0). It is always a signer. It is always writable (fees are deducted from its balance). This is the one account that can never be compressed, in any transaction, regardless of format.

Program IDs referenced in instructions are a special case. In the instruction encoding, each instruction specifies a program ID by its index into the account array. In v0, this index can point to either a static key or a looked-up key — programs referenced through ALTs work correctly at the execution level. However, putting a program ID in the static keys ensures it is available for signature-independent verification. In practice, frequently invoked programs (Token program, System program, DEX programs) are often placed in the ALT to save bytes, and this works without issues.

Everything else — pool accounts, vault accounts, token mint addresses, authority PDAs, oracle accounts, tick arrays, bin arrays, configuration accounts — can be resolved through the lookup table. These are the accounts that consume the bulk of the byte budget in multi-hop transactions, and they are the accounts where ALT compression delivers its value.

The Migration Path

Migrating from legacy to v0 transactions is not a flag flip. It is a plumbing change that touches every stage of the transaction lifecycle.

Construction. The transaction builder must produce a v0 message instead of a legacy message. This means adding the version prefix, maintaining the distinction between static keys and looked-up keys, and populating the Address Table Lookups section with the correct table addresses and indices. The builder must know which accounts are in which tables and at which indices. This requires maintaining a mapping from account addresses to (table, index) pairs, and consulting that mapping during transaction construction.

Serialization. The wire format changes. A legacy message serializes as header + account_keys + blockhash + instructions. A v0 message serializes as version_prefix + header + static_account_keys + blockhash + instructions + address_table_lookups. The serialization code must handle both formats if the system supports a mix of transaction types.

Signing. The data that gets signed changes. The signer produces an Ed25519 signature over the serialized v0 message bytes. The signature covers the version prefix and the ALT references. Any change to the table reference or the indices after signing invalidates the signature.

Transmission. RPC endpoints that receive transactions must accept v0 format. The sendTransaction RPC method accepts both legacy and v0 transactions in their serialized form. The RPC node deserializes, validates, and forwards. For Jito bundles, the bundle format accepts v0 transactions — and in fact, MEV bundles almost universally use v0 because the compression is essential for the complex transactions that MEV involves.

Deserialization and display. Block explorers, transaction parsers, and analytics tools that consume transaction data from the chain must resolve ALT references to display human-readable account addresses. A transaction log that shows "account index 22" is useless without resolving index 22 against the lookup table to get the actual public key. This resolution requires loading the table's state at the time the transaction executed, because tables can be modified over time.

The migration is a one-time cost. Once the transaction pipeline produces v0 transactions, every subsequent transaction benefits. The cost is engineering time — rewriting construction, serialization, signing, and display code. The benefit is access to ALT compression on every transaction from that point forward.

The MEV Significance

For an MEV bot, the legacy-to-v0 migration is not a nice-to-have upgrade. It is a survival requirement.

The reasoning is a simple chain of dependencies:

Multi-hop arbitrage cycles require many accounts. Many accounts consume many bytes. Many bytes exceed 1,232. Exceeding 1,232 means the transaction is rejected. Address Lookup Tables compress accounts from 32 bytes to 1 byte. ALTs require the Address Table Lookups section. The Address Table Lookups section exists only in v0 transactions. Therefore: no v0, no ALT, no compression, no multi-hop cycles.

A bot running on legacy transactions is limited to cycles where the account list fits in 1,232 bytes with full 32-byte addresses. In practice, this means two-hop cycles through simple DEX protocols, and some tight three-hop cycles through protocols with low account counts. The moment the cycle requires a concentrated liquidity DEX with tick arrays, a bin-based DEX with bin arrays, or a fourth hop through any protocol, the byte budget explodes.

The bot operating on legacy is like a delivery company with a fleet of compact sedans. The sedans work for small packages. They work for local deliveries. But the company cannot take on any job that requires a truck. The large, high-value deliveries — the ones with the best margins — go to competitors who have trucks. The sedan company is not losing those jobs because of bad routing or slow drivers. It is losing them because the vehicle cannot carry the cargo.

v0 is the truck. The same roads. The same destinations. The same traffic. But the cargo capacity is fundamentally different. The sedan (legacy) carries 1,132 bytes of payload after fixed overhead, with every account consuming 32 bytes. The truck (v0) carries the same 1,132 bytes of payload, but each looked-up account consumes 1 byte instead of 32. The payload space has not changed. The density of information per byte has changed by a factor of 32.

A bot that does not adopt v0 is not competing on the same terms as bots that do. It is competing with a smaller vehicle. Every cycle that requires more accounts than the legacy budget allows is invisible to the legacy bot — not unprofitable, not risky, not poorly timed, but physically unreachable. The opportunity exists on the blockchain. The price discrepancy is real. The profit is there. The legacy bot cannot construct a transaction to capture it.

This is not a theoretical concern. In practice, the most profitable MEV opportunities tend to involve more complex routes — more hops, more diverse DEX protocols, more accounts. Simple two-hop cycles through a single DEX protocol are the most contested opportunities on the network. Every bot can find them. Every bot can fit them in a transaction. The competition is fierce and the margins are thin. Complex cycles through multiple protocols are less contested precisely because they require more sophisticated transaction engineering — including v0 format and ALT usage.

The Format Is the Foundation

The versioned transaction format is not glamorous. It does not involve clever algorithms or advanced mathematics. It is one byte of version prefix, one new section in the message structure, and a set of infrastructure requirements for the ecosystem to support it. The concept is straightforward. The implementation is engineering — updating serialization code, managing signing changes, ensuring compatibility.

But that one byte is the foundation upon which the entire compression stack rests. Without v0, Address Lookup Tables are on-chain data with no way to reference them in transactions. Without ALT references, every account pays its full 32-byte toll. Without compression, complex cycles exceed 1,232 bytes. Without fitting in 1,232 bytes, the opportunity does not exist.

The version prefix is one byte. The Address Table Lookups section is a few dozen bytes of table addresses and indices. Together, they transform the transaction's carrying capacity. The 1,232-byte wall stands exactly where it has always stood. The IPv6 minimum MTU has not changed. The packet header overhead has not changed. The limit is permanent.

What has changed is how much fits inside that limit. And the change starts with a single byte: 0x80.