The Billion Dollar Decision Every Builder Faces
In today’s crypto world, where you choose to deploy your app is as important as the product itself.
This begs, what I believe to be, the billion dollar question in many builder’s minds right now:
Where is the best place to deploy my app?
In today’s post, I’ll present what I believe to be the best three options as of today, the pro’s and con’s of each, and why I believe upcoming tech improvements will make the choice easier than it is now.
The best three options for builders right now is to deploy on a general-purpose L2, Solana, or build an app-specific chain. Each of these decisions has far-reaching implications on performance, security, user experience, and long-term viability.
This post will delve into the technical differences between these options, framed by their respective pros and cons, and argue for the growing importance of app-specific chains as Ethereum’s competitive edge against Solana.
General-Purpose L2s/Rollups
Pros:
- Security Inheritance: General-purpose L2s or rollups, such as Optimism or Arbitrum, inherit the security of Ethereum. This means that applications built on these platforms benefit from Ethereum's robust security without having to maintain their own validator set. This is a massive factor for launching an application because bootstrapping your own economic security via a validator set (typically as an L1) is very difficult.
Not to mention, there are quite a few different universal L2s to choose from.
- Composability: General purpose L2s offer a high degree of composability, allowing seamless interactions with other applications and protocols on the same L2. “Money legos” is a term originally coined in DeFi Summer 2020 which still rings true today. One of the biggest advantages to building onchain is the composability.
You don’t get this in TradFi or in software outside of crypto. This is particularly advantageous for DeFi applications that rely on liquidity and interoperability.
- Easy For Devs: Building on general-purpose L2s (typically) means leveraging the EVM, which most crypto-native developers are already familiar with. This lowers the learning curve and speeds up development. In the case of altVM rollups, there are programming languages with more non-crypto native developer experience such as Rust (for stacks like Soon SVM), C, C++ (Arbitrum stylus), Move (Movement Labs and Lumio) Linux (Cartesi), Web assembly (Fluent) and even Sway from Fuel Network.
Cons:
- Congestion and Scalability Issues: As more applications are deployed on the same L2, congestion can become a problem, leading to higher fees and slower transactions. This could degrade user experience, particularly for applications that require low latency.
The “noisy neighbor” problem is a real one and we’ve seen it happen on L2s during liquidation periods or events with high frequency of user interactions. Again, this is a nuanced take where parallelizing the EVM like MegaETH, using based rollups, or a different execution environment as mentioned above can help mitigate this.
- Limited Customization & Monetization: General-purpose L2s are designed to cater to a broad range of applications, which means they often lack the flexibility to optimize for the specific needs of a single application. If you’re a builder who wants to have custom gas tokens, customized blocktimes, as well as transaction ordering rules, this is problematic. This could limit performance tuning and user experience optimization.
One big realization I’ve had is around MEV and sequencing revenue as well. When you deploy your app on a general purpose L2 and they do not offer revenue sharing, you are practically renting blockspace from the rollup operator and earning revenue for them, which could be redirected to your app and community. We’ll touch on this shortly.
App-Specific Chains
Pros:
- Full Customization: App-specific chains allow developers to optimize every aspect of the blockchain environment for their application's needs. This can result in higher performance, lower fees, and a better user experience.
You can internalize revenue from your own sovereign sequencer and control transaction ordering, offer lower fees and better experience for users via paymasters for gas, or advanced account abstraction solutions, or extremely fast block times (like Reya with 100ms blocktimes or Clearpool which just launched Ozean RWA focused appchain with a ton of unique features). By doing this, you unlock unique monetization methods for builders and users on your chain in a mutually beneficial way. More fees, transactions and usage leads to more sequencer revenue distribution for the entire community in whatever way you please.
- Scalability: Since the chain is dedicated to a single application or a suite of related applications, there's no risk of congestion caused by other projects. You get to own your blockspace and get rid of noisy neighbors (congestion) onchain. Less gas spikes. More control over your blockspace.
Cons:
- Complexity and Overhead: While RaaS providers like Gelato Network, Conduit, Caldera and others help to make launching a new chain easy, building and maintaining an app-specific chain requires more preparation and resources compared to deploying your app on a general-purpose L2 (deploying smart contracts vs. deploying an entire chain).
Teams like Layer Labs and other incubators can help here, but generally the process of launching a chain is more intensive. You have to think about interoperability providers from day one, sequencing (most RaaS provide some options here), and things like RPCs – although Lava Network could be helpful here.
- Interoperability Challenges: Although frameworks like Cosmos offer built-in interoperability solutions, interacting with the broader Ethereum L2 ecosystem can be more complex compared to using a general-purpose L2. As an appchain, your biggest question is going to be how you get users from day zero. Which interoperability provider is going to help and support you?
Think Hyperlane, Union Build, Jumper Exchange, LayerZero and eventually Omni & AggLayer. Coordinated blockbuilding will play a strong role too, teams like Astria and Nodekit.
Also, if you want to have solvers provide fast interoperability, you likely need a relationship with teams like Everclear, AcrossProtocol, LiFi Protocol, or some of the larger solvers like Wintermute. These challenges, paired with the annoyances of cross-chain UX pose the largest issue to launching an appchain.
I’ll touch more on this later.
Solana
Pros:
- Extremely Performant: Solana is designed for high-performance applications, with the capability to handle thousands of transactions per second with minimal latency (but transactions sometimes fail). The speed makes it an attractive option for applications which count on low latency and performance. These factors also extend into the UX which is undeniably good for any crypto user.
- Unified Experience: Solana’s single state machine is enticing from a composability POV. It makes building money legos far easier than on an appchain, but similar to launching on a general purpose L2. The architecture provides a unified environment where all apps share the same state, and you can siphon off network effects from successful apps like Kamino Finance and JupiterExchange.
- Ecosystem Trajectory: Solana’s ecosystem and developer growth has been up only. The ecosystem has strong support for DeFi, NFTs, and broader web3 applications, not to mention memecoins. Its developer community is also expanding due to being able to write in Rust, offering more resources and tools for new projects – as well as non-crypto native devs.
I think the ecosystem will continue to balloon and its likely your app would receive network effects of that expansion. See the ecosystem map below from earlier this year:
Cons:
- Centralization Risks: Despite its technical strengths, Solana has faced criticism for centralization. Its validator network is smaller compared to Ethereum with higher costs to get setup. There is less censorship resistance than building on Ethereum L1, but the difference between an L2 with a centralized sequencer is actually in favor of Solana imo. Still, the somewhat centralized nature of the chain is a byproduct of its infancy and is to be considered.
- Outages: Solana has experienced several network outages and stability issues, raising concerns about its reliability. It has always bounced back from this but is a risk for developers who need consistent uptime. This hasn't happened at all recently, which is a good sign.
The reasons presented above are as objective and neutral as possible, yet I still reach the conclusion of app-specific chains being in the middle of both general purpose L2s and Solana in terms of tradeoffs and performance.
I find this diagram to be quite helpful as well:
In my opinion, app-specific chains represent a viable strategy for the modular ecosystem to compete with monolithic L1s performance and developer experience. By allowing developers to build tailored environments optimized for their specific use cases, appchains can offer performance and flexibility that rivals or even surpasses these L1s.
However, its key to know that proper interoperability and chain abstraction are the keys to making this rollup-centric, modular expansion roadmap feasible. As new chains continue to launch the fragmentation problem only worsens.
Teams working on chain abstraction like Xion, Okto, Particle Network, NEAR Protocol, Halliday, Aarc, and others will play a big part here. Without this, and better interoperability solutions, the modular future is at risk.
To summarize:
While general-purpose L2s and Solana each offer compelling advantages, app-specific chains represent an opportunity for builders to monetize, specialize, and compete with the scale & composability of general purpose L2s, Solana, and other L1s.
As the modular ecosystem expands, app-specific chains will play a pivotal role in the growth of popular apps. However, this vision is strictly dependent on nailing a standard for interoperability solutions sooner than later.
I believe this will happen successfully and we will see a blossoming of app-specific rollups which are interconnected in the coming years.