牆內排隊：訂單簿密集區的掛單位置分析

引言：為什麼聚合盤口在"說謊"

每一位看盤口交易的交易者都會看到同樣的畫面：左邊是買盤（bid），右邊是賣盤（ask），每個價格層級顯示一個數字，代表限價單的總量。例如：

价格 10001  |  150 手
价格 10000  |  2,400 手   ← 挂单墙
价格  9999  |  80 手

10000 價位上的 2,400 手就是一堵"牆"（wall、density，即密集掛單區）。這裡出現了一個大多數交易者忽視的關鍵問題：我們的訂單在這 2,400 手中到底排在哪個位置？

价格 10000  [ 我们前面 1,800 手 ][ 我们的订单 10 手 ][ 我们后面 590 手 ]

這不是學術上的好奇心。這是訂單被執行與未被執行的區別。是盈利與虧損的區別。是回測中顯示漂亮淨值曲線與現實中策略失效的區別。

什麼是 Queue Position（排隊位置），為什麼要計算它

FIFO 佇列視覺化：交易者在價格層級中與其他訂單的相對位置

FIFO 與交易所的現實

絕大多數交易所——無論是傳統交易所（CME、NASDAQ），還是加密貨幣交易所（Binance、Bybit、OKX）——都採用**價格-時間優先（FIFO）**規則。這意味著：在相同價格下，最先提交的訂單最先被執行。

當一個市價賣單到達並"擊中"我們的 bid 價格層級時，它會按照從隊首到隊尾的順序依次執行限價單。如果該市價單不夠大，無法到達我們在佇列中的位置——我們的訂單就不會被執行。

排隊位置價值的兩個組成部分

學術研究（Moallemi & Yuan，哥倫比亞商學院，2017）將排隊位置的價值分為兩個組成部分：

1. 靜態組成部分 —— 賺取價差與逆向選擇之間的權衡。我們在佇列中越靠後，被大型知情訂單（而非噪音交易）執行的機率就越高。簡單來說：如果你是佇列中最後被執行的——價格很可能已經朝不利方向運動了。

2. 動態組成部分 —— 隨著時間推移，佇列位置改善帶來的期權價值。當排在我們前面的訂單被取消或執行時，我們的位置會自動改善，無需任何主動操作。

實證資料表明，對於大 tick 品種，排隊位置的價值可以與價差大小相當。這是一個巨大的數值。

如何評估自己的排隊位置

評估問題

我們以價格 P 提交一筆大小為 S 的限價單。提交時該價格層級上已有 Q 手。我們的初始位置估計：

V̂(t₀) = Q(t₀)     — 排在我们前面的手数

然後，我們追蹤該價格層級上所有的成交量變化。這是 Erik Rigtorp 描述並在 Trading Technologies (TT)、Bookmap 等產品中實現的核心演算法。

更新演算法

每當價格層級上的量減少 ΔQ 時，我們需要判斷：減少的是排在我們前面的還是排在我們後面的訂單？

如果我們能區分成交（fills）和撤單（cancellations）：

• 成交（Fill）： 確定性地減少前方佇列 → V̂ = max(V̂ + ΔQ, 0)
• 撤單（Cancel）： 不確定性——撤掉的訂單可能在我們前面，也可能在後面

對於撤單，使用機率模型：

V̂(n+1) = max(V̂(n) + p(n) × ΔQ(n), 0)

其中 p(n) 是被撤訂單排在我們前面的機率。一類模型為：

p(n) = f(V̂(n)) / (f(V̂(n)) + f(max(Q(n) - S - V̂(n), 0)))

其中 f(x) 是遞增函數，例如 ln(1+x) 或恆等函數。直覺是：相對於後方量，前方量越大，撤單發生在前方的機率就越高。

資料層級與加密市場現實

評估質量直接取決於資料的精細度：

加密市場的現狀：

• Binance —— 提供 L2 depth stream，更新間隔 100ms。L3 (MBO) 資料不公開提供。
• Coinbase —— 少數提供 L3 流的中心化交易所之一，通過 WebSocket 提供完整的逐單資料。
• CME（BTC/ETH 期貨）—— 通過 ITCH feed 提供完整的 MBO 資料。

大多數加密交易者使用 L2 資料，因此只能進行機率估計。但即使是機率估計，也遠好於完全沒有評估。

視覺化：將牆看作內部盤口

我們建議將每個顯著的密集掛單區（牆）視覺化為盤口中的迷你盤口：

╔════════════════════════════════════════════════════════════════╗
║  价格 10001  │  150 手                                        ║
╠════════════════════════════════════════════════════════════════╣
║  价格 10000  │  [████████████░░░▓▓░░░░░░░]  2,400 手          ║
║              │   ↑ 前方 1,800   ↑ 我们  ↑ 后方 590            ║
║              │   消耗速度: ~120 手/秒                          ║
║              │   预计成交时间: ~15 秒                          ║
╠════════════════════════════════════════════════════════════════╣
║  价格  9999  │  80 手                                         ║
╚════════════════════════════════════════════════════════════════╝

