Skip to main content

VaR Monitoring Pipeline (Steps 1–3)

1. Reserve Pool Snapshot

At each trigger, the system captures a consistent snapshot of the Reserve Pool's state across all corridors. All values must be captured atomically from the same block to avoid stale or inconsistent data across corridors.

Data PointSourceDescription
Inventory UnitsOn-chain Reserve Pool balanceTotal units of each stablecoin currently held in Reserve. e.g., 30,000,000 IDRX
WAOP (per batch)WAOP tracking contract / backend ledgerWeighted Average Oracle Price at which the inventory was absorbed from the Active Pool. This is the cost basis.
Current Oracle MidPyth + Orakl aggregated priceCurrent aggregated mid-rate for the corridor pair. Same source as FX Engine oracle layer.
Pool Capital (USD)Reserve Pool USDT balance at oracle rateCurrent USD-equivalent value of all stablecoins held in Reserve. Used as the denominator for VaR ratio calculations.
Batch CountRebalancing batch ledgerNumber of open (unsettled) batches per corridor. Multiple open batches increase concentration risk.
Time Since Last External RebalanceBatch lifecycle trackerHow long the oldest open batch has been accumulating. Longer duration = greater market risk exposure.

2. Exposure & Mark-to-Market Calculation

2.1 Gross Inventory Exposure

Gross Inventory Exposure converts the raw inventory position into USD terms using the current oracle mid-rate. This gives the protocol a single comparable number for how much capital is at risk in each corridor.

Gross Exposure (USD) = Inventory Units × Current Oracle Mid

Example: Reserve holds 30,000,000 IDRX. Current USD/IDR oracle mid = 16,000. Gross Exposure = 30,000,000 / 16,000 = $1,875 USD.

Note on Direction

Ratio's Reserve Pool holds the currency it received from the Active Pool — typically IDR stablecoins when the market has been net USD-to-IDR. A long IDRX position loses value when IDR weakens (USD/IDR rate rises). The VaR calculation is always computed from the perspective of the Reserve Pool needing to sell the held currency to buy back USDT.

2.2 Unrealised PnL (Mark-to-Market)

Unrealised PnL measures how the inventory's value has changed since it was absorbed at WAOP. A positive unrealised PnL means the market has moved favourably — the Reserve could clear at better than WAOP right now. A negative unrealised PnL means the market has moved against the position.

Unrealised PnL = (Current Oracle Mid − WAOP) × Inventory Units
ScenarioWAOPCurrent Oracle MidUnrealised PnLInterpretation
USD/IDR rising (IDR weakening)16,00016,200−$375 on 30M IDRXMarket moved against position. Reserve would lose money clearing now.
USD/IDR falling (IDR strengthening)16,00015,800+$375 on 30M IDRXMarket moved in favour. Reserve would profit if clearing now.
No change16,00016,000$0Neutral. Break-even rebalance.

3. VaR Calculation Engine

Value-at-Risk (VaR) answers the question: given the current inventory position and current market volatility, what is the maximum loss the Reserve Pool could realistically suffer over the next 24 hours at a given confidence level? It translates a position size and a volatility measurement into a single loss estimate that can be compared against the pool's capital.

3.1 VaR Formula

1-Day VaR = Gross Exposure × Daily Volatility × Confidence Multiplier
InputSourceDescription
Gross Exposure (USD)Step 2 calculationUSD value of the inventory position in the Reserve Pool
Daily VolatilityPyth conf (primary) or historical StdDev (secondary)Expected 1-day price movement of the corridor pair, expressed as a percentage
Confidence MultiplierConfigured per risk level95% confidence = 1.645 (standard risk). 99% confidence = 2.326 (stress test scenario).

3.2 Volatility Sourcing

The VaR engine uses two volatility sources in priority order, consistent with the approach defined in the Ratio Volatility Spread Calculation specification.

SourceMethodWhen UsedRationale
Pyth Network conf fieldVolatility% = (conf / price) × 100Primary — always attempted firstGas-efficient, real-time, reflects immediate publisher uncertainty. Publishers widen conf during crashes, providing an instant defence signal.
Historical StdDev via Web2 backendStdDev of last 30 minutes of 1-minute OHLC data from XE / Twelve DataSecondary — used when Pyth conf is unavailable or appears anomalously lowCaptures trend-based choppiness. More accurate for pricing inventory risk over a multi-hour window.

3.3 Example VaR Calculation

InputValue
Gross Exposure (USD)$1,875 USD (30M IDRX at 16,000 rate)
Pyth conf fieldconf = 24, price = 16,000 → Volatility = 24/16,000 = 0.15%
Daily Volatility (scaled)0.15% × √(1440 minutes / 1 minute) ≈ 0.57%
Confidence Multiplier (95%)1.645
1-Day VaR$1,875 × 0.0057 × 1.645 = $17.58 USD
Reserve Pool Capital$5,000,000 USD (max capacity)
VaR as % of Capital0.00035% — well within normal bounds

3.4 Portfolio VaR Aggregation

VaR is calculated independently per corridor, then aggregated to a total portfolio level. A simple sum of corridor VaRs is conservative (assumes perfect correlation). Ratio applies a correlation discount to account for the fact that IDR, SGD, and MYR do not move perfectly together, which reflects a more realistic portfolio risk.

Total Portfolio VaR = Sum of (Corridor VaRs) × (1 − Diversification Discount)
Diversification Discount: 15% for Phase 1 (three corridors, moderate correlation)

The 15% diversification discount reflects the imperfect correlation between USD-IDR, USD-SGD, and MYR-IDR movements. In stressed markets where correlations converge toward 1.0, this discount provides less protection — which is by design, as the threshold checks in Step 4 are calibrated assuming the discount applies.