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

Uniswap Strategy #252

Open
micahalcorn opened this issue Sep 24, 2020 · 1 comment
Open

Uniswap Strategy #252

micahalcorn opened this issue Sep 24, 2020 · 1 comment
Labels
contracts Works related to contracts P2 Small number of users are affected, major cosmetic issue

Comments

@micahalcorn
Copy link
Member

Add a vault strategy that takes stablecoin deposits and supplies them to one or more of the following liquidity pools:

We will need to decide how to allocate deposits and withdrawals since Uniswap liquidity pools necessarily involve dealing with two tokens at a time as opposed to our Compound strategy, which can lend or withdraw any single token.

@micahalcorn micahalcorn added P1 Large amount of significant user impact, a meaningful feature is broken contracts Works related to contracts labels Sep 24, 2020
@tomlinton
Copy link
Contributor

Our current allocate structure will actually work as is for Uniswap. Allocate iterates over all assets and deposits in one strategy to maintain a target weight for that strategy. So adding a Uniswap strategy that supports DAI and USDT will have the result we want, a strategy that fills up with DAI and USDT. The deposit() method of the strategy then provides liquidity in the Uniswap strategy by adding equal amounts of each coin according to the minimum.

In practice this is far from optimal, we will end up with very small amounts of DAI and much higher values of USDT, leaving a lot of uninvested USDT in the strategy. If we are looking at the DAI/USDC pool however, what we have might work fine.

I do think we should figure out a better approach, but I wanted to point out our existing setup would work for certain cases because I think we might be able to get to where we need to be with smaller changes than you might think.

Some ideas I'm tossing around:

  • The deposit() method on the strategy returns any assets it doesn't want to use and we attempt to provide that to the next strategy.
  • We add a balanced flag on strategies where allocate attempts to provide the same values of each of the supported assets. I know this is not a requirement for Curve, but it seems optimal given the bonuses. In general, other platforms are probably want to receive balanced amounts of tokens so it might be a good implementation for general use.

It seems like some of what may be required can be based off the calculateRedeemOutputs code.

@micahalcorn micahalcorn added P2 Small number of users are affected, major cosmetic issue and removed P1 Large amount of significant user impact, a meaningful feature is broken labels Sep 29, 2020
@micahalcorn micahalcorn added this to the 10/01/20-10/14/20 milestone Oct 10, 2020
@micahalcorn micahalcorn added P1 Large amount of significant user impact, a meaningful feature is broken and removed P2 Small number of users are affected, major cosmetic issue labels Oct 15, 2020
@micahalcorn micahalcorn added P2 Small number of users are affected, major cosmetic issue and removed P1 Large amount of significant user impact, a meaningful feature is broken labels Oct 28, 2020
@micahalcorn micahalcorn removed this from the 11/03/20-11/16/20 milestone Nov 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contracts Works related to contracts P2 Small number of users are affected, major cosmetic issue
Projects
None yet
Development

No branches or pull requests

3 participants