Under the trend of modularization, should the application build its own chain?

Written by: Alana Levin; Compiled by: Luffy, Foresight News

Two years ago, application developers faced a fairly simple choice when deciding which chain to deploy their application on: Ethereum, Solana, Cosmos, or another Layer 1 blockchain. At that time, Rollup had not yet launched the main network, and few people had heard of the term "modular stack". The differences between L1s (throughput, fees, etc.) are obvious and relatively easy to understand.

Things look very different today. Application developers are faced with more choices: L1, general-purpose Rollup (Optimistic and zk), IBC infrastructure, Rollup-as-a-service provider, AppChain, and more. More options bring more questions: should teams deploy applications to generic rollups, or build application-specific rollups. If they go the generic Rollup, which one to choose; if they go the app Rollup route, which SDK/Rollup-as-a-service to use, which data availability layer to choose, can EigenLayer help, how to think about sequencers; if they choose Taking the route of OP Stack, whether it can occupy a place in Optimism's super chain ecosystem.

To narrow down the problem, this article will adopt the framework of an application already deployed on Ethereum that wishes to scale within the Ethereum ecosystem. So this article will focus on the decision tree that application teams face when deciding whether to launch their own rollup, which types of applications are particularly suitable for certain types of infrastructure, and when I think we may reach the tipping point of adoption.

High Level Framework

At the heart of the application rollup decision is actually a simple question: If the application were built on its own chain, would users still use it? Further development is two questions:

• Are users more likely to use an application if it is on its own chain?
• If the application is on its own chain, will users use it as well?

The benefits of application-specific rollups are better control: the ability to abstract gas costs, limit on-chain congestion caused by other application activity, better experiment with how tokens are utilized, explore different economic structures (e.g. gas rebates), build Customize the execution environment, implement access controls (such as permission deployment), and more.

But the price of this extra control is a loss of connectivity to the wider ecosystem. Applications on a universal chain have access to the liquidity already on that chain (e.g., no need for additional bridges between chains), composability with other applications, and on-chain user attention. Compared with applications that run their own chains, building on the general chain also saves a lot of engineering overhead.

Better control might enhance the user experience if it were free. So the answer to the core question — whether users would still use an application if it was on its own chain — really depends on this trade-off of control versus connectivity.

**How much connectivity can an application sacrifice? **

Connections come in many forms, the two most important being: 1) attention, and 2) capital.

Attention is related to native communication. If a team's project is the first project users engage with when they enter the ecosystem, then the app is natively viral. Apps that can command attention are better suited to launching their own chain; users will use the app no matter which chain the app is on. In my opinion, the current apps with native propagation include Mirror, Zora, Manifold, Sound.xyz, and OnCyber. There is also an argument that apps without strong dissemination may choose to launch their own chains in order to spark user interest (but I find this less compelling if many chains are pursuing this route at the same time).

The second form of connectivity is capital. Often, the funds that users deploy on one application are transferred from another application in the same ecosystem. I call it "shared liquidity," and its implications are real. A large number of new applications choose Universal Rollup because of the large amount of ETH bridged to this ecosystem, and existing capital within the ecosystem can help remove barriers to user adoption (instead of trying to convince users to enter a new ecosystem). These factors are considerations for any application that embeds some form of financialization into its product. Examples outside of DeFi might include: collecting NFT papers via Mirror, paying to "steal" images on a Stealcam, or anything with an in-product tipping feature.

Losing this "fund connectivity" means that applications need to force users to park funds on-chain. One reason could be that consumers use the app a lot, cross-chains are painful after all, so it would be easier to maintain a healthy supply of funds on-chain. But even more compelling than idle funds is giving users the option to generate yield. This looks like yield in the form of chain-natives, applications building adjacent products that provide yield (like Blur's lending protocol), and more.

Attention and capital is also why many see on-chain games as ideal candidates for application-specific rollups: they are fairly self-contained economies and rely heavily on a smooth user experience. In other words, on-chain games benefit from a high degree of control and do not suffer significant losses if they are orphaned. Other applications that are well-suited for Rollup might do so by subsidizing transactions (e.g. the first few transactions are free) or requiring no payment upon login (e.g. user-generated on-chain content, certain social apps, DePIN networks, etc.) Minimizes upfront user capital requirements.

Of course, there are other reasons why projects want more control over their infrastructure. Proprietary Rollups enable the ability to deploy permissions and screen users (e.g. KYC for chain owned/operated sequencers). However, this also leads to blurring of the line between Rollup databases and centralized databases.

Minimize Connectivity Loss

As interoperability solutions improve, the connectivity-versus-control tradeoff becomes less important. Bridges and sequencers are often the critical infrastructure that is discussed. They are somewhat similar in that both provide a way for transactions on one chain to affect transactions on another chain. Bridges do this by passing messages or enabling asset transfers, shared orderers do this by ingesting and ordering transactions from multiple chains. Both shared orderers and bridges are necessary for atomic composability - the orderer is guaranteed to contain multiple (cross-chain) transactions in a block, and the actual execution of these transactions usually requires a bridge.

The unit economics of Rollups is another area where "connectivity" has an impact. L2 transaction fees consist of two parts: 1) the cost of publishing data to L1, and 2) the cost that users pay for the transaction. Rollup batches transaction call data so that the cost of publishing can be shared among users: the more transactions, the lower the average cost per user. This also means that less active Rollups may delay publishing transactions to L1 until they have a sufficiently large transaction package. The consequence is slower finalization times and poor user experience. Shared orderers appear to be increasingly serving as aggregation layers, where batching transactions from multiple smaller rollups can help create viable unit economics for long-tail individuals.

**Are we at an inflection point? **

The idea of application chains and application rollups is not new. For a long time, however, it felt like a residential area under development: lots of infrastructure was being built, but without any residents. In recent months, we have begun to see an influx of first residents. Lattice built OpCraft, an on-chain autonomous world backed by its own rollup; Lit Protocol and Synapse have announced their own Rollup (though both are more infrastructure-oriented than application-oriented projects); Zora launched Zorachain. Recent conversations with mature application teams (especially those considering L2 strategies) have begun to explore whether application rollups are right for them.

My assumption is that the real inflection point will come in (at least) 6-12 months. Gaming and social apps have the most obvious product-market fit with app-specific Rollups: both social and gaming rely heavily on indexing, ordering issues (especially in gameplay) and custom features (like gas-free transactions) for recreational consumption Products are very important. Many application teams are under construction, especially games, which can take years to develop and release.

My other takeaway is that for less financial apps, the most critical thing is to attract attention. So far, this article has defined application Rollups as "one application per Rollup". But this view may be too narrow. Perhaps there are multiple applications forming a collective to start a chain together. Likewise, we can see an application build its own chain and encourage other applications to deploy on top of it.

Finally, I firmly believe that we will see more Rollups in the future. Projects building infrastructure services for application rollups will proliferate. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. provide application teams with low-threshold solutions to start their own Rollup. Espresso, Astria, and Flashbots' SUAVE were some of the early explorers in the sequencer space. Start-up costs are trending down, and the “connectivity” tradeoff becomes less important. But such a large number of new infrastructure providers also means that application teams may take time to understand the various options, and a war will break out between these players. Again, while there are signs of adoption, I think the inflection point is still a few months away.

Thanks to Devloper, Jill Gunter, Kyle Samani, Jason Maier, Cem Ozer, and Viktor Bunin for their feedback, comments, and conversations that helped develop many of these ideas.