Newsroom
8 September, 2026 / News / AI / Tags: bytes, transaction, solana, format, atomic

Network upgrade to Transaction v1 format lifts the data limit from 1,232 bytes to 4,096 bytes, enabling more complex atomic operations
Solana is scheduled to activate its Transaction v1 format on mainnet on September 9, raising the maximum size of a single transaction from 1,232 bytes to 4,096 bytes. The change multiplies available capacity by roughly 3.3 times and is intended to let developers pack larger and more intricate operations into one atomic transaction.
The previous 1,232-byte ceiling originated from networking constraints tied to the minimum IPv6 maximum transmission unit after accounting for overhead. Once Solana adopted the QUIC transport protocol, that fixed packet-size restriction no longer applied. The new 4,096-byte limit was selected in part because it aligns with a common four-kilobyte memory page size used by validator hardware.
Two Solana Improvement Documents define the upgrade. SIMD-0296 establishes the higher size ceiling, while SIMD-0385 specifies the Transaction v1 message format. Both proposals were co-authored by Solana Foundation Vice President of Technology Jacob Creech and engineer Andrew Fitzgerald. The format has already been active on testnet, giving developers time to experiment before the mainnet rollout.
Under the old limit, many advanced operations had to be split across multiple transactions. That approach introduced complexity and the risk that one step would succeed while another failed. Transaction v1 allows more of those operations to fit inside a single atomic unit, so either every instruction succeeds or the entire transaction fails.
The Solana Foundation has identified several workloads expected to benefit. These include large multisignature operations, BLS signatures, Winternitz one-time signatures, confidential transfers, and zero-knowledge proofs. Developers working with rollups or systems that move data between zero-knowledge roots may also gain from the expanded space. Co-founder Anatoly Yakovenko specifically noted the ability to move data atomically through two zk roots in one transaction.
The upgrade does not raise the existing cap of 64 referenced accounts or 64 instructions per transaction. Applications can carry more data and signatures, but they remain bound by those account and instruction limits.
Transaction v1 is optional. Legacy and v0 formats continue to operate under the previous 1,232-byte limit, so wallets and applications that do not need the extra capacity require no immediate changes. Users do not need to migrate tokens or take any action for the activation itself.
Services that read blocks and transactions face different requirements. Remote procedure call providers, indexers, explorers, and analytics platforms must support the new version and set their maximum supported transaction version to one. Otherwise, requests that encounter a v1 transaction may fail. Resource limits and priority-fee settings are stored differently in the new format, so outdated software could display incorrect fee or compute information.
In the v1 format, address lookup tables are removed and full 32-byte account addresses are stored directly inside the transaction. Resource limits appear in a dedicated configuration mask rather than as separate ComputeBudget instructions. Developers adopting the format must explicitly set compute-unit and loaded-data limits, which default to zero.
| Feature | Previous Limit | New Limit (v1) |
|---|---|---|
| Maximum transaction size | 1,232 bytes | 4,096 bytes |
| Accounts per transaction | 64 | 64 |
| Instructions per transaction | 64 | 64 |
| Required format | Legacy or v0 | v1 (optional) |
Larger transactions will consume additional bandwidth. Priority fees remain the primary mechanism for securing timely inclusion when demand is high; no separate fee based on transaction size is being introduced. The official roadmap continues to list mainnet activation as pending, so the September 9 target remains subject to possible adjustment, although testnet and related environments have already enabled the feature.
The change stands apart from other ongoing Solana developments such as rent reductions, shorter slot times, and the Alpenglow consensus redesign. Once activated, the expanded capacity will be available for production use by any developer who chooses the v1 format.









