คิวภายในกำแพง: การวิเคราะห์ตำแหน่งคำสั่งซื้อในความหนาแน่นของ Order Book

บทนำ: ทำไม Order Book แบบรวมจึงให้ข้อมูลที่ไม่ตรงความจริง

ผู้ซื้อขายทุกคนที่ซื้อขายโดยใช้ order book เห็นภาพเดียวกัน: bids ทางซ้าย, asks ทางขวา, และในแต่ละระดับราคา — ตัวเลขที่แสดงปริมาณรวมของ limit orders ตัวอย่างเช่น:

ราคา 10001  |  150 lots
ราคา 10000  |  2,400 lots   ← กำแพง
ราคา  9999  |  80 lots

2,400 lots ที่ระดับ 10000 — นั่นคือ "กำแพง" (ความหนาแน่น) และนี่คือคำถามที่สำคัญมากซึ่งผู้ซื้อขายส่วนใหญ่ละเลย: คำสั่งซื้อของเราอยู่ที่ตำแหน่งใดกันแน่ภายใน 2,400 lots นั้น?

ราคา 10000  [ 1,800 lots ก่อนเรา ][ คำสั่งของเรา 10 lots ][ 590 lots หลังเรา ]

นี่ไม่ใช่ความอยากรู้ทางวิชาการ มันคือความแตกต่างระหว่างคำสั่งที่ถูกเติมเต็มและไม่ถูกเติมเต็ม ระหว่างกำไรและขาดทุน ระหว่าง backtest ที่แสดง equity curve สวยงามกับความเป็นจริงที่กลยุทธ์ของคุณไม่ทำงาน

Queue Position คืออะไรและทำไมต้องคำนวณ

การแสดงผลคิว FIFO: ตำแหน่งของผู้ซื้อขายในบรรดาคำสั่งอื่นที่ระดับราคา

FIFO และความเป็นจริงของ Exchange

Exchange ส่วนใหญ่ — ทั้งแบบดั้งเดิม (CME, NASDAQ) และแบบคริปโต (Binance, Bybit, OKX) — ใช้กฎ Price-Time Priority (FIFO) ซึ่งหมายความว่า: ที่ราคาเดียวกัน คำสั่งที่วางก่อนจะถูกเติมเต็มก่อน

เมื่อ market sell order มาถึงและ "ชน" ระดับราคา bid ของเรา มันจะเติมเต็ม limit orders ตามลำดับจากหัวคิวไปยังหางคิว หาก market order ไม่ใหญ่พอที่จะถึงตำแหน่งของเราในคิว — เราจะยังคงไม่ถูกเติมเต็ม

สององค์ประกอบของมูลค่า Queue Position

งานวิจัยเชิงวิชาการ (Moallemi & Yuan, Columbia Business School, 2017) ระบุองค์ประกอบสองประการของมูลค่า queue position:

1. องค์ประกอบแบบสถิต — การแลกเปลี่ยนระหว่างการจับ spread และ adverse selection ยิ่งเราอยู่ห่างจากหัวคิวมากเท่าไร โอกาสที่เราจะถูกเติมเต็มโดย large informed order (แทนที่จะเป็น noise) ก็ยิ่งสูงขึ้น กล่าวง่ายๆ: ถ้าคุณถูกเติมเต็มท้ายคิว — ราคามักจะเคลื่อนที่ต่อต้านคุณอยู่แล้ว

2. องค์ประกอบแบบไดนามิก — ทางเลือกที่ queue position ให้เมื่อมีการปรับปรุงตามเวลา เมื่อคำสั่งที่อยู่ข้างหน้าเราถูกยกเลิกหรือเติมเต็ม ตำแหน่งของเราจะดีขึ้นโดยไม่ต้องทำอะไร

ข้อมูลเชิงประจักษ์แสดงให้เห็นว่าสำหรับ instrument ที่มีขนาด tick ขนาดใหญ่ มูลค่าของ queue position อาจเทียบเคียงได้กับขนาด spread นี่คือขนาดที่มหาศาล

