Non-Core Tokens Displayed Without Symbol in Order Details.
The getOrderDetailsString
function is designed to provide a human-readable summary of an order’s key data. It includes the amount of the token to sell and its symbol (e.g., 1000 wETH
). However, the function only assigns a value to the tokenSymbol
variable if the token address matches a small hardcoded set of “core” tokens: wETH
, wBTC
, or wSOL
.
For non-core tokens, tokenSymbol
remains an uninitialized empty string. As a result, when a user views the order details for non-core token orders, they will see a numeric amount but no associated token name or symbol, which can be misleading or deceptive.
This breaks expectations for users, affects UI rendering, and creates the potential for confusion or even manipulation in decentralized marketplaces where new or lesser-known tokens may be introduced dynamically.
Risk
Likelihood:
This issue occurs 100% of the time for any token not on the hardcoded list.
In a dynamic environment where users can trade many tokens, this will affect a significant number of orders.
Impact:
No direct fund loss or contract takeover is possible.
However, users can be misled into interacting with orders without clearly seeing which token is involved.
Suppose a user places an order to sell 500 units of a non-core token XYZ
(which is not wETH, wBTC, or wSOL). The returned string would look like this:
There is no indication of which token is being sold — just the number 500
, with the token symbol omitted.
A user or frontend application parsing this string would have no reliable way to determine the token being traded, potentially leading to dangerous misunderstandings.
Recommended Mitigation
Add a Fallback Token Symbol:
If a token is not recognized as a core token, display a default label like "Unknown"
or "Custom Token"
instead of leaving it blank.
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.