OmniChain Liquidity addresses the challenge of liquidity segregation in Web3, where projects need to allocate significant capital to provide liquidity on multiple chains.

TLDR

<aside> 💡

For a quick overview, readers can focus on the "Description" section for problem context and the "The Flow of an omniSwap" section for a high-level understanding of the process.

</aside>

Key Points:

Problem: Projects must invest large amounts of capital to create markets and provide liquidity for their tokens on additional chains.
Solution: OmniChain Liquidity allows projects to leverage their primary chain liquidity across multiple chains.
Cost Savings: Potential 80% reduction in liquidity investment when expanding to multiple chains (e.g., $500K instead of $2.5M for expansion to 5 chains).
High-Level Flow: Utilizes a Token Interface, MultiChain DEX Aggregation Protocol, and OmniChain Liquidity Pool to facilitate cross-chain swaps.

Description

OmniChain Liquidity solves the problem of liquidity segregation in Web3. If a project wants to launch on multiple chains, it must allocate exponentially more capital to create a market and provide liquidity for its token on additional chains. For example, if a project adds $200,000 worth of liquidity on Ethereum at a rate of $1 per token, it will need $100,000 worth of their token e.g. x token, and $100,000 worth of ETH to add the x/ETH pair on a DEX.

Let’s assume the pool is optimized to keep slippage around 2% for swaps of up to $1K.

<aside> 💡 The formula for slippage can be derived from the constant product formula used by AMMs like UniSwap. The constant product formula is *XY* = *K*, where *X* is the quantity of one asset in the liquidity pool (x token), *Y* is the quantity of the other asset (ETH), and *K* is a constant value. Learn more.

</aside>

If the project wants to go on additional chains to access a greater community, the access chain-specific features, the ecosystem, or cheaper gas fees, it faces a significant capital hurdle. Let’s imagine the project initially launched on Ethereum and now wants to launch it’s token on Arbitrum. The project must choose how to handle liquidity provisioning to create a market and enable trading access for its token on the Arbitrum.

In simple terms, if the project wants to provide the same optimization to keep 2% slippage for swaps up to $1K on Arbitrum (new market) in addition to Ethereum (current market), they will need to procure $100,000 worth of their token, and an additional $100,000 worth of ETH.

Procurement of the project’s own token is typically not a hurdle, as many projects allocate a portion of their operational supply for multi-chain liquidity provisioning. However, procuring an additional $100,000 worth of ETH directly impacts the project’s available liquid funds. The money that can be allocated to development, marketing, and growth is now being allocated to create a market and enable trading on a secondary chain, even though a market already exists on the primary chain.

What if the project didn’t need the additional pair token, ETH in this case, to enable multi-chain liquidity? What if the project could provide access to its primary chain market on secondary, tertiary, and additional chains where it launches its token?

In other words, what if the project did not need to create a market on additional chains, did not need hundreds of thousands of dollars of additional capital to allow trading on additional chains and maintain the same slippage?

This is where OmniChain liquidity comes into play. Let’s dive in. 😎