Where Do L2 Network Effects Come From? What makes L2 sticky?

Author: Alana Levin; Compiler: Huohuo, vernacular blockchain

Two years ago, application developers faced a fairly simple choice when deciding where to deploy their applications: Ethereum, Solana, Cosmos, or perhaps some other layer 1 chain. Rollup is not yet in use, and few people have heard the term “modular stack”. The differences between L1s (throughput, cost, etc.) are obvious and relatively easy to grasp.

**Things look very different today. Application developers are faced with more choices: L1, generic rollups (Optimistic and zk), advanced IBC infrastructure, Rollups-as-a-service providers, application chains, and more. **

More options bring more questions, including: should teams deploy to generic rollups or build application-specific rollups? If you choose general rollup, which one to choose? If they go the app rollup route, which SDK/rollup-as-a-service to use? Which data availability tier to choose? Can EigenLayer help? How to think about sequencers? If they choose to go the OP Stack route, will there be a colorful sphere emoji left in Optimism’s superchain ecosystem? These questions are tricky.

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 the focus will be on the decision tree that application teams face in determining whether to launch their own rollup, the assumptions about what types of applications are particularly suitable for this infrastructure, and when I think we might reach a tipping point for adoption.

1. High-level framework

At the heart of an app rollup decision is actually a simple question: **if the app was on its own chain, would users still use the app? **There are two subsets of this question:

1) Are users more likely to use an app if it is on its own chain?

2) If the application is on its own chain, is it equally possible for the user to use the application?

Application-specific rollup benefits stem from greater control: Ability to extract gas costs, limit on-chain congestion caused by other application activity, better experiment with how tokens are utilized, explore different economic structures (such as integrated gas rebates), build custom execution environments, implement access controls (such as permission deployment), and more.

** But this extra control comes at the cost of connectivity to the larger ecosystem. **Apps on a shared/universal chain have access to liquidity already on that chain (e.g. without additional bridges between chains), composability with other apps, and users already dedicated to that chain attention. Building on a common chain also requires less internal engineering work/overhead than an application running its own chain.

Better controls might enhance the user experience if it were free. So the answer to the core question — whether users would still use an app if it was on its own chain — really depends on how severe this control vs. connection tradeoff is. **

2. How many connections can the application afford to lose?

Connections come in many forms. The two most important are: 1) Attention, and 2) Capital.

** Note the native distribution. If the team’s project is the first thing users engage with when they enter the ecosystem, it’s a compelling case for the app to have a native distribution. ** Attention-controlling apps are better suited for starting their own chain; users will use that app regardless of which chain it exists on. In my opinion, current examples of apps that have a native distribution include Mirror, Zora, Manifold, Sound.xyz, and OnCyber. There is also an argument that applications without a strong distribution may choose to launch their own chains to spark interest.

The second component of “connectivity” is capital. Often, funds deployed by users for one app are reclaimed from another app in the same ecosystem. I call it “shared liquidity,” and its implications are real. We’ve seen new applications choose one general-purpose rollup over another because of the larger amount of ETH bridged to the ecosystem; existing capital within the ecosystem can help remove barriers to user adoption (rather than Trying to convince users to enter a new ecosystem). These considerations are relevant for any application that embeds some form of financialization into its product. Examples outside of pure DeFi might include collecting NFT articles via Mirror, paying to “steal” images on a Stealcam, or anything with an in-product tipping feature.

**Loss of this “fund connectivity” means applications need to force users to park their inventory on-chain. ** One reason may be that consumers use the app a lot - the bridging experience is painful, so it will be easier to maintain a healthy supply of funds on-chain. But even more convincing than idle inventory is giving users options that generate revenue. This might look like a chain-native form of yield, an application building an adjacent product that provides yield (like Blur’s lending protocol), or something else.

The above reasons (attention and capital) are also why many see on-chain games as ideal candidates for application-specific rollups: they are fairly self-contained economies, control the mind share of consumers, and are a sort-and-avoid Congestion is a category that is both important to a pleasant user experience.

In other words, on-chain games benefit from a high degree of control and are not significantly affected if they are isolated. Other apps that are well-suited for app rollup might do so by subsidizing transactions (e.g., the first few transactions are free) or requiring no payment at first (e.g., user-generated on-chain content, certain social apps, DePIN networks, etc.) Minimize upfront user capital requirements.

Of course, there are other reasons why projects want more control over their infrastructure. Having a rollup introduces permission to deploy or the ability to implement user screening requirements (such as KYC on chain owned/operated sequencers). In these cases, however, the line between rollup databases and centralized databases becomes less and less clear.

3. Minimize connection loss

As interoperability solutions improve, the connectivity versus control tradeoff becomes less critical. **Bridges and sequencers are often the critical infrastructure discussed in this question. 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. A shared orderer does this by ingesting and ordering transactions from multiple chains, creating a coordination mechanism that enables actions on one chain to affect actions on another. Atomic composability requires shared sequencers and bridges - the sequencer is guaranteed to contain multiple (cross-domain) 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 are made up of two factors: 1) the cost of publishing data to L1, and 2) the cost users pay for inclusion. **Rollup operator batches call data for transactions, enabling publishing costs to be spread across users - the more transactions, 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 size. The consequence is a slower finalization time and a worse 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 the existence of the long tail.

4. Are we at an inflection point?

The idea of application chains and application rollups is 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’ve started to see the first influx of residents. Lattice built OpCraft, an on-chain autonomous world backed by its own rollup. Projects like Lit Protocol and Synapse have announced their own rollups (though both are more infrastructure rather than application oriented). Zora launched Zorachain. Recent conversations with more mature application layer teams (especially those considering L2 strategies) have begun to explore whether application rollup is 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: social and gaming both rely heavily on indexing (and benefit greatly by not having to compete with shared state), ordering issues (especially in gameplay) and custom features (like gasless transactions) are especially useful for entertainment-oriented consumer products**. Many of these application teams are still under construction. Games, in particular, can take years to develop and release.

My other takeaway is that attention grabbing is the most critical factor for less financial apps. So far this article has defined application rollups as “one application per rollup”. But this view may be too narrow. Perhaps multiple applications decide to form a collective, pool their “attention”, and start a chain together. Likewise, we could 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 test adoption of the infrastructure it wants to control.

Finally, I very much believe that we will see more rollups in the future. There has been a proliferation of projects building infrastructure services for application rollups. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. provide low lift solutions for teams to start their own Rollup.

Espresso, Astria, and Flashbots’ SUAVE are some of the early entrants in the sequencer space. Setup costs are trending down, and the “connectivity” tradeoff becomes less severe. Both reinforce the case for adoption. **But such a large number of new infrastructure providers also means that application teams may take the time to understand the various options and put these various players to the test of battle before choosing a winner. **Again, while there are signs of adoption, I think the inflection point is still a few months away.