Agave 4.3 Update: All You Need to Know

Introduction

With Agave 4.3, Solana is preparing for arguably the largest protocol upgrade ever. The 4.3 release cycle will usher in Alpenglow, Solana's highly anticipated new consensus mechanism, culminating in "Alpenswitch": the coordinated mainnet transition away from TowerBFT.

Since launch, Solana's consensus architecture has been built around Proof of History and TowerBFT. Validators vote by submitting transactions that are processed and included in blocks alongside regular user transactions. Finality then accumulates as those votes build up across 32 slots, giving Solana a finality time of roughly 12.8 seconds (assuming 400-millisecond slot times).

Proof of History (PoH) was one of Solana's defining architectural innovations at launch, with its unique approach to ordering events and coordinating time. Its eventual sunsetting therefore marks the end of an era, and highlights how far the protocol has evolved from the technologies that originally set it apart.

Alpenglow replaces 'PoH + TowerBFT' with Votor, a protocol in which validators exchange votes outside the core transaction pipeline. It aggregates these votes into cryptographic certificates. The design targets finality in ~150 milliseconds.

For users and applications that submit transactions and read account state, there is little or nothing to migrate. Transactions and fee mechanics remain unchanged. Validators and infrastructure that consume blocks, votes, streams, or commitment data will feel the biggest adjustments.

Vote transactions disappear from blocks, confirmed and finalized effectively converge, and streaming infrastructure gains new information for distinguishing competing banks within the same slot.

In this article, we'll look at how Alpenglow works, including what Votor changes for block production and finality. We'll also cover other notable changes arriving across the Agave 4.3 release cycle.

Staged Rollout: Votor first, then Rotor

Alpenglow was designed around two major components, Votor, which replaces Solana's voting and finality mechanism, and Rotor, which redesigns how blocks propagate across the network. These two mechanisms will roll out in stages, with Votor arriving first.

Agave 4.3 introduces Votor while retaining the existing block propagation protocol, Turbine. Rotor was explicitly excluded from SIMD-0326, the proposal governing Alpenglow's initial activation. It will require its own SIMD before it can be deployed. The initial rollout changes how validators reach consensus, but not yet how block data moves across the network.

Votor

Votor replaces TowerBFT's vote transactions and lockouts system with a more direct validator-to-validator protocol. Under TowerBFT, validators vote by submitting transactions which are included in blocks, eventually accumulating enough lockout depth for a block to become finalized. Under Votor, validators instead exchange signed vote messages directly, and the protocol aggregates those signatures into compact certificates.

Rather than waiting for votes to accumulate over 32 slots, Votor can finalize a block after either one or two rounds of voting. The protocol targets finality of ~150 milliseconds, compared with ~12.8 seconds under TowerBFT.

Votor has two paths to finality that operate concurrently.

If at least 80% of stake notarizes a block in the first round, those votes can be aggregated into a Fast-Finalization Certificate, and the block is immediately final. This is the protocol's fast path and requires only a single round of voting.

If the 80% threshold is not reached, a block can still progress if more than 60% of stake has voted to notarize it. This produces a Notarization Certificate which allows for a second round of voting. Once more than 60% of stake casts finalization votes through the two-round path, this forms a Finalization Certificate, making the block final.

The full protocol therefore has five vote types: Notarization, Notarization Fallback, Skip, Skip Fallback, and Final. Different combinations of these votes produce notarization, fallback, skip, or finalization certificates. These certificates act as compact cryptographic evidence that enough stake has agreed on a slot's outcome.

Votor is designed to continue making progress with as little as 60% responsive honest stake, allowing up to 20% of stake to behave adversarially while another 20% is offline or unresponsive. The trade-off is deliberate: Alpenglow gives up the traditional one-third Byzantine threshold of BFT designs in exchange for a 20+20 resilience model with greater tolerance for crashed or unavailable validators.

Votor also removes the use of Proof of History as the consensus clock. Validators use local timeout timers instead. If a validator has waited long enough without receiving an acceptable block, it can cast a skip vote and allow consensus to move on. This simplifies the relationship between timekeeping and consensus compared with TowerBFT.

Rotor

