Solana V1 trading landed on the testnet, aiming to merge multiple operations into one step

Solana V1 upgrade: The transaction capacity has been increased to 4096 bytes, helping atomization operations

On September 1, Anza launched Transaction V1 on the Solana test website, kicking off the final drill before its official launch on September 9.

According to Solana Compass, the upgrade aims to allow encryption and DeFi workloads that would otherwise need to be handled in different transactions to be completed in one atomic transaction.

The work that was originally split can now be completed with one call.

The most significant change is space expansion. The maximum size of Solana serialized transactions has been increased 3.3 times from 1,232 bytes to 4,096 bytes. This change has taken effect on the test network epoch1025.

According to the Solana Foundation's update on large transactions, such a large transaction size will allow zero-knowledge proofs, large multi-signature transactions, and various signature schemes to be implemented in a single transaction, which previously could not be completed in a single transaction.

Correspondingly, the number of transactions that need to be processed is reduced, the fees used to pay for signatures are reduced, and there is no need to wait for a series of confirmations. The BLS signature scheme, confidential transactions and multi-signature settings will all benefit from this upgrade.

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

Less than a day after the upgrade was activated, Anza CEO Brennan Watt posted on X, mentioning that a big transaction had appeared on the Testnet browser, with the postscript: "Note: The big transaction has arrived at Testnet."

Why a deal trumps a bundle

Atomicity is important because developers have sometimes used Jito bundles to bypass Solana's old size limits. In fact, SIMD-0296 explains this workaround and points out that bundles lack atomicity at the protocol level, while native transactions do.

According to Jito's documentation, a bundle can contain up to five transactions, processed in an all-or-nothing order. But the bundle runs inside Jito's block engine and requires tips from competing verifiers. The V1 transaction refers to a single Solana native transaction with the transaction-level atomic guarantees provided by Solana.

For DeFi developers, this helps simplify establishing exchange routes, certifications, and other multi-step transactions. If the entire operation is completely covered by V1 transactions, then it either succeeds or rolls back as a single native transaction without relying on a set of transaction bundles.

DeFi gets more than just extra bytes

V1 also modifies the transaction structure. Legacy and V0 versions use ComputeBudget instructions to handle priority fees and resource requests, while SIMD-0385 incorporates these configurations into V1 's transaction configuration, simplifying the verifier's work in identifying resource requirements without having to proactively traverse the instruction list.

V1 also canceled the Address lookup table (ALT) used by V0 to shorten account addresses. Based on the Solana Foundation's analysis of ALT tradeoffs in V1, V1 switched to inline address placement. This makes it easier for validators to enter, a significant improvement over applications in V0 that require a large number of accounts-which consume more bytes when converting.

The practical benefit for routers and DEX aggregators is that there is now more space to build complex atomic routes. However, this improvement is not without limitations. In fact, the capacity limit for up to 64 different accounts in Solana remains the same, so applications that require a large number of accounts may still be subject to this limit, even if byte capacity is no longer an issue.

This upgrade comes as Solana makes great strides into the field of on-chain finance. The Solana report for the second quarter of 2026 provided by Galaxy shows increasing activity in stablecoins, tokenized stocks and real-world assets.

According to Galaxy's predictions, Solana's potential in the future will largely depend on the ability of assets to be used in lending, mortgage, margin and income, rather than just issuance or trading. According to DeFiLlama's data on Solana, the platform seems to have a strong DeFi ecosystem.

In addition, the timing of the upgrade coincides with the Agave 4.2 upgrade phase. It has been previously reported that the gradual implementation of the cost reduction plan is expected to save approximately 90% in fees, while shortening processing time from 500 milliseconds to 200 milliseconds, benefiting stablecoin issuers, wallet providers and payment systems.

RPC operators have one week to update

V1 is an optional upgrade, so Legacy and V0 transactions will continue to operate normally. The key question is whether the infrastructure to read V1 traffic is ready.

Anza has asked RPC providers to migrate to Agave v4.2.2 or v4.3.0-beta.3. Helius's Agave 4.2 migration checklist also emphasizes that RPC consumers who have not claimed V1 compatibility may encounter situations where calls such as getBlock fail when using V1 transactions.

The process began with a local test of V1 on August 24, and then confirmed on August 29 that the main online launch date was September 9. V1 was launched on the test network epoch 1025 on September 1 and is scheduled to be activated on the main network on September 9.

This latest testnet operation is the final preparation step for RPC providers, indexers, wallets, SDKs and analysis platforms before going online on the main network.