State-Aware Trade Routing with Deterministic Precedence Chain

Executive Summary

JIL Sovereign's trading stack offers a trader more than one way to fill an order: the constant-product AMM leg for immediate execution, a request-for-quote (RFQ) leg for institutional-size fills, and a time-weighted execution leg for orders that should be worked over many blocks rather than filled at once. Deciding which leg to try first, on a per-order or per-heuristic basis, risks making that decision inconsistently with the system's actual real-time risk posture.

JIL's approach instead derives venue precedence entirely from the single, centrally computed MarketState value described in the companion hysteresis state-machine filing. Each of the four states carries a statically defined parameter set - whether the AMM is enabled, whether RFQ is enabled, and whether RFQ is prioritized ahead of the AMM - so that the precedence chain for every order routed during a given state is identical, computed once by the state manager and consumed everywhere downstream.

Problem Statement

A multi-venue trading system that lets each order independently decide its own routing logic creates a race condition at the risk-management layer: two orders evaluated at nearly the same instant, under slightly different local views of market conditions, could route to different venues even though the system's actual risk state has not changed between them. During a stress event, this kind of inconsistency is exactly when it is most costly.

Why Per-Order Routing Heuristics Fall Short

• Local decision drift: Independent per-order evaluators can reach different conclusions from stale or slightly different signal snapshots.
• Unauditable routing: Without one canonical state driving the decision, it is difficult to prove after the fact that two similarly situated orders were routed consistently.
• Race conditions at state transitions: An order evaluated during the transition window between two states can be routed as if the old state still applied unless routing reads from the same authoritative state value the risk system just updated.

Technical Architecture

Precedence Table by State

Single Source of Truth

The precedence table is not evaluated independently by each routing call; it is a pure function of the one MarketState value maintained by the state manager described in Claim 98. Because every routing decision reads the same state at the moment of routing, and because state transitions themselves are serialized through a single evaluator, no two orders processed under the same state value can be routed inconsistently with each other.

Time-Weighted Fallback Leg

For order sizes that would otherwise need to breach a stress-scaled cap on the AMM or RFQ legs, the precedence chain's final fallback is a time-weighted execution leg that slices the order into per-block increments proportional to a configured execution window, rather than forcing an outsized single fill through either primary venue.

Prior Art Differentiation

Patent Claim