Cascade

何が起きるか

5人のトレーダーがエントリー価格110で2ブロックにわたりロングの perp ポジションを建てる。ブロック3で小さなマークブック（Buy 95 / Sell 97）が置かれ、CLOB のミッドポイントが96へ低下——これが清算スキャナの読むマーク価格になる。エントリー110・マーク96のため維持証拠金が割れ、ブロック2でスキャナは水没した2件のロング（Bob・Carol）を検知。tick 後のライトバックループが両者のポジションをゼロにし、不足分を保険基金＋ADL（メイカーのショートをヘアカット価格で強制決済）で吸収する。以降の tick では検知すべき水没アカウントが残らず、カスケードは1tickで解消。mark-drop ストレス下のクロスマージンが、ブロック間で scan→liquidate→ADL 相手方というクローズループ全体を伴ってどう振る舞うかを見るためのシナリオ。注：オラクル起点のカスケード（CLOB ミッドポイントでなくオラクル指数価格がマークを駆動する場合）はシナリオ JSON のオラクル観測対応が必要で、v2 で対応予定。

宣言された結果

宣言した各結果は、実行時の実際の状態に対して ✓ 合格 / ✗ 不合格 で採点されます。

• チェーン履歴の適用後、トレーディングアカウントが5件存在する
• 約定はちょうど4件（4件の成行買いが待機中の売りとクロス）
• 4件の買い以外に想定外の約定はない
• ブロック3のマークブック（Buy 95 / Sell 97 → ミッド96）が置かれるとマークは96に確定
• ブロック2でスキャナが水没ロング2件（Bob・Carol）を検知。ライトバックが決済し、以降の tick では検知対象が残らない
• 実行を通じて清算は2件を超えない——ライトバックが再検知を防ぐ
• Alice（アカウント10）は +10 ロングを維持して生存（ポジションに対し証拠金が厚い）
• Bob（アカウント20）は清算決済でポジションがゼロになって終了
• Carol（アカウント30）は清算決済でポジションがゼロになって終了
• Dave（アカウント40）——水没ロングへ売ったメイカー——はロングが水没した際に ADL で強制決済される

10件中10件の結果を検証

検証レポート（原文）

ツールが出力する英語の原文レポート（5セクション）——毎回同一です。

─── 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

他のシナリオ