Solana has enabled Transaction V1 on testnet, a change that increases the maximum serialized transaction size from 1,232 bytes to 4,096 bytes. The feature went live at testnet epoch 1025 on September 1 as part of a final rehearsal before a planned mainnet activation on September 9.

The upgrade is intended to let larger cryptographic, multisig, confidential-transfer and DeFi operations execute as one native atomic transaction, instead of being broken into several calls or assembled through external bundle mechanisms. Ecosystem services now have a short period to verify that they support the new format before the target mainnet date.

Bigger transactions, fewer split operations

The central change in Transaction V1 is simple: Solana transactions can carry much more data. By expanding the serialized transaction limit to 4,096 bytes, the network can fit workloads that previously ran into space constraints when developers tried to package them into a single on-chain action.

According to the rollout details, that extra capacity can accommodate zero-knowledge proofs, larger multisig transactions and other signature schemes within one transaction. The stated goal is to reduce the need for multiple signatures, avoid waiting through a chain of confirmations, and preserve the all-or-nothing behavior of a single native transaction.

Protocol changes behind V1

Two Solana improvement proposals underpin the update. SIMD-0296 raises the transaction size ceiling, while SIMD-0385 defines the V1 message format and shifts transaction configuration into the message itself.

V1 also changes how transactions are structured compared with V0. It removes the use of Address Lookup Tables and places addresses inline, a design that Anza says should make validator input handling simpler than under V0, where account-heavy transactions consumed additional bytes.

Why developers used bundles before

Before this change, some developers worked around Solana’s older size limits by using Jito bundles. Those bundles can contain up to five transactions that are processed sequentially on an all-or-nothing basis, but they run through Jito’s block-engine and compete for validator tips.

Transaction V1 is meant to keep that atomic behavior inside the base protocol. For DeFi applications, that could simplify complex swap routes, proofs and other multi-step actions by allowing them to succeed or fail as one native Solana transaction rather than depending on a bundle of separate transactions.

Limits remain and support is optional

The added space does not remove every constraint. Solana’s maximum of 64 accounts per transaction remains in place, which means applications with especially heavy account requirements may still run into limits even after V1 is available.

The new format is opt-in, and Legacy and V0 transactions will continue to work. Even so, infrastructure providers need to prepare for V1 if they want to handle those transactions reliably. The migration guidance says RPC operators need to move to Agave v4.2.2 or v4.3.0-beta.3, and warns that users who do not explicitly indicate V1 support may see call failures when a V1 transaction is involved.

Testnet rehearsal before mainnet

The rollout followed local verification on August 24 and confirmation of the September 9 mainnet target on August 29. Testnet activation then took place on September 1. Less than a day later, Anza’s Brennan Watt pointed to a large transaction on the testnet explorer with the note that large transactions had reached the network.

For now, the next confirmed step is the planned September 9 activation on mainnet. Until then, RPC providers, indexers, wallets, SDKs and analytics platforms have a narrow window to test compatibility with Transaction V1 before the feature is expected to reach production.

Source: Cryptopolitan