Where does the network effect of L2 come from? What makes L2 sticky?

Author: Alana Levin; Translation: Huohuo, Plain-Language Blockchain

Two years ago, application developers faced a rather simple choice when deciding where to deploy their applications: Ethereum, Solana, Cosmos, or perhaps some other layer 1 chains. Rollups had not yet been deployed, and few had heard of the term “modular stack.” The differences between L1s (throughput, fees, etc.) were very clear and relatively easy to grasp.

Today, the situation appears to be quite different. Application developers are faced with more choices: L1s, general rollups (Optimistic and zk), advanced IBC infrastructure, rollup-as-a-service providers, application chains, and so on.

More choices bring more questions, including: should teams deploy to a general rollup or build a rollup specific to their application? If choosing a general rollup, which one should they choose? If they go the application aggregation route, which SDK/rollup-as-a-service should they use? Which data availability layer to choose? Can EigenLayer provide assistance? How to think about sequencers? If they choose the OP Stack route, will there be a colored ball emoji left in the Optimism superchain ecosystem? These questions are all tricky.

To narrow down the scope, this article will adopt a framework of an application already deployed on Ethereum, which hopes to scale within the Ethereum ecosystem. Therefore, the focus will be on the decision tree that application teams face when determining whether to launch their own rollup, assumptions about which types of applications are particularly suitable for this infrastructure, and when we might reach the tipping point for adoption.

1. High-level Framework

The core of the decision for application rollups is actually a simple question: Will users still use the application if it is on its own chain? This question has two subsets:

1) If the application process is on its own chain, are users more likely to use the application process?

2) If the application process is on its own chain, are users equally likely to use the application process?

The benefits of a specific application rollup come from better control: the ability to extract gas costs, limit on-chain congestion caused by other application activities, better experimentation with token utilization, exploration of different economic structures (such as integrated gas rebates), building custom execution environments, implementing access control (such as permission deployment), and so on.

But this additional control comes at the cost of being connected to a larger ecosystem. Applications on shared/general chains can access the existing liquidity on that chain (e.g., without the need for additional bridging between chains), composability with other applications, and the user attention already focused on that chain. Building on a general chain requires less internal engineering work/expenses compared to running their own chain.

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

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

There are multiple forms of connections. The two most important ones are: 1) attention, and 2) capital.

Note that native distribution is essential. If the team’s project is the first thing users engage with when entering the ecosystem, then the application process has native distribution, which is a convincing case. Applications that control attention are better suited to launch their own chain; users will use the application process regardless of which chain it exists on. In my opinion, examples of application processes with native distribution currently include Mirror, Zora, Manifold, Sound.xyz, and OnCyber. There is also an argument that application processes without strong distribution may choose to launch their own chains to drive interest.

The second component of “interconnectivity” is capital. Typically, the funds that users deploy for one application are recycled from another application within the same ecosystem. I call this “shared liquidity,” and its impact is real. We have seen new applications choose one common rollup over another because there is more ETH bridged to that ecosystem; existing capital within the ecosystem can help eliminate 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 may include collecting NFT articles through Mirror, “stealing” images for payment on Stealcam, or anything with an in-product tipping feature.

Losing this “capital interconnectivity” means that the application needs to force users to park inventory on-chain. One reason for this may be that consumers frequently use the application—the bridging experience is painful, so it is easier to maintain a healthy supply of funds on-chain. But more convincing than idle inventory is providing users with options that generate revenue. This could look like native forms of yield, applications that build adjacent products that offer yield (such as Blur’s lending protocol), or something else.

The above reasons (attention and capital) are also why many people see blockchain games as ideal candidates for specific application rollups: they are fairly independent economies that control consumers’ mindshare and are a category where sorting and avoiding congestion are important for a pleasant user experience.

