> ## Content Index
> Fetch the complete content index at: https://www.solanahorizon.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Anza Delays Solana Transaction V1 Mainnet Activation to September 15
- URL: https://www.solanahorizon.com/anza-delays-solana-transaction-v1-mainnet-activation-to-september-15/
- Published: 2026-09-10T13:42:13.000Z
- Updated: 2026-09-10T13:42:13.000Z
- Description: The six-day delay gives wallets, RPC providers, and indexers more time to prepare for Solana’s larger transaction format.
- Author: Bart Hillerich
- Tags: Anza, Solana, News

[Anza](https://www.anza.xyz/?ref=solanahorizon.com), the team behind Solana’s Agave validator client, has delayed Transaction V1 activation on Solana mainnet-beta until the start of epoch 1035, expected around 01:20 UTC on September 15, 2026.

The upgrade was previously scheduled for September 9, but ecosystem teams asked for more time to test and update their infrastructure. Anza announced the delay in a [September 9 post](https://x.com/anza%5Fxyz/status/2097769035144561079?ref=solanahorizon.com), and the [Solana Foundation upgrade page](https://solana.com/upgrades/larger-transaction-sizes?ref=solanahorizon.com) now lists the same epoch and time.

> *"Teams across the ecosystem told us they needed more time to test and integrate V1 support. We listened."*

Transaction V1 is already active on devnet and testnet. Legacy and v0 transactions will continue to work after the mainnet activation, but v1 creates breaking changes for applications that read, index, sponsor, or stream transactions.

## What Transaction V1 Changes

Transaction V1 implements Solana’s larger transaction size upgrade. Under [SIMD-0296](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0296-larger-transactions.md?ref=solanahorizon.com), Solana’s maximum transaction size increases from 1,232 bytes to 4,096 bytes. [SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md?ref=solanahorizon.com) defines the new v1 wire format.

The added space supports workloads that have been difficult to fit into one atomic transaction, including zero-knowledge proofs, confidential transfer flows, large multisig operations, BLS-style signature schemes, and batched instructions.

Solana based the old 1,232-byte limit on a conservative use of the 1,280-byte IPv6 maximum transmission unit after accounting for overhead. SIMD-0296 argues that Solana’s adoption of QUIC for transaction ingestion makes a larger size practical because QUIC does not share the same UDP packet-era constraint.

V1 changes more than just the size of the existing transaction layout. It moves signatures to the end of the transaction, introduces a version byte of 0x81, removes address lookup tables, rejects duplicate addresses, and moves resource-limit configuration into the message.

In legacy and v0 transactions, developers set compute budgets and priority fees through ComputeBudget instructions. In v1, those values live in transactionConfig. ComputeBudget instructions can still appear in a v1 transaction, but they become successful no-ops and do not set the limits.

## Why the Delay Matters for Wallets and Indexers

The delay gives the surrounding ecosystem more time to prepare to read larger transactions correctly.

Sending v1 transactions is optional, so applications that do not need the larger format can continue using legacy or v0 transactions. Reading v1 transactions requires updates. Once a v1 transaction lands onchain, RPC consumers, explorers, wallets, analytics systems, indexers, and streaming pipelines must recognize and decode the new format.

The Foundation’s migration guidance says clients calling getTransaction or getBlock must pass maxSupportedTransactionVersion: 1\. 

Without that setting, a v1 transaction can cause getTransaction to fail. A single v1 transaction can also cause an entire getBlock response to fail instead of returning a partial block.

Streaming systems require updates as well. The Foundation warns that blockSubscribe can emit block: null and stop advancing when a client has not opted into v1 support. Stale indexer decoders may report incorrect compute-budget or priority-fee data if the pipeline continues scanning instructions that no longer contain those values.

V1 also changes how senders prepare transactions. When a sender builds a v1 transaction without explicitly setting the compute-unit limit and loaded-accounts-data-size limit, both default to zero and the transaction fails. The Foundation recommends simulating with maximum limits, reading the resulting resource usage, and writing those limits into the v1 transaction config before sending.

## Larger Transactions, but Not a Universal DeFi Fix

The 4,096-byte ceiling gives Solana developers more room for transactions that previously required multiple steps or off-protocol workarounds. SIMD-0296 cites confidential-balance proofs, untruncated Winternitz one-time signatures, nested multisigs, and onchain cryptographic signature schemes as use cases constrained by the previous limit.

The change may reduce the need for bundled or chained operations when one larger atomic transaction would work better.

V1 retains the 64-account and 64-instruction limits, and it removes address lookup tables instead of extending them. Some account-heavy flows that rely on v0 and ALTs may therefore be unable to move directly to v1, despite the larger byte limit.

The design trades address lookup tables for more raw space and resource-limit data that infrastructure can inspect more easily. Developers must inline accounts, update decoders, and handle fees and compute limits differently.

## Where It Fits in Solana’s Upgrade Calendar

Transaction V1 is separate from Alpenglow and other Solana infrastructure changes planned for 2026.

The delay moves this transaction-format upgrade to epoch 1035\. It does not affect ongoing slot-time reductions, rent-related changes, or the planned Alpenglow consensus overhaul, which is expected to replace TowerBFT with Votor and target substantially faster finality.

The extra six days give wallets, RPC providers, indexers, explorers, and fee-sponsoring systems more time to address potential failures before activation.

If activation proceeds on September 15 as scheduled, Solana will gain a larger transaction format while retaining support for legacy and v0 transactions. Applications and infrastructure providers will still need to update their read paths for the opt-in format.