Agave 3.1 Update: All You Need to Know

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

Introduction

Agave v3.1, the latest evolution of the Solana Agave client, is here! This update introduces a broad set of upgrades that improve client performance, validator operations, and the developer experience. The update also includes several important feature gate activations that lay the groundwork for in-protocol block reward distribution, meaningful state bond (i.e., rent) reductions, and, most notably, the upcoming Alpenglow consensus upgrade.

Notable Agave 3.1 Updates

• Reduced Disk I/O During Replay
• Faster Client Restarts
• 2x Faster Transaction Processing
• Increased CPI Account Infos Limits*
• Validator Vote Account V4 and Delayed Commission Updates*
• Reduced Turbine ChaCha Rounds*
• New Instruction Data Pointer*
• RPC Improvements

* feature-gated upgrade

Whether you’re a validator operator or developer, this guide offers 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 3.1.8 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!

Client Performance Gains

This major Agave release includes a range of performance gains. Below, we highlight several of the most important improvements.

Reduced Disk I/O During Replay 

Agave 3.1 brings a major reduction in disk activity during replay. The image below shows a 10-second profiling window from replay with Agave 3.0 processing real mainnet transactions. Disk operations (shown as red markers) exceed 1,100 events. This is an issue because each disk hit introduces I/O wait time, adding jitter to both banking and replay. 

With Agave 3.1, disk I/O during replay is dramatically reduced. The same 10-second window shows fewer than 80 disk operations, representing a 93% drop. This improves replay stability while reducing disk wear, helping extend disk lifespan.

Faster Client Restarts

Client restart performance continues to improve dramatically, primarily driven by optimizations to AccountsDB. With Agave 1.* major releases, restarts commonly took more than 30 minutes. Agave 2.* releases reduced this to under 10 minutes. Under Agave 3.1, restart times drop even further, now typically taking less than 1 minute. Looking ahead, the next major release, Agave 4.0, is expected to push restart times below 30 seconds, further improving validator uptime and reducing recovery time after maintenance or unexpected failures.

Faster Transaction Processing

Agave 3.1 includes key fixes that significantly improve transaction processing efficiency. Previously, bugs in the transaction processing pipeline caused banking workers to spend excessive time synchronizing with Proof of History rather than executing transactions, so in leader mode, the client was not actively scheduling transactions for roughly 61% of the time.

With these issues resolved in Agave 3.1, banking worker threads now spend ~91% of their time processing transactions. As a result, transaction processing is twice as fast, materially improving throughput and better utilization of leader time.

Other performance enhancements worthly of mentioning include keeping the accounts index entirely in memory by default. Epoch boundary transitions have also been significantly improved, now completing in under 400ms, down from over two seconds, resulting in far fewer skipped slots during epoch rollovers.

Network Hardening

Anza invests heavily in resilience through continuous stress testing, red teaming, and real-time situation monitoring for the Agave client. While the details of this work have previously been kept confidential, the program has matured sufficiently that this important work can now be publicly acknowledged. A dedicated invalidator team at Anza actively attacks Solana’s public testnet with a new set of tests every hour. 

Tests fall into two primary categories. The first focuses on network-layer denial-of-service scenarios, stress-testing backpressure handling, and load shedding under extreme conditions. The second form of tests involves producing curated blocks containing unusual and adversarial transactions designed to push the limits of the Solana VM.

Anza systematically builds attack scenarios and develops defenses against them. This work is grounded in realistic threat models based on what a malicious, well-informed, reasonably staked validator could do and what an external, well-capitalized, and sophisticated developer could attempt.

This level of preparedness was validated in December, when Solana sustained a major DDoS attack that lasted for weeks, reportedly peaking at nearly 6 Tbps, making it one of the largest attacks ever recorded against a distributed system. Despite the immense scale, the network showed little measurable impact, with sub-second confirmations and stable slot latency throughout the attack period.

Increased CPI Account Infos Limits

SIMD-0339: Increase CPI Account Infos Limit is set to activate on mainnet during the Agave 3.1 release cycle. This increases the cross-program invocation (CPI) account info limit by almost 4x, from 64 to 255, addressing a long-standing pain point for developers building programs that need to pass large account lists through CPIs. Account infos are the serialized account metadata passed into CPI syscalls, enabling the callee program to read the accounts provided by the caller.

Previously, CPIs were restricted to just 64 account infos per syscall. This constraint forces programs to deduplicate and reconstruct account lists prior to CPI calls, adding complexity and overhead. In practice, many real-world programs routinely exceed this threshold, for example, wrappers around DEX aggregators such as DFlow or Jupiter.

In addition to increasing the limit, this feature gate introduces changes to compute unit costs that scale with the number of account infos and instruction accounts passed to a CPI. This preserves incentives for programs to minimize account usage. 

Because the limit is only being raised, the change is fully backward compatible and does not affect existing program behavior.

Validator Vote Account V4 and Delayed Commission Updates

