Two years ago, app developers faced a fairly simple choice when determining where they wanted to deploy their application: Ethereum, Solana, Cosmos, or maybe a few additional layer-1 chains. Rollups weren’t yet operational, and few had ever heard the phrase “modular stack.” The differences between the L1s (throughput, fees, etc.) were stark and relatively easy to grasp.

Today, the landscape looks quite different. App developers are faced with a much larger array of choices: L1s, general-purpose rollups (both optimistic and zk), advanced IBC infra, rollup-as-a-service providers, appchains, and more. With more choices come more questions, including: whether teams should deploy to a general-purpose rollup or build an app-specific rollup; if they pick a general-purpose rollup, then which one; if they go the app-rollup route, then which SDK/rollup-as-a-service to use; which data availability layer to select; whether EigenLayer can help; how to think about sequencers; and if there will even be a colored orb emoji within Optimism’s Superchain ecosystem left if they choose to go the OP Stack route. It’s overwhelming.

To narrow down the set of questions, this piece will take the framing of an app already deployed on Ethereum that wants to scale within the Ethereum ecosystem. Consequently, the focus will be on the decision tree that app teams face when determining whether to launch their own rollup, my hypotheses around which types of apps are particularly well suited for this infrastructure, and when I think we might hit the tipping point in adoption.

At the heart of the app-rollup decision is really a simple question: Will users still use the app if it’s on its own chain? This question has two subsets:

1. Are users more likely to use an app if it’s on its own chain?

2. Are users just as likely to use an app if it’s on its own chain?

Benefits of app-specific rollups stem from greater control: the ability to abstract gas costs, limit onchain congestion stemming from other apps’ activities, better experiment with how to utilize a token, explore different economic structures (e.g. gas rebates for integrations), build custom execution environments, implement access controls (e.g. permission deployments), and more.

But this added control comes at the cost of connectivity with a greater ecosystem. Apps on shared/general-purpose chains enjoy access to liquidity already on that chain (e.g. no additional bridging between chains necessary), composability with other apps, and user attention already dedicated toward that chain. Building on a general-purpose chain also requires less internal engineering effort/overhead relative to an app running its own chain.

Greater control would likely enhance user experiences if it came at no cost. So, the answer to the core question - whether users will still use the app if it’s on its own chain - really depends on the severity of this control-connectivity trade-off.

Connectivity comes in several forms. The two most important are: 1) attention, and 2) capital.

Attention is about native distribution. If a team’s project is the first thing a user engages with when coming to the ecosystem, there’s a compelling case that the app has native distribution. Apps that control attention are better suited to launch their own chain; users will use the app regardless of what chain it lives on. In my view, examples of apps currently with native distribution include Mirror, Zora, Manifold, Sound.xyz, and OnCyber. There’s also an argument to be made that an app without strong distribution may choose to launch its own chain as an effort to spark interest (although I find this less compelling if many chains are pursuing this route simultaneously).

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

Losing this “capital connectivity” means that apps need to compel users to park inventory on the chain. One reason might be that the consumer uses the application frequently - bridging is painful, so it’s easier to just keep a healthy supply of capital on the chain. But even more convincing than idle inventory is offering users options to generate yield. This could look like chain-native forms of yield, apps building adjacent products that offer yield (like Blur’s lending protocol), or something else.

The above reasons - attention and capital - are also why many point to onchain games as ideal candidates for app-specific rollups: they’re fairly self-contained economies, control consumer mindshare, and are a category where both ordering and avoiding congestion is important for a delightful user experience. In other words, onchain games benefit from a great degree of control without suffering significantly if they’re isolated. Other apps well-suited for app-rollups likely minimize upfront user capital requirements by subsidizing transactions (e.g. first few transactions are free) or by not requiring payments when onboarding (e.g. user-generated onchain content, certain social apps, DePIN networks, etc.).

