# Need alternative ways for fund transfer in end() to prevent DoS

MintingHub.end() bundles multiple ERC20 transfers; a revert-on-zero or blacklisted token transfer bricks the whole call, locking challenger collateral and bidder funds.

- Payout: Contest reward
- Severity: medium
- Program: Frankencoin
- Credited: \_\_141345\_\_
- Disclosed: 2023-06-09
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-04-frankencoin-findings/issues/680
- Library page: https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AM-07
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** MintingHub.end() / Position.notifyChallengeSucceeded collateral settlement
**Root cause:** end() performs several sequential external ERC20 transfers (collateral return, bidder excess, owner excess) in one transaction; any single failing transfer (revert-on-zero, blacklist, zero-address recipient, insufficient zchf) reverts the entire settlement.
**Steps:**
1. Open multiple concurrent challenges on one position so total challengedAmount exceeds collateralBalance.
2. Let earlier end() calls drain collateral; last challenger's notifyChallengeSucceeded computes _size=colBal=0 and calls internalWithdrawCollateral(bidder, 0).
3. Collateral token reverts on zero-value transfer (e.g. LEND), so `IERC20(collateral).transfer(target, 0)` reverts.
4. Whole end() reverts, blocking returnCollateral() and bidder excess refund; funds stuck.
5. Alternatively set position owner to address(0) so `zchf.transfer(owner, ...)` reverts on recipient check.
**How found:** Code reading of end()'s sequential external transfers and notifyChallengeSucceeded's redimension logic; noticed concurrent challenges can reduce _size to 0, then cross-referenced weird-ERC20 revert-on-zero behavior and ERC20 zero-address recipient check.
**Exploitation:** Attacker (or natural concurrent-challenge state) forces a zero-amount or invalid-recipient transfer inside end(), causing the settlement transaction to revert and permanently/temporarily locking challenger collateral and bidder funds; no direct theft, griefing/DoS only.
**Insight:** When a settlement function batches multiple token transfers, enumerate every transfer's edge cases (zero amount, zero address, blacklisted recipient, insufficient balance) as independent revert vectors — any one bricks the whole batch; prefer pull-payment accounting.