OIP-8 Per Block Yield

[DanielVF]

The oTokens could have per block yield. Like aTokens, the balanceOf would constantly be moving up, our current rebaseRatio would also move block by block.

For gas efficiency, we would want to avoid writes to "global" variables during this. A write to an extra per account variable during a transfer could be okay.

We'd want these balance increases to be time capped, with an end. For example, increase to X from Y over Z time. For precision we would want to work off these totals rather than using a rate per block or rate per second.

Tokens to research look at are the different aTokens, sFrxETH.

👍 We should be able to ensure exact transfers by doing math in balance space (as we've already explored in PR #1680)

👍 This would also unlock making rebases happen less frequently, or disconnected from the daily calendar. This would benefit OUSD, since we would not need to rebase as often. This would benefit OETH because we might only rarely actually need the incentivized rebasing if we had had an organic rebase in the last X hours.

😢 This would probably make CEX exchange support even harder than it already is. However, anyone supporting sFrxETH or aTokens will already be dealing with this. It probably makes DEX yield support easier.

[micahalcorn]

Thanks @DanielVF 👊 We should also consider what the consequences are for user experience. @joshfraser pointed out that this will make tax reporting even more interesting since there may not be discreet events where the balance increases. I suspect there's a frontend solution for this but it will be more complicated than just exporting the rebases.

In terms of benefits, I like that the balance is always going up instead of just happening one or more times per day. But I wonder if users would actually experience this in a meaningful way. I'm not sure if wallets, like MetaMask, poll the balances vs just listening to transfers and calling balanceOf when the wallet is opened. In other words, I doubt you would be able to sit there with your wallet open and watch the money pile up. We already know from experience that Etherscan caches balances and only updates when certain pages are requested.

[DanielVF]

At the least it makes it nice for analytics tools. Our UI can also get the exact balance at the time and show it to the user.

[DanielVF]

@micahalcorn I agree that the key thing is user experience. Got any ideas how we would find out what people would like?

Just following my own nose, about what I'd like to use, I like it. :D

[rafaelugolini]

Thanks @DanielVF 👊 We should also consider what the consequences are for user experience. @joshfraser pointed out that this will make tax reporting even more interesting since there may not be discreet events where the balance increases. I suspect there's a frontend solution for this but it will be more complicated than just exporting the rebases.

We have 4626 woTokens for that :)

[micahalcorn]

We'd want these balance increases to be time capped, with an end. For example, increase to X from Y over Z time. For precision we would want to work off these totals rather than using a rate per block or rate per second.

@DanielVF would the rebase change X in this case? I'm trying to understand the role of the rebase if rebaseRatio is constantly changing.

[matt-bullock]

I like the idea of the balance constantly growing in the analytics tool and in the user balance and earnings within the dapp UIs. It's probably something we could market well. But as Micah mentioned, I'm not sure it would make a huge difference to users that have grown accustomed to checking their balances daily/weekly and are used to seeing their balances grow anyway within those timeframes.

[micahalcorn]

@DanielVF a few follow-up questions from our product meeting:

• Does this have any impact on our move to 100% Dripper integration with the vault or that's a separate concern?
• Would this change how our APY is calculated?
• What events would be emitted and when? Is it still a rebase event, just less often? This would have implications for how the frontend would display yield history.
• Same question from above ☝️

[DanielVF]

1. It does not impact it, but it might do 99% of the job of it. There's very little APY benefit from building the dripper in, the main reason for having a dripper is the UX of a more constant earning rate, and we'd like that across everything. This gives us that smooth earnings across all yield.

2. It would make user side calcs more accurate, since the current rebase ratio on the OUSD would always be accurate to the block.

3. No events on the per block rebasing. We would emit an event whenever we refreshed the OUSD token growth rate. Yes, this might need some front end calculation rethinking.

4. We would still have a time when we compare how much the vault has to how much OUSD is out there, and recalculate how much OUSD to hand out. The handout would just be over time, rather than instant.