> 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/technical-architecture/anti-slippage.md).

# Anti-Slippage & Order Slicing

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

Slippage is one of the primary failure modes in structural alpha capture.

A platform can claim execution precision and still lose money if it cannot bound slippage under real market conditions.

BASIS treats slippage control as a layered systems problem, combining deterministic execution, math constraints, and state machine risk controls.

## 1) Slippage components

| Component         | Meaning                                                       | Primary control                                                    |
| ----------------- | ------------------------------------------------------------- | ------------------------------------------------------------------ |
| Market impact     | Your order consumes visible liquidity and moves the book      | Size gating, depth-aware sizing, slicing rules                     |
| Adverse selection | You interact with better-informed or faster flow              | Venue scoring, toxic flow filters, strategy eligibility rules      |
| Latency           | The market changes before the order is acknowledged or filled | BHLE routing, sub-50μs internal handling, strict cancel discipline |

BASIS designs an explicit control layer for each source of execution drift.

## 2) Pre-trade slippage bounds

Before sending an order, BASIS computes a conservative slippage bound using:

* live order book depth
* recent volatility
* venue-specific execution quality
* expected queue position
* routing and network latency

If expected slippage exceeds the available edge, the trade is rejected.

```
if expected_edge <= expected_slippage + fees:
  reject_trade()
```

{% hint style="warning" %}
⚠️ Core rule: when expected cost is greater than expected edge, no order should be sent.
{% endhint %}

This is the practical form of slippage inversion. When cost dominates opportunity, the correct action is inaction.

## 3) Order slicing

For larger sizes, BASIS may split a parent order into controlled child orders and re-evaluate conditions between fills.

{% tabs %}
{% tab title="When slicing is used" %}

* the opportunity window is sufficiently wide
* hedge quality remains controlled
* venue depth supports incremental execution
* estimated exposure time stays within strategy limits
  {% endtab %}

{% tab title="When slicing is not used" %}

* signal half-life is too short
* hedge quality deteriorates rapidly
* realized slippage is already near rejection threshold
* venue conditions enter a stressed regime
  {% endtab %}
  {% endtabs %}

### Iceberg concept

An iceberg strategy exposes only part of the total size to the book at any given time.

Benefits:

* reduced signaling
* lower instantaneous market impact

Costs:

* longer exposure time
* higher risk of regime change during execution

BASIS only permits slicing when these trade-offs remain favorable under risk constraints.

## 4) Price protection

Orders are wrapped with explicit protection logic.

{% stepper %}
{% step %}
Apply protective limit bounds
{% endstep %}

{% step %}
Set time-in-force rules appropriate to the venue and strategy
{% endstep %}

{% step %}
Cancel or replace when the market moves outside the allowed execution band
{% endstep %}

{% step %}
Abort when fill quality degrades below threshold
{% endstep %}
{% endstepper %}

BASIS treats no fill as preferable to a bad fill when capital preservation is the correct decision.

## 5) Post-trade analysis

A reliable execution system tracks:

* realized slippage distribution
* fill quality by venue and asset
* regime sensitivity during spikes and normal conditions
* reject rates versus accepted trade outcomes
* child-order behavior during slicing

This data feeds directly into venue scoring, risk calibration, and future eligibility decisions.

{% hint style="success" %}
BHLE is the proprietary routing and execution layer behind BASIS. It is engineered for sub-50μs internal latency and 100K+ OPS. The objective is not speed alone. It is deterministic execution quality under strict risk constraints.
{% endhint %}

***

Next: read Risk Engine.