Unipilot Vaults

Vaults are used to manage the liquidity positions of users. A new vault has to be deployed for each pair e.g. (ETH/USDT). The total supply of the vault’s LP tokens represents the share of liquidity in that pool [on the underlying DEX] that is managed by Unipilot. A user’s LP tokens represent their share of the Unipilot vault.

Recap of architectural improvements with v2:

Unipilot v1 was built with an NFT-based architecture, with one contract managing all users' liquidity share across all pairs. This approach was applied due to the ease of liquidity management inside a single contract, which reduced the overall quantity of transactions required to manage all vaults on Unipilot.

This approach worked as expected from the perspective of deployment costs and state management. However, due to the frequent management of the contract state it led to high transaction costs for users, affecting the overall efficiency of the protocol.

With Unipilot v2, we addressed the shortcomings of v1 by switching to an LP-based factory architecture. In this architecture, the protocol deploys separate vaults for each pool. The protocol mints LP tokens for each vault, and these are used to represent each user's share of the vault. This approach does increase the vault deployment cost, but as v2 offers active liquidity management (which we'll discuss later), the protocol bears the cost for the deployment of vaults for these pools.

Our tests have shown that switching to LP-token based architecture reduces transaction costs for users by ~60% on average compared to v1. Since we position Unipilot as a universal automated liquidity optimization protocol, we wanted to not only allow users to deploy vaults for any pair but also make using the protocol as affordable as possible.