Oracle stale
Stale publisher feed — staleness filter drops the offending feed, deviation filter contains the residual outlier, scanner does not trigger.
Oracle protects the book at 110; once the feed goes stale at block 4 the CLOB midpoint takes over and the longs cascade.
What happens
Three traders open long perp positions at entry 110 against one maker (40 sells 50 @ 110). An oracle index price is published at 110 — so even though the CLOB midpoint later settles to 91 via mark-book orders Buy 90 / Sell 92, `effective_mark` reads the oracle and the longs remain HEALTHY. At block 4 the oracle aggregate goes stale: the bridge clears its cached index, `effective_mark` falls back to the CLOB midpoint 91, and the cascade fires. Accounts 10 / 20 / 30 are underwater, the close-loop liquidates them, and the maker counterparty (40) takes the ADL hit when the underwater closes run out of book liquidity. Use this scenario to see what happens when an oracle feed silently drops out from under a live position book.
Declared outcomes
Each declared outcome is scored ✓ pass / ✗ fail against the run’s actual state.
- Four trading accounts exist after the chain history applies (mark-book accounts 1 / 2 don't deposit).
- The three under-collateralized longs (10 / 20 / 30) are flagged by the scanner once the oracle clears at block 4.
- The maker short (40) is force-closed via ADL when the underwater longs run out of book liquidity.
- Account 40's short is fully absorbed by ADL.
- After the oracle clears, `effective_mark` falls back to the CLOB midpoint (Buy 90 / Sell 92 → 91).
5 of 5 outcome(s) verified.
Verbatim report
The exact 5-section report the run emits — identical every run.
─── scenario: oracle-stale ────────────────────────────────────
HEADLINE ✓: Oracle protects the book at 110; once the feed goes stale at block 4 the CLOB midpoint takes over and the longs cascade.
DESCRIPTION:
Three traders open long perp positions at entry 110 against one maker (40 sells 50 @ 110). An oracle index price is published at 110 — so even though the CLOB midpoint later settles to 91 via mark-book orders Buy 90 / Sell 92, `effective_mark` reads the oracle and the longs remain HEALTHY. At block 4 the oracle aggregate goes stale: the bridge clears its cached index, `effective_mark` falls back to the CLOB midpoint 91, and the cascade fires. Accounts 10 / 20 / 30 are underwater, the close-loop liquidates them, and the maker counterparty (40) takes the ADL hit when the underwater closes run out of book liquidity. Use this scenario to see what happens when an oracle feed silently drops out from under a live position book.
TIMELINE (per-block):
height mark src trades fills deposits liqs adl fund
------ ------ --------------- ------ ----- -------- ---- --- ----
1 110 oracle 1 0 4 0 — —
2 110 oracle 3 3 0 0 — —
3 110 oracle 2 0 0 0 — —
4 91 clob 0 0 0 3 yes —
5 91 clob 0 0 0 0 — —
ACCOUNT DELTA (final − initial):
account collateral position avg_entry
------- ---------- -------- ---------
10 0 0 110
20 0 0 110
30 0 0 110
40 824 0 110
(initial account count: 0, final account count: 4)
OUTCOMES:
✓ Four trading accounts exist after the chain history applies (mark-book accounts 1 / 2 don't deposit).
✓ The three under-collateralized longs (10 / 20 / 30) are flagged by the scanner once the oracle clears at block 4.
✓ The maker short (40) is force-closed via ADL when the underwater longs run out of book liquidity.
✓ Account 40's short is fully absorbed by ADL.
✓ After the oracle clears, `effective_mark` falls back to the CLOB midpoint (Buy 90 / Sell 92 → 91).
5 of 5 outcome(s) verified.
NOTE: v1 runs the scenario in-process against a unit-provider
`LiveRethEvmBridge<()>` (no Reth boot). For the production-shape
run (real Reth + Malachite + JSON-RPC), use:
openhl reth-devnet --chain-history scenarios/oracle-stale.json --rounds 5
NEXT:
• Adopt this engine : https://github.com/psyto/rdk
• Custom build : https://fabrknt.com/waitlist.html?product=evm-perp&intent=build
• Hosted access : https://fabrknt.com/waitlist.html?product=evm-perp&intent=hosted