Agave v2.1 Update: All You Need to Know

Many thanks to 0xIchigo, Andrew Fitzgerald, and Steven C for reviewing earlier versions of this work.

The release of Agave validator client v2.1 marks a significant milestone in Solana’s journey toward a more resilient, multi-client ecosystem. This update delivers key improvements to enhance network performance, reliability, and efficiency.

Notable Agave 2.1 Release Cycle Updates 

• Extensive performance optimizations
• Increased block limits
• Introduction of the greedy scheduler (experimental)
• Native support for Secp256r1 signature verification (Update: pushed back to Agave 2.2)
• Disabling rent fee collection and rent rewrites
• Relaxed constraints for transaction loading failures
• Migration of config and address look-up table programs to core BPF

Each section in this article is designed to stand alone, allowing readers to navigate freely and focus on the topics that interest them most. Whether you’re a validator operator, developer, or active user, this in-depth overview of Agave 2.1 will provide the insights you need to leverage these advancements effectively.

Features Rollout

At the time of writing, 88% of stake is now running Agave version 2.1.11. Feature gate activations on mainnet were temporarily paused to allow for wider v2.1 adoption and are expected to resume shortly according to the scheduled activation order. 

Most of the new full features discussed in the later sections are currently not live and are expected to be rolled out over the 2.1 release cycle using the feature gate system. Features are activated at certain epochs based on relative priority and the order in which they were activated on testnet and devnet clusters.

Performance Enhancements

Validators and RPC operators have reported noticeable gains in stability and performance with Agave 2.1. Over the past year, Anza has prioritized eliminating bottlenecks, optimizing resource efficiency, and enhancing overall performance. New client releases are just as much about refining core fundamentals—increase bandwidth, reduce latency—as they are about introducing new features. Before we get into the specifics of the 2.1 update, it’s worth taking a step back and quantifying the significant performance improvements achieved across the latest sequence of client updates.

Block Times

Faster block times on Solana are driving mean slot times below 400ms, with recent epochs on pace to complete in just under two days—the fastest in the network’s history. Both clients are ready for shorter block times. This acceleration has implications beyond just higher transaction throughput. Since staking rewards are tied to inflation emissions, which are calculated using "epoch years" rather than calendar years, validators and stakers stand to benefit. An epoch year assumes 182.5 epochs per year, based on the standard two-day epoch length. When epochs shorten, more fit within the same timeframe, effectively increasing the rate at which staking rewards are distributed.

Uptime

Solana demonstrated near-perfect reliability throughout 2024 and early 2025, maintaining 100% uptime for over one year. The last recorded outage occurred on February 6, 2024, when a known bug temporarily disrupted block finalization on Mainnet. This issue was swiftly identified and patched. Since then, Solana has produced blocks seamlessly, even during periods of intense network activity—such as the recent surge driven by Trump family token launches—proving its resilience under heavy load.

Skipped Slot Rates

The skipped slot rate measures how often a validator, assigned as the leader for a given slot, fails to produce a block within the allocated time. Since approximately epoch 700 in November 2024, skipped slot rates have dramatically declined. Previously fluctuating between 2% and 5% for several years, these rates have now dropped to near zero for most well-optimized validators.  

A contributing factor behind this improvement is the introduction of partitioned epoch rewards on mainnet in epoch 707. By spreading stake rewards across multiple blocks, this change mitigates the performance bottlenecks caused by reward distribution being concentrated in the first block of each new epoch, resulting in smoother network operation.

Additionally, Timely Vote Credits (TVC), introduced in November 2024, incentivize validators to vote promptly while discouraging delayed voting. By reducing the number of validators intentionally holding back votes, TVC improves cluster convergence, leading to faster confirmation and finality. This mechanism helps minimize forking and shortens fork durations. Since TVC scoring now influences stake pool rankings, operators have responded by upgrading their hardware and optimizing their validator setups for better performance.

Transactions Per Second (TPS)

Higher transactions per second (TPS) indicate increased chain throughput, and Solana’s non-vote TPS (AKA ‘True TPS’) has been on a steady upward trajectory since late 2023. Most recent data for the first week of February 2025 shows the network recorded a 50th percentile average of 1,228 TPS, with peak performance in the 99th percentile reaching 2,520 TPS.  

