feat: Add delayed redemptions #184
Conversation
bingen
force-pushed
the
delayed_redemptions
branch
from
be77d1f to
7d50dde
Compare
bingen
force-pushed
the
delayed_redemptions
branch
from
2658c96 to
452ee45
Compare
| boldToken.transfer(msg.sender, redemptionRefund); | ||
|
|
||
| // Send penalty to yield router | ||
| boldToken.transfer(interestRouterAddress, penalty); |
There was a problem hiding this comment.
Dunno what the final plans are, but currently, the ActivePools themselves split their yield 72:28 between the corresponding SPs & the global interestRouter. Are we intentionally leaving out the SPs here, e.g. for simplicity or because it's ambiguous who should get how much?
| _calcRedemptionRate(_getUpdatedBaseRateFromRedemption(_boldAmount, totals.boldSupplyAtStart)); | ||
| require(redemptionRate <= _maxFeePercentage, "CR: Fee exceeded provided maximum"); | ||
| uint256 redemptionRate = _calcRedemptionRate( | ||
| _getUpdatedBaseRateFromRedemption(redemptionCommitment.boldAmount, totals.boldSupplyAtStart) |
There was a problem hiding this comment.
The whitepaper declares that:
The resulting fee
f(t_j) = f_min + b(t_j)for a redeemer gets fixed upon commitment and is applied to the redeemed amount when the redemption is confirmed (see above).
Also see @cvalkan's comment in relevant Slack thread:
My mental model is that from the redeemer's perspective, the system state (relevant for the fee calculation) is frozen at commitment time, while for everybody else (i.e. subsequent redeemers) it continues to evolve normally.
I not sure if it necessarily has to work like that, just wanted to point out that we're deviating from the WP. If we decide not to implement it as described, then we should update the WP.
|
After some discussion during dev call and on Slack, we are not doing this for now. We may reopen it after the oracle decision (specially if we go for the composite solution). |
Closes #29