> For the complete documentation index, see [llms.txt](https://docs.basis.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.basis.pro/whitepaper/execution-model.md).

# 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)