# Execution Model: Technical Detail

{% 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 %}

The BASIS execution model follows one rule: deterministic, low-latency, atomic execution. BHLE is the execution layer behind structural alpha capture and funding-rate strategies. It combines sub-50μs internal execution latency, 100K+ OPS throughput, proprietary routing infrastructure, and fail-closed state-machine controls to keep execution variance bounded.

## Core execution properties

| Property                | Implementation                                                                            |
| ----------------------- | ----------------------------------------------------------------------------------------- |
| Deterministic routing   | Pre-calculated venue state removes last-second discovery calls                            |
| Math-constrained sizing | Position sizing, slippage bounds, and margin checks are computed against fixed invariants |
| Atomic coordination     | Dual-leg orders are linked by correlation ID and timeout logic                            |
| Risk control model      | State-machine transitions block invalid or partially reconciled states                    |
| Reliability scoring     | Venue quality is updated from observed acknowledgements, fills, and slippage              |

## Pre-calculated network state

Many execution stacks react in-line. A signal arrives, the system queries books, sizes the trade, then submits. Each query adds latency and jitter. BHLE avoids that by continuously maintaining a pre-calculated network state, a live model of:

* current order book depth across active venues
* normalized liquidity at each price level within the slippage bound of 0.30%
* current margin ratios across open positions
* funding-rate state per asset and venue
* network and gas estimates for on-chain settlement legs
* venue health, acknowledgement quality, and route reliability scores

When a signal fires, BHLE decides against this state instead of issuing last-second queries. This removes a major latency source and improves execution precision.

## Order submission pipeline

```
[Signal] -> [Decision] -> [Order Construction] -> [Atomic Submission] -> [Fill Confirmation]
  <1μs <5μs <10μs <14μs <20μs

Total internal pipeline target: <50μs
```

{% stepper %}
{% step %}

#### 1. Signal

Signals enter from three sources:

* funding-rate monitor, scheduled
* structural alpha scanner, continuous
* risk monitor, event-driven

Each signal carries the asset, direction, target notional, maximum slippage, timeout window, and route class.
{% endstep %}

{% step %}

#### 2. Decision

BHLE checks the signal against the pre-calculated state and hard risk constraints:

* is the spread still inside the 0.30% slippage bound
* is depth sufficient for the target notional
* are margin ratios above minimum on both legs
* are venue health and route reliability above threshold
* are circuit breakers and state-machine guards clear

If any check fails, BHLE rejects the signal and submits no order.
{% endstep %}

{% step %}

#### 3. Order construction

BHLE builds both legs at the same time with synchronized order IDs. Each order contains:

* venue
* asset
* side
* quantity
* limit price derived from spot and tolerance
* correlation ID linking the two legs

Sizing is math-constrained. Orders cannot exceed the validated depth, margin envelope, or route timeout budget.
{% endstep %}

{% step %}

#### 4. Atomic submission

BHLE submits both orders simultaneously over co-located venue links and proprietary routing infrastructure.

Atomic means the trade is treated as one coordinated state transition. If Leg 2 does not receive a fill acknowledgement inside the timeout window, BHLE cancels or offsets Leg 1 immediately. The engine does not leave a partially hedged position open past the configured threshold.
{% endstep %}

{% step %}

#### 5. Fill confirmation

BHLE receives acknowledgements and fills, reconciles them, and updates the state model. If realized slippage exceeds the configured threshold, the trade is flagged for post-trade review and the venue reliability score is adjusted.
{% endstep %}
{% endstepper %}

## Latency breakdown

| Stage                                | Target latency | Primary bottleneck             |
| ------------------------------------ | -------------- | ------------------------------ |
| Signal to Decision                   | < 1μs          | pre-calculated state lookup    |
| Decision to Order Construction       | < 5μs          | dual-leg size calculation      |
| Order Construction to Submission     | < 10μs         | network serialization          |
| Submission to Exchange ACK           | < 14μs         | co-location and venue response |
| Exchange ACK to Fill Confirmation    | < 20μs         | exchange matching engine       |
| End-to-end, signal to confirmed fill | < 50μs         | BHLE internal path             |

{% hint style="info" %}
These figures represent BHLE internal processing targets. Venue network RTT and blockchain finality are external to the internal latency budget.
{% endhint %}

## Atomic execution and partial fill prevention

{% tabs %}
{% tab title="Preventive controls" %}

* correlated order IDs for both legs
* pre-trade depth validation on both routes
* slippage ceiling fixed at 0.30%
* margin and exposure invariants checked before submission
* venue health and reliability gating
  {% endtab %}

{% tab title="Fail-closed behavior" %}

* if Leg 2 misses the timeout, Leg 1 is cancelled or neutralized immediately
* if state reconciliation fails, new orders are blocked until the state machine returns to a valid state
* if a venue degrades, the route is disabled and traffic is rebalanced
* if market movement exceeds tolerance, the order is rejected rather than chased
  {% endtab %}
  {% endtabs %}

Partial fills are the primary execution risk in cross-venue structural alpha capture. BHLE reduces that risk by combining pre-trade validation, correlated execution, and immediate rollback logic.

## SVM vs EVM execution differences

BHLE bridges SVM and EVM environments for BIVB operations and active PAXG settlement paths.

| Dimension            | SVM (Solana)                            | EVM (Ethereum and L2)                                |
| -------------------- | --------------------------------------- | ---------------------------------------------------- |
| Block time           | \~400ms                                 | 12s on L1, \~250ms on fast L2s                       |
| Transaction finality | \~1s, optimistic                        | multi-block on L1, faster on L2 depending on network |
| Gas model            | fixed compute units                     | variable gas pricing                                 |
| Parallelism          | native parallel execution               | sequential virtual machine execution                 |
| BHLE use             | preferred for time-sensitive settlement | used for DeFi integrations and active PAXG routes    |

{% hint style="warning" %}
For time-sensitive BIVB settlement, BHLE prefers the route with the best combined latency, liquidity quality, and deterministic settlement profile. In practice, that often favors SVM paths for high-speed settlement and EVM paths for integrations where liquidity access or asset support is superior.
{% endhint %}

## Why this matters

Execution quality is not only a speed problem. It is a control problem. BASIS uses deterministic routing, math-bounded sizing, and state-machine risk controls so that structural alpha capture remains inside a known execution envelope instead of depending on discretionary intervention.

## See also

* [System Overview](/whitepaper/system-overview.md)
* [BHLE Architecture](/technical-architecture/overview.md)
* [Cross-Venue Execution](/research-library-deep-dives/cross-exchange-execution.md)


---

# 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/execution-model.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.