Quick overview of key points
We are working on two important upgrades that together address the liquidity issues of Connext.
Virtual AMM (Virtual Automated Market Maker) allows routers to price cross-chain transfers based on available liquidity. This will provide an incentive for arbitrageurs to profit by reallocating liquidity.
The liquidity auction selects the router offering the cheapest liquidity for the transfer. This allows aggregation of liquidity between different routers and the ability to read liquidity from different routers.
Over the past few weeks, we have seen an incredible increase in the volume of transactions on Connext. However, this growth has created a new problem of scarce and often uneven router liquidity, which has led to poor user experience and even downtime.
The core team at Connext anticipated this early on (though we had no idea it would happen so soon), and we have been working on a long-term solution to free up liquidity in the network and create incentives to keep it relatively balanced across routers.
Today, we are pleased to introduce our Virtual AMM and liquidity auction program.
Routers and the liquidity problem
Let’s start by reviewing how the Connext router (liquidity provider) works.
A Connext router is a node of a stateful channel that automatically processes the transactions sent to it by the channel. For a cross-chain transaction, this means that the Connext router is equivalent to a liquidity provider that transfers funds to you in the channel of chain B and gets your funds in chain A.
For example, if you want to send 100 USDCs from Polygon to Arbitrum, you need to deposit 100 USDCs into the Polygon router’s state channel. Then, you send an in-channel transmission to the router, and you subsequently receive the transmission from the corresponding state channel of the router on Arbitrum. These transactions are automatically unlocked, ensuring that you never need to trust anyone.
To make everything look simple and workable, we now use hashlock, but since Connext is a stateful channel system, we can use arbitrary conditions (including passing calldata to perform contract interactions!) ), and eventually, we may use a packaged payment method similar to the one pioneered by ILP.
In other words, the router gives you 100 USDC (minus fees) on Arbitrum, and it will get 100 USDC on Polygon. for a router to fund you on Arbitrum, it needs to be sufficiently liquid. However, if a router has limited liquidity and the flow of funds is largely one-way, then you often run into awkward problems like the following.
In short, this is the mobility problem we must solve.
Any system that relies on a liquidity pool for swapping will encounter the above problem. For example, when you swap 100 USDC for 100 USDT on Uniswap, the Uni USDC pool has 100 USDC more and the USDT pool will have 100 USDT less accordingly. if there is a fixed exchange rate for the swap between the two pools, then it is entirely possible that the same situation as above will occur.
Uniswap and other AMMs deal with this problem by pricing swaps as a function of the liquidity ratio between the two pools. This means that the above swaps change the price of USDC→USDT from 1 to a price slightly higher than 1, such as 1.00001. Importantly, as the pools become more and more unbalanced in terms of funding ratios, the difference in swap prices becomes larger. This in turn creates more and more arbitrage opportunities, as the USDT→USDC price ends up being much better than other exchanges in the ecosystem. AMMs often arbitrage in this way, and this is part of what keeps them liquid.
While routers do not have the dynamic characteristics of passive liquidity pools that on-chain AMMs have, they can actually use the same core concepts to transfer prices between chains. For the conversion of ETH between Arbitrum and Optimism, the following diagram shows:
This concept is called Virtual AMM and it allows routers to reap the benefits of arbitrage incentives from AMM even when transmitting across chains.
In other words, if all the liquidity is piled up on one side of the router, then Virutal AMM allows arbitrageurs to trade in the opposite direction to regain the balance of funds and profit from it.
There are already a number of routers in Connext that offer liquidity and anyone can start their own router without the involvement of a team.
However, the process of determining which router to connect to is currently entirely manual. This means that there is no aggregation or reading of mobility between routers. If the usage of a given Dapp spikes, the router it is connected to will be overloaded even if there is enough liquidity on other routers.
A mobility auction is a mechanism for dynamically routing a given transfer to the router that can provide it with the cheapest mobility.
When you make a transfer, you will broadcast to the network the mobility you want to send/receive. The router will then submit an offer directly to you to transfer money for you at the cheapest price, much like Uber matches you with the cheapest drivers in your area.
When paired with Virtual AMM’s pricing for swaps, this means that your transfers are automatically sent to the router with the most imbalanced liquidity. In other words, regardless of where the demand for a swap comes from, the network automatically reads the balance of routers in the ecosystem based on available liquidity.
Development status and timeline
1Hive has built the MVP implementation of the liquidity auction! Many thanks to their team for helping develop a key part of the network ❤️. This week, we plan to build a simnet environment to rigorously test the auction mechanism, with the goal of enabling it as soon as testing is complete. We expect this to happen in the next two weeks.
We have also merged an earlier, feature-tagged Virutal AMM implementation into our codebase. This implementation uses the newly released Balancer v2 Stable curve, thanks to early help and feedback from Mike McDonald. Some additional work is needed to read the on-chain balances of all funds and rigorous testing is required before going live. Development of this is being hampered by the liquidity auction, but we expect to release an experimental version less than two weeks after the liquidity auction goes live.
Please note that both of these implementations will be early experimental versions. As such, we will slowly scale up the router while ensuring that everything remains secure and reliable. However, even with the above MVP implementation, we still expect a 10x-100x improvement in liquidity! ????
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/how-connext-solves-the-liquidity-problem-of-cross-chain-transactions/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.