Solana has activated Transaction V1 on mainnet, introducing a new transaction format that substantially expands the amount of data developers can process atomically. The upgrade raises the maximum transaction size from 1,232 bytes to 4,096 bytes, with the feature gate going live at the start of epoch 1035 on September 15 at approximately 01:00 UTC, according to the Solana Foundation’s official upgrade page.
The larger format is designed for workloads that previously struggled to fit inside Solana’s transaction ceiling. Zero-knowledge proofs, large multisignature operations, confidential transfers and other data-heavy workflows can now fit into a single atomic transaction in cases where they previously required multiple steps. Legacy and V0 transactions remain supported, while applications must explicitly opt into V1 to use the expanded format.
Transaction V1 Reworks Resource Limits and Account Encoding
Beyond transaction size, V1 substantially changes how resource requirements are represented. Compute unit limits, loaded-account data limits, heap size and priority fees move into a transaction-level configuration instead of being supplied through ComputeBudget instructions. In V1, those older ComputeBudget instructions become no-ops, making updated transaction construction and parsing essential for developers adopting the format.
The account model also changes. V1 transactions do not support Address Lookup Tables and instead allow as many as 64 account addresses to be included directly inside the transaction, taking advantage of the larger 4,096-byte envelope. The underlying SIMD-0385 specification caps V1 transactions at 64 addresses, 64 instructions and 12 signatures.
The 4,096-byte ceiling was not chosen arbitrarily. SIMD-0296 says the larger limit was selected partly with validator memory management and common page sizes in mind, while providing enough capacity to cover many transactions that previously required bundling or splitting. This creates more room for complex operations without changing the atomic execution guarantees of a single transaction.
Wallets, Indexers and RPC Providers Must Adapt
For infrastructure providers, V1 introduces compatibility requirements even when they do not intend to create the new transactions themselves. RPC clients reading blocks or transactions must support transaction version 1, while indexers need to obtain resource limits from transactionConfig rather than scanning for ComputeBudget instructions. Older integrations can otherwise fail to read V1 transactions or silently report incorrect compute-budget information.
Solana recommends Agave v4.2.2 or later for relevant RPC infrastructure, while updated SDK versions are required across TypeScript, Rust, Python and Go. Sending V1 transactions is optional, but reading them is now an ecosystem-wide compatibility issue because V1 transactions can already appear in mainnet blocks. Wallets must also explicitly advertise V1 support before applications should request that they sign the new format.
The upgrade should not be conflated with Solana’s separate increase in block-level compute capacity. Mainnet blocks were already operating against a 100 million-unit block limit before Transaction V1 activated, with the official explorer showing that ceiling on August 21. Transaction V1 instead expands what an individual transaction can contain and changes how its resources are encoded.
The immediate challenge now shifts from protocol activation to ecosystem adoption. Developers, wallets, indexers and RPC operators need to ensure their tooling correctly constructs and interprets V1 transactions, while the first production workloads will show how extensively developers use the additional space for ZK proofs, multisigs, confidential transfers and other complex atomic operations.