Rotor is not part of Agave 4.3, and there is currently no published activation date. Turbine will therefore continue carrying block data when Votor activates. Rotor, along with the smart-sampling mechanism used to select its relays, will go through a separate proposal and rollout later.

Importantly, this does not mean that Solana must wait for Rotor to achieve sub-second finality. The current Alpenglow rollout targets ~150 ms finality with Votor in Agave 4.3 while Turbine remains in place. Rotor is intended to improve block dissemination further and make the broader Alpenglow architecture more efficient, but it is not a prerequisite for Votor's new finality model.

No More Vote Transactions

One of the most visible consequences of Alpenglow will be the disappearance of vote transactions from Solana blocks. Validators pay transaction fees for these votes, and the network spends bandwidth, compute, and ledger space processing and storing them.

Historically, vote transactions have accounted for roughly three-quarters of all transactions recorded onchain, a ratio that has fallen as block capacity has increased. While vote transactions are cheap (5,000 lamports) and account for only a small fraction (~5%) of overall compute, they inflate the network's raw transaction count and ledger footprint.

With Alpenglow validators, instead, exchange BLS-signed vote messages directly with one another. Agave's ConsensusPool tracks the votes it has observed and aggregates sufficient stake into the certificates used by Votor to advance or finalize consensus.

That does not mean evidence of validator participation disappears from the ledger. Alpenglow blocks introduce a new block footer containing consensus information. In the current Agave implementation, BlockFooterV1 can carry the latest finalization certificate as well as notar_reward_cert and skip_reward_cert. The reward certificates include an aggregate BLS signature and a bitmap identifying the validators that have voted.

Systems that currently determine whether a validator voted by indexing Vote Program transactions will need to move to Alpenglow's certificates and vote-related data instead. Existing transaction pipelines that simply filter vote transactions can generally continue operating; the filter will simply have nothing to remove after Alpenswitch.

The switch also creates a discontinuity in Solana's familiar TPS statistics. Once Alpenglow activates, raw TPS measurements that include vote transactions will drop sharply even if user activity remains completely unchanged. Non-vote TPS is therefore the meaningful metric for comparing activity before and after Alpenswitch. Removing vote transactions eliminates a long-standing source of confusion around Solana's actual throughput and will make comparisons with peer networks easier.

Removing vote transactions returns some capacity to users, but the effect should not be overstated given votes are a relatively small portion of the network's compute load.

Commitment Levels

Alpenglow also collapses one of Solana's long-standing distinctions: the gap between confirmed and finalized commitment.

Today, applications choose between three commitment levels. processed provides the freshest view but carries no cluster-wide guarantee. confirmed means that a supermajority of stake has voted for the block, typically arriving within a slot or two. finalized provides deterministic finality, but under TowerBFT requires the block to reach maximum vote lockout, creating a gap of roughly 32 slots between confirmation and finalization. Generally, confirmed is recommended for latency-sensitive RPC requests and finalized when a stronger guarantee is required.

In practice, confirmed has proved extremely reliable: no optimistically confirmed Solana block has ever subsequently failed to finalize. But the protocol guarantee is still weaker. A confirmed block is not yet deterministically final, and applications such as bridges, exchanges, and settlement systems that cannot tolerate such residual tail risk have historically had to wait for finalized.

Alpenglow removes this trade-off. Once Votor produces either a fast-finalization or finalization certificate, the block is final. When Votor selects a finalized bank as the root, the validator updates its highest confirmed slot, root, and highest supermajority root at the same time.

For developers, this means confirmed and finalized effectively point to the same consensus state after Alpenswitch. Existing applications do not need to change their commitment setting on activation day, as the RPC interface still accepts processed, confirmed, and finalized, but the latency difference between the latter two disappears.

The distinction between Votor's two finalization paths is invisible to ordinary RPC consumers. Whether a block reaches the 80% fast-finalization threshold in one round or finalizes through the 60%-threshold two-round path, the externally visible result is the same.

Multiple Candidate Blocks

Another important change in Alpenglow targets RPC providers, indexers, and other infrastructure that consumes validator data. A slot can no longer be treated as a unique block identifier.

A Solana slot is a window in which a leader can produce a block. A bank, meanwhile, is the validator's local representation of the state produced by executing a particular candidate block. These concepts have always been distinct, and competing banks are not new, but much production infrastructure has always treated slots and blocks as synonymous.

