The current implementation of randomness in the SpookySwap contract uses a pseudo-random number generator based on keccak256
and block.timestamp
, which is vulnerable to miner manipulation. This allows for the possibility of unfair outcomes in the trick-or-treat process
In the trickOrTreat
function, randomness is generated using the following code:
uint256 random = uint256(keccak256(abi.encodePacked(block.timestamp, msg.sender, nextTokenId, block.prevrandao))) % 1000 + 1;
This method of generating randomness is not secure. Miners can manipulate the block timestamp or choose whether or not to include certain transactions based on favorable outcomes, especially given the 1/1000 chance for the "trick" (double price) and "treat" (half price).
The manipulation of randomness could lead to the following:
Users obtaining an unfair advantage in the minting process, receiving a treat (half-price mint) more frequently.
Exploiting the "trick" scenario by intentionally delaying transactions or controlling the outcome, resulting in financial losses for other users and unfair pricing.
This could erode trust in the platform's fairness, particularly if malicious actors exploit these vulnerabilities.
Manual Code Review: A thorough review of the smart contract identified the use of insecure pseudo-randomness.
Solidity Security Best Practices: Cross-checked against industry standards for secure randomness.
To securely generate randomness and prevent manipulation, it is recommended to integrate Chainlink VRF. This provides a cryptographically secure and provable source of randomness.
```
}
```
It's written in the README: "We're aware of the pseudorandom nature of the current implementation. This will be replaced with Chainlink VRF in later builds." This is a known issue.
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.