# Denial of service of Liquiditypool QueuedWithdrawals

Attacker queues a zero-amount withdrawal to the sUSD proxy address, which always reverts on transfer, permanently blocking the withdrawal queue and trapping later users' liquidity tokens.

- Payout: Contest reward
- Severity: high
- Program: Polynomial Protocol
- Credited: Lirios
- Disclosed: 2023-08-01
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-03-polynomial-findings/issues/103
- Library page: https://bugbountylibrary.com/r/c4%3A2023-03-polynomial%3AH-12
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** LiquidityPool withdrawal queue (queueWithdraw/processWithdraws)
**Root cause:** processWithdraws transfers sUSD to an arbitrary user-supplied receiver; sUSD's _internalTransfer reverts for the proxy/implementation addresses, and a reverting entry never advances queuedWithdrawalHead, halting the whole queue.
**Steps:**
1. Call `pool.queueWithdraw(0, 0xDfA2d3a0d32F870D87f8A0d7AA6b9CdEB7bc5AdB)` (sUSD MultiCollateralSynth) with amount 0, callable by anyone.
2. Wait past minWithdrawDelay; `processWithdraws()` reverts on the sUSD transfer to the proxy address.
3. queuedWithdrawalHead never increments, so all subsequent queued withdrawals are permanently unprocessable.
4. Later users' liquidityTokens are burned with no sUSD received.
**How found:** Read the sUSD token implementation and noticed _internalTransfer requires to != address(this) && to != address(proxy); combined with the queue's head-pointer design where a reverting entry blocks all processing.
**Exploitation:** Attacker submits a zero-value queueWithdraw naming the sUSD proxy/implementation as receiver; the queue head is stuck at the reverting entry, blocking all later withdrawals and stranding their burned liquidity tokens. Can be timed to frontrun a large withdrawal.
**Insight:** When a queue processes entries by advancing a head pointer, any entry whose external transfer can be forced to revert (e.g. token blacklists or self/proxy-address guards) becomes a permanent DoS; check token-specific transfer guards against user-controlled receiver fields.