By Yash Agarwal

A month ago, Vibhu, the founder of DRiP, the top consumer app on Solana distributing free NFTs from top artists, sparked a much-needed debate with his statement:

Solana is going to have and needs to have L2s and/or rollups

His frustration arose because DRiP has been leaking significant value (~$20K/week) to the base layer, thanks to rising SOL prices and network congestion. Increased activity on Solana leads to:

1. Pros — Enhanced liquidity, capital, and transaction volumes (owing to composability)
2. Cons — Elevated infrastructure costs, poor user experience, and congestion

However, DRiP, which primarily uses Solana just as infra to distribute millions of NFTs weekly from artists to thousands of wallets, does not benefit from high composability. The growth in Solana’s TVL and capital influx has little impact on DRiP, which primarily suffers from drawbacks, such as high infra costs.

Vibhu points out, “Composability has diminishing returns.” He also notes that Solana app developers are discussing privately their desire for rollups because of:

1. Increased transaction throughput, less block space competition, and reduced fees.
2. Greater control over the economic value their businesses generate.

Over the past few months, Solana has experienced multiple congestion incidents, ranging from airdrops like JUP to ORE mining and peak memecoin trading. While one might argue that the Firedancer can resolve all these issues, let’s be realistic: the timeline remains uncertain, and it cannot scale beyond 10x for now. Despite this, it’s true that among all the major chains that have been battle-tested, Solana stands as the last remaining true monolith.

Should Solana remain a monolith or become modular? Will Solana also evolve like Ethereum with fragmented L2 and L3 solutions, among others? What is the current landscape of appchains and rollups on Solana?

To address these questions and summarize the entire debate, this essay will explore all possibilities, discuss various projects, and evaluate their pros and cons.

This article won’t delve deeply into technicalities but will instead adopt a more market-oriented and practical perspective in discussing various scaling approaches to provide an overview.

All insights, no fluff — plus plenty of alpha.

In a nutshell, we will discuss:

1. Solana and the Congestion
2. Making Solana Modular
3. Solana Appchains — with examples
4. Sollana Layer-2s and Rollups (RollApps) — with examples
5. Infra Powering Rollups and Appchains

Solana and the Congestion:

Let’s start by addressing the elephant in the room: the Solana network has been highly congested lately (now mostly resolved) due to airdrops, a substantial amount of memecoin trading activity, and so forth, leading to high ping times, a high percentage of failed transactions, and increased network fees due to higher priority fees. Despite all of this, Solana has consistently processed around 1–2k TPS, more than all EVM chains combined. I would say it’s a good problem for a blockchain to have, and it has also put Solana’s monolithic thesis to the test.

The Solana Foundation recently published a blog urging projects to take immediate actions to enhance network performance, including:

• Implementing priority fees — critical to avoiding delayed or dropped transactions.
• Optimizing Program Compute Unit (CU) usage — using only what is necessary.
• Implementing stake-weighted Quality of Service (QoS) — allowing apps to prioritize their users’ transaction processing.

However, all these measures only somewhat improve transaction completion and do not guarantee a smooth transaction UX. One immediate fix to this issue is the much-anticipated new Transaction Scheduler, slated for release in version 1.18 targeted for late April. It will be introduced alongside the current scheduler but will not be enabled by default, allowing validators to monitor the performance of the new scheduler and easily revert to the old one if any problems arise. This new scheduler aims to fill blocks more efficiently and economically, improving upon the old scheduler’s inefficiencies. Read this article to learn more in-depth about the new Scheduler.

Anza (a spinoff entity from Solana Labs) has been continuously trying to solve the network congestion which has been identified as issues related to QUIC implementation, and the behavior of the Agave (Solana Labs) validator client, when asked to process a large number of requests.

While proponents of modularity have strongly advocated for a ‘modular roadmap’ for Solana, Solana Labs/Anza (the core maintainer of the Solana protocol) remains focused on optimizing the base layer’s throughput and latency. Some potential improvements include:

1. Overhauling the fee markets and increasing the base fees (currently set at 5,000 Lamports or 0.000005 SOL).

2. Implementing an exponential write-lock fee for accounts, i.e., incrementally increasing fees over time to discourage spamming.

3. Optimizing CU budget requests through a penalty system.

4. Enhancing the overall network architecture.

