# BigBang::repay and Singularity::repay spend more than allowed amount

BigBang/Singularity repay checks allowance against borrow part but withdraws the larger elastic amount, letting a spender pull more than approved.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: zzzitron
- Disclosed: 2023-11-16
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-07-tapioca-findings/issues/918
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-44
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** BigBang and Singularity lending markets (repay)
**Root cause:** repay validates allowance using `part` (borrow share) but `_repay` withdraws the corresponding `elastic` amount, which exceeds `part` whenever totalBorrow.elastic > totalBorrow.base due to accrued interest.
**Steps:**
1. eoa1 calls `approveBorrow(deployer, 1e18)` on wethBigBangMarket
2. advance time 10 days so totalBorrow.elastic > totalBorrow.base
3. deployer calls `repay(eoa1, deployer, false, 1e18)`
4. observe yieldBox balance of eoa1 drops by 1000136987569097987 > 1e18
**How found:** Code reading: noticed repay's allowance modifier uses `part` while `_repay` computes `amount` from totalBorrow.sub(part,true) and withdraws `amount`; hypothesized elastic/base divergence grows with accrued interest, confirmed via Hardhat PoC.
**Exploitation:** A spender with a limited borrow allowance calls repay on behalf of the victim; the allowance check passes on `part` but yieldBox.withdraw pulls the larger elastic amount from the victim, spending beyond the approved maximum.
**Insight:** When an allowance is checked on a share/part unit but the transfer uses a converted asset amount, any exchange-rate drift (accrued interest) breaks the cap; audit every allowance check against the unit actually transferred.