Di dalam slice: taktik child-order antara scheduler anda dan exchange

Satu trajektori Almgren-Chriss memberi anda satu angka: jual 4.2 BTC dalam lima minit akan datang. Satu jadual VWAP memberi anda jenis angka yang sama dengan justifikasi berbeza. Tiada satu pun yang menyatakan apa yang berlaku seterusnya — sama ada 4.2 BTC itu masuk ke book sebagai satu order marketable, duduk di touch mengumpul yuran maker, tersembunyi di sebalik display 0.3 BTC, atau di-reprice sebelas kali mengejar quote yang hanyut. Lapisan keputusan kedua itu ialah lapisan taktik, dan pada book crypto yang didominasi yuran, ia lazimnya menggerakkan lebih banyak PnL per slice berbanding pilihan scheduler di atasnya. Bajet interval scheduler berbeza antara TWAP dan Almgren-Chriss yang ditala baik hanya sebanyak beberapa bps impak sepanjang keseluruhan parent order; membayar yuran taker pada slice yang sepatutnya boleh dibuat sebagai maker, atau kehilangan queue position akibat reprice yang cuai, boleh menelan kos sebanyak itu setiap jam. Artikel ini membincangkan lapisan yang dijalankan oleh semua orang tetapi hampir tiada siapa yang mendokumentasikannya: state machine yang menentukan bagaimana setiap child order menyentuh book.

Dua lapisan, satu antara muka sempit

Buku Lehalle dan Laruelle, Market Microstructure in Practice (edisi ke-2, 2018), memformalkan apa yang dicapai oleh setiap execution desk: lapisan strategik (scheduler) yang mengagihkan kuantiti merentasi masa, dan lapisan taktikal (microtrader) yang menguruskan setiap agihan terhadap book yang live. Pemisahan ini bukan sekadar estetik — kedua-dua lapisan hidup pada jam dan data yang berbeza. Scheduler berfikir dalam unit minit, menggunakan ramalan volatiliti dan volum, dan menyelesaikan masalah variasional. Lapisan taktik pula berfikir dalam unit milisaat hingga saat, menggunakan delta L2 dan anggaran queue, dan menyelesaikan satu siri masalah stopping yang kecil.

Antara muka di antara keduanya harus sempit. Ke bawah, bagi setiap slice $k$:

• bajet $q_k$ — kuantiti untuk dieksekusi dalam interval ini (iaitu $n_k$ bagi Almgren-Chriss, atau kenaikan lengkung volum bagi VWAP);
• tetingkap $\tau_k$ — panjang slice;
• urgency — bagi Almgren-Chriss, calon semula jadi ialah $\kappa = \sqrt{\lambda\sigma^2/\eta}$, yang telah pun memampatkan risk aversion, volatiliti, dan likuiditi ke dalam satu kadar; bagi scheduler VWAP pula ia biasanya berupa jarak jalur ("kita ketinggalan 1.8% daripada lengkung sasaran").

Ke atas: fill berserta cap masa dan yuran, baki yang belum terisi, dan implementation shortfall pada peringkat slice yang diukur berbanding mid ketibaan interval. Yang terakhir ini penting: parameter impak scheduler $\eta$ telah pun menetapkan harga apa yang sepatutnya dikenakan untuk menuntut likuiditi pada kadar $q_k/\tau_k$. Skop kerja lapisan taktik hanya satu ayat: merealisasikan fill pada kos yang lebih baik daripada kos tersirat-$\eta$, tanpa membocorkan kewujudan parent order. Jika shortfall slice yang anda ukur secara konsisten mengatasi kos model, $\eta$ yang ditentukur boleh diturunkan, scheduler menjadi lebih pantas, dan keseluruhan stack bertambah baik. Jika anda tidak dapat mengukur shortfall slice secara berasingan daripada kos jadual, anda tidak dapat menala mana-mana lapisan — anda hanya ada satu angka kabur dan dua alat kawalan.

Polisi baki juga sebahagian daripada kontrak ini. Apabila sesuatu slice berakhir dengan kuantiti belum terisi, sama ada lapisan taktik memaksa penyelesaian (cross baki tersebut — lalai di bawah urgency deadline) atau memulangkannya kepada scheduler untuk diagihkan semula merentasi slice yang berbaki (boleh diterima pada awal jadual $\kappa$ rendah, tetapi merbahaya berhampiran deadline di mana agihan semula secara senyap-senyap membesar menjadi slice akhir yang besar).