Even with these improvements in vertical scaling (single chain), we can’t dismiss the possibility of Solana adopting horizontal scaling (rollups). The reality is that Solana can become a hybrid of both — it could serve as an excellent base layer for rollups, boasting super low latency block times (~400 ms) that would significantly benefit rollups, such as enabling super-fast soft confirmation from sequencers. The best part is that Solana has historically been quick to implement changes, potentially making it a more efficient layer for rollups than Ethereum.

Update: Anza has now pushed some patches help alleviate some of the ongoing network congestion, and will be followed by further enhancements in v1.18.

Making Solana Modular:

The efforts to make Solana modular have already been started. As Anza DevRel’s post indicates, the Solana validator and the SVM (execution environment that processes transactions and smart contracts/programs) are tightly coupled and maintained by Anza (a spin-off entity from Solana Labs). However, the validator client and the SVM runtime will be separated over the next few months. This separation will facilitate forking off the SVM and easily creating ‘Solana appchains.’

For rollups, the benefit could come from optimizing the Data Availability (DA)/blob layer of Solana, although this may happen at a later stage.

Joe C (engineer at Anza) also unveiled the plans for making SVM modular, where the transactions processing pipeline will be taken out of the validator and put into SVM. This will enable developers to run the implementation of SVM and operate independently of any validator.

The isolated SVM will be an assembly of entirely independent modules. Any SVM implementation could drive these modules through well-defined interfaces, further reducing the barriers for SVM-compatible projects by significantly decreasing the overhead required to architect custom solutions. Teams could implement only the modules they are interested in, while utilizing established implementations for the rest, such as those from Agave or Firedancer.

In short, Solana would be more plug-and-play, making Solana appchains and rollups much easier.

Broadly, there are two directions, where this can go: Layer-2s/Rollups and Appchains. We will have a look at both — one by one.

Solana Appchains:

Also known as SVM forks, these are essentially forks of the Solana chain dedicated to specific applications. Pyth was the first Solana appchain, but the concept truly gained attention when Rune, the founder of one of the largest DeFi protocols, Maker, caused quite a stir with his proposal to develop a Maker appchain (for governance) based on the Solana (SVM) codebase. He chose SVM due to its strong developer community and technical superiority over other VMs, aiming to fork the most performant chain to better meet consumer needs. Although nothing has been implemented yet, this move sparked a much-needed debate on Solana appchains.

Broadly, it can be of two types:

1. Permissionless — Anyone can join the network, similar to the current Solana mainnet.
2. Permissioned — Packaged as ‘Solana Permissioned Environments (SPEs)’ by the Solana Foundation for institutions, it allows entities to build and maintain their own chain instance, powered by the SVM.

Pyth — The OG Solana Appchain:
At one time, Pyth accounted for 10–20% of all transactions on the Solana mainnet. However, it didn’t require any composability, so they simply forked the Solana codebase. This allowed them to leverage Solana’s fast block time of 400 ms for high-frequency price updates. Pythnet was the first network to adopt SVM for its appchain.

The Pythnet appchain is a Proof-of-Authority fork of Solana’s mainnet, serving as a computational base layer for processing and aggregating data provided by Pyth’s network of data publishers.

Why did Pyth move?
-It didn’t require composability and was thus free from mainnet congestion.
- It needed a permissioned environment for publishing data.

Cube Exchange is another example, a hybrid CEX deployed as a sovereign SVM appchain (with a completely off-chain order book and settlement on their SVM appchain)

Some examples of Solana Appchains could be:

1. Perp DEXs: Like Hyperliquid, Perp DEXs can operate as separate L1 networks. Additionally, for trading use cases, the number of transactions per block can be customized, or conditional logic can be implemented, such as integrating the execution of a stop-loss order directly into the L1, ensuring it is enforced as a state transition, or introducing atomic logic specific to the app.
2. AI and DePIN: These can feature a controlled list of service providers like Pyth. For example, Akash operates as a compute marketplace via a Cosmos appchain.
3. Governance appchains: Validated by MakerDAO’s interest in an SVM app-chain, a sovereign governance appchain can be compelling. Governance in crypto is still evolving, and having a dedicated chain-to-fork can be a useful coordination mechanism.
4. Future Enterprise appchains: Potential applications include funds (like BlackRock) or payment systems (like Visa or CBDCs).
5. Gaming Appchains: A casino gaming project on Solana is considering its appchain.
6. Modified forks of Solana: Similar to how Monad or Sei offer optimized EVMs (parallelized), someone could build a more optimized version of Solana. This trend might become more prevalent in the coming years, especially as the Solana mainnet begins to explore new design architectures.

