Solana Activates Transaction V1 on Mainnet, Raising the Maximum Transaction Size to 4,096 Bytes

Solana Transaction V1 is a live transaction format that can be as large as 4,096 bytes, compared with the 1,232-byte ceiling for legacy and v0 transactions. The txv1 feature gate activated on Solana mainnet at the start of epoch 1035, on September 15, 2026 at about 01:00 UTC; V1 is also live on testnet and devnet.

The change gives developers a larger transaction format, not a blanket increase for every transaction on the network. A program, wallet, SDK, RPC client and other supporting services may need to recognize V1 before an application can reliably create, submit, retrieve or process it.

Transaction V1 is live, with a 4,096-byte limit

Transaction V1 is Solana’s newer versioned transaction format. Its maximum serialized size is 4,096 bytes. That is more than three times the 1,232-byte maximum that applies to the established legacy and version-0 formats, according to Solana Improvement Document 0296.

Solana’s mainnet activation made the format usable at the protocol level rather than merely a planned upgrade. The network’s larger transaction sizes documentation identifies the epoch-1035 activation and says V1 is available across mainnet, testnet and devnet.

Transaction size concerns the encoded transaction sent through the network. It is not a general measure of how much computation a transaction can consume, how much account data a program can access, or how much SOL a user will pay. Those are related operational considerations, but they are not interchangeable with the byte limit.

The larger limit applies only to V1, not every Solana transaction

Activation does not alter the size rules for transactions that continue to use older formats. Legacy transactions and v0 transactions remain valid and retain their 1,232-byte limit. V1 operates alongside them rather than replacing them outright.

That distinction matters for both users and developers. An app may continue sending legacy or v0 transactions exactly as before, while another app can adopt V1 where its transaction construction and supporting services are ready. The presence of V1 on mainnet therefore does not mean a transaction that exceeds 1,232 bytes will automatically be accepted if it is encoded as legacy or v0.

Version choice is consequently part of transaction design. Developers should select the format that fits the accounts, instructions and service compatibility required for a particular operation, instead of treating 4,096 bytes as a network-wide default.

V1 trades address lookup tables for inline account addresses

The important architectural difference is how the formats handle account addresses. Version-0 transactions support address lookup tables, commonly called ALTs. These tables can let a v0 transaction reference addresses without carrying each full address in the transaction message.

V1 does not support address lookup tables. It instead carries account addresses inline. Under the documented constraints, V1 supports up to 64 accounts, as set out in Solana Improvement Document 0385.

The trade-off is central to deciding whether V1 is appropriate. The expanded 4,096-byte allowance creates room to include more information directly in the transaction, including inline account addresses. But a developer cannot combine that V1 byte budget with the ALT mechanism available in v0.

For example, an application whose operation needs a broad set of account addresses may find that a V1 transaction can carry its required accounts directly, within the format’s constraints. An application already structured around address lookup tables may instead prefer v0, depending on its transaction’s composition. Neither format is simply a larger or smaller edition of the other; they use different account-address mechanisms.

Legacy transactions remain a separate option for simpler flows. The practical task is to measure and construct the transaction against the rules of its chosen format, rather than assuming account capacity or address encoding works identically across all three.

Wallet and SDK support determines whether an app can send V1

Protocol activation alone does not ensure that an application can send a V1 transaction through a user’s wallet. Wallets are expected to advertise the transaction versions they support through the Wallet Standard supportedTransactionVersions array. An application intending to send V1 needs a wallet and SDK that support V1.

An application can use that version signal to determine whether the newer format is available through a given wallet connection—but if the connected wallet does not indicate V1 support, V1 cannot safely be treated as a signing path.

Apps that only create legacy or v0 transactions do not need to migrate because V1 is live. Solana’s upgrade guidance frames V1 adoption as a compatibility requirement for applications that choose to send the new format, not as a compulsory conversion of all existing transaction flows.

This is especially relevant for products with several transaction participants. A front end may construct a transaction, a wallet may sign it, and a separate service may sponsor fees or co-sign. Introducing V1 calls for checking the format support across the path, rather than validating only the application’s initial transaction builder.

RPC clients must explicitly opt in to reading V1 transactions

Sending a transaction and reading transaction data are separate compatibility questions. RPC consumers that retrieve V1 transactions must set maxSupportedTransactionVersion to 1. Without that declared support, a client should not assume it can parse or receive V1 transaction results correctly.

Solana’s RPC JSON structures documentation describes V1-specific fields, including transactionConfig. It also notes that addressTableLookups are omitted from V1 messages, consistent with V1’s lack of address lookup table support.

Indexers, explorers, analytics systems and back-end applications should therefore review more than their transaction-submission code. Systems that call RPC endpoints to inspect confirmed transactions, decode messages or retain normalized transaction records need to request V1 support and handle the format’s fields correctly.

A useful implementation sequence is straightforward: first establish that the wallet and SDK can create and sign V1, then ensure the application selects V1 only when that support exists, and finally configure downstream RPC readers to accept transaction version 1. Even a successful submission does not by itself prove that monitoring, reconciliation or reporting services understand the result.

TransactionConfig moves resource and fee settings out of ComputeBudget instruction inference

V1 moves compute-unit, loaded-account-data, heap and priority-fee settings into transactionConfig instead of having them inferred from ComputeBudget instructions. Solana’s upgrade documentation says indexers, fee sponsors and co-signing services should use that field when handling V1 transactions.

The change matters to services interpreting transactions after assembly or signing. Indexers may need to adjust parsing logic, while fee sponsors and co-signing providers need to review the data used before authorizing, funding or processing their role.

It is not a retroactive change to older formats: legacy and v0 transactions persist alongside V1, so the relevant representation must be selected through format-aware handling.

Frequently Asked Questions

Is Solana Transaction V1 active on mainnet?

Yes. Solana’s txv1 feature gate activated at the start of epoch 1035 on September 15, 2026, at approximately 01:00 UTC. The format is also live on testnet and devnet.

Are all Solana transactions now allowed to be 4,096 bytes?

No. The 4,096-byte maximum applies only to Transaction V1. Legacy and v0 transactions continue to have a 1,232-byte maximum size.

Does Transaction V1 use address lookup tables?

No. V1 carries account addresses inline and does not support address lookup tables. V0 continues to support the ALT mechanism.

How can an RPC application read V1 transactions?

The RPC request must set maxSupportedTransactionVersion to 1. Clients should also account for V1 fields such as transactionConfig and should not expect addressTableLookups in a V1 message.

Must an existing Solana app migrate to V1?

Not if it only uses legacy or v0 transactions. An app needs V1-capable wallet and SDK support when it chooses to create and send V1 transactions.

Disclaimer: This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.