Smart Order Routing ในคริปโต: คำสั่งเดียว สิบสอง Venue ไม่มี NBBO

คุณต้องซื้อ BTC 400 เหรียญ Binance มี depth มากที่สุด OKX และ Bybit ต่างก็แสดง size ที่ดีพอสมควรในระดับราคาที่ห่างออกไปหนึ่ง tick Coinbase เสนอราคาที่ดูดีกว่าในหน้าจอ แต่เป็น USD ไม่ใช่ USDT top of book ของ Kraken ดูยอดเยี่ยม แต่ข้อมูลเก่าไปแล้ว 400 มิลลิวินาที Upbit ดียิ่งกว่านั้นอีก แต่คุณไม่มีการอนุมัติ compliance สำหรับเกาหลี และก็ไม่มี KRW เช่นกัน เทรดเดอร์ตลาดหุ้นที่เจอความยุ่งเหยิงแบบนี้คงหยิบ smart order router มาใช้แล้วเลิกคิด เพราะในตลาดหุ้น ส่วนที่ยากของการ routing ถูกกำกับดูแลจนกลายเป็นโครงสร้างพื้นฐานไปแล้วเมื่อสองทศวรรษก่อน แต่ในคริปโต คุณคือโครงสร้างพื้นฐานนั้นเอง ไม่มี consolidated tape ไม่มีกฎ order-protection ไม่มีเพดานค่าธรรมเนียม ไม่มี netted settlement — และที่สำคัญที่สุดคือ ไม่มีความสามารถในการเทรดที่ใดก็ตามที่เงินทุนของคุณยังไม่ได้อยู่ตรงนั้น

บทความนี้ว่าด้วยการสร้าง router ขึ้นมาทั้งที่สภาพแวดล้อมเป็นแบบนี้ นั่นคือ consolidated book และเหตุผลที่การ routing แบบ best-price อย่างไร้เดียงสาทำให้ขาดทุน ปัญหาการจัดสรร (allocation) ในรูป convex program ที่คุณแก้ได้จริงภายใน deadline ของ child order ข้อจำกัดด้านเงินทุนที่ทำให้ SOR ในคริปโตแยกไม่ออกจากการบริหารคลัง (treasury management) การ routing แบบ maker-aware ข้ามหลาย venue และ TCA feedback loop ที่บอกคุณว่าทั้งหมดนี้ได้ผลจริงหรือไม่ มันคือบทความคู่แฝดเชิงวิศวกรรมของ Complex Arbitrage Execution in Rust — บทความนั้นครอบคลุมระดับนาโนวินาที ส่วนบทความนี้ครอบคลุมระดับการตัดสินใจ

สิ่งที่ SOR ในตลาดหุ้นได้มาฟรีๆ

คุ้มค่าที่จะระบุให้ชัดเจนว่าการ routing ในตลาดหุ้นสหรัฐฯ ได้อะไรมาจากการกำกับดูแล เพราะทุกรายการในลิสต์นี้คือสิ่งที่คุณต้องสร้างขึ้นมาเองหรือใช้ชีวิตอยู่โดยไม่มีมันอย่างมีสติ

Regulation NMS (SEC, 2005) ทำสามสิ่งที่สำคัญตรงนี้ Rule 611 หรือ Order Protection Rule ห้ามการ execute ในราคาที่แย่กว่า protected quote ที่แสดงอยู่บนตลาดอื่น — เรียกว่า "trade-through" — ซึ่งบังคับให้โบรกเกอร์ทุกรายต้อง route ไปยังราคาที่ดีที่สุดที่แสดงอยู่ หรือไม่ก็กวาดมันด้วย intermarket sweep orders Rule 610 กำหนดเพดานค่าธรรมเนียมการเข้าถึง (access fee) ที่ venue ใดๆ จะเรียกเก็บสำหรับการ take protected quote ไว้ที่ $0.003 ต่อหุ้น ทำให้ราคาที่แสดงเปรียบเทียบกันได้ระหว่าง venue ในกรอบ 30 mils และ consolidated tape (the SIPs) เผยแพร่ National Best Bid and Offer ซึ่งเป็นคำตอบทางการเดียวสำหรับคำถามว่า "ตลาดตอนนี้เป็นอย่างไร"

