Closed adu-web3 closed 2 months ago
The changes introduce enhanced security measures in the LSTRestakingController
contract to prevent unauthorized withdrawals by enforcing stricter checks on the token
parameter. Additionally, the test suite is expanded with a new contract for validating withdrawal scenarios, ensuring robust handling of edge cases and adherence to naming conventions.
File | Change Summary |
---|---|
src/core/LSTRestakingController.sol |
Added logic to prevent VIRTUAL_STAKED_ETH_ADDRESS from being used if the vault can be retrieved, enhancing security against unauthorized withdrawals. |
src/core/Bootstrap.sol |
Introduced a conditional check to prevent vault deployment for VIRTUAL_STAKED_ETH_ADDRESS , refining token-specific handling. |
src/core/ClientGatewayLzReceiver.sol |
Added comments clarifying that vaults should not be deployed for VIRTUAL_STAKED_ETH_ADDRESS , improving code documentation. |
src/libraries/Errors.sol |
Added a new error declaration to prohibit vault deployment for VIRTUAL_STAKED_ETH_ADDRESS , enhancing error handling. |
src/storage/BootstrapStorage.sol |
Introduced a constant for VIRTUAL_STAKED_ETH_ADDRESS and added validation in _deployVault to prevent vault deployment for this address, improving control flow and error handling. |
src/storage/ClientChainGatewayStorage.sol |
Removed the constant for VIRTUAL_STAKED_ETH_ADDRESS , indicating a shift in how staked ETH is managed. |
test/foundry/unit/ClientChainGateway.t.sol |
Renamed withdrawNonBeaconChainETHFromCapsule to WithdrawNonBeaconChainETHFromCapsule for consistency; introduced WithdrawalPrincipalFromExocore contract with tests for various withdrawal scenarios, enhancing testing capabilities. |
test/foundry/unit/Bootstrap.t.sol |
Added a constant for VIRTUAL_STAKED_ETH_ADDRESS and a new test function to verify that a vault is not deployed for this address, ensuring correct handling of the virtual staked ETH scenario. |
Objective | Addressed | Explanation |
---|---|---|
Prevent bypassing of withdrawal checks (#84) | ✅ |
🐰 Hopping through the code, what a sight to see,
New checks and balances, as safe as can be!
With names that shine bright, and tests that are keen,
Our staking's now stronger, a well-oiled machine!
So let’s cheer for the changes, with a joyful little dance,
For security’s a treasure, and we’ve taken a chance! 🎉
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
in this new commit, we forbid deploying vault for VIRTUAL_STAKED_ETH_ADDRESS
, so that whether for Bootstrap or ClientChainGateway, there is no possibility that a vault is deployed for VIRTUAL_STAKED_ETH_ADDRESS
.
We should forbid deploying vault for VIRTUAL_STAKED_ETH_ADDRESS
because this could lead to bypassing the native restaking withdrawal checks
Description
closes: #84
the solution is simple, before sending the withdrawal request to Exocore in
LSTRestakingController.withdrawPrincipalFromExocore
, we try to get corresponding vault for the specified token. If we could get the vault, the token cannot be VIRTUAL_STAKED_ETH_ADDRESS.Simply checking that the token being not equal to VIRTUAL_STAKED_ETH_ADDRESS is also a good approach, but
_getVault
could guarantee not only the token is LST token but also the vault existsSummary by CodeRabbit
Summary by CodeRabbit
New Features
Bug Fixes
Documentation