Alpenglow makes that assumption increasingly unsafe.

Agave 4.3 extends Geyser (the validator interface used to stream account, transaction, entry, and block updates) with a new identifier: bank_id. The new bank-aware callbacks, including update_account_for_bank, notify_transaction_for_bank, notify_entry_for_bank, and notify_block_metadata_for_bank, associate an event with the specific bank that produced it. Bank-scoped status notifications similarly carry a bank_id. The older callbacks remain for compatibility in 4.3 but are deprecated and slated for removal in the next major Agave release.

The important point is that bank_id identifies a local bank instance, not a globally agreed block. Agave creates bank IDs from a local atomic counter maintained by the validator runtime, so two validators replaying the same block should not be expected to assign it the same bank_id. Infrastructure should therefore use (slot, bank_id) to separate competing streams coming from a single validator, but use the block ID or blockhash when reconciling data across different validators or connections.

Future stages of Alpenglow make multiple banks for the same slot a normal part of validator operation.

The clearest example is fast leader handover, one of the Alpenglow components being rolled out after the initial Votor activation. A leader can begin building optimistically on the parent it expects consensus to accept. If Votor instead decides that the parent should be skipped, the leader can switch parent and rebuild for the remainder of its leader window. Internally, that means replacing one bank with another for the same slot. Agave already contains the UpdateParent machinery required to represent this switch. Fast leader handover is not part of the initial Agave 4.3 Alpenglow activation and is expected to be rolled out during 4.4.

Leader equivocation can produce the same broad outcome. If a leader signs and distributes two different blocks for the same slot, validators may temporarily need to retain and reason about both candidates. Different parts of the network can see those candidates in different orders because Votor is asynchronous and validators act on blocks, votes, certificates, and local timeouts as they arrive.

A recent change tightened MAX_ALTERNATE_BLOCKS_PER_SLOT from 11 to 6. Therefore, a validator needs to retain at most seven candidate blocks for a slot. Consensus ultimately resolves those candidates to one history. Under Votor, notarization requires more than 60% of stake. Two conflicting blocks cannot both obtain valid notarization certificates without substantial stake voting for both. Under Alpenglow's assumption that less than 20% of stake behaves Byzantine, conflicting notarization certificates are impossible without violating the protocol's safety assumptions.

For Geyser consumers, the practical lesson is straightforward: stop keying transient state by slot alone. Account changes, transactions, entries, and block metadata should be tracked per (slot, bank_id) until consensus identifies the surviving bank. If another bank appears for the same slot, its events belong to a separate candidate state and should not silently overwrite those from the first.

Validator Admission Tickets

Vote transactions are currently the highest cost in running a Solana validator. Under TowerBFT, validators pay a standard transaction fee every time they submit a vote, adding up to roughly 2 SOL per epoch. Alpenglow replaces transaction fees with a fee charged once per epoch to validators admitted to the active consensus set, known as the Validator Admission Ticket (VAT).

The groundwork for this transition is already live. BLS public-key registration, specified in SIMD-0387, activated on mainnet in July, shortly followed by the VAT feature gate, SIMD-0357. Votor uses BLS signatures, so that signatures from many validators can be aggregated into a single compact certificate. Each validator must register a BLS public key in its vote account before it can participate in Alpenglow. Since the VAT gate was activated, validators without one are already excluded from the voting set.

Before Alpenglow, validators continue submitting ordinary vote transactions and paying their associated fees. At this stage, VAT acts primarily as an admission filter. Eligible validators must have a BLS key and fall within the top 2,000 qualifying validators by stake. VAT begins once Alpenglow is enabled, and vote transactions disappear.

Once Alpenglow is active, admission is recalculated around epoch boundaries. A validator's vote account must contain a registered BLS key and enough SOL to cover the ticket plus rent exemption. If more than 2,000 accounts qualify, the system ranks them by stake and admits the highest-staked validators. The system then deducts the ticket directly from each admitted validator's vote account and sends it to Solana's incinerator account. Validators therefore need to keep their vote account funded; under the old system, vote transaction fees were deducted from the validator's identity account.

