Two years ago, application developers faced relatively simple choices when deciding which chain to deploy their applications on: Ethereum, Solana, Cosmos, and perhaps a few other Layer 1 chains. At that time, Rollups was not yet operational and few people had heard of the term “modular stack.” The differences (throughput, fees, etc.) between these L1 chains are very obvious and relatively easy to understand.
Today, things look very different. Application developers are faced with more choices: L1 chain, universal Rollups (including op and zk), advanced IBC infrastructure, Rollup as a service provider, application chain, etc. As the choices increase, so do the questions, including:
Should teams deploy to a generic rollup or build application-specific rollups?
If you choose a universal rollup, which one should you choose?
If you go the application rollup route, which SDK/Rollup as a service to use?
Which data availability tier to choose?
Is EigenLayer helpful?
How to think about sequencers?
If you choose the OP Stack route, will there still be Colorful Orb Emoticons in Optimisms Superchain ecosystem?
It’s all overwhelming!
To narrow down the problem, this post will be from the perspective of an application already deployed on Ethereum and looking to expand within the Ethereum ecosystem. Therefore, the focus will be on the decisions application teams face when deciding whether to roll out their own Rollup, which types of applications are particularly suitable for this infrastructure, and when we may reach the tipping point of adoption.
an overview framework
At its core, deciding whether to use application-specific rollups is actually a simple question:If the app runs on its own chain, will users still use it?? This question has two sub-questions:
Are users more likely to use an app if it runs on its own chain?
If the app runs on its own chain, are users still as likely to use it?
The benefits of application-specific rollups stem from greater control: the ability to abstract gas costs, limit on-chain congestion caused by other application activity, better experiment with how tokens are used, explore different economic structures (e.g., provide support for integrations gas rebates), build custom execution environments, implement access controls (e.g., permissioned deployment), and more.
But this increased control comes at the cost of connectivity to the larger ecosystem. Applications on a shared/universal chain can enjoy the liquidity already on that chain (e.g., no need for additional inter-chain bridging), composability with other applications, and the attention of users already focused on the chain. Building on a universal chain also requires less internal development work than an application running its own chain.
If greater control comes at no cost, its likely to enhance the user experience. So the answer to the core question - would users still use the app if it ran on its own chain -It really comes down to how much of that control vs. connectivity tradeoff。
How much loss of connectivity can the application tolerate?
Connectivity comes in several forms. The two most important ones are:One is attention, and the other is capital.
Attention is a natural attraction that comes with it. If a team’s project is the first thing users encounter when entering the ecosystem, there’s good reason to think that the app has a native ability to grab attention. Applications that control attention are better suited to launch their own chain, and users will use it no matter which chain the application exists on. In my opinion, current examples of apps with native appeal include Mirror, Zora, Manifold, Sound.xyz, and OnCyber. There is also the argument that applications without strong attraction capabilities may choose to launch their own chain as an effort to stimulate interest (although I find this approach less convincing if many chains take this route at the same time).
The second component of “connectivity” is capital. Often, the funds a user deploys for one app are recycled from another app within the same ecosystem. I call it shared liquidity and its impact is real. Weve seen new applications choose one universal rollup over another because more ETH is bridged into that ecosystem. Existing capital within the ecosystem can help remove barriers to user adoption (as opposed to trying to convince users to bridge to a new ecosystem). These considerations are relevant for any application that embeds some form of financialization into its products. Examples outside of pure DeFi might include collecting NFT articles via Mirror, paying to steal pictures on Stealcam, or any app with an in-product tipping feature.
Losing this “capital connectivity” means applications need to convince users to store future assets on-chain. One reason could be that consumers use the app frequently - bridging is painful, so the easiest thing to do is to keep a sufficient supply of capital on-chain. But even more compelling than idle inventory is giving users the option to generate revenue. This might look like a form of chain-native yield, applications building adjacent yield-providing products (such as Blur’s lending protocol), or other means.
The above reasons – attention and capital – are also the reasons why many consider on-chain games to be ideal candidates for application-specific rollups: they are fairly independent economies, control consumers’ share of mind, prioritize ordering and avoid congestion. Aspects are very important for a pleasant user experience. In other words, on-chain games can benefit from independent chains and will not be severely affected even if they are isolated. Other applications suitable for Rollup may minimize the users initial capital requirements through subsidized transactions (e.g., the first few transactions are free) or do not require payment at the time of onboarding (e.g., user-generated on-chain content, certain social applications, DePIN network, etc.).
Of course, there are other reasons why projects want more control over their infrastructure. Having a Rollup introduces the ability to license deployment or enforce user screening requirements (e.g. KYC for chain owned/operated sequencers). However, in these cases, the line between Rollup and centralized databases becomes increasingly unclear.
Minimize connectivity loss
As interoperability solutions improve, the connectivity versus control tradeoff becomes less severe. Bridges and sequencers are often the critical infrastructure discussed in this area. They are similar to some extent in that they both provide a way for transactions on one chain to affect transactions on the other chain. Bridges do this by passing messages or enabling the transfer of assets. A shared sequencer does this by absorbing and sequencing transactions from multiple chains, creating a coordination mechanism that allows actions on one chain to affect actions on another chain. Both shared sequencers and bridges are required for atomic composability - sequencers guarantee the inclusion of multiple (cross-domain) transactions in a block, and bridges are often required to execute these transactions.
Rollups unit economics are another area where connectivity has a significant impact. Layer two (L2) transaction fees consist of two components: 1) the cost of publishing calldata to L1, and 2) the cost that users pay in order to be included. The rollup operator batches the calldata of transactions so that publishing costs can be spread among users - the more transactions, the lower the average cost per user. This also means that rollups with low activity may delay publishing transactions to L1 until they have a large enough batch size. The consequences are slower finality times and a worse user experience. It seems that shared sorters are increasingly becoming an aggregation layer, where batching transactions from multiple smaller rollups can help create viable unit economics for the long tail.
Are we at a turning point?
The concepts of application chaining and application rollup are not new. Yet for a long time it looked like a residential complex under development: lots of infrastructure being built, but no residents. But in recent months, we’ve started to see the first residents trickle in. Lattice built OpCraft, an on-chain autonomous world powered by its own Rollup. Projects like Lit Protocol and Synapse announced their own rollups (although both are more infrastructure than application-oriented projects). Zora launches Zorachain. Recently chatting with some mature application layer teams, especially those considering their second layer strategy, I found that they are starting to explore whether applying Rollup is suitable for them.
My hypothesis is that the real turning point will come in (at least) 6-12 months (this article was published on 2023.6.30). Gaming and social apps are the most obvious candidates for app-specific rollups: both social and gaming rely heavily on indexing (and benefit greatly from not having to compete with shared state), sorting is particularly important in gameplay, custom features like no gas transactions) are particularly useful for entertainment-oriented consumer products. Many of these application teams are still under construction. Games, in particular, can take years to fully develop and launch.
My other conclusion is that for less financialized applications, having attention is the most critical factor. So far, this article has framed application rollups as one application per Rollup. But this view may be too narrow. Maybe multiple applications decide to form a collective, pool their attention, and launch a chain together. Likewise, we might see a major application decide to build its own chain and encourage other applications to deploy on it—in effect, using its own application to practice adoption of the infrastructure it wants to control.
Finally, I do believe we will see more Rollups in the future. Projects building infrastructure services for Rollup applications have exploded. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. provide low-threshold solutions for teams to quickly start their own Rollup. Espresso, Astria and Flashbots SUAVE were early entrants in the sequencer space. Construction costs are falling, and so are the severity of the “connectivity” trade-offs. Both points strengthen the case for adoption. However, the emergence of a large number of new infrastructure providers also means that application teams may take time to understand the various options and put these various players through the battle before choosing a winner. So while signs point in the direction of adoption, I think the real turning point is still many months away.