The all-time high TPS was observed during the PENGU token airdrop week ending December 23, 2024, when the 50th percentile averaged 1,260 TPS, while the 99th percentile peaked at 3,252 TPS. This sustained growth highlights Solana’s continued scalability and improvement in transaction processing efficiency.

Priority Fees

Finally, a comparison of priority fee collection between Agave 2.1 and the previous 2.0 version from January 27 to February 4, 2025, shows that Agave 2.1 consistently collects slightly higher priority fees.

Raising Block Limits

An increase in block limits, proposed in SIMD-0207: Raise Block Limit to 50M, is scheduled for Solana’s 2.1 release cycle. Currently, the protocol caps total computational resources per block at 48 million Compute Units (CUs). Block limits ensure nodes can keep up with the network by restricting the amount of work a leader can pack into a block. The founding team chose the current limit empirically based on how much validators can reasonably process to arrive at 400 millisecond block times. 

However, mainnet activity today is not constrained by execution times, meaning blocks could accommodate more transactions without exceeding the 400ms target. This update introduces a modest 4% increase to gradually expand network capacity, raising the per-block compute limit from 48M to 50M CUs. While a more aggressive increase—such as doubling the limit—could be feasible, it has been deemed too risky for an initial change. Expanding block limits impacts not just validators but also critical infrastructure like RPC nodes, indexers, and archival services, which must scale accordingly.

Other protocol limits remain unchanged:

• The per-account compute limit per block stays at 12M CUs.
• The maximum compute per transaction remains 1.4M CUs.

Further increases to block limits are anticipated and expected to proceed through the formal SIMD process.

Greedy Scheduler

Background: The Central Scheduler

The last major scheduler update—the central scheduler—was introduced in Agave 1.18 in May last year. This scheduler constructs a dependency graph of the top N priority transactions, where N is currently set to 256. It then attempts to schedule transactions in priority order, ensuring that non-conflicting transactions are processed first. Once scheduled, these transactions are removed from the graph, allowing previously conflicting transactions to be prioritized. The scheduler then refills the graph to maintain a queue of N transactions.

This approach was primarily designed to optimize larger batch processing, improving overall transaction throughput. However, one major drawback is that constructing the dependency graph and sorting transactions takes considerable time, creating a bottleneck. 

Refer to our previous Helius blog post for a more detailed overview of Agave 1.18 and the central scheduler’s implementation.

The New Greedy Scheduler

Unlike the central scheduler, the greedy scheduler does not construct a dependency graph. Instead, it follows a more straightforward approach:

• First, select the highest-priority transaction.
• If the transaction does not conflict with an ongoing batch, it is added to one of four worker thread queues.
• If conflicts arise, the current batch is finalized and dispatched, and the transaction is added to a new batch.

This method significantly speeds up transaction scheduling but results in smaller batch sizes, which increases per-transaction overhead. However, in real-world mainnet conditions, this tradeoff is worthwhile since execution time is dominated by BPF processing rather than batching.

The central scheduler struggles under high network load, primarily because it requires time to sort transactions and build the dependency graph. By removing this overhead, the greedy scheduler improves responsiveness at the cost of reduced batching efficiency.

Consider a scenario where transactions fall into three conflict groups: A, B, and C. Transactions conflict when one transaction wants to write an account that another transaction wants to read or write to. Transactions in A have higher priority fees than those in B or C.

• The central scheduler would schedule non-conflicting transactions A1, B1, and C1 together in a batch: [A1, B1, C1].
• The greedy scheduler prioritizes the highest-fee transactions first, scheduling A1 as a separate batch and then moving on to A2 in the next batch.

This prioritization ensures faster scheduling but may lead to smaller batches than the central scheduler.

Native Program for Verifying Secp256r1 Signatures

Solana is introducing a new native program for verifying secp256r1 elliptic curve signatures, enabling on-chain support for Passkeys, the WebAuthn standard, and new account abstraction models, including two-factor authentication (2FA). This enhancement paves the way for passwordless authentication, already widely used in Web2, to serve as a second factor for on-chain security.

The secp256r1 elliptic curve is a NIST-standardized cryptographic curve and is extensively supported across modern devices, including:

