Although I agree with the general sentiment that this does not seem high priority, I do see that there could be 2nd and 3rd order effects of this capability that may not be immediately obvious. I’m curious what Ren’s rationale is for putting this as the first RFC; I’d bet this is only part of a bigger picture.
Personally, I’m supportive of this kind of functionality for the following reasons:
- Most obviously, increased security by reducing total withdrawable rewards on a constant basis rather than at the end of each epoch (because operators can continuously withdraw)
- Biggest impact, increased smooth flow of transactions and reduced gas costs for everyone especially those operating multiple nodes (computing fees occurring on RenVM would aggregate transactions to the VM rather than across multiple chains… these savings will be multiplied as RenTokens are put on multiple chains)
- It seems we’d be able to split rewards between multiple stakers** in one node allowing partial stakers that do not have the minimum 100k $Ren tokens (because rewards are represented in fractional tokens)
- Potentially, we can have daily registrations and de-registrations (because rewards aren’t locked on a 28 day basis) but there must be appropriate disincentives to deregister and incentives appropriately lower than operating a whole node yourself
- Speculatively, there could be potential to stake OFTs in a yield bearing pool in the future (because it will be its own erc20)
However in terms of risk, I’m curious how timing of claims (after large mint/burns or holding OFTs and withdrawing in the future when total available rewards are higher) would impact rewards, to @noah’s point. I’d hope that this functionality does not cause node operators to compete against each other to time their rewards.