Agave 4.0 Update: All You Need to Know

Many thanks to 0xIchigo and Brian Wong for reviewing earlier versions of this work.

Introduction

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.

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

Whether you’re a validator operator or developer, this guide gives you the updates and insights needed to make the most of the latest improvements. Each section of this article is self-contained, allowing readers to focus on the topics most relevant to them. 

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!

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.

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.

In the absence of native G2 support, some projects have relied on custom implementations such as solana-alt-bn128-bls, an end-to-end BLS signature library built by Blueshift’s Dean Little on top of existing syscalls. Enabling G2 operations at the syscall level would remove the need for these workarounds, making it easier to build production-grade cryptographic protocols natively on Solana.

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.

Rather than introducing an entirely new syscall interface, this upgrade extends the existing curve syscalls with new identifiers for BLS12-381 G1 and G2 operations. This allows developers to perform group arithmetic, point validation, decompression, and batch pairing checks using a familiar interface, while significantly expanding cryptographic capabilities.

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. This brings us to our next section.

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. Because slot numbers alone do not uniquely identify blocks, especially in cases of equivocation where multiple blocks may be produced for the same slot, clients cannot rely on slot ordering to determine the correct parent-child relationship.

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. Under TowerBFT, this is enforced by requiring FEC sets to reference their parent’s Merkle root both within and across slots. Alpenglow uses a double Merkle root construction over all FEC sets in a slot. If these checks fail, the block, or slot, is marked as dead. Enforcing these rules strengthens consensus safety and ensures validators can recover from receiving incorrect or conflicting blocks.

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. The change introduces stricter placement requirements for DATA_COMPLETE_SHRED and a new “parent ready” marker, ensuring that a block’s completeness can be unambiguously detected from the shred stream itself.

Today, ambiguity around whether a slot is fully transmitted can delay the next leader, since they may need to wait for additional shreds or risk building on incomplete data. By standardizing how completion is signaled, this change allows the next leader to confidently begin producing blocks earlier, without additional coordination or guesswork.

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. 

Today, simple vote transactions are charged a constant 3,428 CUs, based on legacy assumptions about deterministic execution cost. Under the new model, vote transactions will be metered dynamically like any other transaction, making cost accounting more consistent and eliminating the need for a separate Vote CU limit.

While the actual runtime CU consumption for vote transactions remains the same, how they are accounted for during block packing does shift. In particular, votes will now include additional ~16 thousand estimated CUs, such as account data loading costs, resulting in higher upfront CU reservations when leaders construct blocks.

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: the low-level bytecode format and virtual machine that on-chain programs compile to before execution. This update combines work outlined across three SIMDs: SIMD-0178, SIMD-0189, and SIMD-0377. 

SIMD-0178 introduces static syscalls, allowing syscall references to be resolved at link time rather than via runtime ELF relocations. Today, those relocations add complexity to the program loader; removing them simplifies execution and reduces security risk.

SIMD-0189 then tightens the allowed ELF layout for programs, requiring a stricter file structure so validators have fewer edge cases to parse and less unexpected data to handle. This should be transparent to developers, since the linker toolchain is expected to emit compliant binaries automatically.

Finally, SIMD-0377 updates the SBPF virtual machine to better match the modern eBPF instruction set generated by LLVM, including support for additional instructions such as 32-bit jump operations. The goal is to make Solana’s VM more compatible with upstream tooling while allowing programs to compile into more efficient bytecode. 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. This allows accounts to be prefunded before creation, simplifying a common developer workflow and reducing unnecessary instructions.

Previously, the CreateAccount instruction would fail if the destination account already held lamports. As a result, developers had to split account initialization into multiple steps, typically a transfer, followed by allocate and assign, which increases complexity and adds extra compute cost. This pattern is especially common in programs that fund accounts in advance.

The new instruction consolidates these steps into a single call by allowing prefunded accounts to be initialized directly. 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. Because this is introduced as a new instruction rather than as a modification to existing instructions, it remains fully backward compatible.

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. This is especially useful because snapshot data is typically streamed to disk and does not need to displace hotter validator data from memory. Operators can opt out with --no-accounts-db-snapshots-direct-io if their filesystem does not support O_DIRECT. Direct I/O is expected to be extended to snapshot creation in a future release. 

Conclusion

Agave v4.0 is a substantial client upgrade that delivers a range of performance improvements and runtime optimizations. Changes that are designed to make the network faster, safer, and easier to build on.

Looking ahead, the next milestone is Agave 4.1 and the Apenglow consensus update.

Further Resources

• Agave 4.0 Release Schedule
• Feature Gate Tracker Schedule
• Agave 4.0 Change Log
• Agave 4.0 Pull Requests