Tangga eskalasi: pasif dahulu, agresif mengikut deadline

Hasil kajian paling awal dalam bidang ini ialah Harris (1998), "Optimal dynamic order submission strategies in some stylized trading problems" (Financial Markets, Institutions & Instruments 7(2)): bagi seorang peniaga likuiditi yang perlu menyelesaikan satu dagangan menjelang deadline, strategi optimum adalah dinamik — berdiri di dalam book dengan limit order semasa masa masih murah, reprice ke arah pasaran apabila deadline menghampiri, dan cross pada akhirnya. Setiap enjin taktik production adalah keturunan bentuk ini: post di touch, age out, eskalasi, cross. Apa yang ditambah oleh jadual yuran moden dan dinamik queue ialah aritmetik tepat bila setiap peralihan itu tercetus.

Break-even untuk crossing

Kerja per unit, harga relatif kepada mid semasa, untuk pembelian. Crossing sekarang menelan kos separuh spread ditambah yuran taker:

Posting di bid sepanjang tetingkap $\tau$ terisi dengan kebarangkalian $p$; satu fill memperoleh separuh-spread dan membayar yuran maker $f_m$ (negatif jika ia rebat). Tiada fill bermakna crossing pada penghujung tetingkap selepas harga, secara purata, telah bergerak melawan anda sebanyak $\delta(\tau) = E[\,\text{pergerakan mid buruk} \mid \text{tiada fill}\,] > 0$ — nilai ini positif secara tegas, kerana tiada-fill dan drift buruk adalah peristiwa yang sama: bid anda tidak dilanggar apabila pasaran melonjak menjauhinya. Jangkaan kos posting:

Posting mengatasi crossing jika dan hanya jika

di mana $\Pi$ ialah hadiah — jumlah round-trip penuh yang anda perolehi dengan menjadi maker berbanding taker: spread ditambah perbezaan yuran. Ini ialah break-even yang sama yang mengawal keseluruhan ekonomi maker-taker dalam eksekusi, dimampatkan kepada satu slice sahaja.

Contoh angka, BTCUSDT perp: mid $100,000, spread satu tick s = \0.10$, yuran gaya VIP0 maker 2 bps / taker 5 bps, jadi$f_m = $20$,$f_t = $50$per BTC. Hadiah$\Pi = 0.10 + 50 - 20 = $30.10 \approx 3$bps — perhatikan spread menyumbang hampir tiada apa-apa; pada crypto major yang ketat, hadiah itu *ialah* perbezaan yuran. Ambil vol harian 3$\sigma_{\text{day}} = $3{,}000$) dan$\delta(\tau) \approx 0.6,\sigma_{\text{day}}\sqrt{\tau/86400}$ (0.6 itu ialah haircut adverse-selection yang perlu anda tentukur, bukan dipercayai bulat-bulat):

• $\tau = 10$ s: \delta \approx \19$, jadi$p^* = 19/49 \approx 0.39$. Post hanya jika anda menjangkakan sekurang-kurangnya 39% fill dalam masa 10 saat.
• $\tau = 60$ s: \delta \approx \47$, jadi$p^* = 47/77 \approx 0.61$.
• Dengan rebat maker 1 bp berbanding yuran 2 bp (f_m = -\10$):$\Pi = $60.10$, dan ambang 10 s turun kepada$p^* \approx 0.24$.

Dua fakta struktur terhasil daripada ini. Pertama, $\delta$ berkembang seperti $\sqrt{\tau}$ sementara $\Pi$ kekal malar, jadi $p^\*(\tau) \to 1$: kesabaran mempunyai tarikh luput yang keras, dan timer age-out bukanlah heuristik tetapi titik persilangan dua lengkung — $p(\tau)$ anggaran anda (cekung, tepu apabila queue di hadapan anda semakin luput) berbanding $p^\*(\tau)$ (yang meningkat). Kedua, tier yuran tempat anda berdagang secara fizikal menggerakkan tangga ini. Naik taraf tier yang mengurangkan yuran taker menjadikan taktik optimum anda lebih agresif — satu gandingan yang kebanyakan orang hanya sedar apabila statistik fill mereka berubah selepas re-tier VIP.