In other words, blockchain games benefit from a high level of control and would not be significantly impacted if they were isolated. Other applications that are very suitable for application rollups may minimize the initial user capital requirements by subsidizing transactions (e.g., the first few transactions are free) or not requiring payment at the beginning (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. Owning a rollup introduces the ability to deploy licenses or meet user screening requirements (e.g., performing KYC on sequencers that own/operate the chain). However, in these cases, the boundary between the rollup database and the centralized database becomes increasingly unclear.

3. Minimizing Connectivity Loss

With the improvement of interoperability solutions, the trade-off between connectivity and control has become less severe. Bridges and sequencers are often the key infrastructure discussed in this issue. They are similar in that they both provide a way for transactions on one chain to affect transactions on another chain. Bridges achieve this by passing messages or enabling asset transfers. Shared sequencers achieve this by ingesting and ordering transactions from multiple chains, creating a coordination mechanism that allows operations on one chain to affect operations on another chain. Atomic composability requires shared sequencers and bridges – sequencers ensure that multiple (cross-domain) transactions are included in a block, and the actual execution of these transactions often requires bridges.

Unit economics of rollups is another area where “connectivity” has influence. L2 transaction fees are composed of two factors: 1) the cost of publishing data to L1, 2) the cost paid by users for inclusion. Rollup operators batch process the call data of transactions, allowing the publishing cost to be shared among users – the more transactions, the lower the average cost for each user. This also means that rollups with less activity may delay publishing transactions to L1 until they have a large enough batch size. The consequence is slower finalization time and poorer user experience. Shared sequencers seem to increasingly become an aggregation layer where batching transactions from multiple smaller rollups can help create viable unit economics for the long tail.

4. Are We at a Turning Point?

The idea of application chains and application rollups is not new. However, for a long time, it felt like a developing residential area: a lot of infrastructure is being built, but there are no residents yet.

But in recent months, we have started to see the first wave of residents moving in. Lattice has built OpCraft, a self-governed world on its own rollup. Projects like Lit Protocol and Synapse have announced their own rollups (although these two projects are more infrastructure-focused rather than application-focused). Zora has launched Zorachain. Conversations with more mature application layer teams, especially those considering L2 strategies, have started to explore whether application rollups are suitable for them.

My assumption is that the real turning point will come in (at least) 6-12 months. Games and social applications have the most obvious product-market fit with application-specific rollups: both social and gaming heavily rely on indexing (and benefit greatly from not having to compete for shared state), ordering problems (especially in gameplay), and custom functionality (like gasless transactions) are particularly useful for entertainment-oriented consumer products. Many of these application teams are still under construction. Especially for games, it may take several years to complete development and release.

One of my other takeaways is that for applications with low financialization, attracting attention is the most critical factor. So far, this article has defined rollup applications as “one application per rollup”. But this view may be too narrow. Perhaps multiple applications decide to form a collective, concentrate their “attention”, and launch a chain together. Similarly, we can see a major application deciding to build its own chain and encourage other applications to deploy on it – in fact, using its own application to test the adoption of the infrastructure it wants to control.

Finally, I firmly believe that we will see more rollups in the future. The projects that build infrastructure services for rollup applications are increasing. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, and others provide low-lift solutions for teams to launch their own Rollups.

Espresso, Astria, and Flashbots’ SUAVE are some early entrants in the sequencing field. The setup costs are decreasing, and the “connectivity” trade-off is becoming less severe. Both strengthen the reasons for adoption. But such a large number of new infrastructure providers also means that application teams may spend time understanding various options and subjecting these different participants to a battle test before choosing a winner. Again, although signs indicate that adoption is happening, I think it will take a few more months for the inflection point to be reached.

Like what you're reading? Subscribe to our top stories.

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

Follow us on Twitter, Facebook, YouTube, and TikTok.


Was this article helpful?

93 out of 132 found this helpful

Gambling Chain Logo
Digital Asset Investment
Real world, Metaverse and Network.
Build Daos that bring Decentralized finance to more and more persons Who love Web3.
Website and other Media Daos

Products used

GC Wallet

Send targeted currencies to the right people at the right time.