> For the complete documentation index, see [llms.txt](https://candora.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://candora.gitbook.io/whitepaper/candora-grid/risk-engine.md). # Risk Engine ### Real-Time Risk Computation and Solvency Management Layer Candora Risk Engine is the solvency, exposure, and risk-management layer of Candora Grid. It is responsible for continuously evaluating account risk, enforcing margin requirements, coordinating liquidations, and maintaining systemic solvency across the exchange environment. Risk Engine serves as the authoritative solvency layer of the Grid. Every leveraged position, collateralized account, margin calculation, liquidation decision, and exposure constraint ultimately depends on Risk Engine as the definitive source of risk-state evaluation. Unlike traditional exchange risk systems that rely on periodic recalculation and isolated account checks, Risk Engine operates as a continuously updated computation framework. Changes originating from Pulse, Orbit, Oracle, and Vault are incorporated as they occur, allowing solvency state to evolve alongside market conditions, execution activity, pricing changes, and collateral movements. At a high level, Risk Engine continuously balances account solvency, collateral integrity, leverage management, liquidation containment, liquidity awareness, and overall system stability while preserving deterministic behavior and replay consistency across all operating conditions. ### Risk State Model Risk state is represented as a structured multi-dimensional object rather than a single leverage ratio: ``` R_a(t) = { exposure_vector, collateral_vector, margin_state, liquidation_buffer, correlation_state, stress_sensitivity } ``` Each component evolves independently while remaining linked through shared solvency constraints. This structure allows Risk Engine to evaluate directional exposure concentration, collateral fragmentation, liquidity-adjusted leverage, correlation sensitivity, liquidation-chain exposure, and stress-conditioned solvency risk simultaneously rather than reducing solvency assessment to a single leverage metric. Each account remains synchronized with Orbit execution state, Pulse market-state updates, Oracle valuation state, and Vault collateral state, ensuring risk calculations remain consistent throughout live operation, replay, and recovery. ### Multi-Layer Margin Framework Risk evaluation is structured around three interacting margin layers: ``` IM = f(notional, volatility, liquidity_depth) MM = IM × maintenance_factor SM = VaR_99.9 + liquidity_haircut + gap_risk ``` Initial Margin governs position admission, Maintenance Margin governs ongoing position health, and Stress Margin provides additional protection during extreme market conditions. These requirements are dynamic rather than static. Margin requirements continuously adapt to market volatility, liquidity conditions, changing correlation behavior, and the shared stress state of the platform. As market conditions deteriorate, initial margin requirements may increase, maintenance thresholds may tighten, stress margins may expand, and effective leverage capacity may compress. This allows the platform to reduce aggregate leverage before instability develops into solvency failure. Margin requirements are continuously visible through trading interfaces and reflect the current risk state produced by Risk Engine. Because requirements respond to changing liquidity, volatility, and stress conditions, they may change while positions remain open. All adjustments are governed through predefined risk policies and deterministic control logic rather than discretionary intervention. As conditions normalize, requirements may gradually return toward baseline levels. Participants operating within the same market and risk regime remain subject to the same underlying margin framework. Risk Engine may additionally consume bounded analytical telemetry produced by Cortex to support solvency analysis and systemic-risk monitoring. Such telemetry remains advisory and cannot independently trigger liquidations or override rule-based risk controls. ### Correlation and Regime Adaptation Risk Engine treats correlation as a dynamic market characteristic rather than a fixed historical assumption. During stable market conditions, diversification benefits remain available. During stressed conditions, correlation assumptions become increasingly conservative: ``` AdjustedExposure = NetExposure × CorrelationStressFactor ``` This allows portfolio risk to reflect changing market dependencies rather than static historical relationships. The engine continuously evaluates cross-asset correlation, volatility synchronization, liquidity contagion behavior, exposure concentration, funding-rate instability, and liquidation overlap probability in order to determine whether diversification assumptions remain reliable. As diversification reliability decreases, effective exposure increases and leverage capacity contracts automatically. This prevents excessive leverage expansion during unstable market regimes while preserving more efficient capital utilization during stable conditions. ### Reactive Risk Computation Architecture Risk computation is implemented as a reactive dependency graph rather than a sequential calculation pipeline: ``` ΔRisk = (∂Risk/∂Price × ΔPrice) + (∂Risk/∂Position × ΔPosition) + (∂Risk/∂Collateral × ΔCollateral) + (∂Risk/∂Stress × ΔStress) ``` Only affected portions of the graph are recomputed when state changes occur. This architecture enables low-latency recomputation, high throughput, deterministic replay behavior, and efficient resource utilization without requiring full portfolio recalculation for every state change. The computation graph remains synchronized with Pulse market-state events, Orbit execution activity, Oracle valuation updates, and Vault collateral changes, creating a continuously updated solvency model across the Grid. ### Shared Stress-State Integration Risk Engine consumes the shared stress state defined by Candora's [Operational Model](/whitepaper/candora-grid/operational-model.md) and incorporates it directly into margin computation, leverage controls, liquidation pacing, and ongoing solvency monitoring. As systemic stress increases, Risk Engine may expand margin requirements, increase liquidation buffers, reduce effective leverage capacity, and tighten solvency constraints according to predefined risk policies. Risk Engine also exports telemetry used in the computation of the shared stress state, including margin utilization, liquidation activity, leverage concentration, and collateral stress indicators. This allows solvency conditions to contribute to broader infrastructure awareness while preserving clear separation of responsibility between subsystems. The result is a coordinated framework in which risk conditions influence platform behavior while remaining governed by deterministic and transparent control policies. ### Liquidation Framework Liquidation is treated as a controlled risk-reduction process rather than a binary enforcement event. When positions violate solvency requirements, Risk Engine determines the required reduction in exposure while Orbit remains responsible for execution. This separation ensures that solvency logic and execution logic remain independent while operating in a synchronized manner. Liquidation activity may incorporate partial deleveraging, execution slicing, liquidity-aware pacing, and dynamic reduction scheduling. The objective is to reduce insolvency risk while minimizing unnecessary market disruption and avoiding destabilizing liquidity shocks. Risk Engine defines solvency targets and reduction requirements. Orbit executes liquidation orders according to current market conditions and execution rules. This separation preserves both risk integrity and execution neutrality. ### Pre-Trade and In-Trade Risk Enforcement Risk enforcement operates continuously throughout the order lifecycle rather than existing as a single validation checkpoint. Before orders enter Orbit, Risk Engine evaluates projected leverage impact, margin sufficiency, collateral availability, stress-adjusted exposure levels, and liquidity-sensitive constraints. Only orders satisfying applicable solvency requirements are permitted to proceed into execution. During execution, Risk Engine continuously monitors changing market conditions and updates internal risk state accordingly. After execution, exposure updates propagate throughout Candora Grid, ensuring synchronization between risk state, market state, valuation state, and financial state. This creates a continuously updated solvency framework operating alongside execution and settlement activity while maintaining consistency across the broader infrastructure. ### Deterministic Replay and Recovery All risk-state transitions are recorded as replayable event streams. Risk reconstruction supports restoration of historical solvency states, exposure evolution, margin transitions, liquidation activity, and collateral-state changes. Recovery follows: ``` R_recovered = R_snapshot + Σ Δrisk_events ``` Because risk-state evolution is deterministic, reconstructed state remains consistent with original system behavior. This enables auditing, simulation, debugging, forensic analysis, and recovery without requiring approximation of prior risk conditions. ### System Role Summary Candora Risk Engine serves as the authoritative solvency layer of Candora Grid. It coordinates exposure computation, margin management, leverage controls, liquidation requirements, collateral risk evaluation, and solvency-state synchronization across the exchange environment. All leverage control, solvency enforcement, margin management, liquidation coordination, and risk-state computation within Candora Grid ultimately originate from Risk Engine, making it the foundational solvency layer of the exchange infrastructure.