How Delegatecall Batching Reused ETH Payments in a DeFi Auction
Summary
This incident report explains how a batch-call library combined with an auction contract created a payment vulnerability. Delegatecall preserved the caller and the original payment value across batched calls, so a user could invoke the ETH commitment function repeatedly while relying on the same payment. The author also found that the Dutch auction’s refund logic could return ETH sent beyond its hard cap, increasing the funds at risk.
The team verified the flaw with a proof of concept, coordinated disclosure, and chose an administrator-led rescue that bought the remaining allocation and finalized the auction. For a separate batch auction, the team explored using a live points-list hook to detect commitments exceeding the contract’s ETH balance. The account highlights that individually sound components can interact unsafely, and that payment checks using a persistent transaction value need careful review in loops and batched execution. Its findings concern specific Solidity contracts and auction logic, not all batch-call systems.
Key ideas
- Delegatecall preserves the original caller and payment value across batched function calls.
- Repeated ETH commitment calls can reuse one transaction’s payment if contract logic only checks the supplied value.
- Refund behavior beyond an auction hard cap can turn a bidding flaw into a way to withdraw contract funds.
- Composability requires reviewing how components interact, even when each appears safe in isolation.
- Coordinated disclosure and an administrator-led auction finalization were used to secure the funds.
Tags
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.