Trick or Treat
First Flight #27
Beginner FriendlyFoundry
100 EXP
View results
Previous Next
Submission Details
Severity: low
Invalid

Ambiguity in shared Metadata usage, NFT treats are expected to be unique in design `ERC721`.

edmpulasky

Summary

Without no specification if sharing metadata is intended to do so, SpookySwap:trickOrTreat ties a Treat along with tokenId then attaches a metadata as tokenURI, each call to trickOrTreat with the same _name will use same Treat to tie another tokenId which contradicts the expected uniqueness of NFT's.

Vulnerability Details

function mintTreat(address recipient, Treat memory treat) internal {
uint256 tokenId = nextTokenId;
_mint(recipient, tokenId);
@> _setTokenURI(tokenId, treat.metadataURI);
nextTokenId += 1;
​
emit Swapped(recipient, treat.name, tokenId);
}

Impact

Although it does not affect protocol funds, it assigns same metadata to multiple tokenIds, leading to user confusion, as buyers expect to buy unique Treats, as they aren't unique they are devaluated.

Tools Used

  • Manual Review

  • Foundry testing tool

function testSameMetadaForMultipleTokenIds() public {
protocol.addTreat("candy", 0.1 ether, "uri1");
uint256 tokenId1 = protocol.nextTokenId();
vm.prank(user);
protocol.trickOrTreat{ value: 0.2 ether }("candy");
​
uint256 tokenId2 = protocol.nextTokenId();
vm.prank(user2);
protocol.trickOrTreat{ value: 0.2 ether }("candy");
​
string memory metadata1 = protocol.tokenURI(tokenId1);
string memory metadata2 = protocol.tokenURI(tokenId2);
​
assert(Strings.equal(metadata1, metadata2));
}

Recommendations

  • Enforce treat minting, is assiged with unique metadata

Updates

Appeal created

bube Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

[invalid] Duplicate treats

The function `addTreat` is called by the owner. The owner is trusted. There will be no duplicates.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.