The Solana network continues to ship major protocol upgrades as the network scales with growing demand. This page is a technical roadmap of key features planned for upcoming releases. Version numbers and timelines are subject to change as development progresses.
Last updated 3 February 2026
Vote Account V4
STATUS: 🟡 Under development. Expected by Agave 3.1
Vote accounts are how validators participate in Solana's consensus mechanism. Currently, vote accounts use space inefficiently—over 40% of the account stores a history of previous authorized voters that is rarely needed. Vote Account V4 modernizes this structure to be leaner and more flexible.
The upgrade removes unnecessary historical tracking and introduces separate commission settings for different types of validator revenue. This means validators can set one commission rate for inflation rewards and a different rate for block revenue from transaction fees. Vote Account V4 is a foundational requirement for other upcoming features, particularly block revenue distribution to delegators and Alpenglow.
Rent Reduction
STATUS: 🟡 Under development. Expected by Agave 4.0
The Solana protocol requires a rent deposit every time an account is opened. Rent is a misnomer: the deposit is actually a redeemable bond that is recovered whenever the account is closed. The cost of the rent is denoted in lamports per byte. Rent reduction will gradually reduce lamports per byte in a series of feature activations, allowing new Solana accounts to be created at a reduced rent amount. This makes it more affordable for developers to build applications and for users to interact with the network, potentially reducing costs by up to 90%.
Alpenglow
STATUS: 🟡 Under development. Expected by Agave 4.1
Alpenglow is a state-of-the-art consensus protocol that will bring 150ms confirmation times to Solana. Existing protocol features such as Proof of History (PoH) and on-chain vote transactions will be removed to make way for a simpler mechanism in Alpenglow. This represents a fundamental simplification of how the network agrees on blocks, materially improving reliability while sharply reducing confirmation times.
Alpenglow introduces the concept of VAT (Validator Admission Ticket). VAT is a 1.6 SOL fee that validators must pay to be included in the consensus set each epoch. With the introduction of VAT, Alpenglow paves the way for faster block times and increased CU capacity with the removal of vote transactions from blocks.
SIMD-123: Block Revenue Distribution
STATUS: 🟡 Under development. Expected by Agave 4.1
When you delegate SOL to a validator, you currently only receive rewards from inflation in the protocol. But validators also earn revenue from transaction fees, priority fees and MEV (maximal extractable value) when they produce blocks. SIMD-123 enables validators to share this block revenue with their delegators automatically through the protocol.
Validators will be able to set a commission rate for block revenue—similar to how they set commission for inflation rewards. The protocol will automatically calculate and distribute the remaining revenue to delegators at the end of each epoch based on their stake. This creates more transparency and allows delegators to choose validators offering better revenue-sharing terms.
XDP (eXpress Data Path)
STATUS: 🟢 Available in Agave 3.0+
XDP is a high-performance networking technology from the Linux kernel that allows Solana validators to process network packets faster. Think of it as a shortcut that bypasses normal network processing, letting data flow more directly between the network card and validator software. This reduces latency by up to 200x.
Agave version 3.0.9 and later supports XDP for block propagation, but validators must enable the feature. Early testing shows that 100M compute unit blocks are achievable when validator operators adopt XDP. While XDP is not a protocol change, it is a critical performance improvement that will increase network capacity.
100M CUs (Compute Units)
STATUS: 🟡 Under development. Expected by Agave 4.1
Solana's blocks have a capacity limit measured in compute units (CUs). Each transaction consumes some number of CUs depending on how complex it is. The current limit is 60 million CUs per block.
SIMD-286 proposes increasing this limit to 100 million CUs, a 66% boost in capacity. This means more transactions per block, higher throughput, and reduced congestion during peak demand.
SIMD-296: Larger Transaction Size
STATUS: 🟡 Under development. Expected by Agave 4.1
Transactions on the Solana network are currently limited to a maximum of 1,232 bytes. This limitation restricts the ability for programs to compose with each other, as transactions have a specific amount of data to fit. Larger transactions enable more complex operations in a single transaction, reducing the need for awkward multi-step execution patterns.
Core engineers have accepted SIMD-296 to enable more expressive transactions that can interact with more programs and accounts in a single atomic operation.
SIMD-268: Raise CPI Nesting Limit
STATUS: 🟡 Under development. Expected by Agave 4.1
Cross-Program Invocation (CPI) is how Solana programs call into other programs during execution. The current maximum nesting depth is 4 levels, meaning a program can call another program, which calls another, up to 4 deep. This limits the sophistication of multi-program interactions.
SIMD-268 increases the nesting limit from 4 to 8, doubling the depth of program-to-program calls. This enables developers to build more complex decentralized applications that compose multiple protocols together.