transfer(), failing to detect tokens that signal transfer failure by returning false instead of reverting. Because the function does not verify success, it emits a withdrawal event even when no tokens were transferred. This misleads users and off-chain systems, resulting in incorrect assumptions and inaccurate accounting.The contract should only emit a withdrawal event after a successful ERC20 token transfer.
The transfer operation should revert or fail cleanly when the underlying token does not execute the transfer correctly.
The function calls transfer() without checking its boolean return value, allowing silent failures for tokens that return false instead of reverting.
As a result, the withdrawal event is emitted even when no tokens were transferred, creating misleading signals for users, bots, and off-chain systems.
Likelihood:
Occurs whenever interacting with ERC20 tokens or non ERC20 that do not revert on failure but instead return false.
Occurs when balance is insufficient, when transfers are blocked by token logic, or when the token implements alternative failure semantics.
Impact:
Events indicate successful withdrawals despite failed transfers.
Off-chain systems relying on event logs become inconsistent with true on-chain balances.
Operators may believe tokens have been withdrawn when they have not, potentially enabling accounting discrepancies or operational mistakes.
For this PoC to succedd and work as intended you have to deploy a contract which return a bool value upon transfer
Just replace the existing code in withdrawToken with the code given below
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.