วิธีประมาณ Queue Position ของคุณ

ปัญหาการประมาณ

เราวาง limit order ขนาด S ที่ราคา P ณ เวลาที่วาง มี Q lots อยู่ที่ระดับราคานั้นอยู่แล้ว การประมาณตำแหน่งเริ่มต้นของเรา:

V̂(t₀) = Q(t₀)     — จำนวน lots ที่อยู่ข้างหน้าเรา

จากนั้น เราติดตามการเปลี่ยนแปลงปริมาณทั้งหมดที่ระดับราคาของเรา นี่คืออัลกอริทึมหลักที่อธิบายโดย Erik Rigtorp และนำไปใช้งานใน products ของ Trading Technologies (TT), Bookmap, และอื่นๆ

อัลกอริทึมอัปเดต

สำหรับการลด ΔQ แต่ละครั้งที่ระดับราคา เราต้องพิจารณา: คำสั่งนั้นอยู่ ข้างหน้าเรา หรือ หลังเรา?

ถ้าเราสามารถแยกแยะ fills (executions) จาก cancellations:

• Fill (execution): ลดคิวข้างหน้าเราอย่างชัดเจน → V̂ = max(V̂ + ΔQ, 0)
• Cancel (cancellation): ไม่แน่นอน — คำสั่งที่ถูกยกเลิกอาจอยู่ข้างหน้าหรือหลังเรา

สำหรับ cancellations จะใช้แบบจำลองความน่าจะเป็น:

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) หรือ identity function ความหมายเชิงสัญชาตญาณ: ยิ่งปริมาณข้างหน้าเรามากกว่าปริมาณหลังเรามากเท่าไร โอกาสที่การยกเลิกเกิดขึ้นข้างหน้าเราก็ยิ่งสูง

ระดับข้อมูลและความเป็นจริงของตลาดคริปโต

คุณภาพการประมาณขึ้นอยู่กับความละเอียดของข้อมูลโดยตรง:

ในคริปโต สถานการณ์เป็นดังนี้:

• Binance — ให้ L2 depth stream พร้อมอัปเดตทุก 100ms ข้อมูล L3 (MBO) ไม่เปิดให้สาธารณะ
• Coinbase — หนึ่งใน CEX ไม่กี่แห่งที่ให้ L3 stream ผ่าน WebSocket พร้อมข้อมูลคำสั่งทั้งหมด
• CME (BTC/ETH futures) — ข้อมูล MBO เต็มรูปแบบผ่าน ITCH feed

ผู้ซื้อขายคริปโตส่วนใหญ่ทำงานกับ L2 ซึ่งหมายความว่าพวกเขาพึ่งพาการประมาณเชิงความน่าจะเป็น แต่แม้แต่การประมาณเชิงความน่าจะเป็นก็ดีกว่าไม่มีเลยอย่างชัดเจน

การแสดงผล: กำแพงในฐานะ Order Book ภายใน

เราเสนอให้แสดงแต่ละความหนาแน่นที่มีนัยสำคัญ (กำแพง) เป็น mini order book ภายใน order book:

╔════════════════════════════════════════════════════════════════╗
║  ราคา 10001  │  150 lots                                      ║
╠════════════════════════════════════════════════════════════════╣
║  ราคา 10000  │  [████████████░░░▓▓░░░░░░░]  2,400 lots        ║
║              │   ↑ 1,800 ก่อนเรา  ↑ เรา  ↑ 590 หลัง         ║
║              │   อัตราการระบาย: ~120 lots/วินาที              ║
║              │   ETA ถึงการเติมเต็ม: ~15 วินาที               ║
╠════════════════════════════════════════════════════════════════╣
║  ราคา  9999  │  80 lots                                       ║
╚════════════════════════════════════════════════════════════════╝

สิ่งที่คำนวณแบบ Real-Time

