Problems of Decentralized Exchanges
While decentralized exchanges are an important mosaic block in the blockchain ecosystem, they face some problems. Here, we explain the most common problems of decentralized exchanges, such as:
- Front-running
- liquidity
- degree of centralization
- bugs
Front running
Front running means that an actor can influence the transaction order in a block. The only nodes that can determine the transaction order are block producers since they create the blocks.
If a block producer observes a transaction Tb that is a buy order at 100 coins for 1000 tokens and there are current sell orders at 90 for the same volume, the block producer can squeeze two transactions before transaction Tb. In the first transaction, the block producer buys up the sell order at 90 and in the second transaction, it sells the assets at 100 to the transaction Tb. The profit for the front-running block producer is the difference between the buy price and sell price minus transaction fees and exchange fees.
A buy order without frontrunning.
The block producer inserted a buy and sell transaction (marked yellow) before the original buy order.
Degree of (De)centralization
Some smart contracts allow interference of central elements. This can reach from earning fees to shut down the smart contract completely. Central elements introduce the risk of a single point of failure.
Impermanent Loss
Let us assume a liquidity pool of a decentralized exchange contains A tokens and ETH. When funding the pool, 1 ETH was worth 100 Euro, and 1 A token was worth 100 Euro too. As a result, the ratio in the liquidity pool must be 1.
If there are 100 A tokens, there must be 100 ETH in the liquidity pool.
If the smart contract applies a constant product function, 100 * 100 = 10,000 = k.
Now, the price of the A token goes up from 100 Euro to 200 Euro. The price of the ETH remains constant. This change is also reflected in the liquidity pool since arbitrage traders buy the underpriced A token until the A token-ETH ratio equals the market price.
The liquidity pool now contains 70.7107 A token and 141.4214 ETH. The product is still 10,000.
How much is the liquidity pool now in Euro?
70.7107 A token * 200 Euro/A token + 141.4214 ETH * 100 Euro/ETH = 28,284.27125 Euro
This is a profit of 8284.27125 Euro compared to the time before the price change.
But what if the liquidity provider would have kept its initial 100 A tokens and 100 ETH? The Euro value would be 100 A token * 200 Euro/A token + 100 ETH * 100 Euro/ETH = 30,000 Euro. This is 1,715.73 Euro more than the content of the liquidity pool.
A liquidity provider would have to earn more in fees than this amount to be profitable. Impermanent loss is a problem and can prevent users from providing liquidity to curve-based exchanges.
Impermanent Loss Calculator
| Hold Value | Arbitrage adjusted Pool Value | Impermanentloss | 1111 | 1111 | 1111 |
|---|
Bugs
In DeFi, smart contracts store a large amount of tokens. This makes them an alluring target for hackers. As long as a smart contract is coded error-free, this is no problem. But in some cases, unforeseen mistakes happen. Attackers can exploit those bugs and steal or destroy large amounts.
In smart contracts, bugs are even more critical than in common software since everybody can see their code and try to find weaknesses. Besides that, transactions cannot be undone. And even if the creator or honest hacker discovered a bug, it is difficult to fix if the concept of decentralization is taken seriously. If a smart contract is updatable, it requires at least one (central) authority that is allowed to upload changes. And this again is a central point of failure.
Vampire Attacks
A large liquidity pool reduces slippage, contributing to a better user experience. That’s why decentralized exchanges that work with pricing curves not only compete for customers but also for liquidity providers.
Let us now assume that we have an established decentralized exchange and a newcomer. The newcomer has the problem that no liquidity provider would deposit any liquidity because there are not traders. And traders would not have any reason to trade with the newcomer because there is no liquidity. It is a typical hen-and-egg problem.
To understand the vampire attack, one must know that liquidity providers earn so-called liquidity tokens (LP token) representing their share of the pool.
The newcomer could now allow liquidity providers to stake LP tokens from the established exchange. In return, the liquidity providers would earn a fraction of the newcomer’s earnings. The newcomer then exchanges the LP token for the underlying assets like ETH, DAI, etc., and transfer this to its own exchange.
Since it is technically not difficult to set up a vampire attack it could be difficult for users to find reliable services as they might change quickly.
