In the era of L2, how to save the shattered liquidity landscape

Author: 0xmiddle

Today's crypto is a chaotic world composed of multiple chains. Once, Ethereum gathered the vast majority of liquidity and DeFi applications in the crypto world, but now its TVL share has dropped below 60% and is still on a downward trend.

Some EVM-compatible chains and new public chains continue to eat away at market share. In the face of this situation, Ethereum is also undergoing self-revolution to improve performance and ecosystem capacity, with various Layer 2 solutions becoming the biggest competitors to new public chains, once again reclaiming assets and users from Alt chains.

This world of coexistence between multiple chains and L2 provides more possibilities for dApps and DeFi financial innovations. dApps do not have to be built on the expensive and congested Ethereum mainnet, avoiding limitations on adoption rates due to gas fees. Layer 2 solutions can bring high performance while still interacting with assets within Layer 1 and the entire EVM ecosystem. dApps can even choose to independently build dedicated L2 application chains.

It is foreseeable that the decentralization of applications and liquidity will intensify in the future, bringing new challenges to both developers and users.

For users, regardless of which chain they trade on, it is almost impossible to mobilize global liquidity, leading to higher price impact and making large transactions susceptible to liquidity shortages. Some assets may even lack liquidity on certain chains, forcing users to switch to other chains to trade.

From the developers' perspective, to meet the needs of users on different chains, liquidity must be guided across different chains, which incurs additional costs. If limited liquidity is guided to different chains, it will leave all chains with thin liquidity, degrading the trading experience. However, if certain chains are abandoned, it will mean losing some users and business revenue.

How to Efficiently Utilize Liquidity?

Faced with the dilemma of fragmented liquidity, some solutions attempt to approach the problem from the user's perspective, allowing users to utilize liquidity across different chains as efficiently as possible during trading, thereby reducing trading losses. Generally speaking, there are two main approaches—Liquidity Routing and Trading Agency.

Liquidity Routing

Liquidity routing manifests as applications similar to trading aggregators. When users trade within them, the system does not simply use local liquidity to complete the transaction for the user, but instead searches for the optimal trading path across different chains. Liquidity routing can serve both local trades and cross-chain trades.

We can illustrate how Liquidity Router works using Chainhop and Chainge Finance as examples. Both are cross-chain exchange aggregators.

On ChainHop, if a user wants to exchange asset A on chain X for asset B on chain Y, but the main liquidity for A/B is on chain Z, ChainHop will execute a multi-hop transaction, helping the user send asset A to chain Z, exchange it for asset B, and then send it to chain Y. Through this "multi-hop" method, although gas expenses increase, the overall result can still provide a better trading outcome for users.

For example, when a user requests to exchange a large amount of ETH for USDC on Optimism while on Fantom, Chainhop will first bridge the ETH to Ethereum, then complete the ETH - USDC exchange on Ethereum (which usually has much lower price impact), and finally bridge the USDC to Optimism.

Chainge Finance goes a step further by supporting the splitting of orders across multiple liquidity pools on different chains to complete transactions. For instance, if a user needs to exchange a large amount of ETH on the Fusion chain for USDT on the Tron chain, the system might split the order across Ethereum and Polygon, completing the exchanges separately before transferring the USDT to the Tron chain.

Through the "multi-hop" and "order-splitting" mechanisms, the "liquidity routing" approach can intelligently and fully utilize the dispersed liquidity across multiple chains to complete transactions for users, effectively reducing overall price impact.

Trading Agency

A trading agency refers to a scenario where, after a user issues a trading request, the trading agency helps the user complete the transaction. The trading agency forms a bidding market, allowing users to choose the agency that can provide the best price to execute the trade. This method is somewhat similar to an order book, but unlike traditional order books, these trading agencies do not necessarily reserve their own liquidity in advance; instead, they can help users find the best trading path and complete the transaction after receiving the order, earning a commission in the process. During this process, trading agencies can even fully utilize liquidity from centralized exchanges (CEX), as long as they can provide users with better prices, they can use available liquidity from anywhere.

Like the liquidity routing solution, the trading agency solution can also provide users with both local trading services and cross-chain trading services.

A typical case of this solution is Uniswap X. Uniswap X is a new product launched by Uniswap Labs in July 2023. In the official description, Uniswap X is a new type of permissionless, open-source, Dutch auction-based aggregation trading protocol designed to serve users across AMMs and other liquidity sources, featuring advantages such as no gas fees, no slippage, and MEV resistance.

In Uniswap X, the trading agency is called "Filler." After a user initiates a trading request through Uniswap X, it will be responded to by a Filler. Fillers compete with each other, and the system determines who gets the order through a Dutch auction. The Filler that ultimately secures the order will help the user complete the exchange. In short, Uniswap X allows numerous Fillers to provide users with the best execution price through bidding, while Fillers gain a competitive advantage by discovering better trading paths.

Throughout the process, gas fees are paid by the Filler, so users experience a no-gas experience. As for the risks of MEV attacks and slippage, these are also transferred to the Filler, allowing users to enjoy a "what you see is what you get" trading experience.

The Uniswap official interface already has a button to enable Uniswap X, and users can click the small gear in the upper right corner to manually enable it, currently only supporting the Ethereum network.

