Under the trend of modularity, should applications build their own chains?

Should apps create their own chains under modularity?

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

Two years ago, application developers faced a fairly simple choice when deciding where to deploy their applications on a blockchain: Ethereum, Solana, Cosmos, or another Layer 1 blockchain. At that time, Rollups had not yet launched their mainnets, and few had heard of the term “modular stack”. The differences between L1s (throughput, fees, etc.) were very clear and relatively easy to understand.

Today’s situation looks very different. Application developers are faced with more choices: L1, general Rollups (Optimistic and zk), IBC infrastructure, Rollup as a service providers, application chains, and more. More choices bring more questions: should teams deploy their applications to general Rollups or build specific application Rollups? If they choose a general Rollup, which one should they choose? If they go the application Rollup route, which SDK/Rollup as a service to use, which data availability layer to choose, whether EigenLayer can help, and how to consider the sequencer; if they choose to go with the OP stack, can they have a place in the Optimism superchain ecosystem?

To narrow the scope of the problem, this article will use the framework of an application deployed on Ethereum that hopes to scale in the Ethereum ecosystem. Therefore, the focus of this article will be 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 for adoption.

• Web3 Industry Survival Guide: 5 Simple to Unimaginable Ways to Prevent Sudden Death and Fight Depression
• a16z’s latest revelation: How successful startups attract top talent
• Aura Finance: Why choose to drive LST liquidity growth on Optimism?

High-level Framework

The core of the application Rollup decision is actually a simple question: will users still use it if the application is built on its own chain? To further expand, there are two questions:

• Are users more likely to use the application if it is on its own chain?

• Will users still use the application if it is on its own chain?

The advantage of a specific application Rollup is better control: the ability to abstract Gas costs, limit on-chain congestion caused by other application activities, better experimentation with token utilization, exploration of different economic structures (such as Gas rebates), building custom execution environments, implementing access control (such as permission deployment), and more.

However, the cost of this additional control is the loss of connectivity with a larger ecosystem. Applications on a general-purpose chain can access existing liquidity on the chain (for example, no need for additional bridging between chains), composability with other applications, and user attention on the chain. Building on a general-purpose chain saves a lot of engineering expense compared to running your own chain.

If it is free, better control may enhance the user experience. Therefore, the answer to the core question-whether users will still use the application if it is on their own chain-actually depends on the trade-off between this control and connectivity.

How much connectivity can the application sacrifice?

There are various forms of connectivity, the two most important of which are: 1) Attention, 2) Capital.

Attention is related to native propagation. If a team’s project is the project that users must first participate in when entering the ecosystem, it means that the application has native propagation. Applications that can control attention are more suitable for launching their own chains; users will use the application no matter which chain the application is on. In my opinion, current applications with native propagation include Mirror, Zora, Manifold, Sound.xyz, and OnCyber. Another view is that applications without strong propagation may choose to launch their own chains to stimulate user interest (but I found that if many chains are pursuing this route at the same time, it is not so eye-catching).

The second form of connectivity is capital. Usually, the funds deployed by users on an application are transferred from another application in the same ecosystem. I call it “shared liquidity”, and its impact is real. Many new applications choose a general Rollup because more ETH is bridged to the ecosystem, and existing capital in the ecosystem can help eliminate user adoption barriers (rather than trying to persuade users to enter a new ecosystem). These factors need to be considered for any application that embeds some form of financialization into its product. Examples outside of DeFi may include: collecting NFT papers through Mirror, “stealing” images on Stealcam for a fee, or anything with an in-product tipping function.

Losing this “funding connectivity” means that applications need to force users to park funds on the chain. One reason may be that consumers frequently use the application, after all, cross-chain is painful, so it is easier to maintain a healthy supply of funds on the chain. But more convincing than idle funds is to provide users with choices that generate income. This looks like the native form of income, applications that build adjacent products that provide income (such as Blur’s lending protocol), etc.

Attention and capital are also reasons why many people consider chain games to be ideal candidates for specific application Rollups: they are relatively independent economic entities and rely heavily on smooth user experience. In other words, on-chain games benefit from a high degree of control and even if they are isolated, they will not suffer significant losses. Other applications that are very suitable for Rollup applications may minimize the initial user capital requirements by subsidizing transactions (such as the first few transactions are free) or not requiring payment at login (such as user-generated on-chain content, some social applications, DePIN network, etc.).Of course, there are other reasons why projects hope to have more control over their infrastructure. Proprietary Rollup implementations provide the ability to deploy licenses and screen users (such as KYC for chains owned/operated). However, this also blurs the boundary between Rollup databases and centralized databases.Minimizing connectivity lossAs interoperability solutions improve, the trade-off between connectivity and control becomes less important. Bridges and sorters are often key infrastructure discussed. They are somewhat similar because both provide a way for transactions on one chain to affect transactions on another chain. The bridge achieves this by passing messages or enabling asset transfers, while the shared sorter achieves this by ingesting and sorting transactions from multiple chains. Shared sorters and bridges are both necessary for atomic composability – the sorter ensures that multiple (cross-chain) transactions are included in a block, and the actual execution of these transactions usually requires a bridge.The unit economics of Rollups are 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 paid by users for transactions. Rollup batch processes transaction call data, allowing publishing costs to be shared among users: the more transactions, the lower the average cost per user. This also means that Rollups with lower activity levels may delay publishing transactions to L1 until they have a sufficiently large transaction package. The consequence is slower final confirmation time and poor user experience. Shared sorters seem to be increasingly becoming aggregation layers where batch processing of transactions from multiple smaller Rollups can help create viable unit economics for long-tail individuals.

Are we at an inflection point?

The ideas of application chains and application rollups are not new. However, for a long time, it felt like a residential area under development: a lot of infrastructure is being built, but there are no residents. In recent months, we have seen the first wave of residents moving in. Lattice has built OpCraft, an on-chain autonomous world supported by its own rollup; Lit Protocol and Synapse have announced their own rollups (although both are more infrastructure-oriented than application-oriented projects); Zora has 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 hypothesis is that the real inflection point will come (at least) 6 to 12 months later. Games and social applications have the most obvious product market fit with specific application rollups: social and games rely heavily on indexing, sorting issues (especially in gameplay), and custom features (like gasless transactions) are particularly important for entertainment and consumer products. Many application teams are under construction, especially games, which may take years to develop and release.

My other takeaway is that for applications with lower levels of financialization, the key is to attract attention. So far, this article has defined application rollups as “each rollup corresponds to an application.” But this view may be too narrow. Maybe multiple applications make up a collective and jointly launch a chain. Similarly, we can see an application building its own chain and encouraging other applications to deploy on it.

Finally, I firmly believe that we will see more rollups in the future. Projects that build infrastructure services for application rollups will explode. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. provide low-threshold solutions for application teams to launch their own rollups. SUAVE of Espresso, Astria, and Flashbots is a group of early explorers in the sorter field. Launch costs are trending down, and “connectivity” trade-offs are becoming less important. But so many new infrastructure providers also mean that application teams may spend time understanding various options and that a war will break out between these participants. Once again, although the signs indicate that people are adopting, I believe the inflection point will take a few more months.

Thank you 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.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!