Anza Block: Alexander Meißner

Solana developers are getting some serious quality-of-life improvements. At Breakpoint 2025, Alexander Meißner from Anza's SVM team unveiled a roadmap of changes that will dramatically expand what's possible on Solana—including doubling CPI nesting depth, eliminating account resizing limits, and finally enabling developers to completely delete program accounts and reclaim their addresses.

Summary

Top Projects

Lulo

Score: 7,586.13

Bonk

Score: 4,806.12

Sphere

Score: 2,544.42

Moonwalk

Score: 2,026.11

The Solana Virtual Machine (SVM) team at Anza is focused on three core objectives: improving throughput and bandwidth, reducing protocol complexity to help other validator implementations like Firedancer catch up, and enhancing developer usability. While these improvements promise significant gains, they come with mandatory changes that all programs—including already deployed ones—will need to address.

The most immediate action item for developers is testing their programs against new restrictions being introduced. Several programs have already been identified as potentially affected, and while they won't break entirely, some instructions will fail without updates. The fixes are straightforward, but testing is essential before these changes go live.

Looking further ahead, Anza is preparing ABIV2 (Application Binary Interface version 2), a significant overhaul that will expose transaction information more efficiently, allow unlimited account resizing, and dramatically simplify Cross-Program Invocation (CPI) calls. Additionally, SBPF V3 will enable smaller compiled programs with just a recompile—no source code changes required.

Perhaps most exciting for long-time Solana developers is the upcoming ability to completely close and delete program accounts, reclaiming both the address and all associated funds. This addresses a long-standing limitation that has frustrated developers for years.

Key Points:

Mandatory Program Restrictions and Testing Requirements

Anza is introducing new mandatory restrictions that will apply to all programs on Solana, including those already deployed. These restrictions shouldn't affect programs following best practices, but historical SDK patterns have led some programs to include problematic code. Developers will encounter three specific error messages if their programs violate these new rules.

The SVM team has already identified specific programs that will be affected. If your program appears on their list, it means some instructions will fail once these changes activate. The fixes are described as "pretty simple," but developers must proactively test with the latest toolchain to identify issues before they impact users on mainnet.

ABIV2: A New Application Binary Interface

ABIV2 represents a substantial upgrade to how programs interact with the Solana runtime. The new interface will expose most transaction information essentially for free, including signatures and all program-derived addresses (PDAs) in the transaction. This change requires developers to make adjustments through syscalls rather than the current patterns.

The benefits are substantial: account resizing will become essentially unrestricted, eliminating the current 10-kilobyte limit that has constrained many applications. Entry points will become significantly cheaper, CPI calls will be both cheaper and simpler, and the current AccountInfo, Pubkey, and AccountMeta structures will be replaced with simpler index-based approaches.

SBPF V3: Smaller Programs, More Toolchain Options

SBPF (Solana Berkeley Packet Filter) V3 will bring program size reductions with minimal developer effort. The change requires only recompiling programs with the latest toolchain—no source code modifications are necessary. This is a straightforward "recompile and deploy" upgrade.

Beyond size improvements, SBPF V3 aligns Solana more closely with upstream BPF tooling, opening the door to using different toolchains and compiler options. This standardization should make development more accessible and enable the ecosystem to benefit from improvements in the broader BPF community.

Loader V4: Overhauled Program Management

A complete overhaul of Solana's upgradeable loader is underway, codenamed "Loader V4." This affects both the internal account layout—necessary for performance improvements in the load path—and the specific actions available through the loader. Whether this will involve an actual change to the program owner field remains undetermined.

The upgrade will be opt-in initially before becoming mandatory later. The headline feature for developers: the ability to completely close and reclaim program accounts, including recovering the address itself and all associated rent funds. Existing workflows like buffer-based redeployment will continue functioning as expected.

Expanded CPI Limits

Two significant limit increases are coming that will unlock new application architectures. The CPI nesting depth is increasing from 4 to 8, allowing for more complex program compositions and deeper call stacks. Even more dramatically, the number of instruction accounts in CPI calls is jumping from 64 to 255.

This 255-account limit means a CPI call can now reference all accounts in an entire transaction simultaneously. This removes a significant constraint that has forced developers to create workarounds and split operations across multiple transactions.

Debugging and Developer Tooling Improvements

