Releases: stakewise/v3-core
v5.0.1
v5.0.0
Changelog
v5.0.0
A major release introducing the NodesManager system, a redesigned meta-vault architecture with a dedicated SubVaultsRegistry, new ERC-20 meta-vault variants, and the EthCommunityVault.
Breaking Changes
- Meta-vault architecture restructured. The shared
MetaVaultbase contract has been removed.EthMetaVaultandGnoMetaVaultwere moved out of thecustom/directory and now live alongside other vault types. Sub-vault state is no longer managed insideVaultSubVaults— it lives in a new standaloneSubVaultsRegistrydeployed per meta-vault. GnoPrivMetaVaulthas been removed. Private meta-vaults are now Ethereum-only, alongside the new ERC-20 variants.SubVaultUtilslibrary removed. Sub-vault logic was relocated toSubVaultsRegistryand the newExitPositionslibrary (renamed fromSubVaultExits).- OsToken immutables relocated. OsToken-related immutables moved out of
VaultImmutablesintoVaultOsToken. OsToken configuration moved intoVaultImmutablesand redemption logic intoVaultSubVaults. OsTokenRedeemerreworked to operate againstSubVaultsRegistryand support meta-vaults. Position tracking and the redemption update flow have changed.- Meta-vault factories are now permissionless.
New Features
- NodesManager: new component for delegating validator operations to node operators. Includes operator-state management with merkle proofs, oracle-signed validator registration, share donations, an exit queue, pending penalties, and minimum-balance checks. Supports delegation of the validators manager role and the withdrawals manager role. Introduces direct deposits in place of the old deposit queue.
- EthCommunityVault: new ERC-20 Ethereum vault with a locked
NodesManagerset as both fee recipient and validators manager. EmitsEthCommunityVaultCreatedon deployment. - ERC-20 meta-vaults:
EthErc20MetaVault,EthPrivErc20MetaVault, andEthPrivMetaVaultare now available. - SubVaultsRegistry & SubVaultsRegistryFactory: standalone registry contracts that own all sub-vault accounting (positions, exit queues, capacities) for a meta-vault. Upgrades remain gated by the parent meta-vault.
- Validator checker redemption support:
ValidatorsCheckernow factors redemption assets into its checks. - Meta-vault state updates in OsTokenRedeemer: redeemer now triggers state updates as part of redemption.
subVaultsExitsview: new function for inspecting per-sub-vault exit state.getExitQueueCumulativeTicketsview: exposes cumulative ticket counts on the exit queue.
Improvements
- BalancedCurator: simplified, and now respects each sub-vault's capacity when distributing deposits. Empty deposit lists are returned (instead of reverting) when no sub-vaults can accept funds. A new BalancedCurator has been deployed across all networks.
- Gas optimizations: reduced redundant memory operations in
OsTokenRedeemerandSubVaultsRegistry; cachedmetaVaultSLOAD before access checks inenterSubVaultsExitQueue; skipped redundant computation ingetExitQueueMissingAssetswhenqueuedSharesis zero; harvest checks are now skipped for uncollateralized meta-vaults. - Reentrancy hardening:
nonReentrantadded toSubVaultsRegistryandNodesManager.
Internal / Dev
- Pinned commit hashes for all GitHub Actions workflows.
- Renamed
SubVaultExitslibrary toExitPositions. - Updated and regenerated gas snapshots across the suite.
- Reworked upgrade scripts (
UpgradeEthNetwork,UpgradeGnoNetwork) to deploy only meta-vaults and the OsToken redeemer where applicable. - Deployment artifacts updated for mainnet, hoodi, and gnosis (including governor transaction batches).
Full Changelog: v4.0.1...v5.0.0
Audit: https://github.com/stakewise/v3-core/blob/v5.0.0/audits/2026-04-Statemind.pdf
v5.0.0d
v5.0.0c
v5.0.0b
v5.0.0a
v4.0.1
v4.0.0
What's Changed
Base
- Extracted the EIP-712 domain separator calculation from the
_computeDomainSeparatorfunction in theERC20Upgradeablecontract into theEIP712Utilslibrary to reduce the size of the vault contract. - Switched from Uniswap inspired
Multicallimplementation to OpenZeppelinAddress.functionDelegateCall
Curators
- Added the
BalancedCuratorcontract for theMetaVault. This contract calculates the amounts to deposit or withdraw from the sub-vaults, evenly distributing and allocating assets among them. TheMetaVaultshould set this contract as its curator to apply the even distribution logic. - Added the
CuratorsRegistrycontract, which keeps track of all registered curator contracts. Any new curator contract must be listed there to be used with theMetaVault.
Removed contracts
- Removed the
CumulativeMerkleDropcontract, as it is not currently in use. - Removed all
restakefunctionality from the vaults, as it is not currently in use. - Removed the
XDaiExchangecontract, as it has been replaced by theTokensConvertercontract.
Vaults
- Extracted all constructor arguments for the vault implementation contracts into structs (e.g.,
EthErc20VaultConstructorArgs) to avoid 'stack too deep' errors during compilation. - Added the
setAdminfunction to change the admin address of the vault. It can only be called by the current admin and emits anAdminUpdatedevent. - Added the
donateAssetsfunction to the vault, allowing anyone to donate ETH/GNO. It can be used to distribute or refund extra ETH/GNO rewards to the vault and emits anAssetsDonatedevent. - Added the
setFeePercentfunction to update the vault's current fee. It can only be called by the vault admin. The fee can be updated once every 3 days and may only be increased by up to 20% at a time. If the initial fee is 0%, the first increase is limited to 1%. - Replaced the
queuedSharesandtotalExitingAssetsfunctions withgetExitQueueData, which returns all queuing data for the vault. This change reduces the vault contract's bytecode size. - The minimum withdrawal delay for private vaults has been removed. For all other vaults, it has been reduced from 24 hours to 15 hours.
- Added the
fundValidatorsfunction to top up existing validators with ETH/GNO. It can only be called by an address with thevalidatorsManagerrole or by providing a validvalidatorsManagersignature. Top-ups are allowed only for validators that have been previously consolidated to a 0x02 validator or registered as a 0x02 validator. Emits aValidatorFundedevent. - Added the
consolidateValidatorsfunction for migrating 0x01 validators to 0x02 validators. It can only be called by an address with thevalidatorsManagerrole or by providing a validvalidatorsManagersignature. If the consolidation targets a validator that was not previously consolidated or registered with a 0x02 withdrawal prefix, oracle signatures must be provided. These signatures are verified using the newConsolidationsCheckercontract. ETH/xDAI must be sent along with the call to cover the consolidation fee, and any unused amount is refunded to the caller. Emits theValidatorConsolidationSubmittedevent. Note: a successful function call does not guarantee successful consolidation at the consensus level. - Added the
withdrawValidatorsfunction to trigger withdrawals from validators. It can only be called by an address with thevalidatorsManagerrole or by providing a validvalidatorsManagersignature. ETH/xDAI must be sent with the call to cover the withdrawal fee, and any unused amount is refunded to the caller. Emits theValidatorWithdrawalSubmittedevent. Note: a successful function call does not guarantee a successful withdrawal at the consensus level. - Modified the
registerValidatorsfunction to support registration of both 0x01 and 0x02 validators. It can only be called by an address with thevalidatorsManagerrole or by providing a validvalidatorsManagersignature. When registering a 0x02 validator, the amount in Gwei must be specified for each validator. Registration of a 0x01 validator emits aValidatorRegisteredevent, while registration of a 0x02 validator emits aV2ValidatorRegisteredevent. - Removed the
swapXdaiToGnofunction and deprecated theXdaiSwappedevent. DuringGnoVaultinitialization, aTokensConvertercontract is created. OnceGnoVaultpulls accumulated xDAI fromOwnMevEscroworSharedMevEscrow, it transfers it to theTokensConverter, converts it to sDAI, and uses CowSwap to swap it for GNO. InupdateState, all converted GNO is pulled back into the vault from theTokensConverterand accounted for using thedonateAssetsfunction. - Migrated the exit queue for
GnoVaultsfrom theexitingAssetsto theExitQueuelibrary, similar to the implementation used in ETH vaults. - Extracted the
calculateReceivedAssetsfunction, used for calculatingOsTokenliquidation and redemption assets, into a separateOsTokenUtilslibrary to reduce the vault contract's bytecode size. - A new
rescueAssetsfunction was added. It can only be called by the vault admin when no validators have been created. This function allows the admin, who has just created the vault, to withdraw an incorrectly created validator whose withdrawal credentials are set to the vault, but whose deposit was made directly to the Beacon chain contract instead of through the vault contract. The function is disabled once the first validator is created using the vault.
Genesis Vault
- Deprecated the
GenesisVaultCreatedevent, as it will no longer be emitted. Only one instance of the genesis vault exists, and it has already been created. - Removed the
acceptPoolEscrowOwnershipfunction, as ownership of thePoolEscrowhas already been transferred and the function will not be called in the future. - Removed rewards splitting with the legacy
rETH2contract.
Meta Vault
Added a new type of vault called MetaVaults. Unlike other vaults, MetaVaults do not register validators directly - instead, they delegate accumulated assets to sub-vaults, which are managed by the vault admin. Each sub-vault must have at least one registered validator, and up to 50 sub-vaults can be added to a MetaVault.
When a sub-vault is removed, all assets allocated to it enter the exit queue. Once the assets exit successfully, they are returned to the MetaVault, and the sub-vault is removed from the list.
Calling the depositToSubVaults function deposits all available assets from the MetaVault into the sub-vaults. The deposit and withdrawal amounts for each sub-vault are determined by the Curator contract, which can be changed by the admin using the setSubVaultsCurator function. By default, the BalancedCurator is used to evenly distribute and withdraw assets across sub-vaults.
In the updateState function, the locked amounts in all sub-vaults are synchronized, and the reward delta is calculated. Before calling updateState on the MetaVault, all sub-vaults must be up-to-date (i.e., updateState must be called on each sub-vault first). During the MetaVault's updateState, assets queued for exit are submitted to the sub-vaults. The curator contract determines the amount to withdraw from each sub-vault.
If a sub-vault is in the process of being removed, the exiting assets will be prioritized to process its exit queue before submitting new exit requests to other sub-vaults. All exit requests to sub-vaults must be claimed using the claimSubVaultsExitedAssets function before calling updateState on the MetaVault.
MetaVaults can be deployed using the EthMetaVaultFactory contract, and currently, only the factory owner is permitted to deploy new MetaVaults.
Reward Splitter
- Added a
claimerrole that can trigger exits on behalf of splitter shareholders using theenterExitQueueOnBehalffunction. The claimer is managed by the vault admin via thesetClaimerfunction. - Added the
claimExitedAssetsOnBehalffunction, which can be called by anyone to withdraw exited assets to the respective shareholder. - Replaced the owner of the
RewardSplitterwith the admin of the vault. - Added the
enterExitQueueOnBehalffunction, allowing anyone to enter the exit queue on behalf of a shareholder.
OsToken Redeemer
The new OsTokenRedeemer contract was introduced to enable OsToken redemptions. This contract is set as the redeemer in OsTokenConfig and can call redeemOsToken in the vault.
OsToken holders can enter the exit queue by locking their OsTokens in the OsTokenRedeemer contract and receiving an exit queue ticket. Once their OsTokens are redeemed for assets (ETH/GNO), they can claim them from the OsTokenRedeemer contract. The process is the same as unstaking ETH/GNO from the vault.
The exit queue is processed as follows:
- Collecting positions: The
PositionsManagercollects redeemable positions from the vaults. These are stakers in the vaults who have minted and sold their OsTokens, or whose LTV is approaching the liquidation threshold. Once all positions are collected, the manager proposes a new root and IPFS hash usingproposeRedeemablePositions. - Review by the redemptions committee: The redemptions committee reviews the proposed redeemable positions. If everything is correct, they approve it by calling
acceptRedeemablePositions. They can also reject the proposal by callingdenyRedeemablePositions. - Executing redemptions: Once the new root has been approved, the queued OsTokens can be redeemed from the vaults using
redeemOsTokenPositions. This function verifies that the position is included in the approved root, burns the OsTokens in the vault, and claims the corresponding assets. The vault must have enough unbonded assets (ETH/GNO) for the redem...
v3.0.1
v3.0.0
What's Changed
- Added the
EthOsTokenVaultEscrowandGnoOsTokenVaultEscrowcontracts. These contracts allow users to request an exit for staked ETH/GNO without immediately burning osETH/osGNO. This feature supports certain DeFi integrations by enabling users to 1) request an exit from the vault without burning osETH/osGNO, and 2) once the unstaked ETH/GNO is ready to be claimed, burn osETH/osGNO and receive the unstaked ETH/GNO in a single transaction. - Added
OsTokenFlashLoans. This contract allows to mint and burn osETH in single transaction (up to 100k osETH). For example, leverage strategy usesOsTokenFlashLoansto mint osETH, supply to Aave, borrow ETH, mint osETH from the vault and return the flashloan. - When user migrates from StakeWise Legacy, we always mint max amount of osTokens to the user in the Genesis Vault.
- Move back to the exit queue processing implemented in V1 vaults
- The
enterExitQueuefunction will return maxUINT256as position ticket in case the vault has no validators and assets vault can be redeemed. - The max possible osToken shares can be minted if max
UINT256is passed to themintOsToken. If no osToken shares can be minted, 0 will be returned.
Audit report
The audit was performed by Sigma Prime and is available here.
New Contributors
Full Changelog: v2.0.1...v3.0.0