You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description: Description
The redeemAtom function in the EthMultiVault contract attempts to transfer ETH directly to the receiver. If this transfer fails, the function simply reverts instead of attempting a fallback method using WETH. This approach can lead to unnecessary transaction failures and a poor user experience, especially when interacting with contracts that can't receive ETH directly but can handle WETH.
Attack Scenario
While not a direct security vulnerability, this issue can lead to the following problems:
A user attempts to redeem their shares to a contract address that doesn't have a payable fallback function but can handle WETH.
The ETH transfer fails, causing the entire transaction to revert.
The user is unable to redeem their shares, despite the receiving contract being capable of handling the assets in WETH form.
This limits the contract's interoperability with other DeFi protocols and smart contracts.
function redeemAtom(uint256shares, addressreceiver, uint256id) external nonReentrant returns (uint256) {
if (id ==0|| id > count) {
revert Errors.MultiVault_VaultDoesNotExist();
}
if (isTripleId(id)) {
revert Errors.MultiVault_VaultNotAtom();
}
(uint256assets, uint256protocolFee) =_redeem(id, msg.sender, shares);
// Try to transfer ETH first
(boolsuccess,) =payable(receiver).call{value: assets}("");
if (!success) {
// If ETH transfer fails, fallback to WETH
WETH.deposit{value: assets}();
require(WETH.transfer(receiver, assets), "WETH transfer failed");
}
_transferFeesToProtocolVault(protocolFee);
return assets;
}
The text was updated successfully, but these errors were encountered:
The report suggests adding a WETH fallback mechanism in the redeemAtom function to handle failed ETH transfers.
Label:invalid
Comment:
We designed the contract to only handle ETH in V1. The suggested WETH fallback is more gas-intensive and unnecessary as the number of users redeeming shares to a contract without a payable fallback or receive function is negligible. Moreover, the lack of this fix can be considered a security measure, preventing potential loss of funds if the receiver address cannot handle ETH.
Comment on the issue:
We designed the contract to handle only ETH in V1, making the suggested WETH fallback unnecessary and more gas-intensive. The current implementation prevents potential loss of funds, making this suggestion invalid.
Github username: --
Twitter username: --
Submission hash (on-chain): 0xfe48c86ee5fde1eaae0770dab56021baee6c579c2aa94c61a309134d82982c86
Severity: medium
Description:
Description
The
redeemAtom
function in the EthMultiVault contract attempts to transfer ETH directly to the receiver. If this transfer fails, the function simply reverts instead of attempting a fallback method using WETH. This approach can lead to unnecessary transaction failures and a poor user experience, especially when interacting with contracts that can't receive ETH directly but can handle WETH.Attack Scenario
While not a direct security vulnerability, this issue can lead to the following problems:
Attachments
Proof of Concept (PoC) File
Intuition-0x538dbadc50cc87b281cd655f1edbc6ebda02a66a/src/EthMultiVault.sol
Lines 726 to 729 in b2e422f
Revised Code File (Optional)
The text was updated successfully, but these errors were encountered: