Executive Summary
Where the companion filing on VRF batch shuffling covers how intents are ordered, this claim covers what happens next: how JIL Sovereign's AMM v5 core turns a shuffled batch of buy and sell intents into a single settlement event at one clearing price. The engine starts its search at the live oracle price, iteratively nudges a candidate clearing price toward the level that would balance directional flow, and stops either when the imbalance is negligible or after a fixed maximum number of iterations - all while the candidate price is clamped to a percentage band around the oracle so it can never wander to an economically implausible level even under a thin or lopsided batch.
Once a clearing price is found, every intent in the shuffled batch is evaluated against it independently: intents whose limit price or maximum-slippage tolerance would be violated are skipped rather than force-filled, and the remainder fill at the single discovered price with fees split across liquidity-provider, protocol, and a dedicated allocation the codebase itself labels the humanity-fee share.
Problem Statement
A batch auction that shuffles order sequence but still fills each order at its own marginal price along a continuous bonding curve reopens a subtler version of the ordering problem: an order later in the shuffled sequence still executes against a pool state already moved by every order ahead of it. A true batch-auction defense against MEV requires that price, not just sequence, be decoupled from position in the batch.
Why Continuous-Curve Batch Execution Falls Short
- Sequential AMM execution within a batch: Even after shuffling, each order still moves the price for the next, so batch position still matters economically - just via price impact instead of ordering priority.
- Unbounded price search: A clearing algorithm without an iteration cap or an oracle clamp can, on a thin or adversarial batch, converge slowly or drift the settlement price away from any external reference.
- All-or-nothing batch fills: Forcing every order in a batch to execute regardless of its own limit price either strands conservative traders or requires unbounded price movement to clear.
Technical Architecture
Clearing Pipeline
| Step | Mechanism | Bound |
|---|---|---|
| 1. Shuffle | Fisher-Yates over VRF seed (see Claim 96) | Uniform over all orderings |
| 2. Band computation | p_min = p_oracle * (1 - band), p_max = p_oracle * (1 + band) | Pool-configured oracle_band_bps |
| 3. Iterative search | Evaluate net directional flow at the candidate price; step price ±1% toward balance | Stops when |net flow| < 1 unit, or after 8 iterations |
| 4. Clamp | Candidate price forced back into [p_min, p_max] if the search overshoots | Hard floor/ceiling, no exceptions |
| 5. Per-intent filter | Reject if clearing price violates the intent's limit price, or if the deviation from current pool spot exceeds the intent's own max_slippage_bps | Independent per intent |
| 6. Uniform fill | Every admitted intent executes at the single discovered clearing price | No per-order price variance |
Fee Allocation on Cleared Volume
Each filled intent's fee is computed against the total fee rate and then split proportionally across three destinations tracked in the same execution record: a liquidity-provider share, an operations share, and a residual share the codebase itself designates for a dedicated protocol allocation - keeping the economics of every fill transparent and auditable alongside the clearing price and the fill itself.
Prior Art Differentiation
| Approach | Price Basis | Bounded Search? | Oracle-Clamped? |
|---|---|---|---|
| Continuous AMM (no batching) | Per-trade marginal price | N/A | No |
| Batch with sequential curve fills | Position-dependent within batch | N/A | Rarely |
| Generic uniform-price batch auction | Single clearing price | Often unbounded search | Not always |
| JIL Sovereign | Single clearing price | 8-iteration cap | Yes - hard band clamp |