Risk Management

Kaskad is designed around over-collateralization, bounded risk parameters, and partial liquidations. Every risk-related setting is adjustable by governance only within predefined safety ranges.

Core Risk Model

All borrowing on Kaskad is over-collateralized. Users must deposit more value than they borrow, and the protocol continuously monitors position health to ensure solvency.

The risk model is defined per asset, reflecting the specific volatility, liquidity depth, and oracle reliability of each supported token.

Risk Parameters per Asset

Each asset has three key risk parameters:

Loan-to-Value (LTV)

The LTV ratio defines the maximum borrowing power against a given collateral asset.

Example: An asset with 70% LTV allows a user who deposits $1,000 to borrow up to $700 in other assets.

LTV is adjustable by governance within ±5% of the default, with a hard floor of 15%. Governance cannot set LTV to 0% (which would disable borrowing) or to unsafe levels.

The liquidation threshold defines the point at which a position becomes eligible for liquidation. It is always set higher than or equal to the LTV ratio, creating a safety buffer between maximum borrowing and liquidation.

Example: LTV of 70% with a liquidation threshold of 75% means a user can borrow up to 70%, and only gets liquidated if their collateral ratio drops to 75% (due to price movements).

Liquidation Penalty

The liquidation penalty is the bonus paid to liquidators for executing a liquidation. It compensates for gas costs and execution risk. The penalty is deducted from the borrower's collateral — a portion goes to the liquidator and the remainder is routed to the protocol treasury.

Liquidation Design

Kaskad uses partial liquidations exclusively:

Only enough debt is repaid to restore the Health Factor above 1.0
Borrowers retain the remainder of their collateral and position
Full position closures do not occur — this protects users from total collateral loss due to temporary price volatility

Liquidations are permissionless: any external actor can trigger them, ensuring the system does not depend on a centralized keeper or operator.

Health Factor Monitoring

The Health Factor is the primary indicator of position safety:

HF = (Risk-adjusted collateral value) / (Total debt value)

Users should monitor their Health Factor and take action if it approaches 1.0. Options include adding collateral, repaying part of the debt, or switching to a lower-volatility collateral asset.

The protocol roadmap includes automated repayment and re-collateralization features (planned for 2026) to help users manage positions more actively.

Bounded Risk Governance

All risk parameters are governed within bounded ranges:

Governance can propose changes to LTV, liquidation threshold, and liquidation penalty per asset
Changes must stay within the predefined adjustable range
Hard floors and ceilings are enforced at the contract level
Proposals go through the standard governance lifecycle: snapshot, voting period, 48h timelock, 24h challenge window

This means governance can respond to changing market conditions (e.g., tightening parameters for a volatile asset) without the ability to introduce unsafe configurations.

Full governance details

Cross-Chain Risk Considerations

Cross-chain operations via Hyperlane introduce additional risk factors:

Oracle latency — price feeds for cross-chain assets may have marginally higher latency than native assets. Risk parameters for cross-chain assets account for this with wider safety buffers.

Bridge message delay — if a user's position becomes liquidatable while a cross-chain message is in transit, there is a window during which the liquidation may not execute optimally. The protocol's liquidation penalty includes a buffer to account for this scenario.

Relayer risk — the reliability of cross-chain liquidation execution depends on Hyperlane relayer uptime. Backup mechanisms and redundant relayer infrastructure mitigate this risk.

Users who interact with Kaskad cross-chain should maintain more conservative Health Factors (1.5+ recommended) compared to native Igra users.