Agave v2.2 Update: All You Need to Know

Many thanks to Alexander Meißner, 0xIchigo, and Will Hickey for reviewing earlier versions of this work.

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

Notable Agave 2.2 Release Cycle Updates 

• Extensive performance optimizations
• 20% Increase in block limits from 50M to 60M CUs
• Introduction of the Accounts Lattice Hash (ALH)
• Secp256r1 signature verification (pushed back from Agave 2.1 release cycle)
• Deployment and execution of SBPFv1, v2 and v3 programs
• Lift CPI Caller Restriction
• Loader-v4
• Greedy Scheduler is activated by default

Each section of this article is self-contained, making it easy for readers to explore the topics most relevant to them. Whether you're a validator operator, developer, or engaged user, this comprehensive guide to Agave 2.2 offers the key insights needed to take full advantage of the latest improvements.

Features Rollout

At the time of writing, 19.8% of total stake is running Agave v2.2.*, signaling strong support for network-wide adoption. Mainnet feature gate activations have been temporarily paused during the upgrade period and are expected to resume shortly following the planned activation sequence.

Most major features introduced in Agave 2.2 are currently gated and not yet active on mainnet. These will be progressively enabled throughout the 2.2 release cycle via Solana’s feature gate system. Activation timing is determined by feature priority and their rollout order on testnet and devnet clusters. Please refer to the Agave feature gate tracker for the latest updates.

Raise Block Limits to 60M CUs

Anza has set an ambitious goal for 2025: doubling the available block space on Solana. As part of this effort, SIMD-0256: Increase Block Limits to 60M is scheduled for inclusion in the upcoming Solana 2.2 release, representing a 20% increase over the current block limit.

This follows a prior upgrade that increased block limits from 48 million to 50 million compute units (CUs), after which block times consistently remained below the 400ms target. Recent data shows that blocks routinely saturate the 50M CU cap, signaling readiness for further scaling.

Note: Some blocks appear as 104% full due to a hardcoded constant in the Firedancer dashboard’s reporting logic.

Other protocol limits remain consistent in this update:

• The per-account compute budget per block is unchanged at 12 million CUs.
• The maximum compute per transaction remains capped at 1.4 million CUs.
• The aggregate compute limit for vote transactions per block stays at 36 million CUs.
• The maximum new account data allocation per block remains limited to 100 MB.

Raising block limits directly impacts user experience: higher network throughput results in lower median transaction fees and increases the likelihood of successfully landing transactions during congestion periods.

Challenges in Raising Block Limits

When boosting throughput, a careful and gradual approach to raising block limits is advisable, as two key challenges must be addressed:

1. Infrastructure Readiness

The broader ecosystem infrastructure must keep pace with the core client optimizations. Specifically, the write layer cannot outpace the read layer (e.g., RPC nodes, indexers, and archival services) without degrading the user experience.

2. Timely Block Propagation

Another bottleneck lies in delivering blocks from the leader node to the rest of the cluster. Significantly larger blocks could cause block distribution times to exceed the 400ms target, especially under high-load conditions.

A pressing challenge is the retransmit stage of the Transaction Validation Unit (TVU), through which shreds are distributed across the cluster. Large validators approach 150,000 outbound packets per second (PPS) due to Turbine’s aggressive fanout factor of 200 (i.e., each node is responsible for relaying shreds to 200 other nodes). If this is handled inefficiently, it can cause shred backlogs, erratic leader handoffs, and inconsistent state views across the network.

To address this, Anza engineers are currently overhauling the block distribution pipeline. The team is currently working on transitioning to XDP (eXpress Data Path), which enables bypassing the kernel by exposing packet handling directly to user space. This approach eliminates costly intermediate copies, allowing the validator software to communicate directly with the network interface card (NIC).

Accounts Lattice Hash (ALH)

Solana’s path to supporting billions of accounts requires a more scalable approach to hashing global account state. The newly introduced Accounts Lattice Hash (ALH) will replace the previous Merkle-based account hashes with a more efficient and scalable alternative based on homomorphic hashing, which allows for creating a new hash from existing hashes without having to recompute from scratch.

Solana currently maintains two account state hashes:

• Epoch Accounts Hash (EAH): A Merkle root of the entire account state, computed once per epoch.
• Accounts Delta Hash (ADH): A Merkle root of accounts modified within a single block, recomputed every block.

Both rely on sorting accounts by public key and constructing Merkle trees, which leads to performance and scalability challenges, especially as the account set grows. The dual-hash model emerged as a compromise: EAH was accurate (including all account state) but infrequent, while ADH was frequent but partial (only modified accounts). Ideally, every block would contain a complete and up-to-date hash of the entire account state, without the overhead of recomputing a Merkle tree.

The Accounts Lattice Hash: How It Works

