search

OriginProtocol / origin-dollar

OUSD and OETH are stablecoins that passively accrue yield while you are holding it
https://originprotocol.com
MIT License
116 stars 79 forks source link

Variable Performance Fee #546

Open micahalcorn opened 3 years ago

micahalcorn commented 3 years ago

Now that https://github.com/OriginProtocol/origin-dollar/issues/527 is completed, we're reserving 10% of all OUSD yield and holding it in a contract that will eventually buy OGN. On a few occasions, we've discussed making this fee variable based on the APY. There are a couple of reasons to do this.

1) We've hypothesized that there is diminishing marginal utility for users as the APY increases. If OUSD is consistently returning 20%, for example, this may be enough of an increase over traditional finance or other substitutes to motivate people to buy OUSD. Doubling that yield to 40% isn't likely to double the number of people who convert. We could probably model an adoption curve that levels out in the upper double-digit range. We've received some anecdotal feedback from some early adopters validating this hypothesis. 2) Ridiculously high APYs might actually have an adverse effect on user psychology. When our annualized yield is above 100%, for example, people are likely more skeptical than when it is 20%. We also know that triple-digit APYs are not sustainable over the long-term. So it might make sense to smooth them out sooner rather than later and err on the side of accruing value to OGN rather than "wasting" yield on OUSD. And our ideal user isn't someone who apes in while the APY is 100% but quickly leaves when it falls to 20%.

A couple of concerns though:

  1. We may struggle to keep our APY above a certain threshold anyway. We wouldn't want to invest a lot of time and effort in a variable fee if we end up having a hard time achieving 20% yields as time goes on. This is largely outside of our control and we don't know what the long-term outlook is for money market rates and yield farming.
  2. How would we technically implement a variable fee? Our yield is sporadic and not very predictable. It also varies significantly for users depending on when they're holding OUSD. If you happen to come into OUSD just before a COMP harvest and then quickly redeem, your rate of return is much higher than someone else who holds OUSD over long periods of low yield from our strategies. So I don't think it would make sense to calculate a time-based yield and use this historical performance to determine how to allocate "current" yield in a given block. We also don't have any yield calculation built into our contract logic, I don't think. Introducing it would increase complexity and thus gas costs for anything that calls rebase.

Any thoughts @DanielVF @tomlinton @joshfraser @matthewliu?

tomlinton commented 3 years ago

I agree with your reasons for doing it. For the concerns:

  1. Agreed this is a problem, but it depends what a satisfactory yield looks like. If we cap it at 20% is that satisfactory? It goes back to modelling the adoption curve like you said. If we decide that 40% is what we need, then I think it'll be very hard to maintain and there isn't much sense in implementing this. I'm more on the fence about 20% though.
  2. We can cap the % increase of each rebase and divert the remainder. This will probably mean we have a lower APY than what we are targeting though which is not ideal. I can't think of a way to smooth it out over time without a lot of complexity.
joshfraser commented 3 years ago

Agree conceptually that this would be valuable, but I think there are probably more pressing issues for us to focus on right now & I don't like the added complexity. My vote would be to keep this issue open and revisit it in a few months.