Risk Model: States, Triggers, Protections

Operator and jurisdiction: BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC (LEI: 254900IX2F2KCWNSSS64).

Research framework: strategy research, validation, and systems design are supported by Base58 Labs, referenced in BASIS materials as a Research Partner.

Accounting convention: portfolio values are displayed in USDT-equivalent terms for internal accounting and reporting only. USDT is not a depositable or withdrawable asset on BASIS. Deposits and withdrawals use native assets only, including BTC, ETH, SOL, and PAXG.

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

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.

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.

Venue triggers

Asset and accounting triggers

Internal system triggers

---

3) Protection logic

When a trigger fires, protections are applied automatically according to severity and scope.

1

Step 1: Detect and classify

The system validates the trigger, assigns severity, and determines whether the issue is local, scoped, or systemic.

2

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.

3

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.

4

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

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

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 are 30 minutes to 1 hour for BTC and 1 to 6 minutes for ETH, SOL, and PAXG.

---

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.