Solana activated its txv1 feature gate at the beginning of mainnet epoch 1035 on September 15, 2026, at approximately 01:00 UTC. Transaction V1 raises the maximum transaction size from 1,232 bytes to 4,096 bytes, providing roughly 3.3 times as much room.

Legacy and V0 transactions remain supported. Applications do not need to start sending V1 transactions simply because the format is available.

The old ceiling was becoming a design constraint

At 1,232 bytes, developers sometimes had to restructure operations around the transaction format rather than around the application itself. Larger proofs, complex multisignature setups and other data-heavy operations could exceed the limit and require several transactions or additional mechanisms.

V1 makes room for workloads including zero-knowledge proofs, large multisigs and some onchain signature schemes. More instructions and data can also live inside one atomic operation instead of being split across a sequence of transactions.

That atomicity matters. When several steps genuinely belong together, one transaction provides a protocol-level all-or-nothing result rather than an application attempting to coordinate several separate confirmations.

V1 is not merely a larger V0

The message format changes as well. Solana's V0 format supports Address Lookup Tables, allowing applications to reference account addresses through compact indexes. V1 supports up to 64 inline account addresses and does not use ALTs.

Resource configuration also moves. Legacy and V0 transactions rely on ComputeBudget instructions for limits such as compute units. V1 stores those limits in the transaction message configuration.

Developers opting into V1 therefore need to set compute-unit and data-size limits explicitly. Their defaults are zero.

Readers have a migration problem even if senders do not

A wallet can continue sending older transaction formats. A service reading the chain cannot necessarily ignore V1.

Clients requesting blocks or transactions need to advertise support for the format, including maxSupportedTransactionVersion: 1 where applicable. A reader that has not been updated can fail when its request encounters a V1 transaction.

That reaches beyond developer libraries. RPC infrastructure, explorers, indexers, analytics platforms, exchanges and wallets often depend on the same transaction-reading path.

Software that sponsors fees or applies limits to transactions has another detail to update: resource caps that were previously inferred from ComputeBudget instructions must be read from the V1 transaction configuration instead.

4,096 bytes is not a new TPS figure

The upgrade increases how much information a single transaction can contain. It does not, by itself, mean that Solana suddenly processes 3.3 times as many transactions per second.

Larger transactions also consume more bandwidth. During congested periods, applications sending large operations can still face competition for block space and may need higher priority fees. V1 does not introduce a separate mandatory per-byte fee.

Program deployment is an immediate practical example

Solana's September engineering changelog highlights program deployment as one workload that can directly benefit. Deployments write program data into buffer accounts across multiple transactions.

With V1 carrying roughly four times as much data as the old maximum, tooling can pack substantially more program data into each write. Solana developers are integrating V1 into solana program deploy with the expectation of roughly four-times-lower transaction-fee overhead for that process.

The 1,232-byte ceiling shaped Solana application design for years. As of epoch 1035, developers finally have a 4,096-byte option instead.