Solana Transaction v1 targets September 9 for mainnet. The new format raises the maximum serialized transaction size.
The limit increases from 1,232 bytes to 4,096 bytes. Developers get about 3.3 times more transaction space.
Why Solana Transaction v1 matters
The additional capacity can accommodate zero-knowledge proofs. It also supports large multisignature operations and batches. Some onchain signature schemes benefit from this upgrade.
Large operations previously had to be divided into several transactions. This happened when instructions exceeded the 1,232-byte ceiling. That process added complexity to operations. One transaction could succeed while another step failed.
Transaction v1 could let developers combine more instructions. They can combine them into one atomic operation. Either every instruction succeeds or the entire transaction fails. The model benefits trading routes and confidential transfers. Cross-chain operations and complex cryptographic proofs also gain advantages.
Nevertheless, the upgrade does not raise Solana’s account limit. The limit remains 64 referenced accounts per transaction. Applications can include more data and instructions. They cannot automatically interact with more accounts.
Existing Solana transactions remain valid
Transaction v1 is optional. Wallets and applications can continue sending legacy transactions. They can also send v0 transactions under the existing limit. Users do not need to migrate tokens before activation. They also do not need to exchange SOL or complete a claim.
Developers must deliberately adopt the new format. Only then can they access its larger capacity. The Solana documentation identifies three supported formats. These are legacy, v0, and v1 formats. Each format organizes account addresses differently.
The v0 format uses Address Lookup Tables (ALTs). These represent account addresses through compressed one-byte indexes. V1 removes ALTs completely. It places complete 32-byte account addresses directly inside the transaction.
This creates a trade-off. V1 provides a larger overall envelope. Nevertheless, applications that rely heavily on lookup tables may spend more bytes. Solana’s technical analysis found that 90% of sampled transactions would add fewer than 1,400 bytes. This applies when converted from v0 to v1.
Infrastructure providers must update their software
The main compatibility risk applies to services that read blocks. Remote procedure call providers must set their maximum supported version to one. Otherwise, requests could fail when they encounter a v1 transaction.
Indexers, explorers, and analytics services must also change. They must update how they retrieve resource limits. Legacy and v0 transactions place compute limits inside ComputeBudget instructions. V1 stores them in a dedicated transaction configuration.
Outdated services could display incorrect information. For example, an explorer might show a zero priority fee. The user may have paid one nevertheless. Fee sponsors and applications must read the new configuration. They must stop scanning old-style instructions.
Applications sending v1 transactions must set compute-unit limits. They must also set loaded-data limits because both default to zero. Developers should test transaction construction and signing. They should also test decoding before moving production traffic.
September 9 remains a targeted activation date
Solana Foundation Vice President Jacob Creech identified September 9 as the planned date. As previously reported, the upgrade is included in Anza’s Agave 4.2 rollout.
Nevertheless, the official roadmap still labels the feature as “not activated.” It also says Anza’s release schedule is “tentative and subject to change.” Testnet and devnet have already activated the feature. The latest Foundation status page confirms this.
The size increase comes from SIMD-0296. SIMD-0385 defines the v1 format. Jacob Creech and Andrew Fitzgerald co-authored both proposals.
Solana selected the 4,096-byte ceiling partly because four kilobytes matches common memory-page size. Validator hardware uses this size. Larger transactions will also consume additional bandwidth. The upgrade introduces no separate fee charged per byte nevertheless.
Transaction v1 remains separate from Solana’s rent reductions. It also differs from shorter slot targets and Alpenglow consensus redesign. Alpenglow targets approximately 150-millisecond finality. October remains a development target rather than a guaranteed activation date.