Changelog - HackMD

## Gnosis vaults - New [Gnosis vaults](https://github.com/stakewise/v3-core/tree/main/contracts/vaults/gnosis) were deployed to the Gnosis network. They use the new [VaultGnoStaking](https://github.com/stakewise/v3-core/blob/main/contracts/vaults/modules/VaultGnoStaking.sol) module. The main differences from the Ethereum vaults are as follows: - Deposits are made in GNO tokens, and ERC-20 approval must be done before the call. - Partial and full withdrawals are stored in the [contract](https://gnosisscan.io/address/0x0B98057eA310F4d31F2a452B414647007d1645d9) used to register the validators. They are pulled by the vault during user withdrawals, validator registrations, and state updates. - 1 GNO, instead of 32 ETH, must be staked for the validator to activate. - Rewards from transaction fees are received in xDAI and must be swapped using the [swapXdaiToGno](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultGnoStaking.sol#L37) function. This function performs the transaction through the Balancer pool (which can be updated by the DAO) and uses oracles to verify the correct swap price in the [XdaiExchange](https://github.com/stakewise/v3-core/blob/main/contracts/misc/XdaiExchange.sol#L114) contract. ## Restake vaults - New [Restake vaults](https://github.com/stakewise/v3-core/tree/main/contracts/vaults/ethereum/restake) were deployed to the Ethereum network. They use the new [VaultEthRestaking](https://github.com/stakewise/v3-core/blob/main/contracts/vaults/modules/VaultEthRestaking.sol) module. The main differences from the regular Ethereum vaults are as follows: - The new [createEigenPod](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEthRestaking.sol#L54) function creates [EigenPod](https://github.com/Layr-Labs/eigenlayer-contracts/blob/dev/src/contracts/pods/EigenPod.sol) and [EigenPodOwner](https://github.com/stakewise/v3-core/blob/main/contracts/vaults/ethereum/restake/EigenPodOwner.sol) contracts and emits the [EigenPodCreated](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEthRestaking.sol#L19) event. The `EigenPodOwner` contract is the owner of the `EigenPod` and stores the functions to manage it. All the eigen pods can be retrieved using the [getEigenPods](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEthRestaking.sol#L49) function. - The new [restakeOperatorsManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEthRestaking.sol#L37) role was added to the vault. The address assigned to this role can create new [eigen pods](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEthRestaking.sol#L54) and [delegate](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IEigenPodOwner.sol#L62) or [undelegate](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IEigenPodOwner.sol#L71) eigen operators to the eigen pods. This role is assigned to the vault admin by default and can be updated by the vault admin using the [setRestakeOperatorsManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEthRestaking.sol#L66) function, which emits the [RestakeOperatorsManagerUpdated](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEthRestaking.sol#L25) event. - The new [restakeWithdrawalsManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEthRestaking.sol#L43) role was added to the vault. The address assigned to this role can [verifyWithdrawalCredentials](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IEigenPodOwner.sol#L48) for the eigen pod validators, enter the exit queue in the Eigenlayer using [queueWithdrawal](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IEigenPodOwner.sol#L77), and complete queued withdrawals from the Eigenlayer using [completeQueuedWithdrawal](https://github.com/stakewise/v3-core/blob/main/contracts/vaults/ethereum/restake/EigenPodOwner.sol#L147). This role is assigned to the vault admin by default and can be updated by the vault admin using the [setRestakeWithdrawalsManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEthRestaking.sol#L60) function, which emits the [RestakeWithdrawalsManagerUpdated](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEthRestaking.sol#L31) event. This role must be assigned to the [v3-operator](https://github.com/stakewise/v3-operator) hot wallet to manage the EigenLayer withdrawals. - The validators registered for the vault must include a withdrawal address that matches one of the eigen pods created for the vault. The withdrawal address is then converted to the withdrawal credentials as seen [here](https://github.com/stakewise/v3-core/blob/main/contracts/vaults/modules/VaultEthRestaking.sol#L101). ## Blocklist vaults - New [blocklist vaults](https://github.com/stakewise/v3-core/tree/main/contracts/vaults/ethereum) were deployed to Ethereum and Gnosis. These vaults use the [VaultBlocklist](https://github.com/stakewise/v3-core/blob/main/contracts/vaults/modules/VaultBlocklist.sol) module, which keeps track of accounts that cannot stake to the vault. For example, you can block all sanctioned addresses from depositing to your vault. - The account with the [blocklistManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultBlocklist.sol#L32) role can manage the blocklist. This role is assigned to the vault admin by default. The vault admin can update the role using the [setBlocklistManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultBlocklist.sol#L52) function, which emits the [BlocklistManagerUpdated](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultBlocklist.sol#L26) event. - You can use [blockedAccounts](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultBlocklist.sol#L39) to check whether an account is blocked. The `blocklistManager` can update the list using the [updateBlocklist](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultBlocklist.sol#L46) function. Blocklist updates emit the [BlocklistUpdated](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultBlocklist.sol#L19) event. ## Exit queue - The [enterExitQueue](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEnterExit.sol#L88) function now locks the conversion rate between assets and shares at the time of the call, rather than during the `updateState` call. Shares are burned immediately. The locked assets will not receive rewards after the call but will incur penalties if the vault APY is negative. These penalties will be distributed proportionally to all assets in the vault. Exit positions created before the upgrade will be processed according to the Vault’s V1 logic. - All newly created exit positions now emit the [V2ExitQueueEntered](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEnterExit.sol#L60) event. - The [ExitingAssetsPenalized](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultState.sol#L33) event is emitted during the updateState call if the vault incurs a penalty. The penalty will be proportionally distributed among all currently exiting assets. - The [claimExitedAssets](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEnterExit.sol#L126) will not return anything after the upgrade. - The [claimExitedAssets](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEnterExit.sol#L126) must be used for the exit positions created before and after the vault upgrade to V2. - The `redeem` function was removed. All the exits must be submitted using [enterExitQueue](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEnterExit.sol#L88). - The [totalExitingAssets](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultState.sol#L69) function was added to the vault. It returns the total amount of assets in the exit queue after the upgrade to V2. - For exit positions created after the upgrade, the [getExitQueueIndex](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEnterExit.sol#L99C12-L99C29) function is not needed. You can pass `0` to both the [calculateExitedAssets](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEnterExit.sol#L112) and [claimExitedAssets](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultEnterExit.sol#L126) functions. ## Validators management - All the logic for managing the vault’s deposit data has been moved to the immutable [DepositDataRegistry](https://github.com/stakewise/v3-core/blob/main/contracts/validators/DepositDataRegistry.sol) contract: - The `validatorsRoot` was moved to [depositDataRoots](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IDepositDataRegistry.sol#L55). - The `validatorIndex` was moved to [depositDataIndexes](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IDepositDataRegistry.sol#L48). - The `keysManager` was moved to [getDepositDataManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IDepositDataRegistry.sol#L62). - The `setKeysManager` was moved to [setDepositDataManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IDepositDataRegistry.sol#L69). - The `registerValidator` was moved to [registerValidator](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IDepositDataRegistry.sol#L94). - The `registerValidators` was moved to [registerValidators](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IDepositDataRegistry.sol#L108). - During the vault upgrade, all current values for the variables above are migrated to the `DepositDataRegistry` contract, so no extra actions are needed. - The new [validatorsManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultValidators.sol#L46) role was added to the vault. The address that is assigned to this role can register validator(s). It defaults to the `DepositDataRegistry` contract. The `validatorsManager` role can be update by admin using the [setValidatorsManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultValidators.sol#L62) function. The function emits the [ValidatorsManagerUpdated](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultValidators.sol#L40) on every update. - The new [validatorsManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultValidators.sol#L46) role has been added to the vault. The address assigned to this role can register validator(s) and defaults to the `DepositDataRegistry` contract. The `validatorsManager` role can be updated by the admin using the [setValidatorsManager](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultValidators.sol#L62) function. This function emits the [ValidatorsManagerUpdated](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultValidators.sol#L40) event on every update. - The new [registerValidators](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IVaultValidators.sol#L53) function has been added to the vault. This function allows for the registration of both single and multiple validators. It can only be called by the `validatorsManager` or by providing the signature of the `validatorsManager` over the validator registration data (see example [here](https://github.com/stakewise/v3-core/blob/main/test/EthVault.register.spec.ts#L201)). ## Private vaults - The ERC-20 private vaults, on [token transfer](https://github.com/stakewise/v3-core/blob/main/contracts/vaults/ethereum/EthPrivErc20Vault.sol#L117), check that both the sender and recipient are whitelisted. - Both ERC-20 and non-ERC-20 private vaults, on [mintOsToken](https://github.com/stakewise/v3-core/blob/main/contracts/vaults/ethereum/EthPrivVault.sol#L96), check that the caller is still whitelisted. ## Vault osToken - The [depositAndMintOsToken](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IEthVault.sol#L60) and [updateStateAndDepositAndMintOsToken](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IEthVault.sol#L75) functions have been added to all the Ethereum vault contracts. These functions can be used to batch deposit, mint `osToken`, and update the vault state in a single call. If the `osTokenShares` argument is set to `2^256 - 1`, the maximum osToken shares will be minted based on the deposit amount. - The [OsTokenConfig](https://github.com/stakewise/v3-core/blob/main/contracts/tokens/OsTokenConfig.sol) was updated: - Replaced `redeemFromLtvPercent` and `redeemToLtvPercent` variables with the [redeemer](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IOsTokenConfig.sol#L47) role that can redeem assets from the vaults where `osToken` was minted. An equal amount of `osToken` must be burned during the call. This role is managed by the DAO through the [setRedeemer](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IOsTokenConfig.sol#L60) function, which emits the [RedeemerUpdated](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IOsTokenConfig.sol#L29) event. - The DAO can set the default configuration for all vaults or override the configuration for a specific vault using the [updateConfig](https://github.com/stakewise/v3-core/blob/main/contracts/interfaces/IOsTokenConfig.sol#L67) function. By setting the `liqThresholdPercent` parameter to `2^64 - 1`, liquidations will be disabled for the vault. ## RewardSplitter - The `redeem` function was removed from the [RewardSplitter](https://github.com/stakewise/v3-core/blob/main/contracts/misc/RewardSplitter.sol) contract. - The [totalRewards](https://github.com/stakewise/v3-core/blob/main/contracts/misc/RewardSplitter.sol#L49) function was added. It returns the total amount of accumulated unclaimed rewards.