getunite / yield-booster Goto Github PK

Is your feature request related to a problem? Please describe.
Add options to the yield boost pools, this is a more classic pools like the ones we have already implemented

Describe the solution you'd like
We need to test, deploy and add options for the 2 following convex vaults:

1. 
2. 

Here are the contract addresses:

1. Reward contract: 0xe94b4cC50aC9ebeC491c3665C3E5a017a87dCF19
2. Reward contract:0x0404d05F3992347d2f0dC3a97bdd147D77C85c1c

Describe alternatives you've considered
NA

Additional context
NA

Is your feature request related to a problem? Please describe.
No problem, the goal is to increase TVL in the protocol and the number of CVX rewards $ALLUO lockers earns.

This is related to the white paper here: https://www.notion.so/alluo/Yield-booster-933737d27e1f4808b425081f3ecbd60c

Describe the solution you'd like
This task is to build the first part of the Yield Booster product, the vault. The vault should take in base assets, create the LP on Curve, and issue the AlluoBoostedXXX token to the user.

We would like to use the ERC-4626 standard (described here by open Zepplin: https://docs.openzeppelin.com/contracts/4.x/api/token/erc20#ERC4626) and implement the UX improvements that come with EIP-2612 as well.

This issue includes:

• create the template vault to create more AlluoBoostedXXX tokens
• implement the AlluoBoostedFraxUsdc
• implement the wrapper that will convert the USDC and FRAX into LP and then deposit them into the AbFraxUsdc vault

The AlluoBoostedFraxUsdc should be able to take in USDC or FRAX tokens and invests them in the Frax/Usdc pool on the Curve (https://curve.fi/fraxusdc) then move the LP token to the booster pool (issue to be created)

The AbFraxUsdc vault should implement all the standard functions described in the ERC:

• asset() -> should return the address of the underlying Curve LP
• totalAssets() - should return the amount of Curve LP managed by the vault.
• convertToShares(assets)
• convertToAssets(shares)
• maxDeposit(_)
• maxMint(_)
• [maxWithdraw(owner)](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20#ERC4626-maxWithdraw-address-
• maxRedeem(owner)
• previewDeposit(assets)
• previewMint(shares)
• previewWithdraw(assets)
• previewRedeem(shares)
• deposit(assets, receiver) - this should take the Curve LP and NOT the underlying 2 assets.
• mint(shares, receiver)
• withdraw(assets, receiver, owner)
• redeem(shares, receiver, owner)

The vault should then be complemented by a wrapper contract which will actually be used by the Alluo webapp and mobile app to interact with this boosted pool. This contract should implement the following functions:

• getBalances(address, address = 0x) -> this should return the underlying balance of the tokens addresses passed. So in the Frax / USDC case, you would be able to query the view function with both USDC and FRAX addresses and it would give back the amount of USDC or FRAX you are able to claim back from the vault if you are to unwind your LP
• getRewardsBalance() -> this function would return the balance in reward from the boost pool for the Frax/Usdc case if it is attached to the boost pool Cvx/ETH it would return how much ETH and how much CVX a share of the vault is entitled to.

Describe alternatives you've considered
this is the only standard out there for now, so better than building our own stuff!

Additional context
This task is linked to the booster pool which will be described the next task.

Is your feature request related to a problem? Please describe.

Today, claiming of rewards across multiple vaults is extremely expensive and a wasteful duplication of gas. This is because on each transaction, we are unwrapping and withdrawing from curve, multiple times.

Describe the solution you'd like

We should additionally add an option to claim rewards across all the vaults in one go.

Proposed architecture

Create a delegate claiming contract where the users can call claimAll().

This should (across all the vaults) update the rewards mapping for the user to 0 (add new function in the vault contract).

Then, we should add a new function in the pool contract that correctly deducts the each vault's shares of the booster pool.

Finally, we should withdrawAndUnwrap the correct total amount of cvxETH lps back to the user.

For example:

User has CVX-ETH rewards in two different vaults - 50 CVXETH and 80 CVX-ETH.

1. User calls claimAll().
2. delegateClaim contract updates both vaults' rewards mapping to 0.

User's rewards balance is now 0, 0.

3. delegateClaim contract correctly deducts each vault's share of the booster pool (check how it is done today in the claiming function called withdraw()).

4. delegateClaim contract withdrawsaAndUnwraps 50+80 = 130 CVX-ETH lps from the booster pool directly.

There are different ways of doing it but this is one solution

Is your feature request related to a problem? Please describe.
We want to create a vault contract that accepts token deposits, and then invests those into the top X yielding beefy vaults that week on the same chain (crosschain will come later).

Every week (or time period we decide on), through an offchain script, we wil nominate and change the underlying X number of beefy vaults to maximise the yield. This will be a separate ticket for automation.

Describe the solution you'd like
Create a vault contract that has the following characteristics:

1. Accepts token deposits and withdrawals so that we can change tokens into a moo token and vice versa.

2. Upon a token deposit, split the deposit up into whatever proportion is decided, then swap them into the beefy vault moo tokens. Then, indvidually credit the user with the appropriate token.

For example:

a. User deposits 100 EURT

b. The proportion decided is 50% in Vault A, 30% in Vault B, 20% in Vault C. Therefore split the EURT into:

50 EURT for Vault A, 30 EURT for Vault B, 20 EURT for Vault C.

Then swap each EURT into the vault's beefy vault moo tokens. We should create the appropriate beefy adapters for the exchange to streamline the process. This will be written as a separate ticket in the exchange repo.

c. Credit the user with the resulting Moo tokens received for each vault:

Vault A resulted in 30 Moo tokens, Vault B in 20 Moo Tokens, VAult C in 8 Moo tokens:

Credit the User with: {Vault A: 30 Moo, Vault B: 20 Moo, Vault C: 8 Moo}

3. Create a 'reallocate' function that changes the underlying allocation and then loops through to credit the users with the correct balances.

Ex.)
Step 1: Check the user's balance as a proportion of the total balances.

User with: {Vault A: 20 Moo, Vault B: 8Moo, Vault C: 12 Moo} and the Optimizer has balances {Vault A: 60 Moo, Vault B: 40Moo, Vault C: 16 Moo}

The user had 33% of the optimizer's Vault A moo tokens (20/60), 20% of the optimizer's Vault B moo tokens (8/40), 75% of the optimizer's Vault C moo tokens (12/16).

Step 2: Change the allocation

Allocation changes to 60% Vault C, 40% Vault D.

Swap all Moo tokens into USDC (single token) : {Vault A: 60 Moo, Vault B: 40Moo, Vault C: 16 Moo} -->{Vault A: 100USDC, Vault B: 60 USDC, Vault C: 40USDC} == 200 USDC total.

Then do

120 USDC --> Vault C, 80 USDC --> Vault D.

Results in:

{Vault C: 90 Moo tokens, Vault D: 70 Moo tokens} in total for the whole Optimizer.

Step 3: Calculate how much belongs to the user in absolute terms

Total: {Vault A: 100USDC, Vault B: 60 USDC, Vault C: 40USDC} == 200 USDC total after swaps.

Therefore, the user deserves: 100 USDC * 33% + 60 USDC * 20% + 75% * 40 USDC = 75 USDC worth.

75 USDC / 200 USDC = 37.5% of the vault's new moo tokens belong to the user.

Vaults new total balances : {Vault C: 90 Moo tokens, Vault D: 70 Moo tokens}

User's new mapping should be updated to

(90 * 0.375) , (70 * 0.375)= )(33.75, 26.25)

User's new mapping: {Vault C: 33.75 Moo tokens, Vault D: 26.25 Moo tokens}

Describe alternatives you've considered
There might be more efficient ways to avoid slippage but we want to avoid other solutions that try denominate things into a single token because it can be frontrun.

Therefore, in this implementation, there are no "share" receipt tokens. Just an updating of the mapping. Perhaps we can add a transfer function if we want to to alter the underlying mappings. But this is not necessary.

Additional context

Is your feature request related to a problem? Please describe.
Adding more diversity to our locked pools options.

Describe the solution you'd like
We need to check what needs to be done (add coins to the exchange, update the strategy contract, test, etc.) and implement the 2 pools from fraxConvex:

1. 
2. 

Contract addresses are here:

1. Underlying curve: https://curve.fi/#/ethereum/pools/factory-crypto-97/deposit/ | staking address: https://etherscan.io/address/0x57c9F019B25AaAF822926f4Cacf0a860f61eDd8D
2. Underlying curve: https://curve.fi/#/ethereum/pools/frxeth/deposit | staking address: https://etherscan.io/address/0xa537d64881b84faffb9Ae43c951EEbF368b71cdA

This is of course a similar issue then with the frax.convex implementation in the LD repo, what do we do while its locked?
For now let's just lock the funds for 7 days, and the user is simply not able to withdraw. The DAO does NOT take the risk.

Describe alternatives you've considered
NA

Additional context
Add any other context or screenshots about the feature request here.