# Minting and redeeming will break for fully minted tiers with reserveRate != 0 and reserveRate/MaxReserveRate tokens burned

Juicebox tiered NFT store underflows when computing outstanding reserve tokens after burns, permanently reverting all minting and redeeming.

- Payout: Contest reward
- Severity: high
- Program: Juicebox
- Credited: 0x52
- Disclosed: 2023-01-09
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-10-juicebox-findings/issues/113
- Library page: https://bugbountylibrary.com/r/c4%3A2022-10-juicebox%3AH-02
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** JBTiered721DelegateStore reserve token accounting
**Root cause:** _numberOfReservedTokensOutstandingFor subtracts _reserveTokensMinted from a recomputed _numberReservedTokensMintable without checking the former is smaller; burning tokens lowers the mintable count below already-minted reserves, causing underflow revert.
**Steps:**
1. Configure a tier with reserveRate=100 (1/100) and initialQuantity=10000; fully mint so _reserveTokensMinted=100, remainingQuantity=0.
2. Burn 100 tokens so remainingQuantity=100.
3. Call any mint or redeem; _numberOfNonReservesMinted = 10000-100-100 = 9800.
4. _numerator = 9800*100 = 980000; _numberReservedTokensMintable = 980000/10000 = 98.
5. Return `98 - 100` underflows and reverts, breaking all mint/redeem paths.
**How found:** Code review of the reserve-token math: noticed the return statement lacks a guard ensuring _numberReservedTokensMintable >= _reserveTokensMinted, then constructed a fully-minted tier with burns to force the underflow.
**Insight:** In reserve/royalty accounting, recomputing 'mintable' from remaining supply while separately tracking 'already minted' diverges once burns occur; check subtraction operands and consider tracking burned reserves explicitly.