Agave 4.4 Update: All You Need to Know

Introduction

With Agave 4.4, Solana’s core validator client builds on the Alpenglow rollout, simplifying block validation, streamlining staking reward calculations, and lowering the SOL required to store programs and account data. These changes improve day-to-day efficiency while laying further groundwork for asynchronous execution. The recent reduction of target slot times to 200ms shortens epochs to roughly one day, which enables an even faster cadence of feature gate activations.

Notable Agave 4.4 Release Cycle Updates

• Allow Invalid Fee Payers: A key step towards enabling asynchronous execution
• Auto Program Resizing: Refunds surplus rent during program upgrades
• Standardizing Shreds: Protocol now enforces 32-data, 32-coding FEC sets
• Inactive Stake Cleanup: Excludes inactive stake from reward calculations
• Rent Reduction: Final three planned stages of the 90% reduction in state bonds

Allowing for Invalid Fee Payers

The feature gate activation of SIMD-0290: Relax Fee-Payer Constraint is expected to go live during the Agave 4.4 release cycle. This changes what happens when a block contains a transaction whose fee payer fails validation, for example, because it has insufficient SOL. Previously, including such a transaction invalidated the entire block. Under the new consensus rules, the transaction remains in the block, and validators skip execution, making no changes to account state.

A fee payer’s balance may change as earlier transactions execute. Requiring every transaction to have a valid fee payer therefore means validators must execute some preceding transactions before they can determine whether a block is valid. Treating fee-payer failures as skipped transactions removes this particular dependency.

This is groundwork for asynchronous execution, where validators can agree on blocks and transaction ordering before completing execution. Execution proceeds separately, applying the agreed transactions to account state. Solana is moving toward this design to support future improvements such as shorter block times and multiple concurrent block proposers.

Agave represents these skipped transactions as no-ops: they execute no instructions and pay no fees. They still consume block capacity according to their full requested or default resource budgets, limiting how many a leader can include. The implementation also preserves the leader’s ability to filter them out during block production, even though validators can accept them when replaying a block.

SIMD-0290 applies specifically to transactions using a recent blockhash for their lifetime specifier. Durable nonce transactions require additional handling, addressed separately by SIMD-0297: Relax Invalid Nonced Transactions Constraint. The change is fully backward compatible with all previously valid transactions and blocks remaining valid.

Auto-resizing Programs on Upgrade

Agave 4.4 will include a feature gate activation for SIMD-0433: Loader V3: Set Program Data to ELF Length, which makes program upgrades automatically resize the account storing the program’s compiled code.

Loader v3 (i.e., the current default loader for deploying and upgrading Solana programs) stores a program’s compiled ELF binary in a ProgramData account, alongside metadata such as its upgrade authority. Previously, developers could only extend this account but never shrink it. Upgrading to a smaller binary therefore left unused space, and the SOL required to keep that space rent-exempt remained locked in the account.

With this change, the Upgrade instruction resizes the account to the metadata header plus the new ELF’s length. A smaller binary releases surplus lamports to the upgrade’s spill account, the designated recipient for leftover funds. A larger binary automatically expands the account, removing the separate extension step for ordinary upgrades. The ProgramData and buffer accounts must already contain enough lamports to meet the new rent requirement; otherwise, the upgrade fails.

Developers adopting smaller binaries can therefore recover SOL during their next upgrade. Any previously reserved spare capacity is also removed. For upgrades invoked through CPI, the 10 KiB account-growth limit still applies: larger increases require prior extension or a top-level upgrade instruction. Developers should check their spill-account destination before upgrading to ensure refunds reach the intended recipient.

This change incentivizes developers to upgrade to newer, more performant libraries and frameworks such as Pinocchio. It also reduces the amount of space programs take up in Accounts DB.

Standardizing Shreds

Agave 4.4 includes a tightening of Solana’s block propagation rules outlined in SIMD-0317: Enforce 32 Data + 32 Coding Shreds. This standardizes the structure validators use to distribute and reconstruct block data.

Solana distributes blocks through Turbine, which breaks block data into shreds and relays them through layers of validators. Shreds are grouped into forward error correction (FEC) sets, combining data shreds with coding shreds containing recovery information. With a correctly constructed 32-data, 32-coding set, a receiver can reconstruct the original data from any 32 of the 64 shreds, helping it tolerate packet loss.

Each shred also carries a Merkle proof linking it to the set’s Merkle root, which is authenticated by the leader’s signature. For a set of 64 shreds, that proof has six entries, corresponding to the six levels between a leaf and the root. Agave’s proof-size check requires the size expected for this fixed 32:32 structure.

Clients already produce 32 data shreds and 32 coding shreds per set, but receiving validators have historically accepted more flexible configurations. SIMD-0317 closes that gap by making the fixed 32:32 structure a protocol requirement. This simplifies validation: a receiver can determine valid shred-index boundaries without waiting for a coding shred to reveal the set’s dimensions.

The fixed structure also simplifies detection of equivocation, where a leader distributes conflicting versions of the same data. Two shreds belonging to the same FEC set, with different Merkle roots and valid leader signatures, provide evidence of that conflict. Standardizing the format therefore reduces implementation complexity while making equivocation easier to identify.

Removing Inactive Stake from Reward Calculations

The Agave 4.4 release cycle will include a feature gate activation for SIMD-0599: Remove Inactive Stakes from Stake Delegations, which simplifies how validators handle inactive stake accounts during partitioned epoch rewards at the beginning of each epoch. Inactive stake accounts may hold SOL above their rent-exempt minimum, but have no active or activating stake. Their SOL is undelegated or has fully completed deactivation.

These accounts earn no protocol rewards, yet their inclusion can affect the number of reward-distribution partitions and the lattice hash used to track account state. Every validator client must reproduce this behavior precisely, adding unnecessary complexity to consensus-critical code.

The change excludes stake that was inactive during the epoch being rewarded, retaining activating, active, and deactivating stakes. Thus, a stake account that becomes inactive at the start of a new epoch still receives rewards earned during the preceding epoch in which it was deactivating.

More Rent Reduction

Agave 4.4 is expected to bring the final three activations in Solana’s phased rent reduction. Under the plan set out in SIMD-0437, the minimum balance required per byte of account storage falls from the original 6,960 lamports to 696 across five steps (i.e., a 90% reduction).

Each activation has its own feature gate, letting the network assess the impact on account creation and state growth before proceeding.

Lowering this requirement reduces the capital developers and users must commit when creating token accounts, PDAs, and other onchain state. This is particularly useful for applications that fund account creation on behalf of users, such as large-scale payment services.

Estimates from Ghost indicate over 3 million SOL (~$300m) is redeemable. Several tools have been developed to help users reclaim excess SOL from their accounts.

Conclusion

Agave 4.4’s headline changes build on Alpenglow while advancing long-awaited improvements to staking rewards, program deployment, and account costs. Together, they continue Solana’s push toward a faster, more accessible network. Next comes Breakpoint London, followed by Agave 4.5.

Further Resources

• Agave 4.4 Release Schedule
• Feature Gate Tracker Schedule
• Agave 4.4 Change Log
• Agave 4.4 Pull Requests