💾

MEV_and_trading/protocols/0x_protocol/README.md

@@ -0,0 +1,31 @@
+# 0x protocol
+
+<br>
+
+### tl; dr
+
+<br>
+
+* 0x request-for-quote (rfq), mev proof + zero slippage trades
+* all communication happens off-chain until settlement, making the system extremely gas efficient for market makers
+* trades are impossible to front-run or sandwich: no mev
+* trades have zero slippage, zero fees (aside from gas), and are settled at a predetermined price
+* highly capital efficient (max trade size = balance of market marker)
+* rfq liquidity is composable
+* off-chain orders, on-chain settlement
+* the `txOrigin` field must be set and enforces that the order can only be filled by the specified address - it is impossible for any other trader or bot to front-run the trade.
+
+
+
+<br>
+
+----
+
+### resources
+
+<br>
+
+* [matcha.xyz](https://matcha.xyz/)
+* [RFQ orders official guide](https://protocol.0x.org/en/latest/basics/orders.html#rfq-orders)
+* [0xv4 RFQ order guide](https://gist.github.com/lampshade9909/cf16b2aa198e4df8d00702ffd7bf506a)
+* [0x at mev.wtf](https://docs.google.com/presentation/d/1kde_3RPgHJP0vOP8GG92mlA7VtdGdHiGdrEGhFhx-5U/edit#slide=id.g465c39fec5_0_1309)

MEV_and_trading/protocols/0x_protocol/RFQ.md

@@ -0,0 +1,12 @@
+##  Request-for-Quote (RFQ)
+
+### tl; dr
+
+
+<br>
+
+---
+
+### resources
+
+* [0xv4 RFQ order guide in python](https://gist.github.com/lampshade9909/cf16b2aa198e4df8d00702ffd7bf506a)

MEV_and_trading/protocols/uniswap/README.md

@@ -0,0 +1,44 @@
+## [uniswap](https://uniswap.org/)
+
+<br>
+
+### tl,dr
+
+
+<br>
+
+* **AMMs** replace the buy and sell orders in an order book market with a liquidity pool of two assets, both valued relative to each other. as one asset is trader for the other, the relative prices of the two assets shift, and the new market rate for both is determined.
+* uniswwap is a peer-to-peer system designed for exchanging ERC20 tokens on the ethereum blockchain.
+* the protocol is implemented as a set of persistent, non-upgradable smart contracts; designed to prioritize censorship, resistance, security, self-custody.
+
+
+<br>
+
+---
+
+### in this dir
+
+<br>
+
+* [uniswap v2](uniswap-v2)
+* [uniswap v3](uniswap-v3)
+
+
+<br>
+
+---
+
+### resources
+
+<br>
+
+* [what's an amm, by coindesk](https://www.coindesk.com/learn/what-is-an-automated-market-maker/)
+* [uniswap docs](https://docs.uniswap.org/protocol)
+* [uniswap arb analysis](https://github.com/ccyanxyz/uniswap-arbitrage-analysis)
+* [uniswap extractooor](https://www.uniswap.shippooor.xyz/)
+* [dune for total uniswap users over time](https://dune.com/queries/2740)
+* [understanding amms by hasu](https://www.paradigm.xyz/2021/04/understanding-automated-market-makers-part-1-price-impact)
+* [mev's impact on uniswap](https://eigenphi.io/report/mev-impact-on-uniswap)
+* [quantifying the cost of providing liquidity to amms, by a16z](https://a16zcrypto.com/lvr-quantifying-the-cost-of-providing-liquidity-to-automated-market-makers/)
+* [automated market making and loss-versus-balancing, by j. milionis et al](https://arxiv.org/abs/2208.06046)
+

MEV_and_trading/protocols/uniswap/uniswap-v2/README.md

@@ -0,0 +1,74 @@
+## uniswap v2
+
+<br>
+
+### tl; dr
+
+* uniswap v2 introduced new features and optimizations in may 2020
+* each Uniswap liquidity pool is a trading venue for a pair of ERC20 tokens
+
+<br>
+
+<img width="500" alt="Screen Shot 2022-10-10 at 1 45 22 PM" src="https://user-images.githubusercontent.com/1130416/194949749-99a525c8-32f9-48bc-8ca3-e757120e35a1.png">
+
+
+* whenever liquidity is deposited into a pool, unique tokens known as liquidity tokens are minted and sent to the provider's address
+* if the provider is minting a new pool, the number of liquidity tokens they will receive will equal sqrt(x * y), where x and y represent the amount of each token provided.
+* to retrieve the underlying liquidity, plus any fees accrued, liquidity providers must "burn" their liquidity tokens, effectively exchanging them for their portion of the liquidity pool, plus the proportional fee allocation.
+
+<br>
+
+----
+
+### arbitrage opportunities
+
+#### 💡 check my [amm arbitrage toolkit](https://github.com/MEV-WAIFU-LABS/amm_arbitrage_toolkit) for a clean nice code on uniswap v2 protocol
+
+* let's chat about a bot looking for uniswap-like arbitrages which it could perform after the opportunity tx take advantages of liquidity disparities accross pools
+* a pool with X WETH and Y USDC allows users to swap WETH and USDC, the governing principle of the pool is that the product of X * Y is always constant (the uniswap invariant)
+* for a pool with reserves of (X, Y) we can work out how much USDC out we expect for selling delta X WETH
+* the pool also takes a fee of ~30bps (~0.3%)
+
+<br><img width="503" alt="Screen Shot 2022-10-16 at 12 29 14 PM" src="https://user-images.githubusercontent.com/1130416/196054290-ce741355-a9c8-470d-84e3-2f56ce2e3873.png">
+<img width="500" alt="Screen Shot 2022-10-16 at 12 29 22 PM" src="https://user-images.githubusercontent.com/1130416/196054291-0054d2f1-d4fe-46ed-8a4d-abb977c780cc.png">
+<img width="429" alt="Screen Shot 2022-10-16 at 12 29 43 PM" src="https://user-images.githubusercontent.com/1130416/196054294-a7699e6f-ad2c-41fc-93c2-705d2d4746fd.png">
+<img width="453" alt="Screen Shot 2022-10-16 at 12 29 50 PM" src="https://user-images.githubusercontent.com/1130416/196054295-7c5a6026-bfda-4468-ac42-d9f2519654e4.png">
+
+<br>
+
+##### bots step
+
+1. once we figured out how to perform swaps to max profit, the bot needs to acquire delta X of the initial token to perform these swaps (e.g. using a flash loan from aave)
+2. then the bot needs to bundler the flash loan plus both swaps and transfer of flash loan back to aave into a single tx (this can be done using a custom smart contract that is pre-deployed on chain)
+3. once the tx is created and signed, it's submitted to the mempool to be mined. there are many other bots searching for the same opportunities
+4. we want to ensure that our tx gets mined first, this means our arb tx should follow the original tx in the same block and be mined immediatially aftward. this is what's known as "back run".
+5. in order to achieve a back run, the bot needs to first understand the gas price that the original tx offered, and then needs to copy these exact parameters in the arb tx
+6. finally, the tx is signed and submitted to the mempool directly by the bot for validation and free money
+
+
+<br>
+
+----
+
+### lp burn
+
+<br>
+
+- liquidity providers (LP) provide the pool with the two tokens that can be exchanged (token0 and token1).
+- in return they receive a third token that represents partial ownership of the pool called a liquidity (pool) token.
+- the function burn() is called when liquidity is withdrawn, and the liquidity tokens need to be burned, it sends the destination address the underlying tokens in proportion to the burned tokens.
+- for example if there are 1000 token0, 500 token1, and 90 liquidity tokens in the pool. If someone gives 9 tokens to burn, this is burning 10% of the liquidity tokens, the user receives 100 token0 and 50 token1.
+balanceOf() function returns the token balance of the given address: balance0 = IERC20(_token0).balanceOf(address(this)) .
+address(this) refers to the address of the instance of the contract where the call is being made.
+- the amount of liquidity tokens to remove: liquidity = IERC20(lpToken).balanceOf(address(this));.
+- the totalSupply() function returns the total supply of the tokens. This means that the sum total of token balances of all of the token holders must match the total supply: uint256 _totalSupply = IERC20(lpToken).totalSupply().
+- for completeness, this is how LP tokens got minted:
+https://github.com/Uniswap/v2-core/blob/master/contracts/UniswapV2Pair.sol#L110
+```
+ if (_totalSupply == 0) {
+	 liquidity = Math.sqrt(amount0.mul(amount1)).sub(MINIMUM_LIQUIDITY);
+	 _mint(address(0), MINIMUM_LIQUIDITY); // permanently lock the first MINIMUM_LIQUIDITY tokens
+	 } else {
+	 liquidity = Math.min(amount0.mul(_totalSupply) / _reserve0, amount1.mul(_totalSupply) / _reserve1);
+	 }
+ ```

MEV_and_trading/protocols/uniswap/uniswap-v3/README.md

@@ -0,0 +1,45 @@
+## uniswap v3
+
+<br>
+
+### tl; dr
+
+<br> 
+
+- uniswap v3 introduced: 
+
+  * **concentrated liquidity** and **non-fungible liquidity**: 
+    * replacing fungible ERC20 liquidity positions with non-fungible ERC-721 liquidity positions. 
+    * individual LPs get granular control over what price ranges their capital is allocated to. 
+    * individual positions are aggregated together into a single pool, forming one combined curve for users to trade against.
+  * **multiple fee tiers**: allowing LPs to be appropriately compensated for taking on varying degrees of risk. 
+  * **range orders**: lps can deposit a single token in a custom price range, above or below the current price.
+  * **improvements to the TWAP oracle**: possible to calculate any recent TWAP within ~9 days in a single on-call chain.
+
+- new strategies:
+  * creating and closing LP positions can be a form of trading. range orders can be used as either buy-limit or take-profit orders. 
+
+
+<br>
+
+---
+
+### in this dir
+
+<br>
+
+* [just in time liquidity mev](just-in-time.md)
+
+<br>
+
+---
+
+### resources
+
+<br>
+
+* [uniswap v3 whitepaper](https://uniswap.org/whitepaper-v3.pdf)
+* [liquidity mining on uniswap v3 by paradigm](https://www.paradigm.xyz/2021/05/liquidity-mining-on-uniswap-v3)
+* [uniswap v3 book, by jeiwan](https://github.com/Jeiwan/uniswapv3-book)
+* [jit liquidity by chainsight](https://twitter.com/ChainsightLabs/status/1457958811243778052)
+* [conceptualizing uniswap v3 lp profit and loss](https://atise.medium.com/conceptualizing-uniswap-v3-lp-profit-and-loss-ecbae6e09644)

MEV_and_trading/protocols/uniswap/uniswap-v3/just-in-time.md

@@ -0,0 +1,41 @@
+## just-in-time (jit) liquidity 
+
+<br>
+
+### tl; dr
+
+<br>
+
+* **uniswap v3** comes with just-in-time (jit) liquidity, allowing LPs to provide concentrated liquidity within smaller price ranges, i.e., to specify a range of prices their liquidity is active for. this allows capital efficiency for correlated tokens.
+* the **liquidity range** determines the share of fees. however, the tighter the tick range, the greater the risk of impermanence loss (the greater the likelihood that the price of the asset pair will move out of the tick range to volatility), which would generate no fees).
+* a **strategy** is to scan the mempool for substantial pending trades, provide liquidity where a LP mints and burns a concentrated position immediately before and after a swap. no impermanent loss happens because everything happens within the same block.
+* because provision has **high costs**, it's usually only used against very large swaps (i.e., it's a non-atomic strategy).
+
+
+<br>
+
+### example cex + dex
+
+<br>
+
+1. consider a JIT LP that has ETH and USDC both in a wallet and in a CEX. 
+2. when the LP observes a large ETH -> USDC swap in the mempool, they deploy a LP position on Uniswap, and at the same time submit an ETH buy order on the CEX. 
+3. after both trades, the LP has the same total amount of ETH and USDC as before. 
+4. assuming that the following holds, the LP are also profitable:
+
+```
+    fees_DEX + price_impact_DEX > fees_CEX + price_impact_CEX
+```
+
+
+<br>
+
+----
+
+<br>
+
+### resources
+
+* [uniswap on jit liquidity](https://uniswap.org/blog/jit-liquidity)
+* [just-in-time mev dune board](https://dune.com/ChainsightAnalytics/Uniswap-v3-Just-in-Time-(JIT)-Liquidity-MEV)
+* [uniswap v3 lp by rekt](https://rekt.news/uniswap-v3-lp-rekt/)