The RewardsManager contract integrates with vaults to manage their users' rewards. Rewards can be added to the RewardsManager contract by anyone. Those rewards can be claimed directly from the RewardsManager contract by the vault's depositors. Rewards accumulate per epoch, each of which has a duration of one week.
Check the Audit before using this code into production.
Also fully read the readme below
https://mint-salesman-909.notion.site/Badger-Rewards-Intro-58ce9b2026dc4c39a180a1c3bac47477
https://miro.com/app/board/uXjVOQU-Z8A=/?invite_link_id=120636167771
Allows to vest rewards based on time spent
Use case is deposits in a vault so that Badger Dao can move to fully onChain emissions Code is generalized enough to allow to handle an unknown amount of rewards for an unknown amount of types of tokens
If you wish to run all tests use:
brownie test
For gas benchmarks:
brownie test --gas
For Coverage:
First, change DEPLOY_TIME to be non-immutable (due to a bug from Brownie)
Then run:
brownie test --coverage
Report: https://docs.google.com/document/d/1bO2XfwQ60wQWePihgJu6UsukimI5ygTmC1rBTMGGNp0/edit Status: Vulnerabilities have been mitigated
Report: https://www.hacknote.co/17c261f7d8fWbdml/17f3efe98b4HW20Y Status: Vulnerabilities have been mitigated
Report: https://docs.google.com/document/d/1l3sWKgKrp29syOj3_dX7tCozVtmpwYOIykBj1A-unVU/edit# Status: Vulnerabilities have been mitigated
Vault tokens being sent to this contract causes unfairness in claiming tokens as the rewards contract will receive a portion of the rewards
Solution: Accrue the contract and calculate the totalSupply - thisContract Supply
Status: Mitigated
- Can you cause the Points to be greater than TotalPoints, allowing to extract more than the rewards for one epoch for one vault?
yarn
yarn format
## Provably unfair math
The first release of this contract tries to handle self-emitting vaults (vaults that add themselves as rewards to depositors), however the math is provably unfair towards late claimers.
Make sure self-emitting vaults are not used (just auto-compound bruh), and if they are, make sure to claim every week.
I kind of gave up on tracking a week across leap years, either way, the contract uses EPOCHS as: Set Amounts of time, as such, while the "claiming day" will end up switching every 4 years, the time in between claims will be consistent (as it's tracked in seconds).
For those reasons, please don't send reports about the math not being once per week.
In a system that is lower yield, higher gas, more predictable (think fixed yield), you could re-use the contract with a SECONDS_PER_EPOCH set to a month or even more.
Negatives:
- Can claim less often
Positives:
- Each claim is "bigger" and as such the fixed cost of gas is less noticeable