# Auction deadline duration timestamp confusion

Stored auction end is a duration, not block.timestamp plus duration, so guards fire early or late

_Area: DeFi oracles, liquidations and flash loans. Seen in 2 disclosed reports; latest 2022-11-07. Updated 2026-10-23._

## How it works
A deadline guard compares `block.timestamp` against a stored `end` value. The assumption that breaks: the stored value is an absolute timestamp. When the code stores a duration (e.g. `auctionWindow() + 1 day`) instead of `block.timestamp + duration`, the comparison is meaningless. A duration like ~259200 is a tiny absolute value, always in the past, so guards that should block claims until the auction ends pass immediately [E3](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-34.md). The same confusion lets epochs progress while an auction is still running, corrupting liquidation accounting [E1](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-21.md).

## Where it shows up
- A field named `finalAuctionEnd`, `finalAuctionTimestamp` or similar assigned from a config getter such as `auctionWindow()` rather than `block.timestamp + ...` [E1](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-21.md)[E3](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-34.md).
- Guards of the form `block.timestamp >= end` or `block.timestamp < end` where `end` crosses a contract boundary.
- Epoch or session logic that assumes an auction ends within a fixed window, ignoring bid-extension logic (timeBuffer) that pushes the real end later [E2](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-31.md).
- Functions like `claim()` or `processEpoch()` gated only by such a comparison.

## How to review
The invariant: every stored deadline must be an absolute timestamp computed as `block.timestamp + duration` at the point of storage, and every guard must compare `block.timestamp` against it. Trace each `end`/`deadline` value from assignment to comparison. If it comes from a getter returning a duration, it is wrong. Separately, check that any "will this end before X" branch accounts for the auction engine's extension rules, not just the nominal window [E2](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-31.md).

## Variants seen
- Duration stored as absolute end, letting `claim()` fire before the auction ends [E3](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-34.md).
- Same duration confusion letting epochs advance mid-auction, causing LP fund loss and collateral lockup [E1](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-21.md).
- Epoch check ignoring anti-sniping extensions, so auctions end in a later epoch and withdrawers are underpaid [E2](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-31.md).

## Impact and severity
High: premature claims corrupt vault accounting [E3](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-34.md), mid-auction epoch progression locks collateral and loses LP funds [E1](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-21.md), and mis-timed epoch ends underpay withdrawers [E2](https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-31.md). Severity rises when the wrong value is passed across contracts, since the receiving guard cannot tell a duration from a timestamp.

## Why fixes fail
Fixing only the assignment in one caller leaves other paths passing durations; the receiving contract has no type-level way to reject a duration, so each call site must be audited.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-21.md
- E2: https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-31.md
- E3: https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-34.md