Solana is targeting September 9 for Transaction v1, a new format that raises the maximum serialized transaction size from 1,232 bytes to 4,096 bytes.
Summary
- Solana plans to raise maximum transaction size from 1,232 bytes to 4,096 bytes Wednesday mainnet.
- Transaction v1 remains optional, while legacy and v0 formats continue operating under existing size limits.
- Applications reading blocks must support version one or risk errors when encountering the new format.
- V1 removes address lookup tables and stores resource limits directly within each transactions configuration metadata.
- Solanas official roadmap labels mainnet activation pending, making the September 9 schedule potentially changeable still.
The increase gives developers about 3.3 times more transaction space. Solanas official roadmap says the additional capacity can accommodate zero-knowledge proofs, large multisignature operations, batches and some onchain signature schemes.
Large operations previously had to be divided into several transactions when their instructions, signatures and account information exceeded the 1,232-byte ceiling. That process added complexity because one transaction could succeed while another step failed.
Transaction v1 could let developers combine more of those instructions into one atomic operation. Either every instruction succeeds or the entire transaction fails. The model could benefit trading routes, confidential transfers, cross-chain operations and applications processing complex cryptographic proofs.
The upgrade does not raise Solanas limit of 64 referenced accounts per transaction. Applications can include more data and instructions, but they cannot automatically interact with more accounts.
Solana to triple transaction size as apps get room for more complex trades
The Solana smart contract blockchain is targeting Wednesday to increase the maximum transaction size from 1,232 bytes to 4,096 bytes, giving developers more than three times as much room to fit…
You might also like:
Solana price holds $103 support despite bearish CMF
Existing Solana transactions will remain valid
Transaction v1 is optional. Wallets and applications can continue sending legacy and v0 transactions under the existing 1,232-byte limit. Users do not need to migrate tokens, exchange SOL or complete a claim before activation.
Developers must deliberately adopt the new format to access its larger capacity. The Solana documentation identifies three supported formats: legacy, v0 and v1. Each format organizes account addresses and resource limits differently.
The v0 format uses Address Lookup Tables, or ALTs, to represent account addresses through compressed one-byte indexes. V1 removes ALTs and places complete 32-byte account addresses directly inside the transaction.
This creates a trade-off. V1 provides a larger overall envelope, but applications that rely heavily on lookup tables may spend more bytes representing the same accounts. Solanas technical analysis found that 90% of sampled transactions would add fewer than 1,400 bytes when converted from v0 to v1.
Infrastructure providers must update their software
The main compatibility risk applies to services that read blocks and transactions. Remote procedure call providers must set their maximum supported transaction version to one. Otherwise, requests could fail when they encounter a v1 transaction.
Indexers, explorers and analytics services must also change how they retrieve resource limits. Legacy and v0 transactions place compute limits and priority-fee settings inside ComputeBudget instructions. V1 stores them in a dedicated transaction configuration.
Outdated services could therefore display incorrect information. For example, an explorer might show a zero priority fee even though the user paid one. Fee sponsors and applications that check transaction limits must read the new configuration rather than scan old-style instructions.
Applications sending v1 transactions must explicitly set compute-unit and loaded-data limits because both default to zero. Developers should test transaction construction, signing and decoding before moving production traffic to the format.
September 9 remains a targeted activation date
Solana Foundation Vice President of Technology Jacob Creech identified September 9 as the planned mainnet date. As crypto.news previously reported, the upgrade is included in Anzas Agave 4.2 rollout.
However, the official roadmap still labels the mainnet feature as “not activated.” It also says Anzas release schedule is “tentative and subject to change.” Testnet and devnet have already activated the feature, according to the latest Foundation status page.
The size increase comes from SIMD-0296, while SIMD-0385 defines the v1 format. Jacob Creech and Andrew Fitzgerald co-authored both proposals.
The 4,096-byte ceiling was selected partly because four kilobytes matches a common memory-page size used by validator hardware. Larger transactions will also consume additional bandwidth, although the upgrade introduces no separate fee charged per byte.
Transaction v1 remains separate from Solanas rent reductions, shorter slot targets and Alpenglow consensus redesign. In related coverage, crypto.news reported that Alpenglow targets approximately 150-millisecond finality, with October remaining a development target rather than a guaranteed activation date.
Read more:
Citi, DBS test instant U.S.-Singapore payments