Envisioning the Solana Appchain Stack:

While establishing an appchain may be relatively straightforward, ensuring connectivity across all appchains is crucial for interoperability. Taking inspiration from Avalanche Subnets (connected by native Avalanche Warp Messaging) and Cosmos appchains (connected by IBC), Solana could also create a native messaging framework to connect these appchains.

One could also create a Cosmos-SDK-like middleware, offering a turnkey solution for creating appchains with built-in support for oracles (like Pyth or Switchboard), RPCs (like Helius), and messaging connectivity (like Wormhole), among others.

Polygon AggLayer would also be an interesting approach, where devs can connect any L1 or L2 chain to the AggLayer, which aggregates ZK proofs from all connected chains.

Is an Appchain Net Positive for the Solana Ecosystem?

Although appchains do not directly accrue value to SOL, as they would not pay fees in SOL or use SOL as the gas token — unless the re-staked SOL is used for economic security — they do greatly benefit the SVM ecosystem. Just as there are ‘EVM network effects,’ more SVM forks and appchains will strengthen SVM network effects. The same logic that makes Eclipse (SVM L2 on Ethereum) bullish for SVM applies, even though it is a direct competitor to the Solana mainnet.

Solana Layer-2s:

Solana Layer-2s, or rollups, are logically separate chains that post data to their host chain’s Data Availability (DA) layer and reuse the host chain’s consensus mechanism. They can also use other DA Layers like Celestia, however, it doesn’t remain a true rollup. “RollApp” is a term generally used for Application-specific Rollups (which most Solana applications are exploring).

Would Solana Rollups be the same as Ethereum?
Apparently No. For Solana, Rollups would be mostly abstracted away for the end user. On the ideological front, Ethereum rollups were top-down, where the Ethereum Foundation and leaders decided that the best way to scale was through rollups, and they started supporting various L2s after the CryptoKitties fiasco. Whereas on Solana, the demand is bottom-up, i.e., coming from application developers with significant consumer adoption. As a result, most of the current roll-up plays are marketing plays and are more narrative-driven than consumer demand-driven. This is a significant difference and may lead to a different future for rollups than what we saw on Ethereum.

Are Compression = Rollups?

L2s scale base layer blockchains (L1s) by executing transactions on the L2, batching the transaction data, and compressing it. The compressed data is then sent to the L1 and used in either the fraud proof (optimistic rollup) or validity proof (zk rollup). This proving process is referred to as ‘settlement.’ Similarly, compression offloads transactions from the mainnet, reducing contention for state on the base layer. Notably, Grass L2 will be leveraging State Compression for its rollup.

Rollups Landscape on Solana:

Two ‘somewhat rollapps’ are live currently:

1. GetCode:

A payments app with a micropayments SDK enables anyone to pay and accept payments instantly and also uses a pseudo-rollup for its application. It creates intents for all transactions and employs a rollup-like sequencer, which settles on Solana after N intervals.

Using a rollup-like structure enables:

1. Flexibility: Intents can represent various future activities, not just payment transactions. Moreover, Solana as a chain can also be replaced if necessary.
2. Instant and Private: Given the soft finality of the sequencer, payments are instant even during Solana congestion. While transactions are visible on-chain, the exact value and intent remain obscured, ensuring user privacy.

2. Ephermal Rollups by MagicBlocks

MagicBlocks, a web3 gaming infra has developed Ephermal (or temporary) rollups, particularly for games. It uses SVM’s account structure and the game state is split into clusters. It temporarily transfers the state to an auxiliary layer or the “ephemeral rollup”, a configurable dedicated layer. The ephemeral rollup operates as a specialized SVM runtime or rollup to facilitate transaction processing at an elevated throughput.

Using a rollup-like structure enables:

1. Customization of the specialized runtime to include features like gasless transactions, quicker block times, and the incorporation of a ticking mechanism (e.g., an integrated transaction scheduling system like clockwork, operated without fees).
2. Developers to deploy programs to the base layer (e.g., Solana) rather than on a separate chain or rollup. ERs don’t fragment the existing ecosystem and allow the acceleration of targeted operations without creating an isolated environment. This means all existing Solana infrastructure can be utilized.

