Site icon Blaize

Solutions to Impermanent Loss and Front-running in DeFi

From this article you will know how to avoid impermanent loss and front-running problems in DeFi and successful solutions to those.

The main driver for new development opportunities in DeFi was the presence of certain problems connected to liquidity loss. Such problems as impermanent loss and front-running are also considered as the main prevention of 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.  Looking ahead, the fastest and most efficient way to avoid impermanent loss is to use stablecoins that do not lose value over time. But, let’s talk about everything in order.

Impermanent loss problem explained

In most traditional examples of DEX 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 liquidity pool. To better understand the impermanent loss issue, let’s take an easy example. 

Assume the 50/50 ETH/DAI pool with the 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. In this case, the liquidity pool is considered balanced and gives an ideal environment for the trade. 

Find out more explanation about various types of AMM mechanisms in our previous article AMM Types & Differentiations

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.

Liquidity loss example

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). If those do not act on time, it may cause a huge liquidity loss. Read: How to Prevent Liquidity Vampire Attacks in DeFi

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 

What is impermanent loss?

As we see in the impermanent loss example above, 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. (Impermanent loss was one of the main problems in the first version of Uniswap).

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 liquidity 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 liquidity 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.

SOLUTIONS to Impermanent loss problem

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 problem mitigation and elimination. One of them is to hold your money in stablecoins.

1. Curve.fi

The problem of impermanent loss in crypto 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. 

Read more about Curve and other Defi projects in our article Top 10 Successful DeFi Startups You Should Know About

2. Balancer

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 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 multiple token pools 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. 

Balancer pool with unequal amount of tokens mitigate the impermanent loss
Balancer pool mitigating possibility of impermanent loss

3. Bancor

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 the 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”.

Bancor

Front-running problem explained

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. 

What is front-running?

Front-running attack occurs when the one makes profit out of performing his transaction before another participant while knowing about such a transaction in advance. In the DEX environment, such attacks performance is available for everyone, meaning both traders, arbitrageurs and miners. Yet, it is worth mentioning that due to having a right to choose an order of transactions in the block, miners have the easiest way to make a front-running attack.

Liquidity loss example

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 the 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. 

Front-running attack in traditional DEX

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. More explanation of the front-running problem in DeFi might be found here.

Solutions to Front-running problem

The unperfect mechanism allows for quite a simple profiting from others’ disadvantageous prices which made front-running a very serious problem.

1. 0x Protocol

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 order they have chosen in step one. 

Unfortunately, even while eliminating the front-running attack 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 make it vulnerable to detrimental attacks. 

Read Also: How to conduct audit for smart contracts

2. Enigma Protocol

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 blockchain 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 (learn more about DeFi derivatives). 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 DeFi app resistant to front-running attacks? Contact us and get a FREE 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 enterprise blockchain solutions into existing systems. If you consider building your own DEX eliminating impermanent loss and front-running problems or integration with such protocol as Enigma contact us in order to discuss further cooperation!

Frequently Asked Questions

Is it possible to build an app resistant to front-running attacks?

Yes. The Blaize team has 5+ years of experience developing highly secure dApps, DEXes, and protocols. We always follow industry best practices to make sure that your platform is resistant to all known types of hacks, including front-running attacks.

How to quickly calculate impermanent loss in DeFi?

To calculate impermanent loss, you can use one of the calculators available online. But please note that most of them do not take into account transaction fees, so you should add them to the impermanent loss result. 

Is it possible to reduce impermanent loss in crypto?

Sure. There are several existing solutions to impermanent loss. The easiest one is to hold your crypto in stablecoins, of course. But if you are not interested in that, you can use one of the protocols that have solved this issue, such as Curve.fi, Balancer, or Bancor.

Exit mobile version