# USDMPegRecovery Risk of fund locked, due to discrepancy between curveLP token value against internal contract math

USDMPegRecovery tracks user deposits in storage but provides liquidity using real Curve balances, so a single swap desyncs accounting and locks withdrawals.

- Payout: Audit contest
- Severity: high
- Program: Concur Finance
- Found by: Alex the Entreprenerd
- Disclosed: 2022-05-24
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-02-concur-findings/issues/70
- Library page: https://bugbountylibrary.com/r/c4%3A2022-02-concur%3AH-05
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** USDMPegRecovery.sol deposit/withdraw/provide accounting
**Root cause:** deposit/withdraw update stored balances directly, but provide() adds liquidity based on actual Curve pool balances; after any swap the pool is imbalanced so real balances diverge from stored accounting.
**Steps:**
1. Deposit equal amounts of usdm and 3crv into USDMPegRecovery
2. Call provide() to mint Curve LP
3. Perform one swap on the Curve pool to imbalance it
4. Call withdraw() for full balance; stored balance no longer matches real balance, causing revert or wrong payout
**How found:** Code reading of deposit/withdraw vs provide: noticed provide uses real balances while storage tracks deposits, then reasoned that Curve imbalance after swaps breaks the invariant.
**Exploitation:** Not weaponized; accounting desync causes users to be unable to withdraw exact deposits, locking funds.
**Insight:** When a contract tracks user shares in storage but prices them off live AMM/pool balances, any external pool imbalance desyncs accounting; check every path that reads real vs stored balances.