Persistent congestion: Does Solana need Layer 2 and Rollups?
TechFlow Selected TechFlow Selected
Persistent congestion: Does Solana need Layer 2 and Rollups?
Solana Needs a Soulmate: Are Appchains and Rollups Its Perfect Match?
Navigating Web3 tides with focused insightsAuthor: Yash Agarwal
Translation: TechFlow
A month ago, Vibhu, the founder of DRiP, sparked a much-needed debate in a statement: Solana needs L2s and rollups.
His reasoning? Due to rising SOL prices and network congestion, DRiP has been leaking significant value (about $20,000/week) to the base layer. Increased activity on Solana has led to:
-
Pros: Enhanced liquidity, capital inflows, and trading volume (attributed to composability)
-
Cons: Rising infrastructure costs, poor user experience, and network congestion
However, DRiP primarily uses Solana as infrastructure—distributing millions of NFTs weekly to thousands of wallets—and thus does not benefit from high composability. Growth in Solana’s TVL and capital inflows has little impact on DRiP, while it is significantly affected by drawbacks such as high infrastructure costs.
Vibhu pointed out: “Diminishing returns from composability.” He also noted that Solana app developers are privately discussing their desire for rollups, due to reasons including:
-
Increased transaction throughput, reduced block space competition, and lower fees
-
Greater control over the economic value generated by their business
Over the past few months, Solana has experienced multiple congestion events—from JUP airdrops to ORE mining and meme coin trading surges. While some may argue Firedancer can solve all these issues, let's be realistic: timelines remain uncertain, and current scaling beyond 10x is not feasible. Nevertheless, among all major chains tested through various stress scenarios, Solana is considered the last true monolithic chain standing.
Should Solana remain monolithic or become modular? Will Solana evolve like Ethereum, adopting decentralized L2 and L3 solutions? What is the current landscape of application-specific chains and rollups on Solana?
To answer these questions and summarize the entire debate, this article will explore all possibilities, discuss various projects, and assess their pros and cons.
This article will not delve into technical details but will take a more market-oriented and practical approach, discussing various scaling methods to provide an overview.
In short, we’ll cover:
-
Solana and congestion
-
Modularizing Solana
-
Solana appchains and examples
-
Solana L2s and rollups (RollApps) and examples
-
Infrastructure enabling rollups and appchains
Solana and Congestion
Let’s address the elephant in the room: recently, the Solana network has been highly congested (though mostly resolved now), due to activities like airdrops and massive meme coin trading, resulting in high ping rates, a high proportion of failed transactions, and increased network fees from priority fees. Despite these issues, Solana has maintained around 1–2k TPS—more than all EVM chains combined. I’d say this is a good problem for a blockchain to have, and it puts Solana’s monolithic design to the test.
The Solana Foundation recently published a blog post urging projects to immediately take action to enhance network performance, including:
-
Implementing priority fees, crucial for avoiding delayed or lost transactions.
-
Optimizing program compute unit (CU) usage via penalty systems, using only necessary portions.
-
Implementing priority-weighted quality of service (QoS), allowing apps to prioritize user transaction processing.
However, these measures can only improve transaction completion rates to a certain extent and cannot guarantee a smooth transaction experience. An immediate solution to this issue is the highly anticipated new transaction scheduler, planned for release in version 1.18 at the end of April. It will launch alongside the current scheduler but won’t be enabled by default, allowing validators to monitor its performance and easily revert if any issues arise. This new scheduler aims to fill blocks more efficiently and economically, improving upon the inefficiencies of the old one. Read this article for a deeper dive into the new scheduler.
Anza (a spin-off from Solana Labs) has been continuously experimenting to solve network congestion, identifying issues related to QUIC implementation and the behavior of Agave (Solana Labs) validator clients when handling large volumes of requests.
While proponents of modularity strongly advocate for Solana to adopt a "modular roadmap," Solana Labs/Anza (core maintainers of the Solana protocol) remain focused on optimizing base-layer throughput and latency. Some potential improvements include:
-
A complete overhaul of the fee market and raising the base fee (currently set at 5,000 Lamports or 0.000005 SOL)
-
Exponential write-lock fees for accounts, gradually increasing over time to deter spam
-
Optimizing CU budget requests via a penalty system.
-
Strengthening overall network architecture
Even with these vertical scaling (single-chain) improvements, we cannot rule out Solana adopting horizontal scaling (rollups). In fact, Solana could become a hybrid—serving as an excellent base layer for rollups, thanks to its ultra-low-latency block times (~400ms), which would greatly benefit rollups by enabling ultra-fast soft confirmations from sequencers. The best part? Solana has historically implemented changes rapidly, potentially making it a more efficient rollup settlement layer than Ethereum.
Update: Anza has now deployed several patches to help alleviate ongoing network congestion, with further enhancements coming in v1.18.
Modularizing Solana
Efforts to modularize Solana have already begun. As shown in a post from Anza DevRel, Solana validators and SVM (the execution environment for transactions and smart contracts/programs) are tightly coupled and maintained by Anza. However, the validator client and SVM runtime will be decoupled in the coming months. This separation will facilitate forking SVM and easily creating 'Solana appchains'.
For rollups, benefits may come from optimizing Solana’s data availability (DA)/blob layer, though this might happen in later stages.
Joe C, an engineer at Anza, also revealed plans to modularize SVM, where the transaction processing pipeline will be moved from validators into SVM itself. This will allow developers to run SVM implementations independently of any validator operations.
Isolated SVMs will be fully independent modular components. Any SVM implementation can drive these modules through clearly defined interfaces, significantly lowering barriers for SVM-compatible projects by reducing overhead for custom solutions. Teams can implement only the modules they care about while leveraging others from established implementations like Agave or Firedancer.
In short, Solana will become more plug-and-play, making Solana appchains and rollups easier to build.
Overall, there are two directions to pursue: Layer-2s/rollups and appchains. We’ll examine each in turn.
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 gained real attention when Rune, founder of Maker, proposed building a Maker appchain (for governance) based on the Solana (SVM) codebase. He chose SVM due to its strong developer community and technical advantages over other VMs, aiming to fork the highest-performing chain to better meet consumer needs. Although no implementation has occurred yet, this move sparked urgent discussions around Solana appchains.
Broadly, these can be divided into two types:
-
Permissionless: Anyone can join the network, similar to the current Solana mainnet
-
Permissioned: Packaged by the Solana Foundation as "Solana Permissioned Environments (SPEs)" for institutional use, allowing entities to build and maintain their own chain instances powered by SVM.
Pyth: The Pioneer of Solana Appchains
At one point, Pyth accounted for 10–20% of all transactions on the Solana mainnet. However, it didn’t require composability, so they simply forked the Solana codebase. This allowed them to leverage Solana’s 400ms fast block time for high-frequency price updates. Pythnet was the first network to adopt SVM as its appchain.
The Pythnet appchain is a proof-of-authority fork of the Solana mainnet, serving as the computational base layer for processing and aggregating data provided by Pyth Network data publishers.
Why did Pyth migrate?
-
It didn’t need composability, so it could escape mainnet congestion
-
It required a permissioned environment for data publishing
Cube Exchange is another example—a hybrid CEX deployed as a sovereign SVM appchain (with a fully off-chain order book, settling trades on its SVM appchain).
Some examples of Solana appchains include:
-
Perp DEX: Like Hyperliquid, perp DEXs can operate as standalone L1 networks. Additionally, for trading use cases, the number of transactions per block can be customized, or conditional logic can be implemented—such as directly integrating stop-loss order execution into the L1 to ensure it executes as a state transition—or introducing application-specific atomic logic.
-
AI and DePIN: These can have controlled lists of service providers like Pyth. For example, Akash operates as a compute marketplace via Cosmos appchains.
-
Governance appchains: Validated by MakerDAO’s interest in SVM appchains, sovereign governance appchains may be appealing. Cryptocurrency governance is still evolving, and having a dedicated chain for forking could serve as a useful coordination mechanism.
-
Future enterprise appchains: Potential applications include funds (like BlackRock) or payment systems (like Visa or CBDCs).
-
Gaming appchains: A casino gaming project on Solana is considering launching its own appchain.
-
Modified Solana forks: Just as Monad or Sei offer optimized EVMs (parallelized), someone could build a more optimized version of Solana. This trend may become more common in the coming years, especially as the Solana mainnet begins exploring new architectural designs.
Envisioning a Solana Appchain Stack
While building an appchain may be relatively simple, ensuring connectivity between all appchains is crucial for interoperability. Taking inspiration from Avalanche subnets (connected via native Avalanche Warp Messaging) and Cosmos appchains (connected via IBC), Solana could also create a native messaging framework to connect these appchains.
Middleware similar to Cosmos-SDK could also be created, offering a one-stop solution for building appchains with built-in support for oracles (like Pyth or Switchboard), RPCs (like Helius), and messaging connectivity (like Wormhole).
Polygon AggLayer is another interesting approach, where developers can connect any L1 or L2 chain to AggLayer, which aggregates ZK proofs from all connected chains.
Are Appchains Positive for the Solana Ecosystem?
Although appchains don’t directly increase SOL’s value—since they don’t pay fees in SOL or use SOL as gas unless re-staked SOL is used for economic security—they do greatly benefit the SVM ecosystem. Just as there’s an “EVM network effect,” more SVM forks and appchains will strengthen the SVM network effect. The same logic makes Eclipse (an SVM L2 on Ethereum) beneficial for SVM, even though it’s a direct competitor to the Solana mainnet.
Solana Layer 2
Solana’s Layer 2, or rollups, are logically independent chains that publish data to their parent chain’s data availability (DA) layer and reuse the parent chain’s consensus mechanism. They can also use other DA layers like Celestia, but then they wouldn’t be true rollups. “RollApp” is a term commonly used to refer to application-specific rollups (which most Solana applications are exploring).
Are Solana Rollups the Same as Ethereum’s?
Clearly not. For Solana, rollups are largely abstracted from end users. Ideologically, Ethereum’s rollups are top-down—driven by the Ethereum Foundation and leaders who decided to scale via rollups after the CryptoKitties incident, supporting various L2s. On Solana, demand is bottom-up, emerging from application developers with significant consumer adoption. Thus, most current rollups are marketing-driven narratives rather than consumer-demand-driven. This key difference may lead to a future for rollups distinct from what we’ve seen on Ethereum.
Does Compression Equal Rollup?
L2s scale base-layer blockchains (L1s) by executing transactions on L2, batching transaction data, and compressing it. The compressed data is then sent to L1 and used in fraud proofs (optimistic rollups) or validity proofs (zk rollups). This process is called “settlement.” Similarly, compression can offload transactions from the mainnet, reducing contention for base-layer state. Notably, Grass L2 will leverage state compression for its rollup.
Current State of Rollups on Solana
Currently, two “sort-of-Rollapp” applications are live:
GetCode
A payments app with a micropayments SDK enabling instant payments and receipts, also using a pseudo-rollup structure for its app. It creates intents for all transactions and uses a rollup-like sequencer to settle batches on Solana every N intervals.
Using a rollup-like structure enables:
-
Flexibility: Intents can represent various future actions, not just payment transactions. Additionally, Solana as a chain can be replaced if needed.
-
Instant and private: Payments are instant due to the sequencer’s soft finality, even during Solana congestion. While transactions are visible on-chain, exact values and intents remain obscured, preserving user privacy.
MagicBlocks’ Ephemeral Rollup
MagicBlocks is Web3 gaming infrastructure that developed ephemeral (or temporary) rollups specifically for games. It uses SVM’s account structure, with game states split into clusters. It temporarily shifts state to an auxiliary layer or “ephemeral rollup”—a configurable, dedicated layer. The ephemeral rollup runs as a specialized SVM runtime or rollup to process transactions at higher throughput.
Using a rollup-like structure enables:
-
Customization of specialized runtimes, including gasless transactions, faster block times, and integration of a tick mechanism (e.g., a fee-free integrated transaction scheduling system, akin to clockwork).
-
Developers can deploy programs to the base layer (e.g., Solana) instead of separate chains or rollups. ER doesn’t break the existing ecosystem and allows accelerated target operations without creating isolated environments. This means all existing Solana infrastructure can be leveraged.
This approach helps build a highly scalable system capable of launching rollups on-demand and auto-scaling horizontally to handle millions of transactions per user, without typical trade-offs of traditional L2s. While MagicBlock focuses on gaming, this method could also apply to other applications like payments.
Upcoming Solana Rollups
Grass: A DePIN project aiming to solve AI data problems via verified web crawlers. When Grass nodes crawl AI training data from the web, validators will store the data on-chain, precisely tracking the source of the data and the nodes responsible for crawling it, and reward them proportionally.
Grass requires one million web requests per second—unfeasible on the Solana mainnet. Therefore, they plan to generate ZK proofs for raw data across datasets and batch-settle on Solana L1. They’re considering using state compression from another cluster and settling roots on mainnet-beta.
This development will position Grass as a foundational layer for a suite of applications possible only atop Grass (note: platforms and infrastructures typically command higher valuations, and Grass is preparing to launch its token).
Zeta: One of the oldest perpetual exchanges on Solana, previously relying entirely on-chain perpetual options order books, now plans to move matching off-chain via a Solana rollup.
Perpetual exchanges have immediate PMF (product-market fit) for rollups because they drastically improve user experience. Just ask anyone trading between Hyperliquid or Aevo versus a Solana perpetual exchange—you’ll find that on Solana, you must sign every trade, a wallet popup appears, and you wait about 10–20 seconds. Moreover, perpetual exchanges don’t require synchronous execution and have high composability with other assets in other areas of DeFi (especially trade matching).
Interestingly, Armani, co-founder of Backpack, also tweeted that they now lean toward L2.
Sonic is also building a modular SVM chain (Hypergrid), enabling games to deploy their own chains on Solana. There are also SVM-based Ethereum rollups like Eclipse and NitroVM, using SVM as the execution engine. Neon operates on Solana as an EVM-compatible L2. Additionally, conceptual-stage projects include Molecule (an SVM Bitcoin Layer 2).
Sovereign SDK is another Node.js-like framework for building rollups. Users bring their Rust code, and we convert it into an optimistic or ZK rollup deployable on any blockchain. The Rust code can be your specific application logic or any virtual machine.
Key Arguments Around Rollups
1. Rollups = Aligned with SOL:
The term “ETH-aligned” or better, “ETH asset bundle preference,” has become a popular meme. Why do you think Layer 2 and Restaking/EigenLayer became the hottest narratives? Because they enhance “ETH’s monetary properties,” with ETH used as the core asset. The same principle applies to Solana. The Solana community will rally behind any solution that strengthens their SOL holdings—it’s that simple. As the Solana ecosystem expands, the once-overlooked “monetary properties of SOL” will grow in importance. Remember, most rollups are “marketing plays,” and since the market still values infrastructure more than applications, they offer better token value accrual.
2. Rollups Will Feel Like Extensions of Solana
Beyond security benefits (i.e., inheriting security from the base layer), easy access to Solana users and assets will be a major advantage. As Jon Charbonneau pointed out, Ethereum rollups like Base, Optimism, and Arbitrum feel more like extensions of Ethereum. Users keep the same wallets and addresses, the native gas token is a single canonical version of ETH, ETH dominates DeFi, all trading pairs are priced in ETH, social apps price NFTs in ETH and pay creators in ETH (e.g., friend.tech), and deposits into L2s are instant, etc. Similarly, this will happen on Solana. Learning from Ethereum, most Solana Rollapps won’t make users feel like they’re using a separate chain (e.g., Getcode).
3. Solana Will See More “RollApps” Than “Rollups”
Unlike Ethereum, Solana doesn’t face the scaling issue where the mainnet becomes unusable due to high gas fees—it’s already highly optimized. However, some applications needing dedicated blockspace will create their own rollups. While general-purpose rollups on Solana don’t make sense to me, economically they do for projects. For instance, Base users generated $2M in revenue for Coinbase in a single day! Incentives heavily favor L2s for builders. Yet, as observed, every EVM rollup seems generic—Lvm, Scroll, or zkSync—becoming ghost chains with only minimal token airdrop trades from bounty hunters.
Moreover, I feel general-purpose L2s on Solana could lead to the same past Ethereum problems: centralized rollups, congestion, and fragmented liquidity.
4. Why Do Some Apps Want to Migrate to Rollapps/Appchains?
Every application will initially launch on the Solana mainnet, as hosting more apps on shared infrastructure significantly reduces complexity for both developers and users. However, as these apps grow, they may seek:
-
Value capture: Internalizing value is more challenging on a shared Solana layer designed for more than just one app. MEV capture could be another lucrative option for DEXs.
-
Dedicated blockspace
-
Customizability for use cases, such as:
-
Privacy: e.g., Getcode uses a sequencer to offer private payments to its users
-
Fee market experimentation
-
Encrypted mempools to minimize MEV
-
Custom order books
-
However, not all apps want to launch their own rollup, especially those that haven’t reached sufficient escape velocity (e.g., enough TVL, users, trading volume). Launching your own chain today involves pain and unnecessary trade-offs (complexity, cost, worse UX, liquidity fragmentation, etc.), and most apps—especially early-stage ones—can’t justify the incremental gains. Solana remains the heart and soul of SVM development, and many new apps will likely deploy here for this reason.
App Builders: Solana Mainnet vs. Appchain vs. Rollup
For app builders: Solana mainnet, appchain, or rollup—it completely depends on the use case. If there’s no strong need to compose with all other apps, moving some distinct components off-chain (whether appchain or rollup) makes perfect sense. Users may not even know they’re using a rollup or appchain. Grass, Zeta, and Getcode all abstract the rollup-type infrastructure they use from their users.
For use cases requiring permissions and customization, token extensions can also meet most needs
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@yashhsm