The ALH achieves this goal by using a homomorphic hashing function that allows incremental updates. Instead of rebuilding a Merkle tree each time, the ALH simply adds or subtracts individual account hashes (LtHashes) as accounts are written to. The end result is a single 2048-byte hash that summarizes the state of all accounts. Critically, this can be updated block by block without having to recompute from scratch.

This approach offers O(n) complexity, a significant improvement over the O(n log n) complexity of Merkle trees. It allows every block to include a hash of the entire account state, without costly recomputation.

Integration and Decommissioned Hashes

The rollout spans three separate SIMDs with corresponding independent feature gate activations across the Agave 2.2 release cycle.

• SIMD-0215: Accounts Lattice Hash
• SIMD-0220: Snapshots use Accounts Lattice Hash
• SIMD-0223: Removes Accounts Delta Hash

With these changes, the Accounts Lattice Hash replaces both ADH and EAH. ALH will be integrated into each block's bank hash, enabling full-state hashing at block frequency rather than epoch frequency.

Performance and Tradeoffs

The switch to ALH offers substantial validator performance benefits by eliminating Merkle-based hashing on every block. This will streamline consensus and snapshot generation. For example, validators no longer need to sort accounts or rebuild trees during block finalization or snapshot production—ALH updates are simple additive operations.

However, this approach does not support inclusion or exclusion proofs, unlike Merkle or Verkle trees. While this impacts certain cryptographic verification use cases, such as light clients and Simple Payment Verification (SPV), the tradeoff is considered worthwhile given the dramatic efficiency gains. A discussion on alternative methods for inclusion proofs can be found here.

Snapshot Integration

Since computing the initial Accounts Lattice Hash is expensive, the ALH value now persists in validator snapshots and is restored at startup if available. Snapshots will reflect the updated ALH format rather than Merkle-based Snapshot Hashes, further aligning Solana’s storage and hashing model around this new design.

Native Secp256r1 Signature Verification

Solana is adding native support for secp256r1 elliptic curve signature verification, a critical upgrade that enables on-chain compatibility with Passkeys, the WebAuthn standard, and advanced account abstraction models, including two-factor authentication (2FA). This update introduces passwordless authentication, already ubiquitous in Web2, into the Web3 domain, enhancing security and usability for on-chain applications.

Initially scheduled for the Agave 2.1 release, this feature was deferred to 2.2. For more details, see our comprehensive breakdown of Secp256r1 Signature Verification in the Agave 2.1 update.

Precompile Alignment Bug

Shortly after the initial rollout of Agave 2.2, a critical bug was discovered in the implementation of the Secp256r1 and Ed25519 precompile programs. The bug was triggered under the new `--transaction-structure` view flag, which exposes raw transaction layouts without guaranteeing alignment. The precompiles incorrectly assumed 2-byte alignment for instruction data, leading to inconsistent execution results between block producers and validators. This caused bank hash mismatches, forcing leaders to abort, leading to a loss of availability. The issue, first reported on April 9th, was promptly patched by April 11th. The bug had no impact on user funds. Further details can be found in the Root Cause Analysis published shortly after.

Deployment and Execution of SBPFv1, v2 and v3 Programs

The Solana Berkeley Packet Filter (SBPF) is a custom virtual machine designed to efficiently and securely execute Solana programs. It is a Rust-based fork of the extended Berkeley Packet Filter (eBPF), initially built for Linux. 

Upgrades to Solana’s Berkeley Packet Filter (SBPF) are essential to enhance performance, strengthen security, and unlock new capabilities for application developers. Agave 2.2 lays the foundation for long-term maintainability and performance upgrades by introducing a formal versioning system for the SBPF virtual machine, first outlined in SIMD-0161. This change enables the deployment and execution of SBPFv1 (SIMD-0166), SBPFv2 (SIMD-0173, SIMD-0174), and SBPFv3 (SIMD-0178, SIMD-0179, SIMD-0189) programs, establishing a sustainable framework for evolving the program execution environment in stages without requiring network-wide redeployments.

Until now, all SBPF upgrades had to be introduced via global feature gates, making runtime evolution cumbersome and deployment coordination nearly impossible. Versioning solves this by decoupling program behavior from the global runtime and tying it instead to a per-program version tag, encoded in the e_flags field of the Executable and Linkable Format (ELF) file header. This approach enables the following:

Explicit runtime behavior: Each program signals the instruction set architecture (i.e., a SBPF version) it expects. Based on this version, the program's runtime will alter its behavior.

Controlled rollout: Feature gates will independently enable the deployment and execution of new SBPF versions, gradually phasing out older ones over time. Entire sets of changes are bundled into distinct SBPF versions, making upgrades cleaner and easier to manage.

Phased deprecation: Support for older SBPF versions can eventually be dropped once they are deprecated, simplifying virtual machine logic. This deprecation process will be slow, giving developers ample time to migrate or redeploy their programs and adapt to newer versions.

Version discriminator

