We've introduced the idea of impermanent loss before and let's actually go through it again in the context of Uniswap. Again, the idea here is liquidity providers. They supply the capital. Because of the nature of this constant product automated market maker, there will be some impermanent loss as the exchange rate actually changes. We went through some calculations before as to how this works. Even though the liquidity providers are earning, a rate of return based upon the volume of trading within the pool. There's also a cost associated with this in terms of the impermanent loss. Let's go through that again we went through it quickly in the previous course. The impermanent loss is an opportunity cost. It is the amount of money that the liquidity provider would have made if they didn't pledge liquidity to the liquidity pool but just sat on it. So it's an opportunity lost. It will happen anytime there's a deviation from the initial market price, ratio for the two, and the only way that there's no impermanent loss is if that ratio stays the same. That's essentially important for impermanent loss. Again, the fees hopefully will overcome the impermanent loss but nevertheless, this is one of the downsides of any constant product automated market maker. One way to reduce impermanent loss is to look at pairs that are highly correlated. When the pairs are highly correlated are mean reverting, then there's going to be not that much deviation and exchange rate and the impermanent loss is going to be very small. The examples that I used in the previous course were dramatic examples where something went up by 400 percent and something else went up by 200 percent. It's a huge gap between the performance. Literally, one of the pairs doubled relative to another pair. If you think of a low volatility or high correlation pair, like DAI and USDC, that's just not going to happen. The impermanent loss is very low for a very highly correlated pair. Impermanent loss is something that is well-known in the space, so people providing liquidity understand impermanent loss. They understand that they need to take that into account in factoring and what the expected rate of return is. They also understand that high correlation pairs, minimize that and there's some protocols that just focus on high correlation pairs. But the problem is that people want to trade cryptos well beyond the high correlation pairs. There's only so much you can do with USDC and DAI. This impermanent loss is just something that we have to deal with. Essentially, almost any ERC-20 pair is possible on Uniswap. This is super interesting that anybody can start a pair, so ERC-20 to ERC-20. You've got a new token that you're introduced, well, you can seed it in a Uniswap pair. It's instantly available for trade. Think about that in traditional finance. How difficult it is to actually get a stock listing. Only a very small number of companies can actually do this, and they have to go through a very costly process to actually be traded. Well, with Uniswap, it's immediate. You can actually just create a liquidity pool and it might be that you've got a new token, you create many of these pools, and it's available for trading in terms of this decentralized exchange. One thing that's interesting is that this is designed for all ERC-20 tokens and Ethereum is not an ERC-20 token. These tokens are based upon the Ethereum Blockchain, but Ethereum isn't an ERC-20. Is that a problem? No. Because there are wrapped versions of Ethereum, so w-ETH. We'll talk about wrap versions a little later on, but it's just a way to tokenize Ethereum. There's a wrap version of Bitcoin also that operates as an ERC-20 within the Ethereum Blockchain. Indeed, that is the one we'll talk about a little later. Within Uniswap, the way it works is that if you've got the Ether, you can actually use it, but it's immediately translated into the wrapped version of ETH, which is the ERC-20 tokens. Router contracts, that's one of the words on the word cloud that we'll reveal at the end of this course. How is this useful? Well, it might be that you want to trade a pair that isn't available on Uniswap. You want to do AB, but AB isn't available, but there is an AC and there's a BC, so effectively what you can do is to triangulate and find the best route through the different pools to get the exchange that you actually want and this is done with a router contract. Even if the pair isn't offered, that doesn't mean you can't trade it within this decentralized exchange, you just need to employ a router contract that can do this very efficiently. We talked a little bit about front running previously and I want to go back to that. This is an issue with automated market-makers, it is an issue with proof of work in general, in that the miners can see all of the pending transactions. It could be that there's a pending transaction that takes advantage of an arbitrage opportunity, maybe it involves a flash loan. Well, the miner can literally just copy that transaction and put that into the candidate block that they're mining and effectively front run. Again, I want to emphasize that this type of front running is not to be confused with the illegal front running in traditional finance. This is not illegal because all of the information is publicly available. This is public and the miners are willing to do this, but they want to do this because this is a way to increase their revenue. Again, this is a downside proof of work that will likely be mitigated in the future when we actually go to a proof of stake type of model. I also want to emphasize that it's not a sure thing, that the miner might front run, but the miner might not win the block and if they don't win the block there's no front running. The problem exists when many miners are doing the same thing, they see the same opportunities. Again, the memory pool of all the candidate transactions is open for anybody to see, is very straightforward, you need a browser you're in and you can see all of this. This is their game within this particular system. Uniswap also offers something interesting, which is maximum slippage. Essentially within the transaction, you can say that if the rate slips to anything below x, then don't execute the transaction. This is easily done and essentially it is a check in the contract and if the condition where the slippage is above the maximum, then the transaction remember is atomic and it doesn't actually do the trade, so we revert to where we were. That's a nice idea within this idea where you can specify a level of slippage that you're comfortable with and it provides a degree of risk management that's important. There's lots of possibilities here for arbitrageurs because there's so many of these pools that are available, that you can imagine I told you about a router contract that if you've got a pair that isn't traded, you can find other pairs to triangulate and effectively trade. Instead of just running on one liquidity pool, you have to do multiple. Well, there's also this possibility of seeking out arbitrage possibilities given the network of all of these exchange rates. This is maybe a drawback, but maybe not because the arbitrageurs are making sure that the prices are what they should be, and they shouldn't deviate, there shouldn't be any arbitrage, and just the act of arbitrage is actually making those prices more fair. But nevertheless, this is something that essentially the arbitrageurs are profiting at the expense of the liquidity providers and ideally you want the prices set in a way that minimizes this possibility. Of course, a lot of liquidity is very helpful, but there could be some pools that are illiquid that cause issues and an arbitrage obtains.
