whoismxuse - BaseTokenID is wrongfully set to reservedUntilTokenId

[sherlock-admin2]

whoismxuse

medium

BaseTokenID is wrongfully set to reservedUntilTokenId

Summary

In Token.sol function _addFounders contains line of code uint256 baseTokenId = reservedUntilTokenId; , however if we delve deeper into what this line of code does we will see problems arise.

Vulnerability Detail

We know that baseTokenId should be a number between 0 and 100 & the tokens for the founders should be applied after the reserve. However if we have reservedUntilTokenId is greater than 100 which is not rare (in a case where there are more than 100 reserved tokens for minters). This is where the problem starts.

Impact

for (uint256 j; j < founderPct; ++j) {

// Get the available token id

baseTokenId = _getNextTokenId(baseTokenId);

  

// Store the founder as the recipient

tokenRecipient[baseTokenId] = newFounder;

  

emit MintScheduled(baseTokenId, founderId, newFounder);

the code will wrongfully start at the wrong baseTokenId and will start counting from there (instead of storing baseTokenId starting from 0) also it will emit MintScheduled which will take the wrong parameters considering it takes baseTokenId and Newfounder which has the incorrect baseTokenId stored.

This will cause the MintScheduled to have a different BaseTokenIdthan the MintUnscheduled, obviously we want MintScheduled to be the same as MintUnscheduled (also confirmed this on discord with the devs).

We also do not want the BaseTokenIdto ever exceed 100, but since the first BaseTokenId goes into the loop and gets stored in MintScheduled before going through the % 100 this means it will take the same number as reservedUntilTokenId

Code Snippet

https://github.com/ourzora/nouns-protocol/blob/e81cfce40e09b8abd9222443373ac747598bac4b/src/token/Token.sol#L161C9

Tool used

Manual Review

Recommendation

// Used to store the base token id the founder will recieve
uint256 baseTokenId = 0;

Duplicate of #42