Offchain System

Cascade separates millisecond-level price discovery from deterministic custody so builders can reason about each layer independently.

Signed Intent & Order Flow

1. Traders sign maker or taker orders via EIP-712 digests that encode amount, limit price, expiry, fee splits, and execution flags. No gas is spent until settlement.
2. Matchers collect these signed intents, align maker and taker interest, and check that both sides respect their own limits.
3. Optional originators (front-ends or routing networks) can be tipped via a priority fee that sits alongside the protocol fee split.

This off-chain loop handles bulk cancellations, advanced instructions (OCO, stop, iceberg), and routing heuristics without inflating the on-chain surface area.

Matchers & Trust Boundaries

Matchers are trusted for sequencing but not for custody:

• They can determine matching order, but Perpetual replays every signature, lot-size, deviation, open-interest, and margin check before state changes.
• The only path around signatures covers emergency actions—liquidations, closeouts, and ADL unwind intents—so any actor can restore solvency when NAV breaches risk limits.
• Maker/taker role is derived from who provides liquidity at the clearing price; fees and funding calculations use that actual role rather than an off-chain label.

The end result is deterministic settlement while still allowing venues to innovate on UX, routing, or incentive programs off-chain.

Permissionless Emergency Paths

Liquidations run entirely off-chain until the final unwind is posted to Perpetual. Keepers submit taker orders flagged as liquidation or closeout, and the contract proves that:

• the targeted account already breached maintenance or closeout NAV tests,
• the trade strictly reduces the distressed position size, and
• the order inherits the proper price protections (maintenance fills honor deviation caps; closeout fills sacrifice them for liveness).

ADL flows piggyback on closeout events: a solvent maker is sourced automatically to take the other side of the bankrupt trader, shrinking global exposure without socialized loss. Because the signature invariant is waived for these code paths, anyone can trigger them when the math allows.

Oracle & Matcher Inputs

Cascade consumes Stork oracle updates through a short commit pipeline:

1. Decode the batch, verify feed identifiers, and check that timestamps advance.
2. Validate the publisher signature over (id, timestamp, price, publisherRoot, algHash) using the canonical Stork key.
3. Clamp freshness using the market’s maxDelay parameter before caching (p_stork, t_stork).

Matchers must supply two prices for every fill:

• P_index stays within the deviation band of the cached oracle price.
• P_mark—the settlement price—must stay within the same deviation band of P_index.

If any check fails, the entire bundle is rejected. When a bundle does settle, Perpetual emits the accepted (P_index, P_mark) pair so downstream systems can reconstruct funding and NAV calculations exactly.

Signing & Integration Notes

• Reuse Cascade’s published EIP-712 schema when building clients or vault delegates so signatures match the contract digest byte-for-byte.
• Before relaying a bundle, simulate the same invariants off-chain—lot sizing, open-interest deltas, and post-trade margin sufficiency—to avoid submitting fills that will revert on-chain.
• Matchers are trusted only for sequencing, so high-volume routers should keep detailed logs of the orders they match to aid downstream reconciliation.