Now, whether it is the "liquidity routing" or "trading agency" model, the core focus is on delivering results to users—optimal execution prices—while hiding the complex processes, whether through intelligent algorithms or bidding markets, to complete the tasks for users. This approach can actually be described with a more fashionable and fitting concept, which is the "intent layer." Whether it is liquidity routing or trading agency, they can all be considered different forms of Intent Solvers. Of course, the Intent-Centric narrative is grand and encompasses many other aspects.

How to Better Deploy Liquidity?

Above, we discussed how to help users better utilize multi-chain liquidity. From the perspective of liquidity deployment and guidance, namely DeFi project teams, how can they improve the efficiency of liquidity utilization?

For DeFi projects, liquidity is core; in fact, liquidity is the service that DeFi projects provide. Fragmented and decentralized liquidity prevents each part from maximizing its utility, resulting in low overall liquidity efficiency and hindering the establishment of competitive advantages. Concentrating liquidity on one chain, however, would mean losing users and opportunities from other chains.

To improve this situation, there are two feasible approaches.

Dynamic Liquidity Scheduling

A representative solution for this approach is SLAMM (Shared Liquidity AMM), which is based on the idea of establishing a role called "Predictor," responsible for predicting the distribution of trading volume over a certain period and scheduling liquidity in advance based on that. The closer the Predictor's predictions are to reality, the more rewards they will receive.

Ideally, the Predictor can transfer liquidity from other chains to a specific chain before a trading volume explosion occurs, preventing transaction failures due to insufficient liquidity. They can also transfer excess liquidity to more needed places in advance before a trading volume reduction occurs, avoiding waste of liquidity.

However, this approach has significant drawbacks. First, even with reasonable scheduling, each chain still cannot utilize global liquidity. Second, trading volume changes often lack clear indicators, making it difficult for the Predictor to make reasonable predictions and schedules. Third, users must pay fees to the Predictor.

Although SLAMM has been proposed for over a year, the author has yet to see any practical cases of SLAMM, indicating that developers are not optimistic about this approach.

Remote Liquidity Invocation

This is a simpler approach. DeFi project teams deploy and guide all liquidity on one chain and provide remote access modules on other chains. When users initiate trading requests on other chains, they actually use liquidity remotely through cross-chain methods.

This approach has many advantages, including:

• Users access global liquidity on any chain.
• The guidance and deployment of liquidity become very simple, eliminating allocation and scheduling issues.
• Better cross-chain integration, allowing applications on other chains to use the project's global liquidity through remote invocation. For example, lending projects can remotely use global liquidity for liquidation, reducing losses during liquidation.

The all-chain LSD project Bifrost is practicing this approach. The author has elaborated on this in a previous article titled “The Future of Cross-Chain Bridges: Full Chain Interoperability is Inevitable, and Liquidity Bridges Will Decline”. In fact, this is not just a liquidity deployment method but a new application architecture. We can describe it as a "headquarters + branch" structure.

In this structure, applications do not need to deploy instances on all chains; instead, they deploy the core module (headquarters) on one chain while deploying a lightweight remote module (branch) on other chains. Users from any other chain can remotely access the application through cross-chain methods to obtain services.

In other words, what is unified on one chain is not just liquidity, but also the main part of the application.

Of course, this model also faces challenges. During the remote invocation process, cross-chain bridges are needed, and executing two cross-chain transfers will incur additional costs. If the cross-chain bridge infrastructure is not secure enough, such operations may also carry additional risks.

However, the author sees that cross-chain bridge infrastructure is continuously developing and improving, with a new generation of safer cross-chain bridges emerging, which will dispel the unsafe impression that cross-chain bridges have created. The author’s article “The Downfall of Multichain May Become an Opportunity for Cross-Chain Bridges to Transform” can be referenced.

Let’s analyze the costs of cross-chain asset transfers. These costs are divided into two parts: first, the protocol fees charged by cross-chain bridges to maintain the operation of Bridge Nodes and Relayers, which are generally minimal and can often be ignored; some cross-chain bridges even fully subsidize this, such as Wormhole and Zetachain; second, the gas fees incurred during the cross-chain process, which is the main part.

Remote exchanges incur approximately 282,000 additional gas compared to local exchanges (using EVM as an example). This gas fee ranges from about $0.005 to $0.2 on Arbitrum, Polygon, BSC, and Optimism. Although this price fluctuates with network congestion and token price changes, it remains within an acceptable range. Ethereum L1 is a bit more expensive and can be treated as an exception.

Therefore, weighing the pros and cons from a cost perspective, we can conclude that the cost of cross-chain interoperability is not significant compared to the troubles caused by fragmented liquidity. The remote invocation model for liquidity is more feasible than the dynamic scheduling model.

Views and Summary

In summary, we have elaborated on the reasons for the emergence of a multi-chain landscape and its inevitability, and through examining existing explorations in the industry, we have proposed solutions to the problem of liquidity fragmentation.

Overall, there are two main points:

First, new trading methods centered around intent, such as liquidity routing and trading agency, are helping users better utilize liquidity across different chains, reducing trading losses;

Second, DeFi applications are also pursuing higher efficiency by better deploying liquidity. Dynamic liquidity solutions are somewhat better than static ones, but with the maturation of cross-chain infrastructure, the "single-chain deployment of liquidity + remote invocation" approach is actually more promising.

In the future multi-chain liquidity landscape, the main liquidity of most assets will be concentrated on one chain, and remote exchanges will become the norm. Stablecoins (USDT, USDC, and even ETH to some extent) will be exceptions, as they will be distributed across various chains, serving as a medium for cross-chain asset exchanges.