# MuteBond is susceptible to DOS

MuteBond deposit reverts permanently once maxDeposit() drops below 52, because dMute.timeToTokens returns 0 and LockTo requires tokens_to_mint > 0.

- Payout: Contest reward
- Severity: medium
- Program: Mute.io
- Credited: evan
- Disclosed: 2023-04-27
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-03-mute-findings/issues/22
- Library page: https://bugbountylibrary.com/r/c4%3A2023-03-mute%3AM-05
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** MuteBond / dMute bond deposit contracts
**Root cause:** timeToTokens truncates base_tokens to 0 when _amount * lock_time / 52 weeks < 1 (e.g. amount < 52 with 1-week lock), and LockTo requires tokens_to_mint > 0, so deposit reverts. maxDeposit() shrinks as bond price rises, eventually falling below 52.
**Steps:**
1. Set startPrice=1e18, maxPrice=2e18, maxPayout=100e18.
2. Call deposit(99998511926905849653, buyer1, false) to push maxDeposit() below 52.
3. Subsequent deposit(1, ..., false/true) and deposit(1e18, ..., false/true) all revert because payout < 52 makes timeToTokens return 0.
**How found:** Code reading of timeToTokens rounding and LockTo's require(tokens_to_mint > 0), then noticing MuteBond.deposit passes payout (bounded by maxDeposit()) into LockTo; hypothesized maxDeposit() could fall below 52 and confirmed with a Hardhat test.
**Exploitation:** Attacker buys a bond sized to drive maxDeposit() below 52; every later deposit reverts since payout <= maxDeposit() < 52 yields zero minted tokens and LockTo reverts.
**Insight:** When a downstream mint/lock function requires a nonzero output, check whether upstream amount bounds (like maxDeposit) can shrink below the rounding threshold that makes the output zero — integer truncation plus a >0 require is a DoS primitive.