Cont dan Kukanov, "Optimal order placement in limit order markets" (Quantitative Finance 17(1), 2017; arXiv 2012), menjadikan ini rigor dalam satu tempoh: minimumkan jangkaan kos untuk mengeksekusi $S$ unit yang dibahagikan antara market dan limit order (merentasi satu atau beberapa venue), dengan penalti bagi shortfall. Penyelesaian satu-venue adalah eksplisit dan mempunyai struktur newsvendor: saiz limit order optimum digerakkan oleh taburan queue outflow — post saiz secara agresif apabila queue di hadapan kecil berbanding jangkaan outflow, dan lindungi risiko tail dengan market order. Sambungan multi-venue mereka diselesaikan melalui stochastic approximation dan merupakan teras intelektual bagi logik peruntukan pasif setiap smart order router. Bacaan praktikal bagi enjin taktik: $p$ dalam break-even di atas bukanlah pemalar — ia adalah fungsi kepada queue position dan kadar drain, itulah sebabnya lapisan taktik mesti menggunakan penganggar queue-position sebagai input kelas pertama.

Parameter urgency memampatkan keseluruhan tangga ini. $\kappa$ tinggi daripada scheduler bermakna masa ciri $\theta = 1/\kappa$ pendek: tetingkap mengecil, $p^\*$ meningkat, dan enjin terus melompat kepada crossing — dengan betul, kerana scheduler telah pun mengisytiharkan bahawa risiko inventori mengatasi penjimatan yuran. $\kappa$ rendah pula meregangkan fasa pasif. Lapisan taktik tidak sepatutnya sekali-kali menerbitkan semula urgency daripada pandangannya sendiri terhadap pasaran; itu tugas scheduler, dan menduplikasikannya mencipta dua pengawal yang saling bertentangan.

Reprice tanpa membakar queue position anda

Setelah post dibuat, quote akan hanyut. Mengejarnya secara naif — cancel, post semula pada touch baharu, ulang — adalah cara enjin taktik secara senyap-senyap memusnahkan kebarangkalian fill yang menjustifikasikan posting itu sendiri. Queue position adalah aset dengan nilai dolar yang boleh diukur (Moallemi dan Yuan, 2016, meletakkan harga padanya: kedudukan front-of-queue dalam book FIFO yang likuid bernilai sebahagian besar daripada spread), dan setiap keputusan reprice adalah satu dagangan: jual queue position semasa anda, beli satu di belakang tahap harga yang berbeza. Dagangan itu hanya berbaloi dilakukan apabila nilai tahap baharu melebihi nilai tahap lama ditambah kos messaging. Ini memerlukan pengetahuan tentang apa sebenarnya yang dilakukan oleh amend setiap venue terhadap kedudukan anda dalam baris — dan jawapannya amat tidak seragam.

CME Globex mendokumentasikan semantik paling bersih: mengurangkan kuantiti order mengekalkan keutamaan masa; menambah kuantiti atau menukar harga menghantar anda ke belakang queue. Ini ialah model rujukan — quantity-down adalah percuma, segala-galanya yang lain adalah re-queue.

Binance spot secara sejarahnya hanya menawarkan POST /api/v3/order/cancelReplace — satu operasi cancel-plus-new yang kelihatan atomik tetapi secara eksplisit bukan transaksional. Dua mod: STOP_ON_FAILURE (lalai — jika cancel gagal, tiada order baharu) dan ALLOW_FAILURE (letakkan order baharu walaupun cancel gagal — helo, pendedahan berganda tanpa disengajakan). Operasi ini boleh berjaya secara separa, ditandakan dengan HTTP 409, jadi OMS anda mesti menyesuaikan kedua-dua kaki secara berasingan; dan order baharu sentiasa memulakan kehidupan queue yang baharu. Kemudian pada 2025 Binance melancarkan Order Amend Keep Priority (PUT /api/v3/order/amend/keepPriority): kurangkan kuantiti di tempat, kekalkan keutamaan masa, dengan kos sifar bagi kiraan order belum terisi. Semantik CME, lima belas tahun kemudian — dan hanya separuh quantity-down sahaja.

