Agave 2.0 Summary

The release of Agave validator client v2.0 marks a significant milestone in Solana’s journey toward a more robust, multi-client ecosystem. This update introduces several critical improvements to boost network performance, reliability, and efficiency. Key changes in this update include:

‍

• Extensive codebase refactorings and optimizations
• Partitioned epoch rewards
• Rewarding the full priority fee to validators
• The new central scheduler is now on by default
• The ZK ElGamal Proof program
• Get-Sysvar Syscall
• GetEpochStake Syscall
• MoveStake and MoveLamports
• Removal of deprecated RPC methods
• Crate renamings

‍

Whether you run a validator, build on the platform, or actively use Solana, this comprehensive overview of the Agave 2.0 update will equip you with the insights needed to understand and take advantage of these latest innovations.

What Makes 2.0 a Major Version Update?

There is no longer a single ‘Solana validator.’ Agave 2.0 embraces Solana’s new multi-client world and marks a clean break from the old Solana Labs GitHub repository. The Solana Labs repository will be archived, and new pull requests or issues will no longer be accepted. Previously, this repository mirrored activity from the Agave repository. Developers should migrate all activities to the Anza Agave GitHub repository if they haven’t already done so. The Solana Labs to Agave migration process began on March 1st and is publicly tracked on their GitHub.

‍

As the ecosystem evolves, operators must adapt to running one or more clients. Following this shift, several crates are being renamed, clearing the namespace to support multiple clients—most notably Firedancer — managed by independent developer teams. Crates maintained by Anza will now be prefixed with “agave,” making them easily identifiable as Anza-specific dependencies within the multi-client environment.

‍

‍

Affected crates are:

‍

solana-validator, solana-ledger-tool, solana-watchtower, solana-install, solana-geyser-plugin-interface, solana-cargo-registry

‍

As detailed in our previous transition guide, the 2.0 update introduces several breaking changes, most notably removing several obsolete and deprecated endpoints—key updates that all Solana developers should be aware of by now. Full details of RPC changes are included at the end of this article.

Features Rollout

At the time of writing, ~20.7% of validators are running version 2.0.14. Feature gate activations on mainnet are temporarily paused to allow v2.0 adoption to align more closely with activations on the testnet and devnet. Once the mainnet cluster has widely adopted v2.0, feature gate activations are expected to resume according to the scheduled activation order.

‍

The new full features discussed in the following sections are currently not live and will be slowly rolled out over the 2.0 lifecycle using a 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.

‍

Reward Full Priority Fee to Validators

This highly anticipated and much debated economic update is now being implemented following the proposal, SIMD-0096, which went through a validator governance vote in May. The vote concluded at the end of epoch 620, with 51.17% of the stake participating and 77.77% voting in favor. The feature-gated update will fundamentally change the network’s handling of priority fees. Instead of the current model, which splits fees with 50% burned and 50% rewarded to validators, the new model will allocate 100% of priority fees directly to validators.

Above: Solana weekly priority fees in USD value (source)

‍

While priority fees are technically optional, they have become standard practice as economic activity on Solana has increased. These fees are calculated in micro-lamports (millionths of a lamport) per compute unit using the formula:

‍

‍prioritization fee = compute unit price (micro-lamports) x compute unit limit

‍

Going forward, all priority fees will be awarded to block producers. This creates a stronger alignment of incentives and reduces the likelihood of validators engaging in out-of-protocol arrangements for transaction inclusion, which has been an issue in the past.

‍

Although removing fee burns slightly raises SOL’s net inflation rate, new token issuance through staking rewards has a far more significant impact. Readers can refer to our earlier Helius blog post on Solana’s issuance and inflation schedule for a more detailed breakdown of these dynamics.

‍

Partitioned Epoch Rewards

Partitioned epoch rewards aim to distribute stake rewards across multiple blocks, alleviating the performance issues tied to concentrating reward distribution within the first block of each new epoch. The main bottleneck in this process is the requirement to write updates back to the growing number of active stake accounts on the network, now totaling approximately 1.4 million. \

Under this new approach, stake reward computation and distribution at the epoch boundary will be divided into two distinct phases:

‍

• Rewards Calculation Phase: In this phase, epoch rewards for all active stake accounts are computed, and the distribution is broken into scheduled chunks.
• Rewards Distribution Phase: The pre-calculated epoch rewards for active stake accounts are distributed accordingly.

‍

To facilitate and monitor the process, a Sysvar account, EpochRewards, will track and verify reward distributions throughout the distribution phase. The EpochRewards Sysvar records if the rewards distribution phase is in progress and the information needed to resume distribution when starting from a snapshot.

Reward Calculation

