Exchange Engineering Shortlist — October 3, 2026
1. Forced or Frantic? — liquidation cascades vs panic selling
A recent Hyperliquid study separates forced deleveraging from voluntary position-closing and finds that forced liquidations create materially more price dislocation even after controlling for liquidation size.
Why it matters: a risk engine should not treat all selling pressure as equivalent. Liquidations are synchronized, time-constrained flows that can consume liquidity faster than normal discretionary selling.
Worth applying: track liquidatable notional together with expected depth consumption and concentration of liquidation prices. A large amount of maintenance-margin exposure clustered inside a narrow price band should raise a symbol-level liquidation concentration score.
2. Reference-price construction and perpetual fragility
Recent work on perpetual markets highlights how reference-price construction can become a failure amplifier when oracle prices diverge sharply from executable market prices.
Why it matters: index price, mark price, and last traded price should be treated as independent signals rather than interchangeable inputs to liquidation.
Worth applying: continuously monitor mark/index divergence, last/index divergence, venue dispersion, constituent freshness, and a depth-adjusted confidence score. The liquidation engine should be able to enter a degraded-oracle mode instead of blindly liquidating against a technically valid but economically implausible mark.
3. Deribit Starbase — separate the exchange interfaces
Deribit's newer high-performance stack separates binary order entry, sequenced market-data distribution, and independent drop-copy reconciliation.
Why it matters: sophisticated participants should not have to reconstruct authoritative order and trade history from the same session used for order submission.
Worth applying: keep order entry, market data, and drop copy as distinct interfaces. Internally, use the same principle for reconciliation so every account can reconstruct authoritative activity independently from the trading gateway.
4. Central counterparty risk in automated markets
Recent clearing-risk research formalizes the feedback loop where liquidating a defaulting trader moves the market, which changes the size of the remaining deficit and the resources available to absorb it.
Why it matters: liquidation, insurance funds, and ADL are not independent subsystems. Price impact from liquidation directly changes downstream loss allocation.
Worth applying: scenario-test the full waterfall — account equity, liquidation execution, liquidation penalty, insurance fund, and ADL — as one coupled system. The simulator should answer whether the entire waterfall survives a shock, not merely whether individual accounts liquidate correctly.
5. Market-data health must measure data, not sockets
Recent multi-exchange feed measurements show that a connection can remain technically healthy while the underlying market data is stale or nearly absent.
Why it matters: a connected-but-stale venue is more dangerous to an index or oracle than a clearly disconnected venue because it can continue to look eligible.
Worth applying: track last-message age, exchange-event age, sequence gaps, updates per second, checksum validity, and best-bid/best-ask freshness. Oracle eligibility should depend on these data-plane signals rather than WebSocket connection state.
6. eBPF and low-overhead hot-path observability
New observability work continues to show that lightweight kernel- and runtime-level probes can measure low-latency systems with substantially less interference than conventional application tracing.
Why it matters: instrumenting every matching-engine operation with normal distributed tracing can distort the tail latency you are trying to understand.
Worth applying: use OpenTelemetry for service-level causality across API, risk, wallet, sequencer, and engine boundaries, but use perf counters, eBPF, compact ring-buffer events, and asynchronous export for the actual matching hot path.
One experiment worth building
Build a Liquidation Blast Radius simulator. For each symbol, apply a price shock, identify accounts crossing maintenance margin, aggregate forced orders, walk the current book, recompute the mark, discover newly liquidatable accounts, and repeat until the cascade stops.
Run shocks such as 1%, 2%, 5%, 10%, and 15% and report initial liquidation notional, cascade liquidation notional, book consumed, worst slippage, insurance-fund loss, whether ADL is required, and number of cascade rounds.
The practical goal is to let maximum leverage depend not only on historical volatility, but on how much forced inventory the market can actually absorb.