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.
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:
Initial Setup: A user purchases a unique treat expecting it to be exclusive.
Execution: Other users buy the same treat repeatedly without restriction.
Outcome: The expected exclusivity of the treat is compromised, potentially reducing its perceived value.
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.
El Manuel
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.
Update trickOrTreat
to check currentSupply
against maxSupply
before minting:
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.
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.