Reward calculations will be performed at the first block of the epoch. Once calculated, the rewards are partitioned into distribution chunks stored in the bank, which will be distributed during the reward distribution phase.

‍

To minimize the impact on block processing time during the reward distribution phase and to ensure that each block distributes a subset of the rewards in a deterministic manner, a target of 4,096 stake rewards will be distributed per block. To safeguard against dramatic growth in the number of stake accounts, the number of blocks is capped at 10% of the total slots in an epoch. Only if this block cap is reached are accounts per partition allowed to surpass the 4,096 target.

Reward Distribution

Reward distribution begins immediately following the reward computation phase, starting from the second block of the epoch. Reward distributions occur at the top of the block before normal transaction processing.

‍

As a result, users may see rewards credited to their stake accounts a few blocks later than before. However, the overall experience remains similar, as the prolonged first block time at the epoch boundary previously delayed the user’s access to stake accounts. An additional benefit of this approach is that non-staking transactions can continue processing smoothly, whereas previously, they were blocked during reward distribution.

‍

Due to the comparatively low number of vote accounts, approximately 1,500, the existing mechanism for distributing vote rewards at the first block of the epoch boundary will remain unchanged. Only stake rewards will be distributed over multiple blocks.

‍

Central Scheduler Is Now On By Default

First introduced as a feature release in the v1.18 update, the central scheduler, formerly known as “the scheduler,” was not enabled by default and had to be enabled by operators using the —block-production-method central-scheduler flag when starting a validator. It is now turned on by default. The previous scheduler implementation had several issues that could adversely affect performance. Bottlenecks in transaction processing often lead to jitter or inconsistency in transaction ordering and prioritization.

‍

The newer implementation replaces the previous model of four independent banking threads, each managing its own transaction prioritization and processing. In this revised structure, the central scheduler is the sole recipient of transactions from the TPU’s SigVerify stage. It builds a priority queue and deploys a dependency graph, known as a prio-graph, to better manage the processing and prioritization of conflicting transactions. This new scheduler design increases scalability and flexibility, allowing for an increase in the number of threads without the previous concerns of increased lock conflicts. The initial rollout of the central scheduler has been shown to generate better rewards, resulting in improved earnings for many operators. Our previous Helius post on the Solana v1.18 update extensively covered how the central scheduler works.

‍

ZK ElGamal Proof program

The ZK Token Proof program, originally planned for inclusion in the 1.17 release, is now deprecated and will be replaced by a more versatile, application-independent ZK ElGamal Proof program. The new ZK ElGamal Proof program retains the portions of the ZK Token Proof program that apply broadly across applications, such as verifying the validity of a public key or the range of values encrypted within an ElGamal ciphertext. However, it omits application-specific elements like the zero-knowledge proof validation required for SPL Token transfer instructions. The new ZK ElGamal Proof program will be incorporated into the list of built-in programs at the address ZkE1Gama1Proof11111111111111111111111111111.

‍

To learn more about the ZK Token Proof Program, read our original write-up on the Helius blog.

Get-Sysvar Syscall

Syscalls, or system calls, request services from the operating system kernel. In Solana’s context, a Syscall enables programs running within the Solana Virtual Machine (SVM) to interact with external resources and services.

‍

Sysvars expose cluster state information, such as the recent block hash and epoch rewards. These accounts are populated at known addresses. Programs can access Sysvars via a Sysvar account or query them via a Syscall. On-chain programs use many Sysvars for a wide range of use cases, and certain Sysvars are essential for the network’s operation.

‍

The Get-Sysvar Syscall, initially proposed in SIMD-127 by Anza engineer Joe Caulfield, introduces a unified Syscall interface for accessing Sysvar data. This upgrade enables retrieval of previously inaccessible Sysvar data, including SlotHashes and StakeHistory. With this new interface, developers can access specific fragments of Sysvar data—such as calling SlotHashes::get_slot(slot) and StakeHistory::get_entry(epoch)—without needing to duplicate entire data structures.

‍

The update also minimizes overhead when modifying Sysvar data layouts or adding new Sysvars. Previously, each new Sysvar required the addition of a corresponding Syscall, creating a tightly coupled relationship that inflated the Syscall interface over time and complicated maintenance. Now, a single sol_get_Sysvar Syscall will serve all Sysvar interfaces, enabling consistent and efficient data retrieval from any Sysvar.

‍

Introducing the new Syscall simplifies the process of modifying and adding new Sysvars. It significantly reduces the complexity and maintenance requirements of the Syscall interface. Additionally, this update paves the way for expanding BPF program access to Sysvar data, enabling on-chain programs to read more Sysvar information without impacting transaction size.

‍

