Solana initiated Transaction V1 on its testnet on September 1, with a scheduled mainnet launch set for September 9. The upgrade expands the maximum transaction size from 1,232 bytes to 4,096 bytes—a 3.3-fold increase—allowing cryptographic and DeFi workloads previously requiring multiple transactions to execute in a single atomic operation.
The expansion addresses a constraint that forced developers to fragment complex operations across separate transactions. By consolidating these operations, V1 reduces signature costs, eliminates the need to wait for chains of confirmations, and enables previously unfeasible approaches including zero-knowledge proofs, large multisig transactions, and various signature schemes.
Technical Implementation
Two core proposals drive the upgrade. SIMD-0296 increases the transaction size limit, while SIMD-0385 defines the V1 message format and moves transaction configuration from individual instructions into the message itself. This restructuring allows validators to identify resource needs without searching through instruction lists.
V1 also eliminates Address Lookup Tables used in prior versions, instead placing addresses inline. This simplifies validator processing for applications with heavy account usage, though the protocol's maximum account limit of 64 remains unchanged.
Advantages Over Bundled Transactions
Previously, developers circumvented size constraints using Jito bundles, which can include up to five transactions processed on an all-or-nothing basis. However, bundles operate within Jito's block-engine and lack protocol-level atomicity. V1 transactions, by contrast, are native Solana transactions carrying transaction-level atomicity guarantees, providing DeFi developers simpler execution for swap routes, proofs, and multistep operations that either fully succeed or fail as a single unit.
Infrastructure Readiness
V1 is opt-in, meaning Legacy and V0 transactions continue functioning. However, infrastructure must be updated to handle V1 traffic. Anza has required RPC providers to migrate to Agave v4.2.2 or v4.3.0-beta.3. RPC consumers that do not declare V1 compliance risk call failures such as getBlock errors when encountering V1 transactions. The testnet phase provides RPC providers, indexers, wallets, SDKs, and analytical platforms a final preparation window before mainnet activation.
Local testing began August 24, with the mainnet date confirmed August 29. Testnet activation occurred September 1 at epoch 1025.
