- Transaction V1 is now live on Solana mainnet-beta, giving applications substantially more room for complex operations.
- The new format targets workloads including ZK proofs, corporate multisigs and BLS signatures.
- V1 removes address lookup tables and moves compute and fee configuration into the transaction structure.
- Existing legacy and V0 transactions remain supported, while infrastructure providers need to account for the new format.
Solana has activated Transaction V1 on mainnet-beta, increasing the maximum transaction size from 1,232 to 4,096 bytes and giving developers more room to execute cryptographically complex operations within a single transaction. The change targets a constraint that increasingly affected zero-knowledge proofs, large multisignature structures and confidential transactions as Solana applications became more sophisticated.
Transactions V1 is now live on Solana, increasing max transaction sizes from 1,232 to 4,096 bytes.
Complex operations like ZK proofs, large multisigs, and confidential transfers that required multiple transactions now fit in one.
Full details from @anza_xyz:…
— Solana (@solana) September 15, 2026
Solana’s Original Limit Was a Networking Constraint
The previous ceiling originated in Solana’s networking design rather than an application-level assessment of how much data modern transactions required.
Solana historically used a conservative 1,280-byte MTU based on IPv6 networking. Once overhead was deducted, developers were left with 1,232 bytes for a transaction payload. The adoption of QUIC removed the need to remain within that original restriction, opening the possibility of larger transactions.
Over time, the limit became particularly restrictive for applications carrying large amounts of cryptographic data.
Solana’s SIMD-0296 identifies confidential-balance ZK proofs, untruncated Winternitz one-time signatures, nested corporate multisigs and BLS signatures among the workloads affected by the previous ceiling.
What Can Developers Fit Into V1?
The additional space matters most when an application previously needed to break one logical operation into several transactions or rely on alternative coordination mechanisms.
A confidential transfer, for example, can require significantly more cryptographic information than an ordinary token transfer. Corporate multisig structures can similarly accumulate signatures and account data until they encounter the transaction ceiling.
Solana developers had also turned to Jito bundles to accommodate operations too large for a single transaction.
SIMD-0296 explicitly identifies this as a workaround and notes an important difference: bundles do not provide the same protocol-level atomicity guarantee as a single transaction.
The upgrade therefore gives developers more room for several demanding workloads:
- ZK applications can accommodate larger proof data used in confidential-balance systems.
- Corporate multisigs can handle more complicated authorization structures.
- BLS and other signature schemes have additional space for cryptographic data.
- Complex trading routes can potentially package more instructions and account interactions together.
The 4,096-byte limit was also informed by observed bundle usage. According to SIMD-0296, roughly half of measured Jito bundles were 2,048 bytes or smaller, while 65% were no larger than 6,144 bytes. The chosen limit therefore captures a meaningful portion of workloads that had been using bundles without expanding transactions all the way to the largest observed sizes.
Transaction V1 Changes More Than Size
SIMD-0385 also redesigns how resource requirements are represented.
Legacy and V0 transactions use Compute Budget Program instructions for parameters such as compute-unit limits and priority fees. V1 places this information directly into the transaction through TransactionConfigMask and associated configuration values.
That allows validators to identify resource requirements without scanning the instruction list first, addressing an inefficiency in transaction ingestion.
The format retains limits of 12 signatures, 64 accounts and 64 instructions, despite having a larger overall envelope. It also does not support Address Lookup Tables, a feature available to V0 transactions. Addresses instead need to be included directly.
That makes V1 an additional transaction format rather than a universal replacement for V0. Developers whose applications benefit from lookup tables can continue using the older format, while applications constrained by transaction size gain another option.
Indexers and RPC Infrastructure Need to Adapt
The upgrade also creates a practical issue beyond application developers.
Sending V1 transactions is optional, but infrastructure that reads Solana activity needs to understand them once they appear onchain. Solana’s developer documentation warns that RPC and gRPC consumers without V1 support can fail or incorrectly report transaction information.
One specific example involves priority fees. Infrastructure that calculates them by searching for Compute Budget instructions would report zero for V1 transactions because that information has moved into TransactionConfig.
The Solana Foundation has published working V1 examples in Rust, TypeScript, Python and Go, covering transaction submission, decoding, block reading and Yellowstone gRPC indexing.
Solana Transaction V1 developer examples
Adoption Will Show Whether the Extra Space Was Needed
Transaction V1 does not mean every Solana transaction will become larger, and it does not multiply the network’s overall throughput by the same factor as the transaction-size increase.
Its impact should instead become visible in which applications adopt the format.
The most useful indicators will be whether developers migrate workflows away from bundle-based workarounds, whether privacy and multisig applications begin using larger atomic transactions, and how quickly RPC providers and indexers achieve full V1 compatibility.
Those adoption patterns will show whether Solana’s old transaction ceiling was merely an inconvenience for specialized applications or a meaningful constraint on the next generation of onchain cryptography.
Credit: Source link