This approach facilitates a highly scalable system capable of launching rollups on demand and auto-scaling horizontally to accommodate users performing millions of transactions, without the trade-offs typical of traditional L2s. While MagicBlock is specifically focused on gaming, this approach can be applied to other applications like payments.

Upcoming Solana Rollups:

1. Grass: A DePIN project aimed at solving AI data problems through verified scraping. When Grass nodes scrape the web for AI training data, validators will store the data on-chain, tracking precisely where the data originated and which node was responsible for scraping it, rewarding them proportionately.
   Grass requires 1 million web requests per second, which is unfeasible on the Solana mainnet. Therefore, they plan to make ZK proofs of the origin data for all datasets and batch them for settlement on Solana L1. They are considering using state compression from another cluster and settling roots on the mainnet-beta.
   This development will position Grass as a base layer for a wide range of applications that are only possible atop Grass (note that platforms and infrastructure often command much higher valuations and Grass is launching the token soon :P).
2. Zeta: One of the oldest perp DEX on Solana which had a completely on-chain perp order book is also planning to move its matching off-chain via the Solana rollup.
   Perp DEXs have an immediate PMF for rollups as they significantly improve UX. Just ask someone who has traded on Hyperliquid or Aevo versus Solana perp DEXs, where you have to sign each transaction, a wallet pops up, and you have to wait ~10–20 seconds. Furthermore, perps don’t require synced execution and offer high composability with the rest of DeFi, particularly in the trade matching aspect.

Interestingly, Armani (Co-Founder of Backpack) also tweeted they are now tending to L2.

Sonic is also building a modular SVM chain (Hypergrid) that will enable games to deploy their own chains on Solana. There are also SVM-based Ethereum rollups like Eclipse and NitroVM that use SVM as the execution engine. Neon functions as an EVM-compatible L2 on Solana. Additionally, there are projects at the idea stage, such as Molecule (an SVM Bitcoin Layer 2).

Sovereign SDK is another framework similar to node.js, but for building rollups. Users bring their Rust code, and we turn it into an Optimistic or ZK rollup that can be deployed on any blockchain. The Rust code can be your specific app logic, or any VM.

A few theses on Rollups:

1. Rollups = Being SOL-Aligned:
   The term ‘ETH-Aligned,’ or a better word for ‘ETH Bag Biases,’ has become a popular meme. Why do you think Layer 2s and Restaking/EigenLayer have become the hottest narrative? It’s because they increase the ‘Moneyness of ETH,’ with ETH being used as the core asset everywhere.
   The same principle applies to Solana. The Solana community will rally around any solution that boosts their SOL holdings — it’s that simple. As the Solana ecosystem expands, the once-overlooked ‘Moneyness of SOL’ will come into significance. Remember, most Rollups are anyway “Marketing Play” and give better token value accrual as markets still value Infra more than Applications.
2. Rollups will feel like an extension to Solana:
   Beyond security benefits (i.e., inheriting security from the base layer), easy access to Solana users and assets will be a significant advantage. As Jon Charbonneau notes, Ethereum Rollups such as Base, Optimism, and Arbitrum feel more like extensions of Ethereum. Users maintain the same wallets and addresses, the native gas token is a single canonical version of ETH, ETH dominates DeFi with all trading pairs, social apps price NFTs in ETH and pay creators in ETH (e.g., friend.tech), and deposits into the L2 are instant, etc.
   Similarly, this will happen with Solana. Learning from Ethereum, most Solana Rollapps will not make users feel like they are using a separate chain (e.g., Getcode).
3. Solana will see more “RollApps” than “Rollups”
   Solana doesn’t have a scaling problem like Ethereum where the mainnet is simply unusable due to high gas fees, it’s highly optimized. However, some apps which need dedicated blockspace will create their rollups. While general-purpose Rollups on Solana don’t make sense to me, economically it does make sense for the projects. For instance, Base users generated $2 million in revenue for Coinbase in just one day! The incentives for builders are heavily skewed towards L2. However, as observed, every EVM rollup appears to be a vanilla roll-up, and many, like Linea, Scroll, or zkSync, have become ghost chains with only farmers conducting a few transactions for token airdrops.
   Furthermore, I feel general-purpose L2s on Solana may lead to the same old Ethereum problems, i.e., centralized rollups, congestion, and liquidity fragmentation.
4. Why would some apps want to move to Rollapps/appchain?
   Every app will initially start on the Solana Mainnet, as hosting more apps on shared infrastructure significantly reduces developer and user complexity. However, as these apps grow, they might seek to:

