# If the recipient is added to the USDC blacklist, then cancel() does not work

Stream.cancel() transfers vested USDC to recipient; a blacklisted recipient makes safeTransfer revert, blocking payer from cancelling the stream.

- Payout: Contest reward
- Severity: medium
- Program: Nounsdao
- Credited: Zarf
- Disclosed: 2022-11-23
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-11-nounsdao-judging/issues/37
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-11-nounsdao%3AM-6
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity vuln:business-logic vuln:dos

**Target:** Stream.sol payment stream contract
**Root cause:** cancel() pushes vested tokens to the recipient via safeTransfer before/while zeroing remainingBalance; if the recipient is USDC-blacklisted the transfer reverts, so cancellation cannot complete.
**Steps:**
1. Deploy/observe Stream with USDC token and a recipient
2. Recipient accrues vested balance > 0
3. Recipient gets its address blacklisted by USDC (e.g. via malicious activity)
4. Payer calls `cancel()`; `token_.safeTransfer(recipient_, recipientBalance)` reverts
5. Payer cannot cancel; future payments continue to accrue to recipient
**How found:** Code review of cancel()'s push-payment pattern combined with knowledge that USDC has a blacklist that makes transfers revert.
**Exploitation:** Malicious recipient deliberately gets blacklisted so payer's cancel() reverts, keeping the stream alive and future payments flowing to the recipient.
**Insight:** Any push-payment to an external token recipient can be griefed by token-level blocklists (USDC/USDT); prefer pull/claim patterns so admin actions like cancel() never depend on recipient transferability.