Two feature-gated updates scheduled for activation during the Agave 3.1 release cycle are especially important for validator operators. The first is SIMD-0185: Vote Account V4, which introduces a new version of the vote account state to enable upcoming protocol upgrades, including Alpenglow, block revenue distribution, and improvements to commissions.

Today, vote accounts only store a single commission rate. However, with the upcoming ability to distribute block revenue in-protocol outlined in SIMD-0123: Block Revenue Sharing, validators will need the ability to set separate commission rates for different income streams.

Additionally, all block-fee revenue, including base and priority fees, is currently deposited into the validator identity account. This can introduce operational and security concerns, as the identity account cannot be a cold wallet because it must frequently sign messages for critical networking protocols such as Turbine and Gossip.

Vote Account V4 addresses these constraints by expanding vote state with new fields (see code block below) that allow validators to configure both the commission rate and the collector account for inflation rewards and block revenue. The update also removes the legacy prior_voters field.

pub struct VoteStateV4 {
    pub node_pubkey: Pubkey,
    pub authorized_withdrawer: Pubkey,

    /// REMOVED
    /// commission: u8,

    /// NEW: the collector accounts for validator income
    pub inflation_rewards_collector: Pubkey,
    pub block_revenue_collector: Pubkey,

    /// NEW: basis points (0-10,000) that represent how much of each income
    /// source should be given to this VoteAccount
    pub inflation_rewards_commission_bps: u16,
    pub block_revenue_commission_bps: u16,

    /// NEW: reward amount pending distribution to stake delegators
    pub pending_delegator_rewards: u64,

    /// NEW: compressed bls pubkey for alpenglow
    pub bls_pubkey_compressed: Option<[u8; 48]>

    pub votes: VecDeque<LandedVote>,
    pub root_slot: Option<Slot>,

    /// UPDATED: serialization structure of the AuthorizedVoters map is
    /// unchanged but will now contain entries for the previous epoch.
    pub authorized_voters: AuthorizedVoters,

    /// REMOVED
    /// prior_voters: CircBuf<(Pubkey, Epoch, Epoch)>,

    pub epoch_credits: Vec<(Epoch, u64, u64)>,
    pub last_timestamp: BlockTimestamp,
}

As part of the update, commission values will be stored in basis points. However, the existing UpdateCommission instruction in the Vote Program only supports integer-percentage commission values. Until SIMD-0291: Commission Rate in Basis Points is adopted, commission rates will remain limited to whole percentages, so commission calculations should continue to use integer percentage values for now.

Existing tooling or programs that read vote state, including the stake program, will be updated to support the new vote account version.

Delayed Commission Updates

The second feature-gated update important for validator operators is SIMD-0249: Delay Commission Updates. This change allows validators to submit commission updates at any time, while ensuring those updates do not take effect until at least one full epoch has passed.

The vote program will be modified to remove the current restriction that prevents commission increases during the first half of an epoch. Instead of limiting when a commission change can be submitted, the protocol enforces a delay before it becomes active. This means validators can adjust commission rates freely but must wait at least one full epoch before the new rate takes effect.

This delay also benefits stake delegators by giving them a full epoch of notice to respond to upcoming commission changes. Critically, it stops “commission rugging,” a practice in which malicious validators temporarily spike their commissions to 100% shortly before an epoch boundary to capture rewards, then quickly revert to normal shortly after.

State Bond (Rent) Reduction

High state bond requirements, commonly referred to as “rent”, remain one of the most important long-term scaling constraints for Solana developers. Today, state bonds on mainnet are expensive, with storage costing roughly $1M per gigabyte. For example, creating a single new token account (ATA) requires just over 0.002 SOL, which at current prices is approximately $0.25. This makes large-scale direct token airdrops prohibitively expensive and creates friction for micropayments and stablecoin payment applications, which must either subsidize token account creation or pass that cost on to end users.

A first step toward reducing this burden is SIMD-0194: Deprecate Rent Exemption Threshold, scheduled for activation in the Agave 3.1 release cycle. This marks the beginning of a broader effort to meaningfully lower and simplify storage costs, enabling applications to scale to millions of users without prohibitive state-related capital requirements. In addition, three more SIMDs are currently in the pipeline to directly address state bond costs and further reduce rent.

SIMD-0194 simplifies future rent updates. Today, calculating whether an account is rent-exempt is relatively expensive for on-chain programs. The current `Rent::minimum_balance` computation uses floating-point (f64) math and consumes roughly 256 compute units per call. Under SIMD-0194, this is reduced to just 8 CUs by removing floating-point operations from rent exemption logic.

This is achieved by deprecating the exempt_threshold (f64) field, eliminating the need for programs to perform floating-point calculations when determining rent exemption status.

As part of the change, lamports_per_byte_year is renamed to lamports_per_byte, and the default value is doubled from 3480 to 6960, reflecting the fact that rent exemption has historically been defined as holding two years' worth of rent. Importantly, this update does not change the amount required for an account to be rent-exempt; it only simplifies and standardizes how the value is represented and computed.

The update is fully backwards compatible, and existing deployed programs will not be impacted.

Looking Ahead: SIMD-0437

