Agave 3.0 Update: All You Need to Know

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

Introduction

The Agave v3.0 major release marks another milestone for Solana, introducing a range of upgrades aimed at improving network performance, validator operations, and the developer experience.

Notable Agave 3.0 Updates 

• Cache Overhaul: delivering 30–40% faster transaction processing
• Higher Single-Account Compute Limit: raises the single account limit to 40% of a block’s CUs
• New Scheduler TransactionView Struct: improving scheduling efficiency
• eXpress Data Path (XDP) for Turbine: a prerequisite for 100 million CU blocks
• Increased CPI Nesting Depth: raises the CPI nesting limit from 4 to 8
• Relax Entry Constraints: simplifies scheduling logic and is necessary for async execution
• Faster Startup Times: nodes now come back online faster
• Loaded Transaction Data Size Specification: standardizes how loaded transaction data is calculated
• RPC Improvements: faster, more reliable real-time updates for dApps using PubSub WebSockets

Each section of this article is self-contained, allowing readers to focus on the topics most relevant to them. Whether you’re a validator operator, developer, or active community member, this guide to Agave v3.0 offers you the key updates and insights needed to make the most of the latest improvements.

Client-Related Trends

Before exploring the details of Agave v3.0’s new features, let’s look at how recent data highlights the progress made by the Solana network and the Agave client, showcasing faster release cycles, broader client adoption, and robust performance under pressure.

Agave Release Cadence

Anza has notably accelerated its release cadence this year, reducing the gap between minor Agave versions to under three months. The Agave 2.2.* series remained the supermajority version for only 11 weeks, with Agave 2.3 tracking a similar timeline.

Multi-Client Network

Firedancer adoption on mainnet has advanced significantly in recent months. Currently, 21.6% of stake is running the Jito-Frankendancer client, a figure that has grown slowly and steadily throughout the year (see chart below). Adoption is expected to remain around the 20% threshold until the full Firedancer client is production-ready for mainnet deployment.

This marks a significant milestone for Solana’s multi-client strategy, a long-standing goal aimed at improving network safety, liveness, and resilience. Increased client diversity offers greater choice to validator operators, fosters healthy competition among client teams, and brings more eyes to the client codebases. It also mitigates the risk of a single critical bug triggering a network-wide outage.

It’s also notable that stake running the vanilla Agave client, meaning Agave without third-party MEV modifications such as Jito, has declined from around 6% at the start of the year to roughly 2% today. Meanwhile, adoption of Paladin-Agave has risen in recent months, now accounting for about 6% of total stake.

Network Stress Test

On October 10th, the crypto market experienced the largest liquidation event in its history, triggering extreme volatility across all major blockchains. Despite the record-breaking surge in network activity, the Solana network and the Agave validator client demonstrated remarkable resilience and stability under pressure.

During the peak, Solana sustained six times its normal traffic levels with leaders ingesting around 100,000 transaction packets per second, while producing full blocks at the 60 million CU limit.

Even under these conditions, Solana exhibited the most stable fee dynamics of any major network while processing an order of magnitude higher throughput. True TPS (non-vote transactions) exceeded 3,200 at the height of activity.

Over the roughly two-hour peak window, Solana’s median (P50) transaction fee rose only to $0.007, less than one cent. Average fees briefly reached $0.10, and the top 1% of transactions (P99) peaked just above $1.00. This pattern demonstrates the effectiveness of local fee markets, which confined high fees to only those transactions interacting with contested hot accounts, while ordinary users performing simple transfers (e.g., stablecoin payments) were unaffected.

For comparison, Ethereum mainnet and Arbitrum saw median fees briefly spike above $100 per transaction during the same period. Coinbase-operated L2 Base also experienced fee surges with median fees peaking at over $3. These networks lack local fee markets, applying global fee adjustments that uniformly raise costs for all users during network stress.

State Growth

Solana recently crossed a major milestone in on-chain state growth, surpassing 1 billion total accounts. Nearly 67% of these accounts are owned by the Token Program, of which 89.45% are associated token accounts and 10.55% token mint accounts.