บทสรุปทางวิชาการเกี่ยวกับสถาปัตยกรรมนี้คือมันทำงานได้ดีอย่างน่าประหลาดใจ O'Hara and Ye (2011), "Is market fragmentation harming market quality?" (Journal of Financial Economics 100(3), 459–474) ศึกษาหุ้นสหรัฐฯ ในระดับ fragmentation ต่างๆ และพบว่าหุ้นที่กระจัดกระจายมากกว่ากลับมี transaction cost ต่ำกว่า และ execution เร็วกว่า โดยราคาใกล้เคียงกับ random walk มากขึ้น บทสรุปของพวกเขาคือวลีสำคัญ นั่นคือตลาดหุ้นสหรัฐฯ ทำงานเสมือน "ตลาดเสมือนเดียวที่มีจุดเข้าหลายจุด" การกระจัดกระจายไม่เป็นอันตรายเมื่อ smart router บวกกับ trade-through protection เย็บชิ้นส่วนที่กระจัดกระจายกลับเข้าด้วยกัน Foucault and Menkveld (2008), "Competition for Order Flow and Smart Order Routing Systems" (Journal of Finance 63(1), 119–158) แสดงกลไกนี้ในตลาดเนเธอร์แลนด์ เมื่อ limit order book ที่สอง (EuroSETS ของ LSE) เข้ามาแข่งกับ Euronext depth ที่รวมกัน เพิ่มขึ้น และ liquidity supply บน venue หนึ่งถูกหน่วงโดยตรงจากอัตรา trade-through ของมัน — router ที่เมินเฉย venue ใดก็ทำลายแรงจูงใจในการเสนอราคาของ venue นั้น

แม้ในโลกที่ถูกกำกับดูแลแบบนี้ มุมมองแบบ consolidated ก็ยังเป็นเรื่องโกหกในช่วงเวลาสั้นๆ Ding, Hanna, and Hendershott (2014), "How Slow Is the NBBO? A Comparison with Direct Exchange Feeds" (Financial Review 49(2), 313–332) วัด SIP NBBO เทียบกับ NBBO ที่สร้างจาก direct exchange feed ใน data center เดียวกัน และพบความคลาดเคลื่อนหลายครั้งต่อวินาทีในหุ้นที่มีการซื้อขายคึกคัก โดยทั่วไปกินเวลาหนึ่งถึงสองมิลลิวินาที ซึ่งเป็น latency ล้วนๆ จากการรวมข้อมูลและการส่งผ่าน จำตัวเลขนี้ไว้ นี่คือเวอร์ชันตลาดหุ้นของปัญหาที่ในคริปโตแย่กว่าหนึ่งถึงสองระดับขนาด (order of magnitude)

ทีนี้ลบทั้งหมดนี้ทิ้งไป คริปโตไม่มี NBBO เพราะไม่มี SIP ไม่มีกฎ trade-through venue จะปริ้นราคาให้คุณในราคาที่ห่างจาก quote ของอีก venue หนึ่งห้า tick ได้อย่างสบายใจ และไม่มีใครยื่นเรื่องร้องเรียนอะไรทั้งสิ้น ไม่มีเพดานค่าธรรมเนียม taker fee มีตั้งแต่ tier ที่เจรจาต่อรองได้ต่ำกว่า basis point ไปจนถึงตาราง retail 10 bps ดังนั้น การเรียงลำดับตามราคาที่แสดงกับการเรียงลำดับตามราคาสุทธิมักจะไม่ตรงกัน และไม่มี consolidated clearing แต่ละ exchange เป็น silo ของตัวเองที่มี balance แบบ prefunded คุณคือ SIP, router และ clearing firm ในเวลาเดียวกัน

การสร้าง Consolidated Book และเหตุผลที่การ Routing แบบ Best-Price อย่างไร้เดียงสาล้มเหลว

พื้นฐานทางวิศวกรรมนั้นไม่หรูหราอะไร นั่นคือ WebSocket L2 feed จำนวน N ตัว, การจัดการช่องว่างของ sequence number รายเวนิว, การ normalize symbol และ tick size, และการ normalize สกุลเงิน quote (book BTC-USD กับ book BTC-USDT ต่างกันตามอัตรา USDT/USD ซึ่งไม่ได้เท่ากับ 1.0 เป๊ะ และบางครั้งก็ห่างจาก 1.0 มากทีเดียว) รวม book ที่ normalize แล้วเข้าเป็น ladder เดียวที่เรียงตามราคา โดยแท็กทุกระดับด้วย venue ของมัน และ — สิ่งที่สำคัญมาก — อายุของ snapshot ที่มันมาจาก ถ้า merged book ของคุณไม่มี quote age รายเวนิวเป็น field หลัก แสดงว่าคุณสร้าง screensaver ไม่ใช่ router

router แบบไร้เดียงสาจะเดินไปตาม merged ladder นี้แบบ greedy โดยเลือกราคาสุทธิที่ดีที่สุดก่อน มันล้มเหลวด้วยสามเหตุผลที่แตกต่างกัน และคุ้มค่าที่จะแยกมันออกจากกันเพราะวิธีแก้ไขต่างกัน

