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.
getTransactionandgetSignatureStatusessupportminContextSlot, and account subscriptions obeydataSlice.
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).

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
InsufficientFundsForFeeorAccountNotFound. - 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 withInsufficientFunds. - 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
ExtendProgramoperation 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:

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:
getTransactionsupportsminContextSlot.getSignatureStatusessupportscommitmentandminContextSlot, and still defaults toprocessed. If the node is behind, it returns error -32016, allowing load-balanced clients to retry on a different node and not get stale data.accountSubscribeandprogramSubscriberespectdataSlice. A zero-length slice returns empty data, which is useful for watching lamport or owner changes without paying for the account data.getLeaderSchedulereturns 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-coresand--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.
