Transaction V1 Activates on Solana Testnet at Epoch 1025, Tripling Max Transaction Size

Anza activated Transaction V1 on Solana testnet at epoch 1025 on September 1, expanding the maximum serialized transaction size from 1,232 bytes to 4,096 bytes, a 3.3x increase that brings ZK proofs, large multisigs, and confidential transfers into the realm of single atomic operations on Solana SOL$101.86+2.3%.

Anza's official account confirmed the activation at 22:19 UTC on September 1. Less than 19 hours later, Anza CEO Brennan Watt linked to an actual large transaction on the Solana Explorer testnet, writing: "ATTENTION: large transactions have hit the testnet."

Mainnet activation is scheduled for September 9. The testnet run is the final proving ground before that date.

What SIMD-0385 Changes in a Single Epoch

Two proposals work in tandem. SIMD-0296 sets the new 4,096-byte hard limit. SIMD-0385 defines the V1 message format itself: a 0x81 version byte and a config mask that replaces how transactions signal resource requirements.

Under Legacy and V0, developers used compute budget instructions to set priority fees. V1 moves those requests into the transaction header directly, which reduces overhead and frees instruction space for actual program logic. That shift also makes transaction parsing more predictable for indexers and RPC providers.

Use Cases That Required Multiple Transactions Now Fit in One

The 1,232-byte ceiling created a hard constraint for cryptographic workloads. Zero-knowledge proofs, BLS signature aggregation, and confidential transfers (which encrypt amounts using ZK cryptography) were routinely fragmented across multiple transactions to fit, with each fragment carrying its own fee and landing risk.

At 4,096 bytes, those operations fit in a single transaction. For large multisig setups, which can require 20 to 30 signers, the size expansion means the signature set no longer forces a split. Cross-chain bridge attestations, which typically carry large witness data, also benefit.

Address Lookup Tables, the mechanism V0 added to compress account lists, are not supported in V1. With 4,096 bytes of raw capacity, they are no longer necessary for the same use cases.

QuickNode's Solana team summarized the practical shift: "No need for address lookup tables when you need a lot of accounts, priority fees are part of the transaction, and less need for bundling transactions together now you can fit more instructions in."

Opt-In Format: Legacy and V0 Remain Supported

V1 is opt-in. Applications using the original Legacy format or V0 continue to work unchanged and can move to V1 on their own schedule. Anza stated that "existing apps continue working as is, and can adopt V1 on their own timeline."

The three formats now coexist: Legacy (the original), V0 (which added address lookup tables in 2022), and V1.

RPC Operators Must Update Before Mainnet

RPC operators that have not yet upgraded need to update to Agave v4.2.2 or v4.3.0-beta.3 before mainnet activation on September 9 to serve the larger transaction size. Nodes running older versions will not correctly handle V1 transactions.

Wallet providers, block explorers, indexers, SDKs, and analytics platforms are also in scope. A V1 transaction served to a client built against the old 1,232-byte schema will appear incomplete or malformed.

Testnet as the Last Gate Before September 9

This activation is the third step in a staged rollout. Local testing via Solana CLI v4.2+ and Surfpool opened on August 24, giving developers a sandboxed environment. The mainnet date was set publicly on August 29. Testnet activation at epoch 1025 on September 1 is the live network validation before mainnet follows on September 9.

The week between now and mainnet is the window for tooling updates to land. The Anza CEO's confirmation of a live testnet transaction on the Solana Explorer signals the format is functioning as specified under real network conditions.