1. Lots ข้างหน้าคำสั่งของเรา — การประมาณปริมาณที่ต้องถูกเติมเต็มหรือยกเลิกก่อนถึงเรา

2. Lots หลังคำสั่งของเรา — ปริมาณที่วางหลังเรา หากกำแพง "พองตัว" อย่างรวดเร็วจากหาง — ผู้เข้าร่วมอื่นถือว่าระดับนี้น่าสนใจ

3. Queue drain rate — คำนวณจาก trades จริง (executions) ที่ระดับราคานี้ แสดงเป็น lots/วินาที

4. Estimated Time to Fill (ETF) — การพยากรณ์เวลาจนกว่าคำสั่งของเราจะถูกเติมเต็ม คำนวณเป็น lots_ahead / drain_rate

5. หลายคำสั่งในความหนาแน่นเดียว — บอทสามารถติดตามตำแหน่งของคำสั่งแต่ละรายการถ้ามีหลายรายการในกำแพงเดียวกัน

การประยุกต์ใช้ใน Scalping

การเปรียบเทียบ backtesting แบบ naive กับ queue-aware: ความน่าจะเป็นการเติมเต็มจริงกับการประมาณที่มองโลกในแง่ดี

ปัญหากับ Backtesting แบบ Candlestick

backtest แบบคลาสสิกบนแท่งเทียน OHLCV ทำงานดังนี้: ถ้าราคาถึง limit order ของเรา — นับว่าถูกเติมเต็ม แต่นี่คือข้อผิดพลาดร้ายแรง:

ตัวอย่าง เรามี buy-limit ที่ 10000 ในแท่งเทียน 1 นาที low = 10000 backtest แบบแท่งเทียนนับว่าเติมเต็ม แต่ในความเป็นจริง:

• มีกำแพง 5,000 lots ที่ระดับ 10000
• คำสั่งของเราอยู่ท้ายคิว (ตำแหน่ง 4,800)
• มีการซื้อขายเพียง 2,000 lots ผ่านระดับนั้นในนาทีนี้
• ในความเป็นจริง คำสั่งของเรา จะไม่ถูกเติมเต็ม

Queue-aware backtesting แก้ปัญหานี้: มันจำลอง queue position นับปริมาณการซื้อขายที่ระดับจากข้อมูล tick และพิจารณาว่าปริมาณที่ซื้อขายเพียงพอที่จะถึงตำแหน่งของเราหรือไม่

มากกว่าหนึ่งครั้งการเติมเต็มต่อนาที

ใน scalping ที่ active คำสั่งสามารถถูกเติมเต็มและวางใหม่ได้หลายครั้งภายในหนึ่งนาที backtest แบบแท่งเทียนไม่สามารถจำลองสิ่งนี้ได้ เฉพาะการวิเคราะห์ระดับ tick พร้อมการจำลองคิวเท่านั้นที่ช่วยให้คุณ:

• กำหนดเวลาที่แน่นอนของการเติมเต็มแต่ละครั้ง
• เข้าใจว่าเรามีเวลาวางคำสั่งใหม่หรือไม่
• ประมาณจำนวนครั้งที่กลยุทธ์จะทำงานจริงภายในช่วงเวลา

การทำนายเวลาจนถึงการเติมเต็ม

บอทที่รู้ queue position และอัตราการ "ระบาย" กำแพงปัจจุบันสามารถ:

1. คำนวณ ETA — เวลาโดยประมาณจนถึงการเติมเต็ม
2. เปรียบเทียบ ETA กับการพยากรณ์การเคลื่อนไหวราคา — ถ้า ETA = 30 วินาที แต่โมเดลของเราพยากรณ์การกลับตัวใน 10 วินาที เราควรยกเลิกคำสั่ง
3. ปรับขนาดคำสั่ง — คำสั่งที่ใหญ่กว่าอยู่ใกล้หัวคิวบน exchange แบบ pro-rata (CME) แต่บน FIFO exchanges ขนาดไม่มีผลต่อ queue position

