Last-second minter would overpay mint price if salesOption == 2 #1622
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
duplicate-1275
satisfactory
satisfies C4 submission criteria; eligible for awards
Lines of code
https://github.com/code-423n4/2023-10-nextgen/blob/main/smart-contracts/MinterContract.sol#L540
Vulnerability details
NextGenMinterContract#getPrice
returns the price for minting a new token. If the collection hassalesOption
with value 2 and the current timestamp is betweenallowlistStartTime
andpublicEndTime
, this function would calculate the mint price between values ofcollectionMintCost
andcollectionEndMintCost
. Price is changing consistently with the growingblock.timestamp
value:Minting functions in
MinterContract
allow minting tokens whenblock.timestamp == publicEndTime
:At the same time
getPrice
function returns thecollectionMintCost
price in caseblock.timestamp
is equal topublicEndTime
. This creates a scenario where minting at thepublicEndTime - 1
timestamp is more cost-effective than minting at thepublicEndTime
timestamp. This discrepancy arises from the accurate price drop in the first case contrasted with the wrongly returnedcollectionMintCost
value in the second case.Impact
Last-second minter would overpay the mint price if the case of the collection with
salesOption
== 2.Proof of Concept
The next foundry test shows how last-second minter is overpaid compared to the minter from the previous second:
Recommended Mitigation Steps
Consider updating the next line in
MinterContract.sol
:Assessed type
Math
The text was updated successfully, but these errors were encountered: