This commit introduces changes related to vault registrations in the
stake manager.
The stake manager needs to keep track of the vaults a users creates so
it can aggregate accumulated MP across vaults for any given user.
The `StakeVault` now comes with a `register()` function which needs to
be called to register itself with the stake manager. `StakeManager` has
a new `onlyRegisteredVault` modifier that ensures only registered vaults
can actually `stake` and `unstake`.
Closes#70
This function allows users to `leave()` the system if they can't or
don't want to trust the stake manager. This is the case when the owner
of the stake manager performs an upgrade.
In case of such an upgrade, the stake manager will be marked as not
trusted which prevents the user from staking, unstaking, locking etc.
The user can then either explicitly trust stake manager (will happen in
future changes) to enable the vault's functionality again, or, `leave()`
the system at which point it will try to perform a benign `leave()`
operation and then move the funds out of the vault.
Closes#66
This commit introduces upgradeability of the `RewardsStreamerMP`
contract by leveraging the UUPS pattern.
This means, for deployment, we have to first deploy an instance of
`RewardsStreamerMP` contract as a "template" logic contract and then
create a ERC1967Proxy that points to it.
The proxy ensures the implementation address is stored in a
deterministic storage slot.
This will later be leveraged by the `StakeVault` contract to implement
the functionality to leave the system in case there was a malicious
upgrade.
Closes#22
This adds a new emergency mode that can be enabled by the owner of the system.
When in emergency mode, stakers or `StakeVault`s can leave the system immediately.
This also applies when there was a malicious upgrade and a call to
`emergencyModeEnabled()` panics.
To have this in a fully secure manner, we still have to add the counter
part of "leaving" the system. This will allow users that don't agree
with a (malicious) upgrade to get their funds out of the vaults
regardless.
Closes#66
`potentialMP`
This commit changes the mechanics to ensure there are no more MP
generated that what's allowed as per max limiting.
Previously we've kept track of `potentialMP` which would decrease as
more MP are generated.
This made verifying certain rules on certora hard and/or impossible.
So we decided to track `maxMP` instead, which only decreases when users
unstake.
This commit also introduces a rule that ensures any accounts MP never
exceed their max mp.
Closes#44
