Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Beefy Omnivault / Beefy Vault Optimizer (same chain) #36

Open
pentatonictritones opened this issue Mar 28, 2023 · 0 comments · May be fixed by #37
Open

Beefy Omnivault / Beefy Vault Optimizer (same chain) #36

pentatonictritones opened this issue Mar 28, 2023 · 0 comments · May be fixed by #37

Comments

@pentatonictritones
Copy link
Contributor

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}

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant