Risk Engine

The oracle integration layer is the data ingestion component that fetches real-time market prices, liquidity data, and protocol-specific information from multiple sources. It is critical for accurate risk assessment, as it provides the price feeds and on-chain state data needed for all calculations. This layer often aggregates data from multiple oracles (e.g., Chainlink, Pyth) to mitigate manipulation risk and ensure data integrity. A failure in this layer can lead to catastrophic oracle price manipulation or stale data, resulting in incorrect liquidations or bad debt.

The risk parameter store is the central repository of configurable rules and thresholds that define the protocol's risk appetite. This includes:

• Loan-to-Value (LTV) Ratios: The maximum borrowing power against a collateral asset.
• Liquidation Thresholds: The LTV level at which a position becomes eligible for liquidation.
• Liquidation Penalties: The fee charged during a liquidation event.
• Asset Risk Classifications: Categorizations (e.g., 'stablecoin', 'volatile', 'unlisted') that determine collateral factors. These parameters are typically set and updated by governance or a dedicated risk committee based on market conditions.

This is the core computational module that continuously assesses the health of user positions (e.g., loans, leveraged trades). It takes inputs from the oracle layer and applies formulas from the risk parameter store to calculate key metrics:

• Health Factor / Collateral Ratio: A numerical representation of a position's safety, calculated as (Collateral Value * Collateral Factor) / Borrowed Value. A value below 1.0 indicates an undercollateralized, liquidatable position.
• Liquidation Price: For a given position, the price at which the collateral value falls to the liquidation threshold. This component must be highly performant to evaluate thousands of positions per block.

The liquidation engine is the enforcement mechanism that identifies and executes liquidations on unhealthy positions. It monitors the output of the Position Evaluator and, when a health factor falls below the threshold, triggers a liquidation event. Its key functions include:

• Liquidation Queueing: Prioritizing which positions to liquidate first (e.g., by largest shortfall).
• Liquidation Execution: Initiating transactions to seize collateral, repay debt, and distribute the liquidation penalty.
• Keeper Incentivization: Often relies on external keepers or bots to execute liquidations, offering them a bounty (the penalty) for their gas costs and effort.

This component provides real-time visibility into the aggregate risk state of the protocol for operators, governance, and sometimes users. It aggregates data to display metrics such as:

• Total Value Locked (TVL) and Total Borrowed.
• Protocol Health / Reserve Ratios: The amount of capital available to cover bad debt.
• Collateral Concentration: Exposure to any single asset.
• Historical Liquidations & Bad Debt. This dashboard is essential for proactive risk management and informed governance decisions regarding parameter updates.

A secure governance and upgrade mechanism allows for the adjustment of the risk engine's logic and parameters without introducing centralization risks or requiring a hard fork. This is typically implemented via:

• Timelocks: A mandatory delay between a governance vote passing and its execution, allowing users to react to parameter changes.
• Multisig Wallets: Controlled by a committee for emergency pauses or critical updates.
• On-chain Voting: Using governance tokens to vote on parameter proposals. This component ensures the risk engine can adapt to new market conditions, asset listings, and attack vectors in a transparent, decentralized manner.

A risk engine integrates several key modules: a collateral valuation oracle for real-time price feeds, a liquidation module to trigger margin calls, a risk parameter framework (e.g., Loan-to-Value ratios, health factors), and a market data aggregator for volatility and liquidity analysis. These components work together to assess the solvency of positions continuously.

When a user's collateral value falls below a predefined threshold (e.g., health factor < 1), the risk engine initiates a liquidation. This involves:

• Auction-based sales (e.g., Dutch auctions in MakerDAO)
• Fixed discount sales (common in lending protocols)
• Liquidation bots competing to repay debt for a portion of the collateral

The goal is to repay the undercollateralized loan before the protocol incurs bad debt.

Risk engines are heavily dependent on price oracles. Key vulnerabilities include:

• Oracle manipulation via flash loans to create false price feeds
• Latency issues causing stale prices during volatile markets
• Centralized oracle failure as a single point of failure Protocols mitigate this using decentralized oracle networks (e.g., Chainlink), time-weighted average prices (TWAPs), and circuit breakers.

Risk parameters are not static; they are set and adjusted via decentralized governance. This includes:

• Collateral factors and debt ceilings for different assets
• Liquidation penalties and close factor limits
• Stability fee adjustments Poor parameterization (e.g., overly aggressive LTV) can lead to mass liquidations or, conversely, allow dangerous levels of undercollateralization.

Risk engines must account for systemic risk where correlated asset crashes or liquidity crunches can overwhelm the system. Examples include:

• Cascading liquidations driving prices down further (debt spiral)
• Liquidity pool insolvency affecting collateral valuation
• Protocol interdependence where one failure triggers others (e.g., the UST/LUNA collapse) Stress testing and circuit breakers are critical defenses.