การเปรียบเทียบ Drain Rate กับค่าเฉลี่ย

เมตริกที่มีค่ายิ่งสำหรับ scalper: อัตราการระบายคิวปัจจุบันเทียบกับอัตราเฉลี่ยในช่วง N แท่งเทียน

• อัตราสูงกว่าค่าเฉลี่ย → ความก้าวร้าวของ market order สูง → กำแพงอาจ "ทะลุ" → โอกาสเติมเต็มสูงขึ้น
• อัตราต่ำกว่าค่าเฉลี่ย → ตลาด "หยุดนิ่ง" → กำแพงจะยึด → คำสั่งจะค้างอยู่ และราคาอาจเคลื่อนออกไป

ที่ซึ่งสิ่งนี้ถูกนำไปใช้แล้ว: ภาพรวมตลาด

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

การนำไปใช้ที่ครบครันที่สุด TT แสดง PIQ สำหรับคำสั่งของผู้ซื้อขายแต่ละรายในคอลัมน์ Floating Order Book สำหรับ exchanges ที่ให้ข้อมูล queue position โดยตรงผ่าน feed ของพวกเขา (CME, ICE) จะแสดงค่าที่แม่นยำ สำหรับรายอื่น — การประมาณแบบอนุรักษ์นิยม

Bookmap Quant

เวอร์ชันมืออาชีพของ Bookmap ($499/เดือน) รวมการแสดงผล queue position ของคำสั่งและการส่งออก event Bookmap Quant ใช้ข้อมูล MBO และ L0 API ช่วยให้สร้าง adapter แบบกำหนดเองสำหรับแหล่งข้อมูลใดก็ได้

CQG — Queue Position Estimation

CQG ให้การประมาณ queue position สำหรับตลาด futures แพลตฟอร์มคำนวณการประมาณ PIQ เชิงความน่าจะเป็นโดยอิงจากข้อมูล L2/L3 และแสดงในอินเทอร์เฟซ DOMTrader

Rithmic — Order Queue Data

Rithmic คือผู้ให้บริการข้อมูลตลาดที่เสนอการเข้าถึงข้อมูลแบบ low-latency สำหรับการประมาณ queue position ใช้เป็น infrastructure layer โดย prop trading firms และ algorithmic traders หลายรายเพื่อสร้างโมเดล PIQ ของตนเอง

Jigsaw Trading — Order Flow Visualization

Jigsaw Trading เชี่ยวชาญด้านการแสดงผล order flow พร้อมการประมาณ queue position เครื่องมือ Depth & Sales และ Reconstructed Tape ช่วยให้ผู้ซื้อขายเห็นภาพการ execution จริงที่ระดับราคา

แบบจำลองเชิงวิชาการ

• Moallemi & Yuan (2017) — แบบจำลองเชิงรูปแบบสำหรับการประเมินมูลค่า queue position โดยอิงจากข้อมูล NASDAQ ITCH
• Cont, Stoikov & Talreja (2010) — แบบจำลอง limit order book เป็นระบบ birth-death process
• Gould & Bonart (2015) — queue imbalance เป็นตัวทำนาย mid-price movement ล่วงหน้าหนึ่ง tick
• Deep Learning approaches — โมเดล RNN (Columbia, 2022) สำหรับประมาณความน่าจะเป็นการเติมเต็มและเวลาการเติมเต็ม

สิ่งที่ยังไม่มีในตลาด

ไม่มี product ที่มีอยู่ใดๆ ที่เสนอการแสดงผลโครงสร้างภายในของกำแพงสำหรับตลาดคริปโตในรูปแบบที่ออกแบบมาสำหรับ scalping bot นี่คือ niche ที่ Marketmaker.cc สามารถเติมเต็มได้

การต่อต้านกลยุทธ์ผู้บิดเบือน

การตรวจจับกำแพงปลอม: คำสั่งจริงกับบล็อก spoofing ที่มีอัตราการยกเลิกสูง

