OriginProtocol / OriginProtocol/origin-dollar

Variable Performance Fee

Open
#546 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

contracts enhancement P4
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.

  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?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.