Anza Developer Sets Mainnet Dates: Transaction V1 September 9, Rent Reduction This Week, Alpenglow in October

Anza developer Jacob Creech published four specific mainnet upgrade dates on August 29, compressing the remainder of Solana SOL$105.07+1.2%'s 2026 infrastructure roadmap into a single thread. The list runs from this week through October: a rent reduction cut arriving on mainnet within days, Transaction V1 going live September 9, slot times dropping further on no set date yet, and Alpenglow consensus activation targeting October.

Each item has been in preparation for months. What changed on August 29 is that Creech put specific dates on the two nearest milestones: "next week" for the rent reduction and "Sept 9" for Transaction V1.

Transaction V1 Reaches Mainnet on September 9

Transaction V1, specified in SIMD-0296 and SIMD-0385, expands the maximum transaction size from 1,232 bytes to 4,096 bytes, roughly 3.3 times the current limit. That extra capacity opens workloads that have historically required workarounds: ZK proofs, large multisig schemes, BLS signatures, and confidential transfers using zero-knowledge proofs can now fit inside a single atomic transaction where they previously spanned multiple steps or relied on lookup tables.

The format is opt-in. Legacy and v0 transactions continue to work without change. Applications that want to send v1 transactions must adopt compatible SDKs — @solana/kit 8.0.0 and solana-* 4.2.x or later — and must explicitly set compute unit and data size limits within each transaction, since those fields are required and default to zero in v1. Applications fetching v1 transactions also need to pass maxSupportedTransactionVersion: 1 to their RPC calls.

One structural change: v1 transactions carry 64 inline accounts but do not support address lookup tables. Developers who currently use lookup tables to fit more accounts into a transaction will need to evaluate whether the larger base limit alone covers their use case.

The format has been testable locally since late August using Solana CLI v4.2 and Surfpool v1.5. September 9 is the first confirmed mainnet date.

SIMD-0437 Rent Reduction Step 1 Coming to Mainnet Next Week

Creech's "next week" puts the first rent reduction step on mainnet between approximately September 1 and September 5. The move follows SIMD-0437's activation on testnet on August 28.

SIMD-0437 cuts lamports_per_byte, the coefficient governing how much SOL must be deposited to keep an account open, from 6,960 to a final target of 696, a 90% reduction rolled out across five independent feature gates. Step 1 moves the value from 6,960 to 6,333, a roughly 9% initial cut. The full five-step schedule targets 696.

The practical effect compounds as subsequent steps activate. A standard SPL token account currently requires a rent-exempt deposit of approximately $0.159, falling to approximately $0.016 when all five steps complete. Step 1 alone produces a modest reduction, but it starts the clock on the larger cuts to follow.

Each step is gated independently so engineers can observe state growth at each level before proceeding. A fallback gate can restore the prior value if a step produces unexpected state expansion. The staged approach is the same logic that has governed slot time reductions.

Further Slot Time Reductions Planned Under SIMD-0525

Creech listed a further slot time reduction without specifying a date. The network currently runs at 300ms after the August 28 epoch 1024 activation, itself the second of four planned decrements under SIMD-0525. That plan targets 200ms as the eventual baseline, which would require two more 50ms steps.

No date or epoch target for the third decrement appeared in Creech's post. The cadence of prior steps (400ms to 350ms at epoch 1020, then 350ms to 300ms at epoch 1024) suggests the next reduction will come after engineers confirm stability at the current level.

Alpenglow Consensus Targets October Mainnet Activation

The Alpenglow consensus upgrade, which replaces TowerBFT with a protocol targeting roughly 150ms finality, is aimed at October mainnet activation. The Agave 4.3 release schedule shows the timeline: a mainnet upgrade candidate tagged September 4, stake-weighted validator adoption recommended by September 21, and feature activation beginning September 28. October activation is consistent with that progression: validators upgrade through September, and the feature gate follows once adoption is broad enough.

The earlier September 28 target reported in the Agave 4.3 schedule referred to when feature activation begins, not when the protocol is fully live across the network. Creech's "October" timing reflects the expected completion of that process.

Alpenglow's test cluster has already demonstrated what the protocol can deliver: 96% fast-path finalization at 214ms, against TowerBFT finality that runs closer to 12.8 seconds under typical conditions. The Agave 4.2 release overview notes that Alpenglow's code is complete in 4.2 but activation defers to 4.3.

Creech closed his post with a reference to the Scale or Die conference in November, Solana's next major developer gathering, as the milestone following the October Alpenglow window.