Quote ที่เก่าและความเหลื่อมของ latency venue ของคุณไม่ได้ส่งข้อมูลด้วย latency เท่ากัน feed ที่ colocate อาจเก่าแค่ 3 มิลลิวินาทีตอนที่คุณใช้งาน ในขณะที่ public WebSocket จาก venue บนอีกทวีปหนึ่งอาจเก่าถึง 300 มิลลิวินาที top of book ที่รวมกันจึงเป็นภาพผสมของอดีตที่ต่างกัน เมื่อ BTC เคลื่อนไหว 10 bps ใน 200 มิลลิวินาที ซึ่งเป็นเรื่องปกติ quote ของ venue ที่เก่าจะดูน่าสนใจอย่างเป็นระบบในด้านที่ผิดพอดี การ route ไปหามันคือการซื้อการแข่งขันที่คุณแพ้ไปแล้ว quote หายไปแล้ว IOC ของคุณกลับมาแบบว่าง หรือ fill แค่บางส่วน และในเวลาที่คุณ re-route ใหม่ venue ที่สดกว่าก็ปรับราคาไปแล้ว นี่คือปัญหา SIP dislocation 1–2 มิลลิวินาทีของ Ding–Hanna–Hendershott เวอร์ชันคริปโต เพียงแต่ความคลาดเคลื่อนของคุณกินเวลาหลายร้อยมิลลิวินาที และไม่มีใครมีพันธะต้องรักษาสัญญาอะไรเลย

Liquidity หลอก (Phantom Liquidity) การรวม size ที่แสดงข้าม venue เป็นการนับซ้ำ เพราะ inventory ของ market maker คนเดียวกันถูกเสนอในหลายที่พร้อมกัน Van Kervel (2015), "Competition for Order Flow with Fast and Slow Traders" (Review of Financial Studies 28(7), 2094–2127) บันทึกเรื่องนี้ในตลาดหุ้นที่กระจัดกระจาย การเทรดใน venue หนึ่งตามมาด้วยการยกเลิก limit order ขนาดใหญ่ใน venue คู่แข่งภายในเวลาไม่กี่มิลลิวินาที ตรงตามที่โมเดลทำนายไว้ นั่นคือ fast liquidity provider เสนอ size ซ้ำกันทุกที่ แล้วดึงสำเนากลับทันทีที่โดน hit สักที่หนึ่ง market maker ในคริปโตก็เล่นเกมเดียวกันข้าม Binance/OKX/Bybit ดังนั้น depth ที่รวมกันแบบ เข้าถึงได้จริง จึงน้อยกว่า depth ที่รวมกันแบบ แสดงบนหน้าจอ อย่างมีนัยสำคัญ และส่วนต่างนี้จะยิ่งมากขึ้นตามความเป็นลำดับ (แทนที่จะเป็นพร้อมกัน) ในการยิงไปที่ venue ต่างๆ ถ้า router ของคุณส่ง child order ทีละ venue โดยรอ fill confirmation ของแต่ละอันก่อน คุณกำลังเก็บเกี่ยวจากตัวเอง เพราะ fill แต่ละครั้งเป็นสัญญาณให้ตลาดที่เหลือรีบยกเลิก

ค่าธรรมเนียมจัดลำดับ Ladder ใหม่ venue ที่แสดงราคาดิบดีที่สุดพร้อม taker fee 7.5 bps มักเป็นราคาสุทธิที่ แย่ที่สุด ใน book ฟังดูชัดเจนเกินกว่าจะต้องพูด แต่การ routing แบบ "ราคาที่แสดงดีที่สุด" คือสิ่งที่ router คริปโตรุ่นแรกส่วนใหญ่ (และผลิตภัณฑ์ของ vendor หลายเจ้า) ทำอยู่จริง การเปรียบเทียบแบบหักค่าธรรมเนียมแล้ว (net-of-fee) คือมาตรฐานขั้นต่ำ บทความคู่แฝดเรื่อง maker-taker fees and rebates ครอบคลุมสมการค่าธรรมเนียมรายเวนิว, กลไก VIP-tier และเหตุผลที่ fee tier ส่วนเพิ่ม (marginal) ของคุณ — ไม่ใช่ตัวเลขบนป้าย — ควรอยู่ใน router

Optimization ของการ Routing

มาสร้างสูตรของปัญหา child order ให้เป็นทางการ คุณต้องซื้อปริมาณ $Q$ ทันที แบบ marketable ข้าม venue $v = 1,\dots,V$ ให้ $A_v(x)$ เป็นราคา ask ส่วนเพิ่มของ venue $v$ หลังจากกิน $x$ หน่วยของ book มัน (เป็นฟังก์ชันขั้นบันไดที่ไม่ลดลงจาก L2 snapshot) $f_v$ คือ taker fee ของมัน และ $\lambda_v$ คือบทลงโทษต่อหน่วยสำหรับความเก่าและ adverse selection บน venue $v$ (ปรับค่าด้านล่างจาก markout ของคุณเอง) การจัดสรร $q = (q_1, \dots, q_V)$ แก้สมการ

