New upgrade to Solana: cheaper to use, more difficult to run

Agave 4.2 upgrade: On-chain rent is reduced by approximately 90%, and the maximum transaction capacity of

will be increased from 1,232 bytes to 4,096 bytes in five steps. The time slot time has been reduced from 400 milliseconds to 200 milliseconds, doubling the frequency of network block production. This version deployed Alpenglow's complete code in advance before the official activation of Agave 4.3.

Anza, the engineering company responsible for maintaining Solana's mainnetwork validator client, plans to activate Agave 4.2 for the first time on the mainnetwork during the week of August 17. This update redefines network data storage costs and single transaction carrying capacity, reducing on-chain rents by approximately 90%, while increasing the maximum transaction capacity from 1,232 bytes to 4,096 bytes, and reducing the slot time from 400 milliseconds to 200 milliseconds. This version also includes Alpenglow's complete code-this consensus mechanism refactoring will be activated in Agave 4.3, but the current version has a test environment for it, which will be the largest protocol change since Solana was launched.

Rental, transaction capacity and slot time are adjusted synchronously

Anza announced the schedule for version 4.2 on June 30, and has maintained a six-weekly release pace since the version 4.0 cycle. The three changes will be activated one by one: the validator upgrades the software first, and when the network is ready, each function will be activated independently. Among them, the rent reduction was the largest, and it was the largest of the three changes in percentage terms.

Indicator comparison:

• On-chain rent (lamports/byte): old version 6,960 → 4.2 version target 696 (approximately 90% cost reduction)
• Transaction capacity (bytes): Old version 1,232 → 4.2 version 4,096 (supports atomic bundling)
• Slot time: old version 400ms → 4.2 version 200ms (Block output frequency doubles)
• Finality (Through version 4.3): Old version 12.8s → version 4.2 targets 100-150ms (sub-second settlement)

How 90% rent cuts change developers 'on-chain storage strategies

Solana charges a persistent small fee, known as "rent," for the data occupied by accounts on the ledger. The fee is designed to curb inefficient state use because each account created by the program must permanently reside in memory across all nodes. 4.2 The version gradually reduces the rate from 6,960 lamports per byte to 696, using a gradual rather than one-time adjustment.

In the past, creating millions of user accounts or deploying programs that took up a lot of state required significant capital costs, so the team minimized the data on the chain when designing. The low-cost status eliminates this upfront cost, allowing the protocol to maintain long-term accounts and large data structures directly on the ledger. Storage is no longer a capital decision, but a negligible operating cost. This change quietly rewritten Solana's design guidelines for years.

The 1,232-byte capacity limit was broken

The old capacity cap stems from the network architecture. Solana limits transactions to 1,232 bytes to maintain the size of a single network packet, leaving only actual data space after deducting overhead. A 2022 network change removed this rigid limit, and the SIMD-0296 proposal took advantage of this to increase the cap to 4,096 bytes through a new v1 transaction format.

This extra space is crucial for developers building complex logic. Under the 1,232-byte limit, developers have to split a single logical operation into multiple transactions, which introduces rollback logic, exposure to the robot risk of profiting by reordering pending transactions, and the risk that some transactions succeed and some fail. The 4,096-byte capacity allows a single transaction to bundle multiple steps that either succeed or fail, including zero-knowledge certificates used for private transfers, hierarchical approvals used by institutions to authorize large transactions, and previously multi-step transactions that had to be split due to capacity constraints. The v1 format also eliminates the address lookup table because in most cases the complete account list can be directly inline.

Faster time slots reward operators who lay their own fiber

Reducing the slot time to 200 milliseconds is the most technically difficult part of this release and is implemented in five phases through the SIMD-0525 proposal. Each validator must now receive, execute, and spread chunk data in a shorter amount of time. Operators that rely on public Internet routing rather than dedicated optical fibers face higher risks of lost blocks and delayed voting, a pressure that tends to give institutional operators with private backbones such as the DoubleZero optical layer an advantage over home operators.

