The constructor in the `WToken` contract assigns the same value to both the token name and the token symbol. While this might not inherently lead to a vulnerability, it can create issues in certain scenarios where there is a need to differentiate between the token's "name" and "symbol". In particular, a poorly designed naming convention can lead to confusion, inefficiencies in tracking, and potential errors in systems interacting with the token, such as wallets or exchanges.
The constructor code provided is:
In the constructor, both the name
and symbol
of the ERC20 token are being set to the same value, passed as symbol_
.
The token’s name is typically intended to be a human-readable name (e.g., "Wrapped Bitcoin"), whereas the symbol is a short code (e.g., "WBTC").
Setting both the name and symbol to the same value may lead to confusion and problems when interacting with wallets, exchanges, or dApps that expect these to be different.
While this isn't necessarily a severe security vulnerability (e.g., no immediate risks like reentrancy or overflow), it could cause confusion or errors in external systems such as:
Wallets: Wallet interfaces that expect name and symbol to differ might display confusing information.
Exchanges: When interacting with token listings or during the creation of token pairs, exchanges might face difficulties in properly labeling the token.
User experience: End users may be confused about the difference between the name and symbol of the token.
In the worst case, it could result in a poor user experience, as some wallets, apps, or services may expect a different name and symbol to appear.
Manual review.
Assign a different value to name_
and symbol_
parameters in the constructor to provide clarity and avoid potential conflicts with other services or systems interacting with the token.
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.