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:
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:
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:
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:
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 @harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7">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:
Overhauling the fee markets and increasing the base fees (currently set at 5,000 Lamports or 0.000005 SOL).
Implementing an exponential write-lock fee for accounts, i.e., incrementally increasing fees over time to discourage spamming.
Optimizing CU budget requests through a penalty system.
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.
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.
Source: Anza DevRel
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.
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:
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 high composability (particularly for non-Solana apps) and was thus free from mainnet congestion.
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:
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.
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, 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.
Two ‘somewhat rollapps’ are live currently:
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:
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:
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.
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).
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.
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.
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).
Furthermore, I feel general-purpose L2s on Solana may lead to the same old Ethereum problems, i.e., centralized rollups, congestion, and liquidity fragmentation.
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)
If the rollapp/appchain thesis expands, existing infrastructure providers will benefit greatly as they tap into new markets:
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?
Feel free to contact me at Yash Agarwal (@yashhsm on Twitter) for any suggestions or if you have any opinions. If you find this even slightly insightful, please share it — justifies my weeks of effort and gets more eyeballs :)
Special thanks to Karthik (PepperDEX), Brian Breslow (Dorahacks), Parth (Arana Ventures), Rex (Anza), Het Dagli (Superteam), Kash (Superteam), and Akshay (Superteam), who reviewed and provided insights at different stages of the draft.
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:
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:
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:
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:
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 @harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7">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:
Overhauling the fee markets and increasing the base fees (currently set at 5,000 Lamports or 0.000005 SOL).
Implementing an exponential write-lock fee for accounts, i.e., incrementally increasing fees over time to discourage spamming.
Optimizing CU budget requests through a penalty system.
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.
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.
Source: Anza DevRel
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.
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:
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 high composability (particularly for non-Solana apps) and was thus free from mainnet congestion.
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:
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.
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, 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.
Two ‘somewhat rollapps’ are live currently:
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:
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:
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.
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).
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.
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.
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).
Furthermore, I feel general-purpose L2s on Solana may lead to the same old Ethereum problems, i.e., centralized rollups, congestion, and liquidity fragmentation.
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)
If the rollapp/appchain thesis expands, existing infrastructure providers will benefit greatly as they tap into new markets:
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?
Feel free to contact me at Yash Agarwal (@yashhsm on Twitter) for any suggestions or if you have any opinions. If you find this even slightly insightful, please share it — justifies my weeks of effort and gets more eyeballs :)
Special thanks to Karthik (PepperDEX), Brian Breslow (Dorahacks), Parth (Arana Ventures), Rex (Anza), Het Dagli (Superteam), Kash (Superteam), and Akshay (Superteam), who reviewed and provided insights at different stages of the draft.