The _depositToVaults function in the OperatorVCS::deposit process lacks a mechanism to prevent deposits into vaults that have been removed from Chainlink's staking contract but not yet removed from the operator strategy. Since removeVault can only be called after the unbonding period ends, the function may attempt to deposit into a removed vault, causing transaction reverts that halt the deposit process.
When a vault is removed from Chainlink's staking contract, it must also be removed from the operator strategy by calling queueVaultRemoval followed by removeVault. However, removeVault cannot be executed immediately until the unbonding period concludes. This creates a delay where the vault remains in the operator strategy but has already been marked for removal in the Chainlink staking contract. If _depositToVaults attempts to deposit into such a vault, the Chainlink contract will revert the transaction.
The _depositToVaults function handles deposits into vault groups as well as vaults that do not belong to a group. When depositing to group vaults, the function checks whether the vault has been removed:
However, when the function reaches the section where it deposits into vaults that do not yet belong to a group, it does not check if the vault has been removed:
This can lead to a scenario where, if all the group vaults are full, the contract will attempt to deposit into a removed vault, causing a revert in the Chainlink staking contract. This prevents the users from depositing in to staking pool.
Deposit could fail due to removed operator vaults
manual
Modify the _depositToVaults function to include a check that ensures a vault has not been removed before attempting to deposit into it, similar to how the function checks for group vaults.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.