* MPMaximum Latex syntax fix
* Update T_RATE to reflect block time on SN Sepolia
* Pending Latex syntax fix
* Global Reward Latex syntax fix
* NewIndex Latex syntax fix
* reward example value typo fix
* format MathSpec table
* explicitly state T_RATE is chain dependent value
- 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.
This commit introduces a new contract `KarmaTiers` that allows for
maintaing tiers for gasless transactions.
The owner of the contract can add tiers, update tiers and deactivate or
activate them.
Tier names can only be 32 bytes long and there's no overlap allowed
between min and max Karma bounds of the tiers.
Closes#216
This commit introduces the ability for accounts with the necessary
privileges to slash other accounts. The amount to be slashed is
controlled via the `slashPercentage`.
The amount to be slashed will be calculated from the account's current
Karma balance, which is the total Karma across all distributors, minus
the known `slashAmount` for that account.
Under the hood, it calculates the slash amount for each item
(distributor or internal balance). This ensure we reduce the slash
amount correctly, if a reward distributor is removed.
**Example**:
For example, if the account has 100 Karma and hasn't been slashed
before, the account's balances would look like this:
```
rawBalance: 100
slashAmount: 0
balance: 100
```
Therefore, `balanceOf(account)` will return `100`.
If slashing burns 10% of the account's balance, then, after calling
`slash(account)`, the `slashAmount` will be increased accordingly:
```
rawBalance: 100
slashAmount: 10
balance: 90
```
Notice that `rawBalance` isn't actually a new contract property, but
there's a new internal function `_rawBalanceAndSlashAmountOf(account)`, which is used
by `balanceOf(account)` to determine the effective balance of an
account.
**Authorization**
In order to slash accounts, the message sender needs to have the newly
introduced `SLASHER_ROLE`.
Closes#212
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
When debugging storage layouts, it's actually hard to follow where all
the `__gap` fields are coming from when multiple upgradeable contracts
are part of the dependency chain.
This commit changes the name of `__gap` toa contract specific name,
allowing for clarity when inspecting storage layouts.
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
As described in #206 it's theoretically possible to cause overflows when
either Karma is issued via `mint()` or `setReward()` because both
functions don't take the supply of the other "domain" into account.
This commit fixes this by performing an arithmetic operation on
`super.totalSupply()`, `totalDistributorAllocation` and the newly issued
`amount`.
If there's an overflow, the code will cause an overflow and reverts.
This ensure overflows can't happen *after* rewards have been issued.
Closes#206
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)`
This is no longer a necessary requirement.
This commit removes `mintAllowance()`, it's internal counterpart and its
usage.
BREAKING CHANGE:
`mintAllowance()` no longer exists.
Closes#192
This is to align with all the other `mp*Of` and `mp*OfAccount`
functions as discussed in #188
BREAKING CHANGE:
`getStakedBalance(address)` is now `stakedBalanceOf(address)`
Closes#188
This commit does the following changes:
`_getVaultPendingMP()` -> _`vaultPendingMP()`
`_liveTotalMP()` -> `_totalMP()`
`_liveRewardIndex()` -> `_rewardIndex()`
`updateRewardIndex()` -> `_updateRewardIndex()`
BREAKING CHANGE:
The previous public `rewardIndex` field is now called `lastRewardIndex`.
Closes#189
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>