การเข้าใจโครงสร้างภายในของกำแพงไม่ใช่แค่การปรับ execution ของตัวเองให้เหมาะสม มันคือเครื่องมือสำหรับ การป้องกันการบิดเบือน และเมื่อใช้อย่างชำนาญ คือเครื่องมือสำหรับ การอ่านความตั้งใจของผู้เล่นรายใหญ่

Spoofing: กำแพงปลอม

Spoofing คือการวางคำสั่งขนาดใหญ่โดยมีความตั้งใจจะยกเลิกก่อนการ execution เป้าหมายคือสร้างความประทับใจเท็จเกี่ยวกับ supply/demand

PIQ analysis ช่วยได้อย่างไร:

• ความเร็วในการสร้างกำแพง กำแพงจริงสร้างขึ้นทีละน้อย กำแพง spoofing ปรากฏทันที
• พฤติกรรมเมื่อราคาเข้าใกล้ กำแพงจริงอยู่นิ่ง กำแพง spoof "วิ่งหนี"
• Cancel rate Spoofers ยกเลิกคำสั่งก่อน execution การติดตามอัตราส่วนที่วาง/ยกเลิกช่วยให้ตรวจจับ spoof แบบ real-time ได้
• ความเป็นวัฏจักร Spoofing มักมีรูปแบบซ้ำๆ: ปรากฏ → หายไป → ปรากฏที่ระดับใหม่

Layering: ระดับปลอมแบบ Cascading

Layering คือรูปแบบที่ซับซ้อนกว่าของ spoofing ที่วางคำสั่งปลอมในหลายระดับราคา

PIQ analysis ช่วยได้อย่างไร:

• การยกเลิกที่สัมพันธ์กัน หากคำสั่งใน 5 ระดับต่อเนื่องถูกยกเลิกพร้อมกัน — เกือบแน่นอนว่าเป็น layering โดยผู้เข้าร่วมรายเดียว
• ความไม่สมดุลของ order book สภาพคล่องจริงโดยปกติกระจายตัวค่อนข้างสม่ำเสมอ
• ปฏิกิริยาต่อ fills คำสั่งจริงถูกเติมเต็มและไม่ "วิ่งหนี"

Iceberg Orders: สภาพคล่องซ่อนเร้น

Iceberg คือคำสั่งขนาดใหญ่ที่แบ่งเป็นส่วนเล็กๆ ที่มองเห็นได้ หลังจากส่วนหนึ่งถูกเติมเต็ม ส่วนถัดไปจะปรากฏโดยอัตโนมัติ

PIQ analysis ช่วยได้อย่างไร:

• รูปแบบระดับ "อมตะ" ปริมาณถูกเติมเต็มอย่างต่อเนื่องแต่ไม่ลดลง
• การวิเคราะห์การดูดซับ ราคาชนกำแพง เติมเต็มปริมาณที่มองเห็น แต่กำแพงสร้างขึ้นใหม่
• พฤติกรรมคิวระหว่างการดูดซับ ตำแหน่งของเรา "เลื่อน" ไปข้างหน้าทุกครั้งที่ iceberg slice ถูกเติมเต็มและวางใหม่ท้ายคิว

Market Maker ในฐานะผู้เข้าร่วม "มองไม่เห็น" ในกำแพง

Professional market makers ใช้หลายยุทธวิธี:

1. Quote stuffing — การวางและยกเลิกคำสั่งจำนวนมากเพื่อ "ปนเปื้อน" ข้อมูลของคู่แข่ง
2. Penny jumping — การวางคำสั่งที่ดีกว่าคู่แข่งหนึ่ง tick เพื่อจับ priority
3. Dynamic quoting — การปรับคำสั่งแบบ real-time เมื่อ queue imbalance เปลี่ยนแปลง
4. Level defense — การเพิ่มสภาพคล่องเมื่อราคาเข้าใกล้

การนำไปใช้: สถาปัตยกรรมโมดูล Queue Position Tracker

ข้อมูล Input