Binance USDT-M futures mempunyai endpoint modify sebenar (PUT /fapi/v1/order), tetapi bacalah cetakan halus: hanya order LIMIT, kedua-dua price dan quantity mesti dihantar, dan "modified orders will be reordered in the match queue" — dokumentasi menjanjikan tiada pengekalan keutamaan walaupun untuk pengurangan kuantiti tulen. Anggaplah setiap modify futures sebagai reset queue yang kebetulan menjimatkan satu mesej dan mengekalkan order ID. Satu perkara tajam yang perlu diketahui: mengubah suai order GTX (post-only) kepada harga yang akan crossing menyebabkan order tersebut dibatalkan, bukan ditolak-dan-dikekalkan — implementasi peg yang tidak menyemak perkara ini kadangkala akan meng-amend dirinya sendiri hingga tidak wujud.

OKX mendedahkan POST /api/v5/trade/amend-order (newPx, newSz, dengan cxlOnFail untuk auto-cancel apabila amend gagal). Ia satu mesej, mengekalkan order ID, dan mengesahkan secara asinkron — sCode = 0 bermakna "permintaan diterima", dan hasil sebenar tiba pada saluran order sebagai amendResult. Apa yang secara jelas tidak dinyatakan oleh dokumentasi awam ialah tingkah laku queue-priority. Jangan isi jurang dokumentasi itu dengan optimisme. Ukurlah: post dua order penanda pada tahap yang senyap, amend saiz satu daripadanya ke bawah, dan perhatikan yang mana terisi dahulu dalam beberapa ratus percubaan. Sehingga anda mempunyai data itu, andaian konservatif — mana-mana perubahan harga meng-re-queue anda di mana-mana sahaja, quantity-down hanya mengekalkan keutamaan di tempat yang didokumentasikan secara eksplisit — adalah satu-satunya yang boleh dipertahankan.

Akibat dasar-dasarnya:

1. Hysteresis, bukan pegging. Reprice hanya apabila touch telah hanyut lebih daripada satu jalur $b$ tick daripada harga resting anda. Di dalam jalur itu, drift adalah hingar dan queue position anda bernilai lebih daripada satu tick penambahbaikan harga. Jalur permulaan yang munasabah ialah 1–3 tick yang diskalakan mengikut vol jangka pendek; jalur yang betul menjadikan reprice marginal itu neutral EV: $V_{\text{new}} - V_{\text{cur}} = c_{\text{msg}}$, dengan $V$ ialah nilai queue gaya Moallemi-Yuan dan $c_{\text{msg}}$ ialah harga bayangan had kadar (rate-limit) anda. Operasi amend/cancel-replace menggunakan bajet kadar order pada kedua-dua venue Binance; enjin taktik yang peg setiap tick akan melaparkan sisa sistem anda daripada kapasiti mesej.
2. Amend ke bawah, jangan sekali-kali cancel-repost ke bawah. Apabila scheduler memotong bajet slice di tengah jalan (scheduler POV melihat volum semakin kering, penyelesaian semula Almgren-Chriss selepas fill separa), gunakan laluan yang mengekalkan keutamaan di mana ia wujud. Ini satu-satunya makan tengah hari percuma dalam keseluruhan lapisan ini.
3. Urgency tidak simetri pada reprice. Reprice ke arah pasaran (mengejar) mereset queue anda pada harga yang lebih buruk — ia sepatutnya hanya tercetus daripada logik eskalasi, mengikut timernya. Reprice menjauhi (pasaran datang kepada anda) adalah hadiah; ambillah ia hanya melalui jalur pasif, kerana tahap semasa anda hampir pasti akan terisi.

Iceberg, saiz display, dan apa yang membocorkan niat anda

Saiz display adalah keputusan ketiga, dan ia adalah dagangan dua hala yang sebenar, bukan butang stealth percuma. Rekod empirikal:

• Frey dan Sandås ("The Impact of Iceberg Orders in Limit Order Books", kertas kerja 2009; Quarterly Journal of Finance, 2017), pada data Xetra: iceberg order membawa 9.3% volum yang dihantar dan 15.9% volum yang dieksekusi, bersaiz 12–20x lebih besar daripada limit order biasa, dan — kemuncaknya — apabila peserta lain mengesan satu iceberg, mereka bertindak balas dengan market order yang sepadan. Saiz tersembunyi, sebaik sahaja disimpulkan, menarik flow: carian likuiditi latent berfungsi dalam kedua-dua arah.
• Bessembinder, Panayides dan Venkataraman ("Hidden liquidity: an analysis of order exposure strategies in electronic stock markets", JFE 94(3), 2009), pada Euronext Paris, di mana order tersembunyi merupakan 44% volum sampel: menyembunyikan menurunkan implementation shortfall tetapi juga menurunkan kebarangkalian eksekusi penuh dan memanjangkan masa-untuk-siap. Exposure membeli fill dan membayarnya dalam bentuk impak; opsyen ini digunakan tepat seperti yang diramalkan oleh teori — order agresif mendedahkan diri untuk menarik counterparty, saiz sabar menyembunyikan diri.
• Esser dan Mönch ("The navigation of an iceberg", Finance Research Letters 4(2), 2007) melayan saiz peak sebagai satu pengoptimuman: display lebih besar terisi lebih pantas, display lebih kecil membocorkan lebih sedikit, dan optimum itu adalah interior.

