Trick or Treat

First Flight #27
Beginner FriendlyFoundry
100 EXP
View results
Submission Details
Severity: high
Invalid

Lack of Availability Control for Treats in SpookySwap Contract

Summary

In the SpookySwap contract, users can repeatedly buy the same treat without restrictions, as the treat remains available in the treatList mapping indefinitely. According to the contract design, users should be able to “swap ETH for Halloween treat NFTs,” suggesting that each treat may be a unique item or have a limited supply. However, the lack of availability control means that any treat can be purchased multiple times by different users, which may not align with the intended scarcity or uniqueness of certain treats. This design could lead to user confusion and diminish the value of specific treats that are expected to be exclusive.

Vulnerability Details

The SpookySwap contract defines treats in the treatList mapping and stores treat names in the treatNames array, allowing users to select a treat and swap ETH for the corresponding NFT. However, treats are not removed or disabled from these collections after a user purchases them. This absence of availability control allows treats to be repeatedly purchased, creating an inconsistency with potential expectations of treat uniqueness.

Example Scenario:

  1. Initial Setup: A user purchases a unique treat expecting it to be exclusive.

  2. Execution: Other users buy the same treat repeatedly without restriction.

  3. Outcome: The expected exclusivity of the treat is compromised, potentially reducing its perceived value.

Impact

  • Multiple Sales of Identical NFTs: The same treat can be repeatedly sold to different buyers, reducing its exclusivity.

  • Price Disparities: With multiple identical NFTs in circulation, buyers can set varying prices, leading to market confusion about the treat's true value.

  • Loss of Collectibility and Trust: Users expecting limited-edition treats may lose trust in the platform, as over-issuance diminishes perceived rarity and collectibility.

Tools Used

El Manuel

Recommendations

Add a Supply Limit: Introduce a maxSupply variable in the Treat struct to limit the number of times each treat can be purchased. Update the trickOrTreat function to track purchases and prevent exceeding the supply.

struct Treat {
string name;
uint256 cost;
string metadataURI;
++ uint256 maxSupply;
++ uint256 currentSupply;
}

Update trickOrTreat to check currentSupply against maxSupply before minting:

...
++ require(treat.currentSupply < treat.maxSupply, "Treat is no longer available");
++ treat.currentSupply += 1;
...

One-Time Purchase Option: Remove treats from the treatList after purchase if they are meant to be unique, using delete treatList[_treatName]. This ensures that once a treat is bought, it cannot be repurchased.

Updates

Appeal created

bube Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

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