Solana To More Than Triple Maximum Transaction Size Wednesday

Solana is targeting Wednesday to raise its maximum transaction size from 1,232 bytes to 4,096 bytes, giving developers more than three times the room to fit instructions into a single operation. 

The upgrade, called Transaction v1, is already running on Solana’s test and development networks ahead of the planned mainnet activation. Existing transaction formats will keep working, but any software that reads Solana data must be updated to handle the new format correctly.

What The Larger Format Enables

Operations that previously required splitting across several transactions can increasingly fit into one under Transaction v1. That includes large cryptographic proofs, payments that require many separate approvals, and some confidential transfer operations that need more space than the old format allowed.

Developers are not required to adopt the new format. Wallets and applications that do not need the extra space can continue using the existing transaction structure without any changes on their end.

A Structural Limit Solana Has Carried Since Its Early Design

The 1,232-byte cap traces back to Solana’s original networking design, in which each transaction had to fit inside a roughly 1,280-byte internet data packet. Solana changed how it transmits transaction traffic in 2022, a shift that made the original byte ceiling less technically necessary even though the limit itself remained in place until now.

The new format stops at 4,096 bytes because four kilobytes is a standard memory-page size used by validator hardware. Pushing the limit meaningfully higher could force a single transaction to span multiple memory pages, adding processing cost for the machines that run the network.

The change positions Solana to close a gap with Ethereum, which has no rigid protocol-level size limit and lets developers run data-dense operations in one transaction simply by paying a higher fee. 

Solana’s transactions have remained faster and cheaper on average, but the fixed byte cap had kept certain complex operations out of reach in a single transaction regardless of what a user was willing to pay.

Software That Reads Solana Must Update First

The larger technical change falls on services that fetch and interpret Solana blocks and transactions rather than on end users. Those services need to be updated to recognize Transaction v1, or requests involving the new format can fail outright.

Some of that software will also need to change where it looks for priority-fee data. A priority fee is an optional payment users can add to have a transaction processed faster, and Transaction v1 stores that fee information in a different location than the old format. Software that has not been updated could display a fee of zero even when a user actually paid one.

Wallets, block explorers and trading applications typically rely on this back-end software to show users what happened on-chain. If that underlying software has not been updated, the effects could surface as incorrect data on a user’s screen rather than as a problem visible to Solana’s core protocol.

Bandwidth And Fee Implications

Larger transactions will consume more network bandwidth than the current format allows. Developers anticipate that users may need to offer higher priority fees during periods when large transactions are competing for limited block space, though the upgrade itself does not add any new per-byte fee.

The change is defined across two separate improvement proposals, SIMD-0296 and SIMD-0385, co-authored by Jacob Creech and Andrew Fitzgerald. It is unrelated to Solana’s recent governance vote that changed the rate at which new SOL is created and removed from supply through network fees, a separate decision the network finalized in late August.