If there's a malicious upgrade which causes a stack overflow error when
`leave()` is called, the user of the vault should still be able to get
their funds out.
This commit adds a test that proofs this is happening.
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
This enables whitelisting in the staking manager contract using the
`TrustedCodehashAccess` interface.
These changes were largely taken from #39 with few changes:
- Due to different OZ versions, `Ownable()` constructor needs to be
called with owner
Closes#15
This introduces a first version of `IStakeManager`, highly inspired by
the changes done in
https://github.com/vacp2p/staking-reward-streamer/pull/39.
However, in this commit, it only adds the methods that are currently
supported by both, `StakeManager` and `RewardStreamerMP`.
Future commits will add APIs for locking and leaving.
This ports the `StakeVault` contract over to this repository
and exposes functions to interface with the reward streamer contract
to address issue #14.
Closes#14
correctly at unstake
This commit adds some tests to check that, if a user (partically)
unstakes their funds, their initial and bonus MP get decreased
proportionally, as well as their max mp.
Closes#46
`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
This commit changes the calculation for when MPs are reduced globally
and for the user that is unstaking.
Instead of getting an `amountRatio` first and using that the
multiplication, we're now applying the `SCALE_FACTOR` to both, the
numerator and denominator to maintain the ratio while increasing
precision.
