Author: Yash Agarwal Source: medium Translation: Shan Ouba, Golden Finance

A month ago, Vibhu, the founder of Solana's top consumer application DRiP, made a statement that sparked a much-needed discussion. DRiP gives away free NFTs from well-known artists every week through the platform. His statement was:

Solana will have and needs to have L2 and/or Rollup solutions.

His frustration stems from the fact that DRiP leaks a lot of value (about $20,000) to the bottom layer every week due to SOL price increases and network congestion. Increased Solana activity leads to:

• Pros - Increased liquidity, capital, and volume due to composability

• Cons - High infrastructure costs, poor user experience, and network congestion

However, DRiP, which primarily leverages Solana’s infrastructure to send millions of NFTs to thousands of wallets each week, does not benefit from high composability. Solana’s TVL growth and capital inflows have minimal impact on DRiP, which primarily suffers from drawbacks such as high infrastructure costs.

Vibhu noted that “there are diminishing returns to composability.” He also noted that Solana application developers privately discussed their desire for Rollup solutions due to the following reasons:

Increased transaction throughput, reduced block space competition, and lower fees. More control over the economic value generated by their business.

Solana has experienced multiple congestion events in the past few months, from JUP airdrops to ORE mining and peak memecoin transactions. One might think that Firedancer can solve all of these problems, but the reality is: Firedancer's timeline remains uncertain and it is currently unable to scale more than 10x. Despite this, Solana does remain the last true monolithic architecture among all the major battle-tested blockchains.

Should Solana remain a monolithic architecture or go modular? Will Solana evolve into fragmented L2 and L3 solutions like Ethereum? What is the current landscape of application chains and Rollups on Solana?

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

This article will not delve into technical details, but will take a more market-oriented and practical perspective to discuss various expansion methods to provide an overview.

This article will cover the following:

• Solana and Network Congestion

• Making Solana Modular

• Solana Application Chain - Examples

• Solana Layer-2 and Rollup (RollApps) - Examples

• Powering the Infrastructure for Rollup and Application Chains

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

• Implementing priority fees — critical to avoid delayed or lost transactions.

• Optimizing program compute unit (CU) usage — using only what is necessary.

• Implementing stake-weighted quality of service (QoS) — allowing applications to prioritize users’ transaction processing.

However, all of these measures can only improve transaction completion to a certain extent and do not guarantee a smooth transaction user experience. One immediate solution to this problem is the much-anticipated new transaction scheduler, scheduled for release in version 1.18 at the end of 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 scheduler if any issues arise. This new scheduler is designed to fill blocks more efficiently and economically, improving upon the inefficiencies of the old scheduler. Read this article for a deeper dive into the new Scheduler.

Anza (a spin-off entity of Solana Labs) has been continually attempting to address network congestion issues, which have been identified as issues related to the QUIC implementation, and requests for the behavior of the Agave (Solana Labs) validator client when asked to process large amounts of data.

While modularity proponents strongly advocate Solana’s “modularity roadmap,” Solana Labs/Anza (the core maintainers of the Solana protocol) remain focused on optimizing throughput and latency at the base layer. Some potential improvements include:

1. Overhaul the fee market and increase the base fee (currently set to 5,000 Lamports or 0.000005 SOL).

2. Implement exponential write lock fees on accounts, i.e. gradually increase fees over time to discourage spam.

3. Optimize CU budget requests through a penalty system.

4. Improve the overall architecture of the network.

Even with these improvements in vertical scaling (single chain), we cannot rule out the possibility of Solana adopting horizontal scaling (Rollup). The reality is that Solana can be a hybrid of the two - it can serve as an excellent base layer for rollups, with ultra-low latency block times (about 400 milliseconds), which will significantly benefit rollups, such as achieving ultra-fast soft confirmations from sequencers. The best part is that Solana has historically been able to implement changes quickly, which may make it a more effective Rollup layer than Ethereum. Making Solana Modular: Efforts to modularize Solana have already begun. As shown in Anza DevRel’s post, Solana validators and SVM (the execution environment that handles transactions and smart contracts/programs) are tightly coupled and maintained by Anza (a spinoff entity of Solana Labs). However, the validator client and SVM runtime will be separated in the coming months. This separation will facilitate forking the SVM and easily creating a “Solana AppChain”.

