Research
5 min read

Solving the Fragmentation Dilemma

Written by
Eclipse Labs
Published on
March 25, 2025

The principal argument against ETH as a value accruing asset has been that REV and net asset issuance are moving to L2s. The proponents of the rollup-centric-roadmap (RCR) or Celestia’s sovereign rollups argue that because in the logical end-state dapps will want customization, ownership over economics and isolated fee markets, that their thesis, and thus a consistent increase of fragmentation, is inevitable. 

The rollup-centric-roadmap is true in so far as customization and value ownership for dapps is NOT available on the L1 / L2. An L2 is not defined by its relationship with the L1, but owns its own state and at the moment, sequencing. It is able to tap into trust-minimized liquidity sources from existing large players, but does not have to be defined in its identity as constrained to the scalability solution of an explicit SINGLE base layer. 

The best defense for a stateful execution environment against fragmentation and the only path to retain single globally synchronous state to continue to provide best-in-class UX AND stay as a relevant developer platform is to DESTROY the incentives to fragmentation at its root.

Image

Solving cross-domain fragmentation is a fundamentally difficult incentive compatibility problem. Cross-domain synchronicity requires trust on the finailty of the other domain’s transaction output. For instance, in the fast-agg path of Agglayer, the receiving chain must be comfortable with the proof posted by the state exporting chain before allowing users to build transactions off the fast-agg’ed state. The receiving chain is responsible for potential issues if the fast-agg’d state later becomes invalid. Larger ecosystems also have incentives to capture theoretical cross-domain revenue via instantiating their own ecosystem’s shared sequencer, rather than a global or cross-ecosystem enforced cross-domain sequencer. For a longer explanation see this thread:

In the face of these difficult incentive compatibility and social coordination problems, we propose a fundamental mindset shift. 

Before: 

Fragmentation is inevitable therefore due to the incentives of economic ownership, fee market locality and customization. Therefore assuming that we will have infinite disparate domains, we should try to build systems that allow them to interoperate seamlessly with each other.

After: 

Fragmentation is caused by the explicit incentives of economic ownership, fee market locality and customization. If we build new technologies that eliminate these foundational incentives at the execution layer, we can also eliminate fragmentation! 

—--—--—--—--—--—--—--—--—--

For an execution layer (L1 or L2) to eliminate the incentives causing fragmentation, and plausibly claim to be a globally synchronous execution layer, there are five qualities that it must have: 

1. Maximum total global throughput

The chain must be able to support the total sum of transaction throughput demand for every dapp on the chain. If the chain is congested (blocks are full) due to insufficient global throughput, it is impossible for the successive dapp to deploy as their users will not be able to land transactions or land at costs under their value of inclusion. Existing dapps wil lose out on potential revenue. Insufficient throughput at the base layer is what incentivized rollups to initially deploy on Ethereum, and has been one of the driving forces behind network extensions on Solana (the desire for cheaper / free transactions at a higher throughput and lower latency for perp dexes - Zeta Bullet). 

2. Local fee markets

The chain should be able to support multiple concurrent hotspots without correlated fee spikes. If the fee rises for one dapp, it should not rise for any other non-complement dapps. The EVM today has global fee markets where congestion on dapp causes fees to rise for all dapps. This makes it difficult for multiple apps of different user value to inclusion to coexist in one domain.

The best way to empirically observe local fee markets is to have as close to zero correlation between median and the average fee as possible. This means that while there are fee spikes happening on the chain, other users of unrelated state are able to get inclusion at the median fee / minimal fee for inclusion. 

Image

Read more about what is required for true local fee markets and ways to improve its exposure to users here:

https://www.eclipselabs.io/blogs/improving-the-svms-fee-markets

3. Incentive Compatibility

One of the core incentives for apps to own their block space is ownership over MEV and execution fees. Today, multiple mechanisms already allow block builders and validators to share a portion of such fees with order flow originators, apps, and users.

Dapps should be able to receive a portion of fees that users pay to access the state that they create. One step further, dapps should be able to programmatically set not only the price to use its products (ie. a frontend fee) but also have the option to dynamically set congestion pricing dependent on customer segmentation and price discrimination.

Today, many options and diverging paths exist for execution environments to provide incentive compatibility - from MEV taxes to CSR. This is also an advantage that an L2, with a trusted block producer and thus the ability to enforce custom sequencing rules, has over an L1. Read about incentive compatibiltiy further in this article:

4. Application Specific Sequencing

At this point, having tackled insufficient base layer throughput, fee market locality, and value ownership, the last defense for the rollup-centric-roadmap - of the vision of a million rollups - is customization, which, though we personally have not observed it in the market, is apparently on the rise.

Image

There are two relevant types of customization - sequencing and execution. 

Sequencing customization is when dapps define custom rules by which they sequence transactions.For example, perp dex chains may want to prioritize cancellations and maker orders so that market makers can quote tight spreads without worrying about getting stale quotes picked off. DEXes that want to internalize MEV may enshrine a top-of-bundle LVR auction and enforce UCP. Arbitrum may want FIFO or Timeboost sequencing. Users of Chainlink’s Fair sequencing service want FIFO guarantees…etc. Sequencing customization is an incredibly useful tool that allows you to control both the user experience and value flow within your dapp. 

Whereas in the past, a chain had to migrate to their own appchain to enjoy these features, and in the process incur the various larger-than-you-think costs that come from rolling your own chain, today, application-specific-sequencing (ASS) infra such as Fastlane’s Atlas or Semantic layer allow you to define custom ordering, auctioning rules and operators. This is able to fully achieve sequencing customization without state fragmentation. 

Execution customization is adding specialized functionality to the execution environment mostly in the form of new syscalls/opcodes. Most are often used to enshrine specialized computation that can now be directly accessed in the smart contract layer, which previously would have required external oracles. The best examples are direct access to AI inference onchain and the ability to read L1 state.

In general, it is very rare to see people focused on building new L2s that focus on execution customization as

  1. External oracles can provide you this information (ie. Opengradient, Risc0 Bonsai) within any existing environment
  2. Base layer compute costs are also going down over time

Overall, I am yet to be convinced that execution customization is a compelling rationale for attempting to take on all the negative aspects of rolling your own rollup.

5. Users and Liquidity

To date, dapps have made more fees from user trading volume and liquidity deposited than from MEV or share of execution revenue. This means that for a dapp to maximize revenue and minimize costs, the most important factor is the level of activity and liquidity on the base chain, and secondarily the willingness of the chain’s users to try out products similar to your dapp. 

This is however, insufficient to say that incumbents with liquidity and user bases have a defensible long term moat. The chain with ALL the liquidity and users pre-2024 was Ethereum. Solana with the help of ONE dapp (Pump.fun) was able to siphon off most of Ethereum’s users and be the place to onboard net new users inflow. Solana has since made meaningful strides in stablecoin and native liquidity thanks to this boost in activity. Liquidity has generally been sticky, but crypto is still in its infancy where ONE breakout dapp can change these dynamics. Regardless, having users and liquidity on your chain is a pre-requisite if you want to be the single execution environment.

Conclusion

 

The best solutions to problems come often from framing the problem in a different way. User experience has overall suffered due to incentives that explicitly encourage constant fragmentation in the absence of incentives that glue disparate state back together in an easy to use way. W.r.t cutting the Gordian knot is not to rely on larger players to shepard their ecosystem against its explicit incentives and try to socially coordinate cross-domain solutions, but rather to cut the incentives to fragment at its root. 

Share this post