There are, of course, other reasons projects would want more control over their infrastructure. Owning a rollup introduces the ability to permission deployments or implement user screening requirements (e.g. KYCing a chain-owned/operated sequencer). In these instances, though, the line between a rollup and a centralized database becomes less and less clear.

The connectivity vs. control trade-off is also becoming less severe as interoperability solutions improve. Bridges and sequencers are often the key infrastructure discussed within this bucket. They’re somewhat similar, in that both provide a way for transactions on one chain to impact transactions on another chain. Bridges do this by passing messages or enabling the transfer of assets. Shared sequencers do this by ingesting and ordering transactions from multiple chains, creating a coordination mechanism enabling the actions on one chain to affect those on another. Both shared sequencers and bridges are required for atomic composability - sequencers guarantee the inclusion of multiple (cross-domain) transactions in a block, while a bridge is typically required for the actual execution of those transactions.

Rollups’ unit economics are another area where “connectivity” is impactful. L2 transaction fees are composed of two factors: 1) the cost of publishing calldata to the L1, and 2) the cost a user pays for inclusion at all. Rollup operators batch calldata for the transactions, enabling the cost of publication to be amortized across users - the more transactions, the lower the average cost per user. That also means rollups with less activity may delay posting transactions to the L1 until they have a sufficiently large batch size. The consequences are slower times to finality and a worse user experience. It seems like shared sequencers can increasingly become aggregation layers, where batching the transactions from a number of smaller rollups can help create viable unit economics for the long tail to exist.

The idea of app-chains and app-rollups is nothing new. Yet for a long time it felt like a housing complex in development: lots of infrastructure being built without any residents. But in recent months, we’ve started to see the first few residents trickle in. Lattice built OpCraft, an onchain autonomous world supported by its own rollup. Projects like Lit Protocol and Synapse have announced their own rollups (albeit both are more infra- rather than app-oriented projects). Zora launched Zorachain. Recent conversations with more mature application-layer teams - especially those thinking about their L2 strategy - have begun to include exploration around whether an app-rollup is right for them.

My hypothesis is that the true inflection point will come (at least) 6-12 months from now. Games and social apps have the most obvious product-market fit with app-specific rollups: both social & gaming rely heavily on indexing (and benefit greatly by not having to contend with shared state), ordering matters especially in gameplay, and custom features (like gasless transactions) can be especially useful for entertainment-oriented consumer products. Many of these app teams are still building. Games, in particular, can take years to fully develop and launch.

My other takeaway is that, for less financialized apps, owning attention is the most critical factor. So far, this essay has framed app-rollups as “one app per rollup.” But that viewpoint might be too narrow. Maybe multiple apps decide to form a collective, pool their “attention,” and launch a chain together. Similarly, we could see a major app decide to build its own chain and encourage other apps to deploy on it - in effect, using its own app to dogfood adoption of infrastructure it would like to control.

Finally, I do very much believe we’ll see a future with many more rollups. There has been an explosion of projects building infrastructure services for app-rollups. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, and more offer low-lift solutions for teams to spin up their own rollup. Espresso, Astria, and Flashbots’ SUAVE are some of the early entrants in the sequencer space. Setup costs are trending downward and the “connectivity” trade-off is becoming less severe. Both strengthen the case for adoption. But this high number of new infrastructure providers also means app teams may take their time in both learning about the various options and letting these different players become battle-tested before selecting a winner. So again, while the signs directionally point toward adoption, I think an inflection point is still a good number of months away.

Thank you to Devloper, Jill Gunter, Kyle Samani, Jason Maier, Cem Ozer, and Viktor Bunin for feedback, comments, and conversations that helped develop many of these ideas.

This post was originally posted on the Variant website.

Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by Variant. While taken from sources believed to be reliable, Variant has not independently verified such information. Variant makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This post reflects the current opinions of the authors and is not made on behalf of Variant or its Clients and does not necessarily reflect the opinions of Variant, its General Partners, its affiliates, advisors or individuals associated with Variant. The opinions reflected herein are subject to change without being updated.