The original Alpenglow and VAT proposals specified a 1.6 SOL ticket per epoch, around 80% of the roughly 2 SOL a validator previously spent on vote transactions. That figure assumed Solana's historical 400-millisecond slot target. SIMD-0525 instead scales VAT alongside slot duration. Admission costs at 200-millisecond slot times will be 0.8 SOL.

VAT also changes where this cost goes. Today, the 5,000-lamport base fee paid by a vote transaction is split in two: 50% is burned, and 50% goes to the block leader. VAT, by contrast, is sent entirely to the incinerator. The broader purpose of VAT, however, is not to make SOL materially more deflationary. It is to preserve an economic cost to joining the consensus set after vote transaction fees disappear.

Safety and Preparedness

Replacing a live network's consensus protocol is an unusually high-risk operation. Alpenglow therefore has a much broader testing and migration process than a typical Agave feature activation, including a dedicated community test cluster and bug bounty.

Since May, validator operators have been running a dedicated Alpenglow Community Cluster, which has grown to more than 100 nodes. Operators run real validator hardware and networking setups, allowing Alpenglow to be tested under geographic dispersion, latency variation, software configurations, restarts, and operational mistakes that are difficult to reproduce in controlled environments.

One of its most important purposes has been testing Alpenswitch itself. Rather than only checking whether Votor works once a cluster is already running Alpenglow, operators have repeatedly exercised the transition from TowerBFT into the new consensus system.

Roger Wattenhofer

@TheWattenhofer

We just had the first successful Alpenswitch on our Alpenglow community cluster! The @solana finalization time improved 100x. Thanks to everybody participating. Watch it live: https://ag.validblocks.com/ https://ag-community-status.stakingfacilities.com/

May 9, 2026, 6:59 PM

Alpenglow has also undergone a dedicated adversarial review. In August, Anza opened a two-week Alpenglow Bug Bounty Competition with a prize pool of up to 50,000 SOL. Unlike the standing Agave bounty, the competition was scoped specifically to the new consensus stack, including Votor, BLS signature and certificate verification, validator admission, and the TowerBFT-to-Alpenglow migration path. Participation was substantial. Anza reported more than 300 submissions and said that over 25,000 SOL would be distributed in bounties.

Frankendancer support is ending with Alpenglow's arrival. Frankendancer was always intended as a transitional client, combining Firedancer's networking and block-production components with Agave components for execution and consensus. Supporting the new consensus system in that hybrid architecture would add another substantial maintenance and security burden, so the Firedancer team is focusing development on the full Firedancer client instead.

Guidance shared with validators is that neither Frankendancer nor full Firedancer will support the short TowerBFT-to-Alpenglow migration window itself. Firedancer operators should therefore arrange to fail over to an Agave validator before Alpenswitch, remain on Agave through the handoff, and then move back to Firedancer once the cluster is operating normally under Alpenglow.

How Alpenswitch Actually Happens

Alpenglow does not turn on everywhere at an arbitrary wall-clock time. Once its feature is activated, the protocol defines a migration boundary 5,000 slots later. TowerBFT continues operating while validators move beyond this boundary and search for a sufficiently strongly confirmed block. Validators then BLS-sign the selected Alpenglow genesis block and distribute those genesis votes directly to one another.

The handoff occurs once at least 82% of stake has signed the same genesis block, producing the Alpenglow genesis certificate. Validators that receive and verify that certificate disable TowerBFT beyond the genesis block and initialize Votor from the agreed state. The certificate then propagates through the validator set, bringing remaining nodes across the boundary.

This certificate gives infrastructure operators a convenient way to determine which side of Alpenswitch a cluster is on.

Agave 4.3 introduces a new RPC method getAgGenesisCert. Before migration, an Agave 4.3 node returns null. After the cluster switches, it returns the Alpenglow genesis certificate, including the genesis block and aggregate BLS signature. An older node that does not support the method instead returns Method not found. The CLI exposes the same information through: solana alpenglow-genesis-info.

For validators, RPC providers, and other infrastructure that needs to react to the migration, checking for the genesis certificate is therefore preferable to assuming Alpenglow became active at a particular timestamp.

New Cryptographic Syscalls

Agave 4.3 also expands the SVM's cryptographic toolbox with new runtime primitives for operations that are prohibitively expensive to perform directly in sBPF.

