Hypervisor / Supervisor

Hypervisor
Introduction
A Hypervisor is a position manager contract. A Hypervisor has certain management functions such as rebalance, set limit position, collect fees, and reinvest earned fees. These functions allow it to manage funds in a liquidity pool. Hypervisors are non-custodial in that only the depositor can withdraw funds. Each liquidity pool, whether Public or Pro is functionally run by a Hypervisor. 
A list of active Hypervisors can be found here:
Supported Pairs
Deposits
‌The Hypervisor contract allows liquidity providers to deposit tokens using the deposit function. The function allows for both double-asset deposits to be made from any account, choosing amounts of token0, token1, and a recipient of the LP ownership shares that represent ownership of the deposit. 
When a Hypervisor receives a deposit, it mints a fungible LP ERC20 token which represents fractional ownership in the pool. These shares are minted in proportion to the units of token1 and token0 that are provided into the pool. These tokens are transferred to the LP token account specified by the depositor. 
Withdrawals
Withdrawals may be initiated by any holder of LP tokens by calling the withdraw function. A withdrawer specifies how many LP tokens they would like to burn in exchange for the share of the Hypervisor's underlying LP position's assets the burned tokens represented and specifies a recipient account to whom those assets should be sent.‌
Burning LP tokens release underlying assets in the ratio held by the Hypervisor. For example, a Hypervisor that has its liquidity 20% in WETH and 80% in UNI would satisfy withdrawals by providing 20% WETH, 80% UNI, even if liquidity was provided originally was not at that ratio.
Rebalancing
An advisor account designated by the Hypervisor deployer has the right to call the rebalance function, which modifies the Hypervisor's LP position. In the current strategy, a Hypervisor's position consists of two UniswapV3Pool positions: a base position which must match the pool's current ratio of tken0 and token1 in composition; and a limit position, which contains a single asset (often what cannot be deposited in the base position due to the mechanics of concentrated liquidity). A Hypervisor's strategy consists of the determination of where these positions should be placed, and when they should be changed in response to market conditions.

During a rebalance, the advisor account provides width and placement parameters for these respective positions. It also supplies a fee recipient account.‌
Fees
When a rebalance occurs, the base and limit positions are burned, and the fees earned from swaps over the liquidity provision ranges are collected. A fraction of these earned fees (defined by the Hypervisor deployer) can be deducted from this quantity and sent to the recipient account provided by the advisor calling the rebalance. The remaining fees are reinvested in the new, rebalanced position.
‌Hypervisors deduct 10% of these fees and send the fees to a distributor account. An individual deployer may choose whichever fee schedule they wish to implement. The fee recipient account provided by the advisor account can be a smart contract, for example, allowing custom business logic to determine the final destination or management of this fraction of earned fees.
Functions
The Hypervisor is Gamma's LP Management contract, which generates its own set of periphery functions to interact with Uniswap v3's pools, without having to use their NFTs which are non-fungible and difficult for smart contracts to interact with.
The Hypervisor allows for different LPs to pool their assets into one actively managed position in a non-custodial fashion while allowing for a Supervisor role to set administer the position, which is done by our sister organization Gamma Strategies.
When a user deposits assets to a Hypervisor they are issued ERC-20 receipt tokens in proportion to the assets supplied, allowing for the non-fungible Uniswap v3 LP position to become fungible, as well as interaction with other protocols using the ERC-20 tokens. For most of our public Hypervisors, these are held within our NFT Vault, allowing for future subscription to liquidity mining programs using our stack.
Most users will interact with our Hypervisor through our frontend, but we provide here a description of the inner workings of the contract for those who are interested.
In this section, we will describe the different public and relevant private functions of the Hypervisor contract..
deposit
Hypervisor.sol
    function deposit(
        uint256 deposit0,
        uint256 deposit1,
        address to
    ) external override returns (uint256 shares) 
With this function, LPs deposit assets to our Hypervisor and receive the ERC-20 shares that represents the proportion of the assets that are in the Hypervisor contract. Note that we allow in some Hypervisors single-sided deposits, thus there is a possibility of either deposit0 or deposit1 being equal to zero.
Arguments:
deposit0 units of token 0 of the Uniswap v3 pool contract being deposited.
deposit1 units of token 1 of the Uniswap v3 pool contract being deposited.
to address of the recipient of the ERC-20 receipt tokens.
Returns:
shares representation of the share of the pool that the LP will receive. The deposited assets are aggregated into token 1 value according to the current pool price.
withdraw
Hypervisor.sol
    function withdraw(
        uint256 shares,
        address to,
        address from
    ) external override returns (uint256 amount0, uint256 amount1) 
With this function, LPs can burn a proportion or all of their ERC-20 shares in order to withdraw their share of liquidity from the Hypervisor. The assets are transferred to the withdrawing LP according to the proportion in which they are held in our LP position. Thus, even if you deposited single-sided assets, you are likely to receive both tokens of the Uniswap v3 pool, unless our position is fully in one asset. This is unlikely as Gamma's active management strategies generally seek to keep a good balance of both assets to minimize Impermanent Loss.
Arguments:
shares units of the ERC-20 to be burned in order to withdraw assets
to address of the recipient of the withdrawn assets 
from address from which the liquidity tokens are sent
Returns:
amount0 units of token 0 that will be transferred to the withdrawing LP.
amount1 units of token 1 that will be transferred to the withdrawing LP.
rebalance
Hypervisor.sol
function rebalance(
        int24 _baseLower,
        int24 _baseUpper,
        int24 _limitLower,
        int24 _limitUpper,
        address feeRecipient,
        int256 swapQuantity
    ) external override onlyOwner
This is the function used by the Supervisor to actively manage the LP position. It is important to emphasize that this function can only be called by this administrator role, allowing for non-custodial active management of the LP position by Gamma Strategies.
In this function you are able to see the inner working of the LP position, where the Hypervisor maintains two simultaneous LP positions to maximize the assets that are deployed in the pool, a "base position" that has both assets of the Uniswap v3 pool, and thus contains the current price; and a "limit position" that has only one of the assets (whichever token is not able to be deployed due to single-sided deposits, or the mathematics of concentrated liquidity ranges).
Arguments:
_baseLower tick for the low end of the base position.
_baseUpper tick for the high end of the base position.
_limitLower tick for the low end of the limit position.
_limitUpper tick for the high end of the limit position.
feeRecipient address of the recipient of the share of fee income to be distributed to VISR stakers
swapQuantity optional token swap to be conducted during the rebalance; if quantity is positive, swapQuantity token 0 are swaped for token 1, if negative, swapQuantity token 1 is swaped for token 0
properDepositRatio
Hypervisor.sol
 function properDepositRatio(uint256 deposit0, uint256 deposit1
          ) public view returns (bool)
This function allows LPs to check whether they are depositing deposit0 units of token 0 and deposit1 units of token 1 in the ratio that is given by the current state of the Hypervisor's LP position.
Arguments:
deposit0units of token 0 the LP is attempting to deposit.
deposit1units of token 1 the LP is attempting to deposit.
Returns:
bool Return true if the assets are in the correct ratio, false if they are in the incorrect ratio.
Supervisor
A Supervisor is a Hypervisor contract with a controller. The controller carries out an asset management strategy for the Hypervisor. The Supervisor updates/changes certain defined variables in the Hypervisor contract to manage assets and implement strategies. 
Features - Previous
CLM Strategies
Next - Learn
Community / PSAs
Last modified 1mo ago
Copy link
On this page
Hypervisor
Introduction
Deposits
Withdrawals
Rebalancing
Fees
Functions
Supervisor