Solana is emerging as an important entity in the modular landscape. Though it remains a highly integrated and optimised system, Solana’s components are now being recognized for their potential in a variety of modular settings. This influence is extending beyond Solana’s native ecosystem, impacting even the two other major blockchain networks: Ethereum and Bitcoin.

The trend toward modularity began with Ethereum’s rollup-centric roadmap to overcome its scaling limits and has since been embraced by Bitcoin, with new rollups unlocking programmability on it. Solana, with its high-performance architecture, is uniquely positioned not only to capitalise on these opportunities but also to push the boundaries of what’s possible in the modular landscape. In this report, we’ll explore how Solana is contributing to the growing landscape of modular blockchain components, while also developing its internal demand for these solutions through the creation of L2 solutions.

We’ll take a close look at how Solana’s modular approach is expanding its influence across different environments. This expansion doesn’t mean dismantling Solana’s core structure but rather using its powerful components in new, modular ways. We’ll start by examining the SVM, a key piece of Solana’s performance, and how it’s being integrated into different configurations. Next, we’ll explore how Solana’s consensus mechanism is now being used to sequence rollups on other chains, like Ethereum

The report is structured to first explore the SVM and its recent decoupling from validator client—a development that has unlocked new possibilities for modularity. We’ll then discuss the need for L2s on Solana and how SVM-based L2s are being implemented not only within Solana but also on Bitcoin and Ethereum. This discussion will extend to the growing ecosystem of L2s within Solana and how this SVM adoption is reshaping the broader market, strengthening Solana’s strategic position, and influencing its developer community.

Additionally, we touch on the emergence of zk and bridges—vital infrastructure elements that support these L2s. Finally, we’ll explore Solana Permissioned Environments (SPEs) and Solana’s emerging role as a sequencer. This report aims to illuminate this rapidly expanding ecosystem and its supporting infrastructure, highlighting key developments that builders and investors should closely monitor.

Separation of the SVM

The SVM is the execution engine for Solana, including components like the Transaction Processing Unit (TPU), Banking Stage, and Scheduler. Previously, the SVM and Validator Client were closely integrated, which constrained innovation by requiring any changes to consider the entire system as a whole.

Recently, the Anza team separated the SVM and released an SVM API, allowing easier and independent adjustments without affecting the validator functions. Recent developments, however, have kickstarted a new era of modularity and flexibility.

Anza’s successful development of the SVM API is an important development for the ecosystem and SVM. This allows for easier access to and experimentation with the SVM, independent of things like consensus, block time, networking etc. This decoupling opens up several new possibilities which we can expect to see in the upcoming future:

1. Independent Innovation: Teams can now focus on optimizing either the SVM or the validator client without worrying about unintended consequences on the other component.
2. Performance Breakthroughs: Once thought to have reached its peak, execution using the SVM now reveals untapped performance potential, as teams can customise it to meet their specific needs.
3. Ecosystem Diversity: This modularity will likely lead to various SVM variants, each optimized for different applications, leading to a richer and more diverse Solana ecosystem.
4. Standards: Different variants of SVM and fragmentation mean there would be a need for interop standards between them quite different from what we’re currently seeing.
5. Potential bugs: While customizing VMs can provide significant performance and functionality benefits, it also introduces the potential for unique bugs and security vulnerabilities.
6. Rapid Prototyping: The ability to experiment with the SVM independently will accelerate the development and testing of new features and optimizations.

According to Anza Devrel, separation of SVM from the validator client is not the only modularisation of the validator client. There are plans to separate out code for RPCs and the scheduler as well, so there would be an opportunity to have customised components for each use case. Overall, the node is broken down into its component parts, and rollups, appchains and other middleware solutions would be able to customise each piece. This is very early, but we could see custom solutions emerging out of this modularity in the client code.

Do we need L2s on Solana

