Open mart1n-xyz opened 1 month ago
This relates to the debate on total supply and some implementation details of the desirable UX. I wanted to show that
rewardsPerBlock
ahead) are actually practical - one can preset the contract for a desirable period where the total rewards distributed can be result of "some formula" that is a function of, say, the total supply in the previous period (as Cyp suggested in the call). I'd say it is not practical to change setup or send rewards to the contract every block. If setting rewardsPerBlock
in advance is not desirable, the contract can have epoch: any rewards that arrived in previous epoch determine the rewardsPerBlock
in the current epoch (past_rewards/blocks_in_epoch).
Description
Main changes:
currentRewardIndex()
now usesrewardsPerBlock
andblock.number
to determine the currentrewardIndex
but does not update state. Hence, balances update in real time without a need for a transaction.updateRewardIndex()
updates state with the same logic.setRewardsPerBlock()
is an ownable function that changesrewardsPerBlock
untilrewardEndBlock
, it callsREWARD_TOKEN.mint()
for the amount need for this period given the two parameters. So, there should be always sufficient rewards ready in the contract.Checklist
Ensure you completed all of the steps below before submitting your pull request:
pnpm adorno
?pnpm verify
?