Solana to triple transaction size as apps get room for more complex trades

A Transaction v1 feature activates Wednesday, allowing complex proofs and large multisig operations to fit in one transaction while forcing services that read Solana to update.

— Solana plans to raise its maximum transaction size Wednesday from 1,232 bytes to 4,096 bytes, allowing complex operations that once required several transactions to fit into one.

— Existing transaction formats will remain supported, but services that read Solana data must be updated to recognize Transaction v1 and correctly display priority fees.

— Larger transactions will consume more network bandwidth and may require higher priority fees during periods of competition, though the upgrade adds no new per-byte fee.

The Solana smart contract blockchain is targeting Wednesday to increase the maximum transaction size from 1,232 bytes to 4,096 bytes, giving developers more than three times as much room to fit instructions into a single operation.

Operations that previously had to be split across several transactions can increasingly be handled in a single transaction under Transaction v1. That includes large cryptographic proofs, payments requiring many approvals and some confidential transfers.

The new format is already running on Solana’s test and development networks. Existing transaction formats will continue to work, so wallets and apps do not have to switch to v1 unless they need the extra space.

It could help Solana sharpen its edge over its rival Ethereum. While Solana has always been faster and cheaper, it previously fell behind in one key area: its transactions were strictly hard-capped at 1,232 bytes. Ethereum, by contrast, has no rigid protocol size limit, allowing developers to execute massive, data-dense applications in a single operation simply by paying a higher transaction fee.

By more than tripling this ceiling to 4,096 bytes, Solana is looking to eliminate this structural bottleneck.

The bigger change is for software that reads Solana. Services that fetch blocks and transactions need to be updated to recognize v1. If they are not, requests can fail when they encounter the new format.

Some software also needs to change where it looks for priority-fee information. A priority fee is an optional extra payment that users can make to have a transaction processed faster. V1 stores that information elsewhere, so outdated software can show a fee of zero even when one was paid.

Wallets, explorers, and trading apps often rely on these services to display what happened onchain, meaning that bad data behind the scenes can turn into bad data on a user’s screen.

Larger transactions also use more network bandwidth. Developers expect users may need to offer higher-priority fees when larger transactions are competing for space, although the upgrade does not introduce a new fee per byte.

The old 1,232-byte limit comes from Solana’s original networking design, in which each transaction had to fit within a roughly 1,280-byte internet data packet. Solana changed how transaction traffic is transmitted in 2022, making that old ceiling less necessary.

The new limit stops at 4,096 bytes because four kilobytes is a standard memory-page size used by validator hardware. Going much larger could force one transaction to span several pages and make it more expensive for the machines running Solana to process.

The change is defined in two proposals, SIMD-0296 and SIMD-0385, co-authored by Jacob Creech and Andrew Fitzgerald, and is wholly separate from the recent Solana governance votes that changed how quickly new SOL was created and removed from supply through fees earned from network activities.

Anvil is a shared on-chain collateral layer built on a programmable letter of credit: reserve assets as a guarantee -no loan, no interest, keep custody & yield.

Why it matters:

Anvil is a shared on-chain collateral layer built on a programmable letter of credit: reserve assets as a guarantee -no loan, no interest, keep custody & yield.