OriginProtocol / OriginProtocol/origin-dollar
Variable Performance Fee
Nobody has claimed this yet.
- Dominant language
- Solidity
- Stars
- 152
- Forks
- 115
- Avg merge
- 3d 20h
- Merged PRs (30d)
- 17
Description
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.
- 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.
- 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:
- 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.
- 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?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files or tests. Start by reviewing completed issue #527 and the existing contract logic around rebase and yield allocation; then determine how a variable fee should be defined and validated without relying on user-specific historical yield. Done requires an agreed design and implementation scope, which this issue does not yet specify.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- solidity
- Domain
- blockchain
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100