Vault Build
This page describes the technical building blocks and intended behaviors of Vaults
Last updated
This page describes the technical building blocks and intended behaviors of Vaults
Last updated
ICHI-Vaults is a liquidity-management protocol for Uniswap V3.
ICHI-Vaults actively manage liquidity positions. Each ICHI-Vault corresponds to exactly one Uniswap V3 pool defined by two distinct parameters: (1) asset pair and (2) trading fee. Additionally, each ICHI-Vault has an immutable liquidity-management strategy which currently defaults to single-sided asset deployments. The immutable strategy provides investors with assurance that the active liquidity-management will always pursue a pre-defined strategy. Users can change strategies by withdrawing liquidity from the ICHI-Vault to demote and adding liquidity to the ICHI-Vault to promote.
ICHI-Vaults redistribute Uniswap tokens (trading fees) to a recipient and an affiliate. The recipient account is global and controlled by the ICHI-Vault Factory owner. ICHI-Vaults are owned by the users who create them who may define an affiliate address to share in the distribution of fees collected. ICHI-Vault Factory governance controls the global base fee and base fee split (shared with the affiliate). Uniswap fees collected above the base fee are redistributed to liquidity providers indirectly through their interest in the total assets in the ICHI-vault.
Active management is through periodic rebalancing which can only be executed by the owner of the ICHI-Vault. This can be executed through another contract, a daemon-like process, or manually. Certain attack vectors are blocked because the ICHI-Vault cannot be enticed to reorganize liquidity positions by anyone other than the ICHI-Vault owner who alone has the privilege.
Liquidity Pool fee distribution efficiency: There is lag time between deposit() and rebalance() during which Uniswap transaction fees that may have accrued are not distributed. On deposit(), deposited funds begin to earn Uniswap fees starting at the next rebalance(). On withdrawal(), fees stop accruing to the withdrawer as of the most recent rebalance(). This creates a modest opportunity cost which is offset by gas savings and a modest risk arising from dependency on the owner() who alone is authorized to rebalance() the ICHI-Vault. In the worst case scenario, users would be expected to withdraw their deposits. In summary, fees are distributed among active participants at intervals controlled by the owner(). The system uses a defensive pattern to repel price-manipulation attacks: A TWAP (usually one hour) and spot price are compared.
The system chooses the lesser value of assets to deposit and the larger value to estimate the pool value for the shares calculation. In normal market conditions, the differences are expected to be small, while in cases of price-manipulation attempts it would be sufficient to financially disincentivize the attack and leave the vault whole. In either case, any value gain prescribed to the assets under management due to this implementation is shared proportionally by all liquidity providers.
As a further defense, the system rejects transactions when the difference between spot and TWAP exceeds a threshold and the timestamp of the latest observation in the Uniswap pool is the same as the timestamp of the current block. The owner sets the threshold which is initially set to 1%.
It is understood that the ICHI-Vault will become inactive if the price moves outside of the vault’s boundaries and the ICHI-Vault owner neglects to rebalance periodically. In this case, investors would be expected to withdraw liquidity without harm, apart from opportunity cost.
We define "fair amount of shares" as follows:
"Fair amount of shares" is an amount which will result in zero loss/gain for the depositor in the case of share liquidation immediately after the deposit transaction.
The rule can be represented using this formula:
where both Deposited Value and Vault's TVL are calculated based on the amount of each token (t0 and t1) in the vault and ratio between the tokens in the pool at the time of the deposit. That is:
Based on this formula, we calculate User Shares to be issued during deposit as follows:
or
In an abbreviated form the formula looks like this:
Where:
US - User Shares
DV - deposited value
TS - total shares (after deposit)
TVL - total vault's value (after deposit)
It can also be expressed using:
TS_BD - total shares (before deposit)
TVL_BD - total vault's value (without deposit)
As:
which translates into
