Agave 4.1 Update: All You Need to Know

Introduction

With Agave 4.1, Solana’s core validator client continues its steady evolution, delivering performance improvements today while laying the groundwork for larger blocks, 200ms slot times, and the eventual rollout of Alpenglow.

Notable 4.1 Release Cycle Updates

• Faster release cadence, with major releases now every six weeks
• Continued Alpenglow readiness work, including BLS public key management*, Validator Admission Tickets*, and the community test cluster
• XDP adoption surpassing a critical network threshold
• Additional Pinocchio rewrites, including p-memo and p-ATA
• Reduced validator RAM usage
• Preparation for 200ms slot times**

* Feature-gated upgrades

** Expected in Agave 4.2

Alongside the core client work, Anza and the broader ecosystem are also pushing forward on several major initiatives in parallel:

• Constellation: Constellation proposes the first formal, protocol-level implementation of Multiple Concurrent Proposers (MCP) on a production blockchain at scale. Instead of giving a single leader broad discretion over transaction inclusion, Constellation introduces proposers and attesters that constrain what the leader can exclude from a valid block.
• Quantum hardening: Anza’s research team has begun exploring how Solana can be secured against future quantum adversaries, including research around post-quantum signatures, account migration, consensus signatures, block propagation, and onchain signature verification.
• Economic upgrades: A new wave of tokenomics proposals is also in the pipeline. SIMD-550 proposes doubling Solana’s disinflation rate from -15% to -30%, while SIMD-553: Resource and Inclusion Fee proposes splitting today’s signature fee into a base inclusion fee paid to the leader and a burned resource fee based on requested cost units.
• New governance tooling: The next round of economic proposals is also being shaped by improved governance infrastructure. New tooling allows not just validators, but also stakers, to participate directly in Solana governance, broadening who can weigh in on core protocol changes.

There’s so much going on right now.

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.1.0-rc.1 is now recommended for general use on mainnet. Validators, it’s time to upgrade!

Alpenglow Readiness

Much of the groundwork for the Alpenglow consensus upgrade is landing during the Agave 4.1 release cycle. These changes prepare the network for the transition from Tower BFT to Alpenglow, including BLS key management in the vote program, Validator Admission Tickets, and Fast Leader Handover markers.

Community Test Cluster

The remaining path to mainnet activation for Alpenglow now relies heavily on extensive real-world testing. Since May, a community test cluster of roughly 100 geographically distributed validators has been running the upgrade in a live network setting, testing the transition between Solana’s current Tower BFT-based consensus and Alpenglow ahead of mainnet activation.

The goal is to make the launch process as uneventful as possible. Validators on the cluster have been switching between Tower BFT and Alpenglow, exercising the migration path under real operator conditions rather than relying only on controlled internal testing. Discussions are taking place in the `ag-community-cluster` channel in the Solana Tech Discord, and live cluster activity can be followed through community dashboards from Valid Blocks, Staking Facilities, and Noders.

BLS Pubkey Management

SIMD-0387: BLS Pubkey Management in Vote Account will activate during the Agave 4.1 release cycle. This adds the vote program plumbing needed for validators to register BLS public keys in their vote accounts ahead of Alpenglow. Alpenglow uses BLS aggregate signatures to make votes cheaper to aggregate and verify, but BLS public keys are distinct from the Ed25519 vote authority keys used today. 

Validators can add BLS public keys to their vote accounts while continuing to operate with their existing Ed25519 vote authority keys. Once Alpenglow is active, vote accounts without a registered BLS public key will not be able to participate in the new voting process.

Alpenglow Validator Admission Tickets (VAT)

The Agave 4.1 release cycle will also include the mainnet activation of SIMD-0357, which implements Validator Admission Tickets (VAT). VATs are designed to preserve a similar validator cost structure as Solana moves away from the current vote transaction model under Tower BFT.

Today, validators pay vote transaction fees continuously as they vote, adding up to ~2.1 SOL per epoch for validators that vote consistently. Under Alpenglow, those vote transactions are replaced by a new consensus design, so SIMD-0357 introduces a once-per-epoch admission cost instead. Each validator eligible to participate in Alpenglow voting pays a 1.6 SOL VAT per epoch, maintaining a comparable economic barrier while reducing the risk of an immediate, uncontrolled expansion of the validator set after Alpenglow launches.

Implementation is handled at the epoch boundary. When crossing into a new epoch, the runtime calculates the validator set for the next epoch, filters for vote accounts that have both a registered BLS public key and enough lamports to cover the VAT plus rent, and then deducts the VAT from accepted validators’ vote accounts. Those lamports are sent directly to the incinerator account. If more than 2,000 validators qualify, the voting set is capped by stake weight, with the top eligible validators selected.

Operationally, this changes where validator operators need to keep funds. Vote transaction fees are currently paid from the validator identity account, which must be a hot keypair for normal validator operations. With VATs, the admission cost is deducted from the vote account instead.

Fast Leader Handover Markers

Finally, the activation of SIMD-0337: Markers for Alpenglow Fast Leader Handover will add new block markers that allow an Alpenglow leader to declare a block’s parent at the beginning of the block and, when necessary, update that parent while streaming the block. These markers support Fast Leader Handover, which is designed to reduce synchronization delays between leaders.