Two years ago, app developers faced a fairly simple choice when determining where they wanted to deploy their application: Ethereum, Solana, Cosmos, or maybe a few additional layer-1 chains. Rollups weren’t yet operational, and few had ever heard the phrase “modular stack.” The differences between the L1s (throughput, fees, etc.) were stark and relatively easy to grasp.

Today, the landscape looks quite different. App developers are faced with a much larger array of choices: L1s, general-purpose rollups (both optimistic and zk), advanced IBC infra, rollup-as-a-service providers, appchains, and more. With more choices come more questions, including: whether teams should deploy to a general-purpose rollup or build an app-specific rollup; if they pick a general-purpose rollup, then which one; if they go the app-rollup route, then which SDK/rollup-as-a-service to use; which data availability layer to select; whether EigenLayer can help; how to think about sequencers; and if there will even be a colored orb emoji within Optimism’s Superchain ecosystem left if they choose to go the OP Stack route. It’s overwhelming.

To narrow down the set of questions, this piece will take the framing of an app already deployed on Ethereum that wants to scale within the Ethereum ecosystem. Consequently, the focus will be on the decision tree that app teams face when determining whether to launch their own rollup, my hypotheses around which types of apps are particularly well suited for this infrastructure, and when I think we might hit the tipping point in adoption.

At the heart of the app-rollup decision is really a simple question: Will users still use the app if it’s on its own chain? This question has two subsets:

1. Are users more likely to use an app if it’s on its own chain?

2. Are users just as likely to use an app if it’s on its own chain?

Benefits of app-specific rollups stem from greater control: the ability to abstract gas costs, limit onchain congestion stemming from other apps’ activities, better experiment with how to utilize a token, explore different economic structures (e.g. gas rebates for integrations), build custom execution environments, implement access controls (e.g. permission deployments), and more.

But this added control comes at the cost of connectivity with a greater ecosystem. Apps on shared/general-purpose chains enjoy access to liquidity already on that chain (e.g. no additional bridging between chains necessary), composability with other apps, and user attention already dedicated toward that chain. Building on a general-purpose chain also requires less internal engineering effort/overhead relative to an app running its own chain.

Greater control would likely enhance user experiences if it came at no cost. So, the answer to the core question - whether users will still use the app if it’s on its own chain - really depends on the severity of this control-connectivity trade-off.

Connectivity comes in several forms. The two most important are: 1) attention, and 2) capital.

Attention is about native distribution. If a team’s project is the first thing a user engages with when coming to the ecosystem, there’s a compelling case that the app has native distribution. Apps that control attention are better suited to launch their own chain; users will use the app regardless of what chain it lives on. In my view, examples of apps currently with native distribution include Mirror, Zora, Manifold, Sound.xyz, and OnCyber. There’s also an argument to be made that an app without strong distribution may choose to launch its own chain as an effort to spark interest (although I find this less compelling if many chains are pursuing this route simultaneously).

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

Losing this “capital connectivity” means that apps need to compel users to park inventory on the chain. One reason might be that the consumer uses the application frequently - bridging is painful, so it’s easier to just keep a healthy supply of capital on the chain. But even more convincing than idle inventory is offering users options to generate yield. This could look like chain-native forms of yield, apps building adjacent products that offer yield (like Blur’s lending protocol), or something else.

The above reasons - attention and capital - are also why many point to onchain games as ideal candidates for app-specific rollups: they’re fairly self-contained economies, control consumer mindshare, and are a category where both ordering and avoiding congestion is important for a delightful user experience. In other words, onchain games benefit from a great degree of control without suffering significantly if they’re isolated. Other apps well-suited for app-rollups likely minimize upfront user capital requirements by subsidizing transactions (e.g. first few transactions are free) or by not requiring payments when onboarding (e.g. user-generated onchain content, certain social apps, DePIN networks, etc.).

