[IP] USD3 Reward Ratio Change From 2 Weeks to 1 Week


Change the Reward ratio from 2 weeks to 1 week.

Current Reward Ratio:

2 weeks or 0.0000064180294

New Reward Ratio:

1 week or 0.000012836


Currently the reward ratio is set to 2 weeks. This proposal, if enacted, would change the reward ratio from 2 weeks(0.0000064180294) to 1 week(0.000012836).

The current 2 week reward ratio, means it takes longer for yield to propagate through the system, which means that yields can be slow to catch up in the case of large and sudden supply increases.

The rewardRatio is how much of the Furnace melting and StRSR drip to perform per block, as a function of the currently held (post-auction) revenue.

Problem Statement

There is a lag in revenue getting distributed to RSR stakers with the current 2 week reward ratio. This creates a problem of no economic incentive for RSR holders to want to stake and provide overcollateralization.

By keeping the two week reward ratio, this will likely lead to the same problem we see in every other RToken, where, if it grows too quickly the yield takes a while to get going.


We believe that providing a quicker feedback loop for the revenue getting distributed to RSR stakers would be a net positive. We believe this would be an incentive for more RSR holders to want to stake and provide overcollateralization to USD3.


One potential risk is that it could introduce opportunities for people to stake, get yield, and then unstake. However, we believe this is unlikely to be profitable with the 2 week unstaking delay.

What we really want to avoid is what we saw with bsdETH. It experienced a fast supply growth, and its backingBuffer took a while to fill up with enough revenue, so that RToken yield and staker yield took a long time to get off the ground.

  • Yes, I am for this proposal
  • No, I am against this proposal
0 voters

This makes perfect sense, allows for more streamlined (initiation of) revenues for RSR stakers. Also understood that 1 week ratio is the new default on the reserve protocol when creating a new RToken, additional evidence that this is the right way to go. I therefore support this proposal.