This steady expansion of state has longer-term implications for Solana clients and infrastructure providers. As the number of accounts grows, so does the demand on storage, snapshot size, and account indexing, all of which can impact performance and hardware requirements. Solutions such as ZK Compression offer a promising long-term path forward for reducing state bloat.

Agave 3.0 Release Cycle Updates

Cache Overhaul

Agave 3.0 significantly reduces redundant runtime operations. A complete overhaul of the program cache eliminates hundreds of superfluous account lookups per transaction batch, resulting in approximately 30–40% faster transaction processing in internal benchmarks.

Increase Account Limit to 40% of Block CU

As part of the Agave 3.0 release cycle, Solana will activate SIMD-0306: Raise Account CU Limits. This increases the per-account CU limit from a static fixed constant of 12M to 40% of the block CU limit. Currently, each account can consume up to 12 million CUs per block. As shown in the chart below from Anza, the most heavily contested accounts often hit this ceiling.

With this change, the per-account limit will initially rise from 12 million to 24 million CUs, and eventually to 40 million CUs once SIMD-0286 (100M CU blocks) is activated. Combined with updates like the introduction of the P-token program, this upgrade will significantly increase throughput for hot accounts that are frequently accessed within each block.

Other constraints will remain unchanged, including:

• Max Vote Units: the cap on total vote transaction CUs per block, at 36 million CUs
• Max Block Accounts Data Size Delta: the limit on total account data changes per block, at 100 megabytes.

While raising the per-account CU cap improves throughput for hot state, it may also increase the worst-case serialized execution time, potentially lengthening block verification or slot duration in high-load scenarios.

Finally, it’s worth noting the recent proposal SIMD-0370: Remove Compute Unit Block Limit, which explores eliminating CU-based block limits entirely, a direction that will likely be revisited after the Alpenglow upgrade.

eXpress Data Path (XDP) for Turbine

eXpress Data Path (XDP) is a Linux kernel technology designed for high-performance networking. It enables applications to bypass much of the kernel’s standard packet processing path, reducing both intermediate data copies and context switches between user and kernel space. By handling packets directly with the network interface card (NIC) in user space, XDP dramatically cuts per-packet overhead.

Support for XDP in Turbine was first introduced in Agave v2.3.8 and will be enabled by default starting with Agave 3.1. Turbine is the main scalability bottleneck as block limits increase to 100M CUs. Leaders relay their shreds to 200 peers, generating heavy network load. Large validators with more leader slots can approach 150,000 outbound packets per second under current conditions. XDP directly addresses this bottleneck, making packet dispatch up to 100 times faster, allowing validators to propagate larger blocks far more efficiently. 

Readers interested in a deeper look at XDP implementation in Agave can refer to the validator setup guide and our earlier interview with Anza engineer Alessandro Decina, who led the integration of XDP into the Agave client.

Loaded Transaction Data Size Specification

As part of ongoing efforts to simplify and standardize Solana’s execution model, SIMD-0186: Loaded Transaction Data Size Specification, is set to activate on mainnet during the Agave 3.0 release cycle.

This introduces a consensus-safe method for calculating the total account data loaded by each transaction. The goal is to ensure that all validator clients compute identical transaction data sizes, eliminating subtle inconsistencies that could otherwise cause consensus to diverge.

Currently, Solana’s transaction data sizing logic is overly complex. The existing implementation is idiosyncratic in how it handles LoaderV3 and BPF Upgradeable Loader programs, both of which frequently undercount the actual size of loaded program data. These discrepancies made it difficult for independent client teams to implement compatible logic.

Under SIMD-0186, the sizing rules are now explicit and easy to reason about:

• Each loaded account is counted exactly once
• Programs using the BPF Upgradeable Loader include their associated program data
• Each loaded account's size is defined as the byte length of its data before transaction execution, with an added 64 bytes for metadata
• Address Lookup Tables (ALTs) add a flat 8,248 bytes each

This specification standardizes transaction sizing across all clients and makes transaction behavior more predictable for developers.

The loaded data size limit serves a similar role to the per-transaction CU limit, providing predictable resource accounting for validator nodes. By default, each transaction can load up to 64MB of account data, consuming eight compute units (CUs) per 32KB loaded, equivalent to a base cost of 16,000 CUs, even if less data is actually loaded. Developers can lower this limit via the setLoadedAccountsDataSizeLimit instruction to reduce compute cost and improve scheduling efficiency.

