- BREAKING CHANGE: Updated stake and lock functions in StakeManager to accept an additional parameter for current lock until timestamp.
- BREAKING CHANGE: Modified StakeVault to handle the new locking mechanism and removed the old updateLockUntil function.
- Adjusted related tests to reflect changes in function signatures and expected behaviors.
- Ensured that funds locked checks are properly referenced in tests and contracts.
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 was a bandaid solution to easily allow for upgrade scripts.
We've changed those now to expect environment variables instead.
This allows us to change the dependencies without committing them to
version control.
This was uncovered when a user tried to migrate a `StakeVault` from one
deployed `StakeManager` to a vault that was registered with a different
`StakeManager` instance.
The result was that the data of the vault has been indeed migrated to
the new vault, however, since the vault queries stake data from the
`StakeManager`, the new vault is unable to properly calculated balances
to withdraw funds, among other things.
It shouldn't be possible to migrate to a vault that isn't registered
with the system a user migrates from, in the first place.
This commit ensures that by reverting when the `migrateTo` address isn't
a registered vault with the `StakeManager`.
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 is the 1st commit message:
feat(RewardsStreamerMP.t): improve fuzz tests to test revert cases
fix(StakeMath): prevent uint256 overflow error
fix(StakeMath): prevent unstaking zero
# This is the commit message #2:
fix(StakeMath): prevent unstaking zero
# This is the commit message #3:
refactor(fuzz-tests): enhance readibility + test for unstake
# This is the commit message #4:
chore(tests): add compoud fuzz test
# This is the commit message #5:
chore(tests): Add Compound Fuzz Test
# This is the commit message #6:
chore (tests): fix fuzz test Unstake to always call compound function before unstake.
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.
error
One of our tests uses too many local variables and causes stack too deep
errors unless optimized `--via-ir`.
We've introduced `--via-ir` to work around that until a proper fix is
done. The downside of using that option is that compilation times get
significantly longer.
This commit restructures the test such that it doesn't use as many local
variables.
Those were missing and now added.
Because of this we're running into stack to deep errors in test, so we
have to enable `via_ir` by default for now until we split things up.
ones
There are a bunch of error codes that are either similar to other ones
or not used at all.
This commit moves them to the interface and removes the ones that aren't
used anymore. Part of the reason we have so many unused errors becuase
they had been "reintroduced" in `StakeMath`, which we'll revisit as
well as described in #130
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
This commit introduces proxy clones to make create `StakeVault`s as
cheap as possible.
Major changes here are:
- Introduce `VaultFactory` which takes care of creating clones and
registering them with the stake manager
- Make `StakeVault` and `Initializable` so it can be used as a
"template" contract to later have proxies point to it
- Adjust the deployment script to also deploy `VaultFactory` and ensure
The proxy is whitelisted in the stake manager
- Make use of the new proxy clones in tests
- Add a test for `TrustedCodehashAccess` that ensures the proxy
whitelisting works and setting up a (malicious) proxy is not going to
work
Closes#101
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
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.
