Hypervisor / Supervisor
Information on the Hypervisor and Supervisor


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 (AMCLP or private (Phantom) is functionally run by a Hypervisor.
The Hypervisor creator contract (Hypervisor Factory) can be found here:
Hypervisor code can be found here:
GitHub - VisorFinance/hypervisor: Visor Hypervisor active liquidity management contracts
The Hypervisor code was audited by CertiK on July 7, 2021. It can be found here:
hypervisor/REP-Hypervisor-2021-07-07.pdf at master · VisorFinance/hypervisor
A list of active Hypervisors can be found here:


The Hypervisor contract allows liquidity providers 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.
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 that are 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.


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.


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.‌


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 sends 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.


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.
Last modified 22d ago