# getPrice salesOption 2 can round down to the lower barrier, skipping the last time period

NextGen MinterContract getPrice salesOption 2 integer division rounds down, skipping the final price step and jumping straight to the end price.

- Payout: Contest reward
- Severity: medium
- Program: NextGen
- Credited: 0x3b
- Disclosed: 2024-01-08
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-10-nextgen-findings/issues/271
- Library page: https://bugbountylibrary.com/r/c4%3A2023-10-nextgen%3AM-09
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:business-logic vuln:precision-loss

**Target:** MinterContract.getPrice pricing logic (Solidity)
**Root cause:** The else-if condition divides (mintCost-endCost)/rate using integer division, truncating the quotient so the comparison `> tDiff` fails one period early and returns the final end price prematurely.
**Steps:**
1. Set collectionMintCost=0.49 ETH, collectionEndMintCost=0.1 ETH, rate=0.1 ETH/hour, timePeriod=3600s.
2. At tDiff=10800s (hour 3), compute (0.49-0.1)/0.1 = 3.9 truncated to 3.
3. Condition `3 > 3` is false, so else branch returns collectionEndMintCost=0.1 ETH.
4. Observe price sequence 0.49, 0.39, 0.29, 0.10 — the 0.19 step is skipped.
5. Run provided forge test to confirm logs.
**How found:** Warden reasoned about integer division truncation in the price-decrease condition and constructed a numeric example showing the crossover period is skipped, confirmed via forge PoC.
**Insight:** When a linear-decrease formula compares a truncated quotient against elapsed time, test the exact boundary where numerator/denominator truncates — the last period is silently skipped; check bot-reported precision issues for exploitable pricing impact.