# Oracle epoch block-time overshoot

Block-number-to-time estimates and boundary checks that overshoot into future or empty windows

_Area: DeFi oracles, liquidations and flash loans. Seen in 2 disclosed reports; latest 2024-04-26. Updated 2026-10-24._

## How it works
Contracts that need a timestamp sometimes derive it from `block.number` times an average block time. That estimate is an approximation, unbounded in both directions, and can land in the future. Downstream consumers assume the derived time is at or before `block.timestamp` and falls inside a valid window. When the estimate overshoots into a future or empty epoch, weight or eligibility resolves to zero, silently nullifying rewards or checks [E1](https://bugbountylibrary.com/r/c4%3A2024-03-neobase%3AM-06.md). The same class appears when two separate timestamp comparisons guard a boundary and disagree on inclusivity, so both actions are allowed in the same boundary second [E2](https://bugbountylibrary.com/r/c4%3A2023-03-wenwin%3AM-04.md), and when `block.number` semantics differ on L2s, so a delay measured in blocks is not the delay intended [E3](https://bugbountylibrary.com/r/c4%3A2022-12-tigris%3AM-15.md).

## Where it shows up
- Timestamps computed as `referenceTime + (block.number - referenceBlock) * averageBlockTime` [E1](https://bugbountylibrary.com/r/c4%3A2024-03-neobase%3AM-06.md)
- Reward or weight lookups keyed by a derived epoch/week that can be future-dated [E1](https://bugbountylibrary.com/r/c4%3A2024-03-neobase%3AM-06.md)
- Paired boundary checks using `<` on one side and `>` on the other for the same deadline [E2](https://bugbountylibrary.com/r/c4%3A2023-03-wenwin%3AM-04.md)
- Delay or cooldown logic measured in `block.number` on Arbitrum/Optimism deployments [E3](https://bugbountylibrary.com/r/c4%3A2022-12-tigris%3AM-15.md)

## How to review
For every derived timestamp, ask: is it clamped to `<= block.timestamp`, or does the consumer tolerate a future or empty window without zeroing valid state? The property: a derived time should be clamped, or every consumer must return the intended weight for the actual elapsed time rather than zero. For boundaries, verify both comparisons are consistently inclusive or exclusive so no single second satisfies both guards; the fix is consistent inclusivity, not clamping [E2](https://bugbountylibrary.com/r/c4%3A2023-03-wenwin%3AM-04.md). For L2 targets, confirm every `block.number` timing assumption against that chain's semantics; prefer `block.timestamp` where a real delay is intended [E3](https://bugbountylibrary.com/r/c4%3A2022-12-tigris%3AM-15.md).

## Variants seen
- Block-time estimate overshoots into a future week, zeroing gauge weight [E1](https://bugbountylibrary.com/r/c4%3A2024-03-neobase%3AM-06.md)
- Off-by-one on paired draw/registration deadline checks [E2](https://bugbountylibrary.com/r/c4%3A2023-03-wenwin%3AM-04.md)
- Block-number delay broken by L2 block semantics [E3](https://bugbountylibrary.com/r/c4%3A2022-12-tigris%3AM-15.md)

## Impact and severity
Up to a week of rewards nullified [E1](https://bugbountylibrary.com/r/c4%3A2024-03-neobase%3AM-06.md); a boundary-second bypass letting draw execution and ticket purchase coincide [E2](https://bugbountylibrary.com/r/c4%3A2023-03-wenwin%3AM-04.md); trade delay bypass reusing one oracle price [E3](https://bugbountylibrary.com/r/c4%3A2022-12-tigris%3AM-15.md). Severity rises when the zeroed value is silently accepted rather than reverting, and when the same boundary second enables a value-extracting action.

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2024-03-neobase%3AM-06.md
- E2: https://bugbountylibrary.com/r/c4%3A2023-03-wenwin%3AM-04.md
- E3: https://bugbountylibrary.com/r/c4%3A2022-12-tigris%3AM-15.md