# TimeswapPair.sol#mint() Malicious user/attacker can mint new liquidity with an extremely small amount of yIncrease and malfunction the pair with the maturity

Attacker mints liquidity with tiny yIncrease, setting state.y to 1 wei and bricking the pair's math for a chosen maturity.

- Payout: Audit contest
- Severity: medium
- Program: Timeswap
- Found by: WatchPug
- Disclosed: 2022-03-03
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-01-timeswap-findings/issues/165
- Library page: https://bugbountylibrary.com/r/c4%3A2022-01-timeswap%3AM-06
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** TimeswapPair.sol mint() / MintMath
**Root cause:** mint() lets caller specify arbitrary yIncrease with no minimum; state.y is expected to be large (2**32 base), so setting it to 1 wei makes BorrowMath/MintMath unable to meaningfully update state.y.
**Steps:**
1. Call `mint()` on a fresh pair with `yIncrease = 1` wei to set `state.y` to a tiny value
2. Observe subsequent `borrow`/`lend`/`mint` operations fail to meaningfully change `state.y` due to 2**32 scaling in BorrowMath
3. Pair for that maturity is effectively bricked and must be abandoned
**How found:** Code review of MintMath/BorrowMath: noticed state.y is scaled at 2**32 and mint() accepts arbitrary yIncrease without a minimum, so a dust mint collapses state.y and breaks the math.
**Exploitation:** Frontrun a victim's or platform's newLiquidity() call for a desired maturity (e.g. end of quarter/year) by minting with 1 wei yIncrease first, griefing the pair so it malfunctions and cannot be used.
**Insight:** When a protocol scales a state variable by a large fixed factor (2**32), check whether any entry point lets an attacker initialize it to a tiny value; a dust deposit can permanently break the invariant for that pool/maturity.