Risk Model: States, Triggers, Protections
Operator and jurisdiction: BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC (LEI: 254900IX2F2KCWNSSS64).
Research Partner: Base58 Labs contributes execution research, systems modeling, and risk design.
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.
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
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.
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.
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.
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.
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.
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.
3) Protection logic
When a trigger fires, protections are applied automatically according to severity and scope.
Step 1: Detect and classify
The system validates the trigger, assigns severity, and determines whether the issue is local, scoped, or systemic.
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.
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.
Step 4: Resume only after validation
Normal operation resumes only after post-incident checks, ledger reconciliation, venue health confirmation, and control validation are complete.
Protection behavior by state
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
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.)
4) Control philosophy
The BASIS risk model is based on three principles:
Deterministic execution over discretionary reaction The system should respond to stress through pre-validated rules, not improvised operator judgment.
Math constraints over narrative assumptions Positioning, routing, and exposure management must stay within quantified tolerances.
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.
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.
Last updated