Since the new sizing method can produce varying values based on the transaction structure, developers may need to adjust the loaded account data size limit specified in their compute budget instructions.

Scheduler TransactionView Struct

With Agave 3.0, the scheduler introduces a new lightweight data structure called TransactionView, designed to streamline how transactions are parsed and processed. Unlike the older SDK transaction types, which required deserialization and multiple memory allocations, TransactionView provides a direct view into a serialized transaction. It parses and caches metadata about the transaction layout without actually deserializing it.

Faster Startup Times

Client startup performance continues to improve with the Agave v3.0 release, marking a notable quality-of-life upgrade for validator and RPC operators. Whether restarting after a crash, upgrade, or scheduled maintenance, nodes can now come back online significantly faster.

Starting from a snapshot archive, startup times have been reduced to under three and a half minutes, less than half the duration required under Agave v2.2 (see chart below). This improvement represents a critical performance gain, as faster startup directly enhances network resilience and validator uptime by reducing the time it takes for nodes to rejoin consensus.

Looking ahead, Agave v3.1 will streamline this process further by eliminating background account verification, enabling validators to start voting immediately after replay begins.

Raise CPI Nesting Limit

SIMD-0268: Raise CPI Nesting Limit increases the maximum depth of Cross-Program Invocation (CPI) calls from 4 to 8. This effectively doubles the number of times a Solana program can invoke other programs within a single transaction.

CPI is the mechanism by which one Solana program calls another. It’s a foundational feature of Solana’s runtime that allows programs to build on one another’s logic.

Complex on-chain protocols such as perpetual swaps, smart wallets, and cross-margin systems often rely on multiple layers of program interactions to manage positions, liquidations, and risk. The previous 4-level CPI limit constrained these designs, in some cases forcing developers to split logic across multiple transactions.

Existing applications will continue to function as before (unless they depend on the old limit in their logic to fail transactions). Overall, this frequently requested change broadens the design space for developers and strengthens Solana’s composability.

Relax Entry Constraints

SIMD-0083: Relax Entry Constraints, set for activation during Agave 3.0, removes the rule that transactions within a block entry must not conflict with each other. Previously, any entry containing conflicting transactions (i.e., those that both write to the same account or where one reads while another writes) would invalidate the entire block.

With this update, such conflicts are now permitted. When they occur, the transactions are simply executed sequentially in the order they appear. This change simplifies block packing rules, giving leaders greater flexibility in transaction ordering and block construction. It is also a necessary change for Solana to implement asynchronous execution.

RPC Improvements

Agave v3.0 introduces responsiveness upgrades to the subscription server, which now prioritizes incoming messages, such as subscription requests and PINGs, over outgoing notifications. This change delivers faster, more reliable real-time updates for dApps using PubSub WebSockets.

Additionally, slot properties have been added to epoch rewards error data, improving debugging and observability for developers.

Other Changes

• Starting with Agave v3.0.0, Anza has discontinued publishing prebuilt agave-validator binaries. Validator operators must now compile the binaries from source by following the build instructions provided.
• With Agave v3.0, the default snapshot interval has been extended to every 100,000 slots, up from 50,000 in v2.3 and 25,000 in v2.2. Increasing the interval significantly improves disk performance, reducing spikes in IOPS (input/output operations per second) during snapshot creation.
• Numerous deprecated old CLI arguments and flags have been removed (full list here).
• Currently, an advance nonce instruction in a transaction can specify any account in the transaction as the account to advance. Following the feature gate activation for SIMD-0242: Static Nonce Account Only, this will restrict the advance nonce instruction to only be able to advance a statically included account.

Conclusion

Agave v3.0 is a substantial client upgrade, introducing faster transaction processing, higher compute limits, improved scheduler efficiency, and a range of validator and RPC optimizations. Together, these updates strengthen both network performance and developer experience.

Recent data further reinforces this progress: quicker release cadences, growing client diversity, and exceptional network stability under peak demand all highlight Solana’s maturation. With Agave 3.0 now powering the network, Solana continues to prove its ability to scale.

Further Resources

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