Solana Expands Its Transaction Capacity
Solana is introducing a major change to the amount of data that can be carried by a single transaction. Its new Transaction V1 format raises the transaction size limit from 1,232 bytes to 4,096 bytes, giving developers more room to build applications that previously had to split operations across multiple transactions.
According to the Solana Foundation’s upgrade documentation, the mainnet activation is scheduled for the start of epoch 1035, at approximately 01:20 UTC on September 15, 2026. The upgrade increases the available space by roughly 3.3 times while keeping older transaction formats compatible.
The change is designed to address a long-standing limitation in Solana’s transaction architecture. The previous 1,232-byte ceiling could make transactions containing numerous instructions, signatures or cryptographic proofs difficult to fit into a single atomic operation.
What Transaction V1 Changes
Solana’s Transaction V1 format is closely connected to SIMD-0296, the proposal that increases the transaction-size limit, and SIMD-0385, which defines the new transaction format. The official SIMD-0385 specification sets the maximum transaction size at 4,096 bytes, compared with 1,232 bytes for the previous formats.
The larger capacity does not mean Solana is suddenly processing more transactions per second. Instead, it increases the amount of information that can be included in one transaction. That distinction is important: the upgrade primarily gives developers more space for instructions, addresses, signatures and other transaction data.
The new format also changes how some transaction configuration is handled. Compute-unit limits, loaded-account data limits, heap size and priority-fee information can be placed in the transaction configuration rather than being supplied through separate ComputeBudget instructions. This allows the network to read important configuration information more directly.
More Room for Complex Blockchain Applications
The previous transaction limit created practical problems for applications that needed to fit substantial amounts of data into a single atomic transaction.
The SIMD-0296 proposal identifies several potential use cases, including zero-knowledge proofs, large multisignature transactions, nested multisigs used by corporate applications, Winternitz signatures and BLS-based cryptographic schemes.
Zero-knowledge applications are particularly relevant because cryptographic proofs can require significant transaction space. Solana's official transaction examples also demonstrate that a Token-2022 confidential transfer can require multiple instructions and cryptographic proofs that previously could not fit into a single 1,232-byte transaction. Under V1, an example confidential transfer can fit within the new 4,096-byte ceiling.
Why Atomic Transactions Matter
Developers have historically used different workarounds when an operation was too large for a single Solana transaction. One approach involved splitting an operation across multiple transactions. Another involved mechanisms such as bundles.
The problem is that separate transactions do not necessarily provide the same protocol-level atomicity as one transaction. A single transaction can succeed or fail as one unit, whereas a sequence of separate transactions may require additional coordination.
The larger V1 format therefore gives developers the option to put more operations into a single transaction. The Solana Foundation says this can help workloads that previously depended on techniques such as address lookup tables or bundles to overcome transaction-size constraints.
Solana's Approach Differs From Ethereum
The upgrade also highlights a fundamental difference between Solana and Ethereum transaction design.
Ethereum transactions contain fields such as input data and a gas limit, with the amount of computation constrained by gas rather than by a fixed 1,232-byte transaction ceiling. Ethereum's current protocol also has a 16,777,216-gas per-transaction cap, introduced through EIP-7825, meaning Ethereum does impose important computational limits even though its transaction model is different from Solana's byte-size restriction.
On Solana, the new 4,096-byte ceiling specifically targets the amount of data that can be carried by an individual transaction. Developers can therefore use additional space for larger proofs, multisignature structures and more complicated instruction sets without changing the basic transaction model.
Developers and Infrastructure Must Prepare
The upgrade is not completely invisible to wallets, RPC providers and blockchain data services. While legacy and V0 transactions remain supported, applications that want to create V1 transactions must explicitly support the new format.
More importantly, infrastructure that reads or indexes Solana transactions needs to recognize V1 transactions. The Solana Foundation warns that applications reading transactions or blocks must support transaction version 1. Indexers also need to obtain certain configuration values from the new transaction structure rather than relying on the older ComputeBudget instruction approach.
For example, the Foundation recommends that transaction readers advertise support for V1 by using maxSupportedTransactionVersion: 1. RPC and indexing infrastructure also needs appropriate software versions to avoid incorrectly interpreting V1 transactions.
Older Solana Transactions Still Work
The introduction of Transaction V1 does not make existing Solana transactions obsolete. Legacy and V0 formats continue to function, meaning applications do not have to immediately migrate simply because the new format is available.
However, applications that want to take advantage of the 4,096-byte limit will need to update their transaction-building infrastructure. The official documentation lists support for V1 across newer versions of Solana development libraries, including Solana Kit, newer Web3.js releases and Solana Rust crates.
This creates a gradual transition rather than a complete replacement of the existing transaction system. Developers can continue using older formats while upgrading applications that benefit from the additional capacity.
What the Upgrade Means for Solana
Solana's Transaction V1 upgrade addresses a specific technical bottleneck rather than simply increasing the network's headline transaction-per-second capacity.
Moving from 1,232 bytes to 4,096 bytes gives developers roughly 3.3 times more transaction space. That can make it easier to build applications involving complex instructions, large multisignature structures and privacy-focused cryptography without breaking a workflow into multiple transactions.
The broader significance is that more sophisticated workloads can potentially be handled as individual atomic transactions. For developers, that means fewer compromises caused by transaction size. For wallets, RPC providers and indexing services, however, the upgrade also creates a new compatibility requirement: infrastructure must understand the V1 format as it becomes part of Solana's mainnet transaction environment.
