Solana Transaction Limit Increased to 4096 Bytes as v1 Format Activated

Solana's (SOL) maximum single transaction size has been increased from 1,232 bytes to 4,096 bytes. This allows complex operations like zero-knowledge (ZK) proofs and large multi-sig transactions to be processed as a single transaction rather than being split across multiple transactions. The Solana Foundation announced that the v1 transaction format became active at the start of mainnet epoch 1035, which was at approximately 10 a.m. KST on May 15.

The change has already been applied to testnets and devnets. The increase in maximum size—3.3 times larger than before—is implemented through SIMD-0296 and the new transaction structure defined by SIMD-0385. Previously, the 1,232-byte limit had constrained complex operations that required splitting into multiple transactions.

The v1 format enables a single transaction to include confidential transfers using ZK proofs, large multi-sig setups, batch transactions, Winternitz one-time signatures, and BLS signature schemes. The v1 format does not replace the legacy v0 format; both will coexist with existing applications continuing to use v0 if they don't require additional capacity. Applications needing 4,096-byte transactions must adopt the v1 format.

Wallets, applications, RPCs, indexers, and explorers that read Solana data must be able to interpret the new transaction structure. Transaction lookup apps should specify v1 support, while indexers need to read compute limits and fee information from the transactionConfig in the header instead of using the legacy ComputeBudget command.

The Solana Foundation previously reported that compatibility checks for RPCs and indexers were necessary ahead of this transition. With mainnet activation now complete, the challenge shifts to whether surrounding infrastructure can handle real transactions. The v1 format stores addresses directly within transactions rather than using address lookup tables, with SIMD-0385 limiting up to 64 addresses, 12 signatures, and 64 instructions per transaction.

Developers must choose the appropriate format based on their use case as both v0 and v1 will operate concurrently for the foreseeable future. The 4,096-byte limit aligns with the standard 4KiB memory page size of validator hardware to balance network transmission costs and buffer load. Transactions exceeding this limit would split into multiple QUIC frames, potentially requiring full retransmission if some frames are lost.

The Solana Foundation recommends that Jito-Solana validators and RPC operators update to version 4.2.2 or higher. Older RPC versions may display v1 transactions as v0 during storage. To ensure accurate processing of raw transaction data and fee information, system versions and parser support must be verified.

This upgrade does not directly alter Solana's throughput metrics or SOL price. The key improvement is enabling complex operations previously split across multiple transactions to now be handled atomically within a single transaction, with real-world adoption depending on v1 support from wallets, development tools, RPCs, and indexers.