$C_v$ แต่ละตัวเป็น convex (อินทิกรัลของฟังก์ชันที่ไม่ลดลง บวกเทอมเชิงเส้น) ดังนั้นปัญหาจึงเป็น convex และเงื่อนไข KKT บอกเรื่องราวทั้งหมด นั่นคือมีค่า threshold $\mu$ ที่ทำให้

และ $C_v'(0) \ge \mu$ สำหรับ venue ที่ไม่ได้รับอะไรเลย พูดง่ายๆ คือ เทคำสั่งข้าม venue เหมือนกับน้ำ ปรับต้นทุนรวมส่วนเพิ่มให้เท่ากันทุกที่ที่คุณเทรด venue ถูกกันออกก็ต่อเมื่อหน่วยแรกของมัน — ราคาดีที่สุด บวกค่าธรรมเนียม บวกบทลงโทษความเก่า — แย่กว่าหน่วยส่วนเพิ่มที่อื่น

สำหรับ book ที่เป็นฟังก์ชันขั้นบันได คำตอบแบบ water-filling คำนวณได้ด้วยการเดินแบบ greedy บน merged ladder ที่ ปรับด้วยค่าธรรมเนียมและบทลงโทษแล้ว ดังนั้นการเดินแบบ greedy depth-walk ไม่ได้ผิดในตัวมันเอง มันคือคำตอบที่แม่นยำ โดยมีเงื่อนไข ว่าคุณต้อง greedy-walk ต้นทุนส่วนเพิ่มสุทธิที่ปรับ size แบบ haircut แล้ว ไม่ใช่ราคาดิบที่แสดงบนหน้าจอ ความแตกต่างตรงนี้คือความแตกต่างทั้งหมดระหว่าง router กับ screensaver

การจัดการปัญหาทั่วไปแบบมาตรฐานคืองานของ Cont and Kukanov, "Optimal order placement in limit order markets" (Quantitative Finance 17(1), 21–39, 2017; arXiv:1210.1625) พวกเขาสร้างสูตรการวาง order ข้าม venue — รวมถึงการแบ่งระหว่าง limit และ market order, ค่าธรรมเนียมและ rebate, และบทลงโทษสำหรับความเสี่ยงจากการ execute — เป็น convex optimization, อนุมาน closed form ที่ชัดเจนสำหรับการแบ่ง limit/market แบบ single-venue และให้ stochastic-approximation algorithm สำหรับกรณี multi-venue ที่คำนวณการจัดสรรข้าม สิบสอง exchange ได้ภายในเวลาต่ำกว่า 200 มิลลิวินาที กรอบแนวคิดนี้เกิดก่อนคริปโต แต่ถ่ายทอดมาได้เกือบไม่ต้องแก้อะไร เพราะมันไม่เคยสมมติว่ามี NBBO ตั้งแต่แรก มันสมมติแค่ book รายเวนิว ค่าธรรมเนียมรายเวนิว และความไม่แน่นอนเรื่อง fill ซึ่งตรงกับสถานการณ์คริปโตพอดี

ร่างโค้ดขั้นต่ำที่ตรงไปตรงมาของฝั่ง marketable (convex water-fill พร้อม staleness haircut):

import math
from dataclasses import dataclass

@dataclass
class Venue:
    name: str
    asks: list[tuple[float, float]]  # (price, displayed size), sorted
    taker_fee: float                 # fractional, e.g. 0.0002 = 2 bps
    quote_age_ms: float
    kappa: float                     # phantom-liquidity decay rate, 1/ms
    lam: float                       # staleness/toxicity penalty, $ per unit

def allocate(venues: list[Venue], Q: float):
    ladder = []  # (marginal all-in cost, accessible qty, venue)
    for v in venues:
        surv = math.exp(-v.kappa * v.quote_age_ms)  # P(level still there)
        for price, size in v.asks:
            cost = price * (1.0 + v.taker_fee) + v.lam
            ladder.append((cost, size * surv, v.name))
    ladder.sort()

    fills, remaining = {}, Q
    for cost, qty, name in ladder:
        take = min(qty, remaining)
        fills[name] = fills.get(name, 0.0) + take
        remaining -= take
        if remaining <= 1e-12:
            break
    return fills, remaining  # remaining > 0 => book too thin: slice parent

