Step 5 — Response Execution & Emergency RFQ
Step 5A — Green Path — Normal Scheduled Rebalance
When all four checks are within normal bounds, no emergency action is taken. The Reserve Pool continues accumulating inventory in the current open batch. The normal daily rebalancing cycle proceeds on schedule. The monitor loop resets and the next evaluation is triggered by the next NewSwap event, settleRebalance() event, or 5-minute cron — whichever comes first.
Step 5B — Warning Path — Scheduled Early Rebalance
When one or more checks breach the WARNING threshold but none breach the BREACH threshold, the system takes a measured response designed to reduce risk in an orderly manner without disrupting user experience.
| Action | Description |
|---|---|
| PROTECT signal sent to FX Engine | State Engine for the affected corridor is upgraded to PROTECT. Spread is widened and maximum quote size is reduced. Both directions still permitted — the goal is to discourage new inventory accumulation without blocking users. |
| Current batch closed early | The open rebalancing batch for the affected corridor is flagged as ready for external clearance. It will be submitted to the next available RFQ window rather than waiting for the standard daily cycle. |
| Early rebalance window scheduled | The system schedules an external RFQ submission at the next available window (typically within 1–4 hours rather than waiting for end of day). This is an orderly acceleration, not an emergency. |
The warning path is intentionally non-disruptive. Widening the spread discourages the flow that is creating the imbalance (e.g., one-sided USD-to-IDR selling) without rejecting it outright. This gives the protocol time to reduce inventory risk through normal market forces before escalating to an emergency. In most cases, the warning path is sufficient — the batch clears at the next scheduled window and the position normalises.
Step 5C — Breach Path — Emergency RFQ
When one or more checks breach the BREACH threshold, the system immediately transitions to the Emergency RFQ path. This is a time-critical response designed to exit the position as quickly as possible at an acceptable price.
This is the protocol's last line of defence before HALT. The Emergency RFQ path is designed to clear dangerous inventory positions as quickly as possible while still maintaining a price floor to prevent catastrophic losses.
| Step | Action | Detail |
|---|---|---|
| 1. RESTRICT Signal | State Engine set to RESTRICT for affected corridor | One-way quotes only (direction that reduces inventory). Maximum spread applied. New inventory accumulation effectively halted. |
| 2. RFQ Preparation | Aggregate all open batches for the corridor; calculate total inventory to clear; set clearing price floor | Price Floor = WAOP minus Emergency Tolerance. Emergency Tolerance is a configurable bps offset representing the maximum loss the protocol is willing to accept to exit the position quickly. Default: 50 bps below WAOP. |
| 3. Emergency RFQ Dispatch | Send RFQ simultaneously to all configured MMs with shortened timeout | Timeout: 60 seconds (vs standard 300 seconds). Recipients: Binance, Wintermute, OTC partners. All quotes must be above the price floor to be accepted. |
| 4. Quote Evaluation | Accept best quote above price floor | Best quote = highest IDR rate received for IDRX sell. If multiple quotes above floor, accept the highest. |
| 5. Execution | Execute external clearance immediately | Do not wait for daily batch window. USDT proceeds returned to Reserve Pool. On-chain EmergencyRebalanceExecuted event emitted. Ops team notified via configured alert channel. |
Emergency RFQ Escalation
If the Emergency RFQ returns no quotes above the price floor, or if the timeout expires with no response, the system escalates through a defined retry sequence.
| Retry Attempt | Tolerance Adjustment | Action |
|---|---|---|
| Attempt 1 (initial) | WAOP minus 50 bps | Standard emergency dispatch. 60-second timeout. |
| Attempt 2 (1st retry) | WAOP minus 100 bps | Widen tolerance by 50 bps. Accept larger loss to exit. 60-second timeout. |
| Attempt 3 (2nd retry) | WAOP minus 200 bps | Widen tolerance further. Accepting significant loss to exit emergency position. 60-second timeout. |
| No quote after 3 attempts | Position cannot be cleared | Corridor upgraded to HALT state. Active Pool paused for that corridor. On-call ops team paged immediately for manual intervention. |
The escalation logic accepts progressively larger losses to exit the position because the alternative is worse. Holding a large EM currency position during a stressed market while hoping for a better price is speculative behaviour that Ratio explicitly does not want. The Reserve Pool's job is to hold inventory risk for hours, not days. If no market maker will quote within 200 bps of WAOP during an emergency, the position is illiquid and requires human judgment — hence the HALT and ops escalation.
Post-Clearance Processing & State Recovery
Realised PnL Recording
Immediately after Emergency RFQ execution, the system calculates and records the realised PnL for the cleared batches.
Realised PnL = (Executed Rate − WAOP) × Volume
| Outcome | Condition | Accounting Treatment |
|---|---|---|
| Rebalancing Profit | Executed Rate > WAOP | Surplus added to Reserve Pool capital. Contributes to long-term pool growth. |
| Rebalancing Loss (COGS) | Executed Rate < WAOP | Loss deducted from Reserve Pool capital. Must be covered by spread income collected across the batch window. Triggers COGS analysis report. |
| Break-Even | Executed Rate = WAOP | No net gain or loss on inventory. Spread income from the batch is pure protocol revenue. |
Reserve Pool Restoration Check
After clearance, the system evaluates whether the Reserve Pool has been restored to a healthy operating state. Two conditions must be met for a clean restoration: the Reserve Pool USDT balance must be above the 80% minimum liquidity threshold ($4M of $5M max capacity), and gross inventory exposure must have returned to within the normal Check 1 band (below 70% of capacity).
| Condition After Clearance | State Restored To | Rationale |
|---|---|---|
| All four VaR checks now green; Reserve above 80% minimum | NORMAL | Full restoration. Normal quoting resumes immediately. |
| VaR checks green but Reserve below 80% minimum (capital depleted by loss) | PROTECT | Pool is safe but capital is reduced. Spread and size limits kept tighter while Reserve rebuilds. |
| One or more checks still in warning band after clearance | PROTECT | Partial clearance only, or market still stressed. Keep monitoring. |
| Manual ops override | Any state | Ops team can manually set state after reviewing the situation. |
FX Engine State Recovery
Once the restoration check passes, the FX Engine state for the affected corridor is restored based on the current overall system health. A CorridorStateRestored event is emitted on-chain.
On-Chain Audit Events
The following on-chain events are emitted by the Reserve Pool VaR system. These events provide a complete audit trail for all risk monitoring decisions and emergency actions, and are the authoritative record for post-incident analysis and regulatory reporting.
| Event | Trigger | Data Captured |
|---|---|---|
VaRBreachDetected | Any threshold check reaches WARNING or BREACH level | corridor, breach_type (exposure/var/concentration/drawdown), breach_level (WARNING/BREACH), var_amount_usd, capital_ratio_pct, waop, current_oracle_mid, timestamp |
EarlyRebalanceScheduled | Warning path activated | corridor, batch_ids[], total_inventory, waop, scheduled_window, trigger_reason, timestamp |
EmergencyRFQDispatched | Breach path activated | corridor, batch_ids[], total_inventory_units, waop, price_floor, attempt_number, mm_recipients[], timeout_seconds, timestamp |
EmergencyRebalanceExecuted | Emergency RFQ quote accepted and executed | corridor, batch_ids[], executed_rate, waop, volume, realised_pnl_usd, mm_counterparty, tx_hash, timestamp |
EmergencyRFQFailed | All retry attempts exhausted with no viable quote | corridor, attempt_count, final_tolerance_bps, state_set_to (HALT), timestamp |
CorridorStateRestored | State recovery check passes after clearance | corridor, previous_state, new_state, reserve_balance_usd, var_pct, timestamp |