Rent cuts have had a similar impact on hardware issues. Eliminating the 90% rent also removes the main economic means of controlling state inflation, and full nodes already require loading the entire account set into high-performance memory with a capacity of hundreds of gigabytes. A network that is easy to build applications is not the same as a network that is easy to operate and maintain.

Optimistic perspective

• Long-term accounts can remain on the chain, No capital costs required
• Complex logic can be accommodated in a single atomic block
• Settlement speeds close to Web2 levels

Caution perspective

• Resistance to ledger inflation is reduced
• Increase in memory and computing load on each node
• Non-fiber operators face the risk of losing blocks

Alpenglow is the real goal, 4.2 is a preview

The most important code in this release is not yet in effect. By deploying Alpenglow in an inactive state, Anza allows the validator to obtain a real-time testing environment on the community cluster, pending formal activation in Agave 4.3. Alpenglow, defined in Proposal SIMD-0326 and receiving 98% support from the validator in September 2025, will replace two major systems Solana has run since 2020: Proof of History (PoH) and TowerBFT.

The mechanism for the speed increase lies in the change in the voting method of the validator. Currently, validators issue votes as ordinary on-chain transactions, and these votes consume approximately 75% of the block space, resulting in most of the network's capacity being used for self-confirmation. Alpenglow's Votor component moves votes offline and aggregates thousands of BLS signatures into a single compact certificate that is ultimately recorded on the ledger.

Anza expects the median finality to be approximately 150 milliseconds, with a minimum of 100 milliseconds when approximately 80% of the equity is active, while the TowerBFT requires 32 rounds of voting with a finality time of 12.8 seconds. These final data are still based on simulations, and when full-scale validators are deployed on public test nets, they may expose marginal situations that community clusters have not discovered.

98.3% Cost Reduction Statement and Replacement Fees

Alpenglow's most significant economic advantage is reduced validator overhead, but this number requires additional explanation. Currently, the validator costs approximately 1SOL per day for voting, or approximately US$60,000 per year at recent prices. Alpenglow eliminated these time-slot charges and replaced them with a "validator access ticket" of approximately 0.8 SOL per day, which means 1.6 SOL for each approximately two days of epoch, and these fees were destroyed rather than paid to anyone.

IG UK calculates that net operating expenses fell by approximately 98.3%, from nearly US$60,000 per year to approximately US$1,000. Helius's model based on Cogent Crypto Profit Calculator shows that the minimum earnings equity dropped from approximately 4,850 SOL (nearly $800,000) to approximately 450 SOL (approximately $75,000).

While lowering the threshold, it also sets an upper limit. The "Verifier Access Ticket" caps the number of validators at 2,000, so the design replaces time-slot billing with fixed fees and membership limits rather than eliminating costs entirely. Numbers of 4,850 to 450 SOL are model estimates, are not guaranteed results, and depend on incentives and inflation settings introduced with the consensus change.

Impact of sub-second finality on the market

Currently, Solana forces developers to individually choose the degree of certainty of the finality of the transaction for each feature. They can show fast results after about 500 milliseconds but accept a small probability of reversal risk; or wait about 12.8 seconds to ensure that the trade never reverses. Exchange recharge confirmations need to wait for slow versions, as do bridging and clearing engines, because even minor reversals are unacceptable. Alpenglow consolidates these layers into a single deterministic finality of 100-150 milliseconds, a change that allows Solana to become the settlement layer for real-time payments, tokenized assets, and on-chain order books that inherently clear multiple asset paths.

The entire transition will last from August to October 2026 and will be carried out in phases, while Solana promotes client diversity through Firedancer and Mithril to reduce single points of failure. One part was deliberately omitted: Alpenglow does not include a "forfeiture" mechanism-a mechanism to impose financial penalties on validators that violate network rules, and community discussions only include it as a possible proposal for 2027. Whether the network can expand the participation of verifiers while maintaining decentralization of rights and interests without a real-time forfeiture mechanism is an open question that will be answered after 4.3 is activated.