即時計算內容

1. 我們訂單前方的手數 —— 在輪到我們之前，需要被執行或撤銷的量的估計值。

2. 我們訂單後方的手數 —— 排在我們後面的量。如果牆從尾部快速"膨脹"——意味著其他參與者認為該價位有吸引力。

3. 佇列消耗速度 —— 基於該價格層級實際成交（trades）計算。以手/秒錶示。

4. 預計成交時間（Estimated Time to Fill, ETF） —— 我們訂單被執行的時間預測，計算公式為 前方手数 / 消耗速度。

5. 同一密集區的多筆訂單 —— 如果機器人在同一面牆內有多筆訂單，可以看到每筆訂單各自的位置。

在高頻交易中的應用

樸素回測與 Queue-aware 回測的對比：真實成交機率 vs 樂觀估計

K線資料回測的問題

經典的 OHLCV K線回測邏輯是：如果價格觸及我們的限價單——就算作成交。但這是一個嚴重的錯誤：

示例。 我們在 10000 價位有一筆買入限價單。分鐘 K線的最低價 low = 10000。K線回測記錄為成交。但實際上：

• 10000 價位有一面 5,000 手的掛單牆
• 我們的訂單排在隊尾（第 4,800 位）
• 這一分鐘內該價位只成交了 2,000 手
• 實際上我們的訂單不會被執行

Queue-aware 回測解決了這個問題：它模擬排隊位置，根據逐筆資料統計該價位的成交量，判斷成交量是否足以到達我們的位置。

一分鐘內——不止一次成交

在活躍的高頻交易中，一個訂單可能在一分鐘內被執行並重新提交多次。K線回測根本無法模擬這種情況。只有帶佇列模擬的逐筆分析才能：

• 確定每次成交的精確時間
• 判斷我們是否來得及重新提交訂單
• 評估策略在一個時間區間內實際會觸發多少次

預測成交等待時間

瞭解自身排隊位置和當前牆消耗速度的機器人可以：

1. 計算預計成交時間（ETA） —— 大致的成交等待時間
2. 將 ETA 與價格預測關聯 —— 如果 ETA = 30 秒，但我們的模型預測 10 秒後價格反轉，應該撤單
3. 調整訂單大小 —— 在按比例分配的交易所（CME）上，較大的訂單更接近隊首；但在 FIFO 交易所上，訂單大小不影響排隊位置

與平均值比較消耗速度

對高頻交易者而言最有價值的指標：當前佇列消耗速度 vs 過去 N 根 K線的平均速度。

• 速度高於平均 → 市價單攻擊性高 → 牆可能被"擊穿" → 我們的成交機率更大
• 速度低於平均 → 市場"凍結" → 牆將堅守 → 訂單會掛住，價格可能離開

市場現有實現概覽

Trading Technologies (TT) — Position In Queue (PIQ)

最成熟的實現。TT 在 Floating Order Book 列中為每筆交易者訂單顯示 PIQ。對於通過資料來源直接提供排隊位置資訊的交易所（CME、ICE），顯示精確值。其餘交易所則為保守估計。

Bookmap Quant

Bookmap 專業版（$499/月）包含訂單排隊位置視覺化和事件匯出功能。Bookmap Quant 使用 MBO 資料，其 L0 API 允許為任意資料來源構建自定義介面卡。

CQG — 排隊位置估算

CQG 為期貨市場提供排隊位置估算功能。該平臺基於 L2/L3 資料計算機率性 PIQ 估算值，並在 DOMTrader 介面中顯示。

Rithmic — 排隊資料提供商

Rithmic 是一家市場資料提供商，提供低延遲的排隊位置評估資料。許多自營交易公司和演算法交易者將其作為基礎設施層，用於構建自己的 PIQ 模型。

Jigsaw Trading — 訂單流視覺化

Jigsaw Trading 專注於帶排隊位置估算的訂單流視覺化。其 Depth & Sales 和 Reconstructed Tape 工具幫助交易者看到價格層級上的真實執行情況。

學術模型

• Moallemi & Yuan (2017) —— 基於 NASDAQ ITCH 資料的排隊位置價值正式模型
• Cont, Stoikov & Talreja (2010) —— 將限價訂單簿建模為生滅過程系統
• Gould & Bonart (2015) —— 佇列失衡作為中間價單 tick 預測指標
• 深度學習方法 —— RNN 模型（哥倫比亞大學，2022）用於評估成交機率和成交時間

市場上尚不存在的產品

