Reserve Pool VaR & Emergency RFQ
1. Purpose & Scope
This section specifies the Reserve Pool Value-at-Risk (VaR) monitoring system and Emergency RFQ execution path for the Ratio FX platform. It covers how the protocol measures and limits the market risk that accumulates in the Reserve Pool as it absorbs inventory from the Active Pool between rebalancing cycles.
The Reserve Pool Risk Monitor builds directly on the two-phase rebalancing architecture established in the Phase 1 Technical Details. Phase 1 (internal settlement) gives the Active Pool instant solvency. Phase 2 (external clearance) clears the inventory the Reserve Pool has absorbed. The VaR monitoring system adds the risk monitoring layer that sits between these two phases — continuously evaluating whether the accumulated inventory risk is within acceptable limits, and triggering an emergency external clearance when it is not.
The Reserve Pool VaR system is a background process that runs independently of the FX Engine Quote Flow described in the FX Engine section. However, its outputs — specifically the PROTECT and RESTRICT signals — feed directly into the FX Engine State Engine. A VaR breach in the Reserve Pool will cause the State Engine to tighten or halt new quoting in the affected corridor, creating a direct link between back-office risk management and front-office quote generation.
2. Context — How Risk Accumulates in the Reserve Pool
To understand why VaR monitoring is necessary, it is important to understand the mechanics of how inventory risk builds up in the Reserve Pool across the two-phase rebalancing cycle.
2.1 The Two-Phase Rebalancing Recap
| Phase | Trigger | Mechanism | Risk Position After |
|---|---|---|---|
| Phase 1 — Internal Settlement | Hourly cron or deficit threshold breach | Reserve Pool sends USDT to Active Pool; takes IDRX from Active Pool at oracle rate via settleRebalance() | Reserve Pool holds IDRX inventory at WAOP cost basis. Active Pool is restored to solvency. Market risk transferred to Reserve. |
| Phase 2 — External Clearance | Daily cron or inventory limit reached | Off-chain bot aggregates all open batches; submits RFQ to Binance, Wintermute, or OTC; sells IDRX for USDT | Reserve Pool risk cleared. Realised PnL calculated vs WAOP. Batch closed. |
2.2 The Risk Window
Between Phase 1 and Phase 2, the Reserve Pool holds an open inventory position. The duration of this window is typically hours to one day under normal operating conditions. During this window, if the oracle mid-rate moves against the position, the protocol accumulates unrealised losses. If the position becomes large enough — due to high swap volume, a one-sided market, or a fast-moving rate — the unrealised loss can exceed the Reserve Pool's ability to absorb it without impairing LP capital.
This is the core risk that the VaR system addresses. It continuously measures how large this risk window has grown and triggers emergency external clearance before it reaches a level that could impair the pool.
2.3 Scenario Comparison — With and Without VaR Monitoring
| Scenario | Risk Effect | Without VaR Monitoring | With VaR Monitoring |
|---|---|---|---|
| High swap volume, USD-IDR one-sided for several hours | Reserve Pool accumulates large IDRX position at WAOP. IDR weakens vs USD by 0.8%. | Loss only discovered at daily rebalance. Spread income may not cover it. | VaR breach detected. Emergency RFQ triggered. Position cleared before loss worsens. |
| Bank Indonesia announces surprise rate cut | Oracle IDR rate moves 1.2% in 15 minutes. Reserve holds 3M IDRX. | Protocol continues quoting. Unrealised loss grows to $36,000 before daily cycle. | Drawdown check breaches 5% threshold. HALT for USD-IDR. Emergency RFQ dispatched immediately. |
| Normal trading, balanced flow | Reserve Pool accumulates modest IDRX position within expected bounds. | Daily rebalance clears at favourable rate. | VaR check passes green. No action. Normal daily rebalance proceeds. |
3. System Overview
The Reserve Pool VaR system consists of five sequential processing steps that run as a continuous background monitor. Steps 1 and 2 are purely analytical — they calculate the protocol's current risk exposure. Steps 3 and 4 evaluate that exposure against configured thresholds. Step 5 executes the appropriate response.
| Step | Name | Function |
|---|---|---|
| 1 | Reserve Pool Snapshot | Capture current inventory position, WAOP cost basis, oracle mid, and pool capital for each open batch per corridor |
| 2 | Exposure & Mark-to-Market Calculation | Calculate gross inventory exposure in USD terms; compute unrealised PnL vs WAOP for each corridor |
| 3 | VaR Calculation Engine | Compute 1-day VaR per corridor using Pyth confidence intervals (primary) and historical standard deviation (secondary); aggregate to portfolio level |
| 4 | Threshold Breach Evaluation | Evaluate four independent risk checks: Gross Exposure, VaR Limit, Concentration, and Drawdown; determine overall breach severity |
| 5 | Response Execution | No action (green), scheduled early rebalance (warning), or Emergency RFQ with RESTRICT signal (breach) |
3.1 Trigger Conditions
The monitor runs on three trigger conditions:
| Trigger | Frequency | Rationale |
|---|---|---|
| NewSwap event (on-chain) | Every executed swap | Each swap changes Reserve Pool inventory. Risk must be re-evaluated after every change. |
| settleRebalance() event (on-chain) | Every Phase 1 internal settlement | Internal settlement moves a batch of accumulated risk into the Reserve Pool at once — the largest single inventory change event. |
| 5-minute background cron | Every 5 minutes | Catches market movements that increase VaR even when no new swaps occur — e.g., IDR weakening while Reserve holds IDRX. |