Application-Specific Rollups: A Trade-off Between Connectivity and Control

An Overview Framework

The core question of whether to use an application-specific Rollup is actually a simple one: If the application runs on its own chain, will users still use it? This question has two sub-questions:

If the application runs on its own chain, are users more likely to use it?
If the application runs on its own chain, do users still have the same likelihood of using it?

The benefits of an application-specific Rollup stem from greater control: the ability to abstract gas costs, limit on-chain congestion caused by other application activities, better experimentation with token usage, exploring different economic structures (e.g., providing gas rebates for integrations), building customized execution environments, implementing access controls (e.g., permissioned deployments), and more.

But this increased control comes at the cost of connectivity with the larger ecosystem. Applications on shared/general chains can benefit from the existing liquidity on that chain (e.g., no need for additional cross-chain bridging), composability with other applications, and the attention of users who are already focused on that chain. Building on a general chain also requires less internal development work compared to an application running on its own chain.

If greater control comes with no cost, it is likely to enhance the user experience. Therefore, the answer to the core question—if the application runs on its own chain, will users still use it—really depends on the trade-off between this control and connectivity.

Application-Specific Rollups: The Trade-off Between Connectivity and Control

How Much Connectivity Can Applications Afford to Lose?

Connectivity comes in several forms. The two most important are: first, attention, and second, capital.

Attention is a form of native attraction. If a team's project is the first thing users encounter when entering the ecosystem, there is good reason to believe that the application has a native ability to attract attention. Applications that control attention are better suited to launch their own chains, as users will use them regardless of which chain they exist on. In my view, current examples of applications with native attraction include Mirror, Zora, Manifold, Sound.xyz, and OnCyber. There is also a perspective that applications without strong attraction may choose to launch their own chains as an effort to stimulate interest (although I believe this approach is less convincing if many chains take this route simultaneously).

The second component of "connectivity" is capital. Typically, the funds users deploy to an application are recouped from another application within the same ecosystem. I call this "shared liquidity," and its impact is real. We have seen new applications choose one general-purpose Rollup over another because more ETH was bridged to that ecosystem. Existing capital within the ecosystem can help eliminate barriers to user adoption (as opposed to trying to persuade users to bridge to a new ecosystem). These considerations are relevant for any application that embeds some form of financialization into its product. Examples beyond pure DeFi might include collecting NFT articles through Mirror, paying to "steal" images on Stealcam, or any application with a tipping feature within the product.

Losing this "capital connectivity" means that applications need to persuade users to deposit their assets on-chain. One reason might be that consumers frequently use the application—bridging is painful, so the simplest way is to maintain enough capital supply on-chain. But more persuasive than idle inventory is offering users options to generate yield. This could look like chain-native yield forms, applications building adjacent yield-generating products (e.g., Blur's lending protocol), or other means.

The above reasons—attention and capital—are also why many believe on-chain games are ideal candidates for application-specific Rollups: they are relatively independent economies that control consumer mindshare, and sequencing is crucial for a pleasant user experience in avoiding congestion. In other words, on-chain games can benefit from independent chains without being severely affected even if they are isolated. Other applications suitable for application Rollups might minimize users' initial capital requirements by subsidizing transactions (e.g., the first few transactions are free) or not requiring payment during onboarding (e.g., user-generated on-chain content, certain social applications, DePIN networks, etc.).

Of course, there are other reasons projects want more control over their infrastructure. Having a Rollup introduces the ability to implement permissioned deployments or user screening requirements (e.g., KYC for sequencers that own/operate the chain). However, in these cases, the line between Rollup and centralized database becomes increasingly blurred.

Minimizing Connectivity Loss

As interoperability solutions improve, the trade-off between connectivity and control becomes less severe. Bridging and sequencers are often the key infrastructures discussed in this area. They are somewhat similar in that they both provide a way for transactions on one chain to affect transactions on another chain. Bridging achieves this by passing messages or enabling asset transfers. Shared sequencers achieve this by absorbing and ordering transactions from multiple chains, creating a coordination mechanism that allows actions on one chain to impact actions on another chain. Both shared sequencers and bridging are necessary for atomic composability—sequencers ensure the inclusion of multiple (cross-domain) transactions in a block, while bridging is often essential for executing those transactions.

The unit economics of Rollups is another area where "connectivity" has a significant impact. Layer 2 (L2) transaction fees consist of two parts: 1) the cost of posting calldata to L1, and 2) the cost users pay to be included. Rollup operators batch process the calldata of transactions, allowing the posting costs to be shared among users—the more transactions there are, the lower the average cost per user. This also means that less active Rollups may delay posting transactions to L1 until they have a sufficiently large batch. The consequence is slower finality times and a worse user experience. It seems that shared sequencers are increasingly becoming aggregation layers 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 chains and application Rollups are not new. However, for a long time, it felt like a residential area under development: a lot of infrastructure was being built, but there were no residents. But in recent months, we have begun to see the first residents slowly moving in. Lattice has built OpCraft, an on-chain autonomous world supported by its own Rollup. Projects like Lit Protocol and Synapse have announced their own Rollups (although both are more infrastructure than application-oriented projects). Zora launched Zorachain. Recently, in conversations with some mature application layer teams, particularly those considering their Layer 2 strategies, I found that they are beginning to explore whether application Rollups are suitable for them.

My hypothesis is that the real turning point will come in (at least) 6-12 months (as of the publication date of this article on June 30, 2023). Games and social applications match application-specific Rollups most clearly: both social and gaming heavily rely on indexing (and benefit greatly from not having to compete with shared state), sequencing is particularly important in gameplay, and customized features (like gasless transactions) are especially useful for entertainment-oriented consumer products. Many of these application teams are still in development. Particularly in gaming, it may take years to fully develop and launch.

My other conclusion is that for applications with lower degrees of financialization, 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. Perhaps multiple applications decide to form a collective, pooling their "attention" and jointly launching a chain. Similarly, we may see a major application decide to build its own chain and encourage other applications to deploy on it—effectively using its application to practice the adoption of the infrastructure it wants to control.

Finally, I do believe we will see more Rollups emerge in the future. Projects building infrastructure services for application Rollups have exploded in growth. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, and others provide low-barrier solutions for teams to quickly launch their own Rollups. Early entrants in the sequencer space include Espresso, Astria, and Flashbots' SUAVE. The cost of building is decreasing, and the severity of the "connectivity" trade-off is also diminishing. Both of these factors 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 let these different participants undergo the test of battle before choosing a winner. Therefore, while the signs point toward adoption, I believe the real turning point is still several months away.

ChainCatcher reminds readers to view blockchain rationally, enhance risk awareness, and be cautious of various virtual token issuances and speculations. All content on this site is solely market information or related party opinions, and does not constitute any form of investment advice. If you find sensitive information in the content, please click "Report", and we will handle it promptly.