Inventory Position Calculation
1. Inventory Ratio Definition
The inventory position for each corridor is expressed as a ratio of the current Active Pool balance to the target balance for each stablecoin in the pair.
Inventory Ratio (IR) = (CurrentBalance − TargetBalance) / TargetBalance
| Variable | Definition |
|---|---|
| CurrentBalance | Real-time Active Pool balance for the stablecoin, denominated in USD equivalent at Oracle MID |
| TargetBalance | Configured target balance for the stablecoin in that corridor, set by Ops and reviewed weekly |
| IR = 0 | Pool is perfectly balanced at target |
| IR > 0 | Pool is long that stablecoin (excess inventory) |
| IR < 0 | Pool is short that stablecoin (deficit) |
The Active Pool balance drifts from target as user swaps execute. The skew is calculated based on this real-time drift. However, the Active Pool does not hold market risk permanently. When Phase 1 internal rebalancing fires (via settleRebalance()), the Reserve Pool acts as the internal counterparty: it restores the Active Pool to target and absorbs the inventory risk ("The Bag").
The Reserve Pool then holds this market risk until it is cleared via Phase 2 external rebalancing (RFQ/OTC). The skew system operates on the Active Pool's deviation between rebalancing cycles to attract corrective flow before internal settlement is needed.
2. Dual-Sided Inventory Check
For every corridor (e.g., USD-IDR), the system calculates the IR for both sides of the pair. The side with the larger absolute deviation determines the skew direction. This ensures the skew addresses the most pressing imbalance.
IR_USDT = (USDT_Current − USDT_Target) / USDT_Target
IR_IDRX = (IDRX_Current_USD_Equiv − IDRX_Target_USD_Equiv) / IDRX_Target_USD_Equiv
If |IR_USDT| > |IR_IDRX|, the USDT side drives the skew. If |IR_IDRX| > |IR_USDT|, the IDRX side drives the skew. If both are within the dead zone (see Skew Formula), no skew is applied.
3. USD-Equivalent Normalisation
Because IDRX is denominated in IDR (where 1 USD ≈ 15,800 IDR), raw token balances cannot be compared directly. All balances are normalised to USD-equivalent using the Oracle MID before the Inventory Ratio is calculated. This ensures the skew magnitude is proportional to the actual economic exposure, not the nominal token count.
IDRX_USD_Equiv = IDRX_Balance / Oracle_MID_USDIDR
4. Worked Example: USD-IDR
Scenario: The Active Pool target for the USD-IDR corridor is $500,000 USDT and 7,900,000,000 IDRX (equivalent to $500,000 at Oracle MID of 15,800). After a period of heavy USD-to-IDR remittance flow, the pool now holds $350,000 USDT and 10,270,000,000 IDRX ($650,000 USD equivalent).
Step 1: Calculate IR for both sides
IR_USDT = (350,000 − 500,000) / 500,000 = −0.30
IR_IDRX = (650,000 − 500,000) / 500,000 = +0.30
Both sides show a 30% deviation. The IDRX side is long (positive IR), which means the protocol needs to encourage users to take IDRX off the books.
Step 2: Check Dead Zone
|IR| = 0.30, which exceeds the USD-IDR dead zone of 0.05. Skew is active.
Step 3: Calculate Skew Offset
InventorySkew_bps = clamp(15 × 0.30, −8, +8)
InventorySkew_bps = clamp(4.5, −8, +8) = 4.5 bps
The skew offset is 4.5 bps, within the 8 bps cap.
Step 4: Apply to Mid-Rate
Since the protocol is long IDRX, the mid is pulled DOWN (making USD-to-IDR cheaper for users):
Oracle MID = 15,800.00 IDR per USD
Skew Offset = 15,800 × 4.5 / 10,000 = 7.11 IDR
Adjusted MID = 15,800.00 − 7.11 = 15,792.89 IDR per USD
Users swapping USD to IDR now get a slightly better rate (15,792.89 vs 15,800), which attracts the flow that reduces the IDRX surplus. Users swapping IDR to USD get a slightly worse rate, which discourages flow that would worsen the imbalance.
5. Skew Direction Logic
The direction in which the mid-rate is shifted depends on the protocol's Active Pool inventory position. The goal is always to make the beneficial direction of flow cheaper for users.
| Inventory Position | Skew Direction | MID Shift | Economic Effect |
|---|---|---|---|
| Long local (e.g., excess IDRX) | Negative skew | MID pulled DOWN ↓ | USD-to-IDR swaps cheaper; attracts flow that removes excess IDRX from pool |
| Short local (e.g., deficit IDRX) | Positive skew | MID pulled UP ↑ | IDR-to-USD swaps cheaper; attracts flow that adds IDRX to pool |
| Balanced | Zero skew | No shift | Neutral pricing; spread applied symmetrically around Oracle MID |
Cross-Corridor Consistency (MYR-IDR)
For synthetic cross routes (MYR-IDR via USD pivot), the skew must be applied consistently across both legs. If the MYR-IDR corridor is executed as MYR-to-USD then USD-to-IDR, the skew on each leg reflects the inventory position of each respective pool. The combined effect must not create an arbitrage loop.
The pre-flight atomicity check (FX Engine, Layer 4) validates that the combined skew across both legs does not exceed the corridor-level MaxSkew_bps for MYR-IDR (12 bps). If the sum of both leg skews exceeds this cap, the cross-route skew is proportionally reduced.
Combined Skew = Skew_Leg1 + Skew_Leg2
If |Combined Skew| > MaxSkew_MYR_IDR: scale both legs proportionally