Staleness and fallback

Equity feeds cover market hours and go stale over weekends by design. A pool that cannot read fresh data does not stop — it charges its high-water maximum.

Fail-safe means the expensive tax

When oracle data is stale or unreadable, the pool falls back to its precomputed high-water rate: the most any combination of its rules could ever charge. Never to its base.

A dead publisher must not freeze a pool

A swap is never reverted because of oracle failure. Anything the hook calls on the swap path is non-reverting, and the hook additionally wraps those calls defensively. A pool whose data source dies degrades; it does not stop trading.

How to read a stale pool

A pool on its fallback is working as designed. Our interfaces show “stale — charging max” in the same amber used for any other caution, not as an error.

Critically, its active-rule bitmap reads 0 because nothing was evaluated. Do not render that as “every rule was checked and none matched”. They are different facts and only one of them is true.

Two different staleness windows

The hook and the launch router use different windows, because their jobs are opposite:

• The hook must not revert. Freezing every pool on a feed hiccup is a far worse outcome than over-charging briefly, so it degrades instead.
• The router must revert. A launch that refuses to open costs one transaction; a launch opened against an unpriceable fill can cost the whole deposit. Its window is looser — four days — because a tighter one would make launching impossible every weekend.

Front-running

A tax change at a block boundary is visible and exploitable, as in any design with a threshold on an oracle. Going stale is safe, because the fallback is the expensive direction. Coming back to fresh is not. The exposure is bounded by the size of the change, not eliminated.