1. WebSocket order book stream (L2 depth):
   - Best bid/ask updates
   - Depth updates (ปริมาณที่แต่ละระดับราคา)

2. WebSocket trade stream:
   - การซื้อขายแต่ละรายการ: ราคา, ปริมาณ, ด้าน (buy/sell), timestamp

3. คำสั่งของตัวเอง (จาก trading bot):
   - order_id, ราคา, ขนาด, timestamp ที่วาง

อัลกอริทึมหลัก (Python-like Pseudocode)

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)  # EMA of fill rate

    def on_trade(self, trade_price, trade_size):
        """Called on each trade at our price level"""
        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):
        """Called when depth changes at our price level"""
        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):
        """Estimated time to fill in seconds"""
        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):
        """Probability of fill within a given horizon"""
        expected_volume = self.fill_velocity.value * horizon_sec
        return min(expected_volume / max(self.queue_ahead, 1), 1.0)

Edge Cases ที่สำคัญ

1. กำแพงถูก "กินหมด" อย่างสมบูรณ์ — ถ้า queue_ahead ลดลงเป็น 0 market order ถัดไปจะเติมเต็มเรา
2. การยกเลิกจำนวนมาก (wall pull) — กำแพงหายไปอย่างกะทันหัน queue_ahead เปลี่ยนแปลงอย่างรวดเร็ว
3. คำสั่งของเราถูกย้าย — เมื่อยกเลิกและวางใหม่ เราจะไปท้ายคิว
4. หลายคำสั่งในกำแพงเดียวกัน — แต่ละรายการถูกติดตามแยกกัน

เมตริกสำหรับ Dashboard และ Backtesting

Real-Time (Scalping Terminal)

สำหรับ Backtesting (Queue-Aware Simulation)

1. Queue-adjusted fill rate — เปอร์เซ็นต์ของคำสั่งที่ถูกเติมเต็มจริงโดยคำนึงถึง queue position
2. Effective fill latency — เวลาจริงจากการวางถึง execution
3. Adverse selection per fill — การเคลื่อนไหวราคาเฉลี่ยต่อต้านเราหลังการเติมเต็ม
4. Queue velocity correlation — ความสัมพันธ์ระหว่างอัตราการระบายคิวและการเคลื่อนไหวราคาถัดมา

Social Order Book: คำสั่งทีมภายในกำแพง

โมเดลการมองเห็นสามระดับ: คำสั่งส่วนตัว, subscriptions, และตำแหน่งทีมภายในกำแพง

ระดับที่ 1: Exchange หรือ Trading Platform

ถ้าคุณเป็น exchange หรือ trading terminal คุณมี ความรู้ที่สมบูรณ์ เกี่ยวกับตำแหน่งคำสั่งของทุกผู้ใช้ แพลตฟอร์มสามารถแสดงให้แต่ละผู้ใช้เห็นว่าปริมาณ "อื่น" เท่าใดยืนอยู่ก่อนและหลังคำสั่งของพวกเขา โดยไม่เปิดเผยตัวตนของผู้เข้าร่วมอื่น

ระดับที่ 2: Marketmaker.cc Platform — คำสั่งส่วนตัว + Social Layer

ที่ Marketmaker.cc เราวางแผนนำไปใช้โมเดลการมองเห็นคำสั่งสามระดับภายในกำแพง:

คำสั่งส่วนตัว — ชั้นพื้นฐาน ผู้ซื้อขายแต่ละคนเห็นคำสั่งของตนเองทั้งหมดพร้อมเมตริกเฉพาะบุคคล

คำสั่ง Subscription (signal providers) — ผู้ซื้อขายที่แชร์ตำแหน่งผ่าน subscription กลไก opt-in: leader ตัดสินใจว่าจะแสดงตำแหน่งหรือไม่

คำสั่งทีม (trading team / fund) — ชั้นที่มีค่ามากที่สุดสำหรับกลุ่มมืออาชีพ แก้ปัญหา: ความขัดแย้งของคำสั่ง, การจัดสรรสภาพคล่อง, การติดตาม risk ของทีม, การฝึกอบรม

