This was some version of the staking contract for demonstration purposes
and is not actually used as we're working on `RewardStreamerMP` version,
which is aware of multiplier points.
Closes#84
This commit introduces a deployment script for the stake manager which
can later be extended to work with other networks.
The deployment script is also used inside our testsuite, ensuring it's
working as intended.
Closes#88
Whenever `account.lastMPupdateTime` is set, we also call
`_updateAccountMP()` before that, which never reverts, so the value set
there will never differ from the ones we set later explicitly.
Closes#80
As mentioned in #82, increasing `currentTime` by 1 second isn't enough
to actually create new MPs, so the test could return false positives.
This change increases the time between checks arbritraryly longer, such
that MPs would actually be created if the max MP wasn't reached.
Closes#82
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
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