Responding to increased community interest, Anza has been working with partners to improve debugging and code coverage tooling. A particularly notable advancement is enabling debuggers to trace through CPI calls across the entire transaction stack—a capability that will make tracking down bugs in complex multi-program transactions much more practical.

A smaller but welcome ergonomic improvement addresses instruction parsing: the instruction data pointer is now passed as an argument, allowing programs to first discriminate the instruction type before parsing accounts. This lets programs skip account parsing entirely for unsupported instructions, reducing unnecessary computation.

Future Roadmap: Built-in Program Migration

Anza continues working toward migrating all built-in programs to on-chain BPF core programs. This includes the loaders themselves, native programs, and the zk-proof program. The team is also exploring different instruction set architectures (ISAs), additional compiler options, and complex performance optimizations.

Facts + Figures

• CPI nesting depth is increasing from 4 to 8 levels
• CPI instruction accounts limit is jumping from 64 to 255 accounts
• The 10-kilobyte account resizing limit will be eliminated with ABIV2
• SBPF V3 requires only a recompile with no source code changes
• Program accounts will become fully deletable, with address reclamation
• All transaction signatures and PDAs will be accessible essentially for free
• Loader V4 will be opt-in initially, then become mandatory
• The changes will apply to all programs, including already deployed ones
• Three specific error messages will indicate programs need updates
• AccountInfo, Pubkey, and AccountMeta will be replaced by index-based approaches in ABIV2
• Debuggers will soon be able to trace through CPI calls across entire transaction stacks

Top quotes

• "All medicine has side effects. And there are things we need to do, and specifically also you need to do, so that we can unlock the performance gains and the robustness gains we want to have on our chain."

• "You will be able to completely close and reclaim program accounts, including the address and reclaiming all funds—like entirely deleting the account."

• "You gain basically unrestricted resizing of accounts, no more limits in terms of 10 kilobytes."

• "We will be able to raise the number of instruction accounts in CPI from 64 to 255, which means you can CPI all accounts simultaneously of the entire transaction at once."

• "If all of you have anything that has always been on your mind, like 'this is the feature I need in the SVM and I have been dreaming of this all my life,' then please come to us."

Questions Answered

What changes do I need to make to my existing Solana programs?

For the immediate mandatory restrictions being introduced, you need to test your programs with the latest toolchain to identify any issues. If your program triggers one of the three new error messages, fixes are required but described as straightforward. For ABIV2, you'll need to adjust parts of your program to work through syscalls instead of current patterns. For SBPF V3, only a recompile is needed with no source code modifications. Testing now is crucial to avoid unexpected failures when these changes go live on mainnet.

Will I finally be able to delete my program accounts and get my SOL back?

Yes, this highly requested feature is coming with the Loader V4 update. You will be able to completely close and reclaim program accounts, including recovering the address itself and all associated rent funds. The account will be entirely deleted from the blockchain. This addresses a long-standing frustration where developers had abandoned program addresses but couldn't reclaim the locked funds.

How do the increased CPI limits help my application?

The doubled CPI nesting depth (4 to 8) allows more complex program compositions without hitting depth limits. This is particularly valuable for protocols built on composable building blocks. The dramatically increased instruction accounts limit (64 to 255) means a single CPI call can now reference every account in a transaction simultaneously. This eliminates workarounds where developers previously had to split operations or carefully manage which accounts were passed to which calls.

What's happening with account resizing limits?

Currently, accounts can only be resized by 10 kilobytes per instruction. With ABIV2, this restriction is being eliminated, allowing essentially unrestricted account resizing. This unlocks applications that need to grow data structures dynamically without complex multi-instruction workarounds or account migration patterns.

Do these changes affect Firedancer and other validator implementations?

Yes, reducing protocol complexity is explicitly mentioned as a goal to help other validator implementations like Firedancer catch up with the reference implementation. Simpler protocols mean less surface area for implementation differences and bugs, benefiting the entire ecosystem's reliability and multi-client future.

When will these changes go live?

The presentation covers changes expected over "roughly half a year." Mandatory restrictions are coming first and will affect all programs, so testing now is essential. ABIV2 and SBPF V3 follow, with Loader V4 starting as opt-in before becoming mandatory. Developers should monitor Anza's communications for specific activation dates.