Inside:
the newly generated ERC20 token:
Omits the tokenId
in both the name and symbol, making it unclear which specific NFT within the collection is fractioned.
Uses abi.encodePacked
for string concatenation, which can lead to potential collision issues and ambiguous outputs in certain scenarios.
Although this does not directly threaten contract security, it decreases clarity for users and marketplaces that might handle multiple fractionalized NFTs from the same collection. Overlapping or similar names/symbols can cause confusion and hamper identification of the exact fractional tokens.
User Confusion: If multiple tokens from the same collection are fractionalized, each new ERC20 will have effectively the same name/symbol. It becomes difficult for users and marketplaces to distinguish one fractional token from another.
String Collision Risks: While rare in practice, using abi.encodePacked
to concatenate multiple arguments can cause edge-case collisions if certain data is combined. This is a minor concern in this context but worth noting for best practices.
The issue primarily affects token identification and user experience rather than contract security.
Include tokenId
in ERC20 Name/Symbol
For example:
This ensures each fractional token is clearly tied to a specific NFT within the collection.
Use bytes.concat
consider:
Or use abi.encode
if you plan to pass data through hashing or avoid packed encoding collisions.
By updating the function to incorporate the tokenId
and a more collision-resistant concatenation approach, you’ll improve the readability, uniqueness, and maintainability of generated fraction tokens.
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.