How Lien FairSwap works

Lien Protocol

Published in

Lien

6 min readApr 30, 2020

Lien FairSwap White paper: https://lien.finance/pdf/LienFairSwapWP_v1.pdf

To fellow DeFi enthusiasts,

Today you will learn about some of the basic ideas behind Lien FairSwap, whose white paper was published just recently. If you want to understand how Lien FairSwap works in depth, check out the white paper!

tl;dr: Uniswap🦄 + Front running prevention with frequent batch auction ✋+ Dynamic Fee Pricing based on Volatility📊 = Lien FairSwap

If you are reading this article, you might probably be familiar with Uniswap. In case you are not, here is a high level overview on how Uniswap works:

A liquidity provider pools ETH and an ERC-20 token for which it’s providing liquidity, with the pool’s value equally split between the two (i.e. ETH and the ERC-20 token both account for 50% of the pool’s value)
The liquidity provider sends you the token in exchange for ETH and vice versa.
Each token exchange is conducted in such a way that the product of the amount of ETH and that of the token is kept at a constant value “k”, hence the name of the protocol model (Constant Product Market Maker model). This is also called the “Automated Market Maker” model as the price determination is conducted automatically.
A 0.3% fee is deducted from each transaction. The fee will then be distributed to the liquidity provider.

Uniswap boasts the highest volume amongst Ethereum-based decentralized exchange (DEX) platforms as of April 30, 2020:

Now, we cannot have LBT, a derivative token implemented within the Lien protocol, listed on Uniswap because the pooled fund on Uniswap cannot be withdrawn; since an LBT returns ETH to its holder on the contract maturity date, the token has to be available for withdrawal on the maturity date. For this reason, you should NOT pool LBT on Uniswap even if you want to!

Also, there are two additional issues when it comes to creating a Uniswap-like marketplace for LBT.

Front-running

First, there is the issue of front-running.

Front-running is a practice whereby a trader (Trader A) makes a profit by doing the following:

See a (market) order submitted by another trader (Trader B)
Execute a trade before Trader B
Have Trader B trade at a disadvantageous price
Execute a reverse order for a profit

To illustrate this, let’s look at an example.

Suppose Trader A has observed a transaction broadcast by Trader B to sell 50 ETH for 10,000 USDC, with the price slippage limit set to 1%.

Now, if Trader A wants to engage in front-running, he can sell ETH and wait for its price to go down until it reaches 198 USDC/ETH, which is the lower price limit given the slippage limit of 1%. On the Ethereum blockchain, you can have a transaction processed earlier than other transactions by setting a high gas price for it than the other transactions. Here, let’s say Trader A has successfully executed a trade for selling 50 ETH for 10,000 USDC (1 ETH = 200 USDC) before Trader B by configuring a higher value for the transaction’s gas price, causing the ETH price to fall (1 ETH = 198 USDC).

As a result, Trader B ends up selling 50 ETH at the price of 198 USDC/ETH, gaining 9,900 USDC rather than 10,000 USDC he initially expected.

Finally, Trader A can buy back 50 ETH at (for example) 199 USDC/ETH, selling 9950 USDC in total. Trader A is now left with 50 ETH and 50 USDC, resulting in the 50 USDC profit.

Of course, you will have to work with more messy numbers if you use the actual formulas used by the Uniswap protocol but the above example can give you an idea of how you can make a profit through front-running; you can make easy money simply by acting quickly and having others execute a trade at a disadvantageous price.

While Uniswap is trying to mitigate the issue by implementing a price slippage limit for each order, the fact remains that you still have the ability to engage in front-running to other trader’s disadvantage. The issue of front-running is not limited to decentralized exchanges that adopt order books in their trading platform. In fact, the practice is widely prohibited in the traditional financial industry as well.

Because profits made from front-running will increase as the amount of money at stake grows, the fact that people are able to conduct front-running is something that could hinder the future growth of the LBT market.

Volatility

Another issue that arises in the context of trying to have LBT available on Uniswap is that a liquidity provider on Uniswap suffers losses when the market volatility is high.

For example, let’s assume that everyone in the world is looking for arbitrage opportunities. Now, if the ETH/USDC exchange rate outside the Uniswap platform shoots up in an extremely short period of time, the rate on Uniswap would not be updated immediately until people start to engage in arbitrage activities on Uniswap. Here, if people decide to trade the ETH/USDC pair in a way that results in adjusting the rate on Uniswap to the lower market rate observed outside Uniswap, the liquidity provider will end up selling ETH at a disadvantageous price that is higher than the general market price.

Of course, the liquidity provider can collect fees from the transactions but the arbitragers will take into account those fees and make sure that they can still make a profit through those transactions, causing the liquidity provider to suffer losses as a result.

For this reason, an ideal situation for the liquidity provider would be one where people are trading without looking for arbitrage opportunities and the market volatility is relatively low. In this situation, the liquidity provider can rest assured knowing that they can make a profit they expect from each transaction rather than having to worry about losing money due to people conducting arbitrage activities (you can also read this paper for a more detailed analysis on Uniswap).

That said, it’s true that a DEX with a Constant Product Market Maker is really attractive from the usability point of view.

Therefore, we have decided to create Lien FairSwap, a token swap protocol which is based on the Constant Product Market Maker model and attempts to eliminate the above issues as much as possible.

Frequent batch auction: Solution to front-running

We have decided to implement the concept of frequent batch auction, a mechanism which is adopted in traditional financial markets as a countermeasure against front-running or other issues stemming from high-frequency trading. In simple terms, frequent batch auction is a mechanism by which transactions are processed in particular intervals rather than serially as a transaction comes. For example, some financial market might set the interval to 0.1 seconds, meaning transactions are processed every 0.1 seconds.

For the Ethereum blockchain, on which Lien FairSwap is implemented, the interval would correspond to the block number. Here, transactions that occur in the same interval are put into the same group. This ensures that transactions contained within the same block are treated “equally” (i.e. the order by which they have been included in the block doesn’t matter), thereby preventing front-running from occurring.

For more details on frequent batch auction, please read the white paper (p. 13).

Dynamic fee pricing based on volatility: Solution to the volatility issue

In order to solve the issue of a liquidity provider incurring losses in a high volatility environment, we have implemented a mechanism for dynamically adjusting fees based on the market volatility.

You can actually see this implemented in existing exchange platforms where higher volatility leads to widened spreads due to an increased risk that market makers might suffer losses in such a market condition. This mechanism for increasing spreads can be applied to the implementation of the fee adjusting mechanism mentioned above, which helps to make sure that liquidity providers in Lien FairSwap can continue to operate profitably even in a highly volatile environment.

The protocol will reference a reliable oracle (e.g. ChainLink) for the ETH price, evaluate the volatility of the ETH/USD rate, and then compute the implied volatility (IV) of LBT. See the white paper (p. 27) for more details.

Under the current implementation, the required amount of gas is expected to be somewhere around 200,000 Gas. The exact value will depend on each transaction.

While our implementation would be less inefficient than Uniswap in terms of gas fees, we believe it will provide a much more efficient mechanism than other DEXs while ensuring that proper protections are put in place against the issues often seen in existing DEXs.

(Estimated amounts of gas required for a transaction on some major DEXs shown below. Exact values vary depending on the transaction)

How Lien FairSwap works

Front-running

Volatility

Frequent batch auction: Solution to front-running

Dynamic fee pricing based on volatility: Solution to the volatility issue

Written by Lien Protocol