-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spearbit Audit september 2023 #232
Conversation
Codecov Report
@@ Coverage Diff @@
## main #232 +/- ##
==========================================
- Coverage 88.17% 83.88% -4.30%
==========================================
Files 18 19 +1
Lines 1201 1272 +71
Branches 193 205 +12
==========================================
+ Hits 1059 1067 +8
- Misses 93 153 +60
- Partials 49 52 +3
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Relevant fixes from Spearbit audit have been implemented.
2 CI tests are failing:
- lint
- check deploy scripts
Both are ok locally, but I don't want to add another commit to fix those now that the Audit period is over. This will need to be fixed after this PR.
In the meantime, LGTM 🚀
Branch for the spearbit audit
getRiver()
view function toRedeemManager
setOperatorStoppedValidatorCount
eventMore info on the global unlock schedule :
Due to legal & regulatory concerns it was to chosen to apply a global unlock schedule to most, but not all vesting schedules.
The global unlock schedule must release 1/24 th of the total amount of the vesting schedule every month for 2 years after the schedule local lock end. The unlocking is entirely separated from the vesting it just caps the withdrawal of the vested tokens.
Some schedules are not subject to the global unlock schedule, this is why we added the
IgnoreGlobalUnlockSchedule
mapping and altered the vesting schedule creation function to fit the new behaviour.The global unlock schedule computation is done in the existing function where the local lock is taken into account.
Those changes are accompanied by a migration, contained in the migration contract, which should be applied before pointing to the new implementation.
The migration sets
IgnoreGlobalUnlockSchedule
for the schedules where it's needed and also updates some erroneous values currently set.