# TimeswapPair.sol#borrow() Improper implementation allows attacker to increase pool.state.z to a large value

TimeswapPair.borrow() lets attacker inflate pool.state.z with dust xDecrease, then lend and burn insurance tokens to drain collateral from defaulted loans.

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

**Target:** TimeswapPair.sol borrow() and BorrowMath.getCollateral()
**Root cause:** borrow() accepts user-supplied zIncrease and adds it to pool.state.z, but collateral is computed from zIncrease and xDecrease; a dust xDecrease makes collateral tiny while z inflates massively.
**Steps:**
1. Near maturity, call `borrow(maturity, assetTo, dueTo, xDecrease=1, yIncrease, zIncrease=large, data)` with dust xDecrease and huge zIncrease; collateral required stays small.
2. Call `pay()` to repay the dust loan and recover the collateral.
3. Call `lend()` a regular amount of state.x to receive a large amount of insurance tokens.
4. Call `burn()` the insurance tokens to claim a large portion of collateral from defaulted loans.
**How found:** Code review of borrow() noticed zIncrease is user input added to state.z while collateral uses xDecrease and zIncrease; realized dust xDecrease keeps collateral small despite huge zIncrease.
**Exploitation:** Attacker inflates pool.state.z via borrow() with 1 wei xDecrease, repays the dust loan to recover collateral, then lends to mint inflated insurance tokens and burns them to extract collateral backing defaulted loans.
**Escalation:** Chained borrow() state manipulation with lend()/burn() insurance token mechanics to drain pool collateral.
**Insight:** When a state variable is user-supplied but only partially constrained by a computed cost, check whether a dust input on another parameter lets you inflate it cheaply; then trace how that inflated state affects share/insurance token minting.