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
---
Originally published at orbitflare.com.
Alpenglow: How Solana Swaps Its Consensus in One Slot
Solana consensus has been using the same design since 2020. Every validator publishes votes as transactions in the blocks, adds increasingly strong lockouts and declares a block final once 32 more blocks have built upon it. It works, but it lacks a published safety proof, consumes over half of all transactions in the network, and its finality takes seconds despite the rest of the stack working in milliseconds.
Alpenglow is its replacement. The design is due to Quentin Kniep, Jakub Sliwinski, and Roger Wattenhofer, who left ETH Zurich and joined Anza after publishing their research on liveness issues in TowerBFT. Alpenglow was published in May 2025. Validators approved SIMD-0326 in September 2025 with 98.27% of participating stake in favor, and the protocol has been running on a community cluster privately for five months, undergone a bug bounty, rehearsed nine migrations and flipped on testnet and devnet. Mainnet is next.
Why TowerBFT Has to Be Replaced
There are three layers in today's consensus. Proof of History provides validators with a shared clock through continuous hashing. Turbine propagates blocks via a tree of validators, and Alpenglow will preserve this functionality for now. TowerBFT is a voting layer where every validator sends a transaction with the vote for the block it received, and this vote transaction is included into a future block similarly to others. Once there are 32 blocks built upon a block, it is rooted.
This 32-slot wait is responsible for the famous 12.8-second delay at 400-ms slots. Slots are 200 ms now under SIMD-0525, so the wait takes about 7 seconds on mainnet. Way before this moment, the block is optimistically confirmed at 66% of stake, which is what confirmed reports and most applications use.
The reasons for switching to Alpenglow are listed explicitly in SIMD-0326. Finality is slow for anyone requiring a no-rollback guarantee. Vote transactions make up between 54% and 59% of all mainnet transactions in late September 2026, according to Solana Compass, and each of them costs the validator about 5,000 lamports, which adds up to roughly 2.16 SOL per epoch. The votes go through gossip and are verified on chain. And, finally, TowerBFT lacks a formal safety proof. Votor solves all four of these.
Votor: Two Voting Paths at Once
The leader broadcasts the block in chunks via erasure coding. The moment a validator receives a valid and complete block with a parent block that it has already voted for, it broadcasts the notarization vote directly to every other validator. There is no transaction and no gossip here, just a signed UDP message. Then two paths of actions begin at the same time.
First, the fast path: if some validator collects notarization votes from 80% of stake, it puts together the fast-finalization certificate and declares the block final after a single round. Then the slow path: once 60% of stake has notarized, every validator casts a finalization vote, and a finalization certificate is created from 60% of them.
The first path to succeed wins. If 80% of stake is close to you, the fast path wins. If only 60% is close to you, two fast rounds among the latter can beat the single slow round that needs to gather 80%. The protocol does not have to guess the case.
!Two ways to final, one way to skip
!What each certificate needs to form
The 80% and 60% thresholds are a result of the fault model. Under 20% Byzantine stake, any 60% certificate will be composed of votes from over 40% of honest stake, and since any honest validator can cast only one notarization or skip vote per slot, it is impossible for two different blocks to gather 60%. This is the basis of the safety proof of the algorithm. Every certificate consists of one BLS aggregate signature and a bitmap of signers, and thus is small enough to fit in one UDP message.
Timeouts are replacing PoH. When a validator receives a certificate for the block before the leader's four-slot window, it sets a timer for each slot in this window at once. In Agave, the base timeout is 400 ms plus one block time per slot, so at 200 ms blocks, the first slot in a window times out 600 ms after the parent block becomes ready. If the block arrives first, the validator votes for it. If the timer fires first, it broadcasts a skip vote for this slot and all subsequent unvoted slots in this window. No clocks need to be synchronized, as every validator just measures local short intervals. A skip certificate at 60% is a definitive outcome, and the next leader builds upon the latest notarized block, effectively ignoring the skipped slot.
Two fallback votes help to deal with leaders broadcasting different blocks to different validators. A validator who skips a block can switch to a notar-fallback vote once it notices 40% of stake notarizing a block, while a notarizing validator can switch to skip-fallback once it becomes obvious that no block can collect 80%. This guarantees that every slot will end with either a notarized block or a skip certificate. If no slot finalizes for 10 seconds, the validators rebroadcast their latest certificates and increase timeouts by 5% per window, so eventually even a regional outage resolves itself without coordination.
The 20+20 Model, Honestly
The main claim is that Alpenglow tolerates 40% of stake going down. This is correct, but an imprecise statement, and an accurate one is important.
Under complete asynchrony, Alpenglow is safe as long as Byzantine stake is less than 20%. Even an adversary controlling the whole network and delaying every message could not make two honest nodes finalize conflicting blocks. In addition to this, 20% of crashed stake does not affect the safety. As long as the propagation layer does not deliver different blocks for the same slot to different honest nodes, liveness is preserved. Thus, crash-only faults under 40% stake are always tolerated.
However, an adversary who controls a leader with 18% stake and can partition the honest network into two isolated clusters and broadcast different blocks to each of them can stall a slot. A well-distributed validator set makes it hard to do, but it is a known liveness attack. Therefore, understand 40% fault tolerance as 20% malicious plus 20% crashed, not as 40% malicious.
Compared with TowerBFT's 33% Byzantine bound, Alpenglow is worse against a coordinated attack by more than 20% and less than 33% of stake and better against anything else. The trade-off here is that in a large proof-of-stake network, a coordinated attack by a third of stake is not the most likely scenario. Bugs, misconfigurations and outages are, and these correspond to crashes. Signing two conflicting votes is a provable violation under SIMD-0326, but slashing is a separate proposal and is not live yet.
Rotor Is Not Shipping Yet
Rotor is the second part of the design. It replaces Turbine's multilayer tree with a single layer of stake-weighted relays, and makes the leader's upload bandwidth not a limit anymore. Reaching 80% of stake would take around 150 nodes and roughly 2 ms. This is not included in the planned 21 October activation. The Foundation marks it as a feature for a later stage without any date, SIMD-0326 carves it out for its own proposal, and Turbine remains. Fast leader handover and geo-aware handoff are postponed as well.
Votes Are Out of the Blockchain
Three changes happened on the mainnet months before the migration to make off-chain voting possible.
BLS keys (SIMD-0387, July 8, 2026). Since the Ed25519 signatures cannot be aggregated, every validator had to register a 48-byte BLS public key in its vote account with proof of possession. A vote account without one will behave like unstaked when Alpenglow is active, and getVoteAccounts will show a blsPubkeyCompressed field, which is null for those accounts that haven't performed this operation.
The Validator Admission Ticket (SIMD-0357, July 22, 2026). Once the vote transactions are gone, the vote fees disappear too. The VAT replaces them with a flat fee, burned from the vote account at the beginning of each epoch, and gives admission to the next epoch. It was 1.6 SOL per epoch at 400 ms slots and scales with slot time, so at today's 200 ms slots, it is 0.8 SOL per epoch, compared with roughly 2.16 SOL that validators spend on vote fees now. The first charge will be done at the beginning of epoch 1064 and funds epoch 1065. A vote account that cannot pay is not admitted, and that validator neither votes nor produces blocks for the next epoch. The set of admitted validators is capped at 2,000 by stake, which is way above the roughly 680 voting validators today.
Rewards continue to exist. The leader of slot s+8 may include BLS aggregations of votes received for slot s; each included vote earns its voter a share of issuance, and the leader earns the same as each voter for performing the aggregation.
Thus, the practical outcome is that the vote account, not the identity account, has to remain funded. Anza recommends routing block revenue into the vote account to cover VAT automatically and warns that the reward paid at the epoch boundary is too late to rescue a validator that lacks funds at the admission time.
The Migration: Switching Consensus Engines in One Slot
SIMD-0384 describes the process of switching. Its goal is that no user-signed transaction should be dropped and if the migration fails, nothing will happen at all.
!Four steps from TowerBFT to Votor
Activation. The feature gate becomes active at epoch 1064, which starts at slot 459,648,000, and the Foundation expects it to start around 15:00 UTC on Wednesday, 21 October. For now, nothing changes.
Boundary. Exactly 5,000 slots later, at slot 459,653,000 and about 18 minutes afterward, leaders start packing vote transactions only into blocks. Honest validators will mark any block with a user transaction as dead, and TowerBFT will stop rooting. Since all further blocks will contain only votes, rollbacks of any of them incur zero cost to users.
Genesis. The validators will wait for the block at or after the boundary carrying TowerBFT votes from at least 82% of stake in its direct child. Blocks usually carry votes from over 95% of stake, so the boundary block will usually pass immediately. The last block prior to the boundary in this chain will become Alpenglow's genesis block, every validator will sign a BLS genesis vote for it, and with 82% of stake, the genesis certificate will form.
Handoff. Seeing the valid certificate, every validator will launch Votor from the genesis block, disable TowerBFT, roll back all blocks past the genesis in the same way duplicate-block handling works, and enable user transactions again. The genesis certificate will be recorded in the first Alpenglow block and in an on-chain account, so a validator restarting from a later snapshot will know what consensus engine to run. Anza estimates the handoff to take hundreds of milliseconds, and Triton One estimates a user-visible gap of about two slots.
If 82% never signs the genesis, there will be no abort step, as there is no need for it. The validators will continue using TowerBFT, and the migration will not complete. There is no intermediate phase when the chain uses neither engine.
The client diversity issue. Firedancer's v26.10.2 release published on 14 October and labeled as mainnet ready supports Alpenglow consensus, but not the migration from TowerBFT to Alpenglow. So, for the migration itself, every validator must use a client descended from Agave 4.3.0, and that is practically Agave, Jito-Solana or Harmonic Salsa, and then may switch back to Firedancer. According to Solana Compass, as of 13 October, about 15.8% of stake among the top 500 validators used Firedancer-family clients. If this stake stays as is, what remains is barely above the 82% threshold. Anza has been quite explicit that these operators have to switch beforehand.
The Track Record
The community cluster became operational on 11 May 2026 with over 40 nodes. The first migration attempt uncovered two bugs that Anza acknowledged on the validator call of the Foundation and hotfixed. The next attempt completed successfully, and the cluster has been running since then. A public explorer shows the finalization time of about 107 ms and around 96% of blocks taking the fast path. A bug bounty lasted from August 5 to August 19, and featured a fund of up to 50,000 SOL, 115 researchers and more than 300 submissions. Anza has reported payouts exceeding 25,000 SOL, though the breakdown of severity has not been published. Testnet flipped on September 24 at slot 444,625,255, and devnet on September 25 at slot 504,148,999. Agave 4.3 including the full Alpenglow code was recommended for all mainnet validators on September 21.
The 150 ms figure is based on the latency simulation with real validator latencies, with a median around 110 to 130 ms and the slowest node below 200 ms. Consider it an expectation, not a fixed number. A 54 ms testnet median circulated without any publicly named source, so we do not reproduce it.
What Will Change for Developers
Execution will not change. The SVM, transaction formats, programs, fees and priority fees will stay the same. All below is about consensus outputs and data you rely on.
- Commitment levels. confirmed and finalized converge to the same state, defined as 60% of stake voting to finalize or 80% of stake notarizing, and finalized will arrive about 150 ms after the block instead of 32 slots later. They both will work on the activation day, and confirmed commitment level is scheduled for future removal, so use finalized in new code. Do not switch early. Until the genesis certificate is present, finalized commitment on the mainnet still means a 32-slot wait. Check getAgGenesisCert on your RPC, which will return null under TowerBFT and a certificate object once Alpenglow is live. The meaning of getBlockCommitment disappears, as there is no lockout stack to report.
- Transaction counts. Vote transactions will disappear from blocks, so per-block counts and every TPS chart will drop by over half without any change in actual activity. Adjust alerting thresholds before 21 October.
- Multiple candidate blocks per slot. A leader may produce multiple blocks for a slot, and only one will be notarized, so Agave 4.3 will tag Geyser events with a bank_id, and Yellowstone gRPC will expose it. If you build blocks from transactions or account updates, group them by slot and bank id, keep the candidate that reached confirmed and discard others. The ids are node-local, so align blocks across providers by blockhash only. The four legacy Geyser callbacks become deprecated in favor of bank-scoped ones.
- Ticks and block footer. PoH ticks will disappear from the shred stream. Alpenglow blocks start with a BlockHeader marker and will end with a versioned footer (SIMD-0307) containing the producer timestamp, a client user-agent string and the leader's latest finalization certificate. The footers are accessible via a gRPC opt-in filter, but are not accessible via JSON-RPC yet.
- Clock sysvar. The layout will be the same, but the unix_timestamp will become set by the leader in a bounded range, not derived from a stake-weighted median of votes. Use it as an approximation.
- Blockhash expiration. Slots still exist, and the 150-slot window will remain the same, corresponding to about 32 seconds at current slot timing. Fetch blockhashes at confirmed or higher, as a hash of a vote-only block that will be rolled back during the migration is useless.
- Yellowstone gRPC. The plugin release for Alpenglow is v16.0.0-rc10+solana.4.3.0. Old clients will continue streaming but will not be able to see bank_id and footers.
- Migration day for bots. Expect one or two slots of vote-only blocks somewhere near the boundary, followed by a small break in the slot numbering sequence. Read at confirmed through that window, and hold back from the activation slot until the genesis certificate appears if you are conservative. Jito’s BAM nodes will go into maintenance mode during the transition.
Requirements for Validators. If you operate a validator, here are the three requirements you need to satisfy: operate a client based on Agave 4.3.0, since Firedancer can’t help you through the transition; register a BLS key and confirm it with solana vote-account; keep the vote account balance at the rent-exempt minimum plus 0.8 SOL before epoch 1064, with a refill plan. Otherwise, you’ll be left outside the admitted set and earn nothing until you sort it out.
Things That Alpenglow Does Not Do
- It does not improve throughput. “100 times improvement” is about finality latency, not block limits, execution, and compute budget.
- It did not cut the slot time. The transition from 400 ms to 200 ms was SIMD-0525, implemented in four phases from August to October, unrelated to Alpenglow.
- It does not eliminate MEV. The window from block visibility to finality narrows to around 150 ms, thus squeezing the latency arbitrage space, but it does not change the block building incentives.
- It does not bring in slashing, Rotor, or fast leader handover.
- It is not quantum-resistant. There is an experimental quantum-resistant hash-signature scheme called Quantumglow, with no plans on the schedule yet.
Implications for Building on OrbitFlare
As we run RPC, WebSocket, Yellowstone gRPC, Jetstream, and Shredstream, all the above features land on our infrastructure stack and on yours.
RPC and WebSocket users will benefit the most for free. Once getAgGenesisCert starts returning a certificate on mainnet, the guaranteed finalized state will come in a sub-second timeframe, and your signature status flow will respond even faster. Do not switch to finalized prematurely, and do reset any alerts about transaction counts. The gap described in our commitment levels explainer between confirmed and finalized is going away.
Yellowstone gRPC and Jetstream users should implement bank_id processing mentioned above if they build blocks from the transaction-level data and upgrade to the Alpenglow client release prior to activation day. For Jetstream users who act on decoded transactions at processed, their logic will remain the same, but the window where that data is ahead of finality will become shorter, from seconds to about 150 ms.
Shredstream users will be impacted the least as Turbine will stay, and so will shreds. Ticks will disappear, blocks will acquire a header marker and a footer, and under SIMD-0337 the FEC sets will be fixed at 32 data shreds plus 32 coding shreds. Rotor, when it ships, is the change that touches the propagation path, and our Shredstream piece covers how the current one works.
In case you are uncertain about your category, contact us in the OrbitFlare Discord channel prior to activation rather than after.
The Short Version
Alpenglow is a protocol with published proofs, a fault model that is worse for one particular type of attacker, but better for all others, and a migration that cannot lose user transactions or leave the chain between two engines. The primary risk on 21 October is not about the protocol itself; it is about ensuring that all validators run a single client family for the transition, and about one sixth of stake has to move before then. If the transition experience repeats the testnet and devnet one, then the transition will take a few hundred milliseconds, and Solana will wake up with 150 ms finality and votes off the chain.
---
OrbitFlare is a Solana infrastructure layer providing RPC, WebSocket, Yellowstone gRPC, Jetstream shred-decoded streaming, and Shredstream services.
Resources
1. Solana Alpenglow Consensus white paper v1.2 (Kniep, Sliwinski, Wattenhofer, Anza)
2. SIMD-0326: Alpenglow
3. SIMD-0384: Alpenglow Migration
4. Solana Foundation upgrade page: Alpenglow
5. Alpenglow operator documentation (Anza docs)
6. Alpenglow on Mainnet: What to Update (Triton One)
---
Originally published at orbitflare.com.
Mentions
this could be the most important SIMD in the history of solana: >unlocks neural nets onchain >unlocks cryptography onchain neural nets unlock more advanced models onchain cryptography unlocks privacy onchain both unlock gigacapital onchain solana-improvement-documents#714
p-ATA SIMD is merged. Cluster-wide CU reduction in the pipeline. solana-improvement-documents#567
Excited about @bw_solana 's proposal to formally specify the @solana protocol: solana-improvement-documents#716 wen Solana validator ASIC
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 --- Originally published at orbitflare.com.
every day i wake up and i solana solana-improvement-documents#708
Alpenglow: How Solana Swaps Its Consensus in One Slot Solana consensus has been using the same design since 2020. Every validator publishes votes as transactions in the blocks, adds increasingly strong lockouts and declares a block final once 32 more blocks have built upon it. It works, but it lacks a published safety proof, consumes over half of all transactions in the network, and its finality takes seconds despite the rest of the stack working in milliseconds. Alpenglow is its replacement. The design is due to Quentin Kniep, Jakub Sliwinski, and Roger Wattenhofer, who left ETH Zurich and joined Anza after publishing their research on liveness issues in TowerBFT. Alpenglow was published in May 2025. Validators approved SIMD-0326 in September 2025 with 98.27% of participating stake in favor, and the protocol has been running on a community cluster privately for five months, undergone a bug bounty, rehearsed nine migrations and flipped on testnet and devnet. Mainnet is next. Why TowerBFT Has to Be Replaced There are three layers in today's consensus. Proof of History provides validators with a shared clock through continuous hashing. Turbine propagates blocks via a tree of validators, and Alpenglow will preserve this functionality for now. TowerBFT is a voting layer where every validator sends a transaction with the vote for the block it received, and this vote transaction is included into a future block similarly to others. Once there are 32 blocks built upon a block, it is rooted. This 32-slot wait is responsible for the famous 12.8-second delay at 400-ms slots. Slots are 200 ms now under SIMD-0525, so the wait takes about 7 seconds on mainnet. Way before this moment, the block is optimistically confirmed at 66% of stake, which is what confirmed reports and most applications use. The reasons for switching to Alpenglow are listed explicitly in SIMD-0326. Finality is slow for anyone requiring a no-rollback guarantee. Vote transactions make up between 54% and 59% of all mainnet transactions in late September 2026, according to Solana Compass, and each of them costs the validator about 5,000 lamports, which adds up to roughly 2.16 SOL per epoch. The votes go through gossip and are verified on chain. And, finally, TowerBFT lacks a formal safety proof. Votor solves all four of these. Votor: Two Voting Paths at Once The leader broadcasts the block in chunks via erasure coding. The moment a validator receives a valid and complete block with a parent block that it has already voted for, it broadcasts the notarization vote directly to every other validator. There is no transaction and no gossip here, just a signed UDP message. Then two paths of actions begin at the same time. First, the fast path: if some validator collects notarization votes from 80% of stake, it puts together the fast-finalization certificate and declares the block final after a single round. Then the slow path: once 60% of stake has notarized, every validator casts a finalization vote, and a finalization certificate is created from 60% of them. The first path to succeed wins. If 80% of stake is close to you, the fast path wins. If only 60% is close to you, two fast rounds among the latter can beat the single slow round that needs to gather 80%. The protocol does not have to guess the case. !Two ways to final, one way to skip !What each certificate needs to form The 80% and 60% thresholds are a result of the fault model. Under 20% Byzantine stake, any 60% certificate will be composed of votes from over 40% of honest stake, and since any honest validator can cast only one notarization or skip vote per slot, it is impossible for two different blocks to gather 60%. This is the basis of the safety proof of the algorithm. Every certificate consists of one BLS aggregate signature and a bitmap of signers, and thus is small enough to fit in one UDP message. Timeouts are replacing PoH. When a validator receives a certificate for the block before the leader's four-slot window, it sets a timer for each slot in this window at once. In Agave, the base timeout is 400 ms plus one block time per slot, so at 200 ms blocks, the first slot in a window times out 600 ms after the parent block becomes ready. If the block arrives first, the validator votes for it. If the timer fires first, it broadcasts a skip vote for this slot and all subsequent unvoted slots in this window. No clocks need to be synchronized, as every validator just measures local short intervals. A skip certificate at 60% is a definitive outcome, and the next leader builds upon the latest notarized block, effectively ignoring the skipped slot. Two fallback votes help to deal with leaders broadcasting different blocks to different validators. A validator who skips a block can switch to a notar-fallback vote once it notices 40% of stake notarizing a block, while a notarizing validator can switch to skip-fallback once it becomes obvious that no block can collect 80%. This guarantees that every slot will end with either a notarized block or a skip certificate. If no slot finalizes for 10 seconds, the validators rebroadcast their latest certificates and increase timeouts by 5% per window, so eventually even a regional outage resolves itself without coordination. The 20+20 Model, Honestly The main claim is that Alpenglow tolerates 40% of stake going down. This is correct, but an imprecise statement, and an accurate one is important. Under complete asynchrony, Alpenglow is safe as long as Byzantine stake is less than 20%. Even an adversary controlling the whole network and delaying every message could not make two honest nodes finalize conflicting blocks. In addition to this, 20% of crashed stake does not affect the safety. As long as the propagation layer does not deliver different blocks for the same slot to different honest nodes, liveness is preserved. Thus, crash-only faults under 40% stake are always tolerated. However, an adversary who controls a leader with 18% stake and can partition the honest network into two isolated clusters and broadcast different blocks to each of them can stall a slot. A well-distributed validator set makes it hard to do, but it is a known liveness attack. Therefore, understand 40% fault tolerance as 20% malicious plus 20% crashed, not as 40% malicious. Compared with TowerBFT's 33% Byzantine bound, Alpenglow is worse against a coordinated attack by more than 20% and less than 33% of stake and better against anything else. The trade-off here is that in a large proof-of-stake network, a coordinated attack by a third of stake is not the most likely scenario. Bugs, misconfigurations and outages are, and these correspond to crashes. Signing two conflicting votes is a provable violation under SIMD-0326, but slashing is a separate proposal and is not live yet. Rotor Is Not Shipping Yet Rotor is the second part of the design. It replaces Turbine's multilayer tree with a single layer of stake-weighted relays, and makes the leader's upload bandwidth not a limit anymore. Reaching 80% of stake would take around 150 nodes and roughly 2 ms. This is not included in the planned 21 October activation. The Foundation marks it as a feature for a later stage without any date, SIMD-0326 carves it out for its own proposal, and Turbine remains. Fast leader handover and geo-aware handoff are postponed as well. Votes Are Out of the Blockchain Three changes happened on the mainnet months before the migration to make off-chain voting possible. BLS keys (SIMD-0387, July 8, 2026). Since the Ed25519 signatures cannot be aggregated, every validator had to register a 48-byte BLS public key in its vote account with proof of possession. A vote account without one will behave like unstaked when Alpenglow is active, and getVoteAccounts will show a blsPubkeyCompressed field, which is null for those accounts that haven't performed this operation. The Validator Admission Ticket (SIMD-0357, July 22, 2026). Once the vote transactions are gone, the vote fees disappear too. The VAT replaces them with a flat fee, burned from the vote account at the beginning of each epoch, and gives admission to the next epoch. It was 1.6 SOL per epoch at 400 ms slots and scales with slot time, so at today's 200 ms slots, it is 0.8 SOL per epoch, compared with roughly 2.16 SOL that validators spend on vote fees now. The first charge will be done at the beginning of epoch 1064 and funds epoch 1065. A vote account that cannot pay is not admitted, and that validator neither votes nor produces blocks for the next epoch. The set of admitted validators is capped at 2,000 by stake, which is way above the roughly 680 voting validators today. Rewards continue to exist. The leader of slot s+8 may include BLS aggregations of votes received for slot s; each included vote earns its voter a share of issuance, and the leader earns the same as each voter for performing the aggregation. Thus, the practical outcome is that the vote account, not the identity account, has to remain funded. Anza recommends routing block revenue into the vote account to cover VAT automatically and warns that the reward paid at the epoch boundary is too late to rescue a validator that lacks funds at the admission time. The Migration: Switching Consensus Engines in One Slot SIMD-0384 describes the process of switching. Its goal is that no user-signed transaction should be dropped and if the migration fails, nothing will happen at all. !Four steps from TowerBFT to Votor Activation. The feature gate becomes active at epoch 1064, which starts at slot 459,648,000, and the Foundation expects it to start around 15:00 UTC on Wednesday, 21 October. For now, nothing changes. Boundary. Exactly 5,000 slots later, at slot 459,653,000 and about 18 minutes afterward, leaders start packing vote transactions only into blocks. Honest validators will mark any block with a user transaction as dead, and TowerBFT will stop rooting. Since all further blocks will contain only votes, rollbacks of any of them incur zero cost to users. Genesis. The validators will wait for the block at or after the boundary carrying TowerBFT votes from at least 82% of stake in its direct child. Blocks usually carry votes from over 95% of stake, so the boundary block will usually pass immediately. The last block prior to the boundary in this chain will become Alpenglow's genesis block, every validator will sign a BLS genesis vote for it, and with 82% of stake, the genesis certificate will form. Handoff. Seeing the valid certificate, every validator will launch Votor from the genesis block, disable TowerBFT, roll back all blocks past the genesis in the same way duplicate-block handling works, and enable user transactions again. The genesis certificate will be recorded in the first Alpenglow block and in an on-chain account, so a validator restarting from a later snapshot will know what consensus engine to run. Anza estimates the handoff to take hundreds of milliseconds, and Triton One estimates a user-visible gap of about two slots. If 82% never signs the genesis, there will be no abort step, as there is no need for it. The validators will continue using TowerBFT, and the migration will not complete. There is no intermediate phase when the chain uses neither engine. The client diversity issue. Firedancer's v26.10.2 release published on 14 October and labeled as mainnet ready supports Alpenglow consensus, but not the migration from TowerBFT to Alpenglow. So, for the migration itself, every validator must use a client descended from Agave 4.3.0, and that is practically Agave, Jito-Solana or Harmonic Salsa, and then may switch back to Firedancer. According to Solana Compass, as of 13 October, about 15.8% of stake among the top 500 validators used Firedancer-family clients. If this stake stays as is, what remains is barely above the 82% threshold. Anza has been quite explicit that these operators have to switch beforehand. The Track Record The community cluster became operational on 11 May 2026 with over 40 nodes. The first migration attempt uncovered two bugs that Anza acknowledged on the validator call of the Foundation and hotfixed. The next attempt completed successfully, and the cluster has been running since then. A public explorer shows the finalization time of about 107 ms and around 96% of blocks taking the fast path. A bug bounty lasted from August 5 to August 19, and featured a fund of up to 50,000 SOL, 115 researchers and more than 300 submissions. Anza has reported payouts exceeding 25,000 SOL, though the breakdown of severity has not been published. Testnet flipped on September 24 at slot 444,625,255, and devnet on September 25 at slot 504,148,999. Agave 4.3 including the full Alpenglow code was recommended for all mainnet validators on September 21. The 150 ms figure is based on the latency simulation with real validator latencies, with a median around 110 to 130 ms and the slowest node below 200 ms. Consider it an expectation, not a fixed number. A 54 ms testnet median circulated without any publicly named source, so we do not reproduce it. What Will Change for Developers Execution will not change. The SVM, transaction formats, programs, fees and priority fees will stay the same. All below is about consensus outputs and data you rely on. - Commitment levels. confirmed and finalized converge to the same state, defined as 60% of stake voting to finalize or 80% of stake notarizing, and finalized will arrive about 150 ms after the block instead of 32 slots later. They both will work on the activation day, and confirmed commitment level is scheduled for future removal, so use finalized in new code. Do not switch early. Until the genesis certificate is present, finalized commitment on the mainnet still means a 32-slot wait. Check getAgGenesisCert on your RPC, which will return null under TowerBFT and a certificate object once Alpenglow is live. The meaning of getBlockCommitment disappears, as there is no lockout stack to report. - Transaction counts. Vote transactions will disappear from blocks, so per-block counts and every TPS chart will drop by over half without any change in actual activity. Adjust alerting thresholds before 21 October. - Multiple candidate blocks per slot. A leader may produce multiple blocks for a slot, and only one will be notarized, so Agave 4.3 will tag Geyser events with a bank_id, and Yellowstone gRPC will expose it. If you build blocks from transactions or account updates, group them by slot and bank id, keep the candidate that reached confirmed and discard others. The ids are node-local, so align blocks across providers by blockhash only. The four legacy Geyser callbacks become deprecated in favor of bank-scoped ones. - Ticks and block footer. PoH ticks will disappear from the shred stream. Alpenglow blocks start with a BlockHeader marker and will end with a versioned footer (SIMD-0307) containing the producer timestamp, a client user-agent string and the leader's latest finalization certificate. The footers are accessible via a gRPC opt-in filter, but are not accessible via JSON-RPC yet. - Clock sysvar. The layout will be the same, but the unix_timestamp will become set by the leader in a bounded range, not derived from a stake-weighted median of votes. Use it as an approximation. - Blockhash expiration. Slots still exist, and the 150-slot window will remain the same, corresponding to about 32 seconds at current slot timing. Fetch blockhashes at confirmed or higher, as a hash of a vote-only block that will be rolled back during the migration is useless. - Yellowstone gRPC. The plugin release for Alpenglow is v16.0.0-rc10+solana.4.3.0. Old clients will continue streaming but will not be able to see bank_id and footers. - Migration day for bots. Expect one or two slots of vote-only blocks somewhere near the boundary, followed by a small break in the slot numbering sequence. Read at confirmed through that window, and hold back from the activation slot until the genesis certificate appears if you are conservative. Jito’s BAM nodes will go into maintenance mode during the transition. Requirements for Validators. If you operate a validator, here are the three requirements you need to satisfy: operate a client based on Agave 4.3.0, since Firedancer can’t help you through the transition; register a BLS key and confirm it with solana vote-account; keep the vote account balance at the rent-exempt minimum plus 0.8 SOL before epoch 1064, with a refill plan. Otherwise, you’ll be left outside the admitted set and earn nothing until you sort it out. Things That Alpenglow Does Not Do - It does not improve throughput. “100 times improvement” is about finality latency, not block limits, execution, and compute budget. - It did not cut the slot time. The transition from 400 ms to 200 ms was SIMD-0525, implemented in four phases from August to October, unrelated to Alpenglow. - It does not eliminate MEV. The window from block visibility to finality narrows to around 150 ms, thus squeezing the latency arbitrage space, but it does not change the block building incentives. - It does not bring in slashing, Rotor, or fast leader handover. - It is not quantum-resistant. There is an experimental quantum-resistant hash-signature scheme called Quantumglow, with no plans on the schedule yet. Implications for Building on OrbitFlare As we run RPC, WebSocket, Yellowstone gRPC, Jetstream, and Shredstream, all the above features land on our infrastructure stack and on yours. RPC and WebSocket users will benefit the most for free. Once getAgGenesisCert starts returning a certificate on mainnet, the guaranteed finalized state will come in a sub-second timeframe, and your signature status flow will respond even faster. Do not switch to finalized prematurely, and do reset any alerts about transaction counts. The gap described in our commitment levels explainer between confirmed and finalized is going away. Yellowstone gRPC and Jetstream users should implement bank_id processing mentioned above if they build blocks from the transaction-level data and upgrade to the Alpenglow client release prior to activation day. For Jetstream users who act on decoded transactions at processed, their logic will remain the same, but the window where that data is ahead of finality will become shorter, from seconds to about 150 ms. Shredstream users will be impacted the least as Turbine will stay, and so will shreds. Ticks will disappear, blocks will acquire a header marker and a footer, and under SIMD-0337 the FEC sets will be fixed at 32 data shreds plus 32 coding shreds. Rotor, when it ships, is the change that touches the propagation path, and our Shredstream piece covers how the current one works. In case you are uncertain about your category, contact us in the OrbitFlare Discord channel prior to activation rather than after. The Short Version Alpenglow is a protocol with published proofs, a fault model that is worse for one particular type of attacker, but better for all others, and a migration that cannot lose user transactions or leave the chain between two engines. The primary risk on 21 October is not about the protocol itself; it is about ensuring that all validators run a single client family for the transition, and about one sixth of stake has to move before then. If the transition experience repeats the testnet and devnet one, then the transition will take a few hundred milliseconds, and Solana will wake up with 150 ms finality and votes off the chain. --- OrbitFlare is a Solana infrastructure layer providing RPC, WebSocket, Yellowstone gRPC, Jetstream shred-decoded streaming, and Shredstream services. Resources 1. Solana Alpenglow Consensus white paper v1.2 (Kniep, Sliwinski, Wattenhofer, Anza) 2. SIMD-0326: Alpenglow 3. SIMD-0384: Alpenglow Migration 4. Solana Foundation upgrade page: Alpenglow 5. Alpenglow operator documentation (Anza docs) 6. Alpenglow on Mainnet: What to Update (Triton One) --- Originally published at orbitflare.com.
IBRL solana-improvement-documents#693