Cascade
Full liquidation cascade — funding-rate stress drives margin breaches across positions, scanner emits close orders, insurance fund absorbs deficit, ADL fires on the residual.
Mark drops from 110 to 96 (mark-book settles); the scanner flags 2 underwater longs at block 2, the write-back loop closes them + their maker counterparties via ADL, cascade resolves in one tick.
What happens
Five traders open long perp positions over two blocks at entry price 110. At block 3 a small mark-book is placed (Buy 95 / Sell 97) — this drops the CLOB midpoint to 96, which is what the liquidation scanner reads as the mark. With longs entered at 110 and mark at 96, the maintenance margin breaks: at block 2 the scanner flags both underwater longs (Bob + Carol); the post-tick write-back loop zeroes their positions and absorbs the shortfall via the insurance fund + ADL (which forces the maker shorts to close at the haircut price). Subsequent ticks see no underwater accounts left to flag, so the cascade resolves in one tick. Use this scenario to see what cross-margin under mark-drop stress looks like, with the full close-loop (scan → liquidate → ADL counter-party) applied between blocks. Note: oracle-driven cascades (where an oracle index price drives the mark, not the CLOB midpoint) need scenario JSON support for oracle observations and land in v2.
Declared outcomes
Each declared outcome is scored ✓ pass / ✗ fail against the run’s actual state.
- Five trading accounts exist after the chain history applies
- Exactly four fills (the four market buys crossing the resting sells)
- No surprise fills beyond the four buys
- Mark settles to 96 once the block-3 mark-book lands (Buy 95 / Sell 97 → midpoint 96)
- The scanner flags the two underwater longs (Bob + Carol) at block 2; write-back closes them so subsequent ticks see nothing to flag
- No more than 2 liquidations fire across the run — write-back prevents re-flagging
- Alice (account 10) survives with her +10 long unchanged (high collateral relative to her position)
- Bob (account 20) ends with position zeroed by the liquidation close
- Carol (account 30) ends with position zeroed by the liquidation close
- Dave (account 40) — the maker who sold into the underwater longs — is force-closed via ADL when the longs go underwater
10 of 10 outcome(s) verified.
Verbatim report
The exact 5-section report the run emits — identical every run.
─── scenario: cascade ────────────────────────────────────
HEADLINE ✓: Mark drops from 110 to 96 (mark-book settles); the scanner flags 2 underwater longs at block 2, the write-back loop closes them + their maker counterparties via ADL, cascade resolves in one tick.
DESCRIPTION:
Five traders open long perp positions over two blocks at entry price 110. At block 3 a small mark-book is placed (Buy 95 / Sell 97) — this drops the CLOB midpoint to 96, which is what the liquidation scanner reads as the mark. With longs entered at 110 and mark at 96, the maintenance margin breaks: at block 2 the scanner flags both underwater longs (Bob + Carol); the post-tick write-back loop zeroes their positions and absorbs the shortfall via the insurance fund + ADL (which forces the maker shorts to close at the haircut price). Subsequent ticks see no underwater accounts left to flag, so the cascade resolves in one tick. Use this scenario to see what cross-margin under mark-drop stress looks like, with the full close-loop (scan → liquidate → ADL counter-party) applied between blocks. Note: oracle-driven cascades (where an oracle index price drives the mark, not the CLOB midpoint) need scenario JSON support for oracle observations and land in v2.
TIMELINE (per-block):
height mark src trades fills deposits liqs adl fund
------ ------ --------------- ------ ----- -------- ---- --- ----
1 100 stub-empty-book 2 0 5 0 — —
2 100 stub-empty-book 4 4 0 2 yes —
3 96 clob 2 0 0 0 — —
4 96 clob 0 0 0 0 — —
5 96 clob 0 0 0 0 — —
ACCOUNT DELTA (final − initial):
account collateral position avg_entry
------- ---------- -------- ---------
10 200 10 110
20 0 0 110
30 0 0 110
40 300 0 110
50 200 -20 110
(initial account count: 0, final account count: 5)
OUTCOMES:
✓ Five trading accounts exist after the chain history applies
✓ Exactly four fills (the four market buys crossing the resting sells)
✓ No surprise fills beyond the four buys
✓ Mark settles to 96 once the block-3 mark-book lands (Buy 95 / Sell 97 → midpoint 96)
✓ The scanner flags the two underwater longs (Bob + Carol) at block 2; write-back closes them so subsequent ticks see nothing to flag
✓ No more than 2 liquidations fire across the run — write-back prevents re-flagging
✓ Alice (account 10) survives with her +10 long unchanged (high collateral relative to her position)
✓ Bob (account 20) ends with position zeroed by the liquidation close
✓ Carol (account 30) ends with position zeroed by the liquidation close
✓ Dave (account 40) — the maker who sold into the underwater longs — is force-closed via ADL when the longs go underwater
10 of 10 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/cascade.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