# Risk Model: States, Triggers, Protections {% hint style="info" %} Operator and jurisdiction: BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC (LEI: [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64)). Research Partner: Base58 Labs contributes execution research, systems modeling, and risk design. {% endhint %} A platform risk model is its immune system. It defines how the system behaves under stress and is the primary control layer for capital preservation. At BASIS, the risk model is implemented as a deterministic state machine. It is designed to protect structural alpha capture by enforcing strict transitions, measurable triggers, and automated controls. This design works alongside BHLE execution infrastructure, including sub-50μs internal latency targets, 100K+ OPS capacity, and proprietary routing logic built for execution precision. This is not a theoretical framework. It is an engineering specification for a survivable system. *** ## 1) State hierarchy The system operates in one of three states. | State | Name | Description | System action | | ------ | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- | | Normal | Normal Operating Mode | All monitored systems are healthy. Eligible opportunities may be routed and executed within risk limits. | Execute approved activity | | BSCB | Basis Sentinel Circuit Breaker | A defined trigger has been activated for a specific asset, venue, route, or module. The system enters a protective pause for the affected scope. | Stop new entries in affected scope | | DMM | Defensive Maintenance Mode | A severe, systemic, or unknown condition has been detected. Automated activity is halted until operator review and root cause analysis are complete. | Halt all automated activity | {% hint style="success" %} Why a state machine matters 🛡️ A deterministic state model improves auditability, reduces discretionary decision risk, and ensures that capital protection rules are applied consistently across market regimes. {% endhint %} ## 2) Trigger categories Triggers are specific, measurable conditions that cause a state transition. They encode known failure modes and define the system response in advance. {% tabs %} {% tab title="Market triggers" %} * Extreme volatility\ Realized volatility in a core asset, such as BTC, exceeds a predefined threshold over a short interval. * Execution precision inversion\ Estimated execution costs persistently exceed the expected structural alpha available across routes or venues. * Funding rate dislocation\ Funding rates become unstable, invert sharply, or diverge from historical ranges in a way that signals market stress. * Cross-venue basis shock\ The spread between reference venues widens beyond tolerance, increasing routing and hedge risk. {% endtab %} {% tab title="Venue triggers" %} * Deposit or withdrawal halt\ A major venue disables deposits or withdrawals for a relevant asset. * API instability\ Response latency, error rates, or order acknowledgement quality deteriorate beyond operational thresholds. * Abnormal pricing\ A venue price feed diverges materially from the global reference, suggesting internal issues, stale data, or market impairment. * Settlement degradation\ Transfer confirmation patterns, settlement behavior, or custody acknowledgements become inconsistent with baseline expectations. {% endtab %} {% tab title="Asset and accounting triggers" %} * PAXG basis dislocation\ PAXG market pricing diverges materially from reference gold pricing or exhibits sustained abnormal basis behavior. * Native asset chain stress\ BTC, ETH, SOL, or PAXG transfer conditions indicate abnormal confirmation delays, network instability, or elevated settlement risk. * Display-unit divergence\ The USDT/USD display basis moves outside internal tolerance. This affects reporting and accounting alerts only. It does not change the native-asset custody model. * Liquidity compression\ Available executable depth falls below minimum thresholds for safe routing or hedge maintenance. {% endtab %} {% tab title="Internal system triggers" %} * Margin buffer breach\ The safety buffer on a hedged or derivative-linked position falls below a critical threshold. * Reconciliation failure\ Internal ledgers, venue balances, and position records fail to reconcile within tolerance. * State integrity fault\ A control-plane inconsistency, sequencing error, or state transition mismatch is detected. * Risk control timeout\ A required kill-switch, limit update, or exposure reduction action does not complete within the allowed window. {% endtab %} {% endtabs %} *** ## 3) Protection logic When a trigger fires, protections are applied automatically according to severity and scope. {% stepper %} {% step %} **Step 1: Detect and classify** The system validates the trigger, assigns severity, and determines whether the issue is local, scoped, or systemic. {% endstep %} {% step %} **Step 2: Enter BSCB when the issue is scoped** If the condition is isolated to a route, asset, venue, or module, BASIS enters BSCB for that scope. New entries are blocked immediately. Existing exposure may be reduced if the condition persists. {% endstep %} {% step %} **Step 3: Enter DMM when the issue is systemic or unknown** If the condition threatens system-wide integrity, or if the failure mode is not fully classified, BASIS enters DMM. All automated activity stops and operator review begins. {% endstep %} {% step %} **Step 4: Resume only after validation** Normal operation resumes only after post-incident checks, ledger reconciliation, venue health confirmation, and control validation are complete. {% endstep %} {% endstepper %} ### Protection behavior by state | State | New entries | Existing exposure | Automation | Human review | | ------ | -------------------------- | ------------------------------------------------- | -------------------- | ------------ | | Normal | Allowed within limits | Managed normally | Active | Not required | | BSCB | Blocked for affected scope | Reduced if required by policy | Partially restricted | Conditional | | DMM | Fully blocked | Frozen or reduced according to emergency protocol | Halted | Required | {% hint style="warning" %} Customer impact During BSCB or DMM, funding and settlement workflows may be delayed if a relevant chain, venue, or risk-control dependency is affected. Under normal conditions, typical withdrawal processing targets from the Funding Wallet are 10 to 60 minutes for BTC and 1 to 10 minutes for ETH, SOL, and PAXG. (Note: Unstaking from fixed pools requires an additional 7-day buffer before these withdrawal times apply.) {% endhint %} *** ## 4) Control philosophy The BASIS risk model is based on three principles: 1. Deterministic execution over discretionary reaction\ The system should respond to stress through pre-validated rules, not improvised operator judgment. 2. Math constraints over narrative assumptions\ Positioning, routing, and exposure management must stay within quantified tolerances. 3. State machine risk controls over ad hoc overrides\ Every material protection action should be attributable to a clear trigger and an auditable transition. This approach is consistent with high-reliability systems, where the cost of uncontrolled failure is unacceptable. ``` if trigger.severity == "critical" or trigger.classification == "unknown": state = DMM halt_all_automation() alert_operators() elif trigger.scope in ["asset", "venue", "route", "module"]: state = BSCB block_new_entries(trigger.scope) reduce_exposure_if_required(trigger.scope) else: state = Normal ``` *** ## 5) Why this matters BASIS does not rely on a single defense. Capital protection depends on layered controls: * deterministic state transitions * reconciliation and ledger integrity checks * venue and chain health monitoring * routing constraints for execution precision * automated kill-switches and exposure reduction logic * operator review before restart after severe incidents The result is a system designed to preserve capital first and pursue structural alpha only inside clearly defined risk boundaries. *** ### References \[1] Weick, K. E., & Sutcliffe, K. M. (2007). Managing the Unexpected: Resilient Performance in an Age of Uncertainty. Jossey-Bass. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.basis.pro/whitepaper/risk-model.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.