preferred on
Points of Focus
- Solana Transaction V1 went live on mainnet, increasing the maximum serialized transaction size from 1,232 bytes to 4,096 bytes.
- The larger format gives developers more room to fit ZK proofs, large multisigs, and cryptographic operations with bigger payloads into a single atomic transaction.
- RPC providers, indexers, fee sponsors, and co-signing services need V1 support because the format changes how transaction versions and resource limits are read.
Solana Transaction V1 went live on mainnet at epoch 1035 on Sept. 15, raising the maximum size of a single transaction by 3.3 times and easing a byte limit developers have worked around since the network’s early design.
The upgrade activated at the start of epoch 1035 at approximately 01:00 UTC. V1 transactions are now live on mainnet, testnet, and devnet.
Under SIMD-0296, the maximum serialized transaction size increased from 1,232 bytes to 4,096 bytes, using the V1 format defined in SIMD-0385. The previous limit dated back to Solana’s original networking design. Its later adoption of QUIC allowed the network to support larger transactions.
V1 gives cryptographic workloads more room
Solana lists zero-knowledge proofs, large multisigs, and signature schemes with larger proofs among the workloads that can benefit from V1.
Developers have used address lookup tables or split larger operations across multiple transactions and bundles to work around the previous size limit. SIMD-0296 notes that splitting an operation across transactions or bundles introduces additional coordination and can lose the protocol-level atomicity of a single transaction.
V1 supports transactions of up to 4,096 bytes, with a maximum of 12 signatures, 64 accounts, and 64 instructions. Account addresses are carried directly in the transaction, and V1 does not support address lookup tables.
Applications already built around V0 and lookup tables may need to adjust transaction construction before adopting V1. Legacy and V0 transactions continue operating under their existing rules.
The upgrade follows Solana’s earlier increase in the block compute ceiling from 60 million to 100 million compute units. That change increased the amount of computation available across a block. V1 gives individual transactions more room for instructions, accounts, signatures, and proof data.
RPC providers and indexers need V1 support
The upgrade requires changes from infrastructure providers that read, index, or sponsor Solana transactions.
RPC services and indexers need to recognize the new transaction version and read resource limits from V1’s “transactionConfig,” according to the Solana Foundation’s migration guidance. Fee sponsors and co-signing services may also need updates because V1 handles compute limits, priority fees, and other resource settings differently from earlier transaction formats.
Applications sending V1 transactions must also specify their compute unit and loaded account data limits explicitly because both default to zero.
The activation comes amid a broader series of performance upgrades across Solana. The chain has started a staged program to reduce slot times from 400 milliseconds toward 200 milliseconds, while workloads such as AI-agent payments have generated more than 1.5 million transactions in a day.
Solana’s planned Alpenglow consensus upgrade targets roughly 150-millisecond finality as another part of the network’s performance roadmap.
For developers building proof-heavy, multisig, and cryptographic applications, Transaction V1 increases the amount of work that can fit inside a single atomic operation and loosens a transaction-size constraint that has shaped application design for years.
Share
Most read articles
