# Operational Model: Venues, Fragmentation, Controls

{% 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)).
{% endhint %}

BASIS interacts with third-party venues, including centralized exchanges and on-chain protocols, to execute structural alpha capture strategies. This introduces operational complexity, settlement dependencies, and counterparty risk.

This page explains how BASIS manages:

* venue selection and whitelisting
* risk scoring and blacklisting
* liquidity fragmentation
* deterministic execution controls
* incident response and public disclosure

## 1) Venue registry and whitelisting

BASIS maintains a continuously updated venue registry. Only venues that satisfy minimum technical, operational, and risk thresholds are eligible for automated routing. These controls operate within an institutional-grade operating model supported by active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 management systems.

| Registry field      | Description                                                               |
| ------------------- | ------------------------------------------------------------------------- |
| Connectivity status | Endpoint health, latency, timeout rate, failover readiness                |
| Market coverage     | Supported spot and derivatives markets                                    |
| Withdrawal status   | Enabled, delayed, limited, or halted                                      |
| Settlement paths    | On-chain and exchange transfer routes available to BASIS                  |
| Reliability metrics | Historical uptime, rejection rate, cancellation behavior                  |
| Risk score          | Composite score derived from operational and market conditions            |
| Capacity limits     | Internal exposure caps, venue-specific throughput, and balance thresholds |

Whitelisting is not static. A venue may be active for one market and blocked for another if local conditions differ.

{% hint style="warning" %}
Whitelisting is independent from strategy logic. A market signal does not authorize execution unless the venue also passes current operational and risk checks.
{% endhint %}

## 2) Institutional-grade filtering

For each candidate trade, BASIS evaluates whether the opportunity is executable under live constraints. This evaluation is performed through defined control layers that align with BASIS operational discipline and its certified information security and service management processes.

{% tabs %}
{% tab title="Market filters" %}

* Order book depth and replenishment quality
* Spread stability over short intervals
* Realized slippage expectation
* Fee impact after routing
* Cross-venue price consistency
  {% endtab %}

{% tab title="Operational filters" %}

* Withdrawal availability
* Deposit crediting reliability
* Rate-limit pressure
* Maintenance windows
* API degradation or abnormal error rates
  {% endtab %}

{% tab title="Risk filters" %}

* Venue risk score threshold
* Concentration limits
* Asset-specific exposure limits
* Transfer-path restrictions
* Strategy-level capital allocation bounds
  {% endtab %}
  {% endtabs %}

This filtering is what separates theoretical spread from executable structural alpha capture.

## 3) Blacklisting and dynamic exclusion

A venue can be dynamically excluded when one or more of the following conditions appear:

* withdrawals are delayed, limited, or halted
* abnormal pricing or persistent dislocation is detected
* API instability or sequencing errors appear
* order acknowledgements become unreliable
* counterparty risk score deteriorates beyond threshold
* settlement paths become congested or unavailable

Exclusion can occur automatically through system rules or manually through operator intervention. Re-entry requires fresh validation, not simple timeout expiry.

## 4) Liquidity fragmentation policy

Because counterparty risk is real, BASIS follows a liquidity fragmentation policy. Capital is intentionally distributed across multiple venues and settlement paths rather than concentrated in a single location.

| Policy rule              | Objective                                             |
| ------------------------ | ----------------------------------------------------- |
| Multi-venue distribution | Reduce single-point counterparty exposure             |
| Concentration caps       | Prevent excessive dependence on one venue             |
| Pre-positioned balances  | Reduce transfer delay during active execution windows |
| Transfer-path diversity  | Preserve optionality if a route degrades              |
| Protocol exposure limits | Bound smart contract and bridge-related risk          |

Where feasible, BASIS distributes capital across multiple venues and routes. This increases operational complexity, but materially improves survivability during venue-specific incidents.

## 5) Execution infrastructure and control framework

BASIS uses BHLE, a proprietary routing and execution infrastructure designed for deterministic behavior under fragmented market conditions.

| Capability       | Standard                                                               |
| ---------------- | ---------------------------------------------------------------------- |
| Decision latency | Sub-50μs                                                               |
| Throughput       | 100K+ OPS                                                              |
| Routing model    | Proprietary multi-venue routing infrastructure                         |
| Control model    | Deterministic execution, math constraints, state machine risk controls |

Execution flow is constrained by explicit system gates:

```
Signal
  → venue eligibility
  → risk gate
  → route selection
  → execution
  → post-trade reconciliation
  → exposure update
```

Key properties of the control framework:

* deterministic order handling under predefined constraints
* bounded exposure transitions through state-machine logic
* hard rejection of routes that violate capital or reliability thresholds
* continuous reconciliation between venue balances, internal ledgers, and strategy state

These controls are designed to prioritize execution precision and capital preservation over nominal opportunity count.

## 6) Incident response and user communication 🔒

When a venue or protocol incident occurs, BASIS applies a formal response process. This process is supported by an operating framework aligned with the company’s active ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certifications.

1. Detect and classify the event\
   Identify whether the issue is related to market quality, API behavior, withdrawals, settlement, or counterparty risk.
2. Isolate affected routes\
   Disable impacted venues, markets, or transfer paths.
3. Trigger protective state transitions\
   Apply the appropriate system mode, including BSCB → DMM where required by internal risk logic.
4. Communicate externally\
   Publish a timestamped notice describing scope, user impact, and current system status.
5. Resume only after verification\
   Restart routing only after stability checks, reconciliation, and root-cause review are complete.

{% hint style="info" %}
Public documentation, dashboards, and status notices must match actual system behavior. Consistency between disclosed state and live state is a core trust requirement. BASIS treats this as part of an institutional-grade control environment with internationally verifiable management systems.
{% endhint %}

## 7) Practical implication for users

Venue fragmentation and dynamic exclusion may reduce short-term opportunity count, but they improve execution reliability and loss containment under stress. This is consistent with the BASIS operating model:

* deterministic execution instead of discretionary intervention
* constrained state transitions instead of ad hoc overrides
* survivability first, then optimization

In practice, this means BASIS is designed to operate as an institutional-grade, internationally certified, and trustworthy platform where execution discipline, operational resilience, and externally verifiable control standards matter as much as raw opportunity capture.

***

Next: read `Metrics & Reporting` to understand how BASIS defines yield, APY, and performance figures.


---

# 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/operations.md?ask=<question>
```

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.