There are, of course, other reasons projects would want more control over their infrastructure. Owning a rollup introduces the ability to permission deployments or implement user screening requirements (e.g. KYCing a chain-owned/operated sequencer). In these instances, though, the line between a rollup and a centralized database becomes less and less clear.

The connectivity vs. control trade-off is also becoming less severe as interoperability solutions improve. Bridges and sequencers are often the key infrastructure discussed within this bucket. They’re somewhat similar, in that both provide a way for transactions on one chain to impact transactions on another chain. Bridges do this by passing messages or enabling the transfer of assets. Shared sequencers do this by ingesting and ordering transactions from multiple chains, creating a coordination mechanism enabling the actions on one chain to affect those on another. Both shared sequencers and bridges are required for atomic composability - sequencers guarantee the inclusion of multiple (cross-domain) transactions in a block, while a bridge is typically required for the actual execution of those transactions.

Rollups’ unit economics are another area where “connectivity” is impactful. L2 transaction fees are composed of two factors: 1) the cost of publishing calldata to the L1, and 2) the cost a user pays for inclusion at all. Rollup operators batch calldata for the transactions, enabling the cost of publication to be amortized across users - the more transactions, the lower the average cost per user. That also means rollups with less activity may delay posting transactions to the L1 until they have a sufficiently large batch size. The consequences are slower times to finality and a worse user experience. It seems like shared sequencers can increasingly become aggregation layers, where batching the transactions from a number of smaller rollups can help create viable unit economics for the long tail to exist.

The idea of app-chains and app-rollups is nothing new. Yet for a long time it felt like a housing complex in development: lots of infrastructure being built without any residents. But in recent months, we’ve started to see the first few residents trickle in. Lattice built OpCraft, an onchain autonomous world supported by its own rollup. Projects like Lit Protocol and Synapse have announced their own rollups (albeit both are more infra- rather than app-oriented projects). Zora launched Zorachain. Recent conversations with more mature application-layer teams - especially those thinking about their L2 strategy - have begun to include exploration around whether an app-rollup is right for them.

My hypothesis is that the true inflection point will come (at least) 6-12 months from now. Games and social apps have the most obvious product-market fit with app-specific rollups: both social & gaming rely heavily on indexing (and benefit greatly by not having to contend with shared state), ordering matters especially in gameplay, and custom features (like gasless transactions) can be especially useful for entertainment-oriented consumer products. Many of these app teams are still building. Games, in particular, can take years to fully develop and launch.

My other takeaway is that, for less financialized apps, owning attention is the most critical factor. So far, this essay has framed app-rollups as “one app per rollup.” But that viewpoint might be too narrow. Maybe multiple apps decide to form a collective, pool their “attention,” and launch a chain together. Similarly, we could see a major app decide to build its own chain and encourage other apps to deploy on it - in effect, using its own app to dogfood adoption of infrastructure it would like to control.

Finally, I do very much believe we’ll see a future with many more rollups. There has been an explosion of projects building infrastructure services for app-rollups. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, and more offer low-lift solutions for teams to spin up their own rollup. Espresso, Astria, and Flashbots’ SUAVE are some of the early entrants in the sequencer space. Setup costs are trending downward and the “connectivity” trade-off is becoming less severe. Both strengthen the case for adoption. But this high number of new infrastructure providers also means app teams may take their time in both learning about the various options and letting these different players become battle-tested before selecting a winner. So again, while the signs directionally point toward adoption, I think an inflection point is still a good number of months away.

Thank you to Devloper, Jill Gunter, Kyle Samani, Jason Maier, Cem Ozer, and Viktor Bunin for feedback, comments, and conversations that helped develop many of these ideas.

This post was originally posted on the Variant website.

Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by Variant. While taken from sources believed to be reliable, Variant has not independently verified such information. Variant makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This post reflects the current opinions of the authors and is not made on behalf of Variant or its Clients and does not necessarily reflect the opinions of Variant, its General Partners, its affiliates, advisors or individuals associated with Variant. The opinions reflected herein are subject to change without being updated.