目前沒有任何現有產品為加密市場提供專門面向高頻交易機器人的牆內部結構視覺化。 這正是 Marketmaker.cc 可以填補的空白。

對抗操縱者策略

識別虛假掛單牆：真實訂單 vs 高撤單率的幌騙訂單

理解牆的內部結構不僅僅是最佳化自身的執行質量。它是防範操縱的工具，如果運用得當，也是解讀大戶意圖的工具。

幌騙（Spoofing）：虛假掛單牆

幌騙是指提交大額訂單並打算在執行前撤銷。目的是製造虛假的供需印象。

PIQ 分析如何幫助識別：

• 牆體堆積速度。 真實的牆是逐步形成的。幌騙牆瞬間出現。
• 價格逼近時的行為。 真實的牆會留在原地。幌騙牆會"逃跑"。
• 撤單率。 幌騙者在執行前撤銷訂單。追蹤提交/撤銷比率可以即時檢測幌騙。
• 週期性。 幌騙常呈現重複模式：出現 → 消失 → 在新價位出現。

分層下單（Layering）：多層級虛假掛單

Layering 是幌騙的高階形式，在多個價格層級上提交虛假訂單。

PIQ 分析如何幫助識別：

• 關聯撤單。 如果連續 5 個價格層級的訂單同時被撤銷——幾乎可以確定是同一參與者的 layering。
• 盤口不對稱。 真實的流動性通常分佈相對均勻。
• 對成交的反應。 真實的訂單會被執行而不會"逃跑"。

冰山訂單（Iceberg Orders）：隱藏的流動性

冰山訂單是將大額訂單拆分為小的可見部分。當一部分被執行後，下一部分自動出現。

PIQ 分析如何幫助識別：

• "不死"價位模式。 成交量持續被消耗，但總量不減少。
• 吸收分析（Absorption Analysis）。 價格衝擊牆體，執行了可見量，但牆體恢復了。
• 吸收過程中的佇列行為。 每當冰山的一部分被執行並重新排隊到尾部時，我們的位置會"滑向"前方。

做市商作為牆內的"隱形"參與者

專業做市商使用多種策略：

1. 報價轟炸（Quote Stuffing） —— 大量提交和撤銷訂單，"干擾"競爭對手的資料處理
2. 一分搶先（Penny Jumping） —— 以比競爭對手好一個 tick 的價格下單以獲取優先權
3. 動態報價（Dynamic Quoting） —— 根據佇列失衡即時調整訂單
4. 價位保護 —— 當價格逼近時增加流動性

實現：Queue Position Tracker 模組架構

輸入資料

1. WebSocket 订单簿数据流（L2 depth）:
   - 最优买卖价更新
   - 深度更新（每个价格层级的量）

2. WebSocket 成交数据流:
   - 每笔成交: 价格、数量、方向（买/卖）、时间戳

3. 自有订单（来自交易机器人）:
   - order_id、价格、数量、提交时间戳

核心演算法（Python 風格虛擬碼）

class QueuePositionTracker:
    def __init__(self, order_price, order_size, initial_depth):
        self.price = order_price
        self.size = order_size
        self.queue_ahead = initial_depth  # V̂(t₀) = Q(t₀)
        self.queue_behind = 0
        self.fill_velocity = EMA(span=30)  # 成交速度的指数移动平均

    def on_trade(self, trade_price, trade_size):
        """每当我们的价格层级发生成交时调用"""
        if trade_price == self.price:
            self.queue_ahead = max(self.queue_ahead - trade_size, 0)
            self.fill_velocity.update(trade_size)

    def on_depth_change(self, new_depth, change_type):
        """每当我们的价格层级深度变化时调用"""
        if change_type == 'cancel':
            total = self.queue_ahead + self.size + self.queue_behind
            p_ahead = log(1 + self.queue_ahead) / (
                log(1 + self.queue_ahead) + log(1 + self.queue_behind)
            )
            cancelled = abs(new_depth - total)
            self.queue_ahead = max(
                self.queue_ahead - p_ahead * cancelled, 0
            )
            self.queue_behind = max(
                self.queue_behind - (1 - p_ahead) * cancelled, 0
            )
        elif change_type == 'new_order':
            added = new_depth - (self.queue_ahead + self.size + self.queue_behind)
            self.queue_behind += added

    @property
    def estimated_time_to_fill(self):
        """预计成交时间（秒）"""
        if self.fill_velocity.value <= 0:
            return float('inf')
        return self.queue_ahead / self.fill_velocity.value

    @property
    def fill_probability(self, horizon_sec=60):
        """在给定时间范围内的成交概率"""
        expected_volume = self.fill_velocity.value * horizon_sec
        return min(expected_volume / max(self.queue_ahead, 1), 1.0)

關鍵邊界情況

