# debtToMint incorrectly treats feeAdjustment decimals

Opyn CrabNetting's _debtToMint omits feeAdjustment's 18 decimals, yielding zero sqthToSell and breaking depositAuction market orders.

- Payout: Contest reward
- Severity: high
- Program: Opyn
- Credited: keccak123
- Disclosed: 2022-11-22
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2022-11-opyn-judging/issues/236
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-11-opyn%3AH-1
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:precision-loss

**Target:** CrabNetting.sol depositAuction/_debtToMint
**Root cause:** _calcFeeAdjustment returns an 18-decimal value but _debtToMint adds it to collateral without scaling, so the denominator is dominated by debt*feeAdjustment and the result truncates to 0.
**Steps:**
1. Read _calcFeeAdjustment: returns (squeethEthPrice * feeRate)/10000, 18 decimals.
2. Read _debtToMint: wSqueethToMint = (_amount * debt) / (collateral + (debt * feeAdjustment)).
3. Note numerator and denominator both ~36 decimals, so result truncates to 0.
4. Call depositAuction: sqthToSell = 0, so remainingToSell = 0 and the first buy order branch triggers with zero transfer, or auction reverts/underfills.
**How found:** Code review of decimal handling: noticed feeAdjustment is 18-decimal but used unscaled in the denominator, then traced sqthToSell into depositAuction's order loop.
**Exploitation:** No attacker action; depositAuction malfunctions for all callers, producing zero sqthToSell so market buy orders are never filled and no WETH liquidity is brought in.
**Insight:** When mixing oracle-derived fee/price values into share-mint math, verify each term's decimals against the base token; a single unscaled 18-decimal term can truncate the whole result to zero.