Of the additional rent-related SIMDs expected later this year, the most significant is SIMD-0437: Incrementally Reduce `lamports_per_byte` to 696. This proposal outlines a structured schedule to reduce long-term state bond costs by gradually lowering `lamports_per_byte` from 6960 down to 696, a 10x reduction.

SIMD-0437 supersedes the earlier SIMD-0436, which proposed a single 50% reduction. Instead, SIMD-0437 introduces a more granular five-step reduction schedule: 6333 → 5080 → 2575 → 1322 → 696.

Breaking the change into multiple phases allows the network to observe and evaluate state growth over time, while also separating the most controversial reductions into distinct steps for clearer discussion and governance.

Other Notable Agave 3.1 Release Cycle Updates

Strict Enforcement of 32 Data and 32 Coding Shreds

Today, Turbine accepts a variable number of shreds per FEC set. This behavior adds unnecessary complexity without providing meaningful benefits. Validating shred indices becomes more difficult because receivers need the coding shreds to determine index boundaries. The upcoming feature gate activation for SIMD-0317: Enforce 32 data + 32 coding shreds standardizes this behavior by requiring exactly 32 data shreds and 32 coding shreds per FEC set. This change also strengthens equivocation detection, which will later inform enforcement mechanisms such as slashing penalties.

Static Instruction Limits

Today, transactions with more than 64 top-level instructions pass initial sanitization checks but fail at runtime. This creates unnecessary scheduler work by allowing transactions guaranteed to fail to enter the pipeline and consume scheduler resources.

The upcoming feature gate activation for SIMD-0160: Static Instruction Limit addresses this by enforcing the 64-instruction limit during transaction sanitization. Under this change, any transaction exceeding 64 top-level instructions (including CPI calls) will fail sanitization and be rejected immediately.

Reduced Turbine ChaCha Rounds

SIMD-0332: Reduce ChaCha rounds for Turbine from 20 to 8 delivers a small but meaningful performance improvement in Turbine’s ability to propagate block data. Today, Turbine uses ChaCha20 to deterministically shuffle stake-weighted validators when constructing block propagation trees. This randomized ordering is important for preventing censorship attacks, but it comes with additional computational overhead.

ChaCha rounds act as a deterministic scrambler, where each round applies transformations to further randomize the output. More rounds provide stronger cryptographic security, but also increase compute cost.

With Agave’s transition to XDP, retransmit sends have become nearly instantaneous, meaning the weighted shuffle step now dominates the runtime. At roughly ~1 microsecond per shred, reducing the shuffle from ChaCha20 to ChaCha8 keeps the process sufficiently randomized for censorship resistance while preventing it from becoming a bottleneck.

New Instruction Data Pointer

Today, sBPF programs must parse the accounts section of the serialized input region in order to locate instruction data. Because the serialization layout places accounts before instruction data, programs must iterate through every account entry before reaching the instruction data segment, which imposes unnecessary work for programs that primarily (or exclusively) operate on instruction data.

The upcoming feature gate activation for SIMD-0321: VM Register 2 Instruction Data Pointer improves this by providing a 64-bit pointer to instruction data in VM register r2 at the program entrypoint. This pointer directly references the start of the instruction data section in the input region, allowing programs to access instruction data immediately without first parsing the accounts section. This reduces compute unit consumption by eliminating parsing overhead.

Compatibility note: this feature is only backwards compatible for programs that do not currently read from r2 at entrypoint. Any programs that incorrectly rely on the uninitialized/garbage value previously present in r2 at entrypoint will break once this feature is activated.

RPC Improvements

The getProgramAccounts RPC endpoint now returns proper JSON-RPC errors when malformed filters are provided. Previously, invalid filters were silently ignored, causing the RPC call to fall back to an unfiltered query, often triggering unexpectedly expensive requests and unnecessary load on RPC nodes. With this improvement, bad filters now return a clear error, preventing accidental resource-intensive queries and making debugging significantly easier.

Additionally, signature verification failures in simulateTransaction() and the preflight stage of sendTransaction() will now be returned as a TransactionError::SignatureFailure on the simulation result’s err field, rather than being thrown as a JSON-RPC API error (-32003).

As a result, applications that previously relied on catching JSON-RPC exceptions for signature verification failures should now expect these errors to appear directly on the simulation response. Applications that already materialize and handle TransactionError values in simulation results can now expect to receive TransactionError::SignatureFailure at those verification points.

Conclusion

Agave v3.1 is a substantial client upgrade that delivers a range of performance gains and optimizations, including reduced disk I/O, faster transaction processing, and improved RPC error handling. Agave has made noticeable progress in network hardening, with stronger resilience under adversarial conditions. This release also marks the first step toward meaningful reductions in state bonds.

Anza continues to differentiate itself as the only core development team in the industry shipping improvements across the entire stack, including submitting patches to the Linux kernel. With Agave 3.1 set to power the network soon, Solana continues to prove its ability to scale.

Looking ahead, the next milestone is Agave 4.0 and the testnet launch of Alpenglow, currently scheduled for early May.

Further Resources

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