โค้ดตรรกะสิบหกบรรทัด ความฉลาดทั้งหมดอยู่ในข้อมูล input $\kappa$ (อัตราที่ size ที่แสดงระเหยหายไปตามอายุ quote) ปรับค่าจาก IOC fill ratio ของคุณเองในฐานะฟังก์ชันของอายุ quote ณ เวลาที่ส่ง $\lambda_v$ มาจาก markout รายเวนิว (ส่วนสุดท้าย) ทั้งสองตัวถูกวัดจริง ไม่ใช่เดา

ตัวอย่างที่คำนวณจริง ซื้อ $Q = 10$ BTC ข้ามสาม venue:

tape ดิบบอกว่า C มี ask ดีที่สุด (86,990) ตามด้วย B ปรับด้วยค่าธรรมเนียมแล้ว ladder จัดลำดับใหม่หมด ระดับบนสุดของ C สุทธิเป็น $86{,}990 \times 1.00075 = 87{,}055$ ซึ่งเป็น liquidity ที่ แย่ที่สุด บนหน้าจอ ระดับบนสุดของ B สุทธิ 87,004 ของ A สุทธิ 87,017 เมื่อใส่ haircut 30% ให้ size ที่แสดงของ B ($e^{-\kappa \cdot 250\text{ms}} \approx 0.7$) แล้วทำ water-fill จะได้ 1.05 BTC จากระดับแรกของ B, 3.0 จากระดับแรกของ A, 1.4 จากระดับที่สองของ B, 4.0 จากระดับที่สองของ A, 0.55 จากระดับที่สามของ A ค่าเฉลี่ยรวมทั้งหมด: **$87,022.2 ต่อ BTC** router แบบไร้เดียงสาที่เลือกราคาที่แสดงดีที่สุด — C ก่อน แล้ว B ที่ size เต็มหน้าตัก แล้ว C ระดับที่สอง — จ่าย$87,038.8 นั่นคือ แย่กว่า 1.9 bps ประมาณ $166 ต่อ child order 10 BTC หนึ่งครั้ง และสะสมไปเรื่อยๆ ทุก child ของทุก parent ตลอดทั้งวัน และสังเกตประเด็นสำคัญ venue ที่มีราคาแสดงดีที่สุดบน tape ได้รับ flow ศูนย์ จาก router ที่ optimize แล้ว ในคริปโต ไม่มีใครบังคับให้คุณเทรดที่นั่น การ route ผ่าน "protected quote" ไม่ใช่แนวคิดที่มีอยู่ และการจัดสรรที่ถูกต้องมักจะเมิน best price ที่ดูเหมือนดีที่สุดไปเลย

สิ่งที่ convex program ยังละเลย ได้แก่ ความพร้อมกัน (ยิง child ของทุก venue ในมิลลิวินาทีเดียวกัน ไม่งั้นการยกเลิกแบบ van Kervel จะปรับราคา venue ใหม่กลางคัน) ขนาด lot แบบไม่ต่อเนื่องและ notional ขั้นต่ำ (ปัดคำตอบต่อเนื่องแล้วแก้ไขแบบ greedy) และตัวเลือกที่จะ ไม่ ข้าม spread เลย ซึ่งเป็นหัวข้อของส่วนที่ 5 สำหรับคำถามที่ลึกกว่านั้นว่า parent order ขนาดใหญ่ควรถูกแบ่งไปตามเวลาอย่างไรก่อนที่ตรรกะระดับ venue นี้จะทำงาน ดูที่ Almgren–Chriss optimal execution SOR ตัดสินใจว่า child จะไป ที่ไหน ไม่ใช่ เมื่อไหร่ child จะเกิดขึ้น

ข้อจำกัดด้านเงินทุน: SOR คือการบริหารคลัง (Treasury Management)

ทุกอย่างข้างต้นสมมติแบบเงียบๆ ว่าคุณ สามารถ เทรด $q_v$ บน venue $v$ ได้ ในตลาดหุ้นสมมติฐานนี้ได้มาฟรี prime broker เดียว, netted settlement, เทรดตอนนี้แล้วค่อยย้ายเงินทีหลัง แต่ในคริปโต นี่คือข้อจำกัดที่ผูกมัดทั้งระบบ exchange ต้องการ balance แบบ prefunded คุณยกราคา ask ของ Kraken ด้วย USDT ที่นั่งอยู่บน Binance ไม่ได้ ดังนั้นปัญหาที่แท้จริงคือ

