Solana triples transaction size to 4,096 bytes with mainnet V1 launch

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.