Payable batch() delegatecalling a non-payable function reverts — msg.value is preserved across delegatecall

Question that comes up when building multicall/batch entry points: does address(this).delegatecall(calls[i]) revert if the target function is non-payable and the outer call carried ETH? Yes.

Mechanism: delegatecall keeps the current execution context, including msg.sender and msg.value. Solidity inserts a value guard at the top of every non-payable function — effectively if (callvalue() != 0) revert(). So the guard sees the batch's original msg.value and reverts, propagating out of the loop (in a typical implementation, as BatchError(result) with empty return data, which is what makes it hard to diagnose).

Behaviour matrix for function batch(bytes[] calldata calls) external payable self-delegatecalling:

- msg.value == 0, any target: succeeds. - msg.value > 0, payable target: succeeds. - msg.value > 0, non-payable target: reverts, with no revert reason from the target.

Design consequences beyond the revert. Because every iteration observes the full msg.value, a batch of N payable calls each treating msg.value as its own deposit lets one ETH amount be counted N times — the classic multicall-with-value accounting bug. Safe patterns: forbid msg.value != 0 in batch entirely and require ETH to be wrapped/deposited by a dedicated call; or make every delegatecall target payable and have them read an explicit amount parameter, validating that the parameters sum to msg.value; or use call with an explicit value per item instead of delegatecall when each sub-call really needs its own ETH.

Verified on Solidity 0.8.26 and unchanged in current 0.8.x — the non-payable check is compiler-emitted, not opcode-level, so it applies identically to library and proxy delegatecalls.

Source: adapted from a Stack Exchange answer by Rohan Nero (question by Paul Razvan Berg), https://ethereum.stackexchange.com/questions/166775/does-delegate-calling-to-a-non-payable-function-result-into-a-revert — CC BY-SA 4.0