For Rollups, the benefits may come from optimizing Solana’s data availability (DA)/blob layer, although this may happen at a later stage.

Joe C (Anza Engineer) also unveiled plans for SVM modularization, where the transaction processing pipeline will be taken out of the validator and put into the SVM. This will enable developers to run an implementation of the SVM and operate independently of any validator.

An isolated SVM will be a collection of completely independent modules. Any SVM implementation can drive these modules through well-defined interfaces, further reducing the barrier to SVM-compatible projects by significantly reducing the overhead required to build custom solutions. Teams can implement only the modules they are interested in while leveraging established implementations of the rest, such as those from Agave or Firedancer.

In short, Solana will be more plug-and-play, making Solana AppChains and Rollups much easier.

In general, there are two directions: Layer-2s/Rollups and Appchains. We will look at both one by one. Solana Application Chain: Solana Application Chain, also known as SVM fork, is essentially an application-specific branch of the Solana chain. Pyth is the first Solana application chain, but the concept really attracted attention when Rune (one of the founders of the Maker Protocol) proposed to develop a Maker application chain (for governance) based on the Solana (SVM) codebase. Rune chose SVM because it has a strong developer community and technical advantages over other virtual machines, aiming to fork the best performing chain to better meet consumer needs. While no actions have been implemented yet, the move has sparked much-needed discussion about Solana application chains.

Solana application chains can be broadly divided into two types:

• Permissionless: Anyone can join the network, similar to the current Solana mainnet.

• Permissioned: The Solana Foundation launched "Solana Permissioned Environments (SPEs)" for institutions, allowing entities to build and maintain their own chain instances, powered by the SVM.

Pyth: The Old Solana Application Chain

At one point, Pyth accounted for 10-20% of all transactions on the Solana mainnet. However, it did not require any composability, so they simply forked the Solana codebase. This enables them to leverage Solana’s fast 400ms block times for high-frequency price updates. Pythnet is the first network to adopt SVM as its appchain.

The Pythnet appchain is a proof-of-authority fork of the Solana mainnet, used as a computational base layer for processing and aggregating data provided by the Pyth data publisher network.

Why did Pyth migrate?

• It does not require composability, thus avoiding mainnet congestion.

• It requires a permissioned environment for publishing data.

Cube Exchange is another example, a hybrid centralized exchange deployed as a standalone SVM appchain (order books are fully off-chain, settlement is on its SVM appchain).

Solana Application Chain Example

Solana Application Chain (also known as SVM Forks) open up possibilities for a wide range of projects, here are some examples:

• Perpetual Decentralized Exchanges (Perp DEX): Such exchanges, such as Hyperliquid, can run as independent L1 networks. In addition, 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 stop-loss orders directly into L1, ensuring that it is enforced as a state transition, or introducing application-specific atomic logic.

• Artificial Intelligence and Decentralized Physical Infrastructure Networks (DePIN): Such application chains can include a controlled list of service providers, such as Pyth. Akash operates as a computing marketplace through the Cosmos application chain.

• Governed application chains: MakerDAO's interest in the SVM application chain demonstrates the appeal of sovereign governance application chains. Governance in the crypto space is still evolving, and having dedicated chains that can be forked can be a useful coordination mechanism.

• Future Enterprise Application Chains: Potential applications include funds (such as BlackRock) or payment systems (such as Visa or CBDC).

• Game Application Chains: A casino game project on Solana is considering using its own application chain.

• Improved Forks of Solana: Similar to Monad or Sei providing optimized EVMs (parallel), more optimized versions of Solana can also be built. This trend may become more common in the coming years as the Solana mainnet begins to explore new design architectures.

Envisioning the Solana Application Chain Stack:

While it may be relatively simple to build an application chain, ensuring connections between all application chains is critical for interoperability. Solana can build on the experience of Avalanche subnets (connected via native Avalanche Warp messaging) and Cosmos AppChains (connected via IBC) to create a native messaging framework to connect these AppChains.

