Architecture Overview

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

BASIS is a distributed execution platform, not a monolithic application. The system is engineered for structural alpha capture with deterministic execution, high-throughput event processing, and tightly bounded operational risk. Its architecture is designed to support an institutional-grade operating model with traceable controls, disciplined service delivery, and publicly verifiable international certifications.

Core infrastructure targets include:

• Sub-50μs internal routing latency in the BHLE layer

• 100K+ OPS across ingest, signal, execution, and ledger services

• Proprietary routing infrastructure across centralized and onchain venues

• Deterministic replay from immutable event logs

• State-machine risk controls with hard veto and isolation paths

This page summarizes the major building blocks.

Data plane

Market data ingestion → normalization → signal generation → execution orchestration → reconciliation

Control plane

1) Core design philosophy

BASIS uses an event-driven, event-sourced architecture. Services publish and consume immutable events instead of relying on direct point-to-point calls.

Typical events include:

OrderBookUpdate
TradeExecuted
HedgeCompleted
WithdrawalRequest
LedgerPosting
RiskStateChanged

This model provides:

• Resilience: Loose coupling reduces fault propagation

• Scalability: Event streams can be partitioned and processed in parallel

• Auditability: The log is a time-ordered record suitable for replay, verification, and compliance review

• Determinism: Historical behavior can be reconstructed from the event sequence

These properties also support the operational control objectives expected of institutional-grade platforms, including traceability, repeatability, and controlled service delivery under the active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications held by BASIS DIGITAL INFRASTRUCTURE LTD.

2) Component pipeline ⚙️

The production path is organized as a deterministic pipeline.

1

Data ingestion

Collect, normalize, timestamp, and sequence venue data.

2

Signal generation

Convert normalized market state into structural alpha signals with explicit cost and confidence estimates.

3

Execution orchestration

Route and coordinate orders with execution precision and hedge-completion controls.

4

Risk gating

Apply state-machine checks, exposure limits, and venue health controls before any action is allowed.

5

Accounting and reconciliation

Post every state transition to the ledger and verify balances continuously.

Layer	Primary role	Key properties
Data pipeline	Ingest and normalize venue data	Low jitter, venue adapters, schema normalization
Signal layer	Generate structural alpha signals	Cost-aware scoring, confidence weighting, regime filters
Execution layer	Route and coordinate orders	Execution precision, hedge completion, failover
Risk engine	Enforce hard constraints	State-machine controls, venue halts, exposure caps
Accounting layer	Maintain balances and P&L	Deterministic ledger, continuous reconciliation

2.1) Data pipeline

Function:

• Ingest real-time market data from centralized and onchain venues, including order books, trades, quotes, and venue health signals

• Normalize heterogeneous venue formats into a consistent internal schema

• Timestamp and sequence messages for replay and latency analysis

Implementation characteristics:

• Low-latency WebSocket and API connectivity

• Data-oriented implementation in performance-focused languages such as C++ and Rust

• Kernel-bypass and packet-path optimization where appropriate

• Backpressure controls to preserve system stability under burst load

2.2) Signal and alpha generation

Function:

• Convert normalized data into executable structural alpha signals

• Evaluate spread quality, expected edge, impact costs, and completion probability before any order is formed

Signals are not simple price-gap alerts. A valid signal carries:

• Expected edge after fees and slippage

• Estimated completion cost

• Confidence score

• Venue and inventory constraints

• Time-sensitivity and decay characteristics

This layer reflects ongoing research conducted with Base58 Labs as a Research Partner.

2.3) Execution orchestration

Function:

• Transform approved signals into concrete order instructions

• Manage placement logic, slicing, hedge sequencing, and venue-specific routing behavior

Execution priorities:

• Precision: Minimize timing drift between related legs

• Completion: Reduce partial-fill and hedge-failure risk

• Determinism: Ensure each decision path is observable and replayable

• Throughput: Sustain 100K+ OPS across active routing paths

BHLE sits in this layer as the high-performance routing fabric. It is optimized for sub-50μs internal decision latency and uses proprietary routing infrastructure to maintain execution precision across fragmented markets.

2.4) Risk engine

Function:

• Act as the hard gatekeeper for system actions

• Evaluate market state, venue state, internal balances, and strategy constraints before execution is allowed

Control mechanisms include:

• BSCB/DMM state transitions

• Venue health and liveness checks

• Exposure and inventory limits

• Kill-switch and circuit-breaker logic

• Strategy-level veto rules

The risk engine can reject, pause, or isolate a subsystem automatically. This is a hard control plane, not a best-effort alerting layer.

Risk is managed as a deterministic state machine. That design makes failure handling explicit, testable, and auditable. It also aligns with the control, service governance, and continuous improvement disciplines reflected in BASIS DIGITAL INFRASTRUCTURE LTD's active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications. The ISO/IEC 27001:2022 certification covers The Design and Development of Software and Quantitative Research Systems and the Management of Associated IT Infrastructure and Information Security.

2.5) Accounting and reconciliation

Function:

• Maintain the authoritative ledger for balances, positions, rewards, fees, and realized results

• Reconcile internal state continuously against venue state and blockchain state where applicable

Accounting principles:

• Every state transition is event-backed

• All postings must satisfy mathematical balance constraints

• Drift detection runs continuously

• Exceptions are surfaced through explicit reconciliation events

Platform wallet domains are enforced at the ledger level:

• Funding Wallet: native assets only, including BTC, ETH, SOL, and PAXG for deposit and withdrawal

• Staking Wallet: stTokens only, including stBTC, stETH, stSOL, and stPAXG for staking and reward accrual

Swap operations are same-token 1:1 conversions only:

• BTC ↔ stBTC

• ETH ↔ stETH

• SOL ↔ stSOL

• PAXG ↔ stPAXG

This separation reduces accounting ambiguity and supports deterministic balance verification.

3) Why this architecture supports trust 🔒

The architecture follows the same principles used in professional execution systems:

• Separation of concerns: Each service owns a narrow, testable responsibility

• Deterministic execution: Decisions can be replayed from the event log

• Mathematical constraints: Ledger and exposure rules are enforced mechanically

• State-machine risk control: Unsafe transitions are blocked by design

• Operational transparency: Audit trails exist at transaction and system-state level

In practical terms, BASIS turns research into measurable production behavior. Structural alpha capture depends not only on signal quality, but also on deterministic execution, rigorous risk gating, and verifiable accounting. This architecture is operated by BASIS DIGITAL INFRASTRUCTURE LTD under active and publicly verifiable ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications, reinforcing BASIS's institutional-grade security, service management, and operational trust profile.

Reference

[1] Martin Kleppmann, Designing Data-Intensive Applications, O'Reilly Media, 2017.