Hiroki Kotabe
Over 100 subscribers
Thank you to Yiwen, Joanna, Andrea, Chris, Kristian, and Michael for the feedback and review.
While Solana L1 offers high throughput and low latency, emerging congestion and niche use-case demands have driven development of specialized execution environments or “network extensions” over its base layer (broadly grouped as “Solana L2s” in this report). Solana L2s aim to future-proof Solana’s adoption by providing dedicated execution environments for demanding applications without burdening the main chain. In essence, Solana L2s extend Solana’s performance envelope by offering modular “plug-and-play” scaling: they leverage Solana’s core strengths (speed, parallel execution) while customizing parameters like block time and fee markets to specific needs. Although this approach marks a departure from Solana’s monolithic design strategy, it aligns with Solana’s general mission to “increase bandwidth, reduce latency.”
By separating the execution layer as a customizable module, Solana can maintain a robust base layer while specialized L2s handle certain application-specific demands on top that the base layer is not suited for. This approach aligns with industry trends: Ethereum’s rollup-centric roadmap and even Bitcoin’s L2 strategy also demonstrate a move toward modular over monolithic architecture as single blockchains struggle to scale for high-throughput, low-latency applications. Performance remains at the center for Solana’s strategy – even as Firedancer (a new high-performance validator client developed by Jump Crypto) aims for vertical scaling to 1M TPS, Solana’s L2s provide horizontal scaling by adding more execution capacity in parallel. This approach aims to prepare the network to meet future demand from heavy-throughput use cases like real-time DeFi, DePIN, gaming, microtransactions, and more.
Designing Solana L2s involves several architectural decisions (e.g., SVM or VM-less execution, co-located validators, parallel processing) each presenting distinct benefits, tradeoffs, and suitability for specific use cases. Here, I focus on a selection of Solana L2s exemplifying the breadth of designs being implemented across a variety of use cases.
One of the major enablers for Solana L2s is the decoupling of the SVM (Solana’s runtime) from the core validator client, which enables modularity comparable to Ethereum’s L2s. Previously, the SVM and validator client were tightly coupled, which restricted innovation as modifications had to be evaluated within the context of the entire system. Now, with Anza’s SVM API, the SVM can be defined as a separate execution layer like the EVM.
This is useful for rollups that want to execute blocks with the SVM but don’t need the other components of the validator (consensus, block time, networking, etc.). Developers can now reuse Solana’s fast execution engine in new contexts without altering or introducing risks to the Solana mainnet. They can experiment widely, for instance, by custom-tailoring block times, fee mechanisms, state management, security models, and more. This opens the doors to a wide variety of SVM rollups fine-tuned for different applications, settling to any chain. In effect, the decoupling of SVM solves the problem of Solana lacking an abundance mindset, allowing developers to enter the Solana ecosystem and build whatever customizations they want.
Alternatively, Solana L2s may opt for a VM-less sovereign design that eliminates emulation overhead entirely. In this configuration, execution logic and settlement are implemented natively, which minimizes latency – making it particularly well-suited for high-frequency trading (HFT) applications – but at the cost of general-purpose smart contract functionality and broad third-party dapp support. Overall, this modularity – whether through SVM decoupling or VM-less design – embodies Solana’s strategy for future proofing its network by leveraging horizontal scalability and full-stack customizability.
Most Solana L2s are focused on ultra-fast execution, aiming for web2-like performance over peer-to-peer networks. Several adopt a streaming model instead of waiting for the next block boundary – removing the overhead of block formation and incurring no delay between transaction creation and confirmation. For example, Bullet uses a custom sequencer that confirms each transaction individually, enabling soft confirmations in real time.
This design has already achieved sub-50ms end-to-end latency and is targeting <5ms – faster than even the top CEXs. Techniques include removing block batching delays, running a streaming sequencer that processes txs immediately, and eliminating unnecessary VM overhead. By delivering latencies on the order of milliseconds, such designs promise a user experience on par with high-performance web apps, which is a requirement for professional trading and other fast-paced applications.
To reach these speeds, Solana L2s often sacrifice some composability with the main Solana ecosystem. Instead of a general-purpose L2 that supports every dapp, many Solana rollups are application-specific – they dedicate the entire chain to one app or use-case, trading breadth for performance. This isolation means an L2 can customize resource allocation (compute, memory) and scheduling precisely for its app’s workload. The downside is liquidity and user fragmentation: by moving an app off L1, the L2 loses atomic composability with L1 dapps (e.g., cannot borrow funds from an L1 lending protocol and execute a trade on an L2 DEX in the same transaction; requires bridging).
Thus, the decision is a careful balance – dedicated blockspace and custom optimizations for one app vs. the composability and user base of Solana L1. Builders must ask themselves whether the raw performance gains justify breaking composability. To address this, teams are exploring hybrid solutions: MagicBlock’s ephemeral rollups spin up parallel SVM instances tied to L1 accounts – targeting ~1ms execution without a full chain split – while Termina’s network extension platform offers customizable SVM instances that read and write directly to the shared global state without bridging via a novel zkSVM implementation. These hybrid models demonstrate that you can locally capture ultra-low latency and custom execution while minimizing fragmentation with the base chain.
Every rollup must decide where to store its transaction data and ordering information so others can reconstruct its state. Solana L2s use varied DA approaches. Some use Solana L1 for DA, publishing rollup tx batches as opaque blobs in Solana transactions. Bullet follows this model, packing batches of Zeta’s L2 transactions into Solana and storing a hash (state root) of those txs on-chain in single-round zk fraud proofs (later zkVM when feasible). This ensures data is secured by Solana’s 1,000+ validators, but it’s constrained by Solana’s tx size limit (~1.2KB per TX) and could add load to the main chain. That said, this may turn out to be a non-issue as Firedancer promises a tenfold increase over Solana’s current data throughput.
Other projects execute in SVM environments and offload DA to specialized DA layers: Eclipse opts for Celestia as its DA layer and SOON is currently using EigenDA and later will be configurable to use Celestia or Avail. Using purpose-built DA networks can avoid clogging Solana and benefit from specialized scaling DA scaling properties like Celestia’s data availability sampling and blobstream. This can be a useful design choice when building on non-Solana settlement layers like Ethereum with restrictive data throughput limits, enabling Solana devs to deploy high-performance SVM-based dapps in non-Solana ecosystems. However, it does introduce additional trust assumptions at each layer of the stack, as the security and data integrity of the system now depend on both the DA provider and the settlement network.
The variety of DA solutions reflects the expansiveness of Solana’s modular direction: The decoupling of the SVM enables these L2s to not only use Solana L1 for DA but also Celestia, EigenDA, or any other DA protocol, balancing tradeoffs between trust-minimization vs. costs vs. data throughput.
Many early Solana rollups adopt optimistic inclusion plus validity proofs for challenges as mentioned above – this is what is feasible given the current state of zk proving costs and speed. This hybrid approach means the L2 can publish blocks quickly without proving each one, but when a malicious state transition does occur, anyone can submit a zk proof to slash the sequencer and correct the state. The benefit is much faster dispute resolution than traditional interactive proving that can take days – Bullet expects bridging in time into the rollup within seconds (depending on the chosen confirmation level of Solana L1), and a bridging out time that will take ~12 hours (adjustable by risk tolerance). Eventually, as zk proving costs become cheaper and faster (e.g., via Aligned Layer, Succinct), these rollups can transition to a full-blown zk-rollup, where every L2 block is proven with a zk proof and exit times reduce to minutes.
Aside from cryptographic proofs, Solana L2s can also opt to use economic incentives for security. Solana L1 has notably never enabled slashing (though that may be changing soon), but Solana L2s can flexibly turn on staking and slashing for misbehavior or censorship. For instance, a sequencer may be slashed if it fails to include transactions within a short window, enforcing credible neutrality through incentive alignment. In summary, validity proofs and economic stake work in tandem to secure Solana L2s, with a long-term view of minimizing trust assumptions and maximizing censorship resistance.
Most Solana L2 initiatives position as app-specific – tailored to one application or a narrow use case – rather than general L2s hosting many third-party dapps. This contrasts with Ethereum L2s (Base, Optimism, Arbitrum, etc.) which aim to be general-purpose platforms. Solana L2s likely gravitated towards app-specific rollups because:
Solana L1 is already useful for most use cases. Therefore, the marginal gain of a general L2 on Solana is small; but certain apps can achieve order-of-magnitude improvement on a custom L2.
Developers want customization. App-specific chains allow maximal customization – something that developers desire and certain use cases require.
On maximal customization, Termina stands out as a versatile SVM rollup and network extension platform. Rather than being a single L2, Termina is a Solana-centric SDK and framework for building highly customizable SVM rollups and network extensions – supporting both general-purpose and app-specific deployments. Developers can configure Termina to support a wide range of needs, leveraging its SVM Engine, zkSVM module, and Data Module together or individually to create tailored execution environments. This broad configurability positions Termina as an “AWS for SVM chains,” enabling rapid experimentation and deployment of SVM-based rollups or extensions, whether tightly integrated with Solana or operating as sovereign appchains
On the other hand, a few general-purpose SVM rollups focus less on raw performance maximization and more on ecosystem expansion. Eclipse on Ethereum is one example, offering an Ethereum-based L2 where any SVM program can be deployed. Eclipse’s generality targets attracting Solana/Rust devs to Ethereum while avoiding the EVM’s performance limits. SOON is also a general-purpose SVM rollup, currently deployed on Ethereum but designed to expand to any L1. Overall, Solana’s L2 landscape is evolving into a spectrum: at one end, sovereign appchains deliver specialized, maximally performant environments; at the other, general-purpose SVM rollups prioritize interoperability and ecosystem expansion.
There is ongoing debate about the need for L2s on Solana, given its vertical scaling roadmap minimizes L2 incentives for most use cases. While modularity offers horizontal scaling and more flexibility, tradeoffs include sacrificing L1 composability, added complexity from fraud proofs, and security risks from L2 upgrade multisigs. That said, niche applications may justify L2 adoption by prioritizing specialized performance, modularity, or regulatory compliance over atomic composability with the base layer.
One of the major draws driving development of Solana L2s is their capacity to support HFT and advanced trading programs. Zeta Markets, a leading Solana derivatives exchange, has designed Bullet from the ground up to achieve CEX-like speed on a DEX. On Solana L1, even under ideal conditions, order placement incurs a ~400ms latency block time for initial processing and up to 1-3 seconds for finality. In contrast, CEXs like Binance operate at sub-10ms latency – a gap that puts onchain trading at a disadvantage for market makers and HFTs. Bullet’s rollup architecture aims to achieve <5ms latency end-to-end by using a VM-less streaming sequencer (co-developed with Sovereign Labs) and co-locating validators near users. Importantly, Bullet uses Solana L1 for settlement and security: txs execute instantly on the L2, but final trades settle in batches on Solana. By leveraging Solana’s high-performance base for settlement and DA, Bullet can offer traders an experience rivaling CEXs while preserving onchain security and transparency. The market opportunity in HFT-focused L2s is huge: if Bullet succeeds, it could capture substantial volumes (Zeta has already done over $12B in volume on Solana) L1 and even expand to host other fast trading apps. As a comparison, Hyperliquid achieves a ~200ms end-to-end latency and achieved over $27B in volume within months, suggesting strong PMF potential for ultra-fast DEXs.
Other relevant projects: Flash Trade on MagicBlock
Sonic and MagicBlock are leveraging Solana L2 designs to meet the demands of modern games. Sonic is a gaming-optimized rollup built on the Hypergrid framework, which scales horizontally by adding parallel SVM-enabled shards. Each “grid” in Hypergrid aims to handle throughput comparable to Solana L1, and multiple grids can run in parallel for horizontal scalability. It is a full L2 solution in that state changes are handled on the L2 and settled to L1 periodically or on an as-needed basis. Sonic focuses on making life easy for game developers: it provides specialized APIs, smart contract templates for common game logic, and debugging tools in a Solana-friendly developer environment.
In contrast, Magicblock takes a novel approach by using “ephemeral rollups” (a configurable dedicated SVM instance) to achieve extremely low latency for games. MagicBlock’s architecture co-locates bare-metal validator nodes geographically near users and delegates game transactions on an as-needed basis to mini-rollups that run very fast and temporary execution environments. A Solana mainnet program locks relevant game accounts and hands off their state to these ephemeral rollups, which can then process actions in milliseconds by skipping normal consensus and networking overhead. The state changes are later settled back on L1 via fraud proofs by a security committee. Importantly, ephemeral are optional – they can be invoked via smart contract on Solana L1 only when faster transaction processing is needed. This hybrid L1-L2 model retains full composability (atomic bundles of txs between ephemeral rollups and Solana L1 are possible) – the state (e.g., game’s assets) is still on Solana when the rollup isn’t running.
DePIN—and, by extension, IoT—represents a class of applications where the scale and complexity of data processing far exceed the capabilities of any single state machine, making them natural candidates for L2 architectures. This is especially apparent in the context of AI and big data, where trust in data provenance and verifiable computation are important. Grass is a good example of how blockchains can be useful here: as a DePIN protocol, it orchestrates a global network of everyday devices to scrape web data for AI training, anticipating tens of millions of web requests per minute – volumes that would overwhelm any L1 blockchain, including Solana. To address this, Grass has designed a lightweight “sovereign data rollup.”
Instead of putting entire datasets onchain, Grass adds metadata about each data batch – source, timestamps, processing steps – and the rollup generates succinct proofs of provenance and authenticity for these batches. These proofs are settled on Solana L1, providing an immutable audit trail that the dataset came from the correct source and hasn’t been tampered with.
Essentially, Grass uses an L2 as a verifiable coprocessor for offchain data collection and processing, showcasing a unique modular use case of a Solana L2. It highlights how Solana L2s can be applied to serve specific functions that are not feasible on the L1 (e.g., massive data batching and proving; selective privacy), in a non-financial domain (AI data pipelines). For other DePIN protocols handling enormous volumes of requests, we may see other such data verification L2s emerge.
Other relevant projects: Termina’s Data Module
Large enterprises and institutions often require features like privacy, compliance, or guaranteed throughput that public blockchains struggle to provide. Solana’s answer to this is Solana Permissioned Environments (SPEs) – isolated, specialized runtime environments built directly on Solana L1. This means SPEs are not sidechains or L2s in the traditional sense but are effectively isolated instances of Solana tech in a walled-garden mode for institutions. This gives institutions control over their validator set, chain functionality, and gas token usage.
Rimark and Iron (recently acquired by Moonpay) are early examples exploring SPEs to extend Solana for regulated contexts. As SPEs are built on L1, they can maintain composability with Solana’s mainnet for value transfer, but can add layers like token extensions and confidential transactions through FHE (like Iron is doing) or identity controls on top. An SPE might be an app-specific chain where a bank or fintech runs a marketplace with Solana’s performance, yet only whitelisted participants can transaction – combining compliance with Solana’s performant base layer. SPEs are an intriguing market opportunity – they are still early, but they are starting to position Solana to capture institutional activity that might not happen on open L1s, potentially bringing new types of revenue and enterprise partnerships. As regulatory clarity improves, SPEs could tap into significant demand (imagine institutional stable networks or Nasdaq as SPEs).
Solana’s rise to a peak market capitalization north of $120 billion stemmed not only from market dynamics and technical features but also from the commitment and cohesion of its developer and user communities – it was the people behind it who made the real difference. Early contributors – ranging from protocol architects and validator operator to ecosystem builders – played a central role in shaping the network’s capabilities and resilience, particularly during challenging moments like the FTX collapse. Simply labeling a project as a “Solana L2” does not guarantee a repeat of that success. Understanding the underlying factors – community engagement, effective governance, and developer support – is what really matters.
Solana’s early developers and their collaborators prioritized throughput and latency improvements from day one, refining network parameters and tooling to strip away bottlenecks. As a result, the Solana we know today has vastly matured over its original implementation. Teams that adopt a similar hands-on approach – rapidly prototyping features, iterating over user feedback, and maintaining an actively responsive community dialogue – are more likely to build enduring products that usefully expand Solana’s broader ecosystem.
The network’s initial momentum was further amplified by consumer-facing applications that drew in real users: the top memecoin casino (Pump), one of the best crypto wallet user experiences (Phantom), high-speed trading bots (Photon, BullX, Trojan, BONKBot), user-friendly DEXs (Jupiter, Raydium), specialized yield-farming contracts (Meteora’s DLMM pools), and various experimental SocialFi apps driving excitement and exploration of Solana’s ecosystem (Time.fun, Clout, Tribe). Each successful launch attracted new participants, which in turn spurred further development and experimentation – creating a virtuous cycle for its ecosystem. Although other chain ecosystems (primarily Base) have introduced competing services and are contending in SocialFi applications, Solana’s early lead in deploying compelling, user-ready experiences helped establish the brand. Any Solana L2 seeking broad adoption should similarly focus on delivering tangible value and seamless UX to real users, rather than relying solely on performance claims.
Taking this into consideration, when evaluating Solana L2 and appchain projects, it’s important to ask ourselves:
Who are the founders and do they also demonstrate a consistent, product- and user-driven focus?
Is there (potential for) an engaged developer community and users committed to the project’s long-term success?
Does the project address clear needs beyond short-term hype factors?
Are they shipping apps that users will really want to use?
Ultimately, lasting ecosystems require a combination of technical excellence, sustained community investment, and genuine user adoption. The Solana L2s that can replicate or expand upon Solana’s cultural strengths stand the best chance of succeeding. Impressive performance metrics can attract short-term attention, but it’s the human element that sustains and scales a blockchain ecosystem over the long run.
In the next few years, we’ll likely see a more even battle for mindshare between the EVM and SVM ecosystems as high-performance SVM rollups on Ethereum and Solana-native L2s compete for users. This could erode EVM dominance (~43% of developer share) as Solana’s tech becomes more accessible across chains. In fact, Solana emerged as the fastest-growing ecosystem for new devs in 2024, coinciding with the release of the SVM API and surpassing Ethereum for the first time (~14% developer share). As Solana’s technology becomes more accessible across chains, its low-latency performance features (e.g., parallel processing) and strong culture and more focused community vision position the SVM as a compelling alternative to the EVM.
Modularity opens a lot of new market opportunities. Performance benchmarks are being shattered – sub-10ms latency and >10,000 TPS on L2 are becoming realistic, enabling dapps previously thought impossible in DeFi, DePIN, gaming, and beyond. Projects that achieve these feats could capture outsized user bases and revenue. Moreover as multiple SVM chains and SPEs launch, interoperability protocols (e.g., unified bridges, shared sequencer services, rollups-as-a-service platforms) will become important as we’ve seen in the Ethereum ecosystem.
New SVM‑compatible L1s such as Fogo and Unto, developed by former Jump Crypto (Firedancer) team members, have entered the spotlight as well. These platforms extend the modular vision beyond just L2 applications to multiple SVM-compatible L1s forked from the new Firedancer client. This emerging trend highlights the modularity and portability of the SVM (and Firedancer) stack: not only can it be used for L2s and appchains, but it can also serve as the foundation for new L1s.
While they directly compete at the base layer, such SVM-based L1s arguably support each other – similar to how EVM-based L1s do – through compatibility, interactivity, and a shared developer base. Where there is TVL and volumes, devs follow and are driven to learn new ropes as needed. This cross-pollination is evident in the numbers: 1 in 3 devs now work across multiple chains (up from <10% in 2015), with the highest concentrations of multi-chain deployment happening on VM-compatible chains, whether they are L2s or L1s.
In general, shared developer percentages have been rising for EVM-compatible chains year-over-year. As of last year, the average developer share was 51.9% for EVM-compatible chains (across L2s and L1s) vs. 12.2% for non-EVM compatible chains. We may see comparable developer share growth among SVM-compatible chains, with SVM-based L2 (and L1) devs meaningfully contributing to Solana L1 as well.
In the longer term, we can envision a modular, multi-chain “Solana universe” where the base layer handles the global state of potentially thousands of SVM appchains, custom-tailored for specific use cases. By focusing on appchains rather than generalized rollups, Solana can carve out a competitive edge – providing Solana L2s with stronger differentiation and moat than we see in Ethereum’s L2 landscape and also reducing parasitic value extraction from Solana L1 as it will still be performant for the bulk of use cases. Moreover, the combination of sovereign appchains, SPEs driving institutional adoption, and SVM-compatible L1s will arguably amplify Solana’s network effects by diversifying use cases and increasing stakeholders, mindshare, and developer activity.
Disclaimer
This article is prepared for general information purposes only. This post reflects the current views of its authors only and is not made on behalf of Lemniscap or its affiliates and does not necessarily reflect the opinions of Lemniscap, its affiliates or individuals. The opinions herein may be subject to change without this article being updated.
This article does not constitute investment advice, legal or regulatory advice, investment recommendation, or any solicitation to buy, sell or make any investment. This post should not be used to evaluate the making of any investment decision, and should not be relied upon for legal, compliance, regulatory or other advice, investment recommendations, tax advice or any other similar matters.
All liability in connection with this article, its content, and any related services and products and your use thereof, including, without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement is disclaimed. No warranty, endorsement, guarantee, assumption of responsibility or similar is made in respect of any product, service, protocol described herein.