Beyond creating standalone AppChains, there are a few other ways to scale the Solana ecosystem:

• Cosmos-SDK-like middleware: can provide a turnkey solution for creating AppChains, with built-in support for oracles (such as Pyth or Switchboard), RPC (such as Helius), and messaging connections (such as Wormhole).

• Polygon AggLayer: This is also an interesting approach, where developers can connect any L1 or L2 chain to the AggLayer, which aggregates ZK proofs from all connected chains.

Are Lisks Good for the Solana Ecosystem?

While Lisks do not directly increase the value of SOL (since they do not pay SOL fees or use SOL as gas fees - unless the re-staked SOL is used for economic security), they do greatly benefit the SVM ecosystem. Just as there is an "EVM network effect", more SVM forks and Lisks will strengthen the SVM network effect. Even though Eclipse (SVM L2 on Ethereum) is a direct competitor to the Solana mainnet, the same logic that applies to it also applies to Eclipse, i.e. it is good for SVM.

Solana Layer-2: Another Branch on the Road to Modularity

Solana Layer-2 or Rollup are logically independent chains that publish data to the Data Availability (DA) layer of the host chain and reuse the consensus mechanism of the host chain. They can also use other DA layers (such as Celestia), but this would no longer be a true Rollup. "RollApp" is a term that is usually used for application-specific Rollups (which is what most Solana applications are exploring).

Will Solana Rollup be the same as Ethereum?

Apparently not. For Solana, Rollups will be more abstract to the end user. Ethereum's Rollup was ideologically top-down, with the Ethereum Foundation and leaders deciding that Rollups were the best way to scale and starting to support various L2s after the CryptoKitties disaster. For Solana, demand is bottom-up, coming from application developers with significant user adoption. Therefore, most current Rollup projects are more of a marketing gimmick than driven by consumer demand. This is a significant difference that could lead to a different future for Rollups on Solana than what we've seen on Ethereum.

Is Compression = Rollups?

L2 extends the base layer blockchain (L1) by executing transactions on L2, batching transaction data, and compressing it. The compressed data is then sent to L1 and used for fraud proofs (optimistic rollup) or validity proofs (zk rollup). This proof process is called "settlement". Similarly, compression offloads transactions from the mainnet, reducing contention for the base layer state. Notably, Grass L2 will leverage state compression for Rollups.

Rollups Landscape on Solana:

There are currently two "little rollapps" running:

1. Get the code:

The payment application with the micropayment SDK enables anyone to make and accept payments instantly, and also uses pseudo-Rollups for their applications. It creates intents for all transactions and employs a Rollup-like sorter that settles on Solana after N time intervals.

Using a Rollup-like structure allows:

1. Flexibility: Intents can represent a variety of future activities, not just payment transactions. In addition, Solana as a chain can also be replaced as needed.

2. Instant and Private: Given the soft finality of the sorter, payments are instant even during Solana congestion. While transactions are visible on-chain, the exact value and intent remain obscured, ensuring user privacy.

2. MagicBlocks' Temporary Rollup

MagicBlocks is a web3 gaming infrastructure that has developed Ephermal (or temporary) Rollup, especially for games. It uses the account structure of SVM, and the game state is divided into clusters. It temporarily transfers the state to an auxiliary layer or "temporary Rollup" (a configurable dedicated layer). The temporary Rollup runs as a specialized SVM runtime or Rollup to facilitate transaction processing with increased throughput.

Using a Rollup-like structure allows:

1. Customize specialized runtimes, including features such as gas-free transactions, faster block times and a combination of tick mechanisms (e.g., an integrated transaction scheduling system that runs like clockwork, for free).

2. Developers deploy programs to the base layer (e.g., Solana) rather than a separate chain or Rollup. ER does not fragment the existing ecosystem and can accelerate targeted operations without creating isolated environments. This means that all existing Solana infrastructure can be leveraged.

This approach facilitates a highly scalable system, able to spin up Rollups on demand and auto-scale 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 also be applied to other applications such as payments.

Upcoming Solana Rollups:

