# If a `lendingPool` is added to the network while in `late` state, can be defaulted instantly

DefaultStateManager sets state to Late without setting lateTimestamp when a newly added lending pool is first assessed in Late state, letting anyone default it instantly.

- Payout: Contest reward
- Severity: medium
- Program: Carapace
- Credited: Allarious
- Disclosed: 2023-02-01
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-carapace-judging/issues/151
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-carapace%3AM-5
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** DefaultStateManager / ReferenceLendingPools smart contracts
**Root cause:** _assessState transitions Not Supported -> Late without setting lateTimestamp (remains zero), so the grace period check passes immediately on the next call.
**Steps:**
1. Pool is Active when added via `_addReferenceLendingPool` (checked in ReferenceLendingPools.sol#L284)
2. Daily `assessState` runs; pool later goes Active -> Late before next assessment
3. Next `assessState` (delayed) moves pool Not Supported -> Late without setting `lateTimestamp`
4. Attacker calls `assessState` again; zero lateTimestamp makes grace period appear elapsed, marking pool defaulted
**How found:** Code reading of DefaultStateManager._assessState state transitions; noticed lateTimestamp not initialized on first Late entry, and that add-then-assess timing gap allows Active->Late in between.
**Exploitation:** Anyone calls `assessState` a second time after the first Late transition; no capital or permission needed, only gas. Pool becomes defaulted and unusable, DoSing buyers.
**Insight:** When auditing state machines, check that every transition into a time-dependent state initializes its timestamp; first-entry paths from an uninitialized/Not Supported state often skip grace-period bookkeeping.