The normal, expected behavior of SantasList._mintAndIncrement() is that it should increment the state variable s_tokenCounter by 1.
Right now, _mintAndIncrement() does not increment the state variable s_tokenCounter for the contract, but rather only increments the value of s_tokenCounter within the parameter of _safeMint(), meaning that s_tokenCounter remains at the same value it was before _mintAndIncrement() was called.
Likelihood:
The likelyhood that _mintAndIncrement() will not increment s_tokenCounter is always. It is 100%.
s_tokenCounter will always remain the same value it was before calling _mintAndIncrement() as after calling it.
Impact:
The impact is that s_tokenCounter will not be incremented, and it will remain at its current value.
By not incrementing s_tokenCounter, it means that all NFTs will be given the same token id.
Below we show that user calls buyPresent(), which calls _mintAndIncrement(), but we see that santasList.s_tokenCounter is not incremented, and instead remains the same as before.
First _mintAndIncrement() should properly increment s_tokenCounter with s_tokenCounter++; and then it should call _safeMint() using the updated s_tokenCounter. Additionally, buyPresent() calls _mintAndIncrement() in such a way that it presupposes that msg.sender is the recipient of the NFT, because _mintAndIncrement() does not take a recipient parameter. This dilemma can be fixed with a new function or by modifying _mintAndIncrement() to take a recipient parameter that is then passed to _safeMint().
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.