# Batch Auctions

Strike uses **Frequency Batch Auctions (FBA)** instead of continuous order matching. This is the core mechanism that determines how trades execute.

## How a Batch Clears

1. **Accumulate orders** — during the batch interval, traders place and cancel orders. Orders are recorded on-chain but not matched yet.
2. **Trigger clearing** — anyone calls `clearBatch(marketId)`. This is permissionless. There is no on-chain batch interval enforcement — the keeper decides clearing cadence.
3. **Find clearing price** — the contract uses a segment tree binary search to find the clearing tick:
   * Binary search for the highest tick where cumulative bids >= cumulative asks
   * Post-search correction: check tick+1 to ensure maximum matched volume min(cumBid, cumAsk)
   * This handles cases where asks exceed bids at the crossing tick
4. **Calculate pro-rata fills** — at the clearing tick, one side may be oversubscribed. Each order on the oversubscribed side gets `filledLots = (orderLots * matchedLots) / totalSideLots`.
5. **Store result + advance batch** — a `BatchResult` is written: clearing tick, matched lots, total bid/ask lots, timestamp. The batch counter advances so new orders go to the next batch.
6. **Atomic settlement** — all orders in the batch are settled inline in the same transaction:
   * Filled collateral (at clearing price, not order tick) moves to the market pool
   * Excess refund = (locked at order tick) - (cost at clearing tick) returned to owner
   * Uniform fee (20 bps) deducted, sent to protocol fee collector
   * Positions credited (bidder gets UP, asker gets DOWN) — for internal position markets; ERC-1155 tokens minted for token-based markets
   * Unfilled collateral returned to owner
   * GTC orders with remaining lots roll to the next batch

## Collateral Model (USDT)

Both sides lock USDT (ERC-20). Users must approve the Vault before placing orders. Asks do NOT require pre-existing positions.

* **Bid** at tick 50 for 10 lots: locks `10 × $0.01 × 50/100 = $0.05`
* **Ask** at tick 50 for 10 lots: locks `10 × $0.01 × 50/100 = $0.05`
* Total per matched lot = LOT\_SIZE (1e16 = $0.01), fully collateralized

This is simpler than requiring askers to hold positions, and provides symmetric UX for both sides.

## Clearing Price Settlement

All fills settle at the **clearing tick**, not each order's limit tick. A bid placed at tick 70 that clears at tick 55 pays only 55% per lot — the excess 15% is refunded. This ensures all participants in a batch trade at the same fair price.

## Anti-MEV Price Protection

Limit orders provide built-in price protection. Your order will never fill at a price worse than your tick — if the clearing price exceeds your limit, your order simply doesn't fill and your collateral is returned (or rolls to the next batch for GTC orders).

This is fundamentally different from AMM-style slippage. In continuous AMMs, price can move between when you submit a trade and when it executes. In a batch auction, all orders are collected first and cleared together at a single uniform price. There is no "front-running window" — everyone in the batch gets the same deal.

To express willingness to pay more for guaranteed fills, place your order at a tick further from the expected clearing price. The difference between your tick and the actual clearing price is refunded automatically.

## Fill Logic

| Order Position                                          | Result                      |
| ------------------------------------------------------- | --------------------------- |
| Bid at or above clearing tick (non-oversubscribed side) | Fully filled                |
| Ask at or below clearing tick (non-oversubscribed side) | Fully filled                |
| At clearing tick (oversubscribed side)                  | Partially filled (pro-rata) |
| Bid below clearing tick                                 | Not filled                  |
| Ask above clearing tick                                 | Not filled                  |

## Why Batches?

### vs. Continuous Matching

* **No speed advantage** — all orders in a batch are equal, eliminating latency races
* **Uniform price** — everyone gets the same price, not a sequence of price-moving fills
* **Maker-friendly** — makers have the full batch interval to cancel stale quotes

### vs. Parimutuel Pools

* **Real price discovery** — prices are set by supply and demand, not pool ratios
* **Capital efficient** — traders can express precise views at specific prices
* **Secondary market** — positions are tradeable on the book via sell orders

## Resting Orders (Price-Proximity Filtering)

Orders placed far from the last clearing tick (more than **PROXIMITY\_THRESHOLD = 20 ticks** away) are parked in a **resting list** instead of being inserted into the segment tree. This prevents phantom volume from distant orders distorting the clearing price.

* Resting orders lock collateral/tokens normally — they are real orders, just parked outside the tree
* An `OrderResting` event is emitted (distinct from `OrderPlaced`)
* At the start of each `clearBatch`, `pullRestingOrders` runs automatically, pulling in-range resting orders back into the segment tree (paginated: max **MAX\_RESTING\_PULL = 200** pulled, max **MAX\_RESTING\_SCAN = 400** scanned per call)
* GTC orders that move far from price after a batch clear are rolled to the resting list via `_tryRollOrCancel`
* Users can cancel resting orders normally

## Chunked Settlement

Large batches settle across multiple `clearBatch` calls:

* **MAX\_ORDERS\_PER\_BATCH = 1600** — up from 400 in v1.1
* **SETTLE\_CHUNK\_SIZE = 400** — each `clearBatch` call settles up to 400 orders
* Batches with more than 400 orders require multiple `clearBatch` calls to fully settle
* Precomputed fills (clearing tick, matched lots) are stored on the first call and reused by subsequent chunks, ensuring correctness across calls

## Batch Overflow

Each batch can hold up to **MAX\_ORDERS\_PER\_BATCH (1600)** orders. When a batch is full, new orders automatically spill into the next batch. This bounds the gas cost of `clearBatch()` while keeping order placement seamless.

## Batch Cadence

The batch interval is configurable per market at creation time. There is no on-chain enforcement of the interval — the keeper decides when to call `clearBatch()`.

## Segment Tree

Clearing requires knowing cumulative volume at each tick. A naive approach iterates all 99 ticks — expensive on-chain. Strike uses a **segment tree** to compute prefix sums and find the clearing tick in O(log N) operations with minimal storage writes.


---

# 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.strike.pm/protocol/batch-auctions.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.