Mekanik dahulu, kerana ia mengikat pengoptimuman: pada hampir setiap venue yang menyokong iceberg native (Binance spot melalui icebergQty, OKX melalui iceberg algo order-nya), setiap refill peak yang kelihatan memasuki belakang queue pada harga itu. Oleh itu, satu iceberg bukanlah "satu order dengan saiz tersembunyi" — ia adalah satu urutan order kecil, setiap satu membayar penuh queue-wait, tercetus secara automatik. Pada break-even yuran di atas, ini penting: $p$ efektif bagi setiap peak ialah kebarangkalian fill di belakang queue, bukan kedudukan asal anda. Queue yang dalam menghukum peak kecil dua kali ganda — fill lebih perlahan dan lebih banyak adverse selection bernilai refill.

Kemudian masalah signaling. Kaedah pengesanan Frey dan Sandås sendiri adalah kisah amaran: pengesan frekuentis mereka bergantung pada dua corak kemalasan implementasi paling biasa — saiz peak yang malar dan cap masa refill yang sama dengan cap masa dagangan yang mengeksekusinya. Mana-mana peserta yang menjalankan pengesan itu (dan pada venue crypto, ramai yang berbuat demikian — metadata matching exchange sendiri malah memudahkan lagi bagi flow yang colocated) menyusun semula saiz tersembunyi anda dalam beberapa refill sahaja. Vektor kebocoran, disusun mengikut kekerapan saya melihatnya di lapangan:

1. Saiz display yang malar atau bulat (0.5 BTC, setiap kali).
2. Refill segera dan deterministik selepas eksekusi peak-penuh — tandatangan cap-masa-sama.
3. Timer eskalasi deterministik: cross tepat 30 s ke dalam setiap slice dan tape menunjukkan metronome.
4. Kependaman dan jalur reprice yang tetap — kadens amend anda adalah cap jari yang sama mengenal pastinya seperti saiz order anda, iaitu subjek cap jari digital dan pengenalan peniaga.

Kos untuk dikesan bukanlah hipotesis. Van Kervel dan Menkveld ("High-frequency trading around large institutional orders", Journal of Finance 74(3), 2019) menunjukkan HFT mula-mula condong melawan metaorder institusi — menyediakan likuiditi yang digunakan oleh taktik pasif anda — kemudian bertukar kepada berdagang bersama order tersebut sebaik sahaja kegigihannya mendedahkan maklumat, back-running baki dan meningkatkan kos parent secara ketara. Institusi mereka bertindak balas dengan menimbang keuntungan spekulatif berbanding risiko pengesanan. Lapisan taktik anda adalah tepat di mana pertukaran tersebut dilaksanakan: rawakkan saiz display (30–70% seragam daripada asas berskala-vol berfungsi dengan baik), goncangkan (jitter) setiap timer sebanyak ±20–30%, sekali-sekala biarkan satu refill menunggu, dan jangan sekali-kali biarkan dua child order berkongsi saiz, fasa timer, dan profil kependaman yang sama. Tiada satu pun daripada ini menelan kualiti fill yang boleh diukur; kesemuanya menaikkan noise floor bagi sesiapa yang cuba memadankan pengesan kepada flow anda.

Enjin taktik yang minimal

Keseluruhan lapisan di atas dimampatkan kepada satu state machine kecil per slice: IDLE → POSTED → (reprice loop) → CROSSING → DONE, dengan pintu break-even pada kemasukan, satu jalur hysteresis semasa posted, dan eskalasi deadline. Versi di bawah sengaja dibuat minimal — tiada adapter venue, tiada pengurusan iceberg — tetapi ia event-driven dan bebas side-effect, jadi ia terus masuk ke dalam simulator rung-4 yang sedar-queue daripada tangga simulasi fill: simulator memanggil on_tick/on_fill, dan mentafsir tindakan sebagai post → GTX/post-only, cross → IOC, cancel_replace/amend_down → semantik venue daripada matriks di atas.

