We want to combine some of the Booster and Vault Controller logic to make a cleaner integration.
The goal for user experience:
User goes to our site, and sees a list of assets they can deposit. These are both regular ERC20 tokens and LP tokens.
The user hits deposit, and the asset goes into their vault.
If the asset is an LP token the user sees rewards growing in their vault and can hit a 'claim' button to claim those rewards.
Current issues:
To start vaults only counted a users collateral balance using ERC-20 tokens in the address. We updated this to include LP tokens by adding a balance tracker, this way LP tokens can count as collateral AND be deposited into BaseRewardPools.
-- But, this means we've got to have two different functions to support depositing ERC-20 and LP tokens, and it is messy.
The current Booster logic is sloppy and challenging to maintain.
Ideal:
Vault Controller contains a mapping of supported tokens (ERC-20 and LP tokens)
Each token now has a "wrapping" address, a contract which will wrap the token and apply any needed logic.
Each token will have a reward pool (like the kind in the booster) generated for it when it is added to the system.
Vault Controller contains a mapping of tokens -> a token wrapping contract
Vault Controller contains a struct mapping of reward pools.
Vault Controller has one deposit function.
The deposit function checks if a token is supported, if it is, it then checks if it is an LP token (such as $3CRV).
If it is an LP token, the token is sent to a wrapping contract. The wrapping contract deposits the $3CRV into Convex. It then deposits a $w3CRV into the users vault, and a $3CRVdepositToken into the BaseRewardPool on behalf of the vault address.
If it is not an LP token, it should be sent to the wrapping contract. The wrapping contract will just hold the token. It then deposits a $wX token into the users vault, and a $XdepositToken into the BaseRewardPool on behalf of the vault address.
The users collateral is calculated by reading the wrapped tokens + any regular ERC-20 tokens. So Oracles will need to map both.
When a wrapped token is liquidated, the depositToken will need to be withdrawn from the reward pool, then the token will need to be unwrapped and the underlying ERC-20 token will be sent to the liquidator.
We want to combine some of the Booster and Vault Controller logic to make a cleaner integration.
The goal for user experience:
Current issues:
Ideal:
Vault Controller contains a mapping of supported tokens (ERC-20 and LP tokens)
Each token now has a "wrapping" address, a contract which will wrap the token and apply any needed logic.
Each token will have a reward pool (like the kind in the booster) generated for it when it is added to the system.
Vault Controller contains a mapping of tokens -> a token wrapping contract
Vault Controller contains a struct mapping of reward pools.
Vault Controller has one deposit function.
The deposit function checks if a token is supported, if it is, it then checks if it is an LP token (such as $3CRV).
If it is an LP token, the token is sent to a wrapping contract. The wrapping contract deposits the $3CRV into Convex. It then deposits a $w3CRV into the users vault, and a $3CRVdepositToken into the
BaseRewardPoolon behalf of the vault address.If it is not an LP token, it should be sent to the wrapping contract. The wrapping contract will just hold the token. It then deposits a $wX token into the users vault, and a $XdepositToken into the
BaseRewardPoolon behalf of the vault address.The users collateral is calculated by reading the wrapped tokens + any regular ERC-20 tokens. So Oracles will need to map both.
When a wrapped token is liquidated, the depositToken will need to be withdrawn from the reward pool, then the token will need to be unwrapped and the underlying ERC-20 token will be sent to the liquidator.