• WebAuthn: A W3C standard for public-key cryptography-based authentication supported by all major web browsers.
• Apple’s Secure Enclave: A hardware-based Trusted Execution Environment (TEE) that signs messages and is accessible only via biometric authentication.
• Android Keystore: An API for managing private keys and signing methods, leveraging the device's TEE for secure key storage.
• Passkeys: A FIDO Alliance and W3C standard replaces passwords with cryptographic keypairs and is compatible with elliptic curve cryptography.

Several other networks, including Ethereum (EIP-7212), have also explored integrating support for the secp256r1 curve.

Secp256r1 Program Details

The new program will be deployed under ID: Secp256r1SigVerify1111111111111111111111111

Instruction Structure:

• A u8 counter specifies the number of signatures to verify.
• A single byte of padding follows.
• For each signature, the following serialized struct is used:

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get msg data
}

This update originates from SIMD-0048: Native Program for Secp256r1 Sigverify, proposed by the Bunkr team. The Secp256r1 SigVerify Precompile Program will function similarly to Solana’s existing support for secp256k1 and ed25519 signatures.

Disable Rent Fee Collection and Skip Rent Rewrites

Two related updates, proposed in SIMD-0084: Disable Rent Fees Collection and SIMD-0183: Skip Rent Rewrites, will eliminate much of the legacy overhead associated with rent-paying accounts.

Rent fee collection is a complex component within the Bank. Disabling it will simplify the validator client codebase and streamline the development of all validator client implementations, as they will no longer need to replicate rent collection logic. Rent will no longer be deducted from accounts, and collected rent fees will no longer be distributed to validators. Creating new rent-paying accounts is already no longer possible—any attempt will result in a transaction error.

Currently, rent collection checks every account at least once per epoch, loading and storing accounts even if they remain unchanged. Since all Solana accounts are already rent-exempt, maintaining this process is unnecessary computational work.

Rent-related account rewrites will be eliminated, reducing the number of accounts stored per slot. As a result, validators will see performance gains, as fewer accounts will be included in the accounts delta hash and incremental account hash computations. This change also decreases the size of incremental snapshots, further reducing resource consumption.

Relax Transaction Constraints: Loading Failures

Currently, Solana transactions are subject to strict constraints that can cause them to fail before they are included in a block. These pre-block failures result in wasted validator computation, as resources are spent without earning transaction fees—effectively performing work without compensation.

Block production is further complicated by the need to filter out transactions that invoke invalid programs or exceed the 64 MiB (~67.11 MB) maximum loaded account data limit. These restrictions increase the complexity of block assembly and make it harder to determine block validity. By relaxing these constraints, transactions could be included in a block and charged fees without requiring program data to be loaded and verified beforehand. This shift aims to remove reliance on the account state for block validation.

These changes, proposed in SIMD-0191, may impact tooling, such as blockchain explorers, which assume all transactions attempt execution. Additionally, users must ensure their transactions are executable to avoid unnecessary fee expenditures.

Migration of Config & Address Look-Up Table Programs to Core BPF

As part of the ongoing transition from native enshrined programs to Berkeley Packet Filter (BPF) programs, the Config and Address Lookup Table programs will be migrated to Core BPF programs. This shift decouples these critical programs from the validator runtime, enabling more flexible updates and easier maintenance.

BPF programs are less complex than their native counterparts, simplifying development and maintenance across different validator clients. With this change, teams working on Firedancer and Anza will no longer need to track and implement program changes separately in their runtimes. Instead, updates will be applied universally across all clients. 

The reimplemented programs will maintain identical ABIs to their native versions, ensuring full compatibility while differing only in compute usage.

Conclusion

The Agave 2.1 update marks a major step forward for Solana, introducing key feature enhancements and runtime optimizations. This release strengthens the network by expanding functionality, refining performance, and pushing the boundaries of what Solana can achieve. With native support for Secp256r1 signature verification, increased block limits, extensive performance improvements, and the eventual introduction of the greedy scheduler, Agave 2.1 enhances both efficiency and scalability. Whether you're a developer, validator, or active user, this update unlocks new possibilities, making Solana faster, more flexible, and more powerful than ever before.

Further Resources

• Agave Client Repository
• Agave v2.1 Release Schedule
• Agave v2.1 Tagged Pull Requests