According to CoinDesk, Solana’s Transaction v1 was targeted for mainnet activation on Wednesday, September 9, 2026, with legacy and v0 transaction formats continuing alongside it. Transaction v1 would raise the maximum transaction size from 1,232 bytes to 4,096 bytes, a 3.3 times larger transaction envelope for applications whose data has exceeded the existing limit, including those using proofs or more elaborate signing data. The upgrade is defined by SIMD-0296 and implemented through the v1 format described in SIMD-0385, the Solana Foundation’s upgrade documentation says.
Transaction v1 raises Solana’s byte limit to 4,096
Under SIMD-0385, Transaction v1 raises the maximum serialized transaction size from 1,232 bytes to 4,096 bytes, more than three times the prior limit.
CoinDesk reported that legacy transactions and v0 transactions would continue to work alongside v1, which is an additional format rather than an immediate replacement. The format also creates more room in a single transaction for data-heavy components; the published proposal retains other numerical limits that shape transaction construction.
CoinDesk reported September 9 as a target date for activation, rather than confirmation that activation had occurred.
Proofs and complex signing schemes are the intended users
Solana identifies zero-knowledge proofs and confidential transfers among the workloads expected to benefit from the larger envelope. Such applications can require transaction space for proof-related data that may not fit comfortably under the previous cap.
The documentation also names large or nested multisigs, Winternitz signatures and BLS signatures as use cases. Those examples point to a narrow but consequential use of the added capacity: accommodating more complex authorization and cryptographic data without treating the upgrade as a blanket increase in every transaction resource.
That framing separates Transaction v1 from a simple throughput claim. The published materials describe an expansion of the amount of serialized data a transaction can carry; they do not say that all transactions will become larger or that every application needs to move to v1.
The larger envelope leaves signature, account and instruction caps intact
SIMD-0385 sets the v1 transaction cap at 4,096 bytes while retaining maximums of 12 signatures, 64 accounts and 64 instructions. Raising the byte limit therefore does not give a builder additional capacity when the separate signature, account or instruction limits are the constraint.
Unlike v0, v1 does not use address lookup tables, according to the proposal. The format consequently gives applications more room within the transaction’s overall byte limit while preserving several boundaries around its contents.
The clearest benefit is for transactions constrained by total size, rather than those already blocked by the signature, account or instruction caps.
RPC providers and transaction readers need v1 support
The implementation work extends beyond applications that construct transactions. RPC providers, indexers, block explorers and other systems that read transaction data need to recognize the v1 format, Solana’s documentation states. Without that support, tools may not correctly retrieve or interpret v1 transactions even if the network accepts them.
For RPC requests, the documentation says clients should set maxSupportedTransactionVersion to 1. This setting signals that a client can handle the new transaction version when requesting transaction information.
Transaction v1 also moves priority-fee configuration into the transaction header. That makes the upgrade relevant to wallet-adjacent services and transaction-processing software, not only to protocols building proof-heavy or multisignature flows. With mainnet activation targeted for September 9, compatibility work across those readers is part of the deployment path described by Solana.
