Solana activated the Transaction V1 feature on its mainnet on Tuesday, allowing more data to be included in each transaction. The upgrade gives developers additional room to execute complex actions within a single atomic process and is relevant to DeFi developers, wallet providers, indexers, and RPC operators. It may also affect projects working with tokenized assets and payment solutions.

According to Solana’s upgrade page, the txv1 feature gate was rolled out at the beginning of epoch 1035 at approximately 01:00 UTC on September 15. Transaction V1 is now live on Solana’s mainnet, testnet, and devnet.

Transaction size increases from 1,232 to 4,096 bytes

The most visible change is the increase in the maximum size of a serialized transaction. Solana has raised the limit from 1,232 bytes to 4,096 bytes, providing approximately 3.3 times more space for transaction data.

The format for the new transaction was defined in SIMD-0296, while the V1 Message Format is based on SIMD-0385. Previously, Solana’s transaction-size limit was tied to conservative network maximum transmission unit, or MTU, constraints. Transaction V1 moves away from the hard limit on stream size imposed by QUIC, enabling larger transactions.

The additional capacity is intended to support workloads that require substantial amounts of transaction data, including zero-knowledge proofs, large multisig operations, and signatures that use BLS. As Cryptopolitan previously reported, V1 was launched on the testnet at epoch 1025 on September 1, giving infrastructure providers time to prepare for the mainnet release.

Why a single atomic transaction matters

Before the upgrade, developers encountering Solana’s transaction-size limit could, in some cases, divide their operations across several transactions or use Jito bundles. However, the explanation in SIMD-0296 states that a bundle is not equivalent to a native transaction when atomicity is considered at the protocol level.

Transaction V1 allows more instructions and data to be placed within one transaction. As a result, routing, proof checking, and batching can either all succeed or all fail, rather than being carried out across separate transactions. Depending on the operation, this could also reduce the number of signatures and confirmations required.

Address Lookup Table trade-off

Transaction V1 also changes how transactions handle resources and account references. Compute-limit and priority-fee settings have been moved from the ComputeBudget instructions to the transaction settings, making those parameters more accessible to infrastructure providers.

V1 transactions do not use Address Lookup Tables because the referenced accounts are included directly in the transaction. This simplifies the transaction structure but can increase its size. A v0 Address Lookup Table requires only a one-byte index, whereas an inline public key requires 32 bytes.

An analysis of Solana’s Address Lookup Tables found that 62% of v0 transactions used at least one Address Lookup Table. Consequently, dense transactions that use more than one table could grow by more than 1,500 bytes when account references are included directly. The account limit remains unchanged at 64 accounts.

Role in Solana’s tokenized-finance expansion

The upgrade comes as Solana expands its role in on-chain finance. According to DeFiLlama, the total value locked in Solana’s DeFi sector is nearly $5.95 billion, while its 24-hour decentralized-exchange volume is approximately $1.79 billion.

Solana’s August summary also reported that the value of real-world assets on the network had surpassed $4 billion and was distributed across more than 350,000 addresses. In addition, xStocks had accumulated more than $500 million in assets under management.

Greater transaction capacity alone does not guarantee increased adoption. Galaxy Research has observed that a significant share of the value held in Solana’s tokens remains unused, while competing platforms continue to lead in some rapidly expanding areas. Transaction V1 broadens the range of applications developers can build on Solana, but the subsequent response from users, liquidity, and transaction activity remains an open question.

Required changes for operators and developers

RPC readers should set maxSupportedTransactionVersion: 1 for getTransaction and getBlock. Indexers need to read V1 compute limits and priority fees from transactionConfig.

Validators and RPC operators should run Agave v4.2.2 or later. V1 senders should set compute and loaded-account limits explicitly and use base64 for transactions larger than 1,232 bytes.

Wallet providers should advertise V1 support only after confirming that their software can correctly parse and sign the new format, in line with Solana’s upgrade guidance. The original report was published by Cryptopolitan.