# There can only ever be one market with USDT as the underlying

MarketPlace.createMarket unconditionally approves USDT underlying; USDT reverts on non-zero-to-non-zero approve, so only the first USDT market can ever be created.

- Payout: Contest reward
- Severity: medium
- Program: Illuminate
- Credited: pashov
- Disclosed: 2022-10-15
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-10-illuminate-judging/issues/99
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-illuminate%3AM-10
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:dos vuln:misconfiguration

**Target:** MarketPlace.createMarket / Lender.approve on ERC20 underlying
**Root cause:** Lender.approve() calls Safe.approve(uToken, spender, max) without first resetting allowance to zero; USDT-style tokens revert when changing a non-zero allowance to another non-zero value.
**Steps:**
1. Deploy MarketPlace and create first market with USDT as underlying u; Lender.approve sets allowance(u, spender)=max.
2. Create a second market with same USDT underlying; createMarket calls `ILender(lender).approve(u, e, a, t[7])`.
3. Lender.approve executes `Safe.approve(uToken, a, max)` while existing allowance is max, USDT reverts.
4. Market creation for second USDT market fails permanently.
**How found:** Code reading of createMarket's unconditional approve call combined with knowledge of weird-ERC20 approval race protections (USDT reverts on non-zero-to-non-zero approve).
**Insight:** When auditing market/factory contracts that approve underlying tokens per-deployment, check whether the token reverts on non-zero-to-non-zero approve; a shared Lender holding allowances across markets will brick subsequent deployments.