The two notable additions are SHA-512 hashing and big-integer modular exponentiation. Both are additive and feature-gated: existing programs are unaffected, while programs that opt into them can delegate computationally expensive cryptography to optimized native implementations inside the validator runtime.

Big Integer Modular Exponentiation

SIMD-0529: Big Integer ModExp Syscall introduces sol_big_mod_exp, a syscall for calculating:

result = (base ^ exponent) mod modulus

Modular exponentiation is a fundamental operation behind RSA signature verification, cryptographic accumulators, some verifiable delay functions, and other number-theoretic protocols. Implementing it with arbitrary-precision integer arithmetic directly inside an SVM program is extremely compute-intensive, particularly at common RSA key sizes such as 2048, 3072, and 4096 bits.

The new syscall moves the expensive arithmetic into the validator runtime. Programs supply the base, exponent, and modulus as little-endian unsigned integers and receive the result in caller-provided memory. Each operand is initially capped at 512 bytes, enough to support integers up to 4096 bits.

The most obvious use case is RSA verification. For example, a program verifying a conventional RSA signature can invoke sol_big_mod_exp using the common public exponent 65537, rather than implementing large-integer exponentiation itself. The syscall deliberately stops at the arithmetic primitive: programs remain responsible for hashing, RSA padding such as PKCS#1 v1.5 or PSS, key validation, and any protocol-specific domain separation.

It can also perform efficient big-integer modular reduction. Passing an exponent of 1 reduces the operation to:

base mod modulus

This gives programs a native primitive for reducing integers larger than the SVM's built-in machine word sizes without paying for a general-purpose big-integer implementation.

The design is similar in spirit to Ethereum's ModExp precompile introduced by EIP-198, and its compute-metering model follows EIP-198's operation-complexity formula. It is not, however, byte-for-byte compatible with Ethereum. Solana exposes the functionality through a native syscall ABI, uses little-endian inputs, and requires the modulus to be an odd integer greater than one; even moduli are rejected.

That makes the syscall particularly useful for interoperability without forcing Solana to adopt the EVM precompile interface itself. Programs verifying proofs, signatures, or attestations built around Ethereum-style cryptographic assumptions can reuse the same underlying arithmetic while adapting how they invoke it.

SHA-512

The second addition is considerably simpler but immediately useful.

SIMD-0512: Sha512 Syscall adds sol_sha512, giving onchain programs direct access to the SHA-512 hash function through the validator runtime. Its interface mirrors Solana's existing sol_sha256, sol_keccak256, and sol_blake3 syscalls and returns the standard 64-byte SHA-512 digest.

SHA-512 is notably one of the core primitives used by Ed25519, the signature scheme Solana itself uses extensively. Both Agave and Firedancer already depend on SHA-512 internally, but until this change, SVM programs could not directly access that optimized implementation. A program that needed SHA-512 instead had to implement the algorithm in software.

That difference is substantial from a compute perspective. The SIMD estimates that hashing a short input using an sBPF implementation costs thousands of CUs, whereas performing the same operation through the syscall costs fewer than 100 CUs. sol_sha512 uses the same general compute-cost model as Solana's existing SHA-256 syscall.

Taken together, the two syscalls continue a broader trend in the SVM: moving common but computationally expensive cryptographic primitives out of individual programs and into standardized, metered runtime operations. Programs still define the higher-level cryptographic protocol, but the validator can execute the expensive building blocks far more efficiently than an sBPF implementation.

Conclusion

Agave 4.3's headline change is Alpenglow, which replaces TowerBFT with Votor, removes vote transactions from blocks, compresses finality from seconds to milliseconds, and reshapes how validators and infrastructure interact with consensus.

For most users and application developers, much of this transition will happen invisibly. For validators, RPC providers, indexers, and infrastructure teams, however, Agave 4.3 marks the beginning of a major shift in how Solana reaches consensus.

Further Resources

• Alpenglow Whitepaper v1.2 (July, 2026)
• Agave 4.3 Release Schedule
• Feature Gate Tracker Schedule
• Agave 4.3 Change Log
• Agave 4.3 Pull Requests
• Alpenglow Upgrade - Solana Foundation