-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
61 additions
and
44 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,66 +1,83 @@ | ||
| ## Foundry | ||
| # UniswapV4 - Risk Neutral Hook | ||
|
|
||
| **Foundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.** | ||
|
|
||
| Foundry consists of: | ||
| <br> | ||
|
|
||
| - **Forge**: Ethereum testing framework (like Truffle, Hardhat and DappTools). | ||
| - **Cast**: Swiss army knife for interacting with EVM smart contracts, sending transactions and getting chain data. | ||
| - **Anvil**: Local Ethereum node, akin to Ganache, Hardhat Network. | ||
| - **Chisel**: Fast, utilitarian, and verbose solidity REPL. | ||
| <img alt="image" src="Univ4.png" style="width: 100%; height: auto;"> | ||
|
|
||
| ## Documentation | ||
| <br> | ||
|
|
||
| https://book.getfoundry.sh/ | ||
| [This is the explanatory video for our Hook](https://youtu.be/_3UwdIoU23w) | ||
|
|
||
| ## Usage | ||
| [You can also view the presentation slides here](https://docs.google.com/presentation/d/1V69IXV7AJSI59UxeSnM4UYf7mCy2Leu2MyUha8utA2M/edit#slide=id.g2d31d7c8c7b_7_58) | ||
|
|
||
| ### Build | ||
| We try to provide a combined solution to hedge **IL** & **LVR** via dynamic fees and hedges to achieve both delta and gamma neutrality. | ||
|
|
||
| ```shell | ||
| $ forge build | ||
| ``` | ||
| ### Background | ||
|
|
||
| ### Test | ||
| When providing liquidity to Uniswap, liquidity providers (LPs) are subject to the price mechanics of the constant function formula: | ||
|
|
||
| ```shell | ||
| $ forge test | ||
| ``` | ||
| **x * y = k** | ||
|
|
||
| ### Format | ||
| Due to LP positions having negative convexity (which can be proven using Jensen's Inequality), the value of the position will always be inferior to simply holding the tokens (without accounting for fees). | ||
|
|
||
| ```shell | ||
| $ forge fmt | ||
| ``` | ||
| ### Quantifying LP Losses | ||
|
|
||
| ### Gas Snapshots | ||
| There are two main methods of quantifying the loss LPs incur: | ||
|
|
||
| ```shell | ||
| $ forge snapshot | ||
| ``` | ||
| - **Loss-Versus-HODLing**: Also known as Impermanent or Divergence Loss. | ||
| - **Loss-Versus-Rebalancing**: Also known as "lever." | ||
|
|
||
| ### Anvil | ||
| While Impermanent Loss has been the primary metric for quantifying LP losses on Uniswap, it has some major drawbacks: | ||
|
|
||
| ```shell | ||
| $ anvil | ||
| ``` | ||
| - It compares LP value to the value of simply holding the tokens, which is an unrealistic strategy. | ||
| - If the price diverges and then returns to the original price, IL=0, completely disregarding volatility. | ||
|
|
||
| ### Deploy | ||
| Conversely, "lever" is path-dependent, taking into account rebalancing (and arbitrage) opportunities given a time series of prices. It occurs mainly due to AMMs having "stale" prices. | ||
|
|
||
| ```shell | ||
| $ forge script script/Counter.s.sol:CounterScript --rpc-url <your_rpc_url> --private-key <your_private_key> | ||
| ``` | ||
| Moreover, it has been proven that LPs have underpriced volatility and therefore market risk, foregoing additional profits and having a negative Volatility Risk Premium. This can be demonstrated by deriving implied volatility from Uniswap positions and comparing it to realized volatility from any liquid market where price discovery is supposed to occur, such as Deribit. | ||
|
|
||
| ### Cast | ||
| ### Reducing LP Losses | ||
|
|
||
| ```shell | ||
| $ cast <subcommand> | ||
| ``` | ||
| Given that an LP has already chosen a pool, there are two main ways of reducing these losses: | ||
|
|
||
| ### Help | ||
| - **Using hedges** | ||
| - **Dynamically modifying pool fees** | ||
|
|
||
| ```shell | ||
| $ forge --help | ||
| $ anvil --help | ||
| $ cast --help | ||
| ``` | ||
| --- | ||
|
|
||
| ## Hedges | ||
|
|
||
| Due to the negative convexity of the LP value function, their positions cannot be hedged solely with delta-one or linear products. However, for small price movements, a delta-hedge can be sufficient to offset "lever." This can be achieved either by: | ||
|
|
||
| - Selling futures | ||
| - On-chain borrowing and setting a rebalance threshold, from which, if surpassed, a re-hedge is executed. | ||
|
|
||
| For LPs desiring a complete hedge to offset all directional risk, products like power perpetuals or options are the preferred approach. | ||
|
|
||
| We implement a basic Proof of Concept (PoC) of how LP Greeks are updated and how this can be used to compute any hedging updates, verifying that the position is correctly hedged. | ||
|
|
||
| --- | ||
|
|
||
| ## Dynamic Fees | ||
|
|
||
| To correctly remunerate LPs and price volatility accordingly, as well as reduce price impact for large swaps and account for market conditions via gas price, a dynamic fee system has been implemented. | ||
|
|
||
| To achieve this, we extract the implied volatility of the pool from volatile asset drift and the return from pool fees using the formula derived by **Daniel Alcarraz**. | ||
|
|
||
| We attempted to devise a simple model that dynamically adjusts the fees with a discount factor based on the **Volatility Risk Premium**—that is, the difference between Implied and Realised Volatility. | ||
|
|
||
| - **Whenever implied volatility is higher** than historical or expected volatility, providing liquidity yields a positive expected return. | ||
|
|
||
| - **If the implied volatility is lower**, the return becomes negative. | ||
|
|
||
| > *“If the implied volatility is lower than the historical or expected volatility, the return becomes negative.”* - Daniel Alcarraz | ||
| We are also currently investigating the Implied Volatility formula proposed by **Guillaume Lambert**. There is significant room for improvement in both the parameters and the formulas. | ||
|
|
||
| These are preliminary implementations to have the Proof-of-Concept ready for the hackathon but will likely change in the following weeks. We will also be performing: | ||
|
|
||
| - A backend (taking care to avoid backtesting overfitting) | ||
| - A forward test of the models | ||
| - Unit, integration, and fuzz tests | ||
| - Formal verification of all the code |