โดย $B_v$ คือ balance ที่ใช้ได้ของคุณบน venue $v$ (เป็นสินทรัพย์ quote สำหรับการซื้อ, สินทรัพย์ base สำหรับการขาย) เงื่อนไข KKT ตอนนี้กลายเป็น $C_v'(q_v^*) = \mu - \eta_v$ โดย $\eta_v \ge 0$ คือ multiplier บนเพดาน balance บน venue ที่ถูกจำกัด $\eta_v = \mu - C_v'(B_v) > 0$ ดอลลาร์ส่วนเพิ่มตรงนั้น execute ได้ ถูกกว่า ระดับน้ำของตลาดโดยรวม และคุณถูกบังคับให้ผลัก flow ไปยัง venue ที่แพงกว่า multiplier นั้นไม่ใช่นามธรรม $\eta_v$ คือดอลลาร์ต่อหน่วยที่คุณจะประหยัดได้จริงๆ ถ้ามี balance เพิ่มอีกหนึ่งหน่วยบน venue $v$ ตอนนี้เลย เมื่อรวมตลอด flow ที่คาดการณ์ไว้ มันคือความเต็มใจจะจ่าย (willingness-to-pay) ของคุณสำหรับการโอนเพื่อ rebalance และการตัดสินใจ rebalance กลายเป็นการเปรียบเทียบที่ระบบ treasury ใดๆ ก็ execute ได้ นั่นคือย้าย inventory เมื่อ

ฝั่งขวาของสมการไม่เล็กและไม่คงที่ BTC บนเชนต้องการ 2–6 confirmation (20–60 นาที) ก่อนที่ exchange จะเครดิตให้ การโอน ERC-20 ใช้เวลาหลายนาทีบวก gas ที่พุ่งขึ้นพอดีตอนที่ตลาดคึกคัก รางของ TRC-20 และ Solana เร็วกว่าและถูกกว่าแต่ไม่ได้รองรับในทุกที่ และทุก exchange มีคิวประมวลผลการถอนของตัวเองที่ยืดจากไม่กี่นาทีเป็นหลายชั่วโมงได้พอดีในช่วงเหตุการณ์ผันผวน ซึ่งเป็นตอนที่ router ของคุณต้องการย้าย inventory มากที่สุด เลขคณิตต้นทุนการโอนแบบเต็ม — ค่าธรรมเนียม, การกระจายของ latency และความเสี่ยงด้านราคาที่คุณแบกรับระหว่างกลางทาง — ถูกคลี่คลายไว้ใน บทความ funding-rate arbitrage และถ่ายทอดมาได้แบบคำต่อคำ นั่นคือ SOR rebalance เป็นวัตถุเดียวกันกับการโอน leg แบบ arbitrage รวมถึงฝั่งต้นทุนด้วย

นี่คือเหตุผลที่ผลงานวิชาการที่ควรทำความเข้าใจให้ลึกซึ้งตรงนี้ไม่ใช่เปเปอร์เรื่อง execution แต่คือ Makarov and Schoar (2020), "Trading and Arbitrage in Cryptocurrency Markets" (Journal of Financial Economics 135(2), 293–319) พวกเขาบันทึกความเบี่ยงเบนของราคาข้าม exchange ที่คงอยู่นาน หลายวันถึงหลายสัปดาห์ — รวมถึง "kimchi premium" ของเกาหลีที่เคยเกิน 40% ในช่วงต้นปี 2018 — และแสดงว่า transaction cost อธิบายไม่ได้ แต่เงินทุน arbitrage ที่เคลื่อนไหวช้าและถูกควบคุมโดยเงินทุนอธิบายได้ venue คริปโตไม่ใช่ "ตลาดเสมือนเดียวที่มีจุดเข้าหลายจุด" แบบของ O'Hara–Ye มันคือ pool ที่แยกส่วนกันบางส่วน เชื่อมต่อกันด้วยท่อที่ช้าและมีต้นทุนสูง และ router ของคุณอาศัยอยู่ในความแยกส่วนนั้น SOR คริปโตที่ไม่มีโมเดล treasury ก็เป็นแค่ SOR ตลาดหุ้นที่แต่งตัวเลียนแบบ

ในทางปฏิบัติ นี่กลายเป็น controller สองสเกลเวลา loop เร็ว (มิลลิวินาที) แก้ปัญหา water-fill ที่ถูกจำกัดภายใน balance ปัจจุบัน สำหรับทุก child order loop ช้า (นาทีถึงชั่วโมง) เฝ้าดู time series ของ shadow price $\eta_v$ และ flow ที่คาดการณ์ไว้ และกำหนดการโอนเมื่อองค์ประกอบที่คงอยู่ต่อเนื่องของ $\eta_v$ ผ่านเกณฑ์ต้นทุนการโอน — พร้อม hysteresis เพราะการโยน inventory ไปมาระหว่าง venue ตาม noise คือวิธีที่คุณบริจาค edge ของตัวเองให้กับ Tron network โต๊ะเทรดระดับสถาบันบีบอัดปัญหานี้ด้วยการ settlement นอก exchange (Copper ClearLoop, Ceffu MirrorX) หลักประกันอยู่กับ custodian และถูก mirror ไปยัง venue ต่างๆ ซึ่งลด transfer latency ลงอย่างมากสำหรับ venue ที่รองรับ — มันทำให้ข้อจำกัดแคบลง แต่ไม่ได้ลบมันทิ้ง และมันนำ counterparty line-item ของตัวเองเข้ามาด้วย

