Solving liquidity fragmentation through Chain Abstraction

Liquidity Fragmentation

The Ethereum roadmap envisions a future where adoption exists on networks that settle on Ethereum. In theory, this is the best of both worlds: low fees and high security. In practice, this leads to significant issues inhibiting adoption, the most important being liquidity fragmentation.

Currently 64 L2s, 17 L3s, and 79 more networks are actively being built on top of Ethereum (L2Beat).

Each network has attempted to establish liquidity hubs, as few will use a network without liquidity on major pairs. The issue with this is that liquidity is more or less finite, meaning that when one network attracts liquidity, the odds are that specific liquidity (at least a good part) is being siphoned away from a different network.

The issue with fragmented on-chain liquidity is that when swapping, the price impact will always be higher as there is less liquidity.

This will lead to inconsistent pricing for the same asset across various chains and less user output.

MEV bots can limit the spread, but bridging and trading fees make fully closing the spread unprofitable.

The spread can sometimes be very significant due to external reasons. An example of this is ezETH on Blast. Demand for ezETH was very high on Blast because of yield opportunities. The premium was consistently 1-2% higher than the NAV. However, this could not be profitably arbitraged as the discount to instantly bridge ETH off Blast was within the same range as the ezETH premium.

dAPPS also suffer from fragmented liquidity. Polymarket is the leading prediction market but only accepts USDC deposits from the Polygon chain.

If a user holds ETH on Ethereum mainnet, they must go through several steps to deposit (bridging, swapping, depositing). While tools like Jumper work to simplify the above process, they still are not the end game, as the depositing process is only partially abstracted away.

Money markets like Compound suffer from liquidity fragmentation because lending/borrowing is not aggregated. This means interest rates wildly vary across different networks.

An on-chain economy cannot truly flourish with fragmented liquidity.

Chain Abstraction

Account abstraction allows smart contracts to interact with funds without the user relinquishing control of their assets.

This is powerful because it dramatically improves the user UX by enabling smart contracts to handle the more complex parts of interacting with Ethereum.

In several ways, abstraction can greatly improve the UX, such as gas, interface, and data abstraction. However, chain abstraction in particular is our best tool for solving liquidity fragmentation.

Chain abstraction is the concept of separating the blockchain from the UX. Networks will seamlessly run in the background without users knowing their actions are causing transactions.

Currently, to transfer funds to someone, you need to copy their address from somewhere, open up a wallet, and make sure you have enough gas money to send the transaction. If they are expecting the funds on a different network, first, you need to bridge your funds to that network and make sure you have enough gas on that network.

After finally sending the transaction, you need to monitor its status to ensure its success. If it gets stuck because of a gas spike, you need to manually resubmit the transaction with higher gas.

This is not practical for long-term adoption.

Chain abstraction enables the "Venmo" experience for sending transactions. Simply type a user's handle and click send. The app's backend will handle everything, including bridging and gas top-ups.

The benefits of chain abstraction are not limited to sending transfers. Anything complex can be abstracted away to create an easier user experience and, therefore, a higher probability of long-term, sustained adoption.

How does chain abstraction solve liquidity fragmentation?

Liquidity is "aggregated" because a transaction can involve all liquidity available, regardless of chain.

Intents allow a user to submit a request (i.e., an intent to do something), and solvers will fulfill that intent. This all happens in the background.

When users interact with an application utilizing chain abstraction, they do not see the option to switch their network.

When they want to swap tokens, they see a single page allowing them to trade any token with another, regardless of whether the tokens exist on different chains.

The router will find the best output possible (similar to an aggregator), even if that means swapping different percentages of tokens on different DEXs on different chains. Interoperability layers like LZ are used in the background.

All this is done in the backend - the router is scripted with the intent to get the best output for users regardless of networks.

In a nuanced fashion, chain abstraction eliminates the existing MEV because of liquidity fragmentation and returns that output to users.

While MEV inherently is not predatory, we should be taking every step possible to reduce their profitability. While that take may be critiqued, markets are zero-sum, and reduced profitability for arbitrage bots means increased user output.

Chain abstraction benefits liquidity providers, too, because the effective aggregation of liquidity creates greater depth on both sides.

Greater Liquidity → Deeper depth → More Volume → Increased fees

This also stabilizes returns by making all liquidity "equal" because all fees will be returned to LPers on a pro-rata basis relative to the amount of liquidity provided.

This makes liquidity provision appealing to more users, as picking the correct chain and DEX to gain the highest ROI is unnecessary.

For money markets, chain abstraction can simplify lending by automatically routing and splitting deposits into different markets to optimize the interest rate earned. Borrowed funds can also be routed to optimize the lowest interest rate paid. Doing this will eliminate MEV bots that profit from lending/borrowing discrepancies and return that flow to regular users.

However, this isn't viable across multiple applications because of varying levels of contract risk. Instead, the router should just query the specific dAPP chosen on each network they are deployed on to optimize rates (e.g., look through Aave's markets on all the chains they are running on).

Aave is building a unified liquidity layer in V4, similar to the above. ¹

Perhaps the most integral aspect of a flourishing on-chain economy is chain abstraction for deposits into dAPPs.

Being able to deposit into any dAPP from any chain with any asset with a simple tap is paramount to the everyday user interacting with on-chain applications (even if they will not know it!).

Solver Limitations + Atomic Execution

While, in theory, chain abstraction sounds like a (perfect!) solution to the liquidity fragmentation issues the Ethereum ecosystem faces, there are challenges with the implementation.

The first issue is that chain abstraction relies on solvers to execute intents.

Solvers are centralized at the core. Very few solvers are actually capable of filling cross-chain intents quickly. Solvers face numerous limitations that inherently induce centralization, such as hefty start-up requirements and a lack of incentives. This is a great article from LI.FI on solver centralization.

Solver centralization is one of if not the largest, issue that chain abstraction faces because a lack of solvers renders intent-based transactions centralized.

Solvers use their own capital to execute intents and, as such, require incentives (typically in the form of fees). While properly utilized incentives increase user execution and intent speed, misused incentives can lead to user issues. This is because nodes can start to act out of their own interest with controlling intents, simultaneously reducing censorship resistance.

Delphi has written a great report on Anoma (with a lot on intents and solvers) that can be found here.

I believe cross-chain atomic execution is paramount to the success of chain abstraction because, without atomicity, significant liveness risks exist. If a solver submits only a portion of a transaction's intents while the remaining intents go unsolved, solvers can face capital issues. While atomic execution can lead to a higher percentage of transaction failures, the tradeoff is worth it as it solves the issue of improper capital positioning.

One attempt at cross-chain atomic execution is shared validity sequencing. This sequencing method uses a shared sequencer, block-building to process user intents, and shared fraud proofs to enforce the actions. However, this design still poses centralization risks, as it is effectively a single sequencer.

The full whitepaper can be found here.

Clearing Layers Helping Solvers

Solvers struggle tremendously with having funds dispersed across a multitude of different networks, leading to constant rebalancing. This is difficult for existing solvers to manage, and it also hinders new solvers from being spun up, thus contributing to the centralization issue.

Clearing Layers - introduced by Everclear - attempt to solve this by establishing a global liquidity settlement layer for solvers to utilize. Their chain (built as an Arbitrum Orbit chain) will serve as the foundation layer for solvers.

The use of a clearing layer will allow solvers to get liquidity on the chain they want at a near-zero cost through liquidity exchanging.

While several development limitations exist, Chain Abstraction is integral to an on-chain future.

1. Aave V4 Rundown - https://x.com/BSturisky/status/1787560911756013699