Commit Graph

27 Commits

Author SHA1 Message Date
Ricardo Guilherme Schmidt c08fe417ba
feat(StakeVault): add withdraw function and improve documentation
This commit introduces new functions for keeping track of the total amount staked and implements a function to check the available amount of tokens that can be withdrawn. Users are able to withdraw tokens that are not commited to stake by calling the withdraw functions. These changes enhance the overall usability and flexibility of the StakeVault contract.
2024-10-01 18:30:10 -03:00
Ricardo Guilherme Schmidt 769f32f718 refactor(StakeManager): replace epoch.startTime with a global startTime
As now all epochEnd() are multiples of EPOCH_SIZE, we can drop the startTime from the struct Epoch, and avoid storing an information that can be cheaply calculated on the fly.

- Refactored the StakeManager contract to optimize the finalization of epochs and execution of accounts and epochs.
- Replaced the Epoch.startTime with a new global variable startTime to keep track of the start time of the contract.
- Modified the finalizeEpoch function to use a temporary variable for the current epoch and calculate the epoch reward only for the current epoch.
- Updated the migrationInitialize function to set the start time using the new startTime variable.
- Modified the epochEnd function to calculate the end time of the current epoch using the startTime variable.
- Modified the newEpoch function to calculate the number of the next epoch based on the startTime variable.

refactor(StakeManager): set startTime as immutable, load startTime from previousManager at constructor, verify startTime is correct on initializeMigration
2024-09-26 15:41:35 -03:00
Ricardo Guilherme Schmidt 4a261e8b48 refactor(StakeManager): optimize epoch finalization and execution of accounts and epochs
This commit refactors the StakeManager contract to optimize the finalization and execution of epochs. It updates the function finalizeEpoch() to new function finalizeEpoch(uint256 _limitEpoch) that releases rewards for the current epoch and increases the epoch up to the specified limit. This allows for more efficient processing of epochs.

The changes also include updates to the executeEpoch() and executeAccount() functions to utilize the new finalizeEpoch() function. Additionally, a new function newEpoch() is introduced to calculate the last epoch that can be processed based on the current time. Now the executeAccount(account,limit) will also process epochs up to the specified limit.

Added a overload of the executeAccount to process the account up to the newEpoch()

Added a overload of the executeEpoch to allow the process of epochs up to a certain limit.

All methods now that finalizeEpoch will process the epochs up to the newEpoch().

These changes improve the overall performance, user expirience and reliability of the StakeManager contract.

chore(StakeManagerStartMigration.spec): add new function executeEpoch(uint256) to blockedWhenMigrating

