revo-market / contracts Goto Github PK

We should add a check to ensure that the end-tokens in each path correspond to the correct token0/token1 that comprise the LP token

so we don't need to deploy a new RevoFees contract every time we want to update the withdrawal fee

As an end user, I need to be able to get an LP and deposit it into a "meta" farm bot in a single step.

Eng:
the flow should include the following steps:

• user approves Farm Investor (not attached to this naming) for X of token A
• user approves Farm Investor for Y of token B (equal value)
• user calls "invest" method on farm investor
• farm investor takes token A and token B from user
• farm investor approves liquidity router for token A and token B
• farm investor adds liquidity and gets LP in return
• farm investor deposits LP into farm bot and gets RFP in return
• farm investor sends RFP AND ANY UNUSED token A/B to the end user

AC:

• the above contract is implemented and unit tested
• some e2e test is run on alfajores or mainnet

there needs to be an interface which will help us implement different farm bots for different DEX's

there are probably methods that are DEX-agnostic that can be put into an abstract class as well

and potentially different rewards contracts for the same DEX, for instance the single-rewards contract used by some Ubeswap farms

AC:

• UbeswapFarmBot is separated out into an interface, abstract class, and bespoke contract
• the re-usable components are re-usable :)
• unit tests updated and passing

their implementation is here: https://github.com/beefyfinance/beefy-contracts/blob/master/contracts/BIFI/strategies/Sushi/StrategySushiLP.sol

it would be useful to de-risk our implementation of the "farm bot" contract by borrowing as much as possible from theirs

Right now, farm bot names are hardcoded; we should be able to set the contract name as a parameter.

Currently the IRevoBounty interface doesn't have a method for calculating additional bounties before claiming, which means that previewBounty in the farmbot contract can't provide info on additional bounties.

we should run unit tests and formatting checks before enabling merges

3 of the top 5 farms by TVL on Ubeswap have just one token for rewards.

Single-token rewards contracts are different than the multiple-token rewards contracts, so I think we may need to create a new Farm Bot contract to support them.

AC:

• we can deploy a farm bot supporting a farm which has only one token for rewards
• unit tests
• basic e2e tests (deposit, withdraw, compound)

just for practice

should probably be on mcUSD-mcEUR

will involve deploying a new MoolaStakingRewards contract first

AC:

• I can deposit some mcUSD/RFP LP into a farm bot
• compounding for the farm bot works

need full unit test coverage on all our contracts

In particular, make sure the last token in the swaps path is what we expect (a staking token)

how many tokens will exist in total, and what will the starting price of a token be in our IDO? Note that the starting price times the amount of initial liquidity will determine the capital needed for initial liquidity.

note that allocation is out of scope for this issue, see #60

Beefy docs reference a possible exploit that their withdrawal fees are designed to prevent: https://docs.beefy.finance/moo/ecosystem/products/vaults#what-is-the-vault-fee-structure

We should evaluate this threat and determine whether it applies to our use case.

we need a breakdown of how many gov tokens will go to which things.

note that the total number of tokens isn't in scope for this issue.

ubeswap shared their allocation here, we can largely copy from it I think, although I'd like to see the "team" tokens go to a time lock for vesting instead of straight to us

We need to be able to test our contracts on a local chain, against "dummy" contracts. This issue is for getting the framework/proof-of-concept set up that allows us to write tests using this approach.

users may want to know what the new fees are when they are updated

AC:

• farm bot is able to reinvest rewards for farms where multiple tokens are given out as rewards

mainly to make sure the "generalize" issue actually works

AC:

• implementation
• unit tests
• e2e test
• 1 deployed farm bot
• added to compounder
• compounding works