1. Grass: A DePIN project that aims to solve the AI ​​data problem through verified scraping. When Grass nodes scrape AI training data on the network, validators store the data on-chain, precisely tracking the source of the data and the nodes responsible for scraping it, and rewarding them proportionally.
   Grass requires 1 million web requests per second, which is not feasible on the Solana mainnet. As such, they plan to ZK-proof the raw data of all datasets and settle on Solana L1 in batches. They are considering using state compression from another cluster and rooting on the mainnet beta. This development positions Grass as a base layer for a variety of applications that can only be implemented on top of Grass (note that platforms and infrastructure generally demand higher valuations, and Grass is about to launch a token :P). Zeta: One of the oldest Perp DEXs on Solana, with a fully on-chain Perp order book, also plans to move its matching off-chain via Solana Rollup. Perp DEXs have instant PMFs for Rollups because they significantly improve the user experience. Just ask anyone who has traded on Hyperliquid or Aevo with Solana perp DEXs, you have to sign on every trade, a wallet pops up, and you have to wait about 10-20 seconds. Additionally, Perps do not require synchronous execution and offer a high degree of composability with the rest of DeFi, especially in terms of trade matching.

Interestingly, Armani (Backpack co-founder) also tweeted that they are now moving to L2.

Sonic is also building a modular SVM chain (Hypergrid) to enable games to deploy their own chains on Solana. There are also SVM-based Ethereum Rollups, such as Eclipse and NitroVM, which use SVM as an execution engine. Neon acts as an EVM-compatible L2 on Solana. In addition, there are some projects in the conception stage, such as Molecule (SVM Bitcoin Layer 2).

Sovereign SDK is another framework similar to Node.js, but for building Rollups. Users bring their Rust code and we convert it into Optimistic or ZK rollups that can be deployed on any blockchain. The Rust code can be your specific application logic or any virtual machine.

Some Papers on Rollups:

1. Rollups = SOL Alignment:
   The term “ETH Alignment”, or a better term “ETH Bag Biases”, has become a popular meme. Why do you think Layer 2 and Restake/EigenLayer have become the hottest topic? It’s because they increase the “moneyness of ETH” and ETH is used as a core asset everywhere.
   The same principle applies to Solana. The Solana community will rally around any solution that will increase their SOL holdings - it’s that simple. As the Solana ecosystem expands, the once overlooked “moneyness of SOL” will become important. Remember that most Rollups are “marketing plays” anyway and provide better token value accrual because the market still values ​​infrastructure more than applications.

2. Rollups Feel Like an Extension of Solana:
   Besides the security advantage (i.e. inheriting security from the base layer), easy access to Solana users and assets will be a significant advantage. As Jon Charbonneau points out, Ethereum Rollups (e.g. Base, Optimism, and Arbitrum) feel more like an extension of Ethereum. Users maintain the same wallets and addresses, the native Gas token is a single canonical version of ETH, ETH dominates DeFi across all trading pairs, social apps price NFTs in ETH and pay creators in ETH (e.g. friend.tech), and depositing funds into L2 is 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 does not have scaling issues like Ethereum, as Ethereum’s mainnet is not usable at all due to high gas fees, it is highly optimized. However, some applications that require dedicated block space will create their Rollups. While generalized Rollups on Solana do not make sense to me, it does make sense for the project from an economic perspective. For example, 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 seems to be a normal Rollup, and many (such as Linea, Scroll, or zkSync) have become ghost chains with only farmers doing small token airdrop transactions.
   Also, I think that generalized L2 on Solana could lead to the same old Ethereum problems of centralized Rollups, congestion, and liquidity fragmentation.

4. Why would some apps want to migrate to Rollapps/appchain?
   Each application will initially launch on the Solana mainnet, as hosting more applications on shared infrastructure significantly reduces complexity for developers and users. However, as these applications grow, they may seek:

• Value capture: It is more challenging to internalize value on a shared Solana layer designed with more than just one application in mind. MEV capture could be another lucrative option for DEXs.

• Dedicated blockspace

• Customizability in use cases
  such as: - Privacy: For example, Getcode uses a sequencer to facilitate private payments for users.
  - Fee Market Experiments
  - Encrypted Mempool to Minimize MEV
  - Custom Order Books
  However, not all applications will want to launch their own Rollup, especially those that haven’t yet reached a certain escape velocity (e.g., enough TVL, users, volume). Launching your own chain today involves painful and unnecessary tradeoffs (complexity, cost, bad UX, fragmented liquidity, etc.) and most applications, especially those in the early stages, can’t justify the incremental gains. Solana remains the heart and soul of SVM development, so many new applications will likely be deployed.

For App Builders: Solana Mainnet or Appchain or Rollup

Completely depends. If there isn’t a strong need for composability with all your other applications, it makes perfect sense to have some of the different components off-chain (appchain or rollup). Users don’t even need to know they’re using a Rollup or appchain. Grass, Zeta, and Getcode all abstract away whatever Rollup-type infrastructure they use for their users.

For permissioned and custom use cases, token extensions can also satisfy most needs like KYC/transfer logic while retaining composability.

So, will DRiP become an L2/appchain?

Currently, DRiP uses Solana for:

- User wallet creation (can be on L2/appchain)
- Distributing compressed NFTs (can be on L2/appchain)
- Trading compressed NFTs (can be on L2/appchain, but funds require bridging)

We can clearly see that there is no strong demand to use Solana Layer 1 beyond what L2s/appchains can also provide. Since DRiP’s primary target has always been web2 users, it is well-positioned to onboard them directly to their chain, which gives it greater control in the long run as it does not leak all value to the base chain (Solana). Additionally, DRiP has already reached escape velocity (largest consumer application on Solana) and has now moved to its own chain. A pseudo-Rollup structure like Getcode makes total sense for DRiP.

Infrastructure empowers Rollup and application chain

If the Rollup/application chain argument comes true, then existing infrastructure providers will benefit greatly as they enter the new market:

• As demand emerges, Rollup as a Service (RaaS) providers like Caldera can easily enter the SVM market. Similarly, Ethereum-focused SVM Rollups such as Eclipse and NitroVM are also closely watching this opportunity. Additionally, Sovereign Labs offers a Sovereign SDK Solana adapter for implementing Rollups on Solana (but not yet in production). As Mert has hinted several times, Helius is another company that is well suited to building infrastructure for Solana L2.

• The need for shared ordering services (e.g., Rome Protocol) and light clients (e.g., Tinydancer). Shared ordering services are attractive for Rollups because they enable activities such as atomic arbitrage, MEV, and seamless bridging, which reduces liquidity fragmentation.

• Wallets (e.g., Phantom, Backpack, and Solflare) and multi-signature and smart contract wallet infrastructure (e.g., Squads). Squads has been positioning itself as "the ultimate smart contract wallet infrastructure layer for Solana and SVM."

• SOL Re-staking: The modularity argument also promotes re-staking, as these Rollups/appchains may need SOL to share security and be more aligned with Solana. This will benefit:

• Early adopters such as Cambrian, Picaso, and Solayer

• Jito through Stakenet and Sanctum-like LST

• Validators - more income

Conclusion: Can Solana meet global demand?

Absolutely not. Let’s be realistic: this is unrealistic even taking into account Moore’s Law (hardware performance will continue to improve, and Solana is optimized for such hardware advances). I think all the less important transactions (e.g. DRiP sending NFTs) will eventually move to their own chains, while the most valuable transactions will remain on the main chain because true composability is critical here (e.g. instant swaps).

This does not mean Solana loses the battle of monolithic architecture and composability; it will handle use cases that rely on composability and low latency better than other chains. And projects like Sui/Aptos/Sei/Monad are not better yet because we don’t know how they will perform under high user real-world activity yet.

Unlike Ethereum, the Solana mainnet is not designed to be a “B2B chain”; it has always been and will always be a consumer-facing chain. Building distributed systems at scale is incredibly challenging, and Solana has the greatest potential to become the global shared ledger for the most valuable transactions.

Solana needs a soul mate: Can Rollup and application chain be its perfect match?