The emergencyWithdrawERC20() function is designed to prevent withdrawal of core trading tokens, but it relies on hardcoded address checks rather than the dynamic allowedSellToken mapping that controls which tokens can be traded.
Current Hardcoded Protection:
However, the contract allows the owner to dynamically add new trading tokens:
This creates an inconsistency where newly added trading tokens can still be withdrawn via the emergency function because they bypass the hardcoded checks, potentially draining tokens that users have locked in active orders.
Likelihood:
The owner expands the platform by adding new tokens via setAllowedSellToken()
to increase trading pairs and attract more users
Users create sell orders with newly added tokens, depositing significant amounts into the contract for trading
Impact:
Direct theft of user funds deposited in sell orders for non-hardcoded tokens, with no recovery mechanism
Complete breakdown of order fulfillment system as orders become permanently unfillable when underlying tokens are drained
Owner adds a new token as an allowed trading token: orderBook.setAllowedSellToken(wmaticAddress, true);
Users create sell orders with the new token, locking tokens in the contract.
Owner can withdraw all of the new token via emergency function since it's not hardcoded: orderBook.emergencyWithdrawERC20(wmaticAddress, amount, ownerWallet);
User orders become unfillable as the contract no longer holds the tokens.
The fix involves replacing the hardcoded token address checks with a dynamic check against the allowedSellToken
mapping. This creates consistency between the token management system and the emergency withdrawal protection.
The current implementation creates a dangerous disconnect where:
New tokens can be dynamically added for trading via setAllowedSellToken()
But the emergency function only protects hardcoded tokens
This leaves newly added trading tokens vulnerable to withdrawal despite having active user orders
By checking the allowedSellToken
mapping instead, the emergency function will automatically protect any token that's currently enabled for trading, regardless of when it was added. This ensures that user funds locked in orders for any allowed trading token remain secure.
The mitigation also maintains the original intent of the emergency function - to recover accidentally sent tokens that aren't part of the trading system - while preventing the withdrawal of any token that users can actively deposit through sell orders.
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.