Closed sherlock-admin4 closed 5 months ago
Invalid based on sherlock rules
- Use of call vs transfer will be considered as a protocol design choice if there is no good reason why the call may consume more than 2300 gas without opcode repricings.
The protocol team fixed this issue in the following PRs/commits: https://github.com/equilibria-xyz/perennial-v2/pull/295
The Lead Senior Watson signed off on the fix.
bigbick123456789000
medium
Use of
call()
Instead oftransfer()
inMultiInvoker
'sinvoke
FunctionSummary
The
MultiInvoker
contract employs thetransfer()
function when transferring Ether to recipients within itsinvoke()
function. However, this approach can be problematic when the recipient is a smart contract with specific requirements for ETH transfers. To address this, the contract should utilizecall()
instead oftransfer()
to ensure compatibility with a wider range of smart contracts.Vulnerability Detail
The
invoke()
function in theMultiInvoker
contract aims to execute a series of actions defined in Invocation structs. These actions can involve interacting with other contracts, including transferring Ether. Currently, the function employstransfer()
to send Ether back to the caller after executing the invocations. However,transfer()
has limitations when transferring ETH to smart contracts:invoke()
function:Impact
The use of
transfer()
in theinvoke()
function can lead to failed ETH transfers, disrupting the intended functionality of the contract. This could result in funds being locked within the contract or transactions failing unexpectedly.Code Snippet
MultiInvoker.sol#L163
Tool used
Manual Review
Recommendation
The
MultiInvoker
contract should replacetransfer()
withcall()
when transferring Ether back to the caller.