Risk Engine

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

Research support: Risk model design is informed by Base58 Labs Research Institute.

Accounting convention: Limits, PnL, and dashboard values may be shown in USDT-equivalent units for internal accounting and display. USDT is not a deposit or withdrawal asset on BASIS. Supported native assets are BTC, ETH, SOL, and PAXG.

The Risk Engine is the deterministic control layer that protects execution precision and structural alpha capture across the BASIS platform. It evaluates every proposed order before routing, monitors active positions after submission, and reconciles outcomes after completion.

It operates alongside BHLE, BASIS High-Load Execution, which provides sub-50μs internal decision latency, 100K+ OPS capacity, and proprietary routing infrastructure. No order reaches a venue unless it passes the engine's eligibility gate.

---

1. Design model: fail closed by default

The Risk Engine follows a default-deny model. Every trade begins in a rejected state and is promoted to approved only after all required checks succeed.

This fail-closed design matters for three reasons:

• Missing data results in rejection, not silent acceptance

• New or unclassified risk conditions do not bypass controls

• State transitions remain deterministic and auditable

If any required input is stale, unavailable, or internally inconsistent, the engine rejects the order and records the reason.

NORMAL
  -> pre-trade checks pass
  -> route order
  -> monitor fills and exposure
  -> reconcile balances and PnL
  -> NORMAL

NORMAL
  -> critical threshold breach
  -> BSCB
  -> DMM if automated recovery is insufficient

2. Eligibility gate

Before an order is submitted to any venue, the engine evaluates the following controls in sequence.

Check	What is tested	Failure action
System state	Is the platform in NORMAL state, with no active BSCB or DMM restriction?	Reject: system not in executable state
Market data integrity	Are reference prices, books, and internal signals fresh and internally consistent?	Reject: invalid or stale market data
Venue health	Is the target venue reachable, responsive, and within latency bounds?	Reject: venue health check failed
Venue allocation	Would the order push venue concentration beyond the configured cap?	Reject: venue allocation limit reached
Asset exposure	Would net exposure to a single asset exceed policy limits?	Reject: asset concentration limit reached
Margin sufficiency	For leveraged legs, is there enough margin buffer above maintenance thresholds?	Reject: insufficient margin buffer
Impact estimate	Is expected slippage and book impact within execution precision limits?	Reject: estimated impact too high
Structural alpha viability	After fees, expected slippage, and network costs, is the expected edge still positive?	Reject: expected edge not viable after costs
Reconciliation status	Has the most recent reconciliation completed with no unresolved discrepancy?	Reject: reconciliation lock active

3. In-flight monitoring

Once an order is live, the engine continues to supervise it in real time.

Positions

• Margin health monitoring tracks open leveraged positions against warning and critical thresholds

• Hedge integrity checks verify that paired legs remain within allowed deviation bands

• Exposure drift checks detect inventory changes caused by partial fills, funding, or venue-side adjustments

Orders

Escalation

4. Post-trade reconciliation

Every execution cycle ends with a mandatory reconciliation pass.

1

Balance verification

Venue balances are checked against the internal ledger. Any discrepancy is flagged immediately.

2

PnL attribution

Realized profit and loss is attributed to the originating strategy, venue, and execution path.

3

Cost accounting

Exchange fees, network fees, funding, borrow costs, and other direct execution costs are deducted from gross results.

4

State confirmation

The system confirms that all expected state transitions completed correctly before new exposure is permitted.

Reconciliation is not a reporting convenience. It is a hard risk control. If reconciliation does not complete cleanly, the engine can block new orders until the discrepancy is resolved.

5. Relationship to BSCB and DMM

The Risk Engine is the detection and decision layer. BSCB is the automated containment layer. DMM is the operator-supervised escalation layer for conditions that require discretionary review.

A practical hierarchy is:

• Risk Engine, detect and evaluate

• BSCB, contain automatically

• DMM, supervise recovery or exceptional handling

6. Why this matters

The BASIS risk model is built around deterministic execution, explicit mathematical constraints, and state machine risk controls. This architecture supports structural alpha capture without relying on permissive routing or manual intervention during normal operation.

In operational terms, the objective is simple:

• approve only what is safe to execute

• reject anything ambiguous

• reconcile every completed action

• escalate only through defined state transitions