Solana V1 Transactions Now Testable Locally as Mainnet Activation Nears

Solana SOL$101.70+1.5%'s v1 transaction format is now available for local testing, with mainnet activation expected in the coming weeks. Andreas Milz (@a_milz), a developer at the Solana Foundation, announced on August 24 that the format can be exercised today using Solana CLI v4.2 or later and Surfpool v1.5 or later, with no testnet or devnet feature gate required. Defined in SIMD-0296 and SIMD-0385, the format raises the maximum transaction size from 1,232 bytes to 4,096 bytes, a 3.3-fold expansion.

Two improvement documents define the change: SIMD-0296, which sets the 4,096-byte ceiling, and SIMD-0385, which specifies the v1 message envelope. Feature gate txv1aq4pp281K9um3tnPgkfX8UqtFT6wcVW3hNezGLL is not yet activated on testnet, devnet, or mainnet as of August 24. Milz described mainnet activation as expected "in a couple of weeks." CryptoBriefing independently reported the testing availability and activation timeline on the same date.

What V1 Rewrites in the Transaction Envelope

At offset zero, the version byte changes from 0x80 (v0) to 0x81 (v1), allowing validators, indexers, and SDKs to identify the format before parsing further.

Resource limits are the deeper structural change. In v0, compute budget and loaded-account data size are expressed through ComputeBudget instructions appended to the transaction; in v1, they move into a TransactionConfigMask field embedded in the message itself. V1 has no implicit defaults: if a transaction omits these fields, the runtime treats them as zero and the transaction fails. Developers who rely on the validator's default compute allocation must set both the compute unit limit and the loaded-accounts data size explicitly in every v1 transaction.

ComputeBudget instructions submitted inside a v1 transaction become no-ops. They still consume 150 compute units each, so sending them is purely wasteful; the correct approach is to configure limits through the message config field.

Priority fees change format in the same move. V0 denominates priority fees in micro-lamports per compute unit; v1 uses total lamports. Any code that calculates fee bids by multiplying compute units by a micro-lamport rate will produce incorrect results on v1 without a unit conversion.

Transactions exceeding 1,232 bytes must be submitted with encoding: "base64" rather than the default base58 encoding.

V1 Drops Address Lookup Tables, and Why That Trade Works

The v1 format does not support address lookup tables (ALTs). Every account a v1 transaction references must be written inline as a full 32-byte public key, within the 64-account limit that carries over unchanged from v0.

In v0, ALTs provide address compression: per Solana's own analysis, each table introduction costs roughly 34 bytes of overhead, but each subsequent account reference from that table costs only one byte. That compression is what allowed complex DeFi routes with many accounts to fit inside the 1,232-byte limit. V1 removes the need for that mechanism by expanding the byte budget to 4,096 bytes.

Solana's analysis of its own transaction dataset found that approximately 62% of v0 transactions reference at least one ALT, and that the first 25 lookup tables account for 30% of all transaction-to-table references. For the transactions that use those 25 high-concentration tables, v1's larger budget accommodates the inline expansion comfortably. Solana's distribution data shows 90% of sampled v0 transactions fall under 1,400 bytes of address overhead when converted to inline format, and 50% fall under 420 bytes.

Applications that reference many distinct accounts across many different lookup tables may find the 64-account limit is the binding constraint even with the larger byte budget. For those use cases, v0 and legacy transactions remain available and continue to be processed normally after v1 activates.

Breaking Changes for RPC Callers and Indexers

Two categories of breaking change take effect from the moment the first v1 transaction lands on mainnet.

RPC Callers: Adding maxSupportedTransactionVersion

Callers to getTransaction and getBlock must add maxSupportedTransactionVersion: 1 as an integer parameter. The value must be an integer; passing the string "1" does not satisfy the check. Without the parameter, any response that includes a v1 transaction returns error code -32015, and a single v1 transaction in a block causes the entire block query to fail. The same parameter is required for blockSubscribe.

Indexers: Reading transactionConfig Instead of ComputeBudget Instructions

Code that extracts priority fees or compute limits by scanning ComputeBudget instructions will silently return zero for v1 transactions, because those values moved to transactionConfig. Indexers must first detect the transaction version by checking whether the Message.config field (field 7 in the message) is present, then read resource limits from transactionConfig rather than from instruction data. Normalizing priority fees across v0 and v1 transactions also requires a unit conversion, since the two formats express fees differently.

The full eight-point migration checklist covering Agave 4.2's breaking changes, including the RPC parameter change and indexer scanning, is in our prior coverage from August 21.

SDK and Library Minimums for V1 Support

Support across the major Solana SDKs and libraries requires the following minimum versions, per Solana's official upgrade page:

The solana-foundation/solana-go library has a pull request pending as of the announcement date. The geyser plugin at version 15.1.1 downgrades v1 transactions to v0 format, providing a short-term compatibility bridge for downstream consumers that have not yet added v1 decoding.

What the Larger Transaction Ceiling Makes Possible

The 4,096-byte ceiling makes classes of on-chain operations practical that previously exceeded the transaction limit or required multi-transaction workarounds. Per Anza engineers and the Solana Foundation, zero-knowledge proofs for Confidential Transfers, which embed proof data that compresses poorly, previously required multi-step flows or off-chain coordination; the larger envelope brings them into a single transaction. Large multisig schemes and DeFi operations with long account lists benefit from the same headroom without needing address lookup table workarounds. Post-quantum and aggregation schemes, including Winternitz one-time signatures and BLS signature aggregation, also become viable in a single atomic transaction.

None of those capabilities require any further protocol change beyond the v1 feature gate activation.