Closed 0x-r4bbit closed 2 months ago
Interesting, this change broke the MPcantBeGreaterThanMaxMP
invariant.
Investigating this now..
The issue here is that, when we lock()
we just mint the amount of MPs necessary for the given duration but we don't perform the max boost check. And since we're no longer increasing the initialMP
when locking, we end up with currentMP > account.balance + account.initialMP
.
I'm closing this PR as invalid.
As discussed with @3esmit offline, initialMP
has to be updated when lock()
is called to properly calculate the max cap MP later on.
It turned out that initialMP
is just a misleading name. Hence, we're proposing the changes done in #95 which renames it to bonusMP
.
When an account calls
lock()
on theStakeManager
it ultimately called_mintInitialMP()
which besides increasing the accountscurrentMP
, it also increases the accountsinitialMP
.This seems incorrect, as
initialMP
should only increase at first stake.Also, notice how inside
lock()
it always passes anamount
of0
to to_mintInitialMP()
, so it only ever uses one code path of that function.This commit adjust
lock()
such that it no longer uses_mintInitialMP()
. Instead it makes use of_getMaxMPToMint
based on the lock up time delta.It also removes a test that claims that
initialMP
should increase onlock()
and instead adds a test an a CVL rule ensureinitialMP
doesn't increase when locking.Checklist
Ensure you completed all of the steps below before submitting your pull request:
forge snapshot
?pnpm gas-report
?pnpm lint
?forge test
?pnpm verify
?