“The DeFi space is moving so fast that parts of this episode have become somewhat outdated since the time of recording, which was not even a week before this episode comes out. For one, I say that dex trading volume has 8Xed in August from the beginning of the year, and by now, a few days after we recorded, its 10Xed.” (Laura Shin on Unchained with Haseeb Qureshi and Dan Robinson).
For the TL;DR people: Scroll down to Summary.
With the DeFi space tremendously growing we also saw the incredible growth of decentral exchanges (DEX), particularly Uniswap.
However, due to certain attributes natural to blockchain technology the most widely used DEXes like Uniswap are vulnerable to so-called Front Running.
Front Running is an arbitrage strategy that basically leads to a user having to pay a higher price than the market actually needs him to pay.
This seems like an unfair and inefficient situation that resembles an obstacle on the road to decentralized exchanges breakthrough and therefore demands a fairer and more efficient solution.
In two previous articles on the Lien protocol, I explained how Lien built a better and new kind of stablecoin by creating two kinds of derivative tokens that are in and of themselves attractive to be traded.
However, since the trading of LBTs is required for the iDOL system to function, the team behind Lien intended to create a liquid and truly fair market place. They, therefore, created FairSwap, a DEX which is capable of preventing current decentralized exchanges’ biggest problem of front running and hereby providing a marketplace where digital assets can be traded at a truly fair price.
This article will explain to you why your normal Dex or Dex aggregator is not what it could be and how bots are literally stealing away your money. It will explain to you the inefficient design of current decentral exchanges and especially elaborate on how FairSwap is designed to mitigate this inefficiency.
Decentral exchanges are vital for the future of Defi but being a money-making platform for the very few that know how to operate front running bots will prevent them from succeeding.
Therefore a system like FairSwap will form the next generation of decentral exchanges.
So let's start. First some basics.
1. Constant Product Market Making Model
To understand what a Dex does, you need to know what the Constant Product Market Making Model (CPMMM) is. First and foremost it is what FairSwap as well as the most successful DEX Unsiswap is based on.
In the CPMMM, somebody called a Liquidity Provider (LP) or Market Maker can open up a new market and provide an opportunity to exchange two assets. Within the lien system, the team plans to open marketplaces for exchanging ETH, iDOL, and LBT with support for various maturity dates. However, for the sake of explaining, I will take a hypothetical token “ABC” and look at how the liquidity provider within this marketplace can allow us to “buy” and “sell” the ABC token in exchange for ETH.
In contrast to the designs of traditional stock exchanges, the CPMMM does not prespecify the asset price (e.g. the ETH/ABC exchange rate) but instead algorithmically “adjusts” the price based on the inputs from buyers and sellers so as to eliminate arbitrage opportunities.
This works as follows:
- A liquidity provider opens up a marketplace by providing pools for the two traded assets (ETH and ABC).
- Any user can submit a buy order (i.e. send ETH into the ETH pool and take ABC from the ABC pool) or a sell order (i.e. send ABC into the ABC pool and take ETH from the ETH pool) to the marketplace.
- If we assume X ETH and Y ABC to be currently pooled, then the price of the ABC token (denominated in ETH) is determined by the ratio of X to Y. For reasons of simplicity, we ignore the commissions paid by users to the liquidity provider for now.
- To place a buy order, the user transfers the amount of “value” (ETH) he wants to exchange. After receiving ∆x ETH from the user, the marketplace determines ∆y ABC, the amount of ABC tokens the user can receive by solving the following equation: (X+∆x)(Y −∆y)=XY.
- The product of the two factors remaining constant gives the Constant Product Market Maker Model its name. It always holds constant the product of X and Y, or the amount of ETH and ABC held by the marketplace.
- Solving the above equation for ∆y, we have:
Hence, the price (i.e. the price of ABC denominated in ETH) to obtain the ABC token will be:
Obviously, the ABC tokens price will increase as ∆x increases meaning the more ABC the user wants to buy, the more ETH he has to pay. Therefore, the ask price = best possible price proposed by the market maker to a buyer of the ABC token is X/Y ETH/ABC.
In that same manner, we can derive the best price proposed to a seller. If the user transfers ∆y ABC to be sold in the marketplace, the amount of ETH provided by the marketplace (∆x ETH) is calculated with the following equation: (X-∆x)(Y +∆y)=XY.
- Solving for ∆x, we get:
Hence, the price the marketplace pays to the user is:
This price obviously decreases as ∆y increases, meaning that the more the ABC the user wants to sell, the lower the price of each token will be. Consequently, the bid price = which is the best possible price proposed by the market maker to a seller, is X/Y ETH/ABC.
So while we ignore the commissions paid to the validators and the liquidity provider we can see that the CPMMM model always allows for buying and selling the ABC token at the price of X/Y ETH/ABC. If the price for ABC outside our market differs from within the market, a user can take adventage of the arbitrage opportunity always resulting in an overall ratio of X to Y being fixed immediately.
Therefore, the CPMMM can always propose a fair price to the users.
2. Front Running
So much to the model that most of the common DEXes use to provide liquidity at a fair price. In theory…
However, the past has shown us that this is just a theory and that the price actually is not fair. This is because, in its current form of implementation, arbitrage bots can exploit the natural attributes of distributed ledger technologies and hereby artificially increase the users buying price to an unfair price.
This so-called Front running strategy is currently the biggest inefficiency of decentral exchanges and is prevented through Liens FairSwap by design. To give you an understanding of how FairSwap does this, you need to know how front running works:
Consider the following properties that are associated with distributed ledger technologies:
- Transactions on a blockchain are processed in a discrete manner:
The Ethereum network adds a new block every 10 to 20 seconds, meaning transactions are never processed immediately — even in the best-case scenario, a user needs to wait for the next new block to be added to the blockchain before his transaction can be processed. - Pending transactions are publicly visible:
All pending transactions are stored in a public mempool, from which validators pick transactions to create a new block. The mempool is public so that anybody can easily check the details (gas price, value etc.) of the pending transactions. As a result, they can observe the orders sent to Uniswap along with their details. - Lastly, users can control the order of transaction processing.
Usually, validators on the Ethereum network put transactions in descending order based on their gas prices (=fee they receive = their incentive to validate). This allows users to select the relative position of their transactions within a new block by configuring the gas price and hereby make validating particularly their transaction more attractive.
The validator can freely choose the order in which he will validate the transactions but will most logically do so in an order that is most profitable to him. Configuring the gas prices will therefore allow to influence the order in which transactions will be validated.
These three attributes of the Ethereum blockchain allow and arbitrager to exploit a DEX like Uniswap by doing the following:
- Front running opportunities arise whenever a user (who is different from the arbitrager) conducts a high-value transaction. Suppose that the ask price proposed to a user was P0 and that he decides to submit a large buy order.
- This order will now be stored as an Ethereum transaction in the mempool and will not be immediately processed (Attribute 1).
- The arbitrager can now find this order with all its details (gas price, value etc.) in the public pool (Attribute 2) and send in his buy and sell order with approximately the same value.
- He will then adjusts the gas price of his orders in such a way that the transactions are processed in the following order (Attribute 3):
1. The arbitrager’s buy order
2. The user’s buy order
3. The arbitrager’s sell order - Since the arbitrager’s buy order is processed first, the ask price P1(> P0) proposed to him, is close to the users ask price P0.
- However, since he made a large buy order (1), that is processed first, the ABC tokens price will increase so that the actual user is presented with a higher, and less desirable, price, P2(> P1 > P0).
- After 1 and 2 are processed/validated by validators, the arbitrager’s sell order (3) is processed. Since the price has now increased due to his buy order he will now benefit from that higher price to make a profit by selling at P3 (P2 > P3 > P1).
In a nutshell, front running means that arbitragers can effectively use the blockchains specifications and exploit systems like uniswap to buy ABC tokens at P1 and sell them at P3. This means, that actual users end up buying the ABC token at a higher price than necessary and losing money to the arbitrager. This situation seems like an unfair one and is successfully prevented by Liens FairSwap.
3. Price Slippage Limit
What allows front running to happen is that a system like Uniswap is adjusting the price too often (every time the marketplace finds a new order) compared to the frequency at which blocks are validated (20–30 sec).
The user sent a buy order, after he observed P0 as the ask price. However, the actual price proposed to the user (P2) turned out to be different from (and higher than) P0 because of the arbitragers manipulation. This difference between P2 and P0 is called price slippage.
Uniswap mitigates the front-running problem by allowing users to cancel orders when the price slippage results in too large a price discrepancy.
The user is allowed to refuse to buy the ABC tokens when the price is higher than (1 + ε)P0, where ε > 0 is the maximum price slippage (slippage limit). Through this, the arbitrager is discouraged from buying a large number of tokens because he cannot make a profit when the user’s buy order is canceled
Even though the arbitrage opportunity remains, the arbitrager has to act within the following constraint: (1 + ε)P0 > P2 > P3 > P1 (> P0). So, if ε is close to zero, the profit an arbitrager can make as well as the loss the user incurs will become close to zero.
However, this price slippage limit solution has a severe drawback:
- To completely exclude front running opportunities users must not tolerate price slippage. However, price slippage always occurs whenever new orders are processed. Tolerating it is necessary for a well functioning market place. If not tolerated we can think of an extreme case where all successive transactions in one block are canceled after the first transaction causes the critical price slippage. This means that in that extreme case the marketplace could only process one transaction per each block which in turn means that only one user can make a trade for every 10 to 20 seconds. Obviously, such a system fails to provide enough liquidity to the market.
- This poses a dilemma. Front running causes price slippage and to prevent front running, price slippage would have to be forbidden. However, price slippage is necessary for a liquid market so that there will always be front running in the Unsiwap model as long as we allow for the necessary 1 + ε.
Lien FairSwap:
Now to the important part. How is the new DEX FairSwap designed so that Front running is prevented while the required slippage is provided?
Frequent Batch Auction
FairSwap will as well be based on the CPMMM but will furthermore incorporate the idea of so-called frequent batch auctions. This is believed, to be an improvement over the CPMMM as it is implemented in Uniswap and others. The difference between Lien’s model and the original CPMMM is that it does not process transactions serially but forms a batch of transactions to process them simultaneously. This design will make Lien FairSwap robust against front-running.
Exchange Box
Because FairSwap makes use of the frequent batch auction mechanism, it does not process orders one by one but rather batches all orders from several neighboring blocks in a so-called exchange box to then clear these orders within that exchange box simultaneously. Orders included in the same exchange box are cleared with the same price.
The cool thing about this is that batching eliminates the possibility of manipulating the transaction order.
Putting orders in an exchange box and clearing all orders within one box at the same time makes the order by which they have been sent irrelevant. FairSwap can therefore ignore the sending order of transactions so that arbitragers cannot exploit normal users by sandwiching transactions, making the front-running activities unprofitable.
Another advantage
Of course, although FairSwap is resistant to Front running, it allows its users to cancel transactions if users find the natural and necessary price slippage to high. However, since Fairswap is resistant to front running, we can set the parameters for slippage tolerance (parameter that determines when the price slippage limit is reached and orders are canceled) to higher values than traditional Dexes. This means that fewer orders are canceled because of reaching the price slippage limit so that FairSwap is capable of processing more transactions much faster.
To be continued
The implementation of the Frequent Batch Auction mechanism allows to clear transactions from several blocks at the same time, which also means that we have to clear buy and sell orders at the same time. Because of this, the formula for the clearing price has to be adapted. This new clearing price, the consideration of commissions for the liquidity provider, the price slippage limit and the technicalities of the clearing procedure will be subject to Article number 4. Like everything else in this article, you can already find these contents in Lien's second whitepaper.
Summary
So what is FairSwap?
FairSwap is a new decentralized exchange that is designed to make sure that transactions are settled in a fair and more efficient manner by implementing the Frequent Batch Auction mechanism to prevent front-running observed on current exchanges like UniSwap.
In addition, the liquidity is provided through the CPAMMM (Automated Market Maker), allowing for Uniswap-like trading experience.
The result is a fairer and more efficient marketplace to exchange digital Assets (starting with assets used in the Lien ecosystem) without any kind of intermediary or bot that unnecessarily takes money/value from a user.
The main difference between Uniswap and FairSwap is that they have different ways of settling transactions which leads to FairSwap being the fairer and more efficient solution for a user.
- In Uniswap, transactions contained in the same block can have different settlement prices depending on the order in which they are included in the block. This allows the activity of front running bots or a very inefficient situation through price slippage limits.
- FairSwap transactions included in subsequent blocks are settled at the same price regardless of their positions within those blocks so that front running can be prevented and price slippage limits can be high to allow for faster and more settlements.
For all of you that bore with me: Thanks for reading and I hope you got what a big thing the whole Lien system is. Their stablecoin and DEX design will be a tremendous innovation to the DeFi space and will help the space to succeed in its mission.
As always comment below or contact me on Twitter for any of your questions. I am happy to answer them.
Also again the whole concept with all its formulas and graphics is developed by the Lien Team. I just tried to make their concepts more transparent!
Cheers.