Permission Model

┌─────────────────────────────────────────────────────────────┐
│  คำสั่งของผู้ซื้อขาย                                         │
│                                                              │
│  มองเห็นได้โดย:                                              │
│  ├── ผู้ซื้อขายเอง          → เสมอ                           │
│  ├── Subscribers            → ถ้าผู้ซื้อขายเปิดใช้งาน        │
│  │   ├── หน่วงเวลาแสดงผล    → ตั้งค่าได้ (0s–60s)            │
│  │   ├── แสดงขนาด           → ใช่ / ซ่อน / ปัดเศษ           │
│  │   └── แสดง ETA           → ใช่ / ไม่                      │
│  └── ทีม                    → ถ้าเป็นส่วนหนึ่งของทีม         │
│      ├── หน่วงเวลา          → ตั้งค่าได้ (0s–5s)             │
│      ├── แสดงขนาด           → ใช่ (สำหรับการจัดการ risk)     │
│      └── การมองเห็นตามบทบาท → trader / manager / viewer      │
└─────────────────────────────────────────────────────────────┘

ความโปร่งใสเต็มรูปแบบ: DEX Exchanges และ On-Chain Order Books

บน DEX exchanges ที่มี on-chain order books — โดยเฉพาะ Hyperliquid — ทุกคำสั่งเชื่อมโยงกับ wallet address เฉพาะ เราสามารถเห็นไม่แค่กำแพงรวม แต่คำสั่งของผู้เข้าร่วมแต่ละคน

อย่างไรก็ตาม การทำงานกับข้อมูลนี้แบบ real-time ต้องการ การรัน Hyperliquid blockchain node ของตัวเอง

การระบุคำสั่งผู้บิดเบือนโดยอัตโนมัติ

ชั้นการแสดงผลที่สี่ — การจำแนกคำสั่งเชิงอัลกอริทึมตามประเภทผู้เข้าร่วม: market makers, spoofers, retail อัลกอริทึมการจำแนกทำงานในหลายระดับ: การตรวจจับ spoofing, การจำแนก market maker, การตรวจจับสถานการณ์ squeeze, และลายนิ้วมือดิจิทัลของผู้ซื้อขาย

เพิ่มเติมเกี่ยวกับเรื่องนี้ในบทความถัดไปในซีรีส์: "ลายนิ้วมือดิจิทัลของผู้ซื้อขาย: วิธีระบุ Market Maker จากพฤติกรรม Order Book"

บทสรุป

การวิเคราะห์ตำแหน่งคำสั่งภายในความหนาแน่นของ order book คือขั้นวิวัฒนาการถัดไปจาก "การมอง order book" สู่ "การเข้าใจ market microstructure" นี่คือดินแดนที่สิ่งต่อไปนี้มาบรรจบกัน:

• Queueing theory — สำหรับการจำลองคิว
• Stochastic order flow models — สำหรับประมาณความน่าจะเป็นการเติมเต็ม
• Machine learning — สำหรับการตรวจจับ spoofing และการทำนายพฤติกรรมกำแพง
• Low-latency engineering — สำหรับรับและประมวลผลข้อมูลแบบ real-time

ณ วันนี้ ไม่มี product ใดในตลาดคริปโตที่เสนอการแสดงผลที่ครอบคลุมของ "กำแพงในฐานะ mini order book" พร้อมตำแหน่งคำสั่งของผู้ใช้, การประมาณ ETA, การตรวจจับ spoofing, และ queue-aware backtesting ในอินเทอร์เฟซเดียว

ที่ Marketmaker.cc เรากำลังทำงานเพื่อทำให้ analytics นี้เข้าถึงได้สำหรับผู้ซื้อขายทุกคน — ตั้งแต่ scalpers เดี่ยวไปจนถึงทีม prop trading

แหล่งที่มาและการอ่านเพิ่มเติม

• 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