Maker-Aware Routing และเกม Queue ข้าม Venue

router ที่ข้าม spread อย่างเดียวกำลังทิ้ง liquidity ที่ถูกที่สุดไว้โดยไม่ซื้อ นั่นคือของตัวคุณเอง กรอบแนวคิด Cont–Kukanov มีคำตอบอยู่แล้ว closed form แบบ single-venue ของพวกเขาแบ่ง order ระหว่างการโพสต์และการเทกตาม fee, queue position และความเกลียดชังความเสี่ยงจากการ execute และเวอร์ชัน multi-venue ก็ขยายความมันออกไป นั่นคือโพสต์แบบ passive บน venue ที่ (maker fee, ความยาว queue, ความน่าจะเป็นในการ fill ภายใน deadline ของ child) เหนือกว่า เทกบน venue ที่ความทันทีทันใดถูกกว่า และปฏิบัติต่อส่วนที่เหลือแบบ passive ที่ยังไม่ fill เป็น flow ที่กลับเข้าสู่ taker optimization อีกครั้งเมื่อถึง deadline

มีจุดพลิกผันเฉพาะของคริปโตสองอย่างที่ทำให้เรื่องนี้ซับซ้อนกว่าเวอร์ชันตลาดหุ้น

การไล่ล่าค่าธรรมเนียมเป็นกับดักที่วัดผลได้ Battalio, Corwin, and Jennings (2016), "Can Brokers Have It All? On the Relation between Make-Take Fees and Limit Order Execution Quality" (Journal of Finance 71(5)) แสดงว่าโบรกเกอร์สหรัฐฯ ที่ route limit order ไปยัง venue ที่ให้ rebate สูงสุดกลับได้ execution ที่แย่กว่าอย่างวัดผลได้ — fill rate ต่ำกว่า คุณภาพที่ realize ได้แย่กว่า — เพราะ venue ที่ให้ rebate คือที่ที่ order ของทุกคนที่ตาม rebate เหมือนกันก็ไปอยู่ด้วย นั่นคือ queue ยาวที่สุด fill ที่ adverse มากที่สุด สิ่งที่คล้ายกันในคริปโตตรงเป๊ะ venue ที่จ่าย maker rebate ดีที่สุดดึงดูด passive quote ของ market maker ทุกราย order ของคุณเข้าไปต่อ queue ที่ลึก และ fill ส่วนใหญ่ตอนที่ราคากำลังจะทะลุผ่านคุณไปแล้ว เศรษฐศาสตร์ maker แบบ หักลบ markout แล้ว รายเวนิว (ส่วนถัดไป) มักจัดอันดับ venue ตรงข้ามกับตารางค่าธรรมเนียมของมัน

ความเหลื่อมของ Latency คือเกมสองด้าน information flow ข้าม venue เดียวกันที่ van Kervel บันทึกไว้ว่าเป็นการยกเลิกเชิงป้องกัน มองจากอีกด้านหนึ่งคือสัญญาณเชิงรุก การเทรดที่ top of book ของ Binance ทำนายการเทรดและการยกเลิกที่ระดับที่สอดคล้องกันของ OKX ได้ภายในไม่กี่มิลลิวินาที router แบบ maker-aware จึงต้อง (ก) ปรับราคา resting order ของตัวเองใหม่ตามเหตุการณ์ ของ venue อื่น — pegging กับ cross-venue microprice ไม่ใช่ local mid — มิฉะนั้นมันจะกลายเป็นคู่สัญญาที่ช้าที่ arbitrageur ข้าม venue เก็บกิน และ (ข) มันเล่นเกมนี้ได้อย่างจงใจ โพสต์บน venue ที่ล้าหลัง hedge บน venue ที่นำหน้าในจังหวะที่ fill เกิดขึ้น นั่นคือ cross-venue queue arbitrage และมันคือโครงสร้าง latency เดียวกันกับที่ถูกใช้ประโยชน์ใน cross-exchange arbitrage execution เพียงแต่ฝังอยู่ในภารกิจการ execute แทนที่จะเป็นสมุดบัญชี stat-arb ข้อกำหนดในการปฏิบัติงานเหมือนกันทุกประการ นั่นคือเหตุการณ์ fill บน venue A และ hedge order ไปยัง venue B ต้องอยู่ใน code path เดียวกันในระดับมิลลิวินาทีหลักเดียว มิฉะนั้น edge จะเป็นของคนอื่น

