Agave 4.2 cuts on-chain rent by roughly 90%, phased in over five steps. Maximum transaction size rises from 1,232 to 4,096 bytes. Slot times fall from 400ms to 200ms, doubling the network’s b
Anza, the engineering firm that maintains Solana’s main validator client, is targeting the week of August 17 for the first mainnet activations of Agave 4.2, a release that reworks how much it costs to store data on the network and how much a single transaction can carry. The update pairs a roughly 90% cut to on-chain rent with an increase in the maximum transaction size from 1,232 to 4,096 bytes and a reduction in slot times from 400 to 200 milliseconds. It also carries the full code for Alpenglow, the consensus rewrite that stays dormant until Agave 4.3, but whose presence here turns 4.2 into a staging ground for the largest protocol change Solana has attempted since launch.
Anza published the 4.2 schedule on June 30 and has been running a six-week release cadence since the 4.0 cycle. The three changes are switched on one at a time: validators upgrade the software first, and each feature activates separately once enough of the network is ready. The rent reduction is the largest of the three in percentage terms.
MetricBeforeAgave 4.2GoalOn-chain rent (lamports/byte)6,960696~90% cheaper stateTransaction size (bytes)1,2324,096Atomic bundlesSlot time400ms200ms2x block cadenceFinality (via 4.3)12.8s100-150msSub-second settlementSolana charges accounts a small ongoing fee, called rent, for the data they occupy on the ledger. That fee exists to discourage inefficient use of state, since every account a program creates has to sit in the memory of every full node forever. The 4.2 target lowers the rate from 6,960 lamports per byte toward 696, a reduction the network applies gradually rather than in one jump.
Creating millions of user accounts or deploying programs with heavy state used to require a meaningful capital lockup, so teams designed around keeping as little as possible on-chain. Cheap state removes that upfront penalty and lets protocols hold long-lived accounts and larger data structures directly on the ledger. Storage stops being a capital decision and becomes a minor operating cost. That single change quietly rewrites years of Solana design advice.
The old ceiling was a networking artifact. Solana capped transactions at 1,232 bytes to stay inside the size of a single network packet, and after overhead that was the room left for actual data. A networking change in 2022 removed that hard constraint, which is what SIMD-0296 now takes advantage of, delivered through the new v1 transaction format that lifts the limit to 4,096 bytes.
That extra room matters for anyone building complex logic. Under 1,232 bytes, developers had to split a single logical action across several transactions, which introduced rollback logic, exposure to bots that profit by reordering pending transactions, and the risk of one leg failing while another cleared. A 4,096-byte envelope lets a single transaction bundle several steps that all succeed or fail together, including zero-knowledge proofs used in private transfers, the layered approvals institutions use to authorize large transactions, and multi-step trades that previously had to be split up to fit. The v1 format also drops address lookup tables, since the full account list fits inline in most cases.
Cutting slot times to 200ms is the most technically demanding part of the release, delivered in five stages under SIMD-0525. Every validator now has to receive, execute, and propagate block data in half the previous window. Operators running on public internet routing rather than dedicated fiber face a higher chance of dropped slots and late votes, and that pressure tends to favor institutional setups on private backbones such as the DoubleZero fiber layer over home operators.
The rent cut pulls in the same direction on the hardware question. Removing 90% of the rent charge also removes the main economic brake on state bloat, and full nodes already carry the entire account set in high-performance memory that runs to hundreds of gigabytes. A cheap network to build on is not the same as a cheap network to help run.
The optimistic reading
The most consequential code in this release does nothing yet. By shipping Alpenglow in a deactivated state, Anza gives validators a live environment to test it on the community cluster before the switch flips in Agave 4.3. Alpenglow, defined in SIMD-0326 and approved by validators with 98% support in September 2025, replaces both Proof of History and TowerBFT, the two systems Solana has run since 2020.
The mechanism behind the speed gain is a change in how validators vote. Today they publish votes as ordinary on-chain transactions, and those votes consume around 75% of total block space, so the network spends most of its capacity confirming itself. Alpenglow’s Votor component moves voting off-chain and aggregates thousands of BLS signatures into a single compact certificate that lands on the ledger. Anza projects median finality of roughly 150ms, and as low as 100ms when about 80% of stake is active, against the 12.8 seconds TowerBFT needs across its 32 voting rounds. Those finality figures remain simulation-derived, and a public testnet at full validator scale may surface edge cases the community cluster did not.
The clearest economic argument for Alpenglow is what it does to validator overhead, and the headline figure needs a caveat attached.
The lower barrier comes with a ceiling. The Validator Admission Ticket caps admitted validators at 2,000, so the design trades a per-slot cost for a fixed one and a membership limit rather than removing costs outright. The 4,850-to-450 SOL figure is a modelled estimate, not a guaranteed outcome, and it depends on the reward and inflation settings that ship alongside the consensus change.
Solana currently forces developers to choose, feature by feature, how sure they need to be that a transaction is final. They can show a fast result after about 500ms and accept a small chance it later reverses, or wait roughly 12.8 seconds to be certain it can never reverse. Exchanges crediting deposits wait for the slow version. So do bridges and liquidation engines, because even a minor reversal is unacceptable. Alpenglow collapses those tiers into a single deterministic finality at 100-150ms, which is the change that makes Solana viable as a settlement layer for real-time payments, tokenized assets, and on-chain order books that clear multi-asset routes natively.
The full transition runs in stages from August into October 2026, and it lands while Solana pushes on client diversity through Firedancer and Mithril to reduce single points of failure. One piece is deliberately absent: Alpenglow ships without slashing, the penalty that would economically punish validators who act against the network, and community discussion has floated that only as a possible 2027 proposal. Whether the network can widen validator participation while keeping stake decentralized, without a live slashing mechanism in place, is the open question that the 4.3 activation will start to answer.
The post Solana’s New Upgrade Makes It Cheaper to Use, Harder to Run appeared first on ETHNews.
