Solving the Liquidity Problem
Introducing Virtual AMMs and Route Auctions
tl;dr:
We have two upgrades in development that together solve Connext’s liquidity problem:
Virtual AMMs let routers price crosschain transfers based on available liquidity. This creates an incentive for arbitrageurs to rebalance liquidity for a profit.
Route auctions route transfers to whatever router can supply liquidity most cheaply. This enables aggregating and load balancing liquidity between different routers.
Over the last few weeks, we have seen incredible volume growth on Connext. This growth, however, has created a new problem where liquidity is scarce and frequently unbalanced, leading to poor UX and effective downtime.
The core team has known for some time that this problem would exist eventually (though we had no idea how quickly we’d get here!) and we’ve been working towards a long term solution that unbounds the liquidity within the network and creates incentives for it to remain well-balanced.
Today, we’re excited to introduce our plans for Virtual AMMs and Route Auctions.
Recap: Routers and the Liquidity Problem
Let’s start with a refresher on how Connext routers work.
A Connext router is a state channel node that automatically forwards in-channel transfers sent to it. For a crosschain transaction, this means that the Connext router is a liquidity provider that transfers funds to you in-channel on chainB in return for funds on chainA.
For instance, if you want to send 100 USDC from Polygon to Arbitrum, you deposit 100 USDC into a state channel with the router on Polygon. Then, you send an in-channel transfer to the router that is conditional upon you receiving a transfer in a corresponding state channel with the router on Arbitrum. These transfers unlock atomically, ensuring that you never need to trust anyone.
Aside: How does this conditionality work? For now we use hashlocks to keep things simple, but because Connext is a state channel system, we can use any arbitrary conditionality (including passing around calldata to execute a contract interaction!). Eventually, we’ll likely use something that looks like the packetized payments first pioneered by ILP.
In other words, the router gives you 100 USDC (minus fees) on Arbitrum in return for 100 USDC on Polygon. For the router to give you those funds on Arbitrum, it needs to have enough liquidity. However, if a given router has only a limited supply of liquidity and the flow of funds is largely unidirectional, you frequently end up here:
In a nutshell, this is the liquidity problem we have to solve.
Virtual AMMs
The above problem is experienced by any system that relies on swapping between liquidity pools. For instance, when you swap 100 USDC for 100 USDT on Uniswap, the Uni USDC pool size increases by 100 and USDT pool size decreases by 100 in the same way. If there was a fixed swap rate between the two pools, it would be entirely possible to end up in the same situation as above.
Uniswap and other AMMs handle this by pricing swaps as a function of the ratio of liquidity between both pools. This means the above swap changes the USDC →USDT price from 1 to something slightly worse like 1.00001. Importantly, the more the ratio of pools gets unbalanced, the larger the difference in price gets. This, in turn, creates a growing arbitrage opportunity because the USDT →USDC price eventually becomes much better than on other exchanges in the ecosystem. AMMs are arbitraged this way constantly — that’s part of what keeps them as liquid as they are.
While routers don’t have the same passive-LP pool dynamics that onchain AMMs do, there is no reason why they can’t use the same core concept to price transfers between chains. For a transfer of ETH between Arbitrum and Optimism, this looks like:
This concept, called Virtual AMMs, lets routers get the arbitrage incentive benefits of AMMs even when enabling transfers across chains.
In other words, if all of the liquidity is getting pushed to one side of the router, Virtual AMMs make it profitable for arbitrageurs to make transactions in the opposite direction to rebalance!
Route Auctions
There are already several routers providing liquidity in Connext, and it has always been possible for anyone to spin up their own router without any involvement from the team.
However, the process of figuring out which router to connect to is entirely manual right now. This means that liquidity is not aggregated and load balanced between routers right now — if a given dapp’s usage skyrockets, then the router that it is connected to gets overloaded even if there is sufficient liquidity available on other routers.
Route auctions are a mechanism to dynamically route a specific transfer to whichever router can supply liquidity for it most cheaply.
When doing a transfer, you would broadcast to the network with the sending/receiving liquidity that you want. Routers would then submit sealed bids directly to you for the cheapest price at which they can make your transfer, similar to how Uber matches you with the cheapest drivers in your area.
When paired with swap pricing from Virtual AMMs, this means your transfer is automatically sent to whichever routers have the most unbalanced liquidity. In other words, the network automatically load balances between routers in the ecosystem based on available liquidity, regardless of whether the demand is coming from!
Development Status and Timeline
An MVP implementation of Route Auctions has already been built by 1Hive! Huge thanks to their team for helping develop a key part of the network ❤️. This week, we plan on setting up a simnet environment to rigorously test the auction mechanism, with the goal of getting it live as soon as testing is completed. We expect this to happen within the next two weeks.
We’ve also merged an early, feature-flagged implementation of Virtual AMMs to our codebase some time back. The implementation uses the newly released Balancer v2 Stable curve, thanks to key early help and feedback from Mike McDonald. There is some additional work needed to read onchain balances of all funds as well as rigorous testing that needs to happen before it can go live. Development of this is blocked by route auctions, but we expect an experimental release to go out less than two weeks after Route Auctions are live.
Note that both of the above implementations will be early, experimental versions. As such, we’ll be scaling up routers slowly initially while we make sure that everything remains robust and dependable. However, even with the MVP implementations above, we still expect liquidity constraints to be improved by 10x-100x! 🚀
About Connext
Connext is the interoperability protocol of L2 Ethereum.