การวัดคุณภาพการ Routing: Markout และตาราง League

router ในตลาดหุ้นถูกควบคุมด้วยวินัยจากการเปิดเผยข้อมูลตาม Rule 605/606 ไม่มีอะไรควบคุมวินัยของ router คุณ นอกจาก TCA ของคุณเอง — กรอบแนวคิดจาก implementation shortfall and TCA คือกระดานคะแนน ต่อไปนี้คือส่วนที่เฉพาะเจาะจงกับ router

การวัดระดับอะตอมคือ markout รายเวนิว สำหรับทุก fill บันทึก mid (แบบ consolidated ที่แก้ latency แล้ว) ที่ $t + \Delta$ สำหรับ $\Delta \in \{100\text{ms}, 1\text{s}, 10\text{s}, 1\text{min}\}$ โดยมีเครื่องหมายเพื่อให้ค่าลบหมายถึงตลาดเคลื่อนไหวสวนทาง fill ของคุณ รวมเป็นตาราง league แบบครบวงจร

คอลัมน์ค่าธรรมเนียมบอกว่า B คือ venue ที่ถูก คอลัมน์ต้นทุนรวมบอกว่า B คือ venue ที่ แพง quote ที่เก่าของมัน fill ให้คุณอย่างเลือกสรรตอนที่ตลาดกำลังเคลื่อนผ่านมันไปแล้ว และ markout 1 วินาทีเก็บบิลนั้น การกลับด้านนี้ — อันดับตามค่าธรรมเนียมเทียบกับอันดับตามต้นทุนที่มีผลจริง — คือสิ่งที่พบเจอสม่ำเสมอที่สุดเมื่อโต๊ะเทรดสร้างตารางนี้ขึ้นมาครั้งแรก และมันคือตัวเลขที่ควรกลับไปอยู่ใน router พอดี บทลงโทษ $\lambda_v$ ของ convex program คือ ส่วนขาดของ markout รายเวนิวที่คงอยู่ต่อเนื่อง ซึ่งถูกวัด ปรับให้เรียบ และอัปเดต router กับ TCA ก่อตัวเป็น closed loop ไม่งั้นทั้งสองอย่างก็ใช้ไม่ได้ผล

กับดักเชิงระเบียบวิธีอย่างหนึ่ง ตาราง league ที่สร้างจาก router ที่ทำงานอยู่จริงถูกปนเปื้อนด้วย selection bias ถ้า router ส่ง flow ที่ยากและมีข้อมูล (informed) ไปยัง venue ที่ลึกอยู่แล้ว และส่ง flow ที่ง่ายไปยัง venue ที่ถูก markout ของ venue ที่ลึกจะดูแย่อย่างไม่เป็นธรรม วิธีแก้ที่สะอาดคือการสุ่มแบบจงใจ — route child order สองสามเปอร์เซ็นต์แบบสุ่มสม่ำเสมอ (router แบบ $\varepsilon$-greedy ซึ่ง quant จะจำได้ว่าเป็น bandit ที่มี convex-optimization prior) — เพื่อให้มี counterfactual อยู่จริง มันมีต้นทุนเป็น basis point บนส่วนที่สุ่ม และมันคือวิธีเดียวที่จะพิสูจน์ได้ว่า flow อีก 95% ที่เหลือถูก route อย่างดี

สรุปแล้ว stack ทั้งหมดคือ consolidated book ที่ซื่อสัตย์ต่อ latency, convex water-fill บนต้นทุนส่วนเพิ่มสุทธิพร้อมพารามิเตอร์การระเหยและความเป็นพิษที่วัดได้จริง, loop เร็วที่ถูกจำกัดด้วย balance ซึ่ง shadow price ของมันขับเคลื่อน loop ช้าที่ตระหนักถึงต้นทุนการโอน, การวาง passive ที่เคารพ queue และ information flow ข้าม venue, และ TCA แบบสุ่มที่อิงจาก markout ที่ป้อนกลับทุกพารามิเตอร์ ไม่มีส่วนประกอบไหนในนี้ที่ลึกซึ้งด้วยตัวมันเอง แต่ระบบทั้งหมดลึกซึ้ง เพราะในคริปโต ต่างจากตลาดหุ้น ไม่มีหน่วยงานกำกับดูแลใดสร้างชั้นไหนของมันให้คุณเลย และตลาดเก็บค่าธรรมเนียม 2 bps ต่อ child order ตลอดไป จนกว่าคุณจะสร้างมันขึ้นมาเอง