Anza enabled Transaction V1 on Solana's testnet on September 1, giving the network a final rehearsal of the upgrade ahead of its scheduled mainnet launch on September 9. According to Solana Compass, the change allows cryptographic and DeFi workloads that previously had to be fragmented across multiple transactions to be processed in a single atomic transaction.

Split jobs now fit in one call

The most notable change is the increase in space. The maximum size of a serialized Solana transaction has grown from 1,232 bytes to 4,096 bytes — a 3.3x increase — taking effect at testnet epoch 1025. The 1,232-byte cap dated back to Solana's earliest protocol design, and V1 marks the first time the limit has been raised at the message-format level since V0 introduced Address Lookup Tables as a partial workaround for size pressure.

According to the Solana Foundation's large transaction update page, the larger size makes it possible to implement zero-knowledge proofs, large multisig transactions, and various signature schemes that previously could not fit within a single transaction. The result is fewer transactions to process, lower costs for signatures, and no need to wait for a chain of confirmations. BLS signature schemes, confidential transactions, and multisig setups are expected to benefit from the upgrade.

Two proposals are central to the improvement: SIMD-0296 raises the transaction size limit from 1,232 to 4,096 bytes, while SIMD-0385 defines the V1 message format and moves transaction configuration into the message itself.

Less than a day after the activation, Anza CEO Brennan Watt posted on X pointing to a large transaction on the testnet explorer with the message: "ATTENTION: large transactions have hit the testnet."

Why one transaction beats a bundle

Atomicity matters because developers have at times worked around Solana's old size limit using Jito bundles. SIMD-0296 explicitly documents that workaround and notes that bundles lack protocol-level atomicity, unlike a single native transaction.

Per Jito's documentation, bundles can contain up to five transactions processed sequentially on an all-or-nothing basis. However, bundles operate within Jito's block engine and compete among validator tips. A V1 transaction, by contrast, is a single native Solana transaction carrying Solana's own transaction-level atomicity guarantee.

For DeFi developers, this simplifies building swap routes, proofs, and other multistep operations: if the entire operation fits in a V1 transaction, it either succeeds or reverts as one native transaction rather than relying on a bundle.

What DeFi gets beyond extra bytes

V1 also changes the transaction structure itself. Where Legacy and V0 transactions handle priority fees and resource requests through ComputeBudget instructions, SIMD-0385 moves these settings into V1's transaction configuration, making it easier for validators to identify resource needs without scanning the instruction list.

V1 additionally removes Address Lookup Tables (ALTs), which V0 used to shorten account addresses. According to the Foundation's analysis of the V1 ALT trade-off, V1 instead places addresses inline, simplifying validator input compared with V0's approach, which consumed more bytes when converting addresses in account-heavy applications.

The practical benefit for routers and DEX aggregators is more room for complex atomic routes. The improvement is not without limits, however: Solana's cap of 64 distinct accounts per transaction remains unchanged, so account-heavy applications can still hit that ceiling even though byte capacity is no longer the constraint.

The upgrade arrives as Solana pushes deeper into on-chain finance. Galaxy's Q2 2026 Solana report shows growing activity in stablecoins, tokenized equities, and real-world assets. According to Galaxy, Solana's future potential will depend largely on the ability to use these assets in lending, collateralization, margin, and yield — not just issuance or trading. DeFiLlama's data on Solana indicates a strong DeFi presence on the platform.

The timing also coincides with the Agave 4.2 upgrade phase. As Cryptopolitan previously reported, the phased cost-reduction plan was expected to deliver savings of roughly 90% and cut processing time from 500 to 200 milliseconds, benefiting stablecoin issuers, wallet providers, and payment systems.

RPC operators have a week to update

V1 is opt-in, so Legacy and V0 transactions continue to work. The open question is whether infrastructure reading V1 traffic is ready.

Anza has required RPC providers to upgrade to Agave v4.2.2 or v4.3.0-beta.3. The Helius Agave 4.2 migration checklist warns that RPC consumers that do not declare V1 compliance can experience call failures, such as getBlock, when a V1 transaction is involved.

The rollout began with local testing of V1 on August 24, followed by confirmation of the September 9 mainnet date on August 29. V1 was enabled on testnet on September 1 at epoch 1025, with mainnet activation scheduled for September 9.

The latest testnet run serves as the final preparatory step for RPC providers, indexers, wallets, SDKs, and analytics platforms ahead of the mainnet launch.