Payable multicall via delegatecall: msg.value persists per iteration and reverts non-payable targets — a drain vector

Design under examination: a payable multicall(bytes[] calldata) that loops address(this).delegatecall(_data[n]). Sending value and mixing payable and non-payable targets reverts.

Mechanism: delegatecall preserves msg.value for the whole call frame — it is not consumed or decremented by earlier iterations. Solidity injects a callvalue() != 0 → revert guard at the top of every non-payable function, so any non-payable entry reached inside a value-bearing multicall reverts on that guard. There is no way to zero msg.value within the same frame; the only escape is to cross a real external-call boundary (call out to another contract, or a payable function that calls back in), which is exactly the pivot an attacker uses: a payable function that hands control to an arbitrary address (say takeSomeTokens calling IERC20.transferFrom) lets a malicious token re-enter the non-payable function on your behalf.

The security consequence is the more important half. Because msg.value is visible in full to every iteration, a contract that checks require(msg.value == PRICE) inside a function reachable from a delegatecall-multicall can be credited N times for one payment — a straightforward drain of the contract's balance. Treat this as a rule: never read msg.value in any function reachable from a multicall/delegatecall loop; instead pass explicit per-call amounts and assert that they sum to msg.value, tracking the running total across iterations.

Related known vulnerability class: do not combine ERC-2771 meta-transactions (ERC2771Context) with multicall — the combination allows arbitrary _msgSender() spoofing (OpenZeppelin public disclosure, 2023). If you need both, keep them on separate entry points.

Source: adapted from a Stack Exchange answer by 0xSanson (question by zkYan), https://ethereum.stackexchange.com/questions/162361/payable-multi-delegatecall — CC BY-SA 4.0