Layer 4 — Corridor Routing & MYR-IDR Rate Construction
Direct Book Routing (USD-IDR and USD-SGD)
For USD-IDR and USD-SGD, the system routes directly to the respective corridor's Active Pool. No rate construction is required — the oracle mid-rate for these pairs is sourced directly in Layer 5. The request proceeds immediately to Oracle Aggregation.
MYR-IDR Rate Construction Logic
MYR-IDR requires a two-step evaluation before routing. Step 1 determines the reference FX rate using oracle feeds. Step 2 determines the execution path based on pool liquidity. These two decisions are independent — the rate source and the execution route do not need to match.
Step 1 — Rate Construction: Direct Feed Primary, Synthetic as Fallback
The system first checks whether Pyth or Orakl provides a native MYR/IDR price feed. A direct feed is always preferred as the primary rate source because it is more accurate and carries no construction risk.
| Oracle Feed Availability | Rate Construction Method | rate_source Flag |
|---|---|---|
| Direct MYR/IDR feed available from Pyth or Orakl | Direct oracle rate used as the reference MID for all downstream pricing. The synthetic rate is still computed independently in Layer 8 for use in the arbitrage gap check only — it never overrides the direct feed price. | DIRECT |
| No direct MYR/IDR feed from either oracle | Synthetic rate constructed: MYR/IDR = USD/IDR rate divided by USD/MYR rate, plus cross spread add-on. This synthetic rate becomes the reference MID for all downstream pricing. | SYNTHETIC |
The synthetic rate is always computed in Layer 8 (Arbitrage Check) regardless of whether a direct feed exists. This is required for Check 2 of the arb validation — the gap between the direct rate and the synthetic rate must stay within threshold. However, when a direct feed is available, the synthetic rate is used only for this validation purpose and never replaces the direct feed as the pricing reference.
Step 2 — Liquidity Routing: Direct Book or Cross Execution
Once the reference FX rate is determined in Step 1, the system evaluates MYR-IDR Active Pool depth to decide which execution path to use. This decision is independent of Step 1.
| Liquidity Condition | Execution Path |
|---|---|
| MYR-IDR Active Pool depth sufficient for requested amount | Execute directly against MYR-IDR Active Pool using the Step 1 reference rate (direct or synthetic) |
| MYR-IDR Active Pool thin — insufficient depth | Route via USD cross: execute as two legs (USD-IDR and USD-MYR). Both legs must be atomically reserved before either executes. |
Cross-Route Atomicity Check
When MYR-IDR routes via the USD cross, both legs must be confirmed viable before either executes:
- System checks USD-IDR Active Pool depth against the required notional for Leg 1
- System checks USD-MYR Active Pool depth against the required notional for Leg 2
- Only if both legs confirm sufficient depth are both legs reserved simultaneously
- If either leg is insufficient, both legs are aborted. Response:
Insufficient Cross Liquidity
Without atomic pre-flight checking, a partial cross execution is possible — Leg 1 executes but Leg 2 fails, leaving the protocol with an open USD-IDR position and no corresponding MYR leg. This is a broken trade state requiring manual intervention. The atomicity check prevents this entirely.