fix(StakeManager.sol): Replace the check for pending migration in migrationInitialize with noPendingMigration modifier to avoid code duplication
2024-09-26 15:41:35 -03:00
Ricardo Guilherme Schmidt 142137dee7 fix(StakeManager): fix finalizeEpoch to use last epoch epochEnd and add tests to catch error 2024-09-26 15:41:35 -03:00
Ricardo Guilherme Schmidt 4a545a0ed4 chore(test): fix fuzzing function to properly test whats suppoused to and make it deterministic in amount of calls 2024-09-25 12:41:23 -03:00
Ricardo Guilherme Schmidt 653fe5a542 chore: update project description and author information, update README.md 2024-09-25 11:29:22 +02:00
Ricardo Guilherme Schmidt 474e7cacf5 chore(foundry.toml): update fuzzing settings 2024-09-23 06:10:17 -03:00
Ricardo Guilherme Schmidt 2a90b3e6ad chore(.gas-report, .gas-snapshot): update reports 2024-09-19 17:26:17 +02:00
Ricardo Guilherme Schmidt 0c58dfe241 test(StakeManager): add test to catch bug in minting more bonus MPs when stake with lock 2024-09-12 11:44:48 +02:00
Ricardo Guilherme Schmidt 8683376160 feat(StakeManager): optimizations on processAccount 2024-09-11 20:09:08 +02:00
Ricardo Guilherme Schmidt b19182ad20 chore(StakeManager): remove unnecessary `finalizeEpoch` modifier from `migrateTo`
Fixes #109
2024-09-11 16:43:59 +02:00
Ricardo Guilherme Schmidt 58ca65120f chore(StakeManager: remove irrelevant code from `_mintBonusMP` function
Fixes #108
2024-09-11 16:17:17 +02:00
Ricardo Guilherme Schmidt b2a0d0cf25 fix(StakeManager): use while loop instead of hacky for loop in process account
chore: lint again with foundry updated
2024-09-11 15:18:24 +02:00
r4bbit 5dec595a20 feat(StakeManager): implement multiplier points estimation
This commit introduces the internal accounting logic for accrueing
multiplier points, that will later be used to determine how many
experience points an account is eligible to.

The majority of the work here was done by @3esmit.
2024-09-10 08:51:35 +02:00
Ricardo Guilherme Schmidt 6c358dab9e fix(StakeManager): use OpenZeppelin Math to avoid precision loss in int divisions 2024-02-26 10:07:54 -03:00
Ricardo Guilherme Schmidt 92ff9bff21 refactor(StakeManager): account initialize in currentEpoch 2024-02-26 10:07:54 -03:00
Ricardo Guilherme Schmidt 17f859577a refactor(StakeManager): change MIN_LOCKUP_PERIOD to 2 weeks 2024-02-23 11:56:03 -03:00
Ricardo Guilherme Schmidt c9ed9dd833 refactor(StakeManager): refactor multiplier points logic 2024-02-23 10:57:17 -03:00
Ricardo Guilherme Schmidt 03bc6559ae fix: StakeManager migration fixes and certora rules 2024-02-20 09:08:00 +01:00
r4bbit d9a64559a2
fix(StakeManager): add checks for whether lockup period is in range (#39)
This commit introduces `MIN_LOCKUP_PERIOD` and `MAX_LOCKUP_PERIOD` and
makes use of them within `StakeManager.stake()` and
`StakeManager.lock()` accordingly.

When users deposit tokens into their vault via `stake()`, they can
provide an optional lockup time. If the value is `0` it implies users do
not want to lock their stake.

If the value is `> 0` it has to be within the range of
`MIN_LOCKUP_PERIOD` and `MAX_LOCKUP_PERIOD`.

Properly addresses #15
2023-12-06 12:10:07 +01:00
r4bbit f259286e98
feat: introduce `VaultFactory` (#38)
This commit introduces a first version of a `VaultFactory` that later
will be extended to be capable of instantiating reward vaults and
possible keep track of vault instances per owner.

As a first step, this implementation comes with a `createVault()`
function which takes care of creating vaults.

Because `VaultFactory` also knows about `StakeManager` it can derive the
manager's address and stake token from it when creating vaults, allowing
the API to be without arguments.

Partially addresses #37
2023-11-07 09:49:22 +01:00
r4bbit b5e513ce49
refactor(StakeVault): introduce `stakedToken()` API (#36)
Because the `stakedToken` property is `immutable`, solhint recommends to
make it in all caps. This commit changes the property to adhere to that
rule and also makes the property private.

To access the `stakedToken` there's now a `stakedToken()` function on
the contract.
2023-11-07 09:40:38 +01:00
r4bbit 70c74e2c2c
refactor(StakeVault): use custom error over error strings (#35) 2023-11-07 09:38:00 +01:00
r4bbit 6f591dd674
refactor(StakeManager): use custom errors everywhere (#30) 2023-10-10 15:49:34 +02:00
r4bbit 03d2dcf3e8
refactor(StakeManager): add custom `StakeManager__FundsLocked` error (#29) 2023-10-10 15:44:16 +02:00
r4bbit eeffcfe7d7
refactor(StakeManager): use custom error in `onlyVault` modifier (#28)
Also introduce tests that ensure the error is actually emitted.
2023-10-10 15:32:46 +02:00
r4bbit 725d380547
test(StakeManager): expand on deployment test (#27)
Added some additional assertions related to access control and exposed
properties.
2023-10-10 13:53:03 +02:00