Transaction V1 (SIMD-0385) Is Live on Solana Mainnet at Epoch 1035

Transaction V1 activated on Solana mainnet at Epoch 1035 at approximately 01:04 UTC on September 15 2026. The upgrade, developed by Anza under SIMD-0385, raises the maximum transaction size from 1,232 bytes to 4,096 bytes and restructures how transactions encode resource limits.

The Solana Labs account confirmed the live status in a separate post, noting that complex operations previously requiring bundled or chained transactions now execute as a single atomic call. Compass covered the mainnet target date and breaking-change overview on September 3.

What the 4,096-Byte Format Changes

The wire format changes substantially from v0. The version discriminator byte 0x81 sits at position zero, making v1 structurally distinct from both legacy transactions and v0 (0x80). Address Lookup Tables are not supported in v1; all accounts must be listed directly in the message body, up to 64. Signatures move to the trailing end of the transaction envelope.

The biggest structural shift is how resource limits are encoded. In v0, developers set compute unit limits, priority fees, and heap sizes via ComputeBudget instructions embedded in the transaction body. In v1, those values move into a dedicated configuration mask inside the message header. ComputeBudget instructions still parse without error in v1, but they execute as no-ops.

Priority fees also change denomination: v0 expresses them as micro-lamports per compute unit; v1 uses absolute lamports as the total fee.

ZK Proofs, BLS Signatures, and Confidential Transfers in One Atomic Call

The byte expansion unlocks workloads that previously required multiple sequential or bundled transactions. Per the official migration guide, the additional space accommodates zero-knowledge proofs including Confidential Transfer operations, large multisignature schemes, BLS and Winternitz one-time signatures, and batched operations packaged as a single atomic transaction.

These use cases were architecturally blocked by the 1,232-byte ceiling. Projects building privacy features or complex governance flows on Solana can now complete those operations in a single on-chain call.

Breaking Changes Developers Must Address Before Sending V1 Transactions

RPC consumers must pass maxSupportedTransactionVersion: 1 on getTransaction, getBlock, and blockSubscribe calls. Without it, any v1 transaction in the response triggers error code -32015. Transactions larger than 1,232 bytes require base64 encoding for submission.

Indexers and data pipelines can no longer reliably read compute units from ComputeBudget instructions on v1 transactions. Geyser and gRPC consumers need regenerated protobuf stubs and structural detection via the presence of Message.config (field 7). The correct source for compute unit data on v1 is the transactionConfig field in the transaction message.

Transaction senders must explicitly set compute unit limits and loaded accounts data size limits. V1 defaults resource limits to zero, meaning transactions that omit them fail at execution.

Wallet integrations should verify the supportedTransactionVersions field before sending v1 transactions, and wallet implementations must fully parse and sign v1 before advertising support.

On-chain programs have no syscall access to the v1 message config, so programs that previously scanned ComputeBudget instructions to infer resource limits need updated logic.

Library Minimum Versions and Validator Requirements

To read and send v1 transactions, applications need minimum library versions per the migration guide:

• @solana/kit 8.0.0 or higher
• @solana/web3.js 3.0.0-rc.3 or higher
• Rust solana-* crates 4.2.x
• Go solana-foundation/solana-go 1.23.0 or higher
• Python solders 0.29.0 or higher

Jito-Solana operators must upgrade to v4.2.2 or higher. RPC nodes require Agave v4.2.2 or higher to prevent v1 messages from being silently downgraded to v0 with zeroed compute budgets during storage. The feature gate address is txv1aq4pp281K9um3tnPgkfX8UqtFT6wcVW3hNezGLL. Legacy and v0 transactions continue to work without modification.