AMM: Solutions to impermanent loss and front-running
The idea of decentralized finance and direct transactions seemed just amazing a few years ago and remains the same till now. The mechanisms of AMM have experienced a huge revolution and enhancement through its near three years in crypto finance.
The main driver for such opportunities was the presence of certain problems connected to liquidity loss. Some of them are impermanent loss, front running. Those are also considered as main prevention to the widespread of decentralized exchanges. In this article, Blaize wants to guide you through the technical side of such problems and review the use cases on how to prevent them.
Impermanent loss problem explained
In most traditional examples of DEXs liquidity, pools contain just two assets. In order to get in, the user should provide an equal cost of token for each side of the pool. To better understand the issue, let’s take an easy example.
Assume the 50/50 ETH/DAI pool with an equal amount of tokens provided already. As long as the price for those two differs considerably on the market (when 1 ETH = $100; 1 DAI=$1), so in order to make them “equal” we need to put 10 ETH to 1000 DAI. (look more explanation in this article). In this case, the pool is considered balanced and gives an ideal environment for the trade.
As we know, traditional DEXs, like Uniswap are governed by the market supply demand laws, which can become a huge pain in some situations. According to these laws asset prices are set based on the actions of market players not thanks to external sources, such as oracles. In case of market change and token price fluctuation, the real value and cost of a token may be adjusted only by third parties, called arbitrageurs (who charge a lot for their services btw :)).
Imagine the situation when ETH price on the external markets like Binance has changed to $110, but the price on the DEX still remains $100. This creates a perfect “opportunity” for arbitrageurs to make a profit (and to balance the pool of course :)).
In terms of Uniswap, the protocol uses CPMM model to regulate the token pool price.
Therefore, as in our example, the more ETH is taken from the pool, the higher its price becomes. In case of external market price change, the arbitrageur buys now “cheap” ETH from the Uniswap pool until it becomes equal (or near) to the Binance price. He rebalances the pool and earns some profit at the same time.
Assume arbitrageurs buy 1 ETH out of the Uniswap pool still for $100 and provide a certain amount of DAI in exchange. The pool will experience the following:
(10–1)*(1000 + (1*a +fee)) = 10000
assume (1*a + fee) as X
9*(1000+X)=10000
1000+X = 10000/9
1000+X =1111.111….
X = 1111–1000=111
Accordingly, the difference between previous and current prices is $11 which goes to the pocket of arbitrageurs. Those $11 is the arbitrageur profit and the impermanent loss in case of such trade. So other words, impermanent loss is the probable loss of funds supplied to the pool in comparison to just holding them in your crypto wallet. It is probable and impermanent because it occurs only if the LP withdraws the tokens from the DEX.
LP can get a refund only if someone provides the tokens to the pool at a price lower than the market price (e.g. $90 in a pool and 100 at the market). Once the price in the pool becomes equal to the market price ($100), the pool will cover impermanent loss from the previous scenario. With a simple return of the market price from high (110) to the previous (100) liquidity will not appear in the pool back out of nothing. In practice, there will always be an impermanent loss.
What if we talk about much bigger pools?
Imagine the one contains 100000 ETH to 100000000 DAI with the same input data (1 ETH = $100; 1 DAI=$1). Assume the similar fluctuation when the ETH price goes to $110 and the one wants to buy out not 1 ETH, but 50000 ETH at a low Uniswap price ($100). The pool price changes drastically, LPs see this and want to withdraw their ETH in order to detriment the even bigger loss. But… oops, there might be not enough ETH in the pool to pay out everyone. It might cost someone much higher than $11.
Those are the main issues around impermanent loss problems that contributed to the works on its mitigation. There are several solutions that act effectively in terms of impermanent loss elimination. One of them is to hold your money in stablecoins :).
Curve.fi solution
The problem of impermanent loss occurs in a time of market fluctuation and usually deals with high volatile assets. In case of stablecoins, there will be no such volatility, so no need to rebalance the pool one or another way. As long as the price is equal to or near to $1, there is no risk of loss. Curve was the first protocol which indirectly eliminated the impermanent loss problem by enabling swap between stablecoins. We use “indirectly” because this applied only to stable assets and does not resolve the whole problem itself. Despite this, it made a big step forward and created a great alternative on the market then.
Balancer solution
The next step in impermanent loss beating was the introduction of Balancer’s customized pools. The new AMM model, the protocol uses, help to peg the token price to its actual weight or value. Accordingly, it allows the creation of pools with unequal amounts of tokens provided like 60/40 or even 98/2 and 95/5. The other helpful advantage is that the pool is no longer limited to only two assets, so a user can supply 30% ETH/50% DAI/20% USDC as an example.
Such “imbalanced” balance is very effective in case of token price fluctuation. If taking into account the possibility of creating a multiple token pool where assets are provided accordingly to its actual value, the risk of impermanent loss becomes really lower. Yet, it is worth mentioning, that such deduction depends rather on the percentage of stablecoins than the number of assets.
Want to develop your own dApp, but don’t know where to start? Contact us and get a free idea validation & consulting for your project.
Bancor solution
The revolutionary solution has been recently introduced by Bancor. As it is seen in the previous examples, the pools with the constant prices tokens (like stablecoins, wrapped or synthetic tokens) are proven to be resistant to impermanent loss. Bancor has successfully translated this structure on the highly volatile tokens by launching the integration with Chainlink. Its oracles enable to get secured and reliable data about token price from various on and off-chain markets.
“Bancor V2 enables the creation of AMMs with pegged liquidity reserves, which seek to hold the relative value of tokens in the AMM constant. Oracles are used to adjust the pool’s weights and fees to incentivize arbitrageurs to bring value back to the pool when a deficit occurs, mitigating impermanent loss for both stable and volatile tokens.”
Front-running
Decentralized finance is very similar to the traditional financial market in some cases. One thing which can help to feel so is a perfect adoption of front-running strategy to the DEXs. In traditional markets, such attacks can be implemented only by a certain close group of people. In DeFi the market is open for everyone which makes it even more vulnerable to such inequities.
Front-running attack occurs when the one makes a profit out of performing his transaction before another participant while knowing about such transaction in advance. In the DEX environment, such attacks performance is available for everyone, meaning both traders, arbitrageurs and miners. Yet, the miners have the easiest way to perform this, due to having a right to choose an order of transactions in the block.
In order to conduct such an attack, Trader A firstly checks the existing orders on the DEX like Uniswap. If he finds any, which can considerably change the price in the pool, he simply buys this asset at a lower price. Then, put his order before Trader B by setting a high gas price. Such action forces Trader B to trade at a disadvantageous price and the difference goes to Trader A pocket.
Let’s close up and put some numbers in order to better understand this. Imagine Trader A wants to sell 50 ETH for 5000 DAI (when 1 ETH = $100= 100DAI). This transaction will influence the pool price and move ETH price down to 98DAI for 1 ETH. Malicious Trader B sees the order placement, adds more gas fee to his transaction, and performs trade before the Trader A. As long as an order has been placed already, Trader A has no influence on it. Such insolent interruption leads to the price falling and leaves Trader A with a 2DAI loop for each ETH in a wallet (taking 4900 DAI instead of 5000 DAI).
Moreover, according to the CPMM curve, the price in the pool is lowered now. Trader B can sell 50 ETH again to the pool for around 99DAI per each, so pay 4950 for it, instead of earlier mentioned 5000. The profit of a malicious Trader will be 50 DAI (minus fee) in such case.
The unperfect mechanism allows for a quite simple profiting from others’ disadvantageous prices which made front-running a very serious problem.
0x Protocol solution
One of the first on the way to confront front-running was 0x Protocol. They have proposed a unique so-called commit-reveal scheme that divides the transaction approval process into two layers.
The first part lays in detecting an appropriate order by Trader and committing to fulfill this. The important issue here is that the intention is sent to the blockchain, but remains “secret” for other participants.
The next step is to once again send the transaction to the blockchain, but include the full information about the order they committed to. This time also includes the “secret” which proves the eligibility to certain orders they have chosen in step one.
Unfortunately, despite eliminating the front-running issue, this approach faces some serious troubles. One of those is a trade collision in case of huge traffic within the protocol. The other problem is the “taking back” order, when, for instance, a trader cancels the order at a time after the commit but before the reveal step. This needs an advanced and various failure option being added to the smart contract code, which makes it vulnerable to detrimental attacks.
Enigma solution
Next solution to the front-running problem was introduced by Enigma Protocol. It proposes a system, which can integrate into existing DEX and help in preventing front-running attacks. Enigma enables to create a safe and secret environment for traders while building a protocol where users and workers nodes cannot see transactions in the network.
In other words, the pool with unprocessed blocks remains secret, so no one can guess the transaction orders and amounts. A DEX can integrate with the system in two ways: first is eliminating race conditions most exchanges have while utilizing a decentralized coordination system. The second option is to create an order matching logic through Enigma smart contracts.
Conclusion
Front-running and impermanent loss are the biggest problems of the decentralized finance market. In some cases, they may be also considered as the main obstacles on the way to wider acknowledgment and usage of DeFi in general. That is why, the efforts and solutions, which have been recently introduced, made a huge step on the way to confronting such problems.
Thinking of building your own front-running resistant dApp? Contact Blaize to get your project estimation!
Additionally, the issue of front-running is not limited only to decentralized finance and has been well-known in traditional trading practice. In fact, as we can observe now, newer protocols take the front-running problem seriously and put a lot of work into its elimination. Such a successful practice in its prevention may take DEXs to the next level and increase liquidity flow even more.
In Blaize we specialize in building decentralized apps from scratch as well as in integrating blockchain solutions into existing systems. If you consider building your own DEX or integration with such protocol as Enigma contact us in order to discuss further cooperation!
Article source: Blaize blog https://blaize.tech/article-type/overview/amm-solutions-to-impermanent-loss-and-front-running/
