# 批量拍卖

STRIKE 使用 **Frequent Batch Auctions (FBA)**，而不是连续撮合订单。这是决定交易如何执行的核心机制。

## 批次如何清算

1. **Accumulate 订单** — 在批次间隔内，交易者可以下单和取消订单。订单会记录在链上，但尚未撮合。
2. **Trigger 清算** — 任何人都可以调用 `clearBatch(marketId)`。该操作无需许可。链上不强制执行批次间隔；keeper 决定清算 cadence。
3. **Find 清算价格** — 合约使用线段树和二分搜索找到清算 tick：

* Binary search 用于找到满足 cumulative bid >= cumulative ask 的最高 tick
* Post-search correction: 检查 tick+1，确保 `min(cumBid, cumAsk)` 对应最大匹配量
* 这会处理 ask 在交叉 tick 超过 bid 的情况

4. **Calculate 按比例成交** — 在清算 tick，如果一侧超额认购，该侧每笔订单获得 `filledLots = (orderLots * matchedLots) / totalSideLots`。
5. **存储结果并推进批次** — 写入 `BatchResult`：清算 tick、匹配手数、买卖总手数和时间戳。批次计数器随后推进，新订单进入下一个批次。
6. **原子化结算** — 所有订单在同一笔交易中内联结算：

* 已成交抵押资产（按清算价格，而非订单 tick）转入市场池
* Excess 退款 =（按订单 tick 锁定）-（按清算 tick 计算的 cost），返回所有者
* 统一费用（20 bps）扣除并发送到协议费用收集器
* Positions credited（bidder 获得 UP，asker 获得 DOWN）— 用于内部持仓市场；ERC-1155 代币用于基于代币的市场
* 未成交抵押资产返回所有者
* GTC 订单会将剩余 lots 滚入下一个批次

## 抵押资产模型（USDT）

双方都锁定 USDT（ERC-20）。用户下单前必须授权金库。Asks 不需要预先持有 positions。

* **Bid** 以 tick 50 买入 10 lots：锁定 `10 × $0.01 × 50/100 = $0.05`
* **Ask** 以 tick 50 卖出 10 lots：锁定 `10 × $0.01 × 50/100 = $0.05`
* 每个 matched lot 合计 = LOT\_SIZE（1e16 = $0.01），完全抵押

这比要求 askers 预先持有 positions 更简单，也为双方提供对称的 UX。

## 清算价格结算

所有成交都按**清算 tick**结算，而不是按各自订单的 limit tick。若一笔 bid 以 tick 70 提交，并以 tick 55 清算，则每 lot 只支付 55%，多出的 15% 自动退回。这保证同一 batch 中的所有参与者都以同一公平价格成交。

## 抗 MEV 价格保护

限价单提供内置价格保护。你的订单永远不会以差于你的 tick 的价格成交；如果清算价格超过你的 limit，订单不会成交，抵押资产会退回，或作为 GTC 订单滚入下一个批次。

这与 AMM 式滑点有本质区别。在连续 AMM 中，价格可能在你提交交易和交易执行之间移动。批量拍卖会先收集所有订单，再按单一统一价格一起清算。这里没有“抢跑窗口”，同一批次中的所有人都获得相同价格。

如果你愿意支付更高价格以提高成交概率，可以把订单 tick 设置在距离预期清算价格更远的位置。你的 tick 与实际清算价格之间的差额会自动退回。

## 成交逻辑

| 订单位置                                             | 结果        |
| ------------------------------------------------ | --------- |
| Bid at 或 above 清算 tick (non-oversubscribed side) | 完全成交      |
| Ask at 或 below 清算 tick (non-oversubscribed side) | 完全成交      |
| At 清算 tick (oversubscribed side)                 | 部分成交（按比例） |
| Bid below 清算 tick                                | 不成交       |
| Ask above 清算 tick                                | 不成交       |

## 为什么使用批量拍卖？

### vs. 连续撮合

* **No speed advantage** — 同一 batch 中的所有订单平等处理，消除延迟竞争
* **Uniform price** — 所有人获得相同价格，而不是一串逐步推高或压低价格的成交
* **Maker-friendly** — 做市方有完整批次间隔来取消过时报价

### vs. 同注分彩池

* **Real 价格发现** — 价格由 supply 与 demand 决定，而不是由资金池比例决定
* **资本效率高** — 交易者可以在具体价格表达精确观点
* **二级市场** — positions 可以通过订单簿卖单交易

## 休眠订单（价格接近度过滤）

距离上次清算 tick 超过 **PROXIMITY\_THRESHOLD = 20 ticks** 的订单会进入**休眠列表**，而不是插入线段树。这可以防止远离市场的订单形成虚假深度并扭曲清算价格。

* 休眠订单会正常锁定抵押资产/代币；它们是真实订单，只是停放在线段树外
* `OrderResting` 事件会触发，且独立于 `OrderPlaced`
* 每次 `clearBatch` 开始时，`pullRestingOrders` 会自动运行，将 in-range 休眠订单拉回线段树（paginated: max **MAX\_RESTING\_PULL = 200** pulled, max **MAX\_RESTING\_SCAN = 400** scanned per call）
* 如果 GTC 订单在批次清算后远离价格，会通过 `_tryRollOrCancel` 滚入休眠 list
* 用户可以正常取消休眠订单

## 分块结算

Large batches 会跨多个 `clearBatch` 调用结算：

* **MAX\_ORDERS\_PER\_BATCH = 1600** — v1.1 中从 400 提高
* **SETTLE\_CHUNK\_SIZE = 400** — 每次 `clearBatch` 调用最多结算 400 笔订单
* 超过 400 笔订单的 batches 需要多次 `clearBatch` 调用才能完成结算
* 预计算成交结果（清算 tick、匹配手数）会在第一次调用中存储，并被后续 chunks 复用，确保跨调用正确性

## 批次溢出

每个 batch 最多包含 **MAX\_ORDERS\_PER\_BATCH (1600)** 笔订单。当一个 batch 已满，新订单会自动 spill into 下一个批次。这限制了 `clearBatch()` 的 Gas 成本，同时保持下单流程顺畅。

## 批次节奏

批次间隔在市场创建时可配置。链上不强制执行该间隔；keeper 决定何时调用 `clearBatch()`。

## 线段树

清算需要知道每个 tick 的累计成交量。朴素做法需要遍历全部 99 个 ticks，链上成本较高。STRIKE 使用**线段树**计算前缀和，并以 O(log N) operations 和最少存储写入找到清算 tick。


---

# 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/zh/xie-yi/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.