Solana is preparing two major infrastructure upgrades that could reshape its transaction and consensus layers. On September 9, the network is targeting mainnet activation of Transaction v1, a new transaction format that increases the maximum serialized transaction size from 1,232 bytes to 4,096 bytes—roughly 3.3 times more space for developers.
The change is part of Anza's Agave 4.2 rollout and stems from SIMD-0296 and SIMD-0385, co-authored by Jacob Creech and Andrew Fitzgerald. Transaction v1 remains optional: legacy and v0 formats will continue to operate under existing size limits, and users do not need to migrate tokens or claim anything before activation. The new format removes Address Lookup Tables and stores complete 32-byte account addresses directly inside each transaction, while resource limits such as compute units and priority fees live in dedicated transaction configuration metadata instead of ComputeBudget instructions.
Solana's documentation warns that infrastructure providers, RPC services, indexers, explorers and analytics platforms must update their software to support version one or risk errors when reading new-format transactions. Applications sending v1 transactions must explicitly set compute-unit and loaded-data limits because both default to zero. Although the larger format gives developers more room for zero-knowledge proofs, large multisignature operations, batches and onchain signature schemes, it does not raise the existing limit of 64 referenced accounts per transaction. Testnet and devnet have already activated the feature, while mainnet activation remains listed as pending and subject to change.
The second initiative is Alpenglow, Solana's largest consensus overhaul. The network is targeting October for the transition through the upcoming Agave 4.3 validator-client release, though no exact activation date or block height has been announced. Alpenglow replaces the current TowerBFT consensus mechanism with Votor, a voting architecture that allows validators to exchange votes directly and aggregate them using BLS signatures into compact certificates. Solana says the new design targets finality of approximately 150 milliseconds, down from about 12.8 seconds under TowerBFT—an roughly 85-fold reduction.
That finality improvement is especially important for exchanges, cross-chain bridges, payment systems and institutional settlement applications that face additional risk before a block is effectively irreversible. The upgrade is designed to tolerate 20% of stake behaving adversarially alongside another 20% being offline.
Two prerequisites have already been activated: BLS public-key registration went live on July 8, and the Validator Admission Ticket activated on July 22. VAT currently limits the admitted validator set to 2,000 and requires validators to have registered BLS keys, meaning validators without them are already excluded from consensus. Once Alpenglow is fully enabled, admitted validators will pay a flat 1.6 SOL per epoch instead of roughly 2 SOL in aggregate voting transaction costs.
Agave 4.2, released in August, already contains the code necessary to run Alpenglow, allowing developers and validators to test the system before mainnet activation. The broader upgrade cycle also includes a phased 90% reduction in account rent and progressive slot-time reductions from 400 milliseconds toward 200 milliseconds. Validators previously approved SIMD-0326, the Alpenglow proposal, with 98.27% support among participating stake in September 2025. Solana has deliberately stopped short of promising a specific activation day, with final timing dependent on testing, Agave 4.3 readiness and validator adoption.
