# addCredit / increaseCredit cannot be called by lender first when token is ETH

mutualConsent modifier on payable addCredit/increaseCredit lets first caller's ETH be lost or blocks borrower consent, breaking ETH-funded credit lines.

- Payout: Contest reward
- Severity: high
- Program: Debt DAO
- Credited: Lambda
- Disclosed: 2023-02-07
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-11-debtdao-findings/issues/125
- Library page: https://bugbountylibrary.com/r/c4%3A2022-11-debtdao%3AH-03
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity vuln:business-logic

**Target:** LineOfCredit.sol addCredit/increaseCredit payable functions
**Root cause:** The mutualConsent modifier returns false and registers consent instead of reverting on the first call, so ETH sent with that first call is trapped and the second party cannot complete consent without also sending ETH.
**Steps:**
1. Lender Alice calls `LineOfCredit.addCredit(...)` with 1 ETH before borrower consent; modifier registers consent hash and returns false, body skipped, ETH stays in contract.
2. Borrower Bob calls same `addCredit` to grant consent but sends no ETH; payable check/body reverts, so consent cannot complete.
3. Result: lender's ETH lost and credit line cannot be opened via lender-first flow.
**How found:** Code reading of the mutualConsent modifier combined with the payable modifier on addCredit/increaseCredit; noticed the modifier does not revert on first call and ETH is accepted regardless.
**Insight:** When auditing two-party consent patterns, check whether the first-call branch reverts or silently registers state, and cross-reference with payable/value-transferring functions where a no-op first call can strand funds.