This commit introduces `AccessControl` capabilities to Karma. The reason this is done so that there can be multiple actors in the system with different privileges.
The main changes done here are:
- Introduce internal functions for most of the `Karma` specific logic (this is necessary to allow properly extending the contract's functionality via modifiers) later on
- Inherit AccessControlUpgradeable contract
- Introduce OPERATOR_ROLE next to the already provided DEFAULT_ADMIN_ROLE
This is an alternative solution to the PR in #209.
Instead of providing an upgrade version, this commit is a breaking
change as it introduces a storage layout conflict.
BREAKING CHANGE
This commit introduces a storage layout conflict.
Redeployment required.
Closes#207
Most of the reasoning has been discussed in #208.
Primarily what's happening here is:
- `StakeManager.VaultData.lockUntil` has been removed
- `StakeVault.lockUntil` has been introduced
- `StakeVault.updateLockUntil(uint256 value)` has been introduced
- `StakeVault.leave()` performs normal `leave()` action but keeps funds
in vault if lockup period hasn't expired
- `StakeVault.withdrawFromVault()` has been introduced to withdraw
remaining *stake* funds in vault
BREAKING CHANGE:
- `StakeManager.VaultData.lockUntil` has been removed
- `StakeVault.lockUntil` has been introduced
- `StakeVault.leave()` performs normal `leave()` action but keeps funds
in vault if lockup period hasn't expired
Closes#208
This renames `RewardsStreamerMP` to `StakeManager`. The original name
only exists because the project has started with different versions of
the contract. Since the contract is no longer just dealing with MPs but
actually distributes rewards, it makes sense to make this the official
stake manager of the protocol.
**BREAKING CHANGE:**
- `RewardsStreamerMP` is now `StakeManager`
- `StakingManager__*` error selectors are now `StakeManager__*`
selectors
After doing somme work on merging `compound()` into `updateVault()`, we
noticed that both, `vault.mpStaked` and `vault.mpAccrued` are always
equal.
Therefore, we're removing `vault.mpStaked`.
BREAKING CHANGE:
- `VaultData.mpStaked` no longer exists, use `VaultData.mpAccrued`
instead.
- `Compound(address,uint256)` is now `VaultUpdated(address,uint256,uint256)`
- `AccountLeft(address)` is now `VaultLeft(address)`
fix(MultiplierPointMath): Fix helper function to correctly estimate avaliable lock time
chore(spec): remove additional field which does not exist anymore
This commit merges `compound()` into `_updateVault()` as there's no
reason not to update vault without compounding it.
This was discussed in #187.
BREAKING CHANGE: A couple of APIs have been removed or replaced.
-> inline _compound into _updateVault()
-> remove compond() in favor of updateVaultMP()
-> rename updateVaultMP() to updateVault()
-> rename compoundAccount() to updateAccount()
Closes#187
This commit enables users to stake multiple times into the same vault
with a lock increase.
If their total lock increase goes beyond the maximum lock period,
staking will revert. In this case users will have to create a new vault.
Closes#152
Co-authored-by: Andrea Franz <andrea@gravityblast.com>
We put `cancun` as evm version into the foundry toml by mistake and
ended up building on top of it with certain assumptions.
Turns out that the network we're deploying to does not support that
version so we have to compile with `paris`.
This however, also requires a downgrade of the open zeppelin libraries,
which in turn requires changes in our code base. Primarily related to
initialization of `OwnableUpgradeable` and upgrades via UUPSUpgradeable.
This commit makes all the necessary changes.
This commit introduces a function `migrateToVault(address)` that allows
`StakeVault`s to migrate to other `StakeVault` instances.
The idea is that, when an upgrade was done on the stake manager, it
might introduces functions that can't be accessed through the stake
vaults that are out there.
Users will have to create new stake vault instances that provide the
necessary functionality.
`migrateToVault()` allows them to do so.
Closes#127
Originally, I just wanted to simplify the certora rule that,
when emergency mode is enabled, only a few selected functions can be
called.
Instead of listing all the view function as "allowed", I've moved to
using CVLs `isView` flag on the function under verification.
This however uncovered a violation where
`RewardsStreamerMP.registerVault` is allowed to be called in emergency
mode.
In theory there's no harm in registering a vault when the system is in
emergency mode, but semantically it doesn't really make sense.
`registerVault` has been accidentally added to `isViewFunction()`.
This commit fixes this by adding `onlyNotEmergencyMode` modifier to
`registerVault()`.
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
