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


---

# 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/anti-slippage.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.