Solana triples transaction capacity with v1 upgrade

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.

The increase gives developers about 3.3 times more transaction space. Solana’s 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 Solana’s limit of 64 referenced accounts per transaction. Applications can include more data and instructions, but they cannot automatically interact with more accounts.

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. Solana’s 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 Anza’s Agave 4.2 rollout.

However, the official roadmap still labels the mainnet 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, 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 Solana’s 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.