Arbitrage Safety Checks
1. Three-Layer Arbitrage Validation
The FX Engine (Layer 8) specifies three arbitrage checks that every quote must pass before issuance. The inventory skew offset introduces a new attack surface that must be validated against all three.
| Check | Validation | Skew-Specific Risk |
|---|---|---|
| Self-Arb | BID < ASK on same corridor | Extreme skew could push BID above ASK if spread is too narrow; clamp prevents this |
| Cross-Arb | MYR-IDR direct vs synthetic via USD | Different skews on each leg could create cheaper synthetic route; combined leg cap prevents this |
| External-Arb | Ratio quote vs Binance/CEX spot | Skew could push Ratio price far enough from market to enable CEX arbitrage; MaxSkew cap limits exposure |
2. Skew-Adjusted Arb Threshold
The external arbitrage check compares the Ratio quote (post-skew) against the best available external price. The maximum tolerable deviation is:
Arb_Threshold = Base_Spread + MaxSkew_bps + Safety_Buffer
If the deviation between Ratio's Adjusted MID and the external reference exceeds this threshold, the quote is rejected and the State Engine receives a RESTRICT signal.
| Corridor | Base Spread | MaxSkew | Safety Buffer | Arb Threshold |
|---|---|---|---|---|
| USD-IDR | 3–4 bps | 8 bps | 2 bps | ~14 bps |
| USD-SGD | 1–2 bps | 5 bps | 2 bps | ~9 bps |
| MYR-IDR | 5–6 bps | 12 bps | 2 bps | ~20 bps |
3. Real-Time Feedback Loop
3.1 Post-Execution Inventory Update
As documented in the FX Engine (Layer 9 — Execution, Settlement & Audit Trail), the Active Pool inventory state is updated in real time after every executed swap. The next quote request for the same corridor will immediately reflect the inventory impact of the just-executed trade — there is no batch delay between execution and inventory awareness.
However, the Active Pool does not hold market risk permanently. When the Active Pool's deviation from target exceeds the configured threshold (or on a scheduled basis), Phase 1 internal rebalancing fires via the settleRebalance() function. The Reserve Pool acts as the internal counterparty: it sends the deficit stablecoin to the Active Pool and takes the surplus stablecoin, restoring the Active Pool to its target balance. The Reserve Pool then holds the inventory risk until it is cleared via Phase 2 external rebalancing (RFQ/OTC with Binance, Wintermute, or OTC partners).
- Active Pool: Holds transient imbalance between user swaps and the next rebalancing cycle. Skew is calculated on this transient deviation to attract corrective flow.
- Reserve Pool: Holds actual market risk ("The Bag") after Phase 1 internal settlement. VaR limits (Reserve Pool VaR) govern the maximum inventory the Reserve Pool may accumulate.
- External Partners: Clear Reserve Pool inventory via Phase 2 RFQ/OTC, realising final PnL against WAOP.
3.2 Feedback Loop Sequence
| Step | Action | Impact on Skew |
|---|---|---|
| 1 | User executes swap (e.g., 100 USDT to IDRX) | Active Pool USDT increases, IDRX decreases |
| 2 | Pool state updated atomically on-chain | IR recalculated with new balances |
| 3 | Next quote request triggers fresh skew calculation | Skew offset adjusts based on new IR |
| 4 | If swap moved IR closer to zero, skew reduces | Quote becomes more neutral, reflecting improved balance |
| 5 | If swap moved IR further from zero, skew increases | Quote becomes more aggressive, increasing corrective force |
| 6 | If Phase 1 rebalancing fires, Active Pool resets to target | IR returns to zero; skew zeroes out until new flow creates deviation |
3.3 Convergence Behaviour
Under normal market conditions with balanced bilateral flow, the skew system exhibits self-correcting convergence. When flow is predominantly one-directional (e.g., heavy remittance flow from USD to IDR), the skew progressively increases, which either attracts offsetting flow or the inventory threshold triggers Phase 1 internal rebalancing to the Reserve Pool.
The system is designed so that skew-based correction is always attempted first, with internal rebalancing (Phase 1) as the second line of defence, and external RFQ/OTC (Phase 2) as the final backstop. This ordering minimises external execution costs and maximises the value of natural flow.