# Variable opening fee will always be wrongly computed if collateral is not a stablecoin

Hardcoded min/max mint fee thresholds assume USDO/USDC rate; for non-stable collateral the variable opening fee always applies max fee, and setter enforces wrong ordering preventing fix.

- Payout: Contest reward
- Severity: medium
- Program: Tapioca
- Credited: 0xadrii
- Disclosed: 2024-02-14
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-02-tapioca-judging/issues/119
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AM-24
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:fee-bypass

**Target:** BigBang CDP market lending contract (BBLendingCommon.sol, BigBang.sol)
**Root cause:** minMintFeeStart/maxMintFeeStart hardcoded for USDO/USDC rate; _computeVariableOpeningFee assumes maxMintFeeStart < minMintFeeStart but setMinAndMaxMintRange enforces _min < _max, making correct update impossible.
**Steps:**
1. Deploy BigBang market with non-stable collateral (e.g. ETH).
2. Observe _initCoreStorage sets maxMintFeeStart=0.975e18, minMintFeeStart=1e18.
3. Borrow: _computeVariableOpeningFee queries assetOracle.get(oracleData) returning ETH/USD rate ~0.00025e18.
4. Since _exchangeRate <= maxMintFeeStart, maxMintFee is always applied.
5. Attempt fix via setMinAndMaxMintRange: `if (_min >= _max) revert NotValid();` prevents setting maxMintFeeStart > minMintFeeStart as required by the fee formula.
**How found:** Code reading of _computeVariableOpeningFee and _initCoreStorage; noticed hardcoded thresholds only coherent for stablecoin exchange rates and that setter's ordering check contradicts the formula's assumption.
**Insight:** When a fee curve uses two threshold constants, verify the setter's ordering constraint matches the formula's assumed ordering; hardcoded oracle-rate thresholds break for assets with different decimal magnitude.