Skip to content
Developers10 min read

Agave 4.4: What Changes for Solana Developers

Agave 4.4.0 is out as a stable release. Here is what its feature gates, the next rent step and the new RPC options mean for indexers, bots and programs.

Sourav Mishra · OrbitFlare
Agave 4.4: What Changes for Solana Developers

On 28 October 2026, Anza announced Agave v4.4.0 as stable, recommended for 20% of mainnet stake and for testnet and devnet. Now, mainnet uses 4.3.2, so this is what validators will move to over the next few weeks. It adds three new gates, alongside the SIMD-0290 gate that was already in 4.3 and waits to be activated, along with a brief list of RPC and operator changes. None of the gates are active, but two change the content of blocks and program accounts, so check before they flip.

Key Takeaways

  • SIMD-0290 lets blocks have transactions whose fee payer can't pay. Transactions like that show up as failed, with a zero fee and no logs.
  • SIMD-0433 makes program upgrades resize the program data account to the new binary, refunding surplus rent.
  • SIMD-0317 requires 32:32 FEC sets, and SIMD-0599 removes inactive stake from reward calculations.
  • Rent is already down to 5,080 lamports per byte on mainnet; the next cut to 2,575 awaits testnet.
  • getTransaction and getSignatureStatuses support minContextSlot, and account subscriptions obey dataSlice.

This guide is for developers deploying indexers, bots, and programs on Solana, as well as for everybody who works with raw blocks.

Where things stand

We read the gate accounts on mainnet and testnet directly on 29 October 2026 (mainnet epoch 1071).

Feature gate status on 29 October

The timing is important to remember. Epochs are still 432,000 slots long, and on our Amsterdam node it took about 25.5 hours each to process epochs 1069 and 1070, with an average slot duration of 213 milliseconds once skipped slots are counted. Gates activate at epoch boundaries, so a scheduled activation becomes live about a day later.

SIMD-0290: blocks can carry transactions that cannot pay

Today, the presence of just one transaction whose fee payer can't pay enough to cover the fee makes the whole block invalid. With SIMD-0290, this requirement is relaxed for recent-blockhash transactions (and durable nonce transactions are waiting for SIMD-0297 activation). Such a transaction stays in the block but doesn't execute anything. It is a step towards asynchronous execution.

We reviewed the 4.4.0 codebase to learn how such transactions are recorded in the block:

  • The status of a transaction is an error, the same error that used to make the whole block invalid, for instance InsufficientFundsForFee or AccountNotFound.
  • The fee is zero. Nothing transfers and account states don't change.
  • There are no log messages, inner instructions, or return data.
  • Such a transaction contributes to block limits according to its full requested compute unit limit, rather than actual usage. This makes it impossible for a leader to stuff too many free transactions into a block.

Calculations that sum meta.fee over failed transactions will give incorrect results here, and algorithms that expect every failed transaction to have logs or a paid fee payer need to be checked. Consider a transaction failure with zero fee and no logs as "included, not executed".

SIMD-0433: program upgrades resize the account

Loader v3 allows increasing the size of a program data account using ExtendProgram, but never reducing it, meaning that when a program is rewritten to a smaller binary (like in the case of Pinocchio), it keeps paying rent for the original size. Once SIMD-0433 activates, the Upgrade operation resizes the account to fit the new ELF plus metadata header. The surplus rent is refunded to the spill account, and a larger binary grows the account without a separate ExtendProgram call.

Before the next deployment after the activation, make sure that:

  • The spill account exists. It is where the refunds will go, so make sure that it is your account.
  • The lamports for growth. The extra rent should be in the program data account or in its buffer prior to Upgrade, otherwise it fails with InsufficientFunds.
  • The rent you overpaid earlier. Upgrading resets the account balance to the minimum required rent and sends the rest to the spill account, even without SIMD-0433. Programs deployed before the two rent cuts receive some of the deposit back on the next upgrade.
  • Upgrades via CPI. Multisig and governance programs that upgrade a program via CPI still have the 10 KiB per-instruction growth limit. Perform the ExtendProgram operation in several iterations first to increase the size, or upgrade on the top level.

SIMD-0317: fixed 32:32 FEC sets

Blocks transit through Turbine as shreds, grouped into forward error correction (FEC) sets. Every client already sends 32 data shreds and 32 coding shreds per set, but receivers still accept all kinds of combinations. SIMD-0317 mandates 32:32 sets, and any other set will be dropped on ingest. The gate checks the size of the Merkle proof generated from a 64-shred set in the codebase.

It also fixes the size: 995 bytes of payload in each data shred and 31,840 bytes per set. Receivers can validate shred indices without waiting for coding shreds, and two valid shreds from one set with distinct Merkle roots prove equivocation. There is no practical difference for teams decoding shreds themselves, including ShredStream consumers, as the senders use the same format anyway.

SIMD-0599: inactive stake leaves the rewards path