import math
from dataclasses import dataclass
from enum import Enum, auto

class State(Enum):
    IDLE = auto(); POSTED = auto(); CROSSING = auto(); DONE = auto()

@dataclass
class Fees:
    maker: float          # $ per unit; negative = rebate
    taker: float          # $ per unit

@dataclass
class Cfg:
    tick: float
    sigma_1s: float       # $ per sqrt(second), from your live vol estimator
    adverse_frac: float = 0.6   # E[adverse move | no fill] ~ 0.6 * sigma; calibrate
    reprice_band: float = 2.0   # ticks of touch drift tolerated before repricing
    escalate_frac: float = 0.7  # cross the remainder at this fraction of the window

class SliceTactic:
    """One instance per scheduler slice. Drive it from a fill simulator or OMS."""

    def __init__(self, side: str, qty: float, window: float, fees: Fees, cfg: Cfg):
        self.side, self.qty, self.window = side, qty, window
        self.fees, self.cfg = fees, cfg
        self.filled, self.state, self.px, self.t0 = 0.0, State.IDLE, None, None

    def p_star(self, spread: float, tau: float) -> float:
        """Break-even fill probability for posting over a window tau."""
        delta = self.cfg.adverse_frac * self.cfg.sigma_1s * math.sqrt(tau)
        prize = spread + self.fees.taker - self.fees.maker
        return delta / (prize + delta)

    def p_fill(self, queue_ahead: float, drain: float, tau: float) -> float:
        """Crude queue-drain estimate; swap in your calibrated fill model."""
        if drain <= 0: return 0.0
        return min(1.0, drain * tau / max(queue_ahead + self.qty, 1e-9))

    def on_tick(self, t, bid, ask, queue_ahead, drain):
        if self.state == State.DONE: return []
        if self.t0 is None: self.t0 = t
        left = self.qty - self.filled
        elapsed, remain = t - self.t0, self.window - (t - self.t0)
        touch = bid if self.side == "buy" else ask

        if elapsed >= self.cfg.escalate_frac * self.window and left > 0:
            self.state = State.CROSSING          # deadline: pay up, finish
            return [("cross", left)]

        if self.state == State.IDLE:
            if self.p_fill(queue_ahead, drain, remain) >= self.p_star(ask - bid, remain):
                self.state, self.px = State.POSTED, touch
                return [("post", touch, left)]    # GTX / post-only
            self.state = State.CROSSING           # posting is -EV here
            return [("cross", left)]

        if self.state == State.POSTED:
            if abs(touch - self.px) / self.cfg.tick > self.cfg.reprice_band:
                self.px = touch                   # hysteresis breached:
                return [("cancel_replace", touch)]  # accept the queue reset
        return []

    def on_fill(self, t, fill_qty):
        self.filled += fill_qty
        if self.filled >= self.qty - 1e-9:
            self.state = State.DONE
            return [("slice_done", self.filled)]
        return []

    def on_budget_cut(self, new_qty):
        """Scheduler revised the slice down: amend-down keeps queue priority
        where documented (CME, Binance spot amend/keepPriority)."""
        self.qty = new_qty
        left = new_qty - self.filled
        return [("amend_down", left)] if left > 0 else [("cancel",)]

Tiga peringatan jujur. p_fill di sini hanyalah nisbah placeholder — dalam production ia sepatutnya menjadi model yang ditentukur secara live dan dibucketkan daripada artikel simulasi fill, kerana keseluruhan pintu post/cross hanya sebaik anggaran itu. adverse_frac menyembunyikan kuantiti paling sukar dalam artikel ini ($\delta$ bergantung kepada rejim dan melonjak tepat apabila posting paling menggoda); anggarkan ia daripada hasil tiada-fill anda sendiri, dibucketkan mengikut rejim vol. Dan enjin di atas melakukan reprice melalui cancel-replace secara tanpa syarat — versi yang sedar-venue sepatutnya menghalakan perubahan quantity-down melalui laluan yang mengekalkan keutamaan dan mengenakan caj setiap tindakan terhadap satu bajet mesej.

