Skip to main content
The Open Nile Protocol includes emergency mechanisms to protect users and pool liquidity when adverse conditions arise. The primary mechanism is the ModeController, which governs a state machine of operational modes.

​
Mode Escalation Path

The protocol operates in one of four modes, ordered by severity. Each mode progressively restricts which operations are permitted.
ModeSeverityOperations Allowed
NORMALLowestAll operations: open, increase, close, settle, liquidate, deposit, withdraw
DEGRADEDModerateNew positions and increases blocked. Closes, settlements, liquidations, deposits, and withdrawals allowed
REDUCE_ONLYHighSame restrictions as DEGRADED (opens and increases blocked). Signals a more severe protocol state
PAUSEDHighestAll operations blocked. No new positions, no modifications, no settlements, no liquidations, no deposits, no withdrawals
In PAUSED mode, all protocol operations are halted. This is reserved for critical situations where allowing any interaction could harm users or the protocol.

​
Mode Transitions

Only addresses with the ADMIN_ROLE can transition between modes, with one important exception.
1

Admin Escalation

The admin can escalate from any mode to a higher-severity mode (e.g., NORMAL to DEGRADED, or DEGRADED to PAUSED). This is used when the admin detects market conditions or protocol issues that warrant restricting operations.
2

Admin De-escalation

The admin can de-escalate from any mode to a lower-severity mode (e.g., PAUSED back to NORMAL). This is used during recovery after the root cause has been resolved.
3

Permissionless Auto-Pause

The checkOracleAndPause() function is permissionless — anyone can call it. If the oracle is detected as stale or invalid, the function automatically transitions the protocol to PAUSED mode. This allows the community to protect the protocol without waiting for admin intervention.

​
Auto-Pause via Oracle

The checkOracleAndPause() function is a critical safety mechanism:
  1. It queries the OracleModule to check whether the current price data is valid
  2. If the oracle returns invalid or stale data, the function transitions the protocol to PAUSED mode
  3. A ModeTransition event is emitted so off-chain monitoring can detect the change
Anyone can call checkOracleAndPause() at any time. If the oracle is healthy, the call is a no-op. If the oracle is stale or invalid, it triggers an automatic pause. This makes oracle-based protection fully decentralized.

​
Recovery from PAUSED

Recovering from PAUSED mode requires both administrative action and fresh oracle data:
1

Diagnose Root Cause

The admin identifies why the protocol was paused (oracle failure, market event, or detected vulnerability).
2

Restore Oracle Data

The publisher must provide fresh forward price data. Without valid oracle data, operations will fail even if the mode is changed back to NORMAL.
3

Admin De-escalates Mode

The admin transitions the protocol from PAUSED to NORMAL (or an intermediate mode like DEGRADED if a gradual reopening is preferred).
4

Operations Resume

All pending settlements and liquidations can execute once the mode returns to a permissive state. The keeper service will automatically process any backlog.

​
Current Limitations

The current emergency mechanism is admin-controlled. The following enhancements are planned for the M3 (Mainnet Ready) milestone to increase decentralization and safety.
A dedicated emergency shutdown module (similar to MakerDAO’s ESM) that allows token holders to trigger a full protocol wind-down if governance is compromised or unresponsive.
Mode transitions will require multi-sig approval rather than a single admin key, reducing the risk of unilateral action or key compromise.
Recovery from PAUSED mode will include a mandatory time-lock period, giving users time to review the situation before operations resume.
Off-chain monitoring infrastructure that automatically detects anomalies (unusual PnL, rapid utilization changes, oracle deviations) and alerts the operations team before manual intervention is needed.