Solana’s Transaction V1 goes live on testnet, tripling max transaction size

Solana just made its transactions a lot roomier. The network’s new V1 transaction format has gone live on testnet, tripling the maximum serialized transaction size from 1,232 bytes to 4,096 bytes. That 3.3x expansion removes a bottleneck that has forced developers to use awkward workarounds for years.

The upgrade, defined by two protocol proposals called SIMD-0296 and SIMD-0385, is designed to natively support zero-knowledge proofs, large multisig transactions, confidential transfers, and BLS signatures, all within a single transaction. Mainnet activation is confirmed for September 9, 2026.

What the V1 format actually changes

Solana’s legacy transaction format capped payloads at 1,232 bytes. That’s fine for a simple token swap, but it’s painfully tight for anything involving cryptographic proofs or transactions requiring dozens of signers. Zero-knowledge proofs often produce payloads that simply couldn’t fit. Developers had to split operations across multiple transactions or build custom compression schemes.

The V1 format raises the ceiling to 4,096 bytes. SIMD-0296 handles the size limit increase itself, while SIMD-0385 defines the new v1 message format, which uses a 0x81 version byte and a config mask. One notable trade-off: Address Lookup Table (ALT) support has been removed in the new format. Legacy transactions remain fully supported, so nothing breaks for existing applications.

Timeline and developer tooling

Local testing became available starting August 24, 2026, using Solana CLI v4.2+ and Surfpool v1.5+. The testnet activation followed in late August. The September 9 mainnet date gives developers roughly two weeks of testnet runway to catch bugs before the real thing.

Behind the scenes, the upgrade requires meaningful infrastructure work. RPC calls, indexers, and SDKs all need updates to handle the new transaction format. Wallet providers, block explorers, and analytics platforms will need to parse V1 transactions correctly, or risk displaying incomplete data to users.

Why bigger transactions unlock new use cases

Confidential transfers, which allow token movements where amounts are encrypted but still verifiable, have been technically possible on Solana but constrained by the old size limit. With 4,096 bytes of headroom, these transfers can be packaged into single atomic transactions.

Large multisig wallets used by DAOs and institutional treasuries also benefit. A multisig requiring 20 or 30 signers could struggle to fit all the necessary signature data within the old 1,232-byte envelope. The expanded format accommodates these scenarios natively.

BLS signatures, a cryptographic scheme that allows multiple signatures to be aggregated into one compact proof, become practical within single Solana transactions for the first time. This has implications for cross-chain bridges and validator-set attestations.

Zero-knowledge proofs are arguably the biggest unlock. Fitting a ZK proof into a single transaction eliminates the need for multi-step verification flows that add latency and complexity.

Competitive positioning and what to watch

The upgrade also runs parallel to other protocol enhancements Solana has been pursuing, including slot-time reductions and rent adjustments.

For developers evaluating where to build, the practical question is straightforward: does the new format actually work smoothly on testnet, and do the tooling updates land before mainnet goes live on September 9? Infrastructure providers that fall behind on SDK updates could create a bumpy experience for early adopters, even if the protocol layer performs flawlessly.