• Value Capture: It’s more challenging to internalize value on a shared Solana layer not designed with just one application in mind. MEV capture can be another lucrative option for DEXs.
• Dedicated Blockspace
• Customizability in use-cases like:
  - Privacy: For example, Getcode uses a sequencer to facilitate private payments for its users.
  - Fee Market Experimentations
  - Encrypted mempools to minimize MEV
  - Tailored order books
  However, not all apps will want to launch their own Rollup, especially those that have not reached a certain escape velocity (for example, sufficient TVL, users, volume). Launching your own chain today involves painful and unnecessary trade-offs (complexity, cost, worse UX, fragmented liquidity, etc.), which most apps, particularly those in the early stage, cannot justify for the incremental benefits. Solana remains the heart and soul of SVM development, and many new applications will likely be deployed as a result.

For App Builders: Solana Mainnet or Appchain or Rollup

Completely depends. If there is not a strong need for composability with all other apps, taking a few different components off-chain (either appchain or rollup) completely makes sense. A user shouldn’t need to know they are even using a rollup or appchain. Grass, Zeta, and Getcode all abstract any rollup-type infra they are using for their users.

For permissioned and customization use cases, Token Extension also serves most of the needs like KYC/transfer logic while retaining the composability.

So, Will DRiP be an L2/appchain?

Currently, DRiP uses Solana for:

- User-creating wallets (can be on L2/appchain)
- Distributing Compressed NFTs (can be on L2/appchain)
- Trading of Compressed NFTs (can be on L2/appchain, but funds need to be bridged)

We can clearly see there isn’t a strong need to be on Solana Layer 1, besides the tech which L2s/appchains can also provide. Since the primary target of DRiP has always been web2 users, it can very well onboard them directly to their chain, which gives it much higher control in the long term as it won’t be leaking all the value to the base chain (Solana). Further, DRiP has reached the escape velocity (largest consumer app on Solana) to now move to their own chain. A pseudo-rollup structure like Getcode completely makes sense for DRiP.

Infrastructure Powering Rollups and Appchains:

If the rollapp/appchain thesis expands, existing infrastructure providers will benefit greatly as they tap into new markets:

1. Existing Rollup as a Service (RaaS) providers like Caldera can easily enter the SVM market as demand emerges. SVM Ethereum rollups like Eclipse and NitroVM are also keenly watching this opportunity. Additionally, Sovereign Labs offers a Sovereign SDK Solana adapter that enables rollups on Solana (not yet production-ready). Helius is another company well-suited to build infrastructure for Solana L2s, as Mert has hinted at multiple times.
2. Shared Sequencers like Rome Protocol and the need for Light Clients like Tinydancer. Shared sequencers can be interesting for rollups as they enable activities such as atomic arbitrage, MEV, and seamless bridging, decreasing liquidity fragmentation.
3. Wallets like Phantom, Backpack, and Solflare. Multi-sig and smart contract wallet infrastructure like Squads. Squads have always been positioned as “The definitive smart contract wallet infrastructure layer for Solana and SVM.”
4. SOL Restaking: The modular thesis also promotes restaking as these rollups/appchains might require SOL shared security and become more aligned with Solana. This leads to:

• Early-stage players like Cambrian, Picaso, and Solayer
• Jito via Stakenet and LSTs like Sanctum
• Validators — increased revenue

Closing Thoughts: Can Solana Handle the Entire World’s Demand?

Definitely not. Let’s be realistic: even considering Moore’s Law (that hardware performance will continue to improve, and Solana is optimized for such hardware advancements), it’s impractical. I believe that all less critical transactions (like DRiP sending NFTs) will eventually move to their own chains, while the most valuable transactions will remain on the main chain, where true composability is essential (e.g., Spot DEXs).

And no, this doesn’t mean that Solana has lost in the monolith and composability battle; it will manage cases that depend on composability and low latency better than other chains. And no, Sui/Aptos/Sei/Monad, etc etc aren’t any better yet, as we don’t know and they are yet to be battle-tested for the high real user activity.

Unlike Ethereum, the Solana Mainnet is not aiming to be the “B2B chain”; it was and always will be the consumer chain. Building distributed systems at scale is incredibly challenging, and Solana has the best potential to become the global shared ledger for the most valuable transactions.

Solana Needs Soulmates: Could Appchains and Rollups Be Its Perfect Match?