# Epochs can be progressed during ongoing auctions to cause LP fund loss and collateral lockup

AstariaRouter.liquidate sets finalAuctionEnd to a fixed duration (auctionWindow+1 day) instead of a timestamp, letting epochs progress mid-auction and corrupting liquidation accounting.

- Payout: Contest reward
- Severity: high
- Program: Astaria
- Credited: 0xRajeev
- Disclosed: 2022-11-07
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-10-astaria-judging/issues/175
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-21
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic vuln:liquidation

**Target:** PublicVault/LiquidationAccountant epoch and auction lifecycle
**Root cause:** finalAuctionEnd is assigned a duration (COLLATERAL_TOKEN.auctionWindow() + 1 day) rather than block.timestamp + duration, so the auction-end guard in LiquidationAccountant.claim() and PublicVault.processEpoch never correctly reflects an ongoing auction.
**Steps:**
1. Observe AstariaRouter.liquidate calls LiquidationAccountant.handleNewLiquidation which sets finalAuctionEnd = COLLATERAL_TOKEN.auctionWindow() + 1 days (a duration, not a timestamp).
2. Note auctionWindow() returns 2 days, so finalAuctionEnd is a small constant (~3 days) rather than a future timestamp.
3. Since block.timestamp is always greater than this small constant, LiquidationAccountant.claim() passes its `finalAuctionEnd == 0 || block.timestamp > finalAuctionEnd` check even while the auction is ongoing.
4. Call PublicVault.processEpoch() during an ongoing auction despite a liquidation accountant being deployed for the current epoch.
5. Epoch advances mid-auction, desynchronizing liquidation accounting from the auction state.
**How found:** Code review of the liquidation/epoch lifecycle: noticed finalAuctionEnd was set from auctionWindow() (a duration) rather than a timestamp, then traced how claim() and processEpoch rely on that value as a time comparison.
**Exploitation:** Attacker (or any LP) triggers processEpoch while an auction is live because the finalAuctionEnd guard is bypassed by the duration-vs-timestamp bug, advancing the epoch and corrupting liquidation accounting to cause LP fund loss and collateral lockup.
**Insight:** When a guard compares block.timestamp against a stored 'end' value, verify the stored value is actually a timestamp and not a duration returned by a config getter like auctionWindow(); duration-vs-timestamp confusion silently disables time-based guards.