Solana V1 transactions hit testnet, aiming to fold multi-step operations into one

On September 1, Anza initiated Transaction V1 on the testnet of Solana, allowing for the final rehearsal of this upgrade prior to its launch on September 9.

The change is intended to allow cryptographic and DeFi workloads that had initially to be fragmented in different transactions to now be processed in one single atomic transaction, as stated by Solana Compass.

Jobs that used to be split now fit in one call

The most notable alteration is the increase in space. The maximum size of a Solana serialized transaction has increased from 1,232 bytes to 4,096 bytes which is an increase of 3.3 times and took effect at the testnet epoch 1025.

According to the website dedicated to Solana Foundation’s large transaction update, such large transaction size will make it possible to implement zero-knowledge proofs, large multisig transactions along with various signature schemes which were unachievable within one transaction.

In turn, fewer transactions have to be processed, less money is required to pay for signatures, and there is no need to wait for a chain of confirmations. BLS signature schemes, as well as confidential transactions and multisig setups will benefit from this upgrade.

There are two main proposals that are essential for the improvement. SIMD-0296 increases the transaction size from 1,232 bytes to 4,096 bytes, while SIMD-0385 defines the V1 message format and moves transaction configuration into the message itself.

Why one transaction beats a bundle

The importance of atomicity comes from the fact that at times, developers bypassed Solana’s old size limit with Jito bundles. In fact, SIMD-0296 explains that workaround and also mentions that bundles lack atomicity at protocol level as in the case with one native transaction.

According to Jito’s documentation, bundles can include up to five transactions processed sequentially on an all-or-nothing basis. But bundles operate within Jito’s block-engine and compete among validator tips. V1 transaction, on the other hand, refers to a single native Solana transaction, which carries the transaction-level atomicity guarantee from Solana.

For DeFi developers, this can help simplify helping in establishing swap routes, proofs, and other kinds of multistep transactions. If the operation is entirely covered by V1 transaction, it either succeeds or returns it back as a single-native transaction instead of relying on a bundle of transactions.

What DeFi gets beyond extra bytes

V1 modifies the transaction structure as well. Whereas Legacy and V0 processes priority fees and resource requests using ComputeBudget instructions, SIMD-0385 takes these configurations into V1’s transaction configurations, thereby simplifying the job for the validators in the process of identifying resource needs without actively searching through the instructions list.

V1 also eliminates Address Lookup Tables, or ALTs, utilized by V0 for the purpose of shortening account addresses. According to the Foundation’s analysis of the V1’s ALT tradeoff, V1 instead performs address placement inline. This makes validator input easier compared to the method used in heavy account applications in V0, which consume more bytes when converted.

The practical benefit for routers and DEX aggregators is that there is now more room for complex atomic routes. However, this improvement does not come without limitation. Indeed, Solana’s maximum capacity of 64 different accounts remains unchanged, and thus applications that require heavy use of accounts can still suffer from this limitation, even if byte-limit capacity is no longer an issue.

The upgrade is being introduced as Solana is making a leap into on-chain finance. The report about Solana for Q2 2026 provided by Galaxy showcases increasing activity of stablecoins, tokenized equities and real-world assets.

According to Galaxy, in the future, the potential of Solana will largely depend on the ability to use assets in lending, collateralization, margin, and yield, instead of just issuance or trading. Based on DeFiLlama data on Solana, the platform seems to have a strong DeFi presence.

Moreover, the timing of the upgrade matches the Agave 4.2 upgrade phase. Informatively, Cryptopolitan stated that the plan for gradual implementation of cost reduction was expected to lead to savings of about 90%, along with decrease of time needed for processing from 500 to 200 milliseconds, leading to benefits for stablecoin issuers, wallet providers and payment systems.

RPC operators have a week to update

V1 is opt-in, so Legacy and V0 transactions keep working. The issue is whether infrastructure reading V1 traffic is ready.

Anza has obliged RPC providers to move to Agave v4.2.2 or v4.3.0-beta.3. The Helius Agave 4.2 migration checklist also stresses that RPC consumers who don’t state V1 compliance can experience call failures such as getBlock when a V1 transaction is used.

The process began with local testing of V1 on August 24, shortly after which the mainnet date was confirmed as September 9 on August 29. V1 enabled the Testnet on September 1 at epoch 1025, with a scheduled activation on the mainnet on September 9.

This latest testnet run serves as the last preparatory step for RPC providers, indexers, wallets, SDKs and analytical platforms before the mainnet launch.