1. 牆被完全"吃穿" —— 如果 queue_ahead 降為 0，下一筆市價單就會執行我們的訂單
2. 大規模撤單（wall pull） —— 牆突然消失，queue_ahead 跳躍式變化
3. 我們的訂單被移動 —— 撤銷並重新提交後，我們排到隊尾
4. 同一面牆內有多筆訂單 —— 每筆獨立追蹤

儀表盤和回測指標

即時指標（高頻交易終端）

回測指標（queue-aware 模擬）

1. Queue-adjusted 成交率 —— 考慮排隊位置後實際成交的訂單比例
2. 有效成交延遲 —— 從提交到執行的實際時間
3. 每筆成交的逆向選擇 —— 成交後價格對我們不利方向的平均移動幅度
4. 佇列速度相關性 —— 佇列消耗速度與後續價格運動之間的相關性

社交盤口：牆內的團隊訂單

三級可見性模型：個人訂單、訂閱者和團隊持倉在牆內的展示

第一層：交易所或交易平臺

如果你是交易所或交易終端，你擁有關於每個使用者每筆訂單位置的絕對知識。平臺可以向每位使用者展示：在他的訂單前後有多少"他人"的量，而不洩露其他參與者的身份。

第二層：Marketmaker.cc 平臺 —— 個人訂單 + 社交層

在 Marketmaker.cc 中，我們計劃實現牆內訂單的三級可見性模型：

個人訂單 —— 基礎層。每位交易者可以看到自己所有訂單的獨立指標。

訂閱者訂單（訊號提供者） —— 通過訂閱分享持倉的交易者。採用 Opt-in 機制：領導者自行決定是否展示持倉。

團隊訂單（交易團隊/基金） —— 對專業團隊最有價值的層級。解決的問題包括：訂單衝突、流動性分配、團隊風險監控、培訓。

許可權模型

┌─────────────────────────────────────────────────────────────┐
│  交易者的订单                                                 │
│                                                             │
│  可见性:                                                     │
│  ├── 交易者本人           → 始终可见                          │
│  ├── 订阅者               → 如果交易者开启了该功能             │
│  │   ├── 显示延迟          → 可配置 (0s–60s)                 │
│  │   ├── 显示数量          → 是 / 隐藏 / 取整                │
│  │   └── 显示预计成交时间   → 是 / 否                         │
│  └── 团队                 → 如果加入了团队                    │
│      ├── 延迟              → 可配置 (0s–5s)                  │
│      ├── 显示数量          → 是（用于风险管理）                │
│      └── 角色可见性        → 交易员 / 经理 / 观察者            │
└─────────────────────────────────────────────────────────────┘

完全透明：DEX 與鏈上訂單簿

在擁有鏈上訂單簿的 DEX 上——尤其是 Hyperliquid——每筆訂單都繫結到特定的錢包地址。我們不僅可以看到聚合後的牆，還可以看到每個參與者的每筆獨立訂單。

然而，要即時處理這些資料，需要搭建自己的 Hyperliquid 區塊鏈節點。

自動識別操縱者的訂單

第四層視覺化——按參與者型別對訂單進行演算法標註：做市商、幌騙者、散戶。分類演算法在多個層面運作：幌騙檢測、做市商分類、軋空場景檢測、交易者數字指紋。

更多詳情請參閱本系列下一篇文章：《交易者數字指紋：如何通過訂單簿行為識別做市商》

結論

訂單簿密集區內的掛單位置分析是從"看盤口"到"理解市場微觀結構"的下一個進化步驟。這是多個領域的交叉地帶：

• 排隊論（queueing theory）—— 用於佇列建模
• 隨機訂單流模型（Stochastic order flow models）—— 用於評估成交機率
• 機器學習 —— 用於幌騙檢測和牆體行為預測
• 低延遲工程 —— 用於即時資料獲取和處理

截至目前，加密市場上沒有任何產品在統一介面中提供完整的"牆作為迷你盤口"視覺化，包含使用者訂單位置、預計成交時間估算、幌騙檢測和 queue-aware 回測。

我們在 Marketmaker.cc 致力於讓每一位交易者——從個人高頻交易者到專業自營團隊——都能使用這些分析工具。

參考文獻與延伸閱讀

• Moallemi C.C., Yuan K. — "A Model for Queue Position Valuation in a Limit Order Book" (Columbia Business School, 2017)
• Cont R., Stoikov S., Talreja R. — "A Stochastic Model for Order Book Dynamics" (2010)
• Gould M.D., Bonart J. — "Queue Imbalance as a One-Tick-Ahead Price Predictor" (2015)
• Rigtorp E. — "Estimating Order Queue Position" (rigtorp.se)
• Do B.L., Putniņš T.J. — "Detecting Layering and Spoofing in Markets" (SSRN, 2023)
• Trading Technologies — PIQ Documentation
• Bookmap — Iceberg Orders Tracker Knowledge Base