Visor
Search…
Hypervisor Contract
Specifications of Visor Finance's Hypervisor contract

Introduction

The Hypervisor is Visor's LP Management contract, which generates it's 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.

Functions

In this section we will describe the different public and relevant private functions that the Hypervisor contract, available in our Github.

deposit

Hypervisor.sol
1
function deposit(
2
uint256 deposit0,
3
uint256 deposit1,
4
address to
5
) external override returns (uint256 shares)
Copied!
With this function, LPs deposit assets to our Hypervisor and receive the ERC-20 shares that represent their 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
1
function withdraw(
2
uint256 shares,
3
address to,
4
address from
5
) external override returns (uint256 amount0, uint256 amount1)
Copied!
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
1
function rebalance(
2
int24 _baseLower,
3
int24 _baseUpper,
4
int24 _limitLower,
5
int24 _limitUpper,
6
address feeRecipient,
7
int256 swapQuantity
8
) external override onlyOwner
Copied!
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
1
function properDepositRatio(uint256 deposit0, uint256 deposit1
2
) public view returns (bool)
Copied!
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.
Last modified 14d ago