Rollups and Solana may seem like an unlikely pairing, but they’re already being developed on Solana, Ethereum, and Bitcoin. Let’s examine some of the reasons behind these developments and their potential impact on these ecosystems, their developer base and value capture, etc.

The future of scalability on Solana looks promising with the upcoming Firedancer update, which brings significant improvements. However, there’s a critical question: Is reaching 1 million TPS truly the ultimate goal for Solana’s processing?

To assess whether 1 million TPS is truly necessary, let’s consider the potential user base Solana could support based on current average user activity. If we assume the average user makes around 4,000 interactions per day (things like sending tokens, trading, interacting with social apps, etc.), and there are 86,400 seconds in a day, we can do some quick math. With 1 million TPS, Solana could theoretically handle 86.4 billion interactions per day (1,000,000 TPS x 86,400 seconds/day). Divide that by the average interactions per user, and we get a potential user base of 21.6 million (86.4 billion interactions / 4,000 interactions/user).

Now, 21.6 million users sounds like a lot, and it is. But it’s important to remember that this is a simplified calculation based on several assumptions. Not everyone uses the network evenly throughout the day. We’re bound to see periods of peak demand, like during a major NFT drop or a sudden market swing. That congestion can impact performance and potentially slow things down. Moreover, the 4,000 interactions per user is just an average based on current usage patterns and doesn’t account for emerging catalysts like IoT, AR, AI, and other future technologies with larger digital interaction footprint.
So to answer that question, clearly 1M TPS is not enough.

For more context, let’s compare Solana’s approach with Ethereum’s roadmap, which is centered around rollups. Ethereum’s rollup-centric strategy, including initiatives like Surge and next generation rollups capable of handling 100,000 TPS, shows a different path to scalability. With more than 50 rollups currently live, more than 50 upcoming rollups and L3s on Ethereum, a shift to these high-capacity rollups, or the adoption of MegaETH as new performance benchmark, could potentially scale Ethereum execution to Millions of TPS. This assumes a best case scenario, where each rollup operates at maximum efficiency.

It’s also possible that applications prefer their own dedicated rollups. Whether this preference is demanded by applications, Ethereum’s base layer innovations—such as blobs, PeerDAS, or advancements in recursion—remains uncertain. However, it is possible that Ethereum’s scalability limits might exceed 1 million TPS in the future.

When thinking about web3 scalability, it’s essential to consider a paradigm shift that could exponentially increase computing demand: the rise of autonomous agents. Current AI trends suggest that these agents will drive the next significant transformation, with interactions among them expected to surpass current web2 compute ceilings by several orders of magnitude. To support this shift, we need infrastructure that can handle critical use cases, as centralized AI control poses significant risks. Besides, increasing presence of IoT devices, autonomous vehicles, and other sources will not only add to the demand but also engage in financial activities with each other, further increasing the need for scalable and decentralized infrastructure.

Given this context, the combination of vertical and horizontal scaling isn’t necessarily impractical. Vertical scaling, using Solana’s Firedancer, focuses on improving the performance of a single chain to its maximum potential, aiming for 1 million TPS. However, to meet the future demand driven by autonomous AI agents, which could require several orders of magnitude more in transaction processing capacity, both vertical and horizontal scaling could be a good idea. Horizontal scaling, as seen with Ethereum’s rollup-centric approach, distributes the load across multiple chains. This combined approach could potentially address the massive future demand, pushing the boundaries of what blockchains can achieve. Instead of merely catching up to web2, we should aim to prepare for this impending wave of demand.

On Solana, we’re seeing scaling via rollups which are more app specific, for their high performance needs. It is very hard to justify developing a general purpose L2 on Solana, but control of blockspace, gas, and customisation for next level performance are reasons for which apps are interested in developing their own L2s. This approach is particularly crucial for applications where speed and cost are core to their value proposition and user experience, even if it means compromising on composability. We will explore a few applications that are constructing their own L2s on Solana in lat