Solana will officially launch Transaction v1 on mainnet on Sept. 9 (Wednesday), expanding the maximum Trade size from 1,232 bytes to 4,096 bytes—more than three times the previous limit. The upgrade is defined by two Solana improvement proposals: SIMD-0296 (larger Trades) and SIMD-0385 (the Transaction v1 format).
Technical Specifications of Transaction v1
Transaction v1 is defined jointly by two Solana improvement proposals: SIMD-0296 specifies the larger Trade limit, while SIMD-0385 defines the Transaction v1 format. Both proposals were co-authored by Jacob Creech and Andrew Fitzgerald. The new feature has been running stably on the testnet and devnet for some time and officially launched on mainnet on Sept. 9, 2026.
Transaction v1 uses a backward-compatible design, and the existing v0 format remains valid. Wallets and applications will adopt the v1 format only when they need additional Trade space, with no mandatory migration required.
Three Trade Scenarios That Benefit Most Directly from Transaction v1
After increasing the capacity from 1,232 bytes to 4,096 bytes, the following three types of Trades will benefit most directly:
Large cryptographic proofs: Verification data such as ZK proofs previously often had to be split across multiple Trades because it exceeded the 1,232-byte limit. Transaction v1 allows complete ZK verification data to be packaged and sent in a single Trade.
Multi-Signature approval processes: Fund transfers requiring approval from multiple signers, such as corporate treasury transactions or DAO proposals, use space for each Signature. v1 enables Multi-Signature approval processes to be completed within a single Trade.
Confidential transfers: Certain privacy-focused Trade mechanisms require additional cryptographic wrapping, while the previous capacity was insufficient, causing Trades to fail or reducing efficiency. The 4,096-byte limit provides ample capacity for these operations.
Why the 4,096-Byte Limit Was Set
The 4,096-byte (4KB) limit was set with hardware considerations in mind: it is the standard memory page size used by Validator nodes. If a single Trade spans multiple memory pages, processing costs increase significantly, which is unfavorable for maintaining Solana’s high TPS (Trades per second). The 4KB limit therefore represents a balance between expanding capacity and maintaining network performance.
The old 1,232-byte limit originated from Solana’s early network design, in which each Trade had to fit within an IP packet of approximately 1,280 bytes. In 2022, Solana adjusted how Trade traffic was transmitted, making that hard limit no longer necessary. The launch of Transaction v1 formally removes this historical design limitation.
Required Updates for RPC Nodes and Data-Reading Services
Transaction v1 has a greater impact on services that read on-chain data than on those that submit Trades. All services that fetch block and Trade data—including RPC nodes, on-chain data providers, and wallet backends—must update their code. Otherwise, they will return an error when they encounter a Trade in the v1 format.
Another specific impact concerns the location of the Priority Fee field: v1 stores Priority Fee information in a different field from v0. As a result, older software reading v1 Trades will display “zero fee” even when users have actually paid an acceleration fee. If wallet interfaces, blockchain explorers, and Trade apps are not updated, users will see inaccurate fee information.
Capacity Comparison with Ethereum
From a protocol design perspective, Ethereum has no protocol-level Trade size limit. Developers can execute data-intensive operations within a single Trade as long as they pay higher Gas fees. In the past, Solana had significant limitations on “how many instructions a single Trade could accommodate.” After Transaction v1 raises the limit to 4,096 bytes, the gap between the two chains is reduced, but 4,096 bytes is still not a large capacity for Ethereum L1. A complex DeFi portfolio Trade on Ethereum, such as multi-pool arbitrage or multi-asset borrowing and repayment, often exceeds this size.
The practical technical significance for the Solana ecosystem is the elimination of Developer workarounds. When operations previously had to be split across multiple Trades, Developers had to manage cross-Trade state dependencies and failure rollback issues. Transaction v1 allows complex logic to be completed in a single atomic operation, bringing it closer to traditional programming patterns.
Frequently Asked Questions
What is the launch date, maximum capacity change, and defining proposals for Solana Transaction v1?
Solana Transaction v1 launched on mainnet on Sept. 9, 2026 (Wednesday), expanding the maximum Trade size from 1,232 bytes to 4,096 bytes—more than three times the previous limit. The upgrade was defined by the two proposals, SIMD-0296 and SIMD-0385, and co-authored by Jacob Creech and Andrew Fitzgerald. It had previously been running stably on the testnet and devnet.
Why was the 4,096-byte limit set at this figure rather than higher?
4,096 bytes is the standard memory page size used by Validator nodes. If a single Trade spans multiple memory pages, processing costs increase significantly, which is unfavorable for maintaining Solana’s high TPS. The 4KB limit represents a balance between expanding capacity and maintaining network performance.
How do RPC nodes and data-reading services need to be updated, and what is the specific impact of the Priority Fee field change?
All services that fetch block and Trade data must update their code. Otherwise, they will return an error when they encounter v1 Trades. The Priority Fee field is located differently in v1 than in v0, so older software will display “zero fee” when reading v1 Trades, even if users have paid an acceleration fee. Wallets and blockchain explorers that are not updated will display inaccurate fee information.
