# BatchAuction.sol

Handles Frequent Batch Auction clearing and atomic pro-rata settlement.

## `clearBatch(marketId)`

Permissionless. Callable by anyone. Clears the current batch and settles all orders atomically in a single transaction. The contract reads order IDs internally from `batchOrderIds[marketId][batchId]` — no parameters beyond `marketId` are needed.

### Algorithm

1. **Validate market:** check market exists, is active, not halted
2. **Find clearing tick:** segment tree binary search for highest tick where cumBid >= cumAsk, with tick+1 correction for maximum matched volume
3. **Compute volumes:** cumulative bid/ask lots at clearing tick, matched = min(bid, ask). If matched = 0, clearing tick reset to 0 (no cross)
4. **Store result:** write `BatchResult` with marketId, batchId, clearingTick, matchedLots, totalBidLots, totalAskLots, timestamp
5. **Advance batch:** increment `currentBatchId` so new orders go to the next batch
6. **Settle all orders:** loop through `batchOrderIds[marketId][batchId]` and settle each order inline (pro-rata fill at clearing price, mint tokens, return excess collateral)
7. **Empty batches:** still stored (clearingTick = 0, matchedLots = 0)

### BatchResult Struct

```solidity
struct BatchResult {
    uint32  marketId;
    uint32  batchId;
    uint8   clearingTick;   // 0 = no cross
    uint64  matchedLots;
    uint64  totalBidLots;
    uint64  totalAskLots;
    uint40  timestamp;
}
```

### Inline Settlement Flow

For each order in `batchOrderIds[marketId][batchId]`:

**Non-participating orders** (tick doesn't cross clearing price):

* **GoodTilBatch (GTB):** removed from book, full collateral refunded to wallet
* **GoodTilCancel (GTC):** left in book, rolled to next batch via `pushBatchOrderId()`

**Participating orders** (settled at clearing price, not order tick):

1. Compute pro-rata fill: `filledLots = (orderLots * matchedLots) / totalSideLots`
2. Filled collateral calculated at **clearing tick** (not the order's limit tick)
3. Excess refund = (collateral locked at order tick) - (cost at clearing tick)
4. Deduct fee (20 bps total, split 50/50): buy side pays `floor(fee/2)`, sell side pays `ceil(fee/2)` from USDT payout. Fees sent to protocol fee collector
5. Mint outcome token via `mintSingle()` (or credit internal position for `useInternalPositions` markets):
   * **Bidder** receives YES token (or YES position credit)
   * **Asker** receives NO token (or NO position credit)
6. Remove filled lots from order, update segment tree
7. **Fully filled or GTB:** withdraw unfilled collateral + excess refund to wallet
8. **Partially filled GTC:** roll remainder to next batch, withdraw excess refund if any

### Collateral Model (USDT)

Both sides lock USDT collateral (ERC-20). Users must approve the Vault before placing orders. Asks do NOT lock outcome tokens.

* Bid collateral: `lots * LOT_SIZE * tick / 100`
* Ask collateral: `lots * LOT_SIZE * (100 - tick) / 100`
* Sum per matched lot = LOT\_SIZE (1e16 = $0.01), fully collateralized

### Clearing Price Settlement

All fills settle at the **clearing tick**, not the order's limit tick. This means:

* A bid at tick 70 filled at clearing tick 55 pays only 55% per lot (not 70%)
* The excess (70% - 55% = 15% per lot) is refunded to the bidder
* Same logic applies symmetrically to asks

### 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
* On the first call for a batch, clearing tick and matched lots are computed and stored as precomputed fills
* Subsequent calls reuse the precomputed fills and settle the next chunk of orders
* GTB orders that receive zero fills are cleaned up during settlement via `_tryRollOrCancel`

### Resting Order Handling

At the start of each `clearBatch`, `pullRestingOrders` is called to move in-range resting orders back into the segment tree before clearing. After settlement, GTC orders that are now far from the new clearing price are rolled to the resting list via `_tryRollOrCancel` instead of remaining in the active tree.

### Batch Overflow

`MAX_ORDERS_PER_BATCH = 1600`. When the current batch reaches 1600 orders, new orders automatically spill into the next batch. Placement fails only if both the current and next batch are full.

## Events

```solidity
event BatchCleared(uint256 indexed marketId, uint256 indexed batchId, uint256 clearingTick, uint256 matchedLots);
event OrderSettled(uint256 indexed orderId, address indexed owner, uint256 filledLots, uint256 collateralReleased);
```


---

# 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/smart-contracts/batch-auction.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.