- Solana activates Transaction V1 on mainnet on September 9.
- The new format raises the maximum transaction size from 1,232 bytes to 4,096 bytes to fit a 4 KiB validator memory page.
- RPC providers, indexers, and wallets that skip upgrading to Agave v4.2 risk errors or silently wrong fee data.
Solana is set to triple the amount of data a single transaction can carry on September 9. This new 4,096-byte ceiling fits in a single 4 KiB memory page of validator hardware, per the SIMD-0296 proposal on GitHub.
Workloads that require multiple transactions now take one atomic call to complete.
QUIC made the 1,232-byte cap pointless
The original limit of Solana was a networking caution. The network operated with a 1,280-byte IPv6 MTU.
That left 1,232 bytes for a transaction payload after protocol overhead, the authors of SIMD-0296 write. That makes sense when every message had to pass through the MTU without fragmentation.
Solana switched to QUIC as its standard way to handle transactions in 2022. RFC 9000 doesn’t set a maximum stream size, so larger payloads can go through without any problems at the network level.
The limit of 1,232 bytes had turned into a rule that had no technical basis.
The two documents were penned by Anza engineers Jacob Creech and Andrew Fitzgerald. SIMD-0296 raises the size limit.
A companion, SIMD-0385, defines the v1 message format, which contains the extra bytes. The pair solves a constraint developers have been sidestepping since the chain launched.
The proposal prefers 4,096 bytes over the largest size allowed by QUIC so that a transaction can fit into a single standard 4 KiB page of validator memory. No transaction ever crosses a page boundary.
The memory management per transaction is cheap. Each transaction is restricted to a single page.
To arrive at the 4,096-byte limit, Creech and Fitzgerald analyzed how developers used Jito bundles to circumvent the old restrictions:
- 50% of submitted bundles were 2,048 bytes or smaller.
- 65% was under 6,144 bytes.
- 100% remained under 9,216 bytes.
A 4,096-byte ceiling covers the vast majority of these multi-transaction workloads in a single call while staying within validator hardware page constraints.
Unprepared RPC calls now throw error -32015 on Solana
The extra capacity enables workloads that exceed the 1,232-byte limit.
Zero-knowledge proofs, such as those used in Token Extensions’ Confidential Transfers, generated payloads that exceeded the 1,232-byte limit.
To solve this problem, developers chained multiple calls or forgo atomic encrypted transfers. The new limit of 4,096 bytes accommodates zero-knowledge proofs in one transaction.
BLS signature aggregation and large multisig configurations also benefit from this change. SIMD-0296 cites nested multisig, the type of multisig used by institutional treasuries and DAOs via Squads, as one of the main drivers.
It also references Winternitz one-time signatures and on-chain BLS schemes that work without precompiles.
The format shuns the Address Lookup Tables, which v0 used to reference up to 64 accounts with short indexes. The tables add complexity for no payoff because now there are 64 inline 32-byte addresses, which only take up 2,048 bytes, well under the ceiling.
The 64-account limit for every transaction remains in the Solana network. Heavy-account applications will still reach the limit even with the byte budget issue solved.
Jito bundles let devs merge up to five transactions into an all-or-nothing sequence to solve the byte limitation issue.
Transaction v1 achieves the same atomic outcome in a single transaction. It brings native atomicity directly to the base layer.
V1 is opt-in for senders, so legacy and v0 transactions continue to work. The Solana Foundation’s migration notes say it’s a breaking change for infrastructure that reads blocks
If data tools and block explorers are not updated for Solana’s new version, they will completely freeze or spit out errors.
When an app tries to read a v1 transaction or block without the new version parameter, Solana’s servers reject the request with a system error code -32015.
Tools that continuously stream live blocks will hit a new v1 transaction, receive a completely blank response, and stall there.
Indexers, or tools that record transaction data, show zero priority fees for new transactions because they are looking in the wrong place.
They used to read these fees from a special list inside the transaction. In the new version, that information is kept in its own dedicated summary box.
Anza is requiring RPC providers to upgrade to Agave v4.2. Helius has issued a migration checklist detailing the work.
Transaction v1 was activated on the Solana testnet during epoch 1025 on September 1. Anza officially scheduled the mainnet deployment for September 9.
The smartest crypto minds already read our newsletter. Want in? Join them.
Disclaimer. The information provided is not trading advice. Cryptopolitan.com holds no liability for any investments made based on the information provided on this page. We strongly recommend independent research and/or consultation with a qualified professional before making any investment decisions.
Randa Moses
Randa Moses is an editor and reporter at Cryptopolitan covering tech, AI, robotics, crypto, scams, and hacks. She has worked in the crypto space since 2017. She held roles at Forward Protocol, AmaZix, and Cryptosomniac. Randa holds a degree in Electrical and Electronics Engineering from the University of Bradford.
