# liquidationAccountant can be claimed at any time

AstariaRouter passes auction duration instead of final timestamp to liquidationAccountant, so anyone can call claim() before the auction ends, corrupting vault accounting.

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

**Target:** LiquidationAccountant / AstariaRouter liquidation flow
**Root cause:** Router passes `COLLATERAL_TOKEN.auctionWindow() + 1 days` (a duration, ~259200) as `finalAuctionTimestamp` instead of `block.timestamp + duration`, so `finalAuctionEnd` is a tiny absolute value always in the past.
**Steps:**
1. Liquidate a lien ending in a future epoch via `AstariaRouter.liquidate()`, which calls `handleNewLiquidation(lien.amount, auctionWindow()+1 days)`.
2. Observe `finalAuctionEnd` set to ~259200 (3 days as absolute timestamp).
3. Call `LiquidationAccountant.claim()` immediately; require `block.timestamp > finalAuctionEnd` passes.
4. Claim returns 0 since auction hasn't run, decreasing the vault's Y intercept.
**How found:** Code reading of the router's call into handleNewLiquidation, noticing the argument is a duration expression rather than a timestamp, then tracing its use in claim()'s require check.
**Exploitation:** Attacker calls claim() before the auction completes; returned value is 0, so the vault's Y intercept is reduced as if an auction returned no funds, corrupting protocol accounting.
**Insight:** When a timestamp is passed across contracts, check whether the caller computes `block.timestamp + duration` or just passes the duration; a duration used as an absolute deadline is always in the past.