Greater XDP Adoption and the Path to 100 Million CUs

XDP (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. Adoption of XDP is essential for the network to reach the long-standing goal of 100 million CU blocks. 

Adoption has now crossed an important threshold. Earlier this month, the network saw the “flippening,” with more leaders running XDP than not. Currently, more than two-thirds of the network has activated XDP. Agave 4.1 reflects that maturity by removing the experimental label from XDP support and replacing the old `--experimental-retransmit-xdp-*` flags with `--xdp-interface`, `--xdp-cpu-cores`, and `--xdp-zero-copy`. In Agave 4.2, XDP is scheduled to be enabled by default.

For validator operators who still have not made the switch, the Solana Foundation upgrade page and Anza’s setup guide provide a practical compatibility checklist covering kernel support, network hardware, validator capabilities, startup flags, and verification steps. Below is a useful driver and NIC compatibility guide.

More Pinocchio Program Rewrites

The successful launch of p-token proved recently that targeted rewrites of Solana’s most-used programs can unlock meaningful network-wide compute savings. As a drop-in replacement for the SPL Token program, p-token reduces compute unit (CU) consumption by roughly 95%, translating to a ~19x efficiency improvement for standard token transactions. Token program instructions previously accounted for around 10% of block-wide CU usage. By reducing those instructions to roughly 5% of their former cost, p-token freed up close to 9.5% of total block capacity.

The “p” in p-token stands for Pinocchio, an optimized, performant, zero-dependency library for writing Solana programs developed by Anza. Pinocchio serves as a replacement for the standard solana-program crate, which makes extensive use of zero-copy types for handling instruction and account data.

Anza is now rewriting other core programs with Pinocchio. The goal is not to introduce new standards or force application-level migrations, but to make existing, widely used programs dramatically cheaper to execute.

P-memo Program

The first example is p-memo, a Pinocchio reimplementation of the SPL Memo program, which is already live on mainnet. The Memo program is small, but the efficiency gains are still striking. With no signers, p-memo consumes 287 CUs compared to 2,022 CUs for the current Memo program, or about 14% of the existing cost. Once signers are present, the difference becomes even more pronounced: with one signer, p-memo uses 513 CUs compared to 13,525 CUs; with two signers, 628 CUs compared to 25,111 CUs; and with three signers, 743 CUs compared to 36,406 CUs. This means that in signer-heavy cases, p-memo reduces compute consumption to only 2–4% of the current program’s cost.

P-ATA Program

Work is also underway on p-ATA, a Pinocchio reimplementation of the Associated Token Account program. The ATA program defines the standard mapping between a wallet, a token mint, and the token account used to hold that mint. It provides a deterministic way to derive a user’s associated token account and lets anyone create that account for a recipient if it does not already exist. 

The ATA program is the fifth most invoked program on the network. According to Anza team’s estimates, it appears in ~11.9% of all transactions and accounts for ~13.3% of total CU consumption. The rewrite could reduce weighted average CU usage by 80.9%, with further savings expected from new instructions added alongside p-ATA. At current network usage, that would translate into roughly 10% global mainnet CU savings. In Anza’s sampling, p-ATA freed more than 2.78 million CUs per block.

P-token, p-memo, and p-ATA are unlikely to be the end of this work. The Token-2022 program is another highly requested program. More broadly, Anza’s effort to make core programs `no_std` lays the groundwork for rewriting more of Solana’s foundational programs with fewer dependencies and lower compute costs.

Reducing Program Entrypoint Overhead

A related change scheduled for activation during Agave 4.1’s release cycle is SIMD-0449: Direct Account Pointers in Program Input, which optimizes the program entrypoint. Today, ABIv1 sBPF programs must parse the serialized accounts section of the program input to find account boundaries and construct the account slice passed into the program. SIMD-0449 changes this by having the VM append a slice of direct account pointers to the program input, using boundary information that the VM already knows when preparing the invocation.

This is especially relevant for Pinocchio-style programs because account parsing represents a large share of entrypoint cost. With direct account pointers, the entrypoint can access accounts without iterating through the full accounts section, making entrypoint compute effectively constant regardless of account count. 

In the updated benchmarks, a 64-account Pinocchio entrypoint drops from 504 CUs to an estimated 7 CUs, while smaller account sets also converge to the same low 7 CU cost.

Reduced 200ms Slot Times

One of the most anticipated performance improvements is reducing Solana’s target slot time from 400ms to 200ms. This is unlikely to be rolled out during Agave 4.1’s release cycle and will more likely make its way to mainnet with Agave 4.2. However, there is growing momentum to bring this important upgrade to mainnet as soon as possible.

SIMD-0525: Reduce Slot Times proposes a staged rollout, moving from 400ms slots to 350ms, then 300ms, then 250ms, before finally reaching 200ms. Each step is feature-gated, giving client teams and operators a chance to observe the network under shorter slot times before moving to the next stage. Anza has been testing 200ms slots internally for months, and the team believes the network is ready for aggressive slot-time reductions. Improvements to the replay stage have made the change more practical: replaying a full 400ms slot now takes around 40ms.

The motivation is straightforward. Shorter slots reduce confirmation and finalization latency for users. They also shorten each leader window. Today, Solana’s leader span is four consecutive slots, which gives a leader a 1.6-second window at 400ms slots. At 200ms slots, that window falls to 800ms. This improves market structure by reducing the worst-case time a malicious leader can delay, reorder, or selectively include transactions before the next leader has an opportunity to produce a block.

Shorter slots also give applications a finer-grained view of time onchain. That matters for systems that reason about slot freshness, including oracle consumers and proprietary AMM-style market makers.

The proposal is carefully designed to avoid changing Solana’s economics. `slots_per_year` is increased by the inverse ratio, preserving the SOL inflation schedule. Under Alpenglow, Validator Admission Ticket (VAT) costs also scale with the slot-time stage, keeping the admission cost near the intended ~0.8 SOL per day. Additionally, per-slot work limits are reduced in proportion to the shorter target slot time, so the amount of work the network can process per second remains approximately unchanged. 

Several core assumptions remain unchanged. Leader spans are still four slots, epochs remain fixed at 432,000 slots, and ticks per slot remain at 64. Because epochs remain fixed in slot count, 200ms slots reduce the length of an epoch from roughly two days to one day.

One point of contention is the impact on validator voting costs if shorter slot times are activated before Alpenglow. Faster slots mean more votes per day, and therefore higher daily vote costs for validators. Vote transaction costs are the highest single cost for validator operators. Voting transactions are priced uniformly at 0.000005 SOL, and daily, these transaction costs amount to ~1.086 SOL. With 200ms slots, those costs would roughly double.

Other Notable Updates

Several smaller but notable improvements are set for activation during the Agave 4.1 release cycle, ranging from more precise validator commission rates to new cryptographic primitives and the removal of a denial-of-service attack vector in the upgradeable loader.

Validator Commission Rates Increase Precision

As part of the Agave 4.1 release cycle, the feature-gated SIMD-0291: Commission Rate in Basis Points upgrade will activate on mainnet. Today, validator commission rates can only be set in whole percentage points. That means a validator can set commission to 5% or 6%, but not 5.5%, 5.25%, or 5.01%.

With this update, validators gain more fine-grained control by setting commission rates in basis points, where 100 basis points equals 1%. The vote program adds a new `UpdateCommissionBps` instruction, allowing the authorized withdrawer on a vote account to update the validator’s inflation rewards commission with this higher precision. For validators, this makes commission settings more flexible and competitive.

This change is one of several updates tied to the new Vote Account V4. It also helps prepare the network for the anticipated activation of SIMD-0123: Block Revenue Distribution, which will enable block rewards to be distributed in-protocol.

SHA-512 Syscall

SIMD-0512: Sha512 Syscall introduces a new syscall that gives onchain programs direct access to SHA-512 hashing through the runtime, using an interface that mirrors existing hash syscalls such as `sol_sha256`, `sol_keccak256`, and `sol_blake3`.

SHA-512 is a core primitive used in Ed25519 signature verification, and it already exists as an internal dependency in both the Agave and Firedancer validator clients. Until now, however, it has not been exposed to onchain programs. Directly hashing a short message onchain is expensive and will consume thousands of CUs, compared with fewer than 100 CUs through a syscall.

With `sol_sha512`, programs can compute SHA-512 hashes at syscall cost and receive the standard 64-byte digest directly. The change is additive and feature-gated, so programs that do not use the new syscall are unaffected, and existing hash syscalls remain unchanged.

Hardening the Upgradeable Loader

The Agave 4.1 release cycle will also see the feature-gated release of SIMD-0431: Loader V3: Minimum Extend Program Size, which adds a minimum extension size to Loader V3’s `ExtendProgram` instruction. Once this is activated, programs must be extended by at least 10,240 bytes (10 KiB), unless the program data account is already within 10 KiB of the 10 MiB maximum account size.

This change addresses a subtle denial-of-service vector in the current upgradeable loader. `ExtendProgram` is permissionless, meaning anyone can extend an upgradeable program’s data account, even by as little as one byte. Because each extension invalidates the program’s cache entry for the current slot, a cheap one-byte extension can temporarily disrupt access to the program.

Rather than making `ExtendProgram` permissioned, the change preserves the instruction’s permissionless design while making abuse economically unattractive. At the new 10 KiB minimum, each extension costs roughly 0.072 SOL in rent-exempt lamports.

For legitimate program upgrades, the impact should be limited. Programs that need less than 10 KiB of additional space will need to extend by the full minimum, but the extra capacity remains available for future upgrades. The SIMD also leaves the instructions’ accounts, signer requirements, CPI restrictions, and existing multisig workflows unchanged.

Conclusion

Agave 4.1 is a substantial client upgrade that brings together a wide range of performance improvements and optimizations. Looking ahead, Agave 4.2 is shaping up to be even more consequential, with larger 4096-byte transaction sizes, reduced 200ms slot times, and, possibly, the long-awaited Alpenglow consensus upgrade.

Further Resources

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