Jalankan ia di dalam simulator berbanding tape replay sebelum mempercayai mana-mana parameter. Eksperimen yang penting: tetapkan scheduler, imbas escalate_frac dan reprice_band, dan plotkan shortfall slice berbanding kos model tersirat-$\eta$. Permukaan itu mempunyai plateau — jalur luas parameter hampir-optimum — dan dua tebing: eskalasi terlalu lewat (baki belum terisi crossing ke dalam momentum) dan reprice terlalu bersemangat (semua nilai queue terbakar). Anda mahu tahu di mana tebing-tebing anda sebelum production menemuinya untuk anda.

Apa yang perlu dibawa pulang

1. Dua lapisan, satu kontrak. Scheduler menentukan berapa banyak dan bila; taktik menentukan bagaimana. Antara mukanya ialah bajet, tetingkap, urgency ke bawah; fill dan shortfall slice berbanding mid ketibaan interval ke atas. Jika anda tidak dapat mengaitkan shortfall kepada satu lapisan, anda tidak dapat menala mana-mana satu.
2. Pintu post/cross adalah aritmetik, bukan naluri. Post jika dan hanya jika $p > \delta/(\Pi + \delta)$ dengan $\Pi = s + f_t - f_m$. Pada book crypto yang ketat, hadiah itu ialah perbezaan yuran, jadi tier yuran anda menentukan taktik anda — tala semula tangga tersebut selepas setiap re-tier.
3. Timer age-out adalah titik persilangan dua lengkung — kebarangkalian fill yang tepu berbanding adverse selection yang berkembang seperti $\sqrt{\tau}$ — bukan pemalar cerita rakyat.
4. Queue position adalah aset; ketahui semantik amend setiap venue sebelum membelanjakannya. CME: quantity-down mengekalkan keutamaan. Binance spot: cancelReplace sentiasa re-queue, amend-keepPriority 2025 mengekalkannya untuk pengurangan kuantiti. Binance futures: setiap modify re-queue. OKX: tidak didokumentasikan — ukur, dan sementara itu anggap yang paling teruk.
5. Iceberg adalah satu urutan order di belakang queue, dan yang malas boleh dibaca. Peak yang malar dan refill cap-masa-sama adalah tandatangan pengesanan yang telah diterbitkan; rawakkan saiz dan timer atau terimalah risiko di-back-run.
6. Hantar state machine ke dalam simulator fill anda dahulu. Lapisan taktik adalah bahagian stack di mana backtest dan production paling banyak menyimpang — itulah sebabnya ia perlu berada di dalam simulator, bukan ditampal selepas fakta.

Pautan berguna

1. Harris, L. — Optimal Dynamic Order Submission Strategies in Some Stylized Trading Problems, Financial Markets, Institutions & Instruments 7(2), 1-76 (1998)
2. Cont, R., Kukanov, A. — Optimal Order Placement in Limit Order Markets, Quantitative Finance 17(1), 21-39 (2017)
3. Frey, S., Sandås, P. — The Impact of Iceberg Orders in Limit Order Books (2009)
4. Bessembinder, H., Panayides, M., Venkataraman, K. — Hidden Liquidity: An Analysis of Order Exposure Strategies in Electronic Stock Markets, Journal of Financial Economics 94(3), 361-383 (2009)
5. van Kervel, V., Menkveld, A. — High-Frequency Trading around Large Institutional Orders, Journal of Finance 74(3), 1091-1137 (2019)
6. Moallemi, C., Yuan, K. — A Model for Queue Position Valuation in a Limit Order Book (2016)
7. Lehalle, C.-A. — Market Microstructure Knowledge Needed for Controlling an Intra-Day Trading Process (2011)
8. Binance Spot API — Order Amend Keep Priority
9. Binance Spot API — Trading endpoints (cancelReplace semantics)
10. Binance USDT-M Futures API — Modify Order
11. OKX API v5 — Amend order
12. CME Group — Order Functionalities (modification and time priority)

Citation

@article{soloviov2026childordertactics,
  author = {Soloviov, Eugen},
  title = {Inside the slice: child-order tactics between your scheduler and the exchange},
  year = {2026},
  url = {https://marketmaker.cc/blog/child-order-execution-tactics},
  description = {The tactics layer between execution schedulers and the exchange: passive-then-aggressive escalation with maker-taker break-even math, amend vs cancel-replace queue semantics across venues, iceberg anti-signaling, and a per-slice Python state machine for fill simulators.}
}