Partitioned epoch rewards currently traverse every stake account regardless of whether it has effective or activating stake in it. They earn nothing, but they still affect the number of partitions and the lattice hash. SIMD-0599, jointly developed by Anza and Firedancer engineers, removes stake that didn't have any effective or activating stake in the whole rewarded epoch from this calculation.

Stakes that deactivate at the boundary still receive rewards for their last epoch, and the users see no difference. The optimization is significant though. Scanning the mainnet stake accounts on our Amsterdam node we found that out of 1,364,680 delegated stake accounts 232,962 (17.1%) were completely inactive, storing about 3.28 million SOL. All of these accounts, every client processes at every epoch boundary now.

Rent: two steps live, step three gated

SIMD-0437 reduces the lamports_per_byte parameter from 6,960 to 696 in five steps, each separately gated. The first and the second step are live on mainnet. The third one, down to 2,575, is already in 4.3.0-rc.1 and is pending activation on testnet. The fourth and fifth steps (to 1,322 and 696) are not on the activation schedule yet.

This is how the rent for a standard 165-byte token account (rent is calculated on the size of the data + 128-byte overhead) looks now:

Rent for a 165-byte token account

Any hardcoded 2039280 in the code is already incorrect on mainnet. Always calculate the minimum rent from getMinimumBalanceForRentExemption or the Rent sysvar, because this value changes three more times.

RPC and operator changes in 4.4

These updates come with the binary and don't wait for a gate:

  • getTransaction supports minContextSlot.
  • getSignatureStatuses supports commitment and minContextSlot, and still defaults to processed. If the node is behind, it returns error -32016, allowing load-balanced clients to retry on a different node and not get stale data.
  • accountSubscribe and programSubscribe respect dataSlice. A zero-length slice returns empty data, which is useful for watching lamport or owner changes without paying for the account data.
  • getLeaderSchedule returns the new error -32022 if the requested identity is not present in the schedule.
  • Validators running an external scheduler need version 5 of the bindings. The --experimental-retransmit-xdp-* command line flags are gone in favor of --xdp-interface, --xdp-cpu-cores and --xdp-zero-copy.

What this means on OrbitFlare

Our devnet already runs 4.4, and you can start experimenting with minContextSlot and dataSlice subscriptions right now. Our mainnet regions will follow Anza's adoption guidance without any changes in URLs, keys, or gRPC subscriptions. The gated changes will activate at the same slot for all nodes. What may require an update is your code: handling zero-fee failures, preparing the spill account for upgrades, and calculating rent at runtime.

Conclusion

Agave 4.4 looks quite uneventful on the surface. SIMD-0290 and SIMD-0317 move Solana towards validation that doesn't depend on execution, while SIMD-0433 and rent cuts make state maintenance less expensive. Check your indexer for zero-fee failures before the gate reaches testnet, and don't hardcode rent values.

Resources

  1. Agave v4.4.0 release
  2. Agave changelog
  3. Feature gate tracker schedule
  4. SIMD-0290: Relax fee-payer constraint
  5. SIMD-0433: Loader v3, set program data to ELF length
  6. SIMD-0317: Enforce 32 data + 32 coding shreds
  7. SIMD-0599: Remove inactive stakes from rewards
  8. SIMD-0437: Incremental rent reduction

Frequently asked questions

Is Agave 4.4 live on Solana mainnet?
Agave v4.4.0 was released as stable on 28 October 2026 and is recommended for 20% of mainnet stake. Most of mainnet still runs 4.3.2, and none of the feature gates covered here (SIMD-0290, 0433, 0317 and 0599) is active on any cluster yet.
How do transactions with an invalid fee payer appear after SIMD-0290?
They are included in the block but not executed. Their status is an error such as InsufficientFundsForFee, the fee is zero, there are no logs, and they count against block limits at their full requested compute unit limit.
What is the current rent-exempt minimum for a token account?
With 5,080 lamports per byte live on mainnet, a 165-byte token account needs 1,488,440 lamports. It drops to 754,475 lamports when rent step 3 activates. Read it from getMinimumBalanceForRentExemption instead of hardcoding it.
Do I need to change anything on OrbitFlare for Agave 4.4?
No. Endpoints, keys and gRPC subscriptions stay the same. The changes to make are in your own code: handling zero-fee failed transactions, checking the spill account on program upgrades, and reading rent at runtime.

About the author

Sourav Mishra

Solutions Engineer · OrbitFlare

Sourav Mishra help build low-latency Solana infrastructure at OrbitFlare — shred streaming, gRPC pipelines, and eBPF-powered networking, mostly in Rust. He writes the kind of deep dives he wishes existed when he started: what a shred actually is, why Solana's VM shares a lineage with the packet filter in your kernel, and how to get transaction data out of the network before everyone else does.

More articles by Sourav Mishra
Thanks for reading.Back to all articles

Code. Build. Stream. Without Limits.

Build something that moves.

Choose your infrastructure. We’ll help you find the right setup.

A useful starting point

Edit the brief, then copy it and open your assistant. Paste it into a new chat to get started.

Official sources included. You choose when to send.