Visor
Search…
Hypervisor
Visor compatible smart contracts that route assets in your vault to external DeFi protocols

Introduction

Visor deploys Hypervisor smart contracts to manage liquidity in a decentralized protocol using the research output from Gamma Strategies to maximize returns and mitigate risks. The current Hypervisor contracts support liquidity provision in Uniswap v3 pools, allowing for professional LP strategies to be implemented with liquidity that has been pooled from many LPs, while allowing immediate withdrawals that ensure self-custody of funds.

Deposit, Withdrawal and Custody

The Hypervisor contract allows for LPs to deposit tokens using the deposit function. The function allows for both single and 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. At most only one of the two assets can have a value deposited amount of zero. When a Hypervisor receives a deposit, it mints a fungible LP ERC20 token which represents fractional ownership in the pool, therefore maintaining self-custody of funds while taking advantage of high-return LP strategies. These shares are minted in proportion to the units of token1 that is provided into the pool, with the token0 amount (if any) converted using the current pool price. These tokens are transferred to the LP token account specified by the depositor. For example, a Gnosis Safe can call the deposit function, supplying 40 WETH, 100k USDT and provide its own account address as the LP token recipient. Upon deposit, the Gnosis Safe will be in custody of the LP tokens.
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 releases 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 in only one of those assets.

Rebalancing and Fee Collection

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 token0 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 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.‌
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.
‌In its public Hypervisors, Visor.finance deducts 10% of these fees and sends to a distributor account for its protocol revenue. 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 final destination or management of this fraction of earned fees.
Last modified 2mo ago