Agave 4.0 Unleashes Major Solana Performance Boost & Alpenglow Readiness
This critical Agave 4.0 validator client update dramatically enhances Solana's network performance, scalability, and cryptographic capabilities while laying essential groundwork for the future Alpenglow consensus upgrade.
With Agave 4.0, Solana’s core validator client takes yet another step forward, improving core performance paths while preparing the network for larger blocks and the much-anticipated Alpenglow consensus update. At the time of writing, Agave v4.0.0-rc.0 is considered a mainnet upgrade candidate (MUC), with Anza seeking volunteers to help bring the release to 25% of stake. Validators: it’s time to upgrade!
Notable Agave 4.0 Release Cycle Updates
- XDP dramatically accelerates Turbine’s retransmit
- Lower-latency Replay Stage
- Alpenglow readiness: fast leader handover markers and chained block ID validation*
- Expanded cryptographic support: G2 arithmetic and BLS12-381 syscalls*
- Improved serialization with Wincode
- Minimum stake delegation increase with Stake Program v5*
- Re-enabling the ZK ElGamal proof program*
- SBPFv3 program support*
** feature-gated upgrades*
XDP Ready for Wider Adoption
XDP (short for eXpress Data Path) is the high-performance networking path that Agave uses to accelerate Turbine. It lets Agave load an eBPF program close to the network interface card, allowing shred traffic to bypass much of the standard Linux packet-processing path.
This matters because Turbine becomes the main bottleneck as Solana pushes toward higher block limits. Leaders must fan out shreds to hundreds of peers, and large validators can already approach 150,000 outbound packets per second under current conditions. As the network moves toward the long-standing goal of 100 million CU blocks, packet dispatch and retransmit performance need to scale with execution throughput. XDP creates that headroom by making block propagation immensely faster.
With Agave 4.0, XDP is now ready for wider validator adoption. It has been stress-tested under various configurations, hardened further, and undergone additional routing improvements. Production results are immensely encouraging, with Turbine retransmit being orders of magnitude faster.
Image: Transmit Stage Performance Comparison Agave 4.0
For further context on why XDP is such a significant improvement, see our previous interview with Anza engineer Alessandro Decina.
Faster Replay Stage
Agave 4.0 speeds up replay by moving two expensive verification steps off the replay threads’ critical path. In v4.0, entry verification and transaction signature verification are both dispatched asynchronously, allowing replay to keep processing while background jobs confirm that the slot is valid.
The first change moves PoH entry verification into the background. Previously, replay verified the entry hash chain inline before continuing. A second change applies the same idea to transaction signatures, but with an important split: Agave now separates transaction hash/message verification from Ed25519 signature verification. The hash path still runs up front so transactions can be sanitized and executed safely, while the more expensive signature checks run in the background and are joined before the block is accepted.
The practical impact is a much less blocked replay stage, especially during busy slots where signature checks scale with transaction count.
Further Adoption of Wincode
Wincode is a serialization and deserialization library developed by Anza, built for in-place initialization and direct memory writes to minimize intermediate buffering. It delivers top-tier performance among Rust serializers while remaining fully compatible with the more popular bincode.
In Agave 4.0, more performance-critical serialization paths are transitioning from bincode to wincode. Since nearly all data written to disk or sent over the network in Solana relies on bincode, optimizing these paths has a broad impact.
Minimum Stake Delegation Increase (Stake Program v5)
A significant update to the Stake Program is coming with Agave 4.0. This feature-gated change, outlined in SIMD-0490, is preparation for Solana’s broader drive to reduce stake bonds (AKA rent).
The most notable change is that the minimum stake delegation rises from 1 lamport to 1 SOL. This prevents the cost of creating and maintaining stake accounts from becoming too low as rent requirements decrease, which could introduce a potential attack vector. While many smaller stake accounts exist below this threshold, they account for only 0.02% of total active stake and will be grandfathered in once the update goes live.
The upgrade also cleans up several parts of stake account handling. It switches rent calculations to use the Rent sysvar instead of relying on each account’s stored rent_exempt_reserve, makes sysvar account inputs optional for stake program operations, and rewrites the Split implementation to fix longstanding edge cases.
The validator operator community has expressed comfort with the new 1 SOL minimum. Tooling and dapps that interact with the stake program will need to check their logic to account for the new minimum.
Improved Cryptographic Support
Several feature activations throughout the Agave 4.0 release cycle aim to expand Solana’s native cryptographic capabilities, enabling better support for modern use cases, including ZK proofs and BLS signatures.
Re-enabling the ZK ElGamal Proof Program
The ZK ElGamal Proof program is a native Solana program that verifies zero-knowledge proofs used in Token-2022 confidential transfers, enabling validation of encrypted balances and transactions without revealing the underlying data. It serves as a generalized verifier for ElGamal-based cryptographic proofs, forming a key component of Solana’s privacy-preserving token functionality.
The program was disabled on mainnet following a June 2025 security incident, in which a flaw in the proof verification logic, specifically a missing element in the Fiat-Shamir transcript hashing, made it possible to construct forged proofs that could pass verification. While no exploit was observed in the wild, the potential impact led to the program being feature-gated off and confidential transfers paused while fixes and audits were completed. With the issues addressed and the implementation hardened, the program is now scheduled for reactivation on mainnet.
G2 Arithmetic for alt_bn128
SIMD-0302: Add alt_bn128 G2 Syscalls extends Solana’s existing BN254 (alt_bn128) cryptographic syscalls to support native operations over G2 curve points, including addition, subtraction, and scalar multiplication. G1 and G2 are the two elliptic curve groups used in pairing-based cryptography, with G2 defined over a larger extension field.
This fills a key gap in the current syscall set, which primarily focuses on G1 operations, and unlocks more complete support for pairing-based cryptography directly on-chain, particularly for use cases such as BLS signature verification and advanced ZK proof systems.
Little-Endian Support for alt_bn128
SIMD-0284: Add Little-Endian Compatibility for alt_bn128 extends Solana’s existing alt_bn128 cryptographic syscalls to support little-endian input and output formats. Previously, these syscalls only accepted big-endian encoding, creating friction for developers using tooling and libraries, particularly those from the Ethereum ecosystem, since most ZK teams on Solana use ark-bn254, which operates in little-endian. The change is backward-compatible and broadens support for existing use cases involving elliptic curve operations on alt_bn128.
BLS12-381 Syscalls
Lastly, SIMD-0388: BLS12-381 Syscalls introduces native support for cryptographic operations on the BLS12-381 elliptic curve, bringing a modern, 128-bit security pairing-friendly curve to Solana programs. Until now, Solana has relied on BN254 (alt_bn128) for pairing-based cryptography, which falls short of this security standard and limits compatibility with other widely adopted ecosystems such as Ethereum.
Beyond general improvements for zero-knowledge proofs and BLS signature verification, this work is also a key enabler for Alpenglow consensus. In particular, it allows validators to verify BLS Proofs of Possession on-chain, which prevents rogue-key attacks.
Alpenglow Readiness
BLS12-381 syscalls are just one of several feature-gate activations over the Agave 4.0 release cycle that lay the foundation for the Alpenglow consensus upgrade. Below are additional activations that contribute to the rollout, which is currently scheduled to land on mainnet in Q3 2026 alongside Agave 4.1.
Chained Block ID Validation
SIMD-0340: Validate Chained Block ID defines how validators must verify block ancestry to ensure a consistent, canonical chain under both TowerBFT and Alpenglow consensus. This change introduces explicit chain validation rules to ensure that each block correctly references its parent, preventing divergence and helping the network converge on a single history.
Fast Leader Handover Markers
SIMD-0337: Markers for Alpenglow Fast Leader Handover defines explicit signaling rules that let validators determine when a parent slot is fully complete and safe to build on, which is a prerequisite for fast leader transitions. This is a key building block of Alpenglow’s fast leader handover design, in which minimizing the gap between leaders directly improves network throughput.
Vote Transaction Cost Model Update
SIMD-0458: Stop Using Static SimpleVote Transaction Cost removes the use of a fixed CU cost for vote transactions, bringing them in line with the standard transaction cost model used for non-vote transactions. While the actual runtime CU consumption for vote transactions remains the same, how they are accounted for during block packing does shift. This change follows SIMD-0387 (BLS Pubkey management in vote account), which eliminated the assumption that the Vote program has a static execution profile.
Other Notable Upgrades
Additional highlights from the Agave 4.0 release cycle include support for the SBPFv3 program, the ability to create prefunded accounts, and direct I/O for unpacking snapshots.
SBPFv3 Program Support
The Agave 4.0 release cycle includes a feature gate that enables the deployment and execution of SBPFv3 programs. Solana Berkeley Packet Filter (SBPF) is Solana’s Rust-based fork of eBPF. This update combines work outlined across three SIMDs: SIMD-0178, SIMD-0189, and SIMD-0377. For developers, the practical outcome is faster program loading, a smaller attack surface, and the potential for lower compute usage without changing application logic.
Prefunded Account Creation
SIMD-0312: CreateAccountAllowPrefund is set to activate on mainnet during the Agave 4.0 release cycle. This introduces a new instruction in the system program that removes the requirement that newly created accounts start with a zero lamport balance. In practice, this reduces CPI overhead and can save thousands of compute units in common flows, offering a cleaner, more performant path for developers going forward.
Direct I/O for Unpacking Snapshots
Agave 4.0 changes snapshot unpacking to use direct I/O by default, instead of routing snapshot writes through the operating system page cache, improving startup time and snapshot restore performance.
Conclusion
Agave v4.0 is a substantial client upgrade that delivers a range of performance improvements and runtime optimizations, designed to make the network faster, safer, and easier to build on. Looking ahead, the next milestone is Agave 4.1 and the Alpenglow consensus update.