GetEpochStake Syscall

The new GetEpochStake Syscall will introduce a highly requested feature for retrieving a vote account’s delegated stake for the current epoch, providing a more efficient, direct method for retrieving this information on-chain.

‍

Currently, programs cannot access real-time data on the stake delegated to specific vote accounts for the current epoch, creating a barrier for use cases like validator governance and secondary consensus mechanisms. Enabling the on-chain querying of this data will unlock these applications and pave the way for future use cases.

‍

With GetEpochStake, developers provide a 32-byte vote account address, and the syscall will return a u64 integer representing the total active stake currently delegated to that vote account. If the address provided does not correspond to a valid vote account or does not exist, the Syscall will simply return 0.

‍

MoveStake and MoveLamports

Two new stake program instructions, MoveStake and MoveLamports, are being introduced to facilitate value transfers between stake accounts. These instructions, first proposed in SIMD-0148, assist developers by allowing the movement of funds between accounts with matching authorities without the control of the withdrawer authority.

‍

Previously, protocols managing user stakes have faced challenges when splitting stakes across multiple validators and regularly redelegating between them. When a protocol splits a user’s stake for deactivation, it must fund the rent exemption lamports for the new account. The protocol cannot reclaim the rent exemption lamports upon merging these split accounts.

MoveStake: This instruction allows active stake to be moved between accounts, transferring it from one active account to another or from an active account to an inactive one, thereby reactivating the account. If the entire source account delegation is moved, the source account becomes inactive. The rent-exempt balance remains untouched in all scenarios, and minimum delegation rules are maintained for active accounts.

‍

MoveLamports: Move excess lamports from one active or inactive account to another active or inactive account, where “excess lamports” refers to lamports that are neither delegated stake nor required for rent-exemption. MoveLamports enables housekeeping tasks such as reclaiming lamports from merged accounts and consolidating unused funds.

‍

To streamline implementation, these changes do not support activating or deactivating accounts or affect partially active stake accounts. These new program instructions do not alter existing functionality.

‍

Bonus: The Solana-SVM Crate

With the release of Agave 2.0 comes a brand-new solana-svm crate offering developers direct access to core SVM components through a streamlined API independent of the full validator framework. This opens up Solana’s high-performance transaction processing for applications beyond the validator, such as off-chain services, lightweight clients, state channels, and rollups.

‍

By decoupling the API from the rest of the runtime, this crate eliminates the need for components like Bank instances, reducing operational overhead. Developers can now leverage the same robust components that support Solana’s mainnet-beta to build custom SVM projects such as light clients, state channels, rollups, and off-chain services. The core of this API is the TransactionBatchProcessor struct, which allows applications to process batches of sanitized Solana transactions with the full suite of downstream Agave components, including the BPF Loader, eBPF, and virtual machine.

‍

Above: the transaction batch processor (image source: Anza)

‍

Read the deep dive into Anza’s New SVM API for complete details on this exciting development.

‍

Removed RPC Endpoints

Multiple obsolete and deprecated v1 Agave RPC endpoints have been removed. The Helius Devrel team has contacted all customers using these endpoints. Through internal analysis, we’ve previously identified a small group of customers actively using the following endpoints, which are set for removal:

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

Again, we strongly recommend all developers check for references to these calls and update them appropriately with the suggested replacements.

‍

Above: a complete list of obsolete and deprecated v1 Agave RPC endpoints to be removed

‍

N.B. The alternative approach for getAccountInfo shown in the image can be found here.

‍

SDK breaking changes include:

‍

• Support for Borsh v0.9 removed, please use v1 or v0.10 (#1440)
• Copy trait is no longer derived on Rent and EpochSchedule; switch to using clone()
• solana-sdk: deprecated symbols) removed
• solana-program: deprecated symbols removed

‍

For validator operators, several deprecated validator arguments will be removed upon the release of Agave v2.0. A complete list of these can be found here.

‍

Conclusion

The Agave 2.0 update marks a significant advancement for Solana, incorporating numerous feature implementations and runtime optimizations. This release continues to push the boundaries with powerful new Syscalls, extended functionality, and comprehensive housekeeping, including crate renamings, deprecated RPC method removals, and streamlined validator arguments. Agave 2.0 extends Solana’s capabilities and refines its performance and usability. Whether you’re a developer, validator, or active user, the Agave 2.0 update opens up exciting new possibilities for everyone in the Solana ecosystem.

‍

Additional Resources / Further Reading

• Agave v2.0 Release Schedule
• Agave v2.0 Change Log
• Agave Release Versions

Disclaimer：

1. This article is reprinted from [helius)]. All copyrights belong to the original author [Lostin]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.