Currently, the protocol treats any e_flags value other than 0x0020 as SBPF v0, which is valid under the existing system. However, this approach does not scale for supporting multiple SBPF versions and must be updated.

Once the first feature gate enabling a new SBPF version is activated, the protocol will change how it interprets e_flags and will directly map the value to the corresponding SBPF version number. Under this system, 0x0000 will represent SBPF v0, 0x0001 will represent SBPF v1, and so on.

Lift CPI Caller Restriction

The Agave 2.2 release cycle includes a long-anticipated improvement that removes a historical constraint on Cross-Program Invocations (CPI). Currently, any program invoked via CPI must be passed explicitly as an instruction account by the caller. This leads to complex transaction construction and significant compute overhead, especially with deeply nested CPIs. However, this restriction is purely historical and not necessary for the current protocol.

SIMD-0163 lifts this restriction by allowing CPI instructions to reference program accounts directly from the transaction’s top-level account list, rather than requiring those accounts to be passed recursively through every level of invocation. This change provides the following benefits:

• Massively reduces CU usage by avoiding the redundant serialization and deserialization of program accounts (except for loader-v3 programs which store their executable in a separate account), which is particularly costly due to their large size (~10 MB binaries).
• Simplifies transaction construction by eliminating the need to thread callee program accounts through instruction stacks.
• Improves composability, making it easier to build modular and deeply nested program architectures.

Backwards Compatibility

Existing programs remain unaffected unless they want to take advantage of this change. In that case, they can do one of the following:

Programs that have hard-coded the callee statically and only need it as any instruction account to satisfy the constraint imposed by the runtime, can be fed a placeholder like NativeLoader1111111111111111111111111111111, in order not to shift the indices of the other instruction accounts.

All other existing programs, which dynamically call whatever is passed in a specific instruction account, will have to be updated and redeployed to benefit from the lifting of the restriction.

This optimization does not compromise safety. The "delay visibility" feature ensures that programs cannot invoke others that were added, modified, or removed within the same transaction.

Loader-v4

Agave 2.2 introduces support for Loader-v4, a streamlined and more flexible program deployment mechanism designed to replace Loader-v3. Enabled via SIMD-0167, Loader-v4 simplifies program account management, improves upgrade workflows, and introduces critical safety features for live programs, especially those operating in high-stakes environments, such as DeFi.

Key features in Loader-v4:

Single-account model: Loader-v4 eliminates the need for proxy accounts and separate program data buffers. A single account now represents each program.

Maintenance mode: Programs can now be placed in a non-executable "maintenance mode" without being permanently closed or redeployed. This preserves the original program address, allowing developers to pause execution (e.g., in the event of an exploit) without relinquishing the address.

Arbitrary resizing: Loader-v4 supports both growing and shrinking program binaries post-deployment, enabling more flexible resource allocation and reclaiming of locked funds.

Optional buffer usage: Unlike Loader-v3, which always required an external buffer account for redeployments, Loader-v4 makes buffers optional. Programs can now be directly redeployed into the main program account, thus cutting the funds required to be locked during the upload in half.

Partial redeployments: Loader-v3 required full program binaries to be re-uploaded for every upgrade. In contrast, Loader-v4 supports partial uploads, allowing developers to patch only specific sections of a program. This is especially useful for minor updates.

Seamless migration from Loader-v3: Programs deployed with Loader-v3 can be migrated to Loader-v4 without changing their program address. This is facilitated via a new Migrate instruction in Loader-v3. This action will delay visibility, meaning the program will be unavailable for the rest of the current slot.

Following the activation of Loader-v4, a separate feature gate will be triggered to disable new deployments to Loader-v3. Existing Loader-v3 programs will remain functional, but all future deployments are expected to use Loader-v4 going forward.

When finalizing a loader-v4 program, a next-version address can be hinted at, possibly forming a linked list. This enables an alternative to redeploying programs and allows user interfaces to offer users a list of finalized program versions to choose from.

The mechanisms for managing authorities and account closure remain the same in Loader-v4. All of this will be available via the new program-v4 CLI subcommand.

Conclusion

Agave 2.2 represents a significant milestone for the Solana protocol, delivering critical runtime enhancements and new capabilities that expand the network’s technical frontier. This release introduces several key changes: a 20% increase in block capacity, the integration of the Accounts Lattice Hash (ALH) for scalable state hashing, multiple program development upgrades, and support for Secp256r1 signature verification, which is crucial for enabling mainstream cryptographic integrations. Together, these improvements increase throughput, improve developer experience, and enhance the network’s ability to support a broader range of applications.

Whether you're building programs, operating validators, or interacting with the network, Agave 2.2 unlocks greater performance, flexibility, and resilience for Solana.

Further Resources

• Agave Client Repository
• Agave v2.2 Release Schedule
• Agave v2.2 Change Log
• Agave v2.2 Tagged Pull Requests