# Execution Orchestration

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

Research Partner: Base58 Labs contributes execution research, systems modeling, and risk design.
{% endhint %}

Execution orchestration converts modeled structural alpha into realized results.

At BASIS, execution quality depends on deterministic routing, math-constrained order generation, and state machine risk controls running on BHLE infrastructure.

{% hint style="success" %}
⚙️ BHLE highlights

* Sub-50μs internal decision latency
* 100K+ OPS event throughput
* Proprietary routing infrastructure
* Deterministic execution controls with bounded risk transitions
  {% endhint %}

## What the orchestrator is responsible for

A production-grade orchestrator answers four questions:

| Function           | Requirement                                                      |
| ------------------ | ---------------------------------------------------------------- |
| Signal handling    | Validate that a signal remains actionable at dispatch time       |
| Order construction | Generate bounded orders with explicit size and slippage limits   |
| Routing            | Send orders to the correct venue with venue-specific safeguards  |
| Recovery           | Isolate faults, complete required hedges, and reconcile balances |

## 1. Execution lifecycle

{% stepper %}
{% step %}
Signal detected

A structural alpha opportunity is identified and checked for freshness, venue availability, and inventory constraints.
{% endstep %}

{% step %}
Eligibility gate passed

The engine validates capital allocation, venue health, transfer state, and current risk state.
{% endstep %}

{% step %}
Orders generated

The system computes order size, price bounds, hedge dependency, and maximum acceptable slippage.
{% endstep %}

{% step %}
Orders routed

Orders are routed through BHLE with venue-aware throttling, retry rules, and deterministic sequencing.
{% endstep %}

{% step %}
Fills monitored

Fill ratios, hedge completion windows, and residual exposure are tracked in real time.
{% endstep %}

{% step %}
Positions reconciled

Venue balances, partial fills, fees, and transfer dependencies are reconciled before exposure is considered closed.
{% endstep %}

{% step %}
Results recorded

Outcome data is written to reporting systems and displayed using the platform's internal USDT accounting convention.
{% endstep %}
{% endstepper %}

## 2. Atomic and coordinated execution

{% tabs %}
{% tab title="Centralized venues" %}
On centralized venues, atomic execution is operational rather than literal. The objective is coordinated completion with minimal time gap between legs.

Controls include:

* bounded dispatch timing
* hedge completion windows
* fill ratio thresholds
* automatic escalation when symmetry degrades
  {% endtab %}

{% tab title="On-chain venues" %}
On-chain, atomic execution can be literal when both legs execute in a single transaction with revert behavior.

Controls include:

* transaction-level slippage limits
* deterministic calldata generation
* pre-trade simulation
* failure reversion when execution conditions are not met
  {% endtab %}
  {% endtabs %}

The orchestrator treats these as separate execution domains with different guarantees.

## 3. Order management and fill symmetry

The main source of execution loss is asymmetric completion, where one leg fills and the other does not.

BASIS mitigates this with:

* explicit price bounds
* venue-specific slippage caps
* real-time fill symmetry monitoring
* hedge completion deadlines
* state machine escalation when thresholds are breached

{% hint style="warning" %}
🛡️ If fill symmetry falls outside policy, the engine does not continue normal routing. It transitions to a protective state, isolates the position, and executes the required unwind path.
{% endhint %}

## 4. Settlement and reconciliation

Reconciliation is a core control, not a back-office task.

| Reconciliation layer | What is checked                                              |
| -------------------- | ------------------------------------------------------------ |
| Order layer          | Submitted, acknowledged, filled, canceled, expired           |
| Position layer       | Net exposure, hedge completion, residual inventory           |
| Balance layer        | Venue balances, pending transfers, fee deductions            |
| Reporting layer      | Internal accounting values, realized outcome, exception logs |

This loop matters because:

* venue balance updates can lag
* partial fills create residual exposure
* settlement timing can temporarily constrain deployable capital

## 5. Failure modes and fallback behavior

The orchestrator handles adverse conditions conservatively.

| Failure mode      | Default response                                                |
| ----------------- | --------------------------------------------------------------- |
| API timeout       | Stop new dispatch for the affected venue and verify order state |
| Rate limiting     | Degrade routing frequency and preserve hedge priority           |
| Venue maintenance | Quarantine the venue and reroute only if policy allows          |
| Volatility spike  | Tighten bounds, reduce size, or halt execution                  |
| Transfer delay    | Recompute available inventory and block dependent strategies    |

Fallback policy is simple:

```
detect fault
→ freeze unsafe path
→ complete or unwind exposure
→ reconcile balances
→ return to normal only after policy checks pass
```

## 6. Why this matters

Execution quality is not defined only by signal quality. It depends on whether the platform can convert opportunity into realized results under real market conditions.

At BASIS, that conversion is supported by:

* BHLE low-latency routing
* deterministic execution rules
* math-constrained order sizing
* state machine risk controls
* continuous reconciliation across venues

Next: Anti